[dmenu] Putting key combinations in config.h

[Peter John Hartman]

Hi,

In light of the parallel discussion re surf and dmenu, I thought I'd open up
the following suggestion: Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c? There is one case where I know this will
prove useful, namely, the keybinding to close dmenu, which currently is
XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be
able to close dmenu with the same keystroke, i.e.\ Shift_R. But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?

Yours,
Peter

[Colin Shea]

On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman <

Post by Peter John Hartman
Hi,
In light of the parallel discussion re surf and dmenu, I thought I'd open up
the following suggestion: Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c? There is one case where I know this will
prove useful, namely, the keybinding to close dmenu, which currently is
XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be
able to close dmenu with the same keystroke, i.e.\ Shift_R. But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
Yours,
Peter

And I already posted to the previous discussion before reading this, great.

As I stated, it would be better than a parameter passed to dmenu on the
command line.

While it would be excessive, could it also be possible to have the
keybindings change the options available, not the input? Thinking
something along the line of a dmenu-based clone of Google's
Suggestions feature. Being able to type something then have dynamic
results, rather than static. This would be a lot more complex I'd bet than
what Anselm suggested.

[Peter John Hartman]

Post by Peter John Hartman
Hi,
In light of the parallel discussion re surf and dmenu, I thought I'd open up
the following suggestion: Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c?  There is one case where I know this will
prove useful, namely, the keybinding to close dmenu, which currently is
XK_Escape.  I launch dmenu with a keybinding to Shift_R and I like to be
able to close dmenu with the same keystroke, i.e.\ Shift_R.  But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
Yours,
Peter
And I already posted to the previous discussion before reading this, great.
As I stated, it would be better than a parameter passed to dmenu on the
command line.
While it would be excessive, could it also be possible to have the
keybindings change the options available, not the input? Thinking
something along the line of a dmenu-based clone of Google's
Suggestions feature. Being able to type something then have dynamic
results, rather than static. This would be a lot more complex I'd bet than
what Anselm suggested.

Hi,

1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.

2. I don't understand the subsequent request, although I've never used "Google's Suggestions" either.
What do you have in mind?

Peter

[Colin Shea]

On Wed, Oct 21, 2009 at 2:48 PM, Peter John Hartman <

Post by Colin Shea
On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman <

Post by Peter John Hartman
Hi,
In light of the parallel discussion re surf and dmenu, I thought I'd open up
the following suggestion: Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c? There is one case where I know this will
prove useful, namely, the keybinding to close dmenu, which currently is
XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be
able to close dmenu with the same keystroke, i.e.\ Shift_R. But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
Yours,
Peter
And I already posted to the previous discussion before reading this, great.
As I stated, it would be better than a parameter passed to dmenu on the
command line.
While it would be excessive, could it also be possible to have the
keybindings change the options available, not the input? Thinking
something along the line of a dmenu-based clone of Google's
Suggestions feature. Being able to type something then have dynamic
results, rather than static. This would be a lot more complex I'd bet than
what Anselm suggested.

Hi,
1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.
2. I don't understand the subsequent request, although I've never used
"Google's Suggestions" either. What do you have in mind?
Peter

I don't know if Google enabled it for everyone, but if you log into your
Google Account then start searching, it will provide possible completions of
your search term. So if you typed "do" into the search box, the first option
in the drop down would be "dog", but if you then typed "w" instead of
selecting it, it would return "down", etc. It also ties in with your
previous search history, so with "com" computer would rate higher than
complete, for instance.

[markus schnalke]

Post by Peter John Hartman

Post by Peter John Hartman
Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c?
But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
As I stated, it would be better than a parameter passed to dmenu on the command line.

1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.

Do we really agree? At least, I do not, and I hope you don't also when
you read this mail.


Dwm is a very personal program which everyone tailors to his needs.
Here configurable shortcuts are of much value and do not conflict much
with other users/different systems.

Dmenu, on the other hand, is a quite generic program which sould be the
same everywhere. If people start configuring the key strokes, one needs
different dmenus for different users on one system. Also, one may not be
able to use dmenu on a different machine. That's to avoid, for sure.

