Re: newbie tries to hack comint.el (help!)

Re: newbie tries to hack comint.el (help!)

[bill]

In <877jujt2bx.fsf@tc-1-100.kawasaki.gol.ne.jp> Miles Bader <miles@gnu.org> writes:

>bill <please_post@nomail.edu> writes:
>> One thing that this function must do, but I have not been able to
>> figure out is how to to move the point to the beginning of the line
>> of the immediately preceding shell input.  I've been able to handle
>> simple cases, but not tricky ones like:
>>
>> myhost:~/some/dir$ foo \
>>> bar \
>>> baz_
>>
>> where '_' immediately after 'baz' indicates the location of the
>> point at the time I want to move it to the beginning of the line
>> beginning with "myhost".

>Probably you're best bet is to write your own regexp that matches your
>own prompt, but not shell `subprompts' like ">" -- or perhaps a regexp
>that only matches prompts you want to avoid -- and then scan back
>through what comint things are prompts, until you find something that
>matches (or doesn't match).

>For instance:

>   ;; Regexp matching prompts that `foo-beginning-of-previous-important-prompt'
>   ;; should avoid.
>   (defvar foo-avoid-prompt-regexp "^> *$")

>   ;; Move to the beginning of the previous comint prompt that doesn't match
>   ;; `foo-avoid-prompt-regexp'.
>   (defun foo-beginning-of-previous-important-prompt ()
>     (interactive)
>     (while (and (comint-previous-prompt)
>                 (let ((prompt-end-pos (point)))
>                   (forward-line 0) ; move to true beginning-of-line
>                   (string-match foo-avoid-prompt-regexp
>                                 (buffer-substring (point) prompt-end-pos))))))

>seems to work for your current example.

Good idea; it works like a charm.  Well, almost: I had to give an
argument of 1 to comint-previous-prompt (actually, I'm surprised
your code worked at all, unless the code you posted was not a
faithful cut-and-paste of the code you tested).

Many thanks.

	-bill

Re: newbie tries to hack comint.el (help!)

[Miles Bader]

bill <please_post@nomail.edu> writes:
> Well, almost: I had to give an argument of 1 to comint-previous-prompt
> (actually, I'm surprised your code worked at all, unless the code you
> posted was not a faithful cut-and-paste of the code you tested).

Hm, yes -- I wrote the code in the mail buffer, and then copied it
elsewhere for testing, and forgot to copy the tested version back...

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: newbie tries to hack comint.el (help!)

[Kevin Rodgers]

Miles Bader wrote:
 > bill <please_post@nomail.edu> writes:
 >>One thing that this function must do, but I have not been able to
 >>figure out is how to to move the point to the beginning of the line
 >>of the immediately preceding shell input.  I've been able to handle
 >>simple cases, but not tricky ones like:
 >>
 >>myhost:~/some/dir$ foo \
 >>>bar \
 >>>baz_
 >>>
 >>where '_' immediately after 'baz' indicates the location of the
 >>point at the time I want to move it to the beginning of the line
 >>beginning with "myhost".
 >
 > Note that comint _does not know_ (and cannot know) the difference
 > between "myhost: ~ ...$ " and "> " -- it can't tell when your input
 > causes a process to run in the shell, it just sees the input and output.
 > comint-prompt-regexp is probably not useful because it is designed to
 > match most prompts, and that includes "> ".

But doesn't comint or process-mark keep track of where the previous
command's output ended?  You should be able to search forward from there
to the next matching prompt.

-- 
Kevin Rodgers

Re: newbie tries to hack comint.el (help!)

[Miles Bader]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
>  > Note that comint _does not know_ (and cannot know) the difference
>  > between "myhost: ~ ...$ " and "> " -- it can't tell when your input
>  > causes a process to run in the shell, it just sees the input and output.
>  > comint-prompt-regexp is probably not useful because it is designed to
>  > match most prompts, and that includes "> ".
>
> But doesn't comint or process-mark keep track of where the previous
> command's output ended?  You should be able to search forward from there
> to the next matching prompt.

Note that prompts are output -- in this example "> " is the `commands's
most recent output.'

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche