Discussion:
Musings on creating an HTML-based WYSIWYG mode
(too old to reply)
Lars Ingebrigtsen
2018-05-01 14:54:51 UTC
Permalink
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
Søren Pilgård
2018-05-01 19:00:09 UTC
Permalink
Post by 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.
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!
Lars Ingebrigtsen
2018-05-01 20:11:50 UTC
Permalink
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
Søren Pilgård
2018-05-02 08:16:58 UTC
Permalink
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
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.
Joost Kremers
2018-05-02 09:22:44 UTC
Permalink
Post by Lars Ingebrigtsen
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
Van L
2018-05-02 09:36:02 UTC
Permalink
… 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.
Stefan Monnier
2018-05-02 01:45:00 UTC
Permalink
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
So here's what I think: I think somebody (i.e., me) should try
^^
Huh? Me? No way! I think you meant you!
Post by Lars Ingebrigtsen
But like I said, I don't have time at the moment. :-)
Sounds like the ideal moment to start hacking then!


Stefan
Lars Ingebrigtsen
2018-05-02 09:50:43 UTC
Permalink
Post by Stefan Monnier
Post by Lars Ingebrigtsen
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.
Post by Stefan Monnier
Post by Lars Ingebrigtsen
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
Lars Ingebrigtsen
2018-05-02 10:43:58 UTC
Permalink
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
Yuri Khan
2018-05-02 10:49:22 UTC
Permalink
Post by Lars Ingebrigtsen
* 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.
Michael Heerdegen
2018-05-02 20:32:15 UTC
Permalink
Post by Stefan Monnier
Post by Lars Ingebrigtsen
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.

Richard Stallman
2018-05-02 03:11:08 UTC
Permalink
[[[ 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. ]]]
Post by 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.
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.
Van L
2018-05-02 03:50:58 UTC
Permalink
Post by 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. ]]]
Post by 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.
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
Loading...