To Drew Adams?: `dired-get-marked-files' returns error when not on file

To Drew Adams?: `dired-get-marked-files' returns error when not on file

[mafeusek]

Hallo Group Members

This question is rather to Drew Adams, creator of wonderful dired+
module, but maybe some of You will point the answer.

I have the impression `dired-get-marked-files' should return nil instead
signal an error (or at least parameterised) when I am in
dired buffer and I am pointing on empty line after all files.

why? because how can I handle such situation cleanly in elisp code?

best regards,
Pawel

Re: To Drew Adams?: `dired-get-marked-files' returns error when not on file

[Deniz Dogan]

2010/7/6  <mafeusek@gmail.com>:
> Hallo Group Members
>
> This question is rather to Drew Adams, creator of wonderful dired+
> module, but maybe some of You will point the answer.
>
> I have the impression `dired-get-marked-files' should return nil instead
> signal an error (or at least parameterised) when I am in
> dired buffer and I am pointing on empty line after all files.
>
> why? because how can I handle such situation cleanly in elisp code?
>

I am not entirely sure, but I think `condition-case' could be what you
are looking for.

(info "(elisp) Handling Errors")

-- 
Deniz Dogan

RE: To Drew Adams?: `dired-get-marked-files' returns error when not onfile

[Drew Adams]

> I have the impression `dired-get-marked-files' should return 
> nil instead signal an error (or at least parameterised) when
> I am in dired buffer and I am pointing on empty line after all files.
> 
> why? because how can I handle such situation cleanly in elisp code?

In both Dired+ and vanilla Emacs, `dired-get-marked-files' raises an error in
this case.  It calls `dired-get-filename', which raises the error because there
is no file listed on that line.

Your question is how to "handle such a situation".  But it's not clear what you
mean.  What is it that you are trying to do?

Your code can test whether there is a file on the current line in one of these
ways, depending on whether you want to consider `.' and `..' as file names (see
the doc of `dired-get-filename'):

1. Call (dired-get-filename nil 'NO-ERROR-IF-NOT-FILEP)
2. Call `dired-get-filename' inside `condition-case':

(condition-case nil (dired-get-filename) (error nil))

You can also suppress the error in `dired-get-marked-files' and instead return
nil, by wrapping that in `condition-case' the same way.  

(defun my-dired-get-marked-files
 (&optional localp arg filter distinguish-one-marked)
 "Mine."
  (condition-case nil
      (dired-get-marked-files localp arg filter
                              distinguish-one-marked)
    (error nil)))

However, the particular error you are concerned about is not distinguished from
any other errors this way: any error condition here will return nil instead of
raising an error.

RE: To Drew Adams?: `dired-get-marked-files' returns error when notonfile

[Drew Adams]

> > I have the impression `dired-get-marked-files' should return 
> > nil instead signal an error (or at least parameterised) when
> > I am in dired buffer and I am pointing on empty line after 
> > all files.
> > 
> > why? because how can I handle such situation cleanly in elisp code?
> 
> `dired-get-marked-files' raises an error in this case.
> It calls `dired-get-filename', which raises the error because
> there is no file listed on that line.

BTW - There is a good reason for not returning nil, which means there are no
marked files.  If you do in fact have some marked files, and you hit a key to
perform some task on those files, you generally do not want the set of marked
files to be considered empty and the command to act based on that erroneous
assumption.

And if there are no marked files, or if you use a prefix arg, then
`dired-get-marked-files' returns the next ARG files, including the file under
the cursor.  If the cursor is not on a file line then this is problematic, and
an error is in order.

Re: To Drew Adams?: `dired-get-marked-files' returns error when not onfile

[mafeusek]

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

> However, the particular error you are concerned about is not distinguished from
> any other errors this way: any error condition here will return nil instead of
> raising an error.

Hallo Drew.

The above is what concerns me most. I'd consider pointer not on file is not
an error, esspecialy not in non-interactive invocations.

What I am trying to do:
I am going to write a function that invokes command on:
a) files marked explicitly (ie. by `m')
or,
b) all files in directory if there are not marked files.

while acting non-interactivelly, it is hard to do it, unless I want to
hide all the errors with `condition-case' which I think is not reasoanble.

On the other hand in interactive invocation, error is helpful, thus maybe
 good enough choice would be to have optional pointer-away-no-error flag?

best regards,
Pawel

RE: To Drew Adams?: `dired-get-marked-files' returns error when not onfile

[Drew Adams]

> > However, the particular error you are concerned about is 
> > not distinguished from any other errors this way: any error
> > condition here will return nil instead of raising an error.
> 
> The above is what concerns me most. I'd consider pointer not 
> on file is not an error, esspecialy not in non-interactive invocations.
> 
> What I am trying to do: I am going to write a function that
> invokes command on:
>  a) files marked explicitly (ie. by `m') or,
>  b) all files in directory if there are not marked files.
> 
> while acting non-interactivelly, it is hard to do it, unless I want to
> hide all the errors with `condition-case' which I think is 
> not reasoanble.

As I said, "Your code can test whether there is a file on the current line in
one of these ways...".  So your code can determine whether any files are marked
and then act accordingly.

It can also do so more directly, by calling one of the macros that is defined
for this kind of thing (e.g. `dired-map-over-marks',
`dired-map-over-marks-check').  You can also examine their code and do something
different but similar, if you cannot use them out of the box for what you want.

FWIW, see also the definition of macro `dired-map-over-marks(-check)' in Dired+
(as opposed to dired(-aux).el).  It uses the prefix arg as multiple `C-u' to let
users (i.e. commands defined using the macro) treat all files.

As the doc strings of the various commands that use the macro put it, for users:

 A prefix argument ARG specifies files to use instead of marked.
  An integer means use the next ARG files (previous -ARG, if < 0).
  `C-u': Use the current file (whether or not any are marked).
  `C-u C-u': Use all files in Dired, except directories.
  `C-u C-u C-u': Use all files and directories, except `.' and `..'.
  `C-u C-u C-u C-u': Use all files and all directories.

Or as the doc string of the macro puts it, for macro users:

 If ARG is an integer, use the next ARG files (previous -ARG, if < 0).
   In that case point is dragged along.  This is so that commands on
   the next ARG (instead of the marked) files can be easily chained.
 If ARG is a cons with element 16, 64, or 256, corresponding to
   `C-u C-u', `C-u C-u C-u', or `C-u C-u C-u C-u', then use all files
   in the Dired buffer, where:
     16 includes NO directories (including `.' and `..')
     64 includes directories EXCEPT `.' and `..'
    256 includes ALL directories (including `.' and `..')
 If ARG is otherwise non-nil, use the current file.

That's not quite what you want to do, since, based on the ARG, it treats all
files even if some are marked.  But you should be able to code just what you
need, using this or some of the code in dired(-aux).el.

> On the other hand in interactive invocation, error is helpful,
> thus maybe good enough choice would be to have optional 
> pointer-away-no-error flag?