RE: Emacs Explorer?

RE: Emacs Explorer?

[Drew Adams]

Thanks for the info, Jason! I wasn't aware of dired-dd.

I just downloaded it and checked it out.

FYI - It does a lot more than the minor tweaks I mentioned (in particular,
it does drag-&-drop). (It also does less than some of my code; it's
~complementary, in fact.)

I can't say that I would propose the dired-dd user interface as a model for
an Emacs Explorer (or its code as a model of elisp programming!), but it's
good to see a drag-&-drop prototype.

I realize that you didn't propose dired-dd as a model. Do you actually use
it?

I'd like to see something in Dired as user-friendly and useful as what
Windows Explorer offers. Things like drag-&-drop can be quite error prone,
so the user interface needs to be very good (good feedback etc.).

Code like dired-dd (and my dired+) provides only baby steps toward the
functionality of WE - Emacs dev could do a lot better. WE is a model to copy
or learn from; dired-dd is probably not.

Thanks,

  Drew

P.S. Hope you don't mind my cc'ing the list.

-----Original Message-----
From: Jason Rumney [mailto:jasonr@gnu.org]
Sent: Wednesday, April 14, 2004 12:32 PM
To: Drew Adams
Subject: Re: Emacs Explorer?


"Drew Adams" <drew.adams@oracle.com> writes:

> FYI - I've added a couple of the really *minor* Windows-Explorer features
to
> my own dired:
>
>  . To select multiple files, you can click MB1 then Shift-click MB1, or
just
> MB1-drag a region.
>  . Context-dependent MB3 popup menu (operates on all files in the region
or
> the single pointed file).

Have you seen dired-dd? I think I found it on gnu.emacs.sources about
a year ago. It probably has what you've added and more.

Re: Emacs Explorer?

[Jan D.]

> FYI - It does a lot more than the minor tweaks I mentioned (in 
> particular,
> it does drag-&-drop). (It also does less than some of my code; it's
> ~complementary, in fact.)

The drawback of dired-dd is that it only does local drag and drop, i.e.
within the same Emacs.  For DND to be useful I think it should be 
possible
to drag from Emacs to another application.  The advantage of dired-dd is
that it works on all platforms.  DND would have to be implemented 
differently
on all Emacs ports (X, Mac, W32).

	Jan D.

Re: Emacs Explorer?

[Richard Stallman]

    The drawback of dired-dd is that it only does local drag and drop, i.e.
    within the same Emacs.  For DND to be useful I think it should be 
    possible to drag from Emacs to another application.

That is definitely desirable.

Meanwhile, have you implemented dropping icons into Dired buffers yet?

Re: Emacs Explorer?

[Jan D.]

>     The drawback of dired-dd is that it only does local drag and drop, 
> i.e.
>     within the same Emacs.  For DND to be useful I think it should be
>     possible to drag from Emacs to another application.
>
> That is definitely desirable.
>
> Meanwhile, have you implemented dropping icons into Dired buffers yet?

Yes, it is in CVS.

	Jan D.

Re: Emacs Explorer?

[Richard Stallman]

    > Meanwhile, have you implemented dropping icons into Dired buffers yet?

    Yes, it is in CVS.

Thank you.

Considering the idea of dragging files OUT of Dired buffers,
I wonder what sort of mouse interface we could come up with that is
(1) consistent with Emacs and (2) consistent with what users
expect in drag-and-drop.

Re: Emacs Explorer?

[Jan D.]

> Considering the idea of dragging files OUT of Dired buffers,
> I wonder what sort of mouse interface we could come up with that is
> (1) consistent with Emacs and (2) consistent with what users
> expect in drag-and-drop.

(2) implemented in other text editors works like this:
Mark some text with the mouse.  Click on the selected text and drag it.

I have a working implementation for GTK (GTK has drag support that makes
this relatively easy), but I guess we want this to work on all toolkits,
then Emacs needs to have its own implementation.
A change I had to make is that Emacs does not clear the mouse selected
region on button down, but on button up, unless there was a drag in 
between.
I've arbitrary defined a drag as moving the mouse 10 pixels.

Other problems are what coding to use for the text (probably 
UTF8_STRING),
and how to recognize that the text dragged is actually a file name from
a dired buffer.  My current implementation has no lisp interface, it is
all done at the C level.

	Jan D.

