Re: New branch 201906

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2019-06-17 16:12, Katsumi Yamaoka wrote:
> I made a new branch named `modernize201906' mainly to drop old
> Emacsen and XEmacs support.  Now it supports Emacs 25,26 and 27.

Wow. Great! I now only took an initial look and you're understating the
amount of work that you did. For example, you are refactoring to use
cl-lib (I had thought that in the past any use of any cl was avoided),
you updated a lot of documentation and attic stuff. What's the current
policy on cl-lib - is it preferred over elisp? This could have great
consequences throughout the code-base.

> It doesn't necessarily mean to make it fast but clean the code.

Anything to clean and document the code is great. Am I reading the log
correctly that its all squashed into a single commit?

> Still uses lexical-let, using the lexical-binding would be the
> next step.

Phenomenal. Great to here that's coming.

>  Testers are welcome.

This is an excellent example for an idea I've been suggesting a few
times over the past few months, about creating a 'testing' branch for
the purpose of MELPA users and others willing to evaluate new code. You
have a branch that covers modifications spanning many files and
functions, and you want to as many people worldwide to test it, and
those people are probably out there, but they need to find out about it
and it should be easy to install and keep up-to-date. If you create a
'testing' branch and maybe also an 'unstable' and 'experimental' branch,
you can incrementally stage to those branches your modernization
branches and other pull requests (ahem). Melpa users would then see the
new options when they refresh their package lists (it may still take
some time initially), choose what meets their style, and then be able to
easily get updates when bugs are fixed.

Please give thought to "out-reach" to publicize current events in the
project and get more people involved, in this case as testers. For
example, I'm involved in the project, but am busy developing and testing
other things, and there is only so much any single person can do in the
time that they set aside to contribute to free software. Currently, the
only people who will read your invitation to test are those who have
taken the extra step of subscribing to the mailing list.

> Note that you may want to do `git fetch' to check out the branch.

Done.

> The new w3m-download implementation ([emacs-w3m:13326]) is added
> as a makeshift until the improved w3m ([emacs-w3m:13327]) comes.

Does it now handle resumption of interrupted downloads, like my
wget-based version does? It would have been better to have split the
commits between the modernization and the download; someone like andres
ramirez who performs a lot of downloading might be interested in testing
the download patch, but not necessarily get involved in testing an
project-wide refactor.

> Tested and tweaked the code so that `make slow' with Emacs 25.1,
> 26.1, 26.2.90, and 27.0.50 may issue no warning.

???

> In [emacs-w3m:13457]
> On Mon, 17 Jun 2019 16:12:26 +0900, Katsumi Yamaoka wrote:
> > Tested and tweaked the code so that `make slow' with Emacs 25.1,
> > 26.1, 26.2.90, and 27.0.50 may issue no warning.
>
> Sorry.  Not `make slow' but `make very-slow' that compiles the
> .el files one by one individually.

Still don't understand, but I'm not certain its important. It's so nice
to read this development and have the prospect of the cleaner code
coming soon to the master branch.

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