Unordered Tasks

redesign page-modes

The current design of page-modes was modeled on major-modes in Emacs. While this seemed like a novel idea, it has not worked well in practice, because page-modes have ended up being monolithic, many unrelated features bundled together under one name, with seemingly arbitrary defaults. Some page-modes override key bindings, with no clear system for disabling the special keys. This is all bad. Page-modes need to be split up and granularized so that people can turn on only the specific features they want in a simple, uniform api.

improve documentation

internationalization

Help strings, prompts, and docstrings can all be internationalized. Docstrings bear some discussion. By design, they are inline in the source, in English as a form of code literacy. That will not be changed. However, docstrings in other languages can be stored in locale files, and help buffers can display the user's preferred language.

new-tabs rewrite

Currently, any given tab in new-tabs is tightly coupled to the buffer it represents. The tab has a closure on a reference to the buffer, and the buffer has a property reference to the tab. This makes it problematic to change the order of buffers, as we will be able to do in the future, because it means destroying and regenerating tabs for any such change, a clear hack. Instead, tabs should refer to buffers by simple indices. Perhaps each buffer needs its own index within its window stored as a property in order to avoid inefficiency of figuring out the indices from the buffer list at each access. This project needs to happen before the ui redesign, but generally could be done at any time.

Ordered Tasks

contextualize minibuffer and input

currently there is one minibuffer per window. this presents a problem as conkeror's ui becomes more flexible, if commands can run in other contexts and alter, move, or destroy buffers (or other stateful objects) being used by a minibuffer, conkeror's behavior is unpredictable. we considered globalizing the minibuffer and the input handler so that only one sequence could happen at a time, but actually it is preferable to keep the current flexibility of multiple minibuffers, but contextualize them. this means that a given input sequence, and minibuffer-state-stack, could be associated with a particular context, like a buffer, and have a lock on that context so that if anything else tried to modify it, the other command would either fail or gracefully override.

logging system

Replace direct calls to dumpln and minibuffer.message, etc, with calls to a new function "log", which takes a log route, a message, and optional additional information. Log routes can be configured to send different kinds of information to specific targets. A *Messages* buffer may be part of this project. This project depends on a reworking of the minibuffer, to accomodate log routes.

contextualize input system

Commands can be called from different contexts, on different targets. Commands can be called from windows (conkeror windows and potentially other kinds as well), command-line remoting, and on OS X, the menu system. Details to be worked out about coordinating these contexts. See above, "contexualize minibuffer and input".

redesign command line handling

A new command line handling system which accomodates calling commands in particular buffers, and loading urls in particular windows. Depends on contextualized input system.

ui redesign

The signal feature of the so-called "ui redesign" is buffer/window decoupling. Buffers will no longer be stuck in particular windows, but will be movable from one window to another. This is termed a "redesign" because it changes a basic assumption which runs deep in Conkeror. This redesign will be an apt time to add internal window management. Internal window management is the general category which includes, but is not limited to, window splitting.