tex-mode.el dependency on (cl) every?

tex-mode.el dependency on (cl) every?

[David Kastrup]

I see that we have

+(put 'tex-verbatim-environments 'safe-local-variable
+     (lambda (x) (require 'cl) (every 'stringp x)))

Couldn't we rather use the equivalent
  (lambda (x) (null (delq t (mapcar 'stringp x))))
instead?

And why is this needed at all?  tex-verbatim-environments is only ever
passed to regexp-opt and member, so any old value will be _safe_.  So
it should be ok just to do

(put 'tex-verbatim-environments 'safe-local-variable t)

shouldn't it?

-- 
David Kastrup

Re: tex-mode.el dependency on (cl) every?

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> I see that we have
>
> +(put 'tex-verbatim-environments 'safe-local-variable
> +     (lambda (x) (require 'cl) (every 'stringp x)))
>
> Couldn't we rather use the equivalent
>   (lambda (x) (null (delq t (mapcar 'stringp x))))
> instead?
>
> And why is this needed at all?  tex-verbatim-environments is only ever
> passed to regexp-opt and member, so any old value will be _safe_.  So
> it should be ok just to do
>
> (put 'tex-verbatim-environments 'safe-local-variable t)
>
> shouldn't it?

Well, or
(put 'tex-verbatim-environments 'safe-local-variable 'listp)
at least.

-- 
David Kastrup

Re: tex-mode.el dependency on (cl) every?

[Stefan Monnier]

> And why is this needed at all?  tex-verbatim-environments is only ever
> passed to regexp-opt and member, so any old value will be _safe_.  So
> it should be ok just to do

> (put 'tex-verbatim-environments 'safe-local-variable t)

We like `safe-local-variable' to be conservative.  To reduce probablity of
introducing holes in the future.


        Stefan

Re: tex-mode.el dependency on (cl) every?

[David Kastrup]

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

>> And why is this needed at all?  tex-verbatim-environments is only ever
>> passed to regexp-opt and member, so any old value will be _safe_.  So
>> it should be ok just to do
>
>> (put 'tex-verbatim-environments 'safe-local-variable t)
>
> We like `safe-local-variable' to be conservative.  To reduce probablity of
> introducing holes in the future.

listp is ok here, I think.  Anyway, since in most cases
"safe-local-variable" amounts to "matches type defined by customize"
anyway, why don't we just add something like an explicit ":safe" tag
to our customization types?  This could cover part or all of the
customization type, and so everything not matching the "safe" parts of
a customization pattern (including not matching the customize type at
all) would be considered unsafe.

Since the "safe" tag would be a visible part of the customization
type, the likelihood of introducing eval-capable extensions without
thinking about security implications would likely be less than what we
have now.

-- 
David Kastrup

Re: tex-mode.el dependency on (cl) every?

[Richard Stallman]

I installed this change.
Thanks.