Stefan Reichör <[EMAIL PROTECTED]> writes: >> So I suggest adding a buffer-local variable dvc-post-commit-action in >> the status buffer. The status buffer major mode can set it to an >> appropriate action. Then the :finished clause of >> <back-end>-dvc-log-edit-done can switch back to the status buffer via >> dvc-partner-buffer, and call dvc-post-commit-action (if non-nil). > > It would be nice to find a general solution to update the status buffer after > a dvc action. This means adding, removing, renaming, committing, etc.
Yes. I'm adding such operations in my experimental dvc-status-mode, but I don't have a general mechanism; just new code for each command. The current version is available at http://stephe-leake.org/dvc-fileinfo. It still has a long way to go. Although most of them delete the current file(s) from the ewoc; that operation could be factored out better. So, for example, 'i' is bound to dvc-status-ignore-files, not dvc-ignore-files. dvc-status-ignore-files calls dvc-ignore-files, then deletes the just-ignored files from the ewoc. Although I just realized I have a user option dvc-status-display-ignored, which if t says I should _not_ delete them! So that's broken. > Your solution would only provide the functionality for commit. Right. commit is special because it is invoked from the log-edit buffer, which is not in the same major mode as the status buffer. So it needs another mechanism to call the cleanup code. I suppose all dispatching dvc commands could have a '*-command-complete' callback, that each mode could specify. I'm not sure that's better than my current approach. > Would it be too slow, when we just refresh the status buffer after a commit? Well, "too slow" is a personal judgement. refresh will _always_ be slower than just deleting ewoc entries, since that's what refresh does first anyway. Typically you will want to do some other back-end operation, like pull or merge, before you need a full refresh. > We have the following functionality for tla (at least for diff > buffers, not sure about status) After a commit, we show the message > "Committed a new revision, buffer info may be out of date, please > refresh the buffer". Such a thing could be done, when refreshing > would take too long. Right. That happens for bzr too; I forgot that. That's a specific message output in the :finished clause of bzr-log-edit-commit, by calling dvc-diff-clear-buffers. So my proposal is a small generalization of this, that allows dvc-log-edit-commit to not assume its partner buffer is in dvc-diff-mode. dvc-diff-mode would also set dvc-post-commit-action, to a function that calls dvc-diff-clear-buffers. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
