Re: error upon load and tab navigation [PATCH included]

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2017-07-10 18:16, Katsumi Yamaoka wrote:
> In [emacs-w3m : No.12732]
> On Mon, 10 Jul 2017 01:36:43 -0400, Boruch Baum wrote:
>
> > 1] For I don't know how long, I've been getting the following errors
> >    logged to my *Messages* buffer when loading emacs-w3m via M-x w3m,
> >    and when tabbing through links / forms / images on a page.
>
> >   #+BEGIN_SRC conf
> >   w3m-replace-in-string: Wrong type argument:
> >   arrayp, nil Error in post-command-hook (w3m-check-current-position):
> >   (wrong-type-argument arrayp nil)
> >   #+END_SRC
>
> `w3m-check-current-position' runs `w3m-after-cursor-move-hook'
> in which these functions are listed by default:
>
> w3m-highlight-current-anchor
> w3m-show-form-hint
> w3m-print-this-url
> w3m-auto-show
>
> Is it possible to know what function calls `w3m-replace-in-string'
> with a non-string argument?  Well, I think the following function
> definition will reveal it if `debug-on-error' is t.
>
> (defun w3m-replace-in-string  (string regexp newtext &optional literal)
>   (or regexp newtext string (error "XXX"))
>   (replace-regexp-in-string regexp newtext string nil literal))

I did that work while tracing the problem for the patch. The culprit
is `w3m-print-this-url', ie. remove it from the hook list, and the
issue disappears.

>
> > 2] In the attached patch, please notice that I also removed a check
> >    for the existence of function `replace-regexp-in-string' and
> >    removed an option to alias a command to function
> >    `replace-in-string'.
>
> Emacs-w3m hasn't officially dropped the XEmacs support yet, so
> we cannot remove `replace-in-string'.
>
> xemacs-21.4.24 -batch -q -eval\
> '(message "%s" (fboundp (quote replace-regexp-in-string)))'
>  => nil
>
> >    My guess is that code was written at some point in the ancient past
> >    before `replace-regexp-in-string' became a standard part of emacs,
> >    and when there did exist a function called `replace-in-string'.
> >    That hasn't been the case since at least four years[1].
>
> That's right.  Emacs-w3m followed in Gnus' foot steps.  But Gnus
> dropped the XEmacs support and `gnus-replace-in-string' was marked
> obsolete in Emacs 26.  I have no objection on dropping it even if
> I have a nostalgia on XEmacs (the tab-browsing feature of emacs-w3m
> has started with XEmacs ;-).
>
> > 3] There are several cases similar to #2 above in `w3m-util.el' for
> >    which I'd be happy to provide patches if you agree that this is
> >    desirable. Some examples:
>
> Before staring those works, we have to decide what versions of
> Emacs (and XEmacs, SXEmacs ...) that emacs-w3m should support.

My opinion is that in the long run it's in the 'engineering economics'
interest of all these emacsen and add-on projects to be as standard
and as lean as possible, so if the 'center of gravity' of the emacs
world has clearly favored obsoleting the functions, I would say this
project should stop supporting them, as an incremental nudge to
XEmacs, SXEmacs, etc. to tweak their API. My thinking is like this:
For the XEmacs, SXEmacs teams to make the change involves minor
changes to two code-bases (and each can choose to obsolesce the
functions in the interest of simplicity, or choose to keep both
versions of the functions in the interest of maximum compatability).
On the other hand, there are "zillions" of emacs packages, and asking
all those development teams to maintain code forks for all emacsen is
imposing much more effort over a much larger population. It seems to
me fairness favors imposing the work on the emacsen teams, especially
since on their side its minimal.

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