GNU bug report logs - #74524
29.4; dirtrack-mode

Previous Next

Full log

View this message in rfc822 format

From: Colton Goates <coltongoates <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 74524 <at> debbugs.gnu.org
Subject: bug#74524: 29.4; dirtrack-mode
Date: Tue, 26 Nov 2024 11:05:57 -0700

[Message part 1 (text/plain, inline)]

I was referring to the bizarre edge case of a printed edge case that
matches your regex. In that case, it will confuse the two. But like you
said, OS7 is the way to go. I'll just try to get it working

On Tue, Nov 26, 2024 at 7:46 AM Ship Mints <shipmints <at> gmail.com> wrote:

> You can customize dirtrack-list to a regexp that can detect your prompt
> format. I'd still recommend using osc 7 support, though, as it's precise
> (once you get it working) and tracking pushd popd cd, parsing your prompt,
> etc. is not necessary.
>
> 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)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.