From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#49797: 28.0.50; Setting face to custom fontset doesn't work Date: Wed, 6 Oct 2021 11:11:42 -0700 Message-ID: <890ABB11-65A7-4F52-8816-7FA90BED7961@gmail.com> References: <87y29k2h4z.fsf@gnu.org> <3B853424-9F63-4A6B-B7A9-2E3AB71986AC@gmail.com> <835yub4fj5.fsf@gnu.org> <8FD18262-3F40-4033-A49D-F6CEA89A3A31@gmail.com> <83sfxf2ry5.fsf@gnu.org> <1AF30098-F55E-48A7-A0D4-E529DFBA6895@gmail.com> <838rz62kx8.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Kenichi Handa , 49797@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 06 20:16:51 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mYBTF-0007hX-SN for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 20:16:49 +0200 Original-Received: from localhost ([::1]:35104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYBTE-0005g9-PL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 14:16:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYBOc-0001fY-Da for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 14:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33893) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYBOc-0004de-5q for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 14:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYBOc-0001E9-0y for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 14:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Oct 2021 18:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49797 X-GNU-PR-Package: emacs Original-Received: via spool by 49797-submit@debbugs.gnu.org id=B49797.16335439134700 (code B ref 49797); Wed, 06 Oct 2021 18:12:01 +0000 Original-Received: (at 49797) by debbugs.gnu.org; 6 Oct 2021 18:11:53 +0000 Original-Received: from localhost ([127.0.0.1]:45439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYBOS-0001Dj-OJ for submit@debbugs.gnu.org; Wed, 06 Oct 2021 14:11:53 -0400 Original-Received: from mail-qt1-f170.google.com ([209.85.160.170]:38747) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYBOQ-0001DU-2i for 49797@debbugs.gnu.org; Wed, 06 Oct 2021 14:11:50 -0400 Original-Received: by mail-qt1-f170.google.com with SMTP id d8so3567687qtd.5 for <49797@debbugs.gnu.org>; Wed, 06 Oct 2021 11:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GyeqvY3kaAI4qEbydNZyo7vmfYnBqx6TBGI4jGEfQdY=; b=PehurscdC4u2mK+/mBmkKEyP9gy1yW0B4OV4ndx3xYv5F4mgGrQEv444pfwAlg79nm 0uuYVgqLupPbc/DxsvOpXBvXBZcSVH6MvqJsJouAaz/wB9ey4CRMM2zHGDfiYRjdYmh7 iSApQUz8JC0//jQLhW0lkD1C1MWJ7+W/2moFLCitXd2WoBv1WovorKfn8tKfDj6oeMwQ wUnUhFsoLferT3Mg/zHouwABeYnNaFkvBgPIty7lSGJqIayrXSAi7iEJk4ioO9CarRwg hKKKAMMYRy3l22xPmgIbj45AvsGihUctjd8WKg9NK62UtNCroC8TkWUoJI3yuEPZZ9oi kNDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GyeqvY3kaAI4qEbydNZyo7vmfYnBqx6TBGI4jGEfQdY=; b=1Pu0//9je35sxt9TQC29vMnjVi4j/IigJmYVtvSw32eXkflKCgOUl1LZ0Iu0eIPG+D SOvgI8aXzK4i19YLNUsInhipWsrHYanzsnbf9YK6FJuwV+Q2G2wYEsmh5F4iRh1BbNux iJnClWVxT4Grh+hB52WB6SccXFl7VCWvNiSxVnB0ko1IVUCNf6cg3cvT6PqSYnPgE/uU 2AKM6Rt5C6eN90a/Ce66Di2OLPl+cdJTtNu4NYV9HEwRt9olzNHJfoM5XVJYa2tYdWgn iX+YTM6JzOOG1MxKjqWJUCo8O9Pm96fjDetSUf8PesiWfiRms9/gbwsyDFD1Qdt5LIT1 kNfg== X-Gm-Message-State: AOAM5331U3jhpUPPhJ0GiXQJrVMl+esdaBOZGxM06rl7pn3G13Q91vEP Rlzm/6oucHEScesWwcjjraYrCza/lGc= X-Google-Smtp-Source: ABdhPJxU7dsDpvLln5zqCnjHqdsCcem4V80XS6AfH3QmeyTm3a6RUgYNZLDdVnUv90iMbEw7RB/wsQ== X-Received: by 2002:ac8:698f:: with SMTP id o15mr228503qtq.104.1633543904004; Wed, 06 Oct 2021 11:11:44 -0700 (PDT) Original-Received: from smtpclient.apple ([2600:1700:2ec7:8c9f:9d7b:4ef2:efed:f945]) by smtp.gmail.com with ESMTPSA id h27sm4684524qtu.11.2021.10.06.11.11.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 11:11:43 -0700 (PDT) In-Reply-To: <838rz62kx8.fsf@gnu.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:216579 Archived-At: Again, thanks for spending your time on this. >=20 >> Problem 1: The following doesn=E2=80=99t work as intended: >>=20 >> (set-face-attribute 'variable-pitch nil :font "fontset-serif=E2=80=9D) >>=20 >> where =E2=80=9Cfontset-serif=E2=80=9D contains two fonts: Charter for = Latin and Source Han Serif for CJK.=20 >>=20 >> The current effect is, Latin characters in =E2=80=98variable-pitch = works (displayed in Charter), CJK characters don=E2=80=99t (not = displayed in Source Han Serif). With my fix, CJK characters work = (displayed in Source Han Serif). >>=20 >> Problem 2: =E2=80=98default face cannot use fontset. Even if problem = 1 is fixed, setting the fontset for the default face still doesn=E2=80=99t= display CJK characters correctly. With the fix, setting a fontset for = =E2=80=98default works as intended. >>=20 >> The problems are not limited to CJK characters, any other non-ASCII = character that requires a font different from the Latin characters has = the same problem. >=20 > The thing is, what you describe as "problems" is how this stuff was > designed to work, at least AFAIU the code. Specifically, the face we > define and see in Lisp specifies the font only for the ASCII > characters. When Emacs needs to display a non-ASCII character with > some face (including the 'default' face), it calls face_for_char. > That function will use the same face if its font supports the > character, but if not, it will create a new "derivative" face. That > derivative face shares all the face attributes with the original one, > but has a different font. These derivative faces are never exposed to > Lisp, and don't have names, so a few people even know they exist, but > they are very visible on the C level: they have a distinct face ID. >=20 > You want to force Emacs to use the face's font for non-ASCII > characters, but that's not how this stuff was designed, AFAIU. If I'm > not missing something, it means what you perceive as bugs are at best > design bugs, not implementation bugs, and they cannot be fixed with a > few lines of tweaking. That might work in your relatively simple use > case, but I don't see how we can trust that not to break important > features, because working against the design always runs that risk. The comment in face_for_char literally says: ...so that users could still setup fontsets to force Emacs to use specific fonts for characters from other scripts, because choice of fonts is frequently affected by cultural preferences and font features, not by font coverage=E2=80=A6 Later in that function, we take the fontset of that face fontset =3D FONTSET_FROM_ID (face->fontset); Then find an appropriate font from it rfont_def =3D fontset_font (fontset, c, face, id); So Emacs definitely is designed to support using fontsets to assign = different fonts for different characters to faces. In fact, you can try = this right now (without my patch): (set-face-attribute 'variable-pitch :fontset "fontset-serif=E2=80=9D= ) (Notice I used the :fontset attribute, not :font attribute.) And the = variable-pitch face will work as intended, use CJK font for CJK = characters and Latin font for Latin characters, specified in = =E2=80=9Cfontset-serif=E2=80=9D. The only problem is 1) :fontset = attribute is not documented and 2) this doesn=E2=80=99t work with = =E2=80=98default face. >=20 > For example, this part of your patch: >=20 >> @@ -4040,7 +4055,17 @@ DEFUN ("internal-get-lisp-face-attribute", = Finternal_get_lisp_face_attribute, >> else if (EQ (keyword, QCextend)) >> value =3D LFACE_EXTEND (lface); >> else if (EQ (keyword, QCfont)) >> - value =3D LFACE_FONT (lface); >> + { >> + /* We prefer to return fontset, if it is specified, because = font >> + are derived from fontset when the user sets the >> + fontset. I.e., if the fontset is specified, that's probably >> + the one that the user set, and it is intuitive to get back >> + what you put in. */ >> + if (!UNSPECIFIEDP (LFACE_FONTSET (lface))) >> + value =3D LFACE_FONTSET (lface); >> + else >> + value =3D LFACE_FONT (lface); >> + } >=20 > This is completely ad-hoc, and could be wrong in some cases: the > caller wanted the font, but you provide it with a fontset, which is a > completely different Lisp object. And there are other similarly > ad-hoc changes of the semantics of the face attributes. It is ad-hoc, but that=E2=80=99s just to fit my interpretation of the = manual that we don=E2=80=99t want to expose :fontset attribute and want = to use :font for both :fontset and :font. If that interpretation is = wrong, we can of course fix the problem in other non-ad-hoc way. >=20 > Maybe we can extend the design to support "face-specific" fontsets, > but I'm quite sure that will need changes in font.c and fontset.c as > well, because the current design is implicitly assumed there. Emacs already has an elaborate implementation to support fontsets, it is = just hindered by the manual and bugs in the Lisp interface. >=20 >> My fix is based on the assumption that we want to use :font attribute = for both font and fontsets, which is what the manual says, and is what = Handa-san said what RMS wanted. >=20 > That's one way of interpreting what the manual says, but it is not the > only one. If you look at what the code does, you will arrive at > another interpretation: Emacs allows you to specify a fontset as the > value for the :font attribute, but what it does in that case is take > from the fontset the font for ASCII characters, and then use it as if > you specified that font, not a fontset. IOW, the fontset in that case > is just used as a method of specifying the ASCII font. I agree, another way is to document the :fontset attribute, document = that passing a fontset to :font attribute only sets the ASCII font, and = fix the bug where setting :fontset attribute for =E2=80=98default face = doesn=E2=80=99t work. Yuan=