💾 Archived View for gemini.xteddy.org › fvwm › log › fvwmlog-2021-02-07.gmi captured on 2022-06-03 at 23:26:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
I've not done much on Fvwm3 today, as I've been focusing my efforts elsewhere (patches to gemini clients - lagrange and amfora). But there were a few pull-requests from people which is always nice to see.
Fvwm3 is both extremely old, and very new at the same time, as I look to extend established functionality, but also write new features. Nathan Mills (Quipyowert2) has been digging through the likes of Valgrind output to fix various memory leaks, which is great, since these memory leaks have been there for donkey's years! Admittedly, one or two were caused by me more recently. Oops! ;)
Additionally, Github issue #405 has had a bit more interest from a few people. This is the issue which discusses a new Fvwm config format. The problem with fvwm at the moment is that its syntax is old, not unified (i.e., lots of duplication between commands which do the same thing), and each command has to do its own parsing which leads to more duplication.
The proposal in GH issue #405 is to write a preprocessor which would convert a new syntax to the existing line-based syntax which fvwm is already using. So for example, currently it's possible to write the following:
DestroyFunc StartOneTerminal AddToFunc StartOneTerminal + I None (XTerm) Exec exec xterm + I TestRc (NoMatch) Next (XTerm, AcceptsFocus) FlipFocus
This function will either start a brand-new XTerm, or otherwise, switch focus to theexisting one. There's a few things to note here in terms of syntax:
1. The '+' symbol is in context of creating the StartOneTerminal function by appending to it.
2. The 'I' action is immediate (doesn't rely on waiting for buttons or mouse clicks)
One proposal is to introduce a block-based syntax as in:
f.StartOneTerminal {
I {
None (XTerm) Exec exec xterm
TestRc (NoMatch) Next (XTerm, AcceptsFocus) FlipFocus
}
}
In so-doing, one approach would be to create a preprocessor to handle the translation from the newer config to the existing configuration, as we figure out what the best approach is. One downside this though is error messages might seem strange coming from the newer syntax once translated.
Fun!