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: Mon, 20 Sep 2004 21:35:55 +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 1095709014 27225 80.91.229.6 (20 Sep 2004 19:36:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Sep 2004 19:36:54 +0000 (UTC) Cc: boris@gnu.org, alex@emacswiki.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 20 21:36:43 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 1C9Txr-0002lg-00 for ; Mon, 20 Sep 2004 21:36:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9U3k-0003Mo-6W for ged-emacs-devel@m.gmane.org; Mon, 20 Sep 2004 15:42:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9U3b-0003L9-7q for emacs-devel@gnu.org; Mon, 20 Sep 2004 15:42:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9U3Z-0003KJ-Lv for emacs-devel@gnu.org; Mon, 20 Sep 2004 15:42:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9U3Z-0003KG-Ia for emacs-devel@gnu.org; Mon, 20 Sep 2004 15:42:37 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1C9Tx8-0006bM-5u for emacs-devel@gnu.org; Mon, 20 Sep 2004 15:35:58 -0400 Original-Received: (qmail 7243 invoked by uid 65534); 20 Sep 2004 19:35:57 -0000 Original-Received: from dsl-082-083-129-246.arcor-ip.net (EHLO USER-2MOEN8BWBA.gmx.de) (82.83.129.246) by mail.gmx.net (mp013) with SMTP; 20 Sep 2004 21:35:57 +0200 X-Authenticated: #1497658 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Mon, 20 Sep 2004 16:23:04 +0200") 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:27340 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27340 storm@cua.dk (Kim F. Storm) writes: > Some of the existing hook properties may also be used to handle > "delete hard newline betwee paragraphs with different categories" in > some sensible way. > > If nothing else, such hooks could set some global value which causes a > post-command-hook to fix whatever conflicts are created by the last > modification -- at least I think that would be more efficient that > relying on jit-lock to run "all the time". I agree that it would work. But why is it better than the solution that I listed as #2, i.e. letting a special fill-function handle all whitespace formatting issues? I have experimented with this and it works nicely. It can also handle the problem of putting whitespace of a specific height before and after a paragraph rather elegantly. The way I see it we first create two different semantics for paragraphs: one via the `category' property, one via hard new lines. And then we take special pain to keep both representations in sync. To me this seems like asking for trouble. The only benefit I can see, is that `forward-paragraph' and its like would DTRT. But writing a version that works correctly for the other solution and binding it to the appropriate keys is rather trivial. ...! Oh, no! I see now, this is a way to make a slightly modified `fill-paragraph' work. Some of my major concerns could be adressed this way and /technically/ it could be handled by a minor mode. (Though I don't see what good that should be. How a paragraph should be indented in an RTF document depends on its properties, not on paragraph-indent-text-mode nor on paragraph-indent-minor-mode.) It could be a way to provide a user interface for RTF where I can type four spaces to indent a paragraph like in text mode. I don't like the resulting user interface. I don't like it at all. In fact I find it really, really horrible. Would it be possible to handle XML with its tree-like structure this way? My own thoughts have let into an entirely different direction (not explained in this thread); offhand I don't see how nested block boxes would be possible with hard newline semantics. Oliver -- Oliver Scholz Jour des Récompenses de l'Année 212 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M.