From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charlie hemlock Newsgroups: gmane.emacs.bugs Subject: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv Date: Tue, 17 Apr 2018 20:30:33 -0400 Message-ID: References: <8336zv3v8x.fsf@gnu.org> <83efje36i5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e082d3e042a8ca3056a149068" X-Trace: blaine.gmane.org 1524011349 25524 195.159.176.226 (18 Apr 2018 00:29:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 18 Apr 2018 00:29:09 +0000 (UTC) Cc: 31169@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 18 02:29:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1f8ay7-0006UU-Bj for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Apr 2018 02:29:04 +0200 Original-Received: from localhost ([::1]:45053 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8b0D-0006iO-Rs for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Apr 2018 20:31:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8b05-0006hr-J4 for bug-gnu-emacs@gnu.org; Tue, 17 Apr 2018 20:31:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8b02-00081d-Bb for bug-gnu-emacs@gnu.org; Tue, 17 Apr 2018 20:31:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50359) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f8b02-00081C-7o for bug-gnu-emacs@gnu.org; Tue, 17 Apr 2018 20:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f8b01-00013e-SG for bug-gnu-emacs@gnu.org; Tue, 17 Apr 2018 20:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: charlie hemlock Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Apr 2018 00:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31169 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31169-submit@debbugs.gnu.org id=B31169.15240114424040 (code B ref 31169); Wed, 18 Apr 2018 00:31:01 +0000 Original-Received: (at 31169) by debbugs.gnu.org; 18 Apr 2018 00:30:42 +0000 Original-Received: from localhost ([127.0.0.1]:58256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f8azh-000136-QT for submit@debbugs.gnu.org; Tue, 17 Apr 2018 20:30:42 -0400 Original-Received: from mail-wr0-f182.google.com ([209.85.128.182]:45515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f8azf-00012s-Sz for 31169@debbugs.gnu.org; Tue, 17 Apr 2018 20:30:40 -0400 Original-Received: by mail-wr0-f182.google.com with SMTP id u11-v6so28207wri.12 for <31169@debbugs.gnu.org>; Tue, 17 Apr 2018 17:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K9rJEvQ5AnI6BKRUIMUFmI3BPpUWTEbD5Z/2hODvsNY=; b=ex8rSDIl1JMcEOxjQ2IqKOCcEZ33pceCM2oYO2CnWf81FP3pgOnHAHpL1yUm46qb/J HbgfIi4d/wWkFggWV9K7dvohRclvxYYEW82mgSA53M/kdLd9AgTK/0OHDk3LxZKxUCeM FHpaJtLYgp4N6zeOFlUluoUYK2g3wUlBbQE4LJkfbXqMRr5Y9nOAuZQW1Wj/Ynk/u+fr /TLza2HfoX4C/tQEwTzMRzzo5ZfVIWzq5saUzNHB9ycO4dmI4MvfsWJchW9pr9XJfHgN tMalD/X+sK9uOA5ZXnX99wKucfWTjqmZRoUG41R2J6QgiLmOtWJKj/leENKaiN5AQ5sx GWyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K9rJEvQ5AnI6BKRUIMUFmI3BPpUWTEbD5Z/2hODvsNY=; b=hBDt0/qxZPhCI0fXUGL6ZdNufz7JxeRL7E0pYaEFR37dsgwmkbtNSxxXmQse46r4mr v3qtJXjDKNbaoW+i1yCId2eviawxTHYIiwhedCAG3RzhePlnP/r+P81MUNWC7sjW55rH L08qUqGECk37VNYbgqghnKmuPsMTku81iqB/oKJES+MW+Ym6XiL8m0D/wyXArQGGh+pY /X76Yb9ZO7dE3dFCF4IRsw8e0cW7W2lNnlicqY1UBYgSzsbKxbxautvJgiXScy0WVafE /BVY7Ba7rqjoCUx9duvBbuZwbixW+PJW6OTGb0G+c2I1TIhtf37U4BTBKoxkw7v5FY32 A3Cw== X-Gm-Message-State: ALQs6tDGdHLQHBq5u2ZG/m3lc0lzzW7DFUbwYn1TTKEVT9B+FCq38Wm2 qG2rkkhkIbMXsAb6Zi9J8UYdSDbuMnzt2Tsltcs= X-Google-Smtp-Source: AIpwx481nJg+Qeyw170MqncQ7gyEGGDwK8uiW7s27mkQg3gZFvWHf/wF4ExFZrYc/liLuMH2xYTaLzIqgqXJqAo13C4= X-Received: by 10.28.106.5 with SMTP id f5mr196886wmc.84.1524011434149; Tue, 17 Apr 2018 17:30:34 -0700 (PDT) Original-Received: by 10.28.194.197 with HTTP; Tue, 17 Apr 2018 17:30:33 -0700 (PDT) In-Reply-To: <83efje36i5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:145541 Archived-At: --089e082d3e042a8ca3056a149068 Content-Type: text/plain; charset="UTF-8" > The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the window? Is that similar to what you see locally on the GNU/Linux box? That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap indicators show up. > If "C-x C-c" works, then does "M-x redraw-display RET" redraw the frame to its normal appearance? No. > What about "C-x 5 b RET" -- does it create a new frame, and does that frame look correctly? Creates new frame. Does not look correct - same as first. C-x 2 does split frame. But still missing minibuffer and can't type in either buffer. I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display: However, Clicking the Open File icon did open the file browser . Related to this menu issue: - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319 - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319 - Can't say if these are related to the original display issues discussed here or entire separate issue % ~/release/emacs_26.1/bin/emacs -Q (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed [[removed several repeats]] (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu) (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu) *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug (emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating gadget (node menuitem, owner GtkMenuItem) (emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget (node menuitem, owner GtkMenuItem) [[removed several repeats]] In my original post - I forgot to mention with xming 6.9.0.31 (not vcxsrv) I get different emacs behavior (the test combinations are growing) . The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else. % ~/release/emacs_26.1/bin/emacs -Q # click anywhere X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130 When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. Fatal error 6: Aborted But I did include that bug link in original post. I can't say if these are closely or distantly or not related. Anyone else experiencing or able to replicate? Thanks! On Mon, Apr 16, 2018 at 10:34 PM, Eli Zaretskii wrote: > > From: charlie hemlock > > Date: Mon, 16 Apr 2018 19:37:44 -0400 > > Cc: 31169@debbugs.gnu.org > > > > > Is this all you see in the Emacs frame? It looks like a part of a > > > frame , did you clip the image, perhaps? If so, please show all of > the frame. > > > > That was all the frame. Including new attachment [emacs26_gtk3.png] for > clarity. (show a little of background > > and putty window). I tried resizing window and same result. > > > > > To make sure this is related to GTK, could you try building with a > > > different toolkit, just to see if that build starts as expected? > > > > Attached with "motif" x-toolkit screenshot. [emacs26_motif.png]. > > Appears OK, but I can't ./configure --with-xwidgets > > The Motif frame looks better, but still not entirely normal: what's > that empty space to the right of the window? > > Is that similar to what you see locally on the GNU/Linux box? > > > > Does it eat CPU cycles? > > No - just looked a 'top' output. > > > > > Can you exit it with "C-x C-c" or do you have to kill it by a > > signal? > > C-x C-x works. > > If "C-x C-c" works, then does "M-x redraw-display RET" redraw the > frame to its normal appearance? > > What about "C-x 5 b RET" -- does it create a new frame, and does that > frame look correctly? > > Thanks. > --089e082d3e042a8ca3056a149068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The Motif frame looks better, but still not entirely normal: what'= s that empty space to the right of the=C2=A0 window? Is that similar=C2=A0 = to what you see locally on the GNU/Linux box?

