GNU bug report logs -
#74524
29.4; dirtrack-mode
Previous Next
Full log
Message #41 received at 74524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I also default my shell to bash. I might look into wezterm to see if I can
get it working with that one. Thanks for the tip about buffer local
On Tue, Nov 26, 2024 at 7:00 AM Ship Mints <shipmints <at> gmail.com> wrote:
> 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 <at> 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 <at> gnu.org> wrote:
>>
>>> > From: Colton Goates <coltongoates <at> gmail.com>
>>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>>> > Cc: 74524 <at> 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?
>>>
>>
[Message part 2 (text/html, inline)]
This bug report was last modified 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.