A "smaller" dired

A "smaller" dired

[Andrea Crotti]

I was wondering if it would be possible to make the dired buffer similar
to the speedbar.
I don't need the ecb and now my dired opens magically only the files in
"git-files" but the buffer window is always too big.

I removed the "-l" in the dired-list-switches but (as they say) then it
doesn't work anymore.

Why does it need the verbose ls to be able to address to the file after
all?
Thanks

Re: A "smaller" dired

[Jay Belanger]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> I was wondering if it would be possible to make the dired buffer similar
> to the speedbar.
> I don't need the ecb and now my dired opens magically only the files in
> "git-files" but the buffer window is always too big.
>
> I removed the "-l" in the dired-list-switches but (as they say) then it
> doesn't work anymore.

Perhaps dired-details and dired-details+
  http://www.emacswiki.org/emacs/DiredDetails
will help out.

RE: A "smaller" dired

[Drew Adams]

> I was wondering if it would be possible to make the dired 
> buffer similar to the speedbar. I don't need the ecb and now
> my dired opens magically only the files in
> "git-files" but the buffer window is always too big.
> 
> I removed the "-l" in the dired-list-switches but (as they 
> say) then it doesn't work anymore.
> 
> Why does it need the verbose ls to be able to address to the 
> file after all?

I think this is what you're looking for:

http://www.emacswiki.org/emacs/DiredDetails

I am using MS Windows.  80% of the time my Dired buffers show only the file
names.  When I want to see the dates etc.  I just hit a (toggle) key: `)'.

This is especially important to me because I use a separate frame for each
buffer (typically) and the frame is shrink-wrapped to fit the buffer.  With
dired-details the frame is narrow and doesn't waste real estate for stuff I'm
not currently interested in.  When I hit `)' to show the whole buffer, the frame
is auto-resized accordingly.

Even if you want to see the details 99% of the time this feature is useful.
Whatever state you're in (show details or not) is kept as the default for new
Dired buffers etc.  Other than that effect on new buffers, the toggle affects
only the current Dired buffer, so different ones can show details or not.

[FWIW - This feature was OK'd for addition to vanilla Emacs a few years ago, but
no one has bothered to add it.  The author of dired-details.el and myself tried
several times to get past the inertia, but to no avail so far.]

Re: A "smaller" dired

[Andrea Crotti]

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

> I think this is what you're looking for:
>
> http://www.emacswiki.org/emacs/DiredDetails
>
> I am using MS Windows.  80% of the time my Dired buffers show only the file
> names.  When I want to see the dates etc.  I just hit a (toggle) key: `)'.
>
> This is especially important to me because I use a separate frame for each
> buffer (typically) and the frame is shrink-wrapped to fit the buffer.  With
> dired-details the frame is narrow and doesn't waste real estate for stuff I'm
> not currently interested in.  When I hit `)' to show the whole buffer, the frame
> is auto-resized accordingly.
>
> Even if you want to see the details 99% of the time this feature is useful.
> Whatever state you're in (show details or not) is kept as the default for new
> Dired buffers etc.  Other than that effect on new buffers, the toggle affects
> only the current Dired buffer, so different ones can show details or not.
>
> [FWIW - This feature was OK'd for addition to vanilla Emacs a few years ago, but
> no one has bothered to add it.  The author of dired-details.el and myself tried
> several times to get past the inertia, but to no avail so far.]


Thanks a lot that what I wanted!
By the way, interesting the auto-resizing of windows, how do you do it
more or less?
But can I ask why you want a different frame for every buffer?
Were you not satisfied by windows management in only one buffer?

Maybe the window manager is smarter? (mm on windows it would be strange)

Thanks

Re: A "smaller" dired

[Lennart Borgman]

On Wed, Aug 4, 2010 at 6:20 PM, Andrea Crotti <andrea.crotti.0@gmail.com> wrote:
>
> Thanks a lot that what I wanted!
> By the way, interesting the auto-resizing of windows, how do you do it
> more or less?

You could try resize-windows in nXhtml. There is a menu with different options.

RE: A "smaller" dired

[Drew Adams]

> By the way, interesting the auto-resizing of windows, how do you do it
> more or less?

I auto-resize Emacs frames (window-mgr windows), not Emacs windows.

http://www.emacswiki.org/emacs/Shrink-Wrapping_Frames

> But can I ask why you want a different frame for every buffer?
> Were you not satisfied by windows management in only one buffer?
> Maybe the window manager is smarter? (mm on windows it would 
> be strange)

I don't understand some of those questions (dunno what mm is etc.).

I use Emacs frames the way most people use Emacs windows.

I do often reuse frames for different buffers (I don't dedicate all windows as
some people do - e.g. Stefan Monnier).  And I do sometimes (not often) split a
window, using more than one in a frame.

Using Emacs windows instead of frames is essentially like using a tiling window
manager.  I prefer separate frames that I can place anywhere and that I can fit
to their buffers so I don't waste screen real estate.

I have key bindings for moving frames about and resizing frames.


I also use thumbnail frames for iconifying.

http://www.emacswiki.org/emacs/FisheyeWithThumbs

These are like desktop icons, but they are fully functioning (though tiny)
frames.  Instead of just names as icons, stacked in the Windows taskbar, the
icons I use are placed on the desktop (in an ordered way, by default), and I can
see not only the buffer names but the buffer contents.  And I can use that
content even though it is tiny.  It's a great way to save real estate and yet
see multiple buffers in an overall way, monitor the accumulating output of a
process, etc.

The number of frames that I want iconified corresponds well with the amount of
desktop real estate I use for thumbnail frames.  At any time I of course have
many additional buffers open that are not visible in any frame (thumbnail or
otherwise).  And I can also iconify a frame normally (different keystroke), but
I rarely do that.

Re: A "smaller" dired

[Juanma Barranquero]

On Wed, Aug 4, 2010 at 17:50, Drew Adams <drew.adams@oracle.com> wrote:

> [FWIW - This feature was OK'd for addition to vanilla Emacs a few years ago, but
> no one has bothered to add it.  The author of dired-details.el and myself tried
> several times to get past the inertia, but to no avail so far.]

A patch, or at least a reminder, to the bug list with a wishlist tag
would help IMO.

    Juanma

Re: A "smaller" dired

[Andrea Crotti]

"Drew Adams" <drew.adams@oracle.com> writes:
>
> I don't understand some of those questions (dunno what mm is etc.).
>
> I use Emacs frames the way most people use Emacs windows.

Mm was just related to the fact that (but maybe I'm wrong) is linux
where you can have crazy window managers (xmonad for example) that let
you do very interesting things with windows.

But as I see below there are ways also on windows.
It's a good idea I think, the only "problem" is that I like to have
emacs in fullscreen, it's less distracting in general.

[...]

> The number of frames that I want iconified corresponds well with the amount of
> desktop real estate I use for thumbnail frames.  At any time I of course have
> many additional buffers open that are not visible in any frame (thumbnail or
> otherwise).  And I can also iconify a frame normally (different keystroke), but
> I rarely do that.

Interesting thanks I'll give it a try.

RE: A "smaller" dired

[Drew Adams]

> > FWIW - This feature was OK'd for addition to vanilla Emacs 
> > a few years ago, but no one has bothered to add it.
> > The author of dired-details.el and myself tried
> > several times to get past the inertia, but to no avail so far.
> 
> A patch, or at least a reminder, to the bug list with a wishlist tag
> would help IMO.

Done - bug #6799.