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