Re: [vxworks 02/14] New command_post observer.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> There are a lot of calls to execute_command that occur in batch-like
>> places.  For example, this is called from Python, I think it is called
>> from "commands" scripts and "define" scripts, etc.
>> 
>> So if your goal is to have it just emit info at some stopping point, it
>> seems to me that it would be better to have an observer just before a
>> prompt is emitted.

Joel> Either way would work, as far as I am concerned.  The purpose is to
Joel> inform the user that the context (partition) has changed.  I have
Joel> a tiny preference towards having consistent output, if we can, with
Joel> commands executed from the prompt and commands executed from elsewhere
Joel> such as user-defined commands for instance. But that preference really
Joel> has no additional technical merit that I can think of, so I'm happy to
Joel> change the observer to use something triggered just before printing
Joel> the command prompt (btw: it does not matter in this case, but I believe
Joel> that the prompt also gets printed as "> " while entering a canned
Joel> sequence of command).

I think the ">" thing indicates a misunderstanding.  I was talking about
when various command scripts are executed, not when they are entered.

E.g., suppose there are commands in a "define" that change the
partition, do some work, and then change it back.  With the observer as
it now stands, the user will see multiple notifications.  If the
observer were just before the prompt, only one notification would be
emitted.

Maybe there's no way for user commands to change the partition.  That
would render this consideration irrelevant.

Also, if this doesn't matter to you, then it is also fine by me.

Tom