Micro: [Enhancement] Loading in-directory settings.json for portable configuration

[pavelvr]

Would it be possible to load settings.json (maybe bindings.json, ...) from current directory, so you can create a sort of portable configuration? I use micro mainly on Windows, so it would be really useful to have a copy of my settings in the same folder I keep on my flashdrive.

[samdmarshall]

I think you could replicate this with a script that passes the additional flags to micro on startup or redefining XDG_CONFIG_HOME to be pointed at a directory to make the XDG_CONFIG_HOME/micro/settings.json resolve arbitrarily?

[pavelvr]

Thanks a lot @samdmarshall, I'll look into it

[pavelvr]

@samdmarshall, it worked like a charm, thanks, just created a .cmd file with the following content:

@echo off
setlocal

set XDG_CONFIG_HOME=%~dp0
micro.exe %*

endlocal

[GeigerCounter]

@samdmarshall Would this work for the other micro configurations? ( plugins, colorschemes, etc. )

[onodera-punpun]

#!/usr/bin/env bash

export XDG_CONFIG_HOME="./microconf"
micro $@

This way you can drop stuff in ./microconf, even syntax files and plugins, however of course user installed plugins and colorschemes don't work (which kind of is the point of this in-direcotry settings.json?). If you want to let the user make most choices, but still force some settings you could use flags, example:

#!/usr/bin/env bash

micro -tabsize 8 -eofnewline false $@

Also these scritps work on libre operating systems such as *BSD and GNU/Linux, and even on OSX and now Windows since that it has that Linux subsystem ;^)

[GeigerCounter]

@samdmarshall Setting XDG_CONFIG_HOME would cause problems with other programs that look for that, wouldn't it?

[samdmarshall]

It would, which is why you would need to redefine it within a scope where it would only impact micro. it would still impact programs spawned by micro so i wouldn't call this a recommended strategy, but it is a solution to this specific problem.

[zyedidia]

Maybe it would be good for micro to first check for a MICRO_CONFIG_HOME directory and if that is empty or undefined then use the XDG_CONFIG_HOME instead?

[samdmarshall]

I think that is up to you, i think this is edge-case behavior that doesn't need official support beyond XDG_CONFIG_HOME. I think it would be another matter if micro had a single config file, but that isn't the case.

[mame98]

or maybe a --local flag which chechs for config files in the current directrionary and if nothing is found it will fallback to the default files?

[janlazo]

How about a --config flag which accepts a directory filepath?
I want to use ~\AppData\Local\micro as config directory for Micro in Windows.

[GeigerCounter]

@janlazo That's not a bad idea at all, actually. I'll look into implementing this.
@zyedidia Also not a bad choice. I'll look into implementing this as well.
Should be simple to implement. :)
Also, I understand the reasoning for not having micro check its run directory for config by default, but maybe as @mame98 suggested have a flag for it. -p and --portable sound good to everyone?
( Personally, I don't at all mind adding command line flags! I think they're great and they're fairly trivial to implement. And they justify the man page I'm writing for micro. :) )

The priority I'm suggesting for finding config goes as follows:

1. If micro is run with the --no-config flag, alert user that their configuration changes will not be kept and run micro reading the default configuration from micro's internal files.
2. Look in micro's location for directory config if micro is run with the --portable flag or MICRO_CONFIG_HOME is set to %portable%. Create it and fill with default configuration on micro's first run with the portable flag. Issue a warning if micro cannot write to its current working directory and fall back to next config location.
3. If the --config flag is set and points to a directory that micro can find and the --portable flag is not set, then look in the directory set by --config and load configuration from there, or fall back if it cannot.
4. If MICRO_CONFIG_HOME is set and not %default% or %portable%, then treat it as a path and try to locate the specified directory. If it succeeds, load config. If not fall back.
5. If XDG_CONFIG_HOME is set, look there. If it's not set, fall back.
6. Look in/attempt to create ~/.config/micro and use that.
7. If none of the above are applicable/possible, look in micro's location for config or attempt to create it.
8. If all of the above fail utterly... print an error message that explicitly informs the user that their configuration cannot be found and settings changes will not be kept and then run micro anyway with the default settings read internally.

Also, if no configuration is found by the above (i.e. it's micro's first run for that user ), attempt to find and copy from /etc/micro. If it cannot be found then create the config from micro's internal files. ( Rationale: Distribution packaging as per the whims of Debian or Fedora, and to allow sysadmins control over the default behaviour of micro for all users without having to keep a ~/.config/micro/ in /etc/skel. As well as just general program convention for Linux. This will not affect OSX users or Windows users as if micro can't find /etc/micro it'll behave as it currently does. This will largely only be applicable for people who install micro by package instead of manually, but theoretically any sysadmin could just copy their micro configuration to /etc/micro to be used for this purpose. )

While I'm tinkering with this, there's also some directories micro should be making in its initial configuration setup. It's a bit confusing to have documentation referring to directories that are not there by default. I'll fix this.

Anyone have any issues with this proposal or suggested amendments?

[samdmarshall]

that seems overly complicated imo

[zyedidia]

I think it's best to just use MICRO_CONFIG_HOME.

If you'd like to implement this, it should be fairly simple. Here are some pointers:

There's a nice variable called configDir in the code, and it gets set in the InitConfigDir function. I recommend just checking if MICRO_CONFIG_HOME exists and if it does set configDir equal to it, and if not, do the little xdgHome logic that currently exists.

