From kon at iki.fi Mon Jan 1 09:58:42 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Mon, 01 Jan 2007 18:58:42 +0200 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? In-Reply-To: <9655.1167577234@poultrygeist.com> References: <87psa0v2d3.fsf@Astalo.kon.iki.fi> <9655.1167577234@poultrygeist.com> Message-ID: <87irfqu1j1.fsf@Astalo.kon.iki.fi> "M. Levinson" writes: > The decision isn't up to me, but I think this is a good idea. Here's a > patch that would update the documentation and hooks.py, as well as hooks.c. I applied the patch as 26473f72f59641aa60277f14f703f8a76dda5a82, so that users of snapshots will notice it and can complain if they don't like it. Do you anticipate having to add more arguments to the hooks in the future; should we advise users to write hooks in such a way that they ignore extra arguments? I don't really know Python but I assume it wouldn't be difficult. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070101/3ea6144f/attachment.bin From levinsm at users.sourceforge.net Tue Jan 2 10:30:04 2007 From: levinsm at users.sourceforge.net (M. Levinson) Date: Tue, 02 Jan 2007 12:30:04 -0500 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? In-Reply-To: <87irfqu1j1.fsf@Astalo.kon.iki.fi> Message-ID: <12203.1167759004@poultrygeist.com> On Jan 01, 2007, at 6:58pm, Kalle Olavi Niemitalo writes: >I applied the patch as 26473f72f59641aa60277f14f703f8a76dda5a82, >so that users of snapshots will notice it and can complain if >they don't like it. Sounds good. I think it should be straightforward for a snapshot user to fix hooks.py (by removing the second argument to goto_url_hook() and calling elinks.current_url() if needed), but if anyone has further questions I'll be happy to help. >Do you anticipate having to add more arguments to the hooks in >the future; should we advise users to write hooks in such a way >that they ignore extra arguments? I don't expect this to be an issue. Instead of adding new arguments to the hooks, it will be simpler and more flexible to make any additional data available to them by extending the API of the embedded interpreter's builtin elinks module. In other words, rather than adding a new argument "foo" to any given hook, Python users should be provided with a new function "elinks.get_foo()" that can then be called from whichever hooks they want. From kon at iki.fi Thu Jan 4 13:03:42 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Thu, 04 Jan 2007 22:03:42 +0200 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? In-Reply-To: <12203.1167759004@poultrygeist.com> References: <87irfqu1j1.fsf@Astalo.kon.iki.fi> <12203.1167759004@poultrygeist.com> Message-ID: <87vejmsgo1.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070104/7b036ce8/attachment.bin From kon at iki.fi Thu Jan 4 15:41:35 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 05 Jan 2007 00:41:35 +0200 Subject: [elinks-dev] What to do with ELinks 0.10.6.GIT Message-ID: <87irfms9cw.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070105/87c95cbf/attachment.bin From adamg at pld-linux.org Fri Jan 5 03:28:42 2007 From: adamg at pld-linux.org (Adam Golebiowski) Date: Fri, 5 Jan 2007 11:28:42 +0100 Subject: [elinks-dev] What to do with ELinks 0.10.6.GIT In-Reply-To: <87irfms9cw.fsf@Astalo.kon.iki.fi> References: <87irfms9cw.fsf@Astalo.kon.iki.fi> Message-ID: <20070105102842.GA6769@mysza.eu.org> On Fri, Jan 05, 2007 at 12:41:35AM +0200, Kalle Olavi Niemitalo wrote: > If this is OK with Fonseca and others then I can do these. What about releasing 0.10.7 together with a notice that this is the last release of the 0.10.x branch and it will be no longer maintained? On the other hand, I don't know if there are 0.10.x users out there (apart of Debian), so maybe it doesn't really matter. -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer | Everybody needs some solid rock, I know I do. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070105/3dd7126a/attachment.bin From kon at iki.fi Fri Jan 5 14:18:54 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 05 Jan 2007 23:18:54 +0200 Subject: [elinks-dev] What to do with ELinks 0.10.6.GIT In-Reply-To: <20070105102842.GA6769@mysza.eu.org> References: <87irfms9cw.fsf@Astalo.kon.iki.fi> <20070105102842.GA6769@mysza.eu.org> Message-ID: <87ejq9rx35.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070105/4fe143ae/attachment.bin From kon at iki.fi Sat Jan 6 01:12:15 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 06 Jan 2007 10:12:15 +0200 Subject: [elinks-dev] contrib/bzip2-pipe.patch In-Reply-To: <87slferh52.fsf@Astalo.kon.iki.fi> References: <20061209204151.GA32758@pldmachine> <20061210210517.GA29321@diku.dk> <20061214162208.GA8649@pldmachine> <87y7p7qwal.fsf_-_@Astalo.kon.iki.fi> <87slferh52.fsf@Astalo.kon.iki.fi> Message-ID: <87sleor2u8.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070106/821fec54/attachment.bin From witekfl at poczta.onet.pl Sat Jan 6 04:39:52 2007 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Sat, 6 Jan 2007 12:39:52 +0100 Subject: [elinks-dev] contrib/bzip2-pipe.patch In-Reply-To: <87sleor2u8.fsf@Astalo.kon.iki.fi> References: <20061209204151.GA32758@pldmachine> <20061210210517.GA29321@diku.dk> <20061214162208.GA8649@pldmachine> <87y7p7qwal.fsf_-_@Astalo.kon.iki.fi> <87slferh52.fsf@Astalo.kon.iki.fi> <87sleor2u8.fsf@Astalo.kon.iki.fi> Message-ID: <20070106113952.GA17286@pldmachine> On Sat, Jan 06, 2007 at 10:12:15AM +0200, Kalle Olavi Niemitalo wrote: > I was going to ask the bzip2 maintainer whether bzip2-pipe.patch > would have any chance of getting in, but then I noticed that bug > 517 already has an attached patch (attachment 271) that makes > ELinks use BZ2_bzDecompress instead of BZ2_bzRead, so that it can > handle the EAGAIN errors on its own. I am sorry to reject > bzip2-pipe.patch after you've spent time on it, but I believe > changing ELinks to use BZ2_bzDecompress would be better for users > because it does not require any changes in libbz2, cannot break > other programs, and relies only on the published API of libbz2. I agree. > > Could you perhaps test the patch in > and report or > even fix any problems you find in it? It could then be included > in ELinks 0.12.0, I think. It works. In decompress_data writing to the pipe PIPE_BUF / 2 bytes at most is no longer necessary. Likewise reading PIPE_BUF / 32 on init. This is fixed on my branch. From esr at thyrsus.com Thu Jan 4 12:34:32 2007 From: esr at thyrsus.com (esr at thyrsus.com) Date: Thu, 4 Jan 2007 14:34:32 -0500 Subject: [elinks-dev] problems in elinkskeys.5 Message-ID: <200701041934.l04JYWlY002641@snark.thyrsus.com> This is automatically generated email about problems in a man page for which you appear to be responsible. If you are not the right person or list, tell me and I will attempt to correct my database. See http://catb.org/~esr/doclifter/problems.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the mod date of any manual page. You may wish to do that by hand. Problems with elinkskeys.5: 1. Since this page was generated from db2man, I understand that some of its problems may be due to db2man bugs that need to be reported upstream. I am sending this heads-up nevertheless because at least some of the problems can be fixed or worked around in your sources. 2. Running text in what should be a Unix command synopsis. The right fix for this is to change the section name. 3. Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- elinkskeys.5-orig 2007-01-02 23:56:14.000000000 -0500 +++ elinkskeys.5 2007-01-02 23:56:49.000000000 -0500 @@ -20,7 +20,7 @@ .TH "ELINKSKEYS" 5 "ELinks keybindings" "2006-01-29" "ELinks keybindings" .SH NAME elinkskeys \- keybindings for ELinks -.SH "SYNOPSIS" +.SH "OVERVIEW" Information on how to configure keybinding and overview of the default keybindings\&. @@ -87,7 +87,7 @@ Valid keys are: alphanumeric characters, punctuation, \fIEnter\fR, \fIBackspace\fR, \fITab\fR, \fIEscape\fR, \fILeft\fR, \fIRight\fR, \fIUp\fR, \fIDown\fR, \fIInsert\fR, \fIDelete\fR, \fIHome\fR, \fIEnd\fR, \fIPageUp\fR, \fIPageDown\fR, \fIF1\fR to \fIF12\fR\&. -Some keys will need to be quoted or escaped\&. For example, space can be written as " " (quote space quote), and the quote itself as \\" (backslash quote)\&. Backslash can be written as \\\\ (double backslash)\&. +Some keys will need to be quoted or escaped\&. For example, space can be written as " " (quote space quote), and the quote itself as \\" (backslash quote)\&. Backslash can be written as \e\e (double backslash)\&. .SH "KEYMAP ACTIONS" @@ -877,7 +877,7 @@ Go at a specified mark (\fImark\-goto\fR) .TP -\fI\\\fR +\fI\e\fR Toggle rendering page as HTML / plain text (\fItoggle\-html\-plain\fR) .TP ----------------------------- -- Eric S. Raymond From levinsm at users.sourceforge.net Sat Jan 6 05:30:32 2007 From: levinsm at users.sourceforge.net (M. Levinson) Date: Sat, 06 Jan 2007 07:30:32 -0500 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? In-Reply-To: <87vejmsgo1.fsf@Astalo.kon.iki.fi> Message-ID: <800.1168086632@poultrygeist.com> On Jan 04, 2007, at 10:03pm, Kalle Olavi Niemitalo writes: > I've been thinking of adding radio buttons >"Open in: (o) this tab, ( ) new tab, ( ) new window" to the >"Go to URL" dialog, perhaps even with a "[ ] reload" check box. >If we wanted to pass this data to the goto_url_hook, I think it >would be a bit unnatural to add an elinks.get_target function for >that purpose. Yes, I agree. >On the other hand, perhaps there is no reason to tell the hook >how ELinks will open the result; That was my first thought as far as this particular example is concerned (I can't think of a reason for the hook to return different answers depending on the radio button selection), but perhaps some clearer need will come up in the future. If so, here's one possible approach that would maintain backwards compatibility: Instead of passing an instance of Python's built-in string object as the hook's url argument, a future version of the backend could instead pass an instance of a new subclass of string with extra attributes containing additional details about the request. The change would be transparent for users since the number of arguments to the hook would stay the same and existing code that treats the url as a string would continue to work; but newer code could take advantage of the additional attributes as needed. > perhaps there should even be an >elinks.set_target function for the hook; Sure, or perhaps in a future version the hook could be allowed to return either a string or an object incorporating additional details about the target (which would be interpreted appropriately in hooks.c). In practice, though, the Python backend can already do something functionally equivalent to set_target; for example, here's an alternative version of goto_url_hook that opens dumb prefixes in a new tab instead of the current tab: def goto_url_hook(url): if url in dumbprefixes: elinks.open(dumbprefixes[url], new_tab=True) return '' If a different API would allow it to be coded in a more obvious way, that would be great; but the current API is already functionally sufficient for this if the scripting backend provides all of the desired "open" operations. (Right now the Python backend can open a document in a new tab but not yet in a new window, so the latter would need to be added.) > or perhaps we'll later >add a goto_url_hook2 that gets more arguments and by default just >calls goto_url_hook with the URL. That would also solve the problem, and it would be simpler to implement than the approach I described above (at the cost of being perhaps slightly less intuitive for the authors of Python hooks). While writing this, I noticed that the Python API documentation doesn't mention the effect of returning an empty string from goto_url_hook or follow_url_hook. Here's a trivial patch to remedy that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 2096 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070106/1f393a74/attachment-0001.bin From kon at iki.fi Sat Jan 6 12:49:57 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 06 Jan 2007 21:49:57 +0200 Subject: [elinks-dev] problems in elinkskeys.5 In-Reply-To: <200701041934.l04JYWlY002641@snark.thyrsus.com> References: <200701041934.l04JYWlY002641@snark.thyrsus.com> Message-ID: <87ejq8q6je.fsf@Astalo.kon.iki.fi> An embedded and charset-unspecified text was scrubbed... Name: elinkskeys.5 Url: http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070106/749c00f3/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070106/749c00f3/attachment.bin From kon at iki.fi Thu Jan 11 15:17:42 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 12 Jan 2007 00:17:42 +0200 Subject: [elinks-dev] Is setting *url = NULL forbidden in the goto-url hook? In-Reply-To: <800.1168086632@poultrygeist.com> References: <87vejmsgo1.fsf@Astalo.kon.iki.fi> <800.1168086632@poultrygeist.com> Message-ID: <87mz4p6we1.fsf_-_@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070112/452bbc20/attachment.bin From oqba4dmoyy at lydgate.e4ward.com Sat Jan 27 22:57:27 2007 From: oqba4dmoyy at lydgate.e4ward.com (Lydgate) Date: Sun, 28 Jan 2007 05:57:27 +0000 Subject: [elinks-dev] Question, Reproducible Error Message-ID: Thanks for all your great work on the browser! I've only recently discovered its mouse capabilities, and its speed makes it irresistible. One question: is it possible to map the higher mouse buttons 4, 5, etc., to back and forward to elinks running in xterm? I ask because elinks seems very capable of interpreting 1 2 and 3. Would the solution be at an elinks, xterm, or X (e.g. xbindkeys) level? Also, I'm getting every time I try to load this page: www.pcquest.com/content/linux/2005/105041202.asp I don't have gdb installed on this machine but I can do it if it will help. But from the other people in the channel it seems to be widely reproducible. For funny/offensive commentary on reproducibility: http://pastebin.archlinux.org/1052 Lydgate From kon at iki.fi Sun Jan 28 03:18:52 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 28 Jan 2007 12:18:52 +0200 Subject: [elinks-dev] Question, Reproducible Error In-Reply-To: References: Message-ID: <871wlf8neb.fsf@Astalo.kon.iki.fi> Lydgate writes: > One question: is it possible to map the higher mouse buttons 4, 5, etc., > to back and forward to elinks running in xterm? I ask because elinks > seems very capable of interpreting 1 2 and 3. Would the solution be at > an elinks, xterm, or X (e.g. xbindkeys) level? According to xterm-215/ctlseqs.txt, xterm can send press events for mouse buttons 1-5 and release events for buttons 1-3. Xterm does not define escape sequences for other mouse buttons and it is not obvious how they should be defined. I think the easiest solution would be to configure xterm to make the mouse buttons send the same escape sequences as some function keys (e.g. ESC [ 25 ~ for what ELinks thinks is Shift+F3) and then map those function keys to the appropriate actions within ELinks. http://linuxfromscratch.org/pipermail/links-list/2001-April/000996.html (which sets a *VT100.Translations resource to remap the mouse buttons) was already mentioned to you but you wrote it doesn't work for buttons 6 and 7. This appears to be limitation in libxt-1.0.0/src/TMparse.c, which supports only five mouse buttons. I don't know how difficult that would be to fix. You may be able to work around the limit by renumbering the buttons with xmodmap. > Also, I'm getting every time I try to load this page: > > www.pcquest.com/content/linux/2005/105041202.asp Thanks. http://bugzilla.elinks.cz/show_bug.cgi?id=927 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070128/d9d5df35/attachment.bin From oqba4dmoyy at lydgate.e4ward.com Sun Jan 28 06:19:57 2007 From: oqba4dmoyy at lydgate.e4ward.com (Lydgate) Date: Sun, 28 Jan 2007 13:19:57 +0000 Subject: [elinks-dev] Question, Reproducible Error In-Reply-To: References:

