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

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]

[-- 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 --]

bug#47048: dirtrack debug mode log

[Thomas Walker Lynch via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 19 bytes --]

[image: image.png]

[-- Attachment #1.2: Type: text/html, Size: 192 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 80978 bytes --]

bug#47048: dirtrack debug mode log

[Thomas Walker Lynch via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]

This code ran for years before it stopped working recently, and it doesn't
look like the dirtrack.el code has changed either, but I could be wrong
about that, the comment says the variable has not changed since 24.1.
Unfortunately,  Fedora 33 will not allow me to use dnf to go to an older
release for emacs.  It  says that the one used now is the only package for
emacs for F33.

I see in the dirtrack.el comments that a third prompt of t should be added
for a multi line prompt.  I have added that.  It made no difference.  There
are some good examples in the comments.  The prompt used for this bug
report is much like their solaris example.

The dirtrack.el mentions regular expression groups as the second argument.
It is set to 1.  I do not know what that is referring to.  In any case, it
does not look like the dirtrack-list is the problem.

Rather it looks like the problem is that the input to (defun dirtrack
(input)) is being limited to 48 chars.  It is not difficult to find paths
on this system that exceed 44 chars in length (plus the prompt sugar).
 Where is this limitation imposed?  Is there a variable for it somewhere?
It is disappointing that the regular expression match has a maximum length
to trip on at all.




On Wed, Mar 10, 2021 at 3:17 PM Thomas Walker Lynch <
thomas.lynch@reasoningtechnology.com> wrote:

> [image: image.png]
>

[-- Attachment #1.2: Type: text/html, Size: 1989 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 80978 bytes --]

bug#47048: dirtrack debug mode log

[Thomas Walker Lynch via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1865 bytes --]

from dirtrack.el:
  (if dirtrack-mode
      (add-hook 'comint-preoutput-filter-functions 'dirtrack nil t)

M-x describe-variable
comint-preoutput-filter-functions is a variable defined in ‘comint.el’.
Its value is (dirtrack shell-filter-ctrl-a-ctrl-b t)
Local in buffer *shell*; global value is nil


On Wed, Mar 10, 2021 at 4:04 PM Thomas Walker Lynch <
thomas.lynch@reasoningtechnology.com> wrote:

> This code ran for years before it stopped working recently, and it doesn't
> look like the dirtrack.el code has changed either, but I could be wrong
> about that, the comment says the variable has not changed since 24.1.
> Unfortunately,  Fedora 33 will not allow me to use dnf to go to an older
> release for emacs.  It  says that the one used now is the only package for
> emacs for F33.
>
> I see in the dirtrack.el comments that a third prompt of t should be added
> for a multi line prompt.  I have added that.  It made no difference.  There
> are some good examples in the comments.  The prompt used for this bug
> report is much like their solaris example.
>
> The dirtrack.el mentions regular expression groups as the second
> argument.  It is set to 1.  I do not know what that is referring to.  In
> any case, it does not look like the dirtrack-list is the problem.
>
> Rather it looks like the problem is that the input to (defun dirtrack
> (input)) is being limited to 48 chars.  It is not difficult to find paths
> on this system that exceed 44 chars in length (plus the prompt sugar).
>  Where is this limitation imposed?  Is there a variable for it somewhere?
> It is disappointing that the regular expression match has a maximum length
> to trip on at all.
>
>
>
>
> On Wed, Mar 10, 2021 at 3:17 PM Thomas Walker Lynch <
> thomas.lynch@reasoningtechnology.com> wrote:
>
>> [image: image.png]
>>
>

[-- Attachment #1.2: Type: text/html, Size: 3477 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 80978 bytes --]