Could you explain what you want to achieve here. I am not sure I understand your use case. Thanks

Focus without opening == focus without marking read?

Yes, the shortcut in AOL Reader would move focus without expanding the item or marking it as read. Here's a video of how it is now: https://gfycat.com/OldBlandAuklet Scrolling behavior from what I can remember from AOL & Google reader was a bit different.

Why not keeping the same shortcuts but adding an option to keep the entries closed? This way there is only one set of keys for motion.

Because then it's one or the other. The default is fine for me but I do regularly find myself going j, r. Dunno how it'd pan out in practice but I can definitely see some potential. :-)

What I mean is that:

• we already have the j and k to move around
• we already have the c to open/close an entry

We could add an option to define the default state of an entry (open/close) and link the reading function on the open/close action.

That's exactly what I mean too. That's binary. Such settings are useful if you don't like the default at all, but not if you generally like the default.

I see what you mean. I still find having 2 sets of keys to move around is kinda weird.

PS I think n and p specifically are weird and far apart. Something like u and i or n and m seems better.

Vim uses ctrl+b/f.

As long as you can reassign keys, default values are not that important.

Why not keeping the same shortcuts but adding an option to keep the entries closed? This way there is only one set of keys for motion.

Really this is because I want to replicate my habits from AOL (and Google?) Reader(s), and that's how they did it. I remember them as "next" and "previous" and find that my fingers can rest on n,j,k,p easily.

@aledeg You are our mister shortcuts :-P Is it good for you?

@aledeg

As long as you can reassign keys, default values are not that important.

I disagree and I'm sure you do too. ;-) You can't make everybody happy of course but imo you should always design as if there were no options, all the while avoiding the Apple route.

Unless you assume using your left hand to press n and your right hand to press p, then n and p are objectively somewhat suboptimal. (That's the diplomatic way of phrasing it.) The pinky is the worst finger to use because it puts extra stress on the hand. On QWERTY, h and l, i and o, as well as n and m make sense ; on AZERTY maybe only h and l, and i and o.

@mdemoss

Really this is because I want to replicate my habits from AOL (and Google?) Reader(s), and that's how they did it.

That is where configurability comes in, imo.

@Alkarex

You are our mister shortcuts :-P

I'm not "our" mister shortcuts but I did maintain a very heavily customized Opera keyboard shortcut set for over half a decade. It's vaguely similar in principle to Vimperator I suppose, although it dates back to '04 or '05. I've given the matter of keyboard layouts and keyboard shortcuts more thought than most. :-P

@Frenzie
What I meant was that either i and o or m and n is fine for me. As long as the one we choose as default is usable and that it can be changed via configuration, it's good enough.
I am using a qwerty so both solution are equally good for me.

@Alkarex
The code itself look good but I haven't tested it. I might have sometime later this week though.

@aledeg Cool! I misunderstood. :-) I propose i and o then?

@aledeg Something based on element height might make more sense than window height glancing at the code (new_pos -= $(window).height()/4) but I haven't tried it yet.

And yes, we'd expect Shift to work. :-)

@Frenzie the scrolling parameters made the experience really smooth. It didn't bothered me that it was based on window. I have no opinion on what is best for that matter.

It's the kind of thing that jumps out to me as suspicious because it might inadvertently be based on an effective window height of some 600-800 without properly taking into account 200 or 2000. But like I said, might. :-)

@aledeg or @Frenzie Could you please take care of this issue?

@Alkarex I don't have permission to push to the repo.

@Frenzie Ok. If you know the changes to be done, I then suggest we merge here, and you make a new PR with the remaining changes

I'm not entirely sure how @aledeg envisions the config page but the two suggestions I added are probably the main thing.

Something like this perhaps?

@Frenzie Good for me

Alright, I'll stick it in a follow-up PR.

I am late to the discussion, but what would you think of using 'up' / 'down' as default shortcuts for these new skip to the previous / next ? (standard in mail clients such as Outlook, GMail... and other lists)

I'm not the biggest fan of that, but as long as it doesn't interfere with scrolling in opened articles I'm ambivalent toward it.

Good point @Frenzie . With the current implementation, it would indeed interfere in a negative way with open articles.