Matthieu Moy <[EMAIL PROTECTED]> writes:
> I kept track of various nitpicks while using it, and have included a
> list; most of these are quite minor, but I didn't attempt to fix
> anything on the assumption that the code's probably still changing
> quickly and I'd just run into conflicts anyway.
If you want to join, you're welcome ;-) but anyway, thanks for your
remarks.
I've modified the TODO list, some of your remarks were already fixed
and other could be seen in a more general way, so, it's a bit more
than a cut-and-paste:
--- orig/docs/TODO
+++ mod/docs/TODO
@@ -102,6 +105,51 @@
* Recursive commands for projects using configurations.
+* Perhaps when `tla-make-log-function' is non-nil, `tla-make-log' should
+ check the return value, and if nil, make a normal log file. That way
+ the user's special version can only worry about special cases.
+
+* If not in a project tree, `tla-changes' should prompt for the tree
+ name similar to tla-inventory -- often I'd rather start out with
+ `changes' and skip `inventory' entirely.
+
+* It would be nice if the `g' command in a *tla-changes* buffer would
+ would retain any existing marks (I often want to check the changes
+ just one last time before committing).
+ => Should be easy to do since the list of marked files is stored in
+ a variable.
+
+* More diff-mode commands should be bound in the *tla-changes* buffer,
+ e.g., `P', and `N'; maybe it can just inherit from the diff-mode
+ keymap?
+ => We are already inheriting from diff-mode. However, the way the keymap
+ is managed in diff-mode is really strange, and you're right,
+ we're not inheriting `N' and `P'. But still, diff-file-next is
+ available with M-N for example. Strange ...
+
+* After committing from a *tla-changes* buffer, it would be good to
+ automatically update the buffer, so there's a clear indication
+ what's changed.
+
+* When there are no changes anymore, the `g' command in the
+ *tla-changes* buffer just prints a message in the echo area, and
+ doesn't update the buffer, which can be confusing; it would be
+ better to erase the buffer and perhaps insert the "No changes"
+ description to make it clear what's going on (so work slightly
+ differently than `M-x tla-changes' invoked from another buffer -- in
+ that case, just a message is good).
+
+
+* Better management of buffers. xtla buffers should have a unique name
+ based on the directory or archive to which it refers. It should be
+ possible to run several tla-{change|inventory|revisions|...} in
+ different trees. We should keep a list of xtla related buffer to be
+ able to delete them afterwards. (The current regexp-based algorithm
+ is not satisfying in my opinion)
+
+* Modeline : I'd like to see something like the "compiling" item in
+ the modeline while compiling with M-x compile RET.
+
Mostly DONE section:
* Some like file-diff-rev from the aba which gives you the changes to a
The TODO section is now 150 lines long !!!
--
Matthieu
