HOW CAN I STOP THIS NOVICE MODE STUFF?

HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bruce Korb]

Please?  I hate it.  This one seems unstoppable and won't even
let me paste it in.  Emacs really does not know better than me.
I DO NOT WANT TO SEE THIS STUFF.

The local variables list in gnupload
contains variables that are risky (**)

Do you want to apply it?  You can type
y  -- ...
n  -- ...

 ** like hell.  Just do what you are told and leave me alone.
    You won't even let me copy and paste the message because it
    is in a buffer that gets erased and the emacs mode is such
    that the absolutely only allowable thing is to type "y" or 'n'
    because it is so crucially important that you must disrupt my work.

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Lennart Borgman (gmail)]

Bruce Korb wrote:
> Please?  I hate it.  This one seems unstoppable and won't even
> let me paste it in.  Emacs really does not know better than me.
> I DO NOT WANT TO SEE THIS STUFF.
> 
> The local variables list in gnupload
> contains variables that are risky (**)
> 
> Do you want to apply it?  You can type
> y  -- ...
> n  -- ...
> 
>  ** like hell.  Just do what you are told and leave me alone.
>     You won't even let me copy and paste the message because it
>     is in a buffer that gets erased and the emacs mode is such
>     that the absolutely only allowable thing is to type "y" or 'n'
>     because it is so crucially important that you must disrupt my work.

See

   (info "(emacs) Safe Local Variables")

and

    C-h v enable-local-variables

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Andreas Schwab]

Bruce Korb <Bruce.Korb@gmail.com> writes:

> Please?  I hate it.  This one seems unstoppable and won't even
> let me paste it in.  Emacs really does not know better than me.
> I DO NOT WANT TO SEE THIS STUFF.

So you want to allow everyone to erase all your files?

Andreas.

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

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bastien]

Bruce Korb <Bruce.Korb@gmail.com> writes:

> Please?  I hate it.  This one seems unstoppable and won't even
> let me paste it in.  Emacs really does not know better than me.
> I DO NOT WANT TO SEE THIS STUFF.

No need to shout.  And this is not a bug, so please post such requests
to help-gnu-emacs@gnu.org instead.

PS: not being able to reach the documentation pages for local variables
does not prove Emacs should behave as if you were an expert.  Grin.

-- 
Bastien

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Michael Schierl]

On Mon, 24 Dec 2007 15:00:03 +0100, Bastien wrote:

> PS: not being able to reach the documentation pages for local variables
> does not prove Emacs should behave as if you were an expert.  Grin.

And BTW you could copy the buffer if you were an expert:

M-x toggle-debug-on-quit

and then just press C-g at the prompt. Copy the stuff and [c]ontinue from
the Lisp debugger.

HAND

Michael

-- 
#!/usr/bin/perl -I' # tekscribble.pl - start in an xterm and scribble with mouse
$|=1;$g="\35";sub g{getc}sub p{print@_}system"stty -icanon";p"\233?38h";for(;;){
p"$g\33\32";$_=g;$x=g;$X=g;$y=g;$Y=g;last if/q/;$k=$y.chr((ord$Y)+64).$x.chr((
ord$X)+32);p"\33\14"if/c/;p$g.(/ì/?$l:$k).$k;$l=$k;}p"\33\3";system"stty icanon"

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bruce Korb]

Andreas Schwab wrote:
> Bruce Korb <Bruce.Korb@gmail.com> writes:
> 
>> Please?  I hate it.  This one seems unstoppable and won't even
>> let me paste it in.  Emacs really does not know better than me.
>> I DO NOT WANT TO SEE THIS STUFF.
> 
> So you want to allow everyone to erase all your files?

Hi Andreas, Lennart,

"anyone", I would hope :).  Perhaps I was mistaken.  I thought
these incantations were constrained to setting buffer local
variable values.  If they can execute arbitrary emacs lisp code,
then it sounds very Microsoft-like.  ``Let it be easy for
content providers and painful to secure.''  If emacs has really
become "that powerful" then there's nothing for it but to go
back to old versions or back to vi.  I disliked vi in 1974,
despite "ed" being the only competition.

