> Could you prepare a patch for both these
> issues?  (It's safer if you do it so that you can verify that things
> work fine after the change (since you already have a test case).)

Please find attached. I added comments for both changes that explain the
reasoning, so that they are not accidentally reverted by a later change.

Also replaced obsolete `find-function-source-path' with its new name
`find-library-source-path'.

Paul

On Sat, 23 Jul 2022 at 10:30, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Paul Pogonyshev <pogonyshev@gmail.com> writes:
>
> > 1. Function excludes package's current directory, see variable
> > `load-path-sans-dir'.  This is problematic if a package is reinstalled
> > from the same directory after changes have been made. I know this is
> > not how things usually work, but it seems to create problems for no
> > reason: if the same directory is never used, why bother about it here?
> > Normal usecases are not affected at all, why "special" usecases that
> > reuse the same directory suffer.
>
> Yes, that seems odd.
>
> > 2. When searching in `load-history', the function ignores changes from
> byte-compiled
> > to source and vice versa, i.e. `.el' -> `.elc' and `.elc' -> `.el'. In
> other words, if you
> > replace a byte-compiled file with a non-compiled (or vice versa), it
> never gets
> > reloaded. A simple fix (having zero effect in normal usecases) would be
> e.g. this:
> >
> >         (truename (file-truename canonical))
> >         (found (or (member truename history)
> >                    (member (if (string-suffix-p ".el" truename)
> >                                (replace-regexp-in-string (rx ".el" eos)
> ".elc" truename t)
> >                              (replace-regexp-in-string (rx ".elc" eos)
> ".el" truename t))
> >                            history)))
> >
>
> I think that makes sense.  Could you prepare a patch for both these
> issues?  (It's safer if you do it so that you can verify that things
> work fine after the change (since you already have a test case).)
>
>