fix: make use of the updated Universal Ctags parser

psprint commented 1 year ago

Universal Ctags has been updated with dedicated zsh parser, so one cannot use zsh language defined via regex. I've renamed it to zsh3, so that both languages can be used to generate more tags. The new zsh parser supports autoload but it doesn't support local/typeset/declare/etc., so it's good to enable them both.

Usage examples

make tags

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

vladdoster commented 1 year ago

Can you link the dedicated Zsh parser that Ctags released?

psprint commented 1 year ago

https://github.com/universal-ctags/ctags/issues/3494 https://github.com/universal-ctags/ctags/pull/3499

On Wed, 5 Apr 2023 at 17:37, vladislav doster @.***> wrote:

Can you link the dedicated Zsh parser that Ctags released?

— Reply to this email directly, view it on GitHub https://github.com/zdharma-continuum/zinit/pull/482#issuecomment-1497873043, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOE4CBASX2YVUE7DBFRFQ3W7WUVPANCNFSM6AAAAAAVQBKTX4 . You are receiving this because you authored the thread.Message ID: @.***>

-- Best regards, Sebastian Gniazdowski

vladdoster commented 1 year ago

@psprint,

I left two comments when I reviewed it.

However, I've tried to use this and think this functionality should be removed from Zinit and moved to be encapsulated in a Zsh plugin.

My thoughts:

Software Peter principle

Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product. The product's complexity grows due to developers adding new designs and altering earlier ones to reflect changes in fashion and individual taste.

Mostly, the ctags bits in Zinit are relatively isolated. However, the few lines in zinit.zsh add complexity with minimal benefit and support a niche feature. Additionally, this feature is not (AFAIK) discoverable in Zinit CLI; instead requires running a make target.

The functionality and required steps would be much better as a Zsh plugin.

Programmers sometimes make implementation choices that work but have unintended negative consequences. The most common of these mistakes are cataloged and referred to as smells in the book Refactoring by Martin Fowler. Over time, many such implementation choices degrade the software's design, making it increasingly difficult to understand.

Additionally, I've seen no issues related to this functionality raised by users leading me to believe the usage is low.

vladdoster commented 1 year ago

@pschmitt Thoughts?

This will end up as bitrot and should not be merged. See my reasoning above.

pschmitt commented 1 year ago

I agree with your take on that one @vladdoster . This should be outsourced to an annex imo.

vladdoster commented 1 year ago

@psprint,

I am closing this PR.

psprint commented 1 year ago

The browse-symbol function is still in the repo and share/zsh,.ctags too. Would the feature survive in the end? I think that such support – to open a function/var/etc. of any source supported by Ctags is useful, however it is hard to draw users into using it. If such feature would be provided by Zinit (and documented – PRs with README updates haven't been merged) it would help. However I can see the code going out, I already provide the same feature in my Angel project.

zdharma-continuum / zinit