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: Fri, 23 Oct 2015 11:13:47 +0200 Message-ID: References: <561E92D8.1050500@gmx.at> <561F7943.9090309@gmx.at> <562746AA.7090004@gmx.at> <5627B83F.9060303@gmx.at> <5629022A.9060408@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143ac627ba11a0522c20788 X-Trace: ger.gmane.org 1445591667 30595 80.91.229.3 (23 Oct 2015 09:14:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 09:14:27 +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 Fri Oct 23 11:14:16 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 1ZpYQQ-0007FU-5Z for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Oct 2015 11:14:14 +0200 Original-Received: from localhost ([::1]:37114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpYQP-0006Pb-Up for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Oct 2015 05:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpYQI-0006JP-Uw for bug-gnu-emacs@gnu.org; Fri, 23 Oct 2015 05:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpYQE-0007XQ-PO for bug-gnu-emacs@gnu.org; Fri, 23 Oct 2015 05:14:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpYQE-0007XL-KQ for bug-gnu-emacs@gnu.org; Fri, 23 Oct 2015 05:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZpYQE-00027U-9K for bug-gnu-emacs@gnu.org; Fri, 23 Oct 2015 05:14: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: Fri, 23 Oct 2015 09:14: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.14455916318122 (code B ref 21415); Fri, 23 Oct 2015 09:14:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 23 Oct 2015 09:13:51 +0000 Original-Received: from localhost ([127.0.0.1]:33793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpYQ2-00026v-KS for submit@debbugs.gnu.org; Fri, 23 Oct 2015 05:13:51 -0400 Original-Received: from mail-vk0-f43.google.com ([209.85.213.43]:36233) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpYQ0-00026n-K2 for 21415@debbugs.gnu.org; Fri, 23 Oct 2015 05:13:49 -0400 Original-Received: by vkex70 with SMTP id x70so60561327vke.3 for <21415@debbugs.gnu.org>; Fri, 23 Oct 2015 02:13:48 -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=qO8p1dGaEg4fXJu3LRQP1v63UdSB+DLu+97tpaqOKC0=; b=mQRMyrP9iCnT5A43zJpsd1cMJTzvNov4pRb+n+h5yriWyx1cyLzzm07huhHNs39dQ0 3IFsu5q2P2SB2So2/0rRWOb3dDnNoWb8+RPDa7oSE/6OF3tON0aNVIPuwZijZwcW87Vj KXFyqdb943fIscxOlwtGLQ+cVh4Glo/Ho58omVNJ5B+KcUvF6kvIfDaM1tWzpPf6sdpX TUt1B7iYtD41pJ5AVHiRk+e6WWGByzNxCVyGfkjT+o6ZGQZBxklYZCx1dgtbteZSZn1X 4sjalQ6Y0tVh5oL37PtthIVj1Ki7Sh8FGMKG/YxLzIJNHbsBWv4j6e+8ZTALmmrLYO9c Ikmw== X-Received: by 10.31.179.194 with SMTP id c185mr5436584vkf.68.1445591628093; Fri, 23 Oct 2015 02:13:48 -0700 (PDT) Original-Received: by 10.31.210.133 with HTTP; Fri, 23 Oct 2015 02:13:47 -0700 (PDT) In-Reply-To: <5629022A.9060408@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:107898 Archived-At: --001a1143ac627ba11a0522c20788 Content-Type: text/plain; charset=UTF-8 Hi, > Meanwhile please install your changes. Done! > Now the only remaining issue we must fix before the release is that of > the non-shrinking echo area when toggling off the tool bar I wasn't aware of this problem. Can you point me to where it's described. > 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 text size, so the frame would need to be resized slightly anyway (unless `frame-resize-pixelwise' is set). 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 incorrectly. (This problem might be related to the previous.) What is the time frame for the Emacs 25 release? I would be happy to work on this, but with my family situation, work will progress very, very slowly. > I'll give you some feedback when I'm back there. One problem with > NSTRACE I have is that it clutters output with ns_update_window_begin > and ns_defined_color entries. I now started to comment them out one by > one. Maybe you could devise a method to display these optionally only. 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 that 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. / Anders On Thu, Oct 22, 2015 at 5:35 PM, martin rudalics wrote: > > I have never used GNUStep, maybe I should try it out so that my patch > work > > there. Are there build instructions for this somewhere? > > Don't bother. Hardly anyone but me regularly builds on GNUStep. And I > can't use it anyway - too many other problems. > > > Anyway, I think the problem you are seeing is due to the fact that I have > > replaced the code in "zoom" with custom code that simply resizes the > frame. > > On OS X there is nothing special happening when maximizing the frame -- > the > > outer frame (one pixel thick) is still there, no buttons should change > > state etc. > > I suppose so. Maybe I find a way to splice in some code tailored for > GNUStep. But it will have low priority. > > > One thing we should try is to check is the old zoom system would work > > better in GNUStep after all (this is the first of the three different > zoom > > version in the code). > > > > Also, it would be interesting to see the NSTRACE output of a session > where > > we go "fullwidth" and then "maximized" and compare it with what happens > > under OS X -- if it still is a problem after changing the zoom method. > > I'll give you some feedback when I'm back there. One problem with > NSTRACE I have is that it clutters output with ns_update_window_begin > and ns_defined_color entries. I now started to comment them out one by > one. Maybe you could devise a method to display these optionally only. > > > When it comes to the double tool bar, I have unfortunately no idea what > the > > problem is. > > It's a bad interaction between GNUStep and the window manager. Maybe I > can find out more. > > Meanwhile please install your changes. > > martin > --001a1143ac627ba11a0522c20788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

>=C2=A0Meanwhile please install your changes.

Done!
<= div>

> Now the only remaining issue we must= fix before the release is that of
> the non-shrinking echo area when togglin= g off the tool bar

<= /div>
I wasn't aware of this probl= em. Can you point me to where it's described.
=C2=A0

> 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 f= rom `frame-pixel-height', so it makes sense that frame size change when= enabled and disabled. Besides, it's height typically isn't a multi= ple of the text size, so the frame would need to be resized slightly anyway= (unless `frame-resize-pixelwise' is set).

<= div>

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 t= ried it out.

* When the cursor is rendered in the = fringe, it's only drawn incorrectly. (This problem might be related to = the previous.)

What is the time frame for the Emac= s 25 release? I would be happy to work on this, but with my family situatio= n, work will progress very, very slowly.


> I'll give you some feedback= when I'm back there.=C2=A0 One problem with
> NSTRACE I have is that it = clutters output with ns_update_window_begin
> and ns_defined_color entries.= =C2=A0 I now started to comment them out one by
> one.=C2=A0 Maybe you could = devise a method to display these optionally only.

=
I have thought about that as well. Currently, the package provid= es the macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right n= ow, 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 se= tting would silence some of the more frequently called functions.

/ Anders


O= n Thu, Oct 22, 2015 at 5:35 PM, martin rudalics <rudalics@gmx.at> wrote:
> I have n= ever used GNUStep, maybe I should try it out so that my patch work
> there. Are there build instructions for this somewhere?

 Don't bother.=C2=A0 Hardly anyone but me regularly builds on GNUStep.= =C2=A0 And I
can't use it anyway - too many other problems.

> Anyway, I think the problem you are seeing is due to the fact that I h= ave
> replaced the code in "zoom" with custom code that simply res= izes the frame.
> On OS X there is nothing special happening when maximizing the frame -= - the
> outer frame (one pixel thick) is still there, no buttons should change=
> state etc.

 I suppose so.=C2=A0 Maybe I find a way to splice in some code tailored for<= br> GNUStep.=C2=A0 But it will have low priority.

> One thing we should try is to check is the old zoom system would work<= br> > better in GNUStep after all (this is the first of the three different = zoom
> version in the code).
>
> Also, it would be interesting to see the NSTRACE output of a session w= here
> we go "fullwidth" and then "maximized" and compare= it with what happens
> under OS X -- if it still is a problem after changing the zoom method.=

I'll give you some feedback when I'm back there.=C2=A0 One problem = with
NSTRACE I have is that it clutters output with ns_update_window_begin
and ns_defined_color entries.=C2=A0 I now started to comment them out one b= y
one.=C2=A0 Maybe you could devise a method to display these optionally only= .

> When it comes to the double tool bar, I have unfortunately no idea wha= t the
> problem is.

 It's a bad interaction between GNUStep and the window manager.=C2=A0 Ma= ybe I
can find out more.

Meanwhile please install your changes.

martin

--001a1143ac627ba11a0522c20788--