From owner-lynx-dev@sig.net Thu Apr 1 00:45:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA05206 for ; Thu, 1 Apr 1999 00:45:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA05890; Wed, 31 Mar 1999 23:33:11 -0600 (CST) Date: Thu, 1 Apr 1999 00:31:24 -0500 From: Jean-Pierre Radley To: lynx-dev@sig.net Subject: Re: lynx-dev if lynx.cfg is unavailable (was: disabling charsets) Message-ID: <19990401003124.B4419@jpradley.jpr.com> References: <9903311509.aa26791@deepthought.armory.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Klaus Weide on Wed, Mar 31, 1999 at 07:14:12PM -0600 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1165 Lines: 25 Klaus Weide averred (on Wed, Mar 31, 1999 at 07:14:12PM -0600): | | It doesn't need it in order to run somehow. It needs it in order to | know how it is meant to run. It doesn't know whether 'lynx.cfg not | available' is an acceptable condition or not, so it acts according | to 'better safe than sorry'. This is nonsense. The manual should say, and lynx should act as if the manual said: Lynx is compiled to use settings, options, and URLs defined in certain source code files. Many of those settings can be overridden in an optional lynx.cfg file, which must be in a directory defined in those source code files (usually it would be /usr/local/etc/lynx.cfg). [If the man pages were written like those of smail, then that last parenthetical remark wouldn't be necessary, since the man page would carry the precise location where a lynx.cfg file would exist.] IOW, there is nothing "unsafe" to be "sorry" about if lynx uses the settings used at compile-time; there is nothing "unsafe" to be "sorry" about if there's no lynx.cfg file to override any of those defaults. -- Jean-Pierre Radley XC/XT Custodian Sysop, CompuServe SCOForum From owner-lynx-dev@sig.net Thu Apr 1 01:40:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA07073 for ; Thu, 1 Apr 1999 01:40:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA14143; Thu, 1 Apr 1999 00:28:16 -0600 (CST) From: David Woolley Message-Id: <199903312331.AAA05356@djwhome.demon.co.uk> Subject: Re: lynx-dev virtual html pages (fwd) To: lynx-dev@sig.net Date: Thu, 1 Apr 1999 00:31:17 -7100 (BST) In-Reply-To: <199903302044.PAA14464@chass.utoronto.ca> from "Philip Webb" at Mar 30, 99 03:44:24 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1172 Lines: 28 > > 990330 C J Lawson wrote: > > I ran into some program that converts ordinary text files to html > > and after running the file once or twice on misc files, > > I tried piping the result to lynx ... didn't like it Lynx isn't a general file viewer. You would be much better using a designed for the purpose tool, e.g, most or less, and if you want directory browsing, Midnight Commander. > > what if there was a way to generate html files on the fly > > and then store them in some virtual memory space > > (remember the ancient days of 'device=C:\..\ramdrive.sys' ) Any Unix system, with sufficient memory, will cache recently accessed files with no need for any additional software. > this is beyond me: anyone else have thoughts? I think the thinking is confused, which is why you don't understand it. > Mr Lawson appears not to be currently subscribed > -- he sent this to me personally -- , so he should be cc'd. No reply address available, so you'll have to CC him. Probably, you should have ignored him; there has been a recent increase in the number of people asking questions of frequent list contributors when they should have been asking on the list. From owner-lynx-dev@sig.net Thu Apr 1 01:40:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA07078 for ; Thu, 1 Apr 1999 01:40:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA14152; Thu, 1 Apr 1999 00:28:20 -0600 (CST) From: David Woolley Message-Id: <199903310802.JAA04596@djwhome.demon.co.uk> Subject: Re: lynx-dev Re: lynx- Can't access Startfile ... To: lynx-dev@sig.net Date: Wed, 31 Mar 1999 09:02:55 +0100 (BST) In-Reply-To: from "RYA" at Mar 30, 99 10:23:59 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1124 Lines: 29 > Unfortunately there is no troubleshooting help-file in lynx.zip. It wouldn't help, because this is not a Lynx problem, it is a networking problem which, on a more traditional platform for Lynx, would not be part of the responsibilities of Lynx at all. Basically, to produce the MS-DOS Lynx, networking has been added by integrating a third party package; if you need configuration information, you need to look at the documentation for that package. However, in spite of the unnecessary, uuencoding of the attachment, I managed to recover this line: gateway=0.0.0.0 which should be the default gateway address for your ISP. This next one is also technically wrong, but will probably work, and you may well not be able to find the correct setting. hostname=vicom.ru These must be configured for using mail (I don't consider mailaddr optional). #mailserver=my.mail.server #mailaddr=me@my.mail.address PS Are you sure you are not running Windows 95, 8 or NT; network configuration is much easier on these (the process is the same as for the GUI browser, so most ISPs can cope), but needs a Win32 version of Lynx. From owner-lynx-dev@sig.net Thu Apr 1 03:12:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA10716 for ; Thu, 1 Apr 1999 03:12:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA24304; Thu, 1 Apr 1999 01:59:46 -0600 (CST) Message-Id: <199904010602.HAA27286@riffraff.plig.net> To: kornet Cc: lynx-dev@sig.net Subject: lynx-dev Re: Can't connect your site.. In-Reply-To: Your message of "Thu, 01 Apr 1999 11:20:13 +0900." <3702D7DC.737CBEFA@kornet.net> Date: Thu, 01 Apr 1999 07:02:05 +0100 From: Rob Partington Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1048 Lines: 27 [cc'd to lynx-dev@sig.net] In message <3702D7DC.737CBEFA@kornet.net>, kornet writes: > Dear Sir, > > This is Kornet Customer Service. > I am writing with reference that one of our customer who is using your > service through Kornet he couldn't telnet your site last two days. > I would like know what is problem exactly also adding the error messages > below down. > Therefore I would be obliged if you can rely me back in return by email > as soon as possible. > Your kindly help on this matter would be appreciated. Apologies for the problems. The machine lynx.browser.org was on underwent a hardware upgrade that unfortunately introduced more problems than it solved. Things look stable now, however, so hopefully there will be no more problems. In view of the unexpectedly long nature of this outage, and the effect on lynx users, I'm actively looking for people to mirror lynx.browser.org to try and avoid this problem being as extensive in future. Once again, apologies for the outage. -- rob partington / rjp@browser.org From owner-lynx-dev@sig.net Thu Apr 1 06:40:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16767 for ; Thu, 1 Apr 1999 06:40:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04125; Thu, 1 Apr 1999 05:29:23 -0600 (CST) To: lynx-dev@sig.net References: <19990331111548.64202@shell3.ba.best.com> <199903301741.MAA10989@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 15:27:14 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.21.patch.gz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1025 Lines: 25 31-Mar-99 11:15 Kim DeVaughn wrote: > On Wed, Mar 31, 1999, Leonid Pauzner (uue@pauzner.mccme.ru) said: > | | >> * assign LYNXCFG:/ and LYNXCOMPILEOPTS:/ for internal pages of | >> parsed lynx.cfgand compile-time info. Now we will not see a | >> temp file link name in a statusline in advanced mode, also kill | >> overhead since pages created only when really accessed - LP > | > | LYNXCOMPILEOPTS:/ link from '=' page is not accessible > Since the CHANGES note has your initials (LP) by it, does that mean > you're fixing it again (presuming that there was a patch-integration > problem)? I just made development on a DOS machine and build without configure script. It seems to be a problem for any configure-based platforms, will look into (something obvious was lost or a typo, should be compared against LYNXCFG:/ which is essentially identical). > BTW, the "compile time options" link doesn't work for me either (on > FreeBSD), so it doesn't seem like the problem is a platform-dependent > thingy. > /kim From owner-lynx-dev@sig.net Thu Apr 1 06:40:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16769 for ; Thu, 1 Apr 1999 06:40:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04120; Thu, 1 Apr 1999 05:29:19 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 14:24:48 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 755 Lines: 21 31-Mar-99 19:59 Klaus Weide wrote: > On Wed, 31 Mar 1999, Leonid Pauzner wrote: >> Not so effective as you think: >> >> 2) you are disabling charsets from UCDomap.h which have no chartrans tables, >> so you gain probably a hundred of bytes but the actual code for handling >> of CJK and UTF-8 is spreaded across the binary and can easily weight >> for 50K decrease if would #ifndef'ed properly (but this will be >> a maintainance nightmare until the code will be rewritten entirely). >> 3) chartrans handling code (without the tables) weight > 150K of binary >> so this is an obvious loss to live with it but without the tables. > Curious again; how did you get those numbers? Just a guess. UCDomap.o may be a hint for the last number. > Klaus From owner-lynx-dev@sig.net Thu Apr 1 06:45:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16801 for ; Thu, 1 Apr 1999 06:45:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04139; Thu, 1 Apr 1999 05:29:28 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 14:15:58 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (patch) dev21: avoid expanding ~ to $HOME for DOS/WIN MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2163 Lines: 59 31-Mar-99 13:05 Klaus Weide wrote: > On Wed, 31 Mar 1999, Leonid Pauzner wrote: >> * fix to avoid expanding ~ to $HOME for non UNIX/VMS filesystems >> where this character is a valid char within filename (one particular problem > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> was for Win95 LFN path being in TEMP, report by >> "Robert D. Dedman" ). More places fixed, >> currently ifdef'ed with DOSPATH, but how about __EMX__? - LP > It is also a perfectly valid filename char for Unix. It should be left > alone in filenames except in special places :at the beginning of a > given filename string, possibly at the beginning of a path, but NOT > every ~ in a "/~" (or "~/") pair is special. We should set the rule, see below. > If this was broken for DOS/Windows, it is likely broken for Unix, too. Correct! > Not many people have a LYNX_TEMP_SPACE or $HOME or $PWD containing ~, > so this is unlikely to get detected... But this could happen more > frequently when someone mounts a Windows filesystem e.g. on Linux (and > for some reason LFNs don't get fully mapped). > Indeed I just tried 'LYNX_TEMP_SPACE=/tmp/foo~bar lynx' (after creating > the directory /tmp/foo~bar) - it's broken. >> How about checking for "~/" flashed left >> instead of if ((cp = strchr(lynx_temp_space, '~'))) ...? > There's the other matter that lynx consistently (?) ignores foo in ~foo/. > Not that I like it, but I assume there are good reasons for it (1. to > prevent users from looking into other users' directories [this alone > cannot prevent it of course], 2. difficult to implement right [system > dependent; maybe impossible in general for VMS?]). We should set the rule as strict as possible, preferrably in a separate function. Let we describe the possible string *before* ~ 1) nothing 2) file://localhost/ 3) ? complete path ended with a / or probably some prefix on VMS. 4) ? dot Now let describe the string after ~ 1) / 2) ?anything else what if we have two ~ on the path? > --- > I agree with Doug, ~ in DOS/Windows Lynx should have meaning equivalent to > Unix and VMS Lynx if possible. > Klaus From owner-lynx-dev@sig.net Thu Apr 1 07:00:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA17242 for ; Thu, 1 Apr 1999 07:00:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05750; Thu, 1 Apr 1999 05:45:24 -0600 (CST) To: rdedman@easynet.co.uk Cc: lynx-dev@sig.net References: <3702193F.90DC6CCC@easynet.co.uk> <37013D7B.C31F0197@easynet.co.uk> <3700C671.16523F3D@easynet.co.uk> <36FFB531.5C054F95@easynet.co.uk> Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 15:40:29 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev Re: Lynx-dev Using Win95...THANKS! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1471 Lines: 55 31-Mar-99 13:46 Robert D. Dedman wrote: > Leonid Pauzner wrote: >> Hmm... >> I just check the sources and found that '~' gets expanded to user home dir >> like we have on UNIX (without additional check). This is a bug - >> will fix for DOS/Windows ports, thanks! >> Well, why nobody haven't seen that before? >> Probably nobody set temp dir to long name... > Glad to be of some use! > --------------------------------------- > Having problem getting JUMP to work. > The .cfg file says some jump samples are included, but they're not. > 1. On pressing get:"can't locate jump file" > 2. This is what I've typed in the lynx.cfg file: > JUMPFILE:/c:\progra~1\Lynx/jumps.html > 2. I've also tried putting the jumps.html file in the "C:\" directory > and typing alternatively: > JUMPFILE:/c:\jumps.html ^^ try removing leading slash before the drive letter. > ...but get the same message. > 3. Finally, I don't understand this: > "...Make sure your jumps file includes a '?' shortcut for a > file://localhost URL to itself: >
?
This Shortcut > List..." > Does it mean: NO idea. > (a) create a file "jumps.html" > (b) enter "
?
This Shortcut > List" > as HTML code > or what? > Best regards, > Robert I forward your message to lynx-dev@sig.net please send farther reports to this address. Read lynx-dev.html from Lynx on-line help for more info. From owner-lynx-dev@sig.net Thu Apr 1 08:12:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA18926 for ; Thu, 1 Apr 1999 08:12:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA15035; Thu, 1 Apr 1999 06:59:28 -0600 (CST) To: lynx-dev@sig.net References: <19990331111548.64202@shell3.ba.best.com> <199903301741.MAA10989@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 16:57:59 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.21.patch.gz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1669 Lines: 51 31-Mar-99 11:15 Kim DeVaughn wrote: > On Wed, Mar 31, 1999, Leonid Pauzner (uue@pauzner.mccme.ru) said: > | | >> * assign LYNXCFG:/ and LYNXCOMPILEOPTS:/ for internal pages of | >> parsed lynx.cfgand compile-time info. Now we will not see a | >> temp file link name in a statusline in advanced mode, also kill | >> overhead since pages created only when really accessed - LP > | > | LYNXCOMPILEOPTS:/ link from '=' page is not accessible > Since the CHANGES note has your initials (LP) by it, does that mean > you're fixing it again (presuming that there was a patch-integration > problem)? > BTW, the "compile time options" link doesn't work for me either (on > FreeBSD), so it doesn't seem like the problem is a platform-dependent > thingy. > /kim That seems to me HAVE_CFG_DEFS_H is not defined in LYGetFile.c >From LYShowInfo.c: #if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) #define HAVE_CFG_DEFS_H #define PutDefs(table, N) fprintf(fp0, "%-35s %s\n", table[N].name, table[N].value) /* * Compile-time definitions info, returns local url */ PUBLIC char *lynx_compile_opts NOARGS { ... So the simplest solution should be: diff -u old/lygetfil.c ./lygetfil.c --- old/lygetfil.c Wed Mar 31 15:48:14 1999 +++ ./lygetfil.c Thu Apr 1 16:51:02 1999 @@ -263,7 +263,7 @@ return(NOT_FOUND); return(NORMAL); -#ifdef HAVE_CFG_DEFS_H +#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) } else if (url_type == LYNXCOMPILE_OPTS_URL_TYPE) { /* show compile-time settings */ StrAllocCopy(doc->address, (char *)lynx_compile_opts()); From owner-lynx-dev@sig.net Thu Apr 1 08:58:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA20044 for ; Thu, 1 Apr 1999 08:58:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA23838; Thu, 1 Apr 1999 07:44:50 -0600 (CST) Date: Thu, 1 Apr 1999 07:44:45 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: rdedman@easynet.co.uk Subject: Re: lynx-dev Re: Lynx-dev Using Win95...THANKS! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3092 Lines: 86 I have played a bit with a jump file (on Linux) and looked at the code, but not tested anything under Windows. On Thu, 1 Apr 1999, Leonid Pauzner wrote: > 31-Mar-99 13:46 Robert D. Dedman wrote: > > Having problem getting JUMP to work. > > The .cfg file says some jump samples are included, but they're not. They are included in the source package (and should be included in any binary package, definitely if the lynx.cfg that comes with it says so!) If you don't have them, see under . > > 1. On pressing get:"can't locate jump file" > > > 2. This is what I've typed in the lynx.cfg file: > > > JUMPFILE:/c:\progra~1\Lynx/jumps.html > > > 2. I've also tried putting the jumps.html file in the "C:\" directory > > and typing alternatively: > > > JUMPFILE:/c:\jumps.html > ^^ try removing leading slash before the drive letter. Yes. The path in JUMPFILE should be given in native file syntax. (At least I didn't find any place where the name is converted in any way; a comment in lynx.cfg says "On VMS, use Unix SHELL syntax", not sure how this can work for VMS if it does.) It is fed directly to open() [! not fopen() !]. > > ...but get the same message. > > > > 3. Finally, I don't understand this: > > > "...Make sure your jumps file includes a '?' shortcut for a > > file://localhost URL to itself: > >
?
This Shortcut > > List..." > > > Does it mean: > NO idea. > > > (a) create a file "jumps.html" > > (b) enter "
?
This Shortcut > > List" > > as HTML code > > > or what? Basically yes, see the sample jumpsUnix.html, but you'll have to change it appropriately for Windows. The href value should be given in URL syntax, not in native filename syntax, so it will look quite different from what you put in lynx.cfg's JUMPFILE even if both refer to the same file. For example your (b) should probably be
?
This Shortcut List I have also URL-escaped the '~' character, that *should* work for Windows and could avoid potential problems. (Although the problem may not exist for '~' in full URLs.) The format of jump files may be very sensitive, maybe more so than bookmark files. Basically they are parsed in two completely different ways, and both methods are supposed to extract the same URLs. So keep your file(s) as close as possible to the sample file, unless you want to experiment. One thing I haven't seen documented anywhere: It seems that the "keys" (shortcut names, what's after the
) have to be sorted (case-insensitive) otherwise they may not be found at a sortcut prompt. I still don't quite get what the whole mechanism is good for. Every shortcut leads to something that can be expressed as a URL; it seems easier to just put them into an HTML file (with much more freedom in formatting) and just navigate to the right link and activate it, rather than learning shortcut names for those URLs. Klaus From owner-lynx-dev@sig.net Thu Apr 1 09:00:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA20069 for ; Thu, 1 Apr 1999 09:00:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA25316; Thu, 1 Apr 1999 07:50:32 -0600 (CST) Message-ID: <19990401131722.A27681@mema.ucl.ac.be> Date: Thu, 1 Apr 1999 13:17:22 +0200 From: Serge Munhoven To: lynx-dev@sig.net Subject: lynx-dev Request for vote - Fwd: Re: Free GNU/OSS Hosting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6032 Lines: 124 Dear All Though I understand from today's messages on the list that things are also moving on Jim's side, I've got the following on mine (after seeing all those starving mirrors :-) (See http://www.linuxbox.com/gnu.html as well as my mail cited by Chris Gann below for details) Any comments ? - Serge PS: To put it clearly, there was no intention to compete with Jim ----- Forwarded message from Chris Gann ----- >Date: Wed, 31 Mar 1999 19:19:09 -0500 (EST) >From: Chris Gann >To: Serge Munhoven >cc: staff@linuxbox.com >Subject: Re: Free GNU/OSS Hosting >Dear Serge and the rest of the Lynx development team, > >As an avid UNIX user for many years, I know the value of Lynx. I first >used Lynx on a DEC OSF/1 1.3 server in or around 1993 (maybe? it's all a >blur!). Since then, it has become a most valuable tool for many system >administrators and shell account users alike. I personally use it for >just about everything that doesn't require java! Believe me when I say >that your request to us was received with much happiness! This is a >project that we would not only be willing to host, but would also >publicize as being one of the sites that makes us the most proud to do >this. > >Our services have changed a little since our last site update. We are now >located in two cities, one is Pittsburgh, PA and the other is in Shelburne >Falls, MA. We would be willing to mirror at both locations, with two >distinct IP addresses on two seperate servers, thus reducing the chances >of downtime. Your estimations are most likely correct in regards to the >usefulness of a Website, however, an FTP site would be ideal. We are >willing to do both, and offer any other services you would find to be of >interest. This is the reason we're in this to begin with. > >Your project is one of the most respected around, and we would be in >seventh heaven to be able to contribute a little something to it. >(Personal Note: I submitted a small patch to the project via email almost >5 years ago and you still haven't got back to me ). > >I understand the lynx.linuxbox.com statement you made. I also own >nebula.org, that's not really much of a help, I'm sure, but it would at >least be able to be a good way to not designate lynx as being a linux-only >project, because as you've stated, and I also know to be very true, Lynx >is not solely for linux. I'm not solely linux, either. I happen to run >BeOS, UnixWare, Solaris, Mac, Windows and IRIX. Lynx is installed on all >but Windows. Windows isn't worth the time to ftp a compiler, even over >T3. > >Anyhow, what this boils down to is that we'd be willing to help out and do >our part. We don't mind the traffic, and we'd be proud. It's almost like >back during the revolution when citizens would put up american soldiers in >their homes and feed them, etc. Being from Massachusetts, I still have >some of that in my blood. > >The choice is now completely yours. We are here, and more than willing to >work with you! Thank you for your email, and we look forward to hearing >from you! > >--Chris >& The Linuxbox Staff > >On Wed, 31 Mar 1999, Serge Munhoven wrote: > >->Dear Linuxbox staff ! >-> >->I am currently more or less passively (lack of time ...) involved in the >->developpment of lynx, a tty based webbrowser. One of the problems we >->recently ran into was the shutdown of the anonymous ftp service at lynx's >->home site, www.slcc.edu. Though the code is still based and available there >->via http (http://www.slcc.edu/lynx/current/), this had a quite annoying >->consequence: many servers' ftp-mirroring simply stopped. Sad at a moment we >->were trying to get a more comprehensive network of official mirror sites, in >->order to increase availability and visibility of the project ... >-> >->Since then (and even a bit before), negotiations have been under way with >->various site-owners in order to find a new official ftp-server. The main >->conclusions so far have been: >-> >->- ftp.digital.com declared ready to mirror the distribution >->(ftp://ftp.digital.com/pub/net/infosys/lynx/current/), but mirroring broke >->down (see above); >-> >->- gnu.org had been a potential host, but there was insufficient unanimity >->about RMS to more closely join the gnu project. Note though that, as far as I >->understood, lynx *is* de facto GPLed, and anyway completely open-source and >->freely distributable. >-> >->As you can see what is really lacking is an *ftp*-site, more than a website. >->I don't see a reason to leave http://www.slcc.edu/lynx/, as long as we are >->welcome there, especially since this site is refered to in the documentation >->in most of the versions of lynx floating around. Anyway, having a clone of >->that site, e.g. as http://lynx.linuxbox.com, would IMHO not at all be a >->nuisance. What would bother me a bit with lynx.linuxbox.com is that lynx is >->not at all limited to linux (but neither is it to slcc.edu :-), and you'd >->deserve a bit of publicity too for offering the hosting, wouldn't you ?) >->Anyway, lynx.org & lynx.net are already registered by others, for other >->purposes; lynx.browser.org is registered for lynx, but I don't know by whom, >->nor where it is hosted, and the service is currently unavailable. >-> >->You may perhaps want to have a look at http://www.slcc.edu/lynx/current/ to >->get an idea of the volume that would need hosting (to which one could consider >->adding binaries of the most recent release for some architectures, though the >->lot of compile-time configuration options makes this a bit useless; something >->alike exists already at http://www.crl.com/%7Esubir/lynx/bin/). >-> >->I'm looking forward to reading what you think about this all and would be glad >->if I could forward a proposal of yours to the critical eyes and voices of >->lynx's volunteer developpment community ... (hey! no fear ;-) >-> >->Best regards, >-> >-> - Serge >-> > ----- End forwarded message ----- From owner-lynx-dev@sig.net Thu Apr 1 09:04:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA20343 for ; Thu, 1 Apr 1999 09:04:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA25174; Thu, 1 Apr 1999 07:50:08 -0600 (CST) Message-ID: <3702193F.90DC6CCC@easynet.co.uk> Date: Wed, 31 Mar 1999 13:46:55 +0100 From: "Robert D. Dedman" Organization: Teleconsul Europe Ltd X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Leonid Pauzner Subject: lynx-dev Re: Lynx-dev Using Win95...THANKS! References: <37013D7B.C31F0197@easynet.co.uk> <3700C671.16523F3D@easynet.co.uk> <36FFB531.5C054F95@easynet.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1161 Lines: 52 Leonid Pauzner wrote: > Hmm... > I just check the sources and found that '~' gets expanded to user home dir > like we have on UNIX (without additional check). This is a bug - > will fix for DOS/Windows ports, thanks! > Well, why nobody haven't seen that before? > Probably nobody set temp dir to long name... Glad to be of some use! --------------------------------------- Having problem getting JUMP to work. The .cfg file says some jump samples are included, but they're not. 1. On pressing get:"can't locate jump file" 2. This is what I've typed in the lynx.cfg file: JUMPFILE:/c:\progra~1\Lynx/jumps.html 2. I've also tried putting the jumps.html file in the "C:\" directory and typing alternatively: JUMPFILE:/c:\jumps.html ...but get the same message. 3. Finally, I don't understand this: "...Make sure your jumps file includes a '?' shortcut for a file://localhost URL to itself:
?
This Shortcut List..." Does it mean: (a) create a file "jumps.html" (b) enter "
?
This Shortcut List" as HTML code or what? Best regards, Robert From owner-lynx-dev@sig.net Thu Apr 1 09:13:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA20614 for ; Thu, 1 Apr 1999 09:13:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27736; Thu, 1 Apr 1999 08:00:27 -0600 (CST) Message-ID: <19990401060008.28052@shell3.ba.best.com> Date: Thu, 1 Apr 1999 06:00:08 -0800 From: Kim DeVaughn To: Lynx Developers Subject: Re: lynx-dev lynx2.8.2dev.21.patch.gz Mail-Followup-To: Lynx Developers References: <19990331111548.64202@shell3.ba.best.com> <199903301741.MAA10989@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Leonid Pauzner on Thu, Apr 01, 1999 at 04:57:59PM +0400 Organization: Kim's Home for Wayward Cocktail Waitresses & Hors d'oeuvre Girls Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 624 Lines: 20 On Thu, Apr 01, 1999, Leonid Pauzner (uue@pauzner.mccme.ru) said: | | > BTW, the "compile time options" link doesn't work for me either (on | > FreeBSD), so it doesn't seem like the problem is a platform-dependent | > thingy. | | That seems to me HAVE_CFG_DEFS_H is not defined in LYGetFile.c | So the simplest solution should be: | -#ifdef HAVE_CFG_DEFS_H | +#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) Yup, thanks ... that seems to work. One nitsy thing though ... upon entering the "compile time options" page, LYNXCFG:/ shows up in the statusline, rather than the expected LYNXCOMPILEOPTS:/ string. /kim From owner-lynx-dev@sig.net Thu Apr 1 10:36:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA22884 for ; Thu, 1 Apr 1999 10:36:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA23098; Thu, 1 Apr 1999 09:18:21 -0600 (CST) From: Philip Webb Message-Id: <199904011518.KAA18800@chass.utoronto.ca> Subject: lynx-dev jumping out? To: lynx-dev@sig.net Date: Thu, 1 Apr 1999 10:18:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 500 Lines: 11 990401 LP & KW debated the meaning/use of jumps files: may i start a hare? -- ok, i know March has ended (smile) -- isn't the whole jumps-file business a piece of antediluviana, which would be better dropped from present-day Lynx? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 1 10:45:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA23208 for ; Thu, 1 Apr 1999 10:45:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29242; Thu, 1 Apr 1999 09:34:13 -0600 (CST) To: lynx-dev@sig.net References: <19990401060008.28052@shell3.ba.best.com> <19990331111548.64202@shell3.ba.best.com> <199903301741.MAA10989@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 1 Apr 1999 18:19:26 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.21.patch.gz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 414 Lines: 15 > | So the simplest solution should be: > | -#ifdef HAVE_CFG_DEFS_H > | +#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) > Yup, thanks ... that seems to work. > One nitsy thing though ... upon entering the "compile time options" > page, LYNXCFG:/ shows up in the statusline, rather than the expected > LYNXCOMPILEOPTS:/ string. Look more carefully: this is a link name (assume Advanced mode) > /kim From owner-lynx-dev@sig.net Thu Apr 1 11:05:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA23815 for ; Thu, 1 Apr 1999 11:05:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA08426; Thu, 1 Apr 1999 09:58:29 -0600 (CST) Message-ID: <19990401075734.11340@shell3.ba.best.com> Date: Thu, 1 Apr 1999 07:57:34 -0800 From: Kim DeVaughn To: Lynx Developers Subject: Re: lynx-dev lynx2.8.2dev.21.patch.gz Mail-Followup-To: Lynx Developers References: <19990401060008.28052@shell3.ba.best.com> <19990331111548.64202@shell3.ba.best.com> <199903301741.MAA10989@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Leonid Pauzner on Thu, Apr 01, 1999 at 06:19:26PM +0400 Organization: Kim's Home for Wayward Cocktail Waitresses & Hors d'oeuvre Girls Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 423 Lines: 13 On Thu, Apr 01, 1999, Leonid Pauzner (uue@pauzner.mccme.ru) said: | | > One nitsy thing though ... upon entering the "compile time options" | > page, LYNXCFG:/ shows up in the statusline, rather than the expected | > LYNXCOMPILEOPTS:/ string. | | Look more carefully: this is a link name (assume Advanced mode) Ooops ... I overlooked that link in the compile opts page . Guess it's time I got some sleep ... /kim From owner-lynx-dev@sig.net Thu Apr 1 11:55:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA25554 for ; Thu, 1 Apr 1999 11:54:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA23627; Thu, 1 Apr 1999 10:36:39 -0600 (CST) Date: Mon, 29 Mar 1999 21:28:45 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev psrc patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 49606 Lines: 807 Here is a corrected patch that adds html source colorization to any screen. Description is slightly corrected: * added HTML source syntax highlighting (when option -prettysrc that is added is given to lynx). It's available for lynx compiled with and without lss support (it can be much more beatiful when compiled with lss support - read lynx.cfg for description). This functionality coexists with old source view and with -preparsed logic (ie different commandline options make source view logic different) VH * HTChunkPutc was inlined in SGML.c for better performance -VH * Keeping of Style_className was omitted in HTML.c to increase performance of lynx compiled with lss support. -VH * perfomance of lynx compiled with lss support is increased ~ by 15-20% for normal documents, and by up to 50% for documents with a lot of tags VH * fixed bug in lynx compiled with lss support that caused it to load local CSS stylesheets - lynx didn't understand their syntax so it was exiting VH * added type information for attributes in HTMLDTD.c (it's used in source syntax highlighting mode) VH * sample .lss files are updated to support source syntax highlighting VH Notes: * Fixed bug that was in the previous version of the patch - the value of tagname_tranform was used instead of attrname_transform where it should (ie unintended name transformation was applied) *Lynx compiled with lss support should be much faster than it was before - a lot of optimizations were implemented. * Inconsistence/bug:I didn't implement entity detection and colorization in psrc view of the files generated by various modules - so & is displayed as & rather than an & - but I don't think it will hurt anybody. *To TD: This path was based on patch you have partially corrected. HTMLDTD.c is made much more flexible - by choosing the right version for macro T(x) you include or omit the member 'type' of 'attr'. But I had to #define macro USE_PSRC in HTMLDTD.h and SGML.h (and in LYPrettySrc.h), see the comments in them. Probably the best place for definition of USE_PSRC is in userdefs.h. I've compiled lynx with and without .lss, with and without #define USE_PSRC, and it was tested rather exstensively. IMO it will be better to release dev22 today or tomorrow since (IMO) there are no (few) other patches in your queue. Best regards, -Vlad begin 644 patch1.gz M'XL(",>I_S8``W!A=&-H,0#L?6E[VLBR\&?\*SK)<\9@P#%XMR&831#0@?).)XYN:_OU6]2*W52&#'D^N+%IG<&=_SQ>VC[>)0^U8LY&=S_?KUIT^?7M?TJ[DZOWM=G=Y,M*EF6*JE MSXS7E]WR>&%\W1[X($?Z=VVX%.A&/I]/_N)4=[P@I<4U(0>D<'A2/#HI%DGA M^/AH(YO-KC"J5'UFD+HZ)\5C4M@_V=L[*>P@WN.-=^](_G`G=T"R\/]'Y-V[ M#?)Z*U6ZN=&,(5')8*S.U8&ES3?(UE8J[_L'CU]O9%]OD4_JW-"-ZQ-BC34R MF`TU,AO!9]TDHX4QP-$0^#S41KJA`6*33-7!?$9T@W0NZK7MP38ICU7C6MO( M$HJ"-<_F9&$P(*);3F]R.]8,')QQ#2]UOV>;Y#]>XK!(JW=6JY;)MYD^))P4 MK84U(*7V1:=(TOP1V2L7JMT*\GDC(,FE#,.;O%I9&#'6J4<@N2(JE7A.-C<8$R8,Q`084(6,QO0)( MD$,;TF3R^DH?@5"17D?IMSKM,CS@DDD:!.=2ZC>:[7JI)C7HO*'4*-45Z?F8 M/[]L*^?2XP%_7*Z5.AWI^7>!IO?9V]1-6QF2(Q8\TB:FYFW!QP;(W$9V@YA( M]P&=%E'[^.>/?Y,WY*]4*@5+L60,QK!PG$GCG/.IO\C+4KFL=#KOE2\OR8\< M>U2^++4[2E=Z@,.2ORJEMO2UV6Q7I.9*56I$&CC?JA7I:CE?:Z7&A?.M M+G5$ZDK?FMW2F?.UV2C#>GXO/Z@W@8G-7M?_[*,BC:RMU.0O'YTOG6S_*1](9.K6^VZ`+[(V'KMAOUEA_Q`YG2U^50W0(>0"4@] ME48/9_!?-]W((Q2(2T,:X1>RV@=Q&64<"X3@?@]HH3TDP'&.QU#9VVI#A M+CA=:F,"$(B324-P6]V+4VICLA+\/BXY@7"V&`6V.1(5UD8ER]-&!2QDG%3> M0MJX^`6W,5D,;',$,ZB-B6@@'!/7X+8O+26,#U22@]MVB/L?:PN6=?+C=(-X M]-=P.-=,TZ_%*I4V+(D@-1:MHEPJ259";JW3:'YJRSK)N_)=ZSIZ\29=A%$+ M+6HQ12T8,:W8`A4N&*LR^`9L!=MEIEGE1P_63]5*]W+9;8*1 M)I"#E$XA4I%\FZB$J@2'O+QMO)QD.W3WMPD.!,$);JQUM41L(0E7B\W?H#;. MZZ"V55?97`NP!-M**7B%/;3!Y]6U[IYKL^O6:[W=M_8>8GT]KAD6O7.XL'K: M'M><>D)FT8KK\DHU-=^Z1+49M"[=JV0588T2D)]$B&MSMC"&?EI<=)J]1N7! M[+Q:LRE;>>WR+V?RL1F&+!:<;X@<_!QS\&HVO/,+0;/R)<04;$C[PEFI_/ZB MC>(B/;LH-VO-]K+[V;)2XWIOTV,H-AL]SY-HDZ^K?);6\4<7W-E4"X)Z4[+JFY]T@)#/1U]8+-2*3&FZ,2\%M'\/Y$+P>@GD:LAXL M[;OL(!%[3>"0$FC&4K<4WQ]VN3#-L_]2RI+,NC:F>X3=%0+[6*KUO%]=/:+E M/[&L4A(\GAS['`E95CDM@]K8,K3 M)^?E4JM;#1;T@*R;)\2Y%DVW@F:+RCY%A1R?DD;\.5IO,)NX1`$EH5DCJC'$ MOVB=MY8(<6.&S_VM>7Z^;O%HE1I+"@LN']?XUA6B9O,,;Z.S?NIR1NFX5AFT MZ1W4]G`AX\%<&^K^Q$RYK52J2;R.!U=33TH,?HJZ&>K??/RJ5#\NHV)^]A;S MO(U$\%6;7FG^T*A2/U,"`Z,V;[%76C<&D\50-ZYS9#2;$V-VFR/6>&9J9#2? M3I@G_W![_TB_]JD;*I;W;B2/J"R\0<@( M?>'1$,DUPKI,W5]CR;I"E^M9LA'+\K&7WD,N+VTR-#5_4/^\JM0JG>!S3S_; M1'LVPT;^N,[YJK'+9U8]#*MFAM]U/6\V$JPL3_[8Q3U%3C6?+WD:L%/]?Z&' MDAZ&KZYD;PR>*XU*:-NY?(IM7;)"*1-;CE:6E?DT0%;:];!H;:N;%X?NF46/ MES;(WO8.&<[5D47RY.NM!("!WY<)["&E47:G$\)%JJYT+YNN$PB=WEF]*AE' MG7*[VNJ&:A?H[C:F5CH*YZ:1[/N$4"HK4/*O!,FRS3=1APM<%-5?=#M]WM"P"T M%8]2+;>;M5K5I74EFS]:?*-X[QJBE_?R2.]S15TVKQA^H%R(B?C;PNWA=?`P MT#Y%-H;9I\U:Q^9:N_FIL^RFAG`AI&%H'D),KS6_,5?7#7VZF#(EM0M*ZMF> M"Y"ZGV+/74]FIJG.[WP26:F1-`;+*K5R@E,BY6:]59*WO:?+2WNHOS2?Q[Y% M>5D`*^'R8`TYC,;%62D^J]UQ),]I(>5#HU>7OK^O/L!AXH?)C7!J/)(T1<=\ M(@XK<0H'ME%JATCODSO8/)[[1;O]<)DYM]AV+DORU3>/L;1\-'1MF?Y'WM"B MQ8]3)TB,HAS2!PA'/ES(40^VRZNAAKE'#&D_;W`_*F*?U)B_QW3W"NBZ)-(U MOS4%SQ_"64CH$$1*Y`-*W=2?1ZK6E\DC/4H&NI,XH_24.#(\ M8<^H6_J72OF]?%Q[I;/>2KO=7'+!>]9SZ;/K2TUI7,C[DKS>ZU5I,O=4H7&? M(&\V@'*-"]>A<]]]9M\I](Y2T18,.# MX]J&_FL^F-!129Z\:U!W6\5%A03BL^?>XW MN0)O],:1,??VNE,Z6V;-W#Y2W2\^92K/=9?0]T M(>LA3)WSYOJE)FI+_TE2HX%6\!^SKRF@%8+/V3_?W'N$U,%/$@;=^.H7A6KC M?$%&YU.L6+E^8]-ZM M)Z#>:/QYWRMH2:M8<1(%"DSB0IR11O_:"VJN++RF/^!3JR8YJKIZTC1I4O2G MW*5_.EG11\YN_J3[\E/UQG\,IQ1X*7H]]3[69H`_H1WRZ1G@4]7RG^2HE[J7 M08P]:WZ6V?IS+28ZF!!:/B6>_R2^:I:_C&A=Z0:6$2TW&UVE(1?,[79;>>5# MK_HQ9$'>=U"0XPN8LHPZQO)8D1R&]MW2_1Y#0_G@8U ML_QY_D:S&YCE7\MRDW?[=M-UK/P7K*<8M6FSV4MMWQ]TTUY14F97_Z,-_(8B MR[.NXZXG?)6EQE]Q&Y^XS3Q/<3H%D+25$(F,4Y`[\FYY9$*/%IN5KY-W2XW* MV9=PN8Z7@/.>![BW_G=T.<@'N''*N1@@ME$UOAW6!BQ+;_D]N3:X8'G,Y?P0 MM<&37DI/FAX3HA;8)L0NL.UQ4U)1YQC66M]\Z735+-#E;0:&>V,>"4>SH]KH MA2FA""O4>SJX6VJ'W\!:(2#S`"?*G4G[VQ[$G(TZY\OH%M*V=F]WU4TUN`!< M,[3^VSH/OT0)(^;!9=![BN/[2GX]V4J&48^NT(P-*5Q46TD"CH^AI<5 M68'BHQ3/]K0]Q)D;AY[^MGLN'4ET?GC;YN&\,U.;!(4\F;F_7HMDG3<5Y`,@ MO5JWVJJ%KHD$UQ$\MP^BZA/=']U\H()Y3\FI?)`3_%$G\6V6^]L>_R1^^&G[ MA.6;$HL-EM/E7MU0K7&)%!#$Z,N'*3>#-OAHYS M=9D*6(E=U.E)LI=*K=8J53Q^)#S$A$8,YY+5,Y*_M93R$@)+;Z`O%]!P5[/U M!CC:O9H[7^FI]%:OE]I?0N7]9Q2\E2D?T&8S8$VK*JKBE,VO-:Y&SMG`MN0A MGO!"N5'A'RX<@6W1A>:XV`2T/;T]VO(?RNE6:%'UX"-HWMO*G^4%5/IX!?CEEUA6G?+<^/BK.";/B;E*$_++Z.4@)Q=M]U94_7[6+[+_B[ M"B;&=;H3EV-=Y2[^0^R^3RD%_)0\ZZA[[!$U,A_"ZUY5;[C*H"%4.P>;LE*J MP)_S9K.;8]MTQ$\^/\Q/HR7;?!]IKWU*OXSVV/OBT]O[%H&'S7KK.&RVC@M7 MK5I)KE:3^,:52])#93;61? M+8RA-B(-^Y-N?QK;GP;VI^\23!?7!A:&QA^N:FF6-B?GDSO#V#2);ECS&;'@ MOV.-V1/9IM;V]OT$F^@H'JAD9: M>!K_.\F1M*G_J0$:^)HOP&3$XB[#-MN%H7;5:V*IUV9_-AG^@2/OP^9;5QK= M#EWN&WE\)VKLERG8K:@BR*5HOU*_U.VVJV>]KM+)I3H7"%IO=;_DNOT2+B0! M>':&ETT!6M2AX/`72L./H5[]K%00`X62T93;S<:7^DL2$P\#DQ%5*FT%%R], M9SB<:Z;)D!$V*=8J(R1NA*R#C+#5JH&IB>2YN9GP0N*"1K0M`AMMEY&!-T%1 M"7=#((+G$?2&5AE)+S:Y>R[P[B58F+%1()2$YFQ9#&(69S)PJ=%08H^!0;G0 M=!1$["'CJC1C3ZK2E!%<=)H] M_*D2F-2U.5OP(@YP152]D!%@I(#:O$>C'8)'8M!/K;\_3]SH_3BS'0MHBIT'8)&?^!;Y1! M^3?`N0SRUG!\O(.,$/8;MMK%K[KRH56J'\/IPZ!D--6N$I=*"".C:%:61F&/ M`V!<*&J(0?P<-L<`3R,&T:RY$=!?RWX9&PD% M`'=L#-6V"\/'N-(.C3("1@/YER+X\JM$#<)%AEHY&8ZRC*0;FY>R*"CUN.!* MW05^IE!A$R+GJX4-)]5?RZJ#`8 MJA?AI#UW[:M,2D;/8BXCR2?[,GYR"+YA'O(:&\+.#`QO*@+L,)?%F008NQ M0(LRZ&XLT%T9="\6Z)X,NA\+=%\&/8@%>B"#*J6EM;V-`&!D%%39\I^4$*]O MA\O-I:QHL7?L]T,/&<67N#KJ4C8DJW&AJS*PO7ITW_*I^M:/6]ZKW@54K5.- M).K4"S3U`(UDCZ4N:R1:1INBL*ML"R38$H$&FUV(.G&9`B`R@@X/Y^=+#VF5DEW$EN78I@].%X#69:M4(\*H+G#F9 M=JTZ&T'C?10*EY=9JW:Z]'#-\F&8HW=8^D&J&EI4MA!QJ,T>K'M6@1RX>C2^)5= M/$>,!9Z'LPE;)22LI@RBD8K.Y%*%7"KEAF,=9<@FV^5?QJ.I`'-A8KZD76&& MX\'G48AS*0[) M;>=(0KQV0>NFUVGGEVI1?N5[MUP'\]8(?*R#A)"N)]=J"EA+`EQ>2?1J'06V M;]X)!-@2@02;9428]N!1GY@*P@:5T;5CQQ(`1$+P(2ZX'#&*O<7*XM\IU5NQ MX0%&1L%^YA602)>M.![6%BG\K(N,CYT*0'S.Q1:!C[:%;V:L7486WZKKN,RZ M3KU4BVU94B`9"9Z!BHL#8%PHFK%=<(2144"W][$EE4&YT30;2\>2[;%0*!<: M3"$BE^V[!X+)V!*Y"&D/&5=OZ22$/:W>F0M!_%7@BL#AT1E`(&X$<`3P-)PB MT.A&P,CA'`!WD`210XR#-LN(1%C<3KFOHO62)4@.GFPTL/!"D"YCYS MC/=[7&:6:L^ER%*2VR[CO65$@V`RFG;,8=S>V6NK*)%PZA2F@92NT5XMM MQ_9DO?RQ%#OU""`2@D_QTS6?7/F:S\MOO]("^4PWX"P@:*5?EEYF8J;L!2#+ MV&>2INP%&IZQSR1.V0M$/&.?63EE+Q"RC'UFM92]0(8Z+9,T92^0].*3NR># MTXQ]?!0\9<_1G"V-04[9"V"6L8\[!CME;Z/I*!1)HI2]A(1&P#,KI.P%KDHS M_J1HREX@X!G[S,HI>X&P>A%_1#2U(!#08$IL7O-@BHW$SMAG$J?L!2XT33)) M4_82$NJ[959/V0N4']BHXJ7L!?#RB\&5LA?@+&.?62UESY&)C'UFY92]0,@R M]IFD*7N!!C/V<:G$4_8"!6;LXRX'GK*W4=0HAO@I>PLK=1LGTU?LI>(&!2&C-E+X"IO9(T96\C:=X&$YAPS*Z3L942" M1RNF[#G*RP(=6*R4O0`MQ@,M2J"[\4!W)="]>*![$NA^/-!]"?0@'NB!!(K1 MA[C*EL(&`9^\QJ M*7N.C&7L,RND[`4BEK'/K):R%\@N8TLR3=D+<+808J?L;7#N9"9*V=M(6,9^ M67LX,&7/<6'&/I,H96\C8!G[N,:YD[*W$74O^5"2I>P%'LS8Q[9K>QM%E M\:M$*7N.A&?L,S%2]@)29.PSB5/V-B;N2R9*V7,D/&.?63EE+_`QK1`_92_@ MN=^^6LI>(.,9^\S**7N.D*VG."E[`4@S]ID54O8"D9VQ7U)^0E+V`ET[?BR! MI>PY@@^QP:6(4?PM5A)_FK&/#5^2,P8\8Y]9.64O\+&,?6:UE+U`EL"JZ\AF M'QM%,WX+CA/V0L4+&,?>QPB9>^@P8Q][+&(E+V- M!C/VF=52]@)7;_DDA#ME;R-(L`KD"!QF[#.)4O8.`DZ.I"E[@<@.B\=/V0L4 M;$^.F;(7P")CGUE+RE["2C/V2H*09^YB$XBE[@>(R+J$N96#A,\=/ MV0L4-&.?29RR%VC:<8=[=^&JI*Y%P^12FG+(7P+7X=FQ/TLN8L8^[[%G* MGB/XE"!=\TG.UWR.L?WZ4O;NPAN^N_F&=KORW7P[Z2N=,GB^F_]\-W_)_+$, M_'PW_Y>\F^]DZ)_OYB^5Z'^^FW]_HC_)W7P;R=__;C[;KW/KN)W?$C;?D[F> M;^>7GZ_G_^VOY]OPR:[G"_#GZ_F1N?YDU_-M%*M0/*WK^8Z*]&?[ESO" M+'LVST>8XW@V_Y>/,,N>S?,1YA#/YA38)#S$'>#8_^12SR[-Y/L4L(?C[G6)V>3;Q3S&[/)OG4\QAGDVR M4\P>SR;9*6:/9_-D3C$'>C;DE3ZBU:0)4<[*E6J98$GISNO=XQV2SY-K?8)_ M=@J'A[3@.'>NG@N5A8*N6*CL^5SY4A1>X5PY>:490WV$8BXDWB_N1VYQCU$U MSEEEOT;=N"3'\'TT^)L?Q$I0 M4H-+EXZT;UQ((O!<.M)]#^6Y=.3?H72DC2)9Z4@;_%GL[,_%(T,8]5P\ MTEF!3ZUXI!W96U?U2`=ALO*1]J4-&?"Y?*1T%^6Y?&10!.>Y@*1K)D^@@*2$ MYKF`I(L[*Q:0=(1^E1*2#I*$123MZQZ_?!%)AU0)RTC:XTA:1M(906`AR24% MN+5J'4E['LGJ2-K@B>I("NCG.I*>.I++E\.0PQ#/Y3""PQ#/Y3#^#N4P7&&( M^.4P7&&(7Z$1E$,7QCBN2C&>HIB^,,02G@&<*%%;1#G^->(!FVV,? MY$C_K@V7`MW(Y_/)7YRJ`QOKZIP4]DEQ]V1__V3WD!2.CX\WLMGL"J.R\1:/ M26'W9/?XI+#+\%*YV,T=@%3LYN`A"L4K$%0@.N'@_4MDS"O=&$P60XW\CLS; M'K_=R+[>8#:-MZ#8R\U8AHUBUBS1>1^FW M.NTRT4V"PL+>.:07;8@)@#ZD`IM)?K><*')(W4 M(+\O3&T.STWZZF^Z2C9AD8[TZ\5B=F MN@VO9"^&Y9E]Y7F9LQ8(J0'?X>66-@<$9#`&[VH`7\A;2&AUTR2;^&PS`/RRK9S##(H(/I[#\/U= MRK52!^:YAUT&$]4TZ0NV2=!@>I]9[R,Z'#';'%77E!9(BMNQ/A@3=6+.@-FF M?FVH0)"-;"J50F*JTDO8*^BIN@T"0@HLYL63J(H<6D/&$OA`U2/O\FVF#UUJ MGGK0G72:;@ODK-FL@&%\1U M+V58L1W-0IVQD?(GB8'>?24@P4"H*R#6$#@BJ<4U'X'I>T]2O M[*EK>9>;M6:;.7'PG+@0@2](M3^7VJRC/*J-CZ5:M4+2^4*&(0S>'=`Z0"VV M18#VL,OW33JZ4YP-51[&JPR$`L;UCK@W! MX%(-B\!2TZ^GU(P:SHQ-BXP7VL34`B@41(NP28=.F5)#"%46A8':Q2`)H/=! M!G'_'I)OVMP$AK-EP6QJOO):"VM`9(5M/TT/QKE!YE],:I!%@W'^K0F:C[Q] M0_`SB,]L`$IZ"!R#;BG7,^+I0[+T^_5\=GMU=\JQ,BKGWPY52^4`].,_\66@ M3;8RX&(CAK1HRGG>_"][@SBQ808,I.#MZ[R5"IQ`F9$&`R;(PIJ-IMHTW>^? M5VM*OY_#6R$V45[:6'[POP+-'X(\V2R6Z1N=,VFZUU/FU9F$@:9ZADNV@:[:ZS!)@:U/83`4R0VOL5C?1 M9)MJS$JXG<_P_[FWA&X2#!PVL\YL<8-!9[#-R'0V1-N@2FY5T"(&QFK0]D1) M,2W5`.]J?(=ON)W-OYJHV69@+@[07,Q??I0W?!A9@5D=ID;-UP+51Z8&$@AF M&-IZ4_U/9GH1IDI>;Z$9,)H!G]#PA-D,YC,3#5-9GZ$BA$DMYJ"F4$MLN^R, M:J=?3J-A`03&/]MH1I$W;V1;!6GH>&WE_WH_4:D;!)^`7XTF_#U-I6#D^$`S M%E-FFFRG4K@O<$!J)%QV6Z`?%?UZ;)WI5EN]!7BZVD\1'-M(X:"0+QP6_`TX(T^//]-8"#:'&P\JLEUL`T1E7!.#YEK6MR#/[BQXC]1 M1A)V+TV=EJG5M)72397-3C=`1'1[7],'C M/Z44.SJ@%-L]YA1+I3I][3N\<$J%,DA'R>:^`C2)_K\9S&ST#<#-,Y'4-7L#^[+N8T\?;\YP`JP^+K)A.XY M^`66IF;PSP9LUN9`U_NH&N@&%0V5"H*BHV*=>3<^?7,`@\W9F/@7VH5_=F'" M9WYD]"EUC-'.`Q(?%7+[N[94@CT"_$@-3+U/CSV`]?R#G`8Z2)X]')

QP<>=%(_@>:'8VZ(+;/<;9?*2MH:W>3LX0.!7@+3F''TC^&_C)=` M)/8$3"/Z()<&FD'?H:\T(RU)3S;IKX#''Q3O9W[OK;WZF& MS[DPR#1$@\+DZ+AUL97YS>[*+74Z>F;CA8X9S[#$'O$]KZ0RB3`8J#GE5HFP M3EW&)F4#&(NIH+4D+([<9;?6?_7J>X[VSOAQ-%MH;P:NQP`"E?*22-5<-P`>F"@WFEQ6CR M*?H/_;8R)@A+%PKF'.%+KPWNR"DU?VF'D';O2VM?QD`CWYO98\?X-,`@[/L' ML<0XPD?"Y)/^P2`=_MO:2G4X576#CI!0RF(%"+H?LU,1&CAN)BPS*TGYS:NQ$9@]V5(V!TYHB.I5%&H^#M2#@, MLH.*WHY'CFW;S=/&]:=HXXM41*\\Q*A>&S.T>PV,^AHX>)SU^T^\`[>'J*94 MK]&^M1G&05!M>7<9-HV4>PYB<_&J/9M4?3`\K\`U>$,*IRR*>,?\B1=O1,A" M#L.EP$)?S`V'S;A4/;,[TPUU#E:\ILX'8[IN[+?Q"(68)H?%+FG@$`QB)T<9 M)CC*!M>?C?HNWJ98I[?(5OJ5!NA^!V?IGP*1GBUDT%GDV/0,DHND=/A,>V19 M4QX^9UX762PP1=&\05=LH)H:&(@W:>>]?^C_WL;A@ZM&%QP2F@'`L`$[-;O- MQ6"@F>8)S`F\*O2EJ$98E@?Z:1!+A3"\<,NFS1,7=K[WP6@!WQ>E<\H[G+<5 MQ5GX=$>$/CB3\-@6"0C_"-%\@3Z@>#F?$:P#:DR\2;^0:?B2/GR)A,N<.DBD MO=2'P/;T;-J[(-E&\=(L-*1X7^8.6[:$/CD?1VE MJ+V3!3/S!QTVU2\IWTZ($NJ6.K>72V/^3!7[=MG[8#'@GQ'6WP^/"-E+._4# M-8$^8IX6:N+=W8-P>'X.NRO1)7/-TP>S`5FH:AB0I7%@97MG%EWFRS MK3%$7;V0]94]I%:O6TY?XHG%1O^LK93>XZ&BLF)O,8R&+&2%<0V89/D2SS^Q ME;[L\,SQ7>+1U;[T.\US+&O1NE0:GI')`SLJ'.^1__U?8G\O[A3L85("[^]C MAC&[=US,%7<=8X2FNU6,VUZ#F;^Y6]QD"G4R(6E,!@YG+'5W.P<[C895<&,9 MP99^E]GF.$JFN0"QTJ;F#5%-8MW.0.+A<_I*0^T7.GNQH$*(()HE5BF-0!YY M*+$?CT$X[KAC=-2C-$H,MO@&BGZBM6FBOW?GH38]@$!.,DR%!\PQ?#@_?*_/ M.@-Q:0")#FVZ_DBCB;,1R;_AS-!8\G+WN(`.]_[N$8]I"`N9N@]S[68"P^U? M+4;DCX.]?Y]R.PXF#8]&G):\%[H>A$4B:7B.N$SS<]1W"LLHV!8-\=GDU`K7 M>(A#Q-O=IKADB=,H._@^VGR:H=/9*[#I[!_G"@>.P)?'VN`K6YA<&GJ&CL)C MNFUL:N9@/)7UZB]X+]M%H6LM$V(D"9'Q&'OW.TX\H,-\)ZJ#J5QL_K9I?^ND M79D;]IS:B3TW@O!H9]J9\0O%BGQCW;$N0;:;0&D M_YT4]P_(;[_Q1VGVK%`\!/W%G]%^;]^0VA?0'YH)3CK&-J]TZX\@)^3?C\H$ M$L0!8I-_/73G5H>+^!3Q>;M9+W7*U6J:.O49(%0F<[HT>RAK=NF)D_WC(WM= M8!\J]"G!D#?H?:$'!8N#9E"M>5K2`#ERL,,6`(W@<80@Y=E>(5?8(]F#PD%NK^`QCZHC MN07B!%U8&(UR,IUV M=H%,0`B,@P+R07^T,`9]:RN3_LV?QZY8LG=HNZD@C5.WD:$98M_Q[);6_8*'O%I&5]!O5ZO^7EGTV2E4S08NI MJP_H-GIPL&?K:FJ(HK\)KB9XAR__O#7^YV7&V3O=;=#D+%:7Z^FRKDX(C1BA MYMC\A[FYS7S/0`OT5^%<[MJ?JY_;\5R) M<\1E?YB.U0%B0>EU=$#IA>>.'7K]D.+"P$GRX@W9_-?.9D9XIX*]<G>,!/Q0#""OZ2,/-G"`Y9]&KOVASUICIYG7NLUA27" MB/;&ALD[,$-KB';#M?^?"/CJF"+A2* M^^(@@!"\%)>\'J8'=`O/U:',J09AUTCM+502-E?0T]8J(K+(QY]_RZ+$HAX! M4S2IR*[.G:-E>HMKAMB7'FO>V6&SW(5]B',I&@._PK_,R\0E_67ZLM+>//KB M1'=->A27I#4GVTW]$4!#G/(,)_(309`3Z1F;]DD@AC/Z>Q)R;U$[77Y&IQV, M@$W3A0`FP!KZ>2KA`#-7%Q#H)[/!#V@1F7]WA>V;0,8N. MRJ%JT`->M$!Z?JY-Z,$ZEF\':H/VF1%G1:0-&/)5AAAA")7DQFXBGBL M:X3Q0FL\GRVNQU)^[7AWGYZ2P3,ZV-%B>65ZX/%>-AR`&7T]9'[:V.?]= MZ4=7;SQQ=>HL'5]4,%*:V%5]69H\T'9@FU[/)VZJVE:R$U&::R8P"`^AT_YV MVHW\9AO+E"P'!4P+%XH%ARSL6!-+U.=2*;[5VFHO+-&8#4]QO:&ZS4EP,2WG M26WEETUMT4"?._&&.FM9\%0@>%2Z+#!99JMK*5?&C1)ZX@[7EFZ8FF'JEOY- M([9WLEP>C>;L=XJ'5-D5#X_EO9$2&(>[`XX:3+A>DNNKP#/FTH=GP:A!([5F M^)83LIWB(;"^;O3IEGJKFO`9YJ1.\,J`V)ZD&+"X328'4.G1._5J!LN:1T_9 M!`_8EKM;M,7OP2:XILEEI2FR212.V9'%O?VBO/%N.4-;6",,N/1O,H29,:<\ MP`6BF+J>X1F+&1A%3$9^L'.)-"^%IZ]@"4MQBJ&&9AB+4_A-L,/B@7TZ\7X$ MJ3!XQ]9H-+L5Y;S:4"JV&T4&VG8=Z_XH!;7 M$S2!%[`R_FFS7-4C_NH/,J#+:%`*C0CFTEB;-$;%OACRE_DFZ\B/ M<_/SW!D^]3TF<`<[0N`<(Z`QLS3&$29>_+8+,!B8B+AHR3!Z5!V>LC_* M7\&F9DX,J1S=\W0>+P_C-&!A$KFFX@ M+0P09`V=.30PN7M-"PH1%A%@RV&=/G6OD?*`V0#U+=)K52M]K(%TBS37KE M3A&60).02K73JI6^D/)EJ0T>&JB/X-ZIP-ZHO5;]1VT*QY%(#\;HJJ1]^Q]N M2W0O#923MV\(*!NPG\,DY?C@Z)[$G8V-GTC=.]JCYT`*AWO[N:*4_WN1;I4Z MG%E@OE$0"6+9B M'2"P4&T#-B7?36-CR+F[VLAXSZ[PA=-.!#0X!(O7YC3P6D';H2K337H#"B_@ M:].;&=Y[94X3"8[6^JA5.'4HB*0+#I.ZXL;.^00:NEO[4/G0,J[Q.K$+3R8D MC,?4-Y?"NTXV=/,4!TUE=7]WAVJXFU3<:J:;ETY MWEW<:J-)+-POQ"'K@+QH7EZT8CUR60-"L3P.ZN^0Y7A\R+:`Y;`$WR#F2#"M MON3Y!QXY<6"(2X=*&C1Y9P2].RI!6X MN_VZO2R"DL0V`H8"VWH]_NXOKKSJ`&1[IF=GEU^W#%6965F1D1&1<<8"SM@2 M88\=&)O:?GW9:KRY/&G*(DBDT\Y6R97WUC)G0SA83*<4C_=`6NJ/G3ZF2QG" MN14)"%JZ8[GN>!@-QPJA%B]9A)!81N##)E>0='0<>MG%XC$35) M9"1%6K.MYU"7,,K(50`Q(GV=)%JZB=('!B2"##$:P6J,4(Z9!C!ID#-.?V+Q M!+VB:!&2B$77N.>V+M]>736N0:9`2IG-^N@.U#NGOK<.$JL;JZHN@0'5*D%U MM[3M0_64]K(:C\*PCQL2E1P],1,4?5E;7E7,12+"I(DM:%[W9O=](@J72Y5= M*\4L/UB29*['(M0$^C(8SAX2MD&=[HWO._%[CJ',U:@?=;O!>(IAE?V>G"O, MKG>TCY1IAX!5(DH+_>Q9.15`-1T(L;$THA.^#3VG@_?0_ M![[NA4__&(#WPU,`E770?>)R\%(P>:B4-LLZ!`Z;O3U&=>B4W(2,2,AGAR^4 MO#UJP%8#AQ[X;\@G,O\UOU=AV.T,;Z.;]^7@$U""[]@KK,Z\7*6V[9FV.6'_ M?U#"N0/_0_D/4(W'S(O5DJ2FC#9,(&"[%6.JV*TR="O5FN?+B4C[D M1R*58LP+ON!T8_PW6*[-@!B;.&&%B<'W.0B?>L)QD)Y73$+^R,U$Q1>%-V6= M:%].N8T3?%(7!5MD_A[A16,M8J6" MCNF[SJ)%G*-9^Q/QCF9%SK=QC[9\*R7L*]V73=R.TP9UPX_^L2O^16OK*F9( M9W*@UFL"7X:Z,S]"Y.]KP,M]99];?<$*)H0@_?NOX>)(`W=SV$+" M496/EBPJI;(`?*MB)0O,)#'W+84,.9-P]^(7`MN*J7^2G.!.X)\G)\#IA7.) M5FJE4H1Y:+T,2Z6'6B>CG>ZW/!8E6K]3D!&.IY/!Q>PAIPDF[![,R4`QDD,M M+0(J82;D.Y`0.7$5!@[2B8@LS?G%'3)>!R4=Z/@*;7FI\#A%I[!LF"NXARO3 MWA<_[=9-B:3-9!+QB!8V&9>\=?U-2O2`V).,$[FI(,2AW6)2D"/F21C/<*)>S MB0N_VTY_@#G"K";#:(],E]3=][6[;NZ>^R:[;7>+P8"1I:5_L=TV;Z_]`W<9 M.I_O`$PVT9M?,^L$D*3;,C)/TK+'.`!ZW1E3Z:#`"V;:#^Y M0=P?54KP.UYMQ,JI'F\;G`$Q*11OF$FE1A] M:\WW_C?5:R<:L63/-M@]%;>M3@RO/.X+!R(6QK=*FS8$AKQ'1^2-("%D_:EV M25-OK\]5%JW7_?!![:P[AT]&&>TK\TWIZ[Z0N"CSJS+'4S&.-X?AZ4&[WXY( M)T3"M=`[$%%P_V7XLJN=!-'^9ABRKV87CA5GHKQ07$^CL@4\L>)L`I=Z3(4S M),QF#9;T;,B43'SDQ!J8.)NT<,Q$*=Q?P\X-;+C?@VENSZZ<@9V]F;CXF)QM MSQ6`X0+B;=LDO4,J4];2<'(+BH8P$LOYNW,@-1.,H,A&WQ":2+"5;OMV/$YM M*T=D@UK-6!MWYGP,/UQ5ONC.^&/>,Y,.M\/Y<*.9>(><&/DR<\@!!V9:!ARP MV?YO8$HZ^BACV%`$F:;SLNI;W(^5*J,\??M!HQIA0 M8_0_:4E3LA\:/TD/%;RL?Q>7>S8`,_,0/(3!%,[55`0A%^U24"4%IU$@TZ/; M+,;7YM8(:HFI.%WH[,4E4U;OC=0#]4HM_VX7\47.@;,)S08B";V<#?[P;Z;_2"^I?V5 M,ZL6'2P5R.*P:]_5`=>2:)VH"*C6&,H[Y5T?RAOIJ_LU)_\DN0:SWD=Q?'_5 MNY($T@4;PHX:UZH)-"7=O@?*9%6+C8(8]G2WB`:@NKW#D-PJQ_#5^+4ARQ:T MY8*!--(WP-M_13`[>)L$Z:60-AW>M9)@+CK%";Q1'(DC[+\;$9#2$-^(`M2X M:$)EM[(;@Z,-).)(L[8P&59+_#O#F&MN?"L0;_()K&D?5)$S_MP>O5#'Y MIO2`73:J)7\_378.H]G+^@3LYT[01#.?+ M^&GR_9-7V3TCI9V/4M;3:T2+^31O<2?BEQ>GNL,[8,=4Z'#7!N,@'6C;7P>K ME-3$PO[C:-);1MCSL,TYDF)@HPGIC^/&!HXI6 MV:K6BL]9@X@:+3U]O7.B9510JU:WL\39WASND[7G5.*-QM-*#+\)#VB?B+]] M3='S@Z@R*=[FX."?J$MBR#!R4B;XF(;";2`I1A&1/47RDT'KZ6LM6+UWLMO7 M`>MG9\[_,IH4AT;H*<:WT9*4QY`*M.LVV\'?9IU!B'IEJJ=PUV$_5W"CLUJV]Q M,/E5<(NE)RP:6I*_$)%28AYK1\DX=5/%+8HZU.<*U9'= MNIPJ[)O_-FG MN,YV3R6XL8,:873J2>V)!Z]E)*X%IH!_B)0<-[%\I0EPWJ&0^/\6Y]RL5G:V M"U6;DE+(B-#_.D'L/^C[(C&`N94#X<3V__HTQB,Q_T=A_D=0&-IFB(![?S+! MF><'P-MNBYSIJ]7-LCE/$A3#T>U4))H0O5\W..U2\#`;L+,>INJY"*9AMS,. M0'2^*XCO$GIRF:VE/"Z_H5-:=D?K;ECYK1+1B5V@,&7=$G;3_]N>_[<]OWQ[ M=I^V-_-_RN[<+F]C&I,JVG0WG2)JGQUYXOD4Q>FY3HA11U=;>H)WV_[&R_"0 MBTXLU#L_R:_5ESLBS@EP96,Y?=T3/5^M8C;9#]`H97&$?Y[7JZ==62BR.;): MJI#FH6H"U?,=YIRH,JIQ@:AV^:/K_8J(9!2)O/I8J0*?Y=712"FYD595@[T2 M8>I`8Z!KA M&VYX)2.<)BZD>#TBM20R5A`E"G3BE7`X\:L_G'F_3E4]88"6-T#KU/MU[=]K M')TD#O'Z\K*EO*:O+D_>>5>.+\]_N+Y\>T7],P;\I3WYS3KNA,&/O#(9K]PQ M7YV?7?SH/02P)6F"C3=^G8N+5JSNA5N<(VF(*V\:S=;UY<4/WAM[0[Z-O&;9 M?\U$5_#\G-HN;LF,OV(TCKAY'9V?:[J)>9LG#Y1[LKZ>`^S__:.0;7;!J=9V MJ@4WO8O#Y[+*L(PD9,\Y@:!NM'YTGESA/.^6OXB@OWZV7P7;ZX1?R672]OT2!<859`9Q%/> M>,'))^2%S=+M]#X(`XL`(,WV.5;$S:`T1$?][E2-**'\0RR0F6/5DE31_X6L M^&5WE772SP'[UDP-L/Z4*H!I7%[)HT4<6759;QIF; MTQ,0GQ*$-]Y$B]@#N.`PYLN97!I'$K?[I\N4_W.B?H`+$&5&(*454 MS9>@_9B!;Z,X?!8UEWS3,`U7C?K<>#<07NWN4I;BZO;.IO&RLG8B(UK8H*[Z M\F89&P.I]U(L!.0++(7N4OP3O:`^ZQ)96`.)15U@5)$.D@6H6MYD]Y[=S2V= M6,!?M!!#C%!-L!>_T^X/>Q193RG?EZD92!"R^AP M'X7DP_W66>N\<1B.9I-NL+_!O_8WZ-Z*.<%!'Y0E#O>OKAN'*Z1":.NY5!@'9%KR2`89K-NU;$).L=(+/E3* MZR`CUBIIO9U2<[B_:%_F36'>'G]67YCS=XZ?W<%RSI];$ZZ<'=M M`^D-98;'2!F.#.P&4KU(A8\/-Z.!1QOZ(5::[G'=IC[L=_3/"/O8*3*VDF>& M2HY%Q?N"TOF\:7.:!K*-,-_X6CP`1XM%:&H M>A:E:"WB8)=4.1&:D%@3UK$L([;0D\=N^S#U"5P/<7K9#_V.6@4R<-N_FTV" M534:8\\<#@82ERY/,!MB3$8?;]&ADH?M%>$-2#T2?0Q1'A+HGM%[,:'!(@B/ MXR#DW4J9@F"SZB7%#Q'3J^.3H]812X3JJ-?C'!,__EPDQ?MG:G3,X^&V7']& MHR+]AOTW@\/-'Y*#G_8?[V<4@PQ-Y)%;`#ZDV,!5AM,\T=;5@@\F MZJ8B052X`:8"4+X=(:@IX:"N$,73R=!,R%BX[`3B0?R6L..@&7PF#TE)UF0, MFDETO*+"Y,;$=)#KD(HX)$R#Z1H4=8)Y%[T\+?1G>@#12+T4J%=K=>Z.!YTP MW-.E_6C%R^5-G8H,US.R=J1/HSJZ,)QS;8DUC:RM"T^=\@9OXU3U$&YD<<(0 M@WY(1TO1;!S'ED M$K`RRX`JGPHJZ[B0"!V"G\;+#%SOXI>"N##!X3(LX``?[_L@>](]>"#,PQPX MB0R/@-9163'NHWK]"1PLX7ELZ/^:H4`N=09;(!S@Q6+W]BZ%Y^K;Z:Q>MTC@ MZ+N+.'JL+S+N2KVV4Z]57,9=@<,TLNX*;G\6RUYDKM^>-^J8^3$#C.,NF-0W M-M;^`B)49W`_"J<;+!&_4"A6?21`%4ROUYW^0/=:R^B6["$)F(<<,#2-WW3& MF?OI=`SCCP:](A=PV5C3UX;!1W--M)6*V;=B<9T8L`KA"CPP+"*&AX'YK0DG M%T:$I0Z&:GU,_4$PQ\&PCH>4F@%VB5=PC]C41H/@4Q]>VB)%%JX$#V&.AL9L M.'?#/H@:>"+4,;P%KH-L=D0AZC]24'?!$`O,X'$`I(T[V#]R*H,'X$B88PE/ MX:O[&W`4+TB"^H*Z!V(\`9GB=^#PX11MVIBTC^]CG4H030IP-@0`_&V&,E(! M!\,+-"/\XLP*#RDZGSN]>N3=[R:CV1AW!,L<:AH,!J'LEW#Z.(#M0LE!0CA] MDQ\LUM?#<0A$M!8@G,&V^>0,TN<"AC)X/T3`(5\#KMG>/V_\TGASZ=7Q^V6P!&'+^9`=SU/P#TNJ,)B-9C>&,2KW40&4&/9&+^ M)F,I=4X_DSYF'=7KM]>MT\:U:OQR=7YT<82EZ['O^A(?9T/X\LT;;"(^ M'TD?@()\"X""/$ZI="4L.NR^(F\X8%>T=&9_QCYL=-DK>]_0YO6Z\UN,("4@: MY[JA28&F#9%&KXY.FHW_P&_82&:%V7DEH14)PB3N=;C"$>'`,I\!0)\)C%"B MI$;P>%FNEJX"2O50X20G+@?3$3&ZXM+//;(BB:15ZT^T1`VT()P!'4-BL?2` M'YVRK,-'H11`'3I$%VBW+#W6/LWID*HJZQ>$E]8T!A9H,`*^LO1X)$[=F$G9 MO4R[?"3P+0H1\#B!/Q`T1'16*B:2V@Z1)5E^DE:VM:^,E@-:6*"HP=)#.?*F M#T*A_52A>=G!!&@PD.QW0C*7/T8ZH&B+E/OLZ%Q)#@;FI\%@JK\P\UWJ(Y'# M*)H7%.<;0-Z#F[S@)+61Q8M^L'HP\5%,486+)J^#@&6+.NU_BUL/6-_.2.!` M"=9-HB_-RZ,4A:4M`DLEI[8ZX4B`W"V7@\FDQ);\,RPX81"Y2BB>AY:+#!EO_8>330Z\W8-IHH M/#1G+`GY0X5VK`$E6,8I<`E-@@.P"Q!61G<$GUI.&.PJ3&Y5/00=Z._P,6UL MZPE'2Y$G<:C-G#KRA4S`=)JO8' M7'^ESNK/7ZGG9V[S=7ZN\'4+$/^Q^Z\.]_N'1"'W-_J'^QLWAR*L^6,E`=^= MA_#E.KQG9U@4/SU55\_QMS^4Y0L>J4N;860JBH2T"Q8M#^1!AS!YO'KH3@G9 M=;WN/WLX,F3&>9&(<)TH`LAQP7Y(MF9#SH1SD.H^:#YANO%^ZH0E3<=8]B>$LFX\K]A"ZT1/CZ:#(1_*CKA=(M@13X M#=$8%VW$)-QOQPN:V!01)-86EB_>6'9`I+5LJEASEM[\QE)N,]J4D,)KB$N3 M..)U(S[B)(@U96G.;\HY59.:QL#*]L6DI@BQ6%N$6*RQPR/]#DY>#=.)-?E\ MJ(S)+EQ";Z)5_U.D!2&1'574U+Z8CIZ87?);8"B@STT$%R.7!//J"1CV_*9^ MDX1+D1$$:2)7#=&(8$(]ON*1GK*X]81%C,S(72X9!$&J+1;(_M=)V3()J):5 M'.B)\%-#_JD<\.`)L/T+>NP1*7=!XMQ"1C89#0CTR&"%M+)PP>%-+,";*PYU MIC73WA-H[G-Q9_!(6'&E=91,X^NJ!#07+_I+;B=$#I9H3>G1[H&<4ZGJ&*P M5*_4%BD5EQRN4JJ7=NJE;:MGW-I%+2/\%5>`&P!MG9T@ZWK#X:#JF>K?3F"E M4VYV^U-SZS'`/2QW\L_RB2Q$VMY-X'2FF\98B#2ZF6`MO/2FPD6\UMW'3GIC M9"/2^N,]SCRQH>8@2\Y"F$C2N"]>Q+E([*JPC,BHPAUDU$G02WRV,(;%K8@E M+&CF,H*D)5UR!]'ACV-IBP+0K$X+!@ ME(N^.(`O%)N]O_%QR\_?[`^=.W2?6+#1DX"0L+F_[;9>M*$7;N5E-_&RV_>A M/^BM\YHLL8LCK1=OYDB'KV%Z\X;:K6^6C%&.MG:A6H.M7:B)23@^CX:C`9KF/?;Q.W(<(,*J888A] M8<&6W1_B93@%_S3H@%C7F73O@P]J__[#A[_<]T'&+DYFV")X8"J$VP5^AB#E M#>^\2S?>K[[WJX,PJJ-K\`0D!9\GPD2P!;>GB]C]X:[>ZS_4A2%S&W1)G(5F M&._>;?_.2@<@>#Y;[W:(D'G-X?+])-+N9C#J_DYQIRY),`._F`TB'3J]'HBE MH=L:KL).'_@CZ),ZW)M&&3R/?5^V4#(7!YV;8!`9G--GN-(/]@8H>E#^6V2B M(7K*$1CUJ_;])8-#E`8[=YC=N,T'_O#H[^+/*^]B!9"2"%(\R_>F[J\/G8G7 M'':B^_O&_=%W?RQ`'VC@8`_TC2$/SBT%=Y[E(ZCS+)^$.<_R/N+`=.?@#24`0>&L.09_D8@B!D'?R0Z7K8\2S_MPC#,[@AP.]["V%\@+?`0+U[XC!Q]XU!C;#A_-U#9X!-ZO:!3WR3HA*1?0,7# M.`AZ.?$0A(%Q,!!X.@-HU'M$8HR/P)/@0JD@WN+)8D&">/&_2"J8=#=^F/1[ M+1!OB]TTANPUFB,#>.V^B/6GCU"KE[;JE4W'E8;\W4W(DG5G?7M\-/M$WJ_N M570XFDSQ,@<3#M'+[JWW>=$<('T.T M%L`(XK")[O8["8]_TQE'G&_/WS5Z_6GLXM6D/^0II3GC.G&/5^WCTZ/KUO71 M1;-]]+9UV?SYK'5\&GWQZ8A[.8&(R1UUX,!FJ4I^B)M8+*MF7$_#8'"[?GC> M":=8[5QAFI;2ZIY[C^+5@L8GRBUE*R"2=R8!]XIT.`!+Z^I]VKJ<34'L>HTX M2I'P/__\<[MY^?;ZN(&9:7AD\34Z4.\:37DDAU=&[[NU3>S$^/9!5IV_PX`` M];TR@0.JKN9.P0DUWR7ES`(O>9K/%`6RSI+LPCMS#.`#TM.W@ MD;%[WQG>!=HV>(O%ULA\#R]/E9I`YO::D#6#@,#Y$3`#D7(C#.BX>Z`X3H6> MS/,%68?+D/,XSP_<2?_][^B!:"[B.V.L'?:DDC5R&M]7;XY^:3=;[\X;S?;E M1?O\[**!CMXX[G)M%4&2/MR!6_\:Z?V^"/C2___&(]PFTA#KFB[75R\$_;MD M'_:91!W!`8(BTLLTS.?QSF>`I;?D\J1U=ZEYE,^:L$AT3+FTN;E;@',7?-DJ MZQJO^&&,[P$_9R=L*ESE;BT348+E@?(N4N-FF/S>[H1-WN87EXC8S_)_V#`D MNU]R-@C(7G0H!`<*P<27X(.H7)[+`[G!?/[';1)46>5E>%^D-ZMVRUOU4M7A M>Q25"7_+S'DP[EV]"E"XN@1IN-_K@80-5Y\I-Q;A\JK5;AY?J+)SZTJG\_-WQ#`3\L-@M MJJ;Q7YXTVJU+V,9'QS^V+U^_SG[" MTEW9X^;I4?.T>?;_-O+EW-J&VL$/HK"V$G.E=`X"X%0S\\?\!'W'XF`!G";H M\0A.YHQ\-&3G[;0_"%EF(>&BA&M<*Q=V8L+%"8>JI`@\CB#!`30B[ECIXH?! MZ*8S2!@%0`VJ<93$,M_'`J\^'<>'GU6CT.YK>%\@_ M1@(26L"/8.57I-T6O!Y0)>D#+GV9Z*/SVC,&C#`1PML053#)6.K!Q7WL=S$Y8%U"(BU5$MJSQE_F/@6OGRY/*BU<8, M!S^VSRY:C>N+(TRN'52W=,$%$=Y'=U2'MOB$H., MMY:U+);9K(OM!64"B0L2X'S:(L?E@NP#_B'W$-WU#=I/!7]PE%&5]W$0/F=D M@-,6ZB.0/*^I*4I5:UF5Y0%!VJ9]_(7QS*L^_:',([R+/M6D8C0QW M495CS:1X9QV>A@GJ%D#S\D\8J8/`%K1(>SJ9>^WX0H`:47"U?E"`7WM/ MHD.4-&85(K6#%!GL*S?-;X?B9;P`X;47-Q4_?XMY6/ MJ[%IF9$)I?#ND&L-8,?/)*F^4)KS,_P0]OY5@"&=A-VK-F7`IUPF::-E@57` M@:S]XL6G`C4L^&@?'>KR"L6,Q#WK#W5Y%1G)&PLS%L`X!#:04]JFL#@.\BD7 M:=OTVDJ(OS34J(<,09,8"M6$"QE*6Z@D)QE*IAD_\,"PF1I)/=L8$%G:M!D, M""VZ8S][`=(Y&=(V_%\H1.\5O MC[A33.:T`R3P!4Q0@&D>XG?RY3T9UL2:\E@`56@V@^V^NK?J>A`&Z"#);$#X M@)4PE\CB@,?BY_.2)Q"M,\39%+$9DEVZW>T,!EX+WH0MC*54G`CN.T*8WK17 M1(+]J[]"[_?\KK32-[/;7RNE4O2>)1%K:ARY9]Z)0I5T+L78WO>;F)05T68` M;#FL:&4U'0(D!Z:DB@+XWP&<^%Q$7FRB'BK&!X3/&8H0O(02ZXY!#&19?!CU M9JAB8.+,GL7D`H"ZW<3!*,P>P9OM!^RBK5ASPN7MT1I/848H84PZ8W%2'='N M2QH/K9UVS1->0$>8QH#IX$$T)8?^)/`'HE"8HN[RY!VG8N?LI2ZEU[3X"<-= M73>>.IHES*RW3VH3>]$DO/D<^>W_6@96&VL?)_VI%TQ@//&"3_TIG$M3QY^3 ME7(_-2ME\@"4YD;%MU="=J523B5`%/F$338>>8Y.8Q3MA8FTQH]9V/J%U+[X M<=,T0>/$)<4))-R+KA#1#)9!/&(1J\:]H/AV`@PBP__:?Y](CIP9FYI9J6T2 MJEVEM4VK@96X7I&)R-K9EX3)%]-60W_25M7]1%?X:4_`SQ)K'WN9!>T^8R:! M^8`D.731"N*'>-??#E975A=,##\;:R4\XTG2;G:)A=_Z9T4]H$8PB>S&'OE[ M'TZ:=0^0M_IA2B-'S_I.+!:L]II/#4^0N10IOGUT5)#^&D3Y[\6^NTO]5;Q M%.M/A@/)&(8Z+'J)!??Q[7`C/S^H+"+2-'VD;^ M$F_I=:-I[>)9\`#\M`F41!!"9DBHZT[)T],F.X.L)3X;8R)=L:(/\GG57?Z&VMNY2Q]A^0"95T!K/\"F3?"R^'@ MD;/UTR.R$3T$HUK[S=$5FJ*3;QY=-XYT]MJMK1H:]_,[6.!6YW,#B-.YS8;V M]M`D9MRJ);L.VKPD^U@VHL?(N=FF265!KP&4;(QN)S#S[R(ZB():V7L9KA34 MW$.[EM8H/Q/+=2K+:O:G]*2\G*1>8572KZ7WDF_PCV?KF?FS+-(LW=XX:H;R M\4[M9%:**XG7(QVM52]=FQ.U4)""?W5/"WL;:R+@)FIU"LM`12/?0_"0/A`K M@1\8T?5H<931KFBXQJL;^/*\#KL67" M8>+J;TT/K'HK5>,NC5F!GZ21MY,$;!2&]KU:+\M7S&+?O8=9FCYI&BU3PB&? M2=?_:X\IZB#YW/P-8=RN]%Z;CBB03C!9;R6R]T#;>[C6QN^1^T['R`JSK=." M+A%HZV5M'7$L<9J"?A$!<'VVS`LX1*V\?LLJ/ZY@]+8F1)'=M% M[(5TC9TER4[2D369_LQMX@\F8&$E<#HQ,N^'[E@'DF4U?5I)M`LQJQ@]JLXE M/6C@XG&[U-_&:KU0_6R!TBJ\4N_),>$[A;*%97?+6\7:AP6FA&_2AS7'Q-( MW0$;`^F-FDSM:+CW10K*R1G2904EP]G%K:"91"15GJUG1RT921VJ]4J.K!S= MZ8PRJH;L'6GD`:^&@GY?OX9A74U'8[6O"R0M)XEDR%W26KYHPB#JKQ^R_R2] M<$$1A\3TA6&`JNDE^=9_1VSEY.>>6--79/`Z*+/E3E,@;E;]L*<53F@UJ: M*A_7C7,=LBCU:/C^ABG1X)@7I+**/KY+<:N+']LPRGLT\+*:Q[\NM>:DQ`@6 MC"1G?G'+#N^#8!H6;'"CJ8J#4\#:D.CNB9:I+OR+.1=MM*\$,[.'K)Q>N2@/ M@'W$*S5&JQRG&8'AR;4)<#(@SR;G'HP+SRF@61-:H!$L)(]Q'B283#`C=Q"& MG3M.)%(.,>?I<#UX&$\?R=V'9!&>_?''G=(:U: M5K)PNRXDLPGNQBS@Q:;@TB5\.9LXW9$N,ZU)_^$810[*_[S$*3FUA&D>G:^^'A4ND%MX+Y/`6",?/VKH\R+&\)DQ MLUHB?Z?-S>TR!J_[_DY3V!3B\52(>S^14],KW/2O/9>FI6JW_`_R^D%1RW'D M."A]M9]%FD*ZF5W9WUA)UDBGNELD*+S_+9TEOK&&?]&R+:GB7ZS&?^94;>!K M^J_Q2S\^NFZ\?GO.50&(F4VLHQ862QOU9MU`W8U&/36D3(!W)FR/BM?X9[GG M!PK)=3@&^1J17U\G(6T^P=(Y^W$,6[%-5\W:V@(I8`=3.I6WM/P8+P\E)H%$ MK\:X9N&+R?\RI#^=\G\YU9?E?@+AEQY)M%]N?27Y3[(2/;]N')V?O^,%C&!( MSFAQ>%4K5%YJ:[=:,[$T_QME$\;D!8R3((95";?12[AF2CV**EY[`;Y?/P0^ M=C>D.!VT7K3/&Z];>_89:1M$Q78(B=I)YU$==>'R?6J,`,%D:VTMH'MW'CKC MMN2=,$HY$$OQ?2JUTK_#^VP#%Z?WV<1(K+*1:K"UI)D0_;.(,]]J_L:@D*SM MC@;C..^,GS35B(VA62*`U`8KS@GQM(WF!Y+:=@F)%#:7"29-&6&S7MFNUYQ$ M"IL5$D/-^/H0KV>#0;7P2U,[=Y*[40'JK@(6SL2\2G=<."KTW?-L^.C125IM=^\^JX"83U^$<^1M,[N`'6P)F:YQ.9A$17ZTAV9%_.'+7T M4<5PXYK*5\L[A8I0*8S5RC"M*IB?.L%`8C"NI$/=H%*XR8;BXI*S( M(`4*IR#%P[_).=L?2C4X7E?*G->;#7L=@-TZ.L0/`6"]U2GG1F<46>V%JX@7 MX10S.HUN;XM.C2_2LB'DWUT5?KE"(\'-#`77-=4+#[YSK"'T[N_WM&@5?5LK M(K@#J*PQK%Y<\MM_K[X;CNAJFQNJNHH_)\%NNFA8%G!B8\*N<)VOS*I+\A8:@7RAD%+I`Z+&J[*!XWZS2B>MF3I97Z>V1_HJ?D M%D(Y)IC!D\RAP51<_4R+FS2#_9?AR_!095_VN>1]<"P>"&$5>F%W0FK^6`3<%Y&\D$032UGT^"P70Q0^1"PXEAIA>=\ M`S)^\/!`B9@^!OH!'+5.1)-$N"27,W?S6))9L*-@A0C+!\B5B=."A$G#V24O MJN:(AK'*R+#_,!X\ZB*MP,KHR<1/\&?2>%2A448T>?C,H&H\`]*'9@I*91F: M,8MJ_?2G^'A)GH<^;NOSJ7,>8$6S25`2MBE'&NX"W@81+#PZ/FVI_X" M6%@01%0&^2R*86\<'!#OX$"01/NF"&Z]NWK_ZR]7[P]T,@^J7(UYXC3^^\?R7964OUZVL9/H)4,5GX]>87*5.N63X30Q M.I_X!,XV>*S1&<0P76M_--,XI6L@;Y?(P%W=W1(V^N\-ZBA*/AGP2)*62HUR M_@X-I@OD6FZR2*KE5E\NTR;WWZG7:E:BW2V4-U6>_K*>Q!&GK(O(A`/$4/%Y"ULW-?#X'5PEWS##_">*`VW]_OY93_ZG\2^5*CI'0=#L\ M!(D2+R%:"K7-FKLOE171]*LE389NH)_"ETPG'YL-J_+XGT5SBB4HJNYR3?1" MM>IHS(P'?#92##O'*\,N+QP"IEWC8;/(10J.YSFH-555>7C_V$#C7`XFAU-K MX]R,?Z*\`7;>\W,?^;@9]8!C3%6"JDKCJDF*))T%7)'9C,WCO^C-\W/>W!LF MI^WO:SQ/@(+Z.C!X_E\$@PK#H*"Z!3QQ8%,+!HT?.$^:YEK")+O1*2WQ>->) MS)V&60HS&?(S^,>MBWZ$^@>MCW*S<\G4G\0BT@JPNTV68A$)9=5U*O>E6,1] M)'LDL)A-IT!"90LI`Q9AW1+*$'S"'`%RIG*=WBR)@;.>;N8ABLD&Q*1>=B>2 M,W]0_S"UM[%&J65L)OC8X0:DYK*5KAE7T)#OIL5"X=1_C'_@P\=8VQY:-+"R MT2.RAI7^5'D&'Z"Y-I?VQK84Q[(28 MG02J.&5;!+MY%,'MRQ2!FB[1W=O1D3G8@6@W<[H8HP>ZN&RUWS8;)W%4H.J> M'KJ@*%NM_.A$<=ST[W0N(27V5W)_7P0S M^RLI0UA_>#X:Q=.$N1G!_$Q?<*,?+)LHK-T^^>L/5U?MMCM(;V0RA56W2$-= MW2K+Y(3V,\753VO^QRR8/![?!]W?3T8/6+]:ZZPYX27>4!\W.NIOV,ZUO&'& MU:O&=?.LV6IBL^>;HJG\+VPRCJ+2B%"=TB>IDNLU.4S!- M_"[N;]_KHV"M7.,,>CH]L%9JZZ<,1VVIJ-2^G4U027%@'X+NMD#8<$VDSO#J M^OJJZDSN*,>'NW-)U>5ETB(C9Z+`5_W;5R="/ M+"H'`,15]#W!"V5S(:?RF)9^SQ,\T,?A88Q="S2@UI'7Z'6KFJK$)C[\5YCY M4$^='E'0?L(TOKQ)N5IAW[YJM:S-+KZ2`G;!+R"3_=!^?0:L=_5EN(K\]Z;3 M*[(K'"QGD7067D/KDY_F"21)Z*2^3'\B*$+D3&M7)+=:R$()XC,AS^T=4XB; M1R,?G+^[#CJ]X]<_%+MUQGO,6M.FE.0P`FK3C/+LM-4D)X63UDD6=Y83&"'T M3-+4KF6N)B/**HV3T7H\K@[*M>>DW8;`DI)P`RQK>K,G#'-]'.TKJ];IM2?= M+)Z$Q3OFF`:S[0W\R8E/LA\ZD3XEV`%?8X3&TN5J&;09<"F>"Q4A&MV8T@7K\U2E_(\[7?8_],;:`1SQRMB"3>-^*B7KE_'38=@7-V'L11^?R%F=&+V_5MET#,#IQ MGF`(*Y!:+'#+OM=OK\_5W0P62=(>GK]K#,/9)#BZ"4>#V32`^UG4MX%L&]AQ M*)W79`84[(;2]P63AS[6)47$'JI)YR-F5<(2P<$@Z$YA@(^CR>]AKJC4^JMS M"[UTV#WOS1[&[1$E"F_W'QZ"7A^$1JH\;Q*X(;3:I`D,`7V(G9+CZTUPBYZJ M_J0,8'TST\+GD0,QL*/9V+REW>,$[NTMDK3*VSN6DN"0G]HZM>=S9L5(P-:\ MJYQ%\@_Q*3]_UP^/C=+\]6CRB\V?G/D\)SLBP<")BS MY^]0[@ZG[8"JWO2GO^I8`:3"F&;]O3J$`]\F\;C,^;O+<3`\QM+/HLN^(7"N&O,[K%R9UQ$ZY0C)B.Z#(6U!P M`;$H*-`ESZ3F7`&\3JI1UO'*Y-ZS8'$7`0._#,W)4I+$58%-#=/(O+UP9@)2 M&MVP:P&HA'N>KJK;V5"RLF5/&J^/WIZWCWV!TN.#>7E?93=3%D':& MA0&5):N15J,F]JFE]I$GW>KPJ'#:`]*!07OP6:?`*-\D=4.MHM/J9RLV6.JMPRX;BZO?QQ-6&,K7IMNUYU$JM7B9!6 MDXZL2A/1X!008Q9'9CLUH3/C@Y%S,9/[ M1:++IJW[DIJT6IMMIY-'4US#B>+!6\/@8V_4+0H\T+.72R%4Z,WAWZU"N>J$ MZX`@"G3\(OB(QZZ")&F\"S!M(_!9$%:*MN6&_@IL$1\B]2^H"$<",.RDC'-_ MCL(:(C441#XAR9]RH/9#UGUTM*M7,?-`IGP+],#!A-.E,'E&; M#6]A.F+^0GV"0&X$@EZG!T?G=5V-6)'@`SRSRU5@T!+VEP ME8O"D%O`:NDUX);^F[)MF#PL$V[@,")QEK:)!I5+P&-W+:Q!+J=\J8(T@N03 M3%&+ITQ""4I=BHXAHV%1=Q/81]^57O7JNM%L7+3VDG!?;WZ"E9/4U[ACLY++ MSNXZ0'S%0`')V4I5&+'`=O`!G<5P9^B02RXP5:EQB:E:1?L3$!AT:(9)]2^* M&=RMV=/&^94#L;RHVMAU!5@H:LOAP,V[#D%!-H#Q9'0#@LVC>*+(8.84AH,\ MC#X$)$'#C1!F614KI1K5$:F4MLK&6<+L M-9Z[3AP?Q7F]4TY;_5"71=*$1HCE_-6,P%'FLTOR>VF[7*C(%H8#P-OCJUEX M?\01&5+XA;.P,;XF/HAWB'V1=3G@<"X6$"K9A\KD3M=[<=&+Y1>]�P.&G" M6/R7S6N2$:,(&8GRGAP-!J/N\6C\&-F(!17KM<<.-W.A)$]D"F.>X^X=G4(^ MHVF22MN0&K)YC=Z&T.!O(A["N@SQ()4#G8Q[HP`CK8DNH`<6%A`0Y$Y?'.5Q M`>TJ=/Z.8FTOCT[JK([GJO;KUWAF@AT]`HD:V8YV^0 M6!0VZ?S)P2T@W8X8;V143=]@#]-O2M.<'*&=BD9)?&0^N#UN(2MIEY#%'L:P M1>,XR_79S/:T<732EH+3%&*`ZOR@IR=_%F*#K"%KIRTX>-&I7Q_?=?IK:F,, M9>VC9O/M&SCI'<&?D\MC7H-*A4_J%636VUI26E/:49O)\DGKQ*@>'SJ/1,OT MP=*6F`P+NG-(#HF/D>,G4,;?/YK0=00@(,O%9:M1C^3O`+F4M4QX*>SW)*J8 MW,B[4[4NNT+>E\_@?7@.NABCO@X?9F4FQ#WI$=,K'-!J%2D6DQKM.;L`Z3(9CW+Z4GI!1:D2G_C@0V>^ MZDY-5R_+:.;'7V0<4G&P1W_&J<-!%$`H%6(6757Z\.?0HD1M8YP0,\O`D41\ M(F4I@)-M72RUZW-)Q&5=AC\YNVZQ45SIM'0V"R33+=/CLXH?VZ\OK-S8IP6?WZ0MI(56+_.FL M\;.,O10UC#*V=,Z6\?*@+DDD_==X`I%<@DHNI4^QVH+Y"A6GW2*-BM,TT[J? MJ;\"U5-E5:K52R7X3Y5WMTL+52KN(!&=RF:]5K(ZE5*A!`)TH5HBB0YSA]`Y M0`A7@E:13OCS:YU3DS=X2_0_O+D2BJFE:UY2*B)92W3"MM0G:+*=P>Q@EA2G MZY5.`7[`16$R'EM@3:M^;\=&3\^2PY]KYZ8G38/!@*O-FZ(?R`;)!W[UMU5* MFDV1,NOI*(:D)EJF>G-<*@//& M]/1^U,VWYS?UE#8I'>I/']'*&I_9(2[ONYM0=;I@$MJZ[N0"(%(UY_C)4O`& M-S0D#=5K)@J45(%XQ,NY^\DM^.:4=XMNJKTY'6#N"*% M-:2-6U"/'`*U'P3:1?L@X7R28`.=BXV]A^61;FF[5N=.YU%!]O(:.L.EK,FI M8COM^5[/V`=$>?SG.>5@@6[MV1#.+Z.[(1GUL1X$WE[W4RBH.FF895TQ7SH2 MC``@I:P_!WF(D*(KX,F>ME!B._ZQS4RF8"^$&*$:?.JZU\B-JBTSC[;MC:;P M]*1'"60CQ0JY\E6[BX9A'%-*7WN@S2@-)UN8T.`$0!ZUT\EWH%]_X/MP]WN? MT%A&0="193(7+,*%LYO_-J[=T!7]MF/HD(VL(J^XMRYYZ"MWZ=E8E2ZU&HV; MQI>>:1+WFFRAX12.M51\=,6<(2@K5]T&5+%?8Z]/@7>W,%/T.6*A#6=(5D-G MYAGR2W,\%K+K)IOT9STEA`>ZISLP0I\./*ME%9;"'MUFU[!13C((ZDZF/A_T MMK#@.SK]'8Q+151S>D`"U1H/R_?BPW(L^($X\:?U92?Y6&>NU)64>?KY&F(5 M`YV^8K`/(H-:0YS2OYYY*3.A;99NY[C@X-P^$JV@!40BH31W`#Y(>SVJ\ZY% M,-)U<^`05KC@I)%`>AR&/91!PWGP_XM68#H'4@D,I=H4FX! M5'='CN"OV9"U11O27+?YO'\X/FZ_O4#WZJ_Y%C3>REXFF2 M8YFV(U3)9&NEU4$/(O.+T%PG>2M1>EQC#[TX8$=9X$[H3)$B^TP M'6*\V@Z)SHCC`9BR71$YE?%90T4(.;ARK7O`6HJ!UND!@?L$XZE( M]NL\%N+QQ\#,BN\Q)="#%*DEI:E%UQ!*"D*QV4S%,?T8W1DN(,49HB,27"Q- M_0:`'T7X8+2$32@52I`!7(.Z$C\JO]>AD;5TN9_:\YO%$V9$\ MV;Z"C3'/359K,2-.X:*M80HK*WYPG\9\SA<;W7N?60P`6+&X0X$QMXZ&UI$6 M/?F+W5*U-)I,E]0T3*I>'"]=3)V`06(6V>B-?JCKX_YAXS[5VIAJR>ZYEW`R MLL%+T1N?PM>D)L_A^A]& M92F@/DB8EM5CBEQ?WMM8PVRS`!\8A0OW9&)K9?JSMM-;>:L$M3/C4'U\C*@; M"!P,#S9FD2`9=@;C^PY!YN]_)V0^4*OM58$356?6J#SF<4V`\AC9!:YZVA#\ MIORP?%YW-WM`7XB]JG>4V+,3_NP4N\H8X-G[:"/L#V=!Y/WI"_TQT(ECC?=, MBSE$MZ+8DTE!'>>>6JV[+0%I',CS1D;7T`--$NQ;6!JANU22IY^01$%CPSC;BE>T:':[7@/GY1.`E;R= MX5B\X&EZ[_I#+HW5^BDRV3ET4!#6(8Q30>$D8H>H3S=CTS(3EIVB4;U`?P4B MY!&51C=4SH&LA_5C"ZSE:9"E/&8\C_S0ZLA>=!BNWHU.!W\_TNL\90-_\XU: MWO.FE[IWT^BEOX'3MYI=@Z_8^47402#XNCDDR')PQY*&)K/1+8I.<&CY MV,%X;#X!!1^"B9QB^J*/L08(.@F@M@(3)3DB+QW"$R)3='XW3YGE"(RVF+I) MPUPN<1YF)S.!4P[95Z'NP?;I,[*RD=/2QW)(LNLE8K*)-2(=DO:]P`EYE MBC'G2\%"L]1_M4Z%DNEQL)M)O-9M\5JRW,]]^P4M&%/\F;+B8T1#IB+Z,:$G M"%)<%LQ;KP\4@"RS"KL`33+&.%+T8D>0Y\U1C=`'-ET$LII@==])2O"R7 M^<)I5U#A\^73%N3G^AW&9]LWHB)*_J8N1N@V099#.-PC^8''H4GNJ4;O^

+\Y/VF=B%E;DA+X-NP]_SK;FR,7Y]MRR=JCU10FLG@ZD41L/;1*VVQO`9DN M8.GO\$TP7XDS&*(2.T$A#7T,PJ(Z0[+&JAA,Y!ATAC#H[6Q`54LN/TM5E]S@4V\YB?:<[U[D\#\9$NM^]-]L-A@ MS6_'X&JN698&%$XK@?9<(I'3%2FGBN"(9 M(N%FJ)]1L+XJ(!S!RX3FC3\[*J8]A^HM]KNP1&]YFW)JAS2;LIL8)ED/Z2>< MF9)K-V\EK71421^.VS(:2/JI]8Y.SILYTB`_>,\8D1`7*AA\SMY&[&R$M<@) MU8R1VR:P@8,`I=U%$@/T!'&-W$Y0NVXU^W2YR,6'M(FA`!QW'0T`?7C=BIK! MB8*N>RF,$NWP>][MN`U^CY7#\Z222`./ZWX3J<4D0I@K0YA6BR06T_#+XQY3 MAXADZJ$$!12]%@M[3`YNU`/[U\4==-F(QXB?JA>S.`*ZIP,>=SA.9:>&^>LLZ)WH*D"R_4'Z:8[I-P]?_<6MT2T8$M$R%]YA4$(/']@^*VC'S!GLWH9 MUE^&F!`$!Z=WT/U31'HQJ`B(."XZGL##I/1K`$5N="<,5@(?6XB2,BT+RB9M2SAYR-*33 MEQY0*IX5Y?>&RZ^G867/:A/4HE)X97 MS6PN"<^Y2EW!7PBQ*8<5>\#F9G+"-BH.:(('>1Q<+J]Q+U.SULP_Y5#+X[I8 M(RZK=`R'L>&%4[K"DU([*B?7J)Y2G10!SER-NL9KP=CL2`GV$>]]4Y9G\TSK M8C?J7@'U8^\=O>SH;93SGE[$6["X-I^\4+[3RF3*K:G/H- M'O%'TJ:E:4(?;%9X\2FWYR`1S2+AZ2BWYQ+O8,FGQ!O,[-/O`4Q2;NI"4(EW M6>Q/ODWPZ2+V7^H)R;DB^Z1PB:#/)PL=;1H@L)1QRG6%)DOE$ M0E9LC3VUW0=CBJ6]5D;U;1AV.\-;3C:U0H6?OT.P*ZN2@Y_[):0H\$4=5JS* MR\DVM8(N7I;\ILPN2T0'4P-QA0V0!3&=#PA)I4*Y4,G5E=2+_M!AW:_1U.+C M$ATG[2LYRN8OGAC.@%B@L9-6*GL"*`BI9.+Z\>(TW"C$*BBEH M_+1$P%!;%&5!&67L"2<<3?#`32:CFP#P@TIP8PR=H`MG26JW'L>!^4YC_`K, MXYD$-.^6.`T6)J"I.FFP;.Z;E;O1=`3BVFTP@06BF;,O"5YO\XU

_6NLZN M8$`WGDMT)[B(OF=\,=H!GP,O.05Q`=Y#N_B'_@,3&@BXXC(U#1Y=&H>D)]_7 MO$+NVP5<2=[4>GZTE'-H)D\S]9G,@Q)O6^J>=IN91MI=9AN)=X69)MXSC"KU M+C&_Q+O"_A+O^?PHL0G/.'T%O"V,X8_^J1%^!\_,YKK3![;N/@)'SL= MM\>3T:='_2RX7%`E%4%ATSA8Q\Q))*I1_XG2D=X+A#-;,&HV$!SK3(#<>##ARZ8/9\I"GAZ>FA\SNK M=EP5/8R^E(*$LFDO4(](FT7*$6GVY:J1I`%J]>HN_)>J&'E*LB5/`=*DE-9A M/.&3J_Z5>@54$;A:UD6#'(?&>+&@`THZIMLLR%N>]YM%RCH=*!9I5O;EQN$* M.S"KT01S^(2CAX!-TIPS'`-U@.*+ZNYS;/A(R2D[O.02?_+PGF^GE%^Q&0>Y M5&+CO/&F<=%J.F]+K27XUC3?\X,..9([ULJD[_!"^JAQKVU<79/'LG?5,\FS M3$H'S%1'9C.@)EB.Q2I,0_1,QE`I5#\XH@8Y&W."=<#5T:_;'#A(*8XW-RG% M\7:I4-LR\L7:..;BFQV,1K]3Y"3Z;YL?WROSM:Z^FSZ,?RV_U[DEHP6RZB]# MS(E%6B20Z*A:#N>"X`)'UK_[>Q6Y4(=5'\X&@%$8;?DP-KHG+7[I)'ZH7.D% MX1T5X>O`]0[6=E>=86S1*8$`*GA)>? MD[Y1:>)6HKB87MX[T[=&ML[E'= MV8TU;9>A@(L^YPO5#^$>[(^=26[JZ"8IRJ&MG:/6_"<9O8UX2MFFAP=VOHZ" MA?Q`]E1R.T0L\\/5O=6U9Y:7S>7M"N(=M-0SRE1)-?>513_%N\)[>W;)]P9(VC?.M`S6FE-#7_OAJ`#($64O MX[*51)%,;#+:MED]"-+Y0#2RV"$8D(%U-4;,5J4&611)HVE6HZX]2774M;M/ MFB^/0S79E<6+%$5'8#%D\V*5X"$\]/;HL_)0H$C7F!MKW-,7>?+%X[W M!S,;;;H7*RK5`M2E*IB.4=8"U*3K=94T'Q7.A5*HVD35EO!A*CT=OJ4,OJU) M!5`;+V*SJ<(](59202/ON2T,88],.H_D:<<(3:R1HWPZ4XDA(GGD]A'V"3YA M%:N6Z-!["9F7;#B=J8QG,B7,[N[8@T,2-8#L"=_"8#KU(OAO1X/!B)(TZ!3< M1?63-K:OETG4E2FY(4-67V"-]!)<,4+/D<%CT:1O>9(,?Q/.%T'I?D,HF27"9-DDL7Y.)R MG".SP4U#!!=QNJ6JC.,AG$H9](=SN)#3:CZ_=*'5:3O9W!0@B]2,X99Z4AIIX`16V9TF=NO$Y' M; Thu, 1 Apr 1999 14:07:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA14262; Thu, 1 Apr 1999 12:55:33 -0600 (CST) Date: Mon, 29 Mar 1999 23:46:42 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev psrc patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 426 Lines: 14 On Mon, 29 Mar 1999, Vlad Harchev wrote: > Here is a corrected patch that adds html source colorization to any screen. > Description is slightly corrected: >[ ... ] Here is a changelog entry I've missed: * Fixed the bug in lynx with lss support -when displaying html pieces like A B C , only 'AB' was drawn in style corresponding to . PS: This patch is of course to dev21. Best regards, -Vlad From owner-lynx-dev@sig.net Thu Apr 1 15:06:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA01414 for ; Thu, 1 Apr 1999 15:06:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA04863; Thu, 1 Apr 1999 13:53:02 -0600 (CST) From: dickey@clark.net Message-Id: <199904011952.OAA25370@shell.clark.net> Subject: Re: lynx-dev psrc patch To: lynx-dev@sig.net Date: Thu, 1 Apr 1999 14:52:57 -0500 (EST) In-Reply-To: from "Vlad Harchev " at Mar 29, 99 11:46:42 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 578 Lines: 25 > > On Mon, 29 Mar 1999, Vlad Harchev wrote: > > > Here is a corrected patch that adds html source colorization to any screen. > > Description is slightly corrected: > >[ ... ] > Here is a changelog entry I've missed: > * Fixed the bug in lynx with lss support -when displaying html pieces like > A B C , only 'AB' was drawn in style corresponding to . thanks > > PS: This patch is of course to dev21. yes - that was my impression. > Best regards, > -Vlad -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Apr 1 16:10:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA03684 for ; Thu, 1 Apr 1999 16:10:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA29978; Thu, 1 Apr 1999 15:01:05 -0600 (CST) Date: Thu, 1 Apr 1999 16:00:44 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Request for vote - Fwd: Re: Free GNU/OSS Hosting Message-ID: <19990401160044.A13104@mail.bcpl.net> References: <19990401131722.A27681@mema.ucl.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990401131722.A27681@mema.ucl.ac.be>; from Serge Munhoven on Thu, Apr 01, 1999 at 01:17:22PM +0200 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 967 Lines: 27 On Thu, Apr 01, 1999 at 01:17:22PM +0200, Serge Munhoven wrote: > Dear All > > Though I understand from today's messages on the list that things are also > moving on Jim's side, I've got the following on mine (after seeing all those > starving mirrors :-) (See http://www.linuxbox.com/gnu.html as well as my mail > cited by Chris Gann below for details) > > Any comments ? > > - Serge > > PS: To put it clearly, there was no intention to compete with Jim [snipola] I will have the primary Lynx FTP site running and announced next week. After that, we will publish the list of mirror sites as they are set up. Believe me, the Lynx community will benefit greatly from the site we have been given. ------ Marvin the Paranoid Android says: The dew has clearly fallen with a particularly sickening thud this morning. From owner-lynx-dev@sig.net Thu Apr 1 16:11:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA03715 for ; Thu, 1 Apr 1999 16:11:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA29360; Thu, 1 Apr 1999 14:59:25 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Fri, 2 Apr 1999 00:55:17 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev USE_COLOR_STYLE, PDCurces 2.3 and DJGPP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3549 Lines: 123 This is my story of building DJGPP lynx with -lss support, mostly for Tom and Doug (and maybe Wayne Buttles if he occasionally look here): Know nothing about color curces etc. I check PDCurces 2.3 (from Wayne Buttles site) and yes, the header file define "chtype" as long (not short int) so I guess it may work with more colors. First I read INSTALLATION: --enable-color-style (define USE_COLOR_STYLE) Use this option to enable optional and *experimental* color style. (Also defines USE_HASH, LINKEDSTYLES) so define USE_COLOR_STYLES and USE_HASH (btw, why should we define both? does we may use these options separately?) Now I build and found out the problem in LYCurces.c/start_curses(): few lines appears not ifdefed properly: diff -u old/lycurses.c ./lycurses.c --- old/lycurses.c Thu Mar 18 11:05:48 1999 +++ ./lycurses.c Tue Mar 30 21:24:02 1999 @@ -621,8 +621,10 @@ lynx_has_color = TRUE; start_color(); } +#if USE_COLOR_TABLE lynx_init_colors(); lynx_called_initscr = TRUE; +#endif /* USE_COLOR_TABLE */ /* Inform pdcurses that we're interested in knowing when mouse buttons * are clicked. Maybe someday pdcurses will support it. Using the above fix I build lynx successefully, but occasionally without colors at all: something was not initialized, probably parse_userstyles(). Looking more closely, it turns out there are two version of start_curces(): one for DJGPP and for others. Now I remove the entire DJGPP variant and was trying with generic start_curces() for DJGPP platform - seems no visible difference (probably screen gets redraw faster when returning from system() calls), both with/without USE_COLOR_STYLE. What was the original problem? see my patch below. Now I could start lynx -lss=... with lss files from the sample directory and got new color impressions. (Not sure I get more colors but certainly different. Nothing is colored in a source mode - should it?). diff -u old/lycurses.c ./lycurses.c --- old/lycurses.c Thu Mar 18 11:05:48 1999 +++ ./lycurses.c Fri Apr 2 00:00:26 1999 @@ -600,44 +600,7 @@ } #endif /* USE_COLOR_TABLE */ -#if defined (DJGPP) && !defined (USE_SLANG) -/* - * Sorry about making a completely new function, - * but the real one is messy! WB - */ -PUBLIC void start_curses NOARGS -{ - static BOOLEAN first_time = TRUE; - - if(first_time) - { - initscr(); /* start curses */ - first_time = FALSE; - cbreak(); - keypad(stdscr, TRUE); - fflush(stdin); - fflush(stdout); - if (has_colors()) { - lynx_has_color = TRUE; - start_color(); - } - lynx_init_colors(); - lynx_called_initscr = TRUE; - - /* Inform pdcurses that we're interested in knowing when mouse buttons - * are clicked. Maybe someday pdcurses will support it. - */ - if (LYUseMouse) - lynx_enable_mouse (1); - - } else - sock_init(); - LYCursesON = TRUE; - clear(); - noecho(); -} -#else PUBLIC void start_curses NOARGS { #ifdef USE_SLANG @@ -805,6 +768,10 @@ lynx_called_initscr = TRUE; #endif /* USE_COLOR_TABLE */ } +#ifdef __DJGPP__ + else sock_init(); +#endif /* __DJGPP__ */ + #endif /* VMS */ /* nonl(); */ /* seems to slow things down */ @@ -840,7 +807,7 @@ LYCursesON = TRUE; } -#endif /* defined (DJGPP) && !defined (USE_SLANG) */ + PUBLIC void lynx_enable_mouse ARGS1(int,state) { From owner-lynx-dev@sig.net Thu Apr 1 17:56:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA07293 for ; Thu, 1 Apr 1999 17:56:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA06913; Thu, 1 Apr 1999 16:40:22 -0600 (CST) Date: Thu, 1 Apr 1999 17:29:00 -0500 (EST) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev [PATCH][dev21] Remove cut-n-paste code in www_user_search Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 13665 Lines: 417 * Spawn a new function, www_user_search_internals, to begin cancelling the effects of cut-n-paste coding in www_user_search. The body of www_user_search_internals used to be duplicated at two points in www_user_search. See comment in GridText.c for more details. (John Bley) Doing this actually cuts the size of the binary by a KB without modifying behaviour at all (unless I screwed up somewhere). It's kind of a toss-up as to whether it actually makes the code "cleaner" though... -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall diff -Burp lynx2-8-2/WWW/Library/Implementation/HTAssoc.c lynx2-8-2-patched/WWW/Library/Implementation/HTAssoc.c --- lynx2-8-2/WWW/Library/Implementation/HTAssoc.c Thu Aug 6 08:28:22 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTAssoc.c Wed Mar 31 23:45:02 1999 @@ -20,7 +20,6 @@ #include #include -#include #include diff -Burp lynx2-8-2/src/GridText.c lynx2-8-2-patched/src/GridText.c --- lynx2-8-2/src/GridText.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/GridText.c Thu Apr 1 00:42:44 1999 @@ -5738,40 +5738,39 @@ PRIVATE void adjust_search_result ARGS3( } } -PUBLIC void www_user_search ARGS3( +/* + John Bley, April 1, 1999 (No joke) + www_user_search_internals was spawned from www_user_search to + remove a cut-n-paste coding hack: basically, this entire function + was duplicated at the two points that www_user_search now calls it. + And, because www_user_search has a return value defined as modification + of the screen and some global values, and since it used an awkward for(;;) + construct, this method has to distinguish between when it's "really" + returning and when it's just falling through via a break; in the + infinite-for-loop. So, basically, we have a large amount of arguments + since this loop used to be directly in www_user_search, and we return + 1 to say we're "really" returning and 0 to indicate we fell through. + Also, due to exactly one difference between the first pass of this + code and the second pass, we have the "firstpass" argument, which is + true iff it's the first pass. + + I hate cut-n-paste coding. + */ +PRIVATE int www_user_search_internals ARGS8( + int, firstpass, int, start_line, document *, doc, - char *, target) + char *, target, + TextAnchor *, a, + HTLine *, line, + int *, count, + int *, tentative_result) { - register HTLine * line; - register int count; - int tentative_result = -1; - TextAnchor *a; - OptionType *option; + OptionType * option; char *stars = NULL, *cp; - if (!HTMainText) { - return; - } - - /* - * Advance to the start line. - */ - line = HTMainText->last_line->next; - for (count = 1; count <= start_line; line = line->next, count++) { - if (line == HTMainText->last_line) { - line = HTMainText->last_line->next; /* set to first line */ - count = 1; - break; - } - } - a = HTMainText->first_anchor; - while (a && a->line_num < count - 1) { - a = a->next; - } - for (;;) { - while ((a != NULL) && a->line_num == (count - 1)) { + while ((a != NULL) && a->line_num == (*count - 1)) { if (a->show_anchor && (a->link_type != INPUT_ANCHOR || a->input_field->type != F_HIDDEN_TYPE)) { @@ -5779,15 +5778,15 @@ PUBLIC void www_user_search ARGS3( LYno_attr_char_strstr(a->hightext, target)) || ((a->hightext != NULL && case_sensitive == FALSE) && LYno_attr_char_case_strstr(a->hightext, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } if (((a->hightext2 != NULL && case_sensitive == TRUE) && LYno_attr_char_strstr(a->hightext2, target)) || ((a->hightext2 != NULL && case_sensitive == FALSE) && LYno_attr_char_case_strstr(a->hightext2, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } /* @@ -5807,8 +5806,8 @@ PUBLIC void www_user_search ARGS3( ((case_sensitive == FALSE) && LYno_attr_char_case_strstr(a->input_field->value, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } StrAllocCopy(stars, a->input_field->value); for (cp = stars; *cp != '\0'; cp++) @@ -5818,8 +5817,8 @@ PUBLIC void www_user_search ARGS3( ((case_sensitive == FALSE) && LYno_attr_char_case_strstr(stars, target))) { FREE(stars); - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } FREE(stars); } else if (a->input_field->type == F_OPTION_LIST_TYPE) { @@ -5837,8 +5836,8 @@ PUBLIC void www_user_search ARGS3( case_sensitive == FALSE) && LYno_attr_char_case_strstr(option->name, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } option = option->next; } @@ -5855,8 +5854,8 @@ PUBLIC void www_user_search ARGS3( LYno_attr_char_strstr(cp, target)) || ((case_sensitive == FALSE) && LYno_attr_char_case_strstr(cp, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } } else if (a->input_field->type == F_CHECKBOX_TYPE) { /* @@ -5872,8 +5871,8 @@ PUBLIC void www_user_search ARGS3( LYno_attr_char_strstr(cp, target)) || ((case_sensitive == FALSE) && LYno_attr_char_case_strstr(cp, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } } else { /* @@ -5888,191 +5887,89 @@ PUBLIC void www_user_search ARGS3( ((case_sensitive == FALSE) && LYno_attr_char_case_strstr(a->input_field->value, target))) { - adjust_search_result(doc, count, start_line); - return; + adjust_search_result(doc, *count, start_line); + return 1; } } } } a = a->next; } - if (a != NULL && a->line_num <= (count - 1)) { + if (a != NULL && a->line_num <= (*count - 1)) { a = a->next; } if (case_sensitive && LYno_attr_char_strstr(line->data, target)) { - tentative_result = count; + *tentative_result = *count; break; } else if (!case_sensitive && LYno_attr_char_case_strstr(line->data, target)) { - tentative_result = count; + *tentative_result = *count; break; - } else if (line == HTMainText->last_line) { /* next line */ + /* Note: this is where the two passes differ */ + } else if (firstpass && line == HTMainText->last_line) { + /* next line */ break; + } else if (!firstpass && *count > start_line) { + HTUserMsg2(STRING_NOT_FOUND, target); + return 1; /* end */ } else { /* end */ line = line->next; - count++; + (*count)++; } } - if (tentative_result > 0) { - adjust_search_result(doc, tentative_result, start_line); + /* No, man, we just fell through. You want to call us again. */ + return 0; +} + +PUBLIC void www_user_search ARGS3( + int, start_line, + document *, doc, + char *, target) +{ + HTLine * line; + int count; + int tentative_result = -1; + TextAnchor *a; + + if (!HTMainText) { return; } /* - * Search from the beginning. + * Advance to the start line. */ + line = HTMainText->last_line->next; + for (count = 1; count <= start_line; line = line->next, count++) { + if (line == HTMainText->last_line) { + line = HTMainText->last_line->next; /* set to first line */ + count = 1; + break; + } + } + a = HTMainText->first_anchor; + while (a && a->line_num < count - 1) { + a = a->next; + } + if (www_user_search_internals(1, start_line, doc, target, + a, line, &count, &tentative_result) == 1) { + return; /* Return the www_user_search_internals result */ + } + + if (tentative_result > 0) { + adjust_search_result(doc, tentative_result, start_line); + return; + } + /* That didn't work, search from the beginning instead */ line = HTMainText->last_line->next; /* set to first line */ count = 1; a = HTMainText->first_anchor; while (a && a->line_num < count - 1) { a = a->next; } - - for (;;) { - while ((a != NULL) && a->line_num == (count - 1)) { - if (a->show_anchor && - (a->link_type != INPUT_ANCHOR || - a->input_field->type != F_HIDDEN_TYPE)) { - if (((a->hightext != NULL && case_sensitive == TRUE) && - LYno_attr_char_strstr(a->hightext, target)) || - ((a->hightext != NULL && case_sensitive == FALSE) && - LYno_attr_char_case_strstr(a->hightext, target))) { - adjust_search_result(doc, count, start_line); - return; - } - if (((a->hightext2 != NULL && case_sensitive == TRUE) && - LYno_attr_char_strstr(a->hightext2, target)) || - ((a->hightext2 != NULL && case_sensitive == FALSE) && - LYno_attr_char_case_strstr(a->hightext2, target))) { - adjust_search_result(doc, count, start_line); - return; - } - - /* - * Search the relevant form fields, taking the - * case_sensitive setting into account. - FM - */ - if ((a->input_field != NULL && a->input_field->value != NULL) && - a->input_field->type != F_HIDDEN_TYPE) { - if (a->input_field->type == F_PASSWORD_TYPE) { - /* - * Check the actual, hidden password, and then - * the displayed string. - FM - */ - if (((case_sensitive == TRUE) && - LYno_attr_char_strstr(a->input_field->value, - target)) || - ((case_sensitive == FALSE) && - LYno_attr_char_case_strstr(a->input_field->value, - target))) { - adjust_search_result(doc, count, start_line); - return; - } - StrAllocCopy(stars, a->input_field->value); - for (cp = stars; *cp != '\0'; cp++) - *cp = '*'; - if (((case_sensitive == TRUE) && - LYno_attr_char_strstr(stars, target)) || - ((case_sensitive == FALSE) && - LYno_attr_char_case_strstr(stars, target))) { - FREE(stars); - adjust_search_result(doc, count, start_line); - return; - } - FREE(stars); - } else if (a->input_field->type == F_OPTION_LIST_TYPE) { - /* - * Search the option strings that are displayed - * when the popup is invoked. - FM - */ - option = a->input_field->select_list; - while (option != NULL) { - if (((option->name != NULL && - case_sensitive == TRUE) && - LYno_attr_char_strstr(option->name, - target)) || - ((option->name != NULL && - case_sensitive == FALSE) && - LYno_attr_char_case_strstr(option->name, - target))) { - adjust_search_result(doc, count, start_line); - return; - } - option = option->next; - } - } else if (a->input_field->type == F_RADIO_TYPE) { - /* - * Search for checked or unchecked parens. - FM - */ - if (a->input_field->num_value) { - cp = checked_radio; - } else { - cp = unchecked_radio; - } - if (((case_sensitive == TRUE) && - LYno_attr_char_strstr(cp, target)) || - ((case_sensitive == FALSE) && - LYno_attr_char_case_strstr(cp, target))) { - adjust_search_result(doc, count, start_line); - return; - } - } else if (a->input_field->type == F_CHECKBOX_TYPE) { - /* - * Search for checked or unchecked - * square brackets. - FM - */ - if (a->input_field->num_value) { - cp = checked_box; - } else { - cp = unchecked_box; - } - if (((case_sensitive == TRUE) && - LYno_attr_char_strstr(cp, target)) || - ((case_sensitive == FALSE) && - LYno_attr_char_case_strstr(cp, target))) { - adjust_search_result(doc, count, start_line); - return; - } - } else { - /* - * Check the values intended for display. - * May have been found already via the - * hightext search, but make sure here - * that the entire value is searched. - FM - */ - if (((case_sensitive == TRUE) && - LYno_attr_char_strstr(a->input_field->value, - target)) || - ((case_sensitive == FALSE) && - LYno_attr_char_case_strstr(a->input_field->value, - target))) { - adjust_search_result(doc, count, start_line); - return; - } - } - } - } - a = a->next; - } - if (a != NULL && a->line_num <= (count - 1)) { - a = a->next; - } - - if (case_sensitive && LYno_attr_char_strstr(line->data, target)) { - tentative_result = count; - break; - } else if (!case_sensitive && - LYno_attr_char_case_strstr(line->data, target)) { - tentative_result = count; - break; - } else if (count > start_line) { /* next line */ - HTUserMsg2(STRING_NOT_FOUND, target); - return; /* end */ - } else { - line = line->next; - count++; - } + if (www_user_search_internals(0, start_line, doc, target, + a, line, &count, &tentative_result) == 1) { + return; /* Return the www_user_search_internals result */ } if (tentative_result > 0) { adjust_search_result(doc, tentative_result, start_line); From owner-lynx-dev@sig.net Thu Apr 1 18:52:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA09213 for ; Thu, 1 Apr 1999 18:52:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA27410; Thu, 1 Apr 1999 17:45:11 -0600 (CST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Message-ID: <37039B87.C76285C5@vlsi.com> Date: Thu, 01 Apr 1999 08:15:03 -0800 From: Sang Kim X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev dumping web pages References: <3702C5DD.4396DA2E@vlsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 261 Lines: 7 Is there any way to dump pages which is protected by password? I used to use -dump -auth=id:passwd option. But server changed its setup to html based login instead of pop up login. Any help or insight is greatly appreciated. -- Sang Kim Sang.Kim@vlsi.com From owner-lynx-dev@sig.net Thu Apr 1 18:52:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA09220 for ; Thu, 1 Apr 1999 18:52:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA27247; Thu, 1 Apr 1999 17:44:39 -0600 (CST) Date: Thu, 1 Apr 1999 18:42:00 +0100 (BST) From: Ian Hickson To: lynx-dev@sig.net cc: connolly@w3.org Subject: lynx-dev HTTP 'Link' Header Message-ID: X-Home-Page: http://www.bath.ac.uk/%7Epy8ieh/ Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1495 Lines: 47 Hi. We are writing an Internet Draft [1] for RFC2068 [2]'s LINK header [3], which was removed from the IETF's HTTP Internet Draft [4] due to lack of client-side support. NGLayout (aka, Netscape 5) [5] now supports this HTTP header completely, but we need another implementation for this Internet Draft to be considered. Since Lynx already supports the LINK HTML element, and since the Link HTTP header maps straight onto the LINK HTML element, would you consider implementing the HTTP 'Link' Header in your next release? The 'Link' header has the following format: Link: ; rel=relationship; rev=relationship; title=quoted-string; etc... With the possibility of concatenating links on a single header. See the draft specification for a formal definition [1]. To map this onto the LINK HTML element, you need to take and use it for the value of the HREF attribute, and then take each recognised attribute from the HTTP header and use its value for the value of that attribute in the LINK element. Should you wish to implement this feature, some test pages are already available. [6] We thank you in advance for considering this. -- References -- [1] http://www.w3.org/Protocols/9707-link-header [2] http://www.w3.org/Protocols/rfc2068/rfc2068 [3] Section 19.6.2.4 of [2] [4] ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt [5] http://www.mozilla.org/ [6] http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link6.html -- Dan Connolly Ian Hickson From owner-lynx-dev@sig.net Thu Apr 1 19:53:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA11308 for ; Thu, 1 Apr 1999 19:53:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA12104; Thu, 1 Apr 1999 18:44:39 -0600 (CST) From: Philip Webb Message-Id: <199904020044.TAA08560@chass.utoronto.ca> Subject: Re: lynx-dev [PATCH][dev21] Remove cut-n-paste code in www_user_search To: lynx-dev@sig.net Date: Thu, 1 Apr 1999 19:44:35 -0500 (EST) In-Reply-To: from "John Bley" at Apr 1, 99 05:29:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1220 Lines: 21 990401 John Bley wrote: > * Spawn a new function, www_user_search_internals, to begin cancelling > the effects of cut-n-paste coding in www_user_search. The body of > www_user_search_internals used to be duplicated at two points in > www_user_search. See comment in GridText.c for more details. (John Bley) > Doing this actually cuts the size of the binary by a KB without modifying > behaviour at all (unless I screwed up somewhere). It's kind of a > toss-up as to whether it actually makes the code "cleaner" though... even my small perusal of Lynx source revealed a couple of places where one piece of code had apparently been copied to another place aswas; duplication like that surely makes a program more difficult to maintain. this kind of thing probably reflects the rapid expansion of Lynx during early development days, which no-one has ever tidied up. we should always remember how hard the early developers worked at it. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 1 21:31:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA14941 for ; Thu, 1 Apr 1999 21:31:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA03048; Thu, 1 Apr 1999 20:24:11 -0600 (CST) Date: Thu, 1 Apr 1999 18:23:58 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Cc: delo@rub45.vicom.ru Subject: Re: lynx-dev Re: lynx- Can't access Startfile ... In-Reply-To: <199903310802.JAA04596@djwhome.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 899 Lines: 29 On Wed, 31 Mar 1999, David Woolley wrote: > However, in spite of the unnecessary, uuencoding of the attachment, > I managed to recover this line: > > gateway=0.0.0.0 > > which should be the default gateway address for your ISP. This should be set using the IP-UP.BAT file created by DOSPPP. If manually configuring, the correct settings should be in the file. Automatic configuration can be done, as in the LYNXBAT.BAT file included in the DOS lynx distribution from my web and ftp sites. > These must be configured for using mail (I don't consider mailaddr optional). > > #mailserver=my.mail.server > #mailaddr=me@my.mail.address Which mail program uses these settings? They aren't used by the SENDMAIL.EXE file written for the DOS port of lynx by Alfredo Cole. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Thu Apr 1 22:01:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA15710 for ; Thu, 1 Apr 1999 22:01:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA09256; Thu, 1 Apr 1999 20:53:31 -0600 (CST) Date: Thu, 1 Apr 1999 20:53:26 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: Sang.Kim@vlsi.com Subject: Re: lynx-dev dumping web pages In-Reply-To: <37039B87.C76285C5@vlsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 665 Lines: 17 On Thu, 1 Apr 1999, Sang Kim wrote: > Is there any way to dump pages which is protected by password? > I used to use -dump -auth=id:passwd option. But server changed > its setup to html based login instead of pop up login. > Any help or insight is greatly appreciated. What is "html based login"? Without a concrete example (URL) it's impossible to answer yes or no. Your best bet is to manually do the login, then see the '=' info page, see whether the login info is somehoe embedded in the URL (or post data). If yes, you may be able to reproduce this from the command line. If no, you need to use TRACE (or lynx -trace) to see what's going on. Klaus From owner-lynx-dev@sig.net Thu Apr 1 22:05:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA15992 for ; Thu, 1 Apr 1999 22:05:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10544; Thu, 1 Apr 1999 20:58:55 -0600 (CST) Date: Thu, 1 Apr 1999 18:58:47 -0800 From: Michael Warner To: lynx-dev@sig.net Subject: Re: STARTFILE bug? [lynx-dev] Message-ID: <19990401185846.A12367@unicorn.it.wsu.edu> Mail-Followup-To: lynx-dev@sig.net References: <199904011830.NAA18851@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904011830.NAA18851@chass.utoronto.ca>; from Philip Webb on Thu, Apr 01, 1999 at 01:30:34PM -0500 X-Note-To-Self: Add The [lynx-dev]!?!? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 547 Lines: 17 On or about 01 Apr, 1999, Philip Webb wrote: [...] > so i tried changing the latter to (eg) > STARTFILE:file://localhost/homes/purslow/lynx , > which should give me an easily recognisable directory of news stories: > entering lynx file://localhost/homes/purslow/lynx works ok. I tried this out on dev15 and got the same results, until I figured out that I had a 'WWW_HOME' entry in my environment. Did you check for that? -- Michael Warner "You're cute when you're stupid" -- R.A. Miller From owner-lynx-dev@sig.net Fri Apr 2 00:18:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA19293 for ; Fri, 2 Apr 1999 00:18:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA07550; Thu, 1 Apr 1999 23:11:18 -0600 (CST) Date: Fri, 2 Apr 1999 00:06:19 -0500 (EST) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev HTTP 'Link' Header In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 731 Lines: 17 On Thu, 1 Apr 1999, Ian Hickson wrote: > Since Lynx already supports the LINK HTML element, and since the Link HTTP > header maps straight onto the LINK HTML element, would you consider > implementing the HTTP 'Link' Header in your next release? If anybody decides to tackle this (I don't know enough about lynx's document structure to attempt it at this point): in HTMIME.c, around line 1512, there's already a switch case set up to handle "Link:" headers. It doesn't do anything, but it looks like a good place to start. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Fri Apr 2 02:01:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA21933 for ; Fri, 2 Apr 1999 02:01:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA20524; Fri, 2 Apr 1999 00:48:50 -0600 (CST) From: David Woolley Message-Id: <199904012334.AAA01286@djwhome.demon.co.uk> Subject: Re: lynx-dev dumping web pages To: lynx-dev@sig.net Date: Fri, 2 Apr 1999 00:34:32 +0100 (BST) In-Reply-To: <3702C5DD.4396DA2E@vlsi.com> from "Sang Kim" at Mar 31, 99 05:03:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1347 Lines: 32 > > Is there any way to dump pages which is protected by password? > I used to use -dump -auth=id:passwd option. But server changed > its setup to html based login instead of pop up login. That's no login at all in protocol terms. The page is being protected by an ad hoc mechanism that may change at any time. This may be security by obscurity, in which case simply quote the URL that you get after the login. It may be persistent cookie based, although I wouldn't expect a login prompt at all, and recent Lynxes should work if you accept the cookies. It may be session cookie based, in which case you have problems, as Lynx will lose the cookie between invocations. It may be obscurity, but backed by a referer check, in which case you will have to hack the code to fake an on-site referer. It may be done with hidden fields on forms. These will be visible for GET mode forms, but you will have to extract them from a response and use postdata. It may use a short lived session identity coded in URLs or hidden fields, in which case you will have to capture this information within the lifetime of the session. In all cases, it probably doesn't give them added security over using the built-in mechanisms, just allows them control of the appearance of the login dialogue - i.e. it is the normal interactive GUI only mode of thinking. From owner-lynx-dev@sig.net Fri Apr 2 10:05:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA26208 for ; Fri, 2 Apr 1999 10:05:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA14425; Fri, 2 Apr 1999 08:55:55 -0600 (CST) Date: Fri, 2 Apr 1999 09:55:30 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Lynx FTP site test (was: lynx-dev Request for vote...) Message-ID: <19990402095530.A2307@mail.bcpl.net> References: <19990401131722.A27681@mema.ucl.ac.be> <19990401160044.A13104@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990401160044.A13104@mail.bcpl.net>; from Webmaster Jim on Thu, Apr 01, 1999 at 04:00:44PM -0500 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1519 Lines: 36 On Thu, Apr 01, 1999 at 04:00:44PM -0500, Webmaster Jim wrote: > On Thu, Apr 01, 1999 at 01:17:22PM +0200, Serge Munhoven wrote: > > Though I understand from today's messages on the list that things are also > > moving on Jim's side, I've got the following on mine (after seeing all those > > starving mirrors :-) > [more snipola] > I will have the primary Lynx FTP site running and announced next week. > After that, we will publish the list of mirror sites as they are set up. > Believe me, the Lynx community will benefit greatly from the site we > have been given. The directory layout and automated mirroring is not yet ready, but Lynx users who have the chance this weekend can help test the FTP site for Lynx distribution. The directory for the current distribution will be: ftp://lynx.isc.org/current/ This has been aliased by Rob Partington to also be: ftp://ftp.us.browser.org/current/. Our intent is to add "official" mirrors around the globe that will be aliased with the same pattern. My test this morning showed a file transfer rate to BCPL peaking at 25KB/second using Lynx to transfer lynx-cur.zip. If someone can test FTP restart, that would be good. We thank Paul Vixie and the Internet Software Consortium for providing the FTP service for Lynx development. Cheers! ------ Marvin the Paranoid Android says: You'll have a really miserable time. From owner-lynx-dev@sig.net Fri Apr 2 10:09:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA26281 for ; Fri, 2 Apr 1999 10:09:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA15895; Fri, 2 Apr 1999 09:01:12 -0600 (CST) Date: Fri, 2 Apr 1999 13:05:08 +0200 From: Martin Schulze To: Lynx Development Cc: 3846-forwarded@bugs.debian.org, debian-qa@lists.debian.org Subject: lynx-dev Re: The old lynx bug (was: Re: Bugs older than two years) Message-ID: <19990402130508.B8158@finlandia.artis.uni-oldenburg.de> References: <19990331001442.H26835@azure.humbug.org.au> <19990330211903.M2797@ugh.jyu.fi.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990330211903.M2797@ugh.jyu.fi.invalid>; from Antti-Juhani Kaijanaho on Tue, Mar 30, 1999 at 09:19:03PM +0300 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2889 Lines: 121 Dear Lynx developers, we have received the follwoing report through the bug tracking system of Debian at http://www.debian.org/Bugs/. The bug is against version 2.4-FM-960316-1 but still present. The entire report can be viewed at http://www.infodrom.north.de/Debian/Bugs/db/38/3846.html Caveat: The URL as given in the bug report is not available anymore. Please keep 3846@bugs.debian.org in your replies in order to record it in that bug tracking system. There is a bug in the parsing produced by lynx, as shown below. The line marked >>>>> should not appear. (Interestingly Mosaic 2.7b4 and Netscape 2.01 each have a bug here too, but their bugs are different from lynx's even though they're the same as each other's (-:.) Ian. > chiark:~> lynx -dump http://chiark.chu.cam.ac.uk/~ijackson/test-deflist.html > > test > > keyword1 >>>>> > keyword2 > paragraph > > second paragraph > > keyphrase for third para > third paragraph > > test with compact > > keyword1 > keyword2 > paragraph > > second paragraph > keyphrase for third para > third paragraph > chiark:~> Test of definition lists

test

keyword1
keyword2
paragraph

second paragraph

keyphrase for third para
third paragraph

test with compact

keyword1
keyword2
paragraph

second paragraph

keyphrase for third para
third paragraph
Antti-Juhani Kaijanaho wrote: > On Wed, Mar 31, 1999 at 12:14:42AM +1000, Anthony Towns wrote: > > Package: lynx > > Maintainer: Christian Hudon > > 3846 lynx misdisplays multiple
in
> > [HELP] Is this really a bug? > > RFC 1866 (HTML 2.0) says: > > The content of a
element is a sequence of
elements and/or >
elements, usually in pairs. Multiple
may be paired with a > single
element. Documents should not contain multiple > consecutive
elements. > > [...] > > Unless the COMPACT attribute is present, an HTML user agent may leave > white space between successive DT, DD pairs. The COMPACT attribute > may also reduce the width of the left-hand (DT) column. > > Thus, it looks like a bug, since (by natural implication) space may be > left only between successive DT DD pairs, and multiple DT's are allowed > for a DD. The newer HTML specifications do not address this. > > This should be forwarded upstream. Which I've done now. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists. From owner-lynx-dev@sig.net Fri Apr 2 10:22:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA31697 for ; Fri, 2 Apr 1999 10:22:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA19777; Fri, 2 Apr 1999 09:14:38 -0600 (CST) From: Philip Webb Message-Id: <199904021514.KAA11615@chass.utoronto.ca> Subject: Re: STARTFILE bug? [lynx-dev] To: lynx-dev@sig.net Date: Fri, 2 Apr 1999 10:14:33 -0500 (EST) In-Reply-To: <19990401185846.A12367@unicorn.it.wsu.edu> from "Michael Warner" at Apr 1, 99 06:58:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1929 Lines: 39 990401 Michael Warner advised: > 01 Apr, 1999, Philip Webb wrote: >> i tried changing lynx.cfg to >> STARTFILE:file://localhost/homes/purslow/lynx , >> which should give me an easily recognisable directory of news stories >> -- entering lynx file://localhost/homes/purslow/lynx works ok -- , >> but Lynx didn't recognise it. > I tried this out on dev15 and got the same results, > until I figured I had a 'WWW_HOME' entry in my environment. yes, that makes a difference, but not the one it should: .login was doing WWW_HOME http://www.chass.utoronto.ca , something left from an earlier time when i was using the system Lynx. however, i then ran into 2 further problems: (1) having changed .login by commenting out that line & restarting, WWW_HOME remained set to http://www.chass.utoronto.ca as before: is there anywhere else it might be being set? (2) having manually done setenv WWW_HOME (ie blanked it out), Lynx 2-8-2dev.19 refuses to start, giving the message: lynx: Start file could not be found or is not text/html or text/plain , tho' there is a properly defined start file in lynx.cfg ; after manually doing setenv WWW_HOME "." , Lynx started with the correct current directory listing. it would appear that Lynx 2-8-2dev.19 won't start without a start file specified with WWW_HOME , at least on this IRIX 5.3 using csh . i wanted simply to make a small change in the lynx.cfg default, so that ordinary users out there always find a local start file, if something different hasn't been specified elsewhere for/by them, but i seem to have uncovered a bug as well, as often ... (smile). anyone have any further suggestions? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 2 10:52:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA04841 for ; Fri, 2 Apr 1999 10:52:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA25395; Fri, 2 Apr 1999 09:33:45 -0600 (CST) Message-Id: <4.1.19990402103435.00e485c0@pop.ma.ultranet.com> X-Sender: gregmm@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 02 Apr 1999 10:36:55 -0500 To: lynx-dev@sig.net From: Greg Marr Subject: Re: STARTFILE bug? [lynx-dev] In-Reply-To: <199904021514.KAA11615@chass.utoronto.ca> References: <19990401185846.A12367@unicorn.it.wsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 814 Lines: 24 Philip Webb wrote: >however, i then ran into 2 further problems: >(1) having changed .login by commenting out that line & restarting, > WWW_HOME remained set to http://www.chass.utoronto.ca as before: >is there anywhere else it might be being set? Since you're using csh, probably in .cshrc or there is a system setting. (I don't remember the exact location of the file, but it is called global.cshrc I think. The location should be listed in the csh man page.) >(2) having manually done setenv WWW_HOME (ie blanked it out), The correct way to do this is unsetenv WWW_HOME. There is a difference between an environment variable not existing, and it existing with a null value. -- Greg Marr gregm@alum.wpi.edu "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning" From owner-lynx-dev@sig.net Fri Apr 2 10:54:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA05033 for ; Fri, 2 Apr 1999 10:54:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29477; Fri, 2 Apr 1999 09:46:36 -0600 (CST) Date: Fri, 2 Apr 1999 07:46:30 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: RYA Cc: lynx-dev@sig.net Subject: lynx-dev Re: Problem with PPPD for Dos (0.6 beta) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 951 Lines: 21 On Fri, 2 Apr 1999, RYA wrote (to me instead of the list): > I set gateway to 255.255.255.255 - no effect = ping.exe doesn't > work.I set netmask to 255.255.255.255 as well - no effect. To get lynx to work in DOS, you must have the correct settings in your WATTCP.CFG file. When you run EPPPD.EXE from the DOSPPP package, it creates a file when it connects called IP-UP.BAT. Look at this file. It has settings for "myip" "remip" and "netmask". These need to be transferred to your WATTCP.CFG file before you try to run lynx. The value for "myip" goes in the WATTCP.CFG as "my_ip". The value for "remip" goes in as "gateway". The value for "netmask" goes in as "netmask". The values for gateway and netmask will not generally change for your ISP, but the value for "my_ip" may be different every time that you connect. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Apr 2 11:03:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA05126 for ; Fri, 2 Apr 1999 11:03:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA01311; Fri, 2 Apr 1999 09:52:19 -0600 (CST) Date: Fri, 2 Apr 1999 07:52:14 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: STARTFILE bug? [lynx-dev] In-Reply-To: <199904021514.KAA11615@chass.utoronto.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 372 Lines: 13 On Fri, 2 Apr 1999, Philip Webb wrote: > (2) having manually done setenv WWW_HOME (ie blanked it out), > Lynx 2-8-2dev.19 refuses to start, giving the message: This doesn't remove WWW_HOME under csh or tcsh. You need to do "unsetenv WWW_HOME". Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Apr 2 11:03:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA05127 for ; Fri, 2 Apr 1999 11:03:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA01999; Fri, 2 Apr 1999 09:54:23 -0600 (CST) From: Philip Webb Message-Id: <199904021554.KAA13662@chass.utoronto.ca> Subject: Re: lynx-dev Re: The old lynx bug To: lynx-dev@sig.net Date: Fri, 2 Apr 1999 10:54:19 -0500 (EST) Cc: 3846@bugs.debian.org In-Reply-To: <19990402130508.B8158@finlandia.artis.uni-oldenburg.de> from "Martin Schulze" at Apr 2, 99 01:05:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1008 Lines: 22 990402 Martin Schultz outlined a "bug" in Lynx 2.4-FM-960316-1 , involving HTML 2.0 specs for definition lists: others among the international team of volunteers who maintain Lynx can offer more expert advice about HTML, but otherwise: first in practice, only the latest release/development versions are supported: you can get 2-8-1 from www.slcc.edu/lynx/release & 2-8-2dev.21 from sol.slcc.edu/lynx/current ; second, there is no mention of the requirement in HTML 4.0 (as you say), nor is it clear what the rather brief account in the RFC for 2.0 means, but it does seem at least better aesthetically not to insert a blank line between consecutive
's ; third, the described behaviour does indeed persist with 2-8-2dev.19 . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 2 13:14:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA08850 for ; Fri, 2 Apr 1999 13:14:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA13413; Fri, 2 Apr 1999 12:05:22 -0600 (CST) Date: Fri, 2 Apr 1999 13:04:20 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904021304.AA14333@cas.org> Subject: Re: lynx-dev Re: The old lynx bug In-Reply-To: <199904021554.KAA13662@chass.utoronto.ca> of Fri, 2 Apr 1999 10:54:19 -0500 (EST) To: lynx-dev@sig.net Cc: 3846@bugs.debian.org Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 417 Lines: 10 From: Philip Webb >third, the described behaviour does indeed persist with 2-8-2dev.19 . and in fact in 2-8-2dev.21 ... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Fri Apr 2 15:15:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA11907 for ; Fri, 2 Apr 1999 15:15:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA16243; Fri, 2 Apr 1999 14:07:50 -0600 (CST) From: Philip Webb Message-Id: <199904022007.PAA01708@chass.utoronto.ca> Subject: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Fri, 2 Apr 1999 15:07:46 -0500 (EST) In-Reply-To: <4.1.19990402103435.00e485c0@pop.ma.ultranet.com> from "Greg Marr" at Apr 2, 99 10:36:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3363 Lines: 75 990402 Greg Marr (with support from DK) wrote: > Philip Webb wrote: >> having changed .login by commenting out that line & restarting, >> WWW_HOME remained set to http://www.chass.utoronto.ca as before: >> is there anywhere else it might be being set? > Since you're using csh , probably in .cshrc or there is a system setting. > it is called global.cshrc I think. > The location should be listed in the csh man page. on this system, it's /etc/cshrc , which is described in the man pages. thanx both (smile): you learn a lot around lynx-dev ... >> having manually done setenv WWW_HOME (ie blanked it out), > The correct way to do this is unsetenv WWW_HOME . > There is a difference between an environment variable not existing > and it existing with a null value. well blow me down etc, yes that's true, tho' why on earth i don't know. so having sorted out those preliminaries, i have been able to tackle the original problem, which was to have a better default STARTFILE for ordinary users, who may find l.b.o. down for some reason. i hope the warning for anonymous sites is ok (Henry?): if lynx.cfg offers > 1 STARTFILE , Lynx uses the last one found, so this is failsafe, if the sysadmin forgets to comment out the regular line. *** old/lynx.cfg Fri Mar 5 14:47:43 1999 --- new/lynx.cfg Fri Apr 2 14:53:49 1999 *************** *** 33,47 **** # ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system #and now your own tweaks. # ! # STARTFILE is the default URL if none is specified on the command line ! # or via a WWW_HOME environment variable. ! # Note: these files can be remote (http://www.w3.org/default.html) ! # or local (file://localhost/PATH_TO/FILENAME ! # replace PATH_TO with the complete path to FILENAME ! # use Unix SHELL syntax and include the device on VMS systems) ! # ! STARTFILE:http://lynx.browser.org/ # HELPFILE must be defined as a URL and must have a # complete path if local: --- 33,54 ---- # ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system #and now your own tweaks. + # STARTFILE is the default starting URL if none is specified + # on the command line or via a WWW_HOME environment variable; + # Lynx will refuse to start without a starting URL of some kind. + # STARTFILE can be remote, e.g. http://www.w3.org/default.html , + # or local, e.g. file://localhost/PATH_TO/FILENAME , + # where PATH_TO is replaced with the complete path to FILENAME + # using Unix shell syntax and including the device on VMS. + # The default offered for ordinary users is their current directory: + STARTFILE:. # ! # *** NBB *** System administrators with ANONYMOUS USERS !!! ! # set STARTFILE to a REMOTE FILE by uncommenting the next line: ! #STARTFILE:http://lynx.browser.org/ ! # and commenting out the default offered above; ! # you may, of course, choose to replace `lynx.browser.org' ! # with another remote/local file which you know to be safe. # HELPFILE must be defined as a URL and must have a # complete path if local: -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 2 15:40:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA12614 for ; Fri, 2 Apr 1999 15:40:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA23424; Fri, 2 Apr 1999 14:33:43 -0600 (CST) Date: Fri, 2 Apr 1999 15:37:52 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Re: The old lynx bug (was: Re: Bugs older than two years) Message-ID: <19990402153752.A280@bcpl.net> References: <19990331001442.H26835@azure.humbug.org.au> <19990330211903.M2797@ugh.jyu.fi.invalid> <19990402130508.B8158@finlandia.artis.uni-oldenburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990402130508.B8158@finlandia.artis.uni-oldenburg.de>; from Martin Schulze on Fri, Apr 02, 1999 at 01:05:08PM +0200 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1898 Lines: 38 On Fri, Apr 02, 1999 at 01:05:08PM +0200, Martin Schulze wrote: > we have received the follwoing report through the bug tracking system > of Debian at http://www.debian.org/Bugs/. > The bug is against version 2.4-FM-960316-1 but still present. > The entire report can be viewed at http://www.infodrom.north.de/Debian/Bugs/db/38/3846.html > There is a bug in the parsing produced by lynx, as shown below. The > line marked >>>>> should not appear. > Antti-Juhani Kaijanaho wrote: > > On Wed, Mar 31, 1999 at 12:14:42AM +1000, Anthony Towns wrote: > > > Package: lynx > > > Maintainer: Christian Hudon > > > 3846 lynx misdisplays multiple
in
> > > [HELP] Is this really a bug? > > RFC 1866 (HTML 2.0) says: > > The content of a
element is a sequence of
elements and/or > >
elements, usually in pairs. Multiple
may be paired with a > > single
element. Documents should not contain multiple > > consecutive
elements. > > [...] > > Unless the COMPACT attribute is present, an HTML user agent may leave > > white space between successive DT, DD pairs. The COMPACT attribute > > may also reduce the width of the left-hand (DT) column. > > Thus, it looks like a bug, since (by natural implication) space may be > > left only between successive DT DD pairs, and multiple DT's are allowed > > for a DD. The newer HTML specifications do not address this. > > This should be forwarded upstream. > Which I've done now. [ above compacted ] It depends on how one views DT/DD "pairs". One view is that a DT without a following DD is an orphaned term, waiting for a definition. Another view is that they are really "paired" (although more than 2 seem allowed), and thus should be rendered together. Myself, I tend to closey couple terms and definitions... ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Fri Apr 2 15:59:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA13085 for ; Fri, 2 Apr 1999 15:59:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA28426; Fri, 2 Apr 1999 14:52:08 -0600 (CST) Date: Fri, 2 Apr 1999 15:45:43 -0500 (EST) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev [PATCH][dev21] remove big pile of useless #includes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6506 Lines: 206 * Big pile of unneeded #includes removed (John Bley) -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall diff -Burp lynx2-8-2/WWW/Library/Implementation/HTAssoc.c lynx2-8-2-patched/WWW/Library/Implementation/HTAssoc.c --- lynx2-8-2/WWW/Library/Implementation/HTAssoc.c Thu Aug 6 08:28:22 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTAssoc.c Fri Apr 2 15:08:36 1999 @@ -18,7 +18,6 @@ #include -#include #include #include diff -Burp lynx2-8-2/WWW/Library/Implementation/HTLex.c lynx2-8-2-patched/WWW/Library/Implementation/HTLex.c --- lynx2-8-2/WWW/Library/Implementation/HTLex.c Sat Dec 12 23:10:36 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTLex.c Fri Apr 2 15:08:49 1999 @@ -15,7 +15,6 @@ #include -#include #include /* Implemented here */ #include diff -Burp lynx2-8-2/src/GridText.c lynx2-8-2-patched/src/GridText.c --- lynx2-8-2/src/GridText.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/GridText.c Fri Apr 2 15:29:11 1999 @@ -28,8 +28,6 @@ #include #include #include -#include -#include #include #include #include diff -Burp lynx2-8-2/src/HTAlert.c lynx2-8-2-patched/src/HTAlert.c --- lynx2-8-2/src/HTAlert.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/HTAlert.c Fri Apr 2 15:28:52 1999 @@ -15,8 +15,6 @@ #include #include #include -#include -#include #include #include diff -Burp lynx2-8-2/src/HTInit.c lynx2-8-2-patched/src/HTInit.c --- lynx2-8-2/src/HTInit.c Mon Feb 8 05:32:59 1999 +++ lynx2-8-2-patched/src/HTInit.c Fri Apr 2 15:20:42 1999 @@ -24,7 +24,6 @@ #include #include #include -#include #include #include diff -Burp lynx2-8-2/src/HTML.c lynx2-8-2-patched/src/HTML.c --- lynx2-8-2/src/HTML.c Wed Mar 17 22:17:11 1999 +++ lynx2-8-2-patched/src/HTML.c Fri Apr 2 15:20:51 1999 @@ -39,7 +39,6 @@ #include #include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYBookmark.c lynx2-8-2-patched/src/LYBookmark.c --- lynx2-8-2/src/LYBookmark.c Thu Mar 4 05:39:45 1999 +++ lynx2-8-2-patched/src/LYBookmark.c Fri Apr 2 15:29:49 1999 @@ -4,8 +4,6 @@ #include #include #include -#include -#include #include #include /* need for META charset */ #include diff -Burp lynx2-8-2/src/LYCharSets.c lynx2-8-2-patched/src/LYCharSets.c --- lynx2-8-2/src/LYCharSets.c Wed Mar 17 22:17:11 1999 +++ lynx2-8-2-patched/src/LYCharSets.c Fri Apr 2 15:33:51 1999 @@ -12,7 +12,6 @@ #include #include -#include #include extern BOOL HTPassEightBitRaw; diff -Burp lynx2-8-2/src/LYDownload.c lynx2-8-2-patched/src/LYDownload.c --- lynx2-8-2/src/LYDownload.c Thu Jan 28 11:31:29 1999 +++ lynx2-8-2-patched/src/LYDownload.c Fri Apr 2 15:33:31 1999 @@ -5,12 +5,10 @@ #include #include #include -#include #include #include #include -#include #include /* diff -Burp lynx2-8-2/src/LYEdit.c lynx2-8-2-patched/src/LYEdit.c --- lynx2-8-2/src/LYEdit.c Thu Mar 4 05:39:45 1999 +++ lynx2-8-2-patched/src/LYEdit.c Fri Apr 2 15:28:43 1999 @@ -2,9 +2,7 @@ #include #include #include -#include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYForms.c lynx2-8-2-patched/src/LYForms.c --- lynx2-8-2/src/LYForms.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYForms.c Fri Apr 2 15:30:40 1999 @@ -11,8 +11,6 @@ #include #include #include -#include -#include #include diff -Burp lynx2-8-2/src/LYJump.c lynx2-8-2-patched/src/LYJump.c --- lynx2-8-2/src/LYJump.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYJump.c Fri Apr 2 15:19:19 1999 @@ -5,7 +5,6 @@ #include #include #include -#include #include #include diff -Burp lynx2-8-2/src/LYLocal.c lynx2-8-2-patched/src/LYLocal.c --- lynx2-8-2/src/LYLocal.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYLocal.c Fri Apr 2 15:27:38 1999 @@ -43,7 +43,6 @@ #include #include #include -#include #ifndef VMS #ifndef _WINDOWS diff -Burp lynx2-8-2/src/LYSearch.c lynx2-8-2-patched/src/LYSearch.c --- lynx2-8-2/src/LYSearch.c Sat Aug 15 17:57:56 1998 +++ lynx2-8-2-patched/src/LYSearch.c Fri Apr 2 15:18:05 1999 @@ -5,7 +5,6 @@ #include #include #include -#include #include diff -Burp lynx2-8-2/src/LYStrings.c lynx2-8-2-patched/src/LYStrings.c --- lynx2-8-2/src/LYStrings.c Wed Mar 17 22:17:11 1999 +++ lynx2-8-2-patched/src/LYStrings.c Fri Apr 2 15:15:41 1999 @@ -5,7 +5,6 @@ #include #include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYTraversal.c lynx2-8-2-patched/src/LYTraversal.c --- lynx2-8-2/src/LYTraversal.c Mon Jan 18 07:29:20 1999 +++ lynx2-8-2-patched/src/LYTraversal.c Fri Apr 2 15:19:44 1999 @@ -1,7 +1,6 @@ #include #include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYUtils.c lynx2-8-2-patched/src/LYUtils.c --- lynx2-8-2/src/LYUtils.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYUtils.c Fri Apr 2 15:30:04 1999 @@ -11,7 +11,6 @@ #include #include #include -#include #include #include #include From owner-lynx-dev@sig.net Fri Apr 2 22:36:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA22241 for ; Fri, 2 Apr 1999 22:36:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA16692; Fri, 2 Apr 1999 21:25:33 -0600 (CST) Date: Fri, 2 Apr 1999 19:25:25 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: Lawrence Malmay Cc: DOSLYNX-DEV@raven.cc.ukans.edu, lynx-dev@sig.net Subject: lynx-dev Re: e-mail by lynx In-Reply-To: <37057AAB.74F9@hiwaay.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1330 Lines: 33 On Fri, 2 Apr 1999, Lawrence Malmay wrote: > I don't know if this is the appropriate list to pose my question, > but perhaps someone can help me. I have run into a problem sending The appropriate list for this question is lynx-dev@sig.net > e-mail off homepages e-mail links while using Lynx from my IP's > shell account. What is happening is that the e-mail is being > sent, but in the address heading "From:" my e-mail address is being > truncated. > > example: From: " My Name" > It should be > From: "My Name" We will need more information to help. What version of lynx is this, and running on what platform? Which mail program is specified in lynx.cfg (SYSTEM_MAIL)? How are you entering the name? Lynx can be configured to allow you to specify the FROM: line (NO_ANONYMOUS_EMAIL in userdefs.h). Otherwise it may come from system settings. Where do you see it truncated? Is this in the headers in received mail or do you just see it in copies that you get? Lynx version can be obtained by running "lynx -version". Platform can be obtained at times by running "uname -a". You will have to look at the lynx.cfg file on your ISP for the SYSTEM_MAIL information. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Apr 3 01:26:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA26247 for ; Sat, 3 Apr 1999 01:26:25 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA12808; Sat, 3 Apr 1999 00:18:16 -0600 (CST) Date: Sat, 3 Apr 1999 15:29:30 +0900 (JST) From: Henry Nelson Message-Id: <199904030629.PAA04821@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: Lynx-dev Using Win95...THANKS! Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 473 Lines: 14 > Having problem getting JUMP to work. [...] > 2. This is what I've typed in the lynx.cfg file: > > JUMPFILE:/c:\progra~1\Lynx/jumps.html ^^^ Many a moon ago I had trouble on SunOS before changing to the "single-dot" format below: JUMPFILE:./lynx/Books/jmp.html. I have no idea if "." will have the same meaning on a Win32 system. (On my system, that dot means "/home/staff/nelsonhe", but I don't recall the spelled-out format ever working.) __Henry From owner-lynx-dev@sig.net Sat Apr 3 02:16:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA27489 for ; Sat, 3 Apr 1999 02:16:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA19096; Sat, 3 Apr 1999 01:09:52 -0600 (CST) Date: Sat, 3 Apr 1999 16:21:08 +0900 (JST) From: Henry Nelson Message-Id: <199904030721.QAA05055@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 278 Lines: 8 > unless of course you never need charset translation anyway, but in that > case you shouldn't compile it in at all. It was my understanding that it was no longer possible to _not_ compile in chartrans. What is the configure option or define for not compiling it in? __Henry From owner-lynx-dev@sig.net Sat Apr 3 06:03:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA00047 for ; Sat, 3 Apr 1999 06:03:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA27900; Sat, 3 Apr 1999 04:49:53 -0600 (CST) From: dickey@clark.net Message-Id: <199904031049.FAA05150@shell.clark.net> Subject: Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets To: lynx-dev@sig.net Date: Sat, 3 Apr 1999 05:49:49 -0500 (EST) In-Reply-To: <199904030721.QAA05055@ibr1.irm.nara.kindai.ac.jp> from "Henry Nelson " at Apr 3, 99 04:21:08 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 500 Lines: 18 > > > unless of course you never need charset translation anyway, but in that > > case you shouldn't compile it in at all. > > It was my understanding that it was no longer possible to _not_ compile > in chartrans. What is the configure option or define for not compiling > it in? that also was my understanding (iirc, we got rid of all of those ifdef's, and there is no configure option for it anyway). > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 3 11:19:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA06620 for ; Sat, 3 Apr 1999 11:19:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA04458; Sat, 3 Apr 1999 10:11:41 -0600 (CST) Date: Sat, 3 Apr 1999 17:11:36 +0100 (BST) From: "C.J.LAWSON" X-Sender: fx942976@dhaka.pegasus.cranfield.ac.uk To: David Woolley cc: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: <199903312331.AAA05356@djwhome.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2188 Lines: 56 Hi David, Thanks for your response ... I will do my best to address the issues you raise in your email On Thu, 1 Apr 1999, David Woolley wrote: > > > > > I ran into some program that converts ordinary text files to html > > > and after running the file once or twice on misc files, > > > I tried piping the result to lynx ... didn't like it > > Lynx isn't a general file viewer. You would be much better using > a designed for the purpose tool, e.g, most or less, and if you want > directory browsing, Midnight Commander. Indeed Lynx is not a general file viewer ... nor are most, less or mc suitable for html page viewing ... In my message, I explicitly said that the text was converted to html, first, before it is to be viewed... And yes there is a rationale for it (I am sure you can think of others yourself). > Any Unix system, with sufficient memory, will cache recently accessed > files with no need for any additional software. ??? !!! I cannae see how this has a bearing on the question I asked and what is more ... all the world is not unix .. > > > this is beyond me: anyone else have thoughts? > > I think the thinking is confused, which is why you don't understand it. I'll let you off Easter is a time of forgiveness .. > No reply address available, so you'll have to CC him. Probably, you > should have ignored him; there has been a recent increase in the number > of people asking questions of frequent list contributors when they > should have been asking on the list. No reply address available !? Thats odd, I usually have 2 addresses on each of my emails .. but then again lets add this to the things that we shall ignore and I am sorry you are offended that I didn't send the email to the list directly. However, judging by the contumacy of your response, I am sure you may find it within you to excuse me. Happy Easter --- Jonathan Lawson Thermal Processes Unit Department of Applied Energy and Optical Diagnostics School of Mechanical Engineering, Cranfield University, Cranfield, Bedford. UK. email j.lawson@cranfield.ac.uk So teach us to number our days, that we may apply our hearts unto wisdom. Ps 90:12 From owner-lynx-dev@sig.net Sat Apr 3 12:52:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA08719 for ; Sat, 3 Apr 1999 12:52:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA18707; Sat, 3 Apr 1999 11:47:12 -0600 (CST) Date: Sat, 3 Apr 1999 09:47:06 -0800 From: David Combs To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: reverse-search Message-ID: <19990403094706.C20043@netcom2.netcom.com> References: <9903311052.AA26545@cas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <9903311052.AA26545@cas.org>; from Larry W. Virden on Wed, Mar 31, 1999 at 10:52:42AM -0500 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 725 Lines: 20 On Wed, Mar 31, 1999 at 10:52:42AM -0500, Larry W. Virden wrote: > I don't know that there is so much a technical argument against multiple > key commands (though I myself dislike such things) as there is the simple > limit that most features requested for Lynx has - are you David willing > to sit down and code the feature? > -- > Larry W. Virden Well, I'd sure be willing to write it in pseudo-code, if someone else would maybe translate it into c. For me to write in c, and debug it via dbx (oops, gnu debugger -- haven't had dbx since sun unbundled fortran, pascal, and c :-( ) Would also take some pointing out to me of what routine did the command-parsing. David From owner-lynx-dev@sig.net Sat Apr 3 13:33:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA09828 for ; Sat, 3 Apr 1999 13:33:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA24091; Sat, 3 Apr 1999 12:24:30 -0600 (CST) From: m2brown@uwaterloo.ca Date: Fri, 2 Apr 1999 21:18:42 -0500 (EST) X-Sender: michael@mbrown.supermathie.net To: lynx-dev@sig.net Subject: lynx-dev Memory problems Message-ID: X-Get-A-Real-Mail-Client: WWW home page at: http://www.clark.net/pub/lawrencc/ <---- From owner-lynx-dev@sig.net Mon Apr 5 15:59:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA03566 for ; Mon, 5 Apr 1999 15:59:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA04968; Mon, 5 Apr 1999 14:37:51 -0500 (CDT) From: Heather Stern Message-Id: <199904051911.MAA30486@betelgeuse.starshine.org> Subject: Re: lynx-dev default browser on W95 In-Reply-To: <19990405093842.B12645@mred.intellistor.com> from "tlhall@royal.net" at "Apr 5, 99 09:38:42 am" To: lynx-dev@sig.net Date: Mon, 5 Apr 1999 12:11:20 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL37 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2336 Lines: 51 I ate the fortune cookie first, then read what tlhall@royal.net wrote: > I've searched the FAQs and the lynx-dev archives back to '96 and the only > mention I've found of making lynx the default browser in W95/98 is the > one below from Lord Fido. > > Does anyone know how to do it ? > > As Fido says, it takes more than an association with .htm[l] files. > > I think it requires a source code change. Does lynx for win32 honor DDE? If so, then it probably doesn't; merely(!) adjusting applicable registry entries in the form ...\shell\open\command ...\shell\open\ddeexec\Application The topic that IE honors is WWW_OpenURL (according to my thinkpad) ... yeah, I have a token MSwin box around the house. I can't say if I'd prefer DDE calls of this sort to launch new lynx pages or change the running copy (a'la o commands). MSwin apps use DDE in this way to call the running browser, MS behind-the-scenes launches it if it wasn't running already (using the registry entries of course). > Both IE and NetScape have a setting to have it 'check to see if it's the > default browser'. Yet, how do other apps know what to start when you > tell them to 'start your default browser' or when you click on help buttons ? I don't know precisely what they're up to when they do this; but, Mozilla's source is open, so the answer is findable, even if we can't use the same code. Somewhat more whitebox, save your entire registry to a file, let the other one abuse the registry ^H... change the default, and then save the registry to another file. Run diff or some applicable compare tool against them to see what changed. Regedit isn't very bright but it can be used for this. > This implies to me that some component must run in the background or > is somehow hooked into the OS... DDE is the message-passing of the 90's for MSwin applications. > On Sat, Sep 26, 1998 at 08:12:33PM +0000, Fido wrote: > > Subject: lynx-dev Bots and such? > > Go to www.eunet.fi/tucows (or similar via www.tucows.com), select winNT, > > search bots, download all those freeware programs and make lynx work with > > them.. They all need a little bit more than just associating .htm with > > lynx.exe.. That darn default browser thingy etc.. ); We still aren't going to work with FrontPage bots, or toys that relate to javascripting. From owner-lynx-dev@sig.net Mon Apr 5 16:22:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA04853 for ; Mon, 5 Apr 1999 16:22:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA17596; Mon, 5 Apr 1999 15:12:37 -0500 (CDT) Message-Id: <199904052012.QAA1186533@relay.interim.iamworld.net> X-Sender: 10003479@pop.iamdigex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 05 Apr 1999 16:15:59 -0400 To: Robert.Neff@usmint.treas.gov From: Al Gilman Subject: lynx-dev "looking up 'folder'" error message Cc: lynx-dev@sig.net In-Reply-To: <199904051936.OAA04487@roadrunner.sig.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2112 Lines: 56 At 02:36 PM 4/5/99 -0500, owner-lynx-dev@sig.net wrote: >>From owner-lynx-dev Mon Apr 5 14:36:33 1999 >Received: from mx-out1.treas.gov (mx-out1.treas.gov [207.24.148.13]) by roadrunner.sig.net (8.9.0/8.8.6) with ESMTP id OAA04460 for ; Mon, 5 Apr 1999 14:36:32 -0500 (CDT) >Received: from mailhub-1.net.treas.gov (tcs-gateway7.treas.gov [207.24.148.12]) > by mx-out1.treas.gov (8.9.1a/8.9.1) with ESMTP id LAA14366 > for ; Mon, 5 Apr 1999 11:26:24 -0400 (EDT) >Received: from irmadmin.usmint.treas.gov ([10.102.9.4]) > by mailhub-1.net.treas.gov (8.9.2/8.9.2) with ESMTP id PAA11840 > for ; Mon, 5 Apr 1999 15:35:59 -0400 (EDT) >Received: by IRMADMIN.usmint.treas.gov with Internet Mail Service (5.5.2448.0) It would appear that you have installed Lynx in a folder named "Lynx folder" or somewhere in the path to the Lynx executable there is such a folder name containing whitespace. The reference to the path to the executable in LYNX.BAT or some similar reference is breaking when the program launches. It is a Win95 problem of short vs. long names. If this is the problem there are two fixes: a) install Lynx under a path with all 8.3 names running down to it. b) change the references in the LYNX.BAT file [to use the 8.3 abbreviations?] for the long-name segments in the path. HTH Al > id ; Mon, 5 Apr 1999 15:36:01 -0400 >Message-ID: >From: "Neff, Robert" >To: "'lynx-dev@sig.net'" >Subject: error message >Date: Mon, 5 Apr 1999 15:35:56 -0400 >Importance: high >X-Priority: 1 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2448.0) >Content-Type: text/plain; > charset="iso-8859-1" > >I have just downloaded Lynx and am having trouble getting to work. I have >downloaded and unzipped hte file into a file and when I open the application >file lynx.exe, I get: > >1. Looking up folder first. >2. Then Looking up www.Folder.com, guessing... > >Any ideas on how I can get this to function. > >thanks! > From owner-lynx-dev@sig.net Mon Apr 5 16:32:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA05972 for ; Mon, 5 Apr 1999 16:31:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA20872; Mon, 5 Apr 1999 15:21:54 -0500 (CDT) Date: Mon, 5 Apr 1999 13:21:43 -0700 (PDT) From: David Combs Message-Id: <199904052021.NAA25450@netcom17.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: .lynx_cookies First-line a COMMENT: columns-DOC Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 881 Lines: 21 Does the synxtax for .lynx_cookies allow comment-lines? If so, how about a line or several at the top, explaining the columns (or fields or whatever they're called)? .cfol.com FALSE / FALSE 1201651200 CFOL_PERM_ORGID 0 .snap.com FALSE / FALSE 946684799 u_edition_0_0 home .pathfinder.com FALSE / FALSE 2051222400 PFUID cc47f23d369fa22c049a1000ffffff9d www.rediff.com FALSE / FALSE 1293753600 EGSOFT_ID 192.100.81.107-189557040.29245635 .tripod.com FALSE / FALSE 945610792 CookieStatus COOKIE_OK cnn.com FALSE / FALSE 942189160 CNNid cf194710-19707-911277331-4 www.salonmagazine.com FALSE / FALSE 942189160 NGUserID a00000f-266-908149981-1 ... Also (stupid question?) is the format of the above unique to lynx, or is it instead that IS the "standard" format for cookies, and indeed this single file IS the cookie-container; ie a "cookie" is just a line of text IN this file? From owner-lynx-dev@sig.net Mon Apr 5 17:13:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA08255 for ; Mon, 5 Apr 1999 17:13:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA05673; Mon, 5 Apr 1999 16:01:14 -0500 (CDT) From: newsmgr@mhl.nsw.gov.au Date: Tue, 6 Apr 1999 07:00:27 +1000 Message-Id: <99040607002742@mhl.nsw.gov.au> To: lynx-dev@sig.net Subject: lynx-dev Image view problem on VMS X-VMS-To: @MHL_LYNX-DEV.DIS Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6972 Lines: 171 RE: Lynx image viewing problem When attempting to view the same image multiple times the display only works the first time, all subsequent attempts return a file access error from the viewing program. Spawning a session shows the temporary files like this, the zero length indicates a file may be still open to the writing program. L1244-1TMP.GIF;3 0 A new version for each attempt. L1244-1TMP.GIF;2 0 L1244-1TMP.GIF;1 0 LYNX.TRACE;1 0 Total of 5 files, 0 blocks. Here's some trace from a failed attempt. Lynx Trace Log User message: Trace ON! LYpush[1]: address:http://www.mhl.nsw.gov.au/www/welcome.html title:Welcome to Manly Hydraulics Laboratory getfile: getting http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:www.mhl.nsw.gov.au HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 533028 with address `http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif' already exists. HTAccess: loading document http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName:file: HTParse: result:http HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:www.mhl.nsw.gov.au HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:http HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:http HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:www.mhl.nsw.gov.au Looking up www.mhl.nsw.gov.au. HTParseInet: parsing `www.mhl.nsw.gov.au'. HTParseInet: Parsed address as port 80, IP address 203.0.140.10 Making HTTP connection to www.mhl.nsw.gov.au. HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: 1 HTParse: result:/www_root/data/dpws3.gif HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:www.mhl.nsw.gov.au HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: 1 HTParse: result:/www_root/data/dpws3.gif HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: 1 HTParse: result:www_root/data/dpws3.gif HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: HTParse: result:www.mhl.nsw.gov.au [snip cookie junk] www.mhl.nsw.gov.au .tripod.com 0 /www_root/data/dpws3.gif / 0 Composing Authorization for www.mhl.nsw.gov.au:80/www_root/data/dpws3.gif HTAASetup_lookup: No template matched `www_root/data/dpws3.gif' (so probably not protected) HTTP: Not sending authorization (yet). Writing: GET /www_root/data/dpws3.gif HTTP/1.0 Host: www.mhl.nsw.gov.au Accept: text/html, text/plain, text/sgml, image/jpeg, image/gif, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: en Negotiate: trans User-Agent: Lynx/2.8.1rel.2 libwww-FM/2.14 Referer: http://www.mhl.nsw.gov.au/www/welcome.html ---------------------------------- Sending HTTP request. HTTP: WRITE delivered OK HTTP request sent; waiting for response. HTTP: Trying to read 1023 HTTP: Read 195 HTTP: Rx: HTTP/1.0 200 Sending data HTTP: Scanned 2 fields from line_buffer --- Talking HTTP1. HTTP/1.0 200 Sending data HTFormat: Constructing stream stack for www/mime to www/present HTFormat: Looking up presentation for www/mime to www/present StreamStack: found weak wildcard match: www/present FindPresentation: found exact match: www/mime StreamStack: found exact match: www/mime HTMIME: MIME-version: 1.0 Server: OSU/1.8 Content-type: image/gif Content-transfer-encoding: binary Content-length: 10264 Last-Modified: Friday, 11-Sep-98 11:40:54 GMT HTMIME: Got 'S' at beginning of line, state now S HTMIME: Was S, found E, state now SE' HTMIME: Was SE, found R, checking for 'ver' HTMIME: PICKED UP Server: 'OSU/1.8' HTMIME: Got 'C' at beginning of line, state now C HTMIME: Was C, found O, state now CO' HTMIME: Was CO, found N, state now CON HTMIME: Was CON, found T, checking for 'ent-' HTMIME: in case CONTENT_ HTMIME: Was CONTENT_, found T, state now CONTENT_T HTMIME: in case CONTENT_T HTMIME: Was CONTENT_T, found Y, checking for 'pe:' HTMIME: PICKED UP Content-Type: 'image/gif' HTMIME: Got 'C' at beginning of line, state now C HTMIME: Was C, found O, state now CO' HTMIME: Was CO, found N, state now CON HTMIME: Was CON, found T, checking for 'ent-' HTMIME: in case CONTENT_ HTMIME: Was CONTENT_, found T, state now CONTENT_T HTMIME: in case CONTENT_T HTMIME: Was CONTENT_T, found R, checking for 'ansfer-encoding:' HTMIME: PICKED UP Content-Transfer-Encoding: 'binary' HTMIME: Got 'C' at beginning of line, state now C HTMIME: Was C, found O, state now CO' HTMIME: Was CO, found N, state now CON HTMIME: Was CON, found T, checking for 'ent-' HTMIME: in case CONTENT_ HTMIME: Was CONTENT_, found L, state now CONTENT_L HTMIME: in case CONTENT_L HTMIME: Was CONTENT_L, found E, checking for 'ngth:' HTMIME: PICKED UP Content-Length: '10264' Converted to integer: '10264' HTMIME: Got 'L' at beginning of line, state now L HTMIME: Was L, found A, checking for 'st-modified:' HTMIME: PICKED UP Last-Modified: 'Friday, 11-Sep-98 11:40:54 GMT' HTMIME: MIME Content-Type is 'image/gif', converting to 'www/present' HTFormat: Constructing stream stack for image/gif to www/present HTFormat: Looking up presentation for image/gif to www/present StreamStack: found weak wildcard match: www/present FindPresentation: found exact match: image/gif StreamStack: found exact match: image/gif Data transfer complete LYCloseTempFP gif_view sys$scratch:L1244-1TMP.gif **** Viewing program ***** HTAccess: status=29997 HTAccess: `http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif' has been accessed. LYpop[1]: address:http://www.mhl.nsw.gov.au/www/welcome.html title:Welcome to Manly Hydraulics Laboratory getfile: getting http://www.mhl.nsw.gov.au/www/welcome.html HTParse: aName:http://www.mhl.nsw.gov.au/www/welcome.html relatedName: HTParse: result:www.mhl.nsw.gov.au HTParse: aName:http://www.mhl.nsw.gov.au/www/welcome.html relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 525E50 with address `http://www.mhl.nsw.gov.au/www/welcome.html' already exists. HTAccess: loading document http://www.mhl.nsw.gov.au/www/welcome.html HTAccess: Document already in memory. GridText: HText_pageDisplay at line 1 started GridText: HText_pageDisplay finished (Lynx 2.8.1rel2, Alpha VMS 7.1, DEC C 5.6, UCX 4.2) Regards * * * * * Tony Bolton **** **** ** ** ** TBolton 'at' mhl.nsw.gov.au ** **** ** ********* ** MANLY HYDRAULICS LABORATORY. ** ** ** ********* ** 110B King ST. Manly Vale 2093 Sydney AUSTRALIA ** ** ** ** ******** Phone +61 2 99490200 FAX +61 2 99486185 From owner-lynx-dev@sig.net Mon Apr 5 17:26:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA09705 for ; Mon, 5 Apr 1999 17:26:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA10731; Mon, 5 Apr 1999 16:15:04 -0500 (CDT) Message-ID: <19990405151346.A25955@mred.intellistor.com> Date: Mon, 5 Apr 1999 15:13:46 -0600 From: tlhall@royal.net To: lynx-dev@sig.net Subject: Re: lynx-dev default browser on W95 References: <19990405093842.B12645@mred.intellistor.com> <199904051911.MAA30486@betelgeuse.starshine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199904051911.MAA30486@betelgeuse.starshine.org>; from Heather Stern on Mon, Apr 05, 1999 at 12:11:20PM -0700 Organization: Intellistor R&D Operation Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1232 Lines: 31 On Mon, Apr 05, 1999 at 12:11:20PM -0700, Heather Stern wrote: > .. > Does lynx for win32 honor DDE? Boy, I'd be surprised if it did. > I can't say if I'd prefer DDE calls of this sort to launch new lynx pages > or change the running copy (a'la o commands). I'd rather it open a new lynx with each one. I wonder... I found this neat-o scripting tool called 'DDE script' (http://www.winsite.com/info/pc/win3/programr/ddesc110.zip) that lets me write scripts in ASCII files to do DDE client conversations (still haven't been able to successfullly talk to NetScape tho ? ) Is there something similar that would allow me to write server command scripts ? Maybe I could have it be a wrapper around lynx, and when some app tries to start a WWW_OpenURL topic, it could launch lynx. > Somewhat more whitebox, save your entire registry to a file, let the other > one abuse the registry ^H... change the default, and then save the registry > to another file. Run diff or some applicable compare tool against them > to see what changed. Regedit isn't very bright but it can be used for this. Thanks - I'll give this a try ... > DDE is the message-passing of the 90's for MSwin applications. Is OLE the one of the 00's ? From owner-lynx-dev@sig.net Mon Apr 5 17:59:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10554 for ; Mon, 5 Apr 1999 17:59:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA23118; Mon, 5 Apr 1999 16:51:03 -0500 (CDT) To: lynx-dev@sig.net, tlhall@royal.net References: <19990405093842.B12645@mred.intellistor.com> Message-Id: From: "Leonid Pauzner" Date: Mon, 5 Apr 1999 22:34:53 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev default browser on W95 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 762 Lines: 21 5-Apr-99 09:38 tlhall@royal.net wrote: > I've searched the FAQs and the lynx-dev archives back to '96 and the only > mention I've found of making lynx the default browser in W95/98 is the > one below from Lord Fido. How many times would you send this question to the list (this is copy #3 during last week or so). > Does anyone know how to do it ? > As Fido says, it takes more than an association with .htm[l] files. > I think it requires a source code change. > Both IE and NetScape have a setting to have it 'check to see if it's the > default browser'. Yet, how do other apps know what to start when you > tell them to 'start your default browser' or when you click on help buttons ? This probably a Windows configuration question, not a lynx one. From owner-lynx-dev@sig.net Mon Apr 5 17:59:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10561 for ; Mon, 5 Apr 1999 17:59:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA23072; Mon, 5 Apr 1999 16:50:58 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 6 Apr 1999 01:48:31 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev (patch) activate lynx.cfg changes for current lynx session MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 19120 Lines: 568 * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page with the default editor and changes can be activated for the same lynx session. NOT allowed for restricted users (LYRestricted) and occasionally for user mode other than ADVANCED. This is an *experimental* code (reload_read_cfg() in LYMain.c - more work required): currently command-line switches may be lost when overriden by lynx.cfg changes, file paths like lynx_temp_space and LYCookieFile should not be changed (unwanted results). - LP This is a rather long patch over my previous patches but really independent since changes affects other parts of the code. Comments: 1) lynx_cfg_infopage() and lynx_compile_opts() both absorb some code from LYGetFile.c - this may be not nice but add more flexibility. lynx_cfg_infopage() now gains a lot from postoptions() code. 2) lynx_compile_opts() moved from LYShowInfo.c to LYReadCFG.c 3) other minore changes for lynx_cfg_infopage() HTML layout made. 4) two pages excluded from Visited Links page. 5) contributions for reload_read_cfg() always welcome. diff -u old/lygetfil.c ./lygetfil.c --- old/lygetfil.c Wed Mar 31 15:48:14 1999 +++ ./lygetfil.c Mon Apr 5 23:36:24 1999 @@ -250,33 +250,13 @@ #endif } else if (url_type == LYNXCFG_URL_TYPE) { - /* show lynx.cfg settings */ - StrAllocCopy(doc->address, lynx_cfg_infopage()); - WWWDoc.address = doc->address; - WWWDoc.post_data = doc->post_data; - WWWDoc.post_content_type = doc->post_content_type; - WWWDoc.bookmark = doc->bookmark; - WWWDoc.isHEAD = doc->isHEAD; - WWWDoc.safe = doc->safe; + /* show/change/reload lynx.cfg settings */ + return(lynx_cfg_infopage(doc)); - if (!HTLoadAbsolute(&WWWDoc)) - return(NOT_FOUND); - return(NORMAL); - -#ifdef HAVE_CFG_DEFS_H +#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) } else if (url_type == LYNXCOMPILE_OPTS_URL_TYPE) { /* show compile-time settings */ - StrAllocCopy(doc->address, (char *)lynx_compile_opts()); - WWWDoc.address = doc->address; - WWWDoc.post_data = doc->post_data; - WWWDoc.post_content_type = doc->post_content_type; - WWWDoc.bookmark = doc->bookmark; - WWWDoc.isHEAD = doc->isHEAD; - WWWDoc.safe = doc->safe; - - if (!HTLoadAbsolute(&WWWDoc)) - return(NOT_FOUND); - return(NORMAL); + return(lynx_compile_opts(doc)); #endif #ifndef DISABLE_NEWS diff -u old/lyhistor.c ./lyhistor.c --- old/lyhistor.c Wed Mar 31 00:43:06 1999 +++ ./lyhistor.c Mon Apr 5 23:36:02 1999 @@ -67,6 +67,7 @@ * or list files. - FM */ if (doc->post_data || doc->isHEAD || doc->bookmark || + (!strncmp(doc->address, "file://localhost/", 17) && ( !strcmp((doc->title ? doc->title : ""), HISTORY_PAGE_TITLE) || !strcmp((doc->title ? doc->title : ""), PRINT_OPTIONS_TITLE) || !strcmp((doc->title ? doc->title : ""), DOWNLOAD_OPTIONS_TITLE) || @@ -82,9 +83,11 @@ !strcmp((doc->title ? doc->title : ""), ADDRLIST_PAGE_TITLE) || #endif !strcmp((doc->title ? doc->title : ""), SHOWINFO_TITLE) || + !strcmp((doc->title ? doc->title : ""), CONFIG_DEF_TITLE) || + !strcmp((doc->title ? doc->title : ""), LYNXCFG_TITLE) || !strcmp((doc->title ? doc->title : ""), COOKIE_JAR_TITLE) || !strcmp((doc->title ? doc->title : ""), VISITED_LINKS_TITLE) || - !strcmp((doc->title ? doc->title : ""), LYNX_TRACELOG_TITLE)) { + !strcmp((doc->title ? doc->title : ""), LYNX_TRACELOG_TITLE)))) { return; } diff -u old/lymain.c ./lymain.c --- old/lymain.c Sun Apr 4 15:37:18 1999 +++ ./lymain.c Mon Apr 5 23:55:22 1999 @@ -1362,15 +1362,15 @@ LYEnsureAbsoluteURL((char **)&LynxHome, "LynxHome"); /* - * Process any command line arguments not already handled. - FM + * Process any command line arguments not already handled. - FM */ for (i = 1; i < argc; i++) { parse_arg(&argv[i], &i); } /* - * Process any stdin-derived arguments for a lone "-" which we've - * loaded into LYStdinArgs. - FM + * Process any stdin-derived arguments for a lone "-" which we've + * loaded into LYStdinArgs. - FM */ if (LYStdinArgs != NULL) { char *my_args[2]; @@ -1384,7 +1384,7 @@ } /* - * Set the rest of variables when the configuration have read. + * Initialize other things based on the configuration read. */ HTSwitchDTD(!Old_DTD); @@ -1421,6 +1421,14 @@ #endif /* + * Set up our help and about file base paths. - FM + */ + StrAllocCopy(helpfilepath, helpfile); + if ((cp = LYPathLeaf(helpfilepath)) != helpfilepath) + *cp = '\0'; + LYAddHtmlSep(&helpfilepath); + + /* * Check for a save space path in the environment. * If one was set in the configuration file, that * one will be overridden. - FM @@ -1709,14 +1717,6 @@ } /* - * Set up our help and about file base paths. - FM - */ - StrAllocCopy(helpfilepath, helpfile); - if ((cp = LYPathLeaf(helpfilepath)) != helpfilepath) - *cp = '\0'; - LYAddHtmlSep(&helpfilepath); - - /* * Make sure our bookmark default strings * are all allocated and synchronized. - FM */ @@ -1810,6 +1810,59 @@ HTRegisterProtocol(&LYLynxIMGmap); HTRegisterProtocol(&LYLynxCookies); } + + +/* + * Some staff to reload lynx.cfg without restarting new lynx session, + * also load options menu items and command-line options + * to made things consistent. Not implemented yet. + * Warning: experimental, more main() reorganization required. + * + * Called by user of interactive session by LYNXCFG://reload/ link. + */ +PUBLIC void reload_read_cfg NOARGS +{ + if (!LYRestricted) { + + /* save .lynxrc file in case we change something from Options Menu */ + if (!save_rc()) return; + + /* + * Process the configuration file. + */ + read_cfg(lynx_cfg_file, "main program", 1, (FILE *)0); + + /* + * Process the RC file. + */ + read_rc(); + + + /* We are not interested in startfile here */ + /* but other things may be lost: */ + + /* + * Process any command line arguments not already handled. - FM + */ + /* Not implemented yet here */ + + /* + * Process any stdin-derived arguments for a lone "-" which we've + * loaded into LYStdinArgs. - FM + */ + /* Not implemented yet here */ + + /* + * Initialize other things based on the configuration read. + */ + /* Not implemented yet here, + * a major problem: file paths + * like lynx_temp_space, LYCookieFile etc. + */ + + } +} + /* There are different ways of setting arguments on the command line, and * there are different types of arguments. These include: diff -u old/lyreadcf.c ./lyreadcf.c --- old/lyreadcf.c Mon Apr 5 17:52:24 1999 +++ ./lyreadcf.c Mon Apr 5 23:36:06 1999 @@ -1034,8 +1034,6 @@ {0} }; -PRIVATE char *local_url = NULL; - /* * Free memory allocated in 'read_cfg()' */ @@ -1060,7 +1058,6 @@ break; } } - FREE(local_url); } /* @@ -1238,19 +1235,28 @@ case CONF_INCLUDE: /* include another file */ #ifndef NO_CONFIG_INFO - if (fp0 != 0) { + if (fp0 != 0 && !LYRestricted) { char *url = 0; + char *cp1 = NULL; LYLocalFileToURL(&url, value); - fprintf(fp0, "%s:%s\n\n", name, url, value); - fprintf(fp0, " #<begin %s>\n", value); + StrAllocCopy(cp1, value); + if (strchr(value, '&') || strchr(value, '<')) { + LYEntify(&cp1, TRUE); + } + + fprintf(fp0, "%s:%s\n\n", name, url, cp1); + fprintf(fp0, " #<begin %s>\n", cp1); + + read_cfg (value, cfg_filename, nesting_level + 1, fp0); + + fprintf(fp0, " #<end of %s>\n\n", cp1); FREE(url); - } -#endif + FREE(cp1); + } else +#endif /* !NO_CONFIG_INFO */ + read_cfg (value, cfg_filename, nesting_level + 1, fp0); -#ifndef NO_CONFIG_INFO - if (fp0 != 0) - fprintf(fp0, " #<end of %s>\n\n", value); -#endif + break; case CONF_ADD_ITEM: @@ -1355,19 +1361,78 @@ } + +extern void reload_read_cfg NOPARAMS; /* not implemented yet, in LYMain.c */ + /* - * lynx.cfg infopage, returns local url. + * Show rendered lynx.cfg data without comments, LYNXCFG:/ internal page. + * Called from getfile() cyrcle: + * we create and load the page just in place and return to mainloop(). */ -PUBLIC char *lynx_cfg_infopage NOARGS +PUBLIC int lynx_cfg_infopage ARGS1( + document *, newdoc) { char tempfile[LY_MAXPATH]; + static char *local_url; /* static! */ + DocAddress WWWDoc; /* need on exit */ char *temp = 0; + char *cp1 = NULL; FILE *fp0; + +#ifndef NO_CONFIG_INFO + /*------------------------------------------------- + * kludge a link from LYNXCFG:/, the URL was: + * " RELOAD THE CHANGES\n" + *--------------------------------------------------*/ + + if ((strstr(newdoc->address, "LYNXCFG://reload")) && !LYRestricted) { + /* + * Some staff to reload read_cfg(), + * but also load options menu items and command-line options + * to made things consistent. Not implemented yet. Dummy. + */ + reload_read_cfg(); + + /* + * now pop-up and return to updated LYNXCFG:/ page, + * remind postoptions() but much simpler: + */ + + /* the page was pushed, so pop-up. */ + LYpop(newdoc); + WWWDoc.address = newdoc->address; + WWWDoc.post_data = newdoc->post_data; + WWWDoc.post_content_type = newdoc->post_content_type; + WWWDoc.bookmark = newdoc->bookmark; + WWWDoc.isHEAD = newdoc->isHEAD; + WWWDoc.safe = newdoc->safe; + LYforce_no_cache = FALSE; /* ! */ + LYoverride_no_cache = TRUE; /* ! */ + /* + * Working out of getfile() cycle we reset *no_cache manually here so + * HTLoadAbsolute() will return "Document already in memory": it was + * forced reloading obsolete file again without this (overhead). + * + * Probably *no_cache was set in a wrong position because of + * the internal page... + */ + if (!HTLoadAbsolute(&WWWDoc)) + return(NOT_FOUND); + + + /* FIXME: probably remove obsolete temp file just now (before exit)? */ + + /* now set up the flag and fall down to create a new LYNXCFG:/ page */ + local_url = 0; /* see below */ + } +#endif /* !NO_CONFIG_INFO */ + + if (local_url == 0) { if ((fp0 = LYOpenTemp(tempfile, HTML_SUFFIX, "w")) == NULL) { HTAlert(CANNOT_OPEN_TEMP); - return(0); + return(NOT_FOUND); } LYLocalFileToURL(&local_url, tempfile); @@ -1376,13 +1441,15 @@ BeginInternalPage (fp0, LYNXCFG_TITLE, NULL); fprintf(fp0, "
\n");

+
 #ifndef NO_CONFIG_INFO
+       if (!LYRestricted) {
 #if defined(HAVE_CONFIG_H) || defined(VMS)
        if (strcmp(lynx_cfg_file, LYNX_CFG_FILE)) {
-           StrAllocCopy(temp, LYNX_CFG_FILE);
            fprintf(fp0, "%s\n%s",
                         gettext("This is read from your lynx.cfg file,"),
                         gettext("please \"read\" distribution's"));
+           LYLocalFileToURL(&temp, LYNX_CFG_FILE);
            fprintf(fp0, " lynx.cfg ",
                         temp);
            FREE(temp);
@@ -1396,20 +1463,32 @@
                         gettext("This is read from your lynx.cfg file,"),
                         gettext("please \"read\" distribution's"));
            fprintf(fp0, " lynx.cfg ");
-           fprintf(fp0, "%s\n\n",
+           fprintf(fp0, "%s\n",
                         gettext("for more comments."));
        }

+/** a new experimental link ... **/
+       if (user_mode == ADVANCED_MODE)
+           fprintf(fp0, "  %s\n",
+                       gettext("RELOAD THE CHANGES"));
+
+
        LYLocalFileToURL(&temp, lynx_cfg_file);
-       fprintf(fp0, "    #%s %s\n",
+       StrAllocCopy(cp1, lynx_cfg_file);
+       if (strchr(lynx_cfg_file, '&') || strchr(lynx_cfg_file, '<')) {
+           LYEntify(&cp1, TRUE);
+       }
+       fprintf(fp0, "\n    #%s %s\n",
                    gettext("Your primary configuration"),
                    temp,
-                   lynx_cfg_file);
+                   cp1);
        FREE(temp);
+       FREE(cp1);
+
+       } else
+#endif /* !NO_CONFIG_INFO */

-#else
        fprintf(fp0, "%s\n\n", gettext("This is read from your lynx.cfg file:"));
-#endif /* NO_CONFIG_INFO */

        /*
         *  Process the configuration file.
@@ -1421,5 +1500,78 @@
        LYCloseTempFP(fp0);
     }

-    return(local_url);
+                   /* return to getfile() cyrcle */
+                   StrAllocCopy(newdoc->address, local_url);
+                   WWWDoc.address = newdoc->address;
+                   WWWDoc.post_data = newdoc->post_data;
+                   WWWDoc.post_content_type = newdoc->post_content_type;
+                   WWWDoc.bookmark = newdoc->bookmark;
+                   WWWDoc.isHEAD = newdoc->isHEAD;
+                   WWWDoc.safe = newdoc->safe;
+
+                   if (!HTLoadAbsolute(&WWWDoc))
+                        return(NOT_FOUND);
+                   return(NORMAL);
+}
+
+
+#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO)
+/*
+ *  Compile-time definitions info, LYNXCOMPILEOPTS:/ internal page,
+ *  from getfile() cyrcle.
+ */
+PUBLIC int lynx_compile_opts ARGS1(
+    document *,                newdoc)
+{
+    char tempfile[LY_MAXPATH];
+#define PutDefs(table, N) fprintf(fp0, "%-35s %s\n", table[N].name, table[N].value)
+#include 
+    unsigned n;
+    static char *info_url;  /* static! */
+    DocAddress WWWDoc;  /* need on exit */
+    FILE *fp0;
+
+    /* create the page only once - compile-time data will not change... */
+
+    if (info_url == 0) {
+       if ((fp0 = LYOpenTemp (tempfile, HTML_SUFFIX, "w")) == 0) {
+           HTAlert(CANNOT_OPEN_TEMP);
+           return(NOT_FOUND);
+       }
+       LYLocalFileToURL(&info_url, tempfile);
+
+       BeginInternalPage (fp0, CONFIG_DEF_TITLE, NULL);
+       fprintf(fp0, "
\n");
+
+       fprintf(fp0, "%s %s lynx.cfg %s\n\n",
+           SEE_ALSO,
+           YOUR_SEGMENT,
+           RUNTIME_OPT_SEGMENT);
+
+       fprintf(fp0, "\n%s
\nconfig.cache\n", AUTOCONF_CONFIG_CACHE); + for (n = 0; n < TABLESIZE(config_cache); n++) { + PutDefs(config_cache, n); + } + fprintf(fp0, "\n%s
\nlynx_cfg.h\n", AUTOCONF_LYNXCFG_H); + for (n = 0; n < TABLESIZE(config_defines); n++) { + PutDefs(config_defines, n); + } + fprintf(fp0, "
\n"); + EndInternalPage(fp0); + LYCloseTempFP(fp0); + } + + /* exit to getfile() cyrcle */ + StrAllocCopy(newdoc->address, info_url); + WWWDoc.address = newdoc->address; + WWWDoc.post_data = newdoc->post_data; + WWWDoc.post_content_type = newdoc->post_content_type; + WWWDoc.bookmark = newdoc->bookmark; + WWWDoc.isHEAD = newdoc->isHEAD; + WWWDoc.safe = newdoc->safe; + + if (!HTLoadAbsolute(&WWWDoc)) + return(NOT_FOUND); + return(NORMAL); } +#endif /* !NO_CONFIG_INFO */ diff -u old/lyreadcf.h ./lyreadcf.h --- old/lyreadcf.h Wed Mar 31 00:43:12 1999 +++ ./lyreadcf.h Mon Apr 5 23:36:20 1999 @@ -47,7 +47,7 @@ extern void free_lynx_cfg NOPARAMS; extern BOOLEAN have_read_cfg; -extern char *lynx_cfg_infopage NOPARAMS; -extern char *lynx_compile_opts NOPARAMS; +extern int lynx_cfg_infopage PARAMS((document *newdoc)); +extern int lynx_compile_opts PARAMS((document *newdoc)); #endif /* LYREADCFG_H */ diff -u old/lyshowin.c ./lyshowin.c --- old/lyshowin.c Wed Mar 31 00:43:12 1999 +++ ./lyshowin.c Mon Apr 5 23:36:28 1999 @@ -24,55 +24,6 @@ #define ADVANCED_INFO 1 /* to get more info in advanced mode */ -#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) -#define HAVE_CFG_DEFS_H - -#define PutDefs(table, N) fprintf(fp0, "%-35s %s\n", table[N].name, table[N].value) - -/* - * Compile-time definitions info, returns local url - */ -PUBLIC char *lynx_compile_opts NOARGS -{ - char tempfile[LY_MAXPATH]; -#include - unsigned n; - static char *info_url; - FILE *fp0; - - if (info_url == 0) { - if ((fp0 = LYOpenTemp (tempfile, HTML_SUFFIX, "w")) == 0) { - HTAlert(CANNOT_OPEN_TEMP); - return(0); - } - LYLocalFileToURL(&info_url, tempfile); - - BeginInternalPage (fp0, CONFIG_DEF_TITLE, NULL); - fprintf(fp0, "
\n");
-
-       fprintf(fp0, "%s %s lynx.cfg %s\n\n",
-           SEE_ALSO,
-           YOUR_SEGMENT,
-           RUNTIME_OPT_SEGMENT);
-
-       fprintf(fp0, "\n%s
\nconfig.cache\n", AUTOCONF_CONFIG_CACHE); - for (n = 0; n < TABLESIZE(config_cache); n++) { - PutDefs(config_cache, n); - } - fprintf(fp0, "\n%s
\nlynx_cfg.h\n", AUTOCONF_LYNXCFG_H); - for (n = 0; n < TABLESIZE(config_defines); n++) { - PutDefs(config_defines, n); - } - fprintf(fp0, "
\n"); - EndInternalPage(fp0); - LYCloseTempFP(fp0); - } - return info_url; -} -#else -#undef HAVE_CFG_DEFS_H -#endif /* !NO_CONFIG_INFO */ - /* * Showinfo prints a page of info about the current file and the link * that the cursor is on. @@ -135,7 +86,7 @@ (LYNX_RELEASE ? REL_VERSION : DEV_VERSION) ); if (!LYRestricted) { -#ifdef HAVE_CFG_DEFS_H +#if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) fprintf(fp0, " - %s\n", COMPILE_OPT_SEGMENT); #else From owner-lynx-dev@sig.net Mon Apr 5 21:16:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA16025 for ; Mon, 5 Apr 1999 21:16:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10652; Mon, 5 Apr 1999 20:08:04 -0500 (CDT) From: Heather Stern Message-Id: <199904060033.RAA30752@betelgeuse.starshine.org> Subject: Re: lynx-dev default browser on W95 In-Reply-To: from Leonid Pauzner at "Apr 5, 99 10:34:53 pm" To: lynx-dev@sig.net Date: Mon, 5 Apr 1999 17:33:34 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL37 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1537 Lines: 34 tlhall@royal.net wrote: > > I've searched the FAQs and the lynx-dev archives back to '96 and the only > > mention I've found of making lynx the default browser in W95/98 is the > > one below from Lord Fido. ... > > As Fido says, it takes more than an association with .htm[l] files. > > I think it requires a source code change. > > > Both IE and NetScape have a setting... > > tell them to 'start your default browser' Leonid Pauzner wrote: > This probably a Windows configuration question, not a lynx one. Yes and no; *my* favorite HTML editor (HTMLedPro, for such MSwin folk as may be following) allows me to set the complete command line to browse work-in-progress, and a checkbox option for whether it should make a DDE request or not. Obviously for use of lynx it'd be no DDE, and the given commandline would mention the lynx binary. If the tool he's trying to work with requires DDE, then he either needs to wrap the DDE call and doctor the registry... yes, that's MSwin config stuff... and/or lynx needs to honor DDE... no, that's not MSwin's space. Ideally, I've given him enough that he can figure out a DDE wrapper for the call, and he will learn enough about DDE in so doing to be able to add the applicable support to lynx32, leaving everyone a winner, not just MSwin folks capable of deep wizardry in their registries. :) | ->+<- Heather Stern Starshine Technical Services star@starshine.org | Go not to the elves for counsel, for they will say both yes and no. -- J.R.R. Tolkien From owner-lynx-dev@sig.net Tue Apr 6 02:14:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA24474 for ; Tue, 6 Apr 1999 02:14:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06879; Tue, 6 Apr 1999 01:03:25 -0500 (CDT) X-Authentication-Warning: isis.vlsi.com: smtp set sender to using -f Message-ID: <3708F17F.D83A94EB@vlsi.com> Date: Mon, 05 Apr 1999 10:23:11 -0700 From: Sang Kim X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: Re: lynx-dev dumping web pages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 951 Lines: 27 sample html login is http://www.schwab.com/SchwabNOW/Exec/gotrade Once I enter userid and password, somehow it remebers me and allow to navigate protected area. pop up based login example can be found at https://orders7.datek.com Klaus Weide wrote: > > On Thu, 1 Apr 1999, Sang Kim wrote: > > > Is there any way to dump pages which is protected by password? > > I used to use -dump -auth=id:passwd option. But server changed > > its setup to html based login instead of pop up login. > > Any help or insight is greatly appreciated. > > What is "html based login"? Without a concrete example (URL) it's > impossible to answer yes or no. > > Your best bet is to manually do the login, then see the '=' info page, > see whether the login info is somehoe embedded in the URL (or post data). > If yes, you may be able to reproduce this from the command line. > If no, you need to use TRACE (or lynx -trace) to see what's going on. > > Klaus From owner-lynx-dev@sig.net Tue Apr 6 02:14:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA24477 for ; Tue, 6 Apr 1999 02:14:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06800; Tue, 6 Apr 1999 01:02:58 -0500 (CDT) Date: Mon, 5 Apr 1999 22:24:53 +0200 (MET DST) From: Gisle Vanem To: lynx-dev@sig.net Subject: lynx-dev outofmem() allocating memory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 819 Lines: 23 Lynx 2.8.2.dev21, djgpp 2.02 (DOS) version. While building Lynx with a great new mallocing debugger (YAMD), I found that `outotmem()' indirectly tries to allocate another 16kB ! This contradiction happens in libc's `fflush (stdout)'; it doesn't happen while in `fflush(stderr)' (because stdout is line-buffered). It also happens if `printf()' contains a '\n'. I think this behavior is same under other POSIX compliant targets; It makes sense to me that `fflush(stdout)' should flush it's buffer and allocate another. I suggest that when `LYOutOfMemory' is true, flushing should not be done. Alternatively, we should use non-buffered `write()' or print to `stderr'. BTW. YAMD (Yet Another Mallocing Debugger) is for djgpp and Linux. It's available at Gisle V. From owner-lynx-dev@sig.net Tue Apr 6 02:16:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA24491 for ; Tue, 6 Apr 1999 02:16:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06835; Tue, 6 Apr 1999 01:03:06 -0500 (CDT) Message-ID: From: "Neff, Robert" To: "'lynx-dev@sig.net'" Subject: lynx-dev error message Date: Mon, 5 Apr 1999 15:35:56 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 308 Lines: 12 I have just downloaded Lynx and am having trouble getting to work. I have downloaded and unzipped hte file into a file and when I open the application file lynx.exe, I get: 1. Looking up folder first. 2. Then Looking up www.Folder.com, guessing... Any ideas on how I can get this to function. thanks! From owner-lynx-dev@sig.net Tue Apr 6 03:50:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA26655 for ; Tue, 6 Apr 1999 03:50:34 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA06121; Tue, 6 Apr 1999 02:44:36 -0500 (CDT) Date: Tue, 6 Apr 1999 03:43:30 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904060343.AA9480@cas.org> Subject: lynx-dev Re: Mail trouble in Lynx In-Reply-To: <199904051228.IAA1120516@relay.interim.iamworld.net> of Mon, 05 Apr 1999 08:32:22 -0400 To: lynx-dev@sig.net Cc: Jackie Dove Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 440 Lines: 8 I've not, in general, seen a problem using Yahoo and the latest developer releases of lynx 2.8.2. But then, I turn on all the 'accept all cookies' type parameters I can... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 6 06:35:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA31206 for ; Tue, 6 Apr 1999 06:35:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA11763; Tue, 6 Apr 1999 05:27:15 -0500 (CDT) Date: Tue, 6 Apr 1999 19:38:35 +0900 (JST) From: Henry Nelson Message-Id: <199904061038.TAA01419@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev (patch) activate lynx.cfg changes for current lynx session Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 466 Lines: 11 > * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page [...] > occasionally for user mode other than ADVANCED. This is an *experimental* ^^^^^^^^^^^^ What is the configure option or define to NOT compile this in? Why the need for post-launch editing of lynx.cfg? Isn't that the whole purpose of the O)ption menu? (Or is your ultimate plan to get rid of .lynxrc?) __Henry From owner-lynx-dev@sig.net Tue Apr 6 09:06:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA02124 for ; Tue, 6 Apr 1999 09:06:10 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA00966; Tue, 6 Apr 1999 07:56:38 -0500 (CDT) To: lynx-dev@sig.net References: <199904061038.TAA01419@ibr1.irm.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Tue, 6 Apr 1999 16:23:24 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (patch) activate lynx.cfg changes for current lynx session MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1377 Lines: 30 6-Apr-99 19:38 Henry Nelson wrote: >> * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page > [...] >> occasionally for user mode other than ADVANCED. This is an *experimental* > ^^^^^^^^^^^^ > What is the configure option or define to NOT compile this in? NO_CONFIG_INFO will hide all this staff (along with lynx.cfg paths). No separate compile-time option yet (not sure one necessary when a user have write access to lynx.cfg file, and experimental code may became stable in a week or so when we got reports, and things are obvious after all to get rid of unwanted items). > Why the need for post-launch editing of lynx.cfg? Isn't that the > whole purpose of the O)ption menu? (Or is your ultimate plan to > get rid of .lynxrc?) O)ption menu cover a small subset of lynx.cfg repertoire, probably <10%, so sometimes may be a need to change lynx.cfg. This is a step for changing lynx.cfg interactively (I do not plan more steps into that direction) and hope this it more comfortable since you can easily fix a typo etc. when checking a "rendered" version along with testing a changed behaviour (it is very easy to run into a kind of dependency problems when you have an included lynx.cfg files). And you always have an opportunity to not use this feature, of cause. > __Henry From owner-lynx-dev@sig.net Tue Apr 6 15:12:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA13790 for ; Tue, 6 Apr 1999 15:12:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA07015; Tue, 6 Apr 1999 13:48:43 -0500 (CDT) From: mattack@area.com Date: Tue, 6 Apr 1999 11:48:11 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev dumping web pages In-Reply-To: <3708F17F.D83A94EB@vlsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 507 Lines: 16 On Mon, 5 Apr 1999, Sang Kim wrote: >Date: Mon, 05 Apr 1999 10:23:11 -0700 >From: Sang Kim >Reply-To: lynx-dev@sig.net >To: lynx-dev@sig.net >Subject: Re: lynx-dev dumping web pages > >sample html login is >http://www.schwab.com/SchwabNOW/Exec/gotrade >Once I enter userid and password, somehow it remebers me >and allow to navigate protected area. what version of lynx are you using? I haven't been able to use schwab with lynx for a while. It thinks I don't have cookies enabled. From owner-lynx-dev@sig.net Tue Apr 6 15:13:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA13800 for ; Tue, 6 Apr 1999 15:13:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA10011; Tue, 6 Apr 1999 13:56:09 -0500 (CDT) From: www@1Cust222.tnt6.hou3.da.uu.net Date: Tue, 6 Apr 1999 01:48:18 -0500 Message-Id: <199904060648.BAA00562@1Cust222.tnt6.hou3.da.uu.net> To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-URL: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html X-Mailer: Lynx, Version 2.8.1pre.9 Subject: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 174 Lines: 4 could i get some help with viewing graphics with lynx i have tried real hard to find help but have been unable to locate any resources. my email is humphryshere@hotmail.com From owner-lynx-dev@sig.net Tue Apr 6 15:30:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA14435 for ; Tue, 6 Apr 1999 15:30:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA19735; Tue, 6 Apr 1999 14:23:03 -0500 (CDT) From: Philip Webb Message-Id: <199904061922.PAA12296@chass.utoronto.ca> Subject: Re: lynx-dev (patch) activate lynx.cfg changes To: lynx-dev@sig.net Date: Tue, 6 Apr 1999 15:22:47 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 6, 99 04:23:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1208 Lines: 23 990406 Leonid Pauzner commented on his patch for editing lynx.cfg : > No separate compile-time option yet (not sure one necessary > when a user have write access to lynx.cfg file). >> Why the need for post-launch editing of lynx.cfg? >> Isn't that the whole purpose of the O)ption menu? >> Or is your ultimate plan to get rid of .lynxrc? > O)ption menu cover a small subset of lynx.cfg repertoire, > probably < 10 % , so sometimes may be a need to change lynx.cfg. the patch certainly seem useful, but there is a long-term case for simplifying .lynxrc & lynx.cfg , ie to distribute lynx.cfg items among compile-time & on-line actions, so that there are just 2 occasions to make choices: when compiling -- now userdefs.h & --configure-switches -- & when using -- now lynx.cfg , command-line & Options -- via Options or matching command-line switches. Screen manages that way, but it's probably a lot of work to convert Lynx. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 6 18:09:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA19394 for ; Tue, 6 Apr 1999 18:09:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA18705; Tue, 6 Apr 1999 16:58:46 -0500 (CDT) Date: Tue, 6 Apr 1999 19:02:51 -0400 From: Webmaster Jim To: lynx-dev@sig.net Cc: "Neff, Robert" Subject: lynx-dev Re: error message Message-ID: <19990406190251.B343@bcpl.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Neff, Robert on Mon, Apr 05, 1999 at 03:35:56PM -0400 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 748 Lines: 25 On Mon, Apr 05, 1999 at 03:35:56PM -0400, Neff, Robert wrote: > I have just downloaded Lynx and am having trouble getting to work. I have > downloaded and unzipped hte file into a file and when I open the application > file lynx.exe, I get: > > 1. Looking up folder first. > 2. Then Looking up www.Folder.com, guessing... > > Any ideas on how I can get this to function. > > thanks! Try setting up a LYNX.BAT file as per the README.TXT file like this: set term=vt100 set home=d:\programs\lynx set temp=d:\tmp set lynx_cfg=d:\programs\lynx\lynx.cfg d:\programs\lynx\lynx.exe %1 %2 %3 %4 %5 Then invoke the BAT file instead of the EXE file. At a DOS command window, try "LYNX.EXE ." ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Tue Apr 6 18:15:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA19494 for ; Tue, 6 Apr 1999 18:15:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA21625; Tue, 6 Apr 1999 17:07:11 -0500 (CDT) Date: Tue, 6 Apr 1999 19:11:24 -0400 From: Webmaster Jim To: lynx-dev@sig.net Cc: www@1Cust222.tnt6.hou3.da.uu.net, humphryshere@hotmail.com Subject: Re: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html Message-ID: <19990406191124.C343@bcpl.net> References: <199904060648.BAA00562@1Cust222.tnt6.hou3.da.uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904060648.BAA00562@1Cust222.tnt6.hou3.da.uu.net>; from www@1Cust222.tnt6.hou3.da.uu.net on Tue, Apr 06, 1999 at 01:48:18AM -0500 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 583 Lines: 14 On Tue, Apr 06, 1999 at 01:48:18AM -0500, www@1Cust222.tnt6.hou3.da.uu.net wrote: > could i get some help with viewing graphics with lynx i have tried real hard to > find help but have been unable to locate any resources. > my email is humphryshere@hotmail.com (well, your reply address is not) You don't say what platform you're on. For UNIX and VMS, there is help text in the lynx.cfg file as well as in the lynx-dev archives. Look for the string XLOADIMAGE_COMMAND. I don't think Lynx has graphics launchers for Win32. ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Tue Apr 6 18:20:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA19705 for ; Tue, 6 Apr 1999 18:20:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA23160; Tue, 6 Apr 1999 17:11:42 -0500 (CDT) Date: Tue, 6 Apr 1999 19:15:45 -0400 From: Webmaster Jim To: Hiroyuki Kurimoto Cc: lynx-dev@sig.net Subject: lynx-dev Re: We are planning to start mirroring. Message-ID: <19990406191545.A409@bcpl.net> References: <19990303062149.C1396@bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990303062149.C1396@bcpl.net>; from Webmaster Jim on Wed, Mar 03, 1999 at 06:21:49AM -0500 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1051 Lines: 24 On Wed, Mar 03, 1999 at 06:21:49AM -0500, I wrote: > On Wed, Mar 03, 1999 at 02:13:48PM +0900, HiroyukiKurimoto wrote: > > I think the number of lynx user is increasing now. > > So, We are planning to start mirroring lynx-archives. > > If it is possible, please add our site to the MIRRORS. > > Nagoya Syouka University. (Japan) > > http://mirror.nucba.ac.jp/mirror/lynx/ > > ftp://mirror.nucba.ac.jp/mirror/lynx/ > > --------Hiroyuki Kurimoto------------------------------- > > Graduate School of Economics of Osaka University & > > Nagoya University of Commerce and Business Administration > > http://mirror.nucba.ac.jp FTP-Admin > > We are setting up a different master location for anonymous FTP access > to Lynx. Please wait a few days, and check back to see this is working. > Then we will have a more formal list of mirror sites prepared. > Thank you for your offer! Unfortunately, the few days turned into a month. I hope the wait was worth it! Please point your mirror software at our new FTP location: ftp://lynx.isc.org/ Thank you. From owner-lynx-dev@sig.net Tue Apr 6 18:30:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA19979 for ; Tue, 6 Apr 1999 18:30:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA25080; Tue, 6 Apr 1999 17:17:58 -0500 (CDT) Date: Tue, 6 Apr 1999 19:22:21 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Announce: FTP distribution site Message-ID: <19990406192221.A421@bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 754 Lines: 19 Lynx developers: As promised, we have completed setting up a new location for FTP distribution of Lynx after losing the anonymous service at www.slcc.edu. There are a few minor tweaks left to do, but the site is now open. ftp://lynx.isc.org/ ftp://lynx.isc.org/current/index.html The main site is also known as ftp://ftp.us.browser.org/ Please let me know as mirrors are established so I can publish them. Thanks again to Paul Vixie and the Internet Software Consortium! ++++++++++++++++++++++++++++ Marvin the Paranoid Android says: You realise this is going to be a complete waste of time don't you? From owner-lynx-dev@sig.net Tue Apr 6 19:43:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA21786 for ; Tue, 6 Apr 1999 19:43:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA15282; Tue, 6 Apr 1999 18:34:54 -0500 (CDT) Date: Wed, 7 Apr 1999 08:46:09 +0900 (JST) From: Henry Nelson Message-Id: <199904062346.IAA02028@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev (patch) activate lynx.cfg changes for current lynx session Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 339 Lines: 8 > >> * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page > > [...] > > What is the configure option or define to NOT compile this in? > NO_CONFIG_INFO will hide all this staff (along with lynx.cfg paths). ^^^^ Not sure what you mean by "hide"; it's there but you can't see/access it? __Henry From owner-lynx-dev@sig.net Tue Apr 6 20:33:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA23072 for ; Tue, 6 Apr 1999 20:33:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA26158; Tue, 6 Apr 1999 19:26:29 -0500 (CDT) Date: Tue, 6 Apr 1999 17:26:24 -0700 From: Michael Warner To: lynx-dev@sig.net Subject: One-word lynx.cfg nit [lynx-dev] Message-ID: <19990405231751.A7183@unicorn.it.wsu.edu> Mail-Followup-To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 825 Lines: 27 I *think* this is what was intended.... *** lynx.cfg.old Mon Apr 5 22:34:47 1999 --- lynx.cfg Mon Apr 5 22:35:46 1999 *************** *** 1660,1666 **** # If TOGGLE_HELP is mapped, in novice mode the second help menu line # can be toggled among NOVICE_LINE_TWO_A, _B, and _C, as defined in ! # userdefs.h. Otherwise, it will be NOVICE_LINE_TWO. # #KEYMAP:O:TOGGLE_HELP # Show other commands in the novice help menu --- 1660,1666 ---- # If TOGGLE_HELP is mapped, in novice mode the second help menu line # can be toggled among NOVICE_LINE_TWO_A, _B, and _C, as defined in ! # LYMessages_en.h Otherwise, it will be NOVICE_LINE_TWO. # #KEYMAP:O:TOGGLE_HELP # Show other commands in the novice help menu -- Michael Warner "You're cute when you're stupid" -- R.A. Miller From owner-lynx-dev@sig.net Tue Apr 6 20:54:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA23602 for ; Tue, 6 Apr 1999 20:54:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00385; Tue, 6 Apr 1999 19:46:44 -0500 (CDT) From: Philip Webb Message-Id: <199904070046.UAA19747@chass.utoronto.ca> Subject: lynx-dev mirror, mirror ... To: lynx-dev@sig.net Date: Tue, 6 Apr 1999 20:46:41 -0400 (EDT) In-Reply-To: <19990406192221.A421@bcpl.net> from "Webmaster Jim" at Apr 6, 99 07:22:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 728 Lines: 16 990406 Jim Spath announced: > we have completed setting up a new location for FTP distribution of Lynx > There are a few minor tweaks left to do, but the site is now open. > ftp://lynx.isc.org/ > ftp://lynx.isc.org/current/index.html > The main site is also known as ftp://ftp.us.browser.org/ > Please let me know as mirrors are established so I can publish them. where will the list of mirrors be published? and of course, thanx for your labors (smile). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 6 21:35:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA24692 for ; Tue, 6 Apr 1999 21:35:10 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA08693; Tue, 6 Apr 1999 20:26:16 -0500 (CDT) Date: Tue, 6 Apr 1999 21:25:40 -0400 From: Webmaster Jim To: John Freeman Cc: lynx-dev@sig.net Subject: Re: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html Message-ID: <19990406212539.A9945@mail.bcpl.net> References: <19990406235437.99809.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990406235437.99809.qmail@hotmail.com>; from John Freeman on Tue, Apr 06, 1999 at 04:54:36PM -0700 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 883 Lines: 18 On Tue, Apr 06, 1999 at 04:54:36PM -0700, John Freeman wrote: > >> could i get some help with viewing graphics with lynx i have > >> tried real hard to find help but have been unable to locate any > >> resources. my email is humphryshere@hotmail.com > >You don't say what platform you're on. For UNIX and VMS, there is > >help text in the lynx.cfg file as well as in the lynx-dev archives. > >Look for the string XLOADIMAGE_COMMAND. I don't think Lynx has > >graphics launchers for Win32. > Ok well i'm on Unix and i talking about in console not in Xwindows It's not possible to display graphics on UNIX consoles without X. ------ Marvin the Paranoid Android says: You realise this is going to be a complete waste of time don't you? From owner-lynx-dev@sig.net Tue Apr 6 21:43:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA24959 for ; Tue, 6 Apr 1999 21:43:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10925; Tue, 6 Apr 1999 20:36:40 -0500 (CDT) From: dickey@clark.net Message-Id: <199904070136.VAA28168@shell.clark.net> Subject: Re: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html To: lynx-dev@sig.net Date: Tue, 6 Apr 1999 21:36:36 -0400 (EDT) In-Reply-To: <19990406212539.A9945@mail.bcpl.net> from "Webmaster Jim " at Apr 6, 99 09:25:40 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 807 Lines: 22 > On Tue, Apr 06, 1999 at 04:54:36PM -0700, John Freeman wrote: > > >> could i get some help with viewing graphics with lynx i have > > >> tried real hard to find help but have been unable to locate any > > >> resources. my email is humphryshere@hotmail.com > > >You don't say what platform you're on. For UNIX and VMS, there is > > >help text in the lynx.cfg file as well as in the lynx-dev archives. > > >Look for the string XLOADIMAGE_COMMAND. I don't think Lynx has > > >graphics launchers for Win32. > > > Ok well i'm on Unix and i talking about in console not in Xwindows > > It's not possible to display graphics on UNIX consoles without X. sure it is - just not as common. on Linux, he could display using zgv. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 6 21:59:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA25303 for ; Tue, 6 Apr 1999 21:59:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA14578; Tue, 6 Apr 1999 20:53:02 -0500 (CDT) Date: Tue, 6 Apr 1999 21:52:36 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html Message-ID: <19990406215236.A16452@mail.bcpl.net> References: <19990406212539.A9945@mail.bcpl.net> <199904070136.VAA28168@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904070136.VAA28168@shell.clark.net>; from dickey@clark.net on Tue, Apr 06, 1999 at 09:36:36PM -0400 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1324 Lines: 27 On Tue, Apr 06, 1999 at 09:36:36PM -0400, dickey@clark.net wrote: > > On Tue, Apr 06, 1999 at 04:54:36PM -0700, John Freeman wrote: > > > >> could i get some help with viewing graphics with lynx i have > > > >> tried real hard to find help but have been unable to locate any > > > >> resources. my email is humphryshere@hotmail.com > > > >You don't say what platform you're on. For UNIX and VMS, there is > > > >help text in the lynx.cfg file as well as in the lynx-dev archives. > > > >Look for the string XLOADIMAGE_COMMAND. I don't think Lynx has > > > >graphics launchers for Win32. > > > > > Ok well i'm on Unix and i talking about in console not in Xwindows > > > > It's not possible to display graphics on UNIX consoles without X. > sure it is - just not as common. > > on Linux, he could display using zgv. I'm not familiar with that; Lynx has facilites to launch X graphics display programs but no samples I have seen for using any PC-UNIX utilities that might exist. I was referring to traditional video consoles with alphanumeric displays. ------ Marvin the Paranoid Android says: You realise this is going to be a complete waste of time don't you? From owner-lynx-dev@sig.net Wed Apr 7 03:06:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA01201 for ; Wed, 7 Apr 1999 03:06:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA07630; Wed, 7 Apr 1999 01:53:38 -0500 (CDT) From: David Woolley Message-Id: <199904060709.IAA04219@djwhome.demon.co.uk> Subject: Re: lynx-dev outofmem() allocating memory To: lynx-dev@sig.net Date: Tue, 6 Apr 1999 08:09:24 +0100 (BST) In-Reply-To: from "Gisle Vanem" at Apr 5, 99 10:24:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 488 Lines: 10 > I think this behavior is same under other POSIX compliant targets; > It makes sense to me that `fflush(stdout)' should flush it's buffer > and allocate another. I'd consider it a bug in the library, especially allocating so much more than it needs. The one caveat is that, given that you are allowed to supply your own buffer until the first write, it might be reasonable for it to allocate its buffer on the first write. I guess the defence would be to allocate the buffer oneself. From owner-lynx-dev@sig.net Wed Apr 7 04:48:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA04376 for ; Wed, 7 Apr 1999 04:48:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA17522; Wed, 7 Apr 1999 03:31:51 -0500 (CDT) To: lynx-dev@sig.net References: <19990406190251.B343@bcpl.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 12:26:24 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: error message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 862 Lines: 28 6-Apr-99 19:02 Webmaster Jim wrote: > On Mon, Apr 05, 1999 at 03:35:56PM -0400, Neff, Robert wrote: >> I have just downloaded Lynx and am having trouble getting to work. I have >> downloaded and unzipped hte file into a file and when I open the application >> file lynx.exe, I get: >> >> 1. Looking up folder first. >> 2. Then Looking up www.Folder.com, guessing... >> >> Any ideas on how I can get this to function. >> >> thanks! > Try setting up a LYNX.BAT file as per the README.TXT file like this: > set term=vt100 > set home=d:\programs\lynx > set temp=d:\tmp > set lynx_cfg=d:\programs\lynx\lynx.cfg > d:\programs\lynx\lynx.exe %1 %2 %3 %4 %5 > Then invoke the BAT file instead of the EXE file. At a DOS command > window, try "LYNX.EXE ." ^^^^^^^^ perhaps LYNX.BAT here > ++++++++++++++++++++++++++++ > Marvin the Paranoid Android. From owner-lynx-dev@sig.net Wed Apr 7 04:50:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA04387 for ; Wed, 7 Apr 1999 04:50:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA17535; Wed, 7 Apr 1999 03:31:54 -0500 (CDT) To: lynx-dev@sig.net References: <199904062346.IAA02028@ibr1.irm.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 12:13:26 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (patch) activate lynx.cfg changes for current lynx session MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 954 Lines: 21 7-Apr-99 08:46 Henry Nelson wrote: >> >> * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page >> > [...] >> > What is the configure option or define to NOT compile this in? >> NO_CONFIG_INFO will hide all this staff (along with lynx.cfg paths). > ^^^^ > Not sure what you mean by "hide"; it's there but you can't see/access it? Sorry, this is a compile-time flag, it means the staff will not be compiled into. From the other hand, without this flag you can disable the access to the feature with run-time LYRestricted variable (normally associated with any restriction parsed from command line). We could work out some startup conditions when the feature should be accessible run-time: say, check whether no restrictions set and we have write access to the primary lynx.cfg (or one of the included lynx.cfg at least), perhaps something else. This is up to decisions, not a technical problem. > __Henry From owner-lynx-dev@sig.net Wed Apr 7 05:17:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA05044 for ; Wed, 7 Apr 1999 05:17:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA20791; Wed, 7 Apr 1999 04:05:46 -0500 (CDT) From: dickey@clark.net Message-Id: <199904070905.FAA19804@shell.clark.net> Subject: Re: http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 05:05:43 -0400 (EDT) In-Reply-To: <19990406215236.A16452@mail.bcpl.net> from "Webmaster Jim " at Apr 6, 99 09:52:36 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 920 Lines: 24 > > On Tue, Apr 06, 1999 at 09:36:36PM -0400, dickey@clark.net wrote: > > > On Tue, Apr 06, 1999 at 04:54:36PM -0700, John Freeman wrote: > > > > >> could i get some help with viewing graphics with lynx i have ... > > > > Ok well i'm on Unix and i talking about in console not in Xwindows > > > > > > It's not possible to display graphics on UNIX consoles without X. > > sure it is - just not as common. > > > > on Linux, he could display using zgv. > > I'm not familiar with that; Lynx has facilites to launch X graphics > display programs but no samples I have seen for using any PC-UNIX > utilities that might exist. I was referring to traditional video > consoles with alphanumeric displays. I only see "viewing graphics". zgv uses svgalib. I'm aware of (but not familiar with) similar programs on other UNIX consoles. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 05:25:10 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA05075 for ; Wed, 7 Apr 1999 05:25:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA20632; Wed, 7 Apr 1999 04:04:01 -0500 (CDT) From: dickey@clark.net Message-Id: <199904070903.FAA19610@shell.clark.net> Subject: Re: lynx-dev outofmem() allocating memory To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 05:03:58 -0400 (EDT) In-Reply-To: <199904060709.IAA04219@djwhome.demon.co.uk> from "David Woolley " at Apr 6, 99 08:09:24 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 692 Lines: 22 > > > I think this behavior is same under other POSIX compliant targets; > > It makes sense to me that `fflush(stdout)' should flush it's buffer > > and allocate another. > > I'd consider it a bug in the library, especially allocating so much > more than it needs. The one caveat is that, given that you are allowed > to supply your own buffer until the first write, it might be reasonable > for it to allocate its buffer on the first write. it's an implementation detail left unspecified by POSIX, which does not focus on stdio. > I guess the defence would be to allocate the buffer oneself. you can't -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 05:46:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA05475 for ; Wed, 7 Apr 1999 05:46:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA13139; Wed, 7 Apr 1999 04:26:30 -0500 (CDT) To: lynx-dev@sig.net References: <19990403094706.C20043@netcom2.netcom.com> <9903311052.AA26545@cas.org> Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 13:21:46 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev LYNX: reverse-search MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 481 Lines: 12 It was discussed recently about adding a revere search functionality, one of the main problems was a lack of hot-key space since most of the keys are already used by lynx. Currently we have 'n' key for forward next search. It would be logical enough to use capital "N" for backward search (something similar we have with Tab / Shift-Tab for forward/backward "fastnextlink" recently implemented, BTW, Tab/Shift-Tab not currently added to lynx_help/keystrokes/...). Any ideas? From owner-lynx-dev@sig.net Wed Apr 7 06:02:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA05952 for ; Wed, 7 Apr 1999 06:01:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA15015; Wed, 7 Apr 1999 04:48:11 -0500 (CDT) Date: Wed, 7 Apr 1999 04:48:07 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: graphics viewers (was http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html) In-Reply-To: <199904070905.FAA19804@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1827 Lines: 45 > > > on Linux, he could display using zgv. > > > > I'm not familiar with that; Lynx has facilites to launch X graphics > > display programs but no samples I have seen for using any PC-UNIX > > utilities that might exist. I was referring to traditional video > > consoles with alphanumeric displays. > On Wed, 7 Apr 1999 dickey@clark.net wrote: > I only see "viewing graphics". zgv uses svgalib. I'm aware of (but not > familiar with) similar programs on other UNIX consoles. See also the AA-Project at Excerpts from ANNOUNCE and README files: ----------- snip ----------- Why such library? ================= I vote for simplicity. There are many problems of various kinds with video cards, low frequency monitors, crashing graphical apps... AA-lib IS the solution. It works on a terminal of any kind, it is fast and portable, it gives to you standard API. It gives to your old hardware more power! Supports: dos (VGA + MDA), stdio, curses, slang, X11, gpm, linux-console, OS/2 What does this software do then ? ================================= AA-lib is a low level gfx library just as many other libraries are. The main difference is that AA-lib does not require graphics device. In fact, there is no graphical output possible. AA-lib replaces those old-fashioned output methods with powerful ascii-art renderer. [...] ----------- snip ----------- I have tried it (the Debian packages); aview/asciiview allows to view graphics files (various formats; depends on converters like netpbm) without using graphics mode, it should work on vt100 terminals etc. As you can imagine, the resolution is limited; it may or may not give a useful display for a given image file. But it's fun to play around with. One can zoom and pan, change contrast, brightness, gamma,... Klaus From owner-lynx-dev@sig.net Wed Apr 7 06:34:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA06676 for ; Wed, 7 Apr 1999 06:34:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA17961; Wed, 7 Apr 1999 05:20:53 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 14:18:25 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev makefile rules MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1104 Lines: 26 While building recent lynx without configure options on LINUX I got these output on the screen (below). My understandig was the default configuration does not include gettext() support so "intl" directory and LOCALEDIR should be irrelevant, isn't it? gcc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../../intl -I../../.. -I../ ../../src -I../../../intl -I../../../WWW/Library/Implementation -O2 -DLINUX - I../../../WWW/Library/Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../W WW/Library/Implementation/HTGopher.c etc. gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/home/pauzner/.lynx/share/locale\" -I. -I.. - Ichrtrans -I./chrtrans -I.. -I../intl -I../src -I../WWW/Library/Implementation -O2 -DLINUX -c ./LYJump.c gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/home/pauzner/.lynx/share/locale\" -I. -I.. - Ichrtrans -I./chrtrans -I.. -I../intl -I../src -I../WWW/Library/Implementation -O2 -DLINUX -c ./LYList.c etc. In fact, I use few configure options but they are far from gettext() interest: ./configure --prefix=~/.lynx --exec-prefix=~/.lynx --enable-persistent-cookies --enable-nsl-fork From owner-lynx-dev@sig.net Wed Apr 7 06:56:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA07099 for ; Wed, 7 Apr 1999 06:56:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA19977; Wed, 7 Apr 1999 05:42:04 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 14:38:25 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev (more patch) minore cleanup MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 15077 Lines: 523 >From LYMain.c : static int cache_fun ARGS3( Parse_Args_Type*, p GCC_UNUSED, char **, argv GCC_UNUSED, char *, next_arg) What all this GCC_UNUSED staff for? Seems command-line options may have one argument only or none so *p and **argv really unused here. The patch attached. Also minore (and obvious) fixes for src/LYReadCFG.c and WWW/... /HTFile.c over all my previous patches. diff -u old/lymain.c ./lymain.c --- old/lymain.c Mon Apr 5 23:55:22 1999 +++ ./lymain.c Tue Apr 6 03:35:06 1999 @@ -1875,7 +1875,7 @@ */ struct parse_args_type; -typedef int (*ParseFunc) PARAMS((struct parse_args_type *, char **, char *)); +typedef int (*ParseFunc) PARAMS((char *)); typedef union { BOOLEAN * set_value; @@ -1968,9 +1968,7 @@ } /* -anonymous */ -static int anonymous_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int anonymous_fun ARGS1( char *, next_arg GCC_UNUSED) { /* @@ -1985,9 +1983,7 @@ } /* -assume_charset */ -static int assume_charset_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int assume_charset_fun ARGS1( char *, next_arg) { UCLYhndl_for_unspec = safeUCGetLYhndl_byMIME(next_arg); @@ -2001,9 +1997,7 @@ } /* -assume_local_charset */ -static int assume_local_charset_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int assume_local_charset_fun ARGS1( char *, next_arg) { UCLYhndl_HTFile_for_unspec = safeUCGetLYhndl_byMIME(next_arg); @@ -2011,9 +2005,7 @@ } /* -assume_unrec_charset */ -static int assume_unrec_charset_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int assume_unrec_charset_fun ARGS1( char *, next_arg) { UCLYhndl_for_unrec = safeUCGetLYhndl_byMIME(next_arg); @@ -2021,9 +2013,7 @@ } /* -auth */ -static int auth_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int auth_fun ARGS1( char *, next_arg) { parse_authentication(next_arg, authentication_info); @@ -2031,9 +2021,7 @@ } /* -base */ -static int base_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int base_fun ARGS1( char *, next_arg GCC_UNUSED) { /* @@ -2053,9 +2041,7 @@ #ifdef USE_SLANG /* -blink */ -static int blink_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int blink_fun ARGS1( char *, next_arg GCC_UNUSED) { Lynx_Color_Flags |= SL_LYNX_USE_BLINK; @@ -2064,9 +2050,7 @@ #endif /* -cache */ -static int cache_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int cache_fun ARGS1( char *, next_arg) { if (next_arg != 0) @@ -2080,9 +2064,7 @@ } /* -child */ -static int child_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int child_fun ARGS1( char *, next_arg GCC_UNUSED) { child_lynx = TRUE; @@ -2092,9 +2074,7 @@ #ifdef USE_SLANG /* -color */ -static int color_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int color_fun ARGS1( char *, next_arg GCC_UNUSED) { Lynx_Color_Flags |= SL_LYNX_USE_COLOR; @@ -2107,9 +2087,7 @@ #endif /* -crawl */ -static int crawl_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int crawl_fun ARGS1( char *, next_arg GCC_UNUSED) { crawl = TRUE; @@ -2118,9 +2096,7 @@ } /* -display */ -static int display_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int display_fun ARGS1( char *, next_arg) { if (next_arg != 0) { @@ -2133,9 +2109,7 @@ } /* -dump */ -static int dump_output_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int dump_output_fun ARGS1( char *, next_arg GCC_UNUSED) { dump_output_immediately = TRUE; @@ -2144,9 +2118,7 @@ } /* -editor */ -static int editor_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int editor_fun ARGS1( char *, next_arg) { if (next_arg != 0) @@ -2156,9 +2128,7 @@ } /* -error_file */ -static int error_file_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int error_file_fun ARGS1( char *, next_arg) { /* @@ -2172,9 +2142,7 @@ #if defined(EXEC_LINKS) || defined(EXEC_SCRIPTS) /* -exec */ -static int exec_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int exec_fun ARGS1( char *, next_arg GCC_UNUSED) { #ifndef NEVER_ALLOW_REMOTE_EXEC @@ -2187,9 +2155,7 @@ #endif /* -get_data */ -static int get_data_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int get_data_fun ARGS1( char *, next_arg GCC_UNUSED) { /* @@ -2232,9 +2198,7 @@ } /* -help */ -static int help_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int help_fun ARGS1( char *, next_arg GCC_UNUSED) { print_help_and_exit (0); @@ -2242,9 +2206,7 @@ } /* -hiddenlinks */ -static int hiddenlinks_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int hiddenlinks_fun ARGS1( char *, next_arg) { if (next_arg != 0) { @@ -2264,9 +2226,7 @@ } /* -homepage */ -static int homepage_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int homepage_fun ARGS1( char *, next_arg) { if (next_arg != 0) { @@ -2277,9 +2237,7 @@ } /* -mime_header */ -static int mime_header_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int mime_header_fun ARGS1( char *, next_arg GCC_UNUSED) { /* @@ -2295,9 +2253,7 @@ #ifndef DISABLE_NEWS /* -newschunksize */ -static int newschunksize_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int newschunksize_fun ARGS1( char *, next_arg) { if (next_arg != 0) { @@ -2313,9 +2269,7 @@ } /* -newsmaxchunk */ -static int newsmaxchunk_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int newsmaxchunk_fun ARGS1( char *, next_arg) { if (next_arg) { @@ -2332,9 +2286,7 @@ #endif /* not DISABLE_NEWS */ /* -nobrowse */ -static int nobrowse_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int nobrowse_fun ARGS1( char *, next_arg GCC_UNUSED) { HTDirAccess = HT_DIR_FORBID; @@ -2342,9 +2294,7 @@ } /* -nocolor */ -static int nocolor_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int nocolor_fun ARGS1( char *, next_arg GCC_UNUSED) { LYShowColor = SHOW_COLOR_NEVER; @@ -2356,9 +2306,7 @@ } /* -nopause */ -static int nopause_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int nopause_fun ARGS1( char *, next_arg GCC_UNUSED) { InfoSecs = 0; @@ -2368,9 +2316,7 @@ } /* -pauth */ -static int pauth_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int pauth_fun ARGS1( char *, next_arg) { parse_authentication(next_arg, proxyauth_info); @@ -2378,9 +2324,7 @@ } /* -post_data */ -static int post_data_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int post_data_fun ARGS1( char *, next_arg GCC_UNUSED) { /* @@ -2421,9 +2365,7 @@ } /* -restrictions */ -static int restrictions_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int restrictions_fun ARGS1( char *, next_arg) { static CONST char *Usage[] = { @@ -2518,9 +2460,7 @@ } /* -selective */ -static int selective_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int selective_fun ARGS1( char *, next_arg GCC_UNUSED) { HTDirAccess = HT_DIR_SELECTIVE; @@ -2528,9 +2468,7 @@ } /* -source */ -static int source_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int source_fun ARGS1( char *, next_arg GCC_UNUSED) { dump_output_immediately = TRUE; @@ -2541,9 +2479,7 @@ } /* -traversal */ -static int traversal_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int traversal_fun ARGS1( char *, next_arg GCC_UNUSED) { traversal = TRUE; @@ -2557,9 +2493,7 @@ } /* -version */ -static int version_fun ARGS3( - Parse_Args_Type *, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int version_fun ARGS1( char *, next_arg GCC_UNUSED) { SetOutputMode( O_TEXT ); @@ -2587,9 +2521,7 @@ } /* -width */ -static int width_fun ARGS3( - Parse_Args_Type*, p GCC_UNUSED, - char **, argv GCC_UNUSED, +static int width_fun ARGS1( char *, next_arg) { if (next_arg != 0) { @@ -3277,7 +3209,7 @@ case FUNCTION_ARG: fun = q->fun_value; if (0 != fun) { - if (-1 == (*fun) (p, argv, next_arg)) { + if (-1 == (*fun) (next_arg)) { } } break; diff -u old/lyreadcf.c ./lyreadcf.c --- old/lyreadcf.c Mon Apr 5 23:36:06 1999 +++ ./lyreadcf.c Tue Apr 6 15:42:40 1999 @@ -1372,7 +1372,7 @@ PUBLIC int lynx_cfg_infopage ARGS1( document *, newdoc) { - char tempfile[LY_MAXPATH]; + static char tempfile[LY_MAXPATH]; static char *local_url; /* static! */ DocAddress WWWDoc; /* need on exit */ char *temp = 0; @@ -1421,15 +1421,15 @@ return(NOT_FOUND); - /* FIXME: probably remove obsolete temp file just now (before exit)? */ - - /* now set up the flag and fall down to create a new LYNXCFG:/ page */ + /* now set up the flag and fall down to create a new LYNXCFG:/ page */ local_url = 0; /* see below */ } #endif /* !NO_CONFIG_INFO */ if (local_url == 0) { + + LYRemoveTemp(tempfile); if ((fp0 = LYOpenTemp(tempfile, HTML_SUFFIX, "w")) == NULL) { HTAlert(CANNOT_OPEN_TEMP); return(NOT_FOUND); diff -u old/htfile.c ./htfile.c --- old/htfile.c Mon Apr 5 16:05:18 1999 +++ ./htfile.c Tue Apr 6 15:31:44 1999 @@ -1462,6 +1462,7 @@ PUTS("/"); } END(HTML_A); + PUTS("\n"); } #endif /* !NO_PARENT_DIR_REFERENCE */ @@ -1692,11 +1693,15 @@ if (state != test) { #ifndef LONG_LIST if (dir_list_style == FILES_FIRST) { - if (state == 'F') + if (state == 'F') { END(HTML_DIR); + PUTS("\n"); + } } else if (dir_list_style != MIXED_STYLE) - if (state == 'D') + if (state == 'D') { END(HTML_DIR); + PUTS("\n"); + } #endif /* !LONG_LIST */ state = (*(char *)(HTBTree_object(next_element)) @@ -1710,16 +1715,20 @@ END(HTML_EM); } END(HTML_H2); + PUTS("\n"); #ifndef LONG_LIST START(HTML_DIR); + PUTS("\n"); #endif /* !LONG_LIST */ } #else if (state != *(char *)(HTBTree_object( next_element))) { #ifndef LONG_LIST - if (state == 'D') + if (state == 'D') { END(HTML_DIR); + PUTS("\n"); + } #endif /* !LONG_LIST */ state = (*(char *)(HTBTree_object(next_element)) @@ -1731,8 +1740,10 @@ : LABEL_FILES); END(HTML_EM); END(HTML_H2); + PUTS("\n"); #ifndef LONG_LIST START(HTML_DIR); + PUTS("\n"); #endif /* !LONG_LIST */ } #endif /* DIRED_SUPPORT */ @@ -1755,6 +1766,7 @@ FREE(file_extra); } MAYBE_END(HTML_LI); + PUTS("\n"); #endif /* LONG_LIST */ next_element = HTBTree_next(bt, next_element); @@ -1789,7 +1801,7 @@ END(HTML_DIR); #endif /* !LONG_LIST */ } - } /* printing out the tree in order done */ + } /* end printing out the tree in order */ closedir(dp); FREE(logical); From owner-lynx-dev@sig.net Wed Apr 7 07:19:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA07722 for ; Wed, 7 Apr 1999 07:19:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA22201; Wed, 7 Apr 1999 06:03:26 -0500 (CDT) Date: Wed, 7 Apr 1999 06:03:22 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev if lynx.cfg is unavailable In-Reply-To: <19990401003124.B4419@jpradley.jpr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4076 Lines: 81 On Thu, 1 Apr 1999, Jean-Pierre Radley wrote: > Klaus Weide averred (on Wed, Mar 31, 1999 at 07:14:12PM -0600): > | > | It doesn't need it in order to run somehow. It needs it in order to > | know how it is meant to run. It doesn't know whether 'lynx.cfg not > | available' is an acceptable condition or not, so it acts according > | to 'better safe than sorry'. > > This is nonsense. The manual should say, and lynx should act as if the > manual said: > Lynx is compiled to use settings, options, and URLs defined > in certain source code files. Many of those settings can be > overridden in an optional lynx.cfg file, which must be in a > directory defined in those source code files (usually it would > be /usr/local/etc/lynx.cfg). How does that make what I wrote "nonsense"? The manual does not say what you think it should say, and lynx doesn't act as you think it should. Obviously your ideas of what lynx should do differ from what it does, and, assuming this isn't all just accidental, from what previous developers of the code have thought. I was trying to give a reason why things are as they are. You are stating how things should be (without giving any reasons). Different thing. > [If the man pages were written like those of smail, then that last > parenthetical remark wouldn't be necessary, since the man page would > carry the precise location where a lynx.cfg file would exist.] > > IOW, there is nothing "unsafe" to be "sorry" about if lynx uses the > settings used at compile-time; there is nothing "unsafe" to be "sorry" > about if there's no lynx.cfg file to override any of those defaults. There may well be nothing unsafe to be sorry about in your situation, the way you have configured Lynx before compilation and have set it up in your lynx.cfg. That doesn't mean it has to apply to everyone. You have ignored (and snipped) the part of my message that dealt with an unsafe situation. Since for this reason the message isn't archived at www.flora.org, I repeat the relevant part at the end. More generally, yes there's nothing to be sorry about if lynx uses the compiled-in settings AND it is intended to use them. There would be something to be sorry about if lynx used the compiled-in settings when it's not supposed to (they are supposed to be overridden by lynx.cfg), by accident. So far this isn't different from any program that uses any kind of configuration file. I would not argue that any such program should refuse to run if the config file is missing. But lynx's configuration file can be used to impose restrictions beyond the compiled-in settings. Running lynx at all without these restrictions may be unacceptable. By the way, these restrictions don't just apply to multiuser sites or sites with guest accounts. Some of them are needed to protect a single user. Take TRUSTED_LYNXCGI. I may have compiled with LYNXCGI_LINKS since I want lynxcgi sometimes. But I want TRUSTED_LYNXCGI:none (or something a bit less restrictive) during normal browsing, or someone might sneak in a link that would 'accidentally' erase all my files when I follow it. Klaus ---------- excerpt from previous message --------- > > That's in addition to considerations for anonymous or otherwise restricted > > accounts. > > I don't see any interaction with these. If your anonymous/restricted > user can get out to a prompt and run arbitrary binaries (such as a Lynx > which has been compiled for a lynx.cfg path other than the one your > system uses), he's already busted out of his sandbox. If the anonymous/restricted user can not get out to a prompt, but lynx at startup cannot find the lynx.cfg at the configured location and then proceeds as if it had found an empty lynx.cfg file, the anonymous/restricted will get all those permissions that lynx.cfg, if found, would have turned off (unless they are irrevocably turned off already at compile time). Not finding a vital lynx.cfg could be caused by various things, among them admin error, unmounted filesystem, possibly even temporarily unavailable filesystem. From owner-lynx-dev@sig.net Wed Apr 7 07:31:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA07937 for ; Wed, 7 Apr 1999 07:31:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA23716; Wed, 7 Apr 1999 06:17:51 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071117.HAA01863@shell.clark.net> Subject: Re: lynx-dev LYNX: reverse-search To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 07:17:48 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 7, 99 01:21:46 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 696 Lines: 23 > > It was discussed recently about adding a revere search functionality, > one of the main problems was a lack of hot-key space since most of the > keys are already used by lynx. > > Currently we have 'n' key for forward next search. > It would be logical enough to use capital "N" for backward search > (something similar we have with Tab / Shift-Tab > for forward/backward "fastnextlink" recently implemented, > BTW, Tab/Shift-Tab not currently added to lynx_help/keystrokes/...). shift-tab is not generally available (it's not in xterm or rxvt, though I've thought about adding it) > Any ideas? > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 07:43:10 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA08163 for ; Wed, 7 Apr 1999 07:43:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA23891; Wed, 7 Apr 1999 06:19:27 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071119.HAA01966@shell.clark.net> Subject: Re: graphics viewers (was http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html) To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 07:19:24 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 7, 99 04:48:07 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 774 Lines: 21 > > > > > on Linux, he could display using zgv. > > > > > > I'm not familiar with that; Lynx has facilites to launch X graphics > > > display programs but no samples I have seen for using any PC-UNIX > > > utilities that might exist. I was referring to traditional video > > > consoles with alphanumeric displays. > > > On Wed, 7 Apr 1999 dickey@clark.net wrote: > > I only see "viewing graphics". zgv uses svgalib. I'm aware of (but not > > familiar with) similar programs on other UNIX consoles. > > See also the AA-Project at I'm aware of that (iirc, I was not able to make it work properly - but I'll check again, since it uses ncurses more/less) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 07:50:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA08364 for ; Wed, 7 Apr 1999 07:50:57 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA24518; Wed, 7 Apr 1999 06:24:46 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071124.HAA02804@shell.clark.net> Subject: Re: lynx-dev (more patch) minore cleanup To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 07:24:36 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 7, 99 02:38:25 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 16937 Lines: 535 > >From LYMain.c : > static int cache_fun ARGS3( > Parse_Args_Type*, p GCC_UNUSED, > char **, argv GCC_UNUSED, > char *, next_arg) > > What all this GCC_UNUSED staff for? it's because the functions all have the same number of parameters (unless you've rewritten them). if you mix pointers, it won't compile on some platforms (gcc is too forgiving to qualify here as an ANSI compiler). > Seems command-line options may have one argument only or none > so *p and **argv really unused here. The patch attached. > > Also minore (and obvious) fixes for src/LYReadCFG.c and WWW/... /HTFile.c > over all my previous patches. > > > diff -u old/lymain.c ./lymain.c > --- old/lymain.c Mon Apr 5 23:55:22 1999 > +++ ./lymain.c Tue Apr 6 03:35:06 1999 > @@ -1875,7 +1875,7 @@ > */ > > struct parse_args_type; > -typedef int (*ParseFunc) PARAMS((struct parse_args_type *, char **, char *)); > +typedef int (*ParseFunc) PARAMS((char *)); > > typedef union { > BOOLEAN * set_value; > @@ -1968,9 +1968,7 @@ > } > > /* -anonymous */ > -static int anonymous_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int anonymous_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > /* > @@ -1985,9 +1983,7 @@ > } > > /* -assume_charset */ > -static int assume_charset_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int assume_charset_fun ARGS1( > char *, next_arg) > { > UCLYhndl_for_unspec = safeUCGetLYhndl_byMIME(next_arg); > @@ -2001,9 +1997,7 @@ > } > > /* -assume_local_charset */ > -static int assume_local_charset_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int assume_local_charset_fun ARGS1( > char *, next_arg) > { > UCLYhndl_HTFile_for_unspec = safeUCGetLYhndl_byMIME(next_arg); > @@ -2011,9 +2005,7 @@ > } > > /* -assume_unrec_charset */ > -static int assume_unrec_charset_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int assume_unrec_charset_fun ARGS1( > char *, next_arg) > { > UCLYhndl_for_unrec = safeUCGetLYhndl_byMIME(next_arg); > @@ -2021,9 +2013,7 @@ > } > > /* -auth */ > -static int auth_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int auth_fun ARGS1( > char *, next_arg) > { > parse_authentication(next_arg, authentication_info); > @@ -2031,9 +2021,7 @@ > } > > /* -base */ > -static int base_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int base_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > /* > @@ -2053,9 +2041,7 @@ > > #ifdef USE_SLANG > /* -blink */ > -static int blink_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int blink_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > Lynx_Color_Flags |= SL_LYNX_USE_BLINK; > @@ -2064,9 +2050,7 @@ > #endif > > /* -cache */ > -static int cache_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int cache_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) > @@ -2080,9 +2064,7 @@ > } > > /* -child */ > -static int child_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int child_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > child_lynx = TRUE; > @@ -2092,9 +2074,7 @@ > > #ifdef USE_SLANG > /* -color */ > -static int color_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int color_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > Lynx_Color_Flags |= SL_LYNX_USE_COLOR; > @@ -2107,9 +2087,7 @@ > #endif > > /* -crawl */ > -static int crawl_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int crawl_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > crawl = TRUE; > @@ -2118,9 +2096,7 @@ > } > > /* -display */ > -static int display_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int display_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) { > @@ -2133,9 +2109,7 @@ > } > > /* -dump */ > -static int dump_output_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int dump_output_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > dump_output_immediately = TRUE; > @@ -2144,9 +2118,7 @@ > } > > /* -editor */ > -static int editor_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int editor_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) > @@ -2156,9 +2128,7 @@ > } > > /* -error_file */ > -static int error_file_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int error_file_fun ARGS1( > char *, next_arg) > { > /* > @@ -2172,9 +2142,7 @@ > > #if defined(EXEC_LINKS) || defined(EXEC_SCRIPTS) > /* -exec */ > -static int exec_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int exec_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > #ifndef NEVER_ALLOW_REMOTE_EXEC > @@ -2187,9 +2155,7 @@ > #endif > > /* -get_data */ > -static int get_data_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int get_data_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > /* > @@ -2232,9 +2198,7 @@ > } > > /* -help */ > -static int help_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int help_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > print_help_and_exit (0); > @@ -2242,9 +2206,7 @@ > } > > /* -hiddenlinks */ > -static int hiddenlinks_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int hiddenlinks_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) { > @@ -2264,9 +2226,7 @@ > } > > /* -homepage */ > -static int homepage_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int homepage_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) { > @@ -2277,9 +2237,7 @@ > } > > /* -mime_header */ > -static int mime_header_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int mime_header_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > /* > @@ -2295,9 +2253,7 @@ > > #ifndef DISABLE_NEWS > /* -newschunksize */ > -static int newschunksize_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int newschunksize_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) { > @@ -2313,9 +2269,7 @@ > } > > /* -newsmaxchunk */ > -static int newsmaxchunk_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int newsmaxchunk_fun ARGS1( > char *, next_arg) > { > if (next_arg) { > @@ -2332,9 +2286,7 @@ > #endif /* not DISABLE_NEWS */ > > /* -nobrowse */ > -static int nobrowse_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int nobrowse_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > HTDirAccess = HT_DIR_FORBID; > @@ -2342,9 +2294,7 @@ > } > > /* -nocolor */ > -static int nocolor_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int nocolor_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > LYShowColor = SHOW_COLOR_NEVER; > @@ -2356,9 +2306,7 @@ > } > > /* -nopause */ > -static int nopause_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int nopause_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > InfoSecs = 0; > @@ -2368,9 +2316,7 @@ > } > > /* -pauth */ > -static int pauth_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int pauth_fun ARGS1( > char *, next_arg) > { > parse_authentication(next_arg, proxyauth_info); > @@ -2378,9 +2324,7 @@ > } > > /* -post_data */ > -static int post_data_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int post_data_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > /* > @@ -2421,9 +2365,7 @@ > } > > /* -restrictions */ > -static int restrictions_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int restrictions_fun ARGS1( > char *, next_arg) > { > static CONST char *Usage[] = { > @@ -2518,9 +2460,7 @@ > } > > /* -selective */ > -static int selective_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int selective_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > HTDirAccess = HT_DIR_SELECTIVE; > @@ -2528,9 +2468,7 @@ > } > > /* -source */ > -static int source_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int source_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > dump_output_immediately = TRUE; > @@ -2541,9 +2479,7 @@ > } > > /* -traversal */ > -static int traversal_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int traversal_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > traversal = TRUE; > @@ -2557,9 +2493,7 @@ > } > > /* -version */ > -static int version_fun ARGS3( > - Parse_Args_Type *, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int version_fun ARGS1( > char *, next_arg GCC_UNUSED) > { > SetOutputMode( O_TEXT ); > @@ -2587,9 +2521,7 @@ > } > > /* -width */ > -static int width_fun ARGS3( > - Parse_Args_Type*, p GCC_UNUSED, > - char **, argv GCC_UNUSED, > +static int width_fun ARGS1( > char *, next_arg) > { > if (next_arg != 0) { > @@ -3277,7 +3209,7 @@ > case FUNCTION_ARG: > fun = q->fun_value; > if (0 != fun) { > - if (-1 == (*fun) (p, argv, next_arg)) { > + if (-1 == (*fun) (next_arg)) { > } > } > break; > > diff -u old/lyreadcf.c ./lyreadcf.c > --- old/lyreadcf.c Mon Apr 5 23:36:06 1999 > +++ ./lyreadcf.c Tue Apr 6 15:42:40 1999 > @@ -1372,7 +1372,7 @@ > PUBLIC int lynx_cfg_infopage ARGS1( > document *, newdoc) > { > - char tempfile[LY_MAXPATH]; > + static char tempfile[LY_MAXPATH]; > static char *local_url; /* static! */ > DocAddress WWWDoc; /* need on exit */ > char *temp = 0; > @@ -1421,15 +1421,15 @@ > return(NOT_FOUND); > > > - /* FIXME: probably remove obsolete temp file just now (before exit)? */ > - > - /* now set up the flag and fall down to create a new LYNXCFG:/ page */ > + /* now set up the flag and fall down to create a new LYNXCFG:/ page */ > local_url = 0; /* see below */ > } > #endif /* !NO_CONFIG_INFO */ > > > if (local_url == 0) { > + > + LYRemoveTemp(tempfile); > if ((fp0 = LYOpenTemp(tempfile, HTML_SUFFIX, "w")) == NULL) { > HTAlert(CANNOT_OPEN_TEMP); > return(NOT_FOUND); > > > diff -u old/htfile.c ./htfile.c > --- old/htfile.c Mon Apr 5 16:05:18 1999 > +++ ./htfile.c Tue Apr 6 15:31:44 1999 > @@ -1462,6 +1462,7 @@ > PUTS("/"); > } > END(HTML_A); > + PUTS("\n"); > } > #endif /* !NO_PARENT_DIR_REFERENCE */ > > @@ -1692,11 +1693,15 @@ > if (state != test) { > #ifndef LONG_LIST > if (dir_list_style == FILES_FIRST) { > - if (state == 'F') > + if (state == 'F') { > END(HTML_DIR); > + PUTS("\n"); > + } > } else if (dir_list_style != MIXED_STYLE) > - if (state == 'D') > + if (state == 'D') { > END(HTML_DIR); > + PUTS("\n"); > + } > #endif /* !LONG_LIST */ > state = > (*(char *)(HTBTree_object(next_element)) > @@ -1710,16 +1715,20 @@ > END(HTML_EM); > } > END(HTML_H2); > + PUTS("\n"); > #ifndef LONG_LIST > START(HTML_DIR); > + PUTS("\n"); > #endif /* !LONG_LIST */ > } > #else > if (state != *(char *)(HTBTree_object( > next_element))) { > #ifndef LONG_LIST > - if (state == 'D') > + if (state == 'D') { > END(HTML_DIR); > + PUTS("\n"); > + } > #endif /* !LONG_LIST */ > state = > (*(char *)(HTBTree_object(next_element)) > @@ -1731,8 +1740,10 @@ > : LABEL_FILES); > END(HTML_EM); > END(HTML_H2); > + PUTS("\n"); > #ifndef LONG_LIST > START(HTML_DIR); > + PUTS("\n"); > #endif /* !LONG_LIST */ > } > #endif /* DIRED_SUPPORT */ > @@ -1755,6 +1766,7 @@ > FREE(file_extra); > } > MAYBE_END(HTML_LI); > + PUTS("\n"); > #endif /* LONG_LIST */ > > next_element = HTBTree_next(bt, next_element); > @@ -1789,7 +1801,7 @@ > END(HTML_DIR); > #endif /* !LONG_LIST */ > } > - } /* printing out the tree in order done */ > + } /* end printing out the tree in order */ > > closedir(dp); > FREE(logical); > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 08:03:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA08618 for ; Wed, 7 Apr 1999 08:03:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA24275; Wed, 7 Apr 1999 06:22:30 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071122.HAA02577@shell.clark.net> Subject: Re: lynx-dev makefile rules To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 07:22:27 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 7, 99 02:18:25 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1316 Lines: 36 > > While building recent lynx without configure options on LINUX > I got these output on the screen (below). > My understandig was the default configuration does not include gettext() > support so "intl" directory and LOCALEDIR should be irrelevant, isn't it? should be (perhaps I missed a combination). will check. > > gcc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../../intl -I../../.. -I../ > ../../src -I../../../intl -I../../../WWW/Library/Implementation -O2 -DLINUX - > I../../../WWW/Library/Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../W > WW/Library/Implementation/HTGopher.c > > etc. > > gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/home/pauzner/.lynx/share/locale\" -I. -I.. - > Ichrtrans -I./chrtrans -I.. -I../intl -I../src -I../WWW/Library/Implementation > -O2 -DLINUX -c ./LYJump.c > gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/home/pauzner/.lynx/share/locale\" -I. -I.. - > Ichrtrans -I./chrtrans -I.. -I../intl -I../src -I../WWW/Library/Implementation > -O2 -DLINUX -c ./LYList.c > etc. > > In fact, I use few configure options but they are far from gettext() interest: > ./configure --prefix=~/.lynx --exec-prefix=~/.lynx > --enable-persistent-cookies --enable-nsl-fork > > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 08:06:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA08634 for ; Wed, 7 Apr 1999 08:06:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA27025; Wed, 7 Apr 1999 06:44:33 -0500 (CDT) Date: Wed, 7 Apr 1999 06:44:12 -0500 (CDT) From: Klaus Weide To: "C.J.LAWSON" cc: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2389 Lines: 60 On Sat, 3 Apr 1999, C.J.LAWSON wrote: > On Thu, 1 Apr 1999, David Woolley wrote: > [C.J.LAWSON:] > > > > I ran into some program that converts ordinary text files to html > > > > and after running the file once or twice on misc files, > > > > I tried piping the result to lynx ... didn't like it Exactly how did you try piping the result to lynx? And what made you conclude thad lynx "didn't like it?" What is the behavior you wish to see from lynx anyway in such a situation? Fully interactive, or more like 'lynx -dump'? > > Lynx isn't a general file viewer. You would be much better using > > a designed for the purpose tool, e.g, most or less, and if you want > > directory browsing, Midnight Commander. > Indeed Lynx is not a general file viewer ... nor are most, less or mc > suitable for html page viewing But mc can be used for viewing html pages, if it is configured to use (e.g.) lynx as a converter. And less could also be configured to use lynx as a converter, see the LESSOPEN environment variable. > ... In my message, I explicitly said that > the text was converted to html, first, before it is to be viewed... And > yes there is a rationale for it (I am sure you can think of others > yourself). > > > Any Unix system, with sufficient memory, will cache recently accessed > > files with no need for any additional software. > ??? !!! I cannae see how this has a bearing on the question I asked and > what is more ... all the world is not unix .. The question was confusing - I still don't know what exactly the question is. There were at least two topics, not clearly related - pipes and virtual memory/ram drives. And the whole thing looked more like an idea for changing something than a genuine question. You should clarify. I'm sure David knows that all the world is not unix. That's probably why he stated explicitly what OS he's talking about. Which you haven't done at all, as far as I have seen. It should not surpri > > > > > this is beyond me: anyone else have thoughts? > > > > I think the thinking is confused, which is why you don't understand it. > I'll let you off Easter is a time of forgiveness .. > > > No reply address available, so you'll have to CC him. [...] > No reply address available !? Thats odd, I usually have 2 addresses on > each of my emails .. The first message as forwarded to lynx-dev didn't have them. Klaus From owner-lynx-dev@sig.net Wed Apr 7 08:37:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA09383 for ; Wed, 7 Apr 1999 08:37:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA01415; Wed, 7 Apr 1999 07:16:32 -0500 (CDT) Date: Wed, 7 Apr 1999 07:16:28 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev outofmem() allocating memory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2041 Lines: 50 On Mon, 5 Apr 1999, Gisle Vanem wrote: > Lynx 2.8.2.dev21, djgpp 2.02 (DOS) version. > > While building Lynx with a great new mallocing debugger (YAMD), > I found that `outotmem()' indirectly tries to allocate another 16kB ! > > This contradiction happens in libc's `fflush (stdout)'; it doesn't > happen while in `fflush(stderr)' (because stdout is line-buffered). Except that *stderr isn't really the library-provided FILE you would expect, if a Trace Log file is in use. So you may have that problem even for stderr. > It also happens if `printf()' contains a '\n'. > > I think this behavior is same under other POSIX compliant targets; > It makes sense to me that `fflush(stdout)' should flush it's buffer > and allocate another. > > I suggest that when `LYOutOfMemory' is true, flushing should not > be done. Alternatively, we should use non-buffered `write()' or > print to `stderr'. There all kinds of things that may happen after outofmem() is called. Several of those could potentially allocate memory, for example termination of curses mode. Instead of checking all of those possible calls, it seems more reasonambe to provide an option to make outofmem() do an abort() immediately. Maybe after printing where the outofmem condition occurred, but that may already involve allocation of a buffer... Alternatively, outofmem() could try to do some of the cleanups that free memory first, before doing anything else. Then there should be at least enough memory available for stdio purposes. Too bad that memory cleanup has just been disabled in recent patches! But if you seriously want to debug memory problems, you probably want to disable the various things that can happen in outofmem() anyway, and instead replace outpofmem() with something more straightforward. > BTW. YAMD (Yet Another Mallocing Debugger) is for djgpp and Linux. > It's available at For the purposes of debugging lynx, how does it compare to lynx's very own '--enable-find-leaks'? Klaus From owner-lynx-dev@sig.net Wed Apr 7 08:41:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA09579 for ; Wed, 7 Apr 1999 08:41:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA28606; Wed, 7 Apr 1999 06:57:06 -0500 (CDT) Date: Wed, 7 Apr 1999 06:57:03 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev (more patch) minore cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1093 Lines: 27 On Wed, 7 Apr 1999, Leonid Pauzner wrote: > Also minore (and obvious) fixes for src/LYReadCFG.c and WWW/... /HTFile.c > over all my previous patches. > > --- old/htfile.c Mon Apr 5 16:05:18 1999 > +++ ./htfile.c Tue Apr 6 15:31:44 1999 > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); > + PUTS("\n"); Not worth doing, IMO. This is unnecessary overhead, the only benefit I can imagine is for someone looking at the HTML source of generated directory listings, to get a somehow nicer display. Normally there is no reason to do this except for developers and very curious people, and this would slow down generation of directory listings (although most likely not significantly) for everyone at all times. Klaus From owner-lynx-dev@sig.net Wed Apr 7 08:58:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA09911 for ; Wed, 7 Apr 1999 08:58:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA06464; Wed, 7 Apr 1999 07:45:13 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071245.IAA18795@shell.clark.net> Subject: Re: lynx-dev (more patch) minore cleanup To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 08:45:09 -0400 (EDT) In-Reply-To: <199904071124.HAA02804@shell.clark.net> from "dickey@clark.net" at Apr 7, 99 07:24:36 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 734 Lines: 20 > > >From LYMain.c : > > static int cache_fun ARGS3( > > Parse_Args_Type*, p GCC_UNUSED, > > char **, argv GCC_UNUSED, > > char *, next_arg) > > > > What all this GCC_UNUSED staff for? > > it's because the functions all have the same number of parameters (unless > you've rewritten them). if you mix pointers, it won't compile on some > platforms (gcc is too forgiving to qualify here as an ANSI compiler). though now (looking closer) it seems that we've rewritten whatever function JED used that needed the p, argv parameters. I'll verify that anyway when I integrate the patches. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 09:04:15 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA10156 for ; Wed, 7 Apr 1999 09:04:14 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA06578; Wed, 7 Apr 1999 07:45:48 -0500 (CDT) Date: Wed, 7 Apr 1999 07:45:45 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: reverse-search In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1706 Lines: 48 On Wed, 7 Apr 1999, Leonid Pauzner wrote: > It was discussed recently about adding a revere search functionality, > one of the main problems was a lack of hot-key space since most of the > keys are already used by lynx. > > Currently we have 'n' key for forward next search. > It would be logical enough to use capital "N" for backward search ..... > > Any ideas? Currently: (pre-backward-search) lynx: WHEREIS search forward NEXT repeat search, forward Defaults: #KEYMAP:/:WHEREIS #KEYMAP:n:NEXT Other programs: less: '/' search forward 'n' repeat search, last direction '?' search backward 'N' repeat search, opposite direction vi: '/' search forward 'n' repeat search, last direction '?' search backward 'N' repeat search, opposite direction After backward search is implemented in lynx: lynx: WHEREIS search forward NEXT repeat search, last direction WHEREIS_BACKW search backward NEXT_REVERSE repeat search, opposite direction It should be obvious how to map WHEREIS, NEXT, WHEREIS_BACKW, and NEXT_REVERSE by default so that the keys act as in other programs. People who want '?' to be WHEREIS_BACKW map it to WHEREIS_BACKW in lynx.cfg. People who want '?' to be HELP as before map it to HELP in lynx.cfg. The only remaining questions are what the default mapping for '?' should be if no mapping is specified in lynx.cfg, and, if the answer to that first question is "HELP as before", what other default default mapping (if any) should be provided for WHEREIS_BACKW. No new ideas here, just a repetition (as was your question). Klaus From owner-lynx-dev@sig.net Wed Apr 7 09:41:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA11118 for ; Wed, 7 Apr 1999 09:41:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA15488; Wed, 7 Apr 1999 08:22:20 -0500 (CDT) Date: Wed, 7 Apr 1999 09:21:42 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev compile problem on HP-UX 9.07 Message-ID: <19990407092141.A10560@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1902 Lines: 38 I get this on an HP-UX 9.07 machine: cc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../../intl -I../../.. -I../. ./../src -I../../../intl -I../../../WWW/Library/Implementation -DSNAKE -I../../../WWW/Library/Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTAccess.c ../../../src/LYUtils.h: 180: too much defining - use -H option ../../../src/LYUtils.h: 181: too much defining - use -H option ../../../src/LYUtils.h: 182: too much defining - use -H option ../../../src/LYUtils.h: 183: too much defining - use -H option ../../../src/LYUtils.h: 184: too much defining - use -H option ../../../src/LYUtils.h: 185: too much defining - use -H option ../../../src/LYUtils.h: 186: too much defining - use -H option ../../../src/LYUtils.h: 187: too much defining - use -H option ../../../src/LYUtils.h: 188: too much defining - use -H option ../../../src/LYUtils.h: 190: too much defining - use -H option ../../../src/LYUtils.h: 192: too much defining - use -H option ../../../src/LYUtils.h: 202: too much defining - use -H option ../../../src/LYUtils.h: 203: too much defining - use -H option ../../../src/LYUtils.h: 204: too much defining - use -H option ../../../src/LYUtils.h: 205: too much defining - use -H option ../../../src/LYUtils.h: 207: too much defining - use -H option ../../../src/LYUtils.h: 208: too much defining - use -H option ../../../WWW/Library/Implementation/HTAccess.c: 66: no space *** Error code 1 Stop. *** Error code 1 Stop. Is there a workaround ot other fix? This is with 282.dev21. ------ Marvin the Paranoid Android says: I may just be a menial robot, but I'm far too intelligent to expect anyone to think of me for a moment. Far far too intelligent Far far ....... From owner-lynx-dev@sig.net Wed Apr 7 10:16:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA12089 for ; Wed, 7 Apr 1999 10:16:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29868; Wed, 7 Apr 1999 09:05:54 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 17:55:06 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev outofmem() allocating memory MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 914 Lines: 21 7-Apr-99 07:16 Klaus Weide wrote: > On Mon, 5 Apr 1999, Gisle Vanem wrote: > Alternatively, outofmem() could try to do some of the cleanups that > free memory first, before doing anything else. Then there should be > at least enough memory available for stdio purposes. Too bad that > memory cleanup has just been disabled in recent patches! Right. I think fprintf() message should be removed from outofmem() and FatalProblem(), LYexit() [else] reorganized a little: there is already a large chunk for LYOutOfMemory condition, so place all atexit staff and messages there to close cleanly. So we need two kind of atexit() calls - one for free_atexit() to do only when necessary and another for special actions like one pointed out by Doug recently. >From the other hand, HText's is the most memory-hungry item (unless we have a broken loop somewhere) so free_all_texts() may be enough for stdio purposes. From owner-lynx-dev@sig.net Wed Apr 7 10:17:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA12102 for ; Wed, 7 Apr 1999 10:17:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA25933; Wed, 7 Apr 1999 08:54:55 -0500 (CDT) Date: Wed, 7 Apr 1999 15:54:49 +0200 (CEST) Message-Id: <199904071354.PAA25090@login-2.eunet.no> From: "Gisle Vanem" To: lynx-dev@sig.net Subject: Re: lynx-dev outofmem() allocating memory X-Mailer: Watt/POP MIME-Version: 1.0 Content-type: text/plain; charset=cp850 Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1260 Lines: 35 Klaus Weide said: >> This contradiction happens in libc's `fflush (stdout)'; it doesn't >> happen while in `fflush(stderr)' (because stdout is line-buffered). > > Except that *stderr isn't really the library-provided FILE you would > expect, if a Trace Log file is in use. So you may have that problem > even for stderr. Really, I couldn't find that stderr is defined to something special, or that setvbuf() is used anywhere. > Alternatively, outofmem() could try to do some of the cleanups that > free memory first, before doing anything else. Then there should be > at least enough memory available for stdio purposes. Too bad that > memory cleanup has just been disabled in recent patches! Hear, hear! >> BTW. YAMD (Yet Another Mallocing Debugger) is for djgpp and Linux. >> It's available at > For the purposes of debugging lynx, how does it compare to lynx's > very own '--enable-find-leaks'? YAMD is more "low-level"; finds ptr-use after freeing, double-freeing, under or over-indexing dynamic data etc. I'm not sure 'find-leaks' can do that. The disadvantage is that it allocates a page (4kB) for every allocation! That's why I got outofmem() in the first place. Gisle V. From owner-lynx-dev@sig.net Wed Apr 7 10:20:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA12139 for ; Wed, 7 Apr 1999 10:20:55 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA00660; Wed, 7 Apr 1999 09:07:48 -0500 (CDT) From: dickey@clark.net Message-Id: <199904071407.KAA07731@shell.clark.net> Subject: Re: lynx-dev compile problem on HP-UX 9.07 To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 10:07:43 -0400 (EDT) In-Reply-To: <19990407092141.A10560@mail.bcpl.net> from "Webmaster Jim " at Apr 7, 99 09:21:42 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2504 Lines: 53 > > I get this on an HP-UX 9.07 machine: well - I've run into this with X applications, and foud that the -H option did not buy me anything. In that case, the only alternative was to use gcc. (The HPUX box that I was using last year has been down due to a hardware problem, but someone seems to have repaired that - however I'm working against a deadline at work and won't have time to try to fix this myself - assuming that hardware stays working). > > cc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../../intl -I../../.. -I../. ./../src -I../../../intl -I../../../WWW/Library/Implementation -DSNAKE -I../../../WWW/Library/Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTAccess.c > ../../../src/LYUtils.h: 180: too much defining - use -H option > ../../../src/LYUtils.h: 181: too much defining - use -H option > ../../../src/LYUtils.h: 182: too much defining - use -H option > ../../../src/LYUtils.h: 183: too much defining - use -H option > ../../../src/LYUtils.h: 184: too much defining - use -H option > ../../../src/LYUtils.h: 185: too much defining - use -H option > ../../../src/LYUtils.h: 186: too much defining - use -H option > ../../../src/LYUtils.h: 187: too much defining - use -H option > ../../../src/LYUtils.h: 188: too much defining - use -H option > ../../../src/LYUtils.h: 190: too much defining - use -H option > ../../../src/LYUtils.h: 192: too much defining - use -H option > ../../../src/LYUtils.h: 202: too much defining - use -H option > ../../../src/LYUtils.h: 203: too much defining - use -H option > ../../../src/LYUtils.h: 204: too much defining - use -H option > ../../../src/LYUtils.h: 205: too much defining - use -H option > ../../../src/LYUtils.h: 207: too much defining - use -H option > ../../../src/LYUtils.h: 208: too much defining - use -H option > ../../../WWW/Library/Implementation/HTAccess.c: 66: no space > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Is there a workaround ot other fix? This is with 282.dev21. > > ------ > > > Marvin the Paranoid Android says: > I may just be a menial robot, but I'm far too intelligent to > expect anyone to think of me for a moment. > Far far too intelligent > Far far ....... -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 10:21:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA12334 for ; Wed, 7 Apr 1999 10:21:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29892; Wed, 7 Apr 1999 09:05:57 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 16:57:58 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (more patch) minore cleanup MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1552 Lines: 37 7-Apr-99 06:57 Klaus Weide wrote: > On Wed, 7 Apr 1999, Leonid Pauzner wrote: >> Also minore (and obvious) fixes for src/LYReadCFG.c and WWW/... /HTFile.c >> over all my previous patches. >> >> --- old/htfile.c Mon Apr 5 16:05:18 1999 >> +++ ./htfile.c Tue Apr 6 15:31:44 1999 >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); >> + PUTS("\n"); > Not worth doing, IMO. This is unnecessary overhead, the only Nevertheless, I saw several PUTS("\n") in HTFile.c so I am not the first person there, and overhead really small. (Instead, I really think it will add more speed since HTML.c/GridText.c will not calculate a valid end-of-line wrapping position :) Looking at the HTML source may be interesting in 8-bit file name context, if we got a problem (it still not clean in some unusual situations). > benefit I can imagine is for someone looking at the HTML source of > generated directory listings, to get a somehow nicer display. > Normally there is no reason to do this except for developers and > very curious people, and this would slow down generation of directory > listings (although most likely not significantly) for everyone at all > times. > Klaus From owner-lynx-dev@sig.net Wed Apr 7 10:59:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA13376 for ; Wed, 7 Apr 1999 10:59:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA13357; Wed, 7 Apr 1999 09:41:34 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 18:30:49 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev LYNX: reverse-search MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2040 Lines: 55 47-Apr-99 07:45 Klaus Weide wrote: > On Wed, 7 Apr 1999, Leonid Pauzner wrote: >> It was discussed recently about adding a revere search functionality, >> one of the main problems was a lack of hot-key space since most of the >> keys are already used by lynx. >> >> Currently we have 'n' key for forward next search. >> It would be logical enough to use capital "N" for backward search I mean here "repeat search, opposite direction" - this may be enough for majority of users, leaving the question with mapping of '?' for an interesting person. > ..... >> >> Any ideas? > Currently: > (pre-backward-search) > lynx: WHEREIS search forward NEXT repeat search, forward > Defaults: > #KEYMAP:/:WHEREIS > #KEYMAP:n:NEXT > Other programs: > less: '/' search forward 'n' repeat search, last direction > '?' search backward 'N' repeat search, opposite direction > vi: '/' search forward 'n' repeat search, last direction > '?' search backward 'N' repeat search, opposite direction > After backward search is implemented in lynx: > lynx: WHEREIS search forward NEXT repeat search, last direction > WHEREIS_BACKW search backward NEXT_REVERSE repeat search, opposite > direction > It should be obvious how to map WHEREIS, NEXT, WHEREIS_BACKW, and > NEXT_REVERSE by default so that the keys act as in other programs. > People who want '?' to be WHEREIS_BACKW map it to WHEREIS_BACKW in > lynx.cfg. People who want '?' to be HELP as before map it to HELP in > lynx.cfg. The only remaining questions are what the default mapping > for '?' should be if no mapping is specified in lynx.cfg, and, if the > answer to that first question is "HELP as before", what other default > default mapping (if any) should be provided for WHEREIS_BACKW. > No new ideas here, just a repetition (as was your question). OK. > Klaus From owner-lynx-dev@sig.net Wed Apr 7 11:56:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA15316 for ; Wed, 7 Apr 1999 11:56:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA05881; Wed, 7 Apr 1999 10:48:14 -0500 (CDT) Date: Wed, 7 Apr 1999 10:25:32 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev outofmem() allocating memory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1514 Lines: 36 On Wed, 7 Apr 1999, Leonid Pauzner wrote: > 7-Apr-99 07:16 Klaus Weide wrote: > > > Alternatively, outofmem() could try to do some of the cleanups that > > free memory first, before doing anything else. Then there should be > > at least enough memory available for stdio purposes. Too bad that > > memory cleanup has just been disabled in recent patches! > > Right. I think fprintf() message should be removed from outofmem() > and FatalProblem(), LYexit() [else] reorganized a little: > there is already a large chunk for LYOutOfMemory condition, > so place all atexit staff and messages there to close cleanly. A potential problem: if the message is not written immediately, another problem can occur during the attempted cleanup, leading to an abort. In that case the original message would never be seen, and the original cause of the error (whether outofmemory or FatalProblem) would be totally obscure. The situation where outofmem() has not enough memory to even print an error message is so pathetic that there isn't much that can be done safely. Can't stop curses (it probably implies at least a flush), Can't do a lot of stuff since it may generate TRACE messages. > So we need two kind of atexit() calls - one for free_atexit() > to do only when necessary and another for special actions > like one pointed out by Doug recently. We already have the two names needed, call either LYatexit() or atexit(), define atexit(fcn) to be either 'LYatexit(fcn)' or '' (empty) as required... Klaus From owner-lynx-dev@sig.net Wed Apr 7 11:58:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA15328 for ; Wed, 7 Apr 1999 11:58:08 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA04105; Wed, 7 Apr 1999 10:43:32 -0500 (CDT) Date: Wed, 7 Apr 1999 10:43:22 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev outofmem() allocating memory In-Reply-To: <199904071354.PAA25090@login-2.eunet.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1495 Lines: 40 On Wed, 7 Apr 1999, Gisle Vanem wrote: > Klaus Weide said: > > >> This contradiction happens in libc's `fflush (stdout)'; it doesn't > >> happen while in `fflush(stderr)' (because stdout is line-buffered). > > > > Except that *stderr isn't really the library-provided FILE you would > > expect, if a Trace Log file is in use. So you may have that problem > > even for stderr. > > Really, I couldn't find that stderr is defined to something special, > or that setvbuf() is used anywhere. I was wrong about that, as far as the current code is concerned. The trace log code worked by assigning to *stderr in 2.7.?, but that has been changed. > >> BTW. YAMD (Yet Another Mallocing Debugger) is for djgpp and Linux. > >> It's available at > > > For the purposes of debugging lynx, how does it compare to lynx's > > very own '--enable-find-leaks'? > > YAMD is more "low-level"; finds ptr-use after freeing, double-freeing, > under or over-indexing dynamic data etc. I'm not sure 'find-leaks' can > do that. ptr-use no, double-freeing yes. Not sure what is meant by {under,over}- indexing. > The disadvantage is that it allocates a page (4kB) for every > allocation! That's why I got outofmem() in the first place. The advantage of lynx's builtin method is that it comes automatically with lynx, and is easy to compile with (just one configure flag). But no doubt more specialized libraries are more efficient. Klaus From owner-lynx-dev@sig.net Wed Apr 7 12:29:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA16335 for ; Wed, 7 Apr 1999 12:29:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA15227; Wed, 7 Apr 1999 11:10:30 -0500 (CDT) Date: Wed, 7 Apr 1999 11:10:20 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev (more patch) minore cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1567 Lines: 38 On Wed, 7 Apr 1999, Leonid Pauzner wrote: > 7-Apr-99 06:57 Klaus Weide wrote: > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > >> + PUTS("\n"); > > > Not worth doing, IMO. This is unnecessary overhead, the only > Nevertheless, I saw several PUTS("\n") in HTFile.c > so I am not the first person there, and overhead really small. Yes, yes... > (Instead, I really think it will add more speed since HTML.c/GridText.c > will not calculate a valid end-of-line wrapping position :) If not in source mode, HTML.c treats those "\n" like " " (or at least it should). There isn't much 'calculation' in GridText.c for this anyway, it just sets text->permissible_split whenever ch == ' '. > Looking at the HTML source may be interesting in 8-bit file name context, > if we got a problem (it still not clean in some unusual situations). Yes, I do that sometimes, and you do that sometimes, but I haven't missed nicer formatting, and the penalty always applies. It's really small, but still pointless IMO, but you may disagree. Btw. you could consider using PUTC('\n') instead of PUTS("\n"), they SHOULD have the same effect. But I'll stop beating this horse now. Klaus From owner-lynx-dev@sig.net Wed Apr 7 12:44:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA16874 for ; Wed, 7 Apr 1999 12:44:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA24345; Wed, 7 Apr 1999 11:32:44 -0500 (CDT) Date: Sun, 4 Apr 1999 19:14:18 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev fix to psrc patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1475 Lines: 37 I've found a bug in the patch I've sent. I tried to achive maximal performance of lynx compiled with lss support, but I misunderstood some concepts. Please change the following lines in LYCurses.c and in HTML.c (after applying patch) #define OMIT_SCN_KEEPING 1 to #define OMIT_SCN_KEEPING 0 this will enable the Style_className:HTML.c keeping and make lynx with lss slightly slower than it could be(though faster then dev21). If somebody wish to fix a bug, here is a description: If contents of some tag that has corresponding color style occupies more than 2 screens, after navigating to the page, on which the content of that block starts, and then pressing PGDN PGDN PGUP, the effect (color style) of that tag will be lost. The same (loosing style) happens when jumping to the anchor that is in such block and is located not on the 1st page. IMO this is something with style stack. If will be fixed, then keeping of Style_className:HTML.c can be omitted again. And here is a small patch that fixes comment in lynx.cfg: --- lynx-old.cfg Mon Mar 29 12:48:42 1999 +++ lynx.cfg Sun Apr 4 19:12:44 1999 @@ -1983,7 +1983,7 @@ # 5) Angle brackets of html specials won't be surrounded by markup for ABRACKET # # Examples: -# HTMLSRC_COMM:B I:!B !I +# HTMLSRC_COMM:B I:!I !B # - html comments will be surrounded by and in the # - internal html markup # HTMLSRC_ATTRVAL: span.attrval : !span Best regards, -Vlad From owner-lynx-dev@sig.net Wed Apr 7 13:24:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA18178 for ; Wed, 7 Apr 1999 13:24:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA09143; Wed, 7 Apr 1999 12:11:11 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 7 Apr 1999 20:58:40 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (more patch) minore cleanup MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 604 Lines: 19 7-Apr-99 11:10 Klaus Weide wrote: > On Wed, 7 Apr 1999, Leonid Pauzner wrote: >> (Instead, I really think it will add more speed since HTML.c/GridText.c >> will not calculate a valid end-of-line wrapping position :) > If not in source mode, HTML.c treats those "\n" like " " (or at least it Oops, yes (not in source mode). > should). There isn't much 'calculation' in GridText.c for this anyway, > it just sets text->permissible_split whenever ch == ' '. > consider using PUTC('\n') instead of PUTS("\n"), they SHOULD have the > same effect. But I'll stop beating this horse now. > Klaus From owner-lynx-dev@sig.net Wed Apr 7 13:27:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA18211 for ; Wed, 7 Apr 1999 13:27:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA11051; Wed, 7 Apr 1999 12:16:33 -0500 (CDT) Date: Sun, 4 Apr 1999 19:58:01 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: reverse-search In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2881 Lines: 77 On Wed, 7 Apr 1999, Klaus Weide wrote: > On Wed, 7 Apr 1999, Leonid Pauzner wrote: > > > It was discussed recently about adding a revere search functionality, > > one of the main problems was a lack of hot-key space since most of the > > keys are already used by lynx. > > > > Currently we have 'n' key for forward next search. > > It would be logical enough to use capital "N" for backward search > ..... > > > > Any ideas? > > Currently: > direction > > It should be obvious how to map WHEREIS, NEXT, WHEREIS_BACKW, and > NEXT_REVERSE by default so that the keys act as in other programs. > People who want '?' to be WHEREIS_BACKW map it to WHEREIS_BACKW in > lynx.cfg. People who want '?' to be HELP as before map it to HELP in > lynx.cfg. The only remaining questions are what the default mapping > for '?' should be if no mapping is specified in lynx.cfg, and, if the > answer to that first question is "HELP as before", what other default > default mapping (if any) should be provided for WHEREIS_BACKW. > > No new ideas here, just a repetition (as was your question). > > Klaus > Here are my thoughts: 1) Since pressing '/' now will jump to the next page (if there is no links near found text) or will highlight the link closest to the found text (starting from current "virtual" position) ) it will be good if there will be a command/key that will _unconditionally_ go to the next page with found text, ie it won't highlight closest link if there is one. 2) I suggest the following key combinations: '}' - search forward, to next link or next page 'n' - same '{' - reverse search 'N' - may be reverse search, same as '{' ']' - to the next page (unconditionally) '[' - to the previous page (unconditionally) 3) Objections against the scheme in 2) '[' and ']' are currently bound to inline images toggle and send HEAD request. May be that's why that functionality can be implemented later. 4) When key sequences support will be written, IMO it will be good to move all seldom-used commands like (assuming default mapping) " ' * ; ` @ [ ] -free last to to use them as described in 2) to key sequences rather than single keys to free one-key sequences to commands that are used more often. Also a lot of one-letter commands IMO should be rebound to key sequences, like k o ^K ^V As of '?', 'F1' invokes help screen too, and IMO it's more convenient for people that didn't use UNIX. IMO the '?' is not used by the people who wish to view help - such sort of people use F1 more often, so rebinding '?' to reverse search won't be such pain for lynx users. 5) Different variants of key bindings can be distributed with lynx (as standalone files, not as sections in lynx.cfg), so user can 'include' the one he/she prefer rather than composing new one. Best regards, -Vlad From owner-lynx-dev@sig.net Wed Apr 7 17:51:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA26159 for ; Wed, 7 Apr 1999 17:51:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA19202; Wed, 7 Apr 1999 16:41:13 -0500 (CDT) From: sang.kim@vlsi.com X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Date: Wed, 7 Apr 1999 16:10:59 -0400 (EDT) Message-Id: <199904072010.QAA16224@tiger.sanjose.vlsi.com> To: lynx-dev@sig.net X-Url: http://www.flora.org/lynx-dev/html/month0499/msg00097.html X-Mailer: Lynx, Version 2.7 X-Personal_Name: sang Subject: lynx-dev Re: dumping web pages Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 528 Lines: 18 >>Date: Mon, 05 Apr 1999 10:23:11 -0700 >>From: Sang Kim >>Reply-To: lynx-dev@sig.net >>To: lynx-dev@sig.net >>Subject: Re: lynx-dev dumping web pages >> >>sample html login is >>http://www.schwab.com/SchwabNOW/Exec/gotrade >>Once I enter userid and password, somehow it remebers me >>and allow to navigate protected area. > >what version of lynx are you using? I haven't been able to use schwab >with lynx for a while. It thinks I don't have cookies enabled. lynx -version Lynx Version 2.8rel.2 (1998) From owner-lynx-dev@sig.net Wed Apr 7 17:54:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA26172 for ; Wed, 7 Apr 1999 17:54:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA20817; Wed, 7 Apr 1999 16:45:30 -0500 (CDT) Message-Id: <199904072145.RAA02202@smtp-gw.vma.verio.net> From: "Bruce Bailey" To: "Lynx Dev" Subject: lynx-dev Anyone know of a compatible email service? Date: Wed, 7 Apr 1999 17:43:53 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1734 Lines: 41 Dear All, I am new to this list, so please excuse any newbie gaffes. In Maryland, we are fortunate enough to have free text-only dial-up access to the Internet throughout the state. The home page for this service can be found at URL: http://www.sailor.lib.md.us/ I am associated with a couple local organizations that give away recycled computers. The problem is that people don't want free PC's that don't come with Internet access and email. Sailor covers the internet access. There are plenty of free email providers, but the half dozen that I have explored in depth ALL require Microsoft Internet Explorer and/or Internet Explorer (or Windows '95) and cookies. The PC's we are getting donated to us are x386's! Can anyone recommend a free web-based email service that is VERY compatible with Lynx? (Please keep in mind that I am talking about access to Lynx via vt100 emulation on plain vanilla dial-up access. Running the 32 bit Win '95 version of Lynx locally is NOT an option for this application!) Sailor is currently using Lynx version 2.71 (I think). If upgrading that would make a difference, please let me know. Other creative suggestions are welcome. One idea is to forego the text-only approach and try NewDeal Office. I wish I knew more about how people were using this application. You can read more at URL: http://www.newdealinc.com/ BTW Sailor has this to say about the free services currently available: "These sites are not optimized to work well with text-based browsers, Sailor does not recommend these services to people who use Sailor Lynx." (from URL: http://sailor.lib.md.us/docs/freemail.html) Thank you very much. Bruce Bailey, DORS Webmaster http://www.dors.state.md.us/ 410/554-9211 From owner-lynx-dev@sig.net Wed Apr 7 18:00:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA26405 for ; Wed, 7 Apr 1999 18:00:10 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA22755; Wed, 7 Apr 1999 16:51:01 -0500 (CDT) Date: Wed, 7 Apr 1999 12:32:36 -0400 (EDT) From: Clair Wilson X-Sender: cwilson@inet.guthrie.net To: lynx support Subject: lynx-dev lynx under vms Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1788 Lines: 55 Hi I am trying to make lynx 2.8 work on an Alpha machine (formerly vax) under vms. I can make lynx itself run by running LYNXAXPMULTINET.EXE. It runs great and gets to the internet. However, I cannot make the bookmarks file work. I am thinking that maybe I have something set up incorrectly. The following shows my setup : 1. Lynx_Dir is a logical which is set to [clair.lynx2-8.lynx2-8]. (clair.lynx2-8.lynx2-8] is the lynx directory. 2. I placed file lynx.cfg into this same directory. Maybe that is the problem. Perhaps lynx.cfg (the name used in a Unix environment) needs to be renamed to something else. Is the name different on the Alpha ? 3. lynx.cfg points to my bookmarks file, which is called lynx_bookmarks on [clair.lynx2-8.lynx2-8] The entry in lynx.cfg looks as follows : DEFAULT_BOOKMARK_FILE:LYNX_BOOKMARKS For some reason, the bookmark file cannot be found by lynx. I don't think that this is case sensitive. 4. Also, the startfile does not get accessed when I start lynx. The start file is set as follows in lynx.cfg |: STARTFILE:http://www.nfl.com I could us any file here. This is just an example. 5. It appears as though lynx is not using lynx.cfg at all. Does anyone have any idea why ? The logical points to it. I think it is in the correct directory. It points to an existing bookmarks file. It also points to an existiong URL. I am obviously doing something fundamenatlly wrong. I have been running lynx successfully on an rs6000 using AIX for years. So maybe I am doing something Unix-like rather than vms-like. Does anyone have any idea what I am doing wrong ? Thank You Mr. Clair Wilson System Programmer Information Services Robert Packer Hospital Sayre, Pa. cwilson@inet.guthrie.org phone 570-882-5389 fax 570-882-5330 From owner-lynx-dev@sig.net Wed Apr 7 20:46:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA30656 for ; Wed, 7 Apr 1999 20:46:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA03966; Wed, 7 Apr 1999 17:30:31 -0500 (CDT) From: dickey@clark.net Message-Id: <199904072229.SAA02755@shell.clark.net> Subject: Re: lynx-dev lynx under vms To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 18:29:42 -0400 (EDT) In-Reply-To: from "Clair Wilson " at Apr 7, 99 12:32:36 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 708 Lines: 21 > 5. It appears as though lynx is not using lynx.cfg at all. Does anyone > have any idea why ? it has to read lynx.cfg - that much is know. > The logical points to it. I think it is in the correct directory. It > points to an existing bookmarks file. It also points to an existiong URL. > I am obviously doing something fundamenatlly wrong. I have been running > lynx successfully on an rs6000 using AIX for years. So maybe I am doing > something Unix-like rather than vms-like. > > Does anyone have any idea what I am doing wrong ? Does the -trace option work? That does show some of the filenames that are referenced. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 7 20:55:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA30881 for ; Wed, 7 Apr 1999 20:55:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA03957; Wed, 7 Apr 1999 19:41:58 -0500 (CDT) Date: Wed, 7 Apr 1999 17:41:53 -0700 From: David Combs To: lynx-dev@sig.net Subject: Re: graphics viewers (was http://www.slcc.edu/lynx/release2-8/lynx2-8/lynx_help/lynx-dev.html) Message-ID: <19990407174153.A21629@netcom19.netcom.com> References: <199904070905.FAA19804@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Klaus Weide on Wed, Apr 07, 1999 at 04:48:07AM -0500 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 211 Lines: 12 Is this AA-project you mention (klaus) -- is it something I can run on my shell-account at the isp, which runs sparc hardware. Or is it just a library that I have to make calls into? Or what? Thanks! David From owner-lynx-dev@sig.net Wed Apr 7 20:57:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA30895 for ; Wed, 7 Apr 1999 20:57:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA26160; Wed, 7 Apr 1999 17:01:25 -0500 (CDT) From: Philip Webb Message-Id: <199904072201.SAA29694@chass.utoronto.ca> Subject: Re: lynx-dev Re: dumping web pages To: lynx-dev@sig.net Date: Wed, 7 Apr 1999 18:01:07 -0400 (EDT) Cc: sang.kim@vlsi.com In-Reply-To: <199904072010.QAA16224@tiger.sanjose.vlsi.com> from "sang.kim@vlsi.com" at Apr 7, 99 04:10:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 820 Lines: 18 990407 Sang Kim wrote: > sample html login is http://www.schwab.com/SchwabNOW/Exec/gotrade > Once I enter userid and password, > somehow it remebers me and allow to navigate protected area. >> what version of lynx are you using? > Lynx Version 2.8rel.2 (1998) this may well be part of the problem: cookie support has improved since then. goto www.slcc.edu/lynx/release for 2-8-1 , which may help you; you could try the latest development version from sol.slcc.edu/lynx/current ; there are precompiled versions too: start at lynx.browser.org/ . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 7 23:33:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA02485 for ; Wed, 7 Apr 1999 23:33:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA13789; Wed, 7 Apr 1999 22:24:26 -0500 (CDT) Message-ID: <370C1CA7.3D8953AA@auracom.com> Date: Thu, 08 Apr 1999 00:04:07 -0300 From: Jamie Ellis X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev Lynx dev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 990 Lines: 29 Jamie Ellis 21 Alma Street Yarmouth April 7, 99 Your advice is required, I am president of a rapidly expanding Freenet that is about to serve approximately 40 000 people over a 760 sq. mile area. This service, The Yarmouth Community Net has been using Lynx as its web server on a linux OS for several years now. Our arrangement with the Provincial Department of Education limits us to providing member clients text based dial up access only (although we do have a regular WWW Graphical presense. Our members are demanding graphics! 'Text is anachronistic,' I hear. Be that as it may, it raises the question, what sort of server side improvements can be made to gussy up the appearance of Lynx? We have a really strong Technical team who could duplicate any solutions, although frankly, they give me the impression of 'what's the point?' I have always enjoyed your code and browser. It is elegant and fast. That ought to be enough. Is there more? Sincerely, Jamie Ellis President YCN From owner-lynx-dev@sig.net Wed Apr 7 23:48:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA02847 for ; Wed, 7 Apr 1999 23:48:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA18015; Wed, 7 Apr 1999 22:42:37 -0500 (CDT) Date: Wed, 7 Apr 1999 23:42:03 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904072342.AA18717@cas.org> Subject: Re: lynx-dev Anyone know of a compatible email service? In-Reply-To: <199904072145.RAA02202@smtp-gw.vma.verio.net> of Wed, 7 Apr 1999 17:43:53 -0400 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 311 Lines: 6 I use mail.yahoo.com and lynx 2.8.2dev .... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Wed Apr 7 23:55:39 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA03088 for ; Wed, 7 Apr 1999 23:55:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA19287; Wed, 7 Apr 1999 22:48:24 -0500 (CDT) Message-ID: <370C24F1.11CB2B1D@gate-way.net> Date: Wed, 07 Apr 1999 23:39:30 -0400 From: Brian Verkley X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev lynx & startfile Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 433 Lines: 19 did you ever figure this out? i am having the same problem :-( -brian re: Yesterday I installed lynx2.6. When starting it I get error-msg.: "lynx: Can't access start file file://localhost/afs/uni-bonn.de/home/uzr109/lynx/htmls/home_voe.html" "Alert: unable to access document" my lynx.cfg is: STARTFILE:file://localhost/u/uzr109/lynx/htmls/home_voe.html Till now using LYNX2.5FM it worked without any problems. Any help? From owner-lynx-dev@sig.net Wed Apr 7 23:55:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA03094 for ; Wed, 7 Apr 1999 23:55:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA19513; Wed, 7 Apr 1999 22:49:30 -0500 (CDT) Date: Wed, 7 Apr 1999 23:48:56 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904072348.AA18764@cas.org> Subject: Re: lynx-dev Lynx dev In-Reply-To: Your message of Thu, 08 Apr 1999 00:04:07 -0300 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1699 Lines: 32 From: Jamie Ellis >Our arrangement with the Provincial Department of Education limits us to >providing member clients text based dial up access only (although we do >have a regular WWW Graphical presense. >Our members are demanding graphics! 'Text is anachronistic,' I hear. Be Are they? How many of the members? What types of machines are they using and what types of modems? Frankly, graphics are the _least_ of what _I_ find missing when surfing the WWW using lynx... javascript is the most missing, and there's experimental support for that now! >that as it may, it raises the question, what sort of server side >improvements can be made to gussy up the appearance of Lynx? We have a I can think of Nothing that could easily be done for your users. The problem is this - they are dialing into your system and running lynx there. To get graphics shown at all, the lynx would have to some how call across that dial in to talk to the machine (what kind of machine? Solaris? Linux? MacOS? Windows? Windows 95? Windows 98? Windows NT? OS/2? VMS? Other?) and send it binary files AND tell it how to display those files. Now, the user _could_ run the lynx at their machine, configure it for their own system, and just 'pass thru' your servers - but that would take a LOT more hand holding for non-technical users... And at that point, why would they not just use Netscape or IE or Opera, etc.? -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Thu Apr 8 01:18:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA05334 for ; Thu, 8 Apr 1999 01:18:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA03614; Thu, 8 Apr 1999 00:11:39 -0500 (CDT) Date: Wed, 7 Apr 1999 22:48:33 -0500 From: Chris Lawrence To: Klaus Weide Cc: lynx-dev@sig.net, 35523@bugs.debian.org Subject: Re: lynx-dev Bug#35523: lynx: cookie handling broken with non-printable characters (fwd) Message-ID: <19990407224833.A3958@quango.watervalley.net> Mail-Followup-To: Klaus Weide , lynx-dev@sig.net, 35523@bugs.debian.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Chris Lawrence on Mon, Apr 05, 1999 at 10:55:44AM -0400 Organization: Kathie Lee's Sweatshops X-Operating-System: Linux/i486 2.2.4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1699 Lines: 48 On Apr 05, Chris Lawrence wrote: > On Mon, 5 Apr 1999, Klaus Weide wrote: > > It just isn't possible to send a cookie like the following with HTTP: > > > > Set-Cookie: bunny="I3\012." > > (where \012 is LF) > > > > Either the person reporting this misunderstands what's going on, or > > is leaving out some information. > > It may be a literal \012. I need to take a look at the raw HTTP > datastream from the CGI script, however. Here's a transcript of a telnet session; it is a literal \012: Trying 216.92.38.187... Connected to lordsutch.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 08 Apr 1999 03:45:00 GMT Server: Apache/1.3.3 Cache-Control: no-cache Content-Language: en Expires: Thu, 08 Apr 1999 04:45:02 GMT Pragma: no-cache Set-Cookie: firstvisit="I923543100\012."; Max-Age=5184000; Set-Cookie: visitor=dialup136.WaterValley.Net; Max-Age=5184000; Set-Cookie: count="I1\012."; Max-Age=5184000; Last-Modified: Mon, 05 Apr 1999 17:27:49 GMT Connection: close Content-Type: text/html Connection closed by foreign host. The problem: the quotes aren't being stored in the .lynx_cookies file. Chris -- ============================================================================= | Chris Lawrence | Get your Debian/m68k 2.1 CD-ROMs | | | http://www.clark.net/pub/lawrencc/ | | | | | Grad Student, Pol. Sci. | Watch Babylon 5 on TNT | | University of Mississippi | <*> http://tnt.turner.com/babylon5/ <*> | ============================================================================= From owner-lynx-dev@sig.net Thu Apr 8 01:35:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA05804 for ; Thu, 8 Apr 1999 01:35:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA04739; Thu, 8 Apr 1999 00:20:00 -0500 (CDT) From: Philip Webb Message-Id: <199904080519.BAA02742@chass.utoronto.ca> Subject: Re: lynx-dev lynx & startfile To: lynx-dev@sig.net Date: Thu, 8 Apr 1999 01:19:54 -0400 (EDT) Cc: bverkley@gate-way.net In-Reply-To: <370C24F1.11CB2B1D@gate-way.net> from "Brian Verkley" at Apr 7, 99 11:39:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1099 Lines: 27 990407 Brian Verkley wrote: > someone somewhere wrote: >> Yesterday I installed lynx2.6. why??? the latest Lynx is 2-8-1: get it from www.slcc.edu/lynx/release . >> When starting it I get error-msg.: >> "lynx: Can't access start file >> file://localhost/afs/uni-bonn.de/home/uzr109/lynx/htmls/home_voe.html" >> my lynx.cfg is: >> STARTFILE:file://localhost/u/uzr109/lynx/htmls/home_voe.html >> Till now using LYNX2.5FM it worked without any problems. it's not the version: presumably the file has disappeared somewhere. > did you ever figure this out? i am having the same problem :-( change lynx.cfg to STARTFILE:. (yes, that's `.'), which will start Lynx with your current directory: the next development version should have that as default. of course, you can try any other URL you choose, which is accessible. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 8 05:16:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA12139 for ; Thu, 8 Apr 1999 05:16:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA28230; Thu, 8 Apr 1999 03:56:43 -0500 (CDT) To: lynx-dev@sig.net References: <370C1CA7.3D8953AA@auracom.com> Message-Id: From: "Leonid Pauzner" Date: Thu, 8 Apr 1999 12:43:59 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1521 Lines: 38 8-Apr-99 00:04 Jamie Ellis wrote: > Jamie Ellis > 21 Alma Street > Yarmouth > April 7, 99 > Your advice is required, > I am president of a rapidly expanding Freenet that is about to serve > approximately 40 000 people over a 760 sq. mile area. This service, The > Yarmouth Community Net has been using Lynx as its web server on a linux ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lynx is not a server, it's a client. > OS for several years now. > Our arrangement with the Provincial Department of Education limits us to > providing member clients text based dial up access only (although we do > have a regular WWW Graphical presense. > Our members are demanding graphics! 'Text is anachronistic,' I hear. Be > that as it may, it raises the question, what sort of server side > improvements can be made to gussy up the appearance of Lynx? We have a > really strong Technical team who could duplicate any solutions, although > frankly, they give me the impression of 'what's the point?' And I do not understand your point either: if you customers really need graphics manage them slip/ppp connection and let they start GUI browser at their end, but this is a complitely different technologie, require a strong user support team and expansion of modem pool/bandwith etc. So it is up to you to deside whether you want to change something. > I have always enjoyed your code and browser. It is elegant and fast. > That ought to be enough. Is there more? > Sincerely, > Jamie Ellis > President YCN From owner-lynx-dev@sig.net Thu Apr 8 05:39:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA12730 for ; Thu, 8 Apr 1999 05:39:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA21573; Thu, 8 Apr 1999 04:27:19 -0500 (CDT) Date: Thu, 8 Apr 1999 05:26:44 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904080526.AA2212@cas.org> Subject: Re: lynx-dev Lynx dev In-Reply-To: of Thu, 8 Apr 1999 12:43:59 +0400 (MSD) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 836 Lines: 21 From: "Leonid Pauzner" >> approximately 40 000 people over a 760 sq. mile area. This service, The >> Yarmouth Community Net has been using Lynx as its web server on a linux > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Lynx is not a server, it's a client. Technically that is true. However, there are free sites which run lynx on their _server_ and make lynx the only interface the user has to the system (ie the user gets no access to a shell). Lynx plus the site's web pages become a sort of 'pseudo-BBS' system ... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Thu Apr 8 05:47:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA12749 for ; Thu, 8 Apr 1999 05:47:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22196; Thu, 8 Apr 1999 04:34:13 -0500 (CDT) Date: Thu, 8 Apr 1999 18:45:31 +0900 (JST) From: Henry Nelson Message-Id: <199904080945.SAA05158@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx dev Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1459 Lines: 37 > improvements can be made to gussy up the appearance of Lynx? We have a > really strong Technical team who could duplicate any solutions, although Well, let's see how "strong" they really are. I've been struggling with the AA_LIB now for a long time. Just cannot seem to get the all important tool "aview" to compile on my Solaris2.6 box. For a starting page to the library, look at: http://www.ta.jcu.cz/aa/ and http://www.ta.jcu.cz/aa/aview/ . The page that convinced me that it was not a joke is: http://www2.cybercities.com/~jrocho/jan.html. Once you get used to what's going on, you can really see Jan's face. Maybe your technical team could figure out how to get the graphic file to be converted with something like netpbm, pass that output to aview, and finally have Lynx display the characters. Jan tells me that his photo is MUCH clearer when viewed directly as the output of aview. In htmlizing it, he says he lost a lot of resolution. That indicates to me that with the proper VIEWER/SUFFIX lines in lynx.cfg (and working tools) that something quite beautiful could be done. If you are able to work out something, would you PLEASE report your magic back here. Thanks, and good luck. __Henry > frankly, they give me the impression of 'what's the point?' > > I have always enjoyed your code and browser. It is elegant and fast. > That ought to be enough. Is there more? > > Sincerely, > Jamie Ellis > President YCN > > From owner-lynx-dev@sig.net Thu Apr 8 05:58:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA13148 for ; Thu, 8 Apr 1999 05:58:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA23436; Thu, 8 Apr 1999 04:48:02 -0500 (CDT) Date: Thu, 8 Apr 1999 18:59:20 +0900 (JST) From: Henry Nelson Message-Id: <199904080959.SAA05233@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx dev Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 464 Lines: 10 > > Yarmouth Community Net has been using Lynx as its web server on a linux > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Lynx is not a server, it's a client. Yes, but it can be set up to have the "feel" of a server. Before I was allowed to have an httpd of my own, I used a public access Lynx to "serve" the html files residing on my disk. I wouldn't recommend such an arrangement in this day and age, but at the time, it worked. __Henry From owner-lynx-dev@sig.net Thu Apr 8 06:17:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA13430 for ; Thu, 8 Apr 1999 06:17:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA24658; Thu, 8 Apr 1999 05:01:06 -0500 (CDT) To: lynx-dev@sig.net References: <19990407224833.A3958@quango.watervalley.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 8 Apr 1999 13:55:33 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Bug#35523: lynx: cookie handling broken with non-printable characters (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2078 Lines: 55 7-Apr-99 22:48 Chris Lawrence wrote: > On Apr 05, Chris Lawrence wrote: >> On Mon, 5 Apr 1999, Klaus Weide wrote: >> > It just isn't possible to send a cookie like the following with HTTP: >> > >> > Set-Cookie: bunny="I3\012." >> > (where \012 is LF) >> > >> > Either the person reporting this misunderstands what's going on, or >> > is leaving out some information. >> >> It may be a literal \012. I need to take a look at the raw HTTP >> datastream from the CGI script, however. I think the problem is that cookie spec does say nothing about having value in quotes, so quotes should be processed as normal characters. However, lynx do trim qouble quotes in HTMIME.c module, IMHO it should be commented out for Set-Cookie as I made for ETag recently. > Here's a transcript of a telnet session; it is a literal \012: > Trying 216.92.38.187... > Connected to lordsutch.com. > Escape character is '^]'. > HEAD / HTTP/1.0 > HTTP/1.1 200 OK > Date: Thu, 08 Apr 1999 03:45:00 GMT > Server: Apache/1.3.3 > Cache-Control: no-cache > Content-Language: en > Expires: Thu, 08 Apr 1999 04:45:02 GMT > Pragma: no-cache > Set-Cookie: firstvisit="I923543100\012."; Max-Age=5184000; > Set-Cookie: visitor=dialup136.WaterValley.Net; Max-Age=5184000; > Set-Cookie: count="I1\012."; Max-Age=5184000; > Last-Modified: Mon, 05 Apr 1999 17:27:49 GMT > Connection: close > Content-Type: text/html > Connection closed by foreign host. > The problem: the quotes aren't being stored in the .lynx_cookies file. > Chris > -- > ============================================================================= > | Chris Lawrence | Get your Debian/m68k 2.1 CD-ROMs | > | | http://www.clark.net/pub/lawrencc/ | > | | | > | Grad Student, Pol. Sci. | Watch Babylon 5 on TNT | > | University of Mississippi | <*> http://tnt.turner.com/babylon5/ <*> | > ============================================================================= From owner-lynx-dev@sig.net Thu Apr 8 07:54:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA15613 for ; Thu, 8 Apr 1999 07:54:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA02825; Thu, 8 Apr 1999 06:21:40 -0500 (CDT) To: lynx-dev@sig.net References: <19990407224833.A3958@quango.watervalley.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 8 Apr 1999 15:18:45 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Bug#35523: lynx: cookie handling broken with non-printable characters (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3605 Lines: 95 8-Apr-99 13:55 I wrote: > 7-Apr-99 22:48 Chris Lawrence wrote: >> On Apr 05, Chris Lawrence wrote: >>> On Mon, 5 Apr 1999, Klaus Weide wrote: >>> > It just isn't possible to send a cookie like the following with HTTP: >>> > >>> > Set-Cookie: bunny="I3\012." >>> > (where \012 is LF) >>> > >>> > Either the person reporting this misunderstands what's going on, or >>> > is leaving out some information. >>> >>> It may be a literal \012. I need to take a look at the raw HTTP >>> datastream from the CGI script, however. > I think the problem is that cookie spec does say nothing about > having value in quotes, so quotes should be processed as normal characters. > However, lynx do trim qouble quotes in HTMIME.c module, > IMHO it should be commented out for Set-Cookie as I made for ETag recently. >> Here's a transcript of a telnet session; it is a literal \012: >> Trying 216.92.38.187... >> Connected to lordsutch.com. >> Escape character is '^]'. >> HEAD / HTTP/1.0 >> HTTP/1.1 200 OK >> Date: Thu, 08 Apr 1999 03:45:00 GMT >> Server: Apache/1.3.3 >> Cache-Control: no-cache >> Content-Language: en >> Expires: Thu, 08 Apr 1999 04:45:02 GMT >> Pragma: no-cache >> Set-Cookie: firstvisit="I923543100\012."; Max-Age=5184000; >> Set-Cookie: visitor=dialup136.WaterValley.Net; Max-Age=5184000; >> Set-Cookie: count="I1\012."; Max-Age=5184000; >> Last-Modified: Mon, 05 Apr 1999 17:27:49 GMT >> Connection: close >> Content-Type: text/html >> Connection closed by foreign host. >> The problem: the quotes aren't being stored in the .lynx_cookies file. >> Chris >> -- >> ============================================================================= >> | Chris Lawrence | Get your Debian/m68k 2.1 CD-ROMs | >> | | http://www.clark.net/pub/lawrencc/ | >> | | | >> | Grad Student, Pol. Sci. | Watch Babylon 5 on TNT | >> | University of Mississippi | <*> http://tnt.turner.com/babylon5/ <*> | >> ============================================================================= Few words from HTTP/1.1 spec: Fielding, et al [Page 16] INTERNET-DRAFT HTTP/1.1 November 18, 1998 Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6). token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value. comment = "(" *( ctext | quoted-pair | comment ) ")" ctext = A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair = "\" CHAR From owner-lynx-dev@sig.net Thu Apr 8 08:57:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA17066 for ; Thu, 8 Apr 1999 08:57:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA13932; Thu, 8 Apr 1999 07:41:15 -0500 (CDT) Message-Id: <3.0.5.32.19990408084102.007f2b10@RS8.LOC.GOV> X-Sender: LRAS@RS8.LOC.GOV X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 08 Apr 1999 08:41:02 -0400 To: lynx-dev@sig.net From: "Lloyd G. Rasmussen" Subject: Re: lynx-dev Anyone know of a compatible email service? In-Reply-To: <199904072145.RAA02202@smtp-gw.vma.verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2876 Lines: 66 Without using Lynx or the web, people could use Nettamer through any service provider that had PPP. The internet service wouldn't be free, though. There is also a 386 version of Lynx that works through PPP, and with it you could store your own cookies. Although people have written batch files to set these DOOS PPP applications up, they are difficult to install. Cookie handling on a multisession basis is now being done by Lynx version 2.8.1, with 2.8.2 soon to come out. But getting that onto Sailor may not be trivial. I think the programmer who put Lynx on Sailor is not around anymore, since that version is about 2 years old. And there are legitimate security concerns for adding new Lynx options to anonymous users. If you think I can answer any more questions, don't hesitate to call or write. At 05:43 PM 4/7/99 -0400, you wrote: >Dear All, > >I am new to this list, so please excuse any newbie gaffes. > >In Maryland, we are fortunate enough to have free text-only dial-up access >to the Internet throughout the state. The home page for this service can >be found at URL: >http://www.sailor.lib.md.us/ > >I am associated with a couple local organizations that give away recycled >computers. The problem is that people don't want free PC's that don't come >with Internet access and email. Sailor covers the internet access. > >There are plenty of free email providers, but the half dozen that I have >explored in depth ALL require Microsoft Internet Explorer and/or Internet >Explorer (or Windows '95) and cookies. The PC's we are getting donated to >us are x386's! > >Can anyone recommend a free web-based email service that is VERY compatible >with Lynx? (Please keep in mind that I am talking about access to Lynx via >vt100 emulation on plain vanilla dial-up access. Running the 32 bit Win >'95 version of Lynx locally is NOT an option for this application!) > >Sailor is currently using Lynx version 2.71 (I think). If upgrading that >would make a difference, please let me know. > >Other creative suggestions are welcome. One idea is to forego the >text-only approach and try NewDeal Office. I wish I knew more about how >people were using this application. You can read more at URL: >http://www.newdealinc.com/ > >BTW Sailor has this to say about the free services currently available: >"These sites are not optimized to work well with text-based browsers, >Sailor does not recommend these services to people who use Sailor Lynx." >(from URL: http://sailor.lib.md.us/docs/freemail.html) > >Thank you very much. > >Bruce Bailey, DORS Webmaster >http://www.dors.state.md.us/ >410/554-9211 > Lloyd Rasmussen, Senior Staff Engineer National Library Service f/t Blind and Physically Handicapped Library of Congres (202) 707-0535 HOME: ; Thu, 8 Apr 1999 10:34:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA15938; Thu, 8 Apr 1999 09:22:39 -0500 (CDT) Message-Id: <199904081422.KAA05716@smtp-gw.vma.verio.net> From: "Bruce Bailey" To: "David Edward Ratti" Cc: "Lynx Dev" , Subject: lynx-dev Re: Anyone know of a compatible email service? Date: Thu, 8 Apr 1999 10:13:26 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1164 Lines: 37 Eureka! (Or, better yet, Eudora!) I am please to report back to the group that www.eudoramail.com works great through the sailor.lib.md.us Lynx browser! Thank you David and the many others that responded to me on and off the list! Bruce Bailey, DORS Webmaster http://www.dors.state.md.us/ ---------- > From: David Edward Ratti > To: bbailey@clark.net > Subject: Re: Anyone know of a compatible email service? > Date: Thursday, April 08, 1999 12:46 AM > > Well, I'm sending this to you via www.eudoramail.com, > which I'm TELNETing into through sailor.lib.md.us:23 - > Let's see how it works! > > Another possible solution to consider would be the DOS > graphical browser Arachne, from arachne.browser.org - > Written by Michael Polak of Prague, in the Czech Republic, > Arachne will run reasonably well on a 386 with 8 or 16 > megs of RAM, with a VGA card and display. > > Let me know how this E-Mail comes through, OK? It's my > first attempt at EudoraMail via TELNET and Lynx. > > Dave Ratti > D.Ratti@GEnie.com > > > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-lynx-dev@sig.net Thu Apr 8 10:51:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA20292 for ; Thu, 8 Apr 1999 10:51:18 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA19809; Thu, 8 Apr 1999 09:33:05 -0500 (CDT) Message-ID: <19990408083158.B20573@mred.intellistor.com> Date: Thu, 8 Apr 1999 08:31:58 -0600 From: tlhall@royal.net To: lynx-dev@sig.net Subject: Re: lynx-dev Anyone know of a compatible email service? References: <199904072145.RAA02202@smtp-gw.vma.verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199904072145.RAA02202@smtp-gw.vma.verio.net>; from Bruce Bailey on Wed, Apr 07, 1999 at 05:43:53PM -0400 X-Mutt-References: <199904072145.RAA02202@smtp-gw.vma.verio.net> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 900 Lines: 25 On Wed, Apr 07, 1999 at 05:43:53PM -0400, Bruce Bailey wrote: > Can anyone recommend a free web-based email service that is VERY compatible > with Lynx? ... I've found mailcity.com to be real usable for lynx. Some people say that hotmail.com works, but I've had intermittent results ever since MicroSoft took them over, and they officially say: What kind of browser do I need to use Hotmail? At the current time, we do not support text based browsers. To ensure full use of the features of Hotmail, please use a graphical browser. while MailCity says: Can I use MailCity with the Lynx Browser? Lynx browser users must use the nonframes version of MailCity... (which of course isn't true - lynx handles the frames just fine, thank you very much - but the non-frames version is quicker to use) You can get an account on MailCity without first having another email acount. From owner-lynx-dev@sig.net Thu Apr 8 11:05:15 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA20889 for ; Thu, 8 Apr 1999 11:05:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA27310; Thu, 8 Apr 1999 09:52:52 -0500 (CDT) Message-Id: <199904081453.KAA13769@smtp-gw.vma.verio.net> From: "Bruce Bailey" To: " Cc: "Lynx Dev" Subject: Re: lynx-dev Anyone know of a compatible email service? Date: Thu, 8 Apr 1999 10:42:34 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 737 Lines: 17 Yahoo mail (and most of the others) works fine if you have a shell account and are using Lynx locally. Yahoo (and MOST of the others) do not work when you are accessing Lynx via telnet (well, version 2.7 on Sailor anyway). ---------- > From: Larry W. Virden > To: lynx-dev@sig.net > Subject: Re: lynx-dev Anyone know of a compatible email service? > Date: Wednesday, April 07, 1999 11:42 PM > > I use mail.yahoo.com and lynx 2.8.2dev .... > -- > Larry W. Virden > <*> O- "No one is what he seems." > Unless explicitly stated to the contrary, nothing in this posting should > be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Thu Apr 8 11:44:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA22221 for ; Thu, 8 Apr 1999 11:44:18 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA10892; Thu, 8 Apr 1999 10:30:06 -0500 (CDT) Message-Id: <199904081529.LAA02380@smtp-gw2.vma.verio.net> From: "Bruce Bailey" To: Cc: Subject: Re: lynx-dev Anyone know of a compatible email service? Date: Thu, 8 Apr 1999 11:22:12 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1398 Lines: 39 Dear Mr. Hall, Thank you very much for your response! MailCity is run by Lycos, as is EudoraMail (which has almost exactly the same interface). I was not able to get HotMail to work with dial-up Lynx. MailCity is more mainstream, so this is the best tip I have received yet! ---------- > From: tlhall@royal.net > To: lynx-dev@sig.net > Subject: Re: lynx-dev Anyone know of a compatible email service? > Date: Thursday, April 08, 1999 10:31 AM > > On Wed, Apr 07, 1999 at 05:43:53PM -0400, Bruce Bailey wrote: > > Can anyone recommend a free web-based email service that is VERY compatible > > with Lynx? ... > > I've found mailcity.com to be real usable for lynx. > > Some people say that hotmail.com works, but I've had intermittent results > ever since MicroSoft took them over, and they officially say: > > What kind of browser do I need to use Hotmail? > > At the current time, we do not support text based browsers. To ensure > full use of the features of Hotmail, please use a graphical browser. > > while MailCity says: > > Can I use MailCity with the Lynx Browser? > > Lynx browser users must use the nonframes version of MailCity... > > (which of course isn't true - lynx handles the frames just fine, thank > you very much - but the non-frames version is quicker to use) > You can get an account on MailCity without first having another email > acount. From owner-lynx-dev@sig.net Fri Apr 9 02:01:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA18088 for ; Fri, 9 Apr 1999 02:01:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA16507; Fri, 9 Apr 1999 00:49:46 -0500 (CDT) Date: Thu, 8 Apr 1999 22:49:59 -0700 (PDT) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: lynx-dev Lynx doesn't like cookies In-Reply-To: <199904081529.LAA02380@smtp-gw2.vma.verio.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1870 Lines: 43 Hello Developers I downloaded lynx2.8.2dev.21, which I installed with ncurses-4.2. uname -a says "OSF1 goedel2 V4.0 878 alpha". First of all let me congratulate all of you. Lynx has suffered major changes since its last release version, which I am really amazed of. Now here is the problem that I've had. Let's say I go to cnn.com, they give me a cookie, which I accept (I accept all the cookies) and exit immediately. For some reason lynx hangs and does not want to a) write .lynx_cookies b) exit the program Is is there any reason why this is happening? What could I be doing wrong? When in the options menu I configure to "Ignore" all the cookies Lynx exits without problems. What other data do you need me to give you ? Below you will find my compilation settings: ./configure --prefix=/scratch/chappa/lynx/lynx2.8.d21 \ --with-screen=ncurses --enable-addrlist-page --enable-alt-binding \ --enable-kbd-layout --enable-libjs --enable-persistent-cookies \ --enable-externs --enable-font-switch --enable-cgi-links \ --enable-exec-links --enable-exec-scripts --enable-internal-links \ --enable-nsl-fork --enable-syslog --enable-gzip-help \ --enable-debug --enable-trace I had had the same problem before with 2.8.1, but I thought that maybe some changes that I had done may have triggered that. In this case I did not do anything, so I don't know what the problem is. Also I enabled the experimental Javascript, but nowhere that I have tried it has worked. Do you have any address that you can point me to, where I can try this to know what I am testing? Also I did not find any documentation on how to spawn the editor for forms. It was not in the key-strokes help page at least. Thanks a lot. You are doing a great job. Please send some sunshine to the rainy city of Seattle. Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Fri Apr 9 03:21:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA20014 for ; Fri, 9 Apr 1999 03:21:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA23014; Fri, 9 Apr 1999 01:53:17 -0500 (CDT) From: David Woolley Message-Id: <199904080737.IAA00513@djwhome.demon.co.uk> Subject: Re: lynx-dev outofmem() allocating memory To: lynx-dev@sig.net Date: Thu, 8 Apr 1999 08:37:13 +0100 (BST) In-Reply-To: <199904070903.FAA19610@shell.clark.net> from "dickey@clark.net" at Apr 7, 99 05:03:58 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 98 Lines: 5 > > I guess the defence would be to allocate the buffer oneself. > > you can't man 3 setbuf ?? From owner-lynx-dev@sig.net Fri Apr 9 04:15:06 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA22172 for ; Fri, 9 Apr 1999 04:15:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA00479; Fri, 9 Apr 1999 03:07:30 -0500 (CDT) X-Authentication-Warning: localhost.localdomain: hugo set sender to hugo.rabson@zetnet.co.uk using -f Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 09 Apr 1999 08:05:37 -0000 () From: Hugo Rabson To: Lynx Dev List Subject: lynx-dev batch-mode cookies ? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1106 Lines: 32 Hi, I've written a script which navigate Hotmail & forwards new emails to a local mail spool. The thing is, it no longer works because Hotmail now requires cookies & Lynx won't accept or send cookies when it's run in batch mode (non-interactive mode). e.g. "echo abc=123@ghi=456" | lynx -dump -post_data http://cgi...." I've tried using the "-accept_all_cookies" parameter. I've also made sure /etc/lynx.cfg has ACCEPT_ALL_COOKIES and PERSISTENT_COOKIES as true. (I'm running Lynx 2.8.2-3). Lynx appears to handle cookies properly when run interactively (i.e. Hotmail functions okay when I log in & read emails manually). However, Lynx appears not to handle cookies properly when run non-interactively: I get the Hotmail web page saying, "Sorry, your browser does not accept cookies." All advice is appreciated. Hugo P.S. Script is at http://www.jin-sei-kai.demon.co.uk/hugo/linux.html#hotmole --------Hugo Rabson -------- Date: 09-Apr-99 Time: 07:54:12 NT is for the Navy; the Vikings would have used Linux. ------------------------------------------------------ From owner-lynx-dev@sig.net Fri Apr 9 05:05:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA23222 for ; Fri, 9 Apr 1999 05:05:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA05126; Fri, 9 Apr 1999 03:56:45 -0500 (CDT) Message-ID: <19990409015544.36855@shell3.ba.best.com> Date: Fri, 9 Apr 1999 01:55:44 -0700 From: Kim DeVaughn To: Lynx Developers Subject: Re: lynx-dev Lynx doesn't like cookies Mail-Followup-To: Lynx Developers References: <199904081529.LAA02380@smtp-gw2.vma.verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Eduardo Chappa L. on Thu, Apr 08, 1999 at 10:49:59PM -0700 Organization: Kim's Home for Wayward Cocktail Waitresses & Hors d'oeuvre Girls Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2266 Lines: 56 On Thu, Apr 08, 1999, Eduardo Chappa L. (chappa@math.washington.edu) said: | | Also I did not find any documentation on how to spawn the editor for | forms. It was not in the key-strokes help page at least. Mea culpa. I really do need to add a short section somewhere in the user guide to document the new TEXTAREA edit/etc features. Unfortunately, I've been preoccupied getting ready for a cross-country move, packing, etc, so I haven't been doing much in the way of working on lynx lately. There *are* the following few lines in both the Default and Alternate Lineedit Keybindings sections of user guide, however: > Lynx Line Editor Default Key Binding > [...] > LKCMD Invoke cmd prompt - Ctrl-V (in form text fields, only) [2] > [...] > [2] Follow Ctrl-V with the key "e" bound to the EDIT function, > to edit the form's textarea field using an external editor. The other two new TEXTAREA functions require you to add a KEYMAP binding to your lynx.cfg file, in order to access them. I use the following: > KEYMAP:$:GROWTEXTAREA > KEYMAP:^:INSERTFILE which are then invoked (when the cursor is *in* a TEXTAREA) with ^V$ to add 5 lines to the TEXTAREA, or ^V^ to bring up the prompt for the name of an existing file, which is to be inserted into the TEXTAREA (above the cursorline). Also, an automatic variation of GROWTEXTAREA is normally compiled-in, wherein hitting return/enter when the cursor is on the last line in a TEXTAREA, will result in a new line being added to the TEXTAREA, with the cursor positioned on the new line. Note that when *in* a TEXTAREA, any lynx command may be given following the TEXTAREA "escape" key (currently hardcoded to ^V). There has been some discussion of other (better ?) ways to invoke the TEXTAREA specific functions, rather than using the ^V "escape paradigm", but until we have some sort of consensus on the more general question of multi-character commands, et`al, I'm not planning to do anything special to change the current implementation. Hopefully, my move will be completed in early May, and I'll be able to add the requisit documentation on the existing TEXTAREA editing functions, unless someone else takes a shot at it before then ... /kim From owner-lynx-dev@sig.net Fri Apr 9 05:59:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA24235 for ; Fri, 9 Apr 1999 05:59:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA00260; Fri, 9 Apr 1999 04:46:21 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Fri, 9 Apr 1999 13:40:43 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx doesn't like cookies MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 394 Lines: 12 8-Apr-99 22:49 Eduardo Chappa L. wrote: > Hello Developers > I downloaded lynx2.8.2dev.21, which I installed with ncurses-4.2. uname ... > Also I did not find any documentation on how to spawn the editor for > forms. It was not in the key-strokes help page at least. When you run into appropriate form field (textarea) you got a statusline message how to invoke a editor. Any problem? From owner-lynx-dev@sig.net Fri Apr 9 06:00:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA24424 for ; Fri, 9 Apr 1999 06:00:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA00308; Fri, 9 Apr 1999 04:46:52 -0500 (CDT) To: lynx-dev@sig.net, hugo.rabson@zetnet.co.uk References: Message-Id: From: "Leonid Pauzner" Date: Fri, 9 Apr 1999 13:33:41 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev batch-mode cookies ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1441 Lines: 39 9-Apr-99 08:05 Hugo Rabson wrote: > Hi, > I've written a script which navigate Hotmail & forwards new emails to a > local mail spool. The thing is, it no longer works because Hotmail now > requires cookies & Lynx won't accept or send cookies when it's run in > batch mode (non-interactive mode). > e.g. "echo abc=123@ghi=456" | lynx -dump -post_data http://cgi...." > I've tried using the "-accept_all_cookies" parameter. I've also made sure > /etc/lynx.cfg has ACCEPT_ALL_COOKIES and PERSISTENT_COOKIES as true. > (I'm running Lynx 2.8.2-3). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is a development version (2.8.2 has not released yet) try the recent development version - the link is available from '=' Info Page > Lynx appears to handle cookies properly when run interactively (i.e. > Hotmail functions okay when I log in & read emails manually). > However, Lynx appears not to handle cookies properly when run > non-interactively: I get the Hotmail web page saying, "Sorry, your browser > does not accept cookies." > All advice is appreciated. > Hugo > P.S. > Script is at http://www.jin-sei-kai.demon.co.uk/hugo/linux.html#hotmole > --------Hugo Rabson -------- > Date: 09-Apr-99 Time: 07:54:12 > NT is for the Navy; the Vikings would have used Linux. > ------------------------------------------------------ From owner-lynx-dev@sig.net Fri Apr 9 06:10:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA24701 for ; Fri, 9 Apr 1999 06:10:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA01513; Fri, 9 Apr 1999 05:00:08 -0500 (CDT) Date: Fri, 9 Apr 1999 03:00:21 -0700 (PDT) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx doesn't like cookies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 817 Lines: 27 *** Leonid Pauzner (uue@pauzner.mccme.ru) wrote Today: :) 8-Apr-99 22:49 Eduardo Chappa L. wrote: :) > Hello Developers :) :) > I downloaded lynx2.8.2dev.21, which I installed with ncurses-4.2. uname :) ... :) > Also I did not find any documentation on how to spawn the editor for :) > forms. It was not in the key-strokes help page at least. :) :) When you run into appropriate form field (textarea) :) you got a statusline message how to invoke a editor. :) Any problem? :) Yes! you are right. I guess I did not test this in the right place. This is what the bottom line says. (Textarea) Enter text. Use UP/DOWN arrows or TAB to move off (^Ve for editor). When I actually tried it, it did not work. I had to press ^V^Ve for the editor. Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Fri Apr 9 06:45:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA25428 for ; Fri, 9 Apr 1999 06:45:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04866; Fri, 9 Apr 1999 05:37:35 -0500 (CDT) Date: Fri, 9 Apr 1999 06:37:30 -0400 From: Webmaster Jim To: HiroyukiKurimoto Cc: lynx-dev@sig.net Subject: lynx-dev Re: We are planning to start mirroring. Message-ID: <19990409063730.B378@bcpl.net> References: <19990303062149.C1396@bcpl.net>; <19990303062149.C1396@bcpl.net> <19990406191545.A409@bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from HiroyukiKurimoto on Thu, Apr 08, 1999 at 10:33:45PM +0900 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2421 Lines: 65 On Thu, Apr 08, 1999 at 10:33:45PM +0900, HiroyukiKurimoto wrote: > Dear Sirs, > >Please point your mirror software at our new FTP location: > > ftp://lynx.isc.org/ > I have fixed the site of Lynx. > URL > http://mirror.nucba.ac.jp/mirror/lynx > ftp://mirror.nucba.ac.jp/mirror/lynx > Sincerely, Yours > ------Hiroyuki Kurimoto---------------------- > Nagoya Syouka University (ComputerCenter) > hiroyuki@nucba.ac.jp > http://mirror.nucba.ac.jp Thank you for your assistance. For best results, your FTP mirror software should also be retrieving the index.html page from the current subdirectory. I have written a script that organizes the files and displays them along with other pointers. Lynx will render this page properly even in FTP mode; transfers may then be started with Lynx. The site at the company formerly known as Digital is mirroring this page: reading message 6 of 33 (2397 bytes) .. flushed X-Mailer: Mutt 0.95.1i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.3 NetBSD 1.3.3 (NETMAN2) X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" On Thu, Apr 08, 1999 at 10:33:45PM +0900, HiroyukiKurimoto wrote: > Dear Sirs, > >Please point your mirror software at our new FTP location: > > ftp://lynx.isc.org/ > I have fixed the site of Lynx. > URL > http://mirror.nucba.ac.jp/mirror/lynx > ftp://mirror.nucba.ac.jp/mirror/lynx > Sincerely, Yours > ------Hiroyuki Kurimoto---------------------- > Nagoya Syouka University (ComputerCenter) > hiroyuki@nucba.ac.jp > http://mirror.nucba.ac.jp Thank you for your assistance. For best results, your FTP mirror software should also be retrieving the index.html page from the current subdirectory. I have written a script that organizes the files and displays them along with other pointers. Lynx will render this page properly even in FTP mode; transfers may then be started with Lynx. The site at the company formerly known as Digital is mirroring this page: ftp://ftp.digital.com/pub/net/infosys/lynx/current/index.html Other mirrors are still pointing at the old FTP site on sol.slcc.edu (e.g., ftp://ftp.vse.cz/pub/network/lynx-dev/current/). Any assistance in getting them updated would be appreciated. ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Fri Apr 9 07:40:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA26531 for ; Fri, 9 Apr 1999 07:40:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA10819; Fri, 9 Apr 1999 06:32:24 -0500 (CDT) From: dickey@clark.net Message-Id: <199904091132.HAA07936@shell.clark.net> Subject: Re: lynx-dev outofmem() allocating memory To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 07:32:00 -0400 (EDT) In-Reply-To: <199904080737.IAA00513@djwhome.demon.co.uk> from "David Woolley " at Apr 8, 99 08:37:13 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 270 Lines: 15 > > > > I guess the defence would be to allocate the buffer oneself. > > > > you can't > > man 3 setbuf ?? my point: doesn't help is fflush is allocating the buffer for some other reason. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 9 07:52:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA26919 for ; Fri, 9 Apr 1999 07:52:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12163; Fri, 9 Apr 1999 06:43:26 -0500 (CDT) From: dickey@clark.net Message-Id: <199904091143.HAA09226@shell.clark.net> Subject: Re: lynx-dev batch-mode cookies ? To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 07:43:23 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 9, 99 01:33:41 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 978 Lines: 24 > 9-Apr-99 08:05 Hugo Rabson wrote: > > Hi, > > > I've written a script which navigate Hotmail & forwards new emails to a > > local mail spool. The thing is, it no longer works because Hotmail now > > requires cookies & Lynx won't accept or send cookies when it's run in > > batch mode (non-interactive mode). > > > e.g. "echo abc=123@ghi=456" | lynx -dump -post_data http://cgi...." > > > I've tried using the "-accept_all_cookies" parameter. I've also made sure > > /etc/lynx.cfg has ACCEPT_ALL_COOKIES and PERSISTENT_COOKIES as true. > > (I'm running Lynx 2.8.2-3). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is a development version > (2.8.2 has not released yet) > try the recent development version - > the link is available from '=' Info Page yes (I wonder which dev version this corresponds to). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 9 07:57:09 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA26951 for ; Fri, 9 Apr 1999 07:57:08 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA13069; Fri, 9 Apr 1999 06:50:22 -0500 (CDT) From: dickey@clark.net Message-Id: <199904091150.HAA10018@shell.clark.net> Subject: Re: lynx-dev Lynx doesn't like cookies To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 07:50:19 -0400 (EDT) In-Reply-To: from "Eduardo Chappa L." " at Apr 8, 99 10:49:59 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 537 Lines: 17 > Also I enabled the experimental Javascript, but nowhere that I have > tried it has worked. Do you have any address that you can point me to, > where I can try this to know what I am testing? it's just a mod to the configure script - I don't have the libraries, and the fellow who is working on that hasn't reported progress. -- I'll add some more words to the INSTALLATION description. > Eduardo > http://www.math.washington.edu/~chappa/personal.html -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 9 10:49:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA31988 for ; Fri, 9 Apr 1999 10:49:43 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA24044; Fri, 9 Apr 1999 09:32:03 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Fri, 9 Apr 1999 18:27:49 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev uncacheing of internal pages in lynx MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1727 Lines: 47 Thinking a little more about reloading of lynx.cfg code I realize that when we press "RELAD THE CHANGES" several times we remove obsolete temp files for this menu but HText's will not uncached, so we waste a cache and push real documents out of cache. This can be fixed like this diff -u old/lyreadcf.c ./lyreadcf.c --- old/lyreadcf.c Tue Apr 6 15:42:40 1999 +++ ./lyreadcf.c Fri Apr 9 17:32:40 1999 @@ -1420,6 +1420,7 @@ if (!HTLoadAbsolute(&WWWDoc)) return(NOT_FOUND); + HTuncache_current_document(); /* now set up the flag and fall down to create a new LYNXCFG:/ page */ local_url = 0; /* see below */ but the problem more common, from GridText.c/HText_new(): if (!loaded_texts) { loaded_texts = HTList_new(); atexit(free_all_texts); } /* * Links between anchors & documents are a 1-1 relationship. If * an anchor is already linked to a document we didn't call * HTuncache_current_document(), e.g., for the showinfo, options, * download, print, etc., temporary file URLs, so we'll check now * and free it before reloading. - Dick Wesseling (ftu@fi.ruu.nl) */ if (anchor->document) { HTList_removeObject(loaded_texts, anchor->document); CTRACE(tfp, "GridText: Auto-uncaching\n") ; ((HText *)anchor->document)->node_anchor = NULL; HText_free((HText *)anchor->document); anchor->document = NULL; } Seems this comment referring the old behaviour when every internal page had a fixed temp file name. Currently, we create a newer copy of internal page in another temp file so we got a different URL and the code above is not working. From owner-lynx-dev@sig.net Fri Apr 9 11:14:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00133 for ; Fri, 9 Apr 1999 11:14:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA04211; Fri, 9 Apr 1999 10:01:26 -0500 (CDT) Date: Fri, 9 Apr 1999 16:01:18 +0100 (BST) From: "C.J.LAWSON" X-Sender: fx942976@dhaka.pegasus.cranfield.ac.uk To: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2510 Lines: 68 On Wed, 7 Apr 1999, Klaus Weide wrote: > Exactly how did you try piping the result to lynx? As one would expect on a unix box txt2html | lynx normally txt2html dumps the result to stdout > > And what made you conclude thad lynx "didn't like it?" The fact that it didn't > > What is the behavior you wish to see from lynx anyway in such a situation? > Fully interactive, or more like 'lynx -dump'? What I expected was for the piped in page to be displayed on my screen the same way 'cat | more' will show up on my screen. > > But mc can be used for viewing html pages, if it is configured to use > (e.g.) lynx as a converter. And less could also be configured to > use lynx as a converter, see the LESSOPEN environment variable. Indeed, it can and I have long done so on my box; but that is not the issue here.. The comment was digressionary and only served to obfuscate things further. > The question was confusing - I still don't know what exactly the question > is. There were at least two topics, not clearly related - pipes and > virtual memory/ram drives. And the whole thing looked more like an > idea for changing something than a genuine question. You should clarify. Yes there were two separate issues and as I clearly stated the first one initiated the second. The (a) first one was the issue of piping the results of a file2html conversion to lynx, the results of which was (b) the thought that it will be a nice idea to have all my html pages stored in virtual memory (or a ram drive) so I could access them from there. I doubt if it is put any clearer than the first time and regarding that, I can be of no further help. > > I'm sure David knows that all the world is not unix. That's probably why > he stated explicitly what OS he's talking about. Which you haven't done > at all, as far as I have seen. He passed a stupid comment in criticism .. don't bother defending it > > The first message as forwarded to lynx-dev didn't have them. And he didn't think to ask the source of the email for the address which was suggested he copy the response to? .. A poor defence for his comments don't you think? Regards --- Jonathan Lawson Thermal Processes Unit Department of Applied Energy and Optical Diagnostics School of Mechanical Engineering, Cranfield University, Cranfield, Bedford. UK. email j.lawson@cranfield.ac.uk So teach us to number our days, that we may apply our hearts unto wisdom. Ps 90:12 From owner-lynx-dev@sig.net Fri Apr 9 11:40:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00962 for ; Fri, 9 Apr 1999 11:40:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA13938; Fri, 9 Apr 1999 10:28:36 -0500 (CDT) Date: Fri, 9 Apr 1999 08:28:23 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: "C.J.LAWSON" Cc: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 483 Lines: 19 On Fri, 9 Apr 1999, C.J.LAWSON wrote: > > Exactly how did you try piping the result to lynx? > As one would expect on a unix box > > txt2html | lynx > > normally txt2html dumps the result to stdout > To see how to do this see the following message from Bela Lubkin in the archives. "http://www.flora.org/lynx-dev/html/month1098/msg00295.html" Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Apr 9 12:23:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA02209 for ; Fri, 9 Apr 1999 12:23:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA29961; Fri, 9 Apr 1999 11:12:09 -0500 (CDT) Date: Fri, 9 Apr 1999 12:12:01 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev PC Week: Hotmail users report being bitten by 'cookie monster' (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 502 Lines: 15 Those having cookies problems with HotMail should read this: http://www.zdnet.com/pcweek/stories/news/0,4153,1014325,00.html Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Fri Apr 9 13:35:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA04213 for ; Fri, 9 Apr 1999 13:35:52 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA24048; Fri, 9 Apr 1999 12:24:55 -0500 (CDT) Date: Fri, 9 Apr 1999 22:14:23 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev small? patch to dev21 patched with psrc patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3503 Lines: 66 This patch fixes few bugs that psrc implementation has (some comments in lynx.cfg fixed, unknown tags will now be drawn with htmlsrc_badtag style, spaces after tagname in s_junk_tag state are now stripped - now will be drawn as , some other fixes). It can interfere with a patch to lynx.cfg I've sent before (that patch was desgined to fix one line in comment in lynx.cfg). begin 644 patch.gz M'XL("/H)*'@ M-#W2E9!CEN#&V*YW24*K_/?.K%^P#20^J7I[KS^`L7=GGGGF96>7B3F=@N(M M!F`M[1>E6FJ4JA/V5*VXNC!F;%*^N[LK]\U[3_>6Y=[.#5>Z!]4F5"NMPV;KJ`J59K.9+Q0*'P24N_!, MZ+H>@)19.VD=UWR9GS^#4FE4BR=0\+\^?\[#*_R0ASQ\9TXG;`JW(W4\&`W/ M\TJ^P$FL`6[PR^AH+P\YP.M2&PF/Z?.#HOP)8#BV8"^B&+VWV`N; MAV_]'Q)YM7Y<(^CRNRZQYW('!P"(`Z:.![H0GGF_$`Q.F_5`"!7ZZD\/* M:*.2RY4/;$>P%IA3("N+8`IX-BT+[AE,3.Y:^I)-0.?PI%MH#DK>H:D2S&OP M'0!6.L;"\Y![X@%.01"-/LYZ@+-^5*P<2J!I=GU)B&+/Y9XQ?C+9\S[\24CI M]4CK#K4]'7UL/#*Q_\/@5CO?VVWOXIU\>S.(O22S5I,0"SXJ0.HB36+G-(*. M[K.=9YN@[^<+.8GF72',XFS]:7+JO3[Q9Z,I4JG^8.MS-A:>;G-TTAQV3J$2 MV!HA6QMT>@J'^S0DU__:=YZ9=ZYSML?1O_:#TIGH0D<5/MG-BD]V\P-DTS.# ME.UV=NF1$F<"6=Y"Q/N,THA<+DG/V_*VDYN0$.']0:Q>'1X$K&8RV'^>V+,_`JS%UA*PC(2'`7F=LNE`S;DT_90WOJQT/LFTFC2_U,T5FHUG\GC MXQ63:<7$IR]+@EV3&=+]3T2A)'0C(_\;D7@21&*S&O%'NLZU8?=X>N&R";9#R]Z"_0W4S[\=XFMUGQBL05)$)M:1ZC/ M`!5Y=::R.:$68IW-W"8JL]C\-RG-JN+?K0$UK*9UI+IVU`@:U:`]/)^A88.% M,()VH`B&%/M'MCU39+L?!:,R;F[8NP@9%P@F=M'.0Z%H0'X&;NV(984-8OLFU(]]D MV3^NJMYKC+Y1J@GZ-C_$'+"1^8W>WL*%-KQ5H\5,PO0=L-YG?8>&FE/?QOKA MBK49=^OKQBW(YH)36'\,WW\/.YMQOM%6KQ*_O1O_5=X-@[!>/2PV"&VM MBM_!BM[_>NNZFSO2<&E_TU&^EQ0__\'`AA@=`OO)[$_TTH7T6/B6-MQ/BV], M3VG^24.6N<)1`[T6[+CN%6JHL15@NB` MM68\ZP+D0VW6`ZB56K%:"WSU\7*_QN^6#7!4$L(PCLR1](2UF+;2#(O-:$R_ M9;G*%]+V%7*;$RB!I7S@(D;@^,DX+&QA6C`U/4[+MZW(QV!R"1?K2F*J+$=; M[%C3$TVXN^QI*KIJXXBWF)$%@@:DN_;0]6O27E//@HJR/G!=!$T-J(^>Y0,A M6'#YLRF,&3AVVB7R8"`@UH^D9MVOPLWF<52%??R?VF!9YWAO"E.WS#_"TAFAC/"^%V+2FE6$Y2?O'7G1XY(Q M?=A\D!2^?>L`*QP3/Z>J5%NU1JOVWCE5-#5^'%5M'5:3QU'-6E.>1_G?=X>;@)U4#:`-T\+,<..BX4:S4 MR4-T4PU0M_*/Z@'YMQN0@,4-%)E54 MV36#<&182T&9KF[H``XZ-78S9GJ^+S@UHGR!]0<5\?Z"#+P68ILSS'MI9P'X$R'-R`<-?! MPH0QC-3Y_!)YE`29''%K>\QP'FP9FU2EI??]?`ACEH1ENL+8+H5AN"6'4#UE M!_AQ(#<)M&?#^]6$5$1DY\@71(:O&*=S:AE7L&>RS.:LBW)B4K)FAKZ*T&0< M<#\0*-0R6Q=X'@4%1:B4V9JUJ?MD`JV8V-8P`U?)U`0ZJA@-U/->MP\3QQ!+ MEQ7E>&:)\(85,_-`$Y`+R^0XF\`P*E,&_852!'-"Q6AJ,@_E!16P<114P),F MW?@5\'@?NO8#EK^HCJ)!,[$R@@<9C/G%<8-.!RU4=:.DH5`(BR[IBL%77W3Z M9X=3/QW]IT++4NL,>JV=,]CIQ1VE^'J#)8U':9U4VS[KM,V.+`3MLMEIE^\[ ME%X86$E9)C9(GHU.D$)]L.3;=1P]V#F+>STCCONM.!(1M!$'K'`$RUJ+>F&[ M1,&-U19:L$._XVPJL3*<2.UM"`E*(IC:HT'W&@Q+Y_PT4-1!\/2T$X=T.50O M6JVD;MN)HCIFB*\Y5`LS#&G/,NU'F#`NZ#`!@Y'#7A(&M@@; Fri, 9 Apr 1999 14:04:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03427; Fri, 9 Apr 1999 12:54:52 -0500 (CDT) From: dickey@clark.net Message-Id: <199904091754.NAA08008@shell.clark.net> Subject: Re: lynx-dev small? patch to dev21 patched with psrc patch To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 13:54:46 -0400 (EDT) In-Reply-To: from "Vlad Harchev " at Apr 9, 99 10:14:23 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 541 Lines: 15 > > This patch fixes few bugs that psrc implementation has (some comments in > lynx.cfg fixed, unknown tags will now be drawn with htmlsrc_badtag style, > spaces after tagname in s_junk_tag state are now stripped - now > will be drawn as , some other fixes). It can interfere with a patch to > lynx.cfg I've sent before (that patch was desgined to fix one line in comment > in lynx.cfg). does this replace the earlier patch, or is it applied after? -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 9 15:45:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA08427 for ; Fri, 9 Apr 1999 15:45:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA07030; Fri, 9 Apr 1999 14:34:25 -0500 (CDT) X-Authentication-Warning: localhost.localdomain: hugo set sender to hugo.rabson@zetnet.co.uk using -f Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 09 Apr 1999 19:25:41 -0000 () From: Hugo Rabson To: Leonid Pauzner Subject: Re: lynx-dev batch-mode cookies ? Cc: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1181 Lines: 27 On 09-Apr-99 Leonid Pauzner wrote: > 9-Apr-99 08:05 Hugo Rabson wrote: >> I've written a script which navigate Hotmail & forwards new emails to a >> local mail spool. The thing is, it no longer works because Hotmail now >> requires cookies & Lynx won't accept or send cookies when it's run in >> batch mode (non-interactive mode). [...] >> (I'm running Lynx 2.8.2-3). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is a development version > (2.8.2 has not released yet) > try the recent development version - > the link is available from '=' Info Page I'm now running Lynx 2.8.2dev21 and the problem is the same: I don't get a persistent cookie file in batch mode. That is, the cookie file _exists_ & was created by Lynx in batch mode, but it's empty. I've compiled persistent cookies in & set the options in lynx.cfg so that persistent cookies worked just fine under Lynx in _interactive_ mode. --------Hugo Rabson -------- Date: 09-Apr-99 Time: 19:23:10 NT is for the Navy; the Vikings would have used Linux. ------------------------------------------------------ From owner-lynx-dev@sig.net Fri Apr 9 16:34:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA10215 for ; Fri, 9 Apr 1999 16:34:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA23944; Fri, 9 Apr 1999 15:22:59 -0500 (CDT) From: dickey@clark.net Message-Id: <199904092022.QAA02676@shell.clark.net> Subject: Re: lynx-dev compile problem on HP-UX 9.07 To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 16:22:55 -0400 (EDT) In-Reply-To: <19990407092141.A10560@mail.bcpl.net> from "Webmaster Jim " at Apr 7, 99 09:21:42 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 790 Lines: 21 > I get this on an HP-UX 9.07 machine: you need to add this to CPPFLAGS -Wp,-H600000 (maybe not 600k, but it worked for me) also, guard the include for stdarg.h with #if HAVE_STDARG_H && ANSI_VARARGS since HP's stdarg.h incorrectly includes varargs.h -- I'll put those fixes in dev.22 > cc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../../intl -I../../.. -I../. ./../src -I../../../intl -I../../../WWW/Library/Implementation -DSNAKE -I../../../WWW/Library/Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTAccess.c > ../../../src/LYUtils.h: 180: too much defining - use -H option > ../../../src/LYUtils.h: 181: too much defining - use -H option -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 9 17:23:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA11792 for ; Fri, 9 Apr 1999 17:23:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA08694; Fri, 9 Apr 1999 16:06:24 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sat, 10 Apr 1999 00:52:57 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev batch-mode cookies ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2009 Lines: 49 9-Apr-99 19:25 Hugo Rabson wrote: > On 09-Apr-99 Leonid Pauzner wrote: >> 9-Apr-99 08:05 Hugo Rabson wrote: >>> I've written a script which navigate Hotmail & forwards new emails to a >>> local mail spool. The thing is, it no longer works because Hotmail now >>> requires cookies & Lynx won't accept or send cookies when it's run in >>> batch mode (non-interactive mode). > [...] >>> (I'm running Lynx 2.8.2-3). >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is a development version >> (2.8.2 has not released yet) >> try the recent development version - >> the link is available from '=' Info Page > I'm now running Lynx 2.8.2dev21 and the problem is the same: I don't get a > persistent cookie file in batch mode. That is, the cookie file _exists_ & > was created by Lynx in batch mode, but it's empty. I've compiled ^^^^^^^^^^^^^^ Hmm... That may be a problem when "persistent_cookies" does set to FALSE: looking into LYMain.c I found out that "if (persistent_cookies)" check really lost: #ifdef EXP_PERSISTENT_COOKIES /* * We want to save cookies picked up when in immediate dump * mode. Instead of calling cleanup() here, let's only call * this one. - BJP */ LYStoreCookies(LYCookieFile); #endif /* EXP_PERSISTENT_COOKIES */ so cookies may be saved but never loaded next session. > persistent cookies in & set the options in lynx.cfg so that persistent > cookies worked just fine under Lynx in _interactive_ mode. But that may have nothing with your problem. I am not a cookie expert, sorry. Try starting lynx -trace and compare Lynx.trace files from interactive and noninteractive mode, this will give a hint. > --------Hugo Rabson -------- > Date: 09-Apr-99 Time: 19:23:10 > NT is for the Navy; the Vikings would have used Linux. > ------------------------------------------------------ From owner-lynx-dev@sig.net Fri Apr 9 18:28:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA13465 for ; Fri, 9 Apr 1999 18:27:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01220; Fri, 9 Apr 1999 17:16:05 -0500 (CDT) Message-ID: <19990409151500.00974@shell3.ba.best.com> Date: Fri, 9 Apr 1999 15:15:00 -0700 From: Kim DeVaughn To: Lynx Developers Subject: Re: lynx-dev Lynx doesn't like cookies Mail-Followup-To: Lynx Developers References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Eduardo Chappa L. on Fri, Apr 09, 1999 at 03:00:21AM -0700 Organization: Kim's Home for Wayward Cocktail Waitresses & Hors d'oeuvre Girls Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1585 Lines: 46 On Fri, Apr 09, 1999, Eduardo Chappa L. (chappa@math.washington.edu) said: | |(Textarea) Enter text. Use UP/DOWN arrows or TAB to move off (^Ve for editor). | | When I actually tried it, it did not work. I had to press ^V^Ve for the |editor. Yes. That behavior seems to be dependent on the particular flavor of UNIX being used (FreeBSD, Linux, etc), shell (tcsh, sh, etc), and the stty/term settings in use. Unfortunately, the TEXTAREA "escape" key that was chosen in the past, was ^V, which also happens to be the default used in some installations as the command-line "quote" key (also called "lnext in stty man pages, and stty -a output). For the time being, if using a double-^V bothers you, you can always put a "stty lnext undef" cmd in your .cshrc file (or the equivalent for your OS/shell), if you don't normally use ^V as a shell cmdline quote char. Or, if you do use ^V in that manner, invoke lynx through a wrapper script of the form: #!/bin/sh stty lnext undef $HOME/bin/lynx "$@" stty lnext ^V exit or some such. In the future, a "better" choice of a TEXTAREA escape char may make sense, but such changes should be made in conjunction with whatever is decided on for implementing multi-char commands in general, etc. Note also that when NOT in a TEXTAREA, ^V is the lynx command that by default switches between the SortaSGML and TagSoup modes of HTML parsing (ie, the SWITCH_DTD cmd). With the default bindings, etc, you'll also need to hit ^V twice to invoke that cmd. ^V is way too overloaded, but for now anyway, that's the way things are ... /kim From owner-lynx-dev@sig.net Fri Apr 9 20:40:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA16762 for ; Fri, 9 Apr 1999 20:40:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA28989; Fri, 9 Apr 1999 19:29:58 -0500 (CDT) Message-Id: <370E6DBA.94F68966@rs733.gsfc.nasa.gov> Date: Fri, 09 Apr 1999 16:14:34 -0500 From: Lori Perkins X-Mailer: Mozilla 4.01 [en] (WinNT; U) Mime-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev using lynx command line to download jpeg files X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 364 Lines: 16 I am having trouble downloading jpg files using the lynx command line. I can download gif files, text files, html files, but have trouble with jpg format. This works lynx -dump http://www.ssec.wisc.edu/data/comp/latest_cmoll.gif > my.gif but this does not lynx -dump http://www.britannia.org/gallery/Lynxes/clynx.jpg > my.jpg Anybody know why? Thanks, Lori From owner-lynx-dev@sig.net Fri Apr 9 20:53:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA17186 for ; Fri, 9 Apr 1999 20:53:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA01884; Fri, 9 Apr 1999 19:45:41 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904100045.SAA11396@sanitas> Subject: Re: lynx-dev using lynx command line to download jpeg files To: lynx-dev@sig.net Date: Fri, 9 Apr 1999 18:45:06 -0600 (MDT) In-Reply-To: <370E6DBA.94F68966@rs733.gsfc.nasa.gov> from "Lori Perkins" at Apr 9, 99 04:14:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 628 Lines: 19 In a recent note, Lori Perkins said: > Date: Fri, 09 Apr 1999 16:14:34 -0500 > > I am having trouble downloading jpg files using the lynx command line. > I can download gif files, text files, html files, but have trouble with > jpg format. > > This works > lynx -dump http://www.ssec.wisc.edu/data/comp/latest_cmoll.gif > my.gif > > but this does not > lynx -dump http://www.britannia.org/gallery/Lynxes/clynx.jpg > my.jpg > I always use "lynx -source" rather than "lynx -dump" to DL binary files. I'm more mystified why "-dump" even works for ".gif", since it's supposed to render the source before receiving it. -- gil From owner-lynx-dev@sig.net Sat Apr 10 00:30:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22345 for ; Sat, 10 Apr 1999 00:30:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA08563; Fri, 9 Apr 1999 23:24:18 -0500 (CDT) Date: Thu, 08 Apr 1999 12:53:02 BST From: Andy Harper To: LYNX-DEV@sig.net Message-ID: <009D6547.336A119D.1234@alder.cc.kcl.ac.uk> Subject: lynx-dev Problems with lynx 2-8-2 dev 21 for vms Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4758 Lines: 136 [I sent this on mar 31 but it didn't seem to make it into the archive, so here it is again - apologies if anyone received it twice] A few problems have surfaced with the latest lynx development kit 2.8.2 dev 21 when building for OpenVMS 6.2 using DEC C and the SOCKETSHR library. -------------------------------------------------------------------------------- [.WWW.LIBRARY.IMPLEMENTATION]HTTCP.C This module generates one error and a warning. The error is fixed by REMOVING the duff line altogether since it's not needed.... CC/decc/Prefix=ANSI /NoMember /Warning=(disable=implicitfunc) /Include=([-.Implementation],[---.src],[---]) /Define=(ACCESS_AUTH, VC="""2.14""", SOCKETSHR_TCP) HTTCP.C h_errno = NO_RECOVERY; ..................^ %CC-E-UNDECLARED, In this statement, "NO_RECOVERY" is not declared. at line number 671 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.WWW.LIBRARY.IMP LEMENTATION]HTTCP.C;1 phost = gethostbyname(host); /* See netdb.h */ ................^ %CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value "host" is const, but the referenced type of the target of this assignment is not. at line number 1003 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.WWW.LIBRARY.IM PLEMENTATION]HTTCP.C;1 -------------------------------------------------------------------------------- [.SRC]LYCLEAN.C No prior declaration of HTConfirmDefault leads to a warning only.... CC/decc/Prefix=All/NoMember/Define=(ACCESS_AUTH,SOCKETSHR_TCP,__VMS_CURSES) /NOL IST/OBJECT=LYCLEAN.OBJ/Include=([], [-], [.chrtrans], [-.WWW.Library.Implementat ion]) LYCLEAN.C c = HTConfirmDefault(REALLY_EXIT_Y, YES); ................^ %CC-I-IMPLICITFUNC, In this statement, the identifier "HTConfirmDefault" is implicitly declared as a function. at line number 60 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.SRC]LYCLEAN.C;1 c = HTConfirmDefault(REALLY_EXIT_N, NO); ................^ %CC-I-IMPLICITFUNC, In this statement, the identifier "HTConfirmDefault" is implicitly declared as a function. at line number 62 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.SRC]LYCLEAN.C;1 -------------------------------------------------------------------------------- [.SRC]LYCURSES.C No declaration of signal leads to a warning ... CC/decc/Prefix=All/NoMember/Define=(ACCESS_AUTH,SOCKETSHR_TCP,__VMS_CURSES) /NOLIST/OBJECT=LYCURSES.OBJ/Include=([], [-], [.chrtrans],[-.WWW.Library.Implementa tion]) LYCURSES.C signal(sig, func); ............^ %CC-I-IMPLICITFUNC, In this statement, the identifier "signal" is implicitly declared as a function. at line number 1562 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.SRC]LYCURSES.C ;1 -------------------------------------------------------------------------------- [.SRC]LYPRINT.C Mismatched type of Define_VMSLogical leads to a warning ... CC/decc/Prefix=All/NoMember/Define=(ACCESS_AUTH,SOCKETSHR_TCP,__VMS_CURSES) /NOLIST/OBJECT=LYPRINT.OBJ/Include=([], [-], [.chrtrans],[-.WWW.Library.Implementat ion]) LYPRINT.C Define_VMSLogical(names[name], envbuffer); ....^ %CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value "names[name]" is const, but the referenced type of the target of this assignment is not. at line number 90 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.SRC]LYPRINT.C;1 -------------------------------------------------------------------------------- [.SRC]LYUTILS.C This one is missing a semicolon character immediately before the indicated line. The lack of a definition for the DISP_PARTIAL symbol is the cause. If defined, the switch statement is correct. If not defined, then the error occurs. CC/decc/Prefix=All/NoMember/Define=(ACCESS_AUTH,SOCKETSHR_TCP,__VMS_CURSES) /NOLIST/OBJECT=LYUTILS.OBJ/Include=([], [-], [.chrtrans], [-.WWW.Library.Implementation]) LYUTILS.C } /* end switch */ ....^ %CC-E-BADSTMT, Invalid statement. at line number 2321 in file DISK$COMPCENT:[UDAA055.TEMP.LYNX2-8-2.SRC]LYUTILS.C; 1 -------------------------------------------------------------------------------- Miscellaneous... The header files for UCDOMAP.C are not built automatically via the MMS/MMS descrip.MMS files and ought to be included. However, running build-chrtrans.com manually does work if it's done before the MMS/MMK command. Running Lynx, entering the K command and selecting 'help on current keymap' leads to a link that doesn't exist: file://localhost/keystrokes/keystroke_help.html It seems to be missing the /lynx_root/lynx_help/ path prefix and I can find nothing in lynx.cfg to configure this. Any suggestions welcomed... However, accessing it through the H command and then 'keystroke commands' does work. Regards, Andy Harper Kings College London From owner-lynx-dev@sig.net Sat Apr 10 00:32:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22358 for ; Sat, 10 Apr 1999 00:32:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA08524; Fri, 9 Apr 1999 23:24:04 -0500 (CDT) X-Authentication-Warning: isis.vlsi.com: smtp set sender to using -f Message-ID: <370CC470.8C0462BC@vlsi.com> Date: Thu, 08 Apr 1999 08:00:00 -0700 From: Sang Kim X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev Re: dumping web pages]] Content-Type: multipart/mixed; boundary="------------4666557B640C73B6DE323DCB" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4232 Lines: 101 This is a multi-part message in MIME format. --------------4666557B640C73B6DE323DCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------4666557B640C73B6DE323DCB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from relayhost.sanjose.vlsi.com ([134.27.58.1]) by sjc-sodium.sanjose.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 2NCALKSQ; Thu, 8 Apr 1999 07:57:05 -0700 Received: from vlsi.com (tiger.sanjose.vlsi.com [134.27.41.103]) by relayhost.sanjose.vlsi.com (8.8.8+Sun/Hub-Anderson/111497) with ESMTP id HAA26843; Thu, 8 Apr 1999 07:57:03 -0700 (PDT) Sender: sang.kim@sanjose.vlsi.com Message-ID: <370CC3BF.23DCEEAF@vlsi.com> Date: Thu, 08 Apr 1999 07:57:03 -0700 From: Sang Kim X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: lynx-dev@sig.netnk Subject: [Fwd: lynx-dev Re: dumping web pages] Content-Type: multipart/mixed; boundary="------------E258E2B15A8262EBA22877CD" This is a multi-part message in MIME format. --------------E258E2B15A8262EBA22877CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Using Lynx Version 2.8.2dev.21 to go http://www.schwab.com/SchwabNOW/Exec/gotrade is giving the following message Alert! : HTTP/1.0 501 Method Not Implemented Method Not Implemented GET to https://trading58.schwab.com/trading/start not supported. I think https is for secured pages. Maybe this development release deos not have SSL. --------------E258E2B15A8262EBA22877CD Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from osiris.vlsi.com ([134.27.20.23]) by sjc-fluorine.sanjose.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id GSC6LG3A; Wed, 7 Apr 1999 17:59:48 -0700 Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id RAA09077 for ; Wed, 7 Apr 1999 17:59:49 -0700 (PDT) Received: from (chass.utoronto.ca [128.100.160.1]) by osiris.vlsi.com via smap (V2.0) id xma009075; Wed, 7 Apr 99 17:59:27 -0700 Received: (from purslow@localhost) by chass.utoronto.ca (8.9.1/8.9.1) id UAA15338; Wed, 7 Apr 1999 20:59:25 -0400 (EDT) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f From: Philip Webb Message-Id: <199904080059.UAA15338@chass.utoronto.ca> Subject: Re: lynx-dev Re: dumping web pages To: sang.kim@vlsi.com (Sang Kim) Date: Wed, 7 Apr 1999 20:59:24 -0400 (EDT) Cc: sang.kim@vlsi.com In-Reply-To: <370BFABC.63A9B43A@vlsi.com> from "Sang Kim" at Apr 7, 99 05:39:24 pm Reply-To: purslow@chass.utoronto.ca X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 990407 Sang Kim wrote: > sample html login is http://www.schwab.com/SchwabNOW/Exec/gotrade > Once I enter userid and password, > somehow it remebers me and allow to navigate protected area. > Lynx Version 2.8rel.2 (1998) > Philip Webb wrote: >> goto www.slcc.edu/lynx/release for 2-8-1 , which may help you; >> you could try the latest development version >> from sol.slcc.edu/lynx/current ; > I tried latest version - Lynx Version 2.8.2dev.21 (30 Mar 1999). > For somehow I can not access https pages. > I was able to with older version - 2.8rel.2 . Are we going backward? let's hope not (smile). i've forwarded this to lynx-dev, where you should send all messages so that everyone will see them. you should tell us exactly what happens when you try to access the site: what is the https URL? i don't use encryption, so i can't help very much, but hopefully someone else will be able to: 2-8-2dev.21 is a step forwards. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto --------------E258E2B15A8262EBA22877CD-- --------------4666557B640C73B6DE323DCB-- From owner-lynx-dev@sig.net Sat Apr 10 00:32:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22363 for ; Sat, 10 Apr 1999 00:32:05 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA08612; Fri, 9 Apr 1999 23:24:34 -0500 (CDT) Date: Thu, 8 Apr 1999 17:08:38 -0400 (EDT) From: akash agrawal To: lynx-dev@sig.net Subject: lynx-dev Information Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 617 Lines: 16 Sir, Can I download Lynx exe(Unix) from the InterNet.If yes pls tell me from which Site. Akash Agrawal ------------------------------------------------------------------- Akash Agrawal _____________________________ TC4, CMC Centre, Gachibowli, | | | | | Hyderabad-500019 | _____| | | _____| (A.P) India. | | ^ ^ | | ph : 91-40-3000501, Ex:2473 |________|__|___ |__|_________| email : akash@tc4hq.cmcltd.com, ------------------------------------------------------------------- From owner-lynx-dev@sig.net Sat Apr 10 01:37:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA24025 for ; Sat, 10 Apr 1999 01:37:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA16674; Sat, 10 Apr 1999 00:26:10 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904100525.XAA12765@sanitas> Subject: lynx-dev autoconfigure and host_os dependent CC To: lynx-dev@sig.net (Lynx List) Date: Fri, 9 Apr 1999 23:25:36 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 690 Lines: 25 I'd like to make the default C compiler dependent on the host operating system. There's a case statement that does this sort of thing -- I attempted adding: case $host_os in os390*) echo "Original CC was (${CC-undefined})" CC=${CC-c89} CFLAGS="$CFLAGS -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE" ;; esac ... but it happens far too late, after much testing is already done. The original setting apparently happens in macro AC_PROG_CC, called out of configure.in. But I don't know where to find the definition of this macro. For the time being, I'm simply supplying CC=c89 in the environment of the call to configure. Any better suggestions? Thanks, gil From owner-lynx-dev@sig.net Sat Apr 10 02:02:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA24676 for ; Sat, 10 Apr 1999 02:02:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA19800; Sat, 10 Apr 1999 00:55:29 -0500 (CDT) From: speaks@pugersky.tamu.edu Message-Id: <199904100556.AAA10984@pugersky.tamu.edu> Subject: lynx-dev Fatal error in Lynx Ver. 2.5 To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 00:56:32 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 579 Lines: 21 Strangest thing happened tonight. Lynx has been working fine on my Linux 2.0.29 (i586). Now, whenever I execute lynx it crashes saying A Fatal error has occurred in Lynx Ver. 2.5 Lynx now exiting with signal: 11 No core file was dumped. The only unusual thing that happened before this was that lynx hung up on a URL that was not responing, and then my modem connection died (a normal thing after 2 hours). Furthermore, lynx still works fine if I run it as root. Only when I am logged on as my usual login name does it crash like this. Any ideas/help out there? Randy From owner-lynx-dev@sig.net Sat Apr 10 02:23:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25125 for ; Sat, 10 Apr 1999 02:23:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21700; Sat, 10 Apr 1999 01:15:41 -0500 (CDT) Date: Sat, 10 Apr 1999 15:36:10 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev small? patch to dev21 patched with psrc patch In-Reply-To: <199904091754.NAA08008@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1019 Lines: 30 On Fri, 9 Apr 1999 dickey@clark.net wrote: > > > > This patch fixes few bugs that psrc implementation has (some comments in > > lynx.cfg fixed, unknown tags will now be drawn with htmlsrc_badtag style, > > spaces after tagname in s_junk_tag state are now stripped - now > > will be drawn as , some other fixes). It can interfere with a patch to > > lynx.cfg I've sent before (that patch was desgined to fix one line in comment > > in lynx.cfg). > > does this replace the earlier patch, or is it applied after? > > > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey > Recently (in message with title 'fix to psrc patch') I've sent a correction to psrc patch. It consisted of: * verbal request to replace #define OMIT_SCN_KEEPING from 1 to 0 in HTML.c and LYCurses.c. This modification doesn't interfere with patch - so such change still must be performed. * Small patch that fixed comment in lynx.cfg. This patch should be undone. Best regards, -Vlad From owner-lynx-dev@sig.net Sat Apr 10 02:33:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25313 for ; Sat, 10 Apr 1999 02:33:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA22474; Sat, 10 Apr 1999 01:24:01 -0500 (CDT) From: Philip Webb Message-Id: <199904100623.CAA03768@chass.utoronto.ca> Subject: Re: lynx-dev Re: dumping web pages]] To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 02:23:55 -0400 (EDT) Cc: sang.kim@vlsi.com In-Reply-To: <370CC470.8C0462BC@vlsi.com> from "Sang Kim" at Apr 8, 99 08:00:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 717 Lines: 17 990409 Sang Kim wrote: > Using Lynx Version 2.8.2dev.21 to go > http://www.schwab.com/SchwabNOW/Exec/gotrade > is giving the following message >> Alert! : HTTP/1.0 501 Method Not Implemented >> GET to https://trading58.schwab.com/trading/start not supported. > I think https is for secured pages. > Maybe this development release does not have SSL. you have to compile SSL in yourself: look under links [7 9 10] in the Main Help Page ( h ). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 10 02:36:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25320 for ; Sat, 10 Apr 1999 02:36:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA22999; Sat, 10 Apr 1999 01:30:14 -0500 (CDT) From: Philip Webb Message-Id: <199904100630.CAA03873@chass.utoronto.ca> Subject: Re: lynx-dev Information To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 02:30:08 -0400 (EDT) Cc: akash@tc4hq.cmcltd.com In-Reply-To: from "akash agrawal" at Apr 8, 99 05:08:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 579 Lines: 16 990409 Akash Agrawal wrote: > Sir, several Lynx developers are women ... (smile). > Can I download Lynx exe (Unix) from the InterNet. > If yes pls tell me from which Site. you can get binaries via www.clr.com/~subir/lynx/binaries.html ; if you have any problems doing so, ask again here with full details. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 10 02:42:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25510 for ; Sat, 10 Apr 1999 02:42:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA23597; Sat, 10 Apr 1999 01:35:55 -0500 (CDT) Date: Sat, 10 Apr 1999 15:58:35 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 778 Lines: 29 On Fri, 9 Apr 1999, Doug Kaufman wrote: > On Fri, 9 Apr 1999, C.J.LAWSON wrote: > > > > Exactly how did you try piping the result to lynx? > > As one would expect on a unix box > > > > txt2html | lynx > > > > normally txt2html dumps the result to stdout > > > > To see how to do this see the following message from Bela Lubkin in the > archives. > "http://www.flora.org/lynx-dev/html/month1098/msg00295.html" > Doug There is no such message on www.flora.org Can you describe the approach? Most probably it was a script, that read entire pipe to file, invoked a lynx on it, and then removed a tmp file. > __ > Doug Kaufman > Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu > Best regards, -Vlad From owner-lynx-dev@sig.net Sat Apr 10 02:58:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26115 for ; Sat, 10 Apr 1999 02:58:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA24379; Sat, 10 Apr 1999 01:45:36 -0500 (CDT) From: Philip Webb Message-Id: <199904100645.CAA04160@chass.utoronto.ca> Subject: Re: lynx-dev Fatal error in Lynx Ver. 2.5 To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 02:45:31 -0400 (EDT) Cc: speaks@pugersky.tamu.edu In-Reply-To: <199904100556.AAA10984@pugersky.tamu.edu> from "speaks@pugersky.tamu.edu" at Apr 10, 99 00:56:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1215 Lines: 26 990409 Randy Speaks wrote: > Strangest thing happened tonight. > Lynx has been working fine on my Linux 2.0.29 (i586). > Now, whenever I execute lynx it crashes saying >> A Fatal error has occurred in Lynx Ver. 2.5 >> Lynx now exiting with signal: 11 > No core file was dumped. > The only unusual thing that happened before this was > lynx hung up on a URL that was not responing > and then my modem connection died (a normal thing after 2 hours). > Furthermore, lynx still works fine if I run it as root. > Only when I am logged on as my usual login name does it crash like this. > Any ideas/help out there? well first, it's hardly strange: Lynx 2-5 dates from spring 1996 & the Internet has changed a lot since then! get the latest 2-8-1 from www.slcc.edu/lynx/release or try the latest development version from sol.slcc.edu/lynx/current . if you still have a problem, let us know full details, esp the URL which is causing you trouble. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 10 03:09:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA26369 for ; Sat, 10 Apr 1999 03:09:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA25226; Sat, 10 Apr 1999 01:55:49 -0500 (CDT) From: Philip Webb Message-Id: <199904100655.CAA04459@chass.utoronto.ca> Subject: Re: lynx-dev virtual html pages (fwd) To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 02:55:43 -0400 (EDT) In-Reply-To: from "Vlad Harchev" at Apr 10, 99 03:58:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1891 Lines: 52 990410 Vlad Harchev wrote: > On Fri, 9 Apr 1999, Doug Kaufman wrote: >> On Fri, 9 Apr 1999, C.J.LAWSON wrote: >>> As one would expect on a unix box txt2html | lynx >>> normally txt2html dumps the result to stdout >> see the following message from Bela Lubkin in the archives. >> http://www.flora.org/lynx-dev/html/month1098/msg00295.html > There is no such message on www.flora.org i just grabbed it & here it is: Eduardo Chappa wrote: > I tried the following recipe > > :0 B fbw > * () > | lynx -dump -force_html > > and it worked perfectly. The only problem I had was that I could not use > my own version of Lynx, it used the one installed in the system and > nothing that I tried worked, but I guess this is not hte right place to > discuss this. In any case if somebody knows, please let me know. That would always dump your default Lynx home page! Try: | lynx -dump -force_html -nolist /dev/stdin (try with and without -nolist, see which is closer to your intend purpose). Depends on the existence of /dev/stdin, which I think is pretty standard on Unix-like operating systems these days. If it's missing, try /dev/fd/0; if not that, use a temp file: | cat > junk.html; lynx -dump -nolist junk.html That introduces all sorts of horrible security issues, so /dev/stdin is much better. Of course, using Lynx in this manner probably opens up a bunch of security holes in the first place. Adding "-restrictions=all" might make it slightly safer. So I recommend: :0 B fbw * () | lynx -dump -force_html -nolist -restrictions=all /dev/stdin [signed] Bela Lubkin -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 10 03:09:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA26375 for ; Sat, 10 Apr 1999 03:09:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA24730; Sat, 10 Apr 1999 01:49:40 -0500 (CDT) From: Philip Webb Message-Id: <199904100649.CAA04276@chass.utoronto.ca> Subject: Re: lynx-dev Information (correction) To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 02:49:35 -0400 (EDT) Cc: akash@tc4hq.cmcltd.com In-Reply-To: <199904100630.CAA03873@chass.utoronto.ca> from "Philip Webb" at Apr 10, 99 02:30:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 559 Lines: 12 990410 i wrote inaccurately: > 990409 Akash Agrawal wrote: >> Can I download Lynx exe (Unix) from the InterNet. > you can get binaries via www.clr.com/~subir/lynx/binaries.html ; ^^^crl > if you have any problems doing so, ask again here with full details. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 10 07:30:10 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA32503 for ; Sat, 10 Apr 1999 07:30:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA05219; Sat, 10 Apr 1999 06:12:51 -0500 (CDT) From: dickey@clark.net Message-Id: <199904101112.HAA28365@shell.clark.net> Subject: Re: lynx-dev small? patch to dev21 patched with psrc patch To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 07:12:48 -0400 (EDT) In-Reply-To: from "Vlad Harchev " at Apr 10, 99 03:36:10 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 632 Lines: 19 > Recently (in message with title 'fix to psrc patch') I've sent a correction > to psrc patch. It consisted of: > * verbal request to replace #define OMIT_SCN_KEEPING from 1 to 0 in HTML.c > and LYCurses.c. This modification doesn't interfere with patch - so such > change still must be performed. > > * Small patch that fixed comment in lynx.cfg. This patch should be undone. thanks (I've started work on dev.22, probably will be done tomorrow since I delayed working on my tax forms - have to do them now) > Best regards, > -Vlad -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 10 09:52:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA02817 for ; Sat, 10 Apr 1999 09:52:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA21262; Sat, 10 Apr 1999 08:41:02 -0500 (CDT) Date: Sat, 10 Apr 1999 14:40:58 +0100 (BST) From: "C.J.LAWSON" X-Sender: fx942976@robin.pegasus.cranfield.ac.uk To: lynx-dev@sig.net Subject: Re: lynx-dev virtual html pages (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 907 Lines: 38 Thanks!! On Fri, 9 Apr 1999, Doug Kaufman wrote: > On Fri, 9 Apr 1999, C.J.LAWSON wrote: > > > > Exactly how did you try piping the result to lynx? > > As one would expect on a unix box > > > > txt2html | lynx > > > > normally txt2html dumps the result to stdout > > > > To see how to do this see the following message from Bela Lubkin in the > archives. > "http://www.flora.org/lynx-dev/html/month1098/msg00295.html" > Doug > __ > Doug Kaufman > Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu > > --- Jonathan Lawson Thermal Processes Unit Department of Applied Energy and Optical Diagnostics School of Mechanical Engineering, Cranfield University, Cranfield, Bedford. UK. email j.lawson@cranfield.ac.uk So teach us to number our days, that we may apply our hearts unto wisdom. Ps 90:12 From owner-lynx-dev@sig.net Sat Apr 10 10:22:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA03728 for ; Sat, 10 Apr 1999 10:22:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26373; Sat, 10 Apr 1999 09:17:01 -0500 (CDT) Date: Sat, 10 Apr 1999 00:22:36 -0700 (PDT) From: Subir Grewal To: Lynx Development List Cc: "Laimins, Eric" Subject: lynx-dev OS-400 Version of Lynx? (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1197 Lines: 34 Eric, I'm out of the country, but I'm forwarding your message to lynx-dev, someone there should be able to answer your query. Subir ---------- Forwarded message ---------- Date: Thu, 1 Apr 1999 13:07:26 -0500 From: "Laimins, Eric" To: lynx-platforms@trill-home.com Subject: OS-400 Version of Lynx? Out of curiosity, has anyone ever ported Lynx to OS-400? We are looking for a way to get a text only browser to dumb-terminals attached to an AS/400... Essentially, we need to give insurance companies access to our web-site. This poses a problem given the fact that the insurance industry is running a series of legacy mainframe/mid-range machines. Many of them are running MVS (which makes Lynx attractive for our use), but many are running OS/400. Since most (if not all) of these companies are terrified of the cost of putting a PC on everyone's desk, we need a text only OS/400 browser. Do you have any ideas? Would porting Lynx to this platform pose any significant problem based on your experience? Is there another browser out there that we could use? Any help is greatly appreciated, Eric Laimins Director of Business Development Premier Car Rental From owner-lynx-dev@sig.net Sat Apr 10 12:04:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA05986 for ; Sat, 10 Apr 1999 12:04:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA01875; Sat, 10 Apr 1999 10:56:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904101556.LAA29357@shell.clark.net> Subject: Re: lynx-dev OS-400 Version of Lynx? (fwd) To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 11:56:07 -0400 (EDT) Cc: ELaimins@PremierCar.com In-Reply-To: from "Subir Grewal " at Apr 10, 99 00:22:36 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1506 Lines: 42 Is OS-400 anything like OS-390? one of the developers has made changes to lynx over the past several months to accommodate that system. > > Eric, > > I'm out of the country, but I'm forwarding your message to lynx-dev, > someone there should be able to answer your query. > > Subir > > > ---------- Forwarded message ---------- > Date: Thu, 1 Apr 1999 13:07:26 -0500 > From: "Laimins, Eric" > To: lynx-platforms@trill-home.com > Subject: OS-400 Version of Lynx? > > Out of curiosity, has anyone ever ported Lynx to OS-400? We are looking > for a way to get a text only browser to dumb-terminals attached to an > AS/400... > > Essentially, we need to give insurance companies access to our web-site. > This poses a problem given the fact that the insurance industry is > running a series of legacy mainframe/mid-range machines. Many of them > are running MVS (which makes Lynx attractive for our use), but many are > running OS/400. Since most (if not all) of these companies are > terrified of the cost of putting a PC on everyone's desk, we need a text > only OS/400 browser. Do you have any ideas? Would porting Lynx to this > platform pose any significant problem based on your experience? Is > there another browser out there that we could use? > > Any help is greatly appreciated, > Eric Laimins > Director of Business Development > Premier Car Rental -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 10 13:31:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA08070 for ; Sat, 10 Apr 1999 13:31:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA14371; Sat, 10 Apr 1999 12:23:36 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904101723.LAA16246@sanitas> Subject: Re: lynx-dev OS-400 Version of Lynx? (fwd) To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 11:23:02 -0600 (MDT) Cc: ELaimins@PremierCar.com In-Reply-To: <199904101556.LAA29357@shell.clark.net> from "dickey@clark.net" at Apr 10, 99 11:56:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1977 Lines: 40 In a recent note, dickey@clark.net said: > Date: Sat, 10 Apr 1999 11:56:07 -0400 (EDT) > > Is OS-400 anything like OS-390? one of the developers has made changes > to lynx over the past several months to accommodate that system. > > > ---------- Forwarded message ---------- > > Date: Thu, 1 Apr 1999 13:07:26 -0500 > > From: "Laimins, Eric" > > > > Out of curiosity, has anyone ever ported Lynx to OS-400? We are looking > > for a way to get a text only browser to dumb-terminals attached to an > > AS/400... > > > > Essentially, we need to give insurance companies access to our web-site. > > This poses a problem given the fact that the insurance industry is > > running a series of legacy mainframe/mid-range machines. Many of them > > are running MVS (which makes Lynx attractive for our use), but many are > > running OS/400. Since most (if not all) of these companies are > > terrified of the cost of putting a PC on everyone's desk, we need a text > > only OS/400 browser. Do you have any ideas? Would porting Lynx to this > > platform pose any significant problem based on your experience? Is > > there another browser out there that we could use? > > I believe OS-400 is similar to OS/390 only in using EBCDIC rather than ASCII. But the EBCDIC support is present in recent development versions of Lynx (not the "stable" 2.8.1rel2). It still depends on a curses library, which is now available for OS/390. But this depends on what you mean by a "dumb-terminal". On OS/390, Lynx requires an Xterm, vt100 or the like (connected via telnet or rlogin); a 3270 is not supported. Rule of thumb: if vi or emacs works, Lynx probably will; otherwise probably not. I also understand OS-400 suffers a 6.3 single-case file naming restriction. Lynx has been ported to systems with 8.3 single-case file names; 6.3 may be harder. (Offhand, I think of LYMain.c and LYMainLoop.c, which become ambiguous at 6.3). -- gil From owner-lynx-dev@sig.net Sat Apr 10 20:13:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA17222 for ; Sat, 10 Apr 1999 20:13:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA18769; Sat, 10 Apr 1999 19:02:44 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904110002.SAA16974@sanitas> Subject: Re: lynx-dev OS-400 Version of Lynx? (fwd) To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 18:02:10 -0600 (MDT) Cc: ELaimins@PremierCar.com In-Reply-To: <199904101723.LAA16246@sanitas> from "pg@sweng.stortek.com" at Apr 10, 99 11:23:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 711 Lines: 20 In a recent note, pg@sweng.stortek.com said: > Date: Sat, 10 Apr 1999 11:23:02 -0600 (MDT) > > > Date: Thu, 1 Apr 1999 13:07:26 -0500 > > From: "Laimins, Eric" > > > > terrified of the cost of putting a PC on everyone's desk, we need a text > > only OS/400 browser. Do you have any ideas? Would porting Lynx to this > > platform pose any significant problem based on your experience? Is > > there another browser out there that we could use? > > Someone else has pointed me to: Linkname: EnterWEB, the 3270 web browser - Internet and intranet access from a 3270 terminal URL: http://www.macro4.com/enterweb/ (he more text browsers, the better. :-) -- gil From owner-lynx-dev@sig.net Sat Apr 10 21:08:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA18327 for ; Sat, 10 Apr 1999 21:08:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA26787; Sat, 10 Apr 1999 20:00:37 -0500 (CDT) Message-Id: <199904110053.TAA25753@roadrunner.sig.net> To: lynx-dev@sig.net CC: amoraila@mixmail.com From: Alejandro Moraila Date: Sat, 10 Apr 99 20:51:39 -0400 Subject: lynx-dev ayuda X-Mailer: LatinMail v3.0 -- http://www.latinmail.com Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 580 Lines: 18 Hi my name is alejandro, I'm from Mexico, and,I'm conected with a LAN net, and the file "lynx.exe" say this "alert Unable to conect to remote host", and "cant access startfile http://linx.browser.org" I think that the reason is that I didn't create a "Lynx.bat". I don't know how to create a bat file, and what I put inside of this file. Sorry, because my english is very poor. Thanks Moraila Tostado Jesus Alejandro.... Mail: amoraila@mixmail.com ___________________________________________________________ Consigue tu página web gratuita en http://www.gratisweb.com From owner-lynx-dev@sig.net Sat Apr 10 21:21:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA18566 for ; Sat, 10 Apr 1999 21:21:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA29022; Sat, 10 Apr 1999 20:15:49 -0500 (CDT) Date: Sat, 10 Apr 1999 18:15:46 -0700 (PDT) From: David Combs Message-Id: <199904110115.SAA14954@netcom15.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: neat new search engine at www.google.com Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 86 Lines: 4 Looks really good. Is beta version, it says. comes out of the cs dept at stanford. From owner-lynx-dev@sig.net Sat Apr 10 22:01:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA19485 for ; Sat, 10 Apr 1999 22:01:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA04839; Sat, 10 Apr 1999 20:55:13 -0500 (CDT) From: Philip Webb Message-Id: <199904110153.VAA01374@chass.utoronto.ca> Subject: Re: lynx-dev ayuda To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 21:53:48 -0400 (EDT) Cc: amoraila@mixmail.com, amoraila@latinmail.com In-Reply-To: <199904110053.TAA25753@roadrunner.sig.net> from "Alejandro Moraila" at Apr 10, 99 08:51:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1166 Lines: 24 990410 Alejandro Moraila wrote: > I'm conected with a LAN net and the file "lynx.exe" say > this "alert Unable to conect to remote host", > and "cant access startfile http://linx.browser.org". probably, that site is down for some reason: try lynx http://www.ft.com/ or lynx http://www.washingtonpost.com/ , both well-known (English) newspapers, which should be available; that will simply get Lynx started, then you can go where you want. you can also try lynx http://. (yes, `.'), which will start with your current directory, if your system allows that. > I think that the reason is that I didn't create a "Lynx.bat". > I don't know how to create a bat file, and what I put inside of this file. probably not: if you still have a problem after trying the above, tell us again, with as much detail about your system & software as you can, including the version of Lynx (latest is 2-8-1). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 00:14:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22643 for ; Sun, 11 Apr 1999 00:14:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA22809; Sat, 10 Apr 1999 23:00:32 -0500 (CDT) From: Philip Webb Message-Id: <199904110359.XAA06684@chass.utoronto.ca> Subject: Re: lynx-dev ayuda To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 23:59:08 -0400 (EDT) Cc: amoraila@mixmail.com In-Reply-To: <199904110153.VAA01374@chass.utoronto.ca> from "Philip Webb" at Apr 10, 99 09:53:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 498 Lines: 11 990410 i wrote -- while doing too many others things today -- : > you can also try lynx http://. (yes, `.'), > which will start with your current directory, if your system allows that. that should be lynx . (yes, just `.'). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 00:16:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22827 for ; Sun, 11 Apr 1999 00:16:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA22753; Sat, 10 Apr 1999 23:00:11 -0500 (CDT) Date: Sat, 10 Apr 1999 23:59:55 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: Lynx Development List Subject: lynx-dev PATCH [dev21]: source caching Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-719902432-923803195=:3224" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 33709 Lines: 565 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-719902432-923803195=:3224 Content-Type: TEXT/PLAIN; charset=US-ASCII On the If You Want This New Feature, Why Don't You Code It Yourself principle, and because I finally got fed up with reloading an entire document just to look at the source or turn on image links (and because so many other people have asked for it... and just to prove it could be done...), I submit the enclosed patch against dev21 implementing HTML source caching. In this implementation, each document kept in cache has associated with it a temporary file containing the HTML source for the document (well, not all of them -- only those using the HTTP protocol, on the premise that file:// documents are probably local and ftp:// documents are probably not HTML). The temporary file is deleted when the document is uncached. For certain operations, instead of reloading the document via HTLoad(), the source file is reparsed with HTParseFile(). The cached document also remembers certain parser settings (screen size, historical vs. minimal vs. valid comment parsing, and the like), and is regenerated from source if it is fetched out of cache under different settings. This behavior is selectable by a configure option --enable-source-cache and by a lynx.cfg option SOURCE_CACHE; I didn't add a command-line argument or an options menu entry, as this didn't seem to be the sort of thing one would want to change at runtime. Assorted notes: - Oddly, some of the commands I modified reload the document by faking an LYK_RELOAD, and some by calling HTuncache_current_document(). Any particular reason for the difference? I ask because the latter did the HTuncache_...() before printing the associated message and I had to move it after to get the reparse to work, and I probably did it wrong. - I try to be intelligent about passing the source cache file along to the newly generated HText, but I'm a bit nervous about passing it around in a global variable... As always, apply with caution; I've almost certainly gotten something wrong. (I wonder if this is gonna start up that whole argument again....) -sbigham --8323328-719902432-923803195=:3224 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="source_cache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="source_cache.diff" KioqIC4vc3JjL0dyaWRUZXh0LmMub3JpZwlUdWUgTWFyIDMwIDEyOjEwOjM3 IDE5OTkNCi0tLSAuL3NyYy9HcmlkVGV4dC5jCVNhdCBBcHIgMTAgMjI6MDQ6 MDAgMTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogNDYsNTEgKioqKg0KLS0t IDQ2LDU1IC0tLS0NCiAgDQogICN1bmRlZiBERUJVR19BUFBDSA0KICANCisg I2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAjaW5jbHVkZSA8SFRGaWxlLmg+DQor ICNlbmRpZg0KKyANCiAgI2lmZGVmIFVTRV9DT0xPUl9TVFlMRQ0KICAjaW5j bHVkZSA8QXR0ckxpc3QuaD4NCiAgI2luY2x1ZGUgPExZSGFzaC5oPg0KKioq KioqKioqKioqKioqDQoqKiogMTE0LDExOSAqKioqDQotLS0gMTE4LDEyOCAt LS0tDQogIFBVQkxJQyBCT09MRUFOIHVuZGVybGluZV9vbiA9IE9GRjsNCiAg UFVCTElDIEJPT0xFQU4gYm9sZF9vbiAgICAgID0gT0ZGOw0KICANCisgI2lm ZGVmIFNPVVJDRV9DQUNIRQ0KKyBQVUJMSUMgY2hhciAqIHNvdXJjZV9jYWNo ZV9maWxlbmFtZSA9IE5VTEw7DQorIFBVQkxJQyBCT09MRUFOIExZQ2FjaGVT b3VyY2UgPSBUUlVFOw0KKyAjZW5kaWYNCisgDQogICNpZiBkZWZpbmVkKFVT RV9DT0xPUl9TVFlMRSkNCiAgI2RlZmluZSBNQVhfU1RZTEVTX09OX0xJTkUg NjQNCiAgDQoqKioqKioqKioqKioqKioNCioqKiAxNzMsMTc4ICoqKioNCi0t LSAxODIsMjAyIC0tLS0NCiAgKi8NCiAgc3RydWN0IF9IVGV4dCB7DQogIAlI VFBhcmVudEFuY2hvciAqCW5vZGVfYW5jaG9yOw0KKyAjaWZkZWYgU09VUkNF X0NBQ0hFDQorIAljaGFyICoJCQlzb3VyY2VfY2FjaGU7DQorIAkvKg0KKyAJ ICogUGFyc2Ugc2V0dGluZ3Mgd2hlbiB0aGlzIEhUZXh0IHdhcyBnZW5lcmF0 ZWQuDQorIAkgKi8NCisgCUJPT0xFQU4JCQljbGlja2FibGVfaW1hZ2VzOw0K KyAJQk9PTEVBTgkJCXBzZXVkb19pbmxpbmVfYWx0czsNCisgCUJPT0xFQU4J CQlyYXdfbW9kZTsNCisgCUJPT0xFQU4JCQloaXN0b3JpY2FsX2NvbW1lbnRz Ow0KKyAJQk9PTEVBTgkJCW1pbmltYWxfY29tbWVudHM7DQorIAlCT09MRUFO CQkJc29mdF9kcXVvdGVzOw0KKyAJQk9PTEVBTgkJCW9sZF9kdGQ7DQorIAlp bnQJCQlsaW5lczsJCS8qIFNjcmVlbiBzaXplICovDQorIAlpbnQJCQljb2xz Ow0KKyAjZW5kaWYNCiAgCUhUTGluZSAqCQlsYXN0X2xpbmU7DQogIAlpbnQJ CQlMaW5lczsJCS8qIE51bWJlciBvZiB0aGVtICovDQogIAlpbnQJCQljaGFy czsJCS8qIE51bWJlciBvZiB0aGVtICovDQoqKioqKioqKioqKioqKioNCioq KiA0ODMsNDg4ICoqKioNCi0tLSA1MDcsNTM1IC0tLS0NCiAgICAgIHNlbGYt PnN0YWxlID0gWUVTOw0KICAgICAgc2VsZi0+dG9vbGJhciA9IE5POw0KICAg ICAgc2VsZi0+dGFicyA9IE5VTEw7DQorICNpZmRlZiBTT1VSQ0VfQ0FDSEUN CisgICAgIC8qDQorICAgICAgKiBZZXMsIHRoaXMgaXMgYSBHcm9zcyBBbmQg RGlzZ3VzdGluZyBIYWNrKFRNKSwgSSBrbm93Li4uDQorICAgICAgKi8NCisg ICAgIHNlbGYtPnNvdXJjZV9jYWNoZSA9IE5VTEw7DQorICAgICBpZiAoTFlD YWNoZVNvdXJjZSAmJiBzb3VyY2VfY2FjaGVfZmlsZW5hbWUpIHsNCisgICAg ICAgU3RyQWxsb2NDb3B5KHNlbGYtPnNvdXJjZV9jYWNoZSwgc291cmNlX2Nh Y2hlX2ZpbGVuYW1lKTsNCisgICAgICAgRlJFRShzb3VyY2VfY2FjaGVfZmls ZW5hbWUpOw0KKyAgICAgfQ0KKyANCisgICAgIC8qDQorICAgICAgKiBSZW1l bWJlciB0aGUgcGFyc2Ugc2V0dGluZ3MuDQorICAgICAgKi8NCisgICAgIHNl bGYtPmNsaWNrYWJsZV9pbWFnZXMgPSBjbGlja2FibGVfaW1hZ2VzOw0KKyAg ICAgc2VsZi0+cHNldWRvX2lubGluZV9hbHRzID0gcHNldWRvX2lubGluZV9h bHRzOw0KKyAgICAgc2VsZi0+cmF3X21vZGUgPSBMWVJhd01vZGU7DQorICAg ICBzZWxmLT5oaXN0b3JpY2FsX2NvbW1lbnRzID0gaGlzdG9yaWNhbF9jb21t ZW50czsNCisgICAgIHNlbGYtPm1pbmltYWxfY29tbWVudHMgPSBtaW5pbWFs X2NvbW1lbnRzOw0KKyAgICAgc2VsZi0+c29mdF9kcXVvdGVzID0gc29mdF9k cXVvdGVzOw0KKyAgICAgc2VsZi0+b2xkX2R0ZCA9IE9sZF9EVEQ7DQorICAg ICBzZWxmLT5saW5lcyA9IExZbGluZXM7DQorICAgICBzZWxmLT5jb2xzID0g TFljb2xzOw0KKyAjZW5kaWYNCiAgICAgIC8qDQogICAgICAgKiAgSWYgd2Ug YXJlIGdvaW5nIHRvIHJlbmRlciB0aGUgTGlzdCBQYWdlLCBhbHdheXMgbWVy Z2UgaW4gaGlkZGVuDQogICAgICAgKiAgbGlua3MgdG8gZ2V0IHRoZSBudW1i ZXJpbmcgY29uc2lzdGVudCBpZiBmb3JtIGZpZWxkcyBhcmUgbnVtYmVyZWQN CioqKioqKioqKioqKioqKg0KKioqIDcyOSw3MzQgKioqKg0KLS0tIDc3Niw3 OTIgLS0tLQ0KICAJICAgIEhUTWFpbkFuY2hvciA9IE5VTEw7DQogICAgICB9 DQogIA0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorICAgICAvKg0KKyAgICAg ICogQ2xlYW4gdXAgdGhlIHNvdXJjZSBjYWNoZSBmaWxlLCBpZiBhbnkuDQor ICAgICAgKi8NCisgICAgIGlmIChzZWxmLT5zb3VyY2VfY2FjaGUpIHsNCisg CUNUUkFDRSh0ZnAsICJSZW1vdmluZyBzb3VyY2UgY2FjaGUgZmlsZSAlc1xu Iiwgc2VsZi0+c291cmNlX2NhY2hlKTsNCisgCXVubGluayhzZWxmLT5zb3Vy Y2VfY2FjaGUpOw0KKyAJRlJFRShzZWxmLT5zb3VyY2VfY2FjaGUpOw0KKyAg ICAgfQ0KKyAjZW5kaWYNCisgDQogICAgICBGUkVFKHNlbGYpOw0KICB9DQog IA0KKioqKioqKioqKioqKioqDQoqKiogNjE4OSw2MTk0ICoqKioNCi0tLSA2 MjQ3LDYzNTMgLS0tLQ0KICAJQ1RSQUNFKHRmcCwgIkhUdW5jYWNoZS4uIEhU TWFpblRleHQgYWxyZWFkeSBpcyBOVUxMIVxuIik7DQogICAgICB9DQogIH0N CisgDQorICNpZmRlZiBTT1VSQ0VfQ0FDSEUNCisgUFVCTElDIEJPT0xFQU4g SFRyZXBhcnNlX2RvY3VtZW50IE5PQVJHUw0KKyB7DQorICAgICBGSUxFICog ZnA7DQorICAgICBIVEZvcm1hdCBmb3JtYXQ7DQorICAgICBpbnQgcmV0Ow0K KyANCisgICAgIGlmICghSFRNYWluVGV4dCB8fCAhSFRNYWluVGV4dC0+c291 cmNlX2NhY2hlKQ0KKyAJcmV0dXJuIEZBTFNFOw0KKyAgICAgQ1RSQUNFKHRm cCwgIlJlcGFyc2luZyBzb3VyY2UgY2FjaGUgZmlsZSAlc1xuIiwgSFRNYWlu VGV4dC0+c291cmNlX2NhY2hlKTsNCisgDQorICAgICAvKg0KKyAgICAgICog VGhpcyBpcyBtb3JlIG9yIGxlc3MgY29waWVkIG91dCBvZiBIVExvYWRGaWxl KCksIGV4Y2VwdCB3ZSBkb24ndCBnZXQNCisgICAgICAqIGEgY29udGVudCBl bmNvZGluZy4gIFRoaXMgbWF5IGJlIG92ZXJraWxsLi4uDQorICAgICAgKi8N CisgICAgIGlmIChIVE1haW5UZXh0LT5ub2RlX2FuY2hvci0+Y29udGVudF90 eXBlKSB7DQorIAlmb3JtYXQgPSBIVEF0b21fZm9yKEhUTWFpblRleHQtPm5v ZGVfYW5jaG9yLT5jb250ZW50X3R5cGUpOw0KKyAgICAgfSBlbHNlIHsNCisg CWZvcm1hdCA9IEhURmlsZUZvcm1hdChIVE1haW5UZXh0LT5zb3VyY2VfY2Fj aGUsIE5VTEwsIE5VTEwpOw0KKyAJZm9ybWF0ID0gSFRDaGFyc2V0Rm9ybWF0 KGZvcm1hdCwgSFRNYWluVGV4dC0+bm9kZV9hbmNob3IsDQorIAkJCQkgVUNM WWhuZGxfSFRGaWxlX2Zvcl91bnNwZWMpOw0KKyAgICAgfQ0KKyAgICAgQ1RS QUNFKHRmcCwgIiAgQ29udGVudCB0eXBlIGlzIFwiJXNcIlxuIiwgZm9ybWF0 LT5uYW1lKTsNCisgDQorICAgICAvKg0KKyAgICAgICogUGFzcyB0aGUgc291 cmNlIGNhY2hlIGZpbGVuYW1lIG9uIHRvIHRoZSBuZXh0IEhUZXh0LiAgTWFy ayBpdCBOVUxMDQorICAgICAgKiBoZXJlIHNvIHRoYXQgaXQgd29uJ3QgZ2V0 IGRlbGV0ZWQgYnkgSFRleHRfZnJlZSgpLg0KKyAgICAgICovDQorICAgICBz b3VyY2VfY2FjaGVfZmlsZW5hbWUgPSBIVE1haW5UZXh0LT5zb3VyY2VfY2Fj aGU7DQorICAgICBIVE1haW5UZXh0LT5zb3VyY2VfY2FjaGUgPSBOVUxMOw0K KyANCisgICAgIGZwID0gZm9wZW4oc291cmNlX2NhY2hlX2ZpbGVuYW1lLCAi ciIpOw0KKyAgICAgaWYgKCFmcCkgew0KKyAJQ1RSQUNFKHRmcCwgIiAgQ2Fu bm90IHJlYWQgZmlsZSAlc1xuIiwgc291cmNlX2NhY2hlX2ZpbGVuYW1lKTsN CisgCUZSRUUoc291cmNlX2NhY2hlX2ZpbGVuYW1lKTsNCisgCXJldHVybiBG QUxTRTsNCisgICAgIH0NCisgICAgIHJldCA9IEhUUGFyc2VGaWxlKGZvcm1h dCwgSFRPdXRwdXRGb3JtYXQsIEhUTWFpblRleHQtPm5vZGVfYW5jaG9yLCBm cCwNCisgCQkgICAgICBOVUxMKTsNCisgICAgIGZjbG9zZShmcCk7DQorICAg ICBDVFJBQ0UodGZwLCAiUmVwYXJzZSAlc1xuIiwgKHJldCA9PSBIVF9MT0FE RUQgPyAic3VjY2VlZGVkIiA6ICJmYWlsZWQiKSk7DQorICAgICBpZiAocmV0 ICE9IEhUX0xPQURFRCkNCisgCUZSRUUoc291cmNlX2NhY2hlX2ZpbGVuYW1l KTsNCisgICAgIHJldHVybiAocmV0ID09IEhUX0xPQURFRCk7DQorIH0NCisg DQorIFBSSVZBVEUgdm9pZCB0cmFjZV9zZXR0aW5nX2NoYW5nZSBBUkdTMygN CisgCUNPTlNUIGNoYXIgKiwJbmFtZSwNCisgCUJPT0xFQU4sCXByZXZfc2V0 dGluZywNCisgCUJPT0xFQU4sCW5ld19zZXR0aW5nKQ0KKyB7DQorICAgICBp ZiAocHJldl9zZXR0aW5nICE9IG5ld19zZXR0aW5nKQ0KKyAJQ1RSQUNFKHRm cCwgIkhUZG9jdW1lbnRfc2V0dGluZ3NfY2hhbmdlZDogJXMgc2V0dGluZyBo YXMgY2hhbmdlZCAod2FzICVzLCBub3cgJXMpXG4iLA0KKyAJICAgICAgIG5h bWUsIHByZXZfc2V0dGluZyA/ICJPTiIgOiAiT0ZGIiwgbmV3X3NldHRpbmcg PyAiT04iIDogIk9GRiIpOw0KKyB9DQorIA0KKyBQVUJMSUMgQk9PTEVBTiBI VGRvY3VtZW50X3NldHRpbmdzX2NoYW5nZWQgTk9BUkdTDQorIHsNCisgICAg IC8qDQorICAgICAgKiBBbm5veWluZyBIYWNrKFRNKTogIElmIHdlIGRvbid0 IGhhdmUgYSBzb3VyY2UgY2FjaGUgZmlsZW5hbWUsIHdlIGNhbid0DQorICAg ICAgKiByZXBhcnNlIGFueXdheSwgc28gcHJldGVuZCB0aGUgc3RhdGUgaGFz bid0IGNoYW5nZWQuDQorICAgICAgKi8NCisgICAgIGlmICghSFRNYWluVGV4 dCB8fCAhSFRNYWluVGV4dC0+c291cmNlX2NhY2hlKQ0KKyAJcmV0dXJuIEZB TFNFOw0KKyANCisgICAgIGlmIChUUkFDRSkgew0KKyAJLyoNCisgCSAqIElm IHdlJ3JlIHRyYWNpbmcsIG5vdGUgZXZlcnlpbmcgdGhhdCBoYXMgY2hhbmdl ZC4NCisgCSAqLw0KKyAJdHJhY2Vfc2V0dGluZ19jaGFuZ2UoIkNMSUNLQUJM RV9JTUFHRVMiLA0KKyAJCQkgICAgIEhUTWFpblRleHQtPmNsaWNrYWJsZV9p bWFnZXMsIGNsaWNrYWJsZV9pbWFnZXMpOw0KKyAJdHJhY2Vfc2V0dGluZ19j aGFuZ2UoIlBTRVVET19JTkxJTkVfQUxUUyIsDQorIAkJCSAgICAgSFRNYWlu VGV4dC0+cHNldWRvX2lubGluZV9hbHRzLA0KKyAJCQkgICAgIHBzZXVkb19p bmxpbmVfYWx0cyk7DQorIAl0cmFjZV9zZXR0aW5nX2NoYW5nZSgiUkFXX01P REUiLCBIVE1haW5UZXh0LT5yYXdfbW9kZSwgTFlSYXdNb2RlKTsNCisgCXRy YWNlX3NldHRpbmdfY2hhbmdlKCJISVNUT1JJQ0FMX0NPTU1FTlRTIiwNCisg CQkJICAgICBIVE1haW5UZXh0LT5oaXN0b3JpY2FsX2NvbW1lbnRzLA0KKyAJ CQkgICAgIGhpc3RvcmljYWxfY29tbWVudHMpOw0KKyAJdHJhY2Vfc2V0dGlu Z19jaGFuZ2UoIk1JTklNQUxfQ09NTUVOVFMiLA0KKyAJCQkgICAgIEhUTWFp blRleHQtPm1pbmltYWxfY29tbWVudHMsIG1pbmltYWxfY29tbWVudHMpOw0K KyAJdHJhY2Vfc2V0dGluZ19jaGFuZ2UoIlNPRlRfRFFVT1RFUyIsDQorIAkJ CSAgICAgSFRNYWluVGV4dC0+c29mdF9kcXVvdGVzLCBzb2Z0X2RxdW90ZXMp Ow0KKyAJdHJhY2Vfc2V0dGluZ19jaGFuZ2UoIk9MRF9EVEQiLCBIVE1haW5U ZXh0LT5vbGRfZHRkLCBPbGRfRFREKTsNCisgCWlmIChIVE1haW5UZXh0LT5s aW5lcyAhPSBMWWxpbmVzIHx8IEhUTWFpblRleHQtPmNvbHMgIT0gTFljb2xz KQ0KKyAJICAgIENUUkFDRSh0ZnAsDQorIAkJICAgIkhUZG9jdW1lbnRfc2V0 dGluZ3NfY2hhbmdlZDogU2NyZWVuIHNpemUgaGFzIGNoYW5nZWQgKHdhcyAl ZHglZCwgbm93ICVkeCVkKVxuIiwNCisgCQkgICBIVE1haW5UZXh0LT5jb2xz LCBIVE1haW5UZXh0LT5saW5lcywgTFljb2xzLCBMWWxpbmVzKTsNCisgICAg IH0NCisgDQorICAgICByZXR1cm4gKEhUTWFpblRleHQtPmNsaWNrYWJsZV9p bWFnZXMgIT0gY2xpY2thYmxlX2ltYWdlcyB8fA0KKyAJICAgIEhUTWFpblRl eHQtPnBzZXVkb19pbmxpbmVfYWx0cyAhPSBwc2V1ZG9faW5saW5lX2FsdHMg fHwNCisgCSAgICBIVE1haW5UZXh0LT5yYXdfbW9kZSAhPSBMWVJhd01vZGUg fHwNCisgCSAgICBIVE1haW5UZXh0LT5oaXN0b3JpY2FsX2NvbW1lbnRzICE9 IGhpc3RvcmljYWxfY29tbWVudHMgfHwNCisgCSAgICBIVE1haW5UZXh0LT5t aW5pbWFsX2NvbW1lbnRzICE9IG1pbmltYWxfY29tbWVudHMgfHwNCisgCSAg ICBIVE1haW5UZXh0LT5zb2Z0X2RxdW90ZXMgIT0gc29mdF9kcXVvdGVzIHx8 DQorIAkgICAgSFRNYWluVGV4dC0+b2xkX2R0ZCAhPSBPbGRfRFREIHx8DQor IAkgICAgSFRNYWluVGV4dC0+bGluZXMgIT0gTFlsaW5lcyB8fA0KKyAJICAg IEhUTWFpblRleHQtPmNvbHMgIT0gTFljb2xzKTsNCisgfQ0KKyAjZW5kaWYN CiAgDQogIFBVQkxJQyBpbnQgSFRpc0RvY3VtZW50U291cmNlIE5PQVJHUw0K ICB7DQoqKiogLi9zcmMvSFRNTC5jLm9yaWcJV2VkIE1hciAxNyAyMjoxNzox MSAxOTk5DQotLS0gLi9zcmMvSFRNTC5jCVNhdCBBcHIgMTAgMjI6MDY6NDEg MTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogNTgsNjMgKioqKg0KLS0tIDU4 LDY3IC0tLS0NCiAgI2RlZmluZSBwSFRleHRfY2hhbmdlU3R5bGUoWCxZLFop IHt9DQogICNlbmRpZg0KICANCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAj aW5jbHVkZSA8SFRBY2Nlc3MuaD4NCisgI2VuZGlmDQorIA0KICAjaW5jbHVk ZSA8TFlleGl0Lmg+DQogICNpbmNsdWRlIDxMWUxlYWtzLmg+DQogIA0KKioq KioqKioqKioqKioqDQoqKiogNzMsNzkgKioqKg0KLS0tIDc3LDg5IC0tLS0N CiAgDQogIHN0cnVjdCBfSFRTdHJlYW0gew0KICAgICAgQ09OU1QgSFRTdHJl YW1DbGFzcyAqCWlzYTsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAg RklMRSAqCQkJZnA7DQorICAgICBDT05TVCBIVFN0cmVhbUNsYXNzICoJYWN0 aW9uczsNCisgICAgIEhUU3RyZWFtICoJCQl0YXJnZXQ7DQorICNlbHNlDQog ICAgICAvKiAuLi4uICovDQorICNlbmRpZg0KICB9Ow0KICANCiAgUFJJVkFU RSBIVFN0eWxlU2hlZXQgKiBzdHlsZVNoZWV0ID0gTlVMTDsJLyogQXBwbGlj YXRpb24td2lkZSAqLw0KKioqKioqKioqKioqKioqDQoqKiogNzMwMCw3MzA1 ICoqKioNCi0tLSA3MzEwLDc0MjggLS0tLQ0KICAgICAgcmV0dXJuIChIVFN0 cnVjdHVyZWQqKSBtZTsNCiAgfQ0KICANCisgI2lmZGVmIFNPVVJDRV9DQUNI RQ0KKyAvKg0KKyAgKiBQYXNzLXRocnUgY2FjaGUgSFRTdHJlYW0NCisgICov DQorIA0KKyBQUklWQVRFIHZvaWQgQ2FjaGVUaHJ1X2ZyZWUgQVJHUzEoDQor IAlIVFN0cmVhbSAqLAltZSkNCisgew0KKyAgICAgZmNsb3NlKG1lLT5mcCk7 DQorICAgICAoKm1lLT5hY3Rpb25zLT5fZnJlZSkobWUtPnRhcmdldCk7DQor ICAgICBGUkVFKG1lKTsNCisgfQ0KKyANCisgUFJJVkFURSB2b2lkIENhY2hl VGhydV9hYm9ydCBBUkdTMigNCisgCUhUU3RyZWFtICosCW1lLA0KKyAJSFRF cnJvciwJZSkNCisgew0KKyAgICAgZmNsb3NlKG1lLT5mcCk7DQorICAgICAo Km1lLT5hY3Rpb25zLT5fYWJvcnQpKG1lLT50YXJnZXQsIGUpOw0KKyAgICAg RlJFRShtZSk7DQorIH0NCisgDQorIFBSSVZBVEUgdm9pZCBDYWNoZVRocnVf cHV0X2NoYXJhY3RlciBBUkdTMigNCisgCUhUU3RyZWFtICosCW1lLA0KKyAJ Y2hhciwJCWNfaW4pDQorIHsNCisgICAgIGZwdXRjKGNfaW4sIG1lLT5mcCk7 DQorICAgICAoKm1lLT5hY3Rpb25zLT5wdXRfY2hhcmFjdGVyKShtZS0+dGFy Z2V0LCBjX2luKTsNCisgfQ0KKyANCisgUFJJVkFURSB2b2lkIENhY2hlVGhy dV9wdXRfc3RyaW5nIEFSR1MyKA0KKyAJSFRTdHJlYW0gKiwJbWUsDQorIAlD T05TVCBjaGFyICosCXN0cikNCisgew0KKyAgICAgZnB1dHMoc3RyLCBtZS0+ ZnApOw0KKyAgICAgKCptZS0+YWN0aW9ucy0+cHV0X3N0cmluZykobWUtPnRh cmdldCwgc3RyKTsNCisgfQ0KKyANCisgUFJJVkFURSB2b2lkIENhY2hlVGhy dV93cml0ZSBBUkdTMygNCisgCUhUU3RyZWFtICosCW1lLA0KKyAJQ09OU1Qg Y2hhciAqLAlzdHIsDQorIAlpbnQsCQlsKQ0KKyB7DQorICAgICBmd3JpdGUo c3RyLCAxLCBsLCBtZS0+ZnApOw0KKyAgICAgKCptZS0+YWN0aW9ucy0+cHV0 X2Jsb2NrKShtZS0+dGFyZ2V0LCBzdHIsIGwpOw0KKyB9DQorIA0KKyBQUklW QVRFIENPTlNUIEhUU3RyZWFtQ2xhc3MgUGFzc1RocnVDYWNoZSA9DQorIHsN CisgICAgICJQYXNzVGhydUNhY2hlIiwNCisgICAgIENhY2hlVGhydV9mcmVl LA0KKyAgICAgQ2FjaGVUaHJ1X2Fib3J0LA0KKyAgICAgQ2FjaGVUaHJ1X3B1 dF9jaGFyYWN0ZXIsDQorICAgICBDYWNoZVRocnVfcHV0X3N0cmluZywNCisg ICAgIENhY2hlVGhydV93cml0ZQ0KKyB9Ow0KKyANCisgUFJJVkFURSBIVFN0 cmVhbSogQ2FjaGVUaHJ1X25ldyBBUkdTMigNCisgCUhUUGFyZW50QW5jaG9y ICosCWFuY2hvciwNCisgCUhUU3RyZWFtICosCQl0YXJnZXQpDQorIHsNCisg ICAgIGNoYXIgZmlsZW5hbWVbTFlfTUFYUEFUSF07DQorICAgICBGSUxFICpm cCA9IE5VTEw7DQorICAgICBIVFN0cmVhbSAqc3RyZWFtID0gTlVMTDsNCisg ICAgIEhUUHJvdG9jb2wgKnAgPSAoSFRQcm90b2NvbCAqKWFuY2hvci0+cHJv dG9jb2w7DQorICAgICANCisgICAgIC8qDQorICAgICAgKiBOZWF0bHkgYW5k IHRyYW5zcGFyZW50bHkgdmFuaXNoIGlmIHNvdXJjZSBjYWNoaW5nIGlzIGRp c2FibGVkLg0KKyAgICAgICovDQorICAgICBpZiAoIUxZQ2FjaGVTb3VyY2Up DQorIAlyZXR1cm4gdGFyZ2V0Ow0KKyANCisgICAgIGlmIChzdHJjbXAocC0+ bmFtZSwgImh0dHAiKSAhPSAwKSB7DQorIAlDVFJBQ0UodGZwLCAiUHJvdG9j b2wgaXMgXCIlc1wiOyBub3QgY2FjaGluZ1xuIiwgcC0+bmFtZSk7DQorIAly ZXR1cm4gdGFyZ2V0Ow0KKyAgICAgfQ0KKyANCisgICAgIGlmIChzb3VyY2Vf Y2FjaGVfZmlsZW5hbWUpIHsNCisgCUNUUkFDRSh0ZnAsICJSZXVzaW5nIHNv dXJjZSBjYWNoZSBmaWxlICVzXG4iLA0KKyAJICAgICAgIHNvdXJjZV9jYWNo ZV9maWxlbmFtZSk7DQorIAlyZXR1cm4gdGFyZ2V0Ow0KKyAgICAgfQ0KKyAN CisgICAgIGlmICghZm10X3RlbXBuYW1lKGZpbGVuYW1lLCBseW54X3RlbXBf c3BhY2UsIEhUTUxfU1VGRklYKSkgew0KKyAJQ1RSQUNFKHRmcCwgIkNhbm5v dCBnZXQgc291cmNlIGNhY2hlIGZpbGVuYW1lIGZvciBVUkwgJXNcbiIsDQor IAkgICAgICAgSFRBbmNob3JfYWRkcmVzcygoSFRBbmNob3IgKilhbmNob3Ip KTsNCisgCXJldHVybiB0YXJnZXQ7DQorICAgICB9DQorICAgICBpZiAoIShm cCA9IGZvcGVuKGZpbGVuYW1lLCAidyIpKSkgew0KKyAJQ1RSQUNFKHRmcCwg IkNhbm5vdCBvcGVuIHNvdXJjZSBjYWNoZSBmaWxlICVzIGZvciBVUkwgJXNc biIsDQorIAkgICAgICAgZmlsZW5hbWUsIEhUQW5jaG9yX2FkZHJlc3MoKEhU QW5jaG9yICopYW5jaG9yKSk7DQorIAlyZXR1cm4gdGFyZ2V0Ow0KKyAgICAg fQ0KKyANCisgICAgIHN0cmVhbSA9IChIVFN0cmVhbSAqKSBtYWxsb2Moc2l6 ZW9mKCpzdHJlYW0pKTsNCisgICAgIGlmICghc3RyZWFtKQ0KKyAJb3V0b2Zt ZW0oX19GSUxFX18sICJDYWNoZVRocnVfbmV3Iik7DQorIA0KKyAgICAgc3Ry ZWFtLT5pc2EgPSAmUGFzc1RocnVDYWNoZTsNCisgICAgIHN0cmVhbS0+ZnAg PSBmcDsNCisgICAgIHN0cmVhbS0+dGFyZ2V0ID0gdGFyZ2V0Ow0KKyAgICAg c3RyZWFtLT5hY3Rpb25zID0gdGFyZ2V0LT5pc2E7DQorICAgICAvKg0KKyAg ICAgICogWWVzLCB0aGlzIGlzIGEgR3Jvc3MgQW5kIERpc2d1c3RpbmcgSGFj ayhUTSksIEkga25vdy4uLg0KKyAgICAgICovDQorICAgICBTdHJBbGxvY0Nv cHkoc291cmNlX2NhY2hlX2ZpbGVuYW1lLCBmaWxlbmFtZSk7DQorIA0KKyAg ICAgQ1RSQUNFKHRmcCwgIkNhY2hpbmcgc291cmNlIGZvciBVUkwgJXMgaW4g ZmlsZSAlc1xuIiwNCisgCSAgIEhUQW5jaG9yX2FkZHJlc3MoKEhUQW5jaG9y ICopYW5jaG9yKSwgZmlsZW5hbWUpOw0KKyAgICAgcmV0dXJuIHN0cmVhbTsN CisgfQ0KKyAjZW5kaWYNCisgDQogIC8qCUhUQ29udmVydGVyIGZvciBIVE1M IHRvIHBsYWluIHRleHQNCiAgKioJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KICAqKg0KKioqKioqKioqKioqKioqDQoqKiogNzMxMyw3 MzE5ICoqKioNCi0tLSA3NDM2LDc0NDggLS0tLQ0KICAJSFRQYXJlbnRBbmNo b3IgKiwJYW5jaG9yLA0KICAJSFRTdHJlYW0gKiwJCXNpbmspDQogIHsNCisg I2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAgcmV0dXJuIENhY2hlVGhydV9u ZXcoYW5jaG9yLA0KKyAJCQkgU0dNTF9uZXcoJkhUTUxfZHRkLCBhbmNob3Is DQorIAkJCQkgIEhUTUxfbmV3KGFuY2hvciwgcHJlcy0+cmVwX291dCwgc2lu aykpKTsNCisgI2Vsc2UNCiAgICAgIHJldHVybiBTR01MX25ldygmSFRNTF9k dGQsIGFuY2hvciwgSFRNTF9uZXcoYW5jaG9yLCBwcmVzLT5yZXBfb3V0LCBz aW5rKSk7DQorICNlbmRpZg0KICB9DQogIA0KICAvKglIVENvbnZlcnRlciBm b3IgSFRNTCBzb3VyY2UgdG8gcGxhaW4gdGV4dA0KKioqKioqKioqKioqKioq DQoqKiogNzM3Miw3Mzc4ICoqKioNCi0tLSA3NTAxLDc1MTMgLS0tLQ0KICAg ICAgfQ0KICAgICAgaWYgKCFpbnRlcm1lZGlhdGUpDQogIAlyZXR1cm4gTlVM TDsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAgcmV0dXJuIENhY2hl VGhydV9uZXcoYW5jaG9yLA0KKyAJCQkgU0dNTF9uZXcoJkhUTUxfZHRkLCBh bmNob3IsDQorIAkJCQkgIEhUTUxHZW5lcmF0b3IoaW50ZXJtZWRpYXRlKSkp Ow0KKyAjZWxzZQ0KICAgICAgcmV0dXJuIFNHTUxfbmV3KCZIVE1MX2R0ZCwg YW5jaG9yLCBIVE1MR2VuZXJhdG9yKGludGVybWVkaWF0ZSkpOw0KKyAjZW5k aWYNCiAgfQ0KICANCiAgLyoJSFRDb252ZXJ0ZXIgZm9yIEhUTUwgdG8gQyBj b2RlDQoqKioqKioqKioqKioqKioNCioqKiA3Mzk3LDc0MDMgKioqKg0KLS0t IDc1MzIsNzU0MyAtLS0tDQogICAgICBodG1sLT5jb21tZW50X3N0YXJ0ID0g Ii8qICI7DQogICAgICBodG1sLT5jb21tZW50X2VuZCA9ICIgKi9cbiI7CS8q IE11c3Qgc3RhcnQgaW4gY29sIDEgZm9yIGNwcCAqLw0KICAvKiAgICBIVE1M X3B1dF9zdHJpbmcoaHRtbCxodG1sLT5jb21tZW50X3N0YXJ0KTsgKi8NCisg I2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAgcmV0dXJuIENhY2hlVGhydV9u ZXcoYW5jaG9yLA0KKyAJCQkgU0dNTF9uZXcoJkhUTUxfZHRkLCBhbmNob3Is IGh0bWwpKTsNCisgI2Vsc2UNCiAgICAgIHJldHVybiBTR01MX25ldygmSFRN TF9kdGQsIGFuY2hvciwgaHRtbCk7DQorICNlbmRpZg0KICB9DQogIA0KICAv KglQcmVzZW50ZXIgZm9yIEhUTUwNCioqKioqKioqKioqKioqKg0KKioqIDc0 MTQsNzQyMCAqKioqDQotLS0gNzU1NCw3NTY2IC0tLS0NCiAgCUhUUGFyZW50 QW5jaG9yICosCWFuY2hvciwNCiAgCUhUU3RyZWFtICosCQlzaW5rIEdDQ19V TlVTRUQpDQogIHsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAgcmV0 dXJuIENhY2hlVGhydV9uZXcoYW5jaG9yLA0KKyAJCQkgU0dNTF9uZXcoJkhU TUxfZHRkLCBhbmNob3IsDQorIAkJCQkgIEhUTUxfbmV3KGFuY2hvciwgV1dX X1BSRVNFTlQsIE5VTEwpKSk7DQorICNlbHNlDQogICAgICByZXR1cm4gU0dN TF9uZXcoJkhUTUxfZHRkLCBhbmNob3IsIEhUTUxfbmV3KGFuY2hvciwgV1dX X1BSRVNFTlQsIE5VTEwpKTsNCisgI2VuZGlmDQogIH0NCiAgI2VuZGlmIC8q ICFHVUkgKi8NCiAgDQoqKiogLi9zcmMvTFlVdGlscy5jLm9yaWcJVHVlIE1h ciAzMCAxMjoxMDozNyAxOTk5DQotLS0gLi9zcmMvTFlVdGlscy5jCVNhdCBB cHIgMTAgMDA6MDU6MTkgMTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogMzM2 OSwzMzc1ICoqKioNCiAgLyoNCiAgICogQ29uc3RydWN0IGEgdGVtcG9yYXJ5 LWZpbGVuYW1lLiAgQXNzdW1lcyByZXN1bHQgaXMgTFlfTUFYUEFUSCBjaGFy cyBsb25nLg0KICAgKi8NCiEgUFJJVkFURSBpbnQgZm10X3RlbXBuYW1lIEFS R1MzKA0KICAJY2hhciAqLAkJcmVzdWx0LA0KICAJQ09OU1QgY2hhciAqLAlw cmVmaXgsDQogIAlDT05TVCBjaGFyICosCXN1ZmZpeCkNCi0tLSAzMzY5LDMz ODEgLS0tLQ0KICAvKg0KICAgKiBDb25zdHJ1Y3QgYSB0ZW1wb3JhcnktZmls ZW5hbWUuICBBc3N1bWVzIHJlc3VsdCBpcyBMWV9NQVhQQVRIIGNoYXJzIGxv bmcuDQogICAqLw0KISAjaWZkZWYgU09VUkNFX0NBQ0hFDQohIC8qIFdlIHVz ZSB0aGlzIGVsc2V3aGVyZS4uLiAqLw0KISBQVUJMSUMNCiEgI2Vsc2UNCiEg UFJJVkFURQ0KISAjZW5kaWYNCiEgaW50IGZtdF90ZW1wbmFtZSBBUkdTMygN CiAgCWNoYXIgKiwJCXJlc3VsdCwNCiAgCUNPTlNUIGNoYXIgKiwJcHJlZml4 LA0KICAJQ09OU1QgY2hhciAqLAlzdWZmaXgpDQoqKiogLi9zcmMvTFlVdGls cy5oLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5DQotLS0gLi9zcmMv TFlVdGlscy5oCVNhdCBBcHIgMTAgMDA6MDY6NTIgMTk5OQ0KKioqKioqKioq KioqKioqDQoqKiogNjMsNjggKioqKg0KLS0tIDYzLDcxIC0tLS0NCiAgZXh0 ZXJuIEJPT0xFQU4gTFlpc0xvY2FsSG9zdCBQQVJBTVMoKGNoYXIgKmZpbGVu YW1lKSk7DQogIGV4dGVybiBCT09MRUFOIGlubG9jYWxkb21haW4gTk9QQVJB TVM7DQogIGV4dGVybiBDT05TVCBjaGFyICpIb21lX0RpciBOT1BBUkFNUzsN CisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyBleHRlcm4gaW50IGZtdF90ZW1w bmFtZSBQQVJBTVMoKGNoYXIgKiByZXN1bHQsIENPTlNUIGNoYXIgKiBwcmVm aXgsIENPTlNUIGNoYXIgKiBzdWZmaXgpKTsNCisgI2VuZGlmDQogIGV4dGVy biBGSUxFICpMWUFwcGVuZFRvVHh0RmlsZSBQQVJBTVMoKGNoYXIgKiBuYW1l KSk7DQogIGV4dGVybiBGSUxFICpMWU5ld0JpbkZpbGUgUEFSQU1TKChjaGFy ICogbmFtZSkpOw0KICBleHRlcm4gRklMRSAqTFlOZXdUeHRGaWxlIFBBUkFN UygoY2hhciAqIG5hbWUpKTsNCioqKiAuL3NyYy9HcmlkVGV4dC5oLm9yaWcJ VHVlIE1hciAzMCAxMjoxMDozNyAxOTk5DQotLS0gLi9zcmMvR3JpZFRleHQu aAlTYXQgQXByIDEwIDE5OjI0OjUwIDE5OTkNCioqKioqKioqKioqKioqKg0K KioqIDE2NiwxNzEgKioqKg0KLS0tIDE2NiwxNzUgLS0tLQ0KICAJY2hhciAq CQl0YXJnZXQpKTsNCiAgZXh0ZXJuIGludCBIVGlzRG9jdW1lbnRTb3VyY2Ug Tk9QQVJBTVM7DQogIGV4dGVybiB2b2lkIEhUdW5jYWNoZV9jdXJyZW50X2Rv Y3VtZW50IE5PUEFSQU1TOw0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorIGV4 dGVybiBCT09MRUFOIEhUcmVwYXJzZV9kb2N1bWVudCBOT1BBUkFNUzsNCisg ZXh0ZXJuIEJPT0xFQU4gSFRkb2N1bWVudF9zZXR0aW5nc19jaGFuZ2VkIE5P UEFSQU1TOw0KKyAjZW5kaWYNCiAgZXh0ZXJuIGludCBIVGV4dF9nZXRUb3BP ZlNjcmVlbiBOT1BBUkFNUzsNCiAgZXh0ZXJuIGludCBIVGV4dF9nZXRMaW5l cyBQQVJBTVMoKEhUZXh0ICogdGV4dCkpOw0KICBleHRlcm4gaW50IEhUZXh0 X2dldE51bU9mTGluZXMgTk9QQVJBTVM7DQoqKiogLi9zcmMvTFlNYWluTG9v cC5jLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5DQotLS0gLi9zcmMv TFlNYWluTG9vcC5jCVNhdCBBcHIgMTAgMTk6NTE6NTIgMTk5OQ0KKioqKioq KioqKioqKioqDQoqKiogMTIzNywxMjQyICoqKioNCi0tLSAxMjM3LDEyNjIg LS0tLQ0KICAJICAgIH0NCiAgCX0NCiAgDQorICNpZmRlZiBTT1VSQ0VfQ0FD SEUNCisgCS8qDQorIAkgKiBJZiB0aGUgcGFyc2Ugc2V0dGluZ3MgaGF2ZSBj aGFuZ2VkIHNpbmNlIHRoaXMgSFRleHQgd2FzDQorIAkgKiBnZW5lcmF0ZWQs IHdlIG5lZWQgdG8gcmVwYXJzZSBhbmQgcmVkcmF3IGl0Lg0KKyAJICovDQor IAlpZiAoTFlDYWNoZVNvdXJjZSAmJiBIVGRvY3VtZW50X3NldHRpbmdzX2No YW5nZWQoKSkgew0KKyAJICAgIEhUVXNlck1zZyhnZXR0ZXh0KCJSZXBhcnNp bmcgZG9jdW1lbnQgdW5kZXIgY3VycmVudCBzZXR0aW5ncy4uLiIpKTsNCisg CSAgICBpZiAoSFRyZXBhcnNlX2RvY3VtZW50KCkpDQorIAkJcmVmcmVzaF9z Y3JlZW4gPSBUUlVFOw0KKyAJICAgIGVsc2Ugew0KKyAJCS8qDQorIAkJICog VXJrLiAgSSBoYXZlIG5vIGlkZWEgaG93IHRvIHJlY292ZXIgZnJvbSBhIGZh aWx1cmUgaGVyZS4NCisgCQkgKiBBdCBhIGd1ZXNzLCBJJ2xsIHRyeSByZWxv YWRpbmcuDQorIAkJICovDQorIAkJY21kID0gTFlLX1JFTE9BRDsNCisgCQln b3RvIG5ld19jbWQ7DQorIAkgICAgfQ0KKyAJfQ0KKyAjZW5kaWYNCisgDQog IAkvKg0KICAJICogIElmIHRoZSBjdXJkb2MubGluZSBpcyBkaWZmZXJlbnQg dGhhbiBOZXdsaW5lIHRoZW4gdGhlcmUgbXVzdA0KICAJICogIGhhdmUgYmVl biBhIGNoYW5nZSBzaW5jZSBsYXN0IHVwZGF0ZS4gIFJ1biBIVGV4dF9wYWdl RGlzcGxheSgpDQoqKioqKioqKioqKioqKioNCioqKiAyMDQ5LDIwNTQgKioq Kg0KLS0tIDIwNjksMjA4MCAtLS0tDQogIAkJTFlVQ1B1c2hBc3N1bWVkKEhU TWFpbkFuY2hvcik7DQogIAkJSFRPdXRwdXRGb3JtYXQgPSBXV1dfU09VUkNF Ow0KICAJICAgIH0NCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJICAgIGlm IChMWUNhY2hlU291cmNlICYmIEhUcmVwYXJzZV9kb2N1bWVudCgpKSB7DQor IAkJcmVmcmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJyZWFrOw0KKyAJICAg IH0NCisgI2VuZGlmDQogIAkgICAgTFlmb3JjZV9ub19jYWNoZSA9IFRSVUU7 DQogIAkgICAgRlJFRShjdXJkb2MuYWRkcmVzcyk7IC8qIHNvIGl0IGRvZXNu J3QgZ2V0IHB1c2hlZCAqLw0KICAJICAgIGJyZWFrOw0KKioqKioqKioqKioq KioqDQoqKiogMjEyNSwyMTM1ICoqKioNCi0tLSAyMTUxLDIxNjMgLS0tLQ0K ICAJCQkJICAgMCwgMCkgPT0gRkFMU0UpIHsNCiAgCQlIVEluZm9Nc2coV0lM TF9OT1RfUkVMT0FEX0RPQyk7DQogIAkgICAgfSBlbHNlIHsNCisgI2lmbmRl ZiBTT1VSQ0VfQ0FDSEUNCiAgCQlIVHVuY2FjaGVfY3VycmVudF9kb2N1bWVu dCgpOw0KICAJCVN0ckFsbG9jQ29weShuZXdkb2MuYWRkcmVzcywgY3VyZG9j LmFkZHJlc3MpOw0KICAJCUZSRUUoY3VyZG9jLmFkZHJlc3MpOw0KICAJCW5l d2RvYy5saW5lID0gY3VyZG9jLmxpbmU7DQogIAkJbmV3ZG9jLmxpbmsgPSBj dXJkb2MubGluazsNCisgI2VuZGlmDQogIAkgICAgfQ0KICAJICAgIGlmICho aXN0b3JpY2FsX2NvbW1lbnRzKQ0KICAJCWhpc3RvcmljYWxfY29tbWVudHMg PSBGQUxTRTsNCioqKioqKioqKioqKioqKg0KKioqIDIxNDIsMjE0NyAqKioq DQotLS0gMjE3MCwyMTg2IC0tLS0NCiAgCQlIVEFsZXJ0KGhpc3RvcmljYWxf Y29tbWVudHMgPw0KICAJCQlISVNUT1JJQ0FMX09OX1ZBTElEX09GRiA6IEhJ U1RPUklDQUxfT0ZGX1ZBTElEX09OKTsNCiAgCSAgICB9DQorICNpZmRlZiBT T1VSQ0VfQ0FDSEUNCisgCSAgICBpZiAoTFlDYWNoZVNvdXJjZSAmJiBIVHJl cGFyc2VfZG9jdW1lbnQoKSkgew0KKyAJCXJlZnJlc2hfc2NyZWVuID0gVFJV RTsNCisgCQlicmVhazsNCisgCSAgICB9DQorIAkgICAgSFR1bmNhY2hlX2N1 cnJlbnRfZG9jdW1lbnQoKTsNCisgCSAgICBTdHJBbGxvY0NvcHkobmV3ZG9j LmFkZHJlc3MsIGN1cmRvYy5hZGRyZXNzKTsNCisgCSAgICBGUkVFKGN1cmRv Yy5hZGRyZXNzKTsNCisgCSAgICBuZXdkb2MubGluZSA9IGN1cmRvYy5saW5l Ow0KKyAJICAgIG5ld2RvYy5saW5rID0gY3VyZG9jLmxpbms7DQorICNlbmRp Zg0KICAJICAgIGJyZWFrOw0KICANCiAgCWNhc2UgTFlLX01JTklNQUw6CS8q IHRvZ2dsZSAnbWluaW1hbCcgY29tbWVudHMgcGFyc2luZyAqLw0KKioqKioq KioqKioqKioqDQoqKiogMjE1NywyMTY3ICoqKioNCi0tLSAyMTk2LDIyMDgg LS0tLQ0KICAJCQkJICAgICAgIDAsIDApID09IEZBTFNFKSB7DQogIAkJICAg IEhUSW5mb01zZyhXSUxMX05PVF9SRUxPQURfRE9DKTsNCiAgCQl9IGVsc2Ug ew0KKyAjaWZuZGVmIFNPVVJDRV9DQUNIRQ0KICAJCSAgICBIVHVuY2FjaGVf Y3VycmVudF9kb2N1bWVudCgpOw0KICAJCSAgICBTdHJBbGxvY0NvcHkobmV3 ZG9jLmFkZHJlc3MsIGN1cmRvYy5hZGRyZXNzKTsNCiAgCQkgICAgRlJFRShj dXJkb2MuYWRkcmVzcyk7DQogIAkJICAgIG5ld2RvYy5saW5lID0gY3VyZG9j LmxpbmU7DQogIAkJICAgIG5ld2RvYy5saW5rID0gY3VyZG9jLmxpbms7DQor ICNlbmRpZg0KICAJCX0NCiAgCSAgICB9DQogIAkgICAgaWYgKG1pbmltYWxf Y29tbWVudHMpDQoqKioqKioqKioqKioqKioNCioqKiAyMTc1LDIxODAgKioq Kg0KLS0tIDIyMTYsMjIzMiAtLS0tDQogIAkJSFRBbGVydChtaW5pbWFsX2Nv bW1lbnRzID8NCiAgCQkJTUlOSU1BTF9PTl9CVVRfSElTVE9SSUNBTCA6IE1J TklNQUxfT0ZGX0hJU1RPUklDQUxfT04pOw0KICAJICAgIH0NCisgI2lmZGVm IFNPVVJDRV9DQUNIRQ0KKyAJICAgIGlmIChMWUNhY2hlU291cmNlICYmIEhU cmVwYXJzZV9kb2N1bWVudCgpKSB7DQorIAkJcmVmcmVzaF9zY3JlZW4gPSBU UlVFOw0KKyAJCWJyZWFrOw0KKyAJICAgIH0NCisgCSAgICBIVHVuY2FjaGVf Y3VycmVudF9kb2N1bWVudCgpOw0KKyAJICAgIFN0ckFsbG9jQ29weShuZXdk b2MuYWRkcmVzcywgY3VyZG9jLmFkZHJlc3MpOw0KKyAJICAgIEZSRUUoY3Vy ZG9jLmFkZHJlc3MpOw0KKyAJICAgIG5ld2RvYy5saW5lID0gY3VyZG9jLmxp bmU7DQorIAkgICAgbmV3ZG9jLmxpbmsgPSBjdXJkb2MubGluazsNCisgI2Vu ZGlmDQogIAkgICAgYnJlYWs7DQogIA0KICAJY2FzZSBMWUtfU09GVF9EUVVP VEVTOg0KKioqKioqKioqKioqKioqDQoqKiogMjE4OSwyMTk5ICoqKioNCi0t LSAyMjQxLDIyNTMgLS0tLQ0KICAJCQkJICAgMSwgMSkgPT0gRkFMU0UpIHsN CiAgCQlIVEluZm9Nc2coV0lMTF9OT1RfUkVMT0FEX0RPQyk7DQogIAkgICAg fSBlbHNlIHsNCisgI2lmbmRlZiBTT1VSQ0VfQ0FDSEUNCiAgCQlIVHVuY2Fj aGVfY3VycmVudF9kb2N1bWVudCgpOw0KICAJCVN0ckFsbG9jQ29weShuZXdk b2MuYWRkcmVzcywgY3VyZG9jLmFkZHJlc3MpOw0KICAJCUZSRUUoY3VyZG9j LmFkZHJlc3MpOw0KICAJCW5ld2RvYy5saW5lID0gY3VyZG9jLmxpbmU7DQog IAkJbmV3ZG9jLmxpbmsgPSBjdXJkb2MubGluazsNCisgI2VuZGlmDQogIAkg ICAgfQ0KICAJICAgIGlmIChzb2Z0X2RxdW90ZXMpDQogIAkJc29mdF9kcXVv dGVzID0gRkFMU0U7DQoqKioqKioqKioqKioqKioNCioqKiAyMjAxLDIyMDYg KioqKg0KLS0tIDIyNTUsMjI3MSAtLS0tDQogIAkJc29mdF9kcXVvdGVzID0g VFJVRTsNCiAgCSAgICBIVFVzZXJNc2coc29mdF9kcXVvdGVzID8NCiAgCQkg ICAgICBTT0ZUX0RPVUJMRV9RVU9URV9PTiA6IFNPRlRfRE9VQkxFX1FVT1RF X09GRik7DQorICNpZmRlZiBTT1VSQ0VfQ0FDSEUNCisgCSAgICBpZiAoTFlD YWNoZVNvdXJjZSAmJiBIVHJlcGFyc2VfZG9jdW1lbnQoKSkgew0KKyAJCXJl ZnJlc2hfc2NyZWVuID0gVFJVRTsNCisgCQlicmVhazsNCisgCSAgICB9DQor IAkgICAgSFR1bmNhY2hlX2N1cnJlbnRfZG9jdW1lbnQoKTsNCisgCSAgICBT dHJBbGxvY0NvcHkobmV3ZG9jLmFkZHJlc3MsIGN1cmRvYy5hZGRyZXNzKTsN CisgCSAgICBGUkVFKGN1cmRvYy5hZGRyZXNzKTsNCisgCSAgICBuZXdkb2Mu bGluZSA9IGN1cmRvYy5saW5lOw0KKyAJICAgIG5ld2RvYy5saW5rID0gY3Vy ZG9jLmxpbms7DQorICNlbmRpZg0KICAJICAgIGJyZWFrOw0KICANCiAgCWNh c2UgTFlLX1NXSVRDSF9EVEQ6DQoqKioqKioqKioqKioqKioNCioqKiAyMjIz LDIyMzEgKioqKg0KLS0tIDIyODgsMjI5OCAtLS0tDQogIAkJaWYgKEhUaXNE b2N1bWVudFNvdXJjZSgpICYmIExZUHJlcGFyc2VkU291cmNlKSB7DQogIAkJ CUhUT3V0cHV0Rm9ybWF0ID0gV1dXX1NPVVJDRTsNCiAgCQl9DQorICNpZm5k ZWYgU09VUkNFX0NBQ0hFDQogIAkJSFR1bmNhY2hlX2N1cnJlbnRfZG9jdW1l bnQoKTsNCiAgCQlTdHJBbGxvY0NvcHkobmV3ZG9jLmFkZHJlc3MsIGN1cmRv Yy5hZGRyZXNzKTsNCiAgCQlGUkVFKGN1cmRvYy5hZGRyZXNzKTsNCisgI2Vu ZGlmDQogIAkgICAgfQ0KICAjaWZkZWYgTk9fQVNTVU1FX1NBTUVfRE9DDQog IAkgICAgbmV3ZG9jLmxpbmUgPSAxOw0KKioqKioqKioqKioqKioqDQoqKiog MjIzNywyMjQyICoqKioNCi0tLSAyMzA0LDIzMTggLS0tLQ0KICAJICAgIE9s ZF9EVEQgPSAhT2xkX0RURDsNCiAgCSAgICBIVFN3aXRjaERURCghT2xkX0RU RCk7DQogIAkgICAgSFRVc2VyTXNnKE9sZF9EVEQgPyBVU0lOR19EVERfMCA6 IFVTSU5HX0RURF8xKTsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJICAg IGlmIChMWUNhY2hlU291cmNlICYmIEhUcmVwYXJzZV9kb2N1bWVudCgpKSB7 DQorIAkJcmVmcmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJyZWFrOw0KKyAJ ICAgIH0NCisgCSAgICBIVHVuY2FjaGVfY3VycmVudF9kb2N1bWVudCgpOw0K KyAJICAgIFN0ckFsbG9jQ29weShuZXdkb2MuYWRkcmVzcywgY3VyZG9jLmFk ZHJlc3MpOw0KKyAJICAgIEZSRUUoY3VyZG9jLmFkZHJlc3MpOw0KKyAjZW5k aWYNCiAgCSAgICBicmVhazsNCiAgDQogICNpZmRlZiBOT1RfRE9ORV9ZRVQN CioqKioqKioqKioqKioqKg0KKioqIDU0NDcsNTQ1MiAqKioqDQotLS0gNTUy Myw1NTM0IC0tLS0NCiAgDQogIAkgICAgSFRVc2VyTXNnKGNsaWNrYWJsZV9p bWFnZXMgPw0KICAJCSAgICAgQ0xJQ0tBQkxFX0lNQUdFU19PTiA6IENMSUNL QUJMRV9JTUFHRVNfT0ZGKTsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJ ICAgIGlmIChMWUNhY2hlU291cmNlICYmIEhUcmVwYXJzZV9kb2N1bWVudCgp KSB7DQorIAkJcmVmcmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJyZWFrOw0K KyAJICAgIH0NCisgI2VuZGlmDQogIAkgICAgY21kID0gTFlLX1JFTE9BRDsN CiAgCSAgICBnb3RvIG5ld19jbWQ7DQogIA0KKioqKioqKioqKioqKioqDQoq KiogNTQ1OCw1NDYzICoqKioNCi0tLSA1NTQwLDU1NTEgLS0tLQ0KICANCiAg CSAgICBIVFVzZXJNc2cocHNldWRvX2lubGluZV9hbHRzID8NCiAgCQkgICAg ICBQU0VVRE9fSU5MSU5FX0FMVFNfT04gOiBQU0VVRE9fSU5MSU5FX0FMVFNf T0ZGKTsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJICAgIGlmIChMWUNh Y2hlU291cmNlICYmIEhUcmVwYXJzZV9kb2N1bWVudCgpKSB7DQorIAkJcmVm cmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJyZWFrOw0KKyAJICAgIH0NCisg I2VuZGlmDQogIAkgICAgY21kID0gTFlLX1JFTE9BRDsNCiAgCSAgICBnb3Rv IG5ld19jbWQ7DQogIA0KKioqKioqKioqKioqKioqDQoqKiogNTQ3MCw1NDc1 ICoqKioNCi0tLSA1NTU4LDU1NjkgLS0tLQ0KICAJCUhUVXNlck1zZyhMWVJh d01vZGUgPyBSQVdNT0RFX09GRiA6IFJBV01PREVfT04pOw0KICAJCUhUTUxT ZXRDaGFyYWN0ZXJIYW5kbGluZyhjdXJyZW50X2NoYXJfc2V0KTsNCiAgCQlM WVJhd01vZGVfZmxhZyA9IExZUmF3TW9kZTsNCisgI2lmZGVmIFNPVVJDRV9D QUNIRQ0KKyAJCWlmIChMWUNhY2hlU291cmNlICYmIEhUcmVwYXJzZV9kb2N1 bWVudCgpKSB7DQorIAkJICAgIHJlZnJlc2hfc2NyZWVuID0gVFJVRTsNCisg CQkgICAgYnJlYWs7DQorIAkJfQ0KKyAjZW5kaWYNCiAgCQljbWQgPSBMWUtf UkVMT0FEOw0KICAJCWdvdG8gbmV3X2NtZDsNCiAgCSAgICB9DQoqKiogLi9z cmMvTFlSZWFkQ0ZHLmMub3JpZwlUdWUgTWFyIDMwIDEyOjEwOjM3IDE5OTkN Ci0tLSAuL3NyYy9MWVJlYWRDRkcuYwlTYXQgQXByIDEwIDE5OjIxOjQ1IDE5 OTkNCioqKioqKioqKioqKioqKg0KKioqIDk5OSwxMDA0ICoqKioNCi0tLSA5 OTksMTAwNyAtLS0tDQogICAgICAgUEFSU0VfRU5WKCJzbmV3c3Bvc3RfcHJv eHkiLCBDT05GX0VOViwgMCApLA0KICAgICAgIFBBUlNFX0VOVigic25ld3Ny ZXBseV9wcm94eSIsIENPTkZfRU5WLCAwICksDQogICAgICAgUEFSU0VfU0VU KCJzb2Z0X2RxdW90ZXMiLCBDT05GX0JPT0wsIHNvZnRfZHF1b3RlcyksDQor ICNpZmRlZiBTT1VSQ0VfQ0FDSEUNCisgICAgICBQQVJTRV9TRVQoInNvdXJj ZV9jYWNoZSIsIENPTkZfQk9PTCwgTFlDYWNoZVNvdXJjZSksDQorICNlbmRp Zg0KICAgICAgIFBBUlNFX1NUUigic3RhcnRmaWxlIiwgQ09ORl9TVFIsIHN0 YXJ0ZmlsZSksDQogICAgICAgUEFSU0VfU0VUKCJzdHJpcF9kb3Rkb3RfdXJs cyIsIENPTkZfQk9PTCwgTFlTdHJpcERvdERvdFVSTHMpLA0KICAgICAgIFBB UlNFX1NFVCgic3Vic3RpdHV0ZV91bmRlcnNjb3JlcyIsIENPTkZfQk9PTCwg dXNlX3VuZGVyc2NvcmUpLA0KKioqIC4vc3JjL0xZR2xvYmFsRGVmcy5oLm9y aWcJVGh1IE1hciAgNCAwNTozOTo0NSAxOTk5DQotLS0gLi9zcmMvTFlHbG9i YWxEZWZzLmgJU2F0IEFwciAxMCAxOToyNjozNCAxOTk5DQoqKioqKioqKioq KioqKioNCioqKiAyNDUsMjUwICoqKioNCi0tLSAyNDUsMjU0IC0tLS0NCiAg ZXh0ZXJuIEJPT0xFQU4gaGlzdG9yaWNhbF9jb21tZW50czsNCiAgZXh0ZXJu IEJPT0xFQU4gbWluaW1hbF9jb21tZW50czsNCiAgZXh0ZXJuIEJPT0xFQU4g c29mdF9kcXVvdGVzOw0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorIGV4dGVy biBjaGFyICogc291cmNlX2NhY2hlX2ZpbGVuYW1lOw0KKyBleHRlcm4gQk9P TEVBTiBMWUNhY2hlU291cmNlOw0KKyAjZW5kaWYNCiAgZXh0ZXJuIEJPT0xF QU4gTFlDYW5jZWxEb3dubG9hZDsNCiAgZXh0ZXJuIEJPT0xFQU4gTFlSZXN0 cmljdGVkOw0KICBleHRlcm4gQk9PTEVBTiBMWVZhbGlkYXRlOw0KKioqIC4v Y29uZmlndXJlLmluLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5DQot LS0gLi9jb25maWd1cmUuaW4JU2F0IEFwciAxMCAwMDoyNzozMyAxOTk5DQoq KioqKioqKioqKioqKioNCioqKiA1NjcsNTcyICoqKioNCi0tLSA1NjcsNTc5 IC0tLS0NCiAgQUNfTVNHX1JFU1VMVCgkdXNlX2FsdF9iaW5kaW5ncykNCiAg dGVzdCAkdXNlX2FsdF9iaW5kaW5ncyAhPSBubyAmJiBBQ19ERUZJTkUoRVhQ X0FMVF9CSU5ESU5HUykNCiAgDQorIEFDX01TR19DSEVDS0lORyhpZiBzb3Vy Y2UgY2FjaGluZyBzaG91bGQgYmUgdXNlZCkNCisgQ0ZfQVJHX0VOQUJMRShz b3VyY2UtY2FjaGUsDQorIFsgIC0tZW5hYmxlLXNvdXJjZS1jYWNoZSAgIGNh Y2hlIEhUTUwgc291cmNlIGZvciBwYXJzZSBtb2RlIGNoYW5nZXNdLA0KKyAJ W3VzZV9zb3VyY2VfY2FjaGU9JGVuYWJsZXZhbF0sDQorIAlbdXNlX3NvdXJj ZV9jYWNoZT1ub10NCisgdGVzdCAkdXNlX3NvdXJjZV9jYWNoZSAhPSBubyAm JiBBQ19ERUZJTkUoU09VUkNFX0NBQ0hFKQ0KKyANCiAgQUNfTVNHX0NIRUNL SU5HKGlmIGNvbG9yLXN0eWxlIGNvZGUgc2hvdWxkIGJlIHVzZWQpDQogIENG X0FSR19FTkFCTEUoY29sb3Itc3R5bGUsDQogIFsgIC0tZW5hYmxlLWNvbG9y LXN0eWxlICAgIHVzZSBvcHRpb25hbC9leHBlcmltZW50YWwgY29sb3Igc3R5 bGVdLA0KKioqIC4vY29uZmlnLmhpbi5vcmlnCVR1ZSBNYXIgMzAgMTI6MTA6 MzcgMTk5OQ0KLS0tIC4vY29uZmlnLmhpbglTYXQgQXByIDEwIDAwOjI3OjMz IDE5OTkNCioqKioqKioqKioqKioqKg0KKioqIDI4LDMzICoqKioNCi0tLSAy OCwzNCAtLS0tDQogICN1bmRlZiBFWEVDX1NDUklQVFMJCS8qIENGX0FSR19F TkFCTEUoZXhlYy1zY3JpcHRzKSAqLw0KICAjdW5kZWYgRVhQX0FERFJMSVNU X1BBR0UJLyogQ0ZfQVJHX0VOQUJMRShhZGRybGlzdC1wYWdlKSAqLw0KICAj dW5kZWYgRVhQX0FMVF9CSU5ESU5HUwkJLyogQ0ZfQVJHX0VOQUJMRShhbHQt YmluZGluZ3MpICovDQorICN1bmRlZiBTT1VSQ0VfQ0FDSEUJCS8qIENGX0FS R19FTkFCTEUoc291cmNlLWNhY2hlKSAqLw0KICAjdW5kZWYgRVhQX0NIQVJU UkFOU19BVVRPU1dJVENICS8qIENGX0FSR19FTkFCTEUoZm9udC1zd2l0Y2gp ICovDQogICN1bmRlZiBFWFBfS0VZQk9BUkRfTEFZT1VUCS8qIENGX0FSR19F TkFCTEUoa2JkLWxheW91dCkgKi8NCiAgI3VuZGVmIEVYUF9MSUJKUwkJLyog Q0ZfQVJHX0VOQUJMRShsaWJqcykgKi8NCioqKiAuL2x5bnguY2ZnLm9yaWcJ V2VkIE1hciAxNyAyMjoxNzoxMSAxOTk5DQotLS0gLi9seW54LmNmZwlTYXQg QXByIDEwIDE4OjQ1OjA5IDE5OTkNCioqKioqKioqKioqKioqKg0KKioqIDUx Myw1MTggKioqKg0KLS0tIDUxMyw1MjYgLS0tLQ0KICAjREVGQVVMVF9DQUNI RV9TSVpFOjEwDQogICNERUZBVUxUX1ZJUlRVQUxfTUVNT1JZX1NJWkU6NTEy MDAwDQogIA0KKyAjIGlmIFNPVVJDRV9DQUNIRSBpcyBzZXQgVFJVRSwgTHlu eCB3aWxsIGtlZXAgYSB0ZW1wb3JhcnkgZmlsZSBmb3IgZWFjaA0KKyAjIGNh Y2hlZCBkb2N1bWVudCBjb250YWluaW5nIHRoZSBIVE1MIHNvdXJjZSBvZiB0 aGUgZG9jdW1lbnQsIHdoaWNoIHdpbGwgYmUNCisgIyB1c2VkIHRvIHJlcGFy c2UgdGhlIGRvY3VtZW50IHdoZW4gY2VydGFpbiBzZXR0aW5ncyBhcmUgY2hh bmdlZCAoZm9yDQorICMgaW5zdGFuY2UsIGhpc3RvcmljYWwgdnMuIG1pbmlt YWwgdnMuIHZhbGlkIGNvbW1lbnQgcGFyc2luZykgaW5zdGVhZCBvZg0KKyAj IHJlbG9hZGluZyB0aGUgZG9jdW1lbnQgZnJvbSB0aGUgbmV0d29yay4NCisg Iw0KKyAjU09VUkNFX0NBQ0hFOlRSVUUNCisgDQogICMgSWYgQUxXQVlTX1JF U1VCTUlUX1BPU1RTIGlzIHNldCBUUlVFLCBMeW54IGFsd2F5cyB3aWxsIHJl c3VibWl0IGZvcm1zDQogICMgd2l0aCBtZXRob2QgUE9TVCwgZHVtcGluZyBh bnkgY2FjaGUgZnJvbSBhIHByZXZpb3VzIHN1Ym1pc3Npb24gb2YgdGhlDQog ICMgZm9ybSwgaW5jbHVkaW5nIHdoZW4gdGhlIGRvY3VtZW50IHJldHVybmVk IGJ5IHRoYXQgZm9ybSBpcyBzb3VnaHQgd2l0aA0K --8323328-719902432-923803195=:3224-- From owner-lynx-dev@sig.net Sun Apr 11 02:27:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26039 for ; Sun, 11 Apr 1999 02:27:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA08091; Sun, 11 Apr 1999 01:21:53 -0500 (CDT) From: Philip Webb Message-Id: <199904110621.CAA11249@chass.utoronto.ca> Subject: lynx-dev patch: TEXTAREA edit help To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 02:21:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3562 Lines: 80 hopefully, this may get into dev.22 , if TD's tax return is challenging enough (smile); as usual, i've broken lines carefully to match the phrasing. maybe KD will be able to improve & complete the text, when she has finished her big move ... * Add a section to Users Guide to explain the new TEXTAREA editing tools. *** old/Lynx_users_guide.html Sun Apr 11 02:14:00 1999 --- new/Lynx_users_guide.html Sun Apr 11 02:08:30 1999 *************** *** 1330,1335 **** --- 1330,1337 ---- entry field. NOTE, however, that Return also will submit the form if the text entry field is the only non-hidden field in the form. + +
TEXTAREA Fields
TEXTAREA fields are handled as if they were a series of text entry (INPUT) fields for which successive lines imply a newline at the end of the preceding line. You enter text on each line to construct the overall *************** *** 1339,1345 **** or next line of the overall message, as for INPUT fields, and the TAB key will move you down beyond the bottom of the TEXTAREA field, or to the first line on the next page if the overall field ! extends beyond the currently displayed page.
In general, you can move around the form using the standard Lynx navigation --- 1341,1383 ---- or next line of the overall message, as for INPUT fields, and the TAB key will move you down beyond the bottom of the TEXTAREA field, or to the first line on the next page if the overall field ! extends beyond the currently displayed page.

! !

Editing TEXTAREA Fields !
TEXTAREA fields can be edited using an external editor
! by entering ^ve when in the TEXTAREA.

! ! You can also use two other special TEXTAREA functions
! by adding KEYMAP bindings to your lynx.cfg file, e.g.

! !   KEYMAP:$:GROWTEXTAREA
!   KEYMAP:#:INSERTFILE

! ! With these binding -- you can choose other keys -- ,
! (in a TEXTAREA only) ^v$ adds 5 lines to the TEXTAREA
! and ^v# brings up the name of an existing file
! to be inserted into the TEXTAREA (above the cursorline).
! An automatic variation is normally compiled in,
! so that hitting Enter with the cursor on the last line
! adds a new line to the TEXTAREA, with the cursor on it.

! ! Some flavors of UNIX, shells & terminal settings require
! that you enter ^v^ve in order to start the editor,
! as they also use ^v as default command-line quote key
! (called `lnext' in stty man pages and `stty -a' output);
! to avoid this, you can put `stty lnext undef' in .cshrc
! or invoke Lynx with a wrapper script, e.g.

! !   #!/bin/sh
!   stty lnext undef
!   $HOME/bin/lynx "$@"
!   stty lnext ^V
!   exit

! ! NB when NOT in a TEXTAREA, ^v is the default command
! to switch between SortaSGML and TagSoup HTML parsing
! (i.e. SWITCH_DTD ). !

In general, you can move around the form using the standard Lynx navigation -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 03:23:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27501 for ; Sun, 11 Apr 1999 03:23:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA12648; Sun, 11 Apr 1999 02:18:52 -0500 (CDT) From: David Woolley Message-Id: <199904101008.LAA03952@djwhome.demon.co.uk> Subject: Re: lynx-dev outofmem() allocating memory To: lynx-dev@sig.net Date: Sat, 10 Apr 1999 11:08:50 +0100 (BST) In-Reply-To: <199904091132.HAA07936@shell.clark.net> from "dickey@clark.net" at Apr 9, 99 07:32:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 108 Lines: 3 > doesn't help is fflush is allocating the buffer for some other reason. I'd consider it broken if it did. From owner-lynx-dev@sig.net Sun Apr 11 04:28:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA29866 for ; Sun, 11 Apr 1999 04:28:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA17554; Sun, 11 Apr 1999 03:23:40 -0500 (CDT) From: Philip Webb Message-Id: <199904110823.EAA13038@chass.utoronto.ca> Subject: path: revised lynx-dev.html To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 04:23:36 -0400 (EDT) In-Reply-To: <199903182128.QAA09818@chass.utoronto.ca> from "Philip Webb" at Mar 18, 99 04:28:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 862 Lines: 19 990318 John Bley & Larry Virden discussed: > I frequently see new developer releases mentioned at freshmeat.net: > that is how I first became aware of the lynx dev series. & i promised: > a note about the dev.nn series should be added to lynx_help/lynx-dev.html , > which could probably do with some simplification anyway. > subject to comments, i'll see if i can do something with it. an updated version of the file can be found at http://www.chass.utoronto.ca/~purslow/lynx-dev.html ; please view at it with Lynx to see the lay-out correctly. i hope it will make it in time for dev.22 . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 04:56:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30423 for ; Sun, 11 Apr 1999 04:56:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA19425; Sun, 11 Apr 1999 03:51:37 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 11 Apr 1999 12:47:09 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2576 Lines: 50 10-Apr-99 23:59 Scott Bigham wrote: > In this implementation, each document kept in cache has associated with it > a temporary file containing the HTML source for the document (well, not all > of them -- only those using the HTTP protocol, on the premise that file:// > documents are probably local and ftp:// documents are probably not HTML). > The temporary file is deleted when the document is uncached. For certain > operations, instead of reloading the document via HTLoad(), the > source file is reparsed with HTParseFile(). The cached document also > remembers certain parser settings (screen size, historical vs. minimal vs. > valid comment parsing, and the like), and is regenerated from source if it > is fetched out of cache under different settings. Thanks a lot! I found this feature very useful and vote to include it in dev22 immediately. One (minor) problem: keeping a temporarily files for sources cache we need to be sure to clean these files on exit. Currently it implemented in HText_free() but atexit(free_all_texts) was recently ignored without LY_FIND_LEAKS. Probably these files will be deleted by clean_files() anyway, ha, don't forget to disable the feature in NONINTERACTIVE mode - it will not clean temp files currently (if should not create temp files, so a nice check that everything OK). Also we increase disk activity which may be not good for users under disk quota or leaving too much junk if lynx crash unconditionally. > This behavior is selectable by a configure option --enable-source-cache and > by a lynx.cfg option SOURCE_CACHE; I didn't add a command-line argument or > an options menu entry, as this didn't seem to be the sort of thing one > would want to change at runtime. > Assorted notes: > - Oddly, some of the commands I modified reload the document by faking an > LYK_RELOAD, and some by calling HTuncache_current_document(). Any > particular reason for the difference? I ask because the latter did the > HTuncache_...() before printing the associated message and I had to > move it after to get the reparse to work, and I probably did it wrong. > - I try to be intelligent about passing the source cache file along to > the newly generated HText, but I'm a bit nervous about passing it > around in a global variable... > As always, apply with caution; I've almost certainly gotten something > wrong. > (I wonder if this is gonna start up that whole argument again....) > -sbigham > --ATTACHMENT-- text file From owner-lynx-dev@sig.net Sun Apr 11 05:48:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA31422 for ; Sun, 11 Apr 1999 05:48:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA03660; Sun, 11 Apr 1999 04:42:34 -0500 (CDT) From: David Woolley Message-Id: <199904110753.IAA05382@djwhome.demon.co.uk> Subject: Re: lynx-dev ayuda To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 08:53:50 +0100 (BST) Cc: amoraila@mixmail.com In-Reply-To: <199904110053.TAA25753@roadrunner.sig.net> from "Alejandro Moraila" at Apr 10, 99 08:51:39 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1167 Lines: 23 > > > Hi my name is alejandro, I'm from Mexico, and,I'm conected with a LAN net, and the file "lynx.exe" say this "alert Unable to conect to remote host", > and "cant access startfile http://linx.browser.org" y > I think that the reason is that I didn't create a "Lynx.bat". > I don't know how to create a bat file, and what I put inside of this file. Lynx is not primarily a program for Microsoft operating systems, but there are two significantly different versions (MS-DOS + DOS extender and Win32) for those operating systems and several releases of these, so you really need say which operating system and which version of Lynx. Please don't assume that Microsoft are the only operating systems and don't need to be mentioned. Assuming you are talking about MS-DOS, even the basic user documentation describes how to create .bat files and, if you cannot follow that, setting up any TCP application on plain DOS is sufficiently complex that you should really get help from someone in person (or from your ISP, if they support DOS access - no UK one would these days). The Win32 versions don't need a .bat file creating. From owner-lynx-dev@sig.net Sun Apr 11 10:38:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA04713 for ; Sun, 11 Apr 1999 10:38:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28316; Sun, 11 Apr 1999 09:32:05 -0500 (CDT) X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sun, 11 Apr 1999 09:44:51 -0400 Subject: lynx-dev Screen adjustment From: "D Warman" To: lynx-dev@sig.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-ID: <19990411124443.AAA17180@[207.179.142.14]> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 149 Lines: 2 I have a need to use MacLynx on an older Mac SE but the default window is too large on the smaller Mac SE screen. How can I adjust the window size? From owner-lynx-dev@sig.net Sun Apr 11 11:09:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA05574 for ; Sun, 11 Apr 1999 11:09:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02251; Sun, 11 Apr 1999 10:03:31 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904111502.JAA18415@sanitas> Subject: Re: lynx-dev LYNX: neat new search engine at www.google.com To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 09:02:57 -0600 (MDT) In-Reply-To: <199904110115.SAA14954@netcom15.netcom.com> from "David Combs" at Apr 10, 99 06:15:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 199 Lines: 10 In a recent note, David Combs said: > Date: Sat, 10 Apr 1999 18:15:46 -0700 (PDT) > > Looks really good. Is beta version, it says. > comes out of the cs dept at stanford. > Son of Yahoo? -- gil From owner-lynx-dev@sig.net Sun Apr 11 12:13:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA07122 for ; Sun, 11 Apr 1999 12:13:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA10458; Sun, 11 Apr 1999 11:07:35 -0500 (CDT) From: dickey@clark.net Message-Id: <199904111607.MAA03419@shell.clark.net> Subject: Re: lynx-dev Screen adjustment To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 12:07:31 -0400 (EDT) In-Reply-To: <19990411124443.AAA17180@[207.179.142.14]> from "D Warman" " at Apr 11, 99 09:44:51 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 455 Lines: 15 > > I have a need to use MacLynx on an older Mac SE but the default window is > too large on the smaller Mac SE screen. How can I adjust the window size? your terminal description (assuming that lynx is built with curses) has to match the window that it's running in. (I've not seen the changes made for MacLynx - a couple of email inquiries in that direction got no response) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 12:52:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA08272 for ; Sun, 11 Apr 1999 12:52:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA15549; Sun, 11 Apr 1999 11:46:15 -0500 (CDT) Date: Sun, 11 Apr 1999 12:46:07 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1783 Lines: 41 On Sun, 11 Apr 1999, Leonid Pauzner wrote: > One (minor) problem: keeping a temporarily files for sources cache > we need to be sure to clean these files on exit. Currently it implemented > in HText_free() but atexit(free_all_texts) was recently ignored > without LY_FIND_LEAKS. And I had LY_FIND_LEAKS on for testing purposes; no wonder I didn't see it. See, I knew I'd miss something. (examines code) Wait a minute. The declaration and definition of free_all_texts() are wrapped in '#ifdef LY_FIND_LEAKS', but the atexit(free_all_texts) call in HText_new() isn't. How can that even compile without LY_FIND_LEAKS #define'd? Well, at any rate, the quick fix would seem to be to change those wrappers to '#if defined(LY_FIND_LEAKS) || defined(SOURCE_CACHE)'. > Probably these files will be deleted by clean_files() anyway, No, cleanup_files() only deletes files listed in the ly_temp list. And I hesitate to use that mechanism, because then I'd have to go back and remove those files from ly_temp when they get uncached. > ha, don't forget to disable the feature in NONINTERACTIVE mode - it > will not clean temp files currently (if should not create temp files, > so a nice check that everything OK). Hmm, that could be done in the 'if (dump_output_immediately)' block in main(), yes? > Also we increase disk activity which may be not good for users > under disk quota or leaving too much junk if lynx crash unconditionally. Well, the low-disk-quota user could always put SOURCE_CACHE:FALSE in her lynx.cfg (or we could have it off by default and make the user turn it on in lynx.cfg; I only had it on by default for testing purposes), or compile it out if she's building her own. As for the crash, that will be the same as with temporary files, yes? -sbigham From owner-lynx-dev@sig.net Sun Apr 11 13:48:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA09821 for ; Sun, 11 Apr 1999 13:48:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA23467; Sun, 11 Apr 1999 12:41:53 -0500 (CDT) Date: Sun, 11 Apr 1999 10:41:48 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: path: revised lynx-dev.html In-Reply-To: <199904110823.EAA13038@chass.utoronto.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1318 Lines: 32 On Sun, 11 Apr 1999, Philip Webb wrote: > > a note about the dev.nn series should be added to lynx_help/lynx-dev.html , > > which could probably do with some simplification anyway. > > subject to comments, i'll see if i can do something with it. > > an updated version of the file can be found at > http://www.chass.utoronto.ca/~purslow/lynx-dev.html ; > please view at it with Lynx to see the lay-out correctly. For some reason, you seem to have added
at the end of each line. Except for places where this is meaningful, it should probably be avoided. It reads well. I would recommend the following grammar correction: --- lynx-dev.html.ori Sun Apr 11 10:34:06 1999 +++ lynx-dev.html Sun Apr 11 10:35:21 1999 @@ -20,7 +20,7 @@ Lynx is maintained and improved by an international co-operative
of volunteers. Newcomers are welcome to join the group:
you needn't be a super programmer, but you should be prepared
-to listen and learn, as well as contributing patches if you can.
+to listen and learn, as well as to contribute patches if you can.
Since everyone is a volunteer, you will usually be expected
to try to implement any suggestions you make. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 11 13:52:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA10019 for ; Sun, 11 Apr 1999 13:52:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA24219; Sun, 11 Apr 1999 12:47:04 -0500 (CDT) Date: Sun, 11 Apr 1999 10:46:51 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Cc: amoraila@mixmail.com Subject: Re: lynx-dev ayuda In-Reply-To: <199904110753.IAA05382@djwhome.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 456 Lines: 14 On Sun, 11 Apr 1999, David Woolley wrote: > The Win32 versions don't need a .bat file creating. The Win32 version DOES need a batch file to set up the environment properly. Sample batch files are in Wayne's distribution from "http://www.fdisk.com/doslynx/lynxport.htm". It is usually run from a shortcut linked to the batch file. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 11 14:08:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA10318 for ; Sun, 11 Apr 1999 14:08:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA26532; Sun, 11 Apr 1999 13:03:35 -0500 (CDT) Date: Sun, 11 Apr 1999 11:03:30 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: lynx-dev DOS bug report - no fix (PDCurses build) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1106 Lines: 27 I wanted to report to the list two (probably related) bugs in the PDCurses build of the DOS port of lynx. These are not found in the SLang port. I don't know where the problem arises, in PDCurses itself or in the way lynx interacts. 1. When exiting with CTRL-C or CTRL-BREAK, the system BREAK is not reset to the value present before lynx was executed. It is always ON. BREAK is reset properly with a normal exit. 2. When exiting with CTRL-BREAK, but not with CTRL-C, the packet driver can not terminate properly, requiring a reboot to clear it from memory (tested with DOSPPP only). There is a third problem I noticed, but I don't know if it is a bug. Looking at trace files for the PDCurses and SLang ports, on exit with CTRL-C or CTRL-BREAK the SLang port saves cookies. No such messages appear in the PDCurses ports. This all sounds like a problem with handling exiting after SIGINT under PDCurses. This was tested using dev.21 and dev.16, SLang 1.2.2 and PDCurses 2.3. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 11 14:16:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA10558 for ; Sun, 11 Apr 1999 14:16:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA27041; Sun, 11 Apr 1999 13:07:43 -0500 (CDT) From: Heather Stern Message-Id: <199904111738.KAA00608@betelgeuse.starshine.org> Subject: Re: lynx-dev Fatal error in Lynx Ver. 2.5 In-Reply-To: <199904100645.CAA04160@chass.utoronto.ca> from Philip Webb at "Apr 10, 99 02:45:31 am" To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 10:38:11 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL37 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1258 Lines: 28 > 990409 Randy Speaks wrote: > > Strangest thing happened tonight. ... > >> Lynx now exiting with signal: 11 ... > > Furthermore, lynx still works fine if I run it as root. > > Only when I am logged on as my usual login name does it crash like this. > > Any ideas/help out there? While Philip's answer is valid (lynx has changed a lot, you want a new one) it doesn't answer what happened to your previously working copy. Check your own login for environment variables that affect lynx, and your dotfiles or dot directories for lynx control files. Some control data that's kept in your home now either contains wrong information or has bad permissions. "Sig 11" is rather like an MSwin GPF, it isn't really helpful, except to advise that the program crashed, and may have mangled files it had open. There's a HOWTO in the LDP about it that might shed some light for you. LDP Homepage: http://metalab.unc.edu/LDP/ . | . Heather Stern | star@starshine.org --->*<--- Starshine Technical Services - * - consulting@starshine.org ' | ` System Admin Support & Training | Any body suspended in space will remain in space until made aware of its situation. -- Esquire, "O'Donnell's Laws of Cartoon Motion", June 1980 From owner-lynx-dev@sig.net Sun Apr 11 14:21:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA10764 for ; Sun, 11 Apr 1999 14:21:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA28021; Sun, 11 Apr 1999 13:15:06 -0500 (CDT) Date: Sun, 11 Apr 1999 18:13:56 -0400 (EDT) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev batch-mode cookies ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3304 Lines: 88 Leonid wrote: > 9-Apr-99 19:25 Hugo Rabson wrote: > > On 09-Apr-99 Leonid Pauzner wrote: > >> 9-Apr-99 08:05 Hugo Rabson wrote: > >>> I've written a script which navigate Hotmail & forwards new emails to a > >>> local mail spool. The thing is, it no longer works because Hotmail now > >>> requires cookies & Lynx won't accept or send cookies when it's run in > >>> batch mode (non-interactive mode). [...] > > I'm now running Lynx 2.8.2dev21 and the problem is the same: I don't get a > > persistent cookie file in batch mode. That is, the cookie file _exists_ & > > was created by Lynx in batch mode, but it's empty. I've compiled > ^^^^^^^^^^^^^^ > Hmm... That may be a problem when "persistent_cookies" does set to FALSE: > looking into LYMain.c I found out that "if (persistent_cookies)" > check really lost: > > #ifdef EXP_PERSISTENT_COOKIES > /* > * We want to save cookies picked up when in immediate dump > * mode. Instead of calling cleanup() here, let's only call > * this one. - BJP > */ > LYStoreCookies(LYCookieFile); > #endif /* EXP_PERSISTENT_COOKIES */ > > so cookies may be saved but never loaded next session. > > > persistent cookies in & set the options in lynx.cfg so that persistent > > cookies worked just fine under Lynx in _interactive_ mode. > > > But that may have nothing with your problem. > I am not a cookie expert, sorry. > Try starting lynx -trace and compare Lynx.trace files from interactive > and noninteractive mode, this will give a hint. Vanilla 2.8.2dev.21, only compiletime option is --enable-persistent-cookies. Script started on Sun Apr 11 17:58:25 1999 darkstar:~/lynx/2.8.2dev.21$ cat ~/.lynx_cookies cat: /home/pk/.lynx_cookies: No such file or directory darkstar:~/lynx/2.8.2dev.21$ ./lynx -version Lynx Version 2.8.2dev.21 (30 Mar 1999) Copyrights held by the University of Kansas, CERN, and other contributors. Distributed under the GNU General Public License. See http://lynx.browser.org/ and the online help for more information. darkstar:~/lynx/2.8.2dev.21$ ./lynx -dump http://www.altavista.com/ > /dev/null darkstar:~/lynx/2.8.2dev.21$ cat ~/.lynx_cookies .altavista.com FALSE / FALSE 946641600 AV_UID d719f71967c64b darkstar:~/lynx/2.8.2dev.21$ exit exit Script done on Sun Apr 11 17:59:00 1999 Script started on Sun Apr 11 17:59:59 1999 darkstar:~/lynx/2.8.2dev.21$ ./lynx -trace -dump http://www.altavista.com/ > /dev/null darkstar:~/lynx/2.8.2dev.21$ cat ~/.lynx_cookies .altavista.com FALSE / FALSE 946641600 AV_UID d719f71967c64b darkstar:~/lynx/2.8.2dev.21$ grep -i '^Cookie:' ~/Lynx.trace Cookie: AV_UID=d719f71967c64b darkstar:~/lynx/2.8.2dev.21$ exit exit Script done on Sun Apr 11 18:00:52 1999 Am I missing something? AFAIK everything works fine -- a more detailed bug report would help me dig around on this. I'm pretty sure I fixed dump_output_immediately mode for cookie loading and storage a while ago (dev1x or so), so I'm wondering if this is Hotmail being futzy. I'm still really lacking in time (I see I'm not the only one with the cross country move out of CA), so it may take a while, but I'll investigate anything I get. Judiciously snipped trace files can be sent through private mail if needed. -- BJP From owner-lynx-dev@sig.net Sun Apr 11 14:33:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA11026 for ; Sun, 11 Apr 1999 14:33:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA29034; Sun, 11 Apr 1999 13:22:34 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 11 Apr 1999 22:08:48 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2858 Lines: 64 11-Apr-99 12:46 Scott Bigham wrote: > On Sun, 11 Apr 1999, Leonid Pauzner wrote: >> One (minor) problem: keeping a temporarily files for sources cache >> we need to be sure to clean these files on exit. Currently it implemented >> in HText_free() but atexit(free_all_texts) was recently ignored >> without LY_FIND_LEAKS. > And I had LY_FIND_LEAKS on for testing purposes; no wonder I didn't see > it. See, I knew I'd miss something. > (examines code) Wait a minute. The declaration and definition of > free_all_texts() are wrapped in '#ifdef LY_FIND_LEAKS', but the > atexit(free_all_texts) call in HText_new() isn't. How can that even > compile without LY_FIND_LEAKS #define'd? Well, at any rate, the quick That was the very recent changes that #define atexit to nothing to decrease shutdown time (and free_all_texts() is the main contributor), hope will be corrected for dev22 since several problems were reported. > fix would seem to be to change those wrappers to > '#if defined(LY_FIND_LEAKS) || defined(SOURCE_CACHE)'. >> Probably these files will be deleted by clean_files() anyway, > No, cleanup_files() only deletes files listed in the ly_temp list. And > I hesitate to use that mechanism, because then I'd have to go back and > remove those files from ly_temp when they get uncached. I do not understand this. >> ha, don't forget to disable the feature in NONINTERACTIVE mode - it >> will not clean temp files currently (if should not create temp files, >> so a nice check that everything OK). > Hmm, that could be done in the 'if (dump_output_immediately)' block in > main(), yes? sure. >> Also we increase disk activity which may be not good for users >> under disk quota or leaving too much junk if lynx crash unconditionally. > Well, the low-disk-quota user could always put SOURCE_CACHE:FALSE in her > lynx.cfg (or we could have it off by default and make the user turn it > on in lynx.cfg; I only had it on by default for testing purposes), or > compile it out if she's building her own. As for the crash, that will > be the same as with temporary files, yes? I prefer to have a choice between caching sources in temp files or keeping them in RAM by managing a dynamic list of Cached Stream's or so. The latter may be the choice for those with low disk-quota but having enough memory - a standard condition when you run Lynx at ISP machine (not your personal one). The first choice may also slowdown the system (a wild guess). Also, we can expand this little further and implement HTTP/1.1 cache so HTLoad will send conditional GET requests when we already have a source locally. Anyway this may be a next good step. Not sure whether the 'd'ownload command will use the cached sources currently. Lots of minor fixes will be done until the things stabilized. > -sbigham From owner-lynx-dev@sig.net Sun Apr 11 14:33:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA11033 for ; Sun, 11 Apr 1999 14:33:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA29022; Sun, 11 Apr 1999 13:22:32 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 11 Apr 1999 22:19:42 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 761 Lines: 15 11-Apr-99 12:46 Scott Bigham wrote: > On Sun, 11 Apr 1999, Leonid Pauzner wrote: >> One (minor) problem: keeping a temporarily files for sources cache >> we need to be sure to clean these files on exit. Currently it implemented >> in HText_free() but atexit(free_all_texts) was recently ignored >> without LY_FIND_LEAKS. I think there is no strict correlation between the number of cached sources and the number of cached HText's, the only thing currently is a recicling mechanism associated with HText_free(). In fact, we may want to decrease HText cache till 3-4 elements but expand the size of cached sources. This will require a different lists for these objects. So we could solve the problem of deleting of temp files separately from free_all_texts. From owner-lynx-dev@sig.net Sun Apr 11 14:58:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA11552 for ; Sun, 11 Apr 1999 14:58:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA03611; Sun, 11 Apr 1999 13:52:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904111852.OAA23025@shell.clark.net> Subject: Re: path: revised lynx-dev.html To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 14:52:07 -0400 (EDT) In-Reply-To: from "Doug Kaufman " at Apr 11, 99 10:41:48 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 424 Lines: 14 > For some reason, you seem to have added
at the end of each line. > Except for places where this is meaningful, it should probably be > avoided. It reads well. I would recommend the following grammar > correction: yes - we had a discussion about this last year (if I notice unnecessary
's in a patch, I'll remove them). > Doug Kaufman -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 15:13:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA12025 for ; Sun, 11 Apr 1999 15:12:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA05598; Sun, 11 Apr 1999 14:06:41 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 11 Apr 1999 23:03:00 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 575 Lines: 12 11-Apr-99 22:19 I wrote: > I think there is no strict correlation between the number of cached sources > and the number of cached HText's, the only thing currently is a recycling > mechanism associated with HText_free(). In fact, we may want to decrease HText > cache till 3-4 elements but expand the size of cached sources. This will > require a different lists for these objects. So we could solve the problem of > deleting of temp files separately from free_all_texts. Oops, the third list will be HTParentAnchor's that should fit the longer list from the above two. From owner-lynx-dev@sig.net Sun Apr 11 16:11:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA13200 for ; Sun, 11 Apr 1999 16:11:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA14736; Sun, 11 Apr 1999 15:05:20 -0500 (CDT) Date: Sun, 11 Apr 1999 15:57:41 -0400 From: Chuck Martin To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching Message-ID: <19990411155741.B14306@delta.Nexus.of.Obsolescence> Mail-Followup-To: lynx-dev@sig.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Leonid Pauzner on Sun, Apr 11, 1999 at 10:08:48PM +0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 860 Lines: 18 On Sun, Apr 11, 1999 at 10:08:48PM +0400, Leonid Pauzner wrote: > > Also, we can expand this little further and implement HTTP/1.1 cache so > HTLoad will send conditional GET requests when we already have a source > locally. Anyway this may be a next good step. If I'm understanding this correctly, I don't think that's a desireable feature. The point is, I already have a document I'm looking at, and I may want to see the source to see why it looks the way it looks. If the page is dynamically created, the source I get back may not correspond to what I was looking at before, and it defeats my purpose. I don't want the page to be reloaded under any circumstances just because I choose to view it in a different way any more than I want it to be reloaded just because I hit the space bar to go to the next page. Or am I misunderstanding you? Chuck From owner-lynx-dev@sig.net Sun Apr 11 17:26:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA15173 for ; Sun, 11 Apr 1999 17:26:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA23927; Sun, 11 Apr 1999 16:09:00 -0500 (CDT) Date: Sun, 11 Apr 1999 17:08:50 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2265 Lines: 56 On Sun, 11 Apr 1999, Leonid Pauzner wrote: > 11-Apr-99 12:46 Scott Bigham wrote: > > (examines code) Wait a minute. The declaration and definition of > > free_all_texts() are wrapped in '#ifdef LY_FIND_LEAKS', but the > > atexit(free_all_texts) call in HText_new() isn't. How can that even > > compile without LY_FIND_LEAKS #define'd? [...] > That was the very recent changes that #define atexit to nothing > to decrease shutdown time (and free_all_texts() is the main contributor), Eek! That's almost certainly a bad idea. > > No, cleanup_files() only deletes files listed in the ly_temp list. And > > I hesitate to use that mechanism, because then I'd have to go back and > > remove those files from ly_temp when they get uncached. > I do not understand this. Actually, now that I look more closely at the Lynx temp file mechanism (LYOpenTemp() and family in LYUtils.c), it does appear to have all the functionality I need. That should obviate the problem altogether. > > Well, the low-disk-quota user could always put SOURCE_CACHE:FALSE in her > > lynx.cfg (or we could have it off by default and make the user turn it > > on in lynx.cfg; I only had it on by default for testing purposes), or > > compile it out if she's building her own. As for the crash, that will > > be the same as with temporary files, yes? > I prefer to have a choice between caching sources in temp files or keeping > them in RAM by managing a dynamic list of Cached Stream's or so. Yeah, well, I'm not that good. The Lynx code is downright Byzantine; I consider it an accomplishment to have done as much as I did. > Also, we can expand this little further and implement HTTP/1.1 cache so > HTLoad will send conditional GET requests when we already have a source > locally. Anyway this may be a next good step. Well, the whole idea of this was not to have to hit the network at all for something like a view source. That might make sense for an LYK_RELOAD, but I'd be surprised if the reload code didn't do that already. > Not sure whether the 'd'ownload command will use the cached sources > currently. Not currently. I hadn't thought of that one. > Lots of minor fixes will be done until the things stabilized. Well, yes, that was given. :-} -sbigham From owner-lynx-dev@sig.net Sun Apr 11 17:48:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA15674 for ; Sun, 11 Apr 1999 17:47:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA27115; Sun, 11 Apr 1999 16:31:42 -0500 (CDT) To: lynx-dev@sig.net References: <19990411155741.B14306@delta.Nexus.of.Obsolescence> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 01:27:41 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1524 Lines: 31 11-Apr-99 15:57 Chuck Martin wrote: > On Sun, Apr 11, 1999 at 10:08:48PM +0400, Leonid Pauzner wrote: >> >> Also, we can expand this little further and implement HTTP/1.1 cache so >> HTLoad will send conditional GET requests when we already have a source >> locally. Anyway this may be a next good step. > If I'm understanding this correctly, I don't think that's a desireable > feature. The point is, I already have a document I'm looking at, and I > may want to see the source to see why it looks the way it looks. If the > page is dynamically created, the source I get back may not correspond to > what I was looking at before, and it defeats my purpose. I don't want > the page to be reloaded under any circumstances just because I choose to > view it in a different way any more than I want it to be reloaded just > because I hit the space bar to go to the next page. Or am I > misunderstanding you? Yes. I mean we can utilize locally cached sources not only when we change certain layout parameters but also we can emulate proxy-cache without additional costs (if we have no such thing installed on a system, e.g. you run lynx on non-UNIX machine and use ISP's proxy on the other side of a slow link). HTTP/1.1 spec describe the terms of verification whether the document was changed or not, so we can exchange the headers only (under the certain conditions) instead of the entire document when we reload the already visited page. Of cause, the efficiency of such cache depends on a cache size... > Chuck From owner-lynx-dev@sig.net Sun Apr 11 18:14:16 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA01028 for ; Sun, 11 Apr 1999 18:14:15 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA00152 for ; Sun, 11 Apr 1999 19:07:05 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id SAA09155 for ; Sun, 11 Apr 1999 18:34:04 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA03897; Sun, 11 Apr 1999 17:21:43 -0500 (CDT) From: Philip Webb Message-Id: <199904112221.SAA25025@chass.utoronto.ca> Subject: Re: lynx-dev Screen adjustment To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 18:21:38 -0400 (EDT) Cc: warmand@nbnet.nb.ca In-Reply-To: <199904111607.MAA03419@shell.clark.net> from "dickey@clark.net" at Apr 11, 99 12:07:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 763 Lines: 17 990411 David Warman wrote: > I need to use MacLynx on an older Mac SE > but the default window is too large on the smaller Mac SE screen. > How can I adjust the window size? 990411 Thomas Dickey replied: > your terminal description (assuming that lynx is built with curses) > has to match the window that it's running in. > I've not seen the changes made for MacLynx - > a couple of email inquiries in that direction got no response the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 18:14:17 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA01034 for ; Sun, 11 Apr 1999 18:14:16 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA00158 for ; Sun, 11 Apr 1999 19:07:13 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id SAA09177 for ; Sun, 11 Apr 1999 18:36:35 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA03346; Sun, 11 Apr 1999 17:17:25 -0500 (CDT) From: Philip Webb Message-Id: <199904112217.SAA24544@chass.utoronto.ca> Subject: Re: path: revised lynx-dev.html To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 18:17:20 -0400 (EDT) In-Reply-To: <199904111852.OAA23025@shell.clark.net> from "dickey@clark.net" at Apr 11, 99 02:52:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1456 Lines: 29 990411 Tom Dickey & Doug Kaufman wrote: > For some reason, you seem to have added
at the end of each line. > Except for places where this is meaningful, it should probably be > avoided. It reads well. I would recommend the following grammar > correction. > yes - we had a discussion about this last year > (if I notice unnecessary
's in a patch, I'll remove them). i have better things to do than pursue an argument about this, but: (1) having put the time in to do the work, i deserve to decide how to present it to the user, unless there is something clearly awkward or wrong; (2) you don't read the source, you read the rendered version: the
's serve to divide the lines at natural breaks in phrasing & the ordinary user never sees them; (3)
is a perfectly valid item in HTML for authors to use when they want: if most people use it less often, that may be because they are untidy or thoughtless; (4) if we had a discussion about this, my lay-out prevailed: this is not the same issue as the one about

's; (5) there is nothing grammatically wrong with the line as i wrote it, but that's too trivial to argue about. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 18:14:16 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA01032 for ; Sun, 11 Apr 1999 18:14:16 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA00161 for ; Sun, 11 Apr 1999 19:07:14 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id SAA09151 for ; Sun, 11 Apr 1999 18:34:00 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA00328; Sun, 11 Apr 1999 16:53:58 -0500 (CDT) From: dickey@clark.net Message-Id: <199904112153.RAA20187@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 17:53:54 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 11, 99 05:08:50 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 881 Lines: 25 > On Sun, 11 Apr 1999, Leonid Pauzner wrote: > > > 11-Apr-99 12:46 Scott Bigham wrote: > > > > (examines code) Wait a minute. The declaration and definition of > > > free_all_texts() are wrapped in '#ifdef LY_FIND_LEAKS', but the > > > atexit(free_all_texts) call in HText_new() isn't. How can that even > > > compile without LY_FIND_LEAKS #define'd? [...] > > > That was the very recent changes that #define atexit to nothing > > to decrease shutdown time (and free_all_texts() is the main contributor), > > Eek! That's almost certainly a bad idea. no - only on MSDOS is it a bad idea (good idea on Unix and VMS, since allocated memory is returned on exit from a process). MSDOS doesn't have separate address spaces (nor does DJGPP implement that, apparently ;-). > -sbigham -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 18:38:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA00623 for ; Sun, 11 Apr 1999 18:38:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA13910; Sun, 11 Apr 1999 18:31:44 -0500 (CDT) To: lynx-dev@sig.net References: <199904112153.RAA20187@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 03:12:17 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1279 Lines: 32 11-Apr-99 17:53 dickey@clark.net wrote: >> > > (examines code) Wait a minute. The declaration and definition of >> > > free_all_texts() are wrapped in '#ifdef LY_FIND_LEAKS', but the >> > > atexit(free_all_texts) call in HText_new() isn't. How can that even >> > > compile without LY_FIND_LEAKS #define'd? [...] >> >> > That was the very recent changes that #define atexit to nothing >> > to decrease shutdown time (and free_all_texts() is the main contributor), >> >> Eek! That's almost certainly a bad idea. > no - only on MSDOS is it a bad idea (good idea on Unix and VMS, since allocated > memory is returned on exit from a process). MSDOS doesn't have separate > address spaces (nor does DJGPP implement that, apparently ;-). Wrong. DJGPP applications runs with DPMI dos extender which allocate memory and manage virtual pages. On exit from application all allocated memory returned to the system. (No memory problem with dev21, Doug reported a problem with restoring a BREAK signal on exit, completely different story). Not sure how DJGPP will serve several application, share the memory etc., probably no multitasking here. >> -sbigham > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 18:39:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA00632 for ; Sun, 11 Apr 1999 18:39:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA13917; Sun, 11 Apr 1999 18:31:45 -0500 (CDT) To: lynx-dev@sig.net References: <199904112217.SAA24544@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 03:27:55 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: path: revised lynx-dev.html MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1861 Lines: 39 11-Apr-99 18:17 Philip Webb wrote: > 990411 Tom Dickey & Doug Kaufman wrote: >> For some reason, you seem to have added
at the end of each line. >> Except for places where this is meaningful, it should probably be >> avoided. It reads well. I would recommend the following grammar >> correction. >> yes - we had a discussion about this last year >> (if I notice unnecessary
's in a patch, I'll remove them). > i have better things to do than pursue an argument about this, but: > (1) having put the time in to do the work, > i deserve to decide how to present it to the user, > unless there is something clearly awkward or wrong; > (2) you don't read the source, you read the rendered version: > the
's serve to divide the lines at natural breaks in phrasing > & the ordinary user never sees them; Different users may have different screen width (not only 80 col) and HTML documents will be rendered accordingly. So the documents within
 or with 
will not be good looking at different size. Nothing more. (And this is really important in GUI world where a user may want to change a font height or window size). > (3)
is a perfectly valid item in HTML for authors to use when they want: > if most people use it less often, > that may be because they are untidy or thoughtless; > (4) if we had a discussion about this, my lay-out prevailed: > this is not the same issue as the one about

's; > (5) there is nothing grammatically wrong with the line as i wrote it, > but that's too trivial to argue about. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 18:50:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA00945 for ; Sun, 11 Apr 1999 18:50:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA16156; Sun, 11 Apr 1999 18:46:43 -0500 (CDT) To: lynx-dev@sig.net References: <199904112221.SAA25025@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 03:42:04 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Screen adjustment MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 887 Lines: 21 11-Apr-99 18:21 Philip Webb wrote: > 990411 David Warman wrote: >> I need to use MacLynx on an older Mac SE >> but the default window is too large on the smaller Mac SE screen. >> How can I adjust the window size? > 990411 Thomas Dickey replied: >> your terminal description (assuming that lynx is built with curses) >> has to match the window that it's running in. >> I've not seen the changes made for MacLynx - >> a couple of email inquiries in that direction got no response > the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx . This is a port of lynx/2.7.1 and seems no more supported/updated. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 19:03:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA01267 for ; Sun, 11 Apr 1999 19:03:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA18011; Sun, 11 Apr 1999 18:59:57 -0500 (CDT) From: Philip Webb Message-Id: <199904112359.TAA01460@chass.utoronto.ca> Subject: lynx-dev Lynx for Mac's (was screen adjustment) To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 19:59:52 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 12, 99 03:42:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 748 Lines: 16 990412 Leonid Pauzner wrote: > 11-Apr-99 18:21 Philip Webb wrote: >> the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx . > This is a port of lynx/2.7.1 and seems no more supported/updated. yes, i had a feeling it was getting marginal these days, which raises the question whether we should still claim that Lynx is available on Mac's. shouldn't we perhaps rather say that we need someone to do a good upto-date job of re-porting it, with appropriate help documentation? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 19:11:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA01513 for ; Sun, 11 Apr 1999 19:11:35 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA17486; Sun, 11 Apr 1999 18:56:16 -0500 (CDT) From: Philip Webb Message-Id: <199904112356.TAA01156@chass.utoronto.ca> Subject: Re: path: revised lynx-dev.html To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 19:56:11 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 12, 99 03:27:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1105 Lines: 24 990411 Leonid Pauzner wrote: > 11-Apr-99 18:17 Philip Webb wrote: >> (2) you don't read the source, you read the rendered version: >> the
's serve to divide the lines at natural breaks in phrasing >> & the ordinary user never sees them; > Different users may have different screen width (not only 80 col) > and HTML documents will be rendered accordingly. > So the documents within
 or with 
> will not be good looking at different size. Nothing more. yes, but inserting
to force a line-break at a phrase-break will always shorten the line; people with very wide screens will need to hit the Space-bar a bit more often, that's all. > this is really important in GUI world > where a user may want to change a font height or window size. people are unlikely to read Lynx help files with a GUI browser. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sun Apr 11 19:16:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA01721 for ; Sun, 11 Apr 1999 19:16:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA19782; Sun, 11 Apr 1999 19:11:13 -0500 (CDT) Message-ID: <3710F36A.1F477C68@tamu.edu> Date: Sun, 11 Apr 1999 19:09:30 +0000 From: randy X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i586) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: Re: lynx-dev Fatal error in Lynx Ver. 2.5 References: <199904111738.KAA00608@betelgeuse.starshine.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1005 Lines: 26 Heather Stern wrote: > > 990409 Randy Speaks wrote: > > > Strangest thing happened tonight. > ... > > >> Lynx now exiting with signal: 11 > ... > > > Furthermore, lynx still works fine if I run it as root. > > > Only when I am logged on as my usual login name does it crash like this. > > > Any ideas/help out there? > While Philip's answer is valid (lynx has changed a lot, you want a new > one) it doesn't answer what happened to your previously working copy. Yes, thanks to both of you for the advice. Philip's advice was a standard answer, but not for me at that point; but that is just a philosophical issue. I found the problem just an hour or so after I posted, being the inquisitive Linux user that I am :) It had nothing to do with lynx or the internet. As you detected; it was a system 'pilot' error. That may be off topic here, so I won't go into it unless someone really wants to know about it. The important thing is that the application works flawlessly once again! Thanks again. Randy From owner-lynx-dev@sig.net Sun Apr 11 20:24:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA03278 for ; Sun, 11 Apr 1999 20:24:08 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA00480; Sun, 11 Apr 1999 20:15:20 -0500 (CDT) From: dickey@clark.net Message-Id: <199904120115.VAA23278@shell.clark.net> Subject: Re: path: revised lynx-dev.html To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 21:15:16 -0400 (EDT) In-Reply-To: <199904112217.SAA24544@chass.utoronto.ca> from "Philip Webb " at Apr 11, 99 06:17:20 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 374 Lines: 12 > (2) you don't read the source, you read the rendered version: > the
's serve to divide the lines at natural breaks in phrasing > & the ordinary user never sees them; I read the source, run ispell (if the change is more than I can scan rapidly), weblint and tidy -- on each html file. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 20:34:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA03505 for ; Sun, 11 Apr 1999 20:34:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA02099; Sun, 11 Apr 1999 20:24:06 -0500 (CDT) From: dickey@clark.net Message-Id: <199904120124.VAA26791@shell.clark.net> Subject: Re: lynx-dev Screen adjustment To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 21:24:03 -0400 (EDT) In-Reply-To: <199904112221.SAA25025@chass.utoronto.ca> from "Philip Webb " at Apr 11, 99 06:21:38 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 826 Lines: 24 > > 990411 David Warman wrote: > > I need to use MacLynx on an older Mac SE > > but the default window is too large on the smaller Mac SE screen. > > How can I adjust the window size? > 990411 Thomas Dickey replied: > > your terminal description (assuming that lynx is built with curses) > > has to match the window that it's running in. > > I've not seen the changes made for MacLynx - > > a couple of email inquiries in that direction got no response > > the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx . I followed a different link before - there was no source there (this one's got something in binhex format; perhaps I'll find time to unravel that) > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 20:47:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA03972 for ; Sun, 11 Apr 1999 20:47:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA01438; Sun, 11 Apr 1999 20:20:35 -0500 (CDT) From: dickey@clark.net Message-Id: <199904120120.VAA24634@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 21:20:32 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 12, 99 03:12:17 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 744 Lines: 19 > Wrong. DJGPP applications runs with DPMI dos extender > which allocate memory and manage virtual pages. > On exit from application all allocated memory returned to the system. > (No memory problem with dev21, Doug reported a problem with restoring > a BREAK signal on exit, completely different story). you're right - I hadn't gotten to processing Doug's patch yet, and was thinking about a similarly-named Unix symbol (brk or ebrk) which denotes the limit of the process address space. > Not sure how DJGPP will serve several application, > share the memory etc., probably no multitasking here. > > >> -sbigham -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 11 20:50:39 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA03995 for ; Sun, 11 Apr 1999 20:50:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA02215; Sun, 11 Apr 1999 20:24:46 -0500 (CDT) Date: Sun, 11 Apr 1999 21:24:12 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904112124.AA26111@cas.org> Subject: Re: lynx-dev LYNX: neat new search engine at www.google.com In-Reply-To: Your message of Sun, 11 Apr 1999 09:02:57 -0600 (MDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 535 Lines: 15 From: pg@sweng.stortek.com > In a recent note, David Combs said: > > Date: Sat, 10 Apr 1999 18:15:46 -0700 (PDT) > > > > Looks really good. Is beta version, it says. > > comes out of the cs dept at stanford. > > > Son of Yahoo? Son of Ask Jeeves in appearance ... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Sun Apr 11 22:15:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA05930 for ; Sun, 11 Apr 1999 22:15:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA19401; Sun, 11 Apr 1999 21:49:58 -0500 (CDT) Date: Sun, 11 Apr 1999 22:49:42 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching In-Reply-To: <199904112153.RAA20187@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 582 Lines: 16 On Sun, 11 Apr 1999 dickey@clark.net wrote: [I wrote, discussing "#define atexit(func) /* nothing */"] > > Eek! That's almost certainly a bad idea. > no - only on MSDOS is it a bad idea (good idea on Unix and VMS, since > allocated memory is returned on exit from a process). Actually, I was thinking more along the lines of someone in the future trying to install an atexit function that does something besides release memory, not knowing he was being undercut. I dunno, call me paranoid, but this just has "disaster waiting to happen" written all over it. -sbigham From owner-lynx-dev@sig.net Sun Apr 11 22:46:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA06717 for ; Sun, 11 Apr 1999 22:46:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA26212; Sun, 11 Apr 1999 22:26:00 -0500 (CDT) Date: Sun, 11 Apr 1999 23:25:54 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: lynx-dev PATCH [dev21]: source caching, take 2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 632 Lines: 17 On Sun, 11 Apr 1999, Scott Bigham wrote: > On Sun, 11 Apr 1999, Leonid Pauzner wrote: > > I prefer to have a choice between caching sources in temp files or keeping > > them in RAM by managing a dynamic list of Cached Stream's or so. > Yeah, well, I'm not that good. You had to challenge me, didn't you? ;) Okay, after some pfutzing around with HTChunks, I think I've got a working version of memory caching of source. The SOURCE_CACHE option now has settings FILE, MEMORY and NONE, with the obvious meanings, defaulting to NONE. This patch replaces my previous patch, so you'll have to back that out first. -sbigham From owner-lynx-dev@sig.net Sun Apr 11 23:05:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA07196 for ; Sun, 11 Apr 1999 23:05:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA26837; Sun, 11 Apr 1999 22:29:16 -0500 (CDT) Date: Sun, 11 Apr 1999 23:29:00 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: Lynx Development List Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1077411990-923887740=:1861" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 36705 Lines: 611 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1077411990-923887740=:1861 Content-Type: TEXT/PLAIN; charset=US-ASCII D'oh! *This* time the patch is attached. We apologize for the confusion. -sbigham --8323328-1077411990-923887740=:1861 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="source_cache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="source_cache.diff" KioqIC4vc3JjL0dyaWRUZXh0LmMub3JpZwlUdWUgTWFyIDMwIDEyOjEwOjM3 IDE5OTkNCi0tLSAuL3NyYy9HcmlkVGV4dC5jCVN1biBBcHIgMTEgMjI6MzE6 MTEgMTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogNDYsNTEgKioqKg0KLS0t IDQ2LDU1IC0tLS0NCiAgDQogICN1bmRlZiBERUJVR19BUFBDSA0KICANCisg I2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAjaW5jbHVkZSA8SFRGaWxlLmg+DQor ICNlbmRpZg0KKyANCiAgI2lmZGVmIFVTRV9DT0xPUl9TVFlMRQ0KICAjaW5j bHVkZSA8QXR0ckxpc3QuaD4NCiAgI2luY2x1ZGUgPExZSGFzaC5oPg0KKioq KioqKioqKioqKioqDQoqKiogMTE0LDExOSAqKioqDQotLS0gMTE4LDEyOSAt LS0tDQogIFBVQkxJQyBCT09MRUFOIHVuZGVybGluZV9vbiA9IE9GRjsNCiAg UFVCTElDIEJPT0xFQU4gYm9sZF9vbiAgICAgID0gT0ZGOw0KICANCisgI2lm ZGVmIFNPVVJDRV9DQUNIRQ0KKyBQVUJMSUMgY2hhciAqIHNvdXJjZV9jYWNo ZV9maWxlbmFtZSA9IE5VTEw7DQorIFBVQkxJQyBIVENodW5rICogc291cmNl X2NhY2hlX2NodW5rID0gTlVMTDsNCisgUFVCTElDIGludCBMWUNhY2hlU291 cmNlID0gU09VUkNFX0NBQ0hFX05PTkU7DQorICNlbmRpZg0KKyANCiAgI2lm IGRlZmluZWQoVVNFX0NPTE9SX1NUWUxFKQ0KICAjZGVmaW5lIE1BWF9TVFlM RVNfT05fTElORSA2NA0KICANCioqKioqKioqKioqKioqKg0KKioqIDE3Mywx NzggKioqKg0KLS0tIDE4MywyMDQgLS0tLQ0KICAqLw0KICBzdHJ1Y3QgX0hU ZXh0IHsNCiAgCUhUUGFyZW50QW5jaG9yICoJbm9kZV9hbmNob3I7DQorICNp ZmRlZiBTT1VSQ0VfQ0FDSEUNCisgCWNoYXIgKgkJCXNvdXJjZV9jYWNoZV9m aWxlOw0KKyAJSFRDaHVuayAqCQlzb3VyY2VfY2FjaGVfY2h1bms7DQorIAkv Kg0KKyAJICogUGFyc2Ugc2V0dGluZ3Mgd2hlbiB0aGlzIEhUZXh0IHdhcyBn ZW5lcmF0ZWQuDQorIAkgKi8NCisgCUJPT0xFQU4JCQljbGlja2FibGVfaW1h Z2VzOw0KKyAJQk9PTEVBTgkJCXBzZXVkb19pbmxpbmVfYWx0czsNCisgCUJP T0xFQU4JCQlyYXdfbW9kZTsNCisgCUJPT0xFQU4JCQloaXN0b3JpY2FsX2Nv bW1lbnRzOw0KKyAJQk9PTEVBTgkJCW1pbmltYWxfY29tbWVudHM7DQorIAlC T09MRUFOCQkJc29mdF9kcXVvdGVzOw0KKyAJQk9PTEVBTgkJCW9sZF9kdGQ7 DQorIAlpbnQJCQlsaW5lczsJCS8qIFNjcmVlbiBzaXplICovDQorIAlpbnQJ CQljb2xzOw0KKyAjZW5kaWYNCiAgCUhUTGluZSAqCQlsYXN0X2xpbmU7DQog IAlpbnQJCQlMaW5lczsJCS8qIE51bWJlciBvZiB0aGVtICovDQogIAlpbnQJ CQljaGFyczsJCS8qIE51bWJlciBvZiB0aGVtICovDQoqKioqKioqKioqKioq KioNCioqKiA0ODMsNDg4ICoqKioNCi0tLSA1MDksNTQyIC0tLS0NCiAgICAg IHNlbGYtPnN0YWxlID0gWUVTOw0KICAgICAgc2VsZi0+dG9vbGJhciA9IE5P Ow0KICAgICAgc2VsZi0+dGFicyA9IE5VTEw7DQorICNpZmRlZiBTT1VSQ0Vf Q0FDSEUNCisgICAgIC8qDQorICAgICAgKiBZZXMsIHRoaXMgaXMgYSBHcm9z cyBBbmQgRGlzZ3VzdGluZyBIYWNrKFRNKSwgSSBrbm93Li4uDQorICAgICAg Ki8NCisgICAgIHNlbGYtPnNvdXJjZV9jYWNoZV9maWxlID0gTlVMTDsNCisg ICAgIGlmIChMWUNhY2hlU291cmNlID09IFNPVVJDRV9DQUNIRV9GSUxFICYm IHNvdXJjZV9jYWNoZV9maWxlbmFtZSkgew0KKyAgICAgICBTdHJBbGxvY0Nv cHkoc2VsZi0+c291cmNlX2NhY2hlX2ZpbGUsIHNvdXJjZV9jYWNoZV9maWxl bmFtZSk7DQorICAgICAgIEZSRUUoc291cmNlX2NhY2hlX2ZpbGVuYW1lKTsN CisgICAgIH0NCisgICAgIHNlbGYtPnNvdXJjZV9jYWNoZV9jaHVuayA9IE5V TEw7DQorICAgICBpZiAoTFlDYWNoZVNvdXJjZSA9PSBTT1VSQ0VfQ0FDSEVf TUVNT1JZICYmIHNvdXJjZV9jYWNoZV9jaHVuaykgew0KKyAJc2VsZi0+c291 cmNlX2NhY2hlX2NodW5rID0gc291cmNlX2NhY2hlX2NodW5rOw0KKyAJc291 cmNlX2NhY2hlX2NodW5rID0gTlVMTDsNCisgICAgIH0NCisgDQorICAgICAv Kg0KKyAgICAgICogUmVtZW1iZXIgdGhlIHBhcnNlIHNldHRpbmdzLg0KKyAg ICAgICovDQorICAgICBzZWxmLT5jbGlja2FibGVfaW1hZ2VzID0gY2xpY2th YmxlX2ltYWdlczsNCisgICAgIHNlbGYtPnBzZXVkb19pbmxpbmVfYWx0cyA9 IHBzZXVkb19pbmxpbmVfYWx0czsNCisgICAgIHNlbGYtPnJhd19tb2RlID0g TFlSYXdNb2RlOw0KKyAgICAgc2VsZi0+aGlzdG9yaWNhbF9jb21tZW50cyA9 IGhpc3RvcmljYWxfY29tbWVudHM7DQorICAgICBzZWxmLT5taW5pbWFsX2Nv bW1lbnRzID0gbWluaW1hbF9jb21tZW50czsNCisgICAgIHNlbGYtPnNvZnRf ZHF1b3RlcyA9IHNvZnRfZHF1b3RlczsNCisgICAgIHNlbGYtPm9sZF9kdGQg PSBPbGRfRFREOw0KKyAgICAgc2VsZi0+bGluZXMgPSBMWWxpbmVzOw0KKyAg ICAgc2VsZi0+Y29scyA9IExZY29sczsNCisgI2VuZGlmDQogICAgICAvKg0K ICAgICAgICogIElmIHdlIGFyZSBnb2luZyB0byByZW5kZXIgdGhlIExpc3Qg UGFnZSwgYWx3YXlzIG1lcmdlIGluIGhpZGRlbg0KICAgICAgICogIGxpbmtz IHRvIGdldCB0aGUgbnVtYmVyaW5nIGNvbnNpc3RlbnQgaWYgZm9ybSBmaWVs ZHMgYXJlIG51bWJlcmVkDQoqKioqKioqKioqKioqKioNCioqKiA3MjksNzM0 ICoqKioNCi0tLSA3ODMsODA1IC0tLS0NCiAgCSAgICBIVE1haW5BbmNob3Ig PSBOVUxMOw0KICAgICAgfQ0KICANCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0K KyAgICAgLyoNCisgICAgICAqIENsZWFuIHVwIHRoZSBzb3VyY2UgY2FjaGUs IGlmIGFueS4NCisgICAgICAqLw0KKyAgICAgaWYgKHNlbGYtPnNvdXJjZV9j YWNoZV9maWxlKSB7DQorIAlDVFJBQ0UodGZwLCAiUmVtb3Zpbmcgc291cmNl IGNhY2hlIGZpbGUgJXNcbiIsDQorIAkgICAgICAgc2VsZi0+c291cmNlX2Nh Y2hlX2ZpbGUpOw0KKyAJTFlSZW1vdmVUZW1wKHNlbGYtPnNvdXJjZV9jYWNo ZV9maWxlKTsNCisgCUZSRUUoc2VsZi0+c291cmNlX2NhY2hlX2ZpbGUpOw0K KyAgICAgfQ0KKyAgICAgaWYgKHNlbGYtPnNvdXJjZV9jYWNoZV9jaHVuaykg ew0KKyAJQ1RSQUNFKHRmcCwgIlJlbW92aW5nIG1lbW9yeSBzb3VyY2UgY2Fj aGUgJXBcbiIsDQorIAkgICAgICAgKHZvaWQgKilzZWxmLT5zb3VyY2VfY2Fj aGVfY2h1bmspOw0KKyAJSFRDaHVua0ZyZWUoc2VsZi0+c291cmNlX2NhY2hl X2NodW5rKTsNCisgICAgIH0NCisgI2VuZGlmDQorIA0KICAgICAgRlJFRShz ZWxmKTsNCiAgfQ0KICANCioqKioqKioqKioqKioqKg0KKioqIDYxODksNjE5 NCAqKioqDQotLS0gNjI2MCw2NDM4IC0tLS0NCiAgCUNUUkFDRSh0ZnAsICJI VHVuY2FjaGUuLiBIVE1haW5UZXh0IGFscmVhZHkgaXMgTlVMTCFcbiIpOw0K ICAgICAgfQ0KICB9DQorIA0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorIC8q DQorICAqIFRoaXMgaXMgY29waWVkIG1vcmUgb3IgbGVzcyB2ZXJiYXRpbSBm cm9tIEhUUGFyc2VGaWxlKCkgaW4gSFRGb3JtYXQuYw0KKyAgKi8NCisgUFJJ VkFURSBpbnQgSFRQYXJzZU1lbSBBUkdTNSgNCisgCUhURm9ybWF0LAkJcmVw X2luLA0KKyAJSFRGb3JtYXQsCQlmb3JtYXRfb3V0LA0KKyAJSFRQYXJlbnRB bmNob3IgKiwJYW5jaG9yLA0KKyAJSFRDaHVuayAqLAkJY2h1bmssDQorIAlI VFN0cmVhbSAqLAkJc2luaykNCisgew0KKyAgICAgSFRTdHJlYW0gKiBzdHJl YW07DQorICAgICBIVFN0cmVhbUNsYXNzIHRhcmdldENsYXNzOw0KKyANCisg ICAgIHN0cmVhbSA9IEhUU3RyZWFtU3RhY2socmVwX2luLCBmb3JtYXRfb3V0 LCBzaW5rLCBhbmNob3IpOw0KKyAgICAgaWYgKCFzdHJlYW0pIHsNCisgCWlu dCBydjsNCisgCWNoYXIgKmJ1ZmZlciA9IDA7DQorIAlIVFNwcmludGYwKCZi dWZmZXIsIENBTk5PVF9DT05WRVJUX0lfVE9fTywNCisgCQkgICBIVEF0b21f bmFtZShyZXBfaW4pLCBIVEF0b21fbmFtZShmb3JtYXRfb3V0KSk7DQorIAlD VFJBQ0UodGZwLCAiSFRGb3JtYXQoaW4gSFRQYXJzZU1lbSk6ICVzXG4iLCBi dWZmZXIpOw0KKyAJcnYgPSBIVExvYWRFcnJvcihzaW5rLCA1MDEsIGJ1ZmZl cik7DQorIAlGUkVFKGJ1ZmZlcik7DQorIAlyZXR1cm4gcnY7DQorICAgICB9 DQorIA0KKyAgICAgLyogU2hvdmUgdGhlIGRhdGEgZG93biB0aGUgc3RyZWFt IGluIG9uZSBsdW1wLiA7KSAqLw0KKyAgICAgdGFyZ2V0Q2xhc3MgPSAqKHN0 cmVhbS0+aXNhKTsNCisgICAgICgqdGFyZ2V0Q2xhc3MucHV0X2Jsb2NrKShz dHJlYW0sIGNodW5rLT5kYXRhLCBjaHVuay0+c2l6ZSk7DQorICAgICAoKnRh cmdldENsYXNzLl9mcmVlKShzdHJlYW0pOw0KKyAgICAgcmV0dXJuIEhUX0xP QURFRDsNCisgfQ0KKyANCisgUFVCTElDIEJPT0xFQU4gSFRyZXBhcnNlX2Rv Y3VtZW50IE5PQVJHUw0KKyB7DQorICAgICBCT09MRUFOIG9rID0gRkFMU0U7 DQorIA0KKyAgICAgaWYgKCFIVE1haW5UZXh0IHx8IExZQ2FjaGVTb3VyY2Ug PT0gU09VUkNFX0NBQ0hFX05PTkUgfHwNCisgCShMWUNhY2hlU291cmNlID09 IFNPVVJDRV9DQUNIRV9GSUxFICYmDQorIAkgIUhUTWFpblRleHQtPnNvdXJj ZV9jYWNoZV9maWxlKSB8fA0KKyAJKExZQ2FjaGVTb3VyY2UgPT0gU09VUkNF X0NBQ0hFX01FTU9SWSAmJg0KKyAJICFIVE1haW5UZXh0LT5zb3VyY2VfY2Fj aGVfY2h1bmspKQ0KKyAJcmV0dXJuIEZBTFNFOw0KKyANCisgICAgIGlmIChM WUNhY2hlU291cmNlID09IFNPVVJDRV9DQUNIRV9GSUxFICYmIEhUTWFpblRl eHQtPnNvdXJjZV9jYWNoZV9maWxlKSB7DQorIAlGSUxFICogZnA7DQorIAlI VEZvcm1hdCBmb3JtYXQ7DQorIAlpbnQgcmV0Ow0KKyANCisgCUNUUkFDRSh0 ZnAsICJSZXBhcnNpbmcgc291cmNlIGNhY2hlIGZpbGUgJXNcbiIsDQorIAkg ICAgICAgSFRNYWluVGV4dC0+c291cmNlX2NhY2hlX2ZpbGUpOw0KKyANCisg CS8qDQorIAkgKiBUaGlzIGlzIG1vcmUgb3IgbGVzcyBjb3BpZWQgb3V0IG9m IEhUTG9hZEZpbGUoKSwgZXhjZXB0IHdlIGRvbid0DQorIAkgKiBnZXQgYSBj b250ZW50IGVuY29kaW5nLiAgVGhpcyBtYXkgYmUgb3ZlcmtpbGwuLi4NCisg CSAqLw0KKyAJaWYgKEhUTWFpblRleHQtPm5vZGVfYW5jaG9yLT5jb250ZW50 X3R5cGUpIHsNCisgCSAgICBmb3JtYXQgPSBIVEF0b21fZm9yKEhUTWFpblRl eHQtPm5vZGVfYW5jaG9yLT5jb250ZW50X3R5cGUpOw0KKyAJfSBlbHNlIHsN CisgCSAgICBmb3JtYXQgPSBIVEZpbGVGb3JtYXQoSFRNYWluVGV4dC0+c291 cmNlX2NhY2hlX2ZpbGUsIE5VTEwsIE5VTEwpOw0KKyAJICAgIGZvcm1hdCA9 IEhUQ2hhcnNldEZvcm1hdChmb3JtYXQsIEhUTWFpblRleHQtPm5vZGVfYW5j aG9yLA0KKyAJCQkJICAgICBVQ0xZaG5kbF9IVEZpbGVfZm9yX3Vuc3BlYyk7 DQorIAl9DQorIAlDVFJBQ0UodGZwLCAiICBDb250ZW50IHR5cGUgaXMgXCIl c1wiXG4iLCBmb3JtYXQtPm5hbWUpOw0KKyANCisgCS8qDQorIAkgKiBQYXNz IHRoZSBzb3VyY2UgY2FjaGUgZmlsZW5hbWUgb24gdG8gdGhlIG5leHQgSFRl eHQuICBNYXJrIGl0DQorIAkgKiBOVUxMIGhlcmUgc28gdGhhdCBpdCB3b24n dCBnZXQgZGVsZXRlZCBieSBIVGV4dF9mcmVlKCkuDQorIAkgKi8NCisgCXNv dXJjZV9jYWNoZV9maWxlbmFtZSA9IEhUTWFpblRleHQtPnNvdXJjZV9jYWNo ZV9maWxlOw0KKyAJSFRNYWluVGV4dC0+c291cmNlX2NhY2hlX2ZpbGUgPSBO VUxMOw0KKyANCisgCWZwID0gZm9wZW4oc291cmNlX2NhY2hlX2ZpbGVuYW1l LCAiciIpOw0KKyAJaWYgKCFmcCkgew0KKyAJICAgIENUUkFDRSh0ZnAsICIg IENhbm5vdCByZWFkIGZpbGUgJXNcbiIsIHNvdXJjZV9jYWNoZV9maWxlbmFt ZSk7DQorIAkgICAgRlJFRShzb3VyY2VfY2FjaGVfZmlsZW5hbWUpOw0KKyAJ ICAgIHJldHVybiBGQUxTRTsNCisgCX0NCisgCXJldCA9IEhUUGFyc2VGaWxl KGZvcm1hdCwgSFRPdXRwdXRGb3JtYXQsIEhUTWFpblRleHQtPm5vZGVfYW5j aG9yLA0KKyAJCQkgIGZwLCBOVUxMKTsNCisgCWZjbG9zZShmcCk7DQorIAlv ayA9IChyZXQgPT0gSFRfTE9BREVEKTsNCisgCWlmICghb2spDQorIAkgICAg RlJFRShzb3VyY2VfY2FjaGVfZmlsZW5hbWUpOw0KKyAgICAgfQ0KKyANCisg ICAgIGlmIChMWUNhY2hlU291cmNlID09IFNPVVJDRV9DQUNIRV9NRU1PUlkg JiYNCisgCUhUTWFpblRleHQtPnNvdXJjZV9jYWNoZV9jaHVuaykgew0KKyAJ SFRGb3JtYXQgZm9ybWF0ID0gV1dXX0hUTUw7DQorIAlpbnQgcmV0Ow0KKyAN CisgCUNUUkFDRSh0ZnAsICJSZXBhcnNpbmcgZnJvbSBzb3VyY2UgbWVtb3J5 IGNhY2hlICVwXG4iLA0KKyAJICAgICAgICh2b2lkICopSFRNYWluVGV4dC0+ c291cmNlX2NhY2hlX2NodW5rKTsNCisgDQorIAkvKg0KKyAJICogUGFzcyB0 aGUgc291cmNlIGNhY2hlIEhUQ2h1bmsgb24gdG8gdGhlIG5leHQgSFRleHQu ICBDbGVhciBpdA0KKyAJICogaGVyZSBzbyB0aGF0IGl0IHdvbid0IGdldCBk ZWxldGVkIGJ5IEhUZXh0X2ZyZWUoKS4NCisgCSAqLw0KKyAJc291cmNlX2Nh Y2hlX2NodW5rID0gSFRNYWluVGV4dC0+c291cmNlX2NhY2hlX2NodW5rOw0K KyAJSFRNYWluVGV4dC0+c291cmNlX2NhY2hlX2NodW5rID0gTlVMTDsNCisg DQorIAlyZXQgPSBIVFBhcnNlTWVtKGZvcm1hdCwgSFRPdXRwdXRGb3JtYXQs IEhUTWFpblRleHQtPm5vZGVfYW5jaG9yLA0KKyAJCQkgc291cmNlX2NhY2hl X2NodW5rLCBOVUxMKTsNCisgCW9rID0gKHJldCA9PSBIVF9MT0FERUQpOw0K KyAJaWYgKCFvaykgew0KKyAJICAgIEhUQ2h1bmtGcmVlKHNvdXJjZV9jYWNo ZV9jaHVuayk7DQorIAkgICAgc291cmNlX2NhY2hlX2NodW5rID0gTlVMTDsN CisgCX0NCisgICAgIH0NCisgICAgIA0KKyAgICAgQ1RSQUNFKHRmcCwgIlJl cGFyc2UgJXNcbiIsIChvayA/ICJzdWNjZWVkZWQiIDogImZhaWxlZCIpKTsN CisgICAgIHJldHVybiBvazsNCisgfQ0KKyANCisgUFJJVkFURSB2b2lkIHRy YWNlX3NldHRpbmdfY2hhbmdlIEFSR1MzKA0KKyAJQ09OU1QgY2hhciAqLAlu YW1lLA0KKyAJQk9PTEVBTiwJcHJldl9zZXR0aW5nLA0KKyAJQk9PTEVBTiwJ bmV3X3NldHRpbmcpDQorIHsNCisgICAgIGlmIChwcmV2X3NldHRpbmcgIT0g bmV3X3NldHRpbmcpDQorIAlDVFJBQ0UodGZwLCAiSFRkb2N1bWVudF9zZXR0 aW5nc19jaGFuZ2VkOiAlcyBzZXR0aW5nIGhhcyBjaGFuZ2VkICh3YXMgJXMs IG5vdyAlcylcbiIsDQorIAkgICAgICAgbmFtZSwgcHJldl9zZXR0aW5nID8g Ik9OIiA6ICJPRkYiLCBuZXdfc2V0dGluZyA/ICJPTiIgOiAiT0ZGIik7DQor IH0NCisgDQorIFBVQkxJQyBCT09MRUFOIEhUZG9jdW1lbnRfc2V0dGluZ3Nf Y2hhbmdlZCBOT0FSR1MNCisgew0KKyAgICAgLyoNCisgICAgICAqIEFubm95 aW5nIEhhY2soVE0pOiAgSWYgd2UgZG9uJ3QgaGF2ZSBhIHNvdXJjZSBjYWNo ZSwgd2UgY2FuJ3QNCisgICAgICAqIHJlcGFyc2UgYW55d2F5LCBzbyBwcmV0 ZW5kIHRoZSBzZXR0aW5ncyBoYXZlbid0IGNoYW5nZWQuDQorICAgICAgKi8N CisgICAgIGlmICghSFRNYWluVGV4dCB8fCBMWUNhY2hlU291cmNlID09IFNP VVJDRV9DQUNIRV9OT05FIHx8DQorIAkoTFlDYWNoZVNvdXJjZSA9PSBTT1VS Q0VfQ0FDSEVfRklMRSAmJg0KKyAJICFIVE1haW5UZXh0LT5zb3VyY2VfY2Fj aGVfZmlsZSkgfHwNCisgCShMWUNhY2hlU291cmNlID09IFNPVVJDRV9DQUNI RV9NRU1PUlkgJiYNCisgCSAhSFRNYWluVGV4dC0+c291cmNlX2NhY2hlX2No dW5rKSkNCisgCXJldHVybiBGQUxTRTsNCisgDQorICAgICBpZiAoVFJBQ0Up IHsNCisgCS8qDQorIAkgKiBJZiB3ZSdyZSB0cmFjaW5nLCBub3RlIGV2ZXJ5 aW5nIHRoYXQgaGFzIGNoYW5nZWQuDQorIAkgKi8NCisgCXRyYWNlX3NldHRp bmdfY2hhbmdlKCJDTElDS0FCTEVfSU1BR0VTIiwNCisgCQkJICAgICBIVE1h aW5UZXh0LT5jbGlja2FibGVfaW1hZ2VzLCBjbGlja2FibGVfaW1hZ2VzKTsN CisgCXRyYWNlX3NldHRpbmdfY2hhbmdlKCJQU0VVRE9fSU5MSU5FX0FMVFMi LA0KKyAJCQkgICAgIEhUTWFpblRleHQtPnBzZXVkb19pbmxpbmVfYWx0cywN CisgCQkJICAgICBwc2V1ZG9faW5saW5lX2FsdHMpOw0KKyAJdHJhY2Vfc2V0 dGluZ19jaGFuZ2UoIlJBV19NT0RFIiwgSFRNYWluVGV4dC0+cmF3X21vZGUs IExZUmF3TW9kZSk7DQorIAl0cmFjZV9zZXR0aW5nX2NoYW5nZSgiSElTVE9S SUNBTF9DT01NRU5UUyIsDQorIAkJCSAgICAgSFRNYWluVGV4dC0+aGlzdG9y aWNhbF9jb21tZW50cywNCisgCQkJICAgICBoaXN0b3JpY2FsX2NvbW1lbnRz KTsNCisgCXRyYWNlX3NldHRpbmdfY2hhbmdlKCJNSU5JTUFMX0NPTU1FTlRT IiwNCisgCQkJICAgICBIVE1haW5UZXh0LT5taW5pbWFsX2NvbW1lbnRzLCBt aW5pbWFsX2NvbW1lbnRzKTsNCisgCXRyYWNlX3NldHRpbmdfY2hhbmdlKCJT T0ZUX0RRVU9URVMiLA0KKyAJCQkgICAgIEhUTWFpblRleHQtPnNvZnRfZHF1 b3Rlcywgc29mdF9kcXVvdGVzKTsNCisgCXRyYWNlX3NldHRpbmdfY2hhbmdl KCJPTERfRFREIiwgSFRNYWluVGV4dC0+b2xkX2R0ZCwgT2xkX0RURCk7DQor IAlpZiAoSFRNYWluVGV4dC0+bGluZXMgIT0gTFlsaW5lcyB8fCBIVE1haW5U ZXh0LT5jb2xzICE9IExZY29scykNCisgCSAgICBDVFJBQ0UodGZwLA0KKyAJ CSAgICJIVGRvY3VtZW50X3NldHRpbmdzX2NoYW5nZWQ6IFNjcmVlbiBzaXpl IGhhcyBjaGFuZ2VkICh3YXMgJWR4JWQsIG5vdyAlZHglZClcbiIsDQorIAkJ ICAgSFRNYWluVGV4dC0+Y29scywgSFRNYWluVGV4dC0+bGluZXMsIExZY29s cywgTFlsaW5lcyk7DQorICAgICB9DQorIA0KKyAgICAgcmV0dXJuIChIVE1h aW5UZXh0LT5jbGlja2FibGVfaW1hZ2VzICE9IGNsaWNrYWJsZV9pbWFnZXMg fHwNCisgCSAgICBIVE1haW5UZXh0LT5wc2V1ZG9faW5saW5lX2FsdHMgIT0g cHNldWRvX2lubGluZV9hbHRzIHx8DQorIAkgICAgSFRNYWluVGV4dC0+cmF3 X21vZGUgIT0gTFlSYXdNb2RlIHx8DQorIAkgICAgSFRNYWluVGV4dC0+aGlz dG9yaWNhbF9jb21tZW50cyAhPSBoaXN0b3JpY2FsX2NvbW1lbnRzIHx8DQor IAkgICAgSFRNYWluVGV4dC0+bWluaW1hbF9jb21tZW50cyAhPSBtaW5pbWFs X2NvbW1lbnRzIHx8DQorIAkgICAgSFRNYWluVGV4dC0+c29mdF9kcXVvdGVz ICE9IHNvZnRfZHF1b3RlcyB8fA0KKyAJICAgIEhUTWFpblRleHQtPm9sZF9k dGQgIT0gT2xkX0RURCB8fA0KKyAJICAgIEhUTWFpblRleHQtPmxpbmVzICE9 IExZbGluZXMgfHwNCisgCSAgICBIVE1haW5UZXh0LT5jb2xzICE9IExZY29s cyk7DQorIH0NCisgI2VuZGlmDQogIA0KICBQVUJMSUMgaW50IEhUaXNEb2N1 bWVudFNvdXJjZSBOT0FSR1MNCiAgew0KKioqIC4vc3JjL0hUTUwuYy5vcmln CVdlZCBNYXIgMTcgMjI6MTc6MTEgMTk5OQ0KLS0tIC4vc3JjL0hUTUwuYwlT dW4gQXByIDExIDIyOjM3OjQzIDE5OTkNCioqKioqKioqKioqKioqKg0KKioq IDU4LDYzICoqKioNCi0tLSA1OCw2NyAtLS0tDQogICNkZWZpbmUgcEhUZXh0 X2NoYW5nZVN0eWxlKFgsWSxaKSB7fQ0KICAjZW5kaWYNCiAgDQorICNpZmRl ZiBTT1VSQ0VfQ0FDSEUNCisgI2luY2x1ZGUgPEhUQWNjZXNzLmg+DQorICNl bmRpZg0KKyANCiAgI2luY2x1ZGUgPExZZXhpdC5oPg0KICAjaW5jbHVkZSA8 TFlMZWFrcy5oPg0KICANCioqKioqKioqKioqKioqKg0KKioqIDczLDc5ICoq KioNCi0tLSA3Nyw5MCAtLS0tDQogIA0KICBzdHJ1Y3QgX0hUU3RyZWFtIHsN CiAgICAgIENPTlNUIEhUU3RyZWFtQ2xhc3MgKglpc2E7DQorICNpZmRlZiBT T1VSQ0VfQ0FDSEUNCisgICAgIEZJTEUgKgkJCWZwOw0KKyAgICAgSFRDaHVu ayAqCQkJY2h1bms7DQorICAgICBDT05TVCBIVFN0cmVhbUNsYXNzICoJYWN0 aW9uczsNCisgICAgIEhUU3RyZWFtICoJCQl0YXJnZXQ7DQorICNlbHNlDQog ICAgICAvKiAuLi4uICovDQorICNlbmRpZg0KICB9Ow0KICANCiAgUFJJVkFU RSBIVFN0eWxlU2hlZXQgKiBzdHlsZVNoZWV0ID0gTlVMTDsJLyogQXBwbGlj YXRpb24td2lkZSAqLw0KKioqKioqKioqKioqKioqDQoqKiogNzMwMCw3MzA1 ICoqKioNCi0tLSA3MzExLDc0NTYgLS0tLQ0KICAgICAgcmV0dXJuIChIVFN0 cnVjdHVyZWQqKSBtZTsNCiAgfQ0KICANCisgI2lmZGVmIFNPVVJDRV9DQUNI RQ0KKyAvKg0KKyAgKiBQYXNzLXRocnUgY2FjaGUgSFRTdHJlYW0NCisgICov DQorIA0KKyBQUklWQVRFIHZvaWQgQ2FjaGVUaHJ1X2ZyZWUgQVJHUzEoDQor IAlIVFN0cmVhbSAqLAltZSkNCisgew0KKyAgICAgaWYgKG1lLT5mcCkNCisg CUxZQ2xvc2VUZW1wRlAobWUtPmZwKTsNCisgICAgICgqbWUtPmFjdGlvbnMt Pl9mcmVlKShtZS0+dGFyZ2V0KTsNCisgICAgIEZSRUUobWUpOw0KKyB9DQor IA0KKyBQUklWQVRFIHZvaWQgQ2FjaGVUaHJ1X2Fib3J0IEFSR1MyKA0KKyAJ SFRTdHJlYW0gKiwJbWUsDQorIAlIVEVycm9yLAllKQ0KKyB7DQorICAgICBp ZiAobWUtPmZwKQ0KKyAJTFlDbG9zZVRlbXBGUChtZS0+ZnApOw0KKyAgICAg KCptZS0+YWN0aW9ucy0+X2Fib3J0KShtZS0+dGFyZ2V0LCBlKTsNCisgICAg IEZSRUUobWUpOw0KKyB9DQorIA0KKyBQUklWQVRFIHZvaWQgQ2FjaGVUaHJ1 X3B1dF9jaGFyYWN0ZXIgQVJHUzIoDQorIAlIVFN0cmVhbSAqLAltZSwNCisg CWNoYXIsCQljX2luKQ0KKyB7DQorICAgICBpZiAobWUtPmZwKQ0KKyAJZnB1 dGMoY19pbiwgbWUtPmZwKTsNCisgICAgIGVsc2UNCisgCUhUQ2h1bmtQdXRj KG1lLT5jaHVuaywgY19pbik7DQorICAgICAoKm1lLT5hY3Rpb25zLT5wdXRf Y2hhcmFjdGVyKShtZS0+dGFyZ2V0LCBjX2luKTsNCisgfQ0KKyANCisgUFJJ VkFURSB2b2lkIENhY2hlVGhydV9wdXRfc3RyaW5nIEFSR1MyKA0KKyAJSFRT dHJlYW0gKiwJbWUsDQorIAlDT05TVCBjaGFyICosCXN0cikNCisgew0KKyAg ICAgaWYgKG1lLT5mcCkNCisgCWZwdXRzKHN0ciwgbWUtPmZwKTsNCisgICAg IGVsc2UNCisgCUhUQ2h1bmtQdXRzKG1lLT5jaHVuaywgc3RyKTsNCisgICAg ICgqbWUtPmFjdGlvbnMtPnB1dF9zdHJpbmcpKG1lLT50YXJnZXQsIHN0cik7 DQorIH0NCisgDQorIFBSSVZBVEUgdm9pZCBDYWNoZVRocnVfd3JpdGUgQVJH UzMoDQorIAlIVFN0cmVhbSAqLAltZSwNCisgCUNPTlNUIGNoYXIgKiwJc3Ry LA0KKyAJaW50LAkJbCkNCisgew0KKyAgICAgaWYgKG1lLT5mcCkNCisgCWZ3 cml0ZShzdHIsIDEsIGwsIG1lLT5mcCk7DQorICAgICBlbHNlDQorIAlIVENo dW5rUHV0YihtZS0+Y2h1bmssIHN0ciwgbCk7DQorICAgICAoKm1lLT5hY3Rp b25zLT5wdXRfYmxvY2spKG1lLT50YXJnZXQsIHN0ciwgbCk7DQorIH0NCisg DQorIFBSSVZBVEUgQ09OU1QgSFRTdHJlYW1DbGFzcyBQYXNzVGhydUNhY2hl ID0NCisgew0KKyAgICAgIlBhc3NUaHJ1Q2FjaGUiLA0KKyAgICAgQ2FjaGVU aHJ1X2ZyZWUsDQorICAgICBDYWNoZVRocnVfYWJvcnQsDQorICAgICBDYWNo ZVRocnVfcHV0X2NoYXJhY3RlciwNCisgICAgIENhY2hlVGhydV9wdXRfc3Ry aW5nLA0KKyAgICAgQ2FjaGVUaHJ1X3dyaXRlDQorIH07DQorIA0KKyBQUklW QVRFIEhUU3RyZWFtKiBDYWNoZVRocnVfbmV3IEFSR1MyKA0KKyAJSFRQYXJl bnRBbmNob3IgKiwJYW5jaG9yLA0KKyAJSFRTdHJlYW0gKiwJCXRhcmdldCkN Cisgew0KKyAgICAgY2hhciBmaWxlbmFtZVtMWV9NQVhQQVRIXTsNCisgICAg IEhUU3RyZWFtICpzdHJlYW0gPSBOVUxMOw0KKyAgICAgSFRQcm90b2NvbCAq cCA9IChIVFByb3RvY29sICopYW5jaG9yLT5wcm90b2NvbDsNCisgICAgIA0K KyAgICAgLyoNCisgICAgICAqIE5lYXRseSBhbmQgdHJhbnNwYXJlbnRseSB2 YW5pc2ggaWYgc291cmNlIGNhY2hpbmcgaXMgZGlzYWJsZWQuDQorICAgICAg Ki8NCisgICAgIGlmIChMWUNhY2hlU291cmNlID09IFNPVVJDRV9DQUNIRV9O T05FKQ0KKyAJcmV0dXJuIHRhcmdldDsNCisgDQorICAgICBpZiAoc3RyY21w KHAtPm5hbWUsICJodHRwIikgIT0gMCkgew0KKyAJQ1RSQUNFKHRmcCwgIlBy b3RvY29sIGlzIFwiJXNcIjsgbm90IGNhY2hpbmdcbiIsIHAtPm5hbWUpOw0K KyAJcmV0dXJuIHRhcmdldDsNCisgICAgIH0NCisgDQorICAgICBzdHJlYW0g PSAoSFRTdHJlYW0gKikgbWFsbG9jKHNpemVvZigqc3RyZWFtKSk7DQorICAg ICBpZiAoIXN0cmVhbSkNCisgCW91dG9mbWVtKF9fRklMRV9fLCAiQ2FjaGVU aHJ1X25ldyIpOw0KKyANCisgICAgIHN0cmVhbS0+aXNhID0gJlBhc3NUaHJ1 Q2FjaGU7DQorICAgICBzdHJlYW0tPmZwID0gTlVMTDsNCisgICAgIHN0cmVh bS0+Y2h1bmsgPSBOVUxMOw0KKyAgICAgc3RyZWFtLT50YXJnZXQgPSB0YXJn ZXQ7DQorICAgICBzdHJlYW0tPmFjdGlvbnMgPSB0YXJnZXQtPmlzYTsNCisg DQorICAgICBpZiAoTFlDYWNoZVNvdXJjZSA9PSBTT1VSQ0VfQ0FDSEVfRklM RSkgew0KKyAJaWYgKHNvdXJjZV9jYWNoZV9maWxlbmFtZSkgew0KKyAJICAg IENUUkFDRSh0ZnAsICJSZXVzaW5nIHNvdXJjZSBjYWNoZSBmaWxlICVzXG4i LA0KKyAJCSAgIHNvdXJjZV9jYWNoZV9maWxlbmFtZSk7DQorIAkgICAgRlJF RShzdHJlYW0pOw0KKyAJICAgIHJldHVybiB0YXJnZXQ7DQorIAl9DQorIA0K KyAJaWYgKCEoc3RyZWFtLT5mcCA9IExZT3BlblRlbXAoZmlsZW5hbWUsIEhU TUxfU1VGRklYLCAidyIpKSkgew0KKyAJICAgIENUUkFDRSh0ZnAsICJDYW5u b3QgZ2V0IHNvdXJjZSBjYWNoZSBmaWxlIGZvciBVUkwgJXNcbiIsDQorIAkJ ICAgSFRBbmNob3JfYWRkcmVzcygoSFRBbmNob3IgKilhbmNob3IpKTsNCisg CSAgICBGUkVFKHN0cmVhbSk7DQorIAkgICAgcmV0dXJuIHRhcmdldDsNCisg CX0NCisgDQorIAkvKg0KKyAJICogWWVzLCB0aGlzIGlzIGEgR3Jvc3MgQW5k IERpc2d1c3RpbmcgSGFjayhUTSksIEkga25vdy4uLg0KKyAJICovDQorIAlT dHJBbGxvY0NvcHkoc291cmNlX2NhY2hlX2ZpbGVuYW1lLCBmaWxlbmFtZSk7 DQorIA0KKyAJQ1RSQUNFKHRmcCwgIkNhY2hpbmcgc291cmNlIGZvciBVUkwg JXMgaW4gZmlsZSAlc1xuIiwNCisgCSAgICAgICBIVEFuY2hvcl9hZGRyZXNz KChIVEFuY2hvciAqKWFuY2hvciksIGZpbGVuYW1lKTsNCisgICAgIH0NCisg DQorICAgICBpZiAoTFlDYWNoZVNvdXJjZSA9PSBTT1VSQ0VfQ0FDSEVfTUVN T1JZKSB7DQorIAlpZiAoc291cmNlX2NhY2hlX2NodW5rKSB7DQorIAkgICAg Q1RSQUNFKHRmcCwgIlJldXNpbmcgc291cmNlIG1lbW9yeSBjYWNoZSAlcFxu IiwNCisgCQkgICAodm9pZCAqKXNvdXJjZV9jYWNoZV9jaHVuayk7DQorIAkg ICAgRlJFRShzdHJlYW0pOw0KKyAJICAgIHJldHVybiB0YXJnZXQ7DQorIAl9 DQorIA0KKyAJLyogSSB0aGluayB0aGlzIGlzIHJpZ2h0Li4uICovDQorIAlz b3VyY2VfY2FjaGVfY2h1bmsgPSBzdHJlYW0tPmNodW5rID0gSFRDaHVua0Ny ZWF0ZSgxMjgpOw0KKyAJQ1RSQUNFKHRmcCwgIkNhY2hpbmcgc291cmNlIGZv ciBVUkwgJXMgaW4gbWVtb3J5IGNhY2hlICVwXG4iLA0KKyAJICAgICAgIEhU QW5jaG9yX2FkZHJlc3MoKEhUQW5jaG9yICopYW5jaG9yKSwgKHZvaWQgKilz dHJlYW0tPmNodW5rKTsNCisgCSAgICAgICANCisgICAgIH0NCisgDQorICAg ICByZXR1cm4gc3RyZWFtOw0KKyB9DQorICNlbmRpZg0KKyANCiAgLyoJSFRD b252ZXJ0ZXIgZm9yIEhUTUwgdG8gcGxhaW4gdGV4dA0KICAqKgktLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICoqDQoqKioqKioqKioq KioqKioNCioqKiA3MzEzLDczMTkgKioqKg0KLS0tIDc0NjQsNzQ3NiAtLS0t DQogIAlIVFBhcmVudEFuY2hvciAqLAlhbmNob3IsDQogIAlIVFN0cmVhbSAq LAkJc2luaykNCiAgew0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorICAgICBy ZXR1cm4gQ2FjaGVUaHJ1X25ldyhhbmNob3IsDQorIAkJCSBTR01MX25ldygm SFRNTF9kdGQsIGFuY2hvciwNCisgCQkJCSAgSFRNTF9uZXcoYW5jaG9yLCBw cmVzLT5yZXBfb3V0LCBzaW5rKSkpOw0KKyAjZWxzZQ0KICAgICAgcmV0dXJu IFNHTUxfbmV3KCZIVE1MX2R0ZCwgYW5jaG9yLCBIVE1MX25ldyhhbmNob3Is IHByZXMtPnJlcF9vdXQsIHNpbmspKTsNCisgI2VuZGlmDQogIH0NCiAgDQog IC8qCUhUQ29udmVydGVyIGZvciBIVE1MIHNvdXJjZSB0byBwbGFpbiB0ZXh0 DQoqKioqKioqKioqKioqKioNCioqKiA3MzcyLDczNzggKioqKg0KLS0tIDc1 MjksNzU0MSAtLS0tDQogICAgICB9DQogICAgICBpZiAoIWludGVybWVkaWF0 ZSkNCiAgCXJldHVybiBOVUxMOw0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQor ICAgICByZXR1cm4gQ2FjaGVUaHJ1X25ldyhhbmNob3IsDQorIAkJCSBTR01M X25ldygmSFRNTF9kdGQsIGFuY2hvciwNCisgCQkJCSAgSFRNTEdlbmVyYXRv cihpbnRlcm1lZGlhdGUpKSk7DQorICNlbHNlDQogICAgICByZXR1cm4gU0dN TF9uZXcoJkhUTUxfZHRkLCBhbmNob3IsIEhUTUxHZW5lcmF0b3IoaW50ZXJt ZWRpYXRlKSk7DQorICNlbmRpZg0KICB9DQogIA0KICAvKglIVENvbnZlcnRl ciBmb3IgSFRNTCB0byBDIGNvZGUNCioqKioqKioqKioqKioqKg0KKioqIDcz OTcsNzQwMyAqKioqDQotLS0gNzU2MCw3NTcxIC0tLS0NCiAgICAgIGh0bWwt PmNvbW1lbnRfc3RhcnQgPSAiLyogIjsNCiAgICAgIGh0bWwtPmNvbW1lbnRf ZW5kID0gIiAqL1xuIjsJLyogTXVzdCBzdGFydCBpbiBjb2wgMSBmb3IgY3Bw ICovDQogIC8qICAgIEhUTUxfcHV0X3N0cmluZyhodG1sLGh0bWwtPmNvbW1l bnRfc3RhcnQpOyAqLw0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQorICAgICBy ZXR1cm4gQ2FjaGVUaHJ1X25ldyhhbmNob3IsDQorIAkJCSBTR01MX25ldygm SFRNTF9kdGQsIGFuY2hvciwgaHRtbCkpOw0KKyAjZWxzZQ0KICAgICAgcmV0 dXJuIFNHTUxfbmV3KCZIVE1MX2R0ZCwgYW5jaG9yLCBodG1sKTsNCisgI2Vu ZGlmDQogIH0NCiAgDQogIC8qCVByZXNlbnRlciBmb3IgSFRNTA0KKioqKioq KioqKioqKioqDQoqKiogNzQxNCw3NDIwICoqKioNCi0tLSA3NTgyLDc1OTQg LS0tLQ0KICAJSFRQYXJlbnRBbmNob3IgKiwJYW5jaG9yLA0KICAJSFRTdHJl YW0gKiwJCXNpbmsgR0NDX1VOVVNFRCkNCiAgew0KKyAjaWZkZWYgU09VUkNF X0NBQ0hFDQorICAgICByZXR1cm4gQ2FjaGVUaHJ1X25ldyhhbmNob3IsDQor IAkJCSBTR01MX25ldygmSFRNTF9kdGQsIGFuY2hvciwNCisgCQkJCSAgSFRN TF9uZXcoYW5jaG9yLCBXV1dfUFJFU0VOVCwgTlVMTCkpKTsNCisgI2Vsc2UN CiAgICAgIHJldHVybiBTR01MX25ldygmSFRNTF9kdGQsIGFuY2hvciwgSFRN TF9uZXcoYW5jaG9yLCBXV1dfUFJFU0VOVCwgTlVMTCkpOw0KKyAjZW5kaWYN CiAgfQ0KICAjZW5kaWYgLyogIUdVSSAqLw0KICANCioqKiAuL3NyYy9Hcmlk VGV4dC5oLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5DQotLS0gLi9z cmMvR3JpZFRleHQuaAlTYXQgQXByIDEwIDE5OjI0OjUwIDE5OTkNCioqKioq KioqKioqKioqKg0KKioqIDE2NiwxNzEgKioqKg0KLS0tIDE2NiwxNzUgLS0t LQ0KICAJY2hhciAqCQl0YXJnZXQpKTsNCiAgZXh0ZXJuIGludCBIVGlzRG9j dW1lbnRTb3VyY2UgTk9QQVJBTVM7DQogIGV4dGVybiB2b2lkIEhUdW5jYWNo ZV9jdXJyZW50X2RvY3VtZW50IE5PUEFSQU1TOw0KKyAjaWZkZWYgU09VUkNF X0NBQ0hFDQorIGV4dGVybiBCT09MRUFOIEhUcmVwYXJzZV9kb2N1bWVudCBO T1BBUkFNUzsNCisgZXh0ZXJuIEJPT0xFQU4gSFRkb2N1bWVudF9zZXR0aW5n c19jaGFuZ2VkIE5PUEFSQU1TOw0KKyAjZW5kaWYNCiAgZXh0ZXJuIGludCBI VGV4dF9nZXRUb3BPZlNjcmVlbiBOT1BBUkFNUzsNCiAgZXh0ZXJuIGludCBI VGV4dF9nZXRMaW5lcyBQQVJBTVMoKEhUZXh0ICogdGV4dCkpOw0KICBleHRl cm4gaW50IEhUZXh0X2dldE51bU9mTGluZXMgTk9QQVJBTVM7DQoqKiogLi9z cmMvTFlNYWluTG9vcC5jLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5 DQotLS0gLi9zcmMvTFlNYWluTG9vcC5jCVN1biBBcHIgMTEgMjA6NTg6NDMg MTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogMTIzNywxMjQyICoqKioNCi0t LSAxMjM3LDEyNjIgLS0tLQ0KICAJICAgIH0NCiAgCX0NCiAgDQorICNpZmRl ZiBTT1VSQ0VfQ0FDSEUNCisgCS8qDQorIAkgKiBJZiB0aGUgcGFyc2Ugc2V0 dGluZ3MgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoaXMgSFRleHQgd2FzDQorIAkg KiBnZW5lcmF0ZWQsIHdlIG5lZWQgdG8gcmVwYXJzZSBhbmQgcmVkcmF3IGl0 Lg0KKyAJICovDQorIAlpZiAoSFRkb2N1bWVudF9zZXR0aW5nc19jaGFuZ2Vk KCkpIHsNCisgCSAgICBIVFVzZXJNc2coZ2V0dGV4dCgiUmVwYXJzaW5nIGRv Y3VtZW50IHVuZGVyIGN1cnJlbnQgc2V0dGluZ3MuLi4iKSk7DQorIAkgICAg aWYgKEhUcmVwYXJzZV9kb2N1bWVudCgpKQ0KKyAJCXJlZnJlc2hfc2NyZWVu ID0gVFJVRTsNCisgCSAgICBlbHNlIHsNCisgCQkvKg0KKyAJCSAqIFVyay4g IEkgaGF2ZSBubyBpZGVhIGhvdyB0byByZWNvdmVyIGZyb20gYSBmYWlsdXJl IGhlcmUuDQorIAkJICogQXQgYSBndWVzcywgSSdsbCB0cnkgcmVsb2FkaW5n Lg0KKyAJCSAqLw0KKyAJCWNtZCA9IExZS19SRUxPQUQ7DQorIAkJZ290byBu ZXdfY21kOw0KKyAJICAgIH0NCisgCX0NCisgI2VuZGlmDQorIA0KICAJLyoN CiAgCSAqICBJZiB0aGUgY3VyZG9jLmxpbmUgaXMgZGlmZmVyZW50IHRoYW4g TmV3bGluZSB0aGVuIHRoZXJlIG11c3QNCiAgCSAqICBoYXZlIGJlZW4gYSBj aGFuZ2Ugc2luY2UgbGFzdCB1cGRhdGUuICBSdW4gSFRleHRfcGFnZURpc3Bs YXkoKQ0KKioqKioqKioqKioqKioqDQoqKiogMjA0OSwyMDU0ICoqKioNCi0t LSAyMDY5LDIwODAgLS0tLQ0KICAJCUxZVUNQdXNoQXNzdW1lZChIVE1haW5B bmNob3IpOw0KICAJCUhUT3V0cHV0Rm9ybWF0ID0gV1dXX1NPVVJDRTsNCiAg CSAgICB9DQorICNpZmRlZiBTT1VSQ0VfQ0FDSEUNCisgCSAgICBpZiAoSFRy ZXBhcnNlX2RvY3VtZW50KCkpIHsNCisgCQlyZWZyZXNoX3NjcmVlbiA9IFRS VUU7DQorIAkJYnJlYWs7DQorIAkgICAgfQ0KKyAjZW5kaWYNCiAgCSAgICBM WWZvcmNlX25vX2NhY2hlID0gVFJVRTsNCiAgCSAgICBGUkVFKGN1cmRvYy5h ZGRyZXNzKTsgLyogc28gaXQgZG9lc24ndCBnZXQgcHVzaGVkICovDQogIAkg ICAgYnJlYWs7DQoqKioqKioqKioqKioqKioNCioqKiAyMTI1LDIxMzUgKioq Kg0KLS0tIDIxNTEsMjE2MyAtLS0tDQogIAkJCQkgICAwLCAwKSA9PSBGQUxT RSkgew0KICAJCUhUSW5mb01zZyhXSUxMX05PVF9SRUxPQURfRE9DKTsNCiAg CSAgICB9IGVsc2Ugew0KKyAjaWZuZGVmIFNPVVJDRV9DQUNIRQ0KICAJCUhU dW5jYWNoZV9jdXJyZW50X2RvY3VtZW50KCk7DQogIAkJU3RyQWxsb2NDb3B5 KG5ld2RvYy5hZGRyZXNzLCBjdXJkb2MuYWRkcmVzcyk7DQogIAkJRlJFRShj dXJkb2MuYWRkcmVzcyk7DQogIAkJbmV3ZG9jLmxpbmUgPSBjdXJkb2MubGlu ZTsNCiAgCQluZXdkb2MubGluayA9IGN1cmRvYy5saW5rOw0KKyAjZW5kaWYN CiAgCSAgICB9DQogIAkgICAgaWYgKGhpc3RvcmljYWxfY29tbWVudHMpDQog IAkJaGlzdG9yaWNhbF9jb21tZW50cyA9IEZBTFNFOw0KKioqKioqKioqKioq KioqDQoqKiogMjE0MiwyMTQ3ICoqKioNCi0tLSAyMTcwLDIxODYgLS0tLQ0K ICAJCUhUQWxlcnQoaGlzdG9yaWNhbF9jb21tZW50cyA/DQogIAkJCUhJU1RP UklDQUxfT05fVkFMSURfT0ZGIDogSElTVE9SSUNBTF9PRkZfVkFMSURfT04p Ow0KICAJICAgIH0NCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJICAgIGlm IChIVHJlcGFyc2VfZG9jdW1lbnQoKSkgew0KKyAJCXJlZnJlc2hfc2NyZWVu ID0gVFJVRTsNCisgCQlicmVhazsNCisgCSAgICB9DQorIAkgICAgSFR1bmNh Y2hlX2N1cnJlbnRfZG9jdW1lbnQoKTsNCisgCSAgICBTdHJBbGxvY0NvcHko bmV3ZG9jLmFkZHJlc3MsIGN1cmRvYy5hZGRyZXNzKTsNCisgCSAgICBGUkVF KGN1cmRvYy5hZGRyZXNzKTsNCisgCSAgICBuZXdkb2MubGluZSA9IGN1cmRv Yy5saW5lOw0KKyAJICAgIG5ld2RvYy5saW5rID0gY3VyZG9jLmxpbms7DQor ICNlbmRpZg0KICAJICAgIGJyZWFrOw0KICANCiAgCWNhc2UgTFlLX01JTklN QUw6CS8qIHRvZ2dsZSAnbWluaW1hbCcgY29tbWVudHMgcGFyc2luZyAqLw0K KioqKioqKioqKioqKioqDQoqKiogMjE1NywyMTY3ICoqKioNCi0tLSAyMTk2 LDIyMDggLS0tLQ0KICAJCQkJICAgICAgIDAsIDApID09IEZBTFNFKSB7DQog IAkJICAgIEhUSW5mb01zZyhXSUxMX05PVF9SRUxPQURfRE9DKTsNCiAgCQl9 IGVsc2Ugew0KKyAjaWZuZGVmIFNPVVJDRV9DQUNIRQ0KICAJCSAgICBIVHVu Y2FjaGVfY3VycmVudF9kb2N1bWVudCgpOw0KICAJCSAgICBTdHJBbGxvY0Nv cHkobmV3ZG9jLmFkZHJlc3MsIGN1cmRvYy5hZGRyZXNzKTsNCiAgCQkgICAg RlJFRShjdXJkb2MuYWRkcmVzcyk7DQogIAkJICAgIG5ld2RvYy5saW5lID0g Y3VyZG9jLmxpbmU7DQogIAkJICAgIG5ld2RvYy5saW5rID0gY3VyZG9jLmxp bms7DQorICNlbmRpZg0KICAJCX0NCiAgCSAgICB9DQogIAkgICAgaWYgKG1p bmltYWxfY29tbWVudHMpDQoqKioqKioqKioqKioqKioNCioqKiAyMTc1LDIx ODAgKioqKg0KLS0tIDIyMTYsMjIzMiAtLS0tDQogIAkJSFRBbGVydChtaW5p bWFsX2NvbW1lbnRzID8NCiAgCQkJTUlOSU1BTF9PTl9CVVRfSElTVE9SSUNB TCA6IE1JTklNQUxfT0ZGX0hJU1RPUklDQUxfT04pOw0KICAJICAgIH0NCisg I2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJICAgIGlmIChIVHJlcGFyc2VfZG9j dW1lbnQoKSkgew0KKyAJCXJlZnJlc2hfc2NyZWVuID0gVFJVRTsNCisgCQli cmVhazsNCisgCSAgICB9DQorIAkgICAgSFR1bmNhY2hlX2N1cnJlbnRfZG9j dW1lbnQoKTsNCisgCSAgICBTdHJBbGxvY0NvcHkobmV3ZG9jLmFkZHJlc3Ms IGN1cmRvYy5hZGRyZXNzKTsNCisgCSAgICBGUkVFKGN1cmRvYy5hZGRyZXNz KTsNCisgCSAgICBuZXdkb2MubGluZSA9IGN1cmRvYy5saW5lOw0KKyAJICAg IG5ld2RvYy5saW5rID0gY3VyZG9jLmxpbms7DQorICNlbmRpZg0KICAJICAg IGJyZWFrOw0KICANCiAgCWNhc2UgTFlLX1NPRlRfRFFVT1RFUzoNCioqKioq KioqKioqKioqKg0KKioqIDIxODksMjE5OSAqKioqDQotLS0gMjI0MSwyMjUz IC0tLS0NCiAgCQkJCSAgIDEsIDEpID09IEZBTFNFKSB7DQogIAkJSFRJbmZv TXNnKFdJTExfTk9UX1JFTE9BRF9ET0MpOw0KICAJICAgIH0gZWxzZSB7DQor ICNpZm5kZWYgU09VUkNFX0NBQ0hFDQogIAkJSFR1bmNhY2hlX2N1cnJlbnRf ZG9jdW1lbnQoKTsNCiAgCQlTdHJBbGxvY0NvcHkobmV3ZG9jLmFkZHJlc3Ms IGN1cmRvYy5hZGRyZXNzKTsNCiAgCQlGUkVFKGN1cmRvYy5hZGRyZXNzKTsN CiAgCQluZXdkb2MubGluZSA9IGN1cmRvYy5saW5lOw0KICAJCW5ld2RvYy5s aW5rID0gY3VyZG9jLmxpbms7DQorICNlbmRpZg0KICAJICAgIH0NCiAgCSAg ICBpZiAoc29mdF9kcXVvdGVzKQ0KICAJCXNvZnRfZHF1b3RlcyA9IEZBTFNF Ow0KKioqKioqKioqKioqKioqDQoqKiogMjIwMSwyMjA2ICoqKioNCi0tLSAy MjU1LDIyNzEgLS0tLQ0KICAJCXNvZnRfZHF1b3RlcyA9IFRSVUU7DQogIAkg ICAgSFRVc2VyTXNnKHNvZnRfZHF1b3RlcyA/DQogIAkJICAgICAgU09GVF9E T1VCTEVfUVVPVEVfT04gOiBTT0ZUX0RPVUJMRV9RVU9URV9PRkYpOw0KKyAj aWZkZWYgU09VUkNFX0NBQ0hFDQorIAkgICAgaWYgKEhUcmVwYXJzZV9kb2N1 bWVudCgpKSB7DQorIAkJcmVmcmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJy ZWFrOw0KKyAJICAgIH0NCisgCSAgICBIVHVuY2FjaGVfY3VycmVudF9kb2N1 bWVudCgpOw0KKyAJICAgIFN0ckFsbG9jQ29weShuZXdkb2MuYWRkcmVzcywg Y3VyZG9jLmFkZHJlc3MpOw0KKyAJICAgIEZSRUUoY3VyZG9jLmFkZHJlc3Mp Ow0KKyAJICAgIG5ld2RvYy5saW5lID0gY3VyZG9jLmxpbmU7DQorIAkgICAg bmV3ZG9jLmxpbmsgPSBjdXJkb2MubGluazsNCisgI2VuZGlmDQogIAkgICAg YnJlYWs7DQogIA0KICAJY2FzZSBMWUtfU1dJVENIX0RURDoNCioqKioqKioq KioqKioqKg0KKioqIDIyMjMsMjIzMSAqKioqDQotLS0gMjI4OCwyMjk4IC0t LS0NCiAgCQlpZiAoSFRpc0RvY3VtZW50U291cmNlKCkgJiYgTFlQcmVwYXJz ZWRTb3VyY2UpIHsNCiAgCQkJSFRPdXRwdXRGb3JtYXQgPSBXV1dfU09VUkNF Ow0KICAJCX0NCisgI2lmbmRlZiBTT1VSQ0VfQ0FDSEUNCiAgCQlIVHVuY2Fj aGVfY3VycmVudF9kb2N1bWVudCgpOw0KICAJCVN0ckFsbG9jQ29weShuZXdk b2MuYWRkcmVzcywgY3VyZG9jLmFkZHJlc3MpOw0KICAJCUZSRUUoY3VyZG9j LmFkZHJlc3MpOw0KKyAjZW5kaWYNCiAgCSAgICB9DQogICNpZmRlZiBOT19B U1NVTUVfU0FNRV9ET0MNCiAgCSAgICBuZXdkb2MubGluZSA9IDE7DQoqKioq KioqKioqKioqKioNCioqKiAyMjM3LDIyNDIgKioqKg0KLS0tIDIzMDQsMjMx OCAtLS0tDQogIAkgICAgT2xkX0RURCA9ICFPbGRfRFREOw0KICAJICAgIEhU U3dpdGNoRFREKCFPbGRfRFREKTsNCiAgCSAgICBIVFVzZXJNc2coT2xkX0RU RCA/IFVTSU5HX0RURF8wIDogVVNJTkdfRFREXzEpOw0KKyAjaWZkZWYgU09V UkNFX0NBQ0hFDQorIAkgICAgaWYgKEhUcmVwYXJzZV9kb2N1bWVudCgpKSB7 DQorIAkJcmVmcmVzaF9zY3JlZW4gPSBUUlVFOw0KKyAJCWJyZWFrOw0KKyAJ ICAgIH0NCisgCSAgICBIVHVuY2FjaGVfY3VycmVudF9kb2N1bWVudCgpOw0K KyAJICAgIFN0ckFsbG9jQ29weShuZXdkb2MuYWRkcmVzcywgY3VyZG9jLmFk ZHJlc3MpOw0KKyAJICAgIEZSRUUoY3VyZG9jLmFkZHJlc3MpOw0KKyAjZW5k aWYNCiAgCSAgICBicmVhazsNCiAgDQogICNpZmRlZiBOT1RfRE9ORV9ZRVQN CioqKioqKioqKioqKioqKg0KKioqIDU0NDcsNTQ1MiAqKioqDQotLS0gNTUy Myw1NTM0IC0tLS0NCiAgDQogIAkgICAgSFRVc2VyTXNnKGNsaWNrYWJsZV9p bWFnZXMgPw0KICAJCSAgICAgQ0xJQ0tBQkxFX0lNQUdFU19PTiA6IENMSUNL QUJMRV9JTUFHRVNfT0ZGKTsNCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAJ ICAgIGlmIChIVHJlcGFyc2VfZG9jdW1lbnQoKSkgew0KKyAJCXJlZnJlc2hf c2NyZWVuID0gVFJVRTsNCisgCQlicmVhazsNCisgCSAgICB9DQorICNlbmRp Zg0KICAJICAgIGNtZCA9IExZS19SRUxPQUQ7DQogIAkgICAgZ290byBuZXdf Y21kOw0KICANCioqKioqKioqKioqKioqKg0KKioqIDU0NTgsNTQ2MyAqKioq DQotLS0gNTU0MCw1NTUxIC0tLS0NCiAgDQogIAkgICAgSFRVc2VyTXNnKHBz ZXVkb19pbmxpbmVfYWx0cyA/DQogIAkJICAgICAgUFNFVURPX0lOTElORV9B TFRTX09OIDogUFNFVURPX0lOTElORV9BTFRTX09GRik7DQorICNpZmRlZiBT T1VSQ0VfQ0FDSEUNCisgCSAgICBpZiAoSFRyZXBhcnNlX2RvY3VtZW50KCkp IHsNCisgCQlyZWZyZXNoX3NjcmVlbiA9IFRSVUU7DQorIAkJYnJlYWs7DQor IAkgICAgfQ0KKyAjZW5kaWYNCiAgCSAgICBjbWQgPSBMWUtfUkVMT0FEOw0K ICAJICAgIGdvdG8gbmV3X2NtZDsNCiAgDQoqKioqKioqKioqKioqKioNCioq KiA1NDcwLDU0NzUgKioqKg0KLS0tIDU1NTgsNTU2OSAtLS0tDQogIAkJSFRV c2VyTXNnKExZUmF3TW9kZSA/IFJBV01PREVfT0ZGIDogUkFXTU9ERV9PTik7 DQogIAkJSFRNTFNldENoYXJhY3RlckhhbmRsaW5nKGN1cnJlbnRfY2hhcl9z ZXQpOw0KICAJCUxZUmF3TW9kZV9mbGFnID0gTFlSYXdNb2RlOw0KKyAjaWZk ZWYgU09VUkNFX0NBQ0hFDQorIAkJaWYgKEhUcmVwYXJzZV9kb2N1bWVudCgp KSB7DQorIAkJICAgIHJlZnJlc2hfc2NyZWVuID0gVFJVRTsNCisgCQkgICAg YnJlYWs7DQorIAkJfQ0KKyAjZW5kaWYNCiAgCQljbWQgPSBMWUtfUkVMT0FE Ow0KICAJCWdvdG8gbmV3X2NtZDsNCiAgCSAgICB9DQoqKiogLi9zcmMvTFlS ZWFkQ0ZHLmMub3JpZwlUdWUgTWFyIDMwIDEyOjEwOjM3IDE5OTkNCi0tLSAu L3NyYy9MWVJlYWRDRkcuYwlTdW4gQXByIDExIDE5OjQ0OjQxIDE5OTkNCioq KioqKioqKioqKioqKg0KKioqIDc2Myw3NjggKioqKg0KLS0tIDc2Myw3ODMg LS0tLQ0KICAgICAgcmV0dXJuIDA7DQogIH0NCiAgDQorICNpZmRlZiBTT1VS Q0VfQ0FDSEUNCisgc3RhdGljIGludCBzb3VyY2VfY2FjaGVfZnVuIEFSR1Mx KA0KKyAJY2hhciAqLAkJdmFsdWUpDQorIHsNCisgICAgIGlmICghc3RybmNh c2Vjb21wKHZhbHVlLCAiRklMRSIsIDQpKQ0KKyAJTFlDYWNoZVNvdXJjZSA9 IFNPVVJDRV9DQUNIRV9GSUxFOw0KKyAgICAgZWxzZSBpZiAoIXN0cm5jYXNl Y29tcCh2YWx1ZSwgIk1FTSIsIDMpKQ0KKyAJTFlDYWNoZVNvdXJjZSA9IFNP VVJDRV9DQUNIRV9NRU1PUlk7DQorICAgICBlbHNlIGlmICghc3RybmNhc2Vj b21wKHZhbHVlLCAiTk9ORSIsIDQpKQ0KKyAJTFlDYWNoZVNvdXJjZSA9IFNP VVJDRV9DQUNIRV9OT05FOw0KKyANCisgICAgIHJldHVybiAwOw0KKyB9DQor ICNlbmRpZg0KKyANCiAgc3RhdGljIGludCBzdWZmaXhfZnVuIEFSR1MxKA0K ICAJY2hhciAqLAkJdmFsdWUpDQogIHsNCioqKioqKioqKioqKioqKg0KKioq IDk5OSwxMDA0ICoqKioNCi0tLSAxMDE0LDEwMjIgLS0tLQ0KICAgICAgIFBB UlNFX0VOVigic25ld3Nwb3N0X3Byb3h5IiwgQ09ORl9FTlYsIDAgKSwNCiAg ICAgICBQQVJTRV9FTlYoInNuZXdzcmVwbHlfcHJveHkiLCBDT05GX0VOViwg MCApLA0KICAgICAgIFBBUlNFX1NFVCgic29mdF9kcXVvdGVzIiwgQ09ORl9C T09MLCBzb2Z0X2RxdW90ZXMpLA0KKyAjaWZkZWYgU09VUkNFX0NBQ0hFDQor ICAgICAgUEFSU0VfU0VUKCJzb3VyY2VfY2FjaGUiLCBDT05GX0ZVTiwgc291 cmNlX2NhY2hlX2Z1biksDQorICNlbmRpZg0KICAgICAgIFBBUlNFX1NUUigi c3RhcnRmaWxlIiwgQ09ORl9TVFIsIHN0YXJ0ZmlsZSksDQogICAgICAgUEFS U0VfU0VUKCJzdHJpcF9kb3Rkb3RfdXJscyIsIENPTkZfQk9PTCwgTFlTdHJp cERvdERvdFVSTHMpLA0KICAgICAgIFBBUlNFX1NFVCgic3Vic3RpdHV0ZV91 bmRlcnNjb3JlcyIsIENPTkZfQk9PTCwgdXNlX3VuZGVyc2NvcmUpLA0KKioq IC4vc3JjL0xZTWFpbi5jLm9yaWcJVHVlIE1hciAzMCAxMjoxMDozNyAxOTk5 DQotLS0gLi9zcmMvTFlNYWluLmMJU3VuIEFwciAxMSAyMDo1NDoxOSAxOTk5 DQoqKioqKioqKioqKioqKioNCioqKiAxNTU2LDE1NjEgKioqKg0KLS0tIDE1 NTYsMTU2OSAtLS0tDQogIAlub19tdWx0aWJvb2sgPSBUUlVFOw0KICAgICAg fQ0KICANCisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAgICAgLyoNCisgICAg ICAqIERpc2FibGUgc291cmNlIGNhY2hpbmcgaWYgbm90IGludGVyYWN0aXZl Lg0KKyAgICAgICovDQorICAgICBpZiAoZHVtcF9vdXRwdXRfaW1tZWRpYXRl bHkpDQorIAlMWUNhY2hlU291cmNlID0gU09VUkNFX0NBQ0hFX05PTkU7DQor ICNlbmRpZg0KKyANCiAgI2lmZGVmIFZNUw0KICAgICAgc2V0X3Ztc19rZXlz KCk7DQogICNlbmRpZiAvKiBWTVMgKi8NCioqKiAuL3NyYy9MWUdsb2JhbERl ZnMuaC5vcmlnCVRodSBNYXIgIDQgMDU6Mzk6NDUgMTk5OQ0KLS0tIC4vc3Jj L0xZR2xvYmFsRGVmcy5oCVN1biBBcHIgMTEgMjI6MjQ6NDEgMTk5OQ0KKioq KioqKioqKioqKioqDQoqKiogMjcsMzIgKioqKg0KLS0tIDI3LDM2IC0tLS0N CiAgI2RlZmluZSBWSVNJVEVEX0xJTktTX0hFTFAJImtleXN0cm9rZXMvdmlz aXRlZF9oZWxwLmh0bWwiDQogICNlbmRpZiAvKiBMWUhFTFBfSCAqLw0KICAN CisgI2lmZGVmIFNPVVJDRV9DQUNIRQ0KKyAjaW5jbHVkZSA8SFRDaHVuay5o Pg0KKyAjZW5kaWYNCisgDQogICNpZmRlZiBTT0NLUw0KICBleHRlcm4gQk9P TEVBTiBzb2Nrc19mbGFnOw0KICAjZW5kaWYgLyogU09DS1MgKi8NCioqKioq KioqKioqKioqKg0KKioqIDI0NSwyNTAgKioqKg0KLS0tIDI0OSwyNjIgLS0t LQ0KICBleHRlcm4gQk9PTEVBTiBoaXN0b3JpY2FsX2NvbW1lbnRzOw0KICBl eHRlcm4gQk9PTEVBTiBtaW5pbWFsX2NvbW1lbnRzOw0KICBleHRlcm4gQk9P TEVBTiBzb2Z0X2RxdW90ZXM7DQorICNpZmRlZiBTT1VSQ0VfQ0FDSEUNCisg ZXh0ZXJuIGNoYXIgKiBzb3VyY2VfY2FjaGVfZmlsZW5hbWU7DQorIGV4dGVy biBIVENodW5rICogc291cmNlX2NhY2hlX2NodW5rOw0KKyBleHRlcm4gaW50 IExZQ2FjaGVTb3VyY2U7DQorICNkZWZpbmUgU09VUkNFX0NBQ0hFX05PTkUJ MA0KKyAjZGVmaW5lIFNPVVJDRV9DQUNIRV9GSUxFCTENCisgI2RlZmluZSBT T1VSQ0VfQ0FDSEVfTUVNT1JZCTINCisgI2VuZGlmDQogIGV4dGVybiBCT09M RUFOIExZQ2FuY2VsRG93bmxvYWQ7DQogIGV4dGVybiBCT09MRUFOIExZUmVz dHJpY3RlZDsNCiAgZXh0ZXJuIEJPT0xFQU4gTFlWYWxpZGF0ZTsNCioqKiAu L2NvbmZpZ3VyZS5pbi5vcmlnCVR1ZSBNYXIgMzAgMTI6MTA6MzcgMTk5OQ0K LS0tIC4vY29uZmlndXJlLmluCVNhdCBBcHIgMTAgMDA6Mjc6MzMgMTk5OQ0K KioqKioqKioqKioqKioqDQoqKiogNTY3LDU3MiAqKioqDQotLS0gNTY3LDU3 OSAtLS0tDQogIEFDX01TR19SRVNVTFQoJHVzZV9hbHRfYmluZGluZ3MpDQog IHRlc3QgJHVzZV9hbHRfYmluZGluZ3MgIT0gbm8gJiYgQUNfREVGSU5FKEVY UF9BTFRfQklORElOR1MpDQogIA0KKyBBQ19NU0dfQ0hFQ0tJTkcoaWYgc291 cmNlIGNhY2hpbmcgc2hvdWxkIGJlIHVzZWQpDQorIENGX0FSR19FTkFCTEUo c291cmNlLWNhY2hlLA0KKyBbICAtLWVuYWJsZS1zb3VyY2UtY2FjaGUgICBj YWNoZSBIVE1MIHNvdXJjZSBmb3IgcGFyc2UgbW9kZSBjaGFuZ2VzXSwNCisg CVt1c2Vfc291cmNlX2NhY2hlPSRlbmFibGV2YWxdLA0KKyAJW3VzZV9zb3Vy Y2VfY2FjaGU9bm9dDQorIHRlc3QgJHVzZV9zb3VyY2VfY2FjaGUgIT0gbm8g JiYgQUNfREVGSU5FKFNPVVJDRV9DQUNIRSkNCisgDQogIEFDX01TR19DSEVD S0lORyhpZiBjb2xvci1zdHlsZSBjb2RlIHNob3VsZCBiZSB1c2VkKQ0KICBD Rl9BUkdfRU5BQkxFKGNvbG9yLXN0eWxlLA0KICBbICAtLWVuYWJsZS1jb2xv ci1zdHlsZSAgICB1c2Ugb3B0aW9uYWwvZXhwZXJpbWVudGFsIGNvbG9yIHN0 eWxlXSwNCioqKiAuL2NvbmZpZy5oaW4ub3JpZwlUdWUgTWFyIDMwIDEyOjEw OjM3IDE5OTkNCi0tLSAuL2NvbmZpZy5oaW4JU2F0IEFwciAxMCAwMDoyNzoz MyAxOTk5DQoqKioqKioqKioqKioqKioNCioqKiAyOCwzMyAqKioqDQotLS0g MjgsMzQgLS0tLQ0KICAjdW5kZWYgRVhFQ19TQ1JJUFRTCQkvKiBDRl9BUkdf RU5BQkxFKGV4ZWMtc2NyaXB0cykgKi8NCiAgI3VuZGVmIEVYUF9BRERSTElT VF9QQUdFCS8qIENGX0FSR19FTkFCTEUoYWRkcmxpc3QtcGFnZSkgKi8NCiAg I3VuZGVmIEVYUF9BTFRfQklORElOR1MJCS8qIENGX0FSR19FTkFCTEUoYWx0 LWJpbmRpbmdzKSAqLw0KKyAjdW5kZWYgU09VUkNFX0NBQ0hFCQkvKiBDRl9B UkdfRU5BQkxFKHNvdXJjZS1jYWNoZSkgKi8NCiAgI3VuZGVmIEVYUF9DSEFS VFJBTlNfQVVUT1NXSVRDSAkvKiBDRl9BUkdfRU5BQkxFKGZvbnQtc3dpdGNo KSAqLw0KICAjdW5kZWYgRVhQX0tFWUJPQVJEX0xBWU9VVAkvKiBDRl9BUkdf RU5BQkxFKGtiZC1sYXlvdXQpICovDQogICN1bmRlZiBFWFBfTElCSlMJCS8q IENGX0FSR19FTkFCTEUobGlianMpICovDQoqKiogLi9seW54LmNmZy5vcmln CVdlZCBNYXIgMTcgMjI6MTc6MTEgMTk5OQ0KLS0tIC4vbHlueC5jZmcJU3Vu IEFwciAxMSAyMzowNzozNCAxOTk5DQoqKioqKioqKioqKioqKioNCioqKiA1 MTMsNTE4ICoqKioNCi0tLSA1MTMsNTMyIC0tLS0NCiAgI0RFRkFVTFRfQ0FD SEVfU0laRToxMA0KICAjREVGQVVMVF9WSVJUVUFMX01FTU9SWV9TSVpFOjUx MjAwMA0KICANCisgIyBTT1VSQ0VfQ0FDSEUgc2V0cyB0aGUgc291cmNlIGNh Y2hpbmcgYmVoYXZpb3IgZm9yIEx5bng6DQorICMgRklMRSBjYXVzZXMgTHlu eCB0byBrZWVwIGEgdGVtcG9yYXJ5IGZpbGUgZm9yIGVhY2ggY2FjaGVkIGRv Y3VtZW50DQorICMgICBjb250YWluaW5nIHRoZSBIVE1MIHNvdXJjZSBvZiB0 aGUgZG9jdW1lbnQsIHdoaWNoIGl0IHVzZXMgdG8gcmVnZW5lcmF0ZQ0KKyAj ICAgdGhlIGRvY3VtZW50IHdoZW4gY2VydGFpbiBzZXR0aW5ncyBhcmUgY2hh bmdlZCAoZm9yIGluc3RhbmNlLA0KKyAjICAgaGlzdG9yaWNhbCB2cy4gbWlu aW1hbCB2cy4gdmFsaWQgY29tbWVudCBwYXJzaW5nKSBpbnN0ZWFkIG9mIHJl bG9hZGluZw0KKyAjICAgdGhlIHNvdXJjZSBmcm9tIHRoZSBuZXR3b3JrLg0K KyAjIE1FTU9SWSBpcyBsaWtlIEZJTEUsIGV4Y2VwdCB0aGUgZG9jdW1lbnQg c291cmNlIGlzIGtlcHQgaW4gbWVtb3J5LiAgWW91DQorICMgICBtYXkgd2lz aCB0byBhZGp1c3QgREVGQVVMVF9DQUNIRV9TSVpFIGFuZCBERUZBVUxUX1ZJ UlRVQUxfTUVNT1JZX1NJWkUNCisgIyAgIGFjY29yZGluZ2x5Lg0KKyAjIE5P TkUgaXMgdGhlIGRlZmF1bHQ7IHRoZSBkb2N1bWVudCBzb3VyY2UgaXMgbm90 IGNhY2hlZCwgYW5kIGlzIHJlbG9hZGVkDQorICMgICBmcm9tIHRoZSBuZXR3 b3JrIHdoZW4gbmVlZGVkLg0KKyAjDQorICNTT1VSQ0VfQ0FDSEU6Tk9ORQ0K KyANCiAgIyBJZiBBTFdBWVNfUkVTVUJNSVRfUE9TVFMgaXMgc2V0IFRSVUUs IEx5bnggYWx3YXlzIHdpbGwgcmVzdWJtaXQgZm9ybXMNCiAgIyB3aXRoIG1l dGhvZCBQT1NULCBkdW1waW5nIGFueSBjYWNoZSBmcm9tIGEgcHJldmlvdXMg c3VibWlzc2lvbiBvZiB0aGUNCiAgIyBmb3JtLCBpbmNsdWRpbmcgd2hlbiB0 aGUgZG9jdW1lbnQgcmV0dXJuZWQgYnkgdGhhdCBmb3JtIGlzIHNvdWdodCB3 aXRoDQo= --8323328-1077411990-923887740=:1861-- From owner-lynx-dev@sig.net Mon Apr 12 00:40:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA09417 for ; Mon, 12 Apr 1999 00:40:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA13799; Mon, 12 Apr 1999 00:27:07 -0500 (CDT) Date: Mon, 12 Apr 1999 01:19:27 -0400 From: Chuck Martin To: lynx-dev@sig.net Subject: Re: path: revised lynx-dev.html Message-ID: <19990412011927.A17975@delta.Nexus.of.Obsolescence> Mail-Followup-To: lynx-dev@sig.net References: <199904112356.TAA01156@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904112356.TAA01156@chass.utoronto.ca>; from Philip Webb on Sun, Apr 11, 1999 at 07:56:11PM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 860 Lines: 21 On Sun, Apr 11, 1999 at 07:56:11PM -0400, Philip Webb wrote: > > 990411 Leonid Pauzner wrote: > > > > Different users may have different screen width (not only 80 col) > > and HTML documents will be rendered accordingly. > > So the documents within
 or with 
> > will not be good looking at different size. Nothing more. > > yes, but inserting
to force a line-break at a phrase-break > will always shorten the line; people with very wide screens will need > to hit the Space-bar a bit more often, that's all. I think you missed Leonid's point. Lynx may be running in a window under some GUI (Windows or X) that has been resized to *less than* 80 columns. This would mean that you'd see alternating long and short lines, which really looks ugly. Those of us who avoid GUIs unless absolutely necessary would never notice this. Chuck From owner-lynx-dev@sig.net Mon Apr 12 01:20:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA10442 for ; Mon, 12 Apr 1999 01:20:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA17117; Mon, 12 Apr 1999 01:02:35 -0500 (CDT) Date: Sun, 11 Apr 1999 23:02:32 -0700 (PDT) From: David Combs Message-Id: <199904120602.XAA26907@netcom13.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: joke (m$) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2018 Lines: 52 Bill Gates died in a car accident. He found himself in Purgatory being sized up by God... "Well, Bill, I'm really confused on this call. I'm not sure whether to send you to Heaven or Hell. After all, you enormously helped society by putting a computer in almost every home in the world, and yet you created that ghastly Windows 95. I'm going to do something I've never done before. In your case, I'm going to let you decide where you want to go!" Bill replied, "Well, thanks, God. What's the difference between the two?" God said, "I'm willing to let you visit both places briefly if it will help you make a decision." "Fine, but where should I go first?" God said, "I'm going to leave that up to you." Bill said, "OK, then, let's try Hell first." So Bill went to Hell. It was a beautiful, clean, sandy beach with clear waters. There were thousands of beautiful women running around, playing in the water, laughing and frolicking about. The sun was shining, the temperature was perfect. Bill was very pleased. "This is great!" he told God. "If this is Hell, I REALLY want to see Heaven!" "Fine," said God and off they went. Heaven was a high place in the clouds, with angels drifting about playing harps and singing. It was nice but not as enticing as Hell. Bill thought for a quick minute and rendered his decision. "Hmm, I think I prefer Hell," he told God. "Fine," retorted God, "as you desire." So Bill Gates went to Hell. Two weeks later, God decided to check up on the late billionaire to see how he was doing in Hell. When God arrived in Hell, he found Bill shackled to a wall, screaming amongst the hot flames in a dark cave. He was being burned and tortured by demons. "How's everything going, Bill?" God asked. Bill responded - his voice full of anguish and disappointment, "This is awful, this is not what I expected. I can't believe this happened. What happened to that other place with the beaches and the beautiful women playing in the water?" God says, "That was just the screen saver." From owner-lynx-dev@sig.net Mon Apr 12 01:37:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA10661 for ; Mon, 12 Apr 1999 01:37:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA19181; Mon, 12 Apr 1999 01:27:20 -0500 (CDT) Date: Mon, 12 Apr 1999 08:27:15 +0200 (CEST) Message-Id: <199904120627.IAA10456@login-2.eunet.no> From: "Gisle Vanem" To: lynx-dev@sig.net Subject: Re: lynx-dev DOS bug report - no fix (PDCurses build) X-Mailer: Watt/POP MIME-Version: 1.0 Content-type: text/plain; charset=cp850 Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 382 Lines: 11 Doug Kaufman said: > 1. When exiting with CTRL-C or CTRL-BREAK, the system BREAK is not > reset to the value present before lynx was executed. It is always ON. > BREAK is reset properly with a normal exit. Be sure to compile with `IGNORE_CTRL_C'. This should always give the "Are you sure you want to quit? (y)" prompt and exit properly from there. Gisle V. From owner-lynx-dev@sig.net Mon Apr 12 02:01:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA11437 for ; Mon, 12 Apr 1999 02:01:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21237; Mon, 12 Apr 1999 01:53:27 -0500 (CDT) From: David Woolley Message-Id: <199904111031.LAA05894@djwhome.demon.co.uk> Subject: Re: lynx-dev Information To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 11:31:37 +0100 (BST) Cc: akash@tc4hq.cmcltd.com In-Reply-To: from "akash agrawal" at Apr 8, 99 05:08:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 571 Lines: 12 > Can I download Lynx exe(Unix) from the InterNet.If yes pls tell me > from which Site. Depends on the exact brand and version of Unix. Some are at the site already given. Some may be on various sites scattered throughout the internet. Some may require you to compile from source. If the development tools exist on your machine, I would personally always advise compiling from source. (Normally one says "binary" for Unix, just possibly "executables", but "exe" comes from Microsoft's naming conventions and would imply DOS or Windows if you hadn't qualified it.) From owner-lynx-dev@sig.net Mon Apr 12 02:03:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA11444 for ; Mon, 12 Apr 1999 02:03:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21187; Mon, 12 Apr 1999 01:52:58 -0500 (CDT) From: David Woolley Message-Id: <199904111123.MAA05999@djwhome.demon.co.uk> Subject: lynx-dev Graphics for Freenet Lynx To: lynx-dev@sig.net Date: Sun, 11 Apr 1999 12:23:42 +0100 (BST) In-Reply-To: <370C1CA7.3D8953AA@auracom.com> from "Jamie Ellis" at Apr 8, 99 00:04:07 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4144 Lines: 76 > Our arrangement with the Provincial Department of Education limits us to > providing member clients text based dial up access only (although we do > have a regular WWW Graphical presense. > > Our members are demanding graphics! 'Text is anachronistic,' I hear. Be I suspect they are demanding graphics for the reasons that the Department of Education doesn't want to provide graphical access, i.e. to access entertainment (/advertising) sites. (Another reason for the rule may be to avoid overt competition with commercial ISPs and web cafes, although it still must be based on the premise that most valid educational material is viewable in text mode.) Your real problems are that: some useful resources, like search engines, are paid for by advertising and therefore only really interested in maintaining glossy presentations on the big 2; quite a few people with real information either use tools that do things like GIF the text, through ignorance, or are also playing around with following web fashions at the same time as providing their information; and, with commercial sites that include valuable technical information, you usually have to fight your way through the graphical bits done by their marketing people before getting to the real content. Such problem sites are also likely to use active content, and may be unuseable without it. > that as it may, it raises the question, what sort of server side > improvements can be made to gussy up the appearance of Lynx? We have a I'm not clear whether you are talking about desiging pages so as to improve their appearance when viewed with Lynx, or about providing access to the graphic content of third party pages. For your own pages, good design should produce a clean presentation on Lynx without any special provisions. For third party pages, if the users have suitable viewers, they have been able to download the graphical content individually for a long time with Lynx, but only in full screen mode. Anything else would be most easily implemented by running a PPP service and letting them use IE! Generally commercial sites with high graphic content will never look good in anything except one of the big 2 browsers. I think you need to accept that: - if the users can afford to go to competition, or the competition can afford to give away the access, there is no role for public service access; - if the content providers are not interested in communicating with your users, that is their loss; unfortunately many of them would see no commercial justification in serving a market that can only afford to use a freenet service and would probably consider any reformatting of their information content, by you, as a breach of copyright, but it is worth trying to tell non-commercial content providers that they are failing to get their message across, as they are probably more worried about lost minds than lost profits. PS I'm somewhat curious about the public service access to the internet in North America. My impression in the UK is that it is mainly limited to a few libraries using GUI browsers, although many schools also provide such access, again I suspect with GUI tools. It seems strange that you have large numbers of users operating text only at the same time as probably having the largest number of content providers only interested in rich people with lots of bandwidth, GUI browsers and fast machines. Looking at the squid list, ones sees another aspect of this in poor countries, where the net is sufficiently new that the users of commercial access have jumped straight in with current GUI tools. There the ISPs are fighting a hopeless battle against the profligate use of bandwidth (particularly non-cacheable pages) by the content provides most of their customers want, namely the US commercial ones. PPS you might consider converting images to ASCII art for those without the tools or understanding to download and view. However, relatively few images real pictures, most are purely cosmetic items, or are bitmaps of text. I doubt that your users would consider this more than a token move, so wouldn't really reccommend it. From owner-lynx-dev@sig.net Mon Apr 12 04:07:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA13431 for ; Mon, 12 Apr 1999 04:07:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA25458; Mon, 12 Apr 1999 02:41:50 -0500 (CDT) To: lynx-dev@sig.net References: <199904112359.TAA01460@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 11:37:25 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx for Mac's (was screen adjustment) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 858 Lines: 20 11-Apr-99 19:59 Philip Webb wrote: > 990412 Leonid Pauzner wrote: >> 11-Apr-99 18:21 Philip Webb wrote: >>> the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx . >> This is a port of lynx/2.7.1 and seems no more supported/updated. > yes, i had a feeling it was getting marginal these days, > which raises the question whether we should still claim > that Lynx is available on Mac's. shouldn't we perhaps rather say > that we need someone to do a good upto-date job of re-porting it, > with appropriate help documentation? Yes, it would be more polite & welcome approach. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Mon Apr 12 04:12:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA13624 for ; Mon, 12 Apr 1999 04:12:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA25463; Mon, 12 Apr 1999 02:41:52 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 11:34:31 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2042 Lines: 45 11-Apr-99 23:25 Scott Bigham wrote: > On Sun, 11 Apr 1999, Scott Bigham wrote: >> On Sun, 11 Apr 1999, Leonid Pauzner wrote: >> > I prefer to have a choice between caching sources in temp files or keeping >> > them in RAM by managing a dynamic list of Cached Stream's or so. >> Yeah, well, I'm not that good. > You had to challenge me, didn't you? ;) Okay, after some pfutzing > around with HTChunks, I think I've got a working version of memory > caching of source. The SOURCE_CACHE option now has settings FILE, > MEMORY and NONE, with the obvious meanings, defaulting to NONE. This > patch replaces my previous patch, so you'll have to back that out first. Oh, thanks! It also fix cleanup_files problem. Really nice. Just two minor problems found with my particular environment: 1) when SOURCE_CACHE:MEMORY and we are running on very slow machine (i386 in my case) and the document rather long the fetching of "\" source may be really slow, but no "partial mode" happens: no read-progress counter nor redisplay the page while in progress. This is done in HTDisplayPartial() and called from HTCopy() and HTFileCopy(), so OK when running with SOURCE_CACHE:FILE 2) when SOURCE_CACHE:FILE and I run into the document with DOS/WINDOWS end-of-line (cr/lf) style, the cached source has the same line endings (at least with DJGPP when html files opened in a text mode) and when I press "\" I saw the source with additional blank lines between the actual source lines (in a nornal case lynx handle this on an early stage). Seems due to opening temp files via LYUtils.c functions. Don't know a workaround yet, this seems affect only DOS/WINDOWS platforms and can be done laterly. 3) (for Tom) I think #define SOURCE_CACHE should be enabled by default both for configure-based platforms and in the DOS src/makefile.* files since this will allow more testing (and rather stable already) and the default flag in lynx.cfg is NONE. > -sbigham From owner-lynx-dev@sig.net Mon Apr 12 04:13:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA14154 for ; Mon, 12 Apr 1999 04:13:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA25450; Mon, 12 Apr 1999 02:41:48 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 11:04:06 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 731 Lines: 20 11-Apr-99 22:49 Scott Bigham wrote: > On Sun, 11 Apr 1999 dickey@clark.net wrote: > [I wrote, discussing "#define atexit(func) /* nothing */"] >> > Eek! That's almost certainly a bad idea. >> no - only on MSDOS is it a bad idea (good idea on Unix and VMS, since >> allocated memory is returned on exit from a process). > Actually, I was thinking more along the lines of someone in the future > trying to install an atexit function that does something besides release > memory, not knowing he was being undercut. I dunno, call me paranoid, > but this just has "disaster waiting to happen" written all over it. That was exactly what happens (for DJGPP lynx port). > -sbigham From owner-lynx-dev@sig.net Mon Apr 12 04:23:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA14350 for ; Mon, 12 Apr 1999 04:23:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA26687; Mon, 12 Apr 1999 02:56:47 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 11:50:57 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 577 Lines: 14 12-Apr-99 11:34 I wrote: > 1) when SOURCE_CACHE:MEMORY and we are running on very slow machine > (i386 in my case) and the document rather long > the fetching of "\" source may be really slow, > but no "partial mode" happens: no read-progress counter > nor redisplay the page while in progress. > This is done in HTDisplayPartial() and called from HTCopy() and HTFileCopy(), > so OK when running with SOURCE_CACHE:FILE This is in your HTParseMem() under /* Shove the data down the stream in one lump. ;) */ comment. Not sure whether we can change this. From owner-lynx-dev@sig.net Mon Apr 12 04:32:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA14539 for ; Mon, 12 Apr 1999 04:32:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA27520; Mon, 12 Apr 1999 03:07:03 -0500 (CDT) Date: Mon, 12 Apr 1999 01:06:58 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev DOS bug report - no fix (PDCurses build) In-Reply-To: <199904120627.IAA10456@login-2.eunet.no> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 899 Lines: 24 On Mon, 12 Apr 1999, Gisle Vanem wrote: > Doug Kaufman said: > > > 1. When exiting with CTRL-C or CTRL-BREAK, the system BREAK is not > > reset to the value present before lynx was executed. It is always ON. > > BREAK is reset properly with a normal exit. > > Be sure to compile with `IGNORE_CTRL_C'. This should always > give the "Are you sure you want to quit? (y)" prompt and exit > properly from there. You misunderstood the problem. This has to do with the DOS BREAK setting getting restored after lynx exits. See the code in LYMain.c that gets the initial setting, then restores it after lynx exits. The DJGPP code sets BREAK checking on during lynx, so that you can break out of a hung connection. This works with SLang, but not with PDCurses. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Mon Apr 12 04:46:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA14763 for ; Mon, 12 Apr 1999 04:46:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA28750; Mon, 12 Apr 1999 03:21:53 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 12:16:42 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 283 Lines: 5 My previous posts on emulating proxy-cache should probably be ignored. But it will really useful to split the recyclyng mechanism between the cached sources and HText's. This allows to keep different length for each stack and may be useful for performance/resources fine-turning. From owner-lynx-dev@sig.net Mon Apr 12 05:36:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA15772 for ; Mon, 12 Apr 1999 05:36:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA03117; Mon, 12 Apr 1999 04:17:27 -0500 (CDT) From: dickey@clark.net Message-Id: <199904120917.FAA22728@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 05:17:23 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 11, 99 11:25:54 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 840 Lines: 26 > > On Sun, 11 Apr 1999, Scott Bigham wrote: > > > On Sun, 11 Apr 1999, Leonid Pauzner wrote: > > > > I prefer to have a choice between caching sources in temp files or keeping > > > them in RAM by managing a dynamic list of Cached Stream's or so. > > > Yeah, well, I'm not that good. > > You had to challenge me, didn't you? ;) Okay, after some pfutzing > around with HTChunks, I think I've got a working version of memory > caching of source. The SOURCE_CACHE option now has settings FILE, > MEMORY and NONE, with the obvious meanings, defaulting to NONE. This > patch replaces my previous patch, so you'll have to back that out first. you're in luck (I'm 3/4 through the patches and have not applied your earlier one yet). > -sbigham -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 06:19:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16606 for ; Mon, 12 Apr 1999 06:19:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA16997; Mon, 12 Apr 1999 04:58:08 -0500 (CDT) Date: Mon, 12 Apr 1999 05:57:34 -0400 From: Webmaster Jim To: Collin Forbes , lynx-dev@sig.net Subject: lynx-dev Re: We are planning to start mirroring. Message-ID: <19990412055734.E28259@mail.bcpl.net> References: <19990409063730.B378@bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Collin Forbes on Fri, Apr 09, 1999 at 03:56:59AM -0700 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 566 Lines: 13 On Fri, Apr 09, 1999 at 03:56:59AM -0700, Collin Forbes wrote: > I have a mirror of running at > . It updates at 3:05 am daily Pacific time. > This is still at the end of an ISDN connection, but we are hoping to upgrade > to half-T1-speed ADSL soon. Thank you. ------ Marvin the Paranoid Android says: No one can help me, not that anyone has tried of course. From owner-lynx-dev@sig.net Mon Apr 12 06:37:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16990 for ; Mon, 12 Apr 1999 06:37:55 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA17999; Mon, 12 Apr 1999 05:11:07 -0500 (CDT) From: Philip Webb Message-Id: <199904121011.GAA23928@chass.utoronto.ca> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 06:11:02 -0400 (EDT) In-Reply-To: from "Scott Bigham" at Apr 11, 99 11:29:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 438 Lines: 10 990411 Scott Bigham wrote: > D'oh! *This* time the patch is attached. We apologize for the confusion. can you write a few lines for Users Guide, while you're at it? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Mon Apr 12 06:38:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA16998 for ; Mon, 12 Apr 1999 06:38:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA18941; Mon, 12 Apr 1999 05:22:28 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 14:15:21 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1527 Lines: 36 12-Apr-99 11:34 I wrote: > 2) when SOURCE_CACHE:FILE and I run into the document with DOS/WINDOWS > end-of-line (cr/lf) style, the cached source has the same line endings > (at least with DJGPP when html files opened in a text mode) > and when I press "\" I saw the source with additional blank lines > between the actual source lines (in a nornal case lynx handle this > on an early stage). Seems due to opening temp files via LYUtils.c > functions. Don't know a workaround yet, this seems affect only > DOS/WINDOWS platforms and can be done laterly. Here the fix of this problem, hope it will not add more problems for UNIX/VMS platforms. This patch against your "take 2" version and affect the code #ifdef'ed with SOURCE_CACHE, the comment is self-explanatory. diff -u old/html.c ./html.c --- old/html.c Mon Apr 12 13:41:22 1999 +++ ./html.c Mon Apr 12 13:47:28 1999 @@ -7416,7 +7416,13 @@ return target; } - if (!(stream->fp = LYOpenTemp(filename, HTML_SUFFIX, "w"))) { + /* + * Note: LYOpenTemp with "b" mode is a hack: should be "w" since + * the file is essentially a text but let will not fall into the + * compatibility problems with non-UNIX end-of-line styles, + * so save data verbatim. + */ + if (!(stream->fp = LYOpenTemp(filename, HTML_SUFFIX, "b"))) { CTRACE(tfp, "Cannot get source cache file for URL %s\n", HTAnchor_address((HTAnchor *)anchor)); FREE(stream); From owner-lynx-dev@sig.net Mon Apr 12 06:53:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA17399 for ; Mon, 12 Apr 1999 06:53:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA19302; Mon, 12 Apr 1999 05:26:59 -0500 (CDT) Date: Mon, 12 Apr 1999 06:26:29 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Re: autoconfigure and host_os dependent CC Message-ID: <19990412062628.G28259@mail.bcpl.net> References: <199904100525.XAA12765@sanitas> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904100525.XAA12765@sanitas>; from pg@sweng.stortek.com on Fri, Apr 09, 1999 at 11:25:36PM -0600 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1734 Lines: 49 On Fri, Apr 09, 1999 at 11:25:36PM -0600, pg@sweng.stortek.com wrote: > I'd like to make the default C compiler dependent on the > host operating system. There's a case statement that does > this sort of thing -- I attempted adding: > > case $host_os in > os390*) > echo "Original CC was (${CC-undefined})" > CC=${CC-c89} > CFLAGS="$CFLAGS -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE" > ;; > esac > > ... but it happens far too late, after much testing is already done. > > The original setting apparently happens in macro AC_PROG_CC, called > out of configure.in. But I don't know where to find the definition > of this macro. > > For the time being, I'm simply supplying CC=c89 in the environment > of the call to configure. > > Any better suggestions? The environment variable CC is checked early in configure, the script created from configure.in: [ approx line 650 ] # Extract the first word of "gcc", so it can be a program name with args. set dummy gcc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 echo "configure:649: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else if test -n "$CC"; then ac_cv_prog_CC="$CC" # Let the user override the test. else [...] The easy way to force a non-default is to put a different CC in your environment. However, if the default CC is broken for an OS, then perhaps configure needs to learn this somehow. ----- Marvin the Paranoid Android says: No one can help me, not that anyone has tried of course. From owner-lynx-dev@sig.net Mon Apr 12 07:11:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA17664 for ; Mon, 12 Apr 1999 07:11:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA20136; Mon, 12 Apr 1999 05:36:55 -0500 (CDT) To: lynx-dev@sig.net References: <199904121011.GAA23928@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 14:32:44 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 854 Lines: 21 12-Apr-99 06:11 Philip Webb wrote: > 990411 Scott Bigham wrote: >> D'oh! *This* time the patch is attached. We apologize for the confusion. > can you write a few lines for Users Guide, while you're at it? The lynx.cfg comments really enough (also in INSTALLATION and CHANGES). I think this is a very technical info, not for Users Guide. (and I do not like you script example for textarea wrapper for Users Guide, samples should go to samples/ directory or elsewhere). Probably, when the things stabilised, we will use SOURCE_CACHE ON by default if we got a consensus. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Mon Apr 12 07:42:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA18556 for ; Mon, 12 Apr 1999 07:42:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA23372; Mon, 12 Apr 1999 06:11:51 -0500 (CDT) From: dickey@clark.net Message-Id: <199904121111.HAA04217@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 07:11:48 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 11, 99 11:29:00 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 228 Lines: 11 > D'oh! *This* time the patch is attached. We apologize for the > confusion. I (or rather 'patch') cannot make sense of this file. > -sbigham -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 09:32:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA21767 for ; Mon, 12 Apr 1999 09:32:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA03025; Mon, 12 Apr 1999 07:31:25 -0500 (CDT) X-Authentication-Warning: web0.greatbasin.net: CL_Smith owned process doing -bs Date: Sun, 11 Apr 1999 23:13:07 -0700 (PDT) From: Christopher Smith To: Bruce Bailey cc: Lynx Dev Subject: Re: lynx-dev Anyone know of a compatible email service? In-Reply-To: <199904072145.RAA02202@smtp-gw.vma.verio.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1085 Lines: 32 On Wed, 7 Apr 1999, Bruce Bailey wrote: >Dear All, >There are plenty of free email providers, but the half dozen that I have >explored in depth ALL require Microsoft Internet Explorer and/or Internet >Explorer (or Windows '95) and cookies. The PC's we are getting donated to >us are x386's! > >Can anyone recommend a free web-based email service that is VERY compatible >with Lynx? (Please keep in mind that I am talking about access to Lynx via >vt100 emulation on plain vanilla dial-up access. Running the 32 bit Win >'95 version of Lynx locally is NOT an option for this application!) > Try Hotmail.. they have an option for no frames I view an alternate address I have with Hotmail using Lynx on just such a setup at home. Including the 386! the address is www.hotmail.com >Thank you very much. > >Bruce Bailey, DORS Webmaster >http://www.dors.state.md.us/ >410/554-9211 > You're welcome, of course :) | The last time I pointed out who was to blame, | Chris Smith | | I broke my finger on the mirror. | CL_Smith@greatbasin.net | From owner-lynx-dev@sig.net Mon Apr 12 10:09:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA22705 for ; Mon, 12 Apr 1999 10:09:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA17629; Mon, 12 Apr 1999 08:32:00 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 12 Apr 1999 17:28:23 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev PATCH [dev21]: source caching ("raw_mode" patch) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6546 Lines: 150 10-Apr-99 23:59 Scott Bigham wrote: > In this implementation, each document kept in cache has associated with it > a temporary file containing the HTML source for the document (well, not all > of them -- only those using the HTTP protocol, on the premise that file:// > documents are probably local and ftp:// documents are probably not HTML). > The temporary file is deleted when the document is uncached. For certain > operations, instead of reloading the document via HTLoad(), the > source file is reparsed with HTParseFile(). The cached document also > remembers certain parser settings (screen size, historical vs. minimal vs. > valid comment parsing, and the like), and is regenerated from source if it Accidentally, I found a longstanding bug with LYRawMode handling in lynx: HTMLSetCharacterHandling() from LYCharSets.c called a lot in getfile() cyrcle, it can change LYRawMode for its internal needs without any invention from user, probably due to a bug. It was not bothering us before but arise unexpectedly in SOURCE_CACHE mode. >From trace: HTAccess: Document already in memory. HTdocument_settings_changed: RAW_MODE setting has changed (was OFF, now ON) User message: Reparsing document under current settings... Reparsing from source memory cache 208974 HTFormat: Constructing stream stack for text/html to www/present So this is a chartrans problem (LYOptions.c and LYCharSets.c). In fact, LYRawMode is a very internal parameter (probably not used now) and out of our hands. LYUseDefaultRawMode can be changed by user instead. So immediate patch applyed (affects LYMainLoop.c and recent SOURCE_CACHE code in GridText.c, also add some traces for LYCharSets.c): diff -u old/gridtext.c ./gridtext.c --- old/gridtext.c Mon Apr 12 10:39:10 1999 +++ ./gridtext.c Mon Apr 12 16:32:38 1999 @@ -191,7 +191,7 @@ */ BOOLEAN clickable_images; BOOLEAN pseudo_inline_alts; - BOOLEAN raw_mode; + BOOLEAN use_default_raw_mode; BOOLEAN historical_comments; BOOLEAN minimal_comments; BOOLEAN soft_dquotes; @@ -529,7 +529,7 @@ */ self->clickable_images = clickable_images; self->pseudo_inline_alts = pseudo_inline_alts; - self->raw_mode = LYRawMode; + self->use_default_raw_mode = LYUseDefaultRawMode; self->historical_comments = historical_comments; self->minimal_comments = minimal_comments; self->soft_dquotes = soft_dquotes; @@ -6407,7 +6407,9 @@ trace_setting_change("PSEUDO_INLINE_ALTS", HTMainText->pseudo_inline_alts, pseudo_inline_alts); - trace_setting_change("RAW_MODE", HTMainText->raw_mode, LYRawMode); + trace_setting_change("RAW_MODE", + HTMainText->use_default_raw_mode, + LYUseDefaultRawMode); trace_setting_change("HISTORICAL_COMMENTS", HTMainText->historical_comments, historical_comments); @@ -6424,7 +6426,7 @@ return (HTMainText->clickable_images != clickable_images || HTMainText->pseudo_inline_alts != pseudo_inline_alts || - HTMainText->raw_mode != LYRawMode || + HTMainText->use_default_raw_mode != LYUseDefaultRawMode || HTMainText->historical_comments != historical_comments || HTMainText->minimal_comments != minimal_comments || HTMainText->soft_dquotes != soft_dquotes || diff -u old/lymainlo.c ./lymainlo.c --- old/lymainlo.c Mon Apr 12 10:39:14 1999 +++ ./lymainlo.c Mon Apr 12 16:29:34 1999 @@ -248,7 +248,7 @@ BOOLEAN rlink_allowed; BOOLEAN vi_keys_flag = vi_keys; BOOLEAN emacs_keys_flag = emacs_keys; - BOOLEAN LYRawMode_flag = LYRawMode; + BOOLEAN LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifndef NO_OPTION_MENU BOOLEAN LYSelectPopups_flag = LYSelectPopups; BOOLEAN verbose_img_flag = verbose_img; @@ -3975,7 +3975,7 @@ CurrentCharSet_flag != current_char_set || CurrentAssumeCharSet_flag != UCLYhndl_for_unspec || verbose_img_flag != verbose_img || - LYRawMode_flag != LYRawMode || + LYUseDefaultRawMode_flag != LYUseDefaultRawMode || LYSelectPopups_flag != LYSelectPopups || ((strcmp(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")) || @@ -4044,7 +4044,7 @@ CurrentAssumeCharSet_flag = UCLYhndl_for_unspec; show_dotfiles_flag = show_dotfiles; verbose_img_flag = verbose_img; - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; LYSelectPopups_flag = LYSelectPopups; StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); @@ -5557,7 +5557,7 @@ LYUseDefaultRawMode = !LYUseDefaultRawMode; HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; diff -u old/lycharse.c ./lycharse.c --- old/lycharse.c Thu Mar 18 11:05:46 1999 +++ ./lycharse.c Mon Apr 12 17:19:50 1999 @@ -397,6 +397,8 @@ PUBLIC void HTMLSetCharacterHandling ARGS1(int,i) { int chndl = safeUCGetLYhndl_byMIME(UCAssume_MIMEcharset); + BOOLEAN LYRawMode_flag = LYRawMode; + int UCLYhndl_for_unspec_flag = UCLYhndl_for_unspec; if (LYCharSet_UC[i].enc != UCT_ENC_CJK) { HTCJK = NOCJK; @@ -484,6 +486,19 @@ ena_csi((LYlowest_eightbit[current_char_set] > 155)); + + /* some diagnostics */ + it (TRACE) { + if (LYRawMode_flag != LYRawMode) + CTRACE(tfp, "HTMLSetCharacterHandling: LYRawMode changed %s -> %s\n", + (LYRawMode_flag ? "ON" : "OFF"), + (LYRawMode ? "ON" : "OFF")); + if (UCLYhndl_for_unspec_flag != UCLYhndl_for_unspec) + CTRACE(tfp, "HTMLSetCharacterHandling: UCLYhndl_for_unspec changed %d -> %d\n", + UCLYhndl_for_unspec_flag, + UCLYhndl_for_unspec); + } + return; } From owner-lynx-dev@sig.net Mon Apr 12 11:18:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA24648 for ; Mon, 12 Apr 1999 11:18:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23413; Mon, 12 Apr 1999 08:48:57 -0500 (CDT) Date: Mon, 12 Apr 1999 09:48:38 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 994 Lines: 24 On Mon, 12 Apr 1999, Leonid Pauzner wrote: > 1) when SOURCE_CACHE:MEMORY and we are running on very slow machine > (i386 in my case) and the document rather long > the fetching of "\" source may be really slow, > but no "partial mode" happens: no read-progress counter > nor redisplay the page while in progress. Hmm, I hadn't expected that to be a problem. That's pretty easy to fix; I'll have something tonight. > 2) when SOURCE_CACHE:FILE and I run into the document with DOS/WINDOWS > end-of-line (cr/lf) style, the cached source has the same line endings > (at least with DJGPP when html files opened in a text mode) > and when I press "\" I saw the source with additional blank lines > between the actual source lines (in a nornal case lynx handle this > on an early stage). Yeah, I'd wondered if I needed to open the temp file in binary mode. Will that cause problems with documents with high-bit Latin-1 characters (real, not entified)? -sbigham From owner-lynx-dev@sig.net Mon Apr 12 11:21:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA24676 for ; Mon, 12 Apr 1999 11:21:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28253; Mon, 12 Apr 1999 09:03:07 -0500 (CDT) Date: Mon, 12 Apr 1999 10:02:51 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 In-Reply-To: <199904121111.HAA04217@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 25914 Lines: 945 On Mon, 12 Apr 1999 dickey@clark.net wrote: > I (or rather 'patch') cannot make sense of this file. No? It's just a straightforward 'diff -c'; it seems to have worked for Leonid, at least. Could it have gotten munged in the attachment process? I'll try it again inline. -sbigham *** ./src/GridText.c.orig Tue Mar 30 12:10:37 1999 --- ./src/GridText.c Sun Apr 11 22:31:11 1999 *************** *** 46,51 **** --- 46,55 ---- #undef DEBUG_APPCH + #ifdef SOURCE_CACHE + #include + #endif + #ifdef USE_COLOR_STYLE #include #include *************** *** 114,119 **** --- 118,129 ---- PUBLIC BOOLEAN underline_on = OFF; PUBLIC BOOLEAN bold_on = OFF; + #ifdef SOURCE_CACHE + PUBLIC char * source_cache_filename = NULL; + PUBLIC HTChunk * source_cache_chunk = NULL; + PUBLIC int LYCacheSource = SOURCE_CACHE_NONE; + #endif + #if defined(USE_COLOR_STYLE) #define MAX_STYLES_ON_LINE 64 *************** *** 173,178 **** --- 183,204 ---- */ struct _HText { HTParentAnchor * node_anchor; + #ifdef SOURCE_CACHE + char * source_cache_file; + HTChunk * source_cache_chunk; + /* + * Parse settings when this HText was generated. + */ + BOOLEAN clickable_images; + BOOLEAN pseudo_inline_alts; + BOOLEAN raw_mode; + BOOLEAN historical_comments; + BOOLEAN minimal_comments; + BOOLEAN soft_dquotes; + BOOLEAN old_dtd; + int lines; /* Screen size */ + int cols; + #endif HTLine * last_line; int Lines; /* Number of them */ int chars; /* Number of them */ *************** *** 483,488 **** --- 509,542 ---- self->stale = YES; self->toolbar = NO; self->tabs = NULL; + #ifdef SOURCE_CACHE + /* + * Yes, this is a Gross And Disgusting Hack(TM), I know... + */ + self->source_cache_file = NULL; + if (LYCacheSource == SOURCE_CACHE_FILE && source_cache_filename) { + StrAllocCopy(self->source_cache_file, source_cache_filename); + FREE(source_cache_filename); + } + self->source_cache_chunk = NULL; + if (LYCacheSource == SOURCE_CACHE_MEMORY && source_cache_chunk) { + self->source_cache_chunk = source_cache_chunk; + source_cache_chunk = NULL; + } + + /* + * Remember the parse settings. + */ + self->clickable_images = clickable_images; + self->pseudo_inline_alts = pseudo_inline_alts; + self->raw_mode = LYRawMode; + self->historical_comments = historical_comments; + self->minimal_comments = minimal_comments; + self->soft_dquotes = soft_dquotes; + self->old_dtd = Old_DTD; + self->lines = LYlines; + self->cols = LYcols; + #endif /* * If we are going to render the List Page, always merge in hidden * links to get the numbering consistent if form fields are numbered *************** *** 729,734 **** --- 783,805 ---- HTMainAnchor = NULL; } + #ifdef SOURCE_CACHE + /* + * Clean up the source cache, if any. + */ + if (self->source_cache_file) { + CTRACE(tfp, "Removing source cache file %s\n", + self->source_cache_file); + LYRemoveTemp(self->source_cache_file); + FREE(self->source_cache_file); + } + if (self->source_cache_chunk) { + CTRACE(tfp, "Removing memory source cache %p\n", + (void *)self->source_cache_chunk); + HTChunkFree(self->source_cache_chunk); + } + #endif + FREE(self); } *************** *** 6189,6194 **** --- 6260,6438 ---- CTRACE(tfp, "HTuncache.. HTMainText already is NULL!\n"); } } + + #ifdef SOURCE_CACHE + /* + * This is copied more or less verbatim from HTParseFile() in HTFormat.c + */ + PRIVATE int HTParseMem ARGS5( + HTFormat, rep_in, + HTFormat, format_out, + HTParentAnchor *, anchor, + HTChunk *, chunk, + HTStream *, sink) + { + HTStream * stream; + HTStreamClass targetClass; + + stream = HTStreamStack(rep_in, format_out, sink, anchor); + if (!stream) { + int rv; + char *buffer = 0; + HTSprintf0(&buffer, CANNOT_CONVERT_I_TO_O, + HTAtom_name(rep_in), HTAtom_name(format_out)); + CTRACE(tfp, "HTFormat(in HTParseMem): %s\n", buffer); + rv = HTLoadError(sink, 501, buffer); + FREE(buffer); + return rv; + } + + /* Shove the data down the stream in one lump. ;) */ + targetClass = *(stream->isa); + (*targetClass.put_block)(stream, chunk->data, chunk->size); + (*targetClass._free)(stream); + return HT_LOADED; + } + + PUBLIC BOOLEAN HTreparse_document NOARGS + { + BOOLEAN ok = FALSE; + + if (!HTMainText || LYCacheSource == SOURCE_CACHE_NONE || + (LYCacheSource == SOURCE_CACHE_FILE && + !HTMainText->source_cache_file) || + (LYCacheSource == SOURCE_CACHE_MEMORY && + !HTMainText->source_cache_chunk)) + return FALSE; + + if (LYCacheSource == SOURCE_CACHE_FILE && HTMainText->source_cache_file) { + FILE * fp; + HTFormat format; + int ret; + + CTRACE(tfp, "Reparsing source cache file %s\n", + HTMainText->source_cache_file); + + /* + * This is more or less copied out of HTLoadFile(), except we don't + * get a content encoding. This may be overkill... + */ + if (HTMainText->node_anchor->content_type) { + format = HTAtom_for(HTMainText->node_anchor->content_type); + } else { + format = HTFileFormat(HTMainText->source_cache_file, NULL, NULL); + format = HTCharsetFormat(format, HTMainText->node_anchor, + UCLYhndl_HTFile_for_unspec); + } + CTRACE(tfp, " Content type is \"%s\"\n", format->name); + + /* + * Pass the source cache filename on to the next HText. Mark it + * NULL here so that it won't get deleted by HText_free(). + */ + source_cache_filename = HTMainText->source_cache_file; + HTMainText->source_cache_file = NULL; + + fp = fopen(source_cache_filename, "r"); + if (!fp) { + CTRACE(tfp, " Cannot read file %s\n", source_cache_filename); + FREE(source_cache_filename); + return FALSE; + } + ret = HTParseFile(format, HTOutputFormat, HTMainText->node_anchor, + fp, NULL); + fclose(fp); + ok = (ret == HT_LOADED); + if (!ok) + FREE(source_cache_filename); + } + + if (LYCacheSource == SOURCE_CACHE_MEMORY && + HTMainText->source_cache_chunk) { + HTFormat format = WWW_HTML; + int ret; + + CTRACE(tfp, "Reparsing from source memory cache %p\n", + (void *)HTMainText->source_cache_chunk); + + /* + * Pass the source cache HTChunk on to the next HText. Clear it + * here so that it won't get deleted by HText_free(). + */ + source_cache_chunk = HTMainText->source_cache_chunk; + HTMainText->source_cache_chunk = NULL; + + ret = HTParseMem(format, HTOutputFormat, HTMainText->node_anchor, + source_cache_chunk, NULL); + ok = (ret == HT_LOADED); + if (!ok) { + HTChunkFree(source_cache_chunk); + source_cache_chunk = NULL; + } + } + + CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); + return ok; + } + + PRIVATE void trace_setting_change ARGS3( + CONST char *, name, + BOOLEAN, prev_setting, + BOOLEAN, new_setting) + { + if (prev_setting != new_setting) + CTRACE(tfp, "HTdocument_settings_changed: %s setting has changed (was %s, now %s)\n", + name, prev_setting ? "ON" : "OFF", new_setting ? "ON" : "OFF"); + } + + PUBLIC BOOLEAN HTdocument_settings_changed NOARGS + { + /* + * Annoying Hack(TM): If we don't have a source cache, we can't + * reparse anyway, so pretend the settings haven't changed. + */ + if (!HTMainText || LYCacheSource == SOURCE_CACHE_NONE || + (LYCacheSource == SOURCE_CACHE_FILE && + !HTMainText->source_cache_file) || + (LYCacheSource == SOURCE_CACHE_MEMORY && + !HTMainText->source_cache_chunk)) + return FALSE; + + if (TRACE) { + /* + * If we're tracing, note everying that has changed. + */ + trace_setting_change("CLICKABLE_IMAGES", + HTMainText->clickable_images, clickable_images); + trace_setting_change("PSEUDO_INLINE_ALTS", + HTMainText->pseudo_inline_alts, + pseudo_inline_alts); + trace_setting_change("RAW_MODE", HTMainText->raw_mode, LYRawMode); + trace_setting_change("HISTORICAL_COMMENTS", + HTMainText->historical_comments, + historical_comments); + trace_setting_change("MINIMAL_COMMENTS", + HTMainText->minimal_comments, minimal_comments); + trace_setting_change("SOFT_DQUOTES", + HTMainText->soft_dquotes, soft_dquotes); + trace_setting_change("OLD_DTD", HTMainText->old_dtd, Old_DTD); + if (HTMainText->lines != LYlines || HTMainText->cols != LYcols) + CTRACE(tfp, + "HTdocument_settings_changed: Screen size has changed (was %dx%d, now %dx%d)\n", + HTMainText->cols, HTMainText->lines, LYcols, LYlines); + } + + return (HTMainText->clickable_images != clickable_images || + HTMainText->pseudo_inline_alts != pseudo_inline_alts || + HTMainText->raw_mode != LYRawMode || + HTMainText->historical_comments != historical_comments || + HTMainText->minimal_comments != minimal_comments || + HTMainText->soft_dquotes != soft_dquotes || + HTMainText->old_dtd != Old_DTD || + HTMainText->lines != LYlines || + HTMainText->cols != LYcols); + } + #endif PUBLIC int HTisDocumentSource NOARGS { *** ./src/HTML.c.orig Wed Mar 17 22:17:11 1999 --- ./src/HTML.c Sun Apr 11 22:37:43 1999 *************** *** 58,63 **** --- 58,67 ---- #define pHText_changeStyle(X,Y,Z) {} #endif + #ifdef SOURCE_CACHE + #include + #endif + #include #include *************** *** 73,79 **** --- 77,90 ---- struct _HTStream { CONST HTStreamClass * isa; + #ifdef SOURCE_CACHE + FILE * fp; + HTChunk * chunk; + CONST HTStreamClass * actions; + HTStream * target; + #else /* .... */ + #endif }; PRIVATE HTStyleSheet * styleSheet = NULL; /* Application-wide */ *************** *** 7300,7305 **** --- 7311,7456 ---- return (HTStructured*) me; } + #ifdef SOURCE_CACHE + /* + * Pass-thru cache HTStream + */ + + PRIVATE void CacheThru_free ARGS1( + HTStream *, me) + { + if (me->fp) + LYCloseTempFP(me->fp); + (*me->actions->_free)(me->target); + FREE(me); + } + + PRIVATE void CacheThru_abort ARGS2( + HTStream *, me, + HTError, e) + { + if (me->fp) + LYCloseTempFP(me->fp); + (*me->actions->_abort)(me->target, e); + FREE(me); + } + + PRIVATE void CacheThru_put_character ARGS2( + HTStream *, me, + char, c_in) + { + if (me->fp) + fputc(c_in, me->fp); + else + HTChunkPutc(me->chunk, c_in); + (*me->actions->put_character)(me->target, c_in); + } + + PRIVATE void CacheThru_put_string ARGS2( + HTStream *, me, + CONST char *, str) + { + if (me->fp) + fputs(str, me->fp); + else + HTChunkPuts(me->chunk, str); + (*me->actions->put_string)(me->target, str); + } + + PRIVATE void CacheThru_write ARGS3( + HTStream *, me, + CONST char *, str, + int, l) + { + if (me->fp) + fwrite(str, 1, l, me->fp); + else + HTChunkPutb(me->chunk, str, l); + (*me->actions->put_block)(me->target, str, l); + } + + PRIVATE CONST HTStreamClass PassThruCache = + { + "PassThruCache", + CacheThru_free, + CacheThru_abort, + CacheThru_put_character, + CacheThru_put_string, + CacheThru_write + }; + + PRIVATE HTStream* CacheThru_new ARGS2( + HTParentAnchor *, anchor, + HTStream *, target) + { + char filename[LY_MAXPATH]; + HTStream *stream = NULL; + HTProtocol *p = (HTProtocol *)anchor->protocol; + + /* + * Neatly and transparently vanish if source caching is disabled. + */ + if (LYCacheSource == SOURCE_CACHE_NONE) + return target; + + if (strcmp(p->name, "http") != 0) { + CTRACE(tfp, "Protocol is \"%s\"; not caching\n", p->name); + return target; + } + + stream = (HTStream *) malloc(sizeof(*stream)); + if (!stream) + outofmem(__FILE__, "CacheThru_new"); + + stream->isa = &PassThruCache; + stream->fp = NULL; + stream->chunk = NULL; + stream->target = target; + stream->actions = target->isa; + + if (LYCacheSource == SOURCE_CACHE_FILE) { + if (source_cache_filename) { + CTRACE(tfp, "Reusing source cache file %s\n", + source_cache_filename); + FREE(stream); + return target; + } + + if (!(stream->fp = LYOpenTemp(filename, HTML_SUFFIX, "w"))) { + CTRACE(tfp, "Cannot get source cache file for URL %s\n", + HTAnchor_address((HTAnchor *)anchor)); + FREE(stream); + return target; + } + + /* + * Yes, this is a Gross And Disgusting Hack(TM), I know... + */ + StrAllocCopy(source_cache_filename, filename); + + CTRACE(tfp, "Caching source for URL %s in file %s\n", + HTAnchor_address((HTAnchor *)anchor), filename); + } + + if (LYCacheSource == SOURCE_CACHE_MEMORY) { + if (source_cache_chunk) { + CTRACE(tfp, "Reusing source memory cache %p\n", + (void *)source_cache_chunk); + FREE(stream); + return target; + } + + /* I think this is right... */ + source_cache_chunk = stream->chunk = HTChunkCreate(128); + CTRACE(tfp, "Caching source for URL %s in memory cache %p\n", + HTAnchor_address((HTAnchor *)anchor), (void *)stream->chunk); + + } + + return stream; + } + #endif + /* HTConverter for HTML to plain text ** ---------------------------------- ** *************** *** 7313,7319 **** --- 7464,7476 ---- HTParentAnchor *, anchor, HTStream *, sink) { + #ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTML_new(anchor, pres->rep_out, sink))); + #else return SGML_new(&HTML_dtd, anchor, HTML_new(anchor, pres->rep_out, sink)); + #endif } /* HTConverter for HTML source to plain text *************** *** 7372,7378 **** --- 7529,7541 ---- } if (!intermediate) return NULL; + #ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTMLGenerator(intermediate))); + #else return SGML_new(&HTML_dtd, anchor, HTMLGenerator(intermediate)); + #endif } /* HTConverter for HTML to C code *************** *** 7397,7403 **** --- 7560,7571 ---- html->comment_start = "/* "; html->comment_end = " */\n"; /* Must start in col 1 for cpp */ /* HTML_put_string(html,html->comment_start); */ + #ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, html)); + #else return SGML_new(&HTML_dtd, anchor, html); + #endif } /* Presenter for HTML *************** *** 7414,7420 **** --- 7582,7594 ---- HTParentAnchor *, anchor, HTStream *, sink GCC_UNUSED) { + #ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTML_new(anchor, WWW_PRESENT, NULL))); + #else return SGML_new(&HTML_dtd, anchor, HTML_new(anchor, WWW_PRESENT, NULL)); + #endif } #endif /* !GUI */ *** ./src/GridText.h.orig Tue Mar 30 12:10:37 1999 --- ./src/GridText.h Sat Apr 10 19:24:50 1999 *************** *** 166,171 **** --- 166,175 ---- char * target)); extern int HTisDocumentSource NOPARAMS; extern void HTuncache_current_document NOPARAMS; + #ifdef SOURCE_CACHE + extern BOOLEAN HTreparse_document NOPARAMS; + extern BOOLEAN HTdocument_settings_changed NOPARAMS; + #endif extern int HText_getTopOfScreen NOPARAMS; extern int HText_getLines PARAMS((HText * text)); extern int HText_getNumOfLines NOPARAMS; *** ./src/LYMainLoop.c.orig Tue Mar 30 12:10:37 1999 --- ./src/LYMainLoop.c Sun Apr 11 20:58:43 1999 *************** *** 1237,1242 **** --- 1237,1262 ---- } } + #ifdef SOURCE_CACHE + /* + * If the parse settings have changed since this HText was + * generated, we need to reparse and redraw it. + */ + if (HTdocument_settings_changed()) { + HTUserMsg(gettext("Reparsing document under current settings...")); + if (HTreparse_document()) + refresh_screen = TRUE; + else { + /* + * Urk. I have no idea how to recover from a failure here. + * At a guess, I'll try reloading. + */ + cmd = LYK_RELOAD; + goto new_cmd; + } + } + #endif + /* * If the curdoc.line is different than Newline then there must * have been a change since last update. Run HText_pageDisplay() *************** *** 2049,2054 **** --- 2069,2080 ---- LYUCPushAssumed(HTMainAnchor); HTOutputFormat = WWW_SOURCE; } + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + #endif LYforce_no_cache = TRUE; FREE(curdoc.address); /* so it doesn't get pushed */ break; *************** *** 2125,2135 **** --- 2151,2163 ---- 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { + #ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; + #endif } if (historical_comments) historical_comments = FALSE; *************** *** 2142,2147 **** --- 2170,2186 ---- HTAlert(historical_comments ? HISTORICAL_ON_VALID_OFF : HISTORICAL_OFF_VALID_ON); } + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; + #endif break; case LYK_MINIMAL: /* toggle 'minimal' comments parsing */ *************** *** 2157,2167 **** --- 2196,2208 ---- 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { + #ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; + #endif } } if (minimal_comments) *************** *** 2175,2180 **** --- 2216,2232 ---- HTAlert(minimal_comments ? MINIMAL_ON_BUT_HISTORICAL : MINIMAL_OFF_HISTORICAL_ON); } + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; + #endif break; case LYK_SOFT_DQUOTES: *************** *** 2189,2199 **** --- 2241,2253 ---- 1, 1) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { + #ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; + #endif } if (soft_dquotes) soft_dquotes = FALSE; *************** *** 2201,2206 **** --- 2255,2271 ---- soft_dquotes = TRUE; HTUserMsg(soft_dquotes ? SOFT_DOUBLE_QUOTE_ON : SOFT_DOUBLE_QUOTE_OFF); + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; + #endif break; case LYK_SWITCH_DTD: *************** *** 2223,2231 **** --- 2288,2298 ---- if (HTisDocumentSource() && LYPreparsedSource) { HTOutputFormat = WWW_SOURCE; } + #ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); + #endif } #ifdef NO_ASSUME_SAME_DOC newdoc.line = 1; *************** *** 2237,2242 **** --- 2304,2318 ---- Old_DTD = !Old_DTD; HTSwitchDTD(!Old_DTD); HTUserMsg(Old_DTD ? USING_DTD_0 : USING_DTD_1); + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + #endif break; #ifdef NOT_DONE_YET *************** *** 5447,5452 **** --- 5523,5534 ---- HTUserMsg(clickable_images ? CLICKABLE_IMAGES_ON : CLICKABLE_IMAGES_OFF); + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + #endif cmd = LYK_RELOAD; goto new_cmd; *************** *** 5458,5463 **** --- 5540,5551 ---- HTUserMsg(pseudo_inline_alts ? PSEUDO_INLINE_ALTS_ON : PSEUDO_INLINE_ALTS_OFF); + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + #endif cmd = LYK_RELOAD; goto new_cmd; *************** *** 5470,5475 **** --- 5558,5569 ---- HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); LYRawMode_flag = LYRawMode; + #ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + #endif cmd = LYK_RELOAD; goto new_cmd; } *** ./src/LYReadCFG.c.orig Tue Mar 30 12:10:37 1999 --- ./src/LYReadCFG.c Sun Apr 11 19:44:41 1999 *************** *** 763,768 **** --- 763,783 ---- return 0; } + #ifdef SOURCE_CACHE + static int source_cache_fun ARGS1( + char *, value) + { + if (!strncasecomp(value, "FILE", 4)) + LYCacheSource = SOURCE_CACHE_FILE; + else if (!strncasecomp(value, "MEM", 3)) + LYCacheSource = SOURCE_CACHE_MEMORY; + else if (!strncasecomp(value, "NONE", 4)) + LYCacheSource = SOURCE_CACHE_NONE; + + return 0; + } + #endif + static int suffix_fun ARGS1( char *, value) { *************** *** 999,1004 **** --- 1014,1022 ---- PARSE_ENV("snewspost_proxy", CONF_ENV, 0 ), PARSE_ENV("snewsreply_proxy", CONF_ENV, 0 ), PARSE_SET("soft_dquotes", CONF_BOOL, soft_dquotes), + #ifdef SOURCE_CACHE + PARSE_SET("source_cache", CONF_FUN, source_cache_fun), + #endif PARSE_STR("startfile", CONF_STR, startfile), PARSE_SET("strip_dotdot_urls", CONF_BOOL, LYStripDotDotURLs), PARSE_SET("substitute_underscores", CONF_BOOL, use_underscore), *** ./src/LYMain.c.orig Tue Mar 30 12:10:37 1999 --- ./src/LYMain.c Sun Apr 11 20:54:19 1999 *************** *** 1556,1561 **** --- 1556,1569 ---- no_multibook = TRUE; } + #ifdef SOURCE_CACHE + /* + * Disable source caching if not interactive. + */ + if (dump_output_immediately) + LYCacheSource = SOURCE_CACHE_NONE; + #endif + #ifdef VMS set_vms_keys(); #endif /* VMS */ *** ./src/LYGlobalDefs.h.orig Thu Mar 4 05:39:45 1999 --- ./src/LYGlobalDefs.h Sun Apr 11 22:24:41 1999 *************** *** 27,32 **** --- 27,36 ---- #define VISITED_LINKS_HELP "keystrokes/visited_help.html" #endif /* LYHELP_H */ + #ifdef SOURCE_CACHE + #include + #endif + #ifdef SOCKS extern BOOLEAN socks_flag; #endif /* SOCKS */ *************** *** 245,250 **** --- 249,262 ---- extern BOOLEAN historical_comments; extern BOOLEAN minimal_comments; extern BOOLEAN soft_dquotes; + #ifdef SOURCE_CACHE + extern char * source_cache_filename; + extern HTChunk * source_cache_chunk; + extern int LYCacheSource; + #define SOURCE_CACHE_NONE 0 + #define SOURCE_CACHE_FILE 1 + #define SOURCE_CACHE_MEMORY 2 + #endif extern BOOLEAN LYCancelDownload; extern BOOLEAN LYRestricted; extern BOOLEAN LYValidate; *** ./configure.in.orig Tue Mar 30 12:10:37 1999 --- ./configure.in Sat Apr 10 00:27:33 1999 *************** *** 567,572 **** --- 567,579 ---- AC_MSG_RESULT($use_alt_bindings) test $use_alt_bindings != no && AC_DEFINE(EXP_ALT_BINDINGS) + AC_MSG_CHECKING(if source caching should be used) + CF_ARG_ENABLE(source-cache, + [ --enable-source-cache cache HTML source for parse mode changes], + [use_source_cache=$enableval], + [use_source_cache=no] + test $use_source_cache != no && AC_DEFINE(SOURCE_CACHE) + AC_MSG_CHECKING(if color-style code should be used) CF_ARG_ENABLE(color-style, [ --enable-color-style use optional/experimental color style], *** ./config.hin.orig Tue Mar 30 12:10:37 1999 --- ./config.hin Sat Apr 10 00:27:33 1999 *************** *** 28,33 **** --- 28,34 ---- #undef EXEC_SCRIPTS /* CF_ARG_ENABLE(exec-scripts) */ #undef EXP_ADDRLIST_PAGE /* CF_ARG_ENABLE(addrlist-page) */ #undef EXP_ALT_BINDINGS /* CF_ARG_ENABLE(alt-bindings) */ + #undef SOURCE_CACHE /* CF_ARG_ENABLE(source-cache) */ #undef EXP_CHARTRANS_AUTOSWITCH /* CF_ARG_ENABLE(font-switch) */ #undef EXP_KEYBOARD_LAYOUT /* CF_ARG_ENABLE(kbd-layout) */ #undef EXP_LIBJS /* CF_ARG_ENABLE(libjs) */ *** ./lynx.cfg.orig Wed Mar 17 22:17:11 1999 --- ./lynx.cfg Sun Apr 11 23:07:34 1999 *************** *** 513,518 **** --- 513,532 ---- #DEFAULT_CACHE_SIZE:10 #DEFAULT_VIRTUAL_MEMORY_SIZE:512000 + # SOURCE_CACHE sets the source caching behavior for Lynx: + # FILE causes Lynx to keep a temporary file for each cached document + # containing the HTML source of the document, which it uses to regenerate + # the document when certain settings are changed (for instance, + # historical vs. minimal vs. valid comment parsing) instead of reloading + # the source from the network. + # MEMORY is like FILE, except the document source is kept in memory. You + # may wish to adjust DEFAULT_CACHE_SIZE and DEFAULT_VIRTUAL_MEMORY_SIZE + # accordingly. + # NONE is the default; the document source is not cached, and is reloaded + # from the network when needed. + # + #SOURCE_CACHE:NONE + # If ALWAYS_RESUBMIT_POSTS is set TRUE, Lynx always will resubmit forms # with method POST, dumping any cache from a previous submission of the # form, including when the document returned by that form is sought with From owner-lynx-dev@sig.net Mon Apr 12 12:36:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA26955 for ; Mon, 12 Apr 1999 12:36:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02707; Mon, 12 Apr 1999 10:33:59 -0500 (CDT) From: dickey@clark.net Message-Id: <199904121533.LAA18025@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 11:33:54 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 12, 99 10:02:51 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 401 Lines: 14 > On Mon, 12 Apr 1999 dickey@clark.net wrote: > > > I (or rather 'patch') cannot make sense of this file. > > No? It's just a straightforward 'diff -c'; it seems to have worked for > Leonid, at least. Could it have gotten munged in the attachment > process? I'll try it again inline. thanks (will try this tonight). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 13:18:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA28351 for ; Mon, 12 Apr 1999 13:18:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA05782; Mon, 12 Apr 1999 12:00:03 -0500 (CDT) Date: Mon, 12 Apr 1999 12:59:52 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 In-Reply-To: <199904121533.LAA18025@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 165 Lines: 8 On Mon, 12 Apr 1999 dickey@clark.net wrote: > thanks (will try this tonight). Actually, I should have the next version of the patch out by then. -sbigham From owner-lynx-dev@sig.net Mon Apr 12 14:23:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA30201 for ; Mon, 12 Apr 1999 14:23:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA28801; Mon, 12 Apr 1999 13:06:03 -0500 (CDT) From: dickey@clark.net Message-Id: <199904121805.OAA12204@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 2 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 14:05:43 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 12, 99 12:59:52 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 501 Lines: 19 > > On Mon, 12 Apr 1999 dickey@clark.net wrote: > > > thanks (will try this tonight). > > Actually, I should have the next version of the patch out by then. this is the only sizable patch I've not incorporated (I ran some test builds on what I had this morning, will do a more complete set tonight to check the various configure options - would have added yours this morning but patch didn't agree). > -sbigham -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 17:26:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA02875 for ; Mon, 12 Apr 1999 17:26:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA17817; Mon, 12 Apr 1999 16:14:05 -0500 (CDT) Message-ID: <19990412151248.E20080@mred.intellistor.com> Date: Mon, 12 Apr 1999 15:12:48 -0600 From: tlhall@royal.net To: lynx-dev@sig.net Subject: Re: lynx-dev ayuda References: <199904110053.TAA25753@roadrunner.sig.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91.1 In-Reply-To: <199904110053.TAA25753@roadrunner.sig.net>; from Alejandro Moraila on Sat, Apr 10, 1999 at 08:51:39PM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1060 Lines: 33 A batch file is a text file with a list of commands that DOS executes one at a time. An example lynx.bat file comes with the archive that has lynx.exe - you should have one. You can edit it with edit.exe or notepad.exe. You can also edit it with wordpad.exe, but be sure to save it as text. If you have a firewall on your LAN, you may need to set up a proxy in lynx.cfg. On Sat, Apr 10, 1999 at 08:51:39PM -0400, Alejandro Moraila wrote: > > Hi my name is alejandro, I'm from Mexico, and,I'm conected with a LAN net, and the file "lynx.exe" say this "alert Unable to conect to remote host", > and "cant access startfile http://linx.browser.org" > I think that the reason is that I didn't create a "Lynx.bat". > I don't know how to create a bat file, and what I put inside of this file. > > Sorry, because my english is very poor. > Thanks > > Moraila Tostado Jesus Alejandro.... > > Mail: > amoraila@mixmail.com > > > ___________________________________________________________ > Consigue tu página web gratuita en http://www.gratisweb.com > From owner-lynx-dev@sig.net Mon Apr 12 17:27:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA02894 for ; Mon, 12 Apr 1999 17:27:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA14695; Mon, 12 Apr 1999 16:06:40 -0500 (CDT) Date: Mon, 12 Apr 1999 17:06:06 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: Lynx Development List Subject: lynx-dev PATCH [dev21]: source caching, take 3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 27984 Lines: 1012 Grmbl... with HTDisplayPartial() defined private in HTFormat.c, I had to move a fair amount of code there from GridText.c; so I'm resubmitting the patch as a replacement again. I've checked this one, and at least on this end, patch -p0 had no problems. This includes fixes for all the problems Leonid found, plus a fix to my configure.in mods (BTW, what version of autoconf are you using, Tom? I've got 2.12, and it choked on the [apparently no longer existent] AC_DIVERT_HELP() macro). I looked over the users' guide, and I really couldn't find any appropriate place to put a mention of this. -sbigham --- ./WWW/Library/Implementation/HTFormat.c.orig Tue Mar 30 12:10:37 1999 +++ ./WWW/Library/Implementation/HTFormat.c Mon Apr 12 11:49:00 1999 @@ -764,6 +764,50 @@ return rv; } +#ifdef SOURCE_CACHE +/* Push data from an HTChunk down a stream +** --------------------------------------- +** +** This routine is responsible for creating and PRESENTING any +** graphic (or other) objects described by the file. +** +** State of memory and target stream on entry: +** HTChunk* (chunk) and target (sink) assumed valid. +** +** Return values: +** HT_LOADED All data sent. +** +** State of memory and target stream on return: +** always chunk unchanged, target stream still valid. +*/ +PUBLIC int HTMemCopy ARGS2( + HTChunk *, chunk, + HTStream *, sink) +{ + HTStreamClass targetClass = *(sink->isa); + int bytes = 0; + CONST char *data = chunk->data; + + HTReadProgress(0, 0); + for (;;) { + /* Push the data down the stream a piece at a time, in case we're + ** running a large document on a slow machine. + */ + int n = INPUT_BUFFER_SIZE; + if (n > chunk->size - bytes) + n = chunk->size - bytes; + if (n == 0) + break; + (*targetClass.put_block)(sink, data, n); + bytes += n; + data += n; + HTReadProgress(bytes, 0); + HTDisplayPartial(); + } + return HT_LOADED; +} +#endif + #ifdef USE_ZLIB /* Push data from a gzip file pointer down a stream ** ------------------------------------- @@ -1025,6 +1069,54 @@ else return HT_LOADED; } + +#ifdef SOURCE_CACHE +/* Parse a document in memory given format and memory block pointer +** +** This routine is responsible for creating and PRESENTING any +** graphic (or other) objects described by the file. +** +** State of memory and target stream on entry: +** HTChunk* (chunk) assumed valid, +** target (sink) usually NULL (will call stream stack). +** +** Return values: +** -501 Stream stack failed (cannot present or convert). +** HT_LOADED All data sent. +** +** Stat of memory and target stream on return: +** always chunk unchanged; target freed, aborted, or NULL. +*/ +PUBLIC int HTParseMem ARGS5( + HTFormat, rep_in, + HTFormat, format_out, + HTParentAnchor *, anchor, + HTChunk *, chunk, + HTStream *, sink) +{ + HTStream * stream; + HTStreamClass targetClass; + int rv; + + stream = HTStreamStack(rep_in, format_out, sink, anchor); + if (!stream) { + char *buffer = 0; + HTSprintf0(&buffer, CANNOT_CONVERT_I_TO_O, + HTAtom_name(rep_in), HTAtom_name(format_out)); + CTRACE(tfp, "HTFormat(in HTParseMem): %s\n", buffer); + rv = HTLoadError(sink, 501, buffer); + FREE(buffer); + return rv; + } + + /* Push the data down the stream + */ + targetClass = *(stream->isa); + rv = HTMemCopy(chunk, stream); + (*targetClass._free)(stream); + return HT_LOADED; +} +#endif #ifdef USE_ZLIB PRIVATE int HTCloseGzFile ARGS1( --- ./WWW/Library/Implementation/HTFormat.h.orig Wed Mar 17 22:17:11 1999 +++ ./WWW/Library/Implementation/HTFormat.h Mon Apr 12 11:42:00 1999 @@ -312,6 +312,22 @@ HTStream* sink)); +#ifdef SOURCE_CACHE +#include +/* + +HTFileCopy: Copy a file to a stream + + This is used by the protocol engines to send data down a stream, typically one which + has been generated by HTStreamStack. It is currently called by HTParseFile + + */ +extern int HTMemCopy PARAMS(( + HTChunk * chunk, + HTStream* sink)); +#endif + + /* HTCopyNoCR: Copy a socket to a stream, stripping CR characters. @@ -376,6 +392,24 @@ HTParentAnchor *anchor, FILE *fp, HTStream* sink)); + +#ifdef SOURCE_CACHE +/* + +HTParseMem: Parse a document in memory + + This routine is called by protocols modules to load an object. uses + HTStreamStack and HTMemCopy. Returns HT_LOADED if successful, can also + return <0 for failure. + + */ +extern int HTParseMem PARAMS(( + HTFormat format_in, + HTFormat format_out, + HTParentAnchor *anchor, + HTChunk* chunk, + HTStream* sink)); +#endif #ifdef USE_ZLIB --- ./src/GridText.c.orig Tue Mar 30 12:10:37 1999 +++ ./src/GridText.c Mon Apr 12 12:26:41 1999 @@ -46,6 +46,10 @@ #undef DEBUG_APPCH +#ifdef SOURCE_CACHE +#include +#endif + #ifdef USE_COLOR_STYLE #include #include @@ -114,6 +118,12 @@ PUBLIC BOOLEAN underline_on = OFF; PUBLIC BOOLEAN bold_on = OFF; +#ifdef SOURCE_CACHE +PUBLIC char * source_cache_filename = NULL; +PUBLIC HTChunk * source_cache_chunk = NULL; +PUBLIC int LYCacheSource = SOURCE_CACHE_NONE; +#endif + #if defined(USE_COLOR_STYLE) #define MAX_STYLES_ON_LINE 64 @@ -173,6 +183,22 @@ */ struct _HText { HTParentAnchor * node_anchor; +#ifdef SOURCE_CACHE + char * source_cache_file; + HTChunk * source_cache_chunk; + /* + * Parse settings when this HText was generated. + */ + BOOLEAN clickable_images; + BOOLEAN pseudo_inline_alts; + BOOLEAN raw_mode; + BOOLEAN historical_comments; + BOOLEAN minimal_comments; + BOOLEAN soft_dquotes; + BOOLEAN old_dtd; + int lines; /* Screen size */ + int cols; +#endif HTLine * last_line; int Lines; /* Number of them */ int chars; /* Number of them */ @@ -483,6 +509,34 @@ self->stale = YES; self->toolbar = NO; self->tabs = NULL; +#ifdef SOURCE_CACHE + /* + * Yes, this is a Gross And Disgusting Hack(TM), I know... + */ + self->source_cache_file = NULL; + if (LYCacheSource == SOURCE_CACHE_FILE && source_cache_filename) { + StrAllocCopy(self->source_cache_file, source_cache_filename); + FREE(source_cache_filename); + } + self->source_cache_chunk = NULL; + if (LYCacheSource == SOURCE_CACHE_MEMORY && source_cache_chunk) { + self->source_cache_chunk = source_cache_chunk; + source_cache_chunk = NULL; + } + + /* + * Remember the parse settings. + */ + self->clickable_images = clickable_images; + self->pseudo_inline_alts = pseudo_inline_alts; + self->raw_mode = LYUseDefaultRawMode; + self->historical_comments = historical_comments; + self->minimal_comments = minimal_comments; + self->soft_dquotes = soft_dquotes; + self->old_dtd = Old_DTD; + self->lines = LYlines; + self->cols = LYcols; +#endif /* * If we are going to render the List Page, always merge in hidden * links to get the numbering consistent if form fields are numbered @@ -729,6 +783,23 @@ HTMainAnchor = NULL; } +#ifdef SOURCE_CACHE + /* + * Clean up the source cache, if any. + */ + if (self->source_cache_file) { + CTRACE(tfp, "Removing source cache file %s\n", + self->source_cache_file); + LYRemoveTemp(self->source_cache_file); + FREE(self->source_cache_file); + } + if (self->source_cache_chunk) { + CTRACE(tfp, "Removing memory source cache %p\n", + (void *)self->source_cache_chunk); + HTChunkFree(self->source_cache_chunk); + } +#endif + FREE(self); } @@ -6189,6 +6260,148 @@ CTRACE(tfp, "HTuncache.. HTMainText already is NULL!\n"); } } + +#ifdef SOURCE_CACHE +PUBLIC BOOLEAN HTreparse_document NOARGS +{ + BOOLEAN ok = FALSE; + + if (!HTMainText || LYCacheSource == SOURCE_CACHE_NONE || + (LYCacheSource == SOURCE_CACHE_FILE && + !HTMainText->source_cache_file) || + (LYCacheSource == SOURCE_CACHE_MEMORY && + !HTMainText->source_cache_chunk)) + return FALSE; + + if (LYCacheSource == SOURCE_CACHE_FILE && HTMainText->source_cache_file) { + FILE * fp; + HTFormat format; + int ret; + + CTRACE(tfp, "Reparsing source cache file %s\n", + HTMainText->source_cache_file); + + /* + * This is more or less copied out of HTLoadFile(), except we don't + * get a content encoding. This may be overkill... + */ + if (HTMainText->node_anchor->content_type) { + format = HTAtom_for(HTMainText->node_anchor->content_type); + } else { + format = HTFileFormat(HTMainText->source_cache_file, NULL, NULL); + format = HTCharsetFormat(format, HTMainText->node_anchor, + UCLYhndl_HTFile_for_unspec); + } + CTRACE(tfp, " Content type is \"%s\"\n", format->name); + + /* + * Pass the source cache filename on to the next HText. Mark it + * NULL here so that it won't get deleted by HText_free(). + */ + source_cache_filename = HTMainText->source_cache_file; + HTMainText->source_cache_file = NULL; + + fp = fopen(source_cache_filename, "r"); + if (!fp) { + CTRACE(tfp, " Cannot read file %s\n", source_cache_filename); + FREE(source_cache_filename); + return FALSE; + } + ret = HTParseFile(format, HTOutputFormat, HTMainText->node_anchor, + fp, NULL); + fclose(fp); + ok = (ret == HT_LOADED); + if (!ok) + FREE(source_cache_filename); + } + + if (LYCacheSource == SOURCE_CACHE_MEMORY && + HTMainText->source_cache_chunk) { + HTFormat format = WWW_HTML; + int ret; + + CTRACE(tfp, "Reparsing from source memory cache %p\n", + (void *)HTMainText->source_cache_chunk); + + /* + * Pass the source cache HTChunk on to the next HText. Clear it + * here so that it won't get deleted by HText_free(). + */ + source_cache_chunk = HTMainText->source_cache_chunk; + HTMainText->source_cache_chunk = NULL; + + ret = HTParseMem(format, HTOutputFormat, HTMainText->node_anchor, + source_cache_chunk, NULL); + ok = (ret == HT_LOADED); + if (!ok) { + HTChunkFree(source_cache_chunk); + source_cache_chunk = NULL; + } + } + + CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); + return ok; +} + +PRIVATE void trace_setting_change ARGS3( + CONST char *, name, + BOOLEAN, prev_setting, + BOOLEAN, new_setting) +{ + if (prev_setting != new_setting) + CTRACE(tfp, "HTdocument_settings_changed: %s setting has changed (was %s, now %s)\n", + name, prev_setting ? "ON" : "OFF", new_setting ? "ON" : "OFF"); +} + +PUBLIC BOOLEAN HTdocument_settings_changed NOARGS +{ + /* + * Annoying Hack(TM): If we don't have a source cache, we can't + * reparse anyway, so pretend the settings haven't changed. + */ + if (!HTMainText || LYCacheSource == SOURCE_CACHE_NONE || + (LYCacheSource == SOURCE_CACHE_FILE && + !HTMainText->source_cache_file) || + (LYCacheSource == SOURCE_CACHE_MEMORY && + !HTMainText->source_cache_chunk)) + return FALSE; + + if (TRACE) { + /* + * If we're tracing, note everying that has changed. + */ + trace_setting_change("CLICKABLE_IMAGES", + HTMainText->clickable_images, clickable_images); + trace_setting_change("PSEUDO_INLINE_ALTS", + HTMainText->pseudo_inline_alts, + pseudo_inline_alts); + trace_setting_change("RAW_MODE", HTMainText->raw_mode, + LYUseDefaultRawMode); + trace_setting_change("HISTORICAL_COMMENTS", + HTMainText->historical_comments, + historical_comments); + trace_setting_change("MINIMAL_COMMENTS", + HTMainText->minimal_comments, minimal_comments); + trace_setting_change("SOFT_DQUOTES", + HTMainText->soft_dquotes, soft_dquotes); + trace_setting_change("OLD_DTD", HTMainText->old_dtd, Old_DTD); + if (HTMainText->lines != LYlines || HTMainText->cols != LYcols) + CTRACE(tfp, + "HTdocument_settings_changed: Screen size has changed (was %dx%d, now %dx%d)\n", + HTMainText->cols, HTMainText->lines, LYcols, LYlines); + } + + return (HTMainText->clickable_images != clickable_images || + HTMainText->pseudo_inline_alts != pseudo_inline_alts || + HTMainText->raw_mode != LYUseDefaultRawMode || + HTMainText->historical_comments != historical_comments || + HTMainText->minimal_comments != minimal_comments || + HTMainText->soft_dquotes != soft_dquotes || + HTMainText->old_dtd != Old_DTD || + HTMainText->lines != LYlines || + HTMainText->cols != LYcols); +} +#endif PUBLIC int HTisDocumentSource NOARGS { --- ./src/HTML.c.orig Wed Mar 17 22:17:11 1999 +++ ./src/HTML.c Mon Apr 12 13:03:29 1999 @@ -58,6 +58,10 @@ #define pHText_changeStyle(X,Y,Z) {} #endif +#ifdef SOURCE_CACHE +#include +#endif + #include #include @@ -73,7 +77,14 @@ struct _HTStream { CONST HTStreamClass * isa; +#ifdef SOURCE_CACHE + FILE * fp; + HTChunk * chunk; + CONST HTStreamClass * actions; + HTStream * target; +#else /* .... */ +#endif }; PRIVATE HTStyleSheet * styleSheet = NULL; /* Application-wide */ @@ -7300,6 +7311,152 @@ return (HTStructured*) me; } +#ifdef SOURCE_CACHE +/* + * Pass-thru cache HTStream + */ + +PRIVATE void CacheThru_free ARGS1( + HTStream *, me) +{ + if (me->fp) + LYCloseTempFP(me->fp); + (*me->actions->_free)(me->target); + FREE(me); +} + +PRIVATE void CacheThru_abort ARGS2( + HTStream *, me, + HTError, e) +{ + if (me->fp) + LYCloseTempFP(me->fp); + (*me->actions->_abort)(me->target, e); + FREE(me); +} + +PRIVATE void CacheThru_put_character ARGS2( + HTStream *, me, + char, c_in) +{ + if (me->fp) + fputc(c_in, me->fp); + else + HTChunkPutc(me->chunk, c_in); + (*me->actions->put_character)(me->target, c_in); +} + +PRIVATE void CacheThru_put_string ARGS2( + HTStream *, me, + CONST char *, str) +{ + if (me->fp) + fputs(str, me->fp); + else + HTChunkPuts(me->chunk, str); + (*me->actions->put_string)(me->target, str); +} + +PRIVATE void CacheThru_write ARGS3( + HTStream *, me, + CONST char *, str, + int, l) +{ + if (me->fp) + fwrite(str, 1, l, me->fp); + else + HTChunkPutb(me->chunk, str, l); + (*me->actions->put_block)(me->target, str, l); +} + +PRIVATE CONST HTStreamClass PassThruCache = +{ + "PassThruCache", + CacheThru_free, + CacheThru_abort, + CacheThru_put_character, + CacheThru_put_string, + CacheThru_write +}; + +PRIVATE HTStream* CacheThru_new ARGS2( + HTParentAnchor *, anchor, + HTStream *, target) +{ + char filename[LY_MAXPATH]; + HTStream *stream = NULL; + HTProtocol *p = (HTProtocol *)anchor->protocol; + + /* + * Neatly and transparently vanish if source caching is disabled. + */ + if (LYCacheSource == SOURCE_CACHE_NONE) + return target; + + if (strcmp(p->name, "http") != 0) { + CTRACE(tfp, "Protocol is \"%s\"; not caching\n", p->name); + return target; + } + + stream = (HTStream *) malloc(sizeof(*stream)); + if (!stream) + outofmem(__FILE__, "CacheThru_new"); + + stream->isa = &PassThruCache; + stream->fp = NULL; + stream->chunk = NULL; + stream->target = target; + stream->actions = target->isa; + + if (LYCacheSource == SOURCE_CACHE_FILE) { + if (source_cache_filename) { + CTRACE(tfp, "Reusing source cache file %s\n", + source_cache_filename); + FREE(stream); + return target; + } + + /* + * We open the temp file in binary mode to make sure that + * end-of-line stuff and high-bit Latin-1 (or other) characters + * don't get munged; this way, the file should (knock on wood) + * contain exactly what came in from the network. + */ + if (!(stream->fp = LYOpenTemp(filename, HTML_SUFFIX, "wb"))) { + CTRACE(tfp, "Cannot get source cache file for URL %s\n", + HTAnchor_address((HTAnchor *)anchor)); + FREE(stream); + return target; + } + + /* + * Yes, this is a Gross And Disgusting Hack(TM), I know... + */ + StrAllocCopy(source_cache_filename, filename); + + CTRACE(tfp, "Caching source for URL %s in file %s\n", + HTAnchor_address((HTAnchor *)anchor), filename); + } + + if (LYCacheSource == SOURCE_CACHE_MEMORY) { + if (source_cache_chunk) { + CTRACE(tfp, "Reusing source memory cache %p\n", + (void *)source_cache_chunk); + FREE(stream); + return target; + } + + /* I think this is right... */ + source_cache_chunk = stream->chunk = HTChunkCreate(128); + CTRACE(tfp, "Caching source for URL %s in memory cache %p\n", + HTAnchor_address((HTAnchor *)anchor), (void *)stream->chunk); + + } + + return stream; +} +#endif + /* HTConverter for HTML to plain text ** ---------------------------------- ** @@ -7313,7 +7470,13 @@ HTParentAnchor *, anchor, HTStream *, sink) { +#ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTML_new(anchor, pres->rep_out, sink))); +#else return SGML_new(&HTML_dtd, anchor, HTML_new(anchor, pres->rep_out, sink)); +#endif } /* HTConverter for HTML source to plain text @@ -7372,7 +7535,13 @@ } if (!intermediate) return NULL; +#ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTMLGenerator(intermediate))); +#else return SGML_new(&HTML_dtd, anchor, HTMLGenerator(intermediate)); +#endif } /* HTConverter for HTML to C code @@ -7397,7 +7566,12 @@ html->comment_start = "/* "; html->comment_end = " */\n"; /* Must start in col 1 for cpp */ /* HTML_put_string(html,html->comment_start); */ +#ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, html)); +#else return SGML_new(&HTML_dtd, anchor, html); +#endif } /* Presenter for HTML @@ -7414,7 +7588,13 @@ HTParentAnchor *, anchor, HTStream *, sink GCC_UNUSED) { +#ifdef SOURCE_CACHE + return CacheThru_new(anchor, + SGML_new(&HTML_dtd, anchor, + HTML_new(anchor, WWW_PRESENT, NULL))); +#else return SGML_new(&HTML_dtd, anchor, HTML_new(anchor, WWW_PRESENT, NULL)); +#endif } #endif /* !GUI */ --- ./src/GridText.h.orig Tue Mar 30 12:10:37 1999 +++ ./src/GridText.h Sat Apr 10 19:24:50 1999 @@ -166,6 +166,10 @@ char * target)); extern int HTisDocumentSource NOPARAMS; extern void HTuncache_current_document NOPARAMS; +#ifdef SOURCE_CACHE +extern BOOLEAN HTreparse_document NOPARAMS; +extern BOOLEAN HTdocument_settings_changed NOPARAMS; +#endif extern int HText_getTopOfScreen NOPARAMS; extern int HText_getLines PARAMS((HText * text)); extern int HText_getNumOfLines NOPARAMS; --- ./src/LYMainLoop.c.orig Tue Mar 30 12:10:37 1999 +++ ./src/LYMainLoop.c Sun Apr 11 20:58:43 1999 @@ -1237,6 +1237,26 @@ } } +#ifdef SOURCE_CACHE + /* + * If the parse settings have changed since this HText was + * generated, we need to reparse and redraw it. + */ + if (HTdocument_settings_changed()) { + HTUserMsg(gettext("Reparsing document under current settings...")); + if (HTreparse_document()) + refresh_screen = TRUE; + else { + /* + * Urk. I have no idea how to recover from a failure here. + * At a guess, I'll try reloading. + */ + cmd = LYK_RELOAD; + goto new_cmd; + } + } +#endif + /* * If the curdoc.line is different than Newline then there must * have been a change since last update. Run HText_pageDisplay() @@ -2049,6 +2069,12 @@ LYUCPushAssumed(HTMainAnchor); HTOutputFormat = WWW_SOURCE; } +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } +#endif LYforce_no_cache = TRUE; FREE(curdoc.address); /* so it doesn't get pushed */ break; @@ -2125,11 +2151,13 @@ 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { +#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; +#endif } if (historical_comments) historical_comments = FALSE; @@ -2142,6 +2170,17 @@ HTAlert(historical_comments ? HISTORICAL_ON_VALID_OFF : HISTORICAL_OFF_VALID_ON); } +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; +#endif break; case LYK_MINIMAL: /* toggle 'minimal' comments parsing */ @@ -2157,11 +2196,13 @@ 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { +#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; +#endif } } if (minimal_comments) @@ -2175,6 +2216,17 @@ HTAlert(minimal_comments ? MINIMAL_ON_BUT_HISTORICAL : MINIMAL_OFF_HISTORICAL_ON); } +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; +#endif break; case LYK_SOFT_DQUOTES: @@ -2189,11 +2241,13 @@ 1, 1) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { +#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; +#endif } if (soft_dquotes) soft_dquotes = FALSE; @@ -2201,6 +2255,17 @@ soft_dquotes = TRUE; HTUserMsg(soft_dquotes ? SOFT_DOUBLE_QUOTE_ON : SOFT_DOUBLE_QUOTE_OFF); +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; +#endif break; case LYK_SWITCH_DTD: @@ -2223,9 +2288,11 @@ if (HTisDocumentSource() && LYPreparsedSource) { HTOutputFormat = WWW_SOURCE; } +#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); +#endif } #ifdef NO_ASSUME_SAME_DOC newdoc.line = 1; @@ -2237,6 +2304,15 @@ Old_DTD = !Old_DTD; HTSwitchDTD(!Old_DTD); HTUserMsg(Old_DTD ? USING_DTD_0 : USING_DTD_1); +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } + HTuncache_current_document(); + StrAllocCopy(newdoc.address, curdoc.address); + FREE(curdoc.address); +#endif break; #ifdef NOT_DONE_YET @@ -5447,6 +5523,12 @@ HTUserMsg(clickable_images ? CLICKABLE_IMAGES_ON : CLICKABLE_IMAGES_OFF); +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } +#endif cmd = LYK_RELOAD; goto new_cmd; @@ -5458,6 +5540,12 @@ HTUserMsg(pseudo_inline_alts ? PSEUDO_INLINE_ALTS_ON : PSEUDO_INLINE_ALTS_OFF); +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } +#endif cmd = LYK_RELOAD; goto new_cmd; @@ -5470,6 +5558,12 @@ HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); LYRawMode_flag = LYRawMode; +#ifdef SOURCE_CACHE + if (HTreparse_document()) { + refresh_screen = TRUE; + break; + } +#endif cmd = LYK_RELOAD; goto new_cmd; } --- ./src/LYReadCFG.c.orig Tue Mar 30 12:10:37 1999 +++ ./src/LYReadCFG.c Sun Apr 11 19:44:41 1999 @@ -763,6 +763,21 @@ return 0; } +#ifdef SOURCE_CACHE +static int source_cache_fun ARGS1( + char *, value) +{ + if (!strncasecomp(value, "FILE", 4)) + LYCacheSource = SOURCE_CACHE_FILE; + else if (!strncasecomp(value, "MEM", 3)) + LYCacheSource = SOURCE_CACHE_MEMORY; + else if (!strncasecomp(value, "NONE", 4)) + LYCacheSource = SOURCE_CACHE_NONE; + + return 0; +} +#endif + static int suffix_fun ARGS1( char *, value) { @@ -999,6 +1014,9 @@ PARSE_ENV("snewspost_proxy", CONF_ENV, 0 ), PARSE_ENV("snewsreply_proxy", CONF_ENV, 0 ), PARSE_SET("soft_dquotes", CONF_BOOL, soft_dquotes), +#ifdef SOURCE_CACHE + PARSE_SET("source_cache", CONF_FUN, source_cache_fun), +#endif PARSE_STR("startfile", CONF_STR, startfile), PARSE_SET("strip_dotdot_urls", CONF_BOOL, LYStripDotDotURLs), PARSE_SET("substitute_underscores", CONF_BOOL, use_underscore), --- ./src/LYMain.c.orig Tue Mar 30 12:10:37 1999 +++ ./src/LYMain.c Sun Apr 11 20:54:19 1999 @@ -1556,6 +1556,14 @@ no_multibook = TRUE; } +#ifdef SOURCE_CACHE + /* + * Disable source caching if not interactive. + */ + if (dump_output_immediately) + LYCacheSource = SOURCE_CACHE_NONE; +#endif + #ifdef VMS set_vms_keys(); #endif /* VMS */ --- ./src/LYGlobalDefs.h.orig Thu Mar 4 05:39:45 1999 +++ ./src/LYGlobalDefs.h Sun Apr 11 22:24:41 1999 @@ -27,6 +27,10 @@ #define VISITED_LINKS_HELP "keystrokes/visited_help.html" #endif /* LYHELP_H */ +#ifdef SOURCE_CACHE +#include +#endif + #ifdef SOCKS extern BOOLEAN socks_flag; #endif /* SOCKS */ @@ -245,6 +249,14 @@ extern BOOLEAN historical_comments; extern BOOLEAN minimal_comments; extern BOOLEAN soft_dquotes; +#ifdef SOURCE_CACHE +extern char * source_cache_filename; +extern HTChunk * source_cache_chunk; +extern int LYCacheSource; +#define SOURCE_CACHE_NONE 0 +#define SOURCE_CACHE_FILE 1 +#define SOURCE_CACHE_MEMORY 2 +#endif extern BOOLEAN LYCancelDownload; extern BOOLEAN LYRestricted; extern BOOLEAN LYValidate; --- ./configure.in.orig Tue Mar 30 12:10:37 1999 +++ ./configure.in Mon Apr 12 15:13:20 1999 @@ -567,6 +567,14 @@ AC_MSG_RESULT($use_alt_bindings) test $use_alt_bindings != no && AC_DEFINE(EXP_ALT_BINDINGS) +AC_MSG_CHECKING(if source caching should be used) +CF_ARG_ENABLE(source-cache, +[ --enable-source-cache cache HTML source for parse mode changes], + [use_source_cache=$enableval], + [use_source_cache=no]) +AC_MSG_RESULT($use_source_cache) +test $use_source_cache != no && AC_DEFINE(SOURCE_CACHE) + AC_MSG_CHECKING(if color-style code should be used) CF_ARG_ENABLE(color-style, [ --enable-color-style use optional/experimental color style], --- ./config.hin.orig Tue Mar 30 12:10:37 1999 +++ ./config.hin Sat Apr 10 00:27:33 1999 @@ -28,6 +28,7 @@ #undef EXEC_SCRIPTS /* CF_ARG_ENABLE(exec-scripts) */ #undef EXP_ADDRLIST_PAGE /* CF_ARG_ENABLE(addrlist-page) */ #undef EXP_ALT_BINDINGS /* CF_ARG_ENABLE(alt-bindings) */ +#undef SOURCE_CACHE /* CF_ARG_ENABLE(source-cache) */ #undef EXP_CHARTRANS_AUTOSWITCH /* CF_ARG_ENABLE(font-switch) */ #undef EXP_KEYBOARD_LAYOUT /* CF_ARG_ENABLE(kbd-layout) */ #undef EXP_LIBJS /* CF_ARG_ENABLE(libjs) */ --- ./lynx.cfg.orig Wed Mar 17 22:17:11 1999 +++ ./lynx.cfg Sun Apr 11 23:07:34 1999 @@ -513,6 +513,20 @@ #DEFAULT_CACHE_SIZE:10 #DEFAULT_VIRTUAL_MEMORY_SIZE:512000 +# SOURCE_CACHE sets the source caching behavior for Lynx: +# FILE causes Lynx to keep a temporary file for each cached document +# containing the HTML source of the document, which it uses to regenerate +# the document when certain settings are changed (for instance, +# historical vs. minimal vs. valid comment parsing) instead of reloading +# the source from the network. +# MEMORY is like FILE, except the document source is kept in memory. You +# may wish to adjust DEFAULT_CACHE_SIZE and DEFAULT_VIRTUAL_MEMORY_SIZE +# accordingly. +# NONE is the default; the document source is not cached, and is reloaded +# from the network when needed. +# +#SOURCE_CACHE:NONE + # If ALWAYS_RESUBMIT_POSTS is set TRUE, Lynx always will resubmit forms # with method POST, dumping any cache from a previous submission of the # form, including when the document returned by that form is sought with From owner-lynx-dev@sig.net Mon Apr 12 17:43:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA03216 for ; Mon, 12 Apr 1999 17:43:55 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA21491; Mon, 12 Apr 1999 16:23:32 -0500 (CDT) Date: Mon, 12 Apr 1999 17:23:21 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: Lynx Development List Subject: lynx-dev [dev21] LYNXCOMPILEOPTS and HAVE_CFG_DEFS_H? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1076 Lines: 31 In the process of testing my source cache mods, I noticed that the LYNXCOMPILEOPTS:/ link on the document information page wasn't working. On investigation, I noticed an apparent inconsistency: in LYShowInfo.c, where the compile options page is implemented, HAVE_CFG_DEFS_H is #define'd manually, according to the settings of HAVE_CONFIG_H and NO_CONFIG_INFO; but there is nothing analogous in LYGetFile.c, where the LYCOMPILEOPTS URL is handled, and HAVE_CFG_DEFS_H doesn't appear to be #define'd by anything else. I fixed it by adding analogous machinery in LYGetFile.c as indicated below, but this seems an odd way to go about it. -sbigham *** LYGetFile.c.orig Tue Mar 30 12:10:37 1999 --- LYGetFile.c Mon Apr 12 15:55:42 1999 *************** *** 38,43 **** --- 38,49 ---- #endif /* SYSLOG_REQUESTED_URLS */ #endif /* !VMS */ + #if defined(HAVE_CONFIG_H) && !defined(NO_CONFIG_INFO) + #define HAVE_CFG_DEFS_H + #else + #undef HAVE_CFG_DEFS_H + #endif + PRIVATE int fix_http_urls PARAMS((document *doc)); extern char * WWW_Download_File; #ifdef VMS From owner-lynx-dev@sig.net Mon Apr 12 17:54:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA03633 for ; Mon, 12 Apr 1999 17:54:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA25385; Mon, 12 Apr 1999 16:33:39 -0500 (CDT) Date: Mon, 12 Apr 1999 15:22:55 +0000 From: jason rayles Subject: lynx-dev Lynx for Macintosh To: lynx-dev@sig.net Message-id: <0FA300JEWF6MHG@mail.megsinet.net> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express for Macintosh - 4.0a (190) Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 291 Lines: 7 Can someone please give me a URL where I can download a version of Lynx for the Mac OS? Every link I've tried gives me a "file not found" error. If no version is currently available, would you please tell me whether Lynx supports tables or not? Thanks, Jason Rayles jasonrayles@hotmail.com From owner-lynx-dev@sig.net Mon Apr 12 17:57:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA03681 for ; Mon, 12 Apr 1999 17:56:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA25902; Mon, 12 Apr 1999 16:35:07 -0500 (CDT) Message-Id: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> X-Sender: jelavich@sfsu.edu X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 12 Apr 1999 12:04:08 -0700 To: lynx-dev@sig.net From: Jennifer Jelavich Subject: lynx-dev Lynx suppport frames? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 844 Lines: 25 Does Lynx currently support Frames? If not, will the new version support Frames? When will this new version be released? If Lynx does/will not support Frames, can you refer me to a software that does support Frames. This is a critical issue at San Francisco State University as we are introducing a new online course management system called "Blackboard" - which is set up in frames. If you could get back to me as soon as possible, I would really appreciate it. Thanks much, Jennifer Jelavich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jennifer Jelavich, Online Teaching Support Specialist The Center for the Enhancement of Teaching San Francisco State University LIB 437, 1600 Holloway Avenue San Francisco, CA 94132 415.338.6906 (Office Phone) 415.338.6489 (FAX) jelavich@sfsu.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-lynx-dev@sig.net Mon Apr 12 18:24:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA04489 for ; Mon, 12 Apr 1999 18:24:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA08517; Mon, 12 Apr 1999 17:09:59 -0500 (CDT) Date: Mon, 12 Apr 1999 17:09:51 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev jumping out? - 'J' Shortcut files In-Reply-To: <199904011518.KAA18800@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1731 Lines: 40 On Thu, 1 Apr 1999, Philip Webb wrote: > 990401 LP & KW debated the meaning/use of jumps files: > > may i start a hare? -- ok, i know March has ended (smile) -- > isn't the whole jumps-file business a piece of antediluviana, > which would be better dropped from present-day Lynx? Actually, now that I've played a bit more with it, I can see that it's useful. 1) It's useful for building menu systems for very inexperiences users (including people who have never touched a computer). It's easier to say "press the 'j' key, then type in 'help', then press the ENTER key", rather than first teaching folks how to navigate among documents ( <- and -> ARE a bit surprising at first). 2) I find it useful also for myself (now that I've finally gone through the troube of creating some shortcut file - not that it's THAT difficult). I have defined some shortcuts I can easily remember. I can now access some links (and lynxprog: actions) more quickly than would be possible if I collected them in a special page (bookmarks file, Index file, or similar). It saves the intermediate steps (load special page, find link, navigate to it) that interrupt the flow of browsing more than necessary (and also push at least one doc out of the cache). So I find shotcut files are a valuable feature. They just aren't well documented in the User Guide, but lynx.cfg and the sample file have enough info to set everything up. (There should be some notes on the syntax for specifying files though, especially since it gets more nonobvious for non-Unix systems.) So Philip, try it before you dump it. Of course if you had a patch to make compilation optional, I guess that would be welcomed. Klaus From owner-lynx-dev@sig.net Mon Apr 12 18:46:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA04987 for ; Mon, 12 Apr 1999 18:46:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA12321; Mon, 12 Apr 1999 17:21:33 -0500 (CDT) From: mattack@area.com Date: Mon, 12 Apr 1999 15:21:25 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx suppport frames? In-Reply-To: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1426 Lines: 30 On Mon, 12 Apr 1999, Jennifer Jelavich wrote: >Does Lynx currently support Frames? If not, will the new version support >Frames? When will this new version be released? Lynx supports frames, but in a different way than other (in other words, GUI) browsers do it. In Lynx, you only see the content of one frame at a time. When there is a page with multiple frames on it, you see a list of the different frames, and then you can choose the link for each specific frame and "enter" it just like you would choose any other link. This *sounds* very complicated, and it is more complex than seeing all of the frames at once, but in actual everyday use, it is not that big of a deal, since most of the time there are "header" and "footer" frames that sites use, that don't contain very much useful information. Usually the "content" frame has all of the (in my opinion) important stuff in it, so it is in effect only one more step than using frames with other browsers. >If Lynx does/will not support Frames, can you refer me to a software that >does support Frames. Well, Netscape and Internet Explorer support frames, as does my favorite browser besides Lynx -- iCab.. www.icab.de It's a Mac-only browser, and I have no connection to them except as a user. I'm only mentioning it because it's a GUI browser that's *almost* as fast a Lynx. (And far far faster than IE or Netscape running on the same hardware.) From owner-lynx-dev@sig.net Mon Apr 12 19:24:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA06118 for ; Mon, 12 Apr 1999 19:24:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA25772; Mon, 12 Apr 1999 18:08:36 -0500 (CDT) From: dickey@clark.net Message-Id: <199904122308.TAA01933@shell.clark.net> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 3 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 19:08:32 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 12, 99 05:06:06 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 851 Lines: 21 > Grmbl... with HTDisplayPartial() defined private in HTFormat.c, I had to > move a fair amount of code there from GridText.c; so I'm resubmitting > the patch as a replacement again. I've checked this one, and at least > on this end, patch -p0 had no problems. patch got confused, I think, due to the similar chunks interwoven with Vlad's patch. I merged a copy by hand > This includes fixes for all the problems Leonid found, plus a fix to my > configure.in mods (BTW, what version of autoconf are you using, Tom? > I've got 2.12, and it choked on the [apparently no longer existent] look on my webpage for autoconf patches. > AC_DIVERT_HELP() macro). I looked over the users' guide, and I really > couldn't find any appropriate place to put a mention of this. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 19:31:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA06175 for ; Mon, 12 Apr 1999 19:31:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA26090; Mon, 12 Apr 1999 18:09:56 -0500 (CDT) From: dickey@clark.net Message-Id: <199904122309.TAA02014@shell.clark.net> Subject: Re: lynx-dev [dev21] LYNXCOMPILEOPTS and HAVE_CFG_DEFS_H? To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 19:09:52 -0400 (EDT) In-Reply-To: from "Scott Bigham " at Apr 12, 99 05:23:21 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 845 Lines: 19 > In the process of testing my source cache mods, I noticed that the > LYNXCOMPILEOPTS:/ link on the document information page wasn't working. > On investigation, I noticed an apparent inconsistency: in LYShowInfo.c, > where the compile options page is implemented, HAVE_CFG_DEFS_H is > #define'd manually, according to the settings of HAVE_CONFIG_H and > NO_CONFIG_INFO; but there is nothing analogous in LYGetFile.c, where the > LYCOMPILEOPTS URL is handled, and HAVE_CFG_DEFS_H doesn't appear to be > #define'd by anything else. I fixed it by adding analogous machinery in > LYGetFile.c as indicated below, but this seems an odd way to go about > it. LP already sent a patch (it's in dev.22, which I'll put out once I've checked over your current patch). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 12 21:05:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA08877 for ; Mon, 12 Apr 1999 21:05:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA20807; Mon, 12 Apr 1999 19:55:47 -0500 (CDT) Date: Mon, 12 Apr 1999 17:55:38 -0700 From: David Combs To: lynx-dev@sig.net Subject: Re: lynx-dev Information Message-ID: <19990412175538.A3330@netcom18.netcom.com> References: <199904111031.LAA05894@djwhome.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904111031.LAA05894@djwhome.demon.co.uk>; from David Woolley on Sun, Apr 11, 1999 at 11:31:37AM +0100 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 765 Lines: 18 On Sun, Apr 11, 1999 at 11:31:37AM +0100, David Woolley wrote: > > Can I download Lynx exe(Unix) from the InterNet.If yes pls tell me > > from which Site. > > ... > (Normally one says "binary" for Unix, just possibly "executables", but > "exe" comes from Microsoft's naming conventions and would imply DOS or > Windows if you hadn't qualified it.) Well, some of us came from the dec10&20 world where, as I recall, executables were .exe-files, and that term over time got hardwired into our brains. (The dec20 had an operating usually known as "twenex", super-good, and was the one that the seeming-"children" who came in to do the vax vms system seemingly refused to look at, started from a blank sheet of paper, and gave us vms --- and now, I guess, NT. :-( From owner-lynx-dev@sig.net Mon Apr 12 22:13:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA10536 for ; Mon, 12 Apr 1999 22:13:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA05867; Mon, 12 Apr 1999 21:02:01 -0500 (CDT) Date: Mon, 12 Apr 1999 19:01:54 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: lynx-dev rsaref for SSL enabled lynx? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 956 Lines: 21 RSA posted a notice on their ftp site on 2 April 1999 that rsaref is no longer available for download. This may make it difficult for any US citizens who don't already have a copy of this to build a legal SSL-enabled lynx. Does anyone know if rsaref is still available by email, even though not by ftp? Is there another site where a copy of rsaref can legally be obtained by a US citizen? None of this applies where the software patent is not recognized, outside the US. The RSA code in SSLeay should work fine. I've read through the rsaref license and documentation a few times. It is still not clear to me whether or not I can make a copy of the rsaref package for someone who agrees to the redistribution limitations and is qualified by reason of location and citizenship to receive it. Is this clear to anyone else on the list? Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Mon Apr 12 22:40:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA11427 for ; Mon, 12 Apr 1999 22:40:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12469; Mon, 12 Apr 1999 21:29:14 -0500 (CDT) From: Philip Webb Message-Id: <199904130229.WAA16596@chass.utoronto.ca> Subject: Re: lynx-dev PATCH [dev21]: source caching, take 3 To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 22:29:08 -0400 (EDT) In-Reply-To: from "Scott Bigham" at Apr 12, 99 05:06:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 846 Lines: 19 990412 Scott Bigham wrote: > I looked over the users' guide, and I really couldn't find > any appropriate place to put a mention of this. it's on page 6: search for "Lynx renders HTML files and saves the rendition, not the source" & read that paragraph, which will now be inaccurate with your patch. you're the best person to re-write the text, as you know exactly what your patch can/cannot do: make it brief but accurate advice for the ordinary joe/jill out there. and you deserve lots of thanks from everyone for so competently filling a very long felt want ... (smile) -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Mon Apr 12 23:45:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA13278 for ; Mon, 12 Apr 1999 23:45:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA27766; Mon, 12 Apr 1999 22:35:07 -0500 (CDT) From: Philip Webb Message-Id: <199904130335.XAA20829@chass.utoronto.ca> Subject: lynx-dev patch: jumps help (was jumping out) To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 23:35:02 -0400 (EDT) In-Reply-To: from "Klaus Weide" at Apr 12, 99 05:09:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3608 Lines: 75 990412 KW caught my hare, tho' much less quickly than a whippet (grin): > 990401 Philip Webb wrote: >> may i start a hare? -- ok, i know March has ended (smile) -- >> isn't the whole jumps-file business a piece of antediluviana, >> which would be better dropped from present-day Lynx? > now I've played a bit more with it, I can see that it's useful. -- details snipped -- > shortcut files just aren't well documented in the User Guide -- snip -- yes, your description makes sense of it & much of the problem is that it was badly documented some time back in the Age of Giants. below is a patch for Users Guide which should improve things & yes i know it's full of
's, but they make the rendered version neater & easier to read using Lynx for the vast majority of users. please read it with Lynx ... *** old/Lynx_users_guide.html Mon Apr 12 22:49:29 1999 --- new/Lynx_users_guide.html Mon Apr 12 23:17:51 1999 *************** *** 1032,1050 ****

Jump Command

! A feature similar to the Lynx bookmarks is the jump command. The jump ! command allows you to enter a shortcut name to access a URL. If the jump ! feature is active, typing 'j' will produce a prompt where you may ! enter the shortcut name. Type '?' at the jump prompt for a list ! of shortcut names available. !

All jump shortcut entries are saved in a circular buffer, and any ! previous entries can be retrieved for re-use by pressing the ! up-arrow or down-arrow keys at the prompt. !

Note to System Administrators: ! Read the lynx.cfg file on how ! to set up the jump command for your system and how to define shortcut names. [ToC]

Directory Editing

--- 1032,1060 ----

Jump Command

! Similar to the bookmarks file is the jumps file: for an example,
! look in the samples subdirectory in the distribution package.
! To use the jumps command, create a jumps file with the same format
! as the sample file, but containing your own URLs & short-cut names.
! Once you have done that, typing 'j' prompts you to enter
! a short-cut name, which will take you straight to the URL
! associated with the short-cut in the jumps file, ! much like using 'g' .
! If you want to check which short-cuts are available,
! type '?' at the jump prompt for the full list.

! All jump short-cuts you have entered are saved in a circular buffer
! in the same way as with 'g' and '/' (search):
! previous entries can be retrieved with up-arrow ! or down-arrow.

! The jumps feature is especially useful for system administrators
! who have unsophisticated users to care for, but ordinary Lynx users
! who have a number of URLs they regularly visit while browsing
! may find using the jumps command speeds their movements.

! ! For more advice how to set up the jumps command on your system
! and how to define short-cut names, read lynx.cfg . [ToC]

Directory Editing

-- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 00:46:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA14793 for ; Tue, 13 Apr 1999 00:46:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA09866; Mon, 12 Apr 1999 23:37:25 -0500 (CDT) From: Philip Webb Message-Id: <199904130437.AAA24017@chass.utoronto.ca> Subject: lynx-dev trying to jump in ... To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 00:37:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1237 Lines: 27 KW having explained how simple the jumps command is, i thought i'ld have a go, as it would help when looking up the OED. i have created a file /homes/purslow/ltest/lynx2-8-2/jumps.html on this IRIX 5.3 system, which is a copy of the sample jumps file, with the ? line updated & a line added for the OED; lynx.cfg says JUMPFILE:file://localhost/homes/purslow/ltest/lynx2-8-2/jumps.html unfortunately, Lynx 2-8-2dev.19 keeps telling me `Alert! Cannot locate jump file!' , even after a restart ; if i use g to goto the above URL, the jumps file renders correctly. Lynx trace gives nothing; strace gives the following lines: read(0, "j", 1) = 1 xstat(2, "file", 0x7fff9fa0) = -1 ENOENT (No such file or directory) ioctl(0, 0x4004667f, [0]) = 0 ioctl(0, 0x4004667f, [0]) = 0 write(1, "\rAlert!: Cannot locate jump fil"..., 58) = 58 no doubt i'm overlooking something very simple, but what ... ? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 00:49:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA14851 for ; Tue, 13 Apr 1999 00:49:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA10610; Mon, 12 Apr 1999 23:42:09 -0500 (CDT) Date: Mon, 12 Apr 1999 21:42:01 -0700 (PDT) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: Re: lynx-dev trying to jump in ... In-Reply-To: <199904130437.AAA24017@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 947 Lines: 25 *** Philip Webb (purslow@chass.utoronto.ca) wrote on Apr 13, 1999: :) KW having explained how simple the jumps command is, :) i thought i'ld have a go, as it would help when looking up the OED. :) i have created a file /homes/purslow/ltest/lynx2-8-2/jumps.html :) on this IRIX 5.3 system, which is a copy of the sample jumps file, :) with the ? line updated & a line added for the OED; lynx.cfg says :) :) JUMPFILE:file://localhost/homes/purslow/ltest/lynx2-8-2/jumps.html :) :) unfortunately, Lynx 2-8-2dev.19 keeps telling me :) `Alert! Cannot locate jump file!' , even after a restart ; :) if i use g to goto the above URL, the jumps file renders correctly. :) Write in your jumps file (as one line, here it's artificially cut to fit the line)
?
This Shortcut List Hope this helps,Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Tue Apr 13 01:12:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA15426 for ; Tue, 13 Apr 1999 01:12:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA13591; Tue, 13 Apr 1999 00:02:47 -0500 (CDT) Date: Tue, 13 Apr 1999 14:13:59 +0900 (JST) From: Henry Nelson Message-Id: <199904130513.OAA12441@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev patch: jumps help (was jumping out) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 323 Lines: 8 > & yes i know it's full of
's, but they make the rendered version > neater & easier to read using Lynx for the vast majority of users. All those
's don't make a bit of sense to me. What's the point of html? If you absolutely need that kind of formating, you should do it all within
 blocks, IMHO.

__Henry

From owner-lynx-dev@sig.net  Tue Apr 13 01:23:45 1999
Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA15686
	for ; Tue, 13 Apr 1999 01:23:44 -0400
Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA14960; Tue, 13 Apr 1999 00:13:21 -0500 (CDT)
Date: Tue, 13 Apr 1999 14:24:44 +0900 (JST)
From: Henry Nelson 
Message-Id: <199904130524.OAA12490@ibr1.irm.nara.kindai.ac.jp>
To: lynx-dev@sig.net
Subject: Re: lynx-dev trying to jump in ...
Sender: owner-lynx-dev@sig.net
Precedence: bulk
Reply-To: lynx-dev@sig.net
Status: RO
Content-Length: 354
Lines: 13

> with the  ?  line updated & a line added for the OED;  lynx.cfg  says
> 
> JUMPFILE:file://localhost/homes/purslow/ltest/lynx2-8-2/jumps.html

Try:
	JUMPFILE:./ltest/lynx2-8-2/jumps.html

In the distribution lynx.cfg file, there are the instructions:
# Do not include "file://localhost" in the definition.
[...]
#JUMPFILE:/Lynx_Dir/jumps.html

__Henry

From owner-lynx-dev@sig.net  Tue Apr 13 03:10:34 1999
Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA18803
	for ; Tue, 13 Apr 1999 03:10:33 -0400
Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA26098; Tue, 13 Apr 1999 01:52:53 -0500 (CDT)
From: David Woolley 
Message-Id: <199904120737.IAA07982@djwhome.demon.co.uk>
Subject: Re: path: revised lynx-dev.html
To: lynx-dev@sig.net
Date: Mon, 12 Apr 1999 08:37:53 +0100 (BST)
In-Reply-To: <199904112217.SAA24544@chass.utoronto.ca> from "Philip Webb" at Apr 11, 99 06:17:20 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-lynx-dev@sig.net
Precedence: bulk
Reply-To: lynx-dev@sig.net
Status: RO
Content-Length: 765
Lines: 17

> (3) 
is a perfectly valid item in HTML for authors to use when they want: Which causes problems for style sheets, as there is no way to represent it in a style sheet. > if most people use it less often, > that may be because they are untidy or thoughtless; Normally I see excess use of
in GUI pages where the authors are so thoughtless as to not understand that HTML has a paragraph construct. I think it is very bad for Lynx help files to demonstrate the sort of bad style that in other contexts makes pages difficult to read under Lynx. HTML is not a page description language, and, except in verse, newlines are not significant to the structure of body text, so should be left to the browser to insert according to the user's policies. From owner-lynx-dev@sig.net Tue Apr 13 03:12:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA18813 for ; Tue, 13 Apr 1999 03:12:43 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA26103; Tue, 13 Apr 1999 01:52:54 -0500 (CDT) From: Philip Webb Message-Id: <199904130652.CAA27951@chass.utoronto.ca> Subject: lynx-dev patch: lynx.cfg (was jumping) To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 02:52:49 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3823 Lines: 91 990413 Henry Nelson recommended: > JUMPFILE:./ltest/lynx2-8-2/jumps.html > In the distribution lynx.cfg file, there are the instructions: > # Do not include "file://localhost" in the definition. > [...] #JUMPFILE:/Lynx_Dir/jumps.html the following don't work: JUMPFILE:/ltest/lynx2-8-2/jumps.html JUMPFILE:./ltest/lynx2-8-2/jumps.html JUMPFILE:~/ltest/lynx2-8-2/jumps.html the next one does: JUMPFILE:/homes/purslow/ltest/lynx2-8-2/jumps.html this is bizarre: is there anywhere else where the full file://... doesn't work nor does simply ~... , but the spelled-out local-system path does? anyway, yet another oldie among the documentation: lynx.cfg patch below. *** old/lynx.cfg Fri Mar 5 14:47:43 1999 --- new/lynx.cfg Tue Apr 13 02:41:37 1999 *************** *** 82,111 **** # #JUMP_PROMPT:Jump to (use '?' for list): ! # JUMPFILE is the default local file checked for shortcut URLs when ! # the user presses the 'J' (JUMP) key. The user will be prompted for ! # a shortcut entry (analogously to 'g'oto), and can enter one ! # or use '?' for a list of the shortcuts with associated links to ! # their actual URLs. See the jumps files in the lynx*/samples ! # subdirectory. Make sure your jumps file includes a '?' shortcut ! # for a file://localhost URL to itself: # #
?
This Shortcut List # - # If not defined here or in userdefs.h, the JUMP command will invoke - # the NO_JUMPFILE statusline message (see userdefs.h). - # # On VMS, use Unix SHELL syntax (including a lead slash) to define it. # ! # Do not include "file://localhost" in the definition. ! # ! # Additional alternate jumps files can be defined and mapped to ! # keystrokes at the bottom of lynx.cfg, but you should first define ! # the default jumps file (mapped by default to 'J', and to 'j' when ! # the "VI keys" 'o'ption is not ON) here or in userdefs.h, if you ! # wish to implement the jumps mechanism. ! # ! #JUMPFILE:/Lynx_Dir/jumps.html # Set JUMPBUFFER to TRUE if you want to have the previous jump target, # if any, offered for reuse or editing when using the 'J'ump command. --- 82,109 ---- # #JUMP_PROMPT:Jump to (use '?' for list): ! # JUMPFILE is the local file checked for short-cut names for URLs ! # when the user presses the 'j' (JUMP) key. The user will be prompted ! # to enter a short-cut name for an URL, which Lynx will then follow ! # in a similar manner to 'g'oto; alternatively, s/he can enter '?' ! # to view the full JUMPFILE list of short-cuts with associated URLs. ! # There is an example jumps file in the samples subdirectory. ! # If not defined here or in userdefs.h , the JUMP command will invoke ! # the NO_JUMPFILE statusline message (cp LYMessages_en.h ). # + # To allow '?' to work, include in the JUMPFILE + # a short-cut to the JUMPFILE itself, e.g. #
?
This Shortcut List # # On VMS, use Unix SHELL syntax (including a lead slash) to define it. # ! # Additional jumps files can be defined and mapped to keystrokes ! # in lynx.cfg , but you should first define the default jumps file, ! # which is mapped by default to 'j' (or 'J' when VI keys are ON). ! # ! # In the following line, include the actual full local path to JUMPFILE, ! # but do not include 'file://localhost' in the line. ! #JUMPFILE:/FULL_LOCAL_PATH/jumps.html # Set JUMPBUFFER to TRUE if you want to have the previous jump target, # if any, offered for reuse or editing when using the 'J'ump command. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 03:13:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA18820 for ; Tue, 13 Apr 1999 03:13:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA25456; Tue, 13 Apr 1999 01:46:35 -0500 (CDT) To: lynx-dev@sig.net References: <199904122308.TAA01933@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 10:40:04 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2182 Lines: 56 12-Apr-99 19:08 dickey@clark.net wrote: >> Grmbl... with HTDisplayPartial() defined private in HTFormat.c, I had to >> move a fair amount of code there from GridText.c; so I'm resubmitting >> the patch as a replacement again. I've checked this one, and at least >> on this end, patch -p0 had no problems. > patch got confused, I think, due to the similar chunks interwoven with > Vlad's patch. I merged a copy by hand Think we should wait a little until dev22 will be out since several people are out of sync while submitting patches these days over and over. One more problem with SOURCE_CACHE code found: when you are toggling to "\" source mode and then _immediately_ go to any internal page ("=" Info or "<-" History, etc.) that next page got in source mode also. Mistake. (well, I comment out the check for "http" and do my testing locally: actually I run O)ptions menu, press "\" and then press "="). Seems HTOutputFormat will not restored after SOURCE_CHACHE operations, I mention one thing: LYUCPopAssumed() used in HTLoad() cycle but obviously lost in Cache_Thrue... code. No chartrans problems, though. More discussion after dev22 out. > --- ./src/LYMainLoop.c.orig Tue Mar 30 12:10:37 1999 > +++ ./src/LYMainLoop.c Sun Apr 11 20:58:43 1999 > @@ -2049,6 +2069,12 @@ > LYUCPushAssumed(HTMainAnchor); > HTOutputFormat = WWW_SOURCE; > } > +#ifdef SOURCE_CACHE > + if (HTreparse_document()) { > + refresh_screen = TRUE; > + break; > + } > +#endif > LYforce_no_cache = TRUE; > FREE(curdoc.address); /* so it doesn't get pushed */ > break; > @@ -2125,11 +2151,13 @@ > 0, 0) == FALSE) { > HTInfoMsg(WILL_NOT_RELOAD_DOC); > } else { > +#ifndef SOURCE_CACHE > HTuncache_current_document(); > StrAllocCopy(newdoc.address, curdoc.address); > FREE(curdoc.address); > newdoc.line = curdoc.line; > newdoc.link = curdoc.link; > +#endif > } > if (historical_comments) > historical_comments = FALSE; From owner-lynx-dev@sig.net Tue Apr 13 03:13:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA18827 for ; Tue, 13 Apr 1999 03:13:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA26116; Tue, 13 Apr 1999 01:52:58 -0500 (CDT) From: David Woolley Message-Id: <199904120748.IAA08001@djwhome.demon.co.uk> Subject: Re: lynx-dev ayuda To: lynx-dev@sig.net Date: Mon, 12 Apr 1999 08:48:42 +0100 (BST) Cc: amoraila@mixmail.com In-Reply-To: from "Doug Kaufman" at Apr 11, 99 10:46:51 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 381 Lines: 10 > > On Sun, 11 Apr 1999, David Woolley wrote: > > > The Win32 versions don't need a .bat file creating. > > The Win32 version DOES need a batch file to set up the environment All the Win32 versions I've used have worked without *creating* a batch file, although one may have been installed from the distribution. It's possible that mail breaks without one, but browsing is OK. From owner-lynx-dev@sig.net Tue Apr 13 04:13:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA21096 for ; Tue, 13 Apr 1999 04:13:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA00404; Tue, 13 Apr 1999 02:33:40 -0500 (CDT) To: lynx-dev@sig.net References: <199904130652.CAA27951@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 11:26:46 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev patch: lynx.cfg (was jumping) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 823 Lines: 25 13-Apr-99 02:52 Philip Webb wrote: > 990413 Henry Nelson recommended: >> JUMPFILE:./ltest/lynx2-8-2/jumps.html >> In the distribution lynx.cfg file, there are the instructions: >> # Do not include "file://localhost" in the definition. >> [...] #JUMPFILE:/Lynx_Dir/jumps.html > the following don't work: > JUMPFILE:/ltest/lynx2-8-2/jumps.html > JUMPFILE:./ltest/lynx2-8-2/jumps.html > JUMPFILE:~/ltest/lynx2-8-2/jumps.html > the next one does: > JUMPFILE:/homes/purslow/ltest/lynx2-8-2/jumps.html > this is bizarre: is there anywhere else > where the full file://... doesn't work nor does simply ~... , > but the spelled-out local-system path does? Yet another case (also HELPFILE, COOKIE_FILE, lynx_cfg_file, etc?) where we should use a single function to expand tilde to $HOME when we are talking local file. From owner-lynx-dev@sig.net Tue Apr 13 04:21:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA21297 for ; Tue, 13 Apr 1999 04:21:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA00891; Tue, 13 Apr 1999 02:38:40 -0500 (CDT) From: Philip Webb Message-Id: <199904130738.DAA28948@chass.utoronto.ca> Subject: lynx-dev jumping around To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 03:38:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 644 Lines: 13 yes, once you see what it really does, jump is a useful command. however, one nuisance: as it says, you must keep the entries alphabetical or Lynx can't find them, but that creates problems if you want to include quickies like `.', which must be placed before `?', not after, & both must be placed before `aardvark'. is there a reason for this? is there a good reason ... ? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 04:35:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA21502 for ; Tue, 13 Apr 1999 04:35:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA02037; Tue, 13 Apr 1999 02:48:59 -0500 (CDT) Date: Tue, 13 Apr 1999 00:48:54 -0700 (PDT) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: Re: lynx-dev jumping around In-Reply-To: <199904130738.DAA28948@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 686 Lines: 18 *** Philip Webb (purslow@chass.utoronto.ca) wrote Today: :) yes, once you see what it really does, jump is a useful command. :) however, one nuisance: as it says, you must keep the entries alphabetical :) or Lynx can't find them, but that creates problems if you want to include :) quickies like `.', which must be placed before `?', not after, :) & both must be placed before `aardvark'. :) :) is there a reason for this? is there a good reason ... ? :) My jumps file is pretty much unsorted and it works perfectly well from the prompt (?,search, seminars, library,check-mail, mail, files, Graduate program etc...) Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Tue Apr 13 05:25:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA22596 for ; Tue, 13 Apr 1999 05:25:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA08024; Tue, 13 Apr 1999 03:54:45 -0500 (CDT) From: Philip Webb Message-Id: <199904130854.EAA00855@chass.utoronto.ca> Subject: Re: lynx-dev jumping around To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 04:54:40 -0400 (EDT) In-Reply-To: from "Eduardo Chappa L." at Apr 13, 99 00:48:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1615 Lines: 32 990413 Eduardo Chappa wrote: > 990413 Philip Webb wrote: >> however, one nuisance: as it says, you must keep the entries alphabetical >> or Lynx can't find them, but that creates problems if you want to include >> quickies like `.', which must be placed before `?', not after, >> & both must be placed before `aardvark'. > My jumps file is pretty much unsorted and it works perfectly well > from the prompt (?, search, seminars, library, check-mail, > mail, files, Graduate program etc...) well, i just tested it with very simple short-cuts: . ? a i o w y ; that's ok, but if i order them . ? a o i w y , Lynx can't find i , tho' it can find all the others. another glitch: you have to restart Lynx to get a revised jump list, even if you do a ? & ^r first: the revised list is rendered, but the old short-cuts are still the ones recognised: eg if you go off & edit the short-cut `archive' to `a', `archive' is still found, but `a' gets an error message. this has to be wrong: surely Lynx should revise the list after ^r . this is a real PITA for those of us who run Lynx under Screen, where it can remain active with cookie choices, passwords & search patterns all remaining available for weeks (and > 1 K Visited Links ... ). it seems Jump is a useful bit of heritage, which no-one has really explored for a long time (thanx KW). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 06:02:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA23470 for ; Tue, 13 Apr 1999 06:02:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA20926; Tue, 13 Apr 1999 04:21:29 -0500 (CDT) From: Philip Webb Message-Id: <199904130921.FAA01410@chass.utoronto.ca> Subject: Re: lynx-dev jumping around To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 05:21:26 -0400 (EDT) In-Reply-To: <199904130738.DAA28948@chass.utoronto.ca> from "Philip Webb" at Apr 13, 99 03:38:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 939 Lines: 19 and another one: i have an URL in my bookmark file & now jumps file http://www.tor.ec.gc.ca/forecasts/forecast.cgi?city=Toronto&province=Ontario (of course, it's in the proper anchor setting). when i use the bookmark or jumps listing, there's no problem; when i enter j then w (the short-cut), i get a screen telling me i haven't entered the full URL: it seems to be www.tor.ec.gc.ca/ only; even stranger, = tells me i have reached the proper destination, which is a simple Toronto weather outline & forecast. why does j not goto the site, when ACTIVATE does? why does = tell me i've got there, when i haven't? as before, Lynx2-8-2dev.19 on IRIX 5.3 . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 06:10:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA23710 for ; Tue, 13 Apr 1999 06:10:57 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA09227; Tue, 13 Apr 1999 04:07:15 -0500 (CDT) From: dickey@clark.net Message-Id: <199904130907.FAA14247@shell.clark.net> Subject: Re: lynx-dev patch: lynx.cfg (was jumping) To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 05:07:11 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 13, 99 11:26:46 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 496 Lines: 15 > > this is bizarre: is there anywhere else > > where the full file://... doesn't work nor does simply ~... , > > but the spelled-out local-system path does? > > Yet another case (also HELPFILE, COOKIE_FILE, lynx_cfg_file, etc?) > where we should use a single function to expand tilde to $HOME > when we are talking local file. yes (not all of the pathname code has been neatly collected into utility functions). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 06:19:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA23919 for ; Tue, 13 Apr 1999 06:19:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA23324; Tue, 13 Apr 1999 04:50:05 -0500 (CDT) From: dickey@clark.net Message-Id: <199904130950.FAA17280@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.22 To: lynx-dev@sig.net (Lynx Development) Date: Tue, 13 Apr 1999 05:50:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6969 Lines: 103 1999-04-13 (2.8.2dev.22) * correct a missing include for LYLeaks.h in UCAuto.c - TD * implement HTML source caching. In this implementation, each document kept in cache has associated with it a temporary file containing the HTML source for the document (well, not all of them -- only those using the HTTP protocol, on the premise that file:// documents are probably local and ftp:// documents are probably not HTML). The temporary file is deleted when the document is uncached. For certain operations, instead of reloading the document via HTLoad(), the source file is reparsed with HTParseFile(). The cached document also remembers certain parser settings (screen size, historical vs. minimal vs. valid comment parsing, and the like), and is regenerated from source if it is fetched out of cache under different settings. This behavior is selectable by a configure option --enable-source-cache and by a lynx.cfg option SOURCE_CACHE; I didn't add a command-line argument or an options menu entry, as this didn't seem to be the sort of thing one would want to change at runtime. (Scott Bigham ) * amend HTConfirmDefault() logic so that a second character will cause the default response to be returned, e.g,. so that pressing "qq" will make Lynx exit (reported by John Bley) - TD * change the PUTS("\n") calls in HTFile.c to PUTC('\n') since that would be a little more efficient (noted by KW) - TD * minor cleanup: remove obsolete parameters from command-line parsing functions in LYMain.c, add newlines in HTFile.c for readability of html - LP * change default STARTFILE to the current directory, "." - PW * revised lynx-dev.html - PW * lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page with the default editor and changes can be activated for the same lynx session. NOT allowed for restricted users (LYRestricted) and occasionally for user mode other than ADVANCED. This is an *experimental* code (reload_read_cfg() in LYMain.c - more work required): currently command-line switches may be lost when overriden by lynx.cfg changes, file paths like lynx_temp_space and LYCookieFile should not be changed (unwanted results) -LP * retest PARSE_DEBUG ifdef's (LYMain.c, LYReadCFG.c), minor corrections but found no specific reason for LP's problem with tables, except possibly different effect from "&(value)" versus "(&value)" - TD * fix the problem of reading included lynx.cfg files by changing LYReadCFG.c table signature (now it is more close to one in LYMain.c). The problem was the ignoring of *some* values got from the included cfg file (at least for DJGPP2.02/gcc2.8.1 build). Probably we calculate the addresses of variables on a later stage now. - LP * DOSPATH changes: local directory style now configurable from lynx.cfg (LONG_LIST defined). Unlike UNIX it is not "ls -l" by default but a more compact form (date and size present, from lynx.cfg example) - LP * cookies: domains now match case insensitively (reported by Paul Wagner ) - LP * correct an ifdef in LYGetFile.c for config-page - LP * reading of long local directories now benefits from partial mode and fully interruptable. Split out print_local_dir() function from HTLoadFile() - LP * behave sanely if NSL_FORK fork() fails -BL * NSL_FORK try for dns_patience *seconds*, not dns_patience select() calls, which might have been shortened by keyboard input -BL * fix some screwy comment indentation -BL * add section on editing TEXTAREA to user's guide - PW * add a null-pointer check in LYCookie.c (Bill Nottingham ) * revise changes ifdef'ing LY_FIND_LEAKS by making atexit a no-op function since the DOS port depends on atexit to keep the DOS BREAK function properly set on exit. Put back atexit, and ifdef's each place where atexit isn't needed except when finding leaks - DK * modify LYMain.c on DOS, fixing the determination of BREAK status to be independent of SLANG or PDCurses - DK * spawn a new function, www_user_search_internals, to begin cancelling the effects of cut-n-paste coding in www_user_search. The body of www_user_search_internals used to be duplicated at two points in www_user_search. See comment in GridText.c for more details. (John Bley) * big pile of unneeded #includes removed (John Bley) * remove obsolete files from the distribution (John Bley) WWW/Library/Implementation/HTWriter.* * one malloc check, fix --disable-ftp (John Bley) * fixes for compiler warnings when building for OpenVMS 6.2 using DEC C and the SOCKETSHR library (reported by Andy Harper) - TD * add cpp -H option for HPUX bundled C compiler, which otherwise does not have enough symbol table space (reported by JS). Also, modify ifdefs for vs to avoid including the former when ANSI_VARARGS is not defined since HPUX had a broken - TD * changed OMIT_SCN_KEEPING ifdef to 0 (inactive) in LYCurses.c and in HTML.c, still enabling the Style_className:HTML.c keeping and making lynx with lss slightly slower than it could be (though faster then dev21). If somebody wishes to fix a bug, here is a description: If contents of some tag that has corresponding color style occupies more than 2 screens, after navigating to the page, on which the content of that block starts, and then pressing PGDN PGDN PGUP, the effect (color style) of that tag will be lost. The same (loosing style) happens when jumping to the anchor that is in such block and is located not on the 1st page. IMO this is something with style stack. If this will be fixed, then keeping of Style_className:HTML.c can be omitted again -VH * Fixed the bug in lynx with lss support -when displaying html pieces such as A B C , only 'AB' was drawn in style corresponding to -VH * added HTML source syntax highlighting (when option -prettysrc that is added is given to lynx). It's available for lynx compiled with and without lss support (it can be much more beatiful when compiled with lss support - read lynx.cfg for description). This functionality coexists with old source view and with -preparsed logic (ie different commandline options make source view logic different) VH * HTChunkPutc was inlined in SGML.c for better performance -VH * Keeping of Style_className was omitted in HTML.c to increase performance of lynx compiled with lss support. -VH * perfomance of lynx compiled with lss support is increased ~ by 15-20% for normal documents, and by up to 50% for documents with a lot of tags VH * fixed bug in lynx compiled with lss support that caused it to load local CSS stylesheets - lynx didn't understand their syntax so it was exiting VH * added type information for attributes in HTMLDTD.c (it's used in source syntax highlighting mode) VH * sample .lss files are updated to support source syntax highlighting VH From owner-lynx-dev@sig.net Tue Apr 13 07:43:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA25781 for ; Tue, 13 Apr 1999 07:43:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA29949; Tue, 13 Apr 1999 05:56:55 -0500 (CDT) Date: Tue, 13 Apr 1999 05:56:51 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev jumping around In-Reply-To: <199904130921.FAA01410@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2631 Lines: 54 On Tue, 13 Apr 1999, Philip Webb wrote: > and another one: i have an URL in my bookmark file & now jumps file > http://www.tor.ec.gc.ca/forecasts/forecast.cgi?city=Toronto&province=Ontario > (of course, it's in the proper anchor setting). > when i use the bookmark or jumps listing, there's no problem; > when i enter j then w (the short-cut), i get a screen telling me > i haven't entered the full URL: it seems to be www.tor.ec.gc.ca/ only; ======================================= What do you mean by that? www.tor.ec.gc.ca/ is not a URL. I doubt that the INFO page says URL: www.tor.ec.gc.ca/ Anyway, the basic reason for inconsistencies is that Shortcut files[*] are being read by two completely different mechanisms[**]. It's a miracle that they at least sometimes come to the same result... A. normal HTML parsing: treated like any other text/html file, with everything that entails. That's what is used when you actually 'go to' or 'jump to' (with '?') the shortcut file. B. the 'shortcut way': file is read *once* (on first use of the jump key command), a list of (shortcut name, target URL) pairs is built, the list doesn't change until program exit. Mechanism B doesn't know much about HTML. That's why it may break if the format is too different from the samples (similar problem as with bookmark files). It also doesn't know anything about entity unescaping, the URL strings are just used as they are found. (And if they are not given as full absolute URLs, they may later be taken as relative to a different base than when following the link as in method A.) The problem in this specific case seems to be the '&'. Yes, it's more correct than just writing '&'. But mechanism B doesn't understand it, and simple '&' should also work for method A. So just change it. [*] Yes, you can have more than one, if you have some free keys; for example I have 'j'/'J' for main shortcut file, 'D' for Documentation shortcuts. (lynx.cfg says how, after KEYMAP section.) [**] Actually, three mechanisms for the Jumpfile itself: add one for reading it from lynx.cfg. > even stranger, = tells me i have reached the proper destination, > which is a simple Toronto weather outline & forecast. What's the URL according to the INFO page? Does it have '&'? Or does it have '&' only in the *INFO page's SOURCE*? (Look at the real file, not what lynx shows with '\', if you use one of the new fancy source display thingies.) > as before, Lynx2-8-2dev.19 on IRIX 5.3 . Klaus From owner-lynx-dev@sig.net Tue Apr 13 07:53:53 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA26006 for ; Tue, 13 Apr 1999 07:53:52 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA03598; Tue, 13 Apr 1999 06:30:17 -0500 (CDT) Date: Tue, 13 Apr 1999 07:29:44 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904130729.AA7958@cas.org> Subject: lynx-dev Question about patched lynx 2.8.2dev22 configure To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 456 Lines: 11 When I do a configure --help I see: Directory Editor Options: --disable-dired enable optional directory-editor, DirEd The disable flag _enables_ the optional directory editor? -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 13 08:52:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA27581 for ; Tue, 13 Apr 1999 08:52:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA10993; Tue, 13 Apr 1999 07:21:19 -0500 (CDT) Date: Tue, 13 Apr 1999 08:15:59 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev [PATCH][dev22] Various nits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 14633 Lines: 539 * Change all PUTS() with a string of length 1 to PUTC(), fix a uid_t/int assumption in LYLocal.c, remove some unneeded #includes, remove some spurious semicolons. (John Bley) -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall diff -Burp lynx2-8-2/WWW/Library/Implementation/HTAAUtil.c lynx2-8-2-patched/WWW/Library/Implementation/HTAAUtil.c --- lynx2-8-2/WWW/Library/Implementation/HTAAUtil.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTAAUtil.c Tue Apr 13 07:58:27 1999 @@ -48,7 +48,6 @@ #include /* Implemented here */ #include /* Assoc list */ #include -#include #include #include diff -Burp lynx2-8-2/WWW/Library/Implementation/HTFTP.c lynx2-8-2-patched/WWW/Library/Implementation/HTFTP.c --- lynx2-8-2/WWW/Library/Implementation/HTFTP.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTFTP.c Tue Apr 13 07:44:31 1999 @@ -2365,7 +2365,7 @@ PRIVATE int read_directory ARGS4( int BytesReceived = 0; int BytesReported = 0; char NumBytes[64]; - PUTS("\n"); /* prettier LJM */ + PUTC('\n'); /* prettier LJM */ for (ic = 0; ic != EOF;) { /* For each entry in the directory */ HTChunkClear(chunk); @@ -2467,14 +2467,14 @@ unload_btree: if (help_message_cache_non_empty()) { START(HTML_PRE); START(HTML_HR); - PUTS("\n"); + PUTC('\n'); PUTS(help_message_cache_contents()); init_help_message_cache(); /* to free memory */ START(HTML_HR); - PUTS("\n"); + PUTC('\n'); } else { START(HTML_PRE); - PUTS("\n"); + PUTC('\n'); } /* Put up header diff -Burp lynx2-8-2/WWW/Library/Implementation/HTFile.c lynx2-8-2-patched/WWW/Library/Implementation/HTFile.c --- lynx2-8-2/WWW/Library/Implementation/HTFile.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTFile.c Tue Apr 13 07:49:31 1999 @@ -1460,7 +1460,7 @@ PUBLIC BOOL HTDirTitles ARGS3( FREE(printable); } } else { - PUTS("/"); + PUTC('/'); } END(HTML_A); PUTC('\n'); diff -Burp lynx2-8-2/WWW/Library/Implementation/HTFinger.c lynx2-8-2-patched/WWW/Library/Implementation/HTFinger.c --- lynx2-8-2/WWW/Library/Implementation/HTFinger.c Wed Mar 17 22:17:11 1999 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTFinger.c Tue Apr 13 07:44:30 1999 @@ -146,18 +146,18 @@ PRIVATE int response ARGS5( */ CTRACE(tfp,"HTFinger: Reading finger information\n"); START(HTML_HTML); - PUTS("\n"); + PUTC('\n'); START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); PUTS("Finger server on "); PUTS(sitename); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_BODY); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); PUTS("Finger server on "); START(HTML_EM); @@ -179,7 +179,7 @@ PRIVATE int response ARGS5( PUTS(cmd); FREE(cmd); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); START(HTML_PRE); while ((ch=NEXT_CHAR) != EOF) { @@ -237,11 +237,11 @@ PRIVATE int response ARGS5( end_html: END(HTML_PRE); - PUTS("\n"); + PUTC('\n'); END(HTML_BODY); - PUTS("\n"); + PUTC('\n'); END(HTML_HTML); - PUTS("\n"); + PUTC('\n'); FREE_TARGET; return(0); } diff -Burp lynx2-8-2/WWW/Library/Implementation/HTGopher.c lynx2-8-2-patched/WWW/Library/Implementation/HTGopher.c --- lynx2-8-2/WWW/Library/Implementation/HTGopher.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTGopher.c Tue Apr 13 07:44:30 1999 @@ -225,28 +225,28 @@ PRIVATE void parse_menu ARGS2( START(HTML_HTML); - PUTS("\n"); + PUTC('\n'); START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); if ((title = HTAnchor_title(anAnchor))) PUTS(title); else PUTS(GOPHER_MENU_TITLE); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_BODY); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); if ((title = HTAnchor_title(anAnchor))) PUTS(title); else PUTS(GOPHER_MENU_TITLE); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); START(HTML_PRE); while ((ich=NEXT_CHAR) != EOF) { @@ -426,7 +426,7 @@ PRIVATE void parse_menu ARGS2( } /* parse error */ - PUTS("\n"); + PUTC('\n'); p = line; /* Start again at beginning of line */ } /* if end of line */ @@ -435,11 +435,11 @@ PRIVATE void parse_menu ARGS2( end_html: END(HTML_PRE); - PUTS("\n"); + PUTC('\n'); END(HTML_BODY); - PUTS("\n"); + PUTC('\n'); END(HTML_HTML); - PUTS("\n"); + PUTC('\n'); FREE_TARGET; return; @@ -469,16 +469,16 @@ PRIVATE void parse_cso ARGS2( CONST char *title; START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); if ((title = HTAnchor_title(anAnchor))) PUTS(title); else PUTS(GOPHER_CSO_SEARCH_RESULTS); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); if ((title = HTAnchor_title(anAnchor))) PUTS(title); @@ -487,7 +487,7 @@ PRIVATE void parse_cso ARGS2( PUTS(GOPHER_SEARCH_RESULTS); } END(HTML_H1); - PUTS("\n"); + PUTC('\n'); START(HTML_PRE); /* @@ -572,7 +572,7 @@ PRIVATE void parse_cso ARGS2( ** Print data. */ PUTS(second_colon+1); - PUTS("\n"); + PUTC('\n'); if (*(second_colon-1) != last_char) /* end seperator */ @@ -594,9 +594,9 @@ PRIVATE void parse_cso ARGS2( } /* Loop over characters */ /* end the text block */ - PUTS("\n"); + PUTC('\n'); END(HTML_PRE); - PUTS("\n"); + PUTC('\n'); FREE_TARGET; return; /* all done */ @@ -612,18 +612,18 @@ PRIVATE void display_cso ARGS2( CONST char * title; START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); if ((title = HTAnchor_title(anAnchor))) PUTS(title); else PUTS(GOPHER_CSO_INDEX); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); START(HTML_ISINDEX); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); if ((title = HTAnchor_title(anAnchor))) PUTS(title); @@ -656,19 +656,19 @@ PRIVATE void display_index ARGS2( CONST char * title; START(HTML_HEAD); - PUTS("\n"); - PUTS("\n"); + PUTC('\n'); + PUTC('\n'); START(HTML_TITLE); if ((title = HTAnchor_title(anAnchor))) PUTS(title); else PUTS(GOPHER_INDEX_TITLE); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); START(HTML_ISINDEX); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); if ((title = HTAnchor_title(anAnchor))) PUTS(title); diff -Burp lynx2-8-2/WWW/Library/Implementation/HTVMSUtils.c lynx2-8-2-patched/WWW/Library/Implementation/HTVMSUtils.c --- lynx2-8-2/WWW/Library/Implementation/HTVMSUtils.c Sat Dec 26 15:50:01 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTVMSUtils.c Tue Apr 13 07:44:31 1999 @@ -954,25 +954,25 @@ PUBLIC int HTVMSBrowseDir ARGS4( * Output the title and header. */ START(HTML_HTML); - PUTS("\n"); + PUTC('\n'); START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); HTUnEscape(title); START(HTML_TITLE); PUTS(title); PUTS(" directory"); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); FREE(title); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_BODY); - PUTS("\n"); + PUTC('\n'); HTUnEscape(header); START(HTML_H1); PUTS(header); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); if (HTDirReadme == HT_DIR_README_TOP) { FILE * fp; if (header[strlen(header)-1] != '/') @@ -1018,7 +1018,7 @@ PUBLIC int HTVMSBrowseDir ARGS4( PUTS(parent); END(HTML_A); START(HTML_P); - PUTS("\n"); + PUTC('\n'); FREE(relative); FREE(parent); } @@ -1233,11 +1233,11 @@ PUBLIC int HTVMSBrowseDir ARGS4( * Complete the output stream. */ END(HTML_PRE); - PUTS("\n"); + PUTC('\n'); END(HTML_BODY); - PUTS("\n"); + PUTC('\n'); END(HTML_HTML); - PUTS("\n"); + PUTC('\n'); FREE(tail); FREE_TARGET; diff -Burp lynx2-8-2/WWW/Library/Implementation/HTWAIS.c lynx2-8-2-patched/WWW/Library/Implementation/HTWAIS.c --- lynx2-8-2/WWW/Library/Implementation/HTWAIS.c Thu Dec 24 06:27:23 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTWAIS.c Tue Apr 13 07:47:03 1999 @@ -198,7 +198,7 @@ PRIVATE void showDiags ARGS2( PUTS(d[i]->DIAG); PUTC(' '); PUTS(d[i]->ADDINFO); - PUTC('\n'); ; + PUTC('\n'); } } } @@ -482,7 +482,7 @@ PRIVATE void display_search_response ARG PUTS(gettext("the second is the number of lines in the item.")); START(HTML_BR); START(HTML_BR); - PUTS("\n"); + PUTC('\n'); START(HTML_OL); if (response->DatabaseDiagnosticRecords != 0) { @@ -595,7 +595,7 @@ PRIVATE void display_search_response ARG } } /* Loop: display user info */ END(HTML_OL); - PUTC('\n'); ; + PUTC('\n'); } /* Load by name HTLoadWAIS @@ -758,18 +758,18 @@ PUBLIC int HTLoadWAIS ARGS4( HTStructured * target = HTML_new(anAnchor, format_out, sink); START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); HTStartIsIndex(target, HTWAIS_SOLICIT_QUERY , NULL); - PUTS("\n"); + PUTC('\n'); { START(HTML_TITLE); PUTS(wais_database); PUTS(gettext(" (WAIS Index)")); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); PUTS(gettext("WAIS Index: ")); @@ -777,7 +777,7 @@ PUBLIC int HTLoadWAIS ARGS4( PUTS(wais_database); END(HTML_EM); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); PUTS(gettext("This is a link for searching the ")); START(HTML_EM); PUTS(wais_database); @@ -801,7 +801,7 @@ PUBLIC int HTLoadWAIS ARGS4( if (fp) { char c; START(HTML_PRE); /* Preformatted description */ - PUTS("\n"); + PUTC('\n'); while((c=getc(fp))!=EOF) PUTC(c); /* Transfer file */ END(HTML_PRE); fclose(fp); @@ -824,18 +824,18 @@ PUBLIC int HTLoadWAIS ARGS4( target = HTML_new(anAnchor, format_out, sink); START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); HTStartIsIndex(target, HTWAIS_SOLICIT_QUERY, NULL); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); PUTS(keywords); PUTS(gettext(" (in ")); PUTS(wais_database); - PUTS(")"); + PUTC(')'); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_H1); PUTS(gettext("WAIS Search of \"")); @@ -847,7 +847,7 @@ PUBLIC int HTLoadWAIS ARGS4( PUTS(wais_database); END(HTML_EM); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); request_buffer_length = MAX_MESSAGE_LEN; /* Amount left */ CTRACE(tfp, "HTWAIS: Search for `%s' in `%s'\n", diff -Burp lynx2-8-2/WWW/Library/Implementation/HTWSRC.c lynx2-8-2-patched/WWW/Library/Implementation/HTWSRC.c --- lynx2-8-2/WWW/Library/Implementation/HTWSRC.c Thu Dec 24 06:27:23 1998 +++ lynx2-8-2-patched/WWW/Library/Implementation/HTWSRC.c Tue Apr 13 07:44:31 1999 @@ -303,19 +303,19 @@ PRIVATE void WSRC_gen_html ARGS2(HTStrea } START(HTML_HEAD); - PUTS("\n"); + PUTC('\n'); START(HTML_TITLE); PUTS(shortname); PUTS(source_file ? gettext(" WAIS source file") : INDEX_SEGMENT); END(HTML_TITLE); - PUTS("\n"); + PUTC('\n'); END(HTML_HEAD); START(HTML_H1); PUTS(shortname); PUTS(source_file ? gettext(" description") : INDEX_SEGMENT); END(HTML_H1); - PUTS("\n"); + PUTC('\n'); FREE(shortname); } diff -Burp lynx2-8-2/src/GridText.c lynx2-8-2-patched/src/GridText.c --- lynx2-8-2/src/GridText.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/src/GridText.c Tue Apr 13 07:48:58 1999 @@ -1951,7 +1951,7 @@ PRIVATE void split_line ARGS2( linedata[line->size++] = LY_BOLD_START_CHAR; linedata[line->size] = '\0'; ctrl_chars_on_this_line++; - SpecialAttrChars++;; + SpecialAttrChars++; } if (plen) { for (i = (plen - 1); i >= 0; i--) { diff -Burp lynx2-8-2/src/LYCharSets.c lynx2-8-2-patched/src/LYCharSets.c --- lynx2-8-2/src/LYCharSets.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/src/LYCharSets.c Tue Apr 13 07:48:34 1999 @@ -6,7 +6,6 @@ #include #include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYDownload.c lynx2-8-2-patched/src/LYDownload.c --- lynx2-8-2/src/LYDownload.c Tue Apr 13 05:39:16 1999 +++ lynx2-8-2-patched/src/LYDownload.c Tue Apr 13 08:05:19 1999 @@ -6,7 +6,6 @@ #include #include #include -#include #include #include diff -Burp lynx2-8-2/src/LYLocal.c lynx2-8-2-patched/src/LYLocal.c --- lynx2-8-2/src/LYLocal.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYLocal.c Tue Apr 13 08:04:54 1999 @@ -39,7 +39,6 @@ #include #include #include -#include #include #include #include @@ -329,7 +328,7 @@ PRIVATE BOOLEAN not_already_exists ARGS1 return FALSE; } -PRIVATE BOOLEAN dir_has_same_owner ARGS2(struct stat *, info, int, owner) +PRIVATE BOOLEAN dir_has_same_owner ARGS2(struct stat *, info, uid_t, owner) { if (S_ISDIR(info->st_mode)) { if (info->st_uid == owner) { diff -Burp lynx2-8-2/src/LYNews.c lynx2-8-2-patched/src/LYNews.c --- lynx2-8-2/src/LYNews.c Wed Mar 17 22:17:11 1999 +++ lynx2-8-2-patched/src/LYNews.c Tue Apr 13 08:04:58 1999 @@ -10,7 +10,6 @@ #include #include #include -#include #include #include #include diff -Burp lynx2-8-2/src/LYOptions.c lynx2-8-2-patched/src/LYOptions.c --- lynx2-8-2/src/LYOptions.c Tue Mar 30 12:10:37 1999 +++ lynx2-8-2-patched/src/LYOptions.c Tue Apr 13 07:48:27 1999 @@ -11,7 +11,6 @@ #include #include #include -#include #include #include #include From owner-lynx-dev@sig.net Tue Apr 13 09:15:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28222 for ; Tue, 13 Apr 1999 09:14:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA12942; Tue, 13 Apr 1999 07:32:25 -0500 (CDT) From: dickey@clark.net Message-Id: <199904131232.IAA03596@shell.clark.net> Subject: Re: lynx-dev Question about patched lynx 2.8.2dev22 configure To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 08:32:22 -0400 (EDT) In-Reply-To: <9904130729.AA7958@cas.org> from "lvirden@cas.org" at Apr 13, 99 07:29:44 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 382 Lines: 16 > > When I do a configure --help I see: > > Directory Editor Options: > --disable-dired enable optional directory-editor, DirEd > > The disable flag _enables_ the optional directory editor? sounds like a typo to me (thanks) > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 09:19:15 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28444 for ; Tue, 13 Apr 1999 09:19:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16209; Tue, 13 Apr 1999 07:48:34 -0500 (CDT) Message-Id: <3.0.5.32.19990413084823.00824470@RS8.LOC.GOV> X-Sender: LRAS@RS8.LOC.GOV X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 13 Apr 1999 08:48:23 -0400 To: lynx-dev@sig.net From: "Lloyd G. Rasmussen" Subject: Re: lynx-dev Lynx for Macintosh In-Reply-To: <0FA300JEWF6MHG@mail.megsinet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1488 Lines: 29 None of the versions of Lynx so far support tables in the way you are expecting from the graphical world. Tables on web pages are very often wider than the text screen width, and their column widths are specified in pixels or percentages, not in number of fixed-pitch characters. Lynx does act upon markup it finds within table cells, including nested tables. Lynx will put in one space when it encounters the "next cell" tag. It goes to a new line when it encounters a "nextw row" tag. Where tables are being used for page layout purposes, Lynx has the desirable effect of decolumnizing the table, because of all the
tags frequently imbedded in these tables. Where tables are used for the purpose of displaying related information, it doesn't usually do very well. Many of these limitations are the result of Lynx parsing the HTML on a one-pass basis, with no provision for recursion. At 03:22 PM 4/12/99 +0000, you wrote: >Can someone please give me a URL where I can download a version of Lynx for >the Mac OS? Every link I've tried gives me a "file not found" error. If no >version is currently available, would you please tell me whether Lynx >supports tables or not? >Thanks, >Jason Rayles >jasonrayles@hotmail.com > Lloyd Rasmussen, Senior Staff Engineer National Library Service f/t Blind and Physically Handicapped Library of Congres (202) 707-0535 HOME: ; Tue, 13 Apr 1999 09:45:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA25310; Tue, 13 Apr 1999 08:23:09 -0500 (CDT) Date: Tue, 13 Apr 1999 06:23:04 -0700 From: David Combs To: lynx-dev@sig.net Subject: Re: lynx-dev patch: jumps help (was jumping out) Message-ID: <19990413062304.A2780@netcom17.netcom.com> References: <199904130513.OAA12441@ibr1.irm.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904130513.OAA12441@ibr1.irm.nara.kindai.ac.jp>; from Henry Nelson on Tue, Apr 13, 1999 at 02:13:59PM +0900 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1470 Lines: 42 On Tue, Apr 13, 1999 at 02:13:59PM +0900, Henry Nelson wrote: > > & yes i know it's full of
's, but they make the rendered version > > neater & easier to read using Lynx for the vast majority of users. > > All those
's don't make a bit of sense to me. What's the point > of html? If you absolutely need that kind of formating, you should > do it all within
 blocks, IMHO.
> 
> __Henry

Look, if he insists on including the 
's, let him (unless accepting his patches means that they *belong* to him, and can never be again modified). Merely use an editor with an eg "query-replace" (as does emacs), and just run down them (either as patches or in the manual *after* the patches have been merged in), removing the gratuitous ones. --- When running lynx (or anything on the net, via shell acct via kermit) I run from a home window that's 132 wide. I sure like having html fill the thing out to the full screen width. A lot easier for *me* (maybe not others) to read, since there's lots more on the screen that way. If I *want* to see a html-originated file *narrow*, all I have to do is ^Z, do my "nowide" alias for "stty cols 79", "fg", and hit ^R for redisplay 79-wide. This way it is *my* decision how I want to see it. And I too agree, what use html if the width is hard-coded? --- Before I go too far looking the gift horse in the mouth, I want to give *huge* appreciation for *anyone* who is helping on the code and/or the doc. David From owner-lynx-dev@sig.net Tue Apr 13 10:15:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA30193 for ; Tue, 13 Apr 1999 10:15:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA07923; Tue, 13 Apr 1999 08:59:25 -0500 (CDT) Message-Id: <3.0.3.32.19990413085912.008183a0@collins.mail.iastate.edu> X-Sender: collins@collins.mail.iastate.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 13 Apr 1999 08:59:12 -0500 To: lynx-dev@sig.net From: Gene Collins Subject: Re: lynx-dev Lynx suppport frames? In-Reply-To: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1470 Lines: 34 At 12:04 PM 4/12/99 -0700, you wrote: >Does Lynx currently support Frames? If not, will the new version support >Frames? When will this new version be released? > >If Lynx does/will not support Frames, can you refer me to a software that >does support Frames. > >This is a critical issue at San Francisco State University as we are >introducing a new online course management system called "Blackboard" - >which is set up in frames. If you could get back to me as soon as >possible, I would really appreciate it. > Lynx shows each frame as a separate link, rather than displaying frames side by side or above one another on the page. For blind people using screen readers, this is critical, since most screen readers have no way to distinguish multi-column text on the screen. As a totally blind lynx user, I really appreciate this feature, and hope the lynx developers will keep this behavior in future versions of lynx. If you are looking for a web browser that really displays frames, try Netscape or Internet Explorer. But be aware that by insisting on a system that uses frames, you may inhibit access by totally blind students. I know that frames are all the rage on the internet, but they are * not * always the most useful way to present information. My personal and heart felt thanks to all the lynx developers for all there hard work in developing a browser with features that blind people find especially useful. Gene Collins collins@iastate.edu From owner-lynx-dev@sig.net Tue Apr 13 11:34:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00037 for ; Tue, 13 Apr 1999 11:33:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA06546; Tue, 13 Apr 1999 10:16:56 -0500 (CDT) Message-ID: <37135AC8.22125F6C@co.polk.ia.us> Date: Tue, 13 Apr 1999 09:55:04 -0500 From: "Lt. Kerry Kirstein" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev Lynx 2.8 Content-Type: multipart/mixed; boundary="------------5756DC69B5D4DFE74D217C83" X-MDaemon-Deliver-To: lynx-dev@sig.net X-Return-Path: K0611@co.polk.ia.us Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1159 Lines: 48 This is a multi-part message in MIME format. --------------5756DC69B5D4DFE74D217C83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit So where can one pick up this text only browser. I didn't see any links on any of your pages for downloading or purchasing this. ???????????? -- The Truth is Out There ! ! ******************************* mailto:K0611@co.polk.ia.us or mailto:Lt_KK@hotmail.com Polk County Sheriff's Office http://www.co.polk.ia.us/departments/sheriff/auto-index.htm Personal Home Page http://home.att.net/~kirstein/home.htm --------------5756DC69B5D4DFE74D217C83 Content-Type: text/x-vcard; charset=us-ascii; name="K0611.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Lt. Kerry Kirstein Content-Disposition: attachment; filename="K0611.vcf" begin:vcard n:Kirstein;Kerry x-mozilla-html:TRUE org:Polk County Sheriff's Office adr:;;110 6th Ave.;Des Moines;Iowa;50309;USA version:2.1 email;internet:K0611@co.polk.ia.us title:Lieutenant tel;fax:515-286-2081 tel;work:515-286-3804 / 515-286-2166 x-mozilla-cpt:;0 fn:Kerry Kirstein end:vcard --------------5756DC69B5D4DFE74D217C83-- From owner-lynx-dev@sig.net Tue Apr 13 11:34:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00048 for ; Tue, 13 Apr 1999 11:34:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29469; Tue, 13 Apr 1999 09:58:51 -0500 (CDT) Date: Tue, 13 Apr 1999 09:58:46 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch In-Reply-To: <199904022007.PAA01708@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6480 Lines: 152 Commenting on patch that's now in 2.8.2dev.22: On Fri, 2 Apr 1999, Philip Webb wrote: > so having sorted out those preliminaries, > i have been able to tackle the original problem, > which was to have a better default STARTFILE for ordinary users, > who may find l.b.o. down for some reason. > i hope the warning for anonymous sites is ok (Henry?): > if lynx.cfg offers > 1 STARTFILE , Lynx uses the last one found, > so this is failsafe, if the sysadmin forgets to comment out the regular line. > > *** old/lynx.cfg Fri Mar 5 14:47:43 1999 > --- new/lynx.cfg Fri Apr 2 14:53:49 1999 > *************** > *** 33,47 **** > # ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system > #and now your own tweaks. > > # > ! # STARTFILE is the default URL if none is specified on the command line > ! # or via a WWW_HOME environment variable. > ! # Note: these files can be remote (http://www.w3.org/default.html) > ! # or local (file://localhost/PATH_TO/FILENAME > ! # replace PATH_TO with the complete path to FILENAME > ! # use Unix SHELL syntax and include the device on VMS systems) > ! # > ! STARTFILE:http://lynx.browser.org/ > > # HELPFILE must be defined as a URL and must have a > # complete path if local: > --- 33,54 ---- > # ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system > #and now your own tweaks. > > + # STARTFILE is the default starting URL if none is specified > + # on the command line or via a WWW_HOME environment variable; > + # Lynx will refuse to start without a starting URL of some kind. > + # STARTFILE can be remote, e.g. http://www.w3.org/default.html , > + # or local, e.g. file://localhost/PATH_TO/FILENAME , > + # where PATH_TO is replaced with the complete path to FILENAME > + # using Unix shell syntax and including the device on VMS. > + # The default offered for ordinary users is their current directory: > + STARTFILE:. This change flies in the face of what the documentation says, including the comments just above it. "." is not a URL! More generally, there are quite a few places - in userdefs.h - in lynx.cfg - in ynx_url_support.html that say that something "must" be a URL. !! URLs are not filenames. Filenames are not URLs. !! Also a local file URL is not just a filename prefixed with "file://localhost". And a local filename is not just a file: URL stripped of the initial ""file://localhost". That happens to be true only sometimes, and then only for some OSs. Some of the "must"s are not technically required. They should probably be replaced by "should"s. This applies for everything that lynx passes through a pair of LYFillLocalFileURL(...); LYEnsureAbsoluteURL(...); calls: at least startfile, homepage, 'g'/'G' URLs. Lynx tries to convert those things to URLs if they aren't already. It's described in lynx_url_support.html, in the section from "When entering a URL on the command line....." to "These expansions are SOLELY for startfile or 'g'oto entries!" but the "SOLELY" may not be true any more(??). Anyway, something like "/home/myname/" or "." is not a URL in terms of lynx_url_support.html, no matter how you slice it. Putting 'note: STARTFILE must be a URL' directly followed by '#define STARTFILE "."' in userdefs.h just increases the confusion. To *decrease* the confusion, it should be stated clearly what is what: what kind of object is expected by each lynx.cfg option, userdefs.h #define, etc. There are at least three kinds of objects: - 'real' (absolute) URLs - the tentative URLs mentioned above. Let's give them a name for reference. Say U-URL (user URL), or something. lynx_url_support.html should document what forms are acceptable, in addition to strict 'real' URLs. lynx.cfg, userdefs.h, 'g'oto help should say where a U-URL is allowed. - filenames. Things that aren't converted to URLs at all. This is only a broad classification. Some filenames are further treated specially (like bookmark files, sometimes they are supposed to start with './' where '.' stands for the home dir). The VMS code defines a 'Unix syntax' even for most (all?) non-URL filenames. Windows/DOS code may accept Unix form for some filenames. And so on... ---- The patch (without doc changes) increases the discrepancy between documentation and reality, but I also question its usefulness. Is it a good thing to start with browsing the *current* directory by default? I guess Philip got tired of seeing all the problems people are having with lynx refusing to start, but in most cases this change just hides or defers the problem. In most cases (I assume) people *want* to make a network connection. So now they'll see Lynx start up and not exit immediately, but if there network is somehow misconfigured they still can't go anywhere; and if the problem is just that they haven't configured lynx (when they would want to), it also doesn't help much. Anyway, I suggest it would be better to at least start with the user's home directory by default, instead of '.'. Also, this can be specified in URL form: "file://localhost/~/" should work. > # > ! # *** NBB *** System administrators with ANONYMOUS USERS !!! > ! # set STARTFILE to a REMOTE FILE by uncommenting the next line: > ! #STARTFILE:http://lynx.browser.org/ > ! # and commenting out the default offered above; > ! # you may, of course, choose to replace `lynx.browser.org' > ! # with another remote/local file which you know to be safe. It doesn't make much sense to ask system administrators with ANONYMOUS USERS (them and only them) to set STARTFILE to "http://lynx.browser.org/", or to a 'REMOTE FILE'. Those are probably exactly the folks who want to point STARTFILE to a specific (probably local) location. Not just 'you may', they SHOULD. OTOH it looks now as if http://lynx.browser.org/ were only suggested for those administrators with ANONYMOUS USERS, not for others. It should be suggested as an laternative for everyone. Even better, it should be more strongly suggested that folks actually change STARTFILE to *what they want*. ---- About the sentence: > + # Lynx will refuse to start without a starting URL of some kind. It isn't actually possible to *not* have a starting URL of some kind. There's the userdefs.h default, lynx can't even be compiled without it (as you have noticed); so this doesn't make sense. Klaus From owner-lynx-dev@sig.net Tue Apr 13 12:43:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA02410 for ; Tue, 13 Apr 1999 12:43:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA04236; Tue, 13 Apr 1999 11:28:42 -0500 (CDT) Message-ID: <19990413102721.C29694@mred.intellistor.com> Date: Tue, 13 Apr 1999 10:27:21 -0600 From: tlhall@royal.net To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx suppport frames? References: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <3.0.1.32.19990412120408.008e7c10@sfsu.edu>; from Jennifer Jelavich on Mon, Apr 12, 1999 at 12:04:08PM -0700 X-Mutt-References: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 959 Lines: 22 On Mon, Apr 12, 1999 at 12:04:08PM -0700, Jennifer Jelavich wrote: > ... > This is a critical issue at San Francisco State University as we are > introducing a new online course management system called "Blackboard" - > which is set up in frames. If you could get back to me as soon as > possible, I would really appreciate it. Looks to me like you could use lynx to take courses, but not to build them, since lynx doesn't have JavaScript support. See the manual at: http://www.blackboard.net/help/documentation/i_manual If you have acces to lynx, try it on : http://classroom.blackboard.net/courses/PHY111/index.html It looks like Blackboard doesn't use the ALT tags by default, so students may have to deduce where links point by the file names (pretty much S.O.P. for lynx users these days). Apparently, David Weaver (PHY111) found a way to include the ALT tags, so if your students are going to be using lynx, you should use the ALT tags, too. From owner-lynx-dev@sig.net Tue Apr 13 13:16:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA03375 for ; Tue, 13 Apr 1999 13:16:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA16497; Tue, 13 Apr 1999 12:01:20 -0500 (CDT) From: dickey@clark.net Message-Id: <199904131701.NAA15198@shell.clark.net> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 13:01:15 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 13, 99 09:58:46 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1451 Lines: 36 > The patch (without doc changes) increases the discrepancy between > documentation and reality, but I also question its usefulness. thanks (I didn't see any discussion on this last week, put it in dev22 since it's simple to change back - or expand as needed) > Anyway, I suggest it would be better to at least start with the > user's home directory by default, instead of '.'. Also, this > can be specified in URL form: "file://localhost/~/" should work. better (but still doesn't address anon users unless we add something special) > > # > > ! # *** NBB *** System administrators with ANONYMOUS USERS !!! > > ! # set STARTFILE to a REMOTE FILE by uncommenting the next line: > > ! #STARTFILE:http://lynx.browser.org/ > > ! # and commenting out the default offered above; > > ! # you may, of course, choose to replace `lynx.browser.org' > > ! # with another remote/local file which you know to be safe. > > It doesn't make much sense to ask system administrators with ANONYMOUS > USERS (them and only them) to set STARTFILE to > "http://lynx.browser.org/", or to a 'REMOTE FILE'. Those are probably > exactly the folks who want to point STARTFILE to a specific (probably > local) location. Not just 'you may', they SHOULD. yes - that's a problem (people don't read installation instructions unless the program doesn't work) > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 13:46:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA04254 for ; Tue, 13 Apr 1999 13:46:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA06635; Tue, 13 Apr 1999 12:27:49 -0500 (CDT) X-Authentication-Warning: localhost.localdomain: hugo set sender to hugo.rabson@zetnet.co.uk using -f Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 13 Apr 1999 16:24:46 -0000 () From: Hugo Rabson To: Lynx Dev List Subject: lynx-dev Persistent cookies between batch-mode Lynx calls? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1073 Lines: 35 When compiled / configured properly, Lynx handles Hotmail's cookies perfectly... when run in interactive mode. When called from the command line or from within a script, however, Lynx does not seem able to handle Hotmail's cookies. Does Lynx clean out / erase its cookie file between sessions (be they interactive or command line mode)? Does Lynx simply not save/handle cookies in command line mode? I'm using these cookie-specific options in /etc/lynx.cfg :- # SET_COOKIES:TRUE # ACCEPT_ALL_COOKIES:TRUE # COOKIE_FILE:~/.lynx_cookies # PERSISTENT_COOKIES:TRUE All help is appreciated. :) Hugo P.S. Reason behind this post: I'm trying to make a script which will login and retrieve emails from Hotmail; the script uses Lynx & Lynx has until now been perfect for the job. However, Hotmail has introduced cookies and Lynx just can't cope in command line mode. --------Hugo Rabson -------- Date: 13-Apr-99 Time: 16:17:15 NT is for the Navy; the Vikings would have used Linux. ------------------------------------------------------ From owner-lynx-dev@sig.net Tue Apr 13 13:55:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA04551 for ; Tue, 13 Apr 1999 13:55:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03085; Tue, 13 Apr 1999 12:18:12 -0500 (CDT) Date: Tue, 13 Apr 1999 18:04:08 BST From: Andy Harper To: LYNX-DEV@sig.net CC: Andy.Harper@kcl.ac.uk Message-ID: <009D6960.7D6CC8D1.1365@alder.cc.kcl.ac.uk> Subject: lynx-dev lynx 2.8.2. dev 22 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 32638 Lines: 830 Trying to build 2.8.2 dev 22 under VMS 6.2 and DEC C results in a number of problems still. First, 'sleep' is undeclared in Gridtext.c HTalert.c LYbookmark.c LYedit.c LYjump.c LYstrings.c Second, 'alarm' is undeclared in LYCurses.c All of these are warnings only but still should be fixed. Both are declared in 'unistd.h' for DEC C The files HTutils.h and HTstring.H both include each other. This lead to a rather repetitious listing in the compilation HTFILE.C will not compile at all. The error is obscure. The error and an extract from the listing is enclosed (with all macro expansions etc turned on). I think it's a mismatched '}' somewhere but I gave up trying to find it! Lines marked with an X down the left are EXCLUDED by ifdef's. Finally, I think DISP_PARTIAL should be defined for the compilation within BUILD.COM and the DESCRIP.MMS files. Regards, Andy Harper Kings College London Here's the two routines around the error in their entirety (to assist debugging). Sorry they are a bit long... 32263 /* Output parent directory entry. 32264 ** ------------------------------ 32265 ** 32266 ** This gives the TITLE and H1 header, and also a link 32267 ** to the parent directory if appropriate. 32268 ** 32269 ** On exit: 32270 ** Returns TRUE if an "Up to " link was not created 32271 ** for a readable local directory because LONG_LIST is defined 32272 ** and NO_PARENT_DIR_REFERENCE is not defined, such that the 32273 ** calling function use LYListFmtParse() to create a link to 32274 ** the parent directory. Otherwise, it returns FALSE. - FM 32275 */ 32276 PUBLIC BOOL HTDirTitles ARGS3( 1E 1E BOOLEAN 1E (HTStructured * target, HTAnchor * anchor, BOOLEAN tildeIsTop) 32277 HTStructured *, target, 32278 HTAnchor *, anchor, 32279 BOOL, tildeIsTop) 32280 { 32281 char * logical = HTAnchor_address(anchor); 32282 char * path = HTParse(logical, "", PARSE_PATH + PARSE_PUNCTUATION); 1E 4 1E 1 32283 char * current; 32284 char * cp = NULL; 1E ((void *) 0) 32285 BOOL need_parent_link = FALSE; 1E BOOLEAN 1E (0) 32286 int i; 32287 32288 #ifdef DOSPATH X 32289 BOOL local_link = FALSE; X 32290 if (logical[18] == ':') local_link = TRUE; X 32291 #endif 32292 /* 32293 ** Check tildeIsTop for treating home directory as Welcome 32294 ** (assume the tilde is not followed by a username). - FM 32295 */ 32296 if (tildeIsTop && !strncmp(path, "/~", 2)) { 32297 if (path[2] == '\0') { 32298 path[1] = '\0'; Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 585 13-APR-1999 09:39:16 HTFILE.C;1 32299 } else { 32300 for (i = 0; path[(i + 2)]; i++) { 32301 path[i] = path[(i + 2)]; 32302 } 32303 path[i] = '\0'; 32304 } 32305 } 32306 32307 /* 32308 ** Trim out the ;type= parameter, if present. - FM 32309 */ 32310 if ((cp = strrchr(path, ';')) != NULL) { 1E ((void *) 0) 32311 if (!strncasecomp((cp+1), "type=", 5)) { 32312 if (TOUPPER(*(cp+6)) == 'D' || 1E (((decc$$gl___ctypea)?(*decc$$ga___ctypet)[(int)((unsigned char)*(cp+6))]&0x2:islower((unsigned char)*(cp+6 1E ))) ? toupper((unsigned char)*(cp+6)) : ((unsigned char)*(cp+6))) 32313 TOUPPER(*(cp+6)) == 'A' || 1E (((decc$$gl___ctypea)?(*decc$$ga___ctypet)[(int)((unsigned char)*(cp+6))]&0x2:islower((unsigned char)*(cp+6))) ? t 1E oupper((unsigned char)*(cp+6)) : ((unsigned char)*(cp+6))) 32314 TOUPPER(*(cp+6)) == 'I') 1E (((decc$$gl___ctypea)?(*decc$$ga___ctypet)[(int)((unsigned char)*(cp+6))]&0x2:islower((unsigned char)*(cp+6))) ? t 1E oupper((unsigned char)*(cp+6)) : ((unsigned char)*(cp+6))) 32315 *cp = '\0'; 32316 } 32317 cp = NULL; 1E ((void *) 0) 32318 } 32319 current = strrchr(path, '/'); /* last part or "" */ 32320 32321 { 32322 char * printable = NULL; 1E ((void *) 0) 32323 32324 #ifdef DIRED_SUPPORT X 32325 printable = HTfullURL_toFile( X 32326 (0 == strncasecomp(path, "/%2F", 4)) /* "//" ? */ X 32327 ? (path+1) X 32328 : path); X 32329 if (0 == strncasecomp(printable, "/vmsysu:", 8) || X 32330 0 == strncasecomp(printable, "/anonymou.", 10)) { X 32331 StrAllocCopy(cp, (printable+1)); X 32332 StrAllocCopy(printable, cp); X 32333 FREE(cp); X 32334 } X 32335 #else 32336 StrAllocCopy(printable, (current ? current + 1 : "")); 1E HTSACopy (&(printable), (current ? current + 1 : "")) 32337 HTUnEscape(printable); 32338 #endif /* DIRED_SUPPORT */ 32339 32340 START(HTML_HEAD); 1E (*target->isa->start_element)(target, HTML_HEAD, 0, 0, -1, 0) 32341 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32342 START(HTML_TITLE); 1E (*target->isa->start_element)(target, HTML_TITLE, 0, 0, -1, 0) Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 586 13-APR-1999 09:39:16 HTFILE.C;1 32343 PUTS(*printable ? printable : WELCOME_MSG); 1E (*target->isa->put_string)(target, *printable ? printable : "Welcome") 32344 PUTS(SEGMENT_DIRECTORY); 1E (*target->isa->put_string)(target, " directory") 32345 END(HTML_TITLE); 1E (*target->isa->end_element)(target, HTML_TITLE, 0) 32346 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32347 END(HTML_HEAD); 1E (*target->isa->end_element)(target, HTML_HEAD, 0) 32348 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32349 32350 #ifdef DIRED_SUPPORT X 32351 START(HTML_H2); X 32352 PUTS(*printable ? SEGMENT_CURRENT_DIR : ""); X 32353 PUTS(*printable ? printable : WELCOME_MSG); X 32354 END(HTML_H2); X 32355 PUTC('\n'); X 32356 #else 32357 START(HTML_H1); 1E (*target->isa->start_element)(target, HTML_H1, 0, 0, -1, 0) 32358 PUTS(*printable ? printable : WELCOME_MSG); 1E (*target->isa->put_string)(target, *printable ? printable : "Welcome") 32359 END(HTML_H1); 1E (*target->isa->end_element)(target, HTML_H1, 0) 32360 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32361 #endif /* DIRED_SUPPORT */ 32362 if (((0 == strncasecomp(printable, "vmsysu:", 7)) && 32363 (cp = strchr(printable, '.')) != NULL && 1E ((void *) 0) 32364 strchr(cp, '/') == NULL) || 1E ((void *) 0) 32365 (0 == strncasecomp(printable, "anonymou.", 9) && 32366 strchr(printable, '/') == NULL)) { 1E ((void *) 0) 32367 FREE(printable); 1E if (printable) {free(printable); printable = ((void *) 0);} 32368 FREE(logical); 1E if (logical) {free(logical); logical = ((void *) 0);} 32369 FREE(path); 1E if (path) {free(path); path = ((void *) 0);} 32370 return(need_parent_link); 32371 } 32372 FREE(printable); 1E if (printable) {free(printable); printable = ((void *) 0);} 32373 } 32374 32375 #ifndef NO_PARENT_DIR_REFERENCE 32376 /* 32377 ** Make link back to parent directory. 32378 */ 32379 if (current && current[1]) { /* was a slash AND something else too */ 32380 char * parent = NULL; 1E ((void *) 0) 32381 char * relative = NULL; Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 587 13-APR-1999 09:39:16 HTFILE.C;1 1E ((void *) 0) 32382 32383 *current++ = '\0'; 32384 parent = strrchr(path, '/'); /* penultimate slash */ 32385 32386 if ((parent && 32387 (!strcmp(parent, "/..") || 32388 !strncasecomp(parent, "/%2F", 4))) || 32389 !strncasecomp(current, "%2F", 3)) { 32390 FREE(logical); 1E if (logical) {free(logical); logical = ((void *) 0);} 32391 FREE(path); 1E if (path) {free(path); path = ((void *) 0);} 32392 return(need_parent_link); 32393 } 32394 32395 relative = 0; 32396 HTSprintf0(&relative, "%s/..", current); 32397 32398 #ifdef DOSPATH X 32399 if (local_link) X 32400 if (strlen(parent) == 3 ) X 32401 StrAllocCat(relative, "/."); X 32402 #endif 32403 32404 #if !defined (VMS) X 32405 #ifdef DOSPATH X 32406 if(!local_link) X 32407 #endif X 32408 { X 32409 /* X 32410 ** On Unix, if it's not ftp and the directory cannot X 32411 ** be read, don't put out a link. X 32412 ** X 32413 ** On VMS, this problem is dealt with internally by X 32414 ** HTVMSBrowseDir(). X 32415 */ X 32416 DIR * dp = NULL; X 32417 X 32418 if (LYisLocalFile(logical)) { X 32419 /* X 32420 ** We need an absolute file path for the opendir. X 32421 ** We also need to unescape for this test. X 32422 ** Don't worry about %2F now, they presumably have been X 32423 ** dealt with above, and shouldn't appear for local X 32424 ** files anyway... Assume OS / filesystem will just X 32425 ** ignore superfluous slashes. - KW X 32426 */ X 32427 char * fullparentpath = NULL; X 32428 X 32429 /* X 32430 ** Path has been shortened above. X 32431 */ X 32432 StrAllocCopy(fullparentpath, *path ? path : "/"); X 32433 X 32434 /* X 32435 ** Guard against weirdness. Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 588 13-APR-1999 09:39:16 HTFILE.C;1 X 32436 */ X 32437 if (0 == strcmp(current,"..")) { X 32438 StrAllocCat(fullparentpath,"/../.."); X 32439 } else if (0 == strcmp(current,".")) { X 32440 StrAllocCat(fullparentpath,"/.."); X 32441 } X 32442 X 32443 HTUnEscape(fullparentpath); X 32444 if ((dp = opendir(fullparentpath)) == NULL) { X 32445 FREE(fullparentpath); X 32446 FREE(logical); X 32447 FREE(relative); X 32448 FREE(path); X 32449 return(need_parent_link); X 32450 } X 32451 closedir(dp); X 32452 FREE(fullparentpath); X 32453 #ifdef LONG_LIST X 32454 need_parent_link = TRUE; X 32455 FREE(logical); X 32456 FREE(path); X 32457 FREE(relative); X 32458 return(need_parent_link); X 32459 #endif /* LONG_LIST */ X 32460 } X 32461 } X 32462 #endif /* !VMS */ 32463 HTStartAnchor(target, "", relative); 32464 FREE(relative); 1E if (relative) {free(relative); relative = ((void *) 0);} 32465 32466 PUTS(SEGMENT_UP_TO); 1E (*target->isa->put_string)(target, "Up to ") 32467 if (parent) { 32468 if ((0 == strcmp(current,".")) || 32469 (0 == strcmp(current,".."))) { 32470 /* 32471 ** Should not happen, but if it does, 32472 ** at least avoid giving misleading info. - KW 32473 */ 32474 PUTS(".."); 1E (*target->isa->put_string)(target, "..") 32475 } else { 32476 char * printable = NULL; 1E ((void *) 0) 32477 StrAllocCopy(printable, parent + 1); 1E HTSACopy (&(printable), parent + 1) 32478 HTUnEscape(printable); 32479 PUTS(printable); 1E (*target->isa->put_string)(target, printable) 32480 FREE(printable); 1E if (printable) {free(printable); printable = ((void *) 0);} 32481 } 32482 } else { 32483 PUTS("/"); 1E (*target->isa->put_string)(target, "/") 32484 } Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 589 13-APR-1999 09:39:16 HTFILE.C;1 32485 END(HTML_A); 1E (*target->isa->end_element)(target, HTML_A, 0) 32486 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32487 } 32488 #endif /* !NO_PARENT_DIR_REFERENCE */ 32489 32490 FREE(logical); 1E if (logical) {free(logical); logical = ((void *) 0);} 32491 FREE(path); 1E if (path) {free(path); path = ((void *) 0);} 32492 return(need_parent_link); 32493 } 32494 32495 PRIVATE int print_local_dir ARGS5( ............................1 %CC-E-CLOSEPAREN, (1) Missing ")". 1E static 1E (DIR * dp, char * localname, HTParentAnchor * anchor, HTFormat format_out, HTStream * si 1E nk) 32496 DIR *, dp, 32497 char *, localname, 32498 HTParentAnchor *, anchor, 32499 HTFormat, format_out, 32500 HTStream *, sink) 32501 { 32502 HTStructured *target; /* HTML object */ 32503 HTStructuredClass targetClass; 32504 STRUCT_DIRENT * dirbuf; 32505 char *logical = NULL; ....1 %CC-E-BADSTMT, (1) Invalid statement. 1E ((void *) 0) 32506 char *pathname = NULL; ....1 %CC-E-BADSTMT, (1) Invalid statement. 1E ((void *) 0) 32507 char *tail = NULL; ....1 %CC-E-BADSTMT, (1) Invalid statement. 1E ((void *) 0) 32508 BOOL present[HTML_A_ATTRIBUTES]; .........1 %CC-E-NOSEMI, (1) Missing ";". 1E BOOLEAN 1E 25 32509 char * tmpfilename = NULL; ....1 %CC-E-BADSTMT, (1) Invalid statement. 1E ((void *) 0) Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 590 13-APR-1999 09:39:16 HTFILE.C;1 32510 BOOL need_parent_link = FALSE; .........1 %CC-E-NOSEMI, (1) Missing ";". 1E BOOLEAN 1E (0) 32511 struct stat file_info; ....1 %CC-E-BADSTMT, (1) Invalid statement. 32512 int status; ....1 %CC-E-BADSTMT, (1) Invalid statement. 32513 32514 CTRACE(tfp, "print_local_dir() started\n"); 1E if((WWW_TraceFlag))si_fprintf 1E TraceFP() 32515 32516 logical = HTAnchor_address((HTAnchor*)anchor); 32517 pathname = HTParse(logical, "", 32518 PARSE_PATH + PARSE_PUNCTUATION); 1E 4 1E 1 32519 32520 if (!strcmp(pathname,"/")) { 32521 /* 32522 ** Root path. 32523 */ 32524 StrAllocCopy (tail, "/foo/.."); 1E HTSACopy (&(tail), "/foo/..") 32525 } else { 32526 char *p = strrchr(pathname, '/'); /* find last slash */ 32527 32528 if (!p) { 32529 /* 32530 ** This probably should not happen, 32531 ** but be prepared if it does. - KW 32532 */ 32533 StrAllocCopy (tail, "/foo/.."); 1E HTSACopy (&(tail), "/foo/..") 32534 } else { 32535 /* 32536 ** Take slash off the beginning. 32537 */ 32538 StrAllocCopy(tail, (p + 1)); 1E HTSACopy (&(tail), (p + 1)) 32539 } 32540 } 32541 FREE(pathname); 1E if (pathname) {free(pathname); pathname = ((void *) 0);} 32542 32543 if (UCLYhndl_HTFile_for_unspec >= 0) { 32544 HTAnchor_setUCInfoStage(anchor, 32545 UCLYhndl_HTFile_for_unspec, 32546 UCT_STAGE_PARSER, 1E 1 Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 591 13-APR-1999 09:39:16 HTFILE.C;1 32547 UCT_SETBY_DEFAULT); 1E 1 32548 } 32549 32550 target = HTML_new(anchor, format_out, sink); 32551 targetClass = *target->isa; /* Copy routine entry points */ 32552 32553 { int i; 32554 for (i = 0; i < HTML_A_ATTRIBUTES; i++) 1E 25 32555 present[i] = (i == HTML_A_HREF); 1E 6 32556 } 32557 32558 /* 32559 ** The need_parent_link flag will be set if an 32560 ** "Up to " link was not created for a 32561 ** readable parent in HTDirTitles() because 32562 ** LONG_LIST is defined and NO_PARENT_DIR_REFERENCE 32563 ** is not defined so that need we to create the 32564 ** link via an LYListFmtParse() call. - FM 32565 */ 32566 need_parent_link = HTDirTitles(target, 32567 (HTAnchor *)anchor, FALSE); 1E (0) 32568 32569 #ifdef DIRED_SUPPORT X 32570 if (strncmp(anchor->address, "lynxcgi:", 8)) { X 32571 HTAnchor_setFormat((HTParentAnchor *) anchor, WWW_DIRED); X 32572 lynx_edit_mode = TRUE; X 32573 } X 32574 #endif /* DIRED_SUPPORT */ 32575 if (HTDirReadme == HT_DIR_README_TOP) 1E 1 32576 do_readme(target, localname); 32577 32578 32579 { 32580 HTBTree * bt = HTBTree_new((HTComparer)strcmp); 32581 int num_of_entries = 0; /* lines counter */ 32582 32583 _HTProgress (gettext("Reading directory...")); 1E mustshow = (1), HTProgress("Reading directory...") 32584 status = HT_LOADED; /* assume we don't get interrupted */ 1E 200 32585 while ((dirbuf = readdir(dp)) != NULL) { 1E ((void *) 0) 32586 /* 32587 ** While there are directory entries to be read... 32588 */ 32589 char * dirname = NULL; 1E ((void *) 0) 32590 32591 #ifndef DOSPATH 32592 if (dirbuf->d_ino == 0) 32593 /* 32594 ** If the entry is not being used, skip it. Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 592 13-APR-1999 09:39:16 HTFILE.C;1 32595 */ 32596 continue; 32597 #endif 32598 /* 32599 ** Skip self, parent if handled in HTDirTitles() 32600 ** or if NO_PARENT_DIR_REFERENCE is not defined, 32601 ** and any dot files if no_dotfiles is set or 32602 ** show_dotfiles is not set. - FM 32603 */ 32604 if (!strcmp(dirbuf->d_name, ".") /* self */ || 32605 (!strcmp(dirbuf->d_name, "..") /* parent */ && 32606 need_parent_link == FALSE) || 1E (0) 32607 ((strcmp(dirbuf->d_name, "..")) && 32608 (dirbuf->d_name[0] == '.' && 32609 (no_dotfiles || !show_dotfiles)))) 32610 continue; 32611 32612 StrAllocCopy(tmpfilename, localname); 1E HTSACopy (&(tmpfilename), localname) 32613 if (strcmp(localname, "/")) 32614 /* 32615 ** If filename is not root directory. 32616 */ 32617 StrAllocCat(tmpfilename, "/"); 1E HTSACat (&(tmpfilename), "/") 32618 32619 StrAllocCat(tmpfilename, dirbuf->d_name); 1E HTSACat (&(tmpfilename), dirbuf->d_name) 32620 stat(tmpfilename, &file_info); 32621 if (S_ISDIR(file_info.st_mode)) 1E (((file_info.st_mode)& 0170000) == 0040000) 32622 #ifndef DIRED_SUPPORT 32623 HTSprintf0(&dirname, "D%s",dirbuf->d_name); 32624 else 32625 HTSprintf0(&dirname, "F%s",dirbuf->d_name); 32626 /* D & F to have first directories, then files */ 32627 #else X 32628 { X 32629 if (dir_list_style == MIXED_STYLE) X 32630 HTSprintf0(&dirname, " %s/", dirbuf->d_name); X 32631 else if (!strcmp(dirbuf->d_name, "..")) X 32632 HTSprintf0(&dirname, "A%s", dirbuf->d_name); X 32633 else X 32634 HTSprintf0(&dirname, "D%s", dirbuf->d_name); X 32635 } X 32636 else if (dir_list_style == MIXED_STYLE) X 32637 HTSprintf0(&dirname, " %s", dirbuf->d_name); X 32638 else if (dir_list_style == FILES_FIRST) X 32639 HTSprintf0(&dirname, "C%s", dirbuf->d_name); X 32640 /* C & D to have first files, then directories */ X 32641 else X 32642 HTSprintf0(&dirname, "F%s", dirbuf->d_name); X 32643 #endif /* !DIRED_SUPPORT */ 32644 /* 32645 ** Sort dirname in the tree bt. 32646 */ Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 593 13-APR-1999 09:39:16 HTFILE.C;1 32647 HTBTree_add(bt, dirname); 32648 32649 #ifdef DISP_PARTIAL X 32650 /* optimize for expensive operation: */ X 32651 if (num_of_entries % (partial_threshold > 0 ? X 32652 partial_threshold : display_lines) X 32653 == 0) { X 32654 if (HTCheckForInterrupt()) { X 32655 status = HT_PARTIAL_CONTENT; X 32656 break; X 32657 } X 32658 } X 32659 num_of_entries++; X 32660 #endif /* DISP_PARTIAL */ 32661 32662 } /* end while directory entries left to read */ 32663 32664 if (status != HT_PARTIAL_CONTENT) 1E 206 32665 _HTProgress (gettext("OK")); 1E mustshow = (1), HTProgress("OK") 32666 else 32667 CTRACE(tfp, "Reading the directory interrupred by user\n"); 1E if((WWW_TraceFlag))si_fprintf 1E TraceFP() 32668 32669 32670 /* 32671 ** Run through tree printing out in order. 32672 */ 32673 { 32674 HTBTElement * next_element = HTBTree_next(bt,NULL); 1E ((void *) 0) 32675 /* pick up the first element of the list */ 32676 int num_of_entries_partial = 0; /* lines counter */ 32677 32678 char state; 32679 /* I for initial (.. file), 32680 D for directory file, 32681 F for file */ 32682 32683 #ifdef DIRED_SUPPORT X 32684 char test; X 32685 #endif /* DIRED_SUPPORT */ 32686 state = 'I'; 32687 32688 while (next_element != NULL) { 1E ((void *) 0) 32689 char *entry, *file_extra; 32690 32691 StrAllocCopy(tmpfilename,localname); 1E HTSACopy (&(tmpfilename), localname) 32692 if (strcmp(localname, "/")) 32693 /* 32694 ** If filename is not root directory. 32695 */ 32696 StrAllocCat(tmpfilename, "/"); Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 594 13-APR-1999 09:39:16 HTFILE.C;1 1E HTSACat (&(tmpfilename), "/") 32697 32698 StrAllocCat(tmpfilename, 1E HTSACat (&(tmpfilename), (char *)((next_element)->object)+1) 32699 (char *)HTBTree_object(next_element)+1); 32700 /* 32701 ** Append the current entry's filename 32702 ** to the path. 32703 */ 32704 HTSimplify(tmpfilename); 32705 /* 32706 ** Output the directory entry. 32707 */ 32708 if (strcmp((char *) 32709 (HTBTree_object(next_element)), "D..") && 1E ((next_element)->object) 32710 strcmp((char *) 32711 (HTBTree_object(next_element)), "A..")) 1E ((next_element)->object) 32712 { 32713 #ifdef DIRED_SUPPORT X 32714 test = (*(char *)(HTBTree_object(next_element)) X 32715 == 'D' ? 'D' : 'F'); X 32716 if (state != test) { X 32717 #ifndef LONG_LIST X 32718 if (dir_list_style == FILES_FIRST) { X 32719 if (state == 'F') { X 32720 END(HTML_DIR); X 32721 PUTC('\n'); X 32722 } X 32723 } else if (dir_list_style != MIXED_STYLE) X 32724 if (state == 'D') { X 32725 END(HTML_DIR); X 32726 PUTC('\n'); X 32727 } X 32728 #endif /* !LONG_LIST */ X 32729 state = X 32730 (*(char *)(HTBTree_object(next_element)) X 32731 == 'D' ? 'D' : 'F'); X 32732 START(HTML_H2); X 32733 if (dir_list_style != MIXED_STYLE) { X 32734 START(HTML_EM); X 32735 PUTS(state == 'D' X 32736 ? LABEL_SUBDIRECTORIES X 32737 : LABEL_FILES); X 32738 END(HTML_EM); X 32739 } X 32740 END(HTML_H2); X 32741 PUTC('\n'); X 32742 #ifndef LONG_LIST X 32743 START(HTML_DIR); X 32744 PUTC('\n'); X 32745 #endif /* !LONG_LIST */ X 32746 } X 32747 #else 32748 if (state != *(char *)(HTBTree_object( 1E ((next_element)->object) Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 595 13-APR-1999 09:39:16 HTFILE.C;1 32749 next_element))) { 32750 #ifndef LONG_LIST 32751 if (state == 'D') { 32752 END(HTML_DIR); 1E (*target->isa->end_element)(target, HTML_DIR, 0) 32753 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32754 } 32755 #endif /* !LONG_LIST */ 32756 state = 32757 (*(char *)(HTBTree_object(next_element)) 1E ((next_element)->object) 32758 == 'D' ? 'D' : 'F'); 32759 START(HTML_H2); 1E (*target->isa->start_element)(target, HTML_H2, 0, 0, -1, 0) 32760 START(HTML_EM); 1E (*target->isa->start_element)(target, HTML_EM, 0, 0, -1, 0) 32761 PUTS(state == 'D' 1E (*target->isa->put_string)(target, state == 'D' ? "Subdirectories:" : "Files:") 32762 ? LABEL_SUBDIRECTORIES 32763 : LABEL_FILES); 32764 END(HTML_EM); 1E (*target->isa->end_element)(target, HTML_EM, 0) 32765 END(HTML_H2); 1E (*target->isa->end_element)(target, HTML_H2, 0) 32766 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32767 #ifndef LONG_LIST 32768 START(HTML_DIR); 1E (*target->isa->start_element)(target, HTML_DIR, 0, 0, -1, 0) 32769 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32770 #endif /* !LONG_LIST */ 32771 } 32772 #endif /* DIRED_SUPPORT */ 32773 #ifndef LONG_LIST 32774 START(HTML_LI); 1E (*target->isa->start_element)(target, HTML_LI, 0, 0, -1, 0) 32775 #endif /* !LONG_LIST */ 32776 } 32777 entry = (char*)HTBTree_object(next_element)+1; 1E ((next_element)->object) 32778 file_extra = NULL; 1E ((void *) 0) 32779 32780 #ifdef LONG_LIST X 32781 LYListFmtParse(list_format, tmpfilename, target, X 32782 entry, tail); X 32783 #else 32784 HTDirEntry(target, tail, entry); 32785 PUTS(entry); 1E (*target->isa->put_string)(target, entry) 32786 END(HTML_A); 1E (*target->isa->end_element)(target, HTML_A, 0) 32787 if (file_extra) { 32788 PUTS(file_extra); 1E (*target->isa->put_string)(target, file_extra) Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 596 13-APR-1999 09:39:16 HTFILE.C;1 32789 FREE(file_extra); 1E if (file_extra) {free(file_extra); file_extra = ((void *) 0);} 32790 } 32791 MAYBE_END(HTML_LI); 1E if (HTML_dtd.tags[HTML_LI].contents != SGML_EMPTY) (*target->isa->end_element)(target, HTML_LI, 0) 32792 PUTC('\n'); 1E (*target->isa->put_character)(target, '\n') 32793 #endif /* LONG_LIST */ 32794 32795 next_element = HTBTree_next(bt, next_element); 32796 /* pick up the next element of the list; 32797 if none, return NULL*/ 32798 32799 /* optimize for expensive operation: */ 32800 #ifdef DISP_PARTIAL X 32801 if (num_of_entries_partial % X 32802 (partial_threshold > 0 ? partial_threshold : display_lines) X 32803 == 0) { X 32804 /* num_of_entries, num_of_entries_partial... */ X 32805 /* HTReadProgress...(bytes, 0); */ X 32806 HTDisplayPartial(); X 32807 X 32808 if (HTCheckForInterrupt()) { X 32809 _HTProgress (TRANSFER_INTERRUPTED); X 32810 status = HT_PARTIAL_CONTENT; X 32811 break; X 32812 } X 32813 } X 32814 num_of_entries_partial++; X 32815 #endif /* DISP_PARTIAL */ 32816 32817 } /* end while next_element */ 32818 32819 if (status == HT_LOADED) { 1E 200 32820 if (state == 'I') { 32821 START(HTML_P); 1E (*target->isa->start_element)(target, HTML_P, 0, 0, -1, 0) 32822 PUTS("Empty Directory"); 1E (*target->isa->put_string)(target, "Empty Directory") 32823 } 32824 #ifndef LONG_LIST 32825 else 32826 END(HTML_DIR); 1E (*target->isa->end_element)(target, HTML_DIR, 0) 32827 #endif /* !LONG_LIST */ 32828 } 32829 } /* end printing out the tree in order */ 32830 32831 closedir(dp); 32832 FREE(logical); 1E if (logical) {free(logical); logical = ((void *) 0);} 32833 FREE(tmpfilename); 1E if (tmpfilename) {free(tmpfilename); tmpfilename = ((void *) 0);} 32834 FREE(tail); 1E if (tail) {free(tail); tail = ((void *) 0);} 32835 HTBTreeAndObject_free(bt); Source Listing 13-APR-1999 17:06:13 DEC C V5.5-002 Page 597 13-APR-1999 09:39:16 HTFILE.C;1 32836 32837 if (status == HT_LOADED) { 1E 200 32838 if (HTDirReadme == HT_DIR_README_BOTTOM) 1E 2 32839 do_readme(target, localname); 32840 FREE_TARGET; 1E (*target->isa->_free)(target) 32841 } else { 32842 ABORT_TARGET; 1E (*targetClass._abort)(target, ((void *) 0)); 32843 } 32844 } 32845 return status; /* document loaded, maybe partial */ 32846 } From owner-lynx-dev@sig.net Tue Apr 13 14:36:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA05874 for ; Tue, 13 Apr 1999 14:36:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA27191; Tue, 13 Apr 1999 13:24:35 -0500 (CDT) From: dickey@clark.net Message-Id: <199904131824.OAA29049@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2. dev 22 To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 14:24:32 -0400 (EDT) In-Reply-To: <009D6960.7D6CC8D1.1365@alder.cc.kcl.ac.uk> from "Andy Harper " at Apr 13, 99 06:04:08 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1101 Lines: 36 > Trying to build 2.8.2 dev 22 under VMS 6.2 and DEC C results in a number of > problems still. > > First, 'sleep' is undeclared in > Gridtext.c > HTalert.c > LYbookmark.c > LYedit.c > LYjump.c > LYstrings.c > > Second, 'alarm' is undeclared in > LYCurses.c > > All of these are warnings only but still should be fixed. Both are declared > in 'unistd.h' for DEC C > > The files HTutils.h and HTstring.H both include each other. This lead to a > rather repetitious listing in the compilation ugh (one or the other ;-) > HTFILE.C will not compile at all. The error is obscure. The error and an > extract from the listing is enclosed (with all macro expansions etc turned > on). I think it's a mismatched '}' somewhere but I gave up trying to find it! > Lines marked with an X down the left are EXCLUDED by ifdef's. thanks (I'll study this tonight) > Finally, I think DISP_PARTIAL should be defined for the compilation within > BUILD.COM and the DESCRIP.MMS files. ok -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From asgilman@iamdigex.net Tue Apr 13 14:59:45 1999 Received: from relay.interim.iamworld.net (relay.interim.iamworld.net [204.91.241.82]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA06696 for ; Tue, 13 Apr 1999 14:59:40 -0400 Received: from default (pool-209-138-58-16.bltm.grid.net [209.138.58.16]) by relay.interim.iamworld.net (8.9.1a/8.8.8) with SMTP id OAA70901; Tue, 13 Apr 1999 14:59:03 -0400 (EDT) Message-Id: <199904131859.OAA70901@relay.interim.iamworld.net> X-Sender: 10003479@pop.iamdigex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Apr 1999 15:02:48 -0400 To: K0611@co.polk.ia.us From: Al Gilman Subject: where to get Lynx Cc: Lt_KK@hotmail.com In-Reply-To: <199904131513.KAA05408@roadrunner.sig.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Content-Length: 2991 Lines: 96 Kerry, I am confused. Did you visit ? The first two links from there are to distribution points and the third one is to an information site which lists many more. If you want the binary distribution for Windows 95/98, you _will_ have to dig a little because the first kind of distribution you will come across is the source code distribution suitable for Unix/Linux sites. In particular you will eventually find references to: Lynx for DOS 386+ or Win32 http://www.fdisk.com/doslynx/lynxport.htm Win32 version http://www.fdisk.com/doslynx/wlynx/lynx_w32.zip Al PS: no buy. it's free. At 10:13 AM 4/13/99 -0500, you wrote: >>From owner-lynx-dev Tue Apr 13 10:13:50 1999 >Received: from co.polk.ia.us (host5.co.polk.ia.us [207.108.41.12] (may be forged)) by roadrunner.sig.net (8.9.0/8.8.6) with SMTP id KAA05396 for ; Tue, 13 Apr 1999 10:13:49 -0500 (CDT) >Received: from attorney.PC_ATTORNEY [128.128.206.1] by co.polk.ia.us [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 13 Apr 1999 09:53:41 -0500 >Received: from co.polk.ia.us ([128.128.206.51]) by attorney.PC_ATTORNEY > (Post.Office MTA v3.1.2 release (PO205-101c) > ID# 0-42741U100L100S0) with ESMTP id AAA186 > for ; Tue, 13 Apr 1999 09:53:51 -0500 >Message-ID: <37135AC8.22125F6C@co.polk.ia.us> >Date: Tue, 13 Apr 1999 09:55:04 -0500 >From: "Lt. Kerry Kirstein" >X-Mailer: Mozilla 4.51 [en] (Win95; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: lynx-dev@sig.net >Subject: Lynx 2.8 >Content-Type: multipart/mixed; > boundary="------------5756DC69B5D4DFE74D217C83" >X-MDaemon-Deliver-To: lynx-dev@sig.net >X-Return-Path: K0611@co.polk.ia.us >Reply-To: K0611@co.polk.ia.us > >This is a multi-part message in MIME format. >--------------5756DC69B5D4DFE74D217C83 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >So where can one pick up this text only browser. I didn't see any links on any >of your pages for downloading or purchasing this. > ???????????? > >-- >The Truth is Out There ! ! > >******************************* >mailto:K0611@co.polk.ia.us or >mailto:Lt_KK@hotmail.com > >Polk County Sheriff's Office >http://www.co.polk.ia.us/departments/sheriff/auto-index.htm > >Personal Home Page >http://home.att.net/~kirstein/home.htm > > >--------------5756DC69B5D4DFE74D217C83 >Content-Type: text/x-vcard; charset=us-ascii; > name="K0611.vcf" >Content-Transfer-Encoding: 7bit >Content-Description: Card for Lt. Kerry Kirstein >Content-Disposition: attachment; > filename="K0611.vcf" > >begin:vcard >n:Kirstein;Kerry >x-mozilla-html:TRUE >org:Polk County Sheriff's Office >adr:;;110 6th Ave.;Des Moines;Iowa;50309;USA >version:2.1 >email;internet:K0611@co.polk.ia.us >title:Lieutenant >tel;fax:515-286-2081 >tel;work:515-286-3804 / 515-286-2166 >x-mozilla-cpt:;0 >fn:Kerry Kirstein >end:vcard > >--------------5756DC69B5D4DFE74D217C83-- > From owner-lynx-dev@sig.net Tue Apr 13 15:14:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07045 for ; Tue, 13 Apr 1999 15:14:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA10797; Tue, 13 Apr 1999 14:02:16 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 21:05:41 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev prettysrc mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 308 Lines: 7 I check dev22 -prettysrc mode, looks very nice and really useful. One glitch I found is the lost of closing ";" after a named entities, e.g. &ha-ha will be displayed as &ha-ha No problem with numeric entities where ";" restored. Try files sgml.html and unicode.html under the /samples directory. From owner-lynx-dev@sig.net Tue Apr 13 15:16:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07068 for ; Tue, 13 Apr 1999 15:15:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA10965; Tue, 13 Apr 1999 14:02:40 -0500 (CDT) To: lynx-dev@sig.net References: <199904130950.FAA17280@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 20:49:23 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev.22 - USE_PSRC crash MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 751 Lines: 38 dev22 can't build with USE_PSRC *and* without USE_COLOR_STYLE, an obvious fix below: diff -u old/sgml.c ./sgml.c --- old/sgml.c Tue Apr 13 02:39:16 1999 +++ ./sgml.c Tue Apr 13 20:19:56 1999 @@ -34,6 +34,8 @@ #ifdef USE_COLOR_STYLE # include +#endif +#ifdef USE_PSRC # include #endif diff -u old/html.c ./html.c --- old/html.c Tue Apr 13 02:39:16 1999 +++ ./html.c Tue Apr 13 19:18:02 1999 @@ -49,12 +49,15 @@ #include #endif /* VMS */ +#ifdef USE_PSRC +#include +#endif + #ifdef USE_COLOR_STYLE #include #include #include #include -#include #undef SELECTED_STYLES #define pHText_changeStyle(X,Y,Z) {} From owner-lynx-dev@sig.net Tue Apr 13 15:17:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07092 for ; Tue, 13 Apr 1999 15:17:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA11003; Tue, 13 Apr 1999 14:02:46 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 20:53:07 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev.22 - documentation update (patch) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3915 Lines: 75 Few words for CHANGES and INSTALLATION: diff -u old/changes ./changes --- old/changes Tue Apr 13 02:39:16 1999 +++ ./changes Tue Apr 13 20:37:18 1999 @@ -16,7 +16,12 @@ is selectable by a configure option --enable-source-cache and by a lynx.cfg option SOURCE_CACHE; I didn't add a command-line argument or an options menu entry, as this didn't seem to be the sort of thing one would want to change - at runtime. (Scott Bigham ) + at runtime. + You had to challenge me, didn't you? ;) Okay, after some pfutzing + around with HTChunks, I think I've got a working version of memory + caching of source. The SOURCE_CACHE option now has settings FILE, + MEMORY and NONE, with the obvious meanings, defaulting to NONE. + (Scott Bigham ) * amend HTConfirmDefault() logic so that a second character will cause the default response to be returned, e.g,. so that pressing "qq" will make Lynx exit (reported by John Bley) - TD @@ -26,13 +31,13 @@ in LYMain.c, add newlines in HTFile.c for readability of html - LP * change default STARTFILE to the current directory, "." - PW * revised lynx-dev.html - PW -* lynx.cfg and farther included cfg files can be edited from LYNXCFG:/ page +* lynx.cfg and further included cfg files can be edited from LYNXCFG:/ page with the default editor and changes can be activated for the same lynx session. NOT allowed for restricted users (LYRestricted) and occasionally for user mode other than ADVANCED. This is an *experimental* code (reload_read_cfg() in LYMain.c - more work required): currently command-line switches may be lost when overriden by lynx.cfg changes, file paths like - lynx_temp_space and LYCookieFile should not be changed (unwanted results) -LP + lynx_save_space and LYCookieFile should not be changed (unwanted results) -LP * retest PARSE_DEBUG ifdef's (LYMain.c, LYReadCFG.c), minor corrections but found no specific reason for LP's problem with tables, except possibly different effect from "&(value)" versus "(&value)" - TD @@ -91,9 +96,9 @@ * added HTML source syntax highlighting (when option -prettysrc that is added is given to lynx). It's available for lynx compiled with and without lss support (it can be much more beatiful when compiled with lss support - read - lynx.cfg for description). This functionality coexists with old source view - and with -preparsed logic (ie different commandline options make source view - logic different) VH + lynx.cfg for description). The code is ifdef'ed with USE_SRC. + This functionality coexists with old source view and with -preparsed logic + (ie different commandline options make source view logic different) -VH * HTChunkPutc was inlined in SGML.c for better performance -VH * Keeping of Style_className was omitted in HTML.c to increase performance of lynx compiled with lss support. -VH @@ -129,7 +134,7 @@ new HText structure that most likely is never displayed but still pushes another document out of the. cache. Most commonly this occurs when a HTTP error response is received and the user presses 'z' while the resulting alert - message is shown - LW + message is shown - KW * Fix of HTUnEscapeSome in HTParse.c for non-ASCII - KW, PG * tidy up around ed_offset initialization in GridText.c - KED (the patch as given did not compile on a non-ANSI compiler because it used diff -u old/installa ./installa --- old/installa Tue Apr 13 02:39:16 1999 +++ ./installa Tue Apr 13 18:02:00 1999 @@ -366,7 +366,7 @@ --enable-source-cache (define SOURCE_CACHE) Use this option to compile-in support for caching HTML pages locally, - in files. + in files or in memory. Configurable from lynx.cfg --enable-syslog (define SYSLOG_REQUESTED_URLS) Use this option to log NSL requests via syslog(). From owner-lynx-dev@sig.net Tue Apr 13 15:17:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07101 for ; Tue, 13 Apr 1999 15:17:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA09825; Tue, 13 Apr 1999 13:59:47 -0500 (CDT) Message-ID: <19990413125839.F29694@mred.intellistor.com> Date: Tue, 13 Apr 1999 12:58:39 -0600 From: tlhall@royal.net To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx suppport frames? References: <3.0.1.32.19990412120408.008e7c10@sfsu.edu> <19990413102721.C29694@mred.intellistor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19990413102721.C29694@mred.intellistor.com>; from tlhall@royal.net on Tue, Apr 13, 1999 at 10:27:21AM -0600 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 344 Lines: 9 On Tue, Apr 13, 1999 at 10:27:21AM -0600, tlhall@royal.net wrote: > ... > should use the ALT tags, too. oops - I meant the ALT attribute for IMG tags. It look like Blackboard generates the tags (and attributes) for you, so if it asks you for somthing like "text to associate with the image", put something meaningful in there for lynx users. From owner-lynx-dev@sig.net Tue Apr 13 15:23:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07360 for ; Tue, 13 Apr 1999 15:23:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA11053; Tue, 13 Apr 1999 14:02:53 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 13 Apr 1999 22:57:12 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev.22 (followup patch #1) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6648 Lines: 220 Few changes (lost during dev22 patch integration, more things added). Please add this two flags into all DJGPP makefile's under /WWW and /src dirs: diff -u old/makefile.dos ./makefile.dos --- old/makefile.dos Tue Apr 13 02:39:16 1999 +++ ./makefile.dos Tue Apr 13 17:46:24 1999 @@ -13,6 +13,7 @@ CC = gcc MCFLAGS = -O2 -DHAVE_GETBKGD -DDISP_PARTIAL -DUSE_ZLIB \ + -DSOURCE_CACHE -DUSE_PSRC \ -DUSE_EXTERNALS -DCOLOR_CURSES -DNCURSES -DFANCY_CURSES \ -DACCESS_AUTH -DNO_CUSERID -DNOUSERS -DDOSPATH -DNO_TTYTYPE -DNO_UTMP \ -Ichrtrans -I../WWW/library/implementation \ Cut-n-paste typo: diff -u old/htformat.h ./htformat.h --- old/htformat.h Tue Apr 13 02:39:16 1999 +++ ./htformat.h Tue Apr 13 21:49:26 1999 @@ -325,10 +325,10 @@ #include /* -HTFileCopy: Copy a file to a stream +HTMemCopy: Copy a memory chunk to a stream This is used by the protocol engines to send data down a stream, typically one which - has been generated by HTStreamStack. It is currently called by HTParseFile + has been generated by HTStreamStack. It is currently called by HTParseMem */ extern int HTMemCopy PARAMS(( more fixes under /src directory: diff -u old/lycurses.c ./lycurses.c --- old/lycurses.c Tue Apr 13 02:39:16 1999 +++ ./lycurses.c Tue Apr 13 22:35:48 1999 @@ -622,6 +622,7 @@ } #endif /* USE_COLOR_TABLE */ +#ifdef NOTUSED #if defined (DJGPP) && !defined (USE_SLANG) /* * Sorry about making a completely new function, @@ -660,6 +661,10 @@ noecho(); } #else +#endif /* defined (DJGPP) && !defined (USE_SLANG) */ +#endif /* NOTUSED */ + + PUBLIC void start_curses NOARGS { #ifdef USE_SLANG @@ -758,13 +763,15 @@ #else /* Using curses: */ + #ifdef VMS /* * If we are VMS then do initscr() everytime start_curses() * is called! */ initscr(); /* start curses */ -#else /* Unix: */ +#else /* Unix: */ + static BOOLEAN first_time = TRUE; if (first_time) { @@ -827,7 +834,10 @@ lynx_called_initscr = TRUE; #endif /* USE_COLOR_TABLE */ } -#endif /* VMS */ +#ifdef __DJGPP__ + else sock_init(); +#endif /* __DJGPP__ */ +#endif /* not VMS */ /* nonl(); */ /* seems to slow things down */ @@ -862,7 +872,7 @@ LYCursesON = TRUE; } -#endif /* defined (DJGPP) && !defined (USE_SLANG) */ + PUBLIC void lynx_enable_mouse ARGS1(int,state) { diff -u old/lyhistor.c ./lyhistor.c --- old/lyhistor.c Tue Apr 13 02:39:16 1999 +++ ./lyhistor.c Tue Apr 13 22:21:30 1999 @@ -459,6 +459,12 @@ if ((number = atoi(newdoc->address+9)) > nhist || number < 0) return(FALSE); + /* + * Optimization: assume we came from the History Page, + * so never return back - always a new version next time. + */ + HTuncache_current_document(); /* don't waste the cache */ + LYpop_num(number, newdoc); if (((newdoc->internal_link && history[number].intern_seq_start == history[nhist-1].intern_seq_start) || diff -u old/lymain.c ./lymain.c --- old/lymain.c Tue Apr 13 02:39:16 1999 +++ ./lymain.c Tue Apr 13 21:30:54 1999 @@ -1782,7 +1782,8 @@ * mode. Instead of calling cleanup() here, let's only call * this one. - BJP */ - LYStoreCookies(LYCookieFile); + if (persistent_cookies) + LYStoreCookies(LYCookieFile); #endif /* EXP_PERSISTENT_COOKIES */ exit_immediately(status); } else { @@ -1832,6 +1833,7 @@ HTRegisterProtocol(&LYLynxCookies); } +#ifndef NO_CONFIG_INFO /* * Some staff to reload lynx.cfg without restarting new lynx session, * also load options menu items and command-line options @@ -1882,6 +1884,7 @@ } } +#endif /* !NO_CONFIG_INFO */ /* There are different ways of setting arguments on the command line, and @@ -1913,13 +1916,13 @@ #ifdef PARSE_DEBUG #define ParseData BOOLEAN *set_value; int *int_value; char **str_value; ParseFunc fun_value #define PARSE_SET(n,t,v,h) {n,t, v, 0, 0, 0, h} -#define PARSE_INT(n,t,v,h) {n,t, 0, &v, 0, 0, h} +#define PARSE_INT(n,t,v,h) {n,t, 0, v, 0, 0, h} #define PARSE_STR(n,t,v,h) {n,t, 0, 0, v, 0, h} #define PARSE_FUN(n,t,v,h) {n,t, 0, 0, 0, v, h} #else #define ParseData long value #define PARSE_SET(n,t,v,h) {n,t, (long) (v), h} -#define PARSE_INT(n,t,v,h) {n,t, (long)&(v), h} +#define PARSE_INT(n,t,v,h) {n,t, (long) (v), h} #define PARSE_STR(n,t,v,h) {n,t, (long) (v), h} #define PARSE_FUN(n,t,v,h) {n,t, (long) (v), h} #endif @@ -2751,7 +2754,7 @@ "toggles inclusion of ISMAP links when client-side\nMAPs are present" ), PARSE_INT( - "link", NEED_INT_ARG, ccount, + "link", NEED_INT_ARG, &ccount, "=NUMBER\nstarting count for lnk#.dat files produced by -crawl" ), PARSE_SET( @@ -2842,7 +2845,7 @@ "toggles display partial pages while downloading" ), PARSE_INT( - "partial_thres", IGNORE_ARG|INT_ARG, partial_threshold, + "partial_thres", NEED_INT_ARG, &partial_threshold, "[=NUMBER]\nnumber of lines to render before repainting display\n\ with partial-display logic" ), @@ -2862,7 +2865,7 @@ PARSE_SET( "preparsed", SET_ARG, &LYPreparsedSource, "show parsed text/html with -source and in source view\n\ - to visualize how lynx behaves with invalid HTML" +to visualize how lynx behaves with invalid HTML" ), #ifdef USE_PSRC PARSE_SET( diff -u old/lyoption.c ./lyoption.c --- old/lyoption.c Tue Mar 30 09:10:38 1999 +++ ./lyoption.c Tue Apr 13 21:19:30 1999 @@ -3935,6 +3935,7 @@ if (!HTLoadAbsolute(&WWWDoc)) return(NOT_FOUND); + HTuncache_current_document(); /* will never used again */ /* * Return to previous doc, not to options menu! diff -u old/lyreadcf.c ./lyreadcf.c --- old/lyreadcf.c Tue Apr 13 02:39:16 1999 +++ ./lyreadcf.c Tue Apr 13 21:19:50 1999 @@ -1541,7 +1541,7 @@ /* * Some staff to reload read_cfg(), * but also load options menu items and command-line options - * to made things consistent. Not implemented yet. Dummy. + * to made things consistent. Implemented in LYMain.c */ reload_read_cfg(); @@ -1572,6 +1572,7 @@ if (!HTLoadAbsolute(&WWWDoc)) return(NOT_FOUND); + HTuncache_current_document(); /* will never used again */ /* now set up the flag and fall down to create a new LYNXCFG:/ page */ local_url = 0; /* see below */ From asgilman@iamdigex.net Tue Apr 13 15:48:11 1999 Received: from relay.interim.iamworld.net (relay.interim.iamworld.net [204.91.241.82]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07947 for ; Tue, 13 Apr 1999 15:48:08 -0400 Received: from default (pool-209-138-58-16.bltm.grid.net [209.138.58.16]) by relay.interim.iamworld.net (8.9.1a/8.8.8) with SMTP id PAA73302; Tue, 13 Apr 1999 15:47:46 -0400 (EDT) Message-Id: <199904131947.PAA73302@relay.interim.iamworld.net> X-Sender: 10003479@pop.iamdigex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Apr 1999 15:51:39 -0400 To: K0611@co.polk.ia.us From: Al Gilman Subject: Re: Lynx ? In-Reply-To: <37139B70.9614D05E@co.polk.ia.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Content-Length: 2002 Lines: 53 [This is just a small culture clash.] Here's what works: If you get the .zip from the fdisk.com site, you put the .zip file in a virgin folder, unzip it, and read the README that you find there (and what it tells you to read, like the comments in LYNX.BAT). There is no self-installing .exe on the outside, you have to do a little fiddly business first. Warning: This version is not fully consumerized; The instructions are a little thin. Please feel free to write again to lynx-dev@sig.net if it is not working. I get to bail out professional webmasters that work all their life in Windows from time to time. Once you have paths, etc. set up so that starting LYNX.BAT gets you a working web browse session, you can "send [LYNX.BAT] to desktop as shortcut" and a shortcut looking like lynx.ico should show up on your desktop that launches Lynx just like any other Windows Ap. Al At 02:31 PM 4/13/99 -0500, you wrote: >I know a little about DOS and more about windows. but I fail to see the actual >link to Lynx2.8. I found a zip file but did not see any install or setup exe >that would install it. > Please provide the Actual Link to Lynx. > Maybe I'm just stupid but almost any site that has something to download >clearly states it. If Lynx is the zip file, where do the files go, is the >program run by creating a shortcut to the .com file? I found a lot of info on >compiling and long strings of code to configure Lynx but not the actual >program. Plus info on requiring certain libraries ???? All I want is a text >only browser, is this where I can get one with an exe file to install it without >going to college for 14 yrs ? ( hehehe ) > Any help would greatly be appreciated. > >-- >The Truth is Out There ! ! > >******************************* >mailto:K0611@co.polk.ia.us or >mailto:Lt_KK@hotmail.com > >Polk County Sheriff's Office >http://www.co.polk.ia.us/departments/sheriff/auto-index.htm > >Personal Home Page >http://home.att.net/~kirstein/home.htm > > > From owner-lynx-dev@sig.net Tue Apr 13 15:50:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA08152 for ; Tue, 13 Apr 1999 15:50:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA25262; Tue, 13 Apr 1999 14:40:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904131940.PAA17299@shell.clark.net> Subject: Re: lynx-dev dev.22 - USE_PSRC crash To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 15:40:07 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 13, 99 08:49:23 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 996 Lines: 46 > > dev22 can't build with USE_PSRC *and* without USE_COLOR_STYLE, > an obvious fix below: as I understood it, USE_PSRC wasn't workable w/o color-style. > diff -u old/sgml.c ./sgml.c > --- old/sgml.c Tue Apr 13 02:39:16 1999 > +++ ./sgml.c Tue Apr 13 20:19:56 1999 > @@ -34,6 +34,8 @@ > > #ifdef USE_COLOR_STYLE > # include > +#endif > +#ifdef USE_PSRC > # include > #endif > > > diff -u old/html.c ./html.c > --- old/html.c Tue Apr 13 02:39:16 1999 > +++ ./html.c Tue Apr 13 19:18:02 1999 > @@ -49,12 +49,15 @@ > #include > #endif /* VMS */ > > +#ifdef USE_PSRC > +#include > +#endif > + > #ifdef USE_COLOR_STYLE > #include > #include > #include > #include > -#include > #undef SELECTED_STYLES > #define pHText_changeStyle(X,Y,Z) {} > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 16:01:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA08457 for ; Tue, 13 Apr 1999 16:01:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA29035; Tue, 13 Apr 1999 14:50:09 -0500 (CDT) Date: Tue, 13 Apr 1999 15:54:40 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: Lynx Development Subject: Re: lynx-dev lynx2.8.2dev.22 In-Reply-To: <199904130950.FAA17280@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 314 Lines: 10 Instructions at the begining of the patch tell to remove HTFWriter.[ch]. I've done so. When compiling lynx, I've got the following error: ../../../WWW/Library/Implementation/HTFile.c:60: HTFWriter.h: No such file or directory. Removing '#include ' at HTFile.c:60 fixes it. Best regards, -Vlad From owner-lynx-dev@sig.net Tue Apr 13 16:50:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA09919 for ; Tue, 13 Apr 1999 16:50:18 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA15037; Tue, 13 Apr 1999 15:32:27 -0500 (CDT) Date: Tue, 13 Apr 1999 16:29:35 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.22 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 716 Lines: 21 On Tue, 13 Apr 1999, Vlad Harchev wrote: > Instructions at the begining of the patch tell to remove HTFWriter.[ch]. > I've done so. When compiling lynx, I've got the following error: > ../../../WWW/Library/Implementation/HTFile.c:60: HTFWriter.h: No such file or > directory. Gak! Look again: rm -f WWW/Library/Implementation/HTWriter.c rm -f WWW/Library/Implementation/HTWriter.h That's HTWriter, not HTFWriter. But since it compiled for you, I'll look at HTFWriter, but I'm pretty sure it's not dead code. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Tue Apr 13 17:00:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10222 for ; Tue, 13 Apr 1999 17:00:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA20784; Tue, 13 Apr 1999 15:47:44 -0500 (CDT) To: lynx-dev@sig.net, K0611@co.polk.ia.us References: <37135AC8.22125F6C@co.polk.ia.us> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 00:41:35 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx 2.8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 357 Lines: 14 13-Apr-99 09:55 Lt. Kerry Kirstein wrote: > So where can one pick up this text only browser. I didn't see any links on any > of your pages for downloading or purchasing this. > ???????????? Try http://lynx.browser.org > -- > The Truth is Out There ! ! > ******************************* > mailto:K0611@co.polk.ia.us or > mailto:Lt_KK@hotmail.com From owner-lynx-dev@sig.net Tue Apr 13 17:02:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10312 for ; Tue, 13 Apr 1999 17:02:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA20543; Tue, 13 Apr 1999 15:47:07 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 00:24:11 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 445 Lines: 14 13-Apr-99 15:54 Vlad Harchev wrote: > Instructions at the begining of the patch tell to remove HTFWriter.[ch]. > I've done so. When compiling lynx, I've got the following error: > ../../../WWW/Library/Implementation/HTFile.c:60: HTFWriter.h: No such file or > directory. The patch says about HTWriter.[ch] and that is different from HTFWriter.[ch] > Removing '#include ' at HTFile.c:60 fixes it. > Best regards, > -Vlad From owner-lynx-dev@sig.net Tue Apr 13 17:05:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10339 for ; Tue, 13 Apr 1999 17:05:34 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA20740; Tue, 13 Apr 1999 15:47:39 -0500 (CDT) To: lynx-dev@sig.net References: <199904131940.PAA17299@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 00:17:09 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev.22 - USE_PSRC crash MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1182 Lines: 51 13-Apr-99 15:40 dickey@clark.net wrote: >> >> dev22 can't build with USE_PSRC *and* without USE_COLOR_STYLE, >> an obvious fix below: > as I understood it, USE_PSRC wasn't workable w/o color-style. It *is* workable w/o color-style (according to CHANGES, and I test it OK), I guess last-minute changes was not tested in this configuration. >> diff -u old/sgml.c ./sgml.c >> --- old/sgml.c Tue Apr 13 02:39:16 1999 >> +++ ./sgml.c Tue Apr 13 20:19:56 1999 >> @@ -34,6 +34,8 @@ >> >> #ifdef USE_COLOR_STYLE >> # include >> +#endif >> +#ifdef USE_PSRC >> # include >> #endif >> >> >> diff -u old/html.c ./html.c >> --- old/html.c Tue Apr 13 02:39:16 1999 >> +++ ./html.c Tue Apr 13 19:18:02 1999 >> @@ -49,12 +49,15 @@ >> #include >> #endif /* VMS */ >> >> +#ifdef USE_PSRC >> +#include >> +#endif >> + >> #ifdef USE_COLOR_STYLE >> #include >> #include >> #include >> #include >> -#include >> #undef SELECTED_STYLES >> #define pHText_changeStyle(X,Y,Z) {} >> >> > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 17:07:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10365 for ; Tue, 13 Apr 1999 17:07:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA22942; Tue, 13 Apr 1999 15:53:34 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904132052.OAA28360@sanitas> Subject: Re: lynx-dev autoconfigure and host_os dependent CC To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 14:52:57 -0600 (MDT) In-Reply-To: <199904100525.XAA12765@sanitas> from "pg@sweng.stortek.com" at Apr 9, 99 11:25:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2156 Lines: 66 Hello, Lyncei, I've researched this further. In a recent note, pg@sweng.stortek.com said: > Date: Fri, 9 Apr 1999 23:25:36 -0600 (MDT) > > I'd like to make the default C compiler dependent on the > host operating system. > > The original setting apparently happens in macro AC_PROG_CC, called > out of configure.in. But I don't know where to find the definition > of this macro. > In the TODO file with GNU autoconf 2.12, I find: ------------------------------------------------------------------------------ Question: at least one common UNIX variant has a "cc" that is old K&R and "c89" for ANSI C. Is there any reason why AC_PROG_CC couldn't check for c89 before cc if it can't find gcc? hpa@yggdrasil.com (H. Peter Anvin) ------------------------------------------------------------------------------ (I wouldn't call this merely a "common UNIX variant"; it's straight POSIX.) And in: Linkname: Mortice Kern Systems (MKS) Inc. - OS/390 OpenEdition -- GNU Utilities Download Registration URL: http://www.mks.com/s390/gnu/register.htm I find the author has done much work adapting autoconf 2.12 to OS/390. (Lynx works without most of this, but it's probably all necessary somewhere.) But what I was wishing for was: (Thanks to MKS; cite them if you integrate this :-) ================================================================== diff -rc autoconf-2.12/acspecific.m4 mks/autoconf-2.12/acspecific.m4 *** autoconf-2.12/acspecific.m4 Tue Nov 19 22:10:49 1996 --- mks/autoconf-2.12/acspecific.m4 Wed Jan 7 07:43:27 1998 *************** *** 74,81 **** [AC_BEFORE([$0], [AC_PROG_CPP])dnl AC_CHECK_PROG(CC, gcc, gcc) if test -z "$CC"; then ! AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc) ! test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) fi AC_PROG_CC_WORKS --- 74,84 ---- [AC_BEFORE([$0], [AC_PROG_CPP])dnl AC_CHECK_PROG(CC, gcc, gcc) if test -z "$CC"; then ! AC_CHECK_PROG(CC, c89, c89) ! if test -z "$CC"; then ! AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc) ! test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) ! fi fi AC_PROG_CC_WORKS From owner-lynx-dev@sig.net Tue Apr 13 17:08:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10382 for ; Tue, 13 Apr 1999 17:08:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA23274; Tue, 13 Apr 1999 15:54:33 -0500 (CDT) Date: Tue, 13 Apr 1999 16:48:16 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev HTFWriter.c (both of them) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 691 Lines: 20 Why do we have two files named HTFWriter.c? ./src/HTFWriter.c ./WWW/Library/Implementation/HTFWriter.c ./WWW/Library/Implementation/HTFWriter.h The Mozilla folks have decreed thusly: "Every source file must have a unique name." (http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html) They go on to explain that most Mac compilers can't deal with this kind of situation. Sad, really. Anyway, perhaps one of them ought to be renamed, if only to avoid patch confusion. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Tue Apr 13 17:09:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10577 for ; Tue, 13 Apr 1999 17:09:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA20208; Tue, 13 Apr 1999 15:46:26 -0500 (CDT) From: dickey@clark.net Message-Id: <199904132046.QAA28478@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.22 To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 16:46:15 -0400 (EDT) In-Reply-To: from "Vlad Harchev " at Apr 13, 99 03:54:40 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 533 Lines: 23 > > Instructions at the begining of the patch tell to remove HTFWriter.[ch]. that was HTWriter.[ch] (I removed them from my copy, compiled ok - found no problems with John Bley's patches) > I've done so. When compiling lynx, I've got the following error: > ../../../WWW/Library/Implementation/HTFile.c:60: HTFWriter.h: No such file or > directory. > > Removing '#include ' at HTFile.c:60 fixes it. > > Best regards, > -Vlad > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 17:34:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA11157 for ; Tue, 13 Apr 1999 17:34:43 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA04582; Tue, 13 Apr 1999 16:23:59 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 01:17:49 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: STARTFILE patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2205 Lines: 57 13-Apr-99 09:58 Klaus Weide wrote: > Commenting on patch that's now in 2.8.2dev.22: > On Fri, 2 Apr 1999, Philip Webb wrote: >> ! STARTFILE:http://lynx.browser.org/ >> >> # HELPFILE must be defined as a URL and must have a >> # complete path if local: >> --- 33,54 ---- >> # ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system >> #and now your own tweaks. >> >> + # STARTFILE is the default starting URL if none is specified >> + # on the command line or via a WWW_HOME environment variable; >> + # Lynx will refuse to start without a starting URL of some kind. >> + # STARTFILE can be remote, e.g. http://www.w3.org/default.html , >> + # or local, e.g. file://localhost/PATH_TO/FILENAME , >> + # where PATH_TO is replaced with the complete path to FILENAME >> + # using Unix shell syntax and including the device on VMS. >> + # The default offered for ordinary users is their current directory: >> + STARTFILE:. > This change flies in the face of what the documentation says, including the > comments just above it. "." is not a URL! Right. I think the main point of that change was: http://lynx.browser.org often down or ping time very long so another reasonable URL may be a good idea (though not so mnemonic). Probably a HELPFILE (well, may be not a file but URL :) BTW, Subir's page seems no more actively supported, can be pointed to www.slcc.edu or mirror at ftp.digital.com with its nice bandwidth. > More generally, there are quite a few places > - in userdefs.h > - in lynx.cfg > - in ynx_url_support.html > that say that something "must" be a URL. # HELPFILE must be defined as a URL and must have a # complete path if local: # file://localhost/PATH_TO/lynx_help/lynx_help_main.html # Replace PATH_TO with the path to the lynx_help subdirectory # for this distribution (use SHELL syntax including the device # on VMS systems). # The default HELPFILE is: # http://www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html # This should be changed to the local path. # HELPFILE:http://www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html #HELPFILE:file://localhost/PATH_TO/lynx_help/lynx_help_main.html From owner-lynx-dev@sig.net Tue Apr 13 17:38:09 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA11212 for ; Tue, 13 Apr 1999 17:38:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA04967; Tue, 13 Apr 1999 16:24:50 -0500 (CDT) To: lynx-dev@sig.net, hugo.rabson@zetnet.co.uk References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 00:57:31 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Persistent cookies between batch-mode Lynx calls? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1358 Lines: 40 13-Apr-99 16:24 Hugo Rabson wrote: > When compiled / configured properly, Lynx handles Hotmail's cookies > perfectly... when run in interactive mode. > When called from the command line or from within a script, however, Lynx > does not seem able to handle Hotmail's cookies. > Does Lynx clean out / erase its cookie file between sessions (be they > interactive or command line mode)? Does Lynx simply not save/handle cookies > in command line mode? > I'm using these cookie-specific options in /etc/lynx.cfg :- > # SET_COOKIES:TRUE > # ACCEPT_ALL_COOKIES:TRUE > # COOKIE_FILE:~/.lynx_cookies > # PERSISTENT_COOKIES:TRUE > All help is appreciated. :) Could you start lynx with -trace flag both ways and compare Lynx.trace files near the point where lynx send cookies to hotmail and where hotmail return cookies back. Whether they have quotes (") or not? > Hugo > P.S. Reason behind this post: I'm trying to make a script which will login > and retrieve emails from Hotmail; the script uses Lynx & Lynx has until now > been perfect for the job. However, Hotmail has introduced cookies and Lynx > just can't cope in command line mode. > --------Hugo Rabson -------- > Date: 13-Apr-99 Time: 16:17:15 > NT is for the Navy; the Vikings would have used Linux. > ------------------------------------------------------ From owner-lynx-dev@sig.net Tue Apr 13 17:45:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA11443 for ; Tue, 13 Apr 1999 17:45:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA08024; Tue, 13 Apr 1999 16:32:54 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 01:25:47 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev HTFWriter.c (both of them) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 846 Lines: 26 13-Apr-99 16:48 John Bley wrote: > Why do we have two files named HTFWriter.c? > ./src/HTFWriter.c > ./WWW/Library/Implementation/HTFWriter.c > ./WWW/Library/Implementation/HTFWriter.h > The Mozilla folks have decreed thusly: > "Every source file must have a unique name." probably several makefile's from different sources subtrees will not have unique names. > (http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html) > They go on to explain that most Mac compilers can't deal with this kind > of situation. Sad, really. > Anyway, perhaps one of them ought to be renamed, if only to avoid > patch confusion. > -- > John Bley - jbb6@acpub.duke.edu > Duke '99 - English/Computer Science > Since English is a mess, it maps well onto the problem space, > which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Tue Apr 13 18:52:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA13547 for ; Tue, 13 Apr 1999 18:52:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01122; Tue, 13 Apr 1999 17:40:57 -0500 (CDT) Date: Tue, 13 Apr 1999 18:39:22 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev HTFWriter.c (both of them) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 476 Lines: 15 On Wed, 14 Apr 1999, Leonid Pauzner wrote: > > "Every source file must have a unique name." > probably several makefile's from different sources subtrees > will not have unique names. A makefile isn't a source file. Compilers don't generally know too much about them. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Tue Apr 13 19:05:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA13884 for ; Tue, 13 Apr 1999 19:05:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA05151; Tue, 13 Apr 1999 17:55:56 -0500 (CDT) From: dickey@clark.net Message-Id: <199904132255.SAA16899@shell.clark.net> Subject: Re: lynx-dev HTFWriter.c (both of them) To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 18:55:52 -0400 (EDT) In-Reply-To: from "John Bley " at Apr 13, 99 04:48:16 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1001 Lines: 30 > > Why do we have two files named HTFWriter.c? > ./src/HTFWriter.c > ./WWW/Library/Implementation/HTFWriter.c > ./WWW/Library/Implementation/HTFWriter.h I assume it's because the one in ./src is a customization of the one in WWW. There were a few files that I deleted before which were like that, but in this case we're using both. > The Mozilla folks have decreed thusly: > "Every source file must have a unique name." > (http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html) > They go on to explain that most Mac compilers can't deal with this kind > of situation. Sad, really. > > Anyway, perhaps one of them ought to be renamed, if only to avoid > patch confusion. > > -- > John Bley - jbb6@acpub.duke.edu > Duke '99 - English/Computer Science > Since English is a mess, it maps well onto the problem space, > which is also a mess, which we call reality. - Larry Wall -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 19:08:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA13912 for ; Tue, 13 Apr 1999 19:08:34 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA05616; Tue, 13 Apr 1999 17:57:45 -0500 (CDT) From: dickey@clark.net Message-Id: <199904132257.SAA17015@shell.clark.net> Subject: Re: lynx-dev HTFWriter.c (both of them) To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 18:57:42 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 14, 99 01:25:47 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 612 Lines: 21 > > 13-Apr-99 16:48 John Bley wrote: > > Why do we have two files named HTFWriter.c? > > ./src/HTFWriter.c > > ./WWW/Library/Implementation/HTFWriter.c > > ./WWW/Library/Implementation/HTFWriter.h > > > The Mozilla folks have decreed thusly: > > "Every source file must have a unique name." > > probably several makefile's from different sources subtrees > will not have unique names. anyway, the Mozilla folks have been working for a year without producing a release. (let's concentrate on working toward 2.8.2). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 19:22:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA14312 for ; Tue, 13 Apr 1999 19:22:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA09754; Tue, 13 Apr 1999 18:14:39 -0500 (CDT) From: dickey@clark.net Message-Id: <199904132314.TAA20035@shell.clark.net> Subject: Re: lynx-dev dev.22 - USE_PSRC crash To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 19:14:36 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 14, 99 00:17:09 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1682 Lines: 65 > > 13-Apr-99 15:40 dickey@clark.net wrote: > >> > >> dev22 can't build with USE_PSRC *and* without USE_COLOR_STYLE, > >> an obvious fix below: > > > as I understood it, USE_PSRC wasn't workable w/o color-style. > It *is* workable w/o color-style (according to CHANGES, and I test it OK), > I guess last-minute changes was not tested in this configuration. no - I tested what I did, but (I don't see that CHANGES says it would work w/o color style, and from the email that Vlad sent I had this impression. So I made those changes as part of integrating with the configure script. (It may be incorrect, but it was intentional) > > >> diff -u old/sgml.c ./sgml.c > >> --- old/sgml.c Tue Apr 13 02:39:16 1999 > >> +++ ./sgml.c Tue Apr 13 20:19:56 1999 > >> @@ -34,6 +34,8 @@ > >> > >> #ifdef USE_COLOR_STYLE > >> # include > >> +#endif > >> +#ifdef USE_PSRC > >> # include > >> #endif > >> > >> > >> diff -u old/html.c ./html.c > >> --- old/html.c Tue Apr 13 02:39:16 1999 > >> +++ ./html.c Tue Apr 13 19:18:02 1999 > >> @@ -49,12 +49,15 @@ > >> #include > >> #endif /* VMS */ > >> > >> +#ifdef USE_PSRC > >> +#include > >> +#endif > >> + > >> #ifdef USE_COLOR_STYLE > >> #include > >> #include > >> #include > >> #include > >> -#include > >> #undef SELECTED_STYLES > >> #define pHText_changeStyle(X,Y,Z) {} > >> > >> > > > > -- > > Thomas E. Dickey > > dickey@clark.net > > http://www.clark.net/pub/dickey > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 19:54:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA15136 for ; Tue, 13 Apr 1999 19:54:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA14921; Tue, 13 Apr 1999 18:37:18 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 03:34:56 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev prettysrc mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 443 Lines: 12 13-Apr-99 21:05 Leonid Pauzner wrote: > I check dev22 -prettysrc mode, looks very nice and really useful. > One glitch I found is the lost of closing ";" after a named entities, > e.g. &ha-ha will be displayed as &ha-ha > No problem with numeric entities where ";" restored. > Try files sgml.html and unicode.html under the /samples directory. Also, ALT="..." attributes are not translated to display charset in -prettysrc mode. From owner-lynx-dev@sig.net Tue Apr 13 20:14:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA15748 for ; Tue, 13 Apr 1999 20:14:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA21028; Tue, 13 Apr 1999 19:02:46 -0500 (CDT) To: lynx-dev@sig.net References: <199904132314.TAA20035@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 03:53:46 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev.22 - USE_PSRC crash MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2219 Lines: 76 13-Apr-99 19:14 dickey@clark.net wrote: >> >> 13-Apr-99 15:40 dickey@clark.net wrote: >> >> >> >> dev22 can't build with USE_PSRC *and* without USE_COLOR_STYLE, >> >> an obvious fix below: >> >> > as I understood it, USE_PSRC wasn't workable w/o color-style. >> It *is* workable w/o color-style (according to CHANGES, and I test it OK), >> I guess last-minute changes was not tested in this configuration. > no - I tested what I did, but (I don't see that CHANGES says it would work > w/o color style, and from the email that Vlad sent I had this impression. * added HTML source syntax highlighting (when option -prettysrc that is added is given to lynx). It's available for lynx compiled with and without lss ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ support (it can be much more beatiful when compiled with lss support - read lynx.cfg for description). This functionality coexists with old source view and with -preparsed logic (ie different commandline options make source view logic different) VH > So I made those changes as part of integrating with the configure script. > (It may be incorrect, but it was intentional) >> >> >> diff -u old/sgml.c ./sgml.c >> >> --- old/sgml.c Tue Apr 13 02:39:16 1999 >> >> +++ ./sgml.c Tue Apr 13 20:19:56 1999 >> >> @@ -34,6 +34,8 @@ >> >> >> >> #ifdef USE_COLOR_STYLE >> >> # include >> >> +#endif >> >> +#ifdef USE_PSRC >> >> # include >> >> #endif >> >> >> >> >> >> diff -u old/html.c ./html.c >> >> --- old/html.c Tue Apr 13 02:39:16 1999 >> >> +++ ./html.c Tue Apr 13 19:18:02 1999 >> >> @@ -49,12 +49,15 @@ >> >> #include >> >> #endif /* VMS */ >> >> >> >> +#ifdef USE_PSRC >> >> +#include >> >> +#endif >> >> + >> >> #ifdef USE_COLOR_STYLE >> >> #include >> >> #include >> >> #include >> >> #include >> >> -#include >> >> #undef SELECTED_STYLES >> >> #define pHText_changeStyle(X,Y,Z) {} >> >> >> >> >> >> >> > -- >> > Thomas E. Dickey >> > dickey@clark.net >> > http://www.clark.net/pub/dickey >> >> > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 20:26:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA16050 for ; Tue, 13 Apr 1999 20:26:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA22830; Tue, 13 Apr 1999 19:10:12 -0500 (CDT) From: tvassila@Siac.COM Message-Id: <199904132315.TAA25325@pub.siac.com> X-Count: 2 Date: Tue, 13 Apr 1999 19:15:26 -0400 Organization: SIAC X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/879) Mime-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev Client-Side-Pull Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 148 Lines: 4 Why can't one configure Lynx to activate Client-side pull , , has anybody done this. From owner-lynx-dev@sig.net Tue Apr 13 20:29:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA16078 for ; Tue, 13 Apr 1999 20:29:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA25073; Tue, 13 Apr 1999 19:19:37 -0500 (CDT) From: dickey@clark.net Message-Id: <199904140019.UAA01753@shell.clark.net> Subject: Re: lynx-dev dev.22 - USE_PSRC crash To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 20:19:33 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 14, 99 03:53:46 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 805 Lines: 17 > > no - I tested what I did, but (I don't see that CHANGES says it would work > > w/o color style, and from the email that Vlad sent I had this impression. > > * added HTML source syntax highlighting (when option -prettysrc that is added > is given to lynx). It's available for lynx compiled with and without lss > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > support (it can be much more beatiful when compiled with lss support - read > lynx.cfg for description). This functionality coexists with old source view > and with -preparsed logic (ie different commandline options make source view > logic different) VH thanks (I looked right at that and saw only the spelling error) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 20:54:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA16828 for ; Tue, 13 Apr 1999 20:54:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA29808; Tue, 13 Apr 1999 19:39:46 -0500 (CDT) Message-Id: <199904140033.VAA30845@bigboss.urbi.com.br> To: lynx-dev@sig.net From: "Frederic L.W.Meunier" Subject: lynx-dev lynx devel and pre + ssl support: patches? Date: Tue, 13 Apr 1999 21:33:22 +0000 X-Mailer: Urbi Network WebMail Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 397 Lines: 11 Hi. Anyone here make patches for all the devel and pre versions of Lynx and can place them on a download location? Or the patch can be included in the tarball? I don't know if it's prohibited to put the patch, since you're not obliged to use it. Thanks in advance. ---------------------------------------------------- Essa mensagem foi enviada pelo Webmail Urbi Network http://www.urbi.com.br/ From owner-lynx-dev@sig.net Tue Apr 13 20:55:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA16841 for ; Tue, 13 Apr 1999 20:55:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00423; Tue, 13 Apr 1999 19:42:29 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 04:37:49 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev.22 (followup patch #2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 5218 Lines: 131 Please add this also: diff -u -s old/gridtext.c ./gridtext.c --- old/gridtext.c Tue Apr 13 02:39:16 1999 +++ ./gridtext.c Tue Apr 13 23:11:32 1999 @@ -6193,7 +6193,8 @@ } else { format = HTFileFormat(HTMainText->source_cache_file, NULL, NULL); format = HTCharsetFormat(format, HTMainText->node_anchor, - UCLYhndl_HTFile_for_unspec); + UCLYhndl_for_unspec); + /* not UCLYhndl_HTFile_for_unspec - we are talking about remote documents... */ } CTRACE(tfp, " Content type is \"%s\"\n", format->name); diff -u -s old/htaccess.c ./htaccess.c --- old/htaccess.c Tue Apr 13 02:39:16 1999 +++ ./htaccess.c Tue Apr 13 23:30:44 1999 @@ -580,6 +580,11 @@ UCAssume_MIMEcharset = NULL; StrAllocCopy(UCAssume_MIMEcharset, anchor_UCI->MIMEname); pushed_assume_LYhndl = anchor_LYhndl; + /* some diagnostics */ + if (UCLYhndl_for_unspec != anchor_LYhndl) + CTRACE(tfp, "LYUCPushAssumed: UCLYhndl_for_unspec changed %d -> %d\n", + UCLYhndl_for_unspec, + anchor_LYhndl); UCLYhndl_for_unspec = anchor_LYhndl; return; } @@ -592,9 +597,15 @@ * UCLYhndl_for_unspec used for charset "assuming" from the values * saved by LYUCPushAssumed, if any. - kw */ -PRIVATE int LYUCPopAssumed NOARGS +PUBLIC int LYUCPopAssumed NOARGS { + if (pushed_assume_LYhndl >= 0) { + /* some diagnostics */ + if (UCLYhndl_for_unspec != pushed_assume_LYhndl) + CTRACE(tfp, "LYUCPopAssumed: UCLYhndl_for_unspec changed %d -> %d\n", + UCLYhndl_for_unspec, + pushed_assume_LYhndl); UCLYhndl_for_unspec = pushed_assume_LYhndl; pushed_assume_LYhndl = -1; FREE(UCAssume_MIMEcharset); diff -u -s old/htaccess.h ./htaccess.h --- old/htaccess.h Wed Mar 17 19:17:12 1999 +++ ./htaccess.h Tue Apr 13 23:11:32 1999 @@ -305,6 +305,7 @@ extern void LYUCPushAssumed PARAMS(( HTParentAnchor * anchor)); +extern int LYUCPopAssumed NOPARAMS; #endif /* HTACCESS_H */ /* diff -u -s old/lycharse.c ./lycharse.c --- old/lycharse.c Tue Apr 13 02:39:16 1999 +++ ./lycharse.c Tue Apr 13 23:11:32 1999 @@ -396,6 +396,8 @@ PUBLIC void HTMLSetCharacterHandling ARGS1(int,i) { int chndl = safeUCGetLYhndl_byMIME(UCAssume_MIMEcharset); + BOOLEAN LYRawMode_flag = LYRawMode; + int UCLYhndl_for_unspec_flag = UCLYhndl_for_unspec; if (LYCharSet_UC[i].enc != UCT_ENC_CJK) { HTCJK = NOCJK; @@ -483,6 +485,19 @@ ena_csi((LYlowest_eightbit[current_char_set] > 155)); + + /* some diagnostics */ + if (TRACE) { + if (LYRawMode_flag != LYRawMode) + CTRACE(tfp, "HTMLSetCharacterHandling: LYRawMode changed %s -> %s\n", + (LYRawMode_flag ? "ON" : "OFF"), + (LYRawMode ? "ON" : "OFF")); + if (UCLYhndl_for_unspec_flag != UCLYhndl_for_unspec) + CTRACE(tfp, "HTMLSetCharacterHandling: UCLYhndl_for_unspec changed %d -> %d\n", + UCLYhndl_for_unspec_flag, + UCLYhndl_for_unspec); + } + return; } diff -u -s old/lymainlo.c ./lymainlo.c --- old/lymainlo.c Tue Apr 13 02:39:16 1999 +++ ./lymainlo.c Wed Apr 14 04:32:12 1999 @@ -250,7 +250,7 @@ BOOLEAN rlink_allowed; BOOLEAN vi_keys_flag = vi_keys; BOOLEAN emacs_keys_flag = emacs_keys; - BOOLEAN LYRawMode_flag = LYRawMode; + BOOLEAN LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifndef NO_OPTION_MENU BOOLEAN LYSelectPopups_flag = LYSelectPopups; BOOLEAN verbose_img_flag = verbose_img; @@ -4037,7 +4037,7 @@ CurrentCharSet_flag != current_char_set || CurrentAssumeCharSet_flag != UCLYhndl_for_unspec || verbose_img_flag != verbose_img || - LYRawMode_flag != LYRawMode || + LYUseDefaultRawMode_flag != LYUseDefaultRawMode || LYSelectPopups_flag != LYSelectPopups || ((strcmp(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")) || @@ -4113,7 +4113,7 @@ CurrentAssumeCharSet_flag = UCLYhndl_for_unspec; show_dotfiles_flag = show_dotfiles; verbose_img_flag = verbose_img; - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; LYSelectPopups_flag = LYSelectPopups; StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); @@ -5626,7 +5626,7 @@ LYUseDefaultRawMode = !LYUseDefaultRawMode; HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; From owner-lynx-dev@sig.net Tue Apr 13 21:35:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA17920 for ; Tue, 13 Apr 1999 21:35:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10468; Tue, 13 Apr 1999 20:26:58 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904140126.TAA01251@sanitas> Subject: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 19:26:23 -0600 (MDT) In-Reply-To: <199904130950.FAA17280@shell.clark.net> from "dickey@clark.net" at Apr 13, 99 05:50:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 994 Lines: 32 In a recent note, dickey@clark.net said: > Date: Tue, 13 Apr 1999 05:50:02 -0400 (EDT) > 1999-04-13 (2.8.2dev.22) > * revised lynx-dev.html - PW I notice this: --- lynx-dev.html Sat Oct 10 14:53:16 1998 +++ ../../../lynx2.8.2dev.22/lynx2-8-2/lynx_help/lynx-dev.html Tue Apr 13 03:39:16 1999 @@ -7,116 +7,128 @@ -[ Lynx-Dev Archives | +[ Lynx-Dev Archive | About Lynx ] [ snip ! ] drops me into an intro page, rather than an index of months. If it were my choice, I'd back this off -- it's one more transaction to get to the meat of the archive. But maybe this is a power user's bias, and a beginner needs to view the intro. OTOH, the first link on the index of months is a well-marked pointer to the intro for anyone who needs it. Just my $0.02. I generally appreciate the attention PW gives to the Lynx documentation. -- gil From owner-lynx-dev@sig.net Tue Apr 13 21:54:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA18459 for ; Tue, 13 Apr 1999 21:54:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA14883; Tue, 13 Apr 1999 20:45:39 -0500 (CDT) From: dickey@clark.net Message-Id: <199904140145.VAA21097@shell.clark.net> Subject: Re: lynx-dev dev.22 (followup patch #2) To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 21:45:36 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 14, 99 04:37:49 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 311 Lines: 15 > > Please add this also: on my list... > > diff -u -s old/gridtext.c ./gridtext.c > --- old/gridtext.c Tue Apr 13 02:39:16 1999 > +++ ./gridtext.c Tue Apr 13 23:11:32 1999 > @@ -6193,7 +6193,8 @@ > } else { -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 21:56:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA18485 for ; Tue, 13 Apr 1999 21:56:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA15359; Tue, 13 Apr 1999 20:47:45 -0500 (CDT) From: dickey@clark.net Message-Id: <199904140147.VAA21262@shell.clark.net> Subject: Re: lynx-dev lynx devel and pre + ssl support: patches? To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 21:47:41 -0400 (EDT) In-Reply-To: <199904140033.VAA30845@bigboss.urbi.com.br> from "Frederic L.W.Meunier" " at Apr 13, 99 09:33:22 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 482 Lines: 14 > > Hi. Anyone here make patches for all the devel and pre versions of Lynx and can > place them on a download location? Or the patch can be included in the tarball? > I don't know if it's prohibited to put the patch, since you're not obliged to > use it. Thanks in > advance. sorry - we don't put the ssl patch on sol.slcc.edu (from time to time, we do update the ssl patch to track the devel version). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 13 22:32:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA19625 for ; Tue, 13 Apr 1999 22:32:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA22874; Tue, 13 Apr 1999 21:20:02 -0500 (CDT) From: Philip Webb Message-Id: <199904140219.WAA18046@chass.utoronto.ca> Subject: Re: lynx-dev Lynx 2.8 To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 22:19:54 -0400 (EDT) Cc: k0611@co.polk.ia.us In-Reply-To: <37135AC8.22125F6C@co.polk.ia.us> from "Lt. Kerry Kirstein" at Apr 13, 99 09:55:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 924 Lines: 19 990413 Kerry Kerstein wrote: > So where can one pick up this text only browser. I didn't see any links > on any of your pages for downloading or purchasing this. wherever you thought you were sending your message, it ended up at the Lynx developers' mailing list, an appropriate place: Lynx is free software, supported by an international co-op of volunteers. you can get the latest release of Lynx (2-8-1) from http://www.slcc.edu/lynx/release . if you are a Windows user, you may want a binary (compiled) version: try www.fdisk.com/doslynx/lynxport.htm or www.crl.com/~subir/lynx/binaries.html . ask again here if you encounter serious problems. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 22:35:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA19637 for ; Tue, 13 Apr 1999 22:35:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA24011; Tue, 13 Apr 1999 21:25:30 -0500 (CDT) From: Philip Webb Message-Id: <199904140225.WAA18412@chass.utoronto.ca> Subject: Re: lynx-dev lynx devel and pre + ssl support: patches? To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 22:25:23 -0400 (EDT) Cc: marseille@urbi.com.br In-Reply-To: <199904140033.VAA30845@bigboss.urbi.com.br> from "Frederic L.W.Meunier" at Apr 13, 99 09:33:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 686 Lines: 15 990413 Frederic Meunier wrote: > Anyone here make patches for all the devel and pre versions of Lynx > and can place them on a download location? > Or the patch can be included in the tarball? due to US national-security laws & copyright/patent concerns, Lynx does not distribute encryption patches. you can obtain them from www.moxienet.com/lynx . also see Lynx help -- `h' -- for sites which offer help for SSL. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 13 23:48:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA21480 for ; Tue, 13 Apr 1999 23:48:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA08856; Tue, 13 Apr 1999 22:31:36 -0500 (CDT) From: Philip Webb Message-Id: <199904140331.XAA22421@chass.utoronto.ca> Subject: Re: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Tue, 13 Apr 1999 23:31:31 -0400 (EDT) In-Reply-To: <199904140126.TAA01251@sanitas> from "pg@sweng.stortek.com" at Apr 13, 99 07:26:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1342 Lines: 31 990413 pg commented on my revision of lynx-dev.html : > -[ Lynx-Dev Archives | > +[ Lynx-Dev Archive | > drops me into an intro page, rather than an index of months. this was deliberate, for the reason you devine below. > If it were my choice, I'd back this off -- > it's one more transaction to get to the meat of the archive. > maybe this is a power user's bias & a beginner needs to view the intro. yes, my documentation updates are always done with naive users in mind, tho' not to pamper them or ignore more experienced users. > the first link on the index of months is a well-marked pointer > to the intro for anyone who needs it. yes: maybe it's a matter of taste; certainly, a gripelet i'm not going to pursue if anyone wants to alter it. > I generally appreciate the attention PW gives to Lynx documentation. thanx lots: i have been feeling a bit unappreciated, esp with the pedantic nits'n'rants from people who never seem to work on documentation themselves. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 00:35:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22812 for ; Wed, 14 Apr 1999 00:35:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA19281; Tue, 13 Apr 1999 23:24:39 -0500 (CDT) Message-ID: <19990413212352.60289@shell3.ba.best.com> Date: Tue, 13 Apr 1999 21:23:52 -0700 From: Kim DeVaughn To: Lynx Developers Subject: Re: lynx-dev dev.22 lynx_dev.html Mail-Followup-To: Lynx Developers References: <199904140126.TAA01251@sanitas> <199904140331.XAA22421@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <199904140331.XAA22421@chass.utoronto.ca>; from Philip Webb on Tue, Apr 13, 1999 at 11:31:31PM -0400 Organization: Kim's Home for Wayward Cocktail Waitresses & Hors d'oeuvre Girls Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 484 Lines: 12 On Tue, Apr 13, 1999, Philip Webb (purslow@chass.utoronto.ca) said: | | thanx lots: i have been feeling a bit unappreciated, | esp with the pedantic nits'n'rants from people | who never seem to work on documentation themselves. Consider this another "thank you" then, for adding in some documentation about the TEXTAREA editing/etc. functions. I *do* appreciate your efforts in doing so, since I've been too busy to put the information down in the proper format and document. /kim From owner-lynx-dev@sig.net Wed Apr 14 01:07:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA23755 for ; Wed, 14 Apr 1999 01:07:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA24332; Tue, 13 Apr 1999 23:57:26 -0500 (CDT) From: Philip Webb Message-Id: <199904140457.AAA26242@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 00:57:19 -0400 (EDT) In-Reply-To: from "Klaus Weide" at Apr 13, 99 09:58:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7273 Lines: 150 990413 KW commented on my update of STARTFILE info in lynx.cfg : >> # STARTFILE is the default starting URL if none is specified >> # on the command line or via a WWW_HOME environment variable; >> # Lynx will refuse to start without a starting URL of some kind. >> # STARTFILE can be remote, e.g. http://www.w3.org/default.html , >> # or local, e.g. file://localhost/PATH_TO/FILENAME , >> # where PATH_TO is replaced with the complete path to FILENAME >> # using Unix shell syntax and including the device on VMS. >> # The default offered for ordinary users is their current directory: >> STARTFILE:. > This change flies in the face of what the documentation says, > including the comments just above it. so the documentation needs further improvement: your turn ... > "." is not a URL! More generally, there are quite a few places > - in userdefs.h > - in lynx.cfg > - in ynx_url_support.html > that say that something "must" be a URL. > !! URLs are not filenames. Filenames are not URLs. !! > a local file URL is not just a filename prefixed with "file://localhost". > a local filename is not just a file: URL stripped of "file://localhost". > That happens to be true only sometimes, and then only for some OSs. in the absence of a proper account of exceptions, i would maintain that in the context of everyday browsing, a local file URL is a filename prefixed with file://localhost & a local filename may be used as a practical abbreviation for a complete local file URL which includes file://localhost ; . is then a double abbreviation for a local file URL. i may also have views about angels & pins, but that's off topic. the following discussion seems related solely to documentation: > Some of the "must"s are not technically required. > They should probably be replaced by "should"s. > This applies for everything that Lynx passes through a pair of > LYFillLocalFileURL(...); > LYEnsureAbsoluteURL(...); calls: > at least startfile, homepage, 'g'/'G' URLs. > which Lynx tries to convert to URLs if they aren't already. > It's described in lynx_url_support.html , > in the section from "When entering a URL on the command line..." > to "These expansions are SOLELY for startfile or 'g'oto entries!" > but "SOLELY" may not be true any more(??). > Anyway, something like "/home/myname/" or "." is not a URL > in terms of lynx_url_support.html , no matter how you slice it. > Putting 'note: STARTFILE must be a URL' directly followed > by '#define STARTFILE "."' in userdefs.h just increases the confusion. ^^^^^^^^^^ lynx.cfg ? > To *decrease* the confusion, it should be stated clearly what is what: > what kind of object is expected by each lynx.cfg option, > userdefs.h #define etc. There are at least three kinds of objects: > - 'real' (absolute) URLs > - the tentative URLs above. > Let's give them a name for reference: say U-URL (user URL). > lynx_url_support.html should document what forms are acceptable, > in addition to strict 'real' URLs. > lynx.cfg, userdefs.h, 'g'oto help should say where a U-URL is allowed. > - filenames. Things that aren't converted to URLs at all. > This is only a broad classification. > Some filenames are further treated specially > (like bookmark files, sometimes they are supposed to start with './' > where '.' stands for the home dir). > VMS code defines a 'Unix syntax' even for most (all?) non-URL filenames. > Windows/DOS code may accept Unix form for some filenames. And so on... this seems to contain lots of sense: i look forward to your patches. > The patch (without doc changes) increases the discrepancy > between documentation and reality, ditto > but I also question its usefulness. Is it a good thing > to start with browsing the *current* directory by default? on further thought, i agree with LP: best default is Main Help Page. can TD change that by hand for dev.23 ? > I guess Philip got tired of seeing all the problems people are having > with lynx refusing to start, yes, of course. > but in most cases this change just hides or defers the problem. > In most cases (I assume) people *want* to make a network connection. > So now they'll see Lynx start up and not exit immediately, > but if there network is somehow misconfigured they still can't go anywhere; > and if the problem is just that they haven't configured lynx > (when they would want to), it also doesn't help much. no: you haven't been following users' inquiries closely enough. the problem arises when l.b.o. is down -- not infrequently -- , so that Lynx refuses to start & the user can't even enter h ; this could happen with any remote site, so the solution has to be to make the default a local URL: it has to be one we know will always be available, which makes the Main Help Page the best choice, as there may be systems which won't understand . , but given such a default, we can be confident they can at least get started. typically, queries come from people using a shared Lynx, whose invariably overworked sysadmin hasn't changed the default. > Anyway, I suggest it would be better to at least start with > the user's home directory by default, instead of '.'. > this can be specified in URL form: "file://localhost/~/" should work. that's another possibility, but Main Help Page seems better. >> # *** NBB *** System administrators with ANONYMOUS USERS !!! >> # set STARTFILE to a REMOTE FILE by uncommenting the next line: >> #STARTFILE:http://lynx.browser.org/ >> # and commenting out the default offered above; >> # you may, of course, choose to replace `lynx.browser.org' >> # with another remote/local file which you know to be safe. > It doesn't make much sense to ask system administrators > with ANONYMOUS USERS (them and only them) to set STARTFILE > to "http://lynx.browser.org/" or to a 'REMOTE FILE'. > Those are probably exactly the folks who want to point STARTFILE > to a specific (probably local) location. Not just 'you may', they SHOULD. well yes, but we don't know which local location, do we? and we have to have a very simple default they can substitute or we'll have Henry (grin) screaming that the sky is falling. by all means, add 1 - 2 lines of further advice: your patch? > OTOH it looks now as if http://lynx.browser.org/ were only suggested > for those administrators with ANONYMOUS USERS, not for others. > It should be suggested as an alternative for everyone. > Even better, it should be more strongly suggested > that folks actually change STARTFILE to *what they want*. as i said: your patch? >> # Lynx will refuse to start without a starting URL of some kind. > It isn't actually possible to *not* have a starting URL of some kind. > There's the userdefs.h default, lynx can't even be compiled without it > (as you have noticed); so this doesn't make sense. `Lynx will refuse to start if it cannot find a starting URL of some kind': your patch? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 01:37:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA24519 for ; Wed, 14 Apr 1999 01:37:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA29090; Wed, 14 Apr 1999 00:24:43 -0500 (CDT) Date: Wed, 14 Apr 1999 14:36:09 +0900 (JST) From: Henry Nelson Message-Id: <199904140536.OAA14624@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2330 Lines: 45 > > The patch (without doc changes) increases the discrepancy between > > documentation and reality, but I also question its usefulness. I sincerely believe that the default for STARTFILE should remain "http://lynx.browser.org/". 1) It is the official (Well, as official as one can get.) site for Lynx. Analogous to a new installation of MSIE sending you to Microsoft, I think the developers deserve to have a new installation of Lynx take a newcomer to the Lynx Homepage. There is useful information on that page, including information on how to get help. Traditionally the STARTFILE has been a generic page to provide information about Lynx and setup entry points to learn about its use. Before there was a home page, it was "http://www.nyu.edu/pages/wsn/subir/lynx.html", and though it predates me, probably ukans before that. . 2) As Klaus has already pointed out, if you succeed in accessing lynx.browser.org, then you can be sure that Lynx is functional. Just being able to access local files says nothing about getting onto the Web, where most people want to go. Networking problems come hand in hand with Lynx. It is true that lynx.browser.org is not the most stable or fast site around, but quite often as not it is not the source of problems. 3) Rather than making "." the default, I could see it documented, in lynx.cfg and perhaps also PROBLEMS, as one step in the process of debugging network problems. > > > ! # *** NBB *** System administrators with ANONYMOUS USERS !!! > > > ! # set STARTFILE to a REMOTE FILE by uncommenting the next line: > > > ! #STARTFILE:http://lynx.browser.org/ > > > ! # and commenting out the default offered above; > > > ! # you may, of course, choose to replace `lynx.browser.org' > > > ! # with another remote/local file which you know to be safe. All of this discussion about public access and STARTFILE should be removed from lynx.cfg. In its present form, it is misleading. More important to ANONYMOUS is being aware of command line switches like -validate and -homepage, knowing how to compile in STARTFILE, and being sure Lynx reads the intended lynx.cfg in the first place. __Henry From owner-lynx-dev@sig.net Wed Apr 14 02:08:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25328 for ; Wed, 14 Apr 1999 02:08:15 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA03105; Wed, 14 Apr 1999 00:53:58 -0500 (CDT) From: Philip Webb Message-Id: <199904140553.BAA27761@chass.utoronto.ca> Subject: Re: lynx-dev jumping around To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 01:53:50 -0400 (EDT) In-Reply-To: from "Klaus Weide" at Apr 13, 99 05:56:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3686 Lines: 79 990413 Klaus Weide enlightened me: >> i have an URL in my bookmark file & now jumps file >> http://www.tor.ec.gc.ca/forecasts/forecast.cgi?city=Toronto&province=Ontario >> (of course, it's in the proper anchor setting). >> when i use the bookmark or jumps listing, there's no problem; >> when i enter j then w (the short-cut), i get a screen telling me >> i haven't entered the full URL: it seems to be www.tor.ec.gc.ca/ only; > ======================================= > What do you mean by that? www.tor.ec.gc.ca/ is not a URL. > I doubt that the INFO page says URL: www.tor.ec.gc.ca/ it says (centred in the original): weather.ec.gc.ca Thanks for visiting weather.ec.gc.ca! [1]http://weather.ec.gc.ca/ this is NOT the page i reach via the bookmark's full URL above: this page suggests adding the ? and & bits to get the local forecast. >> even stranger, = tells me i have reached the proper destination, >> which is a simple Toronto weather outline & forecast. > What's the URL according to the INFO page? Does it have '&'? it says (with formatting): File that you are currently viewing Linkname: weather.ec.gc.ca URL: http://www.tor.ec.gc.ca/forecasts/forecast.cgi?city=Toronto& ;province=Ontario this is a bug in Lynx: that's not the document i am viewing. > The problem in this specific case seems to be the '&'. > Yes, it's more correct than just writing '&', > but mechanism B doesn't understand it > and simple '&' should also work for method A. So just change it. yes, that does get me to the usual weather-forecast page. > Shortcut files are being read by 2 completely different mechanisms, > plus one for reading JUMPFILE from lynx.cfg . > A. normal HTML parsing: treated like any other text/html file, > with everything that entails. That's what is used > when you actually 'go to' or 'jump to' (with '?') the shortcut file. > B. the 'shortcut way': file is read *once* (on first use of the jump key), > a list of (shortcut name, target URL) pairs is built, > the list doesn't change until program exit. > Mechanism B doesn't know much about HTML. > That's why it may break if the format is too different from the samples > (similar problem as with bookmark files). It also doesn't know anything > about entity unescaping, the URL strings are just used as they are found. it's good to be enlightened, as always, but how would anyone ever know that? even more important, why are things arranged that way? and to repeat the PITA from my other message, why doesn't Lynx re-read the jumps file after ^r when viewing the list? it should be very simple: where should i look to make the correction? to emphasise the point, if i now want to use j to get the weather, i shall have to restart the Lynx i have running under Screen, which already has a lot of cookie choices, passwords etc nicely stored, which i will have to re-enter here & there. then there's my 3rd gripe: jumps refuses to recognise short-cut names if they aren't in alphabetical order: is there any reason for this? this is all another example of the way Lynx was obviously thrown together in the early days with hasty documentation aimed at sysadmins, but has never been revised & cleaned up for more upto-date needs. no criticism of anyone, but a need to focus attention on such things. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 02:18:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25592 for ; Wed, 14 Apr 1999 02:18:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA04561; Wed, 14 Apr 1999 01:06:29 -0500 (CDT) Date: Wed, 14 Apr 1999 15:18:01 +0900 (JST) From: Henry Nelson Message-Id: <199904140618.PAA14881@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev dev.22 lynx_dev.html Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 401 Lines: 11 > > I generally appreciate the attention PW gives to Lynx documentation. > > thanx lots: i have been feeling a bit unappreciated, Well, here's another message of appreciation to cheer you up.
You gotta learn to roll with the punches on this list. Everyone
and his brother has their own idea about the best way to do things.

Anyway, thanks for the docs and help to newbies!

__Henry From owner-lynx-dev@sig.net Wed Apr 14 02:54:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26595 for ; Wed, 14 Apr 1999 02:54:57 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA07738; Wed, 14 Apr 1999 01:36:47 -0500 (CDT) Date: Wed, 14 Apr 1999 15:48:17 +0900 (JST) From: Henry Nelson Message-Id: <199904140648.PAA14937@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1575 Lines: 36 > so the documentation needs further improvement: your turn ... Please, this is not a healthy attitude. Just because you get a little flak doesn't mean you have to turn back. My criticism is intended to be constructive -- really. > on further thought, i agree with LP: best default is Main Help Page. No. Even the default help page has not been set to a local file, for a reason. Appropriately, one is advised to do so, however. > the problem arises when l.b.o. is down -- not infrequently -- , We know this. I happen to disagree that skirting the issue is the solution. I would rather see documentation of the problem and possible solutions, one being to try ".". > so that Lynx refuses to start & the user can't even enter h ; > this could happen with any remote site, > so the solution has to be to make the default a local URL: ^^^^^^^^^ Why? Actually preferable would be a volunteer with huge resources available to host lynx.browser.org. Leonid's idea of pointing to ftp.digital.com might work. Jim? > and we have to have a very simple default they can substitute > or we'll have Henry (grin) screaming that the sky is falling. > by all means, add 1 - 2 lines of further advice: your patch? You're missing the point here. It doesn't matter in the slightest what the default site is. My advice is to remove all mention of anonymous in the discussion about STARTFILE unless the topic is dealt with completely (no 1 - 2 lines by any means, more like 100 to 200). In this case, a little knowledge is potentially dangerous. __Henry From owner-lynx-dev@sig.net Wed Apr 14 03:02:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA26850 for ; Wed, 14 Apr 1999 03:02:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA08628; Wed, 14 Apr 1999 01:43:53 -0500 (CDT) From: Philip Webb Message-Id: <199904140643.CAA28624@chass.utoronto.ca> Subject: Re: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 02:43:30 -0400 (EDT) In-Reply-To: <199904140618.PAA14881@ibr1.irm.nara.kindai.ac.jp> from "Henry Nelson" at Apr 14, 99 03:18:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 730 Lines: 17 990414 Henry Nelson wrote: > Well, here's another message of appreciation to cheer you up.
> You gotta learn to roll with the punches on this list. Everyone
> and his brother has their own idea about the best way to do things. >

> Anyway, thanks for the docs and help to newbies! >

ever heard of a piece of software called `Lynx'? it takes all that messy & turns it into real nice screen images without you doing anything yourself ... -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 03:25:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27268 for ; Wed, 14 Apr 1999 03:25:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA11373; Wed, 14 Apr 1999 02:07:36 -0500 (CDT) To: lynx-dev@sig.net References: <199904140536.OAA14624@ibr1.irm.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 10:58:50 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: STARTFILE patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 988 Lines: 22 14-Apr-99 14:36 Henry Nelson wrote: >> > The patch (without doc changes) increases the discrepancy between >> > documentation and reality, but I also question its usefulness. > I sincerely believe that the default for STARTFILE should remain > "http://lynx.browser.org/". > 2) As Klaus has already pointed out, if you succeed in > accessing lynx.browser.org, then you can be sure that > Lynx is functional. Just being able to access local > files says nothing about getting onto the Web, where > most people want to go. Networking problems come hand > in hand with Lynx. It is true that lynx.browser.org > is not the most stable or fast site around, but quite > often as not it is not the source of problems. > 3) Rather than making "." the default, I could see it > documented, in lynx.cfg and perhaps also PROBLEMS, > as one step in the process of debugging network problems. Agree with Henry. From owner-lynx-dev@sig.net Wed Apr 14 03:50:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27724 for ; Wed, 14 Apr 1999 03:50:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA14437; Wed, 14 Apr 1999 02:38:38 -0500 (CDT) From: Philip Webb Message-Id: <199904140737.DAA29392@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 03:37:39 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 14, 99 10:58:50 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1246 Lines: 27 990414 Leonid Pauzner wrote: > 14-Apr-99 14:36 Henry Nelson wrote: >> I sincerely believe that the default for STARTFILE should remain >> "http://lynx.browser.org/". -- quote from KW's discussion snipped -- > Agree with Henry. but you quoted KW: he & HN have quite different views & yours were different again, ie to use the Main Help Page. can we please get serious? HN turns up once in a long while with loud advice for everyone, but he's very rarely around to answer all those anguished users who suddenly can't get Lynx to start & can't even hit `h'elp because Lynx won't start & can't check lynx.cfg because they don't know what it is & can't get thro' to their always over-worked sysadmin: THEY are the people who call in here needing down-to-earth advice. the way to help them is to make the STARTFILE default something local & i agree with LP (on further thought) that the Main Help Page is best; alternatively, KW's URL for the user's home directory would be ok. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 04:41:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA29811 for ; Wed, 14 Apr 1999 04:41:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA19193; Wed, 14 Apr 1999 03:27:31 -0500 (CDT) To: lynx-dev@sig.net References: <199904122308.TAA01933@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 12:26:03 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev21]: source caching, take 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 587 Lines: 12 >>> Grmbl... with HTDisplayPartial() defined private in HTFormat.c, I had to Hmm... HTDisplayPartial() is not working for MEMORY/FILE caching hit since we are working out of mainloop reloading stage (around getfile()) and display_partial flag is not set properly elsewhere. Will check whether we can fix this. (And the problem not so important, only a very slow machines may be affected). >>> move a fair amount of code there from GridText.c; so I'm resubmitting >>> the patch as a replacement again. I've checked this one, and at least >>> on this end, patch -p0 had no problems. From owner-lynx-dev@sig.net Wed Apr 14 04:55:53 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30214 for ; Wed, 14 Apr 1999 04:55:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA20735; Wed, 14 Apr 1999 03:42:41 -0500 (CDT) From: Philip Webb Message-Id: <199904140841.EAA00688@chass.utoronto.ca> Subject: Re: lynx-dev Lynx for Macintosh To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 04:41:04 -0400 (EDT) Cc: jasonrayles@hotmail.com In-Reply-To: <0FA300JEWF6MHG@mail.megsinet.net> from "jason rayles" at Apr 12, 99 03:22:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 644 Lines: 15 990412 Jason Rayles wrote: > Can someone please give me a URL > where I can download a version of Lynx for the Mac OS? the site for MacLynx is www.lirmm.fr/~gutkneco/maclynx , but there's been no work on it since 1997 & the regular Lynx development crew here can't really support it. so give it a try, let us know how you get on, but you're basically on your own (smile). -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 05:34:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA31026 for ; Wed, 14 Apr 1999 05:34:12 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04950; Wed, 14 Apr 1999 04:23:11 -0500 (CDT) To: lynx-dev@sig.net References: <199904140643.CAA28624@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 13:19:53 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev.22 lynx_dev.html MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 846 Lines: 21 14-Apr-99 02:43 Philip Webb wrote: > 990414 Henry Nelson wrote: >> Well, here's another message of appreciation to cheer you up.
>> You gotta learn to roll with the punches on this list. Everyone
>> and his brother has their own idea about the best way to do things. >>

>> Anyway, thanks for the docs and help to newbies! >>

> ever heard of a piece of software called `Lynx'? > it takes all that messy & turns it into real nice screen images > without you doing anything yourself ... Different falks have really different sense of humor:) > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 05:34:15 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA31031 for ; Wed, 14 Apr 1999 05:34:14 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA05158; Wed, 14 Apr 1999 04:25:20 -0500 (CDT) To: lynx-dev@sig.net References: <199904140737.DAA29392@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 13:14:35 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: STARTFILE patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2523 Lines: 55 14-Apr-99 03:37 Philip Webb wrote: > 990414 Leonid Pauzner wrote: >> 14-Apr-99 14:36 Henry Nelson wrote: >>> I sincerely believe that the default for STARTFILE should remain >>> "http://lynx.browser.org/". > -- quote from KW's discussion snipped -- >> Agree with Henry. > but you quoted KW: he & HN have quite different views > & yours were different again, ie to use the Main Help Page. > can we please get serious? I am quite serious. Henry's point was the startfile probles should belong to PROBLEMS since this most usual a local networking problem, not lynx.browser.org one. So a person compiling lynx from sources could read PROBLEMS without our advice. Another item when we talk about "precompiled binaries" - they are usually distributed without INSTALLATION, PROBLEMS, samples/ etc. and used by less technical people. So they need another README file, in additional to one from sources package. Startfile problems, platform-specific paths, advise to check lynx.cfg, etc. all should belong there (assuming a user cannot start lynx). However, this is up to the binary distributions author. In fact, most UNIX users already have lynx installed somewhere on their system out-of-the-box, they may have no idea about the package besides trying to start "lynx" However, lynx -help always work unless the executable is corrupted. How about adding a special text for -morehelp option (may be another name) like we have for -permissions without arguments? This can be a separate included file, easily maintainable in a root directory and built into any lynx binary like we have for configure options currently. > HN turns up once in a long while with loud advice for everyone, > but he's very rarely around to answer all those anguished users > who suddenly can't get Lynx to start > & can't even hit `h'elp because Lynx won't start > & can't check lynx.cfg because they don't know what it is > & can't get thro' to their always over-worked sysadmin: > THEY are the people who call in here needing down-to-earth advice. > the way to help them is to make the STARTFILE default something local > & i agree with LP (on further thought) that the Main Help Page is best; > alternatively, KW's URL for the user's home directory would be ok. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 06:24:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA32126 for ; Wed, 14 Apr 1999 06:24:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA09350; Wed, 14 Apr 1999 05:11:43 -0500 (CDT) From: Philip Webb Message-Id: <199904141009.GAA01996@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 06:09:23 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 14, 99 01:14:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2728 Lines: 57 990414 Leonid Pauzner wrote: > Henry's point was the startfile probles should belong to PROBLEMS > since this most usual a local networking problem, not lynx.browser.org one. whatever HN's point may have been -- he wasn't very coherent -- , the everyday problem is ordinary users who can't even start Lynx because l.b.o. is down: this will go on happening if we continue to offer a remote file as STARTFILE default. it's got nothing to do with networking. > So a person compiling lynx from sources could read PROBLEMS > without our advice. people compiling their own Lynx are not the ones having the problem: yes, they should have gone thro' lynx.cfg themselves when they started. > "precompiled binaries" are usually distributed > without INSTALLATION, PROBLEMS, samples/ etc. > and used by less technical people. So they need another README file, > in additional to one from sources package. that's a good point: someone should volunteer to write one. > Startfile problems, platform-specific paths, advise to check lynx.cfg, etc. > all should belong there (assuming a user cannot start lynx). > However, this is up to the binary distributions author. if so, they'll probably still be waiting in 2099. > In fact, most UNIX users already have lynx installed somewhere > on their system out-of-the-box, they may have no idea about > the package besides trying to start "lynx" > However, lynx -help always work unless the executable is corrupted. > How about adding a special text for -morehelp option (may be another name) > like we have for -permissions without arguments? > This can be a separate included file, easily maintainable in a root directory > and built into any lynx binary like we have for configure options currently. this would help some users, if anyone cares to implement it. to repeat: >> HN turns up once in a long while with loud advice for everyone, >> but he's very rarely around to answer all those anguished users >> who suddenly can't get Lynx to start >> & can't even hit `h'elp because Lynx won't start >> & can't check lynx.cfg because they don't know what it is >> & can't get thro' to their always over-worked sysadmin: >> THEY are the people who call in here needing down-to-earth advice. >> the way to help them is to make the STARTFILE default something local >> & i agree with LP (on further thought) that the Main Help Page is best; >> alternatively, KW's URL for the user's home directory would be ok. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 06:56:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA32725 for ; Wed, 14 Apr 1999 06:56:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA12583; Wed, 14 Apr 1999 05:45:04 -0500 (CDT) Date: Wed, 14 Apr 1999 19:56:33 +0900 (JST) From: Henry Nelson Message-Id: <199904141056.TAA15359@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2050 Lines: 44 > HN turns up once in a long while with loud advice for everyone, > but he's very rarely around to answer all those anguished users Touche. > who suddenly can't get Lynx to start > & can't even hit `h'elp because Lynx won't start > & can't check lynx.cfg because they don't know what it is All three of these are answered (or should be) by plain text documentation in the distribution. I cannot show a great deal of pity for people who fail to read INSTALLATION, PROBLEMS and other documentation thoroughly. Particularly the last, if "they" don't know what lynx.cfg is, then "they" simply have not put in the effort. > & can't get thro' to their always over-worked sysadmin: If it is the sysadm's job to provide Lynx service, then there isn't a lot we on lynx-dev can do if the sysadm is a slacker. If Lynx isn't a provided or supported service, then it is up to the user to fill in the gap or answer his/her own needs. > THEY are the people who call in here needing down-to-earth advice. > the way to help them is to make the STARTFILE default something local That is your opinion. I happen to differ. Making a decision about a default is not giving advice, down-to-earth or otherwise. I am well aware of the instability of lynx.browser.org. We COULD point everyone to "http://www.jp.msn.com", that _usually_ works. Another possibility perhaps is that of a hardcoded message that would tell the user that Lynx isn't REALLY alive, i.e., how Lynx now supports users who are activating bookmarks for the first time -- that would be a lot better than MSIE which throws up a perfectly blank screen when it can't get to msn.com. At least there would be a brief message about possible things to try. This would also seem very appropriate for non-English speakers, because then there would be at least the opportunity for NLS. Anyway, you enjoy helping "all those anguished users," don't you :) But like you say, I'm no longer an active participant. It is truly up to you who devote yourselves to Lynx to decide what is best. __Henry From owner-lynx-dev@sig.net Wed Apr 14 07:25:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA00632 for ; Wed, 14 Apr 1999 07:25:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA15769; Wed, 14 Apr 1999 06:14:39 -0500 (CDT) Date: Wed, 14 Apr 1999 07:14:04 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904140714.AA29774@cas.org> Subject: Re: lynx-dev Lynx for Macintosh In-Reply-To: <199904140841.EAA00688@chass.utoronto.ca> of Wed, 14 Apr 1999 04:41:04 -0400 (EDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 895 Lines: 19 From: Philip Webb 990412 Jason Rayles wrote: >> Can someone please give me a URL >> where I can download a version of Lynx for the Mac OS? >& the regular Lynx development crew here can't really support it. Jason The reason we can't do anything to support it is because the porter never provided us the source and none of the Mac users here on the list have had the time/energy/interest to redo the port and contribute the changes back to the list. If someone were to do so, then I suspect there are enough Mac users around who want to use MacLynx that we would be able to test new versions, etc. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Wed Apr 14 07:33:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA00830 for ; Wed, 14 Apr 1999 07:33:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA15551; Wed, 14 Apr 1999 06:12:44 -0500 (CDT) Date: Wed, 14 Apr 1999 07:12:10 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904140712.AA29699@cas.org> Subject: Re: lynx-dev Re: STARTFILE patch In-Reply-To: <199904141056.TAA15359@ibr1.irm.nara.kindai.ac.jp> of Wed, 14 Apr 1999 19:56:33 +0900 (JST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2798 Lines: 57 From: Henry Nelson >> who suddenly can't get Lynx to start >> & can't even hit `h'elp because Lynx won't start >> & can't check lynx.cfg because they don't know what it is > >All three of these are answered (or should be) by plain text >documentation in the distribution. I cannot show a great deal >of pity for people who fail to read INSTALLATION, PROBLEMS and >other documentation thoroughly. Particularly the last, if Yikes - are you sure you reread that part before posting Henry? The reason I ask is that I know you have been one of the few strong advocates for maintaining lynx as a 'menuing' system. How would the fine users of such a thing succeed in reading INSTALLATION, PROBLEMS, and other doc - unless that is the fine administrator made sure that these documents were part of the very first thing that users see... Otherwise, they have no access to the file system to get to those files. And we can suspect, from years of messages received from users on such systems sent to this list, how many fine administrators take the time and care to make all of the lynx doc available... (I suspect the percentage is rather small.) > If it is the sysadm's job to provide Lynx service, then there isn't > a lot we on lynx-dev can do if the sysadm is a slacker. If Lynx > isn't a provided or supported service, then it is up to the user to > fill in the gap or answer his/her own needs. And particularly in the case of the 'slacker' the users are going to need help. I know that none of _my_ users have any idea where those files are on our system... I keep lynx binary compiled up to date, but I don't spend time creating specialized web pages pointing to all of the most recent files describing INSTALLATION, etc. Hmm - perhaps we should have a step that converts the plain text files in question into HTML and installs them into the help directory AND make a link in the lynx help files to them! If someone feels this is of interest, then we should add it to the Lynx todo list... > to msn.com. At least there would be a brief message about possible > things to try. This would also seem very appropriate for non-English > speakers, because then there would be at least the opportunity for NLS. It would seem to me that if lynx fails in accessing the STARTFILE site that an error page, with possible explanation along with pointers to a few other useful web sites to try, might be an alternative. Alas, my personal time available for lynx hacking is again at a minimum... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Wed Apr 14 07:56:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA01341 for ; Wed, 14 Apr 1999 07:56:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA18710; Wed, 14 Apr 1999 06:37:08 -0500 (CDT) Date: Wed, 14 Apr 1999 07:36:30 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Re: compile problem on HP-UX 9.0 Message-ID: <19990414073630.A26153@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 281 Lines: 8 The dev.22 switches that Tom added for HPUX 9.0 worked (flawlessly :-). ------ Marvin the Paranoid Android says: Pathetic isn't it? From owner-lynx-dev@sig.net Wed Apr 14 08:34:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA02364 for ; Wed, 14 Apr 1999 08:34:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA22933; Wed, 14 Apr 1999 07:06:11 -0500 (CDT) Date: Tue, 13 Apr 1999 21:29:25 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1064 Lines: 40 I have the following problem with dev22: When pressing '\' on non-local files, the psrc view is shown, but there is no way out of this mode. This patch will fix it. Best regards, -Vlad diff -ru lynx-dev22-orig/src/GridText.c lynx-2.8.2dev22-fixed/src/GridText.c --- lynx-2.8.2dev22-orig/src/GridText.c Tue Apr 13 15:01:11 1999 +++ lynx-2.8.2dev22-fixed/src/GridText.c Tue Apr 13 21:18:00 1999 @@ -6214,8 +6214,14 @@ fp, NULL); fclose(fp); ok = (ret == HT_LOADED); - if (!ok) + if (!ok) { FREE(source_cache_filename); + } +#ifdef USE_PSRC + else + if (LYpsrc && psrc_view) + HTMainText->source=TRUE; +#endif } if (LYCacheSource == SOURCE_CACHE_MEMORY && @@ -6240,6 +6246,11 @@ HTChunkFree(source_cache_chunk); source_cache_chunk = NULL; } +#ifdef USE_PSRC + else + if (LYpsrc && psrc_view) + HTMainText->source=TRUE; +#endif } CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); From owner-lynx-dev@sig.net Wed Apr 14 09:25:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA03656 for ; Wed, 14 Apr 1999 09:25:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA28422; Wed, 14 Apr 1999 07:35:55 -0500 (CDT) From: dickey@clark.net Message-Id: <199904141235.IAA06182@shell.clark.net> Subject: Re: lynx-dev Lynx for Macintosh To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 08:35:51 -0400 (EDT) In-Reply-To: <9904140714.AA29774@cas.org> from "lvirden@cas.org" at Apr 14, 99 07:14:04 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1055 Lines: 26 > > From: Philip Webb > 990412 Jason Rayles wrote: > >> Can someone please give me a URL > >> where I can download a version of Lynx for the Mac OS? > >& the regular Lynx development crew here can't really support it. > > Jason > The reason we can't do anything to support it is because the porter never > provided us the source and none of the Mac users here on the list have had > the time/energy/interest to redo the port and contribute the changes back > to the list. If someone were to do so, then I suspect there are enough > Mac users around who want to use MacLynx that we would be able to test > new versions, etc. now that I'm reminded, I just got a copy of the .hqx file from that site. I'll unpack it, and see if there's anything useful that I can add to dev.23 for people who might want to try porting to Mac. (the file is supposed to be a modified 2.7.1) > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 14 09:26:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA03663 for ; Wed, 14 Apr 1999 09:26:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA29914; Wed, 14 Apr 1999 07:43:28 -0500 (CDT) From: Philip Webb Message-Id: <199904141240.IAA09348@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 08:40:02 -0400 (EDT) In-Reply-To: <199904141056.TAA15359@ibr1.irm.nara.kindai.ac.jp> from "Henry Nelson" at Apr 14, 99 07:56:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3816 Lines: 79 990414 Henry Nelson wrote: >> HN turns up once in a long while with loud advice for everyone, >> but he's very rarely around to answer all those anguished users > Touche. we all try to remain parliamentary in what we say to one another: i suspect the Ontario legislature is rowdier than the Japanese Diet (smile). >> who suddenly can't get Lynx to start >> & can't even hit `h'elp because Lynx won't start >> & can't check lynx.cfg because they don't know what it is > All three of these are answered (or should be) by plain text documentation > in the distribution. I cannot show a great deal of pity for people > who fail to read INSTALLATION, PROBLEMS and other documentation thoroughly. > Particularly the last, if "they" don't know what lynx.cfg is, > then "they" simply have not put in the effort. LV has replied to this already, so i can only echo him: typically, the people who appeal to lynx-dev are using a sysadmin's Lynx & have no knowledge of the existence or whereabouts of those files. >> & can't get thro' to their always over-worked sysadmin: > If it is the sysadm's job to provide Lynx service, > then there isn't a lot we on lynx-dev can do if the sysadm is a slacker. > If Lynx isn't a provided or supported service, > then it is up to the user to fill in the gap or answer his/her own needs. again LV has answered: we can try to find some way to avoid the problem, which is what my amendment of lynx.cfg aims to do. there are other ways to approach it, certainly (see below). >> THEY are the people who call in here needing down-to-earth advice. >> the way to help them is to make the STARTFILE default something local > I am well aware of the instability of lynx.browser.org. > Another possibility is a hardcoded message that would tell the user > that Lynx isn't REALLY alive, i.e. how Lynx now supports users > who are activating bookmarks for the first time -- > that would be a lot better than MSIE > which throws up a perfectly blank screen when it can't get to msn.com. > At least there would be a brief message about possible things to try. > This would also seem very appropriate for non-English speakers, > because then there would be at least the opportunity for NLS. YES: that had also occurred to me, but it requires programming. there really is no reason why Lynx should check out just because it can't access the stated STARTFILE: it could easily default to a simple screen message, which could be an HTML file included in the distribution, which whoever installs Lynx could alter to their taste, or the message could be hard-coded, like the Print screen: eg Start File Inaccessible Lynx is unable to access your start file ...: you can try your start file again by pressing Enter or you can go on with your Lynx session with any Lynx command -- e.g. `g'oto , `h'elp or `v'iew bookmarks -- or you can quit Lynx with `q' or `Q' (unconditional). LP has supported various options at various times: can he do the necessary bit of programming? or can someone tell me where to look for a start? > Anyway, you enjoy helping "all those anguished users," don't you :) not really: i'ld like to remove the cause of their anguish permanently. > But like you say, I'm no longer an active participant. > It is truly up to you who devote yourselves to Lynx to decide what is best. well, sometimes you do sound like the guy in the bleachers who always knows better than the 1st-base umpire, but i know you know quite a bit about the game when you put your mind to it. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 09:26:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA03668 for ; Wed, 14 Apr 1999 09:26:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA02565; Wed, 14 Apr 1999 07:56:17 -0500 (CDT) From: Philip Webb Message-Id: <199904141252.IAA10806@chass.utoronto.ca> Subject: lynx-dev Image view problem on VMS (unanswered query) To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 08:52:48 -0400 (EDT) Cc: newsmgr@mhl.nsw.gov.au X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7841 Lines: 185 none of the Lynx volunteers had anything to say about this problem, despite the lengthy account offered. VMS is not that well supported. > From: newsmgr@mhl.nsw.gov.au > Date: Tue, 6 Apr 1999 07:00:27 +1000 > Subject: lynx-dev Image view problem on VMS > > RE: Lynx image viewing problem > > When attempting to view the same image multiple times the display > only works the first time, all subsequent attempts return a file access > error from the viewing program. > > Spawning a session shows the temporary files like this, the zero length > indicates a file may be still open to the writing program. > > L1244-1TMP.GIF;3 0 A new version for each attempt. > L1244-1TMP.GIF;2 0 > L1244-1TMP.GIF;1 0 > LYNX.TRACE;1 0 > > Total of 5 files, 0 blocks. > > Here's some trace from a failed attempt. > > Lynx Trace Log > > User message: Trace ON! > > LYpush[1]: address:http://www.mhl.nsw.gov.au/www/welcome.html > title:Welcome to Manly Hydraulics Laboratory > getfile: getting http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif > > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:www.mhl.nsw.gov.au > > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result: > Entered HTAnchor_findAddress > Anchor 533028 with address `http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif' already exists. > HTAccess: loading document http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName:file: > HTParse: result:http > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:www.mhl.nsw.gov.au > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:http > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:http > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:www.mhl.nsw.gov.au > Looking up www.mhl.nsw.gov.au. > HTParseInet: parsing `www.mhl.nsw.gov.au'. > HTParseInet: Parsed address as port 80, IP address 203.0.140.10 > Making HTTP connection to www.mhl.nsw.gov.au. > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > 1 > HTParse: result:/www_root/data/dpws3.gif > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:www.mhl.nsw.gov.au > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > 1 > HTParse: result:/www_root/data/dpws3.gif > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > 1 > HTParse: result:www_root/data/dpws3.gif > HTParse: aName:http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif relatedName: > HTParse: result:www.mhl.nsw.gov.au > [snip cookie junk] > www.mhl.nsw.gov.au .tripod.com 0 /www_root/data/dpws3.gif / 0 > Composing Authorization for www.mhl.nsw.gov.au:80/www_root/data/dpws3.gif > HTAASetup_lookup: No template matched `www_root/data/dpws3.gif' (so probably not protected) > HTTP: Not sending authorization (yet). > Writing: > GET /www_root/data/dpws3.gif HTTP/1.0 > Host: www.mhl.nsw.gov.au > Accept: text/html, text/plain, text/sgml, image/jpeg, image/gif, */*;q=0.01 > Accept-Encoding: gzip, compress > Accept-Language: en > Negotiate: trans > User-Agent: Lynx/2.8.1rel.2 libwww-FM/2.14 > Referer: http://www.mhl.nsw.gov.au/www/welcome.html > > ---------------------------------- > Sending HTTP request. > HTTP: WRITE delivered OK > HTTP request sent; waiting for response. > HTTP: Trying to read 1023 > HTTP: Read 195 > HTTP: Rx: HTTP/1.0 200 Sending data > HTTP: Scanned 2 fields from line_buffer > --- Talking HTTP1. > HTTP/1.0 200 Sending data > HTFormat: Constructing stream stack for www/mime to www/present > HTFormat: Looking up presentation for www/mime to www/present > StreamStack: found weak wildcard match: www/present > FindPresentation: found exact match: www/mime > StreamStack: found exact match: www/mime > HTMIME: MIME-version: 1.0 > Server: OSU/1.8 > Content-type: image/gif > Content-transfer-encoding: binary > Content-length: 10264 > Last-Modified: Friday, 11-Sep-98 11:40:54 GMT > > > HTMIME: Got 'S' at beginning of line, state now S > HTMIME: Was S, found E, state now SE' > HTMIME: Was SE, found R, checking for 'ver' > HTMIME: PICKED UP Server: 'OSU/1.8' > HTMIME: Got 'C' at beginning of line, state now C > HTMIME: Was C, found O, state now CO' > HTMIME: Was CO, found N, state now CON > HTMIME: Was CON, found T, checking for 'ent-' > HTMIME: in case CONTENT_ > HTMIME: Was CONTENT_, found T, state now CONTENT_T > HTMIME: in case CONTENT_T > HTMIME: Was CONTENT_T, found Y, checking for 'pe:' > HTMIME: PICKED UP Content-Type: 'image/gif' > HTMIME: Got 'C' at beginning of line, state now C > HTMIME: Was C, found O, state now CO' > HTMIME: Was CO, found N, state now CON > HTMIME: Was CON, found T, checking for 'ent-' > HTMIME: in case CONTENT_ > HTMIME: Was CONTENT_, found T, state now CONTENT_T > HTMIME: in case CONTENT_T > HTMIME: Was CONTENT_T, found R, checking for 'ansfer-encoding:' > HTMIME: PICKED UP Content-Transfer-Encoding: 'binary' > HTMIME: Got 'C' at beginning of line, state now C > HTMIME: Was C, found O, state now CO' > HTMIME: Was CO, found N, state now CON > HTMIME: Was CON, found T, checking for 'ent-' > HTMIME: in case CONTENT_ > HTMIME: Was CONTENT_, found L, state now CONTENT_L > HTMIME: in case CONTENT_L > HTMIME: Was CONTENT_L, found E, checking for 'ngth:' > HTMIME: PICKED UP Content-Length: '10264' > Converted to integer: '10264' > HTMIME: Got 'L' at beginning of line, state now L > HTMIME: Was L, found A, checking for 'st-modified:' > HTMIME: PICKED UP Last-Modified: 'Friday, 11-Sep-98 11:40:54 GMT' > HTMIME: MIME Content-Type is 'image/gif', converting to 'www/present' > HTFormat: Constructing stream stack for image/gif to www/present > HTFormat: Looking up presentation for image/gif to www/present > StreamStack: found weak wildcard match: www/present > FindPresentation: found exact match: image/gif > StreamStack: found exact match: image/gif > Data transfer complete > LYCloseTempFP > gif_view sys$scratch:L1244-1TMP.gif **** Viewing program ***** > HTAccess: status=29997 > HTAccess: `http://www.mhl.nsw.gov.au/www_root/data/dpws3.gif' has been accessed. > LYpop[1]: address:http://www.mhl.nsw.gov.au/www/welcome.html > title:Welcome to Manly Hydraulics Laboratory > getfile: getting http://www.mhl.nsw.gov.au/www/welcome.html > > HTParse: aName:http://www.mhl.nsw.gov.au/www/welcome.html relatedName: > HTParse: result:www.mhl.nsw.gov.au > > HTParse: aName:http://www.mhl.nsw.gov.au/www/welcome.html relatedName: > HTParse: result: > Entered HTAnchor_findAddress > Anchor 525E50 with address `http://www.mhl.nsw.gov.au/www/welcome.html' already exists. > HTAccess: loading document http://www.mhl.nsw.gov.au/www/welcome.html > HTAccess: Document already in memory. > GridText: HText_pageDisplay at line 1 started > GridText: HText_pageDisplay finished > > > (Lynx 2.8.1rel2, Alpha VMS 7.1, DEC C 5.6, UCX 4.2) > > Regards > * * * * * Tony Bolton > **** **** ** ** ** TBolton 'at' mhl.nsw.gov.au > ** **** ** ********* ** MANLY HYDRAULICS LABORATORY. > ** ** ** ********* ** 110B King ST. Manly Vale 2093 Sydney AUSTRALIA > ** ** ** ** ******** Phone +61 2 99490200 FAX +61 2 99486185 > -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 10:02:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA04732 for ; Wed, 14 Apr 1999 10:02:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA16778; Wed, 14 Apr 1999 08:44:18 -0500 (CDT) From: dickey@clark.net Message-Id: <199904141344.JAA17717@shell.clark.net> Subject: Re: lynx-dev Image view problem on VMS (unanswered query) To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 09:44:14 -0400 (EDT) In-Reply-To: <199904141252.IAA10806@chass.utoronto.ca> from "Philip Webb " at Apr 14, 99 08:52:48 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1021 Lines: 29 > > none of the Lynx volunteers had anything to say about this problem, > despite the lengthy account offered. VMS is not that well supported. not exactly - I asked for more information (and this appears to be the second response, since - perhaps it was late - I don't remember the associated trace). Perhaps what's happening is that the temporary file is not being closed before spawning the viewer - resulting in a permissions problem. In that case it would not be VMS-specific. (I meant to test that idea, but dev.22 was running past schedule - so this is on my dev.23 list). > > From: newsmgr@mhl.nsw.gov.au > > Date: Tue, 6 Apr 1999 07:00:27 +1000 > > Subject: lynx-dev Image view problem on VMS > > > > RE: Lynx image viewing problem > > > > When attempting to view the same image multiple times the display > > only works the first time, all subsequent attempts return a file access > > error from the viewing program. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 14 10:08:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA04953 for ; Wed, 14 Apr 1999 10:08:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA20316; Wed, 14 Apr 1999 08:54:36 -0500 (CDT) Message-Id: <3.0.3.32.19990414085025.007dea00@collins.mail.iastate.edu> X-Sender: collins@collins.mail.iastate.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 14 Apr 1999 08:50:25 -0500 To: lynx-dev@sig.net From: Gene Collins Subject: lynx-dev need help with lynx key mapping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1285 Lines: 25 Hello. I'm running Lynx 2.8.1dev.16 under Windows 95. I am a totally blind person using the ASAP screen reader. The problem is that the screen reader wants to use the numeric key pad for it's command keys. Since Lynx is a Windows console app, conagent.exe takes over the keyboard interrupt, and passes all of my screen reader commands on to Lynx, instead of allowing the screen reader to capture them as would normally be the case. I would like to map the numeric key pad so that all the keys on the keypad are ignored, but the arrow keys, page up, page down, home and end keys that are between the key pad and the enter key will still work. Is this possible? If so, where can I find the key scan codes or special key names that I need for specifically mapping the numeric key pad, and what Lynx action verb should I map to each key that I would like ignored. I've looked at lykeymap.c and lykeymap.h, but not being a c programmer, I've had a bit of trouble making sense of them. What I would like to do is put theese mappings in my lynx.cfg file, but the mapping area of lynx.cfg doesn't seem to reference the key pad home and end keys etc. separately from the other home, end, page up, page down, etc. Thanks for all the help in advance. Gene Collins collins@iastate.edu From owner-lynx-dev@sig.net Wed Apr 14 10:43:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06033 for ; Wed, 14 Apr 1999 10:43:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26398; Wed, 14 Apr 1999 09:12:08 -0500 (CDT) Date: Wed, 14 Apr 1999 18:11:50 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: lynx-dev Commenting... Message-ID: <19990414181149.A13480@transas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 589 Lines: 16 Hello, I am not sure whether this forum is suitable for user questions. :) If not, please direct me to the proper forum. The question is quite simple. There is a command called `comment to author', where can I find the information on how to provide the appropriate information for this feature? I believe this is some processing of or tags, but what? And another question, there is a way for providing alternative versions of documents via tag, does lynx support this in some way? If no, is it going to do that (that's developer's question :)? Thanks, -- Mike From owner-lynx-dev@sig.net Wed Apr 14 11:47:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA08000 for ; Wed, 14 Apr 1999 11:47:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26080; Wed, 14 Apr 1999 10:27:46 -0500 (CDT) To: lynx-dev@sig.net References: <199904141235.IAA06182@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 17:44:24 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx for Macintosh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 453 Lines: 10 14-Apr-99 08:35 dickey@clark.net wrote: > site. I'll unpack it, and see if there's anything useful that I > can add to dev.23 for people who might want to try porting to Mac. BTW, Tom can you change configure staff so the system name ("uname -a" or like) will be hardcored into the binary, seen from "lynx -version" (ifdef'ed with !NO_CONFIG_INFO) with the additional hints to check "=" Information Page within lynx for compiled-in default values. From owner-lynx-dev@sig.net Wed Apr 14 11:47:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA08019 for ; Wed, 14 Apr 1999 11:47:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26625; Wed, 14 Apr 1999 10:29:18 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 19:23:21 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4355 Lines: 130 13-Apr-99 21:29 Vlad Harchev wrote: > I have the following problem with dev22: > When pressing '\' on non-local files, the psrc view is shown, but there is no > way out of this mode. This patch will fix it. > Best regards, > -Vlad Thanks for you fix! More problems found with SOURCE_CACHE!=NONE: the length of the re-rendered text may vary so the scrolling down is broken (especially nice when switching to source). This patch will fix it ("more" updated, "lines_in_file" inlined), also include your changes so applied to clean dev22). More problems expected since we now reload documents out of mainloop() cyrcle. diff -u old/gridtext.c ./gridtext.c --- old/gridtext.c Tue Apr 13 23:11:32 1999 +++ ./gridtext.c Wed Apr 14 18:57:06 1999 @@ -6215,8 +6215,9 @@ fp, NULL); fclose(fp); ok = (ret == HT_LOADED); - if (!ok) + if (!ok) { FREE(source_cache_filename); + } } if (LYCacheSource == SOURCE_CACHE_MEMORY && @@ -6244,6 +6245,15 @@ } CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); + + if (ok) {/* fix few flags: */ +#ifdef USE_PSRC + if (LYpsrc && psrc_view) + HTMainText->source=TRUE; +#endif + more = HText_canScrollDown(); /* the length may be changed */ + } + return ok; } diff -u old/lymainlo.c ./lymainlo.c --- old/lymainlo.c Wed Apr 14 04:32:12 1999 +++ ./lymainlo.c Wed Apr 14 19:01:42 1999 @@ -234,7 +234,6 @@ int cmd = LYK_DO_NOTHING, real_cmd = LYK_DO_NOTHING; int getresult; int arrowup = FALSE, show_help = FALSE; - int lines_in_file = -1; int Newline = 0; char prev_target[512]; char user_input_buffer[1024]; @@ -1298,7 +1296,6 @@ */ more = HText_canScrollDown(); curdoc.line = Newline = HText_getTopOfScreen()+1; - lines_in_file = HText_getNumOfLines(); if (curdoc.title == NULL) { /* @@ -1671,7 +1668,6 @@ links[curdoc.link+1].form->name) != 0)))))) { HText_ExpandTextarea (&links[curdoc.link], 1); - lines_in_file = HText_getNumOfLines(); if (links[curdoc.link].ly < display_lines) { refresh_screen = TRUE; @@ -2512,7 +2508,7 @@ case LYK_END: if (more) { - Newline = lines_in_file - display_lines + 3; /* go to end of file */ + Newline = HText_getNumOfLines() - display_lines + 3; /* go to end of file */ arrowup = TRUE; /* position on last link */ } else { cmd = LYK_NEXT_PAGE; @@ -4656,7 +4652,7 @@ */ if (strcmp((curdoc.title ? curdoc.title : ""), SHOWINFO_TITLE)) { - if (showinfo(&curdoc, lines_in_file, + if (showinfo(&curdoc, HText_getNumOfLines(), &newdoc, owner_address) < 0) break; StrAllocCopy(newdoc.title, SHOWINFO_TITLE); @@ -4698,8 +4694,6 @@ n = HText_ExtEditForm (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st trailing blank line in @@ -4731,7 +4725,6 @@ HText_ExpandTextarea (&links[curdoc.link], TEXTAREA_EXPAND_SIZE); - lines_in_file = HText_getNumOfLines(); refresh_screen = TRUE; } else { @@ -4749,8 +4742,6 @@ n = HText_InsertFile (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st line following the text @@ -4788,7 +4779,7 @@ PRINT_OPTIONS_TITLE)) { if (print_options(&newdoc.address, - &curdoc.address, lines_in_file) < 0) + &curdoc.address, HText_getNumOfLines()) < 0) break; StrAllocCopy(newdoc.title, PRINT_OPTIONS_TITLE); FREE(newdoc.post_data); From owner-lynx-dev@sig.net Wed Apr 14 11:48:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA08033 for ; Wed, 14 Apr 1999 11:48:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26159; Wed, 14 Apr 1999 10:28:03 -0500 (CDT) To: lynx-dev@sig.net References: <199904141240.IAA09348@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 17:31:56 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: STARTFILE patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 877 Lines: 26 14-Apr-99 08:40 Philip Webb wrote: > or the message could be hard-coded, like the Print screen: eg > Start File Inaccessible > Lynx is unable to access your start file ...: > you can try your start file again by pressing Enter > or you can go on with your Lynx session with any Lynx command > -- e.g. `g'oto , `h'elp or `v'iew bookmarks -- > or you can quit Lynx with `q' or `Q' (unconditional). > LP has supported various options at various times: > can he do the necessary bit of programming? > or can someone tell me where to look for a start? This is not a programming problem, to get a consensus is. I would rather prefer to correct exit messages with a hint of what happend and what can to do. Say: - incorrect startfile URL syntax; - local file not found; - DNS lookup failure; - interrupted by user; - internal error (!) etc. From owner-lynx-dev@sig.net Wed Apr 14 11:56:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA08311 for ; Wed, 14 Apr 1999 11:56:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA27540; Wed, 14 Apr 1999 10:31:50 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904141531.JAA06036@sanitas> Subject: lynx-dev dev.22 exiting with signal: 11 To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 09:31:02 -0600 (MDT) In-Reply-To: <199904130950.FAA17280@shell.clark.net> from "dickey@clark.net" at Apr 13, 99 05:50:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 12531 Lines: 317 On Solaris 2.6: Start Lynx '=' (go to info page) (go to slcc development version page) '\' (display source) (back to info page) (back to source of slcc page) ^T (Trace on) '\' (attempt to display rendered page) A Fatal error has occurred in Lynx Ver. 2.8.2dev.22 Please notify your system administrator to confirm a bug, and if confirmed, to notify the lynx-dev list. Bug reports should have concise descriptions of the command and/or URL which causes the problem, the operating system name with version number, the TCPIP implementation, and any other relevant information. Do NOT mail the core file if one was generated. Lynx now exiting with signal: 11 Abort(coredump) Problem occurs with SOURCE_CACHE:MEMORY Problem occurs with SOURCE_CACHE:FILE Problem does not occur with SOURCE_CACHE:NONE Problem does not occur on OS/390 Configuration Definitions (Lynx Version 2.8.2dev.22) See also your lynx.cfg for runtime options The following data were derived during the automatic configuration/build process of this copy of Lynx. When reporting a bug, please include a copy of this page. config.cache SYSTEM_MAIL '/usr/lib/sendmail' alt_char_set 'acs_map' ansi_varargs 'yes' baddef_remove 'no' bool_defs 'yes' c_const 'yes' c_inline 'inline' color_curses 'yes' curs_performance 'no' dcl_errno 'yes' dcl_sys_errlist 'no' dcl_sys_nerr 'no' ebcdic 'no' fancy_curses 'yes' fionbio 'fcntl' func___argz_count 'no' func___argz_next 'no' func___argz_stringify 'no' func_alloca_works 'yes' func_cbreak 'yes' func_cuserid 'yes' func_decl_getgrgid 'yes' func_decl_getgrnam 'yes' func_decl_strstr 'yes' func_define_key 'no' func_getcwd 'yes' func_getgroups 'yes' func_gethostbyname 'yes' func_gethostname 'yes' func_getpagesize 'yes' func_gettimeofday 'yes' func_initscr 'no' func_keypad 'yes' func_lstat 'yes' func_mktime 'yes' func_mmap_fixed_mapped 'yes' func_munmap 'yes' func_popen 'yes' func_putenv 'yes' func_readdir 'yes' func_setenv 'no' func_setlocale 'yes' func_socket 'yes' func_stpcpy 'no' func_strcasecmp 'yes' func_strchr 'yes' func_strerror 'yes' func_strstr 'yes' func_tgoto 'no' func_use_default_colors 'no' func_vfork_works 'yes' func_waitpid 'yes' func_wborder 'yes' have_errno 'yes' have_inet_addr 'yes' have_inet_aton 'no' have_sys_errlist 'yes' have_sys_nerr 'yes' have_ttytype 'yes' have_utmp 'utmpx' header_alloca_h 'yes' header_argz_h 'no' header_dirent_dirent_h 'yes' header_fcntl_h 'yes' header_intl 'intl/libintl.h' header_libgt 'intl/libgettext.h' header_limits_h 'yes' header_locale_h 'yes' header_malloc_h 'yes' header_nl_types_h 'yes' header_stdarg_h 'yes' header_stdc 'yes' header_stdlib_h 'yes' header_string_h 'yes' header_sys_fcntl_h 'yes' header_sys_filio_h 'yes' header_sys_ioctl_h 'yes' header_sys_param_h 'yes' header_sys_time_h 'yes' header_sys_wait_h 'yes' header_termio_h 'yes' header_termios_h 'yes' header_time 'yes' header_unistd_h 'yes' header_values_h 'yes' header_varargs_h 'yes' header_vfork_h 'no' lib_cursesX_initscr 'no' lib_curses_initscr 'yes' lib_dir_opendir 'no' lib_inet 'no' lib_nsl_gethostbyname 'yes' lib_socket_socket 'yes' lib_termcap_tgoto 'yes' locale 'yes' ncurses_header 'curses.h' ncurses_version 'no' netlibs '-lnsl -lsocket ' ngroups 'NGROUPS_MAX' path_BZIP2 'bzip2' path_CHMOD '/bin/chmod' path_COMPRESS '/bin/compress' path_COPY '/bin/cp' path_GZIP '/apps/bin/gzip' path_MKDIR '/bin/mkdir' path_MV '/bin/mv' path_RLOGIN '/bin/rlogin' path_RM '/bin/rm' path_TAR '/bin/tar' path_TELNET '/bin/telnet' path_TN3270 'tn3270' path_TOUCH '/bin/touch' path_UNCOMPRESS '/apps/bin/gunzip' path_UNZIP 'unzip' path_UUDECODE '/bin/uudecode' path_ZCAT '/bin/zcat' path_ZIP 'zip' path_install '/usr/GNU/bin/install -c' prog_CC 'gcc' prog_CPP 'gcc -E' prog_LINT 'lint' prog_RANLIB ':' prog_cc_cross 'no' prog_cc_g 'yes' prog_cc_works 'yes' prog_gcc 'yes' prog_make_make_set 'yes' screen 'curses' sizechange 'yes' system_mail_flags '-t -oi' termio_and_curses 'yes' termio_and_termios 'yes' type_getgroups 'gid_t' type_mode_t 'yes' type_off_t 'yes' type_pid_t 'yes' type_size_t 'yes' type_uid_t 'yes' type_unionwait 'no' use_libsocks5 'no' use_libsocks 'no' val_LC_MESSAGES 'yes' The following data were used as automatically-configured compile-time definitions when this copy of Lynx was built. lynx_cfg.h ALT_CHAR_SET acs_map ANSI_VARARGS 1 BZIP2_PATH "bzip2" CHMOD_PATH "/bin/chmod" COLOR_CURSES 1 COMPRESS_PATH "/bin/compress" COPY_PATH "/bin/cp" DECL_SYS_ERRLIST 1 DIRED_SUPPORT 1 DISP_PARTIAL 1 DONT_TRACK_INTERNAL_LINKS 1 FANCY_CURSES 1 GETGROUPS_T gid_t GZIP_PATH "/apps/bin/gzip" HAVE_ALLOCA 1 HAVE_ALLOCA_H 1 HAVE_CBREAK 1 HAVE_CUSERID 1 HAVE_DIRENT_H 1 HAVE_FCNTL_H 1 HAVE_GETBKGD 1 HAVE_GETCWD 1 HAVE_GETGROUPS 1 HAVE_GETTIMEOFDAY 1 HAVE_KEYPAD 1 HAVE_LC_MESSAGES 1 HAVE_LIMITS_H 1 HAVE_LOCALE_H 1 HAVE_LSTAT 1 HAVE_MALLOC_H 1 HAVE_MMAP 1 HAVE_MUNMAP 1 HAVE_NL_TYPES_H 1 HAVE_POPEN 1 HAVE_PUTENV 1 HAVE_READDIR 1 HAVE_SETLOCALE 1 HAVE_SIZECHANGE 1 HAVE_STDARG_H 1 HAVE_STDLIB_H 1 HAVE_STRCASECMP 1 HAVE_STRCHR 1 HAVE_STRERROR 1 HAVE_STRING_H 1 HAVE_SYS_FCNTL_H 1 HAVE_SYS_FILIO_H 1 HAVE_SYS_IOCTL_H 1 HAVE_SYS_PARAM_H 1 HAVE_SYS_WAIT_H 1 HAVE_TERMIOS_H 1 HAVE_TERMIO_H 1 HAVE_TTYTYPE 1 HAVE_UNISTD_H 1 HAVE_UTMP 1 HAVE_VALUES_H 1 HAVE_VARARGS_H 1 HAVE_WAITPID 1 HAVE_WBORDER 1 INSTALL_PATH "/usr/GNU/bin/install -c" LOCALE 1 LONG_LIST 1 LYNX_CFG_FILE "/pub/unsup/test/lib/lynx.cfg" LYNX_CFG_H 1 MKDIR_PATH "/bin/mkdir" MV_PATH "/bin/mv" NGROUPS NGROUPS_MAX OK_GZIP 1 OK_OVERRIDE 1 OK_PERMIT 1 OK_TAR 1 OK_UUDECODE 1 OK_ZIP 1 RLOGIN_PATH "/bin/rlogin" RM_PATH "/bin/rm" SOURCE_CACHE 1 STDC_HEADERS 1 SYSTEM_MAIL "/usr/lib/sendmail" SYSTEM_MAIL_FLAGS "-t -oi" TAR_PATH "/bin/tar" TELNET_PATH "/bin/telnet" TERMIO_AND_CURSES 1 TN3270_PATH "tn3270" TOUCH_PATH "/bin/touch" UNCOMPRESS_PATH "/apps/bin/gunzip" UNIX 1 UNZIP_PATH "unzip" USE_EXTERNALS 1 USE_FCNTL 1 UTMPX_FOR_UTMP 1 UUDECODE_PATH "/bin/uudecode" ZCAT_PATH "/bin/zcat" ZIP_PATH "zip" lstat stat Lynx.trace: Lynx Trace Log (2.8.2dev.22) User message: Trace ON! Reparsing from source memory cache 160480 HTFormat: Constructing stream stack for text/html to www/present HTFormat: Looking up presentation for text/html to www/present FindPresentation: found exact match: text/html StreamStack: found exact match: text/html UCSetTransParams: from iso-8859-1(0) to iso-8859-1(0) Reusing source memory cache 160480 SGML Doctype SGML: Start UCSetTransParams: from iso-8859-1(0) to iso-8859-1(0) GridText: Auto-uncaching UCSetTransParams: from iso-8859-1(0) to iso-8859-1(0) GridText: start HText_new GridText: Change to style Normal GridText: split_line(0 [now:0]) called HTML:begin_element[0]: adding style to stack - Normal SGML: Start < snip! > Gridtext: Anchor found on line:140 col:22 [74] ext:13 anchor text: 'HTML 2.0 validated. Re-validate' GridText: add link on line 140 col 23 [74] in HText_trimHightext Reparse succeeded GridText: HText_pageDisplay at line 1 started GridText: HText_pageDisplay finished LYRemoveTemp(/tmp/pg-volatile/L5990-1TMP.html) ...LYRemoveTemp done(0) From owner-lynx-dev@sig.net Wed Apr 14 12:03:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA08689 for ; Wed, 14 Apr 1999 12:03:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA05396; Wed, 14 Apr 1999 10:52:23 -0500 (CDT) To: uue@pauzner.mccme.ru References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 19:45:20 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4393 Lines: 130 14-Apr-99 19:23 I wrote: > 13-Apr-99 21:29 Vlad Harchev wrote: >> I have the following problem with dev22: >> When pressing '\' on non-local files, the psrc view is shown, but there is no >> way out of this mode. This patch will fix it. >> Best regards, >> -Vlad > Thanks for you fix! More problems found with SOURCE_CACHE!=NONE: > the length of the re-rendered text may vary so the scrolling down > is broken (especially nice when switching to source). > This patch will fix it ("more" updated, "lines_in_file" inlined), > also include your changes so applied to clean dev22). apparently, the "patch" think that patch is broken. Here a better resync: diff -u old/gridtext.c ./gridtext.c --- old/gridtext.c Tue Apr 13 23:11:32 1999 +++ ./gridtext.c Wed Apr 14 18:57:06 1999 @@ -6215,8 +6215,9 @@ fp, NULL); fclose(fp); ok = (ret == HT_LOADED); - if (!ok) + if (!ok) { FREE(source_cache_filename); + } } if (LYCacheSource == SOURCE_CACHE_MEMORY && @@ -6244,6 +6245,15 @@ } CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); + + if (ok) {/* fix few flags: */ +#ifdef USE_PSRC + if (LYpsrc && psrc_view) + HTMainText->source=TRUE; +#endif + more = HText_canScrollDown(); /* the length may be changed */ + } + return ok; } diff -u old/lymainlo.c ./lymainlo.c --- old/lymainlo.c Wed Apr 14 04:32:12 1999 +++ ./lymainlo.c Wed Apr 14 19:35:14 1999 @@ -234,7 +234,6 @@ int cmd = LYK_DO_NOTHING, real_cmd = LYK_DO_NOTHING; int getresult; int arrowup = FALSE, show_help = FALSE; - int lines_in_file = -1; int Newline = 0; char prev_target[512]; char user_input_buffer[1024]; @@ -1298,7 +1297,6 @@ */ more = HText_canScrollDown(); curdoc.line = Newline = HText_getTopOfScreen()+1; - lines_in_file = HText_getNumOfLines(); if (curdoc.title == NULL) { /* @@ -1671,7 +1669,6 @@ links[curdoc.link+1].form->name) != 0)))))) { HText_ExpandTextarea (&links[curdoc.link], 1); - lines_in_file = HText_getNumOfLines(); if (links[curdoc.link].ly < display_lines) { refresh_screen = TRUE; @@ -2512,7 +2509,7 @@ case LYK_END: if (more) { - Newline = lines_in_file - display_lines + 3; /* go to end of file */ + Newline = HText_getNumOfLines() - display_lines + 3; /* go to end of file */ arrowup = TRUE; /* position on last link */ } else { cmd = LYK_NEXT_PAGE; @@ -4656,7 +4653,7 @@ */ if (strcmp((curdoc.title ? curdoc.title : ""), SHOWINFO_TITLE)) { - if (showinfo(&curdoc, lines_in_file, + if (showinfo(&curdoc, HText_getNumOfLines(), &newdoc, owner_address) < 0) break; StrAllocCopy(newdoc.title, SHOWINFO_TITLE); @@ -4698,8 +4695,6 @@ n = HText_ExtEditForm (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st trailing blank line in @@ -4731,7 +4726,6 @@ HText_ExpandTextarea (&links[curdoc.link], TEXTAREA_EXPAND_SIZE); - lines_in_file = HText_getNumOfLines(); refresh_screen = TRUE; } else { @@ -4749,8 +4743,6 @@ n = HText_InsertFile (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st line following the text @@ -4788,7 +4780,7 @@ PRINT_OPTIONS_TITLE)) { if (print_options(&newdoc.address, - &curdoc.address, lines_in_file) < 0) + &curdoc.address, HText_getNumOfLines()) < 0) break; StrAllocCopy(newdoc.title, PRINT_OPTIONS_TITLE); FREE(newdoc.post_data); From owner-lynx-dev@sig.net Wed Apr 14 12:10:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA08806 for ; Wed, 14 Apr 1999 12:10:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA05945; Wed, 14 Apr 1999 10:53:56 -0500 (CDT) From: dickey@clark.net Message-Id: <199904141553.LAA07649@shell.clark.net> Subject: Re: lynx-dev Lynx for Macintosh To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 11:53:46 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" " at Apr 14, 99 05:44:24 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 728 Lines: 21 > > 14-Apr-99 08:35 dickey@clark.net wrote: > > site. I'll unpack it, and see if there's anything useful that I > > can add to dev.23 for people who might want to try porting to Mac. > > BTW, Tom can you change configure staff so the system name > ("uname -a" or like) will be hardcored into the binary, > seen from "lynx -version" (ifdef'ed with !NO_CONFIG_INFO) > with the additional hints to check "=" Information Page within lynx > for compiled-in default values. I do something like that for vile, e.g., vile version 8.2o for solaris2.6, installed Tue Mar 9 08:58:03 1999 The "solaris2.6" is from configure; the date by searching $PATH -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 14 12:14:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA09039 for ; Wed, 14 Apr 1999 12:14:14 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA08684; Wed, 14 Apr 1999 11:01:21 -0500 (CDT) Date: Wed, 14 Apr 1999 12:00:46 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904141200.AA6467@cas.org> Subject: Re: lynx-dev dev.22 exiting with signal: 11 In-Reply-To: Your message of Wed, 14 Apr 1999 09:31:02 -0600 (MDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 398 Lines: 7 I am using SPARC Solaris 2.6 with caching turned on along with persistent cookies and a few other things and don't see this error. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Wed Apr 14 12:14:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA09045 for ; Wed, 14 Apr 1999 12:14:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA08683; Wed, 14 Apr 1999 11:01:21 -0500 (CDT) Date: Wed, 14 Apr 1999 12:01:05 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 5577 Lines: 161 On Tue, 13 Apr 1999, Vlad Harchev wrote: > I have the following problem with dev22: > When pressing '\' on non-local files, the psrc view is shown, but there is no > way out of this mode. This patch will fix it. Actually, I already have a more localized fix of that in this patch. Also included are fixes for related bugs tweaked by going to an internal page while viewing source, and a few blurbs in the documentation (which don't really say much, but...). [Note to Tom: if you've already applied Leonid's recent UCLYhndl patch, then you can punt the part of this patch that touches HTAccess.[ch], because his patch already does what mine needs.] -sbigham --- ./WWW/Library/Implementation/HTAccess.c.orig Tue Apr 13 05:39:16 1999 +++ ./WWW/Library/Implementation/HTAccess.c Wed Apr 14 11:28:16 1999 @@ -592,7 +592,15 @@ * UCLYhndl_for_unspec used for charset "assuming" from the values * saved by LYUCPushAssumed, if any. - kw */ -PRIVATE int LYUCPopAssumed NOARGS +#ifdef SOURCE_CACHE +/* + * We need this outside... -dsb + */ +PUBLIC +#else +PRIVATE +#endif +int LYUCPopAssumed NOARGS { if (pushed_assume_LYhndl >= 0) { UCLYhndl_for_unspec = pushed_assume_LYhndl; --- ./WWW/Library/Implementation/HTAccess.h.orig Wed Mar 17 22:17:11 1999 +++ ./WWW/Library/Implementation/HTAccess.h Tue Apr 13 17:39:29 1999 @@ -305,6 +305,9 @@ extern void LYUCPushAssumed PARAMS(( HTParentAnchor * anchor)); +#ifdef SOURCE_CACHE +extern int LYUCPopAssumed NOPARAMS; +#endif #endif /* HTACCESS_H */ /* --- ./lynx_help/Lynx_users_guide.html.orig Tue Apr 13 05:39:16 1999 +++ ./lynx_help/Lynx_users_guide.html Wed Apr 14 10:00:22 1999 @@ -141,7 +141,8 @@ where to find the linked file and what kind of server will provide it (i.e., HTTP, Gopher, etc.). -

Lynx renders HTML files and saves the rendition, not the source, +

Lynx renders HTML files and saves the rendition (and the source, if +so configured in the lynx.cfg file) for initial display and should you select the link again. If you do select a link again and have reason to desire a new fetch and rendering of the file, use the NOCACHE command, normally mapped to 'x' and @@ -338,9 +339,10 @@ When viewing HTML documents it is possible to retrieve and display the unrendered (i.e., the original HTML) source of the document by pressing -the '\' (backslash) key. The document must be reloaded from the -server or disk to be displayed on the screen unrendered, since Lynx -originally rendered what it received and does not still have it as source. +the '\' (backslash) key. Lynx usually caches only the rendering +of the document and doesn't keep the source (unless it is configured to do +so in the lynx.cfg file), so to display the source +unrendered, Lynx must reload it from the server or disk. When viewing unrendered documents you may print them as any normal document.

Selecting the Print to a local file option from the Print Menu, --- ./src/LYMainLoop.c.orig Tue Apr 13 05:39:16 1999 +++ ./src/LYMainLoop.c Wed Apr 14 11:27:19 1999 @@ -1260,7 +1260,7 @@ #ifdef SOURCE_CACHE /* * If the parse settings have changed since this HText was - * generated, we need to reparse and redraw it. + * generated, we need to reparse and redraw it. -dsb */ if (HTdocument_settings_changed()) { HTUserMsg(gettext("Reparsing document under current settings...")); @@ -1269,7 +1269,7 @@ else { /* * Urk. I have no idea how to recover from a failure here. - * At a guess, I'll try reloading. + * At a guess, I'll try reloading. -dsb */ cmd = LYK_RELOAD; goto new_cmd; @@ -1358,6 +1358,15 @@ if (lynx_edit_mode && nlinks > 0 && !HTList_isEmpty(tagged)) showtags(tagged); #endif /* DIRED_SUPPORT */ +#ifdef SOURCE_CACHE + /* + * This information can get clobbered if we go to an internal + * page while viewing source. Normally it would be recreated + * by reloading the file; we have to do it ourselves. -dsb + */ + if (curdoc.link < 0 && nlinks > 0) + curdoc.link = 0; +#endif if (user_mode == NOVICE_MODE) noviceline(more); /* print help message */ refresh_screen = FALSE; @@ -2110,6 +2119,17 @@ #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; + /* + * These normally get cleaned up after getfile() returns; + * since we're not calling getfile(), we have to clean them + * up ourselves. -dsb + */ + HTOutputFormat = WWW_PRESENT; +#ifdef USE_PSRC + if (psrc_view) + HTMark_asSource(); + psrc_view = FALSE; +#endif break; } #endif --- ./src/GridText.c.orig Tue Apr 13 05:39:16 1999 +++ ./src/GridText.c Wed Apr 14 11:27:08 1999 @@ -561,7 +561,7 @@ self->LastChar = '\0'; self->IgnoreExcess = FALSE; -#ifndef PSRC_TEST +#ifndef USE_PSRC if (HTOutputFormat == WWW_SOURCE) self->source = YES; else @@ -6186,7 +6186,7 @@ /* * This is more or less copied out of HTLoadFile(), except we don't - * get a content encoding. This may be overkill... + * get a content encoding. This may be overkill. -dsb */ if (HTMainText->node_anchor->content_type) { format = HTAtom_for(HTMainText->node_anchor->content_type); @@ -6241,6 +6241,11 @@ source_cache_chunk = NULL; } } + + /* + * I have no idea what this does, but it seems to be necessary... -dsb + */ + LYUCPopAssumed(); CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); return ok; From owner-lynx-dev@sig.net Wed Apr 14 12:19:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA09140 for ; Wed, 14 Apr 1999 12:19:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA09139; Wed, 14 Apr 1999 11:02:30 -0500 (CDT) Date: Wed, 14 Apr 1999 11:02:17 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch In-Reply-To: <199904140457.AAA26242@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 12223 Lines: 267 On Wed, 14 Apr 1999, Philip Webb wrote: > 990413 KW commented on my update of STARTFILE info in lynx.cfg : > >> # STARTFILE is the default starting URL if none is specified > >> # on the command line or via a WWW_HOME environment variable; > >> # Lynx will refuse to start without a starting URL of some kind. > >> # STARTFILE can be remote, e.g. http://www.w3.org/default.html , > >> # or local, e.g. file://localhost/PATH_TO/FILENAME , > >> # where PATH_TO is replaced with the complete path to FILENAME > >> # using Unix shell syntax and including the device on VMS. > >> # The default offered for ordinary users is their current directory: > >> STARTFILE:. > > This change flies in the face of what the documentation says, > > including the comments just above it. > > so the documentation needs further improvement: your turn ... > > > "." is not a URL! More generally, there are quite a few places > > - in userdefs.h > > - in lynx.cfg > > - in ynx_url_support.html > > that say that something "must" be a URL. > > !! URLs are not filenames. Filenames are not URLs. !! > > a local file URL is not just a filename prefixed with "file://localhost". > > a local filename is not just a file: URL stripped of "file://localhost". > > That happens to be true only sometimes, and then only for some OSs. > > in the absence of a proper account of exceptions, > i would maintain that in the context of everyday browsing, > a local file URL is a filename prefixed with file://localhost In the context of *your* everyday browsing, maybe. Certainly not in any Windows user's (or VMS user's, or OS/2 user's, etc.). And not if you happen to have a habit to use certain characters in filenames. > & a local filename may be used as a practical abbreviation > for a complete local file URL which includes file://localhost ; > . is then a double abbreviation for a local file URL. > > i may also have views about angels & pins, but that's off topic. If that's supposed to mean that the difference between URLs and filenames is all too academic: no it isn't. You can brush it away with some some 'It's basically the same' attitude, but that only increases the confusion. > the following discussion seems related solely to documentation: > > > Some of the "must"s are not technically required. > > [snip] > > Putting 'note: STARTFILE must be a URL' directly followed > > by '#define STARTFILE "."' in userdefs.h just increases the confusion. > ^^^^^^^^^^ lynx.cfg ? I did mean userdefs.h here, note the '#define'. It's like that in dev.22 now. > > To *decrease* the confusion, it should be stated clearly what is what: > >[ snip ] > > this seems to contain lots of sense: i look forward to your patches. > > > The patch (without doc changes) increases the discrepancy > > between documentation and reality, > > ditto > > > but I also question its usefulness. Is it a good thing > > to start with browsing the *current* directory by default? > > on further thought, i agree with LP: best default is Main Help Page. > can TD change that by hand for dev.23 ? > > > I guess Philip got tired of seeing all the problems people are having > > with lynx refusing to start, > > yes, of course. > > > but in most cases this change just hides or defers the problem. > > In most cases (I assume) people *want* to make a network connection. > > So now they'll see Lynx start up and not exit immediately, > > but if there network is somehow misconfigured they still can't go anywhere; > > and if the problem is just that they haven't configured lynx > > (when they would want to), it also doesn't help much. > > no: you haven't been following users' inquiries closely enough. I have at least seen most of them. Your description (below) only talks about a subset of them. > the problem arises when l.b.o. is down -- not infrequently -- , > so that Lynx refuses to start & the user can't even enter h ; > this could happen with any remote site, > so the solution has to be to make the default a local URL: > it has to be one we know will always be available, That's only the solution if you define the problem in a certain way. But different people have different problems. 0) When users have problems like "lynx: Can't access start file file://localhost/afs/uni-bonn.de/home/uzr109/lynx/htmls/home_voe.html" (as in one recent report), then obviously this has nothing to do with l.b.o, but is just plain misconfiguration. Changing the distribution default would obviously not help here, since the default isn't being used. 1) When l.b.o is down or unreachable, and the user *wants to* go to l.b.o, then the problem is that l.b.o is down or unreachable. 2) When l.b.o is down or unreachable, and the user doesn't want to go to l.b.o but rather just start up lynx in order to go somewhere, then the problem is that (a) lynx has not been properly configured (to a more appropriate place) and/or (b) the user hasn't learned how to invoke lynx to go to the desired place directly. 3) When l.b.o is unreachable as well as any other remote site because networking or DNS doesn't work, then the problem is the network or DNS setup. The preferred solution would be - for 1), to improve stability and reachability of lynx.browser.org (or ultimately, point the DNS name to a different box). - for 2), system admins / users should configure lynx. Users should learn to point lynx the right way. Maybe some documentation changes would help, but there's always people who don't read any docs. - for 3), the underlying network problem has to be fixed. This seems to be a problem mostly for users of 386 binaries. Maybe creators of those packages can make further improvements (or maybe they are already doing everything that makes sense). I see only two possibilities where a default of 'STARTFILE:.' would solve the problem (rather than just shifting it): 4) The user wants to just test whether lynx "works", probably after having just installed it. User is mislead into thinking "lynx is broken" when it's really l.b.o something else. - Well, the problem is "solved" with 'STARTFILE:.', the user now thinks he has no problem when in reality he does. 5) You regard the amount of mail to lynx-dev with 'Can't access start file' as the real problem. Maybe for some reaon you feel obliged to answer every single one of them, and want to decrease your self-imposed workload. - Well, you could indeed decrease the number of mails who say 'Can't access start file'. Instead all the folks who would have sent them will send error reports with different symptoms (minus the few who neever browse remote documents anyway). Unless you somehow come up with a way that lynx can detect and analyze which is the real underlying problem and then tell the user how to solve it without writing to lynx-dev. Better solution, if 5) should apply: take a break. :) > which makes the Main Help Page the best choice, > as there may be systems which won't understand . , That would be a bug that has to be fixed > but given such a default, we can be confident they can at least get started. To get lynx started up isn't much of an improvement, unless it works right after that. I.e. of 0) - 3) above, this works only for case 2), which A) doesn't seem to be the most frequent nowadays, and B) those users shouldn't have been going to the unchanged installation default all the time anyway, and C) (unless anonymous/menu installation) users can easily type 'lynx .' or 'lynx -book' or 'lynx ' (and D) if this happens for anonymous/menu things are beyonf hope anyway). There's no guarantee that a local copy of the Main Help Page is available at runtime where lynx expects it. My guess is that the number of installations where this is broken outweighs the l.b.o downtime/reachability and startfile-unconfigured problems combined. > typically, queries come from people using a shared Lynx, > whose invariably overworked sysadmin hasn't changed the default. Seems to me that more recently most 'Can't access start file' problems were coming from users of the DOS and Windows ports. > > Anyway, I suggest it would be better to at least start with > > the user's home directory by default, instead of '.'. > > this can be specified in URL form: "file://localhost/~/" should work. > > that's another possibility, but Main Help Page seems better. > > >> # *** NBB *** System administrators with ANONYMOUS USERS !!! > >> # set STARTFILE to a REMOTE FILE by uncommenting the next line: > >> #STARTFILE:http://lynx.browser.org/ > >> # and commenting out the default offered above; > >> # you may, of course, choose to replace `lynx.browser.org' > >> # with another remote/local file which you know to be safe. > > It doesn't make much sense to ask system administrators > > with ANONYMOUS USERS (them and only them) to set STARTFILE > > to "http://lynx.browser.org/" or to a 'REMOTE FILE'. > > Those are probably exactly the folks who want to point STARTFILE > > to a specific (probably local) location. Not just 'you may', they SHOULD. > > well yes, but we don't know which local location, do we? No, and why should we? People configuring for use by anonymous users have to go through the files carefully anyway and put in whatever fits their situation. No point in starting to shout at them in this one place as if this was all they have to do. > and we have to have a very simple default they can substitute > or we'll have Henry (grin) screaming that the sky is falling. > by all means, add 1 - 2 lines of further advice: your patch? > > > OTOH it looks now as if http://lynx.browser.org/ were only suggested > > for those administrators with ANONYMOUS USERS, not for others. > > It should be suggested as an alternative for everyone. > > Even better, it should be more strongly suggested > > that folks actually change STARTFILE to *what they want*. > > as i said: your patch? My preliminary patch would consist of completely removing that whole *** NBB *** paragraph, as Henry suggested. (What's NBB supposed to mean anyway?) > >> # Lynx will refuse to start without a starting URL of some kind. > > It isn't actually possible to *not* have a starting URL of some kind. > > There's the userdefs.h default, lynx can't even be compiled without it > > (as you have noticed); so this doesn't make sense. > > `Lynx will refuse to start if it cannot find a starting URL of some kind': > your patch? You submit a patch, its gets included. Problems and inconsistencies are pointed out. You are reacting as if it were none of your business - let others fix problems you created, right? I already have a queue of other patches I haven't gotten around to brush up and send. Maybe I'll eventually send some changes for this stuff, but I'd prefer someone else to do it, before I get to it. The use of '.' *as a potential,optional value* could be more prominently suggested. Maybe you can find it in your heart... That would be for clarifying documentation. Leonid seems to be interested in unifying option handling for filenames, which could be related. Until such changes happen, I suggest that the startfile default change back to "http://lynx.browser.org/". I am not absolutely opposed to changing it so something local (but at mentioned it should probably not be ".".) It just seems to me it's not such a good idea. What's "http://lynx.browser.org/", really? It is just a pointer that can be changed at any time (by editiong the page, or by changing the pointer by $ nslookup -q=SOA browser.org ... browser.org origin = ns0.plig.net mail addr = hostmaster.browser.org [presumably Rob Partington]) to point to the most sensible "default" page. The whole point of the page is to serve that purpose. As soon as we try to hardwire more help or error text into lynx, there is the danger that it will be outdated soon. If additional help or error text is distributed as local files to-be-install, there's also the same danger execpt for users/sites which keep updating the files, and the separate files may get "lost" anyway. Klaus From owner-lynx-dev@sig.net Wed Apr 14 12:34:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA09682 for ; Wed, 14 Apr 1999 12:34:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA14826; Wed, 14 Apr 1999 11:18:03 -0500 (CDT) From: Philip Webb Message-Id: <199904141614.MAA10682@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 12:14:21 -0400 (EDT) In-Reply-To: from "Leonid Pauzner" at Apr 14, 99 05:31:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1903 Lines: 44 990414 Leonid Pauzner wrote: > 14-Apr-99 08:40 Philip Webb wrote: > > or the message could be hard-coded, like the Print screen: eg > > > Start File Inaccessible > > > Lynx is unable to access your start file ...: > > you can try your start file again by pressing Enter > > or you can go on with your Lynx session with any Lynx command > > -- e.g. `g'oto , `h'elp or `v'iew bookmarks -- > > or you can quit Lynx with `q' or `Q' (unconditional). > This is not a programming problem, to get a consensus is. it seems to me my suggestion above satisfies all views so far. > I would rather prefer to correct exit messages > with a hint of what happend and what can to do. of course, now you've raised another one ... > Say: - incorrect startfile URL syntax; > - local file not found; > - DNS lookup failure; > - interrupted by user; > - internal error (!) etc. the problem case is none of these, tho' DNS & `local not found' are similar: it's where an ordinary user can't start Lynx because Lynx can't get thro' to l.b.o. or some other remote STARTFILE, but there's nothing else (known to be) wrong with the Lynx set-up. that specific case can be handled -- easily you say -- by programming Lynx to react in that -- specific -- case with a screen as above; other cases would result in error messages, which could certainly be customised to give a hint what's wrong. so can you have a go at getting Lynx to put up that screen (just) when it can't find the specified STARTFILE & would have let the user get on with his/her session, if it had occurred with some other URL after starting successfully? ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Wed Apr 14 12:37:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA09715 for ; Wed, 14 Apr 1999 12:37:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA16654; Wed, 14 Apr 1999 11:22:55 -0500 (CDT) Date: Wed, 14 Apr 1999 12:22:48 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev dev.22 exiting with signal: 11 In-Reply-To: <199904141531.JAA06036@sanitas> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 542 Lines: 18 On Wed, 14 Apr 1999 pg@sweng.stortek.com wrote: > Start Lynx > '=' (go to info page) > (go to slcc development version page) > '\' (display source) > (back to info page) > (back to source of slcc page) > ^T (Trace on) > '\' (attempt to display rendered page) > > A Fatal error has occurred in Lynx Ver. 2.8.2dev.22 This sounds like a variant of one of the bugs I fixed in my most recent patch. Try that and see if it helps. -sbigham From owner-lynx-dev@sig.net Wed Apr 14 12:57:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA10271 for ; Wed, 14 Apr 1999 12:57:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA24016; Wed, 14 Apr 1999 11:42:34 -0500 (CDT) From: dickey@clark.net Message-Id: <199904141642.MAA15402@shell.clark.net> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 12:42:30 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 14, 99 11:02:17 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 588 Lines: 19 > > the following discussion seems related solely to documentation: > > > > > Some of the "must"s are not technically required. > > > [snip] > > > Putting 'note: STARTFILE must be a URL' directly followed > > > by '#define STARTFILE "."' in userdefs.h just increases the confusion. > > ^^^^^^^^^^ lynx.cfg ? > > I did mean userdefs.h here, note the '#define'. It's like that in dev.22 > now. right - lynx.cfg and userdefs.h (should) get changed in sync. > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Apr 14 13:52:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA11886 for ; Wed, 14 Apr 1999 13:52:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA14267; Wed, 14 Apr 1999 12:38:38 -0500 (CDT) Date: Wed, 14 Apr 1999 13:38:25 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1407 Lines: 39 On Wed, 14 Apr 1999, Leonid Pauzner wrote: > Thanks for you fix! More problems found with SOURCE_CACHE!=NONE: > the length of the re-rendered text may vary so the scrolling down > is broken (especially nice when switching to source). > This patch will fix it ("more" updated, "lines_in_file" inlined), Eek! Surely this can be localized somewhat. Try the following patch instead, applied on top of my previous dev22 patch: --- src/LYMainLoop.c.v2 Wed Apr 14 13:20:49 1999 +++ src/LYMainLoop.c Wed Apr 14 13:24:05 1999 @@ -1361,9 +1361,12 @@ #ifdef SOURCE_CACHE /* * This information can get clobbered if we go to an internal - * page while viewing source. Normally it would be recreated - * by reloading the file; we have to do it ourselves. -dsb + * page while viewing source, or if the page length changes + * between reparses. Normally it would be recreated by + * reloading the file; we have to do it ourselves. -dsb */ + more = HText_canScrollDown(); + lines_in_file = HText_getNumOfLines(); if (curdoc.link < 0 && nlinks > 0) curdoc.link = 0; #endif > More problems expected since we now reload documents > out of mainloop() cyrcle. Not so much outside of mainloop(); we're just tripping over things that would normally get cleaned up behind getfile(). And yes, I do expect to run into more of them... :-( -sbigham From owner-lynx-dev@sig.net Wed Apr 14 14:14:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA12785 for ; Wed, 14 Apr 1999 14:14:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA22065; Wed, 14 Apr 1999 13:00:40 -0500 (CDT) Date: Wed, 14 Apr 1999 03:08:21 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev LYK_PIPE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 141 Lines: 6 I saw this command in LYKeyMap.[ch] - comments say it's not yet implemented. What it was designed for and by whom? Best regards, -Vlad From owner-lynx-dev@sig.net Wed Apr 14 14:14:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA12799 for ; Wed, 14 Apr 1999 14:14:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA22027; Wed, 14 Apr 1999 13:00:34 -0500 (CDT) Date: Wed, 14 Apr 1999 03:24:16 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev extending the syntax of 'include' command in lynx.cfg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1081 Lines: 26 IMO it would be good if the 'include' command had the list of settings that can be specified in included file. So admins can specify 'include:~/.lynx/colors:COLOR' 'include:~/.lynx/keymap:KEYMAP' 'include:~/.lynx/viewers:VIEWER' safely - and be sure that no critical options were altered by those files. The suggested syntax is include:[:[* ] ] more samples: include:~/.lynx/rc:COLOR KEYMAP VIEWER SUFFIX include:/usr/local/lib/lynx-cfg.part: #all settings can be changed More brave approach: Make ~/.lynxrc to be included by lynx.cfg (it's syntax must be changed to one of lynx.cfg), with a list of options it can contain in the 'include' line. As I understand, with LP's patch lynx.cfg can be edited at runtime and reloaded in the same session - such feature as editing options specified in .lynxrc at runtime is not the major privelege (or feature) of .lynxrc. So, a huge section of code ~32KB can be removed when using this approach. In present state, users with paranoid sysadm were to live with colors s/he specify. Best regards, -Vlad From owner-lynx-dev@sig.net Wed Apr 14 14:23:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA12858 for ; Wed, 14 Apr 1999 14:23:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA26226; Wed, 14 Apr 1999 13:12:33 -0500 (CDT) To: lynx-dev@sig.net, mss@transas.com References: <19990414181149.A13480@transas.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 20:53:26 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Commenting... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 786 Lines: 22 14-Apr-99 18:11 Michael Sobolev wrote: > Hello, > I am not sure whether this forum is suitable for user questions. :) > If not, please direct me to the proper forum. > The question is quite simple. There is a command called `comment to author', > where can I find the information on how to provide the appropriate information > for this feature? I believe this is some processing of or tags, > but what? And another question, there is a way for providing alternative > versions of documents via tag, does lynx support this in some way? If > no, is it going to do that (that's developer's question :)? Your question probably addressed to HTML specs (a suitable references can be found from lynx help page - press "h" inside lynx). > Thanks, > -- > Mike From owner-lynx-dev@sig.net Wed Apr 14 14:24:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA13074 for ; Wed, 14 Apr 1999 14:24:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA26179; Wed, 14 Apr 1999 13:12:28 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 22:06:57 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1214 Lines: 29 14-Apr-99 12:01 Scott Bigham wrote: > On Tue, 13 Apr 1999, Vlad Harchev wrote: >> I have the following problem with dev22: >> When pressing '\' on non-local files, the psrc view is shown, but there is no >> way out of this mode. This patch will fix it. > Actually, I already have a more localized fix of that in this patch. > Also included are fixes for related bugs tweaked by going to an internal > page while viewing source, and a few blurbs in the documentation (which > don't really say much, but...). Thanks! Your fixes challenges around my own:) Along with my changes to page length fixing (scrolling down) yours' fixes most problems with source mode. Currently, the page owner is not restored properly in LYK_SOURCE after HTreparse_document() - add a chunk from near the top of LYMainLoop.c Probably LYUCPopAssumed() and HTMLSetCharacterHandling() should go there also. The latter not very clear for me, probably useful for CJK? > [Note to Tom: if you've already applied Leonid's recent > UCLYhndl patch, then you can punt the part of this patch that > touches HTAccess.[ch], because his patch already does what mine needs.] > -sbigham From owner-lynx-dev@sig.net Wed Apr 14 15:11:06 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA14386 for ; Wed, 14 Apr 1999 15:11:05 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA12298; Wed, 14 Apr 1999 13:57:17 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 22:51:37 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1281 Lines: 27 14-Apr-99 12:01 Scott Bigham wrote: > On Tue, 13 Apr 1999, Vlad Harchev wrote: >> I have the following problem with dev22: >> When pressing '\' on non-local files, the psrc view is shown, but there is no >> way out of this mode. This patch will fix it. > Actually, I already have a more localized fix of that in this patch. > Also included are fixes for related bugs tweaked by going to an internal > page while viewing source, and a few blurbs in the documentation (which BTW, I found one more bug (my own) with reloading sources, (completely independent from SOURCE_CACHE and USE_PSRC), just a returning from forms-based options menu, the exit from postoptions(). There are two LYpop() cycles there, the document is uncached and returned with NULLFILE to the last cyrcle. If I had a document in source mode before entering the options menu, change some layout-dependent option like "raw mode" or "show images" and accept the changes - original document redisplayed in normal mode, not a source. So mystery with HTOutputFormat or so. Since you spent a time to learn this code you can probably came with a fix... Probably the exit from options menu may now utilize the power of SOURCE_CACHE, though it handles more parameters than HTdocument_settings_changed() Leonid. From owner-lynx-dev@sig.net Wed Apr 14 15:27:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA14907 for ; Wed, 14 Apr 1999 15:27:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA18528; Wed, 14 Apr 1999 14:14:35 -0500 (CDT) From: mattack@area.com Date: Wed, 14 Apr 1999 12:14:31 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev lynx devel and pre + ssl support: patches? In-Reply-To: <199904140225.WAA18412@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 919 Lines: 19 On Tue, 13 Apr 1999, Philip Webb wrote: >990413 Frederic Meunier wrote: >> Anyone here make patches for all the devel and pre versions of Lynx >> and can place them on a download location? >> Or the patch can be included in the tarball? > >due to US national-security laws & copyright/patent concerns, >Lynx does not distribute encryption patches. >you can obtain them from www.moxienet.com/lynx . >also see Lynx help -- `h' -- for sites which offer help for SSL. If one of the current bills concerning security export from the US passes, is there anything that can be done to come closer to having SSL built into Lynx? In other words, while they still won't be able to be shipped together (because of the patent concerns), is there anything that could be done to make it less of a hassle to get SSL into Lynx? (hooks, automatically going to some URL to download the SSL stuff when you try an https link, etc..) From owner-lynx-dev@sig.net Wed Apr 14 16:19:11 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA16567 for ; Wed, 14 Apr 1999 16:19:08 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA05798; Wed, 14 Apr 1999 15:03:00 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 23:57:28 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1540 Lines: 37 14-Apr-99 03:24 Vlad Harchev wrote: > More brave approach: > Make ~/.lynxrc to be included by lynx.cfg (it's syntax must be changed to one > of lynx.cfg), with a list of options it can contain in the 'include' line. As > I understand, with LP's patch lynx.cfg can be edited at runtime and reloaded Right. BTW, does it work for your prettysrc settings: I saw a DTD fix before read_cfg() in LYMain.c, so assume may be a problem when reloading changes in another current DTD or so. Is it OK for you? > in the same session - such feature as editing options specified in .lynxrc > at runtime is not the major privelege (or feature) of .lynxrc. So, a huge > section of code ~32KB can be removed when using this approach. Not sure the benefits: Currently we have a compromise between a huge jar of options (lynx.cfg) for advanced and expetienced user, and a small menu-driven subset (we should not normaly looks into .lynxrc et all, it is a machine generated file). It is not possible (and not useful) to made all lynx.cfg options menu driven since that introduce more problems than it solves. just few points: - .lynxrc has options with other names when in lynx.cfg so we should add synonyms to provide compatibility, etc. - we should restrict most lynx.cfg options for .lynxrc - command line flags in between... > In present state, users with paranoid sysadm were to live with colors s/he > specify. ??? what do you mean? with paranoid sysadmin you can get an opprtunity to have no opportunity et all. > Best regards, > -Vlad From owner-lynx-dev@sig.net Wed Apr 14 16:29:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA16887 for ; Wed, 14 Apr 1999 16:29:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA05828; Wed, 14 Apr 1999 15:03:02 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 14 Apr 1999 23:14:36 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1808 Lines: 44 14-Apr-99 13:38 Scott Bigham wrote: > On Wed, 14 Apr 1999, Leonid Pauzner wrote: >> Thanks for you fix! More problems found with SOURCE_CACHE!=NONE: >> the length of the re-rendered text may vary so the scrolling down >> is broken (especially nice when switching to source). >> This patch will fix it ("more" updated, "lines_in_file" inlined), > Eek! Surely this can be localized somewhat. Try the following patch > instead, applied on top of my previous dev22 patch: > --- src/LYMainLoop.c.v2 Wed Apr 14 13:20:49 1999 > +++ src/LYMainLoop.c Wed Apr 14 13:24:05 1999 > @@ -1361,9 +1361,12 @@ > #ifdef SOURCE_CACHE > /* > * This information can get clobbered if we go to an internal > - * page while viewing source. Normally it would be recreated > - * by reloading the file; we have to do it ourselves. -dsb > + * page while viewing source, or if the page length changes > + * between reparses. Normally it would be recreated by > + * reloading the file; we have to do it ourselves. -dsb > */ > + more = HText_canScrollDown(); > + lines_in_file = HText_getNumOfLines(); > if (curdoc.link < 0 && nlinks > 0) > curdoc.link = 0; > #endif Looks well. Agree that mainloop-dependent things should be fixed there, if possible. But the `lines_in_file' should go away for sure - it is set in more places than it actually used (10:3 ratio, I hope). >> More problems expected since we now reload documents >> out of mainloop() cyrcle. > Not so much outside of mainloop(); we're just tripping over things that > would normally get cleaned up behind getfile(). And yes, I do expect to > run into more of them... :-( > -sbigham From owner-lynx-dev@sig.net Wed Apr 14 16:42:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA17252 for ; Wed, 14 Apr 1999 16:42:14 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA16089; Wed, 14 Apr 1999 15:31:30 -0500 (CDT) Date: Wed, 14 Apr 1999 19:51:50 +0430 (IRST) From: Vahid Sanei To: lynx-dev@sig.net Subject: lynx-dev Problem with lynx 2.8.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 573 Lines: 14 Hi there, I recently downloaded and installed lynx 2.8.1 in my home directory, but I have a problem with it. When I read HTML files by lynx 2.8.1, it shows links and hypertexts in reverse mode instead of showing them in color and changing terminal settings has not any effect on it, but when I use my previous lynx 2.6 hypertexts apear in color. How can I overcome this problem. I would appreciate receiving your comments. Best regards Vahid Sanei Institute of Biochemistry and Biophysics, Tehran University, Tehran, Iran. ######################################### From owner-lynx-dev@sig.net Wed Apr 14 16:44:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA17475 for ; Wed, 14 Apr 1999 16:44:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA16050; Wed, 14 Apr 1999 15:31:25 -0500 (CDT) Date: Wed, 14 Apr 1999 18:42:19 +0200 (MEST) From: Matthias Knopf To: lynx-dev@sig.net cc: lynxdev@browser.org Subject: lynx-dev LYNX 2.8rel.2 and INPUT TYPE=FILE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 302 Lines: 14 Hi. I noticed, that lynx (in this version) can not handle forms like

So, my question is: When will this be implemented? (i hope, that it is planed for the near future!!!) Best regards, Jim (Matthias Knopf) --- In a world without fences ... who needs GATES From owner-lynx-dev@sig.net Wed Apr 14 16:51:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA17577 for ; Wed, 14 Apr 1999 16:51:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA18693; Wed, 14 Apr 1999 15:38:25 -0500 (CDT) Date: Wed, 14 Apr 1999 16:37:45 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch Message-ID: <19990414163745.B25130@mail.bcpl.net> References: <199904140457.AAA26242@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Klaus Weide on Wed, Apr 14, 1999 at 11:02:17AM -0500 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 674 Lines: 15 On Wed, Apr 14, 1999 at 11:02:17AM -0500, Klaus Weide wrote: > On Wed, 14 Apr 1999, Philip Webb wrote: > > 990413 KW commented on my update of STARTFILE info in lynx.cfg : > My preliminary patch would consist of completely removing that whole > *** NBB *** paragraph, as Henry suggested. (What's NBB supposed to mean > anyway?) NB is "nota bene" or "note well", as in "take particular notice", so NBB is then "note very well". Probably should be gettexted(;-). ------ Marvin the Paranoid Android says: Pathetic isn't it? From owner-lynx-dev@sig.net Wed Apr 14 18:24:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA21871 for ; Wed, 14 Apr 1999 18:24:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20913; Wed, 14 Apr 1999 17:06:39 -0500 (CDT) Date: Thu, 15 Apr 1999 02:00:48 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... Message-ID: <19990415020048.C932@transas.com> References: <19990414181149.A13480@transas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Leonid Pauzner on Wed, Apr 14, 1999 at 08:53:26PM +0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1011 Lines: 18 On Wed, Apr 14, 1999 at 08:53:26PM +0400, Leonid Pauzner wrote: > 14-Apr-99 18:11 Michael Sobolev wrote: > > The question is quite simple. There is a command called `comment to author', > > where can I find the information on how to provide the appropriate information > > for this feature? I believe this is some processing of or tags, > > but what? And another question, there is a way for providing alternative > > versions of documents via tag, does lynx support this in some way? If > > no, is it going to do that (that's developer's question :)? > > Your question probably addressed to HTML specs (a suitable references > can be found from lynx help page - press "h" inside lynx). Hmm.. Right before asking I checked the spec for HTML 4.0. It says about certain values for LINK, and for META tgs. But the only author I found () doe not work with Lynx: when I press c on my newly create page with author meta information, I get the message no owner is defined. -- Mike From owner-lynx-dev@sig.net Wed Apr 14 20:15:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA24942 for ; Wed, 14 Apr 1999 20:15:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA22089; Wed, 14 Apr 1999 19:06:26 -0500 (CDT) Date: Wed, 14 Apr 1999 20:05:49 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... Message-ID: <19990414200549.A15422@mail.bcpl.net> References: <19990414181149.A13480@transas.com> <19990415020048.C932@transas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990415020048.C932@transas.com>; from Michael Sobolev on Thu, Apr 15, 1999 at 02:00:48AM +0400 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1422 Lines: 26 On Thu, Apr 15, 1999 at 02:00:48AM +0400, Michael Sobolev wrote: > On Wed, Apr 14, 1999 at 08:53:26PM +0400, Leonid Pauzner wrote: > > 14-Apr-99 18:11 Michael Sobolev wrote: > > > The question is quite simple. There is a command called `comment to author', > > > where can I find the information on how to provide the appropriate information > > > for this feature? I believe this is some processing of or tags, > > > but what? And another question, there is a way for providing alternative > > > versions of documents via tag, does lynx support this in some way? If > > > no, is it going to do that (that's developer's question :)? > > > > Your question probably addressed to HTML specs (a suitable references > > can be found from lynx help page - press "h" inside lynx). > Hmm.. Right before asking I checked the spec for HTML 4.0. It says about > certain values for LINK, and for META tgs. But the only author I found () > doe not work with Lynx: when I press c on my newly create page with author > meta information, I get the message no owner is defined. Lynx can use the following as an author/owner tag: ------ Marvin the Paranoid Android says: Pathetic isn't it? From owner-lynx-dev@sig.net Wed Apr 14 22:45:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA29188 for ; Wed, 14 Apr 1999 22:45:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA25549; Wed, 14 Apr 1999 21:35:07 -0500 (CDT) Date: Thu, 15 Apr 1999 11:46:36 +0900 (JST) From: Henry Nelson Message-Id: <199904150246.LAA16782@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 607 Lines: 14 > > >> # *** NBB *** System administrators with ANONYMOUS USERS !!! [...] > > No, and why should we? People configuring for use by anonymous users > have to go through the files carefully anyway and put in whatever fits What is done with "http://lynx.browser.org/" or ".", no big deal; at least no one will get burnt. THIS section on -anonymous IS potentially misleading and could result in disaster. I will yell from the bleachers one more time: take it out of there; it's irresponsible. This is a case where no knowledge is better than a little. No punches pulled; take it for what it's worth. __Henry From owner-lynx-dev@sig.net Thu Apr 15 00:29:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA31898 for ; Thu, 15 Apr 1999 00:29:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA16358; Wed, 14 Apr 1999 23:11:40 -0500 (CDT) From: Philip Webb Message-Id: <199904150411.AAA02078@chass.utoronto.ca> Subject: Re: lynx-dev Re: STARTFILE patch To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 00:11:34 -0400 (EDT) In-Reply-To: <199904150246.LAA16782@ibr1.irm.nara.kindai.ac.jp> from "Henry Nelson" at Apr 15, 99 11:46:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3765 Lines: 78 990415 Henry Nelson commented on the lines following this one: >> # *** NBB *** System administrators with ANONYMOUS USERS !!! > What is done with "http://lynx.browser.org/" or ".", no big deal; > at least no one will get burnt. THIS section on -anonymous IS > potentially misleading and could result in disaster. > I will yell from the bleachers one more time: > take it out of there; it's irresponsible. > This is a case where no knowledge is better than a little. > No punches pulled; take it for what it's worth. ok ok: no problem here: i did explicitly invite your opinion. the patch below gives KW's URL for the user's home directory, which works: the resulting screen may not enlighten novices, but will solve the problem when sysadmins leave the default & l.b.o. is not accessible; hopefully, the rest is not likely to mislead anyone. whoever changed userdefs.h should fix that too (it wasn't me). beyond that, HN's & my idea of having a simple message screen which comes up when any STARTFILE is not accessible -- with appropriate advice to users on the next step -- should surely not cause further contention: i offered an example, which could have a few more lines pointing out that if eg `g'oto doesn't work, there may be deeper problems involving the Lynx/network set-up & how to start investigating & solving them: eg If you have difficulty using ordinary Lynx commands at this point, there may be more serious problems with your system or network. If you have compiled and installed Lynx yourself, check carefully in the INSTALLATION and PROBLEMS files and make sure userdefs.h and lynx.cfg have appropriate choices. If you are using a shared version of Lynx, consult your sysadmin. i can put it on my list of little programming exercises, but LP could probably do the job in a few minutes. what all this really shows is how badly neglected is the whole area of Lynx documentation, much of which is obscure &/or out-of-date: one slight pull on one insignificant string & a whole closet-full of heavy objects starts to fall on your head ... *** old/lynx.cfg Wed Apr 14 23:32:41 1999 --- new/lynx.cfg Wed Apr 14 23:45:43 1999 *************** *** 40,54 **** # or local, e.g. file://localhost/PATH_TO/FILENAME , # where PATH_TO is replaced with the complete path to FILENAME # using Unix shell syntax and including the device on VMS. ! # The default offered for ordinary users is their current directory: ! STARTFILE:. ! # ! # *** NBB *** System administrators with ANONYMOUS USERS !!! ! # set STARTFILE to a REMOTE FILE by uncommenting the next line: #STARTFILE:http://lynx.browser.org/ - # and commenting out the default offered above; - # you may, of course, choose to replace `lynx.browser.org' - # with another remote/local file which you know to be safe. # HELPFILE must be defined as a URL and must have a # complete path if local: --- 40,50 ---- # or local, e.g. file://localhost/PATH_TO/FILENAME , # where PATH_TO is replaced with the complete path to FILENAME # using Unix shell syntax and including the device on VMS. ! # The default offered for ordinary users is their home directory: ! STARTFILE:file://localhost/~/ ! # If for any reason you don't want to use a local URL, ! # you might consider using the Lynx starting site: #STARTFILE:http://lynx.browser.org/ # HELPFILE must be defined as a URL and must have a # complete path if local: -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 15 00:33:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA31914 for ; Thu, 15 Apr 1999 00:33:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA17886; Wed, 14 Apr 1999 23:20:38 -0500 (CDT) Date: Wed, 14 Apr 1999 13:44:00 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2540 Lines: 58 On Wed, 14 Apr 1999, Leonid Pauzner wrote: > 14-Apr-99 03:24 Vlad Harchev wrote: > > More brave approach: > > Make ~/.lynxrc to be included by lynx.cfg (it's syntax must be changed to one > > of lynx.cfg), with a list of options it can contain in the 'include' line. As > > I understand, with LP's patch lynx.cfg can be edited at runtime and reloaded > > Right. BTW, does it work for your prettysrc settings: > I saw a DTD fix before read_cfg() in LYMain.c, so assume may be a problem > when reloading changes in another current DTD or so. Is it OK for you? As long tag names in both DTD are the same at the same indexes, it doesn't matter what DTD it is. I use tag names to compute hashes of tags. > > in the same session - such feature as editing options specified in .lynxrc > > at runtime is not the major privelege (or feature) of .lynxrc. So, a huge > > section of code ~32KB can be removed when using this approach. > > Not sure the benefits: > Currently we have a compromise between a huge jar of options (lynx.cfg) for > advanced and expetienced user, and a small menu-driven subset (we should not > normaly looks into .lynxrc et all, it is a machine generated file). > It is not possible (and not useful) to made all lynx.cfg options menu driven > since that introduce more problems than it solves. I don't mean that we should make ALL options of lynx.cfg menu-editable - I meant that options currently allowed in .lynxrc should be menu-editable - so no (possible) change should be made to option menu generation, etc. > just few points: > - .lynxrc has options with other names when in lynx.cfg > so we should add synonyms to provide compatibility, etc. IMO this is a main problem, but it can be solved. > - we should restrict most lynx.cfg options for .lynxrc According to the syntax I propose, the allowed options are specified, not disallowed. So the line that limit the allowed options for .lynxrc won't be very long. > - command line flags in between... This can be solved. > > In present state, users with paranoid sysadm were to live with colors s/he > > specify. > ??? what do you mean? > with paranoid sysadmin you can get an opprtunity > to have no opportunity et all. > And what do you mean? I meant the following: for lynx compiled without lss, colors are specified in lynx.cfg. Since it's not writable by user, each user have to use the colors sysadm specified (same for viewers, keymaps...) PS: And I don't insist on making .lynxrc to be included by lynx.cfg. Best regards, -Vlad From owner-lynx-dev@sig.net Thu Apr 15 00:33:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA31919 for ; Thu, 15 Apr 1999 00:33:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA17871; Wed, 14 Apr 1999 23:20:35 -0500 (CDT) Date: Wed, 14 Apr 1999 13:32:13 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2079 Lines: 45 On Wed, 14 Apr 1999, Leonid Pauzner wrote: > 14-Apr-99 12:01 Scott Bigham wrote: > > On Tue, 13 Apr 1999, Vlad Harchev wrote: > > >> I have the following problem with dev22: > >> When pressing '\' on non-local files, the psrc view is shown, but there is no > >> way out of this mode. This patch will fix it. > > > Actually, I already have a more localized fix of that in this patch. > > Also included are fixes for related bugs tweaked by going to an internal > > page while viewing source, and a few blurbs in the documentation (which > > BTW, I found one more bug (my own) with reloading sources, > (completely independent from SOURCE_CACHE and USE_PSRC), > just a returning from forms-based options menu, > the exit from postoptions(). There are two LYpop() cycles there, > the document is uncached and returned with NULLFILE to the last cyrcle. > > If I had a document in source mode before entering the options menu, > change some layout-dependent option like "raw mode" or "show images" > and accept the changes - original document redisplayed in normal mode, > not a source. So mystery with HTOutputFormat or so. Since you > spent a time to learn this code you can probably came with a fix... > > Probably the exit from options menu may now utilize the power of SOURCE_CACHE, > though it handles more parameters than HTdocument_settings_changed() > > Leonid. > I found another bug: if there is something on the cache stack (say doc A -current doc and doc B), and we go to 'O' and change something, only appearance of 'A' is changed, the appearance of B is not changed - the cahced version is used. IMO it will be better to uncache everything in the stack. This is best tested with 'links are/not numbered' - since rendered versions differ a lot. If the bug I described is fixed, then all documents will return to their normal (not source) representnation (or we have to keep a stack of modes of the documents somehow - or probably set the pointer to HText to NULL in the cache, but marking whether it was 'source' view or not) Best regards, -Vlad From owner-lynx-dev@sig.net Thu Apr 15 02:14:53 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA01672 for ; Thu, 15 Apr 1999 02:14:52 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA25647; Thu, 15 Apr 1999 00:19:34 -0500 (CDT) From: David Woolley Message-Id: <199904140734.IAA11506@djwhome.demon.co.uk> Subject: Re: lynx-dev Persistent cookies between batch-mode Lynx calls? To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 08:34:16 +0100 (BST) In-Reply-To: from "Hugo Rabson" at Apr 13, 99 04:24:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1148 Lines: 21 > > Does Lynx clean out / erase its cookie file between sessions (be they > interactive or command line mode)? Does Lynx simply not save/handle cookies It is required by the cookie standards to discard session cookies (the more benign type) between sessions. If this is your problem, it arises because you are using a broader definition of a session than most browsers use - most browsers equate a single run of the program with a session. However, I do tend to feel that trying to automate something like hotmail is a mis-direction of effort, which is doomed to be always fighting changes in the service. If hotmail wanted you to automate things, they would provide pop3 mail boxes. If they don't, I think it may well be because they intensely dislike people who bypass the advertising that they add. If you still want to do this sort of thing, I would suggest a better approach would be to use a Perl HTTP module and use Perl to interact with the site. You can then use Lynx to render the captured HTML, although, for plain text email, if the HTML is well constructed, you can probably parse it out with a simple HTML parser, yourself. From owner-lynx-dev@sig.net Thu Apr 15 02:14:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA01677 for ; Thu, 15 Apr 1999 02:14:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA25763; Thu, 15 Apr 1999 00:20:19 -0500 (CDT) From: David Woolley Message-Id: <199904140711.IAA11463@djwhome.demon.co.uk> Subject: Re: lynx-dev Client-Side-Pull To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 08:11:09 +0100 (BST) In-Reply-To: <199904132315.TAA25325@pub.siac.com> from "tvassila@Siac.COM" at Apr 13, 99 07:15:26 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 711 Lines: 17 > > Why can't one configure Lynx to activate Client-side pull , HTTP-EQUIV="Refresh" CONTENT="3; URL="http://host/path">, has anybody > done this. > Lynx DOES support this, but as a link, not by automatically chaining to the page. The argument is that Lynx is often used by blind users and others who may want more control over the time it takes to read a page. Incidentally, there is no standards backing for this feature; probably because it puts unnecessarily large loads on the internet and servers, and because there are already mechanisms in HTTP to handle the simple redirection case. I can't say that I have ever seen a case where the pseudo HTTP Refresh header was ever really justified. From owner-lynx-dev@sig.net Thu Apr 15 02:15:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA01684 for ; Thu, 15 Apr 1999 02:15:06 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA25573; Thu, 15 Apr 1999 00:18:56 -0500 (CDT) From: David Woolley Message-Id: <199904140826.JAA11638@djwhome.demon.co.uk> Subject: Re: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Wed, 14 Apr 1999 09:26:03 +0100 (BST) In-Reply-To: <199904140331.XAA22421@chass.utoronto.ca> from "Philip Webb" at Apr 13, 99 11:31:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1275 Lines: 24 > esp with the pedantic nits'n'rants from people > who never seem to work on documentation themselves. I don't consider the
issue pedantic. I consider it the thin end of the wedge towards Lynx HTML becoming page description HTML just like most of the GUI HTML, rather than media independent language for describing the deep structure of the document so that the user and user agent can may intelligent choices on how to render it. I've done several makeovers of GUI web pages in the past to try and get rid of things like this++, but it is a thankless task as even if I achieve essentially the same layout with clean HTML, people just stick with what they believe "works". I accept that a lot of work goes into documentation, and coding and that I don't have the time, or the commitment to Lynx to do it, but once you start you have to understand that Lynx HTML documentation is in the special position that it has a duty to be an example of best practice, in the true spirit of HTML, as well as being easy to read, correct, complete, etc. ++ E.g. a contents list done as indents with   and
at the end of each item, rather than with
  • (with IE4, you can even suppress the bullets), and sub-headings done as body text with font and bold wrappers. From owner-lynx-dev@sig.net Thu Apr 15 03:32:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA03560 for ; Thu, 15 Apr 1999 03:32:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA05779; Thu, 15 Apr 1999 02:07:18 -0500 (CDT) From: Philip Webb Message-Id: <199904150510.BAA04687@chass.utoronto.ca> Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 01:10:19 -0400 (EDT) In-Reply-To: from "Vlad Harchev" at Apr 14, 99 01:44:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2327 Lines: 44 990414 Vlad Harchev wrote: > On Wed, 14 Apr 1999, Leonid Pauzner wrote: >> 14-Apr-99 03:24 Vlad Harchev wrote: >>> More brave approach: >>> Make ~/.lynxrc included by lynx.cfg >>> (it's syntax must be changed to one of lynx.cfg), >>> with a list of options it can contain in the 'include' line. >>> with LP's patch, lynx.cfg can be edited at runtime and reloaded -- snip -- >> Currently we have a compromise between a huge jar of options (lynx.cfg) >> for advanced user and a small menu-driven subset (we should not normally >> looks into .lynxrc at all, it is a machine generated file). >> It is not possible or useful to made all lynx.cfg options menu-driven, >> since that introduce more problems than it solves. > I don't mean that we should make ALL options of lynx.cfg menu-editable - > I meant options currently allowed in .lynxrc should be menu-editable - > so no (possible) change should be made to option menu generation, etc. >> .lynxrc has options with other names when in lynx.cfg, >> so we should add synonyms to provide compatibility, etc. > this is a main problem, but it can be solved. >> we should restrict most lynx.cfg options for .lynxrc > According to syntax I propose, allowed options are specified, not disallowed, > so the line that limit the allowed options for .lynxrc won't be very long. >> command line flags in between... > This can be solved. >>> In present state, users with paranoid sysadm were to live >>> with colors s/he specify. > for lynx compiled without lss, colors are specified in lynx.cfg. > Since it's not writable by user, each user have to use the colors > sysadm specified (same for viewers, keymaps...) > PS: And I don't insist on making .lynxrc to be included by lynx.cfg. i hesitate to join your erudite discussion, but there is a strong long-term case for the bravest choice: uniting lynx.cfg , .lynxrc/Options & -flags into 1 set of choices & moving security items & those without which Lynx won't start into userdefs.h + --configureflags . perhaps your current work is a step in that direction. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 15 03:34:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA03576 for ; Thu, 15 Apr 1999 03:34:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA06879; Thu, 15 Apr 1999 02:18:42 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 15 Apr 1999 11:01:58 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1906 Lines: 39 14-Apr-99 13:32 Vlad Harchev wrote: > On Wed, 14 Apr 1999, Leonid Pauzner wrote: >> Probably the exit from options menu may now utilize the power of SOURCE_CACHE, >> though it handles more parameters than HTdocument_settings_changed() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Leonid. >> > I found another bug: if there is something on the cache stack (say doc A > -current doc and doc B), and we go to 'O' and change something, only > appearance of 'A' is changed, the appearance of B is not changed - the cahced > version is used. IMO it will be better to uncache everything in the stack. > This is best tested with 'links are/not numbered' - since rendered versions > differ a lot. That was a very expensive solution before SOURCE_CACHE but now this can be done nicely by adding more parameters to the function above and avoid using of HTuncache_current_document() calls. Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. > If the bug I described is fixed, then all documents will return to their > normal (not source) representnation (or we have to keep a stack of modes of ^^^^^^^^^^^^^^^^^^^^ We already do that somehow in LYK_SOURCE - we trying to remember document owner and document charset to utilize them in source mode (parameters gotten for rendering HTML will unavailable in source mode until we store them somehow). Probably, a proper way will be to split out the HTParentAnchor data and HText data so the first will not be lost when we uncache the second. And source mode flag may now belongs to HTParentAnchor. So the mode will always WWW_PRESENT until the *document* has its own value overwise. > the documents somehow - or probably set the pointer to HText to NULL in the > cache, but marking whether it was 'source' view or not) > Best regards, > -Vlad From owner-lynx-dev@sig.net Thu Apr 15 03:51:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA03960 for ; Thu, 15 Apr 1999 03:51:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA08318; Thu, 15 Apr 1999 02:32:59 -0500 (CDT) Date: Thu, 15 Apr 1999 02:32:55 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net cc: mss@transas.com Subject: Re: lynx-dev Commenting... In-Reply-To: <19990414200549.A15422@mail.bcpl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 869 Lines: 24 On Wed, 14 Apr 1999, Webmaster Jim wrote: > Lynx can use the following as an author/owner tag: > > Or alternatively rev="owner". (Try also adding a title="some text" attribute, lynx does someting with with it. Try also giving a URL other than mailto: and see what happens.) But your example does not have a valid mailto URL. At least escape the spaces. I would also put the (full name) comment after the address, not before it, since that's the common form. Whether or not a given mailto URL works for a given user depends on whether the program configured as SYSTEM_MAIL / SYSTEM_MAIL_FLAGS understands the address. I assume that not all such programs are equal. To minimize the chance of breakage for *someone*, I would only use the most bare form, i.e. "mailto:jspath@bcpl.net". Klaus From owner-lynx-dev@sig.net Thu Apr 15 04:19:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA05599 for ; Thu, 15 Apr 1999 04:19:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA11361; Thu, 15 Apr 1999 03:06:17 -0500 (CDT) Date: Thu, 15 Apr 1999 01:06:13 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 975 Lines: 23 On Wed, 14 Apr 1999, Klaus Weide wrote: > - for 3), the underlying network problem has to be fixed. This seems > to be a problem mostly for users of 386 binaries. Maybe creators of > those packages can make further improvements (or maybe they are already > doing everything that makes sense). Maybe I missed it, but I haven't noticed this at all. The DOS version is inherently difficult to configure, but most of this has been partially automated by Alfredo Cole's program to setup DOSPPP and the batch file I include with the binary. I haven't looked at them lately, but I believe that there are at least two other efforts to make things easy for users, John Lewis's Bobcat386 package (available from the fdisk site) and the lynx_kit distribution (from rene.simplenet.com). I haven't noted reports of network problems from Win32 users. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Thu Apr 15 04:32:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA05799 for ; Thu, 15 Apr 1999 04:32:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA12436; Thu, 15 Apr 1999 03:19:19 -0500 (CDT) Date: Wed, 14 Apr 1999 14:12:25 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev PATCH [dev22]: source caching fixes (was: patch to fix PSRC mode with SOURCE_CACHE!=NONE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2360 Lines: 50 On Thu, 15 Apr 1999, Leonid Pauzner wrote: > 14-Apr-99 13:32 Vlad Harchev wrote: > > On Wed, 14 Apr 1999, Leonid Pauzner wrote: > > >> Probably the exit from options menu may now utilize the power of SOURCE_CACHE, > >> though it handles more parameters than HTdocument_settings_changed() > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> Leonid. > >> > > I found another bug: if there is something on the cache stack (say doc A > > -current doc and doc B), and we go to 'O' and change something, only > > appearance of 'A' is changed, the appearance of B is not changed - the cahced > > version is used. IMO it will be better to uncache everything in the stack. > > This is best tested with 'links are/not numbered' - since rendered versions > > differ a lot. > > That was a very expensive solution before SOURCE_CACHE > but now this can be done nicely by adding more parameters to the function > above and avoid using of HTuncache_current_document() calls. > Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. But the way it's implemented now should be considered incorrect. IMO, user should understand that changing options have a penalty and not to do this very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't make things messy/slow. IMO, we should implement the correct behaviour. > > > If the bug I described is fixed, then all documents will return to their > > normal (not source) representnation (or we have to keep a stack of modes of > ^^^^^^^^^^^^^^^^^^^^ > We already do that somehow in LYK_SOURCE - we trying to remember document > owner and document charset to utilize them in source mode (parameters gotten > for rendering HTML will unavailable in source mode until we store them > somehow). Probably, a proper way will be to split out the HTParentAnchor > data and HText data so the first will not be lost when we uncache the second. > And source mode flag may now belongs to HTParentAnchor. So the mode will > always WWW_PRESENT until the *document* has its own value overwise. > Yes, I think it can be done that way. > > the documents somehow - or probably set the pointer to HText to NULL in the > > cache, but marking whether it was 'source' view or not) > Best regards, -Vlad From owner-lynx-dev@sig.net Thu Apr 15 05:08:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA06619 for ; Thu, 15 Apr 1999 05:08:43 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA15594; Thu, 15 Apr 1999 03:58:17 -0500 (CDT) Date: Thu, 15 Apr 1999 03:58:14 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1608 Lines: 32 On Wed, 14 Apr 1999, Vlad Harchev wrote: > On Thu, 15 Apr 1999, Leonid Pauzner wrote: > > > 14-Apr-99 13:32 Vlad Harchev wrote: > > > I found another bug: if there is something on the cache stack (say doc A > > > -current doc and doc B), and we go to 'O' and change something, only > > > appearance of 'A' is changed, the appearance of B is not changed - the cahced > > > version is used. IMO it will be better to uncache everything in the stack. > > > This is best tested with 'links are/not numbered' - since rendered versions > > > differ a lot. > > > > That was a very expensive solution before SOURCE_CACHE > > but now this can be done nicely by adding more parameters to the function > > above and avoid using of HTuncache_current_document() calls. > > Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. > > But the way it's implemented now should be considered incorrect. IMO, user > should understand that changing options have a penalty and not to do this > very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't > make things messy/slow. IMO, we should implement the correct behaviour. I don't consider the current behavior as incorrect or a bug. It's just one of several possible behaviors. It's nice if you want to implement an alternative, but don't force it on everyone (including people with slow net connections), make it configurable. Re "user should understand that changing options have a penalty": maybe, but don't just go and increase the penalty for everyone more than necessary, without a chance of opting out. Klaus From owner-lynx-dev@sig.net Thu Apr 15 05:14:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA06638 for ; Thu, 15 Apr 1999 05:14:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA15017; Thu, 15 Apr 1999 03:50:50 -0500 (CDT) Date: Thu, 15 Apr 1999 03:50:46 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1595 Lines: 32 (only commenting on the uncaching-related part of this; I haven't read up on the rest of this discussion yet, and haven't looked at the recent code.) On Thu, 15 Apr 1999, Leonid Pauzner wrote: > 14-Apr-99 13:32 Vlad Harchev wrote: > > On Wed, 14 Apr 1999, Leonid Pauzner wrote: > > >> Probably the exit from options menu may now utilize the power of SOURCE_CACHE, > >> though it handles more parameters than HTdocument_settings_changed() > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I found another bug: if there is something on the cache stack (say doc A > > -current doc and doc B), and we go to 'O' and change something, only > > appearance of 'A' is changed, the appearance of B is not changed - the cahced > > version is used. IMO it will be better to uncache everything in the stack. > > This is best tested with 'links are/not numbered' - since rendered versions > > differ a lot. > > That was a very expensive solution before SOURCE_CACHE > but now this can be done nicely by adding more parameters to the function > above and avoid using of HTuncache_current_document() calls. > Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. If the behavior is changed from "only reload top document after relevant option change" to "reload all affected documents after option change", then please make this optional/configurable. The current behavior is maybe sometimes unexpected, but I generally prefer it over the alternative. I know where the ^R key is if I need it, and would like to avoid unnecessary reloading. Klaus From owner-lynx-dev@sig.net Thu Apr 15 05:22:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA06836 for ; Thu, 15 Apr 1999 05:22:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA15959; Thu, 15 Apr 1999 04:01:09 -0500 (CDT) Date: Thu, 15 Apr 1999 13:00:48 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... Message-ID: <19990415130048.A8641@transas.com> References: <19990414200549.A15422@mail.bcpl.net> <19990414181149.A13480@transas.com> <19990415020048.C932@transas.com> <19990414200549.A15422@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990414200549.A15422@mail.bcpl.net>; from Webmaster Jim on Wed, Apr 14, 1999 at 08:05:49PM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 268 Lines: 10 On Wed, Apr 14, 1999 at 08:05:49PM -0400, Webmaster Jim wrote: > On Thu, Apr 15, 1999 at 02:32:55AM -0500, Klaus Weide wrote: > Or alternatively rev="owner". Thanks. Where is this documented? -- Mike From owner-lynx-dev@sig.net Thu Apr 15 05:49:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07422 for ; Thu, 15 Apr 1999 05:49:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA29634; Thu, 15 Apr 1999 04:38:52 -0500 (CDT) Date: Thu, 15 Apr 1999 04:38:48 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net cc: Michael Sobolev Subject: Re: lynx-dev Commenting... In-Reply-To: <19990415130048.A8641@transas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 497 Lines: 17 On Thu, 15 Apr 1999, Michael Sobolev wrote: > On Wed, Apr 14, 1999 at 08:05:49PM -0400, Webmaster Jim wrote: > > > > On Thu, Apr 15, 1999 at 02:32:55AM -0500, Klaus Weide wrote: > > Or alternatively rev="owner". > > Thanks. Where is this documented? Quite possibly nowhere, except in source code comments. Please feel welcome to submit a bit of text to add the documentation, in the place where you feel it belongs. Klaus From owner-lynx-dev@sig.net Thu Apr 15 07:11:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA09203 for ; Thu, 15 Apr 1999 07:11:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05790; Thu, 15 Apr 1999 05:48:17 -0500 (CDT) Date: Thu, 15 Apr 1999 06:47:43 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904150647.AA22989@cas.org> Subject: Re: lynx-dev Commenting... In-Reply-To: Your message of Thu, 15 Apr 1999 02:00:48 +0400 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 781 Lines: 15 From: Michael Sobolev >certain values for LINK, and for META tgs. But the only author I found () >doe not work with Lynx: when I press c on my newly create page with author >meta information, I get the message no owner is defined. Anyone on the list gone thru and determined how much of HTML 4.0 lynx does currently support? It might be useful to have a checklist of HTML 4 features and the ones lynx currently supports and the ones it could support with contributions from someone... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Thu Apr 15 07:40:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA09905 for ; Thu, 15 Apr 1999 07:40:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07375; Thu, 15 Apr 1999 06:05:27 -0500 (CDT) From: Philip Webb Message-Id: <199904151105.HAA12513@chass.utoronto.ca> Subject: Re: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 07:05:25 -0400 (EDT) In-Reply-To: <199904140826.JAA11638@djwhome.demon.co.uk> from "David Woolley" at Apr 14, 99 09:26:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2858 Lines: 61 990414 David Woolley wrote: > I don't consider the
    issue pedantic. i would say it depends on the context: if it's a discussion of Internet trends & policies, no; if it's a small attempt to improve Lynx's porous & dilapidated docs, yes. > I consider it the thin end of the wedge towards Lynx HTML becoming > page-description HTML just like most of the GUI HTML, > rather than media-independent language for describing > the deep structure of the document > so that user and user agent can may intelligent choices how to render it. then you must object to the presence of
    in HTML at all: currently, it's a perfectly valid tag for all to use as they see fit. to that extent perhaps, HTML is not a deep-structure-only language. > I've done several makeovers of GUI web pages in the past > to try and get rid of things like a contents list > done as indents with   and
    at the end of each item, > rather than with
    • (with IE4, you can even suppress the bullets), > and sub-headings done as body text with font and bold wrappers. this is a case where there is a proper HTML alternative & use of
      is unnecessary & untidy; the rendered effect is the same. the problem people were having with my use of
      was that they were reading the patch instead of the rendered help-file. the latter should be neat & easy to read: i agree it's probably better to put long stretches of the help documentation in
      ...
      . > even if I achieve essentially the same layout with clean HTML, > people just stick with what they believe "works". yes, there's a vast crowd out there who have no idea what HTML rules are & even less interest, as it is no part of their job description. > I accept that a lot of work goes into documentation and coding > and that I don't have the time or the commitment to Lynx to do it, no problem: i have a bit of time to spare to try to improve things. > Lynx HTML documentation is in the special position > that it has a duty to be an example of best practice, > in the true spirit of HTML, > as well as being easy to read, correct, complete, etc. no, i don't accept that that is part of the Lynx project any more: we should try to use HTML & Internet terminology accurately -- KW's lengthy lectures on URLs & angels have their place -- , but i don't visit the club to fight idealistic battles & my impression is that most lynx-devers in practice don't either. we've been fighting for 16 years for a new trolley bus system & it took 24 years before trams were finally restored to Spadina Av: lynx-dev is just light relaxation ... -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 15 08:29:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11137 for ; Thu, 15 Apr 1999 08:29:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14726; Thu, 15 Apr 1999 07:07:58 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 15 Apr 1999 14:44:02 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2449 Lines: 48 15-Apr-99 03:50 Klaus Weide wrote: > On Thu, 15 Apr 1999, Leonid Pauzner wrote: >> 14-Apr-99 13:32 Vlad Harchev wrote: >> > On Wed, 14 Apr 1999, Leonid Pauzner wrote: >> >> >> Probably the exit from options menu may now utilize the power of SOURCE_CACHE, >> >> though it handles more parameters than HTdocument_settings_changed() >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > I found another bug: if there is something on the cache stack (say doc A >> > -current doc and doc B), and we go to 'O' and change something, only >> > appearance of 'A' is changed, the appearance of B is not changed - the cahced >> > version is used. IMO it will be better to uncache everything in the stack. >> > This is best tested with 'links are/not numbered' - since rendered versions >> > differ a lot. >> >> That was a very expensive solution before SOURCE_CACHE >> but now this can be done nicely by adding more parameters to the function >> above and avoid using of HTuncache_current_document() calls. >> Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. > If the behavior is changed from "only reload top document after > relevant option change" to "reload all affected documents after option > change", then please make this optional/configurable. The current > behavior is maybe sometimes unexpected, but I generally prefer it over > the alternative. I know where the ^R key is if I need it, and would > like to avoid unnecessary reloading. I think a new behaviour should be implemented for SOURCE_CACHE!=NONE (always "reload all affected documents" when we have sources locally - it would be strange otherwise, so no configure options required here). But with SOURCE_CACHE:NONE the old behaviour is preferrable by default to avoid shocking of experienced lynx users base (non default option may be implemented of cause). > Klaus 14-Apr-99 14:12 Vlad Harchev wrote: > But the way it's implemented now should be considered incorrect. IMO, user > should understand that changing options have a penalty and not to do this > very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't > make things messy/slow. IMO, we should implement the correct behaviour. Using of locally installed cached proxis is a good solution but they have a validation/no-cache/expired logic thich may be contrary to our needs (say, dynamically generated pages are always set to expired). From owner-lynx-dev@sig.net Thu Apr 15 08:38:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11364 for ; Thu, 15 Apr 1999 08:38:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA17387; Thu, 15 Apr 1999 07:25:06 -0500 (CDT) Date: Thu, 15 Apr 1999 08:25:08 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... In-Reply-To: <19990415130048.A8641@transas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 913 Lines: 27 On Thu, 15 Apr 1999, Michael Sobolev wrote: > On Wed, Apr 14, 1999 at 08:05:49PM -0400, Webmaster Jim wrote: > > > > On Thu, Apr 15, 1999 at 02:32:55AM -0500, Klaus Weide wrote: > > Or alternatively rev="owner". > > Thanks. Where is this documented? In the Lynx help files: URL Schemes Supported in Lynx http://sol.slcc.edu/lynx/current/lynx2-8-2/lynx_help/lynx_url_support.html mailto http://sol.slcc.edu/lynx/current/lynx2-8-2/lynx_help/lynx_url_support.html#mailto Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Thu Apr 15 08:45:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11397 for ; Thu, 15 Apr 1999 08:45:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16399; Thu, 15 Apr 1999 07:19:04 -0500 (CDT) From: Bela Lubkin Date: Thu, 15 Apr 1999 05:18:44 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev dev.22 lynx_dev.html Message-ID: <9904150518.aa12699@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1566 Lines: 51 Philip Webb wrote: > the problem people were having with my use of
      was > that they were reading the patch instead of the rendered help-file. > the latter should be neat & easy to read: i agree it's probably better > to put long stretches of the help documentation in
      ...
      . You only say this because you work in a certain screen width. In actual fact, artificially truncated lines look quite stupid and hard to read, especially when they are embedded in the middle of otherwise reasonably formatted text. You are imposing *your* idea of a good screen width on your readers. Actually, what looks even worse than short lines is a clumsy mix of alternating long and short lines, which is what your style produces when viewed on a display which is only a little shorter than your
      -terminated "lines". Is it your intention that Lynx documentation should look like this? > > Lynx HTML documentation is in the special position > > that it has a duty to be an example of best practice, > > in the true spirit of HTML, > > as well as being easy to read, correct, complete, etc. > > no, i don't accept that that is part of the Lynx project any more: > we should try to use HTML & Internet terminology accurately > -- KW's lengthy lectures on URLs & angels have their place -- , > but i don't visit the club to fight idealistic battles > & my impression is that most lynx-devers in practice don't either. This isn't just an idealistic battle. There's a reason, which has been explained more than once. Perhaps this browbeating will do it. >Bela< From owner-lynx-dev@sig.net Thu Apr 15 08:47:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11407 for ; Thu, 15 Apr 1999 08:47:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14734; Thu, 15 Apr 1999 07:08:05 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 15 Apr 1999 16:03:59 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev22 - SOURCE_CACHE!=NONE and partial display mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 21966 Lines: 612 14-Apr-99 13:38 Scott Bigham wrote: > On Wed, 14 Apr 1999, Leonid Pauzner wrote: >> Thanks for you fix! More problems found with SOURCE_CACHE!=NONE: >> the length of the re-rendered text may vary so the scrolling down >> is broken (especially nice when switching to source). >> This patch will fix it ("more" updated, "lines_in_file" inlined), > Eek! Surely this can be localized somewhat. Try the following patch > instead, applied on top of my previous dev22 patch: This letter mostly to Scott Bigham since work in progress. I have fixed diplay partial mode for source cache operations, unfortunately, when the document reloaded from cache the screen than became blank or corrupted due to a highlighted link. Probably a problem in mainloop() somethere near the point you mentioned abouve. (Try the reloading of lynx users guide to source mode and wait until the reloading finished without any key scrolling operations). So I sent my current resync against clean dev22 (only files GridText.c, LYMainLoop.c, HTFormat.[ch], LYglobalDefs.h and LYMain.c are affected): * Fix reload_read_cfg() to avoid persistent cookies mode changing at run time - LP * Fixes for SOURCE_CACHE!=NONE mode, trying to accomodate HTreparse_document() for mainloop() events: - fix switching to/from source mode when -prettysrc is in effect - VH & dsb. - fix case LYK_SOURCE - dsb - fix links numbering update - dsb - fix document length update - LP - add partial display mode for HTreparse_document() operations - LP (yes, I know this fix looks ugly, display partial staff should went from mainloop() to HT*Copy(), will be done later but how about corrupted screen?) diff -u ./gridtext.c ../gridtext.c --- ./gridtext.c Tue Apr 13 03:39:16 1999 +++ ../gridtext.c Thu Apr 15 13:50:32 1999 @@ -561,7 +561,7 @@ self->LastChar = '\0'; self->IgnoreExcess = FALSE; -#ifndef PSRC_TEST +#ifndef USE_PSRC if (HTOutputFormat == WWW_SOURCE) self->source = YES; else @@ -6186,14 +6186,15 @@ /* * This is more or less copied out of HTLoadFile(), except we don't - * get a content encoding. This may be overkill... + * get a content encoding. This may be overkill. -dsb */ if (HTMainText->node_anchor->content_type) { format = HTAtom_for(HTMainText->node_anchor->content_type); } else { format = HTFileFormat(HTMainText->source_cache_file, NULL, NULL); format = HTCharsetFormat(format, HTMainText->node_anchor, - UCLYhndl_HTFile_for_unspec); + UCLYhndl_for_unspec); + /* not UCLYhndl_HTFile_for_unspec - we are talking about remote documents... */ } CTRACE(tfp, " Content type is \"%s\"\n", format->name); @@ -6210,12 +6211,34 @@ FREE(source_cache_filename); return FALSE; } +#ifdef DISP_PARTIAL + display_partial = display_partial_flag; /* restore */ + Newline_partial = Newline; /* initialize */ + NumOfLines_partial = -1; /* initialize to -1 */ +#endif /* DISP_PARTIAL */ ret = HTParseFile(format, HTOutputFormat, HTMainText->node_anchor, fp, NULL); fclose(fp); +#ifdef DISP_PARTIAL + if (display_partial) { + /* + * Override Newline with a new value if user + * scrolled the document while downloading. + */ + if (Newline_partial != Newline + && NumOfLines_partial > 0) + Newline = Newline_partial; + + /* + * End of incremental rendering stage here. + */ + display_partial = FALSE; + } +#endif /* DISP_PARTIAL */ ok = (ret == HT_LOADED); - if (!ok) + if (!ok) { FREE(source_cache_filename); + } } if (LYCacheSource == SOURCE_CACHE_MEMORY && @@ -6233,8 +6256,29 @@ source_cache_chunk = HTMainText->source_cache_chunk; HTMainText->source_cache_chunk = NULL; +#ifdef DISP_PARTIAL + display_partial = display_partial_flag; /* restore */ + Newline_partial = Newline; /* initialize */ + NumOfLines_partial = -1; /* initialize to -1 */ +#endif /* DISP_PARTIAL */ ret = HTParseMem(format, HTOutputFormat, HTMainText->node_anchor, source_cache_chunk, NULL); +#ifdef DISP_PARTIAL + if (display_partial) { + /* + * Override Newline with a new value if user + * scrolled the document while downloading. + */ + if (Newline_partial != Newline + && NumOfLines_partial > 0) + Newline = Newline_partial; + + /* + * End of incremental rendering stage here. + */ + display_partial = FALSE; + } +#endif /* DISP_PARTIAL */ ok = (ret == HT_LOADED); if (!ok) { HTChunkFree(source_cache_chunk); @@ -6242,7 +6286,17 @@ } } + /* + * I have no idea what this does, but it seems to be necessary... -dsb + */ + LYUCPopAssumed(); + CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed")); + + if (ok) {/* fix few flags: */ + more = HText_canScrollDown(); /* the length may be changed */ + } + return ok; } diff -u ./htformat.c ../htformat.c --- ./htformat.c Tue Apr 13 03:39:16 1999 +++ ../htformat.c Thu Apr 15 13:21:22 1999 @@ -783,6 +783,7 @@ ** ** Return values: ** HT_LOADED All data sent. +** HT_INTERRUPTED Interruption after some data read. ** ** State of memory and target stream on return: ** always chunk unchanged, target stream still valid. @@ -794,6 +795,7 @@ HTStreamClass targetClass = *(sink->isa); int bytes = 0; CONST char *data = chunk->data; + int rv = HT_OK; HTReadProgress(0, 0); for (;;) { @@ -810,8 +812,18 @@ data += n; HTReadProgress(bytes, 0); HTDisplayPartial(); + + if (HTCheckForInterrupt()) { + _HTProgress (TRANSFER_INTERRUPTED); + if (bytes) { + rv = HT_INTERRUPTED; + } else { + rv = -1; + } + break; + } } - return HT_LOADED; + return rv; } #endif diff -u ./htformat.h ../htformat.h --- ./htformat.h Tue Apr 13 03:39:16 1999 +++ ../htformat.h Thu Apr 15 12:08:32 1999 @@ -325,10 +325,10 @@ #include /* -HTFileCopy: Copy a file to a stream +HTMemCopy: Copy a memory chunk to a stream This is used by the protocol engines to send data down a stream, typically one which - has been generated by HTStreamStack. It is currently called by HTParseFile + has been generated by HTStreamStack. It is currently called by HTParseMem */ extern int HTMemCopy PARAMS(( diff -u ./lyglobal.h ../lyglobal.h --- ./lyglobal.h Tue Apr 13 03:39:16 1999 +++ ../lyglobal.h Thu Apr 15 12:51:30 1999 @@ -271,6 +271,8 @@ extern int NumOfLines_partial; /* -//- "current" number of lines */ extern int partial_threshold; extern BOOLEAN debug_display_partial; /* show with MessageSecs delay */ +extern BOOLEAN display_partial_flag; /* permanent flag, not mutable */ +extern int Newline; /* original newline position, from mainloop() */ #endif extern char *form_post_data; /* User data for post form */ extern char *form_get_data; /* User data for get form */ diff -u ./lymainlo.c ../lymainlo.c --- ./lymainlo.c Tue Apr 13 03:39:16 1999 +++ ../lymainlo.c Thu Apr 15 13:26:56 1999 @@ -86,6 +86,10 @@ #ifdef DISP_PARTIAL PUBLIC int Newline_partial = 0; /* required for display_partial mode */ PUBLIC int NumOfLines_partial = -1; /* required for display_partial mode */ +PUBLIC BOOLEAN display_partial_flag = FALSE; +PUBLIC int Newline = 0; +#else +PRIVATE int Newline = 0; #endif PRIVATE document newdoc; @@ -234,8 +238,6 @@ int cmd = LYK_DO_NOTHING, real_cmd = LYK_DO_NOTHING; int getresult; int arrowup = FALSE, show_help = FALSE; - int lines_in_file = -1; - int Newline = 0; char prev_target[512]; char user_input_buffer[1024]; char *owner_address = NULL; /* Holds the responsible owner's address */ @@ -250,7 +252,7 @@ BOOLEAN rlink_allowed; BOOLEAN vi_keys_flag = vi_keys; BOOLEAN emacs_keys_flag = emacs_keys; - BOOLEAN LYRawMode_flag = LYRawMode; + BOOLEAN LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifndef NO_OPTION_MENU BOOLEAN LYSelectPopups_flag = LYSelectPopups; BOOLEAN verbose_img_flag = verbose_img; @@ -263,9 +265,6 @@ #endif BOOLEAN trace_mode_flag = FALSE; BOOLEAN forced_HTML_mode = LYforce_HTML_mode; -#ifdef DISP_PARTIAL - BOOLEAN display_partial_flag = display_partial; -#endif char cfile[128]; FILE *cfp; char *cp, *toolbar; @@ -312,6 +311,9 @@ user_input_buffer[(sizeof(user_input_buffer) - 1)] = '\0'; *prev_target = '\0'; *user_input_buffer = '\0'; +#ifdef DISP_PARTIAL + display_partial_flag = display_partial; /* permanent flag, not mutable */ +#endif StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); StrAllocCopy(CurrentNegoLanguage, (language ? @@ -561,8 +563,7 @@ * completed, but only if s/he did not mess screen up by * scrolling before... So fall down to old behavior here. */ - if (!LYCursesON || - (Newline_partial == 1 && strchr(newdoc.address, '#'))) + if (Newline_partial == 1 && strchr(newdoc.address, '#')) display_partial = FALSE; } #endif /* DISP_PARTIAL */ @@ -1260,7 +1261,7 @@ #ifdef SOURCE_CACHE /* * If the parse settings have changed since this HText was - * generated, we need to reparse and redraw it. + * generated, we need to reparse and redraw it. -dsb */ if (HTdocument_settings_changed()) { HTUserMsg(gettext("Reparsing document under current settings...")); @@ -1269,7 +1270,7 @@ else { /* * Urk. I have no idea how to recover from a failure here. - * At a guess, I'll try reloading. + * At a guess, I'll try reloading. -dsb */ cmd = LYK_RELOAD; goto new_cmd; @@ -1298,7 +1299,6 @@ */ more = HText_canScrollDown(); curdoc.line = Newline = HText_getTopOfScreen()+1; - lines_in_file = HText_getNumOfLines(); if (curdoc.title == NULL) { /* @@ -1358,6 +1358,15 @@ if (lynx_edit_mode && nlinks > 0 && !HTList_isEmpty(tagged)) showtags(tagged); #endif /* DIRED_SUPPORT */ +#ifdef SOURCE_CACHE + /* + * This information can get clobbered if we go to an internal + * page while viewing source. Normally it would be recreated + * by reloading the file; we have to do it ourselves. -dsb + */ + if (curdoc.link < 0 && nlinks > 0) + curdoc.link = 0; +#endif if (user_mode == NOVICE_MODE) noviceline(more); /* print help message */ refresh_screen = FALSE; @@ -1671,7 +1680,6 @@ links[curdoc.link+1].form->name) != 0)))))) { HText_ExpandTextarea (&links[curdoc.link], 1); - lines_in_file = HText_getNumOfLines(); if (links[curdoc.link].ly < display_lines) { refresh_screen = TRUE; @@ -2110,6 +2118,25 @@ #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; + /* + * These normally get cleaned up after getfile() returns; + * since we're not calling getfile(), we have to clean them + * up ourselves. -dsb + */ + HTOutputFormat = WWW_PRESENT; +#ifdef USE_PSRC + if (psrc_view) + HTMark_asSource(); + psrc_view = FALSE; +#endif + /* + * Set the remaining document elements. + */ + if (ownerS_address != NULL) { + if (!HText_getOwner()) + HText_setMainTextOwner(ownerS_address); + FREE(ownerS_address); + } break; } #endif @@ -2512,7 +2539,7 @@ case LYK_END: if (more) { - Newline = lines_in_file - display_lines + 3; /* go to end of file */ + Newline = HText_getNumOfLines() - display_lines + 3; /* go to end of file */ arrowup = TRUE; /* position on last link */ } else { cmd = LYK_NEXT_PAGE; @@ -4037,7 +4064,7 @@ CurrentCharSet_flag != current_char_set || CurrentAssumeCharSet_flag != UCLYhndl_for_unspec || verbose_img_flag != verbose_img || - LYRawMode_flag != LYRawMode || + LYUseDefaultRawMode_flag != LYUseDefaultRawMode || LYSelectPopups_flag != LYSelectPopups || ((strcmp(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")) || @@ -4113,7 +4140,7 @@ CurrentAssumeCharSet_flag = UCLYhndl_for_unspec; show_dotfiles_flag = show_dotfiles; verbose_img_flag = verbose_img; - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; LYSelectPopups_flag = LYSelectPopups; StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); @@ -4656,7 +4683,7 @@ */ if (strcmp((curdoc.title ? curdoc.title : ""), SHOWINFO_TITLE)) { - if (showinfo(&curdoc, lines_in_file, + if (showinfo(&curdoc, HText_getNumOfLines(), &newdoc, owner_address) < 0) break; StrAllocCopy(newdoc.title, SHOWINFO_TITLE); @@ -4698,8 +4725,6 @@ n = HText_ExtEditForm (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st trailing blank line in @@ -4731,7 +4756,6 @@ HText_ExpandTextarea (&links[curdoc.link], TEXTAREA_EXPAND_SIZE); - lines_in_file = HText_getNumOfLines(); refresh_screen = TRUE; } else { @@ -4749,8 +4773,6 @@ n = HText_InsertFile (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st line following the text @@ -4788,7 +4810,7 @@ PRINT_OPTIONS_TITLE)) { if (print_options(&newdoc.address, - &curdoc.address, lines_in_file) < 0) + &curdoc.address, HText_getNumOfLines()) < 0) break; StrAllocCopy(newdoc.title, PRINT_OPTIONS_TITLE); FREE(newdoc.post_data); @@ -5626,7 +5648,7 @@ LYUseDefaultRawMode = !LYUseDefaultRawMode; HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; diff -u ./lymain.c ../lymain.c --- ./lymain.c Tue Apr 13 03:39:16 1999 +++ ../lymain.c Wed Apr 14 19:37:42 1999 @@ -1257,6 +1257,14 @@ StrAllocCopy(UCAssume_MIMEcharset, LYCharSet_UC[UCLYhndl_for_unspec].MIMEname); + /* + * Make sure we have the edit map declared. - FM + */ + if (!LYEditmapDeclared()) { + fprintf(stderr, gettext("\nLynx edit map not declared.\n\n")); + exit(-1); + } + #if defined(USE_HASH) /* * If no alternate lynx-style file was specified on @@ -1304,15 +1312,7 @@ fclose(fp); style_readFromFile(lynx_lss_file); } -#endif - - /* - * Make sure we have the edit map declared. - FM - */ - if (!LYEditmapDeclared()) { - fprintf(stderr, gettext("\nLynx edit map not declared.\n\n")); - exit(-1); - } +#endif /* USE_HASH */ #if USE_COLOR_TABLE /* @@ -1584,6 +1584,13 @@ if (dump_output_immediately) LYCacheSource = SOURCE_CACHE_NONE; #endif +#ifdef DISP_PARTIAL + /* + * Disable partial mode if not interactive. + */ + if (dump_output_immediately) + display_partial = FALSE; +#endif #ifdef VMS set_vms_keys(); @@ -1782,7 +1789,8 @@ * mode. Instead of calling cleanup() here, let's only call * this one. - BJP */ - LYStoreCookies(LYCookieFile); + if (persistent_cookies) + LYStoreCookies(LYCookieFile); #endif /* EXP_PERSISTENT_COOKIES */ exit_immediately(status); } else { @@ -1832,6 +1840,7 @@ HTRegisterProtocol(&LYLynxCookies); } +#ifndef NO_CONFIG_INFO /* * Some staff to reload lynx.cfg without restarting new lynx session, * also load options menu items and command-line options @@ -1842,10 +1851,17 @@ */ PUBLIC void reload_read_cfg NOARGS { - if (!LYRestricted) { + if (LYRestricted) return; /* for sure */ + + /* save .lynxrc file in case we change something from Options Menu */ + if (!save_rc()) return; /* can not write the very own file :( */ - /* save .lynxrc file in case we change something from Options Menu */ - if (!save_rc()) return; + { + /* set few safe flags: */ +#ifdef PERSISTENT_COOKIES + BOOLEAN persistent_cookies_flag = persistent_cookies; + char * LYCookieFile_flag = LYCookieFile; +#endif /* * Process the configuration file. @@ -1862,13 +1878,13 @@ /* but other things may be lost: */ /* - * Process any command line arguments not already handled. - FM + * Process any command line arguments not already handled. */ /* Not implemented yet here */ /* * Process any stdin-derived arguments for a lone "-" which we've - * loaded into LYStdinArgs. - FM + * loaded into LYStdinArgs. */ /* Not implemented yet here */ @@ -1877,11 +1893,23 @@ */ /* Not implemented yet here, * a major problem: file paths - * like lynx_temp_space, LYCookieFile etc. + * like lynx_save_space, LYCookieFile etc. */ +#ifdef PERSISTENT_COOKIES + /* restore old settings */ + if (persistent_cookies != persistent_cookies_flag) { + persistent_cookies = persistent_cookies_flag; + HTAlert(gettext("persistent cookies state will be changed in next session only.")); + } + if (strcmp(LYCookieFile, LYCookieFile_flag)) { + StrAllocCopy(LYCookieFile, LYCookieFile_flag); + CTRACE(tfp, "cookies file can be changed in next session only, restored.\n") + } +#endif } } +#endif /* !NO_CONFIG_INFO */ /* There are different ways of setting arguments on the command line, and @@ -1913,13 +1941,13 @@ #ifdef PARSE_DEBUG #define ParseData BOOLEAN *set_value; int *int_value; char **str_value; ParseFunc fun_value #define PARSE_SET(n,t,v,h) {n,t, v, 0, 0, 0, h} -#define PARSE_INT(n,t,v,h) {n,t, 0, &v, 0, 0, h} +#define PARSE_INT(n,t,v,h) {n,t, 0, v, 0, 0, h} #define PARSE_STR(n,t,v,h) {n,t, 0, 0, v, 0, h} #define PARSE_FUN(n,t,v,h) {n,t, 0, 0, 0, v, h} #else #define ParseData long value #define PARSE_SET(n,t,v,h) {n,t, (long) (v), h} -#define PARSE_INT(n,t,v,h) {n,t, (long)&(v), h} +#define PARSE_INT(n,t,v,h) {n,t, (long) (v), h} #define PARSE_STR(n,t,v,h) {n,t, (long) (v), h} #define PARSE_FUN(n,t,v,h) {n,t, (long) (v), h} #endif @@ -2751,7 +2779,7 @@ "toggles inclusion of ISMAP links when client-side\nMAPs are present" ), PARSE_INT( - "link", NEED_INT_ARG, ccount, + "link", NEED_INT_ARG, &ccount, "=NUMBER\nstarting count for lnk#.dat files produced by -crawl" ), PARSE_SET( @@ -2842,7 +2870,7 @@ "toggles display partial pages while downloading" ), PARSE_INT( - "partial_thres", IGNORE_ARG|INT_ARG, partial_threshold, + "partial_thres", NEED_INT_ARG, &partial_threshold, "[=NUMBER]\nnumber of lines to render before repainting display\n\ with partial-display logic" ), @@ -2862,7 +2890,7 @@ PARSE_SET( "preparsed", SET_ARG, &LYPreparsedSource, "show parsed text/html with -source and in source view\n\ - to visualize how lynx behaves with invalid HTML" +to visualize how lynx behaves with invalid HTML" ), #ifdef USE_PSRC PARSE_SET( From owner-lynx-dev@sig.net Thu Apr 15 08:55:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11641 for ; Thu, 15 Apr 1999 08:55:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA17887; Thu, 15 Apr 1999 07:27:50 -0500 (CDT) Date: Thu, 15 Apr 1999 08:25:56 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Re: Commenting... Message-ID: <19990415082556.A17736@mail.bcpl.net> References: <19990414200549.A15422@mail.bcpl.net> <19990414181149.A13480@transas.com> <19990415020048.C932@transas.com> <19990414200549.A15422@mail.bcpl.net> <19990415130048.A8641@transas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990415130048.A8641@transas.com>; from Michael Sobolev on Thu, Apr 15, 1999 at 01:00:48PM +0400 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1345 Lines: 31 On Thu, Apr 15, 1999 at 01:00:48PM +0400, Michael Sobolev wrote: > On Wed, Apr 14, 1999 at 08:05:49PM -0400, Webmaster Jim wrote: > > > > On Thu, Apr 15, 1999 at 02:32:55AM -0500, Klaus Weide wrote: > > Or alternatively rev="owner". > > Thanks. Where is this documented? It's in the HTML 3.2 specs, but seems to have vanished from 4.0. All the pages that have this are "obsolete" I guess, but since it's unlikely this function will be removed from Lynx, I still include it in my pages. ==== http://www.w3.org/TR/REC-html32.html HTML 3.2 Reference Specification (p16 of 130) rev This defines a reverse relationship. A link from document A to document B with REV=relation expresses the same relationship as a link from B to A with REL=relation. REV=made is sometimes used to identify the document author, either the author's email address with a mailto URL, or a link to the author's home page. ------ Marvin the Paranoid Android says: You're not going to appreciate me for it are you? Not that that matters to me. Nothing matters really. From owner-lynx-dev@sig.net Thu Apr 15 09:27:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA12483 for ; Thu, 15 Apr 1999 09:27:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28920; Thu, 15 Apr 1999 08:15:56 -0500 (CDT) Date: Thu, 15 Apr 1999 09:16:45 +0430 (IRST) From: Vahid Sanei To: lynx-dev@sig.net Subject: lynx-dev Problem with lynx 2.8.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 617 Lines: 19 Hi there, I recently downloaded and installed lynx 2.8.1 in my home directory, but I have a problem with it. When I read HTML files by lynx 2.8.1, it shows links and hypertexts in reverse mode instead of showing them in color and changing terminal settings has not any effect on it, but when I use my previous lynx 2.6 hypertexts apear in color. How can I overcome this problem. I would appreciate receiving your comments. - OS= Linux 2.0.3 - Terminal type= vt100 Best regards Vahid Sanei Institute of Biochemistry and Biophysics, Tehran University, Tehran, Iran. ######################################### From owner-lynx-dev@sig.net Thu Apr 15 09:32:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA12701 for ; Thu, 15 Apr 1999 09:32:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28153; Thu, 15 Apr 1999 08:13:14 -0500 (CDT) Date: Sun, 11 Apr 1999 17:10:08 +0200 From: Dirk Foersterling To: lynx-dev@sig.net Subject: lynx-dev Lynx 2.8.1rel.2 - HTTP bug? Message-ID: <19990411171008.A576@infinity.milliByte.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i X-Operating-System: Linux 2.0.36 i586 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 893 Lines: 23 Hi, I found lynx (2.7.x, 2.8.0 and 2.8.1) sending incomplete HTTP requests. For example retreiving the URL http://lynx.browser.org/ with lynx (_not_using_any_proxy_) results in an error message (Bad Request). I tracked it down and found lynx forming a request beginning with GET HTTP/1.0 Host: lynx.browser.org which seems to be incorrect, because of the empty URI/path after GET. A proxy usually inserts the missing "/" here, so the problem only shows up in direct lynx/httpd communication. I tried this on several http server software including Apache-1.3.6 and MS-IIS 4, to verify that not a specific server version is picky about empty URIs. -dirk -- D i r k F "o r s t e r l i n g milliByte@DeathsDoor.com ******** http://www.DeathsDoor.com/milliByte/ ------------- ISDN - [I]st [S]owas [D]enn [N]oetig? From owner-lynx-dev@sig.net Thu Apr 15 09:34:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA12736 for ; Thu, 15 Apr 1999 09:34:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28388; Thu, 15 Apr 1999 08:14:11 -0500 (CDT) Date: Thu, 15 Apr 1999 00:49:13 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: Gene Collins Cc: lynx-dev@sig.net Subject: Re: lynx-dev need help with lynx key mapping In-Reply-To: <3.0.3.32.19990414085025.007dea00@collins.mail.iastate.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1374 Lines: 30 I don't think this can be done, but there may be other solutions. If you are running a precompiled version obtained from www.fdisk.com, it was compiled with PDCurses, which doesn't distinguish the vaules of the numberpad keys from the other keys of similar value. I seem to remember some solutions posted to the BLIND-L list. If you subscribe to that list, try posting your question there. Also, you might try upgrading to a newer version. I believe that 2.8.2rel2 is at www.fdisk.com. A recent development version compiled by Hiroyuki Senshu is available, but you will need to look carefully for the English files among the Japanese. "ftp://crab.it.osha.sut.ac.jp/pub/Win32/develope/senshu/Lynx" Doug On Wed, 14 Apr 1999, Gene Collins wrote: > Hello. I'm running Lynx 2.8.1dev.16 under Windows 95. I am a totally > blind person using the ASAP screen reader. > > The problem is that the screen reader wants to use the numeric key pad for > it's command keys. Since Lynx is a Windows console app, conagent.exe takes > over the keyboard interrupt, and passes all of my screen reader commands on > to Lynx, instead of allowing the screen reader to capture them as would > normally be the case. I would like to map the numeric key pad so that all __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Thu Apr 15 09:44:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA13014 for ; Thu, 15 Apr 1999 09:44:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA03961; Thu, 15 Apr 1999 08:32:52 -0500 (CDT) Date: Wed, 14 Apr 1999 15:22:06 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... In-Reply-To: <9904150647.AA22989@cas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1815 Lines: 39 On Thu, 15 Apr 1999, Larry W. Virden wrote: > From: Michael Sobolev > >certain values for LINK, and for META tgs. But the only author I found () > >doe not work with Lynx: when I press c on my newly create page with author > >meta information, I get the message no owner is defined. > > > Anyone on the list gone thru and determined how much of HTML 4.0 lynx does > currently support? It might be useful to have a checklist of HTML 4 features > and the ones lynx currently supports and the ones it could support with > contributions from someone... Lynx doesn't support core attrs (see SGML definition of HTML) that deal with script events - there is no html tag, the core attrs of which lynx supports fully. But it doesn't hurt since there is no JS support yet. A lot of attrs whose value is href are not supported - span.href, div.href, {img,frame,iframe}.longdesc , {q,blockquote,ins,del,}.cite - they are especially useful in PSRC mode - you can browse those hrefs. May be it will be useful if lynx support them - ie add those hrefs to the rendered version with special notes. img.name is not supported (as I understand, it's the same as 'id') A lot of attributes of tags concerning tables are not supported - like {table,td}.background (it's href of the image - these attr are absent in HTML 4.0 spec, but are supported at least by IE, ad may be by NS). BTW, I can add the attrs whose value is URL to the HTMLDTD.[ch] - IMO they are useful when in PSRC mode. > -- > Larry W. Virden > <*> O- "No one is what he seems." > Unless explicitly stated to the contrary, nothing in this posting should > be construed as representing my employer's opinions. > Best regards, -Vlad From owner-lynx-dev@sig.net Thu Apr 15 09:54:16 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA13314 for ; Thu, 15 Apr 1999 09:54:14 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA05153; Thu, 15 Apr 1999 08:36:49 -0500 (CDT) Date: Thu, 15 Apr 1999 17:35:26 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Commenting... Message-ID: <19990415173526.A14035@transas.com> References: <19990415130048.A8641@transas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Ismael Cordeiro on Thu, Apr 15, 1999 at 08:25:08AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1321 Lines: 32 On Thu, Apr 15, 1999 at 08:25:08AM -0400, Ismael Cordeiro wrote: > > Thanks. Where is this documented? > > In the Lynx help files: [ snip ] > mailto > http://sol.slcc.edu/lynx/current/lynx2-8-2/lynx_help/lynx_url_support.html#mailto Thank you. The page you specified contains an example of how this could be done. What I was looking for was: At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current document if the author of the document has specified ownership (which is defined by the LINK element where attribute ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ REL has value either `made' or `owner'). If no ownership is specified then comments ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ are disabled. Certain links called mailto: links will also allow you to send mail to other people. Using the mail features within Lynx is straightforward. (The underlined is what I wanted to see. :) Finally I found that the documentation is incomplete. :) In Lynx_users_guide.html#Banners I found the complete list of expected values for REL attribute of the LINK element. Among them I could find neither `made' nor `owner'. Please take it as a plain fact. :) -- Mike From owner-lynx-dev@sig.net Thu Apr 15 10:06:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA13626 for ; Thu, 15 Apr 1999 10:06:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA08604; Thu, 15 Apr 1999 08:46:57 -0500 (CDT) Date: Thu, 15 Apr 1999 17:41:44 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Re: Commenting... Message-ID: <19990415174144.B14035@transas.com> References: <19990414200549.A15422@mail.bcpl.net> <19990414181149.A13480@transas.com> <19990415020048.C932@transas.com> <19990414200549.A15422@mail.bcpl.net> <19990415130048.A8641@transas.com> <19990415082556.A17736@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990415082556.A17736@mail.bcpl.net>; from Webmaster Jim on Thu, Apr 15, 1999 at 08:25:56AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 923 Lines: 19 On Thu, Apr 15, 1999 at 08:25:56AM -0400, Webmaster Jim wrote: > It's in the HTML 3.2 specs, but seems to have vanished from 4.0. All the > pages that have this are "obsolete" I guess, but since it's unlikely > this function will be removed from Lynx, I still include it in my pages. Why do you think so? :) > rev > This defines a reverse relationship. A link from document A to > document B with REV=relation expresses the same relationship as > a link from B to A with REL=relation. REV=made is sometimes > used to identify the document author, either the author's email > address with a mailto URL, or a link to the author's home page. Yes, I found it (after checking the source of HTML.c where it says about 3.0 and 3.2). But this phrase states that it's `sometimes used' and this value is not included in the list of the `proposed relationship values'. -- Mike From owner-lynx-dev@sig.net Thu Apr 15 10:07:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA13636 for ; Thu, 15 Apr 1999 10:07:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA11195; Thu, 15 Apr 1999 08:54:25 -0500 (CDT) Message-Id: <3.0.3.32.19990415085409.0081b100@collins.mail.iastate.edu> X-Sender: collins@collins.mail.iastate.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 15 Apr 1999 08:54:09 -0500 To: lynx-dev@sig.net From: Gene Collins Subject: Re: lynx-dev need help with lynx key mapping In-Reply-To: References: <3.0.3.32.19990414085025.007dea00@collins.mail.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1499 Lines: 37 Thanks Doug, I'll give your suggestions a try. Gene At 12:49 AM 4/15/99 -0700, you wrote: >I don't think this can be done, but there may be other solutions. If >you are running a precompiled version obtained from www.fdisk.com, it >was compiled with PDCurses, which doesn't distinguish the vaules of >the numberpad keys from the other keys of similar value. I seem to >remember some solutions posted to the BLIND-L list. If you subscribe >to that list, try posting your question there. Also, you might >try upgrading to a newer version. I believe that 2.8.2rel2 is at >www.fdisk.com. A recent development version compiled by Hiroyuki >Senshu is available, but you will need to look carefully for the >English files among the Japanese. > >"ftp://crab.it.osha.sut.ac.jp/pub/Win32/develope/senshu/Lynx" > Doug > >On Wed, 14 Apr 1999, Gene Collins wrote: > >> Hello. I'm running Lynx 2.8.1dev.16 under Windows 95. I am a totally >> blind person using the ASAP screen reader. >> >> The problem is that the screen reader wants to use the numeric key pad for >> it's command keys. Since Lynx is a Windows console app, conagent.exe takes >> over the keyboard interrupt, and passes all of my screen reader commands on >> to Lynx, instead of allowing the screen reader to capture them as would >> normally be the case. I would like to map the numeric key pad so that all > >__ >Doug Kaufman >Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu > > From owner-lynx-dev@sig.net Thu Apr 15 10:08:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA13822 for ; Thu, 15 Apr 1999 10:08:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27930; Thu, 15 Apr 1999 08:12:31 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 15 Apr 1999 17:07:07 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev Re: dev22 - SOURCE_CACHE!=NONE and partial display mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 18323 Lines: 504 15-Apr-99 16:03 I wrote: > This letter mostly to Scott Bigham since work in progress. > I have fixed diplay partial mode for source cache operations, > unfortunately, when the document reloaded from cache > the screen than became blank or corrupted due to a highlighted link. > Probably a problem in mainloop() somethere near the point you mentioned abouve. > (Try the reloading of lynx users guide to source mode and wait until > the reloading finished without any key scrolling operations). > So I sent my current resync against clean dev22 (only files GridText.c, > LYMainLoop.c, HTFormat.[ch], LYglobalDefs.h and LYMain.c are affected): > * Fixes for SOURCE_CACHE!=NONE mode, trying to accomodate HTreparse_document() > for mainloop() events: > - fix switching to/from source mode when -prettysrc is in effect - VH & dsb. > - fix case LYK_SOURCE - dsb > - fix links numbering update - dsb > - fix document length update - LP > - add partial display mode for HTreparse_document() operations - LP > (yes, I know this fix looks ugly, display partial staff should went > from mainloop() to HT*Copy(), will be done later > but how about corrupted screen?) Now a better fix for display partial mode - more clean and should be used for dev23 patch integration series. LYMain.c changes excluded. More LYMainLoop.c and GridText.c changes welcome. diff -u ./gridtext.c ../gridtext.c --- ./gridtext.c Tue Apr 13 03:39:16 1999 +++ ../gridtext.c Thu Apr 15 16:27:52 1999 @@ -6210,12 +6211,17 @@ FREE(source_cache_filename); return FALSE; } +#ifdef DISP_PARTIAL + display_partial = display_partial_flag; /* restore */ + Newline_partial = Newline; /* initialize */ +#endif ret = HTParseFile(format, HTOutputFormat, HTMainText->node_anchor, fp, NULL); fclose(fp); ok = (ret == HT_LOADED); - if (!ok) + if (!ok) { FREE(source_cache_filename); + } } if (LYCacheSource == SOURCE_CACHE_MEMORY && @@ -6233,6 +6239,10 @@ source_cache_chunk = HTMainText->source_cache_chunk; HTMainText->source_cache_chunk = NULL; +#ifdef DISP_PARTIAL + display_partial = display_partial_flag; /* restore */ + Newline_partial = Newline; /* initialize */ +#endif ret = HTParseMem(format, HTOutputFormat, HTMainText->node_anchor, source_cache_chunk, NULL); ok = (ret == HT_LOADED); diff -u ./htfile.c ../htfile.c --- ./htfile.c Tue Apr 13 02:39:16 1999 +++ ../htfile.c Thu Apr 15 16:11:20 1999 @@ -522,6 +522,7 @@ #endif /* LY_FIND_LEAKS */ extern void HTDisplayPartial NOARGS; +extern void HTFinishDisplayPartial NOARGS; /* Send README file. ** ----------------- @@ -1822,6 +1823,7 @@ ABORT_TARGET; } } + HTFinishDisplayPartial(); return status; /* document loaded, maybe partial */ } diff -u ./htformat.c ../htformat.c --- ./htformat.c Tue Apr 13 03:39:16 1999 +++ ../htformat.c Thu Apr 15 16:23:02 1999 @@ -528,6 +528,30 @@ #endif /* DISP_PARTIAL */ } +/* Put this as early as possible, OK just after HTDisplayPartial() */ +PUBLIC void HTFinishDisplayPartial NOARGS +{ +#ifdef DISP_PARTIAL + if (display_partial) { + /* + * Override Newline with a new value if user + * scrolled the document while downloading. + */ + if (Newline_partial != Newline + && NumOfLines_partial > 0) + Newline = Newline_partial; + } + + /* + * End of incremental rendering stage here. + */ + display_partial = FALSE; + NumOfLines_partial = -1; /* initialize to -1 */ + /* -1 restrict HTDisplayPartial() */ + /* until HText_new() start next HTMainText */ + /* and set the flag to 0 */ +#endif /* DISP_PARTIAL */ +} /* Push data from a socket down a stream ** ------------------------------------- @@ -697,6 +721,7 @@ rv = HT_LOADED; finished: + HTFinishDisplayPartial(); return(rv); } @@ -768,6 +793,7 @@ } } /* next bufferload */ + HTFinishDisplayPartial(); return rv; } @@ -783,6 +809,7 @@ ** ** Return values: ** HT_LOADED All data sent. +** HT_INTERRUPTED Interruption after some data read. ** ** State of memory and target stream on return: ** always chunk unchanged, target stream still valid. @@ -794,6 +821,7 @@ HTStreamClass targetClass = *(sink->isa); int bytes = 0; CONST char *data = chunk->data; + int rv = HT_OK; HTReadProgress(0, 0); for (;;) { @@ -810,8 +838,20 @@ data += n; HTReadProgress(bytes, 0); HTDisplayPartial(); + + if (HTCheckForInterrupt()) { + _HTProgress (TRANSFER_INTERRUPTED); + if (bytes) { + rv = HT_INTERRUPTED; + } else { + rv = -1; + } + break; + } } - return HT_LOADED; + + HTFinishDisplayPartial(); + return rv; } #endif @@ -891,6 +931,7 @@ } } /* next bufferload */ + HTFinishDisplayPartial(); return rv; } #endif /* USE_ZLIB */ diff -u ./lyglobal.h ../lyglobal.h --- ./lyglobal.h Tue Apr 13 03:39:16 1999 +++ ../lyglobal.h Thu Apr 15 12:51:30 1999 @@ -271,6 +271,8 @@ extern int NumOfLines_partial; /* -//- "current" number of lines */ extern int partial_threshold; extern BOOLEAN debug_display_partial; /* show with MessageSecs delay */ +extern BOOLEAN display_partial_flag; /* permanent flag, not mutable */ +extern int Newline; /* original newline position, from mainloop() */ #endif extern char *form_post_data; /* User data for post form */ extern char *form_get_data; /* User data for get form */ diff -u ./lyhistor.c ../lyhistor.c --- ./lyhistor.c Tue Apr 13 22:21:30 1999 +++ ../lyhistor.c Thu Apr 15 15:43:46 1999 @@ -335,7 +335,6 @@ #ifdef DISP_PARTIAL /* assume we pop the 'doc' to show it soon... */ Newline_partial = doc->line; /* reinitialize */ - NumOfLines_partial = -1; /* initialize to -1 */ #endif /* DISP_PARTIAL */ CTRACE(tfp, "LYpop[%d]: address:%s\n title:%s\n", nhist, doc->address, doc->title); @@ -365,7 +364,6 @@ #ifdef DISP_PARTIAL /* assume we pop the 'doc' to show it soon... */ Newline_partial = doc->line; /* reinitialize */ - NumOfLines_partial = -1; /* initialize to -1 */ #endif /* DISP_PARTIAL */ } } diff -u ./lymain.c ../lymain.c --- ./lymain.c Tue Apr 13 03:39:16 1999 +++ ../lymain.c Wed Apr 14 19:37:42 1999 @@ -1584,6 +1584,13 @@ if (dump_output_immediately) LYCacheSource = SOURCE_CACHE_NONE; #endif +#ifdef DISP_PARTIAL + /* + * Disable partial mode if not interactive. + */ + if (dump_output_immediately) + display_partial = FALSE; +#endif #ifdef VMS set_vms_keys(); diff -u ./lymainlo.c ../lymainlo.c --- ./lymainlo.c Tue Apr 13 03:39:16 1999 +++ ../lymainlo.c Thu Apr 15 16:38:34 1999 @@ -85,7 +85,11 @@ #ifdef DISP_PARTIAL PUBLIC int Newline_partial = 0; /* required for display_partial mode */ -PUBLIC int NumOfLines_partial = -1; /* required for display_partial mode */ +PUBLIC int NumOfLines_partial = -1; /* initialize to -1 the very first time */ +PUBLIC BOOLEAN display_partial_flag = FALSE; +PUBLIC int Newline = 0; +#else +PRIVATE int Newline = 0; #endif PRIVATE document newdoc; @@ -234,8 +238,6 @@ int cmd = LYK_DO_NOTHING, real_cmd = LYK_DO_NOTHING; int getresult; int arrowup = FALSE, show_help = FALSE; - int lines_in_file = -1; - int Newline = 0; char prev_target[512]; char user_input_buffer[1024]; char *owner_address = NULL; /* Holds the responsible owner's address */ @@ -250,7 +252,7 @@ BOOLEAN rlink_allowed; BOOLEAN vi_keys_flag = vi_keys; BOOLEAN emacs_keys_flag = emacs_keys; - BOOLEAN LYRawMode_flag = LYRawMode; + BOOLEAN LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifndef NO_OPTION_MENU BOOLEAN LYSelectPopups_flag = LYSelectPopups; BOOLEAN verbose_img_flag = verbose_img; @@ -263,9 +265,6 @@ #endif BOOLEAN trace_mode_flag = FALSE; BOOLEAN forced_HTML_mode = LYforce_HTML_mode; -#ifdef DISP_PARTIAL - BOOLEAN display_partial_flag = display_partial; -#endif char cfile[128]; FILE *cfp; char *cp, *toolbar; @@ -312,6 +311,9 @@ user_input_buffer[(sizeof(user_input_buffer) - 1)] = '\0'; *prev_target = '\0'; *user_input_buffer = '\0'; +#ifdef DISP_PARTIAL + display_partial_flag = display_partial; /* permanent flag, not mutable */ +#endif StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); StrAllocCopy(CurrentNegoLanguage, (language ? @@ -544,14 +546,10 @@ LYPermitURL = TRUE; } + Newline = newdoc.line; /* bypass for partial mode */ #ifdef DISP_PARTIAL - display_partial = display_partial_flag; /* restore */ - Newline_partial = newdoc.line; /* initialize */ - NumOfLines_partial = -1; /* initialize to -1 */ - /* -1 restrict HTDisplayPartial() */ - /* until HText_new() start new HTMainText */ - /* and set the flag to 0 */ - if (display_partial) { + display_partial = display_partial_flag; /* restore */ + Newline_partial = Newline; /* * Disable display_partial if requested URL has #fragment * and we are not popped from the history stack @@ -561,10 +559,8 @@ * completed, but only if s/he did not mess screen up by * scrolling before... So fall down to old behavior here. */ - if (!LYCursesON || - (Newline_partial == 1 && strchr(newdoc.address, '#'))) + if (Newline_partial == 1 && strchr(newdoc.address, '#')) display_partial = FALSE; - } #endif /* DISP_PARTIAL */ #ifdef USE_PSRC psrc_first_tag = TRUE; @@ -990,6 +986,7 @@ newdoc.line = curdoc.line; newdoc.link = curdoc.link; newdoc.internal_link = FALSE; /* can't be true. - kw */ + Newline = newdoc.line; /* now here, no partial mode */ } /* @@ -997,23 +994,9 @@ * line the user was on if s/he has been in the file * before, or it is 1 if this is a new file. */ - Newline = newdoc.line; -#ifdef DISP_PARTIAL - if (display_partial) { - /* - * Override newdoc.line with a new value if user - * scrolled the document while downloading. - */ - if (Newline_partial != newdoc.line - && NumOfLines_partial > 0) - Newline = Newline_partial; - - /* - * End of incremental rendering stage here. - */ - display_partial = FALSE; - } -#endif /* DISP_PARTIAL */ + /* Newline = newdoc.line; */ + /* - alreary set and probably updated in partial mode */ + /* End of incremental rendering stage here. */ /* * If we are going to a target line or @@ -1260,7 +1243,7 @@ #ifdef SOURCE_CACHE /* * If the parse settings have changed since this HText was - * generated, we need to reparse and redraw it. + * generated, we need to reparse and redraw it. -dsb */ if (HTdocument_settings_changed()) { HTUserMsg(gettext("Reparsing document under current settings...")); @@ -1269,7 +1252,7 @@ else { /* * Urk. I have no idea how to recover from a failure here. - * At a guess, I'll try reloading. + * At a guess, I'll try reloading. -dsb */ cmd = LYK_RELOAD; goto new_cmd; @@ -1298,7 +1281,6 @@ */ more = HText_canScrollDown(); curdoc.line = Newline = HText_getTopOfScreen()+1; - lines_in_file = HText_getNumOfLines(); if (curdoc.title == NULL) { /* @@ -1358,6 +1340,15 @@ if (lynx_edit_mode && nlinks > 0 && !HTList_isEmpty(tagged)) showtags(tagged); #endif /* DIRED_SUPPORT */ +#ifdef SOURCE_CACHE + /* + * This information can get clobbered if we go to an internal + * page while viewing source. Normally it would be recreated + * by reloading the file; we have to do it ourselves. -dsb + */ + if (curdoc.link < 0 && nlinks > 0) + curdoc.link = 0; +#endif if (user_mode == NOVICE_MODE) noviceline(more); /* print help message */ refresh_screen = FALSE; @@ -1671,7 +1662,6 @@ links[curdoc.link+1].form->name) != 0)))))) { HText_ExpandTextarea (&links[curdoc.link], 1); - lines_in_file = HText_getNumOfLines(); if (links[curdoc.link].ly < display_lines) { refresh_screen = TRUE; @@ -2110,6 +2100,25 @@ #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; + /* + * These normally get cleaned up after getfile() returns; + * since we're not calling getfile(), we have to clean them + * up ourselves. -dsb + */ + HTOutputFormat = WWW_PRESENT; +#ifdef USE_PSRC + if (psrc_view) + HTMark_asSource(); + psrc_view = FALSE; +#endif + /* + * Set the remaining document elements. + */ + if (ownerS_address != NULL) { + if (!HText_getOwner()) + HText_setMainTextOwner(ownerS_address); + FREE(ownerS_address); + } break; } #endif @@ -2512,7 +2521,7 @@ case LYK_END: if (more) { - Newline = lines_in_file - display_lines + 3; /* go to end of file */ + Newline = HText_getNumOfLines() - display_lines + 3; /* go to end of file */ arrowup = TRUE; /* position on last link */ } else { cmd = LYK_NEXT_PAGE; @@ -4037,7 +4046,7 @@ CurrentCharSet_flag != current_char_set || CurrentAssumeCharSet_flag != UCLYhndl_for_unspec || verbose_img_flag != verbose_img || - LYRawMode_flag != LYRawMode || + LYUseDefaultRawMode_flag != LYUseDefaultRawMode || LYSelectPopups_flag != LYSelectPopups || ((strcmp(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")) || @@ -4113,7 +4122,7 @@ CurrentAssumeCharSet_flag = UCLYhndl_for_unspec; show_dotfiles_flag = show_dotfiles; verbose_img_flag = verbose_img; - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; LYSelectPopups_flag = LYSelectPopups; StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); @@ -4656,7 +4665,7 @@ */ if (strcmp((curdoc.title ? curdoc.title : ""), SHOWINFO_TITLE)) { - if (showinfo(&curdoc, lines_in_file, + if (showinfo(&curdoc, HText_getNumOfLines(), &newdoc, owner_address) < 0) break; StrAllocCopy(newdoc.title, SHOWINFO_TITLE); @@ -4698,8 +4707,6 @@ n = HText_ExtEditForm (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st trailing blank line in @@ -4731,7 +4738,6 @@ HText_ExpandTextarea (&links[curdoc.link], TEXTAREA_EXPAND_SIZE); - lines_in_file = HText_getNumOfLines(); refresh_screen = TRUE; } else { @@ -4749,8 +4755,6 @@ n = HText_InsertFile (&links[curdoc.link]); - lines_in_file = HText_getNumOfLines(); - /* * TODO: Move cursor "n" lines from the current line to * position it on the 1st line following the text @@ -4788,7 +4792,7 @@ PRINT_OPTIONS_TITLE)) { if (print_options(&newdoc.address, - &curdoc.address, lines_in_file) < 0) + &curdoc.address, HText_getNumOfLines()) < 0) break; StrAllocCopy(newdoc.title, PRINT_OPTIONS_TITLE); FREE(newdoc.post_data); @@ -5626,7 +5630,7 @@ LYUseDefaultRawMode = !LYUseDefaultRawMode; HTUserMsg(LYRawMode ? RAWMODE_OFF : RAWMODE_ON); HTMLSetCharacterHandling(current_char_set); - LYRawMode_flag = LYRawMode; + LYUseDefaultRawMode_flag = LYUseDefaultRawMode; #ifdef SOURCE_CACHE if (HTreparse_document()) { refresh_screen = TRUE; From owner-lynx-dev@sig.net Thu Apr 15 10:22:33 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA14142 for ; Thu, 15 Apr 1999 10:22:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA14476; Thu, 15 Apr 1999 09:04:07 -0500 (CDT) From: Philip Webb Message-Id: <199904151404.KAA29790@chass.utoronto.ca> Subject: Re: lynx-dev need help with lynx key mapping To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 10:04:04 -0400 (EDT) Cc: collins@iastate.edu In-Reply-To: <3.0.3.32.19990414085025.007dea00@collins.mail.iastate.edu> from "Gene Collins" at Apr 14, 99 08:50:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1831 Lines: 34 990414 Gene Collins wrote: > Hello. I'm running Lynx 2.8.1dev.16 under Windows 95. > I am a totally blind person using the ASAP screen reader. > The problem is that the screen reader wants to use the numeric key pad > for its command keys. Since Lynx is a Windows console app, > conagent.exe takes over the keyboard interrupt and passes > all my screen reader commands on to Lynx, instead of allowing > the screen reader to capture them as would normally be the case. > I would like to map the numeric key pad > so that all the keys on the keypad are ignored, > but the arrow keys, page up, page down, home and end keys will still work. > where can I find the key scan codes or special key names > that I need for specifically mapping the numeric key pad, > and what Lynx action verb should I map to each key that I would like ignored. > I would like to put these mappings in my lynx.cfg file, > but the mapping area of lynx.cfg doesn't seem to reference > the key pad home and end keys etc. separately > from the other home, end, page up, page down, etc. i can't offer explicit help beyond Doug Kaufman's advice, but i seem to remember a brief discussion recently on lynx-dev: try searching the Archive at http://www.flora.org/lynx-dev , esp messages from Rosmaita, Rasmussen & Eaves, but not confined to those; you may need to work back to February or January. you should also update to the latest release 2-8-1rel.2 , if possible: it has a newer Main Help Page, whose links [7] & [11] may help you. get it from http://www.slcc.edu/lynx/release . -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 15 10:42:11 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA14685 for ; Thu, 15 Apr 1999 10:42:08 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA20551; Thu, 15 Apr 1999 09:21:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904151421.KAA15779@shell.clark.net> Subject: Re: lynx-dev Problem with lynx 2.8.1 To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 10:21:06 -0400 (EDT) In-Reply-To: from "Vahid Sanei " at Apr 15, 99 09:16:45 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 932 Lines: 30 > > > Hi there, > I recently downloaded and installed lynx 2.8.1 in my home directory, but > I have a problem with it. When I read HTML files by lynx 2.8.1, it shows > links and hypertexts in reverse mode instead of showing them in color and > changing terminal settings has not any effect on it, but when I use my > previous lynx 2.6 hypertexts apear in color. How can I overcome this > problem. I would appreciate receiving your comments. > > - OS= Linux 2.0.3 > - Terminal type= vt100 vt100's don't do color you need a $TERM that corresponds to your actual terminal type, anyway. that's covered in my ncurses faq: http://www.clark.net/pub/dickey/ncurses/ncurses.faq.html > Best regards > Vahid Sanei > Institute of Biochemistry and Biophysics, > Tehran University, Tehran, Iran. > ######################################### > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Apr 15 10:42:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA14690 for ; Thu, 15 Apr 1999 10:42:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA19484; Thu, 15 Apr 1999 09:18:19 -0500 (CDT) From: Philip Webb Message-Id: <199904151418.KAA01855@chass.utoronto.ca> Subject: Re: lynx-dev HTML 4.0 (was Commenting... ) To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 10:18:13 -0400 (EDT) In-Reply-To: <19990415173526.A14035@transas.com> from "Michael Sobolev" at Apr 15, 99 05:35:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1581 Lines: 33 990415 Michael Sobolev wrote: >>> Where is this documented? >> In the Lynx help files: >> .../lynx2-8-2/lynx_help/lynx_url_support.html#mailto > The page you specified contains an example how this could be done. > What I was looking for was: > At any time while viewing documents within Lynx, > you may use the 'c' command to send a mail message > to the owner of the current document if the author of the document > has specified ownership (which is defined by the LINK element > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > where attribute REL has value either `made' or `owner'). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > If no ownership is specified then comments are disabled. > Certain links called mailto: links will also allow you to send mail > to other people. Using the mail features within Lynx is straightforward. > (The underlined is what I wanted to see. :) > Finally I found that the documentation is incomplete. :) a common occurrence ... > In Lynx_users_guide.html#Banners I found the complete list > of expected values for REL attribute of the LINK element. > Among them I could find neither `made' nor `owner'. > Please take it as a plain fact. :) health warning: trying to improve Lynx documentation can be painful. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Thu Apr 15 10:52:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA14981 for ; Thu, 15 Apr 1999 10:52:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26597; Thu, 15 Apr 1999 09:38:29 -0500 (CDT) From: Philip Webb Message-Id: <199904151438.KAA04047@chass.utoronto.ca> Subject: Re: lynx-dev dev.22 lynx_dev.html To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 10:38:09 -0400 (EDT) In-Reply-To: <9904150518.aa12699@deepthought.armory.com> from "Bela Lubkin" at Apr 15, 99 05:18:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1139 Lines: 29 990415 Bela Lubkin tried to sow seed in stony ground: > 990415 Philip Webb wrote: >> the problem people were having with my use of
      was >> that they were reading the patch instead of the rendered help-file. >> the latter should be neat & easy to read: i agree it's probably better >> to put long stretches of the help documentation in
      ...
      . -- examples snipped -- > You are imposing *your* idea of a good screen width on your readers. grepping the files in /lynx_help/keystrokes/ gives 9 which use
      :
       
        alt_edit_help.html:

        dired_help.html:
        edit_help.html:

        environments.html:
        keystroke_help.html:
        movement_help.html:
        other_help.html:
        scrolling_help.html:
        test_display.html:
      
      a good example is  dired_help.html .
      i don't know who created these: one of the Giants, presumably ...
      
      -- 
      ========================,,============================================
      SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
      ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
      TRANSIT    `-O----------O---'  University of Toronto
      
      From owner-lynx-dev@sig.net  Thu Apr 15 11:40:35 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA16305
      	for ; Thu, 15 Apr 1999 11:40:33 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA10540; Thu, 15 Apr 1999 10:17:00 -0500 (CDT)
      Date: Thu, 15 Apr 1999 19:09:24 +0400
      From: Michael Sobolev 
      To: lynx-dev@sig.net
      Subject: lynx documentation (was Re: lynx-dev HTML 4.0 (was Commenting... ))
      Message-ID: <19990415190924.A15981@transas.com>
      References: <19990415173526.A14035@transas.com> <199904151418.KAA01855@chass.utoronto.ca>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <199904151418.KAA01855@chass.utoronto.ca>; from Philip Webb on Thu, Apr 15, 1999 at 10:18:13AM -0400
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 500
      Lines: 16
      
      On Thu, Apr 15, 1999 at 10:18:13AM -0400, Philip Webb wrote:
      > Michael Sobolev wrote: 
      > > Finally I found that the documentation is incomplete. :)
      > 
      > a common occurrence ...
      Sure.  :)
      
      > health warning: trying to improve Lynx documentation can be painful.
      Yes, that should be.
      
      BTW, can anybody tell how the documentation of lynx is usually modified?
      A lot of features get added, and then, one day, documentation is brought
      up-to-date, or every added feature gets immediately documented?
      
      --
      Mike
      
      From owner-lynx-dev@sig.net  Thu Apr 15 13:05:00 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA18809
      	for ; Thu, 15 Apr 1999 13:04:59 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA04273; Thu, 15 Apr 1999 11:21:19 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904151621.MAA04891@shell.clark.net>
      Subject: Re: lynx documentation (was Re: lynx-dev HTML 4.0 (was Commenting... ))
      To: lynx-dev@sig.net
      Date: Thu, 15 Apr 1999 12:21:06 -0400 (EDT)
      In-Reply-To: <19990415190924.A15981@transas.com>  from "Michael Sobolev " at Apr 15, 99 07:09:24 pm
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 722
      Lines: 23
      
      > 
      > On Thu, Apr 15, 1999 at 10:18:13AM -0400, Philip Webb wrote: 
      > > Michael Sobolev wrote:  
      > > > Finally I found that the documentation is incomplete. :) 
      > >  
      > > a common occurrence ... 
      > Sure.  :) 
      >  
      > > health warning: trying to improve Lynx documentation can be painful. 
      > Yes, that should be. 
      >  
      > BTW, can anybody tell how the documentation of lynx is usually modified? 
      > A lot of features get added, and then, one day, documentation is brought 
      > up-to-date, or every added feature gets immediately documented? 
      
      some people document as they go along, some don't.
      
      All of the interesting changes should be reflected in 'CHANGES'.
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Thu Apr 15 17:01:01 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA25478
      	for ; Thu, 15 Apr 1999 17:00:58 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA03242; Thu, 15 Apr 1999 15:37:44 -0500 (CDT)
      Date: 	Thu, 15 Apr 1999 09:08:00 -1000
      From: Steven Sakata 
      X-Sender: steven@uhunix2
      To: lynx-dev@sig.net
      Subject: lynx-dev passing the authentication login/password via a file?
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 457
      Lines: 9
      
      We are using "lynx" on a UNIX box to download files from a secure site.  We
      currently pass the login and password using the "-auth" argument.  It works
      well.  However, my concern is that while it is running, any user can do a "ps" 
      and see the login and password in clear text.  I was wondering if there is
      a way to have the login and password in a file, or set in an environment
      variable instead of having it used on the command line.
      
      Thank you, Steven.
      
      
      From owner-lynx-dev@sig.net  Thu Apr 15 17:30:06 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA26351
      	for ; Thu, 15 Apr 1999 17:30:05 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA16795; Thu, 15 Apr 1999 16:15:45 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904152115.RAA23293@shell.clark.net>
      Subject: Re: lynx-dev passing the authentication login/password via a file?
      To: lynx-dev@sig.net
      Date: Thu, 15 Apr 1999 17:15:40 -0400 (EDT)
      In-Reply-To:   from "Steven Sakata " at Apr 15, 99 09:08:00 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 696
      Lines: 18
      
      > 
      > We are using "lynx" on a UNIX box to download files from a secure site.  We 
      > currently pass the login and password using the "-auth" argument.  It works 
      > well.  However, my concern is that while it is running, any user can do a "ps"  
      > and see the login and password in clear text.  I was wondering if there is 
      > a way to have the login and password in a file, or set in an environment 
      > variable instead of having it used on the command line. 
      
      no - iirc it's only from the commandline; we'd have to implement it -
      a file maybe (environment variables are not necessarily secure either)
        
      > Thank you, Steven. 
      
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Thu Apr 15 20:33:26 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA04316
      	for ; Thu, 15 Apr 1999 20:33:25 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA07005; Thu, 15 Apr 1999 19:22:36 -0500 (CDT)
      To: lynx-dev@sig.net
      References:  
          
      Message-Id: 
      From: "Leonid Pauzner" 
      Date: Fri, 16 Apr 1999 04:16:53 +0400 (MSD)
      X-Mailer: dMail [Demos Mail for DOS v2.07b]
      Subject: Re: lynx-dev Re: dev22 - SOURCE_CACHE!=NONE and partial display
          mode
      MIME-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 6783
      Lines: 205
      
      15-Apr-99 17:07 Leonid Pauzner wrote:
      > 15-Apr-99 16:03 I wrote:
      
      >>   - add partial display mode for HTreparse_document() operations - LP
      
      >> (yes, I know this fix looks ugly, display partial staff should went
      >> from mainloop() to HT*Copy(), will be done later
      >> but how about corrupted screen?)
      
      > Now a better fix for display partial mode - more clean and should be used
      > for dev23 patch integration series. LYMain.c changes excluded.
      > More LYMainLoop.c and GridText.c changes welcome.
      
      
      And now I fix the problem with screen repainting in partial mode,
      the patch against the previous one:
      
      
      diff -u ../gridtext.c ./gridtext.c
      --- ../gridtext.c       Thu Apr 15 16:27:52 1999
      +++ ./gridtext.c        Fri Apr 16 03:00:12 1999
      @@ -123,6 +123,7 @@
       PUBLIC char * source_cache_filename = NULL;
       PUBLIC HTChunk * source_cache_chunk = NULL;
       PUBLIC int LYCacheSource = SOURCE_CACHE_NONE;
      +PUBLIC BOOLEAN from_source_cache = FALSE;  /* mutable */
       #endif
      
       #if defined(USE_COLOR_STYLE)
      @@ -6259,9 +6260,8 @@
      
           CTRACE(tfp, "Reparse %s\n", (ok ? "succeeded" : "failed"));
      
      -    if (ok)  {/* fix few flags: */
      -       more = HText_canScrollDown();  /* the length may be changed */
      -    }
      +    if (ok)
      +       from_source_cache = TRUE;  /* flag for mainloop events */
      
           return ok;
       }
      diff -u ../lyglobal.h ./lyglobal.h
      --- ../lyglobal.h       Thu Apr 15 12:51:30 1999
      +++ ./lyglobal.h        Fri Apr 16 02:03:14 1999
      @@ -252,6 +252,7 @@
       #ifdef SOURCE_CACHE
       extern char * source_cache_filename;
       extern HTChunk * source_cache_chunk;
      +extern BOOLEAN from_source_cache; /* mutable */
       extern int LYCacheSource;
       #define SOURCE_CACHE_NONE      0
       #define SOURCE_CACHE_FILE      1
      Only in ..: lyhistor.c
      Only in ..: lymain.c
      diff -u ../lymainlo.c ./lymainlo.c
      --- ../lymainlo.c       Thu Apr 15 16:38:34 1999
      +++ ./lymainlo.c        Fri Apr 16 03:59:22 1999
      @@ -1127,7 +1127,6 @@
                    */
                   Newline = www_search_result;
                   www_search_result = -1;  /* reset */
      -            more = HText_canScrollDown();
              }
      
              if (first_file == TRUE) {
      @@ -1247,8 +1246,7 @@
               */
              if (HTdocument_settings_changed()) {
                  HTUserMsg(gettext("Reparsing document under current settings..."));
      -           if (HTreparse_document())
      -               refresh_screen = TRUE;
      +           if (HTreparse_document()) {}
                  else {
                      /*
                       * Urk.  I have no idea how to recover from a failure here.
      @@ -1258,8 +1256,32 @@
                      goto new_cmd;
                  }
              }
      +
      +       /*
      +        *  Trying to accomodate HTreparse_document() logic
      +        *  with mainloop events. Set all the necessaty flags here...
      +        */
      +       if (from_source_cache) {
      +               from_source_cache = FALSE; /* reset */
      +
      +               refresh_screen = TRUE; /* ? */
      +                   /*
      +                    *  Make sure curdoc.line will not be equal
      +                    *  to Newline, so we get a redraw.
      +                    */
      +                   curdoc.line = -1;
      +
      +           /*
      +            * This information can get clobbered if we go to an internal
      +            * page while viewing source.  Normally it would be recreated
      +            * by reloading the file; we have to do it ourselves.  -dsb
      +            */
      +           if (curdoc.link < 0 && nlinks > 0)
      +               curdoc.link = 0;
      +       }
       #endif
      
      +
              /*
               *  If the curdoc.line is different than Newline then there must
               *  have been a change since last update.  Run HText_pageDisplay()
      @@ -1275,9 +1297,9 @@
                  if (lynx_edit_mode && nlinks > 0 && !HTList_isEmpty(tagged))
                    showtags(tagged);
       #endif /* DIRED_SUPPORT */
      +
                  /*
      -            *  If more equals TRUE, then there is more
      -            *  info below this page .
      +            *  If more equals TRUE, then there is more info below this page.
                   */
                  more = HText_canScrollDown();
                  curdoc.line = Newline = HText_getTopOfScreen()+1;
      @@ -1340,15 +1362,12 @@
                  if (lynx_edit_mode && nlinks > 0 && !HTList_isEmpty(tagged))
                      showtags(tagged);
       #endif /* DIRED_SUPPORT */
      -#ifdef SOURCE_CACHE
      +
                  /*
      -            * This information can get clobbered if we go to an internal
      -            * page while viewing source.  Normally it would be recreated
      -            * by reloading the file; we have to do it ourselves.  -dsb
      +            *  If more equals TRUE, then there is more info below this page.
                   */
      -           if (curdoc.link < 0 && nlinks > 0)
      -               curdoc.link = 0;
      -#endif
      +           more = HText_canScrollDown();
      +
                  if (user_mode == NOVICE_MODE)
                      noviceline(more);  /* print help message */
                  refresh_screen = FALSE;
      @@ -2099,7 +2118,6 @@
       #endif
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      /*
                       * These normally get cleaned up after getfile() returns;
                       * since we're not calling getfile(), we have to clean them
      @@ -2228,7 +2246,6 @@
                  }
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
                  HTuncache_current_document();
      @@ -2274,7 +2291,6 @@
                  }
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
                  HTuncache_current_document();
      @@ -2313,7 +2329,6 @@
                            SOFT_DOUBLE_QUOTE_ON : SOFT_DOUBLE_QUOTE_OFF);
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
                  HTuncache_current_document();
      @@ -2373,7 +2388,6 @@
                  HTUserMsg(Old_DTD ? USING_DTD_0 : USING_DTD_1);
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
                  HTuncache_current_document();
      @@ -5598,7 +5612,6 @@
                           CLICKABLE_IMAGES_ON : CLICKABLE_IMAGES_OFF);
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
       #endif
      @@ -5615,7 +5628,6 @@
                            PSEUDO_INLINE_ALTS_ON : PSEUDO_INLINE_ALTS_OFF);
       #ifdef SOURCE_CACHE
                  if (HTreparse_document()) {
      -               refresh_screen = TRUE;
                      break;
                  }
       #endif
      @@ -5633,7 +5645,6 @@
                      LYUseDefaultRawMode_flag = LYUseDefaultRawMode;
       #ifdef SOURCE_CACHE
                      if (HTreparse_document()) {
      -                   refresh_screen = TRUE;
                          break;
                      }
       #endif
      
      
      
      
      From owner-lynx-dev@sig.net  Thu Apr 15 20:36:53 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA04337
      	for ; Thu, 15 Apr 1999 20:36:46 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA07588; Thu, 15 Apr 1999 19:25:30 -0500 (CDT)
      Date: Thu, 15 Apr 1999 20:25:21 -0400 (EDT)
      From: Scott Bigham 
      X-Sender: dsb@rover
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching
       fixes)
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1414
      Lines: 29
      
      On Thu, 15 Apr 1999, Klaus Weide wrote:
      
      > On Thu, 15 Apr 1999, Leonid Pauzner wrote:
      
      > > That was a very expensive solution before SOURCE_CACHE
      > > but now this can be done nicely by adding more parameters to the function
      > > above and avoid using of HTuncache_current_document() calls.
      > > Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy.
      
      > If the behavior is changed from "only reload top document after
      > relevant option change" to "reload all affected documents after option
      > change", then please make this optional/configurable.  The current
      > behavior is maybe sometimes unexpected, but I generally prefer it over
      > the alternative.  I know where the ^R key is if I need it, and would
      > like to avoid unnecessary reloading.
      
      If I may...  If I understand what Leonid is proposing, it would have no
      effect if source caching was not active.  Currently, if source caching
      is enabled and a document is fetched from cache that was originally
      parsed under settings different from the current settings (if inline
      image links have been toggled since you visited that page, for
      instance), the document is automatically re-parsed from cached source
      under the new settings; if source caching is disabled, the behavior is
      unchanged.  AIUI, Leonid is proposing that certaing settings adjustable
      from the options menu, like numbers-as-arrows, be treated in the same
      manner.
      
      						-sbigham
      
      
      From owner-lynx-dev@sig.net  Thu Apr 15 20:57:12 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA05984
      	for ; Thu, 15 Apr 1999 20:57:11 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA13232; Thu, 15 Apr 1999 19:50:22 -0500 (CDT)
      Date: Thu, 15 Apr 1999 17:50:13 -0700 (PDT)
      From: Doug Kaufman 
      X-Sender: dkaufman@waltz
      To: Steven Sakata 
      Cc: lynx-dev@sig.net
      Subject: Re: lynx-dev passing the authentication login/password via a file?
      In-Reply-To: 
      Message-Id: 
      Mime-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1083
      Lines: 24
      
      On Thu, 15 Apr 1999, Steven Sakata wrote:
      
      > We are using "lynx" on a UNIX box to download files from a secure
      > site. We currently pass the login and password using the "-auth"
      > argument. It works well. However, my concern is that while it is
      > running, any user can do a "ps" and see the login and password in
      > clear text. I was wondering if there is a way to have the login and
      > password in a file, or set in an environment variable instead of
      > having it used on the command line.
      
      I see two solutions to this problem. If you use lynx in interactive
      mode, it will ask for the userid and password at the time you try to
      download. This information should not be available via "ps". If in
      non-interactive mode, I don't think that lynx can do this, but wget
      can. Wget can read the userid and password from your .netrc file.
      Read the section of the wget info pages on security considerations,
      however. Wget is available from any of the usual Gnu archives.
                                    Doug
      
      __
      Doug Kaufman
      Internet: dkaufman@rahul.net (preferred)
      	  bn900@cleveland.freenet.edu
      
      
      From owner-lynx-dev@sig.net  Thu Apr 15 22:36:11 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA09163
      	for ; Thu, 15 Apr 1999 22:36:10 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA04692; Thu, 15 Apr 1999 21:28:47 -0500 (CDT)
      Date: Thu, 15 Apr 1999 21:28:42 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      cc: Steven Sakata 
      Subject: Re: lynx-dev passing the authentication login/password via a file?
      In-Reply-To: <199904152115.RAA23293@shell.clark.net>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 868
      Lines: 26
      
      On Thu, 15 Apr 1999 dickey@clark.net wrote:
      
      > > We are using "lynx" on a UNIX box to download files from a secure site.  We 
      > > currently pass the login and password using the "-auth" argument.  It works 
      > > well.  However, my concern is that while it is running, any user can do a "ps"  
      > > and see the login and password in clear text.  I was wondering if there is 
      > > a way to have the login and password in a file, or set in an environment 
      > > variable instead of having it used on the command line. 
      > 
      > no - iirc it's only from the commandline; we'd have to implement it -
      > a file maybe (environment variables are not necessarily secure either)
      
      Reading of flags from stdin is already there, and has been for a long
      time.  Try
      
         $ lynx http://somewhere...  -
         -auth=...
         ^D
      
      and
      
         $ lynx http://somewhere...  -dump  - < ~/mylynxflags
      
      
         Klaus
      
      
      From owner-lynx-dev@sig.net  Thu Apr 15 23:55:51 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA11356
      	for ; Thu, 15 Apr 1999 23:55:50 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA21249; Thu, 15 Apr 1999 22:47:05 -0500 (CDT)
      Date: Fri, 16 Apr 1999 12:58:32 +0900 (JST)
      From: Henry Nelson 
      Message-Id: <199904160358.MAA19054@ibr1.irm.nara.kindai.ac.jp>
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev dev.22 lynx_dev.html
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 257
      Lines: 6
      
      > then you must object to the presence of 
      in HTML at all: > currently, it's a perfectly valid tag for all to use as they see fit. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Guess the 1st base umpire's out to lunch. __Henry From owner-lynx-dev@sig.net Fri Apr 16 00:28:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA12193 for ; Fri, 16 Apr 1999 00:28:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA27571; Thu, 15 Apr 1999 23:21:01 -0500 (CDT) From: Philip Webb Message-Id: <199904160420.AAA00803@chass.utoronto.ca> Subject: lynx-dev patch: add wget to Lynx help To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 00:20:58 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 817 Lines: 27 since we keep recommending wget to users, we should have it in Lynx help. *** old/lynx_help_main.html Fri Apr 16 00:10:06 1999 --- new/lynx_help_main.html Fri Apr 16 00:17:11 1999 *************** *** 67,72 **** --- 67,79 ----
    • WDG HTML Validator
    +

    Other browsing software:

    + +
      +
    • WGET + -- powerful & flexible non-interactive downloader +
    +

    Meta-indexes: lists of links

      -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 03:12:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA17094 for ; Fri, 16 Apr 1999 03:12:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA15609; Fri, 16 Apr 1999 01:53:47 -0500 (CDT) From: David Woolley Message-Id: <199904151944.UAA13871@djwhome.demon.co.uk> Subject: lynx-dev Colour lost on upgrade (was: Problem with lynx 2.8.1) To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 20:44:41 +0100 (BST) In-Reply-To: from "Vahid Sanei" at Apr 14, 99 07:51:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 508 Lines: 12 > I recently downloaded and installed lynx 2.8.1 in my home directory, but > I have a problem with it. When I read HTML files by lynx 2.8.1, it shows > links and hypertexts in reverse mode instead of showing them in color and Link Lynx with a terminal handling library that supports colour and then add the relevant lines to lynx.cfg. Lynx can be used with several different libraries, not all of which support colour. Unspecied Unix brand assumed, although the principle is probably the same for Win32. From owner-lynx-dev@sig.net Fri Apr 16 03:14:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA17126 for ; Fri, 16 Apr 1999 03:14:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA15616; Fri, 16 Apr 1999 01:53:49 -0500 (CDT) From: David Woolley Message-Id: <199904151935.UAA13835@djwhome.demon.co.uk> Subject: Re: lynx-dev Commenting... To: lynx-dev@sig.net Date: Thu, 15 Apr 1999 20:35:34 +0100 (BST) In-Reply-To: <19990414200549.A15422@mail.bcpl.net> from "Webmaster Jim" at Apr 14, 99 08:05:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 625 Lines: 12 > Lynx can use the following as an author/owner tag: > > This is malformed. You should have %20, not raw spaces in URLs. In addition, I'm not sure that the full RFC 822 syntax is allowed in this context - if it is not, the exact mail software on the system may affect whether or not this works - it appears to work for sendmail 8.8.8. Note also, that although this was in early HTML standards, it was dropped following the singular failure of GUI browsers to adopt it, even though they subsequently added META AUTHOR, with no mechanism to mail the author. From owner-lynx-dev@sig.net Fri Apr 16 04:34:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA20099 for ; Fri, 16 Apr 1999 04:33:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA21976; Fri, 16 Apr 1999 03:02:51 -0500 (CDT) To: lynx-dev@sig.net References: <19990411171008.A576@infinity.milliByte.de> Message-Id: From: "Leonid Pauzner" Date: Fri, 16 Apr 1999 11:56:06 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx 2.8.1rel.2 - HTTP bug? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2118 Lines: 60 11-Apr-99 17:10 Dirk Foersterling wrote: > Hi, > I found lynx (2.7.x, 2.8.0 and 2.8.1) sending incomplete HTTP requests. > For example retreiving the URL http://lynx.browser.org/ with lynx > (_not_using_any_proxy_) results in an error message (Bad Request). I > tracked it down and found lynx forming a request beginning with > GET HTTP/1.0 > Host: lynx.browser.org > which seems to be incorrect, because of the empty URI/path after GET. > A proxy usually inserts the missing "/" here, so the problem only shows > up in direct lynx/httpd communication. I tried this on several http > server software including Apache-1.3.6 and MS-IIS 4, to verify that not > a specific server version is picky about empty URIs. I was trying http://lynx.browser.org with and without proxy - "/" path sent, but apparently without hostname in this field. Is it correct? Composing Proxy Authorization for proxy.mccme.ru:3128/http://lynx.browser.org/ HTAASetup_lookup: No template matched `http://lynx.browser.org/' (so probably not protected) HTTP: Not sending proxy authorization (yet). Writing: GET http://lynx.browser.org/ HTTP/1.0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Host: lynx.browser.org Accept: text/html, text/plain, text/sgml, */*;q=0.01 ........ and Composing Authorization for lynx.browser.org:80/ HTAASetup_lookup: No template matched `' (so probably not protected) HTTP: Not sending authorization (yet). Writing: GET / HTTP/1.0 ^^^^^ Host: lynx.browser.org Accept: text/html, text/plain, text/sgml, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: en,ru Accept-Charset: windows-1251;1.0,*;0.5, iso-8859-1;q=0.01, us-ascii;q=0.01 User-Agent: Lynx/2.8.2dev.22 libwww-FM/2.14 Referer: http://www.slcc.edu/lynx/current/ BTW, developers, no_cache lync.cfg variable can not be reloaded via reload_read_cfg() at run time currently - only for next session. Will fix this also. > -dirk > -- > D i r k F "o r s t e r l i n g > milliByte@DeathsDoor.com ******** http://www.DeathsDoor.com/milliByte/ > ------------- > ISDN - [I]st [S]owas [D]enn [N]oetig? From owner-lynx-dev@sig.net Fri Apr 16 05:15:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA21108 for ; Fri, 16 Apr 1999 05:15:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA27194; Fri, 16 Apr 1999 04:01:40 -0500 (CDT) Date: Fri, 16 Apr 1999 04:01:35 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx 2.8.1rel.2 - HTTP bug? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1356 Lines: 43 On Fri, 16 Apr 1999, Leonid Pauzner wrote: > 11-Apr-99 17:10 Dirk Foersterling wrote: > > Hi, > > > I found lynx (2.7.x, 2.8.0 and 2.8.1) sending incomplete HTTP requests. > > For example retreiving the URL http://lynx.browser.org/ with lynx > > (_not_using_any_proxy_) results in an error message (Bad Request). I > > tracked it down and found lynx forming a request beginning with > > > GET HTTP/1.0 > > Host: lynx.browser.org > > > which seems to be incorrect, because of the empty URI/path after GET. It's certainly incorrect, and I've never seen lynx do that. I think it's most likely that something went wrong in your compilation(s). Seomethings seems to be screwed up in the internal structures. > > A proxy usually inserts the missing "/" here, so the problem only shows > > up in direct lynx/httpd communication. I tried this on several http > > server software including Apache-1.3.6 and MS-IIS 4, to verify that not > > a specific server version is picky about empty URIs. > > I was trying http://lynx.browser.org with and without proxy - > "/" path sent, but apparently without hostname in this field. > Is it correct? > > GET http://lynx.browser.org/ HTTP/1.0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Host: lynx.browser.org > ........ > and > > Writing: > GET / HTTP/1.0 > ^^^^^ > Host: lynx.browser.org It's the only right way. Klaus From owner-lynx-dev@sig.net Fri Apr 16 06:00:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA22080 for ; Fri, 16 Apr 1999 06:00:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11521; Fri, 16 Apr 1999 04:43:16 -0500 (CDT) Date: Fri, 16 Apr 1999 04:43:13 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Re: STARTFILE patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1677 Lines: 39 On Thu, 15 Apr 1999, Doug Kaufman wrote: > On Wed, 14 Apr 1999, Klaus Weide wrote: > > > - for 3), the underlying network problem has to be fixed. This seems > > to be a problem mostly for users of 386 binaries. Maybe creators of > > those packages can make further improvements (or maybe they are already > > doing everything that makes sense). > > Maybe I missed it, but I haven't noticed this at all. For example the exchange including your message . But I didn't mean to imply that there's an overwhelming number of those; just that of users that need help with basic network setup problems, most seem to be 386 binary users. > The DOS version is inherently difficult to configure, no doubt, and I didn't mean to criticize your (or someone else's) packages. > but most of this has been > partially automated by Alfredo Cole's program to setup DOSPPP and the > batch file I include with the binary. I haven't looked at them lately, > but I believe that there are at least two other efforts to make things > easy for users, John Lewis's Bobcat386 package (available from the > fdisk site) and the lynx_kit distribution (from rene.simplenet.com). But as long as there are older (less well packaged, I assume) packages around, with pointers to them, there will be people downloading them and then maybe having unnecessary difficulties. (It isn't clear to me, just from following links starting with http://lynx.browser.org/, which would be the currently most up-to-date and complete package; but I'm just commenting as a bystander, having never tried any of the Lynx386 packages.) Klaus From owner-lynx-dev@sig.net Fri Apr 16 06:05:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA22322 for ; Fri, 16 Apr 1999 06:05:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA12348; Fri, 16 Apr 1999 04:53:36 -0500 (CDT) Date: Fri, 16 Apr 1999 04:53:33 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1916 Lines: 38 On Thu, 15 Apr 1999, Leonid Pauzner wrote: > 15-Apr-99 03:50 Klaus Weide wrote: > > If the behavior is changed from "only reload top document after > > relevant option change" to "reload all affected documents after option > > change", then please make this optional/configurable. The current > > behavior is maybe sometimes unexpected, but I generally prefer it over > > the alternative. I know where the ^R key is if I need it, and would > > like to avoid unnecessary reloading. > > I think a new behaviour should be implemented for SOURCE_CACHE!=NONE > (always "reload all affected documents" when we have sources locally - > it would be strange otherwise, so no configure options required here). > But with SOURCE_CACHE:NONE the old behaviour is preferrable by default > to avoid shocking of experienced lynx users base > (non default option may be implemented of cause). It would be nice if these two aspects - SOURCE_CACHE setting on the one hand, auto-invalidation of loaded documents on the other - could be implemented as independent settings (even if for the user they are coupled into one option as you sugggest). That would make it easier to change things later. > 14-Apr-99 14:12 Vlad Harchev wrote: > > But the way it's implemented now should be considered incorrect. IMO, user > > should understand that changing options have a penalty and not to do this > > very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't > > make things messy/slow. IMO, we should implement the correct behaviour. > > Using of locally installed cached proxis is a good solution > but they have a validation/no-cache/expired logic > thich may be contrary to our needs (say, dynamically generated pages > are always set to expired). I assume the SOURCE_CACHE has its own kind-of validation/no-cache/expired logic, just not date-based. But I admit I still haven't looked at the code. Klaus From owner-lynx-dev@sig.net Fri Apr 16 06:37:56 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA23112 for ; Fri, 16 Apr 1999 06:37:55 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA14291; Fri, 16 Apr 1999 05:15:58 -0500 (CDT) From: Philip Webb Message-Id: <199904161015.GAA08951@chass.utoronto.ca> Subject: lynx-dev Re: lynx documentation To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 06:15:56 -0400 (EDT) In-Reply-To: <199904151621.MAA04891@shell.clark.net> from "dickey@clark.net" at Apr 15, 99 12:21:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1496 Lines: 30 990415 Michael Sobolev wrote: > can anybody tell how the documentation of lynx is usually modified? > A lot of features get added, and then, one day, documentation is brought > up-to-date, or every added feature gets immediately documented? 990415 Thomas Dickey replied: > some people document as they go along, some don't. > All of the interesting changes should be reflected in 'CHANGES'. ie the answer to Michael's question is `neither'. as such, Lynx documentation is rarely updated: sometimes, people who have added features add something to the docs, but usually even they aren't interested enough & certainly no-one else around the place wants to invest the time. i've updated a few things here & there, but the destructive reactions of a few noisy people don't exactly encourage me to make a practice of it: there was a huge hoo-hah when i re-organised the Main Help Page for 2-8-1 , tho' of course now everyone's used to it no-one complains. basically, it's like a town meeting in Dodge City or maybe a residents' hearing about a development in present-day Toronto: no-one wants all that thro' traffic nor to lose their on-street parking. suggesting ordinary users search thro' CHANGES is presumably a joke ... -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 06:57:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA23607 for ; Fri, 16 Apr 1999 06:57:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA14957; Fri, 16 Apr 1999 05:23:59 -0500 (CDT) X-Authentication-Warning: www1.hanmail.net: Processed from queue /disk/8/smqueue X-Authentication-Warning: www1.hanmail.net: Processed by hanadmin with -C /hanmail/mta/conf/mixmail.cf From: "Alejandro Moraila Tostado" To: lynx-dev@sig.net Subject: lynx-dev more help..... X-Mailer: Daum Web Mailer 1.0 Date: Thu, 15 Apr 1999 21:58:02 +0100 Message-Id: <19990416005802.HM.00000000000Irhr@mixmail.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 385 Lines: 15 My sistem is: Windows 95 Proxy with firewall NT server LAN net Lynx for window "Lynx_32" If I write Lynx (host) from MS-DOS then Linx show me the page of NT server, but I can't call any other page. Could you tell me how can I write the URL in order to open another page? -------------------------------------------------- Su Email Privado, Gratis en http://www.mixmail.com From owner-lynx-dev@sig.net Fri Apr 16 07:00:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA23645 for ; Fri, 16 Apr 1999 07:00:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA02184; Fri, 16 Apr 1999 05:49:54 -0500 (CDT) From: dickey@clark.net Message-Id: <199904161049.GAA03417@shell.clark.net> Subject: Re: lynx-dev Re: lynx documentation To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 06:49:50 -0400 (EDT) In-Reply-To: <199904161015.GAA08951@chass.utoronto.ca> from "Philip Webb " at Apr 16, 99 06:15:56 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 330 Lines: 11 > suggesting ordinary users search thro' CHANGES is presumably a joke ... this is the developer's mailing list; it's not uncommon to get responses that point into the CHANGES files. > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 16 07:10:38 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA23910 for ; Fri, 16 Apr 1999 07:10:37 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA02129; Fri, 16 Apr 1999 05:49:24 -0500 (CDT) From: Philip Webb Message-Id: <199904161049.GAA09644@chass.utoronto.ca> Subject: lynx-dev screen widths To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 06:49:21 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1491 Lines: 31 some people have claimed -- recently & earlier -- that preformatting documentation with
      or
      ...
      causes problems for screens wider/narrower than the traditional 79 chars: BL displayed text 12 (rather far-fetched) & 50 (more realistic) chars wide, the latter causing awkward line-wrapping with
      's at c 65 chars. normally, reading material is narrower than 79 chars: eg from my shelf: SAS manual 80 hardback novel 60 paperback novel 60 New Yorker 40 / column Financial Times (London) 25 / column anything wider than c 80 chars is likely to be hard on R -> L eye movement, which is presumably why magazines & newspapers -- for quick reading -- divide their texts into columns much narrower than 80 chars; Lynx in fact uses 70 chars (cols 4 - 73) out of the 79 available. so i have a question & a (repeat) suggestion: how many lynx-devers regularly use Lynx with a screen width noticeably more/less than 79 chars & in what contexts? how difficult would it be to add an Option to vary the screen width, incl using the whole of cols 1 - 79 available on a regular screen? there might also be an Option to suppress
      , if it's causing problems. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 07:57:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA25174 for ; Fri, 16 Apr 1999 07:57:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07639; Fri, 16 Apr 1999 06:43:50 -0500 (CDT) Date: Fri, 16 Apr 1999 15:39:02 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Re: lynx documentation Message-ID: <19990416153902.A6133@transas.com> References: <199904161015.GAA08951@chass.utoronto.ca> <199904161049.GAA03417@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904161049.GAA03417@shell.clark.net>; from dickey@clark.net on Fri, Apr 16, 1999 at 06:49:50AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 277 Lines: 10 On Fri, Apr 16, 1999 at 06:49:50AM -0400, dickey@clark.net wrote: > this is the developer's mailing list; it's not uncommon to get responses > that point into the CHANGES files. Hmm... This returns us to my very first question: is there user's mailing list? Thanks, -- Mike From owner-lynx-dev@sig.net Fri Apr 16 08:07:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA25482 for ; Fri, 16 Apr 1999 08:07:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07824; Fri, 16 Apr 1999 06:45:42 -0500 (CDT) Date: Fri, 16 Apr 1999 06:45:37 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths In-Reply-To: <199904161049.GAA09644@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 725 Lines: 23 On Fri, 16 Apr 1999, Philip Webb wrote: > so i have a question & a (repeat) suggestion: > how many lynx-devers regularly use Lynx with a screen width > noticeably more/less than 79 chars & in what contexts? I do. Normally 100x32 text mode console. Everyone resizing an xterm window (where that works...) does. > how difficult would it be to add an Option to vary the screen width, > incl using the whole of cols 1 - 79 available on a regular screen? This doesn't belong in lynx, but in whatever provides lynx with a screen area to draw on. And it's already there: see your stty command. > there might also be an Option to suppress
      , if it's causing problems. This is too mind-boggling to respond to. Klaus From owner-lynx-dev@sig.net Fri Apr 16 08:14:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA25735 for ; Fri, 16 Apr 1999 08:14:06 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA09561; Fri, 16 Apr 1999 07:00:26 -0500 (CDT) Date: Fri, 16 Apr 1999 07:59:51 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Re: lynx documentation Message-ID: <19990416075951.A11716@mail.bcpl.net> References: <199904161015.GAA08951@chass.utoronto.ca> <199904161049.GAA03417@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904161049.GAA03417@shell.clark.net>; from dickey@clark.net on Fri, Apr 16, 1999 at 06:49:50AM -0400 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1080 Lines: 26 On Fri, Apr 16, 1999 at 06:49:50AM -0400, dickey@clark.net wrote: > > suggesting ordinary users search thro' CHANGES is presumably a joke ... > > this is the developer's mailing list; it's not uncommon to get responses > that point into the CHANGES files. Not to mention the CHANGES files are on line and included in the HTTP and FTP index files: http://www.slcc.edu/lynx/current/index.html http://www.slcc.edu/lynx/current/CHANGES ftp://lynx.isc.org/current/index.html ftp://lynx.isc.org/current/CHANGES Typically, when I update any free software I have on my machine I look through the developers CHANGES file to see what kind of bugs have been fixed, and what kind of new features exist. I expect most "ordinary users" do the same. ------ Marvin the Paranoid Android says: Oh sorry did I say something wrong? Pardon me for breathing, which I never do anyway so I don't know why I bother to say it. Oh God, I'm so depressed! From owner-lynx-dev@sig.net Fri Apr 16 08:14:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA25748 for ; Fri, 16 Apr 1999 08:14:35 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA09873; Fri, 16 Apr 1999 07:03:12 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Fri, 16 Apr 1999 15:57:52 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2243 Lines: 46 16-Apr-99 04:53 Klaus Weide wrote: > On Thu, 15 Apr 1999, Leonid Pauzner wrote: >> 15-Apr-99 03:50 Klaus Weide wrote: >> > If the behavior is changed from "only reload top document after >> > relevant option change" to "reload all affected documents after option >> > change", then please make this optional/configurable. The current >> > behavior is maybe sometimes unexpected, but I generally prefer it over >> > the alternative. I know where the ^R key is if I need it, and would >> > like to avoid unnecessary reloading. >> >> I think a new behaviour should be implemented for SOURCE_CACHE!=NONE >> (always "reload all affected documents" when we have sources locally - >> it would be strange otherwise, so no configure options required here). >> But with SOURCE_CACHE:NONE the old behaviour is preferrable by default >> to avoid shocking of experienced lynx users base >> (non default option may be implemented of cause). > It would be nice if these two aspects - SOURCE_CACHE setting on the one hand, > auto-invalidation of loaded documents on the other - could be implemented > as independent settings (even if for the user they are coupled into one > option as you sugggest). That would make it easier to change things later. Auto-invalidation logic controlled by a single line in mainloop(), so no problem to maintain. >> 14-Apr-99 14:12 Vlad Harchev wrote: >> > But the way it's implemented now should be considered incorrect. IMO, user >> > should understand that changing options have a penalty and not to do this >> > very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't >> > make things messy/slow. IMO, we should implement the correct behaviour. >> >> Using of locally installed cached proxis is a good solution >> but they have a validation/no-cache/expired logic >> thich may be contrary to our needs (say, dynamically generated pages >> are always set to expired). > I assume the SOURCE_CACHE has its own kind-of validation/no-cache/expired > logic, just not date-based. But I admit I still haven't looked at the > code. Currently no validation et all. Just reloading for \,[,*, etc. at the moment. But the implementation works! (we are fixing minore bugs in mainloop now). > Klaus From owner-lynx-dev@sig.net Fri Apr 16 08:19:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA25786 for ; Fri, 16 Apr 1999 08:19:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA10597; Fri, 16 Apr 1999 07:08:25 -0500 (CDT) Date: Fri, 16 Apr 1999 08:05:30 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev patch: add wget to Lynx help In-Reply-To: <199904160420.AAA00803@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 685 Lines: 24 On Fri, 16 Apr 1999, Philip Webb wrote: > +

      Other browsing software:

      > + > +
        > +
      • WGET > + -- powerful & flexible non-interactive downloader > +
      > + A one-element list always looks lonely. How about two more: curl: http://www.fts.frontec.se/~dast/curl/ (non-interactive url downloader, supports https urls) snarf: http://www.xach.com/snarf/ (simple, fast, small url downloader) Just an idea. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Fri Apr 16 08:25:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA26032 for ; Fri, 16 Apr 1999 08:25:35 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA11288; Fri, 16 Apr 1999 07:12:54 -0500 (CDT) Date: Fri, 16 Apr 1999 08:09:50 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths In-Reply-To: <199904161049.GAA09644@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 460 Lines: 14 On Fri, 16 Apr 1999, Philip Webb wrote: > so i have a question & a (repeat) suggestion: > how many lynx-devers regularly use Lynx with a screen width > noticeably more/less than 79 chars & in what contexts? I hardly ever use deviant screen widths. Sorry. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Fri Apr 16 08:33:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA26314 for ; Fri, 16 Apr 1999 08:33:18 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA12995; Fri, 16 Apr 1999 07:23:06 -0500 (CDT) To: lynx-dev@sig.net References: <199904161049.GAA03417@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Fri, 16 Apr 1999 16:20:56 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: lynx documentation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2170 Lines: 55 16-Apr-99 06:49 dickey@clark.net wrote: >> suggesting ordinary users search thro' CHANGES is presumably a joke ... > this is the developer's mailing list; it's not uncommon to get responses > that point into the CHANGES files. 16-Apr-99 15:39 Michael Sobolev wrote: > Hmm... This returns us to my very first question: is there user's mailing > list? I would like to introduce a letter from Al Gilman, IMO these words should be added for lynx-dev.html page 7-Apr-99 19:58 Al Gilman wrote: Date: Wed, 07 Apr 1999 19:58:42 -0400 To: tlhall@royal.net, owner-lynx-dev@sig.net, Leonid Pauzner , Maintainer of doslynx-dev , Maintainer of doslynx-dev , Owner of the Lynx-related email list index From: Al Gilman Subject: Re: lynx-dev lynx-users ; doslynx-dev ; doslynx-users Cc: Heather Stern At 09:21 AM 4/7/99 -0600, tlhall@royal.net wrote: >On Mon, Apr 05, 1999 at 10:34:53PM +0400, Leonid Pauzner wrote on lynx-dev: >> ... >> How many times would you send this question to the list >> (this is copy #3 during last week or so). >(sorry about the multi-posts, but something went wrong with my subscribe, >and I never saw my original show up in the archives, nor any responses, ... The key policy points are: Taking user queries off the list would not materially reduce the volume on the list. Developers can deal with a busy list and need a busy list to meet their needs. There is too sporadic a flow of user questions to support a mutual-help water-cooler sort of dialog space. Better they ask the developers, even when the questions are dumb. There just aren't enough of them to weed out. There was a lynx-learners list for a while, but it died after a while. I am not speaking for doslynx-dev. I don't have any idea of the health state of that list. This is just history. There are potentially smarter setups but it is not clear that that trip is necessary, that they would return enough value to justify the added maintenance cost. [explaining what questions go where, etc.] From owner-lynx-dev@sig.net Fri Apr 16 08:40:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA26428 for ; Fri, 16 Apr 1999 08:40:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA13873; Fri, 16 Apr 1999 07:28:42 -0500 (CDT) To: Date: Fri, 16 Apr 1999 05:58:20 -0500 (CDT) From: one12@usa.net Message-Id: <199904161058.FAA02913@roadrunner.sig.net> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 678 Lines: 17 I have a question regarding the SAVE_SPACE item in the lynx.cfg file. i am running the win32 version of lynx on windows nt 4.0 and have been wanting to download files and save them using the "Save to Disk" feature. But I am not sure what to place in the "SAVE_SPACE:" option in lynx.cfg. currently i have "drive:\temp". i have tried "drive:/temp" also. neither of them seem to work. what form do i have to put the path to have this work correctly? thank you for your help. jim ________________________________________________________ NetZero - We believe in a FREE Internet. Shouldn't you? Get your FREE Internet Access and Email at http://www.netzero.net/download.html From owner-lynx-dev@sig.net Fri Apr 16 08:47:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA26712 for ; Fri, 16 Apr 1999 08:47:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA15248; Fri, 16 Apr 1999 07:36:25 -0500 (CDT) Date: Fri, 16 Apr 1999 08:35:51 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904160835.AA15885@cas.org> Subject: Re: lynx-dev Re: lynx documentation In-Reply-To: Your message of Fri, 16 Apr 1999 07:59:51 -0400 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1015 Lines: 20 On Fri, Apr 16, 1999 at 06:49:50AM -0400, dickey@clark.net wrote: > > suggesting ordinary users search thro' CHANGES is presumably a joke ... > > this is the developer's mailing list; it's not uncommon to get responses > that point into the CHANGES files. But I thought that the point the _original poster_ was making was that while telling someone developing lynx (and thus having access and familarity with the code) to look thru the CHANGES file was an unfortunate fact of life, expecting to tell J Average User to do so , even IF a URL to an online copy of the CHANGES file is provided, seems to be a non-serious question. The CHANGES file is oriented towards someone more familar (and interested) in a historical evolution of the tool... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Fri Apr 16 08:48:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA26722 for ; Fri, 16 Apr 1999 08:48:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14015; Fri, 16 Apr 1999 07:29:28 -0500 (CDT) From: Jonathan Lawson To: lynx-dev@sig.net cc: lynx-dev@sig.net Subject: Re: lynx-dev screen widths In-Reply-To: <199904161049.GAA09644@chass.utoronto.ca> Message-ID: Date: Fri, 16 Apr 1999 13:29:27 +0100 (British Summer Time) X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 563 Lines: 21 Hi Phil, On Fri, 16 Apr 1999 06:49:21 -0400 (EDT) Philip Webb wrote: > anything wider than c 80 chars is likely to be hard on R -> L eye movement, Just for the sake of information is that 80 chars or 80 'chars width' .. The reason I ask is that I use SvgaTM @ 132x25 (humm ... does that explain my eyes?) anyhow I haven't seemed to notice any difficulties in reading (and I tend to read almost everything in html, these days) Regards ---------------------- Jonathan Lawson Cranfield University C.J.Lawson@Cranfield.ac.uk From owner-lynx-dev@sig.net Fri Apr 16 09:20:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA27892 for ; Fri, 16 Apr 1999 09:20:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA21762; Fri, 16 Apr 1999 08:06:41 -0500 (CDT) Date: Fri, 16 Apr 1999 06:06:04 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: Alejandro Moraila Tostado Cc: lynx-dev@sig.net Subject: Re: lynx-dev more help..... In-Reply-To: <19990416005802.HM.00000000000Irhr@mixmail.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 488 Lines: 21 On Thu, 15 Apr 1999, Alejandro Moraila Tostado wrote: > My sistem is: > Windows 95 > Proxy with firewall > NT server > LAN net > Lynx for window "Lynx_32" > If I write Lynx (host) from MS-DOS > then > Linx show me the page of NT server, but I can't call any > other page. Did you set "http_proxy" to your proxy server in lynx.cfg or in your environment? Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Apr 16 09:25:42 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28160 for ; Fri, 16 Apr 1999 09:25:40 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA20039; Fri, 16 Apr 1999 07:59:03 -0500 (CDT) From: Philip Webb Message-Id: <199904161259.IAA16545@chass.utoronto.ca> Subject: Re: lynx-dev patch: add downloaders to Main Help To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 08:59:00 -0400 (EDT) In-Reply-To: from "John Bley" at Apr 16, 99 08:05:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1040 Lines: 33 990416 John Bley wrote: > A one-element list always looks lonely. How about two more: done: *** lhm.mr Fri Apr 16 00:10:06 1999 --- lynx_help_main.html Fri Apr 16 08:53:58 1999 *************** *** 67,72 **** --- 67,83 ----
    • WDG HTML Validator
    +

    Other browsing software:

    + +
      +
    • WGET + -- powerful & flexible non-interactive downloader +
    • cURL + -- non-interactive downloader which supports HTTPS +
    • SNARF + -- small simple 1-file non-interactive downloader +
    +

    Meta-indexes: lists of links

      -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 09:31:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28306 for ; Fri, 16 Apr 1999 09:31:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA24684; Fri, 16 Apr 1999 08:17:40 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Fri, 16 Apr 1999 17:14:28 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev lynx DNS search MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6083 Lines: 151 BTW, while trying to access lynx.browser.org with no_proxy I was looking into trace log and was surprized by a series of LYGetHostByName() calls. Why not a single call? Lynx Trace Log (2.8.2dev.22) User message: Trace ON! 'lynx.browser.org' is not a URL Converted 'lynx.browser.org' to '/home/pauzner/lynx.browser.org' Can't stat() or fopen() '/home/pauzner/lynx.browser.org' Looking up lynx.browser.org first. LYGetHostByName: parsing `lynx.browser.org'. CHILD gethostbyname: 0x400e6ef4 { h_name = 0x400e6fa5 "lynx.browser.org", h_aliases = 0x400e6f08 { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x400e6e64 { 0x400e6fb8 "195.40.122.44", 0x0 } } CHILD fill_rehostent: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } 'lynx.browser.org' is not a URL Converted 'lynx.browser.org' to '/home/pauzner/lynx.browser.org' Can't stat() or fopen() '/home/pauzner/lynx.browser.org' Looking up lynx.browser.org first. LYGetHostByName: parsing `lynx.browser.org'. Read from pipe: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: NSL_FORK child 19276 exited, status 0x0. End of LYGetHostByName: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: Resolved name to a hostent. Trying: 'http://lynx.browser.org' HTParse: aName:http://lynx.browser.org relatedName: 1 HTParse: result:http://lynx.browser.org/ LYpush[1]: address:file://localhost/tmp/L19232-1TMP.html title:Information about the current document getfile: getting http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 0x8150120 has hash 57 and address `http://lynx.browser.org/' HTAccess: loading document http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName:file: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org Looking up lynx.browser.org. HTParseInet: parsing `lynx.browser.org'. LYGetHostByName: parsing `lynx.browser.org'. CHILD gethostbyname: 0x400e6ef4 { h_name = 0x400e6fa5 "lynx.browser.org", h_aliases = 0x400e6f08 { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x400e6e64 { 0x400e6fb8 "195.40.122.44", 0x0 } } CHILD fill_rehostent: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: Resolved name to a hostent. Trying: 'http://lynx.browser.org' HTParse: aName:http://lynx.browser.org relatedName: 1 HTParse: result:http://lynx.browser.org/ LYpush[1]: address:file://localhost/tmp/L19232-1TMP.html title:Information about the current document getfile: getting http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 0x8150120 has hash 57 and address `http://lynx.browser.org/' HTAccess: loading document http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName:file: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org Looking up lynx.browser.org. HTParseInet: parsing `lynx.browser.org'. LYGetHostByName: parsing `lynx.browser.org'. Read from pipe: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: NSL_FORK child 19277 exited, status 0x0. End of LYGetHostByName: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: Resolved name to a hostent. HTParseInet: Parsed address as port 80, IP address 195.40.122.44 Making HTTP connection to lynx.browser.org. HTParse: aName:http://lynx.browser.org/ relatedName: 1 HTParse: result:/ HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: 1 HTParse: result:/ HTParse: aName:http://lynx.browser.org/ relatedName: 1 HTParse: result: HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org LYCookie: Searching for 'lynx.browser.org:80', '/'. Composing Authorization for lynx.browser.org:80/ HTAASetup_lookup: No template matched `' (so probably not protected) HTTP: Not sending authorization (yet). Writing: GET / HTTP/1.0 Host: lynx.browser.org Accept: text/html, text/plain, text/sgml, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: en,ru Accept-Charset: windows-1251;1.0,*;0.5, iso-8859-1;q=0.01, us-ascii;q=0.01 User-Agent: Lynx/2.8.2dev.22 libwww-FM/2.14 ---------------------------------- Sending HTTP request. HTTP: WRITE delivered OK ... From owner-lynx-dev@sig.net Fri Apr 16 09:37:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28597 for ; Fri, 16 Apr 1999 09:36:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23257; Fri, 16 Apr 1999 08:12:42 -0500 (CDT) Date: Fri, 16 Apr 1999 17:12:28 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Re: lynx documentation Message-ID: <19990416171228.A7971@transas.com> References: <199904161015.GAA08951@chass.utoronto.ca> <199904161049.GAA03417@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904161049.GAA03417@shell.clark.net>; from dickey@clark.net on Fri, Apr 16, 1999 at 06:49:50AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 463 Lines: 13 On Fri, Apr 16, 1999 at 06:49:50AM -0400, dickey@clark.net wrote: > this is the developer's mailing list; it's not uncommon to get responses > that point into the CHANGES files. I downloaded lynx2.8.2dev.22.tar.bz2 and looked in CHANGES file. I found nothing. Fortunately, there is doc/ subdirectory, which contains a lot of CHANGES files. :) Yes, this option was introduced on 12-15-93. It's pity noone put this into Lynx_users_guide.html. Cheers, -- Mike From owner-lynx-dev@sig.net Fri Apr 16 09:44:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA28888 for ; Fri, 16 Apr 1999 09:44:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27115; Fri, 16 Apr 1999 08:26:00 -0500 (CDT) From: dickey@clark.net Message-Id: <199904161325.JAA21850@shell.clark.net> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 09:25:57 -0400 (EDT) In-Reply-To: from "Jonathan Lawson " at Apr 16, 99 01:29:27 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1126 Lines: 35 > > > Hi Phil, > > On Fri, 16 Apr 1999 06:49:21 -0400 (EDT) Philip Webb > wrote: > > > anything wider than c 80 chars is likely to be hard on R -> L eye movement, > Just for the sake of information is that 80 chars or 80 > 'chars width' .. The reason I ask is that I use > SvgaTM @ 132x25 (humm ... does that explain my eyes?) > anyhow I haven't seemed to notice any difficulties in > reading (and I tend to read almost everything in html, > these days) ordinary (typeset) text runs more than 80 columns, e.g., in a book. newsprint runs shorter. (I could cite numbers, but people will argue) 80 columns simply happens to correspond to punchcards (because programs were developed on punchcards, the video terminals that were developed to replace them had 80 columns, except for the less common ones used for replacing point-of-sale terminals aka cash registers - those are commonly 40 columns). -- let's not confuse cause (historical legacy) with effect (relative ease of use) > Jonathan Lawson -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 16 10:23:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA30181 for ; Fri, 16 Apr 1999 10:23:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA10349; Fri, 16 Apr 1999 09:07:05 -0500 (CDT) Date: Fri, 16 Apr 1999 15:06:58 +0100 (BST) From: "C.J.LAWSON" X-Sender: fx942976@winnie.pegasus.cranfield.ac.uk To: dickey@clark.net cc: lynx-dev@sig.net Subject: Re: lynx-dev screen widths In-Reply-To: <199904161325.JAA21850@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 988 Lines: 34 Thanks .. that was very informative .. Regards On Fri, 16 Apr 1999 dickey@clark.net wrote: > > > > ordinary (typeset) text runs more than 80 columns, e.g., in a book. > > newsprint runs shorter. > > (I could cite numbers, but people will argue) > > 80 columns simply happens to correspond to punchcards (because programs > were developed on punchcards, the video terminals that were developed > to replace them had 80 columns, except for the less common ones used > for replacing point-of-sale terminals aka cash registers - those are > commonly 40 columns). > > -- let's not confuse cause (historical legacy) with effect (relative ease of use) --- Jonathan Lawson Thermal Processes Unit Department of Applied Energy and Optical Diagnostics School of Mechanical Engineering, Cranfield University, Cranfield, Bedford. UK. email j.lawson@cranfield.ac.uk So teach us to number our days, that we may apply our hearts unto wisdom. Ps 90:12 From owner-lynx-dev@sig.net Fri Apr 16 10:47:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA30921 for ; Fri, 16 Apr 1999 10:47:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA20315; Fri, 16 Apr 1999 09:35:48 -0500 (CDT) Date: Fri, 16 Apr 1999 10:35:49 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev patch: add downloaders to Main Help In-Reply-To: <199904161259.IAA16545@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1268 Lines: 41 On Fri, 16 Apr 1999, Philip Webb wrote: > +
    • WGET > + -- powerful & flexible non-interactive downloader I think it's better to send people directly to the source: *** lhm.mr Fri Apr 16 00:10:06 1999 --- lynx_help_main.html Fri Apr 16 08:53:58 1999 *************** *** 67,72 **** --- 67,83 ----
    • WDG HTML Validator
    +

    Other browsing software:

    + +
      +
    • WGET + -- powerful & flexible non-interactive downloader +
    • cURL + -- non-interactive downloader which supports HTTPS +
    • SNARF + -- small simple 1-file non-interactive downloader +
    +

    Meta-indexes: lists of links

      Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Fri Apr 16 11:03:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA31404 for ; Fri, 16 Apr 1999 11:03:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26248; Fri, 16 Apr 1999 09:52:17 -0500 (CDT) Date: Fri, 16 Apr 1999 10:52:05 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1281 Lines: 26 On Fri, 16 Apr 1999, Klaus Weide wrote: > It would be nice if these two aspects - SOURCE_CACHE setting on the one hand, > auto-invalidation of loaded documents on the other - could be implemented > as independent settings (even if for the user they are coupled into one > option as you sugggest). That would make it easier to change things later. (shrug) It could be done, certainly, and without too much trouble. One would need to separate out the new remembered-settings fields in struct _HText, the new HTdocument_settings_changed() function, and the blurb in mainloop() that calls it. But I can't imagine you could rally much support behind such a change. This sort of setting-sensitive re-parsing really only makes sense when source caching is active; your initial reaction to automatically reloading the document from the server under these conditions is, I imagine, pretty much universal. > I assume the SOURCE_CACHE has its own kind-of validation/no-cache/expired > logic, just not date-based. No, source caching does not affect the overall caching protocol in any way; whatever caching logic Lynx has is applied to the cached document as before, and the attached cached source, if any, is reloaded in the process of reloading the cached document. -sbigham From owner-lynx-dev@sig.net Fri Apr 16 11:37:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA32585 for ; Fri, 16 Apr 1999 11:37:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA07904; Fri, 16 Apr 1999 10:25:06 -0500 (CDT) From: Philip Webb Message-Id: <199904161525.LAA04907@chass.utoronto.ca> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 11:25:02 -0400 (EDT) In-Reply-To: <199904161325.JAA21850@shell.clark.net> from "dickey@clark.net" at Apr 16, 99 09:25:57 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2054 Lines: 44 990416 Thomas Dickey wrote: > 990416 C J Lawson wrote: >> 990416 Philip Webb wrote: >>> anything wider than c 80 chars is likely to be hard on R -> L eye movement >> Just for the sake of information is that 80 chars or 80 'chars width' >> I use SvgaTM @ 132x25: I haven't seemed to notice any difficulties >> in reading (and I tend to read almost everything in html these days) my reason for saying that was that you have to make very definite movements with your eyes L -> R , then go back & be sure you have the beginning of the next line; when you read columns in a newspaper, your eyes move straight down step-by-step, with minimal movement L <-> R. that's why newspapers are printed in columns. > ordinary (typeset) text runs more than 80 columns, e.g., in a book. > newsprint runs shorter. no: i carefully listed the width of books & newspaper columns, counting several lines chosen at random & averaging: see my first message. if you have books or journals which are different, please name them. > 80 columns simply happens to correspond to punchcards > (because programs were developed on punchcards, > the video terminals that were developed to replace them had 80 columns, > except for the less common ones used for replacing point-of-sale terminals > aka cash registers - those are commonly 40 columns. i'm not sure that is accurate: CRT terminals replaced typewriter terminals, which typically had more like 132 columns IIRC. > let's not confuse cause (historical legacy) > with effect (relative ease of use) ease of use here is a function of physiology, not familiarity. anyway, i asked because it's time we had some real information & so far replies have been informative. there's no question people respond to machinery of all kinds in very different ways. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 11:45:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00097 for ; Fri, 16 Apr 1999 11:45:30 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA08987; Fri, 16 Apr 1999 10:28:05 -0500 (CDT) From: Philip Webb Message-Id: <199904161528.LAA05207@chass.utoronto.ca> Subject: Re: lynx-dev Re: lynx documentation To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 11:28:02 -0400 (EDT) In-Reply-To: <19990416171228.A7971@transas.com> from "Michael Sobolev" at Apr 16, 99 05:12:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 700 Lines: 17 990416 Michael Sobolev wrote: > I downloaded lynx2.8.2dev.22.tar.bz2 and looked in CHANGES file. > I found nothing. Fortunately, there is doc/ subdirectory, > which contains a lot of CHANGES files. :) > Yes, this option was introduced on 12-15-93. presumably 1993-12-15 to the non-USA part of the World. > It's pity noone put this into Lynx_users_guide.html. feel free to do so: don't forget your hard hat & safety boots ... -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 11:56:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA00442 for ; Fri, 16 Apr 1999 11:55:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA13169; Fri, 16 Apr 1999 10:39:56 -0500 (CDT) From: Philip Webb Message-Id: <199904161539.LAA06599@chass.utoronto.ca> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 11:39:52 -0400 (EDT) In-Reply-To: from "Klaus Weide" at Apr 16, 99 06:45:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1243 Lines: 24 990416 Klaus Weide wrote: > On Fri, 16 Apr 1999, Philip Webb wrote: >> how difficult would it be to add an Option to vary the screen width, >> incl using the whole of cols 1 - 79 available on a regular screen? > This doesn't belong in lynx, > but in whatever provides lynx with a screen area to draw on. > And it's already there: see your stty command. the fact that Lynx uses only columns 4 - 73 of the standard 79-col screen is hard-coded somewhere in Lynx; it has nothing to do with stty: (1) there's nothing in man stty about setting display width, (2) my (present) editor & the man display both use 79 columns, without any change in tty settings. a lot of users would find it helpful if they could use all 79 columns when using Lynx: i am one of them. moreover, the fact that Lynx restricts users to 70 columns flies in the face of the ideological claim that it should be format-neutral: it was chosen -- apparently arbitrarily -- back in the early days of Lynx. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 12:01:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA00552 for ; Fri, 16 Apr 1999 12:01:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA15515; Fri, 16 Apr 1999 10:46:49 -0500 (CDT) From: Philip Webb Message-Id: <199904161546.LAA07737@chass.utoronto.ca> Subject: Re: lynx-dev patch: add downloaders to Main Help To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 11:46:46 -0400 (EDT) In-Reply-To: from "Ismael Cordeiro" at Apr 16, 99 10:35:49 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 798 Lines: 17 990416 Ismael Cordeiro wrote: >> +
    • WGET > I think it's better to send people directly to the source: >
    • WGET ^^^^^^^^^^^^ ?? anyway, no: i deliberately chose the home site in Hungary; the GNU site is a mirror of some kind, which has less information & may not be fully upto-date. we could list both, but we shouldn't clutter the Main Help Page & people can be expected to check GNU for themselves. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Fri Apr 16 12:18:13 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA01120 for ; Fri, 16 Apr 1999 12:18:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA22760; Fri, 16 Apr 1999 11:07:32 -0500 (CDT) Message-Id: <3.0.3.32.19990416110713.00818c40@collins.mail.iastate.edu> X-Sender: collins@collins.mail.iastate.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 16 Apr 1999 11:07:13 -0500 To: lynx-dev@sig.net From: Gene Collins Subject: lynx-dev Re: In-Reply-To: <199904161058.FAA02913@roadrunner.sig.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1352 Lines: 38 Jim, you don't want the quotes (") around the directory path. I just use the lynx environment variable lynx_save_space. You can use this by putting a set command in your autoexec.bat file like this: set lynx_save_space=c:\download\ Come to think of it, you might try inclucing a trailing backslash (\) at the end of your save path in the options page. On last suggestion: lynx uses the temp and tmp environment variables to determine where it should place it's temporary files. Be sure this variable is not set to the same place you want to use as your default save space. Gene Collins collins@iastate.edu At 05:58 AM 4/16/99 -0500, you wrote: >I have a question regarding the SAVE_SPACE item in the lynx.cfg >file. i am running the win32 version of lynx on windows nt 4.0 >and have been wanting to download files and save them using the >"Save to Disk" feature. But I am not sure what to place in the >"SAVE_SPACE:" option in lynx.cfg. > >currently i have "drive:\temp". i have tried "drive:/temp" also. >neither of them seem to work. what form do i have to put the >path to have this work correctly? > >thank you for your help. > >jim >________________________________________________________ >NetZero - We believe in a FREE Internet. Shouldn't you? >Get your FREE Internet Access and Email at >http://www.netzero.net/download.html > From owner-lynx-dev@sig.net Fri Apr 16 12:27:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA01395 for ; Fri, 16 Apr 1999 12:27:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA26323; Fri, 16 Apr 1999 11:17:23 -0500 (CDT) From: dickey@clark.net Message-Id: <199904161617.MAA19342@shell.clark.net> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Fri, 16 Apr 1999 12:17:18 -0400 (EDT) In-Reply-To: <199904161525.LAA04907@chass.utoronto.ca> from "Philip Webb " at Apr 16, 99 11:25:02 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 317 Lines: 10 > i'm not sure that is accurate: CRT terminals replaced typewriter terminals, > which typically had more like 132 columns IIRC. no - 80 (132 column terminals weren't common until the early 80's -- around the time that punchcards went away) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Apr 16 13:58:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA04234 for ; Fri, 16 Apr 1999 13:58:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA25656; Fri, 16 Apr 1999 12:45:27 -0500 (CDT) X-Mailer: exmh version 2.0.2 2/24/98 To: lynx-dev@sig.net cc: Steven Sakata Subject: Re: lynx-dev passing the authentication login/password via a file? In-reply-to: Your message of "Thu, 15 Apr 1999 17:50:13 PDT." X-Face: 1(qSF/Pzjzp_euFvSOGi~qv|,z-.>Q*?[LOn2!@{QS.fPWa8nI*(V5Fy$Y*zzCTCK2xM6Wyli/Rm1zyxw^Y{ From: Dick Wesseling Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 725 Lines: 22 dkaufman@rahul.net said: > On Thu, 15 Apr 1999, Steven Sakata wrote: > > > We are using "lynx" on a UNIX box to download files from a secure > > site. We currently pass the login and password using the "-auth" > > argument. It works well. However, my concern is that while it is > > running, any user can do a "ps" > I see two solutions to this problem. A third solition would be to change the commandline displayed by "ps" if a -auth parameter is present. The trouble is that: a) there is a race condition (but exploit is unlikely?) b) this is system dependent. If anyone is interested, you can look into the Sendmail sources to see how it deals with changing the output of "ps" on the various flavours of unix. From owner-lynx-dev@sig.net Fri Apr 16 15:00:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA06448 for ; Fri, 16 Apr 1999 15:00:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA16713; Fri, 16 Apr 1999 13:51:45 -0500 (CDT) Date: Fri, 16 Apr 1999 22:50:35 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: Re: lynx-dev Re: lynx documentation Message-ID: <19990416225035.A19034@transas.com> References: <19990416171228.A7971@transas.com> <199904161528.LAA05207@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904161528.LAA05207@chass.utoronto.ca>; from Philip Webb on Fri, Apr 16, 1999 at 11:28:02AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 236 Lines: 8 On Fri, Apr 16, 1999 at 11:28:02AM -0400, Philip Webb wrote: > > It's pity noone put this into Lynx_users_guide.html. > > feel free to do so: don't forget your hard hat & safety boots ... ... and a good manual of English. :) -- Mike From owner-lynx-dev@sig.net Fri Apr 16 15:05:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA06769 for ; Fri, 16 Apr 1999 15:05:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA16691; Fri, 16 Apr 1999 13:51:42 -0500 (CDT) From: Bela Lubkin Date: Fri, 16 Apr 1999 11:50:58 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths Message-ID: <9904161150.aa27878@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3149 Lines: 67 Philip Webb wrote: > some people have claimed -- recently & earlier -- > that preformatting documentation with
      or
      ...
      > causes problems for screens wider/narrower than the traditional 79 chars: > BL displayed text 12 (rather far-fetched) & 50 (more realistic) chars wide, > the latter causing awkward line-wrapping with
      's at c 65 chars. Do you disagree that such "awkward" line wrapping actually occurs when the length of each "line" is artificially supplied? > anything wider than c 80 chars is likely to be hard on R -> L eye movement, You may think so. Obviously, however, anyone who has deliberately chosen to use a wider screen does *not* think so and will not appreciate your beliefs being imposed. > so i have a question & a (repeat) suggestion: > how many lynx-devers regularly use Lynx with a screen width > noticeably more/less than 79 chars & in what contexts? Depending on the capabilities of the video board & monitor, I typically use 100x45 or 120x45 displays. Lynx works beautifully in those sizes. I occasionally also pop up a small-font-small-grid window in which to browse documentation -- making it as small as possible to consume less screen real estate. I've used Lynx in 45 or 50 column windows, though not frequently. Text which is forcibly wrapped to ~60 columns, as your
      -laden documentation patches, looks vaguely wrong on an 80-column display. It looks as disturbingly wrong on a 120-column display as my 12-column example did to you. > how difficult would it be to add an Option to vary the screen width, > incl using the whole of cols 1 - 79 available on a regular screen? You already have the option of running Lynx within a window of previously varied size. Lynx ought to also reach sanely when the size of the window it's in is changed out from under it. I haven't tried that in a while; last I remember, there were patches supplied which made it work "ok" on some combinations of curses library & OS, but which still left screen glitches even on those. I do agree that the normal margins Lynx uses are wasteful and represent just that sort of imposed preference that I object to above. They should be tunable user preferences -- left_margin_cols and right_margin_cols. > there might also be an Option to suppress
      , if it's causing problems. But
      has a perfectly useful and important role elsewhere. We only want to suppress *abuse* of
      . You pointed out a number of places in the existing Lynx doc which use
      .  I looked at them.  All but one were carefully laid out visual
      tables -- things like keystroke maps.  Some of those could probably have
      been better expressed as ordered lists, allowing Lynx to do the
      formatting.  One was an image of the "new" HTML options page -- that
      would work better as the actual HTML, modified so that the various popup
      options and other fields are represented by inactive text showing a
      "normal" choice.  Then the example options page would look as much as
      possible like the real one that the reader would see if he hit O.
      
      But not a single one was just someone's plain text which he insisted be
      wrapped Just So.
      
      >Bela<
      
      From owner-lynx-dev@sig.net  Fri Apr 16 15:18:49 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA07150
      	for ; Fri, 16 Apr 1999 15:18:47 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA23027; Fri, 16 Apr 1999 14:09:52 -0500 (CDT)
      From: mattack@area.com
      Date: Fri, 16 Apr 1999 12:09:44 -0700 (PDT)
      X-Sender: mattack@vax
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      In-Reply-To: <199904161539.LAA06599@chass.utoronto.ca>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 729
      Lines: 17
      
      On Fri, 16 Apr 1999, Philip Webb wrote:
      >990416 Klaus Weide wrote: 
      >> On Fri, 16 Apr 1999, Philip Webb wrote:
      >>> how difficult would it be to add an Option to vary the screen width,
      >>> incl using the whole of cols 1 - 79 available on a regular screen?
      >> This doesn't belong in lynx,
      >> but in whatever provides lynx with a screen area to draw on.
      >> And it's already there: see your stty command.
      > 
      >the fact that Lynx uses only columns 4 - 73 of the standard 79-col screen
      
      This is very, to use a technical term, YUCKY.
      
      Why is Lynx _wasting_ characters of my 80 character wide window (or at home,
      screen)?  I hope this is changed into something that is configurable.  I'd
      rather see it use the whole width of the screen.
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 15:59:29 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA08475
      	for ; Fri, 16 Apr 1999 15:59:28 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA02091; Fri, 16 Apr 1999 14:37:59 -0500 (CDT)
      Date: Thu, 15 Apr 1999 00:51:21 +0500 (SAMST)
      From: Vlad Harchev 
      X-Sender: hvv@localhost.localdomain
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 10636
      Lines: 294
      
      On Wed, 14 Apr 1999, Vlad Harchev wrote:
      
      >  IMO it would be good if the 'include' command had the list of settings that
      > can be specified in included file. So admins can specify 
      > 'include:~/.lynx/colors:COLOR' 
      > 'include:~/.lynx/keymap:KEYMAP'
      > 'include:~/.lynx/viewers:VIEWER'
      > 
      >  safely - and be sure that no critical options were altered by those files.
      > The suggested syntax is 
      > include:[:[* ] ]
      > more samples:
      > include:~/.lynx/rc:COLOR KEYMAP VIEWER SUFFIX
      > include:/usr/local/lib/lynx-cfg.part: #all settings can be changed
      > 
      >  More brave approach:
      >  Make ~/.lynxrc to be included by lynx.cfg (it's syntax must be changed to one
      > of lynx.cfg), with a list of options it can contain in the 'include' line. As
      > I understand, with  LP's patch lynx.cfg can be edited at runtime and reloaded
      >  in the same session - such feature as editing options specified in .lynxrc
      >  at runtime is not the major privelege (or feature) of .lynxrc. So, a huge
      > section of code ~32KB can be removed when using this approach. 
      >  In present state, users with paranoid sysadm were to live with colors s/he
        Here is a patch that implements this functionality (except brave approach).
       It works as described. Features:
      *It prints warnings to stderr about unknown options specified in the list of
      allowed options in include command. When 'o'->'lynx.cfg'->'RELOAD THE CHANGES'
      is activated, these warnings are also printed on stderr - so the screen will
      be corrupted if lynx.cfg and included are incorrect. 
      * Only options, allowed for a given file are printed in 
        'o'->'lynx.cfg'->'RELOAD THE CHANGES'.
      * Fully backward compatible - lines of the form
      	include:filename
        will work as they did( ie if the list of allowed options is not specified,
        then the included file can use the same set of options, as the file that
        contained that 'include' command).
      * A funny and may be powerful feature - if you wish to allow included file to
        include others, you must specify 'include' in the list of allowed options.
        Sample:
      	  include:~/.lynx/suffixes:INCLUDE SUFFIX
        so thet user will be able to use 'include' command in '~/.lynx/suffixes' 
        (otherwise included file will be unable to include anything)
      * Option sets are ANDed. If file lynx.cfg contains:
        	include:/usr/lib/lynx.cfg.0:COLOR SUFFIX VIEWER INCLUDE
       and /usr/lib/lynx.cfg.0 contains
              include:/usr/lib/lynx.cfg.1:SUFFIX VIEWER INCLUDE STARTFILE HELPFILE
       then /usr/lib/lynx.cfg.1 can use the following options:
      	SUFFIX VIEWER INCLUDE
      
      NOTE: May be it will be good if the new lynx distributions will use directory
      ~/.lynx as the place for .lynxrc (so it can be called simply 'rc' - ie
      ~/.lynx/rc) and all bookmarks, cookies are also placed in this dir. Also we
      can provide as set of preconfigured keymaps (emacs,pc,etc), and add commented
      lines that contain 'include' of each of such file - so sysadm have only to
      uncomment the line s/he wishes (or the user have to copy the piece s/he likes
      in the ~/.lynx under general name). Or we can insert the following lines in
      lynx.cfg:
      
      #the following line includes user keymap. To users: put the keymap
      #(one of the distribution's keymap -  emacs-keymap, vi-keymap, foo-keymap, or
      # composed by yourself) to the ~/.lynx/keymap
      include:~/.lynx/keymap:KEYMAP INCLUDE
      
       Midnight Commander also uses approach of putting all cfg files and caches
      in '~/.mc' . Here is a 'ls ~/.mc': history hotlist ini tree
      
      PS: It will be good if someone documented the 'include' command. As I
      remember, even the description of the plain 'include' is absent in the docs.
      PS2: I checked this patch with original dev22 with 'enable' and 'disable' of 
      config-info.
      
       Best regards,
        -Vlad
      
      
      diff -ruP dev22-orig/src/LYReadCFG.c lynx-2.8.2dev22-fixed/src/LYReadCFG.c
      --- lynx-2.8.2dev22-orig/src/LYReadCFG.c	Tue Apr 13 15:01:15 1999
      +++ lynx-2.8.2dev22-fixed/src/LYReadCFG.c	Thu Apr 15 00:15:27 1999
      @@ -443,7 +443,7 @@
       }
       #endif /* USE_COLOR_TABLE */
       
      -#define MAX_LINE_BUFFER_LEN	501
      +#define MAX_LINE_BUFFER_LEN	1501
       
       typedef int (*ParseFunc) PARAMS((char *));
       
      @@ -1214,14 +1214,32 @@
           }
       }
       
      +#define NOPTS_ ( (sizeof Config_Table)/(sizeof Config_Table[0]) - 1 )
      +typedef BOOL (optidx_set_t) [ NOPTS_ ];   
      + /* if elt is FALSE, then it's allowed in the current file*/
      +
      +#define optidx_set_AND(r,a,b) \
      +    {\
      +        int i1;\
      +        for (i1=0;i1%s\n\n", name, url, cp1);
       		fprintf(fp0, "	  #<begin  %s>\n", cp1);
      +            };
      +#endif
      +            
      +            if (p1) {    
      +                while (1) {    
      +                    Config_Type *tbl;
      +                    char ch;
      +                    char* name;
      +                    
      +                    while (*p1 && isspace(*p1)) ++p1;
      +                    if (!*p1) break;
      +                    name=p1;
      +                    p2=p1+1;
      +                    while (*p2 && !isspace(*p2)) ++p2;
      +                    savechar=*p2;                    
      +                    *p2=0;
      +
      +            	    tbl = Config_Table;
      +	            ch = TOUPPER(*name);
      +                    
      +        	    while (tbl->name != 0) {
      +	                char ch1 = tbl->name[0];
      +
      +	                if ((ch == TOUPPER(ch1))
      +		            && (0 == strcasecomp (name, tbl->name)))
      +		        break;
      +
      +	                tbl++;
      +	            };
      +
      +        	    if (tbl->name == 0) {
      +                        if (fp0 == NULL)
      +	                    fprintf (stderr, "unknow option name %s in the list of"
      +                            " allowed optnames in %s\n",name,cfg_filename);
      +                        /*FIXME - can do something wiser if generating the 
      +                        html from lynx.cfg */    
      +	            } else {
      +                        int i;
      +                        if (!any_optname_found) {                            
      +                            any_optname_found=TRUE;
      +                            for(i=0;i. Option names will be and uppercased. 
      +            FIXME: uppercasing option names can be considered redundant. */
      +            
      +            if (fp0 != 0  &&  !LYRestricted && resultant_set) {
      +                char buf[2000];
      +                int i;
      +                
      +                fprintf(fp0,"	  Options allowed in this file:\n");
      +                for (i=0;i; Fri, 16 Apr 1999 16:51:39 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA19283; Fri, 16 Apr 1999 15:31:00 -0500 (CDT)
      Date: Fri, 16 Apr 1999 13:30:50 -0700
      From: David Combs 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      Message-ID: <19990416133050.A29828@netcom16.netcom.com>
      References: <199904161049.GAA09644@chass.utoronto.ca>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <199904161049.GAA09644@chass.utoronto.ca>; from Philip Webb on Fri, Apr 16, 1999 at 06:49:21AM -0400
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1624
      Lines: 49
      
      On Fri, Apr 16, 1999 at 06:49:21AM -0400, Philip Webb wrote:
      
      > 
      > anything wider than c 80 chars is likely to be hard on R -> L eye movement,
      > which is presumably why magazines & newspapers -- for quick reading --
      > divide their texts into columns much narrower than 80 chars;
      > Lynx in fact uses 70 chars (cols 4 - 73) out of the 79 available.
      > 
      
      
      I sure don't want ANYONE telling me what width I have to read at!
      
      It's MY computer, MY (expensive) screen, and MY decision what
      to do with it!
      
      BULLSHIT(*) to "anything wider than 80 chars is likely to be
      hard on L -> R eye movement"; that's what I say.
      
      I myself LOVE running on the internet with screen width set to
      132.  I find it MUCH easier to scan large amounts of written
      material.
      
      When I want to print-to-file something that I want to later
      print on the laser-printer, I simply set cols to 79 (via
      ^Z then doing it), then when I do fg, wonderful lynx 
      realizes this change, and a ^R reformats the page, and
      *that's* what I print-to-file.
      
      ---
      
      The whole idea of html, I thought, was that it was
      screen-width INDEPENDENT.  And Lynx has so far made this
      very easy to accomplish.
      
      As far as I am concerned, taking away this freedom
      -- especially on a document prepared FOR lynx -- is
      SO AWFUL -- well, I'm just totally bewildered that this
      is even a subject for discussion on THIS group.  :-(
      
      ---
      
      Sorry for the flaming attitude here, but any discussion
      that might take away MY FREEDOM to do what I want, 
      *especially* on a computer, *especially* on a non $ms
      program, *especially* on UNIX(tm)!!! -- just drives me
      (temporarily, I hope) crazy.
      
      David
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 17:02:07 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10389
      	for ; Fri, 16 Apr 1999 17:02:05 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA24381; Fri, 16 Apr 1999 15:46:23 -0500 (CDT)
      Date: Fri, 16 Apr 1999 13:46:17 -0700
      From: David Combs 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      Message-ID: <19990416134617.B29828@netcom16.netcom.com>
      References:  <199904161325.JAA21850@shell.clark.net>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <199904161325.JAA21850@shell.clark.net>; from dickey@clark.net on Fri, Apr 16, 1999 at 09:25:57AM -0400
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1455
      Lines: 36
      
      On Fri, Apr 16, 1999 at 09:25:57AM -0400, dickey@clark.net wrote:
      >   
      > 80 columns simply happens to correspond to punchcards (because programs
      > were developed on punchcards, the video terminals that were developed
      > to replace them had 80 columns, except for the less common ones used
      > for replacing point-of-sale terminals aka cash registers - those are
      > commonly 40 columns).
      > 
      
      Yes, having been programming since 1969, on non-ibm systems,
      but knowing the kind GARBAGE produced by ibm (eg vm/cms,
      where you couldn't even open a file from a running program,
      so unlike from any other os for other machines (non ibm)) --
      having ANYTHING that limits me be via that awful, stupid
      at almost anything but marketing (thanks to ibm's stupidy we now have
      M$ running the world) --
      
      I'd almost like to abolish "80" from the system of integers.
      
      (Likewise ebdcic or however you spell it -- look at the
      alpha codes, and you see the exact same splitting of
      a-z into three groups matching the presence or absence
      of the sense and mark holes being punched out on the
      "ibm punched card".  Beyond belief.  And they STILL use
      that system now, 30 years after we went to the moon!)
      
      ---
      
      Again, sorry for the flaming attitude.  I guess you can
      tell that I had a run-in with ibm vm/cms long ago, and
      the impact has never left.  Thank god for dec 10, 20,
      (especially with a derivative of Kernighan "software tools"),
      vax with unix, and best of all thus far, sun!
      
      david
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 17:11:49 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA10675
      	for ; Fri, 16 Apr 1999 17:11:47 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA27688; Fri, 16 Apr 1999 15:55:45 -0500 (CDT)
      Date: Fri, 16 Apr 1999 13:55:21 -0700
      From: David Combs 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      Message-ID: <19990416135521.C29828@netcom16.netcom.com>
      References: <199904161049.GAA09644@chass.utoronto.ca> <19990416133050.A29828@netcom16.netcom.com>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <19990416133050.A29828@netcom16.netcom.com>; from David Combs on Fri, Apr 16, 1999 at 01:30:50PM -0700
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 749
      Lines: 24
      
      On Fri, Apr 16, 1999 at 01:30:50PM -0700, David Combs wrote:
      > 
      > BULLSHIT(*) to "anything wider than 80 chars is likely to be
      > hard on L -> R eye movement"; that's what I say.
      > 
      
      Re the "(*)", I forgot to put down at the bottom
      that word is evidently one of a nearby town's mayor's
      favorites.
      
      Who?  Who else but Rudi Guiliani, current mayor of
      New York City, soon maybe :-( U.S. Senator, or perhaps
      (they say he really wants the job) Attorney General
      of the U.S. (double :-(  )).
      
      A local radio station, wbai (of the pacifica group)
      repeatedly plays a tape of him at the 1992 "police riot"
      at City Hall (before he got elected), when he shouts
      it out to his admiring crowd of police.
      
      (Well, at least the trains (subways) run on time...)
      
      David
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 20:03:36 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA15349
      	for ; Fri, 16 Apr 1999 20:03:34 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA11343; Fri, 16 Apr 1999 18:39:05 -0500 (CDT)
      Date: Fri, 16 Apr 1999 19:34:43 -0400 (EDT)
      From: John Bley 
      To: lynx-dev@sig.net
      Subject: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 6260
      Lines: 198
      
      * Fix --disable-trace, chop more unneeded #includes (John Bley)
      
      Strange:
      Turning trace off at compile-time transforms all instances of
      CTRACE(...)
        to 
      if (0) fprintf(...)
      
      But the string literals in the CTRACE calls still wind up in the binaries 
      for me.  (Tried this with both Sun's cc and gcc).  This is like 30k worth 
      of string literal over the whole lynx source.  It's very disturbing.
      
      -- 
      John Bley - jbb6@acpub.duke.edu
      Duke '99 - English/Computer Science
        Since English is a mess, it maps well onto the problem space,
        which is also a mess, which we call reality.     - Larry Wall
      
      diff -Burp lynx2-8-2/WWW/Library/Implementation/HTUtils.h lynx2-8-2-patched/WWW/Library/Implementation/HTUtils.h
      --- lynx2-8-2/WWW/Library/Implementation/HTUtils.h	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/WWW/Library/Implementation/HTUtils.h	Fri Apr 16 19:02:34 1999
      @@ -122,13 +122,13 @@ Debug message control.
       
        */
       
      -#ifdef DEBUG
      +#ifdef NO_LYNX_TRACE
      +#define TRACE 0
      +#define PROGRESS(str) /* nothing for now */
      +#else
       #define TRACE (WWW_TraceFlag)
       #define PROGRESS(str) printf(str)
               extern int WWW_TraceFlag;
      -#else
      -#define TRACE 0
      -#define PROGRESS(str) /* nothing for now */
       #endif
       
       /*
      diff -Burp lynx2-8-2/src/HTFWriter.c lynx2-8-2-patched/src/HTFWriter.c
      --- lynx2-8-2/src/HTFWriter.c	Thu Mar  4 05:39:45 1999
      +++ lynx2-8-2-patched/src/HTFWriter.c	Fri Apr 16 18:49:50 1999
      @@ -23,7 +23,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYCgi.c lynx2-8-2-patched/src/LYCgi.c
      --- lynx2-8-2/src/LYCgi.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYCgi.c	Fri Apr 16 18:49:50 1999
      @@ -41,7 +41,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       
      diff -Burp lynx2-8-2/src/LYCharUtils.c lynx2-8-2-patched/src/LYCharUtils.c
      --- lynx2-8-2/src/LYCharUtils.c	Wed Mar 17 22:17:11 1999
      +++ lynx2-8-2-patched/src/LYCharUtils.c	Fri Apr 16 18:49:50 1999
      @@ -29,7 +29,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYClean.c lynx2-8-2-patched/src/LYClean.c
      --- lynx2-8-2/src/LYClean.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYClean.c	Fri Apr 16 18:49:50 1999
      @@ -5,7 +5,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYCookie.c lynx2-8-2-patched/src/LYCookie.c
      --- lynx2-8-2/src/LYCookie.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYCookie.c	Fri Apr 16 18:49:50 1999
      @@ -59,7 +59,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYEdit.c lynx2-8-2-patched/src/LYEdit.c
      --- lynx2-8-2/src/LYEdit.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYEdit.c	Fri Apr 16 18:49:50 1999
      @@ -5,7 +5,6 @@
       #include 
       #include 
       #include 
      -#include 
       #ifdef VMS
       #include 
       #endif /* VMS */
      diff -Burp lynx2-8-2/src/LYHistory.c lynx2-8-2-patched/src/LYHistory.c
      --- lynx2-8-2/src/LYHistory.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYHistory.c	Fri Apr 16 18:49:50 1999
      @@ -11,7 +11,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       
      diff -Burp lynx2-8-2/src/LYList.c lynx2-8-2-patched/src/LYList.c
      --- lynx2-8-2/src/LYList.c	Thu Mar  4 05:39:45 1999
      +++ lynx2-8-2-patched/src/LYList.c	Fri Apr 16 18:49:50 1999
      @@ -11,7 +11,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       
      diff -Burp lynx2-8-2/src/LYMap.c lynx2-8-2-patched/src/LYMap.c
      --- lynx2-8-2/src/LYMap.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYMap.c	Fri Apr 16 18:49:50 1999
      @@ -15,7 +15,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYReadCFG.c lynx2-8-2-patched/src/LYReadCFG.c
      --- lynx2-8-2/src/LYReadCFG.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYReadCFG.c	Fri Apr 16 18:49:50 1999
      @@ -17,7 +17,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYShowInfo.c lynx2-8-2-patched/src/LYShowInfo.c
      --- lynx2-8-2/src/LYShowInfo.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYShowInfo.c	Fri Apr 16 18:49:51 1999
      @@ -4,12 +4,10 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/LYStyle.c lynx2-8-2-patched/src/LYStyle.c
      --- lynx2-8-2/src/LYStyle.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/LYStyle.c	Fri Apr 16 18:49:51 1999
      @@ -4,7 +4,6 @@
        */
       #include 
       #include 
      -#include 
       #include 
       
       #include 
      diff -Burp lynx2-8-2/src/LYUpload.c lynx2-8-2-patched/src/LYUpload.c
      --- lynx2-8-2/src/LYUpload.c	Wed Feb 17 09:29:33 1999
      +++ lynx2-8-2-patched/src/LYUpload.c	Fri Apr 16 18:49:51 1999
      @@ -21,7 +21,6 @@
       #include 
       #include 
       #include 
      -#include 
       #include 
       #include 
       #include 
      diff -Burp lynx2-8-2/src/UCdomap.c lynx2-8-2-patched/src/UCdomap.c
      --- lynx2-8-2/src/UCdomap.c	Tue Apr 13 05:39:16 1999
      +++ lynx2-8-2-patched/src/UCdomap.c	Fri Apr 16 18:49:51 1999
      @@ -25,7 +25,6 @@
       #include 
       #include 
       #include 
      -#include 
       
       #include 
       
      
      From owner-lynx-dev@sig.net  Fri Apr 16 21:48:09 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA18308
      	for ; Fri, 16 Apr 1999 21:48:05 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA01646; Fri, 16 Apr 1999 20:34:19 -0500 (CDT)
      Date: Fri, 16 Apr 1999 18:34:14 -0700 (PDT)
      From: Doug Kaufman 
      X-Sender: dkaufman@waltz
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Re: 
      In-Reply-To: <3.0.3.32.19990416110713.00818c40@collins.mail.iastate.edu>
      Message-Id: 
      Mime-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 614
      Lines: 17
      
      On Fri, 16 Apr 1999, Gene Collins wrote:
      
      > set lynx_save_space=c:\download\
      > ... 
      > On last suggestion: lynx uses the temp and tmp environment variables to
      > determine where it should place it's temporary files.  Be sure this
      
      The actual variables used are LYNX_SAVE_SPACE, TEMP, and TMP. If you use
      lowercase variables, they will be ignored if uppercase variables are
      already set. This doesn't apply to plain DOS, where all environment
      variables are uppercased by the operating system.
                                     Doug
      __
      Doug Kaufman
      Internet: dkaufman@rahul.net (preferred)
      	  bn900@cleveland.freenet.edu
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 22:13:54 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA19029
      	for ; Fri, 16 Apr 1999 22:13:53 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA06373; Fri, 16 Apr 1999 21:01:04 -0500 (CDT)
      Date: Fri, 16 Apr 1999 19:00:57 -0700 (PDT)
      From: Doug Kaufman 
      X-Sender: dkaufman@waltz
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg
      In-Reply-To: 
      Message-Id: 
      Mime-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 581
      Lines: 15
      
      On Thu, 15 Apr 1999, Vlad Harchev wrote:
      
      > NOTE: May be it will be good if the new lynx distributions will use directory
      > ~/.lynx as the place for .lynxrc (so it can be called simply 'rc' - ie
      > ~/.lynx/rc) and all bookmarks, cookies are also placed in this dir. Also we
      
      This would break lynx for DOS or any other system that doesn't allow
      filenames to start with a ".". That is one of the reasons why the
      names of the files are configurable in lynx.cfg.
                                   Doug
      __
      Doug Kaufman
      Internet: dkaufman@rahul.net (preferred)
      	  bn900@cleveland.freenet.edu
      
      
      From owner-lynx-dev@sig.net  Fri Apr 16 23:54:37 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA21851
      	for ; Fri, 16 Apr 1999 23:54:36 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA24659; Fri, 16 Apr 1999 22:46:37 -0500 (CDT)
      From: Philip Webb 
      Message-Id: <199904170346.XAA19204@chass.utoronto.ca>
      Subject: Re: lynx-dev screen widths
      To: lynx-dev@sig.net
      Date: Fri, 16 Apr 1999 23:46:39 -0400 (EDT)
      In-Reply-To: <19990416135521.C29828@netcom16.netcom.com> from "David Combs" at Apr 16, 99 01:55:21 pm
      X-Mailer: ELM [version 2.4 PL24]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 875
      Lines: 20
      
      990416 David Combs wrote: 
      > BULLSHIT(*) Re the "(*)", I forgot to put down at the bottom
      > that word is evidently one of a nearby town's mayor's favorites.
      > Who else but Rudi Guiliani, current mayor of New York City
       
      this is getting off-topic, but the word occurs occasionally
      not only in the very serious Financial Times (London),
      but even in the very family-oriented Toronto Star.
      
      as for `flames', they are surely personal attacks:
      a vigorous defense of your own preferences is not a flame.
      
      i asked my question because i thought it was time to do a survey:
      so far, the answers are quite informative.
      
      -- 
      ========================,,============================================
      SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
      ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
      TRANSIT    `-O----------O---'  University of Toronto
      
      From owner-lynx-dev@sig.net  Sat Apr 17 02:14:19 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA25861
      	for ; Sat, 17 Apr 1999 02:14:18 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA11807; Sat, 17 Apr 1999 01:02:27 -0500 (CDT)
      Date: Sat, 17 Apr 1999 01:02:23 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      In-Reply-To: <199904161539.LAA06599@chass.utoronto.ca>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1035
      Lines: 24
      
      On Fri, 16 Apr 1999, Philip Webb wrote:
      
      > the fact that Lynx uses only columns 4 - 73 of the standard 79-col screen
      > is hard-coded somewhere in Lynx; it has nothing to do with stty:
      > (1) there's nothing in  man stty  about setting display width,
      > (2) my (present) editor & the man display both use 79 columns,
      > without any change in tty settings.  a lot of users would find it helpful
      > if they could use all 79 columns when using Lynx: i am one of them.
      
      See DefaultStyle.c.
      
      > moreover, the fact that Lynx restricts users to 70 columns flies
      > in the face of the ideological claim that it should be format-neutral:
      > it was chosen -- apparently arbitrarily -- back in the early days of Lynx.
      
      "Back in the early days of Lynx" (or of the WWW Library), these things
      were put in a separate source file; so the rest of the code is
      (mostly) format-neutral in your sense.  The idea of style sheets
      isn't a new one.  If someone implements (changeable) style sheets for
      lynx, that's where changing the margins would belong.
      
         Klaus
      
      
      
      From owner-lynx-dev@sig.net  Sat Apr 17 02:45:44 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26799
      	for ; Sat, 17 Apr 1999 02:45:43 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA14954; Sat, 17 Apr 1999 01:38:00 -0500 (CDT)
      Date: Sat, 17 Apr 1999 01:37:57 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 806
      Lines: 29
      
      On Fri, 16 Apr 1999, John Bley wrote:
      
      > * Fix --disable-trace, chop more unneeded #includes (John Bley)
      
      Could you explain why --disable-trace needed fixing?  It seems to
      me you change doesn't really change anything - you now just test
      for NO_LYNX_TRACE directly rather than indirectly (through DEBUG),
      or am I missing something?
      
      
      > Strange:
      > Turning trace off at compile-time transforms all instances of
      > CTRACE(...)
      >   to 
      > if (0) fprintf(...)
      
      Are you really compiling with -O[>=2] and without -g?
      
        ---
      
      For curiosity's sake, how do you determine which #includes are
      unneeded?  If you don't test for all possible combinations of 
      flags and macros that might control conditional compilation, how
      can you be sure an #include is really unnecessary?  Or do you
      examine everything by hand?
      
      
       Klaus
      
      
      From owner-lynx-dev@sig.net  Sat Apr 17 02:46:35 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26809
      	for ; Sat, 17 Apr 1999 02:46:34 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA15048; Sat, 17 Apr 1999 01:39:03 -0500 (CDT)
      Date: Sat, 17 Apr 1999 02:17:42 -0400
      From: Chuck Martin 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      Message-ID: <19990417021742.B8131@delta.Nexus.of.Obsolescence>
      Mail-Followup-To: lynx-dev@sig.net
      References:  <199904161539.LAA06599@chass.utoronto.ca>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <199904161539.LAA06599@chass.utoronto.ca>; from Philip Webb on Fri, Apr 16, 1999 at 11:39:52AM -0400
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2634
      Lines: 53
      
      On Fri, Apr 16, 1999 at 11:39:52AM -0400, Philip Webb wrote:
      >  
      > the fact that Lynx uses only columns 4 - 73 of the standard 79-col screen
      > is hard-coded somewhere in Lynx; it has nothing to do with stty:
      
      Lynx does in fact use all of the columns.  It just indents certain things,
      normal text being one of them, so most of a document gets indented three
      spaces.
      
      > (2) my (present) editor & the man display both use 79 columns,
      > without any change in tty settings.  a lot of users would find it helpful
      > if they could use all 79 columns when using Lynx: i am one of them.
      
      I used to be one of them, but I changed my mind once I found out what
      lynx is really doing, because those three spaces aren't really wasted.
      They actually add information.  Look at src/DefaultStyle.c in the source
      tree to see what's happening.  Different content types are indented by
      differing amounts of space, and if you familiarize yourself with these,
      you can tell at a glance what the amount of indentation means.
      
      For example, H1 headings are centered (presumably because they're normally
      used for titles), but H2 through H6 are indented 0, 2, 4, 6, and 8 spaces,
      respectively.  A BLOCKQUOTE is indented five spaces.  This makes it very
      easy to differentiate headings and subheadings from normal text and
      BLOCKQUOTEs, since the headings are indented an even number of spaces,
      while the normal text and BLOCKQUOTEs are indented an odd number of spaces.
      It also helps you to differentiate the differentiate the different levels
      of headings from each other without having to look at the HTML source.
      
      If you really want to remove the indentation from normal text, just edit
      src/DefaultStyle.c and find this:
      
      PRIVATE HTStyle HTStyleNormal = {
              0,  "Normal", "P",
              HT_FONT, 1, HT_BLACK,           0, 0,
              3, 3, 6, HT_LEFT,               1, 0,   tabs_8,
              YES, YES, 1, 0,                 0 };
      
      Change the 3's in the fourth line to 0's, and recompile.  This will make
      it do what you're asking, but please don't change that in the distribution.
      I like it the way it is.
      
      You also suggested (or someone did) making that a configurable option,
      but if you look through that file, you'll see that there are *many* of
      these structures.  Are we to make them all configurable from lynx.cfg or
      the options page?  If not, which ones should be configurable?  I think
      it wouldn't make sense to do that.  Three spaces at the beginning of each
      line seems to be a small price to pay for the information it provides.
      Maybe we should instead consider documenting this behavior so that users
      can better understand what they're looking at.
      
      Chuck
      
      
      From owner-lynx-dev@sig.net  Sat Apr 17 02:46:53 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA26827
      	for ; Sat, 17 Apr 1999 02:46:53 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA15040; Sat, 17 Apr 1999 01:39:01 -0500 (CDT)
      Date: Sat, 17 Apr 1999 02:28:31 -0400
      From: Chuck Martin 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev screen widths
      Message-ID: <19990417022831.C8131@delta.Nexus.of.Obsolescence>
      Mail-Followup-To: lynx-dev@sig.net
      References: <199904161525.LAA04907@chass.utoronto.ca> <199904161617.MAA19342@shell.clark.net>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.4i
      In-Reply-To: <199904161617.MAA19342@shell.clark.net>; from dickey@clark.net on Fri, Apr 16, 1999 at 12:17:18PM -0400
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 688
      Lines: 15
      
      On Fri, Apr 16, 1999 at 12:17:18PM -0400, dickey@clark.net wrote:
      > 
      > no - 80 (132 column terminals weren't common until the early 80's -- around
      > the time that punchcards went away)
      
      I don't know about terminals, but I believe 132 column *printers* were
      very much the norm in the 70's.  Since terminals were primarily for input,
      and input was originally done with punched cards, it was logical to make
      the terminals 80 columns, but printers were for output, and there was no
      reason to duplicate the width of the punched card.  (Yes, I know that the
      terminals were also for output, but that was mostly for the programmer's
      benefit--reports and such generally used 132 columns.)
      
      Chuck
      
      
      From owner-lynx-dev@sig.net  Sat Apr 17 03:08:16 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27384
      	for ; Sat, 17 Apr 1999 03:08:09 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA16987; Sat, 17 Apr 1999 02:01:17 -0500 (CDT)
      From: newsmgr@mhl.nsw.gov.au
      Date: Sat, 17 Apr 1999 17:00:25 +1000
      Message-Id: <99041717002508@mhl.nsw.gov.au>
      To: lynx-dev@sig.net
      Subject: lynx-dev lynx dev22 on VMS
      X-VMS-To: @MHL_LYNX-DEV.DIS
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1848
      Lines: 54
      
      
       Recently Philip Webb : purslow@chass.utoronto.ca wrote about a problem
      >none of the Lynx volunteers had anything to say about this problem,
      >despite the lengthy account offered.  VMS is not that well supported.
      
      
      	A bit of a worry so I thought I might give the latest dev22 a compile,
      there was not long to wait....
      
      $ cc := cc/decc/prefix=all /nomember -
      	  /warning=(disable=implicitfunc)-
      	  /DEFINE=(ACCESS_AUTH,UCX)-
      	  /INCLUDE=([-.Implementation],[---.src],[---.src.chrtrans],[---])
      $!
      $ cc [-.Implementation]HTParse.c
      $ cc [-.Implementation]HTAccess.c
      $ cc [-.Implementation]HTTP.c
      $ cc [-.Implementation]HTFile.c
      
      PRIVATE int print_local_dir ARGS5(
      ............................^
      %CC-E-NOTEXPECTING, Error parsing parameter list. 
      Found "*" when expecting one of: ",", ")".
      at line number 1475 in file [LYNX2-8-2.WWW.LIBRARY.IMPLEMENTATION]HTFILE.C;1
      
      >From htfile.lis.....
      	  33208 
      	  33209 PRIVATE int print_local_dir ARGS5(
      		............................1      
      %CC-E-NOTEXPECTING, (1) Error parsing parameter list. 
      Found "*" when expecting one of: ",", ")".
      
      	  33210 	DIR  *,			dp,
      	  33211 	char *,			localname,
      	  33212 	HTParentAnchor *,	anchor,
      	  33213 	HTFormat,		format_out,
      	  33214 	HTStream *,		sink)
      	  33215 {
      	  33216     HTStructured *target;	/* HTML object */
      	  33217     HTStructuredClass targetClass;
      	  33218     STRUCT_DIRENT * dirbuf;
      	  33219     char *logical = NULL;
      		....1                     
      %CC-E-BADSTMT, (1) Invalid statement.
      .....
          after this it got seriously confused...
      
      (Alpha VMS 7.1, UCX 4.2, DECC 5.6, lynx2-8-2 13 Apr)
      
       				Regards
       *      *     *     *     *       Tony Bolton   
      ****  ****   **     **   **       TBolton 'at' mhl.nsw.gov.au
      ** **** **   *********   **       MANLY HYDRAULICS LABORATORY.
      **  **  **   *********   **       110B King ST. Manly Vale 2093 Sydney AUSTRALIA
      
      From owner-lynx-dev@sig.net  Sat Apr 17 03:25:54 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27853
      	for ; Sat, 17 Apr 1999 03:25:53 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA18897; Sat, 17 Apr 1999 02:20:22 -0500 (CDT)
      Date: Sat, 17 Apr 1999 03:19:48 -0400 (EDT)
      From: lvirden@cas.org (Larry W. Virden)
      Message-Id: <9904170319.AA3661@cas.org>
      Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes
      In-Reply-To: Your message of Fri, 16 Apr 1999 19:34:43 -0400 (EDT)
      To: lynx-dev@sig.net
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 931
      Lines: 26
      
      > 
      > Strange:
      > Turning trace off at compile-time transforms all instances of
      > CTRACE(...)
      >   to 
      > if (0) fprintf(...)
      > 
      > But the string literals in the CTRACE calls still wind up in the binaries 
      > for me.  (Tried this with both Sun's cc and gcc).  This is like 30k worth 
      > of string literal over the whole lynx source.  It's very disturbing.
      > 
      Can you change things to say
      
      #if 0
      fprintf(...)
      
      
      instead?  That will get rid of the strings you are trying to get rid of.
      Of course, IMO once someone has compiled out info like ctrace, it should
      a) no longer be permitted to be called lynx and b) no longer be acceptable
      to send problem reports to the list...
      -- 
      Larry W. Virden                 
       <*> O- "No one is what he seems."
      Unless explicitly stated to the contrary, nothing in this posting should 
      be construed as representing my employer's opinions.
      
      From owner-lynx-dev@sig.net  Sat Apr 17 03:40:44 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA28326
      	for ; Sat, 17 Apr 1999 03:40:43 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA19863; Sat, 17 Apr 1999 02:32:02 -0500 (CDT)
      From: Philip Webb 
      Message-Id: <199904170731.DAA24511@chass.utoronto.ca>
      Subject: Re: lynx-dev screen widths
      To: lynx-dev@sig.net
      Date: Sat, 17 Apr 1999 03:31:40 -0400 (EDT)
      In-Reply-To: <19990417022831.C8131@delta.Nexus.of.Obsolescence> from "Chuck Martin" at Apr 17, 99 02:28:31 am
      X-Mailer: ELM [version 2.4 PL24]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1307
      Lines: 25
      
      990417 Chuck Martin wrote: 
      > On Fri, Apr 16, 1999 at 12:17:18PM -0400, dickey@clark.net wrote:
      >> 132 column terminals weren't common until the early 80's --
      >> around the time that punchcards went away
      > I believe 132 column *printers* were very much the norm in the 70's.
      > Since terminals were primarily for input, originally done with punched cards,
      > it was logical to make them 80 columns, but printers were for output
      > and there was no reason to duplicate the width of the punched card.
      > I know the terminals were also for output,
      > but that was mostly for the programmer's benefit --
      > reports and such generally used 132 columns.
       
      i'm thinking of my first interactive encounter, early in 1976:
      APL on an IBM golf-ball terminal-printer, which i'm sure was 132 columns.
      
      the reason for making CRT terminals 80-col seems most likely to have been
      that on a 12" screen it gives characters roughly paper-printing size;
      some very early personal computers had 40-col displays,
      probably due to their very small memories or processors.
      
      -- 
      ========================,,============================================
      SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
      ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
      TRANSIT    `-O----------O---'  University of Toronto
      
      From owner-lynx-dev@sig.net  Sat Apr 17 04:15:58 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30133
      	for ; Sat, 17 Apr 1999 04:15:57 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA22996; Sat, 17 Apr 1999 03:09:48 -0500 (CDT)
      From: David Woolley 
      Message-Id: <199904162313.AAA15867@djwhome.demon.co.uk>
      Subject: Re: lynx-dev dev.22 lynx_dev.html
      To: lynx-dev@sig.net
      Date: Sat, 17 Apr 1999 00:13:06 +0100 (BST)
      In-Reply-To: <199904151105.HAA12513@chass.utoronto.ca> from "Philip Webb" at Apr 15, 99 07:05:25 am
      X-Mailer: ELM [version 2.4 PL25]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 321
      Lines: 6
      
      > then you must object to the presence of 
      in HTML at all: > currently, it's a perfectly valid tag for all to use as they see fit. This argument legitimises the use of IMG to contain a rendered bit map of all the text on a page, something I have seen on some GUI pages for body text as well as headings and buttons. From owner-lynx-dev@sig.net Sat Apr 17 04:18:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30152 for ; Sat, 17 Apr 1999 04:18:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA23268; Sat, 17 Apr 1999 03:13:01 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 12:07:56 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev dev22 (patch) more reload_read_cfg() changes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6710 Lines: 221 * Fix reload_read_cfg() to avoid persistent cookies mode changing at run time; reload printers list, downloaders list, environments - as expected. - LP This patch applies after all my previous patches, sorry if a little messy. Besides reload_read_cfg() changes it also affects few lines in LYReadCFG.c (and rename the user configurable variable name from "dispaly_partial" to "display_partial_flag", according with my recent reorganization of display partial logic). diff -u T2/lymain.c ./lymain.c --- T2/lymain.c Sat Apr 17 12:00:50 1999 +++ ./lymain.c Fri Apr 16 15:20:00 1999 @@ -384,7 +384,7 @@ PUBLIC BOOLEAN LYQuitDefaultYes = QUIT_DEFAULT_YES; #ifdef DISP_PARTIAL -PUBLIC BOOLEAN display_partial = TRUE; /* Display document during download */ +PUBLIC BOOLEAN display_partial_flag = TRUE; /* Display document during download */ PUBLIC BOOLEAN debug_display_partial = FALSE; /* Show with MessageSecs delay */ PUBLIC int partial_threshold = -1; /* # of lines to be d/l'ed until we repaint */ #endif @@ -1257,6 +1257,14 @@ StrAllocCopy(UCAssume_MIMEcharset, LYCharSet_UC[UCLYhndl_for_unspec].MIMEname); + /* + * Make sure we have the edit map declared. - FM + */ + if (!LYEditmapDeclared()) { + fprintf(stderr, gettext("\nLynx edit map not declared.\n\n")); + exit(-1); + } + #if defined(USE_HASH) /* * If no alternate lynx-style file was specified on @@ -1304,15 +1312,7 @@ fclose(fp); style_readFromFile(lynx_lss_file); } -#endif - - /* - * Make sure we have the edit map declared. - FM - */ - if (!LYEditmapDeclared()) { - fprintf(stderr, gettext("\nLynx edit map not declared.\n\n")); - exit(-1); - } +#endif /* USE_HASH */ #if USE_COLOR_TABLE /* @@ -1589,7 +1589,7 @@ * Disable partial mode if not interactive. */ if (dump_output_immediately) - display_partial = FALSE; + display_partial_flag = FALSE; #endif #ifdef VMS @@ -1851,11 +1851,19 @@ */ PUBLIC void reload_read_cfg NOARGS { - if (!LYRestricted) { + if (LYRestricted) return; /* for sure */ - /* save .lynxrc file in case we change something from Options Menu */ - if (!save_rc()) return; + /* save .lynxrc file in case we change something from Options Menu */ + if (!save_rc()) return; /* can not write the very own file :( */ + { + /* set few safe flags: */ +#ifdef PERSISTENT_COOKIES + BOOLEAN persistent_cookies_flag = persistent_cookies; + char * LYCookieFile_flag = LYCookieFile; +#endif + + free_lynx_cfg(); /* free downloaders, printers, not always environments */ /* * Process the configuration file. */ @@ -1871,13 +1879,13 @@ /* but other things may be lost: */ /* - * Process any command line arguments not already handled. - FM + * Process any command line arguments not already handled. */ /* Not implemented yet here */ /* * Process any stdin-derived arguments for a lone "-" which we've - * loaded into LYStdinArgs. - FM + * loaded into LYStdinArgs. */ /* Not implemented yet here */ @@ -1886,8 +1894,19 @@ */ /* Not implemented yet here, * a major problem: file paths - * like lynx_temp_space, LYCookieFile etc. + * like lynx_save_space, LYCookieFile etc. */ +#ifdef PERSISTENT_COOKIES + /* restore old settings */ + if (persistent_cookies != persistent_cookies_flag) { + persistent_cookies = persistent_cookies_flag; + HTAlert(gettext("persistent cookies state will be changed in next session only.")); + } + if (strcmp(LYCookieFile, LYCookieFile_flag)) { + StrAllocCopy(LYCookieFile, LYCookieFile_flag); + CTRACE(tfp, "cookies file can be changed in next session only, restored.\n") + } +#endif } } @@ -2848,7 +2867,7 @@ ), #ifdef DISP_PARTIAL PARSE_SET( - "partial", TOGGLE_ARG, &display_partial, + "partial", TOGGLE_ARG, &display_partial_flag, "toggles display partial pages while downloading" ), PARSE_INT( diff -u T2/lymainlo.c ./lymainlo.c --- T2/lymainlo.c Sat Apr 17 11:34:20 1999 +++ ./lymainlo.c Fri Apr 16 16:51:46 1999 @@ -86,7 +86,7 @@ #ifdef DISP_PARTIAL PUBLIC int Newline_partial = 0; /* required for display_partial mode */ PUBLIC int NumOfLines_partial = -1; /* initialize to -1 the very first time */ -PUBLIC BOOLEAN display_partial_flag = FALSE; +PUBLIC BOOLEAN display_partial = FALSE; PUBLIC int Newline = 0; #else PRIVATE int Newline = 0; @@ -311,9 +311,6 @@ user_input_buffer[(sizeof(user_input_buffer) - 1)] = '\0'; *prev_target = '\0'; *user_input_buffer = '\0'; -#ifdef DISP_PARTIAL - display_partial_flag = display_partial; /* permanent flag, not mutable */ -#endif StrAllocCopy(CurrentUserAgent, (LYUserAgent ? LYUserAgent : "")); StrAllocCopy(CurrentNegoLanguage, (language ? diff -u T2/lyreadcf.c ./lyreadcf.c --- T2/lyreadcf.c Sat Apr 17 12:00:54 1999 +++ ./lyreadcf.c Fri Apr 16 15:43:08 1999 @@ -76,7 +76,6 @@ return NULL; } -#ifdef LY_FIND_LEAKS /* * Function for freeing the DOWNLOADER and UPLOADER menus list. - FM */ @@ -121,7 +120,6 @@ return; } -#endif /* LY_FIND_LEAKS */ /* * Process string buffer fields for DOWNLOADER or UPLOADER menus. @@ -201,7 +199,6 @@ } -#ifdef LY_FIND_LEAKS /* * Function for freeing the PRINTER menus list. - FM */ @@ -221,7 +218,6 @@ return; } -#endif /* LY_FIND_LEAKS */ /* * Process string buffer fields for PRINTER menus. @@ -1121,7 +1117,7 @@ PARSE_SET("no_referer_header", CONF_BOOL, &LYNoRefererHeader), PARSE_FUN("outgoing_mail_charset", CONF_FUN, outgoing_mail_charset_fun), #ifdef DISP_PARTIAL - PARSE_SET("partial", CONF_BOOL, &display_partial), + PARSE_SET("partial", CONF_BOOL, &display_partial_flag), PARSE_INT("partial_thres", CONF_INT, &partial_threshold), #endif #ifdef EXP_PERSISTENT_COOKIES @@ -1206,12 +1202,17 @@ if (q->str_value != 0) { FREE(*(q->str_value)); FREE(q->str_value); + /* is it enough for reload_read_cfg() to clean up + * the result of putenv()? No for certain platforms. + */ } break; default: break; } } + free_item_list(); + free_printer_item_list(); } /* From owner-lynx-dev@sig.net Sat Apr 17 04:41:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30824 for ; Sat, 17 Apr 1999 04:41:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA24777; Sat, 17 Apr 1999 03:33:29 -0500 (CDT) To: lynx-dev@sig.net References: <99041717002508@mhl.nsw.gov.au> Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 12:28:05 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx dev22 on VMS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1960 Lines: 53 17-Apr-99 17:00 newsmgr@mhl.nsw.gov.au wrote: > Recently Philip Webb : purslow@chass.utoronto.ca wrote about a problem >>none of the Lynx volunteers had anything to say about this problem, >>despite the lengthy account offered. VMS is not that well supported. > A bit of a worry so I thought I might give the latest dev22 a compile, > there was not long to wait.... > PRIVATE int print_local_dir ARGS5( > ............................^ > %CC-E-NOTEXPECTING, Error parsing parameter list. > Found "*" when expecting one of: ",", ")". > at line number 1475 in file [LYNX2-8-2.WWW.LIBRARY.IMPLEMENTATION]HTFILE.C;1 > From htfile.lis..... > 33208 > 33209 PRIVATE int print_local_dir ARGS5( > ............................1 > %CC-E-NOTEXPECTING, (1) Error parsing parameter list. > Found "*" when expecting one of: ",", ")". > 33210 DIR *, dp, > 33211 char *, localname, > 33212 HTParentAnchor *, anchor, > 33213 HTFormat, format_out, > 33214 HTStream *, sink) > 33215 { > 33216 HTStructured *target; /* HTML object */ > 33217 HTStructuredClass targetClass; > 33218 STRUCT_DIRENT * dirbuf; > 33219 char *logical = NULL; > ....1 > %CC-E-BADSTMT, (1) Invalid statement. > ..... > after this it got seriously confused... Sorry, my fault, this function not used for VMS, should be ifdef'ed with #if !defined(VMS) && defined(HAVE_READDIR) > (Alpha VMS 7.1, UCX 4.2, DECC 5.6, lynx2-8-2 13 Apr) > Regards > * * * * * Tony Bolton > **** **** ** ** ** TBolton 'at' mhl.nsw.gov.au > ** **** ** ********* ** MANLY HYDRAULICS LABORATORY. > ** ** ** ********* ** 110B King ST. Manly Vale 2093 Sydney AUSTRALIA From owner-lynx-dev@sig.net Sat Apr 17 04:47:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id EAA30866 for ; Sat, 17 Apr 1999 04:47:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA25398; Sat, 17 Apr 1999 03:42:18 -0500 (CDT) Date: Sat, 17 Apr 1999 03:42:14 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev lynx and ncurses and gpm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7997 Lines: 177 I've been trying to understand the mouse code in lynx. The NCURSES mouse code basically works for me in an xterm. But usually I don't use X but work from the linux console. The ncurses documentation suggests that NCURSES mouse support should also work in this environment (I have the gpm daemon running anyway). First, I've found that, although I have gpm (several packages: binaries and libraries) and ncurses (libncurses4 Debian package with associated dev library package) installed, the binary /lib/libncurses.so.4.2 from Debian was not compiled with gpm support (I didn't find this documented anywhere, and the /usr/man/man3/mouse.3ncurses.gz that comes with it suggests otherwise). -- Question 1: Is this common for all Linux distributions? Are thare any Linux distributions with an ncurses package that has gpm support enabled? So I got the latest ncurses from Tom Dickey's FTP site (patches up to 990410) and compiled it. I also got newer gpm source (1.17.6) and recompiled the libgpm libraries, making sure both the new ncurses and the new libgpm reference the new versions' -I and -L directories. After recompiling lynx against the new ncurses lib, what I got was a binary that recognized mouse events (when invoked with -use_mouse, of course), but the mouse support is mostly unusable. The reason is that mouse events handled by lynx are still also handled by the default gpm "selection" handler. So a middle-button click pastes the contents of the selection buffer into the input stream, in addition to being passed to lynx. -- Question 2: Are there any known applications running successfully with gpm mouse support *only* via ncurses (no direct calls to libgpm functions from the application)? I traced this back to the way gpm is initialized by the call to Gpm_Open in ncurses's lib_mouse.c: gpm_connect.eventMask = GPM_DOWN|GPM_UP; gpm_connect.defaultMask = ~gpm_connect.eventMask; gpm_connect.minMod = 0; gpm_connect.maxMod = ~0; This is hardwired, there is no way the application can change these default flags (unless it calls libgpm directly, losing the advantage of the details-agnostic interface provided by ncurses completely). Another formulation of question 2: are there any known applications for which these defaults are appropriate? I changed the initialization to #if USE_GPM_SUPPORT ..... #include /* defines KG_* macros */ #endif ..... gpm_connect.eventMask = GPM_DOWN|GPM_UP; gpm_connect.defaultMask = ~(gpm_connect.eventMask|GPM_HARD); gpm_connect.minMod = 0; gpm_connect.maxMod = ~((1< and then maps all files into their expected locations as symlinks.) 3. Yep, the ABI has changed (just confirming...). However, running an older lynx binary compiled against the previous ncurses version mostly works when linked at runtime against the new library (via a bogus symlink), but with completely wrong colors (only tried an --enable-color-style binary). Where it crashed is in parsing the setkey "^(cuu1)" UPARROW setkey "^(up)" UPARROW entries from a .lynx-keymaps file (no crash after commenting them out). What's happening: $ /usr/local/src/lynx2-8-1-cs/src/lynx ..... A Fatal error has occurred in Lynx Ver. 2.8.1rel.2 ..... Lynx now exiting with signal: 11 $ gdb /usr/local/src/lynx2-8-1-cs/src/lynx core ..... (gdb) where ..... #3 0x8063b28 in FatalProblem (sig=11) at ./LYMain.c:3235 #4 #5 0x400aa3d4 in strcpy () #6 0x804bc58 in expand_tiname (first=0xbfffef2a "cuu1)\"", len=4, result=0xbfffcdac) at ./LYStrings.c:428 apparently the lynx code here accesses internal ncurses structures directly which have changed (this may be sensitive to smaller library upgrades that are *not* reflected in changing the library's soname). Maybe it would be safer if lynx didn't do this... 4. Regarding the ^Z problems discussed a while ago: The obvious ones, which I was observing all the time with the previous libncurses 4.2, don't occur any more with the new version, but I haven't checked yet in detail. Klaus From owner-lynx-dev@sig.net Sat Apr 17 06:04:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA00067 for ; Sat, 17 Apr 1999 06:04:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11342; Sat, 17 Apr 1999 04:57:56 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 13:56:13 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 950 Lines: 26 16-Apr-99 10:52 Scott Bigham wrote: > No, source caching does not affect the overall caching protocol in any > way; whatever caching logic Lynx has is applied to the cached document > as before, and the attached cached source, if any, is reloaded in the > process of reloading the cached document. BTW, we forget to add a warning in HTreload_document() that we lost a form contents, if any. Should be implemented in other way, but let insert from LYK_RELOAD at least. Insert this before #ifdef DISP_PARTIAL in HTreload_partial(): if (lynx_mode == FORMS_LYNX_MODE) { /* * Note that if there are no form links on the current * page, lynx_mode won't have this setting and we won't * know that this warning should be issued. - FM */ HTAlert(RELOADING_FORM); } > -sbigham From owner-lynx-dev@sig.net Sat Apr 17 10:41:08 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06908 for ; Sat, 17 Apr 1999 10:41:03 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id KAA17332 for ; Sat, 17 Apr 1999 10:25:22 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA07005; Sat, 17 Apr 1999 09:14:12 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904171413.IAA22175@sanitas> Subject: Re: lynx-dev dev21: reverse video partly explained. Other stuff. To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 08:13:37 -0600 (MDT) In-Reply-To: from "Klaus Weide" at Apr 17, 99 05:49:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 652 Lines: 24 In a recent note, Klaus Weide said: > Date: Sat, 17 Apr 1999 05:49:13 -0500 (CDT) > > [PG:] > > > Now, though, I get the sticky reverse video when I suspend with ~Z. > > > On Sun, 4 Apr 1999 dickey@clark.net wrote: > > perhaps that's a curses problem (ncurses should restore mods on ^Z, iirc, > > It could also be an interaction between the shell and curses. PG, if After a while, I found this, and TD expanded on it: It was an effect of using an older gcc on Solaris 2.6. Unlike others, I find Lynx doesn't understand the ^Z; stty ...; fg; ^L to reformat the screen. Probably YA curses interaction. I'm not much concerned. Thanks, gil From owner-lynx-dev@sig.net Sat Apr 17 10:41:24 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06920 for ; Sat, 17 Apr 1999 10:41:23 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA10507 for ; Sat, 17 Apr 1999 10:40:48 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id KAA17361 for ; Sat, 17 Apr 1999 10:29:04 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA07601; Sat, 17 Apr 1999 09:18:41 -0500 (CDT) Date: Sat, 17 Apr 1999 07:18:37 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev DOS bug report - no fix (PDCurses build) (PATCH) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3211 Lines: 77 On Sun, 11 Apr 1999, I wrote: > I wanted to report to the list two (probably related) bugs in the > PDCurses build of the DOS port of lynx. These are not found in the > SLang port. I don't know where the problem arises, in PDCurses itself > or in the way lynx interacts. > > 1. When exiting with CTRL-C or CTRL-BREAK, the system BREAK is not > reset to the value present before lynx was executed. It is always ON. > BREAK is reset properly with a normal exit. > > 2. When exiting with CTRL-BREAK, but not with CTRL-C, the packet > driver can not terminate properly, requiring a reboot to clear it from > memory (tested with DOSPPP only). This turns out to be a problem with the DOS PDCurses port. The error was actually introduced by me in 1997. I'll be forwarding a bug report to the PDCurses list. This patch should fix it for lynx. I also put in an update on WATTCP code availability. Doug --- lynx2-8-2/INSTALLATION Tue Mar 30 09:10:38 1999 +++ lynx2-8-2/INSTALLATION.new Sat Apr 17 05:34:38 1999 @@ -676,14 +676,16 @@ zlib.h and zconf.h in the include subdirectory. In addition to the files in the Lynx distribution, you will need a - curses package and a TCP package. You can use PDCurses (available at + curses package and a TCP package. You can use PDCurses (available at "http://www.lightlink.com/hessling/") and the DJGPP port of WATTCP (available in two different versions at "ftp://neonatal.sm.med.ic.ac.uk/" - and in "http://www.fdisk.com/doslynx/wlynx/source/djgpp.zip"). You - can also use slang ("ftp://space.mit.edu/pub/davis/slang") as your - curses library. You need to compile these before you go any further. - If you wish to use PDCurses 2.3, you need to first apply the - following patch: + and in "http://www.fdisk.com/doslynx/wlynx/source/djgpp.zip"). + A patched copy of the version from the neonatal site is also + available from "http://www.rahul.net/dkaufman/tcplibdj.zip" or + "ftp://ftp.rahul.net/pub/dkaufman/tcplibdj.zip". You can also use slang + ("ftp://space.mit.edu/pub/davis/slang") as your curses library. You need + to compile these before you go any further. If you wish to use PDCurses + 2.3, you need to first apply the following patch: *** curses.h Thu Jul 9 19:38:28 1998 --- curses.h.new Sat Aug 15 11:02:08 1998 @@ -697,6 +699,25 @@ #define getch() wgetch(stdscr) #define getmaxx(w) (w)->_maxx #define getmaxy(w) (w)->_maxy +*** dos/pdckbd.c Sat Jul 12 17:10:12 1997 +--- dos/pdckbd.c.new Thu Apr 15 20:52:16 1999 +*************** +*** 443,449 **** + _watch_breaks(); + #else + # ifdef GO32 +! (void*)signal(SIGINT,(setting ? SIG_DFL : SIG_IGN)); + /* __djgpp_set_ctrl_c(setting);*/ + setcbrk(setting); + # else +--- 443,449 ---- + _watch_breaks(); + #else + # ifdef GO32 +! /* (void*)signal(SIGINT,(setting ? SIG_DFL : SIG_IGN)); */ + /* __djgpp_set_ctrl_c(setting);*/ + setcbrk(setting); + # else If you have trouble applying the patch, we recommend that you use the "patch" program, __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Apr 17 10:42:41 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06971 for ; Sat, 17 Apr 1999 10:42:29 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id JAA16581 for ; Sat, 17 Apr 1999 09:37:51 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA00513; Sat, 17 Apr 1999 08:25:51 -0500 (CDT) Date: Sat, 17 Apr 1999 09:23:50 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes In-Reply-To: <199904171119.HAA22016@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 805 Lines: 21 On Sat, 17 Apr 1999 dickey@clark.net wrote: > > Can you change things to say > > > > #if 0 > > fprintf(...) > not exactly. we went over this a few months ago. as KW notes, turning > on optimization would probably accomplish the desired effect. otherwise, > we'll have to rephrase all of the CTRACE macros. (I'd rather concentrate > on finishing off the dangling stuff for 2.8.2 than change 1400 lines of code) Indeed. There's no clean, easy way to "fix" CTRACE, if it really needs to be fixed. I'm still puzzled over why the compiler includes the string literal but not the fprintf call. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Sat Apr 17 10:42:48 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06987 for ; Sat, 17 Apr 1999 10:42:43 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id JAA16265 for ; Sat, 17 Apr 1999 09:11:36 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27589; Sat, 17 Apr 1999 08:00:48 -0500 (CDT) Date: Sat, 17 Apr 1999 08:58:06 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1181 Lines: 31 On Sat, 17 Apr 1999, Klaus Weide wrote: > > * Fix --disable-trace, chop more unneeded #includes (John Bley) > Could you explain why --disable-trace needed fixing? It seems to > me you change doesn't really change anything - you now just test > for NO_LYNX_TRACE directly rather than indirectly (through DEBUG), > or am I missing something? Yes, that's what I thought too, but for some reason ./configure --disable-trace && make all was still producing a binary that could do tracing. (I.e., produces Lynx.trace and fills it with junk). I tried with both gcc and Sun's cc. I don't claim to fully understand why this particular fix works for me, but now when I disable-trace I really don't produce the trace. > > Strange: > > Turning trace off at compile-time transforms all instances of > > CTRACE(...) > > to > > if (0) fprintf(...) > > Are you really compiling with -O[>=2] and without -g? For gcc, yes. Also the appropriate flags for cc. It is quite strange. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Sat Apr 17 10:42:50 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06994 for ; Sat, 17 Apr 1999 10:42:48 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA10555 for ; Sat, 17 Apr 1999 10:42:36 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id JAA16394 for ; Sat, 17 Apr 1999 09:22:21 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28573; Sat, 17 Apr 1999 08:09:28 -0500 (CDT) Date: Sat, 17 Apr 99 05:33 CDT From: owner@bugs.debian.org (Debian Bug Tracking System) To: lynx-dev@sig.net Subject: lynx-dev Bug#3846: Info received (was dev.22 patch 1 - old Debian lynx bug #3846) Message-ID: In-Reply-To: References: X-Debian-PR-Message: ack-info-maintonly 3846 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 602 Lines: 15 Thank you for the additional information you have supplied regarding this problem report. It has been forwarded to the developer(s) and to the developers' mailing list to accompany the original report. Your message has been sent to the package maintainer(s): Christian Hudon If you wish to continue to submit further information on your problem, please send it to 3846@bugs.debian.org, as before. Please do not reply to the address at the top of this message, unless you wish to report a problem with the bug-tracking system. Ian Jackson (administrator, Debian bugs database) From owner-lynx-dev@sig.net Sat Apr 17 10:42:41 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA06969 for ; Sat, 17 Apr 1999 10:42:28 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id JAA16442 for ; Sat, 17 Apr 1999 09:27:15 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28980; Sat, 17 Apr 1999 08:13:23 -0500 (CDT) Date: Sat, 17 Apr 1999 09:11:57 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes In-Reply-To: <9904170319.AA3661@cas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1622 Lines: 46 On Sat, 17 Apr 1999, Larry W. Virden wrote: > > Strange: > > Turning trace off at compile-time transforms all instances of > > CTRACE(...) > > to > > if (0) fprintf(...) > > But the string literals in the CTRACE calls still wind up in the binaries > > for me. (Tried this with both Sun's cc and gcc). This is like 30k worth > > of string literal over the whole lynx source. It's very disturbing. > Can you change things to say > #if 0 > fprintf(...) > instead? That will get rid of the strings you are trying to get rid of. Not by redefining CTRACE. Here's the basic idea from the code: #ifdef NO_LYNX_TRACE #define TRACE 0 #else #define TRACE some_variable_name_I_forget #endif #define CTRACE if(TRACE) fprintf So that CTRACE(...) becomes if(TRACE) fprintf (...) ^^^^^ this stuff untouched by the macro expansion This is really a bizarre hack. I can't redefine CTRACE to be a macro function: #define CTRACE(a, b, c) something-or-other /* Can't do this */ because CTRACE passes on a varargs to fprintf, and I don't think you can reliably do a varargs macro function. > Of course, IMO once someone has compiled out info like ctrace, it should > a) no longer be permitted to be called lynx and b) no longer be acceptable > to send problem reports to the list... That's why you have to explicitly --disable-trace. I live in a small-quota world and like saving all the space I can. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Sat Apr 17 10:43:22 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07044 for ; Sat, 17 Apr 1999 10:43:08 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id IAA16045 for ; Sat, 17 Apr 1999 08:55:44 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA25768; Sat, 17 Apr 1999 07:44:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904171244.IAA10181@shell.clark.net> Subject: Re: lynx-dev lynx and ncurses and gpm To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 08:44:08 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 17, 99 03:42:14 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 5790 Lines: 133 > -- Question 1: > Is this common for all Linux distributions? Are thare any Linux > distributions with an ncurses package that has gpm support enabled? I don't think there are (it's not a technical issue though) > -- Question 2: > Are there any known applications running successfully with gpm > mouse support *only* via ncurses (no direct calls to libgpm functions > from the application)? just a few, I believe - most character-cell applications that use mouse only use one button. so it's not been a big issue til now (though known). lynx, of course can use all 3 buttons (and come to think of it, lynx users are more likely to want to use the console because of the setfont code). > gpm_connect.eventMask = GPM_DOWN|GPM_UP; > gpm_connect.defaultMask = ~(gpm_connect.eventMask|GPM_HARD); > gpm_connect.minMod = 0; > gpm_connect.maxMod = ~((1< > recompiled ncurses, and got a lynx with mouse support under gpm that > works. At least brief testing didn't shown problems that were specific > to the gpm environment, only those that are also there in an xterm. I'll try this out today - the only caveats I can think of offhand are whether the KG_ macros are defined in all versions of Linux. But I can certainly make this configuration available somehow. > -- Question 3: > Tom, could these changes be incorporated into ncurses? > (If there are no apllication for which the previous behavior was > right, as I suspect, this should go into the to-be-released-soon > ncurses.) Possibly - I'm only making bug-fix changes to the beta right now. If it looks like a low-impact change, I can add it. > -- Question 4: > How are the chances of getting this kind of increased flexibility > into the ncurses distribution? > (Also, are there significant security issues with allowing > control by an env variable? - Note it can hardly be worse than > what there is currently.) That's something that I'll have to think about (I would suppose that going the other way - to force paste-behavior - would be less secure). > ------------------- > > Various other remarks steeming from recompiling-ncurses experience: > > 1. I added another model to the ncurses configuration, to get shared libs > with debugging: they will be generated after > ./configure --with-debugshared > as lib*_g.so[.M[.N]] (in case of linux, at least). The changes are > mostly straightforward, just a combination of --with-shared and > --with-debug settings. Tom, are you interested in patches? I do this by CFLAGS=-g configure --with-shared (I'm not entirely happy with the multiple models, but they work) > 2. What is --with-install-prefix supposed to do, and is it implemented > correctly by configure? > I used it as > ./configure --prefix=/usr/local --exec-prefix=/usr/local \ > --with-install-prefix=/usr/local/stow/ncurses-5.0-beta1-990403 ... > > and assumed that compiled-in paths would be configured to reference > locations (for terminfo directory etc.) under /usr/local/, but > actual installation on 'make install' would take place under > the longer path (for example, terminfo files under > /usr/local/stow/ncurses-5.0-beta1-990403/share/terminfo). > But what I found was that actual installation actually takes place > under /usr/local/stow/ncurses-5.0-beta1-990403/usr/local/, > ^^^^^^^^^^ > is that as intended? It seems rather useless. yes - it's so someone can build and install under the install-prefix, then tar that tree up and plop it down on user's machines under the regular prefix. > (I am playing around with the GNU "stow" program, which assumes > packages that are supposed to appear under /usr/local are actuall > installed under /usr/local/stow/ and then maps all > files into their expected locations as symlinks.) some of the paths in ncurses are compiled-in (does stow edit binary files?). > 3. Yep, the ABI has changed (just confirming...). ah. This is something that'll be an FAQ. The last major change I made to the beta does change one of the structures, making the tables it defines extensible (that changes some fixed-length arrays to pointers). The extension itself is normally not configured in (technically it's experimental), but the struct changes were needed to make the extension transparent to applications which would be linked against it. Recompiling the application will fix this. There was more than one change that affected the ABI; we decided to make this additional change to take advantage of this. (otoh, I expect to continue seeing people in the newsgroups advising other people to symlink ncurses 3.0 to 4.2 to 5.0, etc). > apparently the lynx code here accesses internal ncurses structures > directly which have changed (this may be sensitive to smaller library > upgrades that are *not* reflected in changing the library's soname). > Maybe it would be safer if lynx didn't do this... There's no function-interface that covers the structure - I expect there will be some applications that use the structure, but not many. > 4. Regarding the ^Z problems discussed a while ago: > The obvious ones, which I was observing all the time with the previous > libncurses 4.2, don't occur any more with the new version, but I > haven't checked yet in detail. I have a hunch that your fixes from January have covered most of the problems in this area. > Klaus > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 10:44:32 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07191 for ; Sat, 17 Apr 1999 10:44:31 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA10812 for ; Sat, 17 Apr 1999 10:44:15 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id HAA15319 for ; Sat, 17 Apr 1999 07:58:54 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA20379; Sat, 17 Apr 1999 06:48:35 -0500 (CDT) From: Philip Webb Message-Id: <199904171148.HAA29060@chass.utoronto.ca> Subject: Re: lynx-dev lynx dev22 on VMS To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 07:48:43 -0400 (EDT) In-Reply-To: <199904171116.HAA09446@shell.clark.net> from "dickey@clark.net" at Apr 17, 99 07:16:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 674 Lines: 15 990417 Thomas Dickey wrote: > Philip Webb wrote: >> none of the Lynx volunteers had anything to say about this problem, >> despite the lengthy account offered. VMS is not that well supported. > PW doesn't support VMS. I do > (with lots of help from the people who report problems building there). he does try to get people an answer tho' ... and in this case a tiny patch presumably, curtesy of LP. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 17 10:44:56 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07224 for ; Sat, 17 Apr 1999 10:44:51 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id HAA14962 for ; Sat, 17 Apr 1999 07:30:21 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA18213; Sat, 17 Apr 1999 06:19:07 -0500 (CDT) From: dickey@clark.net Message-Id: <199904171119.HAA22016@shell.clark.net> Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 07:19:04 -0400 (EDT) In-Reply-To: <9904170319.AA3661@cas.org> from "lvirden@cas.org" at Apr 17, 99 03:19:48 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1376 Lines: 37 > > > > > Strange: > > Turning trace off at compile-time transforms all instances of > > CTRACE(...) > > to > > if (0) fprintf(...) > > > > But the string literals in the CTRACE calls still wind up in the binaries > > for me. (Tried this with both Sun's cc and gcc). This is like 30k worth > > of string literal over the whole lynx source. It's very disturbing. > > > Can you change things to say > > #if 0 > fprintf(...) not exactly. we went over this a few months ago. as KW notes, turning on optimization would probably accomplish the desired effect. otherwise, we'll have to rephrase all of the CTRACE macros. (I'd rather concentrate on finishing off the dangling stuff for 2.8.2 than change 1400 lines of code) > instead? That will get rid of the strings you are trying to get rid of. > Of course, IMO once someone has compiled out info like ctrace, it should > a) no longer be permitted to be called lynx and b) no longer be acceptable > to send problem reports to the list... > -- > Larry W. Virden > <*> O- "No one is what he seems." > Unless explicitly stated to the contrary, nothing in this posting should > be construed as representing my employer's opinions. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 10:44:59 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07225 for ; Sat, 17 Apr 1999 10:44:51 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id HAA14903 for ; Sat, 17 Apr 1999 07:25:10 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA17532; Sat, 17 Apr 1999 06:11:51 -0500 (CDT) From: dickey@clark.net Message-Id: <199904171111.HAA11212@shell.clark.net> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 07:11:45 -0400 (EDT) In-Reply-To: <19990417022831.C8131@delta.Nexus.of.Obsolescence> from "Chuck Martin " at Apr 17, 99 02:28:31 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1403 Lines: 34 > > On Fri, Apr 16, 1999 at 12:17:18PM -0400, dickey@clark.net wrote: > > > > no - 80 (132 column terminals weren't common until the early 80's -- around > > the time that punchcards went away) > > I don't know about terminals, but I believe 132 column *printers* were printers, yes, terminals no (there's a real difference ;-). printer widths were pretty standard also, I believe because of the paper sizes, and the limited range of character spacing - and _that_ didn't change until the early 80's when laser printers became common, so we could have more variations than switching lines/inch between 6 and 8. wide terminals didn't hit the street until the word processing industry boomed at the end of the 70's, and then they were a niche market until the early 80's (a side effect of the IBM PC, some would argue). (but that's just my first-hand experience ;-) > very much the norm in the 70's. Since terminals were primarily for input, > and input was originally done with punched cards, it was logical to make > the terminals 80 columns, but printers were for output, and there was no > reason to duplicate the width of the punched card. (Yes, I know that the > terminals were also for output, but that was mostly for the programmer's > benefit--reports and such generally used 132 columns.) > > Chuck -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 10:45:01 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07230 for ; Sat, 17 Apr 1999 10:44:57 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id HAA14925 for ; Sat, 17 Apr 1999 07:27:53 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA18063; Sat, 17 Apr 1999 06:17:11 -0500 (CDT) From: dickey@clark.net Message-Id: <199904171116.HAA09446@shell.clark.net> Subject: Re: lynx-dev lynx dev22 on VMS To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 07:16:48 -0400 (EDT) In-Reply-To: <99041717002508@mhl.nsw.gov.au> from "newsmgr@mhl.nsw.gov.au" at Apr 17, 99 05:00:25 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2336 Lines: 66 > Recently Philip Webb : purslow@chass.utoronto.ca wrote about a problem > >none of the Lynx volunteers had anything to say about this problem, > >despite the lengthy account offered. VMS is not that well supported. PW doesn't support VMS. I do (with lots of help from the people who report problems building there). > > A bit of a worry so I thought I might give the latest dev22 a compile, > there was not long to wait.... > > $ cc := cc/decc/prefix=all /nomember - > /warning=(disable=implicitfunc)- > /DEFINE=(ACCESS_AUTH,UCX)- > /INCLUDE=([-.Implementation],[---.src],[---.src.chrtrans],[---]) > $! > $ cc [-.Implementation]HTParse.c > $ cc [-.Implementation]HTAccess.c > $ cc [-.Implementation]HTTP.c > $ cc [-.Implementation]HTFile.c > > PRIVATE int print_local_dir ARGS5( > ............................^ > %CC-E-NOTEXPECTING, Error parsing parameter list. > Found "*" when expecting one of: ",", ")". > at line number 1475 in file [LYNX2-8-2.WWW.LIBRARY.IMPLEMENTATION]HTFILE.C;1 > > >From htfile.lis..... > 33208 > 33209 PRIVATE int print_local_dir ARGS5( > ............................1 > %CC-E-NOTEXPECTING, (1) Error parsing parameter list. > Found "*" when expecting one of: ",", ")". > > 33210 DIR *, dp, I don't see it right off, but suspect that DIR is not declared on VMS. Will check. But it looks like you can ifdef out that function under HAVE_READDIR. > 33211 char *, localname, > 33212 HTParentAnchor *, anchor, > 33213 HTFormat, format_out, > 33214 HTStream *, sink) > 33215 { > 33216 HTStructured *target; /* HTML object */ > 33217 HTStructuredClass targetClass; > 33218 STRUCT_DIRENT * dirbuf; > 33219 char *logical = NULL; > ....1 > %CC-E-BADSTMT, (1) Invalid statement. > ..... > after this it got seriously confused... > > (Alpha VMS 7.1, UCX 4.2, DECC 5.6, lynx2-8-2 13 Apr) > > Regards > * * * * * Tony Bolton > **** **** ** ** ** TBolton 'at' mhl.nsw.gov.au > ** **** ** ********* ** MANLY HYDRAULICS LABORATORY. > ** ** ** ********* ** 110B King ST. Manly Vale 2093 Sydney AUSTRALIA -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 10:45:20 1999 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07251 for ; Sat, 17 Apr 1999 10:45:12 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id HAA14567 for ; Sat, 17 Apr 1999 07:00:01 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA14987; Sat, 17 Apr 1999 05:49:16 -0500 (CDT) Date: Sat, 17 Apr 1999 05:49:13 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev dev21: reverse video partly explained. Other stuff. In-Reply-To: <199904041458.KAA12160@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 531 Lines: 14 [PG:] > > Now, though, I get the sticky reverse video when I suspend with ~Z. > On Sun, 4 Apr 1999 dickey@clark.net wrote: > perhaps that's a curses problem (ncurses should restore mods on ^Z, iirc, > but I don't know if other implementations are as tidy) It could also be an interaction between the shell and curses. PG, if this problem still exists, try starting lynx from different interactive shells; also, if the shell has different line-editing modes (like set -o emacs / set +o emacs), try playing with that. Klaus From owner-lynx-dev@sig.net Sat Apr 17 10:45:35 1999 Received: from sparks.flora.ottawa.on.ca (sparks.flora.ottawa.on.ca [209.195.75.66]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07271 for ; Sat, 17 Apr 1999 10:45:26 -0400 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by sparks.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA10850 for ; Sat, 17 Apr 1999 10:45:10 -0400 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id GAA14377 for ; Sat, 17 Apr 1999 06:43:42 -0400 (EDT) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA13658; Sat, 17 Apr 1999 05:30:22 -0500 (CDT) Date: Sat, 17 Apr 1999 05:29:54 -0500 (CDT) From: Klaus Weide To: Martin Schulze cc: Lynx Development , 3846@bugs.debian.org Subject: lynx-dev dev.22 patch 1 - old Debian lynx bug #3846 In-Reply-To: <19990402130508.B8158@finlandia.artis.uni-oldenburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3843 Lines: 98 On Fri, 2 Apr 1999, Martin Schulze wrote: > we have received the follwoing report through the bug tracking system > of Debian at http://www.debian.org/Bugs/. > > The bug is against version 2.4-FM-960316-1 but still present. > The entire report can be viewed at http://www.infodrom.north.de/Debian/Bugs/db/38/3846.html > > Caveat: The URL as given in the bug report is not available anymore. > > Please keep 3846@bugs.debian.org in your replies in order > to record it in that bug tracking system. [.....] > Antti-Juhani Kaijanaho wrote: > > > > RFC 1866 (HTML 2.0) says: > > > > The content of a
      element is a sequence of
      elements and/or > >
      elements, usually in pairs. Multiple
      may be paired with a > > single
      element. Documents should not contain multiple > > consecutive
      elements. > > > > [...] > > > > Unless the COMPACT attribute is present, an HTML user agent may leave > > white space between successive DT, DD pairs. The COMPACT attribute > > may also reduce the width of the left-hand (DT) column. > > > > Thus, it looks like a bug, since (by natural implication) space may be > > left only between successive DT DD pairs, and multiple DT's are allowed > > for a DD. The newer HTML specifications do not address this. It may be questionable whether this is a bug, but I agree that the requested behavior makes more sense. Below is a patch against current 2.8.2dev.22. Not checked whether it applies cleanly against 2.8.1, but if it doesn't the only reason would be insignificant formatting changes, it should be trivial to fix by hand. Klaus * Tweak in HTML_start_element case HTML_DT: prevent generation of empty line between multiple simple DT elements without intervening DD elements (Debian bug #3846). --- lynx2-8-2.old/src/GridText.c Tue Apr 13 04:39:16 1999 +++ lynx2-8-2/src/GridText.c Sat Apr 17 05:00:48 1999 @@ -6473,6 +6473,15 @@ return; } +PUBLIC BOOL HText_inLineOne ARGS1( + HText *, text) +{ + if (text) { + return text->in_line_1; + } + return YES; +} + /* * This function is for removing the first of two * successive blank lines. It should be called after --- lynx2-8-2.old/src/GridText.h Tue Apr 13 04:39:16 1999 +++ lynx2-8-2/src/GridText.h Sat Apr 17 05:02:19 1999 @@ -186,6 +186,7 @@ extern int HText_LastLineSize PARAMS((HText *me, BOOL IgnoreSpaces)); extern int HText_PreviousLineSize PARAMS((HText *me, BOOL IgnoreSpaces)); extern void HText_NegateLineOne PARAMS((HText *text)); +extern BOOL HText_inLineOne PARAMS((HText *text)); extern void HText_RemovePreviousLine PARAMS((HText *text)); extern int HText_getCurrentColumn PARAMS((HText *text)); extern int HText_getMaximumColumn PARAMS((HText *text)); --- lynx2-8-2.old/src/HTML.c Tue Apr 13 04:39:16 1999 +++ lynx2-8-2/src/HTML.c Sat Apr 17 04:56:35 1999 @@ -2281,7 +2281,23 @@ case HTML_DT: CHECK_ID(HTML_GEN_ID); if (!me->style_change) { + BOOL in_line_1 = HText_inLineOne(me->text); + HTCoord saved_spaceBefore = me->sp->style->spaceBefore; + HTCoord saved_spaceAfter = me->sp->style->spaceAfter; + /* + * If there are several DT elements and this is not the first, + * and the preceding DT element's first (and normally only) line + * has not yet been ended, suppress intervening blank line by + * temporarily modifying the paragraph style in place. Ugly + * but there's ample precedence. - kw + */ + if (in_line_1) { + me->sp->style->spaceBefore = 0; /* temporary change */ + me->sp->style->spaceAfter = 0; /* temporary change */ + } HText_appendParagraph(me->text); + me->sp->style->spaceBefore = saved_spaceBefore; /* undo */ + me->sp->style->spaceAfter = saved_spaceAfter; /* undo */ me->in_word = NO; me->sp->style->alignment = HT_LEFT; } From owner-lynx-dev@sig.net Sat Apr 17 15:19:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA14896 for ; Sat, 17 Apr 1999 15:19:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA19398; Sat, 17 Apr 1999 14:12:50 -0500 (CDT) To: lynx-dev@sig.net References: <199904161528.LAA05207@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 23:07:58 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: lynx documentation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 474 Lines: 13 16-Apr-99 11:28 Philip Webb wrote: >> It's pity noone put this into Lynx_users_guide.html. > feel free to do so: don't forget your hard hat & safety boots ... You have a definite experience:) > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Sat Apr 17 15:20:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA14916 for ; Sat, 17 Apr 1999 15:20:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA19403; Sat, 17 Apr 1999 14:12:52 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 23:03:10 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1517 Lines: 32 15-Apr-99 03:50 Klaus Weide wrote: > (only commenting on the uncaching-related part of this; I haven't read >> > I found another bug: if there is something on the cache stack (say doc A >> > -current doc and doc B), and we go to 'O' and change something, only >> > appearance of 'A' is changed, the appearance of B is not changed - the cahced >> > version is used. IMO it will be better to uncache everything in the stack. >> > This is best tested with 'links are/not numbered' - since rendered versions >> > differ a lot. >> >> That was a very expensive solution before SOURCE_CACHE >> but now this can be done nicely by adding more parameters to the function >> above and avoid using of HTuncache_current_document() calls. >> Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy. > If the behavior is changed from "only reload top document after > relevant option change" to "reload all affected documents after option > change", then please make this optional/configurable. The current > behavior is maybe sometimes unexpected, but I generally prefer it over > the alternative. I know where the ^R key is if I need it, and would > like to avoid unnecessary reloading. I got a point of Klaus: currently with HTrerase_document() we lost a forms content (if any), so it is potentially a bad thing - user could not visit his history stack in certain situations. A better thing would be to store forms data somehow and restore it after reparsing. Still wait a volunteer. > Klaus From owner-lynx-dev@sig.net Sat Apr 17 15:43:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA15671 for ; Sat, 17 Apr 1999 15:43:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA22614; Sat, 17 Apr 1999 14:37:22 -0500 (CDT) From: ralph.usenet@gmx.net Message-ID: <19990417140123.A16523@cs.cornell.edu> Date: Sat, 17 Apr 1999 14:01:23 -0400 To: lynx-dev@sig.net Subject: lynx-dev lynx with -color and -lss Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 765 Lines: 27 Hello, I've been trying to compile Lynx 2.8.1 on my Linux system (Red Hat 5.2), since the original binary didn't support color styles (lss). Despite my earnest attempts, however, I won't get any color. I did /configure --enable-persistent-cookies \ --enable-color-style \ --enable-default-colors \ --enable-underlines \ --with-screen=ncurses but the resulting binary doesn't support the -color command line option. I've tried slang as well, to no avail. Could someone please elaborate why color is broken? I've spent _hours_ browsing news groups and the web but couldn't find any helpful information. Thanks, Ralph -- Ralph Benzinger "This is my theory, it is mine, I own it, PGP key on request and what it is, too." -- Ann Elk (Mrs. From owner-lynx-dev@sig.net Sat Apr 17 15:48:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA15732 for ; Sat, 17 Apr 1999 15:48:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA23332; Sat, 17 Apr 1999 14:42:50 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Sat, 17 Apr 1999 23:34:03 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev source cache & security MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 337 Lines: 10 I feel the source_cache, especially in temp files, is not the best solution for privacy. Perhaps https:// pages will got a bad joke also. Besides that, LYK_CLEAR_AUTH will not free the cache so access to already loaded data still possible. >From keymap page: _ CLEAR_AUTH clear all authorization info for this session From owner-lynx-dev@sig.net Sat Apr 17 16:19:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA16598 for ; Sat, 17 Apr 1999 16:19:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA27392; Sat, 17 Apr 1999 15:13:09 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 00:11:24 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 557 Lines: 15 15-Apr-99 00:51 Vlad Harchev wrote: > Here is a patch that implements this functionality (except brave approach). > It works as described. Features: ... > PS: It will be good if someone documented the 'include' command. As I > remember, even the description of the plain 'include' is absent in the docs. An INCLUDE behaviour mentioned breafly in Lynx Users Guide (near the bottom) with a pointer to LYNXCFG:/ page. But I think the real documentation should belong to lynx.cfg file itself. Probably few words of comments from you really welcome. From owner-lynx-dev@sig.net Sat Apr 17 16:39:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA17174 for ; Sat, 17 Apr 1999 16:39:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00050; Sat, 17 Apr 1999 15:32:56 -0500 (CDT) To: lynx-dev@sig.net, ralph.usenet@gmx.net References: <19990417140123.A16523@cs.cornell.edu> Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 00:27:36 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx with -color and -lss MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1212 Lines: 37 17-Apr-99 14:01 ralph.usenet@gmx.net wrote: > Hello, > I've been trying to compile Lynx 2.8.1 on my Linux system > (Red Hat 5.2), since the original binary didn't support > color styles (lss). Despite my earnest attempts, however, > I won't get any color. I did > /configure --enable-persistent-cookies \ > --enable-color-style \ > --enable-default-colors \ > --enable-underlines \ > --with-screen=ncurses > but the resulting binary doesn't support the -color > command line option. I've tried slang as well, to no > avail. Less advanced colors available *without* --enable-color-style. Lynx color styles need -lss=filename switch, it wouldn't be color without it. Someone more familiar with color styles will reply you later but this code considered as experimental - try the latest development version of lynx if you really concerned about lynx color styles. > Could someone please elaborate why color is broken? I've > spent _hours_ browsing news groups and the web but > couldn't find any helpful information. > Thanks, > Ralph > -- > Ralph Benzinger "This is my theory, it is mine, I own it, > PGP key on request and what it is, too." -- Ann Elk (Mrs. From owner-lynx-dev@sig.net Sat Apr 17 17:33:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA18948 for ; Sat, 17 Apr 1999 17:33:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA07157; Sat, 17 Apr 1999 16:27:53 -0500 (CDT) To: lynx-dev@sig.net References: <9903291650.aa03687@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 01:24:59 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: (PATCH) strange HTTP/HTCheckForInterrupt() bug lynx-dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1808 Lines: 54 29-Mar-99 16:50 Bela Lubkin wrote: > This fixes one of the reported problems (characters other than INTERRUPT > causing the DNS lookup delay to be shortened). It also fixes a serious > problem that I noticed while looking into the other reports: if fork() > failed, we were blindly going ahead and doing who knows what, including > kill(-1, SIGTERM)! On my system, that means "send SIGTERM to every > process with my UID" -- bad news indeed. > But I don't think that's what Leonid was running into. That's something > else, possibly the need to signal((various signals), quench) *before* > fork(). > CHANGES: > * Behave sanely if NSL_FORK fork() fails. -BL > * NSL_FORK try for dns_patience *seconds*, not dns_patience select() > calls, which might have been shortened by keyboard input. -BL > * Fix some screwy comment indentation. > uuencoded (and gzip'd) to try to preserve spaces/tabs. >>Bela< Today I got the same strange buged behaviour, now with dev22. Perhaps I press "z" in a "bad" moment (during DNS search or a little later). ^Z spawn me to a shell and "fg" return me back without visible problems. Exiting via interrupt: 15 [1]+ Stopped lynx [pauzner@mccme pauzner]$ ps -a PID TTY STAT TIME COMMAND 94 2 S 0:00 /sbin/mingetty tty2 230 5 S 0:00 /sbin/mingetty tty5 231 6 S 0:00 /sbin/mingetty tty6 19434 3 S 0:00 /sbin/mingetty tty3 28384 1 S 0:00 /sbin/mingetty tty1 32691 4 S 0:00 /sbin/mingetty tty4 22774 a0 S 0:00 /bin/bash 22776 a0 S 0:00 lynx 28310 q0 S 0:00 bash 2995 p1 S 0:00 -bash 16098 p9 S 0:00 bash 3203 p0 S 0:00 -bash 3215 p0 T 0:03 lynx 7156 p0 Z 0:00 (lynx ) 7261 p0 R 0:00 ps -a [pauzner@mccme pauzner]$ > --ATTACHMENT-- Binary file From owner-lynx-dev@sig.net Sat Apr 17 17:38:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA19007 for ; Sat, 17 Apr 1999 17:38:06 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA07634; Sat, 17 Apr 1999 16:31:09 -0500 (CDT) From: dickey@clark.net Message-Id: <199904172130.RAA01316@shell.clark.net> Subject: Re: lynx-dev lynx with -color and -lss To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 17:30:44 -0400 (EDT) In-Reply-To: <19990417140123.A16523@cs.cornell.edu> from "ralph.usenet@gmx.net" at Apr 17, 99 02:01:23 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1585 Lines: 48 > Hello, > > I've been trying to compile Lynx 2.8.1 on my Linux system > (Red Hat 5.2), since the original binary didn't support > color styles (lss). Despite my earnest attempts, however, > I won't get any color. I did > > /configure --enable-persistent-cookies \ > --enable-color-style \ > --enable-default-colors \ > --enable-underlines \ > --with-screen=ncurses > > but the resulting binary doesn't support the -color > command line option. I've tried slang as well, to no > avail. the -color option is a hack for the slang library (basically says do color even if the terminal description says it doesn't). lynx does color automatically if you are linked with ncurses. (it's not been an faq, but we could add a dummy option for this case) if you're able to get color with the ncurses tests (i.e., you have installed ncurses terminfo), you should be able to get color with lynx with no problem. the lss file handling is a problem: there's no error reported if the lynx.lss file isn't installed and you give no -lss option, but the colors are not right then (but as LP notes, the feature's not well supported since it's considered experimental). > > Could someone please elaborate why color is broken? I've > spent _hours_ browsing news groups and the web but > couldn't find any helpful information. > > Thanks, > Ralph > > -- > Ralph Benzinger "This is my theory, it is mine, I own it, > PGP key on request and what it is, too." -- Ann Elk (Mrs. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 17:39:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA19023 for ; Sat, 17 Apr 1999 17:39:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA07372; Sat, 17 Apr 1999 16:29:17 -0500 (CDT) From: larrywyb@larry.dhis.org Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 17 Apr 1999 16:30:17 -0000 (GMT) To: lynx-dev@sig.net Subject: lynx-dev More color style questions Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 696 Lines: 26 I have been trying to configure the most recent version of lynx to work with color style. I have edited the userdefs.h and tried to run the configure script with: --enable-color-style --enable-default-color --with-screen=slang When configure gets to the color_style part I get the following error: checking if color_style code should be used... configure: error: configuration does not support color styles. I have read and edited the userdefs.h a number of times, as well as read the INSTALLATION text but can't figure out what could be causing this. What am I missing? If I configure and build it without the --enable-color-style everthing works fine. What's the deal? (: Thanks From owner-lynx-dev@sig.net Sat Apr 17 17:47:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA19271 for ; Sat, 17 Apr 1999 17:47:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA09106; Sat, 17 Apr 1999 16:42:04 -0500 (CDT) Date: Sun, 18 Apr 1999 01:41:54 +0400 From: Michael Sobolev To: lynx-dev@sig.net Subject: lynx-dev addition to documentation. commenting. Message-ID: <19990418014154.A32086@transas.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" X-Mailer: Mutt 0.95.4i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1529 Lines: 41 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Disclaimer. It's the English I use. If someone has a better one, please correct the text to make it more English. Thanks, -- Mike --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="lug.diff" --- Lynx_users_guide.html.old Sun Apr 18 01:23:27 1999 +++ Lynx_users_guide.html Sun Apr 18 01:36:22 1999 @@ -909,8 +909,18 @@ At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current -document if the author of the document has specified ownership. If no -ownership is specified then comments are disabled. Certain links called +document if the author of the document has specified ownership. (Note to +authors: if you want to assign the ownership to your document, you need to add +into HEAD section a LINK element with appropriate value for REV attribute. Two +values are recognized: owner and made (these are case +insensitive). For example,
      +<HEAD>
      +    …
      +    <LINK REV="made" HREF="mailto:user@somedomain.com">
      +    …
      +<HEAD>
      +
      You may also add TITLE attribute with, for example, name of yours.) If +no ownership is specified then comments are disabled. Certain links called mailto: links will also allow you to send mail to other people. Using the mail features within Lynx is straightforward. --0F1p//8PRICkK4MW-- From owner-lynx-dev@sig.net Sat Apr 17 18:52:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA20913 for ; Sat, 17 Apr 1999 18:52:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA17441; Sat, 17 Apr 1999 17:43:59 -0500 (CDT) From: larrywyb@larry.dhis.org Message-ID: <19990417174500.26985@larry.dhis.org> Date: Sat, 17 Apr 1999 17:45:00 +0000 To: lynx-dev@sig.net Subject: Re: lynx-dev More color style questions References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from larrywyb@larry.dhis.org on Sat, Apr 17, 1999 at 04:30:17PM -0000 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 423 Lines: 17 On Sat, Apr 17, 1999 at 04:30:17PM -0000, larrywyb@larry.dhis.org wrote: > > > > I have been trying to configure the most recent version > of lynx to work with color style. > > I have edited the userdefs.h and tried to run the configure > script with: > --enable-color-style > --enable-default-color > --with-screen=slang Yadda yadda yadda... Never mind, I figured it all out. (: Sorry to bother anybody. Larry From owner-lynx-dev@sig.net Sat Apr 17 18:54:10 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA21114 for ; Sat, 17 Apr 1999 18:54:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA17862; Sat, 17 Apr 1999 17:47:10 -0500 (CDT) Date: Sat, 17 Apr 1999 18:17:11 -0400 (EDT) From: News Subsystem Message-Id: <199904172217.SAA10639@news.put.com> To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-URL: http://www.slcc.edu/lynx/html/todo-list.html X-Mailer: Lynx, Version 2.8.1rel.2 Subject: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html Cc: le@put.com Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 479 Lines: 11 I'm not sure if the tod-list is being actively maintained...but the stuff on there about Cookies seems too cookie-friendly...how about a feature that can be set to cache-and-erase all cookies,a la Junkbuster?Or a pernmanent list of domains for each user to really "neVer accept" rather than having to enter the V command every session? Beyond that,I'm puzzled as to why high-bidder lists at the domain www.surplusauction.com are accessible to 2.6 but not to 2.8.1. le@put.com From owner-lynx-dev@sig.net Sat Apr 17 19:19:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA21838 for ; Sat, 17 Apr 1999 19:19:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA20906; Sat, 17 Apr 1999 18:11:48 -0500 (CDT) From: dickey@clark.net Message-Id: <199904172311.TAA00120@shell.clark.net> Subject: Re: lynx-dev lynx and ncurses and gpm To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 19:11:15 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 17, 99 03:42:14 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1175 Lines: 25 > 3. Yep, the ABI has changed (just confirming...). > However, running an older lynx binary compiled against the previous > ncurses version mostly works when linked at runtime against the new > library (via a bogus symlink), but with completely wrong colors > (only tried an --enable-color-style binary). Where it crashed > is in parsing the > setkey "^(cuu1)" UPARROW > setkey "^(up)" UPARROW > entries from a .lynx-keymaps file (no crash after commenting them out). not entirely ncurses - I ran some more tests and found I'd missed a null pointer check in the Lynx side (it'll be in dev.23). The Strings array reference in expand_tiname needs the check. -- I don't know offhand why it would break now and not before, since before and after my ncurses changes it would (when the capability is undefined) be a null pointer. (In fact, it didn't break this morning when I first ran the test, but did later, using the same ~/lynx-keymaps file, when I went to use Lynx to check an html file for something I'm installing ;-) > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Apr 17 19:19:58 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA21852 for ; Sat, 17 Apr 1999 19:19:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA20939; Sat, 17 Apr 1999 18:12:04 -0500 (CDT) Message-Id: <19990418031150.01920@firepower> Date: Sun, 18 Apr 1999 03:11:50 +0400 From: Sergey Svishchev To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths Mail-Followup-To: lynx-dev@sig.net References: <199904161049.GAA09644@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <199904161049.GAA09644@chass.utoronto.ca>; from Philip Webb on Fri, Apr 16, 1999 at 06:49:21AM -0400 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 433 Lines: 11 On Fri, Apr 16, 1999 at 06:49:21AM -0400, Philip Webb wrote: > how many lynx-devers regularly use Lynx with a screen width > noticeably more/less than 79 chars & in what contexts? I started using 90x25 OS/2 window just two days back. DejaNews (which I frequent) looks much better in this format, as does www.price.ru (but that site now needs even longer line width for its listings). -- Sergey Svishchev -- svs{at}ropnet{dot}ru From owner-lynx-dev@sig.net Sat Apr 17 19:44:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA22583 for ; Sat, 17 Apr 1999 19:44:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA24091; Sat, 17 Apr 1999 18:37:57 -0500 (CDT) From: mattack@area.com Date: Sat, 17 Apr 1999 16:37:54 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths In-Reply-To: <199904170731.DAA24511@chass.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 432 Lines: 9 On Sat, 17 Apr 1999, Philip Webb wrote: >the reason for making CRT terminals 80-col seems most likely to have been >that on a 12" screen it gives characters roughly paper-printing size; >some very early personal computers had 40-col displays, >probably due to their very small memories or processors. I think it's because the video hardware required is more complicated. Also it's harder to display clear 80 column text on a TV. From owner-lynx-dev@sig.net Sat Apr 17 21:14:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA24980 for ; Sat, 17 Apr 1999 21:14:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA05124; Sat, 17 Apr 1999 20:08:37 -0500 (CDT) From: larrywyb@larry.dhis.org Message-ID: <19990417200937.13398@larry.dhis.org> Date: Sat, 17 Apr 1999 20:09:37 +0000 To: lynx-dev@sig.net Subject: lynx-dev realaudio Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 665 Lines: 22 There is a little script program called rap that runs the realplayer from a text session. I have been trying to get it to work with Lynx but anytime I click on a link to a realaudio stream, lynx drops an html file to the /tmp directory instead of a .ra or .ram file. I may get a file that looks like this: L7854_3TMP.html that contains the realaudio.ra address inside of it. Is there anyway to get Lynx to drop the .ra/.ram file to /tmp instead? I have the mime tupes setup and the mailcap also. The little program works from the command line and would work from lynx if only I could get it to drop the .ra file name to /tmp to be read. Any tips? Thanks From owner-lynx-dev@sig.net Sat Apr 17 21:24:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA25223 for ; Sat, 17 Apr 1999 21:24:21 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA06552; Sat, 17 Apr 1999 20:18:59 -0500 (CDT) Date: Sat, 17 Apr 1999 18:18:48 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Cc: le@put.com Subject: Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html In-Reply-To: <199904172217.SAA10639@news.put.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 474 Lines: 14 On Sat, 17 Apr 1999, le wrote: > Beyond that,I'm puzzled as to why high-bidder lists at the domain > www.surplusauction.com are accessible to 2.6 but not to 2.8.1. It would help if you gave the full URL that is giving you trouble. A recent development version doesn't have trouble getting to "http://www.surplusauction.com/images/high_bidders.gif". Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Apr 17 22:09:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA26362 for ; Sat, 17 Apr 1999 22:09:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12155; Sat, 17 Apr 1999 21:02:45 -0500 (CDT) Date: Sat, 17 Apr 1999 19:02:40 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: Louis Epstein Cc: lynx-dev@sig.net Subject: Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1175 Lines: 29 On Sat, 17 Apr 1999, Louis Epstein wrote: > > It would help if you gave the full URL that is giving you trouble. > > A recent development version doesn't have trouble getting to > > "http://www.surplusauction.com/images/high_bidders.gif". > > Doug > > An example... > http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601&UID=DF1 > has,for Lynx 2.6,a functioning link "Click here to view high bidders list" > to > http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601~HI&UID=DF1 > > but in 2.8.1 the "Click here..." is dead text,not a link. > (This is typical of lots). You need to turn on "image links". While in lynx, you control this with the "*" key. It can also be set from your .lynxrc file via the options page or from the lynx.cfg file with "MAKE_LINKS_FOR_ALL_IMAGES". The command line switch "-image_links" also toggles this. I keep this turned on all the time, only turning it off if the screen is too cluttered. It also controls whether or not the links are shown with the "A" or "L" commands. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 18 02:14:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA00850 for ; Sun, 18 Apr 1999 02:14:34 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA10471; Sun, 18 Apr 1999 01:07:50 -0500 (CDT) Date: Sun, 18 Apr 1999 01:07:45 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net cc: ralph.usenet@gmx.net Subject: Re: lynx-dev lynx with -color and -lss In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1662 Lines: 50 On Sun, 18 Apr 1999, Leonid Pauzner wrote: > 17-Apr-99 14:01 ralph.usenet@gmx.net wrote: > > Hello, > > > I've been trying to compile Lynx 2.8.1 on my Linux system > > (Red Hat 5.2), since the original binary didn't support > > color styles (lss). Despite my earnest attempts, however, > > I won't get any color. I did > > > /configure --enable-persistent-cookies \ > > --enable-color-style \ > > --enable-default-colors \ > > --enable-underlines \ > > --with-screen=ncurses That should work fine, at least with a not-too-old version of ncurses. > > but the resulting binary doesn't support the -color > > command line option. I've tried slang as well, to no > > avail. > > Less advanced colors available *without* --enable-color-style. And as Tom notes, the -color flag is only for slang and isn't needed otherwise (with or without color-style). > Lynx color styles need -lss=filename switch, it wouldn't be color without it. It's not needed if the *.lss file is found in the location compiled in (set either in lynx_cfg.h by configure or in userdefs.h). If you terminal type according to $TERM supports color (well enough), colors will be used. > Someone more familiar with color styles will reply you later > but this code considered as experimental - > try the latest development version of lynx if you > really concerned about lynx color styles. I agree that 2.8.2dev.N should be better. > > Could someone please elaborate why color is broken? I've > > spent _hours_ browsing news groups and the web but > > couldn't find any helpful information. This list is the best place, there isn't much else afaik. Klaus From owner-lynx-dev@sig.net Sun Apr 18 02:37:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA01535 for ; Sun, 18 Apr 1999 02:37:25 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA12252; Sun, 18 Apr 1999 01:32:37 -0500 (CDT) Date: Sun, 18 Apr 1999 01:32:33 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev realaudio In-Reply-To: <19990417200937.13398@larry.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1292 Lines: 36 On Sat, 17 Apr 1999 larrywyb@larry.dhis.org wrote: > There is a little script program called rap that runs the > realplayer from a text session. I have been trying to get it > to work with Lynx but anytime I click on a link to a realaudio > stream, lynx drops an html file to the /tmp directory instead > of a .ra or .ram file. I may get a file that looks like this: > L7854_3TMP.html that contains the realaudio.ra address inside > of it. > > Is there anyway to get Lynx to drop the .ra/.ram file to /tmp > instead? > > I have the mime tupes setup and the mailcap also. If the only problem is the name that lynx chooses - you probably haven't set up mime types right. You should have something like this in the relevant mime.types or .mime.types file: audio/x-pn-realaudio ra rm ram You may have to change there order of the suffixed; it seems lynx uses the last one for generating the temp filename. Also check that the mIME type sent by the server is actually audio/x-pn-realaudio (try ']' HEAD). > The little program works from the command line and would work > from lynx if only I could get it to drop the .ra file name to > /tmp to be read. Of course you could always write a little script around the script that just renames or copies the file. Klaus From owner-lynx-dev@sig.net Sun Apr 18 03:02:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA02281 for ; Sun, 18 Apr 1999 03:02:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA13990; Sun, 18 Apr 1999 01:57:45 -0500 (CDT) Date: Sat, 17 Apr 1999 23:57:41 -0700 From: Michael Warner To: lynx-dev@sig.net Subject: Re: http://www.slcc.edu/lynx/html/todo-list.html [lynx-dev] Message-ID: <19990417235741.A740@unicorn.it.wsu.edu> Mail-Followup-To: lynx-dev@sig.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Doug Kaufman on Sat, Apr 17, 1999 at 07:02:40PM -0700 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2162 Lines: 52 On or about 17 Apr, 1999, Doug Kaufman wrote: > On Sat, 17 Apr 1999, Louis Epstein wrote: > > > > It would help if you gave the full URL that > > > is giving you trouble. A recent development > > > version doesn't have trouble getting to > > > "http://www.surplusauction.com/images/high_bidders.gif". > > > > An example... > > http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601&UID=DF1 > > has,for Lynx 2.6,a functioning link "Click here to view high > > bidders list" to > > http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601~HI&UID=DF1 > > > > but in 2.8.1 the "Click here..." is dead text,not a link. > > (This is typical of lots). > > You need to turn on "image links". While in lynx, you > control this with the "*" key. It can also be set from your > .lynxrc file via the options page or from the lynx.cfg file > with "MAKE_LINKS_FOR_ALL_IMAGES". The command line switch > "-image_links" also toggles this. I keep this turned on all the > time, only turning it off if the screen is too cluttered. It > also controls whether or not the links are shown with the "A" > or "L" commands. I don't think that's the problem. They use an IMG in place of link text, and the '*' key just gets the IMG url (.../high_bidders.gif), not the url of the bidders list. The link he wants is available as a "hidden link" on the 'L'inks page. Using the "-hiddenlinks=merge" commandline switch with links numbered gets a number assigned to the hidden link, making it much easier to find on the 'L'inks page (the urls are pretty cryptic). Note 1 - I think "-hiddenlinks" is documented in the man page, but not in lynx_help. Patch forthcoming. Note 2 - I can't, off-hand, think of any way of making hidden links selectable on the page itself, but there may be one. Note 3 - www.surplus.com seems to use a hefty dose of invalid commenting. Depending on your configuration, you may need to try one of lynx's "forgiving" settings to see the whole page. See the 'K'eymap page for the comment-parsing options. A backtick ("`") works for me. -- Michael Warner "You're cute when you're stupid" -- R.A. Miller From owner-lynx-dev@sig.net Sun Apr 18 03:10:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA02527 for ; Sun, 18 Apr 1999 03:10:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA14287; Sun, 18 Apr 1999 02:00:59 -0500 (CDT) From: newsmgr@mhl.nsw.gov.au Date: Sun, 18 Apr 1999 17:00:08 +1000 Message-Id: <99041817000806@mhl.nsw.gov.au> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx dev22 on VMS - Results X-VMS-To: @MHL_LYNX-DEV.DIS Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1379 Lines: 41 Re Build problem on VMS Thanks for several replies, the most useful was... >Sorry, my fault, >this function not used for VMS, should be ifdef'ed with >#if !defined(VMS) && defined(HAVE_READDIR) I did this and the result was almost clean $ cc [-.Implementation]HTTCP.c #define h_errno my_errno ................^ %CC-W-MACROREDEF, The redefinition of the macro "h_errno" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. at line number 575 in file [LYNX2-8-2.WWW.LIBRARY.IMPLEMENTATION]HTTCP.C;1 I also tried to build on a VAX (VMS 5.5-2, VAX C 3.2, UCX 4.2). It failed like this... $ cc LYrcFile # This file contains options saved from the Lynx Options Screen (normally\n\ %CC-W-INVPPKEYWORD, Missing or invalid keyword in preprocessor directive; directive ignored. Listing line number 21152. At line number 547 in [LYNX2-8-2.SRC]LYRCFILE.C;1. Followed by many repeats and a confused fatal error. Regards * * * * * Tony Bolton **** **** ** ** ** TBolton 'at' mhl.nsw.gov.au ** **** ** ********* ** MANLY HYDRAULICS LABORATORY. ** ** ** ********* ** 110B King ST. Manly Vale 2093 Sydney AUSTRALIA ** ** ** ** ******** Phone +61 2 99490200 FAX +61 2 99486185 * * * * ****** http://www.mhl.nsw.gov.au From owner-lynx-dev@sig.net Sun Apr 18 05:14:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA06592 for ; Sun, 18 Apr 1999 05:14:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22905; Sun, 18 Apr 1999 04:08:36 -0500 (CDT) Date: Thu, 15 Apr 1999 05:52:11 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2084 Lines: 46 On Sun, 18 Apr 1999, Leonid Pauzner wrote: > 15-Apr-99 00:51 Vlad Harchev wrote: > > Here is a patch that implements this functionality (except brave approach). > > It works as described. Features: > ... > > > PS: It will be good if someone documented the 'include' command. As I > > remember, even the description of the plain 'include' is absent in the docs. > > An INCLUDE behaviour mentioned breafly in Lynx Users Guide (near the bottom) > with a pointer to LYNXCFG:/ page. But I think the real documentation > should belong to lynx.cfg file itself. Probably few words of comments > from you really welcome. If TD confirm that this patch will be integrated I'l try, but I afraid of my English. Also I have the following idea: We can write the documentation for the lynx.cfg in html (and each option will have an anchor consisting of it's name). When adding new options/changing behaviour of the options, we will modify that html file. And we can write the script that will regenerate the comments in lynx.cfg automatically: (by cutting the html piece corresponding to each option (with sed), rendering that piece to text with lynx) and prefixing the rendered text with '#'. I think the script will be easy to write. After having moved all docs to some html file( say it will be lynxcfg.html), we can do even more: when generating the contents of LYNXCFG:// in read_cfg, we can make each option name 'X' used to be a hyperlink with href 'lynxcfg.html#X' - so user can quickly explore documentation for each option s/he used. More explanation: if the was a following line in lynx.cfg: STARTFILE:http://lynx.browser.org current code in LYReadCFG.c:read_cfg will generate the following piece of code STARTFILE:http://lynx.browser.org (ie copy it). After moving all option description to lynxcfg.html, we can generate the following entry: > relevant option change" to "reload all affected documents after option > > change", then please make this optional/configurable. The current > > behavior is maybe sometimes unexpected, but I generally prefer it over > > the alternative. I know where the ^R key is if I need it, and would > > like to avoid unnecessary reloading. > > I got a point of Klaus: currently with HTrerase_document() > we lost a forms content (if any), so it is potentially a bad thing - > user could not visit his history stack in certain situations. > > A better thing would be to store forms data somehow and restore it > after reparsing. Still wait a volunteer. I also wait for a volunteer :). May be Klaus approach is the best. In this case volunteer has to hack lynx to store the state of the current document when something is changed in 'options' page. Best regards, -Vlad From owner-lynx-dev@sig.net Sun Apr 18 05:14:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA06602 for ; Sun, 18 Apr 1999 05:14:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22893; Sun, 18 Apr 1999 04:08:30 -0500 (CDT) Date: Thu, 15 Apr 1999 07:03:42 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev removing strings used in CTRACE when configured without tracing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3178 Lines: 109 The are several approaches: 1)Use a feature of gcc - macros with variable number of arguments, in this case we can do the following #ifndef DEBUG # define CTRACE(f, args...) /*nothing*/ #else ... I don't know whether cccp - a c preprocessor distributed with GCC can do that, but gcc supports it. 2) First I've written the following script _____________ # copyright 1999 by Vlad Harchev . Distributed under GPL. #args - the file names to process #this will match C string that doesn't wrap lines CSTR='\("\([^"]*\(\\"\)*\)*"\)'; CTRACE='\(CTRACE[ \t]*([ \t]*[A-z_][_A-z0-9]*[ \t]*,[ \t]*\)'; tmpnm="_tmp$$"; for i; do echo converting $i mv $i $tmpnm && sed -e 's/'"$CTRACE"'\(\('"$CSTR"'[ \t]*\)*\)\([,)]\)/\1CT_(\2)\7/g' \ $tmpnm > $i && rm $tmpnm; done; ____________ It includes the string used as format specifier in the parentheses preceded by CT_ (assumming that we'l define macro CT_(x) ). So, the following line CTRACE( f, "text" "text \"more", params); will be substituted with CTRACE( f, CT_("text" "text \"more"), params); But I found this inacceptable, since when the string constant is long enough, the sed processes each string VERY slow. The file I processed with sed was of the form (file had only 1 line): CTRACE( f, "123456789_123456789" ); It takes 37 seconds for sed to substitute this line (correctly tho'). I have 5x86-133, 32MB of RAM (and no cpu-hungry jobs). Seems that sed I'm using is broken - it's GNU sed-3.02 (was supplied with my RedHat 5.2). Probably it's a bug in regexp code. For shorter lines, like CTRACE( f, "123456789_123456" ); it takes 5 seconds (the string is 3 chars shorter as you see). BTW, can you test the script with other seds (probaly with GNU sed 2.x) 3) So I wrote the the small program using lex (it does the same as script above, but very fast). --------------ctrace-wrap.l----- /* copyright 1999 by Vlad Harchev . Distributed under GPL.*/ %x SEENCTRACE %option noyywrap %{ #include %} W ([ \t\n]*) CSTR (\"([^"\\]*(\\\")*)*\") %% CTRACE{W}\({W}[A-z_][A-z_0-9]*{W},{W} { fwrite(yytext,yyleng,1,stdout); BEGIN(SEENCTRACE); } ({CSTR}{W})* { fwrite("CT_(",4,1,stdout); fwrite(yytext,yyleng,1,stdout); fwrite(")",1,1,stdout); BEGIN(0); } %% void main() { yylex(); }; ---------------------------- It should be called by a script that will process all files passed. So, to remove all string literals from lynx binary when lynx configured with --disable-trace, the following strings should be added to HTUtils.h: #ifndef DEBUG # define CT_(x) NULL #else # define CT_(x) x #endif So the new rule for using CTRACE macro: *wrap the format specifier string in CT_(), eg instead of CTRACE( tfp, "foo" ); use CTRACE( tfp, CT_("foo") ); More ideas: may be it will be useful to define CT_ the following way #ifndef DEBUG # define CT_(x) NULL #else # define do_xstr(x) #x # define xstr(x) do_xstr(x) # define CT_(x) __FILE_ ":" xstr(__LINE__) " " x #endif so each CTRACE record will be preceeded with the name of the file and the line where CTRACE was invoked. Best regards, -Vlad From owner-lynx-dev@sig.net Sun Apr 18 05:28:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07080 for ; Sun, 18 Apr 1999 05:28:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04536; Sun, 18 Apr 1999 04:23:57 -0500 (CDT) From: David Woolley Message-Id: <199904170840.JAA16734@djwhome.demon.co.uk> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 09:40:25 +0100 (BST) In-Reply-To: <199904170731.DAA24511@chass.utoronto.ca> from "Philip Webb" at Apr 17, 99 03:31:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 663 Lines: 13 > the reason for making CRT terminals 80-col seems most likely to have been > that on a 12" screen it gives characters roughly paper-printing size; Not printing, only typewriting, but another good reason is that that is what you get when you use the smallest practical dot matrix pattern with square pixels on a US TV monitor non-interlaced. > some very early personal computers had 40-col displays, > probably due to their very small memories or processors. The main reason is that it represents about the maximum you can get accurately through the aerial socket of a domestic television, i.e 240 pixels in about 60 microseconds, or 4 mega pixels per second. From owner-lynx-dev@sig.net Sun Apr 18 05:28:39 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07089 for ; Sun, 18 Apr 1999 05:28:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04429; Sun, 18 Apr 1999 04:22:44 -0500 (CDT) From: David Woolley Message-Id: <199904170940.KAA16939@djwhome.demon.co.uk> Subject: Re: lynx-dev LYNX 2.8rel.2 and INPUT TYPE=FILE To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 10:40:08 +0100 (BST) In-Reply-To: from "Matthias Knopf" at Apr 14, 99 06:42:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 146 Lines: 4 > So, my question is: When will this be implemented? (i hope, that it is > planed for the near future!!!) When are *you* planning on writing it? From owner-lynx-dev@sig.net Sun Apr 18 05:28:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07081 for ; Sun, 18 Apr 1999 05:28:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04434; Sun, 18 Apr 1999 04:22:47 -0500 (CDT) From: David Woolley Message-Id: <199904170937.KAA16930@djwhome.demon.co.uk> Subject: Re: lynx-dev Problem with lynx 2.8.1 To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 10:37:53 +0100 (BST) In-Reply-To: from "Vahid Sanei" at Apr 15, 99 09:16:45 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 467 Lines: 13 > - OS= Linux 2.0.3 Linux 2.0.3 was so early in the 2.0.x series that it will be quite buggy. (In my view, the 2.0.x series was released too early.) The current released 2.0.x kernel is 2.0.36 or 2.0.37. Also, this problem relates to libraries, so the kernel version is irrelevant, but the distribution is quite important. > - Terminal type= vt100 VT100s are strictly monochrome devices, any colouring is the result of something ignoring the true terminal type. From owner-lynx-dev@sig.net Sun Apr 18 05:28:53 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07100 for ; Sun, 18 Apr 1999 05:28:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04520; Sun, 18 Apr 1999 04:23:50 -0500 (CDT) From: David Woolley Message-Id: <199904170845.JAA16743@djwhome.demon.co.uk> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 09:45:16 +0100 (BST) In-Reply-To: <19990417021742.B8131@delta.Nexus.of.Obsolescence> from "Chuck Martin" at Apr 17, 99 02:17:42 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 587 Lines: 13 > these structures. Are we to make them all configurable from lynx.cfg or > the options page? If not, which ones should be configurable? I think *If* you are going to make them configurable, anything other than useing Cascading Style Sheets language in an external style sheet would be a dead end development. > Maybe we should instead consider documenting this behavior so that users > can better understand what they're looking at. GUI authors who override browser default style sheets, or otherwise try to control the physical presentation, never seem to document their styles! From owner-lynx-dev@sig.net Sun Apr 18 05:30:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA07118 for ; Sun, 18 Apr 1999 05:30:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04441; Sun, 18 Apr 1999 04:22:50 -0500 (CDT) From: David Woolley Message-Id: <199904170949.KAA16954@djwhome.demon.co.uk> Subject: Re: lynx-dev Commenting... To: lynx-dev@sig.net Date: Sat, 17 Apr 1999 10:49:22 +0100 (BST) In-Reply-To: from "Vlad Harchev" at Apr 14, 99 03:22:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 637 Lines: 11 > A lot of attrs whose value is href are not supported - span.href, div.href, > {img,frame,iframe}.longdesc , {q,blockquote,ins,del,}.cite - they are I'm not aware of any page that uses these in anger and I've failed to get longdesc to work in IE4 or NS4 in any detectable way. In a commercial environment, such attributes would never get maintained, as they might get put in by someone who really understood HTML, but the average HTML cut and paste coder would not be aware they existed. On the other hand, if they are easy to do, they should be done. They need to be done in a way that doesn't interfere with an overlapping . From owner-lynx-dev@sig.net Sun Apr 18 06:52:09 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA09201 for ; Sun, 18 Apr 1999 06:52:09 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA09637; Sun, 18 Apr 1999 05:43:50 -0500 (CDT) Date: Sun, 18 Apr 1999 06:43:15 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904180643.AA17199@cas.org> Subject: Re: lynx-dev lynx with -color and -lss In-Reply-To: <199904172130.RAA01316@shell.clark.net> of Sat, 17 Apr 1999 17:30:44 -0400 (EDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 947 Lines: 20 >> but the resulting binary doesn't support the -color > >the -color option is a hack for the slang library (basically >says do color even if the terminal description says it doesn't). >lynx does color automatically if you are linked with ncurses. >installed ncurses terminfo), you should be able to get color with lynx >with no problem. That is - if you use a terminal emulator capable of supporting color, configured in the proper way, you should be able to get color with lynx with no problem. If you are not getting color, tell us what OS, what terminal emulator, what $TERM and what terminfo entry you are using - perhaps it's a matter of not using the right combination. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Sun Apr 18 06:59:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA09419 for ; Sun, 18 Apr 1999 06:59:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA10073; Sun, 18 Apr 1999 05:50:26 -0500 (CDT) Date: Sun, 18 Apr 1999 06:49:52 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904180649.AA17255@cas.org> Subject: Re: lynx-dev lynx with -color and -lss In-Reply-To: Your message of Sun, 18 Apr 1999 01:07:45 -0500 (CDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 773 Lines: 18 From: Klaus Weide > I agree that 2.8.2dev.N should be better. I tried the dev.22 vesion of color styles but configured it back out again when I noticed lynx tended (for me anyways) to write a line overtop of the expert mode URL display. I didn't report it here because I knew the average response was 'lss support is experimental' and I didn't have time this week to chase down any more details. Perhaps someone else using lss if they are seeing a problem can report more details. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Sun Apr 18 07:00:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA09448 for ; Sun, 18 Apr 1999 07:00:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA10227; Sun, 18 Apr 1999 05:53:17 -0500 (CDT) From: David Woolley Message-Id: <199904181026.LAA01047@djwhome.demon.co.uk> Subject: Re: lynx-dev patch: add downloaders to Main Help To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 11:26:48 +0100 (BST) In-Reply-To: from "Ismael Cordeiro" at Apr 16, 99 10:35:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 400 Lines: 8 > > +
    • WGET > > + -- powerful & flexible non-interactive downloader > > I think it's better to send people directly to the source: This *is* the source! The ftp.gnu.org version is derived from this one not the other way round. On the other hand, ftp.gnu.org probably has better bandwidth and may have slightly more stable versions. From owner-lynx-dev@sig.net Sun Apr 18 07:25:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA10011 for ; Sun, 18 Apr 1999 07:25:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA11758; Sun, 18 Apr 1999 06:16:38 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181116.HAA06860@shell.clark.net> Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 07:16:19 -0400 (EDT) In-Reply-To: from "Vlad Harchev " at Apr 15, 99 05:52:11 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 824 Lines: 22 > On Sun, 18 Apr 1999, Leonid Pauzner wrote: > > > PS: It will be good if someone documented the 'include' command. As I > > > remember, even the description of the plain 'include' is absent in the docs. > > > > An INCLUDE behaviour mentioned breafly in Lynx Users Guide (near the bottom) > > with a pointer to LYNXCFG:/ page. But I think the real documentation > > should belong to lynx.cfg file itself. Probably few words of comments > > from you really welcome. > > If TD confirm that this patch will be integrated I'l try, but I afraid of my > English. LP sends in documentation; you both are understandable; I make fixes (grammar and spelling), and other people may also make fixes. But a starting point is needed. > -Vlad -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 07:28:04 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA10237 for ; Sun, 18 Apr 1999 07:27:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12049; Sun, 18 Apr 1999 06:20:57 -0500 (CDT) Date: Thu, 15 Apr 1999 09:23:24 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev bug in lynx with lss (radiobuttons in tables) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1132 Lines: 43 When viewing the following file, the radiogroup looks incorrectly. Try selecting various items and notice how the color of the '( )' changes. To be viewed with distribution's mild-colors.lss. Notice that this .lss file doesn't assign 'gray' to any style, tho' the color of the '(*)' is gray at the very begining. Best regards, -Vlad localhost.localdomain:Type of interface

      Type of interface


      Linuxconf 1.12 (subrev 5)
      .Network configurator


      PPP
      SLIP
      PLIP

      From owner-lynx-dev@sig.net Sun Apr 18 07:31:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA10264 for ; Sun, 18 Apr 1999 07:31:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12285; Sun, 18 Apr 1999 06:24:19 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181124.HAA19710@shell.clark.net> Subject: Re: lynx-dev lynx dev22 on VMS - Results To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 07:24:00 -0400 (EDT) In-Reply-To: <99041817000806@mhl.nsw.gov.au> from "newsmgr@mhl.nsw.gov.au" at Apr 18, 99 05:00:08 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1421 Lines: 46 > Re Build problem on VMS > > Thanks for several replies, the most useful was... > > >Sorry, my fault, > >this function not used for VMS, should be ifdef'ed with > >#if !defined(VMS) && defined(HAVE_READDIR) > > I did this and the result was almost clean > > $ cc [-.Implementation]HTTCP.c > > #define h_errno my_errno ok - I'll fix this (I hope) in dev.23 > ................^ > %CC-W-MACROREDEF, The redefinition of the macro "h_errno" conflicts with a > current definition because the replacement lists differ. > The redefinition is now in effect. > at line number 575 in file [LYNX2-8-2.WWW.LIBRARY.IMPLEMENTATION]HTTCP.C;1 > > I also tried to build on a VAX (VMS 5.5-2, VAX C 3.2, UCX 4.2). > It failed like this... > > $ cc LYrcFile > # This file contains options saved from the Lynx Options Screen (normally\n\ > %CC-W-INVPPKEYWORD, Missing or invalid keyword in preprocessor > directive; directive ignored. > Listing line number 21152. > At line number 547 in [LYNX2-8-2.SRC]LYRCFILE.C;1. > > Followed by many repeats and a confused fatal error. hmm. - I wonder why we didn't hit this before. It's relatively simple to code around though (replace the long strings by an array, print them with a "# %s\n" format). I'll try that. thanks. > * * * * * Tony Bolton -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 07:33:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA10282 for ; Sun, 18 Apr 1999 07:33:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12447; Sun, 18 Apr 1999 06:26:56 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181126.HAA02240@shell.clark.net> Subject: Re: lynx-dev lynx with -color and -lss To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 07:26:17 -0400 (EDT) In-Reply-To: <9904180649.AA17255@cas.org> from "lvirden@cas.org" at Apr 18, 99 06:49:52 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 771 Lines: 23 > From: Klaus Weide > > > I agree that 2.8.2dev.N should be better. > > > I tried the dev.22 vesion of color styles but configured it back out again > when I noticed lynx tended (for me anyways) to write a line overtop > of the expert mode URL display. > > I didn't report it here because I knew the average response was 'lss support > is experimental' and I didn't have time this week to chase down any more > details. Perhaps someone else using lss if they are seeing a problem > can report more details. well, it's experimental, but some of us would like to know how to reproduce the effect. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 08:08:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11312 for ; Sun, 18 Apr 1999 08:08:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA14348; Sun, 18 Apr 1999 06:54:05 -0500 (CDT) To: dickey@clark.net Cc: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 15:49:41 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev more dev22 patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7874 Lines: 249 Assorted notes: - Oddly, some of the commands I modified reload the document by faking an LYK_RELOAD, and some by calling HTuncache_current_document(). Any particular reason for the difference? I ask because the latter did the HTuncache_...() before printing the associated message and I had to move it after to get the reparse to work, and I probably did it wrong. (quoted from original SOURCE_CACHE implementation above). * Fix reloading with HTreparse_document() for LYK_MINIMAL, LYK_HISTORICAL, LYK_SOFT_DQUOTES, LYK_SWITCH_DTD mainloop events (hope we work around replies from POST properly). - LP diff -u ../gridtext.c ./gridtext.c --- ../gridtext.c Sat Apr 17 18:46:40 1999 +++ ./gridtext.c Sun Apr 18 14:23:30 1999 @@ -6282,6 +6282,34 @@ return ok; } +PUBLIC BOOLEAN HTcan_reparse_document NOARGS +{ + if (!HTMainText || LYCacheSource == SOURCE_CACHE_NONE || + (LYCacheSource == SOURCE_CACHE_FILE && + !HTMainText->source_cache_file) || + (LYCacheSource == SOURCE_CACHE_MEMORY && + !HTMainText->source_cache_chunk)) + return FALSE; + + if (LYCacheSource == SOURCE_CACHE_FILE && HTMainText->source_cache_file) { + FILE * fp; + + fp = fopen(HTMainText->source_cache_file, "r"); + if (!fp) { + return FALSE; + } + fclose(fp); + return TRUE; + } + + if (LYCacheSource == SOURCE_CACHE_MEMORY && + HTMainText->source_cache_chunk) { + return TRUE; + } + + return FALSE; /* if came to here */ +} + PRIVATE void trace_setting_change ARGS3( CONST char *, name, BOOLEAN, prev_setting, diff -u ../gridtext.h ./gridtext.h --- ../gridtext.h Tue Apr 13 02:39:16 1999 +++ ./gridtext.h Sun Apr 18 14:47:04 1999 @@ -168,6 +168,7 @@ extern void HTuncache_current_document NOPARAMS; #ifdef SOURCE_CACHE extern BOOLEAN HTreparse_document NOPARAMS; +extern BOOLEAN HTcan_reparse_document NOPARAMS; extern BOOLEAN HTdocument_settings_changed NOPARAMS; #endif extern int HText_getTopOfScreen NOPARAMS; diff -u ../lymainlo.c ./lymainlo.c --- ../lymainlo.c Sat Apr 17 22:06:50 1999 +++ ./lymainlo.c Sun Apr 18 14:59:28 1999 @@ -2189,6 +2189,9 @@ break; case LYK_HISTORICAL: /* toggle 'historical' comments parsing */ +#ifdef SOURCE_CACHE + if (!HTcan_reparse_document()) { +#endif /* * Check if this is a reply from a POST, and if so, * seek confirmation of reload if the safe element @@ -2200,14 +2203,15 @@ 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { -#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; -#endif } +#ifdef SOURCE_CACHE + } /* end if no bypass */ +#endif if (historical_comments) historical_comments = FALSE; else @@ -2221,18 +2225,16 @@ } #ifdef SOURCE_CACHE if (HTreparse_document()) { - break; + break; /* OK */ } - HTuncache_current_document(); - StrAllocCopy(newdoc.address, curdoc.address); - FREE(curdoc.address); - newdoc.line = curdoc.line; - newdoc.link = curdoc.link; #endif break; case LYK_MINIMAL: /* toggle 'minimal' comments parsing */ if (!historical_comments) { +#ifdef SOURCE_CACHE + if (!HTcan_reparse_document()) { +#endif /* * Check if this is a reply from a POST, and if so, * seek confirmation of reload if the safe element @@ -2244,14 +2246,15 @@ 0, 0) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { -#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; -#endif } +#ifdef SOURCE_CACHE + } /* end if no bypass */ +#endif } if (minimal_comments) minimal_comments = FALSE; @@ -2266,17 +2269,15 @@ } #ifdef SOURCE_CACHE if (HTreparse_document()) { - break; + break; /* OK */ } - HTuncache_current_document(); - StrAllocCopy(newdoc.address, curdoc.address); - FREE(curdoc.address); - newdoc.line = curdoc.line; - newdoc.link = curdoc.link; #endif break; case LYK_SOFT_DQUOTES: +#ifdef SOURCE_CACHE + if (!HTcan_reparse_document()) { +#endif /* * Check if this is a reply from a POST, and if so, * seek confirmation of reload if the safe element @@ -2288,14 +2289,15 @@ 1, 1) == FALSE) { HTInfoMsg(WILL_NOT_RELOAD_DOC); } else { -#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); newdoc.line = curdoc.line; newdoc.link = curdoc.link; -#endif } +#ifdef SOURCE_CACHE + } /* end if no bypass */ +#endif if (soft_dquotes) soft_dquotes = FALSE; else @@ -2304,17 +2306,15 @@ SOFT_DOUBLE_QUOTE_ON : SOFT_DOUBLE_QUOTE_OFF); #ifdef SOURCE_CACHE if (HTreparse_document()) { - break; + break; /* OK */ } - HTuncache_current_document(); - StrAllocCopy(newdoc.address, curdoc.address); - FREE(curdoc.address); - newdoc.line = curdoc.line; - newdoc.link = curdoc.link; #endif break; case LYK_SWITCH_DTD: +#ifdef SOURCE_CACHE + if (!HTcan_reparse_document()) { +#endif /* * Check if this is a reply from a POST, and if so, * seek confirmation of reload if the safe element @@ -2345,29 +2345,37 @@ #endif HTOutputFormat = WWW_SOURCE; } -#ifndef SOURCE_CACHE HTuncache_current_document(); StrAllocCopy(newdoc.address, curdoc.address); FREE(curdoc.address); -#endif - } #ifdef NO_ASSUME_SAME_DOC - newdoc.line = 1; - newdoc.link = 0; + newdoc.line = 1; + newdoc.link = 0; #else - newdoc.line = curdoc.line; - newdoc.link = curdoc.link; + newdoc.line = curdoc.line; + newdoc.link = curdoc.link; #endif /* NO_ASSUME_SAME_DOC */ + } +#ifdef SOURCE_CACHE + } /* end if no bypass */ +#endif Old_DTD = !Old_DTD; HTSwitchDTD(!Old_DTD); HTUserMsg(Old_DTD ? USING_DTD_0 : USING_DTD_1); #ifdef SOURCE_CACHE + if (HTcan_reparse_document()) { + if (HTisDocumentSource() && LYPreparsedSource) { +#ifdef USE_PSRC + if (LYpsrc) + psrc_view = TRUE; + else +#endif + HTOutputFormat = WWW_SOURCE; + } if (HTreparse_document()) { break; } - HTuncache_current_document(); - StrAllocCopy(newdoc.address, curdoc.address); - FREE(curdoc.address); + } /* end if bypass */ #endif break; From owner-lynx-dev@sig.net Sun Apr 18 08:15:11 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11414 for ; Sun, 18 Apr 1999 08:15:10 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14969; Sun, 18 Apr 1999 07:03:01 -0500 (CDT) Date: Sun, 18 Apr 1999 07:02:55 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev bug in lynx with lss (radiobuttons in tables) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1286 Lines: 28 On Thu, 15 Apr 1999, Vlad Harchev wrote: > When viewing the following file, the radiogroup looks incorrectly. Try > selecting various items and notice how the color of the '( )' changes. > To be viewed with distribution's mild-colors.lss. Notice that this .lss file > doesn't assign 'gray' to any style, tho' the color of the '(*)' is gray at the > very begining. [ html snipped ] There's two problems there: the style change of the just-deselected item's '( )', and the initial style of the first item's '(*)'. The first is a glitch I've also noticed previously, it seems to be rather consistent (and independent of chosen color style sheet). I actually find it mildly useful, it shows whoat one has changed the selection *from*... The second one seems to be a case that occurs more general: unpredictable style of input fields; most often when they are at the very beginning of a page or close to it, in my experience; this depends on the color style sheet. Note there *is* gray in mild-colors.lss: 'hr:normal:gray'. The color is probably leaking from the preceding
      . I only tested with code preceding your changes regarding color styles, so this is an older problem (apparently still present). I don't thing the fact that this is in a is significant. Klaus From owner-lynx-dev@sig.net Sun Apr 18 08:35:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11931 for ; Sun, 18 Apr 1999 08:35:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16963; Sun, 18 Apr 1999 07:27:59 -0500 (CDT) To: lynx-dev@sig.net References: <199904170937.KAA16930@djwhome.demon.co.uk> Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 16:24:29 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Problem with lynx 2.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 552 Lines: 17 17-Apr-99 10:37 David Woolley wrote: >> - OS= Linux 2.0.3 > Linux 2.0.3 was so early in the 2.0.x series that it will be quite buggy. > (In my view, the 2.0.x series was released too early.) The current > released 2.0.x kernel is 2.0.36 or 2.0.37. And he mean 2.2.3 for sure. > Also, this problem relates to libraries, so the kernel version is irrelevant, > but the distribution is quite important. >> - Terminal type= vt100 > VT100s are strictly monochrome devices, any colouring is the result of > something ignoring the true terminal type. From owner-lynx-dev@sig.net Sun Apr 18 08:35:28 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA11940 for ; Sun, 18 Apr 1999 08:35:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16973; Sun, 18 Apr 1999 07:28:03 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 16:11:34 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1869 Lines: 39 15-Apr-99 05:52 Vlad Harchev wrote: > Also I have the following idea: > We can write the documentation for the lynx.cfg in html (and each option will > have an anchor consisting of it's name). When adding new options/changing > behaviour of the options, we will modify that html file. And we can write the Looks nice and really easy to implement. But this is a bad health for executable size: lynx.cfg currently of ~90K long, HTML version will be larger by factor ~2 and this code should be built into lynx binary. Also we should work around INCLUDED files in that case (we may want to have one large file with all comments but another with a only couple of lines for handy maintenance). > script that will regenerate the comments in lynx.cfg automatically: (by > cutting the html piece corresponding to each option (with sed), rendering that > piece to text with lynx) and prefixing the rendered text with '#'. I think the > script will be easy to write. > After having moved all docs to some html file( say it will be lynxcfg.html), > we can do even more: > when generating the contents of LYNXCFG:// in read_cfg, we can make each > option name 'X' used to be a hyperlink with href 'lynxcfg.html#X' - so user > can quickly explore documentation for each option s/he used. > More explanation: > if the was a following line in lynx.cfg: > STARTFILE:http://lynx.browser.org > current code in LYReadCFG.c:read_cfg will generate the following piece of code > STARTFILE:http://lynx.browser.org > (ie copy it). After moving all option description to lynxcfg.html, we can > generate the following entry: > Date: Sun, 18 Apr 1999 16:18:51 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 884 Lines: 24 15-Apr-99 05:56 Vlad Harchev wrote: > On Sat, 17 Apr 1999, Leonid Pauzner wrote: >> >> I got a point of Klaus: currently with HTrerase_document() >> we lost a forms content (if any), so it is potentially a bad thing - >> user could not visit his history stack in certain situations. >> >> A better thing would be to store forms data somehow and restore it >> after reparsing. Still wait a volunteer. > I also wait for a volunteer :). > May be Klaus approach is the best. In this case volunteer has to hack lynx > to store the state of the current document when something is changed in > 'options' page. Not only in options menu but also hot keys and reload_read_cfg(). So it should be for any HTreparse_document call and probably with SOURCE_CACHE:NONE also (since forms content is the very internal lynx data and should not be lost if possible). > Best regards, > -Vlad From owner-lynx-dev@sig.net Sun Apr 18 09:08:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA13019 for ; Sun, 18 Apr 1999 09:08:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA20013; Sun, 18 Apr 1999 08:03:30 -0500 (CDT) Date: Sun, 18 Apr 1999 09:02:51 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 946 Lines: 25 On Thu, 15 Apr 1999, Vlad Harchev wrote: > The are several approaches: > 1)Use a feature of gcc - macros with variable number of arguments, in this > case we can do the following Non-portable. Not a good fix. Nice to know it exists though, thanks. > 2) First I've written the following script > 3) So I wrote the the small program using lex (it does the same as script > above, but very fast). These are both good ideas, but I'm leery of letting scripts modify 1000+ lines of code in this manner. I don't think there's an easy way to fix this properly. It's best to just let it slide for now, perhaps worry about it after 2.8.2. I'm almost positive this is a bug in the C compiler. Perhaps I'll take umbrage with the gcc folk. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Sun Apr 18 09:39:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA13887 for ; Sun, 18 Apr 1999 09:39:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23014; Sun, 18 Apr 1999 08:34:05 -0500 (CDT) Date: Sun, 18 Apr 1999 08:34:02 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net cc: le@put.com Subject: Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html In-Reply-To: <199904172217.SAA10639@news.put.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3233 Lines: 75 On Sat, 17 Apr 1999, News Subsystem wrote: > I'm not sure if the tod-list is being actively maintained... Not very actively... > but the stuff > on there about Cookies seems too cookie-friendly... Most of what's listed there seems to be in the current cookie code (2.8.1, and more so 2.8.2dev.N). Not just changes to make it more "cookie-friendly" (less discerning in what is acceptable), but also in the opposite direction. (It's not all well documented, things are still in flux.) Quoting from that URL: * (Suggested by Hiram W. Lester, Jr.) Something needs to be done so that cookies can be accepted from all domains by default. This is available as command line "-cookies"; also see the cfg file There is now -accept_all_cookies and ACCEPT_ALL_COOKIES. Note that the -cookies flag does NOT do this, the second sentence is wrong. (-cookies is an overall flag to turn accepting of cookies on or completely off.) * (Suggested by Hiram W. Lester, Jr.) Status message for accepting cookies even if there was an option to always allow all cookies. In general, cookies that are deemed acceptable without needing user confirmation are accepted quietly - a status message of each cookie would be just too annoying, especially if the user had already said he wanted such cookies. But there *is* a message (duration MESSAGESECS) 'A'lways allowing from domain 'XXX.XX.XX'. the first time a cookie from a given domain is auto-accepted, *if* this happens just because of -accept_all_cookies or ACCEPT_ALL_COOKIES (as opposed to previous 'A'lways answer to a prompt, or presence of the domain in a COOKIE_ACCEPT_DOMAINS list or in a persistent cookie file). * (Suggested by Rolf Puchtinger) Would it be possible to prompt users for the option to save COOKIES with expiry dates longer than "session" in a permanent file in the user's directory for subsequent sessions? Persistent cookies are implemented (but still marked "experimental"). Cookies with a given expiration in the future are saved to the persistent cookie file on exit, if enabled. This was broken in 2.8.1 though, it even saves cookies that should not be saved. (But they would be discarded when the file is read the next time.) > how about a feature > that can be set to cache-and-erase all cookies,a la Junkbuster? How would that work? Not sure what chaching means in this context. The current cookies control options all affect the 'receiving' side of the communication (whether to accept a "Set-Cookie:"). I have been thinking of YA setting to suspend/resume the *sending* of cookies independently (whether to send "Cookie:"). Maybe that's similar to what you mean. It's not strictly needed to have an option to control sending independently; if lynx never 'accepts' cookies (from either a server or a cookie file), it won't have anything to send. But toggling cookie sending on and off would be nice touch (mostly for testing whether cookies make a difference and are needed for a given service, probably). > Or a > pernmanent list of domains for each user to really "neVer accept" rather > than having to enter the V command every session? There is COOKIE_REJECT_DOMAINS now. Klaus From owner-lynx-dev@sig.net Sun Apr 18 09:49:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA14137 for ; Sun, 18 Apr 1999 09:49:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23845; Sun, 18 Apr 1999 08:42:23 -0500 (CDT) Message-ID: Date: Sun, 18 Apr 1999 14:41:26 +0100 To: lynx-dev@sig.net From: Don Adaway Subject: lynx-dev Lynx and downloading files MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 573 Lines: 14 I am using version 2.8.1rel.1 under W95. It works admirably for most purposes but if I download a binary file by http or ftp the procedure, while appearing to work, loses the file. At the end of the download I am presented with the option of Save to disk, followed by Filename choice. Taking the default options, Saving... appears, but afterwards the file has disappeared and is nowhere to be found on my disk. I have no problem saving web pages. No doubt I have neglected to set up Lynx.cfg properly. Could anyone please advise? -- Don chervil @ freeuk . com From owner-lynx-dev@sig.net Sun Apr 18 09:56:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA14211 for ; Sun, 18 Apr 1999 09:56:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA24898; Sun, 18 Apr 1999 08:51:37 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181351.JAA07051@shell.clark.net> Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 09:51:34 -0400 (EDT) In-Reply-To: from "John Bley " at Apr 18, 99 09:02:51 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1271 Lines: 38 > > On Thu, 15 Apr 1999, Vlad Harchev wrote: > > > The are several approaches: > > 1)Use a feature of gcc - macros with variable number of arguments, in this > > case we can do the following > > Non-portable. Not a good fix. Nice to know it exists though, thanks. yes. some C-preprocessors really do care - and we wouldn't be able to use the code. > > 2) First I've written the following script > > 3) So I wrote the the small program using lex (it does the same as script > > above, but very fast). > > These are both good ideas, but I'm leery of letting scripts modify 1000+ > lines of code in this manner. I don't think there's an easy way to fix this > properly. It's best to just let it slide for now, perhaps worry about it > after 2.8.2. I've a few of those that I'm saving. (plus, adding lex to the build will complicate ports) > I'm almost positive this is a bug in the C compiler. Perhaps > I'll take umbrage with the gcc folk. > > -- > John Bley - jbb6@acpub.duke.edu > Duke '99 - English/Computer Science > Since English is a mess, it maps well onto the problem space, > which is also a mess, which we call reality. - Larry Wall -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 10:15:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA14757 for ; Sun, 18 Apr 1999 10:15:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26597; Sun, 18 Apr 1999 09:06:46 -0500 (CDT) Date: Sun, 18 Apr 1999 09:06:43 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1367 Lines: 38 On Thu, 15 Apr 1999, Vlad Harchev wrote: > The are several approaches: [ various approaches for changing TRACEing snipped ] If you serious think about changing the TRACE stuff, please have a look at how this is done now in the lates W3C libwww code. (They changed it rather recently.) See (that and our HTUtils.h go back to a common ancestor...) (for brief description/announcement) An example of how it's used: HTTRACE(CORE_TRACE, "Host info... object %p from list %p\n" _ me _ list); (The first parameter selects what kinds of trace messages are wanted - would be nice also for lynx, instead of the current all-or-nothing approach. A trace log can get way too big with ALL trace messages if one is only interested in a specific part of the code.) The use of '_' instead of ',' needs getting used to, but apparent it gets around the variable-argument-number problem nicely. It would be a problem if we used _() as a shhorthand for gettext(); but fortunately the lynx code uses gettext() directly. This would require replacing all TRACE messages throughout the code; but so would the other approaches that are worth considering, I think. I agree with Tom though that this is probably not the best time for it. Klaus From owner-lynx-dev@sig.net Sun Apr 18 10:28:49 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15063 for ; Sun, 18 Apr 1999 10:28:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28167; Sun, 18 Apr 1999 09:21:17 -0500 (CDT) Date: Sun, 18 Apr 1999 09:21:14 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1880 Lines: 51 On Sat, 17 Apr 1999, John Bley wrote: > On Sat, 17 Apr 1999, Klaus Weide wrote: > > > > * Fix --disable-trace, chop more unneeded #includes (John Bley) > > Could you explain why --disable-trace needed fixing? It seems to > > me you change doesn't really change anything - you now just test > > for NO_LYNX_TRACE directly rather than indirectly (through DEBUG), > > or am I missing something? > > Yes, that's what I thought too, but for some reason > ./configure --disable-trace && make all > was still producing a binary that could do tracing. (I.e., produces > Lynx.trace and fills it with junk). I tried with both gcc and Sun's cc. > I don't claim to fully understand why this particular fix works for me, > but now when I disable-trace I really don't produce the trace. There must have been a -DDEBUG somewhere or a '#define DEBUG' in some unexepected .h file... > > > Strange: > > > Turning trace off at compile-time transforms all instances of > > > CTRACE(...) > > > to > > > if (0) fprintf(...) > > > > Are you really compiling with -O[>=2] and without -g? > > For gcc, yes. Also the appropriate flags for cc. It is quite strange. I did a very small test (gcc Debian GNU/Linux package 2.7.2.3-7) with: #include int main(int argc, char **argv) { if (0) fprintf(stderr, "%s", "foo bar\n"); return 0; } No matter what different gcc flags I tried, the string "foo bar" was still in the binary (as shown by 'string')... Aparently gcc optimization is much stupider in this respect than what I would have expected. I guess that all constant strings are handled very early in the compilation process, and then never checked whether actually referenced after subsequent optimization passes. I don't think all compilers act like that - IIRC Jim Spath reported significan size decrease a while ago. Klaus From owner-lynx-dev@sig.net Sun Apr 18 10:38:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15347 for ; Sun, 18 Apr 1999 10:38:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29108; Sun, 18 Apr 1999 09:30:31 -0500 (CDT) To: lynx-dev@sig.net, chervil@freeuk.com References: Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 18:25:49 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Lynx and downloading files MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1042 Lines: 25 18-Apr-99 14:41 Don Adaway wrote: > I am using version 2.8.1rel.1 under W95. > It works admirably for most purposes but if I download a binary file by > http or ftp the procedure, while appearing to work, loses the file. At > the end of the download I am presented with the option of Save to disk, > followed by Filename choice. Taking the default options, Saving... > appears, but afterwards the file has disappeared and is nowhere to be > found on my disk. I have no problem saving web pages. > No doubt I have neglected to set up Lynx.cfg properly. Could anyone > please advise? check you environment for TEMP or TMP variables, probably the path point to not existing directory or LFN (there may be a problem with lynx/Win32 if you use filenames >8.3). Try set TMP=c:\ for sure. (Perhaps already OK since you can use a downloader menu ifself). There is a LYNX_SAVE_SPACE variable in lynx.cfg, this is *where* the files will be downloaded to. Try to set it (with same cautions as above). > -- > Don chervil @ freeuk . com From owner-lynx-dev@sig.net Sun Apr 18 10:39:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15538 for ; Sun, 18 Apr 1999 10:39:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29158; Sun, 18 Apr 1999 09:31:08 -0500 (CDT) Date: Sun, 18 Apr 1999 09:31:04 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev lynx with -color and -lss In-Reply-To: <9904180649.AA17255@cas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1141 Lines: 29 On Sun, 18 Apr 1999, Larry W. Virden wrote: > > I agree that 2.8.2dev.N should be better. > > > I tried the dev.22 vesion of color styles but configured it back out again > when I noticed lynx tended (for me anyways) to write a line overtop > of the expert mode URL display. Hmm, I should have added "for some values of N"... :) > I didn't report it here because I knew the average response was 'lss support > is experimental' and I didn't have time this week to chase down any more > details. Perhaps someone else using lss if they are seeing a problem > can report more details. Maybe you know when this appeared? This sounds like lynx's understanding of current position on the screen and curses' understanding of it getting out of synch. Or possibly lynx and curses agree, but the terminal (or emulator, e.g. xterm) doesn't. Could happen if "line wrapping" is set the wrong way (disagreement between what curses thinks and terminal settings' reality), but normally this shouldn't happen because lynx avoids writing to the last line position (this is the reason only 79 positions are available in 80xNN screen size). Klaus From owner-lynx-dev@sig.net Sun Apr 18 10:39:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15545 for ; Sun, 18 Apr 1999 10:39:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28987; Sun, 18 Apr 1999 09:29:09 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 18:14:38 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 867 Lines: 21 18-Apr-99 08:34 Klaus Weide wrote: > On Sat, 17 Apr 1999, News Subsystem wrote: >> I'm not sure if the tod-list is being actively maintained... > Not very actively... > * (Suggested by Hiram W. Lester, Jr.) Something needs to be done so > that cookies can be accepted from all domains by default. This is > available as command line "-cookies"; also see the cfg file > There is now -accept_all_cookies and ACCEPT_ALL_COOKIES. Note that > the -cookies flag does NOT do this, the second sentence is wrong. > (-cookies is an overall flag to turn accepting of cookies on or > completely off.) I think accept_all_cookies:TRUE should force cookies:TRUE In fact the choice from option menu (3 states) is more intuitive then setting these two separate settings (4 states), and the accept_all_cookies: TRUE and cookies:FALSE is of a little sence. From owner-lynx-dev@sig.net Sun Apr 18 10:44:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15607 for ; Sun, 18 Apr 1999 10:44:45 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA29889; Sun, 18 Apr 1999 09:36:56 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904181436.IAA24921@sanitas> Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 08:36:22 -0600 (MDT) In-Reply-To: from "Vlad Harchev" at Apr 15, 99 07:03:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 387 Lines: 13 In a recent note, Vlad Harchev said: > Date: Thu, 15 Apr 1999 07:03:42 +0500 (SAMST) > > The are several approaches: > 1)Use a feature of gcc - macros with variable number of arguments, in this > Please don't introduce a dependency on a non-ANSI facility of a C compiler unless configure can test for this feature and bypass the dependency with conditional compilation. Thanks, gil From owner-lynx-dev@sig.net Sun Apr 18 10:46:21 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA15624 for ; Sun, 18 Apr 1999 10:46:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA00159; Sun, 18 Apr 1999 09:39:12 -0500 (CDT) Date: Sun, 18 Apr 1999 10:35:16 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1302 Lines: 36 On Sun, 18 Apr 1999, Klaus Weide wrote: > There must have been a -DDEBUG somewhere or a '#define DEBUG' in some > unexepected .h file... It's possible. I'll grep for that later. > I did a very small test (gcc Debian GNU/Linux package 2.7.2.3-7) with: > > #include > int main(int argc, char **argv) > { > if (0) fprintf(stderr, "%s", "foo bar\n"); > return 0; > } > > No matter what different gcc flags I tried, the string "foo bar" was > still in the binary (as shown by 'string')... Aparently gcc > optimization is much stupider in this respect than what I would have > expected. I guess that all constant strings are handled very early in > the compilation process, and then never checked whether actually > referenced after subsequent optimization passes. Yes, I tried a similar experiment. This is what makes me think that I should just complain to the gcc folk and not worry about the lynx code. Well, this part of the lynx code. > I don't think all compilers act like that I hope not. Maybe I'll try egcs and see if they fixed it. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Sun Apr 18 11:01:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA16172 for ; Sun, 18 Apr 1999 11:01:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA01858; Sun, 18 Apr 1999 09:53:57 -0500 (CDT) Date: Sun, 18 Apr 1999 09:53:53 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev cookie flags (was: http://www.slcc.edu/lynx/html/todo-list.html) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1193 Lines: 28 On Sun, 18 Apr 1999, Leonid Pauzner wrote: > 18-Apr-99 08:34 Klaus Weide wrote: > > > There is now -accept_all_cookies and ACCEPT_ALL_COOKIES. Note that > > the -cookies flag does NOT do this, the second sentence is wrong. > > (-cookies is an overall flag to turn accepting of cookies on or > > completely off.) > > I think accept_all_cookies:TRUE should force cookies:TRUE > In fact the choice from option menu (3 states) is more intuitive > then setting these two separate settings (4 states), > and the accept_all_cookies: TRUE and cookies:FALSE is of a little sence. Well, -cookies is a one-stop solution to toggle all cookie receiving from servers; it makes sense to me to have only one flag to turn it off (if it's normally turned on, with whatever more detailed options). The setting of 'accept_all_cookies' doesn't matter while 'cookies' is FALSE [Is sthis strictly true??], but that's nothing unusual. There are more options/flags that only have an effect if other options/flags are set (especially things like restrictions). Maybe the flags are infelicitously named. It should probably be made clearer that 'accept_all_cookies' only has effect if 'cookies' is on. Klaus From owner-lynx-dev@sig.net Sun Apr 18 11:02:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA16189 for ; Sun, 18 Apr 1999 11:02:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA01740; Sun, 18 Apr 1999 09:52:59 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904181452.IAA24949@sanitas> Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 08:52:25 -0600 (MDT) In-Reply-To: from "Klaus Weide" at Apr 18, 99 09:21:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 508 Lines: 14 In a recent note, Klaus Weide said: > Date: Sun, 18 Apr 1999 09:21:14 -0500 (CDT) > > optimization is much stupider in this respect than what I would have > expected. I guess that all constant strings are handled very early in > the compilation process, and then never checked whether actually > referenced after subsequent optimization passes. > It's possible that a compiler is cautious about optimizing string constants in order to preserve copyright notices intended to appear in the binary. -- gil From owner-lynx-dev@sig.net Sun Apr 18 11:02:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA16190 for ; Sun, 18 Apr 1999 11:02:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA02050; Sun, 18 Apr 1999 09:55:25 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904181454.IAA24957@sanitas> Subject: Re: lynx-dev Lynx and downloading files To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 08:54:41 -0600 (MDT) In-Reply-To: from "Leonid Pauzner" at Apr 18, 99 06:25:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 507 Lines: 13 In a recent note, Leonid Pauzner said: > Date: Sun, 18 Apr 1999 18:25:49 +0400 (MSD) > > check you environment for TEMP or TMP variables, probably the path > point to not existing directory or LFN (there may be a problem with lynx/Win32 > if you use filenames >8.3). Try set TMP=c:\ for sure. > (Perhaps already OK since you can use a downloader menu ifself). > If any of these is the cause, Lynx must be failing to check and report the result code from the attempt to create the temporary file. -- gil From owner-lynx-dev@sig.net Sun Apr 18 12:37:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA19058 for ; Sun, 18 Apr 1999 12:37:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA13327; Sun, 18 Apr 1999 11:28:13 -0500 (CDT) Date: Sun, 18 Apr 1999 12:28:18 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev Lynx, colors and VT100 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1984 Lines: 42 I've seen many messages here saying that VT100 doesn'support color. That's true for real VT100 terminals, not for VT100/VT102 emulators, and I don't believe that many people are using real VT100 terminals nowadays. Most VT100 emulators I know support color. Last year I discussed that subject with Thomas and others in comp.infosystems.www.browsers.misc. The best way to get colors in Lynx when using a VT100 emulator is by compiling Lynx with Slang. Slang doesn't assume that VT100 doesn't support colors and displays colors when you use the "-color" option in the command line or set "Show color" to "ON" or "ALWAYS" in the options menu. I've been using Lynx with colors since version 2.7.2, when I decided to compile Slang myself and compile Lynx with it, and I've read some people saying that they were getting colors with Lynx 2.6 compiled with Slang. I told many people that I was using Lynx with colors and received many emails from people who were in ISPs using Lynx compiled with ncurses asking me how to get colors. I began to search for termcap/terminfo capabilities related to colors and tried many of them with Lynx compiled with ncurses and Solaris' curses. Now I can say that I found the capabilities that can be put in the termcap/terminfo VT100 definition to allow Lynx to display colors. Here they are: termcap ------- :Co#8:pa#64:op=\E[37;40m:AF=\E[3%dm:AB=\E[4%dm: terminfo -------- colors#8, pairs#64, op=\E[37;40m, setaf=\E[3%p1%dm, setab=\E[4%p1%dm, I use those in Solaris (terminfo) and FreeBSD (termcap) and I've received reports of they being successfully used in other systems. Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Sun Apr 18 14:12:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA22464 for ; Sun, 18 Apr 1999 14:12:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA25250; Sun, 18 Apr 1999 13:02:35 -0500 (CDT) Date: Thu, 15 Apr 1999 16:05:13 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev bug in lynx with lss (radiobuttons in tables) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1534 Lines: 36 On Sun, 18 Apr 1999, Klaus Weide wrote: > On Thu, 15 Apr 1999, Vlad Harchev wrote: > > > When viewing the following file, the radiogroup looks incorrectly. Try > > selecting various items and notice how the color of the '( )' changes. > > To be viewed with distribution's mild-colors.lss. Notice that this .lss file > > doesn't assign 'gray' to any style, tho' the color of the '(*)' is gray at the > > very begining. > [ html snipped ] > > There's two problems there: the style change of the just-deselected > item's '( )', and the initial style of the first item's '(*)'. > > The first is a glitch I've also noticed previously, it seems to > be rather consistent (and independent of chosen color style sheet). > I actually find it mildly useful, it shows whoat one has changed > the selection *from*... > > The second one seems to be a case that occurs more general: unpredictable > style of input fields; most often when they are at the very beginning of > a page or close to it, in my experience; this depends on the color style > sheet. Note there *is* gray in mild-colors.lss: 'hr:normal:gray'. > The color is probably leaking from the preceding
      . > > I only tested with code preceding your changes regarding color styles, > so this is an older problem (apparently still present). I don't thing > the fact that this is in a
      is significant. > Klaus > I tested the that 'form' piece without a table, and the were no glitches detected, so I inducted that it was due to tables. Best regards, -Vlad From owner-lynx-dev@sig.net Sun Apr 18 14:13:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA22476 for ; Sun, 18 Apr 1999 14:13:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA25260; Sun, 18 Apr 1999 13:02:38 -0500 (CDT) Date: Thu, 15 Apr 1999 15:55:38 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1675 Lines: 43 On Sun, 18 Apr 1999, John Bley wrote: > On Thu, 15 Apr 1999, Vlad Harchev wrote: > > > The are several approaches: > > 1)Use a feature of gcc - macros with variable number of arguments, in this > > case we can do the following > > Non-portable. Not a good fix. Nice to know it exists though, thanks. > > > 2) First I've written the following script > > 3) So I wrote the the small program using lex (it does the same as script > > above, but very fast). > > These are both good ideas, but I'm leery of letting scripts modify 1000+ > lines of code in this manner. I don't think there's an easy way to fix this > properly. It's best to just let it slide for now, perhaps worry about it > after 2.8.2. > I'm almost positive this is a bug in the C compiler. Perhaps > I'll take umbrage with the gcc folk. >[...] Removing the strings from dead code is not yet implemented in gcc and egcs-1.1.1. Here is a quote from eqcs-1.1.1/gcc/PROJECTS | * Constants in unused inline functions | | It would be nice to delay output of string constants so that string | constants mentioned in unused inline functions are never generated. | Perhaps this would also take care of string constants in dead code. Tho' egcs-1.1.1 is not a latest release. As for scripts that modify the 1000+ lines of code, I can say the following: I consider lex lexer built from the file I sent to be reliable. The best way to test it is to change all *.c file in lynx distibution and try to compile it. If you wish, I can do it myself and send a big patch here. I was confused by the need to send ~100 kb patch, but now I relalize I should do it... Should I? Best regards, -Vlad From owner-lynx-dev@sig.net Sun Apr 18 14:24:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA22821 for ; Sun, 18 Apr 1999 14:24:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA25240; Sun, 18 Apr 1999 13:02:32 -0500 (CDT) Date: Thu, 15 Apr 1999 16:02:17 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 977 Lines: 25 On Sun, 18 Apr 1999, Leonid Pauzner wrote: > 15-Apr-99 05:52 Vlad Harchev wrote: > > > Also I have the following idea: > > We can write the documentation for the lynx.cfg in html (and each option will > > have an anchor consisting of it's name). When adding new options/changing > > behaviour of the options, we will modify that html file. And we can write the > > Looks nice and really easy to implement. > But this is a bad health for executable size: lynx.cfg currently of ~90K long, > HTML version will be larger by factor ~2 and this code should be built into > lynx binary. Also we should work around INCLUDED files in that case > (we may want to have one large file with all comments > but another with a only couple of lines for handy maintenance). I meant that HTML file will be standalone as other lynx documentation in the /lynx_help, so the compiled binary won't grow, but the total distribution size will increase. >>[...] Best regards, -Vlad From owner-lynx-dev@sig.net Sun Apr 18 15:09:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA24081 for ; Sun, 18 Apr 1999 15:09:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA02704; Sun, 18 Apr 1999 13:58:05 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181857.OAA29788@shell.clark.net> Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 14:57:41 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 18, 99 09:06:43 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1080 Lines: 27 > The use of '_' instead of ',' needs getting used to, but apparent it gets > around the variable-argument-number problem nicely. maybe - though I'd have to test & see that the different preprocessor agree (some people tend to think that if it works in gcc, it's portable - I can remember an order-of-evaluation problem in gcc which the GNU people had to abandon 4-5 years ago because it wasn't ANSI compatible) > It would be a problem if we used _() as a shhorthand for gettext(); but > fortunately the lynx code uses gettext() directly. > > This would require replacing all TRACE messages throughout the code; > but so would the other approaches that are worth considering, I think. > > I agree with Tom though that this is probably not the best time for it. yes - I'd rather do stuff like that early in a cycle. This week I'm working to finish off changes for xterm for a code freeze in XFree86, then (unless people have different ideas) it's time to do the same for lynx. > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 15:18:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA24323 for ; Sun, 18 Apr 1999 15:18:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA03164; Sun, 18 Apr 1999 14:01:41 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181901.PAA20646@shell.clark.net> Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 15:01:38 -0400 (EDT) In-Reply-To: <199904181436.IAA24921@sanitas> from "pg@sweng.stortek.com" at Apr 18, 99 08:36:22 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 587 Lines: 18 > In a recent note, Vlad Harchev said: > > > Date: Thu, 15 Apr 1999 07:03:42 +0500 (SAMST) > > > > The are several approaches: > > 1)Use a feature of gcc - macros with variable number of arguments, in this > > > Please don't introduce a dependency on a non-ANSI facility of a C > compiler unless configure can test for this feature and bypass the > dependency with conditional compilation. I wouldn't even trust conditional compilation, since after all it _is_ the preprocessor which is being abused. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 15:25:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA24560 for ; Sun, 18 Apr 1999 15:25:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA04879; Sun, 18 Apr 1999 14:15:08 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181914.PAA28820@shell.clark.net> Subject: Re: lynx-dev Lynx, colors and VT100 To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 15:14:35 -0400 (EDT) In-Reply-To: from "Ismael Cordeiro " at Apr 18, 99 12:28:18 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1258 Lines: 36 > I've seen many messages here saying that VT100 doesn'support color. That's > true for real VT100 terminals, not for VT100/VT102 emulators, and I don't > believe that many people are using real VT100 terminals nowadays. Most VT100 > emulators I know support color. Last year I discussed that subject with > Thomas and others in comp.infosystems.www.browsers.misc. -- I still disagree though > compiling Lynx with Slang. Slang doesn't assume that VT100 doesn't support > colors and displays colors when you use the "-color" option in the command slang uses one particular combination of assumptions about color terminals, which works with about half of the "ANSI" color terminals that I'm aware of. > termcap > ------- > :Co#8:pa#64:op=\E[37;40m:AF=\E[3%dm:AB=\E[4%dm: this won't work for the configuration that I use at work, since I use a white background there. (my home machine's screen is higher resolution, and I use black background except when running lynx - color contrasts aren't good enough). > terminfo > -------- > colors#8, pairs#64, op=\E[37;40m, setaf=\E[3%p1%dm, setab=\E[4%p1%dm, same problem - works for you, perhaps not everyone > Ismael -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 15:26:19 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA24572 for ; Sun, 18 Apr 1999 15:26:19 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA05082; Sun, 18 Apr 1999 14:16:54 -0500 (CDT) From: dickey@clark.net Message-Id: <199904181916.PAA10987@shell.clark.net> Subject: Re: lynx-dev lynx with -color and -lss To: lynx-dev@sig.net Date: Sun, 18 Apr 1999 15:16:50 -0400 (EDT) In-Reply-To: from "Klaus Weide " at Apr 18, 99 09:31:04 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 650 Lines: 20 > Could happen if "line wrapping" is set the wrong way (disagreement > between what curses thinks and terminal settings' reality), but normally > this shouldn't happen because lynx avoids writing to the last line > position (this is the reason only 79 positions are available in 80xNN > screen size). that's a problem with older BSD curses, but ncurses does check the terminfo capability that says if wrapping is done (and believes it, of course). It's easy to verify in xterm - just toggle the auto wraparound menu entry and see if the problem goes away. > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Apr 18 15:39:23 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA24858 for ; Sun, 18 Apr 1999 15:39:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA06132; Sun, 18 Apr 1999 14:25:24 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Sun, 18 Apr 1999 23:17:52 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx with -color and -lss MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 358 Lines: 10 18-Apr-99 01:07 Klaus Weide wrote: >> Lynx color styles need -lss=filename switch, it wouldn't be color without it. > It's not needed if the *.lss file is found in the location compiled > in (set either in lynx_cfg.h by configure or in userdefs.h). BTW, in LYMain.c there is no trace message when -cfg or -lss file can not be open, just stderr output. From owner-lynx-dev@sig.net Sun Apr 18 17:23:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA28167 for ; Sun, 18 Apr 1999 17:23:51 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA19897; Sun, 18 Apr 1999 16:15:19 -0500 (CDT) Message-ID: Date: Sun, 18 Apr 1999 22:14:29 +0100 To: lynx-dev@sig.net From: Don Adaway Subject: Re: lynx-dev Lynx and downloading files References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2092 Lines: 48 In article , Leonid Pauzner writes >18-Apr-99 14:41 Don Adaway wrote: >> I am using version 2.8.1rel.1 under W95. > >> It works admirably for most purposes but if I download a binary file by >> http or ftp the procedure, while appearing to work, loses the file. > >check you environment for TEMP or TMP variables, probably the path >point to not existing directory or LFN (there may be a problem with lynx/Win32 >if you use filenames >8.3). Try set TMP=c:\ for sure. >(Perhaps already OK since you can use a downloader menu ifself). Thanks for your help. I have SET TEMP=C:\TEMP in my autoexec.bat (also SET TMP=C:\TEMP but Lynx appears to use TEMP -- see below). Incidentally I tried setting TEMP=C:\ but this twice caused Lynx to lock up when I tried to ftp a file (coincidence or not I don't know) but restoring TEMP to C:\TEMP cured the problem. > >There is a LYNX_SAVE_SPACE variable in lynx.cfg, this is *where* the files >will be downloaded to. Try to set it (with same cautions as above). > I have the LYNX_SAVE_SPACE variable set to a 5 letter directory name (actually C:\LYNX\SAVED\). This directory exists. Lynx does in fact work when I try to ftp. The file downloads in the time I would expect it to and all the Lynx messages are clear and unambiguous. Lynx gives every appearance of saving the file to disk. After the ftp session I have examined the \TEMP directory with a disk recovery program and established that the downloaded file did arrive there with a cryptic name composed of numbers. The first number was missing because the file has been deleted. This is what I hoped to find. Using the undelete facility in the program the file was recoverable. Examining the target directory C:\LYNX\SAVED with the same program I found that there was an entry for the downloaded file with its proper name except again for the first letter. This version of the file was zero length and not recoverable. I like using Lynx and would appreciate any help in solving this problem. -- Don chervil @ freeuk . com From owner-lynx-dev@sig.net Sun Apr 18 18:15:07 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA29636 for ; Sun, 18 Apr 1999 18:15:06 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA25726; Sun, 18 Apr 1999 16:57:58 -0500 (CDT) Date: Sat, 17 Apr 1999 21:45:20 +0000 () From: Louis Epstein To: Doug Kaufman cc: lynx-dev@sig.net Subject: Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 842 Lines: 24 On Sat, 17 Apr 1999, Doug Kaufman wrote: > On Sat, 17 Apr 1999, le wrote: > > > Beyond that,I'm puzzled as to why high-bidder lists at the domain > > www.surplusauction.com are accessible to 2.6 but not to 2.8.1. > > It would help if you gave the full URL that is giving you trouble. > A recent development version doesn't have trouble getting to > "http://www.surplusauction.com/images/high_bidders.gif". > Doug An example... http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601&UID=DF1 has,for Lynx 2.6,a functioning link "Click here to view high bidders list" to http://www.surplusauction.com/wc.dll?Lots~Info~90419A-ME5601~HI&UID=DF1 but in 2.8.1 the "Click here..." is dead text,not a link. (This is typical of lots). (The 2.6 is running under FreeBSD 2.1 and the 2.8.1 under FreeBSD 2.2.8). From owner-lynx-dev@sig.net Sun Apr 18 18:15:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA29646 for ; Sun, 18 Apr 1999 18:15:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA25650; Sun, 18 Apr 1999 16:57:29 -0500 (CDT) Date: Sun, 18 Apr 1999 08:26:15 -0400 (EDT) From: Marcus To: lynx-dev@sig.net Subject: lynx-dev changing options menu from a form to the way it use to be! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 670 Lines: 13 hi! i can't seem to be able to change my options in lynx 2.8.1 like i use to! going into options gives me a form now where you use to be able to hit the letter of the option you wished to change! what happened? how do i change the lynx.cfg file back to hitting letters for options?please e mail direct! marcus25@icubed.com oh and also the problem with http://wire.ap.org still exists!that site worked with lynx 2.7.1 but not any version higher! Check out my web page! http://www.icubed.com/~marcus25/ don't forget the slash at the end! I am scoreboard king time master chocolate king bacon king king of laziness and king of stubbornness! Get the picture! From owner-lynx-dev@sig.net Sun Apr 18 19:38:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA31845 for ; Sun, 18 Apr 1999 19:38:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA07716; Sun, 18 Apr 1999 18:26:42 -0500 (CDT) Date: Sun, 18 Apr 1999 16:26:30 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Cc: Louis Epstein Subject: Re: http://www.slcc.edu/lynx/html/todo-list.html [lynx-dev] In-Reply-To: <19990417235741.A740@unicorn.it.wsu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1750 Lines: 39 On Sat, 17 Apr 1999, Michael Warner wrote: > On or about 17 Apr, 1999, Doug Kaufman > wrote: > > > You need to turn on "image links". While in lynx, you > > control this with the "*" key. It can also be set from your > > .lynxrc file via the options page or from the lynx.cfg file > > with "MAKE_LINKS_FOR_ALL_IMAGES". The command line switch > > "-image_links" also toggles this. I keep this turned on all the > > time, only turning it off if the screen is too cluttered. It > > also controls whether or not the links are shown with the "A" > > or "L" commands. > > I don't think that's the problem. They use an IMG in place > of link text, and the '*' key just gets the IMG url > (.../high_bidders.gif), not the url of the bidders list. > The link he wants is available as a "hidden link" on the > 'L'inks page. Using the "-hiddenlinks=merge" commandline > switch with links numbered gets a number assigned to the > hidden link, making it much easier to find on the 'L'inks > page (the urls are pretty cryptic). You are correct. It looks like I replied before checking this out completely. The site has strange html, with the two links combined, ending in . Tag soup parsing lets you see the intended information. The advice to view this site then would be to use TagSoup parsing, either with the CTRL-V key within lynx, by invoking lynx as "lynx -tagsoup", or by setting the parser to TagSoup in lynx.cfg (with TAGSOUP:TRUE). The hiddenlinks option is probably too esoteric for most users. All of us need to use the alternate parser on occasion. Sorry about the bad advice I gave earlier. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 18 20:12:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA00124 for ; Sun, 18 Apr 1999 20:12:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA13107; Sun, 18 Apr 1999 19:05:54 -0500 (CDT) From: mattack@area.com Date: Sun, 18 Apr 1999 17:05:47 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: http://www.slcc.edu/lynx/html/todo-list.html [lynx-dev] In-Reply-To: <19990417235741.A740@unicorn.it.wsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1023 Lines: 24 On Sat, 17 Apr 1999, Michael Warner wrote: >On or about 17 Apr, 1999, Doug Kaufman > wrote: >> You need to turn on "image links". While in lynx, you >> control this with the "*" key. It can also be set from your ... >I don't think that's the problem. They use an IMG in place >of link text, and the '*' key just gets the IMG url >(.../high_bidders.gif), not the url of the bidders list. >The link he wants is available as a "hidden link" on the >'L'inks page. Using the "-hiddenlinks=merge" commandline So what exactly is a hidden link? I mean, how does someone create a hidden link and why would they do so? (I presume it's not hidden in GUI browsers?) I may be wrong, but I'm under the impression that "image links" needs to be turned on for the case where an image is linked to a URL.. i.e. instead of a link being text, the link is a picture.. and since most people don't view images in links, this causes these types of links to be invisible. (..and causes confusion for Lynx users often..) From owner-lynx-dev@sig.net Sun Apr 18 20:22:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA00448 for ; Sun, 18 Apr 1999 20:22:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA14428; Sun, 18 Apr 1999 19:15:41 -0500 (CDT) Date: Mon, 19 Apr 1999 09:27:01 +0900 (JST) From: Henry Nelson Message-Id: <199904190027.JAA24618@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 488 Lines: 10 > Of course, IMO once someone has compiled out info like ctrace, it should > a) no longer be permitted to be called lynx and b) no longer be acceptable > to send problem reports to the list... Of course, as concerns "b)", unless the reporting person is willing to recompile with debugging turned on. As for "a)", there are two sides of the coin to most everything, as you just reminded me the other day. I would reword that "Lynx should no longer be permitted to call ctrace." __Henry From owner-lynx-dev@sig.net Sun Apr 18 20:32:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA00779 for ; Sun, 18 Apr 1999 20:32:38 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA15762; Sun, 18 Apr 1999 19:25:59 -0500 (CDT) Date: Sun, 18 Apr 1999 17:25:51 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: Don Adaway Cc: lynx-dev@sig.net Subject: Re: lynx-dev Lynx and downloading files In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 938 Lines: 23 On Sun, 18 Apr 1999, Don Adaway wrote: > >> I am using version 2.8.1rel.1 under W95. > > > >> It works admirably for most purposes but if I download a binary file by > >> http or ftp the procedure, while appearing to work, loses the file. > ... > Examining the target directory C:\LYNX\SAVED with the same program I > found that there was an entry for the downloaded file with its proper > name except again for the first letter. This version of the file was > zero length and not recoverable. This sounds like a problem with your cp.exe program. Do you have it in your PATH or in the same directory as lynx (assuming that is your working directory). Does it work to copy binaries when you are working in a DOS box? Lynx uses cp.exe to copy files from the TEMP directory to your chosen location for the file. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Apr 18 20:38:44 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA01018 for ; Sun, 18 Apr 1999 20:38:43 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA16864; Sun, 18 Apr 1999 19:33:13 -0500 (CDT) To: lynx-dev@sig.net, marcus25@infobahn.icubed.com References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 04:09:48 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev changing options menu from a form to the way it use to be! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 421 Lines: 7 18-Apr-99 08:26 Marcus wrote: > hi! i can't seem to be able to change my options in lynx 2.8.1 like i use to! > going into options gives me a form now where you use to be able to hit the > letter of the option you wished to change! what happened? how do i change the > lynx.cfg file back to hitting letters for options?please e mail direct! try FORMS_OPTIONS switch in lynx.cfg or -forms_options command line flag. From owner-lynx-dev@sig.net Sun Apr 18 20:39:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA01031 for ; Sun, 18 Apr 1999 20:39:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA16848; Sun, 18 Apr 1999 19:33:09 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 04:31:51 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev (patch) - show list of statusline messages from history page MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 8041 Lines: 290 * HTAlert, HTUserMsg and HTInfoMsg statusline messages now stored in a cyrcled buffer and accessible from the History Page as LYNXMESSAGES:/ link. This allow us to decrease the messages delay in lynx.cfg when we feel messages too annoying, but have a nice history list for diagnostic purposes. Idea belongs to Bela Lubkin. Buffer of 40 lines long. - LP diff -u old/htalert.c ./htalert.c --- old/htalert.c Tue Apr 13 02:39:16 1999 +++ ./htalert.c Mon Apr 19 03:52:04 1999 @@ -18,6 +18,7 @@ #include #include #include +#include /* store statusline messages */ #include @@ -30,6 +31,7 @@ CTRACE(tfp, "\nAlert!: %s\n\n", Msg); CTRACE_FLUSH(tfp); _user_message(ALERT_FORMAT, Msg); + _store_message2(ALERT_FORMAT, Msg); sleep(AlertSecs); } @@ -69,6 +71,7 @@ _statusline(Msg); if (Msg && *Msg) { CTRACE(tfp, "Info message: %s\n", Msg); + _store_message(Msg); sleep(InfoSecs); } } @@ -82,6 +85,7 @@ _statusline(Msg); if (Msg && *Msg) { CTRACE(tfp, "User message: %s\n", Msg); + _store_message(Msg); sleep(MessageSecs); } } @@ -95,6 +99,7 @@ CTRACE(tfp, "User message: "); CTRACE(tfp, Msg2, Arg); CTRACE(tfp, "\n"); + _store_message2(Msg2, Arg); sleep(MessageSecs); } } Only in .: lyexit.c Only in .: lyexit.h diff -u old/lygetfil.c ./lygetfil.c --- old/lygetfil.c Tue Apr 13 02:39:16 1999 +++ ./lygetfil.c Mon Apr 19 03:52:06 1999 @@ -259,6 +259,10 @@ return(lynx_compile_opts(doc)); #endif + } else if (url_type == LYNXMESSAGES_URL_TYPE) { + /* show list of recent statusline messages */ + return(LYshow_statusline_messages(doc)); + #ifndef DISABLE_NEWS } else if (url_type == NEWSPOST_URL_TYPE || url_type == NEWSREPLY_URL_TYPE || diff -u old/lyhistor.c ./lyhistor.c --- old/lyhistor.c Thu Apr 15 15:43:46 1999 +++ ./lyhistor.c Mon Apr 19 03:52:10 1999 @@ -14,6 +14,7 @@ #include #include #include +#include #ifdef DIRED_SUPPORT #include @@ -83,6 +84,7 @@ !strcmp((doc->title ? doc->title : ""), ADDRLIST_PAGE_TITLE) || #endif !strcmp((doc->title ? doc->title : ""), SHOWINFO_TITLE) || + !strcmp((doc->title ? doc->title : ""), STATUSLINES_TITLE) || !strcmp((doc->title ? doc->title : ""), CONFIG_DEF_TITLE) || !strcmp((doc->title ? doc->title : ""), LYNXCFG_TITLE) || !strcmp((doc->title ? doc->title : ""), COOKIE_JAR_TITLE) || @@ -392,7 +394,11 @@ BeginInternalPage(fp0, HISTORY_PAGE_TITLE, HISTORY_PAGE_HELP); + fprintf(fp0, "[%s]\n", + gettext("Your recent statusline messages")); + fprintf(fp0, "
      \n");
      +
           fprintf(fp0, "%s\n", gettext("You selected:"));
           for (x = nhist-1; x >= 0; x--) {
              /*
      @@ -595,3 +601,133 @@
           FREE(Address);
           return(0);
       }
      +
      +
      +/*
      + *  Keep cycled buffer for statusline messages.
      + */
      +#define STATUSBUFSIZE   40
      +PRIVATE char * buffstack[STATUSBUFSIZE];
      +PRIVATE int topOfStack = 0;
      +
      +PUBLIC void to_stack ARGS1(char *, str)
      +{
      +    /*
      +     *  Cycle buffer:
      +     */
      +    if (topOfStack == STATUSBUFSIZE) {
      +       topOfStack = 0;
      +    }
      +
      +    /*
      +     *  Register string.
      +     */
      +    FREE(buffstack[topOfStack]);
      +    buffstack[topOfStack] = str;
      +    topOfStack++;
      +}
      +
      +#ifdef LY_FIND_LEAKS
      +PRIVATE void free_messages_stack NOARGS
      +{
      +    topOfStack = STATUSBUFSIZE;
      +
      +    while (--topOfStack >= 0) {
      +       FREE(buffstack[topOfStack]);
      +    }
      +}
      +#endif
      +
      +/*
      + *  Status line messages list, LYNXMESSAGES:/ internal page,
      + *  called from getfile() cyrcle.
      + */
      +PUBLIC int LYshow_statusline_messages ARGS1(
      +    document *,                       newdoc)
      +{
      +    static char tempfile[LY_MAXPATH];
      +    static char *info_url;
      +    DocAddress WWWDoc;  /* need on exit */
      +    FILE *fp0;
      +    int i;
      +
      +
      +       LYRemoveTemp(tempfile);
      +       if ((fp0 = LYOpenTemp (tempfile, HTML_SUFFIX, "w")) == 0) {
      +           HTAlert(CANNOT_OPEN_TEMP);
      +           return(NOT_FOUND);
      +       }
      +       LYLocalFileToURL(&info_url, tempfile);
      +
      +       LYforce_no_cache = TRUE;  /* don't cache this doc */
      +
      +       BeginInternalPage (fp0, STATUSLINES_TITLE, NULL);
      +       fprintf(fp0, "
      \n");
      +
      +
      +           fprintf(fp0,  "
        \n"); + + i = topOfStack; + while (--i >= 0) { + if (buffstack[i] != NULL) + fprintf(fp0, "
      1. %s\n", buffstack[i]); + } + i = STATUSBUFSIZE; + while (--i >= topOfStack) { + if (buffstack[i] != NULL) + fprintf(fp0, "
      2. %s\n", buffstack[i]); + } + + fprintf(fp0, "
      \n"); + + + fprintf(fp0, "
      \n"); + EndInternalPage(fp0); + LYCloseTempFP(fp0); + + + /* exit to getfile() cyrcle */ + StrAllocCopy(newdoc->address, info_url); + WWWDoc.address = newdoc->address; + WWWDoc.post_data = newdoc->post_data; + WWWDoc.post_content_type = newdoc->post_content_type; + WWWDoc.bookmark = newdoc->bookmark; + WWWDoc.isHEAD = newdoc->isHEAD; + WWWDoc.safe = newdoc->safe; + + if (!HTLoadAbsolute(&WWWDoc)) + return(NOT_FOUND); + return(NORMAL); +} + + +PUBLIC void _store_message2 ARGS2( + CONST char *, message, + CONST char *, argument) +{ + char *temp = NULL; + + if (message == NULL) + return; + + HTSprintf(&temp, message, (argument == 0) ? "" : argument); + + to_stack(temp); + + return; +} +PUBLIC void _store_message ARGS1( + CONST char *, message) +{ + char *temp = NULL; + + if (message == NULL) + return; + + HTSprintf(&temp, message); + + to_stack(temp); + + return; +} + diff -u old/lyhistor.h ./lyhistor.h --- old/lyhistor.h Mon Sep 7 03:02:16 1998 +++ ./lyhistor.h Mon Apr 19 03:52:12 1999 @@ -14,4 +14,8 @@ extern void LYpop_num PARAMS((int number, document *doc)); extern void LYpush PARAMS((document *doc, BOOLEAN force_push)); +extern void _store_message2 PARAMS((CONST char *message, CONST char *argument)); +extern void _store_message PARAMS((CONST char *message)); +extern int LYshow_statusline_messages PARAMS((document *newdoc)); + #endif /* LYHISTORY_H */ diff -u old/lymessag.h ./lymessag.h --- old/lymessag.h Tue Mar 30 09:10:38 1999 +++ ./lymessag.h Mon Apr 19 03:52:14 1999 @@ -793,6 +793,7 @@ #define PERMIT_OPTIONS_TITLE gettext("File Permission Options") #define PRINT_OPTIONS_TITLE gettext("Printing Options") #define SHOWINFO_TITLE gettext("Information about the current document") +#define STATUSLINES_TITLE gettext("Your recent statusline messages") #define UPLOAD_OPTIONS_TITLE gettext("Upload Options") #define VISITED_LINKS_TITLE gettext("Visited Links Page") diff -u old/lyutils.c ./lyutils.c --- old/lyutils.c Tue Apr 13 02:39:16 1999 +++ ./lyutils.c Mon Apr 19 03:52:18 1999 @@ -2706,6 +2706,12 @@ */ return(LYNXCFG_URL_TYPE); + } else if (compare_type(cp, "LYNXMESSAGES:", 13)) { + /* + * Special Internal Lynx type. + */ + return(LYNXMESSAGES_URL_TYPE); + } else if (compare_type(cp, "LYNXCOMPILEOPTS:", 16)) { /* * Special Internal Lynx type. diff -u old/lyutils.h ./lyutils.h --- old/lyutils.h Tue Mar 30 09:10:38 1999 +++ ./lyutils.h Mon Apr 19 03:52:20 1999 @@ -186,10 +186,11 @@ #define LYNXOPTIONS_URL_TYPE 36 #define LYNXCFG_URL_TYPE 37 #define LYNXCOMPILE_OPTS_URL_TYPE 38 +#define LYNXMESSAGES_URL_TYPE 39 -#define PROXY_URL_TYPE 39 +#define PROXY_URL_TYPE 40 -#define UNKNOWN_URL_TYPE 40 +#define UNKNOWN_URL_TYPE 41 /* * For change_sug_filename(). From owner-lynx-dev@sig.net Sun Apr 18 20:39:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA01040 for ; Sun, 18 Apr 1999 20:39:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA16854; Sun, 18 Apr 1999 19:33:10 -0500 (CDT) Date: Sun, 18 Apr 1999 20:32:32 -0400 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev Re: http://www.slcc.edu/lynx/html/todo-list.html Message-ID: <19990418203232.A24425@mail.bcpl.net> References: <199904172217.SAA10639@news.put.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Klaus Weide on Sun, Apr 18, 1999 at 08:34:02AM -0500 X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'" cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U X-Hack: cough, cough X-Mailer: Mutt 0.95.1i (1999-01-04) X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000 X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs) X-Organization: planet earth X-Signature: /jes X-Url: "jim's subdomain" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3108 Lines: 63 On Sun, Apr 18, 1999 at 08:34:02AM -0500, Klaus Weide wrote: > On Sat, 17 Apr 1999, "News Subsystem" wrote: > > I'm not sure if the tod-list [sic] is being actively maintained... > Not very actively... I'm the "maintainer" of this page, meaning I'm supposed to mark the things as done or remove them when they get done. Direct suggestions or diffs against the html would be good. New requests for things "to-do" get added by others. As you can see, the page was last changed in Sep 1998. > > but the stuff > > on there about Cookies seems too cookie-friendly... > Most of what's listed there seems to be in the current cookie code > (2.8.1, and more so 2.8.2dev.N). Not just changes to make it > more "cookie-friendly" (less discerning in what is acceptable), > but also in the opposite direction. (It's not all well documented, > things are still in flux.) Quoting from that URL: > > * (Suggested by Hiram W. Lester, Jr.) Something needs to be done so > that cookies can be accepted from all domains by default. This is > available as command line "-cookies"; also see the cfg file > > There is now -accept_all_cookies and ACCEPT_ALL_COOKIES. Note that > the -cookies flag does NOT do this, the second sentence is wrong. > (-cookies is an overall flag to turn accepting of cookies on or > completely off.) > > * (Suggested by Hiram W. Lester, Jr.) Status message for accepting > cookies even if there was an option to always allow all cookies. > > In general, cookies that are deemed acceptable without needing user > confirmation are accepted quietly - a status message of each cookie > would be just too annoying, especially if the user had already said > he wanted such cookies. But there *is* a message (duration MESSAGESECS) > 'A'lways allowing from domain 'XXX.XX.XX'. > the first time a cookie from a given domain is auto-accepted, *if* > this happens just because of -accept_all_cookies or ACCEPT_ALL_COOKIES > (as opposed to previous 'A'lways answer to a prompt, or presence of > the domain in a COOKIE_ACCEPT_DOMAINS list or in a persistent cookie > file). > > * (Suggested by Rolf Puchtinger) Would it be possible to prompt > users for the option to save COOKIES with expiry dates longer than > "session" in a permanent file in the user's directory for > subsequent sessions? > > Persistent cookies are implemented (but still marked "experimental"). > Cookies with a given expiration in the future are saved to the persistent > cookie file on exit, if enabled. This was broken in 2.8.1 though, it > even saves cookies that should not be saved. (But they would be > discarded when the file is read the next time.) I don't follow the cookes development code closely, so I'm not qualified to write an update for the TODO page. Can someone give me a short blurb? Thanks! ------ Marvin the Paranoid Android says: It's the people you meet in this job that really get you down. From owner-lynx-dev@sig.net Sun Apr 18 21:09:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA02027 for ; Sun, 18 Apr 1999 21:09:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA20998; Sun, 18 Apr 1999 20:03:06 -0500 (CDT) To: uue@pauzner.mccme.ru References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 05:00:16 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev Re: (patch) - show list of statusline messages from history page MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1295 Lines: 44 19-Apr-99 04:31 I wrote: > * HTAlert, HTUserMsg and HTInfoMsg statusline messages now stored in a cyrcled > buffer and accessible from the History Page as LYNXMESSAGES:/ link. > This allow us to decrease the messages delay in lynx.cfg when we feel > messages too annoying, but have a nice history list for diagnostic purposes. > Idea belongs to Bela Lubkin. Buffer of 40 lines long. - LP * Also add numerous HTProgress messages to LYNXMESSAGES:/ page (but not HTReadProgress) diff -u ../htalert.c ./htalert.c --- ../htalert.c Mon Apr 19 03:52:04 1999 +++ ./htalert.c Mon Apr 19 04:51:22 1999 @@ -110,10 +110,9 @@ PUBLIC void HTProgress ARGS1( CONST char *, Msg) { - if (TRACE) - fprintf(tfp, "%s\n", Msg); - else statusline(Msg); + _store_message(Msg); + CTRACE(tfp, "%s\n", Msg); } /* Issue a read-progress message. HTReadProgress() @@ -179,7 +178,12 @@ if (total < -1) strcat(line, gettext(" (Press 'z' to abort)")); } - HTProgress(line); + + /* do not store the message for history page. */ + if (TRACE) + fprintf(tfp, "%s\n", line); + else + statusline(line); } } } From owner-lynx-dev@sig.net Sun Apr 18 22:27:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA04556 for ; Sun, 18 Apr 1999 22:27:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA03124; Sun, 18 Apr 1999 21:20:21 -0500 (CDT) Date: Mon, 19 Apr 1999 11:31:56 +0900 (JST) From: Henry Nelson Message-Id: <199904190231.LAA24869@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 16339 Lines: 333 > we'll have to rephrase all of the CTRACE macros. (I'd rather concentrate > on finishing off the dangling stuff for 2.8.2 than change 1400 lines of code) Recommended the following actions previously. Especially, since manual configuration on Un*x is no longer supported, and the fact that the docs/ *.old files are so out of date that they are useless, I hope they will be removed. Mention of them is removed from INSTALLATION with the following patch. The following patch also makes in addition to cosmetic changes: 1) rewording of the sentences concerning NLS 2) a better description of how to test Lynx before installing it (Un*x). __Henry Perhaps not this time around, but eventually: mv lynx2-8-2/LYMessages_en.h lynx2-8-2/src/LYMessages_en.h Definitely before a release: rm lynx2-8-2/docs/*.old Hopefully before a release, apply this patch: *** lynx2-8-2/INSTALLATION.dist Mon Apr 19 10:06:41 1999 --- lynx2-8-2/INSTALLATION Mon Apr 19 11:01:29 1999 *************** *** 2,27 **** Lynx Installation Guide This file describes how to compile and install Lynx. A description of Lynx ! can be found in the README file. Lynx has been ported to UN*X, VMS, ! Win32 and 386DOS. The procedures for compiling these ports are quite ! divergent and are detailed respectively in Sections II, III, IV and V. ! General installation, problem solving and environment variables are covered ! in Sections VI and VII. There is also a PROBLEMS file in the same directory ! as this INSTALLATION: it contains advice for a lot of special problems ! people have encountered, esp for particular machines & operating systems. If you don't understand what one of the defines means, try the README.defines and *.announce files in the docs subdirectory. The docs/CHANGES* files record the entire development history of Lynx and are an invaluable resource for understanding how Lynx should perform. - If you still have difficulties, send an e-mail message to the Lynx-Dev mailing - list lynx-dev@sig.net (see the README file). Try to include information about - your system, the name and version of your compiler, which curses library you - are using and the compile-time errors. Be sure to say what version and - image-number of Lynx you are trying to build (alternately the top date of the - CHANGES file). - First, you must configure Lynx for your system regardless of the port you will be using. Follow the instructions given immediately below to configure for your system, and then go to the respective section concerning the port you wish --- 2,26 ---- Lynx Installation Guide This file describes how to compile and install Lynx. A description of Lynx ! can be found in the README file. Lynx has been ported to UN*X, VMS, Win32 ! and 386DOS. The procedures for compiling these ports are quite divergent ! and are detailed respectively in Sections II, III, IV and V. General ! installation, problem solving and environment variables are covered in ! Sections VI and VII. There is also a PROBLEMS file in the same directory ! as INSTALLATION which contains advice for special problems people have ! encountered, especially for particular machines and operating systems. + If you still have difficulties, send an e-mail message to the Lynx-Dev mailing + list (see the README file). Try to include information about your system, + the name and version of your compiler, which curses library you are using + and the compile-time errors. Be sure to say what version and image-number + of Lynx you are trying to build (alternately the top date of the CHANGES file). + If you don't understand what one of the defines means, try the README.defines and *.announce files in the docs subdirectory. The docs/CHANGES* files record the entire development history of Lynx and are an invaluable resource for understanding how Lynx should perform. First, you must configure Lynx for your system regardless of the port you will be using. Follow the instructions given immediately below to configure for your system, and then go to the respective section concerning the port you wish *************** *** 30,47 **** I. General configuration instructions (all ports). ! Step 1. (define compile-time variables -- See the userdefs.h file.) There are a few variables that MUST be defined, or Lynx will not build. There are a few more that you will probably want to change. The variables that must be changed are marked as such in the userdefs.h file. Just edit ! this file, and the changes should be straight forward. Many of the ! variables in "userdefs.h" are now configurable in the lynx.cfg file, so ! you may set them at run-time if you wish. If you compile using auto- ! configure, you would not absolutely need to edit "userdefs.h". Check ! LYMessages_en.h for tailoring the Lynx statusline prompts, messages and ! warnings to the requirements of your site. Lynx implements Native ! Language Support. Read "ABOUT-NLS" if you are interested in building an ! international version of Lynx. Step 2. (define run-time variables -- See the lynx.cfg file for details.) Set up local printers, downloaders, assumed character set, key mapping, --- 29,45 ---- I. General configuration instructions (all ports). ! Step 1. (define compile-time variables) There are a few variables that MUST be defined, or Lynx will not build. There are a few more that you will probably want to change. The variables that must be changed are marked as such in the userdefs.h file. Just edit ! this file, and the changes should be straight forward. If you compile ! using autoconfigure, you should set defines with option switches and not ! edit userdefs.h directly. Many of the variables in userdefs.h are now ! configurable in the lynx.cfg file, so you may set them at run-time if you ! wish. Lynx implements Native Language Support. Read "ABOUT-NLS" if you ! want to build an international version of Lynx or tailor the statusline ! prompts, messages and warnings to the requirements of your site. Step 2. (define run-time variables -- See the lynx.cfg file for details.) Set up local printers, downloaders, assumed character set, key mapping, *************** *** 54,69 **** section below), specified with an environment variable, LYNX_CFG, or specified with the "-cfg" command line option. ! Step 3. (You may skip this step if you only use English and are not ! interested in any special characters, or if your display and local files ! will all use the ISO-8859-1 "ISO Latin 1" Western European character set.) ! People who will be running Lynx in an environment with different and ! incompatible character sets should configure CHARACTER_SET (the Display ! character set) and ASSUME_LOCAL_CHARSET to work correctly for them before ! creating bookmark files et cetera. Please read "lynx.cfg" for detailed ! instructions. Additional character sets and their properties may be ! defined with tables in the src/chrtrans directory, see the README.* files ! therein. Step 4. (optional -- news for UNIX and VMS) Set NNTPSERVER in "lynx.cfg" to your site's NNTP server, or set the --- 52,66 ---- section below), specified with an environment variable, LYNX_CFG, or specified with the "-cfg" command line option. ! Step 3. (You may skip this step if you use only English and are not interested ! in any special characters, or if your display and local files will all use ! the ISO-8859-1 "ISO Latin 1" Western European character set.) People who ! will be running Lynx in an environment with different and incompatible ! character sets should configure CHARACTER_SET (the Display character set) ! and ASSUME_LOCAL_CHARSET to work correctly for them before creating ! bookmark files et cetera. Read "lynx.cfg" for detailed instructions. ! Additional character sets and their properties may be defined with tables ! in the src/chrtrans directory, see the README.* files therein. Step 4. (optional -- news for UNIX and VMS) Set NNTPSERVER in "lynx.cfg" to your site's NNTP server, or set the *************** *** 469,476 **** I personally use the following csh shell script to set environment variables and configure options rather than type them each time. - setenv RESOLVLIB -lbind - #!/bin/csh -f setenv CPPFLAGS "-I$HOME/slang -I$HOME/.usr/include" setenv LIBS "-L$HOME/.slang/lib -L$HOME/.usr/lib" --- 466,471 ---- *************** *** 478,503 **** --mandir=$HOME/.usr/man --libdir=$HOME/.usr/lib \ --with-screen=slang --with-zlib ! The syntax for setting environment variables depends upon your shell. I ! use the libbind.a resolver library, not libresolv.a. Setting RESOLVLIB to ! -lbind defines this environment variable for `make', and thus must be set ! in the same shell that `make' will be run. CPPFLAGS in this example ! defines the full path to the slang and zlib header files, which are not ! kept in standard directories. Likewise, LIBS defines the nonstandard ! locations of libslang.a and libz.a. Setting the option --bindir tells ! the configure script where I want to install the lynx binary; setting ! --mandir tells it where to put the lynx.1 man page, and setting --libdir ! tells it (while at the same time defining LYNX_CFG_FILE) where to put the ! configuration file "lynx.cfg", when I type "make install". The ! --with-screen=slang and --with-zlib options are explained above. ! 2. Manual compile ! If auto-configure does not work for you, or you prefer to compile ! Lynx manually, "docs/Makefile.old" will serve as a template for the ! top-level Makefile, and instructions on how to compile are given in ! "docs/INSTALLATION.old". ! ! 3. Wais support (optional) To add direct WAIS support, get the freeWAIS distribution from "ftp://ftp.cnidr.org/pub/NIDR.tools/freewais", and compile it. The compile process will create the libraries you will need, wais.a and client.a. Edit --- 473,488 ---- --mandir=$HOME/.usr/man --libdir=$HOME/.usr/lib \ --with-screen=slang --with-zlib ! CPPFLAGS in this example defines the full path to the slang and zlib header ! files, which are not kept in standard directories. Likewise, LIBS defines ! the nonstandard locations of libslang.a and libz.a. Setting the option ! --bindir tells the configure script where I want to install the lynx ! binary; setting --mandir tells it where to put the lynx.1 man page, and ! setting --libdir tells it (while at the same time defining LYNX_CFG_FILE) ! where to put the configuration file "lynx.cfg", when I type "make install". ! The --with-screen=slang and --with-zlib options are explained above. ! 2. Wais support (optional) To add direct WAIS support, get the freeWAIS distribution from "ftp://ftp.cnidr.org/pub/NIDR.tools/freewais", and compile it. The compile process will create the libraries you will need, wais.a and client.a. Edit *************** *** 703,710 **** #define getmaxx(w) (w)->_maxx #define getmaxy(w) (w)->_maxy ! If you have trouble applying the patch, we recommend that you use the ! "patch" program, ("http://www.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/pat25b.zip"). The WATTCP TCPLIB sources must also be patched prior to compilation. See "http://www.flora.org/lynx-dev/html/month1197/msg00403.html". --- 688,694 ---- #define getmaxx(w) (w)->_maxx #define getmaxy(w) (w)->_maxy ! If you have trouble applying the patch, try using the "patch" program, ("http://www.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/pat25b.zip"). The WATTCP TCPLIB sources must also be patched prior to compilation. See "http://www.flora.org/lynx-dev/html/month1197/msg00403.html". *************** *** 768,774 **** "ftp://ftp.agate.net/users/01935/internet/dosppp06.zip"; "ftp://ftp.klos.com/demo/pppshare.exe".) - File access looks like this: file:///c:/ --- 752,757 ---- *************** *** 810,818 **** VI. General installation instructions ! Once you have compiled Lynx, test it out on "lynx_help/about_lynx.html". ! You shouldn't need to install Lynx to test it. Once you are satisfied ! that it works, go ahead and install Lynx. For Unix, type "make install". For VMS, you need to have the executable in a public place, make it accessible, define it as a foreign command, and copy lynx.cfg to --- 793,802 ---- VI. General installation instructions ! Once you have compiled Lynx, test it out first on a local file. Be sure ! Lynx can find lynx.cfg. A _sample_ test command line would be: ! `lynx -cfg=/usr/local/lib/lynx.cfg .` Once you are satisfied that ! Lynx works, go ahead and install it. For Unix, type "make install". For VMS, you need to have the executable in a public place, make it accessible, define it as a foreign command, and copy lynx.cfg to *************** *** 850,859 **** after you have installed Lynx. 2. Win32 (95/NT) and 386 DOS - These ports cannot start before setting certain environment variables ! (adapted from "readme.txt" by Wayne Buttles and "readme.dos" by Doug Kaufman) ! Here are some environment variables that should be set, usually in a batch file that runs the lynx executable. Make sure that you have enough room left in your environment. You may need to change your "SHELL=" --- 834,841 ---- after you have installed Lynx. 2. Win32 (95/NT) and 386 DOS ! These ports cannot start before setting certain environment variables. Here are some environment variables that should be set, usually in a batch file that runs the lynx executable. Make sure that you have enough room left in your environment. You may need to change your "SHELL=" *************** *** 860,866 **** setting in config.sys. In addition, lynx looks for a "SHELL" environment variable when shelling to DOS. If you wish to preserve the environment space when shelling, put a line like this in your AUTOEXEC.BAT file also ! "SET SHELL=C:\COMMAND.COM /E:2048". It should match CONFIG.SYS. HOME Where to keep the bookmark file and personal config files. TEMP or TMP Bookmarks are kept here with no HOME. Temp files here. --- 842,848 ---- setting in config.sys. In addition, lynx looks for a "SHELL" environment variable when shelling to DOS. If you wish to preserve the environment space when shelling, put a line like this in your AUTOEXEC.BAT file also ! "SET SHELL=C:\COMMAND.COM /E:2048". It should match CONFIG.SYS. HOME Where to keep the bookmark file and personal config files. TEMP or TMP Bookmarks are kept here with no HOME. Temp files here. *************** *** 879,885 **** set lynx_cfg=d:\win32\lynx.cfg d:\win32\lynx.exe %1 %2 %3 %4 %5 ! In lynx_386, a typical batch file might look like: @echo off set HOME=f:/lynx2-8 --- 861,867 ---- set lynx_cfg=d:\win32\lynx.cfg d:\win32\lynx.exe %1 %2 %3 %4 %5 ! For lynx_386, a typical batch file might look like: @echo off set HOME=f:/lynx2-8 *************** *** 888,897 **** set WATTCP.CFG=%HOME% f:\lynx2-8\lynx %1 %2 %3 %4 %5 %6 %7 %8 %9 ! You will also need to make sure that the WATTCP.CFG file has the ! correct information for IP number, Gateway, Netmask, and Domain Name ! Server. This can also be automated in the batch file. VIII. Acknowledgment --- 870,880 ---- set WATTCP.CFG=%HOME% f:\lynx2-8\lynx %1 %2 %3 %4 %5 %6 %7 %8 %9 ! You need to make sure that the WATTCP.CFG file has the correct information ! for IP number, Gateway, Netmask, and Domain Name Server. This can also be ! automated in the batch file. + Adapted from "readme.txt" by Wayne Buttles and "readme.dos" by Doug Kaufman. VIII. Acknowledgment From owner-lynx-dev@sig.net Mon Apr 19 00:27:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA08277 for ; Mon, 19 Apr 1999 00:27:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA21899; Sun, 18 Apr 1999 23:19:28 -0500 (CDT) Date: Thu, 15 Apr 1999 18:16:09 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: lynx-dev patch that adds few new attrs to html elements Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2981 Lines: 57 This patch adds the following attrs: {bq,blockquote}.cite,{frame,iframe,img}.longdesc, {table,td}.background, td.{height,width}. The {q,ins,del},cite, {span,div}.href were not added since their attributes are described by gen_attr, that is shared among other elements. Best regards, -Vlad begin 644 patch1.gz M'XL("-KD%3<``W!A=&-H,0"U66%SVD84_&Q^Q0W]D@:(.8%`N-,9"R2P&H&( M$"%NI\/8,:Z9VDY*<)M,)O^]=R;=9_'2\6B^-X?;FYV'PZCN[>WZ[N5O?;B^WZ MW?WQ63:.@RQX\1:^>;W^N+KZIJ]6&HW&TW_X*'M8,?_]AO$6X^Y)DY\TNXSW M>KU*K5;[CKLZRFX>\NNZC'=/'/>DUWK*&D[/JW=93?[CL=/3"OOR2X55 MV`=YE;?L8KO=L,M_EO+?/_YDO[+/1T='Q\]9_Q5[UH^3P7# M=O6!/3^N-(X^L^H@]F>S*MM]LF=O?V9?ZI6:.HNR\'`DSF[RL]U_E'^=Y9<. M_50_FQS.@D@[LZUZA]7:7ENP(6DP*;C>7-RM@(5AZH]# MJ_:O_9!>7YQ,1D$X&U1-"M37QWXZBB9G830ZRZI6#?G9(@JRLZI=WT3K^^TD:A"E<:__KW\[CX^7M`#^NS*ZGRO2X5N93QZ6$ M@F_M8@E+^=EL[$]+;BF:)?W?PD%6-<]D>;TVE^7UVBXYI=N+RUN9G[T)9\0H%&<1=?9X>>:4#L[TX;%*$6?)<%@ESV@#4V5V756F M.:6)9&5"7NMK4QI,K3'#,I^@9746^WF+J.]-DD6JC;#11<_)R^MIY05EOTD.,_"-]E2 MM'(>9N?3D(D;+`/Y699&_7D6SAAOBWXT3-BKI=*5UM(F!1&&KT$X0H2BC,%P M$!(%YNRT$"(%HD/:",EU)"L0T3-*Q>9]2)0@Q;I.[("05 M_*``A9J%V5*&&EH!>TB:+&:Z`ES>JXOU4G,=7F\W40%GZ7)'UDX!'"&6 M3+D#"HB*4F2\*%%``=$>DT`!!6378OFQ%1#A3-D*B(AQL240$>-B:R#"<;$U M$.$DV,LDPD'P2B":J?9HB-8K7L*OOO(%OS9H/#*:1/5)03)=L]`G`2E:N/M` MGP3$VG[0)P4QEA^T24"LW0==$A!]8*@N"8BU':%+$B(?(P\0Z)*"Y$^395T2 M$'/%8I<$9&S<"Z?8-7V#4^R:.YA3[)HKF%/LSB=1=N@1I]B=ST*-&$ZQ:WH( MI]@U/83;88`P$%@5A(/`JB`L!%8%X2&P*B+<2_:FH'P&5@5E-+`K"*>!74%8 M#20JPFO$C-(8?7IX"=-Z6WD)TWI?Q9S6;!0:#O85'0?[BI:#?47/P;ZBZ6!C MT76PKV@[V%;T'6PK&@^V%9T'VPK60W158HR@1705_$EU]1&#DO9#8,RG!$[Q M;#TE<(IGTZ.D`Q$8PZ2D!2'&3CH4SW;4P0>2:#*=BR?KP2"<[KIAQS$=LI2O MM40T$]=BQ\]9.APPI]EM*B!;<^^>-=C?_\E7)C*O>6Z[WNZRFN=Z=9=C7LO\ M_C)+#.;M'Y<0RVPYY#7U&M-V6PIB:,[>5#E$>SV).>``*=Y28@XH(+IP[4VU M@VBZM3=5`=E'9(8YX`"9AL7TVILJAQCBMW-``=$%:^>`')+_06/?)0JBNP/D M@!RBBQIR0`Z9),,X6100FEW]H1YR0`Y)Y_'^,1QR0`[1!0TYH(#,QV+7G>]$ M2$%TR7.:75WQG&97%[-#LZNKP,$LG`7$9D+(F]!Z@T-`(@,"70J4">@0Z%(. M28;#/02Z%,!R@RX%L-N@2\&R>#>^AT"7`MA^T*7`%``C-!#8NP\U$,#*(MBU MWD>A!@+UU*M5A!H(B%T$$%Q%`'EM#@QJ((`%8B\BPGDA$!76N_][BKH0C3$B MD;VH"7^&0$08-`0BPJ$A$!$6#8&(\&@(1(1)0R`B7!H"$6'3F(C0J#$1H5-C M(D*KQD2$7HV)",T:$Q&Z-28BM.NR0=3]&A,1&K:T8PIC9#2'YMG(7P[-L^'9 M^#A!>#8A'W1M0C_HVX2``DN%\@.-17LG)(0&3V@(+9X0$9H\H2*T>4)&:/2$ MCM#J*2$%\#1$*`E6`B4E6`J4EF`M4&*"Q4"I"58#)2=8#I2>8#U0@@KLIQ!" D4+!$A)[LIQ#YYST_#7UXRF@^\I11=IG]G?/*_QO9443X)0`` ` end From owner-lynx-dev@sig.net Mon Apr 19 00:39:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA08586 for ; Mon, 19 Apr 1999 00:39:36 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA23616; Sun, 18 Apr 1999 23:33:18 -0500 (CDT) Date: Thu, 15 Apr 1999 18:29:34 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev removing strings used in CTRACE when configured without tracing In-Reply-To: <199904181857.OAA29788@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1743 Lines: 38 On Sun, 18 Apr 1999 dickey@clark.net wrote: > > The use of '_' instead of ',' needs getting used to, but apparent it gets > > around the variable-argument-number problem nicely. > > maybe - though I'd have to test & see that the different preprocessor > agree (some people tend to think that if it works in gcc, it's portable - > I can remember an order-of-evaluation problem in gcc which the GNU people > had to abandon 4-5 years ago because it wasn't ANSI compatible) > > > It would be a problem if we used _() as a shhorthand for gettext(); but > > fortunately the lynx code uses gettext() directly. > > > > This would require replacing all TRACE messages throughout the code; > > but so would the other approaches that are worth considering, I think. > > > > I agree with Tom though that this is probably not the best time for it. > > yes - I'd rather do stuff like that early in a cycle. This week I'm working > to finish off changes for xterm for a code freeze in XFree86, then (unless > people have different ideas) it's time to do the same for lynx. >[...] One of the solutions may be the following: There is a standalone preprocessor distributed with gcc, it's called 'cccp' and it does support macros with variable number of args. It's self contained C file 300 KB long + cccp.1 15KB long. We can include it in the distribution of lynx, so it will be compiled by make before other sources of lynx (as gettext if absent), and be used for all lynx sources. 'cccp' is in the 'gcc' subdir of gcc distribution. In this case we can use macros with variable number of arguments. This won't require touching all *.c files. BTW: cccp binary is not shipped with RedHat 5.2, tho' cccp.1 is. Best regards, -Vlad From owner-lynx-dev@sig.net Mon Apr 19 05:02:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA17224 for ; Mon, 19 Apr 1999 05:02:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA15163; Mon, 19 Apr 1999 03:44:13 -0500 (CDT) To: lynx-dev@sig.net References: <9903291650.aa03687@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 12:38:48 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: (PATCH) strange HTTP/HTCheckForInterrupt() bug lynx-dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7704 Lines: 194 18-Apr-99 01:24 Leonid Pauzner wrote: > 29-Mar-99 16:50 Bela Lubkin wrote: >> This fixes one of the reported problems (characters other than INTERRUPT >> causing the DNS lookup delay to be shortened). It also fixes a serious >> problem that I noticed while looking into the other reports: if fork() >> failed, we were blindly going ahead and doing who knows what, including >> kill(-1, SIGTERM)! On my system, that means "send SIGTERM to every >> process with my UID" -- bad news indeed. >> But I don't think that's what Leonid was running into. That's something >> else, possibly the need to signal((various signals), quench) *before* >> fork(). >> CHANGES: >> * Behave sanely if NSL_FORK fork() fails. -BL >> * NSL_FORK try for dns_patience *seconds*, not dns_patience select() >> calls, which might have been shortened by keyboard input. -BL >> * Fix some screwy comment indentation. >> uuencoded (and gzip'd) to try to preserve spaces/tabs. >>>Bela< > Today I got the same strange buged behaviour, now with dev22. > Perhaps I press "z" in a "bad" moment (during DNS search or a little later). > ^Z spawn me to a shell and "fg" return me back without visible problems. Looking into trace log more carefully I found out that we use two DNS calls: first to resolve anchor and the second for making TCP connection. In case of local proxy we have the second DNS call for proxy address. Probably, interrupting the first call we crash the second by some means? Lynx Trace Log (2.8.2dev.22) User message: Trace ON! 'lynx.browser.org' is not a URL Converted 'lynx.browser.org' to '/home/pauzner/lynx.browser.org' Can't stat() or fopen() '/home/pauzner/lynx.browser.org' Looking up lynx.browser.org first. LYGetHostByName: parsing `lynx.browser.org'. CHILD gethostbyname: 0x400e6ef4 { h_name = 0x400e6fa5 "lynx.browser.org", h_aliases = 0x400e6f08 { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x400e6e64 { 0x400e6fb8 "195.40.122.44", 0x0 } } CHILD fill_rehostent: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } 'lynx.browser.org' is not a URL Converted 'lynx.browser.org' to '/home/pauzner/lynx.browser.org' Can't stat() or fopen() '/home/pauzner/lynx.browser.org' Looking up lynx.browser.org first. LYGetHostByName: parsing `lynx.browser.org'. Read from pipe: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: NSL_FORK child 2379 exited, status 0x0. End of LYGetHostByName: 0x811c360 { h_name = 0x811c384 "lynx.browser.org", h_aliases = 0x811c37c { 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } } LYGetHostByName: Resolved name to a hostent. Trying: 'http://lynx.browser.org' HTParse: aName:http://lynx.browser.org relatedName: 1 HTParse: result:http://lynx.browser.org/ LYpush[0]: address:http://www.mccme.ru/home.html title:MCCME: Bookmarks getfile: getting http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 0x8154b40 has hash 57 and address `http://lynx.browser.org/' HTAccess: loading document http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName:file: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http proxy server found: http://proxy.mccme.ru:3128/ HTParse: aName:http://proxy.mccme.ru:3128/http://lynx.browser.org/ relatedNam e:http: HTParse: result:http HTParse: aName:http://proxy.mccme.ru:3128/http://lynx.browser.org/ relatedNam e: HTParse: result:proxy.mccme.ru:3128 Looking up proxy.mccme.ru:3128. HTParseInet: parsing `proxy.mccme.ru:3128'. LYGetHostByName: parsing `proxy.mccme.ru'. CHILD gethostbyname: 0x400e6ef4 { h_name = 0x400e6fc1 "bsd18.mccme.ru", h_aliases = 0x400e6f08 { 0x400e6fa3 "proxy.mccme.ru", 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x400e6e64 { 0x400e6fd4 "195.133.68.18", 0x0 } } CHILD fill_rehostent: 0x811c360 { h_name = 0x811c388 "bsd18.mccme.ru", h_aliases = 0x811c37c { 0x811c397 "proxy.mccme.ru", 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c384 "195.133.68.18", 0x0 } } LYGetHostByName: Resolved name to a hostent. Trying: 'http://lynx.browser.org' HTParse: aName:http://lynx.browser.org relatedName: 1 HTParse: result:http://lynx.browser.org/ LYpush[0]: address:http://www.mccme.ru/home.html title:MCCME: Bookmarks getfile: getting http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 0x8154b40 has hash 57 and address `http://lynx.browser.org/' HTAccess: loading document http://lynx.browser.org/ HTParse: aName:http://lynx.browser.org/ relatedName:file: HTParse: result:http HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:lynx.browser.org HTParse: aName:http://lynx.browser.org/ relatedName: HTParse: result:http proxy server found: http://proxy.mccme.ru:3128/ HTParse: aName:http://proxy.mccme.ru:3128/http://lynx.browser.org/ relatedNam e:http: HTParse: result:http HTParse: aName:http://proxy.mccme.ru:3128/http://lynx.browser.org/ relatedNam e: HTParse: result:proxy.mccme.ru:3128 Looking up proxy.mccme.ru:3128. HTParseInet: parsing `proxy.mccme.ru:3128'. LYGetHostByName: parsing `proxy.mccme.ru'. Read from pipe: 0x811c360 { h_name = 0x811c388 "bsd18.mccme.ru", h_aliases = 0x811c37c { 0x811c397 "proxy.mccme.ru", 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c384 "195.133.68.18", 0x0 } } LYGetHostByName: NSL_FORK child 2380 exited, status 0x0. End of LYGetHostByName: 0x811c360 { h_name = 0x811c388 "bsd18.mccme.ru", h_aliases = 0x811c37c { 0x811c397 "proxy.mccme.ru", 0x0 }, h_addrtype = 2, h_length = 4, h_addr_list = 0x811c374 { 0x811c384 "195.133.68.18", 0x0 } } LYGetHostByName: Resolved name to a hostent. HTParseInet: Parsed address as port 3128, IP address 195.133.68.18 Making HTTP connection to proxy.mccme.ru:3128. ... Composing Proxy Authorization for proxy.mccme.ru:3128/http://lynx.browser.org/ HTAASetup_lookup: No template matched `http://lynx.browser.org/' (so probably n ot protected) HTTP: Not sending proxy authorization (yet). Writing: GET http://lynx.browser.org/ HTTP/1.0 Host: lynx.browser.org > Exiting via interrupt: 15 > [1]+ Stopped lynx > [pauzner@mccme pauzner]$ ps -a > PID TTY STAT TIME COMMAND > 94 2 S 0:00 /sbin/mingetty tty2 > 230 5 S 0:00 /sbin/mingetty tty5 > 231 6 S 0:00 /sbin/mingetty tty6 > 19434 3 S 0:00 /sbin/mingetty tty3 > 28384 1 S 0:00 /sbin/mingetty tty1 > 32691 4 S 0:00 /sbin/mingetty tty4 > 22774 a0 S 0:00 /bin/bash > 22776 a0 S 0:00 lynx > 28310 q0 S 0:00 bash > 2995 p1 S 0:00 -bash > 16098 p9 S 0:00 bash > 3203 p0 S 0:00 -bash > 3215 p0 T 0:03 lynx > 7156 p0 Z 0:00 (lynx ) > 7261 p0 R 0:00 ps -a > [pauzner@mccme pauzner]$ >> --ATTACHMENT-- Binary file From owner-lynx-dev@sig.net Mon Apr 19 05:03:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA17237 for ; Mon, 19 Apr 1999 05:03:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA15802; Mon, 19 Apr 1999 03:54:22 -0500 (CDT) Date: Mon, 19 Apr 1999 03:54:17 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: <199904190231.LAA24869@ibr1.irm.nara.kindai.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2259 Lines: 45 I agree that the new text is mostly better. (Removing *.old stuff is a different topic). But: On Mon, 19 Apr 1999, Henry Nelson wrote: > ! Step 1. (define compile-time variables) > There are a few variables that MUST be defined, or Lynx will not build. > There are a few more that you will probably want to change. The variables > that must be changed are marked as such in the userdefs.h file. Just edit > ! this file, and the changes should be straight forward. If you compile > ! using autoconfigure, you should set defines with option switches and not > ! edit userdefs.h directly. That last sentence reads as if editing userdefs.h was completely unnecessary and not recommended at all if configure is used. That's of course not true. There are only a handful of userdefs.h settings that can be preempted with flags to ./configure. It also contradicts what userdefs.h says. More than two thirds of it are in sections marked "MUST change (or verify)". [In practice, that MUST isn't true for most users since there are sensible defaults, and I doubt many people take it seriously. But some options that really need to be reviewed by the installer (like GLOBAL_MAILCAP) are grouped together in section 1.) with others that can be safely left at their defaults (like GOTOBUFFER). The latter really don't deserve to be marked as "MUST change". That's probably all or most of current 1c).] ---- Henry didn't change it, but I noticed that Step 3 is giving wrong advice; it would be more correct with the 5 words inserted below. > ! Step 3. (You may skip this step if you use only English and are not interested > ! in any special characters, or if your display and local files will all use ^ ...and all visited Web pages... > ! the ISO-8859-1 "ISO Latin 1" Western European character set.) People who > ! will be running Lynx in an environment with different and incompatible > ! character sets should configure CHARACTER_SET (the Display character set) > ! and ASSUME_LOCAL_CHARSET to work correctly for them before creating > ! bookmark files et cetera. Klasu From owner-lynx-dev@sig.net Mon Apr 19 05:27:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA17805 for ; Mon, 19 Apr 1999 05:27:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA19258; Mon, 19 Apr 1999 04:18:46 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 13:16:09 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1191 Lines: 27 19-Apr-99 03:54 Klaus Weide wrote: > I agree that the new text is mostly better. (Removing *.old stuff is > a different topic). But: > Henry didn't change it, but I noticed that Step 3 is giving wrong advice; > it would be more correct with the 5 words inserted below. >> ! Step 3. (You may skip this step if you use only English and are not interested >> ! in any special characters, or if your display and local files will all use > ^ > ...and all visited Web pages... >> ! the ISO-8859-1 "ISO Latin 1" Western European character set.) People who >> ! will be running Lynx in an environment with different and incompatible >> ! character sets should configure CHARACTER_SET (the Display character set) >> ! and ASSUME_LOCAL_CHARSET to work correctly for them before creating >> ! bookmark files et cetera. Oh, ASSUME_LOCAL_CHARSET isn't defined in userdefs.h. Probably it would be said clearly "don't forget to look into lynx.cfg and set your CHARACTER_SET (the Display character set) and ASSUME_LOCAL_CHARSET properly"... > Klasu From owner-lynx-dev@sig.net Mon Apr 19 05:27:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA17810 for ; Mon, 19 Apr 1999 05:27:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA27918; Mon, 19 Apr 1999 04:20:10 -0500 (CDT) From: dickey@clark.net Message-Id: <199904190920.FAA25093@shell.clark.net> Subject: Re: lynx-dev removing strings used in CTRACE when configured without To: lynx-dev@sig.net Date: Mon, 19 Apr 1999 05:20:06 -0400 (EDT) In-Reply-To: from "Vlad Harchev " at Apr 15, 99 06:29:34 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 389 Lines: 14 > One of the solutions may be the following: > There is a standalone preprocessor distributed with gcc, it's called 'cccp' > and it does support macros with variable number of args. no (I've already been there). that also is gcc-specific, and changes in subtle, incompatible ways as gcc evolves. > -Vlad -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 19 05:58:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA18590 for ; Mon, 19 Apr 1999 05:58:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA29979; Mon, 19 Apr 1999 04:43:01 -0500 (CDT) Date: Mon, 19 Apr 1999 04:42:45 -0500 (CDT) From: Klaus Weide To: ralph.usenet@gmx.net cc: lynx-dev@sig.net Subject: Re: lynx-dev lynx with -color and -lss In-Reply-To: <19990418222554.A445@cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4079 Lines: 95 Please send your messages to the lynx-dev list; I am cc'ing this reply. On Sun, 18 Apr 1999 ralph.usenet@gmx.net wrote: > Hello Klaus, > > Thanks for your information, that should help to track down the > problem. To make a long story short, I was able to get colors > from lynx while I was writing this e-mail. :-) Solution: use -term > option instead of -color! > > Since I'm still curious about what's wrong, I took the liberty of > including some diagnostic messages. There's nothing really 'wrong', but there are two different philosophies here: - Try to enable color 'somehow', even if that may contradict the the terminfo (or termcap) information. (slang) That includes allowing the user to override the assumption that the terminal does *not* support color (derived form terminfo). - Strictly believe the terminfo (or termcap) information (ncurses). When built with slang, lynx follows the slang philosopy; when built with ncurses, it follows the ncurses philosophy... > > [./configure ...] > > That should work fine, at least with a not-too-old version of ncurses. > > ncurses is version 4.2.10, slang is 0.99.38.8. I'm not familiar > with curses at all, but I noticed something peculiar: I re-unpacked > the lynx-tarball and configured --with-screen=slang. This time I > got an error message: > > [...] > checking for screen type... slang > checking if we can link slang without termcap... yes > checking if color-style code should be used... configure: > error: Configuration does not support color-styles > > The message disappears if I configure for ncurses, make clean, and > configure for slang again. Guess make clean doesn't make that > clean. Color-style only works with (n?)curses, not with slang. There may be a glitch in the configure script here, but I am not familiar with its details. Maybe the error would not have happened if you had done `make clean' *and* `rm config.cache'. > > And as Tom notes, the -color flag is only for slang and isn't needed > > otherwise (with or without color-style). > > I see; I probably wasn't very clear here. When I compile lynx > (with or without support for lss files), the resulting binary > doesn't support the -color command line option like the Red Had > binary, i.e. I get an 'invalid option' error message. The color flag is recognized if and only if lynx was compiled with slang. So the Red Hat binary must have been compiled with slang. You should be able to verify that by running `ldd' on the binary. > > If you terminal type according to $TERM supports color (well enough), > > colors will be used. > > Yes, here's the catch. The Red Hat binary correctly identifies an > rxvt and shows colors automatically, and in an xterm, I can start > the Red Hat lynx with -color to get color. My homegrown lynx, on > the other hand, needs to be invoked with '-term=rxvt' for colors. > I found this behavior puzzling; if you have a ready explanation > for this, I'd be eager to hear it, otherwise don't bother -- I'm > happy that it works. Please review other messages on this topic, especially form the last week or so, in the lynx-dev archives. Your xterm terminfo file says that color is not supported, and your rxvt terminfo file says that color is supported. I assume your xterm program is configured to set TERM to "xterm", and that "rxvt" also sets TERM to "xterm". But you can change these if you want (make xterm set TERM to one of the alternative types like "xterm-color", "xterm-xfree86" or whatever is appropriate, and make rxvt set TERM to "rxvt"), by putting the right magical incantation in the right Xresources (or similar) file; something like 'XTerm*termName: xterm-xfree86'; see the man pages [and write up a mini-Howto after you've figured it all out...]. You may wonder why this isn't being done by default. The answer afaik is for compatibility with other systems that know only about basic xterms without color (or other extensions): for example if you telnet from an xterm window into a different OS (or the other way round). Klaus From owner-lynx-dev@sig.net Mon Apr 19 06:14:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA19088 for ; Mon, 19 Apr 1999 06:14:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA01539; Mon, 19 Apr 1999 05:05:18 -0500 (CDT) Date: Mon, 19 Apr 1999 06:01:26 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev The whole CTRACE thing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 971 Lines: 30 Again, not advocating doing anything drastic for 2.8.2, but I do think CTRACE needs to be replaced eventually. Here's why: CTRACE(...); if (TRACE) fprintf(...); ^^^^^^ literal text from the original line So what happens with this? if (warning_cond) /* Note lack of {}s */ CTRACE(... "Warning: blah blah"); else do_safe_stuff(); becomes (to the compiler): if(warning_cond) if (TRACE) fprintf(... "Warning: blah blah"); else /* bound to the if (TRACE), not the if (warning_cond) */ do_safe_stuff(); Now, I don't think this has happened in the lynx source as far as I can see. People have been careful to wrap if/elses using CTRACE with {}s. That doesn't mean it isn't an accident waiting to happen. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Mon Apr 19 06:36:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA19606 for ; Mon, 19 Apr 1999 06:36:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA03119; Mon, 19 Apr 1999 05:26:25 -0500 (CDT) Date: Mon, 19 Apr 1999 12:26:17 +0200 (CEST) Message-Id: <199904191026.MAA08275@login-2.eunet.no> From: "Gisle Vanem" To: lynx-dev@sig.net Subject: Re: lynx-dev The whole CTRACE thing X-Mailer: Watt/POP MIME-Version: 1.0 Content-type: text/plain; charset=cp850 Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 885 Lines: 34 John Bley said: > Again, not advocating doing anything drastic for 2.8.2, but I do think > CTRACE needs to be replaced eventually. Here's why: > CTRACE(...); > if (TRACE) fprintf(...); > ^^^^^^ literal text from the original line > > So what happens with this? > if (warning_cond) /* Note lack of {}s */ > CTRACE(... "Warning: blah blah"); > else > do_safe_stuff(); > > becomes (to the compiler): > > if(warning_cond) > if (TRACE) fprintf(... "Warning: blah blah"); > else /* bound to the if (TRACE), not the if (warning_cond) */ > do_safe_stuff(); That's easy to fix: #define CTRACE(arg) do { \ if (TRACE) \ fprintf arg; \ } while (0) However, this requires extra paranthesis: CTRACE ((tfp, "foo")); Gisle V. From owner-lynx-dev@sig.net Mon Apr 19 06:50:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA20081 for ; Mon, 19 Apr 1999 06:50:49 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04043; Mon, 19 Apr 1999 05:38:31 -0500 (CDT) From: dickey@clark.net Message-Id: <199904191038.GAA01854@shell.clark.net> Subject: Re: lynx-dev The whole CTRACE thing To: lynx-dev@sig.net Date: Mon, 19 Apr 1999 06:38:12 -0400 (EDT) In-Reply-To: from "John Bley " at Apr 19, 99 06:01:26 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1629 Lines: 48 > > Again, not advocating doing anything drastic for 2.8.2, but I do think > CTRACE needs to be replaced eventually. Here's why: yes (eventually). I'm aware of this (bear in mind that before the 2.8.2 development, we had no working varargs - someone broke lynx's includes for that to workaround a bug in slang). Doing CTRACE the 'right' way would be easiest by cloning the HTSprint/HTSprintf0 varargs processing (or restructuring a little to pass a va_list pointer to common code). I'm more interested in making HTSprintf, etc., well tested in the context of buffer overflow though, than in refining a second-order problem. > CTRACE(...); > if (TRACE) fprintf(...); > ^^^^^^ literal text from the original line > > So what happens with this? > if (warning_cond) /* Note lack of {}s */ > CTRACE(... "Warning: blah blah"); > else > do_safe_stuff(); > > becomes (to the compiler): > > if(warning_cond) > if (TRACE) fprintf(... "Warning: blah blah"); > else /* bound to the if (TRACE), not the if (warning_cond) */ > do_safe_stuff(); > > Now, I don't think this has happened in the lynx source as far as I can see. > People have been careful to wrap if/elses using CTRACE with {}s. > That doesn't mean it isn't an accident waiting to happen. > > -- > John Bley - jbb6@acpub.duke.edu > Duke '99 - English/Computer Science > Since English is a mess, it maps well onto the problem space, > which is also a mess, which we call reality. - Larry Wall -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 19 06:57:17 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA20132 for ; Mon, 19 Apr 1999 06:57:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA03600; Mon, 19 Apr 1999 05:32:53 -0500 (CDT) From: Philip Webb Message-Id: <199904191032.GAA24246@chass.utoronto.ca> Subject: Re: lynx-dev screen widths To: lynx-dev@sig.net Date: Mon, 19 Apr 1999 06:32:50 -0400 (EDT) In-Reply-To: <19990418031150.01920@firepower> from "Sergey Svishchev" at Apr 18, 99 03:11:50 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1756 Lines: 35 thanx everyone who responded to my questions about screen widths, something not previously explored on lynx-dev IIRC. there seem to be 2 results, but little consensus. (1) 5 people regularly use a display > 79 columns : 3 express strong feelings that their freedom is at stake if someone cuts line off short of a paragraph end, 2 of whom know Lynx too well to consult documentation frequently; 2 don't seem to have strong feeling about it. only 1 uses a window of 45 - 50 columns for documentation, tho' not frequently for Lynx. 1 hardly ever uses displays <> 79 columns ; presumably, most other users don't either. as i said originally, i'm not going to pursue an argument about using
      or
       to lay out documentation neatly;
          insofar as users may be using displays  <> 79 columns ,
          it is clearly impossible to make things neat for everyone.
      
      (2)  2  people agree with me that using only  70  of  79 columns is wasteful
          & should be configurable;
           2  perhaps agree, but hold that it belongs in a style-sheet,
          for which of course we may have to wait rather a long time;
           1  argues that the long-standing Lynx layout in fact has a pattern,
          if only people notice it (documentation would help here too).
      
          in the absence of style-sheets in the near future,
          i'ld say L/R columns in the screen display should be configurable
          via an Option, but of course someone has to do the coding (BL?).
      
      -- 
      ========================,,============================================
      SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
      ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
      TRANSIT    `-O----------O---'  University of Toronto
      
      From owner-lynx-dev@sig.net  Mon Apr 19 06:58:56 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA20151
      	for ; Mon, 19 Apr 1999 06:58:55 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04699; Mon, 19 Apr 1999 05:46:25 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904191046.GAA02640@shell.clark.net>
      Subject: Re: lynx-dev lynx with -color and -lss
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 06:46:21 -0400 (EDT)
      In-Reply-To:   from "Klaus Weide " at Apr 19, 99 04:42:45 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1534
      Lines: 35
      
      > > Yes, here's the catch.  The Red Hat binary correctly identifies an 
      > > rxvt and shows colors automatically, and in an xterm, I can start 
      > > the Red Hat lynx with -color to get color.  My homegrown lynx, on 
      > > the other hand, needs to be invoked with '-term=rxvt' for colors. 
      > > I found this behavior puzzling; if you have a ready explanation 
      > > for this, I'd be eager to hear it, otherwise don't bother -- I'm 
      > > happy that it works. 
      
      The ncurses terminfo defines an 'rxvt' entry; the default 'xterm' entry
      does not define color (though the install instructions say to change
      _that_ to whatever's best for your installation).  rxvt and xterm are
      different enough that they have different terminal descriptions (both
      are different from XFree86 xterm).
      
      On my home machine, I have compiled several emulators, each setting
      $TERM to match the appropriate description (xterm-r5, xterm-r6, several
      versions of XFree86 xterm, kterm, emu, rxvt and aterm -- no eterm since
      it won't build w/o that imlib stuff)
        
      > Please review other messages on this topic, especially form the last 
      > week or so, in the lynx-dev archives. 
      >  
      > Your xterm terminfo file says that color is not supported, and 
      > your rxvt terminfo file says that color is supported.  I assume 
      > your xterm program is configured to set TERM to "xterm", and 
      
      rxvt sets the $COLORTERM environment variable, which slang applications
      look for.  That's probably why it "works".
      
      >    Klaus 
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Mon Apr 19 07:09:46 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA20437
      	for ; Mon, 19 Apr 1999 07:09:45 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05401; Mon, 19 Apr 1999 05:55:30 -0500 (CDT)
      Date: Mon, 19 Apr 1999 05:55:27 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: strange HTTP/HTCheckForInterrupt() bug lynx-dev
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 3434
      Lines: 89
      
      On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      > 18-Apr-99 01:24 Leonid Pauzner wrote:
      > > 29-Mar-99 16:50 Bela Lubkin wrote:
      > >> This fixes one of the reported problems (characters other than INTERRUPT
      > >> causing the DNS lookup delay to be shortened).  It also fixes a serious
      > >> problem that I noticed while looking into the other reports: if fork()
      > >> failed, we were blindly going ahead and doing who knows what, including
      > >> kill(-1, SIGTERM)!  On my system, that means "send SIGTERM to every
      > >> process with my UID" -- bad news indeed.
      > 
      > >> But I don't think that's what Leonid was running into.  That's something
      > >> else, possibly the need to signal((various signals), quench) *before*
      > >> fork().
      > 
      > >> CHANGES:
      > 
      > >>   * Behave sanely if NSL_FORK fork() fails. -BL
      > >>   * NSL_FORK try for dns_patience *seconds*, not dns_patience select()
      > >>     calls, which might have been shortened by keyboard input. -BL
      > >>   * Fix some screwy comment indentation.
      > 
      > > Today I got the same strange buged behaviour, now with dev22.
      > > Perhaps I press "z" in a "bad" moment (during DNS search or a little later).
      > > ^Z spawn me to a shell and "fg" return me back without visible problems.
      > 
      > 
      > Looking into trace log more carefully I found out that we use two DNS calls:
      > first to resolve anchor and the second for making TCP connection.
      
      Only if you don't give a complete URL, of course.
      
      > In case of local proxy we have the second DNS call for proxy address.
      > Probably, interrupting the first call we crash the second by some means?
      
      This is still a mystery to me.  It would help if the "Exiting with interrupt"
      message mentioned the process id.
      
      Did you interrupt with 'z' at any point?  When?
      
      Anyway, in your trace both lookups succeded:
      
      > LYGetHostByName: NSL_FORK child 2379 exited, status 0x0.
      > End of LYGetHostByName: 0x811c360 { h_name = 0x811c384 "lynx.browser.org",
      >          h_aliases = 0x811c37c { 0x0 },
      >          h_addrtype = 2, h_length = 4,
      >          h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } }
      > LYGetHostByName: Resolved name to a hostent.
      
      > LYGetHostByName: NSL_FORK child 2380 exited, status 0x0.
      > End of LYGetHostByName: 0x811c360 { h_name = 0x811c388 "bsd18.mccme.ru",
      >          h_aliases = 0x811c37c {  0x811c397 "proxy.mccme.ru", 0x0 },
      >          h_addrtype = 2, h_length = 4,
      >          h_addr_list = 0x811c374 { 0x811c384 "195.133.68.18", 0x0 } }
      > LYGetHostByName: Resolved name to a hostent.
      
      Note the status 0x0 both times.  No problem here.
      
      > > Exiting via interrupt: 15
      > 
      > 
      > > [1]+  Stopped                 lynx
      > > [pauzner@mccme pauzner]$ ps -a
      > >   PID TTY STAT  TIME COMMAND
        .......
      > >  3203  p0 S    0:00 -bash
      > >  3215  p0 T    0:03 lynx
      > >  7156  p0 Z    0:00 (lynx )
      > >  7261  p0 R    0:00 ps -a
      > > [pauzner@mccme pauzner]$
      
      This doesn't seem to have anything to do with the trace you showed,
      the pid of the zombie process is completely different.?
      
       ------------------------
      
      Those traces are harder to understand because large sections
      are duplicated, both the child and parent write the same messages
      already buffered when the fork() occurs to the trace log.
      
      As I said in ,
      try inserting a
      
                 CTRACE_FLUSH(tfp);
      
      before the second '#ifdef NSL_FORK' in LYGetHostByName().
      But I don't know that this has anything to do with the problem.
      
         Klaus
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 07:30:55 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA21101
      	for ; Mon, 19 Apr 1999 07:30:54 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07251; Mon, 19 Apr 1999 06:15:28 -0500 (CDT)
      From: Philip Webb 
      Message-Id: <199904191115.HAA25420@chass.utoronto.ca>
      Subject: lynx-dev INSTALLATION file changes (was something)
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 07:15:29 -0400 (EDT)
      In-Reply-To: <199904190231.LAA24869@ibr1.irm.nara.kindai.ac.jp> from "Henry Nelson" at Apr 19, 99 11:31:56 am
      X-Mailer: ELM [version 2.4 PL24]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 565
      Lines: 14
      
      990419 Henry Nelson wrote: 
      > Perhaps not this time around, but eventually:
      >  mv lynx2-8-2/LYMessages_en.h lynx2-8-2/src/LYMessages_en.h
      > Definitely before a release:
      >  rm lynx2-8-2/docs/*.old
      
      both long-felt wants: let's do them for 2-8-2.
      your attention to documentation is appreciated here.
      
      -- 
      ========================,,============================================
      SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
      ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
      TRANSIT    `-O----------O---'  University of Toronto
      
      From owner-lynx-dev@sig.net  Mon Apr 19 07:31:37 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA21116
      	for ; Mon, 19 Apr 1999 07:31:36 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA06301; Mon, 19 Apr 1999 06:05:05 -0500 (CDT)
      Date: Mon, 19 Apr 1999 07:04:31 -0400 (EDT)
      From: lvirden@cas.org (Larry W. Virden)
      Message-Id: <9904190704.AA14272@cas.org>
      Subject: Re: lynx-dev patch that adds few new attrs to html elements
      In-Reply-To: Your message of Thu, 15 Apr 1999 18:16:09 +0500 (SAMST)
      To: lynx-dev@sig.net
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 560
      Lines: 14
      
      Thanks for adding the new attributes.
      
      I was curious though -
      
      >  The {q,ins,del},cite, {span,div}.href were not added since their attributes
      >are described by gen_attr, that is shared among other elements.
      
      What do you mean here - that these were not added because the attributes
      are shared?
      -- 
      Larry W. Virden                 
       <*> O- "No one is what he seems."
      Unless explicitly stated to the contrary, nothing in this posting should 
      be construed as representing my employer's opinions.
      
      From owner-lynx-dev@sig.net  Mon Apr 19 08:32:09 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA22989
      	for ; Mon, 19 Apr 1999 08:32:08 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14181; Mon, 19 Apr 1999 07:20:52 -0500 (CDT)
      Date: Mon, 19 Apr 1999 08:17:58 -0400 (EDT)
      From: John Bley 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev The whole CTRACE thing
      In-Reply-To: <199904191026.MAA08275@login-2.eunet.no>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 547
      Lines: 20
      
      On Mon, 19 Apr 1999, Gisle Vanem wrote:
      
      > #define CTRACE(arg) do {              \
      >                       if (TRACE)      \
      >                          fprintf arg; \
      >                     } while (0)
      > 
      > However, this requires extra paranthesis:
      > 
      >   CTRACE ((tfp, "foo"));
      
      Is this portable?  I was unaware the preprocessor could do that.
      
      
      -- 
      John Bley - jbb6@acpub.duke.edu
      Duke '99 - English/Computer Science
        Since English is a mess, it maps well onto the problem space,
        which is also a mess, which we call reality.     - Larry Wall
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 08:45:47 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA23310
      	for ; Mon, 19 Apr 1999 08:45:46 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA15598; Mon, 19 Apr 1999 07:30:08 -0500 (CDT)
      Date: Mon, 19 Apr 1999 07:30:03 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: lynx-dev strange HTTP/HTCheckForInterrupt() bug - another patch
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2645
      Lines: 99
      
      On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      > 18-Apr-99 01:24 Leonid Pauzner wrote:
      > > 29-Mar-99 16:50 Bela Lubkin wrote:
      > 
      > >> But I don't think that's what Leonid was running into.  That's something
      > >> else, possibly the need to signal((various signals), quench) *before*
      > >> fork().
      
      Try this.  Untested, since I didn't get the abnormal exit frequentely.
      Disadvantage: requires sigprocmask(), so far we have always avoided
      using anything more than just 'signal()'.  For now needs explicit
      -DHAVE_SIGPROCMASK.
      
         Klaus
      
      --- lynx2-8-2.old/WWW/Library/Implementation/HTTCP.c	Tue Apr 13 04:39:16 1999
      +++ lynx2-8-2/WWW/Library/Implementation/HTTCP.c	Mon Apr 19 07:06:17 1999
      @@ -686,6 +686,10 @@
       
           lynx_nsl_status = HT_INTERNAL;	/* should be set to something else below */
       
      +#ifdef DEBUG_HOSTENT_CHILD
      +    CTRACE_FLUSH(tfp);
      +#endif
      +
       #ifdef NSL_FORK
           statuses.h_errno_valid = NO;
       	/*
      @@ -694,6 +698,10 @@
       	*/
           {
       	int got_rehostent = 0;
      +#ifdef HAVE_SIGPROCMASK
      +	sigset_t old_sigset;
      +	sigset_t new_sigset;
      +#endif
       	/*
       	**	Pipe, child pid, status buffers, start time, select()
       	**	control variables.
      @@ -722,6 +730,31 @@
       
       	pipe(pfd);
       
      +#ifdef HAVE_SIGPROCMASK
      +	/*
      +	 *  Attempt to prevent a rare situation where the child
      +	 *  could execute the Lynx signal handlers because it gets
      +	 *  killed before it even has a chance to reset its handlers.
      +	 *  - kw
      +	 */
      +	sigemptyset(&new_sigset);
      +	sigaddset(&new_sigset, SIGTERM);
      +	sigaddset(&new_sigset, SIGINT);
      +#ifndef NOSIGHUP
      +	sigaddset(&new_sigset, SIGHUP);
      +#endif /* NOSIGHUP */
      +#ifdef SIGTSTP
      +	sigaddset(&new_sigset, SIGTSTP);
      +#endif /* SIGTSTP */
      +#ifdef SIGWINCH
      +	sigaddset(&new_sigset, SIGWINCH);
      +#endif /* SIGWINCH */
      +	sigaddset(&new_sigset, SIGBUS);
      +	sigaddset(&new_sigset, SIGSEGV);
      +	sigaddset(&new_sigset, SIGILL);
      +	sigprocmask(SIG_BLOCK, &new_sigset, &old_sigset);
      +#endif /* HAVE_SIGPROCMASK */
      +
       	if ((fpid = fork()) == 0 ) {
       	    struct hostent  *phost;	/* Pointer to host - See netdb.h */
       	    /*
      @@ -759,6 +792,11 @@
       	    signal(SIGSEGV, SIG_DFL);
       	    signal(SIGILL, SIG_DFL);
       
      +#ifdef HAVE_SIGPROCMASK
      +	    /* Restore signal mask to whatever it was before the fork. -kw */
      +	    sigprocmask(SIG_SETMASK, &old_sigset, NULL);
      +#endif /* HAVE_SIGPROCMASK */
      +
       	    /*
       	    **  Child won't use read side.  -BL
       	    */
      @@ -809,6 +847,14 @@
       		_exit(1);
       	    }
       	}
      +
      +#ifdef HAVE_SIGPROCMASK
      +	/*
      +	**  (parent) Restore signal mask to whatever it was
      +	**  before the fork. - kw
      +	*/
      +	sigprocmask(SIG_SETMASK, &old_sigset, NULL);
      +#endif /* HAVE_SIGPROCMASK */
       
       	/*
       	**	(parent) Wait until lookup finishes, or interrupt,
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 08:47:53 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA23348
      	for ; Mon, 19 Apr 1999 08:47:50 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16862; Mon, 19 Apr 1999 07:37:40 -0500 (CDT)
      Date: Fri, 16 Apr 1999 00:41:32 +0500 (SAMST)
      From: Vlad Harchev 
      X-Sender: hvv@localhost.localdomain
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev removing strings used in CTRACE when configured without
      In-Reply-To: <199904190920.FAA25093@shell.clark.net>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 710
      Lines: 19
      
      On Mon, 19 Apr 1999 dickey@clark.net wrote:
      
      > >   One of the solutions may be the following: 
      > >  There is a standalone preprocessor distributed with gcc, it's called 'cccp' 
      > > and it does support macros with variable number of args.  
      > 
      > no (I've already been there).  that also is gcc-specific, and changes in
      > subtle, incompatible ways as gcc evolves.
      
        We can get a snapshot from the latest gcc/egcs version and use it forever, 
      without changing. I have an imression, that it wasn't modified last 4 years. 
      On the other hand, developers of lynx get the reliable and very powerful tool,
      that is thoroughly tested. IMO macros with varargs are useful not in CTRACE. 
      
      >[...] 
      
       Best regards,
        -Vlad
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 08:48:07 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA23353
      	for ; Mon, 19 Apr 1999 08:48:03 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16875; Mon, 19 Apr 1999 07:37:43 -0500 (CDT)
      Date: Fri, 16 Apr 1999 00:25:29 +0500 (SAMST)
      From: Vlad Harchev 
      X-Sender: hvv@localhost.localdomain
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev patch that adds few new attrs to html elements
      In-Reply-To: <9904190704.AA14272@cas.org>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1021
      Lines: 28
      
      On Mon, 19 Apr 1999, Larry W. Virden wrote:
      
      > Thanks for adding the new attributes.
      > 
      > I was curious though -
      > 
      > >  The {q,ins,del},cite, {span,div}.href were not added since their attributes
      > >are described by gen_attr, that is shared among other elements.
      > 
      > What do you mean here - that these were not added because the attributes
      > are shared?
      
         The member 'attributes' of the HTTag describing each of them points to the 
      attr array, to which the member 'attributes' of some other tag(s) point (as I
      remember, it is gen_attr array) - and I was confused by the need of
      introducing the new array of attrs, start new  list of #define's, etc.. - ie
       I've done things that can be done easy/quickly. Sorry.
      
      > -- 
      > Larry W. Virden                 
      >  <*> O- "No one is what he seems."
      > Unless explicitly stated to the contrary, nothing in this posting should 
      > be construed as representing my employer's opinions.
      > 
      
       Best regards,
        -Vlad
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 08:49:15 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA23378
      	for ; Mon, 19 Apr 1999 08:49:14 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA17275; Mon, 19 Apr 1999 07:40:21 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904191239.IAA14454@shell.clark.net>
      Subject: Re: lynx-dev The whole CTRACE thing
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 08:39:52 -0400 (EDT)
      In-Reply-To:   from "John Bley " at Apr 19, 99 08:17:58 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 578
      Lines: 22
      
      > On Mon, 19 Apr 1999, Gisle Vanem wrote: 
      >  
      > > #define CTRACE(arg) do {              \ 
      > >                       if (TRACE)      \ 
      > >                          fprintf arg; \ 
      > >                     } while (0) 
      > >  
      > > However, this requires extra paranthesis: 
      > >  
      > >   CTRACE ((tfp, "foo")); 
      >  
      > Is this portable?  I was unaware the preprocessor could do that. 
      
      yes, but it causes some compilers and most versions of lint to spit
      out nasty messages.
        
      > John Bley - jbb6@acpub.duke.edu 
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Mon Apr 19 09:08:24 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA24128
      	for ; Mon, 19 Apr 1999 09:08:20 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA20671; Mon, 19 Apr 1999 07:58:52 -0500 (CDT)
      Message-ID: <5l+HqBAv9xG3Ewga@freeuk.net>
      Date: Mon, 19 Apr 1999 13:19:59 +0100
      To: lynx-dev@sig.net
      From: Don Adaway 
      Subject: Re: lynx-dev Lynx and downloading files
      References: 
       
      In-Reply-To: 
      MIME-Version: 1.0
      X-Mailer: Turnpike Integrated Version 4.02 U 
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 474
      Lines: 13
      
      In article , Doug
      Kaufman  writes
      
      >This sounds like a problem with your cp.exe program. Do you have it
      >in your PATH or in the same directory as lynx (assuming that is your
      >working directory).
      
      Many thanks for solving the problem.  Cp.exe was not in a directory in
      the path, but another program called cp (a copying program with a
      different syntax) was in the path. 
      
      -- 
      Don      chervil @ freeuk . com
      
      From owner-lynx-dev@sig.net  Mon Apr 19 09:42:28 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA25536
      	for ; Mon, 19 Apr 1999 09:42:26 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28085; Mon, 19 Apr 1999 08:26:54 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904191326.JAA25006@shell.clark.net>
      Subject: Re: lynx-dev removing strings used in CTRACE when configured without
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 09:26:51 -0400 (EDT)
      In-Reply-To:   from "Vlad Harchev " at Apr 16, 99 00:41:32 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1072
      Lines: 31
      
      > 
      > On Mon, 19 Apr 1999 dickey@clark.net wrote: 
      >  
      > > >   One of the solutions may be the following:  
      > > >  There is a standalone preprocessor distributed with gcc, it's called 'cccp'  
      > > > and it does support macros with variable number of args.   
      > >  
      > > no (I've already been there).  that also is gcc-specific, and changes in 
      > > subtle, incompatible ways as gcc evolves. 
      >  
      >   We can get a snapshot from the latest gcc/egcs version and use it forever,  
      > without changing. I have an imression, that it wasn't modified last 4 years.  
      > On the other hand, developers of lynx get the reliable and very powerful tool, 
      > that is thoroughly tested. IMO macros with varargs are useful not in CTRACE.  
      
      I said incompatible, I meant incompatible - I've been inside the gnu
      c preprocessor more than once because newer releases introduce features
      that the older one does not understand.  Not something that you can
      solve with a snapshot.
      
      >  
      > >[...]  
      >  
      >  Best regards, 
      >   -Vlad 
      
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Mon Apr 19 09:52:39 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA25946
      	for ; Mon, 19 Apr 1999 09:52:37 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA02218; Mon, 19 Apr 1999 08:39:33 -0500 (CDT)
      Date: Mon, 19 Apr 1999 09:38:39 -0400
      From: Webmaster Jim 
      To: lynx-dev@sig.net
      Subject: lynx-dev Win32 docs patch (was: Lynx and downloading files)
      Message-ID: <19990419093839.A25894@mail.bcpl.net>
      References:   <5l+HqBAv9xG3Ewga@freeuk.net>
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.1i
      In-Reply-To: <5l+HqBAv9xG3Ewga@freeuk.net>; from Don Adaway on Mon, Apr 19, 1999 at 01:19:59PM +0100
      X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2  WdUS{+X2e6mt${6._[/U%N~y"Br4L6Lm%S0XI8RRTs"'Dpz]#@hD@I`i@G[Q+'"  cKd3Acq&}J;,FhT"6d1[H=*<;o2?Z_RK&He4+Td%v3:47/5;A>0mBqsG-KB8l:\43FGDe;U
      X-Hack: cough, cough
      X-Mailer: Mutt 0.95.1i (1999-01-04)
      X-Operating-System: SunOS mail 5.5 Generic_103093-06 sun4d sparc SUNW,SPARCserver-1000
      X-Operating-System-Of-Choice: NetBSD (See www.netbsd.com for CDROMs)
      X-Organization: planet earth
      X-Signature: /jes
      X-Url: "jim's subdomain"
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2967
      Lines: 80
      
      On Mon, Apr 19, 1999 at 01:19:59PM +0100, Don Adaway wrote:
      > In article , Doug
      > Kaufman  writes
      > >This sounds like a problem with your cp.exe program. Do you have it
      > Many thanks for solving the problem.  Cp.exe was not in a directory in
      [ ... ]
      
      I noticed the INSTALLTION file did not mention lynx_save_space, which
      could be good to know for installing on Win32, so here's a doc patch:
      
      *** INSTALLATION.df     Tue Apr 13 05:39:16 1999
      --- INSTALLATION        Mon Apr 19 09:29:31 1999
      ***************
      *** 602,608 ****
            not just Lynx.
      
      
      ! IV. Compile instructions -- Win32 (Windows95/NT)
      
            The original Win32 port was built with Borland C++ 4.52, but later
            versions reportedly can be used.  Before compiling the Lynx sources, you
      --- 602,608 ----
            not just Lynx.
      
      
      ! IV. Compile instructions -- Win32 (Windows95/98/NT)
      
            The original Win32 port was built with Borland C++ 4.52, but later
            versions reportedly can be used.  Before compiling the Lynx sources, you
      ***************
      *** 849,855 ****
           used by Lynx.  This should be checked later along with reading lynx.cfg
           after you have installed Lynx.
      
      ! 2. Win32 (95/NT) and 386 DOS
           These ports cannot start before setting certain environment variables
      
           (adapted from "readme.txt" by Wayne Buttles and "readme.dos" by Doug Kaufman)
      --- 849,855 ----
           used by Lynx.  This should be checked later along with reading lynx.cfg
           after you have installed Lynx.
      
      ! 2. Win32 (95/98/NT) and 386 DOS
           These ports cannot start before setting certain environment variables
      
           (adapted from "readme.txt" by Wayne Buttles and "readme.dos" by Doug Kaufman)
      ***************
      *** 866,871 ****
      --- 866,872 ----
            TEMP or TMP  Bookmarks are kept here with no HOME.  Temp files here.
            USER         Set to your login name (optional)
            LYNX_CFG     Set to the full path and filename for lynx.cfg
      +     LYNX_SAVE_SPACE  The (modifiable) location for downloaded file storage.
      
            386 version only:
            WATTCP.CFG   Set to the full path for the WATTCP.CFG directory
      ***************
      *** 877,882 ****
      --- 878,884 ----
              set home=d:\win32
              set temp=d:\tmp
              set lynx_cfg=d:\win32\lynx.cfg
      +       set lynx_save_space=d:\download
              d:\win32\lynx.exe %1 %2 %3 %4 %5
      
            In lynx_386, a typical batch file might look like:
      
      FWIW, this diff can't do "-u": -(
      
      bash-2.01$ diff -u  INSTALLATION.df INSTALLATION
      diff: illegal option -- u
      Usage: diff [-bitw] [-c |-C Lines|-D String|-e|-f|-h|-n] File1 File2
             diff [-bilrstw] [-c |-C Lines|-e|-f|-h|-n] [-S File] Directory1 Directory2
      
      ------
      
      
      Marvin the Paranoid Android says:
      My capacity for happiness you could fit in a matchbox...
      (without taking the matches out first)
      
      From owner-lynx-dev@sig.net  Mon Apr 19 10:14:04 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA26736
      	for ; Mon, 19 Apr 1999 10:14:03 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA09916; Mon, 19 Apr 1999 09:02:33 -0500 (CDT)
      Date: Mon, 19 Apr 1999 09:02:29 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: lynx-dev ^Z and stty cols (was: screen widths)
      In-Reply-To: <19990416133050.A29828@netcom16.netcom.com>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1240
      Lines: 35
      
      On Fri, 16 Apr 1999, David Combs wrote:
      > I myself LOVE running on the internet with screen width set to
      > 132.  I find it MUCH easier to scan large amounts of written
      > material.
      > 
      > When I want to print-to-file something that I want to later
      > print on the laser-printer, I simply set cols to 79 (via
      > ^Z then doing it), then when I do fg, wonderful lynx 
      > realizes this change, and a ^R reformats the page, and
      > *that's* what I print-to-file.
      
      Actually, this doesn't work for me if lynx is compiled with
      ncurses.  It does work as described for a version compiled
      with slang.
      
      In general, resizing with the ncurses binary *does* work (with
      the limitations already discussed recently, i.e. ^R or similar
      is required), but doing it with `stty cols NN' while lynx is
      suspended does not.
      
      The reason is that in that situation the lynx process doesn't
      get a SIGWINCH signal; the linux kernel sends the signal only
      to the tty's foreground process group.  So the lynx code doesn't
      get the trigger to re-check the screen size.  The curses structures
      *do* get updated, so ncurses then has the new size, lynx itself
      continues to format assuming the old size, and things are out of
      synch.
      
      Solution:
         stty cols NN
         kill -WINCH %+
      
      
        Klaus
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 10:41:38 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA27531
      	for ; Mon, 19 Apr 1999 10:41:36 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA18865; Mon, 19 Apr 1999 09:28:44 -0500 (CDT)
      Date: Mon, 19 Apr 1999 09:28:40 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Re: http://www.slcc.edu/lynx/html/todo-list.html
      In-Reply-To: <19990418203232.A24425@mail.bcpl.net>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2747
      Lines: 59
      
      On Sun, 18 Apr 1999, Webmaster Jim wrote:
      > On Sun, Apr 18, 1999 at 08:34:02AM -0500, Klaus Weide wrote:
      > 
      > I'm the "maintainer" of this page, meaning I'm supposed to mark the
      > things as done or remove them when they get done. Direct suggestions or
      > diffs against the html would be good. New requests for things "to-do"
      > get added by others. As you can see, the page was last changed in Sep
      > 1998.
      
      > I don't follow the cookes development code closely, so I'm not qualified
      > to write an update for the TODO page. Can someone give me a short blurb?
      
      So my blurbs were too long for your purpose?  :)
      Here is the short version:
      
      > >      * (Suggested by Hiram W. Lester, Jr.) Something needs to be done so
      > >        that cookies can be accepted from all domains by default. This is
      > >        available as command line "-cookies"; also see the cfg file
      > > 
      > > There is now -accept_all_cookies and ACCEPT_ALL_COOKIES.  Note that
      > > the -cookies flag does NOT do this, the second sentence is wrong.
      > > (-cookies is an overall flag to turn accepting of cookies on or
      > > completely off.)
      
      IOW:  Done in 2.8.1 (-accept_all_cookies).   [delete mention of "-cookies"]
      
      > >      * (Suggested by Hiram W. Lester, Jr.) Status message for accepting
      > >        cookies even if there was an option to always allow all cookies.
      > >
      > > In general, cookies that are deemed acceptable without needing user
      > > confirmation are accepted quietly - a status message of each cookie
      > > would be just too annoying, especially if the user had already said
      > > he wanted such cookies.  But there *is* a message (duration MESSAGESECS)
      > >    'A'lways allowing from domain 'XXX.XX.XX'.
      > > the first time a cookie from a given domain is auto-accepted, *if*
      > > this happens just because of -accept_all_cookies or ACCEPT_ALL_COOKIES
      > > (as opposed to previous 'A'lways answer to a prompt, or presence of
      > > the domain in a COOKIE_ACCEPT_DOMAINS list or in a persistent cookie
      > > file).
      
      IOW: done as far as it makes sense.
      
      > >      * (Suggested by Rolf Puchtinger) Would it be possible to prompt
      > >        users for the option to save COOKIES with expiry dates longer than
      > >        "session" in a permanent file in the user's directory for
      > >        subsequent sessions?
      > > 
      > > Persistent cookies are implemented (but still marked "experimental").
      > > Cookies with a given expiration in the future are saved to the persistent
      > > cookie file on exit, if enabled.  This was broken in 2.8.1 though, it
      > > even saves cookies that should not be saved.  (But they would be
      > > discarded when the file is read the next time.)
      
      IOW: persistent cookie storage available ('experimental') since 2.8.1,
           improved in 2.8.2, but no prompting for it.
      
      
        Klaus
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 11:08:31 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA28598
      	for ; Mon, 19 Apr 1999 11:08:28 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA24654; Mon, 19 Apr 1999 09:45:35 -0500 (CDT)
      From: pg@sweng.stortek.com
      Message-id: <199904191444.IAA00612@sanitas>
      Subject: Re: lynx-dev The whole CTRACE thing
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 08:44:54 -0600 (MDT)
      In-Reply-To: <199904191239.IAA14454@shell.clark.net> from "dickey@clark.net" at Apr 19, 99 08:39:52 am
      X-Mailer: ELM [version 2.4 PL24]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 435
      Lines: 15
      
      In a recent note, dickey@clark.net said:
      
      > Date: Mon, 19 Apr 1999 08:39:52 -0400 (EDT)
      > 
      > > >   CTRACE ((tfp, "foo")); 
      > >  
      > > Is this portable?  I was unaware the preprocessor could do that. 
      > 
      > yes, but it causes some compilers and most versions of lint to spit
      > out nasty messages.
      >   
      I'm astonished -- this would seem to be most basic facility, to
      support parenthesized [sub-]expressions as arguments to macros.
      
      -- gil
      
      From owner-lynx-dev@sig.net  Mon Apr 19 11:35:00 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA29573
      	for ; Mon, 19 Apr 1999 11:34:59 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA06670; Mon, 19 Apr 1999 10:16:09 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904191516.LAA08555@shell.clark.net>
      Subject: Re: lynx-dev The whole CTRACE thing
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 11:16:04 -0400 (EDT)
      In-Reply-To: <199904191444.IAA00612@sanitas>  from "pg@sweng.stortek.com" at Apr 19, 99 08:44:54 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 620
      Lines: 24
      
      > 
      > In a recent note, dickey@clark.net said: 
      >  
      > > Date: Mon, 19 Apr 1999 08:39:52 -0400 (EDT) 
      > >  
      > > > >   CTRACE ((tfp, "foo"));  
      > > >   
      > > > Is this portable?  I was unaware the preprocessor could do that.  
      > >  
      > > yes, but it causes some compilers and most versions of lint to spit 
      > > out nasty messages. 
      > >    
      > I'm astonished -- this would seem to be most basic facility, to 
      > support parenthesized [sub-]expressions as arguments to macros. 
      
      not that.  the dangling constant expression on the 'while' loop.
        
      > -- gil 
      
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Mon Apr 19 11:58:52 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA30387
      	for ; Mon, 19 Apr 1999 11:58:50 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA17855; Mon, 19 Apr 1999 10:45:29 -0500 (CDT)
      Date: Mon, 19 Apr 1999 10:45:18 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with    SOURCE_CACHE!=NONE
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2032
      Lines: 41
      
      On Wed, 14 Apr 1999, Scott Bigham wrote:
      > On Wed, 14 Apr 1999, Leonid Pauzner wrote:
      [ .... ]
      > > More problems expected since we now reload documents
      > > out of mainloop() cyrcle.
      > 
      > Not so much outside of mainloop(); we're just tripping over things that
      > would normally get cleaned up behind getfile().  And yes, I do expect to
      > run into more of them... :-(
      
      Uhmm.  I've been following this only from the sidelines, but it reminds
      me of the discussions we had last November (see messages containing "cach"
      in the 1198 archive, including my long blurbs
        
        ).
      It seems the source caching is implemeted in a way I woudl have preferred
      to avoid: data flow separate from the normal getfile() chain, a new
      and very different way to determine freshness, and overall control
      concentrated in already-too-big mainloop().   The result is numerous
      tweaks for cases that were not considered at first, with more to come.
      
      Don't get me wrong, it's great that you have done something while I was
      only talking.  Still, if there is a way you can reconsider the place
      where this is basically controlled, to move it away from mainloop()
      tweaks, please do it...
      
      If the gimme-data part were sitting somewhere between getfile() and
      (current) HTLoadDocument, we'd get the benefits of all the various
      checks that are (especially) in getfile().  Granted, they seem not
      to be needed now, since we're only reloading a document that has
      been loaded and so must have already been checked.  But relying on
      this makes it much more difficult to expand the reach of the source
      cache later (should we want to use caching for not-already-loaded
      documents), or to handle properly the case where the checks done
      in getfile() depend on settings that can change at runtime (and
      I understand that may be the case now, with the edit-lynx.cfg
      changes).  Basically, part or most of getfile() [and others?]
      would have to be duplicated.
      
         Klaus
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 12:14:53 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA30980
      	for ; Mon, 19 Apr 1999 12:14:52 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA24498; Mon, 19 Apr 1999 11:03:25 -0500 (CDT)
      To: lynx-dev@sig.net
      References: <19990419093839.A25894@mail.bcpl.net>
          
          
          <5l+HqBAv9xG3Ewga@freeuk.net>
      Message-Id: 
      From: "Leonid Pauzner" 
      Date: Mon, 19 Apr 1999 19:58:41 +0400 (MSD)
      X-Mailer: dMail [Demos Mail for DOS v2.07b]
      Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files)
      MIME-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 905
      Lines: 24
      
      19-Apr-99 09:38 Webmaster Jim wrote:
      > On Mon, Apr 19, 1999 at 01:19:59PM +0100, Don Adaway wrote:
      >> In article , Doug
      >> Kaufman  writes
      >> >This sounds like a problem with your cp.exe program. Do you have it
      >> Many thanks for solving the problem.  Cp.exe was not in a directory in
      > [ ... ]
      
      IMHO we should check the existance of cp.exe and mv.exe at DOSPATH platforms
      and force HTAlert error when these executables apparently lost (LYCopyFile).
      What does status codes for
              code = LYSystem(the_command)
      look like?
      
      
      > I noticed the INSTALLTION file did not mention lynx_save_space, which
      > could be good to know for installing on Win32, so here's a doc patch:
      
      > *** INSTALLATION.df     Tue Apr 13 05:39:16 1999
      > --- INSTALLATION        Mon Apr 19 09:29:31 1999
      > ***************
      > *** 602,608 ****
      >       not just Lynx.
      
      
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 12:19:08 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA31024
      	for ; Mon, 19 Apr 1999 12:19:07 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA24515; Mon, 19 Apr 1999 11:03:27 -0500 (CDT)
      To: lynx-dev@sig.net
      References: 
      Message-Id: 
      From: "Leonid Pauzner" 
      Date: Mon, 19 Apr 1999 19:41:03 +0400 (MSD)
      X-Mailer: dMail [Demos Mail for DOS v2.07b]
      Subject: Re: strange HTTP/HTCheckForInterrupt() bug lynx-dev
      MIME-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1969
      Lines: 55
      
      19-Apr-99 05:55 Klaus Weide wrote:
      > On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      >> > Today I got the same strange buged behaviour, now with dev22.
      >> > Perhaps I press "z" in a "bad" moment (during DNS search or a little later).
      >> > ^Z spawn me to a shell and "fg" return me back without visible problems.
      >>
      >>
      >> Looking into trace log more carefully I found out that we use two DNS calls:
      >> first to resolve anchor and the second for making TCP connection.
      
      > Only if you don't give a complete URL, of course.
      
      >> In case of local proxy we have the second DNS call for proxy address.
      >> Probably, interrupting the first call we crash the second by some means?
      
      > This is still a mystery to me.  It would help if the "Exiting with interrupt"
      > message mentioned the process id.
      
      
      >   .......
      >> >  3203  p0 S    0:00 -bash
      >> >  3215  p0 T    0:03 lynx
      >> >  7156  p0 Z    0:00 (lynx )
      >> >  7261  p0 R    0:00 ps -a
      >> > [pauzner@mccme pauzner]$
      
      > This doesn't seem to have anything to do with the trace you showed,
      > the pid of the zombie process is completely different.?
      
      Sorry, this zimbie process info from the real crash,
      and trace log was from a succesful resolve (I got crash very seldom
      so I have no trace from that situation, sorry for confusion).
      
      I was just surprised why
      >> LYGetHostByName: Resolved name to a hostent.
      message was 3 times - one for user-defined URL and *two* for proxy address.
      Does there were two gethostbyname calls for proxy?
      >  ------------------------
      
      > Those traces are harder to understand because large sections
      > are duplicated, both the child and parent write the same messages
      > already buffered when the fork() occurs to the trace log.
      
      > As I said in ,
      > try inserting a
      
      >            CTRACE_FLUSH(tfp);
      ok.
      
      > before the second '#ifdef NSL_FORK' in LYGetHostByName().
      > But I don't know that this has anything to do with the problem.
      
      >    Klaus
      
      
      
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 12:58:36 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA32396
      	for ; Mon, 19 Apr 1999 12:58:35 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA10191; Mon, 19 Apr 1999 11:46:32 -0500 (CDT)
      Date: Mon, 19 Apr 1999 11:46:27 -0500 (CDT)
      From: Klaus Weide 
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev (patch) - show list of statusline messages from history page
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 3478
      Lines: 76
      
      On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      
      > * HTAlert, HTUserMsg and HTInfoMsg statusline messages now stored in a cyrcled
      >   buffer and accessible from the History Page as LYNXMESSAGES:/ link.
      >   This allow us to decrease the messages delay in lynx.cfg when we feel
      >   messages too annoying, but have a nice history list for diagnostic purposes.
      >   Idea belongs to Bela Lubkin. Buffer of 40 lines long. - LP
      
      I hope you don't mind if I comment on another piece of code I haven't
      tried yet... :)
      
      1. There are basically thre ways to generate pseudo-documents (auxiliary
      screens, or whatever they should be called):
      A. Generate HTML in textual form, write it to temp file, then read in
         temp file and treat as text/html.  Involves SGML.c with all its gory
         details.
         Examples: many, you must have used one :)
      B. Generate HTML in textual form, pass directly to (normally) SGML.c
         (mostly via HTStreamStack).
         Examples: LYHandleCookies(), LYLoadKeymap()
      C. Generate HTML structures (text, elements, attributes) on the fly, pass
         directly to HTStructured object (i.e. HTML.c functions), bypassing
         SGML.c.
         Examples: files in WWW subdirectory (look for .c files having
           #define PUTC(c) (*targetClass.put_character)(target, c)
         or similar)
      
      Disadvantages for A: overhead of creating/writing/reading file, file
      space needed.  (May be good for things that don't have to be recreated
      every time).
      
      Disadvantages for A and B: Unnecessary tranformation of
           content -> flat text form
      and back again.  That includes also escaping characters that need it.
      (Your code seems to be wrong for any messages that contain '&' and '<'
      characters, you'd have to escape those for using method A.)
      
      Otoh, possible disadvantages for C:
      - A brief look didn't reveal any source file in the src directory
       using it, only under WWW.  But these days the separation between
      those two directories seems to have broken pretty much anyway (files
      under WWW can include heder files from the src directory, which
      used to not be the case), so that shouldn't be significant.
      - Character translation may not work right, maybe (I don't know
      for sure either way).  Well in this cases the only variable text
      that may need translation is in text, not in attributes, so one
      could set the "document charset" up with a META if necessary
      (which should work with all three methods) - if that should be
      needed for localized messages.
      
      So my wish, as you can guess by now, is that this should be done
      using method C.  Especially for *this* kind of thing - if one
      wants to see messages that ralate to disk access problems, like
      some directory set wrong or disk full, one may not be able to
      see them because the temp file can not be created.
      
      >      BeginInternalPage(fp0, HISTORY_PAGE_TITLE, HISTORY_PAGE_HELP);
      > 
      > +    fprintf(fp0, "
      [%s]\n", > + gettext("Your recent statusline messages")); > + This is the very first link on the History Page. I'd prefer it to be at the bottom, otherwise things like ^H, 'd' become a bit more inconvenient. Actually one shouldn't have to go to the history page in order do see past messages. (And among other things, it won't work if the history file cannot be written, see above.) The normal approach would be to sacrifice yet another key, not that I want to recommend it. But I guess 'g LYNXMESSAGES:' should work. (Good candidate for a jump file shortcut...) Klaus From owner-lynx-dev@sig.net Mon Apr 19 13:01:14 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA32488 for ; Mon, 19 Apr 1999 13:01:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA10797; Mon, 19 Apr 1999 11:48:18 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 20:46:30 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3076 Lines: 62 19-Apr-99 10:45 Klaus Weide wrote: > On Wed, 14 Apr 1999, Scott Bigham wrote: >> On Wed, 14 Apr 1999, Leonid Pauzner wrote: > [ .... ] >> > More problems expected since we now reload documents >> > out of mainloop() cyrcle. >> >> Not so much outside of mainloop(); we're just tripping over things that >> would normally get cleaned up behind getfile(). And yes, I do expect to >> run into more of them... :-( > Uhmm. I've been following this only from the sidelines, but it reminds > me of the discussions we had last November (see messages containing "cach" > in the 1198 archive, including my long blurbs > > ). > It seems the source caching is implemeted in a way I woudl have preferred > to avoid: data flow separate from the normal getfile() chain, a new > and very different way to determine freshness, and overall control Yes, it was implemented in a way you were preferred to avoid. But this may have a good sides also: current mainloop/getfile stuff already-too-big and hardly maintainable. Now, when source_cache implemented by someone else I have fixed most mainloop problems in an elegant any clear way (submitted to Tom privately, will be available in dev23 soon). This actually *simpify* mainloop since we got a chance to look there from the other point of view (correct display partial logic in particular). In the other case we would fall into all kind of warnings with the replay from POST resubmit etc. Current caching mechanism hardly maintainable either. I have not figured out yet how we can implement http caching we discussed in November, but probably it is possible rather easy. We may try an equivalent of HText_select() somehow and go that way, probably just put HTreparse_document() in HText_select() with the appropriate checks. Isn't it? > concentrated in already-too-big mainloop(). The result is numerous > tweaks for cases that were not considered at first, with more to come. > Don't get me wrong, it's great that you have done something while I was > only talking. Still, if there is a way you can reconsider the place > where this is basically controlled, to move it away from mainloop() > tweaks, please do it... > If the gimme-data part were sitting somewhere between getfile() and > (current) HTLoadDocument, we'd get the benefits of all the various > checks that are (especially) in getfile(). Granted, they seem not > to be needed now, since we're only reloading a document that has > been loaded and so must have already been checked. But relying on > this makes it much more difficult to expand the reach of the source > cache later (should we want to use caching for not-already-loaded > documents), or to handle properly the case where the checks done > in getfile() depend on settings that can change at runtime (and > I understand that may be the case now, with the edit-lynx.cfg > changes). Basically, part or most of getfile() [and others?] > would have to be duplicated. > Klaus From owner-lynx-dev@sig.net Mon Apr 19 13:33:51 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA00731 for ; Mon, 19 Apr 1999 13:33:50 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA16506; Mon, 19 Apr 1999 12:05:11 -0500 (CDT) Date: Mon, 19 Apr 1999 13:01:06 -0400 (EDT) From: John Bley To: lynx-dev@sig.net Subject: Re: lynx-dev The whole CTRACE thing In-Reply-To: <199904191516.LAA08555@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 784 Lines: 18 Lots of people wrote: > > > > > CTRACE ((tfp, "foo")); > > > > Is this portable? I was unaware the preprocessor could do that. > > > yes, but it causes some compilers and most versions of lint to spit > > > out nasty messages. > > I'm astonished -- this would seem to be most basic facility, to > > support parenthesized [sub-]expressions as arguments to macros. > not that. the dangling constant expression on the 'while' loop. Ah. If the () preprocessor stuff is portable though, I think a good workaround could exist. I'll think about it and test some stuff out. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall From owner-lynx-dev@sig.net Mon Apr 19 13:36:26 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id NAA00963 for ; Mon, 19 Apr 1999 13:36:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA22524; Mon, 19 Apr 1999 12:22:20 -0500 (CDT) Date: Mon, 19 Apr 1999 12:22:04 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev lynx and ncurses and gpm In-Reply-To: <199904171244.IAA10181@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 5592 Lines: 125 On Sat, 17 Apr 1999 dickey@clark.net wrote: [kw:] > > -- Question 1: > > Is this common for all Linux distributions? Are thare any Linux > > distributions with an ncurses package that has gpm support enabled? > > I don't think there are (it's not a technical issue though) Probably because ncurses is a very basic package, it shouldn't depend on many other packages. It would have to depend on a gpm package unless gpm code was statically linked in. > > gpm_connect.eventMask = GPM_DOWN|GPM_UP; > > gpm_connect.defaultMask = ~(gpm_connect.eventMask|GPM_HARD); > > gpm_connect.minMod = 0; > > gpm_connect.maxMod = ~((1< > > > recompiled ncurses, and got a lynx with mouse support under gpm that > > works. At least brief testing didn't shown problems that were specific > > to the gpm environment, only those that are also there in an xterm. > > I'll try this out today - the only caveats I can think of offhand are > whether the KG_ macros are defined in all versions of Linux. But I can > certainly make this configuration available somehow. I looked more into why the defaultMask change is necessary; the gpm (1.17.6) server side do_client() function has some strange logic. (event->type is filtered through GPM_BARE_EVENTS for comparison with eventMask but not for comparison with eventMask). Actually the defaultMask set by ncurses should probably be gpm_connect.defaultMask = GPM_BARE_EVENTS(~gpm_connect.eventMask); instead of the above, otherwise the test in gpm's do_client() will give wrong results becuae of the additionl non-bare bits. (this is untested) About KG_SHIFT, it is used in the gpm code itself (and it is gotten the same way, by including linux/keyboard.h, without fallback definitions). I guess that means it's available on all linux versions where gpm can be used. I don't know about KG_SHIFTL and KG_SHIFTR though, didn't see them used. > > -- Question 3: > > Tom, could these changes be incorporated into ncurses? > > (If there are no apllication for which the previous behavior was > > right, as I suspect, this should go into the to-be-released-soon > > ncurses.) > > Possibly - I'm only making bug-fix changes to the beta right now. > If it looks like a low-impact change, I can add it. At least the defaultMask change should be regarded as a bug fix, or a necessary workaround for a bug in gpm. > > -- Question 4: > > How are the chances of getting this kind of increased flexibility > > into the ncurses distribution? > > (Also, are there significant security issues with allowing > > control by an env variable? - Note it can hardly be worse than > > what there is currently.) > > That's something that I'll have to think about (I would suppose that going > the other way - to force paste-behavior - would be less secure). The less bits set in defaultMask, the less chance/risk for fallback to pasting. In that sence taking bits out is a security improvement... > > ------------------- > > > > Various other remarks steeming from recompiling-ncurses experience: > > > > 1. I added another model to the ncurses configuration, to get shared libs > > with debugging: they will be generated after > > ./configure --with-debugshared > > as lib*_g.so[.M[.N]] (in case of linux, at least). The changes are > > mostly straightforward, just a combination of --with-shared and > > --with-debug settings. Tom, are you interested in patches? > I do this by > CFLAGS=-g configure --with-shared Yes, that looks much simpler. :) > (I'm not entirely happy with the multiple models, but they work) > > > 2. What is --with-install-prefix supposed to do, and is it implemented > > correctly by configure? > > I used it as > > ./configure --prefix=/usr/local --exec-prefix=/usr/local \ > > --with-install-prefix=/usr/local/stow/ncurses-5.0-beta1-990403 ... > > > > and assumed that compiled-in paths would be configured to reference > > locations (for terminfo directory etc.) under /usr/local/, but > > actual installation on 'make install' would take place under > > the longer path (for example, terminfo files under > > /usr/local/stow/ncurses-5.0-beta1-990403/share/terminfo). > > But what I found was that actual installation actually takes place > > under /usr/local/stow/ncurses-5.0-beta1-990403/usr/local/, > > ^^^^^^^^^^ > > is that as intended? It seems rather useless. > > yes - it's so someone can build and install under the install-prefix, > then tar that tree up and plop it down on user's machines under the > regular prefix. Ok, thanks. > > (I am playing around with the GNU "stow" program, which assumes > > packages that are supposed to appear under /usr/local are actuall > > installed under /usr/local/stow/ and then maps all > > files into their expected locations as symlinks.) > > some of the paths in ncurses are compiled-in (does stow edit binary files?). No, it just creates (or removes) symlinks, and possible creates/removes directories under /usr/local as necessary. But I didn't find any compiled-in paths that were wrong (they seem to use --prefix/--exec-prefix/etc. as theu should, not the install-prefix). I got the install into the desired 'real' place by making first a bogus /usr/local/stow/ncurses-5.0-beta1-990403/usr/local -> .. symlink. Klaus From owner-lynx-dev@sig.net Mon Apr 19 14:00:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id OAA01676 for ; Mon, 19 Apr 1999 14:00:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA01295; Mon, 19 Apr 1999 12:48:04 -0500 (CDT) Date: Fri, 16 Apr 1999 05:52:08 +0500 (SAMST) From: Vlad Harchev X-Sender: hvv@localhost.localdomain To: lynx-dev@sig.net Subject: Re: lynx-dev removing strings used in CTRACE when configured without In-Reply-To: <199904191326.JAA25006@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 782 Lines: 22 On Mon, 19 Apr 1999 dickey@clark.net wrote: >[...] > I said incompatible, I meant incompatible - I've been inside the gnu > c preprocessor more than once because newer releases introduce features > that the older one does not understand. Not something that you can > solve with a snapshot. As I understood you, the most thing that confuse you is backward compatiblity? IMO lynx sources use cpp very carefully and are pessimistic about the ANSI compliance of cpp, so, IMO, the problems won't arise. BTW, I explored cccp today. IMO it won't be easy to hack it so it that it can be compiled standalone (and be compact) - probably separate subdir, Makefile.in will be reqired, and I afraid, this will be about (optimistically) 600 KB... > >[...] > Best regards, -Vlad From owner-lynx-dev@sig.net Mon Apr 19 15:20:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA04426 for ; Mon, 19 Apr 1999 15:20:35 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA26733; Mon, 19 Apr 1999 13:58:31 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 22:54:08 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1502 Lines: 35 More on this: 19-Apr-99 10:45 Klaus Weide wrote: > If the gimme-data part were sitting somewhere between getfile() and > (current) HTLoadDocument, we'd get the benefits of all the various > checks that are (especially) in getfile(). Granted, they seem not > to be needed now, since we're only reloading a document that has > been loaded and so must have already been checked. But relying on > this makes it much more difficult to expand the reach of the source > cache later (should we want to use caching for not-already-loaded > documents), or to handle properly the case where the checks done > in getfile() depend on settings that can change at runtime (and > I understand that may be the case now, with the edit-lynx.cfg > changes). Basically, part or most of getfile() [and others?] > would have to be duplicated. Not duplicated, they are bypassed! It is like HText_pageDispaly() calls used for partial mode. Now it is HTreparse_document() used in a small "refresh_screen" mainloop cycle when possible, instead of big "force_load" mainloop/getfile cyrcle. We also can use this function at nearly any stage of the 'big' cycle, preferrably in HTLoadDocument(), along with checking around LY_force_no_cache and LY_override_no_cache, and acting on the exit from HTLoadHTTP() for certain status codes (perhaps "Not Modified"?). And I already use it in getfile/postoptions 'middle' cycle. This probably not very logical but there are only a few instances so easily maintained. > Klaus From owner-lynx-dev@sig.net Mon Apr 19 15:52:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id PAA05405 for ; Mon, 19 Apr 1999 15:52:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA11973; Mon, 19 Apr 1999 14:39:06 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Mon, 19 Apr 1999 23:29:29 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev (patch) - show list of statusline messages from history page MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4318 Lines: 94 19-Apr-99 11:46 Klaus Weide wrote: > On Mon, 19 Apr 1999, Leonid Pauzner wrote: >> * HTAlert, HTUserMsg and HTInfoMsg statusline messages now stored in a cyrcled >> buffer and accessible from the History Page as LYNXMESSAGES:/ link. >> This allow us to decrease the messages delay in lynx.cfg when we feel >> messages too annoying, but have a nice history list for diagnostic purposes. >> Idea belongs to Bela Lubkin. Buffer of 40 lines long. - LP > I hope you don't mind if I comment on another piece of code I haven't > tried yet... :) > 1. There are basically thre ways to generate pseudo-documents (auxiliary > screens, or whatever they should be called): > A. Generate HTML in textual form, write it to temp file, then read in > temp file and treat as text/html. Involves SGML.c with all its gory > details. > Examples: many, you must have used one :) > B. Generate HTML in textual form, pass directly to (normally) SGML.c > (mostly via HTStreamStack). > Examples: LYHandleCookies(), LYLoadKeymap() > C. Generate HTML structures (text, elements, attributes) on the fly, pass > directly to HTStructured object (i.e. HTML.c functions), bypassing > SGML.c. > Examples: files in WWW subdirectory (look for .c files having > #define PUTC(c) (*targetClass.put_character)(target, c) > or similar) Yes, I thought on it before. Method C used for LYNXIMGMAP and directory listings - I was fixing both of them:) This looks preferrable for all pages except static (like compile-time settings, or lynx.cfg page), perhaps no additional memory penalties may be even a benefits. And this require registering such pages as new protocols, a little bit complicated then temp files. > Disadvantages for A: overhead of creating/writing/reading file, file > space needed. (May be good for things that don't have to be recreated > every time). > Disadvantages for A and B: Unnecessary tranformation of > content -> flat text form > and back again. That includes also escaping characters that need it. > (Your code seems to be wrong for any messages that contain '&' and '<' > characters, you'd have to escape those for using method A.) Oops... yes. No problem if C. > Otoh, possible disadvantages for C: > - A brief look didn't reveal any source file in the src directory > using it, only under WWW. But these days the separation between > those two directories seems to have broken pretty much anyway (files > under WWW can include heder files from the src directory, which > used to not be the case), so that shouldn't be significant. > - Character translation may not work right, maybe (I don't know > for sure either way). Well in this cases the only variable text > that may need translation is in text, not in attributes, so one > could set the "document charset" up with a META if necessary > (which should work with all three methods) - if that should be > needed for localized messages. > So my wish, as you can guess by now, is that this should be done > using method C. Especially for *this* kind of thing - if one correct. > wants to see messages that ralate to disk access problems, like > some directory set wrong or disk full, one may not be able to > see them because the temp file can not be created. >> BeginInternalPage(fp0, HISTORY_PAGE_TITLE, HISTORY_PAGE_HELP); >> >> + fprintf(fp0, "[%s]\n", >> + gettext("Your recent statusline messages")); >> + > This is the very first link on the History Page. I'd prefer it to > be at the bottom, otherwise things like ^H, 'd' become a bit more > inconvenient. I would disagree, it is a proper place - a real history of events... Probably we should set a default link at position #2 (just from memory, there was certain problems this that last fall, probably another look will be better). > Actually one shouldn't have to go to the history page in order do see > past messages. (And among other things, it won't work if the history > file cannot be written, see above.) The normal approach would be to > sacrifice yet another key, not that I want to recommend it. But I > guess 'g LYNXMESSAGES:' should work. (Good candidate for a jump > file shortcut...) I am not good to remember all that keys... > Klaus From owner-lynx-dev@sig.net Mon Apr 19 16:14:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id QAA06139 for ; Mon, 19 Apr 1999 16:14:47 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA17377; Mon, 19 Apr 1999 14:54:17 -0500 (CDT) Date: Mon, 19 Apr 1999 15:53:57 -0400 (EDT) From: Scott Bigham X-Sender: dsb@rover To: lynx-dev@sig.net Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 823 Lines: 18 On Mon, 19 Apr 1999, Klaus Weide wrote: > If the gimme-data part were sitting somewhere between getfile() and > (current) HTLoadDocument, we'd get the benefits of all the various > checks that are (especially) in getfile(). Well, the problem there is that the only place I could find where I could get at the actual incoming data was about five layers below HTLoadDocument(), at the HTStream level. Up at the getfile() level, AFAICT, you just stick a document address in one end and get an HText out the other. Now, I suppose if getfile() could be taught to check for a cached source, it could call HTreparse_document() at that level instead of HTLoadDocument(); but I'm still putting my brain back together from my last attempt to decipher getfile(), :-} so I doubt I'll be able to pull that one off. -sbigham From owner-lynx-dev@sig.net Mon Apr 19 17:51:43 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA09635 for ; Mon, 19 Apr 1999 17:51:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA24909; Mon, 19 Apr 1999 16:36:17 -0500 (CDT) Message-Id: <199904191846.NAA22441@roadrunner.sig.net> Alternate-recipient: prohibited Date: Mon, 19 Apr 1999 18:46:29 +0000 (GMT) From: "Cynthia Griffiths (516)233-6839" Subject: lynx-dev Lynx Question To: lynx-dev@sig.net MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Posting-date: Mon, 19 Apr 1999 18:46:30 +0000 (GMT) Importance: normal Sensitivity: Company-Confidential A1-type: MAIL Hop-count: 2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1884 Lines: 58 I am using Lynx 2.4-FM on an digital alpha running VMS When I run the following code: Link page
      I get the following error: terminal = vt_400 series data transfer complete BUT I'm am in a "hung" condition and must perform a cntrl Y to return to a Lynx session (the webmaildba.pl perl script never gets called) If I change the from "hidden" to "text" in the above code I don't hang but I default to interactive lynx and the action address never is gotten to. Thanks for any help, Cindi ***** In case you're wondering what I'm attempting to do. The form outlined above presently calls a Perls script that sends mail. It works on an NT box. I am attempting to write DCL (VMS code) to check if the number of files is greater than 3 in a directory, if so I want to notify the "on call person" via email. I wrote the DCL command and was hoping to use Lynx to help me access a netscape browser so that I can submit my form to the Perl script to send mail. I was hoping to do all this as background procedures. (Thanks Again) ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From owner-lynx-dev@sig.net Mon Apr 19 18:03:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id SAA10202 for ; Mon, 19 Apr 1999 18:02:59 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA01660; Mon, 19 Apr 1999 16:54:42 -0500 (CDT) Message-ID: <371BA780.4A0E5EBC@lanl.gov> Date: Mon, 19 Apr 1999 16:00:32 -0600 From: Craig Idler X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev http header info returned Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 308 Lines: 10 Is there an option that will display the returned http header info too? I'm using the -source option in line mode to get the text, but the http header would be very usefull info also. I know that I can use basic telnet to accomplish this, but I need SSL support so I'm doing this with Lynx. Thanks, Craig From owner-lynx-dev@sig.net Mon Apr 19 19:13:35 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA12346 for ; Mon, 19 Apr 1999 19:13:34 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA22492; Mon, 19 Apr 1999 18:01:48 -0500 (CDT) Date: Mon, 19 Apr 1999 19:01:53 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <199904181914.PAA28820@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2447 Lines: 68 On Sun, 18 Apr 1999 dickey@clark.net wrote: > > I've seen many messages here saying that VT100 doesn'support color. > > That's true for real VT100 terminals, not for VT100/VT102 emulators, and > > I don't believe that many people are using real VT100 terminals > > nowadays. Most VT100 emulators I know support color. Last year I > > discussed that subject with Thomas and others in > > comp.infosystems.www.browsers.misc. > > -- I still disagree though You may disagree but the fact is that most VT100 terminal emulators support color. > > compiling Lynx with Slang. Slang doesn't assume that VT100 doesn't > > support colors and displays colors when you use the "-color" option in > > the command > > slang uses one particular combination of assumptions about color terminals, > which works with about half of the "ANSI" color terminals that I'm aware of. Then Slang is smart enough to know that most VT100 terminal emulators support color. > > termcap > > ------- > > :Co#8:pa#64:op=\E[37;40m:AF=\E[3%dm:AB=\E[4%dm: > > this won't work for the configuration that I use at work, since I use > a white background there. I believe that that black-on-white thing appeared with Windows... SVR4 curses and ncurses use COLOR_BLACK as background default for all terminals. Anyway, If you need black-on-white as default, you can use "op=\E[30;47m". > (my home machine's screen is higher resolution, and I use black background > except when running lynx - color contrasts aren't good enough). Try putting these colors in your lynx.cfg: COLOR:0:lightgray:black COLOR:1:cyan:black COLOR:2:brightcyan:black COLOR:3:magenta:black COLOR:4:green:black COLOR:5:brightblue:black COLOR:6:yellow:black COLOR:7:brightmagenta:black > > terminfo > > -------- > > colors#8, pairs#64, op=\E[37;40m, setaf=\E[3%p1%dm, setab=\E[4%p1%dm, > > same problem - works for you, perhaps not everyone I don't pretend that it'll work for everyone but it works with most VT100 terminal emulators I know. People often send me messages thanking me for allowing them to use colors in Lynx. Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Mon Apr 19 19:35:48 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA13062 for ; Mon, 19 Apr 1999 19:35:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA01297; Mon, 19 Apr 1999 18:23:53 -0500 (CDT) From: mattack@area.com Date: Mon, 19 Apr 1999 16:23:49 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 984 Lines: 23 On Mon, 19 Apr 1999, Ismael Cordeiro wrote: >On Sun, 18 Apr 1999 dickey@clark.net wrote: > >> > I've seen many messages here saying that VT100 doesn'support color. >> > That's true for real VT100 terminals, not for VT100/VT102 emulators, and >> > I don't believe that many people are using real VT100 terminals >> > nowadays. Most VT100 emulators I know support color. Last year I >> > discussed that subject with Thomas and others in >> > comp.infosystems.www.browsers.misc. >> >> -- I still disagree though > >You may disagree but the fact is that most VT100 terminal emulators support >color. But this is a contradiction in terms. If VT100 does not support color, which others have stated is a fact, then a "vt100 emulator" cannot support color, because it is no longer a vt100 emulator. It could be called a "vt100-ish emulator that also supports color", but by definition a vt100 emulator cannot support color if it is true that actual vt100 terminals do not display color. From owner-lynx-dev@sig.net Mon Apr 19 20:16:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA14385 for ; Mon, 19 Apr 1999 20:16:20 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA16336; Mon, 19 Apr 1999 19:02:51 -0500 (CDT) From: dickey@clark.net Message-Id: <199904200001.UAA29356@shell.clark.net> Subject: Re: lynx-dev Lynx, colors and VT100 To: lynx-dev@sig.net Date: Mon, 19 Apr 1999 20:01:32 -0400 (EDT) In-Reply-To: from "mattack@area.com" at Apr 19, 99 04:23:49 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 715 Lines: 19 > >You may disagree but the fact is that most VT100 terminal emulators support > >color. > > But this is a contradiction in terms. yes (I don't think I should argue, since people are likely to forget this) > If VT100 does not support color, which others have stated is a fact, then > a "vt100 emulator" cannot support color, because it is no longer a vt100 > emulator. It could be called a "vt100-ish emulator that also supports color", > but by definition a vt100 emulator cannot support color if it is true that > actual vt100 terminals do not display color. IC's point is that a vt100 is whatever he chooses to call a vt100. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Apr 19 20:28:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA14756 for ; Mon, 19 Apr 1999 20:28:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA21048; Mon, 19 Apr 1999 19:17:32 -0500 (CDT) From: Hans Georg Schaathun Date: Tue, 20 Apr 1999 00:31:32 +0200 (MET DST) Message-Id: <199904192231.AAA17553@tiur.ii.uib.no> To: lynx-dev@sig.net Subject: lynx-dev (stud.oecon. stud.scient.) http://www.ii.uib.no/~georg/ `My belief is my own, and any resemblance to any religion, real or imaginary, is purely coincidential.' From owner-lynx-dev@sig.net Mon Apr 19 21:20:59 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA16527 for ; Mon, 19 Apr 1999 21:20:58 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA05022; Mon, 19 Apr 1999 20:13:51 -0500 (CDT) Date: Tue, 20 Apr 1999 10:25:30 +0900 (JST) From: Henry Nelson Message-Id: <199904200125.KAA27035@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1097 Lines: 24 > as i said originally, i'm not going to pursue an argument > about using
      or
       to lay out documentation neatly;
      
      Shucks!  This is exactly where the problem lies, IMO, i.e., some
      consideration of what is "desirable" and "unacceptable" HTML.
      
      >      1  argues that the long-standing Lynx layout in fact has a pattern,
      >     if only people notice it (documentation would help here too).
      
      Lynx, almost out of necessity, makes decisions about style.  Whether
      users recognize it or not, Fote and others spent considerable time
      thinking about and implementing a style that would be informative and
      functional, pleasing to the appearance and not distractive to a wide
      range of terminals, and to specific NEEDS of certain users.
      
      >     in the absence of style-sheets in the near future,
      >     i'ld say L/R columns in the screen display should be configurable
      >     via an Option, but of course someone has to do the coding (BL?).
      
      I would like to express the opinion, no.  Users have been told
      exactly where to go to change the code; they should be their own
      coders in this case.
      
      __Henry
      
      From owner-lynx-dev@sig.net  Mon Apr 19 22:18:35 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA18221
      	for ; Mon, 19 Apr 1999 22:18:33 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA18275; Mon, 19 Apr 1999 21:09:58 -0500 (CDT)
      Date: Tue, 20 Apr 1999 11:21:36 +0900 (JST)
      From: Henry Nelson 
      Message-Id: <199904200221.LAA27257@ibr1.irm.nara.kindai.ac.jp>
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes)
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2318
      Lines: 51
      
      > > ! Step 1. (define compile-time variables)
      [...]
      > > !   this file, and the changes should be straight forward.  If you compile
      > > !   using autoconfigure, you should set defines with option switches and not
      > > !   edit userdefs.h directly.
      > 
      > That last sentence reads as if editing userdefs.h was completely unnecessary
      > and not recommended at all if configure is used.  That's of course not true.
      > There are only a handful of userdefs.h settings that can be preempted with
      
      Thanks, Klaus, for the input.  Tom, please apply Doug's and Jim's patches to
      INSTALLATION first.  This Saturday I should be able to respond to comments
      and send in a revision.
      
      Tom, and others, could you comment on this "editing of userdefs.h" change.
      It was my impression that there WAS no longer a need to edit userdefs.h, and
      that some of you never do anymore.  Should I leave it the way it is, or
      should I make the change, but emphasize that if you don't edit userdefs.h,
      you absolutely must edit lynx.cfg?
      
      > It also contradicts what userdefs.h says.   More than two thirds of it are
      [...]
      > people take it seriously.  But some options that really need to be reviewed
      > by the installer (like GLOBAL_MAILCAP) are grouped together in section 1.)
      
      I would be willing to revise userdefs.h if that is what autoconfers would
      prefer.  If nothing else, perhaps I could revise INSTALLATION to point to
      specific section(s) of userdefs.h.
      
      > Henry didn't change it, but I noticed that Step 3 is giving wrong advice;
      > it would be more correct with the 5 words inserted below.
      > 
      > > ! Step 3. (You may skip this step if you use only English and are not interested
      > > !     in any special characters, or if your display and local files will all use
      >                                                                      ^
      >                                                 ...and all visited Web pages...
      > 
      > > !     the ISO-8859-1 "ISO Latin 1" Western European character set.) People who
      
      Would it work to be more general rather than define all situations, i.e.,
      
      "You may skip this step if you use only English, are not interested
      in any special characters, and will only view documents in the ISO-8859-1
      (ISO Latin 1) Western European character set."
      
      or even more simply,
      
      "You may skip this step if you use only English."
      
      
      __Henry
      
      From owner-lynx-dev@sig.net  Mon Apr 19 22:19:18 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA18233
      	for ; Mon, 19 Apr 1999 22:19:17 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA19140; Mon, 19 Apr 1999 21:13:14 -0500 (CDT)
      Date: Mon, 19 Apr 1999 22:13:21 -0400 (EDT)
      From: Ismael Cordeiro 
      X-Sender: ismael@Stratus.CAM.ORG
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Lynx, colors and VT100
      In-Reply-To: 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=ISO-8859-1
      Content-Transfer-Encoding: 8BIT
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1286
      Lines: 35
      
      On Mon, 19 Apr 1999 mattack@area.com wrote:
      
      > >You may disagree but the fact is that most VT100 terminal emulators
      > >support color.
      > 
      > But this is a contradiction in terms.
      
      Yes, it is but they support color.
      
      > If VT100 does not support color, which others have stated is a fact,
      
      Yes, true VT100 terminals dodn't support color.
      
      > then a "vt100 emulator" cannot support color, because it is no longer a
      > vt100 emulator.
      
      `A la lettre, you're right but they are VT100 emulators _and_ support color.
      
      > It could be called a "vt100-ish emulator that also supports color", but by
      > definition a vt100 emulator cannot support color if it is true that actual
      > vt100 terminals do not display color.
      
      Usually, those emulations are called VT102 although, as far as I know, true
      VT102 terminals don't support color either. You may call them whatever you
      want, VT147, VT172, etc. and they will still support color.
      
      Ismael
      -- 
      
             +--------------------------------------------------------------+
             | ISMAEL CORDEIRO            | mailto:ismael@cordeiro.com      |
             | Production sound mixer     | http://www.ismael.cordeiro.com/ |
             | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ |
             +--------------------------------------------------------------+
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 22:24:07 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA18536
      	for ; Mon, 19 Apr 1999 22:24:06 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA19742; Mon, 19 Apr 1999 21:15:34 -0500 (CDT)
      Date: Mon, 19 Apr 1999 22:15:39 -0400 (EDT)
      From: Ismael Cordeiro 
      X-Sender: ismael@Stratus.CAM.ORG
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Lynx, colors and VT100
      In-Reply-To: <199904200001.UAA29356@shell.clark.net>
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=ISO-8859-1
      Content-Transfer-Encoding: 8BIT
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1151
      Lines: 28
      
      On Mon, 19 Apr 1999 dickey@clark.net wrote:
      
      > > But this is a contradiction in terms. 
      > 
      > yes (I don't think I should argue, since people are likely to forget this)
      
      If they forget and have problems getting color witha VT100 terminal emulator
      I'll be here to help them.
      
      > > If VT100 does not support color, which others have stated is a fact,
      > > then a "vt100 emulator" cannot support color, because it is no longer a
      > > vt100 emulator. It could be called a "vt100-ish emulator that also
      > > supports color", but by definition a vt100 emulator cannot support color
      > > if it is true that actual vt100 terminals do not display color.
      > 
      > IC's point is that a vt100 is whatever he chooses to call a vt100.
      
      It's not me who called them VT100 or VT102, the programmers did.
      
      Ismael
      -- 
      
             +--------------------------------------------------------------+
             | ISMAEL CORDEIRO            | mailto:ismael@cordeiro.com      |
             | Production sound mixer     | http://www.ismael.cordeiro.com/ |
             | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ |
             +--------------------------------------------------------------+
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 22:27:10 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA18583
      	for ; Mon, 19 Apr 1999 22:27:09 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA20574; Mon, 19 Apr 1999 21:18:38 -0500 (CDT)
      Date: Mon, 19 Apr 1999 19:18:33 -0700 (PDT)
      From: Doug Kaufman 
      X-Sender: dkaufman@waltz
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files)
      In-Reply-To: <19990419093839.A25894@mail.bcpl.net>
      Message-Id: 
      Mime-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2213
      Lines: 53
      
      On Mon, 19 Apr 1999, Webmaster Jim wrote:
      
      > I noticed the INSTALLTION file did not mention lynx_save_space, which
      > could be good to know for installing on Win32, so here's a doc patch:
      > 
      > *** INSTALLATION.df     Tue Apr 13 05:39:16 1999
      > --- INSTALLATION        Mon Apr 19 09:29:31 1999
      > ***************
      > ... 
      > ! 2. Win32 (95/98/NT) and 386 DOS
      >      These ports cannot start before setting certain environment variables
      > 
      >      (adapted from "readme.txt" by Wayne Buttles and "readme.dos" by Doug Kaufman)
      > ***************
      > *** 866,871 ****
      > --- 866,872 ----
      >       TEMP or TMP  Bookmarks are kept here with no HOME.  Temp files here.
      >       USER         Set to your login name (optional)
      >       LYNX_CFG     Set to the full path and filename for lynx.cfg
      > +     LYNX_SAVE_SPACE  The (modifiable) location for downloaded file storage.
      > 
      >       386 version only:
      >       WATTCP.CFG   Set to the full path for the WATTCP.CFG directory
      > ***************
      > *** 877,882 ****
      > --- 878,884 ----
      >         set home=d:\win32
      >         set temp=d:\tmp
      >         set lynx_cfg=d:\win32\lynx.cfg
      > +       set lynx_save_space=d:\download
      >         d:\win32\lynx.exe %1 %2 %3 %4 %5
      
      I agree that we may want to point users to a method of designating
      the save_space directory, but I think that these changes may be
      misleading, since this is the section for environment variables
      without which lynx frequently will not work. The program works
      fine without this, but may save programs to a directory that the
      user didn't expect. Since most users of Win32 and DOS systems use
      a single-user system, it is probably simpler to set SAVE_SPACE in
      lynx.cfg than to set an environment variable whenever the program
      is invoked. I think that this probably goes with the advice to read
      and configure lynx.cfg, especially if the program doesn't work as
      expcected or desired. Where does advice like this go, in the PROBLEMS
      file or elsewhere? I am not sure the INSTALLATION is the best place.
      Also, is this really specific to the Win32 and DOS ports? This seems
      like a more general problem to me?
                                   Doug
      
      __
      Doug Kaufman
      Internet: dkaufman@rahul.net (preferred)
      	  bn900@cleveland.freenet.edu
      
      
      From owner-lynx-dev@sig.net  Mon Apr 19 22:38:09 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA19010
      	for ; Mon, 19 Apr 1999 22:38:08 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23949; Mon, 19 Apr 1999 21:31:36 -0500 (CDT)
      Date: Mon, 19 Apr 1999 19:31:31 -0700 (PDT)
      From: Doug Kaufman 
      X-Sender: dkaufman@waltz
      To: lynx-dev@sig.net
      Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files)
      In-Reply-To: 
      Message-Id: 
      Mime-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1349
      Lines: 32
      
      On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      
      > 19-Apr-99 09:38 Webmaster Jim wrote:
      > > On Mon, Apr 19, 1999 at 01:19:59PM +0100, Don Adaway wrote:
      > >> In article , Doug
      > >> Kaufman  writes
      > >> >This sounds like a problem with your cp.exe program. Do you have it
      > >> Many thanks for solving the problem.  Cp.exe was not in a directory in
      > > [ ... ]
      > 
      > IMHO we should check the existance of cp.exe and mv.exe at DOSPATH platforms
      > and force HTAlert error when these executables apparently lost (LYCopyFile).
      > What does status codes for
      >         code = LYSystem(the_command)
      > look like?
      
      The problem is more complex. As in this user's case, he had a cp.exe
      program, but it was the wrong one. Making sure that there is a valid
      cp program, that follows the expected syntax, seems like a lot of
      overhead every time lynx is run.
      
      I am not sure about mv.exe. Although I distribute mv.exe with lynx
      on my web and ftp sites, I am not sure that it is ever used in the
      DOS port. The last time I grep'ed for this in the code, it was used
      primarily in the DIRED functions, which aren't compiled into the DOS
      port. Where is this used by the DOS or Win32 ports?
                                    Doug
      __
      Doug Kaufman
      Internet: dkaufman@rahul.net (preferred)
      	  bn900@cleveland.freenet.edu
      
      
      From owner-lynx-dev@sig.net  Tue Apr 20 00:24:11 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id AAA22353
      	for ; Tue, 20 Apr 1999 00:24:11 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA16617; Mon, 19 Apr 1999 23:13:18 -0500 (CDT)
      Date: Mon, 19 Apr 1999 21:13:13 -0700
      From: Michael Warner 
      To: lynx-dev@sig.net
      Subject: "hidden" links (was Re: http://www.slcc.edu/lynx/html/todo-list.html) [lynx-dev]
      Message-ID: <19990419211313.C25471@unicorn.it.wsu.edu>
      Mail-Followup-To: lynx-dev@sig.net
      References: <19990417235741.A740@unicorn.it.wsu.edu> 
      Mime-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      X-Mailer: Mutt 0.95.1i
      In-Reply-To: ; from mattack@area.com on Sun, Apr 18, 1999 at 05:05:47PM -0700
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2083
      Lines: 56
      
      On or about 18 Apr, 1999, mattack@area.com
       wrote:
      
      > On Sat, 17 Apr 1999, Michael Warner wrote:
      > >On or about 17 Apr, 1999, Doug Kaufman
      > > wrote:
      > >> You need to turn on "image links". While in lynx, you
      > >> control this with the "*" key. It can also be set from your
      > ...
      > 
      > >I don't think that's the problem.  They use an IMG in place
      > >of link text, and the '*' key just gets the IMG url
      > >(.../high_bidders.gif), not the url of the bidders list.
      > >The link he wants is available as a "hidden link" on the
      > >'L'inks page.  Using the "-hiddenlinks=merge" commandline
      > 
      > So what exactly is a hidden link?
      
      Well, it turns out they weren't really the problem, either.
      As I think Doug mentioned in an unquoted part, the mark-up
      on the page is suspect, specifically some nested anchor
      tags, I believe.  TagSoup takes care of it.
      
      With SortaSGML, the link does show in the L)inks page as a
      hidden link, which is where I went astray.
      
      An "actual" hidden link could be like:
      
       (I believe)
      
      which gets picked up with "*".  No ALT at all gets "[LINK]"
      as selectable text.
      
      An empty link -  - would be the purest form of
      hidden link.
      
      > I mean, how does someone create a hidden link and why would they do so?
      > (I presume it's not hidden in GUI browsers?)
      
      I'd think the empty anchor form would be hidden, regardless.
      I speculate they have some sort of page-maintenance
      function, but I think the others are just poor authoring
      practice, by and large.
      
      > I may be wrong, but I'm under the impression that "image links" needs to
      > be turned on for the case where an image is linked to a URL.. i.e. instead
      > of a link being text, the link is a picture.. and since most people don't
      > view images in links, this causes these types of links to be invisible.
      > (..and causes confusion for Lynx users often..)
      
      Confuses me, anyway.  I may still have some errors above,
      but it's better than my first effort, at least.
      
      -- 
      Michael Warner 		"You're cute when you're stupid"
      				-- R.A. Miller
      
      From owner-lynx-dev@sig.net  Tue Apr 20 01:57:14 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id BAA25117
      	for ; Tue, 20 Apr 1999 01:57:13 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA29982; Tue, 20 Apr 1999 00:42:10 -0500 (CDT)
      From: pg@sweng.stortek.com
      Message-id: <199904200541.XAA20718@sanitas>
      Subject: Re: lynx-dev Lynx, colors and VT100
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 23:41:35 -0600 (MDT)
      In-Reply-To:  from "Ismael Cordeiro" at Apr 19, 99 10:13:21 pm
      X-Mailer: ELM [version 2.4 PL24]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 705
      Lines: 18
      
      In a recent note, Ismael Cordeiro said:
      
      > Date: Mon, 19 Apr 1999 22:13:21 -0400 (EDT)
      > 
      > > then a "vt100 emulator" cannot support color, because it is no longer a
      > > vt100 emulator.
      > 
      > `A la lettre, you're right but they are VT100 emulators _and_ support color.
      > 
      One thing that matters is that not only must the "emulator" support color,
      but curses must support generating the color escape sequences for that
      emulator, which means in turn that the termcap/terminfo for that
      TERM type must define those color escape sequences.  This is likely
      not to be under the control of the "emulator" author.
      
      -- gil
      --------------------
      The great thing about standards is that you get to choose from so many.
      
      From owner-lynx-dev@sig.net  Tue Apr 20 02:56:49 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA27185
      	for ; Tue, 20 Apr 1999 02:56:48 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06496; Tue, 20 Apr 1999 01:38:33 -0500 (CDT)
      To: lynx-dev@sig.net
      References: 
      Message-Id: 
      From: "Leonid Pauzner" 
      Date: Tue, 20 Apr 1999 10:34:58 +0400 (MSD)
      X-Mailer: dMail [Demos Mail for DOS v2.07b]
      Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files)
      MIME-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2184
      Lines: 49
      
      19-Apr-99 19:31 Doug Kaufman wrote:
      > On Mon, 19 Apr 1999, Leonid Pauzner wrote:
      
      >> 19-Apr-99 09:38 Webmaster Jim wrote:
      >> > On Mon, Apr 19, 1999 at 01:19:59PM +0100, Don Adaway wrote:
      >> >> In article , Doug
      >> >> Kaufman  writes
      >> >> >This sounds like a problem with your cp.exe program. Do you have it
      >> >> Many thanks for solving the problem.  Cp.exe was not in a directory in
      >> > [ ... ]
      >>
      >> IMHO we should check the existance of cp.exe and mv.exe at DOSPATH platforms
      >> and force HTAlert error when these executables apparently lost (LYCopyFile).
      >> What does status codes for
      >>         code = LYSystem(the_command)
      >> look like?
      
      > The problem is more complex. As in this user's case, he had a cp.exe
      > program, but it was the wrong one. Making sure that there is a valid
      > cp program, that follows the expected syntax, seems like a lot of
      > overhead every time lynx is run.
      
      I mean this is a common problem: distributive may be broken (cp.exe lost
      or unavailable from PATH) and DOS/Win32 user have no reliable diagnostics,
      the screen just flushed and nothing happened. I have no intention
      to check the existance of cp.exe file (and it may be broken anyway),
      I just want to issue a warning when command fails so the user understand
      the problem.
      
      > I am not sure about mv.exe. Although I distribute mv.exe with lynx
      > on my web and ftp sites, I am not sure that it is ever used in the
      > DOS port. The last time I grep'ed for this in the code, it was used
      > primarily in the DIRED functions, which aren't compiled into the DOS
      > port. Where is this used by the DOS or Win32 ports?
      
      I saw it also in LYBookmarks.c multibookmarks code, grep for "LYCopyFile"
      and read few lines below.  It is not clear for me,
      that code use copy, rename and move for different sitiations
      and there is a comment "rename will not work across filesystems".
      At least for DOS we could use copy only and forget about else
      (IMO ifdef'ing should be corrected: ifdef UNIX -> ifndef VMS).
      
      >                               Doug
      > __
      > Doug Kaufman
      > Internet: dkaufman@rahul.net (preferred)
      >         bn900@cleveland.freenet.edu
      
      
      
      
      
      From owner-lynx-dev@sig.net  Tue Apr 20 03:05:26 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27501
      	for ; Tue, 20 Apr 1999 03:05:24 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA07878; Tue, 20 Apr 1999 01:50:44 -0500 (CDT)
      From: David Woolley 
      Message-Id: <199904190750.IAA02978@djwhome.demon.co.uk>
      Subject: Re: lynx-dev Lynx, colors and VT100
      To: lynx-dev@sig.net
      Date: Mon, 19 Apr 1999 08:50:45 +0100 (BST)
      In-Reply-To:  from "Ismael Cordeiro" at Apr 18, 99 12:28:18 pm
      X-Mailer: ELM [version 2.4 PL25]
      MIME-Version: 1.0
      Content-Type: text/plain; charset=US-ASCII
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 455
      Lines: 13
      
      > termcap
      > -------
      > :Co#8:pa#64:op=3D\E[37;40m:AF=3D\E[3%dm:AB=3D\E[4%dm:
      
      You forgot:  :tc=vt100    and of course changing the name of the entry to
      reflect that it is no longer a VT100 entry.  Similar considerations
      apply to terminfo.
      
      You might also want to see wether term=vt240 works, as, I believe, this
      was the first colour terminal in Digital's VTxxx series.
      
      By changing the capabilities but not the name, you are abusing the
      termcap mechanism.
      
      From owner-lynx-dev@sig.net  Tue Apr 20 03:16:15 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA27798
      	for ; Tue, 20 Apr 1999 03:16:14 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA09611; Tue, 20 Apr 1999 02:06:43 -0500 (CDT)
      Date: Tue, 20 Apr 1999 02:06:34 -0500 (CDT)
      From: Klaus Weide 
      To: Hans Georg Schaathun 
      cc: lynx-dev@sig.net
      Subject: Re: lynx-dev 
      Message-ID: 
      MIME-Version: 1.0
      Content-Type: TEXT/PLAIN; charset=US-ASCII
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 340
      Lines: 13
      
      On Tue, 20 Apr 1999, Hans Georg Schaathun wrote:
      
      > I thought I was a lynx friendly web author, until I started
      > coding forms...
      > 
      > Then I found that lynx plainly ignores hidden input fields.
      
      It certainly doesn't, unless you have a very old version.
      Hidden form fields are supported since at least 2.5, probably
      much earlier.
      
        Klaus
      
      
      From owner-lynx-dev@sig.net  Tue Apr 20 05:37:38 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA32758
      	for ; Tue, 20 Apr 1999 05:37:37 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22882; Tue, 20 Apr 1999 04:21:00 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904200920.FAA26337@shell.clark.net>
      Subject: Re: lynx-dev Lynx, colors and VT100
      To: lynx-dev@sig.net
      Date: Tue, 20 Apr 1999 05:20:55 -0400 (EDT)
      In-Reply-To: <199904190750.IAA02978@djwhome.demon.co.uk>  from "David Woolley " at Apr 19, 99 08:50:45 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 777
      Lines: 27
      
      > 
      > > termcap 
      > > ------- 
      > > :Co#8:pa#64:op=3D\E[37;40m:AF=3D\E[3%dm:AB=3D\E[4%dm: 
      >  
      > You forgot:  :tc=vt100    and of course changing the name of the entry to 
      > reflect that it is no longer a VT100 entry.  Similar considerations 
      > apply to terminfo. 
      >  
      > You might also want to see wether term=vt240 works, as, I believe, this 
      > was the first colour terminal in Digital's VTxxx series. 
      it doesn't use the ANSI controls.
      
      afaik, the first one that applies to ise the VT525, which was designed
      as a clone of the Wyse 375.
      
      btw, the Wyse375 doesn't use bce, and is not compatible with slang.
      
      > By changing the capabilities but not the name, you are abusing the 
      > termcap mechanism. 
      
      true...
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Tue Apr 20 05:37:41 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA32763
      	for ; Tue, 20 Apr 1999 05:37:39 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA25780; Tue, 20 Apr 1999 04:26:00 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904200925.FAA27015@shell.clark.net>
      Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes)
      To: lynx-dev@sig.net
      Date: Tue, 20 Apr 1999 05:25:26 -0400 (EDT)
      In-Reply-To: <199904200221.LAA27257@ibr1.irm.nara.kindai.ac.jp>  from "Henry Nelson " at Apr 20, 99 11:21:36 am
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 871
      Lines: 24
      
      > Thanks, Klaus, for the input.  Tom, please apply Doug's and Jim's patches to 
      > INSTALLATION first.  This Saturday I should be able to respond to comments 
      > and send in a revision. 
      
      on my list
        
      > Tom, and others, could you comment on this "editing of userdefs.h" change. 
      > It was my impression that there WAS no longer a need to edit userdefs.h, and 
      > that some of you never do anymore.  Should I leave it the way it is, or 
      > should I make the change, but emphasize that if you don't edit userdefs.h, 
      > you absolutely must edit lynx.cfg? 
      
      I don't edit userdefs.h myself - do everything that I need to with the
      configure script.  But there are some definitions (at least) listed in
      the makefile.in that are not covered.  Perhaps we need to make a similar
      list for userdefs.h
        
      > __Henry 
      
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Tue Apr 20 05:44:59 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id FAA00064
      	for ; Tue, 20 Apr 1999 05:44:58 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA28762; Tue, 20 Apr 1999 04:30:02 -0500 (CDT)
      From: dickey@clark.net
      Message-Id: <199904200929.FAA27262@shell.clark.net>
      Subject: Re: lynx-dev Lynx, colors and VT100
      To: lynx-dev@sig.net
      Date: Tue, 20 Apr 1999 05:29:59 -0400 (EDT)
      In-Reply-To: <199904200541.XAA20718@sanitas>  from "pg@sweng.stortek.com" at Apr 19, 99 11:41:35 pm
      X-Mailer: ELM [version 2.4 PL25]
      Content-Type: text
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 1018
      Lines: 27
      
      > In a recent note, Ismael Cordeiro said: 
      >  
      > > Date: Mon, 19 Apr 1999 22:13:21 -0400 (EDT) 
      > >  
      > > > then a "vt100 emulator" cannot support color, because it is no longer a 
      > > > vt100 emulator. 
      > >  
      > > `A la lettre, you're right but they are VT100 emulators _and_ support color. 
      > >  
      > One thing that matters is that not only must the "emulator" support color, 
      > but curses must support generating the color escape sequences for that 
      > emulator, which means in turn that the termcap/terminfo for that 
      > TERM type must define those color escape sequences.  This is likely 
      > not to be under the control of the "emulator" author. 
      
      not to worry.  slang has a private interface that makes it "work".
      sort of like the html abuse that people on this list complain about
      from time to time.  (but when you have a public/standard interface,
      the private interfaces just get in the way - they're nothing more than
      fancy bugs).
        
      > -- gil 
      
      -- 
      Thomas E. Dickey
      dickey@clark.net
      http://www.clark.net/pub/dickey
      
      From owner-lynx-dev@sig.net  Tue Apr 20 06:49:18 1999
      Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203])
      	by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id GAA01796
      	for ; Tue, 20 Apr 1999 06:49:18 -0400
      Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA10978; Tue, 20 Apr 1999 05:38:36 -0500 (CDT)
      To: lynx-dev@sig.net, cynthia.griffiths@reuters.com
      References: <199904191846.NAA22441@roadrunner.sig.net>
      Message-Id: 
      From: "Leonid Pauzner" 
      Date: Tue, 20 Apr 1999 14:31:43 +0400 (MSD)
      X-Mailer: dMail [Demos Mail for DOS v2.07b]
      Subject: Re: lynx-dev Lynx Question
      MIME-Version: 1.0
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Sender: owner-lynx-dev@sig.net
      Precedence: bulk
      Reply-To: lynx-dev@sig.net
      Status: RO
      Content-Length: 2369
      Lines: 68
      
      19-Apr-99 18:46 Cynthia Griffiths (516)233-6839 wrote:
      > I am using Lynx 2.4-FM on an digital alpha running VMS
      
      Lynx does not support JavaScript so you could not use onLoad=... etc.
      
      With current Lynx 2.8.1 your sample displayed just as a clean page
      (no submit buttons, all form fields are hidden) but no hang or so.
      If you add submit button user could press it to submit you hidden items,
      probably of a little interest since I have no idea what kind of monitoring
      do you want to perform.
      
      > When I run the following code:
      > 
      > Link page
      > 
      > 
      
      > 
      
      > 
      action="http://196.3.23.218/dbamail/webmaildba.pl"> > type="hidden" name="addrfrom" > value="DTM Monitoring"> type="hidden" name="msgbody" value="Backlog of over 3 DTMS"> > > > > I get the following error: > terminal = vt_400 series > data transfer complete > BUT I'm am in a "hung" condition and must perform a cntrl Y to return to a > Lynx session (the webmaildba.pl perl script never gets called) > If I change the from "hidden" to "text" in the above code I > don't hang but I default to interactive lynx and the action address never > is gotten to. > Thanks for any help, > Cindi > ***** > In case you're wondering what I'm attempting to do. > The form outlined above presently calls a Perls script that sends mail. > It works on an NT box. > I am attempting to write DCL (VMS code) to check if the number of files is > greater than 3 in a directory, if so I want to notify the "on call person" > via email. I wrote the DCL command and was hoping to use Lynx to help me > access a netscape browser so that I can submit my form to the Perl script > to send mail. I was hoping to do all this as background procedures. > (Thanks Again) > ------------------------------------------------------------------------ > Any views expressed in this message are those of the individual sender, > except where the sender specifically states them to be the views of > Reuters Ltd. From owner-lynx-dev@sig.net Tue Apr 20 07:16:31 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA02450 for ; Tue, 20 Apr 1999 07:16:29 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA11985; Tue, 20 Apr 1999 05:49:13 -0500 (CDT) Date: Tue, 20 Apr 1999 06:48:39 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904200648.AA29844@cas.org> Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: Your message of Mon, 19 Apr 1999 19:01:53 -0400 (EDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 608 Lines: 10 If an emulator provides color support, it isn't really a vt100 emulator any more. It can perhaps use a vt100's terminfo/termcap attributes, for the most part. But it is more accurately either a subset or a full vt330 or higher emulator, since no vt100 that I ever saw had color - one can't claim to emulate something that never existed... -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 20 07:25:22 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA02743 for ; Tue, 20 Apr 1999 07:25:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA13177; Tue, 20 Apr 1999 06:00:20 -0500 (CDT) Date: Tue, 20 Apr 1999 06:59:28 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904200659.AA29880@cas.org> Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: <199904200925.FAA27015@shell.clark.net> of Tue, 20 Apr 1999 05:25:26 -0400 (EDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 796 Lines: 19 From: dickey@clark.net >> Tom, and others, could you comment on this "editing of userdefs.h" change. >> It was my impression that there WAS no longer a need to edit userdefs.h, and >I don't edit userdefs.h myself - do everything that I need to with the >configure script. But there are some definitions (at least) listed in >the makefile.in that are not covered. Perhaps we need to make a similar >list for userdefs.h Here is what I edit in userdefs.h - perhaps there are new configure flags I've not found? BOXVERT BOXHORI -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 20 07:49:47 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id HAA03587 for ; Tue, 20 Apr 1999 07:49:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA15599; Tue, 20 Apr 1999 06:22:40 -0500 (CDT) Date: Tue, 20 Apr 1999 06:22:35 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net cc: "Cynthia Griffiths (516)233-6839" Subject: Re: lynx-dev Lynx Question In-Reply-To: <199904191846.NAA22441@roadrunner.sig.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3173 Lines: 89 On Mon, 19 Apr 1999, Cynthia Griffiths (516)233-6839 wrote: > I am using Lynx 2.4-FM on an digital alpha running VMS You should probably get a newer version, this is now quite old. However, whether that matters depends on what you are trying to to, which is not clear to me. > When I run the following code: The below is not code, it is HTML text. That's not just terminology nitpicking, since you cannot "run" HTML text, in the usual sense of the word. What are you actually doing with the HTML text? Invoke lynx on a file containing the text (with what -flags?) from a DCL command file? Invoke lynx interactively and then 'g'oto a URL with that text? Or something else? The embedded scripting is of course ignored by lynx (as you probably know). > > Link page > > > > > >
      action="http://196.3.23.218/dbamail/webmaildba.pl"> > type="hidden" name="addrfrom" > value="DTM Monitoring"> type="hidden" name="msgbody" value="Backlog of over 3 DTMS"> > > > > > I get the following error: > terminal = vt_400 series > data transfer complete > BUT I'm am in a "hung" condition and must perform a cntrl Y to return to a > Lynx session (the webmaildba.pl perl script never gets called) > > If I change the from "hidden" to "text" in the above code I > don't hang but I default to interactive lynx and the action address never > is gotten to. > > Thanks for any help, > Cindi > > ***** > In case you're wondering what I'm attempting to do. > The form outlined above presently calls a Perls script that sends mail. > It works on an NT box. > > I am attempting to write DCL (VMS code) to check if the number of files is > greater than 3 in a directory, if so I want to notify the "on call person" > via email. I wrote the DCL command and was hoping to use Lynx to help me > access a netscape browser so that I can submit my form to the Perl script > to send mail. Do you really want to "access a netscape browser" with lynx? That doesn't seem to make sense. If you just want to submit the form data with lynx, what role does netscape play? > I was hoping to do all this as background procedures. If you just want to submit the form to the script non-interactively, that should be possible with lynx (but I don't know whether it is with your 2.4-FM) under VMS. But don't expect lynx to parse HTML text for the data to submit and then automatically do the POST - it will never do that (no matter what happens on an NT box under completely different circumstances). You have to give the data to lynx directly. You probably want to use `lynx -dump -post_data' or similar. But if that perl CGI script also understands the GET form method, things could be made much simpler. Klaus From owner-lynx-dev@sig.net Tue Apr 20 08:22:06 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA04605 for ; Tue, 20 Apr 1999 08:22:05 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA20576; Tue, 20 Apr 1999 07:01:25 -0500 (CDT) Message-ID: <1Cy0jCAaxGH3EwbQ@freeuk.net> Date: Tue, 20 Apr 1999 13:00:26 +0100 To: lynx-dev@sig.net From: Don Adaway Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files) References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1588 Lines: 30 In article , Doug Kaufman writes >The problem is more complex. As in this user's case, he had a cp.exe >program, but it was the wrong one. Making sure that there is a valid >cp program, that follows the expected syntax, seems like a lot of >overhead every time lynx is run. > As the user mentioned above may I make a comment? The problem was self- inflicted. My original intention was to ensure that downloaded files arrived in a directory of my choice. I had discovered that files were being downloaded to the working directory. This was \lynx by default and because this directory contains the all-important Lynx binaries I preferred that they go elsewhere. Accordingly I changed the working directory, but this had the effect that cp.exe (in the \lynx directory) was no longer on the path and another program called cp.exe (in the path) was being executed. This would not have happened had I understood the significance of the working directory, the path, and the existence of the SAVE_SPACE variable in the behaviour of Lynx. The only place where the existence of the SAVE_SPACE variable is mentioned is in the lynx.cfg file itself; none of the help files mention it that I can find. I feel that mention of the possible interaction between working directory, path and SAVE_SPACE should appear somewhere; possibly comment lines in lynx.cfg would do the trick. It's all obvious when you know, but then perhaps I'm the only person stupid enough to have had this problem. -- Don chervil @ freeuk . com From owner-lynx-dev@sig.net Tue Apr 20 08:44:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA05229 for ; Tue, 20 Apr 1999 08:44:23 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA23268; Tue, 20 Apr 1999 07:17:21 -0500 (CDT) From: dickey@clark.net Message-Id: <199904201216.IAA13272@shell.clark.net> Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 08:16:52 -0400 (EDT) In-Reply-To: <9904200659.AA29880@cas.org> from "lvirden@cas.org" at Apr 20, 99 06:59:28 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 934 Lines: 28 > > From: dickey@clark.net > >> Tom, and others, could you comment on this "editing of userdefs.h" change. > >> It was my impression that there WAS no longer a need to edit userdefs.h, and > > >I don't edit userdefs.h myself - do everything that I need to with the > >configure script. But there are some definitions (at least) listed in > >the makefile.in that are not covered. Perhaps we need to make a similar > >list for userdefs.h > > Here is what I edit in userdefs.h - perhaps there are new configure flags > I've not found? > > BOXVERT > BOXHORI iirc, those should be set properly by the configure script. (I use box characters in Lynx, except of course running minicom in xterm doesn't do box characters since it doesn't really support the alternate character set). > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 20 08:51:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id IAA05514 for ; Tue, 20 Apr 1999 08:51:11 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA25657; Tue, 20 Apr 1999 07:30:40 -0500 (CDT) Date: Tue, 20 Apr 1999 07:30:36 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev dev.22 patch 2 - userdefs et al Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 13401 Lines: 320 The below doesn't deal with userdefs.h de-MUSTification (mentioned in another message) at all - I'll gladly leave that to Henry :) Other remarks: - Does it make sense to store/read partial_thres in/from .lynxrc at all? - I think the userdefs.h text regarding *_PATH is more correct now, but somebody should verify; and it may have to change with what Doug Kaufman just suggested. Klaus * Various changes to userdefs.h and lynx.cfg explanatory text. * Corrected placement of "partial_thres" code in LYrcFile.c, removed an unused prototype in LYUtils.h. --- lynx2-8-2.old/userdefs.h Tue Apr 13 04:39:16 1999 +++ lynx2-8-2/userdefs.h Tue Apr 20 07:08:52 1999 @@ -9,7 +9,7 @@ * There are four sections to this document: * Section 1. Things you MUST change or verify * Section 1a) VMS specific things - * Section 1b) UNIX specific things + * Section 1b) non-VMS specific things * Section 1c) ALL Platforms * * Section 2. Things you should probably check! @@ -35,7 +35,7 @@ */ /******************************************************************* - * Things you must change VMS specific + * Things you must change - VMS specific * Section 1a). */ #ifdef VMS @@ -94,8 +94,9 @@ /************************** * The EXTENSION_MAP file allows you to map file suffixes to * mime types. - * These global and personal files override anything in - * lynx.cfg or src/HTInit.c + * The file locations defined here can be overridden in lynx.cfg. + * Mappings in these global and personal files override any SUFFIX + * definitions in lynx.cfg and built-in defaults from src/HTInit.c. */ #define GLOBAL_EXTENSION_MAP "Lynx_Dir:mime.types" #define PERSONAL_EXTENSION_MAP "mime.types" @@ -103,8 +104,9 @@ /************************** * The MAILCAP file allows you to map file MIME types to * external viewers. - * These global and personal files override anything in - * lynx.cfg or src/HTInit.c + * The file locations defined here can be overridden in lynx.cfg. + * Mappings in these global and personal files override any VIEWER + * definitions in lynx.cfg and built-in defaults from src/HTInit.c. */ #define GLOBAL_MAILCAP "Lynx_Dir:mailcap" #define PERSONAL_MAILCAP ".mailcap" @@ -224,10 +226,10 @@ #endif /* LYNX_LSS_FILE */ /******************************************************************* - * Things you must change UNIX specific + * Things you must change - non-VMS specific * Section 1b). */ -#else /* UNIX */ +#else /* non-VMS: UNIX etc. */ /************************** * NOTE: This variable is set by the configure script; editing changes will @@ -277,8 +279,9 @@ /************************** * The EXTENSION_MAP file allows you to map file suffixes to * mime types. - * These global and personal files override anything in - * lynx.cfg or src/HTInit.c + * The file locations defined here can be overridden in lynx.cfg. + * Mappings in these global and personal files override any SUFFIX + * definitions in lynx.cfg and built-in defaults from src/HTInit.c. */ #define GLOBAL_EXTENSION_MAP "/usr/local/lib/mosaic/mime.types" #define PERSONAL_EXTENSION_MAP ".mime.types" @@ -286,8 +289,9 @@ /************************** * The MAILCAP file allows you to map file MIME types to * external viewers. - * These global and personal files override anything in - * lynx.cfg or src/HTInit.c + * The file locations defined here can be overridden in lynx.cfg. + * Mappings in these global and personal files override any VIEWER + * definitions in lynx.cfg and built-in defaults from src/HTInit.c. */ #define GLOBAL_MAILCAP "/usr/local/lib/mosaic/mailcap" #define PERSONAL_MAILCAP ".mailcap" @@ -324,7 +328,9 @@ * If the path includes a tilde (e.g, "~" or "~/lynxtmp"), Lynx will * replace the tilde with the full path for the user's home. * The definition here can be overridden at run time by setting a - * "LYNX_TEMP_SPACE" environment symbol. + * "LYNX_TEMP_SPACE" environment variable, or (if that is not set) + * the "TMPDIR" (unix), or "TEMP" or "TMP" (Windows,DOS,OS/2) + * variable. */ #define TEMP_SPACE "/tmp/" @@ -352,8 +358,8 @@ * %d date of last modification * %a anchor pointing to file or directory * %A as above but don't show symbolic links - * %t type of file (description derived from MIME type) - * %T MIME type as known by Lynx (from mime.types or default) + * %t type of file (description derived from MIME type) + * %T MIME type as known by Lynx (from mime.types or default) * %k size of file in Kilobytes * %K as above but omit size for directories * %s size of file in bytes @@ -1036,8 +1042,9 @@ * The first two settings: * LOCAL_EXECUTION_LINKS_ALWAYS_ON * LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE - * specify the DEFAULT setting of the users execution link - * options, but the user may still change those options. + * specify the DEFAULT settings of the users execution link + * options (they can also be overridden in lynx.cfg), but + * the user may still change those options. * If you do not wish the user to be able to change the * execution link settings you may wish to use the command line option: * -restrictions=exec_frozen @@ -1067,6 +1074,8 @@ * MAIL_SYSTEM_ERROR_LOGGING will send a message to the owner of * the information if there is one, every time * that a document cannot be accessed! + * This is just the default, it can be changed in lynx.cfg, and error + * logging can be turned off with the -nolog command line option. * * NOTE: This can generate A LOT of mail, be warned. */ @@ -1078,8 +1087,10 @@ * will get status line messages if subsequent new mail arrives. If a jumps * file with a lynxprog URL for invoking mail is available, or your html * pages include an mail launch file URL, the user thereby can access mail - * and read the messages. The checks and status line reports will not be - * performed if Lynx has been invoked with the -restrictions=mail switch. + * and read the messages. + * This is just the default, it can be changed in lynx.cfg. The checks and + * status line reports will not be performed if Lynx has been invoked with + * the -restrictions=mail switch. * * VMS USERS !!! * New mail is normally broadcast as it arrives, via "unsolicited screen @@ -1091,14 +1102,14 @@ #define CHECKMAIL FALSE /* report unread and new mail messages */ /********************************* - * VI_KEYS can be turned on by the user in the options - * screen or the .lynxrc file. This is just the default. + * VI_KEYS can be changed in lynx.cfg and can be turned on by the user + * in the options screen or the .lynxrc file. This is just the default. */ #define VI_KEYS_ALWAYS_ON FALSE /* familiar h,j,k, & l */ /********************************* - * EMACS_KEYS can be turned on by the user in the options - * screen or the .lynxrc file. This is just the default. + * EMACS_KEYS can be changed in lynx.cfg and can be turned on by the user + * in the options screen or the .lynxrc file. This is just the default. */ #define EMACS_KEYS_ALWAYS_ON FALSE /* familiar ^N, ^P, ^F, ^B */ @@ -1109,12 +1120,15 @@ * NUMBERS_AS_ARROWS or * LINKS_ARE_NUMBERED or * LINKS_AND_FORM_FIELDS_ARE_NUMBERED + * + * This default setting can be overridden in lynx.cfg (but not to + * the third value), and it can be changed at run time by the user. */ #define DEFAULT_KEYPAD_MODE NUMBERS_AS_ARROWS /******************************** * The default search. - * This is a default that can be overridden by the user! + * This is a default that can be overridden in lynx.cfg or by the user! */ #define CASE_SENSITIVE_ALWAYS_ON FALSE /* case sensitive user search */ @@ -1269,10 +1283,21 @@ #define SYSTEM_MAIL "sendmail" #define SYSTEM_MAIL_FLAGS "-t -oi" /* -** Following executables may be sought from your PATH at run-time. -** To get those programs look for GNU-port stuff elsewhere. Currently, -** if compiled with -DUSE_ZLIB and without -DDIRED_SUPPORT (default), -** you need only "cp.exe" from the list below. +** The following executables may be used at run time. Unless you change +** the definitions to include the full directories, they will be sought +** from your PATH at run-time; they should be available as "cp.exe", +** "mv.exe" and so on. To get those programs look for GNU-port stuff +** elsewhere. +** Currently, if compiled with -DUSE_ZLIB and without -DDIRED_SUPPORT +** (default), the following from the list below are required: +** COPY_PATH (cp.exe) - needed for file downloading +** MV_PATH (mv.exe) - for bookmark handling (DEL_BOOKMARK command) +** UNCOMPRESS_PATH, BZIP2_PATH - for automatic decompression of files in +** these formats +** TELNET_PATH, TN3270_PATH, RLOGIN_PATH - for access to "telnet:", +** "tn3270:", and "rlogin:" URLs. +** If they are not defined right, the corresponding operations may fail +** in unexpected and obscure ways! ** ** WINDOWS/DOS ** =========== --- lynx2-8-2.old/lynx.cfg Tue Apr 13 04:39:16 1999 +++ lynx2-8-2/lynx.cfg Tue Apr 20 05:49:40 1999 @@ -1380,8 +1380,20 @@ # MIME types and viewers! # # file extensions may be assigned to MIME types using -# the SUFFIX: definition. [This has an effect for ftp and local files only, -# http server does specify MIME type in the Content-Type header]. +# the SUFFIX: definition. +# +# NOTE: It is normally preferable to define new extension mappings in +# EXTENSION_MAP files (see below) instead of here: Definitions +# here are overriden by those in EXTENSION_MAP files and even by +# some built-in defaults in src/HTInit.c. +# Extension mappings have an effect mostly for ftp and local files, +# they are NOT used to determine the type of content for URLs with +# the http protocol. This is because HTTP servers already specify +# the MIME type in the Content-Type header. [It may still be +# necessary to set up an appropriate suffix for some MIME types, +# even if they are accessed only via the HTTP protocol, if the viewer +# (see below) for those MIME types requires a certain suffix for the +# temporary file passed to it.] # # The SUFFIX definition takes the form of: # SUFFIX:: @@ -1394,7 +1406,8 @@ # The suffix definitions listed here in the default lynx.cfg file are # among those established via src/HTInit.c. You can change any of the # defaults by editing that file, or via the global or personal mime.types -# files at run time. They will be overridden if you assign them here. +# files at run time. Assignments made here will be overridden by entries +# in those files. # #SUFFIX:.ps:application/postscript #SUFFIX:.eps:application/postscript @@ -1479,6 +1492,10 @@ # NOTE: if you do not define a viewer to a new MIME type # that you assigned above then it will be saved to # disk by default. +# It is normally preferable to define new viewers in +# MAILCAP files (see below) instead of here: Definitions +# here are overridden by those in MAILCAP files and even +# by some built-in defaults in src/HTInit.c. # # The VIEWER definition takes the form of: # VIEWER::[:environment] @@ -1507,8 +1524,8 @@ # file are among those established via src/HTInit.c. For the image types, # HTInit.c uses the XLOADIMAGE_COMMAND definition in userdefs.h or above # (open is used for NeXT). You can change any of these defaults via the -# global or personal mailcap files at run time. They will be overridden -# if you assign them here. +# global or personal mailcap files. Assignments made here will be overridden +# by entries in those files. # #VIEWER:application/postscript:ghostview %s&:XWINDOWS #VIEWER:image/gif:xli %s&:XWINDOWS --- lynx2-8-2.old/src/LYrcFile.c Thu Mar 4 04:39:44 1999 +++ lynx2-8-2/src/LYrcFile.c Tue Apr 20 03:37:36 1999 @@ -473,6 +473,17 @@ user_mode = NOVICE_MODE; } +#ifdef DISP_PARTIAL + /* + * Partial display logic--set the threshold # of lines before + * Lynx redraws the screen + */ + } else if (FIND_KEYWORD(cp, "partial_thres")) { + cp = SkipEquals(cp); + if (atoi(cp) != 0) + partial_threshold = atoi(cp); +#endif /* DISP_PARTIAL */ + #ifdef ALLOW_USERS_TO_CHANGE_EXEC_WITHIN_OPTIONS /* * Local execution mode - all links. @@ -484,17 +495,6 @@ local_exec = TRUE; else local_exec = FALSE; - -#ifdef DISP_PARTIAL - /* - * Partial display logic--set the threshold # of lines before - * Lynx redraws the screen - */ - } else if (FIND_KEYWORD(cp, "partial_thres")) { - cp = SkipEquals(cp); - if (atoi(cp) != 0) - partial_threshold = atoi(cp); -#endif /* DISP_PARTIAL */ /* * Local execution mode - only links in local files. --- lynx2-8-2.old/src/LYUtils.h Tue Mar 30 11:10:36 1999 +++ lynx2-8-2/src/LYUtils.h Tue Apr 20 07:08:54 1999 @@ -110,7 +110,6 @@ extern void LYTrimRelFromAbsPath PARAMS((char *path)); extern void LYsetXDisplay PARAMS((char *new_display)); extern void change_sug_filename PARAMS((char *fname)); -extern void checkmail NOPARAMS; extern void convert_to_spaces PARAMS((char *string, BOOL condense)); extern void free_and_clear PARAMS((char **obj)); extern void highlight PARAMS((int flag, int cur, char *target)); From owner-lynx-dev@sig.net Tue Apr 20 09:18:20 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06386 for ; Tue, 20 Apr 1999 09:18:18 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA03750; Tue, 20 Apr 1999 08:05:41 -0500 (CDT) Date: Tue, 20 Apr 1999 09:05:47 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <199904190750.IAA02978@djwhome.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2056 Lines: 49 On Mon, 19 Apr 1999, David Woolley wrote: > > termcap > > ------- > > :Co#8:pa#64:op=3D\E[37;40m:AF=3D\E[3%dm:AB=3D\E[4%dm: > > You forgot: :tc=vt100 I didn't. There is no need for it if the capabilities above are put in the vt100 definition. If I create a definition for an equivalent terminal then tc=vt100 could be used. > and of course changing the name of the entry to reflect that it is no > longer a VT100 entry. Similar considerations apply to terminfo. I could change it to anything else, VT666, VT100-ismael, etc. but then the system wouldn't automatically detect the correct terminal type. If I wanted, I could set the terminal in my .???rc file but I simply put the color capabilities in my .termcap/.terminfo VT100 definition. > You might also want to see wether term=vt240 works, as, I believe, this > was the first colour terminal in Digital's VTxxx series. I think it should be VT241, which seems to be the color version of the VT240, but I couldn't find a definition for VT240/VT241 in any termcap/terminfo file I could put my hands on. Anyway, it wouldn't work. Those post-VT100 terminals use capabilities that are not understood by a VT100 or VT100-compatible terminal. I've already tried setting TERM to VT220 and sometimes the results are disastrous. > By changing the capabilities but not the name, you are abusing the > termcap mechanism. Probably. I wouldn't recommend putting those color capabilities in a global termcap/terminfo but in personal ones there's no problem. I know that my .termcap and .terminfo are "abused", "contradictory", "impure", etc. but they work very well and I get color in Lynx with them. That's what's important for me. Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 09:18:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06400 for ; Tue, 20 Apr 1999 09:18:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA04412; Tue, 20 Apr 1999 08:08:15 -0500 (CDT) Date: Tue, 20 Apr 1999 09:07:42 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904200907.AA4209@cas.org> Subject: lynx-dev Linux's attention to handicap access To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 449 Lines: 9 Slashdot.org carries an article this week on one person's call for attention to making the net more accessible to others. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 20 09:20:41 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06428 for ; Tue, 20 Apr 1999 09:20:41 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA04489; Tue, 20 Apr 1999 08:08:37 -0500 (CDT) Date: Tue, 20 Apr 1999 09:08:44 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <9904200648.AA29844@cas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 808 Lines: 19 On Tue, 20 Apr 1999, Larry W. Virden wrote: > If an emulator provides color support, it isn't really a vt100 emulator > any more. It can perhaps use a vt100's terminfo/termcap attributes, for > the most part. But it is more accurately either a subset or a full vt330 or > higher emulator, since no vt100 that I ever saw had color - one can't claim > to emulate something that never existed... Let's say it's a virtual emulator... Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 09:26:05 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06515 for ; Tue, 20 Apr 1999 09:26:04 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA04684; Tue, 20 Apr 1999 08:09:15 -0500 (CDT) Date: Tue, 20 Apr 1999 08:09:12 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev bookmarks and remove()/COPY_PATH/MV_PATH (was: Win32 docs patch) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1802 Lines: 42 On Tue, 20 Apr 1999, Leonid Pauzner wrote: > 19-Apr-99 19:31 Doug Kaufman wrote: > > I am not sure about mv.exe. Although I distribute mv.exe with lynx > > on my web and ftp sites, I am not sure that it is ever used in the > > DOS port. The last time I grep'ed for this in the code, it was used > > primarily in the DIRED functions, which aren't compiled into the DOS > > port. Where is this used by the DOS or Win32 ports? > > I saw it also in LYBookmarks.c multibookmarks code, grep for "LYCopyFile" > and read few lines below. It is not clear for me, > that code use copy, rename and move for different sitiations > and there is a comment "rename will not work across filesystems". That comment would also apply for Unix if the Unix code used rename. > At least for DOS we could use copy only and forget about else > (IMO ifdef'ing should be corrected: ifdef UNIX -> ifndef VMS). Maybe, although using rename() for situations where it does work would be preferable, even for Unix. [Maybe there are some situations involving symlinks where rename would be bad.] The current situation for DOSPATH looks particularly bad: if the MV_PATH stuff is tried but fails, there is no error indication and the bookmarks file may disappear silently! [It should be there as a cryptically- named temp file after te failure, but that may get deleted when lynx exits.] Can the rename() actually fail? It is unlikely that it fails for the reason of different filesystems, since bookmark files are supposed to be under the HOME directory, and the scratch file is created in the HOME directory (different from other temp files). This would break down if bookmark files in arbitrary locations were allowed (Larry suggested a while ago that absolute paths should be allowed for bookmarks files). Klaus From owner-lynx-dev@sig.net Tue Apr 20 09:27:25 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06536 for ; Tue, 20 Apr 1999 09:27:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA06776; Tue, 20 Apr 1999 08:16:28 -0500 (CDT) X-Authentication-Warning: hortensia.etek.chalmers.se: e7patrik owned process doing -bs Date: Tue, 20 Apr 1999 15:16:23 +0200 (MET DST) From: Patrik Vahtras X-Sender: e7patrik@hortensia To: lynx-dev@sig.net Subject: lynx-dev ftp and passive transfers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1579 Lines: 43 Wouldn't it nice to have passive transfers as a choice in the option menu instead of having to recompile the source for it? --- David Woolley wrote: >> How do I switch lynx into "passive" mode? > > djwhome:/usr/src/lynx/lynx2-7-2$ grep NOPORT Makefile > # -DNOPORT if you must use PASV instead of PORT for FTP > >> I've read the faq, docs and archives of this mailinglist. Also, it >> seems as though others have asked this question but haven't gotten a >> response. > > < 5 mins reading the obvious source file (HTFTP.c). It's in the heading > comments, more or less. > > You will of course need to rebuild from source. Further guidance may > depend on your platform (not everyone uses Win '95, and Lynx is not > originally a Windows program). --- Frederic L.W.Meunier wrote: > > Hi. I just install all the versions of Lynx and i noticed an error with > ftp in all the versions i used. I don't know if it's hard to reproduce. > It's like this. You run Lynx and make various ftp connections. At a > moment Lynx stop returning the list of directories and archives. It > only shows the top of the directory. I'm sure Lynx connected to the ftp > site. This is a known bug or i'm the only one experiencing this problem? > If it's a known bug, there's something to make ftp working correctly > again without the need to restart Lynx? I'm using Lynx 2.8.2dev19 > running Linux 2.2.2 on a RedHat 5.1 with all the updates. Lynx was > compiled with Slang 1.3.5. Thanks. Sounds to me like passive mode is required From owner-lynx-dev@sig.net Tue Apr 20 09:35:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA06845 for ; Tue, 20 Apr 1999 09:35:42 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA09198; Tue, 20 Apr 1999 08:24:15 -0500 (CDT) Date: Tue, 20 Apr 1999 09:24:21 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <199904200929.FAA27262@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1128 Lines: 24 On Tue, 20 Apr 1999 dickey@clark.net wrote: > > One thing that matters is that not only must the "emulator" support > > color, but curses must support generating the color escape sequences for > > that emulator, which means in turn that the termcap/terminfo for that > > TERM type must define those color escape sequences. This is likely not > > to be under the control of the "emulator" author. > > not to worry. slang has a private interface that makes it "work". sort of > like the html abuse that people on this list complain about from time to > time. (but when you have a public/standard interface, the private > interfaces just get in the way - they're nothing more than fancy bugs). I would call them "nice features" instead of "fancy bugs". Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 09:39:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA07065 for ; Tue, 20 Apr 1999 09:39:55 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA08668; Tue, 20 Apr 1999 08:22:48 -0500 (CDT) Date: Tue, 20 Apr 1999 09:22:54 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <199904200541.XAA20718@sanitas> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1463 Lines: 32 On Mon, 19 Apr 1999 pg@sweng.stortek.com wrote: > > > then a "vt100 emulator" cannot support color, because it is no longer > > > a vt100 emulator. > > > > `A la lettre, you're right but they are VT100 emulators _and_ support > > color. > > One thing that matters is that not only must the "emulator" support color, > but curses must support generating the color escape sequences for that > emulator, which means in turn that the termcap/terminfo for that TERM type > must define those color escape sequences. This is likely not to be under > the control of the "emulator" author. Exactly. That's why I put the color capabilities in the VT100 definition of my .termcap/.terminfo. However, some programs, like tin-pre1.4, can send color codes even if the terminal definition doesn't have color capabilities. If you set "use_color=on" in tinrc, tin-pre1.4 will send ANSI color codes to the terminal independently of termcap/terminfo definitions. It's up to the user to see whether the color codes work on their terminals or not. If they don't work, one has just to set "use_color=off". Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 09:45:37 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA07162 for ; Tue, 20 Apr 1999 09:45:31 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA12355; Tue, 20 Apr 1999 08:33:53 -0500 (CDT) From: Philip Webb Message-Id: <199904201333.JAA18010@chass.utoronto.ca> Subject: Re: lynx-dev Win32 docs patch To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 09:33:51 -0400 (EDT) In-Reply-To: <1Cy0jCAaxGH3EwbQ@freeuk.net> from "Don Adaway" at Apr 20, 99 01:00:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 919 Lines: 18 990419 Don Adaway wrote: > The only place where the existence of the SAVE_SPACE variable is mentioned > is in the lynx.cfg file itself; none of the help files mention it > that I can find. I feel that mention of the possible interaction > between working directory, path and SAVE_SPACE should appear somewhere; > possibly comment lines in lynx.cfg would do the trick. It's all obvious > when you know, but then perhaps I'm the only person stupid enough > to have had this problem. do feel free to offer patches to the help files: that's how the documentation grows & improves. you are probably currently the expert on this bit of Lynx behaviour. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From owner-lynx-dev@sig.net Tue Apr 20 09:46:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id JAA07201 for ; Tue, 20 Apr 1999 09:46:33 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA10592; Tue, 20 Apr 1999 08:28:51 -0500 (CDT) Date: Tue, 20 Apr 1999 08:28:46 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev userdefs.h vs. configure (was: INSTALLATION file changes) In-Reply-To: <199904200925.FAA27015@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1492 Lines: 37 On Tue, 20 Apr 1999 dickey@clark.net wrote: [Henry:] > > Tom, and others, could you comment on this "editing of userdefs.h" change. > > It was my impression that there WAS no longer a need to edit userdefs.h, and > > that some of you never do anymore. Should I leave it the way it is, or > > should I make the change, but emphasize that if you don't edit userdefs.h, > > you absolutely must edit lynx.cfg? > > I don't edit userdefs.h myself - do everything that I need to with the > configure script. But there are some definitions (at least) listed in > the makefile.in that are not covered. Perhaps we need to make a similar > list for userdefs.h Going through userdefs.h I found the following definitions, for which some setting cannot be deferred to lynx.cfg, and which cannot be done as ./configure flags #define NO_ANONYMOUS_EMAIL TRUE /* #define PERMIT_GOTO_FROM_JUMP */ #define LY_UMLAUT [ does this still have an effect at all? ] /* #define ALLOW_USERS_TO_CHANGE_EXEC_WITHIN_OPTIONS */ /* #define NEVER_ALLOW_REMOTE_EXEC */ #define LOCAL_EXECUTION_LINKS_ALWAYS_OFF_FOR_ANONYMOUS FALSE Stuff in sections 3 and 4 This list may not be complete, or even correct. Some other settings can be done from configure: some are obviously only fallbacks (they are surrounded by #ifdef), some others don't mention that they can be set from configure: /* #define EXEC_LINKS */ /* #define EXEC_SCRIPTS */ /* #define LYNXCGI_LINKS */ Klaus From owner-lynx-dev@sig.net Tue Apr 20 10:00:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07755 for ; Tue, 20 Apr 1999 10:00:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA15965; Tue, 20 Apr 1999 08:44:38 -0500 (CDT) From: pg@sweng.stortek.com Message-id: <199904201344.HAA23818@sanitas> Subject: Re: lynx-dev bookmarks and remove()/COPY_PATH/MV_PATH (was: Win32 docs patch) To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 07:44:04 -0600 (MDT) In-Reply-To: from "Klaus Weide" at Apr 20, 99 08:09:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 728 Lines: 21 In a recent note, Klaus Weide said: > Date: Tue, 20 Apr 1999 08:09:12 -0500 (CDT) > > Maybe, although using rename() for situations where it does work would > be preferable, even for Unix. [Maybe there are some situations involving > symlinks where rename would be bad.] > Not only symlinks, but even more, hard links can give problems here. Some applications refuse to manipulate multiply-linked files for this reason. And rename may cause undesired changes to file permissions. I submitted a patch regarding this quite a while back, which was partially integrated. And there's the possibility that in a captive account the user may have authority to update a file but not to change the directory containing it. -- gil From owner-lynx-dev@sig.net Tue Apr 20 10:06:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA07912 for ; Tue, 20 Apr 1999 10:06:56 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA10319; Tue, 20 Apr 1999 08:28:01 -0500 (CDT) Date: Tue, 20 Apr 1999 09:28:07 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: <199904201216.IAA13272@shell.clark.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 947 Lines: 27 On Tue, 20 Apr 1999 dickey@clark.net wrote: > > Here is what I edit in userdefs.h - perhaps there are new configure > > flags I've not found? > > > > BOXVERT > > BOXHORI > > iirc, those should be set properly by the configure script. > > (I use box characters in Lynx, except of course running minicom in xterm > doesn't do box characters since it doesn't really support the alternate > character set). BOXVERT and BOXHORi only work with curses/ncurses, not with slang. I think that they should be extended to slang, if possible. And a BOXCORNER would be nice too. Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 10:18:40 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA08329 for ; Tue, 20 Apr 1999 10:18:39 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA19740; Tue, 20 Apr 1999 08:55:05 -0500 (CDT) Date: Tue, 20 Apr 1999 08:54:59 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev Re: "hidden" links (was Re: http://www.slcc.edu/lynx/html/todo-list.html) In-Reply-To: <19990419211313.C25471@unicorn.it.wsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 737 Lines: 25 On Mon, 19 Apr 1999, Michael Warner wrote: > An "actual" hidden link could be like: > > (I believe) > > which gets picked up with "*". No ALT at all gets "[LINK]" > as selectable text. > > An empty link - - would be the purest form of > hidden link. > > > I mean, how does someone create a hidden link and why would they do so? > > (I presume it's not hidden in GUI browsers?) > > I'd think the empty anchor form would be hidden, regardless. > I speculate they have some sort of page-maintenance > function, but I think the others are just poor authoring > practice, by and large. One use for intentionally hidden links is to provide then for search engine (and other) robots. Klaus From owner-lynx-dev@sig.net Tue Apr 20 10:40:32 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA09222 for ; Tue, 20 Apr 1999 10:40:28 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28998; Tue, 20 Apr 1999 09:20:09 -0500 (CDT) Date: Tue, 20 Apr 1999 10:20:14 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev The From: field when sending email Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 826 Lines: 24 I've replied to a message in Lynx-Dev with Lynx and I noticed that the From field came out as | From: Ismael Cordeiro However, I have this in my .lynxrc: | personal_mail_address=ismael@cordeiro.com (Ismael Cordeiro) According to the help files, "This mail address will be used to help you send files to yourself and will be included as the From: address in any mail or comments that you send." There is something wrong somewhere. Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 10:47:15 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA09342 for ; Tue, 20 Apr 1999 10:47:13 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA00287; Tue, 20 Apr 1999 09:23:21 -0500 (CDT) Date: Tue, 20 Apr 1999 07:23:16 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: lynx-dev Minor DOS bug fixes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2710 Lines: 67 I found two bugs in the DOS ports. When exiting with interrupt, the message was printed in binary mode, leaving the cursor in the middle of the screen. In the PDCurses build, the keypad enter key only worked when LYK_ACTIVATE was utilized, but not in GOTOLINK or GOTOPAGE. This maps the keypad enter to '\n', so it works in all situations, but keypad enter will no longer be able to be mapped separately. CTRL-PADENTER and ALT-PADENTER can still be separately mapped. These are against dev.21. I hope there haven't been any changes since then to affect the patches. Doug --- lynx2-8-2/src/LYClean.c Tue Mar 30 09:10:38 1999 +++ lynx2-8-2/src/LYClean.c.new Mon Apr 19 23:07:44 1999 @@ -103,6 +103,7 @@ cleanup(); } if (sig != 0) { + SetOutputMode(O_TEXT); printf("\n\n%s %d\n\n", gettext("Exiting via interrupt:"), sig); --- lynx2-8-2/src/LYKeymap.c Thu Mar 4 02:39:46 1999 +++ lynx2-8-2/src/LYKeymap.c.new Mon Apr 19 22:54:26 1999 @@ -297,8 +297,8 @@ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, - 0, 0, LYK_WHEREIS, LYK_ACTIVATE, - /* KP_SLASH KP_ENTER */ + 0, 0, LYK_WHEREIS, 0, + /* KP_SLASH */ 0, 0, 0, LYK_IMAGE_TOGGLE, /* KP_* */ LYK_PREV_PAGE, LYK_NEXT_PAGE, 0, 0, --- lynx2-8-2/src/LYStrings.c Sun Apr 4 11:23:38 1999 +++ lynx2-8-2/src/LYStrings.c.new Mon Apr 19 22:17:48 1999 @@ -1364,7 +1364,12 @@ case KEY_ENTER: /* enter/return */ c = '\n'; break; -#endif /* KEY_END */ +#endif /* KEY_ENTER */ +#ifdef PADENTER /* PDCURSES */ + case PADENTER: + c = '\n'; + break; +#endif /* PADENTER */ #ifdef KEY_END case KEY_END: /* end key 001 */ c = END_KEY; --- lynx2-8-2/docs/pdcurses.key Wed Feb 17 06:29:34 1999 +++ lynx2-8-2/docs/pdcurses.key.new Mon Apr 19 22:49:08 1999 @@ -51,7 +51,6 @@ CTL_END 0x1c0 /* Control-End */ KEY_B2 0x1c5 /* center on Virt. keypad */ PADSLASH 0x1ca /* slash on keypad */ -PADENTER 0x1cb /* enter on keypad */ CTL_PADENTER 0x1cc /* ctl-enter on keypad */ ALT_PADENTER 0x1cd /* alt-enter on keypad */ PADSTOP 0x1ce /* stop on keypad */ __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Apr 20 10:48:29 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA09372 for ; Tue, 20 Apr 1999 10:48:24 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA03669; Tue, 20 Apr 1999 09:32:18 -0500 (CDT) Date: Tue, 20 Apr 1999 09:32:14 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev bookmarks and remove()/COPY_PATH/MV_PATH (was: Win32 docs patch) In-Reply-To: <199904201344.HAA23818@sanitas> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 858 Lines: 25 On Tue, 20 Apr 1999 pg@sweng.stortek.com wrote: > In a recent note, Klaus Weide said: > > > Date: Tue, 20 Apr 1999 08:09:12 -0500 (CDT) > > > > Maybe, although using rename() for situations where it does work would > > be preferable, even for Unix. [Maybe there are some situations involving > > symlinks where rename would be bad.] > > > Not only symlinks, but even more, hard links can give problems here. > Some applications refuse to manipulate multiply-linked files for > this reason. > > And rename may cause undesired changes to file permissions. I > submitted a patch regarding this quite a while back, which was > partially integrated. > > And there's the possibility that in a captive account the > user may have authority to update a file but not to change the > directory containing it. I withdraw the "would be preferable"... Klaus From owner-lynx-dev@sig.net Tue Apr 20 10:56:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA09669 for ; Tue, 20 Apr 1999 10:56:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA02769; Tue, 20 Apr 1999 09:30:01 -0500 (CDT) Date: Tue, 20 Apr 1999 09:29:56 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 809 Lines: 22 On Tue, 20 Apr 1999, Ismael Cordeiro wrote: > BOXVERT and BOXHORi only work with curses/ncurses, not with slang. I think > that they should be extended to slang, if possible. Lynx with slang just uses SLsmg_draw_box(). I don't know of an interface to tell slang what box drawing chars to use in that function. They seem to be hardwired. > And a BOXCORNER would be nice too. None of them should be necessary if terminfo files had the right content and people used the right term type... Well the terminfo language isn't really expressive enough for all situations. For the linux console, the display font can change during run time, some fonts support the drawing chars and others don't. One would have to change the term type at run time in order to always have the right capability info. Klaus From owner-lynx-dev@sig.net Tue Apr 20 10:59:50 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id KAA09902 for ; Tue, 20 Apr 1999 10:59:48 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA07929; Tue, 20 Apr 1999 09:43:43 -0500 (CDT) Date: Tue, 20 Apr 1999 10:42:59 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904201042.AA9000@cas.org> Subject: Re: lynx-dev The From: field when sending email In-Reply-To: Your message of Tue, 20 Apr 1999 10:20:14 -0400 (EDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 576 Lines: 12 Re: difference between .lynxrc setting of address and what people see appearing One of the things that may be wrong is the lynx doc - I am uncertain whether all mail delivery programs treat user specified from information as 'sacred' or if some/most/all have the ability to reformat into preferred formats. -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 20 11:03:10 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA09991 for ; Tue, 20 Apr 1999 11:03:07 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA06292; Tue, 20 Apr 1999 09:39:32 -0500 (CDT) To: lynx-dev@sig.net References: <1Cy0jCAaxGH3EwbQ@freeuk.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 20 Apr 1999 16:28:46 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Win32 docs patch (was: Lynx and downloading files) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1375 Lines: 28 20-Apr-99 13:00 Don Adaway wrote: > As the user mentioned above may I make a comment? The problem was self- > inflicted. My original intention was to ensure that downloaded files > arrived in a directory of my choice. I had discovered that files were > being downloaded to the working directory. This was \lynx by default > and because this directory contains the all-important Lynx binaries I > preferred that they go elsewhere. Accordingly I changed the working > directory, but this had the effect that cp.exe (in the \lynx directory) a working directory and a PATH - two big differences. > was no longer on the path and another program called cp.exe (in the > path) was being executed. This would not have happened had I understood > the significance of the working directory, the path, and the existence > of the SAVE_SPACE variable in the behaviour of Lynx. > The only place where the existence of the SAVE_SPACE variable is > mentioned is in the lynx.cfg file itself; none of the help files mention > it that I can find. I feel that mention of the possible interaction > between working directory, path and SAVE_SPACE should appear somewhere; > possibly comment lines in lynx.cfg would do the trick. It's all obvious > when you know, but then perhaps I'm the only person stupid enough to > have had this problem. > -- > Don chervil @ freeuk . com From owner-lynx-dev@sig.net Tue Apr 20 11:04:24 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA10005 for ; Tue, 20 Apr 1999 11:04:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA05971; Tue, 20 Apr 1999 09:38:41 -0500 (CDT) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Tue, 20 Apr 1999 18:25:34 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev dev.22 patch 2 - userdefs et al MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 569 Lines: 13 20-Apr-99 07:30 Klaus Weide wrote: > The below doesn't deal with userdefs.h de-MUSTification (mentioned > in another message) at all - I'll gladly leave that to Henry :) > Other remarks: > - Does it make sense to store/read partial_thres in/from .lynxrc at all? It make sence to store commaind line -partial_thres value permanently when save .lynxrc from the Options Menu. But this is so hidden and nonintuitive (and even don't work with DJGPP port by some unknown reason) we should avoid it. I personally hide any .lynxrc options NOT available from Options Menu. From owner-lynx-dev@sig.net Tue Apr 20 11:14:46 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA10333 for ; Tue, 20 Apr 1999 11:14:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA13962; Tue, 20 Apr 1999 09:59:46 -0500 (CDT) Date: Tue, 20 Apr 1999 10:59:02 -0400 (EDT) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9904201059.AA9994@cas.org> Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: Your message of Tue, 20 Apr 1999 09:29:56 -0500 (CDT) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 339 Lines: 6 Anyone have some HTML that would test the box drawing function of lynx? -- Larry W. Virden <*> O- "No one is what he seems." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. From owner-lynx-dev@sig.net Tue Apr 20 11:24:36 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA10635 for ; Tue, 20 Apr 1999 11:24:35 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA17890; Tue, 20 Apr 1999 10:09:45 -0500 (CDT) Date: Tue, 20 Apr 1999 10:09:40 -0500 (CDT) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: <199904200221.LAA27257@ibr1.irm.nara.kindai.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2856 Lines: 63 On Tue, 20 Apr 1999, Henry Nelson wrote: > > > ! Step 1. (define compile-time variables) > [...] > > > ! this file, and the changes should be straight forward. If you compile > > > ! using autoconfigure, you should set defines with option switches and not > > > ! edit userdefs.h directly. [ ..... ] > Tom, and others, could you comment on this "editing of userdefs.h" change. > It was my impression that there WAS no longer a need to edit userdefs.h, and > that some of you never do anymore. Should I leave it the way it is, or > should I make the change, but emphasize that if you don't edit userdefs.h, > you absolutely must edit lynx.cfg? I don't know whether the goal is to replace *all* userdefs.h settings that are not just defaults for lynx.cfg stuff with ./configure flags. It seems a bit pointless to me. But anyway, as things are currently it should be at least recommended that people SHOULD look at userdefs.h, especially if they install lynx for the first time (and are therefore most likely to read INSTALLATION). If "some of us" never edit userdefs.h anymore, that would be (ideally) only because we know what's in there, and have decided that we don't need/want to make any change. For the things that are just defaults for lynx.cfg stuff, the point could be made that after setting up everything as wanted in userdefs.h, the runtime lynx.cfg can then be shortened to near-nothing. > > > ! Step 3. (You may skip this step if you use only English and are not interested > > > ! in any special characters, or if your display and local files will all use > > ^ > > ...and all visited Web pages... > > > > > ! the ISO-8859-1 "ISO Latin 1" Western European character set.) People who > > Would it work to be more general rather than define all situations, i.e., > > "You may skip this step if you use only English, are not interested > in any special characters, and will only view documents in the ISO-8859-1 > (ISO Latin 1) Western European character set." > > or even more simply, > > "You may skip this step if you use only English." I find that last one definitely too short - even people who "use only English" can expect to see a copyright character as such etc. They may even expect to see accents on French text correctly, although they "use" only English. Your first variant doesn't take care of French, German, etc. users on completely ISO-8859-1 systems with Latin 1 displays - if they fulfil all those conditions, they should be allowed to skip, too. :) It also doesn't explicitly mention local files - they should be mentioned since practically no DOS systems are set up for ISO-8859-1 (whether English-language or not). I think the conditions SHOULD look a bit scary... Klaus From owner-lynx-dev@sig.net Tue Apr 20 11:36:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id LAA11026 for ; Tue, 20 Apr 1999 11:36:17 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA22498; Tue, 20 Apr 1999 10:21:32 -0500 (CDT) From: dickey@clark.net Message-Id: <199904201520.LAA12834@shell.clark.net> Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 11:20:53 -0400 (EDT) In-Reply-To: <9904201059.AA9994@cas.org> from "lvirden@cas.org" at Apr 20, 99 10:59:02 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 288 Lines: 11 > > Anyone have some HTML that would test the box drawing function of lynx? forms. (I see this every time I go to deja-news since I use the popup) > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 20 12:12:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA12683 for ; Tue, 20 Apr 1999 12:12:22 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA28916; Tue, 20 Apr 1999 10:38:27 -0500 (CDT) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 20 Apr 1999 19:37:06 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev (patch) owner_address and HTreparse_document() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 708 Lines: 19 Tiny mainloop fix (the pointer to HTextMain became broken when HTreparse_document() update HText, let alloc a copy instead of duplicating the statement for special case:) diff -u old/lymainlo.c ./lymainlo.c --- old/lymainlo.c Mon Apr 19 19:06:52 1999 +++ ./lymainlo.c Tue Apr 20 19:14:30 1999 @@ -1036,7 +1036,7 @@ } else if (!dump_output_immediately) { StrAllocCopy(curdoc.title, newdoc.title); } - owner_address = (char *)HText_getOwner(); + StrAllocCopy(owner_address, HText_getOwner()); curdoc.safe = HTLoadedDocumentIsSafe(); if (!dump_output_immediately) { LYAddVisitedLink(&curdoc); From owner-lynx-dev@sig.net Tue Apr 20 12:15:12 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA12889 for ; Tue, 20 Apr 1999 12:15:03 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA03379; Tue, 20 Apr 1999 10:50:21 -0500 (CDT) Date: Tue, 20 Apr 1999 11:50:26 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1465 Lines: 37 On Tue, 20 Apr 1999, Klaus Weide wrote: > > BOXVERT and BOXHORi only work with curses/ncurses, not with slang. I > > think that they should be extended to slang, if possible. > > Lynx with slang just uses SLsmg_draw_box(). I don't know of an interface > to tell slang what box drawing chars to use in that function. They seem to > be hardwired. If it's really not possible, then we'll live with it. > > And a BOXCORNER would be nice too. > > None of them should be necessary if terminfo files had the right content > and people used the right term type... The problem is that not all terminal emulators support alternate character sets. > Well the terminfo language isn't really expressive enough for all > situations. For the linux console, the display font can change during run > time, some fonts support the drawing chars and others don't. One would > have to change the term type at run time in order to always have the right > capability info. Do you mean that terminfo has been "abused" long before I used color capabilities in the VT100 definition? I feel better now... :-) Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 12:30:54 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id MAA13624 for ; Tue, 20 Apr 1999 12:30:53 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA12179; Tue, 20 Apr 1999 11:14:07 -0500 (CDT) Date: Tue, 20 Apr 1999 12:14:06 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 872 Lines: 23 dickey@clark.net wrote: >> You might also want to see wether term=vt240 works, as, I believe, this >> was the first colour terminal in Digital's VTxxx series. > >it doesn't use the ANSI controls. > >afaik, the first one that applies to ise the VT525, which was designed as a >clone of the Wyse 375. The weird thing is that the VT525 is a color terminal but its termcap and terminfo definitions in DEC's ftp site don't have color capabilities. Does that make the VT525 a "contradictory" terminal? Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 17:42:03 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA25711 for ; Tue, 20 Apr 1999 17:42:02 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA09561; Tue, 20 Apr 1999 16:28:22 -0500 (CDT) From: dickey@clark.net Message-Id: <199904202127.RAA18687@shell.clark.net> Subject: Re: lynx-dev removing strings used in CTRACE when configured without To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 17:27:51 -0400 (EDT) In-Reply-To: <9904201303.aa28148@deepthought.armory.com> from "Bela Lubkin " at Apr 20, 99 01:03:40 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 998 Lines: 28 > > Vlad Harchev wrote: > > > BTW, I explored cccp today. IMO it won't be easy to hack it so it that it can > > be compiled standalone (and be compact) - probably separate subdir, > > Makefile.in will be reqired, and I afraid, this will be about (optimistically) > > 600 KB... > > Adding 600KB of cpp source to the Lynx source distribution is an > unreasonable way to solve this problem. We already have the example > from future libwww development, as a portable way to fix CTRACE. > Meanwhile, if the excess strings bother gcc users, use a local preparser > (like your lexer) -- or fix gcc! > > >Bela< this is becoming an faq (perhaps I should make a lynx-dev.faq.html to answer questions on lynx-dev ;-) The change I have in mind won't get done til after 2.8.2, since it would needlessly touch a lot of stable code. Not all of the trace code is inside the CTRACE macros; those have to be revisited. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 20 17:46:00 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id RAA25970 for ; Tue, 20 Apr 1999 17:45:57 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA13143; Tue, 20 Apr 1999 16:36:38 -0500 (CDT) From: dickey@clark.net Message-Id: <199904202136.RAA20381@shell.clark.net> Subject: Re: lynx-dev Lynx, colors and VT100 To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 17:36:29 -0400 (EDT) In-Reply-To: from "Ismael Cordeiro " at Apr 20, 99 12:14:06 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 565 Lines: 15 > The weird thing is that the VT525 is a color terminal but its termcap and > terminfo definitions in DEC's ftp site don't have color capabilities. Does > that make the VT525 a "contradictory" terminal? not at all. DEC's VMS files for this stuff only got updated to show color in mid-1995, not long before they gave (sorry "sold") away their terminal business. The latest terminfo I've seen for the same terminals were dated before that - they don't get updated _that_ often. > Ismael -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Apr 20 19:23:45 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA29133 for ; Tue, 20 Apr 1999 19:23:44 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA17211; Tue, 20 Apr 1999 18:12:14 -0500 (CDT) From: Bela Lubkin Date: Tue, 20 Apr 1999 16:11:12 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev screen widths Message-ID: <9904201611.aa25031@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1479 Lines: 34 Philip Webb wrote: > thanx everyone who responded to my questions about screen widths, > something not previously explored on lynx-dev IIRC. > there seem to be 2 results, but little consensus. > > (1) 5 people regularly use a display > 79 columns : > 3 express strong feelings that their freedom is at stake > if someone cuts line off short of a paragraph end, > 2 of whom know Lynx too well to consult documentation frequently; > 2 don't seem to have strong feeling about it. > only 1 uses a window of 45 - 50 columns for documentation, > tho' not frequently for Lynx. > 1 hardly ever uses displays <> 79 columns ; > presumably, most other users don't either. I can't add up your numbers since they apply to overlapping groups; but at least 5 users use wide displays, and only one "hardly ever uses displays <> 79 columns". So _at least_ 83% of responses indicate that they use nonstandard screen widths. From this you conclude: "presumably, most other users don't [use nonstandard screen widths] either". You must work for a political polling organization. > in the absence of style-sheets in the near future, > i'ld say L/R columns in the screen display should be configurable > via an Option, but of course someone has to do the coding (BL?). It troubles me slightly, but definitely not enough to do anything about it. The loss of a few columns out of a 100 or 120 column screen isn't important. >Bela< From owner-lynx-dev@sig.net Tue Apr 20 19:28:01 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id TAA29363 for ; Tue, 20 Apr 1999 19:28:00 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA19794; Tue, 20 Apr 1999 18:20:38 -0500 (CDT) From: mattack@area.com Date: Tue, 20 Apr 1999 16:20:35 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: <199904200541.XAA20718@sanitas> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1705 Lines: 44 On Mon, 19 Apr 1999 pg@sweng.stortek.com wrote: >Date: Mon, 19 Apr 1999 23:41:35 -0600 (MDT) >From: pg@sweng.stortek.com >Reply-To: lynx-dev@sig.net >To: lynx-dev@sig.net >Subject: Re: lynx-dev Lynx, colors and VT100 > >In a recent note, Ismael Cordeiro said: > >> Date: Mon, 19 Apr 1999 22:13:21 -0400 (EDT) >> >> > then a "vt100 emulator" cannot support color, because it is no longer a >> > vt100 emulator. >> >> `A la lettre, you're right but they are VT100 emulators _and_ support color. >> >One thing that matters is that not only must the "emulator" support color, >but curses must support generating the color escape sequences for that >emulator, which means in turn that the termcap/terminfo for that >TERM type must define those color escape sequences. This is likely >not to be under the control of the "emulator" author. I think this is an argument that probably is useless, because Ismael still doesn't seem to realize that "vt100 emulator" _implies_ that it does not emulate things _besides_ a vt100. (That is, it implies strict emulation.) Anyhow, I actually have a question about this color stuff now that there has been discussion about it.. I'm using Lynx Version 2.8.1rel.2 (1998) I think I'm on Solaris.. (dang I never remember how to check..) In the Options, I can pick different choices for the Show Color popup, but it always goes back to OFF no matter what I pick.. Does this mean it wasn't compiled with Color support in, or what? Is there any way this could be improved so that the other items said or something while I had the popup popped up? even if it said something longer like it would be good. From owner-lynx-dev@sig.net Tue Apr 20 20:41:08 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id UAA31648 for ; Tue, 20 Apr 1999 20:41:06 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA10761; Tue, 20 Apr 1999 19:31:05 -0500 (CDT) Date: Tue, 20 Apr 1999 20:31:12 -0400 (EDT) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2482 Lines: 64 On Tue, 20 Apr 1999 mattack@area.com wrote: > I think this is an argument that probably is useless, because Ismael still > doesn't seem to realize that "vt100 emulator" _implies_ that it does not > emulate things _besides_ a vt100. (That is, it implies strict emulation.) I do realize that a `"vt100 emulator" _implies_ that it does not emulate things _besides_ a vt100' but I was not the one who called those terminal emulators VT100 or VT102. They emulate VT100 and VT102 terminals and give me more. Like you, I want Lynx in color and the terminal emulation in the program I use, although called "VT102", support color. Why wouldn't I care how it's called if I can have Lynx and other programs in colors with it? > Anyhow, I actually have a question about this color stuff now that there > has been discussion about it.. > > I'm using > Lynx Version 2.8.1rel.2 (1998) > > I think I'm on Solaris.. (dang I never remember how to check..) uname -sr If you're on Solaris it should display "SunOs 5.x". > In the Options, I can pick different choices for the Show Color popup, but > it always goes back to OFF no matter what I pick.. > > Does this mean it wasn't compiled with Color support in, or what? If you're actually on Solaris, probably Lynx was compiled with SVR4 curses and consequently with color support. > Is there any way this could be improved Yes, there is... > so that the other items said or something while I had the > popup popped up? even if it said something longer like BECAUSE COLOR NOT COMPILED IN> it would be good. If you use the "old-style" options menu (FORMS_OPTIONS:FALSE in lynx.cfg), Lynx will display "Your 'xxx' terminal does not support color" when you try to set Show Color to ON. If you don't mind being helped by someone you think that `doesn't seem to realize that "vt100 emulator" _implies_ that it does not emulate things _besides_ a vt100', I could probably help you like I helped many Lynx users with a similar problem. What terminal or terminal emulation are you using? Does it support color? What "echo $TERM" says? Ismael -- +--------------------------------------------------------------+ | ISMAEL CORDEIRO | mailto:ismael@cordeiro.com | | Production sound mixer | http://www.ismael.cordeiro.com/ | | Montréal - Québec - Canada | ftp://ftp.cam.org/users/ismael/ | +--------------------------------------------------------------+ From owner-lynx-dev@sig.net Tue Apr 20 21:11:27 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id VAA32713 for ; Tue, 20 Apr 1999 21:11:26 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA20373; Tue, 20 Apr 1999 20:05:08 -0500 (CDT) From: mattack@area.com Date: Tue, 20 Apr 1999 18:05:04 -0700 (PDT) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx, colors and VT100 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2450 Lines: 61 On Tue, 20 Apr 1999, Ismael Cordeiro wrote: >> I think I'm on Solaris.. (dang I never remember how to check..) > >uname -sr > >If you're on Solaris it should display "SunOs 5.x". SunOS 5.6 >> so that the other items said or something while I had the >> popup popped up? even if it said something longer like > BECAUSE COLOR NOT COMPILED IN> it would be good. > >If you use the "old-style" options menu (FORMS_OPTIONS:FALSE in lynx.cfg), >Lynx will display "Your 'xxx' terminal does not support color" when you try >to set Show Color to ON. lynx.cfg is for compile time options right? I tried simply making a lynx.cfg in my home directory with FORMS_OPTIONS:FALSE as the only thing in it and it doesn't seem to change anything. Anyway, I just realized that when I'm on the popup it says: UNMODIFIABLE option list. Use return or arrow keys to review or leave. at the bottom of the screen. >If you don't mind being helped by someone you think that `doesn't seem to >realize that "vt100 emulator" _implies_ that it does not emulate things >_besides_ a vt100', I could probably help you like I helped many Lynx users >with a similar problem. Wow, I didn't mean to make that sound like an insult, I just think both sides are unable to agree. (I'm making the semantic point about words, admittedly.) >What terminal or terminal emulation are you using? Does it support color? >What "echo $TERM" says? heh.. vt100. The 'real' vt100 in /etc/termcap says: d0|vt100|vt100-am|vt100am|dec vt100:\ :do=^J:co#80:li#24:cl=50\E[;H\E[2J:sf=5\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ :rf=/usr/share/lib/tabset/vt100:\ :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=5\EM:vt#3:xn:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: I have no idea how to read that stuff (I'm not saying it's hard, I just never figured out any of it except for things like changing backspace to delete with stty and changing rows manually). I realized there are a lot of other "vt100-ish" entries in /etc/termcap, mentioning things like "fast v100".. Maybe some decade if I ever get around to it I should play around with some of the others to see if I can notice a difference over a modem link. From owner-lynx-dev@sig.net Tue Apr 20 22:04:57 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA01749 for ; Tue, 20 Apr 1999 22:04:57 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA05271; Tue, 20 Apr 1999 20:56:14 -0500 (CDT) Date: Wed, 21 Apr 1999 11:07:48 +0900 (JST) From: Henry Nelson Message-Id: <199904210207.LAA29343@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev userdefs.h vs. configure (was: INSTALLATION file changes) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 929 Lines: 21 > Going through userdefs.h I found the following definitions, for which > some setting cannot be deferred to lynx.cfg, and which cannot be done > as ./configure flags Thanks. You've done all the work! > #define NO_ANONYMOUS_EMAIL TRUE > /* #define PERMIT_GOTO_FROM_JUMP */ > #define LY_UMLAUT [ does this still have an effect at all? ] > /* #define ALLOW_USERS_TO_CHANGE_EXEC_WITHIN_OPTIONS */ > /* #define NEVER_ALLOW_REMOTE_EXEC */ > #define LOCAL_EXECUTION_LINKS_ALWAYS_OFF_FOR_ANONYMOUS FALSE > Stuff in sections 3 and 4 This brings back memories now of why I reorganized userdefs.h. I think with more careful wording I can safely steer first-time installers on Un*x away from editing userdefs.h. Unfortunately, I highly doubt I will be able to get into userdefs.h this time around. I still think I will have time to revise my proposed "fixes" to INSTALLATION and send them in. __Henry From owner-lynx-dev@sig.net Tue Apr 20 22:44:02 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA02886 for ; Tue, 20 Apr 1999 22:44:01 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA17234; Tue, 20 Apr 1999 21:36:12 -0500 (CDT) Date: Wed, 21 Apr 1999 11:47:51 +0900 (JST) From: Henry Nelson Message-Id: <199904210247.LAA29460@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1731 Lines: 39 > > > > ! using autoconfigure, you should set defines with option switches a ^^^^^^ This "should" will definitely go. > But anyway, as things are currently it should be at least recommended > that people SHOULD look at userdefs.h, especially if they install lynx > for the first time (and are therefore most likely to read INSTALLATION). Excellent point. This makes me reconsider my previous reply. > be made that after setting up everything as wanted in userdefs.h, the > runtime lynx.cfg can then be shortened to near-nothing. I'd like to see this comment in lynx.cfg and/or userdefs.h. I'd rather have "veterans" doing this. One problem I have with the "new" Lynx is that you have to "trick" configure now so that it doesn't install that 90kB distribution lynx.cfg automatically on your system. Giving all those hints in INSTALLATION is more than I can do, as much as I hate leaving installers in the dark about what Lynx has in store for them. As it stands now, if you only edit lynx.cfg without deleting the text and unneeded defines, 180kB gets installed! > I find that last one definitely too short - even people who "use only [...] > Your first variant doesn't take care of French, German, etc. users French, German, etc. users are smart enough to know when to skip things. The patsy stuff is mostly for Americans :) > It also doesn't explicitly mention local files - they should be > mentioned since practically no DOS systems are set up for ISO-8859-1 > (whether English-language or not). > > I think the conditions SHOULD look a bit scary... Anyway, thanks. At least now I have a better understanding of why that parenthetical information has to be so long. __Henry From owner-lynx-dev@sig.net Tue Apr 20 22:49:52 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id WAA03164 for ; Tue, 20 Apr 1999 22:49:46 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA19355; Tue, 20 Apr 1999 21:43:21 -0500 (CDT) Date: Wed, 21 Apr 1999 11:54:34 +0900 (JST) From: Henry Nelson Message-Id: <199904210254.LAA29504@ibr1.irm.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev INSTALLATION file changes (was: Fix --disable-trace, #includes) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 305 Lines: 7 > > > BOXVERT and BOXHORi only work with curses/ncurses, not with slang. I I have Lynx compiled with slang, and I DO get the box characters, including the corners. Your terminfo or termcap description probably don't have them defined. (It's pretty much the same problem you have with colors.) __Henry From owner-lynx-dev@sig.net Tue Apr 20 23:09:55 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id XAA03777 for ; Tue, 20 Apr 1999 23:09:54 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA25167; Tue, 20 Apr 1999 22:03:10 -0500 (CDT) Date: Tue, 20 Apr 1999 20:03:05 -0700 (PDT) From: Doug Kaufman X-Sender: dkaufman@waltz To: Russ Kiehne Cc: lynx-dev@sig.net Subject: Re: lynx-dev Lynx In-Reply-To: <19990420153951359.AAA121@mail.141.com@n135.alameda.community.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1167 Lines: 31 On Tue, 20 Apr 1999, Russ Kiehne wrote: > Hi Wayne, I am not sure that Wayne is following lynx-dev regularly any more. > I downloaded: lynx_w32.zip A compiled Win32 Lynx.exe, lynx.cfg, > cp.exe, mv.exe and sendmail.exe along with some config info. > For some reason, I cannot get the bookmark file to work. Maybe you can > tell me what is wrong. Here is my lynx.bat: > @ECHO OFF > set home=d:\win32 > set temp=d:\win32 > set lynx_cfg=d:\win32\lynx.cfg > d:\win32\lynx.exe %1 %2 %3 %4 %5 I have lynx_w32 working on my Win98 system, and would be willing to try to help. You didn't give us enough information. What to you mean that the bookmark file doesn't work? What is the setting for your bookmark file (go to the option menu by typing "o" and tell us what it says under both Multi-bookmarks and Bookmarks file). Did you try to create a bookmark file by saving a link or document with the "a" command? The bookmark file is very sensitive to format. Do you reach the bookmark file with the "v" command? If not, what message do you see? Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Wed Apr 21 02:54:30 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id CAA10854 for ; Wed, 21 Apr 1999 02:54:27 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA29116; Wed, 21 Apr 1999 01:42:43 -0500 (CDT) To: lynx-dev@sig.net Message-Id: MIME-Version: 1.0 Organization: Private Person" From: "Igor B. Poretsky" Date: Wed, 21 Apr 99 09:50:57 +0400 Subject: lynx-dev Dired_support under MSDOS X-mailer: PostMan v0.96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6082 Lines: 184 Hello! I tried to compile Lynx by DJGPP under MSDOS with dired_support enabled, but failed. I'd like to suggest the next patch to resolve this problem. This patch can be applied to the version 2.8.2dev.22. Among the other things, I doubt that changes which I made in the file lymainloop.c are absolutely correct. But without it any attempt to activate link "up to parrent directoru" ended by exiting Lynx with the error message if that parrent directory was the root directory on any local disk. Maybe, some of you could suggest anything better. With great respect, Igor. diff -rc lynx2-8-/src/lyglobal.h e:/tcpip/browsers/lynx/src/lynx2-8-/src/lyglobal.h *** lynx2-8-/src/lyglobal.h Tue Apr 13 09:39:16 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/src/lyglobal.h Tue Apr 13 02:14:28 1999 *************** *** 57,62 **** --- 57,63 ---- extern BOOLEAN no_dired_support; extern int dir_list_style; extern HTList *tagged; + #define DIRECTORIES_FIRST 0 #define FILES_FIRST 1 #define MIXED_STYLE 2 #ifdef OK_OVERRIDE diff -rc lynx2-8-/src/lylocal.c e:/tcpip/browsers/lynx/src/lynx2-8-/src/lylocal.c *** lynx2-8-/src/lylocal.c Tue Mar 30 17:10:36 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/src/lylocal.c Tue Apr 13 02:14:34 1999 *************** *** 1364,1369 **** --- 1364,1379 ---- that need it. Don't forget to FREE it. */ tp = NULL; + #ifdef __MSDOS__ + if (!strncmp(line, "LYNXDIRED://", 12)) { + char *s; + int i; + s = index(&line[12], '/'); + if(s!=NULL) + for(i=0; s[i]!=0; i++) + s[i] = s[i+1]; + } + #endif if (!strncmp(line, "LYNXDIRED://NEW_FILE", 20)) { if (create_file(&line[20]) > 0) LYforce_no_cache = TRUE; *************** *** 2049,2054 **** --- 2059,2077 ---- rc = 1; /* It will work */ stop_curses(); + #ifdef __MSDOS__ + { + int n; + char *the_command = 0; + + HTSprintf(&the_command, "%s", path); + for (n = 1; argv[n] != 0; n++) + HTSprintf(&the_command, " %s", argv[n]); + HTSprintf(&the_command, "\n"); + rc = LYSystem(the_command) ? 0 : 1; + free(the_command); + } + #else pid = fork(); /* fork and execute rm */ switch (pid) { case -1: *************** *** 2086,2091 **** --- 2109,2115 ---- rc = 0; } } + #endif /* MSDOS */ if (rc == 0) { /* diff -rc lynx2-8-/src/lymain.c e:/tcpip/browsers/lynx/src/lynx2-8-/src/lymain.c *** lynx2-8-/src/lymain.c Tue Apr 13 09:39:16 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/src/lymain.c Tue Apr 13 02:14:42 1999 *************** *** 90,96 **** #ifdef DIRED_SUPPORT PUBLIC BOOLEAN lynx_edit_mode = FALSE; PUBLIC BOOLEAN no_dired_support = FALSE; ! PUBLIC int dir_list_style = MIXED_STYLE; PUBLIC HTList *tagged = NULL; #ifdef OK_OVERRIDE PUBLIC BOOLEAN prev_lynx_edit_mode = FALSE; --- 90,96 ---- #ifdef DIRED_SUPPORT PUBLIC BOOLEAN lynx_edit_mode = FALSE; PUBLIC BOOLEAN no_dired_support = FALSE; ! PUBLIC int dir_list_style = DIRECTORIES_FIRST; PUBLIC HTList *tagged = NULL; #ifdef OK_OVERRIDE PUBLIC BOOLEAN prev_lynx_edit_mode = FALSE; diff -rc lynx2-8-/src/lymainlo.c e:/tcpip/browsers/lynx/src/lynx2-8-/src/lymainlo.c *** lynx2-8-/src/lymainlo.c Tue Apr 13 09:39:16 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/src/lymainlo.c Tue Apr 13 02:29:58 1999 *************** *** 3471,3477 **** psrc_view = FALSE; /* we get here if link is not internal */ #endif ! #ifdef DIRED_SUPPORT if (lynx_edit_mode) { HTuncache_current_document(); /* --- 3471,3477 ---- psrc_view = FALSE; /* we get here if link is not internal */ #endif ! #if defined(DIRED_SUPPORT) && !defined(__MSDOS__) if (lynx_edit_mode) { HTuncache_current_document(); /* *************** *** 3482,3488 **** HTUnEscapeSome(newdoc.address,"/"); strip_trailing_slash(newdoc.address); } ! #endif /* DIRED_SUPPORT */ if (!strncmp(curdoc.address, "LYNXCOOKIE:", 11)) { HTuncache_current_document(); } --- 3482,3488 ---- HTUnEscapeSome(newdoc.address,"/"); strip_trailing_slash(newdoc.address); } ! #endif /* DIRED_SUPPORT and not MSDOS */ if (!strncmp(curdoc.address, "LYNXCOOKIE:", 11)) { HTuncache_current_document(); } diff -rc lynx2-8-/src/lyutils.c e:/tcpip/browsers/lynx/src/lynx2-8-/src/lyutils.c *** lynx2-8-/src/lyutils.c Tue Apr 13 09:39:16 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/src/lyutils.c Tue Apr 13 02:15:10 1999 *************** *** 2051,2057 **** #ifdef USE_SLANG if (!LYCursesON) fd = fileno(stdin); ! #if SLANG_VERSION >= 9919 /* SLang_TT_Read_FD introduced in slang 0.99.19, from its changelog: * SLang_TT_Read_FD variable is now available for unix. This is the file * descriptor used by SLang_getkey. */ --- 2051,2057 ---- #ifdef USE_SLANG if (!LYCursesON) fd = fileno(stdin); ! #if (defined REAL_UNIX_SYSTEM) && (SLANG_VERSION >= 9919) /* SLang_TT_Read_FD introduced in slang 0.99.19, from its changelog: * SLang_TT_Read_FD variable is now available for unix. This is the file * descriptor used by SLang_getkey. */ Only in e:/tcpip/browsers/lynx/src/lynx2-8-: userdefs.h~ diff -rc lynx2-8-/www/library/implemen/htdos.c e:/tcpip/browsers/lynx/src/lynx2-8-/www/library/implemen/htdos.c *** lynx2-8-/www/library/implemen/htdos.c Wed Jan 13 11:37:34 1999 --- e:/tcpip/browsers/lynx/src/lynx2-8-/www/library/implemen/htdos.c Tue Apr 13 02:15:38 1999 *************** *** 2,7 **** --- 2,8 ---- */ + #include #include #include *************** *** 81,84 **** --- 82,91 ---- CTRACE(tfp, "HTDOS_name changed `%s' to `%s'\n", wwwname, result); return (result); + } + /* DJGPP doesn't have `lstat', since MS-DOS doesn't + support links. Here's a trivial substitute that will do. */ + int lstat (const char *fname, struct stat *st_buf) + { + return stat (fname, st_buf); } From owner-lynx-dev@sig.net Wed Apr 21 03:04:18 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA11190 for ; Wed, 21 Apr 1999 03:04:16 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA00494; Wed, 21 Apr 1999 01:56:44 -0500 (CDT) From: David Woolley Message-Id: <199904200733.IAA04504@djwhome.demon.co.uk> Subject: Re: lynx-dev from "Hans Georg Schaathun" at Apr 20, 99 00:31:32 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 139 Lines: 6 > > Then I found that lynx plainly ignores hidden input fields. Not true of any Lynx that I have tried it on. Please supply an example. From owner-lynx-dev@sig.net Wed Apr 21 03:04:34 1999 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by calcutta.flora.ottawa.on.ca (8.9.3/8.9.3) with ESMTP id DAA11200 for ; Wed, 21 Apr 1999 03:04:32 -0400 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA00508; Wed, 21 Apr 1999 01:56:50 -0500 (CDT) From: David Woolley Message-Id: <199904200750.IAA04550@djwhome.demon.co.uk> Subject: lynx-dev 2.4 Hangs for hidden fields only form (was: Lynx Question) To: lynx-dev@sig.net Date: Tue, 20 Apr 1999 08:50:49 +0100 (BST) In-Reply-To: <199904191846.NAA22441@roadrunner.sig.net> from "Cynthia Griffiths" at Apr 19, 99 06:46:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1433 Lines: 38 Your subject was of no value. > I am using Lynx 2.4-FM on an digital alpha running VMS This is so obsolete as to be totally unsupported. > > When I run the following code: > > Link page >