I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
The `parse_keys()` function is case insensitive when parsing function keys,
while the `key_to_str()` function always returns a capitalized key
description.
When users hook on the lowercase name of a function key,
e.g. `NormalKey <f10>`, and later hit that same key in normal mode, the
`key_to_str()` will convert it to the uppercase description ("<F10>").
This results into a hook with a lowercase regex predicate being unsuccessfully
matched against an uppercase key description by the hook manager, which
works on a case sensitive basis.
One solution could be to uppercase all function key descriptions passed as
hook filter upon declaration, but detecting that is not trivial as the
filter can contain more than just the simple <f\d+> data, e.g.
---
hook global InsertKey '<(?<name>\w+)>' %{…}
---
Another simpler solution that this commit implements is to allow only <F\d+>
descriptions in `parse_keys()`, and hope users will know not to use the
lowercase notation when declaring hooks.
Fixes#2907
The previous "optimized" history register logic was unfortunately
not restoring correctly as the order of entries in the history
register could have been mutated.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
This attempts to support a simple formatting and intentation style for
plain sh syntax (and other sh-compatible code which doesn't stray too
far from portable sh).
The complexity of sh syntax means that we have to be opinionated -
attempting to be more flexible would require extensive context
awareness, and would require something more akin to a proper
autoformatting tool or a language server.
The formatting style used here makes use of vertical whitespace as the
primary delimiter, so that code ends up looking like this:
if [ $foo = "bar" ]; then
thing1
else
thing2
fi
for i in foo bar baz; do
thing1
thing2
done
case "$foo" in
bar) thing1;;
baz)
thing1
thing2
;;
esac
Since the formatting style used is very opinionated the 'sh_auto_indent'
option can be used to disable auto-indentation, with the default set to
'no'.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.# Please enter the commit message for your changes. Lines starting
