[doug@bagley.org: Re: mouse-1-click-follows-link in dired surprising]

[doug@bagley.org: Re: mouse-1-click-follows-link in dired surprising]

[Richard Stallman]

Bagley argues that the file names in dired should be highlighted as links
so as to avoid surprise.

What do others think?

------- Start of forwarded message -------
To: rms@gnu.org
Subject: Re: mouse-1-click-follows-link in dired surprising
From: Doug Bagley <doug@bagley.org>
Organization: Hana no Chikara Zaibatsu
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon,  3 Jul 2006 16:02:38 -0500 (CDT)
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

Richard Stallman <rms@gnu.org> writes:
> You could try editing the code in Dired to highlight all the file names.
> Does that help you, do you find?

Yes, somewhat. I did a quick experiment of overriding
dired-insert-set-properties to have it set a font-lock-face. It's too
inelegant for a real solution, but I did like the additional visual
information indicting that the filenames were links. 

- -Doug
------- End of forwarded message -------

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in dired surprising]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Bagley argues that the file names in dired should be highlighted as links
> so as to avoid surprise.
>
> What do others think?

I think it would be ugly and distracting.

> From: Doug Bagley <doug@bagley.org>
> Subject: Re: mouse-1-click-follows-link in dired surprising
> To: rms@gnu.org
>
> Richard Stallman <rms@gnu.org> writes:
>> You could try editing the code in Dired to highlight all the file names.
>> Does that help you, do you find?
>
> Yes, somewhat. I did a quick experiment of overriding
> dired-insert-set-properties to have it set a font-lock-face. It's too
> inelegant for a real solution, but I did like the additional visual
> information indicting that the filenames were links. 
>
> - -Doug
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]

    Bagley argues that the file names in dired should be
    highlighted as links so as to avoid surprise.
    What do others think?

If by that you mean `face' highlighting, in addition to `mouse-face',
definitely *not*.

I've said before, and I'll say again:

There are buffers (Dired, *Buffer List*, *grep*, *Occur*,...) that are
link-dense (or potentially so). In addition, the text that is linked is
regular in appearance - for example, a table, each of whose entries is
linked. In most cases (all of the cases just cited), even if the table has
more than one column, there is only one link per row.

For such buffers:

1) We should *not* highlight the links (except via mouseover). The links are
known or predictable by virtue of the regularity of their positions.
Highlighting the links in such a buffer hinders, it does not help,
orientation and navigation.

2) When tabular (regular) buffers have only one link per row, regardless of
how many table columns there are, we should put the *mouse-face on the
entire row*, not just one of the columns (e.g. file name in Dired). That
lets you click anywhere on the row. You can keep your eye on a particular
column, because that is what you want to scan/read, and yet you can click
anywhere on the row (usually a single line). There is no need to put the
mouse exactly where you are looking. And you can move the mouse up and down,
highlighting different rows, without worrying about keeping the mouse within
a column. In particular, you can move the mouse vertically at the right
edge, without having mouseover highlighting skip over short rows.

The attached screenshot of Dired shows what I mean: you can click anywhere
on the row, and there is no `face' highlighting of links (there is only
`mouse-face' highlighting).

Full-row mouse highlighting also helps with visual alignment, when columns
of interest are far apart or are separated by empty entries. The principal
here is that of using a ruler with a parts list or catalog: the highlighting
helps you see everything that is in the same row. When a table row is
multi-line this is even more important: the highlighting shows what
constitutes a row.

Note that it is not only the density of links that determines whether the
above guidelines apply. The buffer must also be regular, so that users
already know where the links are. The link density causes the user to
discover the links (the mouse inevitably hits a link, showing it by
mouse-face and finger pointer). The tabular regularity lets the user predict
the link positions. A buffer that is dense in links but not regular -
Customize, perhaps - does not fit the guidelines: its links should be
highlighted with `face', not only `mouse-face', to help users find them.

Also, a buffer such as Dired that is tabular (regular) with a single link
per row is a candidate for these guidelines, even if it doesn't appear to be
very link-dense currently (with only one column linked). IOW, applying the
second guideline will make buffers like Dired link-dense. This increases
usability, (letting you click anywhere on a row and use mouseover to
highlight a row).

What about tabular data that has more than one link per row?
`list-faces-display' is an example of this. In this case, the first
guideline applies, but the second does not. Each linked entry (i.e. in each
column) should have mouse-face highlighting, but not face highlighting (it
DTRT currently).

If a buffer happened to have multiple columns, more than one of which is
linked, some adjacent columns could be mouse-face highlighted together, for
convenience. IOW, it could be convenient in some cases to join multiple
adjacent columns wrt linking and mouse-face. Imagine, for instance, if Dired
had an additional first column "More Info" that linked a Dired entry to a
buffer of additional information about the file. In that case, a row could
have two links (with mouse-face): one for column More Info and the other for
all of the other columns combined (~guideline #2).

I've never been able to convince anyone else on this score. Trying again...

Please don't `face' highlight links in Dired; mouseover is enough.

