|
From: | Gergely Nagy |
Subject: | [RP] Today's first set of patches |
Date: | Thu Sep 13 09:07:02 2001 |
User-agent: | Mutt/1.3.20i |
Greetings! Today, I was poking around in the TODO file, and tried to make def* echo the settings to stdout. Unfortunately, I didn't succeed. On the other hand, I noticed that `C-t :defwinpos' will crash ratpoison, since parse_pos (in actions.c) does not check if its argument is NULL or not, nor do the cmd_def* functions. So, I modified parse_pos to return -3 when data is NULL. The only problem with that is, that RP will display `pos: unknown position', and not `at least two arguments required' or something. But! This might be good, since when the def*-returns-the-settings thingy is implemented, it should not display that message anyway. Now, the second patch: sometimes, I'm a command-line freak, and try to do everything from a simple shell (or M-x ansi-term :). So, I thought I'll split the screen, launch an xterm, then change to the other frame, and launch an aterm, all from the commandline. I typed the following: ratpoison -c vsplit -c "exec xterm" -c focus -c "exec aterm" To my surprise, only an aterm was launched. So, I looked at the code, and noticed that ratpoison overwrites the previous commands with the last -c one, everytime it encounters one. I sat down, and modified it to store the commands in a string vector, and execute them all. Now it works pretty fine, and I can do complex scripts this way. Eleet :) Not to mention that this will be a great benefit for ratpoison-eval-region (or whatever it will be called). And now, some bugfixing in yesterday's patches: the first buglet I spotted is that find_command_by_keydesc did not initialize `i', the counter. This resulted in weird behaviour in some cases. The trivial fix is to initialize i to zero. The second thing I spotted is that my modifications to cmd_help were ugly, and non-trivial. Not to mention that it wasn't robust enough. So, I decided to write a small function, that will resolve symbinds, to at most the level of MAX_SYMBIND_DEPTH (defined in conf.h). I had the following goal in mind: you can pass any key-description to it, and it will find the command that will be run by that combination, and is not a symbind command. That is, if you ask it to resolve a command associated with C-t c, and it is not a symbind, it will return that command, if it is one, it will extract the key which it is symbound to, and call itself to resolve it. If it goes beyond a certain depth, it will return the current state, regardless of what it actuall is, thus preventing infinite-loops. This was a worthy goal, since when such a function is at our hand, we can use it in cmd_help to resolve _all_ commands, and we don't need to check for symbinds there, for this neat function will take care of that. The result is: a much cleaner cmd_help. It is actually almost the same as the unmodified one. Cool, isn't it? As usual, comments, flames, flowers and praises are welcomed :) Cheers, -- Gergely Nagy \ mhp/|8]
ratpoison-parse_pos-fix.diff
Description: Text document
ratpoison-multicommand.diff
Description: Text document
ratpoison-command-resolve.diff
Description: Text document
pgpHSd4BFQR80.pgp
Description: PGP signature
[Prev in Thread] | Current Thread | [Next in Thread] |