Re: [netrik] Input System Proposal
Status: Beta
Brought to you by:
antrik
From: sarneaud <Sim...@ut...> - 2010-05-15 11:20:34
|
----- Original Message ----- From: ola...@gm... Date: Saturday, May 8, 2010 3:02 Subject: Re: [netrik] Input System Proposal To: net...@li... > 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. I agree. Personally, I've tweaked a few keys on my Vimperator install but I expect most users won't care. I think it's more likely that users will download key configs made by others than make their own if they want changes. Configurability is a just side benefit of keeping data out of the code. > There is a deeper problem as well: trying to cover various > options in > the UI limits the possibilities for optimisation. Changing the > behaviourin 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. In this case, though, I'm certain there will never be any overall benefit to optimising the response time to special cases of keyboard input sequences. > 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...) I agree that would be neat. Most programs with good runtime configurability persist the configuration with config files, of course. > ... > 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. Both approaches have pluses and minuses so I don't think it's clear right now. My feeling is to make the code clean enough that either (or both) can be taken up in future, which isn't a bad idea anyway. *shrug* > > 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? Hmm, I use it heaps in vi, sometimes in less and rarely in vimperator. Vimperator quickmarks are what I really use. Because it's such a vi thing, maybe it's worth having a simple implementation anyway, in such a way that it is low overhead (an extra pointer per page) when not used. Simon |