lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev Re: next/prev link


From: Kim DeVaughn
Subject: lynx-dev Re: next/prev link
Date: Tue, 9 Feb 1999 09:09:28 -0800

On Tue, Feb 09, 1999, Klaus Weide (address@hidden) said:
|
| On Tue, 9 Feb 1999, Kim DeVaughn wrote:
| >
| > Do I smell YAO ...?
|
| O = Option?

Si.


| > | Yes, indeed.  The #ifdef FASTTAB code which explicitly tests " c=='\t' "
| > | is wrongly hard coded.  Make it go through the usual command binding
| > | paths.
|
| Compromise:
|  - Make NEW_AND_IMPROVED_NEXT_LINK implementation
|  - make it default mapping for <TAB>
|  - but keep the #ifdef FASTTAB " c=='\t' " test for bw compatibility
| then Kim maps <TAB> to (old) NEXT_LINK and is happy, and we don't need
| YAO.

Oh, *I* wasn't suggesting any change, myself.  But if I were, that is
something like how I'd do it.

What people don't often realize, it that when someone mucks about with
the actual interface (key bindings, display presentation, etc), is that
they *must* provide for backward compatibility, lest some portion of
the user base is bound to be "pissed".

That is, unless the "something" they're changing is *clearly* "broken",
where "broken" implies a SIGSEGV, or some other form of catastrophic
behavior.

Personal preferences do not count as "broken" (unless the user base is
still quite small, *and* a LARGE majority agree).  This is one of the
reasons that I've not kept up with mutt development ... the UI changes
at the drop of somebody's whim.

As may be ... since I personally don't like alot of ifdef's mucking up
the code (because it can become a maintenance and testing nightmare),
if *I* were to implement NEW_AND_IMPROVED_NEXT_LINK, I'd do everything
except give it a default keybinding (unless the code were really large,
in which case I'd *consider* an ifdef), document it, and let the users
KEYMAP bind it as they wish (or don't).

But then, "change integration" (aka, configuration control) isn't up to
me.  I have alot of sympathy for whomever takes on that usually thank-
less job ... (Hi, Tom) ...

/kim

reply via email to

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