On 5/26/21 11:35 AM, Niteesh G. S. wrote:
Hello Stefan,
On Mon, May 24, 2021 at 7:02 PM Stefan Hajnoczi <stefa...@redhat.com
<mailto:stefa...@redhat.com>> wrote:
On Sat, May 22, 2021 at 12:32:00AM +0530, Niteesh G. S. wrote:
> By end of this summer, I would like to get a basic TUI with some
desirable
> features working. Some of the features I would like to get
working are
> 1) Syntax checking
> 2) Syntax highlighting
> 3) Code completion
> 4) Logging
>
> I would like to hear some of the features you would like to have
and also
> your
> advice's on implementation.
Welcome Niteesh!
It would be great to have an QMP API documentation viewer built into the
TUI. When you enter a command like 'migrate' it would automatically
display the associated QMP command documentation from qapi/*.json.
That's a great idea.
Do you want the documentation as a popup or in a separate tab?
By separate tab what I mean is a full window dedicated to documentation
with some kind of search functionality.
Thanks,
Niteesh.
If we're talking about an urwid interface ...
There are a few ways to do this.
1. Explicitly, if you type something like "/help [command-name]" in the
command bar, you could create a panel that temporarily replaces the
history panel that shows the arguments and usage of the requested
command name.
You could use page-up/page-down to scroll the help up and down accordingly.
To exit the help window, you could issue some keypress (like Ctrl+X? If
you prototype this, just make it configurable -- I am sure people will
have opinions.)
While the help window is up, the command entry bar could stay active --
i.e., you can type your command while the help is visible on-screen.
(As an aside: If we expect that we will have more than just one or two
slash commands, it may be nice to have urwid create a popup suggestion
box when you type a '/', hinting to the user what local shell commands
are available.)
2. You could just display the help output as a flow item directly in the
history pane, but if QEMU is receiving lots of events, you run the risk
of having the help message flood off the screen.
Still, it might be a very simple way to implement it -- and the user can
always just scroll up.
3. If we get around to implementing any kind of fancy syntax for the
command entry bar, it may be possible to have the shell read the
partially-entered command and guess which command we want to see help
for -- maybe by pressing Ctrl+H?
A challenge will be where to pull the help text from. The QEMU server is
not capable (today) of sending help information over the QMP socket itself.
We will need to implement a QMP command inside of QEMU directly that is
capable of delivering this information to the client so that it can
render it.
Since not all versions of QEMU will have this feature, the qmp-shell
will need to be able to gracefully deal with the lack of help text,
displaying an error indicating that this version of QEMU does not have
help information compiled into it.
--js
