bug#10798: 24.0.93; read-file-name

bug#10798: 24.0.93; read-file-name

[Francis Wright]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

The last sentence of the penultimate paragraph of the docstring for
`read-file-name' doesn't make sense to me. It reads as follows:

 

. For graphical file dialogs, any the special values

of MUSTMATCH; `confirm' and `confirm-after-completion' are

treated as equivalent to nil.

 

Perhaps the word "any" should be "ignore".

 


[-- Attachment #2: Type: text/html, Size: 2213 bytes --]

bug#10798: 24.0.93; read-file-name

[Glenn Morris]

Francis Wright wrote:

[read-file-name doc]

> For graphical file dialogs, any the special values of MUSTMATCH;
> `confirm' and `confirm-after-completion' are treated as equivalent to
> nil.

By inspection, it should say something like:

  For graphical file dialogs, any of the special values of MUSTMATCH
  `confirm' and `confirm-after-completion' are treated as equivalent to
  nil.

The idea is that MUSTMATCH = t is still supposed to work.
However, it does not work for me with GTK+ Version 2.18.9 on GNU/Linux
with 23.4 or the current trunk.

I tested with:

(define-key-after menu-bar-help-menu [key]
  '(menu-item "foo" foo))

(defun foo (file)
  (interactive (list (read-file-name "foo: " nil nil t)))
  (setq foo file))

I can happily input a file name that does not exist via the menu-item.

bug#10798: 24.0.93; read-file-name

[Glenn Morris]

Version: 24.0.94

I updated the doc to say:

    For graphical file dialogs, any of the special values of MUSTMATCH
    `confirm' and `confirm-after-completion' are treated as equivalent
    to nil.  Some graphical file dialogs respect a MUSTMATCH value of t,
    and some do not (or it only has a cosmetic effect, and does not
    actually prevent the user from entering a non-existent file).