called by a process filter?

called by a process filter?

[Kevin Rodgers]

Is there a way to tell whether a function was called via process filter?

I have a function that is installed on after-change-functions, and which
tries to detect whether the change that triggered it is a user-invoked
character insertion and thus of interest.  But if the change was done by
a process filter (in particular gnuserv-process-filter -> gnuserv-eval),
examining this-command, last-command-event, and/or the result of
(this-command-keys) is completely unreliable because the process filter
runs independently of the command loop.

It might be nice if Emacs temporarily bound all the command loop info
variables to nil while it runs the process filters.  But since it
doesn't seem to, how can I detect that situation?

Thanks,
-- 
Kevin Rodgers

called by a process filter?

[Kevin Rodgers]

Ooops, I meant to post to gnu.emacs.help, not .devel.  Followup-To set
to .help.

> Is there a way to tell whether a function was called via process filter?
> 
> I have a function that is installed on after-change-functions, and which
> tries to detect whether the change that triggered it is a user-invoked
> character insertion and thus of interest.  But if the change was done by
> a process filter (in particular gnuserv-process-filter -> gnuserv-eval),
> examining this-command, last-command-event, and/or the result of
> (this-command-keys) is completely unreliable because the process filter
> runs independently of the command loop.
> 
> It might be nice if Emacs temporarily bound all the command loop info
> variables to nil while it runs the process filters.  But since it
> doesn't seem to, how can I detect that situation?
> 
> Thanks,
 > --
 > Kevin Rodgers

Re: called by a process filter?

[Stefan Monnier]

> I have a function that is installed on after-change-functions, and which
> tries to detect whether the change that triggered it is a user-invoked
> character insertion and thus of interest.  But if the change was done by
> a process filter (in particular gnuserv-process-filter -> gnuserv-eval),
> examining this-command, last-command-event, and/or the result of
> (this-command-keys) is completely unreliable because the process filter
> runs independently of the command loop.

Could you give us more info about what you're trying to do.  Maybe there's
a better way.


        Stefan

Re: called by a process filter?

[Richard Stallman]

    Is there a way to tell whether a function was called via process filter?

Not currently.

We could envision making the code that calls process filters
bind this-command to the process that sent the output.
That is an incompatible change, but your arguments show
that probably the code that runs in filters would not want
to test this-command, so it probably won't break anything.

We could also create a new variable, perhaps this-process,
and bind that instead.  I think the former is more elegant.

Re: called by a process filter?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Is there a way to tell whether a function was called via process filter?
>
> Not currently.

Doesn't the following work?

(defvar in-my-filter-p nil)

(defun my-filter (proc text)
  (let ((in-my-filter-p t))
    ...))

