dirtrack (shell mode) not working

dirtrack (shell mode) not working

[Samuel Wales]

Shell directory tracking fails to understand when I cd to a
symlink or do anything else that emacs cannot figure out.
Doing cd .. seems to make emacs think that pwd is above the
previous directory.  In the shell, for what it's worth, I
have this:

	#i like physical directories.  this might only be needed for bash.
	alias cd='cd -P'

I have tried various ways.  The following should work -- it
should read from the prompt, which looks like
"03-Sun-18-57-17 L4 ~/Desktop/A/alpha$ ".  The regular
expression works when performed manually, so it doesn't seem
to be an issue with text properties.

What am I doing wrong?

Thanks.

;;will need updating if change prompt in shell
;;(progn (search-backward-regexp (first dirtrack-list)) (match-string 1))
;;this re works, but dirtrack does not actualy use the prompt :(
(setq-default dirtrack-list '("^[0-9][0-9]-.* L[0-9] \\(.*\\)[$#] " 1))
(add-to-list 'comint-output-filter-functions 'dirtrack)

(setf comint-buffer-maximum-size (* 10 1000))
(add-to-list 'comint-output-filter-functions 'comint-truncate-buffer)

(ansi-color-for-comint-mode-on)

-- 
Myalgic encephalomyelitis denialism is causing death and severe suffering
worse than MS.  Conflicts of interest are destroying science.  Anybody can
get the disease at any time permanently.  Do science and justice matter to
you?  http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: dirtrack (shell mode) not working

[Samuel Wales]

dirtrack debugging reveals this.

Input `cd ..
  [33m   [0m   [35m 03-Sun-19-12-32   [0m L4   [1;34m ~/Desktop/A$
  [0m ' failed to match `dirtrack-regexp'

Any idea why?  (See my settings in the parent post for why this should work.)

Thanks.

On Sun, May 3, 2009 at 19:09, Samuel Wales <samologist@gmail.com> wrote:
> Shell directory tracking fails to understand when I cd to a
> symlink or do anything else that emacs cannot figure out.
> Doing cd .. seems to make emacs think that pwd is above the
> previous directory.  In the shell, for what it's worth, I
> have this:
>
>        #i like physical directories.  this might only be needed for bash.
>        alias cd='cd -P'
>
> I have tried various ways.  The following should work -- it
> should read from the prompt, which looks like
> "03-Sun-18-57-17 L4 ~/Desktop/A/alpha$ ".  The regular
> expression works when performed manually, so it doesn't seem
> to be an issue with text properties.
>
> What am I doing wrong?
>
> Thanks.
>
> ;;will need updating if change prompt in shell
> ;;(progn (search-backward-regexp (first dirtrack-list)) (match-string 1))
> ;;this re works, but dirtrack does not actualy use the prompt :(
> (setq-default dirtrack-list '("^[0-9][0-9]-.* L[0-9] \\(.*\\)[$#] " 1))
> (add-to-list 'comint-output-filter-functions 'dirtrack)
>
> (setf comint-buffer-maximum-size (* 10 1000))
> (add-to-list 'comint-output-filter-functions 'comint-truncate-buffer)
>
> (ansi-color-for-comint-mode-on)
>
> --
> Myalgic encephalomyelitis denialism is causing death and severe suffering
> worse than MS.  Conflicts of interest are destroying science.  Anybody can
> get the disease at any time permanently.  Do science and justice matter to
> you?  http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm
>



-- 
Myalgic encephalomyelitis denialism is causing death and severe suffering
worse than MS.  Conflicts of interest are destroying science.  Anybody can
get the disease at any time permanently.  Do science and justice matter to
you?  http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: dirtrack (shell mode) not working

[Peter Dyballa]

Am 04.05.2009 um 04:15 schrieb Samuel Wales:

> dirtrack debugging reveals this.
>
> Input `cd ..
>   [33m   [0m   [35m 03-Sun-19-12-32   [0m L4   [1;34m ~/Desktop/A$
>   [0m ' failed to match `dirtrack-regexp'
>
> Any idea why?


I'd remove the ANSI Esc garbage from the prompt (they're good enough  
for use in terminal emulations). The variable comint-highlight-prompt  
can make it look to be easily recognised. There are also comint- 
prompt-regexp and shell-prompt-pattern.

--
Greetings

   Pete

Klingon function calls do not have "parameters" - they have  
"arguments" - and they ALWAYS WIN THEM.

Re: dirtrack (shell mode) not working

[Samuel Wales]

On 2009-05-04, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>> Input `cd ..
>>   [33m   [0m   [35m 03-Sun-19-12-32   [0m L4   [1;34m ~/Desktop/A$
>>   [0m ' failed to match `dirtrack-regexp'

The big question here is why manual matching works perfectly fine.
Why would ansi colors throw dirtrack off when regexp search backward
accurately identifies the path and only the path?

> I'd remove the ANSI Esc garbage from the prompt (they're good enough
> for use in terminal emulations). The variable comint-highlight-prompt
> can make it look to be easily recognised. There are also comint-
> prompt-regexp and shell-prompt-pattern.

It would be a shame to get rid of the colors in the prompt, as they
separate its components visually for me in a way that makes them
easier to notice.  The first variable sets a single color, while the
second two, afaik, only affect movement.  Is that correct?

> Greetings

Thanks.  I like your Klingon joke.

Re: dirtrack (shell mode) not working

[Peter Dyballa]

Am 04.05.2009 um 18:44 schrieb Samuel Wales:

> On 2009-05-04, Peter Dyballa wrote:
>>> Input `cd ..
>>>   [33m   [0m   [35m 03-Sun-19-12-32   [0m L4   [1;34m ~/Desktop/A$
>>>   [0m ' failed to match `dirtrack-regexp'
>
> The big question here is why manual matching works perfectly fine.
> Why would ansi colors throw dirtrack off when regexp search backward
> accurately identifies the path and only the path?

Your "manual matching" works on the cleaned static text data, while  
the mode in the buffer sees the text plus the ANSI Esc codes which  
are used

>
> It would be a shame to get rid of the colors in the prompt, as they
> separate its components visually for me in a way that makes them
> easier to notice.

Yes, me too! I would like to have other colours used for the number  
plate of my car. There are other options to display information on a  
desktop.

> The first variable sets a single color, while the second two,  
> afaik, only affect movement.  Is that correct?
>

Esc[value;...;valuem sets a graphic mode (colour, intensity,  
blinking, reverse). The value 0 resets, the value 1 sets intensity.  
The foreground (3) colours yellow (3), magenta (5), and blue (4) are  
set.

--
Greetings

   Pete

"Debugging? Klingons do not debug! Our software does not coddle the  
weak."

Re: dirtrack (shell mode) not working

[Samuel Wales]

On Mon, May 4, 2009 at 12:51, Peter Dyballa <Peter_Dyballa@web.de> wrote:
> Your "manual matching" works on the cleaned static text data, while the mode
> in the buffer sees the text plus the ANSI Esc codes which are used

I don't think so.  My manual matching works on the mode in the buffer.
 Why would it be any different for the function?

> Yes, me too! I would like to have other colours used for the number plate of
> my car. There are other options to display information on a desktop.

That is a strange parody of emacs.  Let's not fix anything ever?

>> The first variable sets a single color, while the second two, afaik, only
>> affect movement.  Is that correct?
>>
>
> Esc[value;...;valuem sets a graphic mode (colour, intensity, blinking,
> reverse). The value 0 resets, the value 1 sets intensity. The foreground (3)
> colours yellow (3), magenta (5), and blue (4) are set.

That was not my question either.  You mentioned 3 variables as
solutions.  I do not see that they are solutions.  If that is
incorrect, please kindly say how the last 2 variables solve the
problem in any way whatsoever, and how the first solves it completely.

I know what ansi colors do.  That is not the question.  The question
is what I -- or dirtrack -- are doing wrong in getting dirtrack to
work.

Thanks.

Re: dirtrack (shell mode) not working

[Peter Dyballa]

Am 05.05.2009 um 00:03 schrieb Samuel Wales:

>> Your "manual matching" works on the cleaned static text data,  
>> while the mode
>> in the buffer sees the text plus the ANSI Esc codes which are used
>
> I don't think so.  My manual matching works on the mode in the buffer.
>  Why would it be any different for the function?

The buffer's mode works in real time. It receives everything. What's  
left afterwards is some colourful simple text.

>
> That was not my question either.  You mentioned 3 variables as
> solutions.  I do not see that they are solutions.  If that is
> incorrect, please kindly say how the last 2 variables solve the
> problem in any way whatsoever, and how the first solves it completely.

I have no exact idea. I mentioned them in case you wanted to make  
some experiments. The documentation, which I haven't read for some  
years, might be helpful.

--
Greetings

   Pete

Engineer: a mechanism for converting caffeine into designs