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

Options to abbreviate type names #19

Open
cgay opened this issue Oct 26, 2022 · 1 comment
Open

Options to abbreviate type names #19

cgay opened this issue Oct 26, 2022 · 1 comment

Comments

@cgay
Copy link
Member

cgay commented Oct 26, 2022

Rather than this: Class <subcommand>(<command>:command-line-parser:command-line-parser)

I would prefer this: Class <subcommand>(<command>)

In fact, I'm not sure what the current rules are. For example why does it not display Class <subcommand>:command-line-parser:command-line-parser(<command>:command-line-parser:command-line-parser)? I didn't import <subcommand> and <command> into the current module differently.

What I'm sure of is that frequently the :module:library part just makes it harder to read long parameter lists. As long as textDocument/declaration (i.e. M-.) works I can find the module and library if I need to.

@cgay
Copy link
Member Author

cgay commented Apr 22, 2024

At a minimum, we could remove :dylan:dylan from names exported from the dylan:dylan module. <boolean>:dylan:dylan becomes just <boolean>.

Also, perhaps some standardized abbreviation for when the module name and library name are the same. For example, :command-line-parser:command-line-parser could be :command-line-parser. That is, if there is no library part then it's the same as the module part.

These could be additional command-line options that are configurable in the client.

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

No branches or pull requests

1 participant