P.S. To come back to the OP - `mouse-1-click-follows-link' is a nuisance for
link-dense buffers (whether regular or not). I turn it off (nil). IMO, it
should be off by default in such buffers.

[-- Attachment #2: dired-mouseover.jpg --]
[-- Type: image/jpeg, Size: 53552 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

"Drew Adams" <drew.adams@oracle.com> writes:
> 1) We should *not* highlight the links (except via mouseover). The links are
> known or predictable by virtue of the regularity of their positions.
> Highlighting the links in such a buffer hinders, it does not help,
> orientation and navigation.

I generally agree with Drew on this -- in very "link dense" buffers,
excessive highlighting can be more annoying than helpful.

In the case of dired, however, there is a slight problem (especially
with recent verions of GNU ls[*]) with visually separating the filename
from the file-info on the same line.  Perhaps it would be a good idea to
give the _other_ fields (date, etc) a slightly different face to
de-emphasize them a bit?

[*] Because of GNU ls's current "shrink to fit" behavior, unfortunately
most fields end up with only a single space separating them, which is
really not enough.  An alternative solution to de-emphasizing the
non-name info might be to post-process the ls output to at least insert
a bit more whitespace before the filename.


Here are some pics showing the the current dired appearance, and dired
with non-filename info de-emphasized:

[The face I used for de-emphasis in these pics is "grey80", which is
fairly conservative -- it's almost as bright as normal text -- but still
seems to make big difference in readability.]



[-- Attachment #2: Current dired appearance --]
[-- Type: image/png, Size: 87623 bytes --]

[-- Attachment #3: Dired with non-filename info de-emphasized --]
[-- Type: image/png, Size: 48201 bytes --]

[-- Attachment #4: Type: text/plain, Size: 243 bytes --]



-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Dired coloring and other conveniences

[Drew Adams]

    > 1) We should *not* highlight the links (except via mouseover).
    > The links are known or predictable by virtue of the regularity
    > of their positions. Highlighting the links in such a buffer
    > hinders, it does not help, orientation and navigation.

    I generally agree with Drew on this -- in very "link dense" buffers,
    excessive highlighting can be more annoying than helpful.

    In the case of dired, however, there is a slight problem (especially
    with recent verions of GNU ls[*]) with visually separating the filename
    from the file-info on the same line.  Perhaps it would be a good idea to
    give the _other_ fields (date, etc) a slightly different face to
    de-emphasize them a bit?
    Here are some pics...

Not bad.

I tend to be interested in some of the things in other columns, at least
some of the time. When I'm not interested, I remove the other columns
altogether - see below. As you can see from the screenshot I sent earlier, I
give each column its own face, except for uninteresting files like .elc, for
which I use the same, dull face for the whole line.

Because (on Unix or GNU/Linux) I want to quickly see if a file has different
permissions from the others in a directory, I use different colors for each
permission. Similarly, I use a different face for the file suffix, and I
color a trailing `*' red to show that a file is executable. (I use -alF for
dired-listing-switches, to get the `*').

One of the tweaks I really like for Dired is `dired-details', a library by
Rob Giardina. I have my own minor enhancement, `dired-details+.el'. By
hitting a key, I can toggle between showing only the file names or
everything. Especially on Windows, much of the time I am not interested in
more than the file names. Since I use one buffer per frame, and I
automatically resize frames, not showing the other columns saves a lot of
real estate and visual noise. The effect is modal: subsequent Dired buffers
use the last setting (open to all columns or closed to just file names). A
minor tweak, but surprisingly convenient. I often go days without showing
more than the file names. Or, I sometimes take a peek by hitting my toggle
key, and then hit it again to get back to a "leaner" Dired. Or, I show all
columns in one Dired buffer, but limit the others to file names.

If you're interested, both dired-details.el and dired-details+.el are
available here:
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.el%28%5C.gz%29%
3F.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Richard Stallman]

    I generally agree with Drew on this -- in very "link dense" buffers,
    excessive highlighting can be more annoying than helpful.

    In the case of dired, however, there is a slight problem (especially
    with recent verions of GNU ls[*]) with visually separating the filename
    from the file-info on the same line.  Perhaps it would be a good idea to
    give the _other_ fields (date, etc) a slightly different face to
    de-emphasize them a bit?

What's the difference between putting a different face on the file
names and putting a different face on everything but the file names?
Either way, the file names have one face and the rest of the text has
another.  They seem like two ways of describing the same situation.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     In the case of dired, however, there is a slight problem (especially
>     with recent verions of GNU ls[*]) with visually separating the filename
>     from the file-info on the same line.  Perhaps it would be a good idea to
>     give the _other_ fields (date, etc) a slightly different face to
>     de-emphasize them a bit?
>
> What's the difference between putting a different face on the file
> names and putting a different face on everything but the file names?
> Either way, the file names have one face and the rest of the text has
> another.  They seem like two ways of describing the same situation.

It depends on the faces...  Some faces are more "in your face" than
others.  The link face is intentionally rather attention grabbing (both
because of its appearance and because of its well-known meaning), which
works well if you want to highlight a link in the midst of normal text,
but is annoying when overused.

My point was that it would be good to _slightly_ distinguish between the
filenames and othe rest of the text, but that using a link face was
excessive.

In general, I think that it's good when the "meat" of the buffer is in
the default face, and faces used to either emphasize or de-emphasize
other stuff as appropriate.  In the case of dired buffers, the filenames
are "the meat".

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Richard Stallman]

    My point was that it would be good to _slightly_ distinguish between the
    filenames and othe rest of the text, but that using a link face was
    excessive.

I take your point.  At the same time, using a link face will show
that these act as links.

With good arguments on both sides, I don't have a strong opinion about
this.  But I wonder: could we make the normal link face a little
less obtrusive, such that it would still do its job, but would also
be ok for file names in Dired?

Or could we come up with a toned-down link-like face to use in Dired?

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Luc Teirlinck]

Richard Stallman wrote:

   I take your point.  At the same time, using a link face will show
   that these act as links.

Faces are _already_ used in Dired to distinguish between various kinds
of files and this is important.  File names in Dired do not act as
links.  Following a link shows something else in the same window.
But mouse-2 on a file name in Dired visits the file in _another_ window.
mouse-1 should just set point on a file name, since file names are not links.

Sincerely,

Luc.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Luc Teirlinck]

>From my previous reply:

   But mouse-2 on a file name in Dired visits the file in _another_ window.

Which is different from what RET does.  For normal links in Emacs,
mouse-2 has the same behavior as RET.

Sincerely,

Luc.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Luc Teirlinck]

Richard Stallman wrote:

   I take your point.  At the same time, using a link face will show
   that these act as links.

There is a tooltip telling _exactly_ what mouse-1 will do (which I
believe is different from what people would expect from a link: same
behavior as RET).  A link face would not eliminate surprise for people
who fail to pay any attention to the tooltip and it would override the
current faces, which are very important for efficient use of Dired.

Sincerely,

Luc.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Richard Stallman]

      Following a link shows something else in the same window.

Not necessarily.

Re: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]

[Richard Stallman]

      A link face would not eliminate surprise for people
    who fail to pay any attention to the tooltip

We know of at least one example of a person for whom this is not so.

						 and it would override the
    current faces

Not at all.  Once face does not override another; the attributes are
merged.

dired-details: show/hide file details in Dired

[Drew Adams]

Dired Details lets you toggle the display of file details in Dired. When
off, it looks a bit like speedbar, but it is still a fully functioning Dired
buffer. If the author, Rob Giardina, agrees, how about including this in
Emacs?

> From: Drew Adams Sent: Tuesday, July 04, 2006 8:42 PM
> Subject: Dired coloring and other conveniences
> One of the tweaks I really like for Dired is `dired-details', a library by
> Rob Giardina. I have my own minor enhancement, `dired-details+.el'.
> both dired-details.el and dired-details+.el are available here:
>
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.el%28%5C.gz%29%
3F.

Description with screenshots:
http://www.emacswiki.org/cgi-bin/wiki/DiredDetails

Re: dired-details: show/hide file details in Dired

[Mathias Dahl]

> Dired Details lets you toggle the display of file details in Dired. When
> off, it looks a bit like speedbar, but it is still a fully functioning Dired
> buffer. If the author, Rob Giardina, agrees, how about including this in
> Emacs?

I sometimes would have liked to hide parts of the details. For example
I quite often want to see the file size and dates but very seldom the
permissions. Also, for those, like me, that does not use separate
frames, it would be useful if the dired window was split vertically to
use the extra space, maybe something like follow-mode maybe?

How does these extensions work together with wdired.el?

RE: dired-details: show/hide file details in Dired

[Drew Adams]

> > Dired Details lets you toggle the display of file details in Dired. When
> > off, it looks a bit like speedbar, but it is still a fully
> > functioning Dired buffer. If the author, Rob Giardina, agrees, how
> > about including this in Emacs?
>
> I sometimes would have liked to hide parts of the details. For example
> I quite often want to see the file size and dates but very seldom the
> permissions.

This does not cater to that currently. That might be a useful enhancement.

Personnally, I don't usually want to see such info on a continual basis.
When I want to see it, I toggle briefly to see it, then go back to showing
no details. If there is a use case for continually showing a subset of the
information, that could perhaps be added as an enhancement.

> Also, for those, like me, that does not use separate
> frames, it would be useful if the dired window was split vertically to
> use the extra space, maybe something like follow-mode maybe?

`C-x 3', then Dired?

