Re: [elinks-dev] One thousand eight hundred doollars...
Sorry about this one. I am experimenting with putting up a proper spam filter so the list once again can be open for everyone to post without subscription and with minimal moderation. It's a work in progress ... -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] One thousand eight hundred doollars...
On Mon, Sep 22, 2008 at 14:45, Klaus Knopper [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 10:52:21AM +0200, Jonas Fonseca wrote: Sorry about this one. I am experimenting with putting up a proper spam filter so the list once again can be open for everyone to post without subscription and with minimal moderation. It's a work in progress ... Once you have found a successful way to do right that, please let me know how this miracle works. :-) Heh, well, right now it is not going very well, since my previous mail got caught in the filter. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Errors in bittorent
Some comments ...
Witold Filipczyk [EMAIL PROTECTED] wrote Sat, Aug 30, 2008:
commit b589f19b73c65621c0a8582199509f58dbcac09f
Author: Witold Filipczyk [EMAIL PROTECTED]
AuthorDate: Sat Aug 30 10:52:00 2008 +0200
Commit: Witold Filipczyk [EMAIL PROTECTED]
CommitDate: Sat Aug 30 10:52:00 2008 +0200
An issue with bittorrent.
It was possible that the reference to the automatic variable
uri of the make_bittorrent_peer_connection trashed the stack.
In addition done_uri crashed because uri-string was NULL.
Now uri is allocated and unlocked to avoid memleak.
diff --git a/src/protocol/bittorrent/peerconnect.c
b/src/protocol/bittorrent/peerconnect.c
index aeafbf3..5f65e68 100644
--- a/src/protocol/bittorrent/peerconnect.c
+++ b/src/protocol/bittorrent/peerconnect.c
@@ -20,6 +20,7 @@
#include elinks.h
#include config/options.h
+#include main/object.h
#include main/select.h
#include main/timer.h
#include network/connection.h
@@ -271,9 +272,12 @@ enum bittorrent_state
make_bittorrent_peer_connection(struct bittorrent_connection *bittorrent,
struct bittorrent_peer *peer_info)
{
- struct uri uri;
+ struct string uri_string;
+ struct uri *uri;
struct bittorrent_peer_connection *peer;
- unsigned char port[5];
+ unsigned char port[6];
+ int ip_start, port_start;
+ int port_length;
peer = init_bittorrent_peer_connection(-1);
if (!peer) return BITTORRENT_STATE_OUT_OF_MEM;
@@ -296,14 +300,32 @@ make_bittorrent_peer_connection(struct
bittorrent_connection *bittorrent,
/* FIXME: Rather change the make_connection() interface. This is an ugly
* hack. */
/* FIXME: Set the ipv6 flag iff ... */
- memset(uri, 0, sizeof(uri));
- uri.protocol = PROTOCOL_BITTORRENT;
- uri.host = peer_info-ip;
- uri.hostlen = strlen(peer_info-ip);
- uri.port = port;
- uri.portlen = snprintf(port, sizeof(port), %u, peer_info-port);
-
- make_connection(peer-socket, uri, send_bittorrent_peer_handshake, 1);
+ if (!init_string(uri_string)) {
+ done_bittorrent_peer_connection(peer);
+ return BITTORRENT_STATE_OUT_OF_MEM;
+ }
+ add_to_string(uri_string, bittorrent:);
+ ip_start = uri_string.length;
+ add_to_string(uri_string, peer_info-ip);
+ add_char_to_string(uri_string, ':');
+ port_start = uri_string.length;
+
+ port_length = snprintf(port, sizeof(port), %u, peer_info-port);
+ add_bytes_to_string(uri_string, port, port_length);
+ uri = get_uri(uri_string.source, URI_BASE);
+ done_string(uri_string);
+ if (!uri) {
+ done_bittorrent_peer_connection(peer);
+ return BITTORRENT_STATE_OUT_OF_MEM;
+ }
+
+ uri-host = uri-string + ip_start;
+ uri-hostlen = port_start - ip_start - 1;
+ uri-port = uri-string + port_start;
+ uri-portlen = port_length;
+ /* Do not lock it. */
+ object_unlock(uri);
+ make_connection(peer-socket, uri, send_bittorrent_peer_handshake, 1);
return BITTORRENT_STATE_OK;
}
Instead of fixing this hack, why don't you add a setup_connection() that
make_connection() can use as a wrapper and be done with this. Or if this
is bittorrent URI thing actually works, why do you mess with the URI struct
yourself? Didn't parse_uri() do all that for you already? Also don't
unluck the URI, call done_uri(uri) after the call to make_connection().
Else your checking of add_..._string() calls is a bit sloppy.
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Monthly snapshots
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Fri, Jun 20, 2008: Witold Filipczyk [EMAIL PROTECTED] writes: Me and probably not only me want to package the ELinks-0.12 or even 0.13. If you do not want to release often, create at least monthly (or quoterly) snapshots, eg. elinks-0.13-080630.tar.bz2 and save them on the download site. Mark them as experimental. Sounds good if somebody else is interested in starting the release process of 0.12 and master. As I have said before my ELinks time is very limited these days and mostly goes into mailing list moderation. I don't know if it would make sense to start migrating to use Google Code for hosting the downloads. I have used it for a few projects and it is quite flexible and easy to use. I think this might be preferable compared to the current download hosting that is quite complicated. Anyway, I've created a project at http://elinks.googlecode.com/ and can delete it if you think it is the wrong way to go. I think it is time to release ELinks 0.12pre1 and 0.11.4. All the bugs targeted for 0.12-M1 have been fixed in the elinks-0.12 branch. I will start preparing the release of 0.11.4 in the next few days. In master AKA 0.13.GIT, the current fix of bug 765 can easily cause a crash. I think that should be fixed before any release From that branch. 0.12 and master seem to have already diverged quite a bit: 180 files changed, 4400 insertions(+), 2229 deletions(-) just for src/. Any thoughts about this? In my opinion, this has always (at least once the number of committers grew) been ELinks' problem. The gab between stable/unstable are very big, which makes making new releases and upgrading very painful. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Force protocol.http.compression = 1 again?
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Sun, Feb 24, 2008: Commit d4cec950ecadb0c19206f28b0bf9c6d8992bc1e7 added to src/protocol/http/http.c: #if !(defined(CONFIG_GZIP) || defined(CONFIG_BZIP2)) #define COMP_NOTE \nNote that this ELinks version has been compiled without compression\n \ support anyway. This option will have no effect.\n #else #define COMP_NOTE #endif INIT_OPT_BOOL(protocol.http, N_(Enable on-the-fly compression (experimental)), compression, 0, 1, N_(If enabled, the capability to receive compressed content (gzip and/or\n bzip2) is announced to the server, which usually sends the reply\n compressed, thus saving some bandwidth at slight CPU expense.\n HOWEVER, please note that the ELinks implementation is unfortunately very\n buggy and you may see incomplete pages, pages with garbage instead of\n content, etc.! COMP_NOTE)), Wouldn't it have been easier to just leave out the option completely? Anyway, instead of putting the both versions of the whole string inside #if, I'd like to revert this commit altogether. With Witek's latest changes, compression is not so experimental any more, I think. Can you find any site where it still fails? I haven't tested it personally, but I think it is the right thing to do. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] parse_bencoding_integer does not detect all overflows
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Sat, Jan 26, 2008:
So if the overflow check is necessary, it should be corrected.
If overflows can be assumed to wrap (C does not guarantee that),
then I think the following is correct and the simplest solution:
for (; pos length isdigit(string[pos]); pos++) {
off_t newint = integer * 10 + string[pos] - '0';
if (newint / 10 != integer)
return 0; /* overflow */
integer = newint;
}
OTOH, if overflows instead trap or saturate, then this won't work.
I think the dectection is necessary and I like your correction.
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Bug 744: More tests and fix failures.
Witold Filipczyk [EMAIL PROTECTED] wrote Wed, Aug 29, 2007: Hi! Allo, While browsing diveintopython-5.4 I found a bug in recent ELinks-0.12.GIT. $ cd /usr/share/doc/diveintopython-5.4/html/toc $ elinks index.html Follow the link: 1. Installing Python and you'll get the No such file or directory error. The link starts with ../. I see you fixed it in your own tree. Yesterday, I reverted the change removing the substitution of // into /, so that it is now limited only to file URIs. The great thing is that local directory browsing now looks more sane. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Sponsor development of the key motion.
Ligesh [EMAIL PROTECTED] wrote Fri, Aug 10, 2007:
Hi,
I had requested a specific 2 dimensional keyboard motion some time back. It
was like this: the up/down arrows will move straight up and down, and will
stop on a line that contains a link anywhere on that line. The up/down arrows
will not move right/left at all. They will just stop on a line which contains
the link anywhere, even if the exact location of the cursor does not have a
link.
This should be something like the move-cursor-* actions, right?
Try putting this in your elinks.conf and test:
bind main up = move-cursor-up
bind main down = move-cursor-down
The right-left would of course move along the links on a single line. The
right-left would also wrap-around, so that after the farthest right link, the
right button will wrap to the left most link on the left line. But up/down
moves only straight.
bind main right = move-link-right
bind main left = move-link-left
Almost does what, I think, you want. Unfortunately, it jumps to
a random link sometimes. I've never used this feature and the
code is a bit hairy.
I would like to know if I can sponsor this feature.
Maybe you could test the patch below, which makes the horizontal
navigation kind-of work when browsing local directories and could
serve as a start.
diff --git a/src/viewer/text/link.c b/src/viewer/text/link.c
index 175a0ff..715e690 100644
--- a/src/viewer/text/link.c
+++ b/src/viewer/text/link.c
@@ -615,14 +615,17 @@ next_link_in_dir(struct document_view *doc_view, int
dir_x, int dir_y)
vs = doc_view-vs;
link = get_current_link(doc_view);
- if (!link) return 0;
+ if (link) {
+ /* Find the link's bounding box coordinates. */
- /* Find the link's bounding box coordinates. */
+ get_link_x_bounds(link, -1, min_x, max_x);
- get_link_x_bounds(link, -1, min_x, max_x);
-
- min_y = link-points[0].y;
- max_y = link-points[link-npoints - 1].y;
+ min_y = link-points[0].y;
+ max_y = link-points[link-npoints - 1].y;
+ } else {
+ min_x = max_x = doc_view-session-tab-x - doc_view-box.x;
+ min_y = max_y = doc_view-session-tab-y - doc_view-box.y;
+ }
/* Now go from the bounding box edge in the appropriate
* direction and find the nearest link. */
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] disable mouse (was: Sponsor development of the key motion.)
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Fri, Aug 10, 2007: Ligesh [EMAIL PROTECTED] writes: Also I want to know if I can disable the need to press shift key while copy/pasting from/to elinks. It appears the toggle-mouse action (not bound to a key by default) would stop ELinks from requesting mouse events. Or configure ELinks not to support mouse input with --disable-mouse. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] How to compile ELinks for Win32?
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Fri, Jun 08, 2007: src/osdep/win32/ was last updated in ELinks 0.12.GIT on 2006-07-02. From the commit messages, I get the impression that the Win32 port is supposed to compile and link correctly and even work partially. However, the build system of ELinks heavily depends on GNU Make and POSIX utilities, and I believe these are not generally available on Microsoft Windows. Can ELinks be built on Windows in its current condition, or must it be cross-compiled? Which compiler and tools should be used? The last time I worked and tested this I used MSYS / MingW, which comes with gmake and shell utilities to run the configure script. I haven't tried since. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Downloading 3.5 GB ISO
John Boero [EMAIL PROTECTED] wrote Wed, Jun 06, 2007:
Hi. I distribute sabayon isos through my shared hosting account. It's
quickest for me to ssh into the host and download from my source
directly (thanks to links). This time I noticed quirky estimates on my
larger files. It looks like there's a signed int for tracking bytes
received.
Could you tell us about what version of ELinks you are using?
Could this be fixed by making it a long?
The off_t type should be used for this kind of thing; it seems Witold
already made such preparations.
No big deal, just thought I'd make it known.
Thank you for reporting this.
... and now some comments to the patch
From 6e43bca585238183c6a3f04695b48b755b1b52b6 Mon Sep 17 00:00:00 2001
From: Witold Filipczyk [EMAIL PROTECTED]
Date: Thu, 7 Jun 2007 16:16:53 +0200
Subject: [PATCH] http: used off_t instead of int.
The progress of files bigger than 2GB is shown properly.
---
src/protocol/http/http.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/protocol/http/http.c b/src/protocol/http/http.c
index 62f7c3f..71086c3 100644
--- a/src/protocol/http/http.c
+++ b/src/protocol/http/http.c
@@ -74,13 +74,13 @@ struct http_connection_info {
#define LEN_CHUNKED -2 /* == we get data in unknown number of chunks */
#define LEN_FINISHED 0
- int length;
+ off_t length;
/* Either bytes coming in this chunk yet or parser state. */
#define CHUNK_DATA_END -3
#define CHUNK_ZERO_SIZE -2
#define CHUNK_SIZE -1
- int chunk_remaining;
+ off_t chunk_remaining;
This change should have some consequences for decompress_data calling
also I think. At least we need to check for overflows before trunkating
and assigning the value of this to the len parameter passed to
decompress_data. The code in question:
...
int len;
int zero = (http-chunk_remaining == CHUNK_ZERO_SIZE);
if (zero) http-chunk_remaining = 0;
len = http-chunk_remaining;
/* Maybe everything necessary didn't come yet.. */
int_upper_bound(len, rb-length);
conn-received += len;
data = decompress_data(conn, rb-data, len, data_len);
...
I am not sure if this should also be updated to use strtoll:
unsigned char *de;
int n = 0;
if (l != -1) {
errno = 0;
n = strtol(rb-data, (char **) de, 16);
if (errno || !*de) {
return -1;
}
}
if (l == -1 || de == rb-data) {
return -1;
}
/* Remove everything to the EOLN. */
kill_buffer_data(rb, l);
http-chunk_remaining = n;
... or whether chunk_remaining should even be off_t, but it clearly
results in fewer changes needed to decompress_data.
The problem with potential overflows should also be investigated with
respect the http_connection_info-length member. The only code where
this could be a problem seems to be this. Since the check already
ensures that http-length is smaller than an already known-good value,
it should be OK, I think:
read_normal_http_data(struct connection *conn, struct read_buffer *rb)
{
struct http_connection_info *http = conn-info;
unsigned char *data;
int data_len;
int len = rb-length;
if (http-length = 0 http-length len) {
/* We won't read more than we have to go. */
len = http-length;
}
int code;
};
@@ -1007,7 +1007,7 @@ decompress_data(struct connection *conn, unsigned char
*data, int len,
* early otherwise)). */
enum { NORMAL, FINISHING } state = NORMAL;
int did_read = 0;
- int *length_of_block;
+ off_t *length_of_block;
unsigned char *output = NULL;
length_of_block = (http-length == LEN_CHUNKED ?
http-chunk_remaining
@@ -1761,10 +1761,10 @@ again:
d = parse_header(conn-cached-head, Content-Length, NULL);
if (d) {
unsigned char *ep;
- int l;
+ off_t l;
errno = 0;
- l = strtol(d, (char **) ep, 10);
+ l = strtoll(d, (char **) ep, 10);
if (!errno !*ep l = 0) {
if (!http-close || POST_HTTP_1_0(version))
--
1.5.2.1.851.g432c-dirty
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
John Hawkinson [EMAIL PROTECTED] wrote Sat, Jun 02, 2007:
Hi, I'm not the list. Here are some fixes to build under Solaris 10
(no -rdynamic, no gzclearerr()). Against elinks-0.12-20070601.
Also included is a patch to add more help for -dump-color-mode.
[EMAIL PROTECTED]
John Hawkinson
--- configure.in 2007/06/01 19:18:56 1.1
+++ configure.in 2007/06/02 22:21:07
@@ -256,10 +256,21 @@
dnl
dnl FIXME: This check doesn't work. Something to do with the compiler
dnl happily ignoring it and stderr not being checked for error messages.
+dnl This works instead:
AC_MSG_CHECKING([for -rdynamic])
LDFLAGS_X=$LDFLAGS
LDFLAGS=$LDFLAGS -rdynamic
-AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
+cat conftest.$ac_ext _ACEOF
+int main() { return 0; }
+_ACEOF
+(eval $ac_compile) 2conftest.er1
+(eval $ac_link) 2conftest.err
+if test -s conftest.err
+then
+ have_rdynamic=no
+else
+ have_rdynamic=yes
+fi
test $have_rdynamic = no LDFLAGS=$LDFLAGS_X
AC_MSG_RESULT($have_rdynamic)
Wow, this is really great. A lot of people has mentioned this over the
years and so finally being able to provide a fix is very helpful.
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] increased risk of ECMAScript crashes in ELinks 0.11.3.GIT
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Wed, May 30, 2007: Jonas Fonseca [EMAIL PROTECTED] writes: Ok, thanks for the warning, however, I thought that I expressed that I do not really consider ECMAScript related crashes as something to worry about for the current stable version. 2007-05-27: paakku fonseca: Should bug 755 be fixed in 0.11.3.GIT or 0.11.4.GIT? fonseca paakku: I don't really care about ECMAScript bugs. Crashes caused by dangling pointers may be exploitable (unlike crashes caused by null pointers). I think they should be fixed regardless of whether they occur in ECMAScript support or elsewhere in ELinks. And I especially don't want to become responsible of making a release crash more than the previous one. Fair enough. I guess my reason for not caring stems from the feeling of ECMAScript being pushed too soon before it was even half decent. Perhaps those days are over. ;) I will try to find time to release 0.11.4 in the start of June. I don't think I'll be able to fix things properly before that, so I have now reverted the two commits from elinks-0.11. Ok, cool. Will try to find time to do the preparations for .4 -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] increased risk of ECMAScript crashes in ELinks 0.11.3.GIT
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Tue, May 29, 2007: Fonseca, if you release ELinks 0.11.4 soon, please revert these commits first: 644908c130210ed7b17a3bd1241244576b94c546 Garbage-collect SMJS objects before flushing caches. 5a49b9f14d4b8bb30bfada4958c22e6a8cfab21e NEWS: mention bug 951 The extra garbage collections increase the risk of crashing because of dangling pointers in form_state.ecmascript_obj. This bug has been fixed in commit b4d9b7f5a60a64a26fcfffcb66a376cae5b31bc1 in ELinks 0.12.GIT. I am going to add the bug to bugzilla.elinks.cz (it is not the same as bug 755, which is about pointers _to_ struct form_state) and then backport that commit to 0.11.3.GIT (or 0.11.4.GIT). The fix in 0.12.GIT is not entirely correct (it breaks object identity comparisons) but fixing the bug properly will take some time and I think it is more important now to remove the risk of crashing. Ok, thanks for the warning, however, I thought that I expressed that I do not really consider ECMAScript related crashes as something to worry about for the current stable version. I will try to find time to release 0.11.4 in the start of June. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Navigating
Yan Seiner [EMAIL PROTECTED] wrote Wed, May 02, 2007:
I'm trying to make elinks into a front end for our embedded panel. So
far, I've figured out how to manipulate the form and users can enter and
modify the information on the forms with our interface.
I'm having a bit of an issue with navigation, though.
Question 1:
The form fields are labeled and contain attributes with nav info, eg
INPUT type='text' class='float' id='F_2' idindex='22' tabindex='14'
WRAP='true' NUMTYPE='bearing' VALUE='125' SIZE='4' NAME='F_2'
right='T_2' left='' up='F_1' down='F_3'
So on down arrow I need to navigate to the INPUT field with ID of
'F_3'. I've modified the parser code to extract the attributes I need,
but I can't figure out the navigation
How do I navigate 'by force'? Somehow I need to be able to extract the
information from the INPUT element and use it to navigate. I've tried
next_link_in_dir from within the forms editor but it seems to have no
effect
What function or combination of functions should I be looking at to:
exit edit mode
navigate to a given field in the form
I think it will be enough to search the document-links for the form and then
jump to the link. Maybe you need to escape the edit/insert mode yourself.
struct document *document = doc_view-document;
int link;
for (link = 0; link document-nlinks; link++) {
struct form_control *fc =
get_link_form_control(document-links[link]);
if (fc fc-form == form
CHECK FOR FORM ID) {
jump_to_link_number(ses, doc_view, link);
return;
}
}
Question 2:
I need to implement shortcuts so that when a user hits a button, s/he is
taken to a new page. Right now I have F1 mapped to HomeURL, F2 to
'back, and F5 to HelpURL. How do I tie these keys to URLs?
Using building keybindings / actions. This requires adding something to
src/config/action-*.inc and src/viewer/action.c. Maybe try to look for
the patch of a new action that was added in the past.
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] How do I tell the document has changed?
Yan Seiner [EMAIL PROTECTED] wrote Mon, Apr 30, 2007: Is there something that is guaranteed to change on load/reload that I can check for quickly? Perhaps something like document_view-name? A struct document contains a field called id' which is basically a counter controlled by the cache system and which is changed--for the same URL--on reload and unique across different URLs. Maybe it can be used. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Revert Python goto_url_hook change before 0.11.3?
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Thu, Apr 05, 2007: I'd like to revert this commit from ELinks 0.11.2.GIT before 0.11.3 is released: commit 8bedf25bf84d60b143b16d0fe1b384dc17c93569 tree 4b752e88247d9722399bab58d08d748f215388ea parent e1ae6a0cdf12f05a0f642f70de02c513c69648e5 author witekfl [EMAIL PROTECTED](none) Sun, 29 Jan 2006 14:58:03 +0100 committer Jonas Fonseca [EMAIL PROTECTED] Mon, 27 Nov 2006 17:13:02 +0100 * contrib/python/hooks.py, src/scripting/python/hooks.c: goto_url_hook takes 2 params not 1. Some dumbprefixes defined in hooks.py ... So we have three different calling conventions here. I think it will be less confusing to users if we drop the middle one and make the rest of the stable 0.11 branch call the hook in the same way as 0.11.2 did. The difference would then be only between the 0.11 and 0.12 branches. Objections? Sound like a good idea! -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] BRF charset support
Samuel Thibault [EMAIL PROTECTED] wrote Tue, Dec 12, 2006: Kalle Olavi Niemitalo, le Tue 12 Dec 2006 09:53:18 +0200, a écrit : This elinks-dev mailing list is for the ELinks variant. I don't know whether the developers of the original Links read this list. Ah. So I don't know how to report bugs to Links people :) You can try to either send to one of the developers (see addresses at http://links.twibright.com/development.php) or to the the Links mailing which has the address [EMAIL PROTECTED] ... -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] use native libintl/gettext?
Hello Jeremy, Jeremy C. Reed [EMAIL PROTECTED] wrote Thu, Dec 07, 2006: I am a long time elinks user. It is my browser of choice. Thank you for your great work! Thanks for your feedback. Always encouraging! Is there any way to have it use the system's native gettext libraries instead of building and using the src/intl included with the source? Not at the moment, and it is certainly not planned. Gettext has been changed to integrate better with ELinks: it uses the ELinks memory functions, has some specific wrappers etc. There is a bugzilla entry which is currently marked WONTFIX. Pasky's last remarks are: Our instance of libgettext is *heavily* customized and it is expected to get even more customized by the time, so using system gettext routines is not really feasible. - http://bugzilla.elinks.or.cz/show_bug.cgi?id=537 Any patches to check for adequate gettext and use it if available? I do not know of such patches. If not, would you be interested if used commonly-used autoconf to check this? Patches are always welcome, but I do not really see a reason. Is gettext really that big? (I also found that the Makefile system used in buildling elinks is different than I am used to when using autoconf configure.) Yes, we changed to using a GNU make based build system instead of automake, since ELinks has a lot of build-time options that caused automake to generate huge makefiles because conditional are badly implemented. Sad, but having a Makefile taking several megabytes of storage is crazy. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] elinks: FTBFS on GNU/kFreeBSD
Petr Salinger [EMAIL PROTECTED] wrote Wed, Nov 29, 2006: Package: elinks Severity: important Version: 0.11.1-1.2 Tags: patch Hi, Hello, the current version fails to build on GNU/kFreeBSD. It have to include sys/types.h before using off_t, see bellow. Thanks in advance I've merged the fix[1] from elinks-0.12 into the elinks-0.11 git tree. Hopefully I will have time to release a follow up soon with this and other fixes from the development tree. [1] http://repo.or.cz/w/elinks.git?a=commit;h=135a79a3c309af36cf963f1d3c34b07f296fa2f7 -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Re: [patch] additional functionality for Python backend
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Thu, Sep 21, 2006: Jonas Fonseca [EMAIL PROTECTED] writes: The event system was introduced for keybindings, when work was being done to support loadable module, especially scripting modules. I see, the event system was first added to CVS in commit 2b72492bf294c6fc442a06e6eca94fef0154db34 and soon used for keybindings in commit a4cf28a90691f46b34a2eea581755edcba119bab. Anyway, it looks like registering events with generated names can gradually allocate more and more memory, because unregister_event() is declared but not called nor implemented. Should I file a bug report (RESOLVED LATER) on that or add FIXME comments? Yes, this should probably be fixed. Creating a bug might make it more visible, so if you think it is that important this would probably be the best way. Was unloading a scripting module intended to immediately free all language-specific objects from memory and change ELinks-side structures to no longer point to them, or was there going to be a check so that modules cannot be unloaded when their objects are in use? I don't know but having the event layer was one way to remove the need for referencing them from ELinks-side structures. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Re: UTF-8 decoding changes for handle_interlink_event
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Sun, Aug 27, 2006: Jonas Fonseca [EMAIL PROTECTED] writes: - You indented the goto label in the first commit (e333fb37) and normally labels should not be indented. Oops. I see that's in doc/hacking.txt too. I guess I'll have to configure Emacs to use a custom indentation style for ELinks code. It's not a big deal. It would be better not to use goto at all. ;) - I don't seem to remember the introduction of is_utf16_surrogate() used in the second commit (be7526d0). Did you forgot to add intl/charset.h to the file commit list? I added is_utf16_surrogate in commit 38fe5b72 aka be7526d0~2, Define and use macros for handling UTF-16 surrogates. I typically commit a whole tree, rather than individual files. Ok, sorry for the noise then. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Mouse support?
juman [EMAIL PROTECTED] wrote Tue, Feb 28, 2006: I am a frequent user of elinks and one thing I really like and would like to know a bit more about is the mouse support. I use a pure Linux console through SSH using the Windoze software putty. Running Elinks I can still click on the links on a page to access them even though I am running it all through putty. Could someone point me to where in the sourcecode such events are handled or any information on the net that explains how to do such a thing? I am writing a little GUI and would like to include similair features... The lowlevel mouse driver code is mainly in src/osdep/unix.c (GPM on linux) and src/osdep/bsd.c (sysmouse on BSD). On top of that is src/terminal/mouse.* which is used by src/terminal/kbd.c to generate events through src/terminal/event.*. Search for CONFIG_MOUSE in src/viewer/text or src/bfu to get an idea of how the mouse events are done. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Re: patch: generate *.gmo files to the source directory
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote Tue, Dec 06, 2005: Jonas Fonseca [EMAIL PROTECTED] writes: However, after running cg-export we run ./autogen.sh, ./configure and for the HEAD branch 'make -C po' so that people without the autotools and gettext tools installed can use the tarballs. I am surprised you tar up an already configured tree, as INSTALL tells the user to run ./configure. Well, that is mostly in order to populate doc/ with some nice HTML docs. Anyway, po/*.gmo wouldn't be the only generated files in the source tree. Specifically, autogen.sh places several files there: acinclude.m4, aclocal.m4, config.h.in, and configure. If storing po/*.gmo in the source tree would cause you trouble, how do you cope with these? They are kind of different, IMO, since those generated files can be shared across several builds, no? po/*.gmo can also be shared across builds, if po/*.po are the same in each build. If the po/*.gmo files depended on the user's compilation environment or configuration options, there'd be no point in adding them in elinks-*.tar.gz. (IIRC, there are big-endian and little-endian variants of the GNU MO format, but the GNU Gettext library can recognize and convert them on the fly.) You obviously feel very strong about this, and I don't really, although I really like the idea of putting 'compiled' stuff in the build dir. Also I think it makes sense to have all generated by ./autogen.sh in the source dir (the bootstrapping) and everything else (generated by ./configure and make) in the build dir. Does it really make that big a difference? -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] first start with filename
Peter Gervai [EMAIL PROTECTED] wrote Mon, May 23, 2005: Minor cosmetic problem: If elinks is started the first time with a filename argument, it displays the file correctly but displays help popup (correct) and goto url popup (incorrect). I've fixed this in both the 0.11 and 0.10 cvs trees. I probably won't get to release 0.10.6 before a month from now, so in case the fix is needed elsewhere the patch is here: http://cvsweb.elinks.or.cz/cvsweb.cgi/elinks/src/sched/session.c.diff?r1=1.593.2.7r2=1.593.2.8f=u -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] javascript - noscript tag, missing functions, etc
Aaron Holmgren [EMAIL PROTECTED] wrote Mon, May 23, 2005: I know Javascript isn't expected to work very well. I just thought I'd mention some things, just in case they are useful to think about. Thanks for the input. Currently, I think Pasky is the only one who really understands how ELinks' Javascript handling works and more importantly how to interact with the SpiderMonkey engine. I don't know if he will have energy anytime soon (between exams and Cogito maintaining) to work on JavaScript. elinks seems to be displaying the content within [noscript] tags. It looks like Witold fixed this, so that noscript tags are skipped. Also, the main function that submits a form to check if your browser supports javascript on the main hotmail.com website (I don't use hotmail) doesn't do anything. I also wanted to note that this function works fine with the links2 web browser. Well, the links2 and elinks JavaScript handling is two totally different things, so that is not so strange. -- Jonas Fonseca ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
