Please why ORDER of .emacs lines here matters.....

Please why ORDER of .emacs lines here matters.....

[Christian Seberino]

Notice the py-indent-offset line (2nd one) below.  If I move this
line further down then I don't
get 8 space idents anymore.  The order matters!!!! But why???



  (defun cs-python-mode()
      (setq-default  py-indent-offset        8            )
      (python-mode)
      (turn-on-font-lock)
      (setq-default  auto-fill-function      'do-auto-fill)
      (setq-default  py-python-command       "python2.2"  )
      (setq-default  py-continuation-offset  8            )
      (setq-default  py-smart-indentation    nil          )
      (setq-default  py-block-comment-prefix "#"          ))


P.S. This code gets run when I open a file with ".py" extension.  This
puts me into python-mode (along with my tweaks) for Python source code.

Re: Please why ORDER of .emacs lines here matters.....

[Kevin Rodgers]

Christian Seberino wrote:

> Notice the py-indent-offset line (2nd one) below.  If I move this
> line further down then I don't
> get 8 space idents anymore.  The order matters!!!! But why???

py-indent-offset is probably a buffer local variable whose value is set
in the python-mode function to the global default.  setq-default only
affects the global value, so if you set that after calling python-mode
the buffer local binding is already set to the original value.  (If that
is true, then your claim the it doesn't work isn't quite true: the first
Python mode buffer will have the old global default, but subsequent
Python mode buffers should have the new global default.)


>   (defun cs-python-mode()
>       (setq-default  py-indent-offset        8            )
>       (python-mode)
>       (turn-on-font-lock)
>       (setq-default  auto-fill-function      'do-auto-fill)
>       (setq-default  py-python-command       "python2.2"  )
>       (setq-default  py-continuation-offset  8            )
>       (setq-default  py-smart-indentation    nil          )
>       (setq-default  py-block-comment-prefix "#"          ))

Either move those setq-defaults to the top level (outside your function),

or just use python mode:

(add-hook 'python-mode-hook 'cs-python-mode-hook)

(defun cs-python-mode-hook ()
   (turn-on-font-lock)
   (setq auto-fill-function 'do-auto-fill
	py-python-command "python2.2"
	py-indent-offset 8
	py-continuation-offset 8
	py-smart-indentation nil
	py-block-comment-prefix "#"))

-- 
Kevin Rodgers

Re: Please why ORDER of .emacs lines here matters.....

[Christian Seberino]

Kevin

Thanks so much.  I'm impressed because I tried your theory that 
py-indent-offset would work like I wanted in second buffer even though
it did not work in first.  This was indeed true!!!

Why is it better/different to invoke my customizations in a "hook"
then just
calling my function in place of the mode???  My way worked for c,
java,
fortran77 and fortran90.  It would have worked in python too except
for
this one variable....

Should I redo all other langs to have "hook functions"??
Like cs-java-mode-hook, cs-fortran90-mode-hook, etc.???

If it is better in general for some reason then I'll do it.

I am *very* grateful for this insight.  This was really bugging me!

Chris




Kevin Rodgers <ihs_4664@yahoo.com> wrote in message news:<3F298FDA.10906@yahoo.com>...
> Christian Seberino wrote:
> 
> > Notice the py-indent-offset line (2nd one) below.  If I move this
> > line further down then I don't
> > get 8 space idents anymore.  The order matters!!!! But why???
> 
> py-indent-offset is probably a buffer local variable whose value is set
> in the python-mode function to the global default.  setq-default only
> affects the global value, so if you set that after calling python-mode
> the buffer local binding is already set to the original value.  (If that
> is true, then your claim the it doesn't work isn't quite true: the first
> Python mode buffer will have the old global default, but subsequent
> Python mode buffers should have the new global default.)
> 
> 
> >   (defun cs-python-mode()
> >       (setq-default  py-indent-offset        8            )
> >       (python-mode)
> >       (turn-on-font-lock)
> >       (setq-default  auto-fill-function      'do-auto-fill)
> >       (setq-default  py-python-command       "python2.2"  )
> >       (setq-default  py-continuation-offset  8            )
> >       (setq-default  py-smart-indentation    nil          )
> >       (setq-default  py-block-comment-prefix "#"          ))
> 
> Either move those setq-defaults to the top level (outside your function),
> 
> or just use python mode:
> 
> (add-hook 'python-mode-hook 'cs-python-mode-hook)
> 
> (defun cs-python-mode-hook ()
>    (turn-on-font-lock)
>    (setq auto-fill-function 'do-auto-fill
> 	py-python-command "python2.2"
> 	py-indent-offset 8
> 	py-continuation-offset 8
> 	py-smart-indentation nil
> 	py-block-comment-prefix "#"))

Re: Please why ORDER of .emacs lines here matters.....

[Kevin Rodgers]

Christian Seberino wrote:

> Why is it better/different to invoke my customizations in a "hook"
> then just
> calling my function in place of the mode???  My way worked for c,
> java,
> fortran77 and fortran90.  It would have worked in python too except
> for
> this one variable....
> 
> Should I redo all other langs to have "hook functions"??
> Like cs-java-mode-hook, cs-fortran90-mode-hook, etc.???
> 
> If it is better in general for some reason then I'll do it.

I think it is better to use hooks, because that is what they are there for.


-- 
Kevin Rodgers

Re: Please why ORDER of .emacs lines here matters.....

[Alan Mackenzie]

Christian Seberino <seberino@spawar.navy.mil> wrote on 31 Jul 2003
22:36:22 -0700:

> Why is it better/different to invoke my customizations in a "hook" then
> just calling my function in place of the mode???  My way worked for c,
> java, fortran77 and fortran90.  It would have worked in python too
> except for this one variable....

I don't think it's a good idea to put (setq-default)s into a mode
function either.  It's confusing: you're setting the "default" each time
you call the mode.  Sometimes you ending up evaluating the (setq-default)
after the buffer-local value has already been set, causing even more
confusion.

You're better using normal (setq)s in a hook function, thus overriding
the default in each buffer.  If you _really_ want to use (setq-default),
call it exactly once for each variable by putting in your .emacs.  To be
safe, you probably want to embed this in an (eval-after-load) something
like this:

(eval-after-load "python-mode"
  '(progn (setq-default  auto-fill-function      'do-auto-fill)
      (setq-default  py-python-command       "python2.2"  )
....
      ))

This way, it won't fail through python-mode not being loaded at
initialisation time.

> Should I redo all other langs to have "hook functions"??  Like
> cs-java-mode-hook, cs-fortran90-mode-hook, etc.???

I would say yes.  Not urgently, but over the course of the next few
time-units.

> If it is better in general for some reason then I'll do it.

It'll be less likely to cause obscure errors the next time you amend one
of these hooks, because you'll then be doing it the same tried and
trusted way as everybody else.

> Chris

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: Please why ORDER of .emacs lines here matters.....

[Thien-Thi Nguyen]

seberino@spawar.navy.mil (Christian Seberino) writes:

> If it is better in general for some reason then I'll do it.

a hook is a nook where the normal flow looks.
a surrounding-style rewrite is a whole 'nother book.
when the Programmer friendlily documents this tether
it's better to avoid xor and instead ior together.
otherwise, setq-default is the violent last resort;
probably indicates someone should file a bug report.

thi

Re: Please why ORDER of .emacs lines here matters.....

[Alan Mackenzie]

Thien-Thi Nguyen <ttn@glug.org> wrote on 05 Aug 2003 04:42:45 -0400:
> seberino@spawar.navy.mil (Christian Seberino) writes:

>> If it is better in general for some reason then I'll do it.

> a hook is a nook where the normal flow looks.
> a surrounding-style rewrite is a whole 'nother book.
> when the Programmer friendlily documents this tether
> it's better to avoid xor and instead ior together.
> otherwise, setq-default is the violent last resort;
> probably indicates someone should file a bug report.

Yee!

> thi

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: Please why ORDER of .emacs lines here matters.....

[Kai Großjohann]

seberino@spawar.navy.mil (Christian Seberino) writes:

>   (defun cs-python-mode()
>       (setq-default  py-indent-offset        8            )

Normally, hooks are run in each buffer that is in that mode, so IMVHO
it doesn't (normally) make sense to use setq-default in hooks.  Use
setq instead.  That sets the buffer-local value, if the variable is
buffer-local.
-- 
~/.signature

Re: Please why ORDER of .emacs lines here matters.....

[Stefan Monnier]

>   (defun cs-python-mode()
>       (setq-default  py-indent-offset        8            )
>       (python-mode)
>       (turn-on-font-lock)
>       (setq-default  auto-fill-function      'do-auto-fill)
>       (setq-default  py-python-command       "python2.2"  )
>       (setq-default  py-continuation-offset  8            )
>       (setq-default  py-smart-indentation    nil          )
>       (setq-default  py-block-comment-prefix "#"          ))

It's completely wrong to use setq-default here, so I'd be curious
to know from where you got the idea ?
Instead, you want to use

   ...
   (set (make-local-variable 'py-continuation-offset) 8)
   ...

since you only want to set those variables in the particular buffer
that uses cs-python-mode rather than in all buffers.


        Stefan


PS: Maybe it's time for setq-local.