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

Warn about abbreviated names #9

Open
mattboehm opened this issue Nov 18, 2013 · 7 comments
Open

Warn about abbreviated names #9

mattboehm opened this issue Nov 18, 2013 · 7 comments

Comments

@mattboehm
Copy link
Contributor

Vim lets you abbreviate commands (autocmd -> au) and options (nonumber -> nonu). This is typically considered poor form. Perhaps vim-lint should warn users when they use the shortened versions of commands/options in their viml.

@dbakker
Copy link
Owner

dbakker commented Nov 19, 2013

That's an interesting idea. Here are my thoughts:

Writing something like endfunction definitely seems a lot clearer and better form then endf, although there is some benefit to writing the short variant as well since it is faster to write which some people might prefer.

If this was to be implemented, it might also be a good idea to have some kind of VLFix command that automatically changes to the long versions of all the commands in the current file.

@mattboehm
Copy link
Contributor Author

VLFix could be very useful. One thing to consider is that programmers may have typed an incorrect abbreviation. Silently expanding it means that the programmer is more likely to see the mistake next time they see that line, it may be better to warn. Granted, this may be a rare enough occurrence to not warrant the effort.

I'll install vim-lint and poke around its source code tonight and report back here. Assuming we can agree that it'd be a good addition and the implementation wouldn't get too ugly, I'm happy to submit a PR.

@mattboehm
Copy link
Contributor Author

I see the code already includes a list of ex commands and an expand() function, so the work may be mostly done =).

@dbakker
Copy link
Owner

dbakker commented Nov 20, 2013

I see the code already includes a list of ex commands and an expand() function, so the work may be mostly done =).

Yeah it should be a pretty easy fix in vimlint.py. I believe the hardest part would be the VLFix method. I suppose it will need to call the vimlint python script, collect abbreviation related warnings and try to apply them. So it would be some work, but possible!

Since this is not a change everyone will agree with an option should be added to vimlint.py (I'm thinking PEP8 style --ignore=W1) so folks can stop this new warning if they don't fancy it.

Assuming we can agree that it'd be a good addition and the implementation wouldn't get too ugly, I'm happy to submit a PR.

I gratuitously accept your help! If you don't get around to it I'll happily take a look myself this weekend as well.

@mattboehm
Copy link
Contributor Author

Agreed that an ignore parameter would be nice.

Perhaps VLFix would not be a good idea as it kind of changes the scope of this plugin. Linters are never expected to be able to edit files. Granted you "could", but if you exported the warnings to a quickfix list, it would be really easy for a user to :cnext through them and choose which ones to fix. (Kinda off-topic but an export to quickfix would be nifty ;) )

@dbakker
Copy link
Owner

dbakker commented Nov 24, 2013

(Kinda off-topic but an export to quickfix would be nifty ;) )

Actually, syntastic has the :Errors command which can do this. :)

Just wanted to let you know that I'm currently adding a unit testing system (similar to PEP8) and I'm a little swamped at the moment with other things as well. So even though I think this is a valid issue I will have to shelf it for a while.

@mattboehm
Copy link
Contributor Author

No worries. It's not a pressing need. I'll may take a stab at it myself and meant to work on it this weekend but got caught up with other things.

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

2 participants