C.F. ``See "(info ...)" and "Ch-v v enable-local-variables'', I
am afraid that does not address this issue.  Extracted from .emacs:

  (setq enable-local-variables    't)
  (setq enable-recursive-minibuffers 't)
  (setq hack-local-variables      't)

Cheers - Bruce

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Lennart Borgman (gmail)]

Bruce Korb wrote:
> Andreas Schwab wrote:
>> Bruce Korb <Bruce.Korb@gmail.com> writes:
>>
>>> Please?  I hate it.  This one seems unstoppable and won't even
>>> let me paste it in.  Emacs really does not know better than me.
>>> I DO NOT WANT TO SEE THIS STUFF.
>> So you want to allow everyone to erase all your files?
> 
> Hi Andreas, Lennart,
> 
> "anyone", I would hope :).  Perhaps I was mistaken.  I thought
> these incantations were constrained to setting buffer local
> variable values.  If they can execute arbitrary emacs lisp code,
> then it sounds very Microsoft-like.  ``Let it be easy for
> content providers and painful to secure.''  If emacs has really
> become "that powerful" then there's nothing for it but to go
> back to old versions or back to vi.  I disliked vi in 1974,
> despite "ed" being the only competition.
> 
> C.F. ``See "(info ...)" and "Ch-v v enable-local-variables'', I
> am afraid that does not address this issue.  Extracted from .emacs:
> 
>   (setq enable-local-variables    't)
>   (setq enable-recursive-minibuffers 't)
>   (setq hack-local-variables      't)
> 
> Cheers - Bruce


Hi Bruce, can you please tell what you think is not explained? Did you 
read what the value t means for enable-local-variables?

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Michael Schierl]

On Tue, 25 Dec 2007 09:45:07 -0800, Bruce Korb wrote:

> "anyone", I would hope :).  Perhaps I was mistaken.  I thought
> these incantations were constrained to setting buffer local
> variable values.  

Even if they were: there are some buffer-local variables (for syntax
highlighting for example) whose subexpressions are evaluated. And, there
are local hook variables which contain Lisp code as well. So, even if
enable-local-eval is disabled (as it is by default), you could use
"backdoors" to introduce your own Lisp code by setting the right local
variables.

Therefore, every local variable that is not marked as safe-local-variable
(by the packages that declares it) will cause an "annoying" warning (which
gives you an option to ignore it the next time). On the other hand, a
variable is marked as risky-local-variable, the option

!  -- to apply the local variables list, and permanently mark these
      values (*) as safe (in the future, they will be set automatically.)

will not show up, so you will be asked over and over.

So, to avoid these messages, the best way IMHO is to ask the package
maintainer to mark the variable you want to set in your local variables as
safe.

> If they can execute arbitrary emacs lisp code,
> then it sounds very Microsoft-like.  ``Let it be easy for
> content providers and painful to secure.''  If emacs has really
> become "that powerful" then there's nothing for it but to go
> back to old versions or back to vi.  I disliked vi in 1974,
> despite "ed" being the only competition.

You can disable the local variables stuff completely, if you think it is
too insecure.

> C.F. ``See "(info ...)" and "Ch-v v enable-local-variables'', I
> am afraid that does not address this issue.  Extracted from .emacs:
> 
>   (setq enable-local-variables    't)


a) you do not need to quote t, it will quote itself
b) t and :all is not the same
c) you do not need to quote :all either :)

You can add the variable and its value to safe-local-variable-values if you
do not want to allow all variables.

Michael
-- 
#!/usr/bin/perl -I' # tekscribble.pl - start in an xterm and scribble with mouse
$|=1;$g="\35";sub g{getc}sub p{print@_}system"stty -icanon";p"\233?38h";for(;;){
p"$g\33\32";$_=g;$x=g;$X=g;$y=g;$Y=g;last if/q/;$k=$y.chr((ord$Y)+64).$x.chr((
ord$X)+32);p"\33\14"if/c/;p$g.(/ì/?$l:$k).$k;$l=$k;}p"\33\3";system"stty icanon"

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Richard Stallman]

    "anyone", I would hope :).  Perhaps I was mistaken.  I thought
    these incantations were constrained to setting buffer local
    variable values.

Yes, but there are variables whose values can get evaluated by Emacs
commands.  That's the motive for this feature: to make sure those
variables don't get set by some file to a malicious value.

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bruce Korb]

Richard Stallman wrote:
>     "anyone", I would hope :).  Perhaps I was mistaken.  I thought
>     these incantations were constrained to setting buffer local
>     variable values.
> 
> Yes, but there are variables whose values can get evaluated by Emacs
> commands.  That's the motive for this feature: to make sure those
> variables don't get set by some file to a malicious value.

And the net result is a loss of usability because at least I do not
appreciate being interrupted from my work to answer "are you sure"
questions on files I open and close a fair amount.  The "you've never
set this kind of variable before, do you really want to do that?!?!?!"
question is a nuisance because I don't really want to enumerate
everything, but this one is a bigger hassle.  Perhaps add something
like:

/*
 * Local Variables:
 * .....
 * user-approves-of-everything: bkorb
 * End:
 */

and then just not ask questions of "bkorb" would take care of this?

Anyway, today's question has to do with some other setting that is
not readily solved with googling for

   emacs "does not run" in "separate window"

I can, in fact, C-x 5 2 and create another window and then Alt-F4
kill off the original window, but I'd rather have (emacs &) simply
spawn another window.  There must be some setting that changed, but
there sure is no obvious setting that I know about.  Disabling the
"~/.emacs" config file has no effect.  Googling got me to someone
suggesting a different OS/X binary, but nothing else of interest.
What should I be looking for?  Thank you - Bruce


P.S.  In case it helps, .Xdefaults:

Emacs.font:         7x13
Emacs.BorderWidth:  0
Emacs.geometry:     81x100
Emacs.MenuBar:      off
Emacs.ToolBar:      off
Emacs.VerticalScrollBars:   left

