bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun

[Phil Sainty <psainty@orcon.net.nz>]

On 2021-09-19 18:36, Arthur Miller wrote:
> My question is though, why it happens only with 'when'? I haven't
> found any other form to show same behaviour. There probably are
> some, I just haven't found them by manually testing.

Now that you've narrowed this down to a code conversion issue, that
part was simple to debug (by comparing the buffer in its literal and
non-literal forms), and the reason is that subr.el contains multi-byte
characters.  This included a documentation bug, as the docstring for
`setq-local' had this paragraph in the source:

     The second VALUE is not computed until after the first VARIABLE
     is set, and so on; each VALUE can use the new value of variables
     set earlier in the ‘setq-local’.  The return value of the
     ‘setq-local’ form is the value of the last VALUE.

Note the incorrect unicode quote characters.

I've just pushed a fix for that, but there's also a more intentional
INVERTED EXCLAMATION MARK unicode character in one of the comments,
though, and I've left this alone.

     ;; ¡Beware! when I tried to edebug this code, Emacs got into a weird 
state
     ;; where all the keys were unbound (i.e. it somehow got triggered
     ;; within read-key, apparently).  I had to kill it.

In short, you don't want to be making assumptions about the encoding
of elisp files.

Tangentially, the commit message related to those quote characters
says "expand the doc string by taking some text from `setq'", so I
believe those fancy unicode quote characters were accidentally copied
and pasted from a *Help* buffer rendering of the `setq' docstring.
I think it's a good idea to set `text-quoting-style' to 'grave to
ensure that can never happen.


-Phil