emacs-devel
[Top][All Lists]
Advanced

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

Re: enriched-mode and switching major modes.


From: Eli Zaretskii
Subject: Re: enriched-mode and switching major modes.
Date: Tue, 21 Sep 2004 21:53:58 +0300

> From: Kai Grossjohann <address@hidden>
> Date: Tue, 21 Sep 2004 11:53:41 +0200
> 
> I would expect Emacs to compute the numbers automatically, so that
> inserting an item into the middle would recompute the numbers. To me,
> this means it makes no sense to make the numbers themselves accessible
> via Lisp.

That's not a contradiction: Emacs could recompute them each time a new
item is inserted or deleted, and keep the result in the buffer.

> But Lisp should see that there is an enumerated list using
> the "1." numbering style (as opposed to "1)" or "1/", say), and Lisp
> should see that the list has three items.

If we keep the numbers in the buffer, it becomes almost trivial for a
Lisp program to see them.  That is why keeping them does make sense,
IMHO.

> I would also expect the line spacing between the items to vary
> depending on the style sheet.  That is, Lisp shouldn't see two newline
> characters after "multi-line.", but just the end of the first item.

As Kim pointed out, that depends on what the Lisp program wants to do.
In many cases, Lisp programs walk the buffer in order to decide how
the displayed text looks (or will look when it comes into the visible
portion of the buffer).  Such programs will want to see a very close
approximation of the actual display.

> Now let's talk about the newlines and spaces between "when" and "it"
> (in the first item).  Suppose you decide that you want the item
> numbers to come out bold.  Often, bold weight runs longer than medium
> weight.  This means that the indentation of the "it" line might grow a
> bit.  Does it really make sense to insert more spaces in front of "it"
> just because the user has changed the style sheet of the document to
> specify that enumerations should use bold numbers?

That's a design decision we will have to make.  Ideally, it wouild be
nice to adjust the indentation; in the specific example you've given,
the effect might be almost invisible, but I can think of similar
situations where if we don't adjust the indentation, the text will
look ugly on the screen.  (Try to use a proportional font in a C-Mode
buffer, and you will see what I mean.)

For this indentation to work, Emacs needs to support fractional
spaces.

> Additionally, depending on the exact text, making the numbers wider
> could mean that the "when" does not fit on the line anymore.  Making
> the newlines accessible via Lisp would mean that Lisp would suddenly
> see a newline in front of "when", instead of after "when".

It will see a newline with a special text property.  A Lisp program
that cares about soft newlines can use the property to find that out
and DTRT.

> Now let's talk about cursor movement.  I think that positioning point
> after "multi-line." and then hitting C-f should position point before
> "Second".  The "2." part is not meaningfully editable, as it is
> computed automatically.  The whitespace isn't meaningfully editable,
> either, since the amount depends on the stylesheet in use.

This "smart" cursor motion is not hard to implement (we already do
something similar with invisible/intangible text, don't we?): cursor
motion is part of the display engine, which already examines text
properties as part of its routine operation.  The complications you
mention pale in comparison to what Emacs will need to do after C-f to
support bidirectional editing, for example: there, C-f would sometimes
go backwards or jump over arbitrarily large sequences of characters.

> For instance, I want to be able to search
> for enumeration items containing the word "when".  (The search should
> ignore "when" occurring outside of enumerations.)

If the enumerated items have a suitable text property on them, such a
feature will not be too hard to implement, I think.

Btw, one limitation of text properties is that they cannot overlap.
So, if we base these features on text properties, we need to solve the
nesting problem somehow (or prove to ourselves that nesting is not
required).




reply via email to

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