From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: Redisplay: NS port, high CPU load Date: Thu, 9 Jun 2016 11:25:53 +0200 Message-ID: References: <9793F9E3-979A-4888-8662-F6E0C27C8B37@gmail.com> <20160608195552.GA66865@breton.holly.idiocy.org> <7B0CAF99-689D-4128-8E33-7D9BA8F1823E@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b46423b2c200534d50246 X-Trace: ger.gmane.org 1465464392 14741 80.91.229.3 (9 Jun 2016 09:26:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jun 2016 09:26:32 +0000 (UTC) Cc: Alan Third , Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 09 11:26:31 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bAwER-0007Bc-B8 for ged-emacs-devel@m.gmane.org; Thu, 09 Jun 2016 11:26:31 +0200 Original-Received: from localhost ([::1]:33354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAwEP-00032d-Rx for ged-emacs-devel@m.gmane.org; Thu, 09 Jun 2016 05:26:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAwDs-00032Q-QV for emacs-devel@gnu.org; Thu, 09 Jun 2016 05:25:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAwDq-0004J1-RD for emacs-devel@gnu.org; Thu, 09 Jun 2016 05:25:55 -0400 Original-Received: from mail-vk0-x230.google.com ([2607:f8b0:400c:c05::230]:35625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAwDq-0004Il-LT for emacs-devel@gnu.org; Thu, 09 Jun 2016 05:25:54 -0400 Original-Received: by mail-vk0-x230.google.com with SMTP id d127so46984435vkh.2 for ; Thu, 09 Jun 2016 02:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=58DphK4LcEZ/TQzn8U/owzHqCbCpTa2E7uOOVoPL+WU=; b=O+3sqUjTRE/e8XGspPNWnLRDscyBWJxQ2CDen6I8Bb4RbeMd5bYIiWF09yQ1TfCfSo Jy2MZY8QPC6w7G9c0H4+1TiYx3jjx9vZ0Mva8rCP5HBvHGH4VRhtzYd5qmoRGRRPubjl 1SxP2SYQLa9H9+8b2FMUdvamkbtT/fdlJCshRJXwhGBwf3YKgvIZ170+9kWK2F5dyLAL oSrWainzDUy5iuEAqdghcV13TTWf6qqqbAUd6eBD0MvaBMTlfYcrN1N11Prwf2wLHi+o 07XIk3WkjC1PgMkVHQmC9cgSLp1r2S64vEpYBwXiG7j1//WCgmxZRHUjky+0ImjINoA6 MreA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=58DphK4LcEZ/TQzn8U/owzHqCbCpTa2E7uOOVoPL+WU=; b=U8M5nLlgcXw+F0UGTRWzSID/WkIn8DVBylguBjs7LaFMgXXOitk+QPmPbF/h5aRoPP Wpu0DxeUkVRVXDQydklitXKBWVjmRIpKLQu1cGFQTgtiqRyOFnqeZaOOUeYixb0H0JY7 Ly39UIC06qTfiv3Bw4LaasvKEJ0Epb8H8zSbwr9cCtDFL4t605FTv28FLajIXVSjvNK/ Tdy60NAzNQWyWSLumXvFKshfyhZjf7MHFHVJs2EhyyvkiSzKCZa4uuDh1iSvPCe8bn1I 5x7qoJm8kskIO7tJlmS/hGlUFUElna+qsfgTJtMtICVgk3VjReFMeyGgl4DYvfeo3UXB ujVg== X-Gm-Message-State: ALyK8tIjPV4QdeHJZ9RQ8tfVBpg5G7zxwDArSY/5ly6VnIusUhtCtINBXnfGDsguBZ1s0SqCzcmcNwrb3KSh0g== X-Received: by 10.159.41.196 with SMTP id s62mr4378643uas.47.1465464353662; Thu, 09 Jun 2016 02:25:53 -0700 (PDT) Original-Received: by 10.31.216.195 with HTTP; Thu, 9 Jun 2016 02:25:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:204246 Archived-At: --001a114b46423b2c200534d50246 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 "=C3=A5=C3=A4=C3=B6" 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 wrote: > On Jun 9, 2016, at 11:03 AM, David Reitter > wrote: > > > I can manually cause a call to update_frame_tool_bar by evaluating this > expression. I don=E2=80=99t 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 =3D 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 =E2=80=98utf-8 makes the bug go away. > > What can trigger a redisplay or menu/toolbar update in encode_file_name() > for utf-8-hfs? > > > --001a114b46423b2c200534d50246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

The encoding utf-8-hfs is defined i= n 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-charac= ters' coding system property. (See my and Eli:s commits around 2015-12-= 23). This ensures that editing and completion of composed characters like &= quot;=C3=A5=C3=A4=C3=B6" work properly. However, looking at the code i= n 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 c= auses the redisplays.

=C2=A0 =C2=A0 -- Anders

On Thu, Ju= n 9, 2016 at 10:22 AM, David Reitter <david.reitter@gmail.com>= ; wrote:
On Jun 9= , 2016, at 11:03 AM, David Reitter <david.reitter@gmail.com> wrote:

> I can manually cause a call to update_frame_tool_bar by evaluating thi= s expression.=C2=A0 I don=E2=80=99t have time to look further right now, bu= t the call to Ffind_file_name_handler is a suspect.=C2=A0 See also below.
So far, I have traced it to the use of ENCODE_FILE=C2=A0 (encode_fil= e_name) in verify-visited-file-modtime:

=C2=A0filename =3D ENCODE_FILE (BVAR (b, filename));

Now, file-name-coding-system is utf-8-hfs, and that setting is associated w= ith the error.=C2=A0 Setting it to =E2=80=98utf-8 makes the bug go away.
What can trigger a redisplay or menu/toolbar update in encode_file_name() f= or utf-8-hfs?



--001a114b46423b2c200534d50246--