Richard Stallman <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
