Re: [hackers] [dmenu][RFC][PATCH] History functionality

From: Silvan Jegen <s.jegen_AT_gmail.com>
Date: Tue, 15 Dec 2015 18:09:18 +0100

On Tue, Dec 15, 2015 at 06:41:21AM -0800, Xarchus wrote:
> On Mon, Dec 14, 2015 at 06:57:34PM +0100, Silvan Jegen wrote:
> > Heyolo
> > I think it can go on the site like that. I would vote for it superseding
> > the old history patch which integrated the history functionality in
> > dmenu's C code and does not apply to tip anymore.
>
> Yes, there is a lot of cruft accumulated in the patches section ...
>
> To be super-safe, that history patch can be moved into the "legacy"
> section. The script itself is indeed ancient and obsolete, but the
> description might be useful, it can give people good hints of what can be
> done (i.e. some sort of integration with surf, etc.)

According to the site, the legacy area is for "Patches that have since
been merged into dmenu trunk in the latest release."

I think we should repurpose it.


> But there is also a distinction between that one and the new thing.
>
> The old patch, as invasive as it was (modifying dmenu itself), allowed the
> option to use history (or not) wherever dmenu was used, on a case by case
> basis. By having the file supplied by the caller to dmenu, multiple history
> contexts could be maintained, and not only for executables, but for URLs,
> plain strings or whatever the other instances of dmenu were getting fed
> with. (You could still achieve a similar effect with a general wrapper that
> offers history, but the generality would add a bit of complexity as I guess
> you've already noticed)

I was made aware of that at slcon2.


> This dmenu_run_history, the culmination of our last couple of weeks of
> discussion, is what the name implies, a *global* (per-user) history
> mechanism *for* *dmenu_run*. Nothing more. In any other context where a
> history is desired (say, as in the way the old patch's author was
> suggesting about using it in surf), it would require some changes.
> Which of course, can be left as an exercise for the reader. It's not
> difficult at all, just that each situation will need specific
> customizations.

I would expect people to know what to change if they want to use the
history functionality together with dmenu but without using a shell to
start dmenu's output.


> But it's good to set the expectations, so I think the title should be
> something like "dmenu_run replacement providing history" or something like
> that.

I agree. How about

"dmenu_run with command history"?

Either is fine with me.


> Another thing is that this dmenu_run_history is, technically, almost a
> 'script' and not a 'patch'. (well, in between, 80% script, 20% patch ?)
> demnu_run_history can be run in place of dmenu_run, but doesn't change
> demnu_run, which can still coexist with it. Hmmm...
>
> I noticed in the dmenu wiki area, there is a section for scripts: I rarely
> ventured there, but indeed it exists. To my surprise, it even has a very
> old attempt at adding history into dmenu_path, but in a bit of a
> process-heavy pipe-festival kind of way. Also, its history file saves every
> command invocation, multiple times, which is a bit funny, but, hey, in the
> end the whole thing is quite compact and it seems to do the job.
>
> So another alternative would be to stick this dmenu_run_history there, in
> the 'scripts' section, although I would try to make its own entry, in the
> same way each patch has its own page under "patches/".

I did not even know there was a script section...


> To summarize:
> For the old 'history' patch:
> A1. Move it into legacy
> A2. Keep it
> A3. Delete it
>
> For the new stuff:
> B. Create patch entry (under "patches/") for "dmenu_run with history"
> C. Create entry under "scripts/" for "dmenu_run with history"
>
> You kind of voted for A3 and B , is that correct ?

I would either do A1 if you want to repurpose the section or just A3. C
seems to be more accurate since it's closer to a new script than a
patch but both work for me.
Received on Tue Dec 15 2015 - 18:09:18 CET