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: Fri, 17 Sep 2004 08:15:21 +0300 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> 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 1095398286 27674 80.91.229.6 (17 Sep 2004 05:18:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Sep 2004 05:18:06 +0000 (UTC) Cc: boris@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 17 07:17:47 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 1C8B7z-0004KB-00 for ; Fri, 17 Sep 2004 07:17:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8BDh-0001EH-3A for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2004 01:23:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8BDZ-0001E4-5n for emacs-devel@gnu.org; Fri, 17 Sep 2004 01:23:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8BDX-0001Dn-U0 for emacs-devel@gnu.org; Fri, 17 Sep 2004 01:23:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8BDX-0001Dd-OR for emacs-devel@gnu.org; Fri, 17 Sep 2004 01:23:31 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8B7M-000622-6M; Fri, 17 Sep 2004 01:17:08 -0400 Original-Received: from zaretski ([80.230.149.163]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id COW98380 (AUTH halo1); Fri, 17 Sep 2004 08:17:02 +0300 (IDT) Original-To: Oliver Scholz X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2 In-reply-to: (message from Oliver Scholz on Thu, 16 Sep 2004 19:04:53 +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:27181 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27181 > From: Oliver Scholz > Date: Thu, 16 Sep 2004 19:04:53 +0200 > Cc: boris@gnu.org, emacs-devel@gnu.org, alex@emacswiki.org > > 2) the data structure used to represent that abstract document > internally Note that in Emacs, that data structure is the buffer text (with associated text properties and any Lisp code that those properties evaluate). This is very important thing to understand: there are no data structures built by Emacs from the text it reads except what it puts into the buffer. > > The idea of Emacs is that the appearance is represented by text in the > > buffer. We designed text properties so that the text in th ebuffer > > could be something more than a sequence of characters. > > > > Any extensions have to preserve this principle, or we will lose > > the benefits of Emacs. > > I obviously disagree, since I argued for an enhancement that goes > well beyond this principle. I fail too see at all how we would lose > the benefits of Emacs this way. I think Richard refers to the fact that your suggestions are so incompatible with the design principles and the current workings of the Emacs display engine that implementing them would mean working against the Emacs design. The solutions you propose for the problems raised by Richard (how to deal with line breaks and indentation from Lisp) already show a potential to require changes in too many parts of Emacs, including in lots of Lisp code. That is already an evidence that trying to display too many things that are not in the buffer is a path we should avoid. > > 3. How to represent indentation. If the indentation appears only > > in redisplay, Lisp code that looks at the text will think it is not > > indented at all. > > I actually regard this as a feature. In WP documents the left margin > has no more significance than the right margin, which is not currently > implemented by adding space characters, either. That's not what Richard was thinking and talking about, AFAIU. One example of where the indentation _does_ matter, even in a word processor, is when the mouse pointer hovers above a displayed portion of text: you need to be able to compute the buffer character position which is displayed below the mouse pointer. If the code that computes that doesn't know about indentation, you will never get that right. This breaks the mouse-highlight feature and the tooltips, for starters. > > This model fails to address those problems. It would work as a way > > of grafting a separate word processing facility into Emacs, but it > > would not integrate well with the existing Emacs Lisp world. > > I don't understand why you say that. And I don't know which parts of > the existing Lisp world you mean. The parts that do their work by walking the buffer text and making decisions on how that text is displayed. > > However, later you talk about an implementation more like what I have > > in mind, where the boxes and lists would be rendered by changing the > > buffer text; therefore, the buffer text would show what's really > > there. > > Erm, what does the concept of "what's really there" in that context > mean? What's really there in the buffer.