You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think a distinction can be made between a "prompt theme" and a "prompt theme engine" (from here on shortened to PTE).
In the far past, users would always manually customize their PS1s. Eventually, some had the brilliant idea to make it more complicated, and then to share that creation with others, @nojhan included. Themes, by definition, are opinionated, and are not for everyone. Usually that meant a user would find the theme that fit them best, but eventually this lead to customization preferences in themes, and eventually the framework to drop in a theme over top of the theme, and which point the base theme was not really a theme anymore, but a true PTE.
There are a number of problems with this current state, which I will define in a section below.
But to answer the question, a PTE exists to interface between the terminal and the running theme, and to expose contextual data for the theme to use.
The problems with current PTEs
These problems are mostly universal, Liquid Prompt included.
Due to PTEs starting as simply a theme, there are still a lot of embedded opinions, leaving customization lacking.
Every PTE needs to handle the data gathering from scratch. This leaves many PTEs with subpar data quality.
Similarly, many PTEs lack data types or terminal integration features that a user might want.
Software developers that are good at writing a theme are usually not also good at writing good, performant data gathering code.
A PTE is often written for one or two shells, leaving other users out of luck.
The future / the solution
A universal PTE
To solve these problems, I am envisioning a future with one PTE. This "universal" PTE would handle all of the terminal and contextual data problems for themes, and let theme creators just worry about the theme part. It would have zero opinions about what the prompt looks like. And it would be lightning fast.
Problems to solve
There are obviously a lot of issues to figure out first, or this probably would have been done already. Here is what I am stuck on yet:
What things should be configured in a PTE vs in the theme?
Some things are somewhat obvious. A specific feature (say, Git integration) should probably be enabled/disabled at the PTE level. But some things are not obvious. What mark to display for a Git branch depends on where a theme puts it, and under what conditions it will show it. Should a threshold for Git data be configured at the PTE? What if the logic for the threshold is in the hands of the theme? So if you leave it up to the theme to define, what if every theme defines the same logic, but slightly differently, leaving people confused?
Most PTEs available today lean very heavily toward putting everything in the PTE. Liquid Prompt, Starship, and Oh My Posh are all the most like a true PTE (in my opinion), and yet all have very centralized configs. They all make it difficult for a theme to completely change everything about how a prompt is displayed. (For example, I tried to recreate Liquid Prompt's default theme in Starship, and was only able to get about 75% of the way there.)
How to handle theme customization?
One of the most often requested features in Liquid Prompt is custom functions for overriding a specific part of the theme. Any PTE worth anything should have a way for a user to extend a theme to customize parts of it, but to reuse the parts they do not want to change.
Ideally this could extend to distributed themes, that could depend on a different theme to extend it.
How to handle theme distribution?
I would like the install process for popular themes to remain the same. Which likely rules out "install , then run pte install my-theme.
How to handle data gathering?
Clearly the PTE does the actually data gathering. But the question of "when" and "who controls it" is much harder. If we gather data when the theme wants it (like most current PTEs do), we miss out on possible speedups from parallelization. But if we gather ALL data in parallel right away, we risk gathering more data than the theme will actually need, which could perform worse. Ideally we could predict what data the theme will ask for, and gather it early to have it ready.
How to support plugins?
Another one of the most requested features in Liquid Prompt is plugin support for custom data sources. Ideally the universal PTE supports all data types, but since that likely is not possible, supporting at least a rudimentary plugin system would allow for themes or users to use data that is not so standard.
Can data truly be unopinionated?
The problem with current PTEs is that they are too opinionated about what the prompt will look like. But is it possible to provide structured data to themes without being opinionated at all? If not, I don't see such a universal PTE ever becoming popular.
Prior art
Clearly anything I reason about will be influenced by Liquid Prompt. But this has also been greatly inspired by Starship and Powerlevel10k's gitstatus
Work so far
This has been mostly nothing but a dream of mine for a few years, and a more concrete idea for the past year. I created MOST (stands for Multi-shell Open-source Scriptable Terminal Prompt Engine) about 6 months ago as PoC (and also as a way to learn more Rust), and have not touched it since. It is very rough, and not at all ready for use yet. I think more thought and design needs to go into it before I can continue, which is why I am posting this.
Its biggest features are:
A daemon, which results in the fastest prompt generation I have ever seen.
Embedded scripting engine, which gives total control over execution to the theme.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Current state
What is a Prompt Theme Engine?
I think a distinction can be made between a "prompt theme" and a "prompt theme engine" (from here on shortened to PTE).
In the far past, users would always manually customize their
PS1
s. Eventually, some had the brilliant idea to make it more complicated, and then to share that creation with others, @nojhan included. Themes, by definition, are opinionated, and are not for everyone. Usually that meant a user would find the theme that fit them best, but eventually this lead to customization preferences in themes, and eventually the framework to drop in a theme over top of the theme, and which point the base theme was not really a theme anymore, but a true PTE.There are a number of problems with this current state, which I will define in a section below.
But to answer the question, a PTE exists to interface between the terminal and the running theme, and to expose contextual data for the theme to use.
The problems with current PTEs
These problems are mostly universal, Liquid Prompt included.
The future / the solution
A universal PTE
To solve these problems, I am envisioning a future with one PTE. This "universal" PTE would handle all of the terminal and contextual data problems for themes, and let theme creators just worry about the theme part. It would have zero opinions about what the prompt looks like. And it would be lightning fast.
Problems to solve
There are obviously a lot of issues to figure out first, or this probably would have been done already. Here is what I am stuck on yet:
What things should be configured in a PTE vs in the theme?
Some things are somewhat obvious. A specific feature (say, Git integration) should probably be enabled/disabled at the PTE level. But some things are not obvious. What mark to display for a Git branch depends on where a theme puts it, and under what conditions it will show it. Should a threshold for Git data be configured at the PTE? What if the logic for the threshold is in the hands of the theme? So if you leave it up to the theme to define, what if every theme defines the same logic, but slightly differently, leaving people confused?
Most PTEs available today lean very heavily toward putting everything in the PTE. Liquid Prompt, Starship, and Oh My Posh are all the most like a true PTE (in my opinion), and yet all have very centralized configs. They all make it difficult for a theme to completely change everything about how a prompt is displayed. (For example, I tried to recreate Liquid Prompt's default theme in Starship, and was only able to get about 75% of the way there.)
How to handle theme customization?
One of the most often requested features in Liquid Prompt is custom functions for overriding a specific part of the theme. Any PTE worth anything should have a way for a user to extend a theme to customize parts of it, but to reuse the parts they do not want to change.
Ideally this could extend to distributed themes, that could depend on a different theme to extend it.
How to handle theme distribution?
I would like the install process for popular themes to remain the same. Which likely rules out "install , then run
pte install my-theme
.How to handle data gathering?
Clearly the PTE does the actually data gathering. But the question of "when" and "who controls it" is much harder. If we gather data when the theme wants it (like most current PTEs do), we miss out on possible speedups from parallelization. But if we gather ALL data in parallel right away, we risk gathering more data than the theme will actually need, which could perform worse. Ideally we could predict what data the theme will ask for, and gather it early to have it ready.
How to support plugins?
Another one of the most requested features in Liquid Prompt is plugin support for custom data sources. Ideally the universal PTE supports all data types, but since that likely is not possible, supporting at least a rudimentary plugin system would allow for themes or users to use data that is not so standard.
Can data truly be unopinionated?
The problem with current PTEs is that they are too opinionated about what the prompt will look like. But is it possible to provide structured data to themes without being opinionated at all? If not, I don't see such a universal PTE ever becoming popular.
Prior art
Clearly anything I reason about will be influenced by Liquid Prompt. But this has also been greatly inspired by Starship and Powerlevel10k's gitstatus
Work so far
This has been mostly nothing but a dream of mine for a few years, and a more concrete idea for the past year. I created MOST (stands for Multi-shell Open-source Scriptable Terminal Prompt Engine) about 6 months ago as PoC (and also as a way to learn more Rust), and have not touched it since. It is very rough, and not at all ready for use yet. I think more thought and design needs to go into it before I can continue, which is why I am posting this.
Its biggest features are:
Beta Was this translation helpful? Give feedback.
All reactions