From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Fri, 10 Sep 2004 21:30:13 +0200 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1094846324 15867 80.91.224.253 (10 Sep 2004 19:58:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 10 Sep 2004 19:58:44 +0000 (UTC) Cc: boris@gnu.org, emacs-devel@gnu.org, Alex Schroeder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 10 21:58:18 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 1C5rXG-0000s8-00 for ; Fri, 10 Sep 2004 21:58:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C5rce-0001L2-BZ for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2004 16:03:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C5rbb-0000wc-BJ for emacs-devel@gnu.org; Fri, 10 Sep 2004 16:02:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C5rbY-0000uy-UB for emacs-devel@gnu.org; Fri, 10 Sep 2004 16:02:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C5rbY-0000u5-N5 for emacs-devel@gnu.org; Fri, 10 Sep 2004 16:02:44 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1C5rW3-000567-6s for emacs-devel@gnu.org; Fri, 10 Sep 2004 15:57:04 -0400 Original-Received: (qmail 5714 invoked by uid 65534); 10 Sep 2004 19:30:21 -0000 Original-Received: from dsl-082-082-144-109.arcor-ip.net (EHLO USER-2MOEN8BWBA.gmx.de) (82.82.144.109) by mail.gmx.net (mp014) with SMTP; 10 Sep 2004 21:30:21 +0200 X-Authenticated: #1497658 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri, 10 Sep 2004 13:40:47 -0400") X-Attribution: os X-Face: "HgH2sgK|bfH$; PiOJI6|qUCf.ve<51_Od(%ynHr?=>znn#~#oS>",F%B8&\vus),2AsPYb -n>PgddtGEn}s7kH?7kH{P_~vu?]OvVN^qD(L)>G^gDCl(U9n{:d>'DkilN!_K"eNzjrtI4Ya6; Td% IZGMbJ{lawG+'J>QXPZD&TwWU@^~A}f^zAb[Ru;CT(UA]c& User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt) 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:26985 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26985 Richard Stallman writes: > True, the current implementation allows future derivatives of > text-mode -- such as a major mode to write movie scripts -- to add > persistent colors to the text. > > It also allows existing simple variants of text mode, such as > paragraph-indent-text-mode, to work with enriched mode. But for things like this, enriched-mode-the-minor-mode should /not/ affect anything but encoding/decoding. It should leave everything else to the major mode. > But how often is this power used? > > Enriched mode is not used much, now. Part of the reason is that we > don't have code to save in the formats users really use, and part is > that we have not implemented enough of the display formatting features > that people want in a word processor. This is an unfinished feature. Indeed, I believe that in the long run Emacs' display engine should support a real block model. These two belong together, IMO. It is very difficult to make Emacs support formats that people really use in a WP-style way. Word processors assign properties to paragraphs, including defaults for character styles (like the font, the weight etc.); and they support style sheets for that. It is very, very hairy to keep paragraphs, their properties and their representation in an Emacs buffer in sync, not to talk about style sheets. In fact I do think that getting a WP UI right in Emacs is currently impossible. (However, I start to think that some 60%-70% solution could be feasible. But I have not explored that yet.) Interesting coincidence, btw: I lately had a discussion via e-mail with somebody who stumbled over a prototype RTF reader of mine on the web. He asked me to make enriched-mode support RTF as a format. I told him that this is not possible for the reasons above; even an incomplete, possibly fragile, partial solution would require a major mode. It turned out that that person would be satisfied with something which I call "bad RTF", that specifies font, font height, font weight etc. everywhere explicitely; i.e. indeed something like text/enriched but with a file format that is supported by more programs. This, however, could not really be called "word processing". Personally, I am not interested in such things and I think it is very wrong. I do think that enriched-mode as a minor mode is a dead end. If it would restricted itself to just affecting visiting and saving, it would be nice to have (I disagree with Alex Schröder here). But this is not how WP in Emacs could be like. WP in Emacs should be based on a major mode that handels every aspect of editing and representing and that would support different file formats (RTF, HTML, TEI XML, Docbook, maybe Texinfo) as a target. And most importantly that major mode would be responsible for providing an user interface to a block model -- either a real one supported by the display engine, or a fake one based on some half-obscure hackery. > But does the lack of usage really make a difference here? > > And > at what cost does this power come? > > I don't see the point here. What do you think the cost is? > At present, what we see a bug. I admit that the bug is not > trivial to fix, but I don't see that the "power" of enriched > mode has a "cost" in some inherent sense. > > Even if we wanted this power, > wouldn't it be better if such modes could just add some defun to a > hook or two that would automatically do the right thing: Automatically > encode and decode text properties upon saving and reading files. > Without all the other features of enriched mode which are rarely > useful in this case, such as the the treatment of newlines or the > keybindings. > > I am not really sure what feature you have in mind. > It might be a useful feature, but it would not replace > the existing feature of Enriched mode. I think that Alex talks about writing new major modes that also use text/enriched as a file format. I think that this feature is already there. We have `after-insert-file-functions' and `write-region-annotate-functions' (or `format-alist') and we have `enriched-encode' and `enriched-decode'. Oliver -- Oliver Scholz 25 Fructidor an 212 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M.