Re: [Edbrowse-dev] protocol handlers and outputting to buffer

2018-02-11 Thread Adam Thompson
On Sun, Feb 11, 2018 at 11:54:53AM -0500, Karl Dahlke wrote: > Thank you for raising this issue. > Edbrowse has native support for ftp, but ftp has no headers and no help, so > edbrowse is a bit limited in its understanding, as is every other ftp client. > I know what you mean about a gopher

Re: [Edbrowse-dev] protocol handlers and outputting to buffer

2018-02-11 Thread Adam Thompson
On Fri, Feb 09, 2018 at 03:10:24PM -0500, Karl Dahlke wrote: > curl has gopher support. > Tell edbrowse to use curl to download anything gopher, just as it downloads > http or https. > Look at http.c line 937, perhaps we can just add gopher to the disjunction. > Perhaps headers will come across,

Re: [Edbrowse-dev] nasa slow

2018-02-11 Thread Adam Thompson
On Sat, Feb 10, 2018 at 11:00:44PM -0800, Kevin Carhart wrote: > On Sun, 11 Feb 2018, Karl Dahlke wrote: > > > > NASA needs it in order to run, right? > > > > No, they don't, and that's the point. It's just a big time waster from our > > point of view. > > Acid test 0 needs it, and that's what

[Edbrowse-dev] protocol handlers and outputting to buffer

2018-02-11 Thread Karl Dahlke
Thank you for raising this issue. Edbrowse has native support for ftp, but ftp has no headers and no help, so edbrowse is a bit limited in its understanding, as is every other ftp client. I know what you mean about a gopher menu, ftp presents each directory as a menu, showing subdirectories and

[Edbrowse-dev] protocol handlers and outputting to buffer

2018-02-11 Thread Karl Dahlke
http.c ftpConnect() and parse_directory_listing(). You might need gopher analogies for these two functions. Obviously you'd rename the second to parse_ftp_directory() or some such, then make a gopher version. Seems doable. Some of the complexity of ftpConnect is that we can download, or even

[Edbrowse-dev] stackoverflow and css

2018-02-11 Thread Karl Dahlke
The css portion, that maps css attributes over to objects, takes 2 minutes to run. That's not the infinite loop, but it is intolerable nonetheless. Browse www.stackoverflow.com with db3 and watch 2 minutes go by between execute eb$qs$start execution complete The version we got was built to run

[Edbrowse-dev] stackoverflow and css

2018-02-11 Thread Karl Dahlke
Ok, querySelectorAll was built to run once and work, without regard to the fact that it might run thousands of times over. Imagine a routine querySelectorAll_prep that traverses the document tree and does things like hashnodes[e.nodeName].push(e); So all the div nodes are in the array

Re: [Edbrowse-dev] stackoverflow and css

2018-02-11 Thread Adam Thompson
On Sun, Feb 11, 2018 at 01:53:51PM -0500, Karl Dahlke wrote: > The css portion, that maps css attributes over to objects, takes 2 minutes to > run. > That's not the infinite loop, but it is intolerable nonetheless. > Browse www.stackoverflow.com with db3 and watch 2 minutes go by between > >

[Edbrowse-dev] stackoverflow and css

2018-02-11 Thread Karl Dahlke
If you put nojs = js-sec.indexww.com in your config file then stackoverflow browses; we have excised the js with the infinite loop. Once browsed, I can drop into jdb and list out all the selectors in cssList. There are 3198 of them. I have put them on my website for your review.

[Edbrowse-dev] stackoverflow and css

2018-02-11 Thread Karl Dahlke
It's worse than we thought. I always like to build a local test. Download www.eklhad.net/csstest.zip and review. over.css: the selectors from stackoverflow.com, this is their css file. csstest: the file to browse. Browse with db3 of course. eb$qs$start comes back in jig time, which suggests the