status.lua: Display commit and branch of repository where file is located#3673
status.lua: Display commit and branch of repository where file is located#3673dmaluka merged 2 commits intomicro-editor:masterfrom
status.lua: Display commit and branch of repository where file is located#3673Conversation
|
|
||
| function branch(b) | ||
| local function parseRevision(b, opt) | ||
| if b.Type.Kind ~= buffer.BTInfo then |
There was a problem hiding this comment.
One Addition:
In case we now compare against buffer.BTInfo shouldn't we use b.Type instead of b.Type.Kind?
Because the b.Type.Kind holds the int, but the b.Type the BufType.
There was a problem hiding this comment.
BufType.Kind is exposed to plugins with the same name as BufType constants, so b.Type.Kind has to be compared:
I do not know if the exposed values could somehow be changed without breaking API. Other exposed constant types are int but I was confused when I tried to compare with b.Type a year ago. Thinking about it now, I think a note could be added in documentation.
There was a problem hiding this comment.
Ah, I see. Thank you for this hint. 👍
Not really intuitive, but yes...right now fix in this API.
There was a problem hiding this comment.
Regarding buffer types, it would be beneficial to have access to the buffer kind parameter in the NewBuffer*() functions. Currently, you cannot directly create buffers that are not of type BTDefault, so even if you change the type, the onBufferOpen() function will always receive a BTDefault. As a result, you have to use alternative methods to differentiate between buffers.
There was a problem hiding this comment.
Sorry, I don't have enough free time at this part of the year even with other things.
Other exposed constant types are
intbut I was confused when I tried to compare withb.Typea year ago. Thinking about it now, I think a note could be added in documentation.
I plan to add a note about buffer.BT* constants and option registration (mentioned in sparques/micro-quoter#8 (comment)), but I am not good at writing documentation so someone else may still do it.
Currently, you cannot directly create buffers that are not of type
BTDefault, so even if you change the type, theonBufferOpen()function will always receive aBTDefault.
Please create another issue. I haven't honestly read your comments in other issues much, but for now I suggest to avoid long text like what I did in the description of #3578.
runtime/plugins/status/status.lua
Outdated
| @@ -1,9 +1,12 @@ | |||
| VERSION = "1.0.0" | |||
| VERSION = "1.1.0" | |||
There was a problem hiding this comment.
The version of builtin plugins does not seem to be updated and there is only a fix done in this pull request, so I don't know if this would be fine. I'll revert this sometime around this week.
There was a problem hiding this comment.
This version as such doesn't make a lot of sense for builtin plugins (they are not released separately from micro, not downloaded or installed separately from micro). So yes, I think it's better to keep this 1.0.0, just for consistency.
There was a problem hiding this comment.
What about VERSION = "builtin", which results in this particular case in status (0.0.0-builtin)?
There was a problem hiding this comment.
It's probably better to leave it as-is unless it is causing problems. It is sort of user-facing so changes could potentially break something (https://xkcd.com/1172/).
There was a problem hiding this comment.
By taking https://xkcd.com/1172/ serious we would end up in no change at all. 😉
The user is still able to override builtin plugins with local ones. Don't you think it would be nice to identify this use case?
There was a problem hiding this comment.
The user is still able to override builtin plugins with local ones. Don't you think it would be nice to identify this use case?
I'm not sure how the version number is related, surely you can do that regardless of the version number? 🤔 Or do you just mean that the text "builtin" would then not be visible in the output of micro -plugin list (assuming the user remembered to change the version number in their override)? I don't really think that matters much.
There was a problem hiding this comment.
Or do you just mean that the text "builtin" would then not be visible in the output of
micro -plugin list(assuming the user remembered to change the version number in their override)?
Yes, that's what I meant.
Assuming the user wouldn't touch a copied builtin version number leads to the situation that we can't differentiate it again.
So, ok...we keep it as is, unless anybody comes up with a better idea.
Return current commit hash and branch of repository where file in buffer is located instead of current directory.
7758da8 to
85e2b3b
Compare
The repository where the file is located could be different with the current directory, so the functions in the
statusplugin are changed to run commands in the directory of the file.