http://permalink.gmane.org/gmane.comp.web.links hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.links/3530 <pre>Hello, I'm a long time user of elinks, and recently, I tried to build a lua script to add to elinks the same behavior than vimperator/pentadactyl hint mode : You enter in the hint mode by pressing « f », all links in the page becomes highlighted and labelled, like when you press « . » in elinks for showing links number. Then you begin to type some letters on your keyboard : only the links with thoses char in the text become selected (the links number are updated for counting only the selected links). Ok, that's easy : I just have to fetch all links on the current document, and each time the user enter a key in the message box, match the text with the link name for each link, and set the link as selected or not. I can do this in lua ! Let's take a look in the lua api, there are some fonction described in the documentation, for interracting with elinks core (open a message box…), but where is the api for the differents object (link, document) ? It seems it as not been written… Ok, let's take a look</pre> Sébastien Dailly 2012-02-11T13:00:28 http://permalink.gmane.org/gmane.comp.web.links/3529 <pre>http://www.nongnu.org/libruin/ (Renderer for User Interfaces in Ncurses) This is an excerpt from the home page: libRUIN (Renderer for User Interfaces in Ncurses) is a rendering library for various XML-based user interface markup languages (such as XHTML or Mozilla XUL), using the Ncurses terminal control library as a rendering target. GNU Guile and the SDOM Scheme module are used as the "glue" that manages user input and event handling (as such, event handlers must currently be written in Guile Scheme; support for ECMAscript event handlers is being considered for inclusion). An application programmer passes an XML document (including, potentially, a set of CSS stylesheets) and an Ncurses WINDOW structure, and libRUIN paints the WINDOW according to the markup and CSS; the programmer may subsequently pass Ncurses-style input strings to that WINDOW via libRUIN, and libRUIN will handle the resulting event flows. Development status * Many simple XUL documents can be rendered </pre> clemens fischer 2011-09-20T17:06:23 http://permalink.gmane.org/gmane.comp.web.links/3528 <pre> Hi, I'm currently short of time, so just a quick comments: - The current source format properly supports having the debian dir in the main tree, so there's no need to move it to contrib: http://wiki.debian.org/Projects/DebSrc3.0 - Personally I would be happy to move elinks to a larger maintenance group, so if this is fine with Giridhar we'd be happy to sync the debian dir with upstream git. - Likewise if you, Kumar, wants to join for maintenance that would be welcome as well. Cheers, Moritz </pre> Moritz Mühlenhoff 2011-08-10T18:41:45 http://permalink.gmane.org/gmane.comp.web.links/3527 <pre>---end quoted text--- According to Debian changelog [1], it seems to be Siegfried-Angel Gevatter Pujals (RainCT) &lt;rainct&lt; at &gt;ubuntu.com&gt;: elinks (0.11.3-6) unstable; urgency=low * Remove 11_303164_css_display_none.diff as it is useless without the fix for upstream bug 722. * Change ELinks category in desktop file from Categories=Utility;Network; to Categories=Network;WebBrowser; Thanks Franklin PIAT &lt;fpiat&lt; at &gt;bigfoot.com&gt; (Closes: #474393) * Steal a few .desktop file improvements and translations from Ubuntu [from Siegfried-Angel Gevatter Pujals (RainCT) &lt;rainct&lt; at &gt;ubuntu.com&gt;] * Much improved packages descriptions -- Y Giridhar Appaji Nag &lt;giridhar&lt; at &gt;appaji.net&gt; Thu, 10 Apr 2008 13:34:13 +0530 [1] http://packages.debian.org/changelogs/pool/main/e/elinks/current/changelog </pre> أحمد المحمودي 2011-08-02T21:31:52 http://permalink.gmane.org/gmane.comp.web.links/3526 <pre> elinks.desktop is useful to multiple distros. I think it is better to keep an official version of it in the ELinks tree than require packagers to look for updated versions from each other. Deleting the rest of contrib/debian/ is OK with me. Building a Debian package gets the version number from the changelog, which nobody has bothered to update after the 0.11.0 release, so it looks like nobody is building Debian packages with those files. After we release 0.12.0, Debian will have that version in their archive soon enough. I see you are who last updated contrib/elinks.spec.in. If you say it is not needed, I trust you. Now, what should be added to AUTHORS for those Ubuntu changes of elinks.desktop? _______________________________________________ elinks-dev mailing list elinks-dev&lt; at &gt;linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev </pre> Kalle Olavi Niemitalo 2011-08-02T20:32:52 http://permalink.gmane.org/gmane.comp.web.links/3525 <pre>Dear Kalle, I am only a Debian Elinks user, and occasionally contribute; Giridhar and Moritz Mühlenhoff should probably make the decisions, but here are my comments anyway. On Sun, Jul 31, 2011 at 08:04:47PM +0300, Kalle Olavi Niemitalo wrote: This sounds fair. This is primarily because the Debian packaging provided by upstreams is usually not compliant with the ideas and standards required or imposed by the Debian maintainers themselves. However, in case you are merely going to ship the currently up-to-date debian/ directory, I can see two ways where you can do so without hurting the Debian maintainers: - Just ship the debian/ directory and don't make changes to it, or make only those changes which the Debian maintainers would make anyway, and/or - Become a co-maintainer of the Debian package. If these aren't suitable to you (and the Debian maintainers), then an alternate solution would be necessary. I don't see why a merge would complicate things, although Moritz and Giridhar can comment furt</pre> Kumar Appaiah 2011-08-02T00:54:55 http://permalink.gmane.org/gmane.comp.web.links/3524 <pre>I vote for the deletion of contrib/debian and elinks.spec. Debian and others already have such files in their repos. The Arch's packagers might create the elinks.desktop themselves. </pre> witekfl 2011-08-01T09:11:38 http://permalink.gmane.org/gmane.comp.web.links/3523 <pre>As reported at &lt;http://bugzilla.elinks.cz/show_bug.cgi?id=1117&gt;, contrib/debian/elinks.desktop is in a pre-standard format that triggers a warning from the mimeo program. I could easily fix that in the upstream elinks sources; however, Debian already has an up-to-date elinks.desktop file that also includes translations to a few languages. To avoid needless forking, I'd like to copy that version to the elinks-0.12 branch and later merge to master. Then, to keep authorship information, I think I should also copy debian/changelog, and perhaps the rest of the debian directory. According to &lt;http://bugzilla.elinks.cz/show_bug.cgi?id=988&gt;, the Debian maintainer does not want us to have a debian/ directory in the ELinks sources, so the files would go in contrib/debian/. Does that seem reasonable to do? Also, should I make the commit a merge (from git://git.debian.org/git/collab-maint/elinks.git#debian/unstable), or would that just complicate later Debian maintenance? I suppose another solution would be to move</pre> Kalle Olavi Niemitalo 2011-07-31T17:04:47 http://permalink.gmane.org/gmane.comp.web.links/3522 <pre>Recently, I wanted to link to the documentation of -remote in the ELinks manual. That is currently at &lt;http://elinks.cz/documentation/html/manual.html-chunked/ch11.html&gt; but the chapter number may change as the manual is edited. To make such links more reliable in the future, I'd like to change the file names now to more descriptive ones: for example, this one could be remote.html. By changing the xmlto invocation in doc/Makefile to and then changing the beginning of doc/remote.txt to I get the remote.html file, as desired. Now then, the other files. Subsection 1.7 (Feature configuration file) comes from $builddir/doc/features.txt, which begins with: It appears that AsciiDoc 7.1.2 (bundled in elinks-0.12) does not allow "features.conf" as a BlockId; the section element in the generated manual.xml does not get any id attribute, and the file is consequently not called features.conf.html. The problem seems to be in doc/tools/asciidoc/asciidoc.conf, which does not allow dots in a bare ID: If I chang</pre> Kalle Olavi Niemitalo 2011-07-19T10:03:41 http://permalink.gmane.org/gmane.comp.web.links/3521 <pre>In master:src/util/string.{c,h}, there are various "*case*" functions and macros for case-insensitive string operations: * c_strcasecmp() uses c_tolower(). * c_strcasestr() uses c_strncasecmp(), thus c_tolower(). * c_strlcasecmp() uses elinks_strlcasecmp(...,, 1), thus c_toupper(). * c_strncasecmp() uses c_tolower(). * elinks_strlcasecmp() uses c_toupper() or toupper(), depending on the locale_indep parameter. * elinks_strlcasestr() uses c_strncasecmp(), thus c_tolower(). * strlcasecmp() uses elinks_strlcasecmp(..., 0), thus toupper(). * strlcasestr() uses elinks_strlcasestr(), thus c_toupper(). I think the name of strlcasestr() is misleading because it is locale-independent even though strlcasecmp() is locale-dependent. Should strlcasestr() be renamed to c_strlcasestr(), or should it be changed to use toupper()? The only function using strlcasestr() is match_cache_entry_contents(), which searches for a user-provided string (in the terminal charset) in a cache fragment (in the document charset). Becaus</pre> Kalle Olavi Niemitalo 2011-05-09T06:35:24 http://permalink.gmane.org/gmane.comp.web.links/3520 <pre>Don't search for SpiderMonkey in hardcoded directories (/usr /usr/local /opt/spidermonkey /opt/js), and don't support --with-spidermonkey=DIR (which I think was never documented). Instead, ask pkg-config for mozjs185 or mozilla-js. Everyone who installed SpiderMonkey in an unusual place must either set PKG_CONFIG_PATH appropriately or use --with-xulrunner-includes and --with-xulrunner-libs. This commit also includes a few minor changes in the SpiderMonkey section of the configure script: * Update the SpiderMonkey version number in "checking" messages from 1.5 RC3a to 1.8.5, which matches the actual checks. * Rename --with-xulrunner_includes to --with-xulrunner-includes, and --with-xulrunner_libs likewise. This only affects the --help output; the configure script accepts both spellings. * Wrap the option documentation with AS_HELP_STRING. * Use the Autoconf-generated $with_xulrunner_includes etc. variables directly, instead of copying $withval. * Quote the arguments of macros more consistently. * Wa</pre> Kalle Olavi Niemitalo 2011-04-30T22:49:51 http://permalink.gmane.org/gmane.comp.web.links/3519 <pre> Less consistent than I thought... my patch lost support for content="42, http://example.org/", which Iceweasel does support. I'll add more test cases and perhaps post a revised patch later. _______________________________________________ elinks-dev mailing list elinks-dev&lt; at &gt;linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev </pre> Kalle Olavi Niemitalo 2011-04-27T20:08:35 http://permalink.gmane.org/gmane.comp.web.links/3518 <pre>The URL in &lt;meta http-equiv="Refresh" content="42; URL=target.html"&gt; can now freely contain spaces and semicolons. There cannot be other parameters between the delay and the URL. If the URL is not quoted, then it spans to the end of the attribute, except not to trailing spaces. If the URL is quoted, then it ends at the first closing quotation mark. All this is consistent with Debian Iceweasel 3.5.16. --- src/document/html/Makefile | 4 +- src/document/html/parse-meta-refresh.c | 97 ++++++++++++ src/document/html/parse-meta-refresh.h | 21 +++ src/document/html/parser.c | 170 +++------------------- src/document/html/test/Makefile | 9 + src/document/html/test/parse-meta-refresh-test.c | 174 ++++++++++++++++++++++ src/document/html/test/test-parse-meta-refresh | 3 + 7 files changed, 325 insertions(+), 153 deletions(-) create mode 100644 src/document/html/parse-meta-refresh.c create mode 100644 src/docum</pre> Kalle Olavi Niemitalo 2011-04-27T16:03:46 http://permalink.gmane.org/gmane.comp.web.links/3517 <pre>---end quoted text--- Could this be changed to a for loop that checks for either mozjs185 or mozilla-js ? In Debian, mozjs is installed as part of iceweasel, ie. firefox, and that installs a mozilla-js.pc instead of mozjs185.pc </pre> أحمد المحمودي 2011-04-26T13:06:38 http://permalink.gmane.org/gmane.comp.web.links/3516 <pre>The --with-spidermonkey option no longer supports a DIR argument. AFAICT, that argument was never documented anyway. This commit also changes the SpiderMonkey version number in "checking" messages from 1.5 RC3a to 1.8.5, which matches the actual checks. --- Witek recently changed the master branch (ELinks 0.13.GIT) to require SpiderMonkey 1.8.5. The elinks-0.11 and elinks-0.12 branches do not support SpiderMonkey 1.8.5. I'd like to be able to build both branches, so I have installed SpiderMonkey 1.8.5 in my home directory: ~/prefix/x86_64-unknown-linux-gnu/lib/ and ~/prefix/include/js/. I had difficulty getting ELinks 0.13.GIT to use SpiderMonkey from those directories, however. Because SpiderMonkey 1.8.5 also installs mozjs185.pc, which refers to the correct directories, I'd like to make the configure script of ELinks 0.13.GIT use that. Then, only $PKG_CONFIG_PATH needs to be set. Please post if this patch would cause difficulty to you. I will probably be offline for a day or two. configure.in | </pre> Kalle Olavi Niemitalo 2011-04-23T08:58:26 http://permalink.gmane.org/gmane.comp.web.links/3515 <pre>Hello, There have been API changes in libmozjs, which make the build fail if I enable ECMAScript support. Attached is a patch that fixes the build failure. Anyways, elinks immediately seg faults after invocation. So I had to disable ECMAScript support. </pre> أحمد المحمودي 2011-04-09T21:35:13 http://permalink.gmane.org/gmane.comp.web.links/3514 <pre> CC. I applied both patches to master. Thank you! </pre> witekfl 2010-12-13T17:55:50 http://permalink.gmane.org/gmane.comp.web.links/3513 <pre>Target LD is different from ld when cross-compiling, change it together with CC. Signed-off-by: Sergey Kvachonok &lt;ravenexp&lt; at &gt;gmail.com&gt; --- Makefile.config.in | 1 + configure.in | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.config.in b/Makefile.config.in index c463868..69809d2 100644 --- a/Makefile.config.in +++ b/Makefile.config.in &lt; at &gt;&lt; at &gt; -54,6 +54,7 &lt; at &gt;&lt; at &gt; ASCIIDOC_FLAGS = --unsafe AWK = &lt; at &gt;AWK&lt; at &gt; CATALOGS = &lt; at &gt;CATALOGS&lt; at &gt; CC = &lt; at &gt;CC&lt; at &gt; +LD = &lt; at &gt;LD&lt; at &gt; GIT = &lt; at &gt;GIT&lt; at &gt; CONFDIR = &lt; at &gt;CONFDIR&lt; at &gt; DOXYGEN = &lt; at &gt;DOXYGEN&lt; at &gt; diff --git a/configure.in b/configure.in index b0f8968..feba1bf 100644 --- a/configure.in +++ b/configure.in &lt; at &gt;&lt; at &gt; -57,6 +57,7 &lt; at &gt;&lt; at &gt; echo "Feature summary:" &gt; features.log # =================================================================== AC_PROG_CC +AC_CHECK_TOOL([LD], [ld]) AC_PROG_AWK AC_PATH_PROGS(AWK, "$AWK") AC_PROG_RANLIB </pre> Sergey Kvachonok 2010-12-13T12:08:46 http://permalink.gmane.org/gmane.comp.web.links/3512 <pre>AC_CHECK_FILE runs target executable and dies when cross-compiling. It's unnecessary when checking for files in build environment, simple runtime check will do. Signed-off-by: Sergey Kvachonok &lt;ravenexp&lt; at &gt;gmail.com&gt; --- configure.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index feba1bf..6633cc8 100644 --- a/configure.in +++ b/configure.in &lt; at &gt;&lt; at &gt; -48,8 +48,8 &lt; at &gt;&lt; at &gt; fi # =================================================================== features="features.conf" -AC_CHECK_FILE("$srcdir/$features", [ . $srcdir/$features ]) -AC_CHECK_FILE("$builddir/$features", [ . $builddir/$features ]) +test -f "$srcdir/$features" &amp;&amp; . "$srcdir/$features" +test -f "$builddir/$features" &amp;&amp; . "$builddir/$features" echo "Feature summary:" &gt; features.log # =================================================================== </pre> Sergey Kvachonok 2010-12-13T12:08:47 http://permalink.gmane.org/gmane.comp.web.links/3511 <pre>Hello all, This announcement is sent to this mailing list because yout project uses Git as a version control system. We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. The results will be published to the Git wiki on the GitSurvey2010 page (https://git.wiki.kernel.org/index.php/GitSurvey2010) and discussed on the git mailing list (git&lt; at &gt;vger.kernel.org). The survey would be open from 1 September till 15 October 2010. Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like of it. The survey can be found here: http://tinyurl.com/GitSurvey2010 https://www.survs.com/survey/MUPYR8UJ4B Git User's Survey 2010 was originally announced on git mailing list in the following mail: http://article.gmane.org/gmane.comp.version-control.git/154986 </pre> Jakub Narebski 2010-09-29T23:20:21 http://permalink.gmane.org/gmane.comp.web.links/3510 <pre>[..] Thanks, I've fixed it. I compile with --enable-debug, so I don't know why I didn't get errors from GCC. Best regards, </pre> Miciah Dashiel Butler Masters 2010-09-16T20:59:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.links