From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Patch: Syntax and Hard Newlines Date: Sun, 19 Nov 2006 20:37:38 -0500 Message-ID: References: <455F19FC.6@gmx.at> <87wt5svkz1.fsf@catnip.gol.com> <45603BEB.6050006@gmx.at> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1163986677 15496 80.91.229.2 (20 Nov 2006 01:37:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2006 01:37:57 +0000 (UTC) Cc: herberteuler@hotmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 20 02:37:54 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gly6b-00008U-W8 for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 02:37:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gly6b-0001El-Hf for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 20:37:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gly6O-0001Cc-4f for emacs-devel@gnu.org; Sun, 19 Nov 2006 20:37:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gly6N-0001CM-Nh for emacs-devel@gnu.org; Sun, 19 Nov 2006 20:37:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gly6N-0001CF-EW for emacs-devel@gnu.org; Sun, 19 Nov 2006 20:37:39 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gly6N-0001bT-Gt for emacs-devel@gnu.org; Sun, 19 Nov 2006 20:37:39 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Gly6M-0000jW-1L; Sun, 19 Nov 2006 20:37:38 -0500 Original-To: martin rudalics In-reply-to: <45603BEB.6050006@gmx.at> (message from martin rudalics on Sun, 19 Nov 2006 12:11:39 +0100) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62520 Archived-At: First, I note that in this message you're talking about user-level behavor. Your previous message, which Miles responded to, proposed an implementation, and his response was about that implementation, not the user-level issues. These are two different (though closely related) topics. So let's look at the user-level issues you've raised, and how they relate to implementation. - longlines-mode substitutes newlines for spaces. This means that any function based on scan_newline (like `goto-line') may get me results that are inconsistent with those of tools analyzing the file my buffer visits. How can I treat compiler or grep output with longlines-mode? That is true, but I suspect it is not a problem since the broken lines of compiler output normally won't match the templates for error messages. (And I am not sure it makes sense to use longlines mode in such buffers.) - Matching against the regexp "." may get me different results for the same buffer with longlines-mode disabled and enabled. Ignore that? That is true. Whether it is good or bad, I am not sure. It depends on what the program or the user is trying to achieve. - longlines-mode may wrap a regexp like "[ \t]*" at the space character. How can I evaluate a wrapped regexp like that? The only way to avoid that consequence would be to switch from "soft newlines" to "power spaces". I am not sure that is a good idea, and do we really care about making Longlines mode work for Lisp code? - How can I avoid that longlines-mode wraps a Lisp or Perl expression at a space preceding a left paren (with the left paren ending up at bol and messing up `beginning-of-defun-raw' and thus font-locking)? Likewise. - How can I avoid that longlines-mode wraps a C string and `c-font-lock-invalid-string' complains? Do we really care about making Longlines mode work for C code? - I put an arbitrary text property on a space character. longlines-mode wraps the line at that character. How can I restore that property when turning off longlines-mode? Longlines mode should preserve other text properties when it converts a space to a soft newline and vise versa. - I use two windows of different widths to simultaneously show one and the same buffer. How can I adapt longlines-mode to wrap at the right borders of my windows? It is impossible for anything like Longlines mode to do that. That would require a feature implemented entirely within redisplay. There would be no fundamental difficulty in implementing such a feature inside Emacs redisplay, but it would have to be implemented entirely in C. It would be a variant of the current feature of line continuation, and it would share the big inconvenience of line continuation: all editing commands treat the line that has been continued as one single line.