6:39 p.m.
>>>> "MK" == Michael Kifer
<kifer(a)cs.sunysb.edu> writes:
> (lambda ()
> (let ((last-command-char ?h))
> (ediff-meta-mark-equal-files)
> (ediff-hide-marked-sessions nil)))
>
> And don't ask why the
> (let ((last-command-char ?h))
> binding is necessary :-)
>
> Michael, is there a better way to do this?
>
> My solution looks a bit tricky (I mean the last-command-char hack) to
> me.
MK> Adrian, thanks for the patch.
MK> Regarding the above question, I guess I could add an optional
MK> argument to make it more palatable to use this function. I
MK> didn't make it the default because it can take a lot of time
MK> to run diff on large directories with large files.
Hi Michael, hi All, Happy new year to you!
I am glad to confirm that the latest XEmacs ediff package works fine
with
`ediff-after-session-group-setup-hook' (buffer: .emacs-i586-pc-win32, mode:
Emacs-Lisp)
Customizable user variable:
value: see below
*Hooks run just after a meta-buffer controlling a session group, such as
ediff-directories, is run.
value:
((lambda nil
(ediff-meta-mark-equal-files ?h)
(ediff-hide-marked-sessions nil)))
Another thing:
I wish I could use
= e runs the command dired-ediff
on two directories to run `ediff-directories' automatically.
I realize this particular thing is a dired/ediff integration issue.
Pushing my point farther, wouldn't it be useful for ediff to simplify
its interface to invoke `ediff-files' or `ediff-directories' depending
on the arguments provided?
Is this perhaps even possible already and I just missed this?
How about:
ediff-??? DIR1 FILE2
runs (ediff-files DIR1/FILE2 FILE2)
ediff-??? DIR1 DIR2
runs (ediff-directories DIR1 DIR2)
ediff-??? FILE1 DIR2
runs (ediff-files FILE1 DIR2/FILE1)
Is this too DWIMy for you?
Best regards,
Adrian
MK> --michael
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7:47 p.m.
New subject: ediff questions
Adrian Aichner wrote:
Hi Michael, hi All, Happy new year to you!
Happy New Year to all!
Another thing:
I wish I could use
= e runs the command dired-ediff
on two directories to run `ediff-directories' automatically.
I realize this particular thing is a dired/ediff integration issue.
Pushing my point farther, wouldn't it be useful for ediff to simplify
its interface to invoke `ediff-files' or `ediff-directories' depending
on the arguments provided?
Is this perhaps even possible already and I just missed this?
I think this is something dired-ediff should do: check the file at point
and if it is a directory then run ediff-directories; otherwise ediff-files.
How about:
ediff-??? DIR1 FILE2
runs (ediff-files DIR1/FILE2 FILE2)
ediff-??? DIR1 DIR2
runs (ediff-directories DIR1 DIR2)
ediff-??? FILE1 DIR2
runs (ediff-files FILE1 DIR2/FILE1)
I think the basic commands, such as ediff-files, ediff-directories,
etc., should not second-guess the user.
What you want should be done by a higher-level command, such as dired-ediff.
One can also write something like
ediff-outsmart-the-user
which will always do second-guessing. But I think the user always knows
what he wants and it is faster and easier to type M-x ediff or M-x edirs.
dired-ediff is a different matter. Here we have certain context (the
location of the point in the dired buffer), and it makes sense to apply
your heuristic.
--michael
9:16 p.m.
New subject: ediff questions
>>>> "MK" == Michael Kifer
<kifer(a)cs.sunysb.edu> writes:
MK> Adrian Aichner wrote:
> Hi Michael, hi All, Happy new year to you!
MK> Happy New Year to all!
> Another thing:
>
> I wish I could use
> = e runs the command dired-ediff
> on two directories to run `ediff-directories' automatically.
>
> I realize this particular thing is a dired/ediff integration issue.
>
> Pushing my point farther, wouldn't it be useful for ediff to simplify
> its interface to invoke `ediff-files' or `ediff-directories' depending
> on the arguments provided?
>
> Is this perhaps even possible already and I just missed this?
MK> I think this is something dired-ediff should do: check the
MK> file at point and if it is a directory then run
MK> ediff-directories; otherwise ediff-files.
Ah, I was thinking about running
= e runs the command dired-ediff
on a region, selecting two directories, or files, or one of each.
> How about:
>
> ediff-??? DIR1 FILE2
> runs (ediff-files DIR1/FILE2 FILE2)
>
> ediff-??? DIR1 DIR2
> runs (ediff-directories DIR1 DIR2)
>
> ediff-??? FILE1 DIR2
> runs (ediff-files FILE1 DIR2/FILE1)
MK> I think the basic commands, such as ediff-files,
MK> ediff-directories, etc., should not second-guess the user.
My point is that the UI is lacking because it does not support the
user to do the right thing.
ediff-files only makes sense on two files,
ediff-directories only makes sense on two directories,
but the interface does nothing to help the user in this regard.
e.g. using ediff-files from within the *scratch* buffer (with CWD ~):
1.
ediff-files prompts for file A with ~\.
If I accept this default and complete file B to ~\.emacs, I get:
File `c:\Users\AichnerAd\' is a directory
I have
(getenv "HOME")
"C:\\Users\\AichnerAd"
2.
If I complete file A to ~\.emacs and accept the default of ~\ for file
B, ediff-files compares ~\.emacs with itself.
If suggest ediff should refuse service in both cases and report
inappropriate usage.
e.g. ediff-directories from within the *scratch* buffer (with CWD ~):
3.
ediff-directories prompts for file A with ~\. If I accept this
default for file A and file B, ediff correctly reports:
Directories A and B are the same: c:\Users\AichnerAd\
I'm cool with that.
4.
If I complete file A to ~\.emacs and accept the default of ~\ for file
B, ediff-directories reports
Directories A and B are the same: c:\Users\AichnerAd\
I feel outsmarted :-(
MK> What you want should be done by a higher-level command, such
MK> as dired-ediff. One can also write something like
MK> ediff-outsmart-the-user which will always do
MK> second-guessing. But I think the user always knows what he
MK> wants and it is faster and easier to type M-x ediff or M-x
MK> edirs.
I'm not too sure about that.
MK> dired-ediff is a different matter. Here we have certain
MK> context (the location of the point in the dired buffer), and
MK> it makes sense to apply your heuristic.
I'm working on a patch.
MK> --michael
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:17 p.m.
New subject: ediff questions
Adrian Aichner <adrian(a)xemacs.org> writes:
MK> I think this is something dired-ediff should do: check
the
MK> file at point and if it is a directory then run
MK> ediff-directories; otherwise ediff-files.
Ah, I was thinking about running
= e runs the command dired-ediff
on a region, selecting two directories, or files, or one of each.
Do you mean that point would designate one file and mark the other?
what about comparing 3 files or 3 directories?
>> How about:
>>
>> ediff-??? DIR1 FILE2
>> runs (ediff-files DIR1/FILE2 FILE2)
>>
>> ediff-??? DIR1 DIR2
>> runs (ediff-directories DIR1 DIR2)
>>
>> ediff-??? FILE1 DIR2
>> runs (ediff-files FILE1 DIR2/FILE1)
MK> I think the basic commands, such as ediff-files,
MK> ediff-directories, etc., should not second-guess the user.
My point is that the UI is lacking because it does not support the
user to do the right thing.
ediff-files only makes sense on two files,
ediff-directories only makes sense on two directories,
but the interface does nothing to help the user in this regard.
OK. I agree that
ediff-files DIR1 FILE2
runs (ediff-files DIR1/FILE2 FILE2)
makes good sense. In fact, this is an omission. But I don't think that
ediff-files DIR1 DIR2
should run ediff-directories.
1.
ediff-files prompts for file A with ~\.
If I accept this default and complete file B to ~\.emacs, I get:
File `c:\Users\AichnerAd\' is a directory
I have
(getenv "HOME")
"C:\\Users\\AichnerAd"
2.
If I complete file A to ~\.emacs and accept the default of ~\ for file
B, ediff-files compares ~\.emacs with itself.
If suggest ediff should refuse service in both cases and report
inappropriate usage.
Yes, it shouldn't compare a file with itself.
4.
If I complete file A to ~\.emacs and accept the default of ~\ for file
B, ediff-directories reports
Directories A and B are the same: c:\Users\AichnerAd\
I feel outsmarted :-(
This is a heuristic: if you do ediff-directories and give a file name
instead, it assumes that you meant the file's directory. I found it useful
in many cases, although I don't know if this works for everyone.
MK> What you want should be done by a higher-level command,
such
MK> as dired-ediff. One can also write something like
MK> ediff-outsmart-the-user which will always do
MK> second-guessing. But I think the user always knows what he
MK> wants and it is faster and easier to type M-x ediff or M-x
MK> edirs.
I'm not too sure about that.
I agree that ediff-files/buffers/directories/etc should use heuristics to
offer good defaults and such. Ediff implements a number of such
heuristics and, of course, there is always room for improvement.
What I don't think is appropriate is when ediff-files suddenly
changes its hat and becomes ediff-directories.
However, I am cool with the idea that somebody implements
ediff-I-feel-lucky, which will figure out for you what you want and will
apply the right function on exactly the arguments that you wanted.
--michael
8:33 a.m.
New subject: ediff questions
>>>> "MK" == Michael Kifer
<kifer(a)cs.sunysb.edu> writes:
MK> Adrian Aichner <adrian(a)xemacs.org> writes:
MK> I think this is something dired-ediff should do: check the
MK> file at point and if it is a directory then run
MK> ediff-directories; otherwise ediff-files.
>
> Ah, I was thinking about running
> = e runs the command dired-ediff
> on a region, selecting two directories, or files, or one of each.
MK> Do you mean that point would designate one file and mark the other?
MK> what about comparing 3 files or 3 directories?
Right. That functionality has been there for a long time. I don't
think 3 files or directories can be specified via a dired buffer.
`dired-ediff' (buffer: *wide reply to Michael Kifer*, mode: Message)
Interactive Lisp function:
arguments: (file)
Ediff file at point with FILE.
FILE defaults to the file at the mark.
`ediff-directories' is used if both files are directories.
> >> How about:
> >>
> >> ediff-??? DIR1 FILE2
> >> runs (ediff-files DIR1/FILE2 FILE2)
> >>
> >> ediff-??? DIR1 DIR2
> >> runs (ediff-directories DIR1 DIR2)
> >>
> >> ediff-??? FILE1 DIR2
> >> runs (ediff-files FILE1 DIR2/FILE1)
>
MK> I think the basic commands, such as ediff-files,
MK> ediff-directories, etc., should not second-guess the user.
>
> My point is that the UI is lacking because it does not support the
> user to do the right thing.
>
> ediff-files only makes sense on two files,
> ediff-directories only makes sense on two directories,
> but the interface does nothing to help the user in this regard.
MK> OK. I agree that
MK> ediff-files DIR1 FILE2
MK> runs (ediff-files DIR1/FILE2 FILE2)
MK> makes good sense. In fact, this is an omission. But I don't think that
MK> ediff-files DIR1 DIR2
MK> should run ediff-directories.
> 1.
> ediff-files prompts for file A with ~\.
> If I accept this default and complete file B to ~\.emacs, I get:
> File `c:\Users\AichnerAd\' is a directory
>
> I have
> (getenv "HOME")
> "C:\\Users\\AichnerAd"
>
> 2.
> If I complete file A to ~\.emacs and accept the default of ~\ for file
> B, ediff-files compares ~\.emacs with itself.
>
> If suggest ediff should refuse service in both cases and report
> inappropriate usage.
MK> Yes, it shouldn't compare a file with itself.
What is this good for? Bavavior of 1. vs. 2. looks like an accident
to me with my dumb-user-hat on.
> 4.
> If I complete file A to ~\.emacs and accept the default of ~\ for file
> B, ediff-directories reports
>
> Directories A and B are the same: c:\Users\AichnerAd\
>
> I feel outsmarted :-(
MK> This is a heuristic: if you do ediff-directories and give a
MK> file name instead, it assumes that you meant the file's
MK> directory. I found it useful in many cases, although I don't
How is this heuristic different in nature from what you call
"outsmart"?
MK> know if this works for everyone.
MK> What you want should be done by a higher-level command, such
MK> as dired-ediff. One can also write something like
MK> ediff-outsmart-the-user which will always do
MK> second-guessing. But I think the user always knows what he
MK> wants and it is faster and easier to type M-x ediff or M-x
MK> edirs.
>
> I'm not too sure about that.
MK> I agree that ediff-files/buffers/directories/etc should use heuristics to
MK> offer good defaults and such. Ediff implements a number of such
MK> heuristics and, of course, there is always room for improvement.
MK> What I don't think is appropriate is when ediff-files suddenly
MK> changes its hat and becomes ediff-directories.
I see your point, but current behavoir does not look coherent until
one understands a lot more about ediff than one should be required to
know.
MK> However, I am cool with the idea that somebody implements
MK> ediff-I-feel-lucky, which will figure out for you what you
MK> want and will apply the right function on exactly the
MK> arguments that you wanted.
My dired-ediff patch has entered the patch-approval state-machine :-)
MK> --michael
Best regards,
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8360
days inactive
8362
days old
4 comments
2 participants
participants (2)
-
Adrian Aichner -
Michael Kifer