On Sat, 2 Dec 2017 19:40:35 +1100 Brian Ballsun-Stanton wrote:

A desktop editor, not so much. But it'd be wonderful to have a cloud based one with Git integration.

+1 for desktop editor, although I plan to use Emacs for my ConTeXt writing, so having better support in AUCTeX would be also nice. At the end, I believe that Emacs is not so scary as it looks, especially for the folks ready to enter into the world of things like ConTeXt... As far as Git integration is concerned, not very important feature for me since I prefer using Fossil. ;) Btw, Lout is also interesting, but, iirc, it lacks proper Unicode (UTF-8) support. Recently I was also looking at groff/mom... Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection.

Hi Jonas, A desktop editor, not so much. But it'd be wonderful to have a cloud based one with Git integration. I've rolled my own with floobits and my own VM, but that doesn't scale and I can't share it with my students.

What you describe has already been worked on by overleaf in terms of a realtime option instead of a code option. Maybe extending their work would be a good place to start? Cheers, -Brian Hi Brian,

The type of users that I would like to target, will be those writting rather classical documents of more than 10 - 12 pages and wanting to be able to focus much more on the content than in the formatting but still have good looking results. Typically students or professional that are used to write reports with Word but would be interested to use a more productive editor, but not ready to move too far away from WYSIWYG. I didn't made a definitive choice yet, but I believe that being able to use the editor offline, independantly of the user internet connection, is almost like a must have. But what sounds interesting, as a nice to have, would be an editor that can both work in a cloud workflow which enables features like instant collaborative editing, and a git-like workflow where user can work offline, then publish online, and if needed, resolve conflicts. In regards to the realtime option of overleaf, I guess that after each change of the document, it runs LaTeX to export the document to PDF. The template edition mode would do something different as first it won't be updated realtime: it is only when the user switch to the template edition mode that the template as well as the contents will rendered on screen by the editor, without doing any export to PDF. Cheers, Jonas

it might be simpler to have a ‘watch’ option for the context compiler combined with an ‘open result’. e.g. the coffeescript compiler allows for a ‘-w’ option, it will keep the compiler running in the background and start compiling the file(s) as soon as it detects any changes. i guess such feature might already exist in the rich mtx context tools environment. not sure where to look though … .F

On 7 Dec 2017, at 07:42, Jonas Baggett wrote:

...