But none of this has changed in the last couple of weeks

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Dan Nicolaescu]

Bruce Korb <Bruce.Korb@gmail.com> writes:

  > Richard Stallman wrote:
  > >     "anyone", I would hope :).  Perhaps I was mistaken.  I thought
  > >     these incantations were constrained to setting buffer local
  > >     variable values.
  > > 
  > > Yes, but there are variables whose values can get evaluated by Emacs
  > > commands.  That's the motive for this feature: to make sure those
  > > variables don't get set by some file to a malicious value.
  > 
  > And the net result is a loss of usability because at least I do not
  > appreciate being interrupted from my work to answer "are you sure"
  > questions on files I open and close a fair amount.  The "you've never
  > set this kind of variable before, do you really want to do that?!?!?!"
  > question is a nuisance because I don't really want to enumerate
  > everything, but this one is a bigger hassle.  Perhaps add something
  > like:
  > 
  > /*
  >  * Local Variables:
  >  * .....
  >  * user-approves-of-everything: bkorb
  >  * End:
  >  */

Can you please post the contents of the local variables section for the
file that causes this?

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bruce Korb]

Dan Nicolaescu wrote:
>   > /*
>   >  * Local Variables:
>   >  * .....
>   >  * user-approves-of-everything: bkorb
>   >  * End:
>   >  */
> 
> Can you please post the contents of the local variables section for the
> file that causes this?

It is not germane because I refer to any such variable,
but most especially to those that are unfixable and trigger
this ``Do you want to apply it?'' unsuppressable message.

Anyway, here you go:



