emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 27.1 Windows Binaries -- testing wanted


From: Robert Pluim
Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted
Date: Mon, 24 Aug 2020 14:11:08 +0200

>>>>> On Mon, 24 Aug 2020 13:40:27 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
    >> Date: Mon, 24 Aug 2020 11:28:43 +0200
    >> 
    >> >>>>> On Fri, 21 Aug 2020 22:44:18 +0300, Eli Zaretskii <eliz@gnu.org> 
said:
    >> >> Obviously more features to go. I haven't worked out how to test the 
    >> >> existence of harfbuzz yet.
    >> 
    Eli> (car (frame-parameter nil 'font-backend))
    >> 
    >> There are vendor-provided versions of Emacs that mess with
    >> font-backend and/or FontBackend, and the user may have changed it
    >> themselves, so thatʼs not going to work.

    Eli> I'm not sure I understand the "mess" part.  Can you show an example of
    Eli> what such "messing" produces in the simple recipe I suggested above?

OpenSuse [1] puts 'FontBackend: xft,x' in the global Xresources file
used by their emacs-27 package, even though the build itself is a
Cairo + HarfBuzz build, so produces 'x' for the snippets above (since
thereʼs no xft backend in such an emacs).

    Eli> Also, I'm guessing those vendors don't touch the Windows builds, do
    Eli> they?

True. For Windows your code is much more likely to work, but is still
subject to the user changing font-backend.

    >> Perhaps we need a `harfbuzz-available-p` defun?

    Eli> We could add that if there's a reason good enough.  The advantage of
    Eli> what I proposed is that it also detects the cases where HarfBuzz is
    Eli> available, but for some reason not used.

Only from 'emacs -Q'

Robert

Footnotes:
[1]  I believe they've now fixed this




reply via email to

[Prev in Thread] Current Thread [Next in Thread]