"Eli Zaretskii" writes: >> From: Oliver Scholz >> Date: Sat, 18 Sep 2004 19:08:17 +0200 >> Cc: boris@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org >> >> It works to some extend, as long as you are able to identify those >> newlines and space characters when the document is encoded again and >> written to a file. > > If those characters have a special text property (put there when the > file is decoded), then such an identification at save time is > possible. Yes, that's the technique I have been using so far. It seems to me that Richard would disagree here. [...] > I suggest to discuss that and try to identify the specific problems > that you think will cause such an approach to fail. Then we might > have a better idea of the limitations of this approach, and could talk > about solutions. Easy. Just consider the HTML document attachted below. RTF has similar features, but I chose HTML, because that is more widely known. To see where the problem is, you need a CSS capable browser on a GUI. However, I don't think we need to talk about specific solutions /now/, for this reason: > In other words, the current design might indeed have to be changed, > but I think you will agree that such changes need to be kept to a > minimum, lest we end up redesigning Emacs. Talking about specific > problems will help to come up with such a minimal set of changes. Yes, I agree. If all this is basically a question of whether a box model (in the display engine) is too much work and trouble, then in fact, I suggest to delay such decisions until basic functionality is implemented by means of space and newline characters. Then we'll see whether what's left is worth it. I am thinking about an architecture (for word processing) that should be modular enough to replace the spaces-and-newline box model with something real without trouble. Oliver