BCI NET 2/BCI NET 2.iso/archives/programming/source/a2.0bemacs-src.lha/Emacs-19.25/lisp/dired.todo

Text File | 1992-05-15 | 13.0 KB | 331 lines

# file dired.todo                    -*-Outline-*-

* Sandy's ([e-mail]) main point is slowness when omitting
  (which I use only on demand, and simply don't use if it'd be too
  slow), so a transaction-free, reversible way of omitting by stashing
  away the filenames would be good.

  Hiding could be used, but probably selective-display-ellipses should
  be nil for omitting files, but t for hiding subdirectories, excluding
  simultaneous use of hiding and omitting.  This would not be a problem
  if all subdirs had to be hidden together, but one subdir may be hidden
  while in another the are files to be omitted.

* REALLY have to split large shell commands.

* Try to cope with ls -lF format like this:

  lrwxrwxrwx  1 dsmith          0 Mar 30 16:44 root@

  Note the missing " -> ".

* In dired shell command, provide a way to pass a `*' to the shell,
  e.g., for grep.

*   kpc> well, here's an example.  i'll have done a recursive find and grep, so
    kpc> i'll have, say, 61 files out of 450 possible files in the buffer.  if
    kpc> i want to get them in time order and they are in size or name order,
    kpc> what do i do?  if i use s, i'll get 450 files!  so much for the
    kpc> grep....  on the other hand i can't see hitting l or c-u l 61
    kpc> times....

    I see why you need this.  And `l' or `C-u l' would be no good since it
    always relists a complete subdirectory.

    kpc> redoing the ls with just the displayed files, if it works, would seem
    kpc> to be the best.  though i don't know if anytuhing can be done about
    kpc> the consing.

    Well, if it only happens on demand, it's up to the user to decide
    whether it's worth an additional garbarge collection or two.  And for
    your application of find-dired buffers, the list would not be very
    big.

