todo

multi-tabed terminal based on rxvt

			      TODO list for mrxvt.

If you do something on this list, be sure to send us a patch. See the section
on "CODING GUIDELINES" at the end of this file.

Priority classification:    9 -- Important, 0 -- Useless.

--------------------------------------------------------------------------------

				  NEW FEATURES

Menus:
8   Sticky menus, that can be accessed via the keyboard.
7   Add -pfn option (analogous to -xftpfn) for a proportional font to display
    tab titles / menus with an X11 font.
7   Multichar Xft support in menus.
7   Extend menu language / facility.
5   Write decent menus. Almost all options we have now should be available via
    some menu.

Windows and tabs:
7   Split window support (e.g. like screen / vim).
7   Have mrxvt be able to manage multiple windows. (Advantage is low memory
    usage, and the ability to detach tabs / move them between windows).
7   Rewrite background support using imlib2
7   Show icons in tabs (after imlib2 support is added)
7   Regexp based icon selection for tabs (and EWMH mini icon)
5   Add separate colors for tabbar background, menubar fg/bg
5   Searching scroll buffer support: We should pipe the scroll-back to less
    directly, and open it in the *same* tab. (Ugly hack possible using macros)

Core:
9   UTF-8 support.
8   Better performance with vttest.
7   I18N support
7   regexp based selection, and URL highlighting
7   Smart insertion of newlines in the selection
5   Xterm style mouse support, e.g., joe 3.2
4   Extensible timer support

Code Cleanup:
5   The original rxvt installed a core functionality in a library (librxvt).
    mrxvt does not do this, however a lot of mrxvt's code is structured for it.
    For instance, half our definitions are in rxvtlib.h (which should be moved
    to rxvt.h). All our function names start with "rxvt_". These can be safely
    renamed: e.g. rxvt_cmd_getc can be called getcFromTabs() or getc_from_tabs.
    [The shmuck who does this cleanup will get to use his convention in naming.
    The rest of us will have to follow it.]
5   Some variables are named very badly. Our names should either be mixed case
    without underscores, or lower case with underscores. Not mixed case with
    underscores. This convention should be followed consistently for all global
    structure members, and function names.
5   Legacy rxvt code cleanup: There's tonnes and tonnes of rxvt code that has
    not been read by anyone for YEARS. It can probably be cleaned up a lot.
3   Reduce X resource usage: We currently use one window for each VT. This is
    very wasteful, especially since we only display one window each time.

--------------------------------------------------------------------------------

				      BUGS

9   vt100 printer support is now broken. Fix it.
8   Looks like rxvt_scr_refresh is called twice every time. (The second refresh
    is cheap, as the screen is current). But eliminating this will save a few
    CPU cycles... NOTE: Only happens with -tr
8   When sending escape sequences to mrxvt via macros, make sure we are not
    disrupting processing of another escape sequence.
1   PNG and JPEG background support on Solaris looks broken

--------------------------------------------------------------------------------

			       CODING GUIDELINES

If you want to contribute code to mrxvt, PLEASE PLEASE follow these guidelines.

Right now we only have two regular developers, who are extremely busy. We could
use your help. If you want to help, do anything on the above list and send us a
patch. Or do something useful (and not contradictory to mrxvt's design goals),
and send us a patch.

If you send us patches regularly, then we will probably give you subversion
access.

SUBMITTING A PATCH

    Use the following guidelines when submitting a patch for mrxvt:
    1. Please please submit a patch against the LATEST version from the
       subversion repository (NOT THE LATEST RELEASE). Look on the download
       section for how to checkout mrxvt from subversion.
    2. Include the date, and revision number of the version from the subversion
       repository your patch is against.
    3. Follow the guidelines under "WRITING CODE FOR MRXVT" at the end of this
       section.

COMMITTING TO SUBVERSION

    Use the following guidelines when committing your work to the subversion
    repository.
    1. DO NOT COMMIT YOUR WORK UNLESS IT COMPILES CLEANLY (with
       --enable-everything)
    2. DO NOT COMMIT YOUR WORK IF IT SEGFAULTS.
    3. Be sure you leave helpful messages in the subversion logs.
    4. If you plan on implementing something small (e.g. new option that takes
       all of 10 lines of code, and is useful) just go ahead and do it. No need
       to announce it on the devel list / etc.
    5. If you plan on major code changes, or a "big" feature (e.g. imlib2
       support), then it would be a good idea to discuss this on the devel list
       first.
    6. Follow the guidelines under "WRITING CODE FOR MRXVT" at the end of this
       section

WRITING CODE FOR MRXVT

    PLEASE PLEASE follow these guidelines when contributing code to mrxvt.
    1. The "one true brace/tab style" sucks. Use the style we have in our code.
       With Vim 7 and syntax folding (fdm=syntax), it looks quite nice! If you
       use Vim, and want to edit the code PLEASE USE

	   :set sts=4 ts=8 sw=4 autoindent cindent noet tw=80
       
       If you don't use Vim, this roughly translates to:
	- Make tabs 8 characters wide (and don't expand them into spaces)
	- Indent four spaces for every level
	- Wrap your lines at 80 characters
	- Follow the brace, indent and comment style in the code.

       It's not the end of the world if you don't wrap lines at 80 characters
       (though we strongly urge you to). But if you break the indent, brace, or
       comment style you will get flamed by me (gi1242).
    2. You're probably aware of our design goals: Small, light, and CPU
       friendly. Don't bend this one too much, otherwise you will get flamed
    3. Don't add dependencies unless you ABSOLUTELY have to. Even then, discuss
       it first on the devel list. Regardless, any dependency you add MUST be
       optional, and mrxvt should be able compile and run without it.
    4. If you are adding a new experimental feature (e.g. Jimmy's memory code),
       then make sure you #ifdef it out. Thus you can use the feature by
       compiling with env CFLAGS="-DFANTASTIC_FEATURE" configure
       --enable-everything Once your feature has become stable, either add a
       macro in src/feature.h, or a --enable configure option.
    5. Comment your code! Either me or Jimmy might remove / rewrite it
       otherwise. (Jimmy's removed some under commented code of mine before,
       and he's sure to do it again should the need arise.)
    6. If you've added a new feature, PLEASE DOCUMENT IT.
    7. If you've done something on this TODO list, please update this list.
    8. We're flexible! If for some reason you don't want to follow the above
       coding guidelines, then LET US KNOW. We're open to discussion on coding
       styles / etc. If we agree to your proposed change, then it is your
       responsibility to change the style of the current mrxvt codebase to the
       agreed new style. Just sending us a patch with only your code in your
       style will get you flamed.
    9. Mrxvt is GPL. Don't write code for us unless you are willing to release
       it under GPL.

That's it. Happy hacking

--------------------------------------------------------------------------------

 Authors	: Jimmy Zhou, Gautam Iyer
 $LastChangedDate: 2008-06-29 23:28:25 -0700 (Sun, 29 Jun 2008) $