Design discussion: Declarative scheme config #10441
Replies: 2 comments 10 replies
-
I don't understand why there's a need for defn and fn to take the context as argument explicitly since they'll be reading/writing its 'fields'. Why not expose those directly since the editor context is global?
becomes
whereas I imagine the need for that to be context-awareness since the editor isn't the only 'context', there are other elements f.e. completion, picker etc, since the commands/functions are contextual (ie their behaviour is vary depending on their target) f.e. move-line-up may go up one line in the editor view or in the picker. Am I misunderstanding anything here? |
Beta Was this translation helpful? Give feedback.
-
Just two small things I can think of right now I would think things like cx->count would have to be functions so to get there value you would have to do |
Beta Was this translation helpful? Give feedback.
-
While the fundamental implementation of our scheme config will be build around something like
:set
I want to offer a more declarative config syntax that more closely resembles the current toml config.The declarative config should smoothly allow incorporating lambdas and programmatically defined values so you can still use a declarative config with a scripted config.
Syntax wise I quite like what gnu guile does. I will maintain a version of what I want the config to look like that I will keep updated. This is not a final version yet (hence its a discussion) so this can definitely change with time and nothing is final yet.
I will first show off an example that shows off all features and then add some explanation afterward (hopefully some of this can be turned into docs later)
Main Config (currently under
editor.*
)config
is a macro that allows declaratively setting editor configuration. It will essentially expand to a bunch of:set
calls. While(config)
accepts an arbitrary number of arguments this is just syntactic sugar and exactly the same as writing this out manually. Specifically the following two configs are equivalent:Enumerations/String Constants
Some config options like
line-number
only accept a limited set of values (usually these are string enumerations in rust). These options are represented as strings in the config system (already the case). So the following two configs are equivalent:(config (line-number "relative"))
The former syntax is syntactic sugar enabled by the macro (a manual set call needs to use a string literal). This syntactic sugar is enabled for two reasons:
I expect these to work as follows:
The macro would expand
(line-number relative)
tothese let bindings allow the use of an identifier instead of literals. Since this is normal macro expansion a good lsp (implemented similarly to RA) could do this expansion, parse the let bindings and to autocomplete based on that. Alternatively we can just build the macro into the language servers (same way RA has support for macros builtin). The latter option is probably both easier to implement and will yield better results.
A couple points about this
nested configs
The config system does not have a notion of nested config options like toml does. What is currently a nested config options (like
soft-wrap.enable
) will simply have the its full path as its name (sosoft-wrap
is not a map that containsenable
andwrap-indicator
but insteadsoft-wrap.enable
andsoft-wrap.wrap-indicator
are just two seprate options).So its always possible to set them using the qualified path like in toml.
(config (indent-guides.enable #t))
Additionally the
config
macro offers convenience syntax for setting multiple nested/related config at once. For example the following two configs are equivalentLists
We use lispy syntax so config options that accept a list of values are defined by just adding more values.
Additionally config options that accept lists can append to the currently defined value (either in a different set command, or for example a workspace config can append to the global config). While this will be handeled by a flag with set the macro allows this by simply postfixing a
+
to the name. For example:Keymap
A keymap is defined by
(keymap ...)
. There will be an equivalent ofkeymap
so it will be possible to set mappings programmatically too and then(keymap)
will msotly just expand to that.The first argument of the keymap is the mode you want edit. Usally that will be
normal
,select
orinsert
but you can also define your own custom modes. By defaultkeymap
will append/merge the keymap but you can use(keymap!
to forcefully overwrite a map). Inside a keymap macro you can also postfix a binding with!
to overwrite instead of merging.(this example is purpusfully complex to show off all features a real keymap would usually be simpler)
TODO document details
Beta Was this translation helpful? Give feedback.
All reactions