bug#76165: [PATCH] ansi-osc-directory-tracker respects Tramp remote files

[Ship Mints]

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.