Re: Emacs Explorer?

[Richard Stallman]

    (2) implemented in other text editors works like this:
    Mark some text with the mouse.  Click on the selected text and drag it.

How can we make that fit into Emacs?  It is inconsistent with the usual
Emacs conventions for mouse clicks.

Re: Emacs Explorer?

[Jan D.]

>     (2) implemented in other text editors works like this:
>     Mark some text with the mouse.  Click on the selected text and 
> drag it.
>
> How can we make that fit into Emacs?  It is inconsistent with the usual
> Emacs conventions for mouse clicks.

Exactly what is inconsistent?  That mouse down does not clear the 
selected
part or that it doesn't set mark, or something else?  Note that it is 
only
when clicking on some selected text and dragging that the behaviour 
differs.
If clicking outside selected text, or not dragging, we can keep the old
behaviour.

Alternativly one can use mouse-2 down and drag for dragging text, but I
find this inconvinient and it doesn't follow the conventions of other
applications like GNOME.

	Jan D.

Re: Emacs Explorer?

[Miles Bader]

On Thu, Apr 22, 2004 at 01:52:39PM +0200, Jan D. wrote:
> Exactly what is inconsistent?  That mouse down does not clear the selected
> part or that it doesn't set mark, or something else?  Note that it is only
> when clicking on some selected text and dragging that the behaviour
> differs.  If clicking outside selected text, or not dragging, we can keep
> the old behaviour.

To tell the truth, I hate the D&D-by-dragging-selected-text behavior of other
apps (in particular, mozilla), because it's damn touchy -- often I'll try to
click to make the selected region collapse, but accidentally drag a _little
bit_, which ends up invoking the D&D behavior...

The same thing happens with other interfaces where dragging vs. clicking
makes a significant difference (e.g., trying to edit the filename of a
selected icon in windows -- _infuriating_!), it just seems like poor design.

-Miles
-- 
97% of everything is grunge

Re: Emacs Explorer?

[Jan D.]

> On Thu, Apr 22, 2004 at 01:52:39PM +0200, Jan D. wrote:
>> Exactly what is inconsistent?  That mouse down does not clear the 
>> selected
>> part or that it doesn't set mark, or something else?  Note that it is 
>> only
>> when clicking on some selected text and dragging that the behaviour
>> differs.  If clicking outside selected text, or not dragging, we can 
>> keep
>> the old behaviour.
>
> To tell the truth, I hate the D&D-by-dragging-selected-text behavior 
> of other
> apps (in particular, mozilla), because it's damn touchy -- often I'll 
> try to
> click to make the selected region collapse, but accidentally drag a 
> _little
> bit_, which ends up invoking the D&D behavior...

I get bitten by this sometimes also.  It is important that the amount 
of drag
is customizable.  Usually it is not.

> The same thing happens with other interfaces where dragging vs. 
> clicking
> makes a significant difference (e.g., trying to edit the filename of a
> selected icon in windows -- _infuriating_!), it just seems like poor 
> design.

This is probably the reason why Motif/CDE uses mouse-2 to drag.  No risk
of starting a drag when an ordinary click with mouse-1 was intended.

	Jan D.

Re: Emacs Explorer?

[Miles Bader]

On Thu, Apr 22, 2004 at 03:20:24PM +0200, Jan D. wrote:
> >To tell the truth, I hate the D&D-by-dragging-selected-text behavior of
> >other apps (in particular, mozilla), because it's damn touchy -- often
> >I'll try to click to make the selected region collapse, but accidentally
> >drag a _little bit_, which ends up invoking the D&D behavior...
> 
> I get bitten by this sometimes also.  It is important that the amount of
> drag is customizable.  Usually it is not.

BTW, the other thing I hate about that behavior is that it makes it annoying
to correct a mouse-selected region that's slightly wrong (e.g., you missed
including the first character) -- you can't just redrag it without thinking,
you have to either make sure to click first (without accidentally dragging),
or start the drag outside the region, which is easy to get wrong.  All of
this makes the re-dragging much slower and more awkward, and it's an
operation I do quite a bit.

The reason I give this example is because a customizable drag-threshhold
wouldn't help -- you _want_ to drag, but you _don't_ want to do D&D.

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: Emacs Explorer?