That empty narro= w space looks similar as locally launched Emacs. That narrow area is where = line wrap indicators show up.


> If "C-x C-c" w= orks, then does=C2=A0 "M-x redraw-display RET" redraw the frame t= o its normal appearance?

No.
=
> What about "C-x 5 b=C2=A0 RET" -- does it create a new frame= , and does that frame look correctly?

Creates new frame. Does not look c= orrect - same as first.

C-x 2=C2=A0= =C2=A0 does split frame. But still missing minibuffer and can't type in= either buffer.

I also clicked the "File" button on menu bar, and g= ot several errors below, and the File Menu did not display:
However, Clicking the Open File icon did open the file browser .
<= div class=3D"gmail_extra">Related to this menu issue:
=C2=A0- https://bu= gs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
=C2=A0- https:/= /bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
=C2=A0- Can't say if these are related to the orig= inal display issues discussed here or entire separate issue

% = ~/release/emacs_26.1/bin/emacs -Q

(emacs:3612): Gtk-CRITICAL **: gtk= _widget_get_preferred_height_for_width: assertion 'width >=3D 0'= failed

[[removed several repeats]]
(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: = assertion 'width >=3D 0' failed
*** BUG ***
In pixman_regi= on32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixma= n_log_error' to debug

*** BUG ***
In pixman_region32_init_rec= t: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error&#= 39; to debug

(emacs:3612): Gtk-WARNING **: Negative content width -7= (allocation 1, extents 4x4) while allocating gadget (node arrow, owner Gtk= Menu)

(emacs:3612): Gtk-WARNING **: Negative content width -7 (alloc= ation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu)*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
= Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612= ): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) w= hile allocating gadget (node menuitem, owner GtkMenuItem)

