From: "Eli Zaretskii" <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: enriched-mode and switching major modes.
Date: Tue, 21 Sep 2004 21:53:58 +0300 [thread overview]
Message-ID: <01c4a00c$Blat.v2.2.2$800e77a0@zahav.net.il> (raw)
In-Reply-To: <867jqot0be.fsf@ketchup.de.uu.net> (message from Kai Grossjohann on Tue, 21 Sep 2004 11:53:41 +0200)
> From: Kai Grossjohann <kai@emptydomain.de>
> 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).
next prev parent reply other threads:[~2004-09-21 18:53 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 23:58 enriched-mode and switching major modes Luc Teirlinck
2004-09-05 17:25 ` Richard Stallman
2004-09-06 0:59 ` Luc Teirlinck
2004-09-06 16:42 ` Stefan
2004-09-06 16:53 ` Luc Teirlinck
2004-09-10 17:40 ` Richard Stallman
2004-09-11 2:14 ` Luc Teirlinck
2004-09-11 16:56 ` Stefan
2004-09-11 21:51 ` Luc Teirlinck
2004-09-11 22:55 ` Stefan
2004-09-12 1:46 ` Luc Teirlinck
2004-09-12 18:18 ` Stefan
2004-09-12 2:50 ` Luc Teirlinck
2004-09-13 7:00 ` Richard Stallman
2004-09-12 9:10 ` Richard Stallman
2004-09-12 16:51 ` Luc Teirlinck
2004-09-12 17:08 ` Oliver Scholz
2004-09-12 18:36 ` Kim F. Storm
2004-09-12 20:01 ` Luc Teirlinck
2004-09-13 7:32 ` Kim F. Storm
2004-09-13 23:03 ` Richard Stallman
2004-09-14 3:46 ` Luc Teirlinck
2004-09-14 12:26 ` Stefan Monnier
2004-09-14 22:12 ` Luc Teirlinck
2004-09-15 9:32 ` Richard Stallman
2004-09-17 9:36 ` Richard Stallman
2004-09-19 20:07 ` Luc Teirlinck
2004-09-06 7:36 ` Oliver Scholz
2004-09-06 19:01 ` Alex Schroeder
2004-09-10 17:40 ` Richard Stallman
2004-09-10 19:30 ` Oliver Scholz
2004-09-13 23:04 ` Richard Stallman
2004-09-14 14:41 ` Oliver Scholz
2004-09-14 16:31 ` Oliver Scholz
2004-09-15 1:39 ` Luc Teirlinck
2004-09-15 1:47 ` Luc Teirlinck
2004-09-15 8:06 ` Oliver Scholz
2004-09-15 15:42 ` Richard Stallman
2004-09-16 13:20 ` Kai Grossjohann
2004-09-17 23:22 ` Richard Stallman
2004-09-16 17:04 ` Oliver Scholz
2004-09-17 5:15 ` Eli Zaretskii
2004-09-17 14:34 ` Oliver Scholz
2004-09-17 20:43 ` Kai Grossjohann
2004-09-17 22:05 ` Kim F. Storm
2004-09-18 19:07 ` Richard Stallman
2004-09-18 15:37 ` Robert J. Chassell
2004-09-18 11:14 ` Eli Zaretskii
2004-09-18 12:04 ` David Kastrup
2004-09-18 13:32 ` Eli Zaretskii
2004-09-18 13:46 ` David Kastrup
2004-09-18 15:57 ` Eli Zaretskii
2004-09-19 17:19 ` Kai Grossjohann
2004-09-18 22:55 ` Richard Stallman
2004-09-18 17:08 ` Oliver Scholz
2004-09-18 17:48 ` Eli Zaretskii
2004-09-18 20:02 ` Oliver Scholz
2004-09-18 21:25 ` Eli Zaretskii
2004-09-18 21:54 ` Oliver Scholz
2004-09-20 0:06 ` Richard Stallman
2004-09-20 11:48 ` Oliver Scholz
2004-09-21 18:30 ` Richard Stallman
2004-09-21 19:08 ` Eli Zaretskii
2004-09-21 20:06 ` Stefan Monnier
2004-09-22 4:54 ` Eli Zaretskii
2004-09-22 18:20 ` Richard Stallman
2004-09-22 18:39 ` Eli Zaretskii
2004-09-23 16:44 ` Richard Stallman
2004-09-22 10:01 ` Oliver Scholz
2004-09-22 13:08 ` Stefan Monnier
2004-09-22 13:11 ` Stefan Monnier
2004-09-22 13:14 ` Oliver Scholz
2004-09-22 16:27 ` Stefan Monnier
2004-09-23 1:48 ` Luc Teirlinck
2004-09-23 9:29 ` Richard Stallman
2004-09-23 9:48 ` David Kastrup
2004-09-23 16:44 ` Richard Stallman
2004-09-23 11:35 ` Stefan
2004-09-23 12:46 ` David Kastrup
2004-09-23 12:59 ` Oliver Scholz
2004-09-24 12:08 ` Richard Stallman
2004-09-24 12:50 ` Stefan
2004-09-25 15:34 ` Richard Stallman
2004-09-24 10:59 ` Eli Zaretskii
2004-09-24 11:53 ` Oliver Scholz
2004-09-24 15:51 ` Oliver Scholz
2004-09-24 20:55 ` Alex Schroeder
2004-09-24 21:11 ` Oliver Scholz
2004-09-25 16:36 ` Eli Zaretskii
2004-09-22 10:35 ` Oliver Scholz
2004-09-22 18:21 ` Richard Stallman
2004-09-20 0:05 ` Richard Stallman
2004-09-18 22:11 ` Kim F. Storm
2004-09-19 3:47 ` Eli Zaretskii
2004-09-20 0:05 ` Richard Stallman
2004-09-20 11:07 ` Oliver Scholz
2004-09-20 11:55 ` Kim F. Storm
2004-09-21 18:30 ` Richard Stallman
2004-09-22 7:44 ` Kim F. Storm
2004-09-22 18:14 ` Eli Zaretskii
2004-09-22 21:53 ` Kim F. Storm
2004-09-23 4:47 ` Eli Zaretskii
2004-09-23 7:13 ` Kim F. Storm
2004-09-22 18:20 ` Richard Stallman
2004-09-22 21:58 ` Kim F. Storm
2004-09-20 12:47 ` Kai Grossjohann
2004-09-17 15:08 ` Robert J. Chassell
2004-09-18 17:34 ` Oliver Scholz
2004-09-18 23:05 ` Robert J. Chassell
2004-09-19 11:07 ` Oliver Scholz
2004-09-19 11:24 ` David Kastrup
2004-09-19 13:14 ` Robert J. Chassell
2004-09-20 5:49 ` Stefan
2004-09-20 6:17 ` David Kastrup
2004-09-20 6:26 ` Stefan
2004-09-20 11:00 ` Oliver Scholz
2004-09-20 13:24 ` Stefan Monnier
2004-09-20 14:17 ` Oliver Scholz
2004-09-20 14:55 ` Stefan Monnier
2004-09-20 19:18 ` David Kastrup
2004-09-20 19:49 ` Stefan Monnier
2004-09-20 19:37 ` Oliver Scholz
2004-09-20 20:04 ` Stefan Monnier
2004-09-21 9:07 ` Oliver Scholz
2004-09-21 14:43 ` Robert J. Chassell
2004-09-20 21:44 ` Robert J. Chassell
2004-09-17 23:22 ` Richard Stallman
2004-09-18 16:57 ` Oliver Scholz
2004-09-18 17:12 ` Oliver Scholz
2004-09-20 0:05 ` Richard Stallman
2004-09-20 11:35 ` Oliver Scholz
2004-09-20 11:47 ` Kim F. Storm
2004-09-20 13:27 ` Oliver Scholz
2004-09-20 14:23 ` Kim F. Storm
2004-09-20 19:35 ` Oliver Scholz
2004-09-20 19:35 ` Oliver Scholz
2004-09-20 20:21 ` Kim F. Storm
2004-09-21 9:07 ` Oliver Scholz
2004-09-21 11:20 ` Kim F. Storm
2004-09-22 7:11 ` Richard Stallman
2004-09-21 18:30 ` Richard Stallman
2004-09-21 20:31 ` Miles Bader
2004-09-22 3:20 ` James Clark
2004-09-23 9:30 ` Richard Stallman
2004-09-21 9:53 ` Kai Grossjohann
2004-09-21 11:32 ` Kim F. Storm
2004-09-21 18:53 ` Eli Zaretskii [this message]
2004-09-21 20:34 ` Miles Bader
2004-09-22 0:31 ` David Kastrup
2004-09-22 14:00 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='01c4a00c$Blat.v2.2.2$800e77a0@zahav.net.il' \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.