Musings on creating an HTML-based WYSIWYG mode

Musings on creating an HTML-based WYSIWYG mode

[Lars Ingebrigtsen]

I'm not going to implement this any time soon, but I wondering how much
work it would be to create a WYSIWYG mode for Emacs based on
round-tripping through shr.

I think most people who have approached this subject before have said
"just use some text properties and store as enriched text and there you
go", but it's just not sufficient: If you're writing a <ol> list, then
you want this to be rendered as it should be, and it should be rendered
as the recipient is likely to read the text.  Otherwise it's not very
WYSIWYG, is it?

So: The serialisation format would be HTML.  Whenever a user types
something, Emacs generates HTML, asks shr to render it, and then present
the user with the results.  This would, of course, potentially be
horrifically slow, but we could envision strategies to only re-render
parts of the buffer/document.

Let's say the user is typing away at something resembling this
paragraph, and then decides to make "typing" bold, so the user would go
back to that work, mark it and issue whatever command there is for "make
this bold".  The mode would do the change to the HTML document, ask shr
to re-render it, and then display the results.

This is, of course, not like what Emacs does normally when editing text,
and would break a lot of invariants that people are used to.  We can
preserve basic things like point and mark easily enough (by inserting
special constructs into the HTML that allows us to find and restore them
after re-generating the buffer), but I'm sure there's oodles of stuff
that will stop working with such a radical approach.  But perhaps that's
OK?

Inserting images and the like into the buffer would be unproblematic --
just add a few new dired commands like "copy image to WYSIWYG clipboard"
and then yank from that "clipboard" into the buffer.  This presents
further interesting questions about the serialisation format...  but we
could, for instance, use MIME for that: multipart/related with the
images stashed as cid: links.

"External" images are simpler, of course.

The WYSIWYG clipboard would also be necessary for when cutting and
yanking text: If you're killing text starting from the middle of a link
and ending up in the middle of an <ol> link, you have to ensure that you
end up with something similar when you yank this mess somewhere else.
And you have to ensure that everything remains valid around where you
killed the region, too.

And then there's always the interesting subject of tables, or rather:
Side-by-side continuous regions.  Making editing commands work in those
circumstances may be, er, interesting...

So here's what I think: I think somebody (i.e., me) should try
implementing this.  I think there are so many unknowns here that it's
difficult to say whether this is a workable way of doing WYSIWYG in
Emacs before you have something semi-working and get a grip on how this
would feel in practice.  

But like I said, I don't have time at the moment.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Musings on creating an HTML-based WYSIWYG mode

[Søren Pilgård]

