From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 188bd80: gnus-shorten-url: Improve and avoid args-out-of-range error Date: Tue, 14 Apr 2020 15:42:55 +0300 Message-ID: <838siyi6gg.fsf@gnu.org> References: <20200413102415.23314.52412@vcs0.savannah.gnu.org> <20200413102417.445E520D0C@vcs0.savannah.gnu.org> <87k12ia05d.fsf@gmail.com> <83blnui8n8.fsf@gnu.org> <878siy9rwj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="5052"; mail-complaints-to="usenet@ciao.gmane.io" Cc: handa@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 14 14:43:46 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jOKuo-0001E0-4M for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Apr 2020 14:43:46 +0200 Original-Received: from localhost ([::1]:60034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOKun-00010p-7Z for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Apr 2020 08:43:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36127) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOKuJ-0000XH-Q2 for emacs-devel@gnu.org; Tue, 14 Apr 2020 08:43:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jOKuJ-000074-Lx; Tue, 14 Apr 2020 08:43:15 -0400 Original-Received: from [176.228.60.248] (port=4039 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jOKuJ-0006Gj-8q; Tue, 14 Apr 2020 08:43:15 -0400 In-Reply-To: <878siy9rwj.fsf@gmail.com> (message from =?utf-8?B?xaB0xJtw?= =?utf-8?B?w6FuIE7Em21lYw==?= on Tue, 14 Apr 2020 14:24:28 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246941 Archived-At: > From: Štěpán Němec > Cc: Kenichi Handa , monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Tue, 14 Apr 2020 14:24:28 +0200 > > On Tue, 14 Apr 2020 14:55:39 +0300 > Eli Zaretskii wrote: > > >> E.g. with the default Chinese font emacs -Q uses on my system, I get > >> roughly 8.5 "columns" per 5 Chinese characters, not 10 as claimed by > >> `string-width'. > > > > AFAIK, string-width is exact only on TTY frames. > > Interesting, thanks. Given that I remember the issue (for graphical > frames) being discussed multiple times in the past, asking whether > making it work by default on those as well would be too hard, is > probably pointless? I don't remember past discussions, but I guess the main difficulty with making char-width mode accurate on GUI frames is that doing so requires access to the font information, something that can be slow. maybe we should have two separate APIs, the other one more accurate but also potentially slower. > > See the definition of the Chinese-GBK language, it calls > > use-cjk-char-width-table that sets up the char-width-table entries > > specially, not sure why. Maybe Handa-san can comment on this. > > Now I see that "…" causes other stange behaviour with Chinese-GBK on TTY > frames, too, probably as an artifact of its having "width" 2: it causes > cursor to skip the following character when moving over it. I think the GBK setting assumes some specific fonts to be used. Does anything change if you start Emacs in a GBK locale to begin with? > > No. The ellipsis should be _before_ the tail, in the reading order, > > and that is what you get here. If you want to dwell on this issue a > > bit longer, look what the truncated string looks like in a buffer > > whose bidi-paragraph-direction is set to right-to-left. > > Thanks. I was mainly concerned about the function name: if that's the > case, it had better be called something like "truncate-string-beginning" > instead of "-left"? Yes, "-beginning" would be more accurate, I think.