While not an editor, but rather a language, Skribilo (http://www.nongnu.org/skribilo/) can output documents in various formats, including Context and Lout. I have worked a bit on getting better Context output from it and last tinkered with the math output about a year ago. Such a system might form the output engine on which an editor could be built. The same might be said for Pandoc, in which case perhaps one of the existing Haskell editors could be used as the basis for a specialised text processing system. For non-technical documents SiSU (http://www.jus.uio.no/lm/toc.html) offers various output formats, but again it is not an editor.

While your concept is interesting, I'm an Emacs user, and unlikely to switch to anything else.

Cheers, Roger --

Hi Roger,

Thank you for the suggestion. I was first thinking about incrementally creating a custom format that evolves as features are implemented. And for translating the custom format into a backend format, I was thinking of creating files with translations rules for each backend so that anyone can add support for a new backend or update an existing backend to add more feature or to make it compatible with a newer version of the backend, without needing to modify the editor code. A translation rule is e.g. start_section[title=, back_ground_color=] => @startsection(title -> {}, bg_color -> {}) which will convert a start section command of the document format into the same command for a backend format.

At first glance that way seems to be the easiest way for me, but Skribilo looks interesting as a fallback option, although I find its syntax to be weird, if I find out that the idea with translation rules isn't working as expected.

Cheers, Jonas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________

Hello Jonas, Jonas Baggett writes:

Thank you for the suggestion. I was first thinking about incrementally creating a custom format that evolves as features are implemented. And for translating the custom format into a backend format, I was thinking of creating files with translations rules for each backend so that anyone can add support for a new backend or update an existing backend to add more feature or to make it compatible with a newer version of the backend, without needing to modify the editor code. A translation rule is e.g. start_section[title=, back_ground_color=] => @startsection(title -> {}, bg_color -> {}) which will convert a start section command of the document format into the same command for a backend format.

Skribilo uses an abstract syntax internally and the different output engines process that into the target language. In essence each engine is the collection of rules appropriate to that target.

At first glance that way seems to be the easiest way for me, but Skribilo looks interesting as a fallback option, although I find its syntax to be weird, if I find out that the idea with translation rules isn't working as expected.

There are two input syntaxes, a simple one a bit like Emacs' outline mode and the more Scheme-like syntax. The former has limitations documented on the Skribilo web-site, the latter is far more complete. I an guessing it is the Scheme-like syntax that you find weird. I have played around a a little this week on using Wisp (http://www.draketo.de/proj/wisp/) and Readable (http://readable.sourceforge.net/) to write Skribilo in a less parenthesis rich style. Although not able to complete the work owing to time constraints, it looks acheivavble. Cheers, Roger Off topic ======== My goal would be to have an output ConTeXt (or Lout) document, with fallback to LaTeX or XML if a publisher insists. If this could be combined with Emacs org-mode to document, store and run (or compile-run) source code, then a very complete and versatile system for reproducible reasearch could be constructed.

Mentioned on their wiki at: https://wiki.lyx.org/FAQ/ImportExport On Thu, Dec 7, 2017 at 8:55 AM, William Adams wrote:

Is it not an option to use LyX, and then pandoc to convert to ConTeXt?

http://pandoc.org/

On Thu, Dec 7, 2017 at 7:42 AM, Roger Mason wrote:

...

Hello Jonas,

Jonas Baggett writes:

...

Thank you for the suggestion. I was first thinking about incrementally creating a custom format that evolves as features are implemented. And for translating the custom format into a backend format, I was thinking of creating files with translations rules for each backend so that anyone can add support for a new backend or update an existing backend to add more feature or to make it compatible with a newer version of the backend, without needing to modify the editor code. A translation rule is e.g. start_section[title=, back_ground_color=] => @startsection(title -> {}, bg_color -> {}) which will convert a start section command of the document format into the same command for a backend format.

Skribilo uses an abstract syntax internally and the different output engines process that into the target language. In essence each engine is the collection of rules appropriate to that target.

...

At first glance that way seems to be the easiest way for me, but Skribilo looks interesting as a fallback option, although I find its syntax to be weird, if I find out that the idea with translation rules isn't working as expected.

There are two input syntaxes, a simple one a bit like Emacs' outline mode and the more Scheme-like syntax. The former has limitations documented on the Skribilo web-site, the latter is far more complete. I an guessing it is the Scheme-like syntax that you find weird. I have played around a a little this week on using Wisp (http://www.draketo.de/proj/wisp/) and Readable (http://readable.sourceforge.net/) to write Skribilo in a less parenthesis rich style. Although not able to complete the work owing to time constraints, it looks acheivavble.

Cheers, Roger

Off topic ========

My goal would be to have an output ConTeXt (or Lout) document, with fallback to LaTeX or XML if a publisher insists. If this could be combined with Emacs org-mode to document, store and run (or compile-run) source code, then a very complete and versatile system for reproducible reasearch could be constructed.

____________________________________________________________ _______________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/list info/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ____________________________________________________________ _______________________

Le 03.12.17 à 18:00, Aditya Mahajan a écrit :

...

This is a blog post I recently published: https://jonas17b.wixsite.com/monsite/home/wysiwym-editor-on-top-of-context-l.... It is about some ideas I have for a WYSIWYM editor like LyX, but it would be designed for using more than 1 backend (e.g. ConTeXt, Lout), and to give a much better user experience.

I am curious if you have looked into if it is possible to add a ConTeXt backend to LyX. AFAIU, LyX saves the document in a "Lyx format" and then transforms it into LaTeX. It might be simplest to write a translator from the internal lyx format to ConTeXt and Lout.

Aditya

-- Hi Aditya, From what I have seen, the LyX format is a LaTeX file with a thin layer on top of it. So basically I would need to write a LaTeX to ConTeXt/Lout converter ;-). Looks like to me that this editor that I would like to design cannot be implemented as an incremental improvement to LyX, as it would be a too radical change. In regards to the translator, I have thought about implementing rules of translations in a text file for each supported backend. Advantage would be that it will be easy for any user to add a new backend or extend an existing one to cover new features or to fix incompatibility issues. Here is +/- how could look like rules of translations, with the left expression, something described in the document format and the right expression, the same thing described in the backend format: <func>[ = , = ]{<body>}  =>  @<func>( -> , -> ){<body>} At this point if we have in document: start_section[title = Introduction, back_ground_color = green] it will be translated to @startSection(title -> Introduction, back_ground_color -> green) but if it has instead to be translated to @startHeader(1, Introduction, bgColor -> green), we will add the following in the translation file: start_section[title = , back_ground_color = ] => @startHeader(1, , bgColor -> ) Idea is that it starts with very general translation rules and then it gets more and more detailled for every cases that don't follow the more general rules. Cheers, Jonas