*    >>> On Tue, 24 Mar 92 09:37:17 EST,
    >>> [e-mail] (Francois Pinard) said:

    F> All the lines but the last have been hidden by dired-hide-all, while
    F> the last was first added by dired-maybe-insert-subdir, then hidden by
    F> dired-hide-subdir.  It seems that dired-hide-all properly removes and
    F> reinserts white lines when it hides or unhide directories, while
    F> dired-hide-subdir does nothing about them.  So, let me suggest that
    F> dired-hide-subdir removes white lines which preceedes a directory
    F> while hiding it, and that dired-hide-subdir insures one white line
    F> before any hidden directory it expands.

    I think the problem rather lies with the insertion than the hiding.  A
    subdirectory extends from column zero of its headerline to just before
    the next headerline or end-of-buffer*.  This is the region where \r to
    \n conversion must be done for hiding/unhiding**.  The problem is that
    when `i' appends something (call it DIR-NEW) after a hidden dir (call
    it DIR-OLD) at the end of the buffer, that old dir does not end in a
    blank line like all others do.  So in the process of inserting the
    contents of DIR-NEW it inserts an additional \n actually belonging to
    DIR-OLD (that would have been converted to a \r had it been present
    already when DIR-OLD was hidden).

    So a better fix is to have inserted dirs always end in a blank line,
    even the one at the end of the buffer.  This will perhaps also fix
    some problems with nested dired format.  Thank you for bringing this
    to my attention.  I would appreciate any further comments you have on
    this.

    -Sebastian

    ----
    *  This is an axiom.  I programmed dired so that it would be that way,
       so that the whole buffer would be a disjoint partition of
       subdirectories.

    ** Minus the last character (a newline) --- or several hidden subdir
       headerlines would all be in one hidden line.


* dired-visit-hooks each time when a dired buffer is visited.  Could
  be used to revert buffer each time if so desired.

* let shell-command guessing based on regexps just be a special case
  of classes of files.  Classes would in general be defined by lisp
  predicates evaluated on the file line in the dired buffer.  Probably
  they will call dired-get-filename, but they need not.  A class
  `directory' would be easy, for example.

  With a file class, not only a predicate (for deciding whether this
  file line belongs to the class) but perhaps also a finder method (to
  find all files of the class in this buffer) should be associated.

  File classes could be symbols (=names of boolean functions, or
  rather objects with predicate as one associated method of the
  object) or strings (regexps).  Symbols should probably be of the
  form `dired-file-class-*'.

  `File Classes' should perhaps also work in non-dired buffers
  (->hyperbole!).

  `File Classes' could be a concept unifying omitting, shell command
  guessing and coloring/highlighting of file names under X11.

* let C-u C-u i prompt for the dir to be inserted (?)

* let `0 ESC (' simply run PREDICATE witout parsing each marked line,
  in case PREDICATE doesn't need this kind of extra information.

* dired-between-files is not really safe, especially since it doesn't
  know about find-dired.el's `find' line.

* From: [e-mail] (Paul Eggert)
Subject: vc errors and nulldiff
Date: Tue, 14 Jan 92 15:00:54 PST
To: [e-mail]

   There are two questions attached to this topic.  (1) Has anybody come up
   with a simple robust way to retrieve the status of an Emacs 18 subprocess?

Instead of invoking a command FOO ARG1 ... ARGn, you could invoke the command

/bin/sh -c '"$0" ${1+"$@"}; echo \
$?' FOO ARG1 ... ARGn

This behaves just like FOO ARG1 ... ARGn, except instead of exiting with the
true exit status, it appends the exit status as text to the standard output.
The backslash-newline covers the case when the command's output does not end
in newline.

* dired*.texi: use `selected files' for marked or next N files

* get rid of rcs in dired-x, dired-rcs is much faster.

* let dired-current-directory return default-directory if
  dired-subdir-alist is nil (e.g. outside dired buffers, or in a not
  yet completed find-dired buffer).

* wildcards are not well integrated with dired, e.g. entries are added
  to inappropriate buffers.

* Use zero arg to `!' to just toggle a new dired-shell-command-on-each
  variable for consistency?

* [rms] Put everything for copying, renaming, etc. into a separate file again.

Put just autoloads in this file for that stuff.

Likewise, put everything concerned with inserting, killing, and
hiding subdirs into a separate file.  For example, dired-tree-lessp
and dired-split can go there.

These separate files are to make plain dired smaller for most people.

* use map-ynp instead of dired-query.

*
 (defun dired-advertise ()
   ;;"Advertise in variable `dired-buffers' what directory we dired."
   ;; With wildcards we actually advertise too much.
+;; @@ There is no need to do this.
+;; @@ Just check the subdir alist of the current buffer,
+;; @@ and verify the current buffer is in dired-buffers.
   (if (memq (current-buffer) (dired-buffers-for-dir default-directory))

* [rms] I have an idea that might simplify dired.

Suppose all nonempty non-file lines start with a particular character.
A character one would never use as a mark.
Then it would be very fast and simple to check for file lines.
No need for the slowness of looking for the filename.

I suggest the character * or > or #.

Thus, inserting a subdir would install this marker on the non-file
lines created.

* shell command on several sets of markers: "diff A Z"  Need quoting
  then, and better recognize marker only when embedded in space?

  Separate from `!'?

* let `[' enter a mode where the permission bits can be edited, and
  let `]' exit that mode.  Recursive edit?  Keep list of filenames
  where perms were edited?  Or just one file at a time?

* dired-tree-lessp should use file-newer-than-file-p instead of
  string-lessp if sort on time?

* dired-x: dired-mark-sexp (predicate &optional unflag-p)

  ;; As PREDICATE usually refers to only one or two fields, compiling
  ;; it instead of computing all fields could be worth while.

* dired-ls should perhaps do file-name-nondirectory by itself, as in
  the only place where it lists a single file (in dired-add-entry) the
  basename is constructed afterwards.

* dired-string-replace-match should have a GLOBAL replace flag.

* dired-view-file-other-window? dired-find-file-read-only ?

* Use diff-backup from emacs-19.  Move latest-backup-file into
  emacs-19.

* emacs-19.el's mkdir/rmdir commands should optionally accept a
  log-buffer argument.

* [[e-mail] (David Axmark)]

    The things I want most in dired is a way to skip selective parts of
    the -l listing (I use *long* filenames) from the listing swiches. As
    think this would require a special 'ls' (a hotted up GNU ls?) and some
    hacking of the buffer parsing code. It would be very nice to be able
    to have a format with just date or size or ...

  Yes, I'd like that too (I use **very long** filenames).  Accepting
  ls switches without -l should not be too hard to implement.  Hmm, no
  permission bits at the beginning of each line might break some parts
  of the code...  But "just date" etc. would mean to prefobnicate ls
  output each time it is inserted...though that might me done
  efficiently if based on columns instead of regexps.  I'll think
  about it..


* ls switches without -l shouldn't be that hard, though with loss of certain
  features (like *@/ marking).

  It would clean the screen tremendously.

  [This is possible now, but not documented since not everything works
  without -l, sk 14-May-1992 14:10]

* move VM and RMAIL back into dired.el

* `^' fails to find hidden parent dirlines.  Other cmds too, probably.
  Perhaps the goto cmds should optionally unhide their targets.

* M-DEL should mention in the prompt if there are no flags to remove,
  so it can be used for testing, too.


Musings
=======

*
From: [e-mail] (Joe Wells)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Re: stupid (probably) elisp question
Date: 2 Aug 91 01:38:08 GMT
Organization: U S West Advanced Technologies
In-Reply-To: [e-mail]'s message of Wed, 31 Jul 91 14: 46:22 GMT

(Gabriel) writes:

     | > [I would like to perform a regexp replacement on a string.
     | >  How is this possible short of using an intermediate buffer?]
     |
     | It's not.  Silly, ain't it?  After all, buffers are just big
     | strings, albeit with a lot of state information attached.

     You could use string-match and concat to do the same thing,
     without using buffers:

      Don't do this.  Using a scratch buffer is much more efficient, and
      results in less garbage collection later.

   Really?  Why is this?

1.  Replacing a substring in the middle of a string involves generating at
least three strings, possibly more if you're doing something really fancy
with regexps.  Generating strings is expensive, both at the time they are
generated and later when they're garbage collected.  Since these strings
are temporary, they are destined to be garbage collected.

2.  Buffers are really fast.  Once the gap is moved to the correct
location in the buffer, the replacement involves simply writing the new
bytes on top of the old bytes, even if the number of bytes changes.
Moving the gap is actually pretty cheap, especially if the contents of the
buffer are pretty small, like in this case.

Just don't kill the buffer after you're done with it.  Erase its contents
instead and leave it around for the next time your function is called.

--
Enjoy,

Joe Wells <[e-mail]>




* [jwz] One thing I miss about Lispms is a function called
  BALANCE-DIRECTORIES.  What this would do is get a listing of two
  directories (possibly on different machines) and compare
  directories' contents and the files' write-dates, and copy files
  around until both directories were in synch.  There was also an
  option to tell it to only copy in one direction instead of both, and
  you could run it on one file (a trivial case) that would copy that
  file if and only if the destination was not the same or newer.

  I think this would be a terribly useful feature, though you'd have
  to do it by comparing the textual representation of the date, since
  ange-ftp doesn't return correct numeric dates.

  [A subset of this is possible with copy-dir.el, sk 14-May-1992 14:11]

* Actually, there are different meaning of prefix args:

  - with m, u and M-m, F: include even directories
  - with *@/~# : unmark instead mark
  - with mark-using (instead mark-setting) commands: use current file
    instead of marked files
  - with diff commands, it lets you edit the commandline

*
Perhaps the failed files should be given another mark, e.g. `!'.  Then
I would have to include the code from dired-x.el (just 40 lines)
into dired.el to make it possible to switch the current marker
character.  One could then switch to `!', do something on the `!'
files, and pop the old marker character off the stack.

* dired-marker-regexp could use "\n" instead "^", is it used in
  re-search only, never in looking-at.  But the speedup is not
  measurable (below 5%).

* < and > should skip "." and "..". [No, use -A in switches instead!]