bug#14710: add-file-local-variable vs. unquoted string

bug#14710: add-file-local-variable vs. unquoted string

[jidanni]

Try
M-x add-file-local-variable
compile-command
a b c

Note how b c are thrown away.
Yes the user should have typed "a b c",
but still some warning should be printed upon throwing them away.

Package: emacs-snapshot
Version: 2:20130618-1

bug#14710: add-file-local-variable vs. unquoted string

[Juri Linkov]

> Try
> M-x add-file-local-variable
> compile-command
> a b c
>
> Note how b c are thrown away.

That's because `add-file-local-variable' takes care about writing
only correct values that could be read later without errors.

> Yes the user should have typed "a b c",
> but still some warning should be printed upon throwing them away.

I have no idea how such a warning could be produced, and even
if we will found a way to detect the situation when it should be
displayed, you won't see it anyway because it will be instantaneously
overwritten in the echo area by another recently added message:
"For this change to take effect revisit file using `revert-buffer'".

bug#14710: add-file-local-variable vs. unquoted string

[Glenn Morris]

Juri Linkov wrote:

> displayed, you won't see it anyway because it will be instantaneously
> overwritten in the echo area by another recently added message:
> "For this change to take effect revisit file using `revert-buffer'".

Could use display-warning.

bug#14710: add-file-local-variable vs. unquoted string

[Juri Linkov]

>> displayed, you won't see it anyway because it will be instantaneously
>> overwritten in the echo area by another recently added message:
>> "For this change to take effect revisit file using `revert-buffer'".
>
> Could use display-warning.

display-warning pops up a new window, and this changes the
window configuration that might be undesirable for users.
I wonder why display-warning doesn't support the warning display
in the echo area?  I see no problem with displaying multi-line
messages in the echo area.

But anyway for the given report it seems too late to display
the warning after a wrong value is inserted to the buffer.

I suggest to display the warning before entering a string value
by changing the prompt from

  Add compile-command with value: a b c

to

  Add compile-command with value (use quotes for strings): "a b c"

=== modified file 'lisp/files-x.el'
--- lisp/files-x.el	2013-06-19 22:39:41 +0000
+++ lisp/files-x.el	2013-06-25 06:09:04 +0000
@@ -88,7 +88,8 @@ (defun read-file-local-variable-value (v
 	 (format "Add %s with value: " variable))
        default))
      (t
-      (read (read-string (format "Add %s with value: " variable)
+      (read (read-string (format "Add %s with value (use quotes for strings): "
+				 variable)
 			 nil 'set-variable-value-history
 			 (format "%S"
 				 (cond ((eq variable 'unibyte) t)

bug#14710: add-file-local-variable vs. unquoted string

[martin rudalics]

 > display-warning pops up a new window, and this changes the
 > window configuration that might be undesirable for users.

It could use `with-help-window' so `q' removes the window as quietly as
possible.

 > I wonder why display-warning doesn't support the warning display
 > in the echo area?  I see no problem with displaying multi-line
 > messages in the echo area.

Strictly spoken, this changes the window configuration as well because
it has to change the size of at least one other window.

martin

bug#14710: add-file-local-variable vs. unquoted string

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> -      (read (read-string (format "Add %s with value: " variable)
> +      (read (read-string (format "Add %s with value (use quotes for strings): "
> +				 variable)

Just say it's a sexp.  Strings are not special here.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#14710: add-file-local-variable vs. unquoted string

[Stefan Monnier]

> Try
> M-x add-file-local-variable
> compile-command
> a b c

> Note how b c are thrown away.
> Yes the user should have typed "a b c",
> but still some warning should be printed upon throwing them away.

Good point.  I fixed it with the patch below, which uses
read-from-minibuffer (with a non-nil `read' argument) instead of
read-string, so it re-uses the check that was already used when reading
an Elisp expression.


        Stefan


=== modified file 'lisp/files-x.el'
--- lisp/files-x.el	2013-06-18 20:38:43 +0000
+++ lisp/files-x.el	2013-06-25 12:59:31 +0000
@@ -71,12 +69,14 @@
 	 (format "Add %s with value: " variable))
        default))
      (t
-      (read (read-string (format "Add %s with value: " variable)
-			 nil 'set-variable-value-history
-			 (format "%S"
+    (let ((default (format "%S"
 				 (cond ((eq variable 'unibyte) t)
 				       ((boundp variable)
-					(symbol-value variable))))))))))
+                                  (symbol-value variable)))))
+          (minibuffer-completing-symbol t))
+      (read-from-minibuffer (format "Add %s with value: " variable)
+                            nil read-expression-map t
+                            'set-variable-value-history)))))
 
 (defun read-file-local-variable-mode ()
   "Read per-directory file-local variable's mode using completion.

bug#14710: add-file-local-variable vs. unquoted string

[jidanni]

You're a wiz.

bug#14710: add-file-local-variable vs. unquoted string

[Juri Linkov]

> Good point.  I fixed it with the patch below, which uses
> read-from-minibuffer (with a non-nil `read' argument) instead of
> read-string, so it re-uses the check that was already used when reading
> an Elisp expression.

FWIW, when I wrote `read-file-local-variable-value' I copied its code:

      (read (read-string (format "Add %s with value (use quotes for strings): "
				 variable)
			 nil 'set-variable-value-history
			 (format "%S" ...

from `set-variable':

                   (read
                    (read-string prompt nil
                                 'set-variable-value-history
				 (format "%S" ...

So `set-variable' seems to have the same problem, although
after entering a string without quotes with e.g.
`M-x set-variable RET compile-command RET a b c RET'
it checks `custom-type' of the entered value and reports the
error "Value `a' does not match type string of compile-command".

Perhaps this is not too problematic as long as `set-variable' is used
only for customizable options, and not for ordinary variables.

bug#14710: add-file-local-variable vs. unquoted string

[Stefan Monnier]

> So `set-variable' seems to have the same problem, although

Indeed, thanks,


        Stefan