Re: [elinks-users] Cache problems?
On Sun, Jul 16, 2006 at 02:26:11PM +0200, Jonas Fonseca wrote: > Maybe we should make some of this into a FAQ since you are not the first > one to point this out. Oops, sorry, I guess I didn't dig deeply enough in the archives Thanks for replying. > ELinks' caching behaviour is not very conforming. Historically ELinks > has used a very agressive caching policy, once it even cached redirect by > default. This doesn't mean that we don't want to fix it at some point > but there are several things to be aware of such as usability. > > Over a year ago, I tried to work on it and it quickly got very annoying > for many pages to have it constantly reloading, partly because the > incremental rendering often will cause the current link to change if you > go back in history etc. I guess I don't quite understand the issue. It seems like the graphical browsers pretty much handle this properly these days. (Maybe there's an argument about going back to a cached copy of the page vs. a reload.) Would you say that mimicing firefox's behavior would be a good goal? I can tell you that the scenario I initially described, where a loaded page via a clicked link is out of date and I'm not even aware of it, seems to me like a bad thing. In any case, I can appreciate the possible difficulty of implementing this correctly, so I'm not complaining much! I didn't know before asking whether it was just me, a bug, a design decision, or what. > So that was my take on the status of ELinks' caching behaviour, it > doesn't help you very much and I am sorry about that. There is always > the link-follow-reload action which might help you to some degree. Oh, I wasn't aware of that. That sounds useful as a workaround, thanks. Reid ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] elinks crashes when hooks.pl is used
On Thu, Jul 13, 2006 at 08:17:32PM -0400, jeff wrote: > hello, everyone, and thanks to everyone who has worked on elinks; i'm > greatly enjoying it. > > i'd like to do some programming for it, but it crashes when i try > to use the bundled perl hooks file. i'm using the 0.11.1-1 debian > package, and when i copy the contributed hooks.pl and config.pl from > /usr/share/doc/elinks/examples/contrib/perl to ~/.elinks, elinks > crashes with these messages: There were some fixes done to the GIT version od ELinks (0.12) that might address this -- can you check to see if you can reproduce it using that version? -- Thomas Adam -- "If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat." -- Incredible String Band. ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
[elinks-users] elinks crashes when hooks.pl is used
hello, everyone, and thanks to everyone who has worked on elinks; i'm greatly enjoying it. i'd like to do some programming for it, but it crashes when i try to use the bundled perl hooks file. i'm using the 0.11.1-1 debian package, and when i copy the contributed hooks.pl and config.pl from /usr/share/doc/elinks/examples/contrib/perl to ~/.elinks, elinks crashes with these messages: -- ELinks 0.11.1 (built on May 24 2006 20:12:14) Features: Standard, Fastmem, IPv6, gzip, bzip2, Periodic Saving, Timer, Cascading Style Sheets, Protocol (File, FTP, HTTP, NNTP, SMB, URI rewrite, User protocols), SSL (GnuTLS), MIME (Option system, Mailcap, Mimetypes files), LED indicators, Bookmarks, Cookies, Form History, Global History, Scripting (Lua, Perl), Goto URL History, Search History elinks(dump_backtrace+0x23)[0x80d0173] elinks[0x80abca4] elinks[0x80ac17f] [0xe420] elinks[0x80c03b5] elinks[0x80a27df] elinks(trigger_event+0x14)[0x80a2834] elinks(get_hooked_uri+0x44)[0x80c5e14] elinks(goto_url_with_hook+0x40)[0x80c67e0] elinks(goto_url_home+0x32)[0x80c6842] elinks(init_session+0x1dc)[0x80c46ac] elinks(decode_session_info+0x2b3)[0x80c4bc3] elinks(in_term+0x2fe)[0x80c860e] elinks(select_loop+0x1f6)[0x80a4106] elinks(main+0x41)[0x80a3791] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd0)[0xa7bcdeb0] elinks[0x8059891] -- does anyone have any suggestions? i tried using the bug reporting system before writing here, but both times i tried to register an account, i never received the password that was to have been sent to me. sincerely, -- jeff covey http://jeffcovey.net/ signature.asc Description: Digital signature ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] Re: Make errors on OSX
Daniel E. Macks <[EMAIL PROTECTED]> wrote Wed, Jun 28, 2006: > Clayton Smith <[EMAIL PROTECTED]> said: > > It's pretty unusual to link all those .o into a giant .o instead of > archiving them in a .a, and it also makes it harder to track down > where symbols definitions actually are. So elinks-devels...why is that > being done? I will try to answer you ramblings. Before the new GNU make "based" build system was introduced we used .a files. There was one problem with this, namely that some of these .a file had inter-dependencies when the final elinks binary was being linked together. So everytime you needed to add a new .a file you needed to randomly try to insert it into the list of .a file until you found a way that didn't conflict and errored out with undefined symbols. This was solved with not using .a files. Recursively linking things into a general $subdir/lib.o also makes it easier to add new directories and implementing conditional directory decending. Now for every directory in SUBDIRS you can just check for $subdir/lib.o and link it in if it exists. Before you could end up with .a files in every subdir and then you needed to specify that this $subdir/$subsubdir/lib.a should be linked in. If there is a portable way to link several .a files into a super .a file then that could of course also be used. If I recall correctly, I didn't (bother to ;) figure out how to do that. > I'm having trouble finding clear documentation of the > changes you've made from the official gettext distro. Yes, we should probably have done that. One thing I know of (apart from switching gettext to mostly use ELinks's memory management system and coding style instead of that horrible GNU one ;) is that _() will take a terminal struct as an arg. This stems from the fact that several terminals can exist, each with a different locale. It's probably not so common in practice and I don't know why we bother to support that, but it obviously has to do with ELinks instances being able to connect to each other and share cache info etc. to minimize memory usage. > > Here is the command that runs that actually produces the error: > > > > [EMAIL PROTECTED]/docs/downloads/elinks-0.11.1/src$ gcc -g -O2 -Wall > > -fno-strict-aliasing -Wno-pointer-sign -o elinks lib.o -lssl -lcrypto > > -ldl -lz -lbz2 -liconv > > /usr/bin/ld: warning multiple definitions of symbol _locale_charset > > lib.o definition of _locale_charset in section (__TEXT,__text) > > /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libiconv.dylib(localcharset.o) > > definition of _locale_charset > > There's long been a symbol with the same name in gettext (libintl) and > iconv (libiconv). It usually only triggers a warning on OS X because > each symbol lives in its own lib's namespace. If both definitions of > the symbol wind up in the common namespace, however, there is a > (fatal) collision. There might be a flag to instruct the linker to use > symbols in the specific .o before those in the -l libs? > > The brute-force solution would be to rename the offending symbol in > the elinks gettext. This would probably be the best way to finally put this warning to rest. There was talk about adding support for linking in a local gettext version but for the reason I've explained above regarding _() this will probably never happen and messing with various variables should be safe. -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] New elinks user - three months of happiness..!!
cga2000 <[EMAIL PROTECTED]> wrote Tue, Jul 04, 2006: > On Tue, Jul 04, 2006 at 02:15:44AM EDT, Thomas Adam wrote: > > On Tue, Jul 04, 2006 at 01:51:44AM -0400, cga2000 wrote: > > > I also have a minor problem with sites that use a screen-wide color > > > background to highlight headings. But this may be due to my terminal > > > (xterm+gnu/screen) configuration. I have this problem with the gentoo > > > main page for instance and would be curious to know if others see the > > > same thing I am seeing. > > > > I couldn't say -- the page looks fine to me. You could always take a > > screenshot. > > http://www.geocities.com/cga/gen.png > > normally the purplish-blue background of "Gentoo Weekly Newsletter" .. > etc. should extend as far as the column at the extreme right of the > screen. Here, it stops with the text .. right after the '6' of 'July > 2006". Good news if you don't see this, then likely it's only a matter > of my configuring my terminal correctly. I see this too and it has to do with ELinks only painting/applying the background color for text since it doesn't now anything about stuff like the CSS box model. Tables are treated in a special way so that is why you see the background color applying correctly to the table cells on that page. There might be hope in the future since the a few ELinks developers are talking about meeting at the end of August and this would indeed be a fun thing to work on (if nobody gets it working before that ;). -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] enhancements
Mike Miller <[EMAIL PROTECTED]> wrote Fri, Jul 07, 2006: > Hi, Hi Mike, > If the developers read this list, I wanted to say thanks! This lazy developer does. > To my surprise my enhancement bugs were addressed in the newest > version (0.12.GIT). The new options are: > > ui.tabs.top > ui.show_menu_bar_always Thanks for the feedback and of course thanks to Witold for implementing this back in May. :) -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] Cache problems?
Reid Rivenburgh <[EMAIL PROTECTED]> wrote Fri, Jul 14, 2006: > On Fri, Jul 14, 2006 at 06:39:23AM +, Miciah Dashiel Butler Masters wrote: > > Go to Setup -> Options manager -> Document -> Cache -> Ignore > > cache-control info from server and set that option to 0. > > I forgot about that option. That's already set to 0. Maybe we should make some of this into a FAQ since you are not the first one to point this out. ELinks' caching behaviour is not very conforming. Historically ELinks has used a very agressive caching policy, once it even cached redirect by default. This doesn't mean that we don't want to fix it at some point but there are several things to be aware of such as usability. Over a year ago, I tried to work on it and it quickly got very annoying for many pages to have it constantly reloading, partly because the incremental rendering often will cause the current link to change if you go back in history etc. So that was my take on the status of ELinks' caching behaviour, it doesn't help you very much and I am sorry about that. There is always the link-follow-reload action which might help you to some degree. -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] redirects with user defined protocols
Jonas Fonseca <[EMAIL PROTECTED]> wrote Sun, Jul 16, 2006: > This thing uses the --remote switch which really isn't ideal because it > will cause the screen to be cleared so you have to press ^L to redraw > it. ;) This is of course a bug. Running ELinks with the --remote screen shouldn't need to touch the screen at all, but I didn't bother to fix this when I was working on it. Also, if you want to change the URL of the current tab you should use: elinks --remote "openURL($url)" And ensure that $url is properly escaped. See elinks(1) or elinks --long-help for info about the --remote switch. -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
Re: [elinks-users] redirects with user defined protocols
Nigel Hamilton <[EMAIL PROTECTED]> wrote Wed, Jul 12, 2006: > Hi, Hi Nigel, > I'm using elinks to browse source code and a user defined protocol > (e.g., goo://) to call an external text editor (e.g., vi, emacs etc). This > works really well! > > However, after I finish editing the file I would ideally like to > return to elinks and redirect it to another URL. Any ideas on how/if this > could be done? I could only think of a rather hackish way to do this (see below), but we should maybe have a reload from editor hook that you could script in Lua/Perl/Ruby/JavaScript ... This thing uses the --remote switch which really isn't ideal because it will cause the screen to be cleared so you have to press ^L to redraw it. ;) elinks-0.11.0-gef05126:~/src/elinks/0.12 > cat editor #!/bin/sh vi $@ url="g asdf" (sleep 1; elinks --remote "$url") & elinks-0.11.0-gef05126:~/src/elinks/0.12 > EDITOR=./editor ./src/elinks ... -- Jonas Fonseca ___ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
