lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx2.8.4dev.3


From: Vlad Harchev
Subject: Re: lynx-dev lynx2.8.4dev.3
Date: Sat, 3 Jun 2000 22:46:35 +0500 (SAMST)

On Sat, 3 Jun 2000, Thomas Dickey wrote:

> On Sat, Jun 03, 2000 at 08:21:53PM +0500, Vlad Harchev wrote:
> > On Fri, 2 Jun 2000, Thomas Dickey wrote:
> > 
> > > 2000-06-02 (2.8.4dev.3)
> > >[...]
> > > * remove unused fragments of backspace logic from print_crawl_to_fd() -TD
> >    
> >   I'm not sure that that backspace logic is really unused (seems a
> 
> it could not have been used because it was missing the middle chunk of
> logic that would make the backspaces actually come out.  (whether it
> is good to put backspaces in a report-file is another matter).

  If user requested that behaviour via command line explicitly, we should
assume that it's good for them. But this is very unusual use of backspaces, I
agree, and it could be safe to leave things as they are now (i.e. not to
revert the mods).
  
> >   Thanks for this - without it lynx emitted 80 spaces and newline instead of
> > one newline for each empty line when dumping.
> 
> I noticed this because I tried posting followups in newsgroups.
>    
> > > * modify print_wwwfile_to_fd() to refrain from emitting backspaces when
> > >   the is_reply parameter is true -TD
> > 
> >   In general, with_backspaces is ignored if -dump or -crawl are not 
> > specifed 
> > and the variable LYMain.c:with_backspaces is set to false, so this
> > modification seems to be unnecessary.
> 
> no - it actually was a bug (observed)

  Sorry, what exactly was a bug (the fact that modification was necessary or
there was a bug in the logic?). Your reply could be interpreted in two ways.

> > > * add traces for argument parsing, as well as an environment variable
> > >   LYNX_TRACE which has the effect of the -trace option -TD
> > 
> >   Documentation should be updated too.
> 
> ok.
> 
> >  Tom, did you considered "show document title in xterm window title" patch?
> 
> I considered it, but really only if it were using the termcap/terminfo
> interface (but between that - lack of time to do it right) and that one
> of the most frequent complaints about vim is exactly that sort of behavior,
> I deferred this (will revisit later).

  OK - your experience with termcap/terminfo is not subject to suspection.
  But I don't think that it's fatal to use suboptimal logic - users could
disable lynx's attempts to use xterm window title via lynx.cfg or
commandline.

> -- 
> Thomas E. Dickey <address@hidden>
> http://dickey.his.com
> ftp://dickey.his.com
> 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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