Re: plugin conventions (Re: off topic)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 14,  1:40pm, Oliver Kiddle wrote:
} 
} It's certainly an option to take an existing plugin manager and without
} having looked into any of them, I would tend to assume that Sebastian's
} is the best. It is also clearly very feature rich.

He does appear to have taken the practices of a number of other more
rudimentary plugin managers into account as well as going to a lot of
effort to shield plugins from each other.

} I used the wording "rudimentary plugin manager" because what I had
} in mind foremost is standardising the conventions. A basic reference
} implementation helps with documenting that and determining what issues
} there might be. But perhaps that's already known.

If there's anything Sebastian hasn't thought of yet, I haven't thought
of it either :-) but then again I missed "printf -" for a year.

} For example, I seem
} to remember something about the various frameworks causing compinit to
} be run multiple times. A pure plugin manager has no business running
} compinit even once

The plugins themselves were running "compinit" to force their supplied
completion files to be found after updating fpath.  The manager resolves
this by adding a dummy compinit that queues up all the other attempted
runs until the user is ready to ask for them.

} > Although the idea with this particular file was simply to fold it in to
} > compinit.
} 
} default_zstyle() doesn't prevent it altering an existing user's setup so
} unconditional inclusion might be a problem.

That's true, though it avoids altering any directly conflicting setup.
We'd want a way to ask that the defaults not be included, just like we
have a way to skip "compaudit".