lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev reverse search


From: Vlad Harchev
Subject: Re: lynx-dev reverse search
Date: Fri, 28 Jul 2000 13:20:41 +0500 (SAMST)

On Fri, 28 Jul 2000, Kim DeVaughn wrote:

> On Thu, Jul 27, 2000, Thomas E. Dickey (address@hidden) said:
> |
> | On Thu, 27 Jul 2000, Kim DeVaughn wrote:
> | >
> | > Ah yes ... I remember now from when I added external editor capability
> | > to TEXTAREA's.  And unfortunately, at least one of the structs is only
> | > singly linked ... :-( ...
> |
> | I had an impression of that.  But a nice utility function that searches
> | from the top of the page to the previous struct would alleviate that.
> 
> Yes, that would do the trick (and is what I think Vlad was suggesting
> in his "rude hack" msg :-) ).
> 
> FWIW, I considered converting the TextAnchor struct to doubly linked,
> when I was working on the external editor stuff, but didn't because I
> didn't see any problem with performance, even on some moderately big
> pages.  It wasn't worth the time, effort, and *risk* in trying to find
> *every* place in the code that would need to update a newly added "prev"
> pointer, for a very marginal increase in performance (if such could be
> discerned at all in realtime).
> 
> WRT doing so for some kind of reverse search function, I'm inclined to
> feel the same way ... most pages are short enough that performance is
> probably not an issue with an always-start-at-the-top approach; only on
> very lengthy docs might it become one.
> 

  Yes, and I think reverse-search patch will be no bigger than 7 Kb if such
approach is used (i.e. it will be easy to code it). 
  The only problem I remember is chosing the default key for reverse search
command.
 
> On the subject of regexp's ... yup, that'd be a nice thing to have ...!
> 
> On the down side, as someone (Vlad ?) mentioned, there are a number of
> different RE libs out there ... some with various, uhmm, "shortcomings"
> (aka, bugs) in them; choosing the "best" one to use isn't at all obvious
> (as we discovered in mutt development, a couple years ago).
> 
> Then there's the multi-platform problem (UNIX, VMS, DOS, OS/390, ...).
> 
> And mention was made of unicode support (and other multi-byte stuff).
> 
> I forsee alot of ifdef's and/or config options ... all of which *could*
> be done.  But is it really worth it?

  Since (if we try to be nice) the support for unicode is necessary, I think
no ifdefs will be required - we'll have to bundle (or strictly require to
be installed) one of the rx libs that support unicode (most probably Spencer's)
and use only it. So, I think only one define EXP_SUPPORT_RX or similar will be
added.

> /kim
> 
> ; 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]