Using kakoune, the only thing that seems truly unintuitive to me is the formatting of the cli flags. I've very infrequently run into other applications that prefix flags that are greater than one character with a single '-'. For example, here is the kakoune help list:
Options:
-c <arg> connect to given session
-e <arg> execute argument on client initialisation
-E <arg> execute argument on server initialisation
-n do not source kakrc files on startup
-s <arg> set session name
-d run as a headless session (requires -s)
-p <arg> just send stdin as commands to the given session
-f <arg> filter: for each file, select the entire buffer and execute the given keys
-i <arg> backup the files on which a filter is applied using the given suffix
-q in filter mode, be quiet about errors applying keys
-ui <arg> set the type of user interface to use (ncurses, dummy, or json) <
-l list existing sessions
-clear clear dead sessions <
-debug <arg> initial debug option value <
-version display kakoune version and exit <
-ro readonly mode <
-help display a help message and quit <
Note the marked lines. I would expect for ui, clear, debug, version, ro, and help to be instead closer to:
--ui=<arg> -u set the type of blah blah blah
--clear -C Clear dead sessions
--debug=<arg> -D debug it
--version -v Show version
--ro -R readonly,
--help -h
I went to the trouble of looking through the POSIX spec and IEEE Std 1003.1 (Standard for Command line Utilty interfaces), and the current way of doing things is compliant with both. I could only find documentation of the double dash in the GNU coding standard. I know this project is not GNU and it does not expressly try to comply, but I'm curious the general feeling about modifying options this way. It is possible that I am just too heavily laden with GNU bloat and the '--' style isn't all that common.
Outside of being more compliant to my perception of the standard (again, I could just unknowingly be a GNU fanboy), a change to this effect would also enable multiple flags in one token. If one wanted to run a headless session without the kakrc, for example, what was once kak -s test -d -n could become kak -dns test (or just kak -s test -dn if you aren't feeling too crazy).
I am aware their are are considerable backwards-compatability issues associated with changing this, but I wonder if this would cause issues for kakoune in the future, as it becomes a more widely-used editor.
but I wonder if this would cause issues for kakoune in the future
it wouldn't
Not having the concept of long/short options was a concious decision I made early on. I am not really keen on having 3 ways to express the same thing (-o value, --option value and --option=value) and I dont think short argument collapsing is a very important feature.
Besides my dislike for GNU style long option, Kakoune option parsing is shared between command line argument and internal prompt mode, so changing this would require either splitting that code, or changing the command language itself.
@mawww How about replacing single letter option names with real words?, e.g. -c → -connect.