Oh, I see, you want two or more columns for Dired, right? Yes, you can do
that too: `M-x follow-mode' + `C-x 3' (repeat `C-x 3' as needed). (The
toggle, however, acts on all of the Dired windows, not just one.)

> How does these extensions work together with wdired.el?

Dunno. Give it a try ;-).

add directory selection to the "compile" command

[lucatrv]

Hi, sometimes I work on projects with many subfolders, so every time I issue 
the "compile" command whether I first have to change to the main folder 
(where the makefile is) or I have to manually change the commmand depending 
on the present buffer folder (such as "cd ../../.. && make -k") .
I think it would be very helpfull to add to the "compile" command the 
possibility to specify the directory where the command should be executed. 
The directory should be stored for successive times.
So for instance, the first time someone issues the "compile" command, the 
default directory could be the present directory, while the default command 
could be "make -k". Then, if for instance the user sets another directory 
(such as "/home/user/projectmaindir") and another command (such as "make"), 
then those should be set for successive "compile" command issues.

Please let me know your opinion about this. Unfortunatelly, although I tried 
to obtain something like this, my knowledge of elisp is not good enough to 
implement this.

Luca 

Re: dired-details: show/hide file details in Dired

[Rob Giardina]

Hi Drew,

It's been a while, hope you're well. I'm game to have this included,  
I would be happy to have it when using a bare emacs.

There was a patch for 2005-07-07 CVS that was approved by RMS which I  
can send or update if anyone is interested. I went on vacation and  
got back too late to update the docinfo as requested; should be easy  
to update for modern dired.el.

-Rob

On Jul 2, 2007, at 1:42 AM, Drew Adams wrote:

> Dired Details lets you toggle the display of file details in Dired.  
> When
> off, it looks a bit like speedbar, but it is still a fully  
> functioning Dired
> buffer. If the author, Rob Giardina, agrees, how about including  
> this in
> Emacs?
>
>> From: Drew Adams Sent: Tuesday, July 04, 2006 8:42 PM
>> Subject: Dired coloring and other conveniences
>> One of the tweaks I really like for Dired is `dired-details', a  
>> library by
>> Rob Giardina. I have my own minor enhancement, `dired-details+.el'.
>> both dired-details.el and dired-details+.el are available here:
>>
> http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.el%28% 
> 5C.gz%29%
> 3F.
>
> Description with screenshots:
> http://www.emacswiki.org/cgi-bin/wiki/DiredDetails
>

Re: add directory selection to the "compile" command

[Denis Bueno]

On 07/02/2007 08:02, "lucatrv" <lucatrv@hotmail.com> wrote:

> Hi, sometimes I work on projects with many subfolders, so every time I issue
> the "compile" command whether I first have to change to the main folder
> (where the makefile is) or I have to manually change the commmand depending
> on the present buffer folder (such as "cd ../../.. && make -k") .

Using M-x recompile after the first M-x compile may solve your problem.  M-x
recompile remembers the last compile-command and default-directory.

I frequently work like this:

  - switch to Makefile directory
  - M-x compile RET
  - begin edit-recompile-cycle loop:
    * edit
    * M-x recompile RET
    * goto edit-recompile-cycle

-Denis

Re: dired-details: show/hide file details in Dired

[Mathias Dahl]

> Personnally, I don't usually want to see such info on a continual basis.
> When I want to see it, I toggle briefly to see it, then go back to showing
> no details. If there is a use case for continually showing a subset of the
> information, that could perhaps be added as an enhancement.

My use cases are when I want to see the newest files in a directory.
Then I often sort by date and also look at files "grouped" by a
certain date, to identify batches of downloaded files. I often uses
the file size in combination with `g' to keep track of a file
download, if it is done or not. But I almost never use the part with
the permissions and user and group name.

> Oh, I see, you want two or more columns for Dired, right? Yes, you can do
> that too: `M-x follow-mode' + `C-x 3' (repeat `C-x 3' as needed). (The
> toggle, however, acts on all of the Dired windows, not just one.)

I tried that and it seems to work OK. What I was thinking was that
similar to how your frames shrink, Dired could split the window and
show more when you got space back from hiding details. However, maybe
that would be annoying... :)

> > How does these extensions work together with wdired.el?
>
> Dunno. Give it a try ;-).

Maybe I will, maybe I will... :)

RE: dired-details: show/hide file details in Dired

[Drew Adams]

> > `M-x follow-mode' + `C-x 3' (repeat `C-x 3' as needed).
>
> I tried that and it seems to work OK. What I was thinking was that
> similar to how your frames shrink, Dired could split the window and
> show more when you got space back from hiding details. However, maybe
> that would be annoying... :)

I agree that it could be good to automatically expand and contract the
current Dired window or windows (just as I do with the frame), provided that
a user agrees with that behavior via an option (somewhere). I have not
implemented that - patches welcome ;-).

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    There was a patch for 2005-07-07 CVS that was approved by RMS which I  
    can send or update if anyone is interested. I went on vacation and  
    got back too late to update the docinfo as requested; should be easy  
    to update for modern dired.el.

Now is a good time to install it.  Can you update it for the current
dired.el, and send it with a change log?

RE: dired-details: show/hide file details in Dired

[Drew Adams]

>     There was a patch for 2005-07-07 CVS that was approved by RMS
>     which I can send or update if anyone is interested. I went on
>     vacation and got back too late to update the docinfo as
>     requested; should be easy to update for modern dired.el.
>
> Now is a good time to install it.  Can you update it for the current
> dired.el, and send it with a change log?

How about also installing the enhancements provided by dired-details+.el?

The frame-fitting enhancement need not be applied, since Emacs does not yet
have my frame-fitting code. But I think some of the other enhancements could
be integrated. They are:

1. Update the hide/show overlays automatically whenever you create new files
or directories or rename existing files or directories. This means tweaking
the definitions of `dired-byte-compile', `dired-compress',
`dired-create-files' and `dired-create-directory' (instead of advising
them).

2. Provide a user option, `dired-details-propagate-flag' which, if non-nil,
propagates the last hide/show state you chose to the next Dired buffer you
open.

I also recommend:

1. Binding the toggle command to a key, such as `)'.

