File modes facilities.

File modes facilities.

[Michael Cadilhac]

[-- Attachment #1.1.1: Type: text/plain, Size: 740 bytes --]


  I don't know any  way to change the modes of a  file, or even of the
  current file, within emacs.

  As I  chmod quite often, and  especially the file I  work with, I've
  made up a small package that implements facilities for that.

  The main functions are :
  - file-modes-to-number: Convert "a=rwx,a+r,go-x,u+s,a+t" to 3574
    (06766), "777" to 511 (0777) and 511 to 511.
  - buffer-file-modes: Return the file modes of the file visited by a
    buffer or the default modes.
  - set-current-file-modes: Set the modes of the file currently
    visited.
  - chmod: Change the mode of any file.

  If you're  interested in this module,  feel free to  do whatever you
  want with it :-)

  Any comment appreciated !

  Code attached.


[-- Attachment #1.1.2: Change Modes Package --]
[-- Type: application/emacs-lisp, Size: 7679 bytes --]

[-- Attachment #1.1.3: Type: text/plain, Size: 246 bytes --]



-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: File modes facilities.

[Stefan Monnier]

>   I don't know any  way to change the modes of a  file, or even of the
>   current file, within emacs.

C-h f set-file-modes RET


        Stefan

Re: File modes facilities.

[Michael Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   I don't know any  way to change the modes of a  file, or even of the
>>   current file, within emacs.
>
> C-h f set-file-modes RET

  I meant in an user-friendly way, that's to say, without M-:, and
  without calculating the mode.

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: File modes facilities.

[Nick Roberts]

 > >>   I don't know any  way to change the modes of a  file, or even of the
 > >>   current file, within emacs.
 > >
 > > C-h f set-file-modes RET
 > 
 >   I meant in an user-friendly way, that's to say, without M-:, and
 >   without calculating the mode.

In Dired, type M (`dired-do-chmod')?

Nick

Re: File modes facilities.

[Michael Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > >>   I don't know any  way to change the modes of a  file, or even of the
>  > >>   current file, within emacs.
>  > >
>  > > C-h f set-file-modes RET
>  > 
>  >   I meant in an user-friendly way, that's to say, without M-:, and
>  >   without calculating the mode.
>
> In Dired, type M (`dired-do-chmod')?

  First, it  uses dired,  and I don't  want to  launch a dired  of the
  current directory to modify current-file modes.

  Second, it uses the chmod(1) executable, which, beside the fact that
  another program is called, is not compatible with systems that don't
  have  that kind  of binary  installed (like  if one  just downloaded
  a compiled version of emacs for Windows on http://www.crasseux.com)

  Nop ?

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: File modes facilities.

[Kim F. Storm]

Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr> writes:

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>>  > >>   I don't know any  way to change the modes of a  file, or even of the
>>  > >>   current file, within emacs.
>>  > >
>>  > > C-h f set-file-modes RET
>>  > 
>>  >   I meant in an user-friendly way, that's to say, without M-:, and
>>  >   without calculating the mode.
>>
>> In Dired, type M (`dired-do-chmod')?
>
>   First, it  uses dired,  and I don't  want to  launch a dired  of the
>   current directory to modify current-file modes.
>
>   Second, it uses the chmod(1) executable, which, beside the fact that
>   another program is called, is not compatible with systems that don't
>   have  that kind  of binary  installed (like  if one  just downloaded
>   a compiled version of emacs for Windows on http://www.crasseux.com)

Isn't there something in eshell that can do this?  It supports chmod.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Edward O'Connor]

Kim F. Storm wrote:

> Isn't there something in eshell that can do this?  It supports chmod.

Eshell uses the system's ch{mod,own}.


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: File modes facilities.

[Michael Cadilhac]

storm@cua.dk (Kim F. Storm) writes:

> Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr> writes:
>
>> Nick Roberts <nickrob@snap.net.nz> writes:
>>
>>>  > >>   I don't know any  way to change the modes of a  file, or even of the
>>>  > >>   current file, within emacs.
>>>  > >
>>>  > > C-h f set-file-modes RET
>>>  > 
>>>  >   I meant in an user-friendly way, that's to say, without M-:, and
>>>  >   without calculating the mode.
>>>
>>> In Dired, type M (`dired-do-chmod')?
>>
>>   First, it  uses dired,  and I don't  want to  launch a dired  of the
>>   current directory to modify current-file modes.
>>
>>   Second, it uses the chmod(1) executable, which, beside the fact that
>>   another program is called, is not compatible with systems that don't
>>   have  that kind  of binary  installed (like  if one  just downloaded
>>   a compiled version of emacs for Windows on http://www.crasseux.com)
>
> Isn't there something in eshell that can do this?  It supports chmod.

  M-x eshell-command RET chmod =rwx /tmp/a RET

  Same thing: it uses the chmod(1) binary, the prompt is weirdly
  managed and error are reported only with the binary output.

  Well, it's more or less the same  that M-! with a bogus (or at least
  not  intuitive   as  it  doesn't  follow   emacs  conventions)  file
  completion.

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Eli Zaretskii]

> From: Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>
> Date: Thu, 20 Oct 2005 00:44:42 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> >  > >>   I don't know any  way to change the modes of a  file, or even of the
> >  > >>   current file, within emacs.
> >  > >
> >  > > C-h f set-file-modes RET
> >  > 
> >  >   I meant in an user-friendly way, that's to say, without M-:, and
> >  >   without calculating the mode.
> >
> > In Dired, type M (`dired-do-chmod')?
> 
>   First, it  uses dired,  and I don't  want to  launch a dired  of the
>   current directory to modify current-file modes.
> 
>   Second, it uses the chmod(1) executable, which, beside the fact that
>   another program is called, is not compatible with systems that don't
>   have  that kind  of binary  installed (like  if one  just downloaded
>   a compiled version of emacs for Windows on http://www.crasseux.com)

It sounds like you won't accept any solution except your own ;-)

FWIW, I think the natural place for changing files' modes is in Dired;
a separate interactive command, while I don't object to it, will be
used only by those who prefer command-line UI to GUI.  And I don't see
what's the big deal with ``launching Dired''.

If we want dired-do-chmod to work on systems without an external chmod
command, we can easily modify dired-do-chmod to use set-file-modes.
That's a smaller and easier change than adding a whole new suite of
commands with yet another UI.

Re: File modes facilities.

[Michael Cadilhac]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>
>> 
>> >  > >>   I don't know any  way to change the modes of a  file, or even of the
>> >  > >>   current file, within emacs.
>> >  > >
>> >  > > C-h f set-file-modes RET
>> >  > 
>> >  >   I meant in an user-friendly way.
>> >
>> > In Dired, type M (`dired-do-chmod')?
>> 
>>   First, it  uses dired. Second, it uses the chmod(1) executable
>>
> It sounds like you won't accept any solution except your own ;-)

  Hehe :-) The  principal thing that keeps me up is  that I don't have
  chmod(1) on my  (poorly configured) Windows, and that  I chmod quite
  often the file I work with (I  chmod -w file I don't want to modify,
  but if I really have to, I chmod them back +w) :-)

> FWIW, I think the natural place for changing files' modes is in
> Dired;

  Yep, if I plan to work with files, I'll launch a dired, then use
  M. My point is that I'm most likely to change modes of one file, and
  search it in dired mode is not the most direct way I know.

> a separate interactive command, while I don't object to it, will be
> used only by those who prefer command-line UI to GUI.

  In that case, I see the GUI as a waste of time :-p

> If we want dired-do-chmod to work on systems without an external chmod
> command, we can easily modify dired-do-chmod to use set-file-modes.

  Yep, please do, but please do it with symbol parsing
  ([ugoa]*([+-=][rwxXstugo]+)+,...) too :-)

  I'll then make  my own wrapper around newly  coded functions to have
  the features I use ;-)

  Thanks :-)

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Romain Francoise]

Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr> writes:

> My point is that I'm most likely to change modes of one file, and
> search it in dired mode is not the most direct way I know.

M-: (load "dired-x") RET
C-x C-j M <mode> RET

-- 
Romain Francoise <romain@orebokech.com> | I like the streets when
it's a miracle -- http://orebokech.com/ | they're empty, I can make the
                                        | rest up.

Re: File modes facilities.

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>
> Date: Thu, 20 Oct 2005 12:41:21 +0200
> 
> > If we want dired-do-chmod to work on systems without an external chmod
> > command, we can easily modify dired-do-chmod to use set-file-modes.
> 
>   Yep, please do, but please do it with symbol parsing
>   ([ugoa]*([+-=][rwxXstugo]+)+,...) too :-)

I rather hoped that you will do that, and submit the changes here ;-)

Re: File modes facilities.

[Michael Cadilhac]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>
>> Date: Thu, 20 Oct 2005 12:41:21 +0200
>> 
>> > If we want dired-do-chmod to work on systems without an external chmod
>> > command, we can easily modify dired-do-chmod to use set-file-modes.
>> 
>>   Yep, please do, but please do it with symbol parsing
>>   ([ugoa]*([+-=][rwxXstugo]+)+,...) too :-)
>
> I rather hoped that you will do that, and submit the changes here ;-)

  Hehe ;-) Someone proposed to make set-file-modes interactive and to
  take modes as an integer or string (octal or symbolic) parameter.

  I would have  preferred not to touch C code, but  on the other hand,
  I don't see why chmod would be dired-mode specific.

  Any advice ?

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Stefan Monnier]

> If we want dired-do-chmod to work on systems without an external chmod
> command, we can easily modify dired-do-chmod to use set-file-modes.

Yes, I think we should do that.  It's also useful for the case where you use
dired-do-chmod on a Tramp file.

> That's a smaller and easier change than adding a whole new suite of
> commands with yet another UI.

AFAICT (now that I've looked at it more closely: sorry for replying too
quickly before) all he's suggesting is to add an interactive command `chmod'
and `set-current-file-modes'.  I'm not sure about set-current-file-modes,
but providing `chmod' (or making set-file-modes into a command) is
a good idea.


        Stefan

Re: File modes facilities.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> but providing `chmod' (or making set-file-modes into a command) is
> a good idea.

set-file-modes is a nice simple function in C.

IMHO, a more advanced chmod command should be implemented in Lisp.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Stefan Monnier]

>> but providing `chmod' (or making set-file-modes into a command) is
>> a good idea.

> set-file-modes is a nice simple function in C.
> IMHO, a more advanced chmod command should be implemented in Lisp.

Agreed.  I actually firmly believe that we should be able to provide
elisp code for the interactive spec of a C function.
This would also allow us to get rid of the load vs load-file distinction
and to improve various other commands implemented in C where the minibuffer
query only provides a fairly dull default.


        Stefan

