Why the odd interactive form in byte-compile-file?

Why the odd interactive form in byte-compile-file?

[Daniel Colascione]

byte-compile-file begins with this interactive spec:

(interactive
    (let ((file buffer-file-name)
	 (file-name nil)
	 (file-dir nil))
      (and file
	  (derived-mode-p 'emacs-lisp-mode)
	  (setq file-name (file-name-nondirectory file)
		file-dir (file-name-directory file)))
      (list (read-file-name (if current-prefix-arg
			       "Byte compile and load file: "
			     "Byte compile file: "))
	   current-prefix-arg)))

Why do we go to the trouble of splitting the file name when we're in an 
emacs-lisp-mode buffer? If I'm editing /foo/bar/qux.el and type M-x 
byte-compile-file RET, this code has the effect of compiling qux.el and 
putting "qux.el" in file-name-history, not "/foo/bar/qux.el". Now, if 
default-history is something else and I use C-x C-f C-r qux, I'll end up 
on a bare "qux.el" instead of something I can actually use in another 
context.

Is there some deeper reason we're not using code that looks like this?

(interactive
    (list (read-file-name (if current-prefix-arg
                              "Byte compile and load file: "
                            "Byte compile file: "))
          current-prefix-arg))

Re: Why the odd interactive form in byte-compile-file?

[Daniel Colascione]

On 01/12/2014 08:17 PM, Daniel Colascione wrote:
> byte-compile-file begins with this interactive spec:
>
> (interactive
>     (let ((file buffer-file-name)
>       (file-name nil)
>       (file-dir nil))
>       (and file
>        (derived-mode-p 'emacs-lisp-mode)
>        (setq file-name (file-name-nondirectory file)
>          file-dir (file-name-directory file)))
>       (list (read-file-name (if current-prefix-arg
>                     "Byte compile and load file: "
>                   "Byte compile file: "))
>         current-prefix-arg)))
>
> Why do we go to the trouble of splitting the file name when we're in an
> emacs-lisp-mode buffer? If I'm editing /foo/bar/qux.el and type M-x
> byte-compile-file RET, this code has the effect of compiling qux.el and
> putting "qux.el" in file-name-history, not "/foo/bar/qux.el". Now, if
> default-history is something else and I use C-x C-f C-r qux, I'll end up
> on a bare "qux.el" instead of something I can actually use in another
> context.
>
> Is there some deeper reason we're not using code that looks like this?
>
> (interactive
>     (list (read-file-name (if current-prefix-arg
>                               "Byte compile and load file: "
>                             "Byte compile file: "))
>           current-prefix-arg))

Ping? I'd like to treat this issue as a bugfix and change the 
interactive form to my proposal for 24.4.

Re: Why the odd interactive form in byte-compile-file?

[Thien-Thi Nguyen]

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

() Daniel Colascione <dancol@dancol.org>
() Tue, 14 Jan 2014 16:00:02 -0800

   > Is there some deeper reason we're not using code that looks like this?
   >
   > (interactive
   >     (list (read-file-name (if current-prefix-arg
   >                               "Byte compile and load file: "
   >                             "Byte compile file: "))
   >           current-prefix-arg))

The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
available to the user via ‘M-n’.

The form you propose doesn't do that.

   Ping? I'd like to treat this issue as a bugfix and change the
   interactive form to my proposal for 24.4.

Why do you want to treat this functionality as an "issue"?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Why the odd interactive form in byte-compile-file?

[Daniel Colascione]

On 01/14/2014 08:41 PM, Thien-Thi Nguyen wrote:
> () Daniel Colascione <dancol@dancol.org>
> () Tue, 14 Jan 2014 16:00:02 -0800
>
>     > Is there some deeper reason we're not using code that looks like this?
>     >
>     > (interactive
>     >     (list (read-file-name (if current-prefix-arg
>     >                               "Byte compile and load file: "
>     >                             "Byte compile file: "))
>     >           current-prefix-arg))
>
> The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
> ‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
> available to the user via ‘M-n’.

Why is that useful?

> The form you propose doesn't do that.
>
>     Ping? I'd like to treat this issue as a bugfix and change the
>     interactive form to my proposal for 24.4.
>
> Why do you want to treat this functionality as an "issue"?

The current interactive form results in filenames without paths being 
left in file-name-history when accepting the default filename with RET.

Re: Why the odd interactive form in byte-compile-file?

[Stefan Monnier]

>> > Is there some deeper reason we're not using code that looks like this?
>> > (interactive
>> >     (list (read-file-name (if current-prefix-arg
>> >                               "Byte compile and load file: "
>> >                             "Byte compile file: "))
>> >           current-prefix-arg))
>> The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
>> ‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
>> available to the user via ‘M-n’.
> Why is that useful?

Because you can compile the current buffer's file by just hitting RET.

> The current interactive form results in filenames without paths being left
> in file-name-history when accepting the default filename with RET.

Yes, that's a bug.  We shouldn't pass "file-name" to read-file-name
but buffer-file-name instead.


        Stefan

Re: Why the odd interactive form in byte-compile-file?

[Daniel Colascione]

On 01/15/2014 06:46 AM, Stefan Monnier wrote:
>>>> Is there some deeper reason we're not using code that looks like this?
>>>> (interactive
>>>>      (list (read-file-name (if current-prefix-arg
>>>>                                "Byte compile and load file: "
>>>>                              "Byte compile file: "))
>>>>            current-prefix-arg))
>>> The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
>>> ‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
>>> available to the user via ‘M-n’.
>> Why is that useful?
>
> Because you can compile the current buffer's file by just hitting RET.

Sure, but that also works without the file-dir and file-name parameters 
being passed at all.

Re: Why the odd interactive form in byte-compile-file?

[Stefan Monnier]

>>>>> Is there some deeper reason we're not using code that looks like this?
>>>>> (interactive
>>>>> (list (read-file-name (if current-prefix-arg
>>>>> "Byte compile and load file: "
>>>>> "Byte compile file: "))
>>>>> current-prefix-arg))
>>>> The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
>>>> ‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
>>>> available to the user via ‘M-n’.
>>> Why is that useful?
>> Because you can compile the current buffer's file by just hitting RET.
> Sure, but that also works without the file-dir and file-name parameters
> being passed at all.

I suggest to replace file-name with buffer-file-name for now (since it
fixes a bug), and to install your simpler code after we re-open the
trunk for non-bugfix changes.


        Stefan

Re: Why the odd interactive form in byte-compile-file?

[Daniel Colascione]

On 01/15/2014 03:47 PM, Stefan Monnier wrote:
>>>>>> Is there some deeper reason we're not using code that looks like this?
>>>>>> (interactive
>>>>>> (list (read-file-name (if current-prefix-arg
>>>>>> "Byte compile and load file:"
>>>>>> "Byte compile file: "))
>>>>>> current-prefix-arg))
>>>>> The current ‘interactive’ form supplies DIR and DEFAULT-FILENAME args to
>>>>> ‘read-file-name’ if the current buffer is Emacs Lisp (ish).  Those are
>>>>> available to the user via ‘M-n’.
>>>> Why is that useful?
>>> Because you can compile the current buffer's file by just hitting RET.
>> Sure, but that also works without the file-dir and file-name parameters
>> being passed at all.
>
> I suggest to replace file-name with buffer-file-name for now (since it
> fixes a bug), and to install your simpler code after we re-open the
> trunk for non-bugfix changes.

Thanks. Done.