-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fixing comment plugin not using user settings when overriding default setting #3424
Open
Neko-Box-Coder
wants to merge
4
commits into
zyedidia:master
Choose a base branch
from
Neko-Box-Coder:CommentPluginFix
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
d40a952
Updating comment plugin option and fixing comment option reset bug
Neko-Box-Coder b4920fb
Added error message when using old comment option
Neko-Box-Coder 7134d3f
Rewording error message for old comment option
Neko-Box-Coder 5dc41ce
Fixing old comment option error message being spammed
Neko-Box-Coder File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not nearly obvious why can't it be reset by a "filetype" change if we use
SetOptionNative()
(it took me some time to figure it out, for instance). We should explain it better, e.g. "Don't use SetOptionNative() to set "comment.type", otherwise "comment.type" will be marked as locally overridden and will not be updated when "filetype" changes."Or actually it seems better to:
DoSetOptionNative()
instead of setting the option directlySetOptionNative()
andDoSetOptionNative()
, so that everyone knows what is the difference between them and when to use each of them, and then we don't need this comment here....Another option would be to somehow extend
RegisterCommonOption()
to allow registering default per-filetype values of an option, not just its default global value, at init time, - so thatupdateCommentType()
would not be needed at all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmaluka
DoSetOptionNative()
seems like an internal function to me, the name of it is also quite confusing againstSetOptionNative()
as well.Would adding a function like
SetOptionPersistence(bool persistent)
which setsb.LocalSettings[option]
be enough for now?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As matter of fact, the line between internal and external functions here is pretty blurred. (Technically
DoSetOptionNative()
is external, it is already exported to plugins, although not on purpose but as a side effect of exporting it to other modules inside micro, which is a consequence of the bizarre design of micro's plugin system.)Maybe... @JoeKar what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought you can remember, after the long review road of #3343. 😉
So
SetOptionNative()
calls thenSetOptionNativeMark(option string, nativeValue interface{}, mark(Local) bool)
.The same then for consistent reason for
SetGlobalOptionNative()
->setGlobalOptionNativeMark(option string, nativeValue interface{}, mark(Modified) bool)
The word
persistent
resp.persistence
smells a bit of writing it persistent into the users configuration.BTW: Wasn't the extension with a further parameter of these functions temporary part of #3343, but rejected due to the fact a of the introduction of a further parameter?
Anyway, if fine with that adjustment, in case it helps to improve the code/interfaces. Indeed we can then drop the introduced comment in the
comment
plugin.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what @Neko-Box-Coder meant is a separate function just for toggling the option's persistence state, independently of setting the option value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And also I forgot to mention is I would like to not break back compatibility as well for
SetOptionNative()
andSetGlobalOptionNative()
.So ideally changing those 2 functions (name and parameters I guess) would be our last resort if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, these two should stay as they are, but we can rename those two called from them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, why not simply:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine to add documentation I think but it would be difficult to rename or change the function signature afterwards if we decide to use it in the plugin (which other people will follow and do the same as well if needed)
I still stand by what I said before:
Or even a step further where we make
DoSetOptionNative()
as private just likedoSetGlobalOptionNative()
. The only place it is usingDoSetOptionNative()
isinternal/action/command.go:608
after all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think
DoSetOptionNative
is a particularly bad name (but you are welcome to suggest a better one). It aligns with what it does (and what is described in the documentation I've suggested above): just sets the option for this buffer and does nothing more.Also I hope it is unlikely that any other plugin will actually want to use it. The
comment
plugin's use case is unusual in this regard.internal/action/command.go
is in a different package. Which is why we madeDoSetOptionNative()
public in the first place. Try making it private and compiling micro.