Configuring dmenu's look is one thing, but changing it's behavior is
another. I do recommend *not* to change the behavior. Thus don't put
such options to config.h.

If you *really* need to configure the key strokes, then do it in a way
that preserves the standard behavior. Using command line parameters for
it would be an example. But better don't do it at all.

Have you adjusted the key strokes of e.g. w3m? You may get a bit more
produktivity then ... but you'll lose all of it and more when you are on
another machine. Hence, you better learn the standard configuration and
don't depend on your machine.


Dmenu should be seen like grep or sed -- a standard tool that works the
same everywhere.

Please think about it.


meillo

[Peter John Hartman]

Post by markus schnalke

Post by Peter John Hartman

Post by Peter John Hartman
Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c?
But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
As I stated, it would be better than a parameter passed to dmenu on the command line.

1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.

Do we really agree? At least, I do not, and I hope you don't also when
you read this mail.

I guess not! We agree at least on the first part: that it should be in
/either/ dmenu.c or config.h and not passed to it from the commandline.
Fair enough.

Post by markus schnalke
Dwm is a very personal program which everyone tailors to his needs.
Here configurable shortcuts are of much value and do not conflict much
with other users/different systems.
Dmenu, on the other hand, is a quite generic program which sould be the
same everywhere. If people start configuring the key strokes, one needs
different dmenus for different users on one system. Also, one may not be
able to use dmenu on a different machine. That's to avoid, for sure.

[snip]

Post by markus schnalke
Dmenu should be seen like grep or sed -- a standard tool that works the
same everywhere.

I'm not convinced that dmenu shouldn't have keybindings right out in the
open and in config.h. I do, at least, see your point. (A better analogy
would be 'less'. Imagine instead of q quiting out of less someone hacked
up a variant that had r quit. O the pain!)

However, I do see the real need to configure at least the keybinding I
mentioned before, namely, the Esc keybinding. In a lot of cases, it is nice
to bind the exact same key which opens the menu to the close menu function,
e.g.\ in the case of the "Windows" key, or in my case, the Super_R key; and
in some cases Esc might not be the best guy for the job (although I prefer
having both Esc and the Super_R key precisely because other users will get
upset.)

I'm not sure if I have a positive solution. If there aren't any other cases
when it would be useful to fiddle with the default keybindings, then we
probably shouldn't bother. But maybe I'm not being creative enough?

Peter

[Colin Shea]

On Wed, Oct 21, 2009 at 18:55, Peter John Hartman <

Post by Peter John Hartman
I guess not! We agree at least on the first part: that it should be in
/either/ dmenu.c or config.h and not passed to it from the commandline.
Fair enough.
Dwm is a very personal program which everyone tailors to his needs.

Post by markus schnalke
Here configurable shortcuts are of much value and do not conflict much
with other users/different systems.
Dmenu, on the other hand, is a quite generic program which sould be the
same everywhere. If people start configuring the key strokes, one needs
different dmenus for different users on one system. Also, one may not be
able to use dmenu on a different machine. That's to avoid, for sure.

[snip]
Dmenu should be seen like grep or sed -- a standard tool that works the

Post by markus schnalke
same everywhere.

I'm not convinced that dmenu shouldn't have keybindings right out in the
open and in config.h. I do, at least, see your point. (A better analogy
would be 'less'. Imagine instead of q quiting out of less someone hacked
up a variant that had r quit. O the pain!)
However, I do see the real need to configure at least the keybinding I
mentioned before, namely, the Esc keybinding. In a lot of cases, it is nice
to bind the exact same key which opens the menu to the close menu function,
e.g.\ in the case of the "Windows" key, or in my case, the Super_R key; and
in some cases Esc might not be the best guy for the job (although I prefer
having both Esc and the Super_R key precisely because other users will get
upset.)
I'm not sure if I have a positive solution. If there aren't any other cases
when it would be useful to fiddle with the default keybindings, then we
probably shouldn't bother. But maybe I'm not being creative enough?

