old Wait syntax
Just found this comment in CMD_Wait(): /* nope, multiple tokens - try old syntax */ Actually, apart from the syntax described in the man page (first and only argument is a window name/class/... pattern), there is another syntax mode that looks like this: Wait garbage-token restofline With this syntax, the first argument is thrown away. Then leading and trailing whitespace is removed from the rest of the line, and what remains is used as the pattern to wait for. Does anybody remember where this undocumented extra syntax comes from? Is it safe to remove that? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
mvwm: master branch updated
The mvwm repository's master branch has been updated. The following shows
the diffstat and patchsets between the merged result and HEAD.
commit 71a68616768877f5693fb53baa414f4fe21dcdbc
Merge: 55d129f cedbcb6
Author: Thomas Adam tho...@xteddy.org
Date: Tue Sep 2 21:43:54 2014 +0100
Merge branch 'branch-2_6'
Conflicts:
mvwm/builtins.c
commit cedbcb6cd9a226613f884d7fb4a22b72c151ab02
Merge: 7609bf2 3ca7363
Author: Thomas Adam tho...@xteddy.org
Date: Tue Sep 2 21:40:40 2014 +0100
Merge remote-tracking branch 'cvs/branch-2_6' into branch-2_6
commit 3ca73635637a1499e635e0081ad08f3857dcc531
Author: domivogt domivogt
Date: Tue Sep 2 20:29:34 2014 +
* Fix memory leak in wait command.
diff --git a/ChangeLog b/ChangeLog
index a72ea07..5d5bb27 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-09-02 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
+
+ * fvwm/builtins.c (CMD_Wait):
+ fixed a memory leak
+
2014-08-28 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* fvwm/menus.c (get_menu_options):
diff --git a/fvwm/builtins.c b/fvwm/builtins.c
index 20f8c4c..0ef90d2 100644
--- a/fvwm/builtins.c
+++ b/fvwm/builtins.c
@@ -2539,6 +2539,7 @@ void CMD_Wait(F_CMD_ARGS)
{
temp++;
}
+ free(wait_string);
wait_string = safestrdup(temp);
for (i = strlen(wait_string) - 1; i = 0
isspace(wait_string[i]); i--)
CVS tadam: Update passive grabs tracking modifiers
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 14/09/02 16:19:33 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 bindings.c bindings.h events.c Log message: Update passive grabs tracking modifiers In the case of GTK's link widget which doesn't handle passive grabs following FVWM's window bindings (which assumes the underlying application can handle a PointerReplay), update the grabs in this context by always ungrabbing the button and grabbing it for modifiers other than ALL_MODIFIERS. I've had this in testing for three years and recently dusted it off for a bug report I received for another application with this problem, called darktable.
CVS domivogt: * Added a comment about GetNextSimpleOption().
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt14/09/02 16:32:13 Modified files: fvwm : Tag: branch-2_6 conditional.c Log message: * Added a comment about GetNextSimpleOption().
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: Just found this comment in CMD_Test: /* * unfortunately, GetNextSimpleOption is * * broken, does not accept quoted empty */ Actually, GetNextSimpleOption() is _not_ broken. The parsing library guarantees never to return empty tokens. This is a feature, albeit a questionable one. The CVS command you are looking for is annotate. 1.107 (migo 13-Aug-05): /* unfortunately, GetNextSimpleOption is Could be that it was broken when the comment was written. -- Dan Espen
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
Just pushed a new version of the Abnf. On Tue, Aug 26, 2014 at 10:10:57PM +0100, Dominik Vogt wrote: On Tue, Aug 26, 2014 at 03:20:09PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: I might take the blame for other mis-designed things, but as far as I remember, that goes way back. I think the issue was those pretty long commands AddToFunc, etc. But the + sign is just broken. On the other hand, I've never seen it cause a real problem. I think Fvwm just scoops up commands so fast that it's unlikely that there will be a conflict. Probably because nobody uses dynamic menus much. When fvwm reads a file or PipeRead input, it does not do anything in between, but input from modules cound trigger that. Anyway, it would be nice to have a clean scripting engine that can handle this correctly. You'd just have to store a separate '+' context for each source from which fvwm reads commands. It would be nice if Fvwm reported where it found an error (line 40 .fvwm/config) which would make the parser aware of where commands are coming from and provide a way to fix this. Of course sometimes it would be FvwmAnimate PID 1234, 20th command. Good idea. We should write that down somewhere. Thomas, could you put this information somewhere? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 10:55:43PM +0100, Dominik Vogt wrote: By the way, does anybody know what this infostore stuff is about? https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 11:00:13PM +0100, Thomas Adam wrote: On Tue, Sep 02, 2014 at 10:55:43PM +0100, Dominik Vogt wrote: By the way, does anybody know what this infostore stuff is about? https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Thenks. Can you write the missing sub-rule for the Test command (the one that has to do with infostore)? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: CVS tadam: Update passive grabs tracking modifiers
On Tue, Sep 02, 2014 at 04:19:33PM -0500, c...@math.uh.edu wrote: Log message: Update passive grabs tracking modifiers In the case of GTK's link widget which doesn't handle passive grabs following FVWM's window bindings (which assumes the underlying application can handle a PointerReplay), update the grabs in this context by always ungrabbing the button and grabbing it for modifiers other than ALL_MODIFIERS. I've had this in testing for three years and recently dusted it off for a bug report I received for another application with this problem, called darktable. Can you please explain the problem in even more detail? Grabbing is a crucial part of fvwm that I want to understand completely. (A diff would also be nice for convenience; they're so difficult to get from CVS.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: On Tue, Sep 02, 2014 at 05:48:05PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: Just found this comment in CMD_Test: /* * unfortunately, GetNextSimpleOption is * * broken, does not accept quoted empty */ Actually, GetNextSimpleOption() is _not_ broken. The parsing library guarantees never to return empty tokens. This is a feature, albeit a questionable one. The CVS command you are looking for is annotate. 1.107 (migo 13-Aug-05): /* unfortunately, GetNextSimpleOption is Well, I thought it might be worhtwhile to mention it in public while we're working on the parser anyway. Could be that it was broken when the comment was written. No, it has always been this way. This guarantee is used in many places where parsing is done, and when I coded GetNextSimpleOption() this was in there from the start (because it simply uses the same underlying implementation of the tokenisation functions as the rest of the parsing library). By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. -- Dan Espen
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
On Tue, Sep 02, 2014 at 10:51:05PM +0100, Dominik Vogt wrote: Just pushed a new version of the Abnf. On Tue, Aug 26, 2014 at 10:10:57PM +0100, Dominik Vogt wrote: On Tue, Aug 26, 2014 at 03:20:09PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: I might take the blame for other mis-designed things, but as far as I remember, that goes way back. I think the issue was those pretty long commands AddToFunc, etc. But the + sign is just broken. On the other hand, I've never seen it cause a real problem. I think Fvwm just scoops up commands so fast that it's unlikely that there will be a conflict. Probably because nobody uses dynamic menus much. When fvwm reads a file or PipeRead input, it does not do anything in between, but input from modules cound trigger that. Anyway, it would be nice to have a clean scripting engine that can handle this correctly. You'd just have to store a separate '+' context for each source from which fvwm reads commands. It would be nice if Fvwm reported where it found an error (line 40 .fvwm/config) which would make the parser aware of where commands are coming from and provide a way to fix this. Of course sometimes it would be FvwmAnimate PID 1234, 20th command. Good idea. We should write that down somewhere. Thomas, could you put this information somewhere? Done. It's in the TODO for now. -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 11:09:49PM +0100, Thomas Adam wrote: On 2 September 2014 23:04, Dominik Vogt dominik.v...@gmx.de wrote: Can you write the missing sub-rule for the Test command (the one that has to do with infostore)? Will do in the next half-hour or so. Great. This is the last missing piece of the conditional commands. I'm eager to get over with the basic parsing description draft so I can try some practical things. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 11:11:56PM +0100, Dominik Vogt wrote: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. I don't mind. But I certainly _dislike_ the ridiculous tokens we have now in terms of w.foo, i.foo, etc., etc. I'd much rather we deferred that part until much later on, as I've a few notes regarding expansion versus information coming out of fvwm (and how that's stored in fvwm, etc.) -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. We have SetEnv. Does SetVar work for you? All of 2.6 is stable. -- Dan Espen
Re: GetNextSimpleOption is broken
Thomas Adam tho...@fvwm.org writes: On Tue, Sep 02, 2014 at 11:11:56PM +0100, Dominik Vogt wrote: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. I don't mind. But I certainly _dislike_ the ridiculous tokens we have now in terms of w.foo, i.foo, etc., etc. I'd much rather we deferred that part until much later on, as I've a few notes regarding expansion versus information coming out of fvwm (and how that's stored in fvwm, etc.) Just kibitzing here, but when I do re-factoring, I like to start with consistent names. I could see how changing names might cause git - cvs issues. -- Dan Espen
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 11:15:44PM +0100, Thomas Adam wrote: On Tue, Sep 02, 2014 at 11:11:56PM +0100, Dominik Vogt wrote: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. I don't mind. But I certainly _dislike_ the ridiculous tokens we have now in terms of w.foo, i.foo, etc., etc. Agreed. I'd much rather we deferred that part until much later on, as I've a few notes regarding expansion versus information coming out of fvwm (and how that's stored in fvwm, etc.) Yes, of course. Expansion is a terrible mess right now and needs to be cleaned up, and that will require much thought and planning. I'd prefer to either make expansion much more similar to what shells do (i.e. make the general syntax more shell-like) *or* to do something completely different that does not interfere as much with the parsing of the underlying shell (maybe easier to understand and use). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 06:18:14PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. We have SetEnv. Does SetVar work for you? Of course, but it's closely related to parsing and command line expansion. All of 2.6 is stable. But 2.6.6 is not released. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 06:22:28PM -0400, Dan Espen wrote: I don't mind. But I certainly _dislike_ the ridiculous tokens we have now in terms of w.foo, i.foo, etc., etc. I'd much rather we deferred that part until much later on, as I've a few notes regarding expansion versus information coming out of fvwm (and how that's stored in fvwm, etc.) Just kibitzing here, but when I do re-factoring, I like to start with consistent names. I could see how changing names might cause git - cvs issues. That's actually something I'd like to move as far into the future as possible. I'd rather start with all the changes that would not prevent to push fixes in fvwm to the new code. But eventually it will happen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: GetNextSimpleOption is broken
On Tue, Sep 02, 2014 at 11:14:11PM +0100, Dominik Vogt wrote: Great. This is the last missing piece of the conditional commands. I'm eager to get over with the basic parsing description draft so I can try some practical things. :-) Done. Heh, I've sneakily been starting a few things, but left it... -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
mvwm: document-parsing branch updated
The mvwm repository's document-parsing branch has been updated. The following shows the diffstat and patchsets between the merged result and HEAD. commit 9cceb32e1c4cc012be602f7bda06328f07f53142 Author: Thomas Adam tho...@xteddy.org Date: Tue Sep 2 23:40:03 2014 +0100 Fixed typo --- rewrite-notes/parsing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rewrite-notes/parsing b/rewrite-notes/parsing index bd33ff5..bddf387 100644 --- a/rewrite-notes/parsing +++ b/rewrite-notes/parsing @@ -755,7 +755,7 @@ COLORSETKEYWORD =/ Back COLORSETKEYWORD =/ Background COLORSETKEYWORD =/ hi COLORSETKEYWORD =/ Hilite -COLORSETKEYWORD =/ Hilight +COLORSETKEYWORD =/ Hilight COLORSETKEYWORD =/ sh COLORSETKEYWORD =/ Shade COLORSETKEYWORD =/ Shadow
mvwm: document-parsing branch updated
The mvwm repository's document-parsing branch has been updated. The following shows the diffstat and patchsets between the merged result and HEAD. commit fda352594c6ecae421265e464012a5ccf47df3bf Author: Thomas Adam tho...@xteddy.org Date: Tue Sep 2 23:51:33 2014 +0100 Few more typo fixes --- rewrite-notes/parsing | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/rewrite-notes/parsing b/rewrite-notes/parsing index bddf387..8555c62 100644 --- a/rewrite-notes/parsing +++ b/rewrite-notes/parsing @@ -1219,7 +1219,7 @@ CMD_TITLE = Title ; note: syntax description complete CMD_TITLESTYLE = TitleStyle -!!! +;!!! CMD_SETENV = SetEnv [TOKEN_ENVVAR [TOKEN_ENVVAL]] TOKEN_ENVVAR = TOKEN @@ -1417,6 +1417,8 @@ CMD_WINDOWID = WindowId ; note: syntax description complete WINDOWIDSCREENNUM = POSINT ; note: valid range is 0 to number of screens - 1 +; note: mvwm has replaced Xinerama with XRandr, therfore using integets to +; refer to monitors won't work. WINDOWID = LONGINT ; note: long value parsed by strtol without error checking @@ -1461,14 +1463,14 @@ IMAGEFILE = TOKEN ; note: if file not found, try again with IMAGEFILE .gz ; parsed by parse_gravity_argument -DIR_N = - / N / NorthTop / t / Up / u -DIR_E =/ ] / E / East / Right / r / Right / r -DIR_S =/ _ / S / South / Bottom / b / Down / d -DIR_W =/ [ / W / West / Left / l / Left / l -DIR_NE =/ ^ / NE / NorthEast / TopRight / tr / UpRight / ur -DIR_SE =/ / SE / SouthEast / BottomRight / br / DownRight / dr -DIR_SW =/ v / SW / SouthWest / BottomLeft / bl / DownLeft / dl -DIR_NE =/ / NW / NorthWest / TopLeft / tl / UpLeft / ul +DIR_N = - / N / North / Top / t / Up / u +DIR_E = ] / E / East / Right / r / Right / r +DIR_S = _ / S / South / Bottom / b / Down / d +DIR_W = [ / W / West / Left / l / Left / l +DIR_NE = ^ / NE / NorthEast / TopRight / tr / UpRight / ur +DIR_SE = / SE / SouthEast / BottomRight / br / DownRight / dr +DIR_SW = v / SW / SouthWest / BottomLeft / bl / DownLeft / dl +DIR_NE = / NW / NorthWest / TopLeft / tl / UpLeft / ul DIR_C = . / C / Center / Centre DIRS_MAJOR = DIR_N / DIR_E / DIR_S / DIR_W DIRS_MINOR = DIRS_MAIN / DIR_NE / DIR_SE / DIR_SW / DIR_NW
