> I don't know if a table of contents would help at all. The problem
> is not the number of different pages but the number of different
> items.
??? I don't understand. Please try again.
There are so many different change items in NEWS that people
are likely to get tired of read
> What about a table of contents and enumerating the sections,
> subsections, and subsubsections?
>
> I don't know if a table of contents would help at all. The problem
> is not the number of different pages but the number of different
> items.
??? I don't understand. Please try again.
What about a table of contents and enumerating the sections,
subsections, and subsubsections?
I don't know if a table of contents would help at all.
The problem is not the number of different pages
but the number of different items. Likewise I don't see that
giving numbers to the items wo
> > What about a table of contents and enumerating the sections,
> > subsections, and subsubsections?
>
> In Emacs, NEWS is visited in outline-mode, so after typing `C-c C-t'
> or `C-c C-q' the whole file looks like a table of contents.
I know that, but
. RMS and others don't like to activate
>> NEWS is hard to absorb because it is so big.
>
> What about a table of contents and enumerating the sections,
> subsections, and subsubsections?
In Emacs, NEWS is visited in outline-mode, so after typing `C-c C-t' or
`C-c C-q' the whole file looks like a table of contents.
--
Juri Linkov
http
> NEWS is hard to absorb because it is so big.
What about a table of contents and enumerating the sections,
subsections, and subsubsections?
Werner
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-deve
Perhaps this change should be documented in the `Incompatible
Lisp Changes in Emacs 22.1' in etc/NEWS. When users have hooks
that modify the contents of the *Occur* buffer then these hooks
will fail after the read-only flag was set on the *Occur* buffer.
We should not clutter NEWS
> Perhaps this change should be documented in the `Incompatible
> Lisp Changes in Emacs 22.1' in etc/NEWS. When users have hooks
> that modify the contents of the *Occur* buffer then these hooks
> will fail after the read-only flag was set on the *Occur* buffer.
On one hand, `occur-hook' didn't e
> I've moved the code that sets `buffer-read-only' and the
> buffer-modified flag to just before running `occur-hook'. This won't
> fix the problem Jason and I are reporting, but at least reduces the
> probability of someone losing data.
>
> Any fix of the problem, or better reorganization of `occu
> You mean the fit-window-to-buffer call, right? That seems like a bug
> in fit-window-to-buffer, not a bug in the way hooks are run.
Yes. Still, I tried to duplicate the problem by running it manually,
not from a hook, and couldn't. That doesn't mean it is a problem with
hooks, of course, but pe
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 6/23/05, Lute Kamstra <[EMAIL PROTECTED]> wrote:
>
>> Maybe it's better to first get a good understanding of the problems
>> you're experiencing.
>
> Well, we have at least one case of a fully reproducible bug where
> running a function from a ho
I've moved the code that sets `buffer-read-only' and the
buffer-modified flag to just before running `occur-hook'. This won't
fix the problem Jason and I are reporting, but at least reduces the
probability of someone losing data.
Any fix of the problem, or better reorganization of `occur-1' , are
Why setting the not-modified flag comes after running a hook? AFAIK,
there is a convention that run-hook should be the last element in the
function body, so users could override every default settings of the
function, including in this particular case setting the modification flag.
Jason Rumney <[EMAIL PROTECTED]> writes:
> Juanma Barranquero wrote:
>
>>The issue is that `fit-window-to-buffer', when called from
>>`occur-hook', changes the current buffer.
>>
> Yes, this seems like a real bug. I have noticed some other strange
> behaviour lately with things taking place in the
> Yes, this seems like a real bug.
And very weird. I traced the call, and the buffer changed on return of
`save-selected-window'. Nothing that I could see seemed like a likely
cause.
> If we continue to insist that it is
> the hooks that are wrong, not Emacs, then this will cause a lot of
> disru
On 6/23/05, Lute Kamstra <[EMAIL PROTECTED]> wrote:
> Maybe it's better to first
> get a good understanding of the problems you're experiencing.
Well, we have at least one case of a fully reproducible bug where
running a function from a hook leads to an unexpected switch of the
current buffer. Th
Juanma Barranquero wrote:
The issue is that `fit-window-to-buffer', when called from
`occur-hook', changes the current buffer.
Yes, this seems like a real bug. I have noticed some other strange
behaviour lately with things taking place in the wrong buffer.
I use BBDB along with Gnus, and whe
On 6/23/05, Emilio Lopes <[EMAIL PROTECTED]> wrote:
> Don't know if it helps you, but I have the following in my "~/.emacs" and it
> seems to work:
>
> (defun occur-shrink-window ()
> "*Shrink the \"*Occur*\" window as much as possible to display its
> contents."
> (let ((win (get-buffer-win
Juanma Barranquero gmail.com> writes:
> What about the problem with using `fit-window-to-buffer' in occur-hook?
Don't know if it helps you, but I have the following in my "~/.emacs" and it
seems to work:
(defun occur-shrink-window ()
"*Shrink the \"*Occur*\" window as much as possible to disp
> Probably true...
What about the problem with using `fit-window-to-buffer' in occur-hook?
I'd be much grateful for a comment from experts in the inner workings
of `fit-window-to-buffer'...
--
/L/e/k/t/u
___
Emacs-devel mailing l
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> Hey, it's funny: if I had proposed to move the code setting the
> read-only and not-modified flags to before run-hooks, instead of
> protecting the hook functions from changing the current buffer,
> perhaps no one would have complained... :)
Probabl
> Why setting the not-modified flag comes after running a hook? AFAIK,
> there is a convention that run-hook should be the last element in the
> function body, so users could override every default settings of the
> function, including in this particular case setting the modification flag.
The Em
> I'm not putting the "blame" on the change (which is, AFAICS,
> correct), only stressing that when a function runs a hook and
> *afterwards* sets the not-modified flag, protecting against the
> change of the buffer is not a defense against "random crap".
Why setting the not-modified flag comes af
> Emacs can't, and shouldn't try to, protect against random crap in hooks,
Excuse me if I find this quite funny.
emacs -Q
C-x b test RET
RET
RET
RET
RET
C-x 2
C-x o
M-x ielm RET
;; define hook in ielm
(add-hook 'occur-hook
'(lambda ()
> Emacs can't, and shouldn't try to, protect against random crap in hooks,
> except where a particular mistake is very common and easy to make.
I couldn't agree less with you. It is the consequences of the "random
crap" which should dictate whether it makes sense to protect against
it. Easy to mak
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> What part of "my function changed the buffer by accident, not by
> design" and "I could have lost data" is not clear?
Emacs can't, and shouldn't try to, protect against random crap in hooks,
except where a particular mistake is very common and easy
> The hook-invoker shouldn't have to protect against every possible
> bizarre action that a hook _might_ perform
No. Sure I didn't say that. Did I?
What I'm saying is: *some* hooks should protect against *some*
possible actions/errors; which ones it's something to ponder. *In this
case*, occur-ho
Juanma Barranquero <[EMAIL PROTECTED]> writes:
>> Once your code is fixed this is not needed any more. If the occur-hook is
>> expected to set-buffer in most/many cases, it might make sense, but
>> otherwise it doesn't.
>
> Well, I think it makes sense even if occur-hook is not expected to
> chang
Now, I can easily change my function to do the right thing, but I
still feel that `occur-1' should be fixed by using
`save-current-buffer' around the call to "(run-hooks 'occur-hook). The
rationale being that setting the modified flag to nil on the wrong
buffer can lead to data
>> Sounds like a serious bug. Such bugs can lead to loss of data.
> Does that mean that you agree that occur mode should run occur-hook via
No, it means I agree that your code is buggy and should thus be fixed.
> (save-current-buffer
> (run-hooks 'occur-hook))
Once your code is fixed this
And BTW, occur-mode is a major mode. Shouldn't it use run-mode-hooks?
It already does, to run occur-mode-hook.
occur-hook is different.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> It already does, to run occur-mode-hook.
> occur-hook is different.
Ah, you're right. Silly me.
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> No, it means I agree that your code is buggy and should thus be fixed.
Why was my function buggy? Where is it documented that occur-hook
functions should not change the current buffer? Is that a generic
requirement for hook functions?
In this particular case, if `occur-1' didn't set the read-on
> Sounds like a serious bug. Such bugs can lead to loss of data.
Does that mean that you agree that occur mode should run occur-hook via
(save-current-buffer
(run-hooks 'occur-hook))
?
And BTW, occur-mode is a major mode. Shouldn't it use run-mode-hooks?
--
/L/e/k/t
> In my `occur-hook' I have a custom function which does not save the
> current buffer,
Sounds like a serious bug. Such bugs can lead to loss of data.
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listi
35 matches
Mail list logo
