File: TODO

package info (click to toggle)
curves 0.8.7
  • links: PTS
  • area: main
  • in suites: slink
  • size: 704 kB
  • ctags: 1,001
  • sloc: cpp: 6,197; ansic: 519; makefile: 270; sh: 192; fortran: 149
file content (184 lines) | stat: -rw-r--r-- 9,478 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
#
# 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
    control. 
  - 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
    version 2.
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
    message.

  + 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
usability gaps.

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.