Re: File modes facilities.

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Agreed.  I actually firmly believe that we should be able to provide
> elisp code for the interactive spec of a C function.

I don't think that is needed.  It is already possible and much easier to
provide a lisp wrapper that implements any fancy interactive spec as
needed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: File modes facilities.

[Michael Cadilhac]

Andreas Schwab <schwab@suse.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Agreed.  I actually firmly believe that we should be able to provide
>> elisp code for the interactive spec of a C function.
>
> I don't think that is needed.  It is already possible and much easier to
> provide a lisp wrapper that implements any fancy interactive spec as
> needed.

  Yes, it is, but I don't see any interest of providing to the final
  user a function ``set-file-modes'' and another
  ``set-file-modes-that-really-works-as-you-expect'' when one could be
  sufficient, nop ?

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Miles Bader]

2005/10/21, Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>:
> > I don't think that is needed.  It is already possible and much easier to
> > provide a lisp wrapper that implements any fancy interactive spec as
> > needed.
>
>   Yes, it is, but I don't see any interest of providing to the final
>   user a function ``set-file-modes'' and another
>   ``set-file-modes-that-really-works-as-you-expect'' when one could be
>   sufficient, nop ?

Well having two "almost equivalent" entry points instead of one is
bad, so it should be avoided when possible.  But you can work around
such ugliness to some degree by making the C function a non-advertised
internal function, e.g., call the C function
"set-file-modes-internal", and provide a lisp wrapper for the fancy
stuff that everybody would call.

Still, adding lisp interactive specs to C functions would be very
useful, and much cleaner than having 2*n functions, especially if it's
as simple as Kim suggested.

-Miles
--
Do not taunt Happy Fun Ball.

Re: File modes facilities.

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> Still, adding lisp interactive specs to C functions would be very
> useful, and much cleaner than having 2*n functions, especially if it's
> as simple as Kim suggested.

Well almost..., I forgot about changing call-interactvely.  

Below is a complete patch (including the necessary patch to
Fset_file_modes).

Here is an example of how to set the interactive form.
Of course, it should be changed to recognize octal and ascii forms,
as the current base 10 form is useless for interactive use:

(put 'set-file-modes 'interactive '(list (read-file-name "File: ")
					 (read-number "Modes: ")))


*** callint.c	14 Aug 2005 14:47:25 +0200	1.140
--- callint.c	21 Oct 2005 16:38:22 +0200	
***************
*** 346,351 ****
--- 346,356 ----
  	  function = wrong_type_argument (Qcommandp, function);
  	  goto retry;
  	}
