Re: What?

On 25.09.2024 10:53, Damien Wyart wrote:

I have some NNTP issues (I can see much more articles on the public read-only
server I use than on the other one I use to post) ; I almost never post nowadays
and Usenet is really extremely niche now, so I do not want to invest time on
fixing...
 
I will still answer very quickly to this even if I vaguely feel a trollish tone:
 

Fine. But what is a "framework prompt" (or a "(shell, not LLM)
prompt framework" if you prefer that)? Since you're suggesting
something (in context of something as simple as a shell prompt)
that is obviously not commonly known, do you mind to explain?
Preferably with a rationale or statement why it shall be used
(as opposed to just defining prompt the usual and simple way).

 
I'm not interested in bike-shedding on words, we can call them prompt tools or
whatever, I don't care.
 
"not commonly known" might be true in this newsgroup, but if we look at the
"Github stars" for all the projects I quoted (yes, I know, this metric is not
perfect and can be criticized), they sum up to about 235000, so these projects
clearly have users.
 
If you have a quick look at the tools (why would the whole "evidence" be on my
side?), what they have in common is:
- they provide much more pieces of info you can choose to display (see right
  column on https://starship.rs/config/) and, importantly, to not display if they
  are not relevant to you
- this info is dynamic and comes from many sources unknown from the shell itself
- they are contextual: the display depends on the current directory and its
  content
- they can be configured in much details and you do not need to fiddle with ANSI
  codes to add colors, for example.
 
 
I will stop here on this whole topic, if people hate external prompt tools, they
are free to not use them.

With this belligerent stance (that obviously blurred your perception)
you seem to have completely missed the intent of the various responses
to your post, despite they were coherent across the posts and should
in their own individual ways of expression have been quite clear.

It was not about finding a fitting word for the software package.
It was not about click-rate or download statistics of that tool.
It was not about emotions towards the tool (fans/you vs. haters).

It was simply about what that package is supposed to do.
And why it's worth to install and use that huge package.

From all the posts (yours and other responses) I guess that you have
to install a (huge) package to introduce a layer between you and your
shell, that all input and output gets intercepted and transformed in
ways that can be controlled by an enormously large configuration file.
[ Such sort of an answer I would have hoped to get from you to shed
  some light on the questions, along with some application examples
  to better understand your decision why you prefer to use the tool.]

Personally, I generally try to avoid dependencies, especially to such
voluminous packages with questionable utility and unknown reliability
and potential interference to my environment. I prefer using standard
environments as much as possible and sensible, to be able to work the
same way when switching to other environments. Using e.g. ANSI codes
(if sensible) is no burden for me, certainly not more than learning a
software package and its extensive configuration options. (YMMV.)

Janis

PS: *If* the package is effectively an intercepting layer I wonder
how it will pass functions that I use in my shell (e.g. Vi Editing
Mode) to the shell. Note: this is just of academic interest to me,
so don't bother. But I suspect you're probably anyway not the right
person here to answer that, so I put it just in the post scriptum.
But, if I mis-assessed, feel free to enlighten us with some facts.