Tools bar an menu bar in rev. 115441?

Tools bar an menu bar in rev. 115441?

[Angelo Graziosi]

The trunk rev. 115441 seems to have lost the menu and tools bar... is to 
be expected? How to restore the previous behavior?

- Angelo

Re: Tools bar an menu bar in rev. 115441?

[Dmitry Antipov]

On 12/10/2013 01:18 AM, Angelo Graziosi wrote:

> The trunk rev. 115441 seems to have lost the menu and tools bar...
> is to be expected? How to restore the previous behavior?

Such a bug reports are very likely to be unattended. Usually it's
much better to provide a recipe to reproduce the problem, starting
from 'emacs -Q' (note that menu bar and tool bar can be easily
disabled with just two lines in your .emacs).

Dmitry

Re: Tools bar an menu bar in rev. 115441?

[Eli Zaretskii]

> Date: Tue, 10 Dec 2013 06:43:17 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: emacs <emacs-devel@gnu.org>
> 
> On 12/10/2013 01:18 AM, Angelo Graziosi wrote:
> 
> > The trunk rev. 115441 seems to have lost the menu and tools bar...
> > is to be expected? How to restore the previous behavior?
> 
> Such a bug reports are very likely to be unattended. Usually it's
> much better to provide a recipe to reproduce the problem, starting
> from 'emacs -Q' (note that menu bar and tool bar can be easily
> disabled with just two lines in your .emacs).

Indeed.  And please use "M-x report-emacs-bug RET", because at least
in the native w32 build I see no change wrt these features, so the
particulars of your system are important.

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Angelo Graziosi]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

The issue seems Cygwin specific because I cannot reproduce it with 
similar GTK builds on GNU/Linux Ubuntu 12.04...

The attached screen shots (r.115382 OK, r.115447 .NOT.OK) and the 
following bug report (from rev. 115447) are taken with

$ emacs -Q &

Il 10/12/2013 4.40, Eli Zaretskii ha scritto:
>
> Indeed.  And please use "M-x report-emacs-bug RET", because at least

In GNU Emacs 24.3.50.1 (i686-pc-cygwin, GTK+ Version 3.8.2)
  of 2013-12-10 on homepc
Windowing system distributor `The Cygwin/X Project', version 11.0.11404000
Configured using:
  `configure --prefix=/usr/local/emacs CFLAGS=-O3'

Important settings:
   value of $LANG: it_IT.UTF-8
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<help-echo> <help-echo> M-x <help-echo> <down-mouse-2>
<mouse-2> <help-echo> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)






[-- Attachment #2: screenshots.tar.bz2 --]
[-- Type: application/octet-stream, Size: 64290 bytes --]

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Ken Brown]

On 12/10/2013 6:12 PM, Angelo Graziosi wrote:
> The issue seems Cygwin specific because I cannot reproduce it with
> similar GTK builds on GNU/Linux Ubuntu 12.04...

A bisection shows that the problem starts with the following commit:

revno: 115394
committer: Dmitry Antipov <dmantipov@yandex.ru>
branch nick: trunk
timestamp: Fri 2013-12-06 09:49:05 +0400
message:
   * xterm.c (input_signal_count): Remove.
   (x_dispatch_event): Define unconditionally.
   (x_make_frame_visible): Process X events until the frame
   is really visible (Bug#16027).
   * xterm.h (x_dispatch_event): Declare unconditionally.


Ken

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Angelo Graziosi]

Hi Dmitry,

Il 11/12/2013 18.53, Ken Brown ha scritto:
> On 12/10/2013 6:12 PM, Angelo Graziosi wrote:
>> The issue seems Cygwin specific because I cannot reproduce it with
>> similar GTK builds on GNU/Linux Ubuntu 12.04...
>
> A bisection shows that the problem starts with the following commit:
>
> revno: 115394
> committer: Dmitry Antipov <dmantipov@yandex.ru>
> branch nick: trunk
> timestamp: Fri 2013-12-06 09:49:05 +0400
> message:
>    * xterm.c (input_signal_count): Remove.
>    (x_dispatch_event): Define unconditionally.
>    (x_make_frame_visible): Process X events until the frame
>    is really visible (Bug#16027).
>    * xterm.h (x_dispatch_event): Declare unconditionally.

any comment?

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Ken Brown]

