lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev libreadline


From: brian j pardy
Subject: Re: lynx-dev libreadline
Date: Sat, 11 Dec 1999 22:46:42 -0500

On Sat, Dec 11, 1999, Klaus Weide wrote:
> On Sat, 11 Dec 1999, brian j pardy wrote:
> > On Fri, Dec 10, 1999, Vlad Harchev wrote:
> > >  I'm not familiar with libreadline as programmer, but as a user (of
> > >  bash for example :) I wish to warn you - readline behaviour is:
> > >  when user input is longer than screen, next line (and so on) are
> > >  used for displaying user input (I don't know whether this could be
> > >  turned off programmatically). Such behaviour will make screen
> > >  looking confusing (user input is scrolled in current implemenation
> > >  of prompts in lynx).  
> > 
> > That's true.  AFAIK it can't be disabled in .inputrc, I just did a
> > quick skim of my readline manpage, but I think I have an old version.
> > 
> > If it can't be disabled, we may have to just consider that an artifact
> > of using readline and warn about it.  
> 
> That would be completely unacceptable (for anyone, I would think).  Gain
> some benefit (which I don't really see) for the price of completely
> messing up the display?  It doesn't make sense.

Actually, I just downloaded and compiled readline-4.0.  It has an
option to side-scroll as opposed to wrap (set horizontal-scroll-mode
in .inputrc, assume can be done in the source).

Also -- I'm not proposing completely switching over to readline, just
the possibility of a compile-time choice.  From a quick skim of the
source, I think it might be possible to #ifdef out a bit of the edit
handling code, if someone wants to use readline.  The only area where
I think it could possibly be used is when there's a simple line
prompt, such as for save file name, or when composing mail.  I'm not
sure it could be manipulated into handling form fields or anything,
nor if that would even be desirable.

As for the benefit, that would be wholly subjective.  I like using vi
commandline editing, with a bunch of additional keybindings for the
emacs control keys.  Using readline would allow users to set bindings
only in .inputrc, and have all readline-using apps follow that.

> That said, try the following experiment anyway:
>      TERM=dumb bash

Apart from ^A and ^E not working (which I think is a side-effect of
not having my bash rc scripts set up -- I use zsh), what am I looking for?

-- 
You're already carrying the sphere!

reply via email to

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