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) $
