lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev lynx: questions and suggestions


From: Vlad Harchev
Subject: lynx-dev lynx: questions and suggestions
Date: Fri, 26 Mar 1999 15:42:51 +0400 (SAMT)

 Here are some questions:

   Memory management:
*Lynx thoroughly registers functions  (via atexit) that will free up allocated
 memory chunks. IMO it's not necessary at least on "normal" systems - allocated
 memory is always reclaimed at the program exit. Not registering functions that 
 clear allocated space possibly will yield performance increase since
 (as I understand) it let libc routines to clear the memory in the way it 
 thinks optimal (in the order the chunks are in the memory manager lists). 
     IMO it's safe to make such optimization for all Unixes and possibly 
 Windows. Am I right ? Please correct this list of OSes if something wrong.
 
* Lynx memset's to 0 'links' and 'history' in 'main' (their total size is 
~85Kb).
 IMO it's useless since unitiliazied data is always fill by zeros. May be this
 operation should be done exclusively on those OSes, under which it's not 
 correct. This will slightly speedup invokation time at least on slow machines. 
     IMO it's safe to make such optimization for all Unixes and possibly 
 Windows. Am I right ? Please correct this list of OSes if something wrong.
 
  Keyboard layout:
* It seems that there are only very few keys that are unassigned. May be it's
  time to switch to handling of key sequences (may be limiting their length by
  two keys for now, like ^x-s)
  
     LSS support:
* May be it's time to declare lss support non-experimental and, may be, make 
  it be compiled-in by default? IMO it doesn't have apparent bugs in 
  implementation.
* May be it will be useful to include more examples of .lss files with 
  distribution so that non-experienced users be able to select one of them 
  instead of composing their own? (I can post mine and the one that was sent 
  by Sergey Svishchev <address@hidden>).
* To lss experts: IMO the TrimColorClass and mine FastTrimColorClass(added by 
  my patch) calls can be avoided. They are used to compute the hash code of
  the style that should be stacked off, and that hcode is used in the following
  way in HTML.c:HTML_end_element: 
    HText_characterStyle(me->text, hcode, STACK_OFF);
  The LYCurses.c:curses_w_style function doesn't use the value of the style 
  when dir==STACK_OFF, so arbitrary value can be passed instead of hcode.
   Eliminating TrimColorClass will eliminate the need for maintaining 
  Style_className and can increase perfomance be 10%. 
  

  New features I hope I will be able to add sometime (but I'd like somebody 
  implemented them :) :
*Regex matching
  I'm planning to use Stallman's regex library since it offers  the ability to
  select the regex style - for example - whether |,+,?,(,),{,} are special 
  symbols (and their slash-escaped versions are literals) or vice versa.
  Since it's impossible to make rx searches in multibyte strings, IMO the string
  search command (as implemented now) should be preseved.
     Now, the question is: what keys should the rx searches be assigned to.
  Note: IMO ability to do case sensitve and case insensitive rx-searches is 
very 
  desirable (and may be these variants should be treated as different commands).
     IMO they should be key-sequences if key sequence support will be 
 implemented.  What do you think?
 
* Marks (as in less):
  I plan to implement the one-letter marks (as in less) and string marks (the
  mark is identified by the string rather than by a single character, probably 
  with the ability to display a list of marks in current document and the 
  ability to activate them from that list). In order
  them to be screen resizing-safe, I plan to do the following:
   count non-white non-underscore characters (underscores are used to display
  <br> so their count is not equal for different screen sizes), and for each 
  line, store the number of such characters in preceeding lines. Marks are
  bound to line at the top of the screen. When screen resizing is detected,
  the stored counts of 'letters' is associated with each  mark, and after 
  reloading the document (or during the reloading) marks are rebound to new 
  lines. IMO Mark support requires the following commands - and each of them
  should be bound to some key sequence:
   set one-letter mark
   set string mark
   goto one-letter mark
   goto string mark
   clear all marks (may be two commands - one for one-letter and another for
                   string marks)
   show mark list (probably as a page with hyperlynks to mark locations)
   
  What keys/key sequences do you think should be assigned to these commands?   

 What do you think?
 Best regards,
  -Vlad

reply via email to

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