[Jan D.]

> BTW, the other thing I hate about that behavior is that it makes it 
> annoying
> to correct a mouse-selected region that's slightly wrong (e.g., you 
> missed
> including the first character) -- you can't just redrag it without 
> thinking,
> you have to either make sure to click first (without accidentally 
> dragging),
> or start the drag outside the region, which is easy to get wrong.  All 
> of
> this makes the re-dragging much slower and more awkward, and it's an
> operation I do quite a bit.

I'm not sure I follow.  You extend the region with mouse-3 in Emacs,
so dragging would not enter into it.  However, I see the point if you
for example select qwerty and then descide y should not be part of the
selection.  Then you could first have to click outside the selection
and then redo the drag.  But I use mouse-3 anyway, so it would be the
same for me.  Point taken though.

	Jan D.

Re: Emacs Explorer?

[Kai Grossjohann]

"Jan D." <jan.h.d@swipnet.se> writes:

> I'm not sure I follow.  You extend the region with mouse-3 in Emacs,
> so dragging would not enter into it.

I guess that many people use dragging to select a region.  At least, I
almost always do it that way.  Especially since "double-click
dragging" allows me to select words and "triple-click dragging" allows
me to select lines.

(Double-click dragging means to press, then release, then press again
the mouse1 in quick succession.  Then move the mouse while the mouse
button is pressed.  Then, release the mouse button.)

Kai

Re: Emacs Explorer?

[Jason Rumney]

Jan D. wrote:

>> To tell the truth, I hate the D&D-by-dragging-selected-text 
>> behavior of other apps (in particular, mozilla), because it's damn 
>> touchy -- often I'll try to click to make the selected region 
>> collapse, but accidentally drag a _little bit_, which ends up 
>> invoking the D&D behavior...
> 
> I get bitten by this sometimes also.  It is important that the amount
>  of drag is customizable.  Usually it is not.

I'd say its more important that this type of D&D can be turned off.
Either people are used to doing things this way, with all its faults,
or they are not, and don't want this feature.

> This is probably the reason why Motif/CDE uses mouse-2 to drag.  No 
> risk of starting a drag when an ordinary click with mouse-1 was 
> intended.

We could adopt that convention, but then it would only work within
Emacs, at least on Windows and I presume GTK, Qt and Mac, since the
system idea of dragging would be different than Emacs idea.

Re: Emacs Explorer?

[Jan D.]

>
> I'd say its more important that this type of D&D can be turned off.
> Either people are used to doing things this way, with all its faults,
> or they are not, and don't want this feature.

Agreed.

>
>> This is probably the reason why Motif/CDE uses mouse-2 to drag.  No 
>> risk of starting a drag when an ordinary click with mouse-1 was 
>> intended.
>
> We could adopt that convention, but then it would only work within
> Emacs, at least on Windows and I presume GTK, Qt and Mac, since the
> system idea of dragging would be different than Emacs idea.

The way you start the drag (i.e. mouse-1, shift-mouse-1, mouse-2 e.t.c.)
usually does not matter at all, at least in X.  I would be surprised
if other systems had this limitation.

	Jan D.

RE: Emacs Explorer?

[Drew Adams]

I *hope* I can turn it off.

I understand that some folks like dragging text around within a buffer, but
I wonder how much their use of that "feature" is just habit from using
systems that don't have the mouse functions provided by Emacs.

Those of you who use Emacs and also drag text: What is the advantage? Since
the region is automatically copied to the kill-buffer, and an MB3 click
kills it, and an MB2 click pastes it elsewhere, how could dragging be easier
(than MB1332 or MB1drag32)?  I don't get it.

Again, nothing against your adding it for those who like it - 'long as I can
turn it off.

  - Drew

-----Original Message-----
From: Jason Rumney [mailto:jasonr@gnu.org]
Sent: Thursday, April 22, 2004 7:16 AM
To: Jan D.
Cc: Miles Bader; emacs-devel@gnu.org; rms@gnu.org; drew.adams@oracle.com
Subject: Re: Emacs Explorer?


Jan D. wrote:

