Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoload behavior update #1991

Open
robertmeta opened this issue Apr 5, 2018 · 12 comments

Comments

Projects
None yet
7 participants
@robertmeta
Copy link

commented Apr 5, 2018

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.

@mawww mawww added the design label May 9, 2018

@MarSoft

This comment has been minimized.

Copy link

commented Aug 12, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2018

@andreyorst

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 24, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2018

Related discussion about autoload : #1399

@andreyorst

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2018

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

This comment has been minimized.

Copy link

commented Apr 8, 2019

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 dupilcate 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

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

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

@andreyorst

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

I guess after merging #2772 this can also be closed

@robertmeta

This comment has been minimized.

Copy link
Author

commented May 15, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 15, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.