bill-auger <bill-auger@peers.community> writes:
> the emacs mode is in the smalltalk source tree because it is distributed
> and installed with the smalltalk software, so that all users of the
> smalltalk software will have, it without the need for installing a
> separate package or package manager - for that reason there is little
> need to package it elsewhere
AFAICT as it currently stands, installing GNU Smalltalk will indeed
install a copy of smalltalk-mode.el (and smalltalk-mode-init.el)
somewhere, but the user will still have to manually load that file
(typically from the ~/.emacs after reading some README to figure out
exactly what to put in there). In contrast a package installed via ELPA
will automatically be activated so the user will have smalltalk-mode
enabled in *.st files without needing any extra steps. Of course the
`M-x package-install` is itself an extra step (tho there's been
discussions to try and eliminate this and pre-enable some ELPA packages,
so that for example opening a *.st file would suggest to the user to
install smalltalk-mode if not done yet).
So there is some extra convenience there for users.
For the developer, there can also be some benefits in that it's much
easier to use other packages in your own package (because you don't need
to tell your users to install that other package and/or handle the case
where that other package is not available: you just add it as
a dependency). But I don't think smalltalk-mode maintainers would
benefit much from this.
> from what i understand, derek was proposing that this would be useful
> for people who are reading gnu-smalltalk code, but for some reason do
> not have smalltalk actually installed - IMHO that use-case is
> minuscule at most;
That use-case seems minor, indeed. Maybe there can be other use-cases
for people using some other Smalltalk system, tho IIUC other Smalltalk
systems don't keep their code in files that you could conveniently edit
with Emacs anyway.
> generally speaking, the upstream software developers do not engage in
> the packaging of their own software - even if they wanted to, there are
> simply too many package managers to package for - if the software gets
> packaged at all, that is usually done by someone else who is not
> associated with the upstream dev team, but someone who is associated
> with the repository for that particular package manager, or one of it's
> users
elpa.git is not a "packaging solution". It's a Git repository that is
meant to be used for development and also happens to have packages
automatically built from it, but most of the work of packaging is
delegated to the maintainer because there is "packager" as such.
> in this case, i think this is literally a single file - the humble
> `curl` command is sufficient for pulling in the latest version - i will
That won't preserve the Git history, so I was thinking more of a `git
filter-branch`. Also, some Emacs developers will occasionally install
patches into the elpa.git side (e.g. to fix incompatibilities with newer
Emacs features, or clean up compiler warnings, ...), so the sync needs
to be 2-way.
Anyway, from what I understand, you have no intention of moving
smalltalk-mode.el elsewhere nor to spend your time with a 2-way sync.
In that case, I think it's best not to add smalltalk-mode.el to GNU ELPA
to avoid the risk of a fork.
Stefan
_______________________________________________
help-smalltalk mailing list
help-smalltalk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-smalltalk
