emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: Syntax and Hard Newlines


From: Richard Stallman
Subject: Re: Patch: Syntax and Hard Newlines
Date: Sun, 19 Nov 2006 20:37:38 -0500

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]