If you are using the MICRO_CONFIG_HOME I think it should be assumed that this directory already exists and therefore does not need to be created. If the directory doesn't exist maybe the best behavior is to spit an error message? Or maybe it should stay silent and just use default settings.

[GeigerCounter]

@zyedidia There are cases in which it's plausible that both MICRO_CONFIG_HOME and XDG_CONFIG_HOME would not be set and could not be set, and there's plausible use cases for having a search for the config directory in the same directory micro is run from. For instance, running on Windows from a flash drive while logged in as an unprivileged user. ( In other words, the "I'm at the library" use case. In that case, it may even be the case that micro would not be able to write to XDG_CONFIG_HOME if it found it, depending on just what sort of setup the library in question has. ) And again, looking in /etc/micro is useful for the reasons I've already listed.

Having a --config <path> flag is just standard open source convention ( inasmuch as that's a thing ) and is handy for all sorts of fringe cases.

You're absolutely right though, it's a little on the overcomplicated side. I'd be more than willing to implement it though. :) ( To be frank, if anything gets cut I think it should be looking in XDG_CONFIG_HOME, I was just going to leave that in for reverse-compatibility. )

[janlazo]

Would micro --portable --config foo/bar/path behave as micro --config foo/bar/path --config . where . is the current directory?
It ignores foo/bar/path and uses . as its runtime directory.

[samdmarshall]

I feel strongly that we should support XDG_CONFIG_HOME and a --config-dir flag. The use of XDG_CONFIG_DIR is a universal standard for command line tools to put their configuration files. If micro is unable to read or write to the directories provided it should supply an error message to the user then default to the built-in defaults (since this is one of the features of the editor). I think it is safe to default to using ~/.config if XDG_CONFIG_HOME is not defined in the env.

[zyedidia]

I agree with @samdmarshall although I don't see why --config-dir or the like is superior to an env variable. If you'd like to use a specific directory not attached to XDG then you can just export an env variable instead of having to re-alias micro to micro --config-dir dir. If neither MICRO_CONFIG_HOME nor XDG_CONFIG_HOME is defined then ~/.config/micro should be used (as per the XDG spec).

In the end --config-dir vs an env variable isn't a big deal.

[samdmarshall]

@zyedidia if we have both XDG_CONFIG_HOME and MICRO_CONFIG_HOME then i agree with not seeing a need for a command line flag to specify that.

[GeigerCounter]

@zyedidia Again, what if you're in an environment where you're not allowed to set environment variables? Besides that there's not really a benefit of --config-dir over an env variable. As for setting up an env variable, that'd be useful for more persistent redirects of the config search without having to specify --config-dir every time. So there's arguments to be made for both, but whether either is really necessary is more a decision for the end-user, imo.

As per using XDG_CONFIG_HOME, I disagree with @samdmarshall I think that because we're supporting Windows and theoretically any Linux config, including ones not related to X ( servers, Wayland, Mir, etc. ) we can't assume XDG_CONFIG_HOME is set. I'm sure it's probably set on Mac for legacy reasons specific to Mac, but ah, I think supporting it should be seen as a reverse-compatibility matter and treated as such, with higher priority going to either a --config-dir flag or MICRO_CONFIG_HOME. I still believe that the use cases are enough to support both, not to mention I don't believe the implementation and maintenance would be complex enough to give us a reason not to do so. ( It's the difference between about six lines of code we're talking here, so it's a far cry from bloat to support both. ) I already have the working knowledge to implement any and all of what I specified above and could work it in as a pull request, I'm basically just trying to figure out the implementation that works best for everyone.

@janlazo Yeah, that was what I was thinking would be best.

[samdmarshall]

@GeigerCounter if you have access to a terminal, then you should be able to run env MICRO_CONFIG_HOME=/foo/bar micro file.txt when you launch, thus being able to impact the set of environment variables. Also I strongly feel that "not being able to set environment variables" compared to "not having XDG_CONFIG_HOME" is a grossly incompatible comparison. The use of XDG_CONFIG_HOME is a universal standard. Additionally, as mentioned, if that is not set, we are proposing to default to the existing behavior of assuming ~/.config/micro/ (which on vast majority of systems would be the same location as $XDG_CONFIG_HOME/micro/). This change would have the smallest impact on existing usage.

The addition of a new command line flag would vastly increase the complexity of micro due to now having not only flags to set individual settings but also flags which cause conflict in the specific behaviors set by other flags. That is not desired and would make it harder to debug any future issues due to conflating two sets of conflicting options.

[janlazo]

@zyedidia Does micro support overriding everything discussed here with a lua script before init.lua runs such that I can manually adjust it in runtime? If not and --config-dir is not supported, then I can't rely on micro in cmd.exe for Windows. cmd.exe's home is C:\Windows\System32\ by default so Vim will be my only choice.

[GeigerCounter]

@samdmarshall What about Windows? Also, I wasn't aware that micro had the capability to set individual settings by flags. If anything, that seems to be the overcomplexity. Also, see janlazo's answer. Not everybody's running Mac or Linux. And not everybody is running standard Linux. It may be a "universal standard" for a subset of computers, but not for all of them. I still think it's worthwhile.

[zyedidia]

You can now use the --config-dir option to set the configuration directory.