From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Issue with font rendering caused by one of the commits in last 48 hrs #master Date: Sat, 21 Jan 2017 17:43:59 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11447a5452fcdb05469e5069 X-Trace: blaine.gmane.org 1485020695 21334 195.159.176.226 (21 Jan 2017 17:44:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 21 Jan 2017 17:44:55 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 21 18:44:51 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cUziX-0004WY-Re for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2017 18:44:46 +0100 Original-Received: from localhost ([::1]:32795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUzic-0006DT-V4 for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2017 12:44:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUzi2-0006D4-PN for emacs-devel@gnu.org; Sat, 21 Jan 2017 12:44:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cUzhz-0000QD-0P for emacs-devel@gnu.org; Sat, 21 Jan 2017 12:44:14 -0500 Original-Received: from mail-vk0-x229.google.com ([2607:f8b0:400c:c05::229]:33696) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cUzhy-0000Po-Qw for emacs-devel@gnu.org; Sat, 21 Jan 2017 12:44:10 -0500 Original-Received: by mail-vk0-x229.google.com with SMTP id k127so68497495vke.0 for ; Sat, 21 Jan 2017 09:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Q6gjQ/BQsIsLTlOeamCZpD+GeiscqFCAKgnz6sncEZw=; b=bZlWdoM6yIvAoYqH53Fb5Sxfe9GGlynvZpAMYP+qZR5fVTPTiOceHKE6HzXV05pIho wnhaMrUvDD6nSMnoTvvM3l4EX2fMahzp+4ZbBme3Dk0AWnQ5RY/mV9XQ5WdDzVQ0wi9H /dPlxsCaAuYFEXI1wOLSQPrtp2hsPxXyQO8QrXHIcMffObumFF4Ecjw3rCLvfbLN1wkk 1T5td1o5MBcCGw6EoLCVOZKISjIslOxSqlWvnzJCZXoJNW+FyLAfbzJnaKHnhRUNr1IR kLoGhUP7mCJEhFhWZsqWOc5tsXPHi9M//J2bNLPEW/2uDv3YbSOkxKvoC3mv5RsOdGO8 vBuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Q6gjQ/BQsIsLTlOeamCZpD+GeiscqFCAKgnz6sncEZw=; b=dzNq5Rs2W3LljsMescRYZREQ9MRZ7WPduc7ILbGzNo1Ha9OjAQtDDIjKjTyDziBu6j E2EOI4oBR5/7v17w6XEIR85PFTY7AbbcTyUQTqSubxRq9n9Sa4G899Po7B4YQu0Dg6Kb 23QhBa9grl4GRq4oPYUoKSW0AbbeuHAGEcV2azWWp5L+eJMcH9TNaIkS3FwLYwm4vZiv NrZzYC+Wlf+A4sTwaSHpGp3lRpOJ71Thwrv/V+JPvbh3hFG9KAEd32y98c2fYlCZRz27 KY/dChgbPUJ8CG5gsNFNjJsLHDKNe3yQDSwqudPW2Yae1WxEg6W1rEhRIbPf7EOo/k2M x5VQ== X-Gm-Message-State: AIkVDXJyalh9d88ABCvqMCh2/S5pXmCHneaz3XJcGwkvOL9qUONhFxQAAi3ue0QGV8A/2n7UngcCT+V3oTVMEg== X-Received: by 10.31.62.71 with SMTP id l68mr10096987vka.175.1485020649943; Sat, 21 Jan 2017 09:44:09 -0800 (PST) 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::229 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:211470 Archived-At: --001a11447a5452fcdb05469e5069 Content-Type: text/plain; charset=UTF-8 Hello everyone, I apologize, but I cannot recreate the issue I saw last night. It's very strange given that the 'bad' build and 'good' build were installed with different --prefix flags. So they are 'make install'ed in completely separate directories. Though my building directory is the same. Here are the sequence of events: 1. I update my build to e5e42ce diff-hunk-kill independent of point inside headers 2. Start a fresh emacsclient session, and see that issue. 3. I keep that session open, checkout the branch that last worked fine for me: 8c0fcaf Avoid inefficient regex in diff-refine-hunk 4. I take a screenshot of the bad build and kill that session. 5. Start another fresh emacsclient session using the build of the 'good' branch. 6. And everything looks good again. Sorry guys, as the issue magically went away, I fear it will arrive again. Will open a bug report next time with more info as possible. ====== On Sat, Jan 21, 2017 at 9:02 AM Noam Postavsky < npostavs@users.sourceforge.net> wrote: I can't see a plausible way any these could affect the font, are you sure it wasn't the commit I pushed last night [1: 6a788d2]? 1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 Don't wait for frame to become visible Thanks for the reply, yes I confirmed that was not the case. This was my emacs build info: === Emacs version: GNU Emacs 26.0.50.20 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2017-01-20, built using commit e5e42cefd7f2eb47d2c8660a7a317e8b08d36a82. ./configure options: --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/master '--program-transform-name=s/^ctags$/ctags_emacs/' 'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include -I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64 -ggdb3' Features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 MODULES === >> Tino Calancha > I don't see this issue in my box. > Is it feasible for you to perform a git bisect? Sorry, that's what I was just trying to do, but cannot recreate the issue. :( >> Eli Zaretskii > The only thing I can glean from the images is that the "good" version uses a fixed-pitch > face, while the "bad" one uses a variable-pitch face. It's the exact same font and exact same emacs config. > E.g., is the same font used in both cases? Yes. > What do you see in the Custom buffer if you try to customize the face used by this display? Ah! Sorry, should have done that. But cannot recreate the issue. Sorry. > (I also wonder why you post here and not to the bug tracker.) Will do that next time. I did not see an "error message" or debug info to report other than the screenshot. -- Kaushal Modi --001a11447a5452fcdb05469e5069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Hello everyone,

