[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
- lynx-dev lynx: questions and suggestions,
Vlad Harchev <=
- Re: lynx-dev lynx: questions and suggestions, Philip Webb, 1999/03/29
- Re: lynx-dev lynx: questions and suggestions, Webmaster Jim, 1999/03/29
- Re: lynx-dev lynx: questions and suggestions, Kim DeVaughn, 1999/03/29
- Re: lynx-dev lynx: questions and suggestions, David Combs, 1999/03/29
- Re: lynx-dev lynx: questions and suggestions, Vlad Harchev, 1999/03/30