Re: Patch: Syntax and Hard Newlines

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> 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