Hi!
I planned to write a shell command line application for LSCP. For this I
already played around with Bison's auto generated parser tables. As a first
result of these experiments, the sampler is now providing more useful error
messages on LSCP syntax errors. Before, if you i.e. sent "GET S" (obviously
wrong) it was spitting out something like:
syntax error, unexpected '\r', expecting 'E' or 'T'
now it is also spitting out this:
Context: "GET S^..." -> Should be: SEND_EFFECT_CHAINS | SERVER | STREAMS
For the LSCP shell I planned some convenient usability features for dealing
with LSCP from the command line, either by typing and/or "running" LSCP script
files:
1. Auto completion: when tab is pressed, or when return is pressed and
the command line not fully completed yet and only a unique solution
exists to complete the command line.
2. Auto correction: if the user mistyped something and it is obvious
what
he "meant", then the shell will automatically correct it for the
user
while typing.
3. Colored output. Probably even enabled by default.
4. Much more user friendly error messages on syntax errors, spread over
several lines, with color and indicating semi-graphically the
position
of the issue. Maybe similar to clang compiler syntax error messages.
5. Visually aided suggestion in real-time while typing. The shell could
display the possibilities to complete the current command line in
the
same line in thin font. Once the typed command line is at a point
where there is only one solution to complete it, the line could i.e.
turn green.
Probably a bunch of more features, which make sense to be implemented as part
of a shell. For example relative path arguments (see bug #154), that is
relative to the working directory where the shell was called from. Or
conveniently saving and restoring a sampler session with one command to/from
the user's home directory. Or even variables to be reused in subsequent lines.
I am currently unresolved yet though where to position the shell:
a) on server side with the shell application just being a light-weight
application that only transmits characters and prints out content in color to
the console.
Advantage: shell application would be easy to maintain and quite
independent of the sampler's version being connected to. I.e. the same
shell application could deal with different LSCP versions without
problems.
Disadvantage: typing would be more sluggish on remote network
connections, since every single character typed would be transmitted,
and
result of its processing sent back.
Or
b) a full fledged autonomous shell application on client computer side, which
implements the complete shell on its own, with all the parser work, error
recovery and so on.
Advantage: allows very quick and responsive typing.
Disadvantage: the shell would assume/support exactly one LSCP version
*or* it would need to connect to the server, ask for the LSCP version
(GET SERVER INFO), but in that case we might need to maintain all LSCP
versions inside the shell application, i.e. separate lscp.y files for
each LSCP version in the shell's source files.
Just thoughts for now. Comments, additions appreciated.
CU
Christian
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
