[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the justifying of indented text
Re: the justifying of indented text
Fri, 20 Dec 2019 15:09:18 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
Op 19-12-2019 om 21:57 schreef Seb:
> Bullet lists are GREAT. They work only when auto-indent is ON. So I switch it
> when I write one.
They work fine too when autoindent is OFF (as I normally have): I don't mind
having to type the extra leading whitespace. And when coming back to a file
and editing stuff in it, and then rejustifying things, I don't have to think
about whether to switch on autoindent or not before I hit ^J.
> I did write that "I *usually* don't use autoindent [...] if I'm writing a
> Two exceptions came to my mind but I thought I'd make my point more clearly
> if I
> omitted them at first. Bullet lists are one. The other one is long quotations,
> which I put in paragraphs that have a Tab offset at each line (and a second
> on the first line of each paragraph). For these, too, I need auto-indent.
You need autoindent for ease of entry, yes. But this shouldn't mean that the
user also needs to have autoindent ON in order to be able to justify things
after editing a bullet item or long quotation.
> I also use auto-indent for bullet lists and long quotations. In bullet lists,
> can't remember a time when I may have wanted to separate two paragraphs within
> one bullet point. In long quotations, it could be discussed but the fix is
> (blank line). Whereas in code such as
> I cannot leave a blank line otherwise the \noindent has no effect.
In short: When a file contains only pure text (paragraphs, bullet lists,
quotations, and such), there is no problem, nano will justify things well.
When a file contains only pure code and comments (like in a C or Python
file), there is no problem either: you will not type ^J on the code lines,
and nano is able to distinguish comments from code (through quotestr) and
will justify comments just fine.
The problem occurs when code and text are mixed. Or rather: when *markup*
(HTML) and *commands* (LaTeX, or whatever those \things are called in LaTeX)
are mixed with text without any intervening blank line. Then nano is not able
to see that <p> and \command are not plain text and should not be included into
a paragraph when justifying. (By adding < and \ to quotestr you could kind of
work around the problem, but it is bound to cause other issues.)
>>> 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.
> Well, not in the case above but if I write:
> %<Tab>Some text
> then a ^J will fuse the two lines into one, same point as before.
Of course. Because the two lines have the same indentation (after the %),
so they are a single paragraph. How can nano know that \noindent is a
command and is not part of a paragraph? Nano speaks no LaTeX, nor any
other language. And your trick with adding \ to quotestr will not work
in this case because quoting/commenting will work only with repeated
occurrences of the same leading string -- it was designed to deal with
email quoting: ">", ">>", ">>>", and so on.
>> nano should not justify things differently depending on the setting of
Because Pico does not require an option either to be able to justify
an indented piece of text, as indicated in the relevant commit:
And because one can then use M-J to justify the whole file without
having to think whether there are things somewhere in the file that
need to have autoindent ON in order to be justified correctly.
> This is an example where Nano behaves differently depending on whether
> auto-indent is on or off :-)
To be clear: nano does *not* justify things differently when autoindent
is on or off. Older nanos did, yes, but nanos since 2.9.8 don't.
I went digging into the history of the differentiation in justifying
between having autoindent ON and OFF...
The original patch that David Benbennick posted seventeen years ago
says: "4) It allows justification of indented paragraphs." And then:
There are two down sides. First, the "indented paragraphs" cannot be
turned off, so nano always thinks that two adjacent lines starting with a
tab are in the same paragraph. I should make that feature depend on the
But this doesn't explain why two adjacent lines each starting with a
tab should be considered separate paragraphs. Would it be because of:
Another short sentence.
For a human, both of the previous sentences are obviously
separate paragraphs and should stay that way?
When the patch goes into the repository two months later (see
search for "5)", without the quotes), this rule 5) has been added,
and afterward it explains:
The reason for number 5) is that if AUTOINDENT is not set, then an
indented line is expected to start a paragraph, like in books. Thus,
nano can justify an indented paragraph only if AUTOINDENT is turned on.
But this does not explain *why* the justifying of indented paragraphs
was prevented/disabled when autoindent is OFF. What purpose does this
serve? Well, one reason seems to be your use case: when text is mixed
with *indented* markup or directives, these should not be considered
to be part of any paragraph. This (or something similar) is what the
above explanation should have said.
However, the usefulness of seeing anything that is indented as the
start of a new paragraph is quite limited, because in the files that
I use that have mixed text and markup (doc/nano.1 and doc/nano.texi)
most of the markup is flush with the left edge, it has no indentation,
so even with the above rule nano will still do the wrong thing when
typing ^J on a piece of text. (If I really wanted, in modern nanos
I can first shift-select the piece of text and then type ^J, and it
will get justified correctly. But I still can't justify the whole
file in one go.)
Anyway, for your use case, I've improved the "Christmas-present"
patch: when autoindent is ON, you can also justify tab-indented
long quotations, and even tab-indented bullet lists.
Description: Text Data
Description: OpenPGP digital signature