Closed mierenhoop closed 10 months ago
I'm also using a customized comment function that allows for this. At the time I was the only one who expressed interest in this, which is why I didn't really push for upstream integration. It's implemented as an argument so both versions are possible. Additionally, my function inserts a space between the comment token and the text for added clarity.
The changes are minor but I'm still not sure it's worth to integrate into upstream since it is easily implemented in the local init.lua.
The one issue is if you start with a commented line and extend the selection to the line below, for example:
#foo
bar
When you toggle comment, you'll get this:
foo
ar
Toggling again gives you:
#foo
#ar
The idea of "toggle comment" is that every other time you invoke it, you should get back exactly what was there originally.
There's probably an elegant way to solve it, but I haven't found it yet.
There's probably an elegant way to solve it, but I haven't found it yet.
The elegant way is to correctly guess the users intent which is not really feasible. That's why I am using two different hotkeys for commenting. One for the default toggle and one to comment everything that is selected. Considering how rarely I use the latter this is acceptable to me. Just for comparison, vscode doesn't seem very smart about commenting either. It will often double comment lines which is even more annoying than having two different hotkeys.
The one issue is if you start with a commented line and extend the selection to the line below, for example:
#foo bar
When you toggle comment, you'll get this:
foo ar
Toggling again gives you:
#foo #ar
The idea of "toggle comment" is that every other time you invoke it, you should get back exactly what was there originally.
I can't reproduce the problem where toggling again doesn't restore the original.
Just for comparison, vscode doesn't seem very smart about commenting either. It will often double comment lines which is even more annoying than having two different hotkeys.
This patch tries to replicate VSCode's behaviour where it will double comment, it's really just a matter of taste at this point :)
I can't reproduce the problem where toggling again doesn't restore the original.
When you "toggle comment" on a line that starts with a comment, I would expect that line to be uncommented, hence my comment. I'm not belittling your solution though. I was just hoping to try and come up with something more elegant that makes a bit more intuitive sense.
Ah, thanks for clarifying.
Textadept's
toggle_comment
toggles comments for each line individually. So when someone wants to quickly comment a block of code, non-code comments will get uncommented, this behaviour feels odd (for me). The way I prefer is consistantly either commenting or uncommenting a block, this is what VSCode does. I managed to hack it into myinit.lua
config, but here is the diff for this git repo:As far as I've tested, commenting and uncommenting again will return a piece of code back to it's original state, also, there might be a better way of implementing this...