Configuration files

[gchp]

It would be great to have some kind of simple configuration file which users could use to tweak Iota behaviour. Things like using spaces or tabs, tab width, and so on.

Rust projects seem to use toml a lot for configuration files. Perhaps this would be a good starting place?

[config]
spaces = true
tabwidth = 4

or similar?

In the future there will be a proper plugin system, but we need something simple to start with.

[pythonesque]

Those configuration options seem pretty ad hoc. Wouldn't it be better to have a mapping from key combinations to arbitrary command sequences? Then you could map tab to "insert space" x 4. Later we could develop aliases for common cases.

[withoutboats]

This opens up a larger question on customization in general. Will iota eventually be scriptable? To what extent?

[pythonesque]

One of the stated goals of iota is:

highly extensible/customisable

This to me implies a full fledged scripting language. Doing it right means having a well-defined syntax (EBNF) with clear semantics. Not reinventing the wheel (mentioned by @gchp though not explicitly stated) plus personal experience suggests we should not write a hand-written parser, and LALR parsers are both extremely fast and extremely correct, so we will want to wait for a good Rust LALR parser generator to show up. All of these things will take time so I think we should punt on implementing anything much for now, in the spirit of "do it right or don't do it at all." But maybe a simple stopgap implementation is warranted.

[gchp]

Yep, I'd like it to be fully scriptable. I agree that we shouldn't rush into anything. Do we think something small is needed in the short-term, though? Or is it ok to force defaults for now until we have a correct solution?

[gchp]

It was mentioned on a subreddit that it would be cool to use Rust to script Iota. Building an extension or adding configuration would be a matter of writing a dynamic library and loading that at startup. It would remove the need for using a possibly slower dynamic language, and we wouldn't need to write any sort of intermediate layer. What do people think of that? I have to say I really like the idea.

[pythonesque]

Rust can't really handle dynamic libraries that well at the moment, and loading one is an inherently an unsafe operation (it can never be made completely safe, because it's arbitrary code execution at runtime). Plus we'd still need to expose the same functionality to other languages (unless that is no longer one of your goals?). So I'm not sure if it makes sense as a long-term solution.

[gchp]

Loading any arbitrary code at runtime is going to be somewhat unsafe, so that's not just something associated with this approach. In terms of other languages, I'm not sure just yet, I haven't quite figured out how it would work. This was just a suggestion that I quite liked.

[gchp]

This is all just soundboarding, so I'm open to all ideas!

[pythonesque]

Well, let me put it another way: loading dynamic libraries (as in bytecode) into the same address space is unsafe, in a way that, say, interpreted Python code wouldn't necessarily be. In particular, it can violate Rust's safety guarantees quite easily.

We haven't really worked out the dynamic language interface yet so maybe this will be an issue anyway, but the way I have been thinking about it is that if we force all input into an API that mimicks our query API (that is, interactions with iota are in the form of declarative transactions), we will make it very hard for other applications to create unsafety except where their own runtimes fail. I've been slowly working through designing the query language more formally, and I hope to have some updates on this later this week.

[gchp]

Ok, fair point.

Sweet, sounds good. Having a formal query API in place will help with the public API. At least it will give us something to interact with. We will still need to think of ways to allow definitions of custom keybindings and the likes. The querying will work well for interacting with data, however there are other parts of the editor that need to be scriptable also. Any suggestion on how to approach this piece? This is more what I was thinking with the dynamic libs, I had forgotten about the querying.

Looking forward to what you come up with for the query API though

[torwart]

Also YAML would be cool! I currently also work on an Editor (inC++/wxWidgets) and I felt in love with YAML, then it will looks like this:

# iota configuration
spaces: true
tabwidth: 4
recent_file: /example.txt

And there are two good parsers out in the wild.

[crespyl]

For general setting of properties, I tend to like YAML, or TOML if we're being rusty.

As an interesting reference point, wtftw is a tiling window manager that uses XMonad style compiled configuration files. See here: https://github.com/Kintaro/wtftw/blob/master/core/src/config.rs The aforementioned safety issues apply of course.