From owner-lynx-dev@sig.net Sat Oct 31 19:22:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA09443 for ; Sat, 31 Oct 1998 19:22:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA01682; Sat, 31 Oct 1998 18:06:31 -0600 (CST) Date: Sun, 1 Nov 1998 09:09:35 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811010009.JAA28041@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Autoconf patch for S/390 (EBCDIC) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 330 Lines: 8 > Richard Stallman deems mainframes too far from the mainstream. Our school has permanently "mothballed" what I think is a mainframe, a Fujitsu M770/6 (F8470A6). The electricity required to run it costs too much, and none of the software is y2k compatible, I am told. Should I latch on to it? Could it be made useful? __Henry From owner-lynx-dev@sig.net Sat Oct 31 20:06:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA12037 for ; Sat, 31 Oct 1998 20:06:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA06448; Sat, 31 Oct 1998 18:52:16 -0600 (CST) Date: Sat, 31 Oct 1998 19:53:32 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9810311953.AA20084@cas.org> Subject: lynx-dev lynx 2.8.1 patch 2 core dump To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1762 Lines: 32 I was browsing around the net . I am uncertain what site I was on at the time of the crash - the last site I bookmarked was
  • The PalmPilot Library, featuring E-Texts for the 3-Com PalmPilot, TI Avigo, Psion and WinCE I was looking thru links at electronic books for Palm Pilots. Anyways, it might have been at the above site. Anyways, I went to a page that _supposedly_ was a full list of the books available to download. The interesting thing is that though the books were labeled like the rest of the links normally are, but when I tried to go to link 37 using 37G, I got a core dump. Here is the stack trace - unfortunately it isn't from a debugging version of lynx. program terminated by signal ABRT (Abort) Current function is FatalProblem 3218 abort(); (dbx 1) where [1] _kill(0x0, 0x6, 0xef622e6c, 0x0, 0xffffffff, 0x0), at 0xef607fc4 [2] abort(0xef622e6c, 0x27, 0xef62a724, 0x2cfb50, 0x0, 0x0), at 0xef5ba500 =>[3] FatalProblem(sig = 11), line 3218 in "LYMain.c" ---- called from signal handler with signal 11 (SIGSEGV) ------ [4] HTGetLinkInfo(number = 37, want_go = 1, go_line = 0xefffd378, linknum = 0xefffd374, hightext = 0x2e81f8, lname = 0x2e81f0), line 3589 in "GridText.c" [5] follow_link_number(c = 51, cur = 0, doc = 0x2dc018, num = 0xefffd4e8), line 991 in "LYGetFile.c" [6] mainloop(), line 1759 in "LYMainLoop.c" [7] main(argc = 2, argv = 0xefffe27c), line 1686 in "LYMain.c" ( I will see if I can recreate it... -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Oct 31 21:56:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA18018 for ; Sat, 31 Oct 1998 21:56:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA18741; Sat, 31 Oct 1998 20:43:02 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811010244.TAA06047@sanitas> Subject: Re: lynx-dev Autoconf patch for S/390 (EBCDIC) To: lynx-dev@sig.net Date: Sat, 31 Oct 1998 19:44:16 +1700 (MST) In-Reply-To: <199811010009.JAA28041@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric" at Nov 1, 98 09:09: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: 649 Lines: 18 In a recent note, Nelson Henry Eric said: > Date: Sun, 1 Nov 1998 09:09:35 +0900 (JST) > > Our school has permanently "mothballed" what I think is a mainframe, > a Fujitsu M770/6 (F8470A6). The electricity required to run it > costs too much, and none of the software is y2k compatible, I am told. > > Should I latch on to it? Could it be made useful? > I'd trust their judgment about the electricity cost. And they haven't even mentioned hardware maintenance costs. Unless you need a hobby, and can get someone to pay for it. I don't know that model. A sufficiently old mainframe may fill a room and have about the power of an AT. -- gil From owner-lynx-dev@sig.net Sat Oct 31 22:12:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA19708 for ; Sat, 31 Oct 1998 22:12:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA20717; Sat, 31 Oct 1998 21:00:34 -0600 (CST) From: dickey@clark.net Message-Id: <199811010302.WAA19692@shell.clark.net> Subject: Re: lynx-dev Autoconf patch for S/390 (EBCDIC) To: lynx-dev@sig.net Date: Sat, 31 Oct 1998 22:02:21 +1900 (EST) In-Reply-To: <199811010009.JAA28041@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 1, 98 09:09:35 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: 517 Lines: 18 > > > Richard Stallman deems mainframes too far from the mainstream. > > Our school has permanently "mothballed" what I think is a mainframe, > a Fujitsu M770/6 (F8470A6). The electricity required to run it > costs too much, and none of the software is y2k compatible, I am told. > > Should I latch on to it? Could it be made useful? running computers that you don't have support for can be a little time- consuming... > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 1 00:18:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA26897 for ; Sun, 1 Nov 1998 00:18:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA04144; Sat, 31 Oct 1998 23:03:36 -0600 (CST) From: Al Gilman Message-Id: <199811010505.AAA11244@access2.digex.net> Subject: lynx-dev hangups [in DNS?] in Win 95 To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 00:05:34 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL15 (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: 778 Lines: 23 I have been having a "hung" state sometimes while following links. The display gets to the point where it says "looking up www.w3.org" followed by a blinking cursor. Using Control-G gets me out of the hangup and I can then follow the link without trouble. Now, I don't believe that the "looking up" message is strictly on the up and up because this is a site I had just visited a moment before, so the IP number should be freshly in the cache at the DNS server. The following try goes through quickly. This could have been on URLs where HTTP basic security is in effect, i.e. my Lynx is passing password information with the GET. If that has any possible bearing on the issue. Dunno if that is any use to you or not. Al this is with 2.8.1pre.9 binary from fdisk.com. From owner-lynx-dev@sig.net Sun Nov 1 00:55:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA29109 for ; Sun, 1 Nov 1998 00:55:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA07714; Sat, 31 Oct 1998 23:44:27 -0600 (CST) To: nelsonhe@nara.kindai.ac.jp, lynx-dev@sig.net References: <199811010438.HAA20542@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Sun, 1 Nov 1998 08:43:29 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx whith a special configuration 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: 2670 Lines: 61 > * From: Nelson Henry Eric >> Some features should be disabled and an new feature would be nice. > You're not the only one. :-) I know of no c programmer who is interested > in drastically reducing the size of Lynx (which is what we are talking > about, i.e., getting the image down to <400 Kb). Try using executable packers: with DOS port I now have 513K size, while it was about 2M before. and a higher optimization level: on DOS, -O3 gives 1.1M but no optimization leads to 2.1M executable (no significant difference if using packers, though). > I'm working on it, but progress is SNAIL SLOW, so don't hold your breath. > One thing, PLEASE, if you do anything at all along these lines, do inform > lynx-dev@sig.net, or at least me personally. I'll add it to my references > to the LYNX_LITE (Thanks, Al) project. >> - the browser has to start with a special URL and >> the user is not allowed to other stuff than to > My plan here is to remove all support for lynx.cfg and .lynxrc. Everything > must be compiled in (no one except a compiler/installer with a special > purpose will be fooling around with LYNX_LITE). >> - No nntp, no gopher or other stuff. > Last I tried you could simply not link in LYNews and LYMail without > having to change the code for a slight size reduction. Other > protocols can be cut out similarly, but that does require a fair > amount of modification to the code in some cases. > If you have significant coding skills, try to remove LYTraversal. >> Are threre any hints how to do the specials - so we can do it? >> Any other hints? > First, turn off all the extras you can (DIRED, LYNX_CGI, etc.) > The chartrans code nearly doubles the size of Lynx from what it was > before. Pulling that back out would be nearly impossible. Maybe > you're DonQuixote? :-) You can fairly easily tweak the Makefile No, not in makefile. You can just not include few chartrans tables in UCDomap.c, read chrtrans/readme.tab The effect not so impressive: UCDomap.o hold all tables and have a size of 260K but only 78K if packed. You can safely exclude long "mnemonics" tables, and probably all DOS cpXXX tables if you don't expect users with such display charset (but leave windows-XXXX, lots of such pages around). This may gain about 150K or 30K compressed. Other chartrans code heavily build-in. Exclude old-style options menu. > in src/chrtrans for rather significant gains, however. If you do > this, would you pass your patch by the list, please. > Reduce the size of your buffers (see userdefs.h, MAXHIST and MAXLINKS). ^^^^??? > __Henry From owner-lynx-dev@sig.net Sun Nov 1 02:06:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA00682 for ; Sun, 1 Nov 1998 02:06:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA13411; Sun, 1 Nov 1998 00:54:16 -0600 (CST) To: lynx-dev@sig.net, nelsonhe@nara.kindai.ac.jp References: <199811010438.HAA20542@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Sun, 1 Nov 1998 09:51:21 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx whith a special configuration 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: 1203 Lines: 34 > * From: Nelson Henry Eric > You're not the only one. :-) I know of no c programmer who is interested > in drastically reducing the size of Lynx (which is what we are talking > about, i.e., getting the image down to <400 Kb). > I'm working on it, but progress is SNAIL SLOW, so don't hold your breath. > One thing, PLEASE, if you do anything at all along these lines, do inform > lynx-dev@sig.net, or at least me personally. I'll add it to my references > to the LYNX_LITE (Thanks, Al) project. New "cutoff_exe.h" headers file proposed: #ifdef CUT_OFF_EXE /* Few users ask to reduce lynx executable size ("disk quota exceeded") by reducing some lynx functionality. We recommend using executable packers like gzexe instead, but probably also choose options below: name approx cutoff size (packed) */ #define NO_CHARTRANS_MNEMONICS /* ?(?) KB */ #define NO_CHARTRANS_ARABIC_AND_HEBREW /* ?(?) KB */ #define NO_CHARTRANS_DOS_CODEPAGES /* ?(?) KB */ #define NO_OPTION_MENU /* ?(?) KB */ #define NO_EXTENDED_HTMLDTD /* ?(?) KB */ /* to be continued... */ #endif /* CUT_OFF_EXE */ From owner-lynx-dev@sig.net Sun Nov 1 05:38:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA12402 for ; Sun, 1 Nov 1998 05:38:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA27541; Sun, 1 Nov 1998 04:17:01 -0600 (CST) From: David Woolley Message-Id: <199810311128.LAA04154@djwhome.demon.co.uk> Subject: Re: lynx-dev depth limit for traversal? To: lynx-dev@sig.net Date: Sat, 31 Oct 1998 11:28:09 +0000 (GMT) In-Reply-To: <199810310034.TAA13403@mercator.math.uwaterloo.ca> from "Adrian R.D. Pepper [MFCF]" at Oct 30, 98 07:34: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: 413 Lines: 9 > lynx -traversal -traversal_depth=1 > > would then be a way to check for unreferenced links (on its own server > at least) on the given page. Once the depth could be limited, one > might consider not limiting the traversal to the original server, and > > lynx -traversal -traversal_depth=1 -traverse_world These sort of options already exist in wget, which ought to be a better tool for this job. From owner-lynx-dev@sig.net Sun Nov 1 11:52:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA00739 for ; Sun, 1 Nov 1998 11:52:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA28020; Sun, 1 Nov 1998 10:39:09 -0600 (CST) From: Philip Webb Message-Id: <199811011639.LAA01956@chass.utoronto.ca> Subject: lynx-dev unanswered queries (4) To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 11:39:35 -0500 (EST) Cc: david.balazic@uni-mb.si In-Reply-To: <01J1J3M7XULE002A2E@rcum.uni-mb.si> from "DAVID BALAZIC" at Sep 7, 98 03:45: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: 772 Lines: 16 980903 David Balazic wrote: > I installed Lynx 2.8 with SSL on linux > and it terminates everytime I try to access a HTTPS page. > Details: lynx 2-8 rel2 with SSL patches, SSL 0.9.0b static libraries > Linux 2.0.34 , libc5 , gcc 2.7.2.3 none of the lynx-dev volunteers had any thoughts on this. if you're still having trouble, first get the latest Lynx 2-8-1 from www.slcc.edu/lynx/release/ ; also, let us know where you got the SSL patches from & some examples of HTTPS pages where Lynx terminates. -- ========================,,============================================ 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 Nov 1 12:03:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01387 for ; Sun, 1 Nov 1998 12:03:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA28837; Sun, 1 Nov 1998 10:45:50 -0600 (CST) From: Philip Webb Message-Id: <199811011646.LAA02232@chass.utoronto.ca> Subject: lynx-dev unanswered queries (5) To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 11:46:24 -0500 (EST) Cc: toribio@telcel.net.ve In-Reply-To: <35F954BD.7055@telcel.net.ve> from "Pepe Mijares" at Sep 11, 98 12:50:05 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: 676 Lines: 17 980908 Pepe Mijares wrote: > Dear Sir: several of the Lynx volunteers are women. > I have a Macintosh Power Book. It runs witn 8 M built in memory. > I wonder if there is a chance to download any lynx software > that might help me to move faster in internet. > let me know if there is a browser that suits ok with a Mac sistem. for information about Lynx on a Mac goto 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 Nov 1 12:13:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA02130 for ; Sun, 1 Nov 1998 12:13:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA00296; Sun, 1 Nov 1998 10:58:17 -0600 (CST) From: Philip Webb Message-Id: <199811011658.LAA03169@chass.utoronto.ca> Subject: lynx-dev unanswered queries (6) To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 11:58:50 -0500 (EST) Cc: choleman@simpact.com In-Reply-To: <004001bde70d$f141bbd0$5d8743cf@choleman1.simpact.com> from "C.W.Holeman II" at Sep 23, 98 09:19: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: 2400 Lines: 64 980923 C W Holeman wrote below: none of the lynx-dev volunteers replied to your rather technical query. the 2 sites for help with DOS Lynx are: www.rahul.net/dkaufman/ & www.fdisk.com/doslynx/doslynx.htm . > My command line: > ---------------- > > C:\users>z:\parts\sf-000\sf-000-0001\lynx.exe > -trace \ > -cfg z:\parts\sf-000\sf-000-0001\simpact_lynx.cfg > z\parts\ht-101\ht-101-0001.html > > >From the config file: > --------------------- > > PERSONAL_MAILCAP:simpact_mailcap.dat > > Here is part of the trace file: > ------------------------------- > > Lynx Trace Log > > LYNX_SIG_FILE set to 'C:\TEMP/.lynxsig' > Loading cfg file 'z:\parts\sf-000\sf-000-0001\simpact_lynx.cfg'. > HTMLDTD: Copying DTD element info of size 5192, 118 * 44 > ProcessMailcapFile: Loading file '/usr/local/lib/mosaic/mailcap'. > ProcessMailcapFile: Could not open '/usr/local/lib/mosaic/mailcap'. > ProcessMailcapFile: Loading file 'C:\TEMP/simpact_mailcap.dat'. > ProcessMailcapFile: Could not open 'C:\TEMP/simpact_mailcap.dat'. > > ------------------------------------------------------------------------- > > I see from the trace that the mailcap file is found in the default > directory which was C:\user. I would like to point to a on the same > drive as the config file specified in the command line. Is there > a was in the config file to make such a reference? Otherwise can I > just specifiy the mailcap file from the command line? From the > command line the script that invokes lynx know what drive the config > and the mailcap file live on. > > I am creating a CD-ROM that uses web pages as the interface for accessing > release notes, the software and the manuals in PDF format. This is > so that the same CD-ROM can be sent to Windows NT, Unix and VMS customers. > I am inclding lynx for these various systems just in case they do > not have a browser. Also for Windows NT and VMS untar programs. > > -- > C.W.Holeman II (619)503-1101 > Configuration Management Specialist choleman@simpact.com > Simpact Inc. http://choleman.simpact.com/ > > > > > > -- ========================,,============================================ 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 Nov 1 12:19:04 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA02221 for ; Sun, 1 Nov 1998 12:19:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA01077; Sun, 1 Nov 1998 11:04:36 -0600 (CST) From: Philip Webb Message-Id: <199811011705.MAA03535@chass.utoronto.ca> Subject: Re: lynx-dev Frames, Tables and Horizontal Scrolling support by Lynx To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 12:05:09 -0500 (EST) Cc: abv@general.udm.ru In-Reply-To: <199809261335.SAA09904@gw.mark-itt.ru> from "Anton Bobykin" at Sep 24, 98 02:34:18 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: 680 Lines: 13 980928 Anton Bobykin wrote: > Can anyone tell me about frames, tables and horizontal scrolling > support by lynx. Are any plans for this in future? frames are supported, presented as links to separate pages; tables are very difficult to implement for a fast 1-pass browser; horizontal scrolling has been discussed, but no-one has done the work: if you feel upto the job, have a go & send patches to lynx-dev. -- ========================,,============================================ 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 Nov 1 12:22:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA02553 for ; Sun, 1 Nov 1998 12:22:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA01884; Sun, 1 Nov 1998 11:11:21 -0600 (CST) From: Philip Webb Message-Id: <199811011711.MAA03988@chass.utoronto.ca> Subject: Re: lynx-dev embed src in lynx To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 12:11:51 -0500 (EST) Cc: jlemmens@inter.nl.net In-Reply-To: <199809271837.UAA10154@jojo.inter.nl.net> from "Jos Lemmens" at Sep 27, 98 08:37: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: 605 Lines: 15 980928 Jos Lemmens wrote: > I'm blind and can only use lynx for browsing the internet. > I know Netscape can use the html tag > to autostart a wav-file when you go to a page. > when I go with lynx to my homepage, which uses it, I hear nothing. > Is lynx on Linux capable to use this html tag? it's not in Lynx Supported URLs in the on-line help; also, i at least don't know what a `wav-file' is. can anyone else offer advice on this one? -- ============================================ Philip Webb : purslow@chass.utoronto.ca Centre for Urban & Community Studies University of Toronto From owner-lynx-dev@sig.net Sun Nov 1 12:25:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA02803 for ; Sun, 1 Nov 1998 12:25:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA02181; Sun, 1 Nov 1998 11:13:37 -0600 (CST) From: Philip Webb Message-Id: <199811011714.MAA04071@chass.utoronto.ca> Subject: lynx-dev htmlcompendium To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 12:14:10 -0500 (EST) In-Reply-To: <9810271237.AA19130@cas.org> from "Larry W. Virden" at Oct 27, 98 12:37:12 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: 740 Lines: 14 981027 Larry Virden wrote: > I was just looking at the site http://www.htmlcompendium.org/ , > a site attempting to provide the html coder information about tags > and where they are supported. As you drill down to specific HTML tags > a matrix showing what versions of official HTML, Navigator, > Internet Explorer, Communicator, Opera and WebTV support the tag. > It's too bad they don't have the info for lynx. yes it is: have you tried informing them ... (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 Sun Nov 1 12:29:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA02839 for ; Sun, 1 Nov 1998 12:29:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA02602; Sun, 1 Nov 1998 11:17:06 -0600 (CST) X-Authentication-Warning: moe.cc.utexas.edu: mengmeng owned process doing -bs Date: Sun, 1 Nov 1998 06:01:56 -0600 (CST) From: Mengmeng Zhang X-Sender: mengmeng@moe.cc.utexas.edu To: lynx-dev@sig.net Subject: lynx-dev Lynx 2.8.1 colors help! 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: 949 Lines: 22 Hello, I have just compiled lynx 2.8.1 with the SSL patches. I want to change the colors to look like what they used to with my Redhat built RPM (2.8.0). All the colors look fine now, except for the links. On my old lynx, all links are blue. But I specified "COLOR:1:blue:black", and the links showed up as bright blue. It seems that any color I put in there is "brightened," except for "bright" colors. Does anybody know what is going on? I am comparing my old lynx with my new lynx side by side with identical lynx.cfg's (for the COLOR section), and the links colors just don't match. Thank you very much, MZhang -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GM/CS d- s+: a--->? C++(+++) UL+(++) P+ L++(+++) E- W+(+++) N++ o+(++) K? w--- O@ M- V-- PS++ PE- Y+(++) PGP t 5 X R tv+() b+(++) DI+ D+ G e>++++ h! !r y? ------END GEEK CODE BLOCK------ Get your own Geek Code at http://www.geekcode.com Visit the Z at http://www.math.swt.edu/~mz33062/ From owner-lynx-dev@sig.net Sun Nov 1 12:37:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA03514 for ; Sun, 1 Nov 1998 12:37:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA03651; Sun, 1 Nov 1998 11:26:10 -0600 (CST) From: Philip Webb Message-Id: <199811011726.MAA04424@chass.utoronto.ca> Subject: lynx-dev ENCTYPE="multipart/formdata" To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 12:26:30 -0500 (EST) Cc: doris_hung@hp-usa-om2.om.hp.com In-Reply-To: from "DORIS_HUNG@HP-USA-om2.om.hp.com" at Oct 21, 98 06:52: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: 583 Lines: 12 981021 Doris Hung wrote: > I am working on a web application that supports persons uses LYNX. > I would like to verify with you if LYNX supports MULTIPART/form-data > ENCTYPE attribute. from the on-line help re Supported URLs, it appears not. does anyone else have any advice or an explanation for the omission? -- ========================,,============================================ 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 Nov 1 12:54:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA04689 for ; Sun, 1 Nov 1998 12:54:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA05023; Sun, 1 Nov 1998 11:37:21 -0600 (CST) From: Philip Webb Message-Id: <199811011737.MAA05039@chass.utoronto.ca> Subject: Re: lynx-dev Lynx 2.8.1 colors help! To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 12:37:55 -0500 (EST) Cc: mengmeng@uts.cc.utexas.edu In-Reply-To: from "Mengmeng Zhang" at Nov 1, 98 06:01: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: 1050 Lines: 21 981101 Mengmeng Zhang wrote: > I have just compiled lynx 2.8.1 with the SSL patches. > I want to change the colors to look like what they used to > with my Redhat built RPM (2.8). > All the colors look fine now, except for the links. > On my old lynx, all links are blue, but I specified "COLOR:1:blue:black" > and the links showed up as bright blue. It seems any color I put there > is brightened, except for "bright" colors. > I am comparing my old lynx with my new lynx side by side > with identical lynx.cfg's for the COLOR section > and the links colors just don't match. there was a discussion earlier this week: look in the Archive at www.flora.org/lynx-dev/ . i believe the tentative conclusion was that a fix is needed; you're welcome to offer patches, if you know how. -- ========================,,============================================ 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 Nov 1 13:01:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA05061 for ; Sun, 1 Nov 1998 13:01:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA00574; Sun, 1 Nov 1998 11:48:09 -0600 (CST) Date: Sun, 1 Nov 1998 12:50:48 -0500 (EST) From: Wayne Buttles To: lynx-dev@sig.net cc: doris_hung@hp-usa-om2.om.hp.com Subject: Re: lynx-dev ENCTYPE="multipart/formdata" In-Reply-To: <199811011726.MAA04424@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: 1039 Lines: 23 This is not supported at this time due to its complexity. I'd also like to see it since we use a web app that uses http file upload for homework, but it is out of my league. There was a single, older version that someone made that was supposed to be able to do it, but I never tried it. If you need this feature for a special purpose, that may be of use to you if you can find it. On Sun, 1 Nov 1998, Philip Webb wrote: > 981021 Doris Hung wrote: > > I am working on a web application that supports persons uses LYNX. > > I would like to verify with you if LYNX supports MULTIPART/form-data > > ENCTYPE attribute. > > from the on-line help re Supported URLs, it appears not. > does anyone else have any advice or an explanation for the omission? > > -- > ========================,,============================================ > 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 Nov 1 14:15:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA09666 for ; Sun, 1 Nov 1998 14:15:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA08920; Sun, 1 Nov 1998 13:02:44 -0600 (CST) Date: Sun, 1 Nov 1998 14:04:00 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811011404.AA29800@cas.org> Subject: Re: lynx-dev embed src in lynx In-Reply-To: <199811011711.MAA03988@chass.utoronto.ca> of Sun, 1 Nov 1998 12:11:51 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 967 Lines: 22 From: Philip Webb > 980928 Jos Lemmens wrote: > > I'm blind and can only use lynx for browsing the internet. > > I know Netscape can use the html tag > > to autostart a wav-file when you go to a page. > > when I go with lynx to my homepage, which uses it, I hear nothing. > > Is lynx on Linux capable to use this html tag? > > it's not in Lynx Supported URLs in the on-line help; > also, i at least don't know what a `wav-file' is. > can anyone else offer advice on this one? wav-file - an audio file. Some pages use the embed tag to start up plug in audio players, etc. The idea of lynx doing 'plugin' type support hasn't been discussed recently as far as I recall. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 1 14:29:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA10322 for ; Sun, 1 Nov 1998 14:29:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA09138; Sun, 1 Nov 1998 13:04:37 -0600 (CST) Date: Sun, 1 Nov 1998 14:05:54 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811011405.AA29813@cas.org> Subject: Re: lynx-dev htmlcompendium In-Reply-To: <199811011714.MAA04071@chass.utoronto.ca> of Sun, 1 Nov 1998 12:14:10 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 706 Lines: 13 I would let them know - if I had any idea what to tell them. Unfortunately, each time I or others have asked, on this list, over the past 7 yrs, for info on what tags lynx support, the answer has been 'read the source'. I have, for better or worse, chosen other activities over reading the source to document what tags lynx supports. If anyone else though wishes a way to contribute to lynx, without actually writing code, feel free to take on the task. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 1 15:01:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA12651 for ; Sun, 1 Nov 1998 15:01:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA13653; Sun, 1 Nov 1998 13:47:15 -0600 (CST) From: Philip Webb Message-Id: <199811011947.OAA14133@chass.utoronto.ca> Subject: Re: lynx-dev htmlcompendium To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 14:47:47 -0500 (EST) In-Reply-To: <9811011405.AA29813@cas.org> from "Larry W. Virden" at Nov 1, 98 02:05:54 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: 984 Lines: 18 981101 Larry Virden wrote: > I would let them know - if I had any idea what to tell them. > Unfortunately, each time I or others have asked, on this list, > over the past 7 yrs, for info on what tags lynx support, > the answer has been 'read the source'. > I have, for better or worse, chosen other activities > over reading the source to document what tags lynx supports. your words suggest the culprit may have been one former developer, who would dampen anyone's enthusiasm very quickly, if taken seriously. the starting-place has to be `Supported URLs' in the on-line help, supplemented perhaps by checking 1 - 2 suitable source files. is there a problem after that point? if so, we need to improve `Help'. -- ========================,,============================================ 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 Nov 1 15:40:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA15068 for ; Sun, 1 Nov 1998 15:40:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA18199; Sun, 1 Nov 1998 14:25:25 -0600 (CST) Date: Sun, 1 Nov 1998 12:27:04 -0800 (PST) From: James Elkinton To: Lynx Development Mailing List Subject: lynx-dev Link verification (akin to Traversal thread) 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: 1359 Lines: 29 Reading one of the recent posts on -traversal issues led me to a question that may or may not have been asked in the same (or similar) way: I would like to occasionally put my (rather large) lynx_bookmarks.html into a program/script/etc. that would produce another text specifying the result of going to the link. In other words, whether it got to a page, got a 404 error, etc. I was looking at the WGET page referenced from the Links section at lynx.browser.org, and I am not quite sure if it would do what I want. My personal preference would be a text file that looks something like: http://foo.bar.baz.com/topic/index.html OK http://zing.bat.org/directory/access1.html 404:FILE NOT FOUND but just about anything close to that would be of much help. Would wget do something like this? Or should I be looking at a different program/script? (Being able to press a key in Lynx to do it on the page currently being displayed would be VERY nice too... :) ) .----------------------------------------------------------------------. | James Elkinton | | zio@blueneptune.com ___ | | http://blueneptune.com/~zio/ (o o) | `-------------------------------------------------------ooO-(_)-Ooo----' From owner-lynx-dev@sig.net Sun Nov 1 15:42:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA15092 for ; Sun, 1 Nov 1998 15:42:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA18342; Sun, 1 Nov 1998 14:26:32 -0600 (CST) Date: Sun, 1 Nov 1998 18:26:45 -0200 (EDT) From: Luiz Claudio Duarte To: lynx-dev@sig.net Subject: lynx-dev Lynx as a page retriever 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: 616 Lines: 16 I'm trying to use lynx to retrieve some pages as a cron job. However, I'm stumped with two problems: 1. The pages result from a query form. Is there any way I can "press a button" as a command-line switch? Perhaps it would be better if I created my own page with the form already filled out and used a -traverse? 2. This brings me to the second problem. Is there a way to restrict the depth of traversal, since I do not wish to retrieve the pages referenced in the resulting pages? Thanks in advance for any help. -- Luiz Claudio Duarte arcadia@elisium.com Brasilia, Brazil From owner-lynx-dev@sig.net Sun Nov 1 17:54:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23697 for ; Sun, 1 Nov 1998 17:54:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA04319; Sun, 1 Nov 1998 16:40:02 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811012241.PAA08139@sanitas> Subject: Re: lynx-dev embed src in lynx To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 15:41:18 -0700 (MST) In-Reply-To: <199811011711.MAA03988@chass.utoronto.ca> from "Philip Webb" at Nov 1, 98 12:11: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: 851 Lines: 21 In a recent note, Philip Webb said: > Date: Sun, 1 Nov 1998 12:11:51 -0500 (EST) > > 980928 Jos Lemmens wrote: > > I'm blind and can only use lynx for browsing the internet. > > I know Netscape can use the html tag > > to autostart a wav-file when you go to a page. > > when I go with lynx to my homepage, which uses it, I hear nothing. > > Is lynx on Linux capable to use this html tag? > > it's not in Lynx Supported URLs in the on-line help; > also, i at least don't know what a `wav-file' is. > can anyone else offer advice on this one? > I tried following the link to a .wav file in the Jos Lemmens Page. I got "Permission Denied". Have you another example that's not protected? Lynx doesn't contain a wav player, but could likely use any defined as a helper app for Content-type: audio/wav in your .mailcap file. -- gil From owner-lynx-dev@sig.net Sun Nov 1 18:03:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA24329 for ; Sun, 1 Nov 1998 18:03:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA05308; Sun, 1 Nov 1998 16:48:31 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811012249.PAA08149@sanitas> Subject: Re: lynx-dev Lynx as a page retriever To: lynx-dev@sig.net Date: Sun, 1 Nov 1998 15:49:46 -0700 (MST) In-Reply-To: from "Luiz Claudio Duarte" at Nov 1, 98 06:26:45 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: 670 Lines: 15 In a recent note, Luiz Claudio Duarte said: > Date: Sun, 1 Nov 1998 18:26:45 -0200 (EDT) > > 1. The pages result from a query form. Is there any way I can "press a > button" as a command-line switch? Perhaps it would be better if I created Hmmm. So I got the bright idea that I could turn tracing on with ^T, grab the request out of Lynx.trace, and use that as the startup URL, or even in a "lynx -source" command. Of course this doesn't work because Lynx tries to do a GET instead of a POST on the startup URL. So, the question becomes, Is there a way to cause lynx to use a POST rather than a GET on the initial URL. Does the "-post-data" option do this? -- gil From owner-lynx-dev@sig.net Sun Nov 1 20:22:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA00527 for ; Sun, 1 Nov 1998 20:22:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA23128; Sun, 1 Nov 1998 19:10:43 -0600 (CST) Date: Mon, 2 Nov 1998 10:13:47 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811020113.KAA01640@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx whith a special configuration X-Notice: Please don't CC me; I'm a member of the list. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 717 Lines: 14 > New "cutoff_exe.h" headers file proposed: > > #ifdef CUT_OFF_EXE I once thought along these lines, but my feeling now is that we would be better off with a document referenced from INSTALLATION that would simply make recommendations about which options to "disable"/"without". Perhaps even just make a short statement right in INSTALLATION aimed at people who have an interest in reducing the image size and put asterisks on certain non-essential options. I'm not convinced that LYNX_LITE is anything we want people to be able to turn on with just the push of a button. My vision for LYNX_LITE is something imprinted on a ROM chip that gets shoved in a cellular phone (different from the goal of gzexe). __Henry From owner-lynx-dev@sig.net Mon Nov 2 02:17:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA23040 for ; Mon, 2 Nov 1998 02:17:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06950; Mon, 2 Nov 1998 01:04:04 -0600 (CST) From: Bela Lubkin Date: Sun, 1 Nov 1998 23:05:19 -0800 References: <199811010438.HAA20542@main.mccme.rssi.ru> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev lynx whith a special configuration Message-ID: <9811012305.aa21758@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 974 Lines: 21 Leonid Pauzner wrote: > We recommend using executable packers like gzexe instead, "we"? Executable packers like gzexe act *directly* *against* NHE's goals. They are appropriate only for single-user systems. Even there, they cause *more* memory to be used. They save only disk space. On a multiuser system, like Unix, the executable code of a program that is being run by multiple users is shared in memory. However, if you use an executable packer, the code is stored as if it was data; processes don't share it, and *much* more memory is consumed. Depending on the implementation, disk space may also be consumed. For instance, *each* simultaneous user may write an uncompressed executable image to disk, run that, then delete it: so space is saved only while zero users are running the program. As soon as one user is running it, space equal to (compressed size + uncompressed size) is consumed; each additional user consumes another (uncompressed size). >Bela< From owner-lynx-dev@sig.net Mon Nov 2 02:16:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA23035 for ; Mon, 2 Nov 1998 02:16:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA06395; Mon, 2 Nov 1998 00:57:11 -0600 (CST) Message-ID: <19981102015549.A23869@bcpl.net> Date: Mon, 2 Nov 1998 01:55:49 -0500 From: Webmaster Jim To: lynx-dev@sig.net Cc: Karl Eichwalder , Chris Maxwell , David Trueman , "Michael T. Smith" , =?iso-8859-1?Q?Fran=E7ois_Pinard?= , Sabato De Rosa , Ulrich Drepper Subject: lynx-dev International version up to 2.8.1rel.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i 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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 3732 Lines: 102 I have completed patching gettext function calls into Lynx 2-8-1, up to the the release-2 version. The code is available on ftp://sol.slcc.edu/pub/lynx/current/lynx2-8-1-rel2-intl.tar.gz Tom Dickey has indicated he will assist merging this into the main Lynx source tree. I will be away for a week starting Saturday, so any comments you can make before then would help. == Prior bugs not fixed yet: == *) the LOCALE directory is hard-coded. I haven't been able to figure a way to discover it and pass it through configure to the right place. *) The makefile rules need review. The top-level makefile.in doesn't match the rel2 version very well, although it compiles for me. *) I'm using gettext() rather than _() since the latter gives a warning under BSD. I don't consider this a bug, per se. *) I have not touched the input message handling (i.e., Y/N). *) Likewise, the help screens and usage() function are not gettext'd. == Current issues and bugs: == *) Earlier versions of this code compiled on NetBSD, Digital UNIX, Linux and Solaris. Solaris installation is a bit different. *) Adding the extra functions adds to compiler loads, and probably causes observed bugs on ULTRIX V4.3 and Digital UNIX V3.2. *) I didn't use Tom's patched autoconf, so there are a couple of spurious configure messages. *) I revised some logic that was buried in the LYMessages_en.h file for OS type and put it back in the source module. *) I patched a lot of code by eye over the last 2 months, so some discrepancies surely remain between this code and the main tree. *) Translations that are distributed by GNU will need hard copy release forms. The CSuite-derived catalog doesn't have this. == Treatment of LYMessages_en.h == I've set the size of this file to zero, and expect to eliminate it shortly. I emptied it to find all messages that were stored as macros. Messages have been moved back into the source code, and surrounded by gettext() calls. Language catalogs will be collected to use this call for translations. The included "fr.po" catalog is derived from CSuite sources, and works fairly well already. == Code standards == I've used the calls to gettext for all messages except trace functions. There are a large number of message techniques in the Lynx code. I would like to see all future patches use gettext() around message strings to make translations feasible. There may be a few messages I've missed buried in the code somewhere... I have left in the "#include " in many modules. It should be moved to a higher level. In some places, I've changed "Ftp" to "FTP". Tweaking strings in minor ways will cause translations to fail, so I will whine in the future about cosmetic changes that break the catalogs. On the other hand, anyone that transmutes constructs like this: printf(gettext("Whoof")); into printf("%s", gettext("whoof")); will help the cause immensely. The text "whoof" may appear in many places, but only needs to be translated once. If it is surrounded by different tags, extra translation lookups are forced. For example, this one should be 2 messages, or 1, not 3: #: src/HTFWriter.c:635 src/HTFWriter.c:648 msgid "This file cannot be displayed on this terminal." msgstr "" #: src/HTFWriter.c:646 src/HTFWriter.c:648 src/HTFWriter.c:659 src/HTFWriter.c:661 msgid "%s D)ownload, or C)ancel" msgstr "" #: src/HTFWriter.c:650 src/HTFWriter.c:663 msgid "This file cannot be displayed on this terminal: D)ownload, or C)ancel" msgstr "" == References: == http://www.flora.org/lynx-dev/html/month0898/msg00810.html ABOUT-NLS (ftp://prep.ai.mit.edu/pub/gnu/ABOUT-NLS) -- Marvin the Paranoid Android says: Wretched isn't it? From owner-lynx-dev@sig.net Mon Nov 2 06:11:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA03224 for ; Mon, 2 Nov 1998 06:11:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA21337; Mon, 2 Nov 1998 04:32:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811021034.FAA22399@shell.clark.net> Subject: Re: lynx-dev lynx whith a special configuration To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 05:34:16 -0500 (EST) In-Reply-To: <9811012305.aa21758@deepthought.armory.com> from "Bela Lubkin " at Nov 1, 98 11:05:19 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: 702 Lines: 22 > Leonid Pauzner wrote: > > > We recommend using executable packers like gzexe instead, > > "we"? > > Executable packers like gzexe act *directly* *against* NHE's goals. > They are appropriate only for single-user systems. Even there, they > cause *more* memory to be used. They save only disk space. > > On a multiuser system, like Unix, the executable code of a program that > is being run by multiple users is shared in memory. However, if you use They're also useful on single user's shell accounts (for example, if I were to do it for my ISP account). I think that's what LP was talking about. > >Bela< -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 2 10:14:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA24530 for ; Mon, 2 Nov 1998 10:14:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA25227; Mon, 2 Nov 1998 08:53:04 -0600 (CST) Date: Mon, 2 Nov 98 09:53:29 EST From: "Lloyd G. Rasmussen" Message-Id: <49086.lras@loc.gov> X-Minuet-Version: Minuet1.0_Beta_18A X-POPMail-Charset: English To: lynx-dev@sig.net Subject: Re: lynx-dev hangups [in DNS?] in Win 95 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1738 Lines: 42 On Sun, 1 Nov 1998 00:05:34 -0500 (EST), Al Gilman wrote: >I have been having a "hung" state sometimes while following links. > >The display gets to the point where it says > >"looking up www.w3.org" followed by a blinking cursor. > >Using Control-G gets me out of the hangup and I can then follow >the link without trouble. Now, I don't believe that the "looking >up" message is strictly on the up and up because this is a site I >had just visited a moment before, so the IP number should be >freshly in the cache at the DNS server. The following try goes >through quickly. > >This could have been on URLs where HTTP basic security is in >effect, i.e. my Lynx is passing password information with the >GET. If that has any possible bearing on the issue. > >Dunno if that is any use to you or not. > I ran that binary for at least 3 hours over the weekend to help my wife with her university coursework. I would say I was getting those conditions on about 1 out of 10 attempts to connect. Connection was through Sprynet, using Win95's Dial-up Networking, and the Vocal-Eyes screen reader. I experienced failures to look up as well as failures to connect, and bailed out with the "z" key in most cases. A second attempt to look up a related page from the site always worked, and then I could go back to the site I had tried in the first place. I doubt these were security-related, but who knows. -- Lloyd Rasmussen Senior Staff Engineer, Engineering Section National Library Service for the Blind and Physically Handicapped Library of Congress 202-707-0535 (work) lras@loc.gov http://www.loc.gov/nls/ (home) lras@sprynet.com http://home.sprynet.com/sprynet/lras/ From owner-lynx-dev@sig.net Mon Nov 2 11:43:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA31911 for ; Mon, 2 Nov 1998 11:43:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA22870; Mon, 2 Nov 1998 10:26:22 -0600 (CST) To: lynx-dev@sig.net References: <199811020801.LAA30799@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Mon, 2 Nov 1998 19:18:30 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx whith a special configuration 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: 1117 Lines: 23 >> #ifdef CUT_OFF_EXE > I once thought along these lines, but my feeling now is that we would > be better off with a document referenced from INSTALLATION that would > simply make recommendations about which options to "disable"/"without". > Perhaps even just make a short statement right in INSTALLATION aimed at > people who have an interest in reducing the image size and put asterisks > on certain non-essential options. I'm not convinced that LYNX_LITE is > anything we want people to be able to turn on with just the push of a > button. My vision for LYNX_LITE is something imprinted on a ROM chip > that gets shoved in a cellular phone (different from the goal of gzexe). > __Henry If I understand you right, you want most features became configurable (disable) at compile time, not only those that we have are now but much more. I see too much possible combinations and it can not be implemented without any sharp leading idea or exact aim. Also, this way may go to the madness: many options can be excluded in a rather complicated way because the original lynx code was written without that concern. From owner-lynx-dev@sig.net Mon Nov 2 11:57:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA00388 for ; Mon, 2 Nov 1998 11:57:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA28109; Mon, 2 Nov 1998 10:42:55 -0600 (CST) Message-Id: <199811021648.LAA27061@afb.net> X-Sender: gjr@192.168.1.253 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 02 Nov 1998 11:45:21 -0500 To: lynx-dev@sig.net From: "Gregory J. Rosmaita" Subject: Re: lynx-dev Lynx32/Lynx_95 Color Definition Syntax Error (10/10/98 release) Cc: wbuttles@champlain.edu In-Reply-To: References: <199810310718.CAA23215@afb.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: 378 Lines: 11 on hallowe'en, wayne buttles wrote re: lynx32 color definition >There is a new color parser and it doesn't work with comments at the end >of the line. Just move the comments to their own line and it works fine. thanks, wayne! worked like a charm! gregory. Gregory J. Rosmaita IntraNet Administrator, American Foundation for the Blind email: gjr@afb.net phone: (212) 502-7669 From owner-lynx-dev@sig.net Mon Nov 2 14:28:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA11311 for ; Mon, 2 Nov 1998 14:28:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA11130; Mon, 2 Nov 1998 13:08:43 -0600 (CST) Date: Mon, 2 Nov 1998 12:10:21 -0700 (MST) From: Rick Lewis To: lynx-dev@sig.net Subject: lynx-dev FTP with space in userid 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: 406 Lines: 11 Hi, All, Simple question, but no success finding the answer, although I've come close in Al Gilman's faq files. I use an FTP site where my userid is my name--and there's a space between first and last name. Any way to make this work in lynx? Space, comma, period, that sort of thing all doesn't do it. Thanks for any suggestions, and sorry to bother this list with something so elementary.--Rick From owner-lynx-dev@sig.net Mon Nov 2 14:57:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA13320 for ; Mon, 2 Nov 1998 14:57:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA19797; Mon, 2 Nov 1998 13:36:48 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811021938.MAA14382@sanitas> Subject: Re: lynx-dev FTP with space in userid To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 12:38:13 -0700 (MST) In-Reply-To: from "Rick Lewis" at Nov 2, 98 12:10: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: 270 Lines: 11 In a recent note, Rick Lewis said: > Date: Mon, 2 Nov 1998 12:10:21 -0700 (MST) > Content-Length: 407 > > I use an FTP site where my userid is my name--and there's a space between > first and last name. > Any way to make this work in lynx? Try First%20Last -- gil From owner-lynx-dev@sig.net Mon Nov 2 15:04:43 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA13771 for ; Mon, 2 Nov 1998 15:04:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA23167; Mon, 2 Nov 1998 13:47:31 -0600 (CST) Date: Mon, 2 Nov 1998 13:06:27 -0600 Message-ID: <4990-Mon02Nov1998130627-0600-demers@IRO.UMontreal.CA> X-Mailer: emacs 20.3.1 (via feedmail 7 I) From: demers@IRO.UMontreal.CA (Francois-Nicola Demers) To: lynx-dev@sig.net Subject: lynx-dev View French accents in Win32 Lynx. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 140 Lines: 9 Hi, I am unable to see French accents in Win32 Lynx. The accents are replaced by wrong chars. Thank you for your help. François Demers From owner-lynx-dev@sig.net Mon Nov 2 15:05:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA13785 for ; Mon, 2 Nov 1998 15:05:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA23087; Mon, 2 Nov 1998 13:47:17 -0600 (CST) Message-Id: <199811021912.TAA18712@riffraff.plig.net> To: lynx-dev@sig.net Subject: Re: lynx-dev ENCTYPE="multipart/formdata" In-Reply-To: Your message of "Sun, 01 Nov 1998 12:50:48 EST." Date: Mon, 02 Nov 1998 19:12:40 +0000 From: Rob Partington Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1423 Lines: 27 In message , Wayne Buttles writes: > This is not supported at this time due to its complexity. I'd also like > to see it since we use a web app that uses http file upload for homework, > but it is out of my league. There was a single, older version that > someone made that was supposed to be able to do it, but I never tried it. I did[1], and it worked fine. However, Lynx implemented this according to the recommendations in the RFC, ie, it converts the file to 7 bit clean and adds a Content-Transfer-Encoding header. At the moment, it only uses Base64. Unfortunately, none of the programs I tested it with supported the CTE header. Even CGI.pm doesn't have support for this, meaning that you're unlikely to be able to use it with the majority of sites. I did contemplate modifying Lynx to send 8 bit data, but that would require converting a very large portion of libwww to use binary-capable string handling, which I just wasn't in the mood for at the time. Nor am I in the mood now, particularly. Persuading people to support the standards that Lynx already supports seems to be the order of things. [1] Try it, obviously, since I was the one who patched Lynx to do it. -- rob partington / rjp@browser.org / programmer do while $lang=~/^perl|python|c|tcl|awk|(sg|ht|x)ml$/i; sometime lynx hacker: http://lynx.browser.org/rp/ From owner-lynx-dev@sig.net Mon Nov 2 15:13:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA14493 for ; Mon, 2 Nov 1998 15:13:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA24437; Mon, 2 Nov 1998 13:51:31 -0600 (CST) Date: Mon, 2 Nov 1998 11:53:23 -0800 (PST) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: lynx-dev enable java in lynx In-Reply-To: <199811021912.TAA18712@riffraff.plig.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: 278 Lines: 10 Hello I hope this question is straighforward, although it has not been to me. How can I enable java in lynx. Assumptions: I can use it in netscape in my xterm in this unix machine. Thanks, and have a nice day. Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Mon Nov 2 15:15:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA14753 for ; Mon, 2 Nov 1998 15:15:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA26780; Mon, 2 Nov 1998 13:59:08 -0600 (CST) From: Philip Webb Message-Id: <199811021959.OAA29841@chass.utoronto.ca> Subject: Re: lynx-dev ENCTYPE="multipart/formdata" To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 14:59:40 -0500 (EST) In-Reply-To: from "Wayne Buttles" at Nov 1, 98 12:50: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: 889 Lines: 17 981101 Wayne Buttles wrote re ENCTYPE="multipart/formdata": > This is not supported at this time due to its complexity. > I'd also like to see it, since we use a web app > that uses http file upload for homework, but it is out of my league. > On Sun, 1 Nov 1998, Philip Webb wrote: >> 981021 Doris Hung wrote: >>> I am working on a web application that supports persons uses LYNX. >>> Does LYNX support MULTIPART/form-data ENCTYPE attribute? >> from the on-line help re Supported URLs, it appears not. i've just added this to the todo list at SLCC, which i was please to see was upto-date for September 1998, at least. -- ========================,,============================================ 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 Nov 2 16:34:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA20450 for ; Mon, 2 Nov 1998 16:34:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA18082; Mon, 2 Nov 1998 15:08:46 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: lynx-dev@sig.net Subject: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement) In-reply-to: Your message of "Fri, 30 Oct 1998 16:05:30 PST." <19981030160530.52635@shell3.ba.best.com> 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: 1271 Lines: 32 kimdv@best.com said: > | Actually, that is Fotes binding and my comment. I'm using > BestBinding. > > What is "BestBinding"? Well, of course there is no such thing as "best" binding, it is a matter of personal preferences what is best. Personally I prefer function keys to be grouped by direction and function. E.g. ^D to move a word to the left and ^F to move a word to the right. I don't like mnemonics key names such as ^B for back and ^F for forward. First, because that should be ^A and ^V ("achteruit" and "vooruit" in case you don't speak Dutch). Second, the designers of the qwerty keyboard did not have cursor movement in mind, or else B and F would be next to each other. > Perhaps I should take a look at it, if it is publically available. http://www.flora.org/lynx-dev/lynx-dev/9509/0104.html > And as long as I'm doing a bit of cleanup in this area, let me > reiterate the question I asked previously: > > "is there some rationale for all the trailing whitespace in > LYEditmap.c:LYLineeditNames[] for the "Default Binding " > string?" > This served to align items in the Options screen. The line edit style is now on a line by itself, but I seem to remember that it once shared a line with another item that was to the right of it. From owner-lynx-dev@sig.net Mon Nov 2 17:02:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23009 for ; Mon, 2 Nov 1998 17:02:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA27375; Mon, 2 Nov 1998 15:39:50 -0600 (CST) From: Philip Webb Message-Id: <199811022140.QAA16391@chass.utoronto.ca> Subject: Re: lynx-dev ENCTYPE="multipart/formdata" To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 16:40:21 -0500 (EST) In-Reply-To: <199811021912.TAA18712@riffraff.plig.net> from "Rob Partington" at Nov 2, 98 07:12:40 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: 1165 Lines: 23 981102 Rob Partington wrote: > I did try it and it worked fine. However, Lynx implemented this > according to the recommendations in the RFC, > ie it converts to 7 bit clean & adds a Content-Transfer-Encoding header. > At the moment, it only uses Base64. > none of the programs I tested it with supported the CTE header > so you're unlikely to be able to use it with the majority of sites. > modifying Lynx to send 8 bit data would require converting > a very large portion of libwww to use binary-capable string handling so the crucial question is whether we can omit the CTE-header part, while retaining the 7-bit-clean part: if so, we can quickly enable Lynx to handle typical sites out there; the rest is pedantry. > Persuading people to support the standards Lynx already supports > seems to be the order of things. that's clearly a long-lost cause: Lynx has to live in the real World. -- ========================,,============================================ 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 Nov 2 17:09:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23362 for ; Mon, 2 Nov 1998 17:09:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA01110; Mon, 2 Nov 1998 15:52:07 -0600 (CST) From: Philip Webb Message-Id: <199811022152.QAA18611@chass.utoronto.ca> Subject: Re: lynx-dev enable java in lynx To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 16:52:42 -0500 (EST) In-Reply-To: from "Eduardo Chappa L." at Nov 2, 98 11:53:23 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: 462 Lines: 10 981102 Eduardo Chappa wrote: > How can I enable java in lynx. > I can use it in netscape in my xterm in this unix machine. you have to write the code to do so & submit patches to lynx-dev ... -- ========================,,============================================ 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 Nov 2 17:10:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23666 for ; Mon, 2 Nov 1998 17:10:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00260; Mon, 2 Nov 1998 15:49:20 -0600 (CST) From: dickey@clark.net Message-Id: <199811022150.QAA26668@shell.clark.net> Subject: Re: lynx-dev enable java in lynx To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 16:50:54 -0500 (EST) In-Reply-To: from "Eduardo Chappa L." " at Nov 2, 98 11:53:23 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: 20 > > Hello > > I hope this question is straighforward, although it has not been to me. > How can I enable java in lynx. Assumptions: I can use it in netscape in my > xterm in this unix machine. there's no java - javascript could be integrated, but that's a different matter (and hasn't been done either). > Thanks, and have a nice day. > > 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 Mon Nov 2 17:10:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23675 for ; Mon, 2 Nov 1998 17:10:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00595; Mon, 2 Nov 1998 15:50:29 -0600 (CST) From: Philip Webb Message-Id: <199811022151.QAA18231@chass.utoronto.ca> Subject: lynx-dev trailing white-space To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 16:51:01 -0500 (EST) In-Reply-To: <3872200.910039680@yeti.ftu.nl> from "Dick Wesseling" at Nov 2, 98 09:48: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: 731 Lines: 14 981102 Dick Wesseling replied to someone's question: >> "is there some rationale for all the trailing whitespace in >> LYEditmap.c:LYLineeditNames[] for the "Default Binding " string?" > This served to align items in the Options screen. > The line edit style is now on a line by itself, > but I seem to remember that it once shared a line > with another item that was to the right of it. so the trailing white-space can be removed, given the Options Form. -- ========================,,============================================ 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 Nov 2 17:14:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23776 for ; Mon, 2 Nov 1998 17:14:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA01990; Mon, 2 Nov 1998 15:54:53 -0600 (CST) From: Philip Webb Message-Id: <199811022155.QAA19261@chass.utoronto.ca> Subject: Re: lynx-dev View French accents in Win32 Lynx. To: lynx-dev@sig.net Date: Mon, 2 Nov 1998 16:55:25 -0500 (EST) Cc: demers@iro.umontreal.ca In-Reply-To: <4990-Mon02Nov1998130627-0600-demers@IRO.UMontreal.CA> from "Francois-Nicola Demers" at Nov 2, 98 01:06:27 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: 514 Lines: 11 981102 François Demers wrote: > I am unable to see French accents in Win32 Lynx. > The accents are replaced by wrong chars. set your communications software -- i recommend Kermit -- to use 8-bit characters, not 7-bit: that should do it for you. -- ========================,,============================================ 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 Nov 2 17:23:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA24552 for ; Mon, 2 Nov 1998 17:23:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA02374; Mon, 2 Nov 1998 15:56:14 -0600 (CST) Message-ID: <19981102165613.A516@scitus.dyn.ml.org> Date: Mon, 2 Nov 1998 16:56:13 -0500 From: Eric To: lynx-dev@sig.net Subject: Re: lynx-dev enable java in lynx Mail-Followup-To: lynx-dev@sig.net References: <199811021912.TAA18712@riffraff.plig.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Eduardo Chappa L. on Mon, Nov 02, 1998 at 11:53:23AM -0800 X-Unix: Linux Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 950 Lines: 22 On Mon, Nov 02, 1998 at 11:53:23AM -0800, Eduardo Chappa L. put into existance: ] Hello ] ] I hope this question is straighforward, although it has not been to me. ] How can I enable java in lynx. Assumptions: I can use it in netscape in my Lynx doesn't support Java. ] xterm in this unix machine. You may use Lynx in an xterm, but netscape and xterm are two entirely different entities. Netscape is a (rather large) program of its own, providing you a graphical web browsing environment in the X Window System, whereas xterm is merely a program providing a TTY/terminal-like interface to your Unix system from within the X Window System. xterm, lynx, and netscape are all *totally* unrelated, except for the fact that lynx can be run within an xterm, since lynx requires a TTY/terminal interface to operate and xterm provides just that. ] ] Thanks, and have a nice day. ] ] Eduardo ] http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Mon Nov 2 17:53:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA27001 for ; Mon, 2 Nov 1998 17:53:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA12373; Mon, 2 Nov 1998 16:28:06 -0600 (CST) Date: Mon, 2 Nov 1998 17:30:40 -0500 (EST) From: Wayne Buttles To: lynx-dev@sig.net Subject: Re: lynx-dev ENCTYPE="multipart/formdata" In-Reply-To: <199811022140.QAA16391@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: 1278 Lines: 29 I need 8 bit clean. On Mon, 2 Nov 1998, Philip Webb wrote: > 981102 Rob Partington wrote: > > I did try it and it worked fine. However, Lynx implemented this > > according to the recommendations in the RFC, > > ie it converts to 7 bit clean & adds a Content-Transfer-Encoding header. > > At the moment, it only uses Base64. > > none of the programs I tested it with supported the CTE header > > so you're unlikely to be able to use it with the majority of sites. > > modifying Lynx to send 8 bit data would require converting > > a very large portion of libwww to use binary-capable string handling > > so the crucial question is whether we can omit the CTE-header part, > while retaining the 7-bit-clean part: if so, we can quickly enable Lynx > to handle typical sites out there; the rest is pedantry. > > > Persuading people to support the standards Lynx already supports > > seems to be the order of things. > > that's clearly a long-lost cause: Lynx has to live in the real World. > > -- > ========================,,============================================ > 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 Nov 2 18:23:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA30483 for ; Mon, 2 Nov 1998 18:23:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA09961; Mon, 2 Nov 1998 16:21:01 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Tue, 3 Nov 1998 01:17:41 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev lynx2.8.1rel2 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: 1917 Lines: 53 One more chartrans bug: LYNXIMGMAP: show text in wrong charset (page converted twice), fixed by adding META charset to this internal page (the bug present in all versions starting from 2.7.1ac). Should go to 2.8.1 bugfixes. diff -u old/lymap.c ./lymap.c --- old/lymap.c Sun Oct 18 14:30:36 1998 +++ ./lymap.c Tue Nov 3 00:25:38 1998 @@ -19,6 +19,7 @@ #include #include #include +#include #ifdef DIRED_SUPPORT #include @@ -540,7 +541,21 @@ LYEntify(&MapTitle, TRUE); } - sprintf(buf,"\n%s\n\n\n", MapTitle); + sprintf(buf, "\n\n"); + (*target->isa->put_block)(target, buf, strlen(buf)); + sprintf(buf, "\n", + "http-equiv=\"content-type\"", + LYCharSet_UC[current_char_set].MIMEname); + (*target->isa->put_block)(target, buf, strlen(buf)); + /* + * This page is a list of titles and anchors for them. + * Since titles already passed SGML/HTML stage + * they converted to current_char_set. + * That is why we insist on META charset for this page. + */ + sprintf(buf, "%s\n", MapTitle); + (*target->isa->put_block)(target, buf, strlen(buf)); + sprintf(buf, "\n\n"); (*target->isa->put_block)(target, buf, strlen(buf)); sprintf(buf,"

    %s

    \n", MapTitle); @@ -571,7 +586,7 @@ (*target->isa->put_block)(target, MapTitle, strlen(MapTitle)); (*target->isa->put_block)(target, "\n", 5); } - sprintf(buf,"\n\n", ((keypad_mode == NUMBERS_AS_ARROWS) ? + sprintf(buf,"\n\n\n", ((keypad_mode == NUMBERS_AS_ARROWS) ? "ol" : "ul")); (*target->isa->put_block)(target, buf, strlen(buf)); From owner-lynx-dev@sig.net Mon Nov 2 19:50:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA07751 for ; Mon, 2 Nov 1998 19:50:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA12301; Mon, 2 Nov 1998 18:31:01 -0600 (CST) To: lynx-dev@sig.net References: <199811022303.CAA08337@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Tue, 3 Nov 1998 02:22:57 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev View French accents in Win32 Lynx. MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 580 Lines: 15 > 981102 FranÚois Demers wrote: >> I am unable to see French accents in Win32 Lynx. >> The accents are replaced by wrong chars. Try to go O)ptions menu and change "Display character set" to one of cpXXX (according to your font), this is a *FAQ* > set your communications software -- i recommend Kermit -- > to use 8-bit characters, not 7-bit: that should do it for you. No, Philip, he run Lynx on his local machine (Win32). > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca From owner-lynx-dev@sig.net Mon Nov 2 19:50:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA07752 for ; Mon, 2 Nov 1998 19:50:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA12315; Mon, 2 Nov 1998 18:31:04 -0600 (CST) To: lynx-dev@sig.net References: <199811021938.WAA06268@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Tue, 3 Nov 1998 03:30:37 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx whith a special configuration 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: 1013 Lines: 27 >> > We recommend using executable packers like gzexe instead, >> >> "we"? >> >> Executable packers like gzexe act *directly* *against* NHE's goals. >> They are appropriate only for single-user systems. Even there, they >> cause *more* memory to be used. They save only disk space. >> >> On a multiuser system, like Unix, the executable code of a program that >> is being run by multiple users is shared in memory. However, if you use I know about it :-) If we talk about multiple lynxen on Unix, a huge part of the code should be shared, except the variable zone which mostly allocated dynamically and so use a little space when certain feature not used. Some people prefer to waste ISP memory than pay for extra disk quota (and network provider think opposite, of cause). I do not understand NHE goals, it's right. > They're also useful on single user's shell accounts (for example, if I were > to do it for my ISP account). I think that's what LP was talking about. >> >Bela< > -- > Thomas E. Dickey From owner-lynx-dev@sig.net Tue Nov 3 00:28:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA03898 for ; Tue, 3 Nov 1998 00:28:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA02273; Mon, 2 Nov 1998 23:12:19 -0600 (CST) Date: Mon, 2 Nov 1998 21:14:09 -0800 (PST) From: David Combs Message-Id: <199811030514.VAA20797@netcom8.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: (stupid question) Where are sources? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 408 Lines: 11 The version I use here (2.8.1rel2) can't find the help "?", because it is on the ISP and the fellow who built and maintains it forgot something, evidently. So, please, www-addr where I can download a reasonably new version (newer than the 2.7.1 I use at home here just for viewing local .html files -- and which doesn't work on ghostscript .htm-doc -- but for which 2.8.1... does.) Anyway, thanks... David From owner-lynx-dev@sig.net Tue Nov 3 02:19:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA15557 for ; Tue, 3 Nov 1998 02:19:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA13083; Tue, 3 Nov 1998 00:54:29 -0600 (CST) Message-ID: <19981102225618.A4891@netcom.com> Date: Mon, 2 Nov 1998 22:56:18 -0800 From: Wilson Cheung To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: (stupid question) Where are sources? References: <199811030514.VAA20797@netcom8.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811030514.VAA20797@netcom8.netcom.com>; from David Combs on Mon, Nov 02, 1998 at 09:14:09PM -0800 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1266 Lines: 31 On Mon, Nov 02, 1998 at 09:14:09PM -0800, David Combs wrote: > The version I use here (2.8.1rel2) can't find the > help "?", because it is on the ISP and the fellow > who built and maintains it forgot something, evidently. Well...there IS a reason the newest versions of lynx are always first made available as "lynxtest" for a couple of weeks before being setup as the production "lynx". The problem should be corrected now. Anyway...I think what happened is that I recently started enabling the --enable-gzip-help option when doing the configure in order to save some disk space but I think the scripts I wrote a while back that automate building, customizing, and installing new versions of lynxtest forgot to take into account the changes a "make install" normally does when the --enable-gzip-help option is enabled. I'll have to check. > So, please, www-addr where I can download a reasonably > new version (newer than the 2.7.1 I use at home here > just for viewing local .html files -- and which doesn't > work on ghostscript .htm-doc -- but for which 2.8.1... does.) I like to pull them from: ftp://sol.slcc.edu/pub/lynx/current/ but http://lynx.browser.org/ should lead you to somewhere you can get them. -- Wilson Cheung wcheung@netcom.com From owner-lynx-dev@sig.net Tue Nov 3 04:08:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA26207 for ; Tue, 3 Nov 1998 04:08:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA22634; Tue, 3 Nov 1998 02:53:47 -0600 (CST) Message-ID: <19981103005452.48589@shell3.ba.best.com> Date: Tue, 3 Nov 1998 00:54:52 -0800 From: Kim DeVaughn To: Lynx Developers Subject: [2.8.1rel.2] lineedit cleanup/enhancement (was: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement)) Mail-Followup-To: Lynx Developers References: <19981030160530.52635@shell3.ba.best.com> <3872200.910039680@yeti.ftu.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <3872200.910039680@yeti.ftu.nl>; from Dick Wesseling on Mon, Nov 02, 1998 at 09:48:00PM +0100 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: 14907 Lines: 363 On Mon, Nov 02, 1998, Dick Wesseling (ftu@fi.uu.nl) said: | | kimdv@best.com said: | > | > And as long as I'm doing a bit of cleanup in this area, let me | > reiterate the question I asked previously: | > | > "is there some rationale for all the trailing whitespace in | > LYEditmap.c:LYLineeditNames[] for the "Default Binding " | > string?" | | This served to align items in the Options screen. The line edit style | is now on a line by itself, but I seem to remember that it once shared | a line with another item that was to the right of it. Oh, OK. In the current old-style options menu, it's fine without the trailing whitespace, and is a non sequitur for the new-style forms type options page (which unfathomably omits line-editor binding options). The attached patch now removes the redundent LYE_DELC case code from LYStrings.c, and add the new LYE_DELEOL case (which deletes characters from the current cursor position, thru the end-of-line). Default binding for DELEOL is ^\ (formerly a NOP). References to LYE_DELC are removed from the maps, and documentation, and it is equated to LYE_DELN for backward compatibility reasons. I've cleaned up the help files a bit, to make it clear that the setting of emacs/vi keys ON, has no effect on the line-editor bindings (a point which confused the Hell out of me for awhile). I also clarified what the next/current char is (WRT cursor style), and removed references to DELC, etc. Whether my "Better Bindings" map gets included in the distribution or not doesn't concern me much, but I do hope the new LYE_DELEOL function does, as well as the doc and LYE_DELC cleanup. /kim diff -uNr lynx-2.8.1-rel.2.orig/src/LYStrings.c lynx-2.8.1-rel.2+kd/src/LYStrings.c --- lynx-2.8.1-rel.2.orig/src/LYStrings.c Mon Nov 2 15:47:16 1998 +++ lynx-2.8.1-rel.2+kd/src/LYStrings.c Mon Nov 2 22:49:25 1998 @@ -1514,14 +1514,28 @@ } break; + case LYE_DELEOL: + /* + * Delete from current cursor position thru EOL. + */ + { + int pos0 = Pos; + LYEdit1(edit, 0, LYE_EOL, FALSE); + pos0 = Pos - pos0; + while (pos0--) + LYEdit1(edit, 0, LYE_DELP, FALSE); + } + break; + case LYE_DELN: /* - * Delete next character + * Delete next character (I-beam style cursor), or current + * character (box/underline style cursor). */ if (Pos >= length) break; Pos++; - /* fall through */ + /* fall through - DO NOT RELOCATE the LYE_DELN case wrt LYE_DELP */ case LYE_DELP: /* @@ -1530,18 +1544,6 @@ if (length == 0 || Pos == 0) break; Pos--; - for (i = Pos; i < length; i++) - Buf[i] = Buf[i+1]; - i--; - Buf[i] = 0; - break; - - case LYE_DELC: - /* - * Delete current character. - */ - if (length == 0 || Pos == length) - break; for (i = Pos; i < length; i++) Buf[i] = Buf[i+1]; i--; diff -uNr lynx-2.8.1-rel.2.orig/src/LYStrings.h lynx-2.8.1-rel.2+kd/src/LYStrings.h --- lynx-2.8.1-rel.2.orig/src/LYStrings.h Mon Nov 2 15:47:16 1998 +++ lynx-2.8.1-rel.2+kd/src/LYStrings.h Mon Nov 2 16:52:35 1998 @@ -122,9 +122,9 @@ #define LYE_TAB (LYE_ENTER +1) /* Input complete, return TAB */ #define LYE_ABORT (LYE_TAB +1) /* Input cancelled */ -#define LYE_DELN (LYE_ABORT +1) /* Delete next char */ -#define LYE_DELC (LYE_DELN +1) /* Delete current char */ -#define LYE_DELP (LYE_DELC +1) /* Delete prev char */ +#define LYE_DELN (LYE_ABORT +1) /* Delete next/curr char */ +#define LYE_DELC (LYE_DELN) /* Obsolete (DELC case was equiv to DELN) */ +#define LYE_DELP (LYE_DELN +1) /* Delete prev char */ #define LYE_DELNW (LYE_DELP +1) /* Delete next word */ #define LYE_DELPW (LYE_DELNW +1) /* Delete prev word */ @@ -143,6 +143,8 @@ #define LYE_LKCMD (LYE_UPPER +1) /* Invoke command prompt */ #define LYE_AIX (LYE_LKCMD +1) /* Hex 97 */ + +#define LYE_DELEOL (LYE_AIX +1) /* Delete thru EOL */ #if defined(USE_KEYMAPS) extern int lynx_initialize_keymaps NOPARAMS; diff -uNr lynx-2.8.1-rel.2.orig/src/LYEditmap.c lynx-2.8.1-rel.2+kd/src/LYEditmap.c --- lynx-2.8.1-rel.2.orig/src/LYEditmap.c Mon Nov 2 15:47:16 1998 +++ lynx-2.8.1-rel.2+kd/src/LYEditmap.c Mon Nov 2 18:38:56 1998 @@ -15,7 +15,7 @@ LYE_NOP, LYE_BOL, LYE_DELPW, LYE_ABORT, /* nul ^A ^B ^C */ -LYE_DELC, LYE_EOL, LYE_DELNW, LYE_ABORT, +LYE_DELN, LYE_EOL, LYE_DELNW, LYE_ABORT, /* ^D ^E ^F ^G */ LYE_DELP, LYE_ENTER, LYE_ENTER, LYE_LOWER, @@ -33,7 +33,7 @@ LYE_ERASE, LYE_NOP, LYE_NOP, LYE_NOP, /* ^X ^Y ^Z ESC */ -LYE_NOP, LYE_NOP, LYE_NOP, LYE_NOP, +LYE_DELEOL, LYE_NOP, LYE_NOP, LYE_NOP, /* ^\ ^] ^^ ^_ */ /* sp .. RUBOUT */ @@ -114,9 +114,115 @@ }; /* - * Add your favorite key binding HERE + * Add your favorite key bindings HERE */ +/* 01 */ /* Default except that ^F=cursor-forward and ^B=cursor-backward */ +/* */ + +PRIVATE char BetterEditBinding[]={ + +LYE_NOP, LYE_BOL, LYE_BACK, LYE_ABORT, +/* nul ^A ^B ^C */ + +LYE_DELN, LYE_EOL, LYE_FORW, LYE_ABORT, +/* ^D ^E ^F ^G */ + +LYE_DELP, LYE_ENTER, LYE_ENTER, LYE_DELEOL, +/* bs tab nl ^K */ + +LYE_NOP, LYE_ENTER, LYE_FORWW, LYE_ABORT, +/* ^L cr ^N ^O */ + +LYE_BACKW, LYE_NOP, LYE_DELPW, LYE_NOP, +/* ^P XON ^R XOFF */ + +LYE_DELNW, LYE_ERASE, LYE_LKCMD, LYE_NOP, +/* ^T ^U ^V ^W */ + +LYE_ERASE, LYE_NOP, LYE_NOP, LYE_NOP, +/* ^X ^Y ^Z ESC */ + +LYE_DELEOL, LYE_NOP, LYE_UPPER, LYE_LOWER, +/* ^\ ^] ^^ ^_ */ + +/* sp .. RUBOUT */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_DELP, + +/* 80..9F ISO-8859-1 8-bit escape characters. */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_AIX, +/* 97 AIX */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, + +/* A0..FF (permissible ISO-8859-1) 8-bit characters. */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, + +/* 100..10E function key definitions in LYStrings.h */ +LYE_NOP, LYE_NOP, LYE_FORW, LYE_BACK, +/* UPARROW DNARROW RTARROW LTARROW */ + +LYE_NOP, LYE_NOP, LYE_BOL, LYE_EOL, +/* PGDOWN PGUP HOME END */ + +LYE_NOP, LYE_TAB, LYE_BOL, LYE_EOL, +/* F1 Do key Find key Select key */ + +LYE_NOP, LYE_DELP, LYE_NOP, LYE_NOP, +/* Insert key Remove key DO_NOTHING ... */ +}; + /* * Add the array name to LYLineEditors @@ -124,6 +230,7 @@ PUBLIC char * LYLineEditors[]={ DefaultEditBinding, /* You can't please everyone, so you ... DW */ + BetterEditBinding, /* No, you certainly can't ... /ked 10/27/98*/ }; /* @@ -131,7 +238,8 @@ * The order of LYLineEditors and LyLineditNames MUST be the same */ PUBLIC char * LYLineeditNames[]={ - "Default Binding ", + "Default Binding", + "Better Bindings", (char *) 0 }; diff -uNr lynx-2.8.1-rel.2.orig/lynx_help/Lynx_users_guide.html lynx-2.8.1-rel.2+kd/lynx_help/Lynx_users_guide.html --- lynx-2.8.1-rel.2.orig/lynx_help/Lynx_users_guide.html Tue Oct 27 18:08:12 1998 +++ lynx-2.8.1-rel.2+kd/lynx_help/Lynx_users_guide.html Mon Nov 2 23:01:03 1998 @@ -761,12 +761,16 @@ uppercase H, J, K, and L keys remain mapped to their configured bindings (normally HELP, JUMP, KEYMAP, and LIST, respectively). +

    Note: this has no effect on the line-editor's key bindings. +

    Emacs keys
    If set to ON then the CTRL-P, CTRL-N, CTRL-F, and CTRL-B keys will be mapped to up-arrow, down-arrow, right-arrow, and left-arrow, respectively. Otherwise, they remain mapped to their configured bindings (normally UP_TWO lines, DOWN_TWO lines, NEXT_PAGE, and PREV_PAGE, respectively). + +

    Note: this has no effect on the line-editor's key bindings.

    Show dot files
    If display/creation of hidden (dot) files/directories is diff -uNr lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/edit_help.html lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/edit_help.html --- lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/edit_help.html Mon Nov 24 10:22:32 1997 +++ lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/edit_help.html Mon Nov 2 18:42:40 1998 @@ -10,31 +10,41 @@ Lynx invokes a built-in Line Editor for entering strings in response to prompts, in forms, and for email messages if an external editor has not been defined. Administrators can offer alternate key bindings -by adding them in LYEditmap.c before compiling Lynx, and they can -be selected via the 'o'ptions menu. This is the Default Binding: -
    -     ENTER  Input complete       -  RETURN
    -     TAB    Input complete       -  TAB, Do
    -     ABORT  Input cancelled      -  Ctrl-G, Ctrl-O, Ctrl-C
    -     ERASE  Erase the line       -  Ctrl-U, Ctrl-X
    -
    -     BACK   Cursor back    char  -  Left-Arrow
    -     FORW   Cursor forward char  -  Right-Arrow
    -     BACKW  Cursor back    word  -  Ctrl-P
    -     FORWW  Cursor forward word  -  Ctrl-N
    -     BOL    Go to begin of line  -  Ctrl-A, Home, Find
    -     EOL    Go to end   of line  -  Ctrl-E, End,  Select
    -
    -     DELP   Delete prev    char  -  Ctrl-H, DELETE, Remove
    -     DELC   Delete current char  -  Ctrl-D
    -     DELN   Delete next    char  -  Ctrl-R
    -     DELPW  Delete prev    word  -  Ctrl-B
    -     DELNW  Delete next    word  -  Ctrl-F
    +by adding them in LYEditmap.c before compiling Lynx.  If available, they may
    +be selected via the old-style 'o'ptions menu (see -forms_options command
    +line option), or by editing lineedit_mode in the .lynxrc file.
     
    -     LOWER  Lower case the line  -  Ctrl-K
    -     UPPER  Upper case the line  -  Ctrl-T
    +

    Note: setting emacs/vi keys ON has no effect on line-editor bindings. - LKCMD Invoke cmd prompt - Ctrl-V (in form text fields, only) +

    This is the Default Binding: + +

    +     ENTER  Input complete        -  RETURN
    +     TAB    Input complete        -  TAB, Do
    +     ABORT  Input cancelled       -  Ctrl-G, Ctrl-O, Ctrl-C
    +     ERASE  Erase the line        -  Ctrl-U, Ctrl-X
    +
    +     BACK   Cursor back     char  -  Left-Arrow
    +     FORW   Cursor forward  char  -  Right-Arrow
    +     BACKW  Cursor back     word  -  Ctrl-P
    +     FORWW  Cursor forward  word  -  Ctrl-N
    +     BOL    Go to begin of  line  -  Ctrl-A, Home, Find
    +     EOL    Go to end   of  line  -  Ctrl-E, End,  Select
    +
    +     DELP   Delete prev     char  -  Ctrl-H, DELETE, Remove
    +     DELN   Delete next [*] char  -  Ctrl-D, Ctrl-R
    +     DELPW  Delete prev     word  -  Ctrl-B
    +     DELNW  Delete next     word  -  Ctrl-F
    +     DELEOL Delete to end of line -  Ctrl-\
    +
    +     LOWER  Lower case the line   -  Ctrl-K
    +     UPPER  Upper case the line   -  Ctrl-T
    +
    +     LKCMD  Invoke cmd prompt     -  Ctrl-V (in form text fields, only)
    +
    +[*] "next" means the character "under" a box or underline type cursor; it
    +     means "to the immediate right of" an I-beam type (between characters)
    +     cursor.
     
    #--eof--# From owner-lynx-dev@sig.net Tue Nov 3 05:38:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA02990 for ; Tue, 3 Nov 1998 05:38:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA26823; Tue, 3 Nov 1998 03:55:51 -0600 (CST) Message-Id: <199811030951.JAA18274@riffraff.plig.net> To: lynx-dev@sig.net Subject: Re: lynx-dev ENCTYPE="multipart/formdata" In-Reply-To: Your message of "Mon, 02 Nov 1998 16:40:21 EST." <199811022140.QAA16391@chass.utoronto.ca> Date: Tue, 03 Nov 1998 09:51:52 +0000 From: Rob Partington Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1106 Lines: 22 In message <199811022140.QAA16391@chass.utoronto.ca>, Philip Webb writes: > so the crucial question is whether we can omit the CTE-header part, > while retaining the 7-bit-clean part: if so, we can quickly enable Lynx > to handle typical sites out there; the rest is pedantry. No, you can't. Without the CTE, the remote end has no idea what you've sent. If they were expecting Base64, you'd be ok. However, most things I've seen expect plain binary. No more, no less. IE and Netscape both send plain binary, Lynx has to do the same. > > Persuading people to support the standards Lynx already supports > > seems to be the order of things. > > that's clearly a long-lost cause: Lynx has to live in the real World. True. It would help if the real-world followed it's own standards though. (The RFC is co-written, or possibly entirely written, by people from Netscape. Their own browser doesn't even follow their own RFC.) -- rob partington / rjp@browser.org / programmer do while $lang=~/^perl|python|c|tcl|awk|(sg|ht|x)ml$/i; sometime lynx hacker: http://lynx.browser.org/rp/ From owner-lynx-dev@sig.net Tue Nov 3 07:02:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA13878 for ; Tue, 3 Nov 1998 07:02:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA06826; Tue, 3 Nov 1998 05:29:09 -0600 (CST) Message-ID: <19981103063018.B417@bcpl.net> Date: Tue, 3 Nov 1998 06:30:18 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: (stupid question) Where are sources? References: <199811030514.VAA20797@netcom8.netcom.com> <19981102225618.A4891@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981102225618.A4891@netcom.com>; from Wilson Cheung on Mon, Nov 02, 1998 at 10:56:18PM -0800 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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 1356 Lines: 27 On Mon, Nov 02, 1998 at 10:56:18PM -0800, Wilson Cheung wrote: > On Mon, Nov 02, 1998 at 09:14:09PM -0800, David Combs wrote: > > The version I use here (2.8.1rel2) can't find the > > help "?", because it is on the ISP and the fellow > > who built and maintains it forgot something, evidently. > Well...there IS a reason the newest versions of lynx are always first made > available as "lynxtest" for a couple of weeks before being setup as the > production "lynx". The problem should be corrected now. > Anyway...I think what happened is that I recently started enabling > the --enable-gzip-help option when doing the configure in order > [ ... ] > > So, please, www-addr where I can download a reasonably > > new version (newer than the 2.7.1 I use at home here > > just for viewing local .html files -- and which doesn't > > work on ghostscript .htm-doc -- but for which 2.8.1... does.) > I like to pull them from: > ftp://sol.slcc.edu/pub/lynx/current/ > but http://lynx.browser.org/ should lead you to somewhere you can get them. Also, the breakout directory exists at: http://www.slcc.edu/lynx/release2-8-1/lynx2-8-1/ and http://www.slcc.edu/lynx/current/lynx2-8-1/ (for a little while). You could use the help subdirectory at: http://www.slcc.edu/lynx/release2-8-1/lynx2-8-1/lynx_help/ ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Tue Nov 3 11:10:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA17741 for ; Tue, 3 Nov 1998 11:10:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA23729; Tue, 3 Nov 1998 09:46:35 -0600 (CST) Message-ID: <19981103154953.29267.rocketmail@send202.yahoomail.com> Date: Tue, 3 Nov 1998 07:49:53 -0800 (PST) From: Dan Stumbaugh To: "Lynx Mail List" Lynx 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: 694 Lines: 18 Hello, I am using Lynx 2.8.1 released for Win32 running on WindowsNT 4.0. I am having trouble getting rid of the border/margin that lynx seems to add. I am working with a very small terminal (21 columns by 8 lines) and can’t afford to have borders. I have set my Web pages to “” which shows up on IE-4 with no borders, but Lynx seems to put a border on. I’m more of a system engineer then a programmer so I might be overlooking something very easy. If anybody could help, I would appreciate the response. Dan _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-lynx-dev@sig.net Tue Nov 3 11:18:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA18507 for ; Tue, 3 Nov 1998 11:18:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA28714; Tue, 3 Nov 1998 10:02:38 -0600 (CST) Message-Id: <199811031410.WAA31530@eastgate.cyberway.com.sg> X-Sender: sloh@pop.cyberway.com.sg (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 03 Nov 1998 22:09:08 +0800 To: lynx-dev@sig.net From: Loh Sin Jin Subject: lynx-dev Lynx for Win32 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: 360 Lines: 10 Hi, I have downloaded Lynx for Windows 95/98 from the web-site . However, when I start Lynx, it displays "Making http connection to lynx.browser.org" then "Alert! Unable to connect to remote host". Then the dos box in Windows closes on its own. Please advice. Thanks. Regards Loh Sin Jin From owner-lynx-dev@sig.net Tue Nov 3 11:42:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA22756 for ; Tue, 3 Nov 1998 11:42:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA04431; Tue, 3 Nov 1998 10:21:16 -0600 (CST) Date: Tue, 3 Nov 1998 11:23:51 -0500 (EST) From: Wayne Buttles To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx for Win32 In-Reply-To: <199811031410.WAA31530@eastgate.cyberway.com.sg> 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: 425 Lines: 15 On Tue, 3 Nov 1998, Loh Sin Jin wrote: > Hi, > I have downloaded Lynx for Windows 95/98 from the web-site > . However, when I start Lynx, > it displays "Making http connection to lynx.browser.org" then "Alert! > Unable to connect to remote host". Then the dos box in Windows closes on > its own. Please advice. Thanks. > > Regards > Loh Sin Jin > > From owner-lynx-dev@sig.net Tue Nov 3 11:48:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA23247 for ; Tue, 3 Nov 1998 11:48:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA06609; Tue, 3 Nov 1998 10:27:55 -0600 (CST) From: Philip Webb Message-Id: <199811031628.LAA00845@chass.utoronto.ca> Subject: Re: lynx-dev Lynx for Win32 To: lynx-dev@sig.net Date: Tue, 3 Nov 1998 11:28:28 -0500 (EST) Cc: sloh@pop.cyberway.com.sg In-Reply-To: <199811031410.WAA31530@eastgate.cyberway.com.sg> from "Loh Sin Jin" at Nov 3, 98 10:09: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: 933 Lines: 18 981103 Loh Sin Jin wrote: > I have downloaded Lynx for Windows 95/98 from the web-site > . However, when I start Lynx, > it displays "Making http connection to lynx.browser.org" > then "Alert! Unable to connect to remote host". > Then the dos box in Windows closes on its own. you need to specify a local file as your starting file in lynx.cfg : eg file://yourdir/bookmark.file (whatever the correct name for it); you may have to fiddle with the slashes a bit to get it right: check in lynx.cfg & at doslynx . alternatively, you can specify a remote site you KNOW will be active, eg a local university department. -- ========================,,============================================ 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 Nov 3 11:48:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA23261 for ; Tue, 3 Nov 1998 11:48:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA05795; Tue, 3 Nov 1998 10:25:22 -0600 (CST) Date: Tue, 3 Nov 1998 11:27:42 -0500 (EST) From: Wayne Buttles To: Loh Sin Jin cc: lynx-dev@sig.net Subject: Re: lynx-dev Lynx for Win32 In-Reply-To: <199811031410.WAA31530@eastgate.cyberway.com.sg> 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: 698 Lines: 23 You should change the STARTFILE in lynx.cfg to a file or server you want to see any time you start lynx. Also, for connecting to arbitrary sites, put the name of the intended web site as a parameter. From the console prompt you would just type: lynx www.yahoo.com Wayne On Tue, 3 Nov 1998, Loh Sin Jin wrote: > Hi, > I have downloaded Lynx for Windows 95/98 from the web-site > . However, when I start Lynx, > it displays "Making http connection to lynx.browser.org" then "Alert! > Unable to connect to remote host". Then the dos box in Windows closes on > its own. Please advice. Thanks. > > Regards > Loh Sin Jin > > From owner-lynx-dev@sig.net Tue Nov 3 13:49:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA07465 for ; Tue, 3 Nov 1998 13:49:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA14349; Tue, 3 Nov 1998 12:35:07 -0600 (CST) From: Bela Lubkin Date: Tue, 3 Nov 1998 10:36:23 -0800 References: <19981030160530.52635@shell3.ba.best.com> <3872200.910039680@yeti.ftu.nl> <19981103005452.48589@shell3.ba.best.com> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: [2.8.1rel.2] lineedit cleanup/enhancement (was: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement)) Message-ID: <9811031036.aa28621@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 958 Lines: 23 Kim DeVaughn wrote: > The attached patch now removes the redundent LYE_DELC case code from > LYStrings.c, and add the new LYE_DELEOL case (which deletes characters > from the current cursor position, thru the end-of-line). > > Default binding for DELEOL is ^\ (formerly a NOP). On almost all Unix systems, ^\ is, by default, the `quit' character. It sends SIGQUIT, which causes most programs to dump core (that's its purpose). This can be blocked by ignoring SIGQUIT. I find no references to SIGQUIT in the Lynx source, including in your patch. Hitting ^\ in my (un-patched) Lynx causes it to dump core, as expected. This isn't a good default binding, as it will cause problems on a large percentage of the systems that use Lynx. Fixing it by blocking SIGQUIT wouldn't be good either -- it exists for good reason (e.g. to be able to generate a dump from a hung Lynx, for analysis). I don't object to the feature, just the default binding... >Bela< From owner-lynx-dev@sig.net Tue Nov 3 17:23:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA30603 for ; Tue, 3 Nov 1998 17:23:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA14811; Tue, 3 Nov 1998 16:03:12 -0600 (CST) Message-Id: <4.1.19981103161352.021415a0@192.168.1.253> Message-Id: <4.1.19981103161352.021415a0@192.168.1.253> Message-Id: <4.1.19981103161352.021415a0@192.168.1.253> X-Sender: gjr@192.168.1.253 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 03 Nov 1998 17:05:43 -0500 To: lynx-dev@sig.net From: "Gregory J. Rosmaita" Subject: lynx-dev Re: Lynx32 and Microsoft borders In-Reply-To: <19981103154953.29267.rocketmail@send202.yahoomail.com> 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: 482 Lines: 16 aloha, dan! At 07:49 AM 11/3/98 -0800, you wrote: >I am using Lynx 2.8.1 released for Win32 running on WindowsNT 4.0. I >am having trouble getting rid of the border/margin that lynx seems to >add. it sounds as if you are running Lynx32 in "windowed" mode... try typing ALT-ENTER to display Lynx32 in "Full Screen Mode", i.e. 80 by 25 characters... gregory. Gregory J. Rosmaita IntraNet Administrator, American Foundation for the Blind email: gjr@afb.net phone: (212) 502-7669 From owner-lynx-dev@sig.net Tue Nov 3 20:20:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA15960 for ; Tue, 3 Nov 1998 20:20:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA26650; Tue, 3 Nov 1998 19:05:11 -0600 (CST) Message-ID: <19981103170645.34081@shell3.ba.best.com> Date: Tue, 3 Nov 1998 17:06:45 -0800 From: Kim DeVaughn To: Lynx Developers Subject: Re: [2.8.1rel.2] lineedit cleanup/enhancement - take 3 (was: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement)) Mail-Followup-To: Lynx Developers References: <19981030160530.52635@shell3.ba.best.com> <3872200.910039680@yeti.ftu.nl> <19981103005452.48589@shell3.ba.best.com> <9811031036.aa28621@deepthought.armory.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <9811031036.aa28621@deepthought.armory.com>; from Bela Lubkin on Tue, Nov 03, 1998 at 10:36:23AM -0800 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: 16009 Lines: 384 On Tue, Nov 03, 1998, Bela Lubkin (filbo@deepthought.armory.com) said: | | Kim DeVaughn wrote: | > | > The attached patch now removes the redundent LYE_DELC case code from | > LYStrings.c, and add the new LYE_DELEOL case (which deletes characters | > from the current cursor position, thru the end-of-line). | > | > Default binding for DELEOL is ^\ (formerly a NOP). | | On almost all Unix systems, ^\ is, by default, the `quit' character. It | sends SIGQUIT, which causes most programs to dump core (that's its | purpose). This can be blocked by ignoring SIGQUIT. | | I find no references to SIGQUIT in the Lynx source, including in your | patch. Hitting ^\ in my (un-patched) Lynx causes it to dump core, as | expected. | | This isn't a good default binding, as it will cause problems on a large | percentage of the systems that use Lynx. Fixing it by blocking SIGQUIT | wouldn't be good either -- it exists for good reason (e.g. to be able to | generate a dump from a hung Lynx, for analysis). | | I don't object to the feature, just the default binding... Heh. Forgot about that usage of C-\. FWIW, stty -a shows it bound to "quit" on this FreeBSD 2.2.7-STABLE system, but it seems to have no effect on lynx (nor any other app, for that matter). Wonder where it's getting snarfed up ...?... As may be, I rebound the default for LYE_DELEOL to ^_ (which I *hope* is a safe choice). Also fixed a couple more doc references to emacs/vi keys to reflect that they have no effect on the line-edit bindings. /kim diff -uNr lynx-2.8.1-rel.2.orig/src/LYStrings.c lynx-2.8.1-rel.2+kd/src/LYStrings.c --- lynx-2.8.1-rel.2.orig/src/LYStrings.c Tue Nov 3 15:43:03 1998 +++ lynx-2.8.1-rel.2+kd/src/LYStrings.c Mon Nov 2 22:49:25 1998 @@ -1514,14 +1514,28 @@ } break; + case LYE_DELEOL: + /* + * Delete from current cursor position thru EOL. + */ + { + int pos0 = Pos; + LYEdit1(edit, 0, LYE_EOL, FALSE); + pos0 = Pos - pos0; + while (pos0--) + LYEdit1(edit, 0, LYE_DELP, FALSE); + } + break; + case LYE_DELN: /* - * Delete next character + * Delete next character (I-beam style cursor), or current + * character (box/underline style cursor). */ if (Pos >= length) break; Pos++; - /* fall through */ + /* fall through - DO NOT RELOCATE the LYE_DELN case wrt LYE_DELP */ case LYE_DELP: /* @@ -1530,18 +1544,6 @@ if (length == 0 || Pos == 0) break; Pos--; - for (i = Pos; i < length; i++) - Buf[i] = Buf[i+1]; - i--; - Buf[i] = 0; - break; - - case LYE_DELC: - /* - * Delete current character. - */ - if (length == 0 || Pos == length) - break; for (i = Pos; i < length; i++) Buf[i] = Buf[i+1]; i--; diff -uNr lynx-2.8.1-rel.2.orig/src/LYStrings.h lynx-2.8.1-rel.2+kd/src/LYStrings.h --- lynx-2.8.1-rel.2.orig/src/LYStrings.h Tue Nov 3 15:43:03 1998 +++ lynx-2.8.1-rel.2+kd/src/LYStrings.h Mon Nov 2 16:52:35 1998 @@ -122,9 +122,9 @@ #define LYE_TAB (LYE_ENTER +1) /* Input complete, return TAB */ #define LYE_ABORT (LYE_TAB +1) /* Input cancelled */ -#define LYE_DELN (LYE_ABORT +1) /* Delete next char */ -#define LYE_DELC (LYE_DELN +1) /* Delete current char */ -#define LYE_DELP (LYE_DELC +1) /* Delete prev char */ +#define LYE_DELN (LYE_ABORT +1) /* Delete next/curr char */ +#define LYE_DELC (LYE_DELN) /* Obsolete (DELC case was equiv to DELN) */ +#define LYE_DELP (LYE_DELN +1) /* Delete prev char */ #define LYE_DELNW (LYE_DELP +1) /* Delete next word */ #define LYE_DELPW (LYE_DELNW +1) /* Delete prev word */ @@ -143,6 +143,8 @@ #define LYE_LKCMD (LYE_UPPER +1) /* Invoke command prompt */ #define LYE_AIX (LYE_LKCMD +1) /* Hex 97 */ + +#define LYE_DELEOL (LYE_AIX +1) /* Delete thru EOL */ #if defined(USE_KEYMAPS) extern int lynx_initialize_keymaps NOPARAMS; diff -uNr lynx-2.8.1-rel.2.orig/src/LYEditmap.c lynx-2.8.1-rel.2+kd/src/LYEditmap.c --- lynx-2.8.1-rel.2.orig/src/LYEditmap.c Tue Nov 3 15:43:03 1998 +++ lynx-2.8.1-rel.2+kd/src/LYEditmap.c Tue Nov 3 15:56:32 1998 @@ -15,7 +15,7 @@ LYE_NOP, LYE_BOL, LYE_DELPW, LYE_ABORT, /* nul ^A ^B ^C */ -LYE_DELC, LYE_EOL, LYE_DELNW, LYE_ABORT, +LYE_DELN, LYE_EOL, LYE_DELNW, LYE_ABORT, /* ^D ^E ^F ^G */ LYE_DELP, LYE_ENTER, LYE_ENTER, LYE_LOWER, @@ -33,7 +33,7 @@ LYE_ERASE, LYE_NOP, LYE_NOP, LYE_NOP, /* ^X ^Y ^Z ESC */ -LYE_NOP, LYE_NOP, LYE_NOP, LYE_NOP, +LYE_NOP, LYE_NOP, LYE_NOP, LYE_DELEOL, /* ^\ ^] ^^ ^_ */ /* sp .. RUBOUT */ @@ -114,9 +114,117 @@ }; /* - * Add your favorite key binding HERE + * Add your favorite key bindings HERE */ +/* KED */ /* Default except: ^B=cursor-backward, ^F=cursor-forward, */ + /* ^K=delete-to-EOL, */ + /* ^R=delete-prev-word, ^T=delete-next-word, */ + /* ^^=upper-case-line, ^_=lower-case-line */ + +PRIVATE char BetterEditBinding[]={ + +LYE_NOP, LYE_BOL, LYE_BACK, LYE_ABORT, +/* nul ^A ^B ^C */ + +LYE_DELN, LYE_EOL, LYE_FORW, LYE_ABORT, +/* ^D ^E ^F ^G */ + +LYE_DELP, LYE_ENTER, LYE_ENTER, LYE_DELEOL, +/* bs tab nl ^K */ + +LYE_NOP, LYE_ENTER, LYE_FORWW, LYE_ABORT, +/* ^L cr ^N ^O */ + +LYE_BACKW, LYE_NOP, LYE_DELPW, LYE_NOP, +/* ^P XON ^R XOFF */ + +LYE_DELNW, LYE_ERASE, LYE_LKCMD, LYE_NOP, +/* ^T ^U ^V ^W */ + +LYE_ERASE, LYE_NOP, LYE_NOP, LYE_NOP, +/* ^X ^Y ^Z ESC */ + +LYE_NOP, LYE_NOP, LYE_UPPER, LYE_LOWER, +/* ^\ ^] ^^ ^_ */ + +/* sp .. RUBOUT */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_DELP, + +/* 80..9F ISO-8859-1 8-bit escape characters. */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_AIX, +/* 97 AIX */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, + +/* A0..FF (permissible ISO-8859-1) 8-bit characters. */ +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, +LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, + +/* 100..10E function key definitions in LYStrings.h */ +LYE_NOP, LYE_NOP, LYE_FORW, LYE_BACK, +/* UPARROW DNARROW RTARROW LTARROW */ + +LYE_NOP, LYE_NOP, LYE_BOL, LYE_EOL, +/* PGDOWN PGUP HOME END */ + +LYE_NOP, LYE_TAB, LYE_BOL, LYE_EOL, +/* F1 Do key Find key Select key */ + +LYE_NOP, LYE_DELP, LYE_NOP, LYE_NOP, +/* Insert key Remove key DO_NOTHING ... */ +}; + /* * Add the array name to LYLineEditors @@ -124,6 +232,7 @@ PUBLIC char * LYLineEditors[]={ DefaultEditBinding, /* You can't please everyone, so you ... DW */ + BetterEditBinding, /* No, you certainly can't ... /ked 10/27/98*/ }; /* @@ -131,7 +240,8 @@ * The order of LYLineEditors and LyLineditNames MUST be the same */ PUBLIC char * LYLineeditNames[]={ - "Default Binding ", + "Default Binding", + "Better Bindings", (char *) 0 }; diff -uNr lynx-2.8.1-rel.2.orig/lynx_help/Lynx_users_guide.html lynx-2.8.1-rel.2+kd/lynx_help/Lynx_users_guide.html --- lynx-2.8.1-rel.2.orig/lynx_help/Lynx_users_guide.html Tue Nov 3 15:43:03 1998 +++ lynx-2.8.1-rel.2+kd/lynx_help/Lynx_users_guide.html Mon Nov 2 23:01:03 1998 @@ -761,12 +761,16 @@ uppercase H, J, K, and L keys remain mapped to their configured bindings (normally HELP, JUMP, KEYMAP, and LIST, respectively). +

    Note: this has no effect on the line-editor's key bindings. +

    Emacs keys
    If set to ON then the CTRL-P, CTRL-N, CTRL-F, and CTRL-B keys will be mapped to up-arrow, down-arrow, right-arrow, and left-arrow, respectively. Otherwise, they remain mapped to their configured bindings (normally UP_TWO lines, DOWN_TWO lines, NEXT_PAGE, and PREV_PAGE, respectively). + +

    Note: this has no effect on the line-editor's key bindings.

    Show dot files
    If display/creation of hidden (dot) files/directories is diff -uNr lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/edit_help.html lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/edit_help.html --- lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/edit_help.html Tue Nov 3 15:43:04 1998 +++ lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/edit_help.html Tue Nov 3 16:02:35 1998 @@ -10,31 +10,41 @@ Lynx invokes a built-in Line Editor for entering strings in response to prompts, in forms, and for email messages if an external editor has not been defined. Administrators can offer alternate key bindings -by adding them in LYEditmap.c before compiling Lynx, and they can -be selected via the 'o'ptions menu. This is the Default Binding: -
    -     ENTER  Input complete       -  RETURN
    -     TAB    Input complete       -  TAB, Do
    -     ABORT  Input cancelled      -  Ctrl-G, Ctrl-O, Ctrl-C
    -     ERASE  Erase the line       -  Ctrl-U, Ctrl-X
    -
    -     BACK   Cursor back    char  -  Left-Arrow
    -     FORW   Cursor forward char  -  Right-Arrow
    -     BACKW  Cursor back    word  -  Ctrl-P
    -     FORWW  Cursor forward word  -  Ctrl-N
    -     BOL    Go to begin of line  -  Ctrl-A, Home, Find
    -     EOL    Go to end   of line  -  Ctrl-E, End,  Select
    -
    -     DELP   Delete prev    char  -  Ctrl-H, DELETE, Remove
    -     DELC   Delete current char  -  Ctrl-D
    -     DELN   Delete next    char  -  Ctrl-R
    -     DELPW  Delete prev    word  -  Ctrl-B
    -     DELNW  Delete next    word  -  Ctrl-F
    +by adding them in LYEditmap.c before compiling Lynx.  If available, they may
    +be selected via the old-style 'o'ptions menu (see -forms_options command
    +line option), or by editing lineedit_mode in the .lynxrc file.
     
    -     LOWER  Lower case the line  -  Ctrl-K
    -     UPPER  Upper case the line  -  Ctrl-T
    +

    Note: setting emacs/vi keys ON has no effect on line-editor bindings. - LKCMD Invoke cmd prompt - Ctrl-V (in form text fields, only) +

    This is the Default Binding: + +

    +     ENTER  Input complete        -  RETURN
    +     TAB    Input complete        -  TAB, Do
    +     ABORT  Input cancelled       -  Ctrl-G, Ctrl-O, (Ctrl-C on some systems)
    +     ERASE  Erase the line        -  Ctrl-U, Ctrl-X
    +
    +     BACK   Cursor back     char  -  Left-Arrow
    +     FORW   Cursor forward  char  -  Right-Arrow
    +     BACKW  Cursor back     word  -  Ctrl-P
    +     FORWW  Cursor forward  word  -  Ctrl-N
    +     BOL    Go to begin of  line  -  Ctrl-A, Home, Find
    +     EOL    Go to end   of  line  -  Ctrl-E, End,  Select
    +
    +     DELP   Delete prev     char  -  Ctrl-H, DELETE, Remove
    +     DELN   Delete next [*] char  -  Ctrl-D, Ctrl-R
    +     DELPW  Delete prev     word  -  Ctrl-B
    +     DELNW  Delete next     word  -  Ctrl-F
    +     DELEOL Delete to end of line -  Ctrl-_
    +
    +     LOWER  Lower case the line   -  Ctrl-K
    +     UPPER  Upper case the line   -  Ctrl-T
    +
    +     LKCMD  Invoke cmd prompt     -  Ctrl-V (in form text fields, only)
    +
    +[*] "next" means the character "under" a box or underline style cursor; it
    +     means "to the immediate right of" an I-beam (between characters) type
    +     cursor.
     
    diff -uNr lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/option_help.html lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/option_help.html --- lynx-2.8.1-rel.2.orig/lynx_help/keystrokes/option_help.html Sat Oct 24 09:49:07 1998 +++ lynx-2.8.1-rel.2+kd/lynx_help/keystrokes/option_help.html Tue Nov 3 16:10:25 1998 @@ -68,6 +68,7 @@ to up-arrow, down-arrow, right-arrow and left-arrow respectively. Otherwise, they remain mapped to their configured bindings (normally UP_TWO lines, DOWN_TWO lines, NEXT_PAGE and PREV_PAGE respectively). +

    Note: setting emacs keys does not affect the line-editor bindings.

    Execution links

    @@ -170,6 +171,7 @@ to left-arrow, down-arrow, up-arrow and right-arrow respectively.

    The uppercase H, J, K, and L keys remain mapped to their configured bindings (normally HELP, JUMP, KEYMAP and LIST, respectively). +

    Note: setting vi keys does not affect the line-editor bindings.

    X DISPLAY variable

    ##--eof--## From owner-lynx-dev@sig.net Tue Nov 3 21:36:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA22327 for ; Tue, 3 Nov 1998 21:36:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA11809; Tue, 3 Nov 1998 20:25:49 -0600 (CST) Date: Wed, 4 Nov 1998 11:28:43 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811040228.LAA14264@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev compiler warning in HTFile.c:1065 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 437 Lines: 8 got the following compiler warning (2.8.1rel.1, SunOS4.1.3, slang1.2.2): WW/Library/Implementation -O2 -DSUN -DSUN4 -I../../../WWW/Library/Implementati on/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTFile.c ../../../WWW/Library/Implementation/HTFile.c: In function `HTEditable': ../../../WWW/Library/Implementation/HTFile.c:1065: warning: passing arg 2 of `ge tgroups' from incompatible pointer type __Henry From owner-lynx-dev@sig.net Tue Nov 3 22:11:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA26027 for ; Tue, 3 Nov 1998 22:11:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA17211; Tue, 3 Nov 1998 20:55:18 -0600 (CST) From: dickey@clark.net Message-Id: <199811040257.VAA17676@shell.clark.net> Subject: Re: lynx-dev compiler warning in HTFile.c:1065 To: lynx-dev@sig.net Date: Tue, 3 Nov 1998 21:57:01 -0500 (EST) In-Reply-To: <199811040228.LAA14264@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 4, 98 11:28: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: 1175 Lines: 26 > > got the following compiler warning (2.8.1rel.1, SunOS4.1.3, slang1.2.2): > > WW/Library/Implementation -O2 -DSUN -DSUN4 -I../../../WWW/Library/Implementati > on/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTFile.c > ../../../WWW/Library/Implementation/HTFile.c: In function `HTEditable': > ../../../WWW/Library/Implementation/HTFile.c:1065: warning: passing arg 2 of `ge > tgroups' from incompatible pointer type This is what's going on (I'm not at the moment certain whether you're seeing a bug or a feature): getgroups takes an argument which is an array of gid_t. For the normal SunOS 4.x, this is really an integer (int), but the /5lib environment can really be a short integer. But that's tested properly if you're using the compilers designed for that purpose. I think configuring with gcc confuses things a little because the declaration of gid_t is really a short in both cases -- but when I studied this a month or so ago, it seemed to be doing the right thing in the configure script (including for slang). But I'll look at it again. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 3 22:49:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA28686 for ; Tue, 3 Nov 1998 22:49:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23708; Tue, 3 Nov 1998 21:29:56 -0600 (CST) Date: Tue, 3 Nov 1998 22:32:30 -0500 (EST) From: Wayne Buttles To: lynx-dev Subject: lynx-dev ssl check 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: 608 Lines: 15 I have been playing with lynx and ssl proxy. I was hoping someone could try these links and tell me if they have more success. https://mozilla-crypto.ssleay.org/cryptocheck.php The proxy tells me that I failed to establish a cipher. https://www.thawte.com/ucgi/browsercheck.exe I connect, but apparently this browsercheck can't handle lynx? I was really hoping to find some good places to test out ssl. I even tried a shopping cart, but it didn't work. For some reason my items didn't cary with me to the secure session. I guess that is an issue for another time. So where does lynx and ssl work? From owner-lynx-dev@sig.net Tue Nov 3 22:51:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA29361 for ; Tue, 3 Nov 1998 22:51:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA25661; Tue, 3 Nov 1998 21:40:25 -0600 (CST) Date: Wed, 4 Nov 1998 12:43:30 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811040343.MAA17146@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev ssl check Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 720 Lines: 17 > another time. So where does lynx and ssl work? These are REALLY old, but they're what I used to use for testing: WellsFarg PAWWSFinan SSLapache netscape verisign thawte tis c2 rsa SSLnews netscape.appfoundry.tools.next __Henry From owner-lynx-dev@sig.net Tue Nov 3 22:57:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA29635 for ; Tue, 3 Nov 1998 22:57:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA26258; Tue, 3 Nov 1998 21:43:16 -0600 (CST) Date: Wed, 4 Nov 1998 12:46:23 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811040346.MAA17162@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1168 Lines: 30 Downloaded lynx2-8-1-rel2-intl.tar.gz, and tried it. Got the following fatal error (SunOS4.1.3): cd po && make CC="gcc" make: Fatal error in reader: makefile, line 132: Macro assignment on dependency line Current working directory /home3/nelsonhe/.lynx/lynx2-8-1-rel2-intl/po *** Error code 1 make: Fatal error: Command failed for target `all' I removed all the .po and .gmo files in subdirectory /po. I put in a file, ja.po, which starts the process of moving strings from LYMessages before I begin the translation task. You can see the file I used at: http://www.irm.nara.kindai.ac.jp/lynxdev/docs/ja.po.bz2. I set the environment variable `setenv LINGUAS "ja"` before running ./configure. Couple of questions. Can I assume that po/lynx.pot is the complete catalogue up to that date? I'd like to go ahead and get the lot translated. (Let you and Tom get it to compile :) To make a *.po file for a particular language can I just fill in the ``msgstr ""'' between the double quotes? What's a "*.gmo" file and how do I make it for the language I want? Even though I set LINGUAS, "POFILES and GMOFILES" in po/makefile don't seem to have "ja" listed.. __Henry From owner-lynx-dev@sig.net Wed Nov 4 02:01:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA16036 for ; Wed, 4 Nov 1998 02:01:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA22400; Wed, 4 Nov 1998 00:48:42 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811040650.XAA20282@sanitas> Subject: lynx-dev Misplaced?
    breaks anchor. To: lynx-dev@sig.net (Lynx List) Date: Tue, 3 Nov 1998 23:50:03 -0700 (MST) 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: 894 Lines: 29 Hello, Lyncei, YA example of bad? HTML breaking Lynx (attached (excerpted)). Intuitively, I feel
    has little business appearing between and . But that's the way the page is. Is there some spec I can show the page authors? I think they really wanted
    • ...
    , not
    ...
    , especially since they nested
    ...
    containers. Weblint didn't complain about it. :-( gil ============================================================== Continuus/CM 4.5 Help, UNIX Client Continuus Software Corporation
    Continuus/CM 4.5 Help, UNIX Client



    whatever This link works OK.
    This link doesn't appear.


    Copyright © 1998, Continuus Software Corporation. All rights reserved. From owner-lynx-dev@sig.net Wed Nov 4 02:32:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA19761 for ; Wed, 4 Nov 1998 02:32:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA25259; Wed, 4 Nov 1998 01:17:22 -0600 (CST) From: David Woolley Message-Id: <199811030840.IAA02547@djwhome.demon.co.uk> Subject: Re: lynx-dev View French accents in Win32 Lynx. To: lynx-dev@sig.net Date: Tue, 3 Nov 1998 08:40:39 +0000 (GMT) In-Reply-To: <4990-Mon02Nov1998130627-0600-demers@IRO.UMontreal.CA> from "Francois-Nicola Demers" at Nov 2, 98 01:06:27 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: 366 Lines: 6 > I am unable to see French accents in Win32 Lynx. The accents are > replaced by wrong chars. Make sure that your Lynx display character set is compatible with the font in use and that the files are either in ISO 8859/1 character set (web default) or are being served with correct HTTP headers for then one used, or you have over-ridden the character set in Lynx. From owner-lynx-dev@sig.net Wed Nov 4 03:13:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA23983 for ; Wed, 4 Nov 1998 03:13:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA29107; Wed, 4 Nov 1998 01:58:35 -0600 (CST) Date: Wed, 4 Nov 1998 00:00:25 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev Subject: Re: lynx-dev ssl check 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: 359 Lines: 11 On Tue, 3 Nov 1998, Wayne Buttles wrote: > I was really hoping to find some good places to test out ssl. I even > tried a shopping cart, but it didn't work. For some reason my items Try "http://www.moxienet.com/lynx/ssl-test/" Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Wed Nov 4 05:52:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA13463 for ; Wed, 4 Nov 1998 05:52:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11694; Wed, 4 Nov 1998 04:39:17 -0600 (CST) Message-ID: <19981104054029.A422@bcpl.net> Date: Wed, 4 Nov 1998 05:40:29 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 References: <199811040346.MAA17162@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811040346.MAA17162@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Wed, Nov 04, 1998 at 12:46:23PM +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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 4886 Lines: 144 On Wed, Nov 04, 1998 at 12:46:23PM +0900, Nelson Henry Eric wrote: > Downloaded lynx2-8-1-rel2-intl.tar.gz, and tried it. > > Got the following fatal error (SunOS4.1.3): > > cd po && make CC="gcc" > make: Fatal error in reader: makefile, line 132: Macro assignment on dependency > line > Current working directory /home3/nelsonhe/.lynx/lynx2-8-1-rel2-intl/po > *** Error code 1 > make: Fatal error: Command failed for target `all' > > I removed all the .po and .gmo files in subdirectory /po. I put in a > file, ja.po, which starts the process of moving strings from LYMessages > before I begin the translation task. You can see the file I used at: > http://www.irm.nara.kindai.ac.jp/lynxdev/docs/ja.po.bz2. I set the > environment variable `setenv LINGUAS "ja"` before running ./configure. > > Couple of questions. > Can I assume that po/lynx.pot is the complete catalogue up to that date? > I'd like to go ahead and get the lot translated. (Let you and Tom get > it to compile :) > > To make a *.po file for a particular language can I just fill in the > ``msgstr ""'' between the double quotes? > > What's a "*.gmo" file and how do I make it for the language I want? > > Even though I set LINGUAS, "POFILES and GMOFILES" in po/makefile don't > seem to have "ja" listed.. Lynx.pot was generated by running: xgettext -f /j/files.t -F -j -p po -d lynx where files.t contains the hopefully complete list of modules containing any gettext calls. The list is appended below. I've sent lynx.pot to the Free Translation Project and am waiting for their comments on the contents and procedures (see http://www.iro.umontreal.ca/contrib/po/). I have used emacs with `po-mode.el' to edit some of the sample po files. You can use any method you like, but in order to have a wider distribution of your translations, I'd like to use the FT Project rules, which include sending hard copy releases to the GNU project. The gmo file is the machine specific language object. The po makefile.in generates code intended for gcc, which I had to use under Digital UNIX to build that directory. Michael T. Smith told me this about Solaris: > I've been fixing CSuite il8n on Solaris for the past few days. The > display wasn't working because > > 1. Solaris has its own gettext built into libc; /usr/lib/libintl > has stubs for the functions (isn't required in the link anymore) > 2. Need to use Solaris msgfmt - /usr/bin/msgfmt - not GNU msgfmt > 3. Errors in the PO file were causing Solaris msgfmt to create a > corrupt message catalog -- needed to use -v to catch these > > I've sent you the lynx.po file I'm using (I've just commented out the > duplicate strings) -- apologies if it's too large for your mailbox. On > Solaris make sure you run > > msgfmt -v -o lynx.mo lynx.po > > then copy lynx.mo into (LOCALEDIR)/fr/LC_MESSAGES/. > > I forget where in Lynx LOCALEDIR is defined; we use > /var/csuite/intl/locale/ but /usr/locale or /usr/local/locale is > probably the default. I'm still learning how to set this all up. I had picked a few languages somewhat randomly at first. Only "fr" has a good sample translation file currently. "de", "it", "pt", and "sp" have rough translations for the "lynx -v" message and "it" has a few lines I hand-edited. *VERY IMPORTANT* [download, read, sign and snail-mail this to FSF:] http://www.iro.umontreal.ca/contrib/po/DISCLAIM [references] http://www.iro.umontreal.ca/~pinard/ http://www.iro.umontreal.ca/contrib/po/AUTHORS http://www.iro.umontreal.ca/contrib/po/languages http://www.iro.umontreal.ca/contrib/po/reply [files.t] src/GridText.c src/HTAlert.c src/HTFWriter.c src/HTInit.c src/HTML.c src/LYBookmark.c src/LYCgi.c src/LYCharUtils.c src/LYClean.c src/LYCookie.c src/LYCurses.c src/LYDownload.c src/LYEdit.c src/LYExtern.c src/LYForms.c src/LYGetFile.c src/LYHistory.c src/LYJump.c src/LYKeymap.c src/LYLeaks.c src/LYList.c src/LYLocal.c src/LYMail.c src/LYMain.c src/LYMainLoop.c src/LYMap.c src/LYNews.c src/LYOptions.c src/LYPrint.c src/LYReadCFG.c src/LYSearch.c src/LYShowInfo.c src/LYStrings.c src/LYStyle.c src/LYTraversal.c src/LYUpload.c src/LYUtils.c src/LYexit.c src/LYrcFile.c WWW/Library/Implementation/HTAABrow.c WWW/Library/Implementation/HTAAProt.c WWW/Library/Implementation/HTAccess.c WWW/Library/Implementation/HTFTP.c WWW/Library/Implementation/HTFWriter.c WWW/Library/Implementation/HTFinger.c WWW/Library/Implementation/HTFormat.c WWW/Library/Implementation/HTGopher.c WWW/Library/Implementation/HTMIME.c WWW/Library/Implementation/HTNews.c WWW/Library/Implementation/HTRules.c WWW/Library/Implementation/HTStyle.c WWW/Library/Implementation/HTTCP.c WWW/Library/Implementation/HTTP.c WWW/Library/Implementation/HTVMSUtils.c WWW/Library/Implementation/HTWAIS.c WWW/Library/Implementation/HTWSRC.c ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Wed Nov 4 05:52:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA13472 for ; Wed, 4 Nov 1998 05:52:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11776; Wed, 4 Nov 1998 04:40:11 -0600 (CST) From: dickey@clark.net Message-Id: <199811041042.FAA13222@shell.clark.net> Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 To: lynx-dev@sig.net Date: Wed, 4 Nov 1998 05:42:03 -0500 (EST) In-Reply-To: <199811040346.MAA17162@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 4, 98 12:46: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: 1297 Lines: 35 > I removed all the .po and .gmo files in subdirectory /po. I put in a > file, ja.po, which starts the process of moving strings from LYMessages > before I begin the translation task. You can see the file I used at: > http://www.irm.nara.kindai.ac.jp/lynxdev/docs/ja.po.bz2. I set the > environment variable `setenv LINGUAS "ja"` before running ./configure. I got a copy (though I don't read Japanese ;-) > Couple of questions. > Can I assume that po/lynx.pot is the complete catalogue up to that date? > I'd like to go ahead and get the lot translated. (Let you and Tom get > it to compile :) I'll do that... > To make a *.po file for a particular language can I just fill in the > ``msgstr ""'' between the double quotes? > > What's a "*.gmo" file and how do I make it for the language I want? > > Even though I set LINGUAS, "POFILES and GMOFILES" in po/makefile don't > seem to have "ja" listed.. I don't think this will be solved rapidly -- the people working on the message support are mostly in Europe. 8-bit character sets will probably work, but not 16-bit characters (I assume that's what you want?) I'm not sure how to test this (suggestions on fonts, etc., are welcome) > __Henry > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 4 07:05:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA22728 for ; Wed, 4 Nov 1998 07:05:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA17398; Wed, 4 Nov 1998 05:49:57 -0600 (CST) Date: Wed, 4 Nov 1998 20:53:01 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811041153.UAA18808@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2014 Lines: 53 > > Got the following fatal error (SunOS4.1.3): > > cd po && make CC="gcc" make: Fatal error in reader: makefile, line > > 132: Macro assignment on dependency Any idea at all what this is? How I might work around it? > Lynx.pot was generated by running: xgettext -f /j/files.t -F -j -p po > -d lynx > where files.t contains the hopefully complete list of modules > containing This is good info to know. Thanks. > The gmo file is the machine specific language object. The po > makefile.in generates code intended for gcc, which I had to use under > Digital UNIX to build that directory. I guess I was a bit too optimistic about all this. Should I be working on getting the po directory to compile first, and then go to Lynx? The intl directory seemed to successfully compile, which maybe got my hopes up too high. > Michael T. Smith told me this about Solaris: > > I've been fixing CSuite il8n on Solaris for the past few days. The The rest of this is WAY beyond my capabilities. Other than join the ja@li.org, which I did, is there anything I can be doing? I'll have to do much of the work on SunOS4.1.3, at least initially. Later I will get back on to the Solaris2.6 available to me. > > duplicate strings) -- apologies if it's too large for your > > mailbox. On Solaris make sure you run > > msgfmt -v -o lynx.mo lynx.po So this is how to make the *.gmo file? Where do you come by msgfmt? > > then copy lynx.mo into (LOCALEDIR)/fr/LC_MESSAGES/. > > I forget where in Lynx LOCALEDIR is defined; we use > > /var/csuite/intl/locale/ but /usr/locale or /usr/local/locale is > > probably the default. I assume all of this can be done within my $HOME directory? > I'm still learning how to set this all up. I had picked a few > languages If you have any hints, throw'em my way. I'm totally lost. > *VERY IMPORTANT* [download, read, sign and snail-mail this to FSF:] > http://www.iro.umontreal.ca/contrib/po/DISCLAIM Downloaded and read. Will complete soon. __Henry From owner-lynx-dev@sig.net Wed Nov 4 07:43:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA26556 for ; Wed, 4 Nov 1998 07:43:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA21015; Wed, 4 Nov 1998 06:29:06 -0600 (CST) Date: Wed, 4 Nov 1998 07:31:39 -0500 (EST) From: Wayne Buttles To: lynx-dev Subject: Re: lynx-dev ssl check 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: 597 Lines: 20 On Wed, 4 Nov 1998, Doug Kaufman wrote: > On Tue, 3 Nov 1998, Wayne Buttles wrote: > > I was really hoping to find some good places to test out ssl. I even > > tried a shopping cart, but it didn't work. For some reason my items > > Try "http://www.moxienet.com/lynx/ssl-test/" Moxinet worked, but that only made me wonder if that was because it was set up with the notion of accepting ssleay clients making it more likely to work than other sites. > Doug > __ > Doug Kaufman > Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu > From owner-lynx-dev@sig.net Wed Nov 4 08:09:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA30291 for ; Wed, 4 Nov 1998 08:09:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA21896; Wed, 4 Nov 1998 06:37:41 -0600 (CST) Message-ID: <19981104073852.A24373@mail.bcpl.net> Date: Wed, 4 Nov 1998 07:38:52 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 References: <199811041153.UAA18808@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811041153.UAA18808@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Wed, Nov 04, 1998 at 08:53:01PM +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.93.2i (1998-07-29) 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: 2908 Lines: 61 On Wed, Nov 04, 1998 at 08:53:01PM +0900, Nelson Henry Eric wrote: > > > Got the following fatal error (SunOS4.1.3): > > > cd po && make CC="gcc" make: Fatal error in reader: makefile, line > > > 132: Macro assignment on dependency > Any idea at all what this is? How I might work around it? Sorry, I meant "GNU make" was required (I said gcc). I (or someone) needs to revise the po/makefile.in to have it generate a makefile that is more generic. I know there are other make issues, such as the fact that "make distclean" didn't remove the NetBSD gmo files from that directory. > > The gmo file is the machine specific language object. The po > > makefile.in generates code intended for gcc, which I had to use under > > Digital UNIX to build that directory. > I guess I was a bit too optimistic about all this. Should I be working > on getting the po directory to compile first, and then go to Lynx? The > intl directory seemed to successfully compile, which maybe got my hopes > up too high. It compiles on several UNIX flavors now, so Sun shouldn't be too hard. I got an earlier run to compile on SLCC, but got no messages. > > Michael T. Smith told me this about Solaris: > > > I've been fixing CSuite il8n on Solaris for the past few days. The > The rest of this is WAY beyond my capabilities. Other than join the > ja@li.org, which I did, is there anything I can be doing? I'll have to > do much of the work on SunOS4.1.3, at least initially. Later I will get > back on to the Solaris2.6 available to me. Once these patches are more widely tested, I expect other user help. > > > duplicate strings) -- apologies if it's too large for your > > > mailbox. On Solaris make sure you run > > > msgfmt -v -o lynx.mo lynx.po > So this is how to make the *.gmo file? Where do you come by msgfmt? Yes; it may be on SunOS. If not, try building this for reference: http://www.suse.de/~ke/hello-1.3.18.tar.gz msgfmt is part of GNU gettext (see your local GNU site for this). I used hello to figure out how to do international text, then copied its' rules plus references from CSuite to build by version. > > > then copy lynx.mo into (LOCALEDIR)/fr/LC_MESSAGES/. > > > I forget where in Lynx LOCALEDIR is defined; we use > > > /var/csuite/intl/locale/ but /usr/locale or /usr/local/locale is > > > probably the default. > I assume all of this can be done within my $HOME directory? I haven't done this other than root, although it should be feasible to have LOCALEDIR be under $HOME. > > I'm still learning how to set this all up. I had picked a few > > languages > If you have any hints, throw'em my way. I'm totally lost. See if hello compiles. There is one Japanese author in the AUTHOR file who may be able to help you. ------ Marvin the Paranoid Android says: Oh, not another one... From owner-lynx-dev@sig.net Wed Nov 4 08:24:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA32066 for ; Wed, 4 Nov 1998 08:24:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA24666; Wed, 4 Nov 1998 07:02:36 -0600 (CST) From: dickey@clark.net Message-Id: <199811041304.IAA29494@shell.clark.net> Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 To: lynx-dev@sig.net Date: Wed, 4 Nov 1998 08:04:28 -0500 (EST) In-Reply-To: <199811041153.UAA18808@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 4, 98 08:53:01 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: 1321 Lines: 35 > > > Got the following fatal error (SunOS4.1.3): > > > cd po && make CC="gcc" make: Fatal error in reader: makefile, line > > > 132: Macro assignment on dependency > > Any idea at all what this is? How I might work around it? not yet (haven't studied this stuff yet). I think I know what to look for. > > Lynx.pot was generated by running: xgettext -f /j/files.t -F -j -p po > > -d lynx > > where files.t contains the hopefully complete list of modules > > containing > > This is good info to know. Thanks. > > > The gmo file is the machine specific language object. The po > > makefile.in generates code intended for gcc, which I had to use under > > Digital UNIX to build that directory. > > I guess I was a bit too optimistic about all this. Should I be working > on getting the po directory to compile first, and then go to Lynx? The > intl directory seemed to successfully compile, which maybe got my hopes > up too high. I think I'll probably have to sanitize this stuff - some of the people working on GNU software have a bad attitude about portability, and intentionally put in things that make their tools build only with GNU software. (vendor-lockin is a Bad Thing, no matter what color your hat is). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 4 09:40:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA09087 for ; Wed, 4 Nov 1998 09:40:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA09799; Wed, 4 Nov 1998 08:24:36 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811041425.HAA20965@sanitas> Subject: Re: lynx-dev Misplaced?
    breaks anchor. To: lynx-dev@sig.net Date: Wed, 4 Nov 1998 07:25:55 -0700 (MST) In-Reply-To: <199811040650.XAA20282@sanitas> from "pg@sweng.stortek.com" at Nov 3, 98 11:50:03 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: 310 Lines: 11 In a recent note, pg@sweng.stortek.com said: > Date: Tue, 3 Nov 1998 23:50:03 -0700 (MST) > > Intuitively, I feel
    has little business appearing between > and . But that's the way the page is. > (Following up my own posting) I forgot to try -tagsoup. It works better with -tagsoup. gil From owner-lynx-dev@sig.net Wed Nov 4 09:56:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA10248 for ; Wed, 4 Nov 1998 09:56:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA15290; Wed, 4 Nov 1998 08:43:37 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Wed, 4 Nov 1998 09:45:55 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev Subject: Re: lynx-dev ssl check 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: 1248 Lines: 32 On Tue, 3 Nov 1998, Wayne Buttles wrote: > I have been playing with lynx and ssl proxy. I was hoping someone could > try these links and tell me if they have more success. > > https://mozilla-crypto.ssleay.org/cryptocheck.php > > The proxy tells me that I failed to establish a cipher. > > https://www.thawte.com/ucgi/browsercheck.exe > > I connect, but apparently this browsercheck can't handle lynx? Both work fine with my Lynx/SSleay. > I was really hoping to find some good places to test out ssl. I even tried > a shopping cart, but it didn't work. For some reason my items didn't cary > with me to the secure session. I guess that is an issue for another time. > So where does lynx and ssl work? I've already bought things using secure servers without any problem. I don't know about Lynx and a SSL proxy but Lynx with SSLeay has worked in all sites I tried. 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 Wed Nov 4 10:25:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA13653 for ; Wed, 4 Nov 1998 10:24:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA21580; Wed, 4 Nov 1998 09:04:00 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Wed, 4 Nov 1998 18:00:00 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev -cookie_file problem 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: 611 Lines: 18 Currently, cookie file stored in .lynxrc when you save from the Options menu (automatically). I feel command line switches (if any) should override values from .lynxrc to give user more flexibility. Currently not: in LYMain.c read_rc() at line 1380, but parse_arg() in lines 608, 1349, 1362. In particular, command-line switch -cookie_file=name have no effect when you save data from 2.8.1rel1 Option menu at least once. The same for -partial_thres, probably also for -color and -nocolor (if no "default" value in .lynxrc) Hope read_rc() should be moved before parse_arg(), just after read_cfg(). Leonid. From owner-lynx-dev@sig.net Wed Nov 4 11:05:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA19008 for ; Wed, 4 Nov 1998 11:05:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA04016; Wed, 4 Nov 1998 09:44:18 -0600 (CST) Message-Id: <4.1.19981104102352.00a2db00@pop.ma.ultranet.com> X-Sender: gregmm@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 04 Nov 1998 10:44:09 -0500 To: lynx-dev@sig.net From: Greg Marr Subject: Re: lynx-dev different versions of lynx.. different outputs. In-Reply-To: References: <199810291321.IAA00552@chass.utoronto.ca> 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: 1524 Lines: 39 At 11:28 AM 10/29/98 , you wrote: >> > When I change the tags to >> >
    ..blah blah blah
    >> > >> > both versions of lynx have the same centered output. >> > Any ideas of what could the problem be here ? >> >> the problem is yet another piece of HTML pedantry (grimace): >> i raised this very issue a couple of months ago: >> see the Archive for 9809 (probably). > >Please, let's not consider another "well, everyone else is doing it, so >we can/should break spec". > > has an ALIGN attribute, which is the proper way (as I read the >spec) to center it. > >
    is only a text element. > >(This has probably all been said before...) If it has, it was said incorrectly.
    is not a text element.
    is a synonym for
    , which is a block level element.
    ...
    ,
    ...
    and should all produce the same output. However, many versions of the major browsers don't see it this way, especially the ones before
    was defined as
    , and was just whatever NS wanted it to be.
    ...
    is invalid HTML since can only contain CAPTION, COL, COLGROUP, THEAD, TFOOT and TBODY. TBODY's start and end tags can be omitted, and TBODY can contain only TR. Thus, CENTER isn't allowed in that location. -- 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 Wed Nov 4 11:24:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA21287 for ; Wed, 4 Nov 1998 11:24:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA11208; Wed, 4 Nov 1998 10:07:31 -0600 (CST) Date: Wed, 4 Nov 1998 08:09:21 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev -cookie_file problem 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: 882 Lines: 23 On Wed, 4 Nov 1998, Leonid Pauzner wrote: > Currently, cookie file stored in .lynxrc when you save > from the Options menu (automatically). > > I feel command line switches (if any) should override > values from .lynxrc to give user more flexibility. > Currently not: > in LYMain.c read_rc() at line 1380, > but parse_arg() in lines 608, 1349, 1362. > > In particular, command-line switch -cookie_file=name > have no effect when you save data from 2.8.1rel1 Option menu at least once. > The same for -partial_thres, > probably also for -color and -nocolor (if no "default" value in .lynxrc) > > Hope read_rc() should be moved before parse_arg(), just after read_cfg(). Unless there's some other reason to keep things as they are, I agree. -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Wed Nov 4 11:35:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA22818 for ; Wed, 4 Nov 1998 11:35:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14166; Wed, 4 Nov 1998 10:17:21 -0600 (CST) Date: Wed, 4 Nov 1998 08:19:09 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev different versions of lynx.. different outputs. In-Reply-To: <4.1.19981104102352.00a2db00@pop.ma.ultranet.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: 1571 Lines: 38 On Wed, 4 Nov 1998, Greg Marr wrote: > At 11:28 AM 10/29/98 , you wrote: > >> > When I change the tags to > >> >
    ..blah blah blah
    > >> > > >> > both versions of lynx have the same centered output. > >> > Any ideas of what could the problem be here ? > >> > >> the problem is yet another piece of HTML pedantry (grimace): > >> i raised this very issue a couple of months ago: > >> see the Archive for 9809 (probably). [BJP:] > >Please, let's not consider another "well, everyone else is doing it, so > >we can/should break spec". > > > > has an ALIGN attribute, which is the proper way (as I read the > >spec) to center it. > > > >
    is only a text element. > > > >(This has probably all been said before...) > > If it has, it was said incorrectly.
    is not a text element.
    > is a synonym for
    , which is a block level element. >
    ...
    ,
    ...
    > and should all produce the same output. However, many > versions of the major browsers don't see it this way, especially the ones > before
    was defined as
    , and was just whatever NS > wanted it to be. Okay, remind me to stop trying to parse HTML specs. I just looked back at the spec and it says exactly what you said. I think I misread "CENTER - text alignment" as "text element". -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Wed Nov 4 14:31:25 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.66]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA13833 for ; Wed, 4 Nov 1998 14:31:24 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA02790 for ; Wed, 4 Nov 1998 14:34:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA03121; Wed, 4 Nov 1998 13:04:49 -0600 (CST) From: mattack@area.com Date: Wed, 4 Nov 1998 11:06:12 -0800 (PST) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: lynx-dev Refresh... why isn't it supported? 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: 538 Lines: 10 I guess the answer will simply be "because nobody's written the code to do it".. But there seem to be enough servers that do a Refresh that it would be useful to support it. Is this actually Javascript code or something? Some seem to be really doing a redirect (I'm using this informally -- I just mean pointing you to a different URL), some just seem to be effectively hitting the "reload" command. (Wells Fargo is an example of the latter -- I simply have to manually refresh at the 'looking up your account info' page to get on..) From owner-lynx-dev@sig.net Wed Nov 4 20:59:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA16671 for ; Wed, 4 Nov 1998 20:59:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA17139; Wed, 4 Nov 1998 19:45:26 -0600 (CST) Date: Wed, 4 Nov 1998 17:46:41 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Refresh... why isn't it supported? 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: 20 On Wed, 4 Nov 1998 mattack@area.com wrote: > Subject: lynx-dev Refresh... why isn't it supported? > > I guess the answer will simply be "because nobody's written the code to do > it".. But there seem to be enough servers that do a Refresh that it would > be useful to support it. I am not an expert on this, but I think that if you search the archive, you will see that this is intentional. Refresh is supported by activating its URL in the usual manner. This gives time to those users who need more time (e.g. with screen reader or speech) to examine the page. Control is in the hands of the user, who can activate refresh immediately or take time as needed, then activate refresh. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Wed Nov 4 21:19:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA20426 for ; Wed, 4 Nov 1998 21:19:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA21491; Wed, 4 Nov 1998 20:08:29 -0600 (CST) From: mattack@area.com Date: Wed, 4 Nov 1998 18:09:52 -0800 (PST) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Refresh... why isn't it supported? 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: 1224 Lines: 26 On Wed, 4 Nov 1998, Doug Kaufman wrote: >On Wed, 4 Nov 1998 mattack@area.com wrote: > >> Subject: lynx-dev Refresh... why isn't it supported? >> >> I guess the answer will simply be "because nobody's written the code to do >> it".. But there seem to be enough servers that do a Refresh that it would >> be useful to support it. > >I am not an expert on this, but I think that if you search the >archive, you will see that this is intentional. Refresh is supported >by activating its URL in the usual manner. This gives time to those >users who need more time (e.g. with screen reader or speech) to >examine the page. Control is in the hands of the user, who can >activate refresh immediately or take time as needed, then activate >refresh. But for something like the Wells Fargo web page, there's not a URL printed - like a lot of them say something like Refresh (0 seconds): http://URLHERE But Wells Fargo's doesn't do anything like that.. and unless someone knows the trick to manually reload, it doesn't do anything. So it seems like this should be an option then. I'd turn it on to always refresh. I mean, we *do* want this to act as closely to a "standard" (as in GUI) web browser as possible, don't we? I do.. From owner-lynx-dev@sig.net Wed Nov 4 22:46:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA00887 for ; Wed, 4 Nov 1998 22:46:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA06514; Wed, 4 Nov 1998 21:29:26 -0600 (CST) Date: Wed, 4 Nov 1998 19:30:44 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Refresh... why isn't it supported? 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: 973 Lines: 24 On Wed, 4 Nov 1998 mattack@area.com wrote: > On Wed, 4 Nov 1998, Doug Kaufman wrote: > >On Wed, 4 Nov 1998 mattack@area.com wrote: > > > But for something like the Wells Fargo web page, there's not a URL > printed - like a lot of them say something like > Refresh (0 seconds): http://URLHERE > > But Wells Fargo's doesn't do anything like that.. and unless someone knows > the trick to manually reload, it doesn't do anything. So it seems like > this should be an option then. I'd turn it on to always refresh. I mean, > we *do* want this to act as closely to a "standard" (as in GUI) web browser > as possible, don't we? I do.. I just looked at the web page at "http://www.wellsfargo.com/home/" and don't see Refresh on any of their pages. Exactly what do you see and what do you expect the browser to do? Please give example URL's if possible. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Thu Nov 5 02:57:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA26577 for ; Thu, 5 Nov 1998 02:57:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA09031; Thu, 5 Nov 1998 01:40:32 -0600 (CST) From: David Woolley Message-Id: <199811040848.IAA04332@djwhome.demon.co.uk> Subject: lynx-dev Suppressing Status and Menu Lines (was: [ no subject ] ) To: lynx-dev@sig.net Date: Wed, 4 Nov 1998 08:48:16 +0000 (GMT) Cc: sysenet@yahoo.com In-Reply-To: <19981103154953.29267.rocketmail@send202.yahoomail.com> from "Dan Stumbaugh" at Nov 3, 98 07:49:53 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: 1289 Lines: 29 > I am using Lynx 2.8.1 released for Win32 running on WindowsNT 4.0. I > am having trouble getting rid of the border/margin that lynx seems to Lynx doesn't generate any left or right margins. You can reduce the menu and status areas to one line each (total 2) by selecting advanced user mode. Removing the first and last lines entirely probably requires a source code change. > add. I am working with a very small terminal (21 columns by 8 lines) > and can=92t afford to have borders. I have set my Web pages to > =93=94 which shows up on = ^^^^^^^^^ This is a proprietory Microsoft feature, and not really intended for your useage; I presume it is intended to lock people into the page by disabling the controls, as much as to give a clean window. > =93=94 which shows up on = ^^^ ^^^ These characters are not compatible with your explicitly declared character set, which was: Content-Type: text/plain; charset=us-ascii and do not exist in the default HTTP character set, the HTML character set at all, or in the most commonly used 8 bit character set for email (ISO 8859/1, Unicode and ISO 8859/1 respectively). From owner-lynx-dev@sig.net Thu Nov 5 02:58:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA26589 for ; Thu, 5 Nov 1998 02:58:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA09064; Thu, 5 Nov 1998 01:40:49 -0600 (CST) From: David Woolley Message-Id: <199811040743.HAA04221@djwhome.demon.co.uk> Subject: Re: lynx-dev Misplaced?
    breaks anchor. To: lynx-dev@sig.net Date: Wed, 4 Nov 1998 07:43:20 +0000 (GMT) In-Reply-To: <199811040650.XAA20282@sanitas> from "pg@sweng.stortek.com" at Nov 3, 98 11:50:03 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: 373 Lines: 10 > Is there some spec I can show the page authors? I think they HTML 4.0. The contents of a can only be %inline elements, whereas dd can only appear immediately subordinate to dl. Both are sufficient for error recovery to infer a /a. Note that weblint is really a style checker, for this you want something like nsgmls, or the web front end to it at validator.w3.org. From owner-lynx-dev@sig.net Thu Nov 5 05:20:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA19057 for ; Thu, 5 Nov 1998 05:20:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA20763; Thu, 5 Nov 1998 04:02:12 -0600 (CST) Date: Thu, 5 Nov 1998 19:05:11 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811051005.TAA07828@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 759 Lines: 22 Okay it's coming along. Can you help me get out of this one: collect2: ld returned 2 exit status ld: Undefined symbol _eTAlert *** Error code 1 make: Fatal error: Command failed for target `lynx' Also, after working with NLS and gettext, I very much question whether we really want the gettext package within Lynx (the intl and po directories, etc.). I think anyone setting it up (and this really is something best done by the sysadmin, although a personal user can do it) will find it MUCH easier to download the whole gettext package and install the intl library and tools first. I think Lynx could best support multi-languages with a good document on how to setup gettext, rather than try to get configure to do it for everyone -- on un*x. __Henry From owner-lynx-dev@sig.net Thu Nov 5 05:50:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA21778 for ; Thu, 5 Nov 1998 05:50:25 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA23383; Thu, 5 Nov 1998 04:37:15 -0600 (CST) Message-ID: <19981105053835.A395@bcpl.net> Date: Thu, 5 Nov 1998 05:38:35 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 References: <199811051005.TAA07828@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811051005.TAA07828@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Thu, Nov 05, 1998 at 07:05:11PM +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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 1399 Lines: 34 On Thu, Nov 05, 1998 at 07:05:11PM +0900, Nelson Henry Eric wrote: > collect2: ld returned 2 exit status > ld: Undefined symbol > _eTAlert > *** Error code 1 > make: Fatal error: Command failed for target `lynx' HTFWriter.c:494: eTAlert(EXECUTION_DISABLED); Change this to: HTAlert(gettext("Execution is disabled.")); A typo on my part since I haven't tried all options yet. (Oh No, ET alert! :-) > Also, after working with NLS and gettext, I very much question > whether we really want the gettext package within Lynx (the intl > and po directories, etc.). I think anyone setting it up (and > this really is something best done by the sysadmin, although a > personal user can do it) will find it MUCH easier to download > the whole gettext package and install the intl library and tools > first. > I think Lynx could best support multi-languages with a good > document on how to setup gettext, rather than try to get > configure to do it for everyone -- on un*x. I respect your opinion, particularly on keeping down bloat. I don't think the intl directory adds that much (3000 lines of code), and I have promised to create distributions without the translation texts. For now, they are in there for testing and verification. With a bit of tweaking, we can get it to autoconfigure and install easier than it does now. ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Thu Nov 5 13:40:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA18074 for ; Thu, 5 Nov 1998 13:40:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA04444; Thu, 5 Nov 1998 12:23:27 -0600 (CST) From: mattack@area.com Date: Thu, 5 Nov 1998 10:24:51 -0800 (PST) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Refresh... why isn't it supported? 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: 756 Lines: 20 On Wed, 4 Nov 1998, Doug Kaufman wrote: >I just looked at the web page at "http://www.wellsfargo.com/home/" and >don't see Refresh on any of their pages. Exactly what do you see and >what do you expect the browser to do? Please give example URL's if >possible. No, I mean logging in.. 1) https://banking.wellsfargo.com 2) After you log in, you get [INLINE] Your banking session has been initiated. Verifying your sign on information... and here, you have to manually hit control-R to actually ever get to your bank account. No URL is shown that you can just hit return. Maybe I'm mistaken and this isn't the same as the refresh other sites use, but at least from the user interface point of view it seems the same. From owner-lynx-dev@sig.net Thu Nov 5 18:56:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA22454 for ; Thu, 5 Nov 1998 18:56:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA08002; Thu, 5 Nov 1998 17:40:21 -0600 (CST) Date: Fri, 6 Nov 1998 08:43:24 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811052343.IAA09705@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 656 Lines: 18 > > ld: Undefined symbol _eTAlert *** Error code 1 make: Fatal > > error: Command failed for target `lynx' > HTFWriter.c:494: eTAlert(EXECUTION_DISABLED); > Change this to: HTAlert(gettext("Execution is disabled.")); Thanks. I'll do my best to get a prototype working today. There are two other defines not handled yet which I've stuck in LYMessages_en.h for now. When it's working, I'll give you a complete report. > (Oh No, ET alert! :-) extra-Terrestrial no doubt. > texts. For now, they are in there for testing and verification. With Then everything is fine! I'll do what I can to help with a cookbook style doc for how to set it up. __Henry From owner-lynx-dev@sig.net Thu Nov 5 19:55:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA28686 for ; Thu, 5 Nov 1998 19:55:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA17333; Thu, 5 Nov 1998 18:29:39 -0600 (CST) From: "Jeffrey S. Farmer" Message-Id: <199811051920.OAA10456@acorn.net> Subject: lynx-dev lynx bookmarks bug? To: lynx-dev@sig.net Date: Thu, 5 Nov 98 14:20:34 EST Cc: af369@acorn.net (Jeffrey S. Farmer) X-Mailer: ELM [version 2.3.1 PL11] Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 801 Lines: 24 Dear lynx developer: On my lynx bookmarks page (version 2.8rel2, SCRI-net version 2.2 beta), r, y was not removing the highlighted link, but the link immediately preceding it. This was happening only with higher numbered (more recent, lower on the page) links. I narrowed the problem down to this link:
  • Before this link, r, y worked as it should; after, it didn't. I tried to delete this link (using r, y), but it wouldn't highlight. So I moved the highlight down to the next link, hit r, y, and the "bad" link disappeared. After removing the "bad" link, everything worked normally. I'm sure I lost several bookmarks I wanted to keep before I noticed the problem. Thanks for your work on lynx. -- Jeff Farmer af369@acorn.net From owner-lynx-dev@sig.net Thu Nov 5 20:26:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01394 for ; Thu, 5 Nov 1998 20:26:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA23313; Thu, 5 Nov 1998 19:04:36 -0600 (CST) From: Philip Webb Message-Id: <199811060105.UAA25935@chass.utoronto.ca> Subject: Re: lynx-dev lynx bookmarks bug? To: lynx-dev@sig.net Date: Thu, 5 Nov 1998 20:05:11 -0500 (EST) Cc: af369@acorn.net In-Reply-To: <199811051920.OAA10456@acorn.net> from "Jeffrey S. Farmer" at Nov 5, 98 02:20: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: 924 Lines: 22 981105 Jeffrey Farmer wrote: > Dear lynx developer: it's actually an international team of volunteers. > On my lynx bookmarks page (version 2.8rel2, SCRI-net version 2.2 beta), > r, y was not removing the highlighted link, > but the link immediately preceding it. this is a well-known bug with the bookmark page, which is rather sensitive to any editing. you should use an ordinary editor to delete a bookmark entry & make changes within URLs or bookmark titles. it's a good idea to keep a backup copy of your bookmark file too. Lynx 2-8-1rel.2 is now out, improving on 2-8 in several ways (not bookmarks): get it from 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 Nov 5 23:13:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA23701 for ; Thu, 5 Nov 1998 23:13:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23938; Thu, 5 Nov 1998 21:52:47 -0600 (CST) Message-Id: <199811060352.VAA19502@thune.mrc.org> Subject: Re: lynx-dev -cookie_file problem To: lynx-dev@sig.net Date: Thu, 5 Nov 1998 21:52:10 -0600 (CST) In-Reply-To: from "brian j. pardy" at Nov 4, 98 08:09:21 am From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 975 Lines: 24 Amazingly enough brian j. pardy said: > On Wed, 4 Nov 1998, Leonid Pauzner wrote: > > Currently, cookie file stored in .lynxrc when you save > > from the Options menu (automatically). > > > > I feel command line switches (if any) should override > > values from .lynxrc to give user more flexibility. > > Currently not: > > in LYMain.c read_rc() at line 1380, > > but parse_arg() in lines 608, 1349, 1362. > Unless there's some other reason to keep things as they are, I agree. If an option is overridden by the command line, then user goes into the options menu and saves it, will the value from the command line switch be the new default? What should the semantics behind this be? mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Thu Nov 5 23:22:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA24878 for ; Thu, 5 Nov 1998 23:22:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA27222; Thu, 5 Nov 1998 22:08:52 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Thu, 5 Nov 1998 23:11:21 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev lynx bookmarks bug? In-Reply-To: <199811051920.OAA10456@acorn.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: 1217 Lines: 32 On Thu, 5 Nov 1998, Jeffrey S. Farmer wrote: > On my lynx bookmarks page (version 2.8rel2, SCRI-net version 2.2 beta), r, > y was not removing the highlighted link, but the link immediately > preceding it. > > This was happening only with higher numbered (more recent, lower on the > page) links. I narrowed the problem down to this link: > >
  • ^ It's because that link has no name and lynx doesn't "see" it as a link. For example, with a link like that as "link 3" lynx would display * link 1 * link 2 * * link 4 * link 5 When you move your cursor down from "link 2" it moves to "link 4" because "link 3" is not "seen" by lynx. For the same reasons, if you try to remove "link 5", "link 4" will be removed instead. 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 Nov 5 23:43:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26895 for ; Thu, 5 Nov 1998 23:43:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA01199; Thu, 5 Nov 1998 22:32:32 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Thu, 5 Nov 1998 23:35:02 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev lynx bookmarks bug? In-Reply-To: <199811060105.UAA25935@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: 1772 Lines: 39 On Thu, 5 Nov 1998, Philip Webb wrote: > > On my lynx bookmarks page (version 2.8rel2, SCRI-net version 2.2 beta), > > r, y was not removing the highlighted link, but the link immediately > > preceding it. > > this is a well-known bug with the bookmark page, Well known?! Can you give some references of reports of that "bug"? > which is rather sensitive to any editing. I don't think it is when the person who edits it knows what he's doing. My bookmarks file is full of "arbitrary HTML markings" as Fote used to call them, like
    , ,

    , many
      pairs, etc. If you want see how it looks like go to http://www.ismael.cordeiro.com/links.html A problem existed in lynx 2.4 but was corrected with a small modification to LYBookmarks.c I submited and that was incorporated into 2.5. Since then I have no more problems removing links. If you want to see what it was about go to http://www.flora.org/lynx-dev/lynx-dev/9602/0142.html > you should use an ordinary editor to delete a bookmark entry > & make changes within URLs or bookmark titles. Deleting links (full lines) with a text editor does no harm. The problem is when editing a link. If the person doesn't know what he's doing, weird problems may appear. If lynx can't remove a link or removes the wrong link, probably the bookmarks file has been incorrectly edited. See my reply to Jeffrey S. Farmer's message. 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 Nov 5 23:44:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26903 for ; Thu, 5 Nov 1998 23:44:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA00829; Thu, 5 Nov 1998 22:29:44 -0600 (CST) Message-ID: <19981105203113.A29634@psnw.com> Date: Thu, 5 Nov 1998 20:31:13 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev -cookie_file problem Mail-Followup-To: lynx-dev@sig.net References: <199811060352.VAA19502@thune.mrc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811060352.VAA19502@thune.mrc.org>; from "Mike Castle" on Thu, Nov 05, 1998 at 09:52:10PM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 8:26pm up 13 days, 21:52, 4 users, load average: 1.00, 1.00, 1.00 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1029 Lines: 29 Mike Castle wrote: > Amazingly enough brian j. pardy said: > > On Wed, 4 Nov 1998, Leonid Pauzner wrote: > > > Currently, cookie file stored in .lynxrc when you save > > > from the Options menu (automatically). > > > > > > I feel command line switches (if any) should override > > > values from .lynxrc to give user more flexibility. > > > Currently not: > > > in LYMain.c read_rc() at line 1380, > > > but parse_arg() in lines 608, 1349, 1362. > > Unless there's some other reason to keep things as they are, I agree. > > > If an option is overridden by the command line, then user goes into the > options menu and saves it, will the value from the command line switch be > the new default? > > What should the semantics behind this be? Hmm. I'd say that a command-line option should pretty much be "this session only", and the options menu should reflect the current saved options. We might be evenly divided on this, though -- I can't think of compelling reasons to make it either specific way. -- FORTH IF HONK THEN From owner-lynx-dev@sig.net Fri Nov 6 01:11:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA04991 for ; Fri, 6 Nov 1998 01:10:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA13560; Thu, 5 Nov 1998 23:56:37 -0600 (CST) From: Philip Webb Message-Id: <199811060557.AAA14824@chass.utoronto.ca> Subject: Re: lynx-dev lynx bookmarks bug? To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 00:57:14 -0500 (EST) In-Reply-To: from "Ismael Cordeiro" at Nov 5, 98 11:35:02 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: 1042 Lines: 22 981106 Ismael Cordeiro wrote: > On Thu, 5 Nov 1998, Philip Webb wrote: >> someone asked: >>> On my lynx bookmarks page (version 2.8rel2, SCRI-net version 2.2 beta), >>> r, y was not removing the highlighted link, but the link immediately >>> preceding it. >> this is a well-known bug with the bookmark page, > Well known?! Can you give some references of reports of that "bug"? i don't like saying simply: "Go & look in the Archive", but it's there more than once, tho' not recently; certainly, i raised it early in 1997 (i believe). the fact is that `r' doesn't reliably do what it is supposed to: there may be a case for tidying up how bookmarks work, as yet another piece of antediluviana from a more primitive era in Lynx development, but someone else can tackle 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 Fri Nov 6 01:22:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA07340 for ; Fri, 6 Nov 1998 01:22:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA14347; Fri, 6 Nov 1998 00:02:47 -0600 (CST) From: Philip Webb Message-Id: <199811060603.BAA15013@chass.utoronto.ca> Subject: Re: lynx-dev -cookie_file problem To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 01:03:24 -0500 (EST) In-Reply-To: <199811060352.VAA19502@thune.mrc.org> from "Mike Castle" at Nov 5, 98 09:52:10 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: 746 Lines: 15 981105 Mike Castle wrote: > If an option is overridden by the command line, > then user goes into the options menu and saves it, > will the value from the command line switch be the new default? there are 3 levels involved, not 2 : .lynxrc -switch change-in-option-in-form ; if the latter is saved a/a merely changed for current use, it gets written into .lynxrc for use next time Lynx is executed, depending on whether -switch is added to the command at that time. -- ========================,,============================================ 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 Nov 6 06:29:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA13299 for ; Fri, 6 Nov 1998 06:29:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA13432; Fri, 6 Nov 1998 05:15:50 -0600 (CST) Message-ID: <19981106061700.C1639@mail.bcpl.net> Date: Fri, 6 Nov 1998 06:17:00 -0500 From: Webmaster Jim To: "Michael T. Smith" , lynx-dev@sig.net Subject: lynx-dev Re: International version up to 2.8.1rel.2 References: <19981102015549.A23869@bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Michael T. Smith on Thu, Nov 05, 1998 at 05:15:20PM -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.93.2i (1998-07-29) 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: 1167 Lines: 24 On Thu, Nov 05, 1998 at 05:15:20PM -0400, Michael T. Smith wrote: > On Mon, 2 Nov 1998, Webmaster Jim wrote: > > *) I'm using gettext() rather than _() since the latter gives a warning > > under BSD. I don't consider this a bug, per se. > I'm curious as to what the warning is... _() is a lot quicker to type than > gettext() and takes up less space so we'd be more likely to get people to > use it. Maybe _G() would work too (_T() is used by Win32 for > unicodization). I considered using _(), but it seems to interfere with macros used for allowing non-K&R function prototypes in the BSD world. If someone wants to code for Lynx, they should be able to type gettext() around strings. It does add a few bytes to the source with the side-benefit of increasing clarity of intent. Of course, if output calls are added to the code base without gettext by the author, I or others can simply add it later. P.S. I'm unsubscribing to lynx-dev for a while. Will be reading the archives when possible. ------ Marvin the Paranoid Android says: A brain the size of a planet, and what do I get? From owner-lynx-dev@sig.net Fri Nov 6 07:02:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA17766 for ; Fri, 6 Nov 1998 07:02:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA15893; Fri, 6 Nov 1998 05:44:26 -0600 (CST) From: dickey@clark.net Message-Id: <199811061146.GAA11620@shell.clark.net> Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 06:46:18 -0500 (EST) In-Reply-To: <19981106061700.C1639@mail.bcpl.net> from "Webmaster Jim " at Nov 6, 98 06:17: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: 1064 Lines: 23 > On Thu, Nov 05, 1998 at 05:15:20PM -0400, Michael T. Smith wrote: > > On Mon, 2 Nov 1998, Webmaster Jim wrote: > > > *) I'm using gettext() rather than _() since the latter gives a warning > > > under BSD. I don't consider this a bug, per se. > > I'm curious as to what the warning is... _() is a lot quicker to type than > > gettext() and takes up less space so we'd be more likely to get people to > > use it. Maybe _G() would work too (_T() is used by Win32 for > > unicodization). > > I considered using _(), but it seems to interfere with macros used > for allowing non-K&R function prototypes in the BSD world. If someone > wants to code for Lynx, they should be able to type gettext() around > strings. It does add a few bytes to the source with the side-benefit of > increasing clarity of intent. it's a reserved symbol in some compilers (including g++). don't use symbols beginning with _, anyway (they're usually reserved for standard library implementations). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 6 08:32:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA25400 for ; Fri, 6 Nov 1998 08:32:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA26229; Fri, 6 Nov 1998 07:19:36 -0600 (CST) Date: Fri, 6 Nov 1998 05:21:26 -0800 (PST) From: David Combs Message-Id: <199811061321.FAA29816@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: [2.8.1rel.2] lineedit cleanup/enhancement - take 3 (was: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement)) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2101 Lines: 56 > From owner-lynx-dev@sig.net Tue Nov 3 17:10:09 1998 > Date: Tue, 3 Nov 1998 17:06:45 -0800 > From: Kim DeVaughn > > On Tue, Nov 03, 1998, Bela Lubkin (filbo@deepthought.armory.com) said: > | > | Kim DeVaughn wrote: > | > > | > The attached patch now removes the redundent LYE_DELC case code from > | > LYStrings.c, and add the new LYE_DELEOL case (which deletes characters > | > from the current cursor position, thru the end-of-line). > | > > | > Default binding for DELEOL is ^\ (formerly a NOP). > | > | On almost all Unix systems, ^\ is, by default, the `quit' character. It > | sends SIGQUIT, which causes most programs to dump core (that's its > | purpose). This can be blocked by ignoring SIGQUIT. > | > | I find no references to SIGQUIT in the Lynx source, including in your > | patch. Hitting ^\ in my (un-patched) Lynx causes it to dump core, as > | expected. > | > | This isn't a good default binding, as it will cause problems on a large > | percentage of the systems that use Lynx. Fixing it by blocking SIGQUIT > | wouldn't be good either -- it exists for good reason (e.g. to be able to > | generate a dump from a hung Lynx, for analysis). > | > | I don't object to the feature, just the default binding... > > Heh. Forgot about that usage of C-\. > > FWIW, stty -a shows it bound to "quit" on this FreeBSD 2.2.7-STABLE system, > but it seems to have no effect on lynx (nor any other app, for that matter). > Wonder where it's getting snarfed up ...?... > > > As may be, I rebound the default for LYE_DELEOL to ^_ (which I *hope* is a > safe choice). > > Also fixed a couple more doc references to emacs/vi keys to reflect that > they have no effect on the line-edit bindings. > > /kim OH NO! Not "control-backslash"! Please! On my suns (before, sun3/160, sunos; now sparc5, solaris) that char does NOTHING except echo. But not KERMIT. I dare not even try it. At least, "control-\ C" is kermit's "get to kermit command-level" signal-type-thing. Maybe control-\ itself is ok with kermit. Surely someone knows the answer. David From owner-lynx-dev@sig.net Fri Nov 6 08:40:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA25916 for ; Fri, 6 Nov 1998 08:40:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA27237; Fri, 6 Nov 1998 07:26:28 -0600 (CST) Date: Fri, 6 Nov 1998 05:28:24 -0800 (PST) From: David Combs Message-Id: <199811061328.FAA00357@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev compiler warning in HTFile.c:1065 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1651 Lines: 40 > From owner-lynx-dev@sig.net Tue Nov 3 18:59:01 1998 > From: dickey@clark.net > Subject: Re: lynx-dev compiler warning in HTFile.c:1065 > > > > > got the following compiler warning (2.8.1rel.1, SunOS4.1.3, slang1.2.2): > > > > WW/Library/Implementation -O2 -DSUN -DSUN4 -I../../../WWW/Library/Implementati > > on/ -DXMOSAIC_HACK -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTFile.c > > ../../../WWW/Library/Implementation/HTFile.c: In function `HTEditable': > > ../../../WWW/Library/Implementation/HTFile.c:1065: warning: passing arg 2 of `ge > > tgroups' from incompatible pointer type > > This is what's going on (I'm not at the moment certain whether you're > seeing a bug or a feature): getgroups takes an argument which is an > array of gid_t. For the normal SunOS 4.x, this is really an integer (int), > but the /5lib environment can really be a short integer. But that's > tested properly if you're using the compilers designed for that purpose. > > I think configuring with gcc confuses things a little because the > declaration of gid_t is really a short in both cases -- but when I studied > this a month or so ago, it seemed to be doing the right thing in the > configure script (including for slang). But I'll look at it again. > > > __Henry > > If gnu's configure, or gcc itself, or whatever it is you are talking about, has a problem, please tell them. I don't know where you post it; there is a gnu.misc.discuss newsgroup; maybe they'd see a post and tell you what to do with it, eg where to email it to. Yes, just grepped big .newsrc-list. There is a gnu.gcc.bug, and also a gnu.gdb.bug. david From owner-lynx-dev@sig.net Fri Nov 6 08:48:43 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA26849 for ; Fri, 6 Nov 1998 08:48:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA28869; Fri, 6 Nov 1998 07:36:31 -0600 (CST) Date: Fri, 6 Nov 1998 05:38:27 -0800 (PST) From: David Combs Message-Id: <199811061338.FAA01123@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 859 Lines: 22 > From owner-lynx-dev@sig.net Wed Nov 4 05:10:43 1998 > From: dickey@clark.net > Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 > > I think I'll probably have to sanitize this stuff - some of the people > working on GNU software have a bad attitude about portability, and > intentionally put in things that make their tools build only with > GNU software. > > (vendor-lockin is a Bad Thing, no matter what color your hat is). > You and others would do us ALL a BIG favor if you had or built a list of these sanitization-needing items. Even add it to the web site, near the sources. This computer stuff is just getting so much more difficult these days -- more and more and more stuff you have to know, just so intel and M$ can sell to more people -- it's just crazy for each person to discover this stuff for him/her-self. David From owner-lynx-dev@sig.net Fri Nov 6 09:19:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA31384 for ; Fri, 6 Nov 1998 09:19:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA02470; Fri, 6 Nov 1998 07:56:52 -0600 (CST) Date: Fri, 6 Nov 1998 05:58:48 -0800 (PST) From: David Combs Message-Id: <199811061358.FAA02673@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Misplaced?
      breaks anchor. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1680 Lines: 51 Try -tagsoup, huh? Well, since in this situation I might have a big history list built up, and not want to exit lynx to rerun with a different option, I'd just type "o", and turn it on from the options page!!!!!! :-( For the umpteenth time, I remind everyone that TRN (newer and newer versions all the time, really great newsreader) has one char (I forget, I never need to use it for trn) that lets you type in a line of options, at runtime, just as you would on the command line (complete with minus signs). And again, I say that any concern about the size of the options page having to be one-screen-only, is INSANE. I mean, some of us have 20-inch screens, some 14-inch, soon some a palm-pilot or the like, and maybe even a dick-tracy wristwatch-display! "What is 'one screen'?", a koan for the computer age. David PS: the way I do things is to start something running, and KEEP IT UP FOREVER, or for as long as my isp-session. I want to give COMMAND-LINE options ON the COMMAND-LINE only ONCE, when I first sign in for a two hour session on the isp. Anything else, I want to do it at RUN TIME. Just as with emacs! Browsing the net is a continuous thing, once on the isp. You have all this info built up, eg in the history stack, the "V" list, etc. You sure don't want to LOSE it. SUGGESTION: you be able to "suspend" all that stuff into a file, and then restart lynx via eg a "-restart [optional filename]", That would help, but it is still stupid that you have to eg TRY tagsoup for ONE bad site by taking down lynx and restarting. Just not user-efficiency-friendly. QUESTION: just what IS the problem with more stuff changeable at runtime? David again From owner-lynx-dev@sig.net Fri Nov 6 09:28:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA00252 for ; Fri, 6 Nov 1998 09:27:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA06048; Fri, 6 Nov 1998 08:13:01 -0600 (CST) From: dickey@clark.net Message-Id: <199811061414.JAA08875@shell.clark.net> Subject: Re: lynx-dev compiler warning in HTFile.c:1065 To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 09:14:35 -0500 (EST) In-Reply-To: <199811061328.FAA00357@netcom12.netcom.com> from "David Combs " at Nov 6, 98 05:28: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: 1075 Lines: 34 > > I think configuring with gcc confuses things a little because the > > declaration of gid_t is really a short in both cases -- but when I studied > > this a month or so ago, it seemed to be doing the right thing in the > > configure script (including for slang). But I'll look at it again. > > > > > __Henry > > > > > > If gnu's configure, or gcc itself, or whatever it is you are talking > about, has a problem, please tell them. oh I do... (not everyone listens). I think this one is a little too subtle for the people who are on the autoconf list. If I come up with a clean solution, I'll make sure they use it though. > I don't know where you post it; there is a gnu.misc.discuss newsgroup; > maybe they'd see a post and tell you what to do with it, eg where > to email it to. there's a mailing list too. > Yes, just grepped big .newsrc-list. There is a gnu.gcc.bug, and > also a gnu.gdb.bug. these are more suitable: gnu.utils.bug gnu.utils.help > > david -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 6 10:04:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA04031 for ; Fri, 6 Nov 1998 10:04:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA14788; Fri, 6 Nov 1998 08:44:51 -0600 (CST) Message-ID: <001701be0994$404758e0$293f8589@GV015029.nera.no> From: "Gisle Vanem" To: "Lynx-dev" Subject: lynx-dev prevent NNTP user/pass Date: Fri, 6 Nov 1998 15:46:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 147 Lines: 4 How do I configure Lynx not to prompt me for user-name and password before fetching news? My NNTP-server doesn't need authorisation. Gisle Vanem From owner-lynx-dev@sig.net Fri Nov 6 10:09:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA04756 for ; Fri, 6 Nov 1998 10:09:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA17869; Fri, 6 Nov 1998 08:56:04 -0600 (CST) Message-ID: <19981106065749.51281@shell3.ba.best.com> Date: Fri, 6 Nov 1998 06:57:49 -0800 From: Kim DeVaughn To: Lynx Developers Subject: Re: [2.8.1rel.2] lineedit cleanup/enhancement - take 3 (was: Re: lynx-dev [lynx2.8.1rel.2] lineedit bug fix (and enhancement)) Mail-Followup-To: Lynx Developers References: <199811061321.FAA29816@netcom12.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <199811061321.FAA29816@netcom12.netcom.com>; from David Combs on Fri, Nov 06, 1998 at 05:21:26AM -0800 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: 633 Lines: 20 On Fri, Nov 06, 1998, David Combs (dkcombs@netcom.com) said: | | > From: Kim DeVaughn | > | > As may be, I rebound the default for LYE_DELEOL to ^_ (which I *hope* is | > a safe choice). | | OH NO! Not "control-backslash"! Please! Huh? Reread what I wrote above, David. I *changed* the default binding from ^\ to ^_ in the 3rd incarnation of the patch (which is the one you replied to). OK ...? /kim ========================================================================== "Remember that it is dangerous to be right, when the government is wrong." --Voltaire's Sim From owner-lynx-dev@sig.net Fri Nov 6 10:10:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA05186 for ; Fri, 6 Nov 1998 10:10:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA16561; Fri, 6 Nov 1998 08:51:22 -0600 (CST) Date: Fri, 6 Nov 1998 09:52:03 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811060952.AA29316@cas.org> Subject: Re: lynx-dev -cookie_file problem In-Reply-To: <199811060603.BAA15013@chass.utoronto.ca> of Fri, 6 Nov 1998 01:03:24 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1651 Lines: 39 > > If an option is overridden by the command line, > > then user goes into the options menu and saves it, > > will the value from the command line switch be the new default? > > there are 3 levels involved, not 2 : > .lynxrc -switch change-in-option-in-form ; > if the latter is saved a/a merely changed for current use, > it gets written into .lynxrc for use next time Lynx is executed, > depending on whether -switch is added to the command at that time. Let's see - are there not these possible places where values can be set: When building lynx: hard coded values in source distribution configure generated values from configuration time userdefs.h edited by install person before build time At run time: site wide lynx.cfg file personal .lynxrc command invocation time switches runtime option menu These are presented from lowest to highest priority - lynx merges these into a single set of current operational values. Now, when the user goes into the options menu and saves the values, whatever is represented there becomes the personal .lynxrc values which will be read in the next time lynx is invoked. However, lynx does not make another pass thru all the above to reinitialize. So the command line switch values which cause changes to the lynxrc/option menu options, if not modified by the user on the form before saving the values, get used during the next invocation. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 6 11:59:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA16835 for ; Fri, 6 Nov 1998 11:59:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA22219; Fri, 6 Nov 1998 10:45:17 -0600 (CST) To: lynx-dev@sig.net References: <199811061358.FAA02673@netcom12.netcom.com> Message-Id: From: "Leonid Pauzner" Date: Fri, 6 Nov 1998 19:44:07 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Misplaced?
      breaks anchor. 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: 261 Lines: 10 > Try -tagsoup, huh? > Well, since in this situation I might have a big history > list built up, and not want to exit lynx to rerun > with a different option, I'd just type "o", and turn > it on from the options page!!!!!! Try Ctrl-V at run time. > :-( From owner-lynx-dev@sig.net Fri Nov 6 13:22:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA26155 for ; Fri, 6 Nov 1998 13:22:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA13807; Fri, 6 Nov 1998 11:55:01 -0600 (CST) From: dickey@clark.net Message-Id: <199811061627.LAA03474@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.1 To: lynx-dev@sig.net (Lynx Development) Date: Fri, 6 Nov 1998 11:27:33 -0500 (EST) 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: 1375 Lines: 26 I also put a patch for this in the patches directory under the 2.8.1 release. 1998-11-05 (2.8.2dev.1) * relax the cookie sanity checking for version 0 (old) cookies _only when_ the user has accept_all_cookies set (patch by Risto Widenius ) * modify get_listen_socket() to check if master_socket is set before attempting to use it in FD_CLR (patch by Karl-Andre Skevik ) * minor documentation fixes - DK * use $(LIBS) symbol in src/chrtrans/makefile.in (reported by Alois Maier ) * Fix core dump which may happen after printing-to-email. - LP * Move read_rc() before parsing any command-line arguments (except -help) so the latter will override any .lynxrc settings. In particular, the problem was detected with -cookie_file= which was ignored after saving values from Options menu. - LP * Chartrans bug: LYNXIMGMAP now shows the text in right charset. (The page was converted twice, fixed by adding META charset to this internal page. The bug was in all versions of Lynx starting from 2.7.1ac) - LP * Oops, my typo from pre3 back to 27-09-98: windows-1252 appears twice in the list of character sets in options menu, was also typo in docs. - LP * modify HTDOS.c to permit compile with K&R compiler - TD -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 6 13:57:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA31195 for ; Fri, 6 Nov 1998 13:57:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA26330; Fri, 6 Nov 1998 12:39:13 -0600 (CST) Date: Fri, 6 Nov 1998 10:41:04 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: lynx-dev idea regarding 'Submit' links 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: 585 Lines: 16 An idea a friend told me about, and I must say that I like it. When we're on a 'Submit' link, Lynx doesn't give us any information about where we're submitting to unless we hit the '=' key to look at current document information. What would the rest of you think about having Lynx display the URL that a 'Submit' link points to, most likely only in advanced user mode? I wanted to see if anyone had any objections before I patched this in... -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Fri Nov 6 14:04:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA32243 for ; Fri, 6 Nov 1998 14:04:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA27315; Fri, 6 Nov 1998 12:43:24 -0600 (CST) From: Bela Lubkin Date: Fri, 6 Nov 1998 10:47:29 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev Misplaced?
      breaks anchor. Message-ID: <9811061047.aa14486@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 472 Lines: 12 David Combs wrote: > For the umpteenth time, I remind everyone that TRN (newer > and newer versions all the time, really great newsreader) > has one char (I forget, I never need to use it for trn) > that lets you type in a line of options, at runtime, > just as you would on the command line (complete with > minus signs). Assuming the options unification happens, as I recently blue-skied, this will be easy. It would be premature to add it before unification. >Bela< From owner-lynx-dev@sig.net Fri Nov 6 14:26:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA02346 for ; Fri, 6 Nov 1998 14:26:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA02839; Fri, 6 Nov 1998 13:03:35 -0600 (CST) Date: Fri, 6 Nov 1998 11:05:24 -0800 (PST) From: David Combs Message-Id: <199811061905.LAA22386@netcom10.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Misplaced?
      breaks anchor. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 681 Lines: 23 > From owner-lynx-dev@sig.net Fri Nov 6 08:50:03 1998 > To: lynx-dev@sig.net > References: <199811061358.FAA02673@netcom12.netcom.com> > > > Try -tagsoup, huh? > > > Well, since in this situation I might have a big history > > list built up, and not want to exit lynx to rerun > > with a different option, I'd just type "o", and turn > > it on from the options page!!!!!! > > Try Ctrl-V at run time. > > :-( OK, ok. You got me on that one. SUGGESTION: That the few "interactive" options, such as Ctrl-V, ALSO be listed on the options page, as comments, so to speak. Thus ALL the run-time options that are available, one way or another, can be seen via that page... From owner-lynx-dev@sig.net Fri Nov 6 15:37:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA12937 for ; Fri, 6 Nov 1998 15:37:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA22493; Fri, 6 Nov 1998 14:12:51 -0600 (CST) From: Philip Webb Message-Id: <199811062013.PAA28234@chass.utoronto.ca> Subject: Re: lynx-dev idea regarding 'Submit' links To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 15:13:26 -0500 (EST) In-Reply-To: from "brian j. pardy" at Nov 6, 98 10:41: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: 722 Lines: 14 981106 Brian Pardy wrote: > When we're on a 'Submit' link, Lynx doesn't give us any information > about where we're submitting to unless we hit the '=' key to look > at current document information. > What would the rest of you think about having Lynx display the URL > that a 'Submit' link points to, most likely only in advanced user mode? > I wanted to see if anyone had any objections before I patched this in... sounds like a good idea off-hand. -- ========================,,============================================ 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 Nov 6 15:51:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA16064 for ; Fri, 6 Nov 1998 15:51:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA27467; Fri, 6 Nov 1998 14:28:21 -0600 (CST) From: dickey@clark.net Message-Id: <199811061542.KAA03440@shell.clark.net> Subject: Re: lynx-dev Misplaced?
      breaks anchor. To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 10:42:14 -0500 (EST) In-Reply-To: <199811061358.FAA02673@netcom12.netcom.com> from "David Combs " at Nov 6, 98 05:58: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: 329 Lines: 14 > > Try -tagsoup, huh? > > Well, since in this situation I might have a big history > list built up, and not want to exit lynx to rerun > with a different option, I'd just type "o", and turn > it on from the options page!!!!!! or type a control/V -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 6 17:36:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA30746 for ; Fri, 6 Nov 1998 17:36:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA27655; Fri, 6 Nov 1998 16:11:42 -0600 (CST) Date: Fri, 6 Nov 1998 14:12:55 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net cc: Collin Forbes Subject: Re: lynx-dev idea regarding 'Submit' links 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: 665 Lines: 19 On Fri, 6 Nov 1998, Collin Forbes wrote: > On Fri, 6 Nov 1998, brian j. pardy wrote: > > > What would the rest of you think about having Lynx display the URL > > that a 'Submit' link points to, most likely only in advanced user > > mode? > > I'd like to see this, but I'd want additional indications that it is a submit > button and not a normal link. Oh, I didn't make that clear. I'd also want it the indication that it was a submit link -- maybe something like: (Submit) http://www.altavista.digital.com/cgi-bin/query -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Fri Nov 6 18:09:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA02013 for ; Fri, 6 Nov 1998 18:09:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA03608; Fri, 6 Nov 1998 16:32:33 -0600 (CST) From: Philip Webb Message-Id: <199811062233.RAA18689@chass.utoronto.ca> Subject: Re: lynx-dev Misplaced?
      breaks anchor. To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 17:33:05 -0500 (EST) In-Reply-To: <199811061542.KAA03440@shell.clark.net> from "dickey@clark.net" at Nov 6, 98 10:42: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: 737 Lines: 17 981106 Thomas Dickey wrote: >> Try -tagsoup, huh? >> in this situation I might have a big history list built up, >> and not want to exit lynx to rerun with a different option, >> I'd just type "o", and turn it on from the options page!!!!!! > or type a control/V does that toggle `tagsoup'? the line in the `k' keybinding list reads: ^V SWITCH_DTD switch between two ways of parsing HTML , which is scarcely informative: a doc tweak, maybe ... ? -- ========================,,============================================ 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 Nov 6 19:35:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA11084 for ; Fri, 6 Nov 1998 19:35:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA26136; Fri, 6 Nov 1998 18:16:46 -0600 (CST) Date: Sat, 7 Nov 1998 09:19:23 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811070019.JAA18219@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Misplaced?
      breaks anchor. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 420 Lines: 12 > > or type a control/V > > does that toggle `tagsoup'? the line in the `k' keybinding list reads: > > ^V SWITCH_DTD switch between two ways of parsing HTML , > > which is scarcely informative: a doc tweak, maybe ... ? Re: doc tweak, maybe for your beginners' primer. I don't think words like `tagsoup' and `sorta-sgml' are what should be in short descriptions in the `k' keybinding list. __Henry From owner-lynx-dev@sig.net Fri Nov 6 20:39:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA16791 for ; Fri, 6 Nov 1998 20:39:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA05237; Fri, 6 Nov 1998 19:12:39 -0600 (CST) From: Philip Webb Message-Id: <199811070113.UAA01437@chass.utoronto.ca> Subject: Re: lynx-dev Misplaced?
      breaks anchor. To: lynx-dev@sig.net Date: Fri, 6 Nov 1998 20:13:17 -0500 (EST) In-Reply-To: <199811070019.JAA18219@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric" at Nov 7, 98 09:19:23 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: 763 Lines: 16 981106 Nelson Henry Eric wrote: > 981106 Philip Webb wrote: >> does ^v toggle `tagsoup'? the line in the `k' keybinding list reads: >> >> ^V SWITCH_DTD switch between two ways of parsing HTML , >> >> which is scarcely informative: a doc tweak, maybe ... ? > maybe for your beginners' primer. I don't think `tagsoup' & `sorta-sgml' > are what should be in short descriptions in the `k' keybinding list. i was thinking of eg `toggle lenient tag-nesting': is that all it does? -- ========================,,============================================ 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 Nov 6 21:51:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA22624 for ; Fri, 6 Nov 1998 21:51:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA17757; Fri, 6 Nov 1998 20:36:19 -0600 (CST) Message-ID: <19981106183749.A4053@psnw.com> Date: Fri, 6 Nov 1998 18:37:49 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev idea regarding 'Submit' links Mail-Followup-To: lynx-dev@sig.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "brian j. pardy" on Fri, Nov 06, 1998 at 02:12:55PM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 6:33pm up 11:17, 4 users, load average: 1.00, 1.03, 1.04 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4607 Lines: 111 Here's a patch for what I was talking about. It'll make the statusline give the address to submit to when in advanced user mode. Also fixes one small typo in LYMainLoop.c. FWIW, credit for this idea goes to . (I haven't tested with mailto type forms, I can't find any to check out, but it works with others.) Adds a few extra entries to LYMessages_en.h that'll need to be propagated through to the others, I figure... diff -cr lynx2-8-1/LYMessages_en.h lynx2.8.2dev.1.bri/LYMessages_en.h *** lynx2-8-1/LYMessages_en.h Fri Nov 6 18:14:59 1998 --- lynx2.8.2dev.1.bri/LYMessages_en.h Fri Nov 6 18:24:41 1998 *************** *** 67,78 **** --- 67,84 ---- "(Radio Button) Use right-arrow or to toggle." #define FORM_LINK_RADIO_UNM_MSG \ "UNMODIFIABLE form radio button. Use UP or DOWN arrows or tab to move off." + #define FORM_LINK_SUBMIT_PREFIX \ + "Submit ('x' for no cache) to " + #define FORM_LINK_RESUBMIT_PREFIX \ + "Submit to " #define FORM_LINK_SUBMIT_MESSAGE \ "(Form submit button) Use right-arrow or to submit ('x' for no cache)." #define FORM_LINK_RESUBMIT_MESSAGE \ "(Form submit button) Use right-arrow or to submit." #define FORM_LINK_SUBMIT_DIS_MSG \ "DISABLED form submit button. Use UP or DOWN arrows or tab to move off." + #define FORM_LINK_SUBMIT_MAILTO_PREFIX \ + "Submit mailto form to " #define FORM_LINK_SUBMIT_MAILTO_MSG \ "(mailto form submit button) Use right-arrow or to submit." #define FORM_LINK_SUBMIT_MAILTO_DIS_MSG \ diff -cr lynx2-8-1/src/LYMainLoop.c lynx2.8.2dev.1.bri/src/LYMainLoop.c *** lynx2-8-1/src/LYMainLoop.c Fri Nov 6 18:14:59 1998 --- lynx2.8.2dev.1.bri/src/LYMainLoop.c Fri Nov 6 18:23:49 1998 *************** *** 1033,1039 **** /* * Set the remaining document elements and add to ! * the visitied links list. - FM */ if (ownerS_address != NULL) { if (HTOutputFormat == WWW_SOURCE && !HText_getOwner()) --- 1033,1039 ---- /* * Set the remaining document elements and add to ! * the visited links list. - FM */ if (ownerS_address != NULL) { if (HTOutputFormat == WWW_SOURCE && !HText_getOwner()) *************** *** 1398,1409 **** if (no_mail) { statusline(FORM_LINK_SUBMIT_MAILTO_DIS_MSG); } else { ! statusline(FORM_LINK_SUBMIT_MAILTO_MSG); } } else if (links[curdoc.link].form->no_cache) { ! statusline(FORM_LINK_RESUBMIT_MESSAGE); } else { ! statusline(FORM_LINK_SUBMIT_MESSAGE); } break; case F_RESET_TYPE: --- 1398,1436 ---- if (no_mail) { statusline(FORM_LINK_SUBMIT_MAILTO_DIS_MSG); } else { ! if(user_mode == ADVANCED_MODE) { ! char *submit_str = NULL; ! ! StrAllocCopy(submit_str, FORM_LINK_SUBMIT_MAILTO_PREFIX); ! StrAllocCat(submit_str, links[curdoc.link].form->submit_action); ! statusline(submit_str); ! FREE(submit_str); ! } else { ! statusline(FORM_LINK_SUBMIT_MAILTO_MSG); ! } } } else if (links[curdoc.link].form->no_cache) { ! if(user_mode == ADVANCED_MODE) { ! char *submit_str = NULL; ! ! StrAllocCopy(submit_str, FORM_LINK_RESUBMIT_PREFIX); ! StrAllocCat(submit_str, links[curdoc.link].form->submit_action); ! statusline(submit_str); ! FREE(submit_str); ! } else { ! statusline(FORM_LINK_RESUBMIT_MESSAGE); ! } } else { ! if(user_mode == ADVANCED_MODE) { ! char *submit_str = NULL; ! ! StrAllocCopy(submit_str, FORM_LINK_SUBMIT_PREFIX); ! StrAllocCat(submit_str, links[curdoc.link].form->submit_action); ! statusline(submit_str); ! FREE(submit_str); ! } else { ! statusline(FORM_LINK_SUBMIT_MESSAGE); ! } } break; case F_RESET_TYPE: -- Non-sequiturs make me eat lampshades. From owner-lynx-dev@sig.net Fri Nov 6 23:56:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA00451 for ; Fri, 6 Nov 1998 23:56:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA05550; Fri, 6 Nov 1998 22:44:11 -0600 (CST) Date: Fri, 6 Nov 1998 20:46:08 -0800 (PST) From: James Elkinton To: Lynx Development Mailing List Subject: lynx-dev 2.8.2dev1 untar directory 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: 84 Lines: 4 Subject pretty much says it.. odd that the directory name didn't get changed. :) From owner-lynx-dev@sig.net Sat Nov 7 00:43:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA03571 for ; Sat, 7 Nov 1998 00:43:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA10504; Fri, 6 Nov 1998 23:20:57 -0600 (CST) Date: Sat, 7 Nov 1998 09:13:37 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811070013.JAA18208@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7203 Lines: 200 > P.S. I'm unsubscribing to lynx-dev for a while. Will be reading Sad to hear that! Any ideas when you'll be able to come back? Anyway, I got Lynx-intl to compile on SunOS4.1.3 with the appended patch applied. (It just fixes typos.) Unfortunately, I could not get Lynx to display the translated messages. I suspect it is because Lynx is not finding the lynx.mo file, since the default English messages are displayed without problem. I had no problem getting either the tools (e.g., xgettext, msgfmt) in the gettext package itself or the hello package to use strings I translated myself, so I am confident that my environment is correctly set. I've tested by both removing the respective *.mo files and seeing a fall-back to the English defaults, and by adding new or different strings to the *.mo files and getting them to be displayed. I'll play with it for a few more hours, but I've run out of time myself. __Henry *** lynx2-8-1-rel2-intl/src/HTFWriter.c.orig Fri Nov 6 10:39:32 1998 --- lynx2-8-1-rel2-intl/src/HTFWriter.c Fri Nov 6 10:42:53 1998 *************** *** 491,497 **** return(NULL); } if (no_exec) { ! eTAlert(EXECUTION_DISABLED); return HTPlainPresent(pres, anchor, sink); } if (!local_exec) --- 491,497 ---- return(NULL); } if (no_exec) { ! HTAlert(gettext("Execution is disabled.")); return HTPlainPresent(pres, anchor, sink); } if (!local_exec) *** lynx2-8-1-rel2-intl/src/LYMainLoop.c.orig Fri Nov 6 10:44:30 1998 --- lynx2-8-1-rel2-intl/src/LYMainLoop.c Fri Nov 6 10:48:13 1998 *************** *** 1776,1782 **** LYinternal_flag = TRUE; newdoc.internal_link = TRUE; if (0==strcmp((curdoc.title ? curdoc.title : ""), ! LIST_PAGE_TITLE) && 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { if (!curdoc.post_data || /* --- 1776,1782 ---- LYinternal_flag = TRUE; newdoc.internal_link = TRUE; if (0==strcmp((curdoc.title ? curdoc.title : ""), ! gettext("List Page")) && 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { if (!curdoc.post_data || /* *************** *** 2982,2988 **** */ if (0==strcmp(curdoc.address, LYlist_temp_url()) && 0==strcmp((curdoc.title ? curdoc.title : ""), ! LIST_PAGE_TITLE)) { if (!curdoc.post_data || /* * Normal case - List Page is not associated --- 2982,2988 ---- */ if (0==strcmp(curdoc.address, LYlist_temp_url()) && 0==strcmp((curdoc.title ? curdoc.title : ""), ! gettext("List Page"))) { if (!curdoc.post_data || /* * Normal case - List Page is not associated *** lynx2-8-1-rel2-intl/src/LYOptions.c.orig Fri Nov 6 13:42:56 1998 --- lynx2-8-1-rel2-intl/src/LYOptions.c Fri Nov 6 13:58:53 1998 *************** *** 2513,2523 **** window_offset = 0; cur_choice = 0; if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. ! Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; } --- 2513,2521 ---- window_offset = 0; cur_choice = 0; if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; } *************** *** 2530,2540 **** if (window_offset >= ((num_choices - length) + 1)) { HTUserMsg(gettext("You are already at the end of this choice list.")); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. ! Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; } --- 2528,2536 ---- if (window_offset >= ((num_choices - length) + 1)) { HTUserMsg(gettext("You are already at the end of this choice list.")); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; } *************** *** 2547,2554 **** if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; } --- 2543,2549 ---- if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; } *************** *** 2560,2580 **** sprintf(buffer, gettext("You are already at page %d of this choice list."), number); HTUserMsg(buffer); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use ! return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; } cur_choice = window_offset = ((number - 1) * length); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use ! return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; --- 2555,2571 ---- sprintf(buffer, gettext("You are already at page %d of this choice list."), number); HTUserMsg(buffer); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; } cur_choice = window_offset = ((number - 1) * length); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; *************** *** 2660,2667 **** if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; --- 2651,2657 ---- if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; From owner-lynx-dev@sig.net Sat Nov 7 01:15:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA05442 for ; Sat, 7 Nov 1998 01:15:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA13771; Fri, 6 Nov 1998 23:48:48 -0600 (CST) Date: Sat, 7 Nov 1998 14:50:36 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811070550.OAA07126@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev internationalization Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 10922 Lines: 305 Okay it works! :) :) Time to roll (up your sleeves, that is)! Absolutely out of time, so very briefly: 1) Download, build and install the "gettext" package 2) Apply the appended patch to Jim's -intl version. Further edit out all references to builds in /intl and /po in the makefile.in's. (You've already done it in 1) or will do it in 2) -- it'll save you hours of time NOT using the --with-included-gettext option.) 3) Make a list of all *.[ch] files in the source and run xgettext to make an up-to-date lynx.pot file. Do your translations, run msgfmt to make the lynx.mo file, and put that in your standard LC_MESSAGES directory. 4) Run autoconf with --datadir= (full path up to "locale", defaults to /usr/local/share) and use the LIBS environment variable to set -lintl. And you'll have a Lynx that speaks your language. Speak Lark? No, Lynx! __Henry *** lynx2-8-1-rel2-intl/makefile.in.orig Sat Nov 7 11:37:49 1998 --- lynx2-8-1-rel2-intl/makefile.in Sat Nov 7 12:33:09 1998 *************** *** 49,57 **** helpdir= @libdir@/lynx_help ## Where your locale data is ! # datadir = @datadir@ ! datadir = /usr/local/share ! localedir = $(datadir)/locale ##set the relative location of the WWW library Implementation directory, ##from this directory --- 49,56 ---- helpdir= @libdir@/lynx_help ## Where your locale data is ! datadir = @datadir@ ! localedir = @datadir@/locale ##set the relative location of the WWW library Implementation directory, ##from this directory *************** *** 169,176 **** LY_CFLAGS="$(CFLAGS)" \ CPPFLAGS="$(CPPFLAGS)" \ LYFLAGS="$(SITE_LYDEFS)" - cd intl && $(MAKE) CC="$(CC)" - cd po && $(MAKE) CC="$(CC)" cd src && $(MAKE) all CC="$(CC)" \ CFLAGS="$(CFLAGS)" \ CPPFLAGS="$(CPPFLAGS)" \ --- 168,173 ---- *** lynx2-8-1-rel2-intl/src/makefile.in.orig Sat Nov 7 11:36:39 1998 --- lynx2-8-1-rel2-intl/src/makefile.in Sat Nov 7 12:54:08 1998 *************** *** 9,17 **** exec_prefix = @exec_prefix@ top_srcdir = @top_srcdir@ srcdir = @srcdir@ ! # localedir = @localedir@ ! # this isn't passing from above: ! localedir = /usr/local/share/locale VPATH = $(srcdir) # Symbols which the configure script can set in each makefile: --- 9,15 ---- exec_prefix = @exec_prefix@ top_srcdir = @top_srcdir@ srcdir = @srcdir@ ! localedir = @datadir@/locale VPATH = $(srcdir) # Symbols which the configure script can set in each makefile: *** lynx2-8-1-rel2-intl/src/HTFWriter.c.orig Fri Nov 6 10:39:32 1998 --- lynx2-8-1-rel2-intl/src/HTFWriter.c Fri Nov 6 10:42:53 1998 *************** *** 491,497 **** return(NULL); } if (no_exec) { ! eTAlert(EXECUTION_DISABLED); return HTPlainPresent(pres, anchor, sink); } if (!local_exec) --- 491,497 ---- return(NULL); } if (no_exec) { ! HTAlert(gettext("Execution is disabled.")); return HTPlainPresent(pres, anchor, sink); } if (!local_exec) *** lynx2-8-1-rel2-intl/src/LYOptions.c.orig Fri Nov 6 13:42:56 1998 --- lynx2-8-1-rel2-intl/src/LYOptions.c Fri Nov 6 13:58:53 1998 *************** *** 2513,2523 **** window_offset = 0; cur_choice = 0; if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. ! Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; } --- 2513,2521 ---- window_offset = 0; cur_choice = 0; if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; } *************** *** 2530,2540 **** if (window_offset >= ((num_choices - length) + 1)) { HTUserMsg(gettext("You are already at the end of this choice list.")); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. ! Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; } --- 2528,2536 ---- if (window_offset >= ((num_choices - length) + 1)) { HTUserMsg(gettext("You are already at the end of this choice list.")); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; } *************** *** 2547,2554 **** if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; } --- 2543,2549 ---- if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; } *************** *** 2560,2580 **** sprintf(buffer, gettext("You are already at page %d of this choice list."), number); HTUserMsg(buffer); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use ! return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; } cur_choice = window_offset = ((number - 1) * length); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use ! return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } goto redraw; --- 2555,2571 ---- sprintf(buffer, gettext("You are already at page %d of this choice list."), number); HTUserMsg(buffer); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; } cur_choice = window_offset = ((number - 1) * length); if (disabled) { ! _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } goto redraw; *************** *** 2660,2667 **** if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return an ! d use arrow keys and return to select option.")); } break; --- 2651,2657 ---- if (disabled) { _statusline(gettext("UNMODIFIABLE choice list. Use return or arrow keys to review or leave.")); } else { ! _statusline(gettext("(Choice list) Hit return and use arrow keys and return to select option.")); } break; *** lynx2-8-1-rel2-intl/src/LYMainLoop.c.orig Mon Nov 2 14:13:41 1998 --- lynx2-8-1-rel2-intl/src/LYMainLoop.c Sat Nov 7 13:58:48 1998 *************** *** 1776,1782 **** LYinternal_flag = TRUE; newdoc.internal_link = TRUE; if (0==strcmp((curdoc.title ? curdoc.title : ""), ! LIST_PAGE_TITLE) && 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { if (!curdoc.post_data || /* --- 1776,1782 ---- LYinternal_flag = TRUE; newdoc.internal_link = TRUE; if (0==strcmp((curdoc.title ? curdoc.title : ""), ! gettext("List Page")) && 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { if (!curdoc.post_data || /* *************** *** 2982,2988 **** */ if (0==strcmp(curdoc.address, LYlist_temp_url()) && 0==strcmp((curdoc.title ? curdoc.title : ""), ! LIST_PAGE_TITLE)) { if (!curdoc.post_data || /* * Normal case - List Page is not associated --- 2982,2988 ---- */ if (0==strcmp(curdoc.address, LYlist_temp_url()) && 0==strcmp((curdoc.title ? curdoc.title : ""), ! gettext("List Page"))) { if (!curdoc.post_data || /* * Normal case - List Page is not associated *************** *** 4614,4637 **** if (strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx History Page")) && ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("Information about the current document")) && ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("Lynx Printing Options")) && #ifdef DIRED_SUPPORT strcmp(curdoc.address, LYDiredFileURL) && ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("File Management Options")) && strcmp(curdoc.address, LYPermitFileURL) && ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("File Permission Options")) && strcmp(curdoc.address, LYUploadFileURL) && strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx Upload Options")) && #endif /* DIRED_SUPPORT */ ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("Lynx Download Options")) && ! strcmp((curdoc.title ? curdoc.title : gettext("")), gettext("Lynx Cookie Jar")) && ((nlinks <= 0) || (links[curdoc.link].lname != NULL && --- 4614,4637 ---- if (strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx History Page")) && ! strcmp((curdoc.title ? curdoc.title : ""), gettext("Information about the current document")) && ! strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx Printing Options")) && #ifdef DIRED_SUPPORT strcmp(curdoc.address, LYDiredFileURL) && ! strcmp((curdoc.title ? curdoc.title : ""), gettext("File Management Options")) && strcmp(curdoc.address, LYPermitFileURL) && ! strcmp((curdoc.title ? curdoc.title : ""), gettext("File Permission Options")) && strcmp(curdoc.address, LYUploadFileURL) && strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx Upload Options")) && #endif /* DIRED_SUPPORT */ ! strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx Download Options")) && ! strcmp((curdoc.title ? curdoc.title : ""), gettext("Lynx Cookie Jar")) && ((nlinks <= 0) || (links[curdoc.link].lname != NULL && From owner-lynx-dev@sig.net Sat Nov 7 01:22:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA05981 for ; Sat, 7 Nov 1998 01:22:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA14974; Fri, 6 Nov 1998 23:59:50 -0600 (CST) Date: Sat, 7 Nov 1998 15:02:39 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811070602.PAA07178@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 505 Lines: 9 > Adds a few extra entries to LYMessages_en.h that'll need to be propagated LYMessages_en.h is a dinosaur now that NLS is in the making. Before Jim's work gets too far out of sync, it would be nice to have it in place. BUT, what'll happen to DOS/Win32? Is there anyone who thinks the include mechanism is the better way to go? Since Tom has started 2.8.2dev, this is the time to make the plunge! Those who have a stake in native language support, this is the time to speak up -- and loudly! __Henry From owner-lynx-dev@sig.net Sat Nov 7 01:43:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA07293 for ; Sat, 7 Nov 1998 01:43:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA17777; Sat, 7 Nov 1998 00:26:34 -0600 (CST) Message-ID: <19981106222807.B9469@psnw.com> Date: Fri, 6 Nov 1998 22:28:07 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] Mail-Followup-To: lynx-dev@sig.net References: <199811070602.PAA07178@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811070602.PAA07178@ews07.nara.kindai.ac.jp>; from "Nelson Henry Eric" on Sat, Nov 07, 1998 at 03:02:39PM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 10:18pm up 15:01, 5 users, load average: 1.00, 1.10, 1.07 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1000 Lines: 21 Nelson Henry Eric wrote: > > Adds a few extra entries to LYMessages_en.h that'll need to be propagated > > LYMessages_en.h is a dinosaur now that NLS is in the making. Before > Jim's work gets too far out of sync, it would be nice to have it in > place. BUT, what'll happen to DOS/Win32? Is there anyone who thinks > the include mechanism is the better way to go? Since Tom has started > 2.8.2dev, this is the time to make the plunge! Those who have a stake > in native language support, this is the time to speak up -- and loudly! I had no real idea where else to put these. I did toss them into LYMessages_en.h because that seemed to be where everything else is. As soon as someone tells me what I can do with my user-visible patches to help internationalization, I'll start doing it. (And on a side-note, perhaps full internationalization might be considered to be a large enough change to merit bumping up to (at least) 2.9...) -- Government's Law: There is an exception to all laws. From owner-lynx-dev@sig.net Sat Nov 7 02:01:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA08535 for ; Sat, 7 Nov 1998 02:01:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA19527; Sat, 7 Nov 1998 00:46:22 -0600 (CST) Date: Sat, 7 Nov 1998 15:48:34 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811070648.PAA07321@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 874 Lines: 15 > As soon as someone tells me what I can do with my user-visible patches to > help internationalization, I'll start doing it. > > (And on a side-note, perhaps full internationalization might be considered > to be a large enough change to merit bumping up to (at least) 2.9...) At least 2.8.3 :). Anyway, until Jim's patches get applied, there's not much that can be done but use the include mechanism, so my comment wasn't aimed at anyone in particular; just anxious to get things moving. Once the strings are wrapped in gettext() calls, the function has to be defined somewhere. Maybe there can be a LYgettext that uses the real gettext if nls support is opted for, and does nothing except echo the English hard- code if not. I'll send Tom some aspirin if he needs it, but that's about all I can do other than bark (and tell you all that this nls is _NEAT_). __Henry From owner-lynx-dev@sig.net Sat Nov 7 04:05:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA15263 for ; Sat, 7 Nov 1998 04:05:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA00239; Sat, 7 Nov 1998 02:51:09 -0600 (CST) Date: Sat, 7 Nov 1998 03:52:34 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811070352.AA11789@cas.org> Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] In-Reply-To: <199811070648.PAA07321@ews07.nara.kindai.ac.jp> of Sat, 7 Nov 1998 15:48:34 +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: 389 Lines: 6 Those who are using internationalized lynx - are there any _input_ concerns regarding lynx that have not been addressed yet? Just curious. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 04:23:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA16352 for ; Sat, 7 Nov 1998 04:23:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA01718; Sat, 7 Nov 1998 03:09:19 -0600 (CST) To: lynx-dev@sig.net References: <199811070550.OAA07126@ews07.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Sat, 7 Nov 1998 12:06:13 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev internationalization 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: 4793 Lines: 101 > Okay it works! :) :) Time to roll (up your sleeves, that is)! > Absolutely out of time, so very briefly: > __Henry Does this looks useful to change XXX_TITLE to open text string? This title string found in more than one place (~5) so you may easily get a typo... > *** lynx2-8-1-rel2-intl/src/LYMainLoop.c.orig Mon Nov 2 14:13:41 1998 > --- lynx2-8-1-rel2-intl/src/LYMainLoop.c Sat Nov 7 13:58:48 1998 > *************** > *** 1776,1782 **** > LYinternal_flag = TRUE; > newdoc.internal_link = TRUE; > if (0==strcmp((curdoc.title ? curdoc.title : ""), > ! LIST_PAGE_TITLE) && > 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { > if (!curdoc.post_data || > /* > --- 1776,1782 ---- > LYinternal_flag = TRUE; > newdoc.internal_link = TRUE; > if (0==strcmp((curdoc.title ? curdoc.title : ""), > ! gettext("List Page")) && > 0==strcmp(HTLoadedDocumentURL(), LYlist_temp_url())) { > if (!curdoc.post_data || > /* > *************** > *** 2982,2988 **** > */ > if (0==strcmp(curdoc.address, LYlist_temp_url()) && > 0==strcmp((curdoc.title ? curdoc.title : ""), > ! LIST_PAGE_TITLE)) { > if (!curdoc.post_data || > /* > * Normal case - List Page is not associated > --- 2982,2988 ---- > */ > if (0==strcmp(curdoc.address, LYlist_temp_url()) && > 0==strcmp((curdoc.title ? curdoc.title : ""), > ! gettext("List Page"))) { > if (!curdoc.post_data || > /* > * Normal case - List Page is not associated > *************** > *** 4614,4637 **** > if (strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx History Page")) && > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("Information about the current document")) && > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("Lynx Printing Options")) && > #ifdef DIRED_SUPPORT > strcmp(curdoc.address, LYDiredFileURL) && > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("File Management Options")) && > strcmp(curdoc.address, LYPermitFileURL) && > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("File Permission Options")) && > strcmp(curdoc.address, LYUploadFileURL) && > strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx Upload Options")) && > #endif /* DIRED_SUPPORT */ > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("Lynx Download Options")) && > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > gettext("Lynx Cookie Jar")) && > ((nlinks <= 0) || > (links[curdoc.link].lname != NULL && > --- 4614,4637 ---- > if (strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx History Page")) && > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("Information about the current document")) && > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx Printing Options")) && > #ifdef DIRED_SUPPORT > strcmp(curdoc.address, LYDiredFileURL) && > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("File Management Options")) && > strcmp(curdoc.address, LYPermitFileURL) && > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("File Permission Options")) && > strcmp(curdoc.address, LYUploadFileURL) && > strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx Upload Options")) && > #endif /* DIRED_SUPPORT */ > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx Download Options")) && > ! strcmp((curdoc.title ? curdoc.title : ""), > gettext("Lynx Cookie Jar")) && > ((nlinks <= 0) || > (links[curdoc.link].lname != NULL && From owner-lynx-dev@sig.net Sat Nov 7 07:59:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA29412 for ; Sat, 7 Nov 1998 07:59:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA16135; Sat, 7 Nov 1998 06:34:17 -0600 (CST) To: lynx-dev@sig.net References: <199811022303.CAA08337@main.mccme.rssi.ru> Message-Id: From: "Leonid Pauzner" Date: Sat, 7 Nov 1998 15:29:41 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev documentation update (was: View French accents) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4669 Lines: 116 > 981102 FranÚois Demers wrote: >> I am unable to see French accents in Win32 Lynx. >> The accents are replaced by wrong chars. diff -u old/lynx_use.htm ./lynx_use.htm --- old/lynx_use.htm Tue Oct 27 18:08:12 1998 +++ ./lynx_use.htm Sat Nov 7 15:05:54 1998 @@ -57,6 +57,7 @@ | Lynx and HTML Notes
    • Lynx and HTML Lists
    • Lynx and HTML Quotes +
    • Lynx and HTML Internationalization: 8bit, unicode, etc.
    • Lynx and Client-Side-Image-Maps
    • Lynx and Client-Side-Pull
    • Lynx and State Management (Me want cookie!) @@ -483,7 +484,8 @@ Options Menu (Lynx Version 2.8.1pre.2) - Accept Changes - Reset Changes Left Arrow cancels changes HELP! + Accept Changes - Reset Changes Left Arrow cancels changes HELP! Save options to disk: [_] @@ -1764,6 +1766,15 @@

      Any ID attributes in BLOCKQUOTE, BQ or Q elements can be the target of a hyperlink in the form URL#id. It is treated just like the NAME in Anchors. [ToC] + +

      Lynx and HTML Internationalization: 8bit, unicode, etc.

      + +Lynx have superior support for HTML 4.0/I18N internationalization issues. +However, to see the characters other than 7bit properly you should +set your display character set +from Option Menu and save its value, this is a Frequently Asked Question. +Fine-turning also available from lynx.cfg +[ToC]

      Lynx and Client-Side-Image-Maps

      Only in .: old diff -u old/option_h.htm ./option_h.htm --- old/option_h.htm Sat Oct 24 09:49:08 1998 +++ ./option_h.htm Sat Nov 7 15:11:14 1998 @@ -225,8 +225,9 @@ of viewed documents and from HTML entities into viewable characters. It should be set according to your terminal's character set so that characters other than 7-bit ASCII can be displayed correctly, -using approximations if necessary. You must have the selected character set -installed on your terminal. Since Lynx now supports a wide range of platforms +using approximations if necessary, +try the test here. +Since Lynx now supports a wide range of platforms it may be useful to note that cpXXX codepages are used within IBM PC computers, and windows-xxxx within native MS-Windows applications. diff -u old/test_dis.htm ./test_dis.htm --- old/test_dis.htm Sat Nov 7 15:20:14 1998 +++ ./test_dis.htm Sat Nov 7 15:18:48 1998 @@ -0,0 +1,53 @@ + + + Quick test for identifying display character set + + +

      Try this page with Lynx 2.7.2 or above:

      + +If you see several letters instead of a single - your promised display charset +does not support this character so "7 bit appoximation" is in effect. +If you see any single letter which definitely far from being supposed +you have a wrong lynx settings. +Press 'o' for Options menu and change "Display character set". +Try again if neccessary.
      +When you are satisfied save your changes in Options menu, thanks. +
      +
      +
      +0x00A9    ©           # COPYRIGHT SIGN
      +
      +0x00C7    Ç           # LATIN CAPITAL LETTER C WITH CEDILLA
      +
      +0x00DC    Ü           # LATIN CAPITAL LETTER U WITH DIAERESIS
      +
      +0x00D1    Ñ           # LATIN CAPITAL LETTER N WITH TILDE
      +
      +0x0107    ć           # LATIN SMALL LETTER C WITH ACUTE
      +0x0108    Ĉ           # LATIN CAPITAL LETTER C WITH CIRCUMFLEX
      +0x010C    Č           # LATIN CAPITAL LETTER C WITH CARON
      +
      +
      +0x03BB    λ           # GREEK SMALL LETTER LAMDA
      +
      +0x041B    Л           # CYRILLIC CAPITAL LETTER EL
      +0x042E    Ю           # CYRILLIC CAPITAL LETTER YU
      +0x043B    л           # CYRILLIC SMALL LETTER EL
      +0x044E    ю           # CYRILLIC SMALL LETTER YU
      +
      +0x2026    …           # HORIZONTAL ELLIPSIS
      +0x2122    ™           # TRADE MARK SIGN
      +
      +0x255D    ╝           # BOX DRAWINGS DOUBLE UP AND LEFT
      +0x255E    ╞           # BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE
      +
      +0xFB01    fi           # LATIN SMALL LIGATURE FI
      +
      +
      +
      +
      +This only a quick test to see obvious problems. + + + + From owner-lynx-dev@sig.net Sat Nov 7 09:05:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA00695 for ; Sat, 7 Nov 1998 09:05:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA23114; Sat, 7 Nov 1998 07:52:08 -0600 (CST) From: dickey@clark.net Message-Id: <199811071354.IAA25400@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 08:54:05 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 7, 98 12:06:13 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: 539 Lines: 14 > Does this looks useful to change XXX_TITLE to open text string? > This title string found in more than one place (~5) > so you may easily get a typo... no. I intend keeping the #defines unless someone makes a good argument for removing them. (Besides typos, it makes it simpler to find other instances of the same message). I'm about halfway through checking over the diffs (have found several places where changes were lost, so I'm doing it the hard way ;-). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 09:09:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA00752 for ; Sat, 7 Nov 1998 09:09:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA23614; Sat, 7 Nov 1998 07:57:04 -0600 (CST) From: dickey@clark.net Message-Id: <199811071359.IAA25913@shell.clark.net> Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 08:59:01 -0500 (EST) In-Reply-To: <199811070648.PAA07321@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 7, 98 03:48: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: 1389 Lines: 35 > > > As soon as someone tells me what I can do with my user-visible patches to > > help internationalization, I'll start doing it. > > > > (And on a side-note, perhaps full internationalization might be considered > > to be a large enough change to merit bumping up to (at least) 2.9...) > > At least 2.8.3 :). Anyway, until Jim's patches get applied, there's not I thought we were headed for 2.8.2 (aside from the global nature of the change, it's not that intrusive). Adding message libraries and fixing buffer overflows will take more development time. > much that can be done but use the include mechanism, so my comment wasn't > aimed at anyone in particular; just anxious to get things moving. Once > the strings are wrapped in gettext() calls, the function has to be defined > somewhere. Maybe there can be a LYgettext that uses the real gettext if > nls support is opted for, and does nothing except echo the English hard- just a macro will do the trick. we don't need a function (which would also make the excutable larger). > code if not. I'll send Tom some aspirin if he needs it, but that's about > all I can do other than bark (and tell you all that this nls is _NEAT_). > > __Henry > anyway, I'm about halfway through the diffs. I expect to have a clean patch tomorrow. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 09:25:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA01968 for ; Sat, 7 Nov 1998 09:25:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA24990; Sat, 7 Nov 1998 08:11:29 -0600 (CST) From: dickey@clark.net Message-Id: <199811071413.JAA28179@shell.clark.net> Subject: Re: lynx-dev 2.8.2dev1 untar directory 2-8-1 To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 09:13:26 -0500 (EST) In-Reply-To: from "James Elkinton " at Nov 6, 98 08:46: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: 442 Lines: 12 > > Subject pretty much says it.. odd that the directory name didn't get > changed. :) it's been the practice to switch the name of the directory when we're "near" a release (but there's no hard rule yet about "near" ;-) the drawback to switching the name early, of course, is that we'll see a lot of bug reports against "2.8.2", which won't be released for months... -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 09:36:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA02528 for ; Sat, 7 Nov 1998 09:36:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA26053; Sat, 7 Nov 1998 08:22:41 -0600 (CST) Date: Sat, 7 Nov 1998 09:24:05 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811070924.AA21671@cas.org> Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] In-Reply-To: <199811071359.IAA25913@shell.clark.net> of Sat, 7 Nov 1998 08:59:01 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 645 Lines: 13 >> At least 2.8.3 :). Anyway, until Jim's patches get applied, there's not > >I thought we were headed for 2.8.2 (aside from the global nature of I agree - the internationalization of the msgs would not in my mind be enough to up the second version level. Has anyone out there patched lynx to support 64 bit int support? That's a rather popular, and painful, current activity around the net. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 11:30:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA09068 for ; Sat, 7 Nov 1998 11:29:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA07946; Sat, 7 Nov 1998 10:07:25 -0600 (CST) Date: Sat, 7 Nov 1998 11:08:47 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811071108.AA22493@cas.org> Subject: lynx-dev some proposed nit fixes in lynx.cfg To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 23131 Lines: 430 --- lynx.cfg-dist Fri Nov 6 09:29:41 1998 +++ lynx.cfg-new Sat Nov 7 11:07:49 1998 @@ -8,3 +8,3 @@ # -# If you do not have access to /usr/local/bin you may change +# If you do not have write access to /usr/local/bin you may change # the default location of this file in the userdefs.h file and recompile, @@ -38,3 +38,3 @@ # or via a WWW_HOME environment variable. -# note: these files can be remote (http://www.w3.org/default.html) +# Note: these files can be remote (http://www.w3.org/default.html) # or local (file://localhost/PATH_TO/FILENAME @@ -73,7 +73,8 @@ -# JUMP_PROMPT is the default statusline prompt for jumps files (see below). +# JUMP_PROMPT is the default statusline prompt for selecting a jumps file +# shortcut. (see below). # You can change the prompt here from that defined in userdefs.h. Any -# trailing white space will be trimmed, and a single space added by Lynx +# trailing white space will be trimmed, and a single space is added by Lynx # following the last non-white character. You must set the default prompt -# before setting the default jumps file (below). If a default jumps file +# before setting the default jumps file (below). If a default jumps file # was set via userdefs.h, and you change the prompt here, you must set the @@ -83,3 +84,3 @@ -# JUMPFILE is the default local file checked for shortcut URL's when +# JUMPFILE is the default local file checked for shortcut URLs when # the user presses the 'J' (JUMP) key. The user will be prompted for @@ -87,3 +88,3 @@ # or use '?' for a list of the shortcuts with associated links to -# their actual URL's. See the sample jumps files in the samples +# their actual URL's. See the jumps files in the lynx*/samples # subdirectory. Make sure your jumps file includes a '?' shortcut @@ -100,3 +101,3 @@ # -# Additional, alternate jumps files can be defined and mapped to +# Additional alternate jumps files can be defined and mapped to # keystrokes at the bottom of lynx.cfg, but you should first define @@ -162,3 +163,3 @@ -# CHARACTER_SET defines the display character set, i.e., that assumed to be +# CHARACTER_SET defines the display character set, i.e., assumed to be # installed on the user's terminal. It determines which characters or strings @@ -168,6 +169,6 @@ # character sets, it also determines how Kanji code will be handled. The -# default is defined in userdefs.h and can be changed here, and via the +# default is defined in userdefs.h and can be changed here or via the # 'o'ptions menu. The 'o'ptions menu setting will be stored in the user's RC # file whenever those settings are saved, and thereafter will be used as the -# default. For Lynx a "character set" has two names: MIME name (for +# default. For Lynx a "character set" has two names: a MIME name (for # recognizing properly labeled charset parameters in HTTP headers etc.), and a @@ -175,17 +176,19 @@ # language or group of languages besides MIME name). Not all 'human-readable' -# names correspond to exactly one valid MIME charset (example is "Chinese"), in -# that case an appropriate valid (and more specific) MIME name should be used -# where required. Well-known synonyms are also processed in the code. -# -# Lynx normally translates characters from document's charset to display -# charset, using ASSUME_CHARSET value (see below) if document's charset is not -# specified explicitly. There is the so called `raw or CJK mode' which is OFF -# for this case. (When the document charset specified explicitly -# it override any assumption like ASSUME_CHARSET or raw or CJK mode). +# names correspond to exactly one valid MIME charset (example is "Chinese"); +# in that case an appropriate valid (and more specific) MIME name should be +# used where required. Well-known synonyms are also processed in the code. +# +# Raw (CJK) mode +# +# Lynx normally translates characters from a document's charset to display +# charset, using ASSUME_CHARSET value (see below) if the document's charset +# is not specified explicitly. Raw CJK mode is OFF for this case. +# When the document charset is specified explicitly, that charset +# overrides any assumption like ASSUME_CHARSET or raw CJK mode. # -# For the Asian (CJK) display character sets the corresponding charset is -# assumed in documents, i.e., raw or CJK mode is ON by default. In raw CJK +# For the Asian (CJK) display character sets, the corresponding charset is +# assumed in documents, i.e., raw CJK mode is ON by default. In raw CJK # mode, 8-bit characters are not reverse translated in relation to the entity # conversion arrays, i.e., they are assumed to be appropriate for the display -# character set. It should be toggled OFF when an Asian (CJK) display +# character set. The mode should be toggled OFF when an Asian (CJK) display # character set is selected but the document is not CJK and its charset not @@ -193,6 +196,6 @@ # -# The `raw or CJK mode' may be toggled by user via '@' (LYK_RAW_TOGGLE) key, -# with -raw command line switch or from 'o'ptions menu. +# Raw CJK mode may be toggled by user via '@' (LYK_RAW_TOGGLE) key, +# the -raw command line switch or from the 'o'ptions menu. # -# Raw mode effectively changes the charset assumption about unlabeled +# Raw CJK mode effectively changes the charset assumption about unlabeled # documents. You can toggle raw mode ON if you believe the document has a @@ -209,5 +212,5 @@ # Since Lynx now supports a wide range of platforms it may be useful to note -# that cpXXX codepages used by IBM PC compatible computers, and windows-xxxx -# used by native MS-Windows apps. We also note that cpXXX pages rerely found -# on Internet but mostly for local needs on DOS. +# the cpXXX codepages used by IBM PC compatible computers, and windows-xxxx +# used by native MS-Windows apps. We also note that cpXXX pages rarely are +# found on Internet, but are mostly for local needs on DOS. # @@ -238,3 +241,3 @@ # Baltic Rim (windows-1257) windows-1257 -# Cyrillic (ISO-8859-5) iso-8859-5 +# Cyrillic (ISO-8859-5) iso-8859-5 # Cyrillic (cp866) cp866 @@ -268,3 +271,3 @@ # (the official default for the HTTP protocol). When ASSUME_CHARSET -# given here or by an -assume_charset command line flag is in effect, +# is defined here or by an -assume_charset command line flag is in effect, # Lynx will treat documents as if they were encoded accordingly. @@ -280,3 +283,3 @@ # command line option, the value for ASSUME_CHARSET or -assume_charset -# is used. It works for both text/plain and text/html files. +# is used. It works for both text/plain and text/html files. # This option will ignore "raw mode" toggling when local files are viewed @@ -288,14 +291,14 @@ -# PREPEND_CHARSET_TO_SOURCE:TRUE allow prepending a META CHARSET +# PREPEND_CHARSET_TO_SOURCE:TRUE tells Lynx to prepend a META CHARSET line # to text/html source files when they are retrieved for 'd'ownloading -# or passed to 'p'rint functions. This is necessary for resolving charset -# for local html files, while the assume_local_charset just an assumption... -# For 'd'ownload option charset will be added only if HTTP charset present. -# The compilation default is FALSE. -# It is generally desired to have charset information for every -# local html file, but META CHARSET string may cause -# compatibility problems with other browsers, so -# if you use all CHARACTER_SET, ASSUME_CHARSET, ASSUME_LOCAL_CHARSET -# unchanged from theirs default value iso-8859-1 you usually -# need not change the compilation default for PREPEND_CHARSET_TO_SOURCE. +# or passed to 'p'rint functions. This is necessary for resolving charset +# for local html files, while the assume_local_charset is just an assumption. +# For the 'd'ownload option, a META CHARSET will be added only if the HTTP +# charset is present. The compilation default is FALSE. +# It is generally desirable to have charset information for every local +# html file, but META CHARSET string potentially could cause +# compatibility problems with other browsers, so if you leave all the +# CHARACTER_SET, ASSUME_CHARSET, ASSUME_LOCAL_CHARSET variables +# set to their default value of iso-8859-1 you usually will not need to +# change the compilation default for PREPEND_CHARSET_TO_SOURCE. # Note that the prepending is not done for -source dumps. @@ -305,9 +308,10 @@ # NCR_IN_BOOKMARKS:TRUE allows you to save 8-bit characters in bookmark titles -# with unicode format (NCR). This may be useful if you need switching display -# charset frequently. This is the case when you use lynx on different -# platforms, e.g. on UNIX and from remote PC, but want to keep bookmarks file -# persistent. -# Another side is compatibility: NCR as part of I18N and HTML4.0 -# specifications supported starting with Lynx 2.7.2, Netscape 4.0 and MSIE 4.0 -# Older versions fail, keep NCR_IN_BOOKMARKS:FALSE if you plan to use them. +# in the unicode format (NCR). This may be useful if you need to switch +# display charsets frequently. This is the case when you use Lynx on different +# platforms, e.g. on UNIX and from a remote PC, and want to keep the bookmarks +# file persistent. +# Another aspect is compatibility: NCR is part of I18N and HTML4.0 +# specifications supported starting with Lynx 2.7.2, Netscape 4.0 and MSIE 4.0. +# Older browser versions will fail so keep NCR_IN_BOOKMARKS:FALSE if you +# plan to use them. # @@ -317,4 +321,4 @@ # case-conversion mechanism for case-insensitive searches in non-ASCII display -# character set, FALSE by default (should not be changed unless you encounter -# problems with case-insensitive searches). +# character sets. It is FALSE by default and should not be changed unless +# you encounter problems with case-insensitive searches. # @@ -322,8 +326,8 @@ -# While lynx supports different platforms and display character sets -# we need to limit outgoing mail character repertoire to reduce -# trouble for remote recipient who may not recognize our charset. -# You may try US-ASCII as the safest value (7 bit), any other MIME name -# or leave this field blank (default) to use display character set. -# (Translation currently implemented for mail "subjects= " only). +# While Lynx supports different platforms and display character sets +# we need to limit the charset in outgoing mail to reduce +# trouble for remote recipients who may not recognize our charset. +# You may try US-ASCII as the safest value (7 bit), any other MIME name, +# or leave this field blank (default) to use the display character set. +# Charset translations currently are implemented for mail "subjects= " only. # @@ -352,3 +356,3 @@ # "ISO-8859-2", "ISO-8859-5") which Lynx will indicate you prefer in -# requests to http servers using an Accept-Charsets header. Users can +# requests to http servers using an Accept-Charsets header. Users can # change it via the 'o'ptions menu and save that preference in their RC file. @@ -357,4 +361,4 @@ # If a file in that character set is available, the server will send it. -# "If no Accept-Charset header is present, the default is that any -# character set is acceptable. If an Accept-Charset header is present, +# If no Accept-Charset header is present, the default is that any +# character set is acceptable. If an Accept-Charset header is present, # and if the server cannot send a response which is acceptable @@ -362,3 +366,3 @@ # an error response with the 406 (not acceptable) status code, though -# the sending of an unacceptable response is also allowed." (RFC2068) +# the sending of an unacceptable response is also allowed. See RFC2068. # @@ -373,3 +377,3 @@ # .com.jp). The default lists are defined in userdefs.h and can be -# changed here. Each prefix will be used with each suffix, in order, +# replaced here. Each prefix will be used with each suffix, in order, # until a valid Internet host is created, based on a successful DNS @@ -390,3 +394,3 @@ -# Lynx Options Menu style toggle: forms-based or old-style. +# Lynx Options Menu style toggle: forms-based or old-style. # Works if old-style menu is compiled in as well as the forms-based menu. @@ -399,3 +403,3 @@ # redraws the screen in PARTIAL mode. Anything < 0 implies -# use the screen size. +# use of the screen size. #PARTIAL_THRES:-1 @@ -404,3 +408,3 @@ # Set this to change the units shown: -# TRUE for KB/sec or FALSE for bytes/sec: default is TRUE. +# TRUE for KB/sec or FALSE for bytes/sec: default is TRUE. #SHOW_KB_RATE:TRUE @@ -450,4 +454,5 @@ # [IMAGE] comments (for images without ALT) with filenames of these images. -# This is extremely useful because now we can determine immediately what images -# are just decorations (button.gif, line.gif) and what images are important. +# This can be useful in determining what images are decorations +# (button.gif, line.gif) and what images are important (if the page writer +# bothers to use useful names). # @@ -493,7 +498,7 @@ # the DEFAULT_CACHE_SIZE and DEFAULT_VIRTUAL_MEMORY_SIZE are exceeded, then -# least recently displayed documents will be freed until one or the other -# value is no longer exceeded. The default value was defined in userdefs.h. +# the least recently displayed documents will be freed until one or the other +# value is no longer exceeded. The default value is defined in userdefs.h. # -# The Unix and VMS but not VAXC implementations use the C library malloc's -# and calloc's for memory allocation, and procedures for taking the actual +# The Unix and VMS (but not VAXC) implementations use the C library malloc's +# and calloc's for memory allocation, but procedures for taking the actual # amount of cache into account still need to be developed. They use only @@ -559,6 +564,5 @@ -# Local execution links and scripts are completely disabled -# in the source code unless they are enabled in the -# userdefs.h file and the sources recompiled. Please -# see the Lynx source code distribution and the userdefs.h +# Local execution links and scripts are by default completely disabled +# unless a change is made to the userdefs.h file to enabled them. +# See the Lynx source code distribution and the userdefs.h # file for more detail on enabling execution links and scripts. @@ -632,3 +636,3 @@ # anonymous accounts in which you have disabled execution links generally, -# and may also have disabled jump file links, but still want to allow +# and may also have disabled jumps file links, but still want to allow # execution of particular utility scripts or programs. The format is @@ -669,3 +673,3 @@ # environment variable to the list of environment variables passed on to the -# lynxcgi script. Useful variables are HOME, USER, EDITOR, etc... +# lynxcgi script. Useful variables are HOME, USER, EDITOR, etc... # @@ -704,3 +708,3 @@ # -# NOTE: This can generate A LOT of mail, be warned. +# NOTE: This can generate A LOT of mail, be warned. # @@ -727,4 +731,4 @@ # must be set so that it points to your site's NNTP server (see INSTALLATION). -# Lynx respects RFC 1738 (http://www.ics.uci.edu/pub/ietf/uri/rfc1738.txt) and -# and does not accept a host field in news URLs (use nntp: instead news: for +# Lynx respects RFC 1738 (http://www.ics.uci.edu/pub/ietf/uri/rfc1738.txt) +# and does not accept a host field in news URLs (use nntp: instead of news: for # the scheme if you wish to specify an NNTP host in a URL, as explained in the @@ -734,2 +738,4 @@ # outlive the Lynx image. +# The news reading facility in Lynx is quite limited. Lynx does not provide a +# full featured news reader with elaborate error checking and safety features. # @@ -771,3 +777,3 @@ # post new messages or followups to news groups, using the URL schemes -# described in the "Supported URL" section of the online 'h'elp. The +# described in the "Supported URLs" section of the online 'h'elp. The # posts will be attempted via the nntp server specified in the URL, or @@ -780,2 +786,4 @@ # -restrictions command line switch. +# The posting facility in Lynx is quite limited. Lynx does not provide a +# full featured news poster with elaborate error checking and safety features. # @@ -794,3 +802,3 @@ # the user to click with button-1 on links to select them. -#USE_MOUSE: FALSE +#USE_MOUSE:FALSE @@ -833,3 +841,3 @@ # COOKIE_FILE is the default file to store persistent downloaded cookies -# in, if Lynx was compiled with EXP_PERSISTENT_COOKIES. The cookie file +# in, if Lynx was compiled with EXP_PERSISTENT_COOKIES. The cookie file # can also be specified in .lynxrc or on the commandline. @@ -837,3 +845,4 @@ -# PERSISTENT_COOKIES is tested only if Lynx was compiled with +# PERSISTENT_COOKIES indicates that cookies should be stored for use between +# Lynx sessions. It is only used if Lynx was compiled with # EXP_PERSISTENT_COOKIES. Use this flag to disable the feature. @@ -908,8 +917,7 @@ -# DEFAULT_KEYPAD_MODE specifies whether by default the user -# has numbers that work like arrows or else numbered links. -# DEFAULT KEYPAD MODE may be set to TRUE for using numbers -# as arrows as the default, or FALSE for using numbered links -# as the default (LINKS_AND_FORM_FIELDS_ARE_NUMBERED cannot -# currently be set by this option.). +# DEFAULT_KEYPAD_MODE specifies whether numbers work like arrows or +# numbered links. +# DEFAULT_KEYPAD_MODE set to TRUE indicates numbers act as arrows, +# and set to FALSE indicates numbers refer to numbered links on the patge. +# LINKS_AND_FORM_FIELDS_ARE_NUMBERED cannot currently be set by this option. # @@ -922,6 +930,6 @@ -# DEFAULT_BOOKMARK_FILE is a default filename for use as a personal -# bookmark file. It will reference a file from the user's home directory. +# DEFAULT_BOOKMARK_FILE is the filename used for storing personal bookmarks. +# It will be prepended by the user's home directory. # NOTE that a file ending in .html or other suffix mapped to text/html -# should be used to ensure it's treatment as HTML. The built-in default +# should be used to ensure its treatment as HTML. The built-in default # is lynx_bookmarks.html. On both Unix and VMS, if a subdirectory off of @@ -948,3 +956,3 @@ # default via the .lynxrc file. When on, the setting can be STANDARD or -# ADVANCED. If support is set to the latter, and the user mode also is +# ADVANCED. If SUPPORT is set to the latter, and the user mode also is # ADVANCED, the VIEW_BOOKMARK command will invoke a statusline prompt at @@ -952,3 +960,3 @@ # or '=' to get a menu of available bookmark files. The menu always is -# presented in NOVICE or INTERMEDIATE mode, or if the support is set to +# presented in NOVICE or INTERMEDIATE mode, or if the SUPPORT is set to # STANDARD. No prompting or menu display occurs if only one (the startup @@ -970,5 +978,5 @@ # DEFAULT_USER_MODE sets the default user mode for Lynx users. -# NOVICE shows a three line help message at the bottom of the screen -# INTERMEDIATE shows normal amount of help (one line) -# ADVANCED help is replaced by the URL of the current link +# NOVICE shows a three line help message at the bottom of the screen. +# INTERMEDIATE shows normal amount of help (one line). +# ADVANCED help is replaced by the URL of the current link. # @@ -984,3 +992,3 @@ # know how to use it. Most users do not enjoy getting stuck in -# an unknown editor that they can't get out of. Users can +# an unknown editor that they can't exit. Users can # easily define an editor of their own using the options menu, @@ -1077,2 +1085,3 @@ # even if it does not physically print anything. +# # Usually, downloading involves the use of (e.g.) Ckermit or ZModem @@ -1118,4 +1127,4 @@ # uploader definition sets. Uploaders may be any program -# that could be useful to your users, they do not necessarily -# have to be an upload protocol program. The most common use +# that could be useful to your users; they do not necessarily +# have to be an upload protocol program. The most common use # of an uploader is to use Ckermit or some other transfer @@ -1181,3 +1190,3 @@ # strings will have '-' and a link labeled "[IMAGE]" for the resolved SRC -# appended. See also VERBOSE_IMAGES flag. +# appended. See also VERBOSE_IMAGES flag. # @@ -1222,3 +1231,3 @@ # behavior of treating any '>' as a terminator for comments, instead of -# seeking a valid '-->' terminator (note that white space can be present +# seeking a valid '-->' terminator (white space can be present # between the '--' and '>' in valid terminators). The compilation default @@ -1419,3 +1428,3 @@ # -# Note: if you do not define a viewer to a new MIME type +# NOTE: if you do not define a viewer to a new MIME type # that you assigned above then it will be saved to @@ -1665,16 +1674,16 @@ # -# type: TAG: list only when one or more files are tagged -# FILE: list only when the current selection is a regular file -# DIR: list only when the current selection is a directory -# LINK: list only when the current selection is a symbolic link +# type: TAG: list only when one or more files are tagged +# FILE: list only when the current selection is a regular file +# DIR: list only when the current selection is a directory +# LINK: list only when the current selection is a symbolic link # -# suffix: list only if the current selection ends in this pattern +# suffix: list only if the current selection ends in this pattern # -# link text: the displayed text of the link +# link text: the displayed text of the link # -# extra text: the text displayed following the link +# extra text: the text displayed following the link # -# action: the URL to be followed upon selection +# action: the URL to be followed upon selection # -# link text and action are scanned for % sequences that are expanded +# link text and action are scanned for % sequences that are expanded # at display time as follows: @@ -1796,3 +1805,3 @@ -# External application support. This feature allows lynx to pass a given +# External application support. This feature allows Lynx to pass a given # URL to an external program. It was written for three reasons. @@ -1805,3 +1814,3 @@ # -# 3) To allow for new URLs to be used through lynx. +# 3) To allow for new URLs to be used through Lynx. # URLs can be made up such as mymail: to spawn desired applications @@ -1809,3 +1818,3 @@ # -# Restrictions can be imposed using -restrictions=externals at the lynx +# Restrictions can be imposed using -restrictions=externals at the Lynx # command line. This will disallow all EXTERNAL lines in lynx.cfg that @@ -1827,3 +1836,3 @@ # for certain externals to be enabled while restricting others. TRUE means -# a command will still function while lynx is restricted. WB +# a command will still function while Lynx is restricted. WB # -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 12:09:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA11519 for ; Sat, 7 Nov 1998 12:09:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA13530; Sat, 7 Nov 1998 10:53:33 -0600 (CST) From: Philip Webb Message-Id: <199811071654.LAA02398@chass.utoronto.ca> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 11:54:13 -0500 (EST) In-Reply-To: <9811071108.AA22493@cas.org> from "Larry W. Virden" at Nov 7, 98 11:08:47 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: 532 Lines: 10 981107 Larry Virden offered many nit fixes for lynx.cfg -- snipped -- : mostly improvements, at a quick glance, but there is >= 1 typo: `patge'; i would write 2 spaces following . , but not after : ; one pair of +/- lines re iso-8859-1 are identical ... -- ========================,,============================================ 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 Nov 7 13:29:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA16117 for ; Sat, 7 Nov 1998 13:29:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA23333; Sat, 7 Nov 1998 12:09:57 -0600 (CST) To: lynx-dev@sig.net References: <9811071108.AA22493@cas.org> Message-Id: From: "Leonid Pauzner" Date: Sat, 7 Nov 1998 21:04:43 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev some proposed nit fixes 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: 3159 Lines: 59 Thanks! The only new problem can be introduced by "raw CJK mode". Exact meaning should be: 1) when the document's charset specified explicitely - it always converts to display character set. 2) when the document's charset not specified explicitely ASSUME_CHARSET get in effect. There is a special case: Asian (CJK) display character sets, for which the corresponding charset is assumed in documents, i.e., we introduce `CJK mode' or `raw mode'... .... > --- lynx.cfg-dist Fri Nov 6 09:29:41 1998 > +++ lynx.cfg-new Sat Nov 7 11:07:49 1998 > @@ -175,17 +176,19 @@ > # language or group of languages besides MIME name). Not all 'human-readable' > -# names correspond to exactly one valid MIME charset (example is "Chinese"), in > -# that case an appropriate valid (and more specific) MIME name should be used > -# where required. Well-known synonyms are also processed in the code. > -# > -# Lynx normally translates characters from document's charset to display > -# charset, using ASSUME_CHARSET value (see below) if document's charset is not > -# specified explicitly. There is the so called `raw or CJK mode' which is OFF > -# for this case. (When the document charset specified explicitly > -# it override any assumption like ASSUME_CHARSET or raw or CJK mode). > +# names correspond to exactly one valid MIME charset (example is "Chinese"); > +# in that case an appropriate valid (and more specific) MIME name should be > +# used where required. Well-known synonyms are also processed in the code. > +# > +# Raw (CJK) mode > +# > +# Lynx normally translates characters from a document's charset to display > +# charset, using ASSUME_CHARSET value (see below) if the document's charset > +# is not specified explicitly. Raw CJK mode is OFF for this case. > +# When the document charset is specified explicitly, that charset > +# overrides any assumption like ASSUME_CHARSET or raw CJK mode. > # > -# For the Asian (CJK) display character sets the corresponding charset is > -# assumed in documents, i.e., raw or CJK mode is ON by default. In raw CJK > +# For the Asian (CJK) display character sets, the corresponding charset is > +# assumed in documents, i.e., raw CJK mode is ON by default. In raw CJK > # mode, 8-bit characters are not reverse translated in relation to the entity > # conversion arrays, i.e., they are assumed to be appropriate for the display > -# character set. It should be toggled OFF when an Asian (CJK) display > +# character set. The mode should be toggled OFF when an Asian (CJK) display > # character set is selected but the document is not CJK and its charset not > @@ -193,6 +196,6 @@ > # > -# The `raw or CJK mode' may be toggled by user via '@' (LYK_RAW_TOGGLE) key, > -# with -raw command line switch or from 'o'ptions menu. > +# Raw CJK mode may be toggled by user via '@' (LYK_RAW_TOGGLE) key, > +# the -raw command line switch or from the 'o'ptions menu. > # > -# Raw mode effectively changes the charset assumption about unlabeled > +# Raw CJK mode effectively changes the charset assumption about unlabeled > # documents. You can toggle raw mode ON if you believe the document has a From owner-lynx-dev@sig.net Sat Nov 7 13:44:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA17051 for ; Sat, 7 Nov 1998 13:44:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA25615; Sat, 7 Nov 1998 12:29:30 -0600 (CST) Date: Sat, 7 Nov 1998 10:29:51 -0800 (PST) From: David Combs Message-Id: <199811071829.KAA08487@netcom17.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Misplaced?
      breaks anchor. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 659 Lines: 23 > From owner-lynx-dev@sig.net Fri Nov 6 16:22:09 1998 > Date: Sat, 7 Nov 1998 09:19:23 +0900 (JST) > From: Nelson Henry Eric > > > Re: doc tweak, maybe for your beginners' primer. I don't think > words like `tagsoup' and `sorta-sgml' are what should be in short > descriptions in the `k' keybinding list. > > __Henry > Well, the reader of the K list shouldn't have to learn a new set of synonyms just to be able to follow lynx-dev discussions. WHY did fote call it "tag soup"? Maybe that is actually a good name -- as long as its derivation is explained somewhere. After all, it IS what everyone here calls it! David From owner-lynx-dev@sig.net Sat Nov 7 14:06:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA18582 for ; Sat, 7 Nov 1998 14:06:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA27879; Sat, 7 Nov 1998 12:49:47 -0600 (CST) From: dickey@clark.net Message-Id: <199811071850.NAA13471@shell.clark.net> Subject: Re: another pitch for internationalization [was Re: lynx-dev idea regarding 'Submit' links] To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 13:50:54 -0500 (EST) In-Reply-To: <9811070924.AA21671@cas.org> from "lvirden@cas.org" at Nov 7, 98 09:24:05 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: 627 Lines: 18 > > >> At least 2.8.3 :). Anyway, until Jim's patches get applied, there's not > > > >I thought we were headed for 2.8.2 (aside from the global nature of > > I agree - the internationalization of the msgs would not in my mind be enough > to up the second version level. > > Has anyone out there patched lynx to support 64 bit int support? That's a > rather popular, and painful, current activity around the net. 2.8.1 builds clean & runs on Digital Unix (which is a 64-bit platform). > Larry W. Virden INET: lvirden@cas.org -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 14:33:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA20348 for ; Sat, 7 Nov 1998 14:33:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA00988; Sat, 7 Nov 1998 13:14:13 -0600 (CST) From: dickey@clark.net Message-Id: <199811071916.OAA16455@shell.clark.net> Subject: Re: lynx-dev Misplaced?
      breaks anchor. To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 14:16:06 -0500 (EST) In-Reply-To: <199811071829.KAA08487@netcom17.netcom.com> from "David Combs " at Nov 7, 98 10:29: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: 1300 Lines: 39 > > > From owner-lynx-dev@sig.net Fri Nov 6 16:22:09 1998 > > Date: Sat, 7 Nov 1998 09:19:23 +0900 (JST) > > From: Nelson Henry Eric > > > > > > Re: doc tweak, maybe for your beginners' primer. I don't think > > words like `tagsoup' and `sorta-sgml' are what should be in short > > descriptions in the `k' keybinding list. > > > > __Henry > > > > Well, the reader of the K list shouldn't have to learn > a new set of synonyms just to be able to follow > lynx-dev discussions. > > WHY did fote call it "tag soup"? Maybe that is actually > a good name -- as long as its derivation is explained > somewhere. I suppose it's in the archive - but my understanding is that Klaus and Fote disagreed on how to handle error recovery when tags are improperly nested. Klaus wanted to reject things that weren't properly nested, and Fote made some allowances (i.e., the tags didn't have to follow the standard structure), so someone dubbed it tag-soup. (Much of the initial discussion seems to have been private email between them, or else it started long before I started working on Lynx at the beginning of 1997) > After all, it IS what everyone here calls it! > > David -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 15:26:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA23645 for ; Sat, 7 Nov 1998 15:26:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA07178; Sat, 7 Nov 1998 14:07:17 -0600 (CST) Date: Sat, 7 Nov 1998 12:08:40 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: <9811071108.AA22493@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: 4441 Lines: 101 Many changes here go from correct grammar to less correct formulations. I believe that following changes should not be implemented. I made a few alternate suggestions. I didn't check for tab characters. I would hope that the file would be filtered through expand before it becomes final. Overall, this seems like a good attempt to increase clarity. Doug On Sat, 7 Nov 1998, Larry W. Virden wrote: > --- lynx.cfg-dist Fri Nov 6 09:29:41 1998 > +++ lynx.cfg-new Sat Nov 7 11:07:49 1998 > -# trailing white space will be trimmed, and a single space added by Lynx > +# trailing white space will be trimmed, and a single space is added by Lynx > ... > -# their actual URL's. See the sample jumps files in the samples > +# their actual URL's. See the jumps files in the lynx*/samples > ... > -# Additional, alternate jumps files can be defined and mapped to > +# Additional alternate jumps files can be defined and mapped to > ... > -# CHARACTER_SET defines the display character set, i.e., that assumed to be > +# CHARACTER_SET defines the display character set, i.e., assumed to be The following need to be "Raw (CJK)" rather than "Raw CJK" > +# Raw CJK mode may be toggled by user via '@' (LYK_RAW_TOGGLE) key, > +# the -raw command line switch or from the 'o'ptions menu. > # > -# Raw mode effectively changes the charset assumption about unlabeled > +# Raw CJK mode effectively changes the charset assumption about unlabeled More lines that shouldn't be changed. > -# that cpXXX codepages used by IBM PC compatible computers, and windows-xxxx > -# used by native MS-Windows apps. We also note that cpXXX pages rerely found > -# on Internet but mostly for local needs on DOS. > +# the cpXXX codepages used by IBM PC compatible computers, and windows-xxxx > +# used by native MS-Windows apps. We also note that cpXXX pages rarely are > ... > -# the sending of an unacceptable response is also allowed." (RFC2068) > +# the sending of an unacceptable response is also allowed. See RFC2068. > ... > -# changed here. Each prefix will be used with each suffix, in order, > +# replaced here. Each prefix will be used with each suffix, in order, > ... > -# use the screen size. > +# use of the screen size. > ... > -# Local execution links and scripts are completely disabled > -# in the source code unless they are enabled in the > -# userdefs.h file and the sources recompiled. Please > -# see the Lynx source code distribution and the userdefs.h > +# Local execution links and scripts are by default completely disabled > +# unless a change is made to the userdefs.h file to enabled them. > +# See the Lynx source code distribution and the userdefs.h The following is a typo. > +# DEFAULT_KEYPAD_MODE set to TRUE indicates numbers act as arrows, > +# and set to FALSE indicates numbers refer to numbered links on the patge. ^ A suggested change: > -# DEFAULT_BOOKMARK_FILE is a default filename for use as a personal > -# bookmark file. It will reference a file from the user's home directory. > +# DEFAULT_BOOKMARK_FILE is the filename used for storing personal bookmarks. > +# It will be prepended by the user's home directory. I think that this might be better as "It must be specified relative to the user's home directory" > -# an unknown editor that they can't get out of. Users can > +# an unknown editor that they can't exit. Users can This might be better as "an unknown editor from which they can't exit" The following line has a typo > # uploader definition sets. Uploaders may be any program ^^^^^^^ This should be "programs" > -# that could be useful to your users, they do not necessarily > -# have to be an upload protocol program. The most common use > +# that could be useful to your users; they do not necessarily > +# have to be an upload protocol program. The most common use ^^^^^^^ This should be "have to be upload protocol programs." More lines that should not be changed: > -# seeking a valid '-->' terminator (note that white space can be present > +# seeking a valid '-->' terminator (white space can be present > # between the '--' and '>' in valid terminators). The compilation default __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Nov 7 18:24:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA02925 for ; Sat, 7 Nov 1998 18:24:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA27516; Sat, 7 Nov 1998 17:08:04 -0600 (CST) Date: Sat, 7 Nov 1998 18:09:30 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811071809.AA24863@cas.org> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: of Sat, 7 Nov 1998 21:04:43 +0300 (MSK) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 492 Lines: 8 Originally the text read like 'raw or CJK mode' or 'raw mode' or 'it' - I considered calling it just 'raw' or 'CJK', but I didn't think that flowed as well because of the other wording. However, feel free to submit patches to word it better. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 18:26:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA02954 for ; Sat, 7 Nov 1998 18:26:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA27339; Sat, 7 Nov 1998 17:06:16 -0600 (CST) Date: Sat, 7 Nov 1998 18:07:42 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811071807.AA24852@cas.org> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: <199811071654.LAA02398@chass.utoronto.ca> of Sat, 7 Nov 1998 11:54:13 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 388 Lines: 6 The spaces after : are mixed so I stated to turn them into 1, then decided because there were so many already with 2 to go with 2. Shrug. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 18:47:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA04339 for ; Sat, 7 Nov 1998 18:47:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA28677; Sat, 7 Nov 1998 17:18:56 -0600 (CST) Date: Sat, 7 Nov 1998 18:20:48 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811071820.AA24883@cas.org> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: of Sat, 7 Nov 1998 12:08:40 -0800 (PST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4204 Lines: 93 From: Doug Kaufman > Many changes here go from correct grammar to less correct > formulations. I believe that following changes should not be > On Sat, 7 Nov 1998, Larry W. Virden wrote: > > > --- lynx.cfg-dist Fri Nov 6 09:29:41 1998 > > +++ lynx.cfg-new Sat Nov 7 11:07:49 1998 > > -# trailing white space will be trimmed, and a single space added by Lynx > > +# trailing white space will be trimmed, and a single space is added by Lynx > > ... I disagree that was correct originally. > > -# their actual URL's. See the sample jumps files in the samples > > +# their actual URL's. See the jumps files in the lynx*/samples In this case, URL's should be URLs. Sorry - I started to make that change (as well as a pass thru fixing all the incorrect uses of it's) and got sidetracked by the kids needing to leave. I also disagree that saying sample jumps files in the samples directory is better than saying the jumps files in the lynx*/samples directory. > > ... > > -# Additional, alternate jumps files can be defined and mapped to > > +# Additional alternate jumps files can be defined and mapped to My college English book indicated the comma in this case was a coin toss... > > -# CHARACTER_SET defines the display character set, i.e., that assumed to be > > +# CHARACTER_SET defines the display character set, i.e., assumed to be I can't fathom how that "that" can be correct. > The following need to be "Raw (CJK)" rather than "Raw CJK" That's fine - trying to change the original "raw or CJK mode" was what I was addressing. > More lines that shouldn't be changed. > > > -# that cpXXX codepages used by IBM PC compatible computers, and windows-xxxx > > -# used by native MS-Windows apps. We also note that cpXXX pages rerely found > > -# on Internet but mostly for local needs on DOS. > > +# the cpXXX codepages used by IBM PC compatible computers, and windows-xxxx > > +# used by native MS-Windows apps. We also note that cpXXX pages rarely are > > ... > > -# the sending of an unacceptable response is also allowed." (RFC2068) > > +# the sending of an unacceptable response is also allowed. See RFC2068. Hey! Those quotation marks were removed before me - I just wanted to make that RFC2068 a bit clearer. Shrug. > > -# Local execution links and scripts are completely disabled > > -# in the source code unless they are enabled in the > > -# userdefs.h file and the sources recompiled. Please > > -# see the Lynx source code distribution and the userdefs.h > > +# Local execution links and scripts are by default completely disabled > > +# unless a change is made to the userdefs.h file to enabled them. > > +# See the Lynx source code distribution and the userdefs.h Tom, if you don't like my wording, please consider reworking the original wording, which was so torturous that even a native English speaker had to reread it several times to figure out the point of the lines. > I think that this might be better as "It must be specified relative to > the user's home directory" That's how I started to write it - but I had just worked thru the META CHARSET section and thought using the words prepended might be a bit easy for the novice reader to figure out than the idea of relative pathnames. Either way works fine for me. > > -# an unknown editor that they can't get out of. Users can > > +# an unknown editor that they can't exit. Users can > > This might be better as "an unknown editor from which they can't exit" Good point - I should have caught that one myself. Those "that" phrases usually catch my attention but somehow escaped me this time. > > -# seeking a valid '-->' terminator (note that white space can be present > > +# seeking a valid '-->' terminator (white space can be present > > # between the '--' and '>' in valid terminators). The compilation default the original seemed too wordy too me - I don't see a change in meaning by using less words. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 7 19:04:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA05232 for ; Sat, 7 Nov 1998 19:04:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01351; Sat, 7 Nov 1998 17:43:29 -0600 (CST) From: Philip Webb Message-Id: <199811072344.SAA09341@chass.utoronto.ca> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 18:44:08 -0500 (EST) In-Reply-To: <9811071807.AA24852@cas.org> from "Larry W. Virden" at Nov 7, 98 06:07:42 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: 830 Lines: 16 981107 Larry Virden wrote: > The spaces after : are mixed so I stated to turn them into 1, then decided > because there were so many already with 2 to go with 2. Shrug. yup, you called them `nits'. the documentation needs a lot of improvement & it has to be done nit by nit, basically. i've tried to do a bit & am delighted to see you & LP have a go too: please do more. BTW when documenting, LP needs to remember `the', `is' & `has', none of which have (has?) counterparts in Russian, of course; i never could get the hang of perfective verbs ... (grin). -- ========================,,============================================ 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 Nov 7 19:32:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA06979 for ; Sat, 7 Nov 1998 19:32:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA04489; Sat, 7 Nov 1998 18:11:47 -0600 (CST) Date: Sun, 8 Nov 1998 09:13:27 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811080013.JAA09738@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev internationalization Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1037 Lines: 23 > Does this looks useful to change XXX_TITLE to open text string? Not as important as strings containing instructions, but it would be VERY nice to have native language titles, too. I'm not a programmer, so I cannot make decisions concerning the way things are coded, but it would seem more efficient to have XXX_TITLE, and other strings repeated in multiple places, be defined like: #define LYNX_TRACELOG_TITLE gettext("Lynx Trace Log") rather than the present ``#define LYNX_TRACELOG_TITLE "Lynx Trace Log"''? Wouldn't such an approach, if it's possible at all, also aid in with backward compatibility? > > ! strcmp((curdoc.title ? curdoc.title : gettext("")), ^^ I suspect Jim used a script to edit the source files so this kind of error popped up. The "", i.e., nothing, string is reserved for required header information in the *.po file. Therefore if Lynx does go the GNU NLS route, past and future "" need to be handled with a NUL define, or something like that. __Henry From owner-lynx-dev@sig.net Sat Nov 7 19:40:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA07699 for ; Sat, 7 Nov 1998 19:40:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA05375; Sat, 7 Nov 1998 18:20:17 -0600 (CST) Date: Sun, 8 Nov 1998 09:23:24 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811080023.JAA09788@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 507 Lines: 10 > -# The `raw or CJK mode' may be toggled by user via '@' (LYK_RAW_TOGGLE) key, > -# with -raw command line switch or from 'o'ptions menu. > +# Raw CJK mode may be toggled by user via '@' (LYK_RAW_TOGGLE) key, > +# the -raw command line switch or from the 'o'ptions menu. You've caught me at a bad time, Larry. I'm just swamped with work and can't read through this carefully. I worry about "Raw CJK mode". Isn't that "raw OR cjk" mode, i.e., it's either Raw or CJK depending on other settings? __Henry From owner-lynx-dev@sig.net Sat Nov 7 21:30:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA15473 for ; Sat, 7 Nov 1998 21:30:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA17087; Sat, 7 Nov 1998 20:08:49 -0600 (CST) From: dickey@clark.net Message-Id: <199811080210.VAA23646@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 21:10:31 -0500 (EST) In-Reply-To: <199811080013.JAA09738@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 8, 98 09:13:27 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: 1294 Lines: 35 > > Does this looks useful to change XXX_TITLE to open text string? > > Not as important as strings containing instructions, but it would be > VERY nice to have native language titles, too. > > I'm not a programmer, so I cannot make decisions concerning the way > things are coded, but it would seem more efficient to have XXX_TITLE, > and other strings repeated in multiple places, be defined like: > > #define LYNX_TRACELOG_TITLE gettext("Lynx Trace Log") that's what I'm doing. > rather than the present ``#define LYNX_TRACELOG_TITLE "Lynx Trace Log"''? > Wouldn't such an approach, if it's possible at all, also aid in with > backward compatibility? > > > > ! strcmp((curdoc.title ? curdoc.title : gettext("")), > ^^ > I suspect Jim used a script to edit the source files so this kind of > error popped up. The "", i.e., nothing, string is reserved for required or else he used a global substitution. I did notice some of those (and repaired them). > header information in the *.po file. Therefore if Lynx does go the GNU > NLS route, past and future "" need to be handled with a NUL define, or > something like that. > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 21:38:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA15814 for ; Sat, 7 Nov 1998 21:38:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA18021; Sat, 7 Nov 1998 20:17:41 -0600 (CST) From: dickey@clark.net Message-Id: <199811080213.VAA24336@shell.clark.net> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg To: lynx-dev@sig.net Date: Sat, 7 Nov 1998 21:13:18 -0500 (EST) In-Reply-To: <199811072344.SAA09341@chass.utoronto.ca> from "Philip Webb " at Nov 7, 98 06:44: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: 1170 Lines: 29 > > 981107 Larry Virden wrote: > > The spaces after : are mixed so I stated to turn them into 1, then decided > > because there were so many already with 2 to go with 2. Shrug. when it looks messy, I just reformat the comments anyway (the content is a little more important than worrying about special cases of spacing after ':'). > yup, you called them `nits'. the documentation needs a lot of improvement > & it has to be done nit by nit, basically. i've tried to do a bit > & am delighted to see you & LP have a go too: please do more. > > BTW when documenting, LP needs to remember `the', `is' & `has', > none of which have (has?) counterparts in Russian, of course; > i never could get the hang of perfective verbs ... (grin). he's doing fine afaik, with an occasional mismatch on idioms. > -- > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca > ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies > TRANSIT `-O----------O---' University of Toronto -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 7 22:14:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA18603 for ; Sat, 7 Nov 1998 22:14:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA21689; Sat, 7 Nov 1998 20:49:51 -0600 (CST) Date: Sat, 7 Nov 1998 18:51:47 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: <9811071820.AA24883@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: 3095 Lines: 72 On Sat, 7 Nov 1998, Larry W. Virden wrote: > > > -# trailing white space will be trimmed, and a single space added by Lynx > > > +# trailing white space will be trimmed, and a single space is added by Lynx > > > ... > > I disagree that was correct originally. This is parallel structure, expanding to "trailing white space will be trimmed, and a single space will be added by Lynx". Your change loses the structure, with the first part in future tense, and the second part present. > > > > -# their actual URL's. See the sample jumps files in the samples > > > +# their actual URL's. See the jumps files in the lynx*/samples > > In this case, URL's should be URLs. Sorry - I started to make that change > (as well as a pass thru fixing all the incorrect uses of it's) and got > sidetracked by the kids needing to leave. I also disagree that saying > sample jumps files in the samples directory is better than saying the > jumps files in the lynx*/samples directory. The reason I liked the original was that it indicated specifically that the file was a sample file (i.e. to be changed by the user) and was in the samples subdirectory. I suspect that many users wouldn't understand that "lynx*/samples" refers to "lynx2-8-1/samples". This requires at least simple knowledge of regular expressions, which may be too much to ask. > > > > ... > > > -# Additional, alternate jumps files can be defined and mapped to > > > +# Additional alternate jumps files can be defined and mapped to > > My college English book indicated the comma in this case was a coin toss... These are both acceptable, but mean different things. The first talks about additional files which can be alternate jumps files. The latter about more alternate jumps files (implying at least one alternate jumps file already in existence). > > > > -# CHARACTER_SET defines the display character set, i.e., that assumed to be > > > +# CHARACTER_SET defines the display character set, i.e., assumed to be > > I can't fathom how that "that" can be correct. This is actually quite correct. There is an implied antecedent, "character set", so this expands to "that character set assumed to be" > > I think that this might be better as "It must be specified relative to > > the user's home directory" > > That's how I started to write it - but I had just worked thru the META CHARSET > section and thought using the words prepended might be a bit easy for the > novice reader to figure out than the idea of relative pathnames. Either > way works fine for me. My thought was that the word "prepend" is an unusual term that would send many users to the dictionary. I think that this may be enough discussion of fine points of English usage. The key is to make the document as clear and unambiguous as possible to the novice user, while keeping the technical information needed by those more experienced. It doesn't have to be grammatically correct as long as users can understand what we mean. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Nov 7 22:40:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA20559 for ; Sat, 7 Nov 1998 22:40:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA25945; Sat, 7 Nov 1998 21:26:57 -0600 (CST) Date: Sat, 7 Nov 1998 20:45:40 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811072045.AA25878@cas.org> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg In-Reply-To: <199811080023.JAA09788@ews07.nara.kindai.ac.jp> of Sun, 8 Nov 1998 09:23:24 +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: 383 Lines: 7 Hmm - the way it read originally I thought it was one mode. If it's two cases, then the wording needs changed to reflect this. Thanks -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 8 02:32:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA08631 for ; Sun, 8 Nov 1998 02:32:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA19010; Sun, 8 Nov 1998 01:17:56 -0600 (CST) Date: Sat, 7 Nov 1998 23:19:59 -0800 (PST) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: lynx-dev programming forms in lynx 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: 708 Lines: 16 Hello Everyone! I have a problem/question/suggestion. I would like to have a document in my own directory (unix user) that behaves like a form, but without a cgi program to interpret it (because something like that does not exist in my server). I would like the cgi interpretation to be made by lynx, that is to say I want to have a menu in a local html file (say my bookmarks file), group them in options menu, select one of them and lynx do the work of the cgi program that takes me to the link I choose. I am thinking of something like the options menu forms, but in that case there's no html file. Am I clear enough ? Have a great day! Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Sun Nov 8 04:11:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA14471 for ; Sun, 8 Nov 1998 04:11:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA24316; Sun, 8 Nov 1998 02:34:18 -0600 (CST) To: lynx-dev@sig.net References: <199811080210.VAA23646@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Sun, 8 Nov 1998 11:30:12 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev internationalization 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 >> > Does this looks useful to change XXX_TITLE to open text string? >> >> #define LYNX_TRACELOG_TITLE gettext("Lynx Trace Log") > that's what I'm doing. >> rather than the present ``#define LYNX_TRACELOG_TITLE "Lynx Trace Log"''? >> Wouldn't such an approach, if it's possible at all, also aid in with >> backward compatibility? >> >> > > ! strcmp((curdoc.title ? curdoc.title : gettext("")), >> ^^ >> I suspect Jim used a script to edit the source files so this kind of >> error popped up. The "", i.e., nothing, string is reserved for required > or else he used a global substitution. I did notice some of those > (and repaired them). I wonder, why not to insert gettext() in every message in LYMessages.en.h with the renaming file to LYMessages.h at the initial stage without global expanding of messages back to the C source, it was more maintainable at least. Except LYMessages there are only a few "internal pages" like Print or Cookie, which (probably) need a translation. From owner-lynx-dev@sig.net Sun Nov 8 07:43:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA05028 for ; Sun, 8 Nov 1998 07:30:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA08089; Sun, 8 Nov 1998 06:14:32 -0600 (CST) From: dickey@clark.net Message-Id: <199811081216.HAA08560@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 07:16:31 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 8, 98 11:30:12 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: 810 Lines: 21 > I wonder, why not to insert gettext() in every message in LYMessages.en.h > with the renaming file to LYMessages.h at the initial stage without global > expanding of messages back to the C source, it was more maintainable at least. again - that's what I'm doing. but there's a lot of strings that aren't #define'd in LYMessages_en.h -- JES's version finds many of them, and I'm adding a few, both to LYMessages_en.h and to the inline stuff (if I stop to #define every string I see, it'll take a week). Once done, it'll be simple to grep the result for 'gettext' and think about how best to proceed. > Except LYMessages there are only a few "internal pages" like Print or Cookie, > which (probably) need a translation. > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 8 08:33:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA13508 for ; Sun, 8 Nov 1998 08:33:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA12708; Sun, 8 Nov 1998 07:17:16 -0600 (CST) Date: Sun, 8 Nov 1998 05:19:16 -0800 (PST) From: David Combs Message-Id: <199811081319.FAA16594@netcom2.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1739 Lines: 45 > From owner-lynx-dev@sig.net Sat Nov 7 15:50:53 1998 > From: Philip Webb > > 981107 Larry Virden wrote: > > The spaces after : are mixed so I stated to turn them into 1, then decided > > because there were so many already with 2 to go with 2. Shrug. > > yup, you called them `nits'. the documentation needs a lot of improvement > & it has to be done nit by nit, basically. i've tried to do a bit > & am delighted to see you & LP have a go too: please do more. > > BTW when documenting, LP needs to remember `the', `is' & `has', > none of which have (has?) counterparts in Russian, of course; > i never could get the hang of perfective verbs ... (grin). "Nits". Someone gives me a contract to sign; I go through it and find things to fix, to make make more sense as to the intentions of the parties. Would rather decide those now, than later via some judge doing it. So what do I get? "Nit, Nit, Nit! Just leave it alone, Combs. Our lawyers have approved this contract, and that's it, we can't change it" (that last part is a blatent lie, always. Maybe the whole thing too, who knows). Nit Nit Nit! Yes, FIX them, every darn one, to hell with the complainers. Then turn it over to me, and let me have a go -- except you have to REALLY know lynx to do that, and I don't, so that's not a good idea. Russian, no. English, yes, that I can do. I'd go through and move every "only" (way) forward to its logical place, change every "may" to "might" or the like, if that is the sense ("may" means "is allowed to" in law AND in computer doc -- or at least it should (personal bias)). (end-rant) is THAT tag-soup, with no begin-rant? Sorry, had to make this reply pertinent somehow :-). David From owner-lynx-dev@sig.net Sun Nov 8 09:26:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA19266 for ; Sun, 8 Nov 1998 09:26:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA17487; Sun, 8 Nov 1998 08:11:29 -0600 (CST) Date: Sun, 8 Nov 1998 06:13:29 -0800 (PST) From: David Combs Message-Id: <199811081413.GAA18824@netcom2.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 6941 Lines: 155 I would LOVE to get involved in this discussion -- although I have somehow missed the initial posts. My favorite book on the subject is Fowler's "Modern English Usage" -- NOT the new version that came out last year, but any of the prior ones, which because of complaints from readers, the most recent of those prior editions are being sold alongside the newer one (much munged-over by some new guy). (I myself have not gone through this newest one, but what from I hear, "everyone" hates it). Every time you talk about an issue in this lynx.cfg, please also mention the subject heading IN that file, so I can FIND the text. Also, I just a few days downloaded a couple of lynxes: * -rw-r----- 1 dkc staff 1519943 Nov 3 10:37 lynx2-8-1.tar.gz * -rw-r----- 1 dkc staff 1764732 Nov 3 10:32 lynx2-8-1-rel2-intl.tar.gz Which one should I look in? Or do you already have one newer? > From owner-lynx-dev@sig.net Sat Nov 7 18:52:37 1998 > Date: Sat, 7 Nov 1998 18:51:47 -0800 (PST) > From: Doug Kaufman > > On Sat, 7 Nov 1998, Larry W. Virden wrote: > > > > > -# trailing white space will be trimmed, and a single space added by Lynx > > > > +# trailing white space will be trimmed, and a single space is added by Lynx > > > > ... > > > > I disagree that was correct originally. OK, a question about a question or point: should there ve a semicolon after the "I disagree", or an "it" after the "that". Makes all the difference. > > This is parallel structure, expanding to "trailing white space will be > trimmed, and a single space will be added by Lynx". Your change loses > the structure, with the first part in future tense, and the second part > present. How about "... will be removed, and replaced by [only] a single space". (If you are worried about words, "trimmed" applied to characters is a computer-related usage -- rather, a computer-PROGRAMMING-related usage. My own belief is to hell with the user, use the right word, but that's not very user-friendly. I would say therefore: We programmers who maintain this program talk back and forth to each other, with maybe 100 emails broadcast the whole group of hundreds of each day, and we use a standard set of computer (programming) terminology. Also, most people who read THIS file, lynx.cfg, are "administrators" at sites that provide Lynx to their users, and by definition they twoo are programmers. However, for those of you who are not familiar with the terminology, please look at the bottom of this file and see the glossary we have there. Within that glossary you have words like trim, prepend (there is no better word, which is why the word had to be coined (oops: for the non-English-speaking, invented), ... Thus, a directory is a directory, NOT (god dam# Sun trying to be user-UNfriendly) "folder") > > > > > > > -# their actual URL's. See the sample jumps files in the samples > > > > +# their actual URL's. See the jumps files in the lynx*/samples > > > > In this case, URL's should be URLs. Sorry - I started to make that change > > (as well as a pass thru fixing all the incorrect uses of it's) and got > > sidetracked by the kids needing to leave. I also disagree that saying > > sample jumps files in the samples directory is better than saying the > > jumps files in the lynx*/samples directory. > > The reason I liked the original was that it indicated specifically that > the file was a sample file (i.e. to be changed by the user) and was in > the samples subdirectory. I suspect that many users wouldn't understand > that "lynx*/samples" refers to "lynx2-8-1/samples". This requires at least > simple knowledge of regular expressions, which may be too much to ask. > > > > > > > ... > > > > -# Additional, alternate jumps files can be defined and mapped to > > > > +# Additional alternate jumps files can be defined and mapped to > > > > My college English book indicated the comma in this case was a coin toss... > > These are both acceptable, but mean different things. The first talks > about additional files which can be alternate jumps files. The latter > about more alternate jumps files (implying at least one alternate jumps > file already in existence). > How about "Alternate and/or alternate jumps-files may be defined"? (Yeah, I know the books hate and/or, but what else is there that says what you mean. The lawbooks talk at length (I can't spell "adnauseum" correctly) about "or", ie ior vs xor (or as the lawyers might say, ior v xor -- hey, that "V", doesn't look so bad, does it, pretty symbolic), or what a comma means -- judges make it mean whatever they want it to mean for the case to come out the way they want it to come out!) > > > > > > -# CHARACTER_SET defines the display character set, i.e., that assumed to be > > > > +# CHARACTER_SET defines the display character set, i.e., assumed to be > > > > I can't fathom how that "that" can be correct. I cannot see the rest of it, only what's here in the email, but maybe remove the i.e. (I myself use ie, no periods, but everyone screams at that, and I know they're right and I'm wrong) can be removed and changed to "... set (assumed to be EBCDIC)". :-) > > This is actually quite correct. There is an implied antecedent, > "character set", so this expands to "that character set assumed to be" > > > > I think that this might be better as "It must be specified relative to > > > the user's home directory" > > > > That's how I started to write it - but I had just worked thru the META CHARSET > > section and thought using the words prepended might be a bit easy for the > > novice reader to figure out than the idea of relative pathnames. Either > > way works fine for me. > > My thought was that the word "prepend" is an unusual term that would > send many users to the dictionary. Again, a glossary solves this one. Prepend is a perfectly good word when one is talking about parsing html or any other char-processing app. > > I think that this may be enough discussion of fine points of English > usage. The key is to make the document as clear and unambiguous as > possible to the novice user, while keeping the technical information > needed by those more experienced. It doesn't have to be grammatically > correct as long as users can understand what we mean. I disagree. It is far too much fun to talk about this, and it is actually useful. Further, in going through it, we will have to THINK a bit about what a given option ACTUALLY MEANS, which can't be a bad thing every few years. If others don't want this stuff coming to you, maybe we could create a semi-private mailing list, maybe even just a local list of names we send to, Something in .mailrc (local) that we can fire off to, that gets to all interested. > Doug > > __ > Doug Kaufman > Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu > > From owner-lynx-dev@sig.net Sun Nov 8 14:02:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA27149 for ; Sun, 8 Nov 1998 14:01:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA10358; Sun, 8 Nov 1998 11:46:08 -0600 (CST) From: dickey@clark.net Message-Id: <199811081747.MAA25908@shell.clark.net> Subject: Re: lynx-dev some proposed nit fixes in lynx.cfg To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 12:47:53 -0500 (EST) In-Reply-To: <199811081413.GAA18824@netcom2.netcom.com> from "David Combs " at Nov 8, 98 06:13:29 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: 343 Lines: 11 > If others don't want this stuff coming to you, maybe we could create > a semi-private mailing list, maybe even just a local list of names we send > to, Something in .mailrc (local) that we can fire off to, that gets > to all interested. that would spoil the fun. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 8 19:31:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA16812 for ; Sun, 8 Nov 1998 19:31:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA25147; Sun, 8 Nov 1998 18:03:27 -0600 (CST) Date: Mon, 9 Nov 1998 09:05:10 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811090005.JAA12787@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev internationalization Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 765 Lines: 15 me: > >> #define LYNX_TRACELOG_TITLE gettext("Lynx Trace Log") > Tom: > > that's what I'm doing. [...] Leonid: > I wonder, why not to insert gettext() in every message in LYMessages.en.h > with the renaming file to LYMessages.h at the initial stage without global > expanding of messages back to the C source, it was more maintainable at least. Again, no expert here, but strings used once only would seem to me to be best handled by hard-coding the gettext() where it's used that one time, whereas those used many times, and likely to be used in future additions, would best be handled with a define in "LYMessages.h". It is easy to see which strings are used once, and which are used many times, and where they are used by examining the lynx.pot file. __Henry From owner-lynx-dev@sig.net Sun Nov 8 20:47:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA04190 for ; Sun, 8 Nov 1998 20:47:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA06090; Sun, 8 Nov 1998 19:27:24 -0600 (CST) Date: Mon, 9 Nov 1998 09:21:20 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811090021.JAA12905@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev internationalization Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1144 Lines: 28 > again - that's what I'm doing. but there's a lot of strings that > aren't #define'd in LYMessages_en.h -- JES's version finds many of > them, and I'm adding a few, both to LYMessages_en.h and to the inline > stuff (if I stop to #define every string I see, it'll take a week). I see no problem with taking a week or a month. Don't want to have to keep coming back to it. > Once done, it'll be simple to grep the result for 'gettext' and think > about how best to proceed. Rather than grep, it might be better to use the tools that the translators will be using. I'd recommend making your own lynx.pot file because it will give you information that grep wouldn't. Once you have the gettext package installed, it's pretty straight forward. I'm sure you can do it with more savvy, but simply something like: % ls ./WWW/Library/Implementation/*.[ch] ./src/*.[ch] > z-ls xgettext -f % z-ls -o lynx.pot`date '+%m%d'` will make a fresh *.pot file, tell you where there are errors, and tell you where each string is used. You might want the *.pot file around for debugging, in addition to seeing how the thing works. Just thoughts. __Henry From owner-lynx-dev@sig.net Sun Nov 8 21:52:17 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.66]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA03109 for ; Sun, 8 Nov 1998 21:52:16 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA16284 for ; Sun, 8 Nov 1998 21:49:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA09938; Sun, 8 Nov 1998 19:55:31 -0600 (CST) Message-Id: <199811082350.SAA00203@core.dumped.org> Subject: lynx-dev Persistent Cookies Question To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 18:50:53 -0500 (EST) From: Jonathan Bobin 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: 474 Lines: 13 I was just trying out the new feature of Lynx 2.8.1 and I tried to link ~/.lynx_cookies to ~/.netscape/cookies and see if I could just share the cookie files. However, since Netscape uses comments on the first three lines, Lynx gets confused and thinks those are actual cookies (removing the lines doesn't do anything since Netscape always puts the comments back in). Are there any plans to have Lynx interpret hash marks as comments instead of cookies? Thanks, Jonathan From owner-lynx-dev@sig.net Sun Nov 8 22:01:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA03868 for ; Sun, 8 Nov 1998 22:01:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA03479; Sun, 8 Nov 1998 20:25:53 -0600 (CST) Message-ID: <19981108182748.A32529@psnw.com> Date: Sun, 8 Nov 1998 18:27:48 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: lynx-dev patch for cookies with null value Mail-Followup-To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 6:25pm up 2 days, 11:08, 6 users, load average: 1.39, 1.26, 1.24 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2539 Lines: 65 It looks like this patch fixes the problem that Larry was having with http://www.onelist.com/ in the middle of last month. I'm not sure exactly why Fote wanted to ignore cookies with an empty value, but it looks like if we accept them things work properly. This is against 2.8.2dev.1, should probably work just fine against 2.8.1rel.?... Larry, could you give this a try? diff -cr lynx2-8-1/src/LYCookie.c lynx2.8.2.dev.1.bri/src/LYCookie.c *** lynx2-8-1/src/LYCookie.c Fri Nov 6 06:29:41 1998 --- lynx2.8.2.dev.1.bri/src/LYCookie.c Sun Nov 8 18:21:25 1998 *************** *** 1156,1162 **** * new, unknown attribute which doesn't take a value, and * ignore it. - FM */ ! if (!known_attr && value_end > value_start) { /* * If we've started a cookie, and it's not too big, * save it in the CombinedCookies list. - FM --- 1156,1169 ---- * new, unknown attribute which doesn't take a value, and * ignore it. - FM */ ! /* if (!known_attr && value_end > value_start) { */ ! ! /* Is there any reason we don't want to accept cookies with ! * no value? This seems to be needed for sites that reset a ! * cookie by nulling out the value. If this causes problems, ! * we can go back to the original behavior above. - BJP ! */ ! if (!known_attr) { /* * If we've started a cookie, and it's not too big, * save it in the CombinedCookies list. - FM *************** *** 1622,1628 **** * new, unknown attribute which doesn't take a value, and * ignore it. - FM */ ! if (!known_attr && value_end > value_start) { /* * If we've started a cookie, and it's not too big, * save it in the CombinedCookies list. - FM --- 1629,1642 ---- * new, unknown attribute which doesn't take a value, and * ignore it. - FM */ ! /* if (!known_attr && value_end > value_start) { */ ! ! /* Is there any reason we don't want to accept cookies with ! * no value? This seems to be needed for sites that reset a ! * cookie by nulling out the value. If this causes problems, ! * we can go back to the original behavior above. - BJP ! */ ! if (!known_attr) { /* * If we've started a cookie, and it's not too big, * save it in the CombinedCookies list. - FM -- Whenever people agree with me I always feel I must be wrong. -- Oscar Wilde From owner-lynx-dev@sig.net Sun Nov 8 22:26:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA06066 for ; Sun, 8 Nov 1998 22:26:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA09899; Sun, 8 Nov 1998 21:10:23 -0600 (CST) Message-ID: <19981108191221.A875@psnw.com> Date: Sun, 8 Nov 1998 19:12:21 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev Persistent Cookies Question Mail-Followup-To: lynx-dev@sig.net References: <199811082350.SAA00203@core.dumped.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811082350.SAA00203@core.dumped.org>; from "Jonathan Bobin" on Sun, Nov 08, 1998 at 06:50:53PM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 7:09pm up 2 days, 11:53, 5 users, load average: 1.01, 1.17, 1.22 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1370 Lines: 44 Jonathan Bobin wrote: > I was just trying out the new feature of Lynx 2.8.1 and I tried to > link ~/.lynx_cookies to ~/.netscape/cookies and see if I could just share > the cookie files. > > However, since Netscape uses comments on the first three lines, Lynx gets > confused and thinks those are actual cookies (removing the lines doesn't > do anything since Netscape always puts the comments back in). > > Are there any plans to have Lynx interpret hash marks as comments instead > of cookies? This patch will take care of it. It only checks for hashes at the beginning of a line, but I can't see them popping up anywhere else unless they should be there. Maybe this should go into 2.8.1 bugfixes? Definitely into 2.8.2. diff -cr lynx2-8-1/src/LYCookie.c lynx2.8.2dev.1.bri/src/LYCookie.c *** lynx2-8-1/src/LYCookie.c Fri Nov 6 06:29:41 1998 --- lynx2.8.2dev.1.bri/src/LYCookie.c Sun Nov 8 19:06:18 1998 *************** *** 1909,1915 **** j = fgets(buf, sizeof(buf)-1, cookie_handle); ! if((j == NULL) || (buf[0] == '\0' || buf[0] == '\n')) { continue; } --- 1909,1915 ---- j = fgets(buf, sizeof(buf)-1, cookie_handle); ! if((j == NULL) || (buf[0] == '\0' || buf[0] == '\n' || buf[0] == '#')) { continue; } -- Your sister swims out to meet troop ships. Fine day to throw a party. Throw him as far as you can. From owner-lynx-dev@sig.net Sun Nov 8 22:41:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA07600 for ; Sun, 8 Nov 1998 22:41:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA08289; Sun, 8 Nov 1998 20:59:33 -0600 (CST) Message-ID: <19981108190129.A665@psnw.com> Date: Sun, 8 Nov 1998 19:01:29 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: lynx-dev Re: patch for cookies with null value Mail-Followup-To: lynx-dev@sig.net References: <19981108182748.A32529@psnw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981108182748.A32529@psnw.com>; from "brian j. pardy" on Sun, Nov 08, 1998 at 06:27:49PM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 7:00pm up 2 days, 11:43, 6 users, load average: 1.26, 1.33, 1.26 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1239 Lines: 35 brian j. pardy wrote: > It looks like this patch fixes the problem that Larry was having with > http://www.onelist.com/ in the middle of last month. I'm not sure exactly > why Fote wanted to ignore cookies with an empty value, but it looks like > if we accept them things work properly. Looks like we'll also need this patch. Without it, Lynx will save cookies with emptied out values, causing weird behavior if they are written to disk and re-read. diff -cr lynx2-8-1/src/LYCookie.c lynx2.8.2.dev.1.bri/src/LYCookie.c *** lynx2-8-1/src/LYCookie.c Fri Nov 6 06:29:41 1998 --- lynx2.8.2.dev.1.bri/src/LYCookie.c Sun Nov 8 18:59:48 1998 *************** *** 495,500 **** --- 495,508 ---- co = NULL; /* + * Don't add the cookie if the value is NULL. - BJP + */ + } else if (co->value[0] == '\0') { + CTRACE(tfp, "store_cookie: Value is NULL! Not storing cookie.\n"); + freeCookie(co); + co = NULL; + + /* * If it's a replacement for a cookie that had not expired, * and never allow has not been set, add it again without * confirmation. - FM -- Change is the essential process of all existence. -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2 From owner-lynx-dev@sig.net Sun Nov 8 22:47:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA07713 for ; Sun, 8 Nov 1998 22:47:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12196; Sun, 8 Nov 1998 21:26:40 -0600 (CST) From: dickey@clark.net Message-Id: <199811090328.WAA26978@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 22:28:18 -0500 (EST) In-Reply-To: <199811090005.JAA12787@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 9, 98 09:05:10 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: 1358 Lines: 31 > > me: > >> #define LYNX_TRACELOG_TITLE gettext("Lynx Trace Log") > > > Tom: > > that's what I'm doing. > [...] > Leonid: > I wonder, why not to insert gettext() in every message in LYMessages.en.h > > with the renaming file to LYMessages.h at the initial stage without global > > expanding of messages back to the C source, it was more maintainable at least. > > Again, no expert here, but strings used once only would seem to me to be > best handled by hard-coding the gettext() where it's used that one time, > whereas those used many times, and likely to be used in future additions, > would best be handled with a define in "LYMessages.h". It is easy to see > which strings are used once, and which are used many times, and where they > are used by examining the lynx.pot file. partly - but there's a lot of trash that has to be filtered out where we have strings embedded in HTML. (I'd rather not embed HTML in the gettext strings since that leads to interesting problems maintaining the program). there's a good reason to retain the #define's (I believe LP noticed it too). If you don't, and one of the hardcoded strings is a little different, some places in the code won't work anymore because we do comparisons on the titles and form values. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 8 22:49:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA07972 for ; Sun, 8 Nov 1998 22:49:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12531; Sun, 8 Nov 1998 21:29:07 -0600 (CST) From: dickey@clark.net Message-Id: <199811090330.WAA27771@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 22:30:59 -0500 (EST) In-Reply-To: <199811090021.JAA12905@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 9, 98 09:21:20 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: 803 Lines: 23 > Once you have the gettext package installed, it's pretty straight > forward. I'm sure you can do it with more savvy, but simply something > like: > > % ls ./WWW/Library/Implementation/*.[ch] ./src/*.[ch] > z-ls xgettext -f > % z-ls -o lynx.pot`date '+%m%d'` > > will make a fresh *.pot file, tell you where there are errors, and tell > you where each string is used. You might want the *.pot file around for > debugging, in addition to seeing how the thing works. I already found that (thanks). I've got a patch ready for a test-build on sol, and if that plays, will checkin a dev.2 (most of Monday's already reserved for another project, so I'd like to get this moving along). > Just thoughts. > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 9 03:00:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA30623 for ; Mon, 9 Nov 1998 03:00:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA11248; Mon, 9 Nov 1998 01:45:04 -0600 (CST) From: David Woolley Message-Id: <199811081357.NAA16717@djwhome.demon.co.uk> Subject: Re: lynx-dev programming forms in lynx To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 13:57:52 +0000 (GMT) In-Reply-To: from "Eduardo Chappa L." at Nov 7, 98 11:19:59 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: 1943 Lines: 36 > > I have a problem/question/suggestion. I would like to have a document in > my own directory (unix user) that behaves like a form, but without a cgi > program to interpret it (because something like that does not exist in my > server). I would like the cgi interpretation to be made by lynx, that is Have you investigated lynxcgi: I haven't used it myself, but as I understand it, it causes lynx to invoke a script on your machine according to the CGI protocol. I'm not sure what security mechanisms there are to prevent abuse by a remote page. > to say I want to have a menu in a local html file (say my bookmarks file), > group them in options menu, select one of them and lynx do the work of the > cgi program that takes me to the link I choose. I am thinking of something > like the options menu forms, but in that case there's no html file. Am I > clear enough ? I'm afraid I'm confused. However, the use of CGI for basically cosmetic purposes should be avoided on the real web, as it tends to increase traffic, in particular, by creating non-cacheable URLs. The way that most GUI browsers would approach this these days is to use Javascript, but adding Javascript to Lynx is non-trivial and could never support many of the graphical Javascript uses on the real web. Also, there have been two different attacks on IE4 published recently that allow a remote site to read a local file as a result of holes in the Javascript implementation, so personally, I reject offers of Javascript when running GUI browsers. It's non-trivial because JS is large and because it assumes the Netscape object model (IE4 allows a more relaxed model but, mostly, but not always, works for the Netscape model - layers, which would be almost impossible for Lynx, are one exception). You should really ask yourself the same question that most web sites seem to fail to ask: what is the best way to work within the constraints of the medium? From owner-lynx-dev@sig.net Mon Nov 9 03:01:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA30633 for ; Mon, 9 Nov 1998 03:01:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA11200; Mon, 9 Nov 1998 01:44:26 -0600 (CST) From: David Woolley Message-Id: <199811081440.OAA16766@djwhome.demon.co.uk> Subject: Re: lynx-dev Misplaced?
      breaks anchor. To: lynx-dev@sig.net Date: Sun, 8 Nov 1998 14:40:06 +0000 (GMT) In-Reply-To: <199811071829.KAA08487@netcom17.netcom.com> from "David Combs" at Nov 7, 98 10:29: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: 413 Lines: 7 > WHY did fote call it "tag soup"? Maybe that is actually > a good name -- as long as its derivation is explained > somewhere. I always assumed that it was because all the HTML tags were thrown into the pot (document) stirred up and just came out in random orders. Generally the browsers for which such pages were written didn't actually parse the HTML but just acted on the side effects of tags in isolation. From owner-lynx-dev@sig.net Mon Nov 9 04:45:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA05481 for ; Mon, 9 Nov 1998 04:45:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA18784; Mon, 9 Nov 1998 03:27:22 -0600 (CST) From: Philip Webb Message-Id: <199811090928.EAA14827@chass.utoronto.ca> Subject: lynx-dev unanswered queries (7) To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 04:28:03 -0500 (EST) Cc: jaydeep_desai@hotmail.com In-Reply-To: <19981013070820.29957.qmail@hotmail.com> from "jaydeep desai" at Oct 13, 98 00:08:20 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: 761 Lines: 15 981013 Jaydeep Desai wrote: > Is there any way to upload files from Lynx or Wget? I acess internet > by running personal copy of Lynx on a shell account through proxy server. > Ftp, telnet and rlogin gateways are blocked at proxy server. you can define an uploader in lynx.cfg ; presumably you can get help on wget via one of its sites, eg ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/ . you probably need to speak to your sysadmin re the blocked proxy. does anyone else have 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 Mon Nov 9 04:46:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA05492 for ; Mon, 9 Nov 1998 04:46:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA19031; Mon, 9 Nov 1998 03:30:35 -0600 (CST) From: Philip Webb Message-Id: <199811090931.EAA14850@chass.utoronto.ca> Subject: lynx-dev unanswered queries (8) To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 04:31:16 -0500 (EST) Cc: vimasol@esoterica.pt In-Reply-To: from "Vitor Oliveira" at Oct 16, 98 11:34: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: 603 Lines: 13 981016 Vitor Oliveira: > I'm using the pre9 version of lynx in dos > but I want to built a script file to work externally in ftp mode. > Can some one help me about this? none of the volunteers offered anything: probably you should describe in more detail what you want to do. you can now get 2-8-1 from 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 Mon Nov 9 04:53:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA06302 for ; Mon, 9 Nov 1998 04:53:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA19495; Mon, 9 Nov 1998 03:37:21 -0600 (CST) From: Philip Webb Message-Id: <199811090938.EAA14978@chass.utoronto.ca> Subject: lynx-dev unanswered queries (9) To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 04:38:01 -0500 (EST) Cc: markb@ordern.com In-Reply-To: <19981022154834Y.markb@ordern.com> from "Mark Burton" at Oct 22, 98 03:48: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: 2055 Lines: 54 981022 Mark Burton wrote: no-one volunteered an explanation for your rather technical question. you can now get 2-8-1 from www.slcc.edu/lynx/release/ , tho' i don't know of anything which would affect cacheing there. does anyone else have any suggestions? > I'm trying to use lynx 2.8 on a Linux system > that runs a squid proxy cache & most of the time > doesn't have a connection to the Internet & therefore can't resolve names. > If I specify an URL on the command line: lynx http://www.xemacs.org/ > I get a response like this from squid: > > While trying to retrieve the URL: /www.xemacs.org/ > > The following error was encountered: > * Invalid URL > > Some aspect of the requested URL is incorrect. Possible problems: > * Missing or incorrect access protocol (should be `http://'' etc) > * Missing hostname > * Illegal double-escape in the URL-Path > * Illegal character in hostname; underscores are not allowed > > I know the cache contains the page I want > because I can retrieve its headers like this: > > markb@tower: HEAD http://www.xemacs.org/ > 200 OK > Date: Tue, 20 Oct 1998 01:29:52 GMT > Accept-Ranges: bytes > Age: 184620 > Server: Apache/1.3.1 (Unix) PHP/3.0.3 > Content-Length: 4611 > Content-Type: text/html > ETag: "1a824-1203-36136dc9" > Last-Modified: Thu, 01 Oct 1998 11:55:53 GMT > Client-Date: Thu, 22 Oct 1998 14:39:14 GMT > Client-Peer: 192.168.1.1:3128 > Proxy-Connection: close > X-Cache: HIT from tower.ordern.com > > Does this mean lynx can only retrieve pages from hosts > whose addresses it can resolve? > why has it removed the http:/ from the start of the URL? > If anyone can help, please mail me directly as I don't subscribe. > (I already receive far too much email) so does lynx-dev sometimes ... -- ========================,,============================================ 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 Nov 9 05:29:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA10830 for ; Mon, 9 Nov 1998 05:29:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA21818; Mon, 9 Nov 1998 04:07:25 -0600 (CST) Date: Mon, 9 Nov 1998 05:07:55 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811090507.AA14730@cas.org> Subject: Re: lynx-dev patch for cookies with null value In-Reply-To: <19981108182748.A32529@psnw.com> of Sun, 8 Nov 1998 18:27:48 -0800 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: 8 I am midway to moving my local config to the latest lynx. Once I build that successfully I will apply the test and try it out - thanks! Now if only I could figure out that ncurses bug I was seeing. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 9 07:49:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA32074 for ; Mon, 9 Nov 1998 07:49:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA02969; Mon, 9 Nov 1998 06:29:35 -0600 (CST) To: lynx-dev@sig.net References: <199811090328.WAA26978@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Mon, 9 Nov 1998 15:11:18 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev internationalization 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: 9 > there's a good reason to retain the #define's (I believe LP noticed it too). > If you don't, and one of the hardcoded strings is a little different, some > places in the code won't work anymore because we do comparisons on the > titles and form values. Also, there is a good reason for changing the comparison on titles (for internal pages) in favour of URL comparison (lynx://...) as was proposed by BL, it is a separate subject though. From owner-lynx-dev@sig.net Mon Nov 9 07:53:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA00380 for ; Mon, 9 Nov 1998 07:53:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA02960; Mon, 9 Nov 1998 06:29:32 -0600 (CST) To: lynx-dev@sig.net References: <199811090330.WAA27771@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Mon, 9 Nov 1998 15:14:26 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev internationalization 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: 215 Lines: 8 > I already found that (thanks). I've got a patch ready for a test-build > on sol, and if that plays, will checkin a dev.2 (most of Monday's already in userdefs.h, change RELEASE TRUE > -- > Thomas E. Dickey From owner-lynx-dev@sig.net Mon Nov 9 08:42:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA05549 for ; Mon, 9 Nov 1998 08:42:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA09752; Mon, 9 Nov 1998 07:26:31 -0600 (CST) From: Klaus Peter Wegge Message-Id: <199811091325.OAA19193@narvi.c-lab.de> Subject: lynx-dev ISP AOL for lynx? To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 14:25:16 +0100 (MET) In-Reply-To: <19981020164804.A18901@mail.bcpl.net> from "Webmaster Jim" at Oct 20, 98 04:48:04 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: 697 Lines: 23 I learned from the message below, how to use AOL as ISP for lynx with win95. Did someone one the list try to use AOL as ISP for linux or lynx386? Any hints are very welcome. Thanks Klaus-Peter > On Tue, Oct 20, 1998 at 03:23:47AM -0400, LMW888BJY@aol.com wrote: > > Hi, to whom it may concern. > > > > I downloaded and installed Lynx 2.8.1pre.9 to my computer running windows 95 > > osr2. My service provider is AOL, running version 4.0. > > > > Will Lynx work or not through America Online? > > Thanks, > > Louis M. Weinstein > > E-mail address: LMW888BJY@aol.com > > It should. Once you have a connection, any WinSock program should work > okay, including Lynx, TeraTerm and WS_FTP. ... From owner-lynx-dev@sig.net Mon Nov 9 08:56:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA07990 for ; Mon, 9 Nov 1998 08:56:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA11644; Mon, 9 Nov 1998 07:38:55 -0600 (CST) From: dickey@clark.net Message-Id: <199811091340.IAA04419@shell.clark.net> Subject: Re: lynx-dev internationalization To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 08:40:55 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 9, 98 03:14:26 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: 304 Lines: 12 > > > I already found that (thanks). I've got a patch ready for a test-build > > on sol, and if that plays, will checkin a dev.2 (most of Monday's already > > in userdefs.h, change RELEASE TRUE thanks - I'd forgotten that. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 9 11:14:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA03409 for ; Mon, 9 Nov 1998 11:14:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA17271; Mon, 9 Nov 1998 09:53:47 -0600 (CST) Date: Mon, 9 Nov 1998 07:55:44 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev unanswered queries (8) In-Reply-To: <199811090931.EAA14850@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: 443 Lines: 15 On Mon, 9 Nov 1998, Philip Webb wrote: > 981016 Vitor Oliveira: > > I'm using the pre9 version of lynx in dos > > but I want to built a script file to work externally in ftp mode. > > Can some one help me about this? > > none of the volunteers offered anything: I handled this in private mail. The problem is fixed. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Mon Nov 9 11:34:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA06305 for ; Mon, 9 Nov 1998 11:34:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA23614; Mon, 9 Nov 1998 10:13:04 -0600 (CST) Message-Id: <4.1.19981109110855.00e6eb00@pop.ma.ultranet.com> X-Sender: gregmm@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 09 Nov 1998 11:12:37 -0500 To: lynx-dev@sig.net From: Greg Marr Subject: Re: lynx-dev Misplaced?
      breaks anchor. In-Reply-To: <199811071916.OAA16455@shell.clark.net> References: <199811071829.KAA08487@netcom17.netcom.com> 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: 876 Lines: 21 >> WHY did fote call it "tag soup"? Maybe that is actually >> a good name -- as long as its derivation is explained >> somewhere. >I suppose it's in the archive - but my understanding is that Klaus and Fote >disagreed on how to handle error recovery when tags are improperly nested. > >Klaus wanted to reject things that weren't properly nested, and Fote >made some allowances (i.e., the tags didn't have to follow the standard >structure), so someone dubbed it tag-soup. The term tag-soup I believe originated as a description of how the "major" browsers handled HTML. IIRC, it originated elsewhere long before it came to apply to a parsing mode in lynx. (At least I saw it used in several of the ciw newsgroups long before I saw it on lynx-dev.) -- 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 Mon Nov 9 13:32:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA29507 for ; Mon, 9 Nov 1998 13:32:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA29783; Mon, 9 Nov 1998 12:10:20 -0600 (CST) Date: Mon, 9 Nov 1998 10:12:21 -0800 (PST) From: David Combs Message-Id: <199811091812.KAA19383@netcom6.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: ficticious "EXITING Lynx" msg Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 716 Lines: 24 I can't reproduce it, but I just got this: - - - - - - - - - - - - - - - - HTTSEARCH REVIEWS BY: Ple[18]title of bookystem administrator to confirm a bug, and if [19]author to notify the lynx-dev list. Bug reports should hav[20]publishercriptions of the command and/or URL which causes the[21]reviewere operating system name with version number, the TCPIP implementation, and any other relevant information. - - - - - - - - - - - - - - - - www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) Lynx now exiting with signal: 4 Stopped (signal) {netcom6:278} {netcom6:278} after which I could indeed "fg" back into it, and it worked fine. (I had to answer the question) From owner-lynx-dev@sig.net Mon Nov 9 13:58:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA00538 for ; Mon, 9 Nov 1998 13:58:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA05679; Mon, 9 Nov 1998 12:31:03 -0600 (CST) From: juan_gutmann@libertyart.com.ar Message-Id: Date: Mon, 9 Nov 1998 13:30:08 +0000 To: lynx-dev@sig.net Subject: lynx-dev Trouble With Proxy-Server MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /310000000/310102155/310104315/310380251/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.flora.ottawa.on.ca id NAA00538 Status: RO Content-Length: 1578 Lines: 45 Hi!!! I'm a Lynx Fanatic. I use it a lot at Home, under Linux and Windows 98 with great results. I like it a lot, it's my number 1 choice when I browse the Web, I prefer it even over a GUI-Browser Like Netscape or MSIE. At the office, I want to use the Number 1 browser in the world, too!!! But I have the following problem: The Web connection at the office is thru a proxy-server. So, I edited lynx.cfg, added the proxy server address to the corresponding protocols. (I%m under Windows95 there, using the Lynx 2.8.1 Win32 binaries I got from lynx.browser.org). Then i call lynx.exe with the -pauth switch, but it doesn%t work. I suppose the problem is, my username at the Proxy Server has the form "lastname-firstname", so i call lynx this way: lynx.exe -pauth=lastname-firstname:mypassword , and it doesn't work, i guess because the username has an "-" in it, and so lynx assumes "-firstname" is a switch, like "-pauth" and so the complete username is not received. I get the following message from LYNX when I execute it: Alert: Invalid Header 'Proxy-Authenticate: NTLM' and then: Show the 407 message body? (y/n) If i answer yes, I obviously get an HTTP 407 error. I'm very disappointed, because i really want to use Lynx at the office. I can%t change the username to avoid the "-" , I already talked to the Proxy Server administrator, and he won't change my username to anything withouth the "-", because that's the standard for every user in the company. Any suggestions?? Thanks a lot!!! Yours Sincerely, Juan Gutmann Buenos Aires, Argentina From owner-lynx-dev@sig.net Mon Nov 9 14:19:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA05562 for ; Mon, 9 Nov 1998 14:19:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA05611; Mon, 9 Nov 1998 12:30:48 -0600 (CST) Date: Mon, 9 Nov 1998 10:08:25 -0800 (PST) From: David Combs Message-Id: <199811091808.KAA19118@netcom6.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: allow C-G or C-c in this: Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 186 Lines: 7 - - - - - - - - - - - - - - - - www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) We need a way to cancel this question, via C-c or something. David From owner-lynx-dev@sig.net Mon Nov 9 15:00:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA10293 for ; Mon, 9 Nov 1998 15:00:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA23022; Mon, 9 Nov 1998 13:32:28 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811091930.MAA26168@sanitas> Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 12:30:34 -0700 (MST) In-Reply-To: <199811091808.KAA19118@netcom6.netcom.com> from "David Combs" at Nov 9, 98 10:08: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: 266 Lines: 10 In a recent note, David Combs said: > Date: Mon, 9 Nov 1998 10:08:25 -0800 (PST) > > www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) > > We need a way to cancel this question, via C-c or something. > Why not just type "N"? -- gil From owner-lynx-dev@sig.net Mon Nov 9 15:02:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA10810 for ; Mon, 9 Nov 1998 15:02:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA24271; Mon, 9 Nov 1998 13:37:04 -0600 (CST) Date: Mon, 9 Nov 1998 14:39:04 -0500 (EST) From: Steven Rowe To: lynx-dev@sig.net Subject: lynx-dev [INLINE] 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: 251 Lines: 7 Hello everyone, thanks for allowing me on the list! I believe I'm running version 2.7(something) and would like to eliminate the [INLINE] from the pages I view. Is there a way to do this? As you can tell, I'm a newbie. Thanks kindly, Steven Rowe From owner-lynx-dev@sig.net Mon Nov 9 15:48:26 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.66]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA13898 for ; Mon, 9 Nov 1998 15:48:25 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA19341 for ; Mon, 9 Nov 1998 15:52:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA03595; Mon, 9 Nov 1998 14:08:57 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811092010.NAA26271@sanitas> Subject: Re: lynx-dev [INLINE] To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 13:10:25 -0700 (MST) In-Reply-To: from "Steven Rowe" at Nov 9, 98 02:39: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: 257 Lines: 9 In a recent note, Steven Rowe said: > Date: Mon, 9 Nov 1998 14:39:04 -0500 (EST) > > version 2.7(something) and would like to eliminate the [INLINE] from the > The "*" keystroke will display thesa as links you can follow, if you like that better. -- gil From owner-lynx-dev@sig.net Mon Nov 9 16:07:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA16075 for ; Mon, 9 Nov 1998 16:07:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA10479; Mon, 9 Nov 1998 14:32:15 -0600 (CST) From: Bela Lubkin Date: Mon, 9 Nov 1998 12:37:41 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev unanswered queries (8) Message-ID: <9811091237.aa13828@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 474 Lines: 11 Philip Webb wrote: > none of the volunteers offered anything: > probably you should describe in more detail what you want to do. > you can now get 2-8-1 from www.slcc.edu/lynx/release/ . It's good of you to provide this service of dredging up unanswered queries. But please don't delete the original subject lines. Instead of the serial number you've been using, please leave the subject intact as part of the new one, e.g. "unanswered query (FTP script file)". >Bela< From owner-lynx-dev@sig.net Mon Nov 9 19:16:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA04787 for ; Mon, 9 Nov 1998 19:16:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA02530; Mon, 9 Nov 1998 17:26:25 -0600 (CST) From: Philip Webb Message-Id: <199811092326.SAA05115@chass.utoronto.ca> Subject: Re: lynx-dev unanswered queries (8) To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 18:26:43 -0500 (EST) In-Reply-To: from "Doug Kaufman" at Nov 9, 98 07:55: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: 576 Lines: 12 981109 Doug Kaufman wrote re an unanswered query: > I handled this in private mail. The problem is fixed. i'm very pleased he got some help, but could you remember to copy your responses to lynx-dev, so they won't appear unanswered & more important, so the helpful response will be in the Archive (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 Nov 9 19:19:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA04871 for ; Mon, 9 Nov 1998 19:19:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01484; Mon, 9 Nov 1998 17:21:49 -0600 (CST) From: Philip Webb Message-Id: <199811092322.SAA04573@chass.utoronto.ca> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 18:22:30 -0500 (EST) Cc: juan_gutmann@libertyart.com.ar In-Reply-To: from "juan_gutmann@libertyart.com.ar" at Nov 9, 98 01:30: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: 1375 Lines: 25 981109 Juan Gutmann wrote: > I'm a Lynx Fanatic. I use it a lot at Home, under Linux and Windows 98 > At the office, I have the following problem: > The Web connection is thru a proxy-server. So, I edited lynx.cfg, > added the proxy server address to the corresponding protocols. > I'm under Windows95 there, using the Lynx 2.8.1 Win32 binaries from l.b.o. > my username at the Proxy Server has the form "lastname-firstname", > so i call lynx this way: lynx.exe -pauth=lastname-firstname:mypassword , > and it doesn't work, because the username has an "-" in it, > lynx assumes "-firstname" is a switch & the complete username isn't received. > I can't change the username: the administrator won't change my username > to anything withouth "-", because that's the standard in the company. someone else may have more technical suggestions, but there might be a way of escaping the - : have a look in Al Gilman's FAQs in the Main Help Page; or could you perhaps try -pauth=`lastname-firstname' . also, to lynx-dev more generally: shouldn't Lynx look for - to start a new switch, a/a 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 Mon Nov 9 20:26:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA14709 for ; Mon, 9 Nov 1998 20:26:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA23125; Mon, 9 Nov 1998 19:06:28 -0600 (CST) Date: Mon, 9 Nov 1998 17:08:36 -0800 (PST) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: Re: lynx-dev [INLINE] In-Reply-To: <199811092010.NAA26271@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: 426 Lines: 16 On Mon, 9 Nov 1998 pg@sweng.stortek.com wrote: :)In a recent note, Steven Rowe said: :) :)> Date: Mon, 9 Nov 1998 14:39:04 -0500 (EST) :)> :)> version 2.7(something) and would like to eliminate the [INLINE] from the :)> :)The "*" keystroke will display thesa as links you can follow, if you like :)that better. I think he meant to ask for "[" instead of "*" Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Mon Nov 9 23:11:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA10314 for ; Mon, 9 Nov 1998 23:11:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA21647; Mon, 9 Nov 1998 21:44:10 -0600 (CST) Message-ID: <19981109191123.39424@unicorn.it.wsu.edu> Date: Mon, 9 Nov 1998 19:11:23 -0800 From: Michael Warner To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: Mail-Followup-To: lynx-dev@sig.net References: <199811091808.KAA19118@netcom6.netcom.com> <199811091930.MAA26168@sanitas> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.12 In-Reply-To: <199811091930.MAA26168@sanitas>; from pg@sweng.stortek.com on Mon, Nov 09, 1998 at 12:30:34PM -0700 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 405 Lines: 15 On Mon, Nov 09, 1998, pg@sweng.stortek.com wrote: > In a recent note, David Combs said: > > > www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) > > > > We need a way to cancel this question, via C-c or something. > > > Why not just type "N"? "^G" works for me, too, but I assume it does the equivalent of "N". -- Michael Warner From owner-lynx-dev@sig.net Mon Nov 9 23:11:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA10320 for ; Mon, 9 Nov 1998 23:11:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA22919; Mon, 9 Nov 1998 21:51:57 -0600 (CST) Message-ID: <3647906F.1AB7CE0F@oracleworld.com> Date: Mon, 09 Nov 1998 17:01:35 -0800 From: james_spath X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev Re: International version up to 2.8.1rel.2 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: 1022 Lines: 29 > ------------------------------------------------------------------------ > [Prev][Next][Index][Thread] > > To: lynx-dev@sig.net > * Subject: Re: lynx-dev Re: International version up to 2.8.1rel.2 > * From: Nelson Henry Eric > * Date: Sat, 7 Nov 1998 09:13:37 +0900 (JST) > * Reply-To: lynx-dev@sig.net > * Sender: owner-lynx-dev@sig.net > ------------------------------------------------------------------------ > > P.S. I'm unsubscribing to lynx-dev for a while. Will be reading > Sad to hear that! Any ideas when you'll be able to come back? > I'm in SF at Oracle Open World this week, and then Texas next week for an SAP conference. Rather than have 3000 emails when I get back, I'm "not here". Looks like I stirred up a bit of fun, though. > > ------------------------------------------------------------------------ > Lynx mailing list archives > > [FLORA HOME] [LYNX Home] ----- The dis-embodied Marvin the Paranoid Android: Oh the pain of it all. From owner-lynx-dev@sig.net Mon Nov 9 23:13:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA10569 for ; Mon, 9 Nov 1998 23:13:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23133; Mon, 9 Nov 1998 21:53:14 -0600 (CST) Date: Mon, 9 Nov 1998 11:41:08 -0800 (PST) From: Pam Davis To: lynx-dev@sig.net Subject: lynx-dev having trouble 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: 270 Lines: 13 i use lynx via emrl.com and i'm getting lot's of garbage, ie misplaced text, and at one point was offfered a "cookie" which i declined. what's up? -pam davis ----- "Giving has great reward but no predictable results." -Hugh Prather pdavis@emrl.com dropout@emrl.com From owner-lynx-dev@sig.net Mon Nov 9 23:51:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA16152 for ; Mon, 9 Nov 1998 23:51:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA00305; Mon, 9 Nov 1998 22:36:07 -0600 (CST) From: Philip Webb Message-Id: <199811100436.XAA03020@chass.utoronto.ca> Subject: Re: lynx-dev having trouble To: lynx-dev@sig.net Date: Mon, 9 Nov 1998 23:36:47 -0500 (EST) Cc: pdavis@emrl.com In-Reply-To: from "Pam Davis" at Nov 9, 98 11:41: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: 1010 Lines: 21 981109 Pam Davis wrote: > i use lynx via emrl.com & i'm getting lot's of garbage, ie misplaced text, > and at one point was offfered a "cookie" which i declined. what's up? you'll have to tell us more about which version of Lynx -- enter = to find out: latest is 2-8-1 -- & whether it is an emrl.com service or you compile your own Lynx & they simply provide WWW access. lots of sites offer cookies: it's ok to decline them most of the time. your garbage problem could be caused by a bad phone line, mismatched communications protocols (eg with Kermit), badly written documents, etc: ^L rewrites the screen for you. > "Giving has great reward but no predictable results." -Hugh Prather that's what the lynx-dev volunteers find too ... -- ========================,,============================================ 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 Nov 10 00:47:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA21826 for ; Tue, 10 Nov 1998 00:47:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA08443; Mon, 9 Nov 1998 23:26:58 -0600 (CST) Message-ID: <19981110002248.34197@delta.Nexus.of.Obsolescence> Date: Tue, 10 Nov 1998 00:22:48 -0500 From: Chuck Martin To: lynx-dev@sig.net Subject: lynx-dev Why doesn't lynx cache HTML source? 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: 832 Lines: 15 Sometimes I want to view the HTML source of a document using the "\" key, and then switch back to the rendered document when I'm through, or I want to switch all images to links and back again, using the "*" key, or maybe I want to turn pseudo-ALTs on or off, but every time I make a switch in how I view a document, the whole document has to be downloaded again. Is there a reason why it was done this way? It seems to me that caching the HTML source instead of the rendered document would make more sense, and would save time when making these changes on the fly. Of course, moving between cached documents might be a little slower unless they were cached both ways (source and rendered), but not by much, and rendering a cached document would be much faster than downloading it repeatedly. Could someone enlighten me? Chuck From owner-lynx-dev@sig.net Tue Nov 10 02:39:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA02243 for ; Tue, 10 Nov 1998 02:39:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21077; Tue, 10 Nov 1998 01:20:08 -0600 (CST) Date: Mon, 9 Nov 1998 23:22:07 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: juan_gutmann@libertyart.com.ar Cc: lynx-dev@sig.net Subject: Re: lynx-dev Trouble With Proxy-Server 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: 605 Lines: 14 On Mon, 9 Nov 1998 juan_gutmann@libertyart.com.ar wrote: > "lastname-firstname", so i call lynx this way: > lynx.exe -pauth=lastname-firstname:mypassword , and it doesn't work, i guess > because the username has an "-" in it, and so lynx assumes "-firstname" is a > switch, like "-pauth" and so the complete username is not received. I haven't examined the source to be sure that this will work, but try: "-pauth=lastname%2Dfirstname:mypassword". Let the list know if it works. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Nov 10 02:51:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA04383 for ; Tue, 10 Nov 1998 02:51:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA22772; Tue, 10 Nov 1998 01:39:24 -0600 (CST) Date: Mon, 9 Nov 1998 23:41:24 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev unanswered queries (8) In-Reply-To: <199811092326.SAA05115@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: 19 On Mon, 9 Nov 1998, Philip Webb wrote: > 981109 Doug Kaufman wrote re an unanswered query: > > I handled this in private mail. The problem is fixed. > > i'm very pleased he got some help, > but could you remember to copy your responses to lynx-dev, > so they won't appear unanswered > & more important, so the helpful response will be in the Archive (smile). Good advice in general. The problem here was his computer misconfigured, rather than a lynx problem. MY initial advice was to see the script for doing external ftp in the lynx-for-DOS distribution on my web site, which shows one way to do this. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Nov 10 02:53:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA04395 for ; Tue, 10 Nov 1998 02:52:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA23127; Tue, 10 Nov 1998 01:43:38 -0600 (CST) From: Bela Lubkin Date: Mon, 9 Nov 1998 23:49:13 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Message-ID: <9811092349.aa21852@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2861 Lines: 58 Chuck Martin wrote: > Sometimes I want to view the HTML source of a document using the "\" > key, and then switch back to the rendered document when I'm through, > or I want to switch all images to links and back again, using the "*" > key, or maybe I want to turn pseudo-ALTs on or off, but every time I > make a switch in how I view a document, the whole document has to be > downloaded again. Is there a reason why it was done this way? It > seems to me that caching the HTML source instead of the rendered > document would make more sense, and would save time when making these > changes on the fly. Of course, moving between cached documents might > be a little slower unless they were cached both ways (source and > rendered), but not by much, and rendering a cached document would be > much faster than downloading it repeatedly. Could someone enlighten > me? This issue has been discussed extensively in the past; search the Lynx-Dev archives for the details. I used www.altavista.com's "advanced search" to search for "host:www.flora.org AND source AND cach* AND text:subject AND text:html", finding 59 matches. To summarize briefly: Lynx uses a single-pass recursive descent parser, consuming the HTML source and producing rendered output on the fly. Only that rendered output is cached. Since Lynx has many operations which require it to re-parse the HTML source, many users have suggested that Lynx cache the source as well. This usually leads to a discussion of pros and cons, some of which are: Con: - would add to the complexity of Lynx - caching rules are very difficult to get right - would add code, increasing the size of Lynx source and binary - would increase the in-core and/or on-disk storage consumed by Lynx during operation - duplicates functionality which is already provided by other programs, i.e. web caches such as Squid -- programs which are dedicated to caching functionality and thus can be expected to do it better than Lynx could hope to Pro: - would add to the utility of Lynx - greatly speed operations which require a re-parse, including '\' view-source, '^V' other-DTD, '*' image-URLs, '"' soft-dquotes, '`' and "'" comment-parsing, '[' pseudo-alts, '@' raw-mode, and changes in assumed document character set. - easier for a regular user to install than a full web proxy - persistence of cache can be better tuned to the user (e.g., cached objects can persist only for the duration of a session, thus not consume disk space while Lynx not running) Possile techniques have been discussed. But the bottom line is that Lynx is a cooperative volunteer effort, and big projects like a revamped caching system do not happen unless someone contributes the code. Please feel free to jump in and write it! ;-} >Bela< From owner-lynx-dev@sig.net Tue Nov 10 03:46:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA12762 for ; Tue, 10 Nov 1998 03:46:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA27265; Tue, 10 Nov 1998 02:33:53 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 00:39:31 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "John H. DuBois III" Subject: lynx-dev Lynx can't select /dev/null Cc: lynx-dev@sig.net Message-ID: <9811100039.aa26004@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2602 Lines: 79 > Just figured out why one of my cron jobs hasn't worked for a couple of months. > This works (on deepthought): > /local/bin/lynx-2.8.1dev.9 -dump http://www.armory.com < /dev/null > This does not, and gives a highly misleading error message, which, combined > with the fact that the site I actually want to access often *is* down, had > me running the job manually every day: > /local/bin/lynx -dump http://www.armory.com < /dev/null My fault... I did a bunch of work to make Lynx's DNS lookup truly interruptable, and little glitches are still coming in. I patched it as follows. >Bela< *** HTTCP.c.orig Sat Oct 24 09:49:07 1998 --- HTTCP.c Tue Nov 10 00:30:39 1998 *************** *** 454,459 **** --- 454,460 ---- struct timeval timeout; int dns_patience = 30; /* how many seconds will we wait for DNS? */ int child_exited = 0; + int ok_to_select_stdin = -1; /* ** Reap any children that have terminated since last time *************** *** 526,544 **** */ cycle++; - timeout.tv_sec = 1; - timeout.tv_usec = 0; FD_ZERO(&readfds); - FD_SET(pfd[0], &readfds); #ifndef USE_SLANG /* ** This allows us to abort immediately, not after 1-second ** timeout, when user hits abort key. Can't do this when ** using SLANG (or at least I don't know how), so SLANG ** users must live with up-to-1s timeout. -BL */ ! FD_SET(0, &readfds); /* stdin -BL */ #endif /* USE_SLANG */ /* ** Return when data received, interrupted, or failed. --- 527,558 ---- */ cycle++; FD_ZERO(&readfds); #ifndef USE_SLANG /* ** This allows us to abort immediately, not after 1-second ** timeout, when user hits abort key. Can't do this when ** using SLANG (or at least I don't know how), so SLANG ** users must live with up-to-1s timeout. -BL + ** + ** Whoops -- we need to make sure stdin is actually + ** selectable! /dev/null isn't, on some systems, which + ** makes some useful Lynx invocations fail. -BL */ ! if (ok_to_select_stdin == -1) { ! timeout.tv_sec = 0; ! timeout.tv_usec = 0; ! FD_SET(0, &readfds); /* stdin -BL */ ! selret = select(1, &readfds, NULL, NULL, &timeout); ! if (selret >= 0) ok_to_select_stdin = 1; ! else ok_to_select_stdin = 0; ! FD_ZERO(&readfds); ! } ! if (ok_to_select_stdin) FD_SET(0, &readfds); #endif /* USE_SLANG */ + timeout.tv_sec = 1; + timeout.tv_usec = 0; + FD_SET(pfd[0], &readfds); /* ** Return when data received, interrupted, or failed. From owner-lynx-dev@sig.net Tue Nov 10 03:51:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA13818 for ; Tue, 10 Nov 1998 03:51:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA27213; Tue, 10 Nov 1998 02:33:20 -0600 (CST) From: Philip Webb Message-Id: <199811100834.DAA10158@chass.utoronto.ca> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 03:34:02 -0500 (EST) In-Reply-To: <9811092349.aa21852@deepthought.armory.com> from "Bela Lubkin" at Nov 9, 98 11:49:13 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: 611 Lines: 11 thanks (to BL) for answering the user's FAQ. i kept the last discussion -- & will add your current summary -- with the intention of offering a review some time & proposals for what programming might be needed, so that lynx-dev efforts might get focussed on providing something useful. sorry it's still there, but i do get to things eventually. -- ========================,,============================================ 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 Nov 10 05:21:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA31127 for ; Tue, 10 Nov 1998 05:21:25 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA05373; Tue, 10 Nov 1998 04:07:51 -0600 (CST) From: dickey@clark.net Message-Id: <199811101009.FAA05556@shell.clark.net> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 05:09:53 -0500 (EST) In-Reply-To: <19981110002248.34197@delta.Nexus.of.Obsolescence> from "Chuck Martin " at Nov 10, 98 00:22: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: 1148 Lines: 25 > > Sometimes I want to view the HTML source of a document using the "\" > key, and then switch back to the rendered document when I'm through, > or I want to switch all images to links and back again, using the "*" > key, or maybe I want to turn pseudo-ALTs on or off, but every time I > make a switch in how I view a document, the whole document has to be > downloaded again. Is there a reason why it was done this way? It > seems to me that caching the HTML source instead of the rendered > document would make more sense, and would save time when making these > changes on the fly. Of course, moving between cached documents might > be a little slower unless they were cached both ways (source and > rendered), but not by much, and rendering a cached document would be > much faster than downloading it repeatedly. Could someone enlighten > me? we've talked about this, tentatively decided that local caching would be a Good Thing, but no one's worked through the details to implement it (there's always more things to do than there's time). > Chuck -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 06:07:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA06876 for ; Tue, 10 Nov 1998 06:07:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA09322; Tue, 10 Nov 1998 04:54:42 -0600 (CST) To: lynx-dev@sig.net References: <9811092349.aa21852@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Tue, 10 Nov 1998 13:37:27 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 801 Lines: 20 BL wrote: > Con: > - duplicates functionality which is already provided by other > programs, i.e. web caches such as Squid -- programs which are > dedicated to caching functionality and thus can be expected to do > it better than Lynx could hope to There is a special case I run into: certain documents or hosts set "no-cache" or "expire=...1970" directive and the document doesn't cached by squid. So for theese documents I see re-downloading over the working proxy when I press any key below. > Pro: > - greatly speed operations which require a re-parse, including '\' > view-source, '^V' other-DTD, '*' image-URLs, '"' soft-dquotes, '`' > and "'" comment-parsing, '[' pseudo-alts, '@' raw-mode, and > changes in assumed document character set. From owner-lynx-dev@sig.net Tue Nov 10 06:24:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA08978 for ; Tue, 10 Nov 1998 06:24:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA10367; Tue, 10 Nov 1998 05:06:38 -0600 (CST) X-Authentication-Warning: satellite.misc.org: collinf owned process doing -bs Date: Tue, 10 Nov 1998 03:07:38 -0800 (PST) From: Collin Forbes To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 804 Lines: 20 On Tue, 10 Nov 1998, Leonid Pauzner wrote: > BL wrote: > > Con: > > > - duplicates functionality which is already provided by other > > programs, i.e. web caches such as Squid -- programs which are > > dedicated to caching functionality and thus can be expected to do > > it better than Lynx could hope to > > There is a special case I run into: certain documents or hosts set > "no-cache" or "expire=...1970" directive and the document doesn't cached > by squid. So for theese documents I see re-downloading over the working proxy > when I press any key below. Lynx will also re-POST a form (asking first, of course) when all you want to do is inspect the source or look at an image. .signature

      Collin Forbes

      From owner-lynx-dev@sig.net Tue Nov 10 07:54:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA23139 for ; Tue, 10 Nov 1998 07:54:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA19057; Tue, 10 Nov 1998 06:41:23 -0600 (CST) Date: Tue, 10 Nov 1998 07:42:55 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811100742.AA23094@cas.org> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? In-Reply-To: of Tue, 10 Nov 1998 03:07:38 -0800 (PST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 677 Lines: 12 From: Collin Forbes > There is a special case I run into: certain documents or hosts set > "no-cache" or "expire=...1970" directive and the document doesn't cached > by squid. So for theese documents I see re-downloading over the working proxy > when I press any key below. And if lynx doesn't do the same then it would be a bad citizen of the net, and perhaps violating http protocol as well... -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 10 08:19:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA27200 for ; Tue, 10 Nov 1998 08:19:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA22106; Tue, 10 Nov 1998 07:06:22 -0600 (CST) Date: Tue, 10 Nov 1998 05:08:25 -0800 (PST) From: David Combs Message-Id: <199811101308.FAA20499@netcom11.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: sugg: auto-return from "p" page. Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1425 Lines: 36 You're going down a list of links to sequential html-files, eg chapter1, chapter2, ... chapter55. (You are not using trace, because you like the filename to say chapter4.html, rather than lnk000000000000000000023.dat or something. by the way, anyone written a perl program or something to "mv" those funny-named files to their original name (tail part of)?) Anyway, in vikeys it's j to go down one, p to get to p-page, return to choose to save the html, return to keep the suggested filename -- so far, very fast -- but NOW you have to wait til the p-page reformats or does something (seems to me, from watching screen), and THEN you have to do an "h" to get back to where those links are, ie you must EXPLICITLY return from the p-page. No big thing, hitting an "h", a real nitpick. But after 50 times (say), you wish you didn't have to. Now, if I do "p", get to the p-page, and then hit ^C, someone traps that, and does an auto-h FOR me. --- Problem: suppose someone wants to do TWO print ops to the SAME link. Well, there COULD be an option (at the bottom of the p-page's list) to "do NOT auto-return from THIS p-page", after which THAT p-page works like it does now -- stays there, until an explicit "h" (I talk in vikeys-language). All this assumes that 99.999% of the time, we all do ONE p-page command, and then return back to browsing... Comments on that assumption are clearly needed, from others. David From owner-lynx-dev@sig.net Tue Nov 10 10:50:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA19109 for ; Tue, 10 Nov 1998 10:50:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA28116; Tue, 10 Nov 1998 09:34:55 -0600 (CST) To: lynx-dev@sig.net References: <9811100742.AA23094@cas.org> Message-Id: From: "Leonid Pauzner" Date: Tue, 10 Nov 1998 18:33:10 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 1247 Lines: 30 >> There is a special case I run into: certain documents or hosts set >> "no-cache" or "expire=...1970" directive and the document doesn't cached >> by squid. So for theese documents I see re-downloading over the working proxy >> when I press any key below. > And if lynx doesn't do the same then it would be a bad citizen of the net, > and perhaps violating http protocol as well... > Larry W. Virden INET: lvirden@cas.org There are two different layers: HTTP rendering over the net and lynx internal HTML parsing mechanism - so the re-parsing for different config state (say, verbose images or not) should be done "off-line" (presently it's a lynx fault but nobody want to contribute the code). Breafly speaking, we discuss a "one document cache", for a single text/plain or text/html file(*) since we have no true frames nor true images. Another story for history stack - moving to previously visited document, not the current one - you may need to reload the document over the net in certain cases according to HTTP 1.1 spec. (*) while in partial_display mode we got rendering on the fly, file can only be closed when the transfer complete. robably we should not store it in a file but memory allocation only. Leonid. From owner-lynx-dev@sig.net Tue Nov 10 11:10:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA24214 for ; Tue, 10 Nov 1998 11:10:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA03684; Tue, 10 Nov 1998 09:52:18 -0600 (CST) Date: Tue, 10 Nov 1998 07:54:10 -0800 (PST) From: David Combs Message-Id: <199811101554.HAA18343@netcom8.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 628 Lines: 20 > From owner-lynx-dev@sig.net Mon Nov 9 11:42:03 1998 > From: pg@sweng.stortek.com > Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: > > In a recent note, David Combs said: > > > Date: Mon, 9 Nov 1998 10:08:25 -0800 (PST) > > > > www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) > > > > We need a way to cancel this question, via C-c or something. > > > Why not just type "N"? > The idea is this: I just decided that I hit the wrong key, and don't want to go there at all. (Maybe if "z" was an ok answer -- abort this link and back up one. Or ^C. Or ^G. Anything. SOMETHING!) From owner-lynx-dev@sig.net Tue Nov 10 11:43:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA29670 for ; Tue, 10 Nov 1998 11:43:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA13506; Tue, 10 Nov 1998 10:23:28 -0600 (CST) Date: Tue, 10 Nov 1998 08:25:28 -0800 (PST) From: David Combs Message-Id: <199811101625.IAA20874@netcom8.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4065 Lines: 94 > From owner-lynx-dev@sig.net Mon Nov 9 23:46:27 1998 > From: Bela Lubkin > Date: Mon, 9 Nov 1998 23:49:13 -0800 > > rendered), but not by much, and rendering a cached document would be > > much faster than downloading it repeatedly. Could someone enlighten > > me? > > This issue has been discussed extensively in the past; search the > Lynx-Dev archives for the details. I used www.altavista.com's "advanced > search" to search for "host:www.flora.org AND source AND cach* AND > text:subject AND text:html", finding 59 matches. > > Only that rendered output is cached. Since Lynx has many operations > which require it to re-parse the HTML source, many users have suggested not "suggested", more like SCREAMED for caching (maybe just me!) > that Lynx cache the source as well. This usually leads to a discussion > of pros and cons, some of which are: > > Con: > > - would add to the complexity of Lynx Huh? > - caching rules are very difficult to get right ie, "has the page changed since I last downloaded it". At least for MY browsing, 99% of the time I don't care what's changed in the last TWO MINUTES or so. > - would add code, increasing the size of Lynx source and binary Come now. EVERY improvement (almost) adds to size of source and binary, but you don't find too many of us complaining. Most anyone using LYNX instead of M$ or n-scrape are using for THREE reasons: SPEED, SPEED, and SPEED. Many are administrators (system) and have SO MUCH WORK to do in their 15-hour days, that they'll do most ANYTHING to save 5 seconds here, 3 seconds there -- when they do that operation 1000 times per day. > - would increase the in-core and/or on-disk storage consumed by Lynx > during operation How much. I mean, really, how much can it take to take input from a file than from the net? > - duplicates functionality which is already provided by other > programs, i.e. web caches such as Squid -- programs which are > dedicated to caching functionality and thus can be expected to do > it better than Lynx could hope to Hey, I am using lynx as a USER, on an ISP over which I have NO control or even influence -- they won't even TALK to us users. And if I had set up my own computer as a host, then you are suggesting that I go to all the trouble of finding, compiling, and (by FAR the worst part of all), and having to LEARN some other program -- just so that LYNX (the ONLY program that I run that would involve such caching) can avoid downloading files. Hey, it's hard enough to get LYNX to compile and work, and now you want me to to do that for some OTHER program! > > Pro: > > - would add to the utility of Lynx > - greatly speed operations which require a re-parse, including '\' > view-source, '^V' other-DTD, '*' image-URLs, '"' soft-dquotes, '`' > and "'" comment-parsing, '[' pseudo-alts, '@' raw-mode, and > changes in assumed document character set. > - easier for a regular user to install than a full web proxy I'd say that "easier" is the wrong word. It is virtually IMPOSSIBLE for a normal user to do that. My own head is SO cluttered with different stuff, that it is often in "thrashing mode". Not myself being a "real" admin ('tho that is what I am required to be, as the only user on this sparcstation), you tell me how many classes would I have to go to, and pay for, and take the time and brain-space (scarce!) for, to learn to install AND MAINTAIN AND MANAGE such a thing. NO THANKS! > - persistence of cache can be better tuned to the user (e.g., cached > objects can persist only for the duration of a session, thus not > consume disk space while Lynx not running) > > Possile techniques have been discussed. But the bottom line is that > Lynx is a cooperative volunteer effort, and big projects like a revamped > caching system do not happen unless someone contributes the code. > > Please feel free to jump in and write it! ;-} I would if I could. From owner-lynx-dev@sig.net Tue Nov 10 12:29:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA03377 for ; Tue, 10 Nov 1998 12:29:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA26748; Tue, 10 Nov 1998 11:03:54 -0600 (CST) Date: Tue, 10 Nov 1998 19:04:34 +0200 (EET) From: VictorAs To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: In-Reply-To: <199811101554.HAA18343@netcom8.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: 901 Lines: 27 I think that shortcut "N" is't a bad ideea, but... was useless if we can configure our lynx, isn't it? VictorAs. On Tue, 10 Nov 1998, David Combs wrote: :-) >> From owner-lynx-dev@sig.net Mon Nov 9 11:42:03 1998 :-) >> From: pg@sweng.stortek.com :-) >> Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: :-) >> :-) >> In a recent note, David Combs said: :-) >> :-) >> > Date: Mon, 9 Nov 1998 10:08:25 -0800 (PST) :-) >> > :-) >> > www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) :-) >> > :-) >> > We need a way to cancel this question, via C-c or something. :-) >> > :-) >> Why not just type "N"? :-) >> :-) > :-) >The idea is this: I just decided that I hit the wrong :-) >key, and don't want to go there at all. :-) > :-) >(Maybe if "z" was an ok answer -- abort this link :-) >and back up one. Or ^C. Or ^G. Anything. SOMETHING!) :-) > From owner-lynx-dev@sig.net Tue Nov 10 13:02:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA07709 for ; Tue, 10 Nov 1998 13:02:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA06847; Tue, 10 Nov 1998 11:37:05 -0600 (CST) Date: Tue, 10 Nov 1998 19:28:35 +0200 (EET) From: VictorAs To: lynx-dev@sig.net Subject: lynx-dev a small question 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: 241 Lines: 8 Can anyone send me a lynx.cfg file with advanced stuff included, or only a sample.... I want to configure my lynx and i dont know the lynx.cfg format... Our help i sooo reduced... So please, if you want.... anyone... thanks Victor From owner-lynx-dev@sig.net Tue Nov 10 13:18:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA08553 for ; Tue, 10 Nov 1998 13:18:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA12895; Tue, 10 Nov 1998 11:58:07 -0600 (CST) From: juan_gutmann@libertyart.com.ar Message-Id: Date: Tue, 10 Nov 1998 11:53:01 +0000 To: lynx-dev@sig.net Subject: Re: lynx-dev Trouble With Proxy-Server MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /310000000/310102155/310104315/310380251/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.flora.ottawa.on.ca id NAA08553 Status: RO Content-Length: 1766 Lines: 51 In the first place, I want to send a big "thanks a lot" to Doug Kaufman and to Philip Webb for their very fast replys. Unfortunately, I could not solve my problem. This was the problem: > The Web connection is thru a proxy-server. So, I edited lynx.cfg, > added the proxy server address to the corresponding protocols. > I'm under Windows95 there, using the Lynx 2.8.1 Win32 binaries from l.b.o. > my username at the Proxy Server has the form "lastname-firstname", > so i call lynx this way: lynx.exe -pauth=lastname-firstname:mypassword , > and it doesn't work, because the username has an "-" in it, > lynx assumes "-firstname" is a switch & the complete username isn't received. > I can't change the username: the administrator won't change my username > to anything withouth "-", because that's the standard in the company. Philip wrote: >someone else may have more technical suggestions, >but there might be a way of escaping the - : >have a look in Al Gilman's FAQs in the Main Help Page; I got the FAQ. I guess you refer to the "%hexcode" solution, as Doug did. It doesn't work. If you meant some other solution, I didn't find it in the FAQ, could you be more specific? >or could you perhaps try -pauth=`lastname-firstname' . I tried the following strings without success: -pauth=`lastname-firstname:mypass' -pauth='lastname-firstname:mypass` -pauth=`lastname-firstname:mypass` -pauth='lastname-firstname:mypass' -pauth=lastname%2Dfirstname:mypass -pauth=`lastname%2Dfirstname:mypass' -pauth='lastname%2Dfirstname:mypass` -pauth=`lastname%2Dfirstname:mypass` -pauth='lastname%2Dfirstname:mypass' -pauth="lastname%2Dfirstname:mypass" Any ideas??? Again, thanks a lot to all of you for your concern. Juan Gutmann Buenos Aires, Argentina From owner-lynx-dev@sig.net Tue Nov 10 13:40:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA11205 for ; Tue, 10 Nov 1998 13:40:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA19111; Tue, 10 Nov 1998 12:19:51 -0600 (CST) To: lynx-dev@sig.net References: <199811101625.IAA20874@netcom8.netcom.com> Message-Id: From: "Leonid Pauzner" Date: Tue, 10 Nov 1998 21:17:07 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 1260 Lines: 27 10-Nov-98 08:25 David Combs wrote: >> - caching rules are very difficult to get right > ie, "has the page changed since I last downloaded it". At least for > MY browsing, 99% of the time I don't care what's changed in the last > TWO MINUTES or so. ^^^^^^^^^^^ When you have a long enough lynx session you will care. Some people like starting lynx for _days_ from a separate window. >> - would add code, increasing the size of Lynx source and binary > Come now. EVERY improvement (almost) adds to size of source and binary, > but you don't find too many of us complaining. Most anyone using > LYNX instead of M$ or n-scrape are using for THREE reasons: SPEED, SPEED, > and SPEED. Many are administrators (system) and have SO MUCH WORK to > do in their 15-hour days, that they'll do most ANYTHING to save 5 seconds > here, 3 seconds there -- when they do that operation 1000 times per day. ^^^^^^^^^^^^^^^ I might hardly imagine a person saving 5 second but reading huge lynx-dev in his spare time. The requested internal caching just make lynx a little less annoying in certain situations, this will supersedes "INTERNAL LINKS" stuff, BTW. > Hey, I am using lynx as a USER, on an ISP over which I have NO control choose another ISP From owner-lynx-dev@sig.net Tue Nov 10 13:49:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA11473 for ; Tue, 10 Nov 1998 13:49:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA19412; Tue, 10 Nov 1998 12:20:49 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811101822.LAA05300@sanitas> Subject: Re: lynx-dev a small question To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 11:22:14 -0700 (MST) Cc: vbutiu@uttgm.ro In-Reply-To: from "VictorAs" at Nov 10, 98 07:28: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: 434 Lines: 15 In a recent note, VictorAs said: > Date: Tue, 10 Nov 1998 19:28:35 +0200 (EET) > From: VictorAs > > Can anyone send me a lynx.cfg file with advanced stuff included, > or only a sample.... > I want to configure my lynx and i dont know the lynx.cfg format... > Our help i sooo reduced... > Does this help: Linkname: [ ] lynx.cfg URL: http://www.slcc.edu/lynx/release2-8-1/lynx2-8-1/lynx.cfg -- gil From owner-lynx-dev@sig.net Tue Nov 10 13:57:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA12262 for ; Tue, 10 Nov 1998 13:57:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA21548; Tue, 10 Nov 1998 12:28:10 -0600 (CST) Date: Tue, 10 Nov 1998 13:30:21 -0500 (EST) From: Wayne Buttles To: juan_gutmann@libertyart.com.ar cc: lynx-dev@sig.net Subject: Re: lynx-dev Trouble With Proxy-Server 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: 2033 Lines: 58 Did you try just putting quotes around the argument? lynx.exe "-pauth=lastname-firstname:mypassword" On Tue, 10 Nov 1998 juan_gutmann@libertyart.com.ar wrote: > In the first place, I want to send a big "thanks a lot" to Doug Kaufman and to > Philip Webb for their very fast replys. Unfortunately, I could not solve my > problem. > > This was the problem: > > > The Web connection is thru a proxy-server. So, I edited lynx.cfg, > > added the proxy server address to the corresponding protocols. > > I'm under Windows95 there, using the Lynx 2.8.1 Win32 binaries from l.b.o. > > my username at the Proxy Server has the form "lastname-firstname", > > so i call lynx this way: lynx.exe -pauth=lastname-firstname:mypassword , > > and it doesn't work, because the username has an "-" in it, > > lynx assumes "-firstname" is a switch & the complete username isn't > received. > > I can't change the username: the administrator won't change my username > > to anything withouth "-", because that's the standard in the company. > > Philip wrote: > > >someone else may have more technical suggestions, > >but there might be a way of escaping the - : > >have a look in Al Gilman's FAQs in the Main Help Page; > > I got the FAQ. I guess you refer to the "%hexcode" solution, as Doug did. It > doesn't work. > If you meant some other solution, I didn't find it in the FAQ, could you be > more specific? > > >or could you perhaps try -pauth=`lastname-firstname' . > > I tried the following strings without success: > > -pauth=`lastname-firstname:mypass' > -pauth='lastname-firstname:mypass` > -pauth=`lastname-firstname:mypass` > -pauth='lastname-firstname:mypass' > -pauth=lastname%2Dfirstname:mypass > -pauth=`lastname%2Dfirstname:mypass' > -pauth='lastname%2Dfirstname:mypass` > -pauth=`lastname%2Dfirstname:mypass` > -pauth='lastname%2Dfirstname:mypass' > -pauth="lastname%2Dfirstname:mypass" > > Any ideas??? > > Again, thanks a lot to all of you for your concern. > > Juan Gutmann > Buenos Aires, Argentina > > > From owner-lynx-dev@sig.net Tue Nov 10 15:45:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA23647 for ; Tue, 10 Nov 1998 15:45:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24633; Tue, 10 Nov 1998 14:22:07 -0600 (CST) From: juan_gutmann@libertyart.com.ar Message-Id: Date: Tue, 10 Nov 1998 16:56:32 +0000 To: lynx-dev@sig.net Cc: buttles@wsb.champlain.edu Subject: Re: lynx-dev Trouble With Proxy-Server MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /310000000/310102155/310104315/310380251/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.flora.ottawa.on.ca id PAA23647 Status: RO Content-Length: 175 Lines: 12 >Did you try just putting quotes around the argument? >lynx.exe "-pauth=lastname-firstname:mypassword" Yes, I tried that, too. It doesn't work. Thanks anyway. Juan From owner-lynx-dev@sig.net Tue Nov 10 15:49:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA23763 for ; Tue, 10 Nov 1998 15:49:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA22471; Tue, 10 Nov 1998 14:14:33 -0600 (CST) Date: Tue, 10 Nov 1998 15:16:39 -0500 (EST) From: Wayne Buttles To: juan_gutmann@libertyart.com.ar cc: lynx-dev@sig.net Subject: Re: lynx-dev Trouble With Proxy-Server 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: 296 Lines: 15 Huh, well the -auth command works that way. On Tue, 10 Nov 1998 juan_gutmann@libertyart.com.ar wrote: > >Did you try just putting quotes around the argument? > >lynx.exe "-pauth=lastname-firstname:mypassword" > > Yes, I tried that, too. It doesn't work. > > Thanks anyway. > > Juan > > From owner-lynx-dev@sig.net Tue Nov 10 16:50:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA32069 for ; Tue, 10 Nov 1998 16:50:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA16551; Tue, 10 Nov 1998 15:33:18 -0600 (CST) From: dickey@clark.net Message-Id: <199811102134.QAA07505@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net (Lynx Development) Date: Tue, 10 Nov 1998 16:34:17 -0500 (EST) 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: 439 Lines: 10 i put up the 2.8.2dev.2 patch - connecting to sol is very slow, so I'll pick up detailed changes in the morning. This patch integrates Jim Spath's message library changes. There's more work to do on that, but it's workable as is (I undid much of the embedding of html into the message fragments, but haven't gone through the French message file to update _that_ yet). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 18:07:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA09595 for ; Tue, 10 Nov 1998 18:07:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA08392; Tue, 10 Nov 1998 16:41:05 -0600 (CST) From: Philip Webb Message-Id: <199811102241.RAA22446@chass.utoronto.ca> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 17:41:45 -0500 (EST) In-Reply-To: from "Wayne Buttles" at Nov 10, 98 03:16: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: 719 Lines: 15 981110 various people tried to help Juan Gutmann: >> Did you try just putting quotes around the argument? >> lynx.exe "-pauth=lastname-firstname:mypassword" > Yes, I tried that, too. It doesn't work. may i repeat my suggestion to lynx-dev, which has got overlooked: shouldn't Lynx treat only Space+Hyphen as starting a new switch, but not simply Hyphen not preceded immediately by Space? is it difficult to fix? where should i look in the source? -- ========================,,============================================ 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 Nov 10 18:09:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA09632 for ; Tue, 10 Nov 1998 18:09:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA03805; Tue, 10 Nov 1998 16:27:16 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 14:33:06 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Message-ID: <9811101433.aa28621@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 4790 Lines: 108 David Combs wrote: Before even starting, I would like to point out to David that I was trying to provide an impartial summary of past arguments, not presenting my own position. > > Con: > > > > - would add to the complexity of Lynx > Huh? Caching is complex, tricky business. When this gets implemented we'll surely see dozens of related bugs, for years afterwards. > > - caching rules are very difficult to get right > > ie, "has the page changed since I last downloaded it". At least for > MY browsing, 99% of the time I don't care what's changed in the last > TWO MINUTES or so. In past discussions I have advocated a Lynx internal cache which would hold many documents (user-settable), for arbitrary lengths of time -- perhaps even across invocations of Lynx. As, for instance, Netscape has. Such a cache would have considerable benefits beyond the simple 1-document cache; but it would certainly require full, correct caching semantics. Even the simple 1-document cache has to interact with some caching rules. There have been bugs in the past relating to Lynx's current 1-document-in-1-rendering "cache", which is just about as simple as it can possibly get. > > - would add code, increasing the size of Lynx source and binary > > Come now. EVERY improvement (almost) adds to size of source and binary, > but you don't find too many of us complaining. Most anyone using > LYNX instead of M$ or n-scrape are using for THREE reasons: SPEED, SPEED, > and SPEED. Many are administrators (system) and have SO MUCH WORK to > do in their 15-hour days, that they'll do most ANYTHING to save 5 seconds > here, 3 seconds there -- when they do that operation 1000 times per day. It is a valid objection which has been raised every time the subject has been seriously discussed. > > - would increase the in-core and/or on-disk storage consumed by Lynx > > during operation > > How much. I mean, really, how much can it take to take input from > a file than from the net? Space to store that file on disk, or in memory. Since there is no natural limit on the size of an HTML source file, that could be arbitrarily large. (If the cache fails on files above a set size, I'm sure you'll be back in a week complaining that you found a bigger one...) > > - duplicates functionality which is already provided by other > > programs, i.e. web caches such as Squid -- programs which are > > dedicated to caching functionality and thus can be expected to do > > it better than Lynx could hope to > Hey, I am using lynx as a USER, on an ISP over which I have NO control > or even influence -- they won't even TALK to us users. As LP said: get a better ISP. > And if I had set up my own computer as a host, then you are suggesting > that I go to all the trouble of finding, compiling, and (by FAR the > worst part of all), and having to LEARN some > other program -- just so that LYNX (the ONLY program that I run > that would involve such caching) can avoid downloading files. > > Hey, it's hard enough to get LYNX to compile and work, and now > you want me to to do that for some OTHER program! Hey, you know what? Lynx doesn't balance your checkbook, either, or play `Go', or backup your system to tape. Hate to break it to you, but you will occasionally need software other than Lynx. > > Pro: > > > > - would add to the utility of Lynx > > - greatly speed operations which require a re-parse, including '\' > > view-source, '^V' other-DTD, '*' image-URLs, '"' soft-dquotes, '`' > > and "'" comment-parsing, '[' pseudo-alts, '@' raw-mode, and > > changes in assumed document character set. > > - easier for a regular user to install than a full web proxy > > I'd say that "easier" is the wrong word. It is virtually IMPOSSIBLE > for a normal user to do that. My own head is SO cluttered with > different stuff, that it is often in "thrashing mode". Not myself > being a "real" admin ('tho that is what I am required to be, as the > only user on this sparcstation), you tell me how many classes would I > have to go to, and pay for, and take the time and brain-space (scarce!) > for, to learn to install AND MAINTAIN AND MANAGE such a thing. > > NO THANKS! Again, I was just passing on past arguments. I agree with your position: I could have a proxy, but haven't spent to time to build, install, and learn one; complicated by the fact that I run Lynx on dozens of systems which are in different physical locations, and some have firewalls between them (where I have no control over firewall behavior). So a proxy would be very painful for me to use, and only marginally useful. I really want the internal Lynx cache. So don't flame me for arguments that aren't even mine. >Bela< From owner-lynx-dev@sig.net Tue Nov 10 18:10:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA10063 for ; Tue, 10 Nov 1998 18:10:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA04013; Tue, 10 Nov 1998 16:27:58 -0600 (CST) Message-ID: <000101be0ce4$6d363b20$be9310c8@formas> From: "Marcos Vicente" To: Subject: lynx-dev Questions Date: Tue, 10 Nov 1998 16:57:59 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 210 Lines: 10 I´m having problems reading pages in spanish. I´d like to know how i must configure Lynx to work properly. Thank you very much Marcos Vicente Ps: BTW, I´d like to konw how to configure it to send E-mails. From owner-lynx-dev@sig.net Tue Nov 10 18:10:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA10267 for ; Tue, 10 Nov 1998 18:10:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA12331; Tue, 10 Nov 1998 16:53:16 -0600 (CST) Message-Id: <19981111015501.22718@firepower> Date: Wed, 11 Nov 1998 01:55:01 +0000 From: Sergey Svishchev To: lynx-dev@sig.net Subject: Re: lynx-dev Trouble With Proxy-Server Mail-Followup-To: lynx-dev@sig.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: ; from juan_gutmann@libertyart.com.ar on Mon, Nov 09, 1998 at 01:30:08PM +0000 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 564 Lines: 16 On Mon, Nov 09, 1998 at 01:30:08PM +0000, juan_gutmann@libertyart.com.ar wrote: > I get the following message from LYNX when I execute it: > > Alert: Invalid Header 'Proxy-Authenticate: NTLM' Your problem is not hyphen in your login name. Lynx does not currently support NT LAN Manager-style authentication. http://www.cs.odu.edu/~asf/is2/2/paper.html describes methods of WWW authentication, including NTLM. I think, Samba code and (maybe) MS-CHAP code in pppd can be used as a reference for coding NTLM support. -- Sergey Svishchev -- svs{at}ropnet{dot}ru From owner-lynx-dev@sig.net Tue Nov 10 19:23:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA19458 for ; Tue, 10 Nov 1998 19:23:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA24407; Tue, 10 Nov 1998 17:39:02 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811102340.QAA16945@sanitas> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 16:40:20 -0700 (MST) In-Reply-To: <199811102241.RAA22446@chass.utoronto.ca> from "Philip Webb" at Nov 10, 98 05:41:45 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: 968 Lines: 26 In a recent note, Philip Webb said: > Date: Tue, 10 Nov 1998 17:41:45 -0500 (EST) > > shouldn't Lynx treat only Space+Hyphen as starting a new switch, > but not simply Hyphen not preceded immediately by Space? > is it difficult to fix? where should i look in the source? > Start in LYMain.c: /* * This function performs a string comparison on two strings a and b. a is * assumed to be an ordinary null terminated string, but b may be terminated * by an '=', '+' or '-' character. If terminated by '=', *c will be pointed * to the character following the '='. If terminated by '+' or '-', *c will * be pointed to that character. (+/- added for toggle processing - BL.) * If a and b match, it returns 1. Otherwise 0 is returned. */ static int arg_eqs_parse ARGS3( CONST char *, a, char *, b, char **, c) Presumably, what you want is _not_ to terminate an argument with a '-' as described in the comment. -- gil From owner-lynx-dev@sig.net Tue Nov 10 19:46:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA23199 for ; Tue, 10 Nov 1998 19:46:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA03174; Tue, 10 Nov 1998 18:18:33 -0600 (CST) To: lynx-dev@sig.net References: <199811102134.QAA07505@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 03:08:47 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.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: 999 Lines: 27 > i put up the 2.8.2dev.2 patch - connecting to sol is very slow, so I'll > pick up detailed changes in the morning. This patch integrates Jim > Spath's message library changes. There's more work to do on that, but > it's workable as is (I undid much of the embedding of html into the > message fragments, but haven't gone through the French message file > to update _that_ yet). I have a quick look at this stuff: 1) Please rename makefile.in.in and a couple of others with two dots to a single extension - impossible to unpack .zip on DOS/WIN 2) french "po" file say something like msgid "NeXT character set " msgstr "Jeu de car. NeXT " which obviously wrong for several reasons: 1. trailing spaces not allowed, 2. should be inserted only in option menu but not in LYCharSets.c/UCDomap.c/ LYRCFile.c to avoid compatibility problems with .lynxrc/lynx.cfg 3) please add my fixes for dev1 (and pre2): 1252&help > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 19:50:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA24332 for ; Tue, 10 Nov 1998 19:50:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA03849; Tue, 10 Nov 1998 18:22:18 -0600 (CST) Date: Wed, 11 Nov 1998 09:23:12 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110023.JAA23140@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 424 Lines: 12 > it's workable as is (I undid much of the embedding of html into the > message fragments, This certainly will be a big benefit in the future. Thanks much. > but haven't gone through the French message file > to update _that_ yet). ? _That_ isn't your job. (Or was that a joke.) Anyway, none of the *.po files should be included in the distribution. Japanese is about 1/6th done. Maybe finish at New Years. __Henry From owner-lynx-dev@sig.net Tue Nov 10 19:51:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA24355 for ; Tue, 10 Nov 1998 19:51:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA06573; Tue, 10 Nov 1998 18:36:53 -0600 (CST) From: dickey@clark.net Message-Id: <199811110036.TAA02723@shell.clark.net> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 19:36:57 -0500 (EST) In-Reply-To: <9811101433.aa28621@deepthought.armory.com> from "Bela Lubkin " at Nov 10, 98 02:33: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: 1009 Lines: 28 > > David Combs wrote: > > Before even starting, I would like to point out to David that I was > trying to provide an impartial summary of past arguments, not presenting > my own position. > > > > Con: > > > > > > - would add to the complexity of Lynx > > Huh? > > Caching is complex, tricky business. When this gets implemented we'll > surely see dozens of related bugs, for years afterwards. We might get lucky (stumble across a good/elegant fix), but in general, I'm in agreement here. If I thought it were simple, I'd have looked into it myself. (But frankly, there's sections of the code that are a little hard to follow - not by far the worst I've seen, but enough...) Technical issues aside - once we get into changing that aspect of the design, there'll be a lot of discussion pro/con on _how_ to trigger cache flushing. Look at partial display, which is probably simpler to implement and understand. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 20:01:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA25975 for ; Tue, 10 Nov 1998 20:01:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA07589; Tue, 10 Nov 1998 18:42:30 -0600 (CST) From: dickey@clark.net Message-Id: <199811110039.TAA02906@shell.clark.net> Subject: Re: lynx-dev Questions To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 19:39:55 -0500 (EST) In-Reply-To: <000101be0ce4$6d363b20$be9310c8@formas> from "Marcos Vicente" " at Nov 10, 98 04:57: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: 515 Lines: 20 > > I´m having problems reading pages in spanish. I´d like to know how i must > configure Lynx to work properly. is this a problem setting up the display-characterset? If you are running on some type of Unix system, you can (usually) configure it to display ISO Latin 1 by setting the $LANG variable appropriately. > Thank you very much > > Marcos Vicente > > Ps: BTW, I´d like to konw how to configure it to send E-mails. > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 20:19:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA28122 for ; Tue, 10 Nov 1998 20:19:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA11863; Tue, 10 Nov 1998 19:05:00 -0600 (CST) To: lynx-dev@sig.net References: <9811101433.aa28621@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 03:56:55 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 1710 Lines: 39 10-Nov-98 14:33 Bela Lubkin wrote: > In past discussions I have advocated a Lynx internal cache which would > hold many documents (user-settable), for arbitrary lengths of time -- > perhaps even across invocations of Lynx. As, for instance, Netscape > has. Such a cache would have considerable benefits beyond the simple > 1-document cache; but it would certainly require full, correct caching > semantics. > Even the simple 1-document cache has to interact with some caching Really? Doesn't it enough to introduce one global flag in mainloop - "reload internally" vs "reload as usual"? > rules. There have been bugs in the past relating to Lynx's current > 1-document-in-1-rendering "cache", which is just about as simple as it > can possibly get. 1-document cache may be a first shoot: probably kludge it to incoming socket stream and check the cache somewhere before DNS search - this is not the best way for speed (to use a complete internal circle instead of Klaus's "internal link") but easy and clear. >> > - would increase the in-core and/or on-disk storage consumed by Lynx >> > during operation >> >> How much. I mean, really, how much can it take to take input from >> a file than from the net? > Space to store that file on disk, or in memory. Since there is no > natural limit on the size of an HTML source file, that could be > arbitrarily large. (If the cache fails on files above a set size, I'm > sure you'll be back in a week complaining that you found a bigger > one...) Roughly speaking, caching the sources will takes the same memory as rendered documents takes, so we got a factor 2 or something like this. And disk space for cache should be defined explicitely. From owner-lynx-dev@sig.net Tue Nov 10 20:26:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA29447 for ; Tue, 10 Nov 1998 20:26:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA11845; Tue, 10 Nov 1998 19:04:56 -0600 (CST) To: lynx-dev@sig.net References: <199811102241.RAA22446@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 04:02:48 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Trouble With Proxy-Server 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: 441 Lines: 11 > may i repeat my suggestion to lynx-dev, which has got overlooked: > shouldn't Lynx treat only Space+Hyphen as starting a new switch, > but not simply Hyphen not preceded immediately by Space? > is it difficult to fix? where should i look in the source? LYMain.c - search for "parse_arg" > ========================,,============================================ > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca From owner-lynx-dev@sig.net Tue Nov 10 20:30:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA30399 for ; Tue, 10 Nov 1998 20:30:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA14887; Tue, 10 Nov 1998 19:14:45 -0600 (CST) To: lynx-dev@sig.net References: <000101be0ce4$6d363b20$be9310c8@formas> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 04:13:57 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Questions MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 315 Lines: 12 > I‡m having problems reading pages in spanish. I‡d like to know how i must > configure Lynx to work properly. press 'o' to go Options menu and change "display character set", probably cp850 in your case. > Thank you very much > Marcos Vicente > Ps: BTW, I‡d like to konw how to configure it to send E-mails. From owner-lynx-dev@sig.net Tue Nov 10 20:30:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA30411 for ; Tue, 10 Nov 1998 20:30:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA15240; Tue, 10 Nov 1998 19:16:50 -0600 (CST) From: Philip Webb Message-Id: <199811110117.UAA19596@chass.utoronto.ca> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 20:17:33 -0500 (EST) In-Reply-To: <199811102340.QAA16945@sanitas> from "pg@sweng.stortek.com" at Nov 10, 98 04:40:20 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: 635 Lines: 14 981110 pg wrote: > In a recent note, Philip Webb said: >> shouldn't Lynx treat only Space+Hyphen as starting a new switch, >> but not simply Hyphen not preceded immediately by Space? >> is it difficult to fix? where should i look in the source? > Start in LYMain.c: -- snip -- thanx lots: i'll put it in my to-do folder; maybe someone else will have a go as well. -- ========================,,============================================ 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 Nov 10 21:01:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA03844 for ; Tue, 10 Nov 1998 21:01:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA19962; Tue, 10 Nov 1998 19:41:41 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 17:47:38 -0800 References: <9811101433.aa28621@deepthought.armory.com> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Message-ID: <9811101747.aa21345@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1364 Lines: 30 Leonid Pauzner wrote: > > Even the simple 1-document cache has to interact with some caching > Really? Doesn't it enough to introduce one global flag in mainloop - > "reload internally" vs "reload as usual"? The problem is deciding what value to give that flag! For instance, what should Lynx do if you read a document which expires in 5 hours, then walk away, come back 6 hours later, and ask for it to render differently? This is not the same as a document which was set to expire immediately -- Lynx *has* to assume that such a document is going to be stale some of the time, and let you do what you want. But if it wasn't stale and now it is, maybe it should reload it. Or maybe not. That has to be determined. > > rules. There have been bugs in the past relating to Lynx's current > > 1-document-in-1-rendering "cache", which is just about as simple as it > > can possibly get. > > 1-document cache may be a first shoot: > probably kludge it to incoming socket stream > and check the cache somewhere before DNS search - > this is not the best way for speed (to use a complete internal circle > instead of Klaus's "internal link") but easy and clear. That might be OK. I would prefer to see a full-blown implementation at the start, mainly because I think if we get the 1-document cache going, nobody will ever bother to do the full one... >Bela< From owner-lynx-dev@sig.net Tue Nov 10 21:05:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA04277 for ; Tue, 10 Nov 1998 21:05:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA21195; Tue, 10 Nov 1998 19:48:22 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 04:48:30 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev How to maintain sources with gettext() ? 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: 268 Lines: 6 Is there any special limitation for code using gettext(), e.g. to change english string or just change the line number: would the .po files rescaned properly or became broken? Some docs required. Also, the INSTALLATION file should be updated for new config options. From owner-lynx-dev@sig.net Tue Nov 10 21:48:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA10394 for ; Tue, 10 Nov 1998 21:48:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA26810; Tue, 10 Nov 1998 20:19:24 -0600 (CST) Date: Wed, 11 Nov 1998 11:22:00 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110222.LAA23828@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 789 Lines: 19 > Is there any special limitation for code using gettext(), > e.g. to change english string or just change the line number: If the English string is changed, i.e., the ``msgid ""'', then the .po file must be updated. That is why none of the .po files should be included in the distribution. If they are, then really it seems to me that the "distributors" are obligated to update all of them. What a waste of time. If anything were to be included, only "lynx.pot", the template, should be included, but that too is of very questionable value since it is so easy to create one fresh, after the breakout. > Some docs required. > Also, the INSTALLATION file should be updated for new config options. I'll work on it this winter vacation. Anyone is welcome to beat me to it :-) __Henry From owner-lynx-dev@sig.net Tue Nov 10 21:54:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA11625 for ; Tue, 10 Nov 1998 21:54:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA28871; Tue, 10 Nov 1998 20:30:29 -0600 (CST) Date: Wed, 11 Nov 1998 11:33:08 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110233.LAA23876@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 724 Lines: 21 > 1) Please rename makefile.in.in and a couple of others with two dots If this is in reference to /intl and /po, PLEASE don't include ANY of it. > 2) french "po" file say something like I couldn't get fr.po to even compile. I think it's broken. > msgid "NeXT character set " msgstr "Jeu de car. NeXT " which obviously > wrong for several reasons: 1. trailing spaces not allowed, One nice "feature" of xgettext is that it will find errors in the code. > 2. should be inserted only in option menu but not in > LYCharSets.c/UCDomap.c/ LYRCFile.c to avoid compatibility problems > with .lynxrc/lynx.cfg If this is the case, developers may have to come up with different wording for strings to make them unique. __Henry From owner-lynx-dev@sig.net Tue Nov 10 22:03:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA13636 for ; Tue, 10 Nov 1998 22:03:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA28308; Tue, 10 Nov 1998 20:27:52 -0600 (CST) From: Philip Webb Message-Id: <199811110228.VAA05185@chass.utoronto.ca> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 21:28:35 -0500 (EST) In-Reply-To: from "Leonid Pauzner" at Nov 11, 98 03:08:47 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: 1204 Lines: 29 981111 Leonid Pauzner wrote: > french "po" file say something like > msgid "NeXT character set " > msgstr "Jeu de car. NeXT " > which obviously wrong for several reasons: > 1. trailing spaces not allowed, > 2. should be inserted only in option menu > but not in LYCharSets.c/UCDomap.c/LYRCFile.c > to avoid compatibility problems with .lynxrc/lynx.cfg and 3. because `Jeu de car' isn't French, let alone a translation (unless it's some sort of jargon or slang); `jeu de cartes' = `card game' (eg bridge), `jeu de mots' = `pun'. i haven't been following this thread at all, but do know something about some (human) languages, incl French: where are you getting the translations from ... ? > 3) please add my fixes for dev1 (and pre2): 1252&help while people are adding things, could you revise the 1-line account of the ^v (tagsoup) keybinding to be more informative: i suggested a wording. all with the usual (smiles). -- ========================,,============================================ 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 Nov 10 22:04:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA13862 for ; Tue, 10 Nov 1998 22:04:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA25636; Tue, 10 Nov 1998 20:12:37 -0600 (CST) Date: Tue, 10 Nov 1998 18:14:33 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.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: 465 Lines: 13 On Wed, 11 Nov 1998, Leonid Pauzner wrote: > 1) Please rename makefile.in.in and a couple of others with two dots > to a single extension - impossible to unpack .zip on DOS/WIN What unzipping program are you using? Info-Zip's "unzip" shouldn't have problems with this type of file. It is converted to makefile_in.in, or in 8+3 to makefile.in. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Nov 10 22:13:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA15643 for ; Tue, 10 Nov 1998 22:13:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA03198; Tue, 10 Nov 1998 20:55:04 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 19:01:02 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Message-ID: <9811101901.aa29204@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2114 Lines: 42 Nelson Henry Eric wrote: > > Is there any special limitation for code using gettext(), > > e.g. to change english string or just change the line number: > > If the English string is changed, i.e., the ``msgid ""'', then > the .po file must be updated. That is why none of the .po files > should be included in the distribution. If they are, then really > it seems to me that the "distributors" are obligated to update > all of them. What a waste of time. But then who *does* update the other language files? I know what SCO does: if a message is updated, the person doing the update changes it in all the message catalogues, replacing the foreign language messages with "STILL_ENGLISH rest of English message". Translation teams dig out those "STILL_ENGLISH" tags and correct the messages. The rule is to change it to "STILL_ENGLISH rest of message" even if you *think* you know the right translation, because all too often people who think that are wrong. Lynx, having a much more international development team, would probably have people doing updates who would know the correct messages in 2, 3, maybe even more languages, but still not all of them. So I think a good rule is: When adding a message, add it to all the catalogues, using "STILL_ENGLISH rest of message" in any catalogues you can't fill in correctly yourself. When changing an existing message, fix any ones you can. Any that you can't, add a "STILL_ENGLISH" marker, plus the new English message, and something to show the old non-English text of the message, i.e. STILL_ENGLISH Good day, eh! (formerly "Guten Tag!") If the message catalogues are distributed in the source, they can be updated in this manner, and translators can jump in at any time during ongoing development. If only the English catalogue is distributed, translators need to wait until a stable release point or else maintain their own parallel development setups, which is a hassle. It's much easier and safer to check everything into a central repository, much more conducive to synchronized updates of everything that needs updated. >Bela< From owner-lynx-dev@sig.net Tue Nov 10 22:40:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA19803 for ; Tue, 10 Nov 1998 22:40:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA07135; Tue, 10 Nov 1998 21:14:49 -0600 (CST) From: dickey@clark.net Message-Id: <199811110316.WAA05683@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 22:16:23 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 11, 98 03:08: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: 1234 Lines: 32 > > > i put up the 2.8.2dev.2 patch - connecting to sol is very slow, so I'll > > pick up detailed changes in the morning. This patch integrates Jim > > Spath's message library changes. There's more work to do on that, but > > it's workable as is (I undid much of the embedding of html into the > > message fragments, but haven't gone through the French message file > > to update _that_ yet). > > I have a quick look at this stuff: > 1) Please rename makefile.in.in and a couple of others with two dots > to a single extension - impossible to unpack .zip on DOS/WIN ok > > 2) french "po" file say something like > msgid "NeXT character set " > msgstr "Jeu de car. NeXT " > which obviously wrong for several reasons: > 1. trailing spaces not allowed, the msgid is generated from the actual literal. the msgstr is handcrafted - we'll have to work on these... > 2. should be inserted only in option menu but not in LYCharSets.c/UCDomap.c/ > LYRCFile.c to avoid compatibility problems with .lynxrc/lynx.cfg > > 3) please add my fixes for dev1 (and pre2): 1252&help I have several patches, but this one was the largest - will check. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 22:53:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA21264 for ; Tue, 10 Nov 1998 22:53:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA07931; Tue, 10 Nov 1998 21:18:27 -0600 (CST) From: dickey@clark.net Message-Id: <199811110319.WAA05915@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 22:19:47 -0500 (EST) In-Reply-To: <199811110023.JAA23140@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 11, 98 09:23:12 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: 935 Lines: 27 > > > it's workable as is (I undid much of the embedding of html into the > > message fragments, > > This certainly will be a big benefit in the future. Thanks much. > > > but haven't gone through the French message file > to update _that_ yet). > > ? _That_ isn't your job. (Or was that a joke.) Anyway, none of the > *.po files should be included in the distribution. we'll have to work out a nice way to apply these as add-ons (I'm not satisfied with the way it's organized). -- it's not my job to update the file, but it makes it simpler for testing if I update some of it, to account for the places where I get rid of the embedded html, etc. (Or, as Bela suggests, maybe someone else can work on that - but it has to be done in sync with the C code). > Japanese is about 1/6th done. Maybe finish at New Years. > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 22:53:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA21277 for ; Tue, 10 Nov 1998 22:53:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA07429; Tue, 10 Nov 1998 21:16:18 -0600 (CST) Date: Tue, 10 Nov 1998 19:18:09 -0800 (PST) From: David Combs Message-Id: <199811110318.TAA01256@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1160 Lines: 38 Please explain a bit more -- I don't understand. > From owner-lynx-dev@sig.net Tue Nov 10 09:09:27 1998 > Date: Tue, 10 Nov 1998 19:04:34 +0200 (EET) > From: VictorAs > > I think that shortcut "N" is't a bad ideea, but... was useless if we can > configure our lynx, isn't it? > VictorAs. > Thanks. > On Tue, 10 Nov 1998, David Combs wrote: > > :-) >> From owner-lynx-dev@sig.net Mon Nov 9 11:42:03 1998 > :-) >> From: pg@sweng.stortek.com > :-) >> Subject: Re: lynx-dev LYNX: allow C-G or C-c in this: > :-) >> > :-) >> In a recent note, David Combs said: > :-) >> > :-) >> > Date: Mon, 9 Nov 1998 10:08:25 -0800 (PST) > :-) >> > > :-) >> > www.visa.com cookie: INTERSE=1921128910634813 Allow? (Y/N/Always/neVer) > :-) >> > > :-) >> > We need a way to cancel this question, via C-c or something. > :-) >> > > :-) >> Why not just type "N"? > :-) >> > :-) > > :-) >The idea is this: I just decided that I hit the wrong > :-) >key, and don't want to go there at all. > :-) > > :-) >(Maybe if "z" was an ok answer -- abort this link > :-) >and back up one. Or ^C. Or ^G. Anything. SOMETHING!) > :-) > > > From owner-lynx-dev@sig.net Tue Nov 10 22:56:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA21555 for ; Tue, 10 Nov 1998 22:56:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA11241; Tue, 10 Nov 1998 21:35:13 -0600 (CST) Date: Tue, 10 Nov 1998 19:37:16 -0800 (PST) From: David Combs Message-Id: <199811110337.TAA03095@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1195 Lines: 31 Not flaming you. Just the arguments that I keep hearing over and over -- make lynx smaller, smaller, smaller. And truly I know nothing about caching, or about the difficulties with it, but really dislike the waiting when I back up on the stack to re-download something I might likely not want to see at all! Certainly there could be options on max bytes to save on disk (of course it would be saved to disk, not in core, huh?), and some lru toss-away rule depending on that option, and maybe a settable time-limit for cache to stay (with maybe optional prompt "file expired -- want to keep anyway?"), etc. It would have to be run-time turn-on-offable, so the user could determine whether he wanted a simple and at times incorrect caching, vs no caching at all. His choice -- likely made differently at different times. I would say that also for this session only, and for only this run of lynx -- no second person running lynx could use "my" cache. Maybe it can be simplified enough (by restricting what it does), and optional enough, to be useful to most of us most of the time. THAT would be a win. Again, was not intending a flame, though that's what it came out as. Sorry. David From owner-lynx-dev@sig.net Tue Nov 10 22:58:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA21584 for ; Tue, 10 Nov 1998 22:58:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA10735; Tue, 10 Nov 1998 21:32:51 -0600 (CST) From: dickey@clark.net Message-Id: <199811110326.WAA07562@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 22:26:56 -0500 (EST) In-Reply-To: <199811110233.LAA23876@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 11, 98 11:33:08 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: 1334 Lines: 38 > > 1) Please rename makefile.in.in and a couple of others with two dots > > If this is in reference to /intl and /po, PLEASE don't include ANY of > it. for this pass, I included it - I'd rather make it an add-on package, but that'll take more work. > > 2) french "po" file say something like > > I couldn't get fr.po to even compile. I think it's broken. I spent the past couple of mornings finding that the Solaris version of xgettext doesn't handle the files Lynx has: too many files, and the Solaris versions don't parse the continued lines. And the workarounds don't work. So I don't see how to build it without the GNU gettext stuff. (And building _that_, I found one syntax error ;-). > > msgid "NeXT character set " msgstr "Jeu de car. NeXT " which obviously > > wrong for several reasons: 1. trailing spaces not allowed, > > One nice "feature" of xgettext is that it will find errors in the code. > > > 2. should be inserted only in option menu but not in > > LYCharSets.c/UCDomap.c/ LYRCFile.c to avoid compatibility problems > > with .lynxrc/lynx.cfg > > If this is the case, developers may have to come up with different > wording for strings to make them unique. yes - that's a weakness of xgettext. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 10 23:09:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA22350 for ; Tue, 10 Nov 1998 23:09:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12958; Tue, 10 Nov 1998 21:44:15 -0600 (CST) Date: Tue, 10 Nov 1998 19:46:19 -0800 (PST) From: David Combs Message-Id: <199811110346.TAA04023@netcom12.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 294 Lines: 9 > From owner-lynx-dev@sig.net Tue Nov 10 18:31:04 1998 > From: Philip Webb > Subject: Re: lynx-dev lynx2.8.2dev.2 > > > and 3. because `Jeu de car' isn't French, let alone a translation > (unless it's some sort of jargon or slang); Maybe he's hacking lisp. :-) From owner-lynx-dev@sig.net Tue Nov 10 23:24:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA24003 for ; Tue, 10 Nov 1998 23:24:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA15839; Tue, 10 Nov 1998 22:01:23 -0600 (CST) Date: Wed, 11 Nov 1998 13:04:12 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110404.NAA24331@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2088 Lines: 48 > But then who *does* update the other language files? The person using it (them). If they're not themselves a competent translator, then the *.po file may be obtained from the Free Software Foundation, the owner of the copyright (theoretically). > but still not all of them. So I think a good rule is: > > When adding a message, add it to all the catalogues, using > "STILL_ENGLISH rest of message" in any catalogues you can't fill in No! Leave the work to the tools in the gettext package. Any `msgstr ""', i.e., no translation, will fall back to the English default, which is a lot better than "STILL_ENGLISH rest of message", which gives you absolutely no idea what Lynx is doing. It takes time, and I mean lots of time to translate. No catalogue is going to get done overnight. The beauty of gettext is that you can plug away at it string by string. > If the message catalogues are distributed in the source, they can be > updated in this manner, and translators can jump in at any time during Please realize that _each_ .po file is 100Kb+. Ten languages, and you've got a 1Mb floppy filled up. > ongoing development. If only the English catalogue is distributed, > translators need to wait until a stable release point or else maintain > their own parallel development setups, which is a hassle. It's much Before any more discussion goes on on lynx-dev, I recommend that interested parties get the gettext package and see how it works. The "English catalogue" is the *code itself*! Generating an "English catalogue" in the form that gettext uses takes only a few seconds (even on the SunOS clunker I've been doing my work on). Translators do NOT have to wait for a stable release. They can, as I'm doing, start right now! That's the whole reason for putting gettext in there in the first place! > easier and safer to check everything into a central repository, much The central repository is provided by the NLS project. Not just for Lynx, but for the whole world of free software. Anyway, find out what it's all about. Then let's discuss it. __Henry From owner-lynx-dev@sig.net Tue Nov 10 23:46:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26099 for ; Tue, 10 Nov 1998 23:46:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA20653; Tue, 10 Nov 1998 22:24:07 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 20:30:08 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Message-ID: <9811102030.aa08653@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1165 Lines: 27 Nelson Henry Eric wrote: > > but still not all of them. So I think a good rule is: > > > > When adding a message, add it to all the catalogues, using > > "STILL_ENGLISH rest of message" in any catalogues you can't fill in > > No! Leave the work to the tools in the gettext package. Any `msgstr ""', > i.e., no translation, will fall back to the English default, which > is a lot better than "STILL_ENGLISH rest of message", which gives you > absolutely no idea what Lynx is doing. Sorry, you seem to have misunderstood me. What you put into the other message catalogues is "STILL_ENGLISH" followed by the "rest of message", that is, the actual English message. Not the literal text ``rest of message''! > > If the message catalogues are distributed in the source, they can be > > updated in this manner, and translators can jump in at any time during > > Please realize that _each_ .po file is 100Kb+. Ten languages, and > you've got a 1Mb floppy filled up. They should compress very well, and two of them side-by-side in an archive should compress even better; especially with a compressor that has a large compression window, like `bzip2`. >Bela< From owner-lynx-dev@sig.net Tue Nov 10 23:47:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26105 for ; Tue, 10 Nov 1998 23:47:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA17229; Tue, 10 Nov 1998 22:07:37 -0600 (CST) Date: Wed, 11 Nov 1998 13:09:14 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110409.NAA24384@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 209 Lines: 5 > > (unless it's some sort of jargon or slang); ^^^^^ Never underestimate the power of a translator. Usually they're the ones who start wars and then end them. __Henry From owner-lynx-dev@sig.net Tue Nov 10 23:51:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26616 for ; Tue, 10 Nov 1998 23:51:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA19843; Tue, 10 Nov 1998 22:20:13 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 20:26:13 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Message-ID: <9811102026.aa08185@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1969 Lines: 46 David Combs wrote: > Not flaming you. Just the arguments that I keep hearing over > and over -- make lynx smaller, smaller, smaller. Size isn't *your* concern, but it is a legitimate concern of some users. Live with it. > Certainly there could be options on max bytes to save on disk > (of course it would be saved to disk, not in core, huh?), There are excellent reasons why a particular user might choose either. > and some lru toss-away rule depending on that option, > and maybe a settable time-limit for cache to stay (with maybe > optional prompt "file expired -- want to keep anyway?"), > etc. > > It would have to be run-time turn-on-offable, so the user could > determine whether he wanted a simple and at times incorrect > caching, vs no caching at all. His choice -- likely made > differently at different times. > > I would say that also for this session only, and for only > this run of lynx -- no second person running lynx could > use "my" cache. Again, these are things that might profitably be tunable. I hadn't thought about the idea of multiple users sharing one Lynx cache. An anonymous site operator might want to do that, to save space while providing the largest possible cache (== the best user experience). A single user on his own system would probably want to save the cache across sessions. A sysadmin on a multiuser site where the users *do* have shell access and can't be trusted with a shared cache, would probably want each users' cache to be separate and volatile (to avoid wasting disk space on old, stale cache files for users who haven't even logged in recently). Of course, the more tunable parameters we design into it in our heads, the more difficult the actually programming project becomes... > Maybe it can be simplified enough (by restricting what it does), > and optional enough, to be useful to most of us most of the time. "Simplify" and "make things optional" are diametrically opposed trends... >Bela< From owner-lynx-dev@sig.net Wed Nov 11 00:14:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA28609 for ; Wed, 11 Nov 1998 00:14:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA26111; Tue, 10 Nov 1998 22:57:33 -0600 (CST) Date: Wed, 11 Nov 1998 14:00:28 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110500.OAA24783@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 588 Lines: 13 > Sorry, you seem to have misunderstood me. What you put into the other > message catalogues is "STILL_ENGLISH" followed by the "rest of message", "rest of message" speaks for itself. No need for "STILL_ENGLISH". But, yes, I did misunderstand you. :) > archive should compress even better; especially with a compressor that > has a large compression window, like `bzip2`. I just spent 30 minutes downloading 27Kb of 2.8.2dev.2 before I gave up. I have an `at' job which will try at 3 AM. It means I cannot provide feedback until next week. I'm talking about the tar.bz2. __Henry From owner-lynx-dev@sig.net Wed Nov 11 00:26:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA29652 for ; Wed, 11 Nov 1998 00:26:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA28850; Tue, 10 Nov 1998 23:10:30 -0600 (CST) From: dickey@clark.net Message-Id: <199811110329.WAA07749@shell.clark.net> Subject: Re: lynx-dev How to maintain sources with gettext() ? To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 22:29:26 -0500 (EST) In-Reply-To: <199811110222.LAA23828@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 11, 98 11:22: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: 1140 Lines: 33 > > Is there any special limitation for code using gettext(), > > e.g. to change english string or just change the line number: > > If the English string is changed, i.e., the ``msgid ""'', then > the .po file must be updated. That is why none of the .po files > should be included in the distribution. If they are, then really > it seems to me that the "distributors" are obligated to update > all of them. What a waste of time. but at least if I update the msgid's in the C code, then the .po files don't break - they just leak a little. > If anything were to be included, only "lynx.pot", the template, > should be included, but that too is of very questionable value > since it is so easy to create one fresh, after the breakout. I'd rather not distribute _any_ generated files. I didn't checkin the .mo or .gmo files, for instance. > > Some docs required. > > Also, the INSTALLATION file should be updated for new config options. yes. > I'll work on it this winter vacation. Anyone is welcome to beat me > to it :-) > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 00:59:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA31741 for ; Wed, 11 Nov 1998 00:59:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA01503; Tue, 10 Nov 1998 23:29:07 -0600 (CST) Date: Wed, 11 Nov 1998 13:45:03 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110445.NAA24684@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1064 Lines: 25 > for this pass, I included it - I'd rather make it an add-on package, but > that'll take more work. Don't understand. I found it MUCH less work once I got the old stuff out of the way, i.e., "rm -r /intl /po". For each breakout, a new lynx.pot has to be made, anyway. (Translators: diff it against the lynx.pot that you made your original translation against, and you'll know right away what needs to be fixed. That's right, keep old one's around for reference.) > don't work. So I don't see how to build it without the GNU gettext stuff. > (And building _that_, I found one syntax error ;-). I think that's what I've been trying to say all along. Bite the bullet and use GNU make once, and then you'll be through with it. > > If this is the case, developers may have to come up with different > > wording for strings to make them unique. > > yes - that's a weakness of xgettext. I was hoping my understanding was _in_correct. Oh, well, cannot have everything, I guess. :( I still think it's an improvement over the include file, though. __Henry From owner-lynx-dev@sig.net Wed Nov 11 01:00:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA32047 for ; Wed, 11 Nov 1998 01:00:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA29669; Tue, 10 Nov 1998 23:16:02 -0600 (CST) Date: Wed, 11 Nov 1998 14:17:39 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110517.OAA24855@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1086 Lines: 21 > -- it's not my job to update the file, but it makes it simpler for testing > if I update some of it, to account for the places where I get rid of the > embedded html, etc. (Or, as Bela suggests, maybe someone else can work > on that - but it has to be done in sync with the C code). I'm not being understood. All you, as a developer, should need to do is `xgettext -f z-ls -o lynx.pot` where "z-ls" is a list of all source files. If you get a valid (= no error messages from xgettext) "lynx.pot", then your job is finished. xgettest tells the developer why and exactly where it is unhappy if there is some problem it sees in the code. If you are more of a perfectionist, then also run `msgfmt -v -o lynx.mo lynx.pot` to be sure it will compile. There is no need to include the lynx.pot file, because anyone serious about having NLS support will need the package. We're not talking about just Lynx. I can't imagine why you want to volunteer to "fix" the gettext package and/or provide support for building it (the purpose of /intl) and installing it (/po). __Henry From owner-lynx-dev@sig.net Wed Nov 11 02:03:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA02819 for ; Wed, 11 Nov 1998 02:03:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA08167; Wed, 11 Nov 1998 00:22:57 -0600 (CST) From: Bela Lubkin Date: Tue, 10 Nov 1998 22:28:59 -0800 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Message-ID: <9811102228.aa19792@deepthought.armory.com> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1224 Lines: 26 Nelson Henry Eric wrote: > > Sorry, you seem to have misunderstood me. What you put into the other > > message catalogues is "STILL_ENGLISH" followed by the "rest of message", > > "rest of message" speaks for itself. No need for "STILL_ENGLISH". > But, yes, I did misunderstand you. :) "STILL_ENGLISH" is a token, to make it easy to find such problems with a tool like `grep`. I don't happen to have a `grep` tool that can distinguish one human language from another, unless the author tags it. > > archive should compress even better; especially with a compressor that > > has a large compression window, like `bzip2`. > > I just spent 30 minutes downloading 27Kb of 2.8.2dev.2 before I gave > up. I have an `at' job which will try at 3 AM. It means I cannot > provide feedback until next week. I'm talking about the tar.bz2. You know, connectivity keeps getting better and cheaper around the world. I certainly had less trouble with bandwidth than you when I was traveling in the former USSR -- using one Soviet-style ISP in Moscow, then a newfangled "cybercafe" in St. Petersburg and a small-business ISP in Tallinn. Surely your university will be able to afford decent connectivity some time soon. >Bela< From owner-lynx-dev@sig.net Wed Nov 11 02:58:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA06075 for ; Wed, 11 Nov 1998 02:58:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA16595; Wed, 11 Nov 1998 01:45:37 -0600 (CST) From: David Woolley Message-Id: <199811100856.IAA19942@djwhome.demon.co.uk> Subject: lynx-dev Unexpected Cookie Prompts (was: [no useful subject (having trouble)]) To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 08:56:13 +0000 (GMT) Cc: pdavis@emrl.com In-Reply-To: from "Pam Davis" at Nov 9, 98 11:41:08 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: 538 Lines: 10 > and at one point was offfered a "cookie" which i declined. what's > up? Most commercial sites will try and set cookies these days. If you weren't expecting one, the most likely reason is to allow them to track your accesses for market research purposes. Other reasons are to dispense with a formal logon and to correlate accesses within a single session, e.g. to mainta a "shopping cart". NB the web provider of apparently non-commercial sites may well track you, even if the site owner has no particular requirement for this. From owner-lynx-dev@sig.net Wed Nov 11 02:59:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA06089 for ; Wed, 11 Nov 1998 02:59:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA16657; Wed, 11 Nov 1998 01:46:04 -0600 (CST) From: David Woolley Message-Id: <199811100829.IAA19835@djwhome.demon.co.uk> Subject: lynx-dev Informative subjects (was: unanswered queries (8)) To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 08:29:44 +0000 (GMT) In-Reply-To: <199811092326.SAA05115@chass.utoronto.ca> from "Philip Webb" at Nov 9, 98 06:26:43 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: 349 Lines: 5 > but could you remember to copy your responses to lynx-dev, And could you use informative titles so that these can be found in the archives. I tend to skip these ones because I have no idea what the real subject is. On the other hand, I am more tolerant of newbies using informationless subjects, although I'll normally change them on the reply. From owner-lynx-dev@sig.net Wed Nov 11 02:59:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA06098 for ; Wed, 11 Nov 1998 02:59:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA16636; Wed, 11 Nov 1998 01:45:55 -0600 (CST) From: David Woolley Message-Id: <199811100852.IAA19933@djwhome.demon.co.uk> Subject: lynx-dev Corrupt Displays on emrl.com (was: [no useful subject (having trouble)]) To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 08:52:03 +0000 (GMT) Cc: pdavis@emrl.com In-Reply-To: from "Pam Davis" at Nov 9, 98 11:41:08 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: 588 Lines: 13 > > i use lynx via emrl.com and i'm getting lot's of garbage, ie misplaced > text, Sounds like you are using a shell account. Are you by any chance using the Microsoft terminal program, which is badly broken? Corrupt displays are either flow control failures or the result of telling a shell account that you are using one sort of terminal whilst actually using a terminal that doesn't behave that way. See man terminfo, man termcap etc. and check your terminal emulator and TERM environment variable settings. Don't assume that everyone knows what software you and emrl are using. From owner-lynx-dev@sig.net Wed Nov 11 03:00:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA06184 for ; Wed, 11 Nov 1998 03:00:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA16779; Wed, 11 Nov 1998 01:47:15 -0600 (CST) From: David Woolley Message-Id: <199811100813.IAA19814@djwhome.demon.co.uk> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Tue, 10 Nov 1998 08:13:16 +0000 (GMT) Cc: juan_gutmann@libertyart.com.ar In-Reply-To: from "juan_gutmann@libertyart.com.ar" at Nov 9, 98 01:30:08 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: 277 Lines: 6 > Alert: Invalid Header 'Proxy-Authenticate: NTLM' Your proxy server is using a Microsoft proprietory authentication protocol, although one person from Microsoft did half volunteer to implement in Lynx, recently. Ask the system administrator to enable basic authentication. From owner-lynx-dev@sig.net Wed Nov 11 03:05:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA06414 for ; Wed, 11 Nov 1998 03:05:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA17376; Wed, 11 Nov 1998 01:54:48 -0600 (CST) Date: Wed, 11 Nov 1998 16:57:40 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811110757.QAA25691@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 644 Lines: 14 > "STILL_ENGLISH" is a token, to make it easy to find such problems with > a tool like `grep`. I don't happen to have a `grep` tool that can grep on 'msgstr ""' (escaping the quotes, I'll leave up to you :). Or, better yet, use xgettext to automagically add to your *.po file. > in Tallinn. Surely your university will be able to afford decent > connectivity some time soon. Not as long as the president lives in a $50 million mansion, maintains another equally expensive home in Tokyo, and drives a different car for each day of the week (actually the chauffeur_s_ do the driving). The exaggeration is less than you might think. __Henry From owner-lynx-dev@sig.net Wed Nov 11 04:16:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA10341 for ; Wed, 11 Nov 1998 04:16:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA23667; Wed, 11 Nov 1998 03:05:43 -0600 (CST) Date: Wed, 11 Nov 1998 09:12:43 +0100 From: Louis-David Mitterrand To: lynx-dev@sig.net Subject: lynx-dev Re: lynx2.8.2dev.2 Message-ID: <19981111091243.A5567@uturoa> Mail-Followup-To: lynx-dev@sig.net References: <199811110228.VAA05185@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i In-Reply-To: <199811110228.VAA05185@chass.utoronto.ca>; from Philip Webb on Tue, Nov 10, 1998 at 09:28:35PM -0500 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1124 Lines: 27 On Tue, Nov 10, 1998 at 09:28:35PM -0500, Philip Webb wrote: > 981111 Leonid Pauzner wrote: > > french "po" file say something like > > msgid "NeXT character set " > > msgstr "Jeu de car. NeXT " > > which obviously wrong for several reasons: > > 1. trailing spaces not allowed, > > 2. should be inserted only in option menu > > but not in LYCharSets.c/UCDomap.c/LYRCFile.c > > to avoid compatibility problems with .lynxrc/lynx.cfg > > and 3. because `Jeu de car' isn't French, let alone a translation > (unless it's some sort of jargon or slang); > `jeu de cartes' = `card game' (eg bridge), `jeu de mots' = `pun'. > i haven't been following this thread at all, > but do know something about some (human) languages, incl French: > where are you getting the translations from ... ? "Jeu de car." is correct and is not slang or jargon. In this case "jeu" means a set which makes a complete collection and can be treated as a whole. Example: jeu de clefs = set of keys -- Louis-David Mitterrand - mito@aparima.com - http://www.aparima.com Bill Gates to his broker: "You idiot, I said $150 million on **SNAPPLE**!!!" From owner-lynx-dev@sig.net Wed Nov 11 04:33:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA11384 for ; Wed, 11 Nov 1998 04:33:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA25050; Wed, 11 Nov 1998 03:22:16 -0600 (CST) Date: Wed, 11 Nov 1998 09:26:32 -0800 (PST) From: Vitor Manuel dos Santos Oliveira To: lynx-dev@sig.net Subject: Re: lynx-dev Questions In-Reply-To: <000101be0ce4$6d363b20$be9310c8@formas> Message-ID: X-X-Sender: vimasol@mail.esoterica.pt 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.flora.ottawa.on.ca id EAA11384 Status: RO Content-Length: 426 Lines: 23 Hi: Please let me know in what platform are you working. Vitor Manuel dos Santos Oliveira phon=3511-4743718 Lisbon Portugal vimasol@esoterica.pt On Tue, 10 Nov 1998, Marcos Vicente wrote: > I´m having problems reading pages in spanish. I´d like to know how i must > configure Lynx to work properly. > > Thank you very much > > Marcos Vicente > > Ps: BTW, I´d like to konw how to configure it to send E-mails. > > > From owner-lynx-dev@sig.net Wed Nov 11 05:26:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA14026 for ; Wed, 11 Nov 1998 05:26:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA28886; Wed, 11 Nov 1998 04:12:46 -0600 (CST) From: dickey@clark.net Message-Id: <199811111014.FAA00603@shell.clark.net> Subject: Re: lynx-dev How to maintain sources with gettext() ? To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 05:14:11 -0500 (EST) In-Reply-To: <9811101901.aa29204@deepthought.armory.com> from "Bela Lubkin " at Nov 10, 98 07:01:02 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: 1205 Lines: 26 > But then who *does* update the other language files? > > I know what SCO does: if a message is updated, the person doing the > update changes it in all the message catalogues, replacing the foreign > language messages with "STILL_ENGLISH rest of English message". I haven't experimented with this, but (reading the GNU gettext documentation), it indicates there's a way to automatically (with tupdate) mark the messages that have become orphaned or obsolete as comments. Probably we can reduce this to a less-manual procedure - something that reads the message catalogs and lists the messages that have to be updated. > Translation teams dig out those "STILL_ENGLISH" tags and correct the > messages. The rule is to change it to "STILL_ENGLISH rest of message" > even if you *think* you know the right translation, because all too > often people who think that are wrong. Lynx, having a much more > international development team, would probably have people doing updates > who would know the correct messages in 2, 3, maybe even more languages, > but still not all of them. So I think a good rule is: > >Bela< -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 05:30:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA14537 for ; Wed, 11 Nov 1998 05:30:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA29037; Wed, 11 Nov 1998 04:14:50 -0600 (CST) To: lynx-dev@sig.net References: <9811101747.aa21345@deepthought.armory.com> <9811101433.aa28621@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 13:10:05 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 2175 Lines: 50 >> > rules. There have been bugs in the past relating to Lynx's current >> > 1-document-in-1-rendering "cache", which is just about as simple as it >> > can possibly get. >> >> 1-document cache may be a first shoot: >> probably kludge it to incoming socket stream >> and check the cache somewhere before DNS search - >> this is not the best way for speed (to use a complete internal circle >> instead of Klaus's "internal link") but easy and clear. > That might be OK. I would prefer to see a full-blown implementation at > the start, mainly because I think if we get the 1-document cache going, > nobody will ever bother to do the full one... >>Bela< Right, but I am in another position: my system have well turned Squid so I will not get benefits from lynx cache unless "1-document" only. It is not so hard to clarify the rules for "Visited Links" cache, but takes a time (reading spec, discussion, new bugs, etc. etc.) - this on the logical level, mostly implementation-independent. And "1-document" case is highly lynx-specific. It can be expanded easily if implemented onece. >> > Even the simple 1-document cache has to interact with some caching >> Really? Doesn't it enough to introduce one global flag in mainloop - >> "reload internally" vs "reload as usual"? > The problem is deciding what value to give that flag! For instance, > what should Lynx do if you read a document which expires in 5 hours, > then walk away, come back 6 hours later, and ask for it to render I mean the top history document for "1-document" case, you will not probably look the same document for 6 hours, but cache will be freed every time when you go to another document. (It may only interfere with "Refresh= " directive, but since it is not implemented properly yet - we should not worry about.) But we should care for many-document cache, of cause. > differently? This is not the same as a document which was set to expire > immediately -- Lynx *has* to assume that such a document is going to be > stale some of the time, and let you do what you want. But if it wasn't > stale and now it is, maybe it should reload it. Or maybe not. That has > to be determined. From owner-lynx-dev@sig.net Wed Nov 11 05:38:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA14775 for ; Wed, 11 Nov 1998 05:38:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA00028; Wed, 11 Nov 1998 04:27:13 -0600 (CST) From: dickey@clark.net Message-Id: <199811111029.FAA03514@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 05:29:18 -0500 (EST) In-Reply-To: <199811110445.NAA24684@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 11, 98 01:45:03 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: 1672 Lines: 40 > > don't work. So I don't see how to build it without the GNU gettext stuff. > > (And building _that_, I found one syntax error ;-). > > I think that's what I've been trying to say all along. Bite the bullet > and use GNU make once, and then you'll be through with it. not GNU make. That was a trivial problem. The syntax error was in the gettext source, where it referred to an undefined variable without properly guarding against that. The only makefile problems I ran into were things like the implementor's having constructed the makefile so that it would delete lynx.pot if it was not configured to use the GNU xgettext program. > > > If this is the case, developers may have to come up with different > > > wording for strings to make them unique. > > > > yes - that's a weakness of xgettext. > > I was hoping my understanding was _in_correct. Oh, well, cannot have > everything, I guess. :( I still think it's an improvement over the > include file, though. the other "standard" alternative appears to be catgets, which relies upon unique message identifiers (numbers). From the (biased) descriptions I've read, maintaining the numbers sounds like a labor-intensive activity. -- It's a shame that the GNU gettext isn't compatible with Solaris' version. They imply that it is, but when I _did_ build Lynx with Solaris' library and tried to run it against the message libraries I'd compiled with the GNU gettext, Lynx dumped core in the first call on gettext. (I'll revisit this, but it sounds like the file formats aren't compatible). > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 05:51:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA15696 for ; Wed, 11 Nov 1998 05:51:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA00253; Wed, 11 Nov 1998 04:29:58 -0600 (CST) From: dickey@clark.net Message-Id: <199811111032.FAA04056@shell.clark.net> Subject: Re: lynx-dev How to maintain sources with gettext() ? To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 05:32:01 -0500 (EST) In-Reply-To: <199811110500.OAA24783@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 11, 98 02:00:28 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: 14 > I just spent 30 minutes downloading 27Kb of 2.8.2dev.2 before I gave > up. I have an `at' job which will try at 3 AM. It means I cannot > provide feedback until next week. I'm talking about the tar.bz2. download the diffs and apply those as a patch. This patch is the largest one I've put on the website, and it's still only 15% of the total. Most of the patches are less than 80kb. The archive is 1.6Mb. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 06:21:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA17366 for ; Wed, 11 Nov 1998 06:21:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA02342; Wed, 11 Nov 1998 04:58:53 -0600 (CST) From: Philip Webb Message-Id: <199811111059.FAA00380@chass.utoronto.ca> Subject: Re: lynx-dev Re: lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 05:59:36 -0500 (EST) In-Reply-To: <19981111091243.A5567@uturoa> from "Louis-David Mitterrand" at Nov 11, 98 09:12:43 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: 1290 Lines: 23 981111 Louis-David Mitterrand wrote: > On Tue, Nov 10, 1998 at 09:28:35PM -0500, Philip Webb wrote: >> and 3. because `Jeu de car' isn't French, let alone a translation >> (unless it's some sort of jargon or slang); >> `jeu de cartes' = `card game' (eg bridge), `jeu de mots' = `pun'. >> i haven't been following this thread at all, >> but do know something about some (human) languages, incl French: >> where are you getting the translations from ... ? > "Jeu de car." is correct and is not slang or jargon. > In this case "jeu" means a set which makes a complete collection > and can be treated as a whole. Example: jeu de clefs = set of keys i certainly can't argue, but the `.' after `car' didn't occur in LP's original message: `car' is a conjunction, but never a noun; also, i did check my big Cassells dictionary & found `jeu d'echecs', `jeu de quilles', `jeux d'orgue' & `jeu de voiles', all of which seemed idioms from playing or sailing. there have been cases in the past of very bad WWW machine translations. -- ========================,,============================================ 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 Nov 11 06:22:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA17375 for ; Wed, 11 Nov 1998 06:22:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA03329; Wed, 11 Nov 1998 05:10:02 -0600 (CST) To: lynx-dev@sig.net References: <9811102228.aa19792@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 14:08:04 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev How to maintain sources with gettext() ? 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: 693 Lines: 14 > You know, connectivity keeps getting better and cheaper around the > world. I certainly had less trouble with bandwidth than you when I was > traveling in the former USSR -- using one Soviet-style ISP in Moscow, Well, most in Soviet-style, but several ISP in Moscow run by a highly qualified team - qualified support and no crashes for years. There is a close cooperation between ISP in Moscow for caching, common traffic etc., foreign traffic was expanded by new 34Mbit/s fiber optics channel recently. > then a newfangled "cybercafe" in St. Petersburg and a small-business ISP > in Tallinn. Surely your university will be able to afford decent > connectivity some time soon. >>Bela< From owner-lynx-dev@sig.net Wed Nov 11 06:23:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA17390 for ; Wed, 11 Nov 1998 06:23:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA03346; Wed, 11 Nov 1998 05:10:09 -0600 (CST) To: lynx-dev@sig.net References: <9811102030.aa08653@deepthought.armory.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 13:52:20 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev How to maintain sources with gettext() ? 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: 739 Lines: 17 >> > If the message catalogues are distributed in the source, they can be >> > updated in this manner, and translators can jump in at any time during >> >> Please realize that _each_ .po file is 100Kb+. Ten languages, and >> you've got a 1Mb floppy filled up. > They should compress very well, and two of them side-by-side in an > archive should compress even better; especially with a compressor that > has a large compression window, like `bzip2`. >>Bela< Henry, when the release done the language files may be still open for correction and the ongoing repository should be somewhere at NLS, but while doing development it is more useful to keep things together (unless the developer is a single person and free doing as he want). From owner-lynx-dev@sig.net Wed Nov 11 06:42:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA18470 for ; Wed, 11 Nov 1998 06:42:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04882; Wed, 11 Nov 1998 05:30:02 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 14:22:29 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.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: 480 Lines: 12 > On Wed, 11 Nov 1998, Leonid Pauzner wrote: >> 1) Please rename makefile.in.in and a couple of others with two dots >> to a single extension - impossible to unpack .zip on DOS/WIN > What unzipping program are you using? Info-Zip's "unzip" shouldn't have > problems with this type of file. It is converted to makefile_in.in, or > in 8+3 to makefile.in. > Doug Well, "patch" binary shipped with DJGPP distribution fails to apply dev2 for that files. From owner-lynx-dev@sig.net Wed Nov 11 07:00:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA19556 for ; Wed, 11 Nov 1998 07:00:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA06184; Wed, 11 Nov 1998 05:44:52 -0600 (CST) To: lynx-dev@sig.net References: <199811110228.VAA05185@chass.utoronto.ca> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 14:39:21 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.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: 639 Lines: 21 > 981111 Leonid Pauzner wrote: >> 3) please add my fixes for dev1 (and pre2): 1252&help > while people are adding things, > could you revise the 1-line account of the ^v (tagsoup) keybinding > to be more informative: i suggested a wording. I would rather suggest to add new Options menu section - "Document layout": for HTML parsing - relaxed (tagsoup), strict (sorta sgml) and images - verbose/ no label ([) / add links, something else... > all with the usual (smiles). Feel free to contribute something. As you know I am not the best in english writing > SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca From owner-lynx-dev@sig.net Wed Nov 11 07:13:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA20109 for ; Wed, 11 Nov 1998 07:12:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA07204; Wed, 11 Nov 1998 05:56:15 -0600 (CST) To: lynx-dev@sig.net References: <199811110222.LAA23828@ews07.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Wed, 11 Nov 1998 14:52:39 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev How to maintain sources with gettext() ? 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: 899 Lines: 23 >> Is there any special limitation for code using gettext(), >> e.g. to change english string or just change the line number: > If the English string is changed, i.e., the ``msgid ""'', then > the .po file must be updated. That is why none of the .po files > should be included in the distribution. If they are, then really > it seems to me that the "distributors" are obligated to update > all of them. What a waste of time. The question was another: quick look at .po file show me msg's strings and line numbers in source files, which became out of sync if I change C sources randomly. So few words of comments required for those who do not use translation but want to contribute another lynx code. >> Some docs required. >> Also, the INSTALLATION file should be updated for new config options. > I'll work on it this winter vacation. Anyone is welcome to beat me > to it :-) > __Henry From owner-lynx-dev@sig.net Wed Nov 11 08:01:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA22857 for ; Wed, 11 Nov 1998 08:01:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12887; Wed, 11 Nov 1998 06:51:10 -0600 (CST) From: dickey@clark.net Message-Id: <199811111253.HAA17397@shell.clark.net> Subject: Re: lynx-dev How to maintain sources with gettext() ? To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 07:53:14 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 11, 98 02:52:39 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: 502 Lines: 13 > The question was another: > quick look at .po file show me msg's strings and line numbers in > source files, which became out of sync if I change C sources randomly. > So few words of comments required for those who do not use translation > but want to contribute another lynx code. the line numbers are just part of a comment (and I don't think they're used except by people reading the generated files, for reference). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 08:01:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA22864 for ; Wed, 11 Nov 1998 08:01:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12614; Wed, 11 Nov 1998 06:48:56 -0600 (CST) From: dickey@clark.net Message-Id: <199811111251.HAA17069@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 07:50:59 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 11, 98 02:22:29 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: 679 Lines: 18 > > On Wed, 11 Nov 1998, Leonid Pauzner wrote: > > >> 1) Please rename makefile.in.in and a couple of others with two dots > >> to a single extension - impossible to unpack .zip on DOS/WIN > > > What unzipping program are you using? Info-Zip's "unzip" shouldn't have > > problems with this type of file. It is converted to makefile_in.in, or > > in 8+3 to makefile.in. > > Doug > Well, "patch" binary shipped with DJGPP distribution fails to apply dev2 > for that files. I can rename the file (that's not a big problem). That's what I do for config.hin -> lynx_cfg.h -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 08:33:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA24659 for ; Wed, 11 Nov 1998 08:33:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA16749; Wed, 11 Nov 1998 07:21:28 -0600 (CST) Date: Wed, 11 Nov 1998 08:23:01 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811110823.AA5010@cas.org> Subject: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1556 Lines: 41 Platform: UltraSPARC, Solaris 2.6, Sun c compiler version 4.2 I configured lynx with the following: export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz -L/projects/gnu/sparc-sun-solaris2 .6/lib -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " export CPPFLAGS="-I/ldatae/include -I/projects/gnu/sparc-sun-solaris2.6/include" export CFLAGS="-g" export CC=cc $PWD/configure --prefix=/projects/intranet \ --libdir=/projects/intranet/lib/lynx \ --includedir=/projects/gnu/sparc-sun-solaris2.6/include \ --with-screen=ncurses \ --with-zlib \ --enable-default-colors \ --enable-extended-dtd \ --enable-externs \ --enable-forms-options \ --enable-nsl-fork \ --enable-partial \ --enable-persistent-cookies \ --enable-debug When I do a make, I get: cd /home/lwv26/i/src/Unix/lynx/t/lynx2-8-1/po && rm -f stamp-cat-id && echo time stamp > stamp-cat-id /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o de.mo de.po /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o es.mo es.po /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o fr.mo fr.po /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o it.mo it.po it.po:242: `msgid' and `msgstr' entries do not both end with '\n' found 1 fatal errors Can someone help me fix this? -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 08:43:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA25914 for ; Wed, 11 Nov 1998 08:43:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA18429; Wed, 11 Nov 1998 07:33:37 -0600 (CST) Date: Wed, 11 Nov 1998 08:35:09 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811110835.AA5215@cas.org> Subject: Re: lynx-dev Trouble With Proxy-Server In-Reply-To: of Wed, 11 Nov 1998 04:02:48 +0300 (MSK) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 421 Lines: 8 Re: lynx parsing of hyphens Is this problem a part of the Windows port (which I would assume has to do more monkeying around with the arguments than does the Unix port)? -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 09:05:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA27770 for ; Wed, 11 Nov 1998 09:04:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA21543; Wed, 11 Nov 1998 07:53:09 -0600 (CST) From: dickey@clark.net Message-Id: <199811111355.IAA27952@shell.clark.net> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 08:55:04 -0500 (EST) In-Reply-To: <9811110823.AA5010@cas.org> from "lvirden@cas.org" at Nov 11, 98 08:23:01 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: 1881 Lines: 52 > > Platform: UltraSPARC, Solaris 2.6, Sun c compiler version 4.2 > > I configured lynx with the following: did you install the GNU gettext? (That message isn't from the GNU version) also - add the "--with-included-gettext" option. > export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz -L/projects/gnu/sparc-sun-solaris2 > .6/lib -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " > export CPPFLAGS="-I/ldatae/include -I/projects/gnu/sparc-sun-solaris2.6/include" > export CFLAGS="-g" > export CC=cc > > $PWD/configure --prefix=/projects/intranet \ > --libdir=/projects/intranet/lib/lynx \ > --includedir=/projects/gnu/sparc-sun-solaris2.6/include \ > --with-screen=ncurses \ > --with-zlib \ > --enable-default-colors \ > --enable-extended-dtd \ > --enable-externs \ > --enable-forms-options \ > --enable-nsl-fork \ > --enable-partial \ > --enable-persistent-cookies \ > --enable-debug > > When I do a make, I get: > > cd /home/lwv26/i/src/Unix/lynx/t/lynx2-8-1/po && rm -f stamp-cat-id && echo time > stamp > stamp-cat-id > /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o de.mo de.po > /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o es.mo es.po > /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o fr.mo fr.po > /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o it.mo it.po > it.po:242: `msgid' and `msgstr' entries do not both end with '\n' > found 1 fatal errors > > > Can someone help me fix this? > -- > Larry W. Virden INET: lvirden@cas.org > <*> O- "We are all Kosh." > 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 Wed Nov 11 09:08:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA27859 for ; Wed, 11 Nov 1998 09:08:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA22222; Wed, 11 Nov 1998 07:56:07 -0600 (CST) Date: Wed, 11 Nov 1998 08:57:39 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811110857.AA5624@cas.org> Subject: lynx-dev moving on... To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 493 Lines: 8 Okay, I fixed the it.po problem. The msg certainly didn't come across as meaning "edit po/it.po and add a \n to the last line of the file" but when I did that, I got farther. So I am hopeful now that things might actually completely compile. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 09:19:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA28600 for ; Wed, 11 Nov 1998 09:19:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA25073; Wed, 11 Nov 1998 08:08:29 -0600 (CST) Date: Wed, 11 Nov 1998 09:10:02 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811110910.AA6275@cas.org> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 In-Reply-To: <199811111355.IAA27952@shell.clark.net> of Wed, 11 Nov 1998 08:55:04 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 402 Lines: 6 I do have the gnu gettext installed - however, I've no idea whether lynx's configure is going to find it or not since it's not installed in /usr/local . -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 09:30:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA29573 for ; Wed, 11 Nov 1998 09:30:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27150; Wed, 11 Nov 1998 08:17:25 -0600 (CST) Date: Wed, 11 Nov 1998 09:18:56 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811110918.AA8754@cas.org> Subject: lynx-dev new problems in lynx 2.8.1dev.2 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2639 Lines: 59 Okay, I changed my configure to: export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz -L/projects/gnu/sparc-sun-solaris2 .6/lib -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " export CPPFLAGS="-I/ldatae/include -I/projects/gnu/sparc-sun-solaris2.6/include" export CFLAGS="-g" export CC=cc $PWD/configure --prefix=/projects/intranet \ --libdir=/projects/intranet/lib/lynx \ --includedir=/projects/gnu/sparc-sun-solaris2.6/include \ --with-screen=ncurses \ --with-included-gettext \ --with-catgets \ --with-zlib \ --enable-default-colors \ --enable-extended-dtd \ --enable-externs \ --enable-forms-options \ --enable-nsl-fork \ --enable-partial \ --enable-persistent-cookies \ --enable-debug $ gettext --version gettext (GNU gettext) 0.10.34 Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper. Whereas before I was getting a very simple little error in it.po, now I get: cc -c -DLOCALEDIR=\"/projects/intranet/share/locale\" -DGNULOCALEDIR=\"/projects /intranet/share/locale\" -DLOCALE_ALIAS_PATH=\"/projects/intranet/share/locale:. \" -DHAVE_CONFIG_H -I.. -I. -I/home/lwv26/i/src/Unix/lynx/t/lynx2-8-1/intl -I/ho me/lwv26/i/src/Unix/lynx/t/lynx2-8-1/lib -I/ldatae/include -I/projects/gnu/sparc -sun-solaris2.6/include -g bindtextdom.c "./gettextP.h", line 40: undefined or not a type: inline "./gettextP.h", line 42: warning: function prototype parameters must have types "./gettextP.h", line 42: parameter not in identifier list: SWAP "./gettextP.h", line 42: syntax error before or at: nls_uint32 "./gettextP.h", line 42: parameter not in identifier list: i "./gettextP.h", line 43: syntax error before or at: { "./gettextP.h", line 44: syntax error before or at: & "./gettextP.h", line 44: syntax error before or at: >> "./gettextP.h", line 44: warning: syntax error: empty declaration "./gettextP.h", line 49: warning: dubious struct declaration; use tag only: load ed_domain "./gettextP.h", line 60: warning: dubious struct declaration; use tag only: bind ing followed by a lot more errors. Since I only added those two new lines, I have to assume that they are the problem. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 10:26:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA01586 for ; Wed, 11 Nov 1998 10:26:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA12278; Wed, 11 Nov 1998 09:11:54 -0600 (CST) Message-ID: <19981111150059.13300.rocketmail@send105.yahoomail.com> Date: Wed, 11 Nov 1998 07:00:59 -0800 (PST) From: Alois Maier Subject: Re: Re: lynx-dev Building Problem with Lynx2.8.1 October 24 release To: lynx-dev@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: 988 Lines: 28 >> While building Lynx 2.8.1, the following problem occurred: >> The makefile for the src/chrtrans directory generated by configure does >> not honor the setting of LIBS environment variable. As a consequence, (on >> this particular host) linking of makeuctb fails. > oh. I hadn't thought makeutcb would be a problem since it uses no math, > and uses only the standard C library. What sort of platform is this? It´s AIX 4.3.2 Setting LIBS is required because of unusual library locations. configure ignores LIBS when generating the chrtrans makefile and the generated makefile ignores the LIBS environment variable either. Consequently, the linker uses the wrong library when trying to link makeutcb and linking fails. ( Comments in other makefiles show that similiar things happen in other makefiles with other environment variables ). _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-lynx-dev@sig.net Wed Nov 11 11:28:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA07474 for ; Wed, 11 Nov 1998 11:28:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA00809; Wed, 11 Nov 1998 10:11:34 -0600 (CST) From: dickey@clark.net Message-Id: <199811111612.LAA29277@shell.clark.net> Subject: Re: lynx-dev new problems in lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 11:12:41 -0500 (EST) In-Reply-To: <9811110918.AA8754@cas.org> from "lvirden@cas.org" at Nov 11, 98 09:18: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: 488 Lines: 13 > Whereas before I was getting a very simple little error in it.po, now I get: > cc -c -DLOCALEDIR=\"/projects/intranet/share/locale\" -DGNULOCALEDIR=\"/projects ... > "./gettextP.h", line 40: undefined or not a type: inline I've only built this on Linux and Solars - both with gcc. (I guess I should have expected that they were using gcc extensions). > Larry W. Virden INET: lvirden@cas.org -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 11:34:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08172 for ; Wed, 11 Nov 1998 11:34:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA03176; Wed, 11 Nov 1998 10:19:22 -0600 (CST) From: dickey@clark.net Message-Id: <199811111614.LAA29678@shell.clark.net> Subject: Re: Re: lynx-dev Building Problem with Lynx2.8.1 October 24 release To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 11:14:09 -0500 (EST) In-Reply-To: <19981111150059.13300.rocketmail@send105.yahoomail.com> from "Alois Maier " at Nov 11, 98 07:00:59 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: 1051 Lines: 25 > > > >> While building Lynx 2.8.1, the following problem occurred: > >> The makefile for the src/chrtrans directory generated by configure does > >> not honor the setting of LIBS environment variable. As a consequence, (on > >> this particular host) linking of makeuctb fails. > > > oh. I hadn't thought makeutcb would be a problem since it uses no math, > > and uses only the standard C library. What sort of platform is this? > > It´s AIX 4.3.2 > Setting LIBS is required because of unusual library locations. > configure ignores LIBS when generating the chrtrans makefile and the > generated makefile ignores the LIBS environment variable either. > Consequently, the linker uses the wrong library when trying to link > makeutcb and linking fails. > ( Comments in other makefiles show that similiar things happen in other > makefiles with other environment variables ). ok (I did fix that in the 2.8.2dev.1 patch, which is in the 2.8.1 fixes) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 12:37:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA14280 for ; Wed, 11 Nov 1998 12:37:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA20870; Wed, 11 Nov 1998 11:13:19 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811111715.KAA18764@sanitas> Subject: Re: lynx-dev Trouble With Proxy-Server To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 10:15:02 -0700 (MST) In-Reply-To: <9811110835.AA5215@cas.org> from "Larry W. Virden" at Nov 11, 98 08:35:09 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: 385 Lines: 10 In a recent note, Larry W. Virden said: > Date: Wed, 11 Nov 1998 08:35:09 -0500 (EST) > > Is this problem a part of the Windows port (which I would assume has to > do more monkeying around with the arguments than does the Unix port)? > Whether monkeying around is necessary depends on whether Windows supports article 2.1.2.2.1 of ANSI X3.159-1989 Programming Language - C. -- gil From owner-lynx-dev@sig.net Wed Nov 11 14:13:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA25077 for ; Wed, 11 Nov 1998 14:13:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA15092; Wed, 11 Nov 1998 12:38:40 -0600 (CST) From: mattack@area.com Date: Wed, 11 Nov 1998 10:40:13 -0800 (PST) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev How to maintain sources with gettext() ? In-Reply-To: <199811110500.OAA24783@ews07.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: 583 Lines: 15 On Wed, 11 Nov 1998, Nelson Henry Eric wrote: >Date: Wed, 11 Nov 1998 14:00:28 +0900 (JST) >From: Nelson Henry Eric >Reply-To: lynx-dev@sig.net >To: lynx-dev@sig.net >Subject: Re: lynx-dev How to maintain sources with gettext() ? > >> Sorry, you seem to have misunderstood me. What you put into the other >> message catalogues is "STILL_ENGLISH" followed by the "rest of message", > >"rest of message" speaks for itself. No need for "STILL_ENGLISH". You have "STILL_ENGLISH" so it's easy to grep through the files to find the un-translated strings. From owner-lynx-dev@sig.net Wed Nov 11 14:41:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA28410 for ; Wed, 11 Nov 1998 14:41:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA19393; Wed, 11 Nov 1998 12:56:11 -0600 (CST) Date: Wed, 11 Nov 1998 13:57:43 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811111357.AA12258@cas.org> Subject: lynx-dev Re: gnu-ified lynx 2.8.1dev.2 code To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 462 Lines: 9 Once I deleted the inline keyword from 3 intl/*.c files the software compiled and runs . I still have the ncurses problem on this platform that I've described several times, but other than that things work okay. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 11 16:56:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA10310 for ; Wed, 11 Nov 1998 16:56:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA06836; Wed, 11 Nov 1998 15:40:04 -0600 (CST) Date: Wed, 11 Nov 1998 21:39:44 GMT Message-Id: <199811112139.VAA01781@toucan.phy.bris.ac.uk> To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-URL: file://localhost/usr/freeware/lib/lynx-2.8/lynx_help/lynx-dev.html X-Mailer: Lynx, Version 2.8rel.2 X-Personal_name: Guido Germano From: g.germano@bristol.ac.uk Subject: lynx-dev iris-ansi terminal not supported Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 378 Lines: 8 I'm using lynx for the first time. I'm running IRIX 6.5 on a SGI Indy R4000. I got lynx from the SGI Freeware CD. If I start lynx from a normal IRIX window, whose TERM is by default iris-ansi, the enter key inside lynx does not work! I worked around the problem putting this alias in my .tcshrc, but it's ugly: alias lynx 'sh "TERM=vt320; /usr/freeware/bin/lynx \!*"' Regards From owner-lynx-dev@sig.net Wed Nov 11 18:47:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA22712 for ; Wed, 11 Nov 1998 18:47:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA08725; Wed, 11 Nov 1998 17:32:04 -0600 (CST) Message-Id: <199811112259.OAA07299@scaup.prod.itd.earthlink.net> Date: Wed, 11 Nov 1998 14:46:8 -0800 From: jon To: "lynx-dev@sig.net" Subject: lynx-dev lynx X-mailer: FoxMail 2.1 [en] 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: 327 Lines: 13 i am not much of a computer wizard but do use the internet alot and would like to move faster i cant figure out how to use or compile Lynx2-8-1 PLEASE send me some info on how to use it or maybe an .EXE file of the program i have read the INSTALLATION file but its Greek Please Help THANK YOU twokazy4u@earthlink.net From owner-lynx-dev@sig.net Wed Nov 11 19:57:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01012 for ; Wed, 11 Nov 1998 19:57:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA23019; Wed, 11 Nov 1998 18:43:23 -0600 (CST) Date: Thu, 12 Nov 1998 09:46:41 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811120046.JAA29664@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2309 Lines: 46 > did you install the GNU gettext? (That message isn't from the GNU > version) > > also - add the "--with-included-gettext" option. Since I haven't worked on Solaris yet, I should probably shut up, but my gut feeling is that since you have the GNU gettext package installed, you should use it, and not the one included with Lynx (which personally I could never get to work), i.e., don't use the "--with-included-gettext" option. > > export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz > > -L/projects/gnu/sparc-sun-solaris2 .6/lib > > -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " If you go the route I suggest, then you need to add "-lintl" here, > > export CPPFLAGS="-I/ldatae/include > > -I/projects/gnu/sparc-sun-solaris2.6/include" and the location of the header files for intl here. > > /projects/gnu/sparc-sun-solaris2.6/bin/msgfmt -o it.mo it.po > > it.po:242: `msgid' and `msgstr' entries do not both end with '\n' > > found 1 fatal errors > > > > Can someone help me fix this? Yeah, don't bother with building binaries against language catalogues you're never going to use. First skip the entire build in the /po directory and see if you get a working Lynx. (I assume you want Lynx more than a Barbie doll that speaks Italian.) Then make a FRESH *.po file for the language you want or need. (NONE of the po files in the prototype Jim got together are viable with the current release of Lynx. Why people insist on using them is beyond me. -- the one for French is useful as a source of translations, of course) Compile the file you translated (or files if you speak numerous languages) using the msgfmt that you installed with the GNU gettext package (I suggest using -v). Aim Lynx to where you installed the *.mo file. I recommend using environment variables for that. Since the VAST majority of Lynx users will be happy with an English version, I can't fathom why anyone would want to waste CPU time fiddling around with the installation and maintenance of NLS when it can easily be done separate from Lynx. (CPU= Computer, People, Users). __Henry From owner-lynx-dev@sig.net Wed Nov 11 20:19:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA03627 for ; Wed, 11 Nov 1998 20:19:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA27591; Wed, 11 Nov 1998 19:06:44 -0600 (CST) From: dickey@clark.net Message-Id: <199811120108.UAA04053@shell.clark.net> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 20:08:31 -0500 (EST) In-Reply-To: <199811120046.JAA29664@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 12, 98 09:46:41 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: 756 Lines: 20 > > > did you install the GNU gettext? (That message isn't from the GNU > > version) > > > > also - add the "--with-included-gettext" option. > > Since I haven't worked on Solaris yet, I should probably shut up, > but my gut feeling is that since you have the GNU gettext package > installed, you should use it, and not the one included with Lynx > (which personally I could never get to work), i.e., don't use the > "--with-included-gettext" option. I suppose - as long as you don't pick up the Solaris version by mistake. (You still need the GNU utilities to build with - Lynx only has a library). But I didn't have any trouble building with the included gettext code. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 11 20:22:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA04615 for ; Wed, 11 Nov 1998 20:22:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA28020; Wed, 11 Nov 1998 19:09:08 -0600 (CST) From: Philip Webb Message-Id: <199811120109.UAA03003@chass.utoronto.ca> Subject: Re: lynx-dev lynx To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 20:09:51 -0500 (EST) Cc: twokazy4u@earthlink.net In-Reply-To: <199811112259.OAA07299@scaup.prod.itd.earthlink.net> from "jon" at Nov 11, 98 02:46: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: 774 Lines: 16 981111 Jon wrote: > i cant figure out how to use or compile Lynx2-8-1 > PLEASE send me some info on how to use it > or maybe an .EXE file of the program > i have read the INSTALLATION file but its Greek Greek's easy, but computers do require a tiny bit of effort from you. you can get binaries: start at lynx.browser.org/ & follow the links. if you need more help from the volunteers here, you will have to tell us what sort of system you are using with as much detail as you know or can find out. -- ========================,,============================================ 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 Nov 11 20:30:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA06028 for ; Wed, 11 Nov 1998 20:30:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA29212; Wed, 11 Nov 1998 19:15:30 -0600 (CST) Date: Thu, 12 Nov 1998 10:18:43 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811120118.KAA29938@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 114 Lines: 3 The permission for fr.po seems to have been changed to 444. If so, could it be made 644, or even looser? __Henry From owner-lynx-dev@sig.net Wed Nov 11 20:34:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA06271 for ; Wed, 11 Nov 1998 20:34:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00376; Wed, 11 Nov 1998 19:22:02 -0600 (CST) From: Philip Webb Message-Id: <199811120122.UAA03941@chass.utoronto.ca> Subject: Re: lynx-dev lynx2.8.2dev.2 To: lynx-dev@sig.net Date: Wed, 11 Nov 1998 20:22:45 -0500 (EST) In-Reply-To: from "Leonid Pauzner" at Nov 11, 98 02:39: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: 1248 Lines: 25 981111 Leonid Pauzner wrote: > I would rather suggest to add new Options menu section - "Document layout": > for HTML parsing - relaxed (tagsoup), strict (sorta sgml) > and images - verbose/ no label ([) / add links, something else... sounds like a good idea, but that's a programming task which is probably best left to those who created the Options Form. > As you know I am not the best in english writing you do very well, but documentation in English should be well-written. `the' & `is' are among the first words anglophones learn, but they must present real difficulties for anyone whose first language doesn't contain their equivalents: i remember trying to get a handle on `ests/sests' & `zakryvats/zakryts' when i learned some Russian many years ago: English has nothing similar; ordinarily no-one cares, but in docs you should remember it's `he has'. i got caught today using an 80-year-old dictionary: apparently French idioms have advanced since then ... (grin). -- ========================,,============================================ 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 Nov 11 22:42:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA22463 for ; Wed, 11 Nov 1998 22:42:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23423; Wed, 11 Nov 1998 21:30:47 -0600 (CST) To: lynx-dev@sig.net Path: not-for-mail From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Newsgroups: list.lynx.dev Subject: lynx-dev 2.8.1rel2: attributes broken in UTF-8 display mode Date: 12 Nov 1998 02:54:56 +0100 Message-ID: <72df5g$70h$1@mips.rhein-neckar.de> X-Newsreader: trn 4.0-test67 (15 July 1998) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 742 Lines: 15 Lynx 2.8.1rel2 (tested on FreeBSD) and earlier. This is an old bug. When the display character set is UNICODE (UTF-8), the inline text attributes bold and underline aren't displayed. Only after a link has been selected are its attributes correctly updated. Reverse mode for the currently selected link and the status line works fine. This is easily reproduced on a Unicode terminal; I used the Linux console switched to UTF-8 mode. I also captured the screen output using "script" and verified that indeed no sequences to switch the attributes are sent; it's not a Linux console emulation bug. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de 100+ SF Book Reviews: From owner-lynx-dev@sig.net Wed Nov 11 22:46:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA22513 for ; Wed, 11 Nov 1998 22:46:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA24187; Wed, 11 Nov 1998 21:35:06 -0600 (CST) Date: Thu, 12 Nov 1998 12:38:11 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811120338.MAA08176@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 288 Lines: 8 Two more requests re: intl. Could makefile.in be changed to accept --datadir=, please. Preferably, change "datadir = /usr/local/share" to "datadir = @datadir@". If /po is going to continue to be supported, could we at least get it to act on the environment variable "LINGUAS"? __Henry From owner-lynx-dev@sig.net Thu Nov 12 05:49:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA11160 for ; Thu, 12 Nov 1998 05:49:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA10847; Thu, 12 Nov 1998 04:24:44 -0600 (CST) From: dickey@clark.net Message-Id: <199811121026.FAA20511@shell.clark.net> Subject: Re: lynx-dev protection 444 for fr.po To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 05:26:49 -0500 (EST) In-Reply-To: <199811120118.KAA29938@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 12, 98 10:18: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: 499 Lines: 16 > > The permission for fr.po seems to have been changed to 444. If so, > could it be made 644, or even looser? probably. (PRCS records the last permissions of the file when it was checked-in -- I expect there'll be more than one patch to fr.po, and I'll remember to fix the permissions...) -- I keep files readonly as a matter of habit (makefile rules should work with that, otherwise it's an error too). > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 05:59:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA12090 for ; Thu, 12 Nov 1998 05:59:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11572; Thu, 12 Nov 1998 04:34:13 -0600 (CST) From: dickey@clark.net Message-Id: <199811121036.FAA21355@shell.clark.net> Subject: Re: lynx-dev iris-ansi terminal not supported To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 05:36:19 -0500 (EST) In-Reply-To: <199811112139.VAA01781@toucan.phy.bris.ac.uk> from "g.germano@bristol.ac.uk" at Nov 11, 98 09:39:44 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: 1259 Lines: 31 > > I'm using lynx for the first time. I'm running IRIX 6.5 on a SGI Indy > R4000. I got lynx from the SGI Freeware CD. If I start lynx from a > normal IRIX window, whose TERM is by default iris-ansi, the enter key > inside lynx does not work! I worked around the problem putting this > alias in my .tcshrc, but it's ugly: > > alias lynx 'sh "TERM=vt320; /usr/freeware/bin/lynx \!*"' there's more than one factor - determining which is the underlying problem will require some work: + The 'iris-ansi' description specifies 'kent=^M', which is probably what you are talking about. The IRIX 'vt320' does not specify kent (enter-key). + 'kent' is a little ambiguous - depending on who wrote the description, it may mean either the key on the main part of the keyboard, or the key on most keypads. The latter is (in keypad application mode) a control sequence. + The xwsh emulator (what I assume you're talking about) is a quasi- vt100 emulator (not really compatible). It can be run in either IRIS or VT100 emulation modes. So I need some more clarification. (If I know what I'm looking for, I can do limited testing on that system). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 07:14:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA19897 for ; Thu, 12 Nov 1998 07:14:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA19339; Thu, 12 Nov 1998 06:00:11 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Thu, 12 Nov 1998 14:58:35 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev -help and -restrictions should be gettext()'ed also 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: 80 Lines: 3 in LYMain.c, command line help should be gettext'ed for possible translation. From owner-lynx-dev@sig.net Thu Nov 12 08:08:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA26942 for ; Thu, 12 Nov 1998 08:08:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA24622; Thu, 12 Nov 1998 06:50:37 -0600 (CST) Date: Thu, 12 Nov 1998 14:41:47 +0200 (EET) From: VictorAs To: lynx-dev@sig.net Subject: lynx-dev A question about downloading in 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: 365 Lines: 9 I have a problem when i download tgz files.... I want to mail that files(ostream*) but i cant, in my lynx version exist only save to a file, but i have a quota on my server and i cant download files biger than 1.5 Mbytes... Can i configure my lynx to mail that kind of files to an specific e-mail address? If i can please tell me how... Thanks... Victor From owner-lynx-dev@sig.net Thu Nov 12 08:16:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA28989 for ; Thu, 12 Nov 1998 08:16:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA25728; Thu, 12 Nov 1998 06:59:19 -0600 (CST) Date: Thu, 12 Nov 1998 13:57:06 +0200 Message-Id: <98111213570651@decus.fr> From: soma_c@decus.fr (Claude SOMA - CNTS) To: lynx-dev@sig.net Subject: Re: lynx-dev new problems in lynx 2.8.1dev.2 X-VMS-To: SMTP%"lynx-dev@sig.net" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 234 Lines: 5 > "./gettextP.h", line 40: undefined or not a type: inline I have build on ultrix and DU some remarks are in http://www.flora.org/lynx-dev/html/month0998/msg00601.html ----------------------------------------------------2----- Claude From owner-lynx-dev@sig.net Thu Nov 12 08:33:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA32260 for ; Thu, 12 Nov 1998 08:33:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA28247; Thu, 12 Nov 1998 07:16:41 -0600 (CST) Date: Thu, 12 Nov 1998 08:18:15 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811120818.AA22471@cas.org> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 In-Reply-To: <199811120046.JAA29664@ews07.nara.kindai.ac.jp> of Thu, 12 Nov 1998 09:46:41 +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: 1280 Lines: 26 From: Nelson Henry Eric > Yeah, don't bother with building binaries against language catalogues > you're never going to use. First skip the entire build in the /po > directory and see if you get a working Lynx. (I assume you want Lynx You mean - go into the Makefiles and figure out how to skip that part. As far as I can tell, there isn't a make option to 'build lynx and skip the po directory'. > Why people insist on using them is beyond me. -- the one for French is Because the makefile generated by configure uses them - all we want to do is to type "configure ; make install install-help install-doc" and have working code appear. > Since the VAST majority of Lynx users will be happy with an English > version, I can't fathom why anyone would want to waste CPU time fiddling > around with the installation and maintenance of NLS when it can easily > be done separate from Lynx. (CPU= Computer, People, Users). Because other software wants/needs NLS and so it is build and maintained. -- Larry W. Virden INET: lvirden@cas.org <*> O- "We are all Kosh." 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 Nov 12 09:08:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA06597 for ; Thu, 12 Nov 1998 09:08:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA04615; Thu, 12 Nov 1998 07:55:44 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 12 Nov 1998 16:48:17 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev A question about downloading 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: 574 Lines: 15 > I have a problem when i download tgz files.... > I want to mail that files(ostream*) but i cant, in my lynx version exist > only save to a file, but i have a quota on my server and i cant download > files biger than 1.5 Mbytes... > Can i configure my lynx to mail that kind of files to an specific e-mail No, only text files can be e-mailed currently (From 'P'rint menu). > address? > If i can please tell me how... Try reading lynx.cfg about DOWNLOADER: probably Zmodem or ftp may be your case. > Thanks... > Victor From owner-lynx-dev@sig.net Thu Nov 12 09:09:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA06608 for ; Thu, 12 Nov 1998 09:09:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA04534; Thu, 12 Nov 1998 07:55:16 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Thu, 12 Nov 1998 15:12:59 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev gettext() 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: 390 Lines: 8 Does "intl" programs allow to switch language back to english on startup? I mean we can fall into the bug reports from people using different translations of fatal/status messages we cannot easily understand, so Lynx need -english command line switch for that purpose. Also some users may be not satisfied with the translation quality and want switching back to english for that reason. From owner-lynx-dev@sig.net Thu Nov 12 10:54:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA22999 for ; Thu, 12 Nov 1998 10:54:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA03224; Thu, 12 Nov 1998 09:38:27 -0600 (CST) Date: Thu, 12 Nov 1998 17:35:41 +0200 (EET) From: VictorAs To: lynx-dev@sig.net Subject: Re: lynx-dev A question about downloading in lynx.... 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: 845 Lines: 25 On Thu, 12 Nov 1998, Leonid Pauzner wrote: :-) >> I have a problem when i download tgz files.... :-) >> I want to mail that files(ostream*) but i cant, in my lynx version exist :-) >> only save to a file, but i have a quota on my server and i cant download :-) >> files biger than 1.5 Mbytes... :-) >> Can i configure my lynx to mail that kind of files to an specific e-mail :-) >No, only text files can be e-mailed currently (From 'P'rint menu). :-) > :-) >> address? :-) >> If i can please tell me how... :-) >Try reading lynx.cfg about DOWNLOADER: :-) >probably Zmodem or ftp may be your case. :-) > :-) >> Thanks... :-) >> Victor :-) > Yes but i want to configure it to can mail the files, can anyone tell me exact what to do? :-) Thanks, Victor. :-) > :-) > From owner-lynx-dev@sig.net Thu Nov 12 11:34:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA29560 for ; Thu, 12 Nov 1998 11:34:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14738; Thu, 12 Nov 1998 10:12:30 -0600 (CST) Date: Thu, 12 Nov 1998 13:13:47 -0300 (ARST) From: Cesar Ballardini X-Sender: cballard@nita.sfe.epesf To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question 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: 570 Lines: 17 On Thu, 12 Nov 1998, Leonid Pauzner wrote: > Does "intl" programs allow to switch language back to english on startup? > > I mean we can fall into the bug reports from people using different > translations of fatal/status messages we cannot easily understand, > so Lynx need -english command line switch for that purpose. > Also some users may be not satisfied with the translation quality > and want switching back to english for that reason. As long as I know, the LANG variable is all you need to set to the language of your choice. Cheers. --- Cesar Ballardini From owner-lynx-dev@sig.net Thu Nov 12 15:51:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA24219 for ; Thu, 12 Nov 1998 15:51:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA03904; Thu, 12 Nov 1998 14:32:42 -0600 (CST) Message-ID: <19981112213436.B12193@mema.ucl.ac.be> Date: Thu, 12 Nov 1998 21:34:36 +0100 From: Serge MUNHOVEN To: lynx-dev@sig.net Subject: Re: lynx-dev A question about downloading in lynx.... References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.93.2i In-Reply-To: ; from VictorAs on Thu, Nov 12, 1998 at 05:35:41PM +0200 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.flora.ottawa.on.ca id PAA24219 Status: RO Content-Length: 2166 Lines: 47 On Thu, Nov 12, 1998 at 05:35:41PM +0200, VictorAs wrote: > On Thu, 12 Nov 1998, Leonid Pauzner wrote: > > :-) >> I have a problem when i download tgz files.... > :-) >> I want to mail that files(ostream*) but i cant, in my lynx version exist > :-) >> only save to a file, but i have a quota on my server and i cant download > :-) >> files biger than 1.5 Mbytes... > :-) >> Can i configure my lynx to mail that kind of files to an specific e-mail > :-) >No, only text files can be e-mailed currently (From 'P'rint menu). > :-) > > :-) >> address? > :-) >> If i can please tell me how... > :-) >Try reading lynx.cfg about DOWNLOADER: > :-) >probably Zmodem or ftp may be your case. > :-) > > :-) >> Thanks... > :-) >> Victor > :-) > > Yes but i want to configure it to can mail the files, can > anyone tell me exact what to do? > :-) Thanks, > Victor. > :-) > > :-) > > But once you get to the DOWNLOADER menu, you have already transferred the complete big file to your local host, as far as I understand. Lynx stores them in some place (/var/tmp in my case) and "Save to disk" (and other DOWNLOADERs) actually act on that temporary file. Note that "Save to disk" *copies* the file, which doubles the required diskquotas if the temporary file also eats on them. It may be possible to circumvent this by defining an entry that rather *moves* the file to its final location (depending on how the system's "move" works). Anyway, I wonder if many mailers allow you to send a stream of incoming data rather than a complete existing local file (any expert opinion ?). In addition your binary data will have to be encoded for standard mail transport (8bit cleaness is not guaranteed). Guess the mailer will again help itself with an even larger temporary file ... As to an actual DOWNLOADER entry to mail the file, it heavily depends on your system, especially your mailer's capability and flags to encode and attach files. - Serge PS: "Jeu de car." abbreviated for "Jeu de caractères" - "Character set". (Yes, I know French better than C). From owner-lynx-dev@sig.net Thu Nov 12 15:51:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA24252 for ; Thu, 12 Nov 1998 15:51:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA04625; Thu, 12 Nov 1998 14:35:13 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Thu, 12 Nov 1998 20:22:41 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev A question about downloading 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: 774 Lines: 19 :-) >>> I have a problem when i download tgz files.... :-) >>> I want to mail that files(ostream*) but i cant, in my lynx version exist :-) >>> only save to a file, but i have a quota on my server and i cant download :-) >>> files biger than 1.5 Mbytes... > Yes but i want to configure it to can mail the files, can > anyone tell me exact what to do? > :-) Thanks, > Victor. Look files under src/ tree: LYPrint.c ("case MAIL:" for example of print-to-email, just the idea), LYDownload.c HTFWrite.c (one you plan to change) I hope it is assumed as uuencoded attached file. BTW, you need probably use pipe instead of temp files while doing uuencode etc., because temp file will also waste your disk quota (for a moment). From owner-lynx-dev@sig.net Thu Nov 12 17:43:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA31922 for ; Thu, 12 Nov 1998 17:43:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA07412; Thu, 12 Nov 1998 16:21:04 -0600 (CST) From: dickey@clark.net Message-Id: <199811122222.RAA13966@shell.clark.net> Subject: Re: lynx-dev A question about downloading in lynx.... To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 17:22:37 -0500 (EST) In-Reply-To: <19981112213436.B12193@mema.ucl.ac.be> from "Serge MUNHOVEN " at Nov 12, 98 09:34: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: 1804 Lines: 39 > But once you get to the DOWNLOADER menu, you have already transferred the > complete big file to your local host, as far as I understand. Lynx stores > them in some place (/var/tmp in my case) and "Save to disk" (and other > DOWNLOADERs) actually act on that temporary file. Note that "Save to disk" > *copies* the file, which doubles the required diskquotas if the temporary > file also eats on them. It may be possible to circumvent this by defining an > entry that rather *moves* the file to its final location (depending on how > the system's "move" works). moves, or simply passes the downloaded tmp-file via a pipe as LP suggests. > Anyway, I wonder if many mailers allow you to send a stream of incoming data > rather than a complete existing local file (any expert opinion ?). In addition mutt and elm do, as well as the various mail/mailx/etc. I guess pine does. any others (unix of course)? > your binary data will have to be encoded for standard mail transport (8bit > cleaness is not guaranteed). Guess the mailer will again help itself with an > even larger temporary file ... > > As to an actual DOWNLOADER entry to mail the file, it heavily depends on your > system, especially your mailer's capability and flags to encode and attach > files. you can uuencode to standard output. wouldn't take much of a script to pick up a file, prepend some descriptive text and pipe the whole to the mailer w/o any temporary files. > - Serge > > PS: "Jeu de car." abbreviated for "Jeu de caractères" - "Character set". > (Yes, I know French better than C). I had 3 years of French in high school, but that was before Unix was designed. So I'll leave translation to people who speak the language. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 19:08:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA04914 for ; Thu, 12 Nov 1998 19:08:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA05023; Thu, 12 Nov 1998 17:47:54 -0600 (CST) Message-ID: <19981113004956.A17608@mema.ucl.ac.be> Date: Fri, 13 Nov 1998 00:49:56 +0100 From: Serge MUNHOVEN To: lynx-dev@sig.net Subject: Re: lynx-dev A question about downloading in lynx.... References: <19981112213436.B12193@mema.ucl.ac.be> <199811122222.RAA13966@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811122222.RAA13966@shell.clark.net>; from dickey@clark.net on Thu, Nov 12, 1998 at 05:22:37PM -0500 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2475 Lines: 55 On Thu, Nov 12, 1998 at 05:22:37PM -0500, dickey@clark.net wrote: >> *copies* the file, which doubles the required diskquotas if the temporary >> file also eats on them. It may be possible to circumvent this by defining an >> entry that rather *moves* the file to its final location (depending on how >> the system's "move" works). > moves, or simply passes the downloaded tmp-file via a pipe as LP suggests. ? Don't some weird systems move by copying & deleting ? This happens anyway when you move between filesystems (though they probably won't share quota). > >> Anyway, I wonder if many mailers allow you to send a stream of incoming data >> rather than a complete existing local file (any expert opinion ?). In addition > > mutt and elm do, as well as the various mail/mailx/etc. I guess pine does. > any others (unix of course)? I knew about piping to mail/mailx/mutt (unix of course ...), but my question was about, e.g.: % cat bin.data | mutt -a - -: unable to attach file. Thought I could be too lazy to add another pipe, for uuencode'ing :-) > you can uuencode to standard output. wouldn't take much of a script > to pick up a file, prepend some descriptive text and pipe the whole Sure, no problem for me either, but on the system I know. > to the mailer w/o any temporary files. I would not have bet, since I even managed to fill a filesystem using a named pipe (though not the one the pipe was on; don't know enough about how those beings are actually implemented). My advice in the present case, after mailing myself an 9MB file for fun: use mail/mailx for that kind of joke ... % uuencode USER_GDE.PS2 USER_GDE.PS2 | wc -c 12285521 % uuencode USER_GDE.PS2 USER_GDE.PS2 | mutt munhoven [and keep an eye on /tmp; that's why 9MB; keep it buzy a moment] % ls -l /tmp -rw------- 1 munhoven system 12285521 Nov 12 23:56 mutt-cezanne-16633-0 -rw------- 1 munhoven system 12285787 Nov 12 23:56 mutt-cezanne-16633-1 -rw------- 1 munhoven system 12285521 Nov 12 23:56 mutt-cezanne-16633-2 Oops. With another file of similar size in /var/spool/mqueue, but that one belongs to root :-) In any case will the file be completely downloaded before being eventually piped to mail. lynx is simply not the most appropriate tool to solve the problem described. Perhaps rather: % wget -O - http://dummy.site/very.big.tgz | mailx user@large.mail.box would do it on my system (but on the original request system ?). - Serge From owner-lynx-dev@sig.net Thu Nov 12 19:14:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA05294 for ; Thu, 12 Nov 1998 19:14:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA09637; Thu, 12 Nov 1998 18:00:30 -0600 (CST) Date: Fri, 13 Nov 1998 09:03:54 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130003.JAA04821@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1000 Lines: 21 > You mean - go into the Makefiles and figure out how to skip that part. > As far as I can tell, there isn't a make option to 'build lynx and skip No option yet. If Tom insists on keeping the /intl and /po directories then in time he plans to get around to supporting the configure script to handle the builds in those directories correctly. > Because the makefile generated by configure uses them - all we want to do > is to type "configure ; make install install-help install-doc" and have This is a problem with the present configure script. > > Since the VAST majority of Lynx users will be happy with an English > > version, I can't fathom why anyone would want to waste CPU time fiddling > > around with the installation and maintenance of NLS when it can easily > > be done separate from Lynx. (CPU= Computer, People, Users). > > Because other software wants/needs NLS and so it is build and maintained. ^^^^^ Exactly! NLS has its own debugging and maintenance team. __Henry From owner-lynx-dev@sig.net Thu Nov 12 19:21:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA05986 for ; Thu, 12 Nov 1998 19:21:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA10407; Thu, 12 Nov 1998 18:02:41 -0600 (CST) Date: Fri, 13 Nov 1998 09:06:09 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130006.JAA04849@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 216 Lines: 5 > Does "intl" programs allow to switch language back to english on startup? Just don't install a lynx.mo file and you'll get the defaults. Gettext falls back to the msgid if it can't find another catalogue. __Henry From owner-lynx-dev@sig.net Thu Nov 12 19:27:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA06289 for ; Thu, 12 Nov 1998 19:27:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA07329; Thu, 12 Nov 1998 17:54:09 -0600 (CST) Date: Fri, 13 Nov 1998 08:57:34 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811122357.IAA04733@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 146 Lines: 4 > checked-in -- I expect there'll be more than one patch to fr.po, and I should certainly hope not to the one in the Lynx distribution. __Henry From owner-lynx-dev@sig.net Thu Nov 12 19:37:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA06928 for ; Thu, 12 Nov 1998 19:37:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA18142; Thu, 12 Nov 1998 18:24:02 -0600 (CST) From: dickey@clark.net Message-Id: <199811130025.TAA22416@shell.clark.net> Subject: Re: lynx-dev A question about downloading in lynx.... To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 19:25:49 -0500 (EST) In-Reply-To: <19981113004956.A17608@mema.ucl.ac.be> from "Serge MUNHOVEN " at Nov 13, 98 00:49: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: 2836 Lines: 63 > Don't some weird systems move by copying & deleting ? This happens anyway when > you move between filesystems (though they probably won't share quota). most unix ones do moves within the same filesystem by hardlinks - but of course moves across filesystems require coping. (VMS has an analogous concept to hardlinking, since files are entered into directory files - but doesn't exploit it). Someone on this list mentioned that win32 can rename across filesystems; I see that POSIX permits that. (But it would require copying at some level - right?). > >> Anyway, I wonder if many mailers allow you to send a stream of incoming data > >> rather than a complete existing local file (any expert opinion ?). In addition > > > > mutt and elm do, as well as the various mail/mailx/etc. I guess pine does. > > any others (unix of course)? > > I knew about piping to mail/mailx/mutt (unix of course ...), but my question > was about, e.g.: > > % cat bin.data | mutt -a - > -: unable to attach file. > > Thought I could be too lazy to add another pipe, for uuencode'ing :-) I guess so - I mostly pipe whole files at mailers to send people directory listings and stuff like that where I don't need to combine things. > > you can uuencode to standard output. wouldn't take much of a script > > to pick up a file, prepend some descriptive text and pipe the whole > Sure, no problem for me either, but on the system I know. > > to the mailer w/o any temporary files. > I would not have bet, since I even managed to fill a filesystem using a named > pipe (though not the one the pipe was on; don't know enough about how those > beings are actually implemented). My advice in the present case, after mailing > myself an 9MB file for fun: use mail/mailx for that kind of joke ... > > % uuencode USER_GDE.PS2 USER_GDE.PS2 | wc -c > 12285521 > % uuencode USER_GDE.PS2 USER_GDE.PS2 | mutt munhoven > [and keep an eye on /tmp; that's why 9MB; keep it buzy a moment] > % ls -l /tmp > -rw------- 1 munhoven system 12285521 Nov 12 23:56 mutt-cezanne-16633-0 > -rw------- 1 munhoven system 12285787 Nov 12 23:56 mutt-cezanne-16633-1 > -rw------- 1 munhoven system 12285521 Nov 12 23:56 mutt-cezanne-16633-2 ugh. There's no good reason for uuencode to buffer via a file, since it doesn't require multiple passes. > Oops. With another file of similar size in /var/spool/mqueue, but that one > belongs to root :-) ( that's root's quota ;-) > In any case will the file be completely downloaded before being eventually > piped to mail. lynx is simply not the most appropriate tool to solve the > problem described. Perhaps rather: yes - Lynx downloads the file completely before doing anything with it. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 19:47:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA07524 for ; Thu, 12 Nov 1998 19:47:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA19437; Thu, 12 Nov 1998 18:27:40 -0600 (CST) From: dickey@clark.net Message-Id: <199811130029.TAA22882@shell.clark.net> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 19:29:09 -0500 (EST) In-Reply-To: <199811130003.JAA04821@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 13, 98 09:03: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: 761 Lines: 18 > > > You mean - go into the Makefiles and figure out how to skip that part. > > As far as I can tell, there isn't a make option to 'build lynx and skip > > No option yet. If Tom insists on keeping the /intl and /po directories > then in time he plans to get around to supporting the configure script > to handle the builds in those directories correctly. I intend making it an add-on, so the configure script will be able to first check if the directories are there before doing anything with them, and further, to make it pick up the list of .po files so we don't have to embed that in the sources. (I do remember commenting that it would take more than one patch to do this) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 19:56:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA08137 for ; Thu, 12 Nov 1998 19:56:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA24325; Thu, 12 Nov 1998 18:41:14 -0600 (CST) From: dickey@clark.net Message-Id: <199811130043.TAA25101@shell.clark.net> Subject: Re: lynx-dev protection 444 for fr.po To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 19:43:08 -0500 (EST) In-Reply-To: <199811122357.IAA04733@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 13, 98 08:57:34 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: 519 Lines: 17 > > > checked-in -- I expect there'll be more than one patch to fr.po, and > > I should certainly hope not to the one in the Lynx distribution. actually yes. There shouldn't be any html in the msgid's. It'll just create a lot of maintenance problems. I reorganized a fair number of the strings in the C code to work around this, but there's more. It should be stable by the end of the month, but it's certainly not done now. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 20:01:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA08449 for ; Thu, 12 Nov 1998 20:01:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA27039; Thu, 12 Nov 1998 18:50:00 -0600 (CST) Date: Thu, 12 Nov 1998 19:51:34 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811121951.AA28019@cas.org> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 In-Reply-To: <199811130029.TAA22882@shell.clark.net> of Thu, 12 Nov 1998 19:29:09 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 726 Lines: 16 Tom, I just want to say that I REALLY appreciate all you have contributed to Lynx . People can only get a glimmer of all the pain that's involved in trying to coordinate a software project - let alone the several that you handle. Thank you so much for all of your help. I am sorry if my bug reports are not satisfactory at times. Sometimes the reports are tough to generate - other times, I just flat out blow it. Hopefully _some_ are relatively useful. -- 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 Nov 12 20:06:13 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA08719 for ; Thu, 12 Nov 1998 20:06:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA27364; Thu, 12 Nov 1998 18:50:58 -0600 (CST) Date: Thu, 12 Nov 1998 19:52:33 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811121952.AA28044@cas.org> Subject: lynx-dev NEWS: A call to arms in court To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2262 Lines: 47 Posted at 6:34 a.m. PST Thursday, November 12, 1998 Blind man wants better cyberspace access SAN FRANCISCO (AP) -- A blind man says his inability to access Web sites violates the Americans With Disabilities Act. Randy Tamez, who was blinded 12 years ago by treatment for a brain tumor, has filed a formal complaint against the Metropolitan Transportation Commission. The commission oversees nine Bay Area counties' mass transit systems. Tamez, 36, who sees only shapes, shadows and light, says his inability to access the site's documents, including bus and train schedules, violates the Americans With Disabilities Act, passed by Congress in 1990. It's one of the first formal complaints filed against a Web site, according to Cynthia Waddell, the city of San Jose's ADA coordinator. As more and more sensory impaired users go on-line, the more barriers they find in front of them, the biggest of which is the World Wide Web. And as Web sites fill with pictures, video clips and sound, text becomes a secondary concern to on-line designers. But text drives the technology, especially screen readers, that allows a sight- or hearing-disabled person to use the Web. ``The on-line world was friendly when it was a text-based medium,'' said Waddell, San Jose ADA coordinator, who is deaf. ``But as it has rapidly grown to a robust multimedia environment, it has erected new barriers that were never there before.'' Tamez's recently filed a complaint against the MTC as part of a growing mound of paperwork that is steering ADA regulations toward the Web. Two other formal complaints, filed against San Francisco and Washington this year, allege those cities failed to make public touch-screen computer kiosks compliant with hearing- and vision-impaired users. Both cities have promised to enact guidelines and training to bring the kiosks in compliance with the ADA. -- 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 Nov 12 20:20:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA09700 for ; Thu, 12 Nov 1998 20:20:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA02867; Thu, 12 Nov 1998 19:07:39 -0600 (CST) Message-Id: <199811130108.TAA06474@thune.mrc.org> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 19:08:50 -0600 (CST) In-Reply-To: <199811130029.TAA22882@shell.clark.net> from "dickey@clark.net" at Nov 12, 98 07:29:09 pm From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 927 Lines: 21 Amazingly enough dickey@clark.net said: > I intend making it an add-on, so the configure script will be able to > first check if the directories are there before doing anything with them, > and further, to make it pick up the list of .po files so we don't have > to embed that in the sources. Out of curiosity, any clue how this will be done? The only package I know of that uses configure and add-ons is egcs, and the command line switch to configure is "--enable-add-ons=item1,item2,...,itemN" Is the "--enable-add-ons" a standard configure thing or just an egcs thing? If not a standard configure thing, what do other packages do? mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Thu Nov 12 21:14:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA12758 for ; Thu, 12 Nov 1998 21:14:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA20400; Thu, 12 Nov 1998 20:00:07 -0600 (CST) To: lynx-dev@sig.net References: <199811112239.BAA20821@ns.mccme.ru> Message-Id: From: "Leonid Pauzner" Date: Fri, 13 Nov 1998 04:59:10 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 2276 Lines: 52 While BL made his attempt to analize 59 lynx-dev messages for lynx internal cache pro at contra, I spent few hours to analize HTTP 1.1 spec for caching rules. I think my previous words for "1-document" cache are mistaken, now I feel the picture as follows. Lynx internal cache for HTML sources: ===================================== 1) Every document should be cached except local (which always available). Use them for internal needs (*, [, \, etc) immediately without any checks, the flag may be enabled in HTuncache_current_document(). (well, we store several latest documents only, because of space limitations...) 2) Let we have cached data (enough space, not delete entry yet), when use it for remote calls? Do not use cache for any method other than http/https "GET" Do not use cache if the origin document was incomplete (?) Use cache - always validate cached data (see Note3): use Last-Modified and ETag value from the previous request - add If-Modified-Since: and If-None-Match: to GET request, send protocol version as "HTTP/1.1" If we got 304 (not Modified) status - use cached data, but update header fields from this new responce. If we got 200 (OK) status - do as usual but do not forget to pick it up to the cache, with the flag for user interruption if any happen. If we got other status - do as usual and NOTHING for cache in any case. Note1: If we have only Last-Modified data and the origin server was HTTP1.0 we should have a possibility to avoid sending this string. (http-v11-spec) Note2: We probably need sending "HTTP/1.1" for any request and any method (to not confise the server ?), does we lost something from HTTP 1.1 client features ourself? Note3: According to http-v11-spec, the documents which became stale because of expire, cache-control: no-cache, cache-control: max-age=... should not be reloaded completely. Instead, they should be revalidated with the remote server as we explain above. There is an expiration model described in sections 13.2 and 14.9 of the docs which allows sending documents without revalidation with the remote server for documents that are not staled yet - we do not use it for now. There may be also security considerations if we want a persistent cache. Leonid. From owner-lynx-dev@sig.net Thu Nov 12 21:35:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA14043 for ; Thu, 12 Nov 1998 21:35:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA27581; Thu, 12 Nov 1998 20:23:31 -0600 (CST) Date: Fri, 13 Nov 1998 11:26:18 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130226.LAA05697@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1269 Lines: 23 > > > checked-in -- I expect there'll be more than one patch to fr.po, and > > > > I should certainly hope not to the one in the Lynx distribution. > > actually yes. There shouldn't be any html in the msgid's. It'll just > create a lot of maintenance problems. I reorganized a fair number of > the strings in the C code to work around this, but there's more. It I still don't understand why you feel the need to maintain fr.po unless you just enjoy doing it. Anyway, I assume you know about the -j option to xgettext. It would also make the file a bit smaller if you'd use the --no-location option. Since you plan on supporting the build in /po, you might consider adding the --no-location option as a default. I did find that I lost about half of the 400+ translated strings I had done on Jim's code set when I updated to dev2. I hope to be able to salvage them, but it might mean hand editing. (Moan.) If I figure out what triggered the loss, I'll let you know. I hadn't worked on any strings with html tags in them, so that wasn't it. Did you switch locations of "%s" or "%d" in places? There were a few strings with trailing white space. Are these all going to be revised to strip it off? (If so, I'll put off translating those, too.) __Henry From owner-lynx-dev@sig.net Thu Nov 12 21:45:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA14708 for ; Thu, 12 Nov 1998 21:45:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA01205; Thu, 12 Nov 1998 20:35:07 -0600 (CST) To: lynx-dev@sig.net References: <199811130006.JAA04849@ews07.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Fri, 13 Nov 1998 05:12:17 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev gettext() 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: 441 Lines: 14 >> Does "intl" programs allow to switch language back to english on startup? > Just don't install a lynx.mo file and you'll get the defaults. > Gettext falls back to the msgid if it can't find another catalogue. At compile time or when the binary already installed? If it's at run-time, lynx should certainly have a command-line switch -english for person like me who cannot guess (undocumented) features I am not using at. > __Henry From owner-lynx-dev@sig.net Thu Nov 12 21:45:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA14718 for ; Thu, 12 Nov 1998 21:45:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA01237; Thu, 12 Nov 1998 20:35:09 -0600 (CST) To: lynx-dev@sig.net References: <199811122222.RAA13966@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Fri, 13 Nov 1998 05:21:04 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev A question about downloading 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: 485 Lines: 10 >> Anyway, I wonder if many mailers allow you to send a stream of incoming data >> rather than a complete existing local file (any expert opinion ?). In addition > mutt and elm do, as well as the various mail/mailx/etc. I guess pine does. > any others (unix of course)? I guess 2Mb+ letters (1.5Mb zip uuencoded) fails on any SMTP mailer or even crash the system. You should split it for several parts and than rebuild on receiving to avoid conflict with system administrator :-( From owner-lynx-dev@sig.net Thu Nov 12 22:11:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA17575 for ; Thu, 12 Nov 1998 22:11:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA07609; Thu, 12 Nov 1998 20:57:22 -0600 (CST) From: dickey@clark.net Message-Id: <199811130259.VAA28879@shell.clark.net> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 21:59:27 -0500 (EST) In-Reply-To: <9811121951.AA28019@cas.org> from "lvirden@cas.org" at Nov 12, 98 07:51: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: 1515 Lines: 31 > > Tom, I just want to say that I REALLY appreciate all you have contributed > to Lynx . People can only get a glimmer of all the pain that's involved > in trying to coordinate a software project - let alone the several that > you handle. > > Thank you so much for all of your help. > > I am sorry if my bug reports are not satisfactory at times. Sometimes > the reports are tough to generate - other times, I just flat out blow > it. Hopefully _some_ are relatively useful. no problem (you don't see the bugs that keep me busy - reproducing and analyzing some take quite a while). so I'm well aware that some things that I've gotten used to (like the different versions of 'patch') are stumbling blocks. and others (perhaps your display problem with ncurses) may be a bug that I've simply not encountered the right conditions to reproduce it for myself. for example, I noticed a bug in xterm a couple of weeks ago, while demo'ing it (under some circumstances there's a cursor dropping). it seemed intermittent, but I could reproduce it - only on the first time through a particular program. but I was working on a change to xterm, and found a way to reproduce it reliably (by simply changing the way I ran my testing ;-). once I saw _that_, I traced back and found the bug's been there for at least two years. no one reported it, and I didn't see it myself until two weeks ago. (Now all I have to do is to fix it...) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 22:21:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA18353 for ; Thu, 12 Nov 1998 22:21:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA10930; Thu, 12 Nov 1998 21:09:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811130311.WAA04495@shell.clark.net> Subject: Re: lynx-dev problems building lynx 2.8.1dev.2 To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 22:11:23 -0500 (EST) In-Reply-To: <199811130108.TAA06474@thune.mrc.org> from "dalgoda@ix.netcom.com" at Nov 12, 98 07: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: 1397 Lines: 33 > Amazingly enough dickey@clark.net said: > > I intend making it an add-on, so the configure script will be able to > > first check if the directories are there before doing anything with them, > > and further, to make it pick up the list of .po files so we don't have > > to embed that in the sources. > > > Out of curiosity, any clue how this will be done? automatically - check for directory existence. I do this in ncurses for the Ada95 and c++ directories. I did a part of this in the lynx script this week while trying to get the Solaris gettext stuff to work. It just isn't noticeable - but look at the @INTLDIR_MAKE@ substitutions in makefile.in, for example. > The only package I know of that uses configure and add-ons is egcs, and the > command line switch to configure is "--enable-add-ons=item1,item2,...,itemN" > > Is the "--enable-add-ons" a standard configure thing or just an egcs thing? > > If not a standard configure thing, what do other packages do? different packages do different things. I don't know that there's a standard - just different groups of people develop their own conventions. (I'm aware that ncurses is bundled as an add-on to glibc2, though the mechanism looks rather complex to me). > Mike Castle Life is like a clock: You can work constantly -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 22:28:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA18729 for ; Thu, 12 Nov 1998 22:28:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA12785; Thu, 12 Nov 1998 21:16:14 -0600 (CST) From: dickey@clark.net Message-Id: <199811130318.WAA07578@shell.clark.net> Subject: Re: lynx-dev protection 444 for fr.po To: lynx-dev@sig.net Date: Thu, 12 Nov 1998 22:18:06 -0500 (EST) In-Reply-To: <199811130226.LAA05697@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 13, 98 11:26:18 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: 1929 Lines: 44 > > > > checked-in -- I expect there'll be more than one patch to fr.po, and > > > > > > I should certainly hope not to the one in the Lynx distribution. > > > > actually yes. There shouldn't be any html in the msgid's. It'll just > > create a lot of maintenance problems. I reorganized a fair number of > > the strings in the C code to work around this, but there's more. It > > I still don't understand why you feel the need to maintain fr.po unless > you just enjoy doing it. Anyway, I assume you know about the -j option I just want to have an example for testing (english/english doesn't help me much). I'm not planning to _maintain_ fr.po so much as to resync so that we don't lose Jim's changes. > to xgettext. It would also make the file a bit smaller if you'd use > the --no-location option. Since you plan on supporting the build in > /po, you might consider adding the --no-location option as a default. on my list... > I did find that I lost about half of the 400+ translated strings I had > done on Jim's code set when I updated to dev2. I hope to be able to > salvage them, but it might mean hand editing. (Moan.) If I figure out > what triggered the loss, I'll let you know. I hadn't worked on any > strings with html tags in them, so that wasn't it. Did you switch > locations of "%s" or "%d" in places? There were a few strings with I don't recall switching the %s and %d - just split up the strings that had html in them. (The %s and %d tokens are less of a problem for maintenance than the html, and far more difficult to adjust). But that's just my opinion. > trailing white space. Are these all going to be revised to strip it > off? (If so, I'll put off translating those, too.) I believe LP recommended stripping the trailing blanks. I hadn't really thought about it. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 12 23:01:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA21982 for ; Thu, 12 Nov 1998 23:01:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA19144; Thu, 12 Nov 1998 21:50:06 -0600 (CST) To: lynx-dev@sig.net References: <199811130226.LAA05697@ews07.nara.kindai.ac.jp> Message-Id: From: "Leonid Pauzner" Date: Fri, 13 Nov 1998 06:46:59 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev protection 444 for fr.po 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: 1228 Lines: 23 > I still don't understand why you feel the need to maintain fr.po unless > you just enjoy doing it. Anyway, I assume you know about the -j option > to xgettext. It would also make the file a bit smaller if you'd use > the --no-location option. Since you plan on supporting the build in ^^^^^^^^^^^^^ > /po, you might consider adding the --no-location option as a default. > I did find that I lost about half of the 400+ translated strings I had ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > done on Jim's code set when I updated to dev2. I hope to be able to > salvage them, but it might mean hand editing. (Moan.) If I figure out > what triggered the loss, I'll let you know. I hadn't worked on any > strings with html tags in them, so that wasn't it. Did you switch > locations of "%s" or "%d" in places? There were a few strings with > trailing white space. Are these all going to be revised to strip it > off? (If so, I'll put off translating those, too.) You contradict yourself: .po and .pot files have comments for filename/line info, if you remove it you easily fall into such a problem. Look in LYMessages.en.h (dev2) for you lost strings, they are mostly there. > __Henry From owner-lynx-dev@sig.net Fri Nov 13 00:40:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA31065 for ; Fri, 13 Nov 1998 00:40:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA06128; Thu, 12 Nov 1998 23:26:44 -0600 (CST) Message-ID: <19981112212846.61814@unicorn.it.wsu.edu> Date: Thu, 12 Nov 1998 21:28:47 -0800 From: Michael Warner To: lynx-dev@sig.net Subject: Piping to mailer's stdin (was Re: lynx-dev A question about downloading in lynx....) Mail-Followup-To: lynx-dev@sig.net References: <19981112213436.B12193@mema.ucl.ac.be> <199811122222.RAA13966@shell.clark.net> <19981113004956.A17608@mema.ucl.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.12 In-Reply-To: <19981113004956.A17608@mema.ucl.ac.be>; from Serge MUNHOVEN on Fri, Nov 13, 1998 at 12:49:56AM +0100 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 964 Lines: 37 [Apologies for non-lynx reply, but open-source folk gotta stick together, eh?] On Fri, Nov 13, 1998, Serge MUNHOVEN wrote: [...] > I knew about piping to mail/mailx/mutt (unix of course ...), > but my question was about, e.g.: > > % cat bin.data | mutt -a - > -: unable to attach file. In this case, I think % cat bin.data | mutt whoever@some.dom would have done it. Stdin is the default, and "-a -" apparently doesn't work as a synonym. A snippet of my (somewhat old) mutt manual: Mutt also supports a ``batch'' mode to send prepared messages. Simply redirect input from the file you wish to send. For example, mutt -s "data set for run #2" professor@bigschool.edu < ~/run2.dat This command will send a message to ``professor@bigschool.edu'' with a subject of ``data set for run #2''. In the body of the message will be the contents of the file ``~/run2.dat''. HTH -- Michael Warner From owner-lynx-dev@sig.net Fri Nov 13 00:50:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA31979 for ; Fri, 13 Nov 1998 00:50:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA07651; Thu, 12 Nov 1998 23:38:12 -0600 (CST) Date: Fri, 13 Nov 1998 00:38:57 -0500 (EST) From: Philip Webb Message-Id: <199811130538.AAA06851@chass.utoronto.ca> To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-URL: mailto:lynx-dev@sig.net X-Mailer: Lynx, Version 2.8.1rel.1 Subject: lynx-dev sleeping partners Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1813 Lines: 40 Financial Times (London) 981113 LYNX: Software group `positive' about prospects -- Maggie Urry A combination of organic growth and acquisitions helped Lynx, the software group, to a 35 % increase in pre-tax profits for the year to September 30. Profits rose from £ 9.81 M to £ 13.3 M , on sales up 50 % to £ 181 M . Stewart Douglas-Mann, chairman, said the group was "extremely positive" about its prospects. Richard Last, chief executive, said the order book amounted to £ 22.7 M at the year end, up from £ 12.4 M at the start of the financial year. Operating profits from continuing businesses rose 25 % to £ 12.8 M , and acquisitions, notably Tenhill, which was bought in April 1998, contributed £ 1.1 M . The interest charge was up by £ 484 K to £ 713 K , reflecting the debt-financing of acquisitions. Mr Last said most of the group's activities had achieved significant growth in sales and profits. The only difficult area was automotive systems, where the main customers are the large carmakers. He said a number of manufacturers had delayed projects, and so the division "did not perform to an acceptable level". Nonetheless, the group remained confident this market offered growth. Lynx this week acquired Exepos as a base for a new communications division. Mr Last said this could grow into a "substantial" business which would "quickly become a significant contributor to group profits". Earnings per share rose 27 % to 8.67 p , and a recommended final dividend of 1.7 p gives a total 2.25 p . Lynx -- www.lynx.com/ -- ========================,,============================================ 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 Nov 13 00:59:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA32759 for ; Fri, 13 Nov 1998 00:59:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA09075; Thu, 12 Nov 1998 23:48:18 -0600 (CST) To: lynx-dev@sig.net Subject: lynx-dev lynx2.8.2dev.2 fails to build outside of the source tree. X-Mailer: Ganriki-1 (^o^;) MIME-Version: 1.0 Message-Id: <19981113140832-8312F.objectx@bandit.co.jp> Date: Fri, 13 Nov 1998 14:08:32 +0900 From: Masashi Fujita X-Dispatcher: imput version 981104(IM103) Content-Type: Multipart/mixed; boundary="-19981113140832-8312H.objectx_bandit.co.jp-" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1201 Lines: 32 ---19981113140832-8312H.objectx_bandit.co.jp- Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Dear lynx maintainers: Attached patch should be needed when building the lynx outside of the source tree. Sincerely. # I've tried to make `userdefs.h' automatically copied to build # directory, but failed to update `configure' due to aclocal.m4 contains # `AC_DIVERT_HELP' macro...(stock autoconf-2.12 does not contain this) -- M.Fujita -- objectx@polyphony.scei.co.jp -- objectx@bandit.co.jp ---19981113140832-8312H.objectx_bandit.co.jp- Content-Type: Text/plain; charset=us-ascii diff -ur ORIG/lynx2.8.2dev.2/src/makefile.in lynx2.8.2dev.2/src/makefile.in --- ORIG/lynx2.8.2dev.2/src/makefile.in Wed Nov 11 04:47:38 1998 +++ lynx2.8.2dev.2/src/makefile.in Fri Nov 13 13:55:38 1998 @@ -116,7 +116,7 @@ LYMainLoop.o: $(top_srcdir)/userdefs.h LYOptions.o: $(top_srcdir)/userdefs.h LYReadCFG.o: $(top_srcdir)/userdefs.h -LYShowInfo.o: $(top_srcdir)/cfg_defs.h +LYShowInfo.o: $(top_builddir)/cfg_defs.h LYTraversal.o: $(top_srcdir)/userdefs.h LYUtils.o: $(top_srcdir)/userdefs.h LYrcFile.o: $(top_srcdir)/userdefs.h ---19981113140832-8312H.objectx_bandit.co.jp--- From owner-lynx-dev@sig.net Fri Nov 13 02:46:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA08694 for ; Fri, 13 Nov 1998 02:46:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21590; Fri, 13 Nov 1998 01:34:39 -0600 (CST) Date: Fri, 13 Nov 1998 16:37:28 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130737.QAA07159@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 609 Lines: 15 > > Just don't install a lynx.mo file and you'll get the defaults. > > Gettext falls back to the msgid if it can't find another catalogue. > > At compile time or when the binary already installed? At run time. The *.mo file is referenced by the running binary. The *.po file, from which the *.mo file is produced, is what the human translating the strings uses. Neither of them are needed at compile time. > If it's at run-time, lynx should certainly have a command-line > switch -english for person like me who cannot guess (undocumented) Sorry, I don't follow you here. Please explain again. __Henry From owner-lynx-dev@sig.net Fri Nov 13 03:07:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA10126 for ; Fri, 13 Nov 1998 03:07:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA22609; Fri, 13 Nov 1998 01:44:17 -0600 (CST) Date: Fri, 13 Nov 1998 16:47:14 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130747.QAA07222@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 697 Lines: 17 > that had html in them. (The %s and %d tokens are less of a problem > for maintenance than the html, and far more difficult to adjust). They seem to work fine, so if possible it would be nice if strings containing them stay the same. > > trailing white space. Are these all going to be revised to strip it > > off? (If so, I'll put off translating those, too.) > > I believe LP recommended stripping the trailing blanks. I hadn't really > thought about it. I can't say either way. What makes me itchy is having the msgid change on me, forcing an update. (But that's my problem, not yours, and as with Larry, I very much appreciate what you are doing to improve the program.) __Henry From owner-lynx-dev@sig.net Fri Nov 13 03:22:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA11449 for ; Fri, 13 Nov 1998 03:22:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA23872; Fri, 13 Nov 1998 01:58:16 -0600 (CST) Date: Fri, 13 Nov 1998 17:01:25 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811130801.RAA07294@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev protection 444 for fr.po Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 910 Lines: 17 > You contradict yourself: .po and .pot files have comments for filename/line > info, if you remove it you easily fall into such a problem. I was too brief. I didn't actually "lose" the strings (after all I made them in the first place :). What I meant was that after running xgettext with the -j option (updating) writing to my previously constructed po file, about half of the strings that were translated did not carry over to the new file. I'm not sure what is best to do in this case. Rather than try to write a gawk script to move the msgstr to the new msgid, it will probably be faster to just cut-n-paste them over. I will try to figure out why it happened, though, so that something like this doesn't happen in the future after Tom has it all stabilized. > Look in LYMessages.en.h (dev2) for you lost strings, they are mostly there. ^^ LYMessages_ja.h ^^ __Henry From owner-lynx-dev@sig.net Fri Nov 13 05:05:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA18555 for ; Fri, 13 Nov 1998 05:05:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA03845; Fri, 13 Nov 1998 03:46:42 -0600 (CST) Date: Fri, 13 Nov 1998 10:52:13 +0200 Message-Id: <98111310521337@decus.fr> From: soma_c@decus.fr (Claude SOMA - CNTS) To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question X-VMS-To: SMTP%"lynx-dev@sig.net" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 465 Lines: 15 On Fri, 13 Nov 1998 05:12:17 +0300 (MSK) "Leonid Pauzner" wrote: >If it's at run-time, lynx should certainly have a command-line >switch -english for person like me who cannot guess (undocumented) >features I am not using at. If you have no switch, you can do: (shell syntax) (LANGUAGE=fr ;export LANGUAGE; lynx ...) #to have french translation But some bug (example buffer overflow) can arise only whith some translation file... Claude From owner-lynx-dev@sig.net Fri Nov 13 06:55:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA26265 for ; Fri, 13 Nov 1998 06:55:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA13553; Fri, 13 Nov 1998 05:35:11 -0600 (CST) To: lynx-dev@sig.net References: <98111310521337@decus.fr> Message-Id: From: "Leonid Pauzner" Date: Fri, 13 Nov 1998 14:30:50 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev gettext() 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: 644 Lines: 20 > On Fri, 13 Nov 1998 05:12:17 +0300 (MSK) "Leonid Pauzner" > wrote: >>If it's at run-time, lynx should certainly have a command-line >>switch -english for person like me who cannot guess (undocumented) >>features I am not using at. > If you have no switch, you can do: (shell syntax) ^^^^^^^^^^^^^^^^^^^^^ Not me :-) just want people who contribute the code spent few minutes for Lynx_user_guide.html too. > (LANGUAGE=fr ;export LANGUAGE; lynx ...) #to have french translation > But some bug (example buffer overflow) can arise only whith some translation That is the problem I am expecting. > file... > Claude 2 From owner-lynx-dev@sig.net Fri Nov 13 06:56:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA26295 for ; Fri, 13 Nov 1998 06:56:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA14183; Fri, 13 Nov 1998 05:40:30 -0600 (CST) Date: Fri, 13 Nov 1998 13:42:28 +0200 (EET) From: VictorAs To: lynx-dev@sig.net Subject: Re: lynx-dev A question about downloading in lynx.... In-Reply-To: <19981112213436.B12193@mema.ucl.ac.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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.flora.ottawa.on.ca id GAA26295 Status: RO Content-Length: 2698 Lines: 58 On Thu, 12 Nov 1998, Serge MUNHOVEN wrote: :-) >On Thu, Nov 12, 1998 at 05:35:41PM +0200, VictorAs wrote: :-) > > On Thu, 12 Nov 1998, Leonid Pauzner wrote: :-) > > :-) > > :-) >> I have a problem when i download tgz files.... :-) > > :-) >> I want to mail that files(ostream*) but i cant, in my lynx version exist :-) > > :-) >> only save to a file, but i have a quota on my server and i cant download :-) > > :-) >> files biger than 1.5 Mbytes... :-) > > :-) >> Can i configure my lynx to mail that kind of files to an specific e-mail :-) > > :-) >No, only text files can be e-mailed currently (From 'P'rint menu). :-) > > :-) > :-) > > :-) >> address? :-) > > :-) >> If i can please tell me how... :-) > > :-) >Try reading lynx.cfg about DOWNLOADER: :-) > > :-) >probably Zmodem or ftp may be your case. :-) > > :-) > :-) > > :-) >> Thanks... :-) > > :-) >> Victor :-) > > :-) > :-) > > Yes but i want to configure it to can mail the files, can :-) > > anyone tell me exact what to do? :-) > > :-) Thanks, :-) > > Victor. :-) > > :-) > :-) > > :-) > :-) > > :-) >But once you get to the DOWNLOADER menu, you have already transferred the :-) >complete big file to your local host, as far as I understand. Lynx stores :-) >them in some place (/var/tmp in my case) and "Save to disk" (and other :-) >DOWNLOADERs) actually act on that temporary file. Note that "Save to disk" :-) >*copies* the file, which doubles the required diskquotas if the temporary :-) >file also eats on them. It may be possible to circumvent this by defining an :-) >entry that rather *moves* the file to its final location (depending on how :-) >the system's "move" works). :-) > :-) >Anyway, I wonder if many mailers allow you to send a stream of incoming data :-) >rather than a complete existing local file (any expert opinion ?). In addition :-) >your binary data will have to be encoded for standard mail transport (8bit :-) >cleaness is not guaranteed). Guess the mailer will again help itself with an :-) >even larger temporary file ... :-) > :-) >As to an actual DOWNLOADER entry to mail the file, it heavily depends on your :-) >system, especially your mailer's capability and flags to encode and attach :-) >files. yes, but i want to send that file attached.... can any1 tell me how? I am a regular user, i dont know how to configure exact, and if i need to copy lynx.cfg in my directory? Thanks Serge and anyone can help me with that problem.... Victor :-) > :-) > - Serge :-) > :-) >PS: "Jeu de car." abbreviated for "Jeu de caractères" - "Character set". :-) >(Yes, I know French better than C). :-) > From owner-lynx-dev@sig.net Fri Nov 13 19:20:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA05169 for ; Fri, 13 Nov 1998 19:20:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA00068; Fri, 13 Nov 1998 18:02:40 -0600 (CST) Date: Sat, 14 Nov 1998 09:06:04 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811140006.JAA10822@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 255 Lines: 7 > But some bug (example buffer overflow) can arise only whith some translation > file... Can you give us more information on this? I worry because it is often impossible to give a clear translation within the same length as the English message. __Henry From owner-lynx-dev@sig.net Fri Nov 13 19:48:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA07595 for ; Fri, 13 Nov 1998 19:48:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA05214; Fri, 13 Nov 1998 18:33:38 -0600 (CST) Message-Id: <199811140033.SAA07038@thune.mrc.org> Subject: Re: lynx-dev gettext() question To: lynx-dev@sig.net Date: Fri, 13 Nov 1998 18:33:14 -0600 (CST) In-Reply-To: <98111310521337@decus.fr> from "Claude SOMA - CNTS" at Nov 13, 98 10:52:13 am From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 822 Lines: 20 Amazingly enough Claude SOMA - CNTS said: > If you have no switch, you can do: (shell syntax) > > (LANGUAGE=fr ;export LANGUAGE; lynx ...) #to have french translation > I guess something to consider is giving a way to change the language at run time. (think public anonymous lynx configurations here). What mechanisms exist to allow this? Do the gettext() implementations check the environment variable every time? Or do they do it once then sent something internally? If the latter, is there a way to reload a message base? mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Fri Nov 13 20:16:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA11271 for ; Fri, 13 Nov 1998 20:16:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA09529; Fri, 13 Nov 1998 18:59:15 -0600 (CST) Date: Sat, 14 Nov 1998 10:02:46 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811140102.KAA11050@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 286 Lines: 6 > What mechanisms exist to allow this? Do the gettext() implementations > check the environment variable every time? Or do they do it once then sent At the risk of getting flamed (wouldn't be the first time :), shouldn't these questions be going to the gettext mailing list? __Henry From owner-lynx-dev@sig.net Fri Nov 13 20:18:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA11502 for ; Fri, 13 Nov 1998 20:18:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA09027; Fri, 13 Nov 1998 18:55:44 -0600 (CST) Date: Sat, 14 Nov 1998 09:59:12 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811140059.JAA11029@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2915 Lines: 61 > >>If it's at run-time, lynx should certainly have a command-line > >>switch -english for person like me who cannot guess (undocumented) > >>features I am not using at. > > > If you have no switch, you can do: (shell syntax) > ^^^^^^^^^^^^^^^^^^^^^ > Not me :-) I have no idea what you imply here. Does "Not me" apply to not having a switch (which means you plan to write the code for the switch), or does it mean you don't want to use an environment variable? If the first, could you explain in more detail what the switch you propose will do and why you need it. If the second, why not? (If you were specifically referring to French, then no need to reply; I get the joke -- although I do assume you will be interested in Russian at some point.) > just want people who contribute the code spent few minutes for > Lynx_user_guide.html too. > > > (LANGUAGE=fr ;export LANGUAGE; lynx ...) #to have french translation Are you saying that documentation for NLS and gettext needs to be written and incorporated into Lynx_user_guide.html? Everyone by now knows that I am not particularly thrilled about doing something like that. The reason is that NLS is not Lynx specific. There are already a number of GNU programs out there which support NLS. Some of them have been around for 4 years or more. I really see no need to have any more documentation than there was previously for the LYMessages_??.h method. Over time, there have not been a tremendous number of inquiries about LYMessages_??.h, and to my knowledge all of the inquiries were answered, by myself or others. To follow up on the example above, the system I have been testing on (unpatched 10-year-old SunOS4.1.3) I must use (csh): setenv LANGUAGE ja setenv LANG japanese The settings here will be different for every system/language/user. I argue that this is the problem of the sysadm and the user, not lynx-dev. I will not renege on my promise to write up how to install NLS AS IT SPECIFICALLY RELATES to Lynx, but I have no intention of going into the detail of how the LANG and LANGUAGE environment variables interact, how to initiate and maintain the translations, nor other system/user specific details. The reason is that that documentation is already written and included in the gettext package. A reference to that package should be sufficient (and is the main reason I opposed so strongly incorporation of the half-baked /intl directory in the Lynx distribution). > > But some bug (example buffer overflow) can arise only whith some > > translation > > That is the problem I am expecting. What problem are you expecting? Can you give me a real-world example that I can test, i.e., quote the actual msgstr you would like me to plug in? Gettext() is working like a charm here, but I sure would like to iron out any bugs early in the game, especially before Tom gets it solidified and wants to move on to new ground. __Henry From owner-lynx-dev@sig.net Fri Nov 13 21:54:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA24990 for ; Fri, 13 Nov 1998 21:54:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA24323; Fri, 13 Nov 1998 20:37:32 -0600 (CST) Date: Fri, 13 Nov 1998 18:39:52 -0800 (PST) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: lynx-dev handling the screen in lynxexec In-Reply-To: <199811140102.KAA11050@ews07.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: 912 Lines: 20 Hello, This is a question, whose answer may be that this is not a problem in lynx, but I want to make sure anyway. I installed lynx 2.8.1rel1 in digital unix, with ncursesv4.2. I enabled local execution of programs. I wrote some programs that I wanted to execute while still being in lynx, so I added them to my jump file. The input and output of these program are files. My problem is that if I make a mistake entering the name of these files while runing the program, the erase character appears printed in the screen (^H), so if I make a mistake I have to restart all over again. So my question is if this is a problem with ncurses or with lynx, and if is it there any way to fix it ? Also, I enabled the advanced user mode and the last line is not erased on the start of the program, my program writes over it. Is ncurses the problem ? Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Sat Nov 14 01:02:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA19074 for ; Sat, 14 Nov 1998 01:02:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA21742; Fri, 13 Nov 1998 23:43:51 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Sat, 14 Nov 1998 00:46:29 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev SSL patches for lynx2.8.2dev.2 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: 24090 Lines: 820 Here are Mark Mentovai's SSL patches modified to work with lynx2.8.2dev.2. Only the patches for HTNews.c and HTTP.c had to be modified. *** lynx2-8-1.dist/WWW/Library/Implementation/HTAAUtil.c Thu Aug 6 08:28:22 1998 --- lynx2-8-1/WWW/Library/Implementation/HTAAUtil.c Mon Oct 26 15:06:51 1998 *************** *** 50,55 **** --- 50,62 ---- #include #include + #ifdef USE_SSL + #define free_func free__func + #include + #undef free_func + PRIVATE SSL * Handle = NULL; /* The SSL Handle */ + #endif /* USE_SSL */ + #include #include *************** *** 531,537 **** --- 538,551 ---- /* Reading from socket */ if (start_pointer >= end_pointer) {/*Read the next block and continue*/ + #ifdef USE_SSL + if (Handle) + count = SSL_read(Handle, buffer, BUFFER_SIZE); + else + count = NETREAD(in_soc, buffer, BUFFER_SIZE); + #else count = NETREAD(in_soc, buffer, BUFFER_SIZE); + #endif /* USE_SSL */ if (count <= 0) { in_soc = -1; return line; *** lynx2-8-1.dist/WWW/Library/Implementation/HTFormat.c Wed Sep 30 17:06:48 1998 --- lynx2-8-1/WWW/Library/Implementation/HTFormat.c Mon Oct 26 15:06:51 1998 *************** *** 17,22 **** --- 17,28 ---- */ #include + #ifdef USE_SSL + #define free_func free__func + #include + #undef free_func + #endif /* USE_SSL */ + PUBLIC float HTMaxSecs = 1e10; /* No effective limit */ PUBLIC float HTMaxLength = 1e10; /* No effective limit */ PUBLIC long int HTMaxBytes = 0; /* No effective limit */ *************** *** 248,253 **** --- 254,292 ---- return FROMASCII(ch); } + #ifdef USE_SSL + PUBLIC char HTGetSSLCharacter ARGS1(void *, handle) + { + char ch; + interrupted_in_htgetcharacter = 0; + if(!handle) + return (char)EOF; + do { + if (input_pointer >= input_limit) { + int status = SSL_read((SSL *)handle, + input_buffer, INPUT_BUFFER_SIZE); + if (status <= 0) { + if (status == 0) + return (char)EOF; + if (status == HT_INTERRUPTED) { + CTRACE(tfp, "HTFormat: Interrupted in HTGetSSLCharacter\n"); + interrupted_in_htgetcharacter = 1; + return (char)EOF; + } + CTRACE(tfp, "HTFormat: SSL_read error %d\n", status); + return (char)EOF; /* -1 is returned by UCX + at end of HTTP link */ + } + input_pointer = input_buffer; + input_limit = input_buffer + status; + } + ch = *input_pointer++; + } while (ch == (char) 13); /* Ignore ASCII carriage return */ + + return FROMASCII(ch); + } + #endif /* USE_SSL */ + /* Match maintype to any MIME type starting with maintype, * for example: image/gif should match image */ *************** *** 570,576 **** --- 609,622 ---- goto finished; } + #ifdef USE_SSL + if (handle) + status = SSL_read((SSL *)handle, input_buffer, INPUT_BUFFER_SIZE); + else + status = NETREAD(file_number, input_buffer, INPUT_BUFFER_SIZE); + #else status = NETREAD(file_number, input_buffer, INPUT_BUFFER_SIZE); + #endif /* USE_SSL */ if (status <= 0) { if (status == 0) { *** lynx2-8-1/WWW/Library/Implementation/HTNews.c.orig Tue Nov 10 14:47:38 1998 --- lynx2-8-1/WWW/Library/Implementation/HTNews.c Fri Nov 13 12:31:21 1998 *************** *** 33,41 **** --- 33,58 ---- #define SERVER_FILE "/usr/local/lib/rn/server" #endif /* SERVER_FILE */ + #ifdef USE_SSL + #define free_func free__func + #include + #undef free_func + extern SSL_CTX * ssl_ctx; + extern SSL * HTGetSSLHandle NOPARAMS; + PRIVATE SSL * Handle = NULL; + PRIVATE int channel_s = 1; + #define NEWS_NETWRITE(sock, buff, size) \ + (Handle ? SSL_write(Handle, buff, size) : NETWRITE(sock, buff, size)) + #define NEWS_NETCLOSE(sock) \ + { (void)NETCLOSE(sock); if (Handle) SSL_free(Handle); Handle = NULL; } + extern char HTGetSSLCharacter PARAMS((void *handle)); + PRIVATE char HTNewsGetCharacter NOPARAMS; + #define NEXT_CHAR HTNewsGetCharacter() + #else #define NEWS_NETWRITE NETWRITE #define NEWS_NETCLOSE NETCLOSE #define NEXT_CHAR HTGetCharacter() + #endif /* USE_SSL */ #include #include *************** *** 2024,2034 **** --- 2041,2053 ---- group_wanted) && strchr(arg, '@') == NULL) && (strchr(arg, '*') != NULL); + #ifndef USE_SSL if (!strncasecomp(arg, "snewspost:", 10) || !strncasecomp(arg, "snewsreply:", 11)) { HTAlert(gettext("This client does not contain support for posting to news with SSL.")); return HT_NOT_LOADED; } + #endif /* !USE_SSL */ if (post_wanted || reply_wanted || spost_wanted || sreply_wanted) { /* ** Make sure we have a non-zero path for the newsgroup(s). - FM *************** *** 2115,2124 **** --- 2134,2180 ---- sprintf(command, "nntp://%.251s/", NewsHost); StrAllocCopy(NewsHREF, command); } + #ifdef USE_SSL + else if (!strncasecomp (arg, "snews:", 6)) { + if (((*(arg + 6) == '\0') || + (!strcmp((arg + 6), "/") || + !strcmp((arg + 6), "//") || + !strcmp((arg + 6), "///"))) || + ((!strncmp((arg + 6), "//", 2)) && + (!(cp = strchr((arg + 8), '/')) || *(cp + 1) == '\0'))) { + p1 = "*"; + group_wanted = FALSE; + list_wanted = TRUE; + } else if (*(arg + 6) != '/') { + p1 = (arg + 6); + } else if (*(arg + 6) == '/' && *(arg + 7) != '/') { + p1 = (arg + 7); + } else { + p1 = (cp + 1); + } + if (!(cp = HTParse(arg, "", PARSE_HOST)) || *cp == '\0') { + if (s >= 0 && NewsHost && strcasecomp(NewsHost, HTNewsHost)) { + NEWS_NETCLOSE(s); + s = -1; + } + StrAllocCopy(NewsHost, HTNewsHost); + } else { + if (s >= 0 && NewsHost && strcasecomp(NewsHost, cp)) { + NEWS_NETCLOSE(s); + s = -1; + } + StrAllocCopy(NewsHost, cp); + } + FREE(cp); + sprintf(command, "snews://%.250s/", NewsHost); + StrAllocCopy(NewsHREF, command); + } + #else else if (!strncasecomp(arg, "snews:", 6)) { HTAlert(gettext("This client does not contain support for SNEWS URLs.")); return HT_NOT_LOADED; } + #endif /* USE_SSL */ else if (!strncasecomp (arg, "news:/", 6)) { if (((*(arg + 6) == '\0') || !strcmp((arg + 6), "/") || *************** *** 2315,2320 **** --- 2371,2414 ---- ** Now, let's get a stream setup up from the NewsHost. */ for (retries = 0; retries < 2; retries++) { + #ifdef USE_SSL + if (Handle && channel_s >= 0) { + s = channel_s; + channel_s = -1; + HTInitInput(s); /* set up buffering */ + if (((status = response(NULL)) / 100) != 2) { + char message[BIG]; + NEWS_NETCLOSE(s); + s = -1; + if (status == HT_INTERRUPTED) { + _HTProgress(gettext("Connection interrupted.")); + } else { + HTAlert(gettext("Can't read news info.")); + CTRACE(tfp, "News host %.20s responded: %.200s\n", + NewsHost, response_text); + if (!(post_wanted || reply_wanted || + spost_wanted || sreply_wanted)) + (*targetClass._abort)(target, NULL); + FREE(NewsHost); + FREE(NewsHREF); + FREE(ProxyHost); + FREE(ProxyHREF); + FREE(ListArg); + if (postfile) { + #ifdef VMS + while (remove(postfile) == 0) + ; /* loop through all versions */ + #else + remove(postfile); + #endif /* VMS */ + FREE(postfile); + } + return HT_NOT_LOADED; + } + } + } + #endif /* USE_SSL */ + if (s < 0) { /* CONNECTING to news host */ char url[260]; *************** *** 2329,2335 **** --- 2423,2440 ---- _HTProgress(gettext("Connecting to NewsHost ...")); + #ifdef USE_SSL + if (!using_proxy && + (!strncmp(arg, "snews:", 6) || + !strncmp(arg, "snewspost:", 10) || + !strncmp(arg, "snewsreply:", 11))) + status = HTDoConnect (url, "NNTP", SNEWS_PORT, &s); + else + status = HTDoConnect (url, "NNTP", NEWS_PORT, &s); + #else status = HTDoConnect (url, "NNTP", NEWS_PORT, &s); + #endif /* USE_SSL */ + if (status == HT_INTERRUPTED) { /* ** Interrupt cleanly. *************** *** 2345,2350 **** --- 2450,2461 ---- FREE(ProxyHost); FREE(ProxyHREF); FREE(ListArg); + #ifdef USE_SSL + if (Handle) { + SSL_free(Handle); + Handle = NULL; + } + #endif /* USE_SSL */ if (postfile) { HTSYS_remove(postfile); FREE(postfile); *************** *** 2372,2377 **** --- 2483,2530 ---- } else { CTRACE(tfp, "HTNews: Connected to news host %s.\n", NewsHost); + #ifdef USE_SSL + /* + ** If this is an snews url, + ** then do the SSL stuff here + */ + if (!using_proxy && + (!strncmp(url, "snews", 5) || + !strncmp(url, "snewspost:", 10) || + !strncmp(url, "snewsreply:", 11))) { + Handle = HTGetSSLHandle(); + SSL_set_fd(Handle, s); + status = SSL_connect(Handle); + + if (status <= 0) { + CTRACE(tfp, + "HTNews: Unable to complete SSL handshake for remote host '%s' (SSLerror = %d)\n", + url, status); + HTAlert(gettext("Unable to make secure connection to remote host.")); + NEWS_NETCLOSE(s); + s = -1; + if (!(post_wanted || reply_wanted || + spost_wanted || sreply_wanted)) + (*targetClass._abort)(target, NULL); + FREE(NewsHost); + FREE(NewsHREF); + FREE(ProxyHost); + FREE(ProxyHREF); + FREE(ListArg); + if (postfile) { + #ifdef VMS + while (remove(postfile) == 0) + ; /* loop through all versions */ + #else + remove(postfile); + #endif /* VMS */ + FREE(postfile); + } + return HT_NOT_LOADED; + } + _HTProgress(SSL_get_cipher(Handle)); + } + #endif /* USE_SSL */ HTInitInput(s); /* set up buffering */ if (proxycmd[0]) { status = NEWS_NETWRITE(s, proxycmd, strlen(proxycmd)); *************** *** 2700,2705 **** --- 2853,2897 ---- */ free_NNTP_AuthInfo(); } + + #ifdef USE_SSL + PRIVATE char HTNewsGetCharacter NOARGS + { + if (!Handle) + return HTGetCharacter(); + else + return HTGetSSLCharacter((void *)Handle); + } + + PUBLIC int HTNewsProxyConnect ARGS5 (int, sock, CONST char *, url, + HTParentAnchor *, anAnchor, + HTFormat, format_out, + HTStream *, sink) + { + int status; + CONST char * arg = url; + + s = channel_s = sock; + Handle = HTGetSSLHandle(); + SSL_set_fd(Handle, s); + status = SSL_connect(Handle); + + if (status <= 0) { + channel_s = -1; + CTRACE(tfp, + "HTTP: Unable to complete SSL handshake for remote host '%s' (SSLerror = %d)\n", + url, status); + HTAlert(gettext("Unable to make secure connection to remote host.")); + NEWS_NETCLOSE(s); + s = -1; + return HT_NOT_LOADED; + } + _HTProgress(SSL_get_cipher(Handle)); + status = HTLoadNews(arg, anAnchor, format_out, sink); + channel_s = -1; + return status; + } + #endif /* USE_SSL */ #ifdef GLOBALDEF_IS_MACRO #define _HTNEWS_C_1_INIT { "news", HTLoadNews, NULL } *** lynx2-8-1/WWW/Library/Implementation/HTTP.c.orig Tue Nov 10 14:47:38 1998 --- lynx2-8-1/WWW/Library/Implementation/HTTP.c Fri Nov 13 12:31:32 1998 *************** *** 10,15 **** --- 10,22 ---- #include #include + #ifdef USE_SSL + #define free_func free__func + #include + #include + #undef free_func + #endif /* USE_SSL */ + #define HTTP_VERSION "HTTP/1.0" #define HTTP_PORT 80 *************** *** 64,72 **** --- 71,121 ---- extern BOOL traversal; /* TRUE if we are doing a traversal */ extern BOOL dump_output_immediately; /* TRUE if no interactive user */ + #ifdef USE_SSL + PUBLIC SSL_CTX * ssl_ctx = NULL; /* SSL ctx */ + + PRIVATE void free_ssl_ctx NOARGS + { + if (ssl_ctx != NULL) + SSL_CTX_free(ssl_ctx); + } + + PUBLIC SSL * HTGetSSLHandle NOARGS + { + if (ssl_ctx == NULL) { + /* + * First time only. + */ + #if SSLEAY_VERSION_NUMBER < 0x0800 + ssl_ctx = SSL_CTX_new(); + X509_set_default_verify_paths(ssl_ctx->cert); + #else + SSLeay_add_ssl_algorithms(); + ssl_ctx = SSL_CTX_new(SSLv23_client_method()); + SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL); + SSL_CTX_set_default_verify_paths(ssl_ctx); + #endif /* SSLEAY_VERSION_NUMBER < 0x0800 */ + atexit(free_ssl_ctx); + } + return(SSL_new(ssl_ctx)); + } + + #define HTTP_NETREAD(sock, buff, size, handle) \ + (handle ? SSL_read(handle, buff, size) : NETREAD(sock, buff, size)) + #define HTTP_NETWRITE(sock, buff, size, handle) \ + (handle ? SSL_write(handle, buff, size) : NETWRITE(sock, buff, size)) + #define HTTP_NETCLOSE(sock, handle) \ + { (void)NETCLOSE(sock); if (handle) SSL_free(handle); handle = NULL; } + + extern int HTNewsProxyConnect PARAMS (( int sock, CONST char *url, + HTParentAnchor *anAnchor, + HTFormat format_out, + HTStream *sink )); + #else #define HTTP_NETREAD(a, b, c, d) NETREAD(a, b, c) #define HTTP_NETWRITE(a, b, c, d) NETWRITE(a, b, c) #define HTTP_NETCLOSE(a, b) (void)NETCLOSE(a) + #endif /* USE_SSL */ /* Load Document from HTTP Server HTLoadHTTP() *************** *** 121,127 **** --- 170,187 ---- BOOL doing_redirect, already_retrying = FALSE, bad_location = FALSE; int len = 0; + #ifdef USE_SSL + BOOL do_connect = FALSE; /* ARE WE going to use a proxy tunnel ? */ + BOOL did_connect = FALSE; /* ARE WE actually using a proxy tunnel ? */ + CONST char *connect_url = NULL; /* The URL being proxied */ + char *connect_host = NULL; /* The host being proxied */ + SSL * handle = NULL; /* The SSL handle */ + #if SSLEAY_VERSION_NUMBER >= 0x0900 + BOOL try_tls = TRUE; + #endif /* SSLEAY_VERSION_NUMBER >= 0x0900 */ + #else void * handle = NULL; + #endif /* USE_SSL */ if (anAnchor->isHEAD) do_head = TRUE; *************** *** 139,144 **** --- 199,228 ---- goto done; } + #ifdef USE_SSL + if (using_proxy && !strncmp(url, "http://", 7)) { + if (connect_url = strstr((url+7), "https://")) { + do_connect = TRUE; + connect_host = HTParse(connect_url, "https", PARSE_HOST); + if (!strchr(connect_host, ':')) { + sprintf(temp, ":%d", HTTPS_PORT); + StrAllocCat(connect_host, temp); + } + CTRACE(tfp, "HTTP: connect_url = '%s'\n", connect_url); + CTRACE(tfp, "HTTP: connect_host = '%s'\n", connect_host); + } else if (connect_url = strstr((url+7), "snews://")) { + do_connect = TRUE; + connect_host = HTParse(connect_url, "snews", PARSE_HOST); + if (!strchr(connect_host, ':')) { + sprintf(temp, ":%d", SNEWS_PORT); + StrAllocCat(connect_host, temp); + } + CTRACE(tfp, "HTTP: connect_url = '%s'\n", connect_url); + CTRACE(tfp, "HTTP: connect_host = '%s'\n", connect_host); + } + } + #endif /* USE_SSL */ + sprintf(crlf, "%c%c", CR, LF); /* *************** *** 162,173 **** --- 246,263 ---- line_kept_clean = NULL; if (!strncmp(url, "https", 5)) + #ifdef USE_SSL + status = HTDoConnect (url, "HTTPS", HTTPS_PORT, &s); + else + status = HTDoConnect (url, "HTTP", HTTP_PORT, &s); + #else { HTAlert(gettext("This client does not contain support for HTTPS URLs.")); status = HT_NOT_LOADED; goto done; } status = HTDoConnect (arg, "HTTP", HTTP_PORT, &s); + #endif /* USE_SSL */ if (status == HT_INTERRUPTED) { /* ** Interrupt cleanly. *************** *** 185,196 **** --- 275,353 ---- goto done; } + #ifdef USE_SSL + use_tunnel: + /* + ** If this is an https document + ** then do the SSL stuff here + */ + if (did_connect || !strncmp(url, "https", 5)) { + handle = HTGetSSLHandle(); + SSL_set_fd(handle, s); + #if SSLEAY_VERSION_NUMBER >= 0x0900 + if (!try_tls) + handle->options|=SSL_OP_NO_TLSv1; + #endif /* SSLEAY_VERSION_NUMBER >= 0x0900 */ + status = SSL_connect(handle); + + if (status <= 0) { + #if SSLEAY_VERSION_NUMBER >= 0x0900 + if (try_tls) { + CTRACE(tfp, "HTTP: Retrying connection without TLS\n"); + _HTProgress("Retrying connection."); + try_tls = FALSE; + if (did_connect) + HTTP_NETCLOSE(s, handle); + goto try_again; + } else { + CTRACE(tfp, + "HTTP: Unable to complete SSL handshake for remote host '%s' (SSLerror = %d)\n", + url, status); + HTAlert(gettext("Unable to make secure connection to remote host.")); + if (did_connect) + HTTP_NETCLOSE(s, handle); + status = HT_NOT_LOADED; + goto done; + } + #else + CTRACE(tfp, + "HTTP: Unable to complete SSL handshake for remote host '%s' (SSLerror = %d)\n", + url, status); + HTAlert(gettext("Unable to make secure connection to remote host.")); + if (did_connect) + HTTP_NETCLOSE(s, handle); + status = HT_NOT_LOADED; + goto done; + #endif /* SSLEAY_VERSION_NUMBER >= 0x0900 */ + } + _HTProgress (SSL_get_cipher(handle)); + + #ifdef NOTDEFINED + if (strcmp(HTParse(url, "", PARSE_HOST), + strstr(X509_NAME_oneline( + X509_get_subject_name( + handle->session->peer)),"/CN=")+4)) { + HTAlert(gettext("Certificate is for different host name")); + HTAlert(strstr(X509_NAME_oneline( + X509_get_subject_name( + handle->session->peer)),"/CN=")+4); + } + #endif /* NOTDEFINED */ + } + #endif /* USE_SSL */ + /* Ask that node for the document, ** omitting the host name & anchor */ { char * p1 = (HTParse(url, "", PARSE_PATH|PARSE_PUNCTUATION)); + #ifdef USE_SSL + if (do_connect) { + METHOD = "CONNECT"; + StrAllocCopy(command, "CONNECT "); + } else + #endif /* USE_SSL */ if (do_post) { METHOD = "POST"; StrAllocCopy(command, "POST "); *************** *** 207,214 **** --- 364,380 ---- ** of say: /gopher://a;lkdjfl;ajdf;lkj/;aldk/adflj ** so that just gopher://.... is sent. */ + #ifdef USE_SSL + if (using_proxy && !did_connect) { + if (do_connect) + StrAllocCat(command, connect_host); + else + StrAllocCat(command, p1+1); + } + #else if (using_proxy) StrAllocCat(command, p1+1); + #endif /* USE_SSL */ else StrAllocCat(command, p1); FREE(p1); *************** *** 437,442 **** --- 603,612 ---- if (traversal || dump_output_immediately) HTAlert( gettext("Can't proceed without a username and password.")); + #ifdef USE_SSL + if (did_connect) + HTTP_NETCLOSE(s, handle); + #endif /* USE_SSL */ FREE(command); FREE(hostname); FREE(docname); *************** *** 552,558 **** --- 722,732 ---- auth_proxy = NO; } + #ifdef USE_SSL + if (!do_connect && do_post) { + #else if (do_post) { + #endif /* USE_SSL */ CTRACE (tfp, "HTTP: Doing post, content-type '%s'\n", anAnchor->post_content_type ? anAnchor->post_content_type : "lose"); *************** *** 578,586 **** --- 752,766 ---- else StrAllocCat(command, crlf); /* Blank line means "end" of headers */ + #ifdef USE_SSL + CTRACE (tfp, "Writing:\n%s%s----------------------------------\n", + command, + (anAnchor->post_data && !do_connect ? crlf : "")); + #else CTRACE (tfp, "Writing:\n%s%s----------------------------------\n", command, (anAnchor->post_data ? crlf : "")); + #endif /* USE_SSL */ _HTProgress (gettext("Sending HTTP request.")); *************** *** 916,921 **** --- 1096,1130 ---- * > 206 is unknown. * All should return something to display. */ + #ifdef USE_SSL + if (do_connect) { + CTRACE(tfp, "HTTP: Proxy tunnel to '%s' established.\n", + connect_host); + do_connect = FALSE; + url = connect_url; + FREE(line_buffer); + FREE(line_kept_clean); + if (!strncmp(connect_url, "snews", 5)) { + CTRACE(tfp, + " Will attempt handshake and snews connection.\n"); + status = HTNewsProxyConnect(s, url, anAnchor, + format_out, sink); + goto done; + } + did_connect = TRUE; + already_retrying = TRUE; + eol = 0; + bytes_already_read = 0; + had_header = NO; + length = 0; + doing_redirect = FALSE; + permanent_redirection = FALSE; + target = NULL; + CTRACE(tfp, + " Will attempt handshake and resubmit headers.\n"); + goto use_tunnel; + } + #endif /* USE_SSL */ HTProgress(line_buffer); } /* case 2 switch */ break; *************** *** 1466,1471 **** --- 1675,1687 ---- gettext("Retrying with access authorization information.")); FREE(line_buffer); FREE(line_kept_clean); + #ifdef USE_SSL + if (using_proxy && !strncmp(url, "https://", 8)) { + url = arg; + do_connect = TRUE; + did_connect = FALSE; + } + #endif /* USE_SSL */ goto try_again; } else if (!(traversal || dump_output_immediately) && HTConfirm(gettext("Show the 401 message body?"))) { *************** *** 1755,1760 **** --- 1971,1985 ---- do_head = FALSE; do_post = FALSE; reloading = FALSE; + #ifdef USE_SSL + do_connect = FALSE; + did_connect = FALSE; + FREE(connect_host); + if (handle) { + SSL_free(handle); + handle = NULL; + } + #endif /* USE_SSL */ return status; } *** lynx2-8-1/makefile.in.orig Tue Nov 10 14:47:38 1998 --- lynx2-8-1/makefile.in Fri Nov 13 20:22:00 1998 *************** *** 63,68 **** --- 63,79 ---- COMPRESS_PROG=@COMPRESS_PROG@ COMPRESS_EXT=@COMPRESS_EXT@ + # !!!!!!!!!! SSL Support (HTTPS connections) !!!!!!!!!!!!!!!!!!!!!!!!!!! + # To build a Lynx binary which supports the Secure Sockets Layer (SSL), + # you must compile in the crypto and SSL implementations from the SSLeay + # library, available at ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/. Once you + # have installed SSLeay, change the location of the crypto and SSL + # libraries in SSL_LIBS and the location of ssl.h and crypto.h in + # SSL_DEFINES if necessary. Defining USE_SSL below will create a binary + # which supports "https" and "snews" URLs. + SSL_LIBS= -L/usr/local/ssl/lib -lssl -lcrypto + SSL_DEFINES= -I/usr/local/ssl/include -DUSE_SSL + # !!!!!!!!!!! SUN resolv LIBRARY !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # To include resolv in the LIBS="" list for SUN 3, 4 or Solaris OS, # point RESOLVLIB to that library. You need this if you get the message *************** *** 97,109 **** # If you apply patches which require linking to site-specific libraries, set # SITE_LIBS to those libraries. ! SITE_LIBS= # Your libraries here # Set SITE_LYDEFS to one or more of the defines for the WWW Library: ! SITE_LYDEFS = # Your defines here # Set SITE_DEFS to one or more of the defines for lynx below: ! SITE_DEFS = # Your defines here # defines for which there are no configure options: # -DHP_TERMINAL For DIM workaround to REVERSE problems on HP terminals. --- 108,120 ---- # If you apply patches which require linking to site-specific libraries, set # SITE_LIBS to those libraries. ! SITE_LIBS= $(SSL_LIBS) # Your libraries here # Set SITE_LYDEFS to one or more of the defines for the WWW Library: ! SITE_LYDEFS = $(SSL_DEFINES) # Your defines here # Set SITE_DEFS to one or more of the defines for lynx below: ! SITE_DEFS = $(SSL_DEFINES) # Your defines here # defines for which there are no configure options: # -DHP_TERMINAL For DIM workaround to REVERSE problems on HP terminals. 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 Sat Nov 14 07:33:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA10062 for ; Sat, 14 Nov 1998 07:33:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA23491; Sat, 14 Nov 1998 06:18:05 -0600 (CST) From: dickey@clark.net Message-Id: <199811141220.HAA24256@shell.clark.net> Subject: Re: lynx-dev handling the screen in lynxexec To: lynx-dev@sig.net Date: Sat, 14 Nov 1998 07:20:13 -0500 (EST) In-Reply-To: from "Eduardo Chappa L." " at Nov 13, 98 06:39: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: 1103 Lines: 25 > This is a question, whose answer may be that this is not a problem in > lynx, but I want to make sure anyway. > > I installed lynx 2.8.1rel1 in digital unix, with ncursesv4.2. I enabled > local execution of programs. I wrote some programs that I wanted to > execute while still being in lynx, so I added them to my jump file. The > input and output of these program are files. My problem is that if I make > a mistake entering the name of these files while runing the program, the > erase character appears printed in the screen (^H), so if I make a mistake > I have to restart all over again. > > So my question is if this is a problem with ncurses or with lynx, and > if is it there any way to fix it ? Also, I enabled the advanced user mode > and the last line is not erased on the start of the program, my program > writes over it. Is ncurses the problem ? that would be a lynx problem - I'll check to see if there's a simple fix. > 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 Sat Nov 14 07:39:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA10479 for ; Sat, 14 Nov 1998 07:39:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA23830; Sat, 14 Nov 1998 06:22:48 -0600 (CST) From: David Woolley Message-Id: <199811130819.IAA01755@djwhome.demon.co.uk> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? To: lynx-dev@sig.net Date: Fri, 13 Nov 1998 08:19:38 +0000 (GMT) In-Reply-To: from "Leonid Pauzner" at Nov 13, 98 04:59:10 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: 1679 Lines: 34 > > Use cache - always validate cached data (see Note3): A large proportion of web pages these days are uncacheable, often for misguided commercial reasons. I strongly suspect that a disproportionate number of the ones that people will need to view source on or parse in different ways will fall in this category. Pages are becoming uncacheable either because they are dynamically generated or because uncacheability is forced in order to give the page owner, or the web hosting service, better statistics on accesses and accessors. Even the banner adverts on AltaVista are now dynamically generated GIFs as far as any cache is concerned. > use Last-Modified and ETag value from the previous request - > add If-Modified-Since: and If-None-Match: to GET request, > send protocol version as "HTTP/1.1" I think this is a rather strong statement by Lynx; I believe that you must not send this unless you can handle anything permitted by HTTP/1.1 in reply. > If we got 304 (not Modified) status - use cached data, > but update header fields from this new responce. > If we got 200 (OK) status - do as usual but do not forget to pick it up > to the cache, with the flag for user interruption if any happen. > If we got other status - do as usual and NOTHING for cache in any case. RFC 2068 makes user agent caching policies more or less a local issue. Does this new draft spec require user agents to be much more strict? I can think of cases where that would cause a lot of unnecessary refetches of dynamically created pages. Certainly current generation GUI browsers have a strong element of local policy control and are typically set to revalidate only once per session. From owner-lynx-dev@sig.net Sat Nov 14 08:12:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA15542 for ; Sat, 14 Nov 1998 08:12:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA27029; Sat, 14 Nov 1998 06:59:26 -0600 (CST) Date: Sat, 14 Nov 1998 05:01:36 -0800 (PST) From: David Combs Message-Id: <199811141301.FAA03427@netcom15.netcom.com> To: lynx-dev@sig.net Subject: lynx-dev LYNX: in Colorado, vs "other predators" (will lynx survive?) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2376 Lines: 62 I saw this on "Nando News": RETURN TO HEALTH & SCIENCE: [1]NORMAL || [2]LOW-GRAPHICS Lynx to return to Colorado after 25 years' absence Copyright 1998 Nando Media Copyright 1998 The Associated Press DENVER (November 13, 1998 09:15 a.m. EST http://www.nandotimes.com) -- The first of 80 lynx will begin arriving in southwestern Colorado next month in a plan to reintroduce the secretive cats to the state for the first time in nearly 25 years. The Colorado Wildlife Commission approved a plan Thursday to reintroduce lynx to the Weminuche Wilderness, a remote area in the eastern end of the San Juan National Forest. The cats once roamed freely in the area, but biologists believe they were chased away by logging, trapping, construction and ski area development. Forty lynx will be purchased from trappers in Alaska and in Canada's British Columbia, the Yukon and the Northwest Territories, and flown and driven to the high mountain wilderness in December. If all goes well, another 40 will arrive next year. Critics wonder whether the lynx, rarely found south of the Canadian border, can survive. John Seidel, a predator mammals biologist with the Colorado Division of Wildlife overseeing the project, said there are no guarantees. Though he would prefer to get the cats later in the winter, when temperatures are less extreme and the snow depth lower, there is a need to move quickly because the population of the lynx follows cycling of hare populations, usually about every 10 years. Lynx populations now are at a maximum. The lynx, equipped with radio collars, will be closely monitored for the next two to three years to see how they adapt, he said. Biologists want to determine whether the cats have specific habitat preferences in Colorado, whether they are able to compete with other predators for prey, and if they die, why. The Colorado Wildlife Commission's 5-1 decision came less than a month after an environmental group claimed responsibility for fires on Vail Mountain to protest expansion it said would "ruin the last, best lynx habitat in the state." Nobody knows exactly how many lynx roam in the United States, but environmentalists think the figure is fewer than 2,000. By ROBIN MCDOWELL, Associated Press Writer From owner-lynx-dev@sig.net Sat Nov 14 12:26:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA23781 for ; Sat, 14 Nov 1998 12:26:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA27335; Sat, 14 Nov 1998 11:10:38 -0600 (CST) To: lynx-dev@sig.net References: <199811130819.IAA01755@djwhome.demon.co.uk> Message-Id: From: "Leonid Pauzner" Date: Sat, 14 Nov 1998 19:40:59 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 3340 Lines: 66 >> >> Use cache - always validate cached data (see Note3): > A large proportion of web pages these days are uncacheable, often for > misguided commercial reasons. I strongly suspect that a disproportionate > number of the ones that people will need to view source on or parse in > different ways will fall in this category. Thats mostly because Lynx say "HTTP/1.0" in it's header and server reply so. HTTP 1.1 have unique ETag that allow advanced validation for any cached data. So most benefits from lynx cache - to receive short responce like HEAD instead of fetching a complete document (sometimes even a head-like request not needed but this is an obvious check and not for your case). > Pages are becoming uncacheable either because they are dynamically > generated or because uncacheability is forced in order to give the > page owner, or the web hosting service, better statistics on accesses > and accessors. Even the banner adverts on AltaVista are now dynamically > generated GIFs as far as any cache is concerned. >> use Last-Modified and ETag value from the previous request - >> add If-Modified-Since: and If-None-Match: to GET request, >> send protocol version as "HTTP/1.1" > I think this is a rather strong statement by Lynx; I believe that you > must not send this unless you can handle anything permitted by HTTP/1.1 > in reply. This should be carefully inspected, but I feel most HTTP/1.1 things conserns about "transparent proxies" that serve for different clients and so the compatibility, replies to client to made a new request and submit it again, etc. We are in another position: we need HTTP/1.1 client with an optional addition of cache with HTTP 1.1 validation mechanism. You will help me considerably if you read spec and compare against the comments in HTTP.c - actions on return status (200, 304, etc, etc.) >> If we got 304 (not Modified) status - use cached data, >> but update header fields from this new responce. >> If we got 200 (OK) status - do as usual but do not forget to pick it up >> to the cache, with the flag for user interruption if any happen. >> If we got other status - do as usual and NOTHING for cache in any case. > RFC 2068 makes user agent caching policies more or less a local issue. > Does this new draft spec require user agents to be much more strict? I > can think of cases where that would cause a lot of unnecessary refetches of > dynamically created pages. Certainly current generation GUI browsers have > a strong element of local policy control and are typically set to revalidate > only once per session. Read my words in the beginning of this letter. You probably not right: "REFRESH 60 seconds" usually works properly with GUI... If any browser revalidate something once per session it obviously break the spec: there are a special http/1.1 rules for this, for example, Expired or "no-cache" documents should be validated every time we are trying to access them. The rules insist on validating (either by local calculation or with remote) for entry using of cached data, no more nor less. I think we may be a little more strict and ask the remote (server or proxy) for validation when we could do this but too lazy to do our calclulations. Anyway, this is a small overhead and could be easily done when the main code will be implemented (not so easy!). From owner-lynx-dev@sig.net Sat Nov 14 13:52:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA04686 for ; Sat, 14 Nov 1998 13:52:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA09087; Sat, 14 Nov 1998 12:40:22 -0600 (CST) To: lynx-dev@sig.net Message-Id: From: "Leonid Pauzner" Date: Sat, 14 Nov 1998 21:38:20 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev Option Menu: submit button problem 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: 403 Lines: 11 Test: try go forms-based Options Menu and press 'd' on "Accept" button to see what is happen. Occasionally, you download the document thich was before options menu and if you press left arrow key you return back to the document that was before the previous one. Probably my bug from LYPop/LYPush and history stack. Well, does we need something to download if pressing 'd' at submit button? Leonid. From owner-lynx-dev@sig.net Sat Nov 14 16:06:36 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA26114 for ; Sat, 14 Nov 1998 16:06:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA26257; Sat, 14 Nov 1998 14:53:52 -0600 (CST) Message-ID: <19981114132826.A237@mail.bcpl.net> Date: Sat, 14 Nov 1998 13:28:26 -0500 From: Webmaster Jim To: translation@iro.umontreal.ca Cc: Karl Eichwalder , lynx-dev@sig.net Subject: lynx-dev Need translators for Lynx browser Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i 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.93.2i (1998-07-29) 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: 777 Lines: 16 We have incorporated NLS support in the current version of Lynx and would like translations to be done and distributed via the Free Translation Project. For those on the Lynx developers list who have missed the URL for this project, it is: http://www.iro.umontreal.ca/~pinard/ Based on my browsing of the lynx-dev archives for the past week, the developers could also use help in moving the existing code base to gettext(), generating the master catalog, and coordination between users, developers and translators. I am currently unsubscribed from the mailing list because I'm on the road, but will return in a few days. ------ Marvin the Paranoid Android says: Why stop now just when I'm hating it? From owner-lynx-dev@sig.net Sat Nov 14 18:44:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA18482 for ; Sat, 14 Nov 1998 18:44:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA14969; Sat, 14 Nov 1998 17:25:58 -0600 (CST) Date: Sat, 14 Nov 1998 18:27:38 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811141827.AA8693@cas.org> Subject: lynx-dev Question about BASE HREF alert To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 589 Lines: 16 I am seeing the following when I do a trace using lynx 2.8.1dev.2: SGML: Start HTParse: aName:file:/home/lwv26/public_html/ relatedName: HTParse: result: HTML: BASE 'file:/home/lwv26/public_html/' is not an absolute URL. Alert!: HREF in BASE tag is not an absolute URL. Can someone tell me what this msg means? -- 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 Nov 14 20:14:04 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA32642 for ; Sat, 14 Nov 1998 20:13:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA25812; Sat, 14 Nov 1998 18:53:35 -0600 (CST) From: mattack@area.com Date: Sat, 14 Nov 1998 16:55:15 -0800 (PST) X-Sender: mattack@vax To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? In-Reply-To: <199811130819.IAA01755@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: 897 Lines: 23 On Fri, 13 Nov 1998, David Woolley wrote: >Date: Fri, 13 Nov 1998 08:19:38 +0000 (GMT) >From: David Woolley >Reply-To: lynx-dev@sig.net >To: lynx-dev@sig.net >Subject: Re: lynx-dev Why doesn't lynx cache HTML source? > >> >> Use cache - always validate cached data (see Note3): > >A large proportion of web pages these days are uncacheable, often for >misguided commercial reasons. I strongly suspect that a disproportionate >number of the ones that people will need to view source on or parse in >different ways will fall in this category. > >Pages are becoming uncacheable either because they are dynamically >generated or because uncacheability is forced in order to give the Why does dynamic generation make a page uncacheable? Obviously Lynx is getting HTML data, so it could just save that same un- rendered HTML data, so it can show as source or regularly. From owner-lynx-dev@sig.net Sat Nov 14 21:58:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA13959 for ; Sat, 14 Nov 1998 21:57:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA09934; Sat, 14 Nov 1998 20:40:48 -0600 (CST) Date: Sat, 14 Nov 1998 20:42:55 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev 2.8.1rel.2 patches (long) 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: 45274 Lines: 1582 Hello all, I have just re-subscribed to the list, after some time away.. I see lynx dev is alive and well, and has made progress, in spite of the somewhat (hmm...) messy code I left behind. (Sorry Leonid and others.. it probably wasn't much fun cleaning up the chartrans stuff.) I have downloaded 2.8.1rel.2 and played with it. I especially like the partial display stuff. There are some problems I found, among them: - When a longer piece of text is to be highlighted/underlined, like

      some text that is so long that it will occupy several lines when displayed,

      the underlining is lost after the first or second line. (I am surprised nobody noticed this?) - When long lines are split in SOURCE display, and a search target is highlighted on one of the continuation lines, the display is wrong. - There are many memory leaks. Not good if you want to keep lynx running for days. Developers and testers should compile with --enable-find-leaks once in a while, and check Lynx.leaks after running lynx. There are patches for these and some other problems below. (I am sure there are more leaks.) ----- In LYCharUtils.c there is a comment: /* * FIXME: something's wrong with the limit checks here (clearing the * buffer helps). */ memset(replace_buf, 0, sizeof(replace_buf)); Is there any known test case to reproduce the problem? ----- Let me know if there are questions about my past code contributions. (No, I haven't read all the archives, only some recent messages.) Klaus -------------------------------------------------------------------------- Note: patches are against Lynx Version 2.8.1rel.2 Bugs: DefaultStyle.c GridText.c HTML.c LYBookmark.c LYDownload.c LYMain.c LYReadCFG.c LYShowInfo.c UCdomap.c * Include LYLeaks.h in UCdomap.c for memory leak detection. * Fixed various memory leaks (UCdomap.c, LYShowInfo.c, LYReadCFG.c, LYMain.c, LYDownload.c, LYBookmark.c, HTML.c, DefaultStyle.c). * Escape '&' and '<' in HTML generated to display current lynx.cfg option values (LYReadCFG.c). * Revert logic in split_line. Emphasis highlighting that should extend over several lines was being lost at line breaks (GridText.c). (IsSpecialAttrChar probably shouldn't return true for LY_SOFT_NEWLINE since in most places it tests whether to skip a character position, but as long as this special char is only used in SOURCE mode it cannot mess up any anchor positions so it should be ok.) * Correct character counting in SOURCE display continuation lines. A highlighted search target would be shown shifted left by one character position because the LY_SOFT_NEWLINE special was displayed as '+' but not counted (GridText.c). * Prevent generation of invalid/unparseable comments if UCSaveBookmarksInUnicode is in effect, other minor changes in LYBookmark.c. * Correction for color styles in HText_appendCharacter (GridText.c). At some point a memmove was replaced by a for loop, but source and destination were reversed and the counter was wrong. Should-have improvements: GridText.c HTInit.c LYBookmark.c * When adding bookmark entries, don't accept a title string which appears to consist only of blank characters (LYBookmark.c). When rendering a bookmark file, use hiddenlinks=merge counting, so that numbers after entries with empty titles don't get out of whack (GridText.c). This should prevent 'R' from removing the wrong bookmark entry. * Prevent generation of some unnecessary temp files when constructing mailcap file test commands (HTInit.c). Minimal tweaks: GridText.c HTAnchor.c HTFile.c * Check for 'z'ap while constructing local directory listings (non-VMS only, in HTFile.c). * Added a couple outofmem checks (HTAnchor.c). Minor TRACE message change in GridText.c for -tlog / USE_TRACE_LOG disabled. Minor enhancements: GridText.c HTAnchor.c * Don't trim trailing and leading spaces from unformatted text lines in some cases (split_line in GridText.c). Prevents corruption of some uuencoded files when they are displayed and then 'P'rinted (although 'D'ownload should be used instead). * Some changes in HText_appendCharacter (GridText.c). Splitting of long SOURCE lines now works with color styles. * Workaround for multiple anchors in the same (invalid) HTML document with the same NAME and different destinations (HTAnchor.c). *** lynx2-8-1.orig/src/UCdomap.c Thu Sep 17 05:43:48 1998 --- lynx2-8-1/src/UCdomap.c Sat Nov 14 19:34:25 1998 *************** *** 25,30 **** --- 25,32 ---- #include #include + #include + /* * Include tables & parameters. */ *************** *** 1512,1532 **** { int i; int LYhndl = -1; ! char *UC_MIMEcharset = NULL; if (!value || !(*value)) { CTRACE(tfp, "UCGetLYhndl_byMIME: NULL argument instead of MIME name.\n"); return -1; } - StrAllocCopy(UC_MIMEcharset, value); - LYLowerCase(UC_MIMEcharset); - for (i = 0; (i < MAXCHARSETS && i < LYNumCharsets && LYchar_set_names[i]); i++) { if (LYCharSet_UC[i].MIMEname && ! !strcmp(UC_MIMEcharset, LYCharSet_UC[i].MIMEname)) { return i; } } --- 1514,1531 ---- { int i; int LYhndl = -1; ! CONST char *UC_MIMEcharset = value; if (!value || !(*value)) { CTRACE(tfp, "UCGetLYhndl_byMIME: NULL argument instead of MIME name.\n"); return -1; } for (i = 0; (i < MAXCHARSETS && i < LYNumCharsets && LYchar_set_names[i]); i++) { if (LYCharSet_UC[i].MIMEname && ! !strcasecomp(UC_MIMEcharset, LYCharSet_UC[i].MIMEname)) { return i; } } *************** *** 1534,1595 **** /* * Not yet found, try synonyms. - FM */ ! if (!strcmp(UC_MIMEcharset, "unicode-1-1-utf-8") || ! !strcmp(UC_MIMEcharset, "utf8")) { /* * Treat these as synonyms for the IANA registered name. - FM */ return UCGetLYhndl_byMIME("utf-8"); } ! if (!strncmp(UC_MIMEcharset, "iso-2022-jp", 11) || ! !strcmp(UC_MIMEcharset, "x-euc-jp")) { return UCGetLYhndl_byMIME("euc-jp"); } ! if (!strcmp(UC_MIMEcharset, "x-shift-jis")) { return UCGetLYhndl_byMIME("shift_jis"); } ! if (!strcmp(UC_MIMEcharset, "iso-2022-kr")) { return UCGetLYhndl_byMIME("euc-kr"); } ! if (!strcmp(UC_MIMEcharset, "gb2312") || ! !strncmp(UC_MIMEcharset, "cn-gb", 5) || ! !strcmp(UC_MIMEcharset, "iso-2022-cn")) { return UCGetLYhndl_byMIME("euc-cn"); } ! if (!strcmp(UC_MIMEcharset, "cn-big5")) { return UCGetLYhndl_byMIME("big5"); } ! if (!strcmp(UC_MIMEcharset, "x-mac-roman") || ! !strcmp(UC_MIMEcharset, "mac-roman")) { return UCGetLYhndl_byMIME("macintosh"); } ! if (!strcmp(UC_MIMEcharset, "x-next") || ! !strcmp(UC_MIMEcharset, "nextstep") || ! !strcmp(UC_MIMEcharset, "x-nextstep")) { return UCGetLYhndl_byMIME("next"); } ! if (!strcmp(UC_MIMEcharset, "iso-8859-1-windows-3.1-latin-1") || ! !strcmp(UC_MIMEcharset, "cp1252") || ! !strcmp(UC_MIMEcharset, "cp-1252") || ! !strcmp(UC_MIMEcharset, "ibm1252") || ! !strcmp(UC_MIMEcharset, "iso-8859-1-windows-3.0-latin-1")) { /* * Treat these as synonyms for windows-1252, which is more * commonly used than the IANA registered name. - FM */ return UCGetLYhndl_byMIME("windows-1252"); } ! if (!strcmp(UC_MIMEcharset, "iso-8859-2-windows-latin-2") || ! !strcmp(UC_MIMEcharset, "cp1250") || ! !strcmp(UC_MIMEcharset, "cp-1250") || ! !strcmp(UC_MIMEcharset, "ibm1250")) { /* * Treat these as synonyms for windows-1250. - FM */ return UCGetLYhndl_byMIME("windows-1250"); } ! if ((!strncmp(UC_MIMEcharset, "ibm", 3) || ! !strncmp(UC_MIMEcharset, "cp-", 3)) && isdigit((unsigned char)UC_MIMEcharset[3]) && isdigit((unsigned char)UC_MIMEcharset[4]) && isdigit((unsigned char)UC_MIMEcharset[5])) { --- 1533,1594 ---- /* * Not yet found, try synonyms. - FM */ ! if (!strcasecomp(UC_MIMEcharset, "unicode-1-1-utf-8") || ! !strcasecomp(UC_MIMEcharset, "utf8")) { /* * Treat these as synonyms for the IANA registered name. - FM */ return UCGetLYhndl_byMIME("utf-8"); } ! if (!strncasecomp(UC_MIMEcharset, "iso-2022-jp", 11) || ! !strcasecomp(UC_MIMEcharset, "x-euc-jp")) { return UCGetLYhndl_byMIME("euc-jp"); } ! if (!strcasecomp(UC_MIMEcharset, "x-shift-jis")) { return UCGetLYhndl_byMIME("shift_jis"); } ! if (!strcasecomp(UC_MIMEcharset, "iso-2022-kr")) { return UCGetLYhndl_byMIME("euc-kr"); } ! if (!strcasecomp(UC_MIMEcharset, "gb2312") || ! !strncasecomp(UC_MIMEcharset, "cn-gb", 5) || ! !strcasecomp(UC_MIMEcharset, "iso-2022-cn")) { return UCGetLYhndl_byMIME("euc-cn"); } ! if (!strcasecomp(UC_MIMEcharset, "cn-big5")) { return UCGetLYhndl_byMIME("big5"); } ! if (!strcasecomp(UC_MIMEcharset, "x-mac-roman") || ! !strcasecomp(UC_MIMEcharset, "mac-roman")) { return UCGetLYhndl_byMIME("macintosh"); } ! if (!strcasecomp(UC_MIMEcharset, "x-next") || ! !strcasecomp(UC_MIMEcharset, "nextstep") || ! !strcasecomp(UC_MIMEcharset, "x-nextstep")) { return UCGetLYhndl_byMIME("next"); } ! if (!strcasecomp(UC_MIMEcharset, "iso-8859-1-windows-3.1-latin-1") || ! !strcasecomp(UC_MIMEcharset, "cp1252") || ! !strcasecomp(UC_MIMEcharset, "cp-1252") || ! !strcasecomp(UC_MIMEcharset, "ibm1252") || ! !strcasecomp(UC_MIMEcharset, "iso-8859-1-windows-3.0-latin-1")) { /* * Treat these as synonyms for windows-1252, which is more * commonly used than the IANA registered name. - FM */ return UCGetLYhndl_byMIME("windows-1252"); } ! if (!strcasecomp(UC_MIMEcharset, "iso-8859-2-windows-latin-2") || ! !strcasecomp(UC_MIMEcharset, "cp1250") || ! !strcasecomp(UC_MIMEcharset, "cp-1250") || ! !strcasecomp(UC_MIMEcharset, "ibm1250")) { /* * Treat these as synonyms for windows-1250. - FM */ return UCGetLYhndl_byMIME("windows-1250"); } ! if ((!strncasecomp(UC_MIMEcharset, "ibm", 3) || ! !strncasecomp(UC_MIMEcharset, "cp-", 3)) && isdigit((unsigned char)UC_MIMEcharset[3]) && isdigit((unsigned char)UC_MIMEcharset[4]) && isdigit((unsigned char)UC_MIMEcharset[5])) { *************** *** 1615,1621 **** FREE(cptmp); return LYhndl; } ! if (!strncmp(UC_MIMEcharset, "windows-", 8) && isdigit((unsigned char)UC_MIMEcharset[8]) && isdigit((unsigned char)UC_MIMEcharset[9]) && isdigit((unsigned char)UC_MIMEcharset[10])) { --- 1614,1620 ---- FREE(cptmp); return LYhndl; } ! if (!strncasecomp(UC_MIMEcharset, "windows-", 8) && isdigit((unsigned char)UC_MIMEcharset[8]) && isdigit((unsigned char)UC_MIMEcharset[9]) && isdigit((unsigned char)UC_MIMEcharset[10])) { *************** *** 1631,1637 **** FREE(cptmp); return LYhndl; } ! if (!strcmp(UC_MIMEcharset, "koi-8")) { /* accentsoft bugosity */ return UCGetLYhndl_byMIME("koi8-r"); } } --- 1630,1636 ---- FREE(cptmp); return LYhndl; } ! if (!strcasecomp(UC_MIMEcharset, "koi-8")) { /* accentsoft bugosity */ return UCGetLYhndl_byMIME("koi8-r"); } } *** lynx2-8-1.orig/src/HTML.c Sat Oct 17 16:20:41 1998 --- lynx2-8-1/src/HTML.c Sat Nov 14 19:34:25 1998 *************** *** 78,91 **** /* .... */ }; ! PRIVATE HTStyleSheet * styleSheet; /* Application-wide */ /* Module-wide style cache */ PRIVATE HTStyle *styles[HTML_ELEMENTS+31]; /* adding 24 nested list styles */ /* and 3 header alignment styles */ /* and 3 div alignment styles */ ! PRIVATE HTStyle *default_style; PUBLIC char *LYToolbarName = "LynxPseudoToolbar"; --- 78,91 ---- /* .... */ }; ! PRIVATE HTStyleSheet * styleSheet = NULL; /* Application-wide */ /* Module-wide style cache */ PRIVATE HTStyle *styles[HTML_ELEMENTS+31]; /* adding 24 nested list styles */ /* and 3 header alignment styles */ /* and 3 div alignment styles */ ! PRIVATE HTStyle *default_style = NULL; PUBLIC char *LYToolbarName = "LynxPseudoToolbar"; *************** *** 2735,2744 **** if (*alt_string == '\0') { if (map_href) { StrAllocCopy(alt_string, (title ? title : ! MakeNewMapValue(value,"USEMAP"))); } else if (dest_ismap) { StrAllocCopy(alt_string, (title ? title : ! MakeNewMapValue(value,"ISMAP"))); } else if (me->inA == TRUE && dest) { StrAllocCopy(alt_string, (title ? --- 2735,2746 ---- if (*alt_string == '\0') { if (map_href) { StrAllocCopy(alt_string, (title ? title : ! (temp = MakeNewMapValue(value,"USEMAP")))); ! FREE(temp); } else if (dest_ismap) { StrAllocCopy(alt_string, (title ? title : ! (temp = MakeNewMapValue(value,"ISMAP")))); ! FREE(temp); } else if (me->inA == TRUE && dest) { StrAllocCopy(alt_string, (title ? *************** *** 2758,2769 **** } else if (map_href) { StrAllocCopy(alt_string, (title ? title : ! MakeNewMapValue(value,"USEMAP"))); } else if ((dest_ismap == TRUE) || (me->inA && present && present[HTML_IMG_ISMAP])) { StrAllocCopy(alt_string, (title ? title : ! MakeNewMapValue(value,"ISMAP"))); } else if (me->inA == TRUE && dest) { StrAllocCopy(alt_string, (title ? --- 2760,2773 ---- } else if (map_href) { StrAllocCopy(alt_string, (title ? title : ! (temp = MakeNewMapValue(value,"USEMAP")))); ! FREE(temp); } else if ((dest_ismap == TRUE) || (me->inA && present && present[HTML_IMG_ISMAP])) { StrAllocCopy(alt_string, (title ? title : ! (temp = MakeNewMapValue(value,"ISMAP")))); ! FREE(temp); } else if (me->inA == TRUE && dest) { StrAllocCopy(alt_string, (title ? *************** *** 2782,2788 **** title : "")); } if (*alt_string == '\0' && map_href) { ! StrAllocCopy(alt_string, MakeNewMapValue(value,"USEMAP")); } CTRACE(tfp, "HTML IMG: USEMAP=%d ISMAP=%d ANCHOR=%d PARA=%d\n", --- 2786,2793 ---- title : "")); } if (*alt_string == '\0' && map_href) { ! StrAllocCopy(alt_string, (temp = MakeNewMapValue(value,"USEMAP"))); ! FREE(temp); } CTRACE(tfp, "HTML IMG: USEMAP=%d ISMAP=%d ANCHOR=%d PARA=%d\n", *************** *** 2844,2850 **** if (dest_ismap) { HTML_put_character(me, ' '); me->in_word = NO; ! HTML_put_string(me, MakeNewMapValue(value,"ISMAP")); } else if (dest) { HTML_put_character(me, ' '); me->in_word = NO; --- 2849,2856 ---- if (dest_ismap) { HTML_put_character(me, ' '); me->in_word = NO; ! HTML_put_string(me, (temp = MakeNewMapValue(value,"ISMAP"))); ! FREE(temp); } else if (dest) { HTML_put_character(me, ' '); me->in_word = NO; *************** *** 2900,2905 **** --- 2906,2912 ---- HText_endAnchor(me->text, me->CurrentANum); me->CurrentANum = 0; HTML_put_character(me, '-'); + FREE(newtitle); StrAllocCopy(alt_string, ((present && present[HTML_IMG_ISOBJECT]) ? *************** *** 2956,2961 **** --- 2963,2969 ---- HText_endAnchor(me->text, me->CurrentANum); me->CurrentANum = 0; HTML_put_character(me, '-'); + FREE(newtitle); StrAllocCopy(alt_string, ((present && present[HTML_IMG_ISOBJECT]) ? *************** *** 3012,3018 **** if (dest_ismap) { HTML_put_character(me, ' ');/* space char may be ignored */ me->in_word = NO; ! HTML_put_string(me, MakeNewMapValue(value,"ISMAP")); } else if (dest) { HTML_put_character(me, ' ');/* space char may be ignored */ me->in_word = NO; --- 3020,3027 ---- if (dest_ismap) { HTML_put_character(me, ' ');/* space char may be ignored */ me->in_word = NO; ! HTML_put_string(me, (temp = MakeNewMapValue(value,"ISMAP"))); ! FREE(temp); } else if (dest) { HTML_put_character(me, ' ');/* space char may be ignored */ me->in_word = NO; *************** *** 4398,4404 **** * We have a TYPE="image" with a non-zero-length SRC * attribute and want clickable images. Make the * SRC's value a link if it's still not zero-length ! * legitiimizing it. - FM */ url_type = LYLegitimizeHREF(me, &href, TRUE, TRUE); if (*href) { --- 4407,4413 ---- * We have a TYPE="image" with a non-zero-length SRC * attribute and want clickable images. Make the * SRC's value a link if it's still not zero-length ! * legitimizing it. - FM */ url_type = LYLegitimizeHREF(me, &href, TRUE, TRUE); if (*href) { *************** *** 4436,4441 **** --- 4445,4451 ---- if (me->inBoldH == FALSE) HText_appendCharacter(me->text, LY_BOLD_START_CHAR); HTML_put_string(me, VERBOSE_IMG(value,HTML_INPUT_SRC,"[IMAGE]")); + FREE(newtitle); if (me->inBoldH == FALSE) HText_appendCharacter(me->text, LY_BOLD_END_CHAR); HText_endAnchor(me->text, 0); *************** *** 4687,4692 **** --- 4697,4703 ---- } } HText_setIgnoreExcess(me->text, FALSE); + FREE(ImageSrc); FREE(I_value); FREE(I_name); } *** lynx2-8-1.orig/src/LYReadCFG.c Sat Oct 24 11:49:07 1998 --- lynx2-8-1/src/LYReadCFG.c Sat Nov 14 19:34:25 1998 *************** *** 7,12 **** --- 7,13 ---- #include #include #include + #include #include #include #include *************** *** 969,974 **** --- 970,977 ---- {0} }; + PRIVATE char *local_url = NULL; + /* * Free memory allocated in 'read_cfg()' */ *************** *** 993,998 **** --- 996,1002 ---- break; } } + FREE(local_url); } /* *************** *** 1191,1198 **** break; #endif default: ! if (fp0 != 0) ! fprintf(fp0, "%s:%s\n", name, value); break; } } --- 1195,1211 ---- break; #endif default: ! if (fp0 != 0) { ! if (strchr(value, '&') || strchr(value, '<')) { ! char *cp1 = NULL; ! StrAllocCopy(cp1, value); ! LYEntify(&cp1, TRUE); ! fprintf(fp0, "%s:%s\n", name, cp1); ! FREE(cp1); ! } else { ! fprintf(fp0, "%s:%s\n", name, value); ! } ! } break; } } *************** *** 1238,1244 **** */ PUBLIC char *lynx_cfg_infopage NOARGS { - static char *local_url; char tempfile[LY_MAXPATH]; char *temp = 0; FILE *fp0; --- 1251,1256 ---- *** lynx2-8-1.orig/src/DefaultStyle.c Thu Aug 6 07:28:22 1998 --- lynx2-8-1/src/DefaultStyle.c Sat Nov 14 19:34:25 1998 *************** *** 363,371 **** PRIVATE HTStyleSheet sheet = { "default.style", &HTStyleHeadingRight }; /* sheet */ PUBLIC HTStyleSheet * DefaultStyle NOARGS { - static HTStyleSheet *result; HTStyle *p, *q; /* --- 363,383 ---- PRIVATE HTStyleSheet sheet = { "default.style", &HTStyleHeadingRight }; /* sheet */ + + PRIVATE HTStyleSheet *result = NULL; + + PRIVATE void FreeDefaultStyle NOARGS + { + HTStyle * style; + while((style=result->styles)!=0) { + result->styles = style->next; + FREE(style); + } + FREE(result); + } + PUBLIC HTStyleSheet * DefaultStyle NOARGS { HTStyle *p, *q; /* *************** *** 378,383 **** --- 390,396 ---- result = HTStyleSheetNew (); *result = sheet; result->styles = 0; + atexit(FreeDefaultStyle); for (p = sheet.styles; p != 0; p = p->next) { q = HTStyleNew (); *q = *p; *************** *** 389,397 **** p != 0 && q != 0; p = p->next, q = q->next) { HTStyle *r = p->next; - HTStyle temp; - temp = *p; - temp.next = q->next; *p = *q; p->next = r; } --- 402,407 ---- *** lynx2-8-1.orig/src/LYMain.c Sat Oct 24 11:49:07 1998 --- lynx2-8-1/src/LYMain.c Sat Nov 14 19:34:25 1998 *************** *** 75,81 **** #endif /* VMS */ #ifndef VMS ! PUBLIC char *lynx_version_putenv_command = NULL; PUBLIC char *list_format = NULL; /* LONG_LIST formatting mask */ #ifdef SYSLOG_REQUESTED_URLS PUBLIC char *syslog_txt = NULL; /* syslog arb text for session */ --- 75,81 ---- #endif /* VMS */ #ifndef VMS ! PRIVATE char *lynx_version_putenv_command = NULL; PUBLIC char *list_format = NULL; /* LONG_LIST formatting mask */ #ifdef SYSLOG_REQUESTED_URLS PUBLIC char *syslog_txt = NULL; /* syslog arb text for session */ *************** *** 486,495 **** --- 486,503 ---- FREE(URLDomainSuffixes); FREE(XLoadImageCommand); FREE(LYTraceLogPath); + FREE(lynx_cfg_file); #if defined(USE_HASH) FREE(lynx_lss_file); #endif FREE(UCAssume_MIMEcharset); + { + char *p = LYlist_temp_url(); + if (p && *p) { + *p = '\0'; + FREE(p); + } + } for (i = 0; i < nlinks; i++) { FREE(links[i].lname); } *************** *** 696,701 **** --- 704,710 ---- StrAllocCopy(lynx_version_putenv_command, "LYNX_VERSION="); StrAllocCat(lynx_version_putenv_command, LYNX_VERSION); putenv(lynx_version_putenv_command); + FREE(lynx_version_putenv_command); #endif /* VMS */ if ((cp = getenv("LYNX_TEMP_SPACE")) != NULL) *** lynx2-8-1.orig/src/LYShowInfo.c Sat Oct 17 16:20:41 1998 --- lynx2-8-1/src/LYShowInfo.c Sat Nov 14 19:34:25 1998 *************** *** 82,88 **** char *, owner_address) { static char tempfile[LY_MAXPATH]; - static char *info_url; int url_type; FILE *fp0; char *Address = NULL, *Title = NULL; --- 82,87 ---- *************** *** 101,112 **** return(-1); } - LYLocalFileToURL(&info_url, tempfile); /* * Point the address pointer at this Url */ ! StrAllocCopy(newdoc->address, info_url); if (nlinks > 0 && links[doc->link].lname != NULL && (url_type = is_url(links[doc->link].lname)) != 0 && --- 100,111 ---- return(-1); } /* * Point the address pointer at this Url */ ! LYLocalFileToURL(&newdoc->address, tempfile); ! if (nlinks > 0 && links[doc->link].lname != NULL && (url_type = is_url(links[doc->link].lname)) != 0 && *** lynx2-8-1.orig/src/GridText.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/GridText.c Sat Nov 14 19:34:25 1998 *************** *** 464,472 **** /* * If we are going to render the List Page, always merge in hidden * links to get the numbering consistent if form fields are numbered ! * and show up as hidden links in the list of links. - kw */ ! if (anchor->address && !strcmp(anchor->address, LYlist_temp_url())) self->hiddenlinkflag = HIDDENLINKS_MERGE; else self->hiddenlinkflag = LYHiddenLinks; --- 464,477 ---- /* * If we are going to render the List Page, always merge in hidden * links to get the numbering consistent if form fields are numbered ! * and show up as hidden links in the list of links. ! * If we are going to render a bookmark file, also always merge in ! * hidden links, to get the link numbers consistent with the counting ! * in remove_bookmark_link(). Normally a bookmark file shouldn't ! * contain any entries with empty titles, but it might happen. - kw */ ! if (anchor->bookmark || ! (anchor->address && !strcmp(anchor->address, LYlist_temp_url()))) self->hiddenlinkflag = HIDDENLINKS_MERGE; else self->hiddenlinkflag = LYHiddenLinks; *************** *** 1208,1214 **** for (; written < len && (tmp[0] = data[itmp]) != '\0'; itmp++) { ! if (IsSpecialAttrChar(tmp[0])) { /* * Ignore special characters. */ --- 1213,1219 ---- for (; written < len && (tmp[0] = data[itmp]) != '\0'; itmp++) { ! if (IsSpecialAttrChar(tmp[0]) && tmp[0] != LY_SOFT_NEWLINE) { /* * Ignore special characters. */ *************** *** 1714,1721 **** if (line->numstyles > 0 && line->numstyles < MAX_STYLES_ON_LINE) { int n; inew ++; ! for (n = line->numstyles; n >= 0; n--) ! line->styles[n + inew] = line->styles[n]; } else if (line->numstyles == 0) /* FIXME: RJP - shouldn't use 0xffffffff for largest integer */ --- 1719,1726 ---- if (line->numstyles > 0 && line->numstyles < MAX_STYLES_ON_LINE) { int n; inew ++; ! for (n = 0; n < line->numstyles; n++) ! line->styles[n] = line->styles[n + inew]; } else if (line->numstyles == 0) /* FIXME: RJP - shouldn't use 0xffffffff for largest integer */ *************** *** 1754,1760 **** if (split > 0) { /* Delete space at "split" splitting line */ char *p, *prevdata = previous->data, *linedata = line->data; unsigned plen; ! unsigned i; /* * Split the line. - FM --- 1759,1765 ---- if (split > 0) { /* Delete space at "split" splitting line */ char *p, *prevdata = previous->data, *linedata = line->data; unsigned plen; ! int i; /* * Split the line. - FM *************** *** 1767,1773 **** * of our new line. - FM */ p = prevdata + split; ! while (*p == ' ' || *p == LY_SOFT_HYPHEN) { p++; HeadTrim++; } --- 1772,1784 ---- * of our new line. - FM */ p = prevdata + split; ! while ((*p == ' ' && ! (HeadTrim || text->first_anchor || ! underline_on || bold_on || ! text->style->alignment != HT_LEFT || ! text->style->wordWrap || text->style->freeFormat || ! text->style->spaceBefore || text->style->spaceAfter)) || ! *p == LY_SOFT_HYPHEN) { p++; HeadTrim++; } *************** *** 1782,1788 **** */ underline_on = NO; if (split) { ! for (i = (split-1); i != 0; i--) { if (prevdata[i] == LY_UNDERLINE_END_CHAR) { break; } --- 1793,1799 ---- */ underline_on = NO; if (split) { ! for (i = (split-1); i >= 0; i--) { if (prevdata[i] == LY_UNDERLINE_END_CHAR) { break; } *************** *** 1802,1808 **** SpecialAttrChars++; } if (plen) { ! for (i = (plen - 1); i != 0; i--) { if (p[i] == LY_UNDERLINE_START_CHAR) { underline_on = YES; break; --- 1813,1819 ---- SpecialAttrChars++; } if (plen) { ! for (i = (plen - 1); i >= 0; i--) { if (p[i] == LY_UNDERLINE_START_CHAR) { underline_on = YES; break; *************** *** 1812,1818 **** break; } } ! for (i = (plen - 1); i != 0; i--) { if (p[i] == LY_UNDERLINE_START_CHAR || p[i] == LY_UNDERLINE_END_CHAR) { ctrl_chars_on_this_line++; --- 1823,1829 ---- break; } } ! for (i = (plen - 1); i >= 0; i--) { if (p[i] == LY_UNDERLINE_START_CHAR || p[i] == LY_UNDERLINE_END_CHAR) { ctrl_chars_on_this_line++; *************** *** 1827,1833 **** */ bold_on = NO; if (split) { ! for (i = (split - 1); i != 0; i--) { if (prevdata[i] == LY_BOLD_END_CHAR) { break; } --- 1838,1844 ---- */ bold_on = NO; if (split) { ! for (i = (split - 1); i >= 0; i--) { if (prevdata[i] == LY_BOLD_END_CHAR) { break; } *************** *** 1845,1854 **** linedata[line->size] = '\0'; ctrl_chars_on_this_line++; SpecialAttrChars++;; ! } else ! bold_on = OFF; if (plen) { ! for (i = (plen - 1); i != 0; i--) { if (p[i] == LY_BOLD_START_CHAR) { bold_on = YES; break; --- 1856,1864 ---- linedata[line->size] = '\0'; ctrl_chars_on_this_line++; SpecialAttrChars++;; ! } if (plen) { ! for (i = (plen - 1); i >= 0; i--) { if (p[i] == LY_BOLD_START_CHAR) { bold_on = YES; break; *************** *** 1858,1871 **** break; } } ! for (i = (plen - 1); i != 0; i--) { if (p[i] == LY_BOLD_START_CHAR || p[i] == LY_BOLD_END_CHAR || IS_UTF_EXTRA(p[i]) || p[i] == LY_SOFT_HYPHEN) { ctrl_chars_on_this_line++; } ! if (p[i] == LY_SOFT_HYPHEN && text->permissible_split < i) { text->permissible_split = i + 1; } } --- 1868,1881 ---- break; } } ! for (i = (plen - 1); i >= 0; i--) { if (p[i] == LY_BOLD_START_CHAR || p[i] == LY_BOLD_END_CHAR || IS_UTF_EXTRA(p[i]) || p[i] == LY_SOFT_HYPHEN) { ctrl_chars_on_this_line++; } ! if (p[i] == LY_SOFT_HYPHEN && (int)text->permissible_split < i) { text->permissible_split = i + 1; } } *************** *** 1882,1888 **** * Economize on space. */ while ((previous->size > 0) && ! (previous->data[previous->size-1] == ' ')) { /* * Strip trailers. */ --- 1892,1903 ---- * Economize on space. */ while ((previous->size > 0) && ! (previous->data[previous->size-1] == ' ') && ! (ctrl_chars_on_this_line || HeadTrim || text->first_anchor || ! underline_on || bold_on || ! text->style->alignment != HT_LEFT || ! text->style->wordWrap || text->style->freeFormat || ! text->style->spaceBefore || text->style->spaceAfter)) { /* * Strip trailers. */ *************** *** 1908,1930 **** /* * Align left, right or center. */ ! for (cp = previous->data; *cp; cp++) { ! if (*cp == LY_UNDERLINE_START_CHAR || ! *cp == LY_UNDERLINE_END_CHAR || ! *cp == LY_BOLD_START_CHAR || ! *cp == LY_BOLD_END_CHAR || ! IS_UTF_EXTRA(*cp) || ! *cp == LY_SOFT_HYPHEN) ! ctrl_chars_on_previous_line++; ! } ! /* @@ first line indent */ ! spare = (LYcols-1) - ! (int)style->rightIndent - indent + ! ctrl_chars_on_previous_line - previous->size - ! ((previous->size > 0) && ! (int)(previous->data[previous->size-1] == ! LY_SOFT_HYPHEN ? ! 1 : 0)); switch (style->alignment) { case HT_CENTER : --- 1923,1950 ---- /* * Align left, right or center. */ ! spare = 0; ! if (style->alignment == HT_CENTER || ! style->alignment == HT_RIGHT) { ! /* Calculate spare character positions if needed */ ! for (cp = previous->data; *cp; cp++) { ! if (*cp == LY_UNDERLINE_START_CHAR || ! *cp == LY_UNDERLINE_END_CHAR || ! *cp == LY_BOLD_START_CHAR || ! *cp == LY_BOLD_END_CHAR || ! IS_UTF_EXTRA(*cp) || ! *cp == LY_SOFT_HYPHEN) ! ctrl_chars_on_previous_line++; ! } ! /* @@ first line indent */ ! spare = (LYcols-1) - ! (int)style->rightIndent - indent + ! ctrl_chars_on_previous_line - previous->size - ! ((previous->size > 0) && ! (int)(previous->data[previous->size-1] == ! LY_SOFT_HYPHEN ? ! 1 : 0)); ! } switch (style->alignment) { case HT_CENTER : *************** *** 2280,2286 **** return; } ! if (IsSpecialAttrChar(ch)) { #ifndef USE_COLOR_STYLE if (line->size >= (MAX_LINE-1)) return; if (ch == LY_UNDERLINE_START_CHAR) { --- 2300,2306 ---- return; } ! if (IsSpecialAttrChar(ch) && ch != LY_SOFT_NEWLINE) { #ifndef USE_COLOR_STYLE if (line->size >= (MAX_LINE-1)) return; if (ch == LY_UNDERLINE_START_CHAR) { *************** *** 2309,2319 **** bold_on = OFF; ctrl_chars_on_this_line++; return; - } else if (ch == LY_SOFT_NEWLINE) { - line->data[line->size++] = LY_SOFT_NEWLINE; - line->data[line->size] = '\0'; - ctrl_chars_on_this_line++; - return; } else if (ch == LY_SOFT_HYPHEN) { int i; --- 2329,2334 ---- *************** *** 2341,2346 **** --- 2356,2365 ---- #else return; #endif + } else if (ch == LY_SOFT_NEWLINE) { + line->data[line->size++] = LY_SOFT_NEWLINE; + line->data[line->size] = '\0'; + return; } if (IS_UTF_EXTRA(ch)) { *************** *** 4064,4070 **** int, line_num, char *, target) { ! CTRACE(tfp, "GridText: HText_pageDisplay at line %d started\n", line_num); #ifdef DISP_PARTIAL if (display_partial && detected_forms_input_partial) { --- 4083,4091 ---- int, line_num, char *, target) { ! if (debug_display_partial || (LYTraceLogFP != NULL)) { ! CTRACE(tfp, "GridText: HText_pageDisplay at line %d started\n", line_num); ! } #ifdef DISP_PARTIAL if (display_partial && detected_forms_input_partial) { *************** *** 4091,4097 **** is_www_index = HTAnchor_isIndex(HTMainAnchor); ! CTRACE(tfp, "GridText: HText_pageDisplay finished\n"); } /* --- 4112,4120 ---- is_www_index = HTAnchor_isIndex(HTMainAnchor); ! if (debug_display_partial || (LYTraceLogFP != NULL)) { ! CTRACE(tfp, "GridText: HText_pageDisplay finished\n"); ! } } /* *** lynx2-8-1.orig/src/HTInit.c Thu Sep 17 05:43:48 1998 --- lynx2-8-1/src/HTInit.c Sat Nov 14 19:34:25 1998 *************** *** 532,540 **** /* * Build the command and execute it. */ ! if (LYOpenTemp(TmpFileName, HTML_SUFFIX, "w") == 0) ! ExitWithError(CANNOT_OPEN_TEMP); ! LYCloseTemp(TmpFileName); cmd = (char *)malloc(1024); if (!cmd) ExitWithError("Out of memory"); --- 532,545 ---- /* * Build the command and execute it. */ ! if (strchr(mc->testcommand, '%')) { ! if (LYOpenTemp(TmpFileName, HTML_SUFFIX, "w") == 0) ! ExitWithError(CANNOT_OPEN_TEMP); ! LYCloseTemp(TmpFileName); ! } else { ! /* We normally don't need a temp file name - kw */ ! TmpFileName[0] = '\0'; ! } cmd = (char *)malloc(1024); if (!cmd) ExitWithError("Out of memory"); *************** *** 545,551 **** CTRACE(tfp, "PassesTest: Executing test command: %s\n", cmd); result = LYSystem(cmd); FREE(cmd); ! LYRemoveTemp(TmpFileName); /* * Free the test command as well since --- 550,557 ---- CTRACE(tfp, "PassesTest: Executing test command: %s\n", cmd); result = LYSystem(cmd); FREE(cmd); ! if (TmpFileName[0]) ! LYRemoveTemp(TmpFileName); /* * Free the test command as well since *** lynx2-8-1.orig/src/LYDownload.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/LYDownload.c Sat Nov 14 19:34:25 1998 *************** *** 608,613 **** --- 608,614 ---- fprintf(fp0, "\ Downloaded link: %s\n", downloaded_url); + FREE(downloaded_url); fprintf(fp0, "\ Suggested file name: %s\n", *** lynx2-8-1.orig/src/LYBookmark.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/LYBookmark.c Sat Nov 14 19:34:25 1998 *************** *** 7,12 **** --- 7,13 ---- #include #include #include /* need for META charset */ + #include #include /* need for LYHaveCJKCharacterSet */ #include #include *************** *** 171,178 **** return(newfile); } ! PRIVATE BOOLEAN have8bit PARAMS((char *Title)); ! PRIVATE char* title_convert8bit PARAMS((char *Title)); /* * Adds a link to a bookmark file, creating the file --- 172,180 ---- return(newfile); } ! PRIVATE BOOLEAN havevisible PARAMS((CONST char *Title)); ! PRIVATE BOOLEAN have8bit PARAMS((CONST char *Title)); ! PRIVATE char* title_convert8bit PARAMS((CONST char *Title)); /* * Adds a link to a bookmark file, creating the file *************** *** 260,275 **** * Allow user to change the title. - FM */ string_buffer[255] = '\0'; ! LYstrncpy(string_buffer, title, 255); ! convert_to_spaces(string_buffer, FALSE); ! LYMBM_statusline(TITLE_PROMPT); ! LYgetstr(string_buffer, VISIBLE, sizeof(string_buffer), NORECALL); ! if (*string_buffer == '\0') { ! LYMBM_statusline(CANCELLED); ! sleep(MessageSecs); ! FREE(bookmark_URL); ! return; ! } /* * Create the Title with any left-angle-brackets --- 262,279 ---- * Allow user to change the title. - FM */ string_buffer[255] = '\0'; ! do { ! LYstrncpy(string_buffer, title, 255); ! convert_to_spaces(string_buffer, FALSE); ! LYMBM_statusline(TITLE_PROMPT); ! LYgetstr(string_buffer, VISIBLE, sizeof(string_buffer), NORECALL); ! if (*string_buffer == '\0') { ! LYMBM_statusline(CANCELLED); ! sleep(MessageSecs); ! FREE(bookmark_URL); ! return; ! } ! } while(!havevisible(string_buffer)); /* * Create the Title with any left-angle-brackets *************** *** 283,290 **** StrAllocCopy(Title, string_buffer); LYEntify(&Title, TRUE); if (UCSaveBookmarksInUnicode && ! have8bit(Title) && (!LYHaveCJKCharacterSet)) ! StrAllocCopy(Title, title_convert8bit(Title)); /* * Create the bookmark file, if it doesn't exist already, --- 287,297 ---- StrAllocCopy(Title, string_buffer); LYEntify(&Title, TRUE); if (UCSaveBookmarksInUnicode && ! have8bit(Title) && (!LYHaveCJKCharacterSet)) { ! char *p = title_convert8bit(Title); ! FREE(Title); ! Title = p; ! } /* * Create the bookmark file, if it doesn't exist already, *************** *** 877,885 **** } /* * Check whether string have 8 bit chars. */ ! PRIVATE BOOLEAN have8bit ARGS1(char *, Title) { CONST char *p = Title; --- 884,921 ---- } /* + * Check whether we have any visible (non-blank) chars. + */ + PRIVATE BOOLEAN havevisible ARGS1(CONST char *, Title) + { + CONST char *p = Title; + unsigned char c; + long unicode; + + for ( ; *p; p++) { + c = (unsigned char)(TOASCII(*p)); + if (c > 32 && c < 127) + return(TRUE); + if (c <= 32 || c == 127) + continue; + if (LYHaveCJKCharacterSet || !UCCanUniTranslateFrom(current_char_set)) + return(TRUE); + unicode = UCTransToUni(*p, current_char_set); + if (unicode > 32 && unicode < 127) + return(TRUE); + if (c <= 32 || (c >= 127 && c <= 160) || c == 0xad) + continue; + if (unicode >= 0x2000 && unicode < 0x200f) + continue; + return(TRUE); + } + return(FALSE); /* if we came here */ + } + + /* * Check whether string have 8 bit chars. */ ! PRIVATE BOOLEAN have8bit ARGS1(CONST char *, Title) { CONST char *p = Title; *************** *** 909,922 **** * Older versions fail. * */ ! PRIVATE char* title_convert8bit ARGS1(char *, Title) { CONST char *p = Title; char temp[256]; char *q = temp; char *comment = NULL; char *ncr = NULL; char *buf = NULL; for ( ; *p; p++) { LYstrncpy(q, p, 1); --- 945,961 ---- * Older versions fail. * */ ! PRIVATE char* title_convert8bit ARGS1(CONST char *, Title) { CONST char *p = Title; char temp[256]; + char *p0; char *q = temp; char *comment = NULL; char *ncr = NULL; char *buf = NULL; + int charset_in = current_char_set; + int charset_out = -1; for ( ; *p; p++) { LYstrncpy(q, p, 1); *************** *** 924,935 **** StrAllocCat(comment, q); StrAllocCat(ncr, q); } else { ! int charset_in, charset_out, uck; long unicode; char replace_buf [10], replace_buf2 [10]; ! charset_in = current_char_set; ! charset_out = UCGetLYhndl_byMIME("us-ascii"); uck = UCTransCharStr(replace_buf, sizeof(replace_buf), *q, charset_in, charset_out, YES); --- 963,974 ---- StrAllocCat(comment, q); StrAllocCat(ncr, q); } else { ! int uck; long unicode; char replace_buf [10], replace_buf2 [10]; ! if (charset_out < 0) ! charset_out = UCGetLYhndl_byMIME("us-ascii"); uck = UCTransCharStr(replace_buf, sizeof(replace_buf), *q, charset_in, charset_out, YES); *************** *** 946,951 **** --- 985,1003 ---- } /* + * Cleanup comment, collapse multiple dashes into one dash, + * skip '>'. + */ + for (q = p0 = comment; *p0; p0++) { + if ((unsigned char)(TOASCII(*p0)) >= 32 && + *p0 != '>' && + (q == comment || *p0 != '-' || *(q-1) != '-')) { + *q++ = *p0; + } + } + *q = '\0'; + + /* * valid bookmark should be a single line (no linebreaks!). */ StrAllocCat(buf, ""); StrAllocCat(buf, ncr); + FREE(comment); + FREE(ncr); return(buf); } *** lynx2-8-1.orig/WWW/Library/Implementation/HTAnchor.c Sun Sep 13 09:35:55 1998 --- lynx2-8-1/WWW/Library/Implementation/HTAnchor.c Sat Nov 14 19:35:03 1998 *************** *** 68,73 **** --- 68,75 ---- { HTParentAnchor *newAnchor = (HTParentAnchor *)calloc(1, sizeof(HTParentAnchor)); /* zero-filled */ + if (newAnchor == NULL) + outofmem(__FILE__, "HTParentAnchor_new"); newAnchor->parent = newAnchor; newAnchor->bookmark = NULL; /* Bookmark filename. - FM */ newAnchor->isISMAPScript = FALSE; /* Lynx appends ?0,0 if TRUE. - FM */ *************** *** 194,199 **** --- 196,203 ---- } child = HTChildAnchor_new(); + if (child == NULL) + outofmem(__FILE__, "HTChildAnchor_new"); CTRACE(tfp, "new Anchor %p named `%s' is child of %p\n", (void *)child, tag ? tag : (CONST char *)"", *************** *** 245,250 **** --- 249,277 ---- parsed_doc.safe = FALSE; dest = HTAnchor_findAddress(&parsed_doc); + #define DUPLICATE_ANCHOR_NAME_WORKAROUND + + #ifdef DUPLICATE_ANCHOR_NAME_WORKAROUND + if (tag && *tag) { + HTAnchor *testdest1; + int nlinks; + testdest1 = child->mainLink.dest; + if (testdest1) { + nlinks = 1 + HTList_count(child->links); + CTRACE(tfp, + "*** Duplicate ChildAnchor %p named `%s' with %d links", + child, tag, nlinks); + if (dest == testdest1 && ltype == child->mainLink.type) { + CTRACE(tfp,", same dest %p and type, keeping it\n", + testdest1); + } else { + CTRACE(tfp,", different dest %p, creating unnamed child\n", + testdest1); + child = HTAnchor_findChild(parent, 0); + } + } + } + #endif HTAnchor_link((HTAnchor *)child, dest, ltype); FREE(parsed_doc.address); FREE(relative_to); *** lynx2-8-1.orig/WWW/Library/Implementation/HTFile.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/WWW/Library/Implementation/HTFile.c Sat Nov 14 19:35:12 1998 *************** *** 105,110 **** --- 105,112 ---- #define MAYBE_END(e) if (HTML_dtd.tags[e].contents != SGML_EMPTY) \ (*target->isa->end_element)(target, e, 0) #define FREE_TARGET (*target->isa->_free)(target) + #define ABORT_TARGET (*targetClass._abort)(target, NULL); + struct _HTStructured { CONST HTStructuredClass * isa; /* ... */ *************** *** 1985,1990 **** --- 1987,1993 ---- { HTBTree * bt = HTBTree_new((HTComparer)strcmp); + status = HT_LOADED; /* assume we don't get interrupted */ while ((dirbuf = readdir(dp)) != NULL) { /* ** While there are directory entries to be read... *************** *** 2075,2080 **** --- 2078,2088 ---- while (next_element != NULL) { char *entry, *file_extra; + if (HTCheckForInterrupt()) { + _HTProgress ("Data transfer interrupted."); + status = HT_PARTIAL_CONTENT; + break; + } StrAllocCopy(tmpfilename,localname); if (strcmp(localname, "/")) /* *************** *** 2170,2183 **** /* pick up the next element of the list; if none, return NULL*/ } ! if (state == 'I') { ! START(HTML_P); ! PUTS("Empty Directory"); ! } #ifndef LONG_LIST ! else ! END(HTML_DIR); #endif /* !LONG_LIST */ } /* end while directory entries left to read */ closedir(dp); --- 2178,2193 ---- /* pick up the next element of the list; if none, return NULL*/ } ! if (status == HT_LOADED) { ! if (state == 'I') { ! START(HTML_P); ! PUTS("Empty Directory"); ! } #ifndef LONG_LIST ! else ! END(HTML_DIR); #endif /* !LONG_LIST */ + } } /* end while directory entries left to read */ closedir(dp); *************** *** 2186,2197 **** FREE(tail); HTBTreeAndObject_free(bt); ! if (HTDirReadme == HT_DIR_README_BOTTOM) ! do_readme(target, localname); ! FREE_TARGET; FREE(localname); FREE(nodename); ! return HT_LOADED; /* document loaded */ } } /* end if localname is directory */ --- 2196,2211 ---- FREE(tail); HTBTreeAndObject_free(bt); ! if (status == HT_LOADED) { ! if (HTDirReadme == HT_DIR_README_BOTTOM) ! do_readme(target, localname); ! FREE_TARGET; ! } else { ! ABORT_TARGET; ! } FREE(localname); FREE(nodename); ! return status; /* document loaded, maybe partial */ } } /* end if localname is directory */ From owner-lynx-dev@sig.net Sat Nov 14 22:39:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA19848 for ; Sat, 14 Nov 1998 22:39:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA15887; Sat, 14 Nov 1998 21:23:49 -0600 (CST) From: dickey@clark.net Message-Id: <199811150325.WAA06532@shell.clark.net> Subject: Re: lynx-dev 2.8.1rel.2 patches (long) To: lynx-dev@sig.net Date: Sat, 14 Nov 1998 22:25:59 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 14, 98 08:42:55 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: 648 Lines: 22 > There are patches for these and some other problems below. (I am sure > there are more leaks.) thanks. I'm about 1/4 through putting together a patch for dev.3 (this is larger than any of the chunks that I have in my queue). > In LYCharUtils.c there is a comment: > > /* > * FIXME: something's wrong with the limit checks here (clearing the > * buffer helps). > */ > memset(replace_buf, 0, sizeof(replace_buf)); > > Is there any known test case to reproduce the problem? Laura Eaves had one - I don't know if it's still available. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 14 23:20:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA25743 for ; Sat, 14 Nov 1998 23:20:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA20351; Sat, 14 Nov 1998 21:58:02 -0600 (CST) Date: Sat, 14 Nov 1998 23:00:05 -0500 (EST) Message-Id: <199811150400.XAA00804@access5.digex.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.flora.org/lynx-dev/html/month1198/msg00341.html X-Mailer: Lynx, Version 2.8.1dev.7 From: asgilman@access.digex.net (Al Gilman) Subject: lynx-dev BASE not absolute URL alert Cc: asgilman@access.digex.net (Al Gilman) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 729 Lines: 22 > * Subject: lynx-dev Question about BASE HREF alert > * From: [6]lvirden@cas.org (Larry W. Virden) > * Date: Sat, 14 Nov 1998 18:27:38 -0500 (EST) > _________________________________________________________________ > >I am seeing the following when I do a trace using lynx 2.8.1dev.2: > >SGML: Start >HTParse: aName:file:/home/lwv26/public_html/ relatedName: >HTParse: result: >HTML: BASE 'file:/home/lwv26/public_html/' is not an absolute URL. > >Alert!: HREF in BASE tag is not an absolute URL. > >Can someone tell me what this msg means? Try and see if the alert doesn't go away. I think the alert is triggered by this error in the URL syntax. Al From owner-lynx-dev@sig.net Sat Nov 14 23:49:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA29512 for ; Sat, 14 Nov 1998 23:49:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA25771; Sat, 14 Nov 1998 22:34:53 -0600 (CST) From: Philip Webb Message-Id: <199811150435.XAA18222@chass.utoronto.ca> Subject: lynx-dev welcome back! To: lynx-dev@sig.net Date: Sat, 14 Nov 1998 23:35:39 -0500 (EST) In-Reply-To: from "Klaus Weide" at Nov 14, 98 08:42: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: 450 Lines: 8 we've been getting along well enough without you, but your absence has been commented on more than once with regrets; i'm sure everyone hopes that whatever caused it is now resolved. -- ========================,,============================================ 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 Nov 15 00:52:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA04292 for ; Sun, 15 Nov 1998 00:52:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA02654; Sat, 14 Nov 1998 23:36:21 -0600 (CST) Date: Sun, 15 Nov 1998 00:04:19 -0500 (EST) From: John Bley To: lynx-dev@sig.net Subject: lynx-dev segfault (signal 11) in lynx 2.8.1-rel2 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: 24946 Lines: 702 Gentlemen: I get a segfault when loading http://www.tvgen.com/tv/listings_left.htm lynx 2.7.0 does not seem to exhibit this behaviour. lynx 2.8.1-rel2 does. The saved HTML source, lynx -trace output, and the interesting bit of gdb debugging info follows. My lynx 2.8.1-rel2+SSL also exhibits this behaviour along with the pure 2.8.1-rel2. I hope this is enough information. If I can be of further assistance please let me know. uname -a reports: SunOS soc15.acpub.duke.edu 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-30 Compiled lynx using gcc (one regular build, one with --enable-debug in the configure - both do the segfault) Both compiles were clean. -- John Bley - jbb6@acpub.duke.edu Duke '99 - English/Computer Science Ubi dubium ibi libertas. Television

    • (gdb) where #0 0xef64e40c in strrchr () #1 0x6dde0 in MakeNewTitle (value=0x15c6c8, src_type=48) at ./HTML.c:7469 #2 0x647e8 in HTML_start_element (me=0x159498, element_number=59, present=0x15c6a4 "", value=0x15c6c8, tag_charset=0, include=0x15c7a0) at ./HTML.c:2775 #3 0x98ab8 in start_element (context=0x15c678) at ../../../WWW/Library/Implementation/SGML.c:921 #4 0x9b19c in SGML_character (context=0x15c678, c_in=62 '>') at ../../../WWW/Library/Implementation/SGML.c:2513 #5 0x9c110 in SGML_write (context=0x15c678, str=0x12aae9 ">\n\n\n\n to continue, or q to quit--- #9 0x89cdc in HTLoad (addr=0x0, anchor=0x158d88, format_out=0x14d358, sink=0x0) at ../../../WWW/Library/Implementation/HTAccess.c:606 #10 0x8a0c8 in HTLoadDocument ( full_address=0x158b68 "file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm ", anchor=0x158d88, format_out=0x14d358, sink=0x0) at ../../../WWW/Library/Implementation/HTAccess.c:844 #11 0x8a5f8 in HTLoadAbsolute (docaddr=0x158b68) at ../../../WWW/Library/Implementation/HTAccess.c:1000 #12 0x36030 in getfile (doc=0x125594) at ./LYGetFile.c:649 #13 0x3a778 in mainloop () at ./LYMainLoop.c:565 #14 0x38b84 in main (argc=2, argv=0xeffffae4) at ./LYMain.c:1686 Lynx Trace Log LYNX_SIG_FILE set to '/afs/acpub/users/j/b/jbb6/.lynxsig' Loading cfg file '/usr/local/lib/lynx.cfg'. HTMLDTD: Copying DTD element info of size 5192, 118 * 44 ProcessMailcapFile: Loading file '/usr/local/lib/mosaic/mailcap'. ProcessMailcapFile: Could not open '/usr/local/lib/mosaic/mailcap'. ProcessMailcapFile: Loading file '/afs/acpub/users/j/b/jbb6/.mailcap'. ProcessMailcapFile: Could not open '/afs/acpub/users/j/b/jbb6/.mailcap'. HTFormat: Looking up presentation for text/plain to www/present FindPresentation: found exact match: text/plain HTFormat: Looking up presentation for text/html to www/present FindPresentation: found exact match: text/html HTFileInit: Loading default (HTInit) extension maps. HTLoadExtensionsConfigFile: Loading file '/usr/local/lib/mosaic/mime.types'. HTLoadExtensionsConfigFile: Could not open '/usr/local/lib/mosaic/mime.types'. HTLoadExtensionsConfigFile: Loading file '/afs/acpub/users/j/b/jbb6/.mime.types'. HTLoadExtensionsConfigFile: Could not open '/afs/acpub/users/j/b/jbb6/.mime.types'. HTParse: aName:http://www.duke.edu/duke.html relatedName: 1 HTParse: result:http://www.duke.edu/duke.html STARTFILE 'listings_left.htm' is not a URL Converted 'listings_left.htm' to '/tmp/jbb6/lynx2-8-1/listings_left.htm' Converted 'listings_left.htm' to 'file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm' HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: 1 HTParse: result:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm LYMain.c: User in REMOTE domain Entering mainloop, startfile=file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm getfile: getting file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:localhost HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:localhost HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:file HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: 1 HTParse: result:/tmp/jbb6/lynx2-8-1/listings_left.htm HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 15ae18 has hash 54 and address `file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm' HTAccess: loading document file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName:file: HTParse: result:file HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:localhost HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:file HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: 1 HTParse: result:/tmp/jbb6/lynx2-8-1/listings_left.htm HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:localhost HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:file HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:file HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: HTParse: result:localhost HTParse: aName:file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm relatedName: 1 HTParse: result:/tmp/jbb6/lynx2-8-1/listings_left.htm Node `file://localhost/tmp/jbb6/lynx2-8-1/listings_left.htm' means path `/tmp/jbb6/lynx2-8-1/listings_left.htm' HTLoadFile: Opening `/tmp/jbb6/lynx2-8-1/listings_left.htm' gives 136d78 File mode is 0100666, uid=25565, gid=109. My uid=25565, 3 groups ( 33536 32572 109) 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 SGML Doctype SGML: Start GridText: start HText_new GridText: Change to style Normal HTML:begin_element[0]: adding style to stack - Normal SGML: Start HTML:begin_element[1]: adding style to stack - Normal SGML: Start HTML:begin_element[2]: adding style to stack - Normal SGML: End HTML:end_element[2]: Popped style off stack - Normal SGML: Start LYHandleMETA: HTTP-EQUIV="NULL" NAME="description" CONTENT="NULL" SGML: Start LYHandleMETA: HTTP-EQUIV="NULL" NAME="Keywords" CONTENT="NULL" SGML: Start HTML:end_element[2]: Popped style off stack - Normal HTML: SCRIPT content = SGML: Start HTML:end_element[2]: Popped style off stack - Normal HTML: SCRIPT content = | | ----> | | ----> | | ----> | | | | | | | | | | | | ------- ------- ------- ------- ------- user cache cache cache origin Each of the intermediate boxes Ln represents a level of caching. U is the "user" of cached data (not necesarily human, but a part of an application. The arrows show the flow of request; the response data of course goes the other way. Well so far I this isn't very original. It is meant to be general, "cache" can stand for all kinds of things. Let's see how this can apply to a HTTP request from Lynx. U: mainloop() L1: cache of rendered documents - WHAT WE HAVE L2: ??? cache for raw bytes - WHAT WE DONT HAVE L3: a proxy cache in the network O: HTTP origin server (Btw. in some respect the internal links stuff can be viewed as an additional first cache L0, consisting of only the viewed document, but let's ignore that now.) As you can see, I suggest a place where a new cache level for raw data should belong - if we want to do it right. Note that I leave it open whether that new level stores data in memory, in files, or maybe even both. Do you agree so far? Each "cache" box stands for - cached data - metadata: for example How old, Time Received, validity flags, ... - logic and code to - handle requests (incoming arrow from left) - see whether we have the data - determine whether data can be used for reply - make request (become a user of the next level, arrow to the right) - respond (possibly negative, erro message) - store new data if appropriate - keep metadata updated For the left part of the diagram, communication between the levels is function calls and return values and (for passing the data back) HTStream stages. To the right of L2, it's HTTP messages. The simple diagram implies that a cache level automatically "writes through" the request to the following level if it cannot satisfy the request. I.e. between two styles of communication: A. -- caller: Gimme data if you have, or an error. -- cache: Ok, here it is... or: -- cache: Nope, try something else without me. B: -- caller: Gimme data, whether you already have it or not. -- cache: Ok, here it is... (I had it cached) or: -- cache: Ok, let's see... yep, I got it for you. the second is preferred. With B, levels can more easily be chained. (We get a linear diagram.) With A, we'd probably have something like this: U Ln ------- Req. ------- Req. | | ----> | | ----> | | <---- | | <---- ------- data ------- data \ ^ / Req. \ \ data / v \ / data ------- / | | <---------- | | ------- Ln' This looks more complicated... One part of the program (the top left box) now has to do a lot more: talk to two caches instead of one (probably in a different language), determine which to use, resolve conflicts, know a lot about the caches' metadata. Now image that this has to be implemented in (or somehow controlled by) mainloop() and getfile(), which are already horribly complicated... (I know, my fault too.) I am afraid that the new caching level will look more like the second diagram if we are not careful. Initially that may look like a win: The new routines after all have to do less (don't have to pass on requests). But even if this new stuff is only meant for special cases (reloading current document for '*', '[', ^V etc.), the caller has to keep track of it; and it will get more complicated if someone later wants to do a more complete cacheing system. The second diagram suggests some splitting of the data stream; this could mean that the same bytes, while being read from the next level (the network), are simultaneously written to a disk file (or memory buffer) and towards the HText rendering/caching. I don't mean that this is bad -- it is most certainly better than first-write-to-file,-then-load-file-data -- but it should ideally be handled within one box. I.e. one set of functions (perhaps including a new HTStream stage) which interoperate and share (meta-) data, but the rest of the program doesn't need to know much about their internals. So let's look more at the linear model. For it to work, the caller has to be able to tell the next cache level what it wants, and for that we need to have a language... If that language is expressive enough (and precise enough), the caller does not need to bypass the normal line of request/resons communication to get direct access to the cache's data. To explain more concretely what i mean, let's look at mainloop(). It normally passes a request to getfile() which passes it on by calling lower levels. The lower levels decide what to do based on the URL and other parameters (and global variables, which ideally should be parameters). Somewhere in HTAccess.c it is decided whether to satisfy the request from the rendered- document-cache. mainloop() just gets a result after all is done; it doesn't (and usually cannot) know whether the document loaded now came from the cache or from the network (or a proxy server etc.). This nice separation is sometimes violated: when mainloop() wants to know whether a POST result is still in the cache, in order to prompt the user if appropriate. If the language in which mainloop() talks to getfile() etc. could express "Give me this document, but if it is not cached ask for confirmation first", then mainloop() wouldn't have to do so much work. Currently the caching-related request vocabulary already consists of a bunch of flags: `reloading', `LYforce_no_cache', `LYoverride_no_cache', `LYinternal_flag', ..., text->no_cache, anchor->no_cache, in conjunction with various other bits and pieces. This is very confusing. These are all needed so HTLoadDocument() (& friends) can make a decision what to do. Now imagine what happens if we add another cache level. Or just modify or enhance the current cache's behavior. Again, putting more of the decision making in mainloop() may seem an easy way out; I think instead there is an urgent need to rationalise the language, before much gets added cachewise. There are two places where we may look for guidance: * The HTTP protocol itself. * Newer versions of libwww. Since HTTP is engineered to support cacheing, and is quite detailed about it, it may tell us a lot about what kinds of requests a level of a cache hierarchy can make - what kinds of parameters are needed, what modes of operation one could think of etc. With necessary modifications of course, for the program-internal rather than over-the-network case. Note that HTTP caching is completely based on the style B communication (above). (Squid caches talking ICP with each other are something else.) In libwww 5.2, I find in : ------------ snip ------------ HTTP Cache Validation and Cache Control The Library has two concepts of caching: in memory and on file. When loading a document, this flag can be set in order to define who can give a response to the request. The mempory buffer is considered to be equivalent to a history buffer. That is, it doesn't not follow the same expiration mechanism that is characteristic for a persistent file cache. You can also set the cache to run in disconnected mode - see the [23]Cache manager for more details on how to do this. typedef enum _HTReload { HT_CACHE_OK = 0x0, /* Use any version available */ HT_CACHE_FLUSH_MEM = 0x1, /* Reload from file cache or network */ HT_CACHE_VALIDATE = 0x2, /* Validate cache entry */ HT_CACHE_END_VALIDATE = 0x4, /* End to end validation */ HT_CACHE_RANGE_VALIDATE = 0x8, HT_CACHE_FLUSH = 0x10, /* Force full reload */ HT_CACHE_ERROR = 0x20 /* An error occurred in the cache */ } HTReload; extern void HTRequest_setReloadMode (HTRequest *request, HTReload mode); extern HTReload HTRequest_reloadMode (HTRequest *request); ------------ snip ------------ He, that looks just like what we need! Instead of setting many variables mainloop() and other higher-level functions could just set one request variable to the right value, using max() if appropriate, to bump up the, hmm, nocache-nature of a request. Rough correspondence to current flags (omitting the two that may not really belong here): HT_CACHE_OK default or LYoverride_no_cache HT_CACHE_FLUSH_MEM LYforce_no_cache, text->nocache HT_CACHE_VALIDATE HT_CACHE_END_VALIDATE HT_CACHE_FLUSH `reloading' Well, the correspondence isn't a direct one. But I think something like this should replace the current flags as far as possible. With added values if we need more. What do you think? ----- Some comments on your concrete suggestions: > Currently I think cache should be checked in HTLoadDocument() or HTLoad(), maybe add another function call level? > than in HTLoadHTTP() we try If-Modified_Since and update cached header > from (any) responce, and the last step - No, only for 200 responses (and maybe similar ones). Think about what happens if we get 4xx or 5xx responses intermixed with 2xx responses for the same URL (maybe unreliable server...) Where do you plan to keep all the metainformation? (Last-modified, Etag, ...) In the node_anchor as now? maybe that is not so good. > update cached data in LYAddVisitedLink() when everything done OK. Much too late (too high level) for my taste... Anyway, I am not sure what you mean with "update cached data". I have to read your proposal more carefully. > Anyway, > we should kludge into HTStream properly... > and the Anchor structure should be coupled with cached source > when doing HTuncache_current_document() for rendered image. ----- Well all I wrote above was so much theory. In practical implementation, maybe we end up with something completely different. But before you go ahead, could you try to explain how your ideas fit into my understanding? Also, may I suggest you have a look at and see whether you can reuse anything from there. ----- > By introducing a simple invariant > "current_char_set and UCLYhndl_for_unspec always valid" > I wipe lots of if (hndl>= 0) and made the code more understandable :-) Well, good to know that that is now meant to be always true. :) Klaus From owner-lynx-dev@sig.net Tue Nov 17 15:37:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA28569 for ; Tue, 17 Nov 1998 15:37:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA10664; Tue, 17 Nov 1998 14:14:31 -0600 (CST) Date: Tue, 17 Nov 1998 14:16:43 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx News 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: 712 Lines: 20 On Mon, 16 Nov 1998, Ismael Cordeiro wrote: > On Mon, 16 Nov 1998, Guentcho D. Skordev wrote: > > > Lynx (Lynx/2.7.1 libwww-FM/2.14 on HP-UX) has a problem resolving the > > following link: > > > > news://news.binco.com/R6#DxXPE#GA.274@sitekeeper.sitekeeper.com > > That URL is correctly interpreted by lynx2.7.2 and lynx2.8.2dev.2 but not > by lynx2.7.1. I suggest you to upgrade your version of lynx. Or rather: That URL is interpreted incorrectly, just as you (and apparently the rest of the word) expect. '#' in an URL string always means start of a fragment. So looking for NAME="DxXPE#GA.274@sitekeeper.sitekeeper.com" in news://news.binco.com/R6 would be the right thing to do... Klaus From owner-lynx-dev@sig.net Tue Nov 17 15:54:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA30075 for ; Tue, 17 Nov 1998 15:54:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA15665; Tue, 17 Nov 1998 14:30:26 -0600 (CST) From: george_morrison@pleasantco.com Message-ID: <596E6ADAB278D111BCD500A0C9968148DCDF5F@MDL_IRON> To: lynx-dev@sig.net Subject: lynx-dev Function Key Mapping in Lynx 2.7.1 Date: Tue, 17 Nov 1998 14:34:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 635 Lines: 20 I'm having trouble using lynx.cfg to map the function key assignments in Lynx. The Lynx session is being invoked from HP terminals (running vt100 emulation) running under SunOS 5.6. The keycodes that Lynx looks for are not obvious (they do not run in sequence). So far, I've only managed to figure out the following keys: F3 = 0x101 F7 = 0x106 F8 = 0x102 Also, F2 seems to map to 0x107, but generates odd behavior when it is remapped. Any advice on how to identify the codes being passed to Lynx, or a comprehensive list of the keycodes Lynx looks for would be appreciated! Regards, George Morrison george_morrison@pleasantco.com From owner-lynx-dev@sig.net Tue Nov 17 16:50:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA01811 for ; Tue, 17 Nov 1998 16:50:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA29145; Tue, 17 Nov 1998 15:13:51 -0600 (CST) Date: Tue, 17 Nov 1998 15:16:03 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev internal cache proposal 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: 4726 Lines: 134 Lots of questions here: On Mon, 16 Nov 1998, Leonid Pauzner wrote: > Lynx internal cache implementation proposal. > > - the source of every document now cached for greatly speed operations > which require a re-parse, including '\' view-source, > '^V' other-DTD, '*' image-URLs, '[' pseudo-alts, > '"' soft-dquotes, '`' and "'" comment-parsing, > '@' raw-mode, and changes in assumed document character set. > This also work for downloading document from the History page > and would probably usefull for future table implementation (if happend). What do you mean with "internal" cache? (Everything implemented in lynx is internal to Lynx :) ) So we already have one internal cache.... You don't really say anywhere whether you want to cache on dosk ore in memory. (I assume in memory.) > - simple HTTP 1.1 cache implemented, e.g. if you request http:// document > for purposes other than listed above, the document's source > already in lynx internal cache and the requested method is GET - > a "conditional GET" request follows (one include additional headers > If-Modified_Since and/or If-None-Match against cached value Last-Modified > and ETag). If the remote server (or proxy) detect no change and returns > with 304 (Not Modified) status - our internally cached entry used. How does this interact with the current cache? Is it always flushed when your cache kicks in? Anyway, is this second paragraph necessary for implementing what's in the first? Or is it just an added bonus? > Proccessing the other statuses have not been changed. Does it invalidate the cache? Does the cached copy get deleted? > The header of cached entry updated with every responce. Hmmmm. Where do you keep the headers? > We also change lynx request header from "HTTP/1.0" to "HTTP/1.1" > to allow server send us ETag for best caching validation Bad idea, as explained in another message. > (does we lost something that SHOULD be implemented in HTTP 1.1 client?). Yes. > The expiration status calculated by LYinternal_cache_stale() function. Suggestion: see is_fresh() (or similar name) in HTCache.c of newer libwww. Suggestion: Keep dates as time_t values, not strings. (or: in addition. keep sting value for display in '=' screen.) > The documents we sure as not expired will be loaded from internal cache > immediately (no DNS search, no HTTP request). What happens with ^R? 'x'? > No methods other than GET http:// cached (except for internal use like ^V). Do we HAVE TO discriminate against FTP? Anything to do about HEAD? > It should be stressed separately that according to HTTP 1.1 and 1.0, > the expired or "no-cache" document may also be cached but > the conditional GET request SHOULD be proccessed for validation > by the remote server, not an intermediate proxy nor ourself > (so "no-cache" directive act on validation, but data may be valid). What section are you referring to? Why is this significant here? > - Implementation details: cache updated in LYAddVisitedLink(), > e.g. when the document already received successfully, > there should not be any problem from redirections. What does "cache updating" mean? I mean, you already have the data, so you already have updated the cache, right? Or do you temporarily want to have two full copies? > Klaus's internal (#fragment) links now obsolete and will be removed soon. What has it to do with your cache? It is not obsolete IMHO. > - Possible problems/future domain: > LYinternal_cache_stale() currently assume any document expired for sure, > will be fixed soon. Does that function already exist? > Method POST may be not cached for internal use > like changing ^V etc. Why not? > SSL? Redirections? > Cache recycling mechanism? Too brief to understand what you mean. > Persistent cache can be implemented easily when everything else done. Maybe. > - Questions: > * If we interrupt transfer with 'Z' - the result will be cached > for "internal use" but assumed as already expired for normal operations(?). Define "for internal use" please. If you mean ^V, '*', '[', .., maybe we can find a better term. Anyway, in that case your idea probalby makes sense. But a safer way would be to discard incomplete stuff. > Probably it should not be forced as expired but not persistent for sure. > * Should any responces besides 200 (OK) status be cached? > * #fragments? Shouldn't have anything to do with it. > * compressed files? Why not? :) Klaus From owner-lynx-dev@sig.net Tue Nov 17 17:18:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA03759 for ; Tue, 17 Nov 1998 17:18:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA11587; Tue, 17 Nov 1998 15:54:43 -0600 (CST) From: dickey@clark.net Message-Id: <199811172156.QAA14667@shell.clark.net> Subject: Re: lynx-dev gettext() question To: lynx-dev@sig.net Date: Tue, 17 Nov 1998 16:56:52 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 17, 98 04:13:37 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: 657 Lines: 15 > look src/LYMainLoop.c:5422 - > problem usually arise then message have several `%s' templates, > probably change those sprintf with HTSprintf or what so evere... I'll do that - my aim in the last patch was to have a workable HTSprintf that I could test (both logic and porting) before I spent a lot of time changing the existing sprintf's (likewise, the other patches on my queue should be dealt with before they get pushed farther away). Plus - it would be simpler now to replace some of those rather unreadable chains of StrAllocCopy/StrAllocCat with HTSprintf or HTSprintf0. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 17 18:02:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA07450 for ; Tue, 17 Nov 1998 18:02:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA24579; Tue, 17 Nov 1998 16:34:52 -0600 (CST) Message-ID: <19981117143702.A2431@psnw.com> Date: Tue, 17 Nov 1998 14:37:02 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.3 Mail-Followup-To: lynx-dev@sig.net References: <19981116235542.A17448@psnw.com> <199811171013.FAA09394@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811171013.FAA09394@shell.clark.net>; from "dickey@clark.net" on Tue, Nov 17, 1998 at 05:13:31AM X-Operating-System: Linux odin 2.0.34 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 2:33pm up 1 day, 23:36, 4 users, load average: 1.08, 1.02, 1.01 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1276 Lines: 41 dickey@clark.net wrote: > > Just wanted to verify that one of my other patches regarding this is still > > set aside. With only the part that you applied, there'll be a few other > > problems with null cookies. > I see this (going back to 1 September), grepping for 'pardy': > Date: Fri, 6 Nov 1998 18:37:49 -0800 > From: "brian j. pardy" > To: lynx-dev@sig.net > Subject: Re: lynx-dev idea regarding 'Submit' links > but that doesn't seem applicable. Perhaps I missed it Ah, no, not that one. > > Can resend if you'd like. > ok. Here it is: diff -cr lynx2-8-1/src/LYCookie.c lynx2.8.2.dev.1.bri/src/LYCookie.c *** lynx2-8-1/src/LYCookie.c Fri Nov 6 06:29:41 1998 --- lynx2.8.2.dev.1.bri/src/LYCookie.c Sun Nov 8 18:59:48 1998 *************** *** 495,500 **** --- 495,508 ---- co = NULL; /* + * Don't add the cookie if the value is NULL. - BJP + */ + } else if (co->value[0] == '\0') { + CTRACE(tfp, "store_cookie: Value is NULL! Not storing cookie.\n"); + freeCookie(co); + co = NULL; + + /* * If it's a replacement for a cookie that had not expired, * and never allow has not been set, add it again without * confirmation. - FM -- Reactor error - core dumped! From owner-lynx-dev@sig.net Tue Nov 17 19:21:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA13089 for ; Tue, 17 Nov 1998 19:21:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA07557; Tue, 17 Nov 1998 17:20:23 -0600 (CST) Date: Tue, 17 Nov 1998 18:22:29 -0500 From: Jean-Pierre Radley To: lynx-dev@sig.net Subject: lynx-dev core dumps Message-ID: <19981117182229.O986@jpradley.jpr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.16i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 372 Lines: 13 SCO OpenServer 5.0.5 lynx2.8.2dev.[123].tgz All three of the above releases compile just fine here, using the latest egcs snapshot of gcc. But all three of the resulting binaries core dump when trying to access any URL at all. What info can I provide to help figure out the problem? -- Jean-Pierre Radley XC/XT Custodian Sysop, CompuServe SCOForum From owner-lynx-dev@sig.net Tue Nov 17 19:26:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA13384 for ; Tue, 17 Nov 1998 19:26:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA09160; Tue, 17 Nov 1998 17:27:12 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811172232.PAA00473@sanitas> Subject: lynx-dev Safety Belt To: lynx-dev@sig.net (Lynx List) Date: Tue, 17 Nov 1998 15:32:55 -0700 (MST) 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: 1154 Lines: 32 Hello, Lyncei, A few weeks ago, I carelessly defined a null macro in config.hin. This percolated into lynx_cfg.h, thence into cfg_defs.h, where it had been transformed into a VOID member in a struct initializer. It took me several hours to track down the SIGSEGV every time I pressed "=". Today, I did it again, but it took me less than an hour to recall what had happened the last time. Lest I forget again: diff -brc ./orig/lynxsrc/src/LYShowInfo.c ./lynxsrc/src/LYShowInfo.c *** ./orig/lynxsrc/src/LYShowInfo.c Tue Nov 10 12:47:38 1998 --- ./lynxsrc/src/LYShowInfo.c Tue Nov 17 14:36:37 1998 *************** *** 26,32 **** #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 --- 26,33 ---- #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?table[N].value:"<VOID>") /* * Compile-time definitions info, returns local url From owner-lynx-dev@sig.net Tue Nov 17 19:32:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA13791 for ; Tue, 17 Nov 1998 19:32:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA13297; Tue, 17 Nov 1998 17:47:17 -0600 (CST) Date: Tue, 17 Nov 1998 15:49:29 -0800 (PST) From: David Combs Message-Id: <199811172349.PAA18229@netcom4.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 545 Lines: 12 > From owner-lynx-dev@sig.net Mon Nov 16 11:48:24 1998 > To: lynx-dev@sig.net > References: <199811161641.IAA08119@netcom17.netcom.com> > > > Half the time I am just backing up THROUGH something, not even reading > > (via my eyes) anything on the page, just backing up to the prior one. > > > I DON'T CARE whether that page is in-sync or not. If I worry > > about a given page, I can just do a ^C, and get a "fresher" copy. > ^^^^^^^^ > right mr. Combs! ^R of course. sorry. From owner-lynx-dev@sig.net Tue Nov 17 19:54:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA15986 for ; Tue, 17 Nov 1998 19:54:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA20831; Tue, 17 Nov 1998 18:23:31 -0600 (CST) Date: Wed, 18 Nov 1998 09:27:08 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811180027.JAA02543@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev on caching (long) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 869 Lines: 15 > so, may I suggest you have a look at > Because of my very slow connection to the Interent, having Lynx cache the source has been a nebulous dream I've held for Lynx since I joined this mailing list. It has been fought for, literally, a number of times. The "best" solution for me, I've found, is a cacheing server or proxy, whether that be in my own personal one or one setup system-wide. The fact is that there are very good servers out there which specialize in just cacheing. Supposedly they are fairly well debugged and have already thought out the problems. Couldn't one of these, or its library, be added to Lynx as an add-on module, sort of like libz, SSL, or, more recently, libintl? It just doesn't seem that it could be more tricky than, say, SSL, and unlike SSL, the "hooks" could be implanted permanently. __Henry From owner-lynx-dev@sig.net Tue Nov 17 20:42:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA19499 for ; Tue, 17 Nov 1998 20:42:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00885; Tue, 17 Nov 1998 19:15:54 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 03:50:34 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev on caching (long) 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: 3449 Lines: 72 > > What do you think? > Well, thank you Klaus for detailed (nice) responce. I will try to reply you later, not now, should think on it. Just a more practical thought. How does display partial logic appears in lynx? One boy from Check found out that repaint done by HText_pageDisplay() and the appropriate place to call it from HTFormat.c/HTCopy() while reading stream and LYUtils.c/HTCheckForInterrupt() to enable scrolling. He made an alpha patch and disconnected from lynx-dev. Of cause, we got a lot of bugs and and side effects. Now I jump into and fix them by introducing several flags: including two linecounters, durty workaround for "forms input" problems, and a synchronization semaphore (!), we got it in 5-10 sequential attempts... What I want to say: it wasn't supposed to do so by lynx original designers but the internal structure permits this (except few more recent bugs - we find a workarond for them). Now with cacheing. If we create a library from the beginning we do so and so. It may be a good idea to discuss its future language but the implementation is a thremendous long-time job, definitely not for me new at programming. We are at other position: we have a "working" code stable for years with its own "language". I think on kludging an internal cache without changing lynx logic. So I think on a high level: LYAddVisitedLink() called just before repainting the rendered document, it obviously transferred from network OK. So we can add it to cached sources list (there is a check for repeated documents in Visited Links already, need a minore change to exclude #fragments and file://localhost). >From the other side, HTLoad() calls get_physical() to access network layer with proxy and origin (L3 and O on your diagram). So we can add try_internal_cache() which will call for get_physical() if no valid cached source found. Also a kludge inside HTLoadHTTP for IF-Modified-Since request. Yes, this is not a linear transparent model. And definitely not the best for CPU/memory usage either (we could do several manipulation just inside mainloop() instead, but we will get many special cases in getfile(), here and there, probably will look not so clear unless we rewrite the code significantly). The main subject is validation of a cached source. There are two cases: 1) HTTP request. Calculate expiration status and load from cache if valid, otherwise (or we are too lazy) do as much as sending conditional GET request to L3 or O. (no more). 2) history. We need a document for '*', '['... probably few other cases like <- key or #fragment that point out to the document inside the history stack (more cases discussible). Here the documents assumed valid. Originally, my system running Squid and Lynx can access it nicely but since the case 2) differ from 1) - few documents with "no-cache" pragma appears reloading when I want history. That is a lynx fault. So I start thinking on it and found that 1) and 2) can be handled the same time. > > In principle, and IMO, caching should be like this: > > U L1 L2 L3 O > ------- ------- ------- ------- ------- > | | ----> | | ----> | | ----> | | ----> | | > | | | | | | | | | | > ------- ------- ------- ------- ------- > user cache cache cache origin > From owner-lynx-dev@sig.net Tue Nov 17 21:12:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA22651 for ; Tue, 17 Nov 1998 21:12:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA06257; Tue, 17 Nov 1998 19:45:56 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 04:43:04 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev internal cache proposal 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: 1887 Lines: 59 > Lots of questions here: most problems was from my language/style, things are explained again in a separate letter. Few points: a) "internal cache" should read "cache for sources" (we already had cache for rendered documents). b) I have not even start coding yet nor choose a struct's for keeping the headers (anchor?) and data. >> Proccessing the other statuses have not been changed. > Does it invalidate the cache? Does the cached copy get deleted? probably yes for certain responce statuses. > Suggestion: see is_fresh() (or similar name) in HTCache.c of newer libwww. thanks! >> The documents we sure as not expired will be loaded from internal cache >> immediately (no DNS search, no HTTP request). > What happens with ^R? 'x'? this is equivalent to "expired", sending conditional GET with "no-cache" is enough (was explained below). >> No methods other than GET http:// cached (except for internal use like ^V). > Do we HAVE TO discriminate against FTP? No. Just "not implemented" - I haven't look FTP specifications yet, it probably have no HEAD, right? > Anything to do about HEAD? Why? this is always the same as returned from GET. >> - Implementation details: cache updated in LYAddVisitedLink(), >> e.g. when the document already received successfully, >> there should not be any problem from redirections. > What does "cache updating" mean? made a pointer; delete an old cached source if the server returns a newer copy. >> Method POST may be not cached for internal use >> like changing ^V etc. > Why not? it takes a time to understand what current code do with it. >> * #fragments? > Shouldn't have anything to do with it. Visited links have different entries for them, but they have a single html source. >> * compressed files? > Why not? :) cache uncompressed data or the original? From owner-lynx-dev@sig.net Tue Nov 17 21:29:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA23934 for ; Tue, 17 Nov 1998 21:29:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA07578; Tue, 17 Nov 1998 19:53:37 -0600 (CST) Message-ID: <19981117175538.A800@psnw.com> Date: Tue, 17 Nov 1998 17:55:38 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: lynx-dev 2.8.2dev.3 - exiting via interrupt (cosmetic) Mail-Followup-To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 5:50pm up 1:23, 5 users, load average: 1.24, 1.23, 1.13 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 936 Lines: 44 In 2.8.2dev.3, if Lynx exits due to an interrupt, the following will be printed on screen: [begin] Exiting via interrupt: %d 2 [fin] I assume this isn't desired. Might want to get rid of extra the leading newlines in the gettext() string as well... Might be a few more of these sitting around, too. diff -cr lynx2.8.2dev.3/src/LYClean.c lynx2.8.2dev.3.bri/src/LYClean.c *** lynx2.8.2dev.3/src/LYClean.c Tue Nov 10 11:47:38 1998 --- lynx2.8.2dev.3.bri/src/LYClean.c Tue Nov 17 17:48:16 1998 *************** *** 106,112 **** } if (sig != 0) { printf("\n\n%s %d\n\n", ! gettext("\n\nExiting via interrupt: %d\n\n"), sig); fflush(stdout); } --- 106,112 ---- } if (sig != 0) { printf("\n\n%s %d\n\n", ! gettext("\n\nExiting via interrupt: "), sig); fflush(stdout); } -- I think that God in creating man somewhat overestimated his ability. -- Oscar Wilde From owner-lynx-dev@sig.net Tue Nov 17 21:35:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA24530 for ; Tue, 17 Nov 1998 21:35:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10093; Tue, 17 Nov 1998 20:08:11 -0600 (CST) Message-ID: <19981117181021.A886@psnw.com> Date: Tue, 17 Nov 1998 18:10:21 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: lynx-dev thoughts on cookie file w/multiple sessions Mail-Followup-To: lynx-dev@sig.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 5:58pm up 1:31, 5 users, load average: 1.25, 1.22, 1.15 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1497 Lines: 34 Some method to handle a single cookie file being used by multiple Lynx sessions needs to be worked out. This is an idea I recently came up with, but it seems too simple to me and I need someone to poke holes in it. As things are presently: Two sessions, A and B are running. Both load the same set of cookies from COOKIE_FILE. Session A gets a new cookie from some site, then exits, writing all the original cookies and the new cookie to COOKIE_FILE. Session B quits, overwriting COOKIE_FILE with all the original cookies, but blowing away the new cookie that session A received. So here's my thought -- prior to writing cookies in memory to COOKIE_FILE, Lynx should *reread* COOKIE_FILE, ignoring any cookies that are already in memory, but adding cookies from the file that are not in memory. The only thing coming to mind so far that could be a problem here would be getting two cookies with the same 'name' attribute from a server in two different sessions (two unique identifiers from advertising sites?), in which case the one which is written to COOKIE_FILE first (thus read into memory in the other Lynx session, overwriting the existing one) will be maintained, and the others dropped. Netscape, FWIW, gives an error saying basically "I'm already running, bookmarks won't work properly" to get around the issue of multiple instances, I assume this means cookies won't work either. -- I just asked myself... what would John DeLorean do? -- Raoul Duke From owner-lynx-dev@sig.net Tue Nov 17 21:49:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA25380 for ; Tue, 17 Nov 1998 21:49:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA12677; Tue, 17 Nov 1998 20:21:36 -0600 (CST) From: dickey@clark.net Message-Id: <199811180223.VAA16714@shell.clark.net> Subject: Re: lynx-dev core dumps To: lynx-dev@sig.net Date: Tue, 17 Nov 1998 21:23:50 -0500 (EST) In-Reply-To: <19981117182229.O986@jpradley.jpr.com> from "Jean-Pierre Radley " at Nov 17, 98 06:22:29 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: 571 Lines: 24 > > SCO OpenServer 5.0.5 > > lynx2.8.2dev.[123].tgz > > All three of the above releases compile just fine here, using the latest > egcs snapshot of gcc. > > But all three of the resulting binaries core dump when trying to access > any URL at all. > > What info can I provide to help figure out the problem? for starters: a traceback - and the config.status so I can see what you built. > -- > Jean-Pierre Radley XC/XT Custodian Sysop, CompuServe SCOForum > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 17 22:44:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA30289 for ; Tue, 17 Nov 1998 22:44:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA22728; Tue, 17 Nov 1998 21:16:50 -0600 (CST) Date: Wed, 18 Nov 1998 12:20:10 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811180320.MAA03584@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev strange interaction with gettext/anonymous/gz Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3128 Lines: 62 > > Just hitting the `=' key to get the info page will lock up the > > keyboard except for ctrl codes when the environment variable is > > set to LANG=japanese AND the user is in a captive account. The [...] > I just visited your machine and saw the same thing... (also the lockups). Apologies, everyone. It was a very stupid oversight on my part. I had the new user "jlynx" sharing its $HOME with "lynx", but it was not the owner. The problem has nothing to do any of the conditions mentioned in the subject. The problem does NOT occur with LANG=ja and anonymous, now that the permissions on the $HOME directory are correct. VERY sorry. I was hoping to get an automatic switching of the languages at login. Now the wrapper prompts for which of the two supported languages is desired. Anyway, those who want to get a feel for NLS are free to test it out. (Please avoid Wed and Fri afternoons, JST, however.) > Unfortunately I don't know anything about gettext. There wasn't really enough discussion on the pros and cons of going to gettext. In order to do it right, i.e., translaters will be able to *simply* run xgettext to get a correct template to do the translations on, will make it a must that at least some of the Lynx developers have a fairly good knowledge of the gettext mechanism. I fear the burden on the programmers is going to be a pretty heavy, at least in the initial stages. For the non-programmer to be able to maintain the translation part, without unwittingly introducing bugs of the type already mentioned by Claude, will require that the programmer know how to efficiently use keywords and comments, which xgettext, and subsequently, msgfmt know about. __Henry PS I haven't said it yet, but a hearty `Welcome back'! Are you interested in reinstating your general HTmmdecode()? I THINK the problem with it as far as Japanese was that you interpreted the allowed length of the string differently than from standard practice. Although the number of characters between a =?iso-,=?= pair may be limited, the number of these delineated strings is not. A real world example from a recent post to a jp news group: Subject: =?ISO-2022-JP?B?GyRCPCslNSE8JVAbKEI=?= =?ISO-2022-JP?B?GyRCN1BNMyRHQj4lVyVtJVElJCVAJE4lYSE8JWsbKEI=?= =?ISO-2022-JP?B?GyRCPHU/LhsoQg==?= Y. Sato's routines (at least recent ones, possibly not the ones in Lynx) will translate all three strings into the locale charset (euc-jp) and then concatenate them (of course you cannot see it as I do): " $B<+%5!<%P7PM3$GB>%W%m%Q%$%@$N%a!<%k%W%m%Q%$%@$N%a!<%k(J Subject: =?ISO-2022-JP?B?GyRCPHU/LhsoQg==?= X-Subject-EUC: $B; Tue, 17 Nov 1998 23:02:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA26088; Tue, 17 Nov 1998 21:35:19 -0600 (CST) Date: Wed, 18 Nov 1998 12:38:37 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811180338.MAA03758@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev 2.8.2dev.3 - exiting via interrupt (cosmetic) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 304 Lines: 7 > Might want to get rid of extra the leading newlines in the gettext() It is not a particular worry from the non-programmer translater's point of view since msgfmt watches out for unbalances in \n between the msgid and msgstr, and issues a warning with line numbers when a problem is foreseen. __Henry From owner-lynx-dev@sig.net Wed Nov 18 02:45:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA17777 for ; Wed, 18 Nov 1998 02:45:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA28230; Wed, 18 Nov 1998 01:10:26 -0600 (CST) Date: Tue, 17 Nov 1998 23:12:25 -0800 From: Irving_Wolfe@Wolfe.Net To: lynx-dev@sig.net Cc: i-a-o@Wolfe.Net Subject: lynx-dev Problem Building lynx 2.8.2dev3 -- Hope This Helps Message-ID: <19981117231225.D248@wolfe.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nFreZHaLTZJo0R7j X-Mailer: Mutt 0.94.14i Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 60497 Lines: 1400 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii I get: it.po:242: `msgid' and `msgstr' entries do not both end with '\n' found 1 fatal errors make[1]: *** [it.gmo] Error 1 make[1]: Leaving directory `/usr/home/irving/not/net/lynx2-8-2/po' make: *** [all] Error 2 This is on SuSE Linux 5.3. Linux cicada.happy-man.com 2.0.35 #2 Sun Sep 13 15:05:50 PDT 1998 i586 unknown Requested files attached. Regards, - Irving -- Irving_Wolfe@Wolfe.Net Wolfe Internet Access, L.L.C. +1 206 812 4000, ext.101 2001 Sixth Avenue, Ste. 2328 fax: +1 206 443 9446 Seattle, WA 98121 USA WolfeNet's friendly, knowledgeable people and superior Internet bandwidth can help you thrive and prosper. --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config.log" This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:607: checking host system type configure:632: checking for gcc configure:709: checking whether the C compiler (gcc ) works configure:723: gcc -o conftest conftest.c 1>&5 configure:743: checking whether the C compiler (gcc ) is a cross-compiler configure:748: checking whether we are using GNU C configure:757: gcc -E conftest.c configure:772: checking whether gcc accepts -g configure:800: checking how to run the C preprocessor configure:821: gcc -E conftest.c >/dev/null 2>conftest.out configure:863: checking for ranlib configure:890: checking whether make sets ${MAKE} configure:918: checking for style of include in makefiles configure:979: checking for a BSD compatible install configure:1033: checking for lint configure:1033: checking for alint configure:1033: checking for lclint configure:1033: checking for tdlint configure:1063: checking for AIX configure:1087: checking for POSIXized ISC configure:1113: checking if you want to see long compiling messages configure:1161: checking if you want to check memory-leaks configure:1185: checking if you want to enable debug-code configure:1230: checking if you want to turn on gcc warnings configure:1367: checking for ANSI C header files configure:1380: gcc -E conftest.c >/dev/null 2>conftest.out configure:1447: gcc -o conftest -O2 conftest.c 1>&5 configure:1471: checking for working const configure:1525: gcc -c -O2 conftest.c 1>&5 configure:1546: checking for inline configure:1560: gcc -c -O2 conftest.c 1>&5 configure:1586: checking for off_t configure:1619: checking for size_t configure:1654: checking for working alloca.h configure:1666: gcc -o conftest -O2 conftest.c 1>&5 configure:1687: checking for alloca configure:1715: gcc -o conftest -O2 conftest.c 1>&5 configure:1884: checking for unistd.h configure:1894: gcc -E conftest.c >/dev/null 2>conftest.out configure:1923: checking for getpagesize configure:1951: gcc -o conftest -O2 conftest.c 1>&5 configure:1976: checking for working mmap configure:2124: gcc -o conftest -O2 conftest.c 1>&5 configure:2152: checking for argz.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for limits.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for locale.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for nl_types.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for malloc.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for string.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for unistd.h configure:2152: checking for values.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2152: checking for sys/param.h configure:2162: gcc -E conftest.c >/dev/null 2>conftest.out configure:2192: checking for getcwd configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for munmap configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for putenv configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for setenv configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for setlocale configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for strchr configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for strcasecmp configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for __argz_count configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for __argz_stringify configure:2220: gcc -o conftest -O2 conftest.c 1>&5 configure:2192: checking for __argz_next configure:2220: gcc -o conftest -O2 conftest.c 1>&5 /tmp/cca259201.o: In function `main': /tmp/cca259201.o(.text+0x4): undefined reference to `__argz_next' configure: failed program was: #line 2197 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char __argz_next(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char __argz_next(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub___argz_next) || defined (__stub_____argz_next) choke me #else __argz_next(); #endif ; return 0; } configure:2249: checking for stpcpy configure:2277: gcc -o conftest -O2 conftest.c 1>&5 configure:2311: checking for LC_MESSAGES configure:2323: gcc -o conftest -O2 conftest.c 1>&5 configure:2344: checking whether NLS is requested configure:2365: checking whether included gettext is requested configure:2385: checking for libintl.h configure:2395: gcc -E conftest.c >/dev/null 2>conftest.out configure:2412: checking for gettext in libc configure:2424: gcc -o conftest -O2 conftest.c 1>&5 /tmp/cca259851.o: In function `main': /tmp/cca259851.o(.text+0x9): undefined reference to `gettext' configure: failed program was: #line 2417 "configure" #include "confdefs.h" #include int main() { return (int) gettext ("") ; return 0; } configure:2440: checking for bindtextdomain in -lintl configure:2459: gcc -o conftest -O2 conftest.c -lintl 1>&5 configure:2475: checking for gettext in libintl configure:2487: gcc -o conftest -O2 conftest.c 1>&5 /tmp/cca260121.o: In function `main': /tmp/cca260121.o(.text+0x9): undefined reference to `gettext' configure: failed program was: #line 2480 "configure" #include "confdefs.h" int main() { return (int) gettext ("") ; return 0; } configure:2699: checking whether catgets can be used configure:2964: checking for msgfmt configure:2998: checking for gmsgfmt configure:3030: checking for xgettext configure:3120: checking for catalogs to be installed configure:3301: checking if you want full utility pathnames configure:3322: checking for system mailer configure:3349: checking system mail flags configure:3377: checking for chmod configure:3450: checking for compress configure:3523: checking for cp configure:3596: checking for gzip configure:3669: checking for mkdir configure:3742: checking for mv configure:3815: checking for rm configure:3888: checking for tar configure:3961: checking for touch configure:4034: checking for gunzip configure:4107: checking for unzip configure:4180: checking for uudecode configure:4253: checking for zcat configure:4326: checking for zip configure:4486: checking for working const configure:4863: checking if you want socks library configure:4883: checking if you want socks5 library configure:5087: checking for network libraries configure:5098: checking for gethostname configure:5126: gcc -o conftest -O2 -DLINUX conftest.c 1>&5 configure:5264: checking for -linet configure:5278: gcc -o conftest -O2 -DLINUX conftest.c -linet 1>&5 /usr/i486-linux/bin/ld: cannot open -linet: No such file or directory configure: failed program was: #line 5271 "configure" #include "confdefs.h" int main() { main() ; return 0; } configure:5301: checking for socket configure:5329: gcc -o conftest -O2 -DLINUX conftest.c 1>&5 configure:5468: checking for gethostbyname configure:5496: gcc -o conftest -O2 -DLINUX conftest.c 1>&5 configure:5579: checking for strcasecmp configure:5695: checking for screen type configure:6208: checking for ncurses header file configure:6231: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:6317: checking for ncurses version configure:6374: gcc -o conftest -O2 -DLINUX conftest.c 1>&5 configure:6399: checking for Gpm_Open in -lgpm configure:6418: gcc -o conftest -O2 -DLINUX conftest.c -lgpm 1>&5 configure:6434: checking for initscr in -lgpm configure:6453: gcc -o conftest -O2 -DLINUX conftest.c -lgpm 1>&5 configure:6531: checking for initscr configure:6559: gcc -o conftest -O2 -DLINUX conftest.c 1>&5 /tmp/cca262061.o: In function `main': /tmp/cca262061.o(.text+0x4): undefined reference to `initscr' configure: failed program was: #line 6536 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char initscr(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char initscr(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_initscr) || defined (__stub___initscr) choke me #else initscr(); #endif ; return 0; } configure:6579: checking for initscr in -lncurses configure:6589: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:7352: checking for location of config-file configure:7362: checking for ANSI C header files configure:7466: checking whether time.h and sys/time.h may both be included configure:7480: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:7505: checking for dirent.h that defines DIR configure:7518: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:7543: checking for opendir in -ldir configure:7562: gcc -o conftest -O2 -DLINUX conftest.c -ldir -lncurses 1>&5 /usr/i486-linux/bin/ld: cannot open -ldir: No such file or directory configure: failed program was: #line 7551 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char opendir(); int main() { opendir() ; return 0; } configure:7642: checking for fcntl.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for limits.h configure:7642: checking for stdlib.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for string.h configure:7642: checking for sys/fcntl.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for sys/filio.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7648: sys/filio.h: No such file or directory configure: failed program was: #line 7647 "configure" #include "confdefs.h" #include configure:7642: checking for sys/ioctl.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for sys/param.h configure:7642: checking for sys/time.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for termio.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for termios.h configure:7652: gcc -E conftest.c >/dev/null 2>conftest.out configure:7642: checking for unistd.h configure:7680: checking termio.h and termios.h configure:7699: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:7722: checking for sys/wait.h configure:7732: gcc -E conftest.c >/dev/null 2>conftest.out configure:7860: checking for union wait configure:7877: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 compiles ok w/o union wait configure:7998: checking for uid_t in sys/types.h configure:8032: checking type of array argument to getgroups configure:8065: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8103: checking for pid_t configure:8136: checking for uid_t in sys/types.h configure:8170: checking for mode_t configure:8206: checking for vfork.h configure:8216: gcc -E conftest.c >/dev/null 2>conftest.out configure:8212: vfork.h: No such file or directory configure: failed program was: #line 8211 "configure" #include "confdefs.h" #include configure:8241: checking for working vfork configure:8391: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8415: checking if we should use fcntl or ioctl configure:8433: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8482: checking for broken/missing definition of remove configure:8495: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8535: checking for lstat configure:8550: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8582: checking for cuserid configure:8610: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8582: checking for getcwd configure:8582: checking for getgroups configure:8610: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8582: checking for putenv configure:8582: checking for readdir configure:8610: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8582: checking for strerror configure:8610: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8582: checking for waitpid configure:8610: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8640: checking for mktime configure:8668: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8640: checking for strstr configure:8668: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:8699: checking for strstr declaration configure:8713: gcc -c -O2 -DLINUX conftest.c 1>&5 configure: In function `main': configure:8708: conflicting types for `strstr' /usr/include/string.h:111: previous declaration of `strstr' configure: failed program was: #line 8704 "configure" #include "confdefs.h" #include int main() { #ifndef strstr extern int strstr(); #endif ; return 0; } configure:8768: checking for getgrgid declaration configure:8784: gcc -c -O2 -DLINUX conftest.c 1>&5 configure: In function `main': configure:8779: conflicting types for `getgrgid' /usr/include/grp.h:78: previous declaration of `getgrgid' configure: failed program was: #line 8773 "configure" #include "confdefs.h" #include #include int main() { #ifndef getgrgid extern int getgrgid(); #endif ; return 0; } configure:8768: checking for getgrnam declaration configure:8784: gcc -c -O2 -DLINUX conftest.c 1>&5 configure: In function `main': configure:8779: conflicting types for `getgrnam' /usr/include/grp.h:81: previous declaration of `getgrnam' configure: failed program was: #line 8773 "configure" #include "confdefs.h" #include #include int main() { #ifndef getgrnam extern int getgrnam(); #endif ; return 0; } configure:8841: checking if TRUE/FALSE are defined configure:8856: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:8883: checking declaration of errno configure:8902: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:8974: checking for setlocale() configure:8987: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9008: checking if NGROUPS is defined configure:9028: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9084: checking declaration of sys_nerr configure:9103: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9084: checking declaration of sys_errlist configure:9103: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9176: checking if struct utmp is declared configure:9191: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9235: checking if character set is EBCDIC configure:9254: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9249: #error "Character set is not EBCDIC" configure: failed program was: #line 9241 "configure" #include "confdefs.h" int main() { /* TryCompile function for CharSet. Treat any failure as ASCII for compatibility with existing art. Use compile-time rather than run-time tests for cross-compiler tolerance. */ #if '0'!=240 #error "Character set is not EBCDIC" #endif ; return 0; } configure:9288: checking if curses supports alternate-character set configure:9305: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9328: checking if curses supports fancy attributes configure:9347: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9367: checking for ncurses version configure:9444: checking for obsolete/broken version of ncurses configure:9464: gcc -c -O2 -DLINUX conftest.c 1>&5 configure:9489: checking if curses supports color attributes configure:9510: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9537: checking declaration of size-change configure:9590: gcc -c -O2 -DLINUX conftest.c 1>&5 size-change succeeded () configure:9622: checking if ttytype is declared in curses library configure:9635: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9663: checking for cbreak configure:9691: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9663: checking for define_key configure:9691: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9663: checking for keypad configure:9691: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9663: checking for use_default_colors configure:9691: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9663: checking for wborder configure:9691: gcc -o conftest -O2 -DLINUX conftest.c -lncurses 1>&5 configure:9721: checking if new-style forms-based options screen should be used configure:9745: checking if old-style options menu should be used configure:9769: checking if configuration info should be browsable configure:9793: checking if experimental persistent-cookie logic should be used configure:9817: checking if color-style code should be used configure:9865: checking for location of style-sheet file configure:9878: checking if partial-display should be used configure:9907: checking if you want to use default-colors configure:9932: checking if you want to use extended HTML DTD logic configure:9956: checking if you want to use external commands configure:9980: checking if you want to use setfont support configure:10004: checking if you want cgi-link support configure:10023: checking if you want exec-links support configure:10042: checking if you want exec-scripts support configure:10061: checking if you want internal-links feature configure:10085: checking if you want to fork NSL requests configure:10109: checking if you want to log URL requests via syslog configure:10133: checking if you want to underline links configure:10157: checking if help files should be gzip'ed configure:10186: checking if you want to use zlib for decompression of some gzip files configure:10339: checking if directory-editor code should be used configure:10560: checking if you want long-directory listings configure:10586: checking if parent-directory references are permitted configure:10606: checking if we can include termio.h with curses configure:10624: gcc -c -O2 -DLINUX -DHAVE_CONFIG_H -I. -I. -I./src -I./WWW/Library/Implementation conftest.c 1>&5 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config.status" #! /bin/sh # Generated automatically by configure. # Run this file to recreate the current configuration. # This directory was configured as follows, # on host cicada.happy-man.com: # # ./configure --enable-color-style --disable-dired --enable-internal-links --enable-persistent-cookies --enable-syslog --with-screen=ncurses --enable-underlines # # Compiler output produced by configure, useful for debugging # configure, is in ./config.log if it exists. ac_cs_usage="Usage: ./config.status [--recheck] [--version] [--help]" for ac_option do case "$ac_option" in -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r) echo "running ${CONFIG_SHELL-/bin/sh} ./configure --enable-color-style --disable-dired --enable-internal-links --enable-persistent-cookies --enable-syslog --with-screen=ncurses --enable-underlines --no-create --no-recursion" exec ${CONFIG_SHELL-/bin/sh} ./configure --enable-color-style --disable-dired --enable-internal-links --enable-persistent-cookies --enable-syslog --with-screen=ncurses --enable-underlines --no-create --no-recursion ;; -version | --version | --versio | --versi | --vers | --ver | --ve | --v) echo "./config.status generated by autoconf version 2.12.971230" exit 0 ;; -help | --help | --hel | --he | --h) echo "$ac_cs_usage"; exit 0 ;; *) echo "$ac_cs_usage"; exit 1 ;; esac done ac_given_srcdir=. ac_given_INSTALL="/usr/bin/ginstall -c" trap 'rm -fr makefile WWW/Library/unix/makefile src/makefile src/chrtrans/makefile intl/makefile po/makefile.in lynx_cfg.h conftest*; exit 1' 1 2 15 # Protect against being on the right side of a sed subst in config.status. sed 's/%@/@@/; s/@%/@@/; s/%g$/@g/; /@g$/s/[\\&%]/\\&/g; s/@@/%@/; s/@@/@%/; s/@g$/%g/' > conftest.subs <<\CEOF /^[ ]*VPATH[ ]*=[^:]*$/d s%@CFLAGS@%-O2 -DLINUX %g s%@CPPFLAGS@%%g s%@CXXFLAGS@%%g s%@DEFS@%-DHAVE_CONFIG_H%g s%@LDFLAGS@%%g s%@LIBS@%-lncurses %g s%@exec_prefix@%${prefix}%g s%@prefix@%/usr/local%g s%@program_transform_name@%s,x,x,%g s%@bindir@%${exec_prefix}/bin%g s%@sbindir@%${exec_prefix}/sbin%g s%@libexecdir@%${exec_prefix}/libexec%g s%@datadir@%${prefix}/share%g s%@sysconfdir@%${prefix}/etc%g s%@sharedstatedir@%${prefix}/com%g s%@localstatedir@%${prefix}/var%g s%@libdir@%${exec_prefix}/lib%g s%@includedir@%${prefix}/include%g s%@oldincludedir@%/usr/include%g s%@infodir@%${prefix}/info%g s%@mandir@%${prefix}/man%g s%@host@%i586-pc-linux-gnulibc1%g s%@host_alias@%i586-pc-linux-gnulibc1%g s%@host_cpu@%i586%g s%@host_vendor@%pc%g s%@host_os@%linux-gnulibc1%g s%@CC@%gcc%g s%@CPP@%gcc -E%g s%@RANLIB@%ranlib%g s%@SET_MAKE@%%g s%@make_include_left@%include %g s%@make_include_right@%%g s%@INSTALL_PROGRAM@%${INSTALL}%g s%@INSTALL_DATA@%${INSTALL} -m 644%g s%@LINT@%%g s%@ECHO_LD@%%g s%@RULE_CC@%# compiling%g s%@SHOW_CC@%# compiling%g s%@ECHO_CC@%%g s%@DONT_ECHO_CC@%%g s%@EXTRA_CFLAGS@%%g s%@ALLOCA@%%g s%@USE_NLS@%yes%g s%@MSGFMT@%/usr/bin/msgfmt%g s%@GMSGFMT@%/usr/bin/msgfmt%g s%@XGETTEXT@%/usr/bin/xgettext%g s%@GENCAT@%%g s%@USE_INCLUDED_LIBINTL@%yes%g s%@CATALOGS@% de.gmo es.gmo fr.gmo it.gmo ko.gmo nl.gmo no.gmo pl.gmo pt.gmo sl.gmo sv.gmo%g s%@CATOBJEXT@%.gmo%g s%@DATADIRNAME@%share%g s%@GMOFILES@% de.gmo es.gmo fr.gmo it.gmo ko.gmo nl.gmo no.gmo pl.gmo pt.gmo sl.gmo sv.gmo%g s%@INSTOBJEXT@%.mo%g s%@INTLDEPS@%$(top_builddir)/intl/libintl.a%g s%@INTLLIBS@%$(top_builddir)/intl/libintl.a%g s%@INTLOBJS@%$(GETTOBJS)%g s%@POFILES@% de.po es.po fr.po it.po ko.po nl.po no.po pl.po pt.po sl.po sv.po%g s%@POSUB@%po%g s%@INCLUDE_LOCALE_H@%#include %g s%@GT_NO@%%g s%@GT_YES@%#YES#%g s%@MKINSTALLDIRS@%./mkdirs.sh%g s%@l@%%g s%@INTLDIR_MAKE@%%g s%@MSG_DIR_MAKE@%%g s%@CHMOD@%/bin/chmod%g s%@COMPRESS@%compress%g s%@COPY@%/bin/cp%g s%@GZIP@%/bin/gzip%g s%@MKDIR@%/bin/mkdir%g s%@MV@%/bin/mv%g s%@RM@%/bin/rm%g s%@TAR@%/bin/tar%g s%@TOUCH@%/usr/bin/touch%g s%@UNCOMPRESS@%/bin/gunzip%g s%@UNZIP@%/usr/bin/unzip%g s%@UUDECODE@%/usr/bin/uudecode%g s%@ZCAT@%/usr/bin/zcat%g s%@ZIP@%/usr/bin/zip%g s%@PROG_EXT@%%g s%@LIBOBJS@%%g s%@INSTALL_LSS@%install-lss%g s%@COMPRESS_PROG@%%g s%@COMPRESS_EXT@%%g s%@SRCDIR_CLEAN@%#%g CEOF # Split the substitutions into bite-sized pieces for seds with # small command number limits, like on Digital OSF/1 and HP-UX. ac_max_sed_cmds=90 # Maximum number of lines to put in a sed script. ac_file=1 # Number of current file. ac_beg=1 # First line for current file. ac_end=$ac_max_sed_cmds # Line after last line for current file. ac_more_lines=: ac_sed_cmds="" while $ac_more_lines; do if test $ac_beg -gt 1; then sed "1,${ac_beg}d; ${ac_end}q" conftest.subs > conftest.s$ac_file else sed "${ac_end}q" conftest.subs > conftest.s$ac_file fi if test ! -s conftest.s$ac_file; then ac_more_lines=false rm -f conftest.s$ac_file else if test -z "$ac_sed_cmds"; then ac_sed_cmds="sed -f conftest.s$ac_file" else ac_sed_cmds="$ac_sed_cmds | sed -f conftest.s$ac_file" fi ac_file=`expr $ac_file + 1` ac_beg=$ac_end ac_end=`expr $ac_end + $ac_max_sed_cmds` fi done if test -z "$ac_sed_cmds"; then ac_sed_cmds=cat fi CONFIG_FILES=${CONFIG_FILES-"makefile WWW/Library/unix/makefile src/makefile src/chrtrans/makefile intl/makefile po/makefile.in:po/makefile.inn "} for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in". case "$ac_file" in *:*) ac_file_in=`echo "$ac_file"|sed 's%[^:]*:%%'` ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;; *) ac_file_in="${ac_file}.in" ;; esac # Adjust a relative srcdir, top_srcdir, and INSTALL for subdirectories. # Remove last slash and all that follows it. Not all systems have dirname. ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'` if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then # The file is in a subdirectory. test ! -d "$ac_dir" && mkdir "$ac_dir" ac_dir_suffix="/`echo $ac_dir|sed 's%^\./%%'`" # A "../" for each directory in $ac_dir_suffix. ac_dots=`echo $ac_dir_suffix|sed 's%/[^/]*%../%g'` else ac_dir_suffix= ac_dots= fi case "$ac_given_srcdir" in .) srcdir=. if test -z "$ac_dots"; then top_srcdir=. else top_srcdir=`echo $ac_dots|sed 's%/$%%'`; fi ;; /*) srcdir="$ac_given_srcdir$ac_dir_suffix"; top_srcdir="$ac_given_srcdir" ;; *) # Relative path. srcdir="$ac_dots$ac_given_srcdir$ac_dir_suffix" top_srcdir="$ac_dots$ac_given_srcdir" ;; esac case "$ac_given_INSTALL" in [/$]*) INSTALL="$ac_given_INSTALL" ;; *) INSTALL="$ac_dots$ac_given_INSTALL" ;; esac echo creating "$ac_file" rm -f "$ac_file" configure_input="Generated automatically from `echo $ac_file_in|sed 's%.*/%%'` by configure." case "$ac_file" in *Makefile*) ac_comsub="1i\\ # $configure_input" ;; *) ac_comsub= ;; esac ac_file_inputs=`echo $ac_file_in|sed -e "s%^%$ac_given_srcdir/%" -e "s%:% $ac_given_srcdir/%g"` sed -e "$ac_comsub s%@configure_input@%$configure_input%g s%@srcdir@%$srcdir%g s%@top_srcdir@%$top_srcdir%g s%@INSTALL@%$INSTALL%g " $ac_file_inputs | (eval "$ac_sed_cmds") > $ac_file fi; done rm -f conftest.s* # These sed commands are passed to sed as "A NAME B NAME C VALUE D", where # NAME is the cpp macro being defined and VALUE is the value it is being given. # # ac_d sets the value in "#define NAME VALUE" lines. ac_dA='s%^\([ ]*\)#\([ ]*define[ ][ ]*\)' ac_dB='\([ ][ ]*\)[^ ]*%\1#\2' ac_dC='\3' ac_dD='%g' # ac_u turns "#undef NAME" with trailing blanks into "#define NAME VALUE". ac_uA='s%^\([ ]*\)#\([ ]*\)undef\([ ][ ]*\)' ac_uB='\([ ]\)%\1#\2define\3' ac_uC=' ' ac_uD='\4%g' # ac_e turns "#undef NAME" without trailing blanks into "#define NAME VALUE". ac_eA='s%^\([ ]*\)#\([ ]*\)undef\([ ][ ]*\)' ac_eB='$%\1#\2define\3' ac_eC=' ' ac_eD='%g' if test "${CONFIG_HEADERS+set}" != set; then CONFIG_HEADERS="lynx_cfg.h:config.hin" fi for ac_file in .. $CONFIG_HEADERS; do if test "x$ac_file" != x..; then # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in". case "$ac_file" in *:*) ac_file_in=`echo "$ac_file"|sed 's%[^:]*:%%'` ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;; *) ac_file_in="${ac_file}.in" ;; esac echo creating $ac_file rm -f conftest.frag conftest.in conftest.out ac_file_inputs=`echo $ac_file_in|sed -e "s%^%$ac_given_srcdir/%" -e "s%:% $ac_given_srcdir/%g"` cat $ac_file_inputs > conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in rm -f conftest.frag conftest.h echo "/* $ac_file. Generated automatically by configure. */" > conftest.h cat conftest.in >> conftest.h rm -f conftest.in if cmp -s $ac_file conftest.h 2>/dev/null; then echo "$ac_file is unchanged" rm -f conftest.h else # Remove last slash and all that follows it. Not all systems have dirname. ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'` if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then # The file is in a subdirectory. test ! -d "$ac_dir" && mkdir "$ac_dir" fi rm -f $ac_file mv conftest.h $ac_file fi fi; done # Extra initialization commands, if any USE_NLS=yes # Extra commands, if any if test "$USE_NLS" = yes ; then echo creating po/makefile rm -f po/temp$$ sed -e '$s/\\//' po/POTFILES >po/temp$$ sed -e "/POTFILES =/r po/temp$$" \ po/makefile.in > po/makefile rm -f po/temp$$ fi exit 0 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config.cache" # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure # scripts and configure runs. It is not useful on other systems. # If it contains results you don't want to keep, you may remove or edit it. # # By default, configure uses ./config.cache as the cache file, # creating it if it does not exist already. You can give configure # the --cache-file=FILE option to use a different cache file; that is # what configure does when it calls configure scripts in # subdirectories, so they share the cache. # Giving --cache-file=/dev/null disables caching, for debugging configure. # config.status only pays attention to the cache file if you give it the # --recheck option to rerun configure. # ac_cv_c_const=${ac_cv_c_const=yes} ac_cv_c_inline=${ac_cv_c_inline=inline} ac_cv_func___argz_count=${ac_cv_func___argz_count=yes} ac_cv_func___argz_next=${ac_cv_func___argz_next=no} ac_cv_func___argz_stringify=${ac_cv_func___argz_stringify=yes} ac_cv_func_alloca_works=${ac_cv_func_alloca_works=yes} ac_cv_func_cbreak=${ac_cv_func_cbreak=yes} ac_cv_func_cuserid=${ac_cv_func_cuserid=yes} ac_cv_func_decl_getgrgid=${ac_cv_func_decl_getgrgid=yes} ac_cv_func_decl_getgrnam=${ac_cv_func_decl_getgrnam=yes} ac_cv_func_decl_strstr=${ac_cv_func_decl_strstr=yes} ac_cv_func_define_key=${ac_cv_func_define_key=yes} ac_cv_func_getcwd=${ac_cv_func_getcwd=yes} ac_cv_func_getgroups=${ac_cv_func_getgroups=yes} ac_cv_func_gethostbyname=${ac_cv_func_gethostbyname=yes} ac_cv_func_gethostname=${ac_cv_func_gethostname=yes} ac_cv_func_getpagesize=${ac_cv_func_getpagesize=yes} ac_cv_func_initscr=${ac_cv_func_initscr=no} ac_cv_func_keypad=${ac_cv_func_keypad=yes} ac_cv_func_lstat=${ac_cv_func_lstat=yes} ac_cv_func_mktime=${ac_cv_func_mktime=yes} ac_cv_func_mmap_fixed_mapped=${ac_cv_func_mmap_fixed_mapped=yes} ac_cv_func_munmap=${ac_cv_func_munmap=yes} ac_cv_func_putenv=${ac_cv_func_putenv=yes} ac_cv_func_readdir=${ac_cv_func_readdir=yes} ac_cv_func_setenv=${ac_cv_func_setenv=yes} ac_cv_func_setlocale=${ac_cv_func_setlocale=yes} ac_cv_func_socket=${ac_cv_func_socket=yes} ac_cv_func_stpcpy=${ac_cv_func_stpcpy=yes} ac_cv_func_strcasecmp=${ac_cv_func_strcasecmp=yes} ac_cv_func_strchr=${ac_cv_func_strchr=yes} ac_cv_func_strerror=${ac_cv_func_strerror=yes} ac_cv_func_strstr=${ac_cv_func_strstr=yes} ac_cv_func_use_default_colors=${ac_cv_func_use_default_colors=yes} ac_cv_func_vfork_works=${ac_cv_func_vfork_works=yes} ac_cv_func_waitpid=${ac_cv_func_waitpid=yes} ac_cv_func_wborder=${ac_cv_func_wborder=yes} ac_cv_header_alloca_h=${ac_cv_header_alloca_h=yes} ac_cv_header_argz_h=${ac_cv_header_argz_h=yes} ac_cv_header_dirent_dirent_h=${ac_cv_header_dirent_dirent_h=yes} ac_cv_header_fcntl_h=${ac_cv_header_fcntl_h=yes} ac_cv_header_libintl_h=${ac_cv_header_libintl_h=yes} ac_cv_header_limits_h=${ac_cv_header_limits_h=yes} ac_cv_header_locale_h=${ac_cv_header_locale_h=yes} ac_cv_header_malloc_h=${ac_cv_header_malloc_h=yes} ac_cv_header_nl_types_h=${ac_cv_header_nl_types_h=yes} ac_cv_header_stdc=${ac_cv_header_stdc=yes} ac_cv_header_stdlib_h=${ac_cv_header_stdlib_h=yes} ac_cv_header_string_h=${ac_cv_header_string_h=yes} ac_cv_header_sys_fcntl_h=${ac_cv_header_sys_fcntl_h=yes} ac_cv_header_sys_filio_h=${ac_cv_header_sys_filio_h=no} ac_cv_header_sys_ioctl_h=${ac_cv_header_sys_ioctl_h=yes} ac_cv_header_sys_param_h=${ac_cv_header_sys_param_h=yes} ac_cv_header_sys_time_h=${ac_cv_header_sys_time_h=yes} ac_cv_header_sys_wait_h=${ac_cv_header_sys_wait_h=yes} ac_cv_header_termio_h=${ac_cv_header_termio_h=yes} ac_cv_header_termios_h=${ac_cv_header_termios_h=yes} ac_cv_header_time=${ac_cv_header_time=yes} ac_cv_header_unistd_h=${ac_cv_header_unistd_h=yes} ac_cv_header_values_h=${ac_cv_header_values_h=yes} ac_cv_header_vfork_h=${ac_cv_header_vfork_h=no} ac_cv_lib_dir_opendir=${ac_cv_lib_dir_opendir=no} ac_cv_lib_gpm_Gpm_Open=${ac_cv_lib_gpm_Gpm_Open=yes} ac_cv_lib_gpm_initscr=${ac_cv_lib_gpm_initscr=yes} ac_cv_lib_inet=${ac_cv_lib_inet=no} ac_cv_lib_intl_bindtextdomain=${ac_cv_lib_intl_bindtextdomain=yes} ac_cv_path_CHMOD=${ac_cv_path_CHMOD=/bin/chmod} ac_cv_path_COMPRESS=${ac_cv_path_COMPRESS=compress} ac_cv_path_COPY=${ac_cv_path_COPY=/bin/cp} ac_cv_path_GMSGFMT=${ac_cv_path_GMSGFMT=/usr/bin/msgfmt} ac_cv_path_GZIP=${ac_cv_path_GZIP=/bin/gzip} ac_cv_path_MKDIR=${ac_cv_path_MKDIR=/bin/mkdir} ac_cv_path_MSGFMT=${ac_cv_path_MSGFMT=/usr/bin/msgfmt} ac_cv_path_MV=${ac_cv_path_MV=/bin/mv} ac_cv_path_RM=${ac_cv_path_RM=/bin/rm} ac_cv_path_TAR=${ac_cv_path_TAR=/bin/tar} ac_cv_path_TOUCH=${ac_cv_path_TOUCH=/usr/bin/touch} ac_cv_path_UNCOMPRESS=${ac_cv_path_UNCOMPRESS=/bin/gunzip} ac_cv_path_UNZIP=${ac_cv_path_UNZIP=/usr/bin/unzip} ac_cv_path_UUDECODE=${ac_cv_path_UUDECODE=/usr/bin/uudecode} ac_cv_path_XGETTEXT=${ac_cv_path_XGETTEXT=/usr/bin/xgettext} ac_cv_path_ZCAT=${ac_cv_path_ZCAT=/usr/bin/zcat} ac_cv_path_ZIP=${ac_cv_path_ZIP=/usr/bin/zip} ac_cv_path_install=${ac_cv_path_install='/usr/bin/ginstall -c'} ac_cv_prog_CC=${ac_cv_prog_CC=gcc} ac_cv_prog_CPP=${ac_cv_prog_CPP='gcc -E'} ac_cv_prog_RANLIB=${ac_cv_prog_RANLIB=ranlib} ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross=no} ac_cv_prog_cc_g=${ac_cv_prog_cc_g=yes} ac_cv_prog_cc_works=${ac_cv_prog_cc_works=yes} ac_cv_prog_gcc=${ac_cv_prog_gcc=yes} ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes} ac_cv_type_getgroups=${ac_cv_type_getgroups=gid_t} ac_cv_type_mode_t=${ac_cv_type_mode_t=yes} ac_cv_type_off_t=${ac_cv_type_off_t=yes} ac_cv_type_pid_t=${ac_cv_type_pid_t=yes} ac_cv_type_size_t=${ac_cv_type_size_t=yes} ac_cv_type_uid_t=${ac_cv_type_uid_t=yes} am_cv_val_LC_MESSAGES=${am_cv_val_LC_MESSAGES=yes} cf_cv_SYSTEM_MAIL=${cf_cv_SYSTEM_MAIL=/usr/sbin/sendmail} cf_cv_alt_char_set=${cf_cv_alt_char_set=acs_map} cf_cv_baddef_remove=${cf_cv_baddef_remove=no} cf_cv_bool_defs=${cf_cv_bool_defs=yes} cf_cv_color_curses=${cf_cv_color_curses=yes} cf_cv_dcl_errno=${cf_cv_dcl_errno=yes} cf_cv_dcl_sys_errlist=${cf_cv_dcl_sys_errlist=yes} cf_cv_dcl_sys_nerr=${cf_cv_dcl_sys_nerr=yes} cf_cv_ebcdic=${cf_cv_ebcdic=no} cf_cv_fancy_curses=${cf_cv_fancy_curses=yes} cf_cv_fionbio=${cf_cv_fionbio=ioctl} cf_cv_have_errno=${cf_cv_have_errno=yes} cf_cv_have_lib_ncurses=${cf_cv_have_lib_ncurses=yes} cf_cv_have_sys_errlist=${cf_cv_have_sys_errlist=yes} cf_cv_have_sys_nerr=${cf_cv_have_sys_nerr=yes} cf_cv_have_ttytype=${cf_cv_have_ttytype=yes} cf_cv_have_utmp=${cf_cv_have_utmp=yes} cf_cv_locale=${cf_cv_locale=yes} cf_cv_ncurses_broken=${cf_cv_ncurses_broken=no} cf_cv_ncurses_header=${cf_cv_ncurses_header=curses.h} cf_cv_ncurses_version=${cf_cv_ncurses_version=3.0.980228} cf_cv_netlibs=${cf_cv_netlibs=} cf_cv_ngroups=${cf_cv_ngroups=yes} cf_cv_screen=${cf_cv_screen=ncurses} cf_cv_sizechange=${cf_cv_sizechange=yes} cf_cv_system_mail_flags=${cf_cv_system_mail_flags='-t -oi'} cf_cv_termio_and_curses=${cf_cv_termio_and_curses=yes} cf_cv_termio_and_termios=${cf_cv_termio_and_termios=yes} cf_cv_type_unionwait=${cf_cv_type_unionwait=no} cf_cv_use_libsocks=${cf_cv_use_libsocks=no} cf_cv_use_libsocks5=${cf_cv_use_libsocks5=no} gt_cv_func_gettext_libc=${gt_cv_func_gettext_libc=no} gt_cv_func_gettext_libintl=${gt_cv_func_gettext_libintl=no} nls_cv_force_use_gnu_gettext=${nls_cv_force_use_gnu_gettext=no} nls_cv_header_intl=${nls_cv_header_intl=intl/libintl.h} nls_cv_header_libgt=${nls_cv_header_libgt=intl/libgettext.h} nls_cv_use_catgets=${nls_cv_use_catgets=no} nls_cv_use_gnu_gettext=${nls_cv_use_gnu_gettext=yes} --nFreZHaLTZJo0R7j-- From owner-lynx-dev@sig.net Wed Nov 18 03:16:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA20251 for ; Wed, 18 Nov 1998 03:16:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA01679; Wed, 18 Nov 1998 01:48:50 -0600 (CST) From: David Woolley Message-Id: <199811170833.IAA08454@djwhome.demon.co.uk> Subject: Re: lynx-dev Why doesn't lynx cache HTML source? To: lynx-dev@sig.net Date: Tue, 17 Nov 1998 08:33:30 +0000 (GMT) In-Reply-To: from "Leonid Pauzner" at Nov 16, 98 02:09:57 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: 1868 Lines: 36 > It was a problem in HTTP/1.0 with different contents, i.e. the same document > may be available in different forms for different charset or user agant, etc, Very few web site creators have the technical competence to even know that content negotiation is possible. Most browser dependent content is done using Microsoft's ASP application level code. Other content negotiation is very unlikely (the only confirmed siting is that w3.org will serve PNG to anyone admitting to be able to handle it, but this is rare and caused confusion because the resulting object didn't have a .png extension and couldn't be handled by a Windows browser locally. > I hope HTML form submits as POST and the responce usually have ? to indicate > info on submitting to made URL unique enough, also this is plain wasting of > cache capacity because too many different submit request may be possible... There are legitimate reasons for using GET mode forms (basically to make the results cacheable because there are no side effects - this applies to most search engines although some are uncacheable for other reasons). However, because the GET/POST distinction was too subtle for many designers there are a lot of GET mode forms with side effects. Another factor, is that is some environments it is slightly easier to program the handling of GET than POST form parameters, and, as should be obvious to Lynx users, many designers aren't interested in correctness, only the immediate commercial objectives. If GET mode forms were used properly, caching policies would depend on the nature of the traffic and the position of the cache in the hierarchy. A browser would probably want to cache. Incidentally, one use of GET mode forms is with SELECTION elements to provide and alternative presentation for a menu (without using JavaScript), or for a two dimensional menu. > > > > From owner-lynx-dev@sig.net Wed Nov 18 03:47:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA22429 for ; Wed, 18 Nov 1998 03:47:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA04303; Wed, 18 Nov 1998 02:18:25 -0600 (CST) Date: Wed, 18 Nov 1998 17:21:42 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811180821.RAA11704@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev why have --datadir=DIR if you can't use it? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1132 Lines: 43 Pretty please?! (for the third time): *** lynx2-8-2/makefile.in.orig Wed Nov 18 13:06:20 1998 --- lynx2-8-2/makefile.in Wed Nov 18 13:07:48 1998 *************** *** 48,56 **** helpdir= @libdir@/lynx_help ## Where your locale data is ! # datadir = @datadir@ ! datadir = /usr/local/share ! localedir = $(datadir)/locale ##set the relative location of the WWW library Implementation directory, ##from this directory --- 48,55 ---- helpdir= @libdir@/lynx_help ## Where your locale data is ! datadir = @datadir@ ! localedir = @datadir@/locale ##set the relative location of the WWW library Implementation directory, ##from this directory *** lynx2-8-2/src/makefile.in.orig Wed Nov 18 13:25:08 1998 --- lynx2-8-2/src/makefile.in Wed Nov 18 13:25:45 1998 *************** *** 13,20 **** top_builddir = .. ! # see po/makefile ! localedir = $(prefix)/@DATADIRNAME@/locale # Symbols which the configure script can set in each makefile: CC = @CC@ --- 13,19 ---- top_builddir = .. ! localedir = @datadir@/locale # Symbols which the configure script can set in each makefile: CC = @CC@ From owner-lynx-dev@sig.net Wed Nov 18 06:05:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA00537 for ; Wed, 18 Nov 1998 06:05:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA15306; Wed, 18 Nov 1998 04:32:33 -0600 (CST) Date: Wed, 18 Nov 1998 04:34:47 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev strange interaction with gettext/anonymous/gz In-Reply-To: <199811180320.MAA03584@ews07.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: 2541 Lines: 54 On Wed, 18 Nov 1998, Nelson Henry Eric wrote: > There wasn't really enough discussion on the pros and cons of going > to gettext. In order to do it right, i.e., translaters will be able > to *simply* run xgettext to get a correct template to do the translations > on, will make it a must that at least some of the Lynx developers have > a fairly good knowledge of the gettext mechanism. I fear the burden on > the programmers is going to be a pretty heavy, at least in the initial > stages. For the non-programmer to be able to maintain the translation > part, without unwittingly introducing bugs of the type already mentioned > by Claude, will require that the programmer know how to efficiently use > keywords and comments, which xgettext, and subsequently, msgfmt know about. Well, I haven't even looked at the dev.n code yet; but since there aren't many alternatives AFAIK, and gettext seems to be the GNU way, in principle I'm all for it. I just prefer to look at other things now, and leave the gettext stuff to those already more familiar with it. As long as I don't introduce or change user-visible strings, there shouldn't be a problem, right? > PS I haven't said it yet, but a hearty `Welcome back'! Thank you, and the others. > Are you interested in reinstating your general HTmmdecode()? I > THINK the problem with it as far as Japanese was that you interpreted > the allowed length of the string differently than from standard > practice. Although the number of characters between a =?iso-,=?= pair > may be limited, the number of these delineated strings is not. A > real world example from a recent post to a jp news group: > > Subject: =?ISO-2022-JP?B?GyRCPCslNSE8JVAbKEI=?= =?ISO-2022-JP?B?GyRCN1BNMyRHQj4lVyVtJVElJCVAJE4lYSE8JWsbKEI=?= =?ISO-2022-JP?B?GyRCPHU/LhsoQg==?= > [ ... ] > This is in reference to CHANGES (1997-12-13) > * Restored the v2.7.1 HTmmdecode() that's specific for iso-2022-jp in > HTMIME.c. We still only call it when HTCJK == JAPANESE, and the > generalized version reportedly has problems. - FM What were those problems? Does anyone remember, or would I find them in the archives? If the problem was only that it was too restrictive with respect to length, that could be easily changed by bumping up that number, but I somehow doubt that that was the only problem. Are you asking for the other HTmmdecode() because it also treated non-Japanese strings, or for some other reason? How does the current Lynx show that Subject line? Klaus From owner-lynx-dev@sig.net Wed Nov 18 06:20:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA01783 for ; Wed, 18 Nov 1998 06:20:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA16697; Wed, 18 Nov 1998 04:51:36 -0600 (CST) Date: Wed, 18 Nov 1998 04:53:51 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev partial display (was: on 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: 2025 Lines: 41 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > Just a more practical thought. > > How does display partial logic appears in lynx? > One boy from Check found out that repaint done by HText_pageDisplay() > and the appropriate place to call it from HTFormat.c/HTCopy() while > reading stream and LYUtils.c/HTCheckForInterrupt() to enable scrolling. > He made an alpha patch and disconnected from lynx-dev. > Of cause, we got a lot of bugs and and side effects. > Now I jump into and fix them by introducing several flags: > including two linecounters, durty workaround for "forms input" problems, > and a synchronization semaphore (!), > we got it in 5-10 sequential attempts... > What I want to say: it wasn't supposed to do so by lynx original designers > but the internal structure permits this (except few more recent bugs - > we find a workarond for them). Some things about the partial display: I am not surprised that it took 5-10 sequential attempts. I am actually surprised that it didn't take more changes to the code, and that it works more-or-less nicely already. Functions now get called in situations where they never were meant to be called, and it is astonishing that they don't crash (even if the display sometimes get garbled). I am working on changing HText_trimHightext() so that it can deal correctly with being called several times, and will submit a patch. But it occured to me that there may be a much simper solution to the problems with form fields: What happens if you just don't do the highlight(OFF, (nlinks - 1), target); in display_page() while being in incremental rendering mode? Could you please try that? (You know best which flags to check for determine whether the function is called during partial display.) Then calling HText_trimHightext() may not be necessary at all. You may also want to break out of the two major loops in display_page() when text->last_line has been reached, because that is the line still being filled (only during partial display). Klaus From owner-lynx-dev@sig.net Wed Nov 18 06:26:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA01912 for ; Wed, 18 Nov 1998 06:26:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA17233; Wed, 18 Nov 1998 04:58:32 -0600 (CST) Date: Wed, 18 Nov 1998 05:00:47 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? In-Reply-To: <199811172349.PAA18229@netcom4.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.flora.ottawa.on.ca id GAA01912 Status: RO Content-Length: 579 Lines: 15 On Tue, 17 Nov 1998, David Combs wrote: > > > I DON'T CARE whether that page is in-sync or not. If I worry > > > about a given page, I can just do a ^C, and get a "fresher" copy. > > ^^^^^^^^ > > right mr. Combs! > > ^R of course. sorry. You know about ^R, and so do I and probably most readers of this list. Most lynx users may not know about it. The point is that any change or addition to caching shouldn't increase the chance that a more naïve lynx user gets a "stale" version of a document. Klaus From owner-lynx-dev@sig.net Wed Nov 18 06:40:04 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA02872 for ; Wed, 18 Nov 1998 06:40:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA18193; Wed, 18 Nov 1998 05:09:12 -0600 (CST) Date: Wed, 18 Nov 1998 05:11:28 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too In-Reply-To: <199811161624.IAA06571@netcom17.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: 1495 Lines: 39 On Mon, 16 Nov 1998, David Combs wrote: > > From owner-lynx-dev@sig.net Sun Nov 15 10:17:21 1998 > > > > On Sun, 15 Nov 1998, David Combs wrote: > > > > > How much of a pain would it be for the parser to grab the > > > "title" associated with the www-addr that lynx goes-to, > > > and on the "L"-page, to display that title out to the > > > right? > > > > Lynx ALREADY shows the title on the List page, instead of the > > address -- if it knows the title. > > But I don't want JUST the title -- in fact, EACH line should > have the address. > > (It is the ADDRESS that is important for THIS page, the L-page) > > What I want is BOTH of them, on the SAME line: addr first, then title > (or vice versa, I gess that would be ok?). Ok, it wasn't clear to me before what you wanted. So you want something that looks like the history page? > I'm saying that an option to have BOTH would be a real win. You can't have the title unless lynx already has already seen it recently. (In the same session. Unless someone adds a "permanent history list".) So some entries could have tho lines, and others one line. > QUESTION: does ANYONE ELSE think they'd find this useful? Personally, I don't. :) I just haven't missed it. And it means that less links fit on one page. So I won't make a patch for it. But if you can convince someone else, it shouldn't be too difficult to change LYList.c to do what you want (since the function calls to get the title and addres are already there). Klaus From owner-lynx-dev@sig.net Wed Nov 18 07:09:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA05485 for ; Wed, 18 Nov 1998 07:09:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA21076; Wed, 18 Nov 1998 05:41:21 -0600 (CST) Date: Wed, 18 Nov 1998 06:43:06 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811180643.AA13529@cas.org> Subject: lynx-dev Request for Comment: partial display and refresh To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1011 Lines: 20 When I configure lynx to do partial display and to use ncurses 4.2.patched thru the first week of November, it appears that at the end of the loading of the file, lynx does a screen refresh. I am wondering if someone familar with that code could conceive of a way for that code to some how determine whether or not the refresh is necessary. In many cases, lynx loads things so quickly that the refresh occurs almost as fast as the initial load occurs - causing the screen to 'blink'. I would rather not see that blink if necessary. I see this on my Mac vt220 emulator (at 28k), my Solaris dtterm, and to a lesser annoyance under rxvt and xterm. Apparently dtterm does its text screen refreshes at about the same speed as the mac at 28k :-( . -- 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 Nov 18 08:17:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA11022 for ; Wed, 18 Nov 1998 08:17:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA27497; Wed, 18 Nov 1998 06:46:57 -0600 (CST) Date: Wed, 18 Nov 1998 21:50:36 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811181250.VAA13744@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev strange interaction with gettext/anonymous/gz Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2561 Lines: 57 > Well, I haven't even looked at the dev.n code yet; but since there aren't > many alternatives AFAIK, and gettext seems to be the GNU way, in principle > I'm all for it. I just prefer to look at other things now, and leave the Echos my sentiments. > If the problem was only that it was too restrictive with respect to length, > that could be easily changed by bumping up that number, but I somehow > doubt that that was the only problem. I tried moving the number to twice what you had, but it still wasn't enough to catch all the problem SUBJECTS. In truth, the only way I could get it to work was to block all your checks on the strings and force the whole thing to a "valid" (or was that invalid?) string. It seemed to me that what was happening was that the string was getting truncated somewhere, with the result that occasionally a multibyte character would get split in a place that would result in a non-ascii character that messed up what came after it. At the time, I thought it was because the function seemed to analyze the =?iso-nnnn part only one time, whereas in fact it can occur multiple times. It also seemed like it was trying to cut out the =?iso-nnnn part, when it could just stay there. But really my memory has faded a lot. > Are you asking for the other HTmmdecode() because it also treated > non-Japanese strings, or for some other reason? Just thought it was a very noble idea for Lynx to try to handle any language, not just CJK. I'm sure you've got your own priorities, so fiddle with it only if you want. I just wanted to let you know that I would continue to check that it was working or not with CJK. (My level of understanding has not increased from a year ago, so take that tongue-in-cheek.) > How does the current Lynx show that Subject line? Fine (Lynx also did the posting): fj.test, Articles 105995-106024 ([1]Earlier articles...) Articles in fj.test * [3]"$B%F%9%H$G$9!#(J" - OwlTKHS * [4]"$B;n83Cf(J" - OwlTKHS * [5]"Re: test test" - "LOVE CAT" [...] ignore @@NCM" - Usenet exProwler * [12]"$B%F%9%H$G$"$j$^$9$k(J" - "skintone" <== this one's funny -HN * [13]"none" - Anonymous [...] * [29]"EFNET NoCeM Report ncmreport.fj+japan+tnn-sbi.19981117-0415.1 ignore @@NCM" - Usenet exProwler * [30]"$B<+%5!<%P7PM3$GB>%W%m%Q%$%@$N%a!<%k; Wed, 18 Nov 1998 08:34:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA29771; Wed, 18 Nov 1998 07:06:26 -0600 (CST) From: dickey@clark.net Message-Id: <199811181308.IAA17110@shell.clark.net> Subject: Re: lynx-dev strange interaction with gettext/anonymous/gz To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 08:08:42 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 18, 98 04:34: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: 728 Lines: 15 > Well, I haven't even looked at the dev.n code yet; but since there aren't > many alternatives AFAIK, and gettext seems to be the GNU way, in principle > I'm all for it. I just prefer to look at other things now, and leave the > gettext stuff to those already more familiar with it. As long as I don't > introduce or change user-visible strings, there shouldn't be a problem, > right? right. At some point (after Thanksgiving) I'll work on moving some of the repeated strings into LYMessages_en.h (besides the maintenance issues, reducing the number of files with strings may make this work with Solaris' gettext - that's one of the problems). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 08:35:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA12557 for ; Wed, 18 Nov 1998 08:35:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA00249; Wed, 18 Nov 1998 07:09:25 -0600 (CST) From: dickey@clark.net Message-Id: <199811181311.IAA19118@shell.clark.net> Subject: Re: lynx-dev Request for Comment: partial display and refresh To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 08:11:40 -0500 (EST) In-Reply-To: <9811180643.AA13529@cas.org> from "lvirden@cas.org" at Nov 18, 98 06:43:06 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: 569 Lines: 15 > In many cases, lynx loads things so quickly that the refresh occurs > almost as fast as the initial load occurs - causing the screen to > 'blink'. > > I would rather not see that blink if necessary. nor I (we discussed this in September - I saw it around the same time you reported it). But it's one of several bugs to look at. At the moment I'm trying to catch up on submitted patches so I can leave town for a few days. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 08:38:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA12606 for ; Wed, 18 Nov 1998 08:38:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA29072; Wed, 18 Nov 1998 07:00:59 -0600 (CST) From: dickey@clark.net Message-Id: <199811181303.IAA16335@shell.clark.net> Subject: Re: lynx-dev why have --datadir=DIR if you can't use it? To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 08:03:15 -0500 (EST) In-Reply-To: <199811180821.RAA11704@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 18, 98 05:21: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: 1438 Lines: 52 > Pretty please?! (for the third time): I'll look at this in the next patch - this won't work as you've written it, but it's a good reminder. > *** lynx2-8-2/makefile.in.orig Wed Nov 18 13:06:20 1998 > --- lynx2-8-2/makefile.in Wed Nov 18 13:07:48 1998 > *************** > *** 48,56 **** > helpdir= @libdir@/lynx_help > > ## Where your locale data is > ! # datadir = @datadir@ > ! datadir = /usr/local/share > ! localedir = $(datadir)/locale > > ##set the relative location of the WWW library Implementation directory, > ##from this directory > --- 48,55 ---- > helpdir= @libdir@/lynx_help > > ## Where your locale data is > ! datadir = @datadir@ > ! localedir = @datadir@/locale > > ##set the relative location of the WWW library Implementation directory, > ##from this directory > *** lynx2-8-2/src/makefile.in.orig Wed Nov 18 13:25:08 1998 > --- lynx2-8-2/src/makefile.in Wed Nov 18 13:25:45 1998 > *************** > *** 13,20 **** > > top_builddir = .. > > ! # see po/makefile > ! localedir = $(prefix)/@DATADIRNAME@/locale > > # Symbols which the configure script can set in each makefile: > CC = @CC@ > --- 13,19 ---- > > top_builddir = .. > > ! localedir = @datadir@/locale > > # Symbols which the configure script can set in each makefile: > CC = @CC@ -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 09:37:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA17176 for ; Wed, 18 Nov 1998 09:37:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA11657; Wed, 18 Nov 1998 08:12:09 -0600 (CST) Date: Wed, 18 Nov 1998 08:14:22 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? In-Reply-To: <199811151157.LAA05524@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: 11056 Lines: 228 Commenting on an older message: On Sun, 15 Nov 1998, David Woolley wrote: > > > A large proportion of web pages these days are uncacheable, often for > > > misguided commercial reasons. I strongly suspect that a disproportionate > > > number of the ones that people will need to view source on or parse in > > > different ways will fall in this category. Yeah, probably... But looking at the SOURCE of completely valid and static pages is still useful. And toggling image links with '*' and so on. > > Thats mostly because Lynx say "HTTP/1.0" in it's header and server reply so. (No, as mentioned elsewhere.) > > HTTP 1.1 have unique ETag that allow advanced validation for any cached data. > > So most benefits from lynx cache - to receive short responce like HEAD > > instead of fetching a complete document (sometimes even a head-like request > > not needed but this is an obvious check and not for your case). > > Very little of the web server and cache software around supports ETag. Apache does. It generates Etag whenever it automatically generates Last-Modified for a static file, AFAIK. > But, in any case most cacheability failures are due to apparently deliberate > attempts to frustrate it (accurate hit counts are much more saleable that > fast access, it seems) or dynamic content that goes way beyond content > negotiation (I don't think many people even know it is possible). "Deliberate" or, maybe more often, "We never thought of it". See : why is there no Last-Modified header? > > You will help me considerably if you read spec and compare against > > the comments in HTTP.c - actions on return status (200, 304, etc, etc.) > > Looks like I will have to do this. [ ... ] > > If any browser revalidate something once per session it obviously > > break the spec: there are a special http/1.1 rules for this, > > for example, Expired or "no-cache" documents should be validated every time > > we are trying to access them. > > I think that IE4 will honour Expires - in fact we had to remove an > immediate expires from a dynamic page because it was expired even > before it could handed on to an OLE helper (Excel). I'd have to check > the status of no-cache. But most pages do not have these headers (and > when they start to, will probably have the authoring tools defaults!). > IE4 does not use heuristics on Last Modified Date and will still cache > pages without this header and without other cache controlling headers. > There is a user configuration option with three values: never revalidate, > validate once per session and always revalidate. Out of the box it > is once per session and most users will never change it from that. > Lynx currently also behaves as once per session! :) Well Lynx behaves as "once per session", except that "revalidation" always consists of a new fetch (no If-Modified-Since). > Calculation based revalidation normally requires an extensive set of rules, > e.g. most people configure external caches to assume that the likely lifetime > of a .gif is a much larger proportion of its lifetime up to the point of > fetching than they would for a .html or .htm. The rules may also favour > certain sites. It doesn't have to be that difficult. Of course one can make very complex rules, but a simple "10% of the age when received" heuristic for freshness lifetime can go a long way. > The formal backing for this behaviour is section 13.13. of RFC 2068, > although there might be semantic arguments about the border between > caching and history mechanisms (as a user, I would expect the same result > from using the back button to return to a home page and using a link > on the subordinate page); in my view, all those wanting unrendered > caching in Lynx to support the \ command would want the history > interpretation, to avoid refetching of dynamic content. I think we all agree that '\' and similar should ideally have "history" behavior, as opposed to "semantically transparent" behavior. Although that is a deliberate choice of one of several possible interpretations. Regarding the parenthesis: You may expect that, but it would be wrong. And there is not way for an author to say "this link should have history behavior". That is for "normal" links, disregarding any scripting. > In fact this section has a warning that using revalidation for history > pages may actually cause site designers not to use cache control > information properly on their pages, because to do so migh force > unexpected reloads and unstable content. > > > The rules insist on validating (either by local calculation or with remote) > > for entry using of cached data, no more nor less. > > I think we may be a little more strict and ask the remote (server or proxy) > > for validation when we could do this but too lazy to do our calclulations. We should never make more network requests than necessary, if there is no other benefit, just because someone was too lazy! > > Anyway, this is a small overhead and could be easily done > > when the main code will be implemented (not so easy!). > > Revalidation itself can sometimes be slow (and, as was the main point of the > article, will very often result in a complete reload of the page). Indeed. > Slowness > is particularly a problem for GUI browsers, where a large number of GIFs > may have to be revalidated! It also makes it impossible to operate the > browser in offline mode. IE4 has explicit support for this, but even > Lynx will satisfy pages from its rendered cache, even though you've > stopped paying the phone company or ISP for connectivity. Let's image a scale of possible behavior (although that cannot really all be expressed in one dimension): complete use all semantic <----------------------------------|-------> cached data transparency | forever Lynx in general Complete transparency means: whenever a link is followed, a new request is made. The other end of the scale would be: ignore all "no-cache", "expires" etc. directives, keep documents around as long as they fit in the cache, and never re-request what we already have. No client implements either extreme (by default). Lynx is currently closer to the right; it is not completeley there because it honors no-cache in responses and (some forms of) Expires, and resubmits POST and HEAD requests. There are several "modes" of going to a page: 1) explicit reload: ^R, 'x' 2) '*', '\', '[', '"', ^V, etc. 3) form submissions (POST) 4) following a normal link, entering an address with 'g' etc.; default 5) going back in history: either left arrow, or link from History Page I have ordered them according to the scale above, 1) corresponds to the left end, 5) to the right end. I would argue that any change or addition of caching mechanisms should not move Lynx much to the left or to the right, for any of the modes, _by default_ -- except for 2), see below. I don't want a lynx session to act much more semantically transparent by default (I have a slow link, too), especially for 4), although it would be more correct to do so (it should follow the rules HTTP sets for caches more closely). But it would be nice to be able to configure Lynx to act more semantically transparent. I also don't want Lynx to act (much) more relaxed by default. But it would be nice to be able to configure Lynx to do even less checking. (For example, never honor Expires, or ignore it in META tags.) Mode 2 is different, because it is close to the left by accident and not by design: we would like it to behave like 5 but cannot since we throw away the raw bytes. So now someone wants to implement a cache for raw bytes of HTML documents to achieve that. Apart from the implementation, the major question is: how should this change the behavior in other modes. If the answer is: It shouldn't, by default -- then the minimal solution is simple: just use the new rawdata cache for what it was intended, that is only mode 2 requests. It is very tempting to reuse the rawdata for mode 5 requests -- it seems such a waste not to do it -- but we don't have to do it. If the new rawbyte cache never gets used for requests other than mode 2, then no change is needed in the rules for when to make a new request, and no If-Modified-Since/Etag implementation is needed to preserve the current behavior. IMS/Etag/304 could still be implemented later, but that is then a separate problem. (It could also already be implemented already now, for the existing rendered-doc cache, [except for the "language confusion" problem,] which shows that it is separate.) But it DOES seem wasteful to keep raw data if in most cases we won't use them. But: A. The impementation doesn't have to be complicated if - We never keep the cached raw data around for longer than we keep the rendered text, with one exception: during a mode 2 request when the data is reparsed. - We keep cached raw data in memory (not files). We could simply put each bufferful of data into a HTChunk while it is being received. - There is no new expiration, validation, or timestamp comparison logic, so no new metadata needs to be stored. B. It can be greatly restricted what documents get entered into the cache in the first place. We have a choice of - Caching everything received. - Caching all text/html, maybe with further restrictions based on URL, method, etc. - Require explicit user action. Maybe a special "Enter cache" key, meaning "I am going to want this text reparsed, so start caching it". - When '\' is pressed the first time for the current text, we mark if for rawbyte caching. There could be a confirmation question. That means at least two network request are needed, but after that cached data is used. When we go to view a document in other than mode 2, the cached data can be thrown away. Or alternatively, whenever there is a new network request. Note that this could be done without significant changes in mainloop(). It just would have to set a "this is a mode 2 request" flag, HTuncache_current_document() might have to take care to preserve existing raw data in this case (and maybe get rid of it otherwise), Then other lower-level functions could handle the storing to cache and reading from it. The mainloop() function wouldn't have to know where the new data comes from. > Actually, if there is a case for source caching in Lynx, as against an > external caching proxy, it is that it can relax the revalidation rules. I agree that that would be at least an important benefit. It should be configurable how relaxed we are. My above ideas only address the specific case of what I called mode 2 requests. For all other situations, the answer "use an external caching proxy" would still apply. Klaus From owner-lynx-dev@sig.net Wed Nov 18 10:17:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA20517 for ; Wed, 18 Nov 1998 10:17:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23761; Wed, 18 Nov 1998 08:55:13 -0600 (CST) Date: Wed, 18 Nov 1998 09:56:28 -0500 (EST) Message-Id: <199811181456.JAA05402@mail.bcpl.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.flora.org/lynx-dev/html/month1198/msg00454.htmlContent-Type: text/plain; charset=iso-8859-1 X-Mailer: Lynx, Version 2.8.1dev.12 X-Personal_name: Webmaster Jim From: "Webmaster Jim" Subject: http://www.flora.org/lynx-dev/html/month1198/msg00454.html Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1383 Lines: 25 > * Subject: Re: lynx-dev strange interaction with > gettext/anonymous/gz > * From: dickey@clark.net > * Date: Wed, 18 Nov 1998 08:08:42 -0500 (EST) > * In-Reply-To: > from > "Klaus Weide " at Nov 18, 98 04:34:47 am >> Well, I haven't even looked at the dev.n code yet; but since there aren't >> many alternatives AFAIK, and gettext seems to be the GNU way, in principle >> I'm all for it. I just prefer to look at other things now, and leave the >> gettext stuff to those already more familiar with it. As long as I don't >> introduce or change user-visible strings, there shouldn't be a problem, >> right? >right. At some point (after Thanksgiving) I'll work on moving some of the >repeated strings into LYMessages_en.h (besides the maintenance issues, >reducing the number of files with strings may make this work with Solaris' >gettext - that's one of the problems). I was working hard to remove the "en" file beacuse I thought it conflicted with the operation of gettext, in that identical messages map to a single catalog entry, and therefore to a single translation (per language). Using macros may save some space in the source code, but I felt it was more useful to see the full messages in context of the code when doing translation work. (I'm back, too.) From owner-lynx-dev@sig.net Wed Nov 18 10:22:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA21160 for ; Wed, 18 Nov 1998 10:22:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA23359; Wed, 18 Nov 1998 08:54:12 -0600 (CST) Date: Wed, 18 Nov 1998 08:56:25 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Request for Comment: partial display and refresh In-Reply-To: <199811181311.IAA19118@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: 1028 Lines: 23 On Wed, 18 Nov 1998 dickey@clark.net wrote: [LWV:] > > In many cases, lynx loads things so quickly that the refresh occurs > > almost as fast as the initial load occurs - causing the screen to > > 'blink'. > > > > I would rather not see that blink if necessary. > > nor I (we discussed this in September - I saw it around the same time you > reported it). But it's one of several bugs to look at. At the moment I'm > trying to catch up on submitted patches so I can leave town for a few days. The second call to display_page() could be skipped if and only if the following is true: when display_page() was called before, during incremental rendering, it was called for the same range of lines and HText_trimHightext() had been done. But I don't understand why the screen repaints even if display_page() is called again: there are refresh() calls, but they shouldn't result in a complete redraw unless clearok() or clear() have been called, or erase() and then refresh(), and I don't see where that happens. Klaus From owner-lynx-dev@sig.net Wed Nov 18 10:31:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA21674 for ; Wed, 18 Nov 1998 10:31:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26698; Wed, 18 Nov 1998 09:04:05 -0600 (CST) Date: Wed, 18 Nov 1998 10:05:21 -0500 (EST) Message-Id: <199811181505.KAA07113@mail.bcpl.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.flora.org/lynx-dev/html/month1198/msg00447.htmlContent-Type: text/plain; charset=iso-8859-1 X-Mailer: Lynx, Version 2.8.1dev.12 X-Personal_name: Webmaster Jim From: "Webmaster Jim" Subject: lynx-dev re: why have --datadir=DIR if you can't use it? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 750 Lines: 15 > * Subject: lynx-dev why have --datadir=DIR if you can't use it? > * From: Nelson Henry Eric > * Date: Wed, 18 Nov 1998 17:21:42 +0900 (JST) >Pretty please?! (for the third time): > > ## Where your locale data is >! # datadir = @datadir@ >! datadir = /usr/local/share >! localedir = $(datadir)/locale For the record, I left this as a fixed value because I was unable to figure out how to pass a configure value from the top-level down to the correct place. Believe me, I tried. Perhaps now that others have seen the code they can suggest how this value can be configured and over-ridden. Apparently it works in the reference "hello" program but that has a different top-level configure script and makefile. From owner-lynx-dev@sig.net Wed Nov 18 10:46:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA22826 for ; Wed, 18 Nov 1998 10:46:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA01642; Wed, 18 Nov 1998 09:19:53 -0600 (CST) From: francis@ncgraphics.co.uk (Francis Irving) To: lynx-dev@sig.net Subject: lynx-dev Problems with -traversal Date: Wed, 18 Nov 1998 15:21:51 GMT Message-ID: <3655d4f0.175758890@clarabel> X-Mailer: Forte Agent 1.5/32.451 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.flora.ottawa.on.ca id KAA22826 Status: RO Content-Length: 1308 Lines: 38 With -traversal, Lynx keeps traversing the same page over and over again. I'm using version 2.8.1rel.1, the Win32 port (downloaded today from http://www.fdisk.com/doslynx/wlynx/lynx_w32.zip). Example. with an empty current directory type: > lynx -traversal http://www.meta.demon.co.uk Lynx gets stuck in an infinite loop, and generates two files [d:\sitetest]type traverse.dat http://www.meta.demon.co.uk/ http://www.meta.demon.co.uk/i.html http://www.meta.demon.co.uk/index.html http://www.meta.demon.co.uk/i.html http://www.meta.demon.co.uk/index.html http://www.meta.demon.co.uk/i.html [d:\sitetest]type traverse2.dat http://www.meta.demon.co.uk/ Francis's page http://www.meta.demon.co.uk/i.html I http://www.meta.demon.co.uk/index.html Francis's page http://www.meta.demon.co.uk/i.html I http://www.meta.demon.co.uk/index.html Francis's page http://www.meta.demon.co.uk/i.html I http://www.meta.demon.co.uk/index.html Francis's page http://www.meta.demon.co.uk/i.html I which repeat in this way. I didn't have the same problem with an earlier pre-release of the same version. Thanks for your help! This is a perfect feature for checking web site links, and it would be great if I could get it to work. Francis. Home: francis@pobox.co.uk Web: www.meta.demon.co.uk From owner-lynx-dev@sig.net Wed Nov 18 11:11:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA25207 for ; Wed, 18 Nov 1998 11:11:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA11787; Wed, 18 Nov 1998 09:51:30 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811181319.PAA17851@ozone.fmi.fi> Subject: Re: lynx-dev gettext() question #2 In-Reply-To: from Leonid Pauzner at "Nov 16, 1998 02:37:26 am" To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 15:19:44 +0200 (EET) Cc: lynx-dev@sig.net X-Mailer: ELM [version 2.4ME+ PL50 (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: 1461 Lines: 38 Leonid Pauzner: > >> At the risk of getting flamed (wouldn't be the first time :), shouldn't > >> these questions be going to the gettext mailing list? > > > > Nope. Lynx is using gettext; gettext isn't using lynx. > > > My question was meant to provoke some thought. Specifically, will it be > > possible to change, on the fly, what language gettext is using. And if so, > > consider adding that to the user interface somehow. > > > Again, referring to my original reason for proprosing such an ability: > > public access lynx where the admin might be interested in providing > > multiple languages for the users. > > There is another problem possible: > gettext() support based on language, not character set (usually iso-8859-1). > Lynx support a list of character sets, so a person using cpXXX display > will be confused... Display charset generally independent from LOCALE, > assuming a person start lynx from the remote terminal. $LANG includes implicity character set, because it specifies also LC_CTYPE locale. So if user is using some remote terminal, he needs adjust $LANG also to get other programs (than lynx) to work correctly. Some systems there is several possible $LANG values for same language (which just differ by used caharacter-set). For example: en_US en_US.ISO8859-1 It may make do sense to map $LANG (or result of setlocale(LC_CTYPE,NULL) actually) to character set with some (OS dependent) mapping table. / Kari Hurtta From owner-lynx-dev@sig.net Wed Nov 18 11:21:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA25958 for ; Wed, 18 Nov 1998 11:21:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14965; Wed, 18 Nov 1998 10:01:25 -0600 (CST) To: lynx-dev@sig.net References: <19981117181021.A886@psnw.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 18:44:39 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1156 Lines: 25 > As things are presently: > Two sessions, A and B are running. Both load the same set of cookies > from COOKIE_FILE. > Session A gets a new cookie from some site, then exits, writing all > the original cookies and the new cookie to COOKIE_FILE. > Session B quits, overwriting COOKIE_FILE with all the original > cookies, but blowing away the new cookie that session A received. > So here's my thought -- prior to writing cookies in memory to COOKIE_FILE, > Lynx should *reread* COOKIE_FILE, ignoring any cookies that are already in > memory, but adding cookies from the file that are not in memory. > The only thing coming to mind so far that could be a problem here would be > getting two cookies with the same 'name' attribute from a server in two > different sessions (two unique identifiers from advertising sites?), in > which case the one which is written to COOKIE_FILE first (thus read into > memory in the other Lynx session, overwriting the existing one) will be > maintained, and the others dropped. Remote server may change cookie expiration date, which date should be correct from session A or from session B? From owner-lynx-dev@sig.net Wed Nov 18 11:22:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA25989 for ; Wed, 18 Nov 1998 11:22:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA13031; Wed, 18 Nov 1998 09:55:18 -0600 (CST) From: Ilya Zakharevich Message-Id: <199811180826.DAA09278@monk.mps.ohio-state.edu> Subject: lynx-dev Building the latest devel release of lynx on OS/2 To: lynx-dev@sig.net, emx@iaehv.nl (EMX Mailing list) Date: Wed, 18 Nov 1998 03:26:12 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 6013 Lines: 173 Short summary: To build on OS/2 is possible, not deadly hard, but hard, and there are many bugs (some patches included). I'm not on lynx-dev mailing list, so try to include me if you reply. (I did not try to build with configure-as-shipped, but applied my fixer to obvious problems in autoconf-generate scripts. Get one from ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/convert_configure.pl ) Successfully compiled (without gettext) with configure.cmd --with-screen=ncurses --enable-persistent-cookies=yes \ --enable-color-style=yes --enable-default-colors=yes \ --enable-gzip-help=yes --enable-externs=yes --enable-gzip-help=yes \ --prefix=f:/emx.add |& tee 00c5 (Edit ./Makefile to comment 'cd po' command, and set INSTALL_* to cp) make CC=gcc HOSTCC=gcc make install make install-help (Fails due to 'mkdir f:', but next time succeeds): make install-help Extended comments: a) Makefile in ./po assumes that ':' is a directory separator; ========================================================= b) Makefile in ./po assumes that msgfmt is present (Possible solution: in the main Makefile disable descending into ./po if msgfmt not present); ========================================================= c) A lot of options in configure --help list unreadable defaults, like DirEd, partial-display etc. It is a double negative problem? I cannot understand why --disable-dired enable optional directory-editor, DirEd (default: on) results in checking if directory-editor code should be used... yes Does it mean (default: enable)? Maybe disable optional directory-editor, DirEd (default: enabled) would be better. ========================================================= d) --disable-extended-dtd (in --help) is not valid at all ========================================================= e) I did not find it stated what are "the most user-friendly" options to Configure. I found the options stated above, do not know where this is good enough. ========================================================= f) A lot of messages like ../cfg_defs.h:212: warning: unknown escape sequence `\U' ========================================================= g) How to set SYSTEM_MAIL=sendmail (it is present on PATH)? ========================================================= h) The patch below enables gunzip on system without hardlinks: --- configure~ Tue Nov 17 06:20:42 1998 +++ configure Tue Nov 17 17:58:44 1998 @@ -4061,6 +4061,9 @@ else test -z "$ac_cv_path_UNCOMPRESS" && ac_cv_path_UNCOMPRESS="$UNCOMPRESS" ;; esac +fi +if test "$ac_cv_path_UNCOMPRESS" = gunzip -a "$GZIP" != "gzip"; then + ac_cv_path_UNCOMPRESS="$GZIP -d" fi UNCOMPRESS="$ac_cv_path_UNCOMPRESS" if test -n "$UNCOMPRESS"; then ========================================================= i) A non-portable construct is used (does not work with pdksh), here is -x trace: + eval 'ac_maketemp="make"' + ac_maketemp="make" configure.cmd: ac_maketemp="make": not found ========================================================= j) HELP_FILE may be written to lynx.cfg without a slash, like HELPFILE:file://localhostf:/emx.add/lib/lynx_help/lynx_help_main.html.gz (note no / between localhost and f:). ========================================================= h) Big compressed help files did not work. There must be better ways to do this, but the following patches fixes things: --- ./WWW/Library/Implementation/HTFile.c~ Tue Nov 10 14:47:38 1998 +++ ./WWW/Library/Implementation/HTFile.c Wed Nov 18 02:25:58 1998 @@ -2204,7 +2204,13 @@ PUBLIC int HTLoadFile ARGS4( */ #endif /* HAVE_READDIR */ { +# ifdef __EMX__ + int len = strlen(localname); + int bin = ((len > 3) && !strcasecomp(localname + len - 3, ".gz")); + FILE * fp = fopen(localname, (bin ? "rb" : "r")); +# else /* !( defined __EMX__ ) */ FILE * fp = fopen(localname, "r"); +# endif CTRACE (tfp, "HTLoadFile: Opening `%s' gives %p\n", localname, (void*)fp); ========================================================= k) In fact compressed files-support requires that the decompression program contains backslashes in its name. Again, the solution below may be not that universal, but it works, and allows lynx coexist with non-Unixish shells: --- ./src/LYUtils.c~ Mon Nov 16 17:59:26 1998 +++ ./src/LYUtils.c Wed Nov 18 02:56:38 1998 @@ -6039,6 +6039,7 @@ PUBLIC int LYSystem ARGS1( char *, command) { int code; + int do_free = 0; fflush(stdout); fflush(stderr); @@ -6051,6 +6052,29 @@ PUBLIC int LYSystem ARGS1( #ifdef VMS code = DCLsystem(command); #else +# ifdef __EMX__ /* XXXX Should be LY_CONVERT_SLASH? */ + /* Configure writes commands which contain direct slashes. + Native command-(non)-shell will not tolerate this. */ + { + char *space = command, *slash = command; + while (*space && *space != ' ' && *space != '\t') + space++; + while (slash < space && *slash != '/') + slash++; + if (slash != space) { + char *old = command; + + command = NULL; + StrAllocCopy(command, old); + do_free = 1; + slash = (slash - old) + command - 1; + space = (space - old) + command; + while (++slash < space) + if (*slash == '/') + *slash = '\\'; + } + } +# endif code = system(command); #endif @@ -6062,6 +6086,8 @@ PUBLIC int LYSystem ARGS1( fflush(stdout); fflush(stderr); + if (do_free) + FREE(command); return code; } ========================================================= l) -use_mouse option works, but USE_MOUSE: TRUE directive in lynx config file does not. ========================================================= m) Mouse supports kinda works, but is very primitive. Mouse does not work in popup-menus (for selection), I get a wrong behaviour if there are two input fields on the same row, and cannot mouse-navigate *inside* an input field. Is it "works as it can", or a problem with EMX port? Ilya From owner-lynx-dev@sig.net Wed Nov 18 11:23:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA26023 for ; Wed, 18 Nov 1998 11:23:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14937; Wed, 18 Nov 1998 10:01:21 -0600 (CST) To: lynx-dev@sig.net References: <19981117175538.A800@psnw.com> Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 18:37:00 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev 2.8.2dev.3 - exiting via interrupt (cosmetic) 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: 839 Lines: 27 > Might want to get rid of extra the leading newlines in the gettext() > string as well... > Might be a few more of these sitting around, too. > diff -cr lynx2.8.2dev.3/src/LYClean.c lynx2.8.2dev.3.bri/src/LYClean.c > *** lynx2.8.2dev.3/src/LYClean.c Tue Nov 10 11:47:38 1998 > --- lynx2.8.2dev.3.bri/src/LYClean.c Tue Nov 17 17:48:16 1998 > *************** > *** 106,112 **** > } > if (sig != 0) { > printf("\n\n%s %d\n\n", > ! gettext("\n\nExiting via interrupt: %d\n\n"), > sig); > fflush(stdout); > } > --- 106,112 ---- > } > if (sig != 0) { > printf("\n\n%s %d\n\n", > ! gettext("\n\nExiting via interrupt: "), ^^^^remove it. > sig); > fflush(stdout); > } From owner-lynx-dev@sig.net Wed Nov 18 11:23:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA26039 for ; Wed, 18 Nov 1998 11:23:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14894; Wed, 18 Nov 1998 10:01:13 -0600 (CST) To: lynx-dev@sig.net References: <9811180643.AA13529@cas.org> Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 18:54:36 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Request for Comment: partial display and refresh 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: 735 Lines: 17 > When I configure lynx to do partial display and to use ncurses 4.2.patched > thru the first week of November, it appears > that at the end of the loading of the file, lynx does a screen refresh. > I am wondering if someone familar with that code could conceive of a I saw this with old 1.99e ncurses in certain situations but no problem with slang (actually another problems). Someone should look curces/slang based code for cleaning up the screen somewhere between/inside HText_pageDisplay(). > way for that code to some how determine whether or not the refresh is > necessary. > In many cases, lynx loads things so quickly that the refresh occurs > almost as fast as the initial load occurs - causing the screen to > 'blink'. From owner-lynx-dev@sig.net Wed Nov 18 11:24:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA26293 for ; Wed, 18 Nov 1998 11:24:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14996; Wed, 18 Nov 1998 10:01:29 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 18:29:19 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev partial display (was: on 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: 2125 Lines: 50 > I am working on changing HText_trimHightext() so that it can deal correctly good! > with being called several times, and will submit a patch. But it occured > to me that there may be a much simper solution to the problems with form > fields: What happens if you just don't do the > highlight(OFF, (nlinks - 1), target); > in display_page() while being in incremental rendering mode? Could you I haven't tried this sort of things because I was not understanding the logic of display_page()/HText_TrimHightext(), there are two kind of hightext etc... Just appears that display_page may be called several times but HText_endAppend only once (it may be ignored in most cases but made a bad thing for forms input). To see the forms input problem: try comment out HText_trimHightext() in HText_pageDisplay(), start lynx with -debug_partial, set MESSGSECS to something about 5 and look any forms page, I usually try new 'O'ptions Menu. The problem from multiple running of HText_trimHightext() leads to overtrimming currently selected hightext link in hightext for normal pages, try accessing lynx-dev month index at www.flora.org with removed detected_forms_input_partial check in HText_pageDisplay(). Well, it was an empiric but more-or-less works (proper changes wellcome!). > please try that? (You know best which flags to check for determine All necessary flags used in HText_pageDisplay(), they are display_partial (TRUE for getfile cycle but became FALSE when we about finish the case NORMAL of mainloop) and detected_forms_input_partial, you know what this means. You may probably want to know when HText_pageDisplay called the very first time, it is NumOfLines_partial == 0 but you should swap two commands in HTFormat.c/HTDisplayPartial() first. > whether the function is called during partial display.) Then calling > HText_trimHightext() may not be necessary at all. > You may also want to break out of the two major loops in display_page() > when text->last_line has been reached, because that is the line still > being filled (only during partial display). > Klaus From owner-lynx-dev@sig.net Wed Nov 18 11:47:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA28052 for ; Wed, 18 Nov 1998 11:46:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA23295; Wed, 18 Nov 1998 10:26:05 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 19:23:31 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too 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: 299 Lines: 7 18-Nov-98 05:11 Klaus Weide wrote: > You can't have the title unless lynx already has already seen it recently. > (In the same session. Unless someone adds a "permanent history list".) ^^^^^^^^^^^^^^^^^^^^^^ No, "permanent Visited Links" instead. From owner-lynx-dev@sig.net Wed Nov 18 12:19:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA30419 for ; Wed, 18 Nov 1998 12:19:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02603; Wed, 18 Nov 1998 10:53:57 -0600 (CST) Date: Wed, 18 Nov 1998 08:56:03 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1811 Lines: 40 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > > As things are presently: > > > Two sessions, A and B are running. Both load the same set of cookies > > from COOKIE_FILE. > > > Session A gets a new cookie from some site, then exits, writing all > > the original cookies and the new cookie to COOKIE_FILE. > > > Session B quits, overwriting COOKIE_FILE with all the original > > cookies, but blowing away the new cookie that session A received. > > > So here's my thought -- prior to writing cookies in memory to COOKIE_FILE, > > Lynx should *reread* COOKIE_FILE, ignoring any cookies that are already in > > memory, but adding cookies from the file that are not in memory. > > > The only thing coming to mind so far that could be a problem here would be > > getting two cookies with the same 'name' attribute from a server in two > > different sessions (two unique identifiers from advertising sites?), in > > which case the one which is written to COOKIE_FILE first (thus read into > > memory in the other Lynx session, overwriting the existing one) will be > > maintained, and the others dropped. > > Remote server may change cookie expiration date, > which date should be correct from session A or from session B? With the way I have things up there, whichever copy of Lynx is exited first will be the session with the cookie that is saved. So it's pretty much an even shot either way. I don't like this, and can't really think of a way to do handle this without (for example) timestamping individual cookies (possibly with comments in the cookie file?). The more I think about it, the more appealing a directory to store cookies sounds. -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Wed Nov 18 12:34:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA31953 for ; Wed, 18 Nov 1998 12:34:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA08252; Wed, 18 Nov 1998 11:11:09 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 19:57:47 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Request for Comment: partial display and refresh 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: 433 Lines: 11 18-Nov-98 08:56 Klaus Weide wrote: > The second call to display_page() could be skipped if and only if the > following is true: when display_page() was called before, during > incremental rendering, it was called for the same range of lines and > HText_trimHightext() had been done. Probably no, "currently selected link" became highlited and available only when the complete loading done, unless you fix something around this. From owner-lynx-dev@sig.net Wed Nov 18 12:38:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA32106 for ; Wed, 18 Nov 1998 12:38:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA08283; Wed, 18 Nov 1998 11:11:17 -0600 (CST) To: lynx-dev@sig.net References: <199811181319.PAA17851@ozone.fmi.fi> Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 19:51:52 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev gettext() question #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: 1276 Lines: 37 >> There is another problem possible: >> gettext() support based on language, not character set (usually iso-8859-1). >> Lynx support a list of character sets, so a person using cpXXX display >> will be confused... Display charset generally independent from LOCALE, >> assuming a person start lynx from the remote terminal. > $LANG includes implicity character set, because it specifies > also LC_CTYPE locale. not always, but should to. > So if user is using some remote terminal, he needs adjust > $LANG also to get other programs (than lynx) to work correctly. > Some systems there is several possible $LANG values for same > language (which just differ by used caharacter-set). For example: > en_US > en_US.ISO8859-1 > It may make do sense to map $LANG (or result of setlocale(LC_CTYPE,NULL) > actually) to character set with some (OS dependent) mapping table. probably Yes. It was proposed just before the releasing 2.8, concerning case-insensitive search, but nobody have contributed the mapping table (we find another workaround). I personaly use PC (cp866 for display charset) and the remote terminal running lynx have LOCALE at "ru_RU.KOI8-R" what should lynx do here? Probably set language support only if locale match display charset? > / Kari Hurtta From owner-lynx-dev@sig.net Wed Nov 18 13:01:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA01260 for ; Wed, 18 Nov 1998 13:01:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA17638; Wed, 18 Nov 1998 11:39:40 -0600 (CST) From: dickey@clark.net Message-Id: <199811181741.MAA05838@shell.clark.net> Subject: Re: lynx-dev re: why have --datadir=DIR if you can't use it? To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 12:41:55 -0500 (EST) In-Reply-To: <199811181505.KAA07113@mail.bcpl.net> from "Webmaster Jim" " at Nov 18, 98 10:05:21 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: 1253 Lines: 29 > > > * Subject: lynx-dev why have --datadir=DIR if you can't use it? > > * From: Nelson Henry Eric > > * Date: Wed, 18 Nov 1998 17:21:42 +0900 (JST) > >Pretty please?! (for the third time): > > > > ## Where your locale data is > >! # datadir = @datadir@ > >! datadir = /usr/local/share > >! localedir = $(datadir)/locale > > For the record, I left this as a fixed value because I was unable to > figure out how to pass a configure value from the top-level down to > the correct place. Believe me, I tried. Perhaps now that others have > seen the code they can suggest how this value can be configured and > over-ridden. Apparently it works in the reference "hello" program but > that has a different top-level configure script and makefile. I modified that so that it uses the values that the chunk of autoconf script which comes with gettext uses - that's done in src/makefile.in Henry's change to ./makefile.in has no effect since the parameter is not carried down to src - and it's not really good to do that with makefile assignments since there's so many things it could be done for & will rapidly become unusable. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 13:06:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA01675 for ; Wed, 18 Nov 1998 13:06:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA16252; Wed, 18 Nov 1998 11:34:51 -0600 (CST) From: dickey@clark.net Message-Id: <199811181737.MAA04970@shell.clark.net> Subject: Re: http://www.flora.org/lynx-dev/html/month1198/msg00454.html To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 12:37:01 -0500 (EST) In-Reply-To: <199811181456.JAA05402@mail.bcpl.net> from "Webmaster Jim" " at Nov 18, 98 09:56: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: 1363 Lines: 26 > >right. At some point (after Thanksgiving) I'll work on moving some of the > >repeated strings into LYMessages_en.h (besides the maintenance issues, > >reducing the number of files with strings may make this work with Solaris' > >gettext - that's one of the problems). > > I was working hard to remove the "en" file beacuse I thought > it conflicted with the operation of gettext, in that identical > messages map to a single catalog entry, and therefore to > a single translation (per language). Using macros may save some space in > the source code, but I felt it was more useful to see the full messages > in context of the code when doing translation work. I understood that - but I wrote a script to workaround (the xgettext utility is reluctant to read preprocessor statements). xgettext also does not like long command lines, and though the manpage says, it does not (on the systems I tried ;-) accept a list of filenames from stdin. I tried using the GNU xgettext with the solaris gettext function, but that doesn't work. When I look at this again, I'll see if it looks practical to move enough strings into LYMessages_en.h so that the command line will fit in Solaris' xgettext limits. If that works out, we may be able to build against either version of gettext. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 14:07:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA06375 for ; Wed, 18 Nov 1998 14:07:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA07230; Wed, 18 Nov 1998 12:46:42 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 21:34:09 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 581 Lines: 16 >> ^R of course. sorry. > You know about ^R, and so do I and probably most readers of this list. > Most lynx users may not know about it. The point is that any change > or addition to caching shouldn't increase the chance that a more naÑve > lynx user gets a "stale" version of a document. No chance for wrong version when doing as I was describing: there are two different cases "HTTP request" and "history" (I mean this "history for sure" or "for unternal use" e.g. for *, [, etc.) "HTTP request" cacheing may be switched to "lazy" style until we sure enough. > Klaus From owner-lynx-dev@sig.net Wed Nov 18 14:12:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA06810 for ; Wed, 18 Nov 1998 14:12:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA07869; Wed, 18 Nov 1998 12:48:52 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 21:46:43 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev partial display (was: on 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: 941 Lines: 21 > But if a client sends a request line with "HTTP/1.1", then the servers > is entitled to assume that the client > - wants persistent connections (unless "Connection: close" is sent) One problem in partial display mode remind me this. while accesing certain rare sites with lynx I got repainting the screen on _previous_ document, not the downloading one, so I analize the trace and add a semaphore against HText_new(). The only side information on that problemical sites - they are not Apache and are not sending "Connection: close" (and lynx send HTTP/1.0 as usual). > - understands "Transfer-Encoding: chunked" > - understands intermediate responses like "100 Continue" (probably; > not sure whether something has changed there) > So there are no good reasons to pretend we are fully implementing HTTP 1.1, > and there are good reasons not to do so. (Except in your own private > copy of lynx, to see what would go wrong...) From owner-lynx-dev@sig.net Wed Nov 18 14:12:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA06833 for ; Wed, 18 Nov 1998 14:12:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA07782; Wed, 18 Nov 1998 12:48:36 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 21:04:52 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 922 Lines: 21 >> Remote server may change cookie expiration date, >> which date should be correct from session A or from session B? > With the way I have things up there, whichever copy of Lynx is exited first > will be the session with the cookie that is saved. But the second session may even be not looking for this host while the first change cookie. > So it's pretty much an even shot either way. I don't like this, and can't > really think of a way to do handle this without (for example) timestamping > individual cookies (possibly with comments in the cookie file?). Why not to save cookies file every time we change cookie info and create something to emulate VMS version number, probably lock file, to re-read cookies when changed? Too much disk activities? > The more I think about it, the more appealing a directory to store cookies > sounds. this is unrelated subject, time-stamp or equivalent will still necessary. From owner-lynx-dev@sig.net Wed Nov 18 14:49:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA09674 for ; Wed, 18 Nov 1998 14:49:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA18420; Wed, 18 Nov 1998 13:23:27 -0600 (CST) Date: Wed, 18 Nov 1998 11:25:38 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1129 Lines: 29 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > >> Remote server may change cookie expiration date, > >> which date should be correct from session A or from session B? > > > With the way I have things up there, whichever copy of Lynx is exited first > > will be the session with the cookie that is saved. > > But the second session may even be not looking for this host > while the first change cookie. Hmm, true. I don't know. > > So it's pretty much an even shot either way. I don't like this, and can't > > really think of a way to do handle this without (for example) timestamping > > individual cookies (possibly with comments in the cookie file?). > > Why not to save cookies file every time we change cookie info > and create something to emulate VMS version number, probably lock file, > to re-read cookies when changed? Too much disk activities? I think that was discussed, but I don't recall what the reasoning against it was. -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 what have you contributed to open source today? From owner-lynx-dev@sig.net Wed Nov 18 15:11:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA11667 for ; Wed, 18 Nov 1998 15:11:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA25692; Wed, 18 Nov 1998 13:47:03 -0600 (CST) From: dickey@clark.net Message-Id: <199811181949.OAA04935@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.4 To: lynx-dev@sig.net (Lynx Development) Date: Wed, 18 Nov 1998 14:49:16 -0500 (EST) 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: 2876 Lines: 48 Except for Klaus' patch from Saturday, I think this is all of the submitted patches that I had in my queue. (I'm sure there's some that I missed). 1998-11-18 (2.8.2dev.4) * change default for configure option of NLS (gettext) to disabled until we finish porting it to implementations other than GNU gettext. Also, change default for include-gettext configure option to "with" - TD * suppress cookie-storing if the value is null - BJP * ifdef'd alternative set of line-edit bindings with EXP_ALT_BINDINGS, add configure option --enable-alt-bindings, rename DELEOL to DELEL, remove binding of DELEL to '\'. - TD * add alternative set of line-edit bindings to change the behavior of the ^B and ^F line editor bindings to provide emacs/tcsh like behavior (cursor left/right), instead of "word" deletes. Corrected a bug in the ^R (LYE_DELN) function, which is described as "delete next character", but was in fact performing identically to ^D (LYE_DELC) "delete current character". Added a function called LYE_DELEL, which does the expected thing, and deletes from the current cursor position, to the EOL. New bindings: ^B = LYE_BACK cursor backwards ^F = LYE_FORW cursor forwards ^K = LYE_DELEOL delete to end-of-line ^T = LYE_DELNW delete next word ^X = LYE_DELPW delete previous word ^^ = LYE_UPPER upper case line (not active when kbd-layout binding is) ^_ = LYE_LOWER lower case line (Kim DeVaughn ). * modify to show address to submit to on the statusline when in advanced user mode. Also fixes one small typo in LYMainLoop.c. (suggested by ) - BJP * modify HTParseInet() so that it works if stdin has been redirected to /dev/null, e.g., when running a cron job (reported by John H. DuBois III ) - BL * minor documentation updates to lynx.cfg (Larry Virden). * change some character constants from '\hex' and '\octal' form to decimal, to pursuade compilers that upper-128 compares are legal - TD * ifdef'd KEYBOARD_LAYOUT with EXP_KEYBOARD_LAYOUT, add configure option --enable-kbd-layout. Note that control/Y is used as a process suspend character on some platforms (VMS and Solaris) - TD * implement EXP_CHARTRANS_AUTOSWITCH for OS/2 EMX (Sergey Svishchev). * add 'a' response when printing a file to allow append rather than overwrite (Sergey Svishchev). * add KEYBOARD_LAYOUT to lynx.cfg, to support character-translation on input, add missing line editing style selection to Options form. This is enabled and disabled by the line edit control/Y (Sergey Svishchev ). * use exit_immediately() to reduce some signal-function clutter - LP * correct dependency in src/makefile.in for cfg_defs.h (Masashi Fujita ) * change quoted includes in intl directory to bracketed includes - TD From owner-lynx-dev@sig.net Wed Nov 18 16:12:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA16698 for ; Wed, 18 Nov 1998 16:12:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA14231; Wed, 18 Nov 1998 14:47:54 -0600 (CST) Date: Wed, 18 Nov 1998 14:49:59 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Request for Comment: partial display and refresh 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: 602 Lines: 16 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > 18-Nov-98 08:56 Klaus Weide wrote: > > > The second call to display_page() could be skipped if and only if the > > following is true: when display_page() was called before, during > > incremental rendering, it was called for the same range of lines and > > HText_trimHightext() had been done. > > Probably no, "currently selected link" became highlited and available > only when the complete loading done, unless you fix something around this. But that isn't done by display_page() at all, it is done by a call to highlight(ON) in mainloop(). Klaus From owner-lynx-dev@sig.net Wed Nov 18 16:14:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA16802 for ; Wed, 18 Nov 1998 16:14:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA15264; Wed, 18 Nov 1998 14:51:24 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 18 Nov 1998 23:48:04 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 5912 Lines: 119 18-Nov-98 08:14 Klaus Weide wrote: That is exactly what I mean in another words (much clear here). but see near the bottom. > Let's image a scale of possible behavior (although that cannot really all > be expressed in one dimension): > complete use all > semantic <----------------------------------|-------> cached data > transparency | forever > Lynx in general > Complete transparency means: whenever a link is followed, a new request > is made. The other end of the scale would be: ignore all > "no-cache", "expires" etc. directives, keep documents around as long as > they fit in the cache, and never re-request what we already have. > No client implements either extreme (by default). > Lynx is currently closer to the right; it is not completeley there > because it honors no-cache in responses and (some forms of) Expires, > and resubmits POST and HEAD requests. > There are several "modes" of going to a page: > 1) explicit reload: ^R, 'x' > 2) '*', '\', '[', '"', ^V, etc. > 3) form submissions (POST) > 4) following a normal link, entering an address with 'g' etc.; default > 5) going back in history: either left arrow, or link from History Page > I have ordered them according to the scale above, 1) corresponds to > the left end, 5) to the right end. > I would argue that any change or addition of caching mechanisms should > not move Lynx much to the left or to the right, for any of the modes, > _by default_ -- except for 2), see below. > I don't want a lynx session to act much more semantically transparent > by default (I have a slow link, too), especially for 4), although it would > be more correct to do so (it should follow the rules HTTP sets for caches > more closely). But it would be nice to be able to configure Lynx to > act more semantically transparent. > I also don't want Lynx to act (much) more relaxed by default. But it > would be nice to be able to configure Lynx to do even less checking. > (For example, never honor Expires, or ignore it in META tags.) > Mode 2 is different, because it is close to the left by accident and > not by design: we would like it to behave like 5 but cannot since we > throw away the raw bytes. So now someone wants to implement a cache > for raw bytes of HTML documents to achieve that. Apart from the > implementation, the major question is: how should this change the behavior > in other modes. > If the answer is: It shouldn't, by default -- then the minimal solution > is simple: just use the new rawdata cache for what it was intended, > that is only mode 2 requests. It is very tempting to reuse the rawdata > for mode 5 requests -- it seems such a waste not to do it -- but we don't > have to do it. > If the new rawbyte cache never gets used for requests other than mode 2, > then no change is needed in the rules for when to make a new request, > and no If-Modified-Since/Etag implementation is needed to preserve the > current behavior. IMS/Etag/304 could still be implemented later, but > that is then a separate problem. (It could also already be implemented > already now, for the existing rendered-doc cache, [except for the > "language confusion" problem,] which shows that it is separate.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^?? > But it DOES seem wasteful to keep raw data if in most cases we won't > use them. But: > A. The impementation doesn't have to be complicated if > - We never keep the cached raw data around for longer than we > keep the rendered text, with one exception: during a mode 2 > request when the data is reparsed. > - We keep cached raw data in memory (not files). We could > simply put each bufferful of data into a HTChunk while it is being > received. > - There is no new expiration, validation, or timestamp comparison > logic, so no new metadata needs to be stored. > B. It can be greatly restricted what documents get entered into the > cache in the first place. We have a choice of > - Caching everything received. > - Caching all text/html, maybe with further restrictions based > on URL, method, etc. also restrictions on file://localhost which always available > - Require explicit user action. Maybe a special "Enter cache" key, > meaning "I am going to want this text reparsed, so start caching > it". ??? > - When '\' is pressed the first time for the current text, we mark > if for rawbyte caching. There could be a confirmation question. > That means at least two network request are needed, but after that > cached data is used. ??? > When we go to view a document in other than mode 2, the cached > data can be thrown away. Or alternatively, whenever there is a new > network request. > Note that this could be done without significant changes in mainloop(). > It just would have to set a "this is a mode 2 request" flag, > HTuncache_current_document() might have to take care to preserve > existing raw data in this case (and maybe get rid of it otherwise), > Then other lower-level functions could handle the storing to cache > and reading from it. The mainloop() function wouldn't have to know > where the new data comes from. exactly. But I think "mode 2" need no confirmation in any case: every text/plain _rendered_ document should be cached in rawdata if it currently cached in rendered form, otherwise fall back to the present behaviour (no rawdata cacheing at all). Of cause, rawdata cache may be larger than rendered cache. When we mean modes other than "mode 2" we can easily get more relaxed behaviour it we want it (configurable, of cause), but getting more strict require changing of present code (LYoverride_no_cache etc.) - it is a separate problem. From owner-lynx-dev@sig.net Wed Nov 18 16:48:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA19638 for ; Wed, 18 Nov 1998 16:48:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA25347; Wed, 18 Nov 1998 15:24:34 -0600 (CST) Date: Wed, 18 Nov 1998 15:26:45 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev partial display (was: on 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: 1953 Lines: 47 On Wed, 18 Nov 1998, Leonid Pauzner wrote: [KW:] > > But if a client sends a request line with "HTTP/1.1", then the servers > > is entitled to assume that the client > > - wants persistent connections (unless "Connection: close" is sent) > > One problem in partial display mode remind me this. > while accesing certain rare sites with lynx > I got repainting the screen on _previous_ document, not the downloading one, > so I analize the trace and add a semaphore against HText_new(). I don't understand why you think it could have something to do with something at the HTTP protocol level. Lynx doesn't do persistent HTTP connections anyway. :) Maybe it has something to do with how the response we receive is packaged into packets. Often servers ship off the data in such a way that the message headers are in one network packet, and then it is likely that the first call to HTCopy() from HTLoadHTTP() starts with the first bytes of the message body (because the first read() from the network socket has delivered just the headers). The call /* ** Recycle the first chunk of data, in all cases. */ (*target->isa->put_block)(target, start_of_data, length); before the HTCopy() in HTTP.c will have shipped just the headers to the MIME parser. So when HTDisplayPartial() gets first called from HTCopy(), there will already have been a block of body data shipped to the SGML and HTML parsers. Then it is likely that the new HText structure has been created at that point. If on the other hand not all message headers fit in one network packet (or datagram, to be more exact), or if for some other reason the read() in HTLoadHTTP() hasn't yet read all header data, then the first call to HTCopy() may still be passing just header fields to the MIME parser, so that when HTDisplayPartial() is first called, no part of the body has been seen and a new HText structure has not yet been created. Does this make sense? Klaus From owner-lynx-dev@sig.net Wed Nov 18 17:23:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA22528 for ; Wed, 18 Nov 1998 17:23:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA04548; Wed, 18 Nov 1998 15:55:06 -0600 (CST) From: dickey@clark.net Message-Id: <199811182157.QAA02850@shell.clark.net> Subject: Re: lynx-dev Request for Comment: partial display and refresh To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 16:57:15 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 18, 98 02: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: 941 Lines: 27 > > On Wed, 18 Nov 1998, Leonid Pauzner wrote: > > > 18-Nov-98 08:56 Klaus Weide wrote: > > > > > The second call to display_page() could be skipped if and only if the > > > following is true: when display_page() was called before, during > > > incremental rendering, it was called for the same range of lines and > > > HText_trimHightext() had been done. > > > > Probably no, "currently selected link" became highlited and available > > only when the complete loading done, unless you fix something around this. > > But that isn't done by display_page() at all, it is done by a call to > highlight(ON) in mainloop(). bottom line is that someone will have to take the time to trace it and see where the code's causing a refresh (if I could make a scenario on local testing, I'd have done it by now -- but online testing is very slow). > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 17:30:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA23190 for ; Wed, 18 Nov 1998 17:30:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA08422; Wed, 18 Nov 1998 16:07:00 -0600 (CST) From: dickey@clark.net Message-Id: <199811182209.RAA05856@shell.clark.net> Subject: Re: lynx-dev partial display (was: on caching) To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 17:09:16 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 18, 98 03:26:45 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: 650 Lines: 17 > If on the other hand not all message headers fit in one network packet > (or datagram, to be more exact), or if for some other reason the read() > in HTLoadHTTP() hasn't yet read all header data, then the first call > to HTCopy() may still be passing just header fields to the MIME parser, > so that when HTDisplayPartial() is first called, no part of the body > has been seen and a new HText structure has not yet been created. > > Does this make sense? some - but when I saw the blinking it was pretty repeatable. This sounds rather time-dependent. > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 17:56:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA24799 for ; Wed, 18 Nov 1998 17:56:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA17718; Wed, 18 Nov 1998 16:31:18 -0600 (CST) To: lynx-dev@sig.net References: <199811181949.OAA04935@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 19 Nov 1998 01:27:45 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.4 - core dump 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: 504 Lines: 17 dev.4 build with DGJPP core dumps immediately just on startup, the last line was found in the trace file: Node `file://localhost/c:/lynx/dist28' means path `/c:/lynx/dist28' HTDOS_name changed `/c:/lynx/dist28' to `c:\lynx\dist28' c:\lynx\dist28 is a directory HTParse: aName:file://localhost/c:/lynx/dist28 relatedName: 1 HTParse: result:/c:/lynx/dist28 HTParse: aName:file://localhost/c:/lynx/dist28 relatedName: 1 HTParse: result:/c:/lynx/dist28 UCSetTransParams: from ^^^^^^^^^^^^^^^^^^^^^^ From owner-lynx-dev@sig.net Wed Nov 18 17:58:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA25043 for ; Wed, 18 Nov 1998 17:58:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA18438; Wed, 18 Nov 1998 16:33:08 -0600 (CST) Date: Wed, 18 Nov 1998 17:34:29 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811181734.AA17250@cas.org> Subject: lynx-dev minor typo patch for lynx.cfg in lynx 2.8.2dev.4 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3089 Lines: 55 --- lynx.cfg-dist Wed Nov 18 14:23:55 1998 +++ lynx.cfg-new Wed Nov 18 17:33:46 1998 @@ -10,3 +10,3 @@ # the default location of this file in the userdefs.h file and recompile, -# or specify it's location on the command line with the "-cfg" +# or specify its location on the command line with the "-cfg" # command line option. @@ -32,3 +32,3 @@ #INCLUDE:/usr/local/lib/lynx.cfg -# ^^^^^^^^^^^^^^^^^^^^^^^ or whatever's appropriate on your system +# ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system #and now your own tweaks. @@ -88,3 +88,3 @@ # or use '?' for a list of the shortcuts with associated links to -# their actual URL's. See the jumps files in the lynx*/samples +# their actual URLs. See the jumps files in the lynx*/samples # subdirectory. Make sure your jumps file includes a '?' shortcut @@ -264,2 +264,3 @@ # Lynx (case insensitive). +# Find RFC 1345 at http://www.ics.uci.edu/pub/ietf/uri/rfc1345.txt . # @@ -366,3 +367,4 @@ # an error response with the 406 (not acceptable) status code, though -# the sending of an unacceptable response is also allowed. See RFC2068. +# the sending of an unacceptable response is also allowed. See RFC 2068 +# (http://www.ics.uci.edu/pub/ietf/uri/rfc2068.txt). # @@ -501,4 +503,4 @@ # -# The Unix and VMS (but not VAXC) implementations use the C library malloc's -# and calloc's for memory allocation, but procedures for taking the actual +# The Unix and VMS (but not VAXC) implementations use the C library mallocs +# and callocs for memory allocation, but procedures for taking the actual # amount of cache into account still need to be developed. They use only @@ -592,5 +594,5 @@ # or lynxprog command will be permitted if it was referenced with a URL -# beginning with that string. If you wish to restrict the referencing URL's +# beginning with that string. If you wish to restrict the referencing URLs # further, you can extend the string to include a trusted path. You also can -# specify a trusted directory for http URL's, which will then be treated as +# specify a trusted directory for http URLs, which will then be treated as # if they were local rather than remote. For example: @@ -619,6 +621,6 @@ # If EXEC_LINKS and JUMPFILE have been defined, any lynxexec or lynxprog -# URL's in that file will be permitted, regardless of other settings. If +# URLs in that file will be permitted, regardless of other settings. If # you also set LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE:TRUE and a single # TRUSTED_EXEC rule that will always fail (e.g., "none"), then *ONLY* the -# lynxexec or lynxprog URL's in JUMPFILE (and any ALWAYS_TRUSTED_EXEC rules, +# lynxexec or lynxprog URLs in JUMPFILE (and any ALWAYS_TRUSTED_EXEC rules, # see below) will be allowed. Note, however, that if Lynx was compiled with -- 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 Nov 18 18:05:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA25470 for ; Wed, 18 Nov 1998 18:05:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA19353; Wed, 18 Nov 1998 16:35:20 -0600 (CST) Date: Wed, 18 Nov 1998 17:36:51 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811181736.AA17286@cas.org> Subject: lynx-dev minor typo/grammer changes to userdefs.h To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1606 Lines: 33 --- userdefs.h-dist Wed Nov 18 14:23:55 1998 +++ userdefs.h-new Wed Nov 18 16:55:47 1998 @@ -94,3 +94,3 @@ /************************** - * The EXTENSION_MAP file allows you to map file suffix's to + * The EXTENSION_MAP file allows you to map file suffixs to * mime types. @@ -277,3 +277,3 @@ /************************** - * The EXTENSION_MAP file allows you to map file suffix's to + * The EXTENSION_MAP file allows you to map file suffixs to * mime types. @@ -332,3 +332,3 @@ /************************** - * A place to put temporary files, it's almost always in "/tmp/" + * A place to put temporary files, it is almost always in "/tmp/" * for UNIX systems. If you include "$USER" in the definition @@ -569,4 +569,4 @@ * -* The Unix and VMS but not VAXC implementations use the C library malloc's -* and calloc's for memory allocation, and procedures for taking the actual +* The Unix and VMS but not VAXC implementations use the C library mallocs +* and callocs for memory allocation, and procedures for taking the actual * amount of cache into account still need to be developed. They use only @@ -1134,3 +1134,3 @@ * - * If it's FALSE at startup of Lynx, the user can regulate it via the + * If it is FALSE at startup of Lynx, the user can regulate it via the * 'o'ptions menu, and may save the preference in the RC file. -- 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 Nov 18 18:13:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA26091 for ; Wed, 18 Nov 1998 18:13:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA25168; Wed, 18 Nov 1998 16:50:24 -0600 (CST) Date: Wed, 18 Nov 1998 17:52:08 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811181752.AA19642@cas.org> Subject: lynx-dev bug in recent lynx 2.8.2dev releases To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1704 Lines: 43 When I go to a link to a binary file, and press return (causing lynx to attempt to load the page as HTML), lynx determines it is binary and tries to ask me if I want to download the file. This code was broken recently - I just don't know when. I go to . I move down to one of the .bz2 links and press return. I am seeing this at the bottom of the screen. 10875 Sep 26 21:34 [43]2.8.1pre.3.patch.gz 21626 Sep 25 04:46 [44]2.8.1pre.2.patch.gz s D)ownload, or C)ancel Notice the s? I think it is supposed to say something... Here's my config info. SPARC Solaris 2.6,Sun cc 4.2, ncurses 4.2 patched thru the first week of November and these compile flags. export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz -L/projects/gnu/sparc-sun-solaris2.6/lib -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " export CPPFLAGS="-I/ldatae/include -I/projects/gnu/sparc-sun-solaris2.6/include" export CFLAGS="-g" export CC=cc $PWD/configure --prefix=/projects/intranet \ --libdir=/projects/intranet/lib/lynx \ --includedir=/projects/gnu/sparc-sun-solaris2.6/include \ --with-screen=ncurses \ --with-included-gettext \ --with-catgets \ --with-zlib \ --enable-default-colors \ --enable-extended-dtd \ --enable-externs \ --enable-forms-options \ --enable-nsl-fork \ --enable-partial \ --enable-persistent-cookies \ --enable-debug I don't know whether GNU's gettext or Sun's is being used. -- 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 Nov 18 18:38:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA27955 for ; Wed, 18 Nov 1998 18:38:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01420; Wed, 18 Nov 1998 17:06:08 -0600 (CST) To: lynx-dev@sig.net References: <199811181949.OAA04935@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Thu, 19 Nov 1998 02:03:07 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.4 - core dump 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: 135 Lines: 5 > dev.4 build with DGJPP core dumps immediately just on startup, it was a dependency problem, `make clean' solve everything, sorry. From owner-lynx-dev@sig.net Wed Nov 18 18:48:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA28715 for ; Wed, 18 Nov 1998 18:48:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA04623; Wed, 18 Nov 1998 17:15:00 -0600 (CST) Date: Wed, 18 Nov 1998 15:11:14 -0800 (PST) From: David Combs Message-Id: <199811182311.PAA12477@netcom4.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2466 Lines: 65 > From owner-lynx-dev@sig.net Wed Nov 18 03:12:48 1998 > Date: Wed, 18 Nov 1998 05:11:28 -0600 (CST) > From: Klaus Weide > > Ok, it wasn't clear to me before what you wanted. So you want something > that looks like the history page? > > > I'm saying that an option to have BOTH would be a real win. > > You can't have the title unless lynx already has already seen it recently. > (In the same session. Unless someone adds a "permanent history list".) > So some entries could have tho lines, and others one line. > > > QUESTION: does ANYONE ELSE think they'd find this useful? > > Personally, I don't. :) > I just haven't missed it. And it means that less links fit on one page. > So I won't make a patch for it. But if you can convince someone else, > it shouldn't be too difficult to change LYList.c to do what you want > (since the function calls to get the title and addres are already there). > No, not so like the history page: addr on the left, and on the SAME line, the title, out to the right. to either wrap or truncate on a narrow screen. Why: We have all the TITLES, in plain text, even highlighted, on the main page. So those while important, are less important. It is the ADDRESSES that we do NOT have, in plain text, on the displayed html page. Sure, in advanced mode we can see the ONE address the cursor happens to be "at", but there is NO way, other than the L page, to see a PATTERN of addresses, eg 80% from www.foo.edu -- other than to Print the page, suck it into vi, search for /^References:/, and see them there. I myself find the L page INVALUABLE, as a way to tell me "about" the links from the current page. All I want is two things: 1) the addr at the left (not the title, as sometimes appears not INSTEAD of the addr, with no clue as to what the addr is) 2) AND the title too, appended out to the right. Perhaps there could be a .cfg-option that says "maximum screen-width for printing the L-page title on a second line indented under the address -- wider than that, and it gets appended, ie whole thing takes only ONE (wide) line", Which klaus would set to eg 80, and those of us who want it to NEVER take a 2nd line would use 9000 or something, making it ALWAYS append the title, regardless of how wide the whole thing got. I am surprised no one finds this L-page feature (title appended somehow) useful. Maybe no one but me even uses the L page? David From owner-lynx-dev@sig.net Wed Nov 18 19:32:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA31894 for ; Wed, 18 Nov 1998 19:32:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA23382; Wed, 18 Nov 1998 18:11:26 -0600 (CST) Date: Thu, 19 Nov 1998 09:15:07 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190015.JAA16217@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: http://www.flora.org/lynx-dev/html/month1198/msg00454.html Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 998 Lines: 20 > the source code, but I felt it was more useful to see the full > messages in context of the code when doing translation work. That's the way I looked at it at first, too. However, having gotten a bit of a "feel" for the idea, I think the philosophy reflected in the gettext documentation of distinguishing between programmer, non- programmer translator, installer/maintainer and user is very practical. "An ounce of prevention is worth a pound of cure" will really apply here. Most translators will not be able to read c and definitely should not be required to do so. The programmer will have to be sure that the translator can not introduce bugs. Gettext goes out of its way to help the programmer do this, and arguably if a translator can introduce a bug into the program, then actually that is a bug in gettext itself. > (I'm back, too.) Excellent! Thanks, Jim, for strong-arming the team. For me, gettext is the biggest thing to happen to Lynx since the Win32/DOS porting. __Henry From owner-lynx-dev@sig.net Wed Nov 18 19:37:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA31981 for ; Wed, 18 Nov 1998 19:37:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA25177; Wed, 18 Nov 1998 18:17:24 -0600 (CST) Date: Thu, 19 Nov 1998 09:21:03 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190021.JAA16254@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev re: why have --datadir=DIR if you can't use it? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 313 Lines: 7 > For the record, I left this as a fixed value because I was unable to I knew that. Since I can fix it by patching the makefile.in's, it's no big deal. I'm just trying to get Tom to give me a slice of his turkey. Sort of like begging for scraps at the table. (No Thanksgiving Day over here in Japan.) __Henry From owner-lynx-dev@sig.net Wed Nov 18 19:54:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA00586 for ; Wed, 18 Nov 1998 19:54:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA00272; Wed, 18 Nov 1998 18:34:07 -0600 (CST) Date: Thu, 19 Nov 1998 09:37:47 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190037.JAA16356@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question #2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 770 Lines: 18 > So if user is using some remote terminal, he needs adjust > $LANG also to get other programs (than lynx) to work correctly. These kinds of questions are going to start POURING into lynxdev. They are all answered in the gettext documentation. Use LANG system-wide; use LANGUAGE for your GNU NLS programs. You are at the mercy of the provider if you do not have shell access, but a _decent_ provider would at least give you a choice. In some countries, (e.g., Canada?) it may even become law that a choice is given. > Some systems there is several possible $LANG values for same > language (which just differ by used caharacter-set). For example: So set it to whichever one you want. (Why and how you can do this is answered in the gettext documentation.) __Henry From owner-lynx-dev@sig.net Wed Nov 18 21:13:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA06180 for ; Wed, 18 Nov 1998 21:13:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA25514; Wed, 18 Nov 1998 19:55:11 -0600 (CST) Date: Thu, 19 Nov 1998 10:58:44 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190158.KAA19344@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev include directories dropped: dev.4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 705 Lines: 14 got the following error on SunOS4.1.3: gcc -DHAVE_CONFIG_H -I/home/nelsonhe/.usr/include -DLOCALEDIR=\"/home/ nelsonhe/.usr/share/locale\" -I. -I.. -Ichrtrans -I./chrtrans -I.. -I.. /intl -I../src -I../WWW/Library/Implementation -O2 -DSUN -DSUN4 -c ./LYHash. c gcc -O2 -DSUN -DSUN4 -I/home/nelsonhe/.usr/include -target sun4 -o chrtra ns/makeuctb chrtrans/makeuctb.c chrtrans/makeuctb.c:20: HTUtils.h: No such file or directory chrtrans/makeuctb.c:21: tcp.h: No such file or directory chrtrans/makeuctb.c:33: UCkd.h: No such file or directory chrtrans/makeuctb.c:34: UCDefs.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `chrtrans/makeuctb' __Henry From owner-lynx-dev@sig.net Wed Nov 18 21:16:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA06229 for ; Wed, 18 Nov 1998 21:16:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA26498; Wed, 18 Nov 1998 19:58:02 -0600 (CST) From: dickey@clark.net Message-Id: <199811190200.VAA16577@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.4 - core dump To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 21:00:18 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 19, 98 02:03: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: 296 Lines: 12 > > > dev.4 build with DGJPP core dumps immediately just on startup, > > it was a dependency problem, `make clean' solve everything, > sorry. good (I didn't know of anything that would have caused a new bug like that) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 21:18:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA06260 for ; Wed, 18 Nov 1998 21:18:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA27412; Wed, 18 Nov 1998 20:00:48 -0600 (CST) From: dickey@clark.net Message-Id: <199811190203.VAA17198@shell.clark.net> Subject: Re: lynx-dev bug in recent lynx 2.8.2dev releases To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 21:03:05 -0500 (EST) In-Reply-To: <9811181752.AA19642@cas.org> from "lvirden@cas.org" at Nov 18, 98 05:52: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: 254 Lines: 8 > I don't know whether GNU's gettext or Sun's is being used. --with-included-gettext should be using GNU's gettext. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 21:20:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA06783 for ; Wed, 18 Nov 1998 21:20:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA28068; Wed, 18 Nov 1998 20:02:40 -0600 (CST) From: dickey@clark.net Message-Id: <199811190204.VAA17432@shell.clark.net> Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 21:04:57 -0500 (EST) In-Reply-To: <199811182311.PAA12477@netcom4.netcom.com> from "David Combs " at Nov 18, 98 03:11:14 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: 410 Lines: 14 > I am surprised no one finds this L-page feature > (title appended somehow) useful. Maybe no one but me > even uses the L page? I glance at it occasionally just to see if Lynx finds links on the page. (I looked at one at netscape today, and Lynx seems to be ignoring some of the links - but that's a different story ;-). > David -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 21:22:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA06842 for ; Wed, 18 Nov 1998 21:22:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA28587; Wed, 18 Nov 1998 20:04:17 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811190206.TAA19071@sanitas> Subject: Re: lynx-dev lynx2.8.2dev.3 To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 19:05:59 -0700 (MST) In-Reply-To: <199811162316.SAA04706@shell.clark.net> from "dickey@clark.net" at Nov 16, 98 06:16:09 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: 691 Lines: 18 In a recent note, dickey@clark.net said: > Date: Mon, 16 Nov 1998 18:16:09 -0500 (EST) > > * add preliminary changes from: pg@sweng.stortek.com to support port to OS/390, > some ifdef'd with __MVS__, some with EBCDIC and NOT_ASCII. Hurrah! By dev.4, this compiles out-of-the-box and runs on OS/390. (Well, nearly OOTB. I have to knock off a couple rough edges, mentioned here previously.) "preliminary"? Well, I haven't even attempted testing gopher, wais, unicode, lots of fringe stuff. Welcome back Klaus. I understand you're a character set manipulation expert. I guess I've added a new dimension of complexity with the possibility of a host that doesn't run in ASCII. -- gil From owner-lynx-dev@sig.net Wed Nov 18 21:34:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA07597 for ; Wed, 18 Nov 1998 21:34:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA02442; Wed, 18 Nov 1998 20:15:43 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811190217.TAA19175@sanitas> Subject: lynx-dev "inline" fix To: lynx-dev@sig.net (Lynx List) Date: Wed, 18 Nov 1998 19:17:24 -0700 (MST) 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: 630 Lines: 15 Here's all it takes. TED noted that the support is all in configure; it just needs to be exploited. diff -brc ./orig/lynxsrc/config.hin ./lynxsrc/config.hin *** ./orig/lynxsrc/config.hin Mon Nov 16 15:59:28 1998 --- ./lynxsrc/config.hin Wed Nov 18 08:03:23 1998 *************** *** 135,140 **** --- 135,141 ---- #undef ZIP_PATH /* CF_PATH_PROG(zip) */ #undef _ALL_SOURCE /* AC_AIX */ #undef const /* defined by AC_C_CONST */ + #undef inline /* defined by AC_C_INLINE */ #undef mode_t /* defined by AC_TYPE_MODE_T */ #undef pid_t /* defined by AC_TYPE_PID_T */ #undef uid_t /* defined by AC_TYPE_UID_T */ From owner-lynx-dev@sig.net Wed Nov 18 21:39:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA07964 for ; Wed, 18 Nov 1998 21:39:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA04267; Wed, 18 Nov 1998 20:20:52 -0600 (CST) From: dickey@clark.net Message-Id: <199811190222.VAA23404@shell.clark.net> Subject: Re: lynx-dev include directories dropped: dev.4 To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 21:22:58 -0500 (EST) In-Reply-To: <199811190158.KAA19344@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 19, 98 10:58: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: 1001 Lines: 25 > > got the following error on SunOS4.1.3: > gcc -DHAVE_CONFIG_H -I/home/nelsonhe/.usr/include -DLOCALEDIR=\"/home/ > nelsonhe/.usr/share/locale\" -I. -I.. -Ichrtrans -I./chrtrans -I.. -I.. > /intl -I../src -I../WWW/Library/Implementation -O2 -DSUN -DSUN4 -c ./LYHash. > c > gcc -O2 -DSUN -DSUN4 -I/home/nelsonhe/.usr/include -target sun4 -o chrtra > ns/makeuctb chrtrans/makeuctb.c > chrtrans/makeuctb.c:20: HTUtils.h: No such file or directory > chrtrans/makeuctb.c:21: tcp.h: No such file or directory > chrtrans/makeuctb.c:33: UCkd.h: No such file or directory > chrtrans/makeuctb.c:34: UCDefs.h: No such file or directory > *** Error code 1 > make: Fatal error: Command failed for target `chrtrans/makeuctb' what changed? (I didn't modify the include paths on this patch) your log is one level short - perhaps you edited src/makefile to pass the flags down to src/chrtrans/makefile? > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 18 23:03:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA15139 for ; Wed, 18 Nov 1998 23:03:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA01944; Wed, 18 Nov 1998 21:42:30 -0600 (CST) Date: Wed, 18 Nov 1998 19:28:23 -0500 (EST) From: Marcus To: lynx-dev@sig.net Subject: lynx-dev http://wire.ap.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: 443 Lines: 10 the associated press site use to work with lynx 2.7.2 and 2.7.1 but doesn't work with 2.8 why is this? is it because lynx 2.8 doesn't support refuring servers anymore? Check out my web page! http://www.icubed.com/~marcus25/ don't forget the slash at the end! I am scoreboard king time master and Dana lover! I am chocolate king bacon king and Dana lover! I am king of laziness king of stubbornness and Dana lover! Get the picture? From owner-lynx-dev@sig.net Wed Nov 18 23:05:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA15204 for ; Wed, 18 Nov 1998 23:05:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA01784; Wed, 18 Nov 1998 21:41:57 -0600 (CST) Date: Wed, 18 Nov 1998 21:35:44 -0500 (EST) From: By-Tor To: lynx-dev@sig.net Subject: lynx-dev Lynx Bug 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: 952 Lines: 21 I've encountered a very repeatable problem with lynx that seems to have started with 2.8.2dev2: For some reason, which I've been unable to determine, if I try to log into www.cdnow.com it will give me an error saying that I'm possibly behind a firewall, which I'm not. Older versions of lynx will work fine. Basically, the easiest way to replicate this problem is to create an account on cdnow's website and then try to log in afterwards. Here's the pertinent info in my setup: Lynx Version 2.8.2dev.4 (18 Nov 1998) 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. BSD/OS nile.intac.com 2.1 BSDI BSD/OS 2.1 Kernel #3: Sun Apr 12 12:12:10 EDT 1998 ktbyers@www-server5.intac.net:/usr/local/src/sys/compile/NILE i386 -Mike mmp@earthling.net From owner-lynx-dev@sig.net Wed Nov 18 23:13:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA15816 for ; Wed, 18 Nov 1998 23:13:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA04815; Wed, 18 Nov 1998 21:51:27 -0600 (CST) From: Al Gilman Message-Id: <199811190354.WAA16818@access2.digex.net> Subject: lynx-dev demo experience at SC'98 To: lynx-dev@sig.net Date: Wed, 18 Nov 1998 22:54:50 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL15 (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: 724 Lines: 20 Thank you, Wayne, for getting 2.8.2 up there so I could be running it in the booth. I did get to flash it at several people, although because the point was to push accessible design I spent more time showing people pwWebSpeak talking their pages. But Lynx came in handy for a clear and compact depiction of technical flaws such as missing ALT's,
      's etc. There were hairy moments; our equipment got lost because the tag got torn off, and SciNet only got the network running on the demo floor like minutes before the gala opening. So we spent a lot of the first two days showing unrelated aps that could run canned on the kiosk. But in the end it all worked. Thanks again, Al Ref: http://trace.wisc.edu/world/paci/ From owner-lynx-dev@sig.net Thu Nov 19 01:04:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA24727 for ; Thu, 19 Nov 1998 01:04:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA26479; Wed, 18 Nov 1998 23:46:27 -0600 (CST) Message-Id: <19981119084823.07896@firepower> Date: Thu, 19 Nov 1998 08:48:23 +0000 From: Sergey Svishchev To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.4 Mail-Followup-To: lynx-dev@sig.net References: <199811181949.OAA04935@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <199811181949.OAA04935@shell.clark.net>; from dickey@clark.net on Wed, Nov 18, 1998 at 02:49:16PM -0500 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 587 Lines: 12 On Wed, Nov 18, 1998 at 02:49:16PM -0500, dickey@clark.net wrote: > * ifdef'd KEYBOARD_LAYOUT with EXP_KEYBOARD_LAYOUT, add configure option > --enable-kbd-layout. Note that control/Y is used as a process suspend > character on some platforms (VMS and Solaris) - TD > * add KEYBOARD_LAYOUT to lynx.cfg, to support character-translation on input, > add missing line editing style selection to Options form. This is enabled > and disabled by the line edit control/Y (Sergey Svishchev ). Not Control/Y, but Control/6. -- Sergey Svishchev -- svs{at}ropnet{dot}ru From owner-lynx-dev@sig.net Thu Nov 19 01:55:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA28054 for ; Thu, 19 Nov 1998 01:55:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA02186; Thu, 19 Nov 1998 00:35:58 -0600 (CST) Date: Thu, 19 Nov 1998 15:39:16 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190639.PAA21000@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev include directories dropped: dev.4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 217 Lines: 7 > what changed? (I didn't modify the include paths on this patch) Not sure, but (as usual?) it must be something I did since it compiled straight away on Solaris2.6. Thanks for clearing up the   bit. __Henry From owner-lynx-dev@sig.net Thu Nov 19 02:54:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA32181 for ; Thu, 19 Nov 1998 02:54:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA06353; Thu, 19 Nov 1998 01:22:23 -0600 (CST) Date: Wed, 18 Nov 1998 23:24:39 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev minor typo/grammer changes to userdefs.h In-Reply-To: <9811181736.AA17286@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: 787 Lines: 23 On Wed, 18 Nov 1998, Larry W. Virden wrote: > --- userdefs.h-dist Wed Nov 18 14:23:55 1998 > +++ userdefs.h-new Wed Nov 18 16:55:47 1998 > @@ -94,3 +94,3 @@ > /************************** > - * The EXTENSION_MAP file allows you to map file suffix's to > + * The EXTENSION_MAP file allows you to map file suffixs to ^^^^^^^ > * mime types. > @@ -277,3 +277,3 @@ > /************************** > - * The EXTENSION_MAP file allows you to map file suffix's to > + * The EXTENSION_MAP file allows you to map file suffixs to ^^^^^^^ This should be "suffixes". Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Thu Nov 19 03:13:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA00444 for ; Thu, 19 Nov 1998 03:13:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA09402; Thu, 19 Nov 1998 01:51:59 -0600 (CST) From: David Woolley Message-Id: <199811190007.AAA10879@djwhome.demon.co.uk> Subject: Re: lynx-dev internal cache proposal To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 00:07:22 +0000 (GMT) In-Reply-To: from "Leonid Pauzner" at Nov 18, 98 04:43:04 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: 1103 Lines: 29 > this is equivalent to "expired", sending conditional GET with "no-cache" > is enough (was explained below). This is actually a rather weird combination; it should either be an unconditional request with no-cache, to force an end to end reload, or a conditional request with max-age=0, to force end to end revalidation. I've wondered about this in the past, but Lynx really needs at least two and preferably three cases: 1) force revalidation (override history mechanism/refresh current page); 2) force end to end reload (an intermediate cache seems to have a corrupt copy); 3) force end to end revalidation (option: as (1) but override any policy by an intermediate cache to defer revalidation). I'm not sure which of these is currently being generated. > >> Method POST may be not cached for internal use > >> like changing ^V etc. > > > Why not? > it takes a time to understand what current code do with it. A true cache may never cache POST as POST is expected to have side effects and caching would prevent them. A history mechanism would normally not resubmit a POST. From owner-lynx-dev@sig.net Thu Nov 19 04:18:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA05628 for ; Thu, 19 Nov 1998 04:18:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA15322; Thu, 19 Nov 1998 02:55:09 -0600 (CST) Date: Thu, 19 Nov 1998 17:58:36 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811190858.RAA26466@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev include directories dropped: dev.4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 255 Lines: 7 > > what changed? (I didn't modify the include paths on this patch) > Not sure, but (as usual?) it must be something I did since it Just for the record, I got it to work by defining --prefix= for ./configure, something I had never done before. __Henry From owner-lynx-dev@sig.net Thu Nov 19 05:24:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA09666 for ; Thu, 19 Nov 1998 05:24:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22184; Thu, 19 Nov 1998 04:06:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811191008.FAA27081@shell.clark.net> Subject: Re: lynx-dev "inline" fix To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 05:08:46 -0500 (EST) In-Reply-To: <199811190217.TAA19175@sanitas> from "pg@sweng.stortek.com" at Nov 18, 98 07:17: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: 848 Lines: 26 > > Here's all it takes. TED noted that the support is > all in configure; it just needs to be exploited. thanks (I'd forgotten it had become a standard autoconf macro - it's been there so long...) > diff -brc ./orig/lynxsrc/config.hin ./lynxsrc/config.hin > *** ./orig/lynxsrc/config.hin Mon Nov 16 15:59:28 1998 > --- ./lynxsrc/config.hin Wed Nov 18 08:03:23 1998 > *************** > *** 135,140 **** > --- 135,141 ---- > #undef ZIP_PATH /* CF_PATH_PROG(zip) */ > #undef _ALL_SOURCE /* AC_AIX */ > #undef const /* defined by AC_C_CONST */ > + #undef inline /* defined by AC_C_INLINE */ > #undef mode_t /* defined by AC_TYPE_MODE_T */ > #undef pid_t /* defined by AC_TYPE_PID_T */ > #undef uid_t /* defined by AC_TYPE_UID_T */ > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 19 05:29:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA09952 for ; Thu, 19 Nov 1998 05:29:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22568; Thu, 19 Nov 1998 04:10:53 -0600 (CST) From: dickey@clark.net Message-Id: <199811191013.FAA27693@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.4 To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 05:13:11 -0500 (EST) In-Reply-To: <19981119084823.07896@firepower> from "Sergey Svishchev " at Nov 19, 98 08:48:23 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: 736 Lines: 19 > > On Wed, Nov 18, 1998 at 02:49:16PM -0500, dickey@clark.net wrote: > > > * ifdef'd KEYBOARD_LAYOUT with EXP_KEYBOARD_LAYOUT, add configure option > > --enable-kbd-layout. Note that control/Y is used as a process suspend > > character on some platforms (VMS and Solaris) - TD > > * add KEYBOARD_LAYOUT to lynx.cfg, to support character-translation on input, > > add missing line editing style selection to Options form. This is enabled > > and disabled by the line edit control/Y (Sergey Svishchev ). > > Not Control/Y, but Control/6. ok (I assume I was reading the wrong row). > Sergey Svishchev -- svs{at}ropnet{dot}ru -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 19 06:27:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA14914 for ; Thu, 19 Nov 1998 06:27:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA27212; Thu, 19 Nov 1998 05:03:24 -0600 (CST) Date: Thu, 19 Nov 1998 06:05:10 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811190605.AA4463@cas.org> Subject: Re: lynx-dev minor typo/grammer changes to userdefs.h In-Reply-To: of Wed, 18 Nov 1998 23:24:39 -0800 (PST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 678 Lines: 15 Yikes! I was looking at those ' marks and my brain shut down about spelling. I am SO embarrassed - again. Thanks for the catch. And yes, I did change a couple legit contractions. I was trying to leave things in the two files that people generally change so that the only ' usage was possessive. In my mind, when we have cross lingual submitting updates to the file, reducing special cases makes life easier. -- 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 Nov 19 07:15:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA18458 for ; Thu, 19 Nov 1998 07:15:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA00760; Thu, 19 Nov 1998 05:47:53 -0600 (CST) Date: Thu, 19 Nov 1998 06:49:40 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811190649.AA4706@cas.org> Subject: lynx-dev more info on the download message bug To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2144 Lines: 62 Okay, here's a repeatable, for me, case. Run: lynx http://www.qni.com/~brisk/PalmPilot/ReadDocJ/ReadDocJ.zip When it is time for the download, what _I_ see is s D)ownload, or C)ancel Here is the stack trace at the time of the msg. It looks like lynx wants to say: application/zip D)ownload, or C)ancel =>[1] HTSprintf(pstr = 0xefffc3dc, fmt = 0x25238c "%s D)ownload, or C)ancel", ...), line 554 in "HTString.c" [2] user_message(message = 0x25238c "%s D)ownload, or C)ancel", argument = 0x30ee48 "application/zip"), line 5314 in "GridText.c" [3] HTSaveToFile(pres = 0xefffc5d4, anchor = 0x30f658, sink = (nil)), line 633 in "HTFWriter.c" [4] HTStreamStack(rep_in = 0x3075f8, rep_out = 0x2fa018, sink = (nil), anchor = 0x30f658), line 407 in "HTFormat.c" [5] HTMIME_put_character(me = 0x3106e8, c = '\n'), line 512 in "HTMIME.c" Here's the HTSprintf code: #if USE_STDARG_H PUBLIC char * HTSprintf (char ** pstr, CONST char * fmt, ...) #else PUBLIC char * HTSprintf (pstr, fmt, va_alist) char ** pstr; CONST char * fmt; va_dcl #endif { va_list ap; LYva_start(ap,fmt); StrAllocVsprintf(pstr, (pstr && *pstr) ? strlen(*pstr) : 0, fmt, ap); va_end(ap); return (*pstr); } During this entry, pstr had already been allocated - BUT, *pstr is '\0'. fmt was the D)ownload msg, and when I attempt to print ap, I get (void) - before and after the LYva_start() call. When we get down into the StrAll... I find that because a 0 is passed, we never get into the loop that attempts to interpret the fmt string, resulting in the s thru the rest of the string being used as the prompt. Does that help anyone fix this bug? P.S. I don't know if I remember correctly - did someone mention the bug where when you interrupt lynx, two copies of the error msg, both with % signs in them, are output? I suspect this is related to this bug. -- 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 Nov 19 07:25:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA19244 for ; Thu, 19 Nov 1998 07:25:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA02879; Thu, 19 Nov 1998 06:07:01 -0600 (CST) Message-ID: <19981119070834.A614@bcpl.net> Date: Thu, 19 Nov 1998 07:08:34 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: lynx-dev NLS tweaks for 282dev4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i 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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 776 Lines: 16 I just built dev4 using "./configure --enable-nls --with-included-gettext". After a bit of tweaking it is working again for me on NetBSD. I see the long copyright message has been restored to 3 lines in LYMain.c, which might have disabled the translations I hacked up (but it seems to work still). I needed to copy cat-id-tbl.c from the hello code to get the po files to build. I'm not sure of the purpose of this file, so if anyone knows, please advise. It says "Automatically generated by po2tbl.sed from hello.pot." I've uploaded newer lynx.pot and fr.po files into http://www.slcc.edu/lynx/po/. Until the Free Translation Project answers my email and sets up a repository for these files, I will put them here. ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Thu Nov 19 08:19:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA24416 for ; Thu, 19 Nov 1998 08:19:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA08483; Thu, 19 Nov 1998 06:51:51 -0600 (CST) From: dickey@clark.net Message-Id: <199811191254.HAA20208@shell.clark.net> Subject: Re: lynx-dev more info on the download message bug To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 07:54:09 -0500 (EST) In-Reply-To: <9811190649.AA4706@cas.org> from "lvirden@cas.org" at Nov 19, 98 06:49:40 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: 804 Lines: 20 > When we get down into the StrAll... I find that because a 0 is passed, we > never get into the loop that attempts to interpret the fmt string, resulting > in the s thru the rest of the string being used as the prompt. > > Does that help anyone fix this bug? probably. I'll look at this tonight. > P.S. I don't know if I remember correctly - did someone mention the bug > where when you interrupt lynx, two copies of the error msg, both with % > signs in them, are output? I suspect this is related to this bug. probably (it calls the same function). sounds like I missed a turn in the logic to retain the previous buffer's size when reallocating. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 19 08:24:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA24955 for ; Thu, 19 Nov 1998 08:24:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA09344; Thu, 19 Nov 1998 06:57:49 -0600 (CST) Date: Thu, 19 Nov 1998 22:01:26 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811191301.WAA27488@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 844 Lines: 19 > to build. I'm not sure of the purpose of this file, so if anyone knows, The following works for me without a hitch (Solaris2.6, SunOS4.1.3). % cd lynx2-8-2 % ls ./WWW/Library/Implementation/*.[ch] ./src/*.[ch] ./*.[ch] > z-ls % cp ../ja.po . % xgettext -f z-ls -j --no-location -o ja.po % msgfmt -a -v -o lynx.mo ja.po % cp lynx.mo /home/.usr/share/locale/ja/LC_MESSAGES If you are doing it for the first time, the third step is not valid, and the forth step is without the -j option. The second step may seem like overkill, but there certainly is infinitely less overhead than using a bunch of tools to get an exact listing. Change ja to the language of your choice. Sorry, Jim, but I still do `rm -rf intl po` before a build. Once you have libintl, you have it. Once you've done even one translation, it's xgettext with -j. __Henry From owner-lynx-dev@sig.net Thu Nov 19 08:40:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA26375 for ; Thu, 19 Nov 1998 08:40:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA12901; Thu, 19 Nov 1998 07:21:48 -0600 (CST) From: Philip Webb Message-Id: <199811191322.IAA10743@chass.utoronto.ca> Subject: Re: lynx-dev http://wire.ap.org To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 08:22:40 -0500 (EST) Cc: marcus25@infobahn.icubed.com In-Reply-To: from "Marcus" at Nov 18, 98 07:28: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: 952 Lines: 19 981118 Marcus wrote: > the associated press site use to work with lynx 2.7.2 and 2.7.1 > but doesn't work with 2.8 why is this? > is it because lynx 2.8 doesn't support refuring servers anymore? no: the problem seems to be that wire.ap.org/ is largely Javascript; if you add APnews/main.html , you get what you probably want. note to lynx-dev generally: entering the former URL got me the JS page, but when i entered \ then \ again to recover the rendered page, i got a page consisting of 2 frame URLs, incl the latter above, whence i was able to goto some real information. i've never before encountered a situation in which 2 \'s take me to a different rendered page. -- ========================,,============================================ 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 Nov 19 08:51:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA27043 for ; Thu, 19 Nov 1998 08:51:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA14542; Thu, 19 Nov 1998 07:31:19 -0600 (CST) From: Philip Webb Message-Id: <199811191332.IAA11702@chass.utoronto.ca> Subject: Re: lynx-dev minor typo patch for lynx.cfg in lynx 2.8.2dev.4 To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 08:32:12 -0500 (EST) In-Reply-To: <9811181734.AA17250@cas.org> from "Larry W. Virden" at Nov 18, 98 05:34:29 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: 1002 Lines: 21 981118 Larry Virden wrote: > --- lynx.cfg-dist Wed Nov 18 14:23:55 1998 > +++ lynx.cfg-new Wed Nov 18 17:33:46 1998 -- snip -- > @@ -501,4 +503,4 @@ > # > -# The Unix and VMS (but not VAXC) implementations use the C library malloc's > -# and calloc's for memory allocation, but procedures for taking the actual > +# The Unix and VMS (but not VAXC) implementations use the C library mallocs > +# and callocs for memory allocation, but procedures for taking the actual > # amount of cache into account still need to be developed. They use only -- snip -- i recommend keeping the ' in such cases for legibility, ie when the word is the name of a lower-case program function. the other nits are worth picking, if you have the time. -- ========================,,============================================ 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 Nov 19 08:54:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA27112 for ; Thu, 19 Nov 1998 08:54:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA15104; Thu, 19 Nov 1998 07:34:56 -0600 (CST) From: Philip Webb Message-Id: <199811191335.IAA12033@chass.utoronto.ca> Subject: Re: lynx-dev minor typo/grammer[SIC] changes etc To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 08:35:50 -0500 (EST) In-Reply-To: <9811181736.AA17286@cas.org> from "Larry W. Virden" at Nov 18, 98 05:36: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: 1336 Lines: 33 981118 Larry Virden is hiding his blushes (smile) & wrote: > --- userdefs.h-dist Wed Nov 18 14:23:55 1998 > +++ userdefs.h-new Wed Nov 18 16:55:47 1998 > @@ -94,3 +94,3 @@ > /************************** > - * The EXTENSION_MAP file allows you to map file suffix's to > + * The EXTENSION_MAP file allows you to map file suffixs to > * mime types. > @@ -277,3 +277,3 @@ > /************************** > - * The EXTENSION_MAP file allows you to map file suffix's to > + * The EXTENSION_MAP file allows you to map file suffixs to > * mime types. the plural of `suffix' is `suffixes' ... -- snip -- > @@ -569,4 +569,4 @@ > * > -* The Unix and VMS but not VAXC implementations use the C library malloc's > -* and calloc's for memory allocation, and procedures for taking the actual > +* The Unix and VMS but not VAXC implementations use the C library mallocs > +* and callocs for memory allocation, and procedures for taking the actual > * amount of cache into account still need to be developed. They use only same objection as in the other message. -- snip -- -- ========================,,============================================ 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 Nov 19 09:08:13 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA28055 for ; Thu, 19 Nov 1998 09:08:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA18369; Thu, 19 Nov 1998 07:51:41 -0600 (CST) Message-ID: <19981119085301.A2622@mail.bcpl.net> Date: Thu, 19 Nov 1998 08:53:01 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 References: <199811191301.WAA27488@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811191301.WAA27488@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Thu, Nov 19, 1998 at 10:01:26PM +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.93.2i (1998-07-29) 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: 1688 Lines: 32 On Thu, Nov 19, 1998 at 10:01:26PM +0900, Nelson Henry Eric wrote: > The following works for me without a hitch (Solaris2.6, SunOS4.1.3). > 1 % cd lynx2-8-2 > 2 % ls ./WWW/Library/Implementation/*.[ch] ./src/*.[ch] ./*.[ch] > z-ls > 3 % cp ../ja.po . > 4 % xgettext -f z-ls -j --no-location -o ja.po > 5 % msgfmt -a -v -o lynx.mo ja.po > 6 % cp lynx.mo /home/.usr/share/locale/ja/LC_MESSAGES > > If you are doing it for the first time, the third step is not valid, > and the forth step is without the -j option. The second step may seem > like overkill, but there certainly is infinitely less overhead than > using a bunch of tools to get an exact listing. Change ja to the > language of your choice. Sorry, Jim, but I still do `rm -rf intl po` > before a build. Once you have libintl, you have it. Once you've done > even one translation, it's xgettext with -j. No need to apologize. I am trying to make sure all of the pieces are there for new users, while you are looking at incremental stability for existing users. Both are important. I copied your ja.po.bz2 file to the directory http://www.slcc.edu/lynx/po. Hope you don't mind. What do you think about storing bz2 vs. gz vs. plain po text files? I changed the lynx.pot back to lynx.po since ".pot" caused SLCC to assume I had a powerpoint template file (shudder). ------ Marvin the Paranoid Android says: Pausing to reconstruct the whole infrastructure of integral mathematics in his head, he went about his humble task, never thinking to ask for reward, recognition or even a moments ease from the pain in all the diodes down his left side... From owner-lynx-dev@sig.net Thu Nov 19 09:10:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA28353 for ; Thu, 19 Nov 1998 09:10:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA18577; Thu, 19 Nov 1998 07:53:02 -0600 (CST) Date: Thu, 19 Nov 1998 07:55:16 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev HTmmdecode (was Re: strange interaction with gettext/anonymous/gz) In-Reply-To: <199811181250.VAA13744@ews07.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: 782 Lines: 17 On Wed, 18 Nov 1998, Nelson Henry Eric wrote: > It seemed to me that what was happening was that the string was getting > truncated somewhere, with the result that occasionally a multibyte > character would get split in a place that would result in a non-ascii > character that messed up what came after it. At the time, I thought > it was because the function seemed to analyze the =?iso-nnnn part only > one time, whereas in fact it can occur multiple times. It also seemed > like it was trying to cut out the =?iso-nnnn part, when it could just > stay there. But really my memory has faded a lot. And so has mine. :) I'll probably look at it at some point. I save your message as an example of the bytes that should be generated (but I can't read any of it. :) ) Klaus From owner-lynx-dev@sig.net Thu Nov 19 09:16:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA28453 for ; Thu, 19 Nov 1998 09:16:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA19264; Thu, 19 Nov 1998 07:56:22 -0600 (CST) Message-ID: <19981119085731.B2622@mail.bcpl.net> Date: Thu, 19 Nov 1998 08:57:31 -0500 From: Webmaster Jim To: lynx-dev@sig.net Cc: Yury Onischuck Subject: lynx-dev Entry to TODO list: emacs hooks Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" X-Mailer: Mutt 0.93.2i 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.93.2i (1998-07-29) 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: 1770 Lines: 45 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii I've attached a "TODO" item just entered. I think this is not a Lynx development item, but an emacs lisp issue. I use the Emacs "sgml" mode and can launch netscape or lynx to view page I have just edited. Send private email for details. ------ Marvin the Paranoid Android says: Pausing to reconstruct the whole infrastructure of integral mathematics in his head, he went about his humble task, never thinking to ask for reward, recognition or even a moments ease from the pain in all the diodes down his left side... --W/nzBZO5zC0uMSeA Content-Type: message/rfc822 Content-Description: Forwarded message from Yury Onischuck Received: from SOL.SLCC.EDU (sol.SLCC.edu [144.35.10.96]) by mail.bcpl.net (8.8.7/8.8.7) with ESMTP id IAA02521 for ; Thu, 19 Nov 1998 08:46:38 -0500 (EST) Received: (from nobody@localhost) by SOL.SLCC.EDU (8.9.1/8.9.1) id GAA17848; Thu, 19 Nov 1998 06:49:16 -0700 (MST) Date: Thu, 19 Nov 1998 06:49:16 -0700 (MST) Message-Id: <199811191349.GAA17848@SOL.SLCC.EDU> Reply-to: yury@buyonet.com (Yury Onischuck) From: yury@buyonet.com (Yury Onischuck) Subject: Entry to TODO list Content-Type: text You have a new entry in your TODO list: ------------------------------------------------------ I would like to have a tight integration between lynx and emacs. I mean lynx to be run as background process rendering pages to be used in emacs buffer. Very much like GUD makes emacs interface to GDB. Yury Onischuck - Thursday, November 19, 1998 at 06:49:15 (MST) ------------------------------------------------------ --W/nzBZO5zC0uMSeA-- From owner-lynx-dev@sig.net Thu Nov 19 09:25:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA29110 for ; Thu, 19 Nov 1998 09:25:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA20594; Thu, 19 Nov 1998 08:01:54 -0600 (CST) Date: Thu, 19 Nov 1998 08:04:12 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Request for Comment: partial display and refresh In-Reply-To: <9811180643.AA13529@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: 931 Lines: 23 On Wed, 18 Nov 1998, Larry W. Virden wrote: > When I configure lynx to do partial display and to use ncurses 4.2.patched > thru the first week of November, it appears > that at the end of the loading of the file, lynx does a screen refresh. > I am wondering if someone familar with that code could conceive of a > way for that code to some how determine whether or not the refresh is > necessary. > > In many cases, lynx loads things so quickly that the refresh occurs > almost as fast as the initial load occurs - causing the screen to > 'blink'. One thing to check: does this also occur when the first screen of the page doesn't have any links - for example when it is text/plain not text/html? If not, it probably has something to do with the refresh() done in highlight(). Just to be sure: you have FANCY_CURSES defined, and are not using -enable_scrollback, and your display character set is not UTF-8, right? Klaus From owner-lynx-dev@sig.net Thu Nov 19 09:28:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA29447 for ; Thu, 19 Nov 1998 09:28:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA21480; Thu, 19 Nov 1998 08:05:53 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Thu, 19 Nov 1998 09:08:07 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev Lynx Bug 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: 2864 Lines: 69 On Wed, 18 Nov 1998, By-Tor wrote: > I've encountered a very repeatable problem with lynx that seems to > have started with 2.8.2dev2: For some reason, which I've been unable to > determine, if I try to log into www.cdnow.com it will give me an error > saying that I'm possibly behind a firewall, which I'm not. Older versions > of lynx will work fine. It seems to be the same problem I'm having when I submit a form. With dev.3 and dev.4 I can't login to eBay and MailBank. Here's part of the the tracelog of dev.2 and dev.3 when trying to submit a form at eBay.: dev.2 ----- User message: Trace ON! SubmitForm: field "MfcISAPICommand" 0 us-ascii OK SubmitForm: name "MfcISAPICommand" 0 us-ascii OK SubmitForm: field "item" 0 us-ascii OK SubmitForm: name "item" 0 us-ascii OK SubmitForm: field "userid" 0 us-ascii OK SubmitForm: name "userid" 0 us-ascii OK SubmitForm: field "pass" 0 us-ascii OK SubmitForm: name "pass" 0 us-ascii OK SubmitForm: field "maxbid" 0 us-ascii OK SubmitForm: name "maxbid" 0 us-ascii OK SubmitForm: skipping submit field with name "" for link_name "", no field name. GridText - post_data: MfcISAPICommand=MakeBid&item=41941683&userid=ismaelc&pass=xxxx&maxbid=3.25 dev.3 ---- User message: Trace ON! FIXME:SubmitForm SubmitForm: field "MfcISAPICommand" 0 us-ascii OK SubmitForm: name "MfcISAPICommand" 0 us-ascii OK SubmitForm: field "item" 0 us-ascii OK SubmitForm: name "item" 0 us-ascii OK SubmitForm: field "userid" 0 us-ascii OK SubmitForm: name "userid" 0 us-ascii OK SubmitForm: field "pass" 0 us-ascii OK SubmitForm: name "pass" 0 us-ascii OK SubmitForm: field "maxbid" 0 us-ascii OK SubmitForm: name "maxbid" 0 us-ascii OK SubmitForm: skipping submit field with name "" for link_name "", no field name. GridText - post_data: sMfcISAPICommand=MakeBid&item=41941683&userid=ismaelc&pass=xxxx&maxbid=3.25 Besides the "FIXME:SubmitForm" message we can see that an "s" is being added to the begining of "GridText - post_data". Here's another one with the "s" added: User message: Trace ON! FIXME:SubmitForm SubmitForm: field "EmailAddress" 0 us-ascii OK SubmitForm: name "EmailAddress" 0 us-ascii OK SubmitForm: field "Password" 0 us-ascii OK SubmitForm: name "Password" 0 us-ascii OK SubmitForm: field "MbrPage" 0 us-ascii OK SubmitForm: name "MbrPage" 0 us-ascii OK SubmitForm: field "Submit" 0 us-ascii OK SubmitForm: name "Submit" 0 us-ascii OK GridText - post_data: sEmailAddress=ismael@cordeiro.com&Password=xxxx&MbrPage=MbrMain.asp&Submit=Submit 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 Nov 19 10:04:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA32398 for ; Thu, 19 Nov 1998 10:04:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA28028; Thu, 19 Nov 1998 08:32:07 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Thu, 19 Nov 1998 09:34:18 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.4 In-Reply-To: <19981119084823.07896@firepower> 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: 844 Lines: 19 On Thu, 19 Nov 1998, Sergey Svishchev wrote: > > * add KEYBOARD_LAYOUT to lynx.cfg, to support character-translation on input, > > add missing line editing style selection to Options form. This is enabled > > and disabled by the line edit control/Y (Sergey Svishchev ). > > Not Control/Y, but Control/6. What that ^6 sends? I've never heard of ^6. The control codes, 00h to 1Fh, in ASCII/ISO 646/ISO 8859-x are ^@, ^A to ^Z, ^[, ^\, ^], ^^ and ^_ 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 Nov 19 10:07:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA00054 for ; Thu, 19 Nov 1998 10:07:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA02076; Thu, 19 Nov 1998 08:46:08 -0600 (CST) Date: Thu, 19 Nov 1998 09:47:53 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811190947.AA6841@cas.org> Subject: Re: lynx-dev Request for Comment: partial display and refresh In-Reply-To: of Thu, 19 Nov 1998 08:04:12 -0600 (CST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1312 Lines: 30 From: Klaus Weide > One thing to check: does this also occur when the first screen of > the page doesn't have any links - for example when it is text/plain > not text/html? If not, it probably has something to do with the refresh() > done in highlight(). It happens when I say lynx /tmp/file.txt and file.txt is not html - I assume that's the same condition you are describing. >Just to be sure: you have FANCY_CURSES defined, and are not using >-enable_scrollback, and your display character set is not UTF-8, >right? How can I tell these things? I don't specifically set enable_scrollback. I use ncurses, so I assume that sets FANCY_CURSES. I am not intentionally setting UTF-8 . Is there something I can generate that will tell you more about my configuration to help? This is one of at least two outstanding issues I have with linking lynx with the development version of ncurses. Unfortunately it does such a great job of color highlighting that I find I can't bear to use the default curses on Solaris... -- 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 Nov 19 10:32:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA02336 for ; Thu, 19 Nov 1998 10:32:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA07486; Thu, 19 Nov 1998 09:03:23 -0600 (CST) Date: Thu, 19 Nov 1998 09:05:38 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: Francis Irving Subject: Re: lynx-dev Problems with -traversal In-Reply-To: <3655d4f0.175758890@clarabel> 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: 3197 Lines: 79 On Wed, 18 Nov 1998, Francis Irving wrote: > With -traversal, Lynx keeps traversing the same page over and over again. > I'm using version 2.8.1rel.1, the Win32 port (downloaded today from > http://www.fdisk.com/doslynx/wlynx/lynx_w32.zip). > > Example. with an empty current directory type: > > > lynx -traversal http://www.meta.demon.co.uk > > Lynx gets stuck in an infinite loop, and generates two files > > [d:\sitetest]type traverse.dat > http://www.meta.demon.co.uk/ > http://www.meta.demon.co.uk/i.html > http://www.meta.demon.co.uk/index.html > http://www.meta.demon.co.uk/i.html > http://www.meta.demon.co.uk/index.html > http://www.meta.demon.co.uk/i.html > > [d:\sitetest]type traverse2.dat > http://www.meta.demon.co.uk/ Francis's page > http://www.meta.demon.co.uk/i.html I > http://www.meta.demon.co.uk/index.html Francis's page > http://www.meta.demon.co.uk/i.html I > http://www.meta.demon.co.uk/index.html Francis's page > http://www.meta.demon.co.uk/i.html I > http://www.meta.demon.co.uk/index.html Francis's page > http://www.meta.demon.co.uk/i.html I > > which repeat in this way. > > I didn't have the same problem with an earlier pre-release of the same > version. When I try this with 2.8.1rel.2 (with some unrelated changes), on linux, I get the following: the starting page is displayed, then the message unable to open traversal found file: No such file or directory is displayed and Lynx exits without restoring the tty settings (leaving icanon and echo off). The directory now contains one new file with two lines: $ cat traverse.dat http://www.meta.demon.co.uk/ http://www.meta.demon.co.uk/i.html and with permissions -rw-------. When I try again without removing that file, the message unable to open reject file: No such file or directory appears somewhere on the screen, and again Lynx exits without restoring the tty settings. It appears there alre problems introduced by replacing fopen() calls in LYTraversal.c with calls to LYNewTxtFile() and LYAppendToTxtFile(). More specifically, at least the LYAppendToTxtFile() calls in add_to_traverse_list() and add_to_reject_list() don't act the same way as the fopen(..,"a+") calls appearing in the same place in previous versions of LYTraversal.c. Maybe they fail because the files don't exist, or because they are not given as full pathnames: #define TRAVERSE_FILE "traverse.dat" #define TRAVERSE_FOUND_FILE "traverse2.dat" #define TRAVERSE_REJECT_FILE "reject.dat" #define TRAVERSE_ERRORS "traverse.errors" A solution or workaround may be to revert LYTraversal.c to what it was in previous versions. I don't see a point in doing paranoid file permission checks on these files anyway. I also don't see the point in leaving them with restrictive permissions; they are user files, not files for internal use by lynx, and they would not normally be in /tmp/, so the normal umask should apply. Also, the functions in LYTraversal.c should call stop_curses() before exiting (maybe only if LYCursesON is set). Note that these problems may be separate from Francis Irving's problems. The platform is not the same, and this is 2.8.1rel.2 vs. his 2.8.1rel.1. Klaus From owner-lynx-dev@sig.net Thu Nov 19 11:10:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA05209 for ; Thu, 19 Nov 1998 11:10:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA24194; Thu, 19 Nov 1998 09:46:11 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Thu, 19 Nov 1998 10:48:17 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev more info on the download message bug In-Reply-To: <9811190649.AA4706@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: 734 Lines: 16 On Thu, 19 Nov 1998, Larry W. Virden wrote: > When we get down into the StrAll... I find that because a 0 is passed, we > never get into the loop that attempts to interpret the fmt string, resulting > in the s thru the rest of the string being used as the prompt. ^ Would be that "s" the same that is being added to submit forms or just a coincidence? 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 Nov 19 11:13:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA05324 for ; Thu, 19 Nov 1998 11:13:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA21290; Thu, 19 Nov 1998 09:39:36 -0600 (CST) Message-ID: <19981119074133.58539@shell3.ba.best.com> Date: Thu, 19 Nov 1998 07:41:33 -0800 From: Kim DeVaughn To: lynx-dev@sig.net Subject: lynx-dev Re: lynx2.8.2dev.4 Mail-Followup-To: lynx-dev@sig.net References: <199811181949.OAA04935@shell.clark.net> <19981119084823.07896@firepower> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19981119084823.07896@firepower>; from Sergey Svishchev on Thu, Nov 19, 1998 at 08:48:23AM +0000 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: 1005 Lines: 25 On Thu, Nov 19, 1998, Sergey Svishchev (svs@ropnet.ru) said: | | On Wed, Nov 18, 1998 at 02:49:16PM -0500, dickey@clark.net wrote: | > | >*ifdef'd KEYBOARD_LAYOUT with EXP_KEYBOARD_LAYOUT, add configure option | > --enable-kbd-layout. Note that control/Y is used as a process suspend | > character on some platforms (VMS and Solaris) - TD | >*add KEYBOARD_LAYOUT to lynx.cfg, to support character-translation on input, | > add missing line editing style selection to Options form. This is enabled | > and disabled by the line edit control/Y (Sergey Svishchev ). | | Not Control/Y, but Control/6. FWIW ... A ^Y does do a suspend on FreeBSD platforms, when lynx is built using ncurses (4.2+patches), unless you do something like "stty dsusp undef" in your .cshrc file. It doesn't do that (or require an stty fixup) when lynx is built with slang (1.2.2). I don't think there is such a thing as a ^6, unless what you meant was a ^^ char (since "^" is usually on the 6-key, shifted). /kim From owner-lynx-dev@sig.net Thu Nov 19 11:33:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA06933 for ; Thu, 19 Nov 1998 11:33:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA06312; Thu, 19 Nov 1998 10:13:14 -0600 (CST) Date: Thu, 19 Nov 1998 11:14:57 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811191114.AA7780@cas.org> Subject: Re: lynx-dev more info on the download message bug In-Reply-To: of Thu, 19 Nov 1998 10:48:17 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 307 Lines: 5 coincidence. The s is part of the prompt. -- 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 Nov 19 11:40:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA07580 for ; Thu, 19 Nov 1998 11:40:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA09830; Thu, 19 Nov 1998 10:21:26 -0600 (CST) Date: Thu, 19 Nov 1998 10:23:39 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: marcus25@infobahn.icubed.com Subject: Re: lynx-dev http://wire.ap.org In-Reply-To: <199811191322.IAA10743@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: 3271 Lines: 70 On Thu, 19 Nov 1998, Philip Webb wrote: > 981118 Marcus wrote: > > the associated press site use to work with lynx 2.7.2 and 2.7.1 > > but doesn't work with 2.8 why is this? > > is it because lynx 2.8 doesn't support refuring servers anymore? > > no: the problem seems to be that wire.ap.org/ is largely Javascript; > if you add APnews/main.html , you get what you probably want. > > note to lynx-dev generally: entering the former URL got me the JS page, > but when i entered \ then \ again to recover the rendered page, > i got a page consisting of 2 frame URLs, incl the latter above, > whence i was able to goto some real information. > i've never before encountered a situation > in which 2 \'s take me to a different rendered page. When you first goto the page, Lynx doesn't send a Referer: header. After that, when you do '\' (SOURCE), then it does. Check your -trace log to verify. The server is sending a different page depending on that. In other words it does negotiation on the Referer header. Of course it also claims to be HTTP/1.1 compliant, but doesn't have a "Vary: referer" anywhere to indicate this, nor does it make the page explicitly uncacheable. (Not that lynx would currently care about the vary, but other clients and caches would.) If you were accessing the page through a cache, the '\' trick wouldn't work, at least if the cache is configured to cache responses without Last-Modified and other caching-related headers (but with a valid Date header.) Note that it also wouldn't work if the caching ideas currently discussed for lynx were implemented. It is at least questionable whether lynx should send a Referer header in this situation at all. Apparently it doesn't when RELOAD is used. The behavior may have changed from previous versions, or the configuration file settings may be different. These peoples seem to be relatively clueless. They introduce some non-interoperable behavior, then then try to blame problems on "Older versions of the AOL browser". Using an AOL browser may not be the only reason why a Refere header is not being sent. This is from RFC 2068: The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. [ ... ] Note: Because the source of a link may be private information or may reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information. See also additional remarks in the section "Security Considerations". Klaus From owner-lynx-dev@sig.net Thu Nov 19 11:51:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08292 for ; Thu, 19 Nov 1998 11:51:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14058; Thu, 19 Nov 1998 10:31:35 -0600 (CST) Date: Thu, 19 Nov 1998 20:34:54 +0530 From: "K.R.Shamasundar" To: lynx-dev@sig.net Subject: lynx-dev Request for help 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: 663 Lines: 16 Hello, I have got lynx2-8-1 and have tried to install it for sgi-irix-6.2 machine. Compilation is successful. I have this problem that, when I press "g" key, and type in "RETURN/ENTER" key, the value is not accepted. The cursor remains as it is. And once I use "g" key, the only way to come back is to use "CNTRL-G" key to cancel this request. That means that lynx is not recognizing "RETURN" key; Can you please suggest me how to solve the problem? Do I have to carryout some settings? I am thankful if you can direct this to a news-group in case you choose not to reply to this mail. my email : krss@comp.ncl.res.in Bye, Shamsundar. From owner-lynx-dev@sig.net Thu Nov 19 11:53:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08342 for ; Thu, 19 Nov 1998 11:53:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14160; Thu, 19 Nov 1998 10:31:48 -0600 (CST) Date: Thu, 19 Nov 1998 01:44:41 -0800 (PST) From: Ryan Hung To: lynx-dev@sig.net Subject: lynx-dev Improper ~/ expansion in 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: 894 Lines: 16 I have just rejoined the list after a long absence, so I am unsure whether this issue has been addressed (a brief search on the archives yielded nothing). Basically, I have observed that in Lynx >2.8.1 (up to 2.8.2dev.4), file://localhost/~ gets expanded as, e.g.: file://localhost//home/username. This means that %p for DIRED_MENU commands is incorrect, breaking operations like changing file permissions. I located what seems to be the relevant section in LYGetFile.c (line 587 in 2.8.2dev.4), but don't understand it well enough to determine whether this is buggy code. Ryan. _/ \__/ \__/ \__/ \__/ \__/ \__/ \__/rhung@vcn.bc.ca__/ \__/ \__/ \_Apoptosis=programmed cell death/ \__/ \rwhung@interchange.ubc.ca_/ \__ _/ --you can't live without it!/ \__/ \http://www.vcn.bc.ca/people/rhung \__/ \__/ \__/ \__/ \__/ \__/ \__/ \My words Copyright (C) 1998 \__ From owner-lynx-dev@sig.net Thu Nov 19 11:54:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08359 for ; Thu, 19 Nov 1998 11:54:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA15282; Thu, 19 Nov 1998 10:34:33 -0600 (CST) Date: Thu, 19 Nov 1998 10:36:34 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Request for Comment: partial display and refresh In-Reply-To: <9811190947.AA6841@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: 1231 Lines: 39 On Thu, 19 Nov 1998, Larry W. Virden wrote: > From: Klaus Weide > > > One thing to check: does this also occur when the first screen of > > the page doesn't have any links - for example when it is text/plain > > not text/html? If not, it probably has something to do with the refresh() > > done in highlight(). > > It happens when I say > lynx /tmp/file.txt > and file.txt is not html - I assume that's the same condition you are > describing. Yes. > >Just to be sure: you have FANCY_CURSES defined, and are not using > >-enable_scrollback, and your display character set is not UTF-8, > >right? > > How can I tell these things? I don't specifically set enable_scrollback. Then you don't. > I use ncurses, so I assume that sets FANCY_CURSES. Yes it should, especially if you are seeing colors. You could check in lynx_cfg.h or by following the "compile time settings" link from a '=' page. > I am not intentionally > setting UTF-8. Is there something I can generate that will tell you > more about my configuration to help? That answers my questions - I was just wildly guessing anyway. I don't seem to see the same effect, with either a slang or a solor style version of 2.8.1rel.2. Klaus From owner-lynx-dev@sig.net Thu Nov 19 11:55:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08389 for ; Thu, 19 Nov 1998 11:55:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA13936; Thu, 19 Nov 1998 10:31:20 -0600 (CST) Date: Thu, 19 Nov 1998 21:33:08 +0530 From: "K.R.Shamasundar" To: lynx-dev@sig.net Subject: lynx-dev Request for help 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: 283 Lines: 9 Hello, This is again in connection with my previous email. "RETURN/ENTER" key is not being recognized at all by lynx2-8-1 here in SGI-IRIX-6.2 m/c. This is not just for the case I mentioned in my last email. Last case was just one example. Shamsundar. krss@comp.ncl.res.in From owner-lynx-dev@sig.net Thu Nov 19 11:57:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08432 for ; Thu, 19 Nov 1998 11:57:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA14242; Thu, 19 Nov 1998 10:31:58 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811190936.LAA23887@ozone.fmi.fi> Subject: Re: lynx-dev gettext() question #2 In-Reply-To: from Leonid Pauzner at "Nov 18, 1998 07:51:52 pm" To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 11:36:39 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL50 (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: 2971 Lines: 132 Leonid Pauzner: > > $LANG includes implicity character set, because it specifies > > also LC_CTYPE locale. > > not always, but should to. > > > So if user is using some remote terminal, he needs adjust > > $LANG also to get other programs (than lynx) to work correctly. > > > Some systems there is several possible $LANG values for same > > language (which just differ by used caharacter-set). For example: > > > en_US > > en_US.ISO8859-1 > > > It may make do sense to map $LANG (or result of setlocale(LC_CTYPE,NULL) > > actually) to character set with some (OS dependent) mapping table. > > probably Yes. > It was proposed just before the releasing 2.8, > concerning case-insensitive search, but nobody > have contributed the mapping table (we find another workaround). Problem is that different OSes use different charster-set for same language. (For example _if I remember correclty_, 'fi_FI' on HPes is roman8 and 'fi_FI.88591' was ISO-8859-1. Other unixes use ISO-8859-1 for 'fi'.) Following mapping does sense on IRIX: POSIX ISO-8859-1 C US-ASCII (or ISO-8859-1) ar ISO-8859-6 ar_AA ISO-8859-6 bg ISO-8859-5 bg_BG ISO-8859-5 cs ISO-8859-2 cs_CS ISO-8859-2 cz ISO-8859-2 cz_CZ ISO-8859-2 da ISO-8859-1 da_DK ISO-8859-1 de ISO-8859-1 de_DE ISO-8859-1 de_AT ISO-8859-1 de_CH ISO-8859-1 el ISO-8859-7 el_GR ISO-8859-7 en ISO-8859-1 en_AU ISO-8859-1 en_CA ISO-8859-1 en_US ISO-8859-1 es ISO-8859-1 es_ES ISO-8859-1 es_AR ISO-8859-1 es_MX ISO-8859-1 fi ISO-8859-1 fi_FI ISO-8859-1 fr ISO-8859-1 fr_BE ISO-8859-1 fr_CA ISO-8859-1 fr_CH ISO-8859-1 fr_FR ISO-8859-1 hr ISO-8859-2 hr_HR ISO-8859-2 hu ISO-8859-2 hu_HU ISO-8859-2 is ISO-8859-1 is_IS ISO-8859-1 it ISO-8859-1 it_IT ISO-8859-1 it_CH ISO-8859-1 iw ISO-8859-8 iw_IL ISO-8859-8 mk ISO-8859-5 mk_MK ISO-8859-5 nl ISO-8859-1 nl_BE ISO-8859-1 nl_NL ISO-8859-1 no ISO-8859-1 no_NO ISO-8859-1 pl ISO-8859-2 pl_PL ISO-8859-2 pt ISO-8859-1 pt_PT ISO-8859-1 pt_BR ISO-8859-1 ro ISO-8859-2 ro_RO ISO-8859-2 ru ISO-8859-5 ru_SU ISO-8859-5 sh ISO-8859-2 sh_YU ISO-8859-2 sk ISO-8859-2 sk_SK ISO-8859-2 sl ISO-8859-2 sl_CS ISO-8859-2 sp ISO-8859-5 sp_YU ISO-8859-5 sv ISO-8859-1 sv_SE ISO-8859-1 tr ISO-8859-9 tr_TR ISO-8859-9 (*) > I personaly use PC (cp866 for display charset) and the remote terminal > running lynx have LOCALE at "ru_RU.KOI8-R" what should lynx do here? > Probably set language support only if locale match display charset? Hmm. Locale using KOI8-R gots probably gives wrong result for ctype(3) routines if character set iused is actually cp866. / Kari Hurtta (*) I have omitted following from this list: ja eucJP ja_JP eucJP ja_JP.EUC eucJP ja_JP.ujis eucJP ja_JP.eucJP eucJP ko eucKR ko_KR eucKR ko_KR.euc eucKR th_TH TIS620 zh eucCN zh_CN eucCN zh_CN.ugb eucCN zh_TW eucTW zh_TW.ucns eucTW From owner-lynx-dev@sig.net Thu Nov 19 12:04:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA09044 for ; Thu, 19 Nov 1998 12:04:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA19241; Thu, 19 Nov 1998 10:43:27 -0600 (CST) Date: Thu, 19 Nov 1998 10:45:42 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1435 Lines: 32 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > > As things are presently: > > > Two sessions, A and B are running. Both load the same set of cookies > > from COOKIE_FILE. > > > Session A gets a new cookie from some site, then exits, writing all > > the original cookies and the new cookie to COOKIE_FILE. > > > Session B quits, overwriting COOKIE_FILE with all the original > > cookies, but blowing away the new cookie that session A received. > > > So here's my thought -- prior to writing cookies in memory to COOKIE_FILE, > > Lynx should *reread* COOKIE_FILE, ignoring any cookies that are already in > > memory, but adding cookies from the file that are not in memory. > > > The only thing coming to mind so far that could be a problem here would be > > getting two cookies with the same 'name' attribute from a server in two > > different sessions (two unique identifiers from advertising sites?), in > > which case the one which is written to COOKIE_FILE first (thus read into > > memory in the other Lynx session, overwriting the existing one) will be > > maintained, and the others dropped. > > Remote server may change cookie expiration date, > which date should be correct from session A or from session B? I suggest that merging cookies from two sessions while they are running is a bad idea. Cookies are session identifiers, they are often used to tell two sessions apart, right? Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:09:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA09493 for ; Thu, 19 Nov 1998 12:09:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA20050; Thu, 19 Nov 1998 10:45:26 -0600 (CST) Date: Thu, 19 Nov 1998 10:47:38 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too 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: 447 Lines: 13 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > 18-Nov-98 05:11 Klaus Weide wrote: > > > You can't have the title unless lynx already has already seen it recently. > > (In the same session. Unless someone adds a "permanent history list".) > ^^^^^^^^^^^^^^^^^^^^^^ > No, "permanent Visited Links" instead. I should have said: what other browsers call a permanent history list (or similar). Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:11:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA09818 for ; Thu, 19 Nov 1998 12:11:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA21349; Thu, 19 Nov 1998 10:48:52 -0600 (CST) Date: Thu, 19 Nov 1998 10:50:14 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 499 Lines: 13 On Wed, 18 Nov 1998, brian j. pardy wrote: > With the way I have things up there, whichever copy of Lynx is exited first > will be the session with the cookie that is saved. > > So it's pretty much an even shot either way. I don't like this, and can't > really think of a way to do handle this without (for example) timestamping > individual cookies (possibly with comments in the cookie file?). Give each session its own cookie file, and merge them (if you wish) after they are done? Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:24:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA10780 for ; Thu, 19 Nov 1998 12:24:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA27276; Thu, 19 Nov 1998 11:02:35 -0600 (CST) From: Philip Webb Message-Id: <199811191703.MAA13666@chass.utoronto.ca> Subject: lynx-dev refer(r)er headers (was wire.ap.org) To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 12:03:25 -0500 (EST) In-Reply-To: from "Klaus Weide" at Nov 19, 98 10:23:39 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: 2208 Lines: 39 981119 Klaus Weide wrote: > On Thu, 19 Nov 1998, Philip Webb wrote: >> note to lynx-dev generally: entering the former URL got me the JS page, >> but when i entered \ then \ again to recover the rendered page, >> i got a page consisting of 2 frame URLs, incl the latter above, >> whence i was able to goto some real information. >> i've never before encountered a situation >> in which 2 \'s take me to a different rendered page. > When you first goto the page, Lynx doesn't send a Referer: header. > After that, when you do '\' (SOURCE), then it does. > The server is sending a different page depending on that. > In other words, it does negotiation on the Referer header. > It is at least questionable whether lynx should send a Referer header > in this situation at all. Apparently it doesn't when RELOAD is used. > The behavior may have changed from previous versions, > or the configuration file settings may be different. > This is from RFC 2068: > The Referer[sic] request-header field allows the client to specify, > for the server's benefit, the address (URI) of the resource from > which the Request-URI was obtained (the "referrer", although the > header field is misspelled.) The Referer request-header allows a > server to generate lists of back-links to resources for interest, > logging, optimized caching, etc. It also allows obsolete or mistyped > links to be traced for maintenance. The Referer field MUST NOT be > sent if the Request-URI was obtained from a source that does not have > its own URI, such as input from the user keyboard. if i understand you & RFC 2068 correctly, Lynx shouldn't be sending a Refer(r)er header when the request is generated by \ , since there is no source with a URI in that case. it really is good to have you back (big grin): did you spend the 347 days having your brain cells individually sharpened? just try not to intimidate us all too much ... -- ========================,,============================================ 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 Nov 19 12:38:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA11670 for ; Thu, 19 Nov 1998 12:38:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA01820; Thu, 19 Nov 1998 11:13:01 -0600 (CST) Date: Thu, 19 Nov 1998 11:15:14 -0600 (CST) From: Klaus Weide To: Lynx Development Subject: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) In-Reply-To: <199811181949.OAA04935@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: 729 Lines: 23 On Wed, 18 Nov 1998 dickey@clark.net wrote: > 1998-11-18 (2.8.2dev.4) [ ... ] > New bindings: > ^B = LYE_BACK cursor backwards > ^F = LYE_FORW cursor forwards > ^K = LYE_DELEOL delete to end-of-line > ^T = LYE_DELNW delete next word > ^X = LYE_DELPW delete previous word > ^^ = LYE_UPPER upper case line (not active when kbd-layout binding is) > ^_ = LYE_LOWER lower case line Would it be reasonable to have ^U behave like the readline default (instead of erasing the whole line), i.e. (from the bash man page) unix-line-discard (C-u) Kill backward from point to the beginning of the line. I would personally prefer that behavior. Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:42:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA12239 for ; Thu, 19 Nov 1998 12:42:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA28393; Thu, 19 Nov 1998 11:05:19 -0600 (CST) Date: Thu, 19 Nov 1998 11:07:34 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question #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: 971 Lines: 25 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > I personaly use PC (cp866 for display charset) and the remote terminal > running lynx have LOCALE at "ru_RU.KOI8-R" That means that you are using the wrong LOCALE, you should be using ru_RU.CP866 or other programs using LOCALE will also make wrong assumptions. But then programs may make wrong assumptions about the character encoding if filenames or file contents. Is the locale concept at all flexible enough to handle the possibility that the filesystem character encoding may be different from the display character encoding? If not, does the character encoding implied by the locale correspond conceptually to lynx's -assume_local_charset or its display character set or something else? > what should lynx do here? > Probably set language support only if locale match display charset? Or translate all the strings from (e.g.) one Cyrillic charset to another Cyrillic charset before displaying them? Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:57:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA13141 for ; Thu, 19 Nov 1998 12:57:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA09309; Thu, 19 Nov 1998 11:30:59 -0600 (CST) Date: Thu, 19 Nov 1998 11:33:11 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 2944 Lines: 69 On Wed, 18 Nov 1998, Leonid Pauzner wrote: > > That is exactly what I mean in another words (much clear here). > but see near the bottom. > > 18-Nov-98 08:14 Klaus Weide wrote: > > complete use all > > semantic <----------------------------------|-------> cached data > > transparency | forever > > Lynx in general > > [...] > > There are several "modes" of going to a page: > > 1) explicit reload: ^R, 'x' > > 2) '*', '\', '[', '"', ^V, etc. > > 3) form submissions (POST) > > 4) following a normal link, entering an address with 'g' etc.; default > > 5) going back in history: either left arrow, or link from History Page > [...] > > > If the new rawbyte cache never gets used for requests other than mode 2, > > then no change is needed in the rules for when to make a new request, > > and no If-Modified-Since/Etag implementation is needed to preserve the > > current behavior. IMS/Etag/304 could still be implemented later, but > > that is then a separate problem. (It could also already be implemented > > already now, for the existing rendered-doc cache, [except for the > > "language confusion" problem,] which shows that it is separate.) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^?? I meant the confusing flags the mainloop() and others (for example in LYHistory.c) use to communicate their requirements w.r.t. caching to the lower-lever functions. > > But it DOES seem wasteful to keep raw data if in most cases we won't > > use them. But: > > B. It can be greatly restricted what documents get entered into the > > cache in the first place. We have a choice of > > - Caching everything received. > > - Caching all text/html, maybe with further restrictions based > > on URL, method, etc. > also restrictions on file://localhost which always available > > - Require explicit user action. Maybe a special "Enter cache" key, > > meaning "I am going to want this text reparsed, so start caching > > it". > ??? > > - When '\' is pressed the first time for the current text, we mark > > if for rawbyte caching. There could be a confirmation question. > > That means at least two network request are needed, but after that > > cached data is used. > ??? I am not sure what your question is. Can you explain? [ ...] > But I think "mode 2" need no confirmation in any case: > every text/plain _rendered_ document should be cached in rawdata > if it currently cached in rendered form, otherwise fall back > to the present behaviour (no rawdata cacheing at all). Maybe. But I may not want that if the document is big (even if I want it for some documents). > Of cause, rawdata cache may be larger than rendered cache. Do you mean more documents, or do you mean more bytes for each document? Klaus From owner-lynx-dev@sig.net Thu Nov 19 12:59:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA13422 for ; Thu, 19 Nov 1998 12:59:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA06690; Thu, 19 Nov 1998 11:24:53 -0600 (CST) Date: Thu, 19 Nov 1998 09:27:01 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1491 Lines: 38 On Thu, 19 Nov 1998, Klaus Weide wrote: > On Wed, 18 Nov 1998, brian j. pardy wrote: > > > With the way I have things up there, whichever copy of Lynx is exited first > > will be the session with the cookie that is saved. > > > > So it's pretty much an even shot either way. I don't like this, and can't > > really think of a way to do handle this without (for example) timestamping > > individual cookies (possibly with comments in the cookie file?). > > Give each session its own cookie file, and merge them (if you wish) after > they are done? That can be done, probably best using temp files as is being done for downloaded files. However, that still doesn't do anything for us to decide which cookie to keep when merging the files if we have >=2 identical domain/name/path cookies with different values. Example: Session1 has a cookie with 'uid=foo' name=value pair in it. Session2 has a cookie with 'uid=foo' name=value pair. Session2 goes to the site that sent the uid=bar cookie, and uses their 'logout' function, which nulls out the cookie (thus deleting it), and then the user logs in again as a different user, causing the site to send a 'uid=bar' name=value pair. So now, upon each session's exit, they will write differing cookies to their individual cookie files. How to reconcile which one is worth keeping when merging them? -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Thu Nov 19 13:11:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA14466 for ; Thu, 19 Nov 1998 13:11:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA15869; Thu, 19 Nov 1998 11:46:18 -0600 (CST) Date: Thu, 19 Nov 1998 23:00:38 +0530 From: "K.R.Shamasundar" To: lynx-dev@sig.net Subject: lynx-dev Request for help(Contd.) 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: 646 Lines: 26 Hello, This is in continuation with my earlier email. There is a "key remapping" problem. The lynx is writing into stderr, the message, key remapping of 0x00 to RIGHT_LINK failed key remapping of 0x00 to LEFT_LINK failed key remapping of 0x00 to DO_NOTHING failed I had enabled these keys in lynx.cfg file by removing the hashes. The message is coming from, file : src/LYReadCFG.c which in turn can be traced to "LYKeymap.c" file : routine - remap The problem may be with our local system. But, I am using lynx browsers of lower versions without any problem, on the same system. Please help me solve the problem. Shamasundar. From owner-lynx-dev@sig.net Thu Nov 19 13:22:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA15460 for ; Thu, 19 Nov 1998 13:22:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA18761; Thu, 19 Nov 1998 11:53:02 -0600 (CST) Date: Thu, 19 Nov 1998 11:55:14 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.3 In-Reply-To: <199811190206.TAA19071@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: 880 Lines: 27 On Wed, 18 Nov 1998 pg@sweng.stortek.com wrote: > Hurrah! By dev.4, this compiles out-of-the-box and runs on OS/390. (Well, > nearly OOTB. I have to knock off a couple rough edges, mentioned here > previously.) > > "preliminary"? Well, I haven't even attempted testing gopher, wais, unicode, > lots of fringe stuff. It may be difficult to find servers to test them, especiall wais which seems quite dead (as an URL access scheme anyway). > Welcome back Klaus. I understand you're a character set manipulation expert. That's exaggerating. > I guess I've added a new dimension of complexity with the possibility of > a host that doesn't run in ASCII. And it actually works? Amazing... I haven't looked at dev.4 at all to see what you had to do, but I'm curious. The only EBCDIC system I have some experience with is VM/CMS, and that was quite a while ago. Klaus From owner-lynx-dev@sig.net Thu Nov 19 13:31:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA16302 for ; Thu, 19 Nov 1998 13:31:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA15402; Thu, 19 Nov 1998 11:45:12 -0600 (CST) Date: Thu, 19 Nov 1998 11:47:23 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Request for Comment: partial display and refresh In-Reply-To: <199811182157.QAA02850@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: 486 Lines: 21 On Wed, 18 Nov 1998 dickey@clark.net wrote: > bottom line is that someone will have to take the time to trace it and > see where the code's causing a refresh (if I could make a scenario on > local testing, I'd have done it by now -- but online testing is very > slow). Basic ncurses question: is the following sequence _supposed_ to cause a screen repainting? draw on stdscr (as lynx does) refresh() erase() draw exactly same data again on stdscr refresh() Klaus From owner-lynx-dev@sig.net Thu Nov 19 14:24:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA20036 for ; Thu, 19 Nov 1998 14:24:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA11120; Thu, 19 Nov 1998 12:48:45 -0600 (CST) Date: Thu, 19 Nov 98 13:49:53 EST From: "Lloyd G. Rasmussen" Message-Id: <61995.lras@loc.gov> X-Minuet-Version: Minuet1.0_Beta_18A X-POPMail-Charset: English To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2267 Lines: 53 On Thu, 19 Nov 1998 09:27:01 -0800 (PST), brian j. pardy wrote: >On Thu, 19 Nov 1998, Klaus Weide wrote: > >> On Wed, 18 Nov 1998, brian j. pardy wrote: >> >> > With the way I have things up there, whichever copy of Lynx is exited first >> > will be the session with the cookie that is saved. >> > >> > So it's pretty much an even shot either way. I don't like this, and can't >> > really think of a way to do handle this without (for example) timestamping >> > individual cookies (possibly with comments in the cookie file?). >> >> Give each session its own cookie file, and merge them (if you wish) after >> they are done? > >That can be done, probably best using temp files as is being done for >downloaded files. > >However, that still doesn't do anything for us to decide which cookie to >keep when merging the files if we have >=2 identical domain/name/path >cookies with different values. > >Example: > >Session1 has a cookie with 'uid=foo' name=value pair in it. >Session2 has a cookie with 'uid=foo' name=value pair. > >Session2 goes to the site that sent the uid=bar cookie, and uses their >'logout' function, which nulls out the cookie (thus deleting it), and >then the user logs in again as a different user, causing the site to send >a 'uid=bar' name=value pair. > >So now, upon each session's exit, they will write differing cookies to >their individual cookie files. How to reconcile which one is worth keeping >when merging them? If a single user runs multiple simultaneous Lynx sessions, he/she deserves to have the cookies mixed up, but only in his/her workspace. If multiple users are running one copy of Lynx, their cookies should be kept separate. If they are going to be persistent cookies, they should be persistently separate, one file per user, I would think. If this is an anonymous site, persistent cookies are probably a bad idea, but the nonpersistent variety would still be useful. That's my two cents. -- Lloyd Rasmussen Senior Staff Engineer, Engineering Section National Library Service for the Blind and Physically Handicapped Library of Congress 202-707-0535 (work) lras@loc.gov http://www.loc.gov/nls/ (home) lras@sprynet.com http://home.sprynet.com/sprynet/lras/ From owner-lynx-dev@sig.net Thu Nov 19 14:43:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA21524 for ; Thu, 19 Nov 1998 14:42:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA21860; Thu, 19 Nov 1998 13:15:11 -0600 (CST) Date: Thu, 19 Nov 1998 13:17:25 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 2394 Lines: 54 On Thu, 19 Nov 1998, Ryan Hung wrote: > I have just rejoined the list after a long absence, so I am unsure whether > this issue has been addressed (a brief search on the archives yielded > nothing). Basically, I have observed that in Lynx >2.8.1 (up to > 2.8.2dev.4), file://localhost/~ gets expanded as, e.g.: > file://localhost//home/username. This means that %p for DIRED_MENU > commands is incorrect, breaking operations like changing file permissions. > I located what seems to be the relevant section in LYGetFile.c (line 587 > in 2.8.2dev.4), but don't understand it well enough to determine whether > this is buggy code. I see the same in 2.8.1rel.2. There are actually at least two problems. Only in combination do they prevent changing file permissions from working: 1) the additional slash in the URL 2) The functions in LYLocal.c do the wrong thing with the strings they get. In this case permit_location() gets passed "//home/username", which it passed to HTfullURL_toFile, which is a macro to a call of HTnameOfFile_WWW() [in HTFile.c]. HTfullURL_toFile() is inappropriate here. It treats the string as a relative URL (so that "home" is seen as the host part of an URL) which it isn't. It also tries to URL-unescape the string which is also inappropriate: See what happens for a file named "%backup%~". Earlier versions of LYLocal.c didn't do all this. For example permit_location() worked for filepaths with duplicate slashes (which are just ignored under Unix) and for filenames with "%". I suggest reverting LYLocal.c back to a previous version that is better behaved, or changing the new macros and functions there to something appropriate. Note that permit_location() should always get a filename or file path as its srcpath argument, not a URL. The code if (strncmp(srcpath, "file://localhost", 16) == 0) srcpath += 16; which appears in previous versions may have been misleading because if makes one think otherwise. But AFAIK that test would normally never apply. I just left it in when I went through LYLocal.c a long time ago. I thought someone who had put it there a still longer time ago might have had a still valid reason for it. But it didn't seem to get used at least with the usual DIRED_MENU rules. (The same may apply to many or most functions in LYLocal.c.) Klaus From owner-lynx-dev@sig.net Thu Nov 19 15:20:58 1998 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA23631 for ; Thu, 19 Nov 1998 15:20:51 -0500 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 PAA28558 for ; Thu, 19 Nov 1998 15:20:36 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA01038; Thu, 19 Nov 1998 13:35:52 -0600 (CST) Date: Thu, 19 Nov 1998 13:38:07 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev refer(r)er headers (was wire.ap.org) In-Reply-To: <199811191703.MAA13666@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: 2118 Lines: 44 On Thu, 19 Nov 1998, Philip Webb wrote: > > This is from RFC 2068: > > The Referer[sic] request-header field allows the client to specify, > > for the server's benefit, the address (URI) of the resource from > > which the Request-URI was obtained (the "referrer", although the > > header field is misspelled.) The Referer request-header allows a > > server to generate lists of back-links to resources for interest, > > logging, optimized caching, etc. It also allows obsolete or mistyped > > links to be traced for maintenance. The Referer field MUST NOT be > > sent if the Request-URI was obtained from a source that does not have > > its own URI, such as input from the user keyboard. > > if i understand you & RFC 2068 correctly, Lynx shouldn't be sending > a Refer(r)er header when the request is generated by \ , > since there is no source with a URI in that case. Probably. Although one could interpret "address of the resource from which the Request-URI was obtained" in a way that includes what Lynx does. If \ is supposed to have "history" character, as we seem to agree on in the caching threads, then Lynx should send the same Referer header it was using the first time. (That is, as long as we don't have the source cache to avoid a new request anyway.) But we don't do that for "real" history requests either, (left arrow or history list), because we don't try to remember the Referer that was in effect when the document was requested earlier. I guess the point is that a Referer header may or may not be sent for any request, depending on client settings and how exactly the user "got there"; and that it is unwise for site authors to use it for navigation purposes. But of course some people do it anyway. > it really is good to have you back (big grin): > did you spend the 347 days having your brain cells individually sharpened? No, most of the time away from the Internet and the braincells are deteriorating but thanks for asking. :) > just try not to intimidate us all too much ... Don't be intimidated. It's more talking than doing anyway. Klaus From owner-lynx-dev@sig.net Thu Nov 19 15:22:31 1998 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA23727 for ; Thu, 19 Nov 1998 15:22:26 -0500 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 PAA28291 for ; Thu, 19 Nov 1998 15:00:08 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA27479; Thu, 19 Nov 1998 13:28:23 -0600 (CST) Date: Thu, 19 Nov 1998 11:30:26 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions In-Reply-To: <61995.lras@loc.gov> 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: 2905 Lines: 65 On Thu, 19 Nov 1998, Lloyd G. Rasmussen wrote: > On Thu, 19 Nov 1998 09:27:01 -0800 (PST), > brian j. pardy wrote: > > >On Thu, 19 Nov 1998, Klaus Weide wrote: > > > >> On Wed, 18 Nov 1998, brian j. pardy wrote: > >> > >> > With the way I have things up there, whichever copy of Lynx is exited first > >> > will be the session with the cookie that is saved. > >> > > >> > So it's pretty much an even shot either way. I don't like this, and can't > >> > really think of a way to do handle this without (for example) timestamping > >> > individual cookies (possibly with comments in the cookie file?). > >> > >> Give each session its own cookie file, and merge them (if you wish) after > >> they are done? > > > >That can be done, probably best using temp files as is being done for > >downloaded files. > > > >However, that still doesn't do anything for us to decide which cookie to > >keep when merging the files if we have >=2 identical domain/name/path > >cookies with different values. > > > >Example: > > > >Session1 has a cookie with 'uid=foo' name=value pair in it. > >Session2 has a cookie with 'uid=foo' name=value pair. > > > >Session2 goes to the site that sent the uid=bar cookie, and uses their > >'logout' function, which nulls out the cookie (thus deleting it), and > >then the user logs in again as a different user, causing the site to send > >a 'uid=bar' name=value pair. > > > >So now, upon each session's exit, they will write differing cookies to > >their individual cookie files. How to reconcile which one is worth keeping > >when merging them? > > If a single user runs multiple simultaneous Lynx sessions, he/she > deserves to have the cookies mixed up, but only in his/her workspace. > If multiple users are running one copy of Lynx, their cookies should > be kept separate. If they are going to be persistent cookies, they > should be persistently separate, one file per user, I would think. If > this is an anonymous site, persistent cookies are probably a bad idea, > but the nonpersistent variety would still be useful. That's my two > cents. Oh, yes, I'm talking about multiple simultaneous Lynx sessions by a single user, not more than one instance invoked by different users. I would *like* to have Lynx do something to protect an individual user if he/she spawns more than one Lynx process (I know I do it enough, but I haven't had many problems because there are only about three sites I accept cookies from) because it doesn't seem right to have cookie storage be based only on the order each instance is exited. Netscape handles this by disabling writing to the bookmarks/cookie/etc files when more than one instance is running -- I certainly don't think this is an acceptable choice. -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Thu Nov 19 15:54:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA26028 for ; Thu, 19 Nov 1998 15:54:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA20284; Thu, 19 Nov 1998 14:22:40 -0600 (CST) From: dickey@clark.net Message-Id: <199811192024.PAA08198@shell.clark.net> Subject: Re: lynx-dev Request for Comment: partial display and refresh To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 15:24:56 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 19, 98 11:47:23 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: 786 Lines: 27 > > On Wed, 18 Nov 1998 dickey@clark.net wrote: > > > bottom line is that someone will have to take the time to trace it and > > see where the code's causing a refresh (if I could make a scenario on > > local testing, I'd have done it by now -- but online testing is very > > slow). > > Basic ncurses question: is the following sequence _supposed_ to cause > a screen repainting? iirc, yes (we went through this sometime last year - John Davis' slang changes did not work that way, but curses/ncurses do that unless you modify the behavior using clearok). > draw on stdscr (as lynx does) > refresh() > erase() > draw exactly same data again on stdscr > refresh() > > > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Thu Nov 19 16:32:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA28957 for ; Thu, 19 Nov 1998 16:32:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA05703; Thu, 19 Nov 1998 14:59:35 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811192101.OAA28411@sanitas> Subject: Re: lynx-dev lynx2.8.2dev.3 To: lynx-dev@sig.net Date: Thu, 19 Nov 1998 14:01:11 -0700 (MST) In-Reply-To: from "Klaus Weide" at Nov 19, 98 11:55: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: 926 Lines: 34 In a recent note, Klaus Weide said: > Date: Thu, 19 Nov 1998 11:55:14 -0600 (CST) > > I haven't looked at dev.4 at all to see what you had to do, but I'm > curious. The only EBCDIC system I have some experience with is VM/CMS, > and that was quite a while ago. > It was a 2000 line context diff patch, still available at: Linkname: Lynx for OS/390 URL: http://www.nyx.net/~pgilmart/lynx.os390.html Link that you currently have selected Linkname: lynx.patch.os390.zip URL: http://www.nyx.net/~pgilmart/lynx.patch.os390.zip Discussed in this list in late October. Look for "EBCDIC" and "Autoconf in the subject. You can find most of it with: egrep 'EBCDIC TOASCII FROMASCII NOT_ASCII IBM_1047 CH_DEL CH_ESC CH_HICTL CH_NBSP CH_SHY' `find lynx2-8-2` The best news was that there were absolutely no changes necessary to deal with curses. -- gil From owner-lynx-dev@sig.net Thu Nov 19 18:35:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA04971 for ; Thu, 19 Nov 1998 18:35:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA27392; Thu, 19 Nov 1998 17:07:46 -0600 (CST) Date: Thu, 19 Nov 1998 18:09:23 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811191809.AA11070@cas.org> Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) In-Reply-To: of Thu, 19 Nov 1998 11:15:14 -0600 (CST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 441 Lines: 10 If this is something open for discussion I kind of like: ^u - delete from current insert point to the beginning of the line ^w - delete previous word ^x - delete entire line -- 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 Nov 19 18:43:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA05623 for ; Thu, 19 Nov 1998 18:43:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA03493; Thu, 19 Nov 1998 17:23:48 -0600 (CST) Date: Thu, 19 Nov 1998 15:25:20 -0800 (PST) From: Ryan Hung To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 2554 Lines: 69 On Thu, 19 Nov 1998, Klaus Weide wrote: > I see the same in 2.8.1rel.2. Yeah, I guess I should have said >=2.8.1. > There are actually at least two problems. Only in combination do > they prevent changing file permissions from working: > > 1) the additional slash in the URL > 2) The functions in LYLocal.c do the wrong thing with the strings > they get. In this case permit_location() gets passed > "//home/username", which it passed to HTfullURL_toFile, which > is a macro to a call of HTnameOfFile_WWW() [in HTFile.c]. > HTfullURL_toFile() is inappropriate here. It treats the > string as a relative URL (so that "home" is seen as the host > part of an URL) which it isn't. It also tries to URL-unescape > the string which is also inappropriate: See what happens > for a file named "%backup%~". > > Earlier versions of LYLocal.c didn't do all this. For example > permit_location() worked for filepaths with duplicate slashes > (which are just ignored under Unix) and for filenames with "%". > > I suggest reverting LYLocal.c back to a previous version that is > better behaved, or changing the new macros and functions there to > something appropriate. Hmm, I'll see if that works. Any idea why adding a few lines to LYUtils.c under LYTrimRelFromAbsPath() doesn't seem to do the trick: Added at Line 4569: while (cp[1] == '/') { if (cp[2] == '/') { /* * Skip over first "/" of a "//". - rhung */ cp += 1; } else { /* Finished. - rhung * */ break; } } After all, the "if (url_type == FILE_URL_TYPE)" section in LYGetFile.c seems to call LYTrimRelFromAbsPath(). > Note that permit_location() should always get a filename or file > path as its srcpath argument, not a URL. The code > > if (strncmp(srcpath, "file://localhost", 16) == 0) > srcpath += 16; > > which appears in previous versions may have been misleading because > if makes one think otherwise. But AFAIK that test would normally Yeah, that's what %p in lynx.cfg should be doing, giving the path. It's just that it gives the wrong path, "/username" rather than "/home/username". Ryan. _/ \__/ \__/ \__/ \__/ \__/ \__/ \__/rhung@vcn.bc.ca__/ \__/ \__/ \_Apoptosis=programmed cell death/ \__/ \rwhung@interchange.ubc.ca_/ \__ _/ --you can't live without it!/ \__/ \http://www.vcn.bc.ca/people/rhung \__/ \__/ \__/ \__/ \__/ \__/ \__/ \My words Copyright (C) 1998 \__ From owner-lynx-dev@sig.net Thu Nov 19 18:55:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA06469 for ; Thu, 19 Nov 1998 18:55:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA04991; Thu, 19 Nov 1998 17:27:56 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: lynx-dev@sig.net Subject: Re: lynx-dev Request for help(Contd.) In-reply-to: Your message of "Thu, 19 Nov 1998 23:00:38 +0530." 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: 724 Lines: 19 krss@comp.ncl.res.in said: > Hello, This is in continuation with my earlier email. There > is a "key remapping" problem. The lynx is writing into stderr, the > message, > > key remapping of 0x00 to RIGHT_LINK failed key remapping of 0x00 to > LEFT_LINK failed key remapping of 0x00 to DO_NOTHING failed > > I had enabled these keys in lynx.cfg file by removing the hashes. > It doesn't make sense to enable all of them because only one function can be bound to a particular key. The problem is that "remap" returns 0 to indicate failure. Upon success it returns a keycode. There if a slight ambiguity if that keycode happens to be zero also... Anyway, this is just a false alarm, just ignore that message. From owner-lynx-dev@sig.net Thu Nov 19 18:56:13 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA06499 for ; Thu, 19 Nov 1998 18:56:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA01200; Thu, 19 Nov 1998 17:17:50 -0600 (CST) Message-Id: <199811191820.TAA20242@ow2.wins.uva.nl> Date: Thu, 19 Nov 1998 19:20:41 +0100 (MET) From: emoost@wins.uva.nl (Elwin M. Oost) X-Organisation: Faculty of Mathematics, Computer Science, Physics & Astronomy University of Amsterdam Plantage Muidergracht 24 NL-1018 TV Amsterdam The Netherlands X-Phone: +31 20 525 5200 X-Fax: +31 20 525 5101 To: lynx-dev@sig.net Subject: lynx-dev Cookie+PostQuery+Dump_Immediately bug :) X-Sun-Charset: US-ASCII Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 770 Lines: 21 Hi, First off, thank you all for giving Lynx to the community! I _think_ I found a bug in LYCookies.c (Lynx 2.8.1). I wanted to automate post-query'ing a site which redirects Lynx with a 302 (yes, it's Microsoft :) to another page. It uses cookies to save info. Browsing everything went fine, but using post_data Lynx kept losing the cookie. I checked the help rigorously and after that the source to find some switch I had forgotten, but I _think_ I found a bug there. store_cookie (LYCookies.c) skips walking through domain_list if dump_output_immediately=TRUE. However, 'de' which holds the domain_entry is initialized during this walk. As such, HTConfirmCookie (HTAlert.c) receives an empty 'de' and will reject it. Hope I have not missed something, Elwin From owner-lynx-dev@sig.net Thu Nov 19 19:12:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA08021 for ; Thu, 19 Nov 1998 19:12:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA12904; Thu, 19 Nov 1998 17:51:19 -0600 (CST) Date: Fri, 20 Nov 1998 08:54:59 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811192354.IAA29784@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1015 Lines: 25 > http://www.slcc.edu/lynx/po. Hope you don't mind. What do you Probably should stay on my server until I get word from FSF that they have accepted my disclaimer. (I sent it airmail last week.) > think about storing bz2 vs. gz vs. plain po text files? I I think gz is better since it is more widely known. Changing the subject, I cannot get my mailcap/mime.types entry to work for bzip2-compressed files. Precisely, I cannot get Lynx to use bzip2 -d to decompress the file, and then pass the result to most for display. Works fine when I have it gzipped. Does anyone have working mailcap/mime.types entries, or lynx.cfg VIEWER/SUFFIX entries, for decompressing bzip2 files and passing the decompressed stream to a reader like most, or even to lynx? > changed the lynx.pot back to lynx.po since ".pot" caused SLCC Yes, originally I, too, thought the .pot file was something special, when it's really just something to put on the stove, and entirely unnecessary from the translator's point of view. __Henry From owner-lynx-dev@sig.net Thu Nov 19 20:41:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA14755 for ; Thu, 19 Nov 1998 20:41:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA10979; Thu, 19 Nov 1998 19:21:56 -0600 (CST) Date: Thu, 19 Nov 1998 17:24:15 -0800 (PST) From: "Eduardo Chappa L." To: lynx-dev@sig.net Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 1043 Lines: 26 On Thu, 19 Nov 1998, Klaus Weide wrote: :)On Wed, 18 Nov 1998, brian j. pardy wrote: :) :)> With the way I have things up there, whichever copy of Lynx is exited first :)> will be the session with the cookie that is saved. :)> :)> So it's pretty much an even shot either way. I don't like this, and can't :)> really think of a way to do handle this without (for example) timestamping :)> individual cookies (possibly with comments in the cookie file?). :) :)Give each session its own cookie file, and merge them (if you wish) after :)they are done? :) :) Klaus :) I don't know if this comment is useful or not, but I use my Lynx_bookmarks file is actually my Netscape file. It occurs sometimes that I add/delete a bookmark in lynx while Netscape(3.04) is still opened. A few minutes later I receive a message from Netscape telling me that my bookmark file has changed and asks me if I want to reload it. Is something like that possible with cookies or am I completely lost ? Eduardo http://www.math.washington.edu/~chappa/personal.html From owner-lynx-dev@sig.net Thu Nov 19 23:03:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA25276 for ; Thu, 19 Nov 1998 23:03:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA23856; Thu, 19 Nov 1998 21:42:38 -0600 (CST) Message-ID: <19981119194447.B31352@psnw.com> Date: Thu, 19 Nov 1998 19:44:47 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 Mail-Followup-To: lynx-dev@sig.net References: <199811192354.IAA29784@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811192354.IAA29784@ews07.nara.kindai.ac.jp>; from "Nelson Henry Eric" on Fri, Nov 20, 1998 at 08:54:59AM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 7:34pm up 2 days, 3:07, 6 users, load average: 1.01, 1.05, 1.01 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 746 Lines: 17 Nelson Henry Eric wrote: [...] > Changing the subject, I cannot get my mailcap/mime.types entry > to work for bzip2-compressed files. Precisely, I cannot get > Lynx to use bzip2 -d to decompress the file, and then pass the > result to most for display. Works fine when I have it gzipped. > > Does anyone have working mailcap/mime.types entries, or lynx.cfg > VIEWER/SUFFIX entries, for decompressing bzip2 files and passing > the decompressed stream to a reader like most, or even to lynx? Can it be that the server is sending improper MIME headers? I know there are a few broken servers that like to try sending (for example) .mp3 files as text/plain... -- If you live in a country run by committee, be on the committee. -- Graham Summer From owner-lynx-dev@sig.net Fri Nov 20 00:23:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA31978 for ; Fri, 20 Nov 1998 00:23:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA10913; Thu, 19 Nov 1998 23:01:46 -0600 (CST) Date: Fri, 20 Nov 1998 14:04:53 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811200504.OAA01564@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1470 Lines: 37 > > Changing the subject, I cannot get my mailcap/mime.types entry to > > work for bzip2-compressed files. Precisely, I cannot get Lynx to > > use bzip2 -d to decompress the file, and then pass the result to > > most for display. Works fine when I have it gzipped. > > > > Does anyone have working mailcap/mime.types entries, or lynx.cfg > > VIEWER/SUFFIX entries, for decompressing bzip2 files and passing the > > decompressed stream to a reader like most, or even to lynx? > > Can it be that the server is sending improper MIME headers? I know It's not just served files, but also files on the localhost that I'm interested in. But to give an example, my own http server gives the following header (analogous to what I have for gzip), but admittedly I'm pretty stupid when it comes to knowing about headers and such. HTTP/1.0 200 Document follows Date: Fri, 20 Nov 1998 04:42:59 GMT Server: NCSA/1.5.2 Last-modified: Fri, 20 Nov 1998 04:38:36 GMT Content-type: text/plain Content-length: 20989 Content-encoding: bzip2 This is for the latest update to the ja.po I did this lunch hour: . My mime.types entries are: application/bzip2 bz2 application/x-bzip2 bz2 and my mailcap entries are: application/bzip2; /usr/local/bin/bzip2 -d %s application/x-bzip2; /usr/local/bin/bzip2 -d %s (the path is correct) I'm sure I've got it wrong, but I just can't figure out where. __Henry From owner-lynx-dev@sig.net Fri Nov 20 01:54:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA06998 for ; Fri, 20 Nov 1998 01:54:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA21921; Fri, 20 Nov 1998 00:35:25 -0600 (CST) Message-ID: <19981119222936.A3266@altern.org> Date: Thu, 19 Nov 1998 22:29:36 -0700 From: Todd Bjorlo To: lynx-dev@sig.net Subject: lynx-dev bug in posting data(?) 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: 703 Lines: 23 Hello, I was attempting to POST data to www.m-w.com, using their dictionary search. After I submit my word to look up, Lynx returns nothing. Here is some more information pertaining to the page and the Lynx I am using: Lynx 2.8.2dev.4 (18 Nov 1998) (development version) - compile time options File that you are currently viewing Linkname: Search URL: http://www.m-w.com/cgi-bin/dictionary Charset: iso-8859-1 (assumed) Server: Apache/1.2.1 Date: Fri, 20 Nov 1998 06:30:41 Post Data: sbook=Dictionary&va=test Post Content Type: application/x-www-form-urlencoded Owner(s): None size: 2 lines mode: normal -- Todd Bjorlo - http://altern.org/todd/ (todd@altern.org) From owner-lynx-dev@sig.net Fri Nov 20 02:16:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA08366 for ; Fri, 20 Nov 1998 02:16:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA23916; Fri, 20 Nov 1998 00:58:07 -0600 (CST) Message-ID: <19981119230025.A1197@psnw.com> Date: Thu, 19 Nov 1998 23:00:25 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev bug in posting data(?) Mail-Followup-To: lynx-dev@sig.net References: <19981119222936.A3266@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981119222936.A3266@altern.org>; from "Todd Bjorlo" on Thu, Nov 19, 1998 at 10:29:36PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 10:55pm up 2 days, 6:28, 6 users, load average: 1.07, 1.04, 1.01 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 947 Lines: 28 Todd Bjorlo wrote: > Hello, I was attempting to POST data to www.m-w.com, > using their dictionary search. After I submit my > word to look up, Lynx returns nothing. Here > is some more information pertaining to the page > and the Lynx I am using: > > > Lynx 2.8.2dev.4 (18 Nov 1998) (development version) - compile time options > > File that you are currently viewing > > Linkname: Search > URL: http://www.m-w.com/cgi-bin/dictionary > Charset: iso-8859-1 (assumed) > Server: Apache/1.2.1 > Date: Fri, 20 Nov 1998 06:30:41 > Post Data: sbook=Dictionary&va=test > Post Content Type: application/x-www-form-urlencoded > Owner(s): None > size: 2 lines > mode: normal I see something similar using 2.8.2dev.3 when submitting the form at too. -- He thinks by infection, catching an opinion like a cold. Every day it's the same thing -- variety. I want something different. From owner-lynx-dev@sig.net Fri Nov 20 02:33:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA09862 for ; Fri, 20 Nov 1998 02:33:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA25295; Fri, 20 Nov 1998 01:12:07 -0600 (CST) Message-ID: <19981119231426.B1197@psnw.com> Date: Thu, 19 Nov 1998 23:14:26 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev NLS tweaks for 282dev4 Mail-Followup-To: lynx-dev@sig.net References: <199811200504.OAA01564@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811200504.OAA01564@ews07.nara.kindai.ac.jp>; from "Nelson Henry Eric" on Fri, Nov 20, 1998 at 02:04:53PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 10:55pm up 2 days, 6:28, 6 users, load average: 1.07, 1.04, 1.01 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1452 Lines: 37 Nelson Henry Eric wrote: > It's not just served files, but also files on the localhost that I'm > interested in. But to give an example, my own http server gives the > following header (analogous to what I have for gzip), but admittedly > I'm pretty stupid when it comes to knowing about headers and such. > > HTTP/1.0 200 Document follows > Date: Fri, 20 Nov 1998 04:42:59 GMT > Server: NCSA/1.5.2 > Last-modified: Fri, 20 Nov 1998 04:38:36 GMT > Content-type: text/plain > Content-length: 20989 > Content-encoding: bzip2 > > This is for the latest update to the ja.po I did this lunch hour: > . > > My mime.types entries are: > application/bzip2 bz2 > application/x-bzip2 bz2 > and my mailcap entries are: > application/bzip2; /usr/local/bin/bzip2 -d %s > application/x-bzip2; /usr/local/bin/bzip2 -d %s > (the path is correct) > > I'm sure I've got it wrong, but I just can't figure out where. It looks (after a quick look) to me that Lynx is doing internal decompression of .gz files, regardless of what mailcap says. Lynx doesn't internally grok bz2, and thus seems to hand off files that don't end in .Z or .gz to an external viewer, without re-rendering their output? Is that what's happening? I surely don't understand this part either... -- "I want to know God's thoughts... the rest are details." - Albert Einstein From owner-lynx-dev@sig.net Fri Nov 20 03:39:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA15214 for ; Fri, 20 Nov 1998 03:39:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA00851; Fri, 20 Nov 1998 02:19:40 -0600 (CST) Date: Fri, 20 Nov 1998 17:22:34 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811200822.RAA02606@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 681 Lines: 20 There are a few messages that, while they do have a reason for being separate, could function just as well if joined. The ones that come to mind are pairs like: Really exit from Lynx? [Y] Really exit from Lynx? [N] Would there be a significant problem if in both situations Really exit from Lynx? [Y/N] were used? There are a few instances like the following: (WAIS Index) WAIS Index: WAIS Index.\n I haven't looked at the code yet, but I suspect the same string could be used in all three situations. Or perhaps only the "WAIS Index" could be within the gettext() call. I'd like a little feedback before I start preparing patches. Am I overlooking something? __Henry From owner-lynx-dev@sig.net Fri Nov 20 03:49:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA15817 for ; Fri, 20 Nov 1998 03:49:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA01741; Fri, 20 Nov 1998 02:30:49 -0600 (CST) Date: Fri, 20 Nov 1998 17:33:53 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811200833.RAA02702@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev How to get bz2 compressed files uncompressed and rendered (not Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 578 Lines: 14 just downloaded) [was Re: lynx-dev NLS tweaks for 282dev4 > It looks (after a quick look) to me that Lynx is doing internal > decompression of .gz files, regardless of what mailcap says. Lynx doesn't That's true now (if you use zlib), but I had very similar entries working when gzip had to be called externally by Lynx. Gzip has a --no-name option (do not save or restore the original name and time stamp), which I think Lynx takes (took?) advantage of. Bzip2 can't do this? > I surely don't understand this part either... Always glad to have a little company :) __Henry From owner-lynx-dev@sig.net Fri Nov 20 05:57:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA24682 for ; Fri, 20 Nov 1998 05:57:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA11926; Fri, 20 Nov 1998 04:39:31 -0600 (CST) From: dickey@clark.net Message-Id: <199811201041.FAA26921@shell.clark.net> Subject: Re: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 05:41:50 -0500 (EST) In-Reply-To: <199811200822.RAA02606@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 20, 98 05:22: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: 978 Lines: 32 > > There are a few messages that, while they do have a reason for > being separate, could function just as well if joined. The > ones that come to mind are pairs like: > Really exit from Lynx? [Y] > Really exit from Lynx? [N] > Would there be a significant problem if in both situations > Really exit from Lynx? [Y/N] > were used? on top of that we need a utility function (on my list) to prompt for yes/no/cancel. > There are a few instances like the following: > (WAIS Index) > WAIS Index: > WAIS Index.\n > I haven't looked at the code yet, but I suspect the same string > could be used in all three situations. Or perhaps only the > "WAIS Index" could be within the gettext() call. that is what I would do - and make the string a #define in LYMessages_en.h > I'd like a little feedback before I start preparing patches. Am > I overlooking something? > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 20 07:13:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA29775 for ; Fri, 20 Nov 1998 07:13:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA18184; Fri, 20 Nov 1998 05:54:48 -0600 (CST) Date: Fri, 20 Nov 1998 13:00:32 +0200 Message-Id: <98112013003251@decus.fr> From: soma_c@decus.fr (Claude SOMA - CNTS) To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in file:// X-VMS-To: SMTP%"lynx-dev@sig.net" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 537 Lines: 11 On Thu, 19 Nov 1998 01:44:41 -0800 (PST) Ryan Hung wrote: >I have just rejoined the list after a long absence, so I am unsure whether >this issue has been addressed (a brief search on the archives yielded >nothing). Basically, I have observed that in Lynx >2.8.1 (up to search on archives whith search engine (altavista ...) don't give any interesting things, indexing for now seen to be dead. you can see some discussion about that in the archive On July search for Subj: Re: lynx-dev searching th archive Claude From owner-lynx-dev@sig.net Fri Nov 20 07:31:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA30764 for ; Fri, 20 Nov 1998 07:31:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA20100; Fri, 20 Nov 1998 06:13:15 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Fri, 20 Nov 1998 07:15:30 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev bug in posting data(?) In-Reply-To: <19981119222936.A3266@altern.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: 1055 Lines: 29 On Thu, 19 Nov 1998, Todd Bjorlo wrote: > Hello, I was attempting to POST data to www.m-w.com, using their > dictionary search. After I submit my word to look up, Lynx returns > nothing. Here is some more information pertaining to the page and the Lynx > I am using: > > > Lynx 2.8.2dev.4 (18 Nov 1998) (development version) - compile time options > > File that you are currently viewing > > Linkname: Search > URL: http://www.m-w.com/cgi-bin/dictionary > Charset: iso-8859-1 (assumed) > Server: Apache/1.2.1 > Date: Fri, 20 Nov 1998 06:30:41 > Post Data: sbook=Dictionary&va=test ^ It's the "s" that lynx is adding to the begining of post-data. 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 Nov 20 08:21:13 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA01822 for ; Fri, 20 Nov 1998 08:21:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA21476; Fri, 20 Nov 1998 06:25:50 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Fri, 20 Nov 1998 07:28:06 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) In-Reply-To: <9811191809.AA11070@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: 782 Lines: 20 On Thu, 19 Nov 1998, Larry W. Virden wrote: > If this is something open for discussion I kind of like: > > ^u - delete from current insert point to the beginning of the line > ^w - delete previous word > ^x - delete entire line In all Unix systems I access, running Solaris 2.5/ksh and FreeBSD/tcsh, ^U deletes the whole line in the system prompt. I would like lynx to keep ^U as "delete the whole line". 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 Nov 20 08:54:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA03979 for ; Fri, 20 Nov 1998 08:54:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA29951; Fri, 20 Nov 1998 07:33:11 -0600 (CST) Date: Fri, 20 Nov 1998 08:34:55 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811200834.AA24077@cas.org> Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) In-Reply-To: of Fri, 20 Nov 1998 07:28:06 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 417 Lines: 8 Okay - I had never tried ^U in ksh emacs mode before -so I didn't know it deleted text after the cursor. I agree that ^U should delete the entire line. -- 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 Nov 20 09:17:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA05285 for ; Fri, 20 Nov 1998 09:17:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA04153; Fri, 20 Nov 1998 07:56:28 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Fri, 20 Nov 1998 16:53:55 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev gettext() question #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: 1246 Lines: 26 > If not, does the character encoding implied by the locale correspond > conceptually to lynx's -assume_local_charset or its display character > set or something else? And how about display charset auto switch? We have few environment variables before running lynx but if the user choose display charset or other settings from 'o'ptions menu they should have a greater priority. And defining assume_local_charset will disable raw 8-bit, right? So lynx have superior support for translation between different codepages but we have no clear understanding about the appropriate interface for user to manipulate with it. I think we should change nothing on this point. >> what should lynx do here? >> Probably set language support only if locale match display charset? > Or translate all the strings from (e.g.) one Cyrillic charset to another > Cyrillic charset before displaying them? Right. But we need to know for sure the gettext's charset and redefine gettext() to enable UC translation in lynx. There is no such problem for iso-8859-1 users (one charset - defferent languages), but do exist for others (including numerous dos/windows charsets for which we usually have no appropriate locale on UNIX. I mean access from remote terminal). From owner-lynx-dev@sig.net Fri Nov 20 09:30:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA06353 for ; Fri, 20 Nov 1998 09:30:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA07897; Fri, 20 Nov 1998 08:11:47 -0600 (CST) Date: Thu, 19 Nov 1998 19:37:34 -0500 (EST) From: Marcus To: Philip Webb cc: lynx-dev@sig.net, Terra Syslo Subject: Re: lynx-dev http://wire.ap.org In-Reply-To: <199811191322.IAA10743@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: 535 Lines: 11 please note when you go to any url in the wire page just by hitting g and typing in the url you will get to the wire welcome page no matter what! this is because the wire is looking at the referring page and if it is not from the wire site it is denying access! Check out my web page! http://www.icubed.com/~marcus25/ don't forget the slash at the end! I am scoreboard king time master and Dana lover! I am chocolate king bacon king and Dana lover! I am king of laziness king of stubbornness and Dana lover! Get the picture? From owner-lynx-dev@sig.net Fri Nov 20 09:43:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA07355 for ; Fri, 20 Nov 1998 09:43:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA07663; Fri, 20 Nov 1998 08:10:58 -0600 (CST) Date: Fri, 20 Nov 1998 02:08:15 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811200208.AA17382@cas.org> Subject: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.com To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 105436 Lines: 2120 I've noticed recently that the cookies in the latest dev support don't work quite right with my.yahoo.com - they worked better in 2.8.1 . For instance, when I try to sign in in my.yahoo.com, I enter my login and password. Regardless of whether I select saving the cookie or not, the first attempt to sign in fails, then seems to work the second time. Next, when I go to mail.yahoo.com, I see the same behavior. Finally, when I go into mail.yahoo.com, and read some mail and select delete, I see the next mail msg, but at the end, all of the mail messages remain. Here's a Lynx trace for the delete action. I don't see any explicit msgs with "warning" or "error" in them. Lynx Trace Log User message: Trace ON! FIXME:SubmitForm SubmitForm: field "TRA" 0 us-ascii OK SubmitForm: name "TRA" 0 us-ascii OK SubmitForm: field "destBox1" 0 us-ascii OK SubmitForm: name "destBox1" 0 us-ascii OK SubmitForm: skipping submit field with name "MV1" for link_name "TRA", not current link. GridText - post_data: sTRA=Delete&destBox1= LYpush[7]: address:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&YY=2039&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&inc=25&num=0&order=down title:Yahoo! Mail getfile: getting http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:f1.mail.yahoo.com HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 4280b0 has hash 83 and address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931' HTAccess: loading document http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName:file: HTParse: result:http HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:f1.mail.yahoo.com HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:http HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:f1.mail.yahoo.com Looking up f1.mail.yahoo.com. HTParseInet: parsing `f1.mail.yahoo.com'. HTParseInet: NSL_FORK child 17463 exited, status 0x0. HTParseInet: Parsed address as port 80, IP address 205.180.60.69 Making HTTP connection to f1.mail.yahoo.com. HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: 1 HTParse: result:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:f1.mail.yahoo.com HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: 1 HTParse: result:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: 1 HTParse: result:py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 relatedName: HTParse: result:f1.mail.yahoo.com LYCookie: Searching for 'f1.mail.yahoo.com:80', '/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931'. Checking cookie 307568 PFUID=cc47f2b83653f7bc068e1000ffffff9d f1.mail.yahoo.com .pathfinder.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 307508 NGUserID=ce0f6758-1267-911472502-1 f1.mail.yahoo.com .foxnews.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 307138 ASPSESSIONIDGGGQGRGJ=PPGOMEABFJEJOCJCOBOFBGCB f1.mail.yahoo.com come.to 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3070c8 Tango_UserReference=A2E5477A737F74B f1.mail.yahoo.com cseng.aw.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 307078 UniqueId=134.243.50.70-911016707-627584-26885 f1.mail.yahoo.com www.cartoonnetwork.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 307028 RCADS=cf018626-3005-910918125-1 f1.mail.yahoo.com .mcng.sjmercury.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306fc8 ASPSESSIONIDQGQGQGOF=EICKDBLDCHCALAPHCDNKNEMK f1.mail.yahoo.com www.hotbot.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306f78 p_uniqid=28DZwe5mPCwWZF0AjB f1.mail.yahoo.com .hotbot.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306ea8 NGUserID=a01000d-300-909833707-1 f1.mail.yahoo.com .miningco.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306ee8 Mint=18862881563528m f1.mail.yahoo.com .miningco.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306f28 TMog=18862881563528m f1.mail.yahoo.com .miningco.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306e58 ASPSESSIONIDGQGGQRSC=PEPDODLAJCGAKKBPOJNKMLFM f1.mail.yahoo.com animation.miningco.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306e08 linkshare=eQTO0AVn1bM-4mcEKw1X8ZP7ruhWf%2FcIKw+1998-10-30/07:42:24 f1.mail.yahoo.com .outpost.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306db8 AV_UID=d3d052cc739f7a f1.mail.yahoo.com .altavista.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306240 YM.Pref=farm%3d1%26silo%3dms1%26v%3dn%26email%3dlvirden%40yahoo.com%26head%3dbrief%26fwd%3dattach%26fontsz%3dnormal%26msgwidth%3d82%26order%3ddown%26inc%3d25%26goto%3dmsg f1.mail.yahoo.com .mail.yahoo.com 1 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306270 YM.Login=id%3d%241%24rm%24JxXK.kgvuHbPNEvny7iP11%26sid%3ds9uiTIX%252bMqeG%250a%26ts%3d%253d%25a6B%257c%25dd%2517%25ed%2597%25da%253f%258b%25c1%25b9 f1.mail.yahoo.com .mail.yahoo.com 1 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 31c030 T=z=iQRV2AiWmV2AidRx12.EJy8NgY2MTc1NjE0MTY- f1.mail.yahoo.com .yahoo.com 1 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3061e0 Y=v=1&n=1scejighn0oed&l=bl8h34d/o&p=m1n1a1s4111b&lg=us f1.mail.yahoo.com .yahoo.com 1 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306140 GeoStitial=911472424 f1.mail.yahoo.com .geocities.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3060b0 uid=lvirden@yahoo.com f1.mail.yahoo.com www.onelist.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3060f0 pid=drzhlF16AHP0Y f1.mail.yahoo.com www.onelist.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 306050 fmval=lvirden@cas.org:90446020 f1.mail.yahoo.com .egroups.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305f70 CFTOKEN=20040 f1.mail.yahoo.com www.macduff.net 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305fc0 CFID=69120 f1.mail.yahoo.com www.macduff.net 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305ff0 ASPSESSIONIDQQQGQGCW=CLOLNPCABJJEFIALAMCGKOPK f1.mail.yahoo.com www.macduff.net 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305f00 ID=a27313f438568ef7 f1.mail.yahoo.com 207.82.250.251 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305ea0 MC1=GUID=c813772570db11d2a7ed00805fb76d19 f1.mail.yahoo.com .microsoft.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305af8 MC1=GUID=c813772570db11d2a7ed00805fb76d19 f1.mail.yahoo.com .msn.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305a98 Apache=13425540909880601102 f1.mail.yahoo.com www.mygale.org 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305a38 ASPSESSIONID=XDFMOMSYHIECNWGA f1.mail.yahoo.com www.jpsystems.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3059e8 Apache=13413931910295787850 f1.mail.yahoo.com tix.mne.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305988 UniqueId=134.243.50.70-910428508-622544-27499 f1.mail.yahoo.com cartoonnetwork.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305938 LookSmartPIN=981112x4b4aeff25a817d95501 f1.mail.yahoo.com www.looksmart.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3058e8 isp=zf f1.mail.yahoo.com .looksmart.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305878 sessionid=NWRHWBYABWK1NAMUVFZE45UBSSUXEUDO f1.mail.yahoo.com .sun.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3057e8 DNREG=01911023099.216f40b4ddb52461bb24615f1538c132baf8f435 f1.mail.yahoo.com .dejanews.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305828 GTUID=04.40732.0.0.614.53342 f1.mail.yahoo.com .dejanews.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 305788 WEBTRENDS_ID=134.243.50.70-4050000352.29233188 f1.mail.yahoo.com www.jamsline.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 304920 ASPSESSIONID=SYAPYNZFROMBITOT f1.mail.yahoo.com .broadcast.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3048d0 preferences=background&default&days&Sun-Sat×&Start%20%26%20End%20Times&default&&calendars&&debug&0 f1.mail.yahoo.com hypermuse 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 /cgi-bin/calmgr 13 Checking cookie 304890 EGSOFT_ID=134.243.50.70-612792272.29233418 f1.mail.yahoo.com news.binco.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 304840 LookSmartPIN=981115x7b38525c38ced8f7c61 f1.mail.yahoo.com altavista.looksmart.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3047f0 ASPSESSIONIDGGQGGGAN=NHKBAPHDGDFFDIFOHEDMAKKL f1.mail.yahoo.com www.intelligence.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 3047a0 WPI=911222219.jw.00902 f1.mail.yahoo.com www.javaworld.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 Checking cookie 304740 M=dp=sum f1.mail.yahoo.com .my.yahoo.com 0 /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 / 0 HTTP: Sending Cookie2: $Version ="1" HTTP: Sending Cookie: YM.Pref=farm%3d1%26silo%3dms1%26v%3dn%26email%3dlvirden%40yahoo.com%26head%3dbrief%26fwd%3dattach%26fontsz%3dnormal%26msgwidth%3d82%26order%3ddown%26inc%3d25%26goto%3dmsg; YM.Login=id%3d%241%24rm%24JxXK.kgvuHbPNEvny7iP11%26sid%3ds9uiTIX%252bMqeG%250a%26ts%3d%253d%25a6B%257c%25dd%2517%25ed%2597%25da%253f%258b%25c1%25b9; T=z=iQRV2AiWmV2AidRx12.EJy8NgY2MTc1NjE0MTY-; Y=v=1&n=1scejighn0oed&l=bl8h34d/o&p=m1n1a1s4111b&lg=us Composing Authorization for f1.mail.yahoo.com:80/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTAASetup_lookup: No template matched `py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931' (so probably not protected) HTTP: Not sending authorization (yet). HTTP: Doing post, content-type 'application/x-www-form-urlencoded' Writing: POST /py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 HTTP/1.0 Host: f1.mail.yahoo.com Accept: text/html, text/plain, video/x-ms-asf, application/marimba, application/x-bzip2, audio/midi, x-conference/x-cooltalk, application/x-candleweb, x-world/x-vrml, video/x-mpeg, application/x-wt, application/x-rasmol, application/x-xdma Accept: audio/x-pn-realaudio, application/x-chat, text/tab-separated-values, application/applefile, application/pgp, application/x-ccitcl, application/safe-tcl, multipart/enabled-mail, application/x-tgif, application/view_pctdoc, application/framemaker Accept: application/pdf, text/enriched, text/richtext, application/andrew-inset, x-be2, application/postscript, application/x-dvi, application/x-tex, message/external-body, message/partial, image/x-xwd, audio/*, audio/basic, audio/x-mpeg, text/sgml Accept: text/x-compressed, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: en Accept-Charset: iso-8859-1, us-ascii;q=0.01 Pragma: no-cache Cache-Control: no-cache User-Agent: Lynx/2.8.2dev.4 libwww-FM/2.14 Cookie2: $Version="1" Cookie: YM.Pref=farm%3d1%26silo%3dms1%26v%3dn%26email%3dlvirden%40yahoo.com%26head%3dbrief%26fwd%3dattach%26fontsz%3dnormal%26msgwidth%3d82%26order%3ddown%26inc%3d25%26goto%3dmsg; YM.Login=id%3d%241%24rm%24JxXK.kgvuHbPNEvny7iP11%26sid%3ds9uiTIX%252bMqeG%250a%26ts%3d%253d%25a6B%257c%25dd%2517%25ed%2597%25da%253f%258b%25c1%25b9; T=z=iQRV2AiWmV2AidRx12.EJy8NgY2MTc1NjE0MTY-; Y=v=1&n=1scejighn0oed&l=bl8h34d/o&p=m1n1a1s4111b&lg=us Content-type: application/x-www-form-urlencoded Content-length: 21 sTRA=Delete&destBox1= ---------------------------------- Sending HTTP request. HTTP: WRITE delivered OK HTTP request sent; waiting for response. HTTP: Trying to read 1023 HTTP: Read 1023 Read 1023 bytes of data. HTTP: Rx: HTTP/1.1 200 OK HTTP: Scanned 2 fields from line_buffer --- Talking HTTP1. HTTP/1.1 200 OK HTFormat: Constructing stream stack for www/mime to www/present HTFormat: Looking up presentation for www/mime to www/present HTFormat: comparing audio/* and www/mime for half match StreamStack: found weak wildcard match: www/present FindPresentation: found exact match: www/mime StreamStack: found exact match: www/mime HTMIME: Date: Fri, 20 Nov 1998 07:06:08 GMT Server: Apache/1.3.1 (Unix) Connection: close Content-Type: text/html Yahoo! Mail
      HTML:end_element[0]: Popped style off stack - Normal SGML: Still open none, no open TD for SGML: Still open none, no open TR for SGML: Still open none, no open TABLE for
        SGML: Start UCSetTransParams: from iso-8859-1(1) to iso-8859-1(1) UCSetTransParams: from iso-8859-1(1) to iso-8859-1(1) GridText: start HText_new GridText: Change to style Normal me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[0]: adding style to stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[1]: adding style to stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[2]: adding style to stack - Normal SGML: End HTML:end_element[2]: Popped style off stack - Normal SGML: End HTML:end_element[1]: Popped style off stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[1]: adding style to stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) GridText: Change to style DivLeft HTML:begin_element[2]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Unknown attribute width for tag TD SGML: Attribute value 140 ignored SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Unknown attribute width for tag TD SGML: Attribute value 1% ignored SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Unknown attribute width for tag TD SGML: Attribute value 100% ignored SGML: Start <- supplied, end HTML:end_element[4]: Popped style off stack - DivLeft SGML: Still open TR, no open FORM for SGML Comment: SGML: End <- supplied, start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:/py/nfWlcm.py?Pyt=Tnf&showad=1&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfWlcm.py?Pyt=Tnf&showad=1&YY=18597 SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) SGML: End HTML:end_element[5]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:#ymmap relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 2 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931#ymmap HTML IMG: USEMAP=1 ISMAP=0 ANCHOR=0 PARA=0 new Anchor 409db0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:LYNXIMGMAP:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931#ymmap relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 3 HTParse: result:LYNXIMGMAP:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931#ymmap HTParse: aName:LYNXIMGMAP:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931#ymmap relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 42f5b0 has hash 28 and address `LYNXIMGMAP:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931#ymmap' Linking anchor 409db0 to anchor 42f5b0 HText_endAnchor: number:1 link_type:1 SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 409d90 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfMBox.py?Pyt=Tnf&box=Inbox&YN=1&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Inbox&YN=1&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Inbox&YN=1&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 3bdbc8 has hash 100 and address `http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Inbox&YN=1&YY=18597' Linking anchor 409d90 to anchor 3bdbc8 HTML:begin_element[9]: adding style to stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft HText_endAnchor: number:2 link_type:1 SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 409dd0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfCmp.py?Pyt=Tnf&1st=1&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 42f7a0 has hash 18 and address `http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&YY=18597' Linking anchor 409dd0 to anchor 42f7a0 HTML:begin_element[9]: adding style to stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft HText_endAnchor: number:3 link_type:1 SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 409df0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfFldr.py?Pyt=Tnf&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfFldr.py?Pyt=Tnf&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfFldr.py?Pyt=Tnf&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 42f8e8 has hash 62 and address `http://f1.mail.yahoo.com/py/nfFldr.py?Pyt=Tnf&YY=18597' Linking anchor 409df0 to anchor 42f8e8 HTML:begin_element[9]: adding style to stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft HText_endAnchor: number:4 link_type:1 SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 409e10 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/yab?v=YM&nf=1 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/yab?v=YM&nf=1 HTParse: aName:http://f1.mail.yahoo.com/yab?v=YM&nf=1 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 39de10 with address `http://f1.mail.yahoo.com/yab?v=YM&nf=1' already exists. Linking anchor 409e10 to anchor 39de10 HTML:begin_element[9]: adding style to stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft HText_endAnchor: number:5 link_type:1 SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: SD> HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      HTML:end_element[5]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML Comment: SGML: Unknown attribute bgcolor for tag TABLE SGML: Attribute value #a0b8c8 ignored SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[8]: adding style to stack - DivLeft SGML: End HTML:end_element[8]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 431860 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://mail.yahoo.com/help/context/yReading.html relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://mail.yahoo.com/help/context/yReading.html HTParse: aName:http://mail.yahoo.com/help/context/yReading.html relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 3c0c50 with address `http://mail.yahoo.com/help/context/yReading.html' already exists. Linking anchor 431860 to anchor 3c0c50 HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Underline Level is 1 HTML:begin_element[9]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[10]: adding style to stack - DivLeft SGML: End HTML:end_element[10]: Popped style off stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Underline Level is 0 SGML: End HTML:end_element[8]: Popped style off stack - DivLeft HText_endAnchor: number:12 link_type:1 SGML: End
      HTML:end_element[5]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: End <- supplied, start HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 new Anchor 431880 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 431770 has hash 84 and address `http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597' Linking anchor 431880 to anchor 431770 BeginForm: action:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 Method:2 HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=message value=4284_2595253_185_576_4690_0 size=0 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=Subject value=This week at In The Market: Holiday Shopping Is Here! size=0 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Unknown attribute width for tag TD SGML: Attribute value 1% ignored SGML: Still open FORM <- invalid start HTML:end_element[7]: Popped style off stack - DivLeft SGML: Still open FORM <- invalid start HTML:end_element[7]: Popped style off stack - DivLeft SGML: Still open FORM <- invalid start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 new Anchor 4318c0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 430718 with address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597' already exists. Linking anchor 4318c0 to anchor 430718 BeginForm: action:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 Method:2 HTML:begin_element[6]: adding style to stack - DivLeft SGML: Still open FORM <- invalid end SGML: Still open FORM <- invalid start SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Unknown attribute bgcolor for tag TD SGML: Attribute value #dcdcdc ignored SGML: Start HTML:end_element[8]: Popped style off stack - DivLeft SGML: Unknown attribute bgcolor for tag TD SGML: Attribute value #dcdcdc ignored SGML: Start HTML:end_element[8]: Popped style off stack - DivLeft SGML: End <- supplied, end HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: End
      SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=reply value=Reply size=5 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=replyAll value=Reply All size=9 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=forward value=Forward size=7 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start HTML:end_element[10]: Popped style off stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Entering HText_setLastOptionValue: value:(2)__inline text, checked:off HText_setLastOptionValue: LAST_ORDER value=(2)__inline text val_cs=0 "iso-8859-1" (submit_val_cs 0 "iso-8859-1") submit_value=quoted SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[9]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 431900 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 431300 has hash 69 and address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597' Linking anchor 431900 to anchor 431300 HTML:begin_element[10]: adding style to stack - DivLeft SGML: End HTML:end_element[10]: Popped style off stack - DivLeft HText_endAnchor: number:17 link_type:1 SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Ending underline SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[9]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 431920 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 430718 has hash 13 and address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597' Linking anchor 431920 to anchor 430718 HTML:begin_element[10]: adding style to stack - DivLeft SGML: End HTML:end_element[10]: Popped style off stack - DivLeft HText_endAnchor: number:18 link_type:1 SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Ending underline SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[7]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[9]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 431940 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 4307c8 has hash 15 and address `http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597' Linking anchor 431940 to anchor 4307c8 HTML:begin_element[10]: adding style to stack - DivLeft SGML: End HTML:end_element[10]: Popped style off stack - DivLeft HText_endAnchor: number:19 link_type:1 SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Ending underline SGML: End HTML:end_element[8]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[9]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=TRA value=Delete size=6 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 431960 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 434338 has hash 31 and address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597' Linking anchor 431960 to anchor 434338 HTML:begin_element[10]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Underline Level is 1 HTML:begin_element[11]: adding style to stack - DivLeft SGML: End HTML:end_element[11]: Popped style off stack - DivLeft Underline Level is 0 SGML: End HTML:end_element[10]: Popped style off stack - DivLeft HText_endAnchor: number:21 link_type:1 SGML: End HTML:end_element[9]: Popped style off stack - DivLeft SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[8]: adding style to stack - DivLeft SGML: Start HTML:end_element[10]: Popped style off stack - DivLeft SGML: End HTML:end_element[9]: Popped style off stack - DivLeft Entering HText_setLastOptionValue: value:(21)_sfbc , checked:off HText_setLastOptionValue: LAST_ORDER value=(21)_sfbc val_cs=0 "iso-8859-1" SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=MV1 value=Move size=4 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: End
      HTML:end_element[5]: Popped style off stack - DivLeft SGML: End
      HTML:end_element[3]: Popped style off stack - DivLeft SGML: End
      <- forced by start HTML:end_element[2]: Popped style off stack - Normal GridText: Change to style Normal SGML: Start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) GridText: Change to style DivLeft HTML:begin_element[2]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 4319c0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/yab?v=YM&nf=1&A=a&.done=/py/nfLttr.py%3fPyt%3dTnf%26box%3dSpam%26message%3d4284_2595253_185_576_4690_0%26sort%3ddate%26order%3ddown%26YY%3d18597&fn=&ln=club&e=club%40shopnowmarket.com relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/yab?v=YM&nf=1&A=a&.done=/py/nfLttr.py%3fPyt%3dTnf%26box%3dSpam%26message%3d4284_2595253_185_576_4690_0%26sort%3ddate%26order%3ddown%26YY%3d18597&fn=&ln=club&e=club%40shopnowmarket.com HTParse: aName:http://f1.mail.yahoo.com/yab?v=YM&nf=1&A=a&.done=/py/nfLttr.py%3fPyt%3dTnf%26box%3dSpam%26message%3d4284_2595253_185_576_4690_0%26sort%3ddate%26order%3ddown%26YY%3d18597&fn=&ln=club&e=club%40shopnowmarket.com relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 435cb0 has hash 10 and address `http://f1.mail.yahoo.com/yab?v=YM&nf=1&A=a&.done=/py/nfLttr.py%3fPyt%3dTnf%26box%3dSpam%26message%3d4284_2595253_185_576_4690_0%26sort%3ddate%26order%3ddown%26YY%3d18597&fn=&ln=club&e=club%40shopnowmarket.com' Linking anchor 4319c0 to anchor 435cb0 HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Underline Level is 1 HTML:begin_element[7]: adding style to stack - DivLeft SGML: End HTML:end_element[7]: Popped style off stack - DivLeft Underline Level is 0 SGML: End HTML:end_element[6]: Popped style off stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft HText_endAnchor: number:24 link_type:1 SGML: End
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: End
      HTML:end_element[2]: Popped style off stack - Normal GridText: Change to style Normal SGML Comment: SGML: Start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      GridText: Change to style Preformatted
      HTML:begin_element[2]: adding style to stack - Preformatted
      GridText: HText_pageDisplay at line 1 started
      Gridtext: Entering HText_trimHightext
      HText_trimHightext: trace disabled in display_partial mode
      
      GridText: Not showing link, hightext=[1
      
      GridText: Not showing link, hightext=[1
      GridText: HText_pageDisplay finished
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 431b80 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:https://www.shopnowmarket.com/markete-bsc/pp4.html   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:https://www.shopnowmarket.com/markete-bsc/pp4.html
      HTParse: aName:https://www.shopnowmarket.com/markete-bsc/pp4.html   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 427fd8 has hash 24 and address `https://www.shopnowmarket.com/markete-bsc/pp4.html'
      Linking anchor 431b80 to anchor 427fd8
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:25 link_type:1
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 431c80 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:http://www.justwhiteshirts.com/Web_storeUS/web_store.cgi?page=jwscustom.htm&cart_id=8328200.23150   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:http://www.justwhiteshirts.com/Web_storeUS/web_store.cgi?page=jwscustom.htm&cart_id=8328200.23150
      HTParse: aName:http://www.justwhiteshirts.com/Web_storeUS/web_store.cgi?page=jwscustom.htm&cart_id=8328200.23150   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 435fb8 has hash 38 and address `http://www.justwhiteshirts.com/Web_storeUS/web_store.cgi?page=jwscustom.htm&cart_id=8328200.23150'
      Linking anchor 431c80 to anchor 435fb8
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: Unknown entity 'cart' 0 -1
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:26 link_type:1
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 431d60 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:https://www.shopnowmarket.com/markete-dis/pp7.html   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:https://www.shopnowmarket.com/markete-dis/pp7.html
      HTParse: aName:https://www.shopnowmarket.com/markete-dis/pp7.html   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 4419b8 has hash 99 and address `https://www.shopnowmarket.com/markete-dis/pp7.html'
      Linking anchor 431d60 to anchor 4419b8
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:27 link_type:1
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 431ea0 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:https://10.10.10.119/markete-etoys/pp3.html   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:https://10.10.10.119/markete-etoys/pp3.html
      HTParse: aName:https://10.10.10.119/markete-etoys/pp3.html   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 441b00 has hash 5 and address `https://10.10.10.119/markete-etoys/pp3.html'
      Linking anchor 431ea0 to anchor 441b00
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:28 link_type:1
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 431f40 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:https://10.10.10.119/markete-savi/ppf203.html   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:https://10.10.10.119/markete-savi/ppf203.html
      HTParse: aName:https://10.10.10.119/markete-savi/ppf203.html   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 450620 has hash 12 and address `https://10.10.10.119/markete-savi/ppf203.html'
      Linking anchor 431f40 to anchor 450620
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:29 link_type:1
      Read 9 KB of data, 9 KB/sec.
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 454850 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:/py/nfCmp.py?Pyt=Tnf&1st=1&to=lvirden@yahoo.com&YY=18597   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=lvirden@yahoo.com&YY=18597
      HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=lvirden@yahoo.com&YY=18597   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 4506d0 has hash 78 and address `http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=lvirden@yahoo.com&YY=18597'
      Linking anchor 454850 to anchor 4506d0
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:30 link_type:1
      SGML: Start 
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0)
      new Anchor 454870 named `' is child of 4280b0
      Entered HTAnchor_findChildAndLink
      HTParse: aName:/py/nfCmp.py?Pyt=Tnf&1st=1&to=leave-shopnow-market-187736A@club.buysoftware.com&YY=18597   relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931
      1
      HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=leave-shopnow-market-187736A@club.buysoftware.com&YY=18597
      HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=leave-shopnow-market-187736A@club.buysoftware.com&YY=18597   relatedName:
      HTParse: result:
      Entered HTAnchor_findAddress
      New anchor 450780 has hash 44 and address `http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&1st=1&to=leave-shopnow-market-187736A@club.buysoftware.com&YY=18597'
      Linking anchor 454870 to anchor 450780
      HTML:begin_element[3]: adding style to stack - Preformatted
      SGML: End 
      HTML:end_element[3]: Popped style off stack - Preformatted
      HText_endAnchor: number:31 link_type:1
      SGML: Still open PRE 	<- invalid end 
      SGML: End 
      HTML:end_element[2]: Popped style off stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) GridText: Change to style DivLeft HTML:begin_element[2]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: End <- supplied, start HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 new Anchor 4548b0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 430718 with address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597' already exists. Linking anchor 4548b0 to anchor 430718 BeginForm: action:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 Method:2 HTML:begin_element[3]: adding style to stack - DivLeft SGML: Unknown attribute bgcolor for tag TD SGML: Attribute value #dcdcdc ignored SGML: Still open FORM <- invalid start HTML:end_element[4]: Popped style off stack - DivLeft SGML: Unknown attribute bgcolor for tag TD SGML: Attribute value #dcdcdc ignored SGML: Still open FORM <- invalid start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Still open TABLE <- invalid end SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: End <- supplied, start HTML:end_element[3]: Popped style off stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTParse: aName:/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 new Anchor 454910 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 431770 with address `http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597' already exists. Linking anchor 454910 to anchor 431770 BeginForm: action:http://f1.mail.yahoo.com/py/nfCmp.py?Pyt=Tnf&folder=Spam&sort=date&order=down&inc=25&YY=18597 Method:2 HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=message value=4284_2595253_185_576_4690_0 size=0 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=Subject value=This week at In The Market: Holiday Shopping Is Here! size=0 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Unknown attribute width for tag TD SGML: Attribute value 1% ignored SGML: Still open FORM <- invalid start HTML:end_element[4]: Popped style off stack - DivLeft SGML: End HTML:end_element[3]: Popped style off stack - DivLeft SGML: Still open TABLE <- invalid start HTML:end_element[3]: Popped style off stack - DivLeft SGML: Still open TABLE <- invalid start HTML:end_element[3]: Popped style off stack - DivLeft SGML: End
      SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=TRA value=Delete size=6 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 4548d0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 434338 with address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&toc=1&order=down&box=Spam&message=4284_2595253_185_576_4690_0&YY=18597' already exists. Linking anchor 4548d0 to anchor 434338 HTML:begin_element[6]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Underline Level is 1 HTML:begin_element[7]: adding style to stack - DivLeft SGML: End HTML:end_element[7]: Popped style off stack - DivLeft Underline Level is 0 SGML: End HTML:end_element[6]: Popped style off stack - DivLeft HText_endAnchor: number:33 link_type:1 SGML: End HTML:end_element[5]: Popped style off stack - DivLeft SGML: End SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start HTML:end_element[6]: Popped style off stack - DivLeft SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Entering HText_setLastOptionValue: value:(21)_sfbc , checked:off HText_setLastOptionValue: LAST_ORDER value=(21)_sfbc val_cs=0 "iso-8859-1" SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=MV1 value=Move size=4 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: End
      SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=reply value=Reply size=5 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=replyAll value=Reply All size=9 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Entering HText_beginInput Input link: name=forward value=Forward size=7 Input link: name_cs=0 "iso-8859-1" (from 0 "iso-8859-1") value_cs=0 "iso-8859-1" (from 0 "iso-8859-1") SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start HTML:end_element[7]: Popped style off stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft Entering HText_setLastOptionValue: value:(2)__inline text, checked:off HText_setLastOptionValue: LAST_ORDER value=(2)__inline text val_cs=0 "iso-8859-1" (submit_val_cs 0 "iso-8859-1") submit_value=quoted SGML: End HTML:end_element[5]: Popped style off stack - DivLeft SGML: End SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 454950 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 431300 with address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&PRE=1&order=down&inc=25&num=0&YY=18597' already exists. Linking anchor 454950 to anchor 431300 HTML:begin_element[6]: adding style to stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft HText_endAnchor: number:40 link_type:1 SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 454990 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 430718 with address `http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=4284_2595253_185_576_4690_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=18597' already exists. Linking anchor 454990 to anchor 430718 HTML:begin_element[6]: adding style to stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft HText_endAnchor: number:41 link_type:1 SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End HTML:end_element[4]: Popped style off stack - DivLeft SGML: End SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[3]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[4]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[5]: adding style to stack - DivLeft SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 4549b0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 4307c8 with address `http://f1.mail.yahoo.com/py/nfMBox.py?Pyt=Tnf&box=Spam&sort=date&order=down&YY=18597' already exists. Linking anchor 4549b0 to anchor 4307c8 HTML:begin_element[6]: adding style to stack - DivLeft SGML: End HTML:end_element[6]: Popped style off stack - DivLeft HText_endAnchor: number:42 link_type:1 SGML: End HTML:end_element[5]: Popped style off stack - DivLeft Ending underline SGML: End HTML:end_element[4]: Popped style off stack - DivLeft SGML: End
      HTML:end_element[2]: Popped style off stack - Normal GridText: Change to style Normal SGML: End <- supplied, end HTML:end_element[1]: Popped style off stack - Normal SGML: Still open HTML, no open FORM for SGML: Start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) SGML: Start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[1]: adding style to stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 4549f0 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:/py/nfTOS.py?Pyt=Tnf&TOS=1&YY=18597 relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://f1.mail.yahoo.com/py/nfTOS.py?Pyt=Tnf&TOS=1&YY=18597 HTParse: aName:http://f1.mail.yahoo.com/py/nfTOS.py?Pyt=Tnf&TOS=1&YY=18597 relatedName: HTParse: result: Entered HTAnchor_findAddress New anchor 45be80 has hash 22 and address `http://f1.mail.yahoo.com/py/nfTOS.py?Pyt=Tnf&TOS=1&YY=18597' Linking anchor 4549f0 to anchor 45be80 HTML:begin_element[2]: adding style to stack - Normal SGML: End HTML:end_element[2]: Popped style off stack - Normal HText_endAnchor: number:43 link_type:1 SGML: Start
      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) Beginning underline HTML:begin_element[2]: adding style to stack - Normal SGML: Start me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) new Anchor 454a50 named `' is child of 4280b0 Entered HTAnchor_findChildAndLink HTParse: aName:http://www.yahoo.com relatedName:http://f1.mail.yahoo.com/py/nfLttr.py?Pyt=Tnf&box=Spam&message=5667_2697605_400_555_17025_0&sort=date&NEX=1&order=down&inc=25&num=0&YY=30931 1 HTParse: result:http://www.yahoo.com/ HTParse: aName:http://www.yahoo.com/ relatedName: HTParse: result: Entered HTAnchor_findAddress Anchor 3143a0 with address `http://www.yahoo.com/' already exists. Linking anchor 454a50 to anchor 3143a0 HTML:begin_element[3]: adding style to stack - Normal SGML: End HTML:end_element[3]: Popped style off stack - Normal HText_endAnchor: number:44 link_type:1 SGML: End HTML:end_element[2]: Popped style off stack - Normal Ending underline SGML: End
      HTML:end_element[1]: Popped style off stack - Normal SGML: End <- supplied, end
      SGML: Start

      me->tag_charset: 0 -> 0 (me->UCLYhndl: 0, tag_charset: 0) HTML:begin_element[0]: adding style to stack - Normal SGML Comment: SGML: End

      <- supplied, end HTML:end_element[0]: Popped style off stack - Normal SGML: Still open none, no open BODY for SGML: Still open none, no open HTML for Read 12 KB of data, 12 KB/sec. Data transfer complete Gridtext: Entering HText_endAppend GridText: Removing bottom blank line: GridText: New bottom line: GridText: Removing bottom blank line: GridText: New bottom line: GridText: Removing bottom blank line: GridText: New bottom line: ^CCopyright © 1997-98 [44]^EYahoo!^F Inc. All rights reserved.^D Gridtext: Entering HText_trimHightext Gridtext: Anchor found on line:1 col:3 anchor text: '[1]^E[USEMAP:ymmap.gif]^F' GridText: add link on line 1 col 6 in HText_trimHightext Gridtext: Anchor found on line:2 col:4 anchor text: ' [2]^ECheck Mail^F' GridText: add link on line 2 col 7 in HText_trimHightext Gridtext: Anchor found on line:3 col:4 anchor text: ' [3]^ECompose^F' GridText: add link on line 3 col 7 in HText_trimHightext Gridtext: Anchor found on line:4 col:4 anchor text: ' [4]^EFolders^F' GridText: add link on line 4 col 7 in HText_trimHightext Gridtext: Anchor found on line:5 col:4 anchor text: ' [5]^EAddresses^F' GridText: add link on line 5 col 7 in HText_trimHightext Gridtext: Anchor found on line:6 col:4 anchor text: ' [6]^ESearch^F' GridText: add link on line 6 col 7 in HText_trimHightext Gridtext: Anchor found on line:7 col:4 anchor text: ' [7]^EOptions^F' GridText: add link on line 7 col 7 in HText_trimHightext Gridtext: Anchor found on line:8 col:4 anchor text: ' [8]^EHelp Desk^F' GridText: add link on line 8 col 7 in HText_trimHightext Gridtext: Anchor found on line:9 col:4 anchor text: ' [9]^EExit^F' GridText: add link on line 9 col 7 in HText_trimHightext Gridtext: Anchor found on line:11 col:4 anchor text: '[10]^E[196a1031.gif] ^F[11]^ENEW E-MAIL' GridText: add link on line 11 col 7 in HText_trimHightext Gridtext: Anchor found on line:11 col:25 anchor text: '[10]^E[196a1031.gif] ^F[11]^ENEW E-MAIL' GridText: add link on line 11 col 26 in HText_trimHightext Gridtext: Anchor found on line:15 col:19 anchor text: '^CRead Message^D [12]^EHelp^F' GridText: add link on line 15 col 20 in HText_trimHightext Gridtext: Anchor found on line:16 col:0 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 3 in HText_trimHightext Gridtext: Anchor found on line:16 col:0 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 3 in HText_trimHightext Gridtext: Anchor found on line:16 col:4 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 7 in HText_trimHightext Gridtext: Anchor found on line:16 col:14 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 17 in HText_trimHightext Gridtext: Anchor found on line:16 col:29 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 32 in HText_trimHightext Gridtext: Anchor found on line:16 col:41 anchor text: '[13]Reply [14]Reply All [15]Forward[16][(1)__as attachment] -' GridText: add link on line 16 col 44 in HText_trimHightext Gridtext: Anchor found on line:17 col:5 anchor text: '^C[17]^EPrev^F^D | ^C[18]^ENext^F^D Back to ^C[19]^ESpam^F^D' GridText: add link on line 17 col 7 in HText_trimHightext Gridtext: Anchor found on line:17 col:20 anchor text: '^C[17]^EPrev^F^D | ^C[18]^ENext^F^D Back to ^C[19]^ESpam^F^D' GridText: add link on line 17 col 18 in HText_trimHightext Gridtext: Anchor found on line:17 col:41 anchor text: '^C[17]^EPrev^F^D | ^C[18]^ENext^F^D Back to ^C[19]^ESpam^F^D' Gri -- 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 Nov 20 10:00:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA08347 for ; Fri, 20 Nov 1998 10:00:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA16737; Fri, 20 Nov 1998 08:36:45 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Fri, 20 Nov 1998 17:28:53 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev thoughts on cookie file w/multiple sessions 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: 521 Lines: 14 >> With the way I have things up there, whichever copy of Lynx is exited first >> will be the session with the cookie that is saved. >> >> So it's pretty much an even shot either way. I don't like this, and can't >> really think of a way to do handle this without (for example) timestamping >> individual cookies (possibly with comments in the cookie file?). > Give each session its own cookie file, and merge them (if you wish) after > they are done? You could not merge them correctly in general case. > Klaus From owner-lynx-dev@sig.net Fri Nov 20 10:02:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA08444 for ; Fri, 20 Nov 1998 10:01:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA07830; Fri, 20 Nov 1998 08:11:34 -0600 (CST) Date: Thu, 19 Nov 1998 20:15:56 -0500 (EST) From: Marcus To: Terra Syslo , lynx-dev@sig.net Subject: lynx-dev the wire trace file Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-57062353-911524556=:31193" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 110481 Lines: 1820 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. --0-57062353-911524556=:31193 Content-Type: TEXT/PLAIN; charset=US-ASCII attached you will find the result of going to http://wire.ap.org/APnews/main.html directly without being on the wire site! Check out my web page! http://www.icubed.com/~marcus25/ don't forget the slash at the end! I am scoreboard king time master and Dana lover! I am chocolate king bacon king and Dana lover! I am king of laziness king of stubbornness and Dana lover! Get the picture? --0-57062353-911524556=:31193 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="trace.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DUdldHRpbmcgaHR0cDovL1dJUkUuQVAuT1JHL0FQTkVXUy9NQUlOLkhUTUwN TG9vawl1cCBXSVJFLkFQLk9SRy4NTWFraW5nIEhUVFAgY29ubmVjdGlvbiB0 byBXSVJFLkFQLk9SRy4NU2VuZGluZyBIVFRQIHJlcXVlc3QuDUhUVFAgcmVx dWVzdCBzZW50OyB3YWl0aW5nIGZvciByZXNwb25zZS4NUmVhZCAxNjEgYnl0 ZXMgb2YgZGF0YS4NQWxlcnQhOiBIVFRQLzEuMSA0MDQgTm90IGZvdW5kDVJl YWQgMjA3IG9mIDIwNyBieXRlcyBvZiBkYXRhLg1EYXRhIHRyYW5zZmVyIGNv bXBsZXRlDQoJCQkJCSAgICAgICAJICAgICAgICAgICAgICAgICAgICAgIE5v dCBGb3VuZA0KDQoNICAgICAgICAgICAgICAgICAgICAJCSAgIE5vdCBGb3Vu ZA0KDSAgIA0KVGhlIHJlcXVlc3RlZCBvYmplY3QJZG9lcyBub3QgZXhpc3Qg b24gdGhpcyBzZXJ2ZXIuIFRoZSBsaW5rCXlvdQ0KDSAgIGZvbGxvd2VkIGlz IGVpdGhlciBvdXRkYXRlZCwJaW5hY2N1cmF0ZSwgb3IgdGhlIHNlcnZlciBo YXMgYmVlbg0KDSAgIGluc3RydWN0ZWQgbm90IHRvIGxldCB5b3UgaGF2ZSBp dC4NCg0gICANCg0KDQoNCg0KDQoNCgkJCSAgDQoNCg0KDQoNCg0KDQoNCg0N CkNvbW1hbmRzOiBVc2UgYXJyb3cga2V5cyB0byBtb3ZlLCAnPycgZm9yIGhl bHAsICdxJyB0byBxdWl0LCAnPC0nIHRvIGdvIGJhY2suDVRyYWNlIE9OIQ1D b21tYW5kczogVXNlIGFycm93IGtleXMgdG8gbW92ZSwgJz8nIGZvciBoZWxw LCAncScgdG8gcXVpdCwgJzwtJyB0byBnbyBiYWNrLg1VUkwgdG8gb3Blbjog aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWxIVFBhcnNlOiBh TmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbCAgIHJl bGF0ZWROYW1lOg0KMQ0KSFRQYXJzZTogcmVzdWx0Omh0dHA6Ly93aXJlLmFw Lm9yZy9BUG5ld3MvbWFpbi5odG1sDQoJCQkgICAgICAgDQpMWXB1c2g6IGFk ZHJlc3M6aHR0cDovL1dJUkUuQVAuT1JHL0FQTkVXUy9NQUlOLkhUTUwNCiAg ICAgICAgdGl0bGU6Tm90IEZvdW5kDQpMWUdldEZpbGU6IGdldHRpbmcgaHR0 cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWwNCg0KSFRQYXJzZTog YU5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWwgICBy ZWxhdGVkTmFtZToNCkhUUGFyc2U6IHJlc3VsdDp3aXJlLmFwLm9yZw0KDUdl dHRpbmcgaHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWwNCkhU UGFyc2U6IGFOYW1lOmh0dHA6Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFpbi5o dG1sICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6DQpFbnRlcmVk IEhUQW5jaG9yX2ZpbmRBZGRyZXNzDQpOZXcgYW5jaG9yIDE0MDA2MTdjMCBo YXMgaGFzaCAzMiBhbmQgYWRkcmVzcyBgaHR0cDovL3dpcmUuYXAub3JnL0FQ bmV3cy9tYWluLmh0bWwnDQpIVEFjY2VzczogbG9hZGluZyBkb2N1bWVudCBo dHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KSFRQYXJzZTog YU5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWwgICBy ZWxhdGVkTmFtZTpmaWxlOg0KSFRQYXJzZTogcmVzdWx0Omh0dHANCkhUUGFy c2U6IGFOYW1lOmh0dHA6Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFpbi5odG1s ICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6d2lyZS5hcC5vcmcN CkhUUGFyc2U6IGFOYW1lOmh0dHA6Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFp bi5odG1sICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6aHR0cA0K SFRQYXJzZTogYU5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWlu Lmh0bWwgICByZWxhdGVkTmFtZToNCkhUUGFyc2U6IHJlc3VsdDp3aXJlLmFw Lm9yZw0KTG9va2luZyB1cCB3aXJlLmFwLm9yZy4NClRDUDogUGFyc2VkIGFk ZHJlc3MgYXMgcG9ydCA4MCwgSVAgYWRkcmVzcyAxNjUuMS43Ni4xMDANCk1h a2luZyBIVFRQIGNvbm5lY3Rpb24gdG8gd2lyZS5hcC5vcmcuDQpIVFBhcnNl OiBhTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbCAg IHJlbGF0ZWROYW1lOg0KMQ0KSFRQYXJzZTogcmVzdWx0Oi9BUG5ld3MvbWFp bi5odG1sDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvQVBu ZXdzL21haW4uaHRtbCAgIHJlbGF0ZWROYW1lOg0KSFRQYXJzZTogcmVzdWx0 OndpcmUuYXAub3JnDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2lyZS5hcC5v cmcvQVBuZXdzL21haW4uaHRtbCAgIHJlbGF0ZWROYW1lOg0KMQ0KSFRQYXJz ZTogcmVzdWx0Oi9BUG5ld3MvbWFpbi5odG1sDQpIVFBhcnNlOiBhTmFtZTpo dHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbCAgIHJlbGF0ZWRO YW1lOg0KMQ0KSFRQYXJzZTogcmVzdWx0OkFQbmV3cy9tYWluLmh0bWwNCkhU UGFyc2U6IGFOYW1lOmh0dHA6Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFpbi5o dG1sICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6d2lyZS5hcC5v cmcNCkxZQ29va2llOiBTZWFyY2hpbmcgZm9yICd3aXJlLmFwLm9yZzo4MCcs ICcvQVBuZXdzL21haW4uaHRtbCcuDQpDb21wb3NpbmcgQXV0aG9yaXphdGlv biBmb3Igd2lyZS5hcC5vcmc6ODAvQVBuZXdzL21haW4uaHRtbA0KSFRBQVNl dHVwX2xvb2t1cDogTm8gdGVtcGxhdGUgbWF0Y2hlZCBgQVBuZXdzL21haW4u aHRtbCcgKHNvIHByb2JhYmx5IG5vdCBwcm90ZWN0ZWQpDQpIVFRQOiBOb3Qg c2VuZGluZyBhdXRob3JpemF0aW9uICh5ZXQpDQpXcml0aW5nOg0KR0VUIC9B UG5ld3MvbWFpbi5odG1sIEhUVFAvMS4wDQ0KSG9zdDogd2lyZS5hcC5vcmcN DQpBY2NlcHQ6IHRleHQvaHRtbCwgdGV4dC9wbGFpbiwgdGV4dC9zZ21sLCB0 ZXh0L3gtc2dtbCwgYXBwbGljYXRpb24veC13YWlzLXNvdXJjZSwgYXBwbGlj YXRpb24vaHRtbCwgKi8qO3E9MC4wMDENDQpBY2NlcHQtRW5jb2Rpbmc6IGd6 aXAsIGNvbXByZXNzDQ0KQWNjZXB0LUxhbmd1YWdlOiBlbg0NCk5lZ290aWF0 ZTogdHJhbnMNDQpVc2VyLUFnZW50OiBMeW54LzIuNy4xIGxpYnd3dy1GTS8y LjE0DQ0KDQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K U2VuZGluZyBIVFRQIHJlcXVlc3QuDQpIVFRQOiBXUklURSBkZWxpdmVyZWQg T0sNCkhUVFAgcmVxdWVzdCBzZW50OyB3YWl0aW5nIGZvciByZXNwb25zZS4N CkhUVFA6IFRyeWluZyB0byByZWFkIDEwMjMNCkhUVFA6IFJlYWQgMTAyMw0K UmVhZCAxMDIzIGJ5dGVzIG9mIGRhdGEuDQpIVFRQOiBSeDogSFRUUC8xLjEg MjAwIE9LIA0KSFRUUDogU2Nhbm5lZCAyIGZpZWxkcyBmcm9tIGxpbmVfYnVm ZmVyDQotLS0gVGFsa2luZyBIVFRQMS4NCkhUVFAvMS4xIDIwMCBPSw0KSFRG b3JtYXQ6IENvbnN0cnVjdGluZyBzdHJlYW0gc3RhY2sgZm9yIHd3dy9taW1l IHRvIHd3dy9wcmVzZW50DQpTdHJlYW1TdGFjazogZm91bmQgd2VhayB3aWxk Y2FyZCBtYXRjaDogd3d3L3ByZXNlbnQNClN0cmVhbVN0YWNrOiBmb3VuZCBl eGFjdCBtYXRjaDogd3d3L21pbWUNCkhUTUlNRTogIFNlcnZlcjogTmV0c2Nh cGUtRW50ZXJwcmlzZS8zLjUuMQ0NCkRhdGU6IFRodSwgMTkgTm92IDE5OTgg MTk6NTc6MzcgR01UDQ0KQ29udGVudC10eXBlOiB0ZXh0L2h0bWwNDQpDb250 ZW50LWxlbmd0aDogMjcxMzUNDQpDb25uZWN0aW9uOiBjbG9zZQ0NCg0NCg0K DQoNCg0KPEhUTUw+CQ0KPEhFQUQ+DQo8TUVUQSBIVFRQLUVRVUlWPSJjb250 ZW50LXR5cGUiIENPTlRFTlQ9InRleHQvaHRtbDtjaGFyc2V0PWlzby04ODU5 LTEiPg0KPE1FVEEgbmFtZT0iRGVzY3JpcHRpb24iIGNvbnRlbnQ9IlRoZSBB c3NvY2lhdGVkIFByZXNzIGlzIHRoZSBuZXdzIGluZHVzdHJ5J3MgbW9zdCBp bW1lZGlhdGUsIGNvbXByZWhlbnNpdmUgYW5kIGNyZWRpYmxlIHNvdXJjZSBv ZiBicmVha2luZyBuZXdzLiBUaGUgV2lyZSBpcyB0aGUgQVAncyByZWFsLXRp bWUgaW50ZXJuZXQgc2VydmljZS4iPg0KPE1FVEEgbmFtZT0iS2V5d29yZHMi IGNvbnRlbnQ9IkFzc29jaWF0ZWQgUHJlc3MsIG5hdGlvbmFsIG5ld3MsIHRl Y2hub2xvZ3kgbmV3cywgbmF0aW9uYWwsIGJ1c2luZXNzLCB3ZWF0aGVyLCBu ZXdzLCBpbnRlcm5hdGlvbmFsLCBlbnRlcnRhaW5tZW50LCBzcG9ydHMsIGFy dHMsIEFQLCBUaGUgV2lyZSwgZmFzaGlvbiwgQXNzb2NpYXRlZCBQcmVzcywg aW50ZXJuYXRpb25hbCwgQVAsIHRlY2hub2xvZ3ksIFRoZSBXaXJlLCBmYXNo aW9uLCBidXNpbmVzcywgZW50ZXJ0YWlubWVudCwgc3BvcnRzLCB3ZWF0aGVy LCBhcnRzLCB3ZWF0aGVyLCBpbnRlcm5hdGlvbmFsLCBzcG9ydHMgbmV3cywg YXJ0cywgQVAsIG5hdGlvbmFsLCB0ZWNobm9sb2d5LCBUaGUgV2lyZSwgZW50 ZXJ0YWlubWVudCwgYnVzaW5lc3MsIGZhc2hpb24sIEFzc29jaWF0ZWQgUHJl c3MsIFRoZSBXaXJlLCBBUCwgdGVjaG5vbG9neSwgd2VhdGhlciwgZmFzaGlv biwgQXNzb2NpYXRlZCBQcmVzcywgZW50ZXJ0YWlubWVudCBuZXdzLCBzcG9y dHMsIGFydHMsIGludGVybmF0aW9uYWwsIG5hdGlvbmFsLCBidXNpbmVzcywg c3BvcnRzLCB3ZWF0aGVyLA0KSFRNSU1FOiBHb3QgJ1MnIGF0IGJlZ2lubmlu ZyBvZiBsaW5lLCBzdGF0ZSBub3cgUw0KSFRNSU1FOiBXYXMgUywgZm91bmQg RSwgc3RhdGUgbm93IFNFJw0KSFRNSU1FOiBXYXMgU0UsIGZvdW5kIFIsIGNo ZWNraW5nIGZvciAndmVyJw0KSFRNSU1FOiBQSUNLRUQgVVAgU2VydmVyOiAn TmV0c2NhcGUtRW50ZXJwcmlzZS8zLjUuMScNCkhUTUlNRTogR290ICdEJyBh dCBiZWdpbm5pbmcgb2YgbGluZSwgY2hlY2tpbmcgZm9yICdhdGU6Jw0KSFRN SU1FOiBQSUNLRUQgVVAgRGF0ZTogJ1RodSwgMTkgTm92IDE5OTggMTk6NTc6 MzcgR01UJw0KSFRNSU1FOiBHb3QgJ0MnIGF0IGJlZ2lubmluZyBvZiBsaW5l LCBzdGF0ZSBub3cgQw0KSFRNSU1FOiBXYXMgQywgZm91bmQgTywgc3RhdGUg bm93IENPJw0KSFRNSU1FOiBXYXMgQ08sIGZvdW5kIE4sIHN0YXRlIG5vdyBD T04NCkhUTUlNRTogV2FzIENPTiwgZm91bmQgVCwgY2hlY2tpbmcgZm9yICdl bnQtJw0KSFRNSU1FOiBpbiBjYXNlIENPTlRFTlRfDQpIVE1JTUU6IFdhcyBD T05URU5UXywgZm91bmQgVCwgc3RhdGUgbm93IENPTlRFTlRfVA0KSFRNSU1F OiBpbiBjYXNlIENPTlRFTlRfVA0KSFRNSU1FOiBXYXMgQ09OVEVOVF9ULCBm b3VuZCBZLCBjaGVja2luZyBmb3IgJ3BlOicNCkhUTUlNRTogUElDS0VEIFVQ IENvbnRlbnQtVHlwZTogJ3RleHQvaHRtbCcNCkhUTUlNRTogR290ICdDJyBh dCBiZWdpbm5pbmcgb2YgbGluZSwgc3RhdGUgbm93IEMNCkhUTUlNRTogV2Fz IEMsIGZvdW5kIE8sIHN0YXRlIG5vdyBDTycNCkhUTUlNRTogV2FzIENPLCBm b3VuZCBOLCBzdGF0ZSBub3cgQ09ODQpIVE1JTUU6IFdhcyBDT04sIGZvdW5k IFQsIGNoZWNraW5nIGZvciAnZW50LScNCkhUTUlNRTogaW4gY2FzZSBDT05U RU5UXw0KSFRNSU1FOiBXYXMgQ09OVEVOVF8sIGZvdW5kIEwsIHN0YXRlIG5v dyBDT05URU5UX0wNCkhUTUlNRTogaW4gY2FzZSBDT05URU5UX0wNCkhUTUlN RTogV2FzIENPTlRFTlRfTCwgZm91bmQgRSwgY2hlY2tpbmcgZm9yICduZ3Ro OicNCkhUTUlNRTogUElDS0VEIFVQIENvbnRlbnQtTGVuZ3RoOiAnMjcxMzUn DQogICAgICAgIENvbnZlcnRlZCB0byBpbnRlZ2VyOiAnMjcxMzUnDQpIVE1J TUU6IEdvdCAnQycgYXQgYmVnaW5uaW5nIG9mIGxpbmUsIHN0YXRlIG5vdyBD DQpIVE1JTUU6IFdhcyBDLCBmb3VuZCBPLCBzdGF0ZSBub3cgQ08nDQpIVE1J TUU6IFdhcyBDTywgZm91bmQgTiwgc3RhdGUgbm93IENPTg0KSFRNSU1FOiBX YXMgQ09OLCBmb3VuZCBOLCBjaGVja2luZyBmb3IgJ2VjdGlvbjonDQpIVE1J TUU6IFBJQ0tFRCBVUCBDb25uZWN0aW9uOiAnY2xvc2UnDQpIVE1JTUU6IE1J TUUgQ29udGVudC1UeXBlIGlzICd0ZXh0L2h0bWwnLCBjb252ZXJ0aW5nIHRv ICd3d3cvcHJlc2VudCcNCkhURm9ybWF0OiBDb25zdHJ1Y3Rpbmcgc3RyZWFt IHN0YWNrIGZvciB0ZXh0L2h0bWwgdG8gd3d3L3ByZXNlbnQNClN0cmVhbVN0 YWNrOiBmb3VuZCBleGFjdCBtYXRjaDogdGV4dC9odG1sDQpTR01MOiBTdGFy dCA8SFRNTD4NCkdyaWRUZXh0OiBDaGFuZ2UgdG8gc3R5bGUgTm9ybWFsDQpH cmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkhUTUw6YmVnaW5fZWxlbWVu dDogYWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFy dCA8SEVBRD4NCkhUTUw6YmVnaW5fZWxlbWVudDogYWRkaW5nIHN0eWxlIHRv IHN0YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFydCA8TUVUQT4NCkxZSGFuZGxl TUVUQTogSFRUUC1FUVVJVj0iY29udGVudC10eXBlIiBOQU1FPSJOVUxMIiBD T05URU5UPSJ0ZXh0L2h0bWw7Y2hhcnNldD1pc28tODg1OS0xIg0KSFRNTDog TmV3IGNoYXJzZXQ6IGlzby04ODU5LTENClNHTUw6IFN0YXJ0IDxNRVRBPg0K TFlIYW5kbGVNRVRBOiBIVFRQLUVRVUlWPSJOVUxMIiBOQU1FPSJEZXNjcmlw dGlvbiIgQ09OVEVOVD0iVGhlIEFzc29jaWF0ZWQgUHJlc3MgaXMgdGhlIG5l d3MgaW5kdXN0cnkncyBtb3N0IGltbWVkaWF0ZSwgY29tcHJlaGVuc2l2ZSBh bmQgY3JlZGlibGUgc291cmNlIG9mIGJyZWFraW5nIG5ld3MuIFRoZSBXaXJl IGlzIHRoZSBBUCdzIHJlYWwtdGltZSBpbnRlcm5ldCBzZXJ2aWNlLiINClNH TUw6IFN0YXJ0IDxNRVRBPg0KTFlIYW5kbGVNRVRBOiBIVFRQLUVRVUlWPSJO VUxMIiBOQU1FPSJLZXl3b3JkcyIgQ09OVEVOVD0iQXNzb2NpYXRlZCBQcmVz cywgbmF0aW9uYWwgbmV3cywgdGVjaG5vbG9neSBuZXdzLCBuYXRpb25hbCwg YnVzaW5lc3MsIHdlYXRoZXIsIG5ld3MsIGludGVybmF0aW9uYWwsIGVudGVy dGFpbm1lbnQsIHNwb3J0cywgYXJ0cywgQVAsIFRoZSBXaXJlLCBmYXNoaW9u LCBBc3NvY2lhdGVkIFByZXNzLCBpbnRlcm5hdGlvbmFsLCBBUCwgdGVjaG5v bG9neSwgVGhlIFdpcmUsIGZhc2hpb24sIGJ1c2luZXNzLCBlbnRlcnRhaW5t ZW50LCBzcG9ydHMsIHdlYXRoZXIsIGFydHMsIHdlYXRoZXIsIGludGVybmF0 aW9uYWwsIHNwb3J0cyBuZXdzLCBhcnRzLCBBUCwgbmF0aW9uYWwsIHRlY2hu b2xvZ3ksIFRoZSBXaXJlLCBlbnRlcnRhaW5tZW50LCBidXNpbmVzcywgZmFz aGlvbiwgQXNzb2NpYXRlZCBQcmVzcywgVGhlIFdpcmUsIEFQLCB0ZWNobm9s b2d5LCB3ZWF0aGVyLCBmYXNoaW9uLCBBc3NvY2lhdGVkIFByZXNzLCBlbnRl cnRhaW5tZW50IG5ld3MsIHNwb3J0cywgYXJ0cywgaW50ZXJuYXRpb25hbCwg bmF0aW9uYWwsIGJ1c2luZXNzLCBzcG9ydHMsIHdlYXRoZXIsIEFzc29jaWF0 ZWQgUHJlc3MsIHRlY2hub2xvZ3ksIFRoZSBXaXJlLCBBUCwgaW50ZXJuYXRp b25hbCBuZXdzLCBidXNpbmVzcywgZmFzaGlvbiwgZW50ZXJ0YWlubWVudCwg YXJ0cywgbmF0aW9uYWwsIG5hdGlvbmFsLCBUaGUgV2lyZSwgYXJ0cywgQVAs IGJ1c2luZXNzIG5ld3MsIHdlYXRoZXIsIGVudGVydGFpbm1lbnQsIHNwb3J0 cywgdGVjaG5vbG9neSwgaW50ZXJuYXRpb25hbCwgQXNzb2NpYXRlZCBQcmVz cywgZmFzaGlvbiwgdGVjaG5vbG9neSwgYnVzaW5lc3MsIGZhc2hpb24sIHdl YXRoZXIsIGludGVybmF0aW9uYWwsIHNwb3J0cywgVGhlIFdpcmUsIEFzc29j aWF0ZWQgUHJlc3MsIGFydHMsIEFQLCBlbnRlcnRhaW5tZW50LCBuYXRpb25h bCINClNHTUw6IFN0YXJ0IDxUSVRMRT4NCkhUTUw6YmVnaW5fZWxlbWVudDog YWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpSZWFkIDQzNyBvZiAy NzEzNSBieXRlcyBvZiBkYXRhLg0KU0dNTDogRW5kIDwvVElUTEU+DQpIVE1M OmVuZF9lbGVtZW50OiBQb3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0gTm9ybWFs DQpTR01MOiBFbmQgPC9IRUFEPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVk IHN0eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KU0dNTDogU3RhcnQgPEJPRFk+ DQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAt IE5vcm1hbA0KU0dNTDogU3RhcnQgPFA+DQpTR01MOiBTdGFydCA8VEFCTEU+ DQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAt IE5vcm1hbA0KU0dNTDogU3RhcnQgPFRSPg0KU0dNTDogU3RhcnQgPFREPg0K U0dNTDogU3RhcnQgPFRBQkxFPg0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRp bmcgc3R5bGUgdG8gc3RhY2sgLSBOb3JtYWwNClNHTUw6IFN0YXJ0IDxUUj4N ClNHTUw6IFN0YXJ0IDxURD4NClNHTUw6IFN0YXJ0IDxQPg0KU0dNTDogU3Rh cnQgPEZPTlQ+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNHTUw6 IGA8L0ZPTlQ+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8Rk9OVD4nLg0KU0dN TDogU3RhcnQgPEZPTlQ+DQpTR01MOiBgPC9QPicgZm91bmQhICBUcmVhdGlu ZyBhcyAnPFA+Jy4NClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRleHQ6IHNwbGl0 X2xpbmUgY2FsbGVkDQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNH TUw6IFN0YXJ0IDxQPg0KU0dNTDogU3RhcnQgPEE+DQpuZXcgQW5jaG9yIDE0 MDA2OGFmMCBuYW1lZCBgJyBpcyBjaGlsZCBvZiAxNDAwNjE3YzANCkVudGVy ZWQgSFRBbmNob3JfZmluZENoaWxkQW5kTGluaw0KSFRQYXJzZTogYU5hbWU6 aHR0cDovL3d3dy5uZXRzY2FwZS5jb20vZG93bmxvYWQvICAgcmVsYXRlZE5h bWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0bWwNCjENCkhU UGFyc2U6IHJlc3VsdDpodHRwOi8vd3d3Lm5ldHNjYXBlLmNvbS9kb3dubG9h ZC8NCkhUUGFyc2U6IGFOYW1lOmh0dHA6Ly93d3cubmV0c2NhcGUuY29tL2Rv d25sb2FkLyAgIHJlbGF0ZWROYW1lOg0KSFRQYXJzZTogcmVzdWx0Og0KRW50 ZXJlZCBIVEFuY2hvcl9maW5kQWRkcmVzcw0KTmV3IGFuY2hvciAxNDAwNjE5 MDAgaGFzIGhhc2ggNTIgYW5kIGFkZHJlc3MgYGh0dHA6Ly93d3cubmV0c2Nh cGUuY29tL2Rvd25sb2FkLycNCkxpbmtpbmcgYW5jaG9yIDE0MDA2OGFmMCB0 byBhbmNob3IgMTQwMDYxOTAwDQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGlu ZyBzdHlsZSB0byBzdGFjayAtIE5vcm1hbA0KU0dNTDogU3RhcnQgPElNRz4N CkhUTUwgSU1HOiBVU0VNQVA9MCBJU01BUD0wIEFOQ0hPUj0xIFBBUkE9MA0K U0dNTDogRW5kIDwvQT4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBzdHls ZSBvZmYgc3RhY2sgLSBOb3JtYWwNClNHTUw6IGA8L1A+JyBmb3VuZCEgIFRy ZWF0aW5nIGFzICc8UD4nLg0KU0dNTDogU3RhcnQgPFA+DQpHcmlkVGV4dDog c3BsaXRfbGluZSBjYWxsZWQNCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxl ZA0KU0dNTDogU3RhcnQgPFA+DQpTR01MOiBTdGFydCA8QT4NCm5ldyBBbmNo b3IgMTQwMDlmMjQwIG5hbWVkIGAnIGlzIGNoaWxkIG9mIDE0MDA2MTdjMA0K RW50ZXJlZCBIVEFuY2hvcl9maW5kQ2hpbGRBbmRMaW5rDQpIVFBhcnNlOiBh TmFtZTpodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vaWUvZG93bmxvYWQvICAg cmVsYXRlZE5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWluLmh0 bWwNCjENCkhUUGFyc2U6IHJlc3VsdDpodHRwOi8vd3d3Lm1pY3Jvc29mdC5j b20vaWUvZG93bmxvYWQvDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd3d3Lm1p Y3Jvc29mdC5jb20vaWUvZG93bmxvYWQvICAgcmVsYXRlZE5hbWU6DQpIVFBh cnNlOiByZXN1bHQ6DQpFbnRlcmVkIEhUQW5jaG9yX2ZpbmRBZGRyZXNzDQpO ZXcgYW5jaG9yIDE0MDA2MWE0MCBoYXMgaGFzaCA5MSBhbmQgYWRkcmVzcyBg aHR0cDovL3d3dy5taWNyb3NvZnQuY29tL2llL2Rvd25sb2FkLycNCkxpbmtp bmcgYW5jaG9yIDE0MDA5ZjI0MCB0byBhbmNob3IgMTQwMDYxYTQwDQpIVE1M OmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAtIE5vcm1h bA0KU0dNTDogU3RhcnQgPElNRz4NCkhUTUwgSU1HOiBVU0VNQVA9MCBJU01B UD0wIEFOQ0hPUj0xIFBBUkE9MA0KU0dNTDogRW5kIDwvQT4NCkhUTUw6ZW5k X2VsZW1lbnQ6IFBvcHBlZCBzdHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNClNH TUw6IGA8L1A+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8UD4nLg0KU0dNTDog U3RhcnQgPFA+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdyaWRU ZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPFA+DQpTR01M OiBTdGFydCA8Qj4NCkJlZ2lubmluZyB1bmRlcmxpbmUNCkhUTUw6YmVnaW5f ZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpTR01M OiBTdGFydCA8Rk9OVD4NClNHTUw6IGA8L0ZPTlQ+JyBmb3VuZCEgIFRyZWF0 aW5nIGFzICc8Rk9OVD4nLg0KU0dNTDogU3RhcnQgPEZPTlQ+DQpTR01MOiBF bmQgPC9CPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0eWxlIG9mZiBz dGFjayAtIE5vcm1hbA0KRW5kaW5nIHVuZGVybGluZQ0KU0dNTDogU3RhcnQg PEZPTlQ+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdyaWRUZXh0 OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPEJSPg0KR3JpZFRl eHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBgPC9GT05UPicgZm91bmQh ICBUcmVhdGluZyBhcyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0IDxGT05UPg0K U0dNTDogU3RhcnQgPEI+DQpCZWdpbm5pbmcgdW5kZXJsaW5lDQpIVE1MOmJl Z2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAtIE5vcm1hbA0K U0dNTDogU3RhcnQgPEZPTlQ+DQpTR01MOiBTdGFydCA8QT4NCm5ldyBBbmNo b3IgMTQwMDlmMzMwIG5hbWVkIGAnIGlzIGNoaWxkIG9mIDE0MDA2MTdjMA0K RW50ZXJlZCBIVEFuY2hvcl9maW5kQ2hpbGRBbmRMaW5rDQpIVFBhcnNlOiBh TmFtZTpodHRwOi8vd3d3LmFvbC5jb20vdHJ5YW9sL2Rvd25sb2FkLmh0bWwg ICByZWxhdGVkTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4u aHRtbA0KMQ0KSFRQYXJzZTogcmVzdWx0Omh0dHA6Ly93d3cuYW9sLmNvbS90 cnlhb2wvZG93bmxvYWQuaHRtbA0KSFRQYXJzZTogYU5hbWU6aHR0cDovL3d3 dy5hb2wuY29tL3RyeWFvbC9kb3dubG9hZC5odG1sICAgcmVsYXRlZE5hbWU6 DQpIVFBhcnNlOiByZXN1bHQ6DQpFbnRlcmVkIEhUQW5jaG9yX2ZpbmRBZGRy ZXNzDQpOZXcgYW5jaG9yIDE0MDA2MWI4MCBoYXMgaGFzaCAwIGFuZCBhZGRy ZXNzIGBodHRwOi8vd3d3LmFvbC5jb20vdHJ5YW9sL2Rvd25sb2FkLmh0bWwn DQpMaW5raW5nIGFuY2hvciAxNDAwOWYzMzAgdG8gYW5jaG9yIDE0MDA2MWI4 MA0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRpbmcgc3R5bGUgdG8gc3RhY2sg LSBOb3JtYWwNClNHTUw6IEVuZCA8L0E+DQpIVE1MOmVuZF9lbGVtZW50OiBQ b3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0gTm9ybWFsDQpTR01MOiBgPC9GT05U PicgZm91bmQhICBUcmVhdGluZyBhcyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0 IDxGT05UPg0KU0dNTDogRW5kIDwvQj4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBv cHBlZCBzdHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNCkVuZGluZyB1bmRlcmxp bmUNClNHTUw6IGA8L1REPicgZm91bmQhICBJZ25vcmluZyBpdC4NClNHTUw6 IGA8L1RSPicgZm91bmQhICBJZ25vcmluZyBpdC4NClNHTUw6IEVuZCA8L1RB QkxFPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0eWxlIG9mZiBzdGFj ayAtIE5vcm1hbA0KU0dNTDogYDwvVEQ+JyBmb3VuZCEgIElnbm9yaW5nIGl0 Lg0KU0dNTDogU3RhcnQgPFREPg0KU0dNTDogU3RhcnQgPFRBQkxFPg0KSFRN TDpiZWdpbl9lbGVtZW50OiBhZGRpbmcgc3R5bGUgdG8gc3RhY2sgLSBOb3Jt YWwNClNHTUw6IFN0YXJ0IDxUUj4NCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNh bGxlZA0KUmVhZCAxODk3IG9mIDI3MTM1IGJ5dGVzIG9mIGRhdGEuDQpTR01M OiBTdGFydCA8VEQ+DQpTR01MOiBTdGFydCA8UD4NCkdyaWRUZXh0OiBzcGxp dF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPEE+DQpuZXcgQW5jaG9yIDE0 MDA5ZjQ1MCBuYW1lZCBgJyBpcyBjaGlsZCBvZiAxNDAwNjE3YzANCkVudGVy ZWQgSFRBbmNob3JfZmluZENoaWxkQW5kTGluaw0KSFRQYXJzZTogYU5hbWU6 aHR0cDovL3dpcmUuYXAub3JnL0dvVG9BUC5jZ2kgICByZWxhdGVkTmFtZTpo dHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KMQ0KSFRQYXJz ZTogcmVzdWx0Omh0dHA6Ly93aXJlLmFwLm9yZy9Hb1RvQVAuY2dpDQpIVFBh cnNlOiBhTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvR29Ub0FQLmNnaSAgIHJl bGF0ZWROYW1lOg0KSFRQYXJzZTogcmVzdWx0Og0KRW50ZXJlZCBIVEFuY2hv cl9maW5kQWRkcmVzcw0KTmV3IGFuY2hvciAxNDAwNjFjYzAgaGFzIGhhc2gg ODAgYW5kIGFkZHJlc3MgYGh0dHA6Ly93aXJlLmFwLm9yZy9Hb1RvQVAuY2dp Jw0KTGlua2luZyBhbmNob3IgMTQwMDlmNDUwIHRvIGFuY2hvciAxNDAwNjFj YzANCkhUTUw6YmVnaW5fZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0YWNr IC0gTm9ybWFsDQpTR01MOiBTdGFydCA8SU1HPg0KSFRNTCBJTUc6IFVTRU1B UD0wIElTTUFQPTAgQU5DSE9SPTEgUEFSQT0wDQpTR01MOiBFbmQgPC9BPg0K SFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0eWxlIG9mZiBzdGFjayAtIE5v cm1hbA0KU0dNTDogU3RhcnQgPEJSPg0KR3JpZFRleHQ6IHNwbGl0X2xpbmUg Y2FsbGVkDQpTR01MOiBgPC9QPicgZm91bmQhICBUcmVhdGluZyBhcyAnPFA+ Jy4NClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRleHQ6IHNwbGl0X2xpbmUgY2Fs bGVkDQpTR01MOiBTdGFydCA8UD4NClNHTUw6IFN0YXJ0IDxCPg0KQmVnaW5u aW5nIHVuZGVybGluZQ0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRpbmcgc3R5 bGUgdG8gc3RhY2sgLSBOb3JtYWwNClNHTUw6IFN0YXJ0IDxGT05UPg0KR3Jp ZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBgPC9GT05UPicgZm91 bmQhICBUcmVhdGluZyBhcyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0IDxGT05U Pg0KU0dNTDogRW5kIDwvQj4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBz dHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNCkVuZGluZyB1bmRlcmxpbmUNClNH TUw6IGA8L1A+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8UD4nLg0KU0dNTDog U3RhcnQgPFA+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdyaWRU ZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPFA+DQpTR01M OiBTdGFydCA8Qj4NCkJlZ2lubmluZyB1bmRlcmxpbmUNCkhUTUw6YmVnaW5f ZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpTR01M OiBTdGFydCA8Rk9OVD4NCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0K R3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBgPC9GT05UPicg Zm91bmQhICBUcmVhdGluZyBhcyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0IDxG T05UPg0KU0dNTDogU3RhcnQgPEE+DQpuZXcgQW5jaG9yIDE0MDA5ZjRlMCBu YW1lZCBgJyBpcyBjaGlsZCBvZiAxNDAwNjE3YzANCkVudGVyZWQgSFRBbmNo b3JfZmluZENoaWxkQW5kTGluaw0KSFRQYXJzZTogYU5hbWU6aHR0cDovL3dp cmUuYXAub3JnL0dvVG9BUC5jZ2kgICByZWxhdGVkTmFtZTpodHRwOi8vd2ly ZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KMQ0KSFRQYXJzZTogcmVzdWx0 Omh0dHA6Ly93aXJlLmFwLm9yZy9Hb1RvQVAuY2dpDQpIVFBhcnNlOiBhTmFt ZTpodHRwOi8vd2lyZS5hcC5vcmcvR29Ub0FQLmNnaSAgIHJlbGF0ZWROYW1l Og0KSFRQYXJzZTogcmVzdWx0Og0KRW50ZXJlZCBIVEFuY2hvcl9maW5kQWRk cmVzcw0KQW5jaG9yIDE0MDA2MWNjMCB3aXRoIGFkZHJlc3MgYGh0dHA6Ly93 aXJlLmFwLm9yZy9Hb1RvQVAuY2dpJyBhbHJlYWR5IGV4aXN0cy4NCkxpbmtp bmcgYW5jaG9yIDE0MDA5ZjRlMCB0byBhbmNob3IgMTQwMDYxY2MwDQpIVE1M OmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAtIE5vcm1h bA0KU0dNTDogU3RhcnQgPEZPTlQ+DQpTR01MOiBgPC9mb250PicgZm91bmQh ICBUcmVhdGluZyBhcyAnPGZvbnQ+Jy4NClNHTUw6IFN0YXJ0IDxGT05UPg0K U0dNTDogRW5kIDwvQT4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBzdHls ZSBvZmYgc3RhY2sgLSBOb3JtYWwNClNHTUw6IFN0YXJ0IDxGT05UPg0KU0dN TDogYDwvRk9OVD4nIGZvdW5kISAgVHJlYXRpbmcgYXMgJzxGT05UPicuDQpT R01MOiBTdGFydCA8Rk9OVD4NClNHTUw6IEVuZCA8L0I+DQpIVE1MOmVuZF9l bGVtZW50OiBQb3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0gTm9ybWFsDQpFbmRp bmcgdW5kZXJsaW5lDQpTR01MOiBgPC9URD4nIGZvdW5kISAgSWdub3Jpbmcg aXQuDQpTR01MOiBgPC9UUj4nIGZvdW5kISAgSWdub3JpbmcgaXQuDQpTR01M OiBTdGFydCA8VFI+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNH TUw6IFN0YXJ0IDxURD4NClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRleHQ6IHNw bGl0X2xpbmUgY2FsbGVkDQpTR01MOiBTdGFydCA8Rk9STT4NCkhUUGFyc2U6 IGFOYW1lOmh0dHA6Ly93aXJlLmFwLm9yZy8gICByZWxhdGVkTmFtZTpodHRw Oi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KMQ0KSFRQYXJzZTog cmVzdWx0Omh0dHA6Ly93aXJlLmFwLm9yZy8NCm5ldyBBbmNob3IgMTQwMDlm NWEwIG5hbWVkIGAnIGlzIGNoaWxkIG9mIDE0MDA2MTdjMA0KRW50ZXJlZCBI VEFuY2hvcl9maW5kQ2hpbGRBbmRMaW5rDQpIVFBhcnNlOiBhTmFtZTpodHRw Oi8vd2lyZS5hcC5vcmcvICAgcmVsYXRlZE5hbWU6aHR0cDovL3dpcmUuYXAu b3JnL0FQbmV3cy9tYWluLmh0bWwNCjENCkhUUGFyc2U6IHJlc3VsdDpodHRw Oi8vd2lyZS5hcC5vcmcvDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2lyZS5h cC5vcmcvICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6DQpFbnRl cmVkIEhUQW5jaG9yX2ZpbmRBZGRyZXNzDQpOZXcgYW5jaG9yIDE0MDA2MWUw MCBoYXMgaGFzaCA5IGFuZCBhZGRyZXNzIGBodHRwOi8vd2lyZS5hcC5vcmcv Jw0KTGlua2luZyBhbmNob3IgMTQwMDlmNWEwIHRvIGFuY2hvciAxNDAwNjFl MDANCkJlZ2luRm9ybTogYWN0aW9uOmh0dHA6Ly93aXJlLmFwLm9yZy8gTWV0 aG9kOjENCkhUTUw6YmVnaW5fZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0 YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFydCA8SU5QVVQ+DQpFbnRlcmluZyBI VGV4dF9iZWdpbklucHV0DQpJbnB1dCBsaW5rOiBuYW1lPUZST05USUQNCnZh bHVlPUhPTUUNCnNpemU9MA0KU0dNTDogU3RhcnQgPEI+DQpCZWdpbm5pbmcg dW5kZXJsaW5lDQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0 byBzdGFjayAtIE5vcm1hbA0KU0dNTDogU3RhcnQgPEZPTlQ+DQpTR01MOiBg PC9GT05UPicgZm91bmQhICBUcmVhdGluZyBhcyAnPEZPTlQ+Jy4NClNHTUw6 IFN0YXJ0IDxGT05UPg0KU0dNTDogRW5kIDwvQj4NCkhUTUw6ZW5kX2VsZW1l bnQ6IFBvcHBlZCBzdHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNCkVuZGluZyB1 bmRlcmxpbmUNClNHTUw6IGA8L1A+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8 UD4nLg0KU0dNTDogU3RhcnQgPFA+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBj YWxsZWQNCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3Rh cnQgPFA+DQpTR01MOiBTdGFydCA8U0VMRUNUPg0KSFRNTDogSWdub3Jpbmcg U0laRT0iMSIgZm9yIFNFTEVDVC4NCkhUZXh0X2JlZ2luU2VsZWN0OiBuYW1l PVNJVEUgdHlwZT00IHNpemU9PE5VTEw+DQpIVE1MOmJlZ2luX2VsZW1lbnQ6 IGFkZGluZyBzdHlsZSB0byBzdGFjayAtIE5vcm1hbA0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X2JlZ2luSW5wdXQNCklucHV0IGxp bms6IG5hbWU9U0lURQ0KdmFsdWU9DQpzaXplPTIwDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6UHVsbCBkb3duIGxpc3QNCiAgICAgICAg ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6Q09O TkVDVElDVVQNCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClJlYWQgMzM1NyBv ZiAyNzEzNSBieXRlcyBvZiBkYXRhLg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOi0gQ1QgQ2VudHJhbCANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBIYXJ0Zm9yZCBDb3VyYW50IA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOk1BSU5FDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBC YW5nb3IgRGFpbHkgTmV3cyBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gS2VubmViZWMgSm91cm5hbCANCiAgICAgICAg IA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBNb3JuaW5nIFNlbnRpbmVs IE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBQb3J0bGFuZCBQcmVzcyBIZXJhbGQgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gU3VuLUpvdXJuYWwgT25saW5lIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOk1BUllMQU5EDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBDYXBpdGFsIE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBDYXJyb2xsIENvdW50eSBPbmxpbmUgDQogICAgICAgICAN CiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gU3VuU3BvdCANCiAgICAgICAg IA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgRnJlZGVyaWNrIE5l d3MtUG9zdCANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpNQVNTQUNI VVNFVFRTDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBCb3N0b25oZXJhbGQuY29tIA0KICAg ICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNH TUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09Q VElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcg SFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEdhemV0dGVORVQg DQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9m Zg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFn IDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRl cmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gTWFzcyBM aXZlIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRh bmdvISAoV29yY2VzdGVyIFRlbGVncmFtICYgR2F6ZXR0ZSBPbmxpbmUpIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpSZWFkIDQ4MTcgb2YgMjcxMzUgYnl0ZXMgb2Yg ZGF0YS4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIENocmlzdGlhbiBTY2ll bmNlIE1vbml0b3IgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6TkVX IEhBTVBTSElSRQ0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gQ29uY29yZCBNb25pdG9yIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIE5ldyBIYW1w c2hpcmUgU2VudGluZWwgU291cmNlIA0KICAgICAgICAgDQogICAgICAgICAN CiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTotIFZhbGxleSBOZXdzIE9ubGluZSANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpSSE9ERSBJU0xBTkQNCiAg ICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNH TUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBT dGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZh bHVlOiB2YWx1ZTotIFByb2pvLmNvbSBKb3VybmFsIEJ1bGxldGluIA0KICAg ICAgICAgDQoJCSwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBFbmQgPC9TRUxFQ1Q+DQpIVE1MOmVuZF9lbGVtZW50OiBQb3BwZWQgc3R5 bGUgb2ZmIHN0YWNrIC0gTm9ybWFsDQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCgkJLCBjaGVja2VkOm9mZg0KU0dN TDogU3RhcnQgPElOUFVUPg0KRW50ZXJpbmcgSFRleHRfYmVnaW5JbnB1dA0K SW5wdXQgbGluazogbmFtZT0NCnZhbHVlPUdvDQpzaXplPTIwDQpHcmlkVGV4 dDogc3BsaXRfbGluZSBjYWxsZWQNClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRl eHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpHcmlkVGV4dDogc3BsaXRfbGluZSBj YWxsZWQNClNHTUw6IEVuZCA8L0ZPUk0+DQpIVE1MOmVuZF9lbGVtZW50OiBQ b3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0gTm9ybWFsDQpHcmlkVGV4dDogc3Bs aXRfbGluZSBjYWxsZWQNClNHTUw6IFN0YXJ0IDxGT1JNPg0KSFRQYXJzZTog YU5hbWU6aHR0cDovL3dpcmUuYXAub3JnLyAgIHJlbGF0ZWROYW1lOmh0dHA6 Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFpbi5odG1sDQoxDQpIVFBhcnNlOiBy ZXN1bHQ6aHR0cDovL3dpcmUuYXAub3JnLw0KbmV3IEFuY2hvciAxNDAwOWY5 OTAgbmFtZWQgYCcgaXMgY2hpbGQgb2YgMTQwMDYxN2MwDQpFbnRlcmVkIEhU QW5jaG9yX2ZpbmRDaGlsZEFuZExpbmsNCkhUUGFyc2U6IGFOYW1lOmh0dHA6 Ly93aXJlLmFwLm9yZy8gICByZWxhdGVkTmFtZTpodHRwOi8vd2lyZS5hcC5v cmcvQVBuZXdzL21haW4uaHRtbA0KMQ0KSFRQYXJzZTogcmVzdWx0Omh0dHA6 Ly93aXJlLmFwLm9yZy8NCkhUUGFyc2U6IGFOYW1lOmh0dHA6Ly93aXJlLmFw Lm9yZy8gICByZWxhdGVkTmFtZToNCkhUUGFyc2U6IHJlc3VsdDoNCkVudGVy ZWQgSFRBbmNob3JfZmluZEFkZHJlc3MNCkFuY2hvciAxNDAwNjFlMDAgd2l0 aCBhZGRyZXNzIGBodHRwOi8vd2lyZS5hcC5vcmcvJyBhbHJlYWR5IGV4aXN0 cy4NCkxpbmtpbmcgYW5jaG9yIDE0MDA5Zjk5MCB0byBhbmNob3IgMTQwMDYx ZTAwDQpCZWdpbkZvcm06IGFjdGlvbjpodHRwOi8vd2lyZS5hcC5vcmcvIE1l dGhvZDoxDQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBz dGFjayAtIE5vcm1hbA0KU0dNTDogU3RhcnQgPElOUFVUPg0KRW50ZXJpbmcg SFRleHRfYmVnaW5JbnB1dA0KSW5wdXQgbGluazogbmFtZT1GUk9OVElEDQp2 YWx1ZT1IT01FDQpzaXplPTANClNHTUw6IFN0YXJ0IDxCPg0KQmVnaW5uaW5n IHVuZGVybGluZQ0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRpbmcgc3R5bGUg dG8gc3RhY2sgLSBOb3JtYWwNClNHTUw6IFN0YXJ0IDxGT05UPg0KU0dNTDog YDwvRk9OVD4nIGZvdW5kISAgVHJlYXRpbmcgYXMgJzxGT05UPicuDQpTR01M OiBTdGFydCA8Rk9OVD4NClNHTUw6IEVuZCA8L0I+DQpIVE1MOmVuZF9lbGVt ZW50OiBQb3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0gTm9ybWFsDQpFbmRpbmcg dW5kZXJsaW5lDQpTR01MOiBgPC9QPicgZm91bmQhICBUcmVhdGluZyBhcyAn PFA+Jy4NClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRleHQ6IHNwbGl0X2xpbmUg Y2FsbGVkDQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNHTUw6IFN0 YXJ0IDxQPg0KU0dNTDogU3RhcnQgPFNFTEVDVD4NCkhUTUw6IElnbm9yaW5n IFNJWkU9IjEiIGZvciBTRUxFQ1QuDQpIVGV4dF9iZWdpblNlbGVjdDogbmFt ZT1TSVRFIHR5cGU9NCBzaXplPTxOVUxMPg0KSFRNTDpiZWdpbl9lbGVtZW50 OiBhZGRpbmcgc3R5bGUgdG8gc3RhY2sgLSBOb3JtYWwNClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9iZWdpbklucHV0DQpJbnB1dCBs aW5rOiBuYW1lPVNJVEUNCnZhbHVlPQ0Kc2l6ZT0yMA0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOlB1bGwgZG93biBsaXN0DQoJCSwgY2hl Y2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwg ZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9O Pg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOkFMQUJBTUENCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IEls bGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8 T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2 YWx1ZTotIEAgdGhlIFNob2FscyANCiAgICAgICAgIA0KICAgICAgICAgDQog ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LSBBbGFiYW1hIExpdmUgDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gR2Fkc2RlbiBUaW1lcyANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTpBUktBTlNBUw0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClJlYWQgNzczNyBvZiAyNzEzNSBi eXRlcyBvZiBkYXRhLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBMb2cgQ2FiaW4g RGVtb2NyYXQgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6 b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0 YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6RkxPUklE QQ0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gQkhJUCANCiAgICAgICAgIA0KICAgICAgICAg DQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRp b25WYWx1ZTogdmFsdWU6LSBEYXl0b25hIEJlYWNoIE5ld3MtSm91cm5hbCBP bmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+ DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0g SmFja3NvbnZpbGxlLmNvbSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBOYXBsZXMgRGFpbHkgTmV3cyBPbmxpbmUgDQogICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gTy1aT05FIA0KICAgICAg ICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFBhbG0gQmVhY2ggSW50 ZXJhY3RpdmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gU2FyYXNvdGEgSGVyYWxkLVRyaWJ1bmUgDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gU3QuIFBldGVyc2J1cmcgVGltZXMgDQog ICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gU3VuIEhlcmFs ZCANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6 b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0 YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBTdW5P TkUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGFs bGFoYXNzZWUgIERlbW9jcmF0IE9ubGluZSANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBUYW1wYSBCYXkgT25saW5lIA0KICAgICAg ICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBMZWRnZXIgT25s aW5lIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRo ZSBNaWFtaSBIZXJhbGQgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gVGhlIE5ld3MgQ2hpZWYgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gVGhlIFN0LiBBdWd1c3RpbmUgUmVjb3JkIA0K ICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQg PC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZv dW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3Nl dExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOkdFT1JHSUENCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClJlYWQgOTE5NyBvZiAyNzEzNSBieXRlcyBvZiBk YXRhLg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gQWNj ZXNzIEF0bGFudGEgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gQXRoZW5zIEJhbm5lciBIZXJhbGQgDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gQXVndXN0YSBDaHJvbmljbGUgDQogICAg ICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dN TDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BU SU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBI VGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gTGVkZ2VyLUVucXVp cmVyIE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAs IGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxl Z2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9Q VElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFs dWU6LSBTYXZhbm5haCBOb3cgDQogICAgICAgICANCiAgICAgICAgIA0KICAg ICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dN TDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0 YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFs dWU6IHZhbHVlOi0gVGhlIE1hY29uIFRlbGVncmFwaCBPbmxpbmUgDQogICAg ICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQg PC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZv dW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3Nl dExhc3RPcHRpb25WYWx1ZTogdmFsdWU6S0VOVFVDS1kNCiAgICAgICAgICwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTotIEJvd2xpbmcgR3JlZW4gRGFpbHkgTmV3cyANCiAgICAgICAgIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBEYW52aWxsZSBPbmxpbmUgDQogICAg ICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dN TDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BU SU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBI VGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gS2VudHVja3kgQ29u bmVjdCANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBO ZXdzLUVudGVycHJpc2UgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gU3VuU2l4IChUaGUgUGFkdWNhaCBTdW4gT25saW5lKSANCiAg ICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpT R01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9P UFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgR2xlYW5l ciBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gVGhlIE1lc3NlbmdlciBJbnF1aXJlciANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNH TUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBT dGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZh bHVlOiB2YWx1ZTpMT1VJU0lBTkENCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEFkdm9jYXRl IE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBOZXcgT3JsZWFucy5uZXQgDQogICAgICAgICANCiAgICAgICAgICwgY2hl Y2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwg ZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9O Pg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTos IGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxl Z2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9Q VElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFs dWU6TUlTU0lTU0lQUEkNCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpSZWFkIDEwNjU3IG9mIDI3MTM1IGJ5dGVzIG9mIGRhdGEu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTotIFN1biBIZXJhbGQgT25saW5lIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOk5PUlRIIENBUk9MSU5BDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBDaGFybG90dGUuY29tIChDaGFybG90dGUgT2JzZXJ2ZXIp IA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEZheWV0 dGV2aWxsZSBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gU3RhciBMaW5lIE9ubGluZSANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgRGVwb3QgDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIFdpbHNvbiBEYWlseSBUaW1l cyBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gV2luc3Rvbi1TYWxlbSBKb3VybmFsIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dN TDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0 YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFs dWU6IHZhbHVlOk9LTEFIT01BDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpT R01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9P UFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBTaGF3bmVlIE5l d3MtU3RhciBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gVGhlIERhaWx5IEFyZG1vcmVpdGUgT25saW5lIA0KICAgICAg ICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBPa2xhaG9tYW4g T25saW5lIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpT R01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9P UFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9m Zg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFn IDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRl cmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOlBVRVJUTyBS SUNPDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBFbCBOdWV2byBEaWEgT25saW5lIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOlNPVVRIIENBUk9MSU5BDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBDaGFybGVzdG9uLk5ldCANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgSXRlbSANCiAgICAgICAgIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgU3RhdGUgDQogICAgICAgICAN CiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClJlYWQgMTIxMTcgb2YgMjcxMzUgYnl0ZXMgb2YgZGF0YS4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gVGhlIHtNeXJ0bGUgQmVhY2h9IFN1biBOZXdz IA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFVwc3Rh dGUgSm91cm5hbCANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9m Zg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFn IDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRl cmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpURU5O RVNTRUUNCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTotIENoYXRUaW1lcyAoQ2hhdHRhbm9vZ2Ep IA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEROSmRv dENPTSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBE YWlseSBUaW1lcyANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAs IGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxl Z2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9Q VElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFs dWU6LSBHcmVlbmUgQ291bnR5IE9ubGluZSANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgQ29tbWVyY2lhbCBBcHBlYWwgDQog ICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIEtub3h2 aWxsZSBOZXdzLVNlbnRpbmVsIE9ubGluZSANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgT2FrIFJpZGdlciBPbmxpbmUgDQog ICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8 L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91 bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0 TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6VklSR0lOSUENCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IEls bGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8 T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2 YWx1ZTotIFBpbG90IE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQog ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LSBSaWNobW9uZCBUaW1lcyBEaXNwYXRjaCANCiAgICAg ICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01M OiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJ T04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhU ZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBTaGVuYW5kb2FoLmNv bSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6 b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0 YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUg RGFpbHkgUHJvZ3Jlc3MgT25saW5lIA0KICAgICAgICAgDQogICAgICAgICAN CiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTotIFRoZSBSb2Fub2tlIFRpbWVzIA0KICAgICAgICAg DQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRp b25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOldFU1QgVklSR0lOSUENCiAgICAgICAgICwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTotIENoYXJsZXN0b24gRGFpbHkgTWFpbCANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBDbGFya3NidXJnIFB1Ymxpc2hpbmcoRXhw b25lbnQtVGVsZWdyYW0pIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAg ICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6 IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFy dCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVl OiB2YWx1ZTotIFRoZSBXZXN0IFZpcmdpbmlhIE5ld3MgDQogICAgICAgICAN Cg0KCQksIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogRW5k IDwvU0VMRUNUPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0eWxlIG9m ZiBzdGFjayAtIE5vcm1hbA0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoJCSwgY2hlY2tlZDpvZmYNClNHTUw6IFN0 YXJ0IDxJTlBVVD4NCkVudGVyaW5nIEhUZXh0X2JlZ2luSW5wdXQNCklucHV0 IGxpbms6IG5hbWU9DQp2YWx1ZT1Hbw0Kc2l6ZT0yMA0KR3JpZFRleHQ6IHNw bGl0X2xpbmUgY2FsbGVkDQpTR01MOiBTdGFydCA8UD4NCkdyaWRUZXh0OiBz cGxpdF9saW5lIGNhbGxlZA0KR3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVk DQpTR01MOiBFbmQgPC9GT1JNPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVk IHN0eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KR3JpZFRleHQ6IHNwbGl0X2xp bmUgY2FsbGVkDQpTR01MOiBTdGFydCA8Rk9STT4NCkhUUGFyc2U6IGFOYW1l Omh0dHA6Ly93aXJlLmFwLm9yZy8gICByZWxhdGVkTmFtZTpodHRwOi8vd2ly ZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KMQ0KSFRQYXJzZTogcmVzdWx0 Omh0dHA6Ly93aXJlLmFwLm9yZy8NCm5ldyBBbmNob3IgMTQwMDlmZmMwIG5h bWVkIGAnIGlzIGNoaWxkIG9mIDE0MDA2MTdjMA0KRW50ZXJlZCBIVEFuY2hv cl9maW5kQ2hpbGRBbmRMaW5rDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2ly ZS5hcC5vcmcvICAgcmVsYXRlZE5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQ bmV3cy9tYWluLmh0bWwNCjENCkhUUGFyc2U6IHJlc3VsdDpodHRwOi8vd2ly ZS5hcC5vcmcvDQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcv ICAgcmVsYXRlZE5hbWU6DQpIVFBhcnNlOiByZXN1bHQ6DQpFbnRlcmVkIEhU QW5jaG9yX2ZpbmRBZGRyZXNzDQpBbmNob3IgMTQwMDYxZTAwIHdpdGggYWRk cmVzcyBgaHR0cDovL3dpcmUuYXAub3JnLycgYWxyZWFkeSBleGlzdHMuDQpM aW5raW5nIGFuY2hvciAxNDAwOWZmYzAgdG8gYW5jaG9yIDE0MDA2MWUwMA0K QmVnaW5Gb3JtOiBhY3Rpb246aHR0cDovL3dpcmUuYXAub3JnLyBNZXRob2Q6 MQ0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRpbmcgc3R5bGUgdG8gc3RhY2sg LSBOb3JtYWwNClNHTUw6IFN0YXJ0IDxJTlBVVD4NCkVudGVyaW5nIEhUZXh0 X2JlZ2luSW5wdXQNCklucHV0IGxpbms6IG5hbWU9RlJPTlRJRA0KdmFsdWU9 SE9NRQ0Kc2l6ZT0wDQpTR01MOiBTdGFydCA8Qj4NCkJlZ2lubmluZyB1bmRl cmxpbmUNCkhUTUw6YmVnaW5fZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0 YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFydCA8Rk9OVD4NClNHTUw6IGA8L0ZP TlQ+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8Rk9OVD4nLg0KU0dNTDogU3Rh cnQgPEZPTlQ+DQpTR01MOiBFbmQgPC9CPg0KSFRNTDplbmRfZWxlbWVudDog UG9wcGVkIHN0eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KRW5kaW5nIHVuZGVy bGluZQ0KU0dNTDogYDwvUD4nIGZvdW5kISAgVHJlYXRpbmcgYXMgJzxQPicu DQpTR01MOiBTdGFydCA8UD4NCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxl ZA0KR3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBTdGFydCA8 UD4NClNHTUw6IFN0YXJ0IDxTRUxFQ1Q+DQpIVE1MOiBJZ25vcmluZyBTSVpF PSIxIiBmb3IgU0VMRUNULg0KSFRleHRfYmVnaW5TZWxlY3Q6IG5hbWU9U0lU RSB0eXBlPTQgc2l6ZT08TlVMTD4NCkhUTUw6YmVnaW5fZWxlbWVudDogYWRk aW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfYmVnaW5JbnB1dA0KSW5wdXQgbGluazog bmFtZT1TSVRFDQp2YWx1ZT0NCnNpemU9MjANClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTpQdWxsIGRvd24gbGlzdA0KCQksIGNoZWNrZWQ6 b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0 YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVu ZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4g Zm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRf c2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpJTExJTk9JUw0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gSUwgQ29wbGV5IE5ld3NwYXBlcnMgDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gU0otUi5DT00vVGhlIFN0YXRlIEpvdXJu YWwtUmVnaXN0ZXIgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gVGhlIERhaWx5IFJlZ2lzdGVyIE9ubGluZSANCiAgICAgICAgIA0K ICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTpJTkRJQU5BDQogICAgICAgICAsIGNoZWNrZWQ6 b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0 YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBFdmFu c3ZpbGxlIE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBJbmRpYW5hcG9saXMgU3Rhci9OZXdzIE9ubGluZSANCiAgICAg ICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01M OiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJ T04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhU ZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgSm91cm5hbCBH YXpldHRlIE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBUaGUgU2hlbGJ5dmlsbGUgIE5ld3MgDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIFN0YXIgUHJlc3MgV2ViIEVk aXRpb24gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+ DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0g VGhlIFRpbWVzIE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+ DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTpJT1dBDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBGWUlvd2EgDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gR2xvYmUgT25saW5lIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOktBTlNBUw0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+ DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0g Qy1KIE9ubGluZSAoVG9wZWthIENhcGl0YWwtSm91cm5hbCkgDQogICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gRG9kZ2UgR2xvYmUgDQog ICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gTW9ybmluZyBT dW4gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gT25s aW5lIERhaWx5TmV3cyANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hl Y2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwg ZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9O Pg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpN SUNISUdBTg0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gTWljaGlnYW4gTGl2ZSANCiAgICAg ICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01M OiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJ T04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhU ZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgRGV0cm9pdCBO ZXdzIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRo ZSBGcmVlcCAoRGV0cm9pdCBGcmVlIFByZXNzKSANCiAgICAgICAgIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgSG9sbGFuZCBTZW50aW5lbCAN CiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClJlYWQgMTYyMTMgb2YgMjcxMzUgYnl0ZXMgb2YgZGF0YS4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTpNSU5ORVNPVEENCiAgICAgICAgICwgY2hl Y2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwg ZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9O Pg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTot IER1bHV0aCBOZXdzIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IEls bGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8 T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2 YWx1ZTotIFBpb25lZXJQbGFuZXQgDQogICAgICAgICANCiAgICAgICAgIA0K ICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOi0gUm9jaGVzdGVyIFBvc3QtQnVsbGV0aW4gT25saW5l IA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBC cmFpbmVyZCBEYWlseSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBzdGFydHJpYnVuZS5jb20gDQogICAgICAgICANCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IEls bGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8 T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2 YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6TUlTU09VUkkNCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNH TUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09Q VElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcg SFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIERpZ2l0YWwgTWlz c291cmlhbiANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBIYW5uaWJhbCBDb3VyaWVyLVBvc3QgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gS2Fuc2FzIENpdHkgU3RhciANCiAgICAgICAg IA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBMZWJhbm9uIERhaWx5IFJl Y29yZCBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gUE9TVG5ldCANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBTdC4gSm9zZXBoIE5ld3MtRXhwcmVzcyANCiAgICAgICAgIA0K ICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQg PC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZv dW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3Nl dExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgSW5kZXBlbmRlbmNlIEV4 YW1pbmVyIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpT R01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9P UFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9m Zg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFn IDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRl cmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOk5FQlJBU0tB DQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRp b25WYWx1ZTogdmFsdWU6LSBHcmFuZCBJc2xhbmQgSW5kZXBlbmRlbnQgDQog ICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8 L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91 bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0 TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6Tk9SVEggREFLT1RBDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBOb3J0aCBEYWtvdGEgT25saW5lIA0KICAgICAgICAgDQog ICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8 L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91 bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0 TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIE5vcnRoc2NhcGUgDQogICAgICAg ICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6T0hJTw0KICAgICAgICAgLCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gQXRo ZW5zIE1lc3NlbmdlciANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBDaXJjbGV2aWxsZSBIZXJhbGQgDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gQ2xldmVsYW5kIExpdmUgDQogICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gSGlsbHNib3JvIFRpbWVz IEdhemV0dGUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gTG9nYW4gRGFpbHkgTmV3cyANCiAgICAgICAgIA0KICAgICAgICAgDQog ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LSBPaGlvLmNvbSANCiAgICAgICAgIA0KICAgICAgICAg DQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRp b25WYWx1ZTogdmFsdWU6LSBURE4tTmV0IChUcm95IERhaWx5IE5ld3MpIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBDaW5j aW5uYXRpIEVucXVpcmVyIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAg ICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6 IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFy dCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVl OiB2YWx1ZTotIFRoZSBDaW5jaW5uYXRpIFBvc3QgV29ybGQgV2lkZSBXZWIg RWRpdGlvbiANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBUaGUgQ29sdW1idXMgRGlzcGF0Y2ggDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gVGhlIERlbGF3YXJlIEdhemV0dGUgDQogICAg ICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dN TDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BU SU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBI VGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIFNpZG5leSBE YWlseSBOZXdzIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTotIFRoZSBUb2xlZG8gQmxhZGUgDQogICAgICAgICANCiAgICAgICAgIA0K ICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOi0gVXJiYW5hIENpdGl6ZW4gDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVmFuIFdlcnQgVGltZXMtQnVsbGV0 aW4gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gV2Fz aGluZ3RvbiBDb3VydCBIb3VzZSBSZWNvcmQtSGVyYWxkIA0KICAgICAgICAg DQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRp b25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOlNPVVRIIERBS09UQQ0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gQWJlcmRlZW4gQW1lcmljYW4gTmV3cyANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBZYW5rdG9uIERhaWx5IFByZXNzIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOldJU0NPTlNJTg0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gTGVhZGVyIFRlbGVncmFtIA0KICAgICAgICAgDQogICAgICAgICAN CiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTotIE1pbHdhdWtlZSBKb3VybmFsIFNlbnRpbmVsIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBKYW5l c3ZpbGxlIEdhemV0dGUgDQogICAgICAgICANCgkJLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IEVuZCA8L1NFTEVDVD4NCkhUTUw6ZW5k X2VsZW1lbnQ6IFBvcHBlZCBzdHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNCkVu dGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K CQksIGNoZWNrZWQ6b2ZmDQpTR01MOiBTdGFydCA8SU5QVVQ+DQpFbnRlcmlu ZyBIVGV4dF9iZWdpbklucHV0DQpJbnB1dCBsaW5rOiBuYW1lPQ0KdmFsdWU9 R28NCnNpemU9MjANCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dN TDogU3RhcnQgPFA+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdy aWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogRW5kIDwvRk9STT4N CkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBzdHlsZSBvZmYgc3RhY2sgLSBO b3JtYWwNCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3Rh cnQgPEZPUk0+DQpIVFBhcnNlOiBhTmFtZTpodHRwOi8vd2lyZS5hcC5vcmcv ICAgcmVsYXRlZE5hbWU6aHR0cDovL3dpcmUuYXAub3JnL0FQbmV3cy9tYWlu Lmh0bWwNCjENCkhUUGFyc2U6IHJlc3VsdDpodHRwOi8vd2lyZS5hcC5vcmcv DQpuZXcgQW5jaG9yIDE0MDBhMDVjMCBuYW1lZCBgJyBpcyBjaGlsZCBvZiAx NDAwNjE3YzANCkVudGVyZWQgSFRBbmNob3JfZmluZENoaWxkQW5kTGluaw0K SFRQYXJzZTogYU5hbWU6aHR0cDovL3dpcmUuYXAub3JnLyAgIHJlbGF0ZWRO YW1lOmh0dHA6Ly93aXJlLmFwLm9yZy9BUG5ld3MvbWFpbi5odG1sDQoxDQpI VFBhcnNlOiByZXN1bHQ6aHR0cDovL3dpcmUuYXAub3JnLw0KSFRQYXJzZTog YU5hbWU6aHR0cDovL3dpcmUuYXAub3JnLyAgIHJlbGF0ZWROYW1lOg0KSFRQ YXJzZTogcmVzdWx0Og0KRW50ZXJlZCBIVEFuY2hvcl9maW5kQWRkcmVzcw0K QW5jaG9yIDE0MDA2MWUwMCB3aXRoIGFkZHJlc3MgYGh0dHA6Ly93aXJlLmFw Lm9yZy8nIGFscmVhZHkgZXhpc3RzLg0KTGlua2luZyBhbmNob3IgMTQwMGEw NWMwIHRvIGFuY2hvciAxNDAwNjFlMDANCkJlZ2luRm9ybTogYWN0aW9uOmh0 dHA6Ly93aXJlLmFwLm9yZy8gTWV0aG9kOjENCkhUTUw6YmVnaW5fZWxlbWVu dDogYWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gTm9ybWFsDQpTR01MOiBTdGFy dCA8SU5QVVQ+DQpFbnRlcmluZyBIVGV4dF9iZWdpbklucHV0DQpJbnB1dCBs aW5rOiBuYW1lPUZST05USUQNCnZhbHVlPUhPTUUNCnNpemU9MA0KU0dNTDog U3RhcnQgPEI+DQpCZWdpbm5pbmcgdW5kZXJsaW5lDQpIVE1MOmJlZ2luX2Vs ZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAtIE5vcm1hbA0KU0dNTDog U3RhcnQgPEZPTlQ+DQpTR01MOiBgPC9GT05UPicgZm91bmQhICBUcmVhdGlu ZyBhcyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0IDxGT05UPg0KU0dNTDogRW5k IDwvQj4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBzdHlsZSBvZmYgc3Rh Y2sgLSBOb3JtYWwNCkVuZGluZyB1bmRlcmxpbmUNClNHTUw6IGA8L1A+JyBm b3VuZCEgIFRyZWF0aW5nIGFzICc8UD4nLg0KU0dNTDogU3RhcnQgPFA+DQpH cmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdyaWRUZXh0OiBzcGxpdF9s aW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPFA+DQpTR01MOiBTdGFydCA8U0VM RUNUPg0KSFRNTDogSWdub3JpbmcgU0laRT0iMSIgZm9yIFNFTEVDVC4NCkhU ZXh0X2JlZ2luU2VsZWN0OiBuYW1lPVNJVEUgdHlwZT00IHNpemU9PE5VTEw+ DQpIVE1MOmJlZ2luX2VsZW1lbnQ6IGFkZGluZyBzdHlsZSB0byBzdGFjayAt IE5vcm1hbA0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X2JlZ2luSW5wdXQNCklucHV0IGxpbms6IG5hbWU9U0lURQ0KdmFsdWU9DQpz aXplPTIwDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6UHVs bCBkb3duIGxpc3QNCgkJLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAgICAgDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpSZWFkIDIwMzA5IG9mIDI3MTM1IGJ5dGVzIG9m IGRhdGEuDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6QUxB U0tBDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBKdW5lYXUgRW1waXJlIE9ubGluZSANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVu ZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4g Zm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRf c2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpBUklaT05BDQogICAgICAgICAs IGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxl Z2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9Q VElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFs dWU6LSBBcml6b25hIENlbnRyYWwgDQogICAgICAgICANCiAgICAgICAgIA0K ICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOi0gU3Rhck5ldCAgKFRoZSBBcml6b25hIERhaWx5IFN0 YXIpIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRo ZSBZdW1hIERhaWx5IFN1biANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVj a2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBl bmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+ DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTpDQUxJRk9STklBDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBIb3QgQ29jbyANCiAgICAg ICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01M OiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJ T04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhU ZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBJbmxhbmQgRW1waXJl IE9ubGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNo ZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2Fs IGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElP Tj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6 LSBMb3MgQW5nZWxlcyBUaW1lcyBXZWIgU2l0ZSANCiAgICAgICAgIA0KICAg ICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9P UFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5k Lg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExh c3RPcHRpb25WYWx1ZTogdmFsdWU6LSBNZXJjdXJ5IENlbnRlciANCiAgICAg ICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01M OiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJ T04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhU ZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBTYW50YSBCYXJiYXJh IE5ld3MtUHJlc3MgT25saW5lIFZlcnNpb24gDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BU SU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4N ClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0 T3B0aW9uVmFsdWU6IHZhbHVlOi0gU2FudGEgUm9zYSBQcmVzcyBEZW1vY3Jh dCBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gU2lnbk9uIFNhbiBEaWVnbyANCiAgICAgICAgIA0KICAgICAgICAgDQog ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LSBTdGFyb25saW5lIChWZW50dXJhIENvdW50eSkgDQog ICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGVsZWdyYW0t VHJpYnVuZSBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gVGhlIEJha2Vyc2ZpZWxkIENhbGlmb3JuaWFuIE9ubGluZSAN CiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpDT0xPUkFETw0KICAgICAg ICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDog SWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0 IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6 IHZhbHVlOi0gQm91bGRlciBOZXdzIA0KICAgICAgICAgDQogICAgICAgICAN CiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTotIENvbG9yYWRvIFNwcmluZ3MgR2F6ZXR0ZSANCiAg ICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpT R01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9P UFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5n IEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBEZW52ZXIgUG9z dCBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBj aGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdh bCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJ T04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVl Oi0gUm9ja3kgTW91bnRhaW4gTmV3cyBPbmxpbmUgDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIEdsZW53b29kIFBvc3QgDQog ICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8 L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91 bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0 TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTosIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6SURBSE8NCiAgICAgICAgICwg Y2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVn YWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BU SU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1 ZTotIElkYWhvIFN0YXRlIEpvdXJuYWwgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gVGhlIFRpbWVzLU5ld3MgKFR3aW4gRmFsbHMs IElkYWhvKSANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0K U0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwv T1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmlu ZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpv ZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRh ZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50 ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpORVZBREEN CiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4N ClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01M OiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlv blZhbHVlOiB2YWx1ZTotIExhcyBWZWdhcyBSZXZpZXctSm91cm5hbCANCiAg ICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwv T1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3Vu ZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRM YXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVu ZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4g Zm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRf c2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpORVcgTUVYSUNPDQogICAgICAg ICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJ bGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQg PE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTog dmFsdWU6LSBBbGJ1cXVlcnF1ZSBKb3VybmFsIE9ubGluZSANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTpPUkVHT04NCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIE1p ZC1WYWxsZXkgT25MaW5lIChBbGJhbnkpIA0KICAgICAgICAgDQogICAgICAg ICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTotIE9yZWdvbiBMaXZlIA0KICAgICAgICAgDQog ICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8 L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91 bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0 TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBSZWdpc3Rlci1HdWFyZCAN CiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5k IDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBm b3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9z ZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpURVhBUw0KICAgICAgICAg LCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxs ZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxP UFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZh bHVlOi0gQWJpbGVuZSBSZXBvcnRlci1OZXdzIA0KICAgICAgICAgDQogICAg ICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09Q VElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQu DQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTotIEFtYXJpbGxvIEdsb2JlLU5ld3MgT25s aW5lIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tl ZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5k IHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0K RW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEJy eWFuLUNvbGxlZ2UgU3RhdGlvbiBFYWdsZSANCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJ T04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0K U0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RP cHRpb25WYWx1ZTogdmFsdWU6LSBFbnRlcnByaXNlLUV4dHJAIA0KICAgICAg ICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6 IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElP Tj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRl eHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIEhPVVNUT04gQ2hyb25p Y2xlIEludGVyYWN0aXZlIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAg ICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6 IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFy dCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVl OiB2YWx1ZTotIEx1YmJvY2tPbmxpbmUgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gU2FuIEFudG9uaW8gRXhwcmVzcy1OZXdzIE9u bGluZSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBT dGFyLVRlbGVncmFtLmNvbSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBUZXhhcyBPbmxpbmUgDQogICAgICAgICANCiAgICAgICAg IA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9O Pg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNH TUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0 aW9uVmFsdWU6IHZhbHVlOi0gVGhlIEJhdHRhbGlvbiBPbmxpbmUgDQogICAg ICAgICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dN TDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BU SU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBI VGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIEJyb3duc3Zp bGxlIEhlcmFsZCANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAs IGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxl Z2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9Q VElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFs dWU6LSBUaGUgRGFpbHkgVGV4YW4gDQogICAgICAgICANCiAgICAgICAgIA0K ICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0K U0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6 IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9u VmFsdWU6IHZhbHVlOi0gVGhlIERhbGxhcyBNb3JuaW5nIE5ld3Mgb24gdGhl IFdlYiANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNr ZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVu ZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4N CkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBU aGUgRmFjdHMgKENsdXRlKSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBUaGUgR2FsdmVzdG9uIENvdW50eSBEYWlseSBOZXdzIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpSZWFkIDI0NDA1IG9mIDI3MTM1IGJ5dGVzIG9m IGRhdGEuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRf c2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBNb25pdG9yIA0KICAg ICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNH TUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09Q VElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcg SFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFZhbGxleSBTdGFy LmNvbSANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dN TDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BU SU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBI VGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpVVEFIDQogICAg ICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01M OiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3Rh cnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1 ZTogdmFsdWU6LSBEZXNlcmV0IE5ld3MgV2ViIEVkaXRpb24gDQogICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOi0gVGhlIERhaWx5IEhlcmFs ZCANCiAgICAgICAgIA0KICAgICAgICAgLCBjaGVja2VkOm9mZg0KU0dNTDog RW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQgdGFnIDwvT1BUSU9O PiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpFbnRlcmluZyBIVGV4 dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOiwgY2hlY2tlZDpvZmYNClNH TUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09Q VElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcg SFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTpXQVNISU5HVE9ODQog ICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+DQpT R01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dNTDog U3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0X3NldExhc3RPcHRpb25W YWx1ZTogdmFsdWU6LSBESkMgT25saW5lIA0KICAgICAgICAgDQogICAgICAg ICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTotIEVhc3RzaWRlIEpvdXJuYWwgT25saW5lIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFBlbmluc3Vs YSBEYWlseSBOZXdzIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAg ICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IEls bGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8 T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2 YWx1ZTotIFNvdXRoIENvdW50eSBKb3VybmFsIE9ubGluZSANCiAgICAgICAg IA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2ZmDQpTR01MOiBF bmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+ IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVyaW5nIEhUZXh0 X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LSBUaGUgQ29sdW1iaWFuIA0K ICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IEVuZCA8L09QVElPTj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8 L09QVElPTj4gZm91bmQuDQpTR01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJp bmcgSFRleHRfc2V0TGFzdE9wdGlvblZhbHVlOiB2YWx1ZTotIFRoZSBTZWF0 dGxlIFRpbWVzIA0KICAgICAgICAgDQogICAgICAgICAsIGNoZWNrZWQ6b2Zm DQpTR01MOiBFbmQgPC9PUFRJT04+DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcg PC9PUFRJT04+IGZvdW5kLg0KU0dNTDogU3RhcnQgPE9QVElPTj4NCkVudGVy aW5nIEhUZXh0X3NldExhc3RPcHRpb25WYWx1ZTogdmFsdWU6LCBjaGVja2Vk Om9mZg0KU0dNTDogRW5kIDwvT1BUSU9OPg0KU0dNTDogSWxsZWdhbCBlbmQg dGFnIDwvT1BUSU9OPiBmb3VuZC4NClNHTUw6IFN0YXJ0IDxPUFRJT04+DQpF bnRlcmluZyBIVGV4dF9zZXRMYXN0T3B0aW9uVmFsdWU6IHZhbHVlOldZT01J TkcNCiAgICAgICAgICwgY2hlY2tlZDpvZmYNClNHTUw6IEVuZCA8L09QVElP Tj4NClNHTUw6IElsbGVnYWwgZW5kIHRhZyA8L09QVElPTj4gZm91bmQuDQpT R01MOiBTdGFydCA8T1BUSU9OPg0KRW50ZXJpbmcgSFRleHRfc2V0TGFzdE9w dGlvblZhbHVlOiB2YWx1ZTotIFd5b21pbmcgVHJpYnVuZS1FYWdsZSANCiAg ICAgICAgIA0KCQksIGNoZWNrZWQ6b2ZmDQpTR01MOiBFbmQgPC9PUFRJT04+ DQpTR01MOiBJbGxlZ2FsIGVuZCB0YWcgPC9PUFRJT04+IGZvdW5kLg0KU0dN TDogRW5kIDwvU0VMRUNUPg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0 eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KRW50ZXJpbmcgSFRleHRfc2V0TGFz dE9wdGlvblZhbHVlOiB2YWx1ZTo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoJICAgICwgY2hlY2tlZDpvZmYN ClNHTUw6IFN0YXJ0IDxJTlBVVD4NCkVudGVyaW5nIEhUZXh0X2JlZ2luSW5w dXQNCklucHV0IGxpbms6IG5hbWU9DQp2YWx1ZT1Hbw0Kc2l6ZT0yMA0KR3Jp ZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBgPC9QPicgZm91bmQh ICBUcmVhdGluZyBhcyAnPFA+Jy4NClNHTUw6IFN0YXJ0IDxQPg0KR3JpZFRl eHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpHcmlkVGV4dDogc3BsaXRfbGluZSBj YWxsZWQNClNHTUw6IFN0YXJ0IDxDRU5URVI+DQpHcmlkVGV4dDogQ2hhbmdl IHRvIHN0eWxlIERpdkNlbnRlcg0KSFRNTDpiZWdpbl9lbGVtZW50OiBhZGRp bmcgc3R5bGUgdG8gc3RhY2sgLSBEaXZDZW50ZXINClNHTUw6IFN0YXJ0IDxQ Pg0KU0dNTDogYDwvUD4nIGZvdW5kISAgVHJlYXRpbmcgYXMgJzxQPicuDQpT R01MOiBTdGFydCA8UD4NCkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0K R3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpTR01MOiBTdGFydCA8UD4N ClNHTUw6IGA8L1A+JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8UD4nLg0KU0dN TDogU3RhcnQgPFA+DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNCkdy aWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPFA+DQpT R01MOiBTdGFydCA8UD4NClNHTUw6IFN0YXJ0IDxJTUc+DQpIVE1MIElNRzog VVNFTUFQPTAgSVNNQVA9MCBBTkNIT1I9MCBQQVJBPTANClNHTUw6IGA8L1A+ JyBmb3VuZCEgIFRyZWF0aW5nIGFzICc8UD4nLg0KU0dNTDogU3RhcnQgPFA+ DQpTR01MOiBTdGFydCA8UD4NClNHTUw6IFN0YXJ0IDxGT05UPg0KU0dNTDog U3RhcnQgPEJSPg0KR3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpHcmlk VGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNHTUw6IFN0YXJ0IDxCUj4NCkdy aWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KU0dNTDogU3RhcnQgPEE+DQpu ZXcgQW5jaG9yIDE0MDBhZjU0MCBuYW1lZCBgJyBpcyBjaGlsZCBvZiAxNDAw NjE3YzANCkVudGVyZWQgSFRBbmNob3JfZmluZENoaWxkQW5kTGluaw0KSFRQ YXJzZTogYU5hbWU6bWFpbHRvOmZlZWRiYWNrQC5hcC5vcmcgICByZWxhdGVk TmFtZTpodHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0KMw0K SFRQYXJzZTogcmVzdWx0Om1haWx0bzpmZWVkYmFja0AuYXAub3JnDQpIVFBh cnNlOiBhTmFtZTptYWlsdG86ZmVlZGJhY2tALmFwLm9yZyAgIHJlbGF0ZWRO YW1lOg0KSFRQYXJzZTogcmVzdWx0Og0KRW50ZXJlZCBIVEFuY2hvcl9maW5k QWRkcmVzcw0KTmV3IGFuY2hvciAxNDAwNjI2YzAgaGFzIGhhc2ggMzYgYW5k IGFkZHJlc3MgYG1haWx0bzpmZWVkYmFja0AuYXAub3JnJw0KTGlua2luZyBh bmNob3IgMTQwMGFmNTQwIHRvIGFuY2hvciAxNDAwNjI2YzANCkhUTUw6YmVn aW5fZWxlbWVudDogYWRkaW5nIHN0eWxlIHRvIHN0YWNrIC0gRGl2Q2VudGVy DQpHcmlkVGV4dDogc3BsaXRfbGluZSBjYWxsZWQNClNHTUw6IEVuZCA8L0E+ DQpIVE1MOmVuZF9lbGVtZW50OiBQb3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0g RGl2Q2VudGVyDQpTR01MOiBgPC9GT05UPicgZm91bmQhICBUcmVhdGluZyBh cyAnPEZPTlQ+Jy4NClNHTUw6IFN0YXJ0IDxGT05UPg0KU0dNTDogYDwvUD4n IGZvdW5kISAgVHJlYXRpbmcgYXMgJzxQPicuDQpTR01MOiBTdGFydCA8UD4N CkdyaWRUZXh0OiBzcGxpdF9saW5lIGNhbGxlZA0KR3JpZFRleHQ6IHNwbGl0 X2xpbmUgY2FsbGVkDQpTR01MOiBgPC9QPicgZm91bmQhICBUcmVhdGluZyBh cyAnPFA+Jy4NClNHTUw6IFN0YXJ0IDxQPg0KU0dNTDogRW5kIDwvQ0VOVEVS Pg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0eWxlIG9mZiBzdGFjayAt IE5vcm1hbA0KR3JpZFRleHQ6IENoYW5nZSB0byBzdHlsZSBOb3JtYWwNClNH TUw6IGA8L1REPicgZm91bmQhICBJZ25vcmluZyBpdC4NClNHTUw6IGA8L1RS PicgZm91bmQhICBJZ25vcmluZyBpdC4NClNHTUw6IEVuZCA8L1RBQkxFPg0K U0dNTDogRm91bmQgPC9UQUJMRT4gd2hlbiBleHBlY3RpbmcgPC9GT1JNPi4g PC9GT1JNPiBhc3N1bWVkLg0KSFRNTDplbmRfZWxlbWVudDogUG9wcGVkIHN0 eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KR3JpZFRleHQ6IHNwbGl0X2xpbmUg Y2FsbGVkDQpTR01MOiBgPC9URD4nIGZvdW5kISAgSWdub3JpbmcgaXQuDQpT R01MOiBgPC9UUj4nIGZvdW5kISAgSWdub3JpbmcgaXQuDQpTR01MOiBFbmQg PC9UQUJMRT4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBlZCBzdHlsZSBvZmYg c3RhY2sgLSBOb3JtYWwNClNHTUw6IGA8L1A+JyBmb3VuZCEgIFRyZWF0aW5n IGFzICc8UD4nLg0KU0dNTDogU3RhcnQgPFA+DQpTR01MOiBFbmQgPC9GT1JN Pg0KU0dNTDogRm91bmQgPC9GT1JNPiB3aGVuIGV4cGVjdGluZyA8L1RBQkxF Pi4gPC9UQUJMRT4gYXNzdW1lZC4NCkhUTUw6ZW5kX2VsZW1lbnQ6IFBvcHBl ZCBzdHlsZSBvZmYgc3RhY2sgLSBOb3JtYWwNClNHTUw6IEVuZCA8L0JPRFk+ DQpIVE1MOmVuZF9lbGVtZW50OiBQb3BwZWQgc3R5bGUgb2ZmIHN0YWNrIC0g Tm9ybWFsDQpTR01MOiBFbmQgPC9IVE1MPg0KSFRNTDplbmRfZWxlbWVudDog UG9wcGVkIHN0eWxlIG9mZiBzdGFjayAtIE5vcm1hbA0KUmVhZCAyNjI3MCBv ZiAyNzEzNSBieXRlcyBvZiBkYXRhLg0KRGF0YSB0cmFuc2ZlciBjb21wbGV0 ZQ0KR3JpZFRleHQ6IHNwbGl0X2xpbmUgY2FsbGVkDQpHcmlkVGV4dDogUmVt b3ZpbmcgYm90dG9tIGJsYW5rIGxpbmU6IA0KR3JpZFRleHQ6IE5ldyBib3R0 b20gbGluZTogDQpHcmlkVGV4dDogUmVtb3ZpbmcgYm90dG9tIGJsYW5rIGxp bmU6IA0KR3JpZFRleHQ6IE5ldyBib3R0b20gbGluZTogDQpHcmlkVGV4dDog UmVtb3ZpbmcgYm90dG9tIGJsYW5rIGxpbmU6IA0KR3JpZFRleHQ6IE5ldyBi b3R0b20gbGluZTogDQpHcmlkVGV4dDogUmVtb3ZpbmcgYm90dG9tIGJsYW5r IGxpbmU6IA0KR3JpZFRleHQ6IE5ldyBib3R0b20gbGluZTogWzZdBWZlZWRi YWNrJiM2NHRoZXdpcmUuYXAub3JnBi4NCkdyaWR0ZXh0OiBFbnRlcmluZyBI VGV4dF9lbmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNob3IgZm91bmQgb24gbGlu ZTo0IGNvbDozDQphbmNob3IgdGV4dDogJ1sxXQVbTElOS10GJyAgIHBvczog NA0KYW5jaG9yIHRleHQ6ICdbMV0FW0xJTktdBicgICBwb3M6IDQNCkdyaWRU ZXh0OiBhZGRpbmcgbGluayBvbiBsaW5lIDQgaW4gSFRleHRfZW5kQXBwZW5k DQpHcmlkdGV4dDogQW5jaG9yIGZvdW5kIG9uIGxpbmU6NiBjb2w6Mw0KYW5j aG9yIHRleHQ6ICdbMl0FW0xJTktdBicgICBwb3M6IDQNCmFuY2hvciB0ZXh0 OiAnWzJdBVtMSU5LXQYnICAgcG9zOiA0DQpHcmlkVGV4dDogYWRkaW5nIGxp bmsgb24gbGluZSA2IGluIEhUZXh0X2VuZEFwcGVuZA0KR3JpZHRleHQ6IEFu Y2hvciBmb3VuZCBvbiBsaW5lOjExIGNvbDo1Ng0KYW5jaG9yIHRleHQ6ICdZ b3UgY2FuIGRvd25sb2FkIGEgbmV3ZXIgdmVyc2lvbiBvZiB0aGUgQU9MIGJy b3dzZXIgA1szXQVoZXJlBi4gBCcgICBwb3M6IDU3DQphbmNob3IgdGV4dDog J1lvdSBjYW4gZG93bmxvYWQgYSBuZXdlciB2ZXJzaW9uIG9mIHRoZSBBT0wg YnJvd3NlciADWzNdBWhlcmUGLiAEJyAgIHBvczogNTcNCkdyaWRUZXh0OiBh ZGRpbmcgbGluayBvbiBsaW5lIDExIGluIEhUZXh0X2VuZEFwcGVuZA0KR3Jp ZHRleHQ6IEFuY2hvciBmb3VuZCBvbiBsaW5lOjEzIGNvbDozDQphbmNob3Ig dGV4dDogJ1s0XQVbTElOS10GJyAgIHBvczogNA0KYW5jaG9yIHRleHQ6ICdb NF0FW0xJTktdBicgICBwb3M6IDQNCkdyaWRUZXh0OiBhZGRpbmcgbGluayBv biBsaW5lIDEzIGluIEhUZXh0X2VuZEFwcGVuZA0KR3JpZHRleHQ6IEFuY2hv ciBmb3VuZCBvbiBsaW5lOjIwIGNvbDo2MQ0KYW5jaG9yIHRleHQ6ICcDbG9j YWwgbmV3cyBzaXRlIGxpc3RlZCwgY2xpY2sgb24gdGhlIGxvZ28gYWJvdmUg b3IgcmlnaHQgWzVdBWhlcmUGLgQnICAgcG9zOiA2Mg0KYW5jaG9yIHRleHQ6 ICcDbG9jYWwgbmV3cyBzaXRlIGxpc3RlZCwgY2xpY2sgb24gdGhlIGxvZ28g YWJvdmUgb3IgcmlnaHQgWzVdBWhlcmUGLgQnICAgcG9zOiA2Mg0KR3JpZFRl eHQ6IGFkZGluZyBsaW5rIG9uIGxpbmUgMjAgaW4gSFRleHRfZW5kQXBwZW5k DQpHcmlkdGV4dDogQW5jaG9yIGZvdW5kIG9uIGxpbmU6MjIgY29sOjANCmFu Y2hvciB0ZXh0OiAnA05vcnRoZWFzdGVybiBTdGF0ZXMEJyAgIHBvczogMA0K YW5jaG9yIHRleHQ6ICcDTm9ydGhlYXN0ZXJuIFN0YXRlcwQnICAgcG9zOiAw DQpHcmlkVGV4dDogYWRkaW5nIGxpbmsgb24gbGluZSAyMiBpbiBIVGV4dF9l bmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNob3IgZm91bmQgb24gbGluZToyNCBj b2w6MQ0KYW5jaG9yIHRleHQ6ICdbUHVsbCBkb3duIGxpc3QuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLl0nICAgcG9zOiAxDQphbmNob3Ig dGV4dDogJ1tQdWxsIGRvd24gbGlzdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uXScgICBwb3M6IDENCkdyaWRUZXh0OiBhZGRpbmcgbGlu ayBvbiBsaW5lIDI0IGluIEhUZXh0X2VuZEFwcGVuZA0KR3JpZHRleHQ6IEFu Y2hvciBmb3VuZCBvbiBsaW5lOjI1IGNvbDowDQphbmNob3IgdGV4dDogJ19f X19fX19fX19fX19fX19fX19fJyAgIHBvczogMA0KYW5jaG9yIHRleHQ6ICdf X19fX19fX19fX19fX19fX19fXycgICBwb3M6IDANCkdyaWRUZXh0OiBhZGRp bmcgbGluayBvbiBsaW5lIDI1IGluIEhUZXh0X2VuZEFwcGVuZA0KR3JpZHRl eHQ6IEFuY2hvciBmb3VuZCBvbiBsaW5lOjI4IGNvbDowDQphbmNob3IgdGV4 dDogJwNTb3V0aGVhc3Rlcm4gU3RhdGVzBCcgICBwb3M6IDANCmFuY2hvciB0 ZXh0OiAnA1NvdXRoZWFzdGVybiBTdGF0ZXMEJyAgIHBvczogMA0KR3JpZFRl eHQ6IGFkZGluZyBsaW5rIG9uIGxpbmUgMjggaW4gSFRleHRfZW5kQXBwZW5k DQpHcmlkdGV4dDogQW5jaG9yIGZvdW5kIG9uIGxpbmU6MzAgY29sOjENCmFu Y2hvciB0ZXh0OiAnW1B1bGwgZG93biBsaXN0Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi5dJyAgIHBvczogMQ0KYW5jaG9yIHRleHQ6ICdb UHVsbCBkb3duIGxpc3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLl0nICAgcG9zOiAxDQpHcmlkVGV4dDogYWRkaW5nIGxpbmsgb24gbGlu ZSAzMCBpbiBIVGV4dF9lbmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNob3IgZm91 bmQgb24gbGluZTozMSBjb2w6MA0KYW5jaG9yIHRleHQ6ICdfX19fX19fX19f X19fX19fX19fXycgICBwb3M6IDANCmFuY2hvciB0ZXh0OiAnX19fX19fX19f X19fX19fX19fX18nICAgcG9zOiAwDQpHcmlkVGV4dDogYWRkaW5nIGxpbmsg b24gbGluZSAzMSBpbiBIVGV4dF9lbmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNo b3IgZm91bmQgb24gbGluZTozNCBjb2w6MA0KYW5jaG9yIHRleHQ6ICcDTWlk d2VzdGVybiBTdGF0ZXMEJyAgIHBvczogMA0KYW5jaG9yIHRleHQ6ICcDTWlk d2VzdGVybiBTdGF0ZXMEJyAgIHBvczogMA0KR3JpZFRleHQ6IGFkZGluZyBs aW5rIG9uIGxpbmUgMzQgaW4gSFRleHRfZW5kQXBwZW5kDQpHcmlkdGV4dDog QW5jaG9yIGZvdW5kIG9uIGxpbmU6MzYgY29sOjENCmFuY2hvciB0ZXh0OiAn W1B1bGwgZG93biBsaXN0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi5dJyAgIHBvczogMQ0KYW5jaG9yIHRleHQ6ICdbUHVsbCBkb3duIGxp c3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLl0nICAgcG9z OiAxDQpHcmlkVGV4dDogYWRkaW5nIGxpbmsgb24gbGluZSAzNiBpbiBIVGV4 dF9lbmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNob3IgZm91bmQgb24gbGluZToz NyBjb2w6MA0KYW5jaG9yIHRleHQ6ICdfX19fX19fX19fX19fX19fX19fXycg ICBwb3M6IDANCmFuY2hvciB0ZXh0OiAnX19fX19fX19fX19fX19fX19fX18n ICAgcG9zOiAwDQpHcmlkVGV4dDogYWRkaW5nIGxpbmsgb24gbGluZSAzNyBp biBIVGV4dF9lbmRBcHBlbmQNCkdyaWR0ZXh0OiBBbmNob3IgZm91bmQgb24g bGluZTo0MCBjb2w6MA0KYW5jaG9yIHRleHQ6ICcDV2VzdGVybiBTdGF0ZXME JyAgIHBvczogMA0KYW5jaG9yIHRleHQ6ICcDV2VzdGVybiBTdGF0ZXMEJyAg IHBvczogMA0KR3JpZFRleHQ6IGFkZGluZyBsaW5rIG9uIGxpbmUgNDAgaW4g SFRleHRfZW5kQXBwZW5kDQpHcmlkdGV4dDogQW5jaG9yIGZvdW5kIG9uIGxp bmU6NDIgY29sOjENCmFuY2hvciB0ZXh0OiAnW1B1bGwgZG93biBsaXN0Li4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5dJyAgIHBvczogMQ0K YW5jaG9yIHRleHQ6ICdbUHVsbCBkb3duIGxpc3QuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLl0nICAgcG9zOiAxDQpHcmlkVGV4dDogYWRk aW5nIGxpbmsgb24gbGluZSA0MiBpbiBIVGV4dF9lbmRBcHBlbmQNCkdyaWR0 ZXh0OiBBbmNob3IgZm91bmQgb24gbGluZTo0MyBjb2w6MA0KYW5jaG9yIHRl eHQ6ICdfX19fX19fX19fX19fX19fX19fXycgICBwb3M6IDANCmFuY2hvciB0 ZXh0OiAnX19fX19fX19fX19fX19fX19fX18nICAgcG9zOiAwDQpHcmlkVGV4 dDogYWRkaW5nIGxpbmsgb24gbGluZSA0MyBpbiBIVGV4dF9lbmRBcHBlbmQN CkdyaWR0ZXh0OiBBbmNob3IgZm91bmQgb24gbGluZTo1MyBjb2w6Mw0KYW5j aG9yIHRleHQ6ICdbNl0FZmVlZGJhY2smIzY0dGhld2lyZS5hcC5vcmcGLicg ICBwb3M6IDQNCmFuY2hvciB0ZXh0OiAnWzZdBWZlZWRiYWNrJiM2NHRoZXdp cmUuYXAub3JnBi4nICAgcG9zOiA0DQpHcmlkVGV4dDogYWRkaW5nIGxpbmsg b24gbGluZSA1MyBpbiBIVGV4dF9lbmRBcHBlbmQNCkhUQWNjZXNzOiAgc3Rh dHVzPTI5OTk3DQpIVEFjY2VzczogYGh0dHA6Ly93aXJlLmFwLm9yZy9BUG5l d3MvbWFpbi5odG1sJyBoYXMgYmVlbiBhY2Nlc3NlZC4NCg0KDQoJCSAgIFRo ZSBXSVJFIC0gQnJlYWtpbmcgTmV3cyBmcm9tIFRoZSBBc3NvY2lhdGVkCVBy ZXNzIChwMSBvZiAzKQ0KDQoNICAgRm9yIGJlc3QgcmVzdWx0cywgdXNlIHRo ZSBsYXRlc3QgdmVyc2lvbnMgb2YJZWl0aGVyIG9mIHRoZXNlCXdlYg0KDSAg IGJyb3dzZXJzOg0KDQoNICAgWzFdW0xJTktdDQoNClsyXVtMSU5LXQ0KDQpB T0wgTWVtYmVyczogT2xkZXIgdmVyc2lvbnMgb2YgdGhlIEFPTCBicm93c2Vy IGRvbid0CWlkZW50aWZ5DQoNICAgcmVmZXJyaW5nIHNlcnZlcnMsIHNvIHlv dSBtYXkgc2VlIHRoaXMgcGFnZSByZXBlYXRlZGx5IHJhdGhlciB0aGFuDQoN ICAgZW50ZXJpbmcgVGhlCVdJUkUuDQoNICAgWW91IGNhbiBkb3dubG9hZCBh IG5ld2VyIHZlcnNpb24gb2YgdGhlIEFPTCBicm93c2VyIFszXWhlcmUuDQoN Cg0gICBbNF1bTElOS10NCg0KVGhlIFdJUkUgaXMgdGhlIG5ld3MgV2ViIHNp dGUgb2YgdGhlIEFQLCBpdHMgbWVtYmVyIG5ld3NwYXBlcnMgYW5kDQpicm9h ZGNhc3RlcnMuIA0KVG8gZW50ZXIgVGhlIFdJUkUgZnJvbSBhIHBhcnRpY3Vs YXIgQVAgbWVtYmVyIFdlYiBzaXRlLCBjaG9vc2Ugb25lDQpmcm9tIHRoZSBs aXN0cyBiZWxvdyBhbmQgY2xpY2sgdGhlIEdvIHN1Ym1pdC4gSWYgeW91IGRv bid0IHNlZSB5b3VyDQpsb2NhbCBuZXdzIHNpdGUgbGlzdGVkLCBjbGljayBv biB0aGUgbG9nbyBhYm92ZSBvciByaWdodCBbNV1oZXJlLg0KDQoNR2V0dGlu ZyBodHRwOi8vd2lyZS5hcC5vcmcvQVBuZXdzL21haW4uaHRtbA0tbW9yZS0g aHR0cDovL3cJdy5uZXRzY2FwZS5jb20vZG93bmxvYWQvDQo= --0-57062353-911524556=:31193-- From owner-lynx-dev@sig.net Fri Nov 20 10:06:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA08743 for ; Fri, 20 Nov 1998 10:06:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA20716; Fri, 20 Nov 1998 08:46:42 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Fri, 20 Nov 1998 09:48:49 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev Viewing bz2 files In-Reply-To: <199811192354.IAA29784@ews07.nara.kindai.ac.jp> 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: 1225 Lines: 39 On Fri, 20 Nov 1998, Nelson Henry Eric wrote: > Does anyone have working mailcap/mime.types entries, or lynx.cfg > VIEWER/SUFFIX entries, for decompressing bzip2 files and passing the > decompressed stream to a reader like most, or even to lynx? In lynx.cfg: VIEWER:application/x-bzip2:bzcat %s | $PAGER or VIEWER:application/x-bzip2:bunzip2 -c %s | $PAGER or VIEWER:application/x-bzip2:bzip2 -dc %s | $PAGER I use bzcat because the other two make bzip2 to give a "broken pipe" message at the end. No need to put references to bzip2 in .mime.types or .mailcap. I also use these for reading the directories of zip, lzh and pma archives: VIEWER:application/lzh:lha v %s | $PAGER VIEWER:application/zip:unzip -v %s | $PAGER VIEWER:application/pma:lha v %s | $PAGER And this one for correctly reading manpages: VIEWER:application/man:$PAGER %s 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 Nov 20 10:22:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA10071 for ; Fri, 20 Nov 1998 10:22:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA27277; Fri, 20 Nov 1998 09:02:33 -0600 (CST) Date: Fri, 20 Nov 1998 09:04:50 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) In-Reply-To: <199811200504.OAA01564@ews07.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: 2504 Lines: 62 On Fri, 20 Nov 1998, Nelson Henry Eric wrote: > > > Changing the subject, I cannot get my mailcap/mime.types entry to > > > work for bzip2-compressed files. Precisely, I cannot get Lynx to > > > use bzip2 -d to decompress the file, and then pass the result to > > > most for display. Works fine when I have it gzipped. > > > > > > Does anyone have working mailcap/mime.types entries, or lynx.cfg > > > VIEWER/SUFFIX entries, for decompressing bzip2 files and passing the > > > decompressed stream to a reader like most, or even to lynx? > > It's not just served files, but also files on the localhost that I'm > interested in. But to give an example, my own http server gives the > following header (analogous to what I have for gzip), but admittedly > I'm pretty stupid when it comes to knowing about headers and such. > > HTTP/1.0 200 Document follows > Date: Fri, 20 Nov 1998 04:42:59 GMT > Server: NCSA/1.5.2 > Last-modified: Fri, 20 Nov 1998 04:38:36 GMT > Content-type: text/plain > Content-length: 20989 > Content-encoding: bzip2 > > This is for the latest update to the ja.po I did this lunch hour: > . > > My mime.types entries are: > application/bzip2 bz2 > application/x-bzip2 bz2 > and my mailcap entries are: > application/bzip2; /usr/local/bin/bzip2 -d %s > application/x-bzip2; /usr/local/bin/bzip2 -d %s Nothing you set in your mailcap file will feed the data back to lynx for rendering. Lynx just invokes the command given, and that's it. It just has always been that way. :) Files compressed with gzip and compress work differently, but only because lynx has special code to handle them; and that is not controlled by a mailcap file. The pseudo MIME types "application/bzip2" (and similar) are only used at all if the internal code has decided that it cannot handle the given compression encoding. It is like Lynx saying "I cannot handle this, but maybe you have some viewer for it". For a file which Lynx *can* handle internally, like Content-type: text/plain Content-encoding: gzip or a local xyz.txt.gz file, pseudo MIME types "application/gzip" or "application/x-gzip" never enter into it at all. Lynx could only work for .bz2 files the same way as it does now for .Z and .gz if equivalent code were added to handle the decompression. If you just want your bzipped file displayed by most, application/bzip2; /usr/local/bin/bzip2 -d %s | most should do it. Klaus From owner-lynx-dev@sig.net Fri Nov 20 11:28:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA14267 for ; Fri, 20 Nov 1998 11:28:25 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA23861; Fri, 20 Nov 1998 10:06:56 -0600 (CST) Date: Fri, 20 Nov 1998 10:09:07 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev How to get bz2 compressed files uncompressed and rendered (not In-Reply-To: <199811200833.RAA02702@ews07.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: 1449 Lines: 31 > > It looks (after a quick look) to me that Lynx is doing internal > > decompression of .gz files, regardless of what mailcap says. Lynx doesn't On Fri, 20 Nov 1998, Nelson Henry Eric wrote: > That's true now (if you use zlib), but I had very similar entries working > when gzip had to be called externally by Lynx. Whether you use zlib or not, the interface shouldn't have changed; I.e. the "regardless of what mailcap says" bit should still apply. That is, regardless of what mailcap says _about the file in its compressed form_ (entries like "application/gzip;...". Once Lynx decides that it is able to decompress, then what mailcap says about the type of the underlying (uncompressed) data _does_ matter (if it applies). > Gzip has a --no-name option > (do not save or restore the original name and time stamp), which I think > Lynx takes (took?) advantage of. That is only a detail of how gzip gets called IF it gets called for automatic gunzipping (in HTFWriter.c). It shouldn't normally make any difference, and is only an attempt to protect from the following theoretical case: gzipped content has a name embedded that is different from the "normal" name, and the --no-name which is the default for gunzipping would be overriden by a --name in a GZIP (or, for VMS, GZIP_OPT) environment setting. In that case, the invocation of gzip could create an uncompressed file which Lynx then wouldn't know how to find or remove. Klaus From owner-lynx-dev@sig.net Fri Nov 20 11:36:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA14909 for ; Fri, 20 Nov 1998 11:36:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26679; Fri, 20 Nov 1998 10:14:02 -0600 (CST) Date: Fri, 20 Nov 1998 08:16:17 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev How to get bz2 compressed files uncompressed and rendered (not In-Reply-To: <199811200833.RAA02702@ews07.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: 956 Lines: 25 On Fri, 20 Nov 1998, Nelson Henry Eric wrote: > just downloaded) [was Re: lynx-dev NLS tweaks for 282dev4 > > > It looks (after a quick look) to me that Lynx is doing internal > > decompression of .gz files, regardless of what mailcap says. Lynx doesn't > > That's true now (if you use zlib), but I had very similar entries working > when gzip had to be called externally by Lynx. Gzip has a --no-name option > (do not save or restore the original name and time stamp), which I think > Lynx takes (took?) advantage of. Bzip2 can't do this? Not as far as I can see, for bzip2. I was able to get bzip2 working by having Lynx spawn something like 'bunzip2 -c %s | less', but that's all I managed to get going. > > I surely don't understand this part either... > > Always glad to have a little company :) Yep! :) -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Fri Nov 20 11:48:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA15584 for ; Fri, 20 Nov 1998 11:48:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA21276; Fri, 20 Nov 1998 10:00:37 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811201601.JAA01749@sanitas> Subject: Re: SUCCESS!! Was: Re: http://www.flora.org/lynx-dev/html/month1098/msg00893.html To: martin.kraemer@mch.sni.de (Martin Kraemer) Date: Fri, 20 Nov 1998 09:01:36 -0700 (MST) Cc: lynx-dev@sig.net (Lynx List) In-Reply-To: <19981120111155.A1442@deejai.mch.sni.de> from "Martin Kraemer" at Nov 20, 98 11:11: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: 2389 Lines: 60 In a recent note, Martin Kraemer said: > Date: Fri, 20 Nov 1998 11:11:55 +0100 > From: Martin Kraemer > X-Organization: Siemens AG (Muenchen, W.Germany) > X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE > VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF SIEMENS AG > X-No-Junk-Mail: I do not want to get *any* junk mail. > > Just out of curiosity I fetched lynx2.8.2dev.4.zip after your > announcement that the OS390 EBCDIC changes had been incorporated > into standard lynx. > > And tried to compile it on BS2000. > > And BINGO!!! The EBCDIC charset was detected right away, and a first > quick test shows that lynx 2-8-2b4 runs on BS2000 and displays most > pages as expected. > I'm delighted to learn the Lynx/EBCDIC user/developer population has doubled. :-) > This OS is `different enough' (i.e., not at all similar, except for > the char set) from IBM's OS390 that I can say that you did a > tremendous job with the portability! > Rather, the credit belongs to lynx-dev for the tremendous and growing intrinsic portability of Lynx; to Thomas E. Dickey for readily incorporating the POSIX compliance patches I've suggested over the past few months; and to GNU for autoconfigure. It was through ignorance rather than design that I made the one choice that may have contributed to BS2000 compatibility: I handcrafted the translation tables -- I might have used OS/390 intrinsics had I been aware of them. > Areas in which I will have to investigate further: > > a) POST data seem to have problems on my machine (wrong MIME type? > not converted to ASCII?). Must see into it. > > b) mailto: address links tried to send mail to ????????.???????@?????.??? > with some warning message about invalid character sets when I tried to > send a mail. > None of our OS/390 run sendmail, so I had no incentive (nor indeed opportunity) to test mailto: URLs. > c) inlined images are transcribed with "]ALT text]" instead of "[ALT text]" > here. Maybe a difference between IBM's and Siemens' EBCDIC<->8859.1 > tables. > > Sorry, I have no details yet, as I was so excited to tell you that it > runs that I didn't take the time to do more investigation. > > Martin > > PS: Feel free to forward this information to the list. > It would be false modesty indeed to hoard such effusive praise :-) Done. -- gil From owner-lynx-dev@sig.net Fri Nov 20 12:33:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA20947 for ; Fri, 20 Nov 1998 12:33:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA16308; Fri, 20 Nov 1998 11:06:50 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Fri, 20 Nov 1998 20:06:04 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Why doesn't lynx cache HTML source? 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: 1498 Lines: 39 19-Nov-98 11:33 Klaus Weide wrote: >> > - Require explicit user action. Maybe a special "Enter cache" key, >> > meaning "I am going to want this text reparsed, so start caching >> > it". >> ??? >> > - When '\' is pressed the first time for the current text, we mark >> > if for rawbyte caching. There could be a confirmation question. >> > That means at least two network request are needed, but after that >> > cached data is used. >> ??? > I am not sure what your question is. Can you explain? Unnecessary user interface complication unless you want to got user totally lost. > [ ...] >> But I think "mode 2" need no confirmation in any case: >> every text/plain _rendered_ document should be cached in rawdata >> if it currently cached in rendered form, otherwise fall back >> to the present behaviour (no rawdata cacheing at all). > Maybe. But I may not want that if the document is big (even if > I want it for some documents). big document usually binary (like .zip) and text/plain or text/html rarely bigger than 500K and tipically under 50K. >> Of cause, rawdata cache may be larger than rendered cache. > Do you mean more documents, or do you mean more bytes for each document? I mean "more documents". Anyway, rendered document needs more memory than rawdata (unless you have big comment inside), I would rather prefer to reduce rendered document's cache in favour of rawdata cache (CPU load is not so critical). > Klaus From owner-lynx-dev@sig.net Fri Nov 20 12:50:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA22736 for ; Fri, 20 Nov 1998 12:50:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA27374; Fri, 20 Nov 1998 11:32:06 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Fri, 20 Nov 1998 12:34:18 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.com In-Reply-To: <9811200208.AA17382@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: 1536 Lines: 35 On Fri, 20 Nov 1998, Larry W. Virden wrote: > I've noticed recently that the cookies in the latest dev support don't > work quite right with my.yahoo.com - they worked better in 2.8.1 . > > For instance, when I try to sign in in my.yahoo.com, I enter my login and > password. Regardless of whether I select saving the cookie or not, the > first attempt to sign in fails, then seems to work the second time. > > Next, when I go to mail.yahoo.com, I see the same behavior. The problem is not with cookies but with submitting forms like the login one in My Yahoo. I reported that problem a couple of days ago. > User message: Trace ON! > FIXME:SubmitForm > SubmitForm: field "TRA" 0 us-ascii OK > SubmitForm: name "TRA" 0 us-ascii OK > SubmitForm: field "destBox1" 0 us-ascii OK > SubmitForm: name "destBox1" 0 us-ascii OK > SubmitForm: skipping submit field with name "MV1" for link_name "TRA", not current link. > GridText - post_data: sTRA=Delete&destBox1= ^ Here's the "s" lynx is adding to the begining of post_data, what makes submitting some forms to fail. The problem appeared in dev.3. dev.2 works fine. 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 Nov 20 13:02:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA24047 for ; Fri, 20 Nov 1998 13:02:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA29869; Fri, 20 Nov 1998 11:39:30 -0600 (CST) Date: Fri, 20 Nov 1998 11:41:46 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 4915 Lines: 128 On Thu, 19 Nov 1998, Ryan Hung wrote: > On Thu, 19 Nov 1998, Klaus Weide wrote: > > > I see the same in 2.8.1rel.2. > > Yeah, I guess I should have said >=2.8.1. > > > There are actually at least two problems. Only in combination do > > they prevent changing file permissions from working: > > > > 1) the additional slash in the URL > > 2) The functions in LYLocal.c do the wrong thing with the strings > > they get. In this case permit_location() gets passed > > "//home/username", which it passed to HTfullURL_toFile, which > > is a macro to a call of HTnameOfFile_WWW() [in HTFile.c]. > > HTfullURL_toFile() is inappropriate here. It treats the > > string as a relative URL (so that "home" is seen as the host > > part of an URL) which it isn't. It also tries to URL-unescape > > the string which is also inappropriate: See what happens > > for a file named "%backup%~". > > > > Earlier versions of LYLocal.c didn't do all this. For example > > permit_location() worked for filepaths with duplicate slashes > > (which are just ignored under Unix) and for filenames with "%". > > > > I suggest reverting LYLocal.c back to a previous version that is > > better behaved, or changing the new macros and functions there to > > something appropriate. > > Hmm, I'll see if that works. On further thought, it won't work to just use an older LYLocal.c, because older versions used the tempname() function which doesn't exist any more. Unless you can find a version which doesn't use tempname() but doesn't have the HTfullURL_toFile() yet. > Any idea why adding a few lines to LYUtils.c > under LYTrimRelFromAbsPath() doesn't seem to do the trick: > > Added at Line 4569: > > while (cp[1] == '/') { > if (cp[2] == '/') { > /* > * Skip over first "/" of a "//". - rhung > */ > cp += 1; > } else { > /* Finished. - rhung > * > */ > break; > } > } > > After all, the "if (url_type == FILE_URL_TYPE)" section in LYGetFile.c > seems to call LYTrimRelFromAbsPath(). It may or may not work, but that seems to be just fiddling around with the symptoms. And I hope you would then carefully examine all places where LYTrimRelFromAbsPath() gets called, and check whether your change is always appropriate (and for all operating systems!). The problem should be solved where it is generated, which is where the /~ is replaced by something else. The code in getfile that expands "/~" looked like this in a previous incarnation: StrAllocCopy(temp, doc->address); #ifdef DOSPATH StrAllocCat(temp, "/"); StrAllocCat(temp, HTDOS_wwwName((char *)Home_Dir())); #else #ifdef VMS StrAllocCat(temp, HTVMS_wwwName((char *)Home_Dir())); #else StrAllocCat(temp, Home_Dir()); #endif /* VMS */ #endif /* DOSPATH */ if ((cp2 = strchr(cp1, '/')) != NULL) { LYTrimRelFromAbsPath(cp2); StrAllocCat(temp, cp2); } StrAllocCopy(doc->address, temp); FREE(temp); It has been replaced by: StrAllocCopy(temp, doc->address); LYAddHtmlSep(&temp); StrAllocCat(temp, wwwName(Home_Dir())); if ((cp2 = strchr(cp1, '/')) != NULL) { LYTrimRelFromAbsPath(cp2); StrAllocCat(temp, cp2); } StrAllocCopy(doc->address, temp); FREE(temp); which apparently doesn't do the same thing. > > Note that permit_location() should always get a filename or file > > path as its srcpath argument, not a URL. The code > > > > if (strncmp(srcpath, "file://localhost", 16) == 0) > > srcpath += 16; > > > > which appears in previous versions may have been misleading because > > if makes one think otherwise. But AFAIK that test would normally > > Yeah, that's what %p in lynx.cfg should be doing, giving the path. It's > just that it gives the wrong path, "/username" rather than > "/home/username". Only if you had something like DIRED_MENU:FILE::Modify Permissions::LYNXDIRED://PERMIT_SRCfile://localhost%p in your lynx.cfg could such a thing be generated. I can't think of any reason to do that. :) Even in that case, the part after "file://localhost" would _still_ be a file path and not an URL path. Which makes a difference when you think of '%'-escaping, and possibly for other reasons. So there _still_ is no reason to use HTfullURL_toFile(). Klaus From owner-lynx-dev@sig.net Fri Nov 20 13:16:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA25535 for ; Fri, 20 Nov 1998 13:16:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA05225; Fri, 20 Nov 1998 11:53:12 -0600 (CST) Date: Fri, 20 Nov 1998 12:54:57 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811201254.AA1480@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.com In-Reply-To: of Fri, 20 Nov 1998 12:34:18 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 397 Lines: 6 Then it looks like to me it's the HTSprintf bug that's got things hosed up - same as the download prompt and a few other features. -- 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 Nov 20 14:16:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA02595 for ; Fri, 20 Nov 1998 14:16:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA25442; Fri, 20 Nov 1998 12:54:04 -0600 (CST) Message-ID: <19981120105556.54231@shell3.ba.best.com> Date: Fri, 20 Nov 1998 10:55:56 -0800 From: Kim DeVaughn To: lynx-dev@sig.net Subject: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) Mail-Followup-To: lynx-dev@sig.net References: <9811191809.AA11070@cas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Ismael Cordeiro on Fri, Nov 20, 1998 at 07:28:06AM -0500 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: 2058 Lines: 51 On Fri, Nov 20, 1998, Ismael Cordeiro (ismael@cordeiro.com) said: | | On Thu, 19 Nov 1998, Larry W. Virden wrote: | > | > If this is something open for discussion I kind of like: | > | > ^u - delete from current insert point to the beginning of the line | > ^w - delete previous word | > ^x - delete entire line | | In all Unix systems I access, running Solaris 2.5/ksh and FreeBSD/tcsh, ^U | deletes the whole line in the system prompt. I would like lynx to keep ^U as | "delete the whole line". I personally agree about ^U, though what this discussion points to is that a way to have *user* specifiable edit keymaps might be a good feature to consider (ie, a method that could be altered in (say) lynx.cfg, rather than requiring the map(s) to be compiled in). If enough folks are interested, I'll think about developing something along those lines. A couple other comments: 1. A "delete to beginning-of-line" function would be pretty trivial to add to LYStrings.[ch], though I've never had much need of it myself (which is why I didn't also add it, when I added the del-to-eol function). The devil, of course, is in a binding choice, as the other comments in this thread show :-) . 2. WRT binding ^W ... I too would prefer to have it bound to DELPW, but simply changing its mapping from a NOP to DELPW in the map struct didn't work. It seems that ^W gets snarfed up earlier in the food-chain, and used to refresh the screen (like ^L). Why this should be done, I dunno. I suppose some non-UNIX OS's must use ^W as the default for screen refreshing. As may be ... I wasn't motivated enough (nor am I familier enough with the code) to trace the keyboard input chain back up to where this is being done, and see about "fixing" it to have a more UNIX-like default behavior (^W is something else I use only infrequently). Comments ...? /kim =========================================================================== "When you open the box, the cat's either dead or it bites you." --M. Flynn From owner-lynx-dev@sig.net Fri Nov 20 14:51:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08272 for ; Fri, 20 Nov 1998 14:51:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA03290; Fri, 20 Nov 1998 13:17:12 -0600 (CST) Date: Fri, 20 Nov 1998 11:18:47 -0800 (PST) From: Ryan Hung To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 1898 Lines: 41 On Fri, 20 Nov 1998, Klaus Weide wrote: > It may or may not work, but that seems to be just fiddling around with > the symptoms. And I hope you would then carefully examine all places > where LYTrimRelFromAbsPath() gets called, and check whether your change > is always appropriate (and for all operating systems!). The problem > should be solved where it is generated, which is where the /~ is replaced > by something else. Hmm, I see. But where would "//" in a real pathname be appropriate? > > Yeah, that's what %p in lynx.cfg should be doing, giving the path. It's > > just that it gives the wrong path, "/username" rather than > > "/home/username". > > Only if you had something like > > DIRED_MENU:FILE::Modify Permissions::LYNXDIRED://PERMIT_SRCfile://localhost%p > > in your lynx.cfg could such a thing be generated. I can't think of any > reason to do that. :) No, that's the thing. It returns "%p" as "/username", even with LYNXDIRED://PERMIT_SRC%p. > Even in that case, the part after "file://localhost" would _still_ be > a file path and not an URL path. Which makes a difference when you > think of '%'-escaping, and possibly for other reasons. So there _still_ > is no reason to use HTfullURL_toFile(). Hmm. To clarify, what I'm getting with 2.8.2.dev.4 is that retrieving "file://localhost/~" or "file://localhost/~/" gets the correct home directory. However, the directory is listed as "/username" rather than "/home/username". When one does an "=" to look at the links there, the full path of the current page is listed as "//home/username". Ryan. _/ \__/ \__/ \__/ \__/ \__/ \__/ \__/rhung@vcn.bc.ca__/ \__/ \__/ \_Apoptosis=programmed cell death/ \__/ \rwhung@interchange.ubc.ca_/ \__ _/ --you can't live without it!/ \__/ \http://www.vcn.bc.ca/people/rhung \__/ \__/ \__/ \__/ \__/ \__/ \__/ \My words Copyright (C) 1998 \__ From owner-lynx-dev@sig.net Fri Nov 20 14:59:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08704 for ; Fri, 20 Nov 1998 14:59:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA06861; Fri, 20 Nov 1998 13:28:25 -0600 (CST) From: dickey@clark.net Message-Id: <199811201930.OAA13949@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 14:30:23 -0500 (EST) In-Reply-To: <9811201254.AA1480@cas.org> from "lvirden@cas.org" at Nov 20, 98 12:54:57 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: 25 > > Then it looks like to me it's the HTSprintf bug that's got things hosed up - > same as the download prompt and a few other features. That's what I expect. But I am a little puzzled: iirc, you are compiiling with gcc. The only problems I have found/fixed have been in the varargs.h code (not used with gcc) rather than the stdarg.h code. I have a pending patch with that (fixes for the non-stdarg.h code), plus Klaus' changes, will probably have it ready for checkin in the early morning (Friday nights never seem to work for patches -- too many errors) > -- > 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 Fri Nov 20 15:42:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA15868 for ; Fri, 20 Nov 1998 15:42:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24694; Fri, 20 Nov 1998 14:20:31 -0600 (CST) From: Philip Webb Message-Id: <199811202021.PAA21497@chass.utoronto.ca> Subject: lynx-dev OS390, BS2000 (was SUCCESS!!) To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 15:21:21 -0500 (EST) In-Reply-To: <199811201601.JAA01749@sanitas> from "pg@sweng.stortek.com" at Nov 20, 98 09:01: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: 995 Lines: 19 981120 pg wrote: > In a recent note, Martin Kraemer said: >> Just out of curiosity I fetched lynx2.8.2dev.4.zip after your >> announcement that the OS390 EBCDIC changes had been incorporated >> into standard lynx. And tried to compile it on BS2000. >> And BINGO!!! The EBCDIC charset was detected right away, and a first >> quick test shows that lynx 2-8-2b4 runs on BS2000 and displays most >> pages as expected. >> This OS is `different enough' (i.e., not at all similar, except for >> the char set) from IBM's OS390 that I can say that you did a >> tremendous job with the portability! will someone add OS390 & BS2000 to the list of supported systems? it's important new & potential users be aware of all successful ports. -- ========================,,============================================ 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 Nov 20 16:27:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA23038 for ; Fri, 20 Nov 1998 16:27:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA09520; Fri, 20 Nov 1998 15:04:11 -0600 (CST) Message-ID: <19981120160524.A13308@mail.bcpl.net> Date: Fri, 20 Nov 1998 16:05:24 -0500 From: Webmaster Jim To: lynx-dev@sig.net Subject: Re: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? References: <199811200822.RAA02606@ews07.nara.kindai.ac.jp> <199811201041.FAA26921@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811201041.FAA26921@shell.clark.net>; from dickey@clark.net on Fri, Nov 20, 1998 at 05:41:50AM -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.93.2i (1998-07-29) 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: 1065 Lines: 26 On Fri, Nov 20, 1998 at 05:41:50AM -0500, dickey@clark.net wrote: > > There are a few messages that, while they do have a reason for > > being separate, could function just as well if joined. The > > ones that come to mind are pairs like: > > Really exit from Lynx? [Y] > > Really exit from Lynx? [N] > > Would there be a significant problem if in both situations > > Really exit from Lynx? [Y/N] > > were used? > on top of that we need a utility function (on my list) to prompt for > yes/no/cancel. We need to look at all messages for language-bias, including things like "'D'ownload". The utility function should be generalized to deal with multiple choice questions so one could do: [1] 'd'ownload [2] 'v'iew [3] 'c'ancel. Thus, the historic English keystrokes will work, but NLS messages that translate this to [1] download [2] view [3] cancel in your language would be feasible. ------ Marvin the Paranoid Android says: You see the sort of thing I have to contend with. From owner-lynx-dev@sig.net Fri Nov 20 16:53:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA26903 for ; Fri, 20 Nov 1998 16:53:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA16131; Fri, 20 Nov 1998 15:24:04 -0600 (CST) Date: Fri, 20 Nov 1998 16:27:33 -0500 (EST) Message-Id: <199811202127.QAA10944@access2.digex.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.flora.org/lynx-dev/html/month1198/msg00563.html X-Mailer: Lynx, Version 2.8.1dev.7 From: asgilman@access.digex.net (Al Gilman) Subject: lynx-dev Do we need different strings per default [Y] Cc: asgilman@access.digex.net (Al Gilman) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2258 Lines: 63 > * Subject: lynx-dev Do we need [Y] AND [N] strings? Could they be > [Y/N]? > * From: Nelson Henry Eric <[6]nelsonhe@nara.kindai.ac.jp> > * Date: Fri, 20 Nov 1998 17:22:34 +0900 (JST) > _________________________________________________________________ > >There are a few messages that, while they do have a reason for >being separate, could function just as well if joined. The >ones that come to mind are pairs like: > Really exit from Lynx? [Y] > Really exit from Lynx? [N] >Would there be a significant problem if in both situations > Really exit from Lynx? [Y/N] >were used? There is a significant loss of information. The content of the [] is customarily the default you will get if you simply hit . Given that this is the tradition of command-line dialogs, it is dangerous to give users a Really exit? [Y/N] prompt _if_ there _is_ a default that will happen for a string other than Y*, y*, N*, or n*. The [Y/N] cue should only be used for situations where a clear Yes or No response is required and there is no default bound to or . Or, in the old days that's what it used to mean, if I can remember. Al > >There are a few instances like the following: > (WAIS Index) > WAIS Index: > WAIS Index.\n >I haven't looked at the code yet, but I suspect the same string >could be used in all three situations. Or perhaps only the >"WAIS Index" could be within the gettext() call. > >I'd like a little feedback before I start preparing patches. Am >I overlooking something? > >__Henry > _________________________________________________________________ > > Follow-Ups: > * [9]Re: lynx-dev Do we need [Y] AND [N] strings? Could they be > [Y/N]? > > * From: dickey@clark.net > _________________________________________________________________ > > * Prev: [10]lynx-dev How to get bz2 compressed files uncompressed > and rendered (not > * Next: [11]Re: lynx-dev NLS tweaks for 282dev4 > * Index(es): > + [12]Main > + [13]Thread > _________________________________________________________________ > > [14]Lynx mailing list archives > > [15][FLORA HOME] [16][LYNX Home] From owner-lynx-dev@sig.net Fri Nov 20 17:04:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA27922 for ; Fri, 20 Nov 1998 17:04:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA11730; Fri, 20 Nov 1998 15:10:43 -0600 (CST) Message-ID: <19981120161159.A15776@mail.bcpl.net> Date: Fri, 20 Nov 1998 16:11:59 -0500 From: Webmaster Jim To: lynx-dev@sig.net Cc: "K.R.Shamasundar" Subject: lynx-dev Irix compile problem -- ENTER key Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" X-Mailer: Mutt 0.93.2i 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.93.2i (1998-07-29) 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: 1758 Lines: 43 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii I haven't had access to that SGI system in over a year, so someone else will need to help you. I'm forwarding your question to the list (although I think you've tried that already). ------ Marvin the Paranoid Android says: You see the sort of thing I have to contend with. --/9DWx/yDrRhgMJTb Content-Type: message/rfc822 Content-Description: Forwarded message from "K.R.Shamasundar" Received: from ems.ncl.res.in (ems.ncl.res.in [202.54.11.129]) by mail.bcpl.net (8.8.7/8.8.7) with ESMTP id OAA06120 for ; Thu, 19 Nov 1998 14:38:28 -0500 (EST) Received: from comp.ncl.res.in (comp [172.16.22.6]) by ems.ncl.res.in with SMTP (8.7.1/8.7.1) id BAA02868 for <@ems.ncl.res.in:jspath@mail.bcpl.lib.md.us>; Fri, 20 Nov 1998 01:08:11 +0530 (IST) Received: from localhost (krss@localhost) by comp.ncl.res.in (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA13737 for ; Fri, 20 Nov 1998 01:01:54 +0530 Date: Fri, 20 Nov 1998 01:01:53 +0530 From: "K.R.Shamasundar" To: jspath@mail.bcpl.lib.md.us Subject: Lynx 2-8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I got your address from lynx-binaries page at http://www.crl.com/ You seem to have compiled lynx2-7 for sgi-irix m/c. I want to know if you have tried lynx2-8-1 version. I tried and I am having some problem with this. "ENTER/RETURN" key is not working at all. Can you suggest me something to solve this? Best Wishes, Shamsundar.K.R. --/9DWx/yDrRhgMJTb-- From owner-lynx-dev@sig.net Fri Nov 20 17:26:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA31723 for ; Fri, 20 Nov 1998 17:26:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA28787; Fri, 20 Nov 1998 16:00:13 -0600 (CST) Date: Fri, 20 Nov 1998 14:02:22 -0800 (PST) From: David Combs Message-Id: <199811202202.OAA24498@netcom11.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1006 Lines: 30 > From owner-lynx-dev@sig.net Thu Nov 19 08:49:41 1998 > Date: Thu, 19 Nov 1998 10:47:38 -0600 (CST) > From: Klaus Weide > To: lynx-dev@sig.net > Subject: Re: lynx-dev LYNX: "L"-page: PLEASE add "titles" too > In-Reply-To: > 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 > > On Wed, 18 Nov 1998, Leonid Pauzner wrote: > > > 18-Nov-98 05:11 Klaus Weide wrote: > > > > > You can't have the title unless lynx already has already seen it recently. > > > (In the same session. Unless someone adds a "permanent history list".) > > ^^^^^^^^^^^^^^^^^^^^^^ > > No, "permanent Visited Links" instead. > > I should have said: what other browsers call a permanent history list (or > similar). > > Klaus > > We ALREADY have a "permanent list for INTERESTING history": the bookmark page. Isn't that sufficient? From owner-lynx-dev@sig.net Fri Nov 20 17:30:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA32667 for ; Fri, 20 Nov 1998 17:30:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA29313; Fri, 20 Nov 1998 16:01:45 -0600 (CST) Date: Fri, 20 Nov 1998 14:03:58 -0800 (PST) From: David Combs Message-Id: <199811202203.OAA24584@netcom11.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 934 Lines: 31 > From owner-lynx-dev@sig.net Thu Nov 19 09:16:39 1998 > Date: Thu, 19 Nov 1998 11:15:14 -0600 (CST) > From: Klaus Weide > > On Wed, 18 Nov 1998 dickey@clark.net wrote: > > > 1998-11-18 (2.8.2dev.4) > [ ... ] > > New bindings: > > ^B = LYE_BACK cursor backwards > > ^F = LYE_FORW cursor forwards > > ^K = LYE_DELEOL delete to end-of-line > > ^T = LYE_DELNW delete next word > > ^X = LYE_DELPW delete previous word > > ^^ = LYE_UPPER upper case line (not active when kbd-layout binding is) > > ^_ = LYE_LOWER lower case line > > Would it be reasonable to have ^U behave like the readline default > (instead of erasing the whole line), i.e. (from the bash man page) > > unix-line-discard (C-u) > Kill backward from point to the beginning of the > line. > > I would personally prefer that behavior. > > Klaus > > Me too! From owner-lynx-dev@sig.net Fri Nov 20 17:33:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA32701 for ; Fri, 20 Nov 1998 17:32:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA01028; Fri, 20 Nov 1998 16:07:40 -0600 (CST) Date: Fri, 20 Nov 1998 14:09:54 -0800 (PST) From: David Combs Message-Id: <199811202209.OAA25105@netcom11.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 424 Lines: 17 > From owner-lynx-dev@sig.net Thu Nov 19 15:14:43 1998 > Date: Thu, 19 Nov 1998 18:09:23 -0500 (EST) > From: lvirden@cas.org (Larry W. Virden) > > If this is something open for discussion I kind of like: > > ^u - delete from current insert point to the beginning of the line > ^w - delete previous word > ^x - delete entire line > > -- > Larry W. Virden ME TOO!!!! David From owner-lynx-dev@sig.net Fri Nov 20 17:33:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA32715 for ; Fri, 20 Nov 1998 17:33:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA02449; Fri, 20 Nov 1998 16:11:52 -0600 (CST) Date: Fri, 20 Nov 1998 14:14:02 -0800 (PST) From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev Do we need different strings per default [Y] In-Reply-To: <199811202127.QAA10944@access2.digex.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: 1025 Lines: 25 On Fri, 20 Nov 1998, Al Gilman wrote: > There is a significant loss of information. The content of the > [] is customarily the default you will get if you simply hit > . Given that this is the tradition of command-line > dialogs, it is dangerous to give users a > > Really exit? [Y/N] > > prompt _if_ there _is_ a default that will happen for a string > other than Y*, y*, N*, or n*. The [Y/N] cue should only be > used for situations where a clear Yes or No response is required > and there is no default bound to or . > > Or, in the old days that's what it used to mean, if I can remember. How about having "Really exit?" as a gettext()'able string, with the function asking for user input appending '[Y/n]' or '[y/N]' as the case may be, with the capitalized letter being the default? (And possibly localizing {y,n}, if it needs to go that far...) -- GPG & PGP public keys: PGP fingerprint: 42 57 B3 D2 39 8E 74 C3 5E 4D AC 43 25 D2 26 D4 From owner-lynx-dev@sig.net Fri Nov 20 17:58:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA02496 for ; Fri, 20 Nov 1998 17:58:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA09929; Fri, 20 Nov 1998 16:32:54 -0600 (CST) Date: Fri, 20 Nov 1998 17:34:37 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811201734.AA4728@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr In-Reply-To: <199811201930.OAA13949@shell.clark.net> of Fri, 20 Nov 1998 14:30:23 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1051 Lines: 19 From: dickey@clark.net > But I am a little puzzled: iirc, you are compiiling with gcc. The only > problems I have found/fixed have been in the varargs.h code (not used with > gcc) rather than the stdarg.h code. > I have a pending patch with that (fixes for the non-stdarg.h code), plus > Klaus' changes, will probably have it ready for checkin in the early > morning (Friday nights never seem to work for patches -- too many errors) Actually, I am using Sun's ANSI C compiler. However, it should use stdargs.h as well. All I know is what I've been reporting regarding my download error. In it, I mention how there's a bug in HTSprintf function, where the dst_len comes in 0 but the dst_ptr is allocated, causing the sprintf loop to never get started after seeing the % sign ... -- 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 Nov 20 18:30:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA07516 for ; Fri, 20 Nov 1998 18:30:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA23226; Fri, 20 Nov 1998 17:11:04 -0600 (CST) From: dickey@clark.net Message-Id: <199811202313.SAA28978@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 18:13:21 -0500 (EST) In-Reply-To: <9811201734.AA4728@cas.org> from "lvirden@cas.org" at Nov 20, 98 05:34:37 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: 1046 Lines: 23 > Actually, I am using Sun's ANSI C compiler. However, it should use stdargs.h > as well. All I know is what I've been reporting regarding my download > error. In it, I mention how there's a bug in HTSprintf function, where > the dst_len comes in 0 but the dst_ptr is allocated, causing the sprintf > loop to never get started after seeing the % sign ... I don't have the man-page handy, but I seem to recall that the Sun compiler doesn't define __STDC__ unless you add options -- that's what lynx is using to trigger the stdarg.h/varargs.h (until I add some configure stuff to get the right version). -- I can't simply test if the header is there (I know, at least, that HP distributes a nicely-broken combination of compiler and headers, so I have to add in a compile-test ;-). Anyway - I had time today to test my changes on the SunOS K&R compiler, so I'm reasonably confident of them now. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 20 18:47:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA08756 for ; Fri, 20 Nov 1998 18:47:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20858; Fri, 20 Nov 1998 17:04:05 -0600 (CST) From: dickey@clark.net Message-Id: <199811202306.SAA27763@shell.clark.net> Subject: Re: lynx-dev Irix compile problem -- ENTER key To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 18:06:24 -0500 (EST) In-Reply-To: <19981120161159.A15776@mail.bcpl.net> from "Webmaster Jim " at Nov 20, 98 04:11: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: 2176 Lines: 52 I've tried responding to him on the mailing list a few times, but made no impression. (I suspect he's got a mismatch between the terminal and description, or the keypad "enter" vs the return "enter" is confusing). > --/9DWx/yDrRhgMJTb > Content-Type: text/plain; charset=us-ascii > > I haven't had access to that SGI system in over a year, so someone > else will need to help you. I'm forwarding your question to the list > (although I think you've tried that already). > > ------ > > Marvin the Paranoid Android says: > You see the sort of thing I have to contend with. > > --/9DWx/yDrRhgMJTb > Content-Type: message/rfc822 > Content-Description: Forwarded message from "K.R.Shamasundar" > > Received: from ems.ncl.res.in (ems.ncl.res.in [202.54.11.129]) > by mail.bcpl.net (8.8.7/8.8.7) with ESMTP id OAA06120 > for ; Thu, 19 Nov 1998 14:38:28 -0500 (EST) > Received: from comp.ncl.res.in (comp [172.16.22.6]) by ems.ncl.res.in with SMTP (8.7.1/8.7.1) id BAA02868 for <@ems.ncl.res.in:jspath@mail.bcpl.lib.md.us>; Fri, 20 Nov 1998 01:08:11 +0530 (IST) > Received: from localhost (krss@localhost) by comp.ncl.res.in (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA13737 for ; Fri, 20 Nov 1998 01:01:54 +0530 > Date: Fri, 20 Nov 1998 01:01:53 +0530 > From: "K.R.Shamasundar" > To: jspath@mail.bcpl.lib.md.us > Subject: Lynx 2-8 > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Hi, > I got your address from lynx-binaries page at http://www.crl.com/ > You seem to have compiled lynx2-7 for sgi-irix m/c. I want to know if you > have tried lynx2-8-1 version. I tried and I am having some problem with > this. "ENTER/RETURN" key is not working at all. Can you suggest me > something to solve this? > > Best Wishes, > Shamsundar.K.R. > > > > --/9DWx/yDrRhgMJTb-- -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Fri Nov 20 18:57:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA10563 for ; Fri, 20 Nov 1998 18:57:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA00678; Fri, 20 Nov 1998 17:34:04 -0600 (CST) Date: Fri, 20 Nov 1998 18:35:50 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811201835.AA6815@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr In-Reply-To: <199811202313.SAA28978@shell.clark.net> of Fri, 20 Nov 1998 18:13:21 -0500 (EST) 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: 10 Hmm - well, I am rebuilding now with the -Xc flag to the compiler. I'm concerned about doing this - this means use strictly only ANSI C features, and don't include Solaris specific features. I've not seen a lot of luck with this, since things like #ifdef sun nolonger works... But we will see. -- 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 Nov 20 19:13:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA13246 for ; Fri, 20 Nov 1998 19:13:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA05958; Fri, 20 Nov 1998 17:51:13 -0600 (CST) Date: Fri, 20 Nov 1998 18:53:00 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811201853.AA10670@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr In-Reply-To: <199811202313.SAA28978@shell.clark.net> of Fri, 20 Nov 1998 18:13:21 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 596 Lines: 11 Okay, I compiled lynx with -Xc, which the man page says turns __STDC__ to 1. I still see the same behavior in Sprintf. But perhaps I now need to wait for your fixes . Luckily, everything compiles fine in lynx. Perhaps I need to do the same thing in ncurses to get around that annoying problem it has displaying periods... -- 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 Nov 20 19:26:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA14811 for ; Fri, 20 Nov 1998 19:26:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA10823; Fri, 20 Nov 1998 18:07:01 -0600 (CST) From: dickey@clark.net Message-Id: <199811210009.TAA08506@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 19:09:21 -0500 (EST) In-Reply-To: <9811201835.AA6815@cas.org> from "lvirden@cas.org" at Nov 20, 98 06:35: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: 891 Lines: 26 > > Hmm - well, I am rebuilding now with the -Xc flag to the compiler. > I'm concerned about doing this - this means use strictly only ANSI C > features, and don't include Solaris specific features. I've not > seen a lot of luck with this, since things like #ifdef sun nolonger works... or just go down into WWW/Library/Implementation/HTUtils.h and change #if defined(__STDC__) || defined(VMS) to #if 1 /* defined(__STDC__) || defined(VMS) */ (I'll add a configure test, but I assume you'd like to compile) > But we will see. > -- > 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 Fri Nov 20 19:30:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA16169 for ; Fri, 20 Nov 1998 19:30:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA08523; Fri, 20 Nov 1998 17:59:39 -0600 (CST) Message-Id: <199811202223.XAA21481@mail.macqel.be> Subject: lynx-dev lynx aborts with http://www.asuscom.com.tw/linux.html To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 23:23:32 +0100 (CET) From: "Philippe De Muyter" 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: 452 Lines: 18 lynx aborts on the following url : http://www.asuscom.com.tw/linux.html because of the following in LYCharUtils.c/LYHandleMETA /* * Hope it's a match, for now. - FM */ cp1 = &cp4[10]; <<<<<<< How can we be sure there are 10 chars there ? in the testcase, cp4 is `big5' while (*cp1 && isdigit((unsigned char)(*cp1))) cp1++; *cp1 = '\0'; <<<<<<< Corrupts the heap. Philippe De Muyter - phdm@macqel.be From owner-lynx-dev@sig.net Fri Nov 20 20:36:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA25653 for ; Fri, 20 Nov 1998 20:36:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA01747; Fri, 20 Nov 1998 19:16:56 -0600 (CST) Message-ID: <19981121021909.A16928@mema.ucl.ac.be> Date: Sat, 21 Nov 1998 02:19:09 +0100 From: Serge MUNHOVEN To: lynx-dev@sig.net Subject: Re: lynx-dev internal cache proposal References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Leonid Pauzner on Wed, Nov 18, 1998 at 04:43:04AM +0300 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2415 Lines: 47 On Wed, Nov 18, 1998 at 04:43:04AM +0300, Leonid Pauzner wrote: > > >> * compressed files? > > > Why not? :) > cache uncompressed data or the original? > Or compress originals that don't already seem to be ? For a persistent cache this could be a useful configuration option too. Personnally I'm more interested in a short time cache. Kind of: I would like to save a copy of the document I am currently looking at (or one of those visited during this session) and don't want to transfer it once more. I was already wondering if I could hack lynx to *replace* its current rendered cache by a raw one, but I guess the proposal discussed in the recent days is a far better idea on the long run. As to non-HTML documents, they all seem to be already kept in temporary files, though you do not have access to them ("e.g. interesting PostScript document I'm looking at; would be nice if I could get into the downloader menu now, to save it with a useful suggested name, since the document is already on my disk"). I understand why results from POSTed queries should not be cached, but shouldn't they still appear in the history and at least be accessible there without reposting the request ? From what I understand, the trouble is the arbitrariy length and contents of that kind of queries. If this could be managed some how, those documents would be "historied" (trying to avoid "cached") as well. I was not fully aware that there is "caching" for the purpose of history and for the purpose of cache (or kind of mirroring). Thanks to the previous contributors. :-) But having all those documents in "history", shouldn't we leave the option to get a prompt to : "revalidate" (and retrieve accordingly from the cache or the net; this would be the default and the action taken straight away when this prompt is disabled) or "redisplay" (I've been warned that the document may be out-dated, but that's alright, just give me what you've already got). There is already a similar choice (though between "resubmitting" and simply "skipping" when moving back beyond the implemented history-"cache"). Just a few random thoughts (not even 5 cents). Maybe the following triggers a few ideas or at least some interesting links : http://mnot.cbd.net.au/cache_docs/ though it already mixes up cache and history a bit (and the HTML does not look that pretty with lynx, but that's an other story). - Serge From owner-lynx-dev@sig.net Fri Nov 20 20:50:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA28280 for ; Fri, 20 Nov 1998 20:50:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA06182; Fri, 20 Nov 1998 19:31:57 -0600 (CST) Message-ID: <19981120173407.B12688@psnw.com> Date: Fri, 20 Nov 1998 17:34:07 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev Cookie+PostQuery+Dump_Immediately bug :) Mail-Followup-To: lynx-dev@sig.net References: <199811191820.TAA20242@ow2.wins.uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811191820.TAA20242@ow2.wins.uva.nl>; from "Elwin M. Oost" on Thu, Nov 19, 1998 at 07:20:41PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 5:30pm up 3 days, 1:03, 4 users, load average: 1.00, 1.00, 1.00 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1127 Lines: 30 On Prickle-Prickle, the 32nd of The Aftermath, 3164, Elwin M. Oost wrote: > Hi, > > First off, thank you all for giving Lynx to the community! > > I _think_ I found a bug in LYCookies.c (Lynx 2.8.1). > > I wanted to automate post-query'ing a site which redirects Lynx with a 302 > (yes, it's Microsoft :) to another page. It uses cookies to save info. > > Browsing everything went fine, but using post_data Lynx kept losing the > cookie. I checked the help rigorously and after that the source to find some > switch I had forgotten, but I _think_ I found a bug there. > > store_cookie (LYCookies.c) skips walking through domain_list if > dump_output_immediately=TRUE. However, 'de' which holds the domain_entry is > initialized during this walk. > > As such, HTConfirmCookie (HTAlert.c) receives an empty 'de' and will > reject it. Taking a look at the code you mentioned, it looks to me like you're right. Does anyone know a reason for the current behavior? It definitely seems wrong to me. Will have a patch soon-ish to take care of this, unless someone has a reason against it.. -- Real programs don't eat cache. From owner-lynx-dev@sig.net Fri Nov 20 21:11:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA32695 for ; Fri, 20 Nov 1998 21:11:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA10821; Fri, 20 Nov 1998 19:48:20 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Fri, 20 Nov 1998 20:50:38 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev lynx aborts with http://www.asuscom.com.tw/linux.html In-Reply-To: <199811202223.XAA21481@mail.macqel.be> 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: 626 Lines: 17 On Fri, 20 Nov 1998, Philippe De Muyter wrote: > lynx aborts on the following url : > > http://www.asuscom.com.tw/linux.html Which version of lynx are you using? lynx2.8.2dev.2 and dev.4 say "Alert!: big5" but display the document without problems. 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 Nov 20 22:42:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA13879 for ; Fri, 20 Nov 1998 22:42:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA05163; Fri, 20 Nov 1998 21:26:14 -0600 (CST) Message-ID: <19981120192822.A18195@psnw.com> Date: Fri, 20 Nov 1998 19:28:22 -0800 From: "brian j. pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev Cookie+PostQuery+Dump_Immediately bug :) Mail-Followup-To: lynx-dev@sig.net References: <199811191820.TAA20242@ow2.wins.uva.nl> <19981120173407.B12688@psnw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981120173407.B12688@psnw.com>; from "brian j. pardy" on Fri, Nov 20, 1998 at 05:34:07PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 7:26pm up 3 days, 3:00, 4 users, load average: 1.00, 1.06, 1.08 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 543 Lines: 14 I wrote: > Taking a look at the code you mentioned, it looks to me like you're right. > > Does anyone know a reason for the current behavior? It definitely seems > wrong to me. > > Will have a patch soon-ish to take care of this, unless someone has a > reason against it.. On second thought, maybe I won't. It looks like weird things are done with dump_output_immediately. If someone else wants to take a look at this too, it'd be a good thing. It's confusing me. :) -- If you can lead it to water and force it to drink, it isn't a horse. From owner-lynx-dev@sig.net Fri Nov 20 23:10:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA17926 for ; Fri, 20 Nov 1998 23:10:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAB10526; Fri, 20 Nov 1998 21:54:02 -0600 (CST) Date: Sat, 21 Nov 1998 12:57:31 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811210357.MAA07519@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev New editing key bindings (was Re: lynx2.8.2dev.4) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 284 Lines: 7 > deletes the whole line in the system prompt. I would like lynx to keep ^U as > "delete the whole line". "Delete the whole line" is easier to translate, so I'd like to keep it that way, too. Also, there is already the message in Lynx: "Use Control-U to erase the default." __Henry From owner-lynx-dev@sig.net Fri Nov 20 23:19:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA19232 for ; Fri, 20 Nov 1998 23:19:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA12197; Fri, 20 Nov 1998 22:03:57 -0600 (CST) Date: Sat, 21 Nov 1998 12:51:44 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811210351.MAA07484@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 997 Lines: 23 > on top of that we need a utility function (on my list) to prompt for > yes/no/cancel. Oh, yes, been waiting for something like that. Won't do anything then since a much better solution is in the making. > > There are a few instances like the following: > > (WAIS Index) > > WAIS Index: > > WAIS Index.\n > > I haven't looked at the code yet, but I suspect the same string > > could be used in all three situations. Or perhaps only the > > "WAIS Index" could be within the gettext() call. > > that is what I would do - and make the string a #define in LYMessages_en.h Okay, in general, then, I'll move in that direction. As for the example I gave (WAIS), I propose that actually we remove gettext from all of them since WAIS is all but dead as a protocol. The strings are probably more understandable in English than translated anyway. I'll also be reviewing the lynx.po file from that point of view, i.e., checking for validity as a target for translation, as well. __Henry From owner-lynx-dev@sig.net Fri Nov 20 23:38:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA22502 for ; Fri, 20 Nov 1998 23:38:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA16737; Fri, 20 Nov 1998 22:22:23 -0600 (CST) Date: Sat, 21 Nov 1998 13:26:02 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811210426.NAA07664@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev gettext() question #2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 592 Lines: 12 > Right. But we need to know for sure the gettext's charset and redefine > gettext() to enable UC translation in lynx. Sorry it's taken me so long to understand what you were getting at. What you propose may actually be quite simple to implement, if it isn't already. Xgettext produces, and msgfmt refuses to compile any file that does not have, a "Content-Type: text/plain; charset=" line. This string is preserved, in ascii not binary form, in the lynx.mo file that the running Lynx is referring to. You do "know for sure" what the charset of the current message catalogue is. __Henry From owner-lynx-dev@sig.net Fri Nov 20 23:52:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA25163 for ; Fri, 20 Nov 1998 23:52:25 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA21118; Fri, 20 Nov 1998 22:36:48 -0600 (CST) Date: Sat, 21 Nov 1998 13:40:18 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811210440.NAA07767@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Viewing bz2 files Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 254 Lines: 7 > I use bzcat because the other two make bzip2 to give a "broken pipe" message > at the end. No need to put references to bzip2 in .mime.types or .mailcap. I wonder if that message was what was tripping me up. Anyway, Ismael, thanks a million! __Henry From owner-lynx-dev@sig.net Sat Nov 21 06:34:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA10662 for ; Sat, 21 Nov 1998 06:34:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA06451; Sat, 21 Nov 1998 05:11:31 -0600 (CST) To: lynx-dev@sig.net References: <199811202223.XAA21481@mail.macqel.be> Message-Id: From: "Leonid Pauzner" Date: Sat, 21 Nov 1998 14:11:14 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: lynx-dev LYHandleMETA problem (was: lynx aborts with http://www.asuscom.com.tw/linux.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: 2485 Lines: 68 > lynx aborts on the following url : > http://www.asuscom.com.tw/linux.html this page have "big5" charset; for display charset other than big5 you cannot view the page properly and got a warning "Alert: big5" message (yes, there is no check for 8bit characters in the document at this point). Hope nothing dangerous here, but the comment is misguding (see below). > because of the following in LYCharUtils.c/LYHandleMETA > /* > * Hope it's a match, for now. - FM ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > */ > cp1 = &cp4[10]; <<<<<<< How can we be sure there > are 10 chars there ? > in the testcase, > cp4 is `big5' > while (*cp1 && > isdigit((unsigned char)(*cp1))) > cp1++; > *cp1 = '\0'; <<<<<<< Corrupts the heap. > Philippe De Muyter - phdm@macqel.be Fote's 2.7.2 code say: ====================== UCSetTransParams(&me->T, me->inUCLYhndl, me->inUCI, me->outUCLYhndl, me->outUCI); /* * Check for an iso-8859-# we don't know. - FM */ } else if (!strncmp(cp4, "iso-8859-", 9) && isdigit(cp4[9]) && !strncmp(LYchar_set_names[current_char_set], "Other ISO Latin", 15)) { /* * Hope it's a match, for now. - FM */ cp1 = &cp4[10]; while (*cp1 && isdigit((unsigned char)(*cp1))) cp1++; *cp1 = '\0'; StrAllocCopy(me->node_anchor->charset, cp4); HTPassEightBitRaw = TRUE; HTAlert(me->node_anchor->charset); } FREE(cp3); if (TRACE && me->node_anchor->charset) { fprintf(stderr, "LYHandleMETA: New charset: %s\n", me->node_anchor->charset); } } "Other ISO Latin" now obsolete and removed, but the comment was not changed, sorry. Case "else" corresponds to !CanTranslateFromTo(), in your case UC-based display and CJK document, so some kind of warning probably a good idea. From owner-lynx-dev@sig.net Sat Nov 21 08:02:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA15899 for ; Sat, 21 Nov 1998 08:02:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA13226; Sat, 21 Nov 1998 06:44:00 -0600 (CST) From: David Woolley Message-Id: <199811202357.XAA14374@djwhome.demon.co.uk> Subject: Re: lynx-dev http://wire.ap.org To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 23:57:52 +0000 (GMT) In-Reply-To: <199811191322.IAA10743@chass.utoronto.ca> from "Philip Webb" at Nov 19, 98 08:22: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: 1676 Lines: 32 > i've never before encountered a situation > in which 2 \'s take me to a different rendered page. That could happen if a cache considered the page at least marginally cacheable and the origin server failed to set a correct Vary header on a page which was dependent on the User-Agent header. What might then happen is that the fastest responding upstream cache varied from request to request and you got versions of the page tailored for different browsers - there is an awful lot of ignorance about caching issues amongst web site designers. Vary is an HTTP 1.1 header which tells a cache that the content of the page is dependent on the values of named headers as well as the URL requested. A server that is acting on the user agent should set: Vary: User-Agent However, most user-agent conditional pages are done using dynamically created HTML, not content negotiation and, unless, as is unlikely, the, typically ASP, script sets that header there will be no indication. Such pages are largely uncacheable, but an incorrect server date, explicit expiry information, or an aggressive cache might still result in its being cached. An HTTP 1.0 cache would also fail to act on Vary. I would suggest looking at the headers, and if they don't contain Vary and/or a combination of Cache-Control: no-cache and Pragma: no-cache, you should add these points to the complaint about not designing the pages to fail gracefully when JavaScript is missing of disabled. Don't expect any sympathy; they are in business to make money, not to produce valid HTTP and HTML; you'd need to convince them that supporting Lynx is more profitable than some other changes they could make. From owner-lynx-dev@sig.net Sat Nov 21 08:02:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA15900 for ; Sat, 21 Nov 1998 08:02:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA13263; Sat, 21 Nov 1998 06:44:24 -0600 (CST) From: David Woolley Message-Id: <199811200832.IAA13606@djwhome.demon.co.uk> Subject: lynx-dev Enter/Return fails on SGI Port (was: [ no useful subject ] ) To: lynx-dev@sig.net Date: Fri, 20 Nov 1998 08:32:10 +0000 (GMT) In-Reply-To: from "K.R.Shamasundar" at Nov 19, 98 09:33:08 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: 764 Lines: 13 > This is again in connection with my previous email. "RETURN/ENTER" > key is not being recognized at all by lynx2-8-1 here in SGI-IRIX-6.2 m/c. > This is not just for the case I mentioned in my last email. Last case was > just one example. I think the reason you don't get replies is that no-one has such a system, and failure of return/enter is a very unlikely symptom; one would expect nearly every full screen program to fail as well. You are going to have to do some research into what is special about terminal handling and curses/ncurses on SGI machines. Could you possibly confirm that this is a general failure, because it is just possible that you are expecting a behaviour exhibited by particular GUI browsers which isn't duplicated by Lynx. From owner-lynx-dev@sig.net Sat Nov 21 10:52:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA25510 for ; Sat, 21 Nov 1998 10:52:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA27061; Sat, 21 Nov 1998 09:06:00 -0600 (CST) Date: Sat, 21 Nov 1998 14:43:48 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811210543.OAA08202@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 331 Lines: 8 > messages that translate this to > [1] download [2] view [3] cancel in your language Actually, I do `[D] ja_dwnld [V] ja_view [C] ja_cncl', and prefer it that way to numbers. Students refuse to recognize a difference between numbers above the alpha keys and numbers on the number pad. The results are a total disaster. __Henry From owner-lynx-dev@sig.net Sat Nov 21 10:54:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA25520 for ; Sat, 21 Nov 1998 10:54:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA26957; Sat, 21 Nov 1998 09:05:03 -0600 (CST) From: dickey@clark.net Message-Id: <199811211315.IAA18605@shell.clark.net> Subject: Re: lynx-dev Do we need [Y] AND [N] strings? Could they be [Y/N]? To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 08:15:20 -0500 (EST) In-Reply-To: <199811210351.MAA07484@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 21, 98 12:51:44 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: 1400 Lines: 36 > > > on top of that we need a utility function (on my list) to prompt for > > yes/no/cancel. > > Oh, yes, been waiting for something like that. Won't do anything then > since a much better solution is in the making. ok (we already have one variant - I was looking at it last night), but it's a little incompatible with the other uses. > > > There are a few instances like the following: > > > (WAIS Index) > > > WAIS Index: > > > WAIS Index.\n > > > I haven't looked at the code yet, but I suspect the same string > > > could be used in all three situations. Or perhaps only the > > > "WAIS Index" could be within the gettext() call. > > > > that is what I would do - and make the string a #define in LYMessages_en.h > > Okay, in general, then, I'll move in that direction. As for the > example I gave (WAIS), I propose that actually we remove gettext from > all of them since WAIS is all but dead as a protocol. The strings > are probably more understandable in English than translated anyway. > I'll also be reviewing the lynx.po file from that point of view, i.e., > checking for validity as a target for translation, as well. if we can reduce the list of filenames to 1024 characters, that will let us use the Solaris xgettext code - iirc we are around 1350 now. > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 12:07:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA29355 for ; Sat, 21 Nov 1998 12:07:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA09138; Sat, 21 Nov 1998 10:41:23 -0600 (CST) From: dickey@clark.net Message-Id: <199811211643.LAA21604@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.5 To: lynx-dev@sig.net (Lynx Development) Date: Sat, 21 Nov 1998 11:43:45 -0500 (EST) 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: 4187 Lines: 67 1998-11-21 (2.8.2dev.5) * modify HTLoadFile() to make compressed files work with OS/2 EMX and LYSystem() to convert forward slashes in pathnames to backslashes, also for EMX (patches by Ilya Zakharevich). * documentation nits (aprostrophes) in lynx.cfg and userdefs.h - LV * fix inconsistent newlines in po/it.po (report by Irving_Wolfe@Wolfe.net) - TD * modify config.guess, added Intergraph 2430 CLIX machines (reported by Alex Matulich ) - TD * minor fix in LYCharSets.c according to recent changes in UCDefs.h introduced by IBM OS/2 codepage number - LP * modify configure script to work with --enable-nls built into a subdirectory of the source tree (reported by PG) - TD * disable regeneration of intl/po2tbl.sed and po/POTFILES if --disable-nls configure option is specified - TD * add configure test for stdarg.h vs varargs.h - TD * fixes to work with SunOS K&R compiler - TD * don't trim trailing and leading spaces from unformatted text lines in some cases (split_line in GridText.c). Prevents corruption of some uuencoded files when they are displayed and then 'P'rinted (although 'D'ownload should be used instead) - KW * some changes in HText_appendCharacter (GridText.c). Splitting of long SOURCE lines now works with color styles - KW * workaround for multiple anchors in the same (invalid) HTML document with the same NAME and different destinations (HTAnchor.c) - KW * check for 'z'ap while constructing local directory listings (non-VMS only, in HTFile.c) - KW * added a couple outofmem checks (HTAnchor.c). Minor TRACE message change in GridText.c for -tlog / USE_TRACE_LOG disabled - KW * when adding bookmark entries, don't accept a title string which appears to consist only of blank characters (LYBookmark.c). When rendering a bookmark file, use hiddenlinks=merge counting, so that numbers after entries with empty titles don't get out of whack (GridText.c). This should prevent 'R' from removing the wrong bookmark entry - KW * prevent generation of some unnecessary temp files when constructing mailcap file test commands (HTInit.c) - KW * include LYLeaks.h in UCdomap.c for memory leak detection - KW * fixed various memory leaks (UCdomap.c, LYShowInfo.c, LYReadCFG.c, LYMain.c, LYDownload.c, LYBookmark.c, HTML.c, DefaultStyle.c) - KW * escape '&' and '<' in HTML generated to display current lynx.cfg option values (LYReadCFG.c) - KW * revert logic in split_line. Emphasis highlighting that should extend over several lines was being lost at line breaks (GridText.c). (IsSpecialAttrChar probably shouldn't return true for LY_SOFT_NEWLINE since in most places it tests whether to skip a character position, but as long as this special char is only used in SOURCE mode it cannot mess up any anchor positions so it should be ok. - KW * correct character counting in SOURCE display continuation lines. A highlighted search target would be shown shifted left by one character position because the LY_SOFT_NEWLINE special was displayed as '+' but not counted (GridText.c) - KW * prevent generation of invalid/unparseable comments if UCSaveBookmarksInUnicode is in effect, other minor changes in LYBookmark.c - KW * correction for color styles in HText_appendCharacter (GridText.c). At some point a memmove was replaced by a for loop, but source and destination were reversed and the counter was wrong - KW * modify HTSprintf/HTSprintf0 to use a more generic approach to varargs by using only va_alist in the parameter list - TD * correct html expression in LYShowInfo.c of dev.3 which did not allow the temp file with the lynx.cfg settings to be accessed from the Configuration Definitions page (patch by Ismael Cordeiro). * correct "Exiting" message format in cleanup_sig(), which had unexpanded %d (reported by BJP) - TD * add to config.hin the definitions set by AM_GNU_GETTEXT macro (PG pointed out that this also sets 'inline', needed for GNU gettext) - TD * modify MakeNewTitle() to check for null pointer, fixing core dump with verbose images when value[src_type] is null (reported by John Bley for 2.8.1rel.2) - TD From owner-lynx-dev@sig.net Sat Nov 21 12:56:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA32299 for ; Sat, 21 Nov 1998 12:55:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA15963; Sat, 21 Nov 1998 11:33:09 -0600 (CST) Date: Sat, 21 Nov 1998 12:34:59 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811211234.AA317@cas.org> Subject: lynx-dev lynx 2.8.2dev.5 still problems To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 701 Lines: 13 I just built the latest changes in dev.5 and still see the HTSprintf bug . Platform: SPARC Solaris 2.6 Sun compiler -Xc flag. I can send along the config flags, the output from configure and the make and I can run tests for someone. Oh, and the ncurses problem of redisplaying pages on initial startup of lynx is still there as well. I've not tried to see if the problem with highlighted strings with periods is still there or not. -- 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 Nov 21 13:02:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA00201 for ; Sat, 21 Nov 1998 13:02:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA13708; Sat, 21 Nov 1998 11:15:23 -0600 (CST) Date: Sat, 21 Nov 1998 09:17:38 -0800 (PST) From: David Combs Message-Id: <199811211717.JAA17133@netcom5.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2410 Lines: 61 > From owner-lynx-dev@sig.net Fri Nov 20 14:38:52 1998 > Date: Fri, 20 Nov 1998 17:34:37 -0500 (EST) > From: lvirden@cas.org (Larry W. Virden) > > From: dickey@clark.net > > > But I am a little puzzled: iirc, you are compiiling with gcc. The only > > problems I have found/fixed have been in the varargs.h code (not used with > > gcc) rather than the stdarg.h code. > > > I have a pending patch with that (fixes for the non-stdarg.h code), plus > > Klaus' changes, will probably have it ready for checkin in the early > > morning (Friday nights never seem to work for patches -- too many errors) > > Actually, I am using Sun's ANSI C compiler. However, it should use stdargs.h > as well. All I know is what I've been reporting regarding my download > error. In it, I mention how there's a bug in HTSprintf function, where > the dst_len comes in 0 but the dst_ptr is allocated, causing the sprintf > loop to never get started after seeing the % sign ... > -- > Larry W. Virden I do hope all these problems that Larry V. is finding get fixed in the configure etc, and NOT just by some instructions "for Solaris get this, and this, and be sure to do this, and that, hand hack these lines in the makefile, etc, etc" -- hopefully so that making on solaris is FULLY AUTOMATIC. -- I myself am simply WAITING until Larry, by his emails to the list, seems satisfied, BEFORE I go re-download a fresh & fixed version and try it on MY sparc/solaris. Seeing so many problems from larry, I haven't even TRIED to compile the version I downloaded two weeks ago... --- re "prefix": By the way, like lots of people, I will have to use "prefix=" somewhere, since, like with lots of people, I followed sun's (implicit) instructions and made all these various file-systems, and now there's not enough room to install anything on /usr/local. (Yes, I now know better: have maybe just TWO filesystems: root, and one for everything else; that's it. Will do it that way when I install solaris 2.7, which just arrived two days ago. Will do this in what, 6 months? (safety)) But please add instructions and hints re this PREFIX stuff, eg hints and tricks via symbolic links in /usr/local, etc. THANKS! David PS: what a NEAT program this lynx is -- and what a LOT of HARD work you guys are doing. And Hooray, too, that Klaus is back, and seems REALLY eager to work! From owner-lynx-dev@sig.net Sat Nov 21 13:08:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA00299 for ; Sat, 21 Nov 1998 13:08:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA17418; Sat, 21 Nov 1998 11:45:29 -0600 (CST) Date: Sat, 21 Nov 1998 12:47:19 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811211247.AA495@cas.org> Subject: lynx-dev Proposed fix for lynx To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 803 Lines: 17 Tom or someone else familar with the HTString.c module, do you have time to look at this change? After making it, it _seems_ like I am getting better behavior both for the download msgs AND for mail.yahoo.com --- HTString.c-dist Sat Nov 21 12:46:03 1998 +++ HTString.c Sat Nov 21 12:42:09 1998 @@ -414,3 +414,4 @@ fmt_ptr[f++] = *fmt; - while (*++fmt != '\0' && dst_len != 0 && !done) { + /* while (*++fmt != '\0' && dst_len != 0 && !done) { */ + while (*++fmt != '\0' && have != 0 && !done) { fmt_ptr[f++] = *fmt; -- 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 Nov 21 14:01:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA03798 for ; Sat, 21 Nov 1998 14:01:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA24494; Sat, 21 Nov 1998 12:42:35 -0600 (CST) From: dickey@clark.net Message-Id: <199811211844.NAA09106@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 13:44:57 -0500 (EST) In-Reply-To: <199811211717.JAA17133@netcom5.netcom.com> from "David Combs " at Nov 21, 98 09:17:38 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: 2146 Lines: 54 > I do hope all these problems that Larry V. is finding get > fixed in the configure etc, and NOT just by some instructions > "for Solaris get this, and this, and be sure to do this, and > that, hand hack these lines in the makefile, etc, etc" -- Yes - that's the general rule. I do add special ifdef's for the places where I cannot make configure-tests (non-Unix platforms such as VMS). For the varargs/stdarg differences, it had been a while since I'd coded that (since all of the other programs that I had as a model I'd converted to stdarg a couple of years ago). For whatever reason, I made an error in the varargs case (unlike stdarg, the called function must start processing the argument list from the beginning). > hopefully so that making on solaris is FULLY AUTOMATIC. > I myself am simply WAITING until Larry, by his emails to > the list, seems satisfied, BEFORE I go re-download a fresh & > fixed version and try it on MY sparc/solaris. > > Seeing so many problems from larry, I haven't even TRIED > to compile the version I downloaded two weeks ago... > > --- re "prefix": > > By the way, like lots of people, I will have to use "prefix=" > somewhere, since, like with lots of people, I followed sun's > (implicit) instructions and made all these various file-systems, > and now there's not enough room to install anything on /usr/local. when I test the prefix stuff, I usually install into /tmp/BUILD, and check that it works properly from that location. > (Yes, I now know better: have maybe just TWO filesystems: > root, and one for everything else; that's it. Will do it that > way when I install solaris 2.7, which just arrived two days > ago. Will do this in what, 6 months? (safety)) > > But please add instructions and hints re this PREFIX stuff, > eg hints and tricks via symbolic links in /usr/local, etc. > > THANKS! > > David > > PS: what a NEAT program this lynx is -- and what a LOT of HARD > work you guys are doing. And Hooray, too, that Klaus is back, > and seems REALLY eager to work! > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:04:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA03826 for ; Sat, 21 Nov 1998 14:04:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA24981; Sat, 21 Nov 1998 12:46:45 -0600 (CST) From: dickey@clark.net Message-Id: <199811211849.NAA09518@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 13:49:07 -0500 (EST) In-Reply-To: <9811211234.AA317@cas.org> from "lvirden@cas.org" at Nov 21, 98 12:34: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: 991 Lines: 28 > I just built the latest changes in dev.5 and still see the HTSprintf bug . hmm. I'll need more information - I ran the SunOS version for about an hour yesterday and saw no problem (nor did Purify). So it's not likely to be the varargs/stdarg difference. More along the lines of 'I did this, and then that'. > Platform: SPARC Solaris 2.6 Sun compiler -Xc flag. I can send along > the config flags, the output from configure and the make and I can > run tests for someone. Perhaps a typescript output would help me see what you're seeing (gzip and uuencode). > Oh, and the ncurses problem of redisplaying pages on initial startup of > lynx is still there as well. I've not tried to see if the problem with that's likely - we've not not done anything to address that. > highlighted strings with periods is still there or not. ditto. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 12:26:57 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01039 for ; Sat, 21 Nov 1998 12:26:52 -0500 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00186 for ; Sat, 21 Nov 1998 17:32:50 -0500 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 QAA06835 for ; Sat, 21 Nov 1998 16:50:30 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA13430; Sat, 21 Nov 1998 15:31:49 -0600 (CST) Message-ID: <19981121133403.B24763@psnw.com> Date: Sat, 21 Nov 1998 13:34:03 -0800 From: "brian j. pardy" To: Lynx Development Subject: Re: lynx-dev lynx2.8.2dev.5 (tiny changes nit) Mail-Followup-To: Lynx Development References: <199811211643.LAA21604@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811211643.LAA21604@shell.clark.net>; from "dickey@clark.net" on Sat, Nov 21, 1998 at 11:43:45AM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 1:26pm up 3 days, 20:59, 5 users, load average: 1.00, 1.00, 1.00 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 456 Lines: 11 dickey@clark.net wrote: > 1998-11-21 (2.8.2dev.5) > * modify HTLoadFile() to make compressed files work with OS/2 EMX and > LYSystem() to convert forward slashes in pathnames to backslashes, also for > EMX (patches by Ilya Zakharevich). > * documentation nits (aprostrophes) in lynx.cfg and userdefs.h - LV ^^^^^^^^^^^^ apostrophes -- When the bosses talk about improving productivity, they are never talking about themselves. From owner-lynx-dev@sig.net Sat Nov 21 12:29:15 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01274 for ; Sat, 21 Nov 1998 12:29:09 -0500 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00369 for ; Sat, 21 Nov 1998 17:35:13 -0500 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 PAA04673 for ; Sat, 21 Nov 1998 15:08:16 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA01853; Sat, 21 Nov 1998 13:46:48 -0600 (CST) To: lynx-dev@sig.net References: <199811211643.LAA21604@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Sat, 21 Nov 1998 22:46:54 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.5 - DJGPP fails 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: 278 Lines: 7 > 1998-11-21 (2.8.2dev.5) > * add configure test for stdarg.h vs varargs.h - TD > * modify HTSprintf/HTSprintf0 to use a more generic approach to varargs by > using only va_alist in the parameter list - TD DJGPP build fails because of parse error in included HTUtils.h:335 From owner-lynx-dev@sig.net Sat Nov 21 12:29:18 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01293 for ; Sat, 21 Nov 1998 12:29:17 -0500 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00389 for ; Sat, 21 Nov 1998 17:35:20 -0500 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 OAA04100 for ; Sat, 21 Nov 1998 14:51:39 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA29564; Sat, 21 Nov 1998 13:26:23 -0600 (CST) Date: Sat, 21 Nov 1998 14:28:13 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811211428.AA1199@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems In-Reply-To: <199811211849.NAA09518@shell.clark.net> of Sat, 21 Nov 1998 13:49:07 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1070 Lines: 24 From: dickey@clark.net > to be the varargs/stdarg difference. More along the lines of 'I did this, > and then that'. Before I made my change, I typed: $ lynx http://huizen.dds.nl/%7Equintess/pub/tkinspect_itcl.patch.tar.gz and got back s D)ownload, or C)ancel The problem is that in the code where I eventually patched, the pointer is allocated, but points to a \0 . Thus, HTSprintf calls the V*printf function with dst_len == 0. This causes the % parsing loop never to be entered, resulting in the %s not getting changed into the appropriate mime info (or that s appearing in the POSTs, etc.). I changed the loop so that it runs while the allocated lenght is not 0. However, this test now thinking about it should never be true, so should just be deleted from the while loop altogether I believe. -- 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 Nov 21 12:29:42 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01339 for ; Sat, 21 Nov 1998 12:29:42 -0500 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00423 for ; Sat, 21 Nov 1998 17:35:44 -0500 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 OAA03737 for ; Sat, 21 Nov 1998 14:28:52 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA27459; Sat, 21 Nov 1998 13:07:27 -0600 (CST) From: dickey@clark.net Message-Id: <199811211909.OAA12176@shell.clark.net> Subject: Re: lynx-dev Proposed fix for lynx To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 14:09:44 -0500 (EST) In-Reply-To: <9811211247.AA495@cas.org> from "lvirden@cas.org" at Nov 21, 98 12:47:19 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: 913 Lines: 22 > Tom or someone else familar with the HTString.c module, do you have time > to look at this change? After making it, it _seems_ like I am getting > better behavior both for the download msgs AND for mail.yahoo.com It looks like you're right: the test for dst_len was part of a fragment that I abandoned - but didn't completely remove. It breaks the calls for telnet and image-map (which I didn't exercise yesterday). > --- HTString.c-dist Sat Nov 21 12:46:03 1998 > +++ HTString.c Sat Nov 21 12:42:09 1998 > @@ -414,3 +414,4 @@ > fmt_ptr[f++] = *fmt; > - while (*++fmt != '\0' && dst_len != 0 && !done) { > + /* while (*++fmt != '\0' && dst_len != 0 && !done) { */ > + while (*++fmt != '\0' && have != 0 && !done) { > fmt_ptr[f++] = *fmt; > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 12:29:56 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA01370 for ; Sat, 21 Nov 1998 12:29:56 -0500 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00431 for ; Sat, 21 Nov 1998 17:35:56 -0500 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 OAA03603 for ; Sat, 21 Nov 1998 14:17:24 -0500 (EST) Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA25289; Sat, 21 Nov 1998 12:49:14 -0600 (CST) From: dickey@clark.net Message-Id: <199811211851.NAA10083@shell.clark.net> Subject: Re: lynx-dev Proposed fix for lynx To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 13:51:36 -0500 (EST) In-Reply-To: <9811211247.AA495@cas.org> from "lvirden@cas.org" at Nov 21, 98 12:47:19 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: 770 Lines: 21 > Tom or someone else familar with the HTString.c module, do you have time > to look at this change? After making it, it _seems_ like I am getting > better behavior both for the download msgs AND for mail.yahoo.com > > > --- HTString.c-dist Sat Nov 21 12:46:03 1998 > +++ HTString.c Sat Nov 21 12:42:09 1998 > @@ -414,3 +414,4 @@ > fmt_ptr[f++] = *fmt; > - while (*++fmt != '\0' && dst_len != 0 && !done) { > + /* while (*++fmt != '\0' && dst_len != 0 && !done) { */ > + while (*++fmt != '\0' && have != 0 && !done) { > fmt_ptr[f++] = *fmt; that could be it (I'll have to think about it - thanks) > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 12:57:09 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA03093 for ; Sat, 21 Nov 1998 12:57:08 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA00727 for ; Sat, 21 Nov 1998 18:03:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA21366; Sat, 21 Nov 1998 16:40:33 -0600 (CST) Date: Sat, 21 Nov 1998 14:42:49 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: lynx-dev Patch for DJGPP port 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: 958 Lines: 30 The following patch allows use of the debugging code built into the WATTCP code which is included in the DJGPP port of lynx. This is activated by placing lines in the WATTCP.CFG file for: DEBUG.MODE= (choices are HEADERS, DUMP, or ALL) DEBUG.PROTO= (choices are TCP, UDP, or ALL) DEBUG.FILE= (name of log file. Defaults to WATTCP.DBG) This adds about 2K to the size of the stripped, compressed executable. You get a log of the headers and/or a binary dump of the packets sent and received. Maybe this will help in determining where ftp is failing in this port. Doug *** lynx2-8-2/src/LYMain.c Wed Nov 18 11:23:56 1998 --- lynx2-8-2/src/LYMain.c.new Thu Nov 19 23:54:34 1998 *************** *** 615,620 **** --- 615,621 ---- init_ctrl_break[0] = 1; } atexit(reset_break); + dbug_init(); sock_init(); #endif __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Nov 21 13:32:35 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA05042 for ; Sat, 21 Nov 1998 13:32:35 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA00879 for ; Sat, 21 Nov 1998 18:38:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA25630; Sat, 21 Nov 1998 17:17:46 -0600 (CST) Date: Sun, 22 Nov 1998 08:21:35 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811212321.IAA13774@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 195 Lines: 5 > > Actually, I am using Sun's ANSI C compiler. This is quite important to keep in mind. The compile on Solaris2.6 is "FULLY AUTOMATIC" for me; the difference is that I use gcc2.7.2.3. __Henry From owner-lynx-dev@sig.net Sat Nov 21 14:32:02 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08280 for ; Sat, 21 Nov 1998 14:32:02 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01017 for ; Sat, 21 Nov 1998 19:37:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA01271; Sat, 21 Nov 1998 18:11:31 -0600 (CST) From: dickey@clark.net Message-Id: <199811220013.TAA01864@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 19:13:53 -0500 (EST) In-Reply-To: <9811211428.AA1199@cas.org> from "lvirden@cas.org" at Nov 21, 98 02:28:13 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: 982 Lines: 21 > I changed the loop so that it runs while the allocated lenght is not 0. > However, this test now thinking about it should never be true, so should > just be deleted from the while loop altogether I believe. I understood that (from your suggested patch). When I reread the code, there seems to be no reason to disagree with it. I was rewriting a module that I'd written for ncurses which simply returns a buffer size without formatting - not efficient - into the present form which allocates and formats as it goes. I'll put that change out as dev.6 (in the meantime I was testing some changes for lynx & ncurses on OS/2 which someone sent me, with the implication that I should see some more bugs to fix - not the case yet). Since this bug is an irritant (and no one's got any other critical bugs), there's no reason to hold up the fix. > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:36:25 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08304 for ; Sat, 21 Nov 1998 14:36:25 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01027 for ; Sat, 21 Nov 1998 19:42:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA01628; Sat, 21 Nov 1998 18:14:52 -0600 (CST) From: dickey@clark.net Message-Id: <199811220017.TAA02418@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.5 - DJGPP fails To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 19:17:13 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 21, 98 10:46: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: 653 Lines: 22 > > > 1998-11-21 (2.8.2dev.5) > > * add configure test for stdarg.h vs varargs.h - TD > > * modify HTSprintf/HTSprintf0 to use a more generic approach to varargs by > > using only va_alist in the parameter list - TD > > DJGPP build fails because of parse error in included HTUtils.h:335 that's non-autoconf. I think the #define's on lines 35 & 36 should define a value '1', e.g., #if defined(__STDC__) || defined(VMS) #define ANSI_VARARGS 1 #define HAVE_STDARGS_H 1 #endif (the undefined case is supposed to be implicitly a zero, but the defined case isn't symmetric). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:36:31 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08309 for ; Sat, 21 Nov 1998 14:36:30 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01031 for ; Sat, 21 Nov 1998 19:42:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA01761; Sat, 21 Nov 1998 18:15:46 -0600 (CST) From: dickey@clark.net Message-Id: <199811220018.TAA02484@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.5 (tiny changes nit) To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 19:18:07 -0500 (EST) In-Reply-To: <19981121133403.B24763@psnw.com> from "brian j. pardy" " at Nov 21, 98 01:34:03 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: 496 Lines: 17 > > dickey@clark.net wrote: > > 1998-11-21 (2.8.2dev.5) > > * modify HTLoadFile() to make compressed files work with OS/2 EMX and > > LYSystem() to convert forward slashes in pathnames to backslashes, also for > > EMX (patches by Ilya Zakharevich). > > * documentation nits (aprostrophes) in lynx.cfg and userdefs.h - LV > ^^^^^^^^^^^^ > apostrophes thanx (sic) (ispell is my friend ;-) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:40:24 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA08822 for ; Sat, 21 Nov 1998 14:40:24 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01044 for ; Sat, 21 Nov 1998 19:46:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA02977; Sat, 21 Nov 1998 18:26:47 -0600 (CST) From: dickey@clark.net Message-Id: <199811220029.TAA04229@shell.clark.net> Subject: Re: lynx-dev lynx 2.8.2dev.4 vs my.yahoo.comrqr To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 19:29:09 -0500 (EST) In-Reply-To: <199811212321.IAA13774@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 22, 98 08:21:35 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: 1197 Lines: 31 > > > > Actually, I am using Sun's ANSI C compiler. > > This is quite important to keep in mind. The compile on Solaris2.6 > is "FULLY AUTOMATIC" for me; the difference is that I use gcc2.7.2.3. when I'm doing integration, that's gcc 2.7.2.3 on Linux. Then if there's portability aspects, I do a test on OS/2 or FreeBSD (depending) still. When I'm ready to check code in, I run a series of compiles on sol (still gcc), using curses, ncurses and slang. I've a guest account on a Digital Unix box, courtesy of one of the people on the list (DEC cc) which I've been getting to about once a month. But when I have a few minutes at work, I run a series on SunOS (cc, gcc 2.8.1), Solaris (cc, gcc 2.8.1), IRIX (cc, gcc 2.8) and CLIX (cc, gcc 2.5.8). I'm usually as busy at work as I am at home - so it's not something that I do every day. (The AIX, HPUX and SCO machines that I used last year are no longer available). All of those builds are pretty automatic. Speaking of SCO, I tried taking Bela's advice and was recently persuading my wife to try the free-SCO. (It didn't boot during the install). > > __Henry -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:47:04 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA09011 for ; Sat, 21 Nov 1998 14:47:03 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA01062 for ; Sat, 21 Nov 1998 19:53:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA03853; Sat, 21 Nov 1998 18:35:37 -0600 (CST) From: dickey@clark.net Message-Id: <199811220038.TAA05998@shell.clark.net> Subject: Re: lynx-dev Patch for DJGPP port To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 19:38:00 -0500 (EST) In-Reply-To: from "Doug Kaufman " at Nov 21, 98 02:42: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: 1320 Lines: 41 > > The following patch allows use of the debugging code built into the > WATTCP code which is included in the DJGPP port of lynx. This is > activated by placing lines in the WATTCP.CFG file for: > DEBUG.MODE= (choices are HEADERS, DUMP, or ALL) > DEBUG.PROTO= (choices are TCP, UDP, or ALL) > DEBUG.FILE= (name of log file. Defaults to WATTCP.DBG) > > This adds about 2K to the size of the stripped, compressed executable. > You get a log of the headers and/or a binary dump of the packets sent > and received. Maybe this will help in determining where ftp is failing > in this port. I seem to be missing part of the story: is this a patch that you want to add to the development version, or a response to someone who is having trouble porting? (If the former, it needs ifdef's) > Doug > > *** lynx2-8-2/src/LYMain.c Wed Nov 18 11:23:56 1998 > --- lynx2-8-2/src/LYMain.c.new Thu Nov 19 23:54:34 1998 > *************** > *** 615,620 **** > --- 615,621 ---- > init_ctrl_break[0] = 1; > } > atexit(reset_break); > + dbug_init(); > sock_init(); > #endif > > > __ > Doug Kaufman > Internet: dkaufman@rahul.net (preferred) > bn900@cleveland.freenet.edu -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 14:56:24 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA09403 for ; Sat, 21 Nov 1998 14:56:24 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01091 for ; Sat, 21 Nov 1998 20:02:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA04916; Sat, 21 Nov 1998 18:44:20 -0600 (CST) Date: Sat, 21 Nov 1998 16:46:42 -0800 (PST) From: David Combs Message-Id: <199811220046.QAA18799@netcom13.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 841 Lines: 21 > From owner-lynx-dev@sig.net Sat Nov 21 09:36:23 1998 > Date: Sat, 21 Nov 1998 12:34:59 -0500 (EST) > From: lvirden@cas.org (Larry W. Virden) > > I just built the latest changes in dev.5 and still see the HTSprintf bug . > > Platform: SPARC Solaris 2.6 Sun compiler -Xc flag. I can send along > the config flags, the output from configure and the make and I can > run tests for someone. > > Oh, and the ncurses problem of redisplaying pages on initial startup of > lynx is still there as well. I've not tried to see if the problem with > highlighted strings with periods is still there or not. > -- > Larry W. Virden Maybe you can test via gcc too? Lots of us refuse to pay sun $$$ for their compiler (I don't even use c -- 99% of my stuff is in a language called "mainsail"). thanks! From owner-lynx-dev@sig.net Sat Nov 21 14:59:34 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA09628 for ; Sat, 21 Nov 1998 14:59:34 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01101 for ; Sat, 21 Nov 1998 20:05:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA05324; Sat, 21 Nov 1998 18:47:49 -0600 (CST) Message-ID: <19981121165001.A488@psnw.com> Date: Sat, 21 Nov 1998 16:50:01 -0800 From: "brian j . pardy" To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.5 (tiny changes nit) Mail-Followup-To: lynx-dev@sig.net References: <19981121133403.B24763@psnw.com> <199811220018.TAA02484@shell.clark.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811220018.TAA02484@shell.clark.net>; from "dickey@clark.net" on Sat, Nov 21, 1998 at 07:18:07PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 4:48pm up 4 days, 21 min, 5 users, load average: 1.77, 1.30, 1.13 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 614 Lines: 19 dickey@clark.net wrote: > > > > dickey@clark.net wrote: > > > 1998-11-21 (2.8.2dev.5) > > > * modify HTLoadFile() to make compressed files work with OS/2 EMX and > > > LYSystem() to convert forward slashes in pathnames to backslashes, also for > > > EMX (patches by Ilya Zakharevich). > > > * documentation nits (aprostrophes) in lynx.cfg and userdefs.h - LV > > ^^^^^^^^^^^^ > > apostrophes > > thanx (sic) > > (ispell is my friend ;-) I had to use ispell to make sure *I* had it correct. :) -- According to the obituary notices, a mean and unimportant person never dies. From owner-lynx-dev@sig.net Sat Nov 21 15:03:47 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA09934 for ; Sat, 21 Nov 1998 15:03:47 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01119 for ; Sat, 21 Nov 1998 20:09:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA05729; Sat, 21 Nov 1998 18:51:39 -0600 (CST) Date: Sat, 21 Nov 1998 16:54:01 -0800 (PST) From: David Combs Message-Id: <199811220054.QAA19163@netcom13.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1149 Lines: 30 > From owner-lynx-dev@sig.net Sat Nov 21 10:50:27 1998 > From: dickey@clark.net > Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems > > > I just built the latest changes in dev.5 and still see the HTSprintf bug . > > hmm. I'll need more information - I ran the SunOS version for about an > hour yesterday and saw no problem (nor did Purify). So it's not likely > to be the varargs/stdarg difference. More along the lines of 'I did this, > and then that'. > > > Platform: SPARC Solaris 2.6 Sun compiler -Xc flag. I can send along > > the config flags, the output from configure and the make and I can > > run tests for someone. > Re my just prior re-gcc request, I use 2.5.1 solaris, not 2.6. Larry, if you're up to it, maybe you control some systems that still have 2.5.1, you could also give a try on. I keep seeing on eg comp.unix.solaris and other places (emacs maybe) about problems on 2.6 that are not on 2.5.1. So maybe what you (Larry) do to make it work on 2.6 makes it NOT work on 2.5.1? (I really know nothing about this, but do see complaints about software, maybe just emacs, giving problems on 2.6?) David From owner-lynx-dev@sig.net Sat Nov 21 15:27:01 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA11041 for ; Sat, 21 Nov 1998 15:27:01 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01158 for ; Sat, 21 Nov 1998 20:33:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA07953; Sat, 21 Nov 1998 19:11:04 -0600 (CST) Date: Sat, 21 Nov 1998 17:13:21 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Patch for DJGPP port In-Reply-To: <199811220038.TAA05998@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: 1013 Lines: 29 On Sat, 21 Nov 1998 dickey@clark.net wrote: > I seem to be missing part of the story: is this a patch that you want > to add to the development version, or a response to someone who is having > trouble porting? (If the former, it needs ifdef's) This is already within an "ifdef __DJGPP__". It just doesn't show in the context diff. This is a patch that I would like to add to the development version. I don't see any reason to leave out the debugging code since it doesn't take much space. No debugging is done unless the debugging lines are put into WATTCP.CFG. Doug > > *** lynx2-8-2/src/LYMain.c Wed Nov 18 11:23:56 1998 > > --- lynx2-8-2/src/LYMain.c.new Thu Nov 19 23:54:34 1998 > > *************** > > *** 615,620 **** > > --- 615,621 ---- > > init_ctrl_break[0] = 1; > > } > > atexit(reset_break); > > + dbug_init(); > > sock_init(); > > #endif __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Nov 21 15:34:08 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA11569 for ; Sat, 21 Nov 1998 15:34:08 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01170 for ; Sat, 21 Nov 1998 20:40:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA09148; Sat, 21 Nov 1998 19:21:37 -0600 (CST) From: dickey@clark.net Message-Id: <199811220123.UAA11848@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.5 (tiny changes nit) To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 20:23:58 -0500 (EST) In-Reply-To: <19981121165001.A488@psnw.com> from "brian j . pardy" " at Nov 21, 98 04:50:01 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: 900 Lines: 29 > > dickey@clark.net wrote: > > > > > > dickey@clark.net wrote: > > > > 1998-11-21 (2.8.2dev.5) > > > > * modify HTLoadFile() to make compressed files work with OS/2 EMX and > > > > LYSystem() to convert forward slashes in pathnames to backslashes, also for > > > > EMX (patches by Ilya Zakharevich). > > > > * documentation nits (aprostrophes) in lynx.cfg and userdefs.h - LV > > > ^^^^^^^^^^^^ > > > apostrophes > > > > thanx (sic) > > > > (ispell is my friend ;-) > > I had to use ispell to make sure *I* had it correct. :) I know how to spell it - but my fingers have been a little clumsy recently. But when someone reports a spelling error, I run ispell on the whole file... > -- > According to the obituary notices, a mean and unimportant person never > dies. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sat Nov 21 15:37:27 1998 Received: from fox.flora.ottawa.on.ca (fox.flora.ottawa.on.ca [209.195.75.69]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA11831 for ; Sat, 21 Nov 1998 15:37:27 -0500 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by fox.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA01191 for ; Sat, 21 Nov 1998 20:43:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA09517; Sat, 21 Nov 1998 19:25:25 -0600 (CST) Date: Sat, 21 Nov 1998 20:27:16 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811212027.AA4606@cas.org> Subject: Re: lynx-dev lynx 2.8.2dev.5 still problems In-Reply-To: <199811220054.QAA19163@netcom13.netcom.com> of Sat, 21 Nov 1998 16:54:01 -0800 (PST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 611 Lines: 12 The changes in question are logic problems, not OS related. At least to do with the stuff we are discussing. The display problems I am seeing appears to be OS/library related, but is a nit compared to the serious bug that Thomas is generously fixing for us. Everyone working with a dev version of 2.8.2 should be sure to upgrade to version 6. -- 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 Nov 21 17:20:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA17276 for ; Sat, 21 Nov 1998 17:20:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA21025; Sat, 21 Nov 1998 21:04:49 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811220306.UAA06799@sanitas> Subject: Re: lynx-dev Proposed fix for lynx To: lynx-dev@sig.net Date: Sat, 21 Nov 1998 20:06:29 -0700 (MST) In-Reply-To: <9811211247.AA495@cas.org> from "Larry W. Virden" at Nov 21, 98 12:47:19 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: 351 Lines: 10 In a recent note, Larry W. Virden said: > Date: Sat, 21 Nov 1998 12:47:19 -0500 (EST) > > Tom or someone else familar with the HTString.c module, do you have time > to look at this change? After making it, it _seems_ like I am getting Applying this patch to dev.4 fixed the POST problem I had experienced on both Solaris 2.5 and OS/390 1.2 -- gil From owner-lynx-dev@sig.net Sun Nov 22 00:05:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA03442 for ; Sun, 22 Nov 1998 00:05:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA02158; Sat, 21 Nov 1998 22:34:45 -0600 (CST) From: dickey@clark.net Message-Id: <199811220437.XAA18851@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.6 To: lynx-dev@sig.net (Lynx Development) Date: Sat, 21 Nov 1998 23:37:07 -0500 (EST) 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: 832 Lines: 14 1998-11-21 (2.8.2dev.6) + add call on dbug_init to LYMain.c, allowing use of the debugging code built into the WATTCP code which is included in the DJGPP port of lynx. This is activated by placing lines in the WATTCP.CFG file for: DEBUG.MODE= (choices are HEADERS, DUMP, or ALL) DEBUG.PROTO= (choices are TCP, UDP, or ALL) DEBUG.FILE= (name of log file. Defaults to WATTCP.DBG) This adds about 2K to the size of the stripped, compressed executable. You get a log of the headers and/or a binary dump of the packets sent and received. Maybe this will help in determining where ftp is failing in this port - DK * correct definitions for ANSI_VARARGS, HAVE_STDARG_H in HTUtils.h (reported by LP, for djgpp) - TD * correct logic in StrAllocVsprintf(), remove spurious test on dst_len (analysis by LV) - TD From owner-lynx-dev@sig.net Sun Nov 22 06:03:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA22915 for ; Sun, 22 Nov 1998 06:03:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA00595; Sun, 22 Nov 1998 04:43:44 -0600 (CST) Date: Sun, 22 Nov 1998 05:45:36 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811220545.AA13194@cas.org> Subject: lynx-dev minor fix for lynx 2.8.2.dev6 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1044 Lines: 18 There's a little bug in the make distclean code. The - before commands only applys to the direct subshells that make executes. The -exec flag of the find is done by a sub-subshell. With the - in front of the rm, shell says that it can't find a command called "-rm". --- makefile.in Sat Nov 21 12:10:04 1998 +++ makefile.in-new Sun Nov 22 05:43:27 1998 @@ -228,4 +228,4 @@ -rm -f WWW/Library/unix/makefile src/makefile src/chrtrans/makefile - @SRCDIR_CLEAN@-find . -type f -name '*.rej' -exec -rm -f {} \; - @SRCDIR_CLEAN@-find . -type f -name '*.orig' -exec -rm -f {} \; + @SRCDIR_CLEAN@-find . -type f -name '*.rej' -exec rm -f {} \; + @SRCDIR_CLEAN@-find . -type f -name '*.orig' -exec rm -f {} \; @SRCDIR_CLEAN@-rmdir WWW/Library/unix && rmdir WWW/Library && rmdir WWW -- 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 Nov 22 06:16:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA23717 for ; Sun, 22 Nov 1998 06:16:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA01492; Sun, 22 Nov 1998 05:00:20 -0600 (CST) Date: Sun, 22 Nov 1998 06:02:12 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811220602.AA14605@cas.org> Subject: lynx-dev Another proposed patch To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1043 Lines: 20 This one is more serious - it is an attempt to fix a crash. However, I am uncertain of the ramifications of the particular strings I have chosen. The problem is that in certain cases, the address was null, so the fprintf was crashing. --- lynx2-8-2/src/LYShowInfo.c-dist Sun Nov 22 05:55:18 1998 +++ lynx2-8-2/src/LYShowInfo.c Sun Nov 22 05:58:47 1998 @@ -26,7 +26,7 @@ #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) +#define PutDefs(table, N) { int val=N; fprintf(fp0, "%-35s %s\n", (table[val].name ? table[val].name :"Not Found") , (table[val].value ? table[val].value : "None Available")); } /* * Compile-time definitions info, returns local url -- 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 Nov 22 06:45:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA25271 for ; Sun, 22 Nov 1998 06:45:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA02792; Sun, 22 Nov 1998 05:18:04 -0600 (CST) Date: Sun, 22 Nov 1998 06:19:56 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811220619.AA14975@cas.org> Subject: lynx-dev makefile enhancement submitted To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 536 Lines: 11 This enhancement gives one a single target to install a full lynx distribution. I know that not everyone wants this - that's why it's not the default target. 267a268,270 > > install-full: install install-help install-doc install-lss > @echo Full installation complete. -- 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 Nov 22 07:10:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA26585 for ; Sun, 22 Nov 1998 07:10:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05027; Sun, 22 Nov 1998 05:55:07 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811220907.LAA09368@ozone.fmi.fi> Subject: Re: lynx-dev Irix compile problem -- ENTER key In-Reply-To: <19981120161159.A15776@mail.bcpl.net> from Webmaster Jim at "Nov 20, 1998 04:11:59 pm" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 11:07:52 +0200 (EET) Cc: lynx-dev@sig.net, krss@comp.ncl.res.in X-Mailer: ELM [version 2.4ME+ PL50 (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: 916 Lines: 25 Webmaster Jim: > I haven't had access to that SGI system in over a year, so someone > else will need to help you. I'm forwarding your question to the list > (although I think you've tried that already). -- Start of included mail From: "K.R.Shamasundar" > Date: Fri, 20 Nov 1998 01:01:53 +0530 > To: jspath@mail.bcpl.lib.md.us > Subject: Lynx 2-8 > > Hi, > I got your address from lynx-binaries page at http://www.crl.com/ > You seem to have compiled lynx2-7 for sgi-irix m/c. I want to know if you > have tried lynx2-8-1 version. I tried and I am having some problem with > this. "ENTER/RETURN" key is not working at all. Can you suggest me > something to solve this? Is lynx taking account that ENTER/RETURN key (mvwgetch() / wgetch()) on certain $TERM values returns KEY_ENTER and not \n or \r ? That hit to me on certaing my programs. I do not know about lynx. / Kari Hurtta From owner-lynx-dev@sig.net Sun Nov 22 07:11:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA26591 for ; Sun, 22 Nov 1998 07:11:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04957; Sun, 22 Nov 1998 05:54:09 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811221047.MAA09539@ozone.fmi.fi> Subject: Re: lynx-dev Irix compile problem -- ENTER key In-Reply-To: <199811202306.SAA27763@shell.clark.net> from "dickey@clark.net" at "Nov 20, 1998 06:06:24 pm" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 12:47:05 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL50 (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: 3195 Lines: 67 dickey@clark.net: > I've tried responding to him on the mailing list a few times, but made > no impression. (I suspect he's got a mismatch between the terminal > and description, or the keypad "enter" vs the return "enter" is confusing). If $TERM = iris-ansi or $TERM = iris-ansi-net (these are results if user users IRIX's winterm) wgetch() gives KEY_ENTER instead of \n (or \r) when user press return "enter". Discription of terminfo is just little odd :-) Problem is that it matches :-) Therefore KEY_ENTER is returned. / Kari Hurtta PS. Compare kent= between iris-ansi and xterm descriptions. # Reconstructed via infocmp from file: /usr/share/lib/terminfo/i/iris-ansi iris-ansi|IRIS emulating 40 line ANSI terminal (almost VT100), am, cols#80, it#8, lines#40, bel=^G, bold=\E[1m, clear=\E[H\E[2J, cnorm=\E[9/y\E[12/y\E[=6l, cr=\r, cub=\E[%p1%dD, cub1=\E[D, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[10/y\E[=1h\E[=2l\E[=6h, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, home=\E[H, ht=\t, hts=\EH, il=\E[%p1%dL, il1=\E[L, ind=\ED, is2=\E[?1l\E>\E[?7h\E[100g\E[0m\E7\E[r\E8, kDC=\E[P, kEND=\E[147q, kHOM=\E[143q, kLFT=\E[158q, kPRT=\E[210q, kRIT=\E[167q, kSPD=\E[218q, kbs=\b, kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=^?, kend=\E[146q, kent=\r, kf1=\E[001q, kf10=\EOQ, kf11=\EOR, kf12=\EOS, kf2=\E[002q, kf3=\E[003q, kf4=\E[004q, kf5=\E[005q, kf6=\E[006q, kf7=\E[007q, kf8=\E[008q, kf9=\EOP, khome=\E[H, kich1=\E[139q, knp=\E[154q, kpp=\E[150q, kprt=\E[209q, krmir=\E[146q, kspd=\E[217q, nel=\EE, pfkey=\EP101;%p1%d.y%p2%s\E\\, rc=\E8, rev=\E[7m, ri=\EM, rmso=\E[m, rmul=\E[m, sc=\E7, sgr0=\E[m, smso=\E[1;7m, smul=\E[4m, tbc=\E[3g, # Reconstructed via infocmp from file: /usr/share/lib/terminfo/x/xterm xterm|vs100|xterm terminal emulator, am, km, mir, msgr, xenl, cols#80, it#8, lines#65, acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=@, bold=\E[1m, clear=\E[H\E[2J, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H, ht=\t, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=\n, ka1=\EOq, ka3=\EOs, kb2=\EOr, kbs=\b, kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy, kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O, rmkx=\E[?1l, rmso=\E[m, rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H, rs2=@kf1=\EOP, sc=\E7, sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;, sgr0=\E[m, smacs=^N, smkx=\E[?1h, smso=\E[7m, tbc=\E[3g, From owner-lynx-dev@sig.net Sun Nov 22 07:11:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA26596 for ; Sun, 22 Nov 1998 07:11:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05096; Sun, 22 Nov 1998 05:55:33 -0600 (CST) Date: Sat, 21 Nov 1998 23:14:02 -0500 From: William Park Message-Id: <199811220414.XAA00239@lewisham.clackson> 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-1/lynx2-8-1/lynx_help/lynx-dev.html X-Mailer: Lynx, Version 2.8.1rel.2 Subject: lynx-dev Better color settings Cc: parkw@better.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 525 Lines: 13 Hi, I upgraded from lynx-2.6 to lynx-2.8.1. I liked partial display of page while it is being downloaded. But, the default color scheme is a bit lame. When I do search (/), lynx moves forward to the location, but the searched pattern is not highlighted. When color is disabled (-color), the search works as expected. Can you point me to or send me another color settings with black background and various color highlights, similar to the way tin-1.4 handles highlights. Yours truly, William Park From owner-lynx-dev@sig.net Sun Nov 22 07:12:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA26605 for ; Sun, 22 Nov 1998 07:12:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA05061; Sun, 22 Nov 1998 05:55:19 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811220858.KAA09329@ozone.fmi.fi> Subject: Re: lynx-dev gettext() question #2 In-Reply-To: from Leonid Pauzner at "Nov 18, 1998 07:51:52 pm" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 10:58:45 +0200 (EET) Cc: lynx-dev@sig.net X-Mailer: ELM [version 2.4ME+ PL50 (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: 591 Lines: 21 Leonid Pauzner: > It was proposed just before the releasing 2.8, > concerning case-insensitive search, but nobody > have contributed the mapping table (we find another workaround). For case in-sensitive search: Lynx uses unicode for mapping characters between different charset, right ? Unicode gives also methods to do case insensitive seach. Pick files: ftp.unicode.org /Public/UNIDATA README.TXT UNIDATA2.TXT First file is required to be included that second file can be redistributed. For case insensitive search columns 12,13,14 gives needed information. / Kari Hurtta From owner-lynx-dev@sig.net Sun Nov 22 07:57:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA28947 for ; Sun, 22 Nov 1998 07:57:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07729; Sun, 22 Nov 1998 06:37:39 -0600 (CST) From: dickey@clark.net Message-Id: <199811221240.HAA14820@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 07:40:01 -0500 (EST) In-Reply-To: <9811220602.AA14605@cas.org> from "lvirden@cas.org" at Nov 22, 98 06:02:12 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: 1208 Lines: 28 > > This one is more serious - it is an attempt to fix a crash. However, I > am uncertain of the ramifications of the particular strings I have chosen. > The problem is that in certain cases, the address was null, so the fprintf > was crashing. I agree that it's a potential hole: but which configuration does this? Perhaps the problem is upstream, and we should not have a null pointer in the first place. I'd like to know - so we can see if this should be applied to the 2.8.1 bugfixes. > --- lynx2-8-2/src/LYShowInfo.c-dist Sun Nov 22 05:55:18 1998 > +++ lynx2-8-2/src/LYShowInfo.c Sun Nov 22 05:58:47 1998 > @@ -26,7 +26,7 @@ > #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) > +#define PutDefs(table, N) { int val=N; fprintf(fp0, "%-35s %s\n", (table[val].name ? table[val].name :"Not Found") , (table[val].value ? table[val].value : "None Available")); } > > /* > * Compile-time definitions info, returns local url > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 08:14:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA29812 for ; Sun, 22 Nov 1998 08:14:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA08243; Sun, 22 Nov 1998 06:44:34 -0600 (CST) From: dickey@clark.net Message-Id: <199811221246.HAA20215@shell.clark.net> Subject: Re: lynx-dev Better color settings To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 07:46:56 -0500 (EST) In-Reply-To: <199811220414.XAA00239@lewisham.clackson> from "William Park " at Nov 21, 98 11:14:02 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: 1051 Lines: 28 > Hi, > > I upgraded from lynx-2.6 to lynx-2.8.1. I liked partial display of > page while it is being downloaded. > > But, the default color scheme is a bit lame. When I do search (/), > lynx moves forward to the location, but the searched pattern is not > highlighted. When color is disabled (-color), the search works as > expected. Can you point me to or send me another color settings with > black background and various color highlights, similar to the way > tin-1.4 handles highlights. I get highlighting with the default color configuration. Perhaps you have not configured lynx against similar libraries to tin (tin can be built with termcap, which lets it specify to use "ANSI" colors when the terminal description does not - curses requires that the terminal description support color). There's some discussion on my ncurses faq: http://www.clark.net/pub/dickey/ncurses/ncurses.faq.html > Yours truly, > William Park > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 08:17:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA30039 for ; Sun, 22 Nov 1998 08:17:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA08012; Sun, 22 Nov 1998 06:41:10 -0600 (CST) From: dickey@clark.net Message-Id: <199811221243.HAA16992@shell.clark.net> Subject: Re: lynx-dev Irix compile problem -- ENTER key To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 07:43:32 -0500 (EST) In-Reply-To: <199811221047.MAA09539@ozone.fmi.fi> from "Kari E. Hurtta" " at Nov 22, 98 12:47:05 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: 3914 Lines: 85 > > dickey@clark.net: > > I've tried responding to him on the mailing list a few times, but made > > no impression. (I suspect he's got a mismatch between the terminal > > and description, or the keypad "enter" vs the return "enter" is confusing). > > If $TERM = iris-ansi or $TERM = iris-ansi-net (these are results if > user users IRIX's winterm) wgetch() gives KEY_ENTER instead of \n (or \r) > when user press return "enter". I have two "enter" keys on my keyboard. They will generate different codes. Are you talking about the one at the far right of the keyboard, in the numeric keypad, or the one in the middle section? Curses is supposed to return a KEY_ENTER if the string matches the 'kent' string - no matter what it is set to (in this case a '\r'). Likewise, there are special definitions for backspace and delete. > Discription of terminfo is just little odd :-) > Problem is that it matches :-) > Therefore KEY_ENTER is returned. then change your terminfo description. > / Kari Hurtta > > PS. Compare kent= between iris-ansi and xterm descriptions. > > > # Reconstructed via infocmp from file: /usr/share/lib/terminfo/i/iris-ansi > iris-ansi|IRIS emulating 40 line ANSI terminal (almost VT100), > am, > cols#80, it#8, lines#40, > bel=^G, bold=\E[1m, clear=\E[H\E[2J, > cnorm=\E[9/y\E[12/y\E[=6l, cr=\r, cub=\E[%p1%dD, > cub1=\E[D, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, > cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, > cuu1=\E[A, cvvis=\E[10/y\E[=1h\E[=2l\E[=6h, > dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, > home=\E[H, ht=\t, hts=\EH, il=\E[%p1%dL, il1=\E[L, > ind=\ED, is2=\E[?1l\E>\E[?7h\E[100g\E[0m\E7\E[r\E8, > kDC=\E[P, kEND=\E[147q, kHOM=\E[143q, kLFT=\E[158q, > kPRT=\E[210q, kRIT=\E[167q, kSPD=\E[218q, kbs=\b, > kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, > kcuu1=\E[A, kdch1=^?, kend=\E[146q, kent=\r, > kf1=\E[001q, kf10=\EOQ, kf11=\EOR, kf12=\EOS, > kf2=\E[002q, kf3=\E[003q, kf4=\E[004q, kf5=\E[005q, > kf6=\E[006q, kf7=\E[007q, kf8=\E[008q, kf9=\EOP, > khome=\E[H, kich1=\E[139q, knp=\E[154q, kpp=\E[150q, > kprt=\E[209q, krmir=\E[146q, kspd=\E[217q, nel=\EE, > pfkey=\EP101;%p1%d.y%p2%s\E\\, rc=\E8, rev=\E[7m, > ri=\EM, rmso=\E[m, rmul=\E[m, sc=\E7, sgr0=\E[m, > smso=\E[1;7m, smul=\E[4m, tbc=\E[3g, > > > # Reconstructed via infocmp from file: /usr/share/lib/terminfo/x/xterm > xterm|vs100|xterm terminal emulator, > am, km, mir, msgr, xenl, > cols#80, it#8, lines#65, > acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, > bel=^G, blink=@, bold=\E[1m, clear=\E[H\E[2J, cr=\r, > csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\b, > cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, > cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, > dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, > ed=\E[J, el=\E[K, el1=\E[1K$<3>, enacs=\E(B\E)0, > home=\E[H, ht=\t, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, > il=\E[%p1%dL, il1=\E[L, ind=\n, ka1=\EOq, ka3=\EOs, > kb2=\EOr, kbs=\b, kc1=\EOp, kc3=\EOn, kcub1=\EOD, > kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, > kf0=\EOy, kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, > kf4=\EOS, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl, > kf9=\EOw, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O, > rmkx=\E[?1l, rmso=\E[m, > rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H, > rs2=@kf1=\EOP, sc=\E7, > sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;, > sgr0=\E[m, smacs=^N, smkx=\E[?1h, smso=\E[7m, > tbc=\E[3g, > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 08:48:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA31654 for ; Sun, 22 Nov 1998 08:48:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA11032; Sun, 22 Nov 1998 07:22:43 -0600 (CST) Date: Sun, 22 Nov 1998 08:24:35 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811220824.AA17068@cas.org> Subject: Re: lynx-dev Another proposed patch In-Reply-To: <199811221240.HAA14820@shell.clark.net> of Sun, 22 Nov 1998 07:40:01 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 425 Lines: 12 The problem occurs here: Platform: UltraSPARC OS: Solaris 2.6 C: Sun C 4.2 I can send along config flags yet again if necessary Occured whenever I press '=' . -- 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 Nov 22 09:39:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA02064 for ; Sun, 22 Nov 1998 09:39:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA15805; Sun, 22 Nov 1998 08:19:56 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811221250.OAA09704@ozone.fmi.fi> Subject: Re: lynx-dev Request for help In-Reply-To: from "K.R.Shamasundar" at "Nov 19, 1998 08:34:54 pm" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 14:50:32 +0200 (EET) Cc: lynx-dev@sig.net X-Mailer: ELM [version 2.4ME+ PL50 (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: 738 Lines: 14 K.R.Shamasundar: > Hello, > I have got lynx2-8-1 and have tried to install it for sgi-irix-6.2 > machine. Compilation is successful. I have this problem that, when I press > "g" key, and type in "RETURN/ENTER" key, the value is not accepted. The > cursor remains as it is. And once I use "g" key, the only way to come back > is to use "CNTRL-G" key to cancel this request. That means that lynx is > not recognizing "RETURN" key; Can you please suggest me how to solve the > problem? Do I have to carryout some settings? > > I am thankful if you can direct this to a news-group in case you > choose not to reply to this mail. Is that occuring only when you use 'winterm' (ie. you have $TERM as iris-ansi or iris-ansi-net') ? From owner-lynx-dev@sig.net Sun Nov 22 11:02:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA07086 for ; Sun, 22 Nov 1998 11:02:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA22986; Sun, 22 Nov 1998 09:33:37 -0600 (CST) From: "Kari E. Hurtta" Message-Id: <199811221441.QAA09860@ozone.fmi.fi> Subject: Re: lynx-dev Irix compile problem -- ENTER key In-Reply-To: <199811221243.HAA16992@shell.clark.net> from "dickey@clark.net" at "Nov 22, 1998 07:43:32 am" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 16:41:11 +0200 (EET) Cc: lynx-dev@sig.net X-Mailer: ELM [version 2.4ME+ PL50 (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: 1503 Lines: 39 dickey@clark.net: > > > > dickey@clark.net: > > > I've tried responding to him on the mailing list a few times, but made > > > no impression. (I suspect he's got a mismatch between the terminal > > > and description, or the keypad "enter" vs the return "enter" is confusing). > > > > If $TERM = iris-ansi or $TERM = iris-ansi-net (these are results if > > user users IRIX's winterm) wgetch() gives KEY_ENTER instead of \n (or \r) > > when user press return "enter". > > I have two "enter" keys on my keyboard. They will generate different codes. > Are you talking about the one at the far right of the keyboard, in the numeric > keypad, or the one in the middle section? > > Curses is supposed to return a KEY_ENTER if the string matches the 'kent' > string - no matter what it is set to (in this case a '\r'). Likewise, > there are special definitions for backspace and delete. > > > Discription of terminfo is just little odd :-) > > Problem is that it matches :-) > > Therefore KEY_ENTER is returned. > > then change your terminfo description. You will get that complain every IRIX 6.2 user which uses winterm :-) Notice that I was not that person which was problems. I do not use winterm either. I'm afrain that you can not avoid these complain without be prepared to accept KEY_ENTER also. After all lynx installation can not change terminfo defination, so that is only solution to you. Or you can declare "That is know problem and will not be fixed." :-) / Kari Hurtta From owner-lynx-dev@sig.net Sun Nov 22 11:07:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA07356 for ; Sun, 22 Nov 1998 11:07:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA23405; Sun, 22 Nov 1998 09:37:38 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811221538.IAA07817@sanitas> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 08:38:41 -0700 (MST) In-Reply-To: <199811221240.HAA14820@shell.clark.net> from "dickey@clark.net" at Nov 22, 98 07:40:01 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: 1557 Lines: 42 In a recent note, dickey@clark.net said: > Date: Sun, 22 Nov 1998 07:40:01 -0500 (EST) > > > This one is more serious - it is an attempt to fix a crash. However, I > > am uncertain of the ramifications of the particular strings I have chosen. > > The problem is that in certain cases, the address was null, so the fprintf > > was crashing. > I reported this phenomenon and proposed a comparable patch in: Linkname: lynx-dev Safety Belt URL: http://www.flora.org/lynx-dev/html/month1198/msg00435.html * Subject: lynx-dev Safety Belt * From: pg@sweng.stortek.com * Date: Tue, 17 Nov 1998 15:32:55 -0700 (MST) A few weeks ago, I carelessly defined a null macro in config.hin. This percolated into lynx_cfg.h, thence into cfg_defs.h, where it had been transformed into a VOID member in a struct initializer. It took me several hours to track down the SIGSEGV every time I pressed "=". Today, I did it again, but it took me less than an hour to recall what had happened the last time. > I agree that it's a potential hole: but which configuration does this? Will "configure", operating properly, ever generate a null macro definition, such as: #define inline in a configuration that doesn't support "inline"? > Perhaps the problem is upstream, and we should not have a null pointer > in the first place. I'd like to know - so we can see if this should be > applied to the 2.8.1 bugfixes. > It might better be fixed upstream in cfg_defs.sh, but I hadn't the fortitude. -- gil From owner-lynx-dev@sig.net Sun Nov 22 11:34:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA08850 for ; Sun, 22 Nov 1998 11:34:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26416; Sun, 22 Nov 1998 10:04:28 -0600 (CST) From: stp@shell.flite.net Date: Sun, 22 Nov 1998 12:09:26 -0500 (EST) To: lynx-dev@sig.net Subject: lynx-dev Compiling lynx with cygnus 32. 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: 532 Lines: 12 Hi. I'm atempting to compile lynx with cygnus 32 for the win32 system. There wasn't a section in the installation guide for itso I'm in doubt about being able to compile it. The reason why I'm wanting to compile it is so that I can add ssl support. I have the patch for the ssl, but I'm not sure where to put it so that it can be included in the compilation. I've got ssl in patch format incase taht makes any difference. What will I also need? Will I just need the lynx sources and the ssl or is something else required? Thanks. From owner-lynx-dev@sig.net Sun Nov 22 12:47:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA13602 for ; Sun, 22 Nov 1998 12:47:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA03103; Sun, 22 Nov 1998 11:07:15 -0600 (CST) To: lynx-dev@sig.net References: <199811220858.KAA09329@ozone.fmi.fi> Message-Id: From: "Leonid Pauzner" Date: Sun, 22 Nov 1998 20:05:35 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev gettext() question #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: 1214 Lines: 34 22-Nov-98 10:58 Kari E. Hurtta wrote: > Leonid Pauzner: >> It was proposed just before the releasing 2.8, >> concerning case-insensitive search, but nobody >> have contributed the mapping table (we find another workaround). > For case in-sensitive search: > Lynx uses unicode for mapping characters between different charset, > right ? > Unicode gives also methods to do case insensitive seach. > Pick files: > ftp.unicode.org /Public/UNIDATA README.TXT > UNIDATA2.TXT Well, right, but UNIDATA2.TXT is 434K long and fast updating for all possible characters... And Lynx's task somehow special: to convert bytes from recognized codepages to unicode, so we already have src/chrtrans/*.tbl The question was to find upper/lower case mappings with minimal efforts and no problem for future maintainability. So we find an appropriate assumption and made a function TOUPPER8() in LYString.c Yes, we could compile a small index from UNIDATA2.TXT and use it instead. > First file is required to be included that second file can be redistributed. > For case insensitive search columns 12,13,14 gives needed information. > / Kari Hurtta From owner-lynx-dev@sig.net Sun Nov 22 14:04:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA18992 for ; Sun, 22 Nov 1998 14:04:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA13067; Sun, 22 Nov 1998 12:36:10 -0600 (CST) From: dickey@clark.net Message-Id: <199811221838.NAA02621@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 13:38:33 -0500 (EST) In-Reply-To: <9811220824.AA17068@cas.org> from "lvirden@cas.org" at Nov 22, 98 08:24:35 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: 697 Lines: 22 > > The problem occurs here: > > Platform: UltraSPARC > OS: Solaris 2.6 > C: Sun C 4.2 > I can send along config flags yet again if necessary ok (I don't have a current copy). What does the page look like when you have your fix applied? (I suspect there's a null pointer that we don't really want). > Occured whenever I press '=' . > -- > 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 Sun Nov 22 14:42:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA21946 for ; Sun, 22 Nov 1998 14:42:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA18470; Sun, 22 Nov 1998 13:23:53 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811221925.MAA11339@sanitas> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 12:25:45 -0700 (MST) In-Reply-To: <199811221838.NAA02621@shell.clark.net> from "dickey@clark.net" at Nov 22, 98 01:38: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: 1311 Lines: 40 In a recent note, dickey@clark.net said: > Date: Sun, 22 Nov 1998 13:38:33 -0500 (EST) > > ok (I don't have a current copy). What does the page look like when > you have your fix applied? (I suspect there's a null pointer that > we don't really want). > The problem occurs when configure causes something to be defined as nothing in lynx_cfg.h: /* #undef _ALL_SOURCE */ /* #undef const */ #define inline /* This is the culprit */ /* #undef mode_t */ /* #undef off_t */ cfg_defs.sh transforms this to: { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, { "inline" }, /* The culprit, again */ { "lstat", "stat" }, }; Which the compiler evidently interprets as: { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, { "inline", NULL }, /* The culprit, again */ { "lstat", "stat" }, }; and LYShowInfo gets a SIGSEGV on the NULL and the page never gets built. Larry's patch and mine both supply a default value instead of the NULL at execution time. It would generate a slightly smaller executable if this were done in cfg_defs.sh, but I was daunted by the sed script. -- gil From owner-lynx-dev@sig.net Sun Nov 22 14:57:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA22849 for ; Sun, 22 Nov 1998 14:57:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA19982; Sun, 22 Nov 1998 13:37:31 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811221939.MAA11476@sanitas> Subject: lynx-dev VARARGS and HTSprintf To: lynx-dev@sig.net (Lynx List) Date: Sun, 22 Nov 1998 12:39:23 -0700 (MST) 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: 2105 Lines: 47 I didn't pay enough attention to the varargs discussion in the last couple days. dev.6 breaks on OS/390 with: Library/Implementation/HTString.c ERROR CBC3343 ./../../../../WWW/Library/Implementation/HTString.c:549 Redeclaration of HTSprintf differs from previous declaration on line 57 of "../../../../WWW/Library/Implementation/HTString.h". ERROR CBC3343 ./../../../../WWW/Library/Implementation/HTString.c:580 Redeclaration of HTSprintf0 differs from previous declaration on line 59 of "../../../../WWW/Library/Implementation/HTString.h". FSUM3065 The COMPILE step ended with return code 12. I believe OS/390 is a pathological situation; ANSI_VARARGS is defined, but a compiler bug (fixed in Next Release, I hope) forces me to run with __STDC__ undefined. This sends me down a truly bizarre path. So, the attached patch may not be suitable for everyone; in fact, it may be suitable for no one but me. I merely offer that it circumvents the defect of OS/390, and seems to break nothing additional with gcc on Solaris 2.5. FWIW, gil ========================================================= diff -brc ./orig/lynxsrc/WWW/Library/Implementation/HTString.h ./lynxsrc/WWW/Library/Implementation/HTString.h *** ./orig/lynxsrc/WWW/Library/Implementation/HTString.h Sat Nov 21 09:32:10 1998 --- ./lynxsrc/WWW/Library/Implementation/HTString.h Sun Nov 22 11:35:31 1998 *************** *** 54,62 **** CONST char * delims, CONST char * bracks, char * found)); #if ANSI_VARARGS ! extern char * HTSprintf PARAMS((char ** pstr, CONST char * fmt, ...)) GCC_PRINTFLIKE(2,3); ! extern char * HTSprintf0 PARAMS((char ** pstr, CONST char * fmt, ...)) GCC_PRINTFLIKE(2,3); #else extern char * HTSprintf () GCC_PRINTFLIKE(2,3); --- 54,62 ---- CONST char * delims, CONST char * bracks, char * found)); #if ANSI_VARARGS ! extern char * HTSprintf (char ** pstr, CONST char * fmt, ...) GCC_PRINTFLIKE(2,3); ! extern char * HTSprintf0 (char ** pstr, CONST char * fmt, ...) GCC_PRINTFLIKE(2,3); #else extern char * HTSprintf () GCC_PRINTFLIKE(2,3); From owner-lynx-dev@sig.net Sun Nov 22 15:29:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA25326 for ; Sun, 22 Nov 1998 15:29:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA23962; Sun, 22 Nov 1998 14:11:59 -0600 (CST) From: dickey@clark.net Message-Id: <199811222014.PAA22812@shell.clark.net> Subject: Re: lynx-dev VARARGS and HTSprintf To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 15:14:23 -0500 (EST) In-Reply-To: <199811221939.MAA11476@sanitas> from "pg@sweng.stortek.com" at Nov 22, 98 12:39: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: 2501 Lines: 57 > I didn't pay enough attention to the varargs discussion in > the last couple days. dev.6 breaks on OS/390 with: > > Library/Implementation/HTString.c > ERROR CBC3343 ./../../../../WWW/Library/Implementation/HTString.c:549 > Redeclaration of HTSprintf differs from previous declaration > on line 57 of "../../../../WWW/Library/Implementation/HTString.h". > ERROR CBC3343 ./../../../../WWW/Library/Implementation/HTString.c:580 > Redeclaration of HTSprintf0 differs from previous declaration on > line 59 of "../../../../WWW/Library/Implementation/HTString.h". > FSUM3065 The COMPILE step ended with return code 12. > > I believe OS/390 is a pathological situation; ANSI_VARARGS is defined, > but a compiler bug (fixed in Next Release, I hope) forces me to run > with __STDC__ undefined. This sends me down a truly bizarre path. ok - your patch looks fine in this context, since the ANSI_VARARGS shouldn't be defined unless the prototype is legal syntax. (Larry may also hit this with the Solaris compiler). > So, the attached patch may not be suitable for everyone; in fact, > it may be suitable for no one but me. I merely offer that it > circumvents the defect of OS/390, and seems to break nothing > additional with gcc on Solaris 2.5. > > FWIW, > gil > ========================================================= > diff -brc ./orig/lynxsrc/WWW/Library/Implementation/HTString.h ./lynxsrc/WWW/Library/Implementation/HTString.h > *** ./orig/lynxsrc/WWW/Library/Implementation/HTString.h Sat Nov 21 09:32:10 1998 > --- ./lynxsrc/WWW/Library/Implementation/HTString.h Sun Nov 22 11:35:31 1998 > *************** > *** 54,62 **** > CONST char * delims, CONST char * bracks, char * found)); > > #if ANSI_VARARGS > ! extern char * HTSprintf PARAMS((char ** pstr, CONST char * fmt, ...)) > GCC_PRINTFLIKE(2,3); > ! extern char * HTSprintf0 PARAMS((char ** pstr, CONST char * fmt, ...)) > GCC_PRINTFLIKE(2,3); > #else > extern char * HTSprintf () GCC_PRINTFLIKE(2,3); > --- 54,62 ---- > CONST char * delims, CONST char * bracks, char * found)); > > #if ANSI_VARARGS > ! extern char * HTSprintf (char ** pstr, CONST char * fmt, ...) > GCC_PRINTFLIKE(2,3); > ! extern char * HTSprintf0 (char ** pstr, CONST char * fmt, ...) > GCC_PRINTFLIKE(2,3); > #else > extern char * HTSprintf () GCC_PRINTFLIKE(2,3); -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 15:31:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA25630 for ; Sun, 22 Nov 1998 15:31:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24360; Sun, 22 Nov 1998 14:15:53 -0600 (CST) From: dickey@clark.net Message-Id: <199811222018.PAA23326@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 15:18:17 -0500 (EST) In-Reply-To: <199811221925.MAA11339@sanitas> from "pg@sweng.stortek.com" at Nov 22, 98 12:25:45 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: 1918 Lines: 58 > In a recent note, dickey@clark.net said: > > > Date: Sun, 22 Nov 1998 13:38:33 -0500 (EST) > > > > ok (I don't have a current copy). What does the page look like when > > you have your fix applied? (I suspect there's a null pointer that > > we don't really want). > > > The problem occurs when configure causes something to be > defined as nothing in lynx_cfg.h: > > /* #undef _ALL_SOURCE */ > /* #undef const */ > #define inline /* This is the culprit */ > /* #undef mode_t */ > /* #undef off_t */ > > cfg_defs.sh transforms this to: so it's an error in my sed script (it may be simpler to patch the C code as Larry indicated ;-) The cases where I'm looking all have an empty string "", rather than the missing token. > { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, > { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, > { "inline" }, /* The culprit, again */ > { "lstat", "stat" }, > }; > > Which the compiler evidently interprets as: the compiler's right, of course. > { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, > { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, > { "inline", NULL }, /* The culprit, again */ > { "lstat", "stat" }, > }; > and LYShowInfo gets a SIGSEGV on the NULL and the page > never gets built. > > Larry's patch and mine both supply a default value instead of > the NULL at execution time. It would generate a slightly > smaller executable if this were done in cfg_defs.sh, but I > was daunted by the sed script. The sed script is about as complicated as it'll get - we're running into portability constraints. I'll look into fixing both - but for 2.8.1 fixes, the C code is a more stable place to fix it. > -- gil -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 15:37:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA25681 for ; Sun, 22 Nov 1998 15:37:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24841; Sun, 22 Nov 1998 14:20:23 -0600 (CST) From: dickey@clark.net Message-Id: <199811222022.PAA24014@shell.clark.net> Subject: Re: lynx-dev Irix compile problem -- ENTER key To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 15:22:47 -0500 (EST) In-Reply-To: <199811221441.QAA09860@ozone.fmi.fi> from "Kari E. Hurtta" " at Nov 22, 98 04:41:11 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: 598 Lines: 19 > I'm afrain that you can not avoid these complain without be > prepared to accept KEY_ENTER also. After all lynx installation > can not change terminfo defination, so that is only solution to you. > > Or you can declare "That is know problem and will not be fixed." well, it's an obvious defect in IRIX's terminfo description, for which there's an easy workaround. So I'll have to stick with the latter (it's the curses library which is deciding which string is KEY_ENTER, not Lynx). > :-) > > / Kari Hurtta > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 15:38:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA25921 for ; Sun, 22 Nov 1998 15:38:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24577; Sun, 22 Nov 1998 14:17:43 -0600 (CST) From: dickey@clark.net Message-Id: <199811222020.PAA23603@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 15:20:07 -0500 (EST) In-Reply-To: <199811221538.IAA07817@sanitas> from "pg@sweng.stortek.com" at Nov 22, 98 08:38:41 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: 1838 Lines: 51 > In a recent note, dickey@clark.net said: > > > Date: Sun, 22 Nov 1998 07:40:01 -0500 (EST) > > > > > This one is more serious - it is an attempt to fix a crash. However, I > > > am uncertain of the ramifications of the particular strings I have chosen. > > > The problem is that in certain cases, the address was null, so the fprintf > > > was crashing. > > > I reported this phenomenon and proposed a comparable patch in: I read this - but did not understand the problem you were reporting (sorry). > Linkname: lynx-dev Safety Belt > URL: http://www.flora.org/lynx-dev/html/month1198/msg00435.html > > * Subject: lynx-dev Safety Belt > * From: pg@sweng.stortek.com > * Date: Tue, 17 Nov 1998 15:32:55 -0700 (MST) > > A few weeks ago, I carelessly defined a null macro in > config.hin. This percolated into lynx_cfg.h, thence into > cfg_defs.h, where it had been transformed into a VOID member > in a struct initializer. It took me several hours to track > down the SIGSEGV every time I pressed "=". Today, I did it > again, but it took me less than an hour to recall what had > happened the last time. > > > I agree that it's a potential hole: but which configuration does this? > > Will "configure", operating properly, ever generate a null macro > definition, such as: > > #define inline > > in a configuration that doesn't support "inline"? > > > Perhaps the problem is upstream, and we should not have a null pointer > > in the first place. I'd like to know - so we can see if this should be > > applied to the 2.8.1 bugfixes. > > > It might better be fixed upstream in cfg_defs.sh, but I hadn't > the fortitude. > > -- gil > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 16:26:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA28969 for ; Sun, 22 Nov 1998 16:26:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA29750; Sun, 22 Nov 1998 15:03:37 -0600 (CST) Date: Sun, 22 Nov 1998 16:05:24 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811221605.AA19468@cas.org> Subject: Re: lynx-dev Another proposed patch In-Reply-To: <199811221838.NAA02621@shell.clark.net> of Sun, 22 Nov 1998 13:38:33 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2099 Lines: 67 From: dickey@clark.net > > > > The problem occurs here: > > > > Platform: UltraSPARC > > OS: Solaris 2.6 > > C: Sun C 4.2 > > I can send along config flags yet again if necessary > ok (I don't have a current copy). What does the page look like when export LIBS=" -L/ldatae/lib -R/ldatae/lib -lz -L/projects/gnu/sparc-sun-solaris2.6/lib -R/projects/gnu/sparc-sun-solaris2.6/lib -lncurses " export CPPFLAGS="-I/ldatae/include -I/projects/gnu/sparc-sun-solaris2.6/include" export CFLAGS="-g -Xc" export CC=cc $PWD/configure --prefix=/projects/intranet \ --libdir=/projects/intranet/lib/lynx \ --includedir=/projects/gnu/sparc-sun-solaris2.6/include \ --with-screen=ncurses \ --with-included-gettext \ --with-catgets \ --with-zlib \ --enable-default-colors \ --enable-extended-dtd \ --enable-externs \ --enable-forms-options \ --enable-nsl-fork \ --enable-partial \ --enable-persistent-cookies \ --enable-debug > you have your fix applied? (I suspect there's a null pointer that > we don't really want). > > > Occured whenever I press '=' . That's the peculiar thing - after the change, I don't see my code appear! Information about the current document Lynx 2.8.2dev.6 (21 Nov 1998) ([1]development version) - [2]compile time options File that you are currently viewing Linkname: Lynx experimental distribution directory URL: http://sol.slcc.edu/lynx/current/ Charset: iso-8859-1 (assumed) Server: Netscape-Enterprise/3.5.1 Date: Sun, 22 Nov 1998 21:06:33 GMT Last Mod: Sun, 22 Nov 1998 04:37:15 GMT Owner(s): mailto:lynx-dev@sig.net size: 133 lines mode: normal Link that you currently have selected Linkname: http://lynx.browser.org URL: http://lynx.browser.org/ -- 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 Nov 22 17:58:22 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA14060 for ; Sun, 22 Nov 1998 17:58:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA10202; Sun, 22 Nov 1998 16:31:23 -0600 (CST) Date: Sun, 22 Nov 1998 16:33:45 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 3356 Lines: 91 On Fri, 20 Nov 1998, Ryan Hung wrote: > On Fri, 20 Nov 1998, Klaus Weide wrote: > > The problem > > should be solved where it is generated, which is where the /~ is replaced > > by something else. > > Hmm, I see. But where would "//" in a real pathname be appropriate? A good question. I don't know the real answer, but "\\" in Windows (which probably would be translated into "//") has a specific meaning, and I seem to recall that POSIX or some similar spec for Unix says something like "a // at the beginning may have system-defined meaning". (Can anyone confirm?) Maybe it is only at the beginning of a pathname that "//" should be preserved, but a function like LYTrimRelFromAbsPath() may get called in many places and doesn't generally know if the string is a full path. So the safest thing may be to leave it alone once a "//" somehow got into a path. That is what lynx does, for the most part. If a user enters a path like that, he gets what he deserves (or maybe has a good reason). A complication is that URL paths and (at least Unux) filesystem paths act differently w.r.t. "". For files, a ".." steps back over multiple slashes, but if I read the URL syntax correctly a ".." should step "in between" the two slashes, there is a path segment between them that just happens to be empty. THe HTSimplify() function in Lynx refuses to step back over "//" segments anyway, probably because it things that may be the "//" occurring before the host in a URL. [ ... ] (I see the same things described by Ryan with 2.8.1rel2.) > Hmm. To clarify, what I'm getting with 2.8.2.dev.4 is that retrieving > "file://localhost/~" or "file://localhost/~/" gets the correct home > directory. Well what you are getting is actually the //home/username. It just happens that your OS regards that as the same as /home/username. > However, the directory is listed as "/username" rather than > "/home/username". An earlier version (around 2.7.1ac-0.91) shows this as Current directory is //home/username as expected, even if I explicitly give "file://localhost//home/username". (I have to give it explicitly because that version does not insert an extra slash when expanding ~). > When one does an "=" to look at the links there, the > full path of the current page is listed as "//home/username". Earlier version shows Name: //home/lynxdev URL: file://localhost//home/lynxdev as expected. So it seems there also has been a change in HTFile.c. ----- This change (untested) should prevent generation of the duplicate slash from /~ in file URL, but doesn't do anything about the other problems. When /~ appears in something in "file syntax", i.e. a file without "file:", it is normally handled in LYConvertToURL() in LYUtils.c which doesn't introduce a double slash. Klaus --- lynx2-8-1-orig/src/LYGetFile.c Wed Oct 14 07:23:56 1998 +++ lynx2-8-1/src/LYGetFile.c Sun Nov 22 16:24:13 1998 @@ -605,8 +605,10 @@ *cp1 = '\0'; cp1 += 2; StrAllocCopy(temp, doc->address); - LYAddHtmlSep(&temp); - StrAllocCat(temp, wwwName(Home_Dir())); + StrAllocCopy(cp, wwwName(Home_Dir())); + if (!LYIsHtmlSep(cp)) + LYAddHtmlSep(&temp); + StrAllocCat(temp, cp); if ((cp2 = strchr(cp1, '/')) != NULL) { LYTrimRelFromAbsPath(cp2); StrAllocCat(temp, cp2); From owner-lynx-dev@sig.net Sun Nov 22 18:01:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA15448 for ; Sun, 22 Nov 1998 18:01:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA11371; Sun, 22 Nov 1998 16:40:58 -0600 (CST) Date: Sun, 22 Nov 1998 16:43:21 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Irix compile problem -- ENTER key In-Reply-To: <199811222022.PAA24014@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: 919 Lines: 33 On Sun, 22 Nov 1998 dickey@clark.net wrote: > well, it's an obvious defect in IRIX's terminfo description, for which > there's an easy workaround. So I'll have to stick with the latter (it's > the curses library which is deciding which string is KEY_ENTER, not Lynx). It is the terminfo description which comes with ncurses AFAIK. Is there anything wrong with this trivial addition to LYStrings.c, which probably should have been there anyway? Klaus *** ../lynx2-8-1-cs/src/LYStrings.c Tue Sep 22 06:05:12 1998 --- ../lynx2-8-1/src/LYStrings.c Sun Nov 22 09:56:53 1998 *************** *** 1060,1065 **** --- 1060,1070 ---- case KEY_C3: /* lower right of keypad */ c = PGDOWN; break; + #ifdef KEY_ENTER + case KEY_ENTER: /* Enter or send (unreliable) */ + c = '\n'; + break; + #endif /* KEY_ENTER */ #ifdef KEY_END case KEY_END: /* end key 001 */ c = END_KEY; From owner-lynx-dev@sig.net Sun Nov 22 18:26:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA18296 for ; Sun, 22 Nov 1998 18:26:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA13738; Sun, 22 Nov 1998 16:59:01 -0600 (CST) Date: Sun, 22 Nov 1998 17:01:20 -0600 (CST) From: Klaus Weide To: William Park cc: lynx-dev@sig.net Subject: Re: lynx-dev Better color settings In-Reply-To: <199811220414.XAA00239@lewisham.clackson> 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: 601 Lines: 20 On Sat, 21 Nov 1998, William Park wrote: > Hi, > > I upgraded from lynx-2.6 to lynx-2.8.1. I liked partial display of > page while it is being downloaded. > > But, the default color scheme is a bit lame. When I do search (/), > lynx moves forward to the location, but the searched pattern is not > highlighted. When color is disabled (-color), the search works as > expected. Which operating system, and what kind of terminal? Is thins in an xterm? Is Lynx compiled with slang, ncurses, curses? With --enable-color-style? Do you have uncommented COLOR settings in lynx.cfg? Klaus From owner-lynx-dev@sig.net Sun Nov 22 19:12:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA23667 for ; Sun, 22 Nov 1998 19:12:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20778; Sun, 22 Nov 1998 17:52:14 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811222354.QAA11938@sanitas> Subject: Re: lynx-dev Improper ~/ expansion in file:// To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 16:54:05 -0700 (MST) In-Reply-To: from "Klaus Weide" at Nov 22, 98 04:33:45 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: 2471 Lines: 71 In a recent note, Klaus Weide said: > Date: Sun, 22 Nov 1998 16:33:45 -0600 (CST) > > A good question. I don't know the real answer, but "\\" in Windows (which > probably would be translated into "//") has a specific meaning, and I seem > to recall that POSIX or some similar spec for Unix says something like > "a // at the beginning may have system-defined meaning". (Can anyone > confirm?) > (I don't have the document handy; this is from memory.) POSIX notes that there is a convention of accessing remote filesystems: /// POSIX tolerates this, but "strongly recommends" that developers of new systems not implement this convention. On the other side, POSIX recommends that application developers not build paths by grafting a branch onto a stem: $STEM'/'$BRANCH because if STEM is '/', this results in a path beginning with the treacherous two slashes. Instead, POSIX recommends: $STEM'//'$BRANCH If STEM is '/', this results in '///'$BRANCH, which begins with three slashes, and only exactly two leading slashes may introduce the remote filesystem construct. A colleague points out that this is likely the genesis of the URL syntax: '://''/'path > Maybe it is only at the beginning of a pathname that "//" should be Elsewhere, POSIX doesn't allow it to matter. > preserved, but a function like LYTrimRelFromAbsPath() may get called > in many places and doesn't generally know if the string is a full > path. So the safest thing may be to leave it alone once a "//" somehow > got into a path. That is what lynx does, for the most part. If a user > enters a path like that, he gets what he deserves (or maybe has a good > reason). > > A complication is that URL paths and (at least Unux) filesystem paths > act differently w.r.t. "". For files, a ".." steps back over multiple > slashes, but if I read the URL syntax correctly a ".." should step "in > between" the two slashes, there is a path segment between them that just Particularly, RFC 1808 details the semantic difference of ending a URL path with a '/', something that makes no difference in POSIX paths. Roughly, if the URL is given as: scheme://host/foo/bar/ and the relative URL is X, the current directory is taken to be the entire URL, and the constructed URL is: scheme://host/foo/bar/X whereas if the base URL had been simply scheme://host/foo/bar the constructed URL is: scheme://host/foo/X -- gil From owner-lynx-dev@sig.net Sun Nov 22 19:35:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA25378 for ; Sun, 22 Nov 1998 19:35:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA22788; Sun, 22 Nov 1998 18:06:29 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811230008.RAA11967@sanitas> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 17:08:21 -0700 (MST) In-Reply-To: <199811222018.PAA23326@shell.clark.net> from "dickey@clark.net" at Nov 22, 98 03:18:17 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: 718 Lines: 25 In a recent note, dickey@clark.net said: > Date: Sun, 22 Nov 1998 15:18:17 -0500 (EST) > > > > #define inline /* This is the culprit */ > > > > cfg_defs.sh transforms this to: > > > { "inline" }, /* The culprit, again */ > > The cases where I'm looking all have an empty string "", rather than the > missing token. > It's OK if cfg_defs.sh does this; configure itself mustn't, or you get constructs such as: static "" HTSprintf () > > I was daunted by the sed script. > > The sed script is about as complicated as it'll get - we're running into particularly since you incorporated my suggested dual-pathing for apostrophes/quotes. -- gil From owner-lynx-dev@sig.net Sun Nov 22 19:50:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA27502 for ; Sun, 22 Nov 1998 19:50:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA25499; Sun, 22 Nov 1998 18:26:30 -0600 (CST) Date: Sun, 22 Nov 1998 16:28:54 -0800 (PST) From: David Combs Message-Id: <199811230028.QAA10517@netcom3.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Another proposed patch Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 632 Lines: 24 > From owner-lynx-dev@sig.net Sun Nov 22 11:27:52 1998 > From: pg@sweng.stortek.com > Subject: Re: lynx-dev Another proposed patch > > In a recent note, dickey@clark.net said: > > > Larry's patch and mine both supply a default value instead of > the NULL at execution time. It would generate a slightly > smaller executable if this were done in cfg_defs.sh, but I > was daunted by the sed script. > > -- gil > Might it be time to (think of) switch to perl for such things? Is getting pretty widespread use, I gather. (Or would people be MORE daunted by perl than by sed?) Just something to consider sometime. David From owner-lynx-dev@sig.net Sun Nov 22 20:00:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA28887 for ; Sun, 22 Nov 1998 20:00:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA27530; Sun, 22 Nov 1998 18:42:30 -0600 (CST) Date: Sun, 22 Nov 1998 16:44:54 -0800 (PST) From: David Combs Message-Id: <199811230044.QAA12905@netcom3.netcom.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in file:// Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1488 Lines: 39 > From owner-lynx-dev@sig.net Sun Nov 22 14:35:06 1998 > Date: Sun, 22 Nov 1998 16:33:45 -0600 (CST) > From: Klaus Weide > To: lynx-dev@sig.net > Subject: Re: lynx-dev Improper ~/ expansion in file:// > In-Reply-To: > 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 > > On Fri, 20 Nov 1998, Ryan Hung wrote: > > > On Fri, 20 Nov 1998, Klaus Weide wrote: > > > The problem > > > should be solved where it is generated, which is where the /~ is replaced > > > by something else. > > > > Hmm, I see. But where would "//" in a real pathname be appropriate? > > A good question. I don't know the real answer, but "\\" in Windows (which > probably would be translated into "//") has a specific meaning, and I seem > to recall that POSIX or some similar spec for Unix says something like > "a // at the beginning may have system-defined meaning". (Can anyone > confirm?) > I don't know what relevance this might or mignt not have, but what emacs does when it sees // when you enter a file-name is to throw away anything to its left. At least that's what it does for me, when it has a default in its prompt, and I just enter (actually, append) "//home/dkc/...", ie it lets the slash just before "home" mean "root". (obviously, you don't do that to http//:... but I bet emacs does, never tried it though) From owner-lynx-dev@sig.net Sun Nov 22 20:14:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA30344 for ; Sun, 22 Nov 1998 20:14:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA28925; Sun, 22 Nov 1998 18:53:38 -0600 (CST) Date: Mon, 23 Nov 1998 09:57:26 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811230057.JAA24790@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev can't configure "--disable-partial" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 504 Lines: 13 Some debugging code for the partial display moved out from inside the ifdef: ./GridText.c: In function `HText_pageDisplay': ./GridText.c:4093: `debug_display_partial' undeclared (first use this function) ,also line 4122. __Henry PS Tom, I continue to have to hand edit the toplevel makefile.in. The commented out "datadir = @datadir@" should work for anyone who can use configure in the first place. Your argument against putting that back simply doesn't hold on at least SunOS4.1.3 and Solaris2.6. From owner-lynx-dev@sig.net Sun Nov 22 20:52:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA03060 for ; Sun, 22 Nov 1998 20:52:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA04278; Sun, 22 Nov 1998 19:35:44 -0600 (CST) From: dickey@clark.net Message-Id: <199811230138.UAA08755@shell.clark.net> Subject: Re: lynx-dev Irix compile problem -- ENTER key To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 20:38:08 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 22, 98 04:43: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: 1366 Lines: 40 > On Sun, 22 Nov 1998 dickey@clark.net wrote: > > > well, it's an obvious defect in IRIX's terminfo description, for which > > there's an easy workaround. So I'll have to stick with the latter (it's > > the curses library which is deciding which string is KEY_ENTER, not Lynx). > > It is the terminfo description which comes with ncurses AFAIK. that particular one does - but in general IRIX's terminfo entries aren't wholly incorporated into ncurses (there's an interesting story - but outside the scope of this mailing list) > Is there anything wrong with this trivial addition to LYStrings.c, > which probably should have been there anyway? probably not - unless of course there was some place that Lynx should distinguish the two (none comes to mind). > Klaus > > *** ../lynx2-8-1-cs/src/LYStrings.c Tue Sep 22 06:05:12 1998 > --- ../lynx2-8-1/src/LYStrings.c Sun Nov 22 09:56:53 1998 > *************** > *** 1060,1065 **** > --- 1060,1070 ---- > case KEY_C3: /* lower right of keypad */ > c = PGDOWN; > break; > + #ifdef KEY_ENTER > + case KEY_ENTER: /* Enter or send (unreliable) */ > + c = '\n'; > + break; > + #endif /* KEY_ENTER */ > #ifdef KEY_END > case KEY_END: /* end key 001 */ > c = END_KEY; -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 21:04:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA04425 for ; Sun, 22 Nov 1998 21:04:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA05986; Sun, 22 Nov 1998 19:48:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811230150.UAA10390@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 20:50:31 -0500 (EST) In-Reply-To: <199811230028.QAA10517@netcom3.netcom.com> from "David Combs " at Nov 22, 98 04:28: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: 1427 Lines: 44 > > From owner-lynx-dev@sig.net Sun Nov 22 11:27:52 1998 > > From: pg@sweng.stortek.com > > Subject: Re: lynx-dev Another proposed patch > > > > In a recent note, dickey@clark.net said: > > > > > > Larry's patch and mine both supply a default value instead of > > the NULL at execution time. It would generate a slightly > > smaller executable if this were done in cfg_defs.sh, but I > > was daunted by the sed script. > > > > -- gil > > > > Might it be time to (think of) switch to perl for such things? no. I'd like to add no more requirements for building Lynx than we have already (adding perl would create more new problems than it would solve). > Is getting pretty widespread use, I gather. yes. > (Or would people be MORE daunted by perl than by sed?) I try to use the tool which is most suitable - sed is universally available on Unix platforms in a pretty standard form; there's a number of versions of perl which are incompatible to a larger extent than the subset of sed which I use for porting scripts. > Just something to consider sometime. sure - when perl is preinstalled on all Unix platforms. awk and sed are already there - the cfg_defs.sh script seems ok in sed, but I could fix the reported problem by moving to awk (if nothing worse turns up, there's no reason to change, however). > David -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 21:06:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA04503 for ; Sun, 22 Nov 1998 21:06:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA06401; Sun, 22 Nov 1998 19:51:04 -0600 (CST) From: dickey@clark.net Message-Id: <199811230153.UAA10812@shell.clark.net> Subject: Re: lynx-dev can't configure "--disable-partial" To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 20:53:29 -0500 (EST) In-Reply-To: <199811230057.JAA24790@ews07.nara.kindai.ac.jp> from "Nelson Henry Eric " at Nov 23, 98 09:57: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: 1025 Lines: 29 > > Some debugging code for the partial display moved out from > inside the ifdef: > > ./GridText.c: In function `HText_pageDisplay': > ./GridText.c:4093: `debug_display_partial' undeclared (first use this function) > > ,also line 4122. I caught this today and have it in my current patch. > __Henry > > PS Tom, I continue to have to hand edit the toplevel makefile.in. The > commented out "datadir = @datadir@" should work for anyone who can use > configure in the first place. Your argument against putting that back > simply doesn't hold on at least SunOS4.1.3 and Solaris2.6. at the moment, it's still a minor issue - I'd like to close out the serious bugs (lynx isn't the only program with those) and pick this up next week. The datadir assignment in the toplevel makefile doesn't do anything to the compiled-in path in src/makefile.in, which in turn is related to the paths in po. I can break it now, or fix it next week. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 21:09:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA04553 for ; Sun, 22 Nov 1998 21:09:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA06754; Sun, 22 Nov 1998 19:53:12 -0600 (CST) From: dickey@clark.net Message-Id: <199811230155.UAA11106@shell.clark.net> Subject: Re: lynx-dev Another proposed patch To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 20:55:36 -0500 (EST) In-Reply-To: <9811221605.AA19468@cas.org> from "lvirden@cas.org" at Nov 22, 98 04:05: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: 1020 Lines: 31 > That's the peculiar thing - after the change, I don't see my code appear! it's in the page generated for the [2] link. > Information about the current document > > Lynx 2.8.2dev.6 (21 Nov 1998) ([1]development version) - [2]compile time > options > > File that you are currently viewing > > Linkname: Lynx experimental distribution directory > URL: http://sol.slcc.edu/lynx/current/ > Charset: iso-8859-1 (assumed) > Server: Netscape-Enterprise/3.5.1 > Date: Sun, 22 Nov 1998 21:06:33 GMT > Last Mod: Sun, 22 Nov 1998 04:37:15 GMT > Owner(s): mailto:lynx-dev@sig.net > size: 133 lines > mode: normal > > Link that you currently have selected > > Linkname: http://lynx.browser.org > URL: http://lynx.browser.org/ > Larry W. Virden -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Sun Nov 22 22:02:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA09911 for ; Sun, 22 Nov 1998 22:02:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA14179; Sun, 22 Nov 1998 20:45:07 -0600 (CST) Date: Sun, 22 Nov 1998 21:47:00 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811222147.AA23195@cas.org> Subject: Re: lynx-dev Another proposed patch In-Reply-To: <199811230155.UAA11106@shell.clark.net> of Sun, 22 Nov 1998 20:55:36 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 11125 Lines: 266 From: dickey@clark.net >> That's the peculiar thing - after the change, I don't see my code appear! > >it's in the page generated for the [2] link. Configuration Definitions (Lynx Version 2.8.2dev.6) See also your[1] 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_cc -DCC_HAS_PROTOS ansi_varargs yes baddef_remove no bool_defs yes c_const yes c_inline no color_curses yes 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 yes func_getcwd yes func_getgroups yes func_gethostbyname yes func_gethostname yes func_getpagesize yes func_gzopen yes func_initscr yes func_keypad yes func_lstat yes func_mktime yes func_mmap_fixed_mapped yes func_munmap 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_use_default_colors yes func_vfork_works yes func_waitpid yes func_wborder yes have_errno yes have_lib_ncurses yes have_lib_z yes 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_dir_opendir no lib_gpm_Gpm_Open no lib_inet no lib_nsl_gethostbyname yes lib_socket_socket yes locale yes ncurses_broken no ncurses_header curses.h ncurses_version 4.2.981114 netlibs -lnsl -lsocket ngroups no path_CHMOD /projects/gnu/sparc-sun-solaris2.6/bin/chmo d path_COMPRESS /bin/compress path_COPY /projects/gnu/sparc-sun-solaris2.6/bin/cp path_GZIP /projects/gnu/sparc-sun-solaris2.6/bin/gzip path_MKDIR /projects/gnu/sparc-sun-solaris2.6/bin/mkdi r path_MV /projects/gnu/sparc-sun-solaris2.6/bin/mv path_RM /projects/gnu/sparc-sun-solaris2.6/bin/rm path_TAR /projects/gnu/sparc-sun-solaris2.6/bin/tar path_TOUCH /projects/gnu/sparc-sun-solaris2.6/bin/touc h path_UNCOMPRESS /projects/gnu/sparc-sun-solaris2.6/bin/gunz ip path_UNZIP /projects/sprs_lwv/sol2/bin/unzip path_UUDECODE /ldatae/bin/uudecode path_ZCAT /projects/gnu/sparc-sun-solaris2.6/bin/zcat path_ZIP /projects/sprs_lwv/sol2/bin/zip path_install /projects/gnu/sparc-sun-solaris2.6/bin/gins tall -c prog_CC cc prog_CPP cc -E prog_LINT lint prog_RANLIB ranlib prog_cc_cross no prog_cc_works yes prog_gcc no prog_make_make_set yes screen ncurses 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_libsocks no use_libsocks5 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 CHMOD_PATH /projects/gnu/sparc-sun-solaris2.6/bin/chmo d COLOR_CURSES 1 COMPRESS_PATH /bin/compress COPY_PATH /projects/gnu/sparc-sun-solaris2.6/bin/cp DECL_SYS_ERRLIST 1 DIRED_SUPPORT 1 DISP_PARTIAL 1 DONT_TRACK_INTERNAL_LINKS 1 EXP_PERSISTENT_COOKIES 1 FANCY_CURSES 1 GETGROUPS_T gid_t GZIP_PATH /projects/gnu/sparc-sun-solaris2.6/bin/gzip HAVE_ALLOCA 1 HAVE_ALLOCA_H 1 HAVE_CBREAK 1 HAVE_CUSERID 1 HAVE_DEFINE_KEY 1 HAVE_DIRENT_H 1 HAVE_FCNTL_H 1 HAVE_GETBKGD 1 HAVE_GETCWD 1 HAVE_GETGROUPS 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_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_USE_DEFAULT_COLORS 1 HAVE_UTMP 1 HAVE_VALUES_H 1 HAVE_VARARGS_H 1 HAVE_WAITPID 1 HAVE_WBORDER 1 INSTALL_PATH /projects/gnu/sparc-sun-solaris2.6/bin/gins tall -c LOCALE 1 LONG_LIST 1 LYNX_CFG_FILE /projects/intranet/lib/lynx/lynx.cfg LYNX_CFG_H 1 MKDIR_PATH /projects/gnu/sparc-sun-solaris2.6/bin/mkdi r MV_PATH /projects/gnu/sparc-sun-solaris2.6/bin/mv NCURSES 1 NGROUPS 16 NSL_FORK 1 OK_GZIP 1 OK_OVERRIDE 1 OK_PERMIT 1 OK_TAR 1 OK_UUDECODE 1 OK_ZIP 1 RM_PATH /projects/gnu/sparc-sun-solaris2.6/bin/rm STDC_HEADERS 1 SYSTEM_MAIL /usr/lib/sendmail SYSTEM_MAIL_FLAGS -t -oi TAR_PATH /projects/gnu/sparc-sun-solaris2.6/bin/tar TERMIO_AND_CURSES 1 TOUCH_PATH /projects/gnu/sparc-sun-solaris2.6/bin/touc h UNCOMPRESS_PATH /projects/gnu/sparc-sun-solaris2.6/bin/gunz ip UNIX 1 UNZIP_PATH /projects/sprs_lwv/sol2/bin/unzip USE_DEFAULT_COLORS 1 USE_EXTERNALS 1 USE_FCNTL 1 USE_ZLIB 1 UTMPX_FOR_UTMP 1 UUDECODE_PATH /ldatae/bin/uudecode ZCAT_PATH /projects/gnu/sparc-sun-solaris2.6/bin/zcat ZIP_PATH /projects/sprs_lwv/sol2/bin/zip inline None Available lstat stat References 1. file://localhost/ldatae/tmp/L23178-7TMP.html -- 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 Nov 23 03:22:36 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA31196 for ; Mon, 23 Nov 1998 03:22:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA21592; Mon, 23 Nov 1998 01:55:00 -0600 (CST) From: David Woolley Message-Id: <199811221745.RAA01909@djwhome.demon.co.uk> Subject: Re: lynx-dev Compiling lynx with cygnus 32. To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 17:45:10 +0000 (GMT) In-Reply-To: from "stp@shell.flite.net" at Nov 22, 98 12:09: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: 233 Lines: 4 > What will I also need? Will I just need the lynx sources and the ssl or is > something else required? You will at least need SSLeay and, if you are in a country where the RSA patent holds (primarily the USA), you will need RSAREF. From owner-lynx-dev@sig.net Mon Nov 23 03:59:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA00811 for ; Mon, 23 Nov 1998 03:59:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA24723; Mon, 23 Nov 1998 02:36:53 -0600 (CST) To: lynx-dev@sig.net References: <199811230153.UAA10812@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Mon, 23 Nov 1998 11:33:20 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev can't configure "--disable-partial" 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: 1422 Lines: 47 >> >> Some debugging code for the partial display moved out from >> inside the ifdef: >> >> ./GridText.c: In function `HText_pageDisplay': >> ./GridText.c:4093: `debug_display_partial' undeclared (first use this function) >> >> ,also line 4122. > I caught this today and have it in my current patch. also add from the same patch: diff -u old/lybookma.c ./lybookma.c --- old/lybookma.c Sat Nov 21 22:22:44 1998 +++ ./lybookma.c Sun Nov 22 22:14:50 1998 @@ -903,7 +903,7 @@ unicode = UCTransToUni(*p, current_char_set); if (unicode > 32 && unicode < 127) return(TRUE); - if (c <= 32 || (c >= 127 && c <= 160) || c == 0xad) + if (unicode <= 32 || unicode == 0xa0 || unicode == 0xad) continue; if (unicode >= 0x2000 && unicode < 0x200f) continue; @@ -955,7 +955,8 @@ char *ncr = NULL; char *buf = NULL; int charset_in = current_char_set; - int charset_out = -1; + int charset_out = UCGetLYhndl_byMIME("us-ascii"); + for ( ; *p; p++) { LYstrncpy(q, p, 1); @@ -966,9 +967,6 @@ int uck; long unicode; char replace_buf [10], replace_buf2 [10]; - - if (charset_out < 0) - charset_out = UCGetLYhndl_byMIME("us-ascii"); uck = UCTransCharStr(replace_buf, sizeof(replace_buf), *q, charset_in, charset_out, YES); Only in .: old From owner-lynx-dev@sig.net Mon Nov 23 05:42:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA06596 for ; Mon, 23 Nov 1998 05:42:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA02265; Mon, 23 Nov 1998 04:23:33 -0600 (CST) Date: Mon, 23 Nov 1998 02:25:40 -0800 (PST) From: Ryan Hung To: lynx-dev@sig.net Subject: Re: lynx-dev Improper ~/ expansion in 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: 1005 Lines: 21 On Sun, 22 Nov 1998, Klaus Weide wrote: > This change (untested) should prevent generation of the duplicate > slash from /~ in file URL, but doesn't do anything about the other > problems. > > When /~ appears in something in "file syntax", i.e. a file without > "file:", it is normally handled in LYConvertToURL() in LYUtils.c > which doesn't introduce a double slash. Hmm. Well, thanks for helping to sort this out, but the patch doesn't fix the file://localhost/~ expansion problem. The /~ is expanded correctly when you, say, load Lynx with the commandline "lynx /~", but you can't use this as a URL and hence it doesn't work for jumpfiles, which is what we are trying to do. Ryan. _/ \__/ \__/ \__/ \__/ \__/ \__/ \__/rhung@vcn.bc.ca__/ \__/ \__/ \_Apoptosis=programmed cell death/ \__/ \rwhung@interchange.ubc.ca_/ \__ _/ --you can't live without it!/ \__/ \http://www.vcn.bc.ca/people/rhung \__/ \__/ \__/ \__/ \__/ \__/ \__/ \My words Copyright (C) 1998 \__ From owner-lynx-dev@sig.net Mon Nov 23 06:40:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA09756 for ; Mon, 23 Nov 1998 06:40:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA06291; Mon, 23 Nov 1998 05:21:26 -0600 (CST) From: dickey@clark.net Message-Id: <199811231123.GAA25734@shell.clark.net> Subject: lynx-dev lynx2.8.2dev.7 To: lynx-dev@sig.net (Lynx Development) Date: Mon, 23 Nov 1998 06:23:46 -0500 (EST) 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: 1367 Lines: 21 1998-11-23 (2.8.2dev.7) * convert KEY_ENTER to newline in LYgetch() to make Lynx work with IRIX's iris-ansi terminfo description, which equates the kent capability with carriage return. Doing this will allow lynx to use the keypad "enter" key as an alias for carriage return on most terminals - KW * correct a few missing ifdef's for disabling the partial-display logic - TD * add/use new functions HTAA_UidToName(), HTAA_NameToUid(), HTAA_GidToName() and HTAA_NameToGid() to hide details of code which uses pwd.h and grp.h, as well as to cache the returned user/group names, improving performance in the dired screen - TD * modify HTCheckForInterrupt() to check for interrupt no more than one per second, since this check is comparatively slow - TD * modify ANSI_VARARGS case for HTSprintf() and HTSprintf0() to always use ANSI prototypes, since __STDC__ may not necessarily be defined on some systems, resulting in an inconsistent definition - PG * add install-full rule to makefile.in - LV * modify PutDefs macro in LYShowInfo.c to check for nonnull table[N].value, which may be null due to limitations of cfg_defs.sh script on some platforms where an empty string was intended (reported by LV, PG, applies to 2.8.1rel.2) - TD * correct typo in 'make distclean' rule; an extra '-' prevented removal of .orig and .rej files (patch by LV). From owner-lynx-dev@sig.net Mon Nov 23 07:19:04 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA11741 for ; Mon, 23 Nov 1998 07:19:03 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA08413; Mon, 23 Nov 1998 05:50:10 -0600 (CST) From: "Esa Pikkarainen" Organization: Oulun yliopisto/KTK To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 13:53:59 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: lynx-dev Authentication problem X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <40A0CF0142E@ktk.oulu.fi> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1182 Lines: 29 Hello! I'm new in this list. My problem now is that I am making certain services to our www-server which should be Lynx compatible. The exapmle service is a web based POP-mail reader. There is a CGI program that requires authentication from the browser (sends header: HTTP/1.0 401 Unauthorized). After that the service uses this information sent by browser to identify the user (uses them as POP userid and pwd). This works fine with Netsc and IE. They continue sending the authentication informatios as long as we stay in a same directory. But Lynx not. I sends this information to CGI-program, but when CGI program redirects it to an other document in the same directory it will not send it any more. The Lynx version is 2.7.2 If you want more information I will explain. Please give some advice, I need thsi Lynx connection! thank you Esa Pikkarainen Mr. Esa Pikkarainen (Linnanmaa, Snelmania, room: KTK338) Fac of Ed, Univ of Oulu Tel:358-8-5533691 Fax: -5533744 P.O. Box 222, SF-90571 Oulu E-mail: epikkara@ktk.oulu.fi Finland :-) WWW: http://wwwedu.oulu.fi/~/epikkara/ PS. Excuse me my bad English - I am not a native nor a daily user. From owner-lynx-dev@sig.net Mon Nov 23 12:17:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA00319 for ; Mon, 23 Nov 1998 12:17:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA03982; Mon, 23 Nov 1998 10:14:25 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Mon, 23 Nov 1998 11:16:19 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev Printing Options patch 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: 1501 Lines: 37 This patch makes lynx to correctly print, in the Printing Options page, "Print options:" and "Standard print options:" instead of "options: Print" and "options: Standard print". *** lynx2-8-2/src/LYPrint.c.ori Sat Nov 21 11:32:10 1998 --- lynx2-8-2/src/LYPrint.c Mon Nov 23 10:08:04 1998 *************** *** 1320,1327 **** if (no_print || no_disk_save || child_lynx || no_mail) fprintf(fp0, " %s\n", gettext("Some print functions have been disabled!")); ! fprintf(fp0, "\n%s %s\n", gettext("options:"), ! (user_mode == NOVICE_MODE) ? gettext("Standard print") : gettext("Print")); if (child_lynx == FALSE && no_disk_save == FALSE && no_print == FALSE) { fprintf(fp0, --- 1320,1329 ---- if (no_print || no_disk_save || child_lynx || no_mail) fprintf(fp0, " %s\n", gettext("Some print functions have been disabled!")); ! fprintf(fp0, "\n%s\n", ! (user_mode == NOVICE_MODE) ! ? gettext("Standard print options:") ! : gettext("Print options:")); if (child_lynx == FALSE && no_disk_save == FALSE && no_print == FALSE) { fprintf(fp0, 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 Nov 23 19:04:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA27955 for ; Mon, 23 Nov 1998 19:04:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20757; Mon, 23 Nov 1998 17:47:16 -0600 (CST) From: Ilya Zakharevich Message-Id: <199811230142.UAA16703@monk.mps.ohio-state.edu> Subject: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 20:42:06 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 703 Lines: 26 Lynx tolerates *some* whitespace in the config file, but doesn't tolerate some other. This is very confusing. Patch follows. Enjoy, Ilya --- ./src/LYReadCFG.c~ Tue Nov 10 14:47:38 1998 +++ ./src/LYReadCFG.c Sun Nov 22 20:35:34 1998 @@ -1077,6 +1077,10 @@ PUBLIC void read_cfg ARGS4( /* skip past colon, but replace ':' with 0 to make name meaningful */ *value++ = 0; + /* Allow spaces around ':' */ + LYTrimTrailing(name); + value = LYSkipBlanks(value); + /* * Trim off any trailing comments. * @@ -1090,6 +1094,7 @@ PUBLIC void read_cfg ARGS4( cp--; if (isspace ((unsigned char) *cp)) *cp = 0; + LYTrimTrailing(value); /* Trim again */ } tbl = Config_Table; From owner-lynx-dev@sig.net Mon Nov 23 19:04:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA27964 for ; Mon, 23 Nov 1998 19:04:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20392; Mon, 23 Nov 1998 17:45:46 -0600 (CST) Date: Mon, 23 Nov 1998 20:35:21 +0100 (MET) From: Gisle Vanem To: lynx-dev@sig.net Subject: lynx-dev HTaaprot fix 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: 1411 Lines: 76 HTaaprot.c doesn't compile if NOUSERS si defined (as with djgpp). Here is a fix: --------------------------------------------------------- --- htaaprot.org Mon Nov 23 19:14:40 1998 +++ htaaprot.c Mon Nov 23 20:30:12 1998 @@ -609,6 +609,7 @@ */ PUBLIC char * HTAA_UidToName ARGS1(int, uid) { +#ifndef NOUSERS struct passwd *pw; HTList *me = known_pwd; @@ -627,6 +628,7 @@ save_uid_info(pw->pw_name, pw->pw_uid); return pw->pw_name; } +#endif return ""; } @@ -640,6 +642,7 @@ */ PUBLIC int HTAA_NameToUid ARGS1(char *, name) { +#ifndef NOUSERS struct passwd *pw; HTList *me = known_pwd; @@ -657,6 +660,7 @@ save_uid_info(pw->pw_name, pw->pw_uid); return pw->pw_uid; } +#endif return NONESUCH; } @@ -670,6 +674,7 @@ */ PUBLIC char * HTAA_GidToName ARGS1(int, gid) { +#ifndef NOUSERS struct group *gr; HTList *me = known_grp; @@ -688,6 +693,7 @@ save_gid_info(gr->gr_name, gr->gr_gid); return gr->gr_name; } +#endif return ""; } @@ -701,6 +707,7 @@ */ PUBLIC int HTAA_NameToGid ARGS1(char *, name) { +#ifndef NOUSERS struct group *gr; HTList *me = known_grp; @@ -718,5 +725,6 @@ save_gid_info(gr->gr_name, gr->gr_gid); return gr->gr_gid; } +#endif return NONESUCH; } --------------------------------------------- Gisle V. From owner-lynx-dev@sig.net Mon Nov 23 19:09:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA28251 for ; Mon, 23 Nov 1998 19:09:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20565; Mon, 23 Nov 1998 17:46:25 -0600 (CST) Message-Id: <3.0.5.32.19981123155647.0092f100@10.0.10.15> X-Sender: ravib@10.0.10.15 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 23 Nov 1998 15:56:47 To: lynx-dev@sig.net From: Ravi Kumar Subject: lynx-dev Queries and problems 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: 1036 Lines: 20 Hi, I started using Lynx recently (infact yesterday) on my windows machine.I read thru your readme document that was bundled along with the lynx zip file.I have a couple of queries to ask. a. I would like to know if the lynx that I downloaded from your site is the latest.If not where can I find the latest win32 version of the same. b.Where can I find the source code of the win32 version of lynx.I checked out the lynx web site, but I find that there are mainly links to UNIX VERSION OF THE BROWSER.i got overwhelmed and would like to get the windows version of the source ( win32 version). c.I am not able to set the HELPFILES to my local machine using "file:" protocol. Lynx says that it is not able to connect to the ftp site.I would like the browser to point to the local help file copy while displaying help. d.I want to custimise the colours.Is it possible. pls help. Success is relative: It is what we can make of the mess we made of things. --- T.S.Eliot Have a nice Day, Ravi Kumar From owner-lynx-dev@sig.net Mon Nov 23 19:25:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA29232 for ; Mon, 23 Nov 1998 19:25:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA24956; Mon, 23 Nov 1998 18:07:01 -0600 (CST) To: lynx-dev@sig.net References: <199811231123.GAA25734@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 03:03:39 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.7 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: 701 Lines: 15 > 1998-11-23 (2.8.2dev.7) > * add/use new functions HTAA_UidToName(), HTAA_NameToUid(), HTAA_GidToName() > and HTAA_NameToGid() to hide details of code which uses pwd.h and grp.h, > as well as to cache the returned user/group names, improving performance > in the dired screen - TD HTAAProt.c fails to build with DJGPP (probably no groups on DOS?) - lines 688,713,717, etc - "redefining pointer to incomplete type" > * modify HTCheckForInterrupt() to check for interrupt no more than one per > second, since this check is comparatively slow - TD I usually test lynx on slow 386: no difference in speed detected, but 1 sec delay while scrolling in partial mode is annoying (with any CPU). From owner-lynx-dev@sig.net Mon Nov 23 19:26:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA29242 for ; Mon, 23 Nov 1998 19:26:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA20817; Mon, 23 Nov 1998 17:47:30 -0600 (CST) From: Ilya Zakharevich Message-Id: <199811222325.SAA14651@monk.mps.ohio-state.edu> Subject: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Sun, 22 Nov 1998 18:25:51 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 16676 Lines: 563 This patch fixes all the mouse problems I see with lynx as far as ncurses are used. The only thing really missing is a (possibly context-sensitive) menu of possible actions assigned to button-2 of the mouse. Well, one could also enjoy a menu of possible print/download methods on Shift-clicking a link! ;-) (These changes should be propagated into other branches (PDCURSES etc), but I cannot do it myself. It should be pretty straightforward.) Q. Why have almost-duplicate code for popup_choice() and popup_option()? Improvements: a) Mouse navigation inside text entry fields; b) Mouse navigation to a text entry field (including an empty one) c) Mouse navigation to a specific position of a text field (since I do not know which fields are text fields, I implemented "b" and "c" for F_TEXTAREA_TYPE and F_TEXT_TYPE only, search for these symbols in the patch); d) Mouse navigation in menus: To scroll, one can click on top/bottom border (single=byline, double=bypage, triple=beg/end), or above/below menu (single=bypage, double=beg/end)) mouse-3 ==> quit; e) Double-click-1 on the first and last row are interpreted as goto- start/end/main-window (depending on the location of the click). Changes: a) Ask ncurses for all mouse events, but increase mouseinterval() to simulate current behaviour (which is effectively an infinite mouseinterval() + masking of repeated clicks); b) Earlier clicking to the left of a link would activate the link. I see no use for this, so consider this a bug. Enjoy, Ilya --- ./src/LYCurses.c~ Tue Nov 10 14:47:38 1998 +++ ./src/LYCurses.c Sun Nov 22 03:22:24 1998 @@ -882,10 +882,22 @@ PUBLIC void lynx_enable_mouse ARGS1(int, } #else /* Inform ncurses that we're interested in knowing when mouse - * button 1 is clicked */ - if (state) - mousemask(BUTTON1_CLICKED | BUTTON3_CLICKED, NULL); - else + * button 1 is clicked. We cannot just specify + * BUTTON1_CLICKED | BUTTON3_CLICKED, since ncurses will try hard + * to translate other events to single-clicks. + * Compensate for small value of maxclick in ncurses. */ + if (state) { + static was = 0; + + if (!was) { + int old = mouseinterval(-1); + + was++; + if (old < 200) /* Default 166 */ + mouseinterval(300); + } + mousemask(ALL_MOUSE_EVENTS, NULL); + } else mousemask(0, NULL); #endif /* __BORLANDC__ and __PDCURSES__ */ #endif /* NCURSES_MOUSE_VERSION */ --- ./src/LYEditmap.c~ Thu Aug 6 07:28:22 1998 +++ ./src/LYEditmap.c Sun Nov 22 01:09:22 1998 @@ -99,7 +99,7 @@ LYE_CHAR, LYE_CHAR, LYE_CHAR LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, LYE_CHAR, -/* 100..10E function key definitions in LYStrings.h */ +/* 100..10F function key definitions in LYStrings.h */ LYE_NOP, LYE_NOP, LYE_FORW, LYE_BACK, /* UPARROW DNARROW RTARROW LTARROW */ @@ -110,7 +110,7 @@ LYE_NOP, LYE_TAB, LYE_BOL, /* F1 Do key Find key Select key */ LYE_NOP, LYE_DELP, LYE_NOP, LYE_NOP, -/* Insert key Remove key DO_NOTHING ... */ +/* Insert key Remove key MOUSE_KEY DO_NOTHING */ }; /* --- ./src/LYForms.c~ Sun Sep 13 09:35:54 1998 +++ ./src/LYForms.c Sun Nov 22 17:40:04 1998 @@ -263,7 +263,7 @@ PRIVATE int form_getstr ARGS1( int max_length; int startcol, startline; BOOL HaveMaxlength = FALSE; - int action; + int action, repeat, non_first = 0; #ifdef VMS extern BOOLEAN HadVMSInterrupt; /* Flag from cleanup_sig() AST */ @@ -337,14 +337,38 @@ PRIVATE int form_getstr ARGS1( */ for (;;) { again: - ch = LYgetch(); + repeat = -1; + get_mouse_link(); /* Reset mouse_link. */ + /* Try to set position basing on the last mouse event */ + if (!non_first++) + peek_mouse_levent(); + + ch = LYgetch_for(FOR_INPUT); #ifdef VMS if (HadVMSInterrupt) { HadVMSInterrupt = FALSE; ch = 7; } #endif /* VMS */ - +# ifdef NCURSES_MOUSE_VERSION + if (ch == MOUSE_KEY) { /* Need to process ourselves */ + MEVENT event; + int curx, cury; + + getmouse(&event); + LYGetYX(cury, curx); + if (event.y == cury) { + repeat = event.x - curx; + if (repeat < 0) { + ch = LTARROW; + repeat = - repeat; + } else + ch = RTARROW; + } + } +# endif /* defined NCURSES_MOUSE_VERSION */ + if (peek_mouse_link() != -1) + break; /* * Filter out global navigation keys that should not be passed * to line editor, and LYK_REFRESH. @@ -393,7 +417,7 @@ again: * else you can get trapped in a form without submit button! */ case LTARROW: - if (MyEdit.pos == 0) { + if (MyEdit.pos == 0 && repeat == -1) { int c = 'Y'; /* Go back immediately if no changes */ if (strcmp(MyEdit.buffer, value)) { _statusline(PREV_DOC_QUERY); @@ -416,7 +440,10 @@ again: /* * Make sure the statusline uses editmode help. */ - LYLineEdit(&MyEdit, ch, TRUE); + if (repeat < 0) + repeat = 1; + while (repeat--) + LYLineEdit(&MyEdit, ch, TRUE); if (MyEdit.strlen >= max_length) { HaveMaxlength = TRUE; } else if (HaveMaxlength && @@ -824,9 +851,84 @@ redraw: wrefresh(form_window); #endif /* USE_SLANG */ - c = LYgetch(); + c = LYgetch_for(FOR_CHOICE); if (c == 3 || c == 7) /* Control-C or Control-G */ cmd = LYK_QUIT; +# ifdef NCURSES_MOUSE_VERSION + else if (c == MOUSE_KEY) { + MEVENT event; + + getmouse(&event); + if ((event.bstate & (BUTTON1_CLICKED | BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + && (event.x >= form_window->_begx) + && (event.x <= (form_window->_begx + form_window->_maxx))) { + int delta = event.y + - form_window->_begy - form_window->_yoffset + - ((i + 1) - window_offset); + int menu_pos = event.y + - form_window->_begy - form_window->_yoffset; + + if (menu_pos == form_window->_maxy) { + /* At the decorative border: scroll forward */ + if (event.bstate & BUTTON1_TRIPLE_CLICKED) + cmd = LYK_END; + else if (event.bstate & BUTTON1_DOUBLE_CLICKED) + cmd = LYK_NEXT_PAGE; + else + cmd = LYK_NEXT_LINK; + } else if (menu_pos > form_window->_maxy) { + if (event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + cmd = LYK_END; + else + cmd = LYK_NEXT_PAGE; + } else if (menu_pos == 0) { + /* At the decorative border: scroll back */ + if (event.bstate & BUTTON1_TRIPLE_CLICKED) + cmd = LYK_HOME; + else if (event.bstate & BUTTON1_DOUBLE_CLICKED) + cmd = LYK_PREV_PAGE; + else + cmd = LYK_PREV_LINK; + } else if (menu_pos < 0) { + if (event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + cmd = LYK_HOME; + else + cmd = LYK_PREV_PAGE; +# ifdef KNOW_HOW_TO_TOGGLE + } else if (event.bstate & (BUTTON_CTRL)) { + cur_selection += delta; + cmd = LYX_TOGGLE; +# endif + } else if (event.bstate & (BUTTON_ALT | BUTTON_SHIFT + | BUTTON_CTRL)) { + /* Probably some unrelated activity, such as + * selecting some text. Select, but do nothing else. */ + cur_selection += delta; + goto redraw; + } else { + /* No scrolling or overflow checks necessary. */ + cur_selection += delta; +# if 0 /* Immediate action looks reasonable since we + * have no help available for individual options. + * Moreover, one can position active element + * with shift-click-1. (;-) */ + if (!(event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED))) + goto redraw; +# endif + cmd = LYK_ACTIVATE; + break; + } + } else if (event.bstate & (BUTTON3_CLICKED | BUTTON3_DOUBLE_CLICKED + | BUTTON3_TRIPLE_CLICKED)) + cmd = LYK_QUIT; + else + cmd = LYK_DO_NOTHING; + } +# endif else cmd = keymap[c+1]; #ifdef VMS --- ./src/LYOptions.c~ Mon Nov 16 17:59:26 1998 +++ ./src/LYOptions.c Sun Nov 22 17:58:04 1998 @@ -2486,10 +2486,86 @@ redraw: #endif /* USE_SLANG */ term_options = FALSE; - c = LYgetch(); + c = LYgetch_for(FOR_CHOICE); if (term_options || c == 3 || c == 7) { cmd = LYK_QUIT; - } else { + } +# ifdef NCURSES_MOUSE_VERSION + else if (c == MOUSE_KEY) { + MEVENT event; + + getmouse(&event); + if ((event.bstate & (BUTTON1_CLICKED | BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + && (event.x >= form_window->_begx) + && (event.x <= (form_window->_begx + form_window->_maxx))) { + int delta = event.y + - form_window->_begy - form_window->_yoffset + - ((i + 1) - window_offset); + int menu_pos = event.y + - form_window->_begy - form_window->_yoffset; + + if (menu_pos == form_window->_maxy) { + /* At the decorative border: scroll forward */ + if (event.bstate & BUTTON1_TRIPLE_CLICKED) + cmd = LYK_END; + else if (event.bstate & BUTTON1_DOUBLE_CLICKED) + cmd = LYK_NEXT_PAGE; + else + cmd = LYK_NEXT_LINK; + } else if (menu_pos > form_window->_maxy) { + if (event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + cmd = LYK_END; + else + cmd = LYK_NEXT_PAGE; + } else if (menu_pos == 0) { + /* At the decorative border: scroll back */ + if (event.bstate & BUTTON1_TRIPLE_CLICKED) + cmd = LYK_HOME; + else if (event.bstate & BUTTON1_DOUBLE_CLICKED) + cmd = LYK_PREV_PAGE; + else + cmd = LYK_PREV_LINK; + } else if (menu_pos < 0) { + if (event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED)) + cmd = LYK_HOME; + else + cmd = LYK_PREV_PAGE; +# ifdef KNOW_HOW_TO_TOGGLE + } else if (event.bstate & (BUTTON_CTRL)) { + cur_selection += delta; + cmd = LYX_TOGGLE; +# endif + } else if (event.bstate & (BUTTON_ALT | BUTTON_SHIFT + | BUTTON_CTRL)) { + /* Probably some unrelated activity, such as + * selecting some text. Select, but do nothing else. */ + cur_choice += delta; + goto redraw; + } else { + /* No scrolling or overflow checks necessary. */ + cur_choice += delta; +# if 0 /* Immediate action looks reasonable since we + * have no help available for individual options. + * Moreover, one can position active element + * with shift-click-1. (;-) */ + if (!(event.bstate & (BUTTON1_DOUBLE_CLICKED + | BUTTON1_TRIPLE_CLICKED))) + goto redraw; +# endif + cmd = LYK_ACTIVATE; + break; + } + } else if (event.bstate & (BUTTON3_CLICKED | BUTTON3_DOUBLE_CLICKED + | BUTTON3_TRIPLE_CLICKED)) + cmd = LYK_QUIT; + else + cmd = LYK_DO_NOTHING; + } +# endif + else { cmd = keymap[c+1]; } #ifdef VMS --- ./src/LYStrings.c~ Mon Nov 16 17:59:26 1998 +++ ./src/LYStrings.c Sun Nov 22 17:44:12 1998 @@ -38,15 +38,42 @@ extern HTCJKlang HTCJK; /* The number of the link selected w/ the mouse (-1 if none) */ static int mouse_link = -1; +static int have_levent; + +#ifdef NCURSES_MOUSE_VERSION +static MEVENT levent; +/* Return the value of mouse_link */ +PUBLIC int peek_mouse_levent NOARGS +{ + if (!have_levent) + return 0; + ungetmouse(&levent); + return 1; +} +#else +PUBLIC int peek_mouse_levent NOARGS +{ + return 0; +} +#endif + /* Return the value of mouse_link, erasing it */ PUBLIC int get_mouse_link NOARGS { int t; t=mouse_link; mouse_link = -1; + if (t < 0) + t = -1; /* Backward compatibility. */ return t; } +/* Return the value of mouse_link */ +PUBLIC int peek_mouse_link NOARGS +{ + return mouse_link; +} + /* Given X and Y coordinates of a mouse event, set mouse_link to the ** index of the corresponding hyperlink, or set mouse_link to -1 if no ** link matches the event. Returns -1 if no link matched the click, @@ -54,7 +81,7 @@ PUBLIC int get_mouse_link NOARGS ** link. **/ -PRIVATE int set_clicked_link ARGS2(int,x,int,y) +PRIVATE int set_clicked_link ARGS3(int,x,int,y,int,code) { int left = 6; int right = LYcols-6; @@ -63,22 +90,45 @@ PRIVATE int set_clicked_link ARGS2(int,x int c = -1; if (y == (LYlines-1)) { + mouse_link = -2; if (x < left) c = LTARROW; else if (x > right) c = '\b'; else c = PGDOWN; } else if (y == 0) { + mouse_link = -2; if (x < left) c = LTARROW; else if (x > right) c = '\b'; else c = PGUP; } else { /* Loop over the links and see if we can get a match */ for (i = 0; i < nlinks; i++) { + int len, lx = links[i].lx, is_text = 0; + + if (links[i].type == WWW_FORM_LINK_TYPE + /* XXXX What else? */ + && (links[i].form->type == F_TEXTAREA_TYPE + || links[i].form->type == F_TEXT_TYPE)) + is_text = 1; + + if (is_text) + len = links[i].form->size; + else + len = strlen(links[i].hightext ); + /* Check the first line of the link */ if ( links[i].hightext != NULL && - links[i].ly == y && - (x - links[i].lx) < (int)strlen(links[i].hightext ) ) { - mouse_link = i; - break; + links[i].ly == y && (x - lx) < len && (x >= lx)) { + int cury, curx; + + if (code != FOR_INPUT + /* Do not pick up the current input field */ + || !(LYGetYX(cury,curx), + (cury == y && (curx >= lx) && ((curx - lx) <= len)))) { + if (is_text) + have_levent = 1; + mouse_link = i; + +} break; } /* Check the second line */ if (links[i].hightext2 != NULL && @@ -323,7 +373,7 @@ PRIVATE int sl_read_mouse_event NOARGS if (-1 != sl_parse_mouse_event (&mouse_x, &mouse_y, &button)) { if (button == 0) /* left */ - return set_clicked_link (mouse_x, mouse_y); + return set_clicked_link (mouse_x, mouse_y, FOR_PANEL); if (button == 2) /* right */ { @@ -808,6 +858,12 @@ PUBLIC int LYgetch NOARGS return keysym; } +PUBLIC int LYgetch_for ARGS1( + int, code) +{ + return LYgetch(); +} + #else /* !USE_KEYMAPS */ /* @@ -817,8 +873,16 @@ PUBLIC int LYgetch NOARGS PUBLIC int LYgetch NOARGS { + return LYgetch_for(FOR_PANEL); +} + +PUBLIC int LYgetch_for ARGS1( + int, code) +{ int a, b, c, d = -1; + have_levent = 0; + #if defined(IGNORE_CTRL_C) || defined(USE_GETCHAR) || !defined(NCURSES) re_read: #endif /* IGNORE_CTRL_C || USE_GETCHAR */ @@ -1110,7 +1174,9 @@ re_read: #endif /* KEY_DC */ #ifdef NCURSES_MOUSE_VERSION case KEY_MOUSE: - { + if (code == FOR_CHOICE) { + c = MOUSE_KEY; /* Will be processed by the caller */ + } else { #ifndef DOSPATH MEVENT event; int err; @@ -1118,17 +1184,31 @@ re_read: c = -1; mouse_link = -1; err = getmouse(&event); + levent = event; /* Allow setting pos in entry fields */ if (event.bstate & BUTTON1_CLICKED) { - c = set_clicked_link(event.x, event.y); + c = set_clicked_link(event.x, event.y, code); + } else if (event.bstate & BUTTON1_DOUBLE_CLICKED) { + c = set_clicked_link(event.x, event.y, code); + if (c == PGDOWN) + c = END_KEY; + else if (c == PGUP) + c = HOME; + else if (c == LTARROW) + c = LYReverseKeymap(LYK_MAIN_MENU); } else if (event.bstate & BUTTON3_CLICKED) { c = LYReverseKeymap (LYK_PREV_DOC); } + if (code == FOR_INPUT && mouse_link == -1) { + ungetmouse(&event); /* Caller will process this. */ + getch(); /* ungetmouse puts KEY_MOUSE back */ + c = MOUSE_KEY; + } #else /* pdcurses version */ c = -1; mouse_link = -1; request_mouse_pos(); if (BUTTON_STATUS(1) & BUTTON_CLICKED) { - c = set_clicked_link(MOUSE_X_POS, MOUSE_Y_POS); + c = set_clicked_link(MOUSE_X_POS, MOUSE_Y_POS, FOR_PANEL); } else if (BUTTON_STATUS(3) & BUTTON_CLICKED) { c = LYReverseKeymap (LYK_PREV_DOC); } --- ./src/LYStrings.h~ Mon Nov 16 17:59:26 1998 +++ ./src/LYStrings.h Sun Nov 22 18:03:04 1998 @@ -9,12 +9,17 @@ extern int UPPER8 PARAMS(( int ch2)); extern int get_mouse_link NOPARAMS; +extern int peek_mouse_link NOPARAMS; +extern int peek_mouse_levent NOPARAMS; + extern char * LYstrncpy PARAMS(( char * dst, CONST char * src, int n)); extern void ena_csi PARAMS((BOOLEAN flag)); extern int LYgetch NOPARAMS; +extern int LYgetch_for PARAMS(( + int code)); extern int LYgetstr PARAMS(( char * inputline, int hidden, @@ -84,7 +89,12 @@ extern char * SNACat PARAMS(( #define SELECT_KEY 267 /* 0x10B */ #define INSERT_KEY 268 /* 0x10C */ #define REMOVE_KEY 269 /* 0x10D */ -#define DO_NOTHING 270 /* 0x10E */ +#define MOUSE_KEY 270 /* 0x10E */ +#define DO_NOTHING 271 /* 0x10F */ + +# define FOR_PANEL 0 +# define FOR_CHOICE 1 +# define FOR_INPUT 2 #define VISIBLE 0 #define HIDDEN 1 From owner-lynx-dev@sig.net Mon Nov 23 20:15:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA32152 for ; Mon, 23 Nov 1998 20:15:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA04807; Mon, 23 Nov 1998 18:56:55 -0600 (CST) To: lynx-dev@sig.net References: <3.0.5.32.19981123155647.0092f100@10.0.10.15> Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 03:57:38 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Queries and problems 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: 29 > Hi, > I started using Lynx recently (infact yesterday) on my windows machine.I > read thru your readme document that was bundled along with the lynx zip > file.I have a couple of queries to ask. > a. I would like to know if the lynx that I downloaded from your site is the ^^^^^^^^^ http://lynx.browser.org > latest.If not where can I find the latest win32 version of the same. > b.Where can I find the source code of the win32 version of lynx.I checked > out the lynx web site, but I find that there are mainly links to UNIX > VERSION OF THE BROWSER.i got overwhelmed and would like to get the windows > version of the source ( win32 version). > c.I am not able to set the HELPFILES to my local machine using "file:" > protocol. Lynx says that it is not able to connect to the ftp site.I would > like the browser to point to the local help file copy while displaying help. > d.I want to custimise the colours.Is it possible. pls help. read lynx.cfg and change HELPFILE to something like file://localhost/c:/help/ everything customised from lynx.cfg, including colours. > Success is relative: It is what we can make of the mess we made of things. > --- T.S.Eliot > Have a nice Day, > Ravi Kumar From owner-lynx-dev@sig.net Mon Nov 23 22:54:10 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA10714 for ; Mon, 23 Nov 1998 22:54:08 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA04164; Mon, 23 Nov 1998 21:34:04 -0600 (CST) Date: Mon, 23 Nov 1998 22:36:22 -0500 (EST) Message-Id: <199811240336.WAA04756@access5.digex.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.flora.org/lynx-dev/html/month1198/msg00681.html X-Mailer: Lynx, Version 2.8.1dev.7 From: asgilman@access.digex.net (Al Gilman) Subject: lynx-dev authentication problem Cc: asgilman@access.digex.net (Al Gilman) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2492 Lines: 64 > >I'm new in this list. My problem now is that I am making certain >services to our www-server which should be Lynx compatible. > >The exapmle service is a web based POP-mail reader. There is a CGI >program that requires authentication from the browser (sends header: >HTTP/1.0 401 Unauthorized). After that the service uses this >information sent by browser to identify the user (uses them as POP >userid and pwd). > >This works fine with Netsc and IE. They continue sending the >authentication informatios as long as we stay in a same directory. >But Lynx not. I sends this information to CGI-program, but when CGI >program redirects it to an other document in the same directory it >will not send it any more. > >The Lynx version is 2.7.2 Lynx version is no matter. Please review your use of the REALM parameter in HTTP exchange. Lynx is very picky in not sending authorization information into what it views as a different realm as that for which the user supplied it. Your second file which is a peer of the CGI probably appears as outside the default REALM to Lynx. I believe that there is a way for you in the 401 challenge to say I need this authorization for realm="foo" and then lynx will answer with the authorization info for all HTTP accesses in that realm. Or else you have to do the initial challenge from something which has the root URL of the path subtree where you want to use the authorization information. Other browsers are not quite so careful about disclosing this information. Sorry not to be able to quote you chapter and verse from the HTTP spec, but this is the rock that you need to look under, I think. Al > >If you want more information I will explain. Please give some advice, >I need thsi Lynx connection! > >thank you >Esa Pikkarainen >Mr. Esa Pikkarainen (Linnanmaa, Snelmania, room: KTK338) >Fac of Ed, Univ of Oulu Tel:358-8-5533691 Fax: -5533744 >P.O. Box 222, SF-90571 Oulu E-mail: epikkara@ktk.oulu.fi >Finland :-) WWW: [9]http://wwwedu.oulu.fi/~/epikkara/ >PS. >Excuse me my bad English - I am not a native nor a daily user. > _________________________________________________________________ > > * Prev: [10]lynx-dev Printing Options patch > * Next: [11]lynx-dev lynx2.8.2dev.7 > * Index(es): > + [12]Main > + [13]Thread > _________________________________________________________________ > > [14]Lynx mailing list archives > > [15][FLORA HOME] [16][LYNX Home] From owner-lynx-dev@sig.net Mon Nov 23 22:54:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA10712 for ; Mon, 23 Nov 1998 22:54:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA03946; Mon, 23 Nov 1998 21:32:58 -0600 (CST) From: Philip Webb Message-Id: <199811240333.WAA27021@chass.utoronto.ca> Subject: Re: lynx-dev Queries and problems To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 22:33:55 -0500 (EST) Cc: ravib@future.futsoft.com In-Reply-To: <3.0.5.32.19981123155647.0092f100@10.0.10.15> from "Ravi Kumar" at Nov 23, 98 03:56: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: 1390 Lines: 29 981123 Ravi Kumar wrote: > I started using Lynx yesterday on my windows machine. > I read thru your readme that was bundled along with the lynx zip file. > (a) Is the lynx I downloaded the latest? > If not where can I find the latest win32 version of the same. how could we tell ... (smile)? the latest release is 2-8-1 from www.slcc.edu/lynx/release/ ; > (b) Where can I find the source code of the win32 version of lynx. > I checked out the lynx web site, but find there are mainly links > to UNIX VERSION. i got overwhelmed and would like to get the windows > version of the source ( win32 version). the above gives you the source for all platforms: for binaries, start at lynx.browser.org/ & follow the links. > (c) I am not able to set the HELPFILES to my local machine using "file:" > protocol. Lynx says that it is not able to connect to the ftp site.I would > like the browser to point to the local help file copy while displaying help. > (d) I want to custimise the colours.Is it possible. LP has already offered some help with these. try these things out & ask again here if you have further 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 Mon Nov 23 23:12:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA11966 for ; Mon, 23 Nov 1998 23:12:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA07746; Mon, 23 Nov 1998 21:53:01 -0600 (CST) From: dickey@clark.net Message-Id: <199811240355.WAA05695@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.7 To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 22:55:22 -0500 (EST) In-Reply-To: from "Leonid Pauzner" at Nov 24, 98 03:03:39 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: 1644 Lines: 36 > > 1998-11-23 (2.8.2dev.7) > > * add/use new functions HTAA_UidToName(), HTAA_NameToUid(), HTAA_GidToName() > > and HTAA_NameToGid() to hide details of code which uses pwd.h and grp.h, > > as well as to cache the returned user/group names, improving performance > > in the dired screen - TD > HTAAProt.c fails to build with DJGPP (probably no groups on DOS?) - > lines 688,713,717, etc - "redefining pointer to incomplete type" ok (I missed the NOUSERS ifdef). > > * modify HTCheckForInterrupt() to check for interrupt no more than one per > > second, since this check is comparatively slow - TD > > I usually test lynx on slow 386: no difference in speed detected, > but 1 sec delay while scrolling in partial mode is annoying (with any CPU). well, on the unix side, it's a big hit (probably slows Lynx down by a factor of 2-3 when just reading a directory). I noticed that it was slow starting up, and (as usual ;-) compared it to 2.7.2, then ran both with strace. About half of all the system calls were being made as as result of the interrupt-check. (This also slows down retrieval of files). I would think that a 1 second delay in stopping output wouldn't be a bad thing - it's a cheap solution (and the alternatives all appear expensive). At the same time, I saw that on Linux (and SunOS) at least, each of those calls to getpwnam, etc., caused the system to reread the whole /etc/passwd (or /etc/group). Probably Solaris caches the information. (We may make the caching by Lynx of user and group info an optional feature - it's a simple ifdef). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 23 23:13:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA11981 for ; Mon, 23 Nov 1998 23:13:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA08175; Mon, 23 Nov 1998 21:55:46 -0600 (CST) From: dickey@clark.net Message-Id: <199811240358.WAA06051@shell.clark.net> Subject: Re: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 22:58:12 -0500 (EST) In-Reply-To: <199811222325.SAA14651@monk.mps.ohio-state.edu> from "Ilya Zakharevich" at Nov 22, 98 06:25:51 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: 23 > This patch fixes all the mouse problems I see with lynx as far as > ncurses are used. The only thing really missing is a (possibly thanks > context-sensitive) menu of possible actions assigned to button-2 of the > mouse. Well, one could also enjoy a menu of possible print/download > methods on Shift-clicking a link! ;-) > > (These changes should be propagated into other branches (PDCURSES etc), > but I cannot do it myself. It should be pretty straightforward.) I'll check on that - slang at least I can do. PDCURSES I'll have to guess at. > Q. Why have almost-duplicate code for popup_choice() and popup_option()? there's a lot of redundancy in the code - I don't much like it, but it takes a while to see it (I merge the ones that I see if I'm not too busy). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 23 23:14:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA11986 for ; Mon, 23 Nov 1998 23:14:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA08253; Mon, 23 Nov 1998 21:56:09 -0600 (CST) From: dickey@clark.net Message-Id: <199811240358.WAA06094@shell.clark.net> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 22:58:34 -0500 (EST) In-Reply-To: <199811230142.UAA16703@monk.mps.ohio-state.edu> from "Ilya Zakharevich" at Nov 22, 98 08:42: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: 226 Lines: 9 > > Lynx tolerates *some* whitespace in the config file, but doesn't > tolerate some other. This is very confusing. Patch follows. thanks (on my list) -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 23 23:14:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA11995 for ; Mon, 23 Nov 1998 23:14:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA08320; Mon, 23 Nov 1998 21:56:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811240358.WAA06114@shell.clark.net> Subject: Re: lynx-dev HTaaprot fix To: lynx-dev@sig.net Date: Mon, 23 Nov 1998 22:58:53 -0500 (EST) In-Reply-To: from "Gisle Vanem" at Nov 23, 98 08:35: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: 1664 Lines: 86 > > > HTaaprot.c doesn't compile if NOUSERS si defined (as with djgpp). > Here is a fix: thanks (I missed that) > --------------------------------------------------------- > > --- htaaprot.org Mon Nov 23 19:14:40 1998 > +++ htaaprot.c Mon Nov 23 20:30:12 1998 > @@ -609,6 +609,7 @@ > */ > PUBLIC char * HTAA_UidToName ARGS1(int, uid) > { > +#ifndef NOUSERS > struct passwd *pw; > HTList *me = known_pwd; > > @@ -627,6 +628,7 @@ > save_uid_info(pw->pw_name, pw->pw_uid); > return pw->pw_name; > } > +#endif > return ""; > } > > @@ -640,6 +642,7 @@ > */ > PUBLIC int HTAA_NameToUid ARGS1(char *, name) > { > +#ifndef NOUSERS > struct passwd *pw; > HTList *me = known_pwd; > > @@ -657,6 +660,7 @@ > save_uid_info(pw->pw_name, pw->pw_uid); > return pw->pw_uid; > } > +#endif > return NONESUCH; > } > > @@ -670,6 +674,7 @@ > */ > PUBLIC char * HTAA_GidToName ARGS1(int, gid) > { > +#ifndef NOUSERS > struct group *gr; > HTList *me = known_grp; > > @@ -688,6 +693,7 @@ > save_gid_info(gr->gr_name, gr->gr_gid); > return gr->gr_name; > } > +#endif > return ""; > } > > @@ -701,6 +707,7 @@ > */ > PUBLIC int HTAA_NameToGid ARGS1(char *, name) > { > +#ifndef NOUSERS > struct group *gr; > HTList *me = known_grp; > > @@ -718,5 +725,6 @@ > save_gid_info(gr->gr_name, gr->gr_gid); > return gr->gr_gid; > } > +#endif > return NONESUCH; > } > > --------------------------------------------- > > Gisle V. > > -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 23 23:25:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA12623 for ; Mon, 23 Nov 1998 23:25:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA10924; Mon, 23 Nov 1998 22:08:37 -0600 (CST) Date: Mon, 23 Nov 1998 20:10:22 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Saner mouse in lynx with ncurses In-Reply-To: <199811222325.SAA14651@monk.mps.ohio-state.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: 2815 Lines: 60 On Sun, 22 Nov 1998, Ilya Zakharevich wrote: > This patch fixes all the mouse problems I see with lynx as far as > ncurses are used. The only thing really missing is a (possibly > context-sensitive) menu of possible actions assigned to button-2 of the > mouse. Well, one could also enjoy a menu of possible print/download > methods on Shift-clicking a link! ;-) > > (These changes should be propagated into other branches (PDCURSES etc), > but I cannot do it myself. It should be pretty straightforward.) > ... > --- ./src/LYEditmap.c~ Thu Aug 6 07:28:22 1998 > +++ ./src/LYEditmap.c Sun Nov 22 01:09:22 1998 > -/* 100..10E function key definitions in LYStrings.h */ > +/* 100..10F function key definitions in LYStrings.h */ > LYE_NOP, LYE_NOP, LYE_FORW, LYE_BACK, > /* UPARROW DNARROW RTARROW LTARROW */ > > @@ -110,7 +110,7 @@ LYE_NOP, LYE_TAB, LYE_BOL, > /* F1 Do key Find key Select key */ > > LYE_NOP, LYE_DELP, LYE_NOP, LYE_NOP, > -/* Insert key Remove key DO_NOTHING ... */ > +/* Insert key Remove key MOUSE_KEY DO_NOTHING */ > ... > #define REMOVE_KEY 269 /* 0x10D */ > -#define DO_NOTHING 270 /* 0x10E */ > +#define MOUSE_KEY 270 /* 0x10E */ > +#define DO_NOTHING 271 /* 0x10F */ I am a little worried about these changes as far as portability goes. There are a number of pdcurses, slang, and djgpp_keyhandler specific mappings in LYKeymap.c. I don't understand exactly how changes in LYEditmap.c will interact, but changes in LYStrings.h should. Mouse support has not yet been achieved in the DOS port, but is in the Win32 port. The value for MOUSE_KEY chosen here is already used by the PDCURSES and DJGPP_KEYHANDLER with SLANG ports. In DJGPP_KEYHANDLER, 0x10E is Alt_Backspace and 0x10F is BackTab. In PDCURSES, 0x10E is F6 and 0x10F is F7. In the SLANG without DJGPP_KEYHANDLER, 0x10F is backspace and mapped to LYK_HISTORY. (I hope I got this right. It has been a while since worked on LYKeymap). I wonder if it might not be better to expand the array in LYEditmap.c to match that in LYKeymap.c (I think that this goes up to 0x293) and move DO_NOTHING to the end of the array, picking a value for MOUSE_KEY not currently used by any of the programs to represent existing keys. If we bring DO_NOTHING to the end of the array, we can get rid of the code at the end of LYStrings.c that distinguishes between the acceptable keys in DJGPP/Windows versus other ports. I hope these worries are groundless, but it is probably easier to bring this up now, rather than after the changes are incorporated in the code. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Nov 24 04:16:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA31087 for ; Tue, 24 Nov 1998 04:16:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA16349; Tue, 24 Nov 1998 02:52:46 -0600 (CST) To: lynx-dev@sig.net References: <199811240355.WAA05695@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 11:48:20 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.7 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: 1446 Lines: 36 >> > * modify HTCheckForInterrupt() to check for interrupt no more than one per >> > second, since this check is comparatively slow - TD >> >> I usually test lynx on slow 386: no difference in speed detected, >> but 1 sec delay while scrolling in partial mode is annoying (with any CPU). > well, on the unix side, it's a big hit (probably slows Lynx down by a > factor of 2-3 when just reading a directory). I noticed that it was > slow starting up, and (as usual ;-) compared it to 2.7.2, then ran both > with strace. About half of all the system calls were being made as > as result of the interrupt-check. (This also slows down retrieval of > files). Yes, reading of large directory is slow on Linux, probably use your DontCheck() in certain situations only? > I would think that a 1 second delay in stopping output wouldn't be > a bad thing - it's a cheap solution (and the alternatives all appear > expensive). > At the same time, I saw that on Linux (and SunOS) at least, each of those > calls to getpwnam, etc., caused the system to reread the whole /etc/passwd > (or /etc/group). Probably Solaris caches the information. (We may make > the caching by Lynx of user and group info an optional feature - it's a > simple ifdef). Yes, something pathological around here: DJGPP port very slow on reading directory from CD, it can take >10 sec easily. > -- > Thomas E. Dickey > dickey@clark.net > http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 04:35:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA32206 for ; Tue, 24 Nov 1998 04:35:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA18510; Tue, 24 Nov 1998 03:15:54 -0600 (CST) From: "Esa Pikkarainen" Organization: Oulun yliopisto/KTK To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 11:19:34 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: lynx-dev authentication problem CC: asgilman@access.digex.net (Al Gilman) In-reply-to: <199811240336.WAA04756@access5.digex.net> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <41F7B607140@ktk.oulu.fi> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1144 Lines: 27 Thank you Al, The problem was not in REALM (it seems that it could be jus anything. The HTTP 1.0 specification (http://www.w3.org/Protocols/HTTP/1.0/spec.html) says that: "The realm value should be considered an opaque string which can only be compared for equality with other realms on that server." And then it uses as an exapmle: "WallyWorld".) The real problem seems to have been the URL that requires that CGI. (I found it out when I was testing with different kind of realm values and redirection methods.) It was "authent.wcgi?posti/lista.ihtml". When I changed the CGI so that I could leave this GET query string out then it started to work. Now Lynx knows that the directory of CGI is the realm where it should send authorisation info automaticly. Now my service is Lynx compatible! greetings Esa Pikkarainen Mr. Esa Pikkarainen (Linnanmaa, Snelmania, room: KTK338) Fac of Ed, Univ of Oulu Tel:358-8-5533691 Fax: -5533744 P.O. Box 222, SF-90571 Oulu E-mail: epikkara@ktk.oulu.fi Finland :-) WWW: http://wwwedu.oulu.fi/~/epikkara/ PS. Excuse me my bad English - I am not a native nor a daily user. From owner-lynx-dev@sig.net Tue Nov 24 04:35:28 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA32212 for ; Tue, 24 Nov 1998 04:35:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA17581; Tue, 24 Nov 1998 03:06:27 -0600 (CST) Date: Tue, 24 Nov 1998 03:08:51 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Config file reader [PATCH] In-Reply-To: <199811240358.WAA06094@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: 395 Lines: 15 On Mon, 23 Nov 1998 dickey@clark.net wrote: > > Lynx tolerates *some* whitespace in the config file, but doesn't > > tolerate some other. This is very confusing. Patch follows. > > thanks (on my list) As provided, that patch would prevent some things from working, where spaces or tabs are significant: TRUSTED_LYNXCGI:/usr/local/etc/httpd/cgi-bin/ KEYMAP: :something Klaus From owner-lynx-dev@sig.net Tue Nov 24 05:25:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA02296 for ; Tue, 24 Nov 1998 05:25:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA22539; Tue, 24 Nov 1998 04:04:56 -0600 (CST) From: dickey@clark.net Message-Id: <199811241007.FAA27701@shell.clark.net> Subject: Re: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 05:07:21 -0500 (EST) In-Reply-To: from "Doug Kaufman " at Nov 23, 98 08:10: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: 644 Lines: 20 > On Sun, 22 Nov 1998, Ilya Zakharevich wrote: ... > > ... > > #define REMOVE_KEY 269 /* 0x10D */ > > -#define DO_NOTHING 270 /* 0x10E */ > > +#define MOUSE_KEY 270 /* 0x10E */ > > +#define DO_NOTHING 271 /* 0x10F */ > > I am a little worried about these changes as far as portability goes. I did notice that (MOUSE_KEY) and question it - I'll tinker with the patch (as I have that habit) to make it more portable. (Of course I miss things, as we see in the changes...). But - like his patch - your comments are on my list to digest/integrate. > Doug Kaufman -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 05:38:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA02840 for ; Tue, 24 Nov 1998 05:38:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA23722; Tue, 24 Nov 1998 04:19:33 -0600 (CST) From: dickey@clark.net Message-Id: <199811241022.FAA29357@shell.clark.net> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 05:21:59 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 24, 98 03:08: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: 739 Lines: 25 > On Mon, 23 Nov 1998 dickey@clark.net wrote: > > > > Lynx tolerates *some* whitespace in the config file, but doesn't > > > tolerate some other. This is very confusing. Patch follows. > > > > thanks (on my list) > > As provided, that patch would prevent some things from working, > where spaces or tabs are significant: > > TRUSTED_LYNXCGI:/usr/local/etc/httpd/cgi-bin/ I don't understand this one - does it matter if someone typed a space instead of a tab? > KEYMAP: :something ok - this one would require some thought. But we don't have anything like KEYWORD::something which would not be doable, right? > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 05:39:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA02860 for ; Tue, 24 Nov 1998 05:39:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA23950; Tue, 24 Nov 1998 04:22:29 -0600 (CST) From: dickey@clark.net Message-Id: <199811241024.FAA29606@shell.clark.net> Subject: Re: lynx-dev lynx2.8.2dev.7 To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 05:24:55 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 24, 98 11:48:20 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: 529 Lines: 16 > Yes, reading of large directory is slow on Linux, > probably use your DontCheck() in certain situations only? maybe - I thought about adding a parameter so I could use the feature only where it was "needed", but that didn't seem to be a good solution. > Yes, something pathological around here: > DJGPP port very slow on reading directory from CD, > it can take >10 sec easily. is that a result of the recent change, or was that the case before? -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 06:03:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA04494 for ; Tue, 24 Nov 1998 06:03:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA25374; Tue, 24 Nov 1998 04:37:55 -0600 (CST) Date: Tue, 24 Nov 1998 19:41:16 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811241041.TAA15530@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 5531 Lines: 185 > If you just want your bzipped file displayed by most, If that's all I wanted, there'd be no need to use Lynx. :-) Anyway, bzip2 has made tremendous strides since this discussion began over a year ago. With the speed of decompression bzip2 has achieved, I strongly urge that Lynx be modified to properly handle bzip2-compressed files. The appended patch, granted not done in decent programming style, will allow that support for http-served files. (Thanks to Bela!) __Henry *** lynx2-8-2/src/HTFWriter.c.orig Tue Nov 24 10:06:22 1998 --- lynx2-8-2/src/HTFWriter.c Tue Nov 24 10:33:12 1998 *************** *** 156,163 **** * and remove any previous uncompressed copy. - FM */ StrAllocCopy(path, me->anchor->FileCache); ! if ((len = strlen(path)) > 2) { ! if (!strcasecomp(&path[len-2], "gz")) { #ifdef USE_ZLIB if (!skip_loadfile) { use_gzread = YES; --- 156,166 ---- * and remove any previous uncompressed copy. - FM */ StrAllocCopy(path, me->anchor->FileCache); ! if ((len = strlen(path)) > 3) { ! if (!strcasecomp(&path[len-3], "bz2")) { ! path[len-4] = '\0'; ! remove(path); ! } else if (!strcasecomp(&path[len-2], "gz")) { #ifdef USE_ZLIB if (!skip_loadfile) { use_gzread = YES; *************** *** 856,862 **** * We have a presentation mapping for it. - FM */ can_present = TRUE; ! if (!strcasecomp(anchor->content_encoding, "x-gzip") || !strcasecomp(anchor->content_encoding, "gzip")) { /* * It's compressed with the modern gzip. - FM --- 859,870 ---- * We have a presentation mapping for it. - FM */ can_present = TRUE; ! if (!strcasecomp(anchor->content_encoding, "x-bzip2") || ! !strcasecomp(anchor->content_encoding, "bzip")) { ! StrAllocCopy(uncompress_mask, BZIP2_PATH); ! StrAllocCat(uncompress_mask, " -d %s"); ! compress_suffix = "bz2"; ! } else if (!strcasecomp(anchor->content_encoding, "x-gzip") || !strcasecomp(anchor->content_encoding, "gzip")) { /* * It's compressed with the modern gzip. - FM *** lynx2-8-2/userdefs.h.orig Tue Nov 24 08:56:36 1998 --- lynx2-8-2/userdefs.h Tue Nov 24 10:37:41 1998 *************** *** 1261,1266 **** --- 1261,1267 ---- */ #define UNCOMPRESS_PATH "gzip -d" #define GZIP_PATH "gzip" + #define BZIP2_PATH "bzip2" #else *************** *** 1282,1287 **** --- 1283,1289 ---- #define UUDECODE_PATH "uudecode" #define ZCAT_PATH "zcat" #define GZIP_PATH "gzip" + #define BZIP2_PATH "bzip2" #define INSTALL_PATH "install" #define TAR_PATH "tar" #define TOUCH_PATH "touch" *** lynx2-8-2/configure.orig Tue Nov 24 12:26:06 1998 --- lynx2-8-2/configure Tue Nov 24 12:43:13 1998 *************** *** 4177,4182 **** --- 4177,4253 ---- + test -z "$BZIP2" && BZIP2=bzip2 + if test "$with_full_paths" = yes ; then + set dummy bzip2; ac_word=$2 + echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 + echo "configure:4185: checking for $ac_word" >&5 + if eval "test \"`echo '$''{'ac_cv_path_BZIP2'+set}'`\" = set"; then + echo $ac_n "(cached) $ac_c" 1>&6 + else + case "$BZIP2" in + /*) + ac_cv_path_BZIP2="$BZIP2" # Let the user override the test with a path. + ;; + *) + IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:" + for ac_dir in $PATH; do + test -z "$ac_dir" && ac_dir=. + if test -f $ac_dir/$ac_word; then + ac_cv_path_BZIP2="$ac_dir/$ac_word" + break + fi + done + IFS="$ac_save_ifs" + test -z "$ac_cv_path_BZIP2" && ac_cv_path_BZIP2="$BZIP2" + ;; + esac + fi + BZIP2="$ac_cv_path_BZIP2" + if test -n "$BZIP2"; then + echo "$ac_t""$BZIP2" 1>&6 + else + echo "$ac_t""no" 1>&6 + fi + + else + echo $ac_n "checking for bzip2""... $ac_c" 1>&6 + echo "configure:4216: checking for bzip2" >&5 + echo "$ac_t""$BZIP2" 1>&6 + fi + + cf_path_prog="" + cf_path_args="" + IFS="${IFS= }"; cf_save_ifs="$IFS" + case $host_os in #(vi + os2*) #(vi + IFS="${IFS};" + ;; + *) + IFS="${IFS}:" + ;; + esac + for cf_temp in $ac_cv_path_BZIP2 + do + if test -z "$cf_path_prog" ; then + cf_path_prog="$cf_temp" + elif test -z "$cf_path_args" ; then + cf_path_args="$cf_temp" + else + cf_path_args="$cf_path_args $cf_temp" + fi + done + IFS="$cf_save_ifs" + + cat >> confdefs.h <> confdefs.h <; Tue, 24 Nov 1998 06:38:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA26980; Tue, 24 Nov 1998 04:58:29 -0600 (CST) Date: Tue, 24 Nov 1998 05:00:55 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev GridText.c patch with new HText_trimHightext 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: 11563 Lines: 379 Here is a patch which hopefully removes problems with form field display during partial rendering. Please test. I still think that changing the highlight() call in display_page() to if (display_partial) highlight(OFF, (nlinks - 1), target); and NOT calling HText_trimHightext() during partial rendering may also solve the problems, but have not tested it. The small change for color styles seems to give a big improvement. Patches are against 2.8.1rel.2 but should also work with dev.x. * HText_trimHightext (GridText.c): don't apply final adjustment repeatedly to an anchor that has already been handled by this function; the function may be called repeatedly if partial display is enabled. Some other changes in this function, to interact better with the other GridText.c functions, especially for partial display mode. We don't have to handle all anchors if the new parameter "final" is not set. Also empty anchors should now generally not any more move down over empty lines, if they happen at a line end. Made some trace messages give more information. * color styles: reset screen style cache to avoid random coloring when a link is unhighlighted. * Tweak in HText_setLastOptionValue: if an OPTION tag was directly followed by several newlines, characters could be dropped. *** lynx2-8-1.orig/src/GridText.h Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/GridText.h Sun Nov 15 09:36:04 1998 *************** *** 202,207 **** --- 202,208 ---- InputFieldData *I)); extern void HText_trimHightext PARAMS(( HText * text, + BOOLEAN final, BOOLEAN disable_trace)); extern void HText_SubmitForm PARAMS(( FormInfo * submit_item, *** lynx2-8-1.orig/src/GridText.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/GridText.c Tue Nov 24 04:13:43 1998 *************** *** 61,66 **** --- 61,77 ---- for (j=0;jtop_of_screen = line_number; display_title(text); /* will move cursor to top of screen */ display_flag=TRUE; *************** *** 3248,3254 **** * Fix up the anchor structure values and * create the hightext strings. - FM */ ! HText_trimHightext(text, FALSE); } --- 3263,3269 ---- * Fix up the anchor structure values and * create the hightext strings. - FM */ ! HText_trimHightext(text, TRUE, FALSE); } *************** *** 3260,3274 **** ** `Forms input' fields cannot be displayed properly without this function ** to be invoked (detected in display_partial mode). ** ! ** (BOOLEAN value allow us to disable annoying repeated trace messages ** for display_partial mode). */ ! PUBLIC void HText_trimHightext ARGS2( HText *, text, BOOLEAN, disable_trace) { int cur_line, cur_char, cur_shift; TextAnchor *anchor_ptr; HTLine *line_ptr; unsigned char ch; --- 3275,3307 ---- ** `Forms input' fields cannot be displayed properly without this function ** to be invoked (detected in display_partial mode). ** ! ** (BOOLEAN disable_trace allow us to disable annoying repeated trace messages ** for display_partial mode). + ** + ** If final is set, this is the final fixup; if not set, we don't have + ** to do everything because there should be another call later. + ** + ** BEFORE this function has treated a TextAnchor, its line_pos and + ** extent fields are counting bytes in the HTLine data, including + ** invisible special attribute chars and counting UTF-8 multibyte + ** characters as multiple bytes. + ** AFTER the adjustment, the anchor line_pos (and hightext2offset + ** if applicable) fields indicate x positions in terms of displayed + ** character cells, and the extent field apparently is unimportant; + ** the anchor text has been copied to the hightext (and possibly + ** hightext2) fields (which should be NULL up to this point), with + ** special attribute chars removed. + ** This needs to be done so that display_page finds the anchors in the + ** form it expects when it sets the links[] elements. */ ! PUBLIC void HText_trimHightext ARGS3( HText *, text, + BOOLEAN, final, BOOLEAN, disable_trace) { int cur_line, cur_char, cur_shift; TextAnchor *anchor_ptr; + TextAnchor *prev_a = NULL; HTLine *line_ptr; unsigned char ch; *************** *** 3286,3322 **** line_ptr = text->last_line->next; cur_char = line_ptr->size; cur_line = 0; - cur_shift = 0; /* * Fix up the anchor structure values and * create the hightext strings. - FM */ for (anchor_ptr = text->first_anchor; ! anchor_ptr; anchor_ptr=anchor_ptr->next) { re_parse: /* * Find the right line. */ ! for (; anchor_ptr->start >= cur_char; line_ptr = line_ptr->next, cur_char += line_ptr->size+1, cur_line++) { ; /* null body */ } if (anchor_ptr->start == cur_char) { anchor_ptr->line_pos = line_ptr->size; } else { anchor_ptr->line_pos = anchor_ptr->start - (cur_char - line_ptr->size); } ! if (anchor_ptr->line_pos < 0) anchor_ptr->line_pos = 0; ! if (!disable_trace) ! CTRACE(tfp, "Gridtext: Anchor found on line:%d col:%d\n", ! cur_line, anchor_ptr->line_pos); /* * Strip off any spaces or SpecialAttrChars at the beginning, * if they exist, but only on HYPERTEXT_ANCHORS. --- 3319,3390 ---- line_ptr = text->last_line->next; cur_char = line_ptr->size; cur_line = 0; /* * Fix up the anchor structure values and * create the hightext strings. - FM */ for (anchor_ptr = text->first_anchor; ! anchor_ptr; ! prev_a = anchor_ptr, anchor_ptr=anchor_ptr->next) { re_parse: /* * Find the right line. */ ! for (; anchor_ptr->start > cur_char; line_ptr = line_ptr->next, cur_char += line_ptr->size+1, cur_line++) { ; /* null body */ } + + if (!final) { + /* + * If this is not the final call, stop when we have reached + * the last line, or the very end of preceding line. + * The last line is probably still not finished. - kw + */ + if (cur_line >= text->Lines) + break; + if (anchor_ptr->start >= text->chars - 1) + break; + /* + * Also skip this anchor if it looks like HText_endAnchor + * is not yet done with it. - kw + */ + if (!anchor_ptr->extent && anchor_ptr->number && + (anchor_ptr->link_type & HYPERTEXT_ANCHOR) && + !anchor_ptr->show_anchor && + anchor_ptr->number == text->last_anchor_number) + continue; + } + + /* + * If hightext has already been set, then we must have already + * done the trimming & adjusting for this anchor, so avoid + * doing it a second time. - kw + */ + if (anchor_ptr->hightext) + continue; + if (anchor_ptr->start == cur_char) { anchor_ptr->line_pos = line_ptr->size; } else { anchor_ptr->line_pos = anchor_ptr->start - (cur_char - line_ptr->size); } ! if (anchor_ptr->line_pos < 0) { ! anchor_ptr->start -= anchor_ptr->line_pos; anchor_ptr->line_pos = 0; ! anchor_ptr->line_num = cur_line; ! } if (!disable_trace) ! CTRACE(tfp, ! "Gridtext: Anchor found on line:%d col:%d [%d] ext:%d\n", ! cur_line, anchor_ptr->line_pos, ! anchor_ptr->number, anchor_ptr->extent); + cur_shift = 0; /* * Strip off any spaces or SpecialAttrChars at the beginning, * if they exist, but only on HYPERTEXT_ANCHORS. *************** *** 3334,3339 **** --- 3402,3408 ---- if (anchor_ptr->extent < 0) { anchor_ptr->extent = 0; } + anchor_ptr->start += cur_shift; if (!disable_trace) CTRACE(tfp, "anchor text: '%s'\n", *************** *** 3341,3355 **** /* * If the link begins with an end of line and we have more * lines, then start the highlighting on the next line. - FM ! */ ! if ((unsigned)anchor_ptr->line_pos >= strlen(line_ptr->data) && ! cur_line < text->Lines) { ! anchor_ptr->start += (cur_shift + 1); ! cur_shift = 0; ! CTRACE(tfp, "found anchor at end of line\n"); ! goto re_parse; } - cur_shift = 0; /* * Copy the link name into the data structure. --- 3410,3431 ---- /* * If the link begins with an end of line and we have more * lines, then start the highlighting on the next line. - FM ! * But if an empty anchor is at the end of line and empty, ! * keep it where it is, unless the previous anchor in the list ! * (if any) already starts later. - kw ! */ ! if ((unsigned)anchor_ptr->line_pos >= strlen(line_ptr->data)) { ! if (cur_line < text->Lines && ! (anchor_ptr->extent || ! anchor_ptr->line_pos != (int)line_ptr->size || ! (prev_a && prev_a->start > anchor_ptr->start))) { ! anchor_ptr->start++; ! CTRACE(tfp, "found anchor at end of line\n"); ! goto re_parse; ! } else { ! CTRACE(tfp, "found anchor at end of line, leaving it there\n"); ! } } /* * Copy the link name into the data structure. *************** *** 3369,3374 **** --- 3445,3457 ---- */ if ((unsigned)anchor_ptr->extent > strlen(anchor_ptr->hightext)) { HTLine *line_ptr2 = line_ptr->next; + + if (!final) { + if (cur_line + 1 >= text->Lines) { + FREE(anchor_ptr->hightext); /* bail out */ + break; + } + } /* * Double check that we have a line pointer, * and if so, copy into hightext2. *************** *** 3414,3421 **** anchor_ptr->line_num = cur_line; if (!disable_trace) ! CTRACE(tfp, "GridText: add link on line %d col %d in HText_trimHightext\n", ! cur_line, anchor_ptr->line_pos); /* * If this is the last anchor, we're done! --- 3497,3505 ---- anchor_ptr->line_num = cur_line; if (!disable_trace) ! CTRACE(tfp, "GridText: add link on line %d col %d [%d] %s\n", ! cur_line, anchor_ptr->line_pos, ! anchor_ptr->number, "in HText_trimHightext"); /* * If this is the last anchor, we're done! *************** *** 4077,4083 **** ** ** Side effect is reported from multiply call of HText_trimHightext. */ ! HText_trimHightext(HTMainText, TRUE); } detected_forms_input_partial = FALSE; #endif --- 4161,4167 ---- ** ** Side effect is reported from multiply call of HText_trimHightext. */ ! HText_trimHightext(HTMainText, FALSE, TRUE); } detected_forms_input_partial = FALSE; #endif *************** *** 6193,6198 **** --- 6277,6290 ---- new_ptr->name = NULL; new_ptr->cp_submit_value = NULL; new_ptr->next = NULL; + /* + * Find first non-space again, convert_to_spaces above may have + * changed the string. - kw + */ + cp = value; + while (isspace((unsigned char)*cp) || + IsSpecialAttrChar((unsigned char)*cp)) + cp++; for (i = 0, j = 0; cp[i]; i++) { if (cp[i] == HT_NON_BREAK_SPACE || cp[i] == HT_EM_SPACE) { From owner-lynx-dev@sig.net Tue Nov 24 06:50:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA06939 for ; Tue, 24 Nov 1998 06:50:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA00096; Tue, 24 Nov 1998 05:31:30 -0600 (CST) Date: Tue, 24 Nov 1998 05:33:55 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev Config file reader [PATCH] In-Reply-To: <199811241022.FAA29357@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: 1220 Lines: 39 [about significant spaces in lynx.cfg] On Tue, 24 Nov 1998 dickey@clark.net wrote: > > TRUSTED_LYNXCGI:/usr/local/etc/httpd/cgi-bin/ > I don't understand this one - does it matter if someone typed a space > instead of a tab? add_trusted() looks specifically for '\t' as a separator. > > KEYMAP: :something > ok - this one would require some thought. Of course one could 0x20 instead. But is it a good idea to make the the syntax more restrictive? > But we don't have anything > like > KEYWORD::something > which would not be doable, right? Not that I know. But why change it at all? The top of lynx.cfg still says # NO spaces are allowed between the pair items. and I don't think that is confusing at all. If spaces happen to be ignored in some places, that is using an undocumented feature. Some configuration values can be rather arbitrary strings, and you don't need quotes around them (which makes things simpler if the strings themselves contain quotes). LIST_FORMAT: is a good example where spaces are significant. If you relax the syntax now, you have to treat some things specially, and introducing new such options in the future will be more complicated. Klaus From owner-lynx-dev@sig.net Tue Nov 24 07:03:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA07780 for ; Tue, 24 Nov 1998 07:03:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA01093; Tue, 24 Nov 1998 05:43:53 -0600 (CST) Date: Tue, 24 Nov 1998 05:46:19 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev show sticky bit 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: 1352 Lines: 44 Since we recommend the sticky bit for tmp directories, we should also attempt to show it in directory listings... *** lynx2-8-1.orig/WWW/Library/Implementation/HTFile.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/WWW/Library/Implementation/HTFile.c Tue Nov 24 05:41:04 1998 *************** *** 183,188 **** --- 183,193 ---- "r-S", "r-s", "rwS", "rws", 0 }; #define PBIT(a, n, s) (s) ? psbits[((a) >> (n)) & 0x7] : \ pbits[((a) >> (n)) & 0x7] + #ifdef S_ISVTX + static char *ptbits[] = { "--T", "--t", "-wT", "-wt", + "r-T", "r-t", "rwT", "rwt", 0 }; + #define PTBIT(a, s) (s) ? ptbits[(a) & 0x7] : pbits[(a) & 0x7] + #endif if (lstat(file, &st) < 0) fmtstr = "%a"; /* can't stat so just do anchor */ *************** *** 299,305 **** sprintf(buf, "%c%s%s%s", type, PBIT(st.st_mode, 6, st.st_mode & S_ISUID), PBIT(st.st_mode, 3, st.st_mode & S_ISGID), ! PBIT(st.st_mode, 0, 0)); sprintf(fmt, "%%%ss", start); sprintf(buf, fmt, buf); break; --- 304,315 ---- sprintf(buf, "%c%s%s%s", type, PBIT(st.st_mode, 6, st.st_mode & S_ISUID), PBIT(st.st_mode, 3, st.st_mode & S_ISGID), ! #ifdef S_ISVTX ! PTBIT(st.st_mode, st.st_mode & S_ISVTX) ! #else ! PBIT(st.st_mode, 0, 0) ! #endif ! ); sprintf(fmt, "%%%ss", start); sprintf(buf, fmt, buf); break; From owner-lynx-dev@sig.net Tue Nov 24 07:29:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA09034 for ; Tue, 24 Nov 1998 07:29:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA02978; Tue, 24 Nov 1998 06:02:24 -0600 (CST) To: lynx-dev@sig.net References: <199811241024.FAA29606@shell.clark.net> Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 14:53:28 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev lynx2.8.2dev.7 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: 275 Lines: 8 >> Yes, something pathological around here: >> DJGPP port very slow on reading directory from CD, >> it can take >10 sec easily. > is that a result of the recent change, or was that the case before? was before (haven't check the recent change, was problem in HTAAProt.c) From owner-lynx-dev@sig.net Tue Nov 24 07:34:36 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA09574 for ; Tue, 24 Nov 1998 07:34:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA04236; Tue, 24 Nov 1998 06:15:12 -0600 (CST) From: dickey@clark.net Message-Id: <199811241217.HAA12604@shell.clark.net> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 07:17:34 -0500 (EST) In-Reply-To: from "Klaus Weide " at Nov 24, 98 05:33:55 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: 498 Lines: 15 > Some configuration values can be rather arbitrary strings, and > you don't need quotes around them (which makes things simpler > if the strings themselves contain quotes). LIST_FORMAT: is a good > example where spaces are significant. If you relax the syntax > now, you have to treat some things specially, and introducing new > such options in the future will be more complicated. ok (not an issue). > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 07:46:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA10134 for ; Tue, 24 Nov 1998 07:46:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA05481; Tue, 24 Nov 1998 06:28:43 -0600 (CST) Date: Tue, 24 Nov 1998 06:31:09 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev lynx2.8.2dev.7 In-Reply-To: <199811240355.WAA05695@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: 1377 Lines: 27 On Mon, 23 Nov 1998 dickey@clark.net wrote: > > > * modify HTCheckForInterrupt() to check for interrupt no more than one per > > > second, since this check is comparatively slow - TD > > > > I usually test lynx on slow 386: no difference in speed detected, > > but 1 sec delay while scrolling in partial mode is annoying (with any CPU). > > well, on the unix side, it's a big hit (probably slows Lynx down by a > factor of 2-3 when just reading a directory). I noticed that it was > slow starting up, and (as usual ;-) compared it to 2.7.2, then ran both > with strace. About half of all the system calls were being made as > as result of the interrupt-check. (This also slows down retrieval of > files). If this is about the HTCheckForInterrupt() in HTFile.c from my patch - By all means take it out if it slows things down. I was not thinking of that effect. The check is probably not very useful in its current form - it only comes into play after all the readdir()s have been done, when Lynx has started generating HTML from the resulting tree structure. I put it there because I was testing reading a long directory under low memory conditions, and this way Lynx seemed to better detect when memory was exhausted (via the faked zap). But if this comes at the cost of reduced responsiveness, it should go away. Or only be done once every N files. Klaus From owner-lynx-dev@sig.net Tue Nov 24 08:17:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA11889 for ; Tue, 24 Nov 1998 08:17:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA07846; Tue, 24 Nov 1998 06:47:48 -0600 (CST) Date: Tue, 24 Nov 1998 06:50:15 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) In-Reply-To: <199811241041.TAA15530@ews07.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: 1033 Lines: 24 On Tue, 24 Nov 1998, Nelson Henry Eric wrote: > Anyway, bzip2 has made tremendous strides since this discussion began > over a year ago. With the speed of decompression bzip2 has achieved, I > strongly urge that Lynx be modified to properly handle bzip2-compressed > files. The appended patch, granted not done in decent programming style, > will allow that support for http-served files. (Thanks to Bela!) I think that code should be #ifdef'd, since we cannot expect everyone to have bzip2. (We seem to be making that assumption about gzip.) > ! if (!strcasecomp(anchor->content_encoding, "x-bzip2") || > ! !strcasecomp(anchor->content_encoding, "bzip")) { Do you mean "bzip2" here? Or do we need all four of "bzip", "x-bzip", "bzip2", and "x-bzip2"? Does anyone volunteer to officially register one of the forms, or at least ask the author about it? It probably would require writing an RFC, but then at least everyone could know what to put in a Content-Encoding header and what to expect there... Klaus From owner-lynx-dev@sig.net Tue Nov 24 10:39:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA21805 for ; Tue, 24 Nov 1998 10:39:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA09454; Tue, 24 Nov 1998 09:12:00 -0600 (CST) Message-Id: <3.0.5.32.19981124180454.00938260@10.0.10.15> X-Sender: ravib@10.0.10.15 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 24 Nov 1998 18:04:54 To: purslow@chass.utoronto.ca, lynx-dev@sig.net From: Ravi Kumar Subject: Re: lynx-dev Queries and problems In-Reply-To: <199811240333.WAA27021@chass.utoronto.ca> References: <3.0.5.32.19981123155647.0092f100@10.0.10.15> 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: 896 Lines: 22 At 10:33 PM 11/23/98 -0500, Philip Webb wrote: ..... LP has already offered some help with these. try these things out & ask again here if you have further problems. ... I managed to finally get the help files to be read from the local Hard Disk.However, I am not able to customise the colour aspect of lynx.I am running the win32 2.8.1 version of lynx on my windows NT 4.0 workstation.I have spent almost a couple of hours tinkering with it, however, to no satisfactory end result.I have only managed to change the background to black and text to blue, which has become extremely difficult to read.Worst still, I do not know how I did it.Pls. Help me with colour aspect of Lynx. Success is relative: It is what we can make of the mess we made of things. --- T.S.Eliot Have a nice Day, Ravi Kumar From owner-lynx-dev@sig.net Tue Nov 24 10:43:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA22384 for ; Tue, 24 Nov 1998 10:43:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA09381; Tue, 24 Nov 1998 09:11:44 -0600 (CST) Date: Tue, 24 Nov 1998 09:47:56 -0400 (AST) From: "David L. Potter" To: lynx-dev@sig.net cc: "Norman L. DeForest" Subject: lynx-dev Mis-numbering of links... 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: 1894 Lines: 56 Our version of Lynx... (which we call) Lynx Version 2.7.1ac-0.102+intl+csuite produces a rather curious result in some rather narrow circumstances. The behaviour was first detected on a Chinese Language page... and has subsequently been duplicated on an English page... a screen print of which is below... as a start you'll notice there are two links numbered '[3]'... ====================================================================== Bug Demo. _________________________________________________________________ [1] xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxxxx???? | BOFH [3] [3] [4] [=||=] _________________________________________________________________ Above, the link number for link # 2 is missing. Any of the "?"s may be deleted from the "length-critical" string and the bug persists. Add one more character to the string or delete more than four characters and the bug disappears. The problem seems to be that lynx gets confused if: 1. a link number is to be at the end of one line with the label wrapped to the line below that and 2. a link following the link to be wrapped has no label specified and 3. the link with no label is on the same line as the wrapped label. Also, some link numbers get duplicated and the first duplicate in a pair seems to have its URL listed as "hidden" with the others listed as "visible". ====================================================================== I'm curious if this rendering is consistent with the latest version of Lynx... Here is the url of our test page: http://www.chebucto.ns.ca/~af380/bug-demo.html Here is the original Chinese Page: http://www.cnnic.cn/cgi-bin/domainqc ---- Thanks to Norman DeForest who did all the work figuring out what was happening... david potter From owner-lynx-dev@sig.net Tue Nov 24 10:51:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA22791 for ; Tue, 24 Nov 1998 10:51:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA09988; Tue, 24 Nov 1998 09:13:39 -0600 (CST) From: jeanslee@990.net Date: 24 Nov 1998 07:40:03 -0000 Message-ID: <19981124074003.27029.fmail@990.net> To: lynx-dev@sig.net Subject: lynx-dev Please help me! Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 815 Lines: 10 hello, All developers of lynx: i am a chinese computer programer, now i read your source code of lynx and want learn something from it, but i meet many problem, one is there are too many states in the function SGML_character() (--in SGML.c file) , i can't get all their means, if you can give me more detail of these states, you will help me more ^_^. another problem is i can not understand how you deal with Unicode, it seems very complex and difficult, could you explain it for me. Very Thankful!!! ^_^ Best Regards jerry 98/24//11 __________________________________________________ »¶Ó­Ê¹ÓýðÁêÈÈÏßÃâ·Ñµç×ÓÓʼþϵͳhttp://www.990.net From owner-lynx-dev@sig.net Tue Nov 24 10:55:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA23090 for ; Tue, 24 Nov 1998 10:55:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA09554; Tue, 24 Nov 1998 09:12:16 -0600 (CST) Date: Tue, 24 Nov 1998 11:49:51 +0100 From: Stanislav Brabec Message-Id: <199811241049.LAA25679@k332.feld.cvut.cz> To: lynx-dev@sig.net Subject: lynx-dev lynx --enable-color-style causes fp error Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 268 Lines: 8 Hallo Lynx developers I have tried some experimental features of lynx, I have found, that lynx build with --enable-color-style causes immediate crash with "floating point exception" bug. My machine is GNU libc-2.0.100 / linux-2.1.128 / egcs-1.1b -- Stanislav Brabec From owner-lynx-dev@sig.net Tue Nov 24 11:22:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA24962 for ; Tue, 24 Nov 1998 11:22:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA21940; Tue, 24 Nov 1998 09:51:57 -0600 (CST) Date: Tue, 24 Nov 1998 10:53:48 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811241053.AA6031@cas.org> Subject: Re: lynx-dev Mis-numbering of links... In-Reply-To: of Tue, 24 Nov 1998 09:47:56 -0400 (AST) To: lynx-dev@sig.net Cc: "Norman L. DeForest" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3080 Lines: 72 Here's what I see with lynx 2.8.2.dev.7: Bug Demo. (p1 of 2) Bug Demo. _________________________________________________________________ [1]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxxxx???? | [2]BOFH [3][=||=] _________________________________________________________________ Above, the link number for link # 2 is missing. Any of the "?"s may be deleted from the "length-critical" string and the bug persists. Add one more character to the string or delete more than four characters and the bug disappears. The problem seems to be that lynx gets confused if: 1. a link number is to be at the end of one line with the label wrapped to the line below that and 2. a link following the link to be wrapped has no label specified and 3. the link with no label is on the same line as the wrapped label. Also, some link numbers get duplicated and the first duplicate in a pair seems to have its URL listed as "hidden" with the others listed as "visible". _________________________________________________________________ As above with label added to first empty link. Bug still present. [4]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxxxx???? | [5]BOFH [6]Profile [7][=||=] _________________________________________________________________ As above with label added to second empty link. Bug still present. [8]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxxx???? | [9]BOFH [10]HTML [11][=||=] _________________________________________________________________ As above with labels added to both empty links. Bug Demo. (p2 of 2) Bug gone. No missing link number. [12]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxx???? | [13]BOFH [14]Profile [15]HTML [16][=||=] _________________________________________________________________ As above with shorter "critical string". Bug gone. No missing link number. [17]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxx | [18]BOFH [19][=||=] _________________________________________________________________ As above with longer "critical string". Bug gone. No missing link number. [20]xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxx????x | [21]BOFH [22][=||=] _________________________________________________________________ -- 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 Nov 24 11:40:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA26386 for ; Tue, 24 Nov 1998 11:40:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA29675; Tue, 24 Nov 1998 10:16:20 -0600 (CST) Date: Tue, 24 Nov 1998 11:18:09 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811241118.AA6343@cas.org> Subject: Re: lynx-dev lynx --enable-color-style causes fp error In-Reply-To: <199811241049.LAA25679@k332.feld.cvut.cz> of Tue, 24 Nov 1998 11:49:51 +0100 To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 371 Lines: 6 The color styles code is experimental, which means that on some platforms it tends to crash immediately... -- 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 Nov 24 12:08:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA28159 for ; Tue, 24 Nov 1998 12:08:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA09061; Tue, 24 Nov 1998 10:46:09 -0600 (CST) From: Philip Webb Message-Id: <199811241647.LAA21578@chass.utoronto.ca> Subject: lynx-dev color problems (was queries etc) To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 11:47:04 -0500 (EST) Cc: ravib@future.futsoft.com In-Reply-To: <3.0.5.32.19981124180454.00938260@10.0.10.15> from "Ravi Kumar" at Nov 24, 98 06:04:54 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: 936 Lines: 18 981124 Ravi Kumar wrote: > I am not able to customise the colour aspect of lynx. > I am running the win32 2.8.1 version of lynx on my NT 4.0 workstation. > I have spent almost a couple of hours tinkering with it, > however, to no satisfactory end result. > I have only managed to change the background to black and text to blue, > which has become extremely difficult to read. > Worst still, I do not know how I did it. someone else will have to help you here: i don't have a color terminal. suggestions: try permutating the various choices in lynx.cfg ; look thro' the Archive at www.flora.org/lynx-dev/ , where you may find similar problems have been discussed. -- ========================,,============================================ 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 Nov 24 14:12:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA03986 for ; Tue, 24 Nov 1998 14:12:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA15375; Tue, 24 Nov 1998 12:48:21 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: lynx-dev@sig.net Subject: Re: lynx-dev Please help me! In-reply-to: Your message of "24 Nov 1998 07:40:03 GMT." <19981124074003.27029.fmail@990.net> 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: 3666 Lines: 84 jeanslee@990.net said: > ello, All developers of lynx: i am a chinese computer programer, > now i read your source code of lynx and want learn something from > it, but i meet many problem, one is there are too many states in the > function SGML_character() (--in SGML.c file) , i can't get all their > means, if you can give me more detail of these states, you will help > me more I don't think anybody has a list of details of SGML_character(), but maybe it will help if you understand the general structure of the program. In Lynx - as in other applications using libWWW - data may come from many different sources. A few of the possible sources are: a local disk file, a HTTP server, a FTP server and a Gopher server. Also, the incoming data may be in several formats, for example HTML and plain text. Finally data may goto to different destinations: it may be rendered to the sreen, or stored on a file. The number of possible combination of source, format and destination is very high. Too high to deal with them in - say - a case statement. Even worse, there may be more steps involved then the three mentioned above, for instance data may be compressed or encrypted. LibWWW solves this complexity by having modules for each of the subtasks - fetching data, parsing data and rendering data. When Lynx opens a connection it determines which steps are required to process the data and it then constructs a chain of modules. LibWWW calls this a "stream". A stream is similar to a Unix pipeline. For example, assume we have a .html file sitting on a FTP server which must be rendered to the screen. If we would have a seperate program for each step then the following Unix pipeline would do the job: ftp_prog | html_parser | screen_renderer If each of the modules would indeed be a seperate program then it could just use standard IO routines to communicate with the other programs in the pipeline. E.g. "html_parser" could use getc() to read data from "ftp_prog" and putc() to write its output to "screen_renderer". But libwww streams are not seperate processes. They are implemented as objects that call one another. Now we have what is known as a "producer consumer" problem; from html_parsers point of view it would be easy if it just could call ftp_prog as a subroutine whenever it needs to PULL a new character from the stream. On the other hand, from ftp_prog's point it view it would be better if it could call html_parser as a subroutine whenever it wants to PUSH a character into the stream. What we really need here are co-routines, not sub-routines. C does not have co-routines which makes things very messy. Since we can not push and pull at the same time libWWW favors the data producers: the producer object - ftp in our example - can call the consumer - html - but not the other way around. Instead the html or SGML module but keep track of where it was in the input stream. This is where all those state variables are for. The reason there are so many of them is that there are a lot of different SGML elements that must be recognized and most of those elements are made up of more than one character. So, if you want to understand what the state variables in SGML.c are for you can best start by learning the syntax of SGML and HTML. Once you understand what SMGL.c is trying to parse you may be able to figure out the details. > another problem is i can not understand how you deal with Unicode, > it seems very complex and difficult, could you explain it for me. I don't under it either... It's been a long time since I seriously looked into SMGL.c and all the Unicode handling has been added in recent years. From owner-lynx-dev@sig.net Tue Nov 24 15:10:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA07724 for ; Tue, 24 Nov 1998 15:10:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA01541; Tue, 24 Nov 1998 13:47:17 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 22:42:59 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev GridText.c patch with new HText_trimHightext 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: 11631 Lines: 318 24-Nov-98 05:00 Klaus Weide wrote: > Here is a patch which hopefully removes problems with form field > display during partial rendering. Please test. Thanks, it works! I've just removed "disable_trace" flag because it is redundant now: HText_trimHightext never trim the same anchor twice. (I haven't removed `detected_forms_input_partial' yet, but it now redundant also) Resync against _dev.7_ included, for Tom. > I still think that changing the highlight() call in display_page() to > if (display_partial) > highlight(OFF, (nlinks - 1), target); > and NOT calling HText_trimHightext() during partial rendering may > also solve the problems, but have not tested it. Wrong. You got a blinking hightext garbage line on the top of the display if you do so. I would also note that forms field looks differently with/without highlighted text ("____" normally and "...." if no hightext), we got such blinking without calls to HText_trimHightext before dispaly_page(). > * HText_trimHightext (GridText.c): don't apply final adjustment > repeatedly to an anchor that has already been handled by this > function; the function may be called repeatedly if partial display > is enabled. Some other changes in this function, to interact > better with the other GridText.c functions, especially for partial > display mode. We don't have to handle all anchors if the new > parameter "final" is not set. > Also empty anchors should now generally not any more move down over > empty lines, if they happen at a line end. Made some trace messages > give more information. > * color styles: reset screen style cache to avoid random coloring > when a link is unhighlighted. > * Tweak in HText_setLastOptionValue: if an OPTION tag was directly > followed by several newlines, characters could be dropped. diff -u old/gridtext.c ./gridtext.c --- old/gridtext.c Tue Nov 24 01:21:48 1998 +++ ./gridtext.c Tue Nov 24 22:09:44 1998 @@ -61,6 +61,17 @@ for (j=0;jtop_of_screen = line_number; display_title(text); /* will move cursor to top of screen */ display_flag=TRUE; @@ -3274,7 +3289,7 @@ * Fix up the anchor structure values and * create the hightext strings. - FM */ - HText_trimHightext(text, FALSE); + HText_trimHightext(text, TRUE); } @@ -3286,25 +3301,37 @@ ** `Forms input' fields cannot be displayed properly without this function ** to be invoked (detected in display_partial mode). ** -** (BOOLEAN value allow us to disable annoying repeated trace messages -** for display_partial mode). +** If final is set, this is the final fixup; if not set, we don't have +** to do everything because there should be another call later. +** +** BEFORE this function has treated a TextAnchor, its line_pos and +** extent fields are counting bytes in the HTLine data, including +** invisible special attribute chars and counting UTF-8 multibyte +** characters as multiple bytes. +** AFTER the adjustment, the anchor line_pos (and hightext2offset +** if applicable) fields indicate x positions in terms of displayed +** character cells, and the extent field apparently is unimportant; +** the anchor text has been copied to the hightext (and possibly +** hightext2) fields (which should be NULL up to this point), with +** special attribute chars removed. +** This needs to be done so that display_page finds the anchors in the +** form it expects when it sets the links[] elements. */ PUBLIC void HText_trimHightext ARGS2( HText *, text, - BOOLEAN, disable_trace) + BOOLEAN, final) { int cur_line, cur_char, cur_shift; TextAnchor *anchor_ptr; + TextAnchor *prev_a = NULL; HTLine *line_ptr; unsigned char ch; if (!text) return; - CTRACE(tfp,"Gridtext: Entering HText_trimHightext\n"); - - if (disable_trace) - CTRACE(tfp,"HText_trimHightext: trace disabled in display_partial mode\n"); + CTRACE(tfp,"Gridtext: Entering HText_trimHightext %s\n", + final ? "(final)" : "(partial)"); /* * Get the first line. @@ -3312,37 +3339,71 @@ line_ptr = text->last_line->next; cur_char = line_ptr->size; cur_line = 0; - cur_shift = 0; /* * Fix up the anchor structure values and * create the hightext strings. - FM */ for (anchor_ptr = text->first_anchor; - anchor_ptr; anchor_ptr=anchor_ptr->next) { + anchor_ptr; + prev_a = anchor_ptr, anchor_ptr=anchor_ptr->next) { re_parse: /* * Find the right line. */ - for (; anchor_ptr->start >= cur_char; + for (; anchor_ptr->start > cur_char; line_ptr = line_ptr->next, cur_char += line_ptr->size+1, cur_line++) { ; /* null body */ } + + if (!final) { + /* + * If this is not the final call, stop when we have reached + * the last line, or the very end of preceding line. + * The last line is probably still not finished. - kw + */ + if (cur_line >= text->Lines) + break; + if (anchor_ptr->start >= text->chars - 1) + break; + /* + * Also skip this anchor if it looks like HText_endAnchor + * is not yet done with it. - kw + */ + if (!anchor_ptr->extent && anchor_ptr->number && + (anchor_ptr->link_type & HYPERTEXT_ANCHOR) && + !anchor_ptr->show_anchor && + anchor_ptr->number == text->last_anchor_number) + continue; + } + + /* + * If hightext has already been set, then we must have already + * done the trimming & adjusting for this anchor, so avoid + * doing it a second time. - kw + */ + if (anchor_ptr->hightext) + continue; + if (anchor_ptr->start == cur_char) { anchor_ptr->line_pos = line_ptr->size; } else { anchor_ptr->line_pos = anchor_ptr->start - (cur_char - line_ptr->size); } - if (anchor_ptr->line_pos < 0) + if (anchor_ptr->line_pos < 0) { + anchor_ptr->start -= anchor_ptr->line_pos; anchor_ptr->line_pos = 0; + anchor_ptr->line_num = cur_line; + } + CTRACE(tfp, + "Gridtext: Anchor found on line:%d col:%d [%d] ext:%d\n", + cur_line, anchor_ptr->line_pos, + anchor_ptr->number, anchor_ptr->extent); - if (!disable_trace) - CTRACE(tfp, "Gridtext: Anchor found on line:%d col:%d\n", - cur_line, anchor_ptr->line_pos); - + cur_shift = 0; /* * Strip off any spaces or SpecialAttrChars at the beginning, * if they exist, but only on HYPERTEXT_ANCHORS. @@ -3360,22 +3421,29 @@ if (anchor_ptr->extent < 0) { anchor_ptr->extent = 0; } + anchor_ptr->start += cur_shift; - if (!disable_trace) CTRACE(tfp, "anchor text: '%s'\n", line_ptr->data); /* * If the link begins with an end of line and we have more * lines, then start the highlighting on the next line. - FM - */ - if ((unsigned)anchor_ptr->line_pos >= strlen(line_ptr->data) && - cur_line < text->Lines) { - anchor_ptr->start += (cur_shift + 1); - cur_shift = 0; - CTRACE(tfp, "found anchor at end of line\n"); - goto re_parse; + * But if an empty anchor is at the end of line and empty, + * keep it where it is, unless the previous anchor in the list + * (if any) already starts later. - kw + */ + if ((unsigned)anchor_ptr->line_pos >= strlen(line_ptr->data)) { + if (cur_line < text->Lines && + (anchor_ptr->extent || + anchor_ptr->line_pos != (int)line_ptr->size || + (prev_a && prev_a->start > anchor_ptr->start))) { + anchor_ptr->start++; + CTRACE(tfp, "found anchor at end of line\n"); + goto re_parse; + } else { + CTRACE(tfp, "found anchor at end of line, leaving it there\n"); + } } - cur_shift = 0; /* * Copy the link name into the data structure. @@ -3395,6 +3463,13 @@ */ if ((unsigned)anchor_ptr->extent > strlen(anchor_ptr->hightext)) { HTLine *line_ptr2 = line_ptr->next; + + if (!final) { + if (cur_line + 1 >= text->Lines) { + FREE(anchor_ptr->hightext); /* bail out */ + break; + } + } /* * Double check that we have a line pointer, * and if so, copy into hightext2. @@ -3439,9 +3514,9 @@ anchor_ptr->line_pos += line_ptr->offset; anchor_ptr->line_num = cur_line; - if (!disable_trace) - CTRACE(tfp, "GridText: add link on line %d col %d in HText_trimHightext\n", - cur_line, anchor_ptr->line_pos); + CTRACE(tfp, "GridText: add link on line %d col %d [%d] %s\n", + cur_line, anchor_ptr->line_pos, + anchor_ptr->number, "in HText_trimHightext"); /* * If this is the last anchor, we're done! @@ -4101,11 +4176,11 @@ ** So we start HText_trimHightext() to forget this side effect. ** This function was split-out from HText_endAppend(). ** It may not be the best solution but it works. - LP - ** (TRUE = to disable annoying repeated trace messages) ** - ** Side effect is reported from multiply call of HText_trimHightext. + ** (FALSE = indicate that we are in partial mode) + ** Multiply calls of HText_trimHightext works without problem now. */ - HText_trimHightext(HTMainText, TRUE); + HText_trimHightext(HTMainText, FALSE); } detected_forms_input_partial = FALSE; #endif @@ -6216,6 +6291,14 @@ new_ptr->name = NULL; new_ptr->cp_submit_value = NULL; new_ptr->next = NULL; + /* + * Find first non-space again, convert_to_spaces above may have + * changed the string. - kw + */ + cp = value; + while (isspace((unsigned char)*cp) || + IsSpecialAttrChar((unsigned char)*cp)) + cp++; for (i = 0, j = 0; cp[i]; i++) { if (cp[i] == HT_NON_BREAK_SPACE || cp[i] == HT_EM_SPACE) { diff -u old/gridtext.h ./gridtext.h --- old/gridtext.h Wed Oct 14 05:23:56 1998 +++ ./gridtext.h Tue Nov 24 21:05:18 1998 @@ -202,7 +202,7 @@ InputFieldData *I)); extern void HText_trimHightext PARAMS(( HText * text, - BOOLEAN disable_trace)); + BOOLEAN final)); extern void HText_SubmitForm PARAMS(( FormInfo * submit_item, document * doc, From owner-lynx-dev@sig.net Tue Nov 24 15:15:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA08303 for ; Tue, 24 Nov 1998 15:15:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA02494; Tue, 24 Nov 1998 13:50:33 -0600 (CST) Date: Tue, 24 Nov 1998 13:52:58 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: "Norman L. DeForest" Subject: Re: lynx-dev Mis-numbering of links... 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: 2385 Lines: 63 On Tue, 24 Nov 1998, David L. Potter wrote: > Our version of Lynx... (which we call) > > Lynx Version 2.7.1ac-0.102+intl+csuite > > produces a rather curious result in some rather narrow circumstances. The > behaviour was first detected on a Chinese Language page... and has > subsequently been duplicated on an English page... a screen print of > which is below... as a start you'll notice there are two links > numbered '[3]'... > > ====================================================================== > > Bug Demo. > _________________________________________________________________ > > [1] xxxxx_this_is_length_critical_xxxxxxxxxxxxxxxxxxxxxxxxxx???? | > BOFH [3] [3] [4] [=||=] > _________________________________________________________________ > > Above, the link number for link # 2 is missing. Any of the "?"s may be > deleted from the "length-critical" string and the bug persists. Add > one more character to the string or delete more than four characters > and the bug disappears. The problem seems to be that lynx gets > confused if: > 1. a link number is to be at the end of one line with the label > wrapped to the line below that and > 2. a link following the link to be wrapped has no label specified and > 3. the link with no label is on the same line as the wrapped label. > > Also, some link numbers get duplicated and the first duplicate in a > pair seems to have its URL listed as "hidden" with the others listed > as "visible". > http://www.chebucto.ns.ca/~af380/bug-demo.html I cannot reproduce this with either 2.8.1rel.2 or 2.7.1ac-0.91. I have seen some glitches w.r.t. line splitting and removing of link numbers, but nothing like this where a number appears twice. What happens if you use -hiddenlinks=merge, -hiddenlinks=ignore, -hiddenlinks=listonly (if your code has that option)? You should check whether your code differs from the latest lynx (see if you just want a few files), specifically: * HText_endAnchor() in GridText.c, * split_line() in GridText.c, especially the loop over anchors at the end, and, if that doesn't yield anything, * all calls to HText_beginAnchor() and HText_endAnchor() in HTML.c, and maybe LYCharUtils.c. Klaus From owner-lynx-dev@sig.net Tue Nov 24 15:19:32 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA08388 for ; Tue, 24 Nov 1998 15:19:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA04449; Tue, 24 Nov 1998 13:57:00 -0600 (CST) From: Philip Webb Message-Id: <199811241957.OAA22822@chass.utoronto.ca> Subject: lynx-dev SGML.c revealed! To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 14:57:57 -0500 (EST) In-Reply-To: <12850888.911933192@yeti.ftu.nl> from "Dick Wesseling" at Nov 24, 98 07:46:32 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: 514 Lines: 10 981124 Dick Wesseling gave lynx-dev a masterful account of an important part of the structure of Lynx source code. occasionally, someone does this for an area s/he is familiar with & these lessons need to be collected as a resource for everyone. -- ========================,,============================================ 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 Nov 24 15:39:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA09814 for ; Tue, 24 Nov 1998 15:39:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA10737; Tue, 24 Nov 1998 14:18:51 -0600 (CST) Date: Tue, 24 Nov 1998 14:21:10 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev SGML.c (was Re: Please help me!) In-Reply-To: <12850888.911933192@yeti.ftu.nl> 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: 1864 Lines: 45 On Tue, 24 Nov 1998, Dick Wesseling wrote: > jeanslee@990.net said: > > ello, All developers of lynx: i am a chinese computer programer, > > now i read your source code of lynx and want learn something from > > it, but i meet many problem, one is there are too many states in the > > function SGML_character() (--in SGML.c file) , i can't get all their > > means, if you can give me more detail of these states, you will help > > me more > > I don't think anybody has a list of details of SGML_character(), but > maybe it will help if you understand the general structure of the > program. [ snipped ] That was a nice overview. Also, for introduction, some of the documentation for the current libwww still applies to lynx, at least the stuff about Streams, in: (but much is different, it may be too confusing to try to use it as a reference for details of the lynx code.) If the goal is to understand the basic ideas of SGML.c, it is probably more useful to look at an earlier version of lynx (say, 2.6 or earlier), or, for a still leaner version, at the one from libwww: . > > another problem is i can not understand how you deal with Unicode, > > it seems very complex and difficult, could you explain it for me. > > I don't under it either... It's been a long time since I seriously > looked into SMGL.c and all the Unicode handling has been added in > recent years. Yes it is ugly (although probably better than I left it after first adding the chartrans stuff). It may halp to first imagine that all incoming characters are pure ASCII so that all the translations shouldn't apply (or should give a trivial result), and follow the code for that case. Klaus From owner-lynx-dev@sig.net Tue Nov 24 16:00:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA11668 for ; Tue, 24 Nov 1998 16:00:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA15338; Tue, 24 Nov 1998 14:35:10 -0600 (CST) Date: Tue, 24 Nov 1998 14:37:34 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net cc: Stanislav Brabec Subject: Re: lynx-dev lynx --enable-color-style causes fp error In-Reply-To: <9811241118.AA6343@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: 289 Lines: 9 On Tue, 24 Nov 1998, Larry W. Virden wrote: > The color styles code is experimental, which means that on some platforms > it tends to crash immediately... Yeah, but I'd be interested to know where and why it crashes on linux, and why that's a "floating point exception" crash. Klaus From owner-lynx-dev@sig.net Tue Nov 24 17:22:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA17279 for ; Tue, 24 Nov 1998 17:22:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00847; Tue, 24 Nov 1998 15:27:17 -0600 (CST) To: lynx-dev@sig.net References: <3.0.5.32.19981124180454.00938260@10.0.10.15> <3.0.5.32.19981123155647.0092f100@10.0.10.15> Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 23:49:13 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Queries and problems 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: 1108 Lines: 26 > > I managed to finally get the help files to be read from the local Hard > Disk.However, I am not able to customise the colour aspect of lynx.I am > running the win32 2.8.1 version of lynx on my windows NT 4.0 workstation.I > have spent almost a couple of hours tinkering with it, however, to no well, there is no MS-Windows interface in lynx to choose color or other settings by clicking the mouse yet. BTW, people, is it possible to made a new internal page with color palette for different pairs so the user could write "magic words" to a paper and change lynx.cfg accordingly. Keeping in mind that ncurses and slang have entirely different default colors. > satisfactory end result.I have only managed to change the background to > black and text to blue, which has become extremely difficult to read.Worst > still, I do not know how I did it.Pls. Help me with colour aspect of Lynx. keep a backup copy of lynx.cfg > Success is relative: It is what we can make of the mess we made of things. > --- T.S.Eliot Ask Tomas Eliot. From owner-lynx-dev@sig.net Tue Nov 24 17:34:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA17989 for ; Tue, 24 Nov 1998 17:34:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00813; Tue, 24 Nov 1998 15:27:11 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Tue, 24 Nov 1998 23:00:14 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) 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: 718 Lines: 14 >> Anyway, bzip2 has made tremendous strides since this discussion began >> over a year ago. With the speed of decompression bzip2 has achieved, I >> strongly urge that Lynx be modified to properly handle bzip2-compressed >> files. The appended patch, granted not done in decent programming style, >> will allow that support for http-served files. (Thanks to Bela!) > I think that code should be #ifdef'd, since we cannot expect everyone > to have bzip2. (We seem to be making that assumption about gzip.) Autoconf find the bzip2_path and it is not a big problem to check the existanse of bzip2_path/bzip2, isn't it? (and DOS/WIN looks executables in several directories from the $PATH, this is another story) From owner-lynx-dev@sig.net Tue Nov 24 17:37:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA18244 for ; Tue, 24 Nov 1998 17:37:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00885; Tue, 24 Nov 1998 15:27:20 -0600 (CST) To: lynx-dev@sig.net References: <12850888.911933192@yeti.ftu.nl> Message-Id: From: "Leonid Pauzner" Date: Wed, 25 Nov 1998 00:11:56 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Please help me! 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: 1330 Lines: 31 > jeanslee@990.net said: >> ello, All developers of lynx: i am a chinese computer programer, >> now i read your source code of lynx and want learn something from >> it, but i meet many problem, one is there are too many states in the >> function SGML_character() (--in SGML.c file) , i can't get all their >> means, if you can give me more detail of these states, you will help >> me more > I don't think anybody has a list of details of SGML_character(), but > maybe it will help if you understand the general structure of the > program. > In Lynx - as in other applications using libWWW - data may come from > many different sources. A few of the possible sources are: a local > disk file, a HTTP server, a FTP server and a Gopher server. You may look also a newer version of libwww (5.2) at http://www.w3.org/Library/User/ it is very nice documented. Of cause, lynx use libwww 2.14 heavy altered, so expect a great difference but general structure have a common genesis. >> another problem is i can not understand how you deal with Unicode, >> it seems very complex and difficult, could you explain it for me. Lynx store data in bytes, basically unicodes like { and   converted to bytes (in display's current_char_set) inside SGML.c Multibyte chars (CJK, UTF-8) handled differently, I do not know details. From owner-lynx-dev@sig.net Tue Nov 24 17:38:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA18263 for ; Tue, 24 Nov 1998 17:38:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00955; Tue, 24 Nov 1998 15:27:28 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 25 Nov 1998 00:26:43 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev on caching (long) 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: 4698 Lines: 94 > There are two places where we may look for guidance: > * The HTTP protocol itself. > * Newer versions of libwww. > Since HTTP is engineered to support cacheing, and is quite detailed about it, > it may tell us a lot about what kinds of requests a level of a cache > hierarchy can make - what kinds of parameters are needed, what modes of > operation one could think of etc. With necessary modifications of course, > for the program-internal rather than over-the-network case. Note that > HTTP caching is completely based on the style B communication (above). > (Squid caches talking ICP with each other are something else.) > In libwww 5.2, I find in : Well, I am highly impressed with libwww 5.2, it was completely rewritten and now the code clean and well documented (I especially like User/Architecture/*.html), it also include DNS cache and a persistent document's cache. I think both caches should be a system-wide on multitask/multiuser system (it is not an user-agent job, otherwise we got obvious wasting or resources: different user-agents, different versions, etc.), all we need is a "history" calls without any revalidation, think there is no such standard calls for arbitrary system-wide cache. So we need a user-agent's feature: we already have rendered document's cache (in-memory) and also need in-memory cache for sources for "mode 2" calls only. And yes, it may be useful to have a persistent cache for "single user" machines as optional (mainly for non-UNIX ports). I am not optimistic in moving Lynx to libwww 5.2 - although they are mutually similar there are lots of differences (chartrans implementation, for example), this is a long-standing work for guru. Also new libwww have a different documentations/comments style: lynx's code looks hairy but self-documented (some how). Is it possible to implement a _part_ of new libwww, its HTTP/1.1 core including cache ? > Currently the caching-related request vocabulary already consists of a bunch > of flags: `reloading', `LYforce_no_cache', `LYoverride_no_cache', > `LYinternal_flag', ..., text->no_cache, anchor->no_cache, in conjunction with > various other bits and pieces. This is very confusing. These are all needed > so HTLoadDocument() (& friends) can make a decision what to do. Now imagine > what happens if we add another cache level. Or just modify or enhance the > current cache's behavior. > Again, putting more of the decision making in mainloop() may seem an easy way > out; I think instead there is an urgent need to rationalise the language, > before much gets added cachewise. > ------------ snip ------------ > HTTP Cache Validation and Cache Control > The Library has two concepts of caching: in memory and on file. When loading a document, > this flag can be set in order to define who can give a response to the request. The > mempory buffer is considered to be equivalent to a history buffer. That is, it doesn't not > follow the same expiration mechanism that is characteristic for a persistent file cache. > You can also set the cache to run in disconnected mode - see the [23]Cache manager for > more details on how to do this. > typedef enum _HTReload { > HT_CACHE_OK = 0x0, /* Use any version available */ > HT_CACHE_FLUSH_MEM = 0x1, /* Reload from file cache or network */ > HT_CACHE_VALIDATE = 0x2, /* Validate cache entry */ > HT_CACHE_END_VALIDATE = 0x4, /* End to end validation */ > HT_CACHE_RANGE_VALIDATE = 0x8, > HT_CACHE_FLUSH = 0x10, /* Force full reload */ > HT_CACHE_ERROR = 0x20 /* An error occurred in the cache */ > } HTReload; > extern void HTRequest_setReloadMode (HTRequest *request, HTReload mode); > extern HTReload HTRequest_reloadMode (HTRequest *request); > ------------ snip ------------ > He, that looks just like what we need! Instead of setting many variables > mainloop() and other higher-level functions could just set one request > variable to the right value, using max() if appropriate, to bump up the, > hmm, nocache-nature of a request. > Rough correspondence to current flags (omitting the two that may not really > belong here): > HT_CACHE_OK default or LYoverride_no_cache > HT_CACHE_FLUSH_MEM LYforce_no_cache, text->nocache > HT_CACHE_VALIDATE > HT_CACHE_END_VALIDATE > HT_CACHE_FLUSH `reloading' > Well, the correspondence isn't a direct one. But I think something like > this should replace the current flags as far as possible. With added > values if we need more. From owner-lynx-dev@sig.net Tue Nov 24 19:39:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA25904 for ; Tue, 24 Nov 1998 19:39:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA12679; Tue, 24 Nov 1998 18:14:26 -0600 (CST) Date: Tue, 24 Nov 1998 12:44:19 -0400 (AST) From: "David L. Potter" To: "Larry W. Virden" cc: "Norman L. DeForest" , lynx-dev@sig.net Subject: Re: lynx-dev Mis-numbering of links... In-Reply-To: <199811241616.LAA06332@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: 487 Lines: 16 OK Larry looks like it's ok. Thanks for having a look at this! david potter (dlp asked... is ur screen set to 80...) On Tue, 24 Nov 1998, Larry W. Virden wrote: > yes, 80 columns by 42 lines > -- > Larry W. Virden >In heaven, there is no panic, > <*> O- | only planning. > 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 Nov 24 21:09:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA31307 for ; Tue, 24 Nov 1998 21:09:48 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA28928; Tue, 24 Nov 1998 19:45:07 -0600 (CST) Date: Wed, 25 Nov 1998 10:48:38 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811250148.KAA19435@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1066 Lines: 22 > > ! if (!strcasecomp(anchor->content_encoding, "x-bzip2") || > > ! !strcasecomp(anchor->content_encoding, "bzip")) { > > Do you mean "bzip2" here? Or do we need all four of "bzip", "x-bzip", Yes, "bzip2", but if I were more confident I would keep only "x-bzip2". Personally, I see no need for both, and if there is general agreement, I would like to see the OR left out and only support "x-bzip2". > Does anyone volunteer to officially register one of the forms, or at > least ask the author about it? It probably would require writing an RFC, > but then at least everyone could know what to put in a Content-Encoding I won't be doing it myself (note this is only to HTFWriter in /src, and not in WWW/Library/Implementation) because bzip2 is less of an application now than it is a library. The author, AFAIK, is more interested in the algorithms being used in library form and wrapped in any number of interfaces, e.g., Lynx, the way zlib was done. I am not a programmer, and only have time for quick hacks to fulfill my own needs. Sorry. __Henry From owner-lynx-dev@sig.net Tue Nov 24 21:14:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA31686 for ; Tue, 24 Nov 1998 21:14:27 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00078; Tue, 24 Nov 1998 19:51:39 -0600 (CST) Date: Wed, 25 Nov 1998 10:55:19 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811250155.KAA19509@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Mis-numbering of links... Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1470 Lines: 45 > Here is the original Chinese Page: > > http://www.cnnic.cn/cgi-bin/domainqc I have my O)ptions set to CJK, and displayed the above link without event using Lynx 2.8.2dev.7. The P)rint to file is appended. __Henry [1][dirc.jpg] $BSrC{2iQ/(J $B=+TZ(JCNNIC$B5DSrC{W"2a?bVP#,2iQ/DzJdHk5DSrC{!#@}Hg(J : xxx.xxx.cn ($B=+2i3vSrC{(Jxxx.xxx.cn$B5DO`9XDZH](J) _________________________________________________________________ $BSISZSC;'PEO"2;Oj#,IPSPIYA?RQW"2aSrC{N4]?b7~Nq(J | [5]$BPEO"7~Nq(J | [6]$BVP9z5<:=(J | [7]CNNIC [8][w.JPG]-[9][w.JPG] References Visible links 1. http://www.cnnic.net.cn/cnnic/images/dirc.jpg 2. http://www.cnnic.net.cn/cnnic/contact.html 3. http://www.cnnic.net.cn/cnnic/reg/index.html 4. http://www.cnnic.net.cn/cgi-bin/domainqc 5. http://www.cnnic.net.cn/cnnic/info/index.html 6. http://www.cnnic.net.cn:802/navichina.html 7. http://www.cnnic.net.cn/intro.html 8. http://www.cnnic.net.cn/ 9. http://www.cnnic.net.cn/cnnic/images/w.JPG Hidden links: 10. http://www.cnnic.net.cn/cnnic/china.html 11. http://www.cnnic.net.cn/cnnic/china.html From owner-lynx-dev@sig.net Tue Nov 24 21:16:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA31935 for ; Tue, 24 Nov 1998 21:16:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA00421; Tue, 24 Nov 1998 19:53:39 -0600 (CST) From: dickey@clark.net Message-Id: <199811250156.UAA09170@shell.clark.net> Subject: Re: lynx-dev on caching (long) To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 20:56:06 -0500 (EST) In-Reply-To: from "Leonid Pauzner" " at Nov 25, 98 00:26: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: 1595 Lines: 35 > > hierarchy can make - what kinds of parameters are needed, what modes of > > operation one could think of etc. With necessary modifications of course, > > for the program-internal rather than over-the-network case. Note that > > HTTP caching is completely based on the style B communication (above). > > (Squid caches talking ICP with each other are something else.) > > > In libwww 5.2, I find in : > > Well, I am highly impressed with libwww 5.2, > it was completely rewritten and now the code clean and well documented otoh, using it would require rewriting large chunks of lynx - since lynx and the libwww have diverged. > I am not optimistic in moving Lynx to libwww 5.2 - > although they are mutually similar there are lots of differences > (chartrans implementation, for example), this is a long-standing work > for guru. Also new libwww have a different documentations/comments style: > lynx's code looks hairy but self-documented (some how). yes. that, the integration with local filesystems (Fote made some comments about the dired mode). It probably doesn't port well - the impression I get is that it's not well tested outside of GNU C and make. > Is it possible to implement a _part_ of new libwww, > its HTTP/1.1 core including cache ? You would probably have to restructure the existing lynx, move the newer (Lynx-specific or enhanced) functions out of libwww and align the remaining libwww with the libwww 5. That's a lot of work. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Tue Nov 24 21:48:19 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA01057 for ; Tue, 24 Nov 1998 21:48:18 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA05916; Tue, 24 Nov 1998 20:23:33 -0600 (CST) Date: Tue, 24 Nov 1998 18:25:56 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) 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: 1015 Lines: 22 On Tue, 24 Nov 1998, Leonid Pauzner wrote: > Autoconf find the bzip2_path and it is not a big problem to check > the existanse of bzip2_path/bzip2, isn't it? > (and DOS/WIN looks executables in several directories from the $PATH, > this is another story) As I mentioned in a previous post, I have ported version 0.1pl2 of bzip2 to DOS/DJGPP, but I have not been successful with the current version (0.9.0b). I think the problem has to do with DJGPP's handling of file descriptors. If anyone who works with DJGPP wants to help with the porting of version 0.9.0b, so that we can keep portability of lynx and its associated features, please write to me off the list. If anyone wants to see the DOS version of bzip2 0.1pl2, I can put it up on my server. Julian Seward, the author of bzip2, was waiting for the port of the current version before making a pointer to the DOS port on his web page. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Tue Nov 24 22:19:44 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA03525 for ; Tue, 24 Nov 1998 22:19:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA10783; Tue, 24 Nov 1998 20:54:05 -0600 (CST) Date: Tue, 24 Nov 1998 21:56:28 -0500 From: Jean-Pierre Radley To: lynx-dev@sig.net Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) Message-ID: <19981124215628.A23348@jpradley.jpr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: ; from Doug Kaufman on Tue, Nov 24, 1998 at 06:25:56PM -0800 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 696 Lines: 12 Doug Kaufman averred (on Tue, Nov 24, 1998 at 06:25:56PM -0800): | As I mentioned in a previous post, I have ported version 0.1pl2 of | bzip2 to DOS/DJGPP, but I have not been successful with the current | version (0.9.0b). I think the problem has to do with DJGPP's handling | of file descriptors. If anyone who works with DJGPP wants to help with | the porting of version 0.9.0b, so that we can keep portability of | lynx and its associated features, please write to me off the list. For the same price of admission, you might as well deal with the current version, which isn't bzip2-0.9.0b, but bzip2-0.9.0c. -- Jean-Pierre Radley XC/XT Custodian Sysop, CompuServe SCOForum From owner-lynx-dev@sig.net Tue Nov 24 22:35:56 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA04533 for ; Tue, 24 Nov 1998 22:35:55 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA13796; Tue, 24 Nov 1998 21:11:41 -0600 (CST) Message-Id: <199811250309.VAA01378@thune.mrc.org> Subject: Re: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 21:09:57 -0600 (CST) In-Reply-To: <199811241007.FAA27701@shell.clark.net> from "dickey@clark.net" at Nov 24, 98 05:07:21 am From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 638 Lines: 15 Amazingly enough dickey@clark.net said: > > On Sun, 22 Nov 1998, Ilya Zakharevich wrote: > > > #define REMOVE_KEY 269 /* 0x10D */ > > > -#define DO_NOTHING 270 /* 0x10E */ > > > +#define MOUSE_KEY 270 /* 0x10E */ > > > +#define DO_NOTHING 271 /* 0x10F */ Just as a matter of programming style, would this not be better implemented as an enum? mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Wed Nov 25 00:07:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA10199 for ; Wed, 25 Nov 1998 00:07:50 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA28498; Tue, 24 Nov 1998 22:38:43 -0600 (CST) Message-Id: <199811250440.WAA01662@thune.mrc.org> Subject: Re: lynx-dev on caching (long) To: lynx-dev@sig.net Date: Tue, 24 Nov 1998 22:40:09 -0600 (CST) In-Reply-To: <199811250156.UAA09170@shell.clark.net> from "dickey@clark.net" at Nov 24, 98 08:56:06 pm From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 819 Lines: 20 Amazingly enough dickey@clark.net said: > > Well, I am highly impressed with libwww 5.2, > > it was completely rewritten and now the code clean and well documented > > otoh, using it would require rewriting large chunks of lynx - since > lynx and the libwww have diverged. But, haven't you expressed interest in doing this? For some reason, I'm reminded of the api changes done with the various versions of the IJG's jpeg library. It was nasty, but in the end, application writers did bite the bullet and made the migration. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Wed Nov 25 00:27:21 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA11132 for ; Wed, 25 Nov 1998 00:27:20 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA02425; Tue, 24 Nov 1998 23:00:13 -0600 (CST) From: jeanslee@990.net Date: 25 Nov 1998 01:12:57 -0000 Message-ID: <19981125011257.21615.fmail@990.net> To: lynx-dev@sig.net Subject: lynx-dev a question about the interface of SGML module Content-Transfer-Encoding: 8bit Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 766 Lines: 9 hi, everyone: Dick and Klaus, very thank you for your help ! ^_^ Now i have another qustion about lynx, when i see the source code in SGML.c, i found the input of SGML module is a start postion and the length of a string which include the content of HTML source, but i can not get the structure of output of SGML module, is it only the HTEXT struct which is a field of the HTSTREAM context? and is this HTEXT struct include all Anchor list, form data and the text to output to screen ? Best Regards! jerry 98/25/11 __________________________________________________ »¶Ó­Ê¹ÓýðÁêÈÈÏßÃâ·Ñµç×ÓÓʼþϵͳhttp://www.990.net From owner-lynx-dev@sig.net Wed Nov 25 01:39:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA15460 for ; Wed, 25 Nov 1998 01:39:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA12630; Wed, 25 Nov 1998 00:16:37 -0600 (CST) Message-Id: <199811250617.AAA01699@thune.mrc.org> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 00:17:33 -0600 (CST) In-Reply-To: from "Klaus Weide" at Nov 24, 98 05:33:55 am From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2488 Lines: 46 Amazingly enough Klaus Weide said: > Some configuration values can be rather arbitrary strings, and > you don't need quotes around them (which makes things simpler > if the strings themselves contain quotes). LIST_FORMAT: is a good > example where spaces are significant. If you relax the syntax > now, you have to treat some things specially, and introducing new > such options in the future will be more complicated. I've been giving some thought to the configuration file stuff for a while now. How much change is acceptable for the next minor release? I have a rough overall plan for redoing how configurations are done. Hopefully something that would make adding new configurations easier and provide a lot more orthogonality between the user configuration file and system wide configuration file while still providing backwards compatibility for however long we'd be willing to keep it. Ideally, new installations would use a lynxrc generated by lynx itself then placed into a central location and modified for local use. Basically, I was thinking a configuration table accessed via a series of api's for setting/retrieving the values instead of global variables. Also, the ability the recognize the differences between values loaded from system configuration file, local configuration files, and command line options. We could possibly minimize the size of the user configuration file by saving only values different from global configuration. In the options menu, we could mark items that have runtime values set on the command line that are different from those set in the configuration file, allowing the user the ability to keep the current runtime value, or choose a different one to save into the configuration file. Additionally, we could perhaps have a way of other instances of lynx detect that a new config file has been saved, and automatically load those values so that they take immediate effect. Actually, now that I think about it, even the global vars don't have to be changed. The table could reference which global var to tweak, just the area for setting runtime values from command line, options menu, and configuration files would need to be changed. Thoughts? mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Wed Nov 25 03:03:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA20583 for ; Wed, 25 Nov 1998 03:03:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA20548; Wed, 25 Nov 1998 01:41:50 -0600 (CST) Date: Wed, 25 Nov 1998 16:44:41 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811250744.QAA21964@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev Config file reader [PATCH] Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 193 Lines: 6 > Thoughts? Bela proposed having only one parser for both the lynx.cfg and .lynxrc files. I think it would be great if that could be done. Having two parsers seems like such a waste. __Henry From owner-lynx-dev@sig.net Wed Nov 25 05:52:15 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA30033 for ; Wed, 25 Nov 1998 05:52:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04290; Wed, 25 Nov 1998 04:30:50 -0600 (CST) From: dickey@clark.net Message-Id: <199811251033.FAA23123@shell.clark.net> Subject: Re: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 05:33:17 -0500 (EST) In-Reply-To: <199811250309.VAA01378@thune.mrc.org> from "dalgoda@ix.netcom.com" at Nov 24, 98 09:09:57 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: 711 Lines: 20 > > Amazingly enough dickey@clark.net said: > > > On Sun, 22 Nov 1998, Ilya Zakharevich wrote: > > > > #define REMOVE_KEY 269 /* 0x10D */ > > > > -#define DO_NOTHING 270 /* 0x10E */ > > > > +#define MOUSE_KEY 270 /* 0x10E */ > > > > +#define DO_NOTHING 271 /* 0x10F */ > > Just as a matter of programming style, would this not be better implemented > as an enum? maybe/maybe not - storing enum values as int's doesn't always work well on older compilers (which Lynx builds on). If I saw it as an enum, I'd have to take that into consideration. > Mike Castle Life is like a clock: You can work constantly -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 25 06:04:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA30593 for ; Wed, 25 Nov 1998 06:04:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA05414; Wed, 25 Nov 1998 04:44:43 -0600 (CST) From: dickey@clark.net Message-Id: <199811251047.FAA25034@shell.clark.net> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 05:47:11 -0500 (EST) In-Reply-To: <199811250617.AAA01699@thune.mrc.org> from "dalgoda@ix.netcom.com" at Nov 25, 98 00:17:33 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: 1319 Lines: 31 > > Amazingly enough Klaus Weide said: > > Some configuration values can be rather arbitrary strings, and > > you don't need quotes around them (which makes things simpler > > if the strings themselves contain quotes). LIST_FORMAT: is a good > > example where spaces are significant. If you relax the syntax > > now, you have to treat some things specially, and introducing new > > such options in the future will be more complicated. > > I've been giving some thought to the configuration file stuff for a while > now. > > How much change is acceptable for the next minor release? The degree of change affects the time of the release - either target a near-term release, or go for late February. As Henry notes, Bela (and others) think it's a waste to have two parsers for config info. Putting LYReadCFG.c into table-driven form would go a long way toward that - by letting us move the parser into a single place. btw, LP points out that the help-message isn't gettext'd (it's not trivial since the gettext scheme only works for function calls; the help message is static strings - so that'll take some redesign to make it both i18n and efficient). > Mike Castle Life is like a clock: You can work constantly -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 25 06:08:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA30635 for ; Wed, 25 Nov 1998 06:08:32 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA04970; Wed, 25 Nov 1998 04:39:27 -0600 (CST) From: dickey@clark.net Message-Id: <199811251041.FAA24420@shell.clark.net> Subject: Re: lynx-dev on caching (long) To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 05:41:54 -0500 (EST) In-Reply-To: <199811250440.WAA01662@thune.mrc.org> from "dalgoda@ix.netcom.com" at Nov 24, 98 10:40:09 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: 1339 Lines: 34 > Amazingly enough dickey@clark.net said: > > > Well, I am highly impressed with libwww 5.2, > > > it was completely rewritten and now the code clean and well documented > > > > otoh, using it would require rewriting large chunks of lynx - since > > lynx and the libwww have diverged. > > But, haven't you expressed interest in doing this? sure - incrementally. (as usual, the topic comes up when my queue's full ;-) right now I'm looking at finishing off the two large global changes (gettext and HTSprintf), which will take us up to late December. LP's suggested we put out 2.8.2 when that's done. That would work for me, since I've a short term project that'll make me rather busy for about a month. (Since I got bogged down in HTSprintf, I didn't get a third bugfixes for 2.8.1 put together - I'll try to get that done early next week so we can discuss whether to make a 2.8.1rel.3) > For some reason, I'm reminded of the api changes done with the various > versions of the IJG's jpeg library. I've noticed that - but am not sure that they did finally stabilize. > It was nasty, but in the end, application writers did bite the bullet and > made the migration. > Mike Castle Life is like a clock: You can work constantly -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Wed Nov 25 06:33:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA32339 for ; Wed, 25 Nov 1998 06:33:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA07657; Wed, 25 Nov 1998 05:11:23 -0600 (CST) Date: Wed, 25 Nov 1998 06:13:20 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811250613.AA590@cas.org> Subject: Re: lynx-dev Saner mouse in lynx with ncurses In-Reply-To: <199811251033.FAA23123@shell.clark.net> of Wed, 25 Nov 1998 05:33:17 -0500 (EST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 775 Lines: 15 From: dickey@clark.net >> Just as a matter of programming style, would this not be better implemented >> as an enum? > >maybe/maybe not - storing enum values as int's doesn't always work well >on older compilers (which Lynx builds on). If I saw it as an enum, I'd >have to take that into consideration. The other thing is that, sad to say, enum's just do not give you any advantage in C. In general, C doesn't do any kind of error checking for enums, so it turns out to be the equivalent of defines anyways. -- 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 Nov 25 07:12:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA01841 for ; Wed, 25 Nov 1998 07:12:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA11267; Wed, 25 Nov 1998 05:54:14 -0600 (CST) Date: Wed, 25 Nov 1998 05:56:41 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev C enums (was: Saner mouse in lynx with ncurses) In-Reply-To: <9811250613.AA590@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: 664 Lines: 18 On Wed, 25 Nov 1998, Larry W. Virden wrote: > From: dickey@clark.net > >> Just as a matter of programming style, would this not be better implemented > >> as an enum? > > > >maybe/maybe not - storing enum values as int's doesn't always work well > >on older compilers (which Lynx builds on). If I saw it as an enum, I'd > >have to take that into consideration. > > The other thing is that, sad to say, enum's just do not give you any > advantage in C. In general, C doesn't do any kind of error checking for > enums, so it turns out to be the equivalent of defines anyways. I find them helpful for debugging; gdb shows the symbol when possible. Klaus From owner-lynx-dev@sig.net Wed Nov 25 07:31:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA02997 for ; Wed, 25 Nov 1998 07:31:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12885; Wed, 25 Nov 1998 06:12:02 -0600 (CST) Date: Wed, 25 Nov 1998 07:13:58 -0500 (EST) From: lvirden@cas.org (Larry W. Virden) Message-Id: <9811250713.AA2267@cas.org> Subject: Re: lynx-dev C enums (was: Saner mouse in lynx with ncurses) In-Reply-To: of Wed, 25 Nov 1998 05:56:41 -0600 (CST) To: lynx-dev@sig.net Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 326 Lines: 5 Ah - I wasn't aware that gdb made use of them. That is nice. -- 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 Nov 25 08:25:31 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA06215 for ; Wed, 25 Nov 1998 08:25:30 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA18049; Wed, 25 Nov 1998 07:02:35 -0600 (CST) Date: Wed, 25 Nov 1998 07:05:00 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: lynx-dev avoiding screen refresh after partial display 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: 5880 Lines: 178 Please test the appended patch. Notes: I hope this will also work for slang and for non-Unix. But no promises. The size_change(0) in the initial start_curses() for NCURSES did leave recent_sizechange set (for me), which shouldn't be needed. size_change(0) for slang doesn't set recent_sizechange at all. This may put too much knowledge about partial display into display_page, but it felt safer to put the information (which lines were shown during last partial) with the object that is affected (the HText *) rather than relying on global flags. Leonid: this probably duplicates Newline_partial and NumOfLines_partial, but should work independently of them. I didn't try to follow all the logic involved for them. * Avoid setting recent_sizechange during the very first start_curses call for ncurses. This would result in an unnecessary refresh after loading the first document. * Added logic to display_page to avoid repainting the full screen contents in a specific situation: if it has been called before (for the same lines in the same document) during partial display, and is now being called normally (not during partial display). If this applies, the normal line content is not redrawn, but the title line and form fields are still repainted, and updating of the links structures is always done. There are additional checks for recent_sizechange and a text->stale flag (which was already implemented but unused) to do the full redraw if that may be needed. This should avoid unnecessary screen 'blinking' with curses when partial display is used (which didn't seem to happen with slang). Diff against 2.8.1rel.2. *** lynx2-8-1.orig/src/LYCurses.c Sat Oct 10 15:53:16 1998 --- lynx2-8-1/src/LYCurses.c Tue Nov 24 19:15:05 1998 *************** *** 763,768 **** --- 763,769 ---- } #if defined(SIGWINCH) && defined(NCURSES_VERSION) size_change(0); + recent_sizechange = FALSE; /* prevent mainloop drawing 1st doc twice */ #endif /* SIGWINCH */ #if defined(USE_KEYMAPS) && defined(NCURSES_VERSION) if (-1 == lynx_initialize_keymaps ()) *** lynx2-8-1.orig/src/LYMainLoop.c Sat Oct 24 11:49:07 1998 --- lynx2-8-1/src/LYMainLoop.c Tue Nov 24 19:14:02 1998 *************** *** 1091,1096 **** --- 1091,1098 ---- start_curses(); clear(); refresh_screen = TRUE; /* to force a redraw */ + if (HTMainText) /* to REALLY force it... - kw */ + HText_setStale(HTMainText); recent_sizechange = FALSE; if (user_mode == NOVICE_MODE) { display_lines = LYlines-4; *** lynx2-8-1.orig/src/GridText.c Wed Oct 14 07:23:56 1998 --- lynx2-8-1/src/GridText.c Wed Nov 25 06:20:54 1998 *************** *** 183,188 **** --- 183,192 ---- BOOL in_line_1; /* of paragraph */ BOOL stale; /* Must refresh */ BOOL page_has_target; /* has target on screen */ + #ifdef DISP_PARTIAL + int first_lineno_last_disp_partial; + int last_lineno_last_disp_partial; + #endif HTkcode kcode; /* Kanji code? */ enum grid_state { S_text, S_esc, S_dollar, S_paren, *************** *** 534,539 **** --- 538,552 ---- */ if (display_partial) NumOfLines_partial = 0; /* enable HTDisplayPartial() */ + + /* + * These two fields should only be set to valid line numbers + * by calls of display_page during partial displaying. This + * is just so that the FIRST display_page AFTER that can avoid + * repainting the same lines on the screen. - kw + */ + self->first_lineno_last_disp_partial = + self->last_lineno_last_disp_partial = -1; #endif CTRACE(tfp, "GridText: start HText_new\n"); *************** *** 1045,1050 **** --- 1058,1066 ---- HTAnchor *link_dest_intl = NULL; static int last_nlinks = 0; static int charset_last_displayed = -1; + #ifdef DISP_PARTIAL + int last_disp_partial = -1; + #endif lynx_mode = NORMAL_LYNX_MODE; *************** *** 1065,1070 **** --- 1081,1094 ---- return; } + #ifdef DISP_PARTIAL + if (display_partial || recent_sizechange || text->stale) { + /* Reset them, will be set near end if all is okay. - kw */ + text->first_lineno_last_disp_partial = + text->last_lineno_last_disp_partial = -1; + } + #endif /* DISP_PARTIAL */ + tmp[0] = tmp[1] = tmp[2] = '\0'; text->page_has_target = NO; last_screen = text->Lines - (display_lines - 2); *************** *** 1166,1171 **** --- 1190,1203 ---- #else assert(line != NULL); #endif /* !VMS */ + + #ifdef DISP_PARTIAL + if (!display_partial && + line_number == text->first_lineno_last_disp_partial && + i + line_number <= text->last_lineno_last_disp_partial) + move((i + 2), 0); + else + #endif display_line(line, text); #if defined(FANCY_CURSES) || defined(USE_SLANG) *************** *** 1347,1352 **** --- 1379,1393 ---- } break; } + #ifdef DISP_PARTIAL + if (display_partial) { + /* + * Remember as fully shown during last partial display, + * if it was not the last text line. - kw + */ + last_disp_partial = i + line_number; + } + #endif /* DISP_PARTIAL */ display_flag = TRUE; line = line->next; } /* end of "Verify and display each line." loop */ *************** *** 1539,1544 **** --- 1580,1597 ---- */ addstr("\n Document is empty"); } + + #ifdef DISP_PARTIAL + if (display_partial && display_flag && + last_disp_partial >= text->top_of_screen && + !recent_sizechange) { /* really remember them if ok - kw */ + text->first_lineno_last_disp_partial = text->top_of_screen; + text->last_lineno_last_disp_partial = last_disp_partial; + } else { + text->first_lineno_last_disp_partial = + text->last_lineno_last_disp_partial = -1; + } + #endif /* DISP_PARTIAL */ if (HTCJK != NOCJK || text->T.output_utf8) { /* From owner-lynx-dev@sig.net Wed Nov 25 09:11:36 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA09531 for ; Wed, 25 Nov 1998 09:11:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA25946; Wed, 25 Nov 1998 07:53:22 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Wed, 25 Nov 1998 08:55:52 -0500 (EST) From: Ismael Cordeiro X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev bzip2 compressed files (was Re: NLS tweaks for 282dev4) 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: 803 Lines: 21 On Tue, 24 Nov 1998, Doug Kaufman wrote: > As I mentioned in a previous post, I have ported version 0.1pl2 of bzip2 > to DOS/DJGPP, but I have not been successful with the current version > (0.9.0b). I was having problems compiling bzip2-0.9.0c on FreeBSD and I contacted Julian Seward. He suggested me to use gcc -O -o bzip2 bzip2.c blocksort.c huffman.c crctable.c randtable.c compress.c decompress.c bzlib.c and it worked. 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 Wed Nov 25 12:43:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA23938 for ; Wed, 25 Nov 1998 12:43:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA21569; Wed, 25 Nov 1998 11:12:18 -0600 (CST) To: lynx-dev@sig.net References: Message-Id: From: "Leonid Pauzner" Date: Wed, 25 Nov 1998 19:51:19 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev avoiding screen refresh after partial display 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: 1206 Lines: 28 > Please test the appended patch. > Notes: > I hope this will also work for slang and for non-Unix. But no promises. > The size_change(0) in the initial start_curses() for NCURSES did leave > recent_sizechange set (for me), which shouldn't be needed. size_change(0) > for slang doesn't set recent_sizechange at all. Thanks, that was a problem. > This may put too much knowledge about partial display into display_page, > but it felt safer to put the information (which lines were shown during > last partial) with the object that is affected (the HText *) rather than > relying on global flags. Leonid: this probably duplicates Newline_partial > and NumOfLines_partial, but should work independently of them. I didn't > try to follow all the logic involved for them. I will look more closely, but now I feel a problem: besides just viewing the incremental rendering we may also scroll the screen by scroll keys in partial mode. It require a complete page redisplay but I think it will not. Newline_partial and NumOfLines_partial also used in LYpop() and LYpop_num(), so they should be global (unless we add them to `document' struct which will add more confision and unnecessary complication.) From owner-lynx-dev@sig.net Wed Nov 25 14:40:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA31924 for ; Wed, 25 Nov 1998 14:40:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA22837; Wed, 25 Nov 1998 13:10:08 -0600 (CST) From: Philip Webb Message-Id: <199811251911.OAA03331@chass.utoronto.ca> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 14:11:01 -0500 (EST) In-Reply-To: <199811250617.AAA01699@thune.mrc.org> from "Mike Castle" at Nov 25, 98 00:17:33 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: 1070 Lines: 21 981125 Mike Castle wrote: > I've been giving some thought to the configuration file stuff. > I have a rough overall plan for redoing how configurations are done. > How much change is acceptable for the next minor release? -- big snip -- there was some debate a couple of months ago (cp the Archive) about updating the whole set of choices in configuration, userdefs.h , lynx.cfg , run-time switches & the new on-line Options form, one aim being to make everything which is not security-related changeable on-line & saveable longer-term if desired. so the first step is to review the whole list of choices everywhere & decide which ones present no security problems; the second step will then be to bring the last 3 methods into alignment, with appropriate methods of saving in the Options form. -- ========================,,============================================ 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 Nov 25 16:06:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA05090 for ; Wed, 25 Nov 1998 16:06:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA16960; Wed, 25 Nov 1998 14:46:09 -0600 (CST) Date: Wed, 25 Nov 1998 20:48:02 +0000 (GMT) From: Georges El Asmar X-Sender: aspggea@atlas To: lynx-dev@sig.net Subject: lynx-dev auto uncaching 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: 333 Lines: 7 Hi everybody, concerning lynx-2.8: once a document is requested and has been cached, is there a way to prevent lynx from getting the same document from the cache ( besides the no cache command ie ^r) and instead send at least a request to check if the document has been modified. This is the behavior of netscape..good bye. georges From owner-lynx-dev@sig.net Wed Nov 25 16:33:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA07079 for ; Wed, 25 Nov 1998 16:33:33 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA24086; Wed, 25 Nov 1998 15:15:44 -0600 (CST) Date: Wed, 25 Nov 1998 16:01:39 -0500 From: Gail Strickler Subject: lynx-dev (no subject) To: lynx-dev@sig.net Message-id: <365C7033.AC0DCE7C@binah.cc.brandeis.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.03 [en] (WinNT; I) 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: 917 Lines: 22 hi--i can access the internet (with my 386 dos computer and kermit)by dialing into my university's mainframe and logging on to the VAX system there. my question is this: from the vax, using lynx, can i read my email from my email account with altavista? or do i have to get onto a p.c. that has web-based internet access? the issue is: i have the latter at work, and thus have the altavista email account, but only have an dos 386 at home, although as i said , i can dial into the university's mainframe, (brandeis), which i know supports lynx. i tried the following command: lynx http://www.altavista.iname.com/member/login.page which did get me to this page, but i was unable to type in my account number and password to actually get into the altavista email account. am i doing something wrong? any info would be appreciated,,, thanks a lot, gail strickler strickler@binah.cc.brandeis.edu (brandeis email) From owner-lynx-dev@sig.net Wed Nov 25 16:56:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA08588 for ; Wed, 25 Nov 1998 16:56:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA29429; Wed, 25 Nov 1998 15:36:23 -0600 (CST) Date: Wed, 25 Nov 1998 14:38:42 -0700 (MST) From: Rick Lewis To: lynx-dev@sig.net Subject: lynx-dev why would I get this message? 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: 492 Lines: 14 Using lynx 2.8.1rel2, I received this message while trying to reach a message board. I only got it once, but having never seen it before, wondered why I may have gotten it. I think it was a 404 message, but it said: /lynxcall.cgi not available on this server. I was using my bookmark file, I only had problems with the address once, and subsequent attemptes to connect to the insidedtheweb.com message board were successful. Just what might cause an error like this? --Rick Lewis From owner-lynx-dev@sig.net Wed Nov 25 17:07:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA09315 for ; Wed, 25 Nov 1998 17:07:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA02829; Wed, 25 Nov 1998 15:50:24 -0600 (CST) From: Al Gilman Message-Id: <199811252152.QAA29928@access1.digex.net> Subject: lynx-dev Re: Lynx link To: federico@comnet.com.ar Date: Wed, 25 Nov 1998 16:52:42 -0500 (EST) Cc: lynx-dev@sig.net In-Reply-To: <000301be187c$49a34240$0ed410c8@Rave-N.comnet.com.ar> from Federico at "Nov 25, 98 11:02:49 am" X-Mailer: ELM [version 2.4ME+ PL15 (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: 1171 Lines: 39 to follow up on what Federico said: > We're a ISP located in argentina, and we're setting up our new > website. I wanna known if we can add a link to the lynx page, > or a link to download lynx. We will need to add links to > download the linux version and the win32 version. And i want to > known if you can give us and icon of lynx to add in these > links. There is a GIF of a Lynx in the Win32 distribution bundle, for example. Does anyone have a suitable GIF of the same image that is in the lynx.ico icon? Federico: you can use the icon _only_ if you include ALT text . You can certainly include links to and to the download sites. You might consider hosting a mirror site for distribution. What kind of bandwidth do your users get for accessing sites in North America? > Thanks for all and sorry about my english, my native lenguage > is the spanish. You can help us by preparing a Spanish language translation of the distribution page, and perhaps the Spanish version of the messages that Lynx shows the user as it runs. Al > > Byebye > > -federico@comnet.com.ar > Comnet S.A. > > -rave-n@usa.net > Unknown-d-menxion From owner-lynx-dev@sig.net Thu Nov 26 00:58:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA06814 for ; Thu, 26 Nov 1998 00:58:11 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA16779; Wed, 25 Nov 1998 23:12:06 -0600 (CST) Message-Id: <199811260512.XAA01974@thune.mrc.org> Subject: Re: lynx-dev Saner mouse in lynx with ncurses To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 23:12:16 -0600 (CST) In-Reply-To: <199811251033.FAA23123@shell.clark.net> from "dickey@clark.net" at Nov 25, 98 05:33:17 am From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1469 Lines: 44 Amazingly enough dickey@clark.net said: > > Just as a matter of programming style, would this not be better implemented > > as an enum? > > maybe/maybe not - storing enum values as int's doesn't always work well > on older compilers (which Lynx builds on). If I saw it as an enum, I'd > have to take that into consideration. What storage is being done here? If storing items, I would stay with defines, but for internal use, I would think that enums provide a better style. Granted, compilers don't enforce type checking on them, but, if a function says it takes something of a certain type, or a switch statement is done against a veriable of a certain type, then it's easier for the programmer to remember what's going on. Plus, just plain saving having to manually give the defines different, monotonically increasing values. And it just plain looks better, in my opinion. #define REMOVE_KEY 269 /* 0x10D */ #define MOUSE_KEY 270 /* 0x10E */ #define DO_NOTHING 271 /* 0x10F */ vs.. typedef enum { REMOVE_KEY = 269, MOUSE_KEY, DO_NOTHING } event_type; Of course, in a larger setting, the differences are much more striking. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Thu Nov 26 01:24:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA08371 for ; Thu, 26 Nov 1998 01:24:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA19793; Wed, 25 Nov 1998 23:38:22 -0600 (CST) Message-Id: <199811260538.XAA02006@thune.mrc.org> Subject: Re: lynx-dev Config file reader [PATCH] To: lynx-dev@sig.net Date: Wed, 25 Nov 1998 23:38:51 -0600 (CST) In-Reply-To: <199811251911.OAA03331@chass.utoronto.ca> from "Philip Webb" at Nov 25, 98 02:11:01 pm From: dalgoda@ix.netcom.com (Mike Castle) Content-Type: text Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 978 Lines: 21 Amazingly enough Philip Webb said: > there was some debate a couple of months ago (cp the Archive) > about updating the whole set of choices in configuration, userdefs.h , > lynx.cfg , run-time switches & the new on-line Options form, > one aim being to make everything which is not security-related > changeable on-line & saveable longer-term if desired. But I want to expand this a bit. This wouldn't necessarily help with reading items from lynx.cfg. For each configurable item, they'd be in the table. The table would control whether the item can be configured at run time or not, and whether it's controlled by the state of other items, and whether the item can be saved or not. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen From owner-lynx-dev@sig.net Thu Nov 26 10:24:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA07953 for ; Thu, 26 Nov 1998 10:24:04 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA14258; Thu, 26 Nov 1998 09:06:11 -0600 (CST) Date: Thu, 26 Nov 1998 15:08:07 +0000 (GMT) From: Georges El Asmar X-Sender: aspggea@atlas To: lynx-dev@sig.net Subject: lynx-dev No CACHE 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: 371 Lines: 9 Hi everybody, concerning lynx-2.8: once a document is requested and has been cached, is there a way to prevent lynx from getting the same document from the cache ( besides the no cache command ie ^r) and instead send at least a request to check if the document has been modified. This is the behavior of netscape..good bye.Can you help me with that.thank you. georges From owner-lynx-dev@sig.net Thu Nov 26 11:17:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA11571 for ; Thu, 26 Nov 1998 11:17:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA20558; Thu, 26 Nov 1998 09:58:09 -0600 (CST) From: Al Gilman Message-Id: <199811261600.LAA12023@access1.digex.net> Subject: lynx-dev Re: Lynx link To: federico@comnet.com.ar (Federico) Date: Thu, 26 Nov 1998 11:00:27 -0500 (EST) Cc: lynx-dev@sig.net In-Reply-To: <000601be1945$8a14a840$0ed410c8@Rave-N.comnet.com.ar> from Federico at "Nov 26, 98 11:03:26 am" X-Mailer: ELM [version 2.4ME+ PL15 (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: 6411 Lines: 168 to follow up on what Federico said: > >> We're a ISP located in argentina, and we're setting up our new > >> website. I wanna known if we can add a link to the lynx page, > >> or a link to download lynx. We will need to add links to > >> download the linux version and the win32 version. And i want to > >> known if you can give us and icon of lynx to add in these > >> links. > >There is a GIF of a Lynx in the Win32 distribution bundle, for > >example. > The linx logo is that kinda tiger? Can i ask you why? :) Because Lynx is identified by text, not by logo. There is no "Lynx logo." > > > Does anyone have a suitable GIF of the same image > >that is in the lynx.ico icon? > > If u're interesed, i can ask to a friend of mine who make graphix to make a > .ico for lynx I like the .ico we have. It is included in the Win32 distribution. > > >Federico: you can use the icon _only_ if you include ALT text > >. > > Ok! > > >You can certainly include links to and > >to the download sites. > > Thanx, we love support lynx > > >You might consider hosting a mirror site for distribution. What > >kind of bandwidth do your users get for accessing sites in North > >America? > > I'll ask to the director of my company if he's interesend, but i hope he > will accept > > >> Thanks for all and sorry about my english, my native lenguage > >> is the spanish. > >You can help us by preparing a Spanish language translation > >of the distribution page, and perhaps the Spanish version of > >the messages that Lynx shows the user as it runs. > > I'll don't have any problem in help you to make the spanish version of lynx. > I'll glad to see lynx in spanish! > For this you will need to communicate with others working on non-English messages. Please either subscribe to lynx-dev and continue communication by that list or subscribe to lynx-dev-contrib and read the list archives for replies. Subscription options and instructions below Al -- [ [1]Lynx-Dev Archives | [2]About Lynx ] Lynx-Dev Discussion List Lynx-dev is a majordomo mailing list used by developers and interested users as a forum to discuss the further development of the Lynx World Wide Web browser. Topic issues include fixing known bugs, porting Lynx to various systems, and increasing the usability of Lynx. Open access Anyone may read what has been said on Lynx-dev by visiting the [3] archives. Anyone may ask a question or offer a comment on Lynx-dev by sending mail to lynx-dev@sig.net, the posting address for this list. Because of the public archive, requests for a personal reply may not be honored, and you should check the archive to find all follow-up responses. Messages from non-subscribers are not immediately distributed to the list to avoid distributing spam. Usually, if your message is on topic, it will be retrieved from the pile of spam headed for the wastebasket within a day or so and distributed to the list. So, for best results subscribe as described below. Subscribing to Lynx-Dev If you are interested in joining this mailing list, send email to [4] majordomo@sig.net with only the following request in the body of your message: SUBSCRIBE LYNX-DEV address where inclusion of your email address is optional if it can be obtained, correctly, from the mail headers of your subscription request. You will be asked to answer one follow-up question to confirm that you want the subscription, and Majordomo will enroll you as a subscriber. Majordomo will thereafter send all messages which you address to the posting address to all subscribers of the list, and you will receive all messages set to that address by other subscribers. NOTE: Subject headers are ignored by the majordomo. Unsubscribing from Lynx-Dev To unsubscribe, send an email message to [5] majordomo@sig.net with only the following request in the body: UNSUBSCRIBE LYNX-DEV address where inclusion of your email address is optional if it can be obtained, correctly, from the mail headers of your request. Subscribing to Lynx-Dev-Contrib If you subscribe an email address to lynx-dev-contrib, mail from that address posted to lynx-dev will be recognized as from a subscriber and automatically distributed to the list. To make such a subscription, send email to [6] majordomo@sig.net with only the following request in the body of your message: SUBSCRIBE LYNX-DEV-CONTRIB address. If you prefer to read the lynx-dev discussion using Lynx and the archive, and not receive all the posts as email, subscribe to lynx-dev-contrib and not to lynx-dev. If you have multiple accounts from which you would like to post to lynx-dev, subscribe one of them to lynx-dev (where you will receive the list mail) and the others to lynx-dev-contrib. Majordomo Commands To receive a brief description of majordomo commands, place the following request in a message to [7] majordomo@sig.net: HELP Read the HELP that you receive by return mail to learn the details of the which command you can use to check on your subscriptions, etc. Further information is available from the [8] majordomo website. Contacting Lynx-Dev If you have questions, problems, or comments about using Lynx or installing it on your system, send email to [9] lynx-dev@sig.net. If you have problems with majordomo not responding to your requests, send email to the list owner: [10] majordomo-owner@sig.net. Please, DO NOT send them to lynx-dev@sig.net as they will be distributed to everyone on the list and will clutter up their mailboxes. Lynx-Dev Archives Archives of messages posted to lynx-dev are now in html format so that you can view them using Lynx. Go to the [11]Lynx-Dev Archives. References 1. http://www.flora.org/lynx-dev/html/ 2. http://www.slcc.edu/lynx/release2-8-1/lynx2-8-1/lynx_help/about_lynx.html 3. http://www.flora.org/lynx-dev/html/ 4. mailto:majordomo@sig.net 5. mailto:majordomo@sig.net 6. mailto:majordomo@sig.net 7. mailto:majordomo@sig.net 8. http://www.greatcircle.com/majordomo/ 9. mailto:lynx-dev@sig.net 10. mailto:majordomo-owner@sig.net 11. http://www.flora.org/lynx-dev/html/ From owner-lynx-dev@sig.net Thu Nov 26 12:37:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA17498 for ; Thu, 26 Nov 1998 12:37:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA00473; Thu, 26 Nov 1998 11:13:10 -0600 (CST) Message-ID: <19981126172039.31055@k332.feld.cvut.cz> Date: Thu, 26 Nov 1998 17:20:39 +0100 From: Stanislav Brabec To: lynx-dev@sig.net Subject: Re: lynx-dev lynx --enable-color-style causes fp error Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74e Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 7859 Lines: 177 Hallo Larry W. Virden, sorry for not explaining lynx bug in details, I didn't know if this experimental feature isn't broken. Lynx crashes whenever --enable-color-style and curses COLORS==0. I was done some tracing with TERM=xterm (from ncurses-4.2 terminfo database). There is defined no color support and it causes lynx 2.8 to hang (see gdb output). The same code works OK with xfree-3.3.2 terminfo. This works: configure --prefix=/usr --with-screen=slang --enable-8bit-toupper --enable-default-colors \ --enable-externs --enable-font-switch --enable-internal-links --enable-nsl-fork \ --enable-underlines --with-zlib This is buggy: configure --prefix=/usr --enable-color-style --enable-debug For this test I have removed -O2 from makefiles: sedfile s/-O2//g makefile */makefile */*/makefile */*/*/makefile ------------------------------------------------------------- exception in: src/LYStyle.c ************************************************************* bA = check_color(bg, default_bg); if (fA == NO_COLOR) { bA = NO_COLOR; } else { if (fA >= COLORS || bA >= COLORS) cA = A_BOLD; if (fA >= COLORS) -> fA %= COLORS; if (bA > COLORS) bA %= COLORS; } /* * If we have colour, and space to create a new colour attribute, * and we have a valid colour description, then add this style */ if (lynx_has_color && colorPairs < COLOR_PAIRS-1 && fA != NO_COLOR) { if (colorPairs <= 0 || fA != last_fA || bA != last_bA) { colorPairs++; init_pair(colorPairs, fA, bA); last_fA = fA; last_bA = bA; ************************************************************* Program received signal SIGFPE, Arithmetic exception. 0x80d5a14 in parse_attributes (mono=0x81c910f "bold", fg=0x81c9114 "white", bg=0x81c911a "green", style=133, element=0x81c9100 "link.green.toc") at ./LYStyle.c:84 (xxgdb) print COLORS $1 = 0 (xxgdb) print fA $2 = 15 (xxgdb) ---------------------- config.cache ------------------------- # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure # scripts and configure runs. It is not useful on other systems. # If it contains results you don't want to keep, you may remove or edit it. # # By default, configure uses ./config.cache as the cache file, # creating it if it does not exist already. You can give configure # the --cache-file=FILE option to use a different cache file; that is # what configure does when it calls configure scripts in # subdirectories, so they share the cache. # Giving --cache-file=/dev/null disables caching, for debugging configure. # config.status only pays attention to the cache file if you give it the # --recheck option to rerun configure. # ac_cv_c_const=${ac_cv_c_const=yes} ac_cv_func_cbreak=${ac_cv_func_cbreak=yes} ac_cv_func_cuserid=${ac_cv_func_cuserid=yes} ac_cv_func_decl_getgrgid=${ac_cv_func_decl_getgrgid=yes} ac_cv_func_decl_getgrnam=${ac_cv_func_decl_getgrnam=yes} ac_cv_func_decl_strstr=${ac_cv_func_decl_strstr=yes} ac_cv_func_getcwd=${ac_cv_func_getcwd=yes} ac_cv_func_getgroups=${ac_cv_func_getgroups=yes} ac_cv_func_gethostbyname=${ac_cv_func_gethostbyname=yes} ac_cv_func_gethostname=${ac_cv_func_gethostname=yes} ac_cv_func_initscr=${ac_cv_func_initscr=no} ac_cv_func_keypad=${ac_cv_func_keypad=yes} ac_cv_func_lstat=${ac_cv_func_lstat=yes} ac_cv_func_mktime=${ac_cv_func_mktime=yes} ac_cv_func_putenv=${ac_cv_func_putenv=yes} ac_cv_func_readdir=${ac_cv_func_readdir=yes} ac_cv_func_socket=${ac_cv_func_socket=yes} ac_cv_func_strcasecmp=${ac_cv_func_strcasecmp=yes} ac_cv_func_strerror=${ac_cv_func_strerror=yes} ac_cv_func_strstr=${ac_cv_func_strstr=yes} ac_cv_func_tgoto=${ac_cv_func_tgoto=no} ac_cv_func_use_default_colors=${ac_cv_func_use_default_colors=yes} ac_cv_func_vfork_works=${ac_cv_func_vfork_works=yes} ac_cv_func_waitpid=${ac_cv_func_waitpid=yes} ac_cv_func_wborder=${ac_cv_func_wborder=yes} ac_cv_header_dirent_dirent_h=${ac_cv_header_dirent_dirent_h=yes} ac_cv_header_fcntl_h=${ac_cv_header_fcntl_h=yes} ac_cv_header_limits_h=${ac_cv_header_limits_h=yes} ac_cv_header_stdc=${ac_cv_header_stdc=yes} ac_cv_header_stdlib_h=${ac_cv_header_stdlib_h=yes} ac_cv_header_string_h=${ac_cv_header_string_h=yes} ac_cv_header_sys_fcntl_h=${ac_cv_header_sys_fcntl_h=yes} ac_cv_header_sys_filio_h=${ac_cv_header_sys_filio_h=no} ac_cv_header_sys_ioctl_h=${ac_cv_header_sys_ioctl_h=yes} ac_cv_header_sys_param_h=${ac_cv_header_sys_param_h=yes} ac_cv_header_sys_time_h=${ac_cv_header_sys_time_h=yes} ac_cv_header_sys_wait_h=${ac_cv_header_sys_wait_h=yes} ac_cv_header_termio_h=${ac_cv_header_termio_h=yes} ac_cv_header_termios_h=${ac_cv_header_termios_h=yes} ac_cv_header_time=${ac_cv_header_time=yes} ac_cv_header_unistd_h=${ac_cv_header_unistd_h=yes} ac_cv_header_vfork_h=${ac_cv_header_vfork_h=no} ac_cv_lib_curses_initscr=${ac_cv_lib_curses_initscr=yes} ac_cv_lib_dir_opendir=${ac_cv_lib_dir_opendir=no} ac_cv_lib_inet=${ac_cv_lib_inet=no} ac_cv_lib_termcap_tgoto=${ac_cv_lib_termcap_tgoto=yes} ac_cv_path_CHMOD=${ac_cv_path_CHMOD=/bin/chmod} ac_cv_path_COMPRESS=${ac_cv_path_COMPRESS=/usr/bin/compress} ac_cv_path_COPY=${ac_cv_path_COPY=/bin/cp} ac_cv_path_GZIP=${ac_cv_path_GZIP=/bin/gzip} ac_cv_path_MKDIR=${ac_cv_path_MKDIR=/bin/mkdir} ac_cv_path_MV=${ac_cv_path_MV=/bin/mv} ac_cv_path_RM=${ac_cv_path_RM=/bin/rm} ac_cv_path_TAR=${ac_cv_path_TAR=/bin/tar} ac_cv_path_TOUCH=${ac_cv_path_TOUCH=/bin/touch} ac_cv_path_UNCOMPRESS=${ac_cv_path_UNCOMPRESS=/bin/gunzip} ac_cv_path_UNZIP=${ac_cv_path_UNZIP=/usr/bin/unzip} ac_cv_path_UUDECODE=${ac_cv_path_UUDECODE=/usr/bin/uudecode} ac_cv_path_ZCAT=${ac_cv_path_ZCAT=/bin/zcat} ac_cv_path_ZIP=${ac_cv_path_ZIP=/usr/bin/zip} ac_cv_path_install=${ac_cv_path_install='/bin/ginstall -c'} ac_cv_prog_CC=${ac_cv_prog_CC=gcc} ac_cv_prog_CPP=${ac_cv_prog_CPP='gcc -E'} ac_cv_prog_RANLIB=${ac_cv_prog_RANLIB=ranlib} ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross=no} ac_cv_prog_cc_g=${ac_cv_prog_cc_g=yes} ac_cv_prog_cc_works=${ac_cv_prog_cc_works=yes} ac_cv_prog_gcc=${ac_cv_prog_gcc=yes} ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes} ac_cv_type_mode_t=${ac_cv_type_mode_t=yes} ac_cv_type_pid_t=${ac_cv_type_pid_t=yes} cf_cv_SYSTEM_MAIL=${cf_cv_SYSTEM_MAIL=/usr/sbin/sendmail} cf_cv_alt_char_set=${cf_cv_alt_char_set=yes} cf_cv_baddef_remove=${cf_cv_baddef_remove=no} cf_cv_bool_defs=${cf_cv_bool_defs=yes} cf_cv_color_curses=${cf_cv_color_curses=yes} cf_cv_curs_performance=${cf_cv_curs_performance=no} cf_cv_dcl_errno=${cf_cv_dcl_errno=yes} cf_cv_dcl_sys_errlist=${cf_cv_dcl_sys_errlist=yes} cf_cv_dcl_sys_nerr=${cf_cv_dcl_sys_nerr=yes} cf_cv_fancy_curses=${cf_cv_fancy_curses=yes} cf_cv_fionbio=${cf_cv_fionbio=ioctl} cf_cv_have_errno=${cf_cv_have_errno=yes} cf_cv_have_sys_errlist=${cf_cv_have_sys_errlist=yes} cf_cv_have_sys_nerr=${cf_cv_have_sys_nerr=yes} cf_cv_have_ttytype=${cf_cv_have_ttytype=yes} cf_cv_have_utmp=${cf_cv_have_utmp=yes} cf_cv_locale=${cf_cv_locale=yes} cf_cv_ncurses_broken=${cf_cv_ncurses_broken=no} cf_cv_ncurses_header=${cf_cv_ncurses_header=curses.h} cf_cv_ncurses_version=${cf_cv_ncurses_version=4.2.980228} cf_cv_netlibs=${cf_cv_netlibs=} cf_cv_ngroups=${cf_cv_ngroups=yes} cf_cv_screen=${cf_cv_screen=curses} cf_cv_sizechange=${cf_cv_sizechange=yes} cf_cv_system_mail_flags=${cf_cv_system_mail_flags='-t -oi'} cf_cv_termio_and_termios=${cf_cv_termio_and_termios=yes} cf_cv_type_unionwait=${cf_cv_type_unionwait=no} ------------------------------------------------------------- Note: configure --prefix=/usr --with-screen=slang --enable-8bit-toupper --enable-default-colors --enable-externs --enable-font-switch --enable-internal-links --enable-nsl-fork --enable-underlines --with-zlib --enable-color-style returns also checking if color-style code should be used... configure: error: Configuration does not support color-styles -- Stanislav Brabec From owner-lynx-dev@sig.net Thu Nov 26 15:27:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA29373 for ; Thu, 26 Nov 1998 15:27:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA21577; Thu, 26 Nov 1998 14:07:09 -0600 (CST) Message-ID: <19981126151218.A1276@scitus.dyn.ml.org> Date: Thu, 26 Nov 1998 15:12:18 -0500 From: Eric To: lynx-dev@sig.net Subject: Re: lynx-dev No CACHE Mail-Followup-To: lynx-dev@sig.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Georges El Asmar on Thu, Nov 26, 1998 at 03:08:07PM +0000 X-Unix: Linux Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 936 Lines: 20 Quite frankly, Georges El Asmar said: ] Hi everybody, concerning lynx-2.8: ] once a document is requested and has been cached, is there a way to ] prevent lynx from getting the same document from the cache ( besides the ] no cache command ie ^r) and instead send at least a request to check if ] the document has been modified. This is the behavior of netscape..good ] bye.Can you help me with that.thank you. ] georges It most likely depends on the situation--if you're just using the left arrow to back out of the current document and into a document that you don't want cached, the only thing you can do is hit ^R when the document appears. If you are selecting a hyperlink and don't want it to view a cached version, instead of hitting ENTER or the Right Arrow key, hit 'x' -- it explicitly loads it without referencing the cache, and throws out the previous cached copy. -- Spirilis root@scitus.dyn.ml.org hannibal@bitsmart.com From owner-lynx-dev@sig.net Thu Nov 26 21:01:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA17969 for ; Thu, 26 Nov 1998 21:01:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA03378; Thu, 26 Nov 1998 19:43:59 -0600 (CST) From: Ilya Zakharevich Message-Id: <199811262136.QAA18160@monk.mps.ohio-state.edu> Subject: lynx-dev Keymap printing patch To: lynx-dev@sig.net Date: Thu, 26 Nov 1998 16:36:06 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 1481 Lines: 39 I was puzzled why lynx would not print its DOWN_TWO binding. The following patch resulted. Note that a) This patch does not help with bindings keys which are not visible in the current font: try binding 0x81, this will result in some invisible entry (is not this a bug in the display code?); b) This prints some unexpected funny bindings, like 0x1b8 ABORT quit the browser unconditionally 0x1cb ACTIVATE go to the document given by the current link 0x1cf IMAGE_TOGGLE toggle handling of all images as links 0x1d0 PREV_PAGE view the previous page of the document 0x1d1 NEXT_PAGE view the next page of the document Do not know why. (But the code printing this is important to debug assignments similar to KEYMAP:0x210:LEFT_LINK.) Enjoy, Ilya --- ./src/LYKeymap.c~ Tue Nov 10 14:47:38 1998 +++ ./src/LYKeymap.c Thu Nov 26 16:26:10 1998 @@ -641,6 +641,8 @@ PRIVATE char *pretty ARGS1 (int, c) sprintf(buf, "^%c", c|0100); else if (c >= 0400 && (c - 0400) < (int) TABLESIZE(funckey)) sprintf(buf, "%s", funckey[c-0400]); + else if (c >= 0400) + sprintf(buf, "%#x", c); else return 0; @@ -726,7 +728,7 @@ PRIVATE int LYLoadKeymap ARGS4 ( /* * LYK_PIPE not implemented yet. */ - if ((i > (int) TABLESIZE(keymap) || i <= ' ' || !isalpha(i-1)) && + if ((i <= 'a' || i > 'z' + 1) && (i <= 'A' || i > 'Z' + 1) && strcmp(revmap[keymap[i]].name, "PIPE")) { print_binding(target, buf, i); } From owner-lynx-dev@sig.net Thu Nov 26 21:02:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA17975 for ; Thu, 26 Nov 1998 21:02:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA03363; Thu, 26 Nov 1998 19:43:52 -0600 (CST) From: "Elwin Oost" To: lynx-dev@sig.net Date: Thu, 26 Nov 1998 23:00:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: lynx-dev Post-query bug X-mailer: Pegasus Mail for Win32 (v3.01c) Message-Id: Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 306 Lines: 10 Hi everybody, About a week ago I sent a bug report regarding a post-query redirection bug (using my other account emoost@wins.uva.nl). Since I have not had a response on it so far, I was wondering whether I made a mistake sending it. Please let me know whether you received it. Best regards, Elwin From owner-lynx-dev@sig.net Thu Nov 26 21:02:20 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA17985 for ; Thu, 26 Nov 1998 21:02:19 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA03404; Thu, 26 Nov 1998 19:44:12 -0600 (CST) From: Ilya Zakharevich Message-Id: <199811262101.QAA07977@monk.mps.ohio-state.edu> Subject: lynx-dev Key remapping problem To: lynx-dev@sig.net Date: Thu, 26 Nov 1998 16:01:02 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 24 I'm somehow lost wrt key remapping in lynx. Looking through the source of LYKeymap.c, I get an impression that keymap[] goes up to 0x293 or some such. However, a pair setkey "^[^[" 0x81 KEYMAP:0x81:LEFT_LINK works, but setkey "^[^[" 0x210 KEYMAP:0x210:LEFT_LINK does not. Moreover, I cannot make this work on PC: setkey "\000s" 0x81 KEYMAP:0x81:LEFT_LINK The ideal would be to document something like: the region 0x120..0x160 is reserved for user-defined keys, and make sure they work. A possibility to remap PC keys would not hurt too ;-). Ilya From owner-lynx-dev@sig.net Thu Nov 26 21:48:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id VAA20759 for ; Thu, 26 Nov 1998 21:48:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id UAA08749; Thu, 26 Nov 1998 20:30:21 -0600 (CST) From: Philip Webb Message-Id: <199811270231.VAA10975@chass.utoronto.ca> Subject: Re: lynx-dev Post-query bug To: lynx-dev@sig.net Date: Thu, 26 Nov 1998 21:31:22 -0500 (EST) Cc: elwin@decent.demon.nl In-Reply-To: from "Elwin Oost" at Nov 26, 98 11:00:42 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: 674 Lines: 14 981126 Elwin wrote: > About a week ago I sent a bug report regarding a post-query > redirection bug (using my other account emoost@wins.uva.nl). > Since I have not had a response on it so far, I was wondering > whether I made a mistake sending it. you can check in the Archive at www.flora.org/lynx-dev/ , where you will also find any replies. if it's not there, let us know again 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 Fri Nov 27 03:21:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA08550 for ; Fri, 27 Nov 1998 03:21:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA10119; Fri, 27 Nov 1998 01:53:46 -0600 (CST) From: David Woolley Message-Id: <199811260855.IAA08747@djwhome.demon.co.uk> Subject: lynx-dev Altavista via VAX "shell" account Lynx (was: [no subject at all]) To: lynx-dev@sig.net Date: Thu, 26 Nov 1998 08:55:07 +0000 (GMT) Cc: strickler@BINAH.CC.BRANDEIS.EDU In-Reply-To: <365C7033.AC0DCE7C@binah.cc.brandeis.edu> from "Gail Strickler" at Nov 25, 98 04:01: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: 853 Lines: 19 > > hi--i can access the internet (with my 386 dos computer and kermit)by A 386 (even SX) with 2MB of memory should run the DOS port of Lynx. A 386 (even SX) with 4MB of memory definitely will run the Linux port. (It would thrash badly in 2MB, but it might still be useable if you were careful to construct a very clean configuration.) You will need someone to provide PPP access to you. > dialing into my university's mainframe and logging on to the VAX system > there. my question is this: from the vax, using lynx, can i read my > email from my email account with altavista? or do i have to get onto a > p.c. that has web-based internet access? the issue is: i have the You probably need the VAX Lynx updating to a current version (2.8.1ish); you didn't say what the current version was. Written using a 386 SX/25, with 6MB, running Linux. From owner-lynx-dev@sig.net Fri Nov 27 03:40:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA09636 for ; Fri, 27 Nov 1998 03:40:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA11840; Fri, 27 Nov 1998 02:18:32 -0600 (CST) From: "Esa Pikkarainen" Organization: Oulun yliopisto/KTK To: lynx-dev@sig.net Date: Fri, 27 Nov 1998 10:22:44 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: lynx-dev Textarea probls and wishes X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <4668A5B19F5@ktk.oulu.fi> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1325 Lines: 28 Hi, I use Lynx from home via 9600 modem. (Maybe I am not last one in this situation...) Often I have to use www services that have forms with textarea fields. You know these are a little uncomfortable with Lynx if they have many rows. Once you step to a row you can only use up and down to navigate and with this modem it is annoying to go through some 20 rows. If I use "numbered links" the situation is alittle bit better because I can step to a certain row but when I am there I have again use onlu up and down - line by line. Isn't it possible to add some more possibilities here? I have at least two suggestions: 1) You could use a certain escape sequence (ctrl-a or something) to get a simple navigation menu with alternatives like: Next/Previous Page; Next/Previous field in form; Out from the form; To the Submit button; etc. 2) The whole Textarea could be editet in editor like comments and mailto: links; either in line editor or the user's specified Editor Thank you Esa Pikkarainen Mr. Esa Pikkarainen (Linnanmaa, Snelmania, room: KTK338) Fac of Ed, Univ of Oulu Tel:358-8-5533691 Fax: -5533744 P.O. Box 222, SF-90571 Oulu E-mail: epikkara@ktk.oulu.fi Finland :-) WWW: http://wwwedu.oulu.fi/~/epikkara/ PS. Excuse me my bad English - I am not a native nor a daily user. From owner-lynx-dev@sig.net Fri Nov 27 05:08:55 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA14351 for ; Fri, 27 Nov 1998 05:08:54 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA18439; Fri, 27 Nov 1998 03:50:47 -0600 (CST) Date: Fri, 27 Nov 1998 01:53:17 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Textarea probls and wishes In-Reply-To: <4668A5B19F5@ktk.oulu.fi> 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: 1205 Lines: 24 On Fri, 27 Nov 1998, Esa Pikkarainen wrote: > I use Lynx from home via 9600 modem. (Maybe I am not last one in this > situation...) Often I have to use www services that have forms with > textarea fields. You know these are a little uncomfortable with Lynx > if they have many rows. Once you step to a row you can only use up > and down to navigate and with this modem it is annoying to go through > some 20 rows. If I use "numbered links" the situation is alittle bit > better because I can step to a certain row but when I am there I have > again use onlu up and down - line by line. Isn't it possible to add > some more possibilities here? I have at least two suggestions: The trick here is to use CTL-V from within the text area. This allows you to use the usual lynx navigation commands. Make sure to set keypad mode to "Form fields and links are numbered" rather than just to "Links are numbered" in your option menu (save to .lynxrc). The question of an editor for the textarea in forms has been brought up before, but is waiting for someone to submit a solution. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Nov 27 05:43:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA16284 for ; Fri, 27 Nov 1998 05:43:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA20581; Fri, 27 Nov 1998 04:23:33 -0600 (CST) Date: Fri, 27 Nov 1998 02:26:04 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Key remapping problem In-Reply-To: <199811262101.QAA07977@monk.mps.ohio-state.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: 2293 Lines: 55 On Thu, 26 Nov 1998, Ilya Zakharevich wrote: > I'm somehow lost wrt key remapping in lynx. Looking through the > source of LYKeymap.c, I get an impression that keymap[] goes up to > 0x293 or some such. > > However, a pair > > setkey "^[^[" 0x81 > KEYMAP:0x81:LEFT_LINK > > works, but > > setkey "^[^[" 0x210 > KEYMAP:0x210:LEFT_LINK > > does not. Moreover, I cannot make this work on PC: > > setkey "\000s" 0x81 > KEYMAP:0x81:LEFT_LINK > > The ideal would be to document something like: the region 0x120..0x160 > is reserved for user-defined keys, and make sure they work. > > A possibility to remap PC keys would not hurt too ;-). I will try to answer this, since I submitted the patch that revised the keymapping code, allowing keymapping of special keys with the DJGPP and Windows ports. The code that gets in the way of your second mapping is in LYStrings.c, lines 1205-1209. The limits on the keys that can be remapped were changed for the DJGPP and Windows ports to 0x293, but were left for other platforms at the previous value of 0x10e. (The value of DO_NOTHING in LYStrings.h). Mapping tables to be used for the DOS and Windows ports are in the files djgpp.key, slang.key, and pdcurses.key in the docs subdirectory of the lynx distribution. Default key mapping can be found in the keymap[] array in LYKeymap.c If you have a platform which maps keys above 0x10e, just change the line in LYStrings to allow the mappings. If there is a general ability or desire to do these mappings on other platforms, it would be simple to change DO_NOTHING in LYStrings.h and LYKeymap.c to 0x294 and expand the keymap[] array by one element. Then all these keys could be mapped on any platform that supports it. You would have to watch for surprise mappings, because of the handling of PDCurses. Since there is no define in the lynx code for PDCurses, it is seen as "(defined(_WINDOWS) || defined(__DJGPP__)) && !defined USE_SLANG", and has default mappings for it in the higher keys in keymap[]. Please write back if this doesn't answer the question in a satisfactory manner. Also, what platform are you using? Why the need to use keys above 0x10e? Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Nov 27 06:03:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA17404 for ; Fri, 27 Nov 1998 06:03:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA21888; Fri, 27 Nov 1998 04:42:00 -0600 (CST) Date: Fri, 27 Nov 1998 02:44:30 -0800 (PST) From: Doug Kaufman X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Keymap printing patch In-Reply-To: <199811262136.QAA18160@monk.mps.ohio-state.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: 801 Lines: 22 On Thu, 26 Nov 1998, Ilya Zakharevich wrote: > Do not know why. (But the code printing this is important to debug > assignments similar to KEYMAP:0x210:LEFT_LINK.) > > Enjoy, > Ilya > > --- ./src/LYKeymap.c~ Tue Nov 10 14:47:38 1998 > +++ ./src/LYKeymap.c Thu Nov 26 16:26:10 1998 > @@ -641,6 +641,8 @@ PRIVATE char *pretty ARGS1 (int, c) I am not sure that this code is really a good idea. I am stil trying to understand what you are trying to accomplish with this. See my reply to your other message in regard to a change in LYStrings.c that may do what you want. Perhaps you can try to explain again what it is that you think that lynx should be doing, but is not. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Fri Nov 27 08:08:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA24320 for ; Fri, 27 Nov 1998 08:08:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA01282; Fri, 27 Nov 1998 06:49:11 -0600 (CST) From: Philip Webb Message-Id: <199811271250.HAA03502@chass.utoronto.ca> Subject: Re: lynx-dev Textarea probls and wishes To: lynx-dev@sig.net Date: Fri, 27 Nov 1998 07:50:07 -0500 (EST) Cc: epikkara@ktk.oulu.fi In-Reply-To: <4668A5B19F5@ktk.oulu.fi> from "Esa Pikkarainen" at Nov 27, 98 10:22: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: 956 Lines: 20 981127 Esa Pikkarainen wrote: > I use Lynx from home via 9600 modem. > Often I have to use www services that have forms with textarea fields. > Once you step to a row you can only use up and down to navigate use ^v to enter any Lynx command, esp eg 12g (goto 12th row): i assume you are using the latest Lynx 2-8-1. > The Textarea could be edited in editor like comments and mailto links; > either in line editor or the user's specified Editor all this needs is someone to do the necessary coding, incl a switch to disable it for anonymous users for security. if you are good enough at C, by all means submit a patch to do this: lots of other people will be pleased too (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 Fri Nov 27 10:09:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA31969 for ; Fri, 27 Nov 1998 10:09:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA13060; Fri, 27 Nov 1998 08:50:47 -0600 (CST) Message-ID: <19981127095158.A19760@mail.bcpl.net> Date: Fri, 27 Nov 1998 09:51:58 -0500 From: Webmaster Jim To: lynx-dev@sig.net Cc: Frangois Pinard Subject: lynx-dev fwd: ...translations Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2i 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.93.2i (1998-07-29) 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: 4377 Lines: 95 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii I received the attached email from Francois and wanted to let the Lynx-dev team know where we are. When Francois has the time, he will help organize translation teams for Lynx support. In the meantime, I will be looking at the newer gettext code he has referenced to see where the template files could be improved. ------ Marvin the Paranoid Android says: You realise this is going to be a complete waste of time don't you? --J/dobhs11T7y2rNN Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Description: =?iso-8859-1?Q?Forwarded_message_from_Fran=E7ois_Pinard_=3Cpinard=40IRO?= =?iso-8859-1?Q?=2EUMontreal=2ECA=3E?= Received: from degusse.IRO.UMontreal.CA (degusse.IRO.UMontreal.CA [132.204.24.51]) by mail.bcpl.net (8.8.7/8.8.7) with ESMTP id SAA08216 for ; Wed, 25 Nov 1998 18:03:49 -0500 (EST) Received: from raptor.IRO.UMontreal.CA (raptor.IRO.UMontreal.CA [132.204.26.133]) by degusse.IRO.UMontreal.CA (8.9.1/8.9.1) with ESMTP id SAA12630 for ; Wed, 25 Nov 1998 18:04:45 -0500 (EST) Received: (from pinard@localhost) by raptor.IRO.UMontreal.CA (8.8.8/8.8.8) id SAA16464; Wed, 25 Nov 1998 18:04:38 -0500 (EST) Sender: pinard@IRO.UMontreal.CA To: "Webmaster Jim" Subject: Re: Lynx translations References: <199811252021.PAA00648@mail.bcpl.net> X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m Date: 25 Nov 1998 18:04:38 -0500 In-Reply-To: "Webmaster Jim"'s message of "Wed, 25 Nov 1998 15:21:06 -0500 (EST)" Message-ID: User-Agent: Gnus/5.070051 (Pterodactyl Gnus v0.51) Emacs/20.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" "Webmaster Jim" writes: > I have sent a couple recent messages about our work to include > translations in the Lynx web browser program. I haven't heard back, > and was beginning to wonder if I had done something wrong. If you are > swamped, I understand... I have both of them. Yes, I'm a bit swamped, it happens sometimes. And surely yes, I'm interested in collaborating in a Lynx translation effort, by getting the translation project teams and mechanics to handle them. When under load like nowadays, I work on projects kind of round-robin, doing a burst on each of them, and usually visit the translation project twice a month. But when the stress is less high, I usually succeed to handle email just as it arrives. Don't despair! :-) If you allow me a very quick comment, before returning to your emails for real, I noticed that the POT files were created using an old verison of `gettext', version 0.10 probably. The header entry format changed significantly since then, and this created problems more than once. Ideally, a new release of the `gettext' package should occur, but the maintainer is overwhelmed as well, and we have to cope with the interim. Oops, I have to leave right now... More later. [...] Sorry for the interruption. I'm now back. I just wanted to add that my intent is to write some script to transform oldish headers into the current format. In fact, I once wrote such a thing, and used it to convert all PO files in the translation project archives, and later threw the script away, after not having seen old headers for a while. Strangely enough, recently, a few projects are publishing POT files with the old `gettext', so I should rewrite the script and do what should be done with these recent POT/PO files, instead of overly bothering maintainers about it. Yet in the long run (or more precisely, in the meantime waiting for a new official release of `gettext'), best would be to use the following instead: http://www.iro.umontreal.ca/contrib/po/gettext-0.10.35.tar.gz OK! I'll be back to you in a few days at most, regarding your emails. Keep happy! -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard --J/dobhs11T7y2rNN-- From owner-lynx-dev@sig.net Fri Nov 27 11:59:26 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA06144 for ; Fri, 27 Nov 1998 11:59:24 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26019; Fri, 27 Nov 1998 10:39:44 -0600 (CST) Date: Fri, 27 Nov 1998 10:42:12 -0600 (CST) From: Klaus Weide To: William Park cc: lynx-dev@sig.net Subject: lynx-dev Re: Better color settings 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: 1904 Lines: 47 [ please include lynx-dev@sig.net in the reply] On Wed, 25 Nov 1998, William Park wrote: > On Sun, 22 Nov 1998, Klaus Weide wrote: > > On Sat, 21 Nov 1998, William Park wrote: > > > > > Hi, > > > > > > I upgraded from lynx-2.6 to lynx-2.8.1. I liked partial display of > > > page while it is being downloaded. > > > > > > But, the default color scheme is a bit lame. When I do search (/), > > > lynx moves forward to the location, but the searched pattern is not > > > highlighted. When color is disabled (-color), the search works as > > > expected. > > > > Which operating system, and what kind of terminal? Is thins in an xterm? > > > > Is Lynx compiled with slang, ncurses, curses? With --enable-color-style? > > > > Do you have uncommented COLOR settings in lynx.cfg? > > Oh yeah, my apology... I was in a hurry. I am using Linux Slackware > 3.3. Lynx-2.8.1 was compiled with > ./configure --with-screen=ncurses --enable-default-colors > The COLOR settings are enabled from ~/.lynxrc, and the system defaults > in lynx.cfg are not changed. I think my ncurses is a bit old > (libncurses.so.1.9.9e); it came with the system. That may be a problem; I don't know whether Tom (ar anyone) still is testing against that version. AFAIK the newer versions should be much better supported. Highlighting of search targets is done with a combination of bold+reverse+underline attributes, at least if FANCY_CURSES is defined (which should apply fur NCURSES). See LYstartTargetEmphasis() in LYCurses.c. But how that actuall appears on the screen depends on the ncurses lib and on the terminfo data. On the linux console, underline isn't actually supported as such, but is simulated as a different color. You may be able to set that to a different color, and thereby make search targets visible, by using `setterm -ulcolor', for example setterm -ulcolor bright magenta Klaus From owner-lynx-dev@sig.net Fri Nov 27 12:01:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA06464 for ; Fri, 27 Nov 1998 12:00:56 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA26269; Fri, 27 Nov 1998 10:42:27 -0600 (CST) Date: Fri, 27 Nov 1998 10:44:57 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev why would I get this message? 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: 689 Lines: 18 On Wed, 25 Nov 1998, Rick Lewis wrote: > Using lynx 2.8.1rel2, I received this message while trying to reach a > message board. I only got it once, but having never seen it before, > wondered why I may have gotten it. > I think it was a 404 message, but it said: > /lynxcall.cgi not available on this server. > I was using my bookmark file, I only had problems with the address once, > and subsequent attemptes to connect to the insidedtheweb.com message board > were > successful. > Just what might cause an error like this? Probably the server is calling lynx internally (which should normally be invisible to you) to retrieve something from another server. Klaus From owner-lynx-dev@sig.net Fri Nov 27 12:15:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA07244 for ; Fri, 27 Nov 1998 12:15:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA27278; Fri, 27 Nov 1998 10:51:25 -0600 (CST) Date: Fri, 27 Nov 1998 10:53:55 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev avoiding screen refresh after partial display 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: 897 Lines: 25 On Wed, 25 Nov 1998, Leonid Pauzner wrote: > I will look more closely, > but now I feel a problem: besides just viewing the incremental rendering > we may also scroll the screen by scroll keys in partial mode. > It require a complete page redisplay but I think it will not. That should be taken care of by the second condition in #ifdef DISP_PARTIAL if (!display_partial && line_number == text->first_lineno_last_disp_partial && i + line_number <= text->last_lineno_last_disp_partial) move((i + 2), 0); else #endif display_line(line, text); The call to display_line is only skipped if line_number (the new text->top_of_screen) is the same as during the last call during display_partial. (For comparison with the global variables, note that these internal line numbers are zero-based, not 1-based.) Klaus From owner-lynx-dev@sig.net Fri Nov 27 12:23:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA07940 for ; Fri, 27 Nov 1998 12:23:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA28996; Fri, 27 Nov 1998 11:04:49 -0600 (CST) X-ROUTED: Fri, 27 Nov 1998 13:04:00 -0300 Message-ID: <000a01be1a1f$4f7182a0$0ed410c8@Rave-N.comnet.com.ar> From: "Federico" To: Subject: RE: lynx-dev fwd: ...translations Date: Fri, 27 Nov 1998 13:02:18 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 551 Lines: 14 >I received the attached email from Francois and wanted to let the >Lynx-dev team know where we are. When Francois has the time, he will >help organize translation teams for Lynx support. In the meantime, I >will be looking at the newer gettext code he has referenced to see where >the template files could be improved. Hi. I've subscribe that list to help in the lynx spanish version. I'm from argentina and i wanna help in translate lynx to my native lenguage. I wanna know who is the organizer of that 'department'. Cya -federico@comnet.com.ar From owner-lynx-dev@sig.net Fri Nov 27 12:24:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA07980 for ; Fri, 27 Nov 1998 12:24:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA28440; Fri, 27 Nov 1998 11:01:10 -0600 (CST) Date: Fri, 27 Nov 1998 11:03:42 -0600 (CST) From: Klaus Weide To: lynx-dev@sig.net Subject: Re: lynx-dev lynx --enable-color-style causes fp error In-Reply-To: <19981126172039.31055@k332.feld.cvut.cz> 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: 1532 Lines: 54 On Thu, 26 Nov 1998, Stanislav Brabec wrote: > Lynx crashes whenever --enable-color-style and curses COLORS==0. > > I was done some tracing with TERM=xterm (from ncurses-4.2 terminfo database). > There is defined no color support and it causes lynx 2.8 to hang (see gdb output). > The same code works OK with xfree-3.3.2 terminfo. > > > This works: > configure --prefix=/usr --with-screen=slang --enable-8bit-toupper --enable-default-colors \ > --enable-externs --enable-font-switch --enable-internal-links --enable-nsl-fork \ > --enable-underlines --with-zlib > > This is buggy: > configure --prefix=/usr --enable-color-style --enable-debug > ------------------------------------------------------------- > > exception in: src/LYStyle.c > ************************************************************* > bA = check_color(bg, default_bg); > if (fA == NO_COLOR) { > bA = NO_COLOR; > } else { > if (fA >= COLORS || bA >= COLORS) > cA = A_BOLD; > if (fA >= COLORS) > -> fA %= COLORS; > if (bA > COLORS) > bA %= COLORS; > } The 2.8.1(rel.2) already has protection against this crash, the code now looks like this: bA = check_color(bg, default_bg); if (fA == NO_COLOR) { bA = NO_COLOR; } else if (COLORS) { if (fA >= COLORS || bA >= COLORS) cA = A_BOLD; if (fA >= COLORS) fA %= COLORS; if (bA > COLORS) bA %= COLORS; } else { cA = A_BOLD; fA = NO_COLOR; bA = NO_COLOR; } Klaus From owner-lynx-dev@sig.net Fri Nov 27 12:25:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA08016 for ; Fri, 27 Nov 1998 12:25:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA29017; Fri, 27 Nov 1998 11:04:58 -0600 (CST) Message-ID: <365E9CAE.A7F4164C@netsense.net> Date: Fri, 27 Nov 1998 07:35:58 -0500 From: Ghora Organization: none X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: lynx-dev@sig.net Subject: lynx-dev STMPhost not defined 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: 260 Lines: 9 Hello, How do i define the SMTPhost. I got this address from http://www.slcc.edu/lynx/current/index.html and was not directed to a general FAQ, so please do not disregard my basic question.. I can be contacted at: ktpr@bu.edu sincerely kwame porter-robinson From owner-lynx-dev@sig.net Fri Nov 27 12:49:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA09580 for ; Fri, 27 Nov 1998 12:49:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA01620; Fri, 27 Nov 1998 11:28:39 -0600 (CST) X-ROUTED: Fri, 27 Nov 1998 14:32:38 -0300 Message-ID: <000501be1a2b$bb87aee0$0ed410c8@Rave-N.comnet.com.ar> From: "Federico" To: Subject: lynx-dev Lynx Transl8 Date: Fri, 27 Nov 1998 14:31:14 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 166 Lines: 10 Hi! I'm from argentina, and i wanna help to translate lynx 2 spanish (my native lenguage) -federico@comnet.com.ar Comnet S.A. -rave-n@usa.net Unknown-d-menxion From owner-lynx-dev@sig.net Fri Nov 27 16:23:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA23859 for ; Fri, 27 Nov 1998 16:23:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA24740; Fri, 27 Nov 1998 14:49:44 -0600 (CST) Message-ID: <19981127125119.52940@shell3.ba.best.com> Date: Fri, 27 Nov 1998 12:51:19 -0800 From: Kim DeVaughn To: Lynx Developers Subject: lynx-dev Passing internal data to external handlers Mail-Followup-To: Lynx Developers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i 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: 1371 Lines: 33 Something that I like to do when I save documents, is to prepend a sort of "header block" to them, telling from where and when they were obtained. For example: >Linkname: Bzip2 Howto >From: http://www.best.com/~dfetter/Bzip2-HOWTO/Bzip2-HOWTO.html >Date: Fri Nov 27 12:05:49 PST 1998 >Last Mod: Tue, 18 Aug 1998 15:56:32 GMT > > I've been doing that "by hand" by first p(rinting) a copy of the Information (=) page, then appending the document proper to it (via my own PRINTER: definition, and handler script), then later going back and manually editing out all the extraneous Information page stuff. All of which is a PITA. What I'd like to be able to do, is pass various bits of internal information (title, url, etc) along to the PRINTER: handler in some way, and then let the script do with it as it wishes. The method that comes to mind, is along the lines of what "trn" does for similar purposes. That is, the user can specify all manner of internal information to be passed along to an external script, using a wide variety of %tokens, as formal args in the handler-invoking definition (eg, PRINTER: def, or whatever). Has something like this been considered before? Or is there some alternate way of accomplishing what I want to do, that I've overlooked? Would anyone besides myself find something like this to be a useful feature? /kim From owner-lynx-dev@sig.net Fri Nov 27 17:05:02 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA26216 for ; Fri, 27 Nov 1998 17:05:01 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA00459; Fri, 27 Nov 1998 15:36:48 -0600 (CST) Message-ID: <19981127144526.B310@bcpl.net> Date: Fri, 27 Nov 1998 14:45:26 -0500 From: Webmaster Jim To: lynx-dev@sig.net Cc: Karl Eichwalder , translation@iro.umontreal.ca Subject: Re: lynx-dev fwd: ...translations References: <000a01be1a1f$4f7182a0$0ed410c8@Rave-N.comnet.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <000a01be1a1f$4f7182a0$0ed410c8@Rave-N.comnet.com.ar>; from Federico on Fri, Nov 27, 1998 at 01:02:18PM -0300 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.93.2i with PGP 2.6.2 and ncurses 4.2 X-Of-Course-I-Run: NetBSD X-Operating-System: NetBSD netman2.bcpl.net 1.3.2 NetBSD 1.3.2 (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: 1437 Lines: 31 On Fri, Nov 27, 1998 at 01:02:18PM -0300, Federico wrote: > >I received the attached email from Francois and wanted to let the > >Lynx-dev team know where we are. When Francois has the time, he will > >help organize translation teams for Lynx support. In the meantime, I > >will be looking at the newer gettext code he has referenced to see where > >the template files could be improved. > Hi. I've subscribe that list to help in the lynx spanish version. I'm from > argentina and i wanna help in translate lynx to my native lenguage. I wanna > know who is the organizer of that 'department'. > -federico@comnet.com.ar > [and elsewhere wrote:] > Hi! I'm from argentina, and i wanna help to translate lynx 2 spanish (my > native lenguage) > -federico@comnet.com.ar > Comnet S.A. > -rave-n@usa.net > Unknown-d-menxion We are trying to coordinate Lynx native language support through a group known as the "Free Translation Project," who are also associated with the GNU project. See the following URLs, and the lynx-dev archives for prior discussions on this topic (the main idea here is that the GNU folks want paper copies of dislaimers in order to freely republish your translation efforts): ftp://prep.ai.mit.edu/pub/gnu/ABOUT-NLS http://www.iro.umontreal.ca/contrib/po/ http://www.iro.umontreal.ca/~pinard/ http://www.flora.org/lynx-dev/html/month1198/msg00340.html [etc.] ++++++++++++++++++++++++++++ Marvin the Paranoid Android. From owner-lynx-dev@sig.net Sat Nov 28 02:46:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA28102 for ; Sat, 28 Nov 1998 02:46:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA09768; Sat, 28 Nov 1998 01:31:55 -0600 (CST) Date: Sat, 28 Nov 1998 16:30:38 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811280730.QAA28664@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev fwd: ...translations Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1391 Lines: 28 > Yet in the long run (or more precisely, in the meantime waiting for a > new official release of `gettext'), best would be to use the following > instead: > > http://www.iro.umontreal.ca/contrib/po/gettext-0.10.35.tar.gz Definitely. Anyone interested in doing the translations for Lynx in a serious way should build and install this package. If you do the translations on a faulty template, which was true of all of the templates (*.po files) up to dev3 of the Lynx distribution, you are likely to lose some of your translations. The command "msgmerge" will help, but you are still likely to get "fuzzy" comments which will keep that string from getting compiled in (*.mo file). Having had hands on experience in translating and installing a working *.mo file, I cannot recommend enough not using what is in the Lynx distribution /intl and /po directories, and go directly to the gettext source referenced above. If you are on Solaris, I would heartily recommend using --with-included-gettext and --program-prefix=g when you configure for the GNU gettext library and tools. In the future Lynx may be able to use Sun's gettext, but I personally am going to wait until Sun gets their act together. I hate to see any of the translators waste their time. It takes only seconds to get an updated template and/or update your previous translations if you have the right tools. __Henry From owner-lynx-dev@sig.net Sat Nov 28 02:57:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id CAA28632 for ; Sat, 28 Nov 1998 02:57:58 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id BAA10735; Sat, 28 Nov 1998 01:45:10 -0600 (CST) Date: Sat, 28 Nov 1998 16:39:35 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811280739.QAA28748@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: RE: lynx-dev fwd: ...translations Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 646 Lines: 12 > Hi. I've subscribe that list to help in the lynx spanish version. I'm from > argentina and i wanna help in translate lynx to my native lenguage. I wanna > know who is the organizer of that 'department'. You might want to check recent lynx-dev archives. I think about two other people have expressed interest in a Spanish translation. Perhaps you could communicate off the list to coordinate a translation. You also should look into the home page of the GNU Native Language Support group to perhaps join the mailing list for Spanish translations, and to read (and hopefully sign) the disclaimer for the copyright on the translation. __Henry From owner-lynx-dev@sig.net Sat Nov 28 06:39:53 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA07859 for ; Sat, 28 Nov 1998 06:39:52 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA25561; Sat, 28 Nov 1998 05:25:20 -0600 (CST) From: David Woolley Message-Id: <199811272131.VAA10783@djwhome.demon.co.uk> Subject: Re: lynx-dev No CACHE To: lynx-dev@sig.net Date: Fri, 27 Nov 1998 21:30:58 +0000 (GMT) In-Reply-To: from "Georges El Asmar" at Nov 26, 98 03:08:07 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: 585 Lines: 10 > once a document is requested and has been cached, is there a way to > prevent lynx from getting the same document from the cache ( besides the > no cache command ie ^r) and instead send at least a request to check if > the document has been modified. This is the behavior of netscape..good > bye.Can you help me with that.thank you. In what sense does ^R not do exactly that? (Actually there are problems, as there is no clear distinction, in Lynx, between reload and revalidate, and it is not clear which ^R is; however, your wording indicated either behaviour to be acceptable.) From owner-lynx-dev@sig.net Sat Nov 28 08:22:43 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA13494 for ; Sat, 28 Nov 1998 08:22:42 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id HAA02618; Sat, 28 Nov 1998 07:10:18 -0600 (CST) To: lynx-dev@sig.net References: <19981120105556.54231@shell3.ba.best.com> <9811191809.AA11070@cas.org> Message-Id: From: "Leonid Pauzner" Date: Sat, 28 Nov 1998 16:06:02 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) 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: 16 > A couple other comments: > 1. A "delete to beginning-of-line" function would be pretty trivial to add > to LYStrings.[ch], though I've never had much need of it myself (which > is why I didn't also add it, when I added the del-to-eol function). A related subject: besides adding a new editing keys (which are not so easy to remember anyway), we have a following problem - while moving to beginning of line with "left arrow" or "backspace" we can easily went out of box and force go to previous document not intentionally... Is it possible to add a check so if we press several "left arrow" on input line we got a prompt (go to previous document? y/n [n]) before leaving that field by this key. Something like this. From owner-lynx-dev@sig.net Sat Nov 28 09:25:29 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA17075 for ; Sat, 28 Nov 1998 09:25:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA07843; Sat, 28 Nov 1998 08:09:45 -0600 (CST) Date: Sat, 28 Nov 1998 23:09:14 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811281409.XAA09114@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev proposed revisions for gettext (I) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2652 Lines: 51 In the weeks (months?) to come, I hope to go through all of the gettext calls and look at: 1) Does this string really need to be translated? Might it better convey its meaning in the original English? Is it worth being translated (especially when there is only one or two calls in the whole file). 2) How is the English itself? Is the meaning clear? Is there a more economical way to say it? 3) Could similar strings be simply stated in exactly the same way so that we can have one "msgid"? Also, when the string is found in more than one file, let's make it a define in LYMessages. 4) Has this string been cut or divided in such a way that English syntax is being forced, i.e., does the translator have enough working room? I hope there will be active discussion and input from the list, both from the view of the changes made to the original English string or page format, and from the point of view of native users of all the different languages who will be doing translations. The first patch in the series is to INSTALLATION. I consider it only temporary until the whole NLS thing gels more. __Henry *** lynx2-8-2/INSTALLATION.orig Sat Nov 28 20:11:45 1998 --- lynx2-8-2/INSTALLATION Sat Nov 28 20:17:20 1998 *************** *** 24,33 **** 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. The strings in LYMessages_en.h ! may be translated into a language of your choice. If you rename the file, ! be sure to change the definition in "userdefs.h". ! Step 2. (define run-time variables -- See the lynx.cfg file for details.) Set up local printers, downloaders, assumed character set, key mapping, and colors in the lynx.cfg file. Please read "lynx.cfg" thoroughly as --- 24,33 ---- 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, and colors in the lynx.cfg file. Please read "lynx.cfg" thoroughly as From owner-lynx-dev@sig.net Sat Nov 28 09:45:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA18425 for ; Sat, 28 Nov 1998 09:45:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA09572; Sat, 28 Nov 1998 08:28:52 -0600 (CST) Date: Sat, 28 Nov 1998 23:28:21 +0900 (JST) From: Nelson Henry Eric Message-Id: <199811281428.XAA09153@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: lynx-dev proposed revisions for gettext (II) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3060 Lines: 76 This patch to LYPrint.c attempts to alleviate the repetition (already in the and <H1>) of "Print options". There was an earlier patch to correct the string in question, but I don't think it was incorporated. To me it makes it easier to understand what "Print" means in the context of this menu. I thought the first call to aid the Novice user was frivolous. The second one should make clear what the first one is all about. Making it "page(s)" saves one msgid and also makes it easier to translate into a language like Japanese where singular/plural has no meaning. Is this acceptable to the English-speaking community? Having the "approximately" placed at the end, even in parentheses, makes it come out strange syntactically. How about other languages? __Henry *** lynx2-8-2/src/LYPrint.c.orig Sat Nov 28 22:42:40 1998 --- lynx2-8-2/src/LYPrint.c Sat Nov 28 22:38:04 1998 *************** *** 1309,1327 **** /* pages = lines_in_file/66 + 1; */ pages = (lines_in_file+65)/66; ! sprintf(buffer, " <em>%s</em> %s\n <em>%s</em> %d\n <em>%s</em> %d %s %s\n", gettext("Document:"), *printed_url, gettext("Number of lines:"), lines_in_file, ! gettext("Number of pages:"), pages, ! (pages > 1 ? gettext("pages") : gettext("page")), ! gettext("(approximately)")); fputs(buffer, fp0); if (no_print || no_disk_save || child_lynx || no_mail) fprintf(fp0, " <em>%s</em>\n", gettext("Some print functions have been disabled!")); ! fprintf(fp0, "\n%s %s\n", gettext("options:"), ! (user_mode == NOVICE_MODE) ? gettext("Standard print") : gettext("Print")); if (child_lynx == FALSE && no_disk_save == FALSE && no_print == FALSE) { fprintf(fp0, --- 1309,1325 ---- /* pages = lines_in_file/66 + 1; */ pages = (lines_in_file+65)/66; ! sprintf(buffer, " <em>%s</em> %s\n <em>%s</em> %d\n <em>%s</em> %s %d %s\n", gettext("Document:"), *printed_url, gettext("Number of lines:"), lines_in_file, ! gettext("Number of pages:"), ! gettext("approx."), pages, gettext("page(s)")); fputs(buffer, fp0); if (no_print || no_disk_save || child_lynx || no_mail) fprintf(fp0, " <em>%s</em>\n", gettext("Some print functions have been disabled!")); ! fprintf(fp0, "\n%s\n", gettext("\"Print\" actions to take on the rendered document:")); if (child_lynx == FALSE && no_disk_save == FALSE && no_print == FALSE) { fprintf(fp0, *************** *** 1349,1355 **** #endif if (user_mode == NOVICE_MODE) ! fprintf(fp0, "\n%s\n", gettext("Local additions:")); for (count = 0, cur_printer = printers; cur_printer != NULL; cur_printer = cur_printer->next, count++) --- 1347,1354 ---- #endif if (user_mode == NOVICE_MODE) ! fprintf(fp0,"\n%s %s\n", gettext("Locally configured"), ! gettext("\"Print\" actions to take on the rendered document:")); for (count = 0, cur_printer = printers; cur_printer != NULL; cur_printer = cur_printer->next, count++) From owner-lynx-dev@sig.net Sat Nov 28 09:51:34 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA18839 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 09:51:31 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA10297; Sat, 28 Nov 1998 08:36:51 -0600 (CST) Date: Sat, 28 Nov 1998 23:36:20 +0900 (JST) From: Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp> Message-Id: <199811281436.XAA09201@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (II) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 328 Lines: 8 > ! fprintf(fp0,"\n%s %s\n", gettext("Locally configured"), ^ ^ Sorry, that should be: ! fprintf(fp0,"\n%s%s\n", gettext("Locally configured "), ^ ^ For languages which do not put spaces between words. __Henry From owner-lynx-dev@sig.net Sat Nov 28 11:50:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA25785 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 11:50:43 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA22637; Sat, 28 Nov 1998 10:35:58 -0600 (CST) Message-ID: <19981128113449.A6166@mail.bcpl.net> Date: Sat, 28 Nov 1998 11:34:49 -0500 From: Webmaster Jim <jspath@bcpl.net> To: lynx-dev@sig.net Subject: Re: lynx-dev fwd: ...translations References: <199811280730.QAA28664@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811280730.QAA28664@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Sat, Nov 28, 1998 at 04:30:38PM +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._[/<C5~mEVeY5J1,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.93.2i (1998-07-29) 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: "<a href="http://www.jim.spath.com/">jim's subdomain</a>" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 864 Lines: 16 On Sat, Nov 28, 1998 at 04:30:38PM +0900, Nelson Henry Eric wrote: > > Yet in the long run (or more precisely, in the meantime waiting for a > > new official release of `gettext'), best would be to use the following > > instead: > > http://www.iro.umontreal.ca/contrib/po/gettext-0.10.35.tar.gz > Definitely. Anyone interested in doing the translations for Lynx in a > serious way should build and install this package. Not knowing any better at the time, I used the gettext package archived at the GNU ftp site. I agree that since the older version has bugs, Lynx should use the newer one. The UMontreal pacakage is 750K compressed, so I would not want it in the Lynx distribution. ------ <http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm> Marvin the Paranoid Android says: I just thought I'd warn you - this will be a waste of time. From owner-lynx-dev@sig.net Sat Nov 28 12:02:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA26470 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 12:02:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA23951; Sat, 28 Nov 1998 10:48:37 -0600 (CST) Message-ID: <19981128084801.65449@shell3.ba.best.com> Date: Sat, 28 Nov 1998 08:48:01 -0800 From: Kim DeVaughn <kimdv@best.com> To: lynx-dev@sig.net Subject: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) Mail-Followup-To: lynx-dev@sig.net References: <19981120105556.54231@shell3.ba.best.com> <9811191809.AA11070@cas.org> <Pine.GSO.4.05.9811200720170.353-100000@Stratus.CAM.ORG> <ABwK_NsK37@pauzner.mccme.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <ABwK_NsK37@pauzner.mccme.ru>; from Leonid Pauzner on Sat, Nov 28, 1998 at 04:06:02PM +0300 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: 1170 Lines: 26 On Sat, Nov 28, 1998, Leonid Pauzner (uue@pauzner.mccme.ru) said: | | > A couple other comments: | | > 1. A "delete to beginning-of-line" function would be pretty trivial to add | > to LYStrings.[ch], though I've never had much need of it myself (which | > is why I didn't also add it, when I added the del-to-eol function). | | A related subject: | besides adding a new editing keys (which are not so easy to remember anyway), | we have a following problem - while moving to beginning of line | with "left arrow" or "backspace" we can easily went out of box | and force go to previous document not intentionally... | | Is it possible to add a check so if we press several "left arrow" | on input line we got a prompt (go to previous document? y/n [n]) | before leaving that field by this key. Something like this. With what function do you see this behavior? And on what platform? With v2.8.1-rel.2? I don't see this with the /-search or g(oto) functions, nor when entering a filename for (say) the p(rint) function. Instead, when the BOL is reached with the cursor, further attempts to "move left" by either the left-arrow or backspace are ignored. /kim From owner-lynx-dev@sig.net Sat Nov 28 12:11:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA27014 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 12:11:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA24972; Sat, 28 Nov 1998 10:58:54 -0600 (CST) Message-ID: <19981128115746.B6166@mail.bcpl.net> Date: Sat, 28 Nov 1998 11:57:46 -0500 From: Webmaster Jim <jspath@bcpl.net> To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (I) References: <199811281409.XAA09114@ews07.nara.kindai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811281409.XAA09114@ews07.nara.kindai.ac.jp>; from Nelson Henry Eric on Sat, Nov 28, 1998 at 11:09:14PM +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._[/<C5~mEVeY5J1,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.93.2i (1998-07-29) 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: "<a href="http://www.jim.spath.com/">jim's subdomain</a>" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2474 Lines: 55 On Sat, Nov 28, 1998 at 11:09:14PM +0900, Nelson Henry Eric wrote: > In the weeks (months?) to come, I hope to go through all of the > gettext calls and look at: > 1) Does this string really need to be translated? Might > it better convey its meaning in the original English? > Is it worth being translated (especially when there is > only one or two calls in the whole file). I agree half-heartedly. When that rare message appears, how would a non-English speaker deal with it? > 2) How is the English itself? Is the meaning clear? Is > there a more economical way to say it? Definitely, except let's not make translator's work obsolete by changing dozens of lines for the heck of it. > 3) Could similar strings be simply stated in exactly the > same way so that we can have one "msgid"? Also, when > the string is found in more than one file, let's make > it a define in LYMessages. Yes, and no. The tools will automagically merge messages from different modules. I disagree with having #defines except as bug workarounds. Leaving the messages in place may help translators decide the best idioms based on context. Seeing the same message in many places would tell me that the *code* could be combined into subroutines (this should please you Henry if we shave some more bytes off the source and executables :-). I noticed in my work the same code had been cut-and-pasted in some modules (some of this was seen by others and cleaned up during my work). > 4) Has this string been cut or divided in such a way that > English syntax is being forced, i.e., does the translator > have enough working room? At the risk of repeating myself, there are some messages with embedded strings or numbers that may need re-work to be more language-independent (see the CSuite notes in the fr.mo file). Multi-line messages that include formatted in them should be easy to find for revision discussion. In addition to the INSTALLATION notes that Henry has modified, I am interested in having the help pages be multi-lingual. Since these are outside the code/gettext context, perhaps they could by worked independently on by volunteers? I will be happy to install them at SLCC. Suggestions for URL template (e.g., http://www.slcc.edu/lynx/fr/lynx_aide.html)? ----- <http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm> Marvin the Paranoid Android says: I just thought I'd warn you - this will be a waste of time. From owner-lynx-dev@sig.net Sat Nov 28 12:50:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA29367 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 12:50:28 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA29163; Sat, 28 Nov 1998 11:35:18 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Sat, 28 Nov 1998 12:35:25 -0500 (EST) From: Ismael Cordeiro <ismael@cordeiro.com> X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (II) In-Reply-To: <199811281428.XAA09153@ews07.nara.kindai.ac.jp> Message-ID: <Pine.GSO.4.05.9811281154150.25721-100000@Stratus.CAM.ORG> 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: 2910 Lines: 56 On Sat, 28 Nov 1998, Nelson Henry Eric wrote: > This patch to LYPrint.c attempts to alleviate the repetition (already in > the <TITLE> and <H1>) of "Print options". There was an earlier patch to > correct the string in question, but I don't think it was incorporated. To > me it makes it easier to understand what "Print" means in the context of > this menu. I find your modifications too verbose. I think the present format is clear enough. Even in the first time I used Lynx I had no problems undertanding what the options in that menu meant. I would hate to see something like `"Print" actions to be taken on the rendered document when you press Return or the right-cursor, or any other key with the same effect, over the option you choose by moving the cursor with the down- or up-cursor:'. Another more important point is that strings shouldn't be split. Splitting strings may work in English but not in other languages with different structures. For instance, in your patch, `Locally configured "Print" actions to be taken on the rendered document:' and `"Print" actions to be taken on the rendered document:' should be separate strings. This is valid for all strings in Lynx. > I thought the first call to aid the Novice user was frivolous. The second > one should make clear what the first one is all about. As I said above, I find the `Locally configured "Print" actions to take on the rendered document:" too verbose. If you want to make "Local additions:" clearer, it would be better to use something like "Locally configured options:", but I find "Local additions:" clear enough. > Making it "page(s)" saves one msgid and also makes it easier to translate > into a language like Japanese where singular/plural has no meaning. Is this > acceptable to the English-speaking community? I don't find it acceptable, even in English. The present format, "page" for one-page documents and "pages" for more-than-one-page documents, is cleaner. Besides, other languages don't necessarily use an "s", or other letter added to the end, to make the plural. For example, in Latin the plural of "paginam" is not "paginams" but "paginas" and the plural of "paginae" is not "paginaes" but "paginarum". "page" and "pages" must be different strings. > Having the "approximately" placed at the end, even in parentheses, makes it > come out strange syntactically. How about other languages? I find the "(approximately)" necessary, and the way it's now seems to be the best compromise for clarity and compatibility with other languages. 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 Sat Nov 28 12:50:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA29375 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 12:50:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA29328; Sat, 28 Nov 1998 11:36:52 -0600 (CST) Message-ID: <19981128123543.A15487@mail.bcpl.net> Date: Sat, 28 Nov 1998 12:35:43 -0500 From: Webmaster Jim <jspath@bcpl.net> To: lynx-dev@sig.net Subject: lynx-dev AltaVista URL moved Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Face: $[):DI3,{Z,[[9Gb^H.yPU[6-J}^Co2e-J!p*jQ>Q8++K~?Ejg~3#,vmYi;O8E55~r~#wa2 WdUS{+X2e6mt${6._[/<C5~mEVeY5J1,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.93.2i (1998-07-29) 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: "<a href="http://www.jim.spath.com/">jim's subdomain</a>" Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 873 Lines: 24 Patch for AltaVista site: *** lynx_help_main.html.df Sat Oct 24 10:49:07 1998 --- lynx_help_main.html Sat Nov 28 10:35:31 1998 *************** *** 76,82 **** <H2>Search engines:</H2> <ul> ! <li><a href="http://www.altavista.digital.com/">Alta Vista</a> <li><a href="http://www.excite.com/">Excite</a> <li><a href="http://www.infind.com/">Inference Find</a> <li><a href="http://guide.Infoseek.com/">Infoseek</a> --- 76,82 ---- <H2>Search engines:</H2> <ul> ! <li><a href="http://www.altavista.com/">AltaVista</a> <li><a href="http://www.excite.com/">Excite</a> <li><a href="http://www.infind.com/">Inference Find</a> <li><a href="http://guide.Infoseek.com/">Infoseek</a> ------ <http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm> Marvin the Paranoid Android says: I just thought I'd warn you - this will be a waste of time. From owner-lynx-dev@sig.net Sat Nov 28 13:24:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA31105 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 13:24:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03000; Sat, 28 Nov 1998 12:10:18 -0600 (CST) To: lynx-dev@sig.net References: <19981128115746.B6166@mail.bcpl.net> <199811281409.XAA09114@ews07.nara.kindai.ac.jp> Message-Id: <AF-k3OsGzU@pauzner.mccme.ru> From: "Leonid Pauzner" <uue@pauzner.mccme.ru> Date: Sat, 28 Nov 1998 21:06:54 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev proposed revisions for gettext (I) 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: 280 Lines: 6 > could by worked independently on by volunteers? I will be happy > to install them at SLCC. Suggestions for URL template (e.g., > http://www.slcc.edu/lynx/fr/lynx_aide.html)? Probably the same filename and the same href="#link" for different languages, just another directory? From owner-lynx-dev@sig.net Sat Nov 28 13:25:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA31113 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 13:25:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03026; Sat, 28 Nov 1998 12:10:32 -0600 (CST) To: lynx-dev@sig.net References: <19981128084801.65449@shell3.ba.best.com> <19981120105556.54231@shell3.ba.best.com> <9811191809.AA11070@cas.org> <Pine.GSO.4.05.9811200720170.353-100000@Stratus.CAM.ORG> <ABwK_NsK37@pauzner.mccme.ru> Message-Id: <ABbL3OsGzU@pauzner.mccme.ru> From: "Leonid Pauzner" <uue@pauzner.mccme.ru> Date: Sat, 28 Nov 1998 20:39:49 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) 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: 426 Lines: 12 > With what function do you see this behavior? And on what platform? With > v2.8.1-rel.2? With any forms input field (try in options menu, for example). > I don't see this with the /-search or g(oto) functions, nor when entering > a filename for (say) the p(rint) function. Instead, when the BOL is > reached with the cursor, further attempts to "move left" by either the > left-arrow or backspace are ignored. > /kim From owner-lynx-dev@sig.net Sat Nov 28 13:25:54 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA31119 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 13:25:53 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03004; Sat, 28 Nov 1998 12:10:21 -0600 (CST) To: lynx-dev@sig.net References: <199811281428.XAA09153@ews07.nara.kindai.ac.jp> Message-Id: <ADze3OsGzU@pauzner.mccme.ru> From: "Leonid Pauzner" <uue@pauzner.mccme.ru> Date: Sat, 28 Nov 1998 21:00:29 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev proposed revisions for gettext (II) 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: 431 Lines: 10 > This patch to LYPrint.c attempts to alleviate the repetition ... > Making it "page(s)" saves one msgid and also makes it easier to > translate into a language like Japanese where singular/plural has > no meaning. Is this acceptable to the English-speaking community? Is there a great problem to place the same japanese equivalent for both "page" and "pages"? It would be a better idea than degrade english wording and code. From owner-lynx-dev@sig.net Sat Nov 28 13:27:59 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA31349 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 13:27:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA03449; Sat, 28 Nov 1998 12:14:41 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Sat, 28 Nov 1998 13:14:47 -0500 (EST) From: Ismael Cordeiro <ismael@cordeiro.com> X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev AltaVista URL moved In-Reply-To: <19981128123543.A15487@mail.bcpl.net> Message-ID: <Pine.GSO.4.05.9811281313310.27749-100000@Stratus.CAM.ORG> 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: 532 Lines: 14 On Sat, 28 Nov 1998, Webmaster Jim wrote: > <li><a href="http://guide.Infoseek.com/">Infoseek</a> This one can also be changed to http://www.infoseek.com/ 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 Sat Nov 28 14:06:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA00835 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 14:06:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA07361; Sat, 28 Nov 1998 12:52:54 -0600 (CST) Date: Sat, 28 Nov 1998 13:49:29 EST5EDT4,M4.1.0,M10.5.0 From: "Harris, Mark" <mharris@monroecc.edu> To: LYNX-DEV@sig.net Message-ID: <009CFE5E.62694AD6.9@monroecc.edu> Subject: lynx-dev Help Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 352 Lines: 5 I can't get into my Hotmail while using the LYNX browser. It says I have to download the text before I can get into my Hotmail account. It just started doing this a couple days ago, I've never had any problems before. I was wondering if you could help me because I have no idea how to download my account and then still be able to get to it. Thankyou. From owner-lynx-dev@sig.net Sat Nov 28 14:17:01 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA01426 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 14:16:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA08408; Sat, 28 Nov 1998 13:03:40 -0600 (CST) Message-ID: <19981128110334.28628@shell3.ba.best.com> Date: Sat, 28 Nov 1998 11:03:34 -0800 From: Kim DeVaughn <kimdv@best.com> To: lynx-dev@sig.net Subject: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) Mail-Followup-To: lynx-dev@sig.net References: <19981128084801.65449@shell3.ba.best.com> <19981120105556.54231@shell3.ba.best.com> <9811191809.AA11070@cas.org> <Pine.GSO.4.05.9811200720170.353-100000@Stratus.CAM.ORG> <ABwK_NsK37@pauzner.mccme.ru> <ABbL3OsGzU@pauzner.mccme.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <ABbL3OsGzU@pauzner.mccme.ru>; from Leonid Pauzner on Sat, Nov 28, 1998 at 08:39:49PM +0300 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: 701 Lines: 17 On Sat, Nov 28, 1998, Leonid Pauzner (uue@pauzner.mccme.ru) said: | | > With what function do you see this behavior? And on what platform? With | > v2.8.1-rel.2? | | With any forms input field (try in options menu, for example). Ah, OK. I see that (returning to the previous page) when I use the left- arrow at the beginning of a forms input line, but NOT when I use the backspace key there (which is just ignored as expected, on our FreeBSD port). I *suspect* the problem is in the forms-handling code, as opposed to the general key-handling code, and I'm not familier with that at all. Perhaps someone who is forms-wise can take a look at this, as it really shouldn't be doing that, IMO. /kim From owner-lynx-dev@sig.net Sat Nov 28 15:02:18 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA03993 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 15:02:17 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id NAA12630; Sat, 28 Nov 1998 13:47:09 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811281946.MAA10688@sanitas> Subject: Re: lynx-dev AltaVista URL moved To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 12:46:31 -0700 (MST) In-Reply-To: <19981128123543.A15487@mail.bcpl.net> from "Webmaster Jim" at Nov 28, 98 12:35:43 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: 291 Lines: 10 In a recent note, Webmaster Jim said: > Date: Sat, 28 Nov 1998 12:35:43 -0500 > > ! <li><a href="http://www.altavista.com/">AltaVista</a> > Interesting. I thought I had heard that an opportunist (other than DEC) had registered "altavista.com". Apparently this has been resolved. -- gil From owner-lynx-dev@sig.net Sat Nov 28 15:27:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA05528 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 15:27:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA15370; Sat, 28 Nov 1998 14:13:55 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811282012.PAA24168@chass.utoronto.ca> Subject: Re: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 15:12:24 -0500 (EST) In-Reply-To: <19981128110334.28628@shell3.ba.best.com> from "Kim DeVaughn" at Nov 28, 98 11:03:34 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: 1020 Lines: 20 981128 Kim wrote: > Ah, OK. I see that (returning to the previous page) > when I use the left-arrow at the beginning of a forms input line, > but NOT when I use the backspace key there > (which is just ignored as expected, on our FreeBSD port). > I *suspect* the problem is in the forms-handling code, > as opposed to the general key-handling code, > and I'm not familier with that at all. > Perhaps someone who is forms-wise can take a look at this, > as it really shouldn't be doing that, IMO. this is another reason for some public-spirited programmer finally to do the coding to allow normal editing of form entry fields. is it that difficult, incl a simple switch to disallow it for anon's? LP, you raised this thread: are you upto it (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 Sat Nov 28 15:29:57 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA05542 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 15:29:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA15694; Sat, 28 Nov 1998 14:16:09 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811282014.PAA24371@chass.utoronto.ca> Subject: Re: lynx-dev AltaVista URL moved To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 15:14:38 -0500 (EST) In-Reply-To: <199811281946.MAA10688@sanitas> from "pg@sweng.stortek.com" at Nov 28, 98 12:46: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: 549 Lines: 12 981128 gil wrote re <li><a href="http://www.altavista.com/">AltaVista</a> > Interesting. I thought I had heard that an opportunist > (other than DEC) had registered "altavista.com". > Apparently this has been resolved. yes, they settled the court case a couple of months ago. -- ========================,,============================================ 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 Nov 28 17:27:04 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA12246 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 17:27:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA26462; Sat, 28 Nov 1998 16:07:42 -0600 (CST) Message-ID: <19981128140734.23918@shell3.ba.best.com> Date: Sat, 28 Nov 1998 14:07:34 -0800 From: Kim DeVaughn <kimdv@best.com> To: lynx-dev@sig.net Subject: lynx-dev Editing text entry fields (was: Re: New editing key bindings) Mail-Followup-To: lynx-dev@sig.net References: <19981128110334.28628@shell3.ba.best.com> <199811282012.PAA24168@chass.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <199811282012.PAA24168@chass.utoronto.ca>; from Philip Webb on Sat, Nov 28, 1998 at 03:12:24PM -0500 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: 1972 Lines: 48 On Sat, Nov 28, 1998, Philip Webb (purslow@chass.utoronto.ca) said: | | 981128 Kim wrote: | > | > I *suspect* the problem is in the forms-handling code, | > as opposed to the general key-handling code, | > and I'm not familier with that at all. | > Perhaps someone who is forms-wise can take a look at this, | > as it really shouldn't be doing that, IMO. | | this is another reason for some public-spirited programmer | finally to do the coding to allow normal editing of form entry fields. | is it that difficult, incl a simple switch to disallow it for anon's? I saw this suggeted in another message, and was going to reply to it, but got called away, and then forgot to. Lemee see if I understand what's being proposed ... You're suggesting that whenever I come across some lines that are for some textual information to be entered and returned to the hosting site, such as: _________________ _________________ _________________ that I could instead of trying to use the indicated line(s), have my EDITOR invoked, enter my input, and then when I've quit the editor, the text that I provided from within the editor, would be "in" those lines? If my interpretation is correct, that'd be a GREAT improvement, as the damn lines provided are most always way too short, and too few, to see what I'm actually entering. Since I know very little about how such things are specified in the source html, I do wonder though, if amount of text entered from an editor, might not "overflow" the expected maximum that the page specified (if such is indeed specified), in either lines or bytes. Or is that not a problem ...? And BTW, thanks to whomever did the EXTERNAL: stuff. That nicely solves the above problem when I come across a mailto: field that I want to respond to (so long as I remember to trim the "mailto:" string from the address :-) ). | LP, you raised this thread: are you upto it (smile)? Sounds good to me too, if the time's available ...! /kim From owner-lynx-dev@sig.net Sat Nov 28 18:01:35 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA14554 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 18:01:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA00276; Sat, 28 Nov 1998 16:47:46 -0600 (CST) Date: Sat, 28 Nov 1998 16:47:45 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) In-Reply-To: <19981128110334.28628@shell3.ba.best.com> Message-ID: <Pine.SUN.3.95.981128164250.25666A-100000@xochi.tezcat.com> 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: 18 On Sat, 28 Nov 1998, Kim DeVaughn wrote: > Ah, OK. I see that (returning to the previous page) when I use the left- > arrow at the beginning of a forms input line, but NOT when I use the > backspace key there (which is just ignored as expected, on our FreeBSD > port). What you want is already there, at least in part. Change something in a text input form field, then move with the left-arrow key to the beginning and try to move further left. You should get a prompt: Do you want to go back to the previous document? [N] Klaus From owner-lynx-dev@sig.net Sat Nov 28 19:03:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA18139 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 19:03:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA06227; Sat, 28 Nov 1998 17:45:21 -0600 (CST) To: lynx-dev@sig.net References: <Pine.SUN.3.95.981128164250.25666A-100000@xochi.tezcat.com> Message-Id: <ABid8Osuf4@pauzner.mccme.ru> From: "Leonid Pauzner" <uue@pauzner.mccme.ru> Date: Sun, 29 Nov 1998 02:40:28 +0300 (MSK) X-Mailer: dMail [Demos Mail for DOS v2.07b] Subject: Re: lynx-dev Re: New editing key bindings (was Re: lynx2.8.2dev.4) 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: 902 Lines: 26 > On Sat, 28 Nov 1998, Kim DeVaughn wrote: >> Ah, OK. I see that (returning to the previous page) when I use the left- >> arrow at the beginning of a forms input line, but NOT when I use the >> backspace key there (which is just ignored as expected, on our FreeBSD >> port). > What you want is already there, at least in part. > Change something in a text input form field, then move with the left-arrow > key to the beginning and try to move further left. You should get a > prompt: > Do you want to go back to the previous document? [N] There is an additional complication: when input string too long we see only a part and should sometimes "scroll" it to see the contents. So the prompt also reasonable in such scrolling, not only when we have changed something. It is safer to issue a prompt than say mercy (and forms documents usually not cached and causing a delay). > Klaus From owner-lynx-dev@sig.net Sat Nov 28 19:41:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id TAA20396 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 19:41:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA10879; Sat, 28 Nov 1998 18:26:44 -0600 (CST) Date: Sat, 28 Nov 1998 16:26:42 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: lynx-dev Possible bug with link numbering Message-Id: <Pine.SUN.3.96.981128160754.24532A-100000@waltz> 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: 2666 Lines: 67 While attempting to investigate a recent complaint on the list about hotmail, I noticed an anomaly in regard to link numbering, in that links that were numbered on the screen (with links and form fields numbered) could not be reached with arrow keys, and could not be reached with the number + "g" command. I am attaching the print to file of the main screen at "http://www.hotmail.com". Links number 1 and 5 to "spacer.gif" were not included in the numbering for the "g" command. The commmand "20g" puts the cursor on link 22 on the screen. It appears that screen links 1 and 5 aren't counted when the "g" command is counting, but are when the screen is numbered. I tried looking at the source to the html, but didn't see the problem. This is with lynx2.8.2dev.6 running on SunOS 4.1.3_U1, set with VERBOSE_IMAGES TRUE. I compiled with gcc and slang. Perhaps someone can see where the numbering logic diverges. The file "spacer.gif" does exist, and can be reached with the URL on lynx's command line. Doug [1]- [2][MSN Hotmail Logo] [3]The World's FREE Web-Based Email Free Email ( Electronic Mail ) on the Internet using your Web Browser. [4]Registered Users [5]- [6]Login Name: [7]Password: [8]________________ [9]________________ [10]Enter [11](_) [12]Frames [13](_) [14]No Frames [15](_) [16]Use my Default [17]Forgot Your Password?-[18][home_do_passwdret.gif] [19][ISMAP:home_do_map.gif]-[20]Learn More About Hotmail-[21][home_do_map.gif] No software. No configuration other than optional one-time POP Mail setup. [22]Copyright 1996-1998 References 1. http://209.1.112.251/spacer.gif 2. http://209.1.112.251/logo_msnhm_lg.gif 3. http://209.1.112.251/slogan_bl.gif 4. http://209.1.112.251/home_lblreg2.gif 5. http://209.1.112.251/spacer.gif 6. http://209.1.112.251/home_lbllogin.gif 7. http://209.1.112.251/home_lblpasswd.gif 8. form field = text entry field 9. form field = password entry field 10. form field = submit button 11. form field = radio button 12. http://209.1.112.251/home_lblframes.gif 13. form field = radio button 14. http://209.1.112.251/home_lblnoframes.gif 15. form field = radio button 16. http://209.1.112.251/home_lbldefault.gif 17. http://www.hotmail.com/cgi-bin/dasp/passwdret.asp 18. http://209.1.112.251/home_do_passwdret.gif 19. http://www.hotmail.com/cgi-bin/indexmap.cgi 20. LYNXIMGMAP:http://www.hotmail.com/#mainmap 21. http://209.1.112.251/home_do_map.gif 22. http://209.1.112.251/c9698.gif __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sat Nov 28 22:20:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA01937 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 22:20:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA27870; Sat, 28 Nov 1998 21:02:47 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811290301.WAA19878@chass.utoronto.ca> Subject: Re: lynx-dev Possible bug with link numbering To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 22:01:16 -0500 (EST) In-Reply-To: <Pine.SUN.3.96.981128160754.24532A-100000@waltz> from "Doug Kaufman" at Nov 28, 98 04:26:42 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: 1435 Lines: 32 981128 Doug Kaufman wrote: > I am attaching the print to file of the main screen > at "http://www.hotmail.com". Links number 1 and 5 to "spacer.gif" > were not included in the numbering for the "g" command. > It appears that screen links 1 and 5 aren't counted when the > "g" command is counting, but are when the screen is numbered. > I tried looking at the source to the html, but didn't see the problem. > This is with lynx2.8.2dev.6 running on SunOS 4.1.3_U1, > set with VERBOSE_IMAGES TRUE. I compiled with gcc and slang. > The file "spacer.gif" does exist, > and can be reached with the URL on lynx's command line. > > [1]- > [2][MSN Hotmail Logo] > [3]The World's FREE Web-Based Email > Free Email ( Electronic Mail ) on the Internet > using your Web Browser. > [4]Registered Users > [5]- > [6]Login Name: [7]Password: > [8]________________ [9]________________ [10]Enter -- snip -- using 2-8-1rel.1 with verbose images & -tagsoup , Lynx numbers the two input fields above [1] & [2]. all the previous items [1] - [7] in DK's version are images in a table: isn't this a case of HTML soup which the switch strains correctly? -- ========================,,============================================ SUPPORT ___________//___, Philip Webb : purslow@chass.utoronto.ca ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT `-O----------O---' University of Toronto From asgilman@access.digex.net Sat Nov 28 22:25:52 1998 Received: from access5.digex.net (qlE46B5DiGQyA@access5.digex.net [205.197.245.196]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA02396 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 22:25:50 -0500 Received: (from asgilman@localhost) by access5.digex.net (8.8.4/8.8.4) id WAA12953 for lynx-dev-archive@flora.org; Sat, 28 Nov 1998 22:25:22 -0500 (EST) Received: (from asgilman@localhost) by access1.digex.net (8.8.4/8.8.4) id QAA19840; Sat, 28 Nov 1998 16:53:56 -0500 (EST) Date: Sat, 28 Nov 1998 16:53:56 -0500 (EST) Message-Id: <199811282153.QAA19840@access1.digex.net> To: ramona@netsense.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-URL: http://www.flora.org/lynx-dev/html/month1198/msg00774.html X-Mailer: Lynx, Version 2.8.1dev.7 From: asgilman@access.digex.net (Al Gilman) Subject: Re: SMTP host not defined Cc: asgilman@access.digex.net (Al Gilman) Sender: asgilman@access.digex.net Status: RO Content-Length: 749 Lines: 21 > * Subject: lynx-dev STMPhost not defined > * From: Ghora <[6]ramona@netsense.net> > * Date: Fri, 27 Nov 1998 07:35:58 -0500 > _________________________________________________________________ > >How do i define the SMTPhost. I got this address from >[9]http://www.slcc.edu/lynx/current/index.html and was not directed to a >general FAQ, so please do not disregard my basic question.. I can be >contacted at: ktpr@bu.edu > >sincerely >kwame porter-robinson I am going to assume you are installing on Windows 95 or 98. Read the file sendmail.txt that comes with the distribution. There is a line in there that you need to copy into your lynx.cfg and edit appropriately. If you are on another OS check the comments in lynx.cfg. Al From owner-lynx-dev@sig.net Sat Nov 28 22:34:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id WAA03277 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 22:34:15 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id VAA29882; Sat, 28 Nov 1998 21:21:51 -0600 (CST) Date: Sat, 28 Nov 1998 22:21:48 -0500 (EST) Message-Id: <199811290321.WAA12892@access5.digex.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.flora.org/lynx-dev/html/month1198/msg00802.html X-Mailer: Lynx, Version 2.8.1dev.7 From: asgilman@access.digex.net (Al Gilman) Subject: lynx-dev verbose++ images ignored in clicable navigation Cc: asgilman@access.digex.net (Al Gilman) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 166 Lines: 4 Well, it does sound like something is not totally together between 123g and verbose images, as it is the links added by the verbose shift that are getting missed. Al From owner-lynx-dev@sig.net Sat Nov 28 23:18:41 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA08092 for <lynx-dev-archive@flora.org>; Sat, 28 Nov 1998 23:18:40 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA04595; Sat, 28 Nov 1998 22:03:20 -0600 (CST) Date: Sat, 28 Nov 1998 20:03:18 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Possible bug with link numbering In-Reply-To: <199811290301.WAA19878@chass.utoronto.ca> Message-Id: <Pine.SUN.3.96.981128200025.7453A-100000@waltz> 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: 16 On Sat, 28 Nov 1998, Philip Webb wrote: > using 2-8-1rel.1 with verbose images & -tagsoup , > Lynx numbers the two input fields above [1] & [2]. > all the previous items [1] - [7] in DK's version are images in a table: > isn't this a case of HTML soup which the switch strains correctly? I should have mentioned - I tried with both parsers and with minimal, historical, and valid comments before I wrote my note. Nothing made a difference. The links are numbered on the screen; you just can't go to them. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Nov 29 00:04:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA13475 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 00:04:46 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA10077; Sat, 28 Nov 1998 22:46:24 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811290444.XAA24986@chass.utoronto.ca> Subject: Re: lynx-dev Possible bug with link numbering To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 23:44:53 -0500 (EST) In-Reply-To: <Pine.SUN.3.96.981128200025.7453A-100000@waltz> from "Doug Kaufman" at Nov 28, 98 08:03:18 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: 1679 Lines: 46 981128 Doug Kaufman wrote: > On Sat, 28 Nov 1998, Philip Webb wrote: >> using 2-8-1rel.1 with verbose images & -tagsoup , >> Lynx numbers the two input fields above [1] & [2]. >> all the previous items [1] - [7] in DK's version are images in a table: >> isn't this a case of HTML soup which the switch strains correctly? > I tried with both parsers and with minimal, historical & valid comments > before I wrote my note. Nothing made a difference. > The links are numbered on the screen; you just can't go to them. what i see is: - [MSN Hotmail Logo] The World's FREE Web-Based Email Free Email ( Electronic Mail ) on the Internet using your Web Browser. Registered Users - Login Name: Password: [1]________________ [2]________________ [3]Enter [4](_) Frames [5](_) No Frames [6](_) Use my Default [7]Forgot Your Password? [8][ISMAP:home_do_map.gif]-[9]Learn More About Hotmail No software. No configuration other than optional one-time POP Mail setup. Copyright 1996-1998 References 1. form field = text entry field 2. form field = password entry field 3. form field = submit button 4. form field = radio button 5. form field = radio button 6. form field = radio button 7. http://www.hotmail.com/cgi-bin/dasp/passwdret.asp 8. http://www.hotmail.com/cgi-bin/indexmap.cgi 9. LYNXIMGMAP:http://www.hotmail.com/#mainmap -- ========================,,============================================ 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 Nov 29 00:17:27 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA14055 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 00:17:26 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA11888; Sat, 28 Nov 1998 23:01:38 -0600 (CST) Date: Sat, 28 Nov 1998 21:01:36 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Possible bug with link numbering In-Reply-To: <199811290444.XAA24986@chass.utoronto.ca> Message-Id: <Pine.SUN.3.96.981128205245.9464A-100000@waltz> 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: 536 Lines: 20 On Sat, 28 Nov 1998, Philip Webb wrote: > 981128 Doug Kaufman wrote: > > ... > > The links are numbered on the screen; you just can't go to them. > > what i see is: > > - > [MSN Hotmail Logo] You have VERBOSE_IMAGES turned off. The (possible) bug only is present with VERBOSE_IMAGES turned on. I am talking about the different numbering seen on the screen versus that acted upon by the 123g code. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Nov 29 01:00:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA18717 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 01:00:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA16653; Sat, 28 Nov 1998 23:46:08 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811290544.AAA27056@chass.utoronto.ca> Subject: Re: lynx-dev Possible bug with link numbering To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 00:44:38 -0500 (EST) In-Reply-To: <Pine.SUN.3.96.981128205245.9464A-100000@waltz> from "Doug Kaufman" at Nov 28, 98 09:01: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: 587 Lines: 14 981129 Doug Kaufman wrote: > You have VERBOSE_IMAGES turned off. > The (possible) bug only is present with VERBOSE_IMAGES turned on. > I am talking about the different numbering seen on the screen > versus that acted upon by the 123g code. from my Options screen: Verbose images : [15][(2)__ON_] -- ========================,,============================================ 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 Nov 29 01:53:12 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id BAA24625 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 01:53:10 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id AAA20927; Sun, 29 Nov 1998 00:36:23 -0600 (CST) Date: Sat, 28 Nov 1998 22:36:22 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Possible bug with link numbering In-Reply-To: <199811290544.AAA27056@chass.utoronto.ca> Message-Id: <Pine.SUN.3.96.981128223211.14460A-100000@waltz> 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: 840 Lines: 23 On Sun, 29 Nov 1998, Philip Webb wrote: > 981129 Doug Kaufman wrote: > > You have VERBOSE_IMAGES turned off. > > The (possible) bug only is present with VERBOSE_IMAGES turned on. > > I am talking about the different numbering seen on the screen > > versus that acted upon by the 123g code. > > from my Options screen: > > Verbose images : [15][(2)__ON_] My apologies. You are correct that VERBOSE_IMAGES is not the critical switch. It is really image_links that matters here. Sorry that I got them confused. To see the behavior I described, either set MAKE_LINKS_FOR_ALL_IMAGES to TRUE in lynx.cfg, run lynx as "lynx -image_links" or hit the "*" key from within lynx to turn on image_links. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Nov 29 05:00:11 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA11834 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 04:59:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA01937; Sun, 29 Nov 1998 03:25:05 -0600 (CST) From: David Woolley <david@djwhome.demon.co.uk> Message-Id: <199811281212.MAA12028@djwhome.demon.co.uk> Subject: Re: lynx-dev STMPhost not defined To: lynx-dev@sig.net Date: Sat, 28 Nov 1998 12:12:15 +0000 (GMT) Cc: ramona@netsense.net In-Reply-To: <365E9CAE.A7F4164C@netsense.net> from "Ghora" at Nov 27, 98 07:35: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: 1461 Lines: 30 > > How do i define the SMTPhost. I got this address from Depends on what operating system and which version of Lynx you are using. In particular, Unix, and VMS versions of Lynx use the operating system's mail sending facilities, so don't need to know the SMTP Host themselves. The string SMTP doesn't occur anywhere in the Linux binaries for Lynx 2.7.2, and only occurs in the source with reference to blocking attempts to do things like: http://somesite:25/ The last version of Win32 Lynx that I configured for mail, used a third party mail sending program, called sendmail (although unrelated to the one from sendmail.org). The command line parameters for that were specified in lynx.cfg and there were comments explaining how to do it. As I don't know which version you are using, I don't know exactly how mail is handled on yours. The SMTP Host value should be supplied by your service provider. Unfortunately the mailing list strips the headers needed to deduce this remotely, although even then the official one may differ from the apparent one. If you can get someone to send back the **full** headers from something you have sent, the last Received line will probably have the correct value in the by clause, and the next to last one may have it in the from clause. If these don't match something approriate sounding in your current mail client, you need to talk to your ISP's support desk. PS Congratulations on using an informative subject. From owner-lynx-dev@sig.net Sun Nov 29 07:29:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA28484 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 07:29:39 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12147; Sun, 29 Nov 1998 06:14:39 -0600 (CST) Date: Sun, 29 Nov 1998 06:14:40 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: Lynx Developers <lynx-dev@sig.net> Subject: Re: lynx-dev Passing internal data to external handlers In-Reply-To: <19981127125119.52940@shell3.ba.best.com> Message-ID: <Pine.SUN.3.95.981129060937.5167A-100000@xochi.tezcat.com> 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: 1782 Lines: 42 On Fri, 27 Nov 1998, Kim DeVaughn wrote: > Something that I like to do when I save documents, is to prepend a sort of > "header block" to them, telling from where and when they were obtained. For > example: > > >Linkname: Bzip2 Howto > >From: http://www.best.com/~dfetter/Bzip2-HOWTO/Bzip2-HOWTO.html > >Date: Fri Nov 27 12:05:49 PST 1998 > >Last Mod: Tue, 18 Aug 1998 15:56:32 GMT > > > ><document> > > I've been doing that "by hand" by first p(rinting) a copy of the Information > (=) page, then appending the document proper to it (via my own PRINTER: > definition, and handler script), then later going back and manually editing > out all the extraneous Information page stuff. > > All of which is a PITA. > > What I'd like to be able to do, is pass various bits of internal information > (title, url, etc) along to the PRINTER: handler in some way, and then let > the script do with it as it wishes. > > The method that comes to mind, is along the lines of what "trn" does for > similar purposes. That is, the user can specify all manner of internal > information to be passed along to an external script, using a wide variety > of %tokens, as formal args in the handler-invoking definition (eg, PRINTER: > def, or whatever). > > Has something like this been considered before? Or is there some alternate > way of accomplishing what I want to do, that I've overlooked? > > Would anyone besides myself find something like this to be a useful feature? For the Title this is already being done: it should be passed in the environment variable LYNX_PRINT_TITLE to your script. You might just expand that to set other variables for other things of interest. That would certainly be simpler than defining a language with %tokens etc. for this purpose. Klaus From owner-lynx-dev@sig.net Sun Nov 29 07:32:38 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id HAA29532 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 07:32:37 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA12433; Sun, 29 Nov 1998 06:19:04 -0600 (CST) Date: Sun, 29 Nov 1998 06:19:04 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Possible bug with link numbering In-Reply-To: <Pine.SUN.3.96.981128160754.24532A-100000@waltz> Message-ID: <Pine.SUN.3.95.981129061555.5167B-100000@xochi.tezcat.com> 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: 969 Lines: 19 On Sat, 28 Nov 1998, Doug Kaufman wrote: > While attempting to investigate a recent complaint on the list about > hotmail, I noticed an anomaly in regard to link numbering, in that > links that were numbered on the screen (with links and form fields > numbered) could not be reached with arrow keys, and could not be > reached with the number + "g" command. I am attaching the print to > file of the main screen at "http://www.hotmail.com". Links number > 1 and 5 to "spacer.gif" were not included in the numbering for the > "g" command. The commmand "20g" puts the cursor on link 22 on the > screen. It appears that screen links 1 and 5 aren't counted when the > "g" command is counting, but are when the screen is numbered. I tried > looking at the source to the html, but didn't see the problem. Do you have partial display enabled? If yes, try it without. If that is the problem, please try my patches for HText_trimHightext (as amended by Leonid). Klaus From owner-lynx-dev@sig.net Sun Nov 29 10:24:09 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA08269 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 10:24:07 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id JAA25626; Sun, 29 Nov 1998 09:10:47 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811291510.IAA12991@sanitas> Subject: Re: lynx-dev Passing internal data to external handlers To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 08:10:15 -0700 (MST) In-Reply-To: <Pine.SUN.3.95.981129060937.5167A-100000@xochi.tezcat.com> from "Klaus Weide" at Nov 29, 98 06:14:40 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: 1531 Lines: 35 In a recent note, Klaus Weide said: > Date: Sun, 29 Nov 1998 06:14:40 -0600 (CST) > > On Fri, 27 Nov 1998, Kim DeVaughn wrote: > > Something that I like to do when I save documents, is to prepend a sort of > > "header block" to them, telling from where and when they were obtained. For > > For the Title this is already being done: it should be passed in the > environment variable LYNX_PRINT_TITLE to your script. You might just > expand that to set other variables for other things of interest. That > would certainly be simpler than defining a language with %tokens etc. for > this purpose. > I've pondered doing something similar. In particular, I'd like Lynx to invoke helper apps defined in .mailcap with the same environment variables provided by metamail. A brief exploration of the code led me to believe that: o The headers are traversed by a state machine which ignores what it isn't interested in; there's no simple way to capture the complete header text, which is one of the variables metamail places in the environment. o The alternative of piping the document to metamail itself isn't easily achieved; again, Lynx discards the headers which metamail expects, and passes only the body to the application. o Likewise "Lynx -source <URL> | metamail" discards the headers, and I see no easy way to preserve them. o I haven't investigated EXTERNALS. Is this a prospect for coupling Lynx to metamail for all unsupported document types? Again, the headers would need to be preserved. -- gil From owner-lynx-dev@sig.net Sun Nov 29 11:35:47 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12466 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:35:45 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA01927; Sun, 29 Nov 1998 10:19:36 -0600 (CST) From: "Elwin Oost" <elwin@decent.demon.nl> To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 16:39:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: lynx-dev Post-query bug (2nd try) X-mailer: Pegasus Mail for Win32 (v3.01c) Message-Id: <E0zk90L-0002LK-00@post.mail.nl.demon.net> Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 670 Lines: 20 Hi, I think I found a bug in the Cookies section when one dumps the output immediately with a post query. I want to fetch a post_data page from a site which redirects with a 302 (indeed, Microsoft) and keeps track of the user with a cookie. This didn't work, I checked all the switches and then dug into the Lynx code to see whether I had missed one, and then (probably) found the bug: LYCookie's store_cookie calls HTAlert's HTConfirmCookie for permission to store it. However, one of HTConfirmCookie's requirements is that the domain entry de isn't empty. However, with dump_output_immediately it stays NULL. Hope this helps, please let me know, Elwin From owner-lynx-dev@sig.net Sun Nov 29 11:36:17 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12475 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:36:14 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02080; Sun, 29 Nov 1998 10:20:47 -0600 (CST) Message-ID: <19981129021009.5325.qmail@hotmail.com> X-Originating-IP: [208.241.51.17] From: "A K S" <aaks@hotmail.com> To: lynx-dev@sig.net Subject: lynx-dev helper apps in Win95 MIME-Version: 1.0 Content-Type: text/plain Date: Sat, 28 Nov 1998 18:10:09 PST Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 629 Lines: 13 I'm using Lynx 2.8.1 in Windows95, and I'd like to be able to have the option of either downloading or running certain filetypes (e.g. wav, jpeg, gif). I'm not sure how to call the apps from lynx.cfg. Here's an example I tried, but didn't work: VIEWER:image/jpeg:c\:/windows/programf/acdsee32 "%s":NON_XWINDOWS The backslash looks ugly, but lynx.cfg says I need it there. Also, I have quotes around %s because Acdsee32 requires quotes if the filename has a space in it. Can anybody help me with this? Thanks, Atram ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-lynx-dev@sig.net Sun Nov 29 11:36:33 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12472 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:36:09 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA01946; Sun, 29 Nov 1998 10:19:43 -0600 (CST) Message-Id: <m0zk7Hg-0000hmC@queen.torfree.net> Date: Sun, 29 Nov 1998 08:53:08 -0500 (EST) From: aa263@torfree.net (Suleman Currim) To: lynx-dev@sig.net X-URL: http://www.crl.com/~subir/lynx/lynx_help/Lynx_users_guide.html#13 X-Mailer: Lynx, Version 2.7.1f Subject: lynx-dev Show Cursor Feature Cc: aa263@freenet.toronto.on.ca Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 329 Lines: 6 I am a blind user, using DOS only (no Windows). I have heard that the "show cursor" feature helps a blind person use Lynx more efficiently. Please explain in what way "show cursor" does so, and how I could activate it. I think my Lynx version is either2.72 or 2.8. Thank you. Suleman Currim, aa263@freenet.toronto.on.ca From owner-lynx-dev@sig.net Sun Nov 29 11:36:49 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12488 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:36:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA01997; Sun, 29 Nov 1998 10:20:02 -0600 (CST) From: Ilya Zakharevich <ilya@math.ohio-state.edu> Message-Id: <199811290853.DAA21961@monk.mps.ohio-state.edu> Subject: Re: lynx-dev Key remapping problem To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 03:53:59 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 1152 Lines: 35 I wrote: > I'm somehow lost wrt key remapping in lynx. Looking through the > source of LYKeymap.c, I get an impression that keymap[] goes up to > 0x293 or some such. > > However, a pair > > setkey "^[^[" 0x81 > KEYMAP:0x81:LEFT_LINK > > works, but > > setkey "^[^[" 0x210 > KEYMAP:0x210:LEFT_LINK > > does not. Doug Kaufman wrote something which I think has no relationship to the question (he described some PDCurses and PC stuff - I'm on PC, but my main question was portable). Let me repeat the question: I want to map some keysequence, say, ^[^[ to some "action", say LEFT_LINK. The current scheme is to do it in two steps (Why?!): I need to remap the keysequence to a symbolic name/index, and then I need to remap this name/index to the action. My question was about a choice of the intermediate input-name/index: to not step on any possible "standard" keyboard input, I need this input-name/index to be above the maximal standard input-name/index, but Lynx would not allow this (as with the example 0x210 above, 0x81 may conflict with, say, cyrillic 'b' in some codepages). Thus we need a user area available for remapping. Ilya From owner-lynx-dev@sig.net Sun Nov 29 11:38:36 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12496 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:38:34 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02060; Sun, 29 Nov 1998 10:20:40 -0600 (CST) From: aldomel@ix.netcom.com Date: Sat, 28 Nov 1998 22:45:17 -0500 Message-Id: <199811290345.WAA07619@me.x> To: lynx-dev@sig.net Subject: lynx-dev backspace off a text entry (was Re: New editing key bindings) References: <19981120105556.54231@shell3.ba.best.com> <9811191809.AA11070@cas.org> <Pine.GSO.4.05.9811200720170.353-100000@Stratus.CAM.ORG> <ABwK_NsK37@pauzner.mccme.ru> In-Reply-To: <ABwK_NsK37@pauzner.mccme.ru> by "Leonid Pauzner", uue@pauzner.mccme.ru, Sat, 28 Nov 1998 16:06:02 +0300 (MSK) X-Mailer: Emacs 20.2 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1607 Lines: 48 >besides adding a new editing keys (which are not so easy to remember anyway), >we have a following problem - while moving to beginning of line >with "left arrow" or "backspace" we can easily went out of box >and force go to previous document not intentionally... > >Is it possible to add a check so if we press several "left arrow" >on input line we got a prompt (go to previous document? y/n [n]) >before leaving that field by this key. Something like this. I hate accidently leaving a page, too. If you want to make it always ask you, use this patch here: It is a little quirky because you might be at the first page and it wil ask if you want to go back anyway. And, for the situation described by the comment, you must use C-v. * src/LYForms.c (form_getstr): always prompt left arrow at left of field --- lynx2-8-1.old/src/LYForms.c Sat Nov 28 19:57:30 1998 +++ lynx2-8-1.new/src/LYForms.c Sat Nov 28 22:02:00 1998 @@ -391,17 +391,16 @@ /* * Left arrrow in column 0 deserves special treatment here, * else you can get trapped in a form without submit button! */ case LTARROW: if (MyEdit.pos == 0) { - int c = 'Y'; /* Go back immediately if no changes */ - if (strcmp(MyEdit.buffer, value)) { - _statusline(PREV_DOC_QUERY); - c = LYgetch(); - } + int c; + _statusline(PREV_DOC_QUERY); + c = LYgetch(); + if (TOUPPER(c) == 'Y') { return(ch); } else { if (form->disabled == YES) _statusline(ARROWS_OR_TAB_TO_MOVE); else ------------- visit http://pw1.netcom.com/~aldomel/lynx.html From owner-lynx-dev@sig.net Sun Nov 29 11:39:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12511 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:39:21 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA02018; Sun, 29 Nov 1998 10:20:10 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811290707.CAA28719@chass.utoronto.ca> Subject: Re: lynx-dev Possible bug with link numbering To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 02:07:59 -0500 (EST) In-Reply-To: <Pine.SUN.3.96.981128223211.14460A-100000@waltz> from "Doug Kaufman" at Nov 28, 98 10:36: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: 786 Lines: 15 981129 Doug Kaufman wrote: > You are correct that VERBOSE_IMAGES is not the critical switch. > It is image_links that matters here. To see the behavior I described, > set MAKE_LINKS_FOR_ALL_IMAGES to TRUE in lynx.cfg, > run lynx as "lynx -image_links" > or hit the "*" key from within lynx to turn on image_links. i haven't tried the former two, but with * i get your screen, but 1g 5g work as usual & i can goto those links ("Download/Cancel?"). it begins to look like a problem introduced since 2-8-1rel.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 Nov 29 11:43:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id LAA12818 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 11:43:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA01969; Sun, 29 Nov 1998 10:19:52 -0600 (CST) From: Ilya Zakharevich <ilya@math.ohio-state.edu> Message-Id: <199811290901.EAA24965@monk.mps.ohio-state.edu> Subject: ]Re: lynx-dev Keymap printing patch To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 04:01:22 -0500 (EST) X-Mailer: ELM [version 2.5 PL0b1] 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: 986 Lines: 25 Doug Kaufman wrote: ====== I am not sure that this code is really a good idea. I am stil trying to understand what you are trying to accomplish with this. See my reply to your other message in regard to a change in LYStrings.c that may do what you want. Perhaps you can try to explain again what it is that you think that lynx should be doing, but is not. ====== The supplied patch fixed (at least one) a bug in lynx: a lot of bindings were not printed, say, the binding for Remove key DOWN_TWO go forward two lines in the document It also allowed one to see *all* the currently present bindings. This is important for debugging purposes - both at the user preferences level, and lynx mainainance level. Ilya P.S. Btw, any reason to name the "Backspace" key as "Delete", and the "Delete" key as "Remove" in the bindings? P.P.S. I'm not subscribed, and the list archives is terribly misconfigured, which makes replying via archive a PITA. Please consider Ccing me. From owner-lynx-dev@sig.net Sun Nov 29 13:57:39 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id NAA21091 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 13:57:38 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA16430; Sun, 29 Nov 1998 12:38:34 -0600 (CST) Date: Sun, 29 Nov 1998 10:38:34 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: lynx-dev@sig.net Subject: Re: lynx-dev Possible bug with link numbering In-Reply-To: <Pine.SUN.3.95.981129061555.5167B-100000@xochi.tezcat.com> Message-Id: <Pine.SUN.3.96.981129103651.19607A-100000@waltz> 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: 475 Lines: 15 On Sun, 29 Nov 1998, Klaus Weide wrote: > Do you have partial display enabled? If yes, try it without. If that > is the problem, please try my patches for HText_trimHightext (as amended > by Leonid). Yes, turning off partial display fixes the problem with the numbering. I'll report back on the patch after I get a chance to recompile. Thanks. Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Nov 29 14:08:52 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA21710 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 14:08:51 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id MAA17919; Sun, 29 Nov 1998 12:52:08 -0600 (CST) Date: Sun, 29 Nov 1998 10:52:07 -0800 (PST) From: Doug Kaufman <dkaufman@rahul.net> X-Sender: dkaufman@waltz To: Ilya Zakharevich <ilya@math.ohio-state.edu> Cc: lynx-dev@sig.net Subject: Re: lynx-dev Key remapping problem In-Reply-To: <199811290853.DAA21961@monk.mps.ohio-state.edu> Message-Id: <Pine.SUN.3.96.981129105132.19607C-100000@waltz> 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: 743 Lines: 19 On Sun, 29 Nov 1998, Ilya Zakharevich wrote: > Doug Kaufman wrote something which I think has no relationship to the > question (he described some PDCurses and PC stuff - I'm on PC, but my > main question was portable). Perhaps it was buried in my message. The code that stops your remapping is in LYStrings.c, line number 1208 in the current code. DO_NOTHING was originally the limit of the number of elements in the keymap[] array. Recently the array was expanded to allow remapping of keys with higher values, but the limit for unix was not changed. Please try changing the code in LYStrings.c and see if this helps Doug __ Doug Kaufman Internet: dkaufman@rahul.net (preferred) bn900@cleveland.freenet.edu From owner-lynx-dev@sig.net Sun Nov 29 15:27:24 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA26534 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 15:27:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA26570; Sun, 29 Nov 1998 14:10:53 -0600 (CST) Message-ID: <19981129121045.A26903@psnw.com> Date: Sun, 29 Nov 1998 12:10:45 -0800 From: "brian j. pardy" <posterkid@psnw.com> To: lynx-dev@sig.net Subject: Re: lynx-dev Post-query bug (2nd try) Mail-Followup-To: lynx-dev@sig.net References: <E0zk90L-0002LK-00@post.mail.nl.demon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <E0zk90L-0002LK-00@post.mail.nl.demon.net>; from "Elwin Oost" on Sun, Nov 29, 1998 at 04:39:22PM X-Operating-System: Linux odin 2.0.36 X-Public-Keys: http://www.psnw.com/~posterkid/keys/ X-Uptime: 11:59am up 11 days, 19:33, 5 users, load average: 1.00, 1.00, 1.00 X-URL: http://www.psnw.com/~posterkid/ Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 1060 Lines: 27 On Sun, Nov 29, 1998, Elwin Oost wrote: > Hi, > > I think I found a bug in the Cookies section when one dumps the > output immediately with a post query. > > I want to fetch a post_data page from a site which redirects with a > 302 (indeed, Microsoft) and keeps track of the user with a cookie. > This didn't work, I checked all the switches and then dug into the > Lynx code to see whether I had missed one, and then (probably) > found the bug: > > LYCookie's store_cookie calls HTAlert's HTConfirmCookie for > permission to store it. However, one of HTConfirmCookie's > requirements is that the domain entry de isn't empty. However, with > dump_output_immediately it stays NULL. > > Hope this helps, please let me know, I took a look at this code, and I agree with your summary. I made a few simple attempts at fixing it that didn't work. I'm very unfamiliar with the dump_output_immediately code and why it does things differently. This looks to be around line 390 in LYCookie.c. -- Don't suspect your friends -- turn them in! -- "Brazil" From owner-lynx-dev@sig.net Sun Nov 29 17:20:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA01560 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 17:20:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA08640; Sun, 29 Nov 1998 15:57:51 -0600 (CST) From: Al Gilman <asgilman@access.digex.net> Message-Id: <199811292157.QAA04138@access1.digex.net> Subject: lynx-dev how to turn on "show cursor" To: aa263@freenet.toronto.on.ca Date: Sun, 29 Nov 1998 16:57:27 -0500 (EST) Cc: lynx-dev@sig.net X-Mailer: ELM [version 2.4ME+ PL15 (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: 1020 Lines: 32 Date: Sun, 29 Nov 1998 08:53:08 -0500 (EST) From: aa263@torfree.net (Suleman Currim) To: lynx-dev@sig.net X-URL: http://www.crl.com/~subir/lynx/lynx_help/Lynx_users_guide.html#13 X-Mailer: Lynx, Version 2.7.1f Subject: Show Cursor Feature Cc: aa263@freenet.toronto.on.ca I am a blind user, using DOS only (no Windows). I have heard that the "show cursor" feature helps a blind person use Lynx more efficiently. Please explain in what way "show cursor" does so, and how I could activate it. I think my Lynx version is either2.72 or 2.8. Thank you. Suleman Currim, aa263@freenet.toronto.on.ca OK, your Lynx version is 2.7.1f which is just before 2.7.2. The email headers from your message told me that. There is an extensive discussion of "show cursor" at the BLYNX site. This is at http://leb.net/blinux/blynx/ and in particular you should read the discussion of "show cursor" in http://leb.net/pub/blinux/lynx/lynx.cfg After you try this, if you are not sure you have it right, please write back. Al From owner-lynx-dev@sig.net Sun Nov 29 17:51:07 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA03423 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 17:51:06 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA12415; Sun, 29 Nov 1998 16:30:02 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811292228.RAA09089@chass.utoronto.ca> Subject: Re: lynx-dev Possible bug with link numbering To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 17:28:31 -0500 (EST) In-Reply-To: <Pine.SUN.3.96.981129103651.19607A-100000@waltz> from "Doug Kaufman" at Nov 29, 98 10:38:34 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: 505 Lines: 10 981129 Doug Kaufman wrote: > Yes, turning off partial display fixes the problem with the numbering. > I'll report back on the patch after I get a chance to recompile. note that i use partial display in 2-8-1rel.1 without your problem. -- ========================,,============================================ 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 Nov 29 20:12:16 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA12806 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 20:12:16 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id SAA29946; Sun, 29 Nov 1998 18:50:21 -0600 (CST) Date: Mon, 30 Nov 1998 09:49:47 +0900 (JST) From: Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp> Message-Id: <199811300049.JAA11495@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (I) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 3124 Lines: 65 Before I start on anything, I just want you to know, Jim, that I appreciate and respect your efforts tremendously. I'm also grateful to Tom for working so hard to polish things up. This whole idea of gettext and NLS is big! > I agree half-heartedly. When that rare message appears, how would a > non-English speaker deal with it? I was thinking about words(?) like "WAIS", "gopher", etc., but there may be other cases. A non-English speaker probably would have no trouble, but I will of course run all of my proposals across the list first. Anyway, Tom and you will have the last say. > Definitely, except let's not make translator's work obsolete by > changing dozens of lines for the heck of it. Do I know about that (I've already hand edited ja.po about three times :)! I test all of the changes I make in both English and Japanese, and try to find a best-for-both solution. I'm not the type of person who does things "for the heck of it." > > same way so that we can have one "msgid"? Also, when the > > string is found in more than one file, let's make it a define > > in LYMessages. > > Yes, and no. The tools will automagically merge messages from > different modules. I disagree with having #defines except as bug > workarounds. I agree in principle, but Tom has indicated that he would like to get Solaris's gettext to work with Lynx. Not being a programmer I can't say either way, but for now I really think it would behoove Sun to do some work to make their implementation more robust. Anyway since Tom said he only needs to cut off a few hundred bytes from the command line (what is that for, xgettext?), so I thought I would at least give it a try. > Leaving the messages in place may help translators decide the best > idioms based on context. Seeing the same message in many places would Only some translators will be able to do this. > tell me that the *code* could be combined into subroutines (this > should please you Henry if we shave some more bytes off the source and > executables :-). I noticed in my work the same code had been Oh, yes! Do I feel good when one more line goes into the trash :-) I'm the programmer's worst enemy perhaps. > Since these are outside the code/gettext context, perhaps they could > by worked independently on by volunteers? I will be happy I didn't discuss this yet, being a bit swamped at work. I VERY much hope that the help files will be kept completely separate from the statusline prompts and messages in Lynx. I am particularly unhappy with how some of the .cfg stuff has crept into the code. I will be looking at a lot of those multi-paragraph messages that have been gettexted, and will try to find a way to have them serviced from the help or doc file sets. I'm NOT saying I favor them being thrown away; I'm saying I would prefer that they be in a text/html file rather than hardcoded in the source. Having huge blocks for translation really bogs one down, especially when it's a spare-time-only job. Some of the internally created pages CAN be made less formidable from the translator's point of view. __Henry From owner-lynx-dev@sig.net Sun Nov 29 20:38:40 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id UAA14275 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 20:38:35 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id TAA04620; Sun, 29 Nov 1998 19:23:27 -0600 (CST) Date: Mon, 30 Nov 1998 10:22:39 +0900 (JST) From: Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp> Message-Id: <199811300122.KAA11604@ews07.nara.kindai.ac.jp> To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (II) Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 2682 Lines: 65 > I find your modifications too verbose. I think the present format is > clear enough. Even in the first time I used Lynx I had no problems > understanding The present format of the P)rint option page has the exact same message "Print options" displayed _three_ times. If my modifications are too verbose, then I would propose that that particular string be removed completely just above the listing in advanced user mode, as is the "Local additions" message below. > what the options in that menu meant. I would hate to see something > like `"Print" actions to be taken on the rendered document when you > press Return Perhaps you, yes. We still do get questions about the difference between "print" and "download" on the list. I know many of my students don't realize a difference between the two. I thought rather than parrot "options" another time, I'd give at least a hint of what was going to happen if they hit the enter key on one of the options. > structures. For instance, in your patch, `Locally configured "Print" > actions to be taken on the rendered document:' and `"Print" actions to > be taken on the rendered document:' should be separate strings. This > is valid for all Very true, and easy to do. > > I thought the first call to aid the Novice user was frivolous. The > > second one should make clear what the first one is all about. > > As I said above, I find the `Locally configured "Print" actions to > take on the rendered document:" too verbose. If you want to make > "Local additions:" clearer, it would be better to use something like > "Locally configured options:", but I find "Local additions:" clear > enough. Actually, I never much cared for the whole idea of these two strings "Print options" and "Local additions", even in Novice mode. If there is agreement here, I'll make another proposal and provide the patch to show these two only in Novice mode, which means in Intermediate and Advanced, you'll just get a list. Okay? > > Making it "page(s)" saves one msgid and also makes it easier to > > translate [...] > I don't find it acceptable, even in English. The present format, > "page" for Okay! These are the kinds of comments I was hoping for. > to the end, to make the plural. For example, in Latin the plural of That would be neat. A Latinized Lynx! > I find the "(approximately)" necessary, and the way it's now seems > to be the best compromise for clarity and compatibility with other Thanks for this input, too. Looks like it's back to the drawing board! But please comment on leaving/removing/revising (in the last case, please make proposals) the "Print options" right above the list of options itself. __Henry From owner-lynx-dev@sig.net Sun Nov 29 23:34:42 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA26441 for <lynx-dev-archive@flora.org>; Sun, 29 Nov 1998 23:34:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id WAA28610; Sun, 29 Nov 1998 22:15:14 -0600 (CST) Date: Sun, 29 Nov 1998 22:15:15 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: lynx-dev@sig.net Subject: lynx-dev Lynx and metamail (was: Passing internal data to external handlers) In-Reply-To: <199811291510.IAA12991@sanitas> Message-ID: <Pine.SUN.3.95.981129100354.16263A-100000@xochi.tezcat.com> 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: 2064 Lines: 49 On Sun, 29 Nov 1998 pg@sweng.stortek.com wrote: > I've pondered doing something similar. In particular, I'd like Lynx to > invoke helper apps defined in .mailcap with the same environment variables > provided by metamail. A brief exploration of the code led me to believe > that: > > o The headers are traversed by a state machine which ignores what it > isn't interested in; there's no simple way to capture the complete > header text, which is one of the variables metamail places in the > environment. You could modify HTMIME_put_character to save the incoming bytes, while not in me->state == MIME_TRANSPARENT mode, into a HTChunk or similar (in addition to parsing them, of course). But you would probably want to make at least line-ends canonical, maybe handle continuation lines. Also, metamail expects mail headers, not HTTP headers, so this doesn't seem very useful in general. (It's going to miss MIME-Version, for one thing.) > o The alternative of piping the document to metamail itself isn't > easily achieved; again, Lynx discards the headers which metamail > expects, and passes only the body to the application. This may give you some ideas: put www/mime; less %s in your mailcap file and see what happens. > o Likewise "Lynx -source <URL> | metamail" discards the headers, and I > see no easy way to preserve them. Try lynx -mime_header. > o I haven't investigated EXTERNALS. Is this a prospect for coupling > Lynx to metamail for all unsupported document types? Again, the headers > would need to be preserved. You could invoke a separate lynx process from EXTERNAL. Rather than having full metamail behavior, I would be more interested in having lynx parse the mailcap files as described in the metamail man page (and probably the relevant RFC), with correct substitutions for %s, %t, and %{...}. They should also be substituted in the test string. That would mean that Lynx may have to run the tests many times, instead of just once at startup. (The newer libwww treats Presenters that way.) Klaus From owner-lynx-dev@sig.net Mon Nov 30 00:32:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id AAA30068 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 00:32:13 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id XAA07970; Sun, 29 Nov 1998 23:17:37 -0600 (CST) From: pg@sweng.stortek.com Message-id: <199811300517.WAA19458@sanitas> Subject: Re: lynx-dev Lynx and metamail (was: Passing internal data to external handlers) To: lynx-dev@sig.net Date: Sun, 29 Nov 1998 22:17:07 -0700 (MST) In-Reply-To: <Pine.SUN.3.95.981129100354.16263A-100000@xochi.tezcat.com> from "Klaus Weide" at Nov 29, 98 10:15:15 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: 922 Lines: 21 In a recent note, Klaus Weide said: > Date: Sun, 29 Nov 1998 22:15:15 -0600 (CST) > [ ... ] > Thanks for the several pointers. > Rather than having full metamail behavior, I would be more interested in > having lynx parse the mailcap files as described in the metamail man page > (and probably the relevant RFC), with correct substitutions for %s, %t, > and %{...}. They should also be substituted in the test string. That > would mean that Lynx may have to run the tests many times, instead of > just once at startup. (The newer libwww treats Presenters that way.) > I'm a modularity partisan; Lynx shouldn't attempt that which metamail already does. And there are subtleties which may not even be resolved by the documentation. For example, I've noticed that the behavior of Lynx differs from metamail when multiple tests succeed -- one takes the earlier rule; the other the later (I forget which). -- gil From owner-lynx-dev@sig.net Mon Nov 30 03:56:50 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA09189 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 03:56:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA23248; Mon, 30 Nov 1998 02:33:07 -0600 (CST) From: "Deepak Kumar" <deepak@vecmail.inet.vec.ac.in> To: <lynx-dev@sig.net> Subject: lynx-dev Enquiry! Date: Mon, 30 Nov 1998 10:42:37 +0530 Message-ID: <01be1c20$0bc2a770$0b12a8c0@ga-01.INET> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 43 Lines: 1 Where I can find a lynx browser for MSDOS. From owner-lynx-dev@sig.net Mon Nov 30 03:59:48 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id DAA09415 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 03:59:47 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id CAA24143; Mon, 30 Nov 1998 02:45:37 -0600 (CST) X-Authentication-Warning: sv4.ictp.trieste.it: onime owned process doing -bs Date: Mon, 30 Nov 1998 09:35:51 +0100 (MET) From: ONIME EHIMIKA OHIREIME <onime@ictp.trieste.it> X-Sender: onime@sv4 To: lynx-dev@sig.net Subject: lynx-dev Re: LYNX 2.8.1 and cookies Message-ID: <Pine.GSO.3.96.981130092130.23619B-100000@sv4> 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: 790 Lines: 23 Dear, Thanks for the good work on Lynx, please keep it up. I am very interested in the lynx support for cookies. I currently need to run lynx in a command line/batch mode. I would like to know if there is a policy against using the cookie file (reading and writting) when in the dump output mode. I have successfully patch LYCookie.c to allow lynx to create and save the cookie file when using the dump mode. My patch disables some code that was kicked in based on the dump_output_immediately variable and also to add the following line to the beginning of function LYCookieJar_free. if (dump_output_immediately) LYStoreCookies (LYCookieFile); I could send the pacthed file across. Please can you in the next release allow the use of cookies from the dump mode. Thanks Clement. From owner-lynx-dev@sig.net Mon Nov 30 04:23:05 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id EAA10814 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 04:23:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id DAA25585; Mon, 30 Nov 1998 03:07:49 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811300906.EAA12120@chass.utoronto.ca> Subject: Re: lynx-dev Enquiry! To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 04:06:20 -0500 (EST) Cc: deepak@vecmail.inet.vec.ac.in In-Reply-To: <01be1c20$0bc2a770$0b12a8c0@ga-01.INET> from "Deepak Kumar" at Nov 30, 98 10:42: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: 436 Lines: 11 981130 Deepak Kumar wrote: > Where I can find a lynx browser for MSDOS? www.rahul.net/dkaufman/ www.fdisk.com/doslynx/doslynx.htm www.fdisk.com/doslynx/bobcat.htm -- ========================,,============================================ 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 Nov 30 05:33:51 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id FAA14714 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 05:33:49 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id EAA29795; Mon, 30 Nov 1998 04:16:14 -0600 (CST) From: dickey@clark.net Message-Id: <199811301016.FAA12140@shell.clark.net> Subject: Re: lynx-dev Lynx and metamail (was: Passing internal data to external handlers) To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 05:16:15 -0500 (EST) In-Reply-To: <Pine.SUN.3.95.981129100354.16263A-100000@xochi.tezcat.com> from "Klaus Weide <kweide@tezcat.com>" at Nov 29, 98 10:15:15 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: 914 Lines: 24 > Rather than having full metamail behavior, I would be more interested in > having lynx parse the mailcap files as described in the metamail man page > (and probably the relevant RFC), with correct substitutions for %s, %t, > and %{...}. They should also be substituted in the test string. That > would mean that Lynx may have to run the tests many times, instead of > just once at startup. (The newer libwww treats Presenters that way.) a better solution would be to cache some of the information - one of the longstanding Debian bug reports is that Lynx runs a lot of tests unnecessarily at initialization time solely to determine if the tests might succeed at some later time. also, the substitutions are incomplete (the "%{" ones for example, are not implemented). sounds like a good project for someone... > > Klaus -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 30 06:58:14 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id GAA19304 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 06:58:12 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id FAA04977; Mon, 30 Nov 1998 05:43:20 -0600 (CST) Message-ID: <19981130034254.04221@shell3.ba.best.com> Date: Mon, 30 Nov 1998 03:42:54 -0800 From: Kim DeVaughn <kimdv@best.com> To: Lynx Developers <lynx-dev@sig.net> Subject: lynx-dev Re: Passing internal data to external handlers Mail-Followup-To: Lynx Developers <lynx-dev@sig.net> References: <19981127125119.52940@shell3.ba.best.com> <Pine.SUN.3.95.981129060937.5167A-100000@xochi.tezcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <Pine.SUN.3.95.981129060937.5167A-100000@xochi.tezcat.com>; from Klaus Weide on Sun, Nov 29, 1998 at 06:14:40AM -0600 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: 1823 Lines: 38 On Sun, Nov 29, 1998, Klaus Weide (kweide@tezcat.com) said: | | On Fri, 27 Nov 1998, Kim DeVaughn wrote: | | > Something that I like to do when I save documents, is to prepend a sort of | > "header block" to them, telling from where and when they were obtained. | > The method that comes to mind, is along the lines of what "trn" does for | > similar purposes. That is, the user can specify all manner of internal | > information to be passed along to an external script, using a wide variety | > of %tokens, as formal args in the handler-invoking definition (eg, PRINTER: | > def, or whatever). | | For the Title this is already being done: it should be passed in the | environment variable LYNX_PRINT_TITLE to your script. You might just | expand that to set other variables for other things of interest. That | would certainly be simpler than defining a language with %tokens etc. for | this purpose. Ah. Another useful, if undocumented, feature (yes, I see it buried in one of the old CHANGES.x files, now that I know what to look for). It really would be nice to have *all* the env vars mentioned somewhere ... perhaps in the man page ... :-) ... Anyway, I had considered using env vars to pass along some of the internal data, but thought that using such a method might suffer from portability problems. I see there is seperate code in LYPrint.c to handle VMS, but what about other platforms? In any case, I'll add vars for those things that I need to pass along, since as you say, the implementation is fairly trivial, compared to a token-passing scheme. Then if there are portability issues, and enough interest from other folks, I'll revisit token-passing somewhere down the line. I'll also see about adding such env vars, and maybe others, to the man page. Thanks muchly for the suggestion ...! /kim From owner-lynx-dev@sig.net Mon Nov 30 08:04:23 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA23272 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 08:04:22 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id GAA09711; Mon, 30 Nov 1998 06:45:03 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Mon, 30 Nov 1998 07:45:13 -0500 (EST) From: Ismael Cordeiro <ismael@cordeiro.com> X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: lynx-dev TagSoup x SortaSGML Message-ID: <Pine.GSO.4.05.9811292036440.5397-100000@Stratus.CAM.ORG> 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: 495 Lines: 12 I've just found out that setting TAGSOUP to TRUE in lynx.cfg doesn't do anything. To select TagSoup one has to press ^V. 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 Nov 30 09:54:03 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA30909 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 09:54:02 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA27795; Mon, 30 Nov 1998 08:35:10 -0600 (CST) Date: Mon, 30 Nov 1998 14:38:47 -0800 (PST) From: Vitor Manuel dos Santos Oliveira <vimasol@esoterica.pt> To: Suleman Currim <aa263@torfree.net> cc: lynx-dev@sig.net, aa263@freenet.toronto.on.ca Subject: Re: lynx-dev Show Cursor Feature In-Reply-To: <m0zk7Hg-0000hmC@queen.torfree.net> Message-ID: <Pine.PCP.3.96.981130143345.7103A-100000@[195.22.1.206]> X-X-Sender: vimasol@mail.esoterica.pt 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: 732 Lines: 26 Hi: I'm a blind user to and I use dos version with a ppp driver. Now, the current version is 2.8.2dev6 in "ftp://ftp.rahul.net/dkaufman/". The show cursor alows you to have the static cursor of your speach syntithizer in the correct place. Regards. Vitor Manuel dos Santos Oliveira phon=3511-4743718 Lisbon Portugal vimasol@esoterica.pt On Sun, 29 Nov 1998, Suleman Currim wrote: > I am a blind user, using DOS only (no Windows). > I have heard that the "show cursor" feature helps a blind person > use Lynx more efficiently. Please explain in what way "show cursor" does so, > and how I could activate it. I think my Lynx version is > either2.72 or 2.8. Thank you. > Suleman Currim, aa263@freenet.toronto.on.ca > From owner-lynx-dev@sig.net Mon Nov 30 10:15:58 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id KAA32458 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 10:15:57 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id IAA02706; Mon, 30 Nov 1998 08:53:10 -0600 (CST) Date: Mon, 30 Nov 1998 14:56:59 -0800 (PST) From: Vitor Manuel dos Santos Oliveira <vimasol@esoterica.pt> To: lynx-dev@sig.net Subject: Re: lynx-dev Enquiry! In-Reply-To: <01be1c20$0bc2a770$0b12a8c0@ga-01.INET> Message-ID: <Pine.PCP.3.96.981130145629.-3307A-100000@[195.22.11.78]> X-X-Sender: vimasol@mail.esoterica.pt 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: 213 Lines: 13 "ftp://ftp.rahul.net/dkaufman" Vitor Manuel dos Santos Oliveira phon=3511-4743718 Lisbon Portugal vimasol@esoterica.pt On Mon, 30 Nov 1998, Deepak Kumar wrote: > Where I can find a lynx browser for MSDOS. > From owner-lynx-dev@sig.net Mon Nov 30 12:11:46 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA08072 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 12:11:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id KAA11717; Mon, 30 Nov 1998 10:50:47 -0600 (CST) Date: Mon, 30 Nov 1998 14:08:33 +0000 (GMT) From: "Alan J. Flavell" <flavell@a5.ph.gla.ac.uk> To: Lynx developers list <lynx-dev@sig.net> Subject: lynx-dev entities and the sortaSGML parser Message-ID: <Pine.OSF.3.96.981130135656.26538C-100000@a5.ph.gla.ac.uk> X-antiSpam: Do not send me unsolicited commercial email 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: 31 A discussion on the usenet group c.i.w.browsers.misc showed that a broken document such as http://www.nybooks.com/nyrev/WWWfeatdisplay.cgi?1998120351R wasn't getting its entities interpreted (é etc.). (Using the tag-soup parser produces a result that's more in accordance with what the misguided document author presumably intended.) [N.B I'm not here concerned with the — rubbish that's in there too.] On a hunch, I tried a simple document such as http://ppewww.ph.gla.ac.uk/~flavell/tests/hunch.html and verified that an entity that appears within a TABLE but outside of any table row TR will be displayed by Lynx _without_ its entities being interpreted. I note that text that's outside of a table cell (e.g TD), but inside of a table row (a situation that's also illegal, of course) gets its entities interpreted. I didn't look too closely at the original document, apart from noting via HTML validation that it is very badly broken. While not for a moment wanting to misplace the blame here, the final results as seen by the reader do seem rather odd. I was wondering whether the developers could see some way around this, if only for cosmetic effect. best regards From owner-lynx-dev@sig.net Mon Nov 30 12:58:30 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA11033 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 12:58:29 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id LAA26519; Mon, 30 Nov 1998 11:35:28 -0600 (CST) From: dickey@clark.net Message-Id: <199811301735.MAA26959@shell.clark.net> Subject: Re: lynx-dev entities and the sortaSGML parser To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 12:35:11 -0500 (EST) In-Reply-To: <Pine.OSF.3.96.981130135656.26538C-100000@a5.ph.gla.ac.uk> from "Alan J. Flavell" <flavell@a5.ph.gla.ac.uk>" at Nov 30, 98 02:08:33 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: 1495 Lines: 38 > A discussion on the usenet group c.i.w.browsers.misc showed that > a broken document such as > http://www.nybooks.com/nyrev/WWWfeatdisplay.cgi?1998120351R > wasn't getting its entities interpreted (é etc.). I saw that, but it seems that you've looked closer than I have (thanks - it looks like a simple test case). Perhaps someone will have a fix. > (Using the tag-soup parser produces a result that's more in > accordance with what the misguided document author presumably > intended.) > > [N.B I'm not here concerned with the — rubbish that's in > there too.] > > On a hunch, I tried a simple document such as > http://ppewww.ph.gla.ac.uk/~flavell/tests/hunch.html > and verified that an entity that appears within a TABLE but outside > of any table row TR will be displayed by Lynx _without_ its > entities being interpreted. > > I note that text that's outside of a table cell (e.g TD), but inside > of a table row (a situation that's also illegal, of course) gets its > entities interpreted. > > I didn't look too closely at the original document, apart from > noting via HTML validation that it is very badly broken. While > not for a moment wanting to misplace the blame here, the final > results as seen by the reader do seem rather odd. I was wondering > whether the developers could see some way around this, if only for > cosmetic effect. > > best regards -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey From owner-lynx-dev@sig.net Mon Nov 30 15:43:06 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA22938 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 15:43:00 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id OAA19181; Mon, 30 Nov 1998 14:23:06 -0600 (CST) X-Authentication-Warning: Stratus.CAM.ORG: ismael owned process doing -bs Date: Mon, 30 Nov 1998 15:23:11 -0500 (EST) From: Ismael Cordeiro <ismael@cordeiro.com> X-Sender: ismael@Stratus.CAM.ORG To: lynx-dev@sig.net Subject: Re: lynx-dev proposed revisions for gettext (II) In-Reply-To: <199811300122.KAA11604@ews07.nara.kindai.ac.jp> Message-ID: <Pine.GSO.4.05.9811301457590.4354-100000@Stratus.CAM.ORG> 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: 2278 Lines: 49 On Mon, 30 Nov 1998, Nelson Henry Eric wrote: > The present format of the P)rint option page has the exact same message > "Print options" displayed _three_ times. If my modifications are too > verbose, then I would propose that that particular string be removed > completely just above the listing in advanced user mode, as is the "Local > additions" message below. I support your proposition and I suggest also removing the TITLE from the Print, Download and Options(forms) menus, and from the List, History and Visited Links pages. Those can't be bookmarked anyway. Well, the Options(forms) menu can be bookmarked but I think it's just something that was forgotten when it was created. By the way, when we quit the Options(forms) menu, the previous page is always reloaded even if nothing was chaged. That's annoying. > Perhaps you, yes. We still do get questions about the difference between > "print" and "download" on the list. I know many of my students don't > realize a difference between the two. I thought rather than parrot > "options" another time, I'd give at least a hint of what was going to > happen if they hit the enter key on one of the options. What about telling them to read the help files, which are one keystroke from them? The Download and Print options are explained there. > Actually, I never much cared for the whole idea of these two strings > "Print options" and "Local additions", even in Novice mode. If there is > agreement here, I'll make another proposal and provide the patch to show > these two only in Novice mode, which means in Intermediate and Advanced, > you'll just get a list. Okay? OK. > That would be neat. A Latinized Lynx! I was giving it just as an example of a language that doesn't necessarily use just an "s" for plural forms, but it's possible to have a Latin version of Lynx. Have you never seen comics in Latin? There are many in Europe. 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 Nov 30 16:45:43 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA27435 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 16:45:41 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA08702; Mon, 30 Nov 1998 15:24:32 -0600 (CST) Date: Mon, 30 Nov 1998 15:24:28 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: lynx-dev@sig.net Subject: Re: lynx-dev entities and the sortaSGML parser In-Reply-To: <199811301735.MAA26959@shell.clark.net> Message-ID: <Pine.SUN.3.95.981130151904.26133A-100000@xochi.tezcat.com> 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: 993 Lines: 24 On Mon, 30 Nov 1998 dickey@clark.net wrote: > > A discussion on the usenet group c.i.w.browsers.misc showed that > > a broken document such as > > http://www.nybooks.com/nyrev/WWWfeatdisplay.cgi?1998120351R > > wasn't getting its entities interpreted (é etc.). > > I saw that, but it seems that you've looked closer than I have (thanks - it > looks like a simple test case). Perhaps someone will have a fix. The following should do it. My fault. Klaus --- lynx2-8-1/WWW/Library/Implementation/SGML.c.~1~ Fri Sep 25 05:41:38 1998 +++ lynx2-8-1/WWW/Library/Implementation/SGML.c Mon Nov 30 15:14:06 1998 @@ -1380,6 +1380,7 @@ (!context->element_stack || (context->element_stack->tag && (context->element_stack->tag->contents == SGML_MIXED || + context->element_stack->tag->contents == SGML_ELEMENT || context->element_stack->tag->contents == SGML_PCDATA || context->element_stack->tag->contents == SGML_RCDATA)))) { /* From owner-lynx-dev@sig.net Mon Nov 30 16:57:37 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA28096 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 16:57:36 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id PAA12414; Mon, 30 Nov 1998 15:36:18 -0600 (CST) Message-ID: <19981130143519.C17095@fujin.intellistor.com> Date: Mon, 30 Nov 1998 14:35:19 -0700 From: Tom Hall <tlhall@royal.net> To: lynx-dev@sig.net Subject: lynx-dev <INPUT TYPE="file" ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Sender: owner-lynx-dev@sig.net Precedence: bulk Reply-To: lynx-dev@sig.net Status: RO Content-Length: 939 Lines: 21 The help page says: However, Lynx does not yet support INPUTs with TYPE="file" or TYPE="range" and will set the DISABLED attribute for all of the form's fields if any INPUTs with either of those two TYPEs are present, so that the form can't be submitted. For the case where you don't want to send a file, would it be possible (and easy) to have lynx send a nul file name, rather than have it set all the form's fields to DISABLED ? I want to submit a form for a web-based email service, which allows you to put an attachment on your email, and unfortunately puts the <INPUT TYPE="file" ... markup on the same page that you use to write email, so lynx displays: "[FILE Input] (Not yet implemented.)" Even if I don't want to submit an attachment, lynx is not able to submit the form, so I can't send email. Is there a "to do" list for lynx somewhere ? Does anyone know when TYPE="file" is planned to be supported in lynx ? From owner-lynx-dev@sig.net Mon Nov 30 18:00:08 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA32616 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 18:00:05 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA03665; Mon, 30 Nov 1998 16:42:46 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811302241.RAA26769@chass.utoronto.ca> Subject: Re: lynx-dev <INPUT TYPE="file" ... To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 17:41:16 -0500 (EST) In-Reply-To: <19981130143519.C17095@fujin.intellistor.com> from "Tom Hall" at Nov 30, 98 02:35:19 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: 1126 Lines: 25 981130 Tom Hall wrote: > The help page says: Lynx does not yet support INPUTs with TYPE="file" > or TYPE="range" and will set the DISABLED attribute for all the fields > if any INPUTs with either of those two TYPEs are present, > so that the form can't be submitted. -- snip -- > For the case where you don't want to send a file, > would it be possible to have Lynx send a nul file name, > rather than have it set all the form's fields to DISABLED ? this really does seem rather anti-social: surely it's a temporary hack long ago, which has been forgotten? > Is there a "to do" list for lynx somewhere ? www.slcc.edu/lynx/html/todo-list.html . > Does anyone know when TYPE="file" is planned to be supported in lynx ? as with everything, when someone gets around to offering a patch: would you like to have a go at it? can anyone else offer advice? -- ========================,,============================================ 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 Nov 30 18:04:00 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA32726 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 18:03:59 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA02731; Mon, 30 Nov 1998 16:39:34 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811302232.RAA24792@chass.utoronto.ca> Subject: lynx-dev envir't variables (was passing data) To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 17:31:55 -0500 (EST) In-Reply-To: <19981130034254.04221@shell3.ba.best.com> from "Kim DeVaughn" at Nov 30, 98 03:42: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: 1166 Lines: 21 981130 Kim DeVaughn wrote: > On Sun, Nov 29, 1998, Klaus Weide (kweide@tezcat.com) said: >> For the Title this is already being done: it should be passed >> in the environment variable LYNX_PRINT_TITLE to your script. >> You might just expand that to set other variables for things of interest. > Another useful, if undocumented, feature -- > I see it buried in one of the old CHANGES files -- > it really would be nice to have *all* the env vars mentioned somewhere > I'll also see about adding such env vars, and maybe others, to the man page. there is nothing in Users Guide on this environment variable or on Lynx environment variables in general: this is a very serious omission in Lynx documentation. besides the man page, what we really need is a section in Users Guide listing ALL Lynx environment variables with their uses. could you have a go at that? can somebody provide the list? -- ========================,,============================================ 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 Nov 30 18:05:45 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA00223 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 18:05:44 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id QAA02320; Mon, 30 Nov 1998 16:37:57 -0600 (CST) From: Philip Webb <purslow@chass.utoronto.ca> Message-Id: <199811302236.RAA25632@chass.utoronto.ca> Subject: lynx-dev Latin Lynx To: lynx-dev@sig.net Date: Mon, 30 Nov 1998 17:36:24 -0500 (EST) In-Reply-To: <Pine.GSO.4.05.9811301457590.4354-100000@Stratus.CAM.ORG> from "Ismael Cordeiro" at Nov 30, 98 03:23:11 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: 757 Lines: 15 981130 Ismael Cordeiro wrote: >> That would be neat. A Latinized Lynx! > I was giving it just as an example of a language > that doesn't necessarily use just an "s" for plural forms, > but it's possible to have a Latin version of Lynx. > Have you never seen comics in Latin? There are many in Europe. there has been a proposal to use Latin to solve the growing problem in the European Union of its many national languages: maybe Lynx could take a lead here: i could do it given time ... -- ========================,,============================================ 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 Nov 30 18:37:25 1998 Received: from roadrunner.sig.net (roadrunner.sig.net [192.195.85.203]) by lists.flora.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id SAA02375 for <lynx-dev-archive@flora.org>; Mon, 30 Nov 1998 18:37:23 -0500 Received: (from majordom@localhost) by roadrunner.sig.net (8.9.0/8.8.6) id RAA12158; Mon, 30 Nov 1998 17:10:25 -0600 (CST) Date: Mon, 30 Nov 1998 17:10:24 -0600 (CST) From: Klaus Weide <kweide@tezcat.com> To: lynx-dev@sig.net Subject: lynx-dev patch for traversal Message-ID: <Pine.SUN.3.95.981130170646.29062A-100000@xochi.tezcat.com> 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: 5585 Lines: 214 This patch reverts the file-opening call which didn't work back to previous behavior. This is based on 2.8.1rel.2; I have not checked whether the implementation of LYAppendToTxtFile etc. has changed in the devel code so that my changes changes would be unnecessary. However, I would actually prefer to have everything handled by just fopen, or a function that acts like it. There is IMO no good reason to apply paranoid permission checks for the traversal files, it only gets in the way of legitimate uses. For example the file permissions end up too restrictive, the normal umask should apply; and links rejected by permission checks are likely to be legitimate. I have also made some changes to avoid repetitive code and to get out of curses mode if an error occurs. (I hope the use of errno doesn't need to be ifdef'd for some systems.) Klaus *** lynx2-8-1.orig/src/LYTraversal.c Thu Aug 6 07:28:22 1998 --- lynx2-8-1/src/LYTraversal.c Mon Nov 30 16:55:16 1998 *************** *** 2,7 **** --- 2,9 ---- #include <LYGlobalDefs.h> #include <LYUtils.h> #include <LYSignal.h> + #include <LYClean.h> + #include <LYCurses.h> #include <LYTraversal.h> #include <LYexit.h> *************** *** 9,34 **** /* routines to handle special traversal feature */ ! PUBLIC BOOLEAN lookup ARGS1(char *,target) { ! FILE *ifp; ! char buffer[200], line[200]; ! if ((ifp = fopen(TRAVERSE_FILE,"r")) == NULL) { ! if ((ifp = LYNewTxtFile(TRAVERSE_FILE)) == NULL) { ! perror("unable to open or create a traversal file"); #ifndef NOSIGHUP ! (void) signal(SIGHUP, SIG_DFL); #endif /* NOSIGHUP */ ! (void) signal(SIGTERM, SIG_DFL); #ifndef VMS ! (void) signal(SIGINT, SIG_DFL); #endif /* !VMS */ #ifdef SIGTSTP ! if (no_suspend) ! (void) signal(SIGTSTP,SIG_DFL); #endif /* SIGTSTP */ ! exit(-1); } else { fclose(ifp); return(FALSE); --- 11,54 ---- /* routines to handle special traversal feature */ ! PRIVATE void final_perror ARGS2(CONST char *,msg, BOOLEAN, clean_flag) { ! int saved_errno = errno; ! if (LYCursesON) { ! if (clean_flag) ! cleanup(); ! else ! stop_curses(); ! } ! errno = saved_errno; ! perror(msg); ! } ! PRIVATE void exit_with_perror ARGS1(CONST char *,msg) ! { ! final_perror(msg, TRUE); #ifndef NOSIGHUP ! (void) signal(SIGHUP, SIG_DFL); #endif /* NOSIGHUP */ ! (void) signal(SIGTERM, SIG_DFL); #ifndef VMS ! (void) signal(SIGINT, SIG_DFL); #endif /* !VMS */ #ifdef SIGTSTP ! if (no_suspend) ! (void) signal(SIGTSTP,SIG_DFL); #endif /* SIGTSTP */ ! exit(-1); ! } ! ! PUBLIC BOOLEAN lookup ARGS1(char *,target) ! { ! FILE *ifp; ! char buffer[200], line[200]; ! ! if ((ifp = fopen(TRAVERSE_FILE,"r")) == NULL) { ! if ((ifp = LYNewTxtFile(TRAVERSE_FILE)) == NULL) { ! exit_with_perror("unable to open or create a traversal file"); } else { fclose(ifp); return(FALSE); *************** *** 54,72 **** FILE *ifp; if ((ifp = LYAppendToTxtFile(TRAVERSE_FILE)) == NULL) { ! perror("unable to open traversal file"); ! #ifndef NOSIGHUP ! (void) signal(SIGHUP, SIG_DFL); ! #endif /* NOSIGHUP */ ! (void) signal(SIGTERM, SIG_DFL); ! #ifndef VMS ! (void) signal(SIGINT, SIG_DFL); ! #endif /* !VMS */ ! #ifdef SIGTSTP ! if (no_suspend) ! (void) signal(SIGTSTP,SIG_DFL); ! #endif /* SIGTSTP */ ! exit(-1); } fprintf(ifp,"%s\n",target); --- 74,80 ---- FILE *ifp; if ((ifp = LYAppendToTxtFile(TRAVERSE_FILE)) == NULL) { ! exit_with_perror("unable to open traversal file"); } fprintf(ifp,"%s\n",target); *************** *** 79,98 **** FILE *ifp; ! if ((ifp = LYAppendToTxtFile(TRAVERSE_FOUND_FILE)) == NULL) { ! perror("unable to open traversal found file"); ! #ifndef NOSIGHUP ! (void) signal(SIGHUP, SIG_DFL); ! #endif /* NOSIGHUP */ ! (void) signal(SIGTERM, SIG_DFL); ! #ifndef VMS ! (void) signal(SIGINT, SIG_DFL); ! #endif /* !VMS */ ! #ifdef SIGTSTP ! if (no_suspend) ! (void) signal(SIGTSTP,SIG_DFL); ! #endif /* SIGTSTP */ ! exit(-1); } fprintf(ifp,"%s\t%s\n",fname, prev_link_name); --- 87,94 ---- FILE *ifp; ! if ((ifp = fopen(TRAVERSE_FOUND_FILE,"a+")) == NULL) { ! exit_with_perror("unable to open traversal found file"); } fprintf(ifp,"%s\t%s\n",fname, prev_link_name); *************** *** 109,115 **** return; if ((ifp = LYAppendToTxtFile(TRAVERSE_FILE)) == NULL) { ! perror("unable to open traversal file"); return; } --- 105,111 ---- return; if ((ifp = LYAppendToTxtFile(TRAVERSE_FILE)) == NULL) { ! final_perror("unable to open traversal file", FALSE); return; } *************** *** 128,147 **** FILE *ifp; ! if ((ifp = LYAppendToTxtFile(TRAVERSE_REJECT_FILE)) == NULL) { ! perror("unable to open reject file"); ! #ifndef NOSIGHUP ! (void) signal(SIGHUP, SIG_DFL); ! #endif /* NOSIGHUP */ ! (void) signal(SIGTERM, SIG_DFL); ! #ifndef VMS ! (void) signal(SIGINT, SIG_DFL); ! #endif /* !VMS */ ! #ifdef SIGTSTP ! if (no_suspend) ! (void) signal(SIGTSTP,SIG_DFL); ! #endif /* SIGTSTP */ ! exit(-1); } fprintf(ifp,"%s\n",target); --- 124,131 ---- FILE *ifp; ! if ((ifp = fopen(TRAVERSE_REJECT_FILE,"a+")) == NULL) { ! exit_with_perror("unable to open reject file"); } fprintf(ifp,"%s\n",target);