On Thu, Nov 18, 2021 at 12:31:09AM +0100, Dominik Vogt wrote:
> I haven't found anything yet either. Anyway, we need
> infrastructure for automated testing. That shouldn't involve much
> more than a testing directory, a Makefile with a "test" target,
> and a couple of files that can be fed into "Read" via FvwmCommand.
We used to have something like that but it fell into bitrot and I removed it
years ago. That being said, it's probably more valuable to have a set of
tests which capture the behaviour of the parser, than it is about checking
window positions, etc.
> Could you try to assemble a list of parsing test cases from past
> bug reports? We don't need hundreds but a selection of relevant
> corner cases.
Sure.
> The execution context is something different. It is basically
> meant to transport the information who or what triggered an action
> to pieces of code that need it. For example, one might need to
> know if a window button was acticated by a mouse button press, or
> a release, from the keyboard (from a menu entry etc.), from a
> module, and so forth. This change was extremely successful.
> Before we had the execution context, there were loads of transient
> bugs because code had to guess how it had been called. These
> problems are all gone now.
Indeed -- and I understood that. My point was to try and pre-enumerate this
along with the window which is required to run the action. That works fine
for individual commands but each item in a function could be working on a
different context entirely. I think what I'm trying to convey here is two
different things which I shouldn't conflate.
> The biggest problem I see is that the parsed information needs to
> be passed to the commands. I really don't want to generate C
> struct types programatically, and definitely not with odd tools
> like lex/yacc/bison. We used them for a while, and quality of the
> generated code was somewhere below zero.
OK.
> Here's an ad-hoc list of things needed for BNF* based commands:
> (* or whatever syntax description we want to use.)
>
> * A precise description of the commands' syntax in BNF.
> * A way to express alternative syntax variants. We have several
> commands that have different modes of operation; for example
> "Move" takes certain arguments in interactive mode, some
> arguments indicate noninteractive mode, and some arguments are
> shared.
I see this as the fundamental underpinings of moving things forward. Get this
right (or at the very least *standardised*), and everything becomes a lot
easier.
I see some of this as recognising that the commands need to have a common
syntax. Just dreaming up something here, but take the Move command for
example:
Move <-- context is known or asked for, but interactive nonetheless
Move -s fvwm.next.XTerm <-- next XTerm in the ring (but interactive)
Move -s fvwm.prev.XTerm -p 200p 100p <-- prev XTerm, non-interactive
(Here, -s indicates the *source* window).
Resize could also work the same with with -s
What I'm really talking myself into here is a DSL which represents the ability
to consistently apply filters to commands which operate consistently. This
would also mean conditional commands are not a separate entity, they're just
filters operating on other commands.
Commands might collectively take '-s' to indicate a source, or '-t' to
indicate the destination. Be it a specific geometry, pixel/percentage,
desktop, page, etc. The syntax for these can be unified and abstracted away.
So I think the BNF descriptions as we have them now are very useful and needed
to understand how the different commands behave now, and overlap. But for any
future changes, we need to think differently.
I don't like the overlap we have now between commands operating as
state/settings changed, and commands which all do the same thing as one
another. The BNF screams that to me even more than the man page does at this
point. ;P
> * Some way to store it in the function table (at compile time
> without making functable.h depend on all other .h files.)
Yes.
> * An indication in the function table whether a command uses old
> style parsing or BNF based.
> * A way to translate the BNF to structured data, either at
> build time (a la bison) or at run time (like the X event
> unions?).
We could start adding to the function table flags to indicate deprecation,
overlaps_with, etc. Along with parsing hints. For example (and completely
made up): imagine some command struct:
struct fvwm_command {
const char *cmd_name;
const char *syntax;
const char *other_cmd; <-- the alternate command to use if deprecated
int flags; <-- deprecated
context_t *context; <-- the window to operate on, etc.
};
So here, what I'm trying to convey is capturing the state of the command we
have now, whether it's deprecated (and the command to use instead), and some
context_t which has evaluated which window, etc., the command needs in order
to run. Then you can add some function pointers for checking/validating the
parsed string, etc.
Kindly,
Thomas
