[emacs-w3m:13367] Re: reload twice with minimal (?) example and 'emacs -q'

On 2019-04-19 00:53, Emanuel Berg wrote:
> OK, is it encouraged to get Emacs-w3m from MELPA rather than the
> repos?

I personally would encourage it, but that's not an official answer from
the project nor from debian. The theory behind preferring the debian
packaging is that the specific builds / versions: 1] have been tested by
debian for reliability, inter-operability, and security, and; 2] can be
updated auto-magically when debian feels it's desirable. OTOH, MELPA is
kind of a free-for-all in that there doesn't seem to be any scrutiny of
pacakges by MELPA, so you need to trust each developer of each package,
and you need to decide how / when / what to upgrade. In the particular
case of emacs-w3m, the current situation is that the MELPA version is
programmed to be updated for each and every single commit to the
emacs-w3m master branch.


> I have always used the repos for Emacs-w3m in particular. It is the
> only "non-Emacs Emacs" stuff I get from there, BTW, not that I expect
> there to be a whole lot of other things around...

The debian emacs team has actually been very active recently, and have
been making changes to their policies and packaging formats. I haven't
been following the details, and would like to find a single document or
web page that describes the changes. As of today ...

  $ apt-cache search elpa- | wc -l
  299

> w3m  20190415.228  available  melpa      an Emacs interface to w3m
> (BTW what does .228 mean? Surely there weren't 228 commits that day?!)

Don't know. I ought to look and find out.

> I have 1.4.569 which is from the w3m-el-snapshot package which has the
> complete package version number 1.4.569+0.20170110-1
>
> So there is a difference [1] of, holy socks!
>
>     2y 3m 5d (825d)

Do yourself a favor and skim the Changelog in order to get an idea of
all the differences since then. The project hasn't been issuing
'press-release' style notices of new features and improvements, so the
Changelog file is probably the best resource.

> But that's not the end of it. The w3m-el Debian package w3m-el has
> Emacs-w3m/package version 1.4.538+0.20141022-5, so the time difference
> here is (hold your breath)
>
>     4y 5m 24d (1636d)
>
> man(1)! Perhaps you should ditch the repos approach?

That's really a decision for each distribution to make for itself. It's
the distribution that decides when to update its version in its
repositories.

I would like the project to consider moving to a multi-branch release
process, in which the project would have branches *master*. *testing*,
*unstable*, and any number of *experimental* branches. The project would
normally accept reasonably looking pull requests into *unstable*, move
them into *testing* as they appear validated by testing and use, and
then migrate into *master* as a tagged release commit when the project
is certain about their stability. Melpa could then be set up to have
separate packages pointing to each of the branches, for each user to
make their own risk/benefit decision. The *experimental* branches
would be reserved for pull requests that proved buggy, but that showed
enough promise, active interest, and active development to not be
discarded.

> Or is the software actually not that old?

It is... Look, in the big picture, the emacs-w3m software has been
'working' great for ~20 years, but yeah, there have been many commits
since the snapshot, and new features. The way to get an exact number
would be to count the lines of `git log --pretty=oneline` back to the
release tag, but I haven't succeeded in identifying it (eg. `| grep
'1\.4\.'`).

> And what happens with the repos installation if I install it from
> MELPA? Does it make sense to purge it first?

Short answer: yes

Longer answer: The theory is that emacs will only look as far as the
first instance found in its `load-path', which *should* mean that your
personally-installed and melpa-installed packages should have priority
over the system-wide debian installed packages. For a system that you
control and curate, it becomes a decision for you to make, based upon
the varying needs of each of your user accounts.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0