On 21/07/08 12:30, Nikita Zlobin wrote:
> Perhaps because user wants :P
> Writing to window title is primary function of my approach. It could be
> done by main app (best), but this time it's dedicated script, designed
> to run parallel and write to window title, while main app displays it
> content. How can it be more minimal?
> - Main app, doing it themselves? Better of has. Or find better point to
> add this feature for app, that doesn't support that.
Catering to user desires is a pitfall which leads to bloated software. It is
easy for the users of suckless software to customize it, so there's no need to
include those customizations in the main repositories, except maybe as patches.
The drawbacks of doing the opposite outweigh the benefits.
> What's better way to open app, logically related to some applet: click
> applet, which is here and now, or again open dialog/menu/term,
> select/type command...
The best way to start a program (I avoid the term "app"/"applet" to refer to
programs and scripts) is to type its name. In dwm, that's what dmenu_run is for,
by default invoked by Mod+p. For more advanced use of programs there's st.
> (ah, forgot another example - mc and even shell, printing cwd to
While generally better than GUI file managers in terms of dependencies, Midnight
Commander (and in fact, any file manager) is not suckless software. TUI in
general is not suckless. I believe there was a discussion recently about this.
If you are referring to
it states at the top:
> Software on this page should have ideas similar to the suckless philosophy.
Note the wording: "similar".
> Each has own understanding of suckless.
That's fine, but everyone's understanding of suckless is not necessarily the
> About patches: I'm not sure, what it's about.
> - If about my specific implementations, using scripts, then there's
> nothing to be simplified.
The functionality itself, the "problem" those scripts are trying to solve, is
not fundamental and would best constitute a patch instead of being included in
the baseline repository of a package like st.
As a standalone project, I again don't see the need to include this in the
Received on Thu Jul 08 2021 - 10:42:57 CEST