Re: Re: setedit and elinks

[<wi...@po...>]

Użytkownik Salvador Eduardo Tropea napisał:
>On 13/08/06 10:25, Witold Filipczyk wrote:
>
>>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
>>
>>
>
>Is that for files with the same name but different path?

There is no rule. Some files are "duplicates", but beos.c is only one. 


>>ELinks has many files, some has the same basename, eg.
>>./src/main/select.c and ./src/dom/select.c
>>While debugging, after pressing a few times F7 setedit shows
>>./src/dom/select.c instead of src/main/select.c.
>>
>>
>
>This is, most probably, a bug (or limitation) in gdb. The problem is,
>most probably, in the way the code is compiled. If the compiler was
>called like this:
>
>gcc ... select.c ...
>
>For both sources, and from different directories, then the debug
>information says "select.c" and nothing else.
>Having two files with the same name in a project is a very bad idea.
>Note that gdb will inform to setedit "we reached line nnn of select.c".

 I see.

 

>
>>Another bug is a tvision bug. I use ATI framebuffer and
>>cursor leaves trace. It's annoying.
>>
>>
>
>This isn't a bug in the editor but in some frame buffer implementations.
>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 in
>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.

 

I thought it was a bug in  rhtvision. No other terminal application

do something like this. The TVision character map do the same (trace).

 

--

Witek