Breaking change just arrived to luar

Hi, everyone!

I’ve just committed a very small but breaking change to the luar plugin. Now it defines a luar module and the lua command is wrapped inside it. So, everyone using it must update kakrc, adding the following line:

require-module luar
1 Like

If people are going to require a module immediately at startup, why bother putting it in a module at all?

3 Likes

I think, it is a good idea, to put plugins in modules, because maybe not everyone wants to load it at startup. And if you’ve got some other commands that should be run at startup and depend on luar you can put these commands in a ModuleLoaded hook, so that they get executed, when luar is loaded.

3 Likes

Yes.

Actually, if it’s to decrease the load time, Kakoune would anyway need to read the file, although the module would be read as a big string. Otherwise, it’s a matter of using source when necessary. The only benefit I’d see is to hide the declared commands when you don’t want to pollute your prompt.

Since other plugins might depend on luar I think this is good idea.

Hi, @Screwtapello!

Good question! And I should have addressed it in the announcement.

I decided to put luar inside a module mainly as a convenience to the user. It’s true that it seems to be just an additional unnecessary burden having to put a require-module in the kakrc, but there are advantages. I’m mainly thinking about users that don’t use a plugin manager and just put the plugins inside the autoload directory. For those, wrapping a plugin inside a module brings the following benefits:

  1. One can easily temporarily disable a plugin by just commenting out a single line. From time to time I’m confronted with a situation in which something breaks in my editor and it’s not obvious where the error is comming from. I had to deal with such a situation a lot when I was using Vim, but it can also happen in Kakoune. Then, being able to disable all plugins but one is handy to find the origin of the bug.

  2. As @listentolist said, it’s good for declaring dependencies: if a plugin author has a dependency on another plugin at startup, she can just put the necessary dependencies in a ModuleLoaded hook. And, since luar can be used as a library for other plugins, it seems to be a good idea.

  3. Declaring dependencies is also useful for the end user. If, for instance, she writes a script inside her autoload that depends on luar being already loaded, she can just listen to the respective ModuleLoaded hook.

2 Likes

Hi @gustavo-hms. It is true what you say about dependencies. I haven’t considered that case myself, but it’s true that this plugin is particularly prone to be depended upon.

But for your first point, if you don’t put it in a module then the user can decide between putting it in their autoload or in a different folder and writing source instead of require-module, in which case they can also comment that line.

1 Like