🚀 go-pugleaf

In article <TOM.92Jun25080511@amber.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) wrote:
>
> OK, I have been watching this discussion for a while, and I just have one
> question: What (other than being slightly clumsy) is wrong with using
> the existing emacs local variables mechanism, together with temporary
> highlighting to, in effect, create permanent highlighting.

Basically, because you want acceptable behavior on the degenerate case of
a multi-megabyte file with lots and lots of font changes.  To do this, you
need something more sophisticated than an alist of endpoints.

Also, markers can't be involved, because the time that insertions take
goes up linearly with the number of markers in the buffer.  (A substantial
reimplementation of markers would fix this, but would be pretty much the
same amount of work as a decent implementation of "regions" (whatever
you're calling them).  We've considered making markers be implemented as
zero-length regions because of this.)

In article <9206242107.AA01431@hugo.lucid> jla@lucid.com (Joseph Arceneaux) wrote:
> 
> The idea is that there is a fundamental distinction between buffer
> text and its properties (e.g., italics), and visual indicators such as
> highlighting selected text, or the the gdb arrow, or marker glyphs
> pointing to various buffer positions.  The text and its properties are
> persistent entities which exist after emacs has finished, while
> overlays such as highlighting are temporary indicators having more to
> do with editing operations.
> 
> This distinction is completely separate from the implementation
> mechanisms, which could be the same.

My take on the whole "properties of the text" versus "visual overlays" thing
is that yes, there is a difference, but it's not a significant enough one to
warrant a distinct implementation for the two.  Both need to have equally
good performance characteristics.

Another thing that I think is worth noting is that, as far as I know, there
aren't any word processors that actually attach "font" information to
characters.  Now I'm not exactly a word processor guru, so maybe I've just
led a sheltered life; I'm sure someone will come up with a counter-example
if this isn't true, but all the word processors I've ever seen behave as if
they use the "overlay" style of formatting while editing, and then put that
information into the file (in whatever encoding) when the file is written.
At least, this is the impression they give from their behavior.

For example: suppose there was a boldface word in the middle of otherwise
plain text.  If you moved the insertion point into the middle of that word
and typed a character, that character would be inserted in boldface in every
word processor I've seen.  The "fonts attached to characters" model would
suggest that it should be inserted in whatever the current "global" font was.
That it is inserted in bold suggests to me that there is a "bold region" in
the buffer, -not- that this particular set of characters, which just happen
to be consecutive, have the "bold" bit set on them.

	-- Jamie

PS: It's true that Zmacs attached font bits to characters, but there were
    enough silly things about the way Zmacs dealt with fonts that it really
    wasn't much of a "word processor."  It certainly wasn't WYSIWYG by any
    stretch of the imagination.