Hacker News Reader

Comment by zarzavat | Hacker News Reader

Go to definition and find usages only work one symbol at a time. I use both, but I still use global find/replace for groups of symbols sharing the same concept.

For example if I want to rename all “Dog” (DogModel, DogView, DogController) symbols to “Wolf”, find/replace is much better at that because it will tell me about symbols I had forgotten about.

View on HN

Jetbrains ReSharper (and Rider) is smart enough to handle these things. It’ll suggest renames across other symbols even ones that have related names

And when it fails to find all the related names, you don't know what it missed.

For that use case I think you can use treesitter[1] you can find Dog.* but only if it is a variable name, for example. Avoiding replacement inside of say literals.

[1] https://www.youtube.com/watch?v=MZPR_SC9LzE

There's no reason they have to work one symbol at a time - that's just a missing feature in your language server implementation.

Some language servers support modifying the symbols in contexts like docstrings as well.

I’ve never seen an LSP server that lets you rename “Dog” to “Wolf” where your actual class names are “Dog[A-Za-z]*”?

Do you have an example?

IntelliJ's refactor tool?

IntelliJ doesn't use LSP as far as I know.

It does usually make that kind of DogModel -> WolfModel refactoring.

Neither have I; and no, I don't - I misinterpreted what you said.

But I don't see why LSP servers shouldn't support this, still. I'm not sure if the LSP specification allows for this as of current, though.

I would actually love a regexp search-and-replace assisted by either TreeSitter or LSP.

Something that lets me say that I want to replace “Dog\(.*\)” with “Wolf\1”, but where each substitution is performed only within single “symbols” as identified by TS or LSP.

ast-grep supports regex [1] or pattern based [2] matching and replacement.

[1] https://ast-grep.github.io/guide/rule-config/atomic-rule.htm... [2] https://ast-grep.github.io/guide/rule-config/atomic-rule.htm...

I am familiar with the situation you describe, and it's a good point.

However, it does suggest that there is an opportunity for factoring "Dog" out in the code, at least by name spacing (e.g. Dog.Model).

That really depends on the context, and specific situation.

That gets to the core of the issue doesn’t it? There are two cultures: Do you prefer to refactor DogView into Dog.View, or do you prefer to refactor Dog.View into DogView.

Personally I value uniqueness/canonicalness over conciseness. I would rather have DogView because then there is one name for the symbol regardless of where I am in the codebase. If the same symbol is used with differently qualified names it is confusing - I want the least qualified name to be more descriptive than “View”.

The other culture is to lean heavily on namespaces and to not worry about uniqueness. In this case you have View and Dog.View that may be used interchangeably in different files. This is the dominant culture in Java and C#.

The second culture that you describe happens also to be how OCaml structures things in modules. It's quite a turnoff for me.

Reply on news.ycombinator.com