(defun my-after-change-function ()
  (if in-my-filter-p
    ...


>
> We could envision making the code that calls process filters
> bind this-command to the process that sent the output.
> That is an incompatible change, but your arguments show
> that probably the code that runs in filters would not want
> to test this-command, so it probably won't break anything.

Binding a non-command object (a process) to this-command looks quite
obscure and unclean to me.

Lots of commands look at this-command (and internally we copy it to
last-command etc).  I could envision this change breaking code in
mysterious ways.


If really needed, the filter can do it

(defun my-filter (proc text)
  (let ((this-command proc))
    ...))


>
> We could also create a new variable, perhaps this-process,
> and bind that instead.  I think the former is more elegant.

Again, the filter can do that itself if needed:

(defun my-filter (proc text)
  (let ((this-process proc))
    ...))


I don't think we need to provide a more general approach, at least not
before the release.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: called by a process filter?

[Stefan Monnier]

> Doesn't the following work?

> (defvar in-my-filter-p nil)

> (defun my-filter (proc text)
>   (let ((in-my-filter-p t))
>     ...))

> (defun my-after-change-function ()
>   (if in-my-filter-p
>     ...

No, because the after-change-function is generic and doesn't know about all
the various filter functions it might interact with (which it'd have to
tweak with defadvice in order to do what you suggest).

My guess is that after-change-function is the wrong place to do what the OP
wants to do.


        Stefan

Re: called by a process filter?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Doesn't the following work?
>
>> (defvar in-my-filter-p nil)
>
>> (defun my-filter (proc text)
>>   (let ((in-my-filter-p t))
>>     ...))
>
>> (defun my-after-change-function ()
>>   (if in-my-filter-p
>>     ...
>
> No, because the after-change-function is generic 

I would expect it to be buffer local, and as such, it would only be
triggered by filter functions that update that buffer.

>                                                  and doesn't know about all
> the various filter functions it might interact with (which it'd have to
> tweak with defadvice in order to do what you suggest).

Of course, if the after-change-function _is_ generic, that would be
necessary.

>
> My guess is that after-change-function is the wrong place to do what the OP
> wants to do.

It does indeed seem odd that the after-change-function need to know
what command made the change...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: called by a process filter?

[Stefan Monnier]

>> No, because the after-change-function is generic 
> I would expect it to be buffer local, and as such, it would only be
> triggered by filter functions that update that buffer.

Well, to tell you the truth, given the lack of info, I actually have
no idea.  My impression is that the OP is writing some kind of
minor-mode-like thingy, so it may interact with more or less any
filter function.

But this impression is based on nothing, so I may be completely off-base.


        Stefan

Re: called by a process filter?

[Kevin Rodgers]

Stefan Monnier wrote:
 > Could you give us more info about what you're trying to do.  Maybe
 > there's a better way.

There certainly is a better way, suggested on gnu.emacs.sources several
years ago by Dave Love, but I haven't had the time to properly
generalize it.  What I'd like to do right now is help someone using my
legacy code, with a patch to work around this problem.

You are also correct, that this after-change-function implements a minor
mode, and that I'm hoping for a general solution like Richard proposed
(vs. advising every filter function as Kim proposed).  It just seems to
me that the command loop info variables and functions ought to return
distinctly different values forms are evaluated outside of that context.

-- 
Kevin Rodgers

Re: called by a process filter?

[Kevin Rodgers]

Kim F. Storm wrote:
 > I would expect it to be buffer local, and as such, it would only be
 > triggered by filter functions that update that buffer.

But when a filter function updates the buffer, this change function
(whether global or buffer local) should do nothing.

But even the change function were to do the same thing as when triggered
by a self-inserting non-word character (which would probably be
acceptable), the command loop variables and functions that it uses to
determine that return misleading information (and I suspect they are the
cause of the error that's been reported to me).

 > It does indeed seem odd that the after-change-function need to know
 > what command made the change...

Yes, it's odd, but it is necessary because of quirks in Emacs'
implementation:

;; One idea is to advise `self-insert-command' to `upcase'
;; `last-command-char' before it is run, but command_loop_1 optimizes
;; out the call to the Lisp binding with its C binding
;; (Fself_insert_command), which prevents any advice from being run.
;;
;; Another idea is to use a before-change-function to `upcase'
;; `last-command-char', but the change functions are called by
;; internal_self_insert, which has already had `last-command-char'
;; passed to it as a C function parameter by command_loop_1.

-- 
Kevin Rodgers

Re: called by a process filter?

[Richard Stallman]

    Binding a non-command object (a process) to this-command looks quite
    obscure and unclean to me.

To me it seems natural.  The filter was not run by any user command,
so I'm suggesting the idea that the command that ran the filter code
is the process itself.

    Lots of commands look at this-command (and internally we copy it to
    last-command etc).  I could envision this change breaking code in
    mysterious ways.

If something looks at this-command inside a process filter, it is
probably broken already.  In general it is unpredictable what command
is running, or was just running, when the process filter is called.
So such code would currently get unpredictable results.

It would indeed be safer to use a new variable, though.

Re: called by a process filter?

[Kim F. Storm]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kim F. Storm wrote:
>  > I would expect it to be buffer local, and as such, it would only be
>  > triggered by filter functions that update that buffer.
>
> But when a filter function updates the buffer, this change function
> (whether global or buffer local) should do nothing.

Can you please show us the code and tell us what you try to accomplish.

As Stefan has already suggested, an after-change-function is probably
the wrong tool for the job.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: called by a process filter?

[Kim F. Storm]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> There certainly is a better way, suggested on gnu.emacs.sources several
> years ago by Dave Love, but I haven't had the time to properly
> generalize it.  What I'd like to do right now is help someone using my
> legacy code, with a patch to work around this problem.

Asking for a change to emacs internals to support your legacy code
isn't a good reason in itself.  And it won't fix the problem for
users using older emacs releases.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: called by a process filter?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Binding a non-command object (a process) to this-command looks quite
>     obscure and unclean to me.
>
> To me it seems natural.  The filter was not run by any user command,
> so I'm suggesting the idea that the command that ran the filter code
> is the process itself.

>     Lots of commands look at this-command (and internally we copy it to
>     last-command etc).  I could envision this change breaking code in
>     mysterious ways.
>
> If something looks at this-command inside a process filter, it is
> probably broken already.  In general it is unpredictable what command
> is running, or was just running, when the process filter is called.
> So such code would currently get unpredictable results.

True.  

We should set this-command to nil while we a reading a key sequence at
the top level (and thus may run anync code).

>
> It would indeed be safer to use a new variable, though.
>
It is also cleaner:

Consider this example:

1) User runs command my-command.
2) my-command calls accept-process-output.
3) accept-process-output calls a filter, my-filter.
4) my-filter tests this-command.
5) my-command continues.
6) my-command tests this-command.


So what value should "this-command" have in step 4 ?

IMO, it should still be "my-command", as that is
the command currently executing.


And just for completeness, "this-command" should also be "my-command"
in step 6 (even if it was something else in step 4).


I suggest to add a new variable `this-process' that is nil
normally, but contains the current process when executing
a filter or sentinel, or just inserting data in a buffer
(which may also run after-change-functions I suppose).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: called by a process filter?

[Kevin Rodgers]

Kim F. Storm wrote:
 > Kevin Rodgers <ihs_4664@yahoo.com> writes:
 >>There certainly is a better way, suggested on gnu.emacs.sources several
 >>years ago by Dave Love, but I haven't had the time to properly
 >>generalize it.  What I'd like to do right now is help someone using my
 >>legacy code, with a patch to work around this problem.
 >
 > Asking for a change to emacs internals to support your legacy code
 > isn't a good reason in itself.  And it won't fix the problem for
 > users using older emacs releases.

Sorry for confusing my 2 separate requests:

1. How to detect that a process filter is running, in Emacs 21, so that
    I can help someone still using my legacy code.  I should have posted
    that question to gnu.emacs.help.

2. If that's not possible, how Emacs 22 might provide such a feature,
    for its general utility to Emacs Lisp programmers.  It sounds like
    the this-process variable may be implemented -- perfect!

Thanks,
-- 
Kevin Rodgers

Re: called by a process filter?

[David Kastrup]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kim F. Storm wrote:
>  > Kevin Rodgers <ihs_4664@yahoo.com> writes:
>  >>There certainly is a better way, suggested on gnu.emacs.sources several
>  >>years ago by Dave Love, but I haven't had the time to properly
>  >>generalize it.  What I'd like to do right now is help someone using my
>  >>legacy code, with a patch to work around this problem.
>  >
>  > Asking for a change to emacs internals to support your legacy code
>  > isn't a good reason in itself.  And it won't fix the problem for
>  > users using older emacs releases.
>
> Sorry for confusing my 2 separate requests:
>
> 1. How to detect that a process filter is running, in Emacs 21, so that
>     I can help someone still using my legacy code.  I should have posted
>     that question to gnu.emacs.help.

Sounds more sensible to change the legacy code rather than the
non-legacy Emacs.  Since you have not so far volunteered any code as
far as I remember following the discussion, this would require more
information.  A pointer to the code appears appropriate.

My apologies if this has already been given, and I forgot or
overlooked it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: called by a process filter?

[Richard Stallman]

    > If something looks at this-command inside a process filter, it is
    > probably broken already.  In general it is unpredictable what command
    > is running, or was just running, when the process filter is called.
    > So such code would currently get unpredictable results.

    True.  

    We should set this-command to nil while we a reading a key sequence at
    the top level (and thus may run anync code).

That would be a clean approach.

As for this-process, it would be clean and safe, but at present there
is no clear need to add it.

Re: called by a process filter?

[Richard Stallman]

    2. If that's not possible, how Emacs 22 might provide such a feature,
	for its general utility to Emacs Lisp programmers.  It sounds like
	the this-process variable may be implemented -- perfect!

So far we don't see a real argument that it is needed.