headers
Luc Teirlinck | 1 Feb 2006 01:27
Picon

Re: Instead of `risky-local-variable'

Richard Stallman wrote:

   I'm considering a more reliable replacement for the
   `risky-local-variable' mechanism.  My idea is that only defcustom'ed
   variables could be specified in a local variables list, and that the
   :type together with the specified value would determine whether a
   variable is safe.

   What do people think?

I personally think that this sounds like a pretty radical change,
supposedly "relatively shortly" before a release.  Any reason why this
can not wait till after the release?

Sincerely,

Luc.
Permalink | Reply | 5 comments |
headers
Stefan Monnier | 1 Feb 2006 01:37
Picon

Re: Risky local variable mechanism

> A few days ago I sent a message about possibly replacing the risky
> local variable mechanism with something safer.  Nobody has responded
> yet.  This problem is important; please help me think about the issue.

I rarely use file-local variables, so it's hard for me to figure out which
set of restrictions will be best.  Using custom types sounds like a good
idea, but note that setting "boolean" variables can be dangerous as well
(e.g. enable-local-eval).  I guess we need to play with it a bit.
But if we change the way it works, I think it might be a good idea to make
sure that what we define is "really" safe.  I.e. we only allow some
known-safe variable settings.  Maybe "string and integer custom vars" are
all safe, I don't know.

Otherwise we could simply introduce a "safe-local-variable" property which
we'd add to every variable we decide is safe to set.  Its value could also
be a predicate (instead of just t) to allow finer settings.

        Stefan
Permalink | Reply | 72 comments |
headers
Luc Teirlinck | 1 Feb 2006 01:41
Picon

Re: Risky local variable mechanism

Stefan Monnier wrote:

   Otherwise we could simply introduce a "safe-local-variable" property which
   we'd add to every variable we decide is safe to set.  Its value could also
   be a predicate (instead of just t) to allow finer settings.

Introduce?  That is exactly what we have already, is it not?

Sincerely,

Luc.
Permalink | Reply | 1 comment |
headers
Juanma Barranquero | 1 Feb 2006 02:13
Picon
Gravatar

multi-occur-in-matching-buffers error

M-x multi-occur-in-matching-buffers RET
 => "Symbol's value as variable is void: allbufs"

And there's a reference to argument nlines, which does not exist.
Perhaps it should be to allbufs.

--
                    /L/e/k/t/u
Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Feb 2006 02:25
Favicon

Re: Display slowness that is painful

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

> A change in image-mode can't fix this problem.  I did not visit that
> file; I produced it in a buffer with base64-decode.  It was not in
> Image mode.
>
> The change in Image mode might avoid the problem in many cases, and it
> might be correct, but it doesn't fix this bug.  The bug is at the
> level of redisplay, and it has to be fixed there.

This is *really* not the time to make changes in redisplay.  I think
the problem here is simply that if you want to display characters as
\XXX, the redisplay iterator has to go through four times as many
glyphs.

How about simply making unibyte_display_via_language_environment
default to t?  That's basically the situation in Emacs 21, and it
makes display responsive again.
Permalink | Reply | 48 comments |
headers
Chong Yidong | 1 Feb 2006 03:30
Favicon

Re: Risky local variable mechanism

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

> A few days ago I sent a message about possibly replacing the risky
> local variable mechanism with something safer.  Nobody has responded
> yet.  This problem is important; please help me think about the issue.

If you want to be really restrictive, you can introduce a list of
`safe-local-variables', and prompt for anything outside that list (the
prompt could have an additional choice, [(a) always allow this
variable], a variable to the list).

Setting `enable-local-variables' to (e.g.) 'unless-risky could bring
back the old behavior, i.e., allowing everything except those marked
as risky.

It seems like people only actually use a handful of file variables,
anyway.  From looking at the source trees of Emacs and some other
projects, the file local variables in use are:

allout-layout
byte-compile-dynamic
byte-compile-warnings
c-basic-offset
c-indent-level
coding
compile-command
fill-column
fill-prefix
indent-tabs-mode
kept-new-versions
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefan Monnier | 1 Feb 2006 03:39
Picon

Re: Risky local variable mechanism

>    Otherwise we could simply introduce a "safe-local-variable" property
>    which we'd add to every variable we decide is safe to set.  Its value
>    could also be a predicate (instead of just t) to allow finer settings.

> Introduce?  That is exactly what we have already, is it not?

Do we?  Oh I guess we do, but we don't really use it much, because we rely
on risky-local-variable instead.  So my suggestion would then be to remove
risky-local-variable and only rely on safe-local-variable.

        Stefan
Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Feb 2006 03:46
Favicon

Re: Instead of `risky-local-variable'

> I'm considering a more reliable replacement for the
> `risky-local-variable' mechanism.  My idea is that only defcustom'ed
> variables could be specified in a local variables list, and that the
> :type together with the specified value would determine whether a
> variable is safe.

This won't work for defcustoms that haven't been loaded yet.
Permalink | Reply | 2 comments |
headers
Stefan Monnier | 1 Feb 2006 03:59
Picon

Re: Display slowness that is painful

> This is *really* not the time to make changes in redisplay.  I think
> the problem here is simply that if you want to display characters as
> \XXX, the redisplay iterator has to go through four times as many
> glyphs.

Huh?  Four times more glyphs per char/byte, yes.
But four times fewer chars/bytes get displayed, so it should be a wash.

In utf-8 environments, unibyte_display_via_language_environment doesn't make
much sense, and around here utf-8 environments are becoming the norm.

        Stefan
Permalink | Reply | 5 comments |
headers
Eli Zaretskii | 1 Feb 2006 05:19
Picon

Re: emacs/info/dir

> From: "Richard M. Stallman" <rms <at> gnu.org>
> CC: emacs-devel <at> gnu.org
> Date: Tue, 31 Jan 2006 18:09:35 -0500
> 
>     Spurious diffs when comparing to DIR created/rearranged by
>     install-info.
> 
> I don't follow.  Would you please be less terse?

I meant diffs due to white space.

Anyway, I don't think this little issue justifies such a prolonged
discussion.  If you want to take the change out, go ahead, and let's
move on.  We have more important things to do with our time.
Permalink | Reply | 0 comments |

Gmane