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

From: Xarchus <xarchus_AT_comcast.net>
Date: Tue, 15 Dec 2015 06:41:21 -0800

On Mon, Dec 14, 2015 at 06:57:34PM +0100, Silvan Jegen wrote:
> Heyolo
[...]

No problem, I'll take care of the trailing spaces.

>
> 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.)


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)

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.

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.


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/".

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 be tempted to do A1 and B, although I would feel more accurate to
do a C instead of B ... But I don't mind either way.
Received on Tue Dec 15 2015 - 15:41:21 CET

This archive was generated by hypermail 2.3.0 : Tue Dec 15 2015 - 15:49:01 CET