2. Using "" as the default value of `dired-details-hidden-string', to save
screen real estate.

Re: dired-details: show/hide file details in Dired

[Rob Giardina]

I will merge the patch with modern dired and bring in as many dired- 
details+ features as is feasible.
I'll get in touch with you Drew if I have problems integrating any +  
features.

-rob

On Jul 2, 2007, at 6:53 PM, Drew Adams wrote:

>>     There was a patch for 2005-07-07 CVS that was approved by RMS
>>     which I can send or update if anyone is interested. I went on
>>     vacation and got back too late to update the docinfo as
>>     requested; should be easy to update for modern dired.el.
>>
>> Now is a good time to install it.  Can you update it for the current
>> dired.el, and send it with a change log?
>
> How about also installing the enhancements provided by dired-details 
> +.el?
>
> The frame-fitting enhancement need not be applied, since Emacs does  
> not yet
> have my frame-fitting code. But I think some of the other  
> enhancements could
> be integrated. They are:
>
> 1. Update the hide/show overlays automatically whenever you create  
> new files
> or directories or rename existing files or directories. This means  
> tweaking
> the definitions of `dired-byte-compile', `dired-compress',
> `dired-create-files' and `dired-create-directory' (instead of advising
> them).
>
> 2. Provide a user option, `dired-details-propagate-flag' which, if  
> non-nil,
> propagates the last hide/show state you chose to the next Dired  
> buffer you
> open.
>
> I also recommend:
>
> 1. Binding the toggle command to a key, such as `)'.
>
> 2. Using "" as the default value of `dired-details-hidden-string',  
> to save
> screen real estate.
>

Re: dired-details: show/hide file details in Dired

[Stefan Monnier]

> How about also installing the enhancements provided by dired-details+.el?

These can be addressed separately afterwards, so let's just wait.


        Stefan

RE: dired-details: show/hide file details in Dired

[Drew Adams]

> > How about also installing the enhancements provided by
> > dired-details+.el?
>
> These can be addressed separately afterwards, so let's just wait.

Why? What's the hurry for one but not the other? Do you have an objection to
a particular enhancement?

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    How about also installing the enhancements provided by dired-details+.el?

Once dired-details.el is installed, please post a copy
and we can think about which of its features we want to install.

    1. Update the hide/show overlays automatically whenever you create new files
    or directories or rename existing files or directories. This means tweaking
    the definitions of `dired-byte-compile', `dired-compress',
    `dired-create-files' and `dired-create-directory' (instead of advising
    them).

That sounds useful.  What precisely are the "hide/show overlays", though?
Which feature uses them?  Is that something in dired-details?

    2. Provide a user option, `dired-details-propagate-flag' which, if non-nil,
    propagates the last hide/show state you chose to the next Dired buffer you
    open.

I would rather not install that.

Re: dired-details: show/hide file details in Dired

[Rob Giardina]

I planned to install Drew's tweaks so that the natural dired behavior  
worked more elegantly; I didn't handle some cases related to updates  
to a dired buffer and Drew's changes fixed that.

On Jul 3, 2007, at 11:43 PM, Richard Stallman wrote:

>     How about also installing the enhancements provided by dired- 
> details+.el?
>
> Once dired-details.el is installed, please post a copy
> and we can think about which of its features we want to install.
>
>     1. Update the hide/show overlays automatically whenever you  
> create new files
>     or directories or rename existing files or directories. This  
> means tweaking
>     the definitions of `dired-byte-compile', `dired-compress',
>     `dired-create-files' and `dired-create-directory' (instead of  
> advising
>     them).
>
> That sounds useful.  What precisely are the "hide/show overlays",  
> though?
> Which feature uses them?  Is that something in dired-details?

That's the heart of dired-details. It's just a loop over the lines of  
ls -l output to make the hairy parts invisible using an overlay.

>     2. Provide a user option, `dired-details-propagate-flag' which,  
> if non-nil,
>     propagates the last hide/show state you chose to the next Dired  
> buffer you
>     open.
>
> I would rather not install that.

I was going to look at that more closely to see if there's anything  
risky about it. If it's just a flag I was going to add it but in the  
interests of harmony I could wait.

-rob

RE: dired-details: show/hide file details in Dired

[Drew Adams]

>     How about also installing the enhancements provided by
>     dired-details+.el?
>
> Once dired-details.el is installed, please post a copy
> and we can think about which of its features we want to install.

I already posted a copy, here:
http://www.emacswiki.org/cgi-bin/wiki/dired-details%2b.el.

>     1. Update the hide/show overlays automatically whenever you
>        create new files or directories or rename existing files
>        or directories. This means tweaking the definitions of
>        `dired-byte-compile', `dired-compress',
>        `dired-create-files' and `dired-create-directory' (instead
>        of advising them).
>
> That sounds useful.  What precisely are the "hide/show overlays", though?
> Which feature uses them?  Is that something in dired-details?

Yes. dired-details uses "an invisible, evaporable overlay for each
file-line's details", to quote the doc string of `dired-details-hide'.

AFAICT, this dired-details+ feature corresponds to the only TODO item in
dired-details: "add a hook for dired-add-file to hide new entries as
necessary". Without this feature, any of the changes mentioned (e.g. adding
a file) results in a full, detailed display of the target file, instead of
keeping its display in sync with the rest of the Dired buffer (details
hidden or shown).

