[Top][All Lists]

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

[Nano-devel] Comment/Uncomment feature patch

From: Mike Scalora
Subject: [Nano-devel] Comment/Uncomment feature patch
Date: Mon, 11 Apr 2016 18:38:19 -0600

I was procrastinating doing my yearly tax paperwork and started playing around with a feature idea I was pondering. I decided I should clean up the code and submit a patch, so here it is.



Feature to "comment out" or "uncomment out" a line or set of (marked) lines.

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)

Both prefix only (like '#' or '//') and bracket (like '/*' & '*/' or '<!--' & '-->') are supported.

Comments are applied to each marked line. Example (CSS)

/*.class-name {*/
/*    color: red;*/
/*    font-weight: bold;*/

I thought about adding a way to configure the comment to allow one block comment for all lines marked but have not implemented it.

No attempt is made to detect possible conflicts with existing comments. It would be possible to warn the user if a suspected conflict is detected but only in some cases and some "false positives" are inevitable.

Uncomment right after comment will almost always return the document to the prior state but uncomment by itself can be irreversible. Uncomment only uncomments like which have the complete comment syntax chosen.

Comment syntax is associated with file type, precedence is as follows:
  1. .nanorc syntax configuration if it contains new comment nanorc command, except the "default" file type is excluded at this point,
  2. an internal file name/extension regexp based lookup (case insensitive)
  3. an internal content sniffing regexp based mechanism is used (like the syntax header command but can examine more than one line [# of lines is compile time config])
  4. .nanorc "default" syntax configuration
  5. '#' line comment style is assumed

.nanorc change:

Syntax section can now have a 'comment' command like:

    syntax "_javascript_" "\.jsquot;
    comment "//"

or for bracket style comments:

    syntax "Open Financial Exchange" "\.ofxquot;
    comment "<!--|-->"

Note: comment commands are optional for syntax sections, an empty string is used to disable the feature for a file type (e.g. JSON which does not allow any kind of comments)


I originally stated with the indent/unindent implementation so much of the code based on that implementation.

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. 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. 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. I mined several sources of comment and filetype info to build the data. Some of the file types are obscure and could be thinned out but that would require a lot of subjective judgement. All of this data could be converted into .nanorc files but then would require distribution, installation and configuration to be useful. Of course it can be overridden in .nanorc configuration.

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.

I decided to use a pipe character for bracketed comments: "<!--|-->" vs "<!--" "-->" in the rc file. Separate parameters could be used but it would increase data size in a few areas for a fairly small cosmetic change. I could go either way.

The internal data (filetype.c) could be compacted quite a bit at the expense of maintainability of the data, code complexity and/or more build process. A lot of different options for this.

I have not done any user documentation work (i.e. man file updates) but would expect to take care of that once any feedback alterations are made.


toggle - many/most tools use a single command to toggle comments on/off but you have to determine what constitutes "on" and then can't 'double comment'
empty lines - currently the code comments all lines 'marked' (except 'the magic line')
last line - Some tools don't comment the last line if the cursor is at the fist char, in effect this is selecting the line-end of the previous line but no char of the bottom line, also GUI apps (at least ont he mac) don't show a cursor while selecting (just the mouse pointer I-beam) so the last line doesn't appear selected.

Attachment: comment_uncomment_0_3.patch
Description: Binary data

reply via email to

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