bug#47048: dirtrack no longer parses long paths from prompt

[Thomas Walker Lynch via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Fedora 33,  emacs 27.1

Here are the dirtrack settings from .emacs, which is currently the
only thing in .emacs:

  (add-hook 'shell-mode-hook
           (lambda ()
             (shell-dirtrack-mode -1)
             (dirtrack-mode 1)))

  (add-hook 'dirtrack-directory-change-hook
            (lambda ()
              (message default-directory)))

  (setq dirtrack-list '("§\\(.*\\)§\n> " 1))



This matches the prompt, from .bashrc:

export PS1='\n$(/usr/local/bin/Z)\n\u@\h§\w§\n> '


The following is from a shell running in emacs (M-x shell).  It is  a three
line prompt, with the date, a path (which can be long) and then a simple
prompt for the command. It is used for logged transcripts.


2021-03-10T12:30:08Z
Morpheus@localhost§~/tmp§
> ls
old


We are in a temp directory under the home directory.  It currently has one
subdirectory called 'old'.  dirtrack correctly followed us here, as we can
tell from M-x pwd.  I create two more directories, one with a short name,
and one with a long name.


2021-03-10T12:30:10Z
Morpheus@localhost§~/tmp§
> mkdir aaaaaa

When I cd to this short name directory, dirtrack follows.  Then I cd back
up, and dirtrack follows.

Now I make a directory with a long name.  When I cd to it, dirtrack does
not follow. Not only that, but it takes emacs back to the home directory.


2021-03-10T12:30:27Z
Morpheus@localhost§~/tmp§
> mkdir bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb


Note, in actual use, rather than just a simple test case, the long names
are paths made of many short directory names. These paths are important for
understanding the transcripts later.

I guess this problem started with an update to Fedora 33, as have many
other problems unrelated to emacs.   However, I can not be sure because of
the nature of the problem, only showing up with long path names.  It might
have come with a more recent package update.

It is also possible this has something to do with regular expression
matching.  Due to the syntax of newling matching being different in regular
expressions that are typed at emacs prompts such as M-x replace-regexp I
could not copy paste to test, but when making the suitable edits, the
regexp replace worked with the same strings as shown above.

I am at a bit of a disadvantage, as this has worked for years, and I
haven't looked at elisp in a long time.  I certainly apologize if I missed
a variable setting or missed something else simple.

See also:
https://pastebin.com/ptpUn8Pc
https://imgur.com/a/Tft2krX
https://imgur.com/a/FAD7EwJ

Thomas

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