emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs as a word processor


From: Arthur Miller
Subject: Re: Emacs as a word processor
Date: Wed, 23 Dec 2020 11:18:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

yarnton--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You could probably implement all these functions with a minimal layer on top 
> of
> org-mode, as it does support a lot of functionality already.
Org is another markup language, org is little higher than say md or rtf
or xml/html which are other markup languages, but it would be much more
work then "minimal layer". It is just half-wysiwyg. It is not
impossible, but is not that minimal either.

> IMHO, since Emacs is mostly plain text oriented it is going to be hard to go
> beyond supporting what Org already offers.
What would be a problem there? Probably every text manipulation program
has some kind of plain text storage in it's backend somewhere; be it an
array as in Emacs or some linked structure.

Emacs has Lisp which has lists which lets you build arbitrary structures.

It is trivial to implement hierarchical structures like DOM tree or a
scene graph in Lisp since n-ary trees can be easily created with
lists. Likewise key-value properties like CSS properties are also easily
represented with lists; I guess that is what Emacs text properties
already are.

One could use buffer just as a memory storage and index into it, so
"plain text" is really not a problem. And by the way, it is not so plain
anymore, is utf8, so big part of the work is already done (encoding/decoding).

The only problem I see is Emacs renderer. It just needs a little bit
more flexibility so it can render stuff in layers, on top of each other,
so we could for example render some nice rectangle for a page,  markers where
text on paper starts, ends etc. Also a pixel aligned dragging of objects
with mouse might be useful to have in a wysiwyg application, but is not 
necessary.

I think print view could already be implemented by simply rendering
buffer to svg image and displaying it in another buffer.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]