help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: refill paragraph but visually (like visual-line-mode)?


From: Garreau, Alexandre
Subject: Re: refill paragraph but visually (like visual-line-mode)?
Date: Wed, 17 Oct 2018 22:53:40 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu)

On 2018-10-17 at 19:00, Eli Zaretskii wrote:
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Wed, 17 Oct 2018 12:54:42 +0200
>> > One potential obstacle to negotiate is that, unlike the existing
>> > indentation functions, which traverse the buffer in order to find
>> > out the indentation of surrounding lines, the display code cannot
>> > easily do that, because the display routines are expected to be
>> > able to be called with a buffer position from which to start
>> > display, and be able to lay out a single screen line without
>> > knowing anything about the neighboring lines.  Some algorithm is
>> > needed to calculate the right indentation in those cases.
>> 
>> I was only thinking about some sort of adaptive-wrap-prefix-mode that
>> would use indentation of the first line as adaptive-prefix-wrap already
>> does.
>
> As I tried to explain above, this kind of algorithm is usually a
> non-starter in the display engine.

Maybe I misexplained what I meant: keep the code as now, don’t re-fill
the lines, don’t display indentation without storing it somewhere, just
support too-long lines.  So “first line” (of paragraph) should begins
after the last “;” for instance, or anything that is indeed a newline in
the file (that should exist).

I wasn’t speaking about indenting everything without even a newline.

So I’m *not* proposing to refill, wrap and indent something such as
" inst;if (expr) inst;\ninst;inst;" to, without changing to-be-saved
content, display as "  inst;\n  if (expr)\n    inst;\n  inst;".

I’m proposing to wrap and indent (without refilling) something such as

#+BEGIN_SRC c
  inst(that, should, be, wrapped); inst;
  if ((long) expression(that, should, also, be, wrapped))
    other(very, very, verylong, instruction);
  inst(verylong, verylong, instruction);
#+END_SRC

be *wrapped* like (given very low `fill-column', so to better give an
example):

#+BEGIN_SRC c
  inst(that, should, 
       be, wrapped); inst;
  if ((long) 
      expression(that, 
                 should, 
                 also, 
                 be, 
                 wrapped))
    other(very, very, 
          verylong, 
          instruction);
  inst(verylong, verylong, 
       instruction);
#+END_SRC
 
There is still a newline in file being hardcoded, plus an hardcoded
indentation following it: couldn’t it be used for indenting?

It could even stay partially wrong by just taking the same indentation
as it should just after the first line, so it would give:

#+BEGIN_SRC c
  inst(that, should, 
       be, wrapped);
  if ((long) 
      expression(that, 
      should, 
      also, 
      be, 
      wrapped))
    other(very, very, 
          verylong, 
          instruction);
  inst(verylong, verylong, 
       instruction);
#+END_SRC

Hence in “most of cases” it would be okay.  The important is not to
“break” indentation by wrapping so that the wraped portion of text will
“cut” the indented block.  More radically, even the following would be
more acceptable than the default:

#+BEGIN_SRC c
  inst(that, should, 
  be, wrapped);
  if ((long) 
  expression(that, 
  should, 
  also, 
  be, 
  wrapped))
    other(very, very, 
    verylong, 
    instruction);
  inst(verylong, verylong, 
  instruction);
#+END_SRC

And I tried: turns out it *already works out of the box* by just
enabling adaptive-wrap-prefix-mode.  So my initial question is more than
half-answered now.

Because it is still better as the (current default):

#+BEGIN_SRC c
  inst(that, should,
be, wrapped);
  if ((long) 
expression(that, 
should, also, be, 
wrapped))
    other(very, very, 
verylong,
instruction);
  inst(verylong,
verylong,
instruction);
#+END_SRC

…where indentation becomes pretty useless only because someone used long
lines.

Okay with the standard 72 columns that’s going to never happens, but
just in case it happens, it is *really* nice to get it work by default.
Now I realize I mostly regret for adaptive-wrap-prefix-mode not to be
the default for wrapping (what drawbacks does it have?).

> No need to submit patches for something visual-fill-column-mode
> already does well enough.

So what where you talking about patches?

PS: sorry for lengthiness but I hope this is all because of examples and
that they are fast to get a glance at.



reply via email to

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