>> To tell the truth, I hate the D&D-by-dragging-selected-text
>> behavior of other apps (in particular, mozilla), because it's damn
>> touchy -- often I'll try to click to make the selected region
>> collapse, but accidentally drag a _little bit_, which ends up
>> invoking the D&D behavior...
>
> I get bitten by this sometimes also.  It is important that the amount
>  of drag is customizable.  Usually it is not.

I'd say its more important that this type of D&D can be turned off.
Either people are used to doing things this way, with all its faults,
or they are not, and don't want this feature.

> This is probably the reason why Motif/CDE uses mouse-2 to drag.  No
> risk of starting a drag when an ordinary click with mouse-1 was
> intended.

We could adopt that convention, but then it would only work within
Emacs, at least on Windows and I presume GTK, Qt and Mac, since the
system idea of dragging would be different than Emacs idea.

Re: Emacs Explorer?

[Jan D.]

> Those of you who use Emacs and also drag text: What is the advantage? 
> Since
> the region is automatically copied to the kill-buffer, and an MB3 click
> kills it, and an MB2 click pastes it elsewhere, how could dragging be 
> easier
> (than MB1332 or MB1drag32)?  I don't get it.

What do you mean by MB1332 and MB1drag32?

If we ignore dragging to other applications for now, it is mostly what
you are used to.  Many applications do not paste on MB2, so if you have
the habit of using DND, that is what you like to do.  BTW, MB3 does not
kill the region for me (emacs -q), it extends it.

Then there are other details, like the visual feedback is better for 
DND.
You can often change a copy to a cut/paste or vice versa by a press of a
button when the drag is ongoing.

	Jan D.

RE: Emacs Explorer?

[Drew Adams]

I thought we were talking here about dragging text within Emacs (only). A
previous discussion covered dragging text between applications and dragging
files (in general). Perhaps I'm wrong.

emacs -q: MB1, MB3, MB3 again at *same place* kills region (Emacs 20).

By MB1332, I meant move text using the mouse: click MB1 here, click MB3
there (same buffer - defines region), click MB3 again at same location
(kills region), click MB2 there (anywhere - pastes region). 4 clicks. Forget
I mentioned MB1drag32: my bad - you need to do MB1drag332, which is extra
work.

I saw the argument for providing something folks are already used to outside
Emacs. I just didn't see why this would be favored in Emacs by you folks,
who are used to the Emacs mouse. I thought maybe I was missing something.
Thanks for these reasons: better feedback and converting copy<->cut while
dragging.

 - Drew

-----Original Message-----
From: Jan D. [mailto:jan.h.d@swipnet.se]
Sent: Thursday, April 22, 2004 9:51 AM
To: Drew Adams
Cc: Jason Rumney; Miles Bader; emacs-devel@gnu.org; rms@gnu.org
Subject: Re: Emacs Explorer?


> Those of you who use Emacs and also drag text: What is the advantage?
> Since
> the region is automatically copied to the kill-buffer, and an MB3 click
> kills it, and an MB2 click pastes it elsewhere, how could dragging be
> easier
> (than MB1332 or MB1drag32)?  I don't get it.

What do you mean by MB1332 and MB1drag32?

If we ignore dragging to other applications for now, it is mostly what
you are used to.  Many applications do not paste on MB2, so if you have
the habit of using DND, that is what you like to do.  BTW, MB3 does not
kill the region for me (emacs -q), it extends it.

Then there are other details, like the visual feedback is better for
DND.
You can often change a copy to a cut/paste or vice versa by a press of a
button when the drag is ongoing.

	Jan D.

Re: Emacs Explorer?

[Jan D.]

2004-04-22 kl. 19.43 skrev Drew Adams:

> I thought we were talking here about dragging text within Emacs 
> (only). A
> previous discussion covered dragging text between applications and 
> dragging
> files (in general). Perhaps I'm wrong.
>
> emacs -q: MB1, MB3, MB3 again at *same place* kills region (Emacs 20).
>
> By MB1332, I meant move text using the mouse: click MB1 here, click MB3
> there (same buffer - defines region), click MB3 again at same location
> (kills region), click MB2 there (anywhere - pastes region). 4 clicks. 
> Forget
> I mentioned MB1drag32: my bad - you need to do MB1drag332, which is 
> extra
> work.

But you have to move the mouse after MB1drag33.  So it is really
MB1 drag MB3 MB3 move mouse MB2.

