Re: [Nano-devel] [PATCH] Some improvements

[Liu Hao]

Benno,

Thanks for your reply. I will reshuffle these patches. But at the moment
I do not have too much time to do it. I could possibly do it tomorrow or
this weekend.

>> Highlighting of preprocessor directives are moved after everything but 
>> comments, so an entire directive is always colored, as preprocessor
>> directives do not follow the other syntactical rules.
> These are meant to highlight the names of include files.  But since you
> change the coloring of these directives below...

I know, but it does not colorize nested C++ template parameters such as
`std::vector<std::basic_string<unsigned char> >`.

>> Highlighting of preprocessor directives are moved after everything but 
>> comments, so an entire directive is always colored, as preprocessor
>> directives do not follow the other syntactical rules.
> 
> Hmmm...  It is quite a change, but I can't say that I dislike it.  In fact,
> I like it.  Anyone against making this change?
> 
> Please provide the last two changes above as a single patch.

Will do.

>> # 0003-Fix-up-c.nanorc-a-little.patch
>> 
>> This patches reverts the old font color for (FIXME|TODO|XXX). It used to be 
>> red,
> 
> ??  The highlighting of FIXME et al was added three years ago, and the
> color was never changed, it has always been just a yellow background.
>> but is omitted as defaulted now. On quite a few terminals it is grey on 
>> yellow
>> thus much harder to read.
> 
> For me, yellow is a kind of brown, and red is another kind of brown,
> which means that red on yellow is completely unreadable.  True, grey
> on yellow is not very good, but it's better than black on yellow, and
> far far better than red on yellow.  When using a dark background, using
> brightwhite on yellow makes the FIXME stand out prominently, so I would
> accept a patch that makes that change.  (Separate signed-off patch.)
> 

Probably it was I that changed it... Just couldn't remember. I work over
an SSH terminals where 'yellow' is anything but dark, in contrary to
yours... I think it is acceptable to use brightred instead of the dark red.

>> Highlighting of labels in C blots C++ (private|protected|public):, so it is 
>> removed.
> 
> Hm...  Maybe C and C++ should have separate syntaxes?

This is an option but AFAIK few editors do that.

>> # 0004-When-untabifying-lines-strip-all-leading-spaces-if-t.patch
>> 
>> When unindenting lines, nano refuses to do anything if at least one line 
>> cannot be unindented. This troublesome when adjusting code that was
>> misaligned (for example, when it was copy-n-pasted over an SSH terminal with
>> autoindent turned on). This patch makes nano unindent those lines
>> unconditionally. If there are fewer spaces than a TAB in the front of a line,
>> all of them are deleted. So if you press M-{ enough times, all lines selected
>> will have no leading spaces.
> 
> Currently, nano tries to prevent the user from destroying relative
> indentations.  But I must say that this kind of gets in the way: it
> doesn't let the user quickly equalize uneven indentations.  If the
> user unintentionally destroys some relative indentation, an undo
> will nowadays quickly restore it.  So I will accept this patch --
> if you write it in a way that doesn't make unnecessary changes.
> (Why replace while (TRUE) with for (;;)?)
> 
> Also, with your patch applied, and something is indented say three
> steps, and you type M-{ ten times, you will have to type M-U ten
> times to undo the unindents again (the first seven undo-s nothing
> will happen).  When an M-{ has zero effect, it should not add an
> undo item.

Will fix both issues.

>> # 0005-Reload-last-search-string-if-any.patch
>> 
>> With the search history option turned on, if a new file is opened and M-W is 
>> pressed, nano tries to reload the last string searched as the search string. 
>> This is not the case when you press ^W or ^\ to open the interactive search
>> or replace input box, where it will be empty and pressing Enter will cancel
>> the operation. This patch makes nano reload the last search string when asked
>> to open the search input box, following the behavior when M-W is pressed.
> I don't like it.  When I start nano and type ^W, I don't want to see
> the string that I last searched for on the prompt bar.  If I want that
> search string again (to edit it), it is one <Up> away.  If I don't want
> to edit it, I can just use M-W.  So I don't see the advantage of putting
> up the last search string also for the first ^W.  (If it were up to me,
> it would be removed from all invocations of ^W.)

This is merely for consistency. If ^W is pressed the last search string
is not reloaded, but when M-W is pressed it is, which is consistent
behavior. If you would like the opposite behavior - do not fill the last
string in in such a way that pressing M-W will open the prompt bar
because of absence of a search string, it is acceptable too.


-- 
Best regards,
LH_Mouse