# This is a list of desired features. It is not a history of
# development, nor does it constitute a contract or promise of things
# to come. It is merely a list of ideas that occur to us during
# development, things we'd like to see included.
# We place a number before any item that has been slated for inclusion
# in a version. This number is from zero to nine where zero is the
# most imporant and therefore most likely kind of feature to make the
# cut. Nines are desirable in this version, but may be cut if we get
# tired or cranky.
- cvs_remote pref needs to propagate. This implies that we should
define an interface to system that can perform the environment
change before pushing. This would be nice anyway since we could
simplify all of the string handling and guarantee buffer space for
the system call. Perhaps an argv style call?
- Need a new layout that permits curves to browse a tree of files.
I envision this being a special pane (or mode) where we show the
tree of directories, whether or not they're controlled, and let
the use choose which ones beneath the current directory to
include in the curves file display. In this mode, the file window
shows either relative paths, or it shows filenames and the
directories are available in another pane.
- ssh/ksh access provided through a special hook to cvs commands.
The user may have a password to enter for these commands. We can
scan the output of the cvs commands for regex matching patterns
that occur when the program asks for passwords. CurVeS prompts
with the regex matched string, gets the password, and passes it
on. We may (or may not) choose to cache passwords during the
session. This is important for secure remote repositories.
1 - Autoconf
There more here to do. We should have more fall-back solutions.
For example, we can simpulate mmap with an allocate and a read.
Lastly, it would be nice if we could allow the user to configure
additional include and lib paths.
4 - Threading. Use LThread from deltacine to implement separate
threads for user input, screen output, and some file i/o. This
has the primary drawback of limiting portability. Probably, we
could get away with x86, sparc, and alpha.
1 - README (Started)
3 - Help -- do this with a help screen?
5 - Built-in pager/viewer
3 - Integral Changelog management
5 - Mouse, gpm library, DOS?
OK. The groundwork is laid. We have *access* to the mouse via
GPM, but the trouble is that ncurses is not a very convenient tool
for updating the screen. The rendering model comes from the
programmer instead of the user. Do we dare to write another? We
could use the same termcap data. Grr. This may end-up being a
usefile thing to do, anyway, if we want to encourage portability.
5 - Append current or tagged files to .cvsignore (use editor instead)
3 - Inclusion of CVSROOT cvsignore's
5 - Module database management
5 - Integral bug reporting
4 - Replacement for ncurses when on PCs: could be vgalib or direct
screen I/O. Note: we may be able to use PDCurses. Scratch that.
We'll be implementing our own, thank you bery much. We'll use
terminfo when available, then termcap, and finally some of our own
terminfo data (ANSI) when neither is available such as under
Windows. We want to get away from curses as fast as possible
because it is drek.
- Color directories with up-to-date color when controlled. Color
CVS directories, too, so we know these are significant to source
- RCS support? PRCS support?
- Directory caching.
- Persistent tags for project-wide, multiple directory, checkins.
- File display supression? Probably not necessary now that we can
sort by class. In fact, it is very unlikely this will be done.
It is left here for awhile until we do everything else.
4 - Win32 native.
- DJGPP build.
- CYGWIN build.
- Sun build.
- Alpha build.
- Checks in build process for size of integers. Note we need 32 bit
integers for some things to work.
5 - Import directory or convert directory to CVS.
- Command language: see below
- Preferences/options editor, integrated, automatically documenting,
extensible through data. ~/.curves/ directory for preferences,
log files, trace files, zworks.
- Make target to roll revisions and such.
- Diff/Comment mode. This would allow us to peruse a diff and
generate comments for each file s.t. we can quickly evaluate each
file, generate an appropriate for the changes made therein, and
commit each file with it's own, custom comment. This is really a
complex feature involving a directory to hold the file-specific
comments, an integrated editor with scrolling diff window, and a
method for duplicating comments when one file shares the same
heritage as one previously commented. This may be pushed to
2 - SIGWINCH: resize windows. Enforce minimum size. This will wait
for our own windowing code.
- SIGINT?, SIGHUP? Do we want to do anything special here? Cleanup?
Do I have any temporary files? Any status to update?
- SIGCONT may want to refresh files if dates have changed? Check
Entries file, too.
- ChangeLog maintainence is really an involved feature. In order to
put the ChangeLog itself into source control, we need to LOCK it
before committing changes. We'll need to do this automatically
for the user, but it also means we'll need to be careful about
signal handling so that the lock on the ChangeLog does not persist
(if we can help it). I believe we can remove the stale lock, but
it is best if we don't need to. Maybe there should be an option
to keep the ChangeLog local. This will not be a very attractive
feature if it doesn't do everything we want. Let's look into
hooking the standard history feature. I'll bet, though, that it
is not really interesting because we want to have a changelog be
specific to a project.
- Intelligent change management. We can keep the stamp for
CVS/Entries to know if anything has changed in the list of files
in source control. We can keep the directory stamp to know when
new files are created or old ones deleted. It won't tell us when
a file is modified, but that is probably OK since we know the
names of all of the files that already exist.
- Enumeration function with callback (or simple state-less index)
for processing tagged files. do_add () needs it. This may have
been obviated by creation of name_file () function.
- There is a large functionality gap in our ability to selectively
update a directory. The problem is that when the repository is
accessible only through a slow network or IP connection, we may
want to avoid redundant status requests. We're using v1.5 for
this development cycle.
- cvs tag
- Rename options file to preferences
- Continue during assert should redisplay the assertion failure
+ Initialization strings should be checked. We are not sending the
ACS enable string, something that could affect XTERMs. There are
some problems with color in X even though it appears to implement
the appropriate control sequences: refer to tct's output. Also,
we need to document that the use of attractive fonts may preclude
the display of line drawing characters.
# Command Language
We'd like to add a command language. The reason for this is to make
the extension of the application easier and more flexible. Also, we
think that a command language is easier to document and organize.
Here's a shot. The view windows can function as accelerators for the
command language, but ultimately, all work must be done by entering
commands. For example, we could let the mouse accelerate CD commands
with a click. We'll use completion to fill in all of the remaining
On second thought, I think it would be nice if the default mode was
navigating through lists of files and that a meta key be required to
start command mode. Perhaps it would be an option for the user to
cd - change directory
sort - change sort criteria
view - view a file
add - add a file to project
commit - commit add/remove/edit changes to project
tag - tag single or group of files. May allow tagging on
criteria. Perhaps this would be another command, ctag.
cvs - all of those cvs commands? Maybe these should be specialized
log - log
diff - differences
checkin - Special mode where we diff and then checkin each tagged
file or files by wildcard.
# Performance Improvement Suggestions
# (I had one and retracted it because it wouldn't work.)
- It has been observed that the cvs status command is the slowest
procedure when scanning a new directory.
- Continuous scrolling through the file list is slow. It should be
very speedy. Why the sloth?
- Threading could improve usability by permitting us to start-up
fast and fill-in details as we can. There is the fundamental
problem of asynchronous I.O, but this can be alleviated by good
autoconf and by clever interleaving of the slower operations. The
key is to make the UI highest priority and responsive.