fossil support

[gour]

Hello,

I installed promptline along with lightline in order to replace powerline-shell, but I do miss Fossil support which would do same/similar as powerline-shell, iow.

Shows some important details about the git/svn/hg/fossil branch:

• Displays the current branch which changes background color when the branch is dirty
• A '+' appears when untracked files are present
• When the local branch differs from the remote, the difference in number of commits is shown along with '⇡' or '⇣' indicating whether a git push or pull is pending

What do you think about it?

[edkolev]

Sure, it can be easily added. I'll do some research on it (I've never used fossil before) and add support for it.

Do you happen to know some big project which uses fossil? I would like to test this on a real world big project.

[gour]

Sure, it can be easily added. I'll do some research on it (I've never used fossil before) and add support for it.

Great!!

Do you happen to know some big project which uses fossil? I would like to test this on a real world big project.

Fossil itself, then SQLite and Tcl/Tk.

[edkolev]

Basic support for the name of the branch is now added. You can use it like so (just like svn and hg, by default fossil branch is not enabled):

let g:promptline_preset = {
        \'a' : [ promptline#slices#host() ],
        \'b' : [ promptline#slices#user() ],
        \'c' : [ promptline#slices#cwd() ],
        \'y' : [ promptline#slices#vcs_branch({'fossil': 1}) ],
        \'warn' : [ promptline#slices#last_exit_code() ]}

and regenerate the .promptline.sh file. Let me know if you run into any issues :)

[gour]

and regenerate the .promptline.sh file. Let me know if you run into any issues :)

I did everything as you said, but I do not see branch name in my prompt. :-(
After, hostname and username I see '⋯'.
Let me say that I use fish shell.
I also wonder if you plan to add support for changing prompt's color based on the branch's status like it's available in powerline?

[edkolev]

Could you share what fossil branch is reporting?

Regarding the features - I'm planning to add support for repository state (if it has untracked files), count of commits ahead/behind and maybe some other stuff that can be extracted from fossil. Changing the color, however, will not be added

[gour]

Could you share what fossil branch is reporting?

• trunk

Regarding the features - I'm planning to add support for repository state (if it has untracked files), count of commits ahead/behind and maybe some other stuff that can be extracted from fossil.

Great.

Changing the color however will not be added

Any reason why not? Too costly?

[gour]

Could you share what fossil branch is reporting?

I apologize...didn't notice that the trunk name is displayed far right - I use terminal fullscreen on big display, but now put branch name on the left. :-)

[edkolev]

If you don't like the branch name on the right - you can move promptline#slices#vcs_branch({'fossil': 1}) to the left by setting it in one of a/b/c.

Regarding the color: separation of concerns - that's how this project has been designed. For example, the prompt has slices which can give useful information (git branch, working directory, etc), but they (the slices) do nothing else. The prompt has a theme which gives some color codes and does nothing else. The prompt has sections (left or right) which call the slices and wrap them in colors (and powerline symbols).

So in order to change the color of some slice, the slice needs to be capable of deciding whether the color should be A or B. I would rather avoid this as this would give the "slice" more that one responsibility (content and color).

In short, it's most probably possible, but such change would lead to a smellier software design.

[gour]

If you don't like the branch name on the right - you can move promptline#slices#vcs_branch({'fossil': 1}) to the left by setting it in one of a/b/c.

I already did that and everything is on the left now.

Regarding the color: separation of concerns - that's how this project has been designed. For example, the prompt has slices which can give useful information (git branch, working directory, etc), but they (the slices) do nothing else.

OK.

So in order to change the color of some slice, the slice needs to be capable of deciding whether the color should be A or B. I would rather avoid this as this would give the "slice" more that one responsibility (content and color).

Well, I do not fully agree...in this case 'color' is just an info holding piece of 'content' about branch's status. How is it different than displaying name of the branch which can be one of many?

Similarly, there is slice carrying the information about last_exit code from the shell. How is having warning displayed, when e.g. exit=127, is different than 'warning' the user that the branch's status is dirty - uncommited/new files etc.?

[edkolev]

OK, I see your point. However, implementing alternating colors wouldn't be a simple task, because I've coded this with the assumption that colors will not be changed based on the content.

Regarding the fossil prompt, I'm planning to add something like the git prompt https://github.com/edkolev/promptline.vim/blob/master/autoload/promptline/slices/git_status.sh
In case you already have something like this for fossil - PRs are more than welcome!

[pdf]

@edkolev the multi-colour feature would be useful. For the vcs slice, as well as others. I want to make the username change colour when root, for example. Can we work out a sane way to handle this generically?

I probably would have gone for a dictionary to store this stuff in the first place, then you could use:

" current syntax, only supports fg/bg
'a': [231, 32]
" dict syntax, supports arbitrary values
'a': { 'fg': 231, 'bg': 32, 'attrs': ['bold', 'blinking'], 'sliceSpecificColour': 220, 'otherSliceColour': 148 }

Would be a breaking change now, but it might be worth it, with a major version bump.

[edkolev]

For configuration, something like this could be used:

{
        \'a'    : [233, 27],
        \'a.alternative'    : [27,233],
        ...
}

Configuration is not my major concern though. It's implementation.

Now, slices do this:

• return 1 (non-zero actually), which means the slice is empty. For example, when we're not in a git tree, the slice returns 1 as early as possible

  promptline.vim/autoload/promptline/slices/git_status.sh

  Line 2 in 91a33e2

  [[ $(git rev-parse --is-inside-work-tree 2>/dev/null) == true ]] || return 1

• return 0, which means the slice is not empty. Plus, the slice function must print some text, which will be put on the prompt.

To allow using some other colors, the slice functions must be able to return more data, something which would mean "don't use the standard color, use the alternative color".

Unfortunately, shell functions are not very well suited to return multiple variables. These options come to mind:

• return-ing 255 (or some other magic number) would mean "the slice is not empty + use the alternative color". I don't like much this approach, because in unix, non-zero means error.
• the slice can print to STDERR; if the slice function prints to STDERR, then the alternative color will be used; if the slice prints to STDOUT, the normal color will be used
• the slice can export a variable USE_ALT_COLOR before returning

Honestly, I don't like either of these approaches, but at the moment I can't think of a better way how a slice function can say "hey, use the alternative color now, because the user is root".

I may try to prototype some of these approaches just to verify this will work. Hopefully, a better approach may come to my mind.

[pdf]

These options all seem to assume a single alternate colour, but something like VCS status might be multi-state.

[tysonclugg]

@edkolev Another option for alternate slice colors would be to setup file descriptor 3 as a pipe, allowing an explicit line of communication for which color scheme should be employed:

[[ $(git rev-parse --is-inside-work-tree 2>/dev/null) == true ]] && echo "alternative" >&3 || return 1

A small aside: This project is great, are you still using it? The last commit was a while ago...

[edkolev]

A small aside: This project is great, are you still using it? The last commit was a while ago...

I'm still using it, although a bit differently. Regarding adding new features - I'm not doing so actively. I guess the primary reason is that I've switched to emacs for coding, which doesn't mean I don't use vim anymore (I do use it daily!), but the result is that I have less motivation to code in VimL, now that I have become more used to Elisp.