[elinks-dev] Remove current_url parameter of Python goto_url_hook?

M. Levinson levinsm at users.sourceforge.net
Sat Jan 6 04:30:32 PST 2007


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://lists.linuxfromscratch.org/pipermail/elinks-dev/attachments/20070106/1f393a74/attachment.bin>


More information about the elinks-dev mailing list