(emacs:361= 2): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) = while allocating gadget (node menuitem, owner GtkMenuItem)

[[removed several repeats]]=


In my original post - I forgot= to mention with xming 6.9.0.31 (not vcxsrv) I get different emacs behavior= (the test combinations are growing) .
= The emacs gui launches and appears ok, but core dumps as soon as I attempt = anything else.
% ~/relea= se/emacs_26.1/bin/emacs -Q
# click anywhere
X protocol error: BadRequest (invalid request code or no such operation) o= n protocol request 130
When compiled with GTK, Emacs cannot recover from= X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=3D8571= 5
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

But I did include that bug link in original p= ost.=C2=A0=C2=A0 I can't say if these are closely or distantly or not r= elated.

Anyone else experiencing or able to replicate?
Thanks!

On Mon, Apr 16, 2018 at 10:34 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
>= ; From: charlie hemlock <cha= rliehemlock@gmail.com>
> Date: Mon, 16 Apr 2018 19:37:44 -0400
> Cc: 31169@debbugs.gnu.org=
>
> > Is this all you see in the Emacs frame?=C2=A0 It looks like a par= t of a
> > frame , did you clip the image, perhaps?=C2=A0 If so, please show= all of the frame.
>
> That was all the frame. Including new attachment [emacs26_gtk3.png] fo= r clarity. (show a little of background
> and putty window). I tried resizing window and same result.
>
> > To make sure this is related to GTK, could you try building with = a
> > different toolkit, just to see if that build starts as expected? =
>
> Attached with "motif" x-toolkit screenshot. [emacs26_motif.p= ng].
> Appears OK,=C2=A0 but I can't ./configure --with-xwidgets

The Motif frame looks better, but still not entirely normal: what= 9;s
that empty space to the right of the window?

Is that similar to what you see locally on the GNU/Linux box?

>=C2=A0 =C2=A0> Does it eat CPU cycles?=C2=A0
> No - just looked a 'top' output.
>
> > Can you exit it with "C-x C-c" or do you have to kill i= t by a
> signal?=C2=A0
> C-x C-x works.

If "C-x C-c" works, then does "M-x redraw-display RET= " redraw the
frame to its normal appearance?

What about "C-x 5 b RET" -- does it create a new frame, and does = that
frame look correctly?

Thanks.

--089e082d3e042a8ca3056a149068--