+       else if (*string == '#')
+ 	{
+ 	  string = 0;
+ 	  goto get_interactive_form;
+ 	}
      }
    else if (COMPILEDP (fun))
      {
***************
*** 356,361 ****
--- 361,367 ----
    else
      {
        Lisp_Object form;
+     get_interactive_form:
        GCPRO2 (function, prefix_arg);
        form = Finteractive_form (function);
        UNGCPRO;

*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	21 Oct 2005 13:04:24 +0200	
***************
*** 787,793 ****
    if (SUBRP (fun))
      {
        if (XSUBR (fun)->prompt)
! 	return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
      }
    else if (COMPILEDP (fun))
      {
--- 787,801 ----
    if (SUBRP (fun))
      {
        if (XSUBR (fun)->prompt)
! 	{
! 	  Lisp_Object spec;
! 	  if (XSUBR (fun)->prompt[0] != '#')
! 	    return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
! 
! 	  if ((spec = Fget (intern (XSUBR (fun)->symbol_name), Qinteractive),
! 	       !NILP (spec)))
! 	    return list2 (Qinteractive, spec);
! 	}
      }
    else if (COMPILEDP (fun))
      {

*** fileio.c	20 Oct 2005 16:48:05 +0200	1.557
--- fileio.c	21 Oct 2005 16:21:25 +0200	
***************
*** 3462,3468 ****
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2, 0,
         doc: /* Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)
--- 3462,3468 ----
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2, "#",
         doc: /* Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Michael Cadilhac]

storm@cua.dk (Kim F. Storm) writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> Still, adding lisp interactive specs to C functions would be very
>> useful, and much cleaner than having 2*n functions, especially if it's
>> as simple as Kim suggested.
>
> Well almost..., I forgot about changing call-interactvely.  
>
> Below is a complete patch (including the necessary patch to
> Fset_file_modes).
>
> Here is an example of how to set the interactive form.
> Of course, it should be changed to recognize octal and ascii forms,
> as the current base 10 form is useless for interactive use:
>
> (put 'set-file-modes 'interactive '(list (read-file-name "File: ")
> 					 (read-number "Modes: ")))

  Very nice ! I really like it this way.

  Now, to  return to the first  point, the chmod  function. The number
  needed as  a mode  needs to  know the file-modes  of the  file being
  chmod'ed (for [Xugo]).

  So we still have to call a lisp function within set-file-modes.

  Or perhaps there's a way to avoid that ?

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Richard M. Stallman]

    *** callint.c	14 Aug 2005 14:47:25 +0200	1.140
    --- callint.c	21 Oct 2005 16:38:22 +0200	
    ***************
    *** 346,351 ****
    --- 346,356 ----
	      function = wrong_type_argument (Qcommandp, function);
	      goto retry;
	    }
    +       else if (*string == '#')
    + 	{
    + 	  string = 0;
    + 	  goto get_interactive_form;
    + 	}

This would be much cleaner (and easier to use) if it read the Lisp
expression out of the string itself, after the #.

But as I said, I'd rather not install this now.
The new feature for setting file modes should also wait
till after the release.

Re: File modes facilities.

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     *** callint.c	14 Aug 2005 14:47:25 +0200	1.140
>     --- callint.c	21 Oct 2005 16:38:22 +0200
>     ***************
>     *** 346,351 ****
>     --- 346,356 ----
> 	      function = wrong_type_argument (Qcommandp, function);
> 	      goto retry;
> 	    }
>     +       else if (*string == '#')
>     + 	{
>     + 	  string = 0;
>     + 	  goto get_interactive_form;
>     + 	}
>
> This would be much cleaner (and easier to use) if it read the Lisp
> expression out of the string itself, after the #.

I did consider that, and we could do that as well, but IMO, the whole
point of this to allow interactive specs for built-in functions to be
written in Lisp, i.e. in a .el file, so people can improve on the code
without modifying the base functionality.

Also, doing it right in the string makes it much harder to edit and
debug, and may cause problems on systems which has an upper limit on
constant string size.

> But as I said, I'd rather not install this now.

Ok, as a strong advocate of focusing on the release, I have to accept
that :-), although this change is really minor compared to some of the
other recent changes to core functionality ...

However, the patch is not the right approach in any case -- as it only
allows creating an interactive spec for DEFUN's which explicitly allow
it with the prompt = "#" marker.

Below is a _much_better_ patch which allows ANY function to have its
interactive specification overridden, and consequently you can make
any function into a command.

Here are some trivial examples:

(put 'set-file-modes 'interactive
     '(list (read-file-name "Set modes on file: ")
	    (read-number "New modes (decimal): ")))

(put 'set-file-times 'interactive
     '(list (read-file-name "Set current time on file: ")
            (current-time)))

(defun test (a b)
 (message "%d" (+ a b)))

(put 'test 'interactive
     '(list (read-number "a: ")
	    (read-number "b: ")))

(put 'test 'interactive "nx: \nny: ")


*** callint.c	14 Aug 2005 14:47:25 +0200	1.140
--- callint.c	24 Oct 2005 14:40:54 +0200	
***************
*** 333,338 ****
--- 333,348 ----
    /* If k or K discard an up-event, save it here so it can be retrieved with U */
    up_event = Qnil;
  
+   /* Allow overriding the interactive spec of any function
+      by placing an interactive property on the function name.  */
+ 
+   if (SYMBOLP (function)
+       && (specs = Fget (function, Qinteractive), !NILP (specs)))
+     {
+       filter_specs = specs;
+       goto override_interactive_form;
+     }
+ 
    /* Decode the kind of function.  Either handle it and return,
       or go to `lose' if not interactive, or go to `retry'
       to specify a different function, or set either STRING or SPECS.  */
***************
*** 357,363 ****
      {
        Lisp_Object form;
        GCPRO2 (function, prefix_arg);
!       form = Finteractive_form (function);
        UNGCPRO;
        if (CONSP (form))
  	specs = filter_specs = Fcar (XCDR (form));
--- 367,373 ----
      {
        Lisp_Object form;
        GCPRO2 (function, prefix_arg);
!       form = Finteractive_form (function, Qt);
        UNGCPRO;
        if (CONSP (form))
  	specs = filter_specs = Fcar (XCDR (form));
***************
*** 365,370 ****
--- 375,382 ----
  	goto lose;
      }
  
+     override_interactive_form:
+ 
    /* If either SPECS or STRING is set to a string, use it.  */
    if (STRINGP (specs))
      {

*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	24 Oct 2005 14:40:32 +0200	
***************
*** 775,788 ****
    return make_string (name, strlen (name));
  }
  
! DEFUN ("interactive-form", Finteractive_form, Sinteractive_form, 1, 1, 0,
         doc: /* Return the interactive form of CMD or nil if none.
  If CMD is not a command, the return value is nil.
  Value, if non-nil, is a list \(interactive SPEC).  */)
!      (cmd)
!      Lisp_Object cmd;
  {
!   Lisp_Object fun = indirect_function (cmd);
  
    if (SUBRP (fun))
      {
--- 775,799 ----
    return make_string (name, strlen (name));
  }
  
! DEFUN ("interactive-form", Finteractive_form, Sinteractive_form, 1, 2, 0,
         doc: /* Return the interactive form of CMD or nil if none.
  If CMD is not a command, the return value is nil.
+ If optional second arg NO-OVERRIDE is non-nil, do not look for an
+ overriding `interactive' specification property on CMD.
  Value, if non-nil, is a list \(interactive SPEC).  */)
!   (cmd, no_override)
!      Lisp_Object cmd, no_override;
  {
!   Lisp_Object fun;
!   Lisp_Object specs;
! 
!  retry:
!   if (NILP (no_override)
!       && SYMBOLP (cmd)
!       && (specs = Fget (cmd, Qinteractive), !NILP (specs)))
!     return list2 (Qinteractive, specs);
! 
!   fun = indirect_function (cmd);
  
    if (SUBRP (fun))
      {
***************
*** 797,811 ****
    else if (CONSP (fun))
      {
        Lisp_Object funcar = XCAR (fun);
        if (EQ (funcar, Qlambda))
  	return Fassq (Qinteractive, Fcdr (XCDR (fun)));
!       else if (EQ (funcar, Qautoload))
  	{
  	  struct gcpro gcpro1;
  	  GCPRO1 (cmd);
  	  do_autoload (fun, cmd);
  	  UNGCPRO;
! 	  return Finteractive_form (cmd);
  	}
      }
    return Qnil;
--- 808,824 ----
    else if (CONSP (fun))
      {
        Lisp_Object funcar = XCAR (fun);
+ 
        if (EQ (funcar, Qlambda))
  	return Fassq (Qinteractive, Fcdr (XCDR (fun)));
! 
!       if (EQ (funcar, Qautoload))
  	{
  	  struct gcpro gcpro1;
  	  GCPRO1 (cmd);
  	  do_autoload (fun, cmd);
  	  UNGCPRO;
! 	  goto retry;
  	}
      }
    return Qnil;

*** eval.c	14 Aug 2005 14:47:28 +0200	1.256
--- eval.c	24 Oct 2005 14:48:31 +0200	
***************
*** 1908,1913 ****
--- 1908,1917 ----
    register Lisp_Object fun;
    register Lisp_Object funcar;
  
+   if (SYMBOLP (function)
+       && !NILP (Fget (function, Qinteractive)))
+     return Qt;
+ 
    fun = function;
  
    fun = indirect_function (fun);

*** fileio.c	20 Oct 2005 16:48:05 +0200	1.557
--- fileio.c	21 Oct 2005 16:21:25 +0200	
***************
*** 3462,3468 ****
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2, 0,
         doc: /* Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)
--- 3462,3468 ----
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2, "#",
         doc: /* Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)

*** lisp.h	02 Oct 2005 21:08:17 +0200	1.542
--- lisp.h	24 Oct 2005 14:41:07 +0200	
***************
*** 2117,2123 ****
  extern Lisp_Object Qinteger;
  
  extern void circular_list_error P_ ((Lisp_Object));
! EXFUN (Finteractive_form, 1);
  
  /* Defined in frame.c */
  extern Lisp_Object Qframep;
--- 2117,2123 ----
  extern Lisp_Object Qinteger;
  
  extern void circular_list_error P_ ((Lisp_Object));
! EXFUN (Finteractive_form, 2);
  
  /* Defined in frame.c */
  extern Lisp_Object Qframep;


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Below is a _much_better_ patch which allows ANY function to have its
> interactive specification overridden, and consequently you can make
> any function into a command.
>
> Here are some trivial examples:
>
> (put 'set-file-modes 'interactive
>      '(list (read-file-name "Set modes on file: ")
> 	    (read-number "New modes (decimal): ")))

Would one not rather write

(put 'set-file-modes 'interactive
     #'(list (read-file-name "Set modes on file: ")
	     (read-number "New modes (decimal): ")))

so that the byte compiler will do its job there?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File modes facilities.

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Would one not rather write
>
> (put 'set-file-modes 'interactive
>      #'(list (read-file-name "Set modes on file: ")
> 	     (read-number "New modes (decimal): ")))
>
> so that the byte compiler will do its job there?

This is not a function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: File modes facilities.

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Would one not rather write
>
> (put 'set-file-modes 'interactive
>      #'(list (read-file-name "Set modes on file: ")
> 	     (read-number "New modes (decimal): ")))
>
> so that the byte compiler will do its job there?

Yes, that works too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Stefan Monnier]

> Below is a _much_better_ patch which allows ANY function to have its
> interactive specification overridden, and consequently you can make
> any function into a command.

Indeed, this is much better.
The only problem I still see with it is that it interacts poorly
with aliases.

E.g. to take a concrete example:

     (put 'set-file-modes 'interactive '(list ...))
     (defalias 'chmod 'set-file-modes)

M-x chmod should work just like M-x set-file-modes, but AFAICT your code
won't handle it right.


        Stefan


PS: One of the funny things we can do, OTOH is:

    (defalias 'load-library 'load "docstring")
    (defalias 'load-file 'load "other docstring")
    (put 'load-library 'interactive '(...))
    (put 'load-file 'interactive '(...))

Re: File modes facilities.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Below is a _much_better_ patch which allows ANY function to have its
>> interactive specification overridden, and consequently you can make
>> any function into a command.
>
> Indeed, this is much better.
> The only problem I still see with it is that it interacts poorly
> with aliases.

Given your examples, I'd say that it's a feature rather than
a bug :-)

But admittedly, I didn't think about aliases.  But there is a way to
get the best of both approaches:

Suppose A is an alias for C.

Now, if A has overriding interactive spec, use that.
Else if C has overriding interactive spec, use that.
Else use original interactive spec for C (if any).

So this would actually work:

>     (defalias 'load-library 'load "docstring")
>     (defalias 'load-file 'load "other docstring")
>     (put 'load-library 'interactive '(...))
>     (put 'load-file 'interactive '(...))

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Stefan Monnier]

>>> Below is a _much_better_ patch which allows ANY function to have its
>>> interactive specification overridden, and consequently you can make
>>> any function into a command.
>> 
>> Indeed, this is much better.
>> The only problem I still see with it is that it interacts poorly
>> with aliases.

> Given your examples, I'd say that it's a feature rather than a bug :-)

The example I care about is `chmod'.  The ones in my PS were meant as things
that should work any way, no matter what you do with aliases.

> But admittedly, I didn't think about aliases.  But there is a way to
> get the best of both approaches:

> Suppose A is an alias for C.

> Now, if A has overriding interactive spec, use that.
> Else if C has overriding interactive spec, use that.
> Else use original interactive spec for C (if any).

That's what I intended.  That's what's done with usage info in docstrings
(the (fn ARG1 ARG2) thingy at the end of some docstrings).


        Stefan

Re: File modes facilities.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Below is a _much_better_ patch which allows ANY function to have its
>>>> interactive specification overridden, and consequently you can make
>>>> any function into a command.
>>>
>>> Indeed, this is much better.
>>> The only problem I still see with it is that it interacts poorly
>>> with aliases.

Here is a new patch which fully supports command aliases, optionally
with different interactive specs:


*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	25 Oct 2005 00:49:49 +0200
***************
*** 775,788 ****
    return make_string (name, strlen (name));
  }

! DEFUN ("interactive-form", Finteractive_form, Sinteractive_form, 1, 1, 0,
         doc: /* Return the interactive form of CMD or nil if none.
  If CMD is not a command, the return value is nil.
  Value, if non-nil, is a list \(interactive SPEC).  */)
!      (cmd)
!      Lisp_Object cmd;
  {
!   Lisp_Object fun = indirect_function (cmd);

    if (SUBRP (fun))
      {
--- 775,801 ----
    return make_string (name, strlen (name));
  }

! DEFUN ("interactive-form", Finteractive_form, Sinteractive_form, 1, 2, 0,
         doc: /* Return the interactive form of CMD or nil if none.
  If CMD is not a command, the return value is nil.
+ If optional second arg NO-OVERRIDE is non-nil, do not look for an
+ overriding `interactive' specification property on CMD.
  Value, if non-nil, is a list \(interactive SPEC).  */)
!   (cmd, no_override)
!      Lisp_Object cmd, no_override;
  {
!   Lisp_Object fun;
!   Lisp_Object specs;
!
!  retry:
!   if (NILP (no_override))
!     {
!       fun = indirect_function_overriding_spec (cmd, &specs);
!       if (!NILP (specs))
! 	return list2 (Qinteractive, specs);
!     }
!   else
!     fun = indirect_function (cmd);

    if (SUBRP (fun))
      {
***************
*** 797,811 ****
    else if (CONSP (fun))
      {
        Lisp_Object funcar = XCAR (fun);
        if (EQ (funcar, Qlambda))
  	return Fassq (Qinteractive, Fcdr (XCDR (fun)));
!       else if (EQ (funcar, Qautoload))
  	{
  	  struct gcpro gcpro1;
  	  GCPRO1 (cmd);
  	  do_autoload (fun, cmd);
  	  UNGCPRO;
! 	  return Finteractive_form (cmd);
  	}
      }
    return Qnil;
--- 810,826 ----
    else if (CONSP (fun))
      {
        Lisp_Object funcar = XCAR (fun);
+
        if (EQ (funcar, Qlambda))
  	return Fassq (Qinteractive, Fcdr (XCDR (fun)));
!
!       if (EQ (funcar, Qautoload))
  	{
  	  struct gcpro gcpro1;
  	  GCPRO1 (cmd);
  	  do_autoload (fun, cmd);
  	  UNGCPRO;
! 	  goto retry;
  	}
      }
    return Qnil;
***************
*** 1912,1917 ****
--- 1927,1975 ----
    return hare;
  }

+ /* If OBJECT is a symbol, find the end of its function chain and
+    return the value found there.  If OBJECT is not a symbol, just
+    return it.  If there is a cycle in the function chain, signal a
+    cyclic-function-indirection error.
+
+    This is like indirect_function, except that it looks for an
+    overriding interactive specification on each symbol alias, and
+    it will return prematurely if found.  */
+ Lisp_Object
+ indirect_function_overriding_spec (object, specs)
+      register Lisp_Object object;
+      Lisp_Object *specs;
+ {
+   Lisp_Object tortoise, hare;
+
+   *specs = Qnil;
+   hare = tortoise = object;
+
+   for (;;)
+     {
+       if (!SYMBOLP (hare) || EQ (hare, Qunbound))
+ 	break;
+       if ((*specs = Fget (hare, Qinteractive), !NILP (*specs)))
+ 	return hare;
+       hare = XSYMBOL (hare)->function;
+
+       if (!SYMBOLP (hare) || EQ (hare, Qunbound))
+ 	break;
+       if ((*specs = Fget (hare, Qinteractive), !NILP (*specs)))
+ 	return hare;
+       hare = XSYMBOL (hare)->function;
+
+       tortoise = XSYMBOL (tortoise)->function;
+
+       if (EQ (hare, tortoise))
+ 	Fsignal (Qcyclic_function_indirection, Fcons (object, Qnil));
+     }
+
+   return hare;
+ }
+
+
+
  DEFUN ("indirect-function", Findirect_function, Sindirect_function, 1, 1, 0,
         doc: /* Return the function at the end of OBJECT's function chain.
  If OBJECT is a symbol, follow all function indirections and return the final

*** lisp.h	02 Oct 2005 21:08:17 +0200	1.542
--- lisp.h	25 Oct 2005 00:48:23 +0200
***************
*** 2117,2123 ****
  extern Lisp_Object Qinteger;

  extern void circular_list_error P_ ((Lisp_Object));
! EXFUN (Finteractive_form, 1);

  /* Defined in frame.c */
  extern Lisp_Object Qframep;
--- 2117,2123 ----
  extern Lisp_Object Qinteger;

  extern void circular_list_error P_ ((Lisp_Object));
! EXFUN (Finteractive_form, 2);

  /* Defined in frame.c */
  extern Lisp_Object Qframep;
***************
*** 2159,2164 ****
--- 2159,2166 ----
  EXFUN (Fsymbol_plist, 1);
  EXFUN (Fsymbol_name, 1);
  extern Lisp_Object indirect_function P_ ((Lisp_Object));
+ extern Lisp_Object indirect_function_overriding_spec P_ ((Lisp_Object,
+ 							  Lisp_Object *));
  EXFUN (Findirect_function, 1);
  EXFUN (Ffset, 2);
  EXFUN (Fsetplist, 2);

*** callint.c	14 Aug 2005 14:47:25 +0200	1.140
--- callint.c	25 Oct 2005 10:47:36 +0200
***************
*** 321,328 ****
    else
      enable = Qnil;

-   fun = indirect_function (function);
-
    specs = Qnil;
    string = 0;
    /* The idea of FILTER_SPECS is to provide away to
--- 321,326 ----
***************
*** 333,343 ****
    /* If k or K discard an up-event, save it here so it can be retrieved with U */
    up_event = Qnil;

    /* Decode the kind of function.  Either handle it and return,
       or go to `lose' if not interactive, or go to `retry'
       to specify a different function, or set either STRING or SPECS.  */

!   if (SUBRP (fun))
      {
        string = (unsigned char *) XSUBR (fun)->prompt;
        if (!string)
--- 331,347 ----
    /* If k or K discard an up-event, save it here so it can be retrieved with U */
    up_event = Qnil;

+   fun = indirect_function_overriding_spec (function, &specs);
+
    /* Decode the kind of function.  Either handle it and return,
       or go to `lose' if not interactive, or go to `retry'
       to specify a different function, or set either STRING or SPECS.  */

!   if (!NILP (specs))
!     {
!       filter_specs = specs;
!     }
!   else if (SUBRP (fun))
      {
        string = (unsigned char *) XSUBR (fun)->prompt;
        if (!string)
***************
*** 357,363 ****
      {
        Lisp_Object form;
        GCPRO2 (function, prefix_arg);
!       form = Finteractive_form (function);
        UNGCPRO;
        if (CONSP (form))
  	specs = filter_specs = Fcar (XCDR (form));
--- 361,367 ----
      {
        Lisp_Object form;
        GCPRO2 (function, prefix_arg);
!       form = Finteractive_form (function, Qt);
        UNGCPRO;
        if (CONSP (form))
  	specs = filter_specs = Fcar (XCDR (form));

*** eval.c	14 Aug 2005 14:47:28 +0200	1.256
--- eval.c	25 Oct 2005 00:52:49 +0200
***************
*** 1907,1916 ****
  {
    register Lisp_Object fun;
    register Lisp_Object funcar;

!   fun = function;
!
!   fun = indirect_function (fun);
    if (EQ (fun, Qunbound))
      return Qnil;

--- 1907,1917 ----
  {
    register Lisp_Object fun;
    register Lisp_Object funcar;
+   Lisp_Object specs;

!   fun = indirect_function_overriding_spec (function, &specs);
!   if (!NILP (specs))
!     return Qt;
    if (EQ (fun, Qunbound))
      return Qnil;


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Richard M. Stallman]

    Here is a new patch which fully supports command aliases, optionally
    with different interactive specs:

As already explained, that's not the direction I think we should go.
It is not clean for interactive specs to be separated in the sources
from the rest of the function definition.

Re: File modes facilities.

[Richard M. Stallman]

    I did consider that, and we could do that as well, but IMO, the whole
    point of this to allow interactive specs for built-in functions to be
    written in Lisp, i.e. in a .el file, so people can improve on the code
    without modifying the base functionality.

The idea is to write it in Lisp, but that doesn't mean putting
it in a different file, which is undesirable.  It is cleaner
to keep the interactive spec in the function definition, not
separate it.

If you want to put the code in a separate file, you can put
it in a function and make the interactive spec call that function.
So that option will still exist.  But I don't want to make that
the only option.

    Below is a _much_better_ patch which allows ANY function to have its
    interactive specification overridden, and consequently you can make
    any function into a command.

I don't know if I want to make functions into commands
except by editing their definitions in the standard way.

Re: File modes facilities.

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I did consider that, and we could do that as well, but IMO, the whole
>     point of this to allow interactive specs for built-in functions to be
>     written in Lisp, i.e. in a .el file, so people can improve on the code
>     without modifying the base functionality.
>
> The idea is to write it in Lisp, but that doesn't mean putting
> it in a different file, which is undesirable.  

I don't see why it is undesirable--quite the contrary.  In many other
situations, we aim at minimizing the "core functionality in C" and
write the "hard parts" in Lisp.

IMO, it is no less desireable than putting a defcustom for built-in
variables or key bindings for built-in commands into a separate file.

Having to maintain pieces of Lisp code as static C strings sounds
rather tedious and inflexible to me, so IMHO the usefulness of this
will be limited.

>                                                It is cleaner
> to keep the interactive spec in the function definition, not
> separate it.

I don't argue that it should be impossible to specify the interactive
spec as part of the current string, e.g. as "#(list (read-string ...))",
but that functionality is another functionality, so the two approaches
may supplement each other.

However, my approach covers all aspects of your approach, whereas your
appoach only addresses one aspect of my approach, and in a rather
inflexible way.

> If you want to put the code in a separate file, you can put
> it in a function and make the interactive spec call that function.

But this still has the MAJOR drawback that this will only apply to
built-in functions that have already been instrumented to do that
(which in practice means: none).

My trivial changes provide a simple, efficient, flexible,
user-extensible solution which can be applied to all existing
functions and commands.

> I don't know if I want to make functions into commands
> except by editing their definitions in the standard way.

That works only for Lisp code, not for built-in functions (unless you
edit the relevant C files and rebuild emacs -- not the normal approach to
extensibility :-).

But even for Lisp code, why copy all the code just to be able to
change the way a command reads its arguments?

One idea just occurred to me -- my approach could be used as a way to
localize emacs by providing e.g. Danish prompts for the most common
commands.  Not that I would do that personally :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> My trivial changes provide a simple, efficient, flexible,
> user-extensible solution which can be applied to all existing
> functions and commands.

.. and it easily forms the foundation for implementing your
preferred approach, i.e. include the lisp form directly in the C
source file like this:

DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2,
       "(list"
       "  (read-file-name \"File: \")"
       "  (read-number \"Modes: \"))",
       doc: /* Set mode bits of file named FILENAME to MODE (an integer).


My approach also allow aliases to be defined with a different
interactive spec like this:

(defalias 'chmod 'set-file-modes
  "Interactive frontend to `set-file-modes'."
  "fFile: \nnModes: ")


So besides being simple, efficient, flexible, and user-extensible,
it is also a clean solution (with the additional patches below).


Here are the necessary additions to my previous patch to
implement these two features:

*** lread.c	23 Oct 2005 23:02:21 +0200	1.341
--- lread.c	26 Oct 2005 10:19:02 +0200
***************
*** 3450,3455 ****
--- 3450,3465 ----
    read_buffer = (char *) xmalloc (read_buffer_size);
  }
  \f
+
+ static Lisp_Object
+ defsubr_error_handler (data)
+      Lisp_Object data;
+ {
+
+   return Qerror;
+ }
+
+
  void
  defsubr (sname)
       struct Lisp_Subr *sname;
***************
*** 3457,3462 ****
--- 3467,3487 ----
    Lisp_Object sym;
    sym = intern (sname->symbol_name);
    XSETSUBR (XSYMBOL (sym)->function, sname);
+   if (sname->prompt && sname->prompt[0] == '(')
+     {
+       /* Parse inline interactive Lisp expression.  */
+       int len = strlen (sname->prompt);
+       if (sname->prompt[len - 1] == ')')
+ 	{
+ 	  Lisp_Object specs;
+ 	  specs = internal_condition_case_1 (Fread,
+ 					     make_string (sname->prompt, len),
+ 					     Qt, defsubr_error_handler);
+ 	  if (EQ (specs, Qerror))
+ 	    fatal ("invalid interactive spec for `%s'", sname->symbol_name);
+ 	  Fput (sym, Qinteractive, specs);
+ 	}
+     }
  }

  #ifdef NOTDEF /* use fset in subr.el now */

*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	26 Oct 2005 09:27:17 +0200
***************
*** 710,723 ****

  extern Lisp_Object Qfunction_documentation;

! DEFUN ("defalias", Fdefalias, Sdefalias, 2, 3, 0,
         doc: /* Set SYMBOL's function definition to DEFINITION, and return DEFINITION.
  Associates the function with the current load file, if any.
  The optional third argument DOCSTRING specifies the documentation string
  for SYMBOL; if it is omitted or nil, SYMBOL uses the documentation string
! determined by DEFINITION.  */)
!      (symbol, definition, docstring)
!      register Lisp_Object symbol, definition, docstring;
  {
    CHECK_SYMBOL (symbol);
    if (CONSP (XSYMBOL (symbol)->function)
--- 710,725 ----

  extern Lisp_Object Qfunction_documentation;

! DEFUN ("defalias", Fdefalias, Sdefalias, 2, 4, 0,
         doc: /* Set SYMBOL's function definition to DEFINITION, and return DEFINITION.
  Associates the function with the current load file, if any.
  The optional third argument DOCSTRING specifies the documentation string
  for SYMBOL; if it is omitted or nil, SYMBOL uses the documentation string
! determined by DEFINITION.
! The optional fourth argument INTERACTIVE-FORM specifies how to read the
! arguments for command SYMBOL when called interactively.  See `interactive'.  */)
!   (symbol, definition, docstring, interactive_form)
!      register Lisp_Object symbol, definition, docstring, interactive_form;
  {
    CHECK_SYMBOL (symbol);
    if (CONSP (XSYMBOL (symbol)->function)
***************
*** 727,732 ****
--- 729,742 ----
    LOADHIST_ATTACH (Fcons (Qdefun, symbol));
    if (!NILP (docstring))
      Fput (symbol, Qfunction_documentation, docstring);
+   if (!NILP (interactive_form))
+     {
+       /* Accept (interactive ARGS) as well as just ARGS.  */
+       if (CONSP (interactive_form)
+ 	  && EQ (XCAR (interactive_form), Qinteractive))
+ 	interactive_form = Fcar (XCDR (interactive_form));
+       Fput (symbol, Qinteractive, interactive_form);
+     }
    return definition;
  }




--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Richard M. Stallman]

    .. and it easily forms the foundation for implementing your
    preferred approach, i.e. include the lisp form directly in the C
    source file like this:

    DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2,
	   "(list"
	   "  (read-file-name \"File: \")"
	   "  (read-number \"Modes: \"))",
	   doc: /* Set mode bits of file named FILENAME to MODE (an integer).

That is what I would like to implement.

    My approach also allow aliases to be defined with a different
    interactive spec like this:

    (defalias 'chmod 'set-file-modes
      "Interactive frontend to `set-file-modes'."
      "fFile: \nnModes: ")

I don't like the idea of defining aliases with different interactive
specs, because it distorts the meaning of "alias".  Aliases should be
equivalent to the original function.

It is cleaner if people define that chmod function thus:

    (defun chmod (file mode)
      "Interactive frontend to `set-file-modes'."
      (interactive "fFile: \nnModes: ")
      (set-file-modes file mode))

Defining a new function in this way is better than defining
an alias which isn't really an alias.

Re: File modes facilities.

[Richard M. Stallman]

    IMO, it is no less desireable than putting a defcustom for built-in
    variables or key bindings for built-in commands into a separate file.

The key bindings for primitive commands are mostly in the same file as
the commands: cmds.c.

As for cus-start.el, that is a kludge, and we keep forgetting to
update it.

    > If you want to put the code in a separate file, you can put
    > it in a function and make the interactive spec call that function.

    But this still has the MAJOR drawback that this will only apply to
    built-in functions that have already been instrumented to do that
    (which in practice means: none).

Right now, no primitive commands use Lisp to read their arguments.
Once we add a mechanism for them to to do so, we can start changing
some of these commands, one by one, to do so.

I want to keep the arg-reading code with the function definition,
not separate.

    My trivial changes provide a simple, efficient, flexible,
    user-extensible solution which can be applied to all existing
    functions and commands.

We don't want to apply it to very many.  And in the cases where we do,
it will be cleaner to keep the arg-reading code in the function
definition.

    But even for Lisp code, why copy all the code just to be able to
    change the way a command reads its arguments?

There is no need to copy the code.  You can simply call the original
function.

I do not like the idea of defining a different interactive spec
for an alias.  The alias should be equivalent to the original.
Likewise, I don't like the idea of being able to change a function's
interactive spec from a place remote from the function definition.

Re: File modes facilities.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> but providing `chmod' (or making set-file-modes into a command) is
>>> a good idea.
>
>> set-file-modes is a nice simple function in C.
>> IMHO, a more advanced chmod command should be implemented in Lisp.
>
> Agreed.  I actually firmly believe that we should be able to provide
> elisp code for the interactive spec of a C function.
> This would also allow us to get rid of the load vs load-file distinction
> and to improve various other commands implemented in C where the minibuffer
> query only provides a fairly dull default.

Like this?

*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	21 Oct 2005 12:54:00 +0200	
***************
*** 786,791 ****
--- 786,794 ----
  
    if (SUBRP (fun))
      {
+       Lisp_Object spec;
+       if ((spec = Fget (fun, Qinteractive)))
+ 	return list2 (Qinteractive, spec);
        if (XSUBR (fun)->prompt)
  	return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
      }

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Agreed.  I actually firmly believe that we should be able to provide
> elisp code for the interactive spec of a C function.

The previous patch I posted was completely untested, and didn't compile.
Here is a better patch:

*** data.c	19 Sep 2005 00:24:45 +0200	1.254
--- data.c	21 Oct 2005 13:04:24 +0200	
***************
*** 787,793 ****
    if (SUBRP (fun))
      {
        if (XSUBR (fun)->prompt)
! 	return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
      }
    else if (COMPILEDP (fun))
      {
--- 787,801 ----
    if (SUBRP (fun))
      {
        if (XSUBR (fun)->prompt)
! 	{
! 	  Lisp_Object spec;
! 	  if (XSUBR (fun)->prompt[0] != '#')
! 	    return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
! 
! 	  if ((spec = Fget (intern (XSUBR (fun)->symbol_name), Qinteractive),
! 	       !NILP (spec)))
! 	    return list2 (Qinteractive, spec);
! 	}
      }
    else if (COMPILEDP (fun))
      {

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Stefan Monnier]

>> Agreed.  I actually firmly believe that we should be able to provide
>> elisp code for the interactive spec of a C function.

> The previous patch I posted was completely untested, and didn't compile.
> Here is a better patch:

> *** data.c	19 Sep 2005 00:24:45 +0200	1.254
> --- data.c	21 Oct 2005 13:04:24 +0200	
> ***************
> *** 787,793 ****
>     if (SUBRP (fun))
>       {
>         if (XSUBR (fun)->prompt)
> ! 	return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
>       }
>     else if (COMPILEDP (fun))
>       {
> --- 787,801 ----
>     if (SUBRP (fun))
>       {
>         if (XSUBR (fun)->prompt)
> ! 	{
> ! 	  Lisp_Object spec;
> ! 	  if (XSUBR (fun)->prompt[0] != '#')
> ! 	    return list2 (Qinteractive, build_string (XSUBR (fun)->prompt));
> ! 
> ! 	  if ((spec = Fget (intern (XSUBR (fun)->symbol_name), Qinteractive),
> ! 	       !NILP (spec)))
> ! 	    return list2 (Qinteractive, spec);
> ! 	}
>       }
>     else if (COMPILEDP (fun))
>       {

That sounds great, except I think it's important to be able to override in
elisp a previous interactive spec provided by C code.


        Stefan


PS: Also I'd move the "spec = ..." out of the if.

Re: File modes facilities.

[Richard M. Stallman]

    Agreed.  I actually firmly believe that we should be able to provide
    elisp code for the interactive spec of a C function.
    This would also allow us to get rid of the load vs load-file distinction
    and to improve various other commands implemented in C where the minibuffer
    query only provides a fairly dull default.

It is a good idea for sometime later.
It would be possible to make one of load-file and load-library
be the same as `load', but we would still need two commands
for loading, since the motive for them is to have two different
ways of reading the argument.

Re: File modes facilities.

[Stefan Monnier]

> It would be possible to make one of load-file and load-library
> be the same as `load', but we would still need two commands
> for loading, since the motive for them is to have two different
> ways of reading the argument.

AFAIK M-x load-library accepts and properly completes both kinds
of arguments.  The only difference is the initial content of the minibuffer
(empty in one case and default-directory in the other).


        Stefan

Re: File modes facilities.

[Richard M. Stallman]

    AFAIK M-x load-library accepts and properly completes both kinds
    of arguments.

Yes, it seems to.  That's a change I had forgotten about.  (In the old
days, load-library did no completion at all.)  However, load-file only
reads file names, and only completes file names.

Could load-file now be an alias to load-library?

RE: File modes facilities.

[Drew Adams]

        AFAIK M-x load-library accepts and properly completes both kinds
        of arguments.

    Yes, it seems to.  That's a change I had forgotten about.  (In the old
    days, load-library did no completion at all.)  However, load-file only
    reads file names, and only completes file names.

    Could load-file now be an alias to load-library?

Don't load-file and load-library complete the file name differently? Doesn't
load-library expect the library to be in the load-path, while load-file is
content to load a file even if it is not in the load-path?

  (defun load-library (library)
     (interactive
     (list (completing-read "Load library: " 'locate-file-completion
                            (cons load-path load-suffixes))))
    (load library))

The (cons load-path load-suffixes) makes me think this only works for
load-path files.

  (defun load-file (file)
    (interactive (list (let ((completion-ignored-extensions
                              (remove ".elc"
completion-ignored-extensions)))
                          (read-file-name "Load file: "))))
    (load (expand-file-name file) nil nil t))

This one has no connection with load-path.

Or am I misunderstanding the issue?

Re: File modes facilities.

[Miles Bader]

2005/10/22, Drew Adams <drew.adams@oracle.com>:
> Don't load-file and load-library complete the file name differently? Doesn't
> load-library expect the library to be in the load-path, while load-file is
> content to load a file even if it is not in the load-path?
...
> The (cons load-path load-suffixes) makes me think this only works for
> load-path files.

Did you try it?  load-library seems to handle both load-path names and
explicitly-specified pathnames.

[The completion help is kind of screwy though -- tons of duplicate
entries are show]

-Miles
--
Do not taunt Happy Fun Ball.

RE: File modes facilities.

[Drew Adams]

    > Don't load-file and load-library complete the file name
    > differently? Doesn't
    > load-library expect the library to be in the load-path, while
    > load-file is
    > content to load a file even if it is not in the load-path?
    > The (cons load-path load-suffixes) makes me think this only works for
    > load-path files.

    load-library seems to handle both load-path names and
    explicitly-specified pathnames. [The completion help is kind
    of screwy though -- tons of duplicate entries are show]

Right - both load-library and load-file just call `load'. I was speaking
only of the completion, responding to Richard, who mentioned that they both
did completion now.

It looks like they complete differently: `load-library' completes libraries
(as Richard said), wrt your load-path; `load-file' completes file names, wrt
the default-directory.

I think it's good to have these two different kinds of completion (that is,
two different commands), even though the aim in both cases is to load a Lisp
file, and both will accept an absolute file name as argument.

Re: File modes facilities.

[Miles Bader]

2005/10/22, Drew Adams <drew.adams@oracle.com>:
>     load-library seems to handle both load-path names and
>     explicitly-specified pathnames. [The completion help is kind
>     of screwy though -- tons of duplicate entries are show]
>
> It looks like they complete differently: `load-library' completes libraries
> (as Richard said), wrt your load-path; `load-file' completes file names, wrt
> the default-directory.

load-library completes both (simultaneously).  Try it.

-Miles
--
Do not taunt Happy Fun Ball.

RE: File modes facilities.

[Drew Adams]

    >     load-library seems to handle both load-path names and
    >     explicitly-specified pathnames. [The completion help is kind
    >     of screwy though -- tons of duplicate entries are show]
    >
    > It looks like they complete differently: `load-library'
    > completes libraries (as Richard said), wrt your load-path;
    > `load-file' completes file names, wrt the default-directory.

    load-library completes both (simultaneously).  Try it.

I did try it. But maybe we're talking about different things. (And I don't
know what you mean by "simultaneously" completing both.)

Go to a directory that is not in your load-path. M-x load-library will not
complete the name of an Emacs-Lisp file in that directory - at least it
doesn't for me. M-x load-file will complete its name - at least it does for
me. I'm using a CVS snapshot from July, if that makes a difference (I quoted
the code).

I still see two different kinds of completion: one wrt your load-path, the
other wrt the default-directory. And that's what I read in the code, too.

But it's late here - perhaps I'm missing something you're saying because I'm
tired; I'm not _trying_ to be obtuse.

Re: File modes facilities.

[Stefan Monnier]

>         AFAIK M-x load-library accepts and properly completes both kinds
>         of arguments.

>     Yes, it seems to.  That's a change I had forgotten about.  (In the old
>     days, load-library did no completion at all.)  However, load-file only
>     reads file names, and only completes file names.

>     Could load-file now be an alias to load-library?

> Don't load-file and load-library complete the file name differently?

Yes, slightly.  But if your file name starts with / or ~ (i.e. is an
absolute file name, as is the default for `load-file' because of its default
initial value) then the difference is minimal.


        Stefan

RE: File modes facilities.

[Drew Adams]

    >     Could load-file now be an alias to load-library?

    > Don't load-file and load-library complete the file name differently?

    Yes, slightly.  But if your file name starts with / or ~ (i.e. is an
    absolute file name, as is the default for `load-file' because
    of its default initial value) then the difference is minimal.

I guess I still don't understand. I see this difference in completion
behavior - do you not?

    Go to a directory that is not in your load-path. M-x load-library
    will not complete the name of an Emacs-Lisp file in that directory...
    M-x load-file will complete its name.

I see the default for `load-file' being an absolute file name that is in the
default-directory. I see it completing to any file in that directory. I
don't see `load-library' doing that at all - I see `load-library' completing
only wrt the `load-path'.

Are we talking about the same thing and seeing different behaviors? Am I
seeing different behavior from you because I'm using a old (July) CVS
snapshot? IOW, has this behavior changed?

Re: File modes facilities.

[Richard M. Stallman]

    I guess I still don't understand. I see this difference in completion
    behavior - do you not?

Could you describe precisely the two different behaviors?

Re: File modes facilities.

[Stefan Monnier]

>     Yes, slightly.  But if your file name starts with / or ~ (i.e. is an
>     absolute file name, as is the default for `load-file' because
>     of its default initial value) then the difference is minimal.

> I guess I still don't understand. I see this difference in completion
> behavior - do you not?

>     Go to a directory that is not in your load-path. M-x load-library
>     will not complete the name of an Emacs-Lisp file in that directory...
>     M-x load-file will complete its name.

Which part of "starts with / or ~" don't you understand?

> I see the default for `load-file' being an absolute file name that is in the
> default-directory. I see it completing to any file in that directory.  I
> don't see `load-library' doing that at all - I see `load-library' completing
> only wrt the `load-path'.

As I said, the initial value (empty string for load-library,
default-directory for load-file) is the main difference.
But if you type in the default directory manually in load-library the
completion facilities will then work pretty much as they do in load-file.


        Stefan

RE: File modes facilities.

[Drew Adams]

    >     Yes, slightly.  But if your file name starts with / or ~
    >     (i.e. is an absolute file name, as is the default for `load-file'
    >     because of its default initial value) then the difference is
minimal.

    > I guess I still don't understand. I see this difference in completion
    > behavior - do you not?
    >   Go to a directory that is not in your load-path. M-x load-library
    >   will not complete the name of an Emacs-Lisp file in that
    >   directory... M-x load-file will complete its name.

    Which part of "starts with / or ~" don't you understand?

I didn't understand that you meant for the user to _type_ the absolute file
name. I thought you were somehow speaking of the default path used for
completion. Sorry.

Yes, if you type the directory explicitly and absolutely (no `../', `./',
`~/'), then `load-library' will complete in that directory.  My point was
that, without doing that, they complete differently - they use different
paths (directories).

It's like saying that we can do without the use of relative file names
(chic!), because one can always type an absolute file name - IIUC.

    > I see the default for `load-file' being an absolute file name
    > that is in the default-directory. I see it completing to any
    > file in that directory.  I don't see `load-library' doing that
    > at all - I see `load-library' completing only wrt the `load-path'.

    As I said, the initial value (empty string for load-library,
    default-directory for load-file) is the main difference.
    But if you type in the default directory manually in load-library the
    completion facilities will then work pretty much as they do in
    load-file.

Coming back to the initial suggestion by RMS of making `load-file' just an
alias to `load-library', I repeat my preference:

    I think it's good to have these two different kinds of completion
    (that is, two different commands), even though the aim in both
    cases is to load a Lisp file, and both will accept an absolute
    file name as argument.

IOW, `load-file' offers the convenience of using the `default-directory', by
default, and inputting a relative filename. Why give up that convenience?
Why make people type an absolute filename?

It's a lot easier to navigate a directory tree using relative file names
(with, e.g., `../' and `~/'). If the user's intent is to load a file, then
the `load-file' UI is made to order, and the `load-library' UI presents an
unnecessary obstacle (= entering an absolute name).  Imagine if you had no
`cd' command in shell, and had to type (even with completion, from `/') an
absolute path for each file name - that's what it would be like, IIUC.

Re: File modes facilities.

[Stefan Monnier]

> Yes, if you type the directory explicitly and absolutely (no `../', `./',
> `~/'), then `load-library' will complete in that directory.  My point was
> that, without doing that, they complete differently - they use different
> paths (directories).

Yes, they do work differently.  I haven't advocated to remove load-file
and/or merge it into load-library for precisely this reason.  But we could
get rid of load-library if we could just add an interactive spec to `load'.

As for getting rid of load-file, maybe you could make load-library's
completion understand a leading "./" as meaning "relative to current dir"
(similarly to what is done in most shells), or maybe make a C-u prefix tell
load-library that the initial minibuffer content should be
default-directory.  Then maybe we could imagine getting rid of load-file.


        Stefan

RE: File modes facilities.

[Drew Adams]

    > Yes, if you type the directory explicitly and absolutely (no
    > `../', `./', `~/'), then `load-library' will complete in that
    > directory.  My point was that, without doing that, they complete
    > differently - they use different paths (directories).

    Yes, they do work differently.  I haven't advocated to remove load-file
    and/or merge it into load-library for precisely this reason.
    But we could get rid of load-library if we could just add an interactive
    spec to `load'.

    As for getting rid of load-file, maybe you could make load-library's
    completion understand a leading "./" as meaning "relative to
    current dir" (similarly to what is done in most shells), or maybe
    make a C-u prefix tell load-library that the initial minibuffer
    content should be default-directory.  Then maybe we could imagine
    getting rid of load-file.

I almost wrote something similar (the "./" part) in my previous message, but
I think that 1) it would be confusing and somewhat hidden functionality, and
2) people would also miss "../", "~/" etc. - IOW, they would miss completion
from the `default-directory'.

Yes, a C-u could signal a change from the completing behavior of
`load-library' (absolute file name) to that of `load-file' (relative file
name, default-directory). But why do that? What is the advantage of getting
rid of `load-file', with its handy UI for file-name completion?

Re: File modes facilities.

[Richard M. Stallman]

      I'm not sure about set-current-file-modes,
    but providing `chmod' (or making set-file-modes into a command) is
    a good idea.

I would like to make set-file-modes into a command, using his code to
parse the modes if they are specified non-numerically.

Re: File modes facilities.

[Michael Cadilhac]

"Richard M. Stallman" <rms@gnu.org> writes:

>       I'm not sure about set-current-file-modes,
>     but providing `chmod' (or making set-file-modes into a command) is
>     a good idea.
>
> I would like to make set-file-modes into a command, using his code to
> parse the modes if they are specified non-numerically.

  Do you mean making a function such as `change-file-modes' aliased to
  `chmod' ? Or you meant  another thing by `making set-file-modes into
  a command' ?

  In the first  case, I think the (naively  named) `chmod' function of
  my proposal (<87hdbdxo94.fsf@mahaena.lrde>) can make the job.

  Feel free  to do  anything you want  with it,  and if you  want some
  modifications to be made, just ask.

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Miles Bader]

2005/10/21, Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>:
> "Richard M. Stallman" <rms@gnu.org> writes:
> > I would like to make set-file-modes into a command, using his code to
> > parse the modes if they are specified non-numerically.
>
>   Do you mean making a function such as `change-file-modes' aliased to
>   `chmod' ? Or you meant  another thing by `making set-file-modes into
>   a command' ?

"Make FOO into a command", where FOO is an existing function, usually
means "Add an appropriate interactive spec to FOO (so that users can
use it via M-x or bind it to a key)."

-Miles
--
Do not taunt Happy Fun Ball.

Re: File modes facilities.

[Michael Cadilhac]

Miles Bader <snogglethorpe@gmail.com> writes:

> 2005/10/21, Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr>:
>> "Richard M. Stallman" <rms@gnu.org> writes:
>> > I would like to make set-file-modes into a command, using his code to
>> > parse the modes if they are specified non-numerically.
>>
>>   Do you mean making a function such as `change-file-modes' aliased to
>>   `chmod' ? Or you meant  another thing by `making set-file-modes into
>>   a command' ?
>
> "Make FOO into a command", where FOO is an existing function, usually
> means "Add an appropriate interactive spec to FOO (so that users can
> use it via M-x or bind it to a key)."

  That's  what I feared,  thanks ;-)  So Richard  meant to  modify the
  C  function, okey.  I'll  post a  patch tomorrow  if nobody  does it
  within this  time and  if needed. Another  question would  be, where
  would   be  placed   the   code  for   symbolic   modes  parsing   ?
  `lisp/files.el'  sounds good to  me, but  I don't  know if  it's the
  right way to go.

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: File modes facilities.

[Richard M. Stallman]

      That's  what I feared,  thanks ;-)  So Richard  meant to  modify the
      C  function, okey.

Here's what I sent you before, but it bounced because the address
in your message is not the real one.


Part of this package would be good to install.  I don't see a need for
the special feature for changing the current file's modes on the next
save.  Why wait for that?

I would like a function to set the modes of a file--what you've called
chmod, but I think it should be called set-file-modes.

There IS a function called set-file-modes.  It is not interactive.  My
idea is to rename that to set-file-modes-internal, and use your chmod
command under the name set-file-modes.  It should accept a numeric
mode argument too; that way, existing callers will still work.  It
would use file-modes-to-number.

Would you like to work on such a patch?

Have we got legal papers from you for Emacs?

    (defvar file-modes 0
      "File modes of the file visited in the current buffer. Do not
    rely on this variable to know current file modes, use `buffer-file-modes'
    instead.")

Please note the rule that the first line of a doc string must always
stand on its own.

Re: File modes facilities.

[Michael Cadilhac]

[-- Attachment #1.1.1: Type: text/plain, Size: 849 bytes --]

"Richard M. Stallman" <rms@gnu.org> writes:

> There IS a function called set-file-modes.  It is not interactive.  My
> idea is to rename that to set-file-modes-internal, and use your chmod
> command under the name set-file-modes.  It should accept a numeric
> mode argument too; that way, existing callers will still work.  It
> would use file-modes-to-number.
>
> Would you like to work on such a patch?

  Of course, here's attached !

> Have we got legal papers from you for Emacs?

  Nop, what's the procedure ?

  Patch follows.

 lisp/ChangeLog     |    5 +
 lisp/file-modes.el |  148 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 lispref/ChangeLog  |    6 ++
 lispref/files.texi |   25 -!!!!!!!
 src/ChangeLog      |    5 +
 src/fileio.c       |   18 !!!!!!
 6 files changed, 164 insertions(+), 5 deletions(-), 38 modifications(!)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: file-modes.patch --]
[-- Type: text/x-patch, Size: 14716 bytes --]

Index: lisp/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.8422
diff -c -r1.8422 ChangeLog
*** lisp/ChangeLog	23 Oct 2005 13:30:15 -0000	1.8422
--- lisp/ChangeLog	23 Oct 2005 23:25:27 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2005-10-24  Michael Cadilhac  <michael.cadilhac@lrde.org>
+ 
+ 	* file-modes.el: New. Implement file modes relative functions
+ 	with symbolic modes notation parsing.
+ 	
  2005-10-23  Thien-Thi Nguyen  <ttn@gnu.org>
  
  	* whitespace.el (whitespace-cleanup): Doc fix.
Index: lispref/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lispref/ChangeLog,v
retrieving revision 1.509
diff -c -r1.509 ChangeLog
*** lispref/ChangeLog	22 Oct 2005 16:41:55 -0000	1.509
--- lispref/ChangeLog	23 Oct 2005 23:25:27 -0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2005-10-24  Michael Cadilhac  <michael.cadilhac@lrde.org>
+ 
+ 	* files.texi (Changing Files): Document the fact that
+ 	`set-file-modes' could take its mode argument as a
+ 	string. Document `file-modes-to-number'.
+ 
  2005-10-22  Eli Zaretskii  <eliz@gnu.org>
  
  	* internals.texi (Building Emacs): Fix last change.
Index: lispref/files.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/lispref/files.texi,v
retrieving revision 1.87
diff -c -r1.87 files.texi
*** lispref/files.texi	17 Oct 2005 06:47:26 -0000	1.87
--- lispref/files.texi	23 Oct 2005 23:25:27 -0000
***************
*** 1083,1098 ****
  @end group
  
  @group
! (set-file-modes "~/junk/diffs" 438)
       @result{} nil
  @end group
  
  @group
- (format "%o" 438)
-      @result{} "666"             ; @r{Convert to octal.}
- @end group
- 
- @group
  % ls -l diffs
    -rw-rw-rw-  1 lewis 0 3063 Oct 30 16:00 diffs
  @end group
--- 1083,1093 ----
  @end group
  
  @group
! (set-file-modes "~/junk/diffs" "a=rw") ; @r{Use symbolic notation.}
       @result{} nil
  @end group
  
  @group
  % ls -l diffs
    -rw-rw-rw-  1 lewis 0 3063 Oct 30 16:00 diffs
  @end group
***************
*** 1480,1490 ****
  @var{string}.  It is available only on VMS.
  @end defun
  
! @defun set-file-modes filename mode
! This function sets mode bits of @var{filename} to @var{mode} (which
! must be an integer).  Only the low 12 bits of @var{mode} are used.
! This function recursively follows symbolic links at all levels for
! @var{filename}.
  @end defun
  
  @c Emacs 19 feature
--- 1475,1493 ----
  @var{string}.  It is available only on VMS.
  @end defun
  
! @defun file-modes-to-number modes &optional from
! This function returns the numerical mode denoted by @var{modes}.
! @var{modes} could be a string (that represents the mode either in
! symbolic or octal representation) or an integer. @var{from} is used to
! compute relative rights ``X'', ``u'', ``g'', ``o''.
! @end defun
! 
! @defun set-file-modes filename modes
! This function sets mode bits of @var{filename} to @var{modes}.
! @var{modes} could be a string (that represents the mode either in
! symbolic or octal representation) or an integer.  Only the low 12 bits
! of the numerical representation of @var{modes} are used.  This function
! recursively follows symbolic links at all levels for @var{filename}.
  @end defun
  
  @c Emacs 19 feature
Index: src/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/src/ChangeLog,v
retrieving revision 1.4669
diff -c -r1.4669 ChangeLog
*** src/ChangeLog	21 Oct 2005 16:54:37 -0000	1.4669
--- src/ChangeLog	23 Oct 2005 23:25:29 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2005-10-24  Michael Cadilhac  <michael.cadilhac@lrde.org>
+ 
+ 	* fileio.c: Rename `set-file-modes' to `set-file-modes-internal'.
+ 	`set-file-modes' is now a Lisp function.
+ 
  2005-10-21  Richard M. Stallman  <rms@gnu.org>
  
  	* lread.c (Fload): Simplify gcpro structure.
Index: src/fileio.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.557
diff -c -r1.557 fileio.c
*** src/fileio.c	20 Oct 2005 15:03:10 -0000	1.557
--- src/fileio.c	23 Oct 2005 23:25:30 -0000
***************
*** 336,342 ****
  Lisp_Object Qfile_regular_p;
  Lisp_Object Qfile_accessible_directory_p;
  Lisp_Object Qfile_modes;
! Lisp_Object Qset_file_modes;
  Lisp_Object Qset_file_times;
  Lisp_Object Qfile_newer_than_file_p;
  Lisp_Object Qinsert_file_contents;
--- 336,342 ----
  Lisp_Object Qfile_regular_p;
  Lisp_Object Qfile_accessible_directory_p;
  Lisp_Object Qfile_modes;
! Lisp_Object Qset_file_modes_internal;
  Lisp_Object Qset_file_times;
  Lisp_Object Qfile_newer_than_file_p;
  Lisp_Object Qinsert_file_contents;
***************
*** 3462,3469 ****
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 2, 0,
!        doc: /* Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)
       Lisp_Object filename, mode;
--- 3462,3471 ----
    return make_number (st.st_mode & 07777);
  }
  
! DEFUN ("set-file-modes-internal", Fset_file_modes_internal, Sset_file_modes_internal,
!        2, 2, 0,
!        doc: /* Internal use only.
! Set mode bits of file named FILENAME to MODE (an integer).
  Only the 12 low bits of MODE are used.  */)
    (filename, mode)
       Lisp_Object filename, mode;
***************
*** 3476,3484 ****
  
    /* If the file name has special constructs in it,
       call the corresponding file handler.  */
!   handler = Ffind_file_name_handler (absname, Qset_file_modes);
    if (!NILP (handler))
!     return call3 (handler, Qset_file_modes, absname, mode);
  
    encoded_absname = ENCODE_FILE (absname);
  
--- 3478,3486 ----
  
    /* If the file name has special constructs in it,
       call the corresponding file handler.  */
!   handler = Ffind_file_name_handler (absname, Qset_file_modes_internal);
    if (!NILP (handler))
!     return call3 (handler, Qset_file_modes_internal, absname, mode);
  
    encoded_absname = ENCODE_FILE (absname);
  
***************
*** 6523,6529 ****
    Qfile_regular_p = intern ("file-regular-p");
    Qfile_accessible_directory_p = intern ("file-accessible-directory-p");
    Qfile_modes = intern ("file-modes");
!   Qset_file_modes = intern ("set-file-modes");
    Qset_file_times = intern ("set-file-times");
    Qfile_newer_than_file_p = intern ("file-newer-than-file-p");
    Qinsert_file_contents = intern ("insert-file-contents");
--- 6525,6531 ----
    Qfile_regular_p = intern ("file-regular-p");
    Qfile_accessible_directory_p = intern ("file-accessible-directory-p");
    Qfile_modes = intern ("file-modes");
!   Qset_file_modes_internal = intern ("set-file-modes-internal");
    Qset_file_times = intern ("set-file-times");
    Qfile_newer_than_file_p = intern ("file-newer-than-file-p");
    Qinsert_file_contents = intern ("insert-file-contents");
***************
*** 6558,6564 ****
    staticpro (&Qfile_regular_p);
    staticpro (&Qfile_accessible_directory_p);
    staticpro (&Qfile_modes);
!   staticpro (&Qset_file_modes);
    staticpro (&Qset_file_times);
    staticpro (&Qfile_newer_than_file_p);
    staticpro (&Qinsert_file_contents);
--- 6560,6566 ----
    staticpro (&Qfile_regular_p);
    staticpro (&Qfile_accessible_directory_p);
    staticpro (&Qfile_modes);
!   staticpro (&Qset_file_modes_internal);
    staticpro (&Qset_file_times);
    staticpro (&Qfile_newer_than_file_p);
    staticpro (&Qinsert_file_contents);
***************
*** 6791,6797 ****
    defsubr (&Sfile_accessible_directory_p);
    defsubr (&Sfile_regular_p);
    defsubr (&Sfile_modes);
!   defsubr (&Sset_file_modes);
    defsubr (&Sset_file_times);
    defsubr (&Sset_default_file_modes);
    defsubr (&Sdefault_file_modes);
--- 6793,6799 ----
    defsubr (&Sfile_accessible_directory_p);
    defsubr (&Sfile_regular_p);
    defsubr (&Sfile_modes);
!   defsubr (&Sset_file_modes_internal);
    defsubr (&Sset_file_times);
    defsubr (&Sset_default_file_modes);
    defsubr (&Sdefault_file_modes);
Index: lisp/file-modes.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/file-modes.c,v
retrieving revision 1.557
diff -c -r1.557 file-modes.el
*** lisp/file-modes.el	2005-10-24 01:20:20.000000000 +0200
--- lisp/file-modes.el	2005-10-24 01:16:28.000000000 +0200
***************
*** 0 ****
--- 1,148 ----
+ ;;; file-modes.el --- Facilities for file modes.
+ 
+ ;; Copyright (C) 2005 Free Software Foundation
+ 
+ ;; Author: Michael Cadilhac <michael.cadilhac@lrde.org>
+ ;; Keywords: file modes
+ ;; Version: 0.1
+ 
+ ;; This program is free software; you can redistribute it and/or
+ ;; modify it under the terms of the GNU General Public License as
+ ;; published by the Free Software Foundation; either version 2, or (at
+ ;; your option) any later version.
+ 
+ ;; This program is distributed in the hope that it will be useful, but
+ ;; WITHOUT ANY WARRANTY; without even the implied warranty of
+ ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ ;; General Public License for more details.
+ 
+ ;; You should have received a copy of the GNU General Public License
+ ;; along with GNU Emacs; see the file COPYING.  If not, write to the
+ ;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ ;; Boston, MA 02110-1301, USA.
+ 
+ ;;; Commentary:
+ 
+ ;; This package implements functions related to file modes
+ ;; modification and symbolic notation modes parsing.
+ 
+ ;; For more information about file modes notations see (info
+ ;; "(coreutils)File permissions").
+ 
+ \f
+ ;;; Code:
+ 
+ ;; Specialized functions
+ 
+ (defun char-to-who (c)
+   "Convert a char to a who-mask for symbolic modes notation.
+ C is in [ugoa] and represents users on which rights will apply."
+   (cond ((= c ?u) #o4700)
+ 	((= c ?g) #o2070)
+ 	((= c ?o) #o1007)
+ 	((= c ?a) #o7777)
+ 	(t (error "%c: bad `who' character" c))))
+ 
+ (defun char-to-right (c &optional from)
+   "Convert a char to a right-mask for symbolic modes notation.
+ C is in [rwxXstugo] and represents a right.
+ FROM (0 if non set) is the current numeric mode to process
+ relative rights [Xugo]."
+   (unless from
+     (setq from 0))
+   (cond ((= c ?r) #o0444)
+ 	((= c ?w) #o0222)
+ 	((= c ?x) #o0111)
+ 	((= c ?s) #o1000)
+ 	((= c ?t) #o6000)
+ 	;; Original file-modes relative rights:
+ 	((= c ?X) (if (= (logand from #o111) 0) 0 #o0111))
+ 	((= c ?u) (let ((uright (logand #o4700 from)))
+ 		    (+ uright (/ uright #o10) (/ uright #o100))))
+ 	((= c ?g) (let ((gright (logand #o2070 from)))
+ 		    (+ gright (/ gright #o10) (* gright #o10))))
+ 	((= c ?o) (let ((oright (logand #o1007 from)))
+ 		    (+ oright (* oright #o10) (* oright #o100))))
+ 	(t (error "%c: bad right character" c))))
+ 
+ 
+ (defun rights-str-to-number (rights who-mask &optional from)
+   "Convert rights string to rights-mask for symbolic modes notation.
+ RIGHTS is the rights string, it should match \"([+=-][rwxXstugo]*)+\".
+ WHO-MASK is the mask returned by `char-to-who'.
+ FROM (0 if non set) is the current numeric modes considered."
+   (save-match-data
+     (let ((case-fold-search nil)
+ 	  (num-rights (if from from 0))
+ 	  op)
+       (while (memq (setq op (string-to-char rights)) '(?+ ?- ?=))
+ 	(if (string-match "^.\\([rwxXstugo]*\\)" rights)
+ 	    (let* ((right (string-to-list (substring rights (match-beginning 1) (match-end 1))))
+ 		   (num-right (apply 'logior 0
+ 				     (mapcar (lambda (c) (char-to-right c num-rights)) right))))
+ 	      (setq num-right (logand who-mask num-right)
+ 		    num-rights (cond ((= op ?+) (logior num-rights num-right))
+ 				     ((= op ?-) (logand num-rights (lognot num-right)))
+ 				     (t (logior (logand num-rights (lognot who-mask))
+ 						num-right)))
+ 		    rights (substring rights (match-end 1))))
+ 	  (error "Parse error in rights string near `%s'" rights)))
+       num-rights)))
+ 
+ (defun symbolic-modes-to-number (modes &optional from)
+   "Convert file modes denoted by symbolic notation to numeric modes.
+ MODES is the string to convert, it should match
+ \"[ugoa]*([+-=][rwxXstugo]*)+,...\". Look at
+ `(info \"(coreutils)File permissions\")' for more informations about this
+ notation.
+ FROM (0 if non set) is the current numeric modes considered."
+   (let ((case-fold-search nil)
+ 	(num-modes (if from from 0)))
+     (while (not (string= modes ""))
+       (if (string-match "^\\([ugoa]*\\)[^,]*\\(,\\|\\)" modes)
+ 	  (let* ((who (string-to-list (substring modes (match-beginning 1) (match-end 1))))
+ 		 (num-who (apply 'logior 0 (mapcar 'char-to-who who))))
+ 	    (when (= num-who 0)
+ 	      (setq num-who (default-file-modes)))
+ 	    (setq num-modes
+ 		  (rights-str-to-number (substring modes (match-end 1))
+ 					num-who num-modes)
+ 		  modes (substring modes (match-end 2))))
+ 	(error "Parse error in modes near %s" modes)))
+     num-modes))
+ 
+ \f
+ ;; Main functions
+ 
+ ;;;###autoload
+ (defun file-modes-to-number (modes &optional from)
+   "Convert file modes denoted by MODES to numeric modes.
+ MODES is either a string representing the modes in octal or in symbolic
+ notation, or a number.
+ FROM (0 if non set) is the numeric modes to which modes will refer is
+ the symbolic notation is used."
+   (if (stringp modes)
+       (if (string-match "^[0-7]+$" modes)
+ 	  (string-to-number modes 8)
+ 	(symbolic-modes-to-number modes from))
+     modes))
+ 
+ ;;;###autoload
+ (defalias 'chmod 'set-file-modes)
+ ;;;###autoload
+ (defun set-file-modes (filename modes)
+   "Set MODES to be the file modes of FILENAME.
+ MODES is either a string (symbolic or octal representation) or a number."
+   (interactive (list (read-file-name "Change mode: " nil nil t)
+ 		     (read-string "File modes (symbolic or octal): ")))
+   (unless (file-exists-p filename)
+     (error "File %s doesn't exist" filename))
+   (unless (and (stringp modes) (string= modes ""))
+     (set-file-modes-internal filename (file-modes-to-number modes (file-modes filename)))))
+ 
+ 
+ 
+ (provide 'file-modes)
+ 
+ ;;; arch-tag: 3cabd295-7f8a-4674-beae-fbfef54cca10
+ ;;; file-modes.el ends here

[-- Attachment #1.1.3: Type: text/plain, Size: 187 bytes --]


-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |
  2 rue de la Convention | 08.70.65.13.14 |
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: File modes facilities.

[Kim F. Storm]

Michael Cadilhac <michael.cadilhac@lrde.epita.fr> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> There IS a function called set-file-modes.  It is not interactive.  My
>> idea is to rename that to set-file-modes-internal, and use your chmod
>> command under the name set-file-modes.  It should accept a numeric
>> mode argument too; that way, existing callers will still work.  It
>> would use file-modes-to-number.

I still think my approach to make any command interactive is much, much
better (and simpler) than this hotch-potch approach of renamingbuilt-in
functions to COMMAND-internal and provide a wrapper in Lisp.

BTW, I thought RMS said he didn't want to include this feature before
the release!??!?

That said, is it really safe to change the name of the file handler
for set-file-modes?  Will it break tramp and ange-ftp (and ???)



> ***************
> *** 3476,3484 ****
>   
>     /* If the file name has special constructs in it,
>        call the corresponding file handler.  */
> !   handler = Ffind_file_name_handler (absname, Qset_file_modes);
>     if (!NILP (handler))
> !     return call3 (handler, Qset_file_modes, absname, mode);
>   
>     encoded_absname = ENCODE_FILE (absname);
>   
> --- 3478,3486 ----
>   
>     /* If the file name has special constructs in it,
>        call the corresponding file handler.  */
> !   handler = Ffind_file_name_handler (absname, Qset_file_modes_internal);
>     if (!NILP (handler))
> !     return call3 (handler, Qset_file_modes_internal, absname, mode);
>   
>     encoded_absname = ENCODE_FILE (absname);

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: File modes facilities.

[Richard M. Stallman]

    That said, is it really safe to change the name of the file handler
    for set-file-modes?  Will it break tramp and ange-ftp (and ???)

The name of the operation should not be changed.
This is a change in the _implementation_ of set-file-modes.

But we could just wait until after the release
and then install a way to call Lisp from the interactive spec.
Then the two separate functions won't be needed.

Re: File modes facilities.

[Kevin Ryde]

Michael Cadilhac <michael.cadilhac-@t-lrde.epita.fr> writes:
>
>   - chmod: Change the mode of any file.

I made myself M-x chmod below, to change the current visited file.  I
usually just want to make a script executable.  I know there's an
executable-chmod or something, but I can never remember and prefer
typing 755 or 700.  The save-buffer is in case it's a new file.


(defun chmod (mode)
  "Set the mode of the current file, as per the chmod program."
  (interactive "sMode (3 or 4 octal digits): ")
  (if (string-match "[0-3]?[0-7][0-7][0-7]" mode)
      (progn
        (unless (file-exists-p (buffer-file-name))
          (save-buffer))
        (set-file-modes (buffer-file-name) (string-to-number mode 8)))
    (error "Invalid mode")))

Re: File modes facilities.

[Miles Bader]

2005/10/20, Kevin Ryde <user42@zip.com.au>:
> I made myself M-x chmod below, to change the current visited file.  I
> usually just want to make a script executable.  I know there's an
> executable-chmod or something, but I can never remember and prefer
> typing 755 or 700.  The save-buffer is in case it's a new file.

Why not (1) Give `set-file-modes' an interactive spec (defaulting to
the current buffer's filename), and (2) make `set-file-modes'
understand chmod-style strings as well as integer modes (I guess the
interactive spec would have to decide how to parse integers -- would
defaulting to octal be reasonable?).

Then just add an alias chmod => set-file-modes (for those people who
are used to unix), and everybody's happy!  Er, I think.

-miles
--
Do not taunt Happy Fun Ball.

Re: File modes facilities.

[Michael Cadilhac]

Miles Bader <snogglethorpe@gmail.com> writes:

> 2005/10/20, Kevin Ryde <user42@zip.com.au>:
>> I made myself M-x chmod below, to change the current visited file.  I
>> usually just want to make a script executable.  I know there's an
>> executable-chmod or something, but I can never remember and prefer
>> typing 755 or 700.  The save-buffer is in case it's a new file.
>
> Why not (1) Give `set-file-modes' an interactive spec (defaulting to
> the current buffer's filename), and (2) make `set-file-modes'
> understand chmod-style strings as well as integer modes (I guess the
> interactive spec would have to decide how to parse integers -- would
> defaulting to octal be reasonable?).

  Isn't that more or less what I proposed in my package proposal ?
  - A `chmod-style strings' parser,
  - A facility to have M-x chmod understand both octal and symbolic
    modes,
  - A way to change the current file modes without saving it.

  ?

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 08.70.65.13.14 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |