Autoload behavior update

[robertmeta]

Currently (2018-04-05) creating an autoload directory under your config directory disables the default autoload folder. I understand this behavior was decided after much debate, but I believe it should be reconsidered.

The current solution is to symlink to the kakoune autoload folder to re-enable autoloading of core scripts. This is generally a really good idea because things like doc, ctags, autowrap, language support/syntax highlighting, grepping, linting, make, diff, and man are only functional when you allow the default autoload directories to be loaded.

I do not think that most people intend to disable all the above listed features by creating an autoload directory, in most cases I suspect people simply want to install a plugin to extend kakoune. As more important functionality is added to those folders, the importance of them not being accidentally disabled goes up. This dovetails with the growth of the plugin ecosystem. I think those who want exclusive behavior are the 1% and we should strive to solve for the 99% first and let the extreme power users read the documentation (which they can because we made sure :doc was loaded!).

So, what are possible solutions and concerns?

Solutions:

• The first sort of obvious solution is redefining the behavior of autoload to be run after the system default autoload. This would require a new directory like autoload-exclusive for users wanting the old behavior.

Concerns:

• This will break a lot of configs in the wild, because it will double source scripts. A possible solution is a module system.

[MarSoft]

One possible fix to double-loading concern would be to add a module to the default autoload dir which, being loaded twice, would report an error with a description what to do (possibly reference to doc). But it won't help for users who chose to symlink to individual scripts rather than the whole default directory.

[alexherbo2]

How about:

1. Extracting the auto-load functionality in a source-recursive command.

2. Consider a single configuration entry-point.

run-time/kak-rc

if user/kak-rc
  source user/kak-rc
else
  source-recursive run-time/auto-load/
end

user/kak-rc

source-recursive run-time/auto-load/
source-recursive user/auto-load/
source-recursive site/user/project/

Instead of the current opt-in logic:

if user/auto-load/
  source-recursive user/auto-load/
else
  source-recursive run-time/auto-load/
end

if user/kak-rc
  source user/kak-rc
end

[alexherbo2]

https://github.com/alexherbo2/pathogen.kak

[andreyorst]

can't double loading issue be fixed with addition of variables that act like load guards? (similar to include guards in programming languages like C). The same idea is widely used in vim's plugins - each defines a did_(auto)?load_plug_name variable, so it won't be reloaded if vimrc gets resouced:

if exists(g:did_autoload_plug_name)
    finish
endif
let g:did_autoload_plug_name = 1

Can't the same trick be done in .kak file via hidden options?

[robertmeta]

@andreyorst we discussed the briefly on IRC -- obviously it is absolutely doable, but it would be great if there was a cleaner way that might handle existing scripts without specific updates.

[Delapouite]

Related discussion about autoload : https://github.com/mawww/kakoune/issues/1399

[andreyorst]

but it would be great if there was a cleaner way that might handle existing scripts without specific updates.

Well, I've implemented such functionality in my plugin manager. It doesn't load plugins twice anymore, so I can resource my kakrc any time. However I used another solution previously. In my scripts I've used -override switch, which allowed my to reload any script any time. Is it a bad practice? I'm still using it in plugin manager, because this is the only plugin that can't be loaded only once.

[MatthewScholefield]

With regards to the opt out, what about having a special init file or something that gets loaded first and can set some disable_system_config option?

With regards to duplicate files, for symlinks each script could be hashed by its real path. However, users who used cp -R /usr/share/kak/autoload ~/.config/kak/autoload would still have a problem. To solve/improve that problem, the contents of each script could be hashed to disregard duplicates and display a warning that there may exist some copied system scripts in the user config. Alternatively, a new folder name could be chosen and the old one would retain the same behavior for some time.

[andreyorst]

what about some scripts that considered "core" scripts and are loaded always and everything else is lazy loaded. Emacs does this

[andreyorst]

I guess after merging #2772 this can also be closed

[robertmeta]

@andreyorst I fear I misunderstood #2772 then, it provides a tool that could be used to fix this but doesn't yet fix it right?

[andreyorst]

oops, for some reason I've thought that this is about lazy loading autoload dir

[SeerLite]

What about an override folder?

~/.config/kak/override/
├── grep.kak
├── python.kak
└── x11.kak

Or more verbose:

~/.config/kak/override/
├── filetype
│   └── python.kak
├── tools
│   └── grep.kak
└── windowing
    └── x11.kak

The files can be empty if the only goal is to disable their original.

At a quick glance I think something like the first example could be implemented with a list of the original files that's then grep -v'd against the ones found in override, which get loaded afterwards. What do you all think?

[lenormf]

Some users use autoload to avoid having the editor read dozens of files that support languages/features they have no interest in at runtime — not just to modify the behaviour of some scripts.

Unless there was a mechanism that would instruct the editor exactly what to load (or where to load everything from, i.e. the path to the runtime directory), it'd be a regression to change how autoload works.

[SeerLite]

Yeah I understand. I still would like some changes to how autoload works though. This is the only (user-level) program that I know of that has this "quirk" where creating a folder overrides the same runtime-dir folder/behavior. In my eyes this is something unexpected and goes against Kakoune's own design goal of being simple and predictable.

IMO this should be configurable in some explicit way. I even think going the zsh way and adding a .kakrc.pre (config before sourcing autoload) would be a good idea.

Currently I can't really use autoload at all because I can't sync it in my dotfiles to other devices. The symlinks break between my Linux and Termux devices (having a %val{runtime} expansion doesn't help if I have to hardcode the locations externally anyway).

Edit: I also think using text configuration for which default files are loaded/overriden is a lot better than handling symlinks one-by-one or relying on the filesystem. I know this is a subjective thing though