Skip to content

Conversation

@elibarzilay
Copy link

I found multiple issues with dired-subtree--readin, this fixes them:

  • Breaks when --dired is included in dired-listing-switches. You'll
    see that the nested directory is indented by 4 spaces instead of 2,
    which also makes inserting a nested subdirectory fail (since it checks
    that the line starts with exactly two spaces followed by a d).

    The problem is that the listing will already have the double-space
    prefix. See dired-insert-directory which just uses looking-at to
    determine if it needs to add spaces or not. I used the same code to
    add the indentation with indent-rigidly.

  • When -F is used in the switches, the ./.. entries are not
    removed, leading to failures.

    This is because they get a suffix of /. Use a /?$-terminated
    regexp to find these lines.

  • Also, if there are file names that precede ./.., the previous code
    would fail since it assumes that they must be first.

    Use a regexp loop that looks for these in the whole buffer rather than
    the first two lines.

  • Also includes a slightly better version of dired-subtree: Respect the value of dired-actual-switches #143, to avoid the conflict
    that would result from this PR.

I found multiple issues with `dired-subtree--readin`, this fixes them:

* Breaks when `--dired` is included in `dired-listing-switches`.  You'll
  see that the nested directory is indented by 4 spaces instead of 2,
  which also makes inserting a nested subdirectory fail (since it checks
  that the line starts with exactly two spaces followed by a `d`).

  The problem is that the listing will already have the double-space
  prefix.  See `dired-insert-directory` which just uses `looking-at` to
  determine if it needs to add spaces or not.  I used the same code to
  add the indentation with `indent-rigidly`.

* When `-F` is used in the switches, the `.`/`..` entries are not
  removed, leading to failures.

  This is because they get a suffix of `/`.  Use a `/?$`-terminated
  regexp to find these lines.

* Also, if there are file names that precede `.`/`..`, the previous code
  would fail since it assumes that they must be first.

  Use a regexp loop that looks for these in the whole buffer rather than
  the first two lines.

* Also includes a slightly better version of #143, to avoid the conflict
  that would result from this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant