Re: Redisplay: NS port, high CPU load

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

Hi!

Unfortunately, I can't reproduce this either, but I have a theory on what
is going on.

`with-temp-buffer' calls `generate-new-buffer'. This, in turn calls
`get-buffer-create', which run `buffer-list-update-hook'. In theory, if a
function on this hook would trigger a tool-bar redisplay,
`(with-temp-buffer (insert "XXX"))' will too.

If this is the cause of the problem David is seeing, one solution would be
to temporarily bind `buffer-list-update-hook' to nil in `with-temp-buffer'.
(This might be a good idea anyway, since we don't want `with-temp-buffer'
to be slowed down by slow hooks, unless is it more important to ensure that
the buffer list is up to date?)

When it comes to the HFS coding rewrite, I still think it is valid. The
documentation of `define-coding-system' indicated that it expects the
pre-write function to convert the current buffer and that the two
parameters are only there for backward compatibility. The function, before
the rewrite, was clearly written for an older version of
`define-coding-system'.

    -- Anders


On Fri, Jun 10, 2016 at 12:36 PM, David Reitter <david.reitter@gmail.com>
wrote:

> On Jun 10, 2016, at 8:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > To be sure this triggers redisplay of the tool bar, you need:
> >
> >  . emacs -Q
> >  . disable blink-cursor-mode
> >  . disable global-eldoc-mode
> >  . define an interactive function that does the above insertion, and
> >    then bind that function to a key (I used F8)
> >  . press F8 and see if update_frame_tool_bar is called
>
>
> Well, turns out this happens with -q, but not with -Q.
>
> If I clear tool-bar-map, the update goes away, but running populating it
> with a standard toolbar as per (tool-bar-setup), the updates come back.
> So, I’m not sure what exactly makes this happen - I’m obviously loading a
> whole lot of settings with -q.
>
> I’m assuming I’ll have to give you something more reproducible then, so
> please stand by.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2616 bytes --]