nano-devel
[Top][All Lists]
Advanced

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

Re: the justifying of indented text


From: Benno Schulenberg
Subject: Re: the justifying of indented text
Date: Wed, 18 Dec 2019 17:43:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

Op 17-12-2019 om 23:01 schreef Seb:
>>> Each line starts with a <Tab> and there is no more text than that. When the
>>> cursor is on the second line, I expect ^J to leave the two lines alone.
>>
>> Why do you expect that?  Just because that is how Pico did it?
> 
> "Because Pico (and previous Nano versions) did it", in other words "Because
> that's been my editor's behavior for the past twenty five years", is indeed a
> reason that comes to mind. And not a trivial one, I may add.

True.  But sometimes things have to change.  Like the fixing of the bug that
underlay the bug that you reported a few days ago.  This fix will result in
a change of behavior in some edge cases, behavior that some people may have
gotten used to because nano behaved that way for more than twelve years.  It
is not going to change back, because now nano is doing the right thing.

(I'm not saying that the change in indenting behavior is the right thing,
nor implying anything on the matter.)

>> Or because you think that indented lines should never be rewrapped? Or to be
>> more precise: that an indented line can only ever be the start of a 
>> paragraph,
>> never the continuation of a paragraph?  If you opine the latter, please give
>> your reasoning.
> 
> Here is my reasoning.
> 
> * if autoindent is OFF (which in my mind means "I'm writing text"):
> 
>     Yes, an indented line can only ever be the start of a paragraph
>     because that's pretty much the definition of a paragraph in a text.

Okay.  But what about bullet lists?  If the text of a bullet point takes
more than one line, then the extra lines are indented, I suppose?  Pico,
and nanos before 2.9.8 are not able to justify these.  For example:

* First item, covering
  two lines.
* Second item, covering
  two lines too.

If you paste this into a file, and then open that file with 'pico -r18'
or with an older nano with 'nano --ignore --fill=18', then both Pico and
nano will make a mess of it when trying to justify the items: they will
destroy the bullet list.  Newer nanos will justify the items beautifully.
That is what the change in behavior in 2.9.8 was meant to achieve.

Since you're a frequent user of bulleted lists, do you appreciate this
new behavior?  Or is it of little value to you?

> * If autoindent in ON:
> 
>     Two lines sharing the same amount of space at the beginning of either
>     line belong to the same paragraph.

But...  If I understood well, autoindent being ON means you are writing
code, and in the code itself there are no paragraphs.  There are only
paragraphs in the comments.  But comments start with a certain character
sequence (described by 'quotestr'), which includes the leading whitespace.
So when comments are concerned, there isn't any indentation, in the eyes
of the justifying routine.
> * Comments follow a dual rule. Consider this example:
> 
>     %    Jusqu'en 2014, le moteur de LaTeX incluait un bug léger dans
>     % \addpenalty, du fichier ltspace.dtx (dans une TeXLive). Il était
>     % corrigé via le fichier fixltx2e.dtx, qui était appelé en \usepackage.
>     %    À partir de 2015, TeXLive a fusionné ces fichiers. Or le changement
>     % dans la définition de \addpenalty a fait que des corrigés compilaient
>     % différemment selon qu'ils étaient compilés sur une TeXLive 2014 (qui
>     % était incluse dans la Debian stable début 2017) ou sur une TeXLive
>     % 2015+ (cas d'Ubuntu et de la nouvelle Debian stable arrivée en milieu
>     % de session).
>     %    La correction de ce bug n'améliore pas les Annales en pratique. Il
>     % est plus important que la compilation soit la même partout. C'est
>     % pourquoi on met ci-dessous l'ancienne définition de \addpenalty.
> 
>     The "%" symbols need to stay vertically aligned (let's say that "%" is
>     in quotestr). Whatever happens after "%" does not count. Autoindent or
>     not.

Here you say that for comments autoindent does not matter, but in the next
paragraph you say that the justifying behavior for comments should differ
depending on whether autoindent is OFF or ON.  What am I overlooking?

>     In the comment's text, the separation into three paragraphs conveys
>     meaning and should be preserved if the user wishes so: if autoindent is
>     OFF, keep the paragraphs; if it is ON, fuse them together.

Fuse together?  But nano has never done this.  All the way back to 2.0.6
(which is the oldest version I have available), nano would justify the
paragraphs as if the "    % " things weren't there.  And I think that is
the preferrable behavior: nano should not justify things differently
depending on the setting of autoindent.

In newer nanos, if a user wants to fuse the paragraphs into a single one,
they can select the entire comment and press ^J.  (This feature, made by
David Ramsey, is available since nano-4.0.)

In the above explanations you say that any indentation (when autoindent
is OFF) should mean: start-of-new-paragraph.  But I think that is
unnecessarily limiting: it would prevent justifying bullet items.

So, to see whether seeing only a TAB as the indicator of a new paragraph
is enough to bring back your desired justifying behavior, please try the
attached patch.  It should apply with only offset and no fuzz to 4.6.

Benno

Attachment: 0001-wrapping-a-line-that-starts-with-a-TAB-always-starts.patch
Description: Text Data

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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