Re: [Pan-users] Automatic Preview of Messages When Selected

[Duncan]

validator via Pan-users posted on Fri, 02 Aug 2024 08:15:44 +0000 as
excerpted:

> I was wondering if there is a way to configure Pan to automatically open
> and display the content of a message as soon as it is selected in the
> headers panel.

So I'll answer for both mouse selection, which I first assumed you wanted 
after the above paragraph, and keyboard, which the below paragraph makes 
clear you were actually asking about.  They're both available but 
configured differently since the keyboard feature is partly covered by 
hotkey customization.

> I've searched through the preferences and couldn't find such an option.
> Specifically, I want to see the message preview immediately when I use
> the arrow keys to navigate and select messages. Does this feature exist?

For the mouse, preferences, behavior, mouse.  There's two separate 
checkboxes for groups and articles.  Checked a left-click activates 
(middle-click to select or use the usual ctrl/shift-click multi-select), 
unchecked it only selects.

Keyboard is more complicated as there's actually several overlapping 
features involved.  First, not quite what you wanted but since 
preferences, behavior may well be already opened for the mouse config 
above, verify the checkboxes under articles are all set according to your 
wishes, and while there you might as well do the same for all the other 
settings on that page as well.

Now, what you're actually asking to hotkey-trigger is the appropriate 
items on the go menu, in particular, the next/previous-article or perhaps 
next-/unread/-article and /parent/-article.  The existing hotkey settings 
should be listed beside them in the menu.  But I've long since customized 
mine and don't remember what the defaults are.

FWIW my settings (if viewing in pan you may want to toggle-wrap for each 
setting on its own line, "w" hotkey here and I believe default):
next article: a
previous article: shift-a (the common shift=reverse-function)
next unread article: shift-ctrl-a
parent article: shift-alt-a
(Depending on your usage next-article and next-unread-article could be 
reversed; I wanted a plain a just doing next article so that's how I set 
it up.)

(I have ctrl-a ingrained as select-all, so in pan it's select-article-
body, with ctrl-alt-a the alternate function of that, select-all-articles 
in the header pane, and shift-ctrl-alt-a the reverse of that, deselecting 
them all.)

So "a" hotkeys are article related (nice that select-all-articles and 
select-article-body are somewhat article related too, so they match both 
my ingrained and the article theme).  Similarly, "t" hotkeys are thread 
related, and "g" hotkeys are group related.  Pan's defaults sort of did 
some of this already, but the logic wasn't consistently applied enough for 
me so I customized.


Before we actually discuss where/how to customize the hotkeys, though, I 
should mention that I'm a bit leery about assigning the (unmodified) arrow 
keys as hotkeys (if it's even possible, not sure), because I think it may 
have other navigation consequences.  Assigning arrows to the next/previous 
(or next-unread/parent) article functions will presumably make them 
unavailable for other navigation, and I'm not sure that's what you want.  
You can of course experiment and see how it works, but I'd encourage you 
to either use the defaults or configure your own modified-letter-based 
hotkeys and let the (unmodified) arrow keys remain the generic navigation 
keys they normally are.

Meanwhile, there's actually THREE (well, four...) ways to configure 
hotkeys, aka keyboard shortcuts, in pan, the new GUI way using the 
shortcuts page of preferences, editing the pan.hotkeys file directly, or 
editing the old accels.txt file that (I think) pan still reads/writes for 
backward compatibility.

If you use the GUI, restart pan immediately after you're done customizing 
to ensure the two files are updated correctly, as pan doesn't write out 
some settings until it shuts down and I'm not sure whether shortcuts are 
among settings only-written-at-shutdown or not.

If you edit the pan.hotkeys file directly, pay attention to the 
instruction comments within, and of course edit it with pan not running so 
it can load the new settings when it starts up.

Accels.txt is for backward compatibility and isn't something I'd recommend 
editing manually but it used to be the only way.  If you open it in a text 
editor I think you'll see why a new solution was needed.  (It's basically 
just a to-humans-unordered dump.)

Early gtk and pan trivia:  Back in the late gtk 1 and/or early gtk 2 era 
when accels.txt was the only pan hotkey storage file and the shortcuts 
prefs page didn't exist yet, gtk menu hotkeys weren't /really/ supposed to 
be configurable at all at the gtk level.  So the "gui configuration 
method" to configure hotkeys for /any/ gtk app involved first manually 
adding some obscure non-default setting to some gtk config file to allow 
the gtk menus to be hotkey-configured, and of course for it to be 
remembered for the next run the app had to dump an accels file at shutdown 
and load it at startup, too, which most apps didn't but pan did.  Then 
you'd restart pan (or whatever other gtk app) to pick than up, after which 
you could mouse-hover over a menu entry and hit the desired new hotkey -- 
which worked unless it didn't.  The problem was that it didn't work for 
any of the menu accelerator keys that were pre-configured to move to a 
different entry on the open menu (the "underlined keys" in the menu 
entries) as they'd do that instead of being picked up as the new hotkey, 
and as it involved text-editing that obscure gtk setting in any case, 
which of course you had to know about first, most customizers just text-
edited accels.txt despite the difficulties.  Of course that meant that you 
*really* had to want to customize things before you'd bother (with either 
method), but it was there for those like me that wanted it bad enough.

Then of course there's the /other/ method, both then and now: grab the pan 
sources and patch them to make the defaults what you want, and rebuild 
pan, much like I did recently for pan's color customization when that was 
broken.  That works... if you're determined enough to make it worth the 
trouble.  (Tho for me as a gentooer that's not the hurdle it would be for 
most, as I already build most everything from source so the tools and 
library include files are all there already, as is the machinery to 
routinely reapply local patches on every update.)

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