From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame Date: Sat, 24 Oct 2015 17:33:35 +0200 Message-ID: References: <561E92D8.1050500@gmx.at> <561F7943.9090309@gmx.at> <562746AA.7090004@gmx.at> <5627B83F.9060303@gmx.at> <5629022A.9060408@gmx.at> <562A75CA.4050402@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ee5c095032b0522db7379 X-Trace: ger.gmane.org 1445700860 352 80.91.229.3 (24 Oct 2015 15:34:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 15:34:20 +0000 (UTC) Cc: Keith David Bershatsky , 21415@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 24 17:34:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zq0pf-0002OM-FX for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 17:34:11 +0200 Original-Received: from localhost ([::1]:44689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq0pe-0001HJ-Rt for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 11:34:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq0pa-0001HA-23 for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 11:34:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zq0pW-0002wu-Pp for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 11:34:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq0pW-0002wg-KV for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 11:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zq0pW-0004Ie-42 for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 11:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Oct 2015 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21415-submit@debbugs.gnu.org id=B21415.144570083916515 (code B ref 21415); Sat, 24 Oct 2015 15:34:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 24 Oct 2015 15:33:59 +0000 Original-Received: from localhost ([127.0.0.1]:37007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zq0pS-0004IG-Cc for submit@debbugs.gnu.org; Sat, 24 Oct 2015 11:33:59 -0400 Original-Received: from mail-vk0-f47.google.com ([209.85.213.47]:36735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zq0p6-0004HM-IB for 21415@debbugs.gnu.org; Sat, 24 Oct 2015 11:33:56 -0400 Original-Received: by vkex70 with SMTP id x70so77679359vke.3 for <21415@debbugs.gnu.org>; Sat, 24 Oct 2015 08:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2kp/skKJZf4316+sWhniSQ766qeRJl/qWtz31EkVGvY=; b=aZPR68wMWyZ+y+q+LKwXp5dgXTVcTRfPMkAl0jZAyhVgHMMuM25g+wRa2G/1RBGuQc P8MvYUZzZ6EF/nUZfOE7vsKCTztopAu0y/dCFqBEmAdhEl9xsebaaM3um1g10OB49uff FpazjmYBJKLvJa3IAbWc5DtySGui/mu3PCQCf1BTPjccvgKvrxoHnMGWDObNzUgXLhgH wPb1/CISfQp/0sGhfxWfFCSTHqHEDxkHJbnW+S31daECaRAAMU85g79x//hj5MvgGLvC //GsdMS6IJ9b1fgxdjZ5B8omyLcRbwjf8T8QI2blSJ2pdR9+g7dS+YlZiCDENHPxlrkF HeuQ== X-Received: by 10.31.41.8 with SMTP id p8mr17536636vkp.149.1445700815879; Sat, 24 Oct 2015 08:33:35 -0700 (PDT) Original-Received: by 10.31.210.133 with HTTP; Sat, 24 Oct 2015 08:33:35 -0700 (PDT) In-Reply-To: <562A75CA.4050402@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107989 Archived-At: --001a113ee5c095032b0522db7379 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I can repeat the problem with the tool-bar here. I'll take a look at it. I fact, it looks Jan was trying to avoid the fact that the frame could be constrained. However, one of the changes I made was to remove the constraining of frames -- so chances are that things would work if we would revert to the old code. Anyway, we should try to include as much as possible into test cases, to ensure that future changes won't break things again. I put the fringe problem on the "fix queue", but it may take some time before I get to them. -- Anders > Citing Keith's experiments on OSX: > > >>> (1) Toggle the tool bar off. Does the overall frame height shrink or > stay the same? > >>> > >>> A: Starting from Emacs -Q. Using the mouse to toggle the toolbar off= , > >>> the height of the frame shrinks -- i.e., top and left remain the same= , > >>> and the bottom shrinks upward about one-half the height of the toolba= r > >>> that disappears. The minibuffer / echo area increases in size to abo= ut > >>> 3 lines of text, with just one line of text that reads: "menu-bar > >>> options showhide showhide-tool-bar". > >>> > >>> > >>> (2) Toggle the tool bar on again. Does the overall frame height > increase or stay the same? > >>> > >>> A: The frame height quickly shrinks and expands, but ultimately remai= ns > >>> the same size -- i.e., slightly less than when Emacs -Q first began i= ts > >>> GUI session. > > I'll attach two screenshots. The problem arose after Jan installed this > change: > > > diff --git a/src/ChangeLog b/src/ChangeLog > index 69da1c3..861ba91 100644 > --- a/src/ChangeLog > +++ b/src/ChangeLog > @@ -1,3 +1,8 @@ > +2015-01-06 Jan Dj=C3=A4rv > + > + * nsterm.m (x_set_window_size): Call updateFrameSize to get real > + size instead of using widht/height. The frame may be constrained. > + > 2015-01-05 Paul Eggert > > * lisp.h (XSYMBOL): Parenthesize id in forward decl. > diff --git a/src/nsterm.m b/src/nsterm.m > index 2ccb7fe..bf3192b 100644 > --- a/src/nsterm.m > +++ b/src/nsterm.m > @@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f, > [view setBoundsOrigin: origin]; > } > > - change_frame_size (f, width, height, 0, 1, 0, pixelwise); > -/* SET_FRAME_GARBAGED (f); // this short-circuits expose call in > drawRect */ > - > - mark_window_cursors_off (XWINDOW (f->root_window)); > - cancel_mouse_face (f); > - > + [view updateFrameSize: NO]; > unblock_input (); > - > - do_pending_window_change (0); > } > > where the crucial aspect is the removal of the change_frame_size call. > Note that in updateFrameSize we call change_frame_size only > > if (oldr !=3D rows || oldc !=3D cols || neww !=3D oldw || newh !=3D ol= dh) > > which usually won't hold when removing the tool bar. Maybe we should > make the change_frame_size call in updateFrameSize unconditional after > being called from update_frame_tool_bar. > > >> and the fact > >> that a frame keeps shrinking when turning off/on the tool bar. I'll > >> look into that but if you have any ideas ... > > > > I though this was by design. On NextStep, the toolbar is excluded from > > `frame-pixel-height', so it makes sense that frame size change when > enabled > > and disabled. Besides, it's height typically isn't a multiple of the te= xt > > size, so the frame would need to be resized slightly anyway (unless > > `frame-resize-pixelwise' is set). > > All true. But the problem is that enabling the tool bar doesn't make > the overall frame height as large as it has been before disabling the > tool bar. So eventually you might end up with a zero height frame. > > > There are other things that we would need to fix: > > > > * Symbols in the fringe are inverted. I saw a patch for this on the > > emacs-dev mailing list a few weeks ago but I haven't tried it out. > > > > * When the cursor is rendered in the fringe, it's only drawn incorrectl= y. > > (This problem might be related to the previous.) > > I've seen these but can't do much about them. It would be great if you > looked into these. > > > What is the time frame for the Emacs 25 release? I would be happy to wo= rk > > on this, but with my family situation, work will progress very, very > slowly. > > Bug fixes are practically always accepted. There's a short period > immediately before the release when only regressions wrt the previous > release may be fixed. So you won't have to bother about the time frame. > > > I have thought about that as well. Currently, the package provides the > > macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now, > > unfortunately they only silence the current function, not functions tha= t > > may be called by it (which is something that we would want). Hopefully,= I > > will be able to categorize the functions in such a way that the default > > setting would silence some of the more frequently called functions. > > That would be fine. > > Thanks, martin > --001a113ee5c095032b0522db7379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I can repeat the problem with the tool-bar he= re. I'll take a look at it.

I fact, it looks J= an was trying to avoid the fact that the frame could be constrained. Howeve= r, one of the changes I made was to remove the constraining of frames -- so= chances are that things would work if we would revert to the old code.

Anyway, we should try to include as much as possible = into test cases, to ensure that future changes won't break things again= .

I put the fringe problem on the "fix queue&= quot;, but it may take some time before I get to them.

=
=C2=A0 =C2=A0 -- Anders

=C2=A0
Citing Keith's experiments on OSX:

>>> (1) Toggle the tool bar off.=C2=A0 Does the overall frame heig= ht shrink or stay the same?
>>>
 >>> A: Starting from Emacs -Q.=C2=A0 Using the mouse to toggle the= toolbar off,
>>> the height of the frame shrinks -- i.e., top and left remain t= he same,
>>> and the bottom shrinks upward about one-half the height of the= toolbar
>>> that disappears.=C2=A0 The minibuffer / echo area increases in= size to about
>>> 3 lines of text, with just one line of text that reads: "= menu-bar
>>> options showhide showhide-tool-bar".
>>>
>>>
 >>> (2) Toggle the tool bar on again.=C2=A0 Does the overall frame= height increase or stay the same?
>>>
 >>> A: The frame height quickly shrinks and expands, but ultimatel= y remains
>>> the same size -- i.e., slightly less than when Emacs -Q first = began its
>>> GUI session.

 I'll attach two screenshots.=C2=A0 The problem arose after Jan installe= d this
change:


diff --git a/src/ChangeLog b/src/ChangeLog
index 69da1c3..861ba91 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-06=C2=A0 Jan Dj=C3=A4rv=C2=A0 <jan.h.d@swipnet.se>
+
+=C2=A0 =C2=A0 * nsterm.m (x_set_window_size): Call updateFrameSize to get = real
+=C2=A0 =C2=A0 size instead of using widht/height.=C2=A0 The frame may be c= onstrained.
+
=C2=A02015-01-05=C2=A0 Paul Eggert=C2=A0 <eggert@cs.ucla.edu>

=C2=A0 =C2=A0 =C2=A0* lisp.h (XSYMBOL): Parenthesize id in forward decl. diff --git a/src/nsterm.m b/src/nsterm.m
index 2ccb7fe..bf3192b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f,
=C2=A0 =C2=A0 =C2=A0[view setBoundsOrigin: origin];
=C2=A0 =C2=A0}

-=C2=A0 change_frame_size (f, width, height, 0, 1, 0, pixelwise);
-/*=C2=A0 SET_FRAME_GARBAGED (f); // this short-circuits expose call in dra= wRect */
-
-=C2=A0 mark_window_cursors_off (XWINDOW (f->root_window));
-=C2=A0 cancel_mouse_face (f);
-
+=C2=A0 [view updateFrameSize: NO];
=C2=A0 =C2=A0unblock_input ();
-
-=C2=A0 do_pending_window_change (0);
=C2=A0}

where the crucial aspect is the removal of the change_frame_size call.
Note that in updateFrameSize we call change_frame_size only

=C2=A0 =C2=A0if (oldr !=3D rows || oldc !=3D cols || neww !=3D oldw || newh= !=3D oldh)

which usually won't hold when removing the tool bar.=C2=A0 Maybe we sho= uld
make the change_frame_size call in updateFrameSize unconditional after
being called from update_frame_tool_bar.

>> and the fact
>> that a frame keeps shrinking when turning off/on the tool bar.=C2= =A0 I'll
>> look into that but if you have any ideas ...
>
> I though this was by design. On NextStep, the toolbar is excluded from=
> `frame-pixel-height', so it makes sense that frame size change whe= n enabled
> and disabled. Besides, it's height typically isn't a multiple = of the text
> size, so the frame would need to be resized slightly anyway (unless > `frame-resize-pixelwise' is set).

 All true.=C2=A0 But the problem is that enabling the tool bar doesn't m= ake
the overall frame height as large as it has been before disabling the
tool bar.=C2=A0 So eventually you might end up with a zero height frame.

> There are other things that we would need to fix:
>
> * Symbols in the fringe are inverted. I saw a patch for this on the > emacs-dev mailing list a few weeks ago but I haven't tried it out.=
>
> * When the cursor is rendered in the fringe, it's only drawn incor= rectly.
> (This problem might be related to the previous.)

I've seen these but can't do much about them.=C2=A0 It would be gre= at if you
looked into these.

> What is the time frame for the Emacs 25 release? I would be happy to w= ork
> on this, but with my family situation, work will progress very, very s= lowly.

 Bug fixes are practically always accepted.=C2=A0 There's a short period=
immediately before the release when only regressions wrt the previous
release may be fixed.=C2=A0 So you won't have to bother about the time = frame.

> I have thought about that as well. Currently, the package provides the=
> macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now= ,
> unfortunately they only silence the current function, not functions th= at
> may be called by it (which is something that we would want). Hopefully= , I
> will be able to categorize the functions in such a way that the defaul= t
> setting would silence some of the more frequently called functions.
That would be fine.

Thanks, martin

--001a113ee5c095032b0522db7379--