What does ":noerror" do?

What does ":noerror" do?

[Xue Fuqiao]

Hi,

From a recent post in emacs-devel[fn:1], I found a usage like this:

(message "Loading Emacspeak...%s"
         (if (load "emacspeak-loader" :noerror) "success!" "FAILED!"))

I'm not sure what the ‘:noerror’ is.  It seems that the ‘:noerror’ is
just like a random symbol, like ‘(quote noerror)’, but I could't find this
kind of usage in lispref.  Any ideas?

Footnotes:

[fn:1] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00256.html

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: What does ":noerror" do?

[Pascal J. Bourguignon]

Xue Fuqiao <xfq.free@gmail.com> writes:

> Hi,
>
>>From a recent post in emacs-devel[fn:1], I found a usage like this:
>
> (message "Loading Emacspeak...%s"
>          (if (load "emacspeak-loader" :noerror) "success!" "FAILED!"))
>
> I'm not sure what the ‘:noerror’ is.  It seems that the ‘:noerror’ is
> just like a random symbol, like ‘(quote noerror)’, but I could't find this
> kind of usage in lispref.  Any ideas?


It is a lisp object that is not the symbol nil, and therefore that is
true.  That's all it takes for a boolean argument.

The doc is quite clear about it:

    If optional second arg NOERROR is non-nil,
    report no error if FILE doesn't exist.

Now this is what it does to the emacs processor.


The question is what it does to the programmer mind of the human
readers?


I could not say about people in general.  It sure looks like it confused
you.  I can tell that I think it should inspire TERROR in every
programmer minds.  Think about it:

      (load file nil :noerror nil :nosuffix)


At least, in Common Lisp we'd use keyword arguments writing something
like:

    (load file :verbose t :print nil :if-does-not-exist nil
               :external-format :utf-8)

and if a typo or wrong keyword is given, the function can easily and do
signal an error.



But with optional arguments, the programmer must ensure that the
parameter are given in the right order, and using keywords for true
booleans may confuse this, and impact a different meaning to the
programmer than to the compiler.  Terror should ensue.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/

RE: What does ":noerror" do?

[Drew Adams]

> > (message "Loading Emacspeak...%s"
> >          (if (load "emacspeak-loader" :noerror) 
> >              "success!"
> >             "FAILED!"))
> >
> > I'm not sure what the ‘:noerror’ is.  It seems that the ‘:noerror’
> > is just like a random symbol, like ‘(quote noerror)’, but I could't
> > find this kind of usage in lispref.  Any ideas?

Right.  It is a keyword, which means that it is a symbol whose value
is always itself, as is the case for `t' and `nil' (which are not
keywords).  It is a constant: you cannot change its value.
`(setq :foo 42)' raises an error saying that you cannot set a constant.

So yes, using `:noerror' here acts the same as using `':noerror'.
 
> It is a lisp object that is not the symbol nil, and therefore that
> is true.  That's all it takes for a boolean argument.
> The doc is quite clear about it:
> 
>     If optional second arg NOERROR is non-nil,
>     report no error if FILE doesn't exist.

IOW, any non-nil value provided as the 2nd argument has the same effect.

> The question is what it does to the programmer mind of the human
> readers?

And the answer is that this particular non-nil argument value, like
`'NOERROR' is (a) as good as any other non-nil value, for the program,
and (b) it says what it does, for a human reader of the code.  Its name
can act as a reminder to someone reading the code that the argument
means "report no error if FILE doesn't exist".

> I could not say about people in general.  It sure looks like it
> confused you.

Perhaps only because keywords are not used so much in Emacs-Lisp code.
It took a long time before they were even added to the language.  And
they still have not been added for use as keyword parameters in lambda
lists.

> I can tell that I think it should inspire TERROR in
> every programmer minds.  Think about it:
>       (load file nil :noerror nil :nosuffix)
> 
> At least, in Common Lisp we'd use keyword arguments writing
> something like:
>     (load file :verbose t :print nil :if-does-not-exist nil
>                :external-format :utf-8)

Now, there you are changing the subject radically.  This use of a
keyword has nothing to do with keyword arguments.  And no, no such use
of a keyword in Emacs "should inspire TERROR" in anyone.  No more than
use of `t' or `nil' or `42' should inspire terror.

OK, so your point is that *IF* the function were a COMMON Lisp function,
and *IF* it had defined keyword arguments (or accepted arbitrary keyword
args, i.e., used `&allow-other-keys`), and *IF* one of those defined
keyword arguments were `:noerror' (or `&allow-other-keys` were present)
*THEN* one might expect `:noerror' to be followed by the keyword value
to pass, and SO someone might be confused to see `:noerror' not be so
followed.

Fair enough.  But off-topic.  The OP asked about alligators, and you
replied about non-alligators.

IF...and IF...and IF...  But OTHERWISE you would (should) not.  And
OTHERWISE is in fact the case.  Your IF...IF...IF... scenario is a
red herring that does not inspire terror.  A non-alligator.

And IF all of that were the case in Emacs Lisp (though it is not) then
the doc would tell you that `&keys' is part of this function's
signature, and it would show each of the defined keywords for the
function, and it would show `&allow-other-keys' if appropriate.
IOW, the signature would let you know whether you can expect
`:noerror' as a keyword arg.

Your uninspired terror is a bogeyman.

Even in Common Lisp, a keyword is just a symbol (in package `keyword')
whose name starts with a colon (`:') and that evaluates to itself
(i.e., has a constant value).

That keywords are often used in Common Lisp as keyword parameters to
functions does not change the fact that they are also used as handy
constant values.

> But with optional arguments, the programmer must ensure that the
> parameter are given in the right order, and using keywords for true
> booleans may confuse this, and impact a different meaning to the
> programmer than to the compiler.  Terror should ensue.

Certainly someone using keywords in Common Lisp needs to know how
they are used as keyword parameters.  But knowing that, there is no
confusion.  Keyword arguments are handled only after all specifiers
of optional parameters have been processed.  And among the keyword
arguments there is no significant order when keywords are present.

In sum:

1. This is Emacs Lisp, which has no keyword parameters (no `&key').

2. Even in Common Lisp, keywords are sometimes used simply as
convenient constants.  As a Boolean Lisp value, for example, they
can be more mnemonic than just `t'.

3. There is no ambiguity here, for either Emacs Lisp or Common Lisp.
But yes, if someone is unclear about keywords then s?he could be
confused.

4. Since there are NO keyword parameters in Emacs Lisp, bringing
them into this discussion creates, instead of removes, confusion.

A keyword passed to an Emacs Lisp function NEVER introduces a
keyword-parameter value.  It is ALWAYS simply a constant value passed
as an ordinary (non-keyword) argument.

5. All of that said, I personally tend to use `'NOERROR' in a context
like this, instead of `:noerror' or `:NOERROR'.  I tend to use
uppercase, and I tend to use the same name that occurs for the formal
parameter in the doc string (but not always, if something better
occurs to me).

Your main answer is well put, however: all that matters in this
particular case is that a non-nil value is passed, and for that
purpose `:noerror' is as good as any other non-nil value.

Re: What does ":noerror" do?

[Xue Fuqiao]

I see, thank you.  Personally, I often use 'no-error or 'noerror.

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: What does ":noerror" do?

[jack-mac]

Le dimanche 13 octobre 2013 05:26:50 UTC+2, Xue Fuqiao a écrit :
> I see, thank you.  Personally, I often use 'no-error or 'noerror.

Me too!

When an argument (whether optional or required) is expected to be a boolean, 
the expected values are usually `t' and `nil'.
But I (try to) NEVER use any of these values (lexically speaking, of course).
Instead, I use the names of the arguments, the way `eldoc' displays them in the echo-area,
so that, when I (or someone else) read the code some time later, 
I can directly understand what I meant when I wrote it.

For a `true' value (non-nil), I use the (quoted symbol) name of the argument, e.g. 'verbose or 'noerror.
For a `false' value (nil), I just use the opposite: (not 'verbose) or (not 'no error).

Of course, with "negative" flags (whose name begins with "no"), 
it leads to an ugly double negation :(

So, for example, as the function `load' is described as:
,----[ M-h f load RET ]
| load is a built-in function in `C source code'.
| 
| (load FILE &optional NOERROR NOMESSAGE NOSUFFIX MUST-SUFFIX)
`----
I would write, for example:
(load file 'noerror 'nomessage) ; if I want no error and no message
or
(load file (not 'noerror) 'nomessage) ; if I want an error but no message

And, yes, in the original context, :noerror 'noerror 'no-error t or any other non-nil value 
would produce almost(1) the same result.

(1) From the point of view of the machine code, I mean. 
Clearly, it produces a lot of different results in the head or the heart of the humans reading the code and in the forum contents!

Re: What does ":noerror" do?

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> writes:

>> > (message "Loading Emacspeak...%s"
>> >          (if (load "emacspeak-loader" :noerror) 
>> >              "success!"
>> >             "FAILED!"))
>> >
>> > I'm not sure what the ‘:noerror’ is.  It seems that the ‘:noerror’
>> > is just like a random symbol, like ‘(quote noerror)’, but I could't
>> > find this kind of usage in lispref.  Any ideas?
>
> Right.  It is a keyword, which means that it is a symbol whose value
> is always itself, as is the case for `t' and `nil' (which are not
> keywords).  It is a constant: you cannot change its value.
> `(setq :foo 42)' raises an error saying that you cannot set a constant.
>
> So yes, using `:noerror' here acts the same as using `':noerror'.
>  
>> It is a lisp object that is not the symbol nil, and therefore that
>> is true.  That's all it takes for a boolean argument.
>> The doc is quite clear about it:
>> 
>>     If optional second arg NOERROR is non-nil,
>>     report no error if FILE doesn't exist.
>
> IOW, any non-nil value provided as the 2nd argument has the same effect.
>
>> The question is what it does to the programmer mind of the human
>> readers?
>
> And the answer is that this particular non-nil argument value, like
> `'NOERROR' is (a) as good as any other non-nil value, for the program,
> and (b) it says what it does, for a human reader of the code.  Its name
> can act as a reminder to someone reading the code that the argument
> means "report no error if FILE doesn't exist".
>
>> I could not say about people in general.  It sure looks like it
>> confused you.
>
> Perhaps only because keywords are not used so much in Emacs-Lisp code.
> It took a long time before they were even added to the language.  And
> they still have not been added for use as keyword parameters in lambda
> lists.
>
>> I can tell that I think it should inspire TERROR in
>> every programmer minds.  Think about it:
>>       (load file nil :noerror nil :nosuffix)
>> 
>> At least, in Common Lisp we'd use keyword arguments writing
>> something like:
>>     (load file :verbose t :print nil :if-does-not-exist nil
>>                :external-format :utf-8)
>
> Now, there you are changing the subject radically.  This use of a
> keyword has nothing to do with keyword arguments.  And no, no such use
> of a keyword in Emacs "should inspire TERROR" in anyone.  No more than
> use of `t' or `nil' or `42' should inspire terror.

Yes more.

Consider:  (load  file nil t nil t)
vs.        (load file nil :noerror nil :nosuffix)

Casual reading of the later let the human programmer think that loading
the file will be done without signaling errors and without suffix.

Casual reading of the former cannot be done: you have to refer to the
documentation to understand what is meant.

Of course, we could agree that the problem here is casual reading.
But then why don't we obfuscate all the symbol names before reading
programs?



> OK, so your point is that *IF* the function were a COMMON Lisp function,
> and *IF* it had defined keyword arguments (or accepted arbitrary keyword
> args, i.e., used `&allow-other-keys`), and *IF* one of those defined
> keyword arguments were `:noerror' (or `&allow-other-keys` were present)
> *THEN* one might expect `:noerror' to be followed by the keyword value
> to pass, and SO someone might be confused to see `:noerror' not be so
> followed.

My point was that &key arguments are more difficult to use in a
misleading way for casual readers than &optional arguments.  Since emacs
lisp doesn't have &key arguments (unless you (require 'cl) and use
defun*), I switched to Common Lisp as a good example.

&allow-other-keys would be proeminently written in the function lambda
list, or :allow-other-keys t would clearly appear in the argument list,
so no casual reading would overlook it.



> […]
> Your uninspired terror is a bogeyman.

I think you've not considered closely enough my other example, the one
written in emacs lisp:

>>       (load file nil :noerror nil :nosuffix)

Agreed, it's shorter than the CL example.  It's hard to denote side boxes
in ASCII (I could have tried some ascii art).



Considering alternative languages with alternative solutions put things
in perspective.  


> Even in Common Lisp, a keyword is just a symbol (in package `keyword')
> whose name starts with a colon (`:') and that evaluates to itself
> (i.e., has a constant value).

Well, no. In CL the name of keyword symbols doesn't start (usually) with
a colon:

  #+common-lisp (symbol-name :hello) -> "HELLO"
  #+emacs-lisp  (symbol-name :hello) -> ":hello"

> […]


>> But with optional arguments, the programmer must ensure that the
>> parameter are given in the right order, and using keywords for true
>> booleans may confuse this, and impact a different meaning to the
>> programmer than to the compiler.  Terror should ensue.
>
> Certainly someone using keywords in Common Lisp needs to know how
> they are used as keyword parameters.  But knowing that, there is no
> confusion.  Keyword arguments are handled only after all specifiers
> of optional parameters have been processed.

Yes.  And notably, it's considered a design error to mix &optional with
&key or &rest.  There are only two functions in CL that do, and only for
historical and legacy compatibility reasons.


> And among the keyword arguments there is no significant order when
> keywords are present.
>
> In sum:
>
> 1. This is Emacs Lisp, which has no keyword parameters (no `&key').

It has, with (require 'cl) (defun* …).



> 2. Even in Common Lisp, keywords are sometimes used simply as
> convenient constants.  As a Boolean Lisp value, for example, they
> can be more mnemonic than just `t'.

Yes, but since we don't ostracize the CL package when we write Common
Lisp programs, we do use &key instead of &optional with kewords.


> 3. There is no ambiguity here, for either Emacs Lisp or Common Lisp.
> But yes, if someone is unclear about keywords then s?he could be
> confused.

No argument here.  The problem is not ambiguity, it's casual reading by
a human processor, vs. precise interpretation by a compiler (or
attentive programmer).


> 4. Since there are NO keyword parameters in Emacs Lisp, bringing
> them into this discussion creates, instead of removes, confusion.

Extends the horizons and propose a would be welcome evolution.


> A keyword passed to an Emacs Lisp function NEVER introduces a
> keyword-parameter value.

And therefore always may induce the programmer in error by its name,
when only its boolean value was expected, (or help the programmer
understand what the boolean value means, when the name matches its
meaning).  Which is all the point of the original question.


>   It is ALWAYS simply a constant value passed
> as an ordinary (non-keyword) argument.
>
> 5. All of that said, I personally tend to use `'NOERROR' in a context
> like this, instead of `:noerror' or `:NOERROR'.  I tend to use
> uppercase, and I tend to use the same name that occurs for the formal
> parameter in the doc string (but not always, if something better
> occurs to me).

That may give a hint to the reader, but can still mislead in case of
error.


> Your main answer is well put, however: all that matters in this
> particular case is that a non-nil value is passed, and for that
> purpose `:noerror' is as good as any other non-nil value.


-- 
__Pascal Bourguignon__
http://www.informatimago.com/

RE: What does ":noerror" do?

[Drew Adams]

> Consider:  (load  file nil t nil t)
> vs.        (load file nil :noerror nil :nosuffix)
> 
> Casual reading of the later let the human programmer think that
> loading the file will be done without signaling errors and without
> suffix.
> 
> Casual reading of the former cannot be done: you have to refer to
> the documentation to understand what is meant.

Using perverse naming, one can mislead a reader.  So what?  Is that a
reason not to try to use names to help readers?  With that logic, why
not name all functions and variables just `a',`b',...`aa',`bb',...?

> Of course, we could agree that the problem here is casual reading.

No.  The real problem is perverse writing.  Whoever writes :noerror
to stand for parameter NOMESSAGE and :nosuffix to stand for parameter
MUST-SUFFIX is the problem.  Even an attentive reader can be thrown
off by perverse naming.

Yes, of course such a writing mistake could be just that: a mistake
(an extra first nil, for instance).  That's no different from other
coding or commenting mistakes.

> But then why don't we obfuscate all the symbol names before reading
> programs?

Indeed.  Why don't we add misleading comments everywhere and rename
all functions and parameters perversely, to confuse readers of even
correct code?  Can you guess the answer?  That's the point: use names
to help, not to hinder.

> My point was that &key arguments are more difficult to use in a
> misleading way for casual readers than &optional arguments.

I don't think you said anything of the kind.  And if you did, it is
off-topic.  No one suggested that &optional args are more difficult
to use in a misleading way for casual readers than are &key args.
Nothing of the kind.  You brought &key into this.

And Emacs Lisp has no &key.  And the day that we add &key to Emacs
Lisp you can be sure that it will be well documented, just as in
Common Lisp.

> Since emacs lisp doesn't have &key arguments (unless you (require
> 'cl) and use defun*), I switched to Common Lisp as a good example.
> 
> &allow-other-keys would be proeminently written in the function
> lambda list, or :allow-other-keys t would clearly appear in the
> argument list, so no casual reading would overlook it.

That's just what I said.  In Common Lisp there is no confusion
between a keyword parameter and a non-keyword parameter whose
argument value is a keyword.  No confusion in the spec and no
confusion (that I've seen) in use (i.e., users).

> > Even in Common Lisp, a keyword is just a symbol (in package
> > `keyword') whose name starts with a colon (`:') and that
> > evaluates to itself (i.e., has a constant value).
> 
> Well, no. In CL the name of keyword symbols doesn't start (usually)
> with a colon:
>   #+common-lisp (symbol-name :hello) -> "HELLO"
>   #+emacs-lisp  (symbol-name :hello) -> ":hello"

You are nitpicking, and it's not pertinent to the discussion.  But
you are correct in pointing this out.  Emacs Lisp has no keyword
package (it has no packages), and it has no exact equivalent of
Common Lisp keywords.  But this is not particularly relevant here
(Subject: `What does ":noerror" do?').

Yes, I should have said "whose name is immediately preceded by a
colon", or some such, instead of "whose name starts with a colon".
And to be very precise I would have needed to write a bit more or
even quote from the standard.  But it's not the point.

The point I made here was to repeat that a keyword is a symbol that
evaluates to itself.  And that in Common Lisp, too, keywords are
sometimes used for just that purpose: as a constant symbol.  Keyword
parameters are one special use of Common Lisp keywords - and they are 
irrelevant here.

> > Certainly someone using keywords in Common Lisp needs to know how
> > they are used as keyword parameters.  But knowing that, there is
> > no confusion.  Keyword arguments are handled only after all
> > specifiers of optional parameters have been processed.
> 
> Yes.  And notably, it's considered a design error to mix &optional
> with &key or &rest.

"It's considered."  I guess you mean that you consider it a flaw in
the design of Common Lisp.

> There are only two functions in CL that do, and only for historical
> and legacy compatibility reasons.

There might be only two *predefined* Common Lisp functions that do so.
But this feature was consciously and deliberately made part of the 
language.  And as a result there are now certainly *lots* of functions
that do so.  The "flawed" designers were very careful about how they
specified this feature, the relation between &key and &rest etc.
They did it on purpose.

But again, this is not pertinent.  The point was that (a) there is
no need to know about Common Lisp keyword parameters when using
Emacs Lisp and reading its doc, and (b) even for Common Lisp users
there is no such confusion as you introduced, between keyword
parameters and other uses of keywords.  It's a non-problem, and
is anyway irrelevant to the OP's question.

> > 1. This is Emacs Lisp, which has no keyword parameters (no
> >    `&key').
> 
> It has, with (require 'cl) (defun* …).

In that case, see the Emacs Lisp doc for library CL.  You will find
there _zero_ specification/description/explanation of any of this.
The Emacs doc simply refers you to the Common Lisp doc.  E.g., for
`defun*':

  Like normal `defun', except ARGLIST allows full Common Lisp
  conventions, and BODY is implicitly surrounded by
  (cl-block NAME ...)

Stick to the topic, please.  There is nothing in the problem as
stated that justifies bringing in Common-Lisp keyword parameters
and thus adding more confusion.

The question was about Emacs-Lisp function `load' and its use in
`(load "emacspeak-loader" :noerror)', which was from this post:
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00256.html
I see nothing there about using cl.el.

It is true that that code was in turn for installing EmacsSpeak,
which itself uses cl.el.  However, grepping the EmacsSpeak sources
indicates that they too apparently make no use of `&key'.

> > 2. Even in Common Lisp, keywords are sometimes used simply as
> > convenient constants.  As a Boolean Lisp value, for example, they
> > can be more mnemonic than just `t'.
> 
> Yes, but since we don't ostracize the CL package when we write
> Common Lisp programs, we do use &key instead of &optional with
> kewords.

Irrelevant to the OP example posed.  You introduced extraneous
possible confusion - a bogeyman "TERROR".

The confusion in the OP question was about using a keyword as a
constant argument value.  The OP understood that this was just a
constant that is equivalent, as a Boolean value, to passing a quoted
symbol `'NOERROR'.  He was asking whether he might be missing
something, because he "could't find this kind of usage in lispref."

We clarified "this kind of usage" (i.e., confirmed that he in fact
understood correctly).  We probably should have also pointed him to
(elisp)`Constant Variables', but it seemed like he was already
pretty clear about it.

The point is that he was not asking about Common Lisp (or cl.el)
keyword parameters.  His question was whether using `:noerror' here
was perhaps something special, somehow essentially different from
just using `'NOERROR' or `t'.

He apparently already thought not, but wanted to be sure he wasn't
missing something.  And he wasn't.  He certainly wasn't missing,
and didn't need, additional possible confusion wrt Common Lisp
keyword parameters.
 
> > 4. Since there are NO keyword parameters in Emacs Lisp, bringing
> > them into this discussion creates, instead of removes, confusion.
> 
> Extends the horizons and propose a would be welcome evolution.

Off-topic and confusing, IMO.  If you want to propose adding keyword
parameters to Emacs Lisp, a new thread is the right place to do that,
and preferably in emacs-devel@gnu.org.

FWIW, I, for one, am favorable to the idea.  And I believe that RMS
is still opposed.  Whether the current maintainer would be in favor,
and if so whether someone would volunteer to implement it, remain
to be seen.

> > A keyword passed to an Emacs Lisp function NEVER introduces a
> > keyword-parameter value.
> 
> And therefore always may induce the programmer in error by its name,
> when only its boolean value was expected, (or help the programmer
> understand what the boolean value means, when the name matches its
> meaning).  Which is all the point of the original question.

Yes.  That is the point.  Good use of names can lead; bad use can
mislead.
 
> > 5. All of that said, I personally tend to use `'NOERROR' in a
> > context like this, instead of `:noerror' or `:NOERROR'.  I tend
> > to use uppercase, and I tend to use the same name that occurs for
> > the formal parameter in the doc string (but not always, if
> > something better occurs to me).
> 
> That may give a hint to the reader, but can still mislead in case of
> error.

Yes, if a writer uses names badly s?he can mislead instead of lead
readers.  We generally do our best to help.

In my case, I add such reminders first of all for myself: the writer
is also a reader.  It is much quicker (for me) to read something with
such a reminder than it is to hit `C-h f' and remind myself of a
function signature that way.  (I turn off `eldoc-mode' most of the
time.)

And if I mislead myself (it can happen) by misnaming or mistyping
then, well, I mislead myself - until I fix it.

I will add an obvious point: such named Boolean arguments are more
useful when there are many possible arguments, some of which are
Boolean, some of which are optional, and some of which are not used
often.  It is particularly in such cases that I tend to start naming
Boolean arguments, to keep things straight when I read.

This is really no different from using a comment.  If the particular
non-nil value makes no difference, then giving it a name serves only
as commentary/doc.  Commentary & doc can be good or bad.  The
possibility of bad help is not a reason not to help.

Re: What does ":noerror" do?

[Xue Fuqiao]

On Mon, Oct 14, 2013 at 12:27 AM, Drew Adams <drew.adams@oracle.com> wrote:
> His question was whether using `:noerror' here was perhaps something
> special, somehow essentially different from just using `'NOERROR' or
> `t'.

Yes, that's exactly what I mean.  Actually, I often use keywords (e.g.,
‘:group’, ‘:link’, and ‘:version’) and symbols-for-boolean-values (such
as 'noerror) in my Emacs Lisp code, but I have never combined them
together.  Thanks again for your info.

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/