David Kettler <[EMAIL PROTECTED]> writes: > G'day John, > >> It is now possible to accomplish what you want as follows > > Thanks, but that doesn't quite do what I want. The behaviour is > right, but not the appearance. I don't want to see the current URL in > the minibuffer when I press g. > >> I hesitate to declare that following a blank url automatically >> equates to reload > > Fair enough. How about if a user variable selected this behaviour? > Or how about a user callback to allow arbitrary fiddling with the > string. >
Hi David, I have been thinking about this problem today, and I think I have an idea for an elegant solution that can unify several features into one interface. Ignore what I said about doing this in the browser-object system. On further thought, I think we should go to a lower level. In summary, the idea is a take on the option you presented: "a user callback to allow arbitrary fiddling with the string." But let me explain it in full....... Months back there was a feature request discussed in the irc channel: When an url has been read in the minibuffer, if it is not a valid url, and it is not a valid webjump, google the text. The idea evolved into "default webjump"--such that any webjump could be used as a default when none was given. Nobody has yet implemented this feature, but I believe it shares common traits with your empty-url handler such that both of them, and *possibly* the entire webjump system itself could be folded into a single configuration-interface. Here is the easy version: After reading some text with minibuffer.read_url and establishing that the text was neither a valid webjump nor a valid url (tricky bit), user-definable handlers would be tried in sequence until one claimed a match and performed a transformation on the text. This method would accomodate both the default webjump feature and the blank url feature, but lacks the comprehensive uniformity of the other possible way to do it.... Now here is the difficult version: minibuffer.read_url would itself be modified such that the completion-processors would be modular, instead of hard-coded. The user could configure the list of completers for read_url to use. Existing completers such as bookmarks, history, and webjumps would be made modular and included in this system. Default-webjump would also be a modular completer, available for the user to add in at a lower precedence than the webjump complter. An empty-url handler would also be available. > BTW, particular thanks also for your improvements to the url panel. Sure! Thank you for the nice feature. Definitely something I will use. Thoughts? -- John Foerch _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
