* Re: Q on minibuffer-message [not found] <MEEKKIABFKKDFJMPIOEBIEJMCOAA.drew.adams@oracle.com> @ 2006-01-20 22:50 ` Lennart Borgman 2006-01-20 23:08 ` Drew Adams 2006-01-22 17:44 ` Richard M. Stallman 0 siblings, 2 replies; 10+ messages in thread From: Lennart Borgman @ 2006-01-20 22:50 UTC (permalink / raw) Cc: Help-Gnu-Emacs As far as I can see it is a bug, at least in CVS Emacs. `minibuffer-message' uses temp_echo_area_glyphs in minibuf.c and that function calls Fsit_for (make_number (2), Qnil, Qnil); which just sits for 2 seconds. BTW `minibuffer-message' puts the string at the end of the current buffer which is not necessarily the minibuffer. Is not that a bug too? --lennart Drew Adams wrote: > I have a command `foo' that calls `minibuffer-message' at various points. > > I want to call this function from another command, `bar', but I don't want > the `minibuffer-message' display to wait for two seconds - I even don't care > if it is displayed at all in this case. > > I could change the definition of command `foo', to pass it a flag to not > call `minibuffer-message' (or to call it only when the command is called > interactively), but I'd rather not have to resort to that. > > `minibuffer-message' displays its message for two seconds, unless an input > event is received during this time. My question is: How can I inhibit the > 2-second wait? Is there, for example, some way I can simulate an input > event? Or is there a simpler, cleaner way? > > In command `bar', just after calling `foo', I tried (sit-for 0), to no > avail. I tried adding a fake event (e.g. a character) to > `unread-command-events', to no avail. I tried binding > `minibuffer-message-timeout' (to nil and to 0), to no avail (it seemed to > have no effect). > > Anyone have a suggestion? > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Q on minibuffer-message 2006-01-20 22:50 ` Q on minibuffer-message Lennart Borgman @ 2006-01-20 23:08 ` Drew Adams 2006-01-22 17:44 ` Richard M. Stallman 1 sibling, 0 replies; 10+ messages in thread From: Drew Adams @ 2006-01-20 23:08 UTC (permalink / raw) As far as I can see it is a bug, at least in CVS Emacs. `minibuffer-message' uses temp_echo_area_glyphs in minibuf.c and that function calls Fsit_for (make_number (2), Qnil, Qnil); which just sits for 2 seconds. BTW `minibuffer-message' puts the string at the end of the current buffer which is not necessarily the minibuffer. Is not that a bug too? I don't know if those observations indicate bugs, and I'm not sure they're related to my question. I'd just like to know how to inhibit or cancel the 2-second delay. I don't understand this enough to know if it is the presence of bugs that prevents me from doing that. I'd like some input on what might work (modulo bugs). ---- Drew Adams wrote: > I have a command `foo' that calls `minibuffer-message' at various points. > > I want to call this function from another command, `bar', but I don't want > the `minibuffer-message' display to wait for two seconds - I even don't care > if it is displayed at all in this case. > > I could change the definition of command `foo', to pass it a flag to not > call `minibuffer-message' (or to call it only when the command is called > interactively), but I'd rather not have to resort to that. > > `minibuffer-message' displays its message for two seconds, unless an input > event is received during this time. My question is: How can I inhibit the > 2-second wait? Is there, for example, some way I can simulate an input > event? Or is there a simpler, cleaner way? > > In command `bar', just after calling `foo', I tried (sit-for 0), to no > avail. I tried adding a fake event (e.g. a character) to > `unread-command-events', to no avail. I tried binding > `minibuffer-message-timeout' (to nil and to 0), to no avail (it seemed to > have no effect). > > Anyone have a suggestion? > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Q on minibuffer-message 2006-01-20 22:50 ` Q on minibuffer-message Lennart Borgman 2006-01-20 23:08 ` Drew Adams @ 2006-01-22 17:44 ` Richard M. Stallman 2006-01-22 18:54 ` Drew Adams 1 sibling, 1 reply; 10+ messages in thread From: Richard M. Stallman @ 2006-01-22 17:44 UTC (permalink / raw) Cc: help-gnu-emacs, drew.adams, emacs-devel > I have a command `foo' that calls `minibuffer-message' at various points. > > I want to call this function from another command, `bar', but I don't want > the `minibuffer-message' display to wait for two seconds - I even don't care > if it is displayed at all in this case. It is not useful to display a minibuffer message and not wait to give the user a chance to see it. The operation must normally wait. Perhaps what you mean is that when foo is used from bar, you see no reason for foo's messages to appear at all. In that case, what I suggest is that you set up foo with an optional argument that is provided as t when it is called interactively. And foo should only display its messages when that argument is t. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Q on minibuffer-message 2006-01-22 17:44 ` Richard M. Stallman @ 2006-01-22 18:54 ` Drew Adams 2006-01-23 4:42 ` Eli Zaretskii 2006-01-24 16:46 ` Richard M. Stallman 0 siblings, 2 replies; 10+ messages in thread From: Drew Adams @ 2006-01-22 18:54 UTC (permalink / raw) > I have a command `foo' that calls `minibuffer-message' at > various points. > > I want to call this function from another command, `bar', > but I don't want the `minibuffer-message' display to wait > for two seconds - I even don't care > if it is displayed at all in this case. It is not useful to display a minibuffer message and not wait to give the user a chance to see it. The operation must normally wait. Perhaps what you mean is that when foo is used from bar, you see no reason for foo's messages to appear at all. Yes, that's what I mean. In that case, what I suggest is that you set up foo with an optional argument that is provided as t when it is called interactively. And foo should only display its messages when that argument is t. That's just what I wanted to avoid having to do. From my original message: I could change the definition of command `foo', to pass it a flag to not call `minibuffer-message' (or to call it only when the command is called interactively), but I'd rather not have to resort to that. `minibuffer-message' displays its message for two seconds, unless an input event is received during this time. My question is: How can I inhibit the 2-second wait? Is there, for example, some way I can simulate an input event? Or is there a simpler, cleaner way? In command `bar', just after calling `foo', I tried (sit-for 0), to no avail. I tried adding a fake event (e.g. a character) to `unread-command-events', to no avail. I tried binding `minibuffer-message-timeout' (to nil and to 0), to no avail (it seemed to have no effect). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Q on minibuffer-message 2006-01-22 18:54 ` Drew Adams @ 2006-01-23 4:42 ` Eli Zaretskii 2006-01-24 16:46 ` Richard M. Stallman 1 sibling, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2006-01-23 4:42 UTC (permalink / raw) Cc: help-gnu-emacs, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sun, 22 Jan 2006 10:54:35 -0800 > Cc: > > In that case, what I suggest is that you set up foo with an optional > argument that is provided as t when it is called interactively. And > foo should only display its messages when that argument is t. > > That's just what I wanted to avoid having to do. From my original message: > > I could change the definition of command `foo', to pass it a flag to not > call `minibuffer-message' (or to call it only when the command is called > interactively), but I'd rather not have to resort to that. This doesn't explain why you wanted to avoid such a solution. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Q on minibuffer-message 2006-01-22 18:54 ` Drew Adams 2006-01-23 4:42 ` Eli Zaretskii @ 2006-01-24 16:46 ` Richard M. Stallman 1 sibling, 0 replies; 10+ messages in thread From: Richard M. Stallman @ 2006-01-24 16:46 UTC (permalink / raw) Cc: help-gnu-emacs, emacs-devel In that case, what I suggest is that you set up foo with an optional argument that is provided as t when it is called interactively. And foo should only display its messages when that argument is t. That's just what I wanted to avoid having to do. That's the right method, so I'm not interested in helping people avoid it. ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <87irsbo7et.fsf@gmail.com>]
* RE: Q on minibuffer-message [not found] <87irsbo7et.fsf@gmail.com> @ 2006-01-23 17:19 ` Drew Adams 2006-01-23 23:23 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2006-01-23 17:19 UTC (permalink / raw) Drew> I could change the definition of command `foo', to pass it a flag to not call `minibuffer-message' (or to call it only when the command is called interactively), but I'd rather not have to resort to that. Eli> This doesn't explain why you wanted to avoid such a solution. In fact, I have always planned anyway to modify `foo' in this way, because my library needs to work also with Emacs 20, which has no `minibuffer-message-timeout'. When I said that I wished to avoid such modification, what I meant was that one should be able to avoid it. Ian> But why? The argument can be optional, meaning if it's not given it will default to nil. So there's no need to modify call sites in programs. The concern was not needing to modify functions that call `foo'. The concern was needing to modify `foo', the function that calls `minibuffer-message'. The point is that it would be useful to be able to inhibit the action of `minibuffer-message' from _without_, just as you can turn off logging of messages in buffer *Messages* from without. Imagine a scenario where you have no control over the definition of `foo'. You simply want to use it, but not hear its `minibuffer-message' noise. Binding `minibuffer-message-timeout' to 0 (or nil, or t, or whatever) should let you do that. That's all. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Q on minibuffer-message 2006-01-23 17:19 ` Drew Adams @ 2006-01-23 23:23 ` Eli Zaretskii 2006-01-24 0:10 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2006-01-23 23:23 UTC (permalink / raw) > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 23 Jan 2006 09:19:29 -0800 > Cc: > > The point is that it would be useful to be able to inhibit the action of > `minibuffer-message' from _without_, just as you can turn off logging of > messages in buffer *Messages* from without. I'm not sure Emacs should cater to such a concern: a function that calls `message' is clearly supposed to be invoked interactively, not silently. In other words, you are asking for a mechanism to subvert the intent of the author of the function which calls `message'. If a good reason presents itself to allow non-interactive invocation of the function, a better solution would be rewrite it so that its code is divided into two parts: one that is an internal non-interactive function, the other an interactive wrapper. Like find-file and its subroutines, for example, or save-buffer and its. > Imagine a scenario where you have no control over the definition of `foo'. > You simply want to use it, but not hear its `minibuffer-message' noise. > Binding `minibuffer-message-timeout' to 0 (or nil, or t, or whatever) should > let you do that. That's all. You have defadvice, which is an official way of committing such crimes of uncleanness. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Q on minibuffer-message 2006-01-23 23:23 ` Eli Zaretskii @ 2006-01-24 0:10 ` Drew Adams 2006-01-24 4:28 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2006-01-24 0:10 UTC (permalink / raw) > Imagine a scenario where you have no control over the > definition of `foo'. You simply want to use it, but not hear its > `minibuffer-message' noise. Binding `minibuffer-message-timeout' > to 0 (or nil, or t, or whatever) should let you do that. That's all. You have defadvice, which is an official way of committing such crimes of uncleanness. Someone gives you a command that has maybe 10 or 100 possible calls to `minibuffer-message' sprinkled throughout its execution tree. You're going to use `defadvice' to try to slice and dice away the message appearances? Or you're going to rewrite the command, so that it uses a non-interactive helper function or accepts a flag that controls message appearance or tests whether it was called interactively? The original author intended it only as an interactive command, but you see that you can use its functionality as is - you just want to inhibit its messages. In other words, you are asking for a mechanism to subvert the intent of the author of the function which calls `message'. Yes. It's far from atypical to reuse something in a way that was not foreseen by the original author. Probably most reuse fits that description. In any case, `minibuffer-message-timeout' apparently has no effect whatsoever currently: a 2-second delay is apparently hard-coded. When that is fixed, one can hope that a setting of 0 seconds will inhibit display. Some will then use 0 for that purpose; others will prefer more official ways of committing such crimes of uncleanness ;-). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Q on minibuffer-message 2006-01-24 0:10 ` Drew Adams @ 2006-01-24 4:28 ` Eli Zaretskii 0 siblings, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2006-01-24 4:28 UTC (permalink / raw) > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 23 Jan 2006 16:10:49 -0800 > Cc: > > Someone gives you a command that has maybe 10 or 100 possible calls to > `minibuffer-message' sprinkled throughout its execution tree. You're going > to use `defadvice' to try to slice and dice away the message appearances? Or > you're going to rewrite the command, so that it uses a non-interactive > helper function or accepts a flag that controls message appearance or tests > whether it was called interactively? > > The original author intended it only as an interactive command, but you see > that you can use its functionality as is - you just want to inhibit its > messages. Are we talking about a well-written, clean function? Or are we talking about something that shouldn't have seen the light of the day? I get the impression that I'm thinking mostly about the former, while you have the latter before your mind's eyes. If it's a badly written function, then yes, I'd rewrite it, or urge the author to do so. > In other words, you are asking for a mechanism to subvert the intent > of the author of the function which calls `message'. > > Yes. It's far from atypical to reuse something in a way that was not > foreseen by the original author. Probably most reuse fits that description. A well written code doesn't need to be subverted to be reused. > In any case, `minibuffer-message-timeout' apparently has no effect > whatsoever currently: a 2-second delay is apparently hard-coded. That's a different issue, with a different solution. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-01-24 16:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <MEEKKIABFKKDFJMPIOEBIEJMCOAA.drew.adams@oracle.com> 2006-01-20 22:50 ` Q on minibuffer-message Lennart Borgman 2006-01-20 23:08 ` Drew Adams 2006-01-22 17:44 ` Richard M. Stallman 2006-01-22 18:54 ` Drew Adams 2006-01-23 4:42 ` Eli Zaretskii 2006-01-24 16:46 ` Richard M. Stallman [not found] <87irsbo7et.fsf@gmail.com> 2006-01-23 17:19 ` Drew Adams 2006-01-23 23:23 ` Eli Zaretskii 2006-01-24 0:10 ` Drew Adams 2006-01-24 4:28 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).