kanata
kanata copied to clipboard
Do not use `:` to separate linux devices
Interpreting :
as separating devices is a bad idea. We should just allow a list to be passed to linux-dev
. For example
(defcfg
linux-dev (dev1 dev2 dev3)
)
The idea of using :
comes from the Linux $PATH
variable. Parsing a list is fine, but it should be added as an alternative and not a replacement, since it doesn't seem like a useful enough change to break existing configurations.
As an aside, some communication advice: avoid unsubstantiated statements like "X is a bad idea". A better way to phrase this type of issue is something like:
The current approach has X, Y, Z weaknesses. The new approach A fixes these weaknesses and also has improvements B, C. Approach A has downsides D, E, but to me, these are worth the advantages.
The idea of using : comes from the Linux $PATH variable.
Yes, but linux environment variables have no "types", everything is a string. By contrast, we are using a structured configuration file in the form of S-expressions. We should take advantage of that structure! It doesn't make sense to have one special case here when we use lists everywhere else.
Most paths in /dev/input/by-path/
have multiple colons in them. For example, pci-0000:00:14.0-usb-0:1:1.0-event
. Why force the user to escape all those colons just to use a path? It is also not intuitive to treat colons as something special. If a new user puts a path into their configuration and it doesn't work because of the colon, it is probably very confusing.
To me, there are no disadvantages to using lists except breaking some existing configurations. We can always document this somewhere so I don't see this as a big issue.
Sounds sensible. We can bump the major version to 2 to signal a breaking change if/when this is implemented.
I suggest just adding an alternative option linux-dev-list
. Then you won't have an incompatible change.
Since my dev list has 5 long ugly things in it (because so many keyboards get connected to my laptop at various times), I like the sound of having a list that I can break up into multiple lines.
That sounds like a decent idea. For anyone that may want to implement this (including my future self), do be aware that currently, the entirety of defcfg
is parsed as a HashMap<String, String>
. It may be easier to have a different top-layer configuration item, e.g.
(defcfg)
(deflinux-devices
/dev/input/1
/dev/input/2
...
)
A consideration: should the two methods merge their items together, or should one take priority over the other?
For anyone that may want to implement this (including my future self), do be aware that currently, the entirety of defcfg is parsed as a HashMap<String, String>
#624 have been merged, now we got the tech to easily parse lists in defcfg
One thing to note, that we now have not only linux-dev
, but also linux-dev-names-include
and linux-dev-names-exclude
, so to keep consistency allowing lists as values should be implemented for all 3.