buffer-read-only is always t at text-mode-hook time

buffer-read-only is always t at text-mode-hook time

[Dan Jacobson]

Perhaps this would work:
(add-hook 'text-mode-hook (lambda ()
   (or buffer-read-only (and(turn-on-auto-fill)(flyspell-mode 1)))))
But buffer-read-only is always true when text-mode-hook is evaluated
apparently.

While a fix is being made, any workarounds?

You see I don't want to turn on flyspell-mode for files I have no hope
of editing.

flyspell.el might add an example of how not to turn on flyspell-mode
for files one has no hope of editing.

P.S. the Info, the first hooks example
     (add-hook 'text-mode-hook 'turn-on-auto-fill)
should also show how to not turn it on for files one has no hope of editing.
While there, tell folks how also to set a hook just in case they need
to override. Don't only mention just add-hook.

BTW, I also don't want to turn on flyspell-mode for files that are
real big.

Re: buffer-read-only is always t at text-mode-hook time

[Kevin Rodgers]

Dan Jacobson wrote:
 > Perhaps this would work:
 > (add-hook 'text-mode-hook (lambda ()
 >    (or buffer-read-only (and(turn-on-auto-fill)(flyspell-mode 1)))))
 > But buffer-read-only is always true when text-mode-hook is evaluated
 > apparently.

I can't replicate that on GNU Emacs 21.3.1 (i386-pc-solaris2.7, X toolkit).

I started emacs with the -q --no-site-file switches and evaluated this
in the *scratch* buffer:

(add-hook 'text-mode-hook
	  (lambda () (message "buffer-read-only is %s" buffer-read-only)))

Then I invoked text mode several different ways (via M-x, via
default-major-mode, and via auto-mode-alist on both new and existing
files), and each time the echo area said "buffer-read-only is nil".

 > While a fix is being made, any workarounds?
 >
 > You see I don't want to turn on flyspell-mode for files I have no hope
 > of editing.

