CVS tadam: Resize: Don't throw away Direction command arguments
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 14/09/09 15:57:26 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 move_resize.c Log message: Resize: Don't throw away Direction command arguments Fix the resize options parsing by not advancing the token when processing the Direction command; additional tokens thereafter are legitimate options.
CVS tadam: Resize: Cleanup temp variable handling
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 14/09/09 16:04:17 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 move_resize.c Log message: Resize: Cleanup temp variable handling
[OT]: Using Emacs
Hi all, I know this is slightly off-topic, but for various reasons I'm having to use Emacs, and was wondering what others on this list do to make their lives easier with things like: * C development; * GDB; * Make/compilation Anything fvwm-specific as well would be welcomed. Kindly, -- 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: mvwm - things I'd like to see
On 3 September 2014 23:18, Dominik Vogt dominik.v...@gmx.de wrote: Well, if you run into problems you can always ask for help un the users' mailing list. is it still developed? Not by me, and I do not know if anybody maintains it. The last change was by thomas: https://github.com/ThomasAdam/fvwm-themes/commit/49f4091e743d0a639223abf44016785996fc4548 that was 4 years ago. Granted. I don't like the pixmap implementation either; it was part of a compromise because many people kept nagging about rounded window edges and things like that. the TODO file in mvwm suggests this might get reworked? Neither do I. But we can hardly add every odd scripting language to the window manager just because someone likes it. I can remember the fvwm-spinoff called scwm (scheme configurable window manager) which was (afaik) given up because scheme configuration turned out to be too slow. yes, Thomas mentioned this in another thread - it looked interesting but ultimately slow. The decision about the scripting implementation in the new core is still open, but we need facts and thinking about the correct choice of the language. i see these things in the TODO file: - The module interface (FVWM - Module) is a mess; consider DBUS? Or imsg? - Use libevent to replace the hand-rolled (and often broken) select/poll mechanism. - What about third-party scripting languages? How do we handle that without requiring linking against the specific language in question? i don't know if all three are related to scripting core, but what does the last item mean? is that relating to a choice of language? thank you for your time. Michael
Re: [OT]: Using Emacs
On Tue, Sep 09, 2014 at 11:46:21PM +0100, Dominik Vogt wrote: On Tue, Sep 09, 2014 at 10:47:19PM +0100, Thomas Adam wrote: I ... was wondering what others on this list do to make their lives easier Automatic removal of trailing whitespace in xemacs (see attachment): Ah. This is wonderful indeed. Thank you, Dominik! I'll mess about with these but they're looking pretty good. If I have to do any special hand-holding for them I'll let you know. I've not forgotten about the whitespace git hook either, I'll get to this on Friday. Thanks again. -- 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: New mvwm changes mailing list?
On Tue, Sep 09, 2014 at 11:46:02PM +0100, Michael Treibton wrote: Hi, is there a good way to ignore the mvwm emails sent here for the code changes? Do they need to get emailed out? they're quite large in size, and i could try and filter them but i worry i will miss other mvwm items on this list. Just filter by mvwm.*branch updated in whatever means suits how you'd usually filter email. instead can there be a separate list for mail of source-coding changes? I don't think Tibbs would like to manage this, and I certainly wouldn't want to subscribe to yet another list, to be honest. do other people here find these emails useful? So far you're the first person to mention this. I really would rather we kept these emails, especially since this list already has a tradition of sending out similar emails from CVS. One of the nicer features in my eyes of the output as I'm formatting it, compared to that of CVS is you can see the actual diffstat. Granted this might be rather unweildy at times (especially in terms of a merge commit), and hence I can always try and adapt that, but it gives a better---more instant---peer-review process, outside of the review process we already have (c.f. people sending patches before submitting to git, etc., 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: mvwm - things I'd like to see
On Tue, Sep 09, 2014 at 11:42:17PM +0100, Michael Treibton wrote: - What about third-party scripting languages? How do we handle that without requiring linking against the specific language in question? i don't know if all three are related to scripting core, but what does the last item mean? is that relating to a choice of language? It's explicitly stating that I would be unhappy linking mvwm against a specific language that has a C API (perl, lua, ruby, etc.) if we ever chose a preferred language. Rather, I'd like to see a language-agnostic interface which any third-party language could use to make use of whatever API/bindings we might come up with. We don't do this at the moment, and perllib is the only thing which tries to bridge the interface of itself with fvwm, but it does so in a very clumsy way; were such a common interface defined, it'd be a lot better, IMO. -- 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: New mvwm changes mailing list?
On Wed, Sep 10, 2014 at 12:02:09AM +0100, Thomas Adam wrote: On Tue, Sep 09, 2014 at 11:46:02PM +0100, Michael Treibton wrote: Hi, is there a good way to ignore the mvwm emails sent here for the code changes? Do they need to get emailed out? they're quite large in size, and i could try and filter them but i worry i will miss other mvwm items on this list. Just filter by mvwm.*branch updated in whatever means suits how you'd usually filter email. instead can there be a separate list for mail of source-coding changes? I don't think Tibbs would like to manage this, and I certainly wouldn't want to subscribe to yet another list, to be honest. do other people here find these emails useful? So far you're the first person to mention this. I really would rather we kept these emails, especially since this list already has a tradition of sending out similar emails from CVS. Well, maybe we could limit the context diff to ~50 lines to limit the size of the commit messages. One of the nicer features in my eyes of the output as I'm formatting it, compared to that of CVS is you can see the actual diffstat. Granted this might be rather unweildy at times (especially in terms of a merge commit), and hence I can always try and adapt that, but it gives a better---more instant---peer-review process, outside of the review process we already have (c.f. people sending patches before submitting to git, etc., etc.) Good point. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: mvwm - things I'd like to see
On Tue, Sep 09, 2014 at 11:42:17PM +0100, Michael Treibton wrote: On 3 September 2014 23:18, Dominik Vogt dominik.v...@gmx.de wrote: Well, if you run into problems you can always ask for help un the users' mailing list. is it still developed? Not by me, and I do not know if anybody maintains it. The last change was by thomas: that was 4 years ago. Oh, just four years? I thought it was more. :-D Granted. I don't like the pixmap implementation either; it was part of a compromise because many people kept nagging about rounded window edges and things like that. the TODO file in mvwm suggests this might get reworked? Yep, cleaning up fvwm would be rather pointless if we don't clean up the really dirty corners. The decision about the scripting implementation in the new core is still open, but we need facts and thinking about the correct choice of the language. i see these things in the TODO file: - The module interface (FVWM - Module) is a mess; consider DBUS? Or imsg? - Use libevent to replace the hand-rolled (and often broken) select/poll mechanism. - What about third-party scripting languages? How do we handle that without requiring linking against the specific language in question? i don't know if all three are related to scripting core, The first two are really about communication between fvwm and the modules, and signal handling in fvwm and the modules. The module interface is somewhat related to scripting because it adds some limitations (maximum line length, parsing of data sent back and forth), but these limitations should be removed eventually. but what does the last item mean? is that relating to a choice of language? In a sense, yes. There's nothing really wrong with interfacing to Lua or other languages. At the moment, fvwm has a built in configuration language and three external interfaces for arbitrary commands: The binary module interface that can transport some information about events and fvwm's internal state. Then there's the PipeRead mechanism that can really run any command written in any language. It's severely limited in what information fvwm can pass to the command (environment variables and command line arguments with parameter expansion). And the third is the perllib. I have no clue how this is implemented and was never interested in using it. My guess is that it allows scripting and accessing the binary information of the module interface from a perl script. All these interfaces are very limited in what internal state of the windows and fvwm they can access. As a long term goal, I'd like to extend this so that all styles, window states, global states and events can be accessed from outside (and from the configuration language too, of course). The resulting scripting possibilities would be incredible, limited almost only by the speed of communication. So, I suggest there should be _one_ fast, internal language and _one_ relatively fast, flexible way without today's limitations (module input max. 255 characters, other commands max 1023 characters) to interface with any binary program or script. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: mvwm - things I'd like to see
On Wed, Sep 10, 2014 at 12:07:30AM +0100, Thomas Adam wrote: On Tue, Sep 09, 2014 at 11:42:17PM +0100, Michael Treibton wrote: - What about third-party scripting languages? How do we handle that without requiring linking against the specific language in question? i don't know if all three are related to scripting core, but what does the last item mean? is that relating to a choice of language? It's explicitly stating that I would be unhappy linking mvwm against a specific language that has a C API (perl, lua, ruby, etc.) if we ever chose a preferred language. Rather, I'd like to see a language-agnostic interface which any third-party language could use to make use of whatever API/bindings we might come up with. My opinion is exactly the same. We don't do this at the moment, and perllib is the only thing which tries to bridge the interface of itself with fvwm, but it does so in a very clumsy way; were such a common interface defined, it'd be a lot better, IMO. I think the perllib was a direct reaction from Mikhael to my special ModuleListenOnly implemented as a zsh script. :-D Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: mvwm: new-parser branch updated
On Wed, Sep 10, 2014 at 12:26:09AM +0100, Dominik Vogt wrote: On Sun, Sep 07, 2014 at 07:23:14AM -0700, Thomas Adam wrote: The mvwm repository's new-parser branch has been updated. I've just pushed some experimental code to the new branch dv/new-parser. Amazing! I've just taken a very quick look and noted that cmdparser.h is missing. https://travis-ci.org/ThomasAdam/mvwm/jobs/34862057 I knew this would come in useful! I suspect you just forgot to git add it. Thomas, you should probably take a look at what I'm doing right now. As a first step, I have started to replace the parsing code in __execute_command_line with hook functions defined elsewhere and stored in a structure. The first milestone is having a parser that provides the current syntax. Next, I want to carefully clean up __execute_command_line so that it needs fewer hooks with saner logic. For now I want to keep compatible, but eventually the hook structure should be replaced with another one provided by the new parser. I understand. I've likely got something similar sat here as well, but I'll wait for yours first and mail out suggestions to you, although I don't think you're going to run into many difficulties initially. One side effect of this first commit is that the static variable func_depth is eliminated. Instead, I've defined a cmdparser_context_t that is generated in __execute_command_line and contains all the state that the cmdparser needs to record. Eventually, nobody else should look at the contents of the structure, but at the moment it just contains an (still unused) copy of the command line and the current nesting depth. Noted, thanks. This is all work in progress and subject to a lot of refactoring. Any suggestions are welcome. Note: The code is completely untested as I haven't set um mvwm yet. :-) No worries; see above. I'll take a look at this tomorrow. :) -- 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.)
CVS tadam: Regenerate FVWM/Commands.pm
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: tadam 14/09/09 18:59:41
Modified files:
perllib: Tag: branch-2_6 ChangeLog
perllib/FVWM : Tag: branch-2_6 Commands.pm
Log message:
Regenerate FVWM/Commands.pm
So it turns out that I didn't do this for the 2.6.0 release; thankfully
there weren't any new commands added then.
Apparently, the way the commands are generated for FVWM/Commands.pm relies
on some *very* carefully formatting of comments in the functable.c file;
which I didn't follow for InfoStore{Add,Remove}. Hence, garbage produced
until I fixed that.
Ideally this needs revisiting in the future...
Re: [OT]: Using Emacs
Thomas Adam tho...@fvwm.org writes: Hi all, I know this is slightly off-topic, but for various reasons I'm having to use Emacs, and was wondering what others on this list do to make their lives easier with things like: * C development; * GDB; * Make/compilation It's important to do make while inside Emacs, there are benefits to working that way. Bind some keys to invoke the compiler and find errors, I do: (define-key global-map [(f1)] 'compile) (define-key global-map [(f2)] 'next-error) (define-key global-map [(S-f2)] 'previous-error) Anything fvwm-specific as well would be welcomed. In the fvwm source directory I keep a file for Emacs that automatically enforces fvwm project rules. The name of the file is .dir-locals.el and it's contents: ((nil . ((indent-tabs-mode . t) (fill-column . 80))) (c-mode . ((c-basic-offset . 8) (c-indent-level . 8) (indent-tabs-mode . t Emacs reads .dir-locals.el and applies it's rules in all sub-directories. -- Dan Espen
