Re: called by a process filter?

[storm@cua.dk (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