messages to *Messages* without appearing in mini-buffer?

messages to *Messages* without appearing in mini-buffer?

[Eric S Fraga]

Hi,

what is the easiest way to output text to the *Messages* buffer, in
elisp, without having it appear in the echo (mini-buffer) area?  

thank you,
eric
-- 
Eric S Fraga with org 9.5 in Emacs 29.0.50 on Debian 11.1

Re: messages to *Messages* without appearing in mini-buffer?

[Gregory Heytings]

>
> what is the easiest way to output text to the *Messages* buffer, in 
> elisp, without having it appear in the echo (mini-buffer) area?
>

(defun message-quiet (format-string &rest args)
   "Like `message', but do not display the message at the bottom of the screen."
   (let ((set-message-function #'always))
     (apply #'message format-string args)))

Re: messages to *Messages* without appearing in mini-buffer?

[Eric S Fraga]

On Thursday, 11 Nov 2021 at 14:45, Gregory Heytings wrote:
> (defun message-quiet (format-string &rest args)
>   "Like `message', but do not display the message at the bottom of the screen."
>   (let ((set-message-function #'always))
>     (apply #'message format-string args)))

Excellent!  Many thanks.

I just needed the (set-message-function #'always) added to an existing
(let ...) and everything is working very nicely.

-- 
Eric S Fraga with org 9.5 in Emacs 29.0.50 on Debian 11.1

RE: [External] : messages to *Messages* without appearing in mini-buffer?

[Drew Adams]

> easiest way to output text to the *Messages* buffer...
> without having it appear in the echo ... area?

(let ((inhibit-message  t))
  (message "Msg only to be logged in *Messages*"))

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Eric S Fraga]

On Thursday, 11 Nov 2021 at 17:01, Drew Adams wrote:
> (let ((inhibit-message  t))
>   (message "Msg only to be logged in *Messages*"))

Thank you!  Even simpler than the other solution.

And this one I *should* have been able to find by myself.  Oh well.

-- 
Eric S Fraga with org 9.5 in Emacs 29.0.50 on Debian 11.1

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> easiest way to output text to the *Messages* buffer...
>> without having it appear in the echo ... area?
>
> (let ((inhibit-message  t))
>   (message "Msg only to be logged in *Messages*"))

Doesn't work for me?

I see it.

Dont know if message displays it or if it is displayed because
it is returned.

But then I don't see either of these. Both are logged.

(let ((inhibit-message t))
  (message "inhib")
  1)

(let ((inhibit-message nil))
  (message "nil so")
  2)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Gregory Heytings]

>
> Dont know if message displays it or if it is displayed because it is 
> returned.
>

It is displayed with double quotes around the string, which means that it 
is displayed because it is returned.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

>> Don't know if message displays it or if it is displayed
>> because it is returned.
>
> It is displayed with double quotes around the string, which
> means that it is displayed because it is returned.

Right, thanks!

But ... if you are annoyed with

  message
  
I think you will be annoyed with

  "message"

as well!

If you don't want to see anything, it should look like this:

(new-log-entry
  "Stardate 41153.7. We have been examining ways to save
  energy and reduce stress among crew members in engineering
  by shutting up the computer's message system. So far, our
  efforts have involved fiddling with variables instead of
  having a robust function to do silent logging. But today,
  crewman Berg seems to be onto something ..."
  *Messages*)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> But ... if you are annoyed with
>
>   message
>   
> I think you will be annoyed with
>
>   "message"
>
> as well!

Some stuff behaves different than in your tests (the majority,
actually).  Try this:

#+begin_src emacs-lisp
(global-set-key
 [f1]
 (defun test ()
   (interactive)
   (let (;; (inhibit-message t)
         )
     (message "Something"))))
#+end_src

Now try f1 with and without the `inhibit-message' binding.

Invoking commands doesn't print a return value.  And invoking commands
is what you do all the time.

Michael.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

> Invoking commands doesn't print a return value. And invoking
> commands is what you do all the time.

Still ... IMO a dedicated function is better than setting
variable back and forth if you plan to use this a lot.

Here is what you can do to have a log if you will ...

But there is a bug somewhere. Rarely but it happens there is
some complain about recentering. Don't know what that is or if
that is related to some other code ...

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   http://user.it.uu.se/~embe8573/emacs-init/todo-did.el
;;;   https://dataswamp.org/~incal/emacs-init/todo-did.el

(defun todo-get-buffer ()
  (let*((todo-env-var "TODO_FILE")
        (todo-file    (getenv todo-env-var))
        (todo-buffer  (if todo-file
                          (find-file-noselect todo-file t)
                        (error "Set the variable %s first" todo-env-var) )))
  todo-buffer) )

(defun todo-sort-and-save ()
  (sort-lines nil (point-min) (point-max)) ; not REVERSE
  (whitespace-cleanup)
  (save-buffer) )

(defun todo-insert-entry (entry buffer)
  (with-current-buffer buffer
    (goto-char (point-max))
    (insert "\n" entry)
    (todo-sort-and-save) ))

(defun todo (what)
  (interactive "sdo what: ")
  (todo-insert-entry what (todo-get-buffer)) )

(defun todo-show-file ()
  (interactive)
  (let ((todo-buffer (todo-get-buffer)))
    (with-current-buffer todo-buffer
      (when (buffer-modified-p todo-buffer)
        (todo-sort-and-save) )
      (switch-to-buffer todo-buffer) )))

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Still ... IMO a dedicated function is better than setting variable
> back and forth if you plan to use this a lot.

You typically bind the variable, and since it's special, it can silence
calls to `message' in code you call that calls `message'.

Michael.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

>> Still ... IMO a dedicated function is better than setting
>> variable back and forth if you plan to use this a lot.
>
> You typically bind the variable, and since it's special, it
> can silence calls to `message' in code you call that calls
> `message'.

Best:

  (do-some-thing)

Second best:

  (do-some-thing this-way)

Not 3rd place:

  (let ((control-behavior with-some-value))
    (in-function) )

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Best:
>
>   (do-some-thing)
>
> Second best:
>
>   (do-some-thing this-way)
>
> Not 3rd place:
>
>   (let ((control-behavior with-some-value))
>     (in-function) )

Ok, if you have the time to rewrite significant parts of Emacs before
every single command call ...but most people don't.  That's why
programmers invented variables.

Michael.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Ok, if you have the time to rewrite significant parts of Emacs before
> every single command call ...but most people don't.  That's why
> programmers invented variables.

I'm sorry about the irony.

Special variables exist to make it possible that one and the same code
behaves differently, depending on the context of the caller.

With `inhibit-message' you can shut up code that normally everybody
wants to display messages, but in some special use case, it would be
distracting or irrelevant.  Please have a look at the examples in the
sources and see why a function wouldn't help in a lot of these cases.

The second point is that calling `message' only for logging is quite
rare, so we only have the variable.

Michael.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

> The second point is that calling `message' only for logging
> is quite rare, so we only have the variable.

But one could have a general function for that and provide the
*Message* buffer as argument.

You don't agree formal parameters/arguments are
better/safer/more convenient than
global/dynamic/special variables?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

> Ok, if you have the time to rewrite significant parts of
> Emacs before every single command call ...but most people
> don't. That's why programmers invented variables.

Global variables should be avoided. It isn't so difficult to
do. I have written 140 files of Elisp. They are not Elisp
files in Emacs sense but much shorter, but still. (Well,
actually that is a good things! Emacs Elisp files are too
long. But it sounds more than it is is what I'm saying.)
Anyway I've only 6 `defvar' in all of that!

These 6 in 140 are ...

Two are extra keywords, e.g.
  https://dataswamp.org/~incal/emacs-init/buffer-menu.el
  - actually I don't know if they are necessary there ... to
  be global/dynamic/special, I mean?

One is a map,
  https://dataswamp.org/~incal/emacs-init/caps-back.el
  - necessary?

And three are here
  https://dataswamp.org/~incal/emacs-init/mode-line.el
  - are they necessary?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Two are extra keywords, e.g.
>   https://dataswamp.org/~incal/emacs-init/buffer-menu.el
>   - actually I don't know if they are necessary there ... to
>   be global/dynamic/special, I mean?

This cannot be a closure, first the byte-compiler says the
variable it is unused, then its value is void. Not sure
why but it looks involved so probably doesn't work then ...

> One is a map,
>   https://dataswamp.org/~incal/emacs-init/caps-back.el
>   - necessary?

Maps were always done globally with `defvar' what I saw and
I don't know have an idea to do it otherwise ...

> And three are here
>   https://dataswamp.org/~incal/emacs-init/mode-line.el
>   - are they necessary?

Hm ... these three, I wonder what they are?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Global variables should be avoided.

Isn't it obvious that this is an example par excellence where a global
variable is justified?

Michael.

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

>> Global variables should be avoided.
>
> Isn't it obvious that this is an example par excellence
> where a global variable is justified?

No?

For the record, I'm not saying support for
global/dynamic/special should be removed ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : messages to *Messages* without appearing in mini-buffer?

[Drew Adams]

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

> Best:
>   (do-some-thing)
> Second best:
>   (do-some-thing this-way)
> Not 3rd place:
>   (let ((control-behavior with-some-value))
>     (in-function) )

That's 3rd-grade "knowledge".  (Only a rough
first approximation, if you prefer.)

There's NO such "best", though convincing the
Lexical Police of this is hardly worth trying. ;-)
"Best" depends on the purpose/use.

[The same applies to side effects and state.
And to `quote' (which by itself destroys
referential transparency).  And to applicative
order evaluation.  And to...  All such "dirty",
more-difficult-to-prove/manage/manipulate, more
complicated things have their uses/advantages.]

There's are reasons that Common Lisp and Elisp
provide not only lexical binding but _also_
dynamic binding.  And the reasons are not just
hysterical raisins.  And Elisp has its own
particular reasons, as it's a Lisp for an editor
(and more).


https://www.gnu.org/software/emacs/emacs-paper.html#SEC17

"It is not necessary for dynamic scope to be the
only scope rule provided, just useful for it to
be available..."


https://www.gnu.org/software/emacs/emacs-paper.html#SEC18

"Some language designers believe that dynamic
binding should be avoided, and explicit argument
passing should be used instead..."


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14958 bytes --]

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> Best:
>>   (do-some-thing)
>> Second best:
>>   (do-some-thing this-way)
>> Not 3rd place:
>>   (let ((control-behavior with-some-value))
>>     (in-function) )
>
> That's 3rd-grade "knowledge". (Only a rough first
> approximation, if you prefer.)

The first case corresponds to a worker in an industry or work
shop who knows what to do and has all the tools of the trade.

The second knows what to do but you have to tell him what
tools to use.

The third (or worse) crewman isn't even in possession of any
tools, you just hope he will take them because before you told
him to get going you placed them in a, in your mind,
well-found place for the purpose ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : messages to *Messages* without appearing in mini-buffer?

[Drew Adams]

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

> > (let ((inhibit-message  t))
> >   (message "Msg only to be logged in *Messages*"))
> 
> Doesn't work for me?
> 
> I see it.
> 
> Dont know if message displays it or if it is displayed because
> it is returned.

What you see is the printed return value of
the sexp you asked to evaluate-AND-PRINT.

Try `eval-region' on the sexp instead.

Or put it in a defun and invoke the function
in a way that doesn't also print its return value.
 


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13494 bytes --]

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>> (let ((inhibit-message  t))
>>>   (message "Msg only to be logged in *Messages*"))
>> 
>> Doesn't work for me?
>> 
>> I see it.
>> 
>> Dont know if message displays it or if it is displayed because
>> it is returned.
>
> What you see is the printed return value of
> the sexp you asked to evaluate-AND-PRINT.
>
> Try `eval-region' on the sexp instead.
>
> Or put it in a defun and invoke the function in a way that
> doesn't also print its return value.

(progn
  (message "But then why don't you just do that?")
  1)

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : messages to *Messages* without appearing in mini-buffer?

[Drew Adams]

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

> >>> (let ((inhibit-message  t))
> >>>   (message "Msg only to be logged in *Messages*"))
> >>
> >> Doesn't work for me?
> >>
> >> I see it.
> >>
> >> Dont know if message displays it or if it is displayed because
> >> it is returned.
> >
> > What you see is the printed return value of
> > the sexp you asked to evaluate-AND-PRINT.
> > Try `eval-region' on the sexp instead.
> > Or put it in a defun and invoke the function in a way that
> > doesn't also print its return value.
> 
> (progn
>   (message "But then why don't you just do that?")
>   1)

Because you don't need to do that, to prevent
`message' from displaying in the echo area.

Printing a return value from evaluating a sexp
has nothing to do with the question.  See the
Subject line.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14166 bytes --]

Re: [External] : messages to *Messages* without appearing in mini-buffer?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>>>> (let ((inhibit-message  t))
>>>>>   (message "Msg only to be logged in *Messages*"))
>>>>
>>>> Doesn't work for me?
>>>>
>>>> I see it.
>>>>
>>>> Dont know if message displays it or if it is displayed because
>>>> it is returned.
>>>
>>> What you see is the printed return value of
>>> the sexp you asked to evaluate-AND-PRINT.
>>> Try `eval-region' on the sexp instead.
>>> Or put it in a defun and invoke the function in a way that
>>> doesn't also print its return value.
>> 
>> (progn
>>   (message "But then why don't you just do that?")
>>   1)
>
> Because you don't need to do that, to prevent `message' from
> displaying in the echo area.
>
> Printing a return value from evaluating a sexp has nothing
> to do with the question. See the Subject line.

Eheh ... is it off-topic?

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : messages to *Messages* without appearing in mini-buffer?

[Drew Adams]

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

> >>> What you see is the printed return value of
> >>> the sexp you asked to evaluate-AND-PRINT.
> >>> Try `eval-region' on the sexp instead.
> >>> Or put it in a defun and invoke the function in a way that
> >>> doesn't also print its return value.
> >>
> >> (progn
> >>   (message "But then why don't you just do that?")
> >>   1)
> >
> > Because you don't need to do that, to prevent `message' from
> > displaying in the echo area.
> >
> > Printing a return value from evaluating a sexp has nothing
> > to do with the question. See the Subject line.
> 
> Eheh ... is it off-topic?

Dunno what you're asking.  Are you perhaps asking
whether I think your question is outside of the
topic of the originally posed question?  Maybe it
it is, but it's not off-topic for this mailing list.

And it's a FAQ that comes up often when looking at
behavior involving commands that echo the result of
an evaluation.  So it's generally good to bring it
up and good to answer it.

You asked (I think) why I didn't just end the sexp
I wrote with some other value than that returned by
the `message' call, to avoid confusion between
printing that return value in the echo area and what
`message' itself does with the message (it doesn't
print it to the echo area).

I answered that I wrote a minimal sexp that answered
the original question: how to prevent `message' from
printing to the echo area.

That's what one typically does: bind `inhibit-message'.
Anything else isn't germane to the original question,
and including it in the code could give the false
impression that it's needed as part of the answer.

But of course including something else (e.g. a
different return value) and not including it can
each lead to confusion.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14870 bytes --]