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: Question about composite.c Date: Tue, 21 Jan 2020 20:15:22 +0200 Message-ID: <83r1zsvfph.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="103451"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gerry Agbobada Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 21 19:17:08 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 1ity5L-000QlG-Rf for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jan 2020 19:17:07 +0100 Original-Received: from localhost ([::1]:59310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ity5K-0004RZ-SU for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jan 2020 13:17:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53036) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ity3e-0002zc-V1 for emacs-devel@gnu.org; Tue, 21 Jan 2020 13:15:24 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ity3e-0001Tq-QG; Tue, 21 Jan 2020 13:15:22 -0500 Original-Received: from [176.228.60.248] (port=3545 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ity3V-0007jO-0m; Tue, 21 Jan 2020 13:15:20 -0500 In-reply-to: (message from Gerry Agbobada on Mon, 20 Jan 2020 23:17:19 +0100) 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:244473 Archived-At: > From: Gerry Agbobada > Date: Mon, 20 Jan 2020 23:17:19 +0100 > > (defvar composition-ligature-table (make-char-table nil)) > (require 'composite) > > (let ((alist > '( > (?* . ".\\(?:\\(\\*\\*\\|[*>]\\)[*>]?\\)") > ))) > (dolist (char-regexp alist) > (set-char-table-range composition-ligature-table (car char-regexp) > `([,(cdr char-regexp) 0 font-shape-gstring])))) > > (set-char-table-parent composition-ligature-table composition-function-table) > > (setq-local composition-function-table composition-ligature-table) Can you tell what kind of ligatures you wanted to support that required such a non-trivial regexp? Also, why did you need to use a separate char-table instead of composition-function-table? > I think my error may come from having a composition-table where a replacement > triggered by =prettify-symbols= occurs before the regex for > =composition-ligature-table= happens, so there's only an empty string for > replacement and there's an error because it doesn't pass the test. It's not just an empty string, it's a _unibyte_ string. How did that happen? More importantly, please don't use prettify-symbols-mode, which are based on static compositions, together with automatic compositions. Static compositions are an obsolete feature, it lacks support for some modern Emacs features (e.g., bidirectional text), and we should remove it from Emacs at some future point -- but not before we implement a replacement for it using composition-function-table and related machinery. Mixing these two incompatible compositions is asking for trouble. If you turn off prettify-symbols-mode, does the problem go away? > diff --git a/src/composite.c b/src/composite.c > index 53e6930b5f..1151721d61 100644 > --- a/src/composite.c > +++ b/src/composite.c > @@ -1735,7 +1735,7 @@ Otherwise (for terminal display), FONT-OBJECT > must be a terminal ID, a > if (NILP (string)) > { > if (NILP (BVAR (current_buffer, enable_multibyte_characters))) > - error ("Attempt to shape unibyte text"); > + error ("Attempt to shape unibyte text \"%s\" in non multibyte > buffer", string); > validate_region (&from, &to); > frompos = XFIXNAT (from); > topos = XFIXNAT (to); > @@ -1745,8 +1745,8 @@ Otherwise (for terminal display), FONT-OBJECT > must be a terminal ID, a > { > CHECK_STRING (string); > validate_subarray (string, from, to, SCHARS (string), &frompos, &topos); > - if (! STRING_MULTIBYTE (string)) > - error ("Attempt to shape unibyte text"); > + if (strlen(string) != 0 && ! STRING_MULTIBYTE (string)) > + error ("Attempt to shape unibyte text \"%s\"", string); > frombyte = string_char_to_byte (string, frompos); This cannot be right. We cannot meaningfully compose unibyte text, because it is not made of characters, it is made of raw bytes, and therefore you cannot meaningfully reference composition-function-table by such raw bytes. The errors are correct, and must stay that way. You need to debug this further to understand how come you ended up in this condition, and then fix whatever root cause caused that. > * Question > I guess the only question is : what's supposed to happen when =string= is an > empty lisp string in this condition ? There's no problem with empty strings here, as long as they are multibyte.