From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Patch: Syntax and Hard Newlines Date: Mon, 20 Nov 2006 11:13:37 +0100 Message-ID: <85psbi77e6.fsf@lola.goethe.zz> References: <455F19FC.6@gmx.at> <87wt5svkz1.fsf@catnip.gol.com> <45603BEB.6050006@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1164017705 22932 80.91.229.2 (20 Nov 2006 10:15:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2006 10:15:05 +0000 (UTC) Cc: martin rudalics , herberteuler@hotmail.com, miles@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 20 11:14:59 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 1Gm6At-0005bA-Cb for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 11:14:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gm6As-0008G2-Cy for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 05:14:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gm6A9-0007xH-2W for emacs-devel@gnu.org; Mon, 20 Nov 2006 05:14:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gm6A6-0007vQ-AV for emacs-devel@gnu.org; Mon, 20 Nov 2006 05:14:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gm6A5-0007ur-RI for emacs-devel@gnu.org; Mon, 20 Nov 2006 05:14:01 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gm6A5-0003AE-E7 for emacs-devel@gnu.org; Mon, 20 Nov 2006 05:14:01 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Gm69x-0007pH-AB; Mon, 20 Nov 2006 05:13:53 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 948E41C4D3DE; Mon, 20 Nov 2006 11:13:37 +0100 (CET) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun\, 19 Nov 2006 20\:37\:38 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) 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:62551 Archived-At: Richard Stallman writes: > 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.) People use longlines-mode in connection with TeX source code (however ill-conceived that may be since TeX has a hard line length limit, nowadays set at something like 32k), and I would suspect that they'd also use it for things like groff and HTML source, all of which might be processed by systems giving out line numbers (and hopefully column numbers for long lines...) for their errors. > - 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". Yes, this might be the ticket. > I am not sure that is a good idea, For some modes, probably. > 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. window-dependent overlays would do the trick, or a display text property could use (when... However, I see in (info "(elisp) Other Display Specs.") You can make any display specification conditional. To do that, package it in another list of the form `(when CONDITION . SPEC)'. Then the specification SPEC applies only when CONDITION evaluates to a non-`nil' value. During the evaluation, `object' is bound to the string or buffer having the conditional `display' property. `position' and `buffer-position' are bound to the position within `object' and the buffer position where the `display' property was found, respectively. Both positions can be different when `object' is a string. Since object is bound to a buffer, not a window, this would not help. Given that text properties are supposed to be a feature of the text, not the window, I can understand that. > 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. Well, there is linemove.el or something like that IIRC that alleviates some of the navigation problems. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum