ELinks-1.0 roadmap ~~~~~~~~~~~~~~~~~~ I've decided that these major points would be too in-convenient to have just in BugZilla. The entries for them should still be in BZ as well tho' as it will be easier to track possible discussion and patches etc. I have no time to look up their bug numbers so please feel free to contribute ;-). I forgot a lot of things, I have big troubles to even keep together in memory these (I have been sitting for three minutes staring into void trying to remember two or three of these). Please contribute. Sorted roughly by priority. [-] : Not started [\] : In early progress [|] : In late progress [/] : In testing [+] : Done [+] Better thought out compile-time configuration Some two level script or so. Just some good wrapper to feature.h. Or maybe to ditch feature.h completely. [\] nl_langinfo(CODESET) Set automatically terminal charset as this (probably a 'System' charset like we have 'System' language). [\] Actions revamp Basically: [+] Make the actions keymap-specific [+] Support for action aliases (so that we can rename the actions like 'up' to something meaningful) [-] Intelligent saving support (so that config_style matters) [-] Then remap all (maybe except the most used, bookmarks&downloads) manager keystrokes behind universal 'm' prefix [-] Then, the path will be free for 'hjkl' navigation ;-) [+] Options fixes Similarly, the deleted options should be saved so appropriately. Probably some 'unset' command for deleted options, otherwise ie. the default user protocols always reappear when you set them. [+] convert_string() efficient usage from HTML renderer Currently, it is a gross memory hog in certain cases of big HTML documents, we need to feed it only in smaller chunks (see how it was done in 0.3 or maybe even 0.4 if the convert_string() functionality was still duplicate by that time). Basically, try to load a _BIG_ text or better HTML file (1M should be fine) in ELinks and watch it die slowly. We call convert_string() in put_chars_conv() just once now, basically duplicating the buffer (while eating gross amounts of memory because of apparently some other bug in the memory management) instead of gradually doing put_chars() every once a while; OTOH we should solve this w/o reintroducing the gross code duplication, when the differences are really only minimal. [\] Do not enter into the form items automatically but after a keypress Will be a gross usability improvement. [/] UI fix of hierboxes Ie. when stopping a download, it asks you 'Delete "filename"?'. VERY confusing ;-). [+] Send bars info in dimensions in the User-Agent header If a bar is shown, ELinks/0.9.1 (textmode; Linux 2.6.1-rc3 i686; 87x32-3) or smt. like that should be sent. Some applications use ie. special formatting for very big tables for ELinks, and they need to know this (requested by MyCompany). The number after dash should be number of the bars shown - 3 would be ie. for title bar, status bar and tabs bar. [/] Cursor routing Basically, an alternative navigation mode to the classic link-by-link jumping. Just w3m-style navigation support ;-). [+] http4/http6 Scheme ending by number 4 or 6 selects the appropriate address family to use. Great if your IPv6 connectivity is non-working. Also some global option turning IPv4/IPv6 on/off. [/] More power to the cookies manager Ability to create/edit cookies. [-] Refresh support remake It needs to be moved to cache_entry, so that it works reliably in frames, on the background etc. [\] Correct caching support At least optionally and by default on we have to support the caching correctly with all its expirations and so. [-] Check download resuming support It just does not work properly it seems. It should get an in-depth review, together with possible changes and cleanups of inner working of bigger parts of the sched subsystem. But this needs to be really carefully controlled so that we will not break it even more. [+] -remote support We should have builtin -remote support, similar to elinks-remote and Netscape/Mozilla's -remote parameter. I think it should be compatible with Mozilla (http://www.mozilla.org/unix/remote.html), the syntax used there looks pretty smart and extensible. [|] Major encoding support enhancement The SSL and gzip combination is killer for big documents, you just always get a garbage, someone need to debug that. It is triggerable at the big form two steps away at http://www.mff.cuni.cz/eprihlaska. The encodings support should get a major cleanup, the standing-long-out-of-the-tree deflate encoding support should be merged etc. We should decode encoded stuff properly, keeping the compressed version around so that we could offer a choice (in form of save-as checkbox I suppose) whether to save the compressed or uncompressed version, and show the download progress properly. [|] Micro CSS support Actually this could well be a two-hour hack for the most trivial CSS support and could take us forward by a great leap. Just trivial attribute-level CSS parser and support for 'style' tags attribute. It won't get any easier than that. We need to support id/class/special selectors to have this flipped to /. To consider this done, we must have support for some more attributes and correct non-pair-tags support. [+] -localhost support For -dump, to ensure to external connections will ever be made. This is almost dome, just pending my review and testing ;-). [|] Ideally, some Perl scripting support Actually, this is not a must-have, but would be very cool. To fit into the Lua framework, but I'd like to have it quite more powerful, actually. [-] Ideally, some major advancement in SSL support Certificates management and such. Just steal it from w3m ;-). vim:formatoptions=tcqn21:autoindent:tw=78: