Hello! On Thu, 12 Aug 2010 21:19:52 -0400, Kris Maglione wrote: > But if you're looking for a start, this is the above modified to > (crudely) complete a command and then files in the current > directory:
I have an issue with this second variant, which I didn't notice first and am unable to solve. Whether I quit it with Return or Esc, the result is the same: the input string is sent to stdout. If you still want to help… I'm stuck here. On Sat, 14 Aug 2010 05:31:01 -0400, Kris Maglione wrote: > I do agree, though, that a program like wimenu or dmenu has no > place providing builtin completion. [..] > For any use other than launching commands, the results make no > sense. That's true. I'm using (wi|d)menu myself for other purposes as well. > This is why I left completion up to the program executing the menu. > It knows what it's running it for better than I do. ---> I think that this is very clever! Bash completion is excellent, but not customizable (as far as I know). Thus I do agree that it is a good thing that wimenu comes with a much more elementary completion (it is not intended to duplicate bash), but fully customizable (it allows to do other things, even those that bash can not). Example: In bash I have always been missing a history behaving like in vim. Let me explain this. If you have typed a long command 'cmd' at some moment and want to repeat it, you will probably want to use the history. Bash will then display successively all the (possibly numerous) other commands that you typed in the mean time, while vim while jump directly to 'cmd' provided you type only the beginning of it. Using bash history inside wimenu with your script (the 'second variant' mentioned above, which I called 'wim' in another post) allows to recover this nice behaviour of vim, which eventually makes wim a significantly BETTER way (in my opinion) of typing commands than to use a terminal. Of course it is assumed here that wim is able to treat differently commands like 'xpdf …' and 'ls …', which is possible by passing its output to an appropriate filter which decides whether the command must be executed as it is or after opening a terminal (and this is one more level of customization). All this, and even more (like a completion suggesting options for certain commands), is possible with wimenu and not in bash (again as far as I know) because of the great flexibility of the former. So… I do agree with you on this point. I'm glad to know that you are going to add a vertical mode to wimenu too, this is nice for menus with long lines (and for most menus on small screens). Regards, LuX. PS: I haven't been able to access http://lists.suckless.org/dev/att-5538/menu.pl I take you at your word if you say that it is 'considerably more arcane than the awk version'. Anyway this is one more reason to 'make a point of only using POSIX utilities in examples' as you said.