Here I opine from my user-perspective, treat is as such. ########################################################################
> Maybe just allowing 'term' in bindings is enough without documenting If a user reads http://man.openbsd.org/cwmrc#command first, like I did, then they might wonder why `term` bind function isn't working, but if a user reads http://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST first, then they might wonder why `command terminal` isn't working, so this should be documented in both places and in BUGS or CAVEATS section, and either both `term` and `terminal` should be allowed in both places, or leave it as it used to be, just document it. ######################################################################## Pieces of manpage about default `command`s don't reference each other. It took me quite a few re-reads over quite a long period of time to grasp what it is all about. ======================================================================== http://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST terminal Spawn a new terminal. lock Lock the screen. These don't mention their linkage to http://man.openbsd.org/cwmrc#command and want a different description: _________________________________________________ terminal Spawn a new terminal. Default is xterm. Configurable with `command term path`. lock Lock the screen. Default is xlock. Configurable with `command lock path`. ````````````````````````````````````````````````` ======================================================================== http://man.openbsd.org/cwmrc#command "The name entries term and lock have a special meaning. They point to the terminal and screen locking programs specified by key bindings. The defaults are xterm(1) and xlock(1), respectively." These don't mention their linkage to http://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST I'd welcome: ________________________________________________________________________ The name entries term and lock have a special meaning. They point to the terminal and screen locking programs invoked via key bindings customizable with `terminal` and `lock`, respectively. (see BIND FUNCTION LIST) The defaults are xterm(1) and xlock(1), respectively. The default key bindings are `CM-Return` and `CM-Delete`, respectively. (see `man 1 cwm`) Special entries term and lock are not displayed in the application menu. ```````````````````````````````````````````````````````````````````````` Perhaps, this info is best displayed as a table... ======================================================================== http://man.openbsd.org/cwm#M-period Spawn “ssh to” dialog. This parses $HOME/.ssh/known_hosts to provide host auto-completion. ssh(1) will be executed via the configured terminal emulator. This left me thinking for looong without finding an answer: what is "the configured terminal emulator"? until I completed the puzzle around the default `command term`. I'd rewrite this spot as: ________________________________________________________________________ Spawn “ssh to” dialog. This parses $HOME/.ssh/known_hosts to provide host auto-completion. ssh(1) will be executed via the terminal emulator specified in cwmrc(5) with: command term path The default is xterm(1). ```````````````````````````````````````````````````````````````````````` And it perhaps should be in both `man cwm` and `man cwmrc`, not only `man cwm`. Now what if user prefers the default `xterm` for regular tasks but another terminal for `ssh`? Go redefine `command term` and set your custom terminal to `CM-Return`! Inflexible and laborious. Wouldn't it be nicer to have a dedicated `ssh terminal` option? ======================================================================== Now, what if an application `terminal` or `lock` is brought into existence, it would be a clash with `cwm`'s bind functions, how does one `bind-key` then? `"sh -c terminal"` `"sh -c lock"` Awkward. What if `cwm` extends the number of special `command`s? Clashes are even likelier. Moreover, "special commands" are not displayed in the app menu as regular `command`s do. I call for a dedicated keyword. For `term` and `lock`, instead of http://man.openbsd.org/cwmrc#command there would be: http://man.openbsd.org/cwmrc#default Thus, if `cwmrc` implemented my take, it would contain, e.g.: _____________________________________________________________________ default terminal xterm # instead of `command term xterm` default lock xlock # instead of `command lock xlock` ssh terminal st # instead of `command term st` command terminal lxterminal command "default terminal" default terminal # run xterm command "ssh terminal" ssh terminal # run st bind-key CM-Return default terminal bind-key CM-Delete default lock ````````````````````````````````````````````````````````````````````` ######################################################################## ######################################################################## With Okan mentioning "inconsistent and overlooked" (it is very pleasant to see such self-criticism in a project), I'd like to continue further. Again, here I opine from my user-perspective, treat is as such. ######################################################################## Short vs long forms in `cwmrc` - it uses both. Long: most of `cwmrc` keywords, like `window-snap-up-right` or `bind-key` Short: C,M,S,4,5 instead of Ctrl, Alt, Shift, Windows, AltGr `wm` http://man.openbsd.org/cwmrc#wm `fg` and `bg` in `color menubg` and `color menufg` `r` in `group-rcycle`, `window-rcycle`, `window-rcycle-ingroup` `h` and `v` in http://man.openbsd.org/cwmrc#htile http://man.openbsd.org/cwmrc#vtile `window-htile` `window-vtile` `window-hmaximize` `window-vmaximize` Some keywords happen to exist in both forms: "cmd" in `menu-cmd` http://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST but `command` http://man.openbsd.org/cwmrc#command And the topic of the thread: `command term` vs `bind-key ... terminal` Either stick with short form, or with long form, or allow both as mutual aliases throughout. ######################################################################## Most of `cwmrc` complex keywords are neatly consistently grouped left-to-right via a dash: group-last group-toggle-[n] group-toggle-all window-group window-fullscreen window-move window-move-up window-move-up-big window-resize window-resize-up window-resize-up-big window-snap-up window-snap-up-right menu-window menu-window-hidden Some lumped without a dash left-to-right: color menubg # why not `menu-bg` or `menu-background` color menufg # why not `menu-fg` or `menu-foreground` But some are lumped without a dash right-to-left: color urgencyborder # why not `border-urgency` color activeborder # why not `border-active` color inactiveborder # why not `border-inactive` color font color selfont # why not `font-sel` or `font-selected` window-movetogroup-[n] # why not `window-group-moveto-[n]` ######################################################################## http://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST menu-cmd Launch application search menu. menu-exec Launch “exec program” menu. How does a reader know which one does what? Especially given that there also is: menu-exec menu-exec-wm The latter replaces `cwm`, the former replaces nothing. I'd write it like this: ________________________________________________________________________ menu-predefined # instead of menu-cmd Launch a menu of entries predefined with `predefined name path`. menu-run # instead of menu-exec Launch a dialog to pick and run an executable from PATH, arguments are allowed. menu-exec # instead of menu-exec-wm Launch “exec” menu. The entry will replace `cwm`. Typical usage: alternative Window Managers and Desktop Environments, applications in kiosk mode and games. ```````````````````````````````````````````````````````````````````````` `run` is a recognizable name for this kind of dialog. `menu-exec` is stripped of `windowmanager`, since window manager ilk is not the only candidate to replace `cwm`, and `exec` echoes what you put into `.xsession` and `.xinitrc`. Admittedly, `menu-exec` entries will also be "predefined"... ######################################################################## Although called "menus" and "dialogs" interchangeably in `man cwm{,rc}`, they express different behavior: menus start as presenting a list, allowing for filtering it, whereas dialogs start as presenting an input field, which upon typing displays a list of matching entries. E.g. M3 on the root window invokes a menu whereas `menu-cmd` bind function invokes a dialog. A dialog may be turned into a menu by pressing `C-a` (List all available items) (menu doesn't turn into a dialog - once there are entries displayed, the list never collapses, even having pressed `C-u` (Clear input)) I, for instance, don't understand why `cwm` launches a dialog, not a menu, upon `menu-window` bind function, thus initially hiding my windows from me. It would be useful to have the ability to run all menus/dialogs in user-preferred mode: as a menu or as a dialog. So, `cwm` would handle: menu-window Launch window search menu. menu-window-hidden Launch hidden window search menu. menu-cmd Launch application search menu. menu-group Launch group search menu. menu-exec Launch “exec program” menu. menu-exec-wm Launch “exec WindowManager” menu. menu-ssh Launch “ssh” menu. dialog-window Launch window search dialog. dialog-window-hidden Launch hidden window search dialog. dialog-cmd Launch application search dialog. dialog-group Launch group search dialog. dialog-exec Launch “exec program” dialog. dialog-exec-wm Launch “exec WindowManager” dialog. dialog-ssh Launch “ssh” dialog. ######################################################################## Since `cwm` ships with pre-configured terminal and lock launching, can restart and quit itself, it would be consistent to add suspend, hibernate, reboot and shutdown and perhaps some other commonly used actions... `cwm` novice users would especially appreciate it if reboot and shutdown were there (if it is possible) due to them requiring additional privileges, which novice users may not know how to configure. ######################################################################## Default keybindings of `cwm` shipped in OpenBSD's base clash with default keybindings of `tmux` shipped in OpenBSD's base. I personally have got used to `4` (Super/Windows) key for managing windows, and it never conflicts. `cwm` defaults thoroughly avoid the `4` key... ######################################################################## Combining (most of) it: `man 1 cwm`: ________________________________________________________________________ M-period Spawn “ssh to” menu. This parses $HOME/.ssh/known_hosts to provide host auto-completion. ssh(1) will be executed via the terminal emulator specified in cwmrc(5) with: ssh terminal path The default is xterm(1)." ```````````````````````````````````````````````````````````````````````` `man 5 cwmrc`: ________________________________________________________________________ The following options are accepted: predefined name path Every name entry is shown in the application menu. When selected, the defined path is executed with execvp(3). default | | default | default | | | type | application | key binding | bind function | | | | see man 1 cwm | see BIND FUNCTION LIST | |-----------|-------------|---------------|------------------------| | terminal | xterm(1) | 4-Return | default terminal | | lock | xlock(1) | 4-Delete | default lock | | suspend | zzz(8) | ... | default suspend | | hibernate | ZZZ(8) | ... | default hibernate | | reboot | ... | ... | default reboot | | shutdown | ... | ... | default shutdown | customizable with: default type path the defined path is executed with ... exec When selected, the Calm Window Manager is replaced by path. Typical usage: alternative Window Managers and Desktop Environments, applications in kiosk mode and games. BIND FUNCTION LIST terminal Spawn a new terminal. Default is xterm. Configurable with `default terminal path`. lock Lock the screen. Default is xlock. Configurable with `default lock path`. suspend ... locks screen with `default lock` hibernate ... locks screen with `default lock` reboot ... shutdown ... dialog-predefined menu-predefined `predefined name path` entries. dialog-run menu-run Pick and run an executable from PATH, arguments are allowed. dialog-exec menu-exec “exec name path” entries, will replace `cwm`. dialog-ssh menu-ssh “ssh to”, parses $HOME/.ssh/known_hosts to provide host auto-completion. ssh(1) will be executed via the terminal emulator specified with: ssh terminal path The default is xterm(1). ```````````````````````````````````````````````````````````````````````` `cwmrc`: ____________________________________________________________ default terminal xterm default lock xlock default suspend ... default hibernate ... default reboot ... default shutdown ... ssh terminal st predefined "custom user terminal" lxterminal predefined "custom screen locker" i3lock predefined "default terminal" default terminal # xterm predefined "default screen locker" default lock # xlock predefined "ssh terminal" ssh terminal # st exec fvwm fvwm exec twm twm bind-key 4-Return default terminal bind-key 4-Delete default lock bind-key ... menu-predefined bind-key ... menu-run bind-key ... dialog-run bind-key ... menu-exec ```````````````````````````````````````````````````````````` ######################################################################## Also - offtopic - a heavily missed feature: window-maximize Maximize current window (gap honored, border removed). Or alternative approach: borderwidth 3 borderwidth-maximized 0 And furthermore it would be awesome (if it is possible): window-vmaximize Vertically maximize current window (gap honored, horizontal border honored, vertical border removed). window-hmaximize Horizontally maximize current window (gap honored, vertical border honored, horizontal border removed). ######################################################################## I don't code in `c`, so I can't help implement these wishes, please excuse me. Regards