(defun hack-local-variables-confirm (vars unsafe-vars risky-vars)
  (if noninteractive
      nil
    (let ((name (if buffer-file-name
		    (file-name-nondirectory buffer-file-name)
		  (concat "buffer " (buffer-name))))
	  (offer-save (and (eq enable-local-variables t) unsafe-vars))
	  prompt char)
      (save-window-excursion
	(let ((buf (get-buffer-create "*Local Variables*")))
	  (pop-to-buffer buf)
	  (set (make-local-variable 'cursor-type) nil)
	  (erase-buffer)
	  (if unsafe-vars
	      (insert "The local variables list in " name
		      "\ncontains values that may not be safe (*)"
		      (if risky-vars
			  ", and variables that are risky (**)."
			"."))
	    (if risky-vars
		(insert "The local variables list in " name
			"\ncontains variables that are risky (**).")
	      (insert "A local variables list is specified in " name ".")))
	  (insert "\n\nDo you want to apply it?  You can type
y  -- to apply the local variables list.
n  -- to ignore the local variables list.")
	  (if offer-save
	      (insert "
!  -- to apply the local variables list, and permanently mark these
      values (*) as safe (in the future, they will be set automatically.)\n\n")
	    (insert "\n\n"))

Things to note:

1.  There is no convenient way to just hush the thing up and tell it,
    "I do not mess with untrustworthy files.  Leave me alone."

2.  Sometimes, even "offer-save" is false, so the possibility of
    saying "don't bother me with this any more" is not allowed.

What do you mean by, "not allowed"?  I know my wants and needs better
than any silly program.  Really.  I do.  Perhaps I should replace this:

(defun hack-local-variables-confirm (_v _uv _rv) #t)

Yes?

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Dan Nicolaescu]

Bruce Korb <Bruce.Korb@gmail.com> writes:

  > Dan Nicolaescu wrote:
  > >   > /*
  > >   >  * Local Variables:
  > >   >  * .....
  > >   >  * user-approves-of-everything: bkorb
  > >   >  * End:
  > >   >  */
  > > 
  > > Can you please post the contents of the local variables section for the
  > > file that causes this?
  > 
  > It is not germane because I refer to any such variable,
  > but most especially to those that are unfixable and trigger

It is, please send the list of variables that you have issues with.
If such variables are defined in emacs itself, then the policy is to
determine what type of arguments are safe for the variables. If the
variables are defined in a package, then it is that package's duty to
mark them as safe.  
The above is the current policy.

Unless you show that the policy is somehow wrong, you'd have trouble
convincing people to change it (which is what you propose).

One way to try to show that the current state of affairs is wrong is to
show actual example where this happens.

Just my 2 cents.

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Bruce Korb]

Dan Nicolaescu wrote:
> It is, please send the list of variables that you have issues with.
> If such variables are defined in emacs itself, then the policy is to
> determine what type of arguments are safe for the variables. If the
> variables are defined in a package, then it is that package's duty to
> mark them as safe.

How does "the package" do that?  If the gnulib project doesn't
do this, then which package providers actually do know the code?

> The above is the current policy.
> 
> Unless you show that the policy is somehow wrong, you'd have trouble
> convincing people to change it (which is what you propose).

What I think I am asking for is documentation on how to make this test:

     (eq enable-local-variables :all)

yield "#t" (or however it is spelled in emacs lisp).
Would that be:

      (set enable-local-variables  :all)

in my .emacs file?  Another part of my request is that I think it
is a little over the top to have to delve into the emacs lisp code
to the point were I found the ``(eq enable-local-variables :all)''
test at all.  :(

> 
> Just my 2 cents.

I'm certain I'm well into the dollars by now.  ;-)

Thank you - Bruce

Re: HOW CAN I STOP THIS NOVICE MODE STUFF?

[Dan Nicolaescu]

Bruce Korb <Bruce.Korb@gmail.com> writes:

  > Dan Nicolaescu wrote:
  > > It is, please send the list of variables that you have issues with.
  > > If such variables are defined in emacs itself, then the policy is to
  > > determine what type of arguments are safe for the variables. If the
  > > variables are defined in a package, then it is that package's duty to
  > > mark them as safe.
  > 
  > How does "the package" do that?  

Fro example
(put 'VARIABLE_NAME 'safe-local-variable 'integerp)
for a variable that is of type interger. There are many examples of this
in the emacs source code.


  > If the gnulib project doesn't do this, then which package providers
  > actually do know the code?

I can't parse this.


  > > The above is the current policy.
  > > 
  > > Unless you show that the policy is somehow wrong, you'd have trouble
  > > convincing people to change it (which is what you propose).
  > 
  > What I think I am asking for is documentation on how to make this test:
  > 
  >      (eq enable-local-variables :all)
  > 
  > yield "#t" (or however it is spelled in emacs lisp).
  > Would that be:
  > 
  >       (set enable-local-variables  :all)
  > 
  > in my .emacs file?  Another part of my request is that I think it
  > is a little over the top to have to delve into the emacs lisp code
  > to the point were I found the ``(eq enable-local-variables :all)''
  > test at all.  :(

As I said in my previous email there's no way to do this and AFAIK no
desire to do it because it does not seem necessary. If you want this to
change you'd have to show it is necessary.  Precise examples of problems
would be a good start for a proof.

local variable for updating the time stamp on save (was: Re: HOW CAN I STOP THIS NOVICE MODE STUFF?)

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Bruce Korb <Bruce.Korb@gmail.com> writes:
  > 
  >   > Dan Nicolaescu wrote:
  >   > > It is, please send the list of variables that you have issues with.
  >   > > If such variables are defined in emacs itself, then the policy is to
  >   > > determine what type of arguments are safe for the variables. If the
  >   > > variables are defined in a package, then it is that package's duty to
  >   > > mark them as safe.
  >   > 
  >   > How does "the package" do that?  
  > 
  > Fro example
  > (put 'VARIABLE_NAME 'safe-local-variable 'integerp)
  > for a variable that is of type interger. There are many examples of this
  > in the emacs source code.
  > 
  > 
  >   > If the gnulib project doesn't do this, then which package providers
  >   > actually do know the code?
  > 
  > I can't parse this.

Hmm, so gnulib is a library (never heard of it before). I downloaded it
and looked at all the Local Variables section in all the files. Some of
the variables used were not marked as safe in Emacs, this was causing
warnings. I marked them as safe on the emacs-22.2 CVS branch. It will
get merged into CVS HEAD soon.

The only issue left with the local variables in gnulib is: 
# eval: (add-hook 'write-file-hooks 'time-stamp)

This cannot be marked as safe as it is.
Does anyone know if we already have a solution for something that
updates the time stamps when saving?
If not, do we want to add such a solution?
What would that solution be?

Re: local variable for updating the time stamp on save (was: Re: HOW CAN I STOP THIS NOVICE MODE STUFF?)

[Richard Stallman]

Bruce wrote:

      > What I think I am asking for is documentation on how to make this test:
      > 
      >      (eq enable-local-variables :all)
      > 
      > yield "#t" (or however it is spelled in emacs lisp).
      > Would that be:
      > 
      >       (set enable-local-variables  :all)
      > 
      > in my .emacs file?

(setq enable-local-variables :all) could do it, but that is a really
bad idea.  It means that a nasty file sent to you, which you then
visit in Emacs, could make your Emacs do anything at all.

    The only issue left with the local variables in gnulib is: 
    # eval: (add-hook 'write-file-hooks 'time-stamp)

Bruce, you can add this to `safe-local-eval-forms'.  Does that work
for you?

Maybe we should add it to the default value of
`safe-local-eval-forms'.

Re: local variable for updating the time stamp on save (was: Re: HOW CAN I STOP THIS NOVICE MODE STUFF?)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Bruce wrote:
  > 
  >       > What I think I am asking for is documentation on how to make this test:
  >       > 
  >       >      (eq enable-local-variables :all)
  >       > 
  >       > yield "#t" (or however it is spelled in emacs lisp).
  >       > Would that be:
  >       > 
  >       >       (set enable-local-variables  :all)
  >       > 
  >       > in my .emacs file?
  > 
  > (setq enable-local-variables :all) could do it, but that is a really
  > bad idea.  It means that a nasty file sent to you, which you then
  > visit in Emacs, could make your Emacs do anything at all.
  > 
  >     The only issue left with the local variables in gnulib is: 
  >     # eval: (add-hook 'write-file-hooks 'time-stamp)
  > 
  > Bruce, you can add this to `safe-local-eval-forms'.  Does that work
  > for you?
  > 
  > Maybe we should add it to the default value of
  > `safe-local-eval-forms'.

IMO we should. config.guess and config.sub use that form. Luckily very
few people need to edit those files...

Re: local variable for updating the time stamp on save (was: Re: HOW CAN I STOP THIS NOVICE MODE STUFF?)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

y  > Bruce wrote:
  > 
  >       > What I think I am asking for is documentation on how to make this test:
  >       > 
  >       >      (eq enable-local-variables :all)
  >       > 
  >       > yield "#t" (or however it is spelled in emacs lisp).
  >       > Would that be:
  >       > 
  >       >       (set enable-local-variables  :all)
  >       > 
  >       > in my .emacs file?
  > 
  > (setq enable-local-variables :all) could do it, but that is a really
  > bad idea.  It means that a nasty file sent to you, which you then
  > visit in Emacs, could make your Emacs do anything at all.
  > 
  >     The only issue left with the local variables in gnulib is: 
  >     # eval: (add-hook 'write-file-hooks 'time-stamp)
  > 
  > Bruce, you can add this to `safe-local-eval-forms'.  Does that work
  > for you?
  > 
  > Maybe we should add it to the default value of
  > `safe-local-eval-forms'.

I have done that as per your request. (on the EMACS_22_BASE branch)

Bruce, do you get any other unsafe variable warnings?

Re: local variable for updating the time stamp on save

[Bruce Korb]

Dan Nicolaescu wrote:
> I have done that as per your request. (on the EMACS_22_BASE branch)
> 
> Bruce, do you get any other unsafe variable warnings?

At the moment, no.  Thank you.  I just updated to GNU Emacs 22.1.1
and plodded my way through variable after variable triggering the
"we've never set this variable before.  Are sure you want to do
this?" over and over and then I hit this one that wouldn't allow
me to say, "YES! Now, leave me alone!!".  It did get rather
repetitive and irritating, even with just the ones I was "allowed"
to hush up.

Again, thank you!

Regards, Bruce

Re: local variable for updating the time stamp on save

[Richard Stallman]

    At the moment, no.  Thank you.  I just updated to GNU Emacs 22.1.1
    and plodded my way through variable after variable triggering the
    "we've never set this variable before.  Are sure you want to do
    this?" over and over

Can you find the list of the ones you accepted, and send it to us?
Maybe we should mark some of them for acceptance by default.

Re: local variable for updating the time stamp on save

[Bruce Korb]

On Jan 16, 2008 12:31 AM, Richard Stallman <rms@gnu.org> wrote:
>     At the moment, no.  Thank you.  I just updated to GNU Emacs 22.1.1
>     and plodded my way through variable after variable triggering the
>     "we've never set this variable before.  Are sure you want to do
>     this?" over and over
>
> Can you find the list of the ones you accepted, and send it to us?
> Maybe we should mark some of them for acceptance by default.

Hi Richard,

I have a "safe-local-variables-values" both at home and at work.  For some
administrative reason, my work one got reset to empty and now only
contains:

'(safe-local-variable-values (quote ((sh-indentation . 2)
(sh-basic-offset . 4) (sh-basic-offset . 2))))

But I'd simply say that anything containing "indent" or "offset" is
pretty likely
to be "pretty safe".  I still think it is better still to "allow" me to say that
this is a nifty feature that I don't like.  :)  I want to live
dangerously because
I don't edit files that might do such nasty things.  Thinking along those lines,
it might make more sense to be able to say "in this file hierarchy, I trust
everything" and "in that file hierarchy, I don't trust a thing."  I
just have little
use for the latter.

Cheers - Bruce

P.S. Have I mentioned that I have really liked using emacs since 1984?  :)

P.P.S. variables using "indent" in their names:

c-indent-comment-alist
  Variable: *Specifies how \[indent-for-comment] calculates the
comment start column.
c-indent-comments-syntactically-p
  Variable: *Specifies how \[indent-for-comment] should handle
comment-only lines.
c-label-minimum-indentation
  Variable: *Minimum indentation for lines inside code blocks.
c-special-indent-hook
  Variable: *Hook for user defined special indentation adjustments.
c-syntactic-indentation
  Variable: *Whether the indentation should be controlled by the
syntactic context.
c-syntactic-indentation-in-macros
  Variable: *Enable syntactic analysis inside macros.
c-tab-always-indent
  Variable: *Controls the operation of the TAB key.
custom-buffer-indent
  Variable: Number of spaces to indent nested groups.
fill-individual-varying-indent
  Variable: *Controls criterion for a new paragraph in
`fill-individual-paragraphs'.
indent-tabs-mode
  Variable: *Indentation can insert tabs if this is non-nil.
mail-indentation-spaces
  Variable: Number of spaces to insert at the beginning of each cited line.
message-indent-citation-function
  Variable: *Function for modifying a citation just inserted in the mail buffer.
sh-first-lines-indent
  Variable: *The indentation of the first non-blank non-comment line.
sh-indent-after-case
  Variable: *How much to indent a statement relative to the `case' statement.
sh-indent-after-do
  Variable: *How much to indent a line after a `do' statement.
sh-indent-after-done
  Variable: *How much to indent a statement after a `done' keyword.
sh-indent-after-else
  Variable: *How much to indent a statement after an `else' statement.
sh-indent-after-function
  Variable: *How much to indent after a function line.
sh-indent-after-if
  Variable: *How much to indent a statement after an `if' statement.
sh-indent-after-loop-construct
  Variable: *How much to indent a statement after a loop construct.
sh-indent-after-open
  Variable: *How much to indent after a line with an opening
parenthesis or brace.
sh-indent-after-switch
  Variable: *How much to indent a `case' statement relative to the
`switch' statement.
sh-indent-comment
  Variable: *How a comment line is to be indented.
sh-indent-for-case-alt
  Variable: *How much to indent statements after the case label.
sh-indent-for-case-label
  Variable: *How much to indent a case label statement.
sh-indent-for-continuation
  Variable: *How much to indent for a continuation statement.
sh-indent-for-do
  Variable: *How much to indent a `do' statement.
sh-indent-for-done
  Variable: *How much to indent a `done' relative to its matching
stmt.  Usually 0.
sh-indent-for-else
  Variable: *How much to indent an `else' relative to its `if'.  Usually 0.
sh-indent-for-fi
  Variable: *How much to indent a `fi' relative to its `if'.  Usually 0.
sh-indent-for-then
  Variable: *How much to indent a `then' relative to its `if'.
sh-indentation
  Variable: The width for further indentation in Shell-Script mode.
standard-indent
  Variable: *Default number of columns for margin-changing functions to indent.
tab-always-indent
  Variable: *Controls the operation of the TAB key.

Re: local variable for updating the time stamp on save

[Dan Nicolaescu]

"Bruce Korb" <bruce.korb@gmail.com> writes:

  > On Jan 16, 2008 12:31 AM, Richard Stallman <rms@gnu.org> wrote:
  > >     At the moment, no.  Thank you.  I just updated to GNU Emacs 22.1.1
  > >     and plodded my way through variable after variable triggering the
  > >     "we've never set this variable before.  Are sure you want to do
  > >     this?" over and over
  > >
  > > Can you find the list of the ones you accepted, and send it to us?
  > > Maybe we should mark some of them for acceptance by default.
  > 
  > Hi Richard,
  > 
  > I have a "safe-local-variables-values" both at home and at work.  For some
  > administrative reason, my work one got reset to empty and now only
  > contains:
  > 
  > '(safe-local-variable-values (quote ((sh-indentation . 2)
  > (sh-basic-offset . 4) (sh-basic-offset . 2))))

sh-indentation is already marked safe.
sh-basic-offset still needs to be marked as safe. I'll take care of it
soon.

  > But I'd simply say that anything containing "indent" or "offset" is
  > pretty likely
  > to be "pretty safe".  I still think it is better still to "allow" me to say that
  > this is a nifty feature that I don't like.  :)  I want to live
  > dangerously because

What we are trying to do is actually for users not have to care about
this, it should work without any action. For that we are trying to mark
as many variables safe as possible.

Maybe we can ask people on the emacs mailing lists to try to help with
this.  Find any variable not marked as safe that is used in any local
variable section in the code that they have access to.

Re: local variable for updating the time stamp on save

[Reiner Steib]

On Thu, Jan 17 2008, Dan Nicolaescu wrote:

> Maybe we can ask people on the emacs mailing lists to try to help with
> this.  Find any variable not marked as safe that is used in any local
> variable section in the code that they have access to.

Additional, maybe an option to report all such variables (using
`reporter.el') would be useful?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: local variable for updating the time stamp on save

[Richard Stallman]

    '(safe-local-variable-values (quote ((sh-indentation . 2)
    (sh-basic-offset . 4) (sh-basic-offset . 2))))

The former already has a property by default.
I will add it to the latter.

    But I'd simply say that anything containing "indent" or "offset" is
    pretty likely
    to be "pretty safe".

Likely, but not certain.  We have decided to be conservative here.

Re: local variable for updating the time stamp on save

[Bruce Korb]

Bruce Korb wrote:
> I have a "safe-local-variables-values" both at home and at work.  For some
> administrative reason, my work one got reset to empty and now only
> contains:
> 
> '(safe-local-variable-values (quote ((sh-indentation . 2)
> (sh-basic-offset . 4) (sh-basic-offset . 2))))

My home version:

 '(safe-local-variable-values (quote ((whitespace-check-buffer-indent) (c-syntactic-indentation) (c-syntactic-indentation-in-macros) (sh-basic-offset . 2) (sh-indentation . 2) (sh-basic-offset . 4) (sh-indentation . 4) (sh-basic-offset . 4) (sh-indentation . 4) (sh-basic-offset . 4) (Mode . shell-script) (ispell-local-pdict . "ispell-dict") (Mode . C) (sh-indentation . 4))))

I really don't like it.  :(

Re: local variable for updating the time stamp on save

[Dan Nicolaescu]

Bruce Korb <bkorb@gnu.org> writes:

  > Bruce Korb wrote:
  > > I have a "safe-local-variables-values" both at home and at work.  For some
  > > administrative reason, my work one got reset to empty and now only
  > > contains:
  > > 
  > > '(safe-local-variable-values (quote ((sh-indentation . 2)
  > > (sh-basic-offset . 4) (sh-basic-offset . 2))))
  > 
  > My home version:
  > 
  >  '(safe-local-variable-values (quote
  > ((whitespace-check-buffer-indent)

I fixed this one on Jan 3rd in the emacs-22.2 branch. You won't see it
after the next release.

  > (Mode . C)
  > (Mode . shell-script)

I think these might be mistakes, it should have "mode", not "Mode". Can
you please check the files where this occurred?

  > (c-syntactic-indentation)
  > (c-syntactic-indentation-in-macros) 

Fixed today.

  > (ispell-local-pdict . "ispell-dict")

Fixed Jan 3rd.

  > (sh-basic-offset . 2) 
  > (sh-basic-offset . 4)
  > (sh-basic-offset . 4)
  > (sh-basic-offset . 4) 

Fixed today.

  > (sh-indentation . 2) 
  > (sh-indentation . 4)
  > (sh-indentation . 4)
  > (sh-indentation . 4)

Fixed Jan 3rd.

It's interesting that you get so many duplicates in the list. That might
point to a possible problem in the code that deals with
safe-local-variable-values.

Re: local variable for updating the time stamp on save

[Bruce Korb]

On Jan 19, 2008 10:32 AM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> It's interesting that you get so many duplicates in the list. That might
> point to a possible problem in the code that deals with
> safe-local-variable-values.

Hi Dan,

s/might/surely/  :)  Likely the reason I found it sub-optimal.  It was asking
questions redundantly..

Anyway, for my project:

c-file-style
indent-tabs-mode
ispell-local-pdict
minor-mode
mode
sh-basic-offset
sh-indentation

For GCC:

ispell-local-pdict
c-font-lock-extra-types "JNIEnv" "JNINativeMethod" "JavaVM"
"JavaVMOption" "jarray" "jboolean" "jbooleanArray" "jbyte"
"jbyteArray" "jchar"  "jcharArray" "jclass" "jdouble" "jdoubleArray"
"jfieldID" "jfloat" "jfloatArray" "jint" "jintArray" "jlong"
"jlongArray" "jmethodID" "jobject" "jstring" "jthrowable" "jvalue"
"jweak" "jvmtiEnv" "jvmtiError" "jthread" "jthreadGroup" "jlocation"
"jrawMonitorID")
c-font-lock-extra-types "JNIEnv" "JNINativeMethod" "JavaVM"
"JavaVMOption" "jarray" "jboolean" "jbooleanArray" "jbyte"
"jbyteArray" "jchar"  "jcharArray" "jclass" "jdouble" "jdoubleArray"
"jfieldID" "jfloat" "jfloatArray" "jint" "jintArray" "jlong"
"jlongArray" "jmethodID" "jobject" "jstring" "jthrowable" "jvalue"
"jweak")
compile-command
eval
folded-file
indent-tabs-mode
mode
sh-indentation
tcl-indent-level
time-stamp-end
time-stamp-format
time-stamp-start

and for autotools:

coding
cperl-brace-offset
cperl-continued-brace-offset
cperl-continued-statement-offset
cperl-extra-newline-before-brace
cperl-indent-level
cperl-label-offset
cperl-merge-trailing-else
eval
fill-column
indent-tabs-mode
ispell-local-dictionary
ispell-local-pdict
mode
perl-brace-imaginary-offset
perl-brace-offset
perl-continued-brace-offset
perl-continued-statement-offset
perl-indent-level
perl-label-offset
sh-indentation
time-stamp-end
time-stamp-format
time-stamp-start
whitespace-check-buffer-indent

And remember that is _will_ be a few years before I see your Emacs fixes.
Distros don't pick up and propagate new versions straight away and I don't
upgrade my workstation distributions very often.  Takes a _lot_ of work!!

Re: local variable for updating the time stamp on save

[Dan Nicolaescu]

"Bruce Korb" <bkorb@gnu.org> writes:

  > On Jan 19, 2008 10:32 AM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > It's interesting that you get so many duplicates in the list. That might
  > > point to a possible problem in the code that deals with
  > > safe-local-variable-values.
  > 
  > Hi Dan,
  > 
  > s/might/surely/  :)  Likely the reason I found it sub-optimal.  It was asking
  > questions redundantly..
  > 
  > Anyway, for my project:
  > 
  > c-file-style
  > indent-tabs-mode

These should work.

  > minor-mode
  > mode

Not sure why you got those

  > ispell-local-pdict
  > sh-basic-offset
  > sh-indentation

I already said these are fixed.

  > c-font-lock-extra-types "JNIEnv" "JNINativeMethod" "JavaVM"

This still needs fixing. Alan can you please mark
c-font-lock-extra-types type to be safe? (not sure what the right
predicate is)

  > compile-command

Should work.

  > folded-file

Does not exist in emacs. 

  > indent-tabs-mode
  > mode
  > sh-indentation
  > tcl-indent-level
  > time-stamp-end
  > time-stamp-format
  > time-stamp-start

Should work. 


  > and for autotools:
  > 
  > coding

Don't know about this one.

  > cperl-brace-offset
  > cperl-continued-brace-offset
  > cperl-continued-statement-offset
  > cperl-extra-newline-before-brace
  > cperl-indent-level
  > cperl-label-offset
  > cperl-merge-trailing-else
  > fill-column
  > indent-tabs-mode
  > ispell-local-dictionary
  > ispell-local-pdict
  > mode
  > perl-brace-imaginary-offset
  > perl-brace-offset
  > perl-continued-brace-offset
  > perl-continued-statement-offset
  > perl-indent-level
  > perl-label-offset
  > sh-indentation
  > time-stamp-end
  > time-stamp-format
  > time-stamp-start
  > whitespace-check-buffer-indent

Should work.


  > And remember that is _will_ be a few years before I see your Emacs fixes.
  > Distros don't pick up and propagate new versions straight away and I don't
  > upgrade my workstation distributions very often.  Takes a _lot_ of work!!

Well, there's not much we can do about that. We can't offer to fix
issues in the past. The GNU Time Machine project it a bit behind
schedule (or ahead?).

Re: local variable for updating the time stamp on save

[Richard Stallman]

    It's interesting that you get so many duplicates in the list. That might
    point to a possible problem in the code that deals with
    safe-local-variable-values.

I looked at the code, and I don't see anything that could cause the
duplication.  The only place that changes the value does it with
`add-to-list', which tests using `member'.

Re: local variable for updating the time stamp on save

[Bruce Korb]

Hi,

On Jan 20, 2008 11:18 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
[....]
>   > minor-mode
>   > mode
>
> Not sure why you got those

I got them because I sedded 'em out of all files containing the string
'Local Variables:'
It wasn't that "mode" and "minor-mode" were added to the "they're okay
now" list,
but that they got extracted with the grep/sed/awk/sort script.  :)

Re: local variable for updating the time stamp on save

[Richard Stallman]

    Well, there's not much we can do about that. We can't offer to fix
    issues in the past. The GNU Time Machine project it a bit behind
    schedule (or ahead?).

I suspect that it is sending us into the future so fast
that bugs go for years without being fixed.

Re: local variable for updating the time stamp on save

[Richard Stallman]

      > and for autotools:
      > 
      > coding

    Don't know about this one.

`coding' is a "fake" variable you can specify in the -*- line to
specify the file's coding system.  If specifying that "variable"
causes questions, please send a precise test case and we will debug
it.

Re: local variable for updating the time stamp on save

[Bruce Korb]

On Jan 21, 2008 12:30 PM, Richard Stallman <rms@gnu.org> wrote:
>     Well, there's not much we can do about that. We can't offer to fix
>     issues in the past. The GNU Time Machine project it a bit behind
>     schedule (or ahead?).
>
> I suspect that it is sending us into the future so fast
> that bugs go for years without being fixed.

That sounds about right.   :)  It really stands as a caveat about
changing behavior.  It causes folks to stumble for years on end
before fixes propagate through all the layers.  Heck, I still have
to concern myself with shell anachronisms that were cleaned up
in the early 80's.  Solaris' /bin/sh is rather extreme though.

Thanks for fixing this stuff up for whenever I eventually see it.  :)

By the way:
>      > and for autotools:
 >     >
 >     > coding
>
>    Don't know about this one.
>
> `coding' is a "fake" variable you can specify in the -*- line to
> specify the file's coding system.  If specifying that "variable"
> causes questions, please send a precise test case and we
> will debug it.

I extracted those names from text found between 'Local Variables:' and
'End:' lines, so autotools is using it down there and not in the -*- line.
Leastwise, they are _trying_ to use it there.

Cheers - Bruce

Re: local variable for updating the time stamp on save

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

> `coding' is a "fake" variable you can specify in the -*- line to
> specify the file's coding system.  If specifying that "variable"
> causes questions, please send a precise test case and we will debug
> it.

The `unibyte' pseudo-variable does cause a question.

-*- unibyte: t -*-

-- 
Johan Bockgård

Re: local variable for updating the time stamp on save

[Richard Stallman]

    > `coding' is a "fake" variable you can specify in the -*- line to
    > specify the file's coding system.  If specifying that "variable"
    > causes questions, please send a precise test case and we
    > will debug it.

    I extracted those names from text found between 'Local Variables:' and
    'End:' lines, so autotools is using it down there and not in the -*- line.
    Leastwise, they are _trying_ to use it there.

I expect it works in both places.
Anyway, if it causes Emacs to ask for confirmation, please report.