Re: [Lynx-dev] lynx.cfg - mime types - viewer for text terminal audio player mpg123
Klaus-Peter Wegge wrote:
> It's in the PATH and full path spec doesn't make a difference.
> But the change in .mailcap is a work arround.
> audio/mpeg; mpg123 -v %s
>
> The VIEWER definition seems to check for the
> DISPLAY env. It's set to DISPLAY=0
> May be there is something wrong with the VIEWER defintion.
As a general troubleshooting technique for this sort of thing, run:
$ strace -e trace=file -s250 -f -o lynx.strace lynx [url]
... then Do The Thing which ends up in running the wrong viewer. Then
look inside lynx.strace. Start by truncating it at the point where it
runs the wrong viewer, since it has with 100% certainty already picked
up the wrong info before that point. Then look for it accessing other
files with names like 'mime.types' or 'mailcap', anywhere in the
filesystem.
You may see ENOENT -- attempts to open files which turn out not to
exist. These might seem like useless noise, but in fact show you the
exact path of files it *tried* to use. These will of course include the
one with the unwanted viewer info; they may also point out other points
of leverage -- files it fails to open, but which you could create so
that next time it succeeds and gets the settings you want.
Overall, you should learn of (1) system files which you as admin could
edit, (2) own files which you could edit, (3) possibly, other places it
looks, which you could create to give you additional points of leverage.
Trying on my system, I got (heavily truncated trace output):
open("/etc/mailcap")
lstat("~/.mailcap")
open("~/.mailcap")
open("~/.mailcap") (yes, twice)
open("/etc/mime.types")
lstat("~/.mime.types") = -1 ENOENT
-- showing that I could add a personal .mime.types if needed for
override purposes.
>Bela<
PS: there is also `lynx -trace`, which very likely would lead to the
same discoveries. But is program-specific, so less generally helpful to
learn. It would certainly be the right thing to look at if you were
e.g. trying to understand some mis-parsing of HTML; but for questions
about what files it accesses, probably not the best tool.
Re: [Lynx-dev] An error with temporary file
Riku Virtanen wrote: > Data transfer complete > /usr/bin/brotli -j -d /tmp/lynx6fQBBD/L1617-7134TMP.html.br > Alert!: Error uncompressing temporary file! I tried to reproduce this. Had to custom-build Lynx with `./configure --without-brotli`, otherwise it used library code rather than the external utility. With the custom build, it did use the external utility (so '--without-brotli' really means '--without-brotli-lib'). And then `lynx -trace https://www.tripadvisor.comm` just worked. The external utility successfully decoded the file. It was clear in my trace that Lynx & tripadvisor *did* decide Brotli was the best format to exchange, and Lynx *did* invoke the external utility, and it succeeded. Lynx is partly at fault in your situation, for emitting a cruddy error message like 'Alert!: Error uncompressing temporary file!'. This message should be much more specific: did exec() fail? (If so, with what errno?) Did it work but the exec'd program exited with an error code? Error message? Empty output? Undecipherable output? I'm sure it has a narrower meaning we could deduce from the Lynx source, but we shouldn't have to; certainly the *next* person with this problem shouldn't have to... Anyway. You can make a fake-brotli to save the file: =cut= #!/bin/sh case $3 in *.br) cp -p $3 $3.save;; esac exec /usr/bin/brotli "$@" =cut= Add: BROTLI_PATH:/path/to/fake/brotli to your lynx.cfg, then run `lynx -trace https://www.tripadvisor.com/` again. Thus collecting a copy of whatever.br as was received by Lynx. Confirm in the trace output that it actually ran your fake-brotli; then go look for $3.save -- is it a valid Brotli format file? Is it empty? Is it an uncompressed HTML file which is spuriously being served to your browser as Brotli-compressed? [ Don't forget to remove BROTLI_PATH from lynx.cfg. BTW, is there a Lynx flag like '--cfg_line=BROTLI_PATH:/path/to/fake/brotli'? ] >Bela<
Re: [Lynx-dev] Ot: how email size is established?
Karen Lewellen wrote: > Oh its quite likely our administrator made changes, even without realizing > the harm caused. > The other end is not getting the communications at all, instead I am told > that my email cannot leave here, even if it could leave here previously. Over the years, email has been growing more and more headers related to anti-spam efforts. Message hashes, authentications, stuff like that. It is quite likely that your site admin either enabled some such feature; raised the size of an encryption key; or allowed some software component to upgrade in a manner which led to that sort of change. It is also likely that this file which you've sent many times before was previously just a tiny smidge below the limit; so any small change on the margin was going to push it past the previously invisible / unknown-to-you limit. You said you're sending this file to robobraille.org. I'm not visually impaired so I have only a few peripheral encounters & ideas of how these things work, so bear with my guesses & assumptions here. Years ago I would have assumed that a site like that would only know about the most popular formats, and text only -- probably meaning MS Word, PDF, and maybe PostScript. But by now it may support a wide variety of formats including HTML, spreadsheets, and who knows what else. It also may, or may not, support various sorts of containers. For instance, if you send it 'myfile.doc' (an MS Word doc), I'm pretty sure it will know what to do. But if you send it 'myfile.doc.zip' -- a Zip archive containing that same MS Word doc, will it still know what to do? What about 'myfile.doc.7z' or '.xz' or whatever? Those are some directions I would recommend you explore. Depending on the input format, you may be able to compress it sufficiently that, after being bloated by the outgoing encoding, it'll still fit within the ~10MB limit. You also mentioned that you've sent this same file before for conversion. Would you happen to have *received* any of those conversions? e.g. if you sent out 'myfile.doc' and received back 'myfile.pdf', it is possible the .pdf file will be smaller. Maybe you could use that as your input file for the next round. Obviously this will only help if the file is really meant to be unchanged; if at least one of the conversions ended up a smaller file than the original; and -- importantly -- if reconversion will not end up mangling the file beyond usability. But these are things you can test. Finally, it *might* work (and *might* be suitable) to edit the source file, removing some sort of redundancy (extra verbiage, unnecessary images, whatever). This is more drastic, of course. A sub-technique I've used with great success is to de-resolution images. e.g. save a large JPEG at '50% quality' and it's likely to be megabytes smaller. If the source document contains any such things -- and if you have a way to evaluate the suitability of any proposed reductions... TLDR on possible fixes: - try to reduce your input file size - by some sort of compression - by preconverting to a different format which happens to be smaller - by editing the actual contents, including possibly de-rezzing images - (back to the top) disable / detune newly added email security features And one final thought: Google Translate lets you paste in text for direct translation; OR, paste in a URL and will grab a web site for you and translate it. Can robobraille.org work from a URL, like a 'cloud' link to Dropbox / Google Drive / whatever? ANSWER: I just actually opened robobraille and *yes*, it takes URLs! So, ignore most of that blather... upload your file to some 'cloud place', make a 'share' link, paste the link into robobraille. Except -- this seems to have an accessibility issue. Robobraille's email interface sounds like it only allows direct attachments; I don't seem to see a way to tell it *via email* to translate a file found at a URL. Which means robobraille.org has a bit of an accessibility issue! Circling way back around to Lynx, I can't quite tell whether their upload page https://www.robobraille.org/web3/cover/Default.aspx can be made to operate. But it does seem to work (at least I get further) with links-the-chain. From there you should be able to either directly upload the file from your shell account; or give it the URL of a 'cloud' file. Hope this helps... >Bela<
Re: [Lynx-dev] A VCS for lynx
Thomas Dickey wrote: > On Fri, Feb 17, 2023 at 08:08:12PM +, Thorsten Glaser wrote: > > > These are called "RCS IDs", but TTBOMK lynx is developed in PRCS. > > was - > https://invisible-island.net/lynx/lynx-develop.html#patches The referenced doc says: | the user community views each phase of Lynx's versions as stable -- referering to my comment archived at: https://lists.nongnu.org/archive/html/lynx-dev/2022-11/msg5.html || Thomas will be more modest, but basically every 'dev' release of Lynx || is rock steady and might as well be released as a simple point release. || Stability bugs are extremely rare. I'm a bit bemused to see my standalone opinion attributed to 'the user community' as a whole! There might be others here who would disagree; don't really know... In any case, this was used in reference to: | Currently (as of 2023), I am simplifying the versioning by eliminating | the PRCS-dependent dev, pre and rel tags -- which is news to me. Possibly good news, I think... The last version seen on the mailing list, and mentioned on https://lynx.invisible-island.net/current/CHANGES, is '2.9.0dev12'. Thomas, are we to expect that the next version will be '2.9.0.13' and we'll go forward from there with purely numeric versions? I didn't intend for you to lose the ability to use the numbering system to clearly delineate 'prerelease' from 'release' versions! It can be a useful project capability to have a 'current release' vs. a 'forward developmental / unstable' version. Many projects do this with more subtle indications, like odd vs. even last digits in one of the dotted values. Or high numbers like '97' in the last value, implying 'almost +1 on the next digit'. Do you intend to switch to something like that? >Bela<
Re: [Lynx-dev] urls longer than 1024 characters
Jude DaShiell wrote: > Would it be possible for lynx to count the characters in an url and if the > url is longer than 1024 characters offer to send the long url to an url > shortening service and then catch the shortened url the service sent back > and then open that shortened url instead? As others have mentioned, this won't work since you'd just get redirected back to the long URL. In my experience, long URLs are usually *chock full of crap*. If you can copy-paste the URL into an editor, break it out into '=that' segments, you'll probably be able to identify one or more huge ones which are obviously useless. Remove those, reassemble the rest, and proceed. Is that a gigantic hassle? Sure. Not advocating this as a great procedure to use all the time; but if you're stuck at one URL, it's worth trying. I'm talking about things like: _key=[400 chars of gibberish] _session_key=[400 more chars of gibberish] You can definitely set the backup key on fire! Use your judgment. There are almost always heaps and mounds of useless trash. Another big pile of junk you'll see is: = = _query_boots= _jabber= ... bunch of empty variable settings. Burn them all to the ground. Almost all receivers will automatically set unspecified keys to an empty default; there is zero reason to include affirmative empty values in the URL parameters. I constantly edit URLs like this. It works. Whenever I send someone (or save for my own purposes) a URL to an item on Amazon, eBay, other commerce services, libraries, etc. -- I smash it down to the smallest *readable* URL I can manage. Like: amazon.com/dp/B081KQ17R3, or camelcamelcamel.com/product/B081KQ17R3 (well, they actually provide succinct URLs in the first place...) I've been doing this for at least 15 years and have yet to run into a case where it caused an actual problem (like locking out my account). You try an edit; either it works or you get the site's rendition of a 404 error, or some database error, and no harm is done. Try again. In something like a bug database lookup, you might mistakenly remove a parameter which was helpfully thinning the result (e.g. the one that means 'currently open bugs only'); so you get back a valid result, but broader than intended. So undo that removal, and carry on. >Bela<
Re: [Lynx-dev] a solution for this problem?
Karen Lewellen wrote: > However, when I hit enter on this link, I get a badly formed address > error...which I admit is new. Can you find out what that badly formed address link is? I'm not sure which of these might work: - `lynx -source the_problem_page > problem-page.html`, then examine that - use backslash 'view source' while in Lynx on the problem page - '=' command inside Lynx, on the problem page, while on the problem link - running the whole thing under `lynx -trace` and digging it out of the wreckage It could be as simple as them using some sort of wrong HTML or URL encoding which other browsers 'know' and silently fix -- or as unreachable as the URL has to be decoded from some sort of crypto by a JavaScript routine... >Bela<
Re: [Lynx-dev] loading incorrect webpage
"jindam, vani" wrote: > probably meaningless, but urlencode was also giving incorrect results for: > > $ urlencode > https://en.wikipedia.org/w/index.php?title=User:Jindam_vani/zandbak=history > > but it shows correct result: > > $ urlencode > 'https://en.wikipedia.org/w/index.php?title=User:Jindam_vani/zandbak=history' Not at all meaningless: it precisely shows the problem. The '&' character is meaningful to the shell, and the first command does not quote it. That command means: 1. Run 'urlencode https://en.wikipedia.org/w/index.php?title=User:Jindam_vani/zandbak' in the background 2. Immediately after launching that in the background, also run 'action=history' in the foreground [ which will finish immediately, without error ] This is standard Unix shell stuff. Quoting with 'single-quotes' is the best approach -- assuming the thing you're putting this into handles that correctly. I don't use `twm`, but chances are it will do exactly as expected, therefore work correctly as soon as you put in the quotes. All of which is completely off-topic to this list, of course. >Bela<
Re: [Lynx-dev] How stable is 2.9.0?
> > You should leap forward and then report any issues, so that they will > > cease being issues. > > My experience has been that my idea of an issue doesn't always line up > with a software project's idea of an issue. (But I do expect that the > two will line up better in lynx's case.) > > The effort involved in a leap forward is rather high, though. I don't > know how soon I'll find the round tuits for it. Unless you've linked your own C code into a mutant Lynx-relative binary, the effort should be small. Just `configure;make;make install` (with a bunch of testing in between the two `make` steps, of course). There shouldn't be breaking changes in command-line flags or anything like that which would mess you up... The 'bunch of testing' part must be where you've stashed all the negative tuits. But it should Just Work, so you start in on testing, go 'wow, this is a waste of time', install, and go from there... >Bela<
Re: [Lynx-dev] How stable is 2.9.0?
Mouse wrote: > The lynx I've been using - 2.8, from 1999 - started exhibiting a > disturbing failure mode, today: I got "lynx in free(): warning: chunk > is already free.", indicating a memory-management bug, and, in at least > one session, got a coredump (ditto, but even more so). > > I could just treat this as a debugging exercise. But I wanted to at > least look at version-jumping instead. It appears to me that the > latest release is 2.8.9, with 2.9.0 being still in development > versions. But a lot of development versions, especially for > open-source software, are plenty usable enough. And I notice that > 2.9.0dev looks relatively stable; the last-change time I see is > 2021-08-07. So, my question is, is 2.9.0 in good enough shape that I > should (FWVO "should") use it, or would 2.8.9 be better? (Of course, > it's possible that either one has some property that will render it > unsuitable for my purposes, but I figured I should at least look into > it.) Thomas will be more modest, but basically every 'dev' release of Lynx is rock steady and might as well be released as a simple point release. Stability bugs are extremely rare. Now if you are really leaping forward from a 1999 release, there may be differences which bug you. You should leap forward and then report any issues, so that they will cease being issues. >Bela<
Re: [Lynx-dev] latest mac edition of Lynx?
> The 2011 reference has absolutely nothing to do with my question. > That you consider my comment about a co-worker using a 2011 macbook pro to > be part of the question illustrates how much travesty this off course. In your initial question you mentioned a person on a mailing list. In a later reply you mentioned a coworker with a 2011 system. Since I was not looking at the first post at that time, I made the assumption that these were the same person. You are the one who introduced a separate and (as you say) irrelevant person. I am the one who mistook that for a repeat reference to the original person needing the info. > For goodness sake, why on earth would my stating a co-worker used a > macbook pro at all have any part in this discussion if they are not > seeking answers? Because it was not clear that these were separate entities. The initial form of your question was confusing because list members here expect all versions of Lynx to work on all versions of Mac OS. It would be like asking 'has this car been tested with Brooklyn pavements?' -- the respondents are flustered by the oddity of the question. If you said 'I'm trying to help someone who needs Lynx on a Mac, where can they get it?' nobody would have been confused. The answer would still be a little difficult because of the messy interaction Mac OS has with open source. I'm glad your list member will now be able to get Lynx going; and, one hopes, successfully drive their braille and/or voice assistive devices. >Bela<
Re: [Lynx-dev] latest mac edition of Lynx?
Karen Lewellen wrote: > So again, that you are not actively engaged in running Lynx on your mac > with a braille display means that your contribution is not going to help > Andrew. Karen, You didn't mention braille at all in the original question. You can hardly fault Travis for not having answered most helpfully towards that goal. Now you've also introduced '2011 MacBook Pro', which undoubtedly also means some rather out of date version of Mac OS. In which case the question your friend probably needs answered is, rather, 'What is the newest or best version of Lynx I can get for INSERT NAME OF ANCIENT MAC OS HERE?' Or, furthermore, add: 'which is built in such a manner that it plays nicely with assistive tools like a braille output device'. And THAT question is a deep question because different assistive software will have different capabilities for receiving input. The capability they need to deal with Lynx is simple ASCII input from a shell-oriented program. This is a capability I would naturally expect any Linux assistive software to have; and rather less likely on Windows; and I don't venture to guess about Mac, except that it will be somewhere between the two extremes. = The state of open source software on Macs is and always has been utterly disastrous, as far as I can tell. There are a bewildering number of competing 'comprehensive' repositories of ported software: MacPorts, Homebrew, Fink, and probably 2-3 others at lower tiers. It is(*) generally the case that if you go looking for a particular piece of open software for the Mac, it will be available in one or more of those repositories; frequently at different version levels. If you need a particular version, you're likely forced to a particular porting suite. But then if you need something that isn't in that suite (or isn't up to date in that suite, or is built with the such-and-such hooks, or just doesn't quite work right), you probably need another one. And they clash like all get out. I've been told by techie Mac users that the different porting suites *don't* clash; and then I've had any Mac I ever tried that on, catch fire. Figuratively, more or less. All of which means: if Andrew is doing serious complex work on his ancient Mac, it is fairly likely that he already has one of these porting suites. It probably has Lynx in it, so he just has to type 'fink install lynx' or whatever the actual invocation is for that suite. But, even that is quite tenuous because it's pretty likely that the porting suites have by now given up on whatever old Mac OS he's running. The *other* choice is to download the Lynx source, type './configure; make'; and hope for the best. It ought to build, assuming he has the Mac development system 'xcode' installed. On current versions of Mac OS, if you try to run one of the command line development tools like `make`, and Xcode isn't installed, it will guide you through that installation. I don't know about older releases. It is also quite likely that Apple in all their walledgardnitude will no longer *offer* the Xcode for that old OS, and the current one won't install. This mingled forest and swamp of disasters *can* be navigated through. But it will not be as easy as just asking 'what version of Lynx'. >Bela< (*)My own interactions with Macs are sporadic over the years. My info about open source porting environments is mostly out of date. But I doubt things have improved much. Perhaps there is a new, awesome, all-encompassing porting suite -- so now there would be 4 major competitors which you would somehow have to balance on a system in order to get all the pieces you want. PS: a likely much easier question is: 'where can I get any sort of version of Lynx, old or new, which runs on Mac OS version XYZ?' Various sorts of small independent builds exist. They are probably not much maintained, especially as builds for older OSes, so will be whatever old version was last built compatibly with that OS release -- which should be sufficient *at least* for a proof of concept setup.
Re: [Lynx-dev] downloading compressed pages
russell bell wrote: > In the past, when a site gzipped its articles for download, > lynx saved them gzipped. lynx stopped, but I notice that in the /tmp > directory the gzipped ones are gzipped there. That's okay with me. > I notice that nytimes.com gzips most of its articles. Few > other sites do. Are they using alternatives, such as xz or lz or bz2 > or ? Or does no one care about us losers with little bandwidth? I doubt NYT habitually sends out articles gzipped. Instead, they probably pay attention to the Accept-Encoding headers issued by the browser. If the browser says it likes files compressed with a certain compressor, they have the option of sending them that way. (I haven't checked actual wire behavior of NYT) Look for PREFERRED_ENCODING in Lynx.cfg. It can also specify bz2, which would typically save a decent amount of bandwidth vs. gz. Doesn't mean any sites are going to comply with it, but it shouldn't hurt to have both in the list. The PREFERRED_ENCODING doc implies that you could add other formats using external programs (e.g. xz). But then offers only prefab keywords for the header. Source looks like the existing ones are all that will work... ... and you can set this from the options menu, although it's one that won't save unless you also change that elsewhere. >Bela<
Re: [Lynx-dev] PASTE on second try causes core dump and abort
> I have exported RL_CLCOPY_CMD and RL_PASTE_CMD in my .bashrc and have them > directed at 'xsel -i' and 'xsel -o' accordingly. Although the problem > persists even when I use xclip instead of xsel and also no matter if I > direct the to the primary or the clipboard. > > I have added the following to the keymap: > > KEYMAP:S:TO_CLIPBOARD > KEYMAP:W:PASTE > > I have tried PASTE_URL instead of PASTE as well with the same result. > > When I start lynx the first use of those keys works perfectly and exactly > as they should. If clipboard is empty pressing 'W' will inform with a > message that the clipboard is empty. Pressing 'S' and 'L' correctly saves > link in clipboard. Pressing 'W' in that case will navigate to the > clipboard-link. Perfect. > > However whenever i try it again pressing 'W' with the same link, or with a > new saved link, or whatever variation I choose, lynx will crash with the > following message: > > A Fatal error has occurred in Lynx Ver. 2.9.0dev.5 > > Please notify your system administrator to confirm a bug, and > if confirmed, to notify the lynx-dev list. Bug reports should > have concise descriptions of the command and/or URL which causes > the problem, the operating system name with version number, the > TCPIP implementation, and any other relevant information. > > Do NOT mail the core file if one was generated. > > Lynx now exiting with signal: 11 > > Aborted (core dumped) Confirmed (on this system's installed Lynx, 2.8.8pre.4). Sufficient to have 'KEYMAP:W:PASTE' in the effective lynx.cfg, then run: $ RL_PASTE_CMD='echo /tmp' lynx . Lynx comes up showing the current directory. Hit 'W', now it shows /tmp. Hit W again, dumps core. >Bela<
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Thomas Dickey wrote: > > In #1, the system setting will override STARTFILE; you'll only see > > abc.def if the system didn't specify STARTFILE. In #2, your setting > > always overrides. Either could be what you mean, you just have to know > > what it is that you mean to mean... > > I'd regard that as obvious: lynx processes the configuration information > in the order that it's given. The existing wording in lynx.cfg suggests > using the include first, and then your own customizations. Of course it's obvious to someone who's been working on the code for decades :) This is always a question with any sort of settings-with-includes setup. Sometimes the settings act like constants -- first mention wins, others either produce warnings or are ignored. Sometimes they act like variables -- last mention wins. Sometimes the winner depends on which input files are 'privileged' (like the system-owned lynx.cfg). > (patches for suggested improvements appreciated) # and now your own tweaks. # + # Lines are scanned in the order seen and the last mention of a setting 'wins'. + # To provide defaults which you will allow the INCLUDE to supersede, list them + # first. To have your own settings take precedence, list them last: + # + # # System admin may want to override this huge SESSION_LIMIT + # SESSION_LIMIT:5 + # + # # Pick up local settings + # INCLUDE:/usr/local/lib/lynx.cfg + # + # # But my STARTFILE rules supreme! + # STARTFILE:https://my.favorite.site/ + # # Starting with Lynx 2.8.2, the INCLUDE facility is yet more powerful. You can # suppress all but specific settings that will be read from included files. > > PS: there's also a LYNX_CFG_PATH environment variable. A system admin > > could do something like: > > in the manual page: > >LYNX_CFG_PATHIf set, this variable overrides the compiled-in > search-list of directories used to find the > configuration files, e.g., lynx.cfg and lynx.lss. > The list is delimited with ":" (or ";" for > Windows) like the PATH environment variable. Right, I just mentioned it because not everyone has read or fully absorbed the man page. > > - add ~/lynx/lynx.cfg to standard files created at account creation time > > > > - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed > > by an 'overrides go here' comment > > > > - set a systemwide LYNX_CFG_PATH environment variable which points to > > the user path first; or compile it directly into the Lynx binary > > actually, the admin might read the install-instructions and compile-in > a suitable value (environment variables are for users) As I said. Anyway, 'might' is the key word. People don't read manuals, it's best to bludgeon them over the head with the needed info right at the point of need. I mean, it's better anyway, in an absolute sense. Was life better when memory DIMMs were all anonymous and you needed a parts catalog to figure out which was a 2MB-ECC vs. an 8MB-parity stick? Or now, when every unit is clearly labeled with its size, speed, manufacturer, and as much bling as they can manage to squeeze on (possibly including a little LCD which plays Doom with itself)? >Bela<
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
It's easy to use your own lynx.cfg while still keeping up with system changes. This is documented near the top of the standard lynx.cfg; but with an important omission. lynx.cfg has an 'include' facility. So all you need to do is write: INCLUDE:/etc/lynx-cur/lynx.cfg STARTFILE:https://abc.def in your own file, let's say ~/lynx/lynx.cfg; and conspire for Lynx to invoke that at startup time. Which you can do with either: alias lynx=/usr/bin/lynx -cfg ~/lynx/lynx.cfg or: export LYNX_CFG=~/lynx/lynx.cfg (using your shell's form of alias / function, or environment export...) = The important omission (at least in 2.9.0dev.7) is that it doesn't discuss ordering. These have different meanings: (1) STARTFILE:https://abc.def INCLUDE:/etc/lynx-cur/lynx.cfg (2) INCLUDE:/etc/lynx-cur/lynx.cfg STARTFILE:https://abc.def In #1, the system setting will override STARTFILE; you'll only see abc.def if the system didn't specify STARTFILE. In #2, your setting always overrides. Either could be what you mean, you just have to know what it is that you mean to mean... = Which means, in *most* cases, the user will want something like: INCLUDE:/path/to/system/lynx.cfg STUFF:that the user wants to override (Thomas, can you add a few words to clarify include ordering, in default lynx.cfg?) >Bela< PS: there's also a LYNX_CFG_PATH environment variable. A system admin could do something like: - add ~/lynx/lynx.cfg to standard files created at account creation time - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed by an 'overrides go here' comment - set a systemwide LYNX_CFG_PATH environment variable which points to the user path first; or compile it directly into the Lynx binary Then any user can do this by just editing one pre-existing file. OR the system lynx.cfg could have an 'INCLUDE:~/lynx/lynx.cfg' at its end (and the user better not have the same); except -- if that file doesn't exist, it errors out. Needs an 'INCLUDE_OPTIONAL:file' directive...
Re: [Lynx-dev] lynx word bleeding?
Karen Lewellen wrote:
> Honestly?
> Well I must have an advantage using a DOS screen reading program arctic
> business vision to come here, as I have never encountered the slight
> character overlay I am getting now, and it does not show up everywhere
> either.
> the control-l solution is working fine though on those few moments.
> Have never encountered the page problem one until this particular DOS
> computer which is much faster than any I have used previously with a
> faster processor and almost a gig of memory.
You said this wasn't happening, and then it started happening. So
something changed to cause it.
This faster 1-gig PC, how long ago did you switch to it? Did the
problem start at the same time?
I don't anything about the Arctic screen reader you're using. Is it
truly a screen reader (does nothing else); or does it also handle the
terminal emulation which collects the screens which it then reads?
The issue you're having is entirely typical of when the software making
the display using ESC sequences (here, Lynx via probably ncurses) is
using a different terminal type definition than the software
interpreting the ESC sequences (whatever terminal emulator you're using
-- built into Arctic or separate).
'using a different definition' can mean something like one things
'VT100' while the other thinks 'ANSI'. But even if the names are the
*same*, there is no guarantee their interpretations of them are the
same. At this point in history, telling a piece of Unix-ish software
that you have a 'vt100' probably produces fairly similar results on
almost all systems. But terminal emulators which claim to emulate
'vt100' are all over the map.
So, did you switch terminal emulators? Upgrade versions? Change which
terminal type it is instructed to emulate? If your terminal program
settings got erased and you had to re-create them, you might have
inadvertently changed it (by way of having set it to some non-default
value in the past, and now it's reset back to default).
To clarify some of the above tangle down to bare bones; to the thing I
think is most likely to have happened:
* If you changed anything about your terminal emulator -- different
emulator, version update, reinstall, whatever -- you probably fell back
to its default terminal type. You need to make it match (in terms of
compatibility, *not* merely name) with what Lynx thinks you're using.
A particularly likely, common mismatch is if one thinks 'vt100' and the
other thinks 'ansi', 'xterm', or 'linux'. Those are all 'compatible
enough' that Lynx will behave adequately well -- with some glitches like
words left behind after a screen update.
One way to approach it is: look at the emulator's list of possible
emulations. For each one, tell the emulator to use that; tell Lynx the
same name; TEST. So if the emulator supports 'vt52', tell it to use
that, then set TERM=vt52 and run Lynx -- does it behave better or worse?
Iterate through all the choices until you find a setting which pairs up
well. ('set TERM=vt52 and run Lynx' is itself a possible area of
confusion depending how accounts are set up on the system, your
familiarity with *ix shells, etc.)
>Bela<
Re: [Lynx-dev] How to Set vi as editor
[ completely irrelevant rambling here, move along... ] Rudy Vener wrote: > In my .profile I have: > export EDIT=/usr/bin/vi > export EDITOR=/usr/bin/vi > export FCEDIT=/usr/bin/vi > export VISUAL=/usr/bin/vi > > Note that some of the above environmental variables are specific to > ksh, my default shell, and others may be legacy variables that I keep > around simply from inertia. Still, it all works for me. None of that is ksh-specific. As usual for this sort of thing, there's a lot of sillybuggers in the history... Sorry. Amateur shell historian here :) $EDITOR is ancient, known forever to *ix programs which might want to invoke an editor. $VISUAL is slightly newer, came in around the development of `vi` at Berkeley. Most things that pay attention to $EDITOR check $VISUAL first; typically, invoke $VISUAL if it exists, else $EDITOR, else some compiled-in default. Programs that think you might want to use a different editor specifically for them will put $MYEDITOR in front of the list -- like $FCEDIT. $FCEDIT was invented by / for `ksh` (*), however, it is now widely used amongst shells with ksh-like command line editing. Furthermore my current ksh(1) man page (for ksh93 '93u+ 2012-08-01') says: FCEDIT Obsolete name for the default editor name for the hist command. FCEDIT is not used when HISTEDIT is set. ... so it's actually deprecated by its parent. (*): I think. It might have been picked up from some other contemporary which is now forgotten. And, I don't know of any program in *ix-land that pays attention to a $EDIT; though you may certainly have run into one. I have 11 traditional-ish *ix shells on this system (13 if you count `rc` and `sash`. They're all over the map on this: `bsd-csh` and `tcsh` have their own history methods, no need for $FCEDIT. (tcsh does use $EDITOR and $VISUAL for one silly unrelated thing.) bash, ksh, mksh, lksh, yash, zsh all have similar history with 'fc', all pay attention to $FCEDIT. Original (AT) ksh says it's a deprecated name. lksh seems to have working history despite no mention in its man page. bash & zsh run $EDITOR for 'fc' if $FCEDIT isn't set. They also both have a peculiar interpretation of $VISUAL. They ignore its value, just noting that it exists; then bash runs /usr/bin/editor while zsh runs /bin/vi. ??!? The dash man page talks about history, binary doesn't have it. The posh man page says 'FCEDIT: The editor used by the fc command (see below)' -- and that's the last mention in the doc. The binary doesn't have it. And, ash -- on my system is a symlink to busybox. The busybox ash build has no history and pays attention to none of those variables; the overall busybox binary has references to $EDITOR and $VISUAL, but I don't know for what. Cheers, >Bela<
Re: [Lynx-dev] the frustration of this kind of advice, was about user agent headers
If you log in and out daily then this wouldn't have helped. The only situation in which 'rehash' would have helped is if some admin moved where the lynx executable was, while you were currently logged in. When the shell successfully runs a program, it keeps a note about where it found it; if the program is moved then that note is invalid. 'rehash' tells it to throw out the current set of notes. The notes are only kept during a single login (actually: single run of the shell). If someone moved the program and 'rehash' was going to fix it, logging out & back in would equally have fixed it. I've been logged into this shell since June 14th (kept in background with GNU `screen`, so despite disconnecting many times and even having had my desktop reboot once due to a power failure, my active shell is still lumping along). So I might actually have need to rehash once in a while, though it's unlikely to surprise me since I'm the admin... :) >Bela<
Re: [Lynx-dev] reaching google in basic html with lynx.
> On Wed, 13 Oct 2021, Karen Lewellen wrote: > > > > Sharing this, in case it helps others. > > > > -- Forwarded message -- > > Date: Tue, 12 Oct 2021 19:51:07 + > > > > https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui Zachary Lee Andrews replied: > Am I missing something, the only thing I see in your message is a gmail > URL that doesn't work... Right, gmail URLs are per-person. mail.google.com/mail/u/0 is the mailbox of *your* primary logged-in google ID. For anyone else, that URL means 'the message with this hash key in *my* mailbox', which is vanishingly unlikely to exist; and if it did, it wouldn't be the same message anyway. If you want to forward text out of a gmail message, you need to forward the text, not a gmail URL... >Bela< PS: apologies to Zachary for mistakenly sending 1st copy of this to him
Re: [Lynx-dev] Google vs redirection limit [was Re: what controls the redirect limit?]
mo...@rodents-montreal.org wrote: > 302 to https://mail.google.com/mail/ > 302 to https://mail.google.com/mail/u/0/ > 302 to https://mail.google.com/mail/u/0/?ui=html=g > 302 to https://mail.google.com/mail/u/0/h/redacted/?zy=g=1 For those without the ability to change Lynx source or the redirect limit, another approach would be to start your session further into the redirect chain. Save a bookmark to one of the above. I would suggest the 2nd one -- https://mail.google.com/mail/u/0/ -- as this is completely generic. (It opens 'the 0th mailbox' of whatever Google accounts are currently logged in via cookies, or whatever mechanism it uses. For many users, this is the only account. If you're typically logged into multiple Google users at once, you could potentially also want https://mail.google.com/mail/u/1/, etc. bookmarks.) The subsequent one with 'ui=html=g' is probably also good. 'ui=html' is pretty obvious, probably means 'use the older HTML interface rather than some sort of whizbang JavaScript And Dancing Ponies interface'. Not sure what 'zy=g' is, but if you start at /u/0 and end up redirected to that, you might as well pre-encode that redirection in your saved bookmark... The one with mouse's [redacted] Google user ID might also be good, obviously with *your* Google ID; but it only saves you one more redirection; and I have some vague misgivings about encoding that in a bookmark. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Chinese characters are not displayed when using charset gb2312/euc-cn
Thomas Dickey wrote: > see > > https://github.com/ThomasDickey/lynx-snapshots/commit/5111b5306b278cecb0b66166eb8338072fc713c6 In INSTALLATION, --disable-japanese-utf8 doc is backward (says it enables the feature). I think these things would better be described something like: - disable Japanese UTF-8 logic for documents encoded in euc-jp and shift_jis - enable Chinese UTF-8 logic for documents encoded in euc-cn By naming the supported character set encodings, it doesn't oversell itself against other existing or future encodings. (Of course if this code were later adapted to other encodings, they would have to be added to this snippet of doc...) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] More or less (was Re: Where does -dump output go?)
`less` was a major improvement of `more` at a time when `more` was being maintained by someone at Berkeley who wasn't interested in UI improvements. Its tagline 'less is more' is more or less snarky... Later, apparently someone else took over `more` maintenance and added many of the same features (perhaps they didn't like the licensing of `less`, or weren't willing to ship the extra bytes, or just 'not invented here'). L still has many complex features above M, but these are not relevant to typical people who just want to page through a file. (whether to exit at the end of the file is a flag [-e] in `less`; per-system defaults might vary) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Gemini Support?
Travis Siegel wrote: > Doesn't the https protocol already handle client certificates? Or does > lynx not verify the certificates? gemini: is not https:, it's its own protocol. And it has different semantics about client certs, which is what I meant by Lynx needing to know how to manage them. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Gemini Support?
Visiblink wrote: > I browse a number of gopher sites, but a lot of the people who were once > there are now using the gemini protocol (see > https://gemini.circumlunar.space/ for information). > > Is there any possibility that gemini support might be added to lynx in > the future? One of the best features of lynx is that it allows users to > access gopher and the web in the same client. It would be great to add > gemini as well. FWIW, I looked at the various Gemini browser implementations offered. The one that seemed internally simplest, most likely to be amenable to bludgeoning into a set of C code to implement the protocol, was the Rust implementation 'Asuka' (git.sr.ht/~julienxx/asuka). (Checking out the very oldest commit in its git history provides a 14-line simple raw gemini-protocol content grabber...) Furthermore, it looks like the protocol can be summarized as: 1. parse 'gemini://host.dom/path/to/thing.ext' as: - save 'host.dom' as 'host' - save entire URL as 'url' - invoke 'gemini' procotol handler 2. open TLS(1.2 or higher,pref 1.3+) connection to '$host:1965' (providing client certificate if available) 3. send '$url\r\n' (e.g. 'gemini://host.dom/path/to/thing.ext\r\n') 4. read content 5. close connection 6. first line of $content is status (see spec) 7. for success status, rest of $content is text or binary, per MIME type given in $status 8. MIME type 'text/gemini' specs a trivial text formatting language Full spec is at https://gemini.circumlunar.space/docs/specification.html Aside from wire protocol handling, Lynx would need to know how to manage a client certificate, and be able to display text/gemini. That could be done with standard mime.types & mailcap, with an external text/gemini decoding program, if one exists. But text/gemini is trivial and can probably be implemented with a few lines of regexp substitutions to mangle text/gemini to (very simple) text/html. Possibly the trickiest bit would be preventing apparent HTML tags & entities in the text/gemini source from being parsed as HTML tags & entities... >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Viewing local directories
Klaus-Peter Wegge wrote: > UNIX only: Please use > LIST_FORMAT in lynx.cfg to configure the desired presentation format. > Useful for adjustment the length to the length of a braille display. > Examples are availabel in lynx.cfg Oh yeah, that does exist! As far as I can tell from the source, this feature is available on all targets except VMS. In fact there's an #ifdef DOSPATH that forces it on, not even allowing it to be disabled on DOS builds. Commentary suggests the default format is different on DOS, but capability should be there. Maybe dan d. previously ran Lynx on DOS or Windows and is used to its simpler default formatting. [ Thomas -- ancient (between 2.8.6dev.6 and dev.14) editing error in file 'INSTALLATION': --disable-largefile (prevent defining LONG_LIST) --disable-long-list (prevent defining LONG_LIST) 'largefile' was copied from 'long-list' and then not re-described. Seen in 2.8.9-rel1 (source I had handy) -- ignore if fixed since then... ] >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Viewing local directories
dan d. wrote: > In past, years ago, I was able to use lynx to view the items in a > directory. > > This included, as I recall, only the name of a file/directory on each > line with perhaps its size if a nondirectory entry > . > > Now this is a typical line: > > -rwxr-xr-x1 dandunfe staff 74362 Mar 7 15:54 ack > > The "ack" at the end is an application in the directory, the rest is > info about that file. > > Is there some config, or possible new one, item to provide just the > file/directory name and size? I think you must be remembering some other command-line file browser. The oldest Lynx binary I have ready access to is from version 2.5-FM, a Xenix binary dated 1996-07-19 (23.6 years ago). With only minor variations, it uses the same directory display format as current Lynx. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] changing lynx default homepage from the comand line?
Karen Lewellen wrote: > folks, > i. do. not. want. to. make. this. change. in lynx.cfg...at all! > How hard is that to understand? > I asked for *command line* not all the ways I might screw up another > person's setup. You have received a variety of alternative suggestions because there IS NO WAY to do precisely what you're asking to do, with Lynx as it exists. My suggestion to edit lynx.cfg does not affect other users. It affects only your own shell account, so will not 'screw up another person's setup'. Making an alias does not affect other users. There are many possible ways to do *approximately* what you want; but you to be willing to actually *use* those ways. 'I want this to behave differently, but I am not willing to change anything' doesn't lead to success. === Stepping back for a moment, I'm not sure if we're even clear on what you want. Your original subject line asks about changing 'lynx default homepage from the command line'. The most trivial thing is to run: $ lynx url-of-desired-homepage i.e. `lynx https://www.xyz.abc` This 'changes' the default by specifying the desired page. But you have to type it every time. Are you prepared to type it every time? That seems to meet the 'on the command line' request. But maybe you meant that you want to run a Lynx command which permanently sets it, like `lynx --set-new-homepage https://www.xyz.abc`, after which just running `lynx` with no arguments would go there. That does not directly exist. There is no Lynx command-line option which saves-for-later your new desired default page. What *does* exist is changing the value in lynx.cfg. In your own private copy of lynx.cfg -- which will not affect other users. But then you have to specify the *use* of that private lynx.cfg, each time you run Lynx. So it's a different hassle. This can be fixed by making an alias -- which is another thing which goes into your private files and doesn't affect other users. 'alias' is one of several choices: depending which shell you are using, you could instead use a shell function, or a small shell script. One way or another, you would have to slightly redefine what happens when you type 'lynx'. === As it stands, your request is like saying: I want this radio to play this show for me, which is on at 3:30pm every day. But I do not ever want to have to touch it: I will not change the station, I will not program a timer, I will not speak voice commands to it, I just want it to intuit my desire. -- Some day you may have a radio which does that (and I suspect you'll find it rather creepy) -- but the one you have today doesn't do any of those things. You have to *do something* to tell it what you want. You have to do it each day at 3:30pm, because it doesn't have a 'always jump to this station and start playing, at this time each day' feature. Editing lynx.cfg, making aliases, etc. -- these are the ways you tell Lynx (and a Unix-like shell system) what you want. If you won't do some version of those things, it won't do what you want. It can't. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] reaching gmail in basic html?
Karen Lewellen wrote: > In October 2018, a senior staff member at google stated that since only > crooks turned off JavaScript, Google was starting to use their own > proprietary edition which among other things is supposed to detect the > presence of adaptive technology for recaptcha, and track specifics > about your account access . i can share the link to that article, or > you can likely find the reference by doing a search for the term > "google will not let you log into your account without JavaScript." Please share the reference. Share everything you've got, with closest-to-source methods (URL to original post, for instance; not copy-paste quotes disassociated from their sources). > Additionally, when I first discovered that some Linux associated > browsers, Links and Elinks, which can be compiled with a form of > JavaScript, but which no longer work to log into gmail, I was told by > Thomas, a member of Google's accessibility team, that these browsers > did not use the "right kind" of JavaScript. Of all of your communications with Google, this seems to be the only thing they said which was true. Jimmying a JavaScript / DOM implementation into a text-mode browser is nearly impossible and it is not at all surprising that the version in [e]links does not meet the requirements. Of course, Google *could* modify their code to succeed in that environment, if they wanted to, but we see where that leads... > Some of the articles I find speak of a more open source form of > JavaScript, which some Linux developers use, but which now Google will > not permit. I haven't seen those articles so I don't have the correct context, but it seems to me this will again be about functional compatibility, not about Google intentionally blocking those things. A bolted-on-the-side JS/DOM implementation inside a text browser is inherently going to be pretty different from a modern graphical browser; it would probably need to be intentionally supported. > Granted, I still have a post from the google accessibility team where a > member claimed that a person should not expect to use the same adaptive > tools they could before. > > Given how often adaptive technology serves as a substitute for a persons > hands, or brain, or eyes, that attitude seems disturbing. Quite. If you're talking about a public post, please share. If it's from a mailing list or private email, consider whether you should publish it anyway. These are disturbing positions for a company like Google to take. I would expect that it's much more a case of an individual Googler talking out his ass, than an official corporate position. Perhaps the person who 'owns' the bug inside Google doesn't feel like expending the effort. Publishing it might light a fire under their ass to fix it (I hear Twitter is a good venue for this sort of thing). Note that in US law, and I believe EU and probably many other jurisdictions, there are legal requirements for software accessibility. The positions you describe seem very likely to be in violation (but I am not at all a lawyer...) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] reaching gmail in basic html?
Tim Chase wrote: > At least according to Google's support page > > https://support.google.com/mail/answer/15049?hl=en > > you should be able to go to this link > > https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui > > to force the HTML/low-bandwidth mode (hopefully a little easier than > trying to intercept the refresh). The *other* link in that post has '?nocheckbrowser' at the end; I wonder if that would help get past the insistence on JS with the low-bandwidth link: https://mail.google.com/mail/u/0/h/?v=lui ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] small issue with filenames and lynx
Thorsten Glaser wrote: > Karl Anliot dixit: > > >This is lynx's error when it encounters a filename like "important: > test.htm" > > In the place where lynx expects an URL, a filename is not the > correct thing to give to it, even if it, as a convenience (I > hate Firefox for not offering the same), often accepts it. > > Place file://$PWD in front of it (file:///home/<80> because the > cwd starts with a slash, you need three). That is the strong general solution. This is also sufficient for the particular case: $ lynx ./'important: test.htm' (or whatever quoting method you're using) FWIW, Firefox is happily doing this (accepting bare filename as a shorthand for file://path-to-file). These worked: $ firefox zort.html $ firefox ./zort.html $ firefox ./zo:rt.html -- while this failed: $ firefox zo:rt.html Firefox & Lynx therefore accepted exactly the same 3-of-4. (FF converted the last one into a search, rather than failing it as an invalid URL scheme. That still constitutes failure for the purpose of 'open this file here'...) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] lynx and amazon?
Ian Collier wrote: > On Tue, Aug 27, 2019 at 04:55:38PM +, Thorsten Glaser wrote: > > Ian Collier dixit: > > >and moreover, the later 2039 ones caused the earlier 2036 ones to be > > >deleted. > > > Oh, do you have a system with 32-bit time_t? > > Well... no. This is x86_64 and the default size of time_t is 64 bits. > The Lynx binary is a 64-bit binary. I don't know how it was compiled. Be that as it may -- the 32-bit rollover hypothesis still seems strong to me. 2036 cookies get recorded, 2039 don't. Even with a 64-bit binary, it may be that some part of either Lynx itself, or the libraries on that particular system, pass the date through a 32-bit bottleneck at some point. (Yes, it could be caused by Lynx code even if someone else demonstrated not having this issue on *their* 64-bit Lynx: the date computation may at some point pass through a system-header-provided data type which for some reason is 32-bit on one build and 64 on the other.) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Cannot open: https://m.medicalxpress.com/page2.html
Mouse wrote: > 2396 does specifically say that > >URI that are hierarchical in nature use the slash "/" character for >separating hierarchical components. For some file systems, a "/" >character (used to denote the hierarchical structure of a URI) is the >delimiter used to construct a file name hierarchy, and thus the URI >path will look similar to a file pathname. This does NOT imply that >the resource is a file or that the URI maps to an actual filesystem >pathname. > > So speaking of /./ as "a reference to the current directory" is, at > least, misleading; path components in URIs/URLs do not need to bear any > relationship to directory structure anywhere. I also have not found > any indication that . or .. components are special in absolute > URIs/URLs; again, perhaps that's just because I haven't found the right > reference. It looks like RFC3986 is the current state of the art, and specifically https://tools.ietf.org/html/rfc3986#section-5.2.4 for this. This is part of section 5: | 5. Reference Resolution | |This section defines the process of resolving a URI reference |within a context that allows relative references so that the result |is a string matching the syntax rule of Section 3. -- which doesn't really say *who* is supposed to be doing this, but I believe it's meant to be understood as 'whenever manipulating URIs'. That is, both the client (Lynx) & the server (Apache) should be modifying '/./' => '/'. Both are at fault. The RFC never mentions HTTPS and uses HTTP all over the place, but I think this is simply because HTTP is being used as a standard example scheme, and URIs are meant to be uniform across schemes. > So I think lynx is at fault for not handling relative path resolution > correctly. Depending on what I've failed to find, the webserver may > also be at fault - does anyone have any pointers to the RFC(s) I've > missed? Does this suffice? I add another quote from 3986 (sec. 1.2.3): |It is often the case that a group or "tree" of documents has been |constructed to serve a common purpose, wherein the vast majority |of URI references in these documents point to resources within the |tree rather than outside it. Similarly, documents located at a |particular site are much more likely to refer to other resources at |that site than to resources at remote sites. Relative referencing |of URIs allows document trees to be partially independent of their |location and access scheme. For instance, it is possible for a |single set of hypertext documents to be simultaneously accessible |and traversable via each of the "file", "http", and "ftp" schemes |if the documents refer to each other with relative references. |Furthermore, such document trees can be moved, as a whole, without |changing any of the relative references. This seems to make it clear that (1) the designers of the whole concept of 'URI schemes' are strongly thinking of them mapping to filesystems and (2) that the really believe in the cross-scheme concordance of URIs. So this applies to HTTPS whether or not HTTPS is mentioned or even existed at the time of 3986 publication. |A relative reference (Section 4.2) refers to a resource by |describing the difference within a hierarchical name space between |the reference context and the target URI. The reference resolution |algorithm, presented in Section 5, defines how such a reference is |transformed to the target URI. This bit *could* be taken as an oblique suggestion that only the client (Lynx), who is composing the relative reference onto the base URI of the source document, is responsible. I don't believe it's meant that way. |All URI references are parsed by generic syntax parsers when used. -- this seems like a clumsy way of saying 'thou shalt run the canonicalization code whenever operating on a URI'; '/./' should never be present in the final output. The next sentence reiterates the use of that assumption: |However, because hierarchical processing has no effect on an absolute |URI used in a reference unless it contains one or more dot-segments |(complete path segments of "." or "..", as described in Section 3.3), |URI scheme specifications can define opaque identifiers by |disallowing use of slash characters, question mark characters, and |the URIs "scheme:." and "scheme:..". >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Cannot open: https://m.medicalxpress.com/page2.html
Ian Collier wrote: > The link is written (some syntax elided): > > load more > > Most other browsers, including links, don't copy this dot into the URL > when following the link, so they don't experience a problem. > > Is Lynx correct to copy the dot? I think not. According to RFC 1808 > in Section 4 where it describes an algorithm for resolving relative > URLs, in Step 6: > >a) All occurrences of "./", where "." is a complete path > segment, are removed. > > This carries through into RFC 3986 where section 5.2.4 describes a > "Remove Dot Segments" algorithm. Lynx appears to be slightly at fault here. However, their web server is grossly at fault. '/./' in a URL is just a reference to the current directory; www.foo.bar/baz/bletch.html should be understood identically to www.foo.bar/./baz/./bletch.html. I don't remember ever having heard of an HTTP server which gets this wrong, before today. (Server claims to be running some unspecified version of Apache. I don't believe any version of Apache is ever likely to have had this problem. There may be a default rewrite rule that is always present, and they've somehow managed to delete?) The third (probably inadvertent) culprit is the web page / page author itself. IF one is in the unique circumstance of using an incompetent HTTP server which chokes on '.' references in a path, one should definitely avoid constructing such paths. The reference should read: load more == For practical purposes, regardless of whose fault this is: having arrived at https://m.medicalxpress.com/./page2.html (and received a 404), you can fix the situation by hitting 'E' (edit current page URL); arrow back far enough to erase a './', leaving only https://m.medicalxpress.com/page2.html; hit Enter, and you're there. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] "Correct" tab-stops?
Thomas Dickey wrote:
> By the way, Bela's assumptions do not work for "all" VT100-wannabe's
> (e.g., KDE konsole), as discussed here:
>
> https://lists.gnu.org/archive/html/bug-ncurses/2019-05/msg00030.html
>
> But that's a bug report for someone else...
I don't actually see how that ncurses post relates directly to my
script.
But, I also see that my script has some SCO ANSI sequences which can't
be expected to do what I intended anywhere but an SCO OpenServer
console!
Updated version below.
>Bela<
#!/bin/sh
# ^ any POSIX shell, but not really old pre-POSIX Bourne sh
row_of()
{
width=$1
column=1
while [ $column -le $columns ]; do
printf %s "$2"
column=$((column + width))
done
printf "\b\b\b\b$CR\n"
}
columns=${1:-${COLUMNS:-$(stty -a &1)" ]; then
SCOiBCS2="${CSIS}3L"
else
SCOiBCS2=
fi
# CSI 3g = CAT (Clear All Tabs)
CAT="${SCOiBCS2}${CSI}3g"
printf "BEFORE v$CR\n"; row_of 8 "T$TAB"
printf "$CAT$CR";row_of 8 "${ESC}H+ "
row_of 8 "T$TAB"
printf "AFTER ^\n"
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
I'm quoting this whole message body as I don't know if Tom is a lynx-dev subscriber (though perhaps he must be, because the list probably only allows inbound messages from subscribers?) Anyway, I'm a little worried that he went completely silent after several suggestions were offered. Mouse wrote: > >> The only thing I have been able to find is if I do a -trace the > >> trace file shows a GETCH0 got 0x just before lynx closed > >> down. > > > As Thorsten Glaser said, this is exactly how it would behave if it > > received a legitimate EOF. > > Indeed. And the suggestions are all good ones. I just have three > minor remarks: > > (1) > > > (e.g.: changing stdio settings like vmin & vtime). > > Minor nit: those are tty settings, not stdio settings. Yes, my inattention. > (2) > > > Essentially nothing about this has to do with Lynx, > > We don't actually know that at present. It could be that there is > something wrong in lynx that's making one piece of code think another > got an EOF from the tty when it actually didn't. Unlikely, yes, but no > more so than some of the other theories given. Technically true, but I'm going to predict that if we ever learn the outcome, it will not have been caused by a Lynx misbehavior. > (3) > > And, finally, are there any other ways of switching vtys? Some systems > support software-initiated switching as well as keyboard-initiated > switching; I don't know Ubuntu (or for that matter any Linux) well > enough to know whether it does. If so, it might be worth trying > switching other ways to see if it makes a difference. (Of course, this > could be difficult to test unless you have another computer you can ssh > in from or some such.) Ah, good suggestion. Yes, there are such programs. I don't know how universal these are, but Ubuntu at least has programs `fgconsole` (print the number of the currently active console virtual terminal AKA VT); and `chvt` (activate a VT by number). Tom indicated that he was hitting ctrl-alt-f4, so that must be a different VT, so the following ought to work to briefly flip the console away (this is bash / POSIX shell syntax, won't work if you're using csh or something exotic): $ cur_vt=$(fgconsole); chvt 4; sleep 2; chvt $cur_vt To test that against Lynx, something like this ought to work: $ cur_vt=$(fgconsole) $ (sleep 2; chvt 4; sleep 2; chvt $cur_vt) & lynx . -- then let Lynx sit idle for 10 seconds. If it is not disturbed, that's evidence that the problem isn't caused by the VT switching. I think the most likely alternative is the keyboard action of invoking the VT switch. > Basically, at this point we're still in the information-collection > phase, trying to probe the envelope of the problem to see if we can get > any hints as to where it might be. We do not start from a place of complete ignorance; speculating about probable causes is reasonable, without requiring a complete research project to search for hints. The speculation might be wrong, but would not have caused any significant problem if so. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
Tom Masterson wrote: > I am using Ubuntu 18.04 (Bionic Beaver) and among other things I am > running brltty as I am blind. When running lynx under a virtual console > (say tty3) if I switch to another console using ctrl-alt-function > (ctrl-alt-f4) and then switch back to lynx the computer has closed lynx. > The only thing I have been able to find is if I do a -trace the trace file > shows a GETCH0 got 0x just before lynx closed down. It appears to > be a normal shutdown. This occurs with the packaged build of 2.8.9dev.16 > or a built version of 2.9.0dev.1. > > I have not seen this in previous versions of Ubuntu or other distros. Any > ideas where I should look to figure out why this is happening? As Thorsten Glaser said, this is exactly how it would behave if it received a legitimate EOF. Here are a few troubleshooting steps I would take, and then where to go next would depend on results. Thet're in the order I thought of them, not necessarily best order to try them... 1. Question: does Lynx die (exit) when you switch away, or switch back? Use `ps` to check. Crudely, `ps --no-headers -C lynx | wc -l` will output how many Lynx processes are running. While Lynx is running, switch away and run that. Switch back and run it again (at the new command line after Lynx died). If they're the same (even nonzero), Lynx died on switch-away; if different by 1, on the switch-back. Significance: dying on switch-away suggests some sort of spurious input character issued by the switch-away keyboard sequence. Dying on switch-back suggests some sort of signal or plumbing issue, possibly in the console driver. 2. Do any unexpected processes have your tty open? Check this before starting Lynx. Run `lsof $(tty)`. Explain any unexpected outputs. Example: I just added a new tab to my running `mate-terminal` (ctrl-shift-t). `lsof $(tty)` there showed 3x `bash` (my running shell's stdin/out/err); 3x `lsof` (itself); 1x `mate-terminal` (not sure why it still has the slave side of the pty open, but it's not entirely unexpected, and it has the pty of every other tab open as well -- along with the expected N times /dev/ptmx). Nothing else. Significance: some other process could be doing something to trigger an EOF (e.g.: changing stdio settings like vmin & vtime). Why it would do that on vty switching is a mystery, but any other processes would be suspicious. Explain them, or kill (or `kill -STOP`) them before doing a test switch-away. Of course killing or suspending unexplained processes may have its own weird effects. But assuming not, if this allows a switch / switch-back to happen without killing Lynx, focus on those other process(es). 3. Run Lynx under `strace`. e.g. `strace -f -tt -o /tmp/lynx.trace lynx`. "-f" to catch child processes; "-tt" to timestamp the lines, which might show whether it happens on switch-away or switch-back, or other insights. Other flags might be useful. Once running, pause a few seconds; switch away; pause a few seconds; switch back. The pauses are to make the timestamps tell a clear story. What happens in the trace when Lynx dies? 4. What if you switch away to a different vty (ctrl-alt-F5)? Maybe it's something bad about the specific vty you've been targeting. Maybe the console stupidly injects an extra ctrl-D when you hit ctrl-alt-F4, but not for other vtys' switch sequences. This is improbable but so easy to test... Also try switching to a vty which has nothing running on it (if any). Maybe it's some misbehavior of whatever are taking the roles of getty, login, and shell, running on the switched-to vty (very unlikely but still easy to test). 5. Suppose you aren't running Lynx, but something simpler? e.g., if I run: $ bash $ read foo _ it's waiting for me to type something and hit Enter ... I hit ctrl-D $ -- shell prompt returned So, start a simple "read foo" (under `bash`, because I'm not 100% confident other shells will behave identically). Switch away; switch back. Did it return to the prompt? ... Essentially nothing about this has to do with Lynx, just some oddity on your system. Feel free to reply directly to me if you want to pursue some sort of additional troubleshooting and don't want to burden the list. (OTOH, list members might want to be in the loop; I'm not sure what the proper etiquette is in such a case.) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Year 2038 problem in handling cookie date
Thorsten Glaser wrote:
> patak...@users.sourceforge.jp dixit:
>
> >Lynx crashes when accessing the site with 32-bit system.
> >I wrote an ad-hoc patch to prevent the crash.
>
> There are more bugs, for example:
>
> 996 if ((long) Start < 0)
>
> This will cause truncation, already on MirBSD/i386 and
> Linux/x32, which are ILP32 and use 64-bit time_t.
`Start' is a time_t, so on systems where time_t is already a 32-bit int
(i.e. `long'), that cast should have no effect. Whereas it breaks
64-bit time_t. So just remove the case: `if (Start < 0)'.
The caller in LYmktime.c also needs work:
| time_t LYmktime(char *string,
| int absolute)
| {
| #if USE_PARSDATE
| time_t result = 0;
|
| if (non_empty(string)) {
| CTRACE((tfp, "LYmktime: Parsing '%s'\n", string));
| result = parsedate(string, 0);
|
| if (!absolute) {
| if ((long) (time((time_t *) 0) - result) >= 0)
| result = 0;
| }
Again, I think no cast is what's wanted. If time_t is `long', the cast
has no effect; if `long long`, it breaks. Both halves of the
subtraction are of type `time_t' and POSIX insists that time_t must be a
signed integer type, so there is no need to cast it to make it signed.
Of course, then that `if' is equivalent to:
| if (result <= 0)
and the whole section can be replaced with:
| if (!absolute && result < 0) result = 0;
Also, beware that parsdate.y is the actual source of parsdate.c, via
modern-yacc-equivalent...
>Bela<
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] "invalid cookie path", Re: redirection loop
Jude DaShiell wrote: > I was told the only machines google cookies will work on and the only > machines google is interested in are windows machines. We do have power > users running lynx on windows, but I suspect for those of us using Mac's > and Linux those are just best disabled. Whoever told you that actually meant 'I know about nothing in the world except Windows; nothing else exists, and since I don't know about it, nobody else does.' It's 100.00% pure rubbish. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] "invalid cookie path", Re: redirection loop
Thomas Dickey wrote: > On Tue, Oct 23, 2018 at 01:59:39AM -0700, Bela Lubkin wrote: > > RFC 6265 obsoleted RFC 2965 in 2011; it says: > > sure - that's > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820485 > > If you have time to work on this, I'll review/etc a patch. > Otherwise, I'll eventually get around to it. Debbug 820485 is actually about other differences between Lynx behavior and RFC 6265 (i.e.: whether cookies are indexed by host port or not -- 6265 says not). It would potentially be reasonable to *act* on the bug report as if it broadly said 'Lynx is not RFC 6265 compatible', and fix everything that could be found. I don't intend to work on any aspect of it. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] "invalid cookie path", Re: redirection loop
Sylvain Bertrand wrote:
> Regarding the "invalid cookie paths":
>
> From the trace file, I have the following request-uri:
> GET
> /search?ie=ISO-8859-1=fr=hp=tintin=Recherche+Google=1
> HTTP/1.1
>
> In server response, I have 2 cookies with an "invalid path attribute":
> /complete/search
> /search
>
> Lynx code seems to perform some prefix validation on the paths regarding the
> request uri, but it seems there is no such thing as path validation in the
> RFC:
> https://tools.ietf.org/html/rfc6265
>
> Namely, /complete/search and /search path attributes should not block lynx
> acceptance of those cookies.
The code which checks this is in src/LYCookie.c, with this comment:
* Apply sanity checks.
*
* Section 4.3.2, condition 1: The value for the Path attribute is
* not a prefix of the request-URI.
'Section 4.3.2' apparently refers to https://tools.ietf.org/html/rfc2109
(1997):
" 4.3.2 Rejecting Cookies
"
"To prevent possible security or privacy violations, a user agent
"rejects a cookie (shall not store its information) if any of the
"following is true:
"
"* The value for the Path attribute is not a prefix of the request-
" URI.
RFC 2109 was was obsoleted by https://tools.ietf.org/html/rfc2965
(2000), which had:
"3.3.2 Rejecting Cookies To prevent possible security or privacy
"violations, a user agent rejects a cookie according to rules below.
"[...]
"
"A user agent rejects (SHALL NOT store its information) if [...]
"any of the following is true of the attributes explicitly present
"in the Set-Cookie2 response header:
"
" * The value for the Path attribute is not a prefix of the
" request-URI.
RFC 6265 obsoleted RFC 2965 in 2011; it says:
" 5.1.4. Paths and Path-Match
"
"The user agent MUST use an algorithm equivalent to the following
"algorithm to compute the default-path of a cookie:
"
"[...]
"
"A request-path path-matches a given cookie-path if at least one of
"the following conditions holds:
"
"o The cookie-path and the request-path are identical.
"
"o The cookie-path is a prefix of the request-path, and the last
" character of the cookie-path is %x2F ("/").
... which means that your cookies (or at least the "/complete/search"
one) do not path-match the request. However, RFC 6265 does not appear
to say that the user agent should reject received cookies for this
reason; as far as I can make out, from section "5.3. Storage Model",
these cookies should be stored. RFC 6265 only seems to care about path
matching when later retrieving a cookie, not when initially storing one.
Thomas, do you agree?
In any case, this code was written to comply with RFC 2109 and does not
appear to have been consciously updated to the standards of 2965 or
6265. Doing so would likely be a Big Project and might break or
destabilize Lynx. I'm not sure if spot-updating this one thing to 6265
level is a good idea. It might introduce a security problem that isn't
a problem in 6265 due to changes elsewhere. (Note: I am not saying that
I have knowledge of such a problem, only speculating that it could
exist.)
>Bela<
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Still Cannot Play mp3s from LYNX?
Chime Hart wrote: > Well, Jude, your request certainly changed from trying to play in alsaplayer > to > now, says > "no space left on device" > And I certainly have room. Thanks again I've seen a bunch of discussion since this, which I think might be going in the wrong direction: Chime, please *show us* commands and outputs. Don't describe them. I *think* you are saying that, after changing the permissions on ~/.mailcap, *trying to play audio in Lynx* reports "no space left on device"; *show* us this as: $ lynx foo.mp3 no space left on device (except I'm sure there's more output -- show us the actual output). Others are interpreting it as if the `chmod` command itself failed: $ chmod 600 ~/.mailcap chmod: changing permissions of '/home/chime/.mailcap': No space left on device Maybe they're right, but I think you meant the former. IF you are getting "no space left on device" when trying to play audio in Lynx, that means progress! It means you've successfully gotten Lynx's attention and changed what it does when trying to play an audio file. Now you need to understand why it fails that way. What happens if you manually run: $ mpv foo.mp3 ? By way of example, here's what happens to me: $ mpv foo.mp3 The program 'mpv' is currently not installed. You can install it by typing: sudo apt-get install mpv -- as expected :) I might have described that as 'it said mpv wasn't installed'. Then the person helping me wouldn't have learned that I was running some sort of Debian or at least apt-based distro, and have the package 'command-not-found' installed; and perhaps more importantly (for the security-minded observer), the account I'm running from has `sudo` privileges. Not that these details are important here; but in general, this problem is going to get solved in the details. So please provide them. I ran `lynx foo.mp3` and it started `vlc` for me. So I searched found the corresponding entry in /etc/mailcap, which was: audio/mpeg; vlc '%s'; description="MPEG Audio"; nametemplate=%s.mpg; test=test -n "$DISPLAY" and copied it into ~/.mailcap (a file which previously didn't exist). And edited it to read: audio/mpeg; echo vlc '%s'; description="MPEG Audio"; nametemplate=%s.mpg; test=test -n "$DISPLAY" -- i.e. added the word 'echo' in front of 'vlc'. Now, sure enough, when I `lynx foo.mp3` it displays what it would have run, instead of running it. Specifically: $ lynx foo.mp3 vlc /tmp/lynxxweDNR/L6695-5750TMP.m4a echo vlc '/tmp/lynxxweDNR/L6695-5750TMP.m4a' lynx: Start file could not be found or is not text/html or text/plain Exiting... I can see that Lynx copied the file to a different name (and extension), then ran the command I specified. Now I have total control! I can change what Lynx(*) will run for a .mp3 file to anything I want. (*) Of course, *many* programs pay attention to .mailcap, so if I wanted to specifically change only what Lynx would use, I'd have to get fancier. And if I had a different audio file type I'd need to change a different entry; or possibly make a wildcard entry for 'audio/*'. How did I figure out that 'audio/mpeg' was the entry I needed to change? I ran `lynx -trace foo.mp3` and found this in the resulting Lynx.trace: StreamStack: found exact match: audio/mpeg -> www/present >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] wikipedia reload problem
> Wow, happens here too: > > - open https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal > - click on any link > - go back > - click on the same link again When you and iohann.f...@protonmail.com say 'not returned to the site', can you be much more detailed about what this means? Is there an error message of some sort? Do you stay on the parent page? Use Lynx's '=' command to see where it thinks you are. `lynx -trace` output would also probably be helpful... My rather rusty Lynx build (2.8.8dev.1!) does NOT reproduce any sort of problem in the above sequence. Which is to say: after step 4, I am once again looking at 'the same link' contents. Perhaps you can bisect through the release history and find when it started? >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Some links not recognized on m.facebook.com
Jude DaShiell wrote: > I changed the user-agent to w3m and encoding to none and did log into > m.facebook.com but the page is a mess links inaccurately labeled and > search for groups so far as I can tell doesn't appear on that page. Jude, Hit control-V to turn on "tag soup" alternative HTML parsing. You could also use the 'l' (letter ell) command to view what Lynx sees as hidden links -- but the result will be truly awful... Despite the horrible mess of code that Facebook sends, this does look like it's probably a Lynx bug. I boiled the problematic document down to this: Link hidden due to div encapsulation? -- and Lynx displays it as an active link only in TagSoup parsing mode. The seemingly equivalent documents: Link hidden due to span encapsulation? Link hidden due to zort encapsulation? do not behave that way. Well, perhaps not a Lynx bug. is an inline element while is block-level, and not allowed inside . (And apparently mystery tags are considered "inline".) So the code being fed to Lynx is wrong. Yet the result seems overly punitive to the user... http://stackoverflow.com/questions/1827965 seems to cover this well. http://html5doctor.com/block-level-links-in-html-5 says it's legal in HTML5, FWIW. >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Invoking a lynx script
Graham Lawrence wrote directly to me: Having 2 macros, one lynx and one vim, would be fine, except the only way I've found to invoke a lynx macro is by a separate invocation of lynx, as xterm -g 120x54 -e lynx -cmd_log=/path/to/script url so its just like lynx -dump, you have to know the url you want to operate on. I can do a dump of the current page most economically by pENTERCTRL-U~/dENTERALT-TAB:r ~/dENTER 15 keystrokes vs. CTRL-ACTRL-CALT-TABCTRL-V 4 keystrokes in a gui browser and editor. Is there a way to invoke a lynx script without requiring a separate invocation of lynx? I replied asking him to repost to the list, but he didn't, nor replied to me, so I think my reply didn't get through. As there is nothing private in the message, I am following up here instead. First, I dispute the keystroke counts: I see 20 for the dump-and-read method vs. 8 for cut-and-paste. Ctrl-foo and alt-bar are 2 keys each for the operator, regardless of what a program's input stream might count. Second, both parts of the dump-and-read method can be shortened up. In lynx.cfg, add a PRINTER or DOWNLOADER which doesn't take a filename (only one %s in its definition) and which writes its output to an agreed-upon location. I suggest something like $HOME/.lynx-copy-out. Now it's p1ENTER (3 keys) to copy out. If my reading of the PRINTER section of lynx.cfg is correct, the script for this could be as simple as just 'cp $1 $HOME/.lynx-copy-out'. You could reduce this to two keys (pENTER) if you can figure out how to make your PRINTER definition the first in the 'p' menu. In vim, make a macro which performs :r $HOME/.lynx-copy-out (whatever shared filename you've chosen). So the full sequence is: p1ENTERALT-TABCTRL-???: 5 keys by your count or 7 by mine. Assuming you can dedicate a ctrl-??? or alt-??? 2-key sequence to the operation. Or you can use the program `xsel` (available in package xsel on Ubuntu and Debian). Your PRINTER script can be 'xsel -p -i $1'. Your full key sequence is: p1ENTERALT-TABSHIFT-INS, and you don't need to create a vim macro. This is effectively the same as the agreed-upon location method, but the agreed-upon location is the X primary selection buffer. Finally, look for EXTERNAL: in lynx.cfg. I added the following lines to mine: EXTERNAL:ftp: lynx -dump -nolist %s | xsel -p -i:::XWINDOWS EXTERNAL:http:lynx -dump -nolist %s | xsel -p -i:::XWINDOWS EXTERNAL:file:lynx -dump -nolist %s | xsel -p -i:::XWINDOWS Now if I hit ',' in Lynx, it brings up a menu where the first choice is lynx -dump ...; I hit ENTER and it copies the contents of the current page into the X primary selection. '.' does the same with the current link that Lynx's cursor is on. Then I commented out the previously existing EXTERNAL: lines; now '.' and ',' did their work *without* putting up a menu. Note: I originally had an EXTERNAL:https: line as well, but that caused it to bring up two identical choices in a menu on https URLs. It seems that https URLs get offered both http https external choices. Nota bene: unlike a PRINTER definition, EXTERNALs receive a URL rather than a formatted output file. In my examples I'm invoking a Lynx subprocess to format that URL. The resulting output is similar to what you might see if you hit ^R (reload) inside Lynx, then 'p'rinted the result. Pages which come up differently each time (e.g. rotating ads) will be different; pages that check the HTTP referrer header may be different; etc. You might use that to advantage, e.g. adding -width 1 so that paragraphs are inserted without line breaks (then vim's :set textwidth= wrapping will work). Slight bug there: Lynx has a line length limit of 1014 chars (from testing); paragraphs longer than that will have arbitrary line breaks inserted. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Invoking a lynx script
Thomas Dickey wrote: On Mon, 10 Oct 2011, Bela Lubkin wrote: You might use that to advantage, e.g. adding -width 1 so that paragraphs are inserted without line breaks (then vim's :set textwidth= wrapping will work). Slight bug there: Lynx has a line length limit of 1014 chars (from testing); paragraphs longer than that will have arbitrary line breaks inserted. yes - it's a compile-time limit, used in various buffer-sizes as well as a chunk-size in GridText.c's memory-allocation scheme. Yes, documented as LINE_MAX in recent man pages. I've never tried compiling Lynx with an expanded LINE_MAX: does it work or does it run into countervailing assumptions elsewhere in the code? I imagine that setting it to a large value like 1M would bloat the Lynx process (but nothing like a GUI browser...) and probably slow it down as well... Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Invoking a lynx script
Thomas Dickey wrote: BL You might use that to advantage, e.g. adding -width 1 so that BL paragraphs are inserted without line breaks (then vim's :set textwidth= BL wrapping will work). Slight bug there: Lynx has a line length limit of BL 1014 chars (from testing); paragraphs longer than that will have BL arbitrary line breaks inserted. TD yes - it's a compile-time limit, used in various buffer-sizes as well TD as a chunk-size in GridText.c's memory-allocation scheme. BL Yes, documented as LINE_MAX in recent man pages. I've never tried BL compiling Lynx with an expanded LINE_MAX: does it work or does it run BL into countervailing assumptions elsewhere in the code? I imagine that TD I recall checking in a previous discussion, and found some buffer-sizes TD that should be made dependent on that. Ok, then not for random people to mess with... BL setting it to a large value like 1M would bloat the Lynx process (but BL nothing like a GUI browser...) and probably slow it down as well... TD It probably would be slower, though it might be interesting to massage TD the code so that it could use plain malloc/free in GridText.c to see TD how much faster the current scheme uses. I was thinking there were probably things like sprintf() or memcpy() where libc would end up zeroing or copying the entire trailing buffer after the interesting part. TD For the buffer sizes - there are probably some special cases that would TD complicate things. No doubt. So for my original purpose (avoiding buffer-size-imposed line wrap in -dump output) it might be better to kludge it. Add a -dont_wrap flag (following the example of -dont_wrap_pre). When inserting a line break due to running out of buffer space, remember the reason; when actually outputting it, if the reason was out of space rather than document said so, output the line without a trailing newline. -dont_wrap would also set -width to the applicable max (so that the out of space, don't newline path isn't exercised unnecessarily). Or don't add -dont_wrap, just turn the behavior on automatically if -width is greater than the build can handle. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Invoking a lynx script
Thomas Dickey wrote: On Mon, 10 Oct 2011, Bela Lubkin wrote: So for my original purpose (avoiding buffer-size-imposed line wrap in -dump output) it might be better to kludge it. Add a -dont_wrap flag (following the example of -dont_wrap_pre). When inserting a line break due to running out of buffer space, remember the reason; when actually outputting it, if the reason was out of space rather than document said so, output the line without a trailing newline. -dont_wrap would also set -width to the applicable max (so that the out of space, don't newline path isn't exercised unnecessarily). hmm - but the dump is working from essentially the same data that would be displayed - and already subject to line-length. I recall that lynx uses some special control characters to denote things like bold- and underline-, as well as something related to wrapping. There may/may not be enough existing logic to make an option like that relatively simply to implement. I looked at the wrap code scattered around GridText.c and HTML.c (plus little bits in HTMLGen.c, SGML.c, LYCharUtils.c, LYCurses.c, LYMain.c) and decided not to tread there... There's way more than enough existing logic. If it can be called that. ;-} Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Invoking a lynx script
Graham Lawrence wrote: Bela, I received your response asking that I post my question to the list rather than to you personally. I took that as an indication that emailing you directly was undesirable. So I did not respond to it explicitly, only implicitly, by posting my question to the list as you requested. I received a reply from Thomas Dickey, for which I thanked him, and considering the issue closed, made no further post. Instead I wrote the bash script alternative I had alluded to in my reply to Thomas, and now dump lynx pages into vim with a single keystroke combination, or 2 keystrokes as you prefer to count it. I don't think I saw the repost; or maybe you posted in different wording and I didn't recognize the congruence of the messages. As well, I don't remember seeing a 1-2 key solution as you mention here. This could all be because I failed to receive a message or two; or because I read them inattentively and didn't gather the details. In any case I've already deleted all of the past of this conversation, so I can't investigate :( Anyway, I'm not very interested in what/why that happened, I chalk it up to the vagaries of asynchronous multi-way communications and don't worry about it. What I *am* interested in is to hear the details of how you solved this down to a 1-key action! Bela PS: I prefer not to receive direct copies of list postings. They exacerbate the asyncronicity problem. Posts laundered through the list are generally in correct perceptual order since each reply is not provoked until the replier receives the message he's replying to. Mail to my mailbox is more likely to be mis-ordered because the mail host's connection is less reliable, leading the sending mail daemons to invoke their delay algorithms -- which are different for every sending host. Plus, I read the different mailboxes with different frequencies. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Transferring page text from lynx to vim
Thorsten Glaser wrote:
Bela Lubkin dixit:
${@-/dev/stdin}POSIX shell syntax for This script's arguments,
or if none, /dev/stdin (standard input)
You want ${@:-/dev/stdin} with the double quotes and the colon.
(Yes, that's POSIX.)
I agree about the quotes. Fortunately the script in question is part of
a `man` back-end and will never actually see filenames with spaces.
I would argue that - is correct here, not :-. That is, the commands
`lynx2ascii` and `lynx2ascii ` *should* behave differently. Lynx's
behavior for a blank argument is to output nothing, not to consume
stdin. That behavior seems more likely to conform to the expectations
of a script invoking this script; if it truly intends to process stdin
then it should pass no arguments.
(Looking at it another way: the missing quotes are an outright error;
- vs. :- is a question of intent, and as the author, I _intend_ my
script to behave differently for no-args vs. empty arg.)
Bela
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Transferring page text from lynx to vim
Graham Lawrence wrote: In lynx, I google my question, choose the response that speaks to my level of expertise and either copy and paste some text from lynx to vim or in xterm issue the command lynx -dump url file then in vim I do :r file My most recent discovery in vim is :map and so I immediately wanted to do something like :map ln :!lynx -dump url fileCR:r fileCR The sticking point is the value of url, how do I get it programmatically, hence my question about a global variable. In your proposed :map macro, Lynx isn't yet running -- you invoke it right there. So there cannot be a Lynx-internal variable which contains the URL until you supply one on the Lynx command line issued by the macro. So your question is really how do I get the URL into that macro? I don't use such macros, so I am not going to attempt a full solution. Instead, here are some factoids, little tricks that I *do* use and may help you get to your goal. I frequently insert the output of commands into a vi buffer. For a command which takes no input, I insert a blank line, then while on that line in edit mode, I type !!command, e.g. !!lynx -dump http://foo.bar;. The blank line is because I'm abusing the behavior doubled command operates on current line -- I'm piping one blank line to the command, knowing that it will ignore stdin. For you, this would be useful in a macro intended to dump a URL. You could create a macro which expects the current line to contain a URL; when you invoke the macro, the URL is replaced by a formatted dump of the URL's target. For a filter, I mark two end points: ma and mb; then :'a,'b!command. You could use this to create a macro which expects a range of lines to be HTML source code and replaces it with formatted output of that code. For clarity, the two macros I'm suggesting would be used for: 1. line contains http://en.wikipedia.org/wiki/Spleen; 2. range of lines contains html ... bunch of HTML source/html; although of course Lynx is forgiving about such technicalities as omitting html, head etc. I think #1 is what you are seeking, more or less. It is also probably possible to create a single macro which recognizes the situation and does the appropriate action. Getting back to the original question, I think what you are really asking is: you have Lynx running in one location (X window, terminal program tab, GNU screen, etc.), and vim in another location. The Lynx session is looking at a page you want to copy into the vim session. To do that you would need some sort of inter-process communication. The default is to view the URL in Lynx (=) command, use mouse cut-and-paste to inject it into vim. You could create a Lynx macro (e.g. PRINTER or DOWNLOADER) which echos the URL into a default filename, and a vim macro which injects formatted output from the URL read from that file. If you want to automate it further -- be able to hit a single command inside vim, for instance -- you'll need fancier IPC. A way to signal the Lynx session to save the current URL somewhere accessible to vim. I can think of various horrible ways to do that, e.g.: - run Lynx under `ltrace`, use a script to parse URLs (but: insane; also very difficult to determine which URL is the desired one) - run Lynx with -trace flag, use a script to parse URLs (but: moderately insane; might also be difficult) - modify Lynx to use setproctitle() (if available) to always display the current URL in an accessible location; use `ps e` or local OS's equivalent to scrape it (but: won't distinguish between multiple Lynx sessions correctly) - modify Lynx to use putenv() to establish an environment variable like LYNX_CURRENT_URL, and maintain it; use /proc/$PID/environ or local OS's equivalent to scrape it (but: also trouble with multiple Lynx sessions) - vim macro runs a script which finds the Lynx session and uses terminal escape sequences to inject characters into its stdin, resulting in Lynx executing a macro that saves the URL (but: extra insane; near-infinite number of things can go wrong) Those are all ideas of how to do this with a single vim macro. One could also propose ways to use a single Lynx macro which emits the current URL to a script, and the script uses another Lynx to format the output, then some sort of insanity to signal vim to read the resulting file. One idea for the signaling method is to use autocmd, possibly with one of the events TermResponse (not sure how this could be used); VimResized (send SIGWINCH to the vim process to trigger it); RemoteReply (set up a fake vim server to do nothing but send replies when Lynx tells it to); or User + :doautocmd + I'm not sure what else.) OR, modify vim to add a set of user-accessible signal handling facilities so that you can e.g. send SIGUSR1 and catch that in an autocmd. === Of all the crazy
Re: [Lynx-dev] [Patch] Lynx won't compile against zlib 1.2.5.1
Tom Dickey wrote: Nikos Chantziaras wrote: Trying to build Lynx with zlib 1.2.5.1 results in build errors, due to the 'ON' macro of zlib, which conflicts with the one in LYUtils.h. Here's a bug report about it on Gentoo's tracker: https://bugs.gentoo.org/show_bug.cgi?id=383113 A patch that fixes the problem by renaming Lynx's ON and OFF macros to LON and LOFF: https://383113.bugs.gentoo.org/attachment.cgi?id=286575 ON/OFF are on the other hand unnecessary in lynx altogether - making them TRUE/FALSE would be simpler (similar to BOOL vs BOOLEAN, but different since the latter are typed). It's good that you've fixed this in Lynx. The triggering bug here, however, is that zlib 1.2.5.1 introduced these bogus ON/OFF macros. Gentoo has picked that up: https://bugs.gentoo.org/show_bug.cgi?id=383179 (and related bugs 383347 383349 383351 383371). The issue has already been raised on the zlib-devel mailing list: http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-September/002621.html -- although not yet substantively responded to. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] lynx2.8.7pre.5
Thomas Dickey wrote:
On Mon, 8 Jun 2009, Bela Lubkin wrote:
I would swallow the idiom:
if (LYBadHTML(me)) {
char *msg = NULL;
HTSprintf0(msg, printf-like-args);
LYShowBadHTML(msg);
FREE(msg);
}
into something like:
LYShowBadIfBad(me, printf-like-args);
I thought about that, but the current scheme is more efficient (since it
doesn't have to evaluate and pass along a set of parameters whether or not
they're going to be used).
Then swallow it into:
if (LYBadHTML(me)) {
LYBadHTMLPrintf(printf-like-args);
}
which could be further hidden inside a macro, or not...
Bela
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] lynx2.8.7pre.5
Thomas Dickey wrote:
On Sun, 7 Jun 2009, Bela Lubkin wrote:
Personally I would like to be able to suppress all of them but still
have them logged to where LYNXMESSAGES: would retrieve them -- in their
expanded (rule-specific) forms.
that sounds reasonable...
see
ftp://invisible-island.net/temp/lynx2.8.7pre.5b.patch.gz
Looks good -- haven't tried to compile, don't have a 287pre5 baseline to
patch onto.
I would swallow the idiom:
if (LYBadHTML(me)) {
char *msg = NULL;
HTSprintf0(msg, printf-like-args);
LYShowBadHTML(msg);
FREE(msg);
}
into something like:
LYShowBadIfBad(me, printf-like-args);
Bela
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] lynx2.8.7pre.5
Thomas Dickey wrote: * remove Bad HTML warning for buttons outside a form, since those can be inline, according to the HTML 4 DTD -TD I'm not sure any of those warnings are particularly useful. They just disrupt viewing of common web pages. Trying to get a web site to change their ways to accomodate Lynx (even if standards agree with you) is a losing battle... Is there currently a way to disable all BAD HTML messages without turning off other messages? If not, can one be added? I was going to complain generally about Bad HTML messages not explaining what was wrong, but I see in the source that many of them do; while others just use LyBadHTML(). No, on closer look it's worse -- it gives the generic Bad HTML message unless you're tracing, even when the more specific messages are compiled into the binary and available to the caller. I don't see the benefit of a generic ** Bad HTML!! Use -trace to diagnose. ** message vs. a specific Bad HTML: BUTTON tag not within FORM tag or whatever it is. It's just an unnecessary step for people who actually want to debug it. For people who want to ignore it, the words Bad HTML probably turn the brain off quickly enough that it doesn't matter what follows. Personally I would like to be able to suppress all of them but still have them logged to where LYNXMESSAGES: would retrieve them -- in their expanded (rule-specific) forms. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] 2-8-7.pre1 : lynx.cfg re storing sessions
Date: Wed, 18 Mar 2009 19:47:58 -0400 From: Thomas Dickey dic...@radix.net There's been an INCLUDE in lynx.cfg for several years: 1998-03-18 (2.8.1dev.1) * implement simple 'include' facility for lynx.cfg - BL ... he says, precisely on its 10th birthday ;-} Bela PS: seems like Lynx has been stuck at 2.8 for a while. ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange table behaviour with example spam x2 and other browsers
Rado S wrote: I use lynx as html-filter for mutt. Recently I saw a spam-mail that looked as if it was a stereogram (imagine how surprised I was to see this in spam! ;). After giving up finding the hidden message, I tried other browsers, believing it was designed for some special system. Much to surprise and disappointment, firefox + links + w3m all displayed the spam different from lynx, and with the new perspective it was clear that it was _no_ stereogram but just badly broken up table cells. See yourself: http://www.ghb-hamburg.de/rado/spam.html http://www.ghb-hamburg.de/rado/spam2.html Now, why do those other browsers show 2 rows as 1, so that the spam is actually readable there while lynx shows the 2 rows as 2, which makes it hard to recognize as spam? That's not a bug, it's a feature! ;-} I much prefer Lynx's presentation. It is instantly obvious that it's some sort of useless spam, and as a bonus, I don't even have to sully my eyes with knowledge of what they're selling. BTW, two `w3m` versions I have laying around also fail. 0.1.11-pre (2000) looks a lot like Lynx. 0.5.1 (Cygwin, 2005) manages to integrate the stuff vertically, but spacing is still crazy, resulting in garbage like W o rl dwi d e D i sc ree t Sh ip p in g. T he pu r vey o rs o f t h is g ar b age s ho u ld b e l i n ed up a nd sh ot. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] [PATCH] Improving the appearance of justified text
Andrew Belov wrote: Here is a minor patch for the EXP_JUSTIFY_ELTS feature. In its current implementation, spaces in justified lines are concentrated near the beginning of each line - this doesn't look neat IMO: Lynx is the text web browser. This is the top level page... The patch changes this to achieve a uniform spacing: Lynx is the text web browser. This is the top level page... Hmmm, well, it looks differently horrible. ;-} BTW, I believe Lynx conflates EXP_JUSTIFY_ELTS with wanting justification. That is: if you configure the build that way, the option is on by default in the resulting binary. This doesn't seem right to me. The configure option should just enable the flag; people who want it on at runtime should have to say so. Also, at least in the past if you built Lynx without EXP_JUSTIFY_ELTS, the -justify command line flag made Lynx abort. I ran into this while writing a script that used Lynx to dump HTML to ASCII -- I put in -justify=off and everything was happy until it ran into a Lynx built without the option. Let's leave the option parsing on even when the option code is disabled. That makes the command interface more uniform. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] README.options
Thorsten Glaser wrote: Bela Lubkin dixit: different reasonable assumption would be that Save options to disk only writes out changes made during the _current_ [O]ptions session. No. It says Save options to disk not Save changes in configuration parametres to disc. My mistake, you're right, nobody could ever misunderstand a sentence or have experience with software that does anything differently from Lynx. Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] justify-elts
[EMAIL PROTECTED] wrote: 20050129 09:13 -0500, Thomas Dickey Generally it looks nicer, but I've read comments on the topic that claim that makes it less readable. One bug--searches don't allow for the variation in whitespace (something that's been on my to-do list for a while). I find that full justification reads better only in pitchless type. I hav seen books printed through line-printers, or the likes of the LA120, with full justification, and they always looked bad to me. Indeed. I find justified text in monotype fonts incredibly ugly. Lynx's --justify looks horrible. One of my email correspondents justifies all of his messages, including any quoted reply parts. Looks awful. He won't hear of it. It's great that Lynx has it as an option, for those wrongheaded [;-}] people who think it looks better... Bela ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] XHTML thwarting
Tom Dickey wrote: On Fri, 17 Sep 2004, Atsuhito KOHDA wrote: Thanks for your reply. From: Doug Kaufman [EMAIL PROTECTED] Subject: Re: [Lynx-dev] XHTML thwarting Date: Thu, 16 Sep 2004 20:19:49 -0700 (PDT) In lynx one hits \ to see the source of http://women.alioth.debian.org/faqs/, but can't. Perhaps this is due to Content-Type: application/xhtml+xml;charset=iso-8859-1 ?xml version=1.0 encoding=iso-8859-1 ? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional/ etc. etc. I don't see this with lynx2.8.6dev.5 built under MingW or with lynx2.8.6dev.4 built with DJGPP. I can get the source without problem when I press the \ key. Sorry, my explanation was not clear enough. I thought a reporter claimed that But the headers that I get are different. I get Content-Type: text/html;charset=iso-8859-1 and don't have the line with ?xml ... at all. the differnce you mentioned was a bug. If one neglected that diffenence, yes, we could say lynx showed the source. lynx is showing the source (comparing with opera which also starts with the doctype line). If you download the page (with lynx), that line shows up in the HTTP headers, e.g., !-- X-URL: http://women.alioth.debian.org/faqs/ -- !-- Date: Fri, 17 Sep 2004 10:55:07 GMT -- BASE HREF=http://women.alioth.debian.org/faqs/; META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=iso-8859-1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.or html lang=en head I think he's complaining that it doesn't show _xml_ source. The missing aha! here is that the _server_ is sending different pages, according to the wishes of the browsers. Opera tells it that application/xml is an acceptable data type; Lynx doesn't. The source sent to Lynx is text/html because that's what Lynx offers to parse. Bela ___ Lynx-dev mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] options pane quirks
Gisle Vanem wrote:
I didn't see any sub-second sleeper, so I added one using select().
It's an error to use select() like this on Windows. Hope other targets
allow this (i.e. all fd_set to NULL).
Ops, something like this is better. I couldn't test this with djgpp
version under Win-XP since S-Lang doesn't seem to support under Win-XP.
#ifdef USE_MOUSE
static void mouse_select_delay (int msec)
{
#ifdef _WINDOWS
Sleep (msec);
#else
struct timeval tv;
msec *= 1000;
tv.tv_sec = msec / 100L;
tv.tv_usec = msec % 100L;
(void) select (0, NULL, NULL, NULL, tv);
#endif
}
#endif
This should not be presented as a mouse-specific function. If existing
facilities inside Lynx aren't adequate, add a new generic function e.g.
`msec_delay()'.
The _contents_ of that function will, over time, become a snarled mess
of #ifdefs. You've made a start on that.
BTW, for debugging purposes it's best not to change the args passed to a
function. If Lynx dumped core while in a `mouse_select_delay(20)' call,
a stack dump would show `mouse_select_delay(2)', which might confuse
some future person trying to debug Lynx.
Bela
___
Lynx-dev mailing list
[EMAIL PROTECTED]
http://lists.nongnu.org/mailman/listinfo/lynx-dev
