Load modes from <config dir>/modes/

[iainh]

In addition to loading modes from config.ron, load modes the modes subdirectory of the configuration directory.

For example, the following would enable the Markdown mode:

$ cat ~/.config/zee/modes/markdown.ron
Mode(
    name: "Markdown",
    scope: "source.md",
    injection_regex: "md|markdown",
    patterns: [
        Suffix(".md"),
    ],
    comment: None,
    indentation: Indentation(
        width: 2,
        unit: Space,
    ),
    grammar: Some(
        Grammar(
            id: "markdown",
            source: Git(
                git: "https://github.com/MDeiml/tree-sitter-markdown",
                rev: "d24196f9b3e5af6fcb2ec2a0b6cbc5c06f58b85e",
            ),
        )
    ),
)

This PR is meant an exploration of the options for making mode configuration easier by removing the need to edit RON files themselves. One possible usage would be to make a <config dir>/modes.avail/ directory containing all of the known modes that a user could then symlink to <config dir>/modes/ similar to how freetype on many linux/unix systems works. Another would be to allow users to download modes from the zee website (or a github repo) and put them into <config dir>/modes/ prior to running --build to enable additional languages.

Any interest in me polishing this feature a little more or it is preferred to keep all mode configuration in config.ron?

[kevinmatthes]

Yes, this is a very interesting feature, thank you for your enhancement!

I would like to suggest to focus on the first option to outsource the mode definition to an own directory rather than providing precompiled versions since this would limit people to a fixed set of platforms. When building the modes with --build, they are compiled with respect to the installed hardware instead of a generic, unoptimised compilation which needs to fit as many hardware configurations as possible. This would possibly disadvantage users with rather unique setups, such as rare CPU architectures, since it would be hard to provide a precompilation for all possible hardwares.

The provision of a precompiled mode could be a next step but should in no case replace the current download mechanism in order to prevent the problems described above. And finally, both options rely on a directory to load from, so continuing developing the directory at first appears to be a reasonable design decision to me.

[kevinmatthes]

How about making the path to the modes directory a configuration parameter?

[kevinmatthes]

Another would be to allow users to download modes from the zee website (or a github repo) and put them into <config dir>/modes/ prior to running --build to enable additional languages.

What exactly do you mean to provide for download? I interpreted this sentence as provision of precompiled mode packs, this is the mode.ron together with the shared objects library and the queries, since the suggestion explicitly refers to the --build option which should be avoided.

Another option, without having to precompile the parsers, is to just provide the RON files for the modes but this would still require to --build them with Zee. This would be my preferred option since it would only require to maintain the configuration files instead of having to precompile all offered parsers and to keep them up to date. If you intended to mean this procedure, I am sorry, I did not understood your suggestion correctly; I assumed that only with precompilation the --build call could be skipped.

[iainh]

I should clarify my intent. I did not intend that binaries would be provided by the project, as you say, too much work to maintain them for all platforms. My thought was that the mode RON files (like the example markdown.ron above) could be distributed separately from the application, and the user could build them themselves. Eventually if zee binaries are provided by the project or an outside group (linux distros, packing systems for macOS/windows, etc.) they could perhaps also provide compiled tree sitter libraries but I'm not thinking of that as an immediate goal.

[iainh]

How about making the path to the modes directory a configuration parameter?

The current code expects the modes directory to be in the same location as config.ron but that location is configurable via the --config-dir command line switch. This keeps it in the same location as the grammars directory as well. Do you have a use case where you'd like to have config.ron point to a modes directory that wasn't stored in the same tree?

@mcobzarenco As the project owner, what is your preference for configuration parameters? Would you like to allow for full customization but possibly more difficult to support model or a "one size fits all" model where customization is limited but that will work the same for all users?

[kevinmatthes]

Do you have a use case where you'd like to have config.ron point to a modes directory that wasn't stored in the same tree?

Yes, there is a pretty common use case in my opinion: users who would like to switch between different versions. In #57, you mentioned a mode configuration file of another editor. If you now compare the Git revision of the Haskell mode they prefer with the Git revision I suggest in #62, you will see that these are different values. I suggested the latest available version since I intended our users to be able to use all implemented features while they surely have their reasons to recommend an older version.

If one now would like to test other versions of a certain Tree-Sitter, especially for updating supported modes, it is very useful to point to another directory with the newer revisions configured. Editing the modes directory path in config.ron is easier and faster than manipulating the respective modes' configuration files themselves then.

[iainh]

Rather than pointing solely to a different directory for modes with the updated rev, wouldn't you need to point to a different config directory all together so that the --build process wouldn't overwrite the grammar lib and queries directories?

Let's wait on Marius' vision for the application (and whether this is even a wanted feature). If everything should be configurable I can add the an item for modes and potentially the build and grammars directories as well since the same argument can be made for each of those. If the preference is to keep the number of configurable items to a minimum, then I'll leave it all as hard coded sub directories of the config directory.

[kevinmatthes]

The --build results' directories could be moved to modes/ but you are right that then, their positions would need to be adjusted, as well. The configuration variables you mentioned could then be overridden with the paths implied by the modes/ directory pointed to.

[kevinmatthes]

Regarding the two options you mentioned in your first post, soft-linking versus download: they do not need to exclude each other. When combining them, there would be the option to provide the configured modes as a repository in this namespace where all suggested configurations are provided, let us assume it is named as you suggested: modes.avail/. The application itself instead should still "listen" to a differently named directory, modes/ -- by default. To activate some of them, one could then either soft-link the desired ones, or, to activate all of them at once, make the configuration point to another directory: modes.avail/. Maybe if some people create their own collections, they would like to point and / or soft-link to. By combining all possibilities, users would achieve at most flexibility.

If the --build artifacts could be moved as sub-directories to the respective modes/ directory, the default directory for modes could be turned into a soft-link, as well. That would even prevent the need of another configuration variable.

What do you think?

[kevinmatthes]

Just as there is a default configuration file which is fetched when initialising from a newly installed binary, a default collection of stable mode configurations could be provided similarly in an own directory in this repository. It could become the suggested modes.avail/ directory.