From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Patch: Syntax and Hard Newlines Date: Mon, 20 Nov 2006 08:39:16 +0100 Message-ID: <45615BA4.8000407@gmx.at> 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=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1164008708 29293 80.91.229.2 (20 Nov 2006 07:45:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2006 07:45:08 +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 08:45:06 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 1Gm3pu-0001w3-F0 for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 08:45:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gm3pu-0005Y1-2I for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 02:45:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gm3pa-0005NJ-Ny for emacs-devel@gnu.org; Mon, 20 Nov 2006 02:44:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gm3pY-0005K3-8a for emacs-devel@gnu.org; Mon, 20 Nov 2006 02:44:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gm3pX-0005JE-SU for emacs-devel@gnu.org; Mon, 20 Nov 2006 02:44:40 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1Gm3pX-0003GV-JJ for emacs-devel@gnu.org; Mon, 20 Nov 2006 02:44:39 -0500 Original-Received: (qmail invoked by alias); 20 Nov 2006 07:44:37 -0000 Original-Received: from N838P006.adsl.highway.telekom.at (EHLO [62.47.48.166]) [62.47.48.166] by mail.gmx.net (mp035) with SMTP; 20 Nov 2006 08:44:37 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: rms@gnu.org In-Reply-To: X-Y-GMX-Trusted: 0 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:62538 Archived-At: > - 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.) I probably formulated that badly: I would use longlines-mode for the source buffer and *not* for the output buffer. Hence compiler output would not contain any "broken lines" and would match the lines on the file. It would not match the lines in the source buffer though. > I am not sure that is a good idea, and do we really > care about making Longlines mode work for Lisp code? Sorry, I completely lost you here. This thread started as follows: >> As documented in the doc string of the command `use-hard-newlines', >> newlines not marked hard are internal to paragraphs. However, >> currently the syntax feature does not work well with this. For >> example, if you turn on long-lines mode with M-x longlines-mode RET in >> the *scratch* buffer, you will see the word `evaluation' in the first >> line is wrapped into the second line, but not recognized as a part of >> the comment. >> To fix this, we can let the function `forw_comment' in syntax.c skip >> the soft newlines when possible. Below is the patch. Since I never use longlines-mode I don't have any opinion on this. But if people do not "care about making Longlines mode work for Lisp code" why discuss this at all? Why reason about a syntax-table property on newlines if their only purpose is to override a syntax property of lisp mode?