nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] unbinding/reassigning two or three keys


From: Benno Schulenberg
Subject: Re: [Nano-devel] unbinding/reassigning two or three keys
Date: Fri, 10 Apr 2015 10:20:39 +0200

Hi Chris and everyone else,

On Thu, Apr 9, 2015, at 22:01, Chris Allegretta wrote:
> I assume this is for 2.5 series you are talking about.

Ehm... I would have liked to change M-B right now, but I realize
now that this is far too soon.  And also, it's not necessary:
users can do it themselves if we only add the abilty to do so.
Currently it's not possible to bind the Backwards toggle in
the main menu.  Would it be okay to add that possibility?

> I strongly encourage people to chime in here,

Yes, please!

> On the topic of what's finger memory: I tend to use M-F right from the
> main menu personally, it's just finger memory for me at this point to
> type M-F,^R.

Okay.  Strange, but okay.  :)

> I think changing M-W is probably not a great idea at this point: [...]

I did not intend in any way to do that.  I was just conjecturing that,
if the functions find-next-forward and find-next-backward became
available, I would bind them to M-N and M-B and never use M-W again.

(Currently, when you're doing M-W several times and then realize you
want to go back to the previous occurrence, it takes three key strokes:
^W M-B <Enter>.  With the proposed M-B direction toggle in the main
menu, it would take just two: M-B M-W.  But better still would be to
have the direction-specific search functions, then it would be just
one key stroke.)

> M-N I also never use anymore and I think its function is quite
> antiquated, so it could probably be repurposed.  But....

Okay.  But I won't repurpose the key, as you've shown quite clearly
that this isn't a good idea.  But the other question: to add it to
the Read File menu, would that be okay?  It just adds something,
without changing any bindings -- if the user happens to have bound
M-N to something else in that menu, their binding will stick and
No-Convert will be overridden.

> In the general case I think while nano may be inconsistent, people
> have been using it for many years or even decades - there are some key
> bindings which I think are just bad (e.g. ^w introduces bad finger
> memory for people using web browsers) [...]

True.  It happens to me about once a week.  :)

(Luckily there is Ctrl-Shift-T.)

> The meta issue here is that we've given people the ability to
> customize a lot of this to their liking already, and changing the
> default keys may cause even more need for people to rebind to get back
> to what they're used to or at least expect.  Unfortunately, a lack of
> response on this thread doesn't mean that there are not scores of
> users who wouldn't want us messing with the key binding for X feature;
> they just don't subscribe to this list or follow nano development
> closely enough as they are happy with it as-is. Such changes could
> take a year or several to find its way onto the operating system
> they're using today and then could be hard to undo.  The feedback
> mechanism is not very tight here so the risk is high of an unexpected
> adverse response some time later.

Agreed on all points.

> I don't think changing default keybindings is going to win us a lot of
> extra users but it certainly risks alienating some.  Honestly I think
> we should tread lightly here.  Potentially engage some of our
> followers on facebook or twitter about this discussion and see what
> they think (if you use either of these platforms) - or if you don't
> perhaps put up a poll and email info-nano about it.

I don't tweet nor book face.  And to put up a poll...  I wouldn't do
it about default keybindings, as it's not a good idea to change those
anyway, but I am pondering one about requested features that I would
like to see included (without being bound to any key, as there's no
room).

Thanks for the detailed response.

Benno

-- 
http://www.fastmail.com - A no graphics, no pop-ups email service




reply via email to

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