[Top][All Lists]

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

Re: [Nano-devel] Comment/Uncomment feature patch

From: Benno Schulenberg
Subject: Re: [Nano-devel] Comment/Uncomment feature patch
Date: Wed, 13 Apr 2016 11:30:49 +0200

On Tue, Apr 12, 2016, at 02:38, Mike Scalora wrote:
> Summary
> Feature to "comment out" or "uncomment out" a line or set of (marked) lines.

Hmm.  In theory I might want to use that.  But I'm not using the
indent/unindent feature either.  (Maybe because the keybinding is
akward: Shift+Alt+{, Shift+Alt+}.  Maybe because it has a bug,

> Proposed default key bindings:
>   M-3 - comment (because the 3 key is commonly where # is found on various
> keyboard layouts and is one of the most common line comment syntaxes)
>   M-4 - uncomment (because 4 is next to 3)

For mnemonics, a good choice.  But some terminal emulators (on Gnome)
use Alt+number to go to one of the tabs in that emulator.  But... there
aren't much keys left, and moving to higher numbers isn't really a solution.

> No attempt is made to detect possible conflicts with existing comments.

> Uncomment right after comment will almost always return the document to the
> prior state but uncomment by itself can be irreversible.

Then undo /must/ work for this.

> Building the 'internal' (compiled into the executable, filetype.c in the
> patch) file name and content sniffing data into the executable is probably
> the most controversial aspect of the implementation.

Yes.  :(

> It doesn't follow any
> established practice in nano but I think it makes the feature much more
> useful. It is my assumption that making use of a .nanorc file is fairly
> uncommon.

For the casual users of nano, probably yes.  But for those that use it
regularly, I can't imagine that they haven't put some things into their

> Even though I have configuration setup on several machines, I am
> often remoting into systems that are not customized. I wanted to make the
> feature smart enough to get the comment style correct most of the time
> without any configuration.

Aah.  How long before a nano with your comment/uncomment feature
(if that happens) is installed by default on those remote machines?

Wouldn't it be easier and more dependable to just scp a .nanorc across
whenever you remote into a machine?  A .nanorc filled with lines like
'extendsyntax CSS comment "/*|*/"'.

Then we wouldn't need the built-in table nor any content sniffing,
just the comment command in the syntax files and the two routines.

> It appears that indent/unindent is not undoable, neither is
> comment/uncomment. I looked into making both undoable but didn't get very
> far. I would have to spend a lot of time to deeply understand how the undo
> mechanism is designed.

It's complicated.  There was some discussion about this two years ago,
and a partial patch for the unindent case.  See

All in all, I don't like the idea of built-in comment/uncomment commands.
We've had a request for this before.  It took a while to find it again:

The alternative "solution" in the last paragraph of my response will work
for just one type of commenting.  But... if we make it possible to specify
a speller per syntax...  That would make a lot of sed scripts you would have
to copy across.  :)


-- - The professional email service

reply via email to

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