Compare this to DND:  MB1 drag MB3 (defines region).  MB1 down, move 
mouse
and release.
To copy instead of move, hold down Shift (or some other key, Alt on Mac 
OSX),
when releasing MB1.  So your example has four mouse clicks, DND has 
three.
Granted you have to keep the MB1 pressed while moving.  I don't see much
difference here.  But three or four mouse clicks are not important, it 
is
just giving users the possibility to choose whatever they prefer and are
comfortable with.

	Jan D.

Re: Emacs Explorer?

[Richard Stallman]

    >     (2) implemented in other text editors works like this:
    >     Mark some text with the mouse.  Click on the selected text and 
    > drag it.
    >
    > How can we make that fit into Emacs?  It is inconsistent with the usual
    > Emacs conventions for mouse clicks.

    Exactly what is inconsistent?  That mouse down does not clear the 
    selected
    part or that it doesn't set mark, or something else?

Each of the three mouse buttons has another standard meaning in Emacs
which is different from this.  So this is going to be an incompatible
change.

Perhaps use of Mouse-2 is an acceptable incompatible change.
Normally, Mouse-2 in Dired will select the file you clicked on.
Making it do something different when there is a region might be ok.

Re: Emacs Explorer?

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

>     (2) implemented in other text editors works like this:
>     Mark some text with the mouse.  Click on the selected text and drag it.
>
> How can we make that fit into Emacs?  It is inconsistent with the usual
> Emacs conventions for mouse clicks.

IMVHO, a slight deviation from the old behavior is not too terrible,
especially with the right kind of user feedback.  And if it is
possible to turn off the new behavior, then there is no problem at
all.

If the mouse pointer is over a marked region, then it could change to
a hand (or some other icon) to signify that dragging at that spot
would behave differently.  Hm.  But then, when the mouse button is
down, the mouse pointer would have to change again, I think.  That
might be confusing if other programs don't do it that way.

A second alternative would be to highlight the marked region in some
way when the mouse pointer is over it.  (Maybe by putting a border
around it?)  That might give a suitable hint that dragging at that
spot behaves differently.

But what do people think about the visual feedback while dragging
text?  In some editor (I forget which one) I once used I saw that the
text was continually updated to reflect the current paste position.
To illustrate what I mean by this, let uppercase characters indicate
the highlighted region.  Start with the following situation:

FOOabc

Now, drag the text with the mouse one character to the right (and do
NOT release the mouse button).  The display changes like so:

aFOObc

Dragging one more character changes it like this:

abFOOc

Then, after releasing the mouse button, I'm not sure if the
highlighting stays or whether it is removed.

For short highlighted text as in the above example, it might look
cute.  But I think this kind of visual feedback is not practical if
the highlighted text is longer than the window size.

Kai

Re: Emacs Explorer?

[Karl Eichwalder]

Kai Grossjohann <kai@emptydomain.de> writes:

> For short highlighted text as in the above example, it might look
> cute.  But I think this kind of visual feedback is not practical if
> the highlighted text is longer than the window size.

On MacOS X the text to be inserted is a shadowed box container attached
to the mouse pointer and the point in the target window where text
can be dropped is marked with a vertical bar.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: Emacs Explorer?

[Richard Stallman]

    If the mouse pointer is over a marked region, then it could change to
    a hand (or some other icon) to signify that dragging at that spot
    would behave differently.  Hm.  But then, when the mouse button is
    down, the mouse pointer would have to change again, I think.  That
    might be confusing if other programs don't do it that way.

    A second alternative would be to highlight the marked region in some
    way when the mouse pointer is over it.  (Maybe by putting a border
    around it?)  That might give a suitable hint that dragging at that
    spot behaves differently.

These are both good ideas, but we still need to figure out
which mouse click would do this.

Emacs Explorer?

[Drew Adams]

<caveat>blankslate.bluesky.don'tfreak.justwhatif.ifdupdelete</caveat>

Here's a set of assertions, some of which might solicit worthwhile
discussion in the context of Emacs development. (Or not.)

