From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Global bar to display global information Date: Tue, 24 Apr 2012 09:06:25 -0400 Message-ID: References: <87hb5he3dy.fsf@wanadoo.es> <86k4a6pxup.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1335272808 15116 80.91.229.3 (24 Apr 2012 13:06:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Apr 2012 13:06:48 +0000 (UTC) Cc: =?iso-8859-1?Q?J=E9r=E9my?= Compostella To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 24 15:06:47 2012 Return-path: Envelope-to: ged-emacs-devel@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 1SMfSB-0000ai-DK for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2012 15:06:47 +0200 Original-Received: from localhost ([::1]:40504 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMfSA-0005a5-OA for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2012 09:06:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMfS2-0005Zt-Sn for emacs-devel@gnu.org; Tue, 24 Apr 2012 09:06:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SMfRs-0006Ak-Ms for emacs-devel@gnu.org; Tue, 24 Apr 2012 09:06:38 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:64349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMfRs-00068u-H5 for emacs-devel@gnu.org; Tue, 24 Apr 2012 09:06:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcIACxOgk/O+LN8/2dsb2JhbABDuCMDgQyBCIIJAQEEAQwbLyMFCwsRAwECHRIUDQsNFiGIAAMGBbQ6DYFrii2BNINJgTAEoSWDIIFdgwM X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="176413020" Original-Received: from 206-248-179-124.dsl.teksavvy.com (HELO pastel.home) ([206.248.179.124]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 Apr 2012 09:06:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A36B658F68; Tue, 24 Apr 2012 09:06:25 -0400 (EDT) In-Reply-To: (=?iso-8859-1?Q?=22J=E9r=E9my?= Compostella"'s message of "Fri, 30 Dec 2011 14:21:03 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.143.162 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149971 Archived-At: OK, I found the patch. To my eyes, it looks fine, but could someone more familiar with the redisplay double check that it is doing the right thing? Stefan >>>>> "J=E9r=E9my" =3D=3D J=E9r=E9my Compostella writes: > 2011/8/22 Stefan Monnier >> > Yet, the displayed information is not completely stable. What I mean is >> > that if I move the cursor in another buffer, the echo area is sometimes >> > cleared. It's a little bit annoying. How could I fix this without >> > advising several cursor displacement function ? >>=20 >> I don't know enough about this code to be able to answer. You're going >> to have to investigate which code does this "clearing" and what calls >> it, to then be able to figure out what's the best way to address the >> problem (we can change the C code for that in 24.2 if needed). >>=20 >>=20 > Hi, > I finally get time to work again on this global information area. I > think the use of " *Minibuf-0*" proposal is really interesting since the > echo area is most of the time useless and the global information are not > really useful when I'm using the minibuffer. So I tried to figure out > why it didn't work the way you said. > The problem is, considering I had put data in the " *Minibuf-0*", these > data are not displayed in the echo area. However, the " *Minibuf-0*" is > displayed each time I do a switch-to-buffer call. But once I type, the > echo area is cleared. > First, each time I type, the clear_message(1, 0) is called even when the > echo area is already cleared. This call looks useless and is part of the > cause of the behavior described above. > Second, when the echo area is clearing it does not redisplay the > miniwindow. So the " *Minibuf-0*" is not displayed as expected. > I tested this patch with emacs -Q, emacs -Q -nw and with my whole > configuration. Everything works perfectly fine and as > expected. Moreover, I verified that this patch does not generate extras > miniwindow redisplay. > Please merge it or review it, > Best regards, > J=E9r=E9my > -- > One Emacs to rule them all > From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Fri, 30 Dec 2011 14:01:13 +0100 > Subject: [PATCH] echo-area: Remove unnecessary clearing and get default m= inibuffer displayed > Each time we push a keyboard key the clear_message(1, 0) is called > even if the echo-area is already cleared. > When the echo area is cleared, the default minibuffer should be > displayed instead of an empty message. > With this patch, it is possible to display information in the echo > area using the default minibuffer when the echo area is cleared and > the minibuffer is inactive. > Signed-off-by: Jeremy Compostella > --- > src/keyboard.c | 5 +++-- > src/xdisp.c | 13 ++++++++++++- > 2 files changed, 15 insertions(+), 3 deletions(-) > diff --git a/src/keyboard.c b/src/keyboard.c > index 2df1ba7..771ee98 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -2982,9 +2982,10 @@ read_char (int commandflag, ptrdiff_t nmaps, Lisp_= Object *maps, > || (!(EQ (Qhelp_echo, XCAR (c))) > && !(EQ (Qswitch_frame, XCAR (c))))) > { > - if (!NILP (echo_area_buffer[0])) > + if (!NILP (echo_area_buffer[0])) { > safe_run_hooks (Qecho_area_clear_hook); > - clear_message (1, 0); > + clear_message (1, 0); > + } > } =20 > reread_for_input_method: > diff --git a/src/xdisp.c b/src/xdisp.c > index 90375ba..77cd80c 100644 > --- a/src/xdisp.c > +++ b/src/xdisp.c > @@ -12666,6 +12666,9 @@ redisplay_internal (void) > frames. Zero means, only selected_window is considered. */ > int consider_all_windows_p; =20 > + /* Non-zero means redisplay has to redisplay the miniwindow */ > + int update_miniwindow_p =3D 0; > + > TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p)); =20 > /* No redisplay if running in batch mode or frame is not yet fully > @@ -12852,6 +12855,10 @@ redisplay_internal (void) > && !MINI_WINDOW_P (XWINDOW (selected_window)))) > { > int window_height_changed_p =3D echo_area_display (0); > + > + if (message_cleared_p) > + update_miniwindow_p =3D 1; > + > must_finish =3D 1; =20 > /* If we don't display the current message, don't clear the > @@ -13227,7 +13234,7 @@ redisplay_internal (void) > } > else if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf)) > { > - Lisp_Object mini_window; > + Lisp_Object mini_window =3D FRAME_MINIBUF_WINDOW (sf); > struct frame *mini_frame; =20 > displayed_buffer =3D XBUFFER (XWINDOW (selected_window)->buffer); > @@ -13236,6 +13243,10 @@ redisplay_internal (void) > internal_condition_case_1 (redisplay_window_1, selected_window, > list_of_error, > redisplay_window_error); > + if (update_miniwindow_p) > + internal_condition_case_1 (redisplay_window_1, mini_window, > + list_of_error, > + redisplay_window_error); =20 > /* Compare desired and current matrices, perform output. */ =20 > --=20 > 1.7.2.5