Emilio Jesús Gallego Arias
Emilio Jesús Gallego Arias
I am opening this issue so we can coordinate about the future of the build infrastructure; I predict that many changes will happen and this is very annoying for developers....
As the project grows, it seems to me that our current setup with vanilla JavaScript may be not enough: we have quite a few components and interfaces among them, and...
`esy` https://esy.sh does provide good support for a hybrid build flow with opam and npm; it thus makes a lot of sense for jsCoq, and we should study how to...
We should have a better management of messages in the message buffer. In particular, outputs of each command should be grouped together. This could be implemented by grouping by `span_id`.
Opam 2.1 will provide lockfiles, so we can exactly reproduce a set of packages à la npm; this is IMHO very useful for us so we should implement it once...
This is an issue to track alternatives to `js_of_ocaml`; personally, `js_of_ocaml` has been serving us super well and it is hard to have a better tradeoff; however lack of tail...
Following discussion on #176 , it turns out the first step is to port jsCoq to Codemirror 6 Migration guide is at https://codemirror.net/6/docs/migration/ , not sure about the difficulty yet.
This has been discussed a few times but so far no issue; our best bet seems: https://github.com/datavis-tech/codemirror-ot
For example, when we hover a sentence with a goal, we could display a tooltip "Press _Ctrl_ to see the goal at point" We should try to anticipate actually being...
The [Coq HoTT library](https://github.com/HoTT/HoTT) is a bit special as it uses it's own prelude and thus cannot be used as a regular package due to the need to pass `-noinit...