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

[Mike Scalora]

On Thu, May 19, 2016 at 1:15 PM, Benno Schulenberg
<address@hidden> wrote:
>
> On Thu, May 19, 2016, at 19:08, Mike Scalora wrote:
>> On Thu, May 19, 2016 at 5:47 AM, Benno Schulenberg
>> <address@hidden> wrote:
>> > What is it that tiny disables that you need in order to make the
>> > comment/uncomment feature work?
>>
>> It could be done, but without being able to mark multiple lines it is
>> of marginal value and the number of additional preprocessor directives
>> to work around the missing mark and undo symbols would make a mess of
>> the implementation.
>
> Aaah.  Tiny cannot mark anything.  Okay.
>
>> When I started down that path I thought to myself,
>> "Self, when Benno sees this mess he's going hate it. I better never
>> let him see this or he's going to flush the whole feature for sure."
>
> :)
>
> But you can easily do without colors (that is: syntaxes); it will
> cost one #ifndef.

I could do that, then one can --disable-color by itself and keep
commenting with only '#'. Does anyone ever use all the possible odd
build combinations unless it is a platform/library limitation?

>> > So... I would like to be able
>> > to configure like this:
>> >
>> >   ./configure --enable-tiny --enable-comment
>>
>> It almost sounds like you have come to appreciate the feature a little
>> bit.
>
> Correct.  :)  You should see how often I do:
>
>   // <Down> // <Down> //  ^S ^X  make <Enter>
>
>> I had the impression you were barley tolerating the whole idea.
>
> Not so much the feature, but the mass of code.  I like features that
> cost ten or twenty, or maybe thirty lines to make.  Not a smothering
> *two hundred and seventy*.  :|
>
> But now that I think about it: what would be really cool is if we
> could bind this feature to a single key instead of to two: when all
> the marked lines are commented, then they are uncommented;
> otherwise, they are commented.  (Because it doesn't make sense,
> other than for decoration purposes,  to comment a bunch of lines
> when all of them are already commented.)  That would save us a
> precious key that we might want for something else.  And would
> make the key easier to remember, and easy to undo if you didn't
> want to comment or uncomment.
>
> How hard would it be to make that?  Or don't you agree that
> this is a desirable behavior?

It has pros and cons, I've used editors in my day job that work both
ways. Two keys are easier to know what will happen.

JetBrains IDEs and BBEdit on the Mac use one key, Command-/ or Ctrl-/.
JetBrains comments unless ALL of the non-empty lines are commented,
then it uncomments. BBEdit uncomments if the top line of the selection
is commented, otherwise it comments, it gets a lot of odd cases wrong.

My many years of Visual Studio 10+ years ago got me used to two keys:
Ctrl-/ and Ctrl-Shift-/. Always obvious what will happen.

We could use M-3 and M-# but I thought the idea of # being the
uncomment key was awkward. And it doesn't save a keystroke, just moves
it to a shifted keystroke which may or may not be a benefit.

A single key would take more code, the amount depending on the
heuristic. How many lines of code have the same value as an unused
keystroke? Are there existing routines to test for a string of
whitespace only?

> Benno