Make elinks realy scriptable.

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 in the code. Omg ! the functions described in the documentation are the only existing
ones ! There is no way to get the document, no way to select a link, no way to jump to a link… This is what you
call a browser « highly customizable and can be extended via Lua or Guile scripts » ? Don't give me that
jazz !

So, as it seems that anything as to be done, let's think about what I expect from a true scriptable browser :

Control the browser and the navigation :

     * To be allowed to open a tab, close one
     * Set the current url, refresh the page
     * To be informed when the user select a link

Control the display :

libRUIN: unify XUL, DOM, CSS, guile-scripting

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
  * Many complex XHTML documents, such as the ones in the W3C CSS2.1
    Test Suite, including ones that involve automatic table layout, can
    be rendered
  * User input is handled correctly and default handlers for several
    inputs (such as the TAB key to switch focus) are working
  * API documentation is in place, in the form of a UNIX man page and a
    Texinfo manual; it is not, however, complete

Importing more recent debian/ to elinks.git

As reported at <http://bugzilla.elinks.cz/show_bug.cgi?id=1117>,
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 <http://bugzilla.elinks.cz/show_bug.cgi?id=988>, 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 elinks.desktop out of
contrib/debian/ and update AUTHORS accordingly.  It does look a
bit odd that the Arch Linux build script reads a file from a
Debian-specific directory.

_______________________________________________
elinks-dev mailing list
elinks-dev <at> linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

file names in elinks/doc/manual.html-chunked/

Recently, I wanted to link to the documentation of -remote in the
ELinks manual.  That is currently at
<http://elinks.cz/documentation/html/manual.html-chunked/ch11.html>
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

> %.html-chunked: %.xml
> 	$(call cmd,xmlto,--stringparam use.id.as.filename=1 html)

and then changing the beginning of doc/remote.txt to

> [[remote]]
> Managing remote ELinks instances
> --------------------------------

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:

> [[features.conf]]
> Feature configuration file (`features.conf`)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

strlcasestr uses c_toupper; rename to c_strlcasestr?

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).  Because the charsets
do not always match, and usually at least one of them is multibyte,
just calling toupper() would not do the right thing.

_______________________________________________
elinks-dev mailing list
elinks-dev <at> linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[0.12 PATCH] HTML: Rewrite parsing of meta refresh

The URL in <meta http-equiv="Refresh" content="42; URL=target.html">
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/document/html/parse-meta-refresh.h
 create mode 100644 src/document/html/test/Makefile
 create mode 100644 src/document/html/test/parse-meta-refresh-test.c
 create mode 100755 src/document/html/test/test-parse-meta-refresh

diff --git a/src/document/html/Makefile b/src/document/html/Makefile
index 5f7510b..91e7e08 100644
--- a/src/document/html/Makefile
+++ b/src/document/html/Makefile
@@ -1,7 +1,7 @@
 top_builddir=../../..
 include $(top_builddir)/Makefile.config

-SUBDIRS = parser

[0.13 PATCH] JS: Use pkg-config mozjs185, not hardcoded directories

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 |   90 ++++++++++++++++++++++++++++-----------------------------
 1 files changed, 44 insertions(+), 46 deletions(-)

diff --git a/configure.in b/configure.in
index 6055a0e..72be7f8 100644
--- a/configure.in
+++ b/configure.in
@@ -632,26 +632,25 @@ AC_ARG_WITH(xulrunner_libs, [  --with-xulrunner_libs=OPTIONS

API changes in libmozjs

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.

--

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7

_______________________________________________
elinks-dev mailing list
elinks-dev <at> linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[PATCH 1/2] Use autoconf to detect LD reliably.

Target LD is different from ld when cross-compiling, change it together with CC.

Signed-off-by: Sergey Kvachonok <ravenexp <at> gmail.com>
---
 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
@@ -54,6 +54,7 @@ ASCIIDOC_FLAGS = --unsafe
 AWK = @AWK@
 CATALOGS = @CATALOGS@
 CC = @CC@
+LD = @LD@
 GIT = @GIT@
 CONFDIR = @CONFDIR@
 DOXYGEN = @DOXYGEN@
diff --git a/configure.in b/configure.in
index b0f8968..feba1bf 100644
--- a/configure.in
+++ b/configure.in
@@ -57,6 +57,7 @@ echo "Feature summary:" > features.log
 # ===================================================================

 AC_PROG_CC
+AC_CHECK_TOOL([LD], [ld])
 AC_PROG_AWK

[ANNOUNCE] Git User's Survey 2010 is now up!

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 <at> 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

--

-- 
Jakub Narebski
on behalf of

[PATCH] Unbreak build with --enable-debug.

b53e8450d1f2bec84bf9354eaaa09dcb244c1edf broke the build with
--enable-debug because of unused variables. This should fix it.

Simon
---
 src/viewer/text/search.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/src/viewer/text/search.c b/src/viewer/text/search.c
index 224601c..b09609f 100644
--- a/src/viewer/text/search.c
+++ b/src/viewer/text/search.c
@@ -1266,9 +1266,6 @@ search_link_text(struct document *document, int current_link, int i,
 static inline void
 fixup_typeahead_match(struct session *ses, struct document_view *doc_view)
 {
-	int current_link = doc_view->vs->current_link;
-	struct link *link = &doc_view->document->links[current_link];
-
 	/* We adjust the box_size to account for the typeahead input line
 	 * (we don't want the input line to cover the current link). */
 	doc_view->box.height -= 1;
-- 
1.7.2.3

--

-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9