Emacs server/client and --eval and security

Emacs server/client and --eval and security

[Stefan Monnier]

I've just installed a patch to server.el and emacsclient.c
that make them use a socket in a private subdir rather than
directly in /tmp.

Please try it out to see if the security checks are not too strict
and please read the code to try and figure out if the security
checks are strict enough.


	Stefan

Autoloads and (t . SYM) in load-history

[Stefan Monnier]

What was the reason for the following change ?


2002-12-07  Richard M. Stallman  <rms@gnu.org>

	* lread.c (syms_of_lread) <load-history>: Doc fix.

	* eval.c (Fdefun, Fdefmacro): Record in load-history redefining an
	autoload.

	* data.c (Fdefalias): Record in load-history redefining an autoload.


There's already another convention related to the above when
a function is autoloaded.  It involves the `autoload' symbol
property and the Vautoload_queue variable.
Although I'm not 100% sure what it does and what it should do,
it seems that the two things might usefully be merged.
Any thought ?


	Stefan

Re: Autoloads and (t . SYM) in load-history

[Richard Stallman]

    What was the reason for the following change ?

I think it was for the sake of unload-feature, to turn the
function back into an autoload.

    There's already another convention related to the above when
    a function is autoloaded.  It involves the `autoload' symbol
    property and the Vautoload_queue variable.

I guess it would work to use Vautoload_queue at the end of loading
to update the load history, instead of doing it directly as I did.
I am not sure this is worth doing.  It might be easier just to add
a comment on each mechanism pointing to the other one.

One complication in combining them is that Vautoload_queue is set up
only when loading for the sake of an autoload.  For other calls to
load, Vautoload_queue is not used.

Also, the name Vautoload_queue is misleading because that variable
is not a Lisp variable.  The name should probably be changed.

Re: Autoloads and (t . SYM) in load-history

[Stefan Monnier]

>     What was the reason for the following change ?
> 
> I think it was for the sake of unload-feature, to turn the
> function back into an autoload.
> 
>     There's already another convention related to the above when
>     a function is autoloaded.  It involves the `autoload' symbol
>     property and the Vautoload_queue variable.
> 
> I guess it would work to use Vautoload_queue at the end of loading
> to update the load history, instead of doing it directly as I did.
> I am not sure this is worth doing.  It might be easier just to add
> a comment on each mechanism pointing to the other one.
> 
> One complication in combining them is that Vautoload_queue is set up
> only when loading for the sake of an autoload.  For other calls to
> load, Vautoload_queue is not used.
> 
> Also, the name Vautoload_queue is misleading because that variable
> is not a Lisp variable.  The name should probably be changed.

I was thinking of merging things as follows:

- Keep your changes, except that instead of pushing (t . FUN)
  onto the load history, we add the autoload data to the
  `autoload' symbol property.
- Instead of using Vautoload_queue, we rely on the `autoload'
  symbol property and the load-history in un_autoload (which
  is also used by Frequire).

That would also be a good step towards merging un_autoload
and unload-feature.


	Stefan

Re: Autoloads and (t . SYM) in load-history

[Richard Stallman]

    I was thinking of merging things as follows:

    - Keep your changes, except that instead of pushing (t . FUN)
      onto the load history, we add the autoload data to the
      `autoload' symbol property.
    - Instead of using Vautoload_queue, we rely on the `autoload'
      symbol property and the load-history in un_autoload (which
      is also used by Frequire).

I have nothing against it, assuming it works correctly,
but it does not seem like a change worth spending any time on.

It would be better to implement a feature that will actually benefit
users.