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: Sat, 18 Sep 2004 14:14:37 +0300 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <01c49d70$Blat.v2.2.2$f7cfb860@zahav.net.il> References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> 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 1095506347 31890 80.91.229.6 (18 Sep 2004 11:19:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2004 11:19:07 +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 Sat Sep 18 13:18:49 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 1C8dEv-00084q-00 for ; Sat, 18 Sep 2004 13:18:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8dKh-0000O2-8f for ged-emacs-devel@m.gmane.org; Sat, 18 Sep 2004 07:24:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8dKb-0000Nx-El for emacs-devel@gnu.org; Sat, 18 Sep 2004 07:24:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8dKU-0000Nc-MM for emacs-devel@gnu.org; Sat, 18 Sep 2004 07:24:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8dKT-0000NS-RD for emacs-devel@gnu.org; Sat, 18 Sep 2004 07:24:33 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8dEE-0006lI-1e; Sat, 18 Sep 2004 07:18:06 -0400 Original-Received: from zaretski ([80.230.157.233]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CPC79326 (AUTH halo1); Sat, 18 Sep 2004 14:17:51 +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 Fri, 17 Sep 2004 16:34:01 +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:27222 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27222 > Cc: boris@gnu.org, emacs-devel@gnu.org, alex@emacswiki.org > From: Oliver Scholz > Date: Fri, 17 Sep 2004 16:34:01 +0200 > > > 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. > > Fine. In that case Emacs can not become a word processor. Or maybe it > already is: the first "word processor" which supports only the file > formats text/plain and text/enriched. > > That means I can stop thinking about implementing word processor > functionality for Emacs right now and go back to use it just as a > programmer's editor. It is not the application then, that I thought > it would become. > > Sorry, for having been a nuisance, then. That's a very far cry from what I intended. I didn't mean to say that the idea of having more word-processing features in Emacs was futile, much less that your messages were a nuisance. All I was saying was that Emacs design has some basic assumptions which are better left alone. It is possible that what I wrote was misunderstood to mean that there's nothing in the buffer but plain text. Others in this thread pointed out something that I assumed was known and obvious: that text properties are also part of buffer text, and that they can be used to hold the additional meta-information required for word-processing features. FWIW, I think there _is_ a way to add sophisticated word-processing capabilities to Emacs without breaking the basic Emacs design assumptions. One good idea was already suggested in this thread: when Emacs decodes a file which has embedded information about the text layout, it should convert that information into a combination of characters and text properties, such that Lisp programs and C code that look at the buffer text could extract the layout information from that text alone. In other words, convert indentation to the appropriate amount of whitespace, add newlines where line-wraps are required (and put some text properties on those added characters to be able to treat them specially, e.g. at save-file time), add text properties for paragraph-level style information, etc. If you think that this approach will not work, can you tell why?