Currently, the prompt command used by glit must still include a lot of extra code if the user wants to properly support color outside of git repositories. In other words, when outside of a git repository, Glitter's format expressions could still be used to format the entire PS1.

Usage could be something like:

glit <FORMAT> [-e|--else <ELSE_FORMAT>]

Where else format is rendered with empty git stats.

This would allow the entire prompt command to be something like:

export FMT = "'## '#g;*(\b)#r(\B(#~('...')))\[#g;*(\+(#~('ahead ')))]\[#r;*(\-(#~('behind ')))]\(#g(\M\A\R\D)#r(\m\a\u\d))\{#m;*;_(\h('@'))}':'#y;*('\w')'\n\$'"
export ELSE = "#g(#*('\u')'@\h')':'#b;*('\w')'\$'"

__set_prompt() {
    local EXIT="$?"
  # Capture last command exit flag first

  # Clear out prompt
  PS1=""

  # If the last command didn't exit 0, display the exit code
  [ "$EXIT" -ne "0" ] && PS1+="$red$EXIT$nc "

  # identify debian chroot, if one exists
  if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    PS1+="${debian_chroot:+($(cat /etc/debian_chroot))}"
  fi

  PS1+="$(glit "$FMT" -e "$ELSE")"
}

This requires a couple changes though, notably backslashes need to be handled such that they can appear inside of literals, and the \\ macro, which is already kind of broken, should be removed.

This would likely also improve the performance of the prompt command enough to consistently complete in less than 0.030s.

Problem

When entering the sub-directory of a git repository, Glitter no longer finds the git repository.

Example

Solution

Instead of grabbing a repository using git2::Repository::open, use git2::Repository::discover to search parent directories for git repositories.

Writing all of the extra \ can be tedious when the set of possible git statuses is essentially closed. As such, it is possible to represent all of them with a single letter. This could make it easier to read Glitter expressions.

Reserve the \ for differentiating expressions which do more complicated things: for example, an expression which separates every node in the tree with a comma and a space:

\,(+('ahead ')-('behind ')) could output ahead 1, behind 1 when both exist.

Glitter seems to take about 20 milliseconds on average to complete execution on my computer; for a smooth experience, it needs to be at least faster than 15 milliseconds every time.

I would like to profile Glitter in-depth and understand which parts take the most time to execute:

• command-line argument parsing
• parsing
• interpreting

If any text colored with Glitter is on the last line of the shell prompt, text wrapping for the terminal seems broken, and the text wraps before the end of the line and overwrites the shell prompt.

I suspect this bug originates from the ansi_term crate, since the issue disappears when no formatted text appears on a line.

Gnome Shell

hyper

Quick Fix

If the shell prompt has unformatted text at the end of a line, then this behaviour does not appear.

At the end of a format, simply add '\n'before the end, or do not use any format macros; for example, instead of:

#g(#*('\u')'@\h')':'#b;*('\w')'\$ '

Add a \n before the end of the format:

#g(#*('\u')'@\h')':'#b;*('\w')'\n\$ '
                               ^^-------- notice \n

Or simply don't use color at all:

'\u@\h:\w\$ '

The test disp_parse_idempotent is a misuse of terminology; it's actually a variant-invariant test.

I have used glitter in MacOSX before, it works as expected on Ubuntu which is my main development platform.

• get access to MacOSX to build glitter
• clarify in documentation that MacOSX is supported and test existing BASH prompt command
• Add to homebrew

Background

The gist expression grammar is a little inflexible as it currently stands. I'd like to improve the way I handle format arguments and expression trees.

Currently, style is handled using a single macro \c('color args', \g('expressions')), but this becomes very unwieldy, difficult to read, and isn't very ergonomic.

Future

Instead, I will create a new set of expressions which start with #, which are format expressions. These expressions take arguments in the form of an expression tree in parentheses, and all text rendered by those expressions is formatted, respecting the formatting of any nested format parameters, to allow for things such as making sub-sections of an expression bolded to stand out.

I intend to support the following set of expressions:

