On Sun, Jan 3, 2016 at 3:26 PM, Artur Malabarba <bruce.connor.am@gmail.com> wrote:

Ken Manheimer <ken.manheimer@gmail.com> writes:

> I'm about to push a multishell as a new packge in the git.sv.gnu.org:

Thank you!

My pleasure!

> One coding wrinkle worth mentioning - I prefixed most of my package's
> functions with "multishell:"

Please change it to “multishell-”. It will work nicer with the customize
interface.

> did not prefix the primary function, "pop-to-shell". I see that as
> the package's exported api. I do not feel strongly bound to this
> choice, and can be persuaded to also prefix it if someone feels there
> is good reason to do so.

The current convention is to use multishell-pop-to-shell. This includes
user stuff (like commands and customization variables) as well as
programatic stuff that you consider “official api” (like functions that
other packages can call, or vars that can be configured but aren't
defcustoms).

In order to differentiate the functions and vars that are NOT
“exported”, use a double-dash (e.g. `multishell--bracket-asterisks').
(This is a relatively new convention, which is why a lot of places don't
use it).

Ok - I've done all this, but also changed my version number to 0, in order to defer release.

This deferral is not due to any of these changes, but rather because I discovered a change I want to make to the way I organize how remote shells are expressed, and I need to shake the change out before it's ready. I don't want anyone to get used to the old syntax, hence the release deferral.

It's been helpful, though, to shake out the release format with your and other's help - thanks for that! I hope it's not inopportune for me to defer the actual release after getting the code situated (and I welcome further suggestions for making multishell a good ELPA citizen).

Ken