Re: setedit and elinks

[Salvador E. T. <sal...@in...>]

On 14/08/06 08:51, wi...@po... wrote:

>U=BFytkownik Salvador Eduardo Tropea napisa=B3:
> =20
>
>>On 13/08/06 10:25, Witold Filipczyk wrote:
>>
>>   =20
>>
>>>Hi!
>>>I'm a new user of setedit. I must say it looks good.
>>>I have some problems with debugging elinks.
>>>elinks.txt was created like this:
>>>cd elinks
>>>find . -name "*.[ch]" > elinks.txt
>>>Then I created the elinks.epr based on elinks.txt
>>>I don't know why some files are visible with "full" path, I mean
>>>eg. ./src/protocol/nntp/connection.h and some files only basename,
>>>eg. beos.c
>>>
>>>
>>>     =20
>>>
>>Is that for files with the same name but different path?
>>   =20
>>
>
>There is no rule. Some files are "duplicates", but beos.c is only one.=20
> =20
>

Can you send me elinks.txt?

[snip]

>>>Another bug is a tvision bug. I use ATI framebuffer and
>>>cursor leaves trace. It's annoying.
>>>
>>>
>>>     =20
>>>
>>This isn't a bug in the editor but in some frame buffer implementations=
=2E
>>The editor doesn't even know you are using frame buffer, it just moves
>>the cursor and draw like when using a regular Linux terminal. The frame=

>>buffer should ensure that old cursor drwings are removed before drawing=

>>it again. Most frame buffer implementations have bugs and limitations i=
n
>>the cursor handling. Last time I checked only a few of them implement
>>the code to change the cursor size ... Some implementations have very
>>odd bugs, I remmember one that failed to set up the font when you
>>changed the resolution "on the fly".
>>I know that this particular bug (cursor trace) isn't triggered by other=

>>applications, but the editor can't be blamed.
>>   =20
>>
>
>=20
>
>I thought it was a bug in  rhtvision. No other terminal application
>
>do something like this. The TVision character map do the same (trace).
> =20
>

Most probably that's because no other terminal application puts as much=20
stress in the terminal code. The program isn't in charge of cursor=20
drawing, that's kernel job and beleive me frame buffer should be renamed =

"frame bugger", most implementations of the frame buffer are quite bad=20
and this situation isn't getting better as time goes by. I guess that=20
people preffers graphical user interfaces and nobody really cares about=20
Linux console, which is really crappy BTW. If you take a look at the=20
Windows console API (yes it have it even when most people doesn't even=20
know) you'll see the implementation is far better than what Linux=20
provides as API, of course: Windows API is full of bugs and limitations, =

but is better than Linux ... it sounds crazy because Linux is much more=20
"terminal oriented", but take a look at the TVision low level drivers=20
and you'll see what I mean.

Regards, SET

--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013