Your code above ought to work, except that you depend on the result of
turn-on-auto-fill, whose return value is not documented.  Use progn
instead of `and'.

 > flyspell.el might add an example of how not to turn on flyspell-mode
 > for files one has no hope of editing.

But you figured it out easily enough, no?

 > P.S. the Info, the first hooks example
 >      (add-hook 'text-mode-hook 'turn-on-auto-fill)
 > should also show how to not turn it on for files one has no hope of editing.

Why?  auto-fill is only invoked if they make a change (insert a space
at the end of a line), and if that's what the user wants it should
work if they M-x toggle-read-only.

 > While there, tell folks how also to set a hook just in case they need
 > to override. Don't only mention just add-hook.

Bad idea.

 > BTW, I also don't want to turn on flyspell-mode for files that are
 > real big.

C-h f buffer-size

-- 
Kevin Rodgers

Re: buffer-read-only is always t at text-mode-hook time

[Dan Jacobson]

Ok it is not true that "buffer-read-only is always t at text-mode-hook time".

Of course my bogus bug report is not my fault,

 > tell folks how also to set a hook just in case they need to
 > override. Don't only mention just add-hook.

Rogers> Bad idea.

Well, with all the setq examples from the 80's gone, we'll just add and add, and
produce bogus bug reports.

rms> 	 (add-hook 'text-mode-hook 'turn-on-auto-fill)
rms>     should also show how to not turn it on for files one has no hope of editing.

rms> Why bother to check?  If you don't edit, it won't do anything.

Well, at least do so for flyspell.el where it counts.

OK, using (and (not buffer-read-only)(> 88888 (buffer-size))(flyspell-mode 1))
Over and out.

Re: buffer-read-only is always t at text-mode-hook time

[Kevin Rodgers]

Dan Jacobson wrote:
 > Ok it is not true that "buffer-read-only is always t at text-mode-hook time".
 >
 > Of course my bogus bug report is not my fault,

Why not?

 >  > tell folks how also to set a hook just in case they need to
 >  > override. Don't only mention just add-hook.
 >
 > Rogers> Bad idea.

Could you do me the small favor of spelling my name correctly?

 > Well, with all the setq examples from the 80's gone, we'll just add
 > and add, and produce bogus bug reports.

add-hook's doc string clearly states that the HOOK symbol is a
variable, from which you can infer that you can modify it with
set/setq like any other.  The reason users should not be encouraged to
do so is obvious: a hook is a list-valued variable that should be
modified incrementally to limit the scope of the change to what is
intended and not not affect other aspects of the system of which the
user may not be aware.

How does add-hook/remove-hook contribute to more bogus bug reports
than set/setq?

 > rms> 	 (add-hook 'text-mode-hook 'turn-on-auto-fill)
 > rms> should also show how to not turn it on for files one has no
   hope of editing.
 > rms> Why bother to check?  If you don't edit, it won't do anything.
 >
 > Well, at least do so for flyspell.el where it counts.

I don't agree.  If a user expects flyspell to work regardless of
whether the buffer is read-only or writeable (i.e. checking the
current word after each command), then disabling it automatically is
clearly wrong (and doesn't allow him/her to control Emacs' behavior).
Leaving it as is at least gives users like you the opportunity to turn
it off.

 > OK, using (and (not buffer-read-only)(> 88888 (buffer-size))(flyspell-mode 1))
 > Over and out.

Ah, the magic 86.8046875 KB buffer size.  :-)

-- 
Kevin Rodgers

Re: buffer-read-only is always t at text-mode-hook time

[Dan Jacobson]

rms> Could you elaborate?  If you turn on flyspell mode for a read-only
rms> buffer, what subsequently happens that you find inconvenient?

Some might want to know of spelling problems they can't fix---but
never mind that---larger problem:

$ cat .emacs
(setq default-major-mode 'text-mode);adding this line makes the below useless!
(add-hook
 'text-mode-hook
 (lambda ()
   (or buffer-read-only (turn-on-auto-fill))
   (and (not buffer-read-only)(> 88888 (buffer-size))(flyspell-mode 1))))
$ emacs -nw --no-site-file /usr/share/emacs/21.3/etc/DOC-21.3.1
And what do you know, despite my best efforts, there I am staring at
"(Text Fly Fill)" in the modeline.

Re: buffer-read-only is always t at text-mode-hook time

[Kevin Rodgers]

Dan Jacobson wrote:
 > Some might want to know of spelling problems they can't fix---but
 > never mind that---larger problem:
 >
 > $ cat .emacs
 > (setq default-major-mode 'text-mode);adding this line makes the below useless!
 > (add-hook
 >  'text-mode-hook
 >  (lambda ()
 >    (or buffer-read-only (turn-on-auto-fill))
 >    (and (not buffer-read-only)(> 88888 (buffer-size))(flyspell-mode 1))))
 > $ emacs -nw --no-site-file /usr/share/emacs/21.3/etc/DOC-21.3.1
 > And what do you know, despite my best efforts, there I am staring at
 > "(Text Fly Fill)" in the modeline.

That is a problem.  It arises because default-major-mode is called 1
of 2 ways: either by set-buffer-major-mode (before the file's contents
have been inserted) or by normal-mode (but only if called with a nil
FIND-FILE argument, which usually doesn't happen since after-find-file
specifies it as t).

I don't know how that could be fixed without moving the call to
set-buffer-major-mode into or after find-file-no-select-1 (which
inserts the file contents into the buffer).  If that's not feasible,
should the interaction between default-major-mode and the mode's hook
functions be documented?

-- 
Kevin Rodgers

Re: buffer-read-only is always t at text-mode-hook time

[Richard Stallman]

    I don't know how that could be fixed without moving the call to
    set-buffer-major-mode into or after find-file-no-select-1 (which
    inserts the file contents into the buffer).  If that's not feasible,
    should the interaction between default-major-mode and the mode's hook
    functions be documented?

Moving the call into after-find-file would fix this, but that kind of
change could easily introduce various other bugs.  I don't know of any
specific thing that could fail after this change, but there are many
things that need to be checked to verify they won't sometimes fail.
Does anyone want to study and check them?

mention other ways than add-hook also

[Dan Jacobson]

In the manual, after all the setq hook examples were changed to
add-hook examples, users end up with miles long hooks as they adjust
their hooks without starting a new emacs.  So put back a few setq hook
examples, or mention how to do eval-last-sexp in .emacs without ending
up with miles long hooks, failed stuff all appended for the ride.

K> add-hook's doc string clearly states that the HOOK symbol is a
K> variable, from which you can infer that you can modify it with
K> set/setq like any other.

"Infer" perhaps, but lower powered users like to follow examples.
Users might even think they must restart emacs every time they change
a hook.

K> The reason users should not be encouraged to do so is obvious: a
K> hook is a list-valued variable that should be modified
K> incrementally to limit the scope of the change to what is intended
K> and not not affect other aspects of the system of which the user
K> may not be aware.

OK, but it's just like if one is not told how to change $PATH, only
how to prepend/append to $PATH.  Works, but no cigar.

Re: mention other ways than add-hook also

[Dan Jacobson]

rms>     In the manual, after all the setq hook examples were changed to
rms>     add-hook examples, users end up with miles long hooks as they adjust
rms>     their hooks without starting a new emacs.

rms> I don't quite understand.  Are you saying that people add various
rms> versions of the same hook without removing old versions?

I mean in the course of adjusting their .emacs, they might use a lot
of eval-last-sexp, eval-region, etc., upon which their hooks just grow
and grow, with results perhaps OK, but not necessarily the same as
what will be when they start a fresh emacs the next day.

So mention that problem, and mention that somebody else might be
tampering with their hooks beyond the bounds of their .emacs file[?!]
so that is why they should still use add-hook... or maybe if they only
adjust the hook in one spot in their .emacs, they can use setq hook.