Matthieu Moy <[EMAIL PROTECTED]> writes: >> Sometimes I find the diff listing useful, but mostly not. > > If you're talking about the summary at the top of the diff buffer, to > me, this is *the* added value of dvc-diff-mode compared to plain > diff-mode. If the diff covers multiple files, and doesn't fill in a > screen, I still want to know easily which files are touched by the > patch.
Right. But I don't use diff-mode in the first place for CM stuff; I'm used to the CVS interface provided by pcvs. That is similar to the "summary", _without_ the actual diffs. I think that's what dvc-status is intended to provide. But modern CM tools are different than CVS, so perhaps the diff is more useful. I should give it more of a try. > Why do you think "diffstat" is so popular in patch exchanging > communities? I have no idea; I'm not part of that community. >>> Implementing a new diff-mode, and removing the summary part from the >>> diff-mode would be a real loss of functionality IMHO. The summary is >>> really the part you want to start with as soon as the diff is more >>> than a screen long, and you have the key 'j' to switch from the >>> summary to the diff, and vice-versa. >> >> Actually, I'm implementing a new status-mode, and leaving the current >> diff-mode alone. >> >> I'm using symbols for the file status (instead of letters), and a CL >> struct for the ewoc data. So it is easier to understand and edit. > > That is something we wanted to do for a long time for dvc-diff-mode, > but no one took the time to do it. Indeed, the relevant structure to > describe the state of a file is a list of symbols (like, '(modified > renamed mode-change)). > >> Perhaps it would make sense to change the current diff-mode to be >> more like what I want. > > Definitely. Doing what you're doing right now, you'll end-up with a > new mode, you'll have to write back-ends for it (you may not /yet/ > have touched the backends, but one day, you'll need someone to fill-in > your ewoc structure for each back-end), and the diff-mode will still > be using letters, so you'll have something worst than duplication of > code: duplication, with one of the version obsoleted but still without > correct replacement. I have to correct what I said about modifying the backend. I'm writing this in an internet cafe, and I feel some time pressure, so I'm not thinking things thru. I did modify the monotone backend, in two ways: 1) Since I changed the ewoc structure, the backend changed to match. 2) Since the backend controls what is put in the ewoc, I took out things I didn't want. > In other words: before implementing a new status-mode, please, > identify _problems_ with the current diff-mode, that are not fixable > in diff-mode itself. I haven't seen any in this thread yet. The only one that is serious is disabling commit commands when reviewing diffs from non-head branches. I suspect that's not much of a problem. > Thanks for your work, anyway :-). You're welcome. One advantage of creating a new mode is I don't have to worry about breaking the old one. But branching is another solution to that. I think what I should do at this point is create a branch to modify dvc-diff to use a new ewoc structure, make it work with montone and bzr, and then play with it on my real (work) project. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
