bug#15447: (quail-help "korean-hangul") generates errors.

bug#15447: (quail-help "korean-hangul") generates errors.

[crocket]

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

The error trace is shown below.

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  quail-help("korean-hangul")
  eval((quail-help "korean-hangul") nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)
  recursive-edit()
  debug(error (wrong-type-argument char-or-string-p nil))
  quail-help("korean-hangul")
  eval((quail-help "korean-hangul") nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)
  recursive-edit()
  debug(error (void-function quail-help))
  (quail-help "korean-hangul")
  eval((quail-help "korean-hangul") nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)
  recursive-edit()
  debug(error (void-function quail-help))
  (quail-help (quote korean-hangul))
  eval((quail-help (quote korean-hangul)) nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)

[-- Attachment #2: Type: text/html, Size: 1502 bytes --]

bug#15447: (quail-help "korean-hangul") generates errors.

[Eli Zaretskii]

> Date: Sun, 22 Sep 2013 18:53:25 +0900
> From: crocket <crockabiscuit@gmail.com>
> 
> The error trace is shown below.
> 
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>   quail-help("korean-hangul")

quail-help gives help on quail _packages_, and korean-hangul is not a
package, it's an input method.

Try this instead:

  C-u C-\ korean-hanja RET
  C-\
  M-: (quail-help "korean-hanja") RET

This works because korean-hanja is a Leim package.

bug#15447: (quail-help "korean-hangul") generates errors.

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> Date: Wed, 25 Sep 2013 05:18:49 +0900
> From: crocket <crockabiscuit@gmail.com>
> 
> So, is it not a bug?

I don't think it is a bug, although it would be nicer if instead of
signaling an error Emacs would say something like "unknown package:
FOO".

bug#15447: (quail-help "korean-hangul") generates errors.

[Stefan Monnier]

>> So, is it not a bug?
> I don't think it is a bug, although it would be nicer if instead of
> signaling an error Emacs would say something like "unknown package:
> FOO".

I guess it also depends on how we end up calling quail-help.
After all, the user is not expected to type M-: (quail-help "foobar") RET.


        Stefan

bug#15447: (quail-help "korean-hangul") generates errors.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: crocket <crockabiscuit@gmail.com>, 15447@debbugs.gnu.org
> Date: Tue, 24 Sep 2013 18:18:44 -0400
> 
> >> So, is it not a bug?
> > I don't think it is a bug, although it would be nicer if instead of
> > signaling an error Emacs would say something like "unknown package:
> > FOO".
> 
> I guess it also depends on how we end up calling quail-help.
> After all, the user is not expected to type M-: (quail-help "foobar") RET.

It's a command, but invoking it interactively yields the same
behavior.  You need to have activated an input method that loads some
quail package, before invoking this command, in order to have a help.
korean-hangul doesn't load any quail package, so the command throws an
error.

So I still think a more human-readable error message is in order,
although when invoked interactively the package name is not given, so
some other wording is in order.

It looks like quail-help was designed to be called only by "C-h C-\",
where it behaves reasonably, but since it's a command, it perhaps
should have some minimal harness for when it is invoked by users
directly.

bug#15447: (quail-help "korean-hangul") generates errors.

[Kenichi Handa]

In article <83li2lh2w1.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> It looks like quail-help was designed to be called only by "C-h C-\",
> where it behaves reasonably, but since it's a command, it perhaps
> should have some minimal harness for when it is invoked by users
> directly.

If it is ok to break a subtle backward compatibility here,
let's make quail-help not a command.  It had to be a
command when I first implemented it, but now it doesn't have
to be.  It is now called from describe-current-input-method
by funcall.

---
Kenichi Handa
handa@gnu.org

bug#15447: (quail-help "korean-hangul") generates errors.

[Stefan Monnier]

> If it is ok to break a subtle backward compatibility here,
> let's make quail-help not a command.

Fine by me,


        Stefan

bug#15447: (quail-help "korean-hangul") generates errors.

[Kenichi Handa]

In article <jwv7ge4x229.fsf-monnier+emacsbugs@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > If it is ok to break a subtle backward compatibility here,
> > let's make quail-help not a command.

> Fine by me,

I've just committed that change.

---
Kenichi Handa
handa@gnu.org

bug#15447: (quail-help "korean-hangul") generates errors.

[Kenichi Handa]

In article <CAL0=0H3qh1xfncjnfH92TZm5UCXVCSBouyaVe1E=QciLLD-Z-Q@mail.gmail.com>, crocket <crockabiscuit@gmail.com> writes:

> The error trace is shown below.

> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>   quail-help("korean-hangul")

As these input methods are not "quail" input methods:
  korean-hangul, korean-hangul3f, korean-hangul390, korean-hangul3,
  ucs
quail-help doesn't work for them.

If you want to describe those input methods, do:
  (describe-input-method "korean-hangul")
or, type "C-h C-\ korean hangul RET".

---
Kenichi Handa
handa@gnu.org