alert shows nothing about alert

[matthew-piziak]

Can reproduce. (alert "This is an alert" :severity 'high) with no customizations does not show any text in the minibuffer as expected.

• Arch Linux
• GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
• alert 20180122.1242 (melpa)

[jave]

I was confused as well at first why there were no messages. I got messages in the messages buffer, but no Alert log.

Reading the code I noticed if you have log4e installed, this will be used instead of the Alert buffer
You can instead do (alert--log-open-log) to see the log4e buffer for the alert system.

I didnt try any of the fancier alert methods, because im running emacs in a ssh session.

[appetrosyan]

This is a pretty critical problem! How come this issue is not yet fixed?

[jagrg]

I'm having the same issue with message as the default style.

[novoid]

I do seem to have the same issue:

• Windows 10
• Emacs 25.2.1
• alert 1.2 (from Elpa)

[appetrosyan]

Can confirm on OS X this produces no output

[excalamus]

Unless I'm mistaken, this seems pretty critical. As far as I can tell, the entire functionality of alert.el rests on the (alert) function.

I can't get a solid workaround, but it seems like a problem with alert-encoding-string.

Reproducing behavior is really squirrel-y for this.

I renamed elpa/ and ran emacs -Q.

In the *scratch* buffer, I did the following, one line at at time:

(package-initialize)

(add-to-list 'package-archives
	     '("melpa" . "http://melpa.org/packages/") t)

(package-refresh-contents)

;; M-x package-install alert

(alert "Hello, world!")			        ; Outputs to *Messages*
(alert "Hello, world!" :style 'message)	; Outputs to *Messages*
(alert "Hello, world!" :style 'toaster)	; Outputs to *Messages*

(alert-message-notify "Hello, world!")  ; Echos "nil" in minibuffer
(alert-toaster-notify "Hello, world!")     ; Generates error

The error is:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  encode-coding-string(nil iso-latin-1-unix)
  alert-toaster-notify("Hello, world!")
  eval((alert-toaster-notify "Hello, world!") nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

---

Thoughts

The function referenced in the error is encode-coding-string which seems to occur within alert-encode-string. This is called all over the place.

It seems like alert-ecode-string is being passed nil when it expects a string.

At one point, I was able to run the following, and get things to work. This redefines alert-encode-string to return an empty string on error (such as when nil is passed to it).

(defsubst alert-encode-string (str)
  (condition-case nil
      (encode-coding-string str (keyboard-coding-system))
    (error "")))

However, I can't get this to work all the time. Is there some code somewhere which is being compiled and read which I'm not aware of?

[jcguu95]

I'm using the style 'libnotify, and (alert "Hi") does not trigger a system notification. There's no buffer *Alerts* either.

Thankfully, as pointed out by @jave above

I was confused as well at first why there were no messages. I got messages in the messages buffer, but no Alert log.

Reading the code I noticed if you have log4e installed, this will be used instead of the Alert buffer
You can instead do (alert--log-open-log) to see the log4e buffer for the alert system.

I didnt try any of the fancier alert methods, because im running emacs in a ssh session.

the alert message is logged in the buffer *log4e-alert*, which is only created after I ran (alert--log-open-log).

---

I tried to look into the source code and find the problem. So far I haven't succeeded. But here are some knowledge about the code.

Pipe flow

1. (alert "Hi!" :style 'libnotify) first wraps my message and configs into an info.
2. #'alert-send-notification then launches (funcall notifier info), where notifier is selected based on the :style I gave in the first step. In my case, the notifier is #'alert-libnotify-notify.
3. In the source of #'alert-libnotify-notify, the critical step is

        (apply #'call-process alert-libnotify-command nil
               (list (get-buffer-create " *libnotify output*") t) nil args))

where alert-libnotify-command has been correctly set to the path of the binary "/usr/bin/notify-send".

To test if the problem is related to dbus.

So to test if this last steps is ok, I write a typical example of an info.

(setq info--a-typical-example
      (list :message "Testing message."
            :title "Testing title."
            :severity 'normal
            :category nil
            :buffer nil
            :mode nil
            :id nil
            :data nil))

And thankfully, (funcall #'alert-libnotify-notify info--a-typical-example) does send a system notification correctly!

This shows that my problem isn't related to dbus or so. I will keep reporting what I have. Hopefully this would be helpful for some of you.

[adicarlo]

I'm having the same problem on Debian/Stretch running Emacs 25.1.1, using message as the default style as well.

Here's a high-priority example:

(alert "This is an alert" :severity 'high)

==> Messages
This is an alert
[nil 22763 37515 567227 nil alert-remove-when-active (alert-message-remove (:message "This is an alert" :title "scratch" :icon nil :severity high :category nil :buffer #<buffer scratch> ...)) nil 522000]

Interestingly, I am seeing the "so-and-so is typing..." messsages.

[opsaaspo]

The same problem on Voidlinux emacs GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.12) of 2017-05-07

This is an alert
[nil 22931 22519 26270 nil alert-remove-when-active (alert-message-remove (:message "This is an alert" :title "My Alert" :icon nil :severity normal :category nil :buffer #<buffer Messages> ...)) nil 148000]

[dalanicolai]

Still same error on Emacs 26.3 on linux (Fedora 31). Just basic (alert "hello") does not show anything in the mini-buffer. It does log it in the Messages buffer though.

[excalamus]

This is a pretty critical problem! How come this issue is not yet fixed?

There are many reasons why this may not be fixed yet. It may be that people have been too busy to give it attention. Maybe the bug is difficult to resolve, despite repeated attempts. Perhaps it's simply holding out for that special someone to come along to fix it. Perhaps that someone is you! Is there anything you've learned about the bug which could help resolve it?

[friedelino]

Hello! I just recently installed alert (because of org-alert) and had this very same problem. After some investigations i found out that notify-send also was not working from emacs-shell. Also invoking

(shell-command (concat "notify-send -t 1800000"  "foo"))

did not show anything, even though the command was executed.
The reason was that inside emacs a different $DBUS_SESSION_BUS_ADDRESS env variable was set then outside, which i recognized by invoking

echo $DBUS_SESSION_BUS_ADDRESS

in a terminal window, where notify-send worked properly.
What fixed this problem for me, was killing & restarting my emacs-daemon.

[jcguu95]

@rudirando thanks for pointing out the possibility. You might want to change

(concat "notify-send -t 1800000" "foo")

to

(concat "notify-send -t 1800000" " foo")

as well (notice the white space).

[jcguu95]

I found the issue for me, with temporary solution in #92. Hopefully this will be fixed..

Please try the temp solution and see if it works for you! Then we can narrow this issue down to that :style isn't handled correctly.

[pkschweiger]

Seeing the same symptoms as those in the initial report:

• output appears in the *Messages* buffer
• followed by [nil 22729 14218 34573 nil alert-remove-when-active ... in the *Messages* buffer
• minibuffer does not display the alert

In my case, on emacs 27.1 this happens for the 'message style irrespective of whether that's forced in alert() invocation or set alert-default-style. I read and tinkered a bit with the code that removes the messages. alert-send-nofitication has the following code:

    (with-current-buffer alert-buffer
      (add-hook 'post-command-hook #'alert-remove-on-command nil t))

just looking at the hook and finding eldoc early in the list:

Its value is
(alert-remove-on-command eldoc-schedule-timer jit-lock--antiblink-post-command t flyspell-post-command-hook)
Local in buffer *scratch*; global value is 
(global-font-lock-mode-check-buffers global-eldoc-mode-check-buffers magit-auto-revert-mode-check-buffers exwm-input--on-post-command mode-local-post-major-mode-change)

I suspect that there's actually interference from other libraries ...

(alert "do not see in minibuffer when evaled in *scratch* buffer")
(defun alert-tst ()
  (interactive)
  (alert "you see this in minibuffer?  Bet you switched to *Messages* buffer before M-x alert-tst "))

in my setup the alert-tst command above doesn't show up in the minibuffer when run while in *scratch* but does show up while current buffer is *Messages*. I see alert messages in the minibuffer, even from *scratch* with a single change to my initialization: (global-eldoc-mode -1)

I suspect the message is actually sent to the minibuffer and removed or superseded before it's actually rendered there. I also suspect eldoc is just one of any number of set ups that can trigger this.

In my original setup, with eldoc, and the alert-remove-on-command addition to post-command-hook commented out, an (alert "tst") causes 2nd message ([nil 22729 14218 34573 nil alert-remove-when-active ...) to appear in the minibuffer.

I do not mean to suggest either either living without eldoc (or any number of other packages that could interfere in similar fashion) or not installing alert-remove-on-command as a workaround - I am only adding observations.

[dalanicolai]

I have looked a little into the alert-send-nofitication function also. So I find that when removing the lines after (funcall notifier info), then style message seems to work "correctly". But when including the subsequent two lines i.e.

  (let ((remover (plist-get style-def :remover)))
    (add-to-list 'alert-active-alerts (list alert-buffer info remover))

Then the message alert breaks. However, when I replace the add-to-list with some other test add-to-list form e.g. (add-to-list 'test "foo") then it works "correctly" again.
Also, I noticed that when stepping through the function with edebug, then after the step where the 'alert-active-alerts hook should have been added, the hook's value is still nil when checked using C-h v 😬

When removing the remover from alert-define-style using the following lines:

(alert-define-style 'message :title "Display message in minibuffer"
                    :notifier #'alert-message-notify)

the message alert also seems to work fine.

[dalanicolai]

THIS SEEMS NOT TO BE A BUG, at least for the style is "message" case.

For the original bug report (the first comment here), it looks like the alert-(default-)style was not set correctly.

I investigated a little more for the message style case, and finally I noticed that the alerts are removed by a post-command-hook. So it means that testing alert using e.g. M-: (alert "test") does not work because actually running the command requires pressing RET, which runs the command read--expression-try-read which runs the hook that deletes the alert message.

If you test the command using e.g.

(run-with-timer 2
                nil
                (lambda () (alert "test")))

then the alert seems to work perfectly fine.

@pkschweiger I did not try to fully understand it, but it feels like this explanation also explains your case...

[jcguu95]

I will test with run-with-timer especially on this! Hopefully that's the main reason why it fails.

[dalanicolai]

@jcguu95 Issue #92 that you are referring to has a different cause.

Until #94 gets merged you can fix it by adding (alert-add-rule) to your dotfile.

[pkschweiger]

@dalanicolai thanks for checking it out!

You did in fact explain the C-x C-e on (alert "test") showing nothing to me. Thank you.

I did not try to fully understand it

My original message mingled a vanilla report with alternate outcomes introduced by hacks. Separate comments might have been better. What I was ultimately trying to point out is that alert package's 'message style is hardly the only contender for a single minibuffer message - eldoc in turn is just one other contender that would lead me to "'message style shows nothing type reports". Like you, I believe `'message' style works as intended, at least in the scenario that led me here.

As you pointed out `'message' style is not the original report - I lost track of by the first comment 😺 - and I'm down to adding noise. Thanks again for your time!

[MarcoHassan]

It is not a solution to alert itself. However if you want to work with org-alert that is working with alert and do not manage to do so you can use this work around on MacOS.

Install terminal-notifier and be sure that it is in your path. Then overwrite the org-alert-check function.

     ;; try to rewrite a function 
     (defun org-alert-check ()
       "Check for active, due deadlines and initiate notifications."
       (interactive)
       (org-alert--preserve-agenda-buffer)
       (let ((active (org-alert--filter-active (org-alert--get-headlines))))
	 (dolist (dl (org-alert--strip-states active))
	   (shell-command-to-string (concatenate 'string "echo " dl " | terminal-notifier -title Emacs_Reminder -sound default  -appIcon http://upload.wikimedia.org/wikipedia/commons/5/59/Emacs_512.png"))))
	   ;; (alert dl :title org-alert-notification-title)))
       (org-alert--restore-agenda-buffer))