[Pan-users] Re: Odd accel behaviour

[Jim Henderson]

On Tue, 20 Oct 2009 20:03:51 +0000, Duncan wrote:

> Actually, yes, altho I thought it read it at open and wrote it at close,
> but it sounds like it writes it back out immediately, from what you
> wrote.

It's about 5000 lines later in the strace file (total line count for an 
open, get all new headers, and then a close is 75000 lines; the first 
open is about line 5000).

The really weird thing is the line where it opens for writing shows:

open("/home/jhenderson/.pan2/accels.txt", O_WRONLY|O_CREAT|O_TRUNC, 0644) 
= 31

Which seems to me to be saying "create this file".  Maybe that's normal, 
but it seems odd to me.

> In either case, what it does (or is supposed to do) is read the file in
> and load the accels, then write it unconditionally, I thought when it
> quit but whenever, with the current accels.

It seems that it is, because I don't see the current accel as a hotkey on 
the menu.  Somehow it's getting removed after being opened.  Let me try a 
different key and see if that fixes it (once I've posted this message).

> You mentioned SuSE, are you using their version directly, or K. Haley's
> GIT version, or upstream/GNOME GIT, or upstream/GNOME version tarball?
> If it was a git version, how often do you update?  Might it have been
> either that, or a conflict between a fairly new GIT change and a library
> update? (IOW for the latter, might the pan git update set the stage, but
> still worked with an older version of whatever library, but then been
> slightly incompatible with a library update?)

Let's see....I'm using 0.132,  It is the one from the openSUSE OSS repo, 
looks like - the package verifies OK and the binary is launching from the 
installed location.

> Also, if you set something else, /that/ won't stick either, right?  What
> about if you change an accel for any /other/ function?  Will the /other/
> function accel mapping stick?

I'll give that a try, hadn't thought to try that.

> It's also possible it was a random on-disk bit-flip.  Can you reinstall
> (from whatever source you use), and see if that fixes it?  Or just
> verify your copy against the package checksums, if you used a package
> and can therefore do so.  That may not be possible if you compiled from
> sources yourself, however.

The package does verify properly, so it's not a code bit flip, pretty 
certain on that.

But I've been meaning to try out the git version as well, so perhaps I'll 
give that a go this evening.

Jim


-- 
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits