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

Make @comment.outer span multiline comment #133

Open
dlukes opened this issue Oct 29, 2021 · 8 comments
Open

Make @comment.outer span multiline comment #133

dlukes opened this issue Oct 29, 2021 · 8 comments
Labels
enhancement New feature or request

Comments

@dlukes
Copy link

dlukes commented Oct 29, 2021

Is your feature request related to a problem? Please describe.
Code comments are usually hard-wrapped, so I use gw / gq to reflow long multiline comments when editing them. Unfortunately, when these are not separated by an empty line from preceding and following code, then the ip (inner paragraph) text object includes that as well, so gwip / gqip reflows even the code (which is unwanted and very probably wrong). So you have to resort to first visually selecting the comment and then gw / gq.

Describe the solution you'd like
I'd love to use treesitter + @comment.outer to invoke gw / gq over the appropriate range of text. However, @comment.outer currently doesn't span multiline comments, it only extends to the current line. Would it be realistic to redefine it, so that e.g. gwac (if ac is configured as the @comment.outer text object) reflows the entire multiline comment?

Describe alternatives you've considered
If redefining @comment.outer is doable but not desirable for backwards compatibility reasons, then maybe a new textobject could be provided, something like @multiline_comment.outer?

Additional context
I'm specifically interesting in Python, but once a solution exists for one language, it should be fairly easy to extend it to other ones with similar syntax?

@dlukes dlukes added the enhancement New feature or request label Oct 29, 2021
@eddiebergman
Copy link

eddiebergman commented Dec 21, 2021

Bump for feature request, would help a lot with long doc strings that need to be copied elsewhere.

For python, I have a solution I use for folding, however it runs into an issue #154

@liaden
Copy link

liaden commented Feb 17, 2022

Given a comment like this:

# Reverses the contents of a String or IO object. (1)
#
# @param [String, #read] contents the contents to reverse (3)
# @return [String] the contents reversed lexically (4)
def reverse(contents)
end

For @mutline_comment.inner:

  • Cursor on line 3 or 4 selects both lines
  • Cursor on line 2 selects line 2
  • Cursor on line 1 selects only line 1

For @multine_comment.outer:

  • Everything is selected.

For @comment.outer:

  • Select entire comment for line cursor is on, including the comment character.

For @comment.inner:

  • Selects only the commented text for the given line.

That said, there is some stuff like ruby's =begin and =end that create multline comments but have no special marker per line like C's /* and */ markers. I think the semantics still make sense but with some overlap.

All said, I don't know that @comment.inner and @comment.outer are still useful since we can already operate on a line reasonably easily already with f# and F# which is useful even when there is code on a line with a comment.

@ok-nick
Copy link

ok-nick commented Sep 13, 2022

This would be very useful, has anyone tried it?

@ok-nick
Copy link

ok-nick commented Nov 28, 2022

I did some research into an implementation for this and came across a shortcoming; most parsers don't support nodes for the content of a comment. It's not possible to detect whether or not a comment is empty.

Luckily, all languages have the capability of a comment content node, they just need to be implemented. For the languages that do support it, we have a few options of how to go about it:

What @liaden suggested:

  • I'm not a huge fan of this design, I feel that it introduces some redundancy. Do you ever really need to select a single comment rather than its whole chain? I know the primary reason for this is for backward compatibility, but maybe @comment.outer should be deprecated, or perhaps extended?

Add @comment_content.outer, @comment_content.inner, @comment.outer, and @comment.inner:

  • @comment_content deals with the contents of a comment (excluding prefix). The inner will select a chain of comments until an empty one, while the outer will select until the end of the comment chain. The normal @comment will replicate that behavior, but include comment prefixes.

Add @comment_block.outer, @comment_block.inner, @comment.outer, and @comment.inner:

  • @comment_block will select a chain of comments until a blank one. The outer includes whitespace, while the inner excludes it. The normal @comment deals with the entire chain of comments whilst replicating the behavior mentioned above.

To preserve backwards compatibility, the @comment tag could be deprecated and the suggested tag names could be changed to something more specific.

@wilsonchen719
Copy link

Hi,
Just recently joined the Neovim community and found this useful plugins.
Want to echo the point that if one comment.outer only support single line, wouldn't be sufficient?

@sassanh
Copy link

sassanh commented Apr 26, 2024

@wilsonchen719 Latest nightly version of Neovim has builtin support for comment objects, the mapping for this text object is gc, so you can do dgc for example to delete the comment block.
The mapping for the comment/uncomment action is also gc, so you can gcgc to uncomment a comment block.
It was announced here
And documented here

@wilsonchen719
Copy link

Hi @sassanh ,
Thanks for the info! Just try it out but seems not working with Python. It seems to be a language-specific issue that deleting comment block not working

@sassanh
Copy link

sassanh commented May 1, 2024

@wilsonchen719 Maybe tree-sitter parser for Python is not installed, you can install it with :TSInstall python. It's working for Python for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants