Re: Gnus IMAP searching not working.

On Mon, 31 Oct 2011 11:59:01 -0800 Dave Abrahams <dave <at> boostpro.com> wrote: 

DA> I am responsible for this changeset, and I apologize for the problem.
DA> Please apply the following patch.  Ted, could you upstream this, please?
DA> diff --git a/lisp/gnus-registry.el b/lisp/gnus-registry.el
DA> index 652e816..d25b8b1 100644
DA> --- a/lisp/gnus-registry.el
DA> +++ b/lisp/gnus-registry.el
DA>  <at>  <at>  -164,7 +164,7  <at>  <at>  nnmairix groups are specifically excluded because they are ephemeral."
DA>                   (const :tag "Always Install" t)
DA>                   (const :tag "Ask Me" ask)))

DA> -(defvar gnus-registry-enabled)
DA> +(defvar gnus-registry-enabled nil)

DA>  (defvar gnus-summary-misc-menu) ;; Avoid byte compiler warning.

I've already fixed it with a different approach, thanks.

Ted

Re: Gnus version

On  1 Nov 2011, Lars Ingebrigtsen wrote:

> Katsumi Yamaoka <yamaoka <at> jpl.org> writes:
>
>> BTW, hadn't we better bump the Gnus version number in Emacs?
>> Though I don't recall how to increment it.  In ChangeLog:
>>
>> 2007-10-28  v5.13
>
> Hm...  if I recall correctly, then No Gnus was really supposed to be
> 5.12?  (Since Quassia was 5.6 and Pterodactyl was 5.8 and Oort was
> 5.10.)  So I don't know where 5.13 comes from...
>
> 5.13 makes `gnus-continuum-version' not work very well.  

http://en.wikipedia.org/wiki/Gnus

says

Gnus 5.10 (Oort Gnus) – May 1, 2003

Gnus 5.11 rebranded 5.10 bundled with GNU Emacs 22.1 (June 2, 2007)

Gnus 5.13 (included in GNU Emacs 23.1 (July 29, 2009) from No Gnus
branch)

--

-- 
BOFH excuse #310:

asynchronous inode failure

Re: Gnus IMAP searching not working.

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> On Mon, 31 Oct 2011 11:59:01 -0800 Dave Abrahams <dave <at> boostpro.com> wrote: 
>
> DA> I am responsible for this changeset, and I apologize for the problem.
> DA> Please apply the following patch.  Ted, could you upstream this, please?
> DA> diff --git a/lisp/gnus-registry.el b/lisp/gnus-registry.el
> DA> index 652e816..d25b8b1 100644
> DA> --- a/lisp/gnus-registry.el
> DA> +++ b/lisp/gnus-registry.el
> DA>  <at>  <at>  -164,7 +164,7  <at>  <at>  nnmairix groups are specifically excluded because they are ephemeral."
> DA>                   (const :tag "Always Install" t)
> DA>                   (const :tag "Ask Me" ask)))
>
> DA> -(defvar gnus-registry-enabled)
> DA> +(defvar gnus-registry-enabled nil)
>
> DA>  (defvar gnus-summary-misc-menu) ;; Avoid byte compiler warning.
>
> I've already fixed it with a different approach, thanks.
>
> Ted

just and FYI, very timely and synced - unless the git repo is old enough
not have the original error ;) Wasnt working for me earlier, did a git
pull and remade emacs 24 and it works fine now. Great job and thanks.

`eval-after-load' broken for symbols?

The ubiquitous function `eval-after-load` seems to be broken.
The following code causes the message to be displayed:

    (require 'dired)
    (eval-after-load "dired"
      '(message "String works!"))

But the following code doesn’t:

    (require 'dired)
    (eval-after-load 'dired
      '(message "Symbol works!"))

From the docstring of `eval-after-load`:

    Arrange that if FILE is loaded, FORM will be run immediately afterwards.
    If FILE is already loaded, evaluate FORM right now.
        […]
    Alternatively, FILE can be a feature (i.e. a symbol), in which case FORM
    is evaluated at the end of any file that `provide's this feature.

I guess that _could_ be trying to say that "when FILE is a symbol"
it *shouldn’t* "evaluate FORM right now", but if you look at the source
code for `eval-after-load` it doesn’t actually avoid evaluating FORM,
it just happens for an unrelated reason to wrap it in a false conditional:

    (when (symbolp regexp-or-feature)
      ;; For features, the after-load-alist elements get run when `provide' is
      ;; called rather than at the end of the file.  So add an indirection to
      ;; make sure that `form' is really run "after-load" in case the provide

More noticeable version of (message)

Re: More noticeable version of (message)

On Tue, Nov 01 2011, Craig Muth wrote:

> Any ideas?  Not a huge fan of beeping because I associate that with
> an error.  I'm on a mac so any face/font stuff is fair game.

There is:
(require 'notifications)
(notifications-notify ...)

(I don't know, if this works on a mac...)

--

-- 
           Peter

Re: More noticeable version of (message)

Craig Muth <craig.muth <at> gmail.com> writes:

> I often don't notice the output of lines like (message "hi"),
> especially when in full-screen mode.
>
> Any ideas?  Not a huge fan of beeping because I associate that with
> an error.  I'm on a mac so any face/font stuff is fair game.

Try this:

(fset 'message-plain (symbol-function 'message))

(defun message-colored (fmt-string &rest args)
  (message-plain 
   (propertize
    (apply 'format fmt-string args)
    'face 'font-lock-comment-face)))

(fset 'message 'message-colored)

You will see that the messages appear in comment face.

> --Craig
>
>
>

--

-- 

defmacro* usage

Hi all,
I have an error with following recipe:

#+BEGIN_SRC lisp
(defmacro* test1 (&key (lang 'french))
  `(case ,lang
     (french (message "Bonjour"))
     (english (message "Hello"))))

(test1 :lang 'french)
"Bonjour"
(test1 :lang 'english)
"Hello"
(test1)
Debugger entered--Lisp error: (void-variable french)
  (eql french (quote french))
  (cond ((eql french (quote french)) (message "Bonjour")) ((eql french (quote english)) (message "Hello")))
  (case french (french (message "Bonjour")) (english (message "Hello")))
  (test1)
  eval((test1) nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)

(defun* test2 (&key (lang 'french))
  (case lang
     (french (message "Bonjour"))
     (english (message "Hello"))))

(test2 :lang 'french)
"Bonjour"
(test2 :lang 'english)
"Hello"
(test2)
"Bonjour"

#+END_SRC

As you can see, the quoted default argument 'french cause an error with
the defmacro* and work fine with the defun*.

Is it a bug or i misunderstand something?
Thanks.

--

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: defmacro* usage

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Is it a bug or i misunderstand something?

That appears to be how it works in CL.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: defmacro* usage

> I have an error with following recipe:

> #+BEGIN_SRC lisp
> (defmacro* test1 (&key (lang 'french))
>   `(case ,lang
>      (french (message "Bonjour"))
>      (english (message "Hello"))))
[...]
> As you can see, the quoted default argument 'french cause an error with
> the defmacro* and work fine with the defun*.

The error is not from defmacro* but from the code you generated using defmacro*.

> Is it a bug or i misunderstand something?

A misunderstanding.  Think harder about what your macro does.  E.g. try
(macroexpand '(test1 :lang 'toto)) and (macroexpand '(test1)).
During macroexpansion, your `lang' is not supposed to hold a "language
value" but "a Lisp expression that will evaluate to a language value".

        Stefan