Re: 26.1: calc-mode header line [PATCH]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> For this patch, the reason I didn't reuse the code was because it was
> small and there were two (maybe more?) differences in the hard-coded
> constants: 1) 1/3 *parent* window width for the trail buffer versus 2/3
> *parent* window width for the calc buffer; 2) unique constants based
> upon four different string lengths plus I think fudge factor.

But none of those are constants, really -- the function could take two
strings and a width as input, and use (length string1) etc.  That would
also make the code less fragile if the strings are changed later.

> Off-topic: I have several private extensions to dired that are ready for
> the introduction into the wild. Is it better to post them to the devel
> mailing list for possibly wider discussion / consideration / criticism /
> publicity, or post them to the bug mailing list as a feature / patch for
> possibly better tracking?

The latter, I think.  It's easy to lose sight of patches on emacs-devel.

>  1) display change - quickly change the 'ls' switches for a dired buffer
>     from among entries in an alist. The changing can be incremental in
>     the list or prompt the user based upon a useful plain-text
>     description. Just additional code. No change to current code.

Hm...  sounds nice, but what's the use case?  

>  2) history navigation - have each chain of dired buffers track where
>     they've been and allow navigation backward and forward within that
>     history. This does make a one-line change to a single current dired
>     function. It adds several navigation functions, including a form of
>     visit parent directory that adds a prefix argument to go up n levels
>     in your current directory tree.

Isn't `C-x C-f M-DEL' a few times easier to remember?

>  3) pass dired variables to a shell - for any emacs shell or terminal
>     emulator, launch it from dired, and pass the current directory,
>     current file at point, current tagged files ... for both the current
>     dired buffer and an optional one other visible dired buffer on the
>     same frame ($d1 $d2 $f1 $f2 $t1 $t2). For this, I still need to
>     polish how the list of tagged files are handled (quoting, bash/zsh
>     array variables versus POSIX/sh ).

Hm.  What do you use that for?

>  4) Recover a 'borked' dired session, useful if you've somehow
>     accumulated n buffers / windows / frames and want to restore a basic
>     setup.

I'm not sure what a "dired session" is?  I just have a bunch of dired
buffers open, but I don't consider that a "session"...

>  5) Fully exit dired. Just kills all dired buffers everywhere.

That sounds very specialised.  But I've often wanted a command that
would kill all buffers that have names that match a regexp, for
instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no