[-- Attachment #1: Type: text/plain, Size: 4345 bytes --]

On Tue, May 1, 2018 at 4:54 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I'm not going to implement this any time soon, but I wondering how much
> work it would be to create a WYSIWYG mode for Emacs based on
> round-tripping through shr.
>
> I think most people who have approached this subject before have said
> "just use some text properties and store as enriched text and there you
> go", but it's just not sufficient: If you're writing a <ol> list, then
> you want this to be rendered as it should be, and it should be rendered
> as the recipient is likely to read the text.  Otherwise it's not very
> WYSIWYG, is it?
>
> So: The serialisation format would be HTML.  Whenever a user types
> something, Emacs generates HTML, asks shr to render it, and then present
> the user with the results.  This would, of course, potentially be
> horrifically slow, but we could envision strategies to only re-render
> parts of the buffer/document.
>
> Let's say the user is typing away at something resembling this
> paragraph, and then decides to make "typing" bold, so the user would go
> back to that work, mark it and issue whatever command there is for "make
> this bold".  The mode would do the change to the HTML document, ask shr
> to re-render it, and then display the results.
>
> This is, of course, not like what Emacs does normally when editing text,
> and would break a lot of invariants that people are used to.  We can
> preserve basic things like point and mark easily enough (by inserting
> special constructs into the HTML that allows us to find and restore them
> after re-generating the buffer), but I'm sure there's oodles of stuff
> that will stop working with such a radical approach.  But perhaps that's
> OK?
>
> Inserting images and the like into the buffer would be unproblematic --
> just add a few new dired commands like "copy image to WYSIWYG clipboard"
> and then yank from that "clipboard" into the buffer.  This presents
> further interesting questions about the serialisation format...  but we
> could, for instance, use MIME for that: multipart/related with the
> images stashed as cid: links.
>
> "External" images are simpler, of course.
>
> The WYSIWYG clipboard would also be necessary for when cutting and
> yanking text: If you're killing text starting from the middle of a link
> and ending up in the middle of an <ol> link, you have to ensure that you
> end up with something similar when you yank this mess somewhere else.
> And you have to ensure that everything remains valid around where you
> killed the region, too.
>
> And then there's always the interesting subject of tables, or rather:
> Side-by-side continuous regions.  Making editing commands work in those
> circumstances may be, er, interesting...
>
> So here's what I think: I think somebody (i.e., me) should try
> implementing this.  I think there are so many unknowns here that it's
> difficult to say whether this is a workable way of doing WYSIWYG in
> Emacs before you have something semi-working and get a grip on how this
> would feel in practice.
>
> But like I said, I don't have time at the moment.  :-)
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>
>
>
The question is if it is worth the effort?
To me the greatest benefit of a WYSIWYG editor would be if I could edit in
the "finished" website eg. sort of like editing the elements in the
developer tools of  chrome/firefox. That means CSS has to be supported, and
potentially also javascript. If a website is only HTML it is easy enough
for me to visualize how it is going to look. Besides HTML rarely stands
alone now a day, it is most likely consumed by some tool and or combined
with CSS (or something compiled to CSS) and javascript (or something
compiled to javascript). And in a lot of cases i do not edit actual HTML
but some templating system complicating the issue even further.

I personally think something like skewer where a browser is updated to
reflect the current state is a lot more useful, though I havent found a way
to make it work fluidly when doing more complex backends.

Building a WYSIWYG editor in Emacs sounds like a complicated affair and I
am not sure it is really worth it as editing plain standalone HTML is
becoming a niche thing. It could be useful for HTML emails though!

[-- Attachment #2: Type: text/html, Size: 5319 bytes --]

Re: Musings on creating an HTML-based WYSIWYG mode

[Lars Ingebrigtsen]

Søren Pilgård <fiskomaten@gmail.com> writes:

> The question is if it is worth the effort?  To me the greatest benefit
> of a WYSIWYG editor would be if I could edit in the "finished" website
> eg. sort of like editing the elements in the developer tools of
> chrome/firefox. That means CSS has to be supported, and potentially
> also javascript. If a website is only HTML it is easy enough for me to
> visualize how it is going to look.

You seem to be talking about programming a web site, not writing text?

The vast majority of text out there on the web is produced in a WYSIWYG
editor of some kind or another, for instance the JS-based editor in
Wordpress or any of a number of editors inside other CMS systems.

> Building a WYSIWYG editor in Emacs sounds like a complicated affair
> and I am not sure it is really worth it as editing plain standalone
> HTML is becoming a niche thing. It could be useful for HTML emails
> though!

Editing text for publication is far from a niche thing, and HTML is the
common serialisation format.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Musings on creating an HTML-based WYSIWYG mode

[Stefan Monnier]

> Let's say the user is typing away at something resembling this
> paragraph, and then decides to make "typing" bold, so the user would go
> back to that work, mark it and issue whatever command there is for "make
> this bold".  The mode would do the change to the HTML document, ask shr
> to re-render it, and then display the results.

Sounds OK.

> This is, of course, not like what Emacs does normally when editing text,
> and would break a lot of invariants that people are used to.

I don't think so, actually.  At least, I don't think it should be very
serious issue (and in the worst case we could do a comparison between
the old and new rendering to try and modify only the "relevant" portion
of the buffer).
IOW, nothing too worrisome.

> So here's what I think: I think somebody (i.e., me) should try
                                                  ^^
Huh?  Me?  No way!  I think you meant you!

> But like I said, I don't have time at the moment.  :-)

Sounds like the ideal moment to start hacking then!


        Stefan

Re: Musings on creating an HTML-based WYSIWYG mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm not going to implement this any time soon, but I wondering how much
  > work it would be to create a WYSIWYG mode for Emacs based on
  > round-tripping through shr.

It could be useful for editing HTML, if it works smoothly enough.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: Musings on creating an HTML-based WYSIWYG mode

[Van L]

> On 2 May 2018, at 13:11, Richard Stallman <rms@gnu.org> wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>> I'm not going to implement this any time soon, but I wondering how much
>> work it would be to create a WYSIWYG mode for Emacs based on
>> round-tripping through shr.
> 
> It could be useful for editing HTML, if it works smoothly enough.
> 

It would be useful to me to live edit HTML, save to file, publish to

	http://emacs.scratch.space

Re: Musings on creating an HTML-based WYSIWYG mode

[Søren Pilgård]

On Tue, May 1, 2018 at 10:11 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Søren Pilgård <fiskomaten@gmail.com> writes:
>
> > The question is if it is worth the effort?  To me the greatest benefit
> > of a WYSIWYG editor would be if I could edit in the "finished" website
> > eg. sort of like editing the elements in the developer tools of
> > chrome/firefox. That means CSS has to be supported, and potentially
> > also javascript. If a website is only HTML it is easy enough for me to
> > visualize how it is going to look.
>

Dont let my comments be seen as a detraction of your project.
I only tried to put words on how a WYSIWYG editor would fit in with MY
use of Emacs. There are of course many different people using Emacs in
many different ways.

> You seem to be talking about programming a web site, not writing text?

Yes, HTML is the base for quite a lot of webpages. And my guess would
be that most people writing HTML in Emacs are doing it to be published
on the web as a site or part of such.

>
> The vast majority of text out there on the web is produced in a WYSIWYG
> editor of some kind or another, for instance the JS-based editor in
> Wordpress or any of a number of editors inside other CMS systems.

I belive you are right. Most content is probably written in some CMS
system WYSIWYG editor.
My guess is in fact that most content on the web is created by people
who dont know HTML at all.
How many of these people would realisticly switch away from the build
in editor and switch to Emacs for doing this content?
Especially as the CMS might not be working with HTML at all but
potentially some other Markup langauge more friendly for focusing on
the content.
Further the CMS systems could extend the markup with custom components
useful in the system.
When you combine this with the styling/theme of the CMS it is very
hard for Emacs to present the HTML in a way that is equivalent to the
CMS system.

>
> > Building a WYSIWYG editor in Emacs sounds like a complicated affair
> > and I am not sure it is really worth it as editing plain standalone
> > HTML is becoming a niche thing. It could be useful for HTML emails
> > though!
>
> Editing text for publication is far from a niche thing, and HTML is the
> common serialisation format.
>
I do know HTML is used for classical publications. But even then the
HTML is most likely consumed by some tool that combines it with the
styling used for the final result.
Thus the HTML presented to you and the result in a book will not look
the same if the same styling is not applied. The simplest thing is how
pages are split and margins are fitted.
When writing a book/article and seing the result immediately is
needed, I think one the most essential things looked for is how it is
layed out over multiple pages.

At least these are my experiences from doing LaTeX in Emacs. I use the
execelent auctex tooling that even has the abillity to preview/show
the result inline in the buffer as it is typed.
When a formula is completed it is shown as rendered, but if you move
the point back into it you see the latex formula instead.
But even with the preview WYSIWYG features available I ended up rarely
using it, instead prefering to have a PDF reader open next to Emacs
controlled from within emacs.

Re: Musings on creating an HTML-based WYSIWYG mode

[Joost Kremers]

On Tue, May 01 2018, Lars Ingebrigtsen wrote:
> The vast majority of text out there on the web is produced in a 
> WYSIWYG
> editor of some kind or another, for instance the JS-based editor 
> in
> Wordpress or any of a number of editors inside other CMS 
> systems.

Yes... I'm running into this right now with Moodle, which has 
these text fields that don't work very well with plugins like 
"Edit with Emacs", because the underlying content is HTML. That's 
to say, it does work, but instead of the text you see the 
underlying HTML, which I don't really like to edit. If in those 
cases I could turn on your hypothetical WYSIWYG mode, that'd be 
great. :-)

-- 
Joost Kremers
Life has its moments

Re: Musings on creating an HTML-based WYSIWYG mode

[Van L]

> Joost Kremers <joostkremers@fastmail.fm> wrote:
> 
> … in those cases I could turn on your hypothetical WYSIWYG mode, that'd be great. :-)
> 

It would be nice to edit both sides of Discourse’s WYSIWYG editor in that mode on Emacs.

Re: Musings on creating an HTML-based WYSIWYG mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> This is, of course, not like what Emacs does normally when editing text,
>> and would break a lot of invariants that people are used to.
>
> I don't think so, actually.  At least, I don't think it should be very
> serious issue (and in the worst case we could do a comparison between
> the old and new rendering to try and modify only the "relevant" portion
> of the buffer).
> IOW, nothing too worrisome.

I was thinking about things, like, "what does it mean to kill a
rectangle in a buffer that's auto-reformatted"?  Do we re-render after
each "piece" that's been killed?  (Probably not.)  What about when the
user types `M-x query-replace-regexp RET ^foo RET bar'...  If we
re-render after each replacement (or not), then there might be lines
starting with "foo" after it has run, anyway (because things will be
re-flowing).

Stuff like that.

I'm not saying that these are insurmountable obstacles or anything, but
there will be these things that people are used to using that may or may
not work the same in a WYSIWYG context, and that dealing with them will
probably require just living with it a bit, thinking about each case,
and adjusting things as we go along.

>> But like I said, I don't have time at the moment.  :-)
>
> Sounds like the ideal moment to start hacking then!

:-)

I think it'll have to wait until my next holiday.  But if anybody else
wants to take a stab at it, don't wait for me.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Musings on creating an HTML-based WYSIWYG mode

[Yuri Khan]

On Wed, May 2, 2018 at 4:53 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I was thinking about things, like, "what does it mean to kill a
> rectangle in a buffer that's auto-reformatted"?  Do we re-render after
> each "piece" that's been killed?  (Probably not.)  What about when the
> user types `M-x query-replace-regexp RET ^foo RET bar'...  If we
> re-render after each replacement (or not), then there might be lines
> starting with "foo" after it has run, anyway (because things will be
> re-flowing).

You can experience these things already with current Emacs. Just generate
some lines that are longer than your window width, and enable
visual-line-mode.

* Rectangle operations break pretty horribly. That is, they behave as if no
line wrapping was in effect, acting on parts of the logical lines defined
in terms of character offset from beginning of line.

* Regular expression ^ and $ work in terms of logical lines, too.

And you know what — that is okay. When you know you have (almost) no
control over how words get laid out into lines, you stop worrying about
that and let text flow freely.

For rectangle operations, I know three use cases in plain text:
indentation, tables, and multi-column layouts. All of these have direct
HTML+CSS replacements that are better exposed as separate editing commands:
apply style; clone style; modify some aspect of the style at point.

Re: Musings on creating an HTML-based WYSIWYG mode

[Lars Ingebrigtsen]

Yuri Khan <yurivkhan@gmail.com> writes:

> You can experience these things already with current Emacs. Just generate
> some lines that are longer than your window width, and enable
> visual-line-mode.
>
> * Rectangle operations break pretty horribly. That is, they behave as if no
> line wrapping was in effect, acting on parts of the logical lines defined
> in terms of character offset from beginning of line.
>
> * Regular expression ^ and $ work in terms of logical lines, too.

Yes, it's horrible, and I never use it.  :-)  Hopefully the WYSIWYG mode
can aim higher than that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Musings on creating an HTML-based WYSIWYG mode

[Yuri Khan]

On Wed, May 2, 2018 at 5:44 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> > * Rectangle operations break pretty horribly. That is, they behave as
if no
> > line wrapping was in effect, acting on parts of the logical lines
defined
> > in terms of character offset from beginning of line.
> >
> > * Regular expression ^ and $ work in terms of logical lines, too.

> Yes, it's horrible, and I never use it.  :-)  Hopefully the WYSIWYG mode
> can aim higher than that.

Well, when/if you get to tables, rectangle operations could usefully
operate on ranges of table cells rather than character cells. ^ and $ could
mean start/end of paragraph, table cell, list item, or whichever
block-level element is around point.

Re: Musings on creating an HTML-based WYSIWYG mode

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > So here's what I think: I think somebody (i.e., me) should try
>                                                   ^^
> Huh?  Me?  No way!  I think you meant you!

Don't be afraid: he can't have meant me, since I didn't participate in
the discussion.  So he must indeed have meant you.


Michael.