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 20:48:07 +0300 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <01c49da7$Blat.v2.2.2$cd5f7160@zahav.net.il> References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> <01c49d70$Blat.v2.2.2$f7cfb860@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 1095529858 15373 80.91.229.6 (18 Sep 2004 17:50:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2004 17:50:58 +0000 (UTC) Cc: boris@gnu.org, emacs-devel@gnu.org, alex@emacswiki.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 18 19:50:45 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 1C8jMC-0007zz-00 for ; Sat, 18 Sep 2004 19:50:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8jRz-0002iD-MO for ged-emacs-devel@m.gmane.org; Sat, 18 Sep 2004 13:56:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8jRq-0002i7-6D for emacs-devel@gnu.org; Sat, 18 Sep 2004 13:56:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8jRo-0002hv-LO for emacs-devel@gnu.org; Sat, 18 Sep 2004 13:56:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8jRo-0002hs-JV for emacs-devel@gnu.org; Sat, 18 Sep 2004 13:56:32 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8jLa-0005tF-Id; Sat, 18 Sep 2004 13:50:06 -0400 Original-Received: from zaretski (pns03-204-211.inter.net.il [80.230.204.211]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CPE09218 (AUTH halo1); Sat, 18 Sep 2004 20:49:55 +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 Sat, 18 Sep 2004 19:08:17 +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:27236 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27236 > From: Oliver Scholz > Date: Sat, 18 Sep 2004 19:08:17 +0200 > Cc: boris@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org > > It works to some extend, as long as you are able to identify those > newlines and space characters when the document is encoded again and > written to a file. If those characters have a special text property (put there when the file is decoded), then such an identification at save time is possible. > This has some limitations. David already mentioned one problem. You > are right, of course, that `next-line' & Co. would need to be changed > to DTRT on screen lines rather than what you called physical lines. > But I really think that this is the least of all problems. Kai > mentioned that cua.el provides such functionality; I counted three > other packages that implement this. That is where I think we disagree: I think that the amount of Lisp code that relies on being able to deduce lots of layout-related issues by merely looking at the buffer is HUGE. You really do NOT want to modify every Emacs command like CUA Mode did. > And then there is also the point that this approach fails for the more > complicated things: tables with different font heights, paragraphs > with background colours and borders ... I suggest to discuss that and try to identify the specific problems that you think will cause such an approach to fail. Then we might have a better idea of the limitations of this approach, and could talk about solutions. In other words, the current design might indeed have to be changed, but I think you will agree that such changes need to be kept to a minimum, lest we end up redesigning Emacs. Talking about specific problems will help to come up with such a minimal set of changes.