On Wed, Apr 13, 2016 at 3:30 AM, Benno Schulenberg <
address@hidden> wrote:
>
>
> 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,
> see
https://savannah.gnu.org/bugs/?47684.)
>
> > 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.
I left it at M-3 and M-4 but maybe M-3 & M-# would be better.
> > 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.
Done. I used a name that is not comment specific (undo_group) for a new struct because I plan on extending it to support undo for indent/unindent.
> > 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. :(
2> - from other reply -
2>(There seem to be two main comment styles: hash and slashslash.
2>You could default to hash, detect whether it has to be slashslash
2>instead, and leave all the others to be set by the syntax files.)
OK, this new patch only tries to detect "//" "#" and "<!--|-->" style comments.
The xml/html are important because I beleive nano is used a lot to shh into
servers and tweak both HTML and XML. (<90 bytes) By explicitly detecting
"#" the default syntax comment setting remains useful for settings at a cost
of only a few 100 bytes.
> > 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
> ~/.nanorc.
>
> > 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?
I'm a very patient man.
>
> 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.
Content sniffing is also useful in two scenarios where nanorc/syntax sometimes fails, yet-to-named files and unknown file extensions.
> > 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
>
https://lists.gnu.org/archive/html/nano-devel/2014-10/msg00045.html.
I'm planning to work on this next. If I understand it correctly, I don't like the approach in the patch referenced. One action should be undoable in one
invocation of undo.
> 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:
>
>
https://lists.gnu.org/archive/html/help-nano/2015-10/msg00004.html>
https://lists.gnu.org/archive/html/help-nano/2015-11/msg00000.html>
> 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. :)
An aside:
A while back I tried to setup a "formatter" and I couldn't figure out how to invoke it. When I read the following part of "help" I assumed the 2nd and 3rd lines are unbound features, not a continuation of the first line. Perhaps indenting and using a lowercase "i" would make the 2nd & 3rd lines more understandable.
^T (F12) Invoke the spell checker, if available
Invoke the linter, if available
Invoke formatter, if available
The nanorc man page has some hints but if you are looking for how to bind or invoke the "formatter" it doesn't help that much. I think something like this would have helped me "get it".
^T (F12) Invoke the spell checker, if available,
otherwise invoke the linter, if available,
otherwise invoke formatter, if available
Maybe I'm just too assuming or "over thinking it", it wouldn't be the first time.
> Benno
>
> --
>
http://www.fastmail.com - The professional email service
>
I added a undo stack dumper that runs when you invoke the stats command (only in debug builds of course). How do you feel about leaving that in the source? I could just apply it from a patch as needed but it might be useful to have around. Is there a better way/place to attach invokable logging?
I have not yet worked on the man page/help content yet. I will once all the issues that affect it are resolved/agreed upon.
comment_with_undo_less_internal_data_4.patch