bug#74524: 29.4; dirtrack-mode

[Ship Mints <shipmints@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Check that your default shell supports the function. I understand later
macOS defaults to zsh which I have no experience with. I use macOS but I
default my shell to bash. If you have an alternate terminal like
Wezterm you could verify your shell settings there
https://wezfurlong.org/wezterm/shell-integration.html#osc-7-escape-sequence-to-set-the-working-directory

As far as your osc filter goes, I think it would be better to install it
buffer-locally in a shell-mode-hook so you don't interfere with other
comint uses.

  (defun my/shell-mode-hook ()
    (shell-dirtrack-mode -1)
    (add-hook 'comint-output-filter-functions #'comint-osc-process-output
nil 'local))
  (add-hook 'shell-mode-hook #'my/shell-mode-hook)

On Tue, Nov 26, 2024 at 3:16 AM Colton Goates <coltongoates@gmail.com>
wrote:

> I don't know how dirtrack would tell the difference between a prompt
> output and other printed output. I just thought of the edge case and
> decided to point it out in case someone knew of a solution. Thanks for
> responding.
>
> On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Colton Goates <coltongoates@gmail.com>
>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>> > Cc: 74524@debbugs.gnu.org
>> >
>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>> to be a directory name, it's a string
>> > that's intended to look exactly like my prompt. (I know it's pretty
>> contrived.)
>> >
>> > So, if someone prints something that resembles their prompt, dirtrack
>> will change the directory, because
>> > dirtrack thinks it just saw the shell prompt appear, but it really just
>> saw a string that resembles the prompt.
>> > Does that make more sense now?
>>
>> What do you expect dirtrack to do when you deliberately try to deceive
>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>> in its commentary), so it cannot be expected to survive such
>> deception.  What kind of changes would you suggest to consider to
>> handle the cases such as this one?
>>
>

[-- Attachment #2: Type: text/html, Size: 3342 bytes --]