On 2017-12-06, at 00:01, Jan Tosovsky wrote:

On 2017-12-02 Jonas Baggett wrote:

...

This is a blog post I recently published: https://jonas17b.wixsite.com/monsite/home/wysiwym-editor-on-top-of- context-lout. It is about some ideas I have for a WYSIWYM editor like LyX, but it would be designed for using more than 1 backend (e.g. ConTeXt, Lout), and to give a much better user experience.

Visual editing of complex structures is hard to implement. For XML based publishing there is just single serious tool! https://www.oxygenxml.com/xml_author/docbook_editor_structured_editing.html

Strange nobody mentioned Org-mode! Also, this: https://emacs.cafe/emacs/guest-post/2017/06/26/hierarchy.html (works with JSON OOTB, but most probably could be used to edit XML).

Desktop is IMHO declining so I'd personally prefer a web app, which could be then packed even for desktop via https://electronjs.org/

Desktop declining??? That's terrifying, since 99% of web apps suck a lot!

For visual editing an advanced rich text editor is a must. This one is really promising https://github.com/ianstormtaylor/slate as it can read/write custom scheme. Btw, it is used in https://github.com/GitbookIO/gitbook project. Mentioning Gitbook, it could also be a source of inspiration.

Again, Emacs (perhaps with Org-mode). Best, -- Marcin Borkowski

On 2017-12-06, at 22:03, Jan Tosovsky wrote:

On 2017-12-06 Marcin Borkowski wrote:

...

On 2017-12-06, at 00:01, Jan Tosovsky wrote:

...

On 2017-12-02 Jonas Baggett wrote:

...

This is a blog post I recently published: https://jonas17b.wixsite.com/monsite/home/wysiwym-editor-on-top-of-context-l... It is about some ideas I have for a WYSIWYM editor like LyX, but it would be designed for using more than 1 backend (e.g. ConTeXt, Lout), and to give a much better user experience.

Visual editing of complex structures is hard to implement. For XML based publishing there is just single serious tool! https://www.oxygenxml.com/xml_author/docbook_editor_structured_editing.html

Strange nobody mentioned Org-mode!

Also, this: https://emacs.cafe/emacs/guest-post/2017/06/26/hierarchy.html (works with JSON OOTB, but most probably could be used to edit XML).

I meant visual editing (WYSIWYM), see e.g. https://www.youtube.com/watch?v=-3z2sYEaLHM

Doesn't Emacs with Org-mode or hierarchy do just that? -- Marcin Borkowski