On 12/11/2013 4:37 PM, Angelo Graziosi wrote:
> Hi Dmitry,
>
> Il 11/12/2013 18.53, Ken Brown ha scritto:
>> On 12/10/2013 6:12 PM, Angelo Graziosi wrote:
>>> The issue seems Cygwin specific because I cannot reproduce it with
>>> similar GTK builds on GNU/Linux Ubuntu 12.04...
>>
>> A bisection shows that the problem starts with the following commit:
>>
>> revno: 115394
>> committer: Dmitry Antipov <dmantipov@yandex.ru>
>> branch nick: trunk
>> timestamp: Fri 2013-12-06 09:49:05 +0400
>> message:
>>    * xterm.c (input_signal_count): Remove.
>>    (x_dispatch_event): Define unconditionally.
>>    (x_make_frame_visible): Process X events until the frame
>>    is really visible (Bug#16027).
>>    * xterm.h (x_dispatch_event): Declare unconditionally.
>
> any comment?

The patch below seems to fix the problem.  It essentially just restores 
some code that Dmitry removed.  (It also reverts a later change that 
Paul made in rev 115412 as a result of the removal.)  Dmitry, did you 
have some reason for removing that code?  I can't see that it has 
anything to do with the bug you were trying to fix.

Ken

=== modified file 'src/keyboard.c'
--- src/keyboard.c      2013-12-07 23:04:10 +0000
+++ src/keyboard.c      2013-12-11 21:45:31 +0000
@@ -1954,7 +1954,6 @@

  static struct atimer *poll_timer;

-#ifdef HAVE_NTGUI
  /* Poll for input, so that we catch a C-g if it comes in.  */
  void
  poll_for_input_1 (void)
@@ -1963,7 +1962,6 @@
        && !waiting_for_input)
      gobble_input ();
  }
-#endif

  /* Timer callback function for poll_timer.  TIMER is equal to
     poll_timer.  */
@@ -2015,8 +2013,6 @@
  #endif
  }

-#ifdef HAVE_NTGUI
-
  /* True if we are using polling to handle input asynchronously.  */

  bool
@@ -2031,7 +2027,6 @@
    return 0;
  #endif
  }
-#endif

  /* Turn off polling.  */


=== modified file 'src/xterm.c'
--- src/xterm.c 2013-12-11 15:06:04 +0000
+++ src/xterm.c 2013-12-11 21:36:55 +0000
@@ -8923,6 +8923,23 @@
        {
         /* Force processing of queued events.  */
         x_sync (f);
+
+       /* Machines that do polling rather than SIGIO have been
+          observed to go into a busy-wait here.  So we'll fake an
+          alarm signal to let the handler know that there's something
+          to be read.  We used to raise a real alarm, but it seems
+          that the handler isn't always enabled here.  This is
+          probably a bug.  */
+       if (input_polling_used ())
+         {
+           /* It could be confusing if a real alarm arrives while
+              processing the fake one.  Turn it off and let the
+              handler reset it.  */
+           int old_poll_suppress_count = poll_suppress_count;
+           poll_suppress_count = 1;
+           poll_for_input_1 ();
+           poll_suppress_count = old_poll_suppress_count;
+         }
         if (XPending (FRAME_X_DISPLAY (f)))
           {
             XEvent xev;

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Dmitry Antipov]

On 12/12/2013 01:59 AM, Ken Brown wrote:

> Dmitry, did you have some reason for removing that code?  I can't see
> that it has anything to do with the bug you were trying to fix.

I missed the fact that poll_for_input_1 is needed to call terminal socket
hooks :-(. Reverted in r115478.

Dmitry

Re: Tools bar an menu bar in rev. 115447? [Cygwin]

[Eli Zaretskii]

> Date: Thu, 12 Dec 2013 08:11:06 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Angelo Graziosi <angelo.graziosi@alice.it>, 
>  Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> On 12/12/2013 01:59 AM, Ken Brown wrote:
> 
> > Dmitry, did you have some reason for removing that code?  I can't see
> > that it has anything to do with the bug you were trying to fix.
> 
> I missed the fact that poll_for_input_1 is needed to call terminal socket
> hooks :-(. Reverted in r115478.

Out of curiosity: how can polling for input affect the display of the
tool bar and menu bar (or lack thereof)?