Peter
Well dmenu should at least have the defaults in config.h, just like the
default colors, etc. Then those who really want functionality X could patch
it in themselves, just like any other tools. Just because, say, I add Ctrl-G
to open a page in my browser with the current input as the URL doesn't mean
(and that probably wouldn't ever) it should become mainstream, or even
something widely used. It's my version of dmenu, hacked to what I want/need
in a choice selection program. Just like I could have a `less' that does use
O to quit rather than q.

I don't know about anyone else, but having escape as the default kill key
works out really well for me. Of course, I do have caps lock switched with
escape, however. It also helps with editing in vim.

[markus schnalke]

Post by Colin Shea
Well dmenu should at least have the defaults in config.h, just like the
default colors, etc.

But this encourages people to change them. I already said: Key bindings
are *not* like the colors.

Post by Colin Shea
Just because, say, I add Ctrl-G
to open a page in my browser with the current input as the URL doesn't mean
(and that probably wouldn't ever) it should become mainstream, or even
something widely used.

It better does not become widely used, as ist totally breaks with the
concept of dmenu.

Dmenu is like it is, in order to not need to build such commands *into*
it. Instead wrap a script around which calls the browser.

You probably should learn the concept behind dmenu first before you
argue on how dmenu should be.


meillo

[Antoni Grzymala]

Post by markus schnalke

Post by Peter John Hartman

Post by Peter John Hartman
Can we put the various keybindings used in dmenu
in config.h rather than dmenu.c?
But more
generally most other suckless apps have the keybindings in config.h, so why
not dmenu?
As I stated, it would be better than a parameter passed to dmenu on the command line.

1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.

Do we really agree? At least, I do not, and I hope you don't also when
you read this mail.
Dwm is a very personal program which everyone tailors to his needs.
Here configurable shortcuts are of much value and do not conflict much
with other users/different systems.
Dmenu, on the other hand, is a quite generic program which sould be the
same everywhere. If people start configuring the key strokes, one needs
different dmenus for different users on one system. Also, one may not be
able to use dmenu on a different machine. That's to avoid, for sure.
Configuring dmenu's look is one thing, but changing it's behavior is
another. I do recommend *not* to change the behavior. Thus don't put
such options to config.h.
If you *really* need to configure the key strokes, then do it in a way
that preserves the standard behavior. Using command line parameters for
it would be an example. But better don't do it at all.
Have you adjusted the key strokes of e.g. w3m? You may get a bit more
produktivity then ... but you'll lose all of it and more when you are on
another machine. Hence, you better learn the standard configuration and
don't depend on your machine.
Dmenu should be seen like grep or sed -- a standard tool that works the
same everywhere.
Please think about it.

I agree. My main argument would be, that one usually runs a single
instance of dwm per session (or sometimes more when on multiple
displays, but still it's a pretty static situation). But then in that
session that user may be launching dmenu multiple times for totally
unrelated purposes for which different colors and key shortcuts might be
suitable (important for visual identification, too). So there could be
defaults in config.h, but commandline switches have to stay.

Of course, this would not go in tune with the suckless paranoia
(doubling functionality, Jesus Christ!!!), so I suppose it should stay
as it is :).

Best,

[Anselm R Garbe]

Post by markus schnalke

Post by Peter John Hartman

      Can we put the various keybindings used in dmenu
      in config.h rather than dmenu.c?
      But more
      generally most other suckless apps have the keybindings in config.h, so why
      not dmenu?
As I stated, it would be better than a parameter passed to dmenu on the command line.

1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question.

Do we really agree? At least, I do not, and I hope you don't also when
you read this mail.

Here is my proposal:

The insert script execution shortcut will be hard wired into dmenu.c
and be ^p. By default it will do nothing. There might be a command
line switch to the insert script/command that is executed and read by
dmenu to insert at current position.

Kind regards,
Anselm

[markus schnalke]

Post by Colin Shea
Being able to type something then have dynamic
results, rather than static.

If you mean what I think you mean, then *omg*.

Never forget: It's all about avoiding complexity!


meillo