Re: [netrik] Input System Proposal

[<ola...@gm...>]

Hi,

On Thu, May 06, 2010 at 12:20:14PM +1000, sarneaud wrote:

> Hi, I came across netrik when I was looking for a browser that would
> let me read html documentation conveniently.  I love the vi interface
> of vimperator and the rapid load time of links and netrik seems to be
> heading for a best of both worlds.

I see. Good to know about specific use cases :-)

> Anyhow, I've come up with a way to handle complex keyboard input and
> built a working sample into the netrik source.

Great :-)

> Complex keyboard handling involves managing a lot of different states,
> so in this system input is handled using a finite state machine (FSM).

Indeed that's what I was considering myself. In fact all the parsers
(HTML, HTTP, URL) in netrik use an FSM approach as well :-)

> * Configurability.  The FSM is configured using a (soon-to-be)
> user-friendly config file.  If the user prefers emacs-style bindings,
> that should be fine.

I must admit that over the years, I have become pretty sceptical about
configurability in general.

For one, it tends to add considerable complexity that few people
actually use. The more individualist ones will probably configure their
own keybindings the first time they set it up; and perhaps also the
second... But when sitting at another system for the third or fourth
time, they's just go "oh fuck it", and stick with the defaults.

However, that's only the individualist ones -- the majority of people
won't even bother the first time...

There is a deeper problem as well: trying to cover various options in
the UI limits the possibilities for optimisation. Changing the behaviour
in one single point means that other things become inconsistent,
awkward, or outright impossible. For a consistent and efficient UI, all
bits need to be custom-fit to each other -- it just doesn't work when
individual options can be configured independently.

The only realistic way to customize the UI is writing alternative
implementations, with their own complete set of consistent keybindings,
behaviours, etc.

Thus I'm more inclined towards the route that "less" has chosen: offer
the most common key combinations from both Vi and Emacs, but don't
implement any configurability. (Except perhaps for special cases like
the alternative cursor key handling that's already in place for the
benefit of braille interface users...)

Having said that, it would be nice to have a "map" facility for macros
like in Vi; and this can *also* be used for completely changing the
keyboard mapping, though only in a rather awkward fashion...

Also note that I don't really believe in static configuration files.
Almost all settings should be possible to change within the running
application.

(Admittedly, netrik doesn't have any facility for this so far...)

> * Multi-task friendliness.  The more involved commands (such as
> document search) currently keep state using function calls, which
> block all other processing.  Because the FSM automatically keeps track
> of state, it should be straightforward, for example, to have an
> incremental search happening while pages are loading in the
> background, without any special coding.

Indeed this is *one* of the reasons why I have preferred the FSM
approach: my original plan was at some point to implement some kind of
continuation mechanism, so we could get parallelism without using
threads...

However, nowadays I think that functionality which is seperate enough to
make sense running in parallel, most of the time probably can be split
off into separate processes alltogether.

I haven't yet started reworking netrik in such a manner; but it formed
into a rather firm determination by now...

On the other hand, going by YAGNI, until I actually start doing it, this
plan shouldn't affect the current design :-) Also, there might be some
cases where in-process concurrency will still be necessary. In either
case, it can't hurt to have the option.

(Just to be clear: I like the FSM approach anyways, regardless of these
considerations :-) )

> Also, because it's a complete system for keyboard input, other things
> are possible, such as vi-style command repeats.  This is already
> implemented.  "20l" scrolls down 20 lines.

Great :-)

> My code also has a basic implementation of page marking with m and '.

Well, this is one thing I originally meant to implement; but I must
admit that I'm not so sure anymore... While it seems useful, I don't
think I ever actually used this feature in w3m -- probably because it's
needed so seldom, that in the few cases where I *could* have used it, I
didn't even think of the possibility...

I'd like to know whether it's just me, and other people use it more
regularily?

> If you are interested, I can upload my code and go into more technical
> details about how it works.

Sure :-) It's one of the things that have been on the ToDo list for a
long time.

-antrik-