Message-ID: On Sun, Jan 28, 2007 at 12:18:52PM +0200, Kalle Olavi Niemitalo wrote: > This appears to be limitation in libxt-1.0.0/src/TMparse.c, > which supports only five mouse buttons. I don't know how difficult > that would be to fix. After a little more searching, it appears not so difficult in terms of code, although the fact that it requires recompiling X (I think?) means it's a little difficult: http://lists.freedesktop.org/archives/xorg/2004-July/index.html But if I understand you correctly, even adding 6 and 7 in X would not be enough, and buttons 6 and 7 would need to be defined in elinks? Although I would think that something like: :U\n\ would bypass that limitation (assuming default keybindings) along with binding Btn7Up to "Left" (although I'm not sure exactly what string this would be). > You may be able to work around the limit by renumbering the buttons > with xmodmap. I think not without losing scrolling or something else... > Thanks. http://bugzilla.elinks.cz/show_bug.cgi?id=927 Thanks for submitting this for me. Lydgate From kon at iki.fi Sun Jan 28 07:04:00 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 28 Jan 2007 16:04:00 +0200 Subject: [elinks-dev] Question, Reproducible Error In-Reply-To: References:

Message-ID: <87r6tf6yen.fsf@Astalo.kon.iki.fi> Lydgate writes: > But if I understand you correctly, even adding 6 and 7 in X would not be > enough, and buttons 6 and 7 would need to be defined in elinks? > Although I would think that something like: :U\n\ would bypass > that limitation (assuming default keybindings) along with binding Btn7Up > to "Left" (although I'm not sure exactly what string this would be). If the terminal sends ESC [ D, ELinks treats that as the Left key. In C syntax, that is "\033[D". I don't know whether libXt understands the same syntax. However, if you're editing an input field in ELinks and press Left, ELinks just moves the cursor to the left inside the input field, instead of going back in the history. If you want mouse button 7 to access the history in this situation too, you should translate it to a string sent by some other keystroke, and then map that keystroke to history-move-back in ELinks. These workarounds make ELinks treat buttons 6 and 7 as keyboard keys. A proper solution would let ELinks treat them as mouse buttons, but then the event would have to carry the coordinates of the mouse pointer as well, so it would probably require patching both xterm and ELinks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070128/3a7e6112/attachment.bin From kon at iki.fi Sun Jan 28 10:33:10 2007 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 28 Jan 2007 19:33:10 +0200 Subject: [elinks-dev] witekfl branch status Message-ID: <87odoj6oq1.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070128/3354e52c/attachment.bin From bjk at luxsci.net Sun Jan 28 11:08:32 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 28 Jan 2007 13:08:32 -0500 Subject: [elinks-dev] pwmd patch Message-ID: <200701281810.l0SIA2r3015117@rs19.luxsci.com> Here's a patch to use pwmd for form history. pwmd is a daemon that listens on a local socket and waits for commands from clients to manipulate data. The data is an encrypted XML file. The password to open/save the file is gotten with gpg-agent. Read src/formhist/README.pwmd for more info. -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E -------------- next part -------------- A non-text attachment was scrubbed... Name: elinks-git-18771fd+libpwmd-2.0.x-3.diff Type: text/x-diff Size: 30142 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070128/d5648cf3/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070128/d5648cf3/attachment-0003.bin