Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
y oder yes oder gar nix
1 view
Skip to first unread message
Torsten Mueller
May 31, 2023, 8:02:02 AM5/31/23
to
Ich hab seit paar Wochen einen neuen Emacs 28.2 für Windows im Einsatz,
der anders ist als mein 28.2 für Linux.
Speziell in Gnus ist das Verhalten von ersterem bei Rückfragen anders
und sehr ungewohnt als bei letzterem, der sich nach wie vor so verhält,
wie das seit Jahrzehnten üblich war.
Ich benutze die Einstellung
(fset 'yes-or-no-p 'y-or-n-p)
Damit verhält sich mein Windows-Emacs in Gnus nun wie folgt:
- Bei den meisten Rückfragen verlangt er "y" oder "n", wie ich es
erwarten würde.
- Wenn ich mich im Groups buffer auf einer der dort aufgelisteten
Gruppen befinde und diese als gelesen markieren will, so gab ich ihm
früher "cy" ("see you"). Nun genügt bereits das "c" und die Aktion
wird sofort ausgeführt. Das "y", das ich selbstverständlich tippe,
wird zum Glück zu Müll ("y is undefined") und startet nicht noch ein
neues Kommando.
- Wenn ich einen Beitrag zum Lesen offen habe und ich drücke "c" so
springt er jetzt sofort bis in den Groups buffer zurück, auch hier war
doch früher "cy" üblich.
- Beim Löschen von mails oder von drafts verlangt er explizit "yes" oder
"no", ich würde aber "y" oder "n" erwarten, so hat es bei mir seit 20
Jahren funktioniert.
Hat außer mir noch jemand diese Phänomene?
Wieso besteht ein Unterschied zwischen zwei gleichen Versionen, die noch
dazu die gleichen Konfigurationsdateien verwenden?
Kann man das irgendwie abstellen? Ich will es wieder so wie früher
haben, einheitlich "y" oder "n", überall. Ich habe bereits lange in den
Optionen herumgesucht, aber bislang nichts Vernünftiges gefunden. Mir
ist auch nicht klar: ist es Emacs oder Gnus?
T.M.
der anders ist als mein 28.2 für Linux.
Speziell in Gnus ist das Verhalten von ersterem bei Rückfragen anders
und sehr ungewohnt als bei letzterem, der sich nach wie vor so verhält,
wie das seit Jahrzehnten üblich war.
Ich benutze die Einstellung
(fset 'yes-or-no-p 'y-or-n-p)
Damit verhält sich mein Windows-Emacs in Gnus nun wie folgt:
- Bei den meisten Rückfragen verlangt er "y" oder "n", wie ich es
erwarten würde.
- Wenn ich mich im Groups buffer auf einer der dort aufgelisteten
Gruppen befinde und diese als gelesen markieren will, so gab ich ihm
früher "cy" ("see you"). Nun genügt bereits das "c" und die Aktion
wird sofort ausgeführt. Das "y", das ich selbstverständlich tippe,
wird zum Glück zu Müll ("y is undefined") und startet nicht noch ein
neues Kommando.
- Wenn ich einen Beitrag zum Lesen offen habe und ich drücke "c" so
springt er jetzt sofort bis in den Groups buffer zurück, auch hier war
doch früher "cy" üblich.
- Beim Löschen von mails oder von drafts verlangt er explizit "yes" oder
"no", ich würde aber "y" oder "n" erwarten, so hat es bei mir seit 20
Jahren funktioniert.
Hat außer mir noch jemand diese Phänomene?
Wieso besteht ein Unterschied zwischen zwei gleichen Versionen, die noch
dazu die gleichen Konfigurationsdateien verwenden?
Kann man das irgendwie abstellen? Ich will es wieder so wie früher
haben, einheitlich "y" oder "n", überall. Ich habe bereits lange in den
Optionen herumgesucht, aber bislang nichts Vernünftiges gefunden. Mir
ist auch nicht klar: ist es Emacs oder Gnus?
T.M.
Stefan Wiens
May 31, 2023, 10:49:00 AM5/31/23
to
Gnus bzw. Message verwenden
gnus-y-or-n-p
gnus-yes-or-no-p
message-y-or-n-p
wobei mindestens die gnus-+-Äquivalente harmlos sind.
Bei "c" im Group-Buffer entscheiden die Variablen
gnus-interactive-catchup und gnus-expert-user
darüber, ob die Rückfrage gestellt wird.
Das zum Anfang.
--
Stefan
Stefan Wiens
May 31, 2023, 7:45:26 PM5/31/23
to
Andreas Kohlbach <a...@spamfence.net> writes:
> Aber warum sollte sich das spontan ändern? Soweit ich sehe, änderte er
> nichts an den Einstellungen, die andernfalls zu dem Problem hätten führen
> können.
>
> Meiner (Version Gnus v5.13) hat keine besonderen Angaben (wie
> "gnus-y-or-n-p"), und verhält sich bei c-y wie erwartet. Ich nutze ihn
> allerdings auf einer TTY (nicht Xterm).
Der OP überlädt die built-in function yes-or-no-p
mit etwas anderem!
Das ist vergleichbar mit (*fset '+ '-*).
(Die Sternchen nur gegen versehentliches Ausführen.)
Wer weiß, was noch ähnlichen Kalibers im Startup-File steht.
Etwas Debugging-Bereitschaft wäre da hilfreich.
--
Stefan
> nichts an den Einstellungen, die andernfalls zu dem Problem hätten führen
> können.
>
> Meiner (Version Gnus v5.13) hat keine besonderen Angaben (wie
> "gnus-y-or-n-p"), und verhält sich bei c-y wie erwartet. Ich nutze ihn
> allerdings auf einer TTY (nicht Xterm).
Der OP überlädt die built-in function yes-or-no-p
mit etwas anderem!
Das ist vergleichbar mit (*fset '+ '-*).
(Die Sternchen nur gegen versehentliches Ausführen.)
Wer weiß, was noch ähnlichen Kalibers im Startup-File steht.
Etwas Debugging-Bereitschaft wäre da hilfreich.
--
Stefan
Torsten Mueller
Jun 1, 2023, 1:42:45 AM6/1/23
to
Stefan Wiens <s....@gmx.net> schrieb:
> Der OP überlädt die built-in function yes-or-no-p mit etwas anderem!
Ja, mit der built-in function y-or-n-p. Das ist weder irgendwie
besonders noch ungewöhnlich, es wird zigfach in Tutorials und
Beispielkonfigs erwähnt und funktioniert einwandfrei, solange ich mich
zurückerinnern kann (mindestens 20 Jahre). Kein Mensch muß genötigt
werden, laufend "yes" oder "no" hinzuschreiben und dann auch noch Enter
drücken zu müssen.
> Das ist vergleichbar mit (*fset '+ '-*).
> (Die Sternchen nur gegen versehentliches Ausführen.)
Unsinn. Es ist vergleichbar mit (*fset '+ '+´*).
> Wer weiß, was noch ähnlichen Kalibers im Startup-File steht.
Nix.
Dein Hinweis auf gnus-expert-user scheint hilfreich gewesen zu sein.
Dies stand bei mir unter Windows tatsächlich auf t und zwar durche inen
Eintrag unter (custom-set-variables ...), d.h. ich hab es in Emacs mit
Browse Customization Groups gemacht - ist mir heute ein Rätsel, ich kann
mich nicht daran erinnern. Ich hab diese Zeile dort jetzt gelöscht, so
daß es wieder nil ist, und siehe, es ist eigentlich wieder wie früher.
Danke.
T.M.
> Der OP überlädt die built-in function yes-or-no-p mit etwas anderem!
besonders noch ungewöhnlich, es wird zigfach in Tutorials und
Beispielkonfigs erwähnt und funktioniert einwandfrei, solange ich mich
zurückerinnern kann (mindestens 20 Jahre). Kein Mensch muß genötigt
werden, laufend "yes" oder "no" hinzuschreiben und dann auch noch Enter
drücken zu müssen.
> Das ist vergleichbar mit (*fset '+ '-*).
> (Die Sternchen nur gegen versehentliches Ausführen.)
> Wer weiß, was noch ähnlichen Kalibers im Startup-File steht.
Dein Hinweis auf gnus-expert-user scheint hilfreich gewesen zu sein.
Dies stand bei mir unter Windows tatsächlich auf t und zwar durche inen
Eintrag unter (custom-set-variables ...), d.h. ich hab es in Emacs mit
Browse Customization Groups gemacht - ist mir heute ein Rätsel, ich kann
mich nicht daran erinnern. Ich hab diese Zeile dort jetzt gelöscht, so
daß es wieder nil ist, und siehe, es ist eigentlich wieder wie früher.
Danke.
T.M.
Axel Reichert
Jun 1, 2023, 2:38:50 AM6/1/23
to
Torsten Mueller <muel...@runbox.com> writes:
> Dein Hinweis auf gnus-expert-user scheint hilfreich gewesen zu sein.
> Dies stand bei mir unter Windows tatsächlich auf t und zwar durche
> inen Eintrag unter (custom-set-variables ...)
Such mal im Netz zu Artikeln, die das Thema "Customize" versus
> Dein Hinweis auf gnus-expert-user scheint hilfreich gewesen zu sein.
> Dies stand bei mir unter Windows tatsächlich auf t und zwar durche
> inen Eintrag unter (custom-set-variables ...)
haendisches Editieren der init.el/.emacs behandeln. Es gibt verschiedene
Strategien, wie man das Problem der doppelten Konfigurationsoptionen
(bzw. Management einer einheitlichen und dokumentierten Konfiguration)
angehen kann:
- Alle customize-Dinge in eigene Datei auslagern
- Alle customize-Dinge in temporaere/ignorierte Datei auslagern,
testen und ggf. in init.el uebernehmen (sei es mit use-package oder
ohne)
- straight.el versus use-package versus "vanilla" (haendisch)
- org-babel zur Doku samt "Bootstrapping" der init.el
Ist jetzt eher tangential zu deiner Anfrage, aber allemal interessant
und lohnend.
Tschoe!
Axel
Stefan Wiens
Jun 1, 2023, 3:01:51 AM6/1/23
to
Torsten Mueller <muel...@runbox.com> writes:
> Stefan Wiens <s....@gmx.net> schrieb:
>
>> Der OP überlädt die built-in function yes-or-no-p mit etwas anderem!
>
> Ja, mit der built-in function y-or-n-p. Das ist weder irgendwie
> besonders noch ungewöhnlich, es wird zigfach in Tutorials und
> Beispielkonfigs erwähnt und funktioniert einwandfrei, solange ich mich
> zurückerinnern kann (mindestens 20 Jahre). Kein Mensch muß genötigt
> werden, laufend "yes" oder "no" hinzuschreiben und dann auch noch Enter
> drücken zu müssen.
Der Vollständigkeit halber: y-or-n-p ist zumindest hier eine
> Stefan Wiens <s....@gmx.net> schrieb:
>
>> Der OP überlädt die built-in function yes-or-no-p mit etwas anderem!
>
> Ja, mit der built-in function y-or-n-p. Das ist weder irgendwie
> besonders noch ungewöhnlich, es wird zigfach in Tutorials und
> Beispielkonfigs erwähnt und funktioniert einwandfrei, solange ich mich
> zurückerinnern kann (mindestens 20 Jahre). Kein Mensch muß genötigt
> werden, laufend "yes" oder "no" hinzuschreiben und dann auch noch Enter
> drücken zu müssen.
compiled Lisp function in ‘subr.el’.
Das Überladen macht bei Emacs Lisp offenbar nichts aus
(bei Common Lisp könnte der Compiler so etwas optimieren).
> Dein Hinweis auf gnus-expert-user scheint hilfreich gewesen zu sein.
> Dies stand bei mir unter Windows tatsächlich auf t und zwar durche inen
> Eintrag unter (custom-set-variables ...), d.h. ich hab es in Emacs mit
> Browse Customization Groups gemacht - ist mir heute ein Rätsel, ich kann
> mich nicht daran erinnern. Ich hab diese Zeile dort jetzt gelöscht, so
> daß es wieder nil ist, und siehe, es ist eigentlich wieder wie früher.
> Danke.
--
Stefan
Torsten Mueller
Jun 1, 2023, 3:06:23 AM6/1/23
to
Torsten Mueller <muel...@runbox.com> schrieb:
> Ich hab diese Zeile dort jetzt gelöscht, so daß es wieder nil ist, und
> siehe, es ist eigentlich wieder wie früher.
Nee, noch immer nicht ganz: beim Löschen (z.B. einer Mail-Nachricht) muß
ich immer noch "yes" hinschreiben und Enter drücken.
Es ist, um auch dies einheitlich zu machen, erforderlich, auch noch
gnus-yes-or-no-p umzudefinieren, z.B. auf gnus-y-or-n-p. Dies darf aber
erst geschehen, nachdem Gnus geladen wurde.
Mindestens dieser Schritt ist bei mir unter Linux nicht erforderlich,
dort wird offenbar die viel früher (nämlich schon beim Starten von
Emacs) erfolgte Umdefinition von yes-or-no-p berücksichtigt.
T.M.
> Ich hab diese Zeile dort jetzt gelöscht, so daß es wieder nil ist, und
> siehe, es ist eigentlich wieder wie früher.
ich immer noch "yes" hinschreiben und Enter drücken.
Es ist, um auch dies einheitlich zu machen, erforderlich, auch noch
gnus-yes-or-no-p umzudefinieren, z.B. auf gnus-y-or-n-p. Dies darf aber
erst geschehen, nachdem Gnus geladen wurde.
Mindestens dieser Schritt ist bei mir unter Linux nicht erforderlich,
dort wird offenbar die viel früher (nämlich schon beim Starten von
Emacs) erfolgte Umdefinition von yes-or-no-p berücksichtigt.
T.M.
Tim Landscheidt
Jun 1, 2023, 7:38:42 PM6/1/23
to
Torsten Mueller <muel...@runbox.com> wrote:
> […]
>> Das ist vergleichbar mit (*fset '+ '-*).
>> (Die Sternchen nur gegen versehentliches Ausführen.)
> Unsinn. Es ist vergleichbar mit (*fset '+ '+´*).
> […]
In diesem speziellen Fall kann es interessant sein, statt-
dessen use-short-answers zu konfigurieren.
Tim
> […]
>> Das ist vergleichbar mit (*fset '+ '-*).
>> (Die Sternchen nur gegen versehentliches Ausführen.)
> Unsinn. Es ist vergleichbar mit (*fset '+ '+´*).
In diesem speziellen Fall kann es interessant sein, statt-
dessen use-short-answers zu konfigurieren.
Tim
Torsten Mueller
Jun 2, 2023, 1:24:31 AM6/2/23
to
Tim Landscheidt <t...@tim-landscheidt.de> schrieb:
> In diesem speziellen Fall kann es interessant sein, stattdessen
> use-short-answers zu konfigurieren.
Nicht im Falle des Löschens von Nachrichten, dort wirkt es nicht. Hab's
probiert. "B Del" ist dann immer noch mit "yes" oder "no" plus Enter zu
beantworten, was vor allem im Falle mehrfacher Löschungen infolge Spam
o.ä. sehr lästig wird. Ja, man könnte erst mehrfach markieren und dann
löschen, ist aber auch nicht besser und vor allem inkonsequent: ich will
ja/nein-Rückfragen einfach konsequent mit "y" oder "n", und ohne Enter.
T.M.
> In diesem speziellen Fall kann es interessant sein, stattdessen
> use-short-answers zu konfigurieren.
Nicht im Falle des Löschens von Nachrichten, dort wirkt es nicht. Hab's
probiert. "B Del" ist dann immer noch mit "yes" oder "no" plus Enter zu
beantworten, was vor allem im Falle mehrfacher Löschungen infolge Spam
o.ä. sehr lästig wird. Ja, man könnte erst mehrfach markieren und dann
löschen, ist aber auch nicht besser und vor allem inkonsequent: ich will
ja/nein-Rückfragen einfach konsequent mit "y" oder "n", und ohne Enter.
T.M.
Tim Landscheidt
Jun 2, 2023, 6:50:36 AM6/2/23
to
use-short-answers nil (Default) bei B DEL nach „yes“ oder
„no“ und RET und bei use-short-answers t nach „y“ oder „n“
(ohne RET). Das ist auch das Verhalten, was man nach dem An-
sehen des Codes vermuten würde.
Jetzt könnten wir spekulieren, ob Du vor (fset 'yes-or-no-p
'y-or-n-p) (fset 'y-or-n-p 'yes-or-no-p) ausgeführt hast,
aber wenn Du fset benutzt, solltest Du auch edebug benutzen
können :-).
Tim
Torsten Mueller
Jun 2, 2023, 7:17:27 AM6/2/23
to
Tim Landscheidt <t...@tim-landscheidt.de> schrieb:
> Hier™ (GNU Emacs 28.2/Fedora 37) fragt Gnus mit use-short-answers nil
> (Default) bei B DEL nach „yes“ oder „no“ und RET und bei
> use-short-answers t nach „y“ oder „n“ (ohne RET). Das ist auch das
> Verhalten, was man nach dem An- sehen des Codes vermuten würde.
Ja, vermuten würde ich das auch. Aber ich sag ja: unter Linux ist es
anders als unter Windows.
> Jetzt könnten wir spekulieren, ob Du vor (fset 'yes-or-no-p 'y-or-n-p)
> (fset 'y-or-n-p 'yes-or-no-p) ausgeführt hast,
Nix, ich hab ja alle eigenmächtigen Verbiegungen extra für den Test mit
use-short-answers stillgelegt. Mit use-short-answers will mein
Windows-Emacs [1] nach "B Del" tatsächlich "yes" oder "no" plus Enter.
An allen anderen Stellen (insbesondere nach "c") scheint es hingegen zu
wirken.
T.M.
[1] der offizielle von https://www.gnu.org/software/emacs, die haben
dort jetzt auch Windows-binaries
> Hier™ (GNU Emacs 28.2/Fedora 37) fragt Gnus mit use-short-answers nil
> (Default) bei B DEL nach „yes“ oder „no“ und RET und bei
> use-short-answers t nach „y“ oder „n“ (ohne RET). Das ist auch das
> Verhalten, was man nach dem An- sehen des Codes vermuten würde.
anders als unter Windows.
> Jetzt könnten wir spekulieren, ob Du vor (fset 'yes-or-no-p 'y-or-n-p)
> (fset 'y-or-n-p 'yes-or-no-p) ausgeführt hast,
use-short-answers stillgelegt. Mit use-short-answers will mein
Windows-Emacs [1] nach "B Del" tatsächlich "yes" oder "no" plus Enter.
An allen anderen Stellen (insbesondere nach "c") scheint es hingegen zu
wirken.
T.M.
[1] der offizielle von https://www.gnu.org/software/emacs, die haben
dort jetzt auch Windows-binaries
Stefan Wiens
Jun 2, 2023, 1:20:59 PM6/2/23
to
M-x debug-on-entry RET yes-or-no-p RET
ausführen und beim unerwünschten Rückfragen im
call-stack nachsehen, von wo her die Funktion
aufgerufen wird.
--
Stefan
Michael Albinus
Jun 2, 2023, 2:14:41 PM6/2/23
to
Torsten Mueller <muel...@runbox.com> writes:
Hi,
>> Jetzt könnten wir spekulieren, ob Du vor (fset 'yes-or-no-p 'y-or-n-p)
>> (fset 'y-or-n-p 'yes-or-no-p) ausgeführt hast,
>
> Nix, ich hab ja alle eigenmächtigen Verbiegungen extra für den Test mit
> use-short-answers stillgelegt. Mit use-short-answers will mein
> Windows-Emacs [1] nach "B Del" tatsächlich "yes" oder "no" plus Enter.
> An allen anderen Stellen (insbesondere nach "c") scheint es hingegen zu
> wirken.
Setz mal (setq debug-on-error t debug-on-quit t)
Wenn Du dann nach "yes" oder "no" gefragt wirst, gehe mit C-g raus. Das
sollte einen Backtrace ergeben, welcher uns erzaehlt, ob das alles ueber
'yes-or-no-p' gelaufen ist, oder einen anderen Weg.
Ausserdem kannst Du (describe-function 'yes-or-no-p) aufrufen, da ist
dann zu sehen, ob es einen Alias gibt.
> T.M.
Ciao, Michael.
Hi,
>> Jetzt könnten wir spekulieren, ob Du vor (fset 'yes-or-no-p 'y-or-n-p)
>> (fset 'y-or-n-p 'yes-or-no-p) ausgeführt hast,
>
> Nix, ich hab ja alle eigenmächtigen Verbiegungen extra für den Test mit
> use-short-answers stillgelegt. Mit use-short-answers will mein
> Windows-Emacs [1] nach "B Del" tatsächlich "yes" oder "no" plus Enter.
> An allen anderen Stellen (insbesondere nach "c") scheint es hingegen zu
> wirken.
Wenn Du dann nach "yes" oder "no" gefragt wirst, gehe mit C-g raus. Das
sollte einen Backtrace ergeben, welcher uns erzaehlt, ob das alles ueber
'yes-or-no-p' gelaufen ist, oder einen anderen Weg.
Ausserdem kannst Du (describe-function 'yes-or-no-p) aufrufen, da ist
dann zu sehen, ob es einen Alias gibt.
> T.M.
Ciao, Michael.
Torsten Mueller
Jun 5, 2023, 2:10:01 AM6/5/23
to
Stefan Wiens <s....@gmx.net> schrieb:
> M-x debug-on-entry RET yes-or-no-p RET
(alles in diesem Beitrag bezieht sich auf Windows)
Wenn ich in .emacs yes-or-no-p auf y-or-n-p umgebogen habe und dann in
Gnus eine Mail-Nachricht mit B Del löschen will, so erscheint die
Nachfrage, die "yes" oder "no" verlangt, aber yes-or-no-p wird dabei
nicht aufgerufen. Der Debugger hält nicht an.
Ich habe daraufhin obiges Kommando auch mit gnus-yes-or-no-p probiert,
was offensichtlich eine eigene Implementierung besitzt, die nicht von
yes-or-no-p abhängt. Bei B Del erfolgt der Aufruf so:
| Debugger entered--entering a function:
| * gnus-yes-or-no-p("Do you really want to delete this article forever?...")
| gnus-summary-delete-article(nil)
| funcall-interactively(gnus-summary-delete-article nil)
| command-execute(gnus-summary-delete-article)
Das Problem besteht meiner Ansicht nach nicht in diesem Aufruf, es muß
ja irgendwie eine ja/nein-Rückfrage erzeugt werden.
Das Problem ist, daß gnus-yes-or-no-p offenbar nicht die globale
Funktion yes-or-no-p benutzt, also nichts von meiner zuvor erfolgten
Verbiegung auf y-or-n-p mitbekommt.
Vielleicht sähe das anders aus, wenn ich mal die .elc-Dateien von Gnus
löschen (und ggf. neu erzeugen) würde. Meine .elc-Dateien sind bei der
Installation auf meine Maschine kopiert worden, die habe ich nicht
selbst erzeugt.
Die einfachste Lösung bleibt jedoch, in .gnus auch gnus-yes-or-no-p auf
y-or-n-p zu legen. Funktioniert sofort.
T.M.
> M-x debug-on-entry RET yes-or-no-p RET
Wenn ich in .emacs yes-or-no-p auf y-or-n-p umgebogen habe und dann in
Gnus eine Mail-Nachricht mit B Del löschen will, so erscheint die
Nachfrage, die "yes" oder "no" verlangt, aber yes-or-no-p wird dabei
nicht aufgerufen. Der Debugger hält nicht an.
Ich habe daraufhin obiges Kommando auch mit gnus-yes-or-no-p probiert,
was offensichtlich eine eigene Implementierung besitzt, die nicht von
yes-or-no-p abhängt. Bei B Del erfolgt der Aufruf so:
| Debugger entered--entering a function:
| * gnus-yes-or-no-p("Do you really want to delete this article forever?...")
| gnus-summary-delete-article(nil)
| funcall-interactively(gnus-summary-delete-article nil)
| command-execute(gnus-summary-delete-article)
Das Problem besteht meiner Ansicht nach nicht in diesem Aufruf, es muß
ja irgendwie eine ja/nein-Rückfrage erzeugt werden.
Das Problem ist, daß gnus-yes-or-no-p offenbar nicht die globale
Funktion yes-or-no-p benutzt, also nichts von meiner zuvor erfolgten
Verbiegung auf y-or-n-p mitbekommt.
Vielleicht sähe das anders aus, wenn ich mal die .elc-Dateien von Gnus
löschen (und ggf. neu erzeugen) würde. Meine .elc-Dateien sind bei der
Installation auf meine Maschine kopiert worden, die habe ich nicht
selbst erzeugt.
Die einfachste Lösung bleibt jedoch, in .gnus auch gnus-yes-or-no-p auf
y-or-n-p zu legen. Funktioniert sofort.
T.M.
0 new messages