ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RP] Today's first set of patches


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]

Attachment: ratpoison-parse_pos-fix.diff
Description: Text document

Attachment: ratpoison-multicommand.diff
Description: Text document

Attachment: ratpoison-command-resolve.diff
Description: Text document

Attachment: pgpHSd4BFQR80.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]