* Global bar to display global information @ 2011-08-16 14:33 Jérémy Compostella 2011-08-16 15:29 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Jérémy Compostella @ 2011-08-16 14:33 UTC (permalink / raw) To: emacs-devel All, As many user, I use Emacs as my full desktop environment on several system (mainly GNU/Linux and Windows at work). To be as independent as possible, I use the mode-line to show information like current date and time, jabber notifications, unread mail number, ... and I start Emacs in full-screen. The problem is since I use several windows (in Emacs term), these information are duplicated and are not always visible. Indeed, the mode-line bar is split in the middle of the information it displays. I think it could be really great if Emacs would provide a global bar based on the same mechanisms as the mode line but dedicated to this kind of global information. What is your opinion ? Is this subject already discussed before ? Thanks, Jérémy ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: Global bar to display global information 2011-08-16 14:33 Global bar to display global information Jérémy Compostella @ 2011-08-16 15:29 ` Drew Adams 2011-08-16 16:18 ` Óscar Fuentes 2011-08-16 17:44 ` chad 2011-08-20 18:29 ` Andreas Röhler 2 siblings, 1 reply; 43+ messages in thread From: Drew Adams @ 2011-08-16 15:29 UTC (permalink / raw) To: 'Jérémy Compostella', emacs-devel > I use the mode-line to show information like current date and > time, jabber notifications, unread mail number, ... and I > start Emacs in full-screen. > > The problem is since I use several windows (in Emacs term), these > information are duplicated and are not always visible. Indeed, the > mode-line bar is split in the middle of the information it displays. > > I think it could be really great if Emacs would provide a global bar > based on the same mechanisms as the mode line but dedicated to this > kind of global information. What is your opinion ? Is this subject > already discussed before? +1 I sort of recall this having been suggested before; dunno... Personally, I think it would be a good (optional) behavior to provide, especially for the case where a user has a standalone minibuffer frame. Using a standalone minibuffer frame already removes the duplication of multiple minibuffer/echo area lines. That, and having a single, stable place to look for messages and input text, is the raison d'etre of a standalone minibuffer. This proposed feature is along the same lines. But this would not have as its goal to eliminate mode lines from individual windows. It would instead just free up some of that individual-window mode line space that might be used for global info (not specific to the given buffer/window). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 15:29 ` Drew Adams @ 2011-08-16 16:18 ` Óscar Fuentes 2011-08-16 16:40 ` Drew Adams 2011-08-16 17:42 ` joakim 0 siblings, 2 replies; 43+ messages in thread From: Óscar Fuentes @ 2011-08-16 16:18 UTC (permalink / raw) To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > +1 +1 [snip] > This proposed feature is along the same lines. But this would not > have as its goal to eliminate mode lines from individual windows. It > would instead just free up some of that individual-window mode line > space that might be used for global info (not specific to the given > buffer/window). I'll appreacite such feature. Most of the time the minibuffer is an idle blank line at the bottom of the frame. Using it for displaying some global info sounds quite convenient. It could display the global info even while asking for input, overwritting the area used by the info as necessary. ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: Global bar to display global information 2011-08-16 16:18 ` Óscar Fuentes @ 2011-08-16 16:40 ` Drew Adams 2011-08-16 17:04 ` Óscar Fuentes 2011-08-16 17:31 ` Stefan Monnier 2011-08-16 17:42 ` joakim 1 sibling, 2 replies; 43+ messages in thread From: Drew Adams @ 2011-08-16 16:40 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > > This proposed feature is along the same lines. But this would not > > have as its goal to eliminate mode lines from individual > > windows. It would instead just free up some of that > > individual-window mode line space that might be used for global > > info (not specific to the given buffer/window). > > I'll appreacite such feature. > > Most of the time the minibuffer is an idle blank line at the bottom of > the frame. Using it for displaying some global info sounds quite > convenient. It could display the global info even while asking for > input, overwritting the area used by the info as necessary. Ouch! That's not what I meant at all. I would not want to see such info displayed in the minibuffer/echo area itself (too complex, confusing, distracting, messy, noisy). And we already have ways of posting text to the echo area (same space as minibuffer) when the minibuffer is inactive: `message'. That messages get replaced by later messages and by minibuffer input is just a further demonstration that using the minibuffer/echo area for this global info would be a bad idea. All I really meant was an analogy: In the same way that a standalone minibuffer frame lets you factor out the multiple minibuffers into a single one, so some kind of global mode line would let you factor out the common/global info from the multiple mode lines into a single one. Somewhere. The feature needs to be optional in any case (obviously). It could also be a user choice where to put this global/common mode line. Choices might be: a. In a standalone minibuffer frame (if it exists), in its own dedicated space within that frame (e.g. 1 line, 2 lines? extendable?), perhaps above the minibuffer/echo area. b. Standalone, in its own frame. c. As a separate line in some existing frame (but in only one). We'd need some way to let users (and Lisp code) choose which frame. d. ? ... (As a user, I would choose (a).) However, for (c), there would be the annoyance of not necessarily seeing the info whenever the frame in question is somewhat occluded by another frame. That could happen in (a) or (b) also, but there the frame could presumably be positioned so that it is generally visible. That's anyway what users (e.g. I) do now for a minibuffer frame. (Mine's across the bottom of the screen, and I generally fit other frames, by default, so they don't overlap it.) Another possibility here (for (a) & (b)) would be to provide an `always-on-top' frame parameter that would cause its frame to never be occluded by other (Emacs) frames (except possibly by another frame that also has non-nil `always-on-top'). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 16:40 ` Drew Adams @ 2011-08-16 17:04 ` Óscar Fuentes 2011-08-16 17:42 ` Drew Adams 2011-08-16 17:31 ` Stefan Monnier 1 sibling, 1 reply; 43+ messages in thread From: Óscar Fuentes @ 2011-08-16 17:04 UTC (permalink / raw) To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: >> Most of the time the minibuffer is an idle blank line at the bottom of >> the frame. Using it for displaying some global info sounds quite >> convenient. It could display the global info even while asking for >> input, overwritting the area used by the info as necessary. > > Ouch! That's not what I meant at all. I know. It was an alternative idea. > I would not want to see such info displayed in the minibuffer/echo > area itself (too complex, confusing, distracting, messy, noisy). > > And we already have ways of posting text to the echo area (same space > as minibuffer) when the minibuffer is inactive: `message'. That > messages get replaced by later messages and by minibuffer input is > just a further demonstration that using the minibuffer/echo area for > this global info would be a bad idea. `message' is used for ephemeral info, very ephemeral (just a keypress makes it go away). I was thinking about something stable that is hidden (totally or partially) while the minibuffer/echo area is used for its current purpose. But your comment about `message' makes me think that *maybe* it would be confusing/distracting/etc when something is posted to the echo area with `message' to be quickly replaced by the global info. It may create a blinking effect. I don't like standalone frames for things like the minibuffer or our hypothetical global info display. I work on just one frame and reusing the minibuffer area looks like a good idea, if it could be implemented on a sane way. If that is not possible or convenient, a dedicated line on each frame looks like the next choice. (If the global info line is displayed on just one frame, what happens when the user creates a new frame on a remote display?) [snip] ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: Global bar to display global information 2011-08-16 17:04 ` Óscar Fuentes @ 2011-08-16 17:42 ` Drew Adams 2011-08-16 19:23 ` Jérémy Compostella 2011-08-16 20:00 ` Thien-Thi Nguyen 0 siblings, 2 replies; 43+ messages in thread From: Drew Adams @ 2011-08-16 17:42 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > If [reusing the minibuffer area] is not possible or convenient, > a dedicated line on each frame looks like the next choice. If it is on each frame then the feature doesn't really factor out the global info. Since you use only one frame, "on each frame" just hides the general-case duplication from you. > (If the global info line is displayed on just one frame, what happens > when the user creates a new frame on a remote display?) Dunno. (But why would you want this info on *each* remote frame?) So make it one frame per display (remotes + local), instead of just one frame overall. Or I suppose users could configure some option to specify just which frames to use... (Hello, Martin ;-)) Essentially, what's requested is some stable place to post (and leave posted) a bit of general info - info that is not specific to any buffer or window or frame... What you feel about windows should also hold for frames: get rid of the duplication. That you use only one frame does not mean that that need goes away for others who might like the feature. It makes most sense not to duplicate that info anywhere, with the possible exception I guess that it could be available (once) on each display (e.g. each remote display, plus local). That means not on every frame and not on every window. It means either giving it its own, dedicated frame (frames, if we include remote) or posting it in some existing frame (e.g. standalone minibuffer frame). And the info need not be limited to a single line. Especially if it is in a dedicated frame, it could use any number of lines. This could be done easily now, just by using a dedicated frame. Instead of posting your global info to the mode line, just display it in a buffer that uses a special frame (which is dedicated). Yes, that's different from (somehow) gathering up some common, global stuff from existing mode lines and displaying it elsewhere. But how to identify such factorable info in existing mode lines? Anyway, it sounds like the main case (OP) was user code that displays such stuff in the mode line. If that hurts then don't do it - instead, put it in a special-display buffer in its own frame. For my part, I still think it could be useful to (be able to) add the info to a standalone minibuffer frame. One difference from having a separate frame for it is that that would save the real estate of an extra frame title and border. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 17:42 ` Drew Adams @ 2011-08-16 19:23 ` Jérémy Compostella 2011-08-16 19:46 ` chad 2011-08-16 20:00 ` Thien-Thi Nguyen 1 sibling, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-08-16 19:23 UTC (permalink / raw) To: emacs-devel Drew Adams <drew.adams <at> oracle.com> writes: > > > If [reusing the minibuffer area] is not possible or convenient, > > a dedicated line on each frame looks like the next choice. > > If it is on each frame then the feature doesn't really factor out the > global info. Since you use only one frame, "on each frame" just hides > the general-case duplication from you. > > (If the global info line is displayed on just one frame, what > > happens when the user creates a new frame on a remote display?) > > Dunno. (But why would you want this info on *each* remote frame?) > > So make it one frame per display (remotes + local), instead of just > one frame overall. Or I suppose users could configure some option to > specify just which frames to use... (Hello, Martin ) > > Essentially, what's requested is some stable place to post (and leave > posted) a bit of general info - info that is not specific to any > buffer or window or frame... > > What you feel about windows should also hold for frames: get rid of > the duplication. That you use only one frame does not mean that that > need goes away for others who might like the feature. > > It makes most sense not to duplicate that info anywhere, with the > possible exception I guess that it could be available (once) on each > display (e.g. each remote display, plus local). > > That means not on every frame and not on every window. It means > either giving it its own, dedicated frame (frames, if we include > remote) or posting it in some existing frame (e.g. standalone > minibuffer frame). > > And the info need not be limited to a single line. Especially if it > is in a dedicated frame, it could use any number of lines. > > This could be done easily now, just by using a dedicated frame. > Instead of posting your global info to the mode line, just display it > in a buffer that uses a special frame (which is dedicated). > > Yes, that's different from (somehow) gathering up some common, global > stuff from existing mode lines and displaying it elsewhere. But how > to identify such factorable info in existing mode lines? > > Anyway, it sounds like the main case (OP) was user code that displays > such stuff in the mode line. If that hurts then don't do it - > instead, put it in a special-display buffer in its own frame. > > For my part, I still think it could be useful to (be able to) add the > info to a standalone minibuffer frame. One difference from having a > separate frame for it is that that would save the real estate of an > extra frame title and border. What I imagine is more like a mode-line bar with the current configuration associated to current Emacs server. The user could enable this global bar and modify a simple global-line-format (like the mode-line-format) to add whatever information he wants. I'm currently using Emacs 23. And I really think it looks inconsistent about some features. What does the display-time feature means ? I think it does not make any sense to have the date and time displayed on each window. As most user, I activate this feature to be able to have the date and time visible even when my underlined desktop environment is hidden or disabled. I just want to be able to see the date and time at the same place every time I need. As another example, I developed a personal activity manager (looks like the usual multi-desktop feature except that each desktop is named and changes between desktop is managed through a stack). And I want to display the current activity name. I do it modifying the mode-line-format but this information is redundant over the all the window on the same frame. This information should be factored by frame. Like the date and time it does not make any sense for me to have this information displayed on each frame. Currently my mode-line is very long in some mode and some information should not be on this mode-line (date/time, jabber notification, current activity, ...). I think the configuration (global-line-format) should be associated to each Emacs server but displaying this bar should be a frame dependant user choice. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 19:23 ` Jérémy Compostella @ 2011-08-16 19:46 ` chad 2011-08-16 19:48 ` chad 2011-08-16 20:54 ` Jérémy Compostella 0 siblings, 2 replies; 43+ messages in thread From: chad @ 2011-08-16 19:46 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1237 bytes --] On Aug 16, 2011, at 12:23 PM, Jérémy Compostella wrote: > > I'm currently using Emacs 23. And I really think it looks inconsistent > about some features. What does the display-time feature means ? > […] I just want to be able to see the date and time at > the same place every time I need. For the vast majority of users, emacs is not their operating system, and such non-editing facilities don't need to be provided by their editor. For those who do use emacs as (a larger part of) their operating system, they typically want very specific things, and know how to assemble those things from the (many) parts emacs provides. For example, Ted Zlanatov was pushing forward an effort in this area: http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html For some(including you), the header-line provides an easy way to meet your goals, but others, like Drew Adams, live in a very multi-frame world, and need different tools. There is interest in this area, especially if you're willing to work on the leading edge. Perhaps you should try either header-line-format or Ted's `Emacs as a Desktop Environment' idea and report back your experience with either/both. Hope that helps, *Chad [-- Attachment #2: Type: text/html, Size: 1951 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 19:46 ` chad @ 2011-08-16 19:48 ` chad 2011-09-25 12:42 ` Ted Zlatanov 2011-08-16 20:54 ` Jérémy Compostella 1 sibling, 1 reply; 43+ messages in thread From: chad @ 2011-08-16 19:48 UTC (permalink / raw) To: Emacs devel; +Cc: Jérémy Compostella On Aug 16, 2011, at 12:46 PM, chad wrote: >> >> For example, Ted Zlanatov was pushing forward an effort in this area: That should have been `Ted Zlatanov'. My apologies. *Chad ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 19:48 ` chad @ 2011-09-25 12:42 ` Ted Zlatanov 0 siblings, 0 replies; 43+ messages in thread From: Ted Zlatanov @ 2011-09-25 12:42 UTC (permalink / raw) To: emacs-devel On Tue, 16 Aug 2011 12:48:35 -0700 chad <yandros@MIT.EDU> wrote: c> On Aug 16, 2011, at 12:46 PM, chad wrote: >>> >>> For example, Ted Zlanatov was pushing forward an effort in this area: c> That should have been `Ted Zlatanov'. My apologies. No problem at all. I get "Zlantanov" etc. all the time. My dad has the bigger problem: first name is Zlatko, same last name. He goes by Mr. Z :) Ted ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 19:46 ` chad 2011-08-16 19:48 ` chad @ 2011-08-16 20:54 ` Jérémy Compostella 2011-08-16 22:32 ` chad 1 sibling, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-08-16 20:54 UTC (permalink / raw) To: emacs-devel chad <yandros <at> MIT.EDU> writes: > > > > On Aug 16, 2011, at 12:23 PM, Jérémy Compostella wrote: > > I'm currently using Emacs 23. And I really think it looks inconsistentabout some features. What does the display-time feature means ? > […] I just want to be able to see the date and time atthe same place every time I need. > > > For the vast majority of users, emacs is not their operating system, and > such non-editing facilities don't need to be provided by their editor. For > those who do use emacs as (a larger part of) their operating system, > they typically want very specific things, and know how to assemble those > things from the (many) parts emacs provides. For example, Ted Zlanatov > was pushing forward an effort in this area: > > http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html > > For some(including you), the header-line provides an easy way to meet > your goals, but others, like Drew Adams, live in a very multi-frame world, > and need different tools. I really do understand that we have different usage of Emacs. However, the feature I describe could be enable or not without any sides effects. > There is interest in this area, especially if you're willing to work on the > leading edge. Perhaps you should try either header-line-format or Ted's > `Emacs as a Desktop Environment' idea and report back your experience > with either/both. As long as I know, header-line-format is buffer related and not frame related. Am I wrong ? What is this Ted's `Emacs as a Desktop Environment' you are talking about ? > Hope that helps, > *Chad ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 20:54 ` Jérémy Compostella @ 2011-08-16 22:32 ` chad 2011-08-16 22:49 ` Jérémy Compostella ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: chad @ 2011-08-16 22:32 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote: > As long as I know, header-line-format is buffer related and not frame related. > Am I wrong ? It is buffer- and not frame-associated, yes. I was suggesting that you consider building a way to have only the topmost window in a given frame display the header-line. This might be tricky in general, but since you're using a desktop system of your own creation, it seems likely to be easier for you. For emacs in general, there is a lot of currently on-going work/discussion around frame and window parameters, so it's probably a bit too early to try to figure out such a mechanism for emacs24, but that's just an artifact of development right now. > What is this Ted's `Emacs as a Desktop Environment' you are talking about ? Some developers are pursing the idea of moving all of the `important' parts of the desktop environment inside emacs, or at least inside emacs' easy reach. This includes `desktop widgets' and an associated `dock', that would be in specialized frames/windows. It's closer to Thien-Thi Nguyen's idea of a `special messages buffer' than your `global mode-line', but it could easily serve both purposes, and other more gui-based uses as well. You can read the discussion (from emacs-devel archives) starting here: >> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html *Chad ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 22:32 ` chad @ 2011-08-16 22:49 ` Jérémy Compostella 2011-08-17 7:49 ` Nicolas Martyanoff 2011-09-25 12:53 ` Ted Zlatanov 2 siblings, 0 replies; 43+ messages in thread From: Jérémy Compostella @ 2011-08-16 22:49 UTC (permalink / raw) To: emacs-devel chad <yandros <at> MIT.EDU> writes: > On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote: > > > As long as I know, header-line-format is buffer related and not > > frame related. Am I wrong ? > [...] > > For emacs in general, there is a lot of currently on-going > work/discussion around frame and window parameters, so it's probably a > bit too early to try to figure out such a mechanism for emacs24, but > that's just an artifact of development right now. OK I see your point. It seems to be a viable workaround except that : how can I disable the mode-line for this topmost window ? > > What is this Ted's `Emacs as a Desktop Environment' you are talking about ? > > [...] > >> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html I'm reading this thread right now. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 22:32 ` chad 2011-08-16 22:49 ` Jérémy Compostella @ 2011-08-17 7:49 ` Nicolas Martyanoff 2011-08-17 9:07 ` martin rudalics 2011-09-25 12:53 ` Ted Zlatanov 2 siblings, 1 reply; 43+ messages in thread From: Nicolas Martyanoff @ 2011-08-17 7:49 UTC (permalink / raw) To: chad; +Cc: Jérémy Compostella, emacs-devel chad <yandros@MIT.EDU> writes: > On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote: > >> As long as I know, header-line-format is buffer related and not frame >> related. Am I wrong ? > > It is buffer- and not frame-associated, yes. I was suggesting that > you consider building a way to have only the topmost window in a given > frame display the header-line. This might be tricky in general, but > since you're using a desktop system of your own creation, it seems > likely to be easier for you. But if you're using elscreen, the header-line is already used to display the list of screens, right ? >> What is this Ted's `Emacs as a Desktop Environment' you are talking >> about ? > > Some developers are pursing the idea of moving all of the `important' > parts of the desktop environment inside emacs, or at least inside > emacs' easy reach. This includes `desktop widgets' and an associated > `dock', that would be in specialized frames/windows. It's closer to > Thien-Thi Nguyen's idea of a `special messages buffer' than your > `global mode-line', but it could easily serve both purposes, and other > more gui-based uses as well. You can read the discussion (from > emacs-devel archives) starting here: > >>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html While this project is really interesting, it seems an order of magnitude more complex than adding an optional per-frame status window. I have no idea about the complexity about adding this feature; there's already a mini-buffer window which behaves in some aspects like a status bar (split-independant width, fixed position, no mode line), so I believe it would be possible to add a status bar just under (or above) the minibuffer without modifying a ton of code. Would someone know if it's possible to do it in emacs lisp, without modifying the C code ? It would make developement much easier. -- Nicolas Martyanoff http://codemore.org khaelin@gmail.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 7:49 ` Nicolas Martyanoff @ 2011-08-17 9:07 ` martin rudalics 2011-08-17 9:27 ` Juri Linkov 2011-08-17 11:38 ` Nicolas Martyanoff 0 siblings, 2 replies; 43+ messages in thread From: martin rudalics @ 2011-08-17 9:07 UTC (permalink / raw) To: Nicolas Martyanoff; +Cc: chad, Jérémy Compostella, emacs-devel > I have no idea about the complexity about adding this feature; there's > already a mini-buffer window which behaves in some aspects like a status > bar (split-independant width, fixed position, no mode line), so I > believe it would be possible to add a status bar just under (or above) > the minibuffer without modifying a ton of code. > > Would someone know if it's possible to do it in emacs lisp, without > modifying the C code ? It would make developement much easier. With current trunk you can try (experimentally) (display-buffer (get-buffer-create "foo") '((use-side-window bottom 0) (pop-up-window-set-height . 1))) How you update the contents of foo is obviously entirely left to you. martin ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 9:07 ` martin rudalics @ 2011-08-17 9:27 ` Juri Linkov 2011-08-17 9:44 ` martin rudalics 2011-08-17 11:38 ` Nicolas Martyanoff 1 sibling, 1 reply; 43+ messages in thread From: Juri Linkov @ 2011-08-17 9:27 UTC (permalink / raw) To: martin rudalics Cc: Nicolas Martyanoff, chad, Jérémy Compostella, emacs-devel > With current trunk you can try (experimentally) > > (display-buffer > (get-buffer-create "foo") > '((use-side-window bottom 0) (pop-up-window-set-height . 1))) I tried this code and get funny results: typing `C-x C-b' displays the *Buffer List* buffer in that small 1-line window :) So this window should be marked as dedicated. A more compact specification to do that could look like: (display-buffer "*global-mode-line*" '(minibuffer . above) (dedicated . t) (height . 1)) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 9:27 ` Juri Linkov @ 2011-08-17 9:44 ` martin rudalics 2011-08-17 11:41 ` Jérémy Compostella 0 siblings, 1 reply; 43+ messages in thread From: martin rudalics @ 2011-08-17 9:44 UTC (permalink / raw) To: Juri Linkov Cc: Nicolas Martyanoff, chad, Jérémy Compostella, emacs-devel > I tried this code and get funny results: typing `C-x C-b' displays > the *Buffer List* buffer in that small 1-line window :) > > So this window should be marked as dedicated. A more compact specification > to do that could look like: > > (display-buffer "*global-mode-line*" > '(minibuffer . above) (dedicated . t) (height . 1)) Frames don't necessarily have a minibuffer. So currently this would be done as (display-buffer (get-buffer-create "*global-mode-line*") '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1))) martin ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 9:44 ` martin rudalics @ 2011-08-17 11:41 ` Jérémy Compostella 2011-08-17 14:05 ` Stefan Monnier 0 siblings, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-08-17 11:41 UTC (permalink / raw) To: emacs-devel martin rudalics <rudalics <at> gmx.at> writes: > > > I tried this code and get funny results: typing `C-x C-b' displays > > the *Buffer List* buffer in that small 1-line window :) > > > > So this window should be marked as dedicated. A more compact specification > > to do that could look like: > > > > (display-buffer "*global-mode-line*" > > '(minibuffer . above) (dedicated . t) (height . 1)) > > Frames don't necessarily have a minibuffer. So currently this would be > done as > > (display-buffer > (get-buffer-create "*global-mode-line*") > '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1))) > I don't have a good Internet connexion on my vacation site so I can't get the emacs repository and I can't test it right now. Could you explain what is the result ? Anyway, I was thinking that we could maybe use the echo area to provide globals information like date/time or unread mail count. These information should not appear in the *Messages* buffer of course. What is your opinion ? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 11:41 ` Jérémy Compostella @ 2011-08-17 14:05 ` Stefan Monnier 2011-08-17 15:38 ` Jérémy Compostella 0 siblings, 1 reply; 43+ messages in thread From: Stefan Monnier @ 2011-08-17 14:05 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel > Anyway, I was thinking that we could maybe use the echo area to > provide globals information like date/time or unread mail count. And I already explained how to do that in my earlier email in this thread. Stefan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 14:05 ` Stefan Monnier @ 2011-08-17 15:38 ` Jérémy Compostella 0 siblings, 0 replies; 43+ messages in thread From: Jérémy Compostella @ 2011-08-17 15:38 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier <at> iro.umontreal.ca> writes: > > > Anyway, I was thinking that we could maybe use the echo area to > > provide globals information like date/time or unread mail count. > > And I already explained how to do that in my earlier email in > this thread. Yes. But first I wasn't really agree with this solution. Indeed I was more thinking about a dedicated/specialized new bar and I confess I was a little bit too rigid about others solutions. But one night after, I think your solution is the best one among all the proposals in this thread to solve this issue because it also solves the useless echo area issue and as I use Emacs as my desktop environment I do like optimized space usage (I disable scrollbar, menubar, window decoration, ...). However, I don't have a reliable Internet access right now and I have to wait Saturday to work on this solution. I will work on a package to format text like you suggested. Thanks for your help, Jeremy ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 9:07 ` martin rudalics 2011-08-17 9:27 ` Juri Linkov @ 2011-08-17 11:38 ` Nicolas Martyanoff 2011-08-20 13:20 ` Jérémy Compostella 1 sibling, 1 reply; 43+ messages in thread From: Nicolas Martyanoff @ 2011-08-17 11:38 UTC (permalink / raw) To: martin rudalics; +Cc: chad, Jérémy Compostella, emacs-devel martin rudalics <rudalics@gmx.at> writes: >> I have no idea about the complexity about adding this feature; there's >> already a mini-buffer window which behaves in some aspects like a status >> bar (split-independant width, fixed position, no mode line), so I >> believe it would be possible to add a status bar just under (or above) >> the minibuffer without modifying a ton of code. >> >> Would someone know if it's possible to do it in emacs lisp, without >> modifying the C code ? It would make developement much easier. > > With current trunk you can try (experimentally) > > (display-buffer > (get-buffer-create "foo") > '((use-side-window bottom 0) (pop-up-window-set-height . 1))) > > How you update the contents of foo is obviously entirely left to you. I played a bit using your code and got encouraging results; I'll see what I can do in the next days, and post on emacs-devel if I make something useful. Thank you for helping! Regards, -- Nicolas Martyanoff http://codemore.org khaelin@gmail.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 11:38 ` Nicolas Martyanoff @ 2011-08-20 13:20 ` Jérémy Compostella 2011-08-20 14:32 ` Óscar Fuentes 2011-08-20 16:01 ` martin rudalics 0 siblings, 2 replies; 43+ messages in thread From: Jérémy Compostella @ 2011-08-20 13:20 UTC (permalink / raw) To: emacs-devel; +Cc: Nicolas Martyanoff Nicolas Martyanoff <khaelin@gmail.com> writes: > martin rudalics <rudalics@gmx.at> writes: > >>> I have no idea about the complexity about adding this feature; there's >>> already a mini-buffer window which behaves in some aspects like a status >>> bar (split-independant width, fixed position, no mode line), so I >>> believe it would be possible to add a status bar just under (or above) >>> the minibuffer without modifying a ton of code. >>> >>> Would someone know if it's possible to do it in emacs lisp, without >>> modifying the C code ? It would make developement much easier. >> >> With current trunk you can try (experimentally) >> >> (display-buffer >> (get-buffer-create "foo") >> '((use-side-window bottom 0) (pop-up-window-set-height . 1))) >> >> How you update the contents of foo is obviously entirely left to you. > > I played a bit using your code and got encouraging results; I'll see > what I can do in the next days, and post on emacs-devel if I make > something useful. > I made some tries on my side. The above three lines of code provides an interesting result. However, I have one important issue : when using the minibuffer with more than one line, the "foo" buffer size is increased and never come back to its original one line size. Do you get interesting result on your side ? Jérémy ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-20 13:20 ` Jérémy Compostella @ 2011-08-20 14:32 ` Óscar Fuentes 2011-08-20 16:02 ` martin rudalics 2011-08-20 16:01 ` martin rudalics 1 sibling, 1 reply; 43+ messages in thread From: Óscar Fuentes @ 2011-08-20 14:32 UTC (permalink / raw) To: emacs-devel Jérémy Compostella <jeremy.compostella@gmail.com> writes: >>> With current trunk you can try (experimentally) >>> >>> (display-buffer >>> (get-buffer-create "foo") >>> '((use-side-window bottom 0) (pop-up-window-set-height . 1))) >>> >>> How you update the contents of foo is obviously entirely left to you. >> >> I played a bit using your code and got encouraging results; I'll see >> what I can do in the next days, and post on emacs-devel if I make >> something useful. >> > I made some tries on my side. The above three lines of code provides an > interesting result. However, I have one important issue : when using the > minibuffer with more than one line, the "foo" buffer size is increased > and never come back to its original one line size. > > Do you get interesting result on your side ? My "interesting" result is that eventually the `foo' buffer ends being displayed on a regular window covering half the screen with its usual modeline. That window wont go away easily (C-x 1 while the other window is active has no effect). I'm using a 1-month old Emacs, so maybe the above is due to bugs already fixed. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-20 14:32 ` Óscar Fuentes @ 2011-08-20 16:02 ` martin rudalics 2011-08-20 16:42 ` Óscar Fuentes 0 siblings, 1 reply; 43+ messages in thread From: martin rudalics @ 2011-08-20 16:02 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > My "interesting" result is that eventually the `foo' buffer ends being What does "eventually" mean? > displayed on a regular window covering half the screen with its usual > modeline. That window wont go away easily (C-x 1 while the other window > is active has no effect). That's part of the idea. C-x 1 should not delete such windows and should not make such a window the only one on its frame. martin ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-20 16:02 ` martin rudalics @ 2011-08-20 16:42 ` Óscar Fuentes 2011-08-21 8:45 ` martin rudalics 0 siblings, 1 reply; 43+ messages in thread From: Óscar Fuentes @ 2011-08-20 16:42 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel martin rudalics <rudalics@gmx.at> writes: >> My "interesting" result is that eventually the `foo' buffer ends being > > What does "eventually" mean? This is the exact recipe: emacs -Q Start by evaluating this in *scratch* (display-buffer (get-buffer-create "foo") '((use-side-window bottom 0) (pop-up-window-set-height . 1))) Now do a C-h f <some-function-name> INTRO The frame is splitted into two windows, one for *scratch* and another for *Help*, "foo" is gone, C-x 1 does not work from *scratch*, C-x 1 from the *Help* buffer reports byte-code: Cannot make side window the only window >> displayed on a regular window covering half the screen with its usual >> modeline. That window wont go away easily (C-x 1 while the other window >> is active has no effect). > > That's part of the idea. C-x 1 should not delete such windows and > should not make such a window the only one on its frame. It seems that Emacs reuses that window for displaying other buffers (*Help*, in the recipe described above) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-20 16:42 ` Óscar Fuentes @ 2011-08-21 8:45 ` martin rudalics 0 siblings, 0 replies; 43+ messages in thread From: martin rudalics @ 2011-08-21 8:45 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > Start by evaluating this in *scratch* > > (display-buffer > (get-buffer-create "foo") > '((use-side-window bottom 0) (pop-up-window-set-height . 1))) This gets you two windows, one displaying *scratch* and the other one displaying foo. > Now do a C-h f <some-function-name> INTRO > > The frame is splitted into two windows, one for *scratch* and another > for *Help*, "foo" is gone, Not really. The window of foo is reused for *Help*. > C-x 1 does not work from *scratch*, C-x 1 > from the *Help* buffer reports > > byte-code: Cannot make side window the only window C-x 0 from *Help* should have worked. Anyway, this behavior was reported by Juri Linkov immediately after my initial proposal and the remedy I suggested was to use (display-buffer (get-buffer-create "*global-mode-line*") '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1))) In addition you probably want to do (setq window-size-fixed 'height) in *global-mode-line* to assure that the window doesn't get resized. >> That's part of the idea. C-x 1 should not delete such windows and >> should not make such a window the only one on its frame. > > It seems that Emacs reuses that window for displaying other buffers > (*Help*, in the recipe described above) Should not happen any more with present trunk. martin ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-20 13:20 ` Jérémy Compostella 2011-08-20 14:32 ` Óscar Fuentes @ 2011-08-20 16:01 ` martin rudalics 1 sibling, 0 replies; 43+ messages in thread From: martin rudalics @ 2011-08-20 16:01 UTC (permalink / raw) To: Jérémy Compostella; +Cc: Nicolas Martyanoff, emacs-devel > I made some tries on my side. The above three lines of code provides an > interesting result. However, I have one important issue : when using the > minibuffer with more than one line, the "foo" buffer size is increased > and never come back to its original one line size. Basically, this problem can be resolved by making the window fixed-height which would be needed anyway, for example, when resizing the frame. But the behavior you observe might hint at a more fundamental problem with minibuffer resizing. Can you produce it with (split-window nil -1) for example? Here the window goes back to a height of one when the echo area is temporarily enlarged and goes back to one line. martin ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 22:32 ` chad 2011-08-16 22:49 ` Jérémy Compostella 2011-08-17 7:49 ` Nicolas Martyanoff @ 2011-09-25 12:53 ` Ted Zlatanov 2 siblings, 0 replies; 43+ messages in thread From: Ted Zlatanov @ 2011-09-25 12:53 UTC (permalink / raw) To: emacs-devel On Tue, 16 Aug 2011 15:32:47 -0700 chad <yandros@MIT.EDU> wrote: c> On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote: >> What is this Ted's `Emacs as a Desktop Environment' you are talking about ? c> Some developers are pursing the idea of moving all of the `important' parts c> of the desktop environment inside emacs, or at least inside emacs' easy c> reach. This includes `desktop widgets' and an associated `dock', that would c> be in specialized frames/windows. It's closer to Thien-Thi Nguyen's idea c> of a `special messages buffer' than your `global mode-line', but it could easily c> serve both purposes, and other more gui-based uses as well. You can read c> the discussion (from emacs-devel archives) starting here: >>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html For me it was a reaction to the ridiculous GUIs in Unity and GNOME 3, and I feel it's important to have a lightweight Emacs-only alternative. See my post in this thread with my current emacs-panel.el for my current status; I have much to do and any help is appreciated. It will be on ELPA eventually. emacs-panel.el would definitely be a good place for global information. In fact one example in the comments shows such a global panel. Thanks Ted ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 17:42 ` Drew Adams 2011-08-16 19:23 ` Jérémy Compostella @ 2011-08-16 20:00 ` Thien-Thi Nguyen 1 sibling, 0 replies; 43+ messages in thread From: Thien-Thi Nguyen @ 2011-08-16 20:00 UTC (permalink / raw) To: emacs-devel () "Drew Adams" <drew.adams@oracle.com> () Tue, 16 Aug 2011 10:42:41 -0700 Essentially, what's requested is some stable place to post (and leave posted) a bit of general info - info that is not specific to any buffer or window or frame... Perhaps ‘message’ could be extended to recognize a distinguished text property and arrange for that text to be placed in a *State of the Emacs* buffer (perhaps indexed/formatted/prettified in some way by that property's value), in addition to being added to *Messages*. Something like: (defun message/stateful (category fmt &rest args) (message "%s" (propertize (apply 'format fmt args) 'message/stateful category))) (defun note-stateful (category text) (with-current-buffer "*State of the Emacs*" (goto-char (GOOD-PLACE-FOR category text)) (apply 'delete-region (REGION-OF-OLD category)) (insert (APPROPRIATELY-DECORATED category text)))) where ‘note-stateful’ is called by ‘Fmessage’. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 16:40 ` Drew Adams 2011-08-16 17:04 ` Óscar Fuentes @ 2011-08-16 17:31 ` Stefan Monnier 2011-08-17 20:12 ` Jérémy Compostella ` (2 more replies) 1 sibling, 3 replies; 43+ messages in thread From: Stefan Monnier @ 2011-08-16 17:31 UTC (permalink / raw) To: Drew Adams; +Cc: 'Óscar Fuentes', emacs-devel > And we already have ways of posting text to the echo area (same space > as minibuffer) when the minibuffer is inactive: `message'. > That messages get replaced by later messages and by minibuffer input > is just a further demonstration that using the minibuffer/echo area > for this global info would be a bad idea. I tend to agree, tho it is also true that the echo area tends to be empty most of the time, so it is tempting to try and use it to display "permanent global non-urgent" info. I probably wouldn't want that by default, but it would be good for Emacs to make such a thing possible/easy. Emacs-24 has introduced the minibuffer-inactive-mode which lets you setup key-bindings for this "empty" inactive thingy, but it has lots of quirks (e.g. mouse event bindings seem to work well, but key event bindings only work for minibuffer-only frames). The inactive/empty echo area is actually displaying a buffer (the buffer named " *Minibuf-0*", IIUC), so technically it shouldn't be too difficult to create a package that inserts useful stuff in that buffer so they get displayed in the echo area when nothing else is shown there. > a. In a standalone minibuffer frame (if it exists), in its own > dedicated space within that frame (e.g. 1 line, 2 lines? extendable?), > perhaps above the minibuffer/echo area. Shouldn't be too hard: create a normal (i.e. with minibuffer, and not minibuffer-only) frame of the appropriate size, make it display a special buffer whose mode-line-format is set to nil and whose content shows whatever you want to see there. > b. Standalone, in its own frame. Same thing, but without the minibuffer. Overall, it sounds like it shouldn't be too hard to make up a little package that fills a buffer with useful global info (time/battery/mail/younameit) and then lets you choose where you want to display it (separate frame, inactive minibuffer, ...). Stefan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 17:31 ` Stefan Monnier @ 2011-08-17 20:12 ` Jérémy Compostella 2011-08-18 0:24 ` chad 2011-08-21 15:50 ` Jérémy Compostella 2011-09-25 12:50 ` Ted Zlatanov 2 siblings, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-08-17 20:12 UTC (permalink / raw) To: emacs-devel > [...] > The inactive/empty echo area is actually displaying a buffer (the buffer > named " *Minibuf-0*", IIUC), so technically it shouldn't be too > difficult to create a package that inserts useful stuff in that buffer > so they get displayed in the echo area when nothing else is shown there. I finally downloaded the Emacs git repository and I do notfind any reference to the *Minibuf-0* buffer you are talking about. Could help me ? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-17 20:12 ` Jérémy Compostella @ 2011-08-18 0:24 ` chad 0 siblings, 0 replies; 43+ messages in thread From: chad @ 2011-08-18 0:24 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 566 bytes --] On Aug 17, 2011, at 1:12 PM, Jérémy Compostella wrote: > I finally downloaded the Emacs git repository and I do notfind any reference > to the *Minibuf-0* buffer you are talking about. Could help me ? FYI, there are a couple emacs git mirrors, but the actual repository is held in bazaar, not git, and the git mirrors seem to lag anywhere between several hours and several weeks behind the actual development sources. You can get more info on the development sources by visiting: http://savannah.gnu.org/projects/emacs Hope that helps, *Chad [-- Attachment #2: Type: text/html, Size: 984 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 17:31 ` Stefan Monnier 2011-08-17 20:12 ` Jérémy Compostella @ 2011-08-21 15:50 ` Jérémy Compostella [not found] ` <jwvobziezor.fsf-monnier+emacs@gnu.org> 2011-09-25 12:50 ` Ted Zlatanov 2 siblings, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-08-21 15:50 UTC (permalink / raw) To: emacs-devel; +Cc: Stefan Monnier Stefan, and others, I made some tries with the " *Minibuffer-0*" buffer and I got some very encouraging results. Indeed, I am now able to display information like date/time, current activity or my jabber status in a fashion I like :) I have tried this with Emacs 23.2.1 and the Emacs trunk and it works the same way. For example, the following line of code will display the date and time when the echo area is unused: (defun display-status () (interactive) (with-current-buffer " *Minibuf-0*" (delete-region (point-min) (point-max)) (insert (format-time-string "%Hh%M %d/%m/%Y" (current-time))) (put-text-property (point-min) (point-max) 'face 'bold))) (run-at-time t 60 'display-status) My implementation do more than that but is not generic enough to be published now. 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 ? Thanks for helping me, Jérémy -- Sent from my Emacs ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <jwvobziezor.fsf-monnier+emacs@gnu.org>]
* Re: Global bar to display global information [not found] ` <jwvobziezor.fsf-monnier+emacs@gnu.org> @ 2011-12-30 13:21 ` Jérémy Compostella 2011-12-31 13:13 ` Jérémy Compostella ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Jérémy Compostella @ 2011-12-30 13:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1841 bytes --] 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca> > > 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 ? > > 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). > > 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érémy -- One Emacs to rule them all [-- Attachment #1.2: Type: text/html, Size: 2371 bytes --] [-- Attachment #2: 0001-echo-area-Remove-unnecessary-clearing-and-get-defaul.patch --] [-- Type: text/x-patch, Size: 2884 bytes --] From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001 From: Jeremy Compostella <jeremy.compostella@gmail.com> Date: Fri, 30 Dec 2011 14:01:13 +0100 Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer 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 <jeremy.compostella@gmail.com> --- 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); + } } 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; + /* Non-zero means redisplay has to redisplay the miniwindow */ + int update_miniwindow_p = 0; + TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p)); /* 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 = echo_area_display (0); + + if (message_cleared_p) + update_miniwindow_p = 1; + must_finish = 1; /* 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 = FRAME_MINIBUF_WINDOW (sf); struct frame *mini_frame; displayed_buffer = 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); /* Compare desired and current matrices, perform output. */ -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-12-30 13:21 ` Jérémy Compostella @ 2011-12-31 13:13 ` Jérémy Compostella 2012-01-01 22:11 ` Stefan Monnier 2012-04-24 13:06 ` Stefan Monnier 2012-05-07 16:10 ` Stefan Monnier 2 siblings, 1 reply; 43+ messages in thread From: Jérémy Compostella @ 2011-12-31 13:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2950 bytes --] Stefan, all, I work with this patch for two days now and it works perfectly fine. The redisplay works fine without any extras rendering operation (I instrumented a little bit to check that point). I will be very grateful if someone could try it, review it and tell me if something is wrong with it. With the patch applied and the following : (with-current-buffer (get-buffer-create " *Minibuf-0*") (insert "Information displayed in echo area :)")) you should see the "Information displayed in echo area :)" instead of the empty usual message. I'm currently working on a package which displays some more usefull information like the date, the battery status, the jabber status, the mail status and anything you may want in the echo area through the " *Minibuf-0*" buffer. Thank you and Happy New Year 2012 ! Jérémy 2011/12/30 Jérémy Compostella <jeremy.compostella@gmail.com> > 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca> > >> > 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 ? >> >> 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). >> >> > 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érémy > > -- > One Emacs to rule them all > -- « Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter » - Edsger Dijkstra [-- Attachment #2: Type: text/html, Size: 3897 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-12-31 13:13 ` Jérémy Compostella @ 2012-01-01 22:11 ` Stefan Monnier 0 siblings, 0 replies; 43+ messages in thread From: Stefan Monnier @ 2012-01-01 22:11 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel > I work with this patch for two days now and it works perfectly fine. > The redisplay works fine without any extras rendering operation > (I instrumented a little bit to check that point). Thank you very much for this contribution. I probably won't have time to review this before we open up the trunk for non-bugfix patches, but it looks very promising. Stefan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-12-30 13:21 ` Jérémy Compostella 2011-12-31 13:13 ` Jérémy Compostella @ 2012-04-24 13:06 ` Stefan Monnier 2012-04-26 18:12 ` Jérémy Compostella 2012-05-07 16:10 ` Stefan Monnier 2 siblings, 1 reply; 43+ messages in thread From: Stefan Monnier @ 2012-04-24 13:06 UTC (permalink / raw) To: emacs-devel; +Cc: Jérémy Compostella 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érémy" == Jérémy Compostella <jeremy.compostella@gmail.com> writes: > 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca> >> > 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 ? >> >> 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). >> >> > 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érémy > -- > One Emacs to rule them all > From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella <jeremy.compostella@gmail.com> > Date: Fri, 30 Dec 2011 14:01:13 +0100 > Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer 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 <jeremy.compostella@gmail.com> > --- > 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); > + } > } > 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; > + /* Non-zero means redisplay has to redisplay the miniwindow */ > + int update_miniwindow_p = 0; > + > TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p)); > /* 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 = echo_area_display (0); > + > + if (message_cleared_p) > + update_miniwindow_p = 1; > + > must_finish = 1; > /* 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 = FRAME_MINIBUF_WINDOW (sf); > struct frame *mini_frame; > displayed_buffer = 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); > /* Compare desired and current matrices, perform output. */ > -- > 1.7.2.5 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2012-04-24 13:06 ` Stefan Monnier @ 2012-04-26 18:12 ` Jérémy Compostella 0 siblings, 0 replies; 43+ messages in thread From: Jérémy Compostella @ 2012-04-26 18:12 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel All, I would be very thankful too is someone could look at it. It's a very simple patch that I use for more than 6 months now and provide me a way to use the echo area as a global information area. Thanks a lot, Jérémy 2012/4/24 Stefan Monnier <monnier@iro.umontreal.ca>: > 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érémy" == Jérémy Compostella <jeremy.compostella@gmail.com> writes: > >> 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca> >>> > 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 ? >>> >>> 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). >>> >>> >> 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érémy > >> -- >> One Emacs to rule them all >> From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001 >> From: Jeremy Compostella <jeremy.compostella@gmail.com> >> Date: Fri, 30 Dec 2011 14:01:13 +0100 >> Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer 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 <jeremy.compostella@gmail.com> >> --- >> 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); >> + } >> } > >> 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; > >> + /* Non-zero means redisplay has to redisplay the miniwindow */ >> + int update_miniwindow_p = 0; >> + >> TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p)); > >> /* 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 = echo_area_display (0); >> + >> + if (message_cleared_p) >> + update_miniwindow_p = 1; >> + >> must_finish = 1; > >> /* 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 = FRAME_MINIBUF_WINDOW (sf); >> struct frame *mini_frame; > >> displayed_buffer = 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); > >> /* Compare desired and current matrices, perform output. */ > >> -- >> 1.7.2.5 > > -- « Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter » - Edsger Dijkstra ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-12-30 13:21 ` Jérémy Compostella 2011-12-31 13:13 ` Jérémy Compostella 2012-04-24 13:06 ` Stefan Monnier @ 2012-05-07 16:10 ` Stefan Monnier 2 siblings, 0 replies; 43+ messages in thread From: Stefan Monnier @ 2012-05-07 16:10 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel Thank you, Jérémy, I installed your patch in the trunk, Stefan > 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érémy > -- > One Emacs to rule them all ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 17:31 ` Stefan Monnier 2011-08-17 20:12 ` Jérémy Compostella 2011-08-21 15:50 ` Jérémy Compostella @ 2011-09-25 12:50 ` Ted Zlatanov 2 siblings, 0 replies; 43+ messages in thread From: Ted Zlatanov @ 2011-09-25 12:50 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1209 bytes --] On Tue, 16 Aug 2011 13:31:13 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: SM> Overall, it sounds like it shouldn't be too hard to make up a little SM> package that fills a buffer with useful global info SM> (time/battery/mail/younameit) and then lets you choose where you want to SM> display it (separate frame, inactive minibuffer, ...). Don't forget the progress bar Michael Albinus and I were pushing, to indicate global "busy" status. That would fit nicely in such a global "status bar." Emacs should really support global progress indicators and I recall our discussion stalled. I am attaching an *early not really functional* version of my ideas in the global information direction, emacs-panel.el. I didn't get far with it this summer before other tasks took priority, but intend to keep working on it. It is specifically intended to function as an information panel, which I think is the goal of this thread. Note that it has some code to let the window manager treat the popups specially so they can be docked, which is essential IMHO. Any improvements, especially such that make it ELPA-ready, most welcome. As I said I intend to keep working on it as time allows. Thanks Ted [-- Attachment #2: emacs-panel.el --] [-- Type: application/emacs-lisp, Size: 9023 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 16:18 ` Óscar Fuentes 2011-08-16 16:40 ` Drew Adams @ 2011-08-16 17:42 ` joakim 1 sibling, 0 replies; 43+ messages in thread From: joakim @ 2011-08-16 17:42 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > "Drew Adams" <drew.adams@oracle.com> writes: > >> +1 > > +1 > > [snip] > >> This proposed feature is along the same lines. But this would not >> have as its goal to eliminate mode lines from individual windows. It >> would instead just free up some of that individual-window mode line >> space that might be used for global info (not specific to the given >> buffer/window). > > I'll appreacite such feature. > > Most of the time the minibuffer is an idle blank line at the bottom of > the frame. Using it for displaying some global info sounds quite > convenient. It could display the global info even while asking for > input, overwritting the area used by the info as necessary. > I think it is possible to do such things with Martins new window code. -- Joakim Verona ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 14:33 Global bar to display global information Jérémy Compostella 2011-08-16 15:29 ` Drew Adams @ 2011-08-16 17:44 ` chad 2011-08-20 18:29 ` Andreas Röhler 2 siblings, 0 replies; 43+ messages in thread From: chad @ 2011-08-16 17:44 UTC (permalink / raw) To: Jérémy Compostella; +Cc: emacs-devel Perhaps a header-line is what you want? C-h v header-line-format RET *Chad On Aug 16, 2011, at 7:33 AM, Jérémy Compostella wrote: > All, > > As many user, I use Emacs as my full desktop environment on several > system (mainly GNU/Linux and Windows at work). To be as independent as > possible, I use the mode-line to show information like current date and > time, jabber notifications, unread mail number, ... and I start Emacs in > full-screen. > > The problem is since I use several windows (in Emacs term), these > information are duplicated and are not always visible. Indeed, the > mode-line bar is split in the middle of the information it displays. > > I think it could be really great if Emacs would provide a global bar > based on the same mechanisms as the mode line but dedicated to this > kind of global information. > > What is your opinion ? Is this subject already discussed before ? > > Thanks, > > Jérémy > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Global bar to display global information 2011-08-16 14:33 Global bar to display global information Jérémy Compostella 2011-08-16 15:29 ` Drew Adams 2011-08-16 17:44 ` chad @ 2011-08-20 18:29 ` Andreas Röhler 2 siblings, 0 replies; 43+ messages in thread From: Andreas Röhler @ 2011-08-20 18:29 UTC (permalink / raw) To: Jérémy Compostella; +Cc: Drew Adams, Emacs developers Am 16.08.2011 16:33, schrieb Jérémy Compostella: > All, > > As many user, I use Emacs as my full desktop environment on several > system (mainly GNU/Linux and Windows at work). To be as independent as > possible, I use the mode-line to show information like current date and > time, jabber notifications, unread mail number, ... and I start Emacs in > full-screen. > > The problem is since I use several windows (in Emacs term), these > information are duplicated and are not always visible. Indeed, the > mode-line bar is split in the middle of the information it displays. > > I think it could be really great if Emacs would provide a global bar > based on the same mechanisms as the mode line but dedicated to this > kind of global information. > > What is your opinion ? Is this subject already discussed before ? > > Thanks, > > Jérémy > > > > Hi, what about implementing that using speedbar? Best regards, Andreas ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2012-05-07 16:10 UTC | newest] Thread overview: 43+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-08-16 14:33 Global bar to display global information Jérémy Compostella 2011-08-16 15:29 ` Drew Adams 2011-08-16 16:18 ` Óscar Fuentes 2011-08-16 16:40 ` Drew Adams 2011-08-16 17:04 ` Óscar Fuentes 2011-08-16 17:42 ` Drew Adams 2011-08-16 19:23 ` Jérémy Compostella 2011-08-16 19:46 ` chad 2011-08-16 19:48 ` chad 2011-09-25 12:42 ` Ted Zlatanov 2011-08-16 20:54 ` Jérémy Compostella 2011-08-16 22:32 ` chad 2011-08-16 22:49 ` Jérémy Compostella 2011-08-17 7:49 ` Nicolas Martyanoff 2011-08-17 9:07 ` martin rudalics 2011-08-17 9:27 ` Juri Linkov 2011-08-17 9:44 ` martin rudalics 2011-08-17 11:41 ` Jérémy Compostella 2011-08-17 14:05 ` Stefan Monnier 2011-08-17 15:38 ` Jérémy Compostella 2011-08-17 11:38 ` Nicolas Martyanoff 2011-08-20 13:20 ` Jérémy Compostella 2011-08-20 14:32 ` Óscar Fuentes 2011-08-20 16:02 ` martin rudalics 2011-08-20 16:42 ` Óscar Fuentes 2011-08-21 8:45 ` martin rudalics 2011-08-20 16:01 ` martin rudalics 2011-09-25 12:53 ` Ted Zlatanov 2011-08-16 20:00 ` Thien-Thi Nguyen 2011-08-16 17:31 ` Stefan Monnier 2011-08-17 20:12 ` Jérémy Compostella 2011-08-18 0:24 ` chad 2011-08-21 15:50 ` Jérémy Compostella [not found] ` <jwvobziezor.fsf-monnier+emacs@gnu.org> 2011-12-30 13:21 ` Jérémy Compostella 2011-12-31 13:13 ` Jérémy Compostella 2012-01-01 22:11 ` Stefan Monnier 2012-04-24 13:06 ` Stefan Monnier 2012-04-26 18:12 ` Jérémy Compostella 2012-05-07 16:10 ` Stefan Monnier 2011-09-25 12:50 ` Ted Zlatanov 2011-08-16 17:42 ` joakim 2011-08-16 17:44 ` chad 2011-08-20 18:29 ` Andreas Röhler
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.