I apologize,= but I cannot recreate the issue I saw last night. It's very strange gi= ven that the 'bad' build and 'good' build were installed wi= th different --prefix flags. So they are 'make install'ed in comple= tely separate directories.

Though my building directory is the sa= me.

Here are the sequence of events:

1. I update my bu= ild to=C2=A0
=C2=A0 =C2=A0 e5e42ce diff-hunk-kill independent of point inside headers
2. Start a fresh emacsclient session, and see that is= sue.
3. I keep that session open, checkout th= e branch that last worked fine for me:
=C2=A0= =C2=A0 8c0fcaf Avoid inefficient regex in diff-r= efine-hunk
4. I take a screenshot of the bad = build and kill that session.
5. Start another= fresh emacsclient session using the build of the 'good' branch.
6. And everything looks good again.

Sorry guys, as the issue magically went away, I fear it will arr= ive again. Will open a bug report next time with more info as possible.

=3D=3D=3D=3D=3D=3D
On Sat, Jan 21, 2017 at 9:02 AM Noam Postavsky <npostavs@users.sourceforge.net> wrote:
=
I can't see a plausible = way any these could affect the font, are you
sure it wasn't the commit I pushed last night [1: 6a788d2]?

1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
=C2=A0 Don't wait for frame to become visible

Thanks for the reply, yes I confirmed that was n= ot the case. This was my emacs build info:
=3D=3D=3D
Emacs version: GNU Emacs 26.0.50= .20 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
=C2=A0of 2017-01-20, built using commit e5e42cefd7f2eb47d2c8660a7a3= 17e8b08d36a82.

=
./configure options:
=C2=A0 --with-modules --prefix=3D/home/kmodi/usr_local/apps/6/emacs/master= '--program-transform-name=3Ds/^ctags$/ctags_emacs/' 'CPPFLAGS= =3D-fgnu89-inline -I/home/kmodi/usr_local/6/include -I/usr/include/freetype= 2 -I/usr/include' 'CFLAGS=3D-ggdb3 -O0' 'CXXFLAGS=3D-ggdb3 = -O0' 'LDFLAGS=3D-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_loc= al/6/lib64 -ggdb3'

Features:
= =C2=A0 XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTING= S NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCR= OLL_BARS GTK2 X11 MODULES
=3D=3D=3D

>> Tino Calancha
> I don't see this issue in my box.
> Is it feasible for you to perform a git bisect?

=
<= div class=3D"gmail_msg">Sorry, that's what I was just trying to do, but= cannot recreate the issue. :(

>> Eli Zaretskii
=

> The only thing I can=C2=A0glean from the images is that the &= quot;good" version uses a fixed-pitch
> face, while the "bad"= one uses a variable-pitch face.=C2=A0=C2=A0

It= 's the exact same font and exact same emacs config.=C2=A0
<= /div>

> E.g., is the=C2=A0same font used in both cases?=C2= =A0=C2=A0

<= /div>
Yes.

<= span style=3D"color:rgb(33,33,33);font-size:13px" class=3D"gmail_msg">> = What do you see in the Custom buffer if=C2=A0you try to customize the fa= ce used by this display?=C2=A0

Ah! Sorry, shou= ld have done that. But cannot recreate the issue. Sorry.
=

> (I also wonder why you post here and not to the bug tracker.)=C2=A0=C2=A0

=
Will do that = next time. I did not see an "error message" or debug info to repo= rt other than the screenshot.

--

Kaushal Modi

--001a11447a5452fcdb05469e5069--