Re: Redisplay: NS port, high CPU load

[Anders Lindgren]

Hi!

The encoding utf-8-hfs is defined in lisp, in international/ucs-normalize.el. However, by glancing at the code, I can't see anything obvious that would trigger a redisplay (the code is relatively complex, though).

One thing that is unique about the utf-8-hfs encoding is that is sets the `decomposed-characters' coding system property. (See my and Eli:s commits around 2015-12-23). This ensures that editing and completion of composed characters like "åäö" work properly. However, looking at the code in src/dired.c doesn't reveal anything obvious either. If you remove the code that sets this property (in ucs-normalize.el) you can check if this causes the redisplays.

    -- Anders

On Thu, Jun 9, 2016 at 10:22 AM, David Reitter <address@hidden> wrote:

On Jun 9, 2016, at 11:03 AM, David Reitter <address@hidden> wrote:

> I can manually cause a call to update_frame_tool_bar by evaluating this _expression_.  I don’t have time to look further right now, but the call to Ffind_file_name_handler is a suspect.  See also below.

So far, I have traced it to the use of ENCODE_FILE  (encode_file_name) in verify-visited-file-modtime:

 filename = ENCODE_FILE (BVAR (b, filename));

Now, file-name-coding-system is utf-8-hfs, and that setting is associated with the error.  Setting it to ‘utf-8 makes the bug go away.

What can trigger a redisplay or menu/toolbar update in encode_file_name() for utf-8-hfs?