best way to maintain/configure local changes to dit

[jaeheum]

More of a comment, not a bug report (yet).

While it is no big deal to maintain local diffs/branches of dit, I wonder about better ways.

Example 1: enabling/disabling themes w/o recompiling (thank goodness it takes less than a second to recompile and start newly built dit! 👍 -- ok I see there is already a TODO from 11 years ago!

Example 2: scripts e.g tmux.lua have cmd.run() that takes a hard coded string that I may want to change from time to time. Some lightweight solution possiblities include .dit/conf.lua (just a table)?

Example 3: binding/default vs scripts. There are two issues:

• manual inspection of both default and scripts to find out what keys are availble
• nomenclature difference across CTRL_A vs key=="A" vs Ctrl+A (in README) is minor but still annoying.

Note I am NOT asking for XML, IDE, or a language VM pretending to be a text editor! :-)

Configuration is hard....

Cheers!

[hishamhm]

Yeah, I've been postponing adding configuration since forever... :)

The ideal way, I think would be like I did in htop: (1) a simple key-value pair config file (like ~/.config/htop/htoprc) and (2) a in-program configuration screen where all options can be edited (like the [F2] Setup screen in htop).

I never implemented either for Dit and have no immediate plans to do so, but the nice thing is that they could be implemented separately, with the config file being added first.

In htop I explicitly didn't want to do this because I didn't want users to have to edit a config file by hand. To implement (2) in Dit, the easiest way would be to steal some more code from htop to make the configuration screens (though some options would probably need user text input and none of the htop options do this, but we could use the Field code that the "find" feature uses).

In any case, starting something like a config file for things like theme, default number of tabs/spaces (and any other things that aren't changeable but should be), etc, would be a welcome addition.

With that in place, implementing a setup screen could be a second, separate step which I may try to do in the future if I get the time and enough motivation to do so. :)

[jaeheum]

Sounds reasonable. In case a wonderful, helpful person (not I) is reading: please pay attention to possible strange interactions between user supplied strings, cmd.run() and other features. Turning cmd.lua into a shell for error/redirect handling would be an overkill. TIA.

[davidak]

There is EditorConfig for per-project configuration. There is actually one in the dit repo. We should use that when available. There is a C library.

When i understand correctly, you can have a .editorconfig file in your home directory and editors use that when a project has no such file. That way we easily have a config file that possibly already exists and other editors can also use. People have them in their dotfiles.

Since EditorConfig uses INI-style format, we also should use that for a general config file with options not included in EditorConfigs Properties.

Here they explain why they use INI-style format.