[Pan-users] Re: Odd accel behaviour

[Duncan]

Jim Henderson posted on Tue, 20 Oct 2009 17:25:21 +0000 as excerpted:

> So running an strace on it, I can see that it opens the accels.txt file
> and reads it fine, but then for some reason (not really explained by a
> quick scan of the strace log file I created) pan recreates the
> accels.txt file.
> 
> It seems to do this every time, regardless of whether I modify the file
> or not.

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.

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 does the write bit in the first place to create the file with the 
defaults so it can be modified as desired, and then just always dumps its 
current accel set at close or whenever, so anything that was changed 
using the GUI gets written.

Of course, the irritating bit (in normal operation) is that when it 
dumps, that's exactly what it does, a dump, in whatever order they were 
in memory, which looks random from a human perspective.  So it's 
impossible to keep it ordered in any way, except by keeping your changes 
in a different file, and (with pan closed) copying it over the dump-file 
when a change is desired.

So the writing out isn't abnormal, except /maybe/ if it's writing at init 
instead of at close, that might be abnormal.  But rather, what seems to 
be the problem is that for some reason that function has seemed to come 
unglued from the accel for loading, so neither whatever you write in the 
file nor its default get loaded, and when it writes it writes the no-
accel that it then has.

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?)

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?

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman