From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Tue, 21 Sep 2004 21:53:58 +0300 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <01c4a00c$Blat.v2.2.2$800e77a0@zahav.net.il> References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> <867jqot0be.fsf@ketchup.de.uu.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1095792997 21183 80.91.229.6 (21 Sep 2004 18:56:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Sep 2004 18:56:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 21 20:56:22 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C9poL-0003ch-00 for ; Tue, 21 Sep 2004 20:56:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9puH-000569-U0 for ged-emacs-devel@m.gmane.org; Tue, 21 Sep 2004 15:02:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9puB-000564-Qi for emacs-devel@gnu.org; Tue, 21 Sep 2004 15:02:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9puA-00055r-Iu for emacs-devel@gnu.org; Tue, 21 Sep 2004 15:02:23 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9puA-00055o-G4 for emacs-devel@gnu.org; Tue, 21 Sep 2004 15:02:22 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9poC-0000Zm-JE for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:56:12 -0400 Original-Received: from zaretski ([80.230.154.85]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CPY92810 (AUTH halo1); Tue, 21 Sep 2004 21:56:04 +0300 (IDT) Original-To: Kai Grossjohann X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2 In-reply-to: <867jqot0be.fsf@ketchup.de.uu.net> (message from Kai Grossjohann on Tue, 21 Sep 2004 11:53:41 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27385 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27385 > From: Kai Grossjohann > 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).