The dired-details+ code (like the dired-details code) uses defadvice. If
this display-sync feature is added to Emacs, then the following code or
equivalent would need to be added at the end of each of the functions
mentioned, to be able to get rid of the defadvice that implements this
feature:

 (dired-details-delete-overlays)
 (dired-details-activate)

Suitably guarded by `fboundp' or `featurep', perhaps, so that it is used
only with dired-details. All this code does is update the buffer display, to
synchronize it for the target files.

>     2. Provide a user option, `dired-details-propagate-flag'
>        which, if non-nil, propagates the last hide/show state
>        you chose to the next Dired buffer you open.
>
> I would rather not install that.

In that case, then that should be the only behavior, IMO, not what is
defined in dired-details.el. That is, if you don't want to have a user
option for this, then IMO the behavior should be to let the hide/show
toggling affect future Dired buffers, instead of them all defaulting to the
same initial state. The toggle is still local, so display of existing Dired
buffers is not affected, but if you open Dired on other directories (e.g.
subdirs or parent dirs), then the current display state (hidden or shown) is
used (instead of some default state).

In my use, at least, this makes more sense, because it requires a lot less
toggling. Typically, if I currently want to hide (show) details in some
Dired buffer, then I probably want to do the same in the next Dired buffer I
open. It is not the case that I always want to start every Dired buffer in
the same default state. Without this modal behavior, you need to toggle more
often or you need to periodically re-customize the default state. The user's
current display state is a better guide to how s?he wants the next Dired
buffer to be displayed than is some default value.

I also recommend that the empty string (instead of "[...]") be used as the
default value of the hidden string (used for the overlay). For one thing, it
saves screen real estate. For another thing, it makes window and frame
fitting easier and more accurate. For another thing, someone who uses
dired-details will not need a "[...]" reminder that there is hidden text
present - that's pretty useless, IMO. If you are keen on not multiplying
user options, then I'd say just hard-code this as the empty string.

That sums up the tweaks that dired-details+ makes to dired-details. There
are only a few dozen lines of code in the file.

Re: dired-details: show/hide file details in Dired

[Robert J. Chassell]

"Drew Adams" wrote, 

    I already posted a copy, here:
    http://www.emacswiki.org/cgi-bin/wiki/dired-details%2b.el.

RMS and many others are not going to go to a Web site when they lack the
time even to read the emacs-devel mailing list thoroughly.  You are
excluding yourself by not posting your proposal.

Indeed, for many (including me, as it happens) going to a Web site is
sometimes difficult and time consuming, sometimes illegal, and sometimes
impossible.

You may have different experiences, but it is worth remembering
others'.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: dired-details: show/hide file details in Dired

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

>     http://www.emacswiki.org/cgi-bin/wiki/dired-details%2b.el.
> 
> RMS and many others are not going to go to a Web site

Attached.

[-- Attachment #2: dired-details+.el --]
[-- Type: application/octet-stream, Size: 8720 bytes --]

;;; dired-details+.el --- Enhancements to library `dired-details+.el'.
;; 
;; Filename: dired-details+.el
;; Description: Enhancements to library `dired-details+.el'.
;; Author: Drew Adams
;; Maintainer: Drew Adams
;; Copyright (C) 2005-2007, Drew Adams, all rights reserved.
;; Created: Tue Dec 20 13:33:01 2005
;; Version: 
;; Last-Updated: Fri Jan 19 20:59:48 2007 (-28800 Pacific Standard Time)
;;           By: dradams
;;     Update #: 141
;; URL: http://www.emacswiki.org/cgi-bin/wiki/dired-details+.el
;; Keywords: dired, frames
;; Compatibility: GNU Emacs 20, GNU Emacs 22
;; 
;; Features that might be required by this library:
;;
;;   `autofit-frame', `avoid', `dired-details', `fit-frame',
;;   `frame-cmds', `frame-fns', `misc-fns', `strings', `thingatpt',
;;   `thingatpt+'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Commentary: 
;; 
;;  This enhances the functionality of library `dired-details.el'.
;;
;;  1. It shrink-wraps Dired's frame whenever you show or hide
;;     details.  For this enhancement, you will need library
;;     `autofit-frame.el'.
;;
;;  2. It advises `dired-byte-compile', `dired-compress',
;;     `dired-create-files' and `dired-create-directory', so that
;;     whenever you create new files or directories or rename them the
;;     hide/show overlays are updated accordingly.
;;
;;  3. It adds user option `dired-details-propagate-flag' which, if
;;     non-nil, propagates the last state you chose to the next Dired
;;     buffer you open.
;;
;;  4. It binds both `)' and `(' to `dired-details-toggle'.
;;
;;  Perhaps #2 corresponds to this TO-DO item in `dired-details.el':
;;
;;    * add a hook for dired-add-file to hide new entries as necessary
;;
;;
;;  ***** NOTE: The following function defined in `dired-details.el'
;;              has been REDEFINED HERE:
;;
;;  `dired-details-activate' - If `dired-details-propagate-flag' is
;;                             non-nil, then use the last state.
;;
;;  ***** NOTE: The following functions defined in `dired-aux.el' have
;;              been REDEFINED HERE (advised only):
;;
;;  `dired-byte-compile', `dired-compress', `dired-create-files',
;;  `dired-create-directory' - Update overlays.
;;
;;
;;  I have submitted these enhancements to Rob Giardina, the author of
;;  `dired-details.el', for inclusion in that library.  When they (or
;;  similar) are added to that library, I'll remove this library.
;;
;;  Put this in your initialization file (~/.emacs):
;;
;;   (require 'dired-details+)
;;
;;  I also recommend customizing `dired-details-hidden-string' to use
;;  the value "" instead of the default "[...]" - less wasted space.
;;
;;  Note: This library also calls `dired-details-install', activating
;;  show/hide and binding keys `(' and `)'.
;;    
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Change log:
;; 
;; 2006/02/02 dadams
;;     Bind both ) and ( to dired-details-toggle.
;; 2006/01/02 dadams
;;     Advised dired-byte-compile and dired-compress.
;; 2006/01/01 dadams
;;     Advised dired-create-directory.
;; 2005/12/30 dadams
;;     Advised dired-create-files.
;;     dired-details-(show|hide): Only fit frame if it's showing Dired.
;; 2005/12/26 dadams
;;     Updated groups.
;; 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;; 
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;; 
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; ;; Floor, Boston, MA 02110-1301, USA.
;; 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Code:

;;; Do this `defcustom' first, before we load `dired-details', so we
;;; don't pick up the `defcustom' there.  The default value here is
;;; the empty string, so the overlay doesn't give a false impression
;;; of the current column number.  This is important for frame fitting
;;; (see library `fit-frame.el', required by `autofit-frame.el').
(defcustom dired-details-hidden-string ""
  "*This string will be shown in place of file details and symbolic links."
  :group 'dired-details :group 'dired
  :type 'string)

(require 'dired-details nil t) ;; (no error if not found): dired-details-hide,
                               ;; dired-details-install, dired-details-show
(require 'autofit-frame nil t) ;; (no error if not found): fit-frame-if-one-window

;;;;;;;;;;;;;;;;;;;;;;;;;;


(defcustom dired-details-propagate-flag t
  "Non-nil means next Dired buffer should be displayed the same.
The last `dired-details-state' value set is used by the next Dired
buffer created."
  :type 'boolean)

(defvar dired-details-last-state nil
  "Last `dired-details-state' value.
This is changed each time any Dired buffer's state changes.")




;;; REPLACE ORIGINAL in `dired-details.el'.
;;;
;;; Use last hide/show state, if `dired-details-propagate-flag'.
;;; 
(defun dired-details-activate ()
  "Set up dired-details in the current dired buffer.
Called by `dired-after-readin-hook' on initial display and when a
subdirectory is inserted (with `i').  The state is chosen as follows:
If the state is already established here, leave it alone.
If `dired-details-propagate-flag' is non-nil, then use the last state.
Otherwise, use the default state, as determined by
  `dired-details-initially-hide'."
  (cond (dired-details-state            ; State chosen in this buffer; respect it.
         (when (eq 'hidden dired-details-state)
           (dired-details-hide)))
        ((and dired-details-propagate-flag ; Inherit state from previous.
              dired-details-last-state)
         (when (eq 'hidden dired-details-last-state)
           (dired-details-hide)))
        (t
         ;;otherwise, use the default state
         (when dired-details-initially-hide
           (dired-details-hide)))))

;; The test (get-buffer-window (current-buffer)) is to make sure that
;; Dired is already displayed.  If not, the selected frame is not what
;; we want to fit.
(when (fboundp 'dired-details-show)
  (dired-details-install)
  ;; Override bindings in `dired-details-install'.
  (define-key dired-mode-map "(" 'dired-details-toggle)
  (define-key dired-mode-map ")" 'dired-details-toggle)
  (defadvice dired-details-show (after fit-dired-frame activate)
    "Save `dired-details-last-state'.  Fit Dired frame if `one-window-p'."
    (setq dired-details-last-state dired-details-state)
    (when (and (get-buffer-window (current-buffer))
               (fboundp 'fit-frame-if-one-window))
      (fit-frame-if-one-window)))

  (defadvice dired-details-hide (after fit-dired-frame activate)
    "Save `dired-details-last-state'.  Fit Dired frame if `one-window-p'."
    (setq dired-details-last-state dired-details-state)
    (when (and (get-buffer-window (current-buffer))
               (fboundp 'fit-frame-if-one-window))
      (fit-frame-if-one-window))))


;; `dired-create-files' is defined in `dired-aux.el'.
;;;###autoload
(defadvice dired-create-files (after dired-details-activate activate)
  "Set up Dired details."
  (dired-details-delete-overlays)
  (dired-details-activate))

;; `dired-create-directory' is defined in `dired-aux.el'.
;;;###autoload
(defadvice dired-create-directory (after dired-details-activate activate)
  "Set up Dired details."
  (dired-details-delete-overlays)
  (dired-details-activate))

;; `dired-byte-compile' is defined in `dired-aux.el'.
;;;###autoload
(defadvice dired-byte-compile (after dired-details-activate activate)
  "Set up Dired details."
  (dired-details-delete-overlays)
  (dired-details-activate))

;; `dired-compress' is defined in `dired-aux.el'.
;;;###autoload
(defadvice dired-compress (after dired-details-activate activate)
  "Set up Dired details."
  (dired-details-delete-overlays)
  (dired-details-activate))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(provide 'dired-details+)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; dired-details+.el ends here

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: dired-details: show/hide file details in Dired

[Robert J. Chassell]

Thank you for sending the code.  I got the other code, too, 

    fit-frame.el
    autofit-frame.el
    dired-details.el

which looks to be needed to test the library.

You need not put it in an attachment.  It is quicker for me when it is
plain text and I look at it and copy it directly.

You forgot to create the variable dired-details-state; I put 
    (setq dired-details-state nil)
at the beginning of dired-details+.el and have not had any trouble
    since.
(I am using today's Emacs snapshot started with -Q -D; that is the
    fourth instance of Emacs I have running.) 

It seems to work on a short test; however, I do like the long listing
that dired provides, I especially find it important to see permission,
owners, size, and date, as well name.  And I hardly ever use frames.

So for me, all this would be useless.  But others operate differently.

Now a friend has come in and must close.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: add directory selection to the "compile" command

[lucatrv]

> Using M-x recompile after the first M-x compile may solve your problem. 
> M-x
> recompile remembers the last compile-command and default-directory.
>
> I frequently work like this:
>
>  - switch to Makefile directory
>  - M-x compile RET
>  - begin edit-recompile-cycle loop:
>    * edit
>    * M-x recompile RET
>    * goto edit-recompile-cycle
>
> -Denis
>

Ops, I'm sorry, I didn't know about this....

Luca 

RE: dired-details: show/hide file details in Dired

[Drew Adams]

> Thank you for sending the code.  I got the other code, too,
>     fit-frame.el
>     autofit-frame.el
>     dired-details.el
>
> which looks to be needed to test the library.

No, not really. As I said, the frame-fitting part is optional. The `require'
is soft (no error if not found), and if you do not have the *-frame.el
libraries, the Dired hide/show code still works just fine. I use non-nil
pop-up-frames, so frame fitting is important to me, but it is not necessary
for the other features provided by dired-details+.el. You can no doubt
imagine that without frame fitting not much would be gained by removing
Dired details: the frame would occupy just as much screen real estate as for
the detailed listing.

dired-details.el is required because dired-details+.el is just a tweak for
it.

> You forgot to create the variable dired-details-state; I put
>     (setq dired-details-state nil)
> at the beginning of dired-details+.el and have not had any trouble
> since.

No, I didn't forget to create that variable. dired-details+.el is just a
tweak on top of dired-details, which defines `dired-details-state' with
`defvar'. If I had written dired-details, then I would have just modified it
directly, instead of creating a separate tweak library.

> It seems to work on a short test; however, I do like the long listing
> that dired provides, I especially find it important to see permission,
> owners, size, and date, as well name.  And I hardly ever use frames.
>
> So for me, all this would be useless.  But others operate differently.

I understand. Use of this feature would be optional. As with all options,
not every Emacs user will find it useful. As always, it depends on your own
usage patterns. It can even depend on your operating system. I am often on
M$ Windows these days, so I often don't need to bother with the file
permissions, for instance.

I don't claim that everyone will find this useful. I do, and I'm glad that
Rob wrote it. I keep my Dired buffers with the file-name-only display 90% of
the time. YMMV. And, besides being optional, you have a toggle to change the
display. I too "like the long listing that dired provides". I just like to
be able to also have a short listing.

Thanks for giving it a try and reporting what you found.

Re: dired-details: show/hide file details in Dired

[Robert J. Chassell]

    > Thank you for sending the code.  I got the other code, too,
    >     fit-frame.el
    >     autofit-frame.el
    >     dired-details.el ... 

    ... the frame-fitting part is optional. ...  You can no doubt
    imagine that without frame fitting not much would be gained by
    removing Dired details ...

That is a critical point -- and is why you need frame fitting.  If you
were to use frames and did not care about permission, owner, group,
size, and date, fitting the frame would make sense.  I can see that
someone who uses restricted software that does not make things
difficult for interlopers might not care about permissions or owners
-- it is like computing was 30 years ago and is very nice until you
get into trouble.

    ... dired-details ... defines `dired-details-state' with `defvar'.

Ah, I must have got an earlier version of dired-details.el, which did
not define `dired-details-state'.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    I planned to install Drew's tweaks so that the natural dired behavior  
    worked more elegantly; I didn't handle some cases related to updates  
    to a dired buffer and Drew's changes fixed that.

In cases like that, please do install his code.

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

Drew wrote:

    The dired-details+ code (like the dired-details code) uses defadvice.

Why does dired-details use defadvice?
How can we get rid of it?
We should get rid of that now.

We should not increase the list of defadvices waiting to be removed.

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    >     2. Provide a user option, `dired-details-propagate-flag'
    >        which, if non-nil, propagates the last hide/show state
    >        you chose to the next Dired buffer you open.
    >
    > I would rather not install that.

    In that case, then that should be the only behavior,

I don't agree.

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    It seems to work on a short test; however, I do like the long listing
    that dired provides, I especially find it important to see permission,
    owners, size, and date, as well name.  And I hardly ever use frames.

What does dired-details.el have to do with frames?

Re: dired-details: show/hide file details in Dired

[Rob Giardina]

On Jul 4, 2007, at 9:30 PM, Richard Stallman wrote:

> Drew wrote:
>
>     The dired-details+ code (like the dired-details code) uses  
> defadvice.
>
> Why does dired-details use defadvice?
> How can we get rid of it?
> We should get rid of that now.

All is well. The defadvices were only needed for extension when it  
was a separate library. They're gone in the merged version.

> We should not increase the list of defadvices waiting to be removed.

Re: dired-details: show/hide file details in Dired

[Rob Giardina]

On Jul 4, 2007, at 9:30 PM, Richard Stallman wrote:

>>     2. Provide a user option, `dired-details-propagate-flag'
>>        which, if non-nil, propagates the last hide/show state
>>        you chose to the next Dired buffer you open.
>>
>> I would rather not install that.
>
>     In that case, then that should be the only behavior,
>
> I don't agree.

I've thought about Drew's propagate behavior and I like it. If you  
sometimes like seeing 'ls -l' details and sometimes like a terse  
display, having your mood perpetuate when you browse through 5 or 10  
directories in a row is a good thing. That said, my mood doesn't  
usually change, I just set the default to terse mode and peek at the  
details when I need to know.

When reviewing the code, I discovered that the `dired-details-toggle'  
function (submitted by Klaus Berndl) has a clever feature I never  
used. The 2nd param is a flag to update the `dired-details-initially- 
hide' variable to the new state set by the toggle call thus the next  
buffer will open in that state. This supports the usage by the multi- 
mood user (with an appropriate key-binding) without adding another  
variable to track global state.

-rob

RE: dired-details: show/hide file details in Dired

[Drew Adams]

>     It seems to work on a short test; however, I do like the long listing
>     that dired provides, I especially find it important to see permission,
>     owners, size, and date, as well name.  And I hardly ever use frames.
>
> What does dired-details.el have to do with frames?

This was already explained in the thread, but I will repeat it, since you
ask.

If you use a one-buffer frame for each Dired buffer, and you shrink the
buffer horizontally by hiding all info but the file names, then it makes
sense to also shrink the frame. Otherwise, you've gained nothing in terms of
display real estate. That is the motivation for automatically fitting the
frame. Similarly, if you expand the displayed buffer contents, then it makes
sense to expand the frame to fit it, so lines don't wrap. The idea is to
synchronize the frame display with the buffer display.

I was clear from the beginning, however, that I was _not_ proposing that the
frame-fitting in dired-details+ be included in Emacs:

July 2:
> The frame-fitting enhancement need not be applied, since Emacs
> does not yet have my frame-fitting code. But I think some of
> the other enhancements could be integrated.

July 4:
> No, not really. As I said, the frame-fitting part is optional...
> I use non-nil pop-up-frames, so frame fitting is important to me,
> but it is not necessary for the other features provided by
> dired-details+.el. You can no doubt imagine that without frame
> fitting not much would be gained by removing Dired details: the
> frame would occupy just as much screen real estate as for
> the detailed listing.

There was also a discussion of possibly fitting the Emacs window as well,
for those who do not use one buffer per frame. There is currently no code
written to do that, but, IMO, it would be a useful addition. Here is that
exchange:

> > similar to how your frames shrink, Dired could split the window
> > and show more when you got space back from hiding details...
>
> I agree that it could be good to automatically expand and contract
> the current Dired window or windows (just as I do with the frame),
> provided that a user agrees with that behavior via an option
> (somewhere). I have not implemented that - patches welcome ;-).

For the record -

1. The frame-fitting call in dired-details+.el has no effect if either (a)
user option `autofit-frames-flag' is nil or (b) there is more than one
window in the frame. Here is the function called in dired-details+.el, _if_
it is available (soft require, fboundp):

(defun fit-frame-if-one-window ()
  "Resize frame to fit selected window if it is alone in the frame.
Usable in `temp-buffer-show-hook'.
This does nothing if `autofit-frames-flag' is nil."
  (and (one-window-p t) autofit-frames-flag (fit-frame)))

2. Again, I did _not_, in any case, propose that the dired-details+.el call
to `fit-frame-if-one-window' be installed in Emacs, "since Emacs does not
yet have my frame-fitting code."

FYI - Besides the modal display preference (new Dired buffers use the
current display state), which you have rejected, dired-details+ just makes
dired-details update the display automatically:

1. By refreshing the current hide/show state whenever the listing of files
changes (e.g. new file). Think of this as a kind of refresh or revert.

2. By fitting the frame when the hide/show state changes.

I propose adding #1 now. If frame-fitting code is later added to Emacs, then
#2 might also be considered at that time.

Re: dired-details: show/hide file details in Dired

[Robert J. Chassell]

RMS, as I understand, what Drew is saying regarding frame fitting:

  * if you do not use frame fitting functions, and 
    you use an instance of Emacs in one frame only,

  * then, by reducing details in dired, you see only the file names
    and lots of empty space in the buffer.

That is according to a test with this morning's snapshot of Emacs and
the dired-details.el and dired-details+.el that I got yesterday.

Presumably, frame fitting in an instance of Emacs in which you use one
frame at a time or only one frame during your session becomes `buffer
fitting'.  In that case two buffers would be created left and right,
rather than above and below.  Such an instance of Emacs could be in a
console.

In such an instance, some buffer would be chosen automatically to fill
the space otherwise left blank.  That new buffer will not have a full
width since some of that width, normally 80 columns, will be taken by
the other buffer whose width is set by the longest file name.

Incidently, another assumption with a second frame (at least for
practicality) is that the new frame be visible at the same time as the
old -- in X, one of my instances uses the multi-tty branch and I
create a second frame with it, but the two frames are not visible on
the same display.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: dired-details: show/hide file details in Dired

[Stefan Monnier]

>> > How about also installing the enhancements provided by
>> > dired-details+.el?
>> These can be addressed separately afterwards, so let's just wait.
> Why? What's the hurry for one but not the other? Do you have an objection to
> a particular enhancement?

Because I prefer working *in* the repository then outside of it
(e.g. because it keeps track of history, etc..., you know: revision
control).


        Stefan

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    That said, my mood doesn't  
    usually change, I just set the default to terse mode and peek at the  
    details when I need to know.

That is what I expect most people will want.

    When reviewing the code, I discovered that the `dired-details-toggle'  
    function (submitted by Klaus Berndl) has a clever feature I never  
    used. The 2nd param is a flag to update the `dired-details-initially- 
    hide' variable to the new state set by the toggle call thus the next  
    buffer will open in that state. This supports the usage by the multi- 
    mood user (with an appropriate key-binding) without adding another  
    variable to track global state.

That is nice.

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    This was already explained in the thread, but I will repeat it, since you
    ask.

Thanks for the explanation.

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    All is well. The defadvices were only needed for extension when it  
    was a separate library. They're gone in the merged version.

That is good.

Can you send me the patch you plan to install?

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

      * then, by reducing details in dired, you see only the file names
	and lots of empty space in the buffer.

Is that because the lines are short?

    Presumably, frame fitting in an instance of Emacs in which you use one
    frame at a time or only one frame during your session becomes `buffer
    fitting'.

Right.  It would make sense to use side-by-side buffers, in the style
of a file browser.  That would be a natural next change to make,
after this one.

However, I don't see a need to hold off installing dired-details.el
until that further change is made.  Rather, let's install it,
and that will encourage others to work on the next change.

RE: dired-details: show/hide file details in Dired

[Drew Adams]

>       * then, by reducing details in dired, you see only the file names
> 	    and lots of empty space in the buffer.
>
> Is that because the lines are short?

Yes.

>     Presumably, frame fitting in an instance of Emacs in which you use one
>     frame at a time or only one frame during your session becomes `buffer
>     fitting'.
>
> Right.  It would make sense to use side-by-side buffers, in the style
> of a file browser.  That would be a natural next change to make,
> after this one.
>
> However, I don't see a need to hold off installing dired-details.el
> until that further change is made.  Rather, let's install it,
> and that will encourage others to work on the next change.

I guess that what you two mean by "buffer fitting" is what I referred to as
window fitting. Is that correct - do you mean resizing the window
(especially horizontally) to fit the buffer? Here, again, is the previous
exchange about that, so you can see if it's the same thing you're talking
about:

Mathias> similar to how your frames shrink, Dired could split
>      > the window and show more when you got space back
>      > from hiding details...
>
Drew> I agree that it could be good to automatically expand and contract
> the current Dired window or windows (just as I do with the frame),
> provided that a user agrees with that behavior via an option
> (somewhere). I have not implemented that - patches welcome ;-).

Re: dired-details: show/hide file details in Dired

[Robert J. Chassell]

    I guess that what you two mean by "buffer fitting" is what I
    referred to as window fitting. Is that correct - do you mean
    resizing the window (especially horizontally) to fit the buffer?

You cannot resize a console.  It is fixed.  It is a physical object.
You can only resize buffers in it -- what we call windows when we are
sure that people understand.

As I said in the RSS feed to

    http://www.rattlesnake.com/notions/windows-frames.html

    Sighted people often think of a `window' on a computer screen as
    being a contiguous, rectangular space.  In Emacs, one of the four
    major types of user interface, this region is called a `frame'.
    This tells the history of the words.  Emacs divided its display
    into windows a generation ago before other windowing systems
    appeared.  Emacs then became able to put its display into several
    parts of a screen, each composed of several windows. The `parts'
    needed a name.  Hence, `frame'.

As I say on the page itself, 

    Emacs was designed initially to fill a complete display as a
    tiling window manager.  (A tiling window manager is one in which
    windows do not overlap, but are contiguous, like physical tiles.)
    Parts of the display were called windows because they enabled a
    sighted person to look at all or part of a buffer.

    Companies like Apple and Sun, and the X Consortium, copied Emacs
    jargon for their own windows, to mean a part of a screen.  (Or
    else the notion of a window was generic and commonplace.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: dired-details: show/hide file details in Dired

[Richard Stallman]

    I guess that what you two mean by "buffer fitting" is what I referred to as
    window fitting. Is that correct - do you mean resizing the window
    (especially horizontally) to fit the buffer?

What I mean is more than just that.  What I mean is displaying two side-by-side
windows and using the right-hand window in a way that coordinates with the
Dired buffer.

The details would have to be explored.