Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for multi-cursor comments to the comment plugin (V1.1.0) #3543

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

MiguelRoldao
Copy link

@MiguelRoldao MiguelRoldao commented Nov 21, 2024

To add multi-cursor support I had to re-engineer the algorithm of the plug-in quite a bit. I tried to reuse as much code that was already implemented as possible to avoid introducing new bugs. I've tested some use cases and I haven't detected any problems so far.

The new algorithm has the following workings:

  1. All the selected lines are taken from all the cursors and compiled into a table.
  2. The lines table will be fed to toggleCommentSelection() which will (un)comment all of the lines, keeping indentation formatting.
  3. The cursors will be restored to their correct position.

Note: All cursor logic is now contained in comment().

I also sneakily added a comment type for the language I'm developing in my master's thesis :P (https://freest-lang.github.io/)

Copy link
Contributor

@Andriamanitra Andriamanitra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around with this a bit and everything seems to work alright even in weird edge cases like multiple cursors on the same line, selections with comments inside them etc. It's really nice that the cursor position is now updated accordingly when a line gets commented.

The only slight annoyance I found is that if the selection ends in a newline, the line immediately after the selection gets commented too. This is not how it used to work, and not how I would like it to work. To reproduce:

  1. Open a file like the one below
# some comment
print("hello")

print("world")
  1. Select the first two lines by holding shift and pressing arrow down twice.
  2. Comment selection. Before this PR you would get comments only on the first two lines, but now you get a # on the empty line too.

@@ -19,6 +19,7 @@ ft["dart"] = "// %s"
ft["dockerfile"] = "# %s"
ft["elm"] = "-- %s"
ft["fish"] = "# %s"
ft["freest"] = "-- %s"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems unrelated to the content of this PR. What's freest? Micro doesn't have built-in support for a file type called "freest". If it gets special treatment in the comment plugin it should probably have a file type (syntax file under micro/runtime/syntax/) as well. Whether or not it's popular enough to warrant built-in support could be a separate PR and discussion.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the end of a selection happens to be on the new empty line it would be commented as well.

I agree that what you commented should be the correct behavior. In the last commit I added a fix for this. I added an exception to not comment the last line of a selection, if it is an empty line.

Regarding FreeST, you're right. I removed the changes. May add full language support in another PR at some point ;)

Copy link
Contributor

@Andriamanitra Andriamanitra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest changes introduced some bugs. I opened a PR in your fork with suggested fixes that you may use if you wish.

@@ -191,7 +206,7 @@ function string.starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end

function init()
functioninit()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happened here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, I have no idea how I didn't see this.

Comment on lines 167 to 170
if cursor.CurSelection[endSel].X == 0 then
lines[cursor.CurSelection[endSel].Y] = nil
staticEnd = true
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can end up overwriting lines that were already set to true by another cursor.

Demo: https://asciinema.org/a/VB99WIg0Oo6HJAkqc4KVeHEPP

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well caught! I have merged your suggestions. It solves the bug, and didn't seem to change any other behavior.

fix bug when commenting selected lines that have and end of selection in new line + syntactic error
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants