"M. Levinson" <[EMAIL PROTECTED]> writes: > 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.
That is fine for getting information about the current status of ELinks. However, 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. What would it do if called from outside the hook? On the other hand, perhaps there is no reason to tell the hook how ELinks will open the result; perhaps there should even be an elinks.set_target function for the hook; 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.
pgplBfEl6FaP7.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
