Maybe we ask Augusto Stoffel what he had in mind with his URL handling
approach to begin with? It's been in the code for something like 5 years.

On Mon, Feb 10, 2025 at 9:11 AM Visuwesh <visuweshm@gmail.com> wrote:

> [திங்கள் பிப்ரவரி 10, 2025] Michael Albinus wrote:
>
> > Visuwesh <visuweshm@gmail.com> writes:
> >
> > Hi,
> >
> >>>>     (concat (file-remote-p default-directory)
> >>>>             (url-unhex-string (url-filename url)))
> >>>
> >>> Looks like, yes :-(
> >>>
> >>> Since I don't know how to activate ansi-osc-directory-tracker in a
> shell
> >>> (where is it documented?), I couldn't test it. Could you pls advice me?
> >>
> >> The documentation is spread over two places:
> >>
> >>     1. Docstring of `ansi-osc-directory-tracker' tells how to set up
> >>        things from the shell side.
> >>     2. You need to add `comint-osc-process-output' to
> >>        `comint-output-filter-functions' (as the commentary following
> >>        comint.el:3998 instructs you to).
> >
> > I've fixed ansi-osc-directory-tracker as described above, and started a
> > test as given in the recipe. Testing on a remote host, different from my
> > local one.
> >
> > There is the following code in ansi-osc-directory-tracker:
> >
> >     (when (and (string= (url-type url) "file")
> >                (or (null (url-host url))
> >                    ;; Use `downcase' to match `url-generic-parse-url'
> behavior
> >                    (string= (url-host url) (downcase (system-name)))))
> >       ...
> >
> >
> > But on the remote host, neither (null (url-host url)) nor (string=
> > (url-host url) (downcase (system-name))) return t; simply because the
> > host name is not nil or equal to (system-name).
> >
> > Instead, the following shall be sufficient:
> >
> >     (when (string= (url-type url) "file")
> >       ...
> >
> > Comments?
>
> That reminds me why my :override advice was simpler.  Indeed, I had to
> get rid of that test to ensure that the function would work as intended
> for remote shell buffers.  It never made much sense IMO and I got the
> impression that it is in place as a "let's be absolutely sure" measure.
> I can say that I face no issues with the test omitted thus far. It could
> be a product of me being in control of $PS1 for local and remote shells
> though.
>
> > Best regards, Michael.
>