1. Windows Explorer is the (min (best | only good)) part of Windows.
2. Dired does some similar things to what Windows Explorer does.
3. Dired does more than Windows Explorer.
4. Windows Explorer does more than Dired.
5. We should add some of the handy-dandy Windows-Explorer features to Dired.
6. A folder forest a la tree-widget (but with drag & drop?) would be a great
start.
7. Not only a folder forest, but also things like different display options
(a la WE View>Details etc. and View>Choose Details). Some of the default
dired-listing-switches stuff, like user & group, is not the most useful
stuff to see most of the time (yes, I know I can change
dired-listing-switches, TYVM).
8. We should add column headings to Dired.
9. Users should be able to click Dired column headings to sort by them.


I'm not acquainted with the current work on Dired, so forgive me if this is
redundant or has already been beat to death.

I just really appreciate both Dired and Windows Explorer - each for what it
does best, and I would love to see some of the Windows-Explorer features
added to Dired.

  - Drew

FYI - I've added a couple of the really *minor* Windows-Explorer features to
my own dired:

 . To select multiple files, you can click MB1 then Shift-click MB1, or just
MB1-drag a region.
 . Context-dependent MB3 popup menu (operates on all files in the region or
the single pointed file).
 . Windows file associations (for MB2 click).

Re: Emacs Explorer?

[Richard Stallman]

    5. We should add some of the handy-dandy Windows-Explorer features to Dired.
    6. A folder forest a la tree-widget (but with drag & drop?) would be a great
    start.

I like the idea of giving Dired both concise and expanded modes, a la
directory browsers.  Using tree-widget for each subdirectory might
be a good idea once tree-widget is in Emacs.

    8. We should add column headings to Dired.

Say what?

RE: Emacs Explorer?

[Drew Adams]

Not sure if you just wanted clarification or were being sarcastic.

Just in case it was the former: All I meant was that we could provide
headings to the various (ls, for now) columns in Dired, for 1) clarification
and 2) manipulation (sorting). If this is already the case for Emacs 21,
then ignore. For example:

Privileges Links User    Group   Size  Date Modified Name
---------- ----- ----    -----   ----  ------------- ----
-rw-r--r--    1  dradams svrtech 13525 Apr  6 08:45  shrink-fit.el

In Windows Explorer:
 . Privileges is called Attributes, and it is different from Unix file
privileges.
 . There are no Links or Group (or Inode etc.) `ls' columns.

More importantly, users should be able to click a column heading to sort by
that column (alternately ascending/descending) - just as in Windows
Explorer.

A folder forest needs to be given significant functionality. The WE version
offers quite a lot.

Windows Explorer is a good model to copy, in general, though Emacs could no
doubt do even better. We should at least *aim* at all you can do in WE.
There is a *lot* there to use as food for thought, including easy
customization (dragging columns around, swapping the folder forest for
search or other panels, various view modes, selection pop-up menus, etc. To
my mind, WE really is the best thing Windows has come up with.

 - Drew

-----Original Message-----
From: Richard Stallman [mailto:rms@gnu.org]
Sent: Wednesday, April 14, 2004 3:54 PM
To: Drew Adams
Cc: emacs-devel@gnu.org
Subject: Re: Emacs Explorer?


    5. We should add some of the handy-dandy Windows-Explorer features to
Dired.
    6. A folder forest a la tree-widget (but with drag & drop?) would be a
great
    start.

I like the idea of giving Dired both concise and expanded modes, a la
directory browsers.  Using tree-widget for each subdirectory might
be a good idea once tree-widget is in Emacs.

    8. We should add column headings to Dired.

Say what?

Re: Emacs Explorer?

[Richard Stallman]

    Not sure if you just wanted clarification or were being sarcastic.

I was serious.  I did not understand what feature you meant.
Your explanation is clear and now I understand.

    Just in case it was the former: All I meant was that we could provide
    headings to the various (ls, for now) columns in Dired, for 1) clarification
    and 2) manipulation (sorting). If this is already the case for Emacs 21,
    then ignore. For example:

    Privileges Links User    Group   Size  Date Modified Name
    ---------- ----- ----    -----   ----  ------------- ----
    -rw-r--r--    1  dradams svrtech 13525 Apr  6 08:45  shrink-fit.el

I guess this could be done with a header line.

    More importantly, users should be able to click a column heading to sort by
    that column (alternately ascending/descending) - just as in Windows
    Explorer.

That doesn't sound too hard.