(...): Expressions to format

With the ability to combine multiple, separated by semicolons.

What remains are the named macros for inserting information about git, along with a couple for inserting illegal characters.

Title: "A git repository status pretty-printer, for displaying information about your repository in your shell prompt", could be better as "A pretty bash prompt that shows the git repository status for the current directory"

Bash only? Should be explicit with notes for Zsh and Windows/Powershell even if they are not supported.

git status -sb uses R to signify that a file has been renamed. The git2 API has a bitflag that should specify if something was renamed, but instead when a file is renamed, the bitflag for the status entry says it was added and deleted, increasing the added and deleted count but never the renamed count. This means that glitter never uses the \R flag.

It would be nice to autogenerate a man page which not only shows all of the help information but also includes detailed information on how to write glitter formats. That way, typing man glit can be a substitute for coming to the README on this repo.

However, it is unclear at this time how much work is required to generate a man page and how many of the things mentioned here are actually publicly useable:

• cli working group's tracking issue
• ripgrep's man file generation
• previous work on generating man pages

Features I would like include:

• include help information generated from structop
• additional documentation for glitter formats
  • test all example formats in the man page against glitter

Currently, if we wanted to prepend text or the results of macros to other ones, we need a group if we have more than one.

\B(\g(\+\-))

It would be more internally consistent to support groups of expressions without the explicit group marker:

\B(\+\-)

Generating random ASTs makes up a pretty significant section of the code in the AST module, and it does not allow the type of control generally desired in property testing. The proptest crate has examples of generating the AST of JSON objects that I could easily adapt into a set of combinators for generating Glitter ASTs.

This eliminates the abuse of rand to do what I need, and allows me to have much more sophisticated error checking.

Glitter uses prop test to do "fuzz" style testing, but cargo fuzz can probably do better since it can generate coverage guided test input.

• Fuzz the parser (replace prop tests)
• Fuzz the interpreter

As a follow up, it might be nice to figure out how to test the actual libgit2 side of glitter.

Rather than typing \M\A\U\D and \m\a\r\d, add shortcuts as \w and \i for working tree and staging index respectively.

For example, if I wanted to deliniate different aspects of my format with spaces so that I could have:

branch@origin/branch M1?2 {@1}

If there are no changes to the index or the working tree, then two spaces would appear between the branch information and the stash information:

branch@origin/branch  {@1}

Or if I wanted to separate the working tree from the staging index with a bar and the ahead/behind information with a comma like so:

branch@origin/branch ahead 1, behind 2 [M1|R2]

There is currently no way supported by glitter to do so. Thus, I could explore adding a new expression type specifically for this purpose which uses the write_queue in the interpreter to queue separator characters to be written only when the expression which follows outputs anything and thus drains the queue.

I recommend supporting the following limited set of separator characters:

• ","
• "|"
• " "

They could be written in the format exactly like so:

#y(#g*('~')'/C/u/glitter') [#c(#*(b)B(#~('@'{+(#g('↿')), -(#r('⇃'))})))] {{#g(MARD)|#r(maud)}} \(\h(#m('@')))'\n''➟'' '

Because the separators need special knowledge about items being written both before and after they appear, they would need to handled in the tree level interpreter function.

The line wrap issue was solved by manually patching ansi-term and adding my own fork (#24) to the Cargo.toml; however, this is not a good long-term solution and actually introduces unexpected and undesired behaviour in some cases:

The added escapes are only properly interpreted when the string is part of PS1, and otherwise (on Gnome Shell at least) they are printed as unrecognized Unicode.

As can be seen in the example, it is simultaneously correct in the shell prompt and wrong in the normal terminal output.

As pointed out in #30, the exact use case and supported platforms of glit are unclear. By coincidence, I have confirmed today that glit will likely work on windows powershell as is, but needs updated documentation to reflect this.

Status:

• glit builds successfully on windows
• glit color supports work
• write a working prompt command
• ensure single-line prompts work and do not require extra escapes
• add glit.exe to 0.2.0 release page