Re: What improvements would be truly useful?

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: Marcin Borkowski <mbork@mbork.pl>, eggert@cs.ucla.edu,
>> rms@gnu.org, emacs-devel@gnu.org, raeburn@raeburn.org,
>> dancol@dancol.org, rostislav.svoboda@gmail.com
>> Date: Fri, 09 Mar 2018 10:56:00 +0000
>> 
>> > Are you saying that either of these is a WYSIWYG word processor?
>> 
>> No. But, then Word or LibreOffice are not WYSIWYG either.
>
> This is just a minor semantic issue: let's assume for the purposes of
> the current discussion that the definition of a WYSIWYG word processor
> is what the Office word processors do.


I think it is not. There are many different forms of word-processor out
there. Emacs is already one of them, albeit for a specialist user base.


>> Org-mode is essentially a structure first view of text. AUCTeX with
>> preview-latex is roughly the same thing. So, both of them have strong
>> aspects of modern word-processor.
>
> They both provide the final view of the document only off-line, and
> that is the crucial difference, for the purposes of this discussion.

Yes, this is most true, although the idea of the "final view" is not
quite as clear as it might be. Even for latex, the end product can be
more than one thing (PDF and HTML for example). For org-mode, whether
the text view is less final than an HTML rendering is an open question.
 

>> If Emacs were able to turn org-mode into HTML, render that HTML and
>> then make changes to the text of that HTML, then you'd have something
>> close to the modal views. Or something like preview-latex which uses
>> syntax highlighting to provide the WYS aspect but allows you to turn it
>> on and off.
>
> Emacs is capable of displaying text with different typefaces, so it
> isn't clear to me why would we need to go through a translator, such
> as Org export or LaTeX.

Oh, because of your notion of WYS. If the "final document" is supposed
to be in HTML, then having something that looks the similar, but is
never ideal.

>> How easy this would be to implement, I do not know. Emacs does not have
>> an MVC architecture -- text properties (i.e. visualization) are stored
>> directly with the contents of a buffer, so switching views is clunky or
>> difficult (see my own lentic.el for an example).
>
> Actually, MVC is exactly the Emacs architecture.  (And text properties
> are stored separately from the buffer contents.)  I wonder what kind
> of misunderstanding is at work here.

My understanding of, for indirect buffers, are that they share text and
text properties. So you cannot put a different visualisation over two
indirect buffers, if those visualisations use text properties, because
they will interfere with each other. Perhaps it would be possible to
recode indirect buffers so that this were not the case, so that only
text were shared.

Similarly, the text that you seen on screen is pretty much what is in
the buffer. You can do things like put before or after strings in text
properties. But then this will be ignored by everything other than the
visualisation -- you can't search for them, for instance, because the
user level functions operate over the text not the visualisation of it.

And, finally, while Emacs does provide notifications of change to buffer
text both before and after, they are neither guaranteed to be paired nor
consistent. Nor is it apparent to the listening function when they will
not be paired or consistent; which is unfortunate as mostly they are.

Of course, this is not to say there is no abillity to visualise the same
thing twice. You can put a buffer into two windows, with independent
mark and point, selection and so forth. But the existence of these
things is ephemeral. So, for example, when viewing a single buffer,
split the window. Now move point in one window, and then unsplit the
window. The location of mark and point in the second window has now been
lost.

So Emacs does not exactly have an MVC architecture -- it sort of has it.
I do not think, for example, it would be straight-forward to produce
something like preview-latex where you could see the inline images and
equations and latex representation simultaneously and be able to edit
either.


Phil