From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Fri, 17 Sep 2004 19:22:26 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> <86u0tyz6y9.fsf@ketchup.de.uu.net> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1095463457 25659 80.91.229.6 (17 Sep 2004 23:24:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Sep 2004 23:24:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 18 01:24:11 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 1C8S5K-0003aX-00 for ; Sat, 18 Sep 2004 01:24:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8SB4-0002pQ-UJ for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2004 19:30:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8S9W-00025N-4j for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:28:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8S9U-00024a-8l for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:28:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8S9T-00024S-LX for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:28:27 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8S3e-0007zD-MD for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:22:26 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C8S3e-0001EJ-3j; Fri, 17 Sep 2004 19:22:26 -0400 Original-To: Kai Grossjohann In-reply-to: <86u0tyz6y9.fsf@ketchup.de.uu.net> (message from Kai Grossjohann on Thu, 16 Sep 2004 15:20:14 +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:27206 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27206 That's true. Perhaps one could have a block-begin text property and a block-end text property, both attached to the gap between two characters? Text properties are attached to characters, not to gaps. I don't think this idea could make sense. Another idea is to give each box a "name", a Lisp object, which has to be eq in order for them to be the same box. It could be a list of data that defines the box characteristics. > 2. How to represent line breaks. Saying "break one long line at > display time" would work ok for display, but all the commands that > operate on lines would see just one long line there. I think this is not too much of a problem. Kim has done a great job of changing the behavior of some Emacs commands to do cua-like things. I expect that a similar method would work to change the behavior of beginning-of-line, next-line and so on. Sorry, I do not want to have to change each command to explicitly recognize lines in two different ways. Imagine that you have a feature which wraps long lines at word boundaries at display time. Imagine that this feature was configured to wrap to the window width. Now imagine that you make the window narrower. This introduces more wrapping points. But which Lisp code needs to see more newlines? Whatever code operates on lines.