Re: Patch: Syntax and Hard Newlines

[martin rudalics]

>     - 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?