Input method or help feature needed

Input method or help feature needed

[Richard Stallman]

Once in a while I want to enter some character that I know exists in
Unicode, though I know nothing about where to find it.  Today it was
the Turkish i without dot.

It is not easy to find how to enter the character you want.
Can anyone develop a way to make it easier?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Thu, 17 Feb 2011 14:14:27 -0500
> From: Richard Stallman <rms@gnu.org>
> 
> Once in a while I want to enter some character that I know exists in
> Unicode, though I know nothing about where to find it.  Today it was
> the Turkish i without dot.
> 
> It is not easy to find how to enter the character you want.
> Can anyone develop a way to make it easier?

Would it be okay to have an apropos-style command that will find
matches in the list of Unicode names of characters created by
ucs-names?

This would allow you to find what you wanted if you know that the name
of the character has "dotless" as its substring.

If that's not what you had in mind, please tell more about the desired
feature.

Re: Input method or help feature needed

[Stephen Berman]

On Thu, 17 Feb 2011 21:27:45 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Thu, 17 Feb 2011 14:14:27 -0500
>> From: Richard Stallman <rms@gnu.org>
>> 
>> Once in a while I want to enter some character that I know exists in
>> Unicode, though I know nothing about where to find it.  Today it was
>> the Turkish i without dot.
>> 
>> It is not easy to find how to enter the character you want.
>> Can anyone develop a way to make it easier?
>
> Would it be okay to have an apropos-style command that will find
> matches in the list of Unicode names of characters created by
> ucs-names?
>
> This would allow you to find what you wanted if you know that the name
> of the character has "dotless" as its substring.

The ucs-insert command already does this: typing

C-x 8 RET * dotless TAB TAB

brings up a completions buffer containing all unicode character names
matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.

Steve Berman

Re: Input method or help feature needed

[Harald Hanche-Olsen]

[Stephen Berman <stephen.berman@gmx.net> (2011-02-17 19:52:06 UTC)]

> The ucs-insert command already does this: typing
> 
> C-x 8 RET * dotless TAB TAB
> 
> brings up a completions buffer containing all unicode character names
> matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.

But I don't think it is obvious from the documentation that the tab
completion recognizes wildcards. Starting from C-h k C-x 8 RET and
following a link we are led to the docstring for read-char-by-name,
which only says

  You can type a few of first letters of the Unicode name and use
  completion.

Adding a note about wildcards to that docstring would be helpful?
After a look at the source, I suppose the wildcard feature is provided
by completing-read, but I certainly didn't have a clue about that
until now.

- Harald

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Thu, 17 Feb 2011 21:24:15 +0100 (CET)
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> 
> [Stephen Berman <stephen.berman@gmx.net> (2011-02-17 19:52:06 UTC)]
> 
> > The ucs-insert command already does this: typing
> > 
> > C-x 8 RET * dotless TAB TAB
> > 
> > brings up a completions buffer containing all unicode character names
> > matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.
> 
> But I don't think it is obvious from the documentation that the tab
> completion recognizes wildcards.

You are right, this seems to be undocumented.  Which is really bad,
IMO.

> Starting from C-h k C-x 8 RET and
> following a link we are led to the docstring for read-char-by-name,
> which only says
> 
>   You can type a few of first letters of the Unicode name and use
>   completion.
> 
> Adding a note about wildcards to that docstring would be helpful?
> After a look at the source, I suppose the wildcard feature is provided
> by completing-read, but I certainly didn't have a clue about that
> until now.

If someone tells which function implements this feature, I will add
the appropriate information to the affected doc strings.

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Fri, 18 Feb 2011 12:53:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Adding a note about wildcards to that docstring would be helpful?
> > After a look at the source, I suppose the wildcard feature is provided
> > by completing-read, but I certainly didn't have a clue about that
> > until now.
> 
> If someone tells which function implements this feature, I will add
> the appropriate information to the affected doc strings.

It seems to be a general feature of completion.  So I just added to
the doc string a note about that possibility, since in this case it
sounds important, due to the large number of potential completion
candidates if one just types TAB TAB with an empty minibuffer.

Re: Input method or help feature needed

[Ted Zlatanov]

On Fri, 18 Feb 2011 17:46:51 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> Date: Fri, 18 Feb 2011 12:53:24 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > Adding a note about wildcards to that docstring would be helpful?
>> > After a look at the source, I suppose the wildcard feature is provided
>> > by completing-read, but I certainly didn't have a clue about that
>> > until now.
>> 
>> If someone tells which function implements this feature, I will add
>> the appropriate information to the affected doc strings.

EZ> It seems to be a general feature of completion.  So I just added to
EZ> the doc string a note about that possibility, since in this case it
EZ> sounds important, due to the large number of potential completion
EZ> candidates if one just types TAB TAB with an empty minibuffer.

For this specific completion (by character name), wouldn't it be nice to
also show the glyph as part of the completion string?  It shouldn't be
required to complete the string, though.

In general I find *browsing* the Unicode charts very rewarding, as
opposed to looking for something specific.  As Werner Lemberg suggested:

WL> An interface which resembles these tables could be helpful:
WL> http://www.unicode.org/charts/collation/

...although that specific interface doesn't show the character names.

Ted

Re: Input method or help feature needed

[Stefan Monnier]

> The ucs-insert command already does this: typing

> C-x 8 RET * dotless TAB TAB

> brings up a completions buffer containing all unicode character names
> matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.

Maybe C-x 8 RET should be changed to use the `substring' completion
style, so the * is not needed.


        Stefan

Re: Input method or help feature needed

[Richard Stallman]

    C-x 8 RET * dotless TAB TAB

    brings up a completions buffer containing all unicode character names
    matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.

That is trying to do this job, but using completion as the interface
is inconvenient.  I don't want to have to navigate that buffer by
typing TAB.  I am not sure what the * does, and I would never have
thought of typing it.

It takes a long time for the buffer to appear.  Perhaps that is
inevitable, but having it happen in the middle of things was
confusing.

C-x 8 RET TAB generated a buffer listing all these characters,
but it took almost 30 seconds, and did not make the buffer current.
Is there a faster way to generate such a list?  A command to generate
that list and make it current -- not via the completion mechanism -- would
be much more convenient.

I'd rather have it ordered by languages than alphabetically.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Fri, 18 Feb 2011 16:24:50 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     C-x 8 RET * dotless TAB TAB
> 
>     brings up a completions buffer containing all unicode character names
>     matching "DOTLESS" -- including LATIN SMALL LETTER DOTLESS I.
> 
> That is trying to do this job, but using completion as the interface
> is inconvenient.  I don't want to have to navigate that buffer by
> typing TAB.  I am not sure what the * does, and I would never have
> thought of typing it.

Yes, the * feature is hard to discover.  It was only documented in the
Emacs manual, and is hardly intuitive for Emacs old-timers such as
myself.

> It takes a long time for the buffer to appear.  Perhaps that is
> inevitable, but having it happen in the middle of things was
> confusing.

There are many characters in the Unicode database, so slow machines
will take time generating the list, especially if that's the first
time you are invoking "C-x 8 RET".

> Is there a faster way to generate such a list?

Try "M-x list-character-sets", where you could type RET on the
unicode-bmp charset and have it displayed.  If you already know that
there's a charset named "unicode-bmp", you could use "M-x
list-charset-chars" instead.

We should probably enhance list-charset-chars with at least the
following 3 features:

  . Show the Unicode name of a character in a tooltip or by typing RET
    on its image;

  . Show input methods that support a character;

  . Allow to insert a character at point in another buffer (although
    M-w followed by C-y will do as a poor-man replacement).

> I'd rather have it ordered by languages than alphabetically.

Unicode character names already are ordered by languages (well,
almost: they are ordered by _scripts_, so only single-language scripts
will give you exactly what you want; there's no "turkish", for
example, only "latin").

Re: Input method or help feature needed

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> There are many characters in the Unicode database, so slow machines
> will take time generating the list, especially if that's the first
> time you are invoking "C-x 8 RET".

There are many pixels on the screen, and redrawing still finishes in
reasonable time.  Computers have become faster since the seventies.

If this is a general problem of completion, tackling it will speed up a
lot of user interaction.  If it is a problem of getting the data (rather
than turning it into a form fit for completion), it still might be
possible to better batch that process.

While "there are many characters" is likely an indicator that behavior
is not quadratic or worse, that does not mean that it is beyond
improvement.

-- 
David Kastrup

Re: Input method or help feature needed

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> There are many characters in the Unicode database, so slow machines
>> will take time generating the list, especially if that's the first
>> time you are invoking "C-x 8 RET".
>
> There are many pixels on the screen, and redrawing still finishes in
> reasonable time.  Computers have become faster since the seventies.

I think Richard uses a machine that's an order of magnitude slower than
average...

(it takes about 1s to generate the unicode completion list on the
machines I use, which are sort of "middle of the road")

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: Input method or help feature needed

[Richard Stallman]

    If this is a general problem of completion, tackling it will speed up a
    lot of user interaction.  If it is a problem of getting the data (rather
    than turning it into a form fit for completion), it still might be
    possible to better batch that process.

I suspect that generating the data in a buffer without sorting it
could be done much faster than what the completion code does.  For
instance, it spends a lot of time in GC, but this task should not
require any consing.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Richard Stallman]

    Try "M-x list-character-sets", where you could type RET on the
    unicode-bmp charset and have it displayed.

I did not think of that, but I tried that now.  The list included
this:

    latin-iso8859-1					1  96 A
    latin-iso8859-10				1  96 V
    latin-iso8859-13				1  96 Y
    latin-iso8859-14				1  96 _
    latin-iso8859-15				1  96 b
    latin-iso8859-16				1  96 f
    latin-iso8859-2					1  96 B
    latin-iso8859-3					1  96 C
    latin-iso8859-4					1  96 D
    latin-iso8859-9					1  96 M

It is not obvious which of these I should look in.

This feature would be more useful if it listed the main languages each
char set is meant for.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Sat, 19 Feb 2011 19:29:58 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: stephen.berman@gmx.net, emacs-devel@gnu.org
> 
>     Try "M-x list-character-sets", where you could type RET on the
>     unicode-bmp charset and have it displayed.
> 
> I did not think of that, but I tried that now.  The list included
> this:
> 
>     latin-iso8859-1					1  96 A
>     latin-iso8859-10				1  96 V
>     latin-iso8859-13				1  96 Y
>     latin-iso8859-14				1  96 _
>     latin-iso8859-15				1  96 b
>     latin-iso8859-16				1  96 f
>     latin-iso8859-2					1  96 B
>     latin-iso8859-3					1  96 C
>     latin-iso8859-4					1  96 D
>     latin-iso8859-9					1  96 M
> 
> It is not obvious which of these I should look in.

I'd try unicode-bmp.  Maybe we should have it at the front of the
list.

Re: Input method or help feature needed

[Richard Stallman]

    I'd try unicode-bmp.  Maybe we should have it at the front of the
    list.

That might be an improvement.  But we really should design an easy and
natural interface for people to choose and use unicode characters.  We
should not urge users to use other features that were designed for
different purposes.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Richard Stallman]

    Would it be okay to have an apropos-style command that will find
    matches in the list of Unicode names of characters created by
    ucs-names?

I think that would be very good.

Another nice interface would be a list of languages, each with a list of
its various non-ASCII characters for you to copy.

Another nice interface would be a list of Unicode code pages, each one
prepared to generate a buffer of all the characters in that code page
using a simple loop.

It would be nice to offer all of them.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Justin Lilly]

Not built-in, but you might consider

http://sigusr2.net/2010/Nov/04/unipoint-minor-mode-for-mathematical-unicode.html
http://xahlee.org/emacs/emacs_n_unicode.html

including

C-x 8 C-h  for a small table of possible unicode characters.
xub-mode http://xahlee.org/emacs/unicode-browser.html

Hope it helps,
  -justin

On Thu, Feb 17, 2011 at 2:14 PM, Richard Stallman <rms@gnu.org> wrote:
> Once in a while I want to enter some character that I know exists in
> Unicode, though I know nothing about where to find it.  Today it was
> the Turkish i without dot.
>
> It is not easy to find how to enter the character you want.
> Can anyone develop a way to make it easier?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org, www.gnu.org
>
>

Re: Input method or help feature needed

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

Hello Richard,

> Once in a while I want to enter some character that I know exists in
> Unicode, though I know nothing about where to find it.  Today it was
> the Turkish i without dot.
>
> It is not easy to find how to enter the character you want.
> Can anyone develop a way to make it easier?

I think it already is easy.  In the buffer with the Turkish text, do

  M-x set-input-method RET turkish-postfix RET

and then

  M-x describe-input-method RET RET

which shows this *Help* buffer:

,----
| Input method: turkish-postfix (mode line indicator:TR<)
| 
| Turkish (Türkçe) input method with postfix modifiers.
| turkish-latin-3-postfix is an obsolete alias for turkish-postfix.
| 
| Note for I, ı, İ, i.
| 
| A^ -> Â
| C, -> Ç
| G^ -> Ğ
| I  -> I
| i  -> ı
| I. -> İ
| i. -> i
| O" -> Ö
| S, -> Ş
| U" -> Ü
| U^ -> Û
| 
| Doubling the postfix separates the letter and postfix: e.g. a^^ -> a^
| 
| 
| KEY SEQUENCE
| ------------
| You can input characters by the following key sequences:
| key char  [type a key sequence to insert the corresponding character]
| --- ---- --- ---- --- ---- --- ---- --- ---- --- ---- --- ---- --- ----
| A^  Â	 G^  Ğ	  O"  Ö	   U"  Ü    a^	â    g^	 ğ    s,  ş    u^  û
| C,  Ç	 I.  İ	  S,  Ş	   U^  Û    c,	ç    o"	 ö    u"  ü
| 
| key character(s)  [type a key (sequence) and select one from the list]
| --- ------------
| i   ı i
`----

Bye,
Tassilo

Re: Input method or help feature needed

[Richard Stallman]

    I think it already is easy.  In the buffer with the Turkish text, do

      M-x set-input-method RET turkish-postfix RET

    and then

It is inconvenient to select an input method just to look at the
documentation.  I was not sure what input method to consider.
And I did not know that the description would be this detailed.

I started paging through the output of list-input-methods and
eventually found what I wanted under Latin-5.  But that is not a
convenient interface.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Fri, 18 Feb 2011 16:24:45 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     I think it already is easy.  In the buffer with the Turkish text, do
> 
>       M-x set-input-method RET turkish-postfix RET
> 
>     and then
> 
> It is inconvenient to select an input method just to look at the
> documentation.

You don't need to select it, you can have its documentation shown with
"C-h I" or "C-h C-\".

This requires that you at least know one language where the character
is used, and that Emacs has an input method whose name includes that
language name.

> And I did not know that the description would be this detailed.

Every input method should show at least the most popular characters, it
produces, if not all of them.  If it doesn't, that's a bug.

Re: Input method or help feature needed

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Every input method should show at least the most popular characters, it
 > produces, if not all of them.  If it doesn't, that's a bug.

Asian ideographs and Hangul excepted, of course.

Re: Input method or help feature needed

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > Every input method should show at least the most popular characters, it
>  > produces, if not all of them.  If it doesn't, that's a bug.
>
> Asian ideographs and Hangul excepted, of course.

A keyboard graphic for Hangul input methods would be veryyy helpful...

-Miles

-- 
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.

Re: Input method or help feature needed

[Kevin Rodgers]

On 2/18/11 2:24 PM, Richard Stallman wrote:
>      I think it already is easy.  In the buffer with the Turkish text, do
>
>        M-x set-input-method RET turkish-postfix RET
>
>      and then
>
> It is inconvenient to select an input method just to look at the
> documentation.  I was not sure what input method to consider.
> And I did not know that the description would be this detailed.

You don't have to: C-h I (aka M-x describe-input-method) provides completion.

If you know the language of the text you're trying to enter, it probably has
an input method.  So e.g. `C-h I turk ?' makes it easy to complete turkish-
postfix, and Bob's your uncle.

> I started paging through the output of list-input-methods and
> eventually found what I wanted under Latin-5.  But that is not a
> convenient interface.

Yes, and who can remember what languages each numbered ISO-8859/Latin character
set is for?

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Input method or help feature needed

[Paul Eggert]

On 02/17/2011 11:14 AM, Richard Stallman wrote:

> Can anyone develop a way to make it easier?

For ideas about this, I suggest looking at Wikipedia's
interface for adding unusual characters.  I find it much
easier to use Wikipedia to add a character that I don't
know, than to use Emacs.  It's easier than using
ucs-insert (which requires that I know the Unicode name,
which I typically don't) or the Turkish input method
(which I don't know how to use and lack time to learn).

For example, to add a dotless i to the start of the
Wikipedia talk page on Emacs, you visit its "Edit" page
<http://en.wikipedia.org/w/index.php?title=Talk:Emacs&action=edit>
and do the following:

   Press the "Insert" button.  Select Latin; it displays
   lots of Latin characters.  Press the dotless i character.

That's much easier than anything Emacs offers now.
Perhaps someone who's an expert on Emacs UI code could
do something similar (or even better) for Emacs.

Re: Input method or help feature needed

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Once in a while I want to enter some character that I know exists in
> Unicode, though I know nothing about where to find it.  Today it was
> the Turkish i without dot.
>
> It is not easy to find how to enter the character you want.
> Can anyone develop a way to make it easier?

The X11 compose feature actually has pretty easy to remember ways to
input such characters.  For example, the dotless i can be generated by
<Multi_key> <i> <.> (<Multi_key> is usually on Shift-RControl).

Andreas.

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

Re: Input method or help feature needed

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Once in a while I want to enter some character that I know exists in
>> Unicode, though I know nothing about where to find it.  Today it was
>> the Turkish i without dot.
>>
>> It is not easy to find how to enter the character you want.
>> Can anyone develop a way to make it easier?
>
> The X11 compose feature actually has pretty easy to remember ways to
> input such characters.  For example, the dotless i can be generated by
> <Multi_key> <i> <.> (<Multi_key> is usually on Shift-RControl).

Isn't that limited to a "common" set of characters in a single locale
though...?

I've tried a lot of these methods before, and the one that generally
seems to work best for obscure characters, and those I'm not used to,
is the "C-x RET * substring TAB" method.

Yeah you need to know or guess part of the name, but the unicode names
are reasonably well chosen, pretty regular, and all you need to know is
_part_ of it; once you can guess that, it's often easy to narrow the
number of choices enough to choose from the completion list...  (often
I'll guess a number of common terms for something, and get a hit after
2-3)

E.g. for dotless-i:  "C-x 8 RET * dotless i TAB" immediately narrows it
down to two choices; just "dotless" gives about 20.

-miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Input method or help feature needed

[Werner LEMBERG]

>>> It is not easy to find how to enter the character you want.
>>> Can anyone develop a way to make it easier?
>>
>> The X11 compose feature actually has pretty easy to remember ways
>> to input such characters.  For example, the dotless i can be
>> generated by <Multi_key> <i> <.> (<Multi_key> is usually on
>> Shift-RControl).
> 
> Isn't that limited to a "common" set of characters in a single
> locale though...?

An interface which resembles these tables could be helpful:

  http://www.unicode.org/charts/collation/


    Werner

Re: Input method or help feature needed

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 18, 2011 at 09:09:44AM +0900, Miles Bader wrote:

[partially enter Unicode name]

> Yeah you need to know or guess part of the name, but the unicode names
> are reasonably well chosen, pretty regular, and all you need to know is
> _part_ of it; once you can guess that, it's often easy to narrow the
> number of choices enough to choose from the completion list...  (often
> I'll guess a number of common terms for something, and get a hit after
> 2-3)

As an additional thought: this won't work for non-English speakers,
right?

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFNXi/QBcgs9XrR2kYRAmI6AJ9ljL2ncuq/UqUUDienKhH+q3AcmQCffTfz
/hGTMOH1ld9A5+/uDTvMD9g=
=ueDi
-----END PGP SIGNATURE-----

Re: Input method or help feature needed

[Miles Bader]

tomas@tuxteam.de writes:
>> Yeah you need to know or guess part of the name, but the unicode
>> names are reasonably well chosen, pretty regular, and all you need to
>> know is _part_ of it; once you can guess that, it's often easy to
>> narrow the number of choices enough to choose from the completion
>> list...  (often I'll guess a number of common terms for something,
>> and get a hit after 2-3)
>
> As an additional thought: this won't work for non-English speakers,
> right?

I'd think of it like a programming language -- it's nominally "English",
but of a rather limited and regular sort.

Can you think of any mechanism that both completely avoids naming and
covers the entire unicode space though?

Well... maybe "M-x list-charset-chars RET unicode-bmp RET"...

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: Input method or help feature needed

[Kenichi Handa]

In article <buomxltbuq8.fsf@dhlpc061.dev.necel.com>, Miles Bader <miles@gnu.org> writes:
> Well... maybe "M-x list-charset-chars RET unicode-bmp RET"...

I have an idea of M-x list-script-chars RET latin RET which
uses different presentation method for each script because
the best method depends on script.  I'll show it when I
finish the code.

---
Kenichi Handa
handa@m17n.org

Re: Input method or help feature needed

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 18, 2011 at 05:41:19PM +0900, Miles Bader wrote:
> tomas@tuxteam.de writes:

> > As an additional thought: this won't work for non-English speakers,
> > right?
> 
> I'd think of it like a programming language -- it's nominally "English",
> but of a rather limited and regular sort.

Kind of. Still, a non-English speaker is less likely to come up with a
construct like "DOTLESS", to keep to the example.

> Can you think of any mechanism that both completely avoids naming and
> covers the entire unicode space though?

You are completely right, that's hard (although this thread is producing
surprising ideas already). My reply wasn't meant as an objection to the
method proposed. Rather as a reminder: we're not done with that, and we
might need a whole bunch of interfaces, complementing each other.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFNYNBZBcgs9XrR2kYRAhCTAJ0Xmaivwf+4MJCEHGdtr2tsaNcgqACfQ+MJ
RA1Poe+z0ny4EjHQ5/P66/4=
=AU4a
-----END PGP SIGNATURE-----

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Sun, 20 Feb 2011 09:27:05 +0100
> From: tomas@tuxteam.de
> Cc: tomas@tuxteam.de, Andreas Schwab <schwab@linux-m68k.org>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, Feb 18, 2011 at 05:41:19PM +0900, Miles Bader wrote:
> > tomas@tuxteam.de writes:
> 
> > > As an additional thought: this won't work for non-English speakers,
> > > right?
> > 
> > I'd think of it like a programming language -- it's nominally "English",
> > but of a rather limited and regular sort.
> 
> Kind of. Still, a non-English speaker is less likely to come up with a
> construct like "DOTLESS", to keep to the example.

I don't understand what you have in mind, specifically.  Unicode
character names are defined in English only.  The only official
translation is into French (http://www.unicode.org/fr/), and even
there many links point back to the English site.  So anyone who looks
for a character by its name in practice must know the English name.

> > Can you think of any mechanism that both completely avoids naming and
> > covers the entire unicode space though?
> 
> You are completely right, that's hard (although this thread is producing
> surprising ideas already). My reply wasn't meant as an objection to the
> method proposed. Rather as a reminder: we're not done with that, and we
> might need a whole bunch of interfaces, complementing each other.

At least one interface that is based on character shapes (rather than
on their names) was mentioned in this thread.  So it doesn't sound
like we forgot something.

Re: Input method or help feature needed

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> At least one interface that is based on character shapes (rather than
> on their names) was mentioned in this thread.  So it doesn't sound
> like we forgot something.

<URL:http://detexify.kirelabs.org/classify.html> is an interesting
search interface for symbols expressable as TeX.

-- 
David Kastrup

Re: Input method or help feature needed

[Richard Stallman]

      So anyone who looks
    for a character by its name in practice must know the English name.

I grant that.  It is an additional reason why we want features for
finding unicode characters that don't depend on their names.

For instance, how about a feature that makes a buffer in which there
is a succession of pages, each page showing the characters of one
Unicode subgroup?  (Excluding Korean and Han characters and whatever
else ought to be excluded).


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Sun, 20 Feb 2011 16:01:19 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: tomas@tuxteam.de, emacs-devel@gnu.org
> 
> For instance, how about a feature that makes a buffer in which there
> is a succession of pages, each page showing the characters of one
> Unicode subgroup?

You mean, like "M-x list-charset-chars RET unicode-bmp RET"?

> (Excluding Korean and Han characters and whatever else ought to be
> excluded).

Why exclude them?

Re: Input method or help feature needed

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > (Excluding Korean and Han characters and whatever else ought to be
 > > excluded).
 > 
 > Why exclude them?

Because there are 11000 of the former and 21000 (and counting) of the
latter.  The Korean Hangul are precomposed in an algorithmic fashion
from about 70 components called "jamo".  It makes very little sense to
just have many pages when you can look up the jamo in smaller lists,
and drill down to exactly the Hangul you want.  Just as it should be
possible to type "i" and get a page of all characters related to "i"
including the Turkish dotless "i" and Greek iota, etc.

Similarly, the Han characters are organized by radical and stroke
count, and it should be possible to look at the (relatively) short
list of 214 radicals, then drill down to an approximate stroke count,
and then page up and down the stroke count.  There are non-radical
components as well, many of which even total Han illiterates would be
likely to recognize.  I don't know if these are listed in the Unicode
tables, but if so they could be combined with the radical and
(optionally) approximate stroke count to drastically prune the search
tree in 90% or more of practical cases.

However a simple list of Hangul or Hanzi would be rather painful to
use, not to mention that if you don't know how to say it (every Hangul
has an algorithmically constructed pronunciation), you're probably not
fluent enough in the language to easily pick the right character out
of an array of say 400 (20 x 20 seems like a reasonable size for a
"page" of characters).  The real differences are often subtle, not to
mention that many characters have several variant glyphs, and these
variations tend to confuse the non-native speaker.

A pure list in Unicode order for these characters is better than
*nothing*, true, but it's not really an acceptable answer to Richard's
requirement.

Re: Input method or help feature needed

[Richard Stallman]

    You mean, like "M-x list-charset-chars RET unicode-bmp RET"?

Yes, that seems quite useful.  It should have a name, such as
list-unicode-chars.

It also should be sped up.  It does a lot of GC; I would expect
that consing can be eliminated.

    > (Excluding Korean and Han characters and whatever else ought to be
    > excluded).

    Why exclude them?

For speed, and because they are not likely to be useful.

There could be a button at the end of the buffer
to add the Korean and Han characters to the buffer.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Kenichi Handa]

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

In article <E1PrGP9-0000NB-0m@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> For instance, how about a feature that makes a buffer in which there
> is a succession of pages, each page showing the characters of one
> Unicode subgroup?  (Excluding Korean and Han characters and whatever
> else ought to be excluded).

Attached is a sample implementation of `list-script-chars'.
----------------------------------------------------------------------
Display a list of characters belonging to SCRIPT.
The list is displayed in a buffer named "*Character List*".
In that buffer, the target characters are highlighted, and you
can copy each of them to kill ring by clicking them.
----------------------------------------------------------------------

Currently it has a special handler only for "latin".  For
ideographic characters, classifying characters by radical
and stroke number may be convenient.  For hangul,
classifying characters by "Choseong" may be convenient.  For
Indic and SEA scripts, categorizing characters by consonant,
dependent-vowel, independent-vowel, etc may be convenient.

It is easy to make it work as you wrote above when a user
enters null SCRIPT (or enters "all").

---
Kenichi Handa
handa@m17n.org


[-- Attachment #2: script.el --]
[-- Type: application/emacs-lisp, Size: 5301 bytes --]

Re: Input method or help feature needed

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: eliz@gnu.org, tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Mon, 21 Feb 2011 09:59:15 +0900
> 
> In article <E1PrGP9-0000NB-0m@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> 
> > For instance, how about a feature that makes a buffer in which there
> > is a succession of pages, each page showing the characters of one
> > Unicode subgroup?  (Excluding Korean and Han characters and whatever
> > else ought to be excluded).
> 
> Attached is a sample implementation of `list-script-chars'.
> ----------------------------------------------------------------------
> Display a list of characters belonging to SCRIPT.
> The list is displayed in a buffer named "*Character List*".
> In that buffer, the target characters are highlighted, and you
> can copy each of them to kill ring by clicking them.
> ----------------------------------------------------------------------

Instead of introducing yet another command, how about extending
list-charset-chars to include these features?  With the notable
exception of Latin scripts, the display looks similar, if not
identical, to list-charset-chars.

Btw, time to generate a buffer for large scripts, like han or hangul,
is quite long, as is the time for producing the list of script names
if I type `?' at the "Script:" prompt.

Re: Input method or help feature needed

[Kenichi Handa]

In article <E1PrPnD-0004tY-Gj@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > Attached is a sample implementation of `list-script-chars'.
> > ----------------------------------------------------------------------
> > Display a list of characters belonging to SCRIPT.
> > The list is displayed in a buffer named "*Character List*".
> > In that buffer, the target characters are highlighted, and you
> > can copy each of them to kill ring by clicking them.
> > ----------------------------------------------------------------------

> Instead of introducing yet another command, how about extending
> list-charset-chars to include these features?  With the notable
> exception of Latin scripts, the display looks similar, if not
> identical, to list-charset-chars.

The reason why the output is similar except for latin is
that I have implemented a special handler only for latin.
As I wrote, some other scripts (han, hangul, various Indic,
etc) should have their own handlers.

> Btw, time to generate a buffer for large scripts, like han or hangul,
> is quite long,

Sure.  That's another reason to have special handlers for
them.  For han, for instance, instead of generating the full
list at once, just showing radicals at first, then,
expanding each radical on mouse clicking, may be efficient.

Creating buttons for each character naively is also slow.
It may be good if there's a way to create a help-echo on the
fly.

> as is the time for producing the list of script names
> if I type `?' at the "Script:" prompt.

Really?  When I tested it, it was almost instant.

---
Kenichi Handa
handa@m17n.org

Re: Input method or help feature needed

[Miles Bader]

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

Kenichi Handa <handa@m17n.org> writes:
> Creating buttons for each character naively is also slow.
> It may be good if there's a way to create a help-echo on the
> fly.

Like the following?  (two patches, one for "lisp/button.el", the other
for your list-script-chars file)

-miles


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to allow button help-echo to be a function --]
[-- Type: text/x-diff, Size: 469 bytes --]

diff -up lisp/button.el.\~1\~ lisp/button.el
--- lisp/button.el.~1~	2011-01-31 12:33:51.000000000 +0900
+++ lisp/button.el	2011-02-21 17:17:40.408941730 +0900
@@ -463,6 +463,8 @@ Returns the button found."
     (if (null button)
 	(error (if wrap "No buttons!" "No more buttons"))
       (let ((msg (and display-message (button-get button 'help-echo))))
+	(when (functionp msg)
+	  (setq msg (funcall msg button)))
 	(when msg
 	  (message "%s" msg)))
       button)))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Patch for list-script-chars to use button function help-echo --]
[-- Type: text/x-diff, Size: 1256 bytes --]

diff -up /tmp/lsc.el.\~1\~ /tmp/lsc.el
--- /tmp/lsc.el.~1~	2011-02-21 17:22:14.214098588 +0900
+++ /tmp/lsc.el	2011-02-21 17:22:23.365735810 +0900
@@ -1,19 +1,19 @@
 (defvar list-script-chars-handler-alist nil)
 
 (define-button-type 'active-char
-  'face '(:background "gray")
+  'face '(:background "grey10")
   'action #'(lambda (button)
-	      (copy-region-as-kill (button-start button) (button-end button))))
+	      (copy-region-as-kill (button-start button) (button-end button)))
+  'help-echo #'(lambda (button)
+		 (let* ((char (char-after (button-start button)))
+			(name (get-char-code-property char 'name)))
+		   (format "U+%04X: %s" char name)))
+  'mouse-face (list :background "yellow"))
 
 (defun make-character-button (char)
   (let ((name (get-char-code-property char 'name)))
     (when name
-      (insert-text-button
-       (string char)
-       :type 'active-char
-       'help-echo (format "U+%04X: %s" char name)
-       ;; We must make this list each time to highlight only one character.
-       'mouse-face (list :background "yellow")))))
+      (insert-text-button (string char) :type 'active-char))))
 
 ;; List characters in RANGE in the current buffer assuming that the
 ;; window width is 80, and tab-width is set to 4.

[-- Attachment #4: Type: text/plain, Size: 65 bytes --]


-- 
Liberty, n. One of imagination's most precious possessions.

Re: Input method or help feature needed

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Mon, 21 Feb 2011 16:47:57 +0900
> 
> > Instead of introducing yet another command, how about extending
> > list-charset-chars to include these features?  With the notable
> > exception of Latin scripts, the display looks similar, if not
> > identical, to list-charset-chars.
> 
> The reason why the output is similar except for latin is
> that I have implemented a special handler only for latin.
> As I wrote, some other scripts (han, hangul, various Indic,
> etc) should have their own handlers.

Still, why have 2 commands instead of just one?  We could make it use
all these improvements and enhancements.

> > as is the time for producing the list of script names
> > if I type `?' at the "Script:" prompt.
> 
> Really?  When I tested it, it was almost instant.

It's slow only the first time.  Try in a fresh Emacs session.

Re: Input method or help feature needed

[Kenichi Handa]

In article <E1PrR8g-0000Um-Hl@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > The reason why the output is similar except for latin is
> > that I have implemented a special handler only for latin.
> > As I wrote, some other scripts (han, hangul, various Indic,
> > etc) should have their own handlers.

> Still, why have 2 commands instead of just one?  We could make it use
> all these improvements and enhancements.

(1) list-charset-chars lists characters with code-points of
    the specified charset, list-script-chars lists
    characters with Unicode code-points.

(2) These names are both charset and script, thus can't be
    distinguished just by names.
	lao, tibetan, ethiopic, symbol

(3) The name "list-charset-chars" is not suitable for what
    list-script-chars does.  If we are going to have just
    one command, the name should be, for instance,
    list-characters.

> > > as is the time for producing the list of script names
> > > if I type `?' at the "Script:" prompt.
> > 
> > Really?  When I tested it, it was almost instant.

> It's slow only the first time.  Try in a fresh Emacs session.

It's still instant with a fresh Emacs session in my
environment.  Actually, the completion list is created by:

(mapcar 'symbol-name (char-table-extra-slot char-script-table 0))

It shouldn't be that slow.  Could you investigate why it's
slow for you?

---
Kenichi Handa
handa@m17n.org

Re: Input method or help feature needed

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Mon, 21 Feb 2011 20:14:04 +0900
> 
> > Still, why have 2 commands instead of just one?  We could make it use
> > all these improvements and enhancements.
> 
> (1) list-charset-chars lists characters with code-points of
>     the specified charset, list-script-chars lists
>     characters with Unicode code-points.

We could show Unicode codepoints by default and charset codepoints
with "C-u".  I doubt that any user would care about the latter, but
Emacs maintainers might.

> (2) These names are both charset and script, thus can't be
>     distinguished just by names.
> 	lao, tibetan, ethiopic, symbol

Are the results different if you interpret these as scripts vs
charsets?  If not, we don't need to care about the issue.

Anyway, having both "charset" and "script" in two almost identical
commands just adds to confusion, for anyone but specialists in this
particular area.  I would guess that "script" is more widely known, so
I would use that by default.  Again, we could use "C-u C-u" or some
such to show charsets instead.  Or maybe show charsets automatically
if the user types a charset name.

> (3) The name "list-charset-chars" is not suitable for what
>     list-script-chars does.  If we are going to have just
>     one command, the name should be, for instance,
>     list-characters.

Fine with me, we could have an alias for backward compatibility.

> > > > as is the time for producing the list of script names
> > > > if I type `?' at the "Script:" prompt.
> > > 
> > > Really?  When I tested it, it was almost instant.
> 
> > It's slow only the first time.  Try in a fresh Emacs session.
> 
> It's still instant with a fresh Emacs session in my
> environment.  Actually, the completion list is created by:
> 
> (mapcar 'symbol-name (char-table-extra-slot char-script-table 0))
> 
> It shouldn't be that slow.  Could you investigate why it's
> slow for you?

I cannot reproduce this anymore, so it's probably something that was
related to what my machine was doing in the background at the time.
Sorry for the noise.

Re: Input method or help feature needed

[Kenichi Handa]

In article <E1PrUpB-00008E-Cn@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > (1) list-charset-chars lists characters with code-points of
> >     the specified charset, list-script-chars lists
> >     characters with Unicode code-points.

> We could show Unicode codepoints by default and charset codepoints
> with "C-u".  I doubt that any user would care about the latter, but
> Emacs maintainers might.

I believe that people who want to list characters of a
specic charset prefer characters ordered by the code-points
of that charset.  At least, when I do M-x list-charset-chars
RET japanese-jisx0208 RET, I do prefer characters
ordered by JISX0208 code points.

> > (2) These names are both charset and script, thus can't be
> >     distinguished just by names.
> > 	lao, tibetan, ethiopic, symbol

> Are the results different if you interpret these as scripts vs
> charsets?

Yes.

---
Kenichi Handa
handa@m17n.org

Re: Input method or help feature needed

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
>> We could show Unicode codepoints by default and charset codepoints
>> with "C-u".  I doubt that any user would care about the latter, but
>> Emacs maintainers might.
>
> I believe that people who want to list characters of a
> specic charset prefer characters ordered by the code-points
> of that charset.  At least, when I do M-x list-charset-chars
> RET japanese-jisx0208 RET, I do prefer characters
> ordered by JISX0208 code points.
>
>> > (2) These names are both charset and script, thus can't be
>> >     distinguished just by names.
>> > 	lao, tibetan, ethiopic, symbol
>
>> Are the results different if you interpret these as scripts vs
>> charsets?
>
> Yes.

It sounds like these really should be separate commands, but perhaps the
two commands could refer to each other in their docstrings to help users
which might be looking for the other functionality.

-miles

-- 
values of β will give rise to dom!

Re: Input method or help feature needed

[Richard Stallman]

    (1) list-charset-chars lists characters with code-points of
	the specified charset, list-script-chars lists
	characters with Unicode code-points.

Since Unicode is divided up into scripts, I think it is better to make
a list for all Unicode (except for Han and Korean characters).
That way, there is no need to know what argument to give.

      If we are going to have just
	one command, the name should be, for instance,
	list-characters.

That seems good to me.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Richard Stallman]

I tried running list-script-chars.  It seems to be trying to do
a useful job, but I can't see any of the characters.
That is because the background color it uses shows up the same
as the foreground on a tty.

I deleted that, and it works nicely.  It seems quite helpful.

It suggests the characters are supposed to be active, but RET and C-c
C-c don't seem to do anything on them.  Is that not yet implemented,
or does it fail to support keyboard activation?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[David Kastrup]

tomas@tuxteam.de writes:

> On Fri, Feb 18, 2011 at 09:09:44AM +0900, Miles Bader wrote:
>
> [partially enter Unicode name]
>
>> Yeah you need to know or guess part of the name, but the unicode names
>> are reasonably well chosen, pretty regular, and all you need to know is
>> _part_ of it; once you can guess that, it's often easy to narrow the
>> number of choices enough to choose from the completion list...  (often
>> I'll guess a number of common terms for something, and get a hit after
>> 2-3)
>
> As an additional thought: this won't work for non-English speakers,
> right?

Let's worry about that after the user interface and manuals of Emacs
have been localized.  At the current point of time, this consideration
seems a bit silly.

-- 
David Kastrup

Re: Input method or help feature needed

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 18, 2011 at 09:43:24AM +0100, David Kastrup wrote:
> tomas@tuxteam.de writes:
> 
> > On Fri, Feb 18, 2011 at 09:09:44AM +0900, Miles Bader wrote:
> >
> > [partially enter Unicode name]
> >

[...]

> > As an additional thought: this won't work for non-English speakers,
> > right?
> 
> Let's worry about that after the user interface and manuals of Emacs
> have been localized.  At the current point of time, this consideration
> seems a bit silly.

Depends: if you interpret the consideration as "wh must implement
something *now*", it's definitely silly. If  you interpret it as "we
should keep that in mind", I'd say it's not (mind you: I, as the
original author of the consideration might be biased ;)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFNYNELBcgs9XrR2kYRAhlVAJ0Sc4IwE38zR+qHxJPtvtYfjZrZtwCffYWy
NeQj8ffmpmB2FiHnlI2YRd8=
=0nUY
-----END PGP SIGNATURE-----

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Sun, 20 Feb 2011 09:30:03 +0100
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > > As an additional thought: this won't work for non-English speakers,
> > > right?
> > 
> > Let's worry about that after the user interface and manuals of Emacs
> > have been localized.  At the current point of time, this consideration
> > seems a bit silly.
> 
> Depends: if you interpret the consideration as "wh must implement
> something *now*", it's definitely silly. If  you interpret it as "we
> should keep that in mind", I'd say it's not

But what does it mean, in practice, "to keep this in mind"?  Emacs
already supports typing text in many languages other than English, and
completion works for non-ASCII text as well as for 7-bit ASCII.  What
specifically should we "keep in mind" while working on an interface
that allows to find a certain character?

Re: Input method or help feature needed

[Richard Stallman]

    The X11 compose feature actually has pretty easy to remember ways to
    input such characters.  For example, the dotless i can be generated by
    <Multi_key> <i> <.> (<Multi_key> is usually on Shift-RControl).

1. Does it also have an easy way to enter the characters that you use
so rarely you would not remember such a sequence?

2. Could we make <Multi_key> sequences work in Emacs on a console?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Eli Zaretskii]

> Date: Fri, 18 Feb 2011 16:25:11 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> 2. Could we make <Multi_key> sequences work in Emacs on a console?

Input methods are supposed to do that, but you need to know which
method to select.

We could have a new input method that supports all the characters that
can be produced by <Multi_key> sequences, if that's considered
useful.  (Assuming we don't already have such an input method; I don't
really know what characters are supported by <Multi_key>.)

Re: Input method or help feature needed

[Richard Stallman]

    We could have a new input method that supports all the characters that
    can be produced by <Multi_key> sequences, if that's considered
    useful.

Since Multi_key has no other meaning, why not unconditionally
support these sequences all the time?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[James Cloos]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS>     We could have a new input method that supports all the characters that
RS>     can be produced by <Multi_key> sequences, if that's considered
RS>     useful.

RS> Since Multi_key has no other meaning, why not unconditionally
RS> support these sequences all the time?

The input method build in to libX11 will, if Multi_key is associated
with any of the physical keys, preempt Emacs; Emacs will only see the
results of the compose sequences.

Simimarly, at the linux kernel console (at least), the Compose key
sequences are all handled by the kernel code; Emacs never sees the
Compose key itself.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Input method or help feature needed

[Richard Stallman]

    RS> Since Multi_key has no other meaning, why not unconditionally
    RS> support these sequences all the time?

    The input method build in to libX11 will, if Multi_key is associated
    with any of the physical keys, preempt Emacs; Emacs will only see the
    results of the compose sequences.

But that only happens under X.
It would be nice if the same key did the same job on a console.

    Simimarly, at the linux kernel console (at least), the Compose key
    sequences are all handled by the kernel code; Emacs never sees the
    Compose key itself.

I did not know there was a Compose key.  Can you email me the documentation?

I hope that the sequences following Compose and Multi_key are the
same, because any difference between them would be a painful added
complexity for the system as a whole.  Also, is Compose the same
key as Multi_key?

How can I find the Compose key on my keyboard?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Harald Hanche-Olsen]

[Richard Stallman <rms@gnu.org> (2011-02-20 21:01:11 UTC)]

> How can I find the Compose key on my keyboard?

As far as I understand, Compose and Multi_key are one and the same.
That is, the key used to be labeled Compose on the old Sun keyboards.
The PC keyboard doesn't have any such key, but I think it has been
common on X11 to use the right hand Menu key for that.
Anyhow, Multi_Key is the keysym used on X11.

If you run xev and place the mouse cursor in the little window that
pops up, you can hit various keys and find out what X11 thinks they're
called. If you don't have a key mapped to Multi_key, you can make it
so with xmodmap: For example,

  xmodmap -e 'keycode 69 = Multi_key'

will make the key with keycode into Multi_key. xev also gives you
keycodes, so that part is easy to figure out.

As for documentation, these days it seems you can find the compose key
combinations in files called /usr/share/X11/locale/*/Compose these
days, at least on one Ubuntu system I regularly use.

- Harald

Re: Input method or help feature needed

[Richard Stallman]

    > How can I find the Compose key on my keyboard?

    As far as I understand, Compose and Multi_key are one and the same.

I mean, how can I find the key that does this outside X?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Richard Stallman]

    As for documentation, these days it seems you can find the compose key
    combinations in files called /usr/share/X11/locale/*/Compose these

Does this mean that the action of Multi_key depends on the locale?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Harald Hanche-Olsen]

[Richard Stallman <rms@gnu.org> (2011-02-21 22:35:25 UTC)]

>     As for documentation, these days it seems you can find the compose key
>     combinations in files called /usr/share/X11/locale/*/Compose these
> 
> Does this mean that the action of Multi_key depends on the locale?

Indeed it does, as far as I can tell.

- Harald

Re: Input method or help feature needed

[Richard Stallman]

    > Does this mean that the action of Multi_key depends on the locale?

    Indeed it does, as far as I can tell.

Too bad.  That being so, it has no advantage over Emacs input methods.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[James Cloos]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> 2. Could we make <Multi_key> sequences work in Emacs on a console?

An input method which simulates the X11 UTF-8 compose sequences would be
easy to assemble.

But what key would Emacs want to use in place of the X11 Multi_key key-
symbol?

The rfc1345.el input method uses & to initiate its sequences.

Would that be preferred for an X11-derived im, too?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Input method or help feature needed

[Richard Stallman]

    But what key would Emacs want to use in place of the X11 Multi_key key-
    symbol?

Some f-key, perhaps?  I am not sure what is typically available
on the keyboard that Emacs does not use.

    The rfc1345.el input method uses & to initiate its sequences.

That would get in people's way, so we should not enable it by default.
The advantage of Multi_key is that it isn't used for anything else.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

RE: Input method or help feature needed

[Drew Adams]

>     But what key would Emacs want to use in place of the X11 
>     Multi_key key-symbol?
> 
> Some f-key, perhaps?  I am not sure what is typically available
> on the keyboard that Emacs does not use.

Is this a repeatable operation?  Stronger: is it something that users will often
want to repeat by holding down the key?

If not, let's not waste a repeatable key on this.  Let's save easily repeatable
keys for operations that users often repeat multiple times - e.g., incremental
modification or movement.  Let them just hold down a key or chord to do that.

Put this on a prefix key.  E.g., instead of putting it on `f7', put it on `C-x
f7'.  

Or if this is used very often, so you do want something quick but you don't need
successive repetition, then put it on itself as a prefix key: `f7 f7'.  Then you
can use the same prefix key for other, related commands.  This wastes `f7' as a
repeatable key, but it is less wasteful than just binding `f7' to your command.

And if there is a related command that _is_ repeatable, then put that one on `f7
f7...' instead, and put commands such as the one you mention nearby - e.g., `f7
f8'.  That's still quick.

To be able to (in effect) repeat a prefix key (`f7 f7 f7...'), where the action
starts on the second press, see:
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg01153.html

Re: Input method or help feature needed

[Richard Stallman]

    If not, let's not waste a repeatable key on this.

The idea is for these sequences to work in any context, including
inside searches.  For that, it has to be just one key.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

RE: Input method or help feature needed

[Drew Adams]

>     If not, let's not waste a repeatable key on this.
> 
> The idea is for these sequences to work in any context, including
> inside searches.  For that, it has to be just one key.

Why does it have to be just one key for use in search?

I don't know enough to argue about this, but certainly we allow multi-key
bindings in `isearch-mode-map'.  We have several by default already.

Re: Input method or help feature needed

[Richard Stallman]

    I don't know enough to argue about this, but certainly we allow multi-key
    bindings in `isearch-mode-map'.  We have several by default already.

I did not realize that was possible.

However, now that I know the Multi-key feature depends on the locale,
I withdraw the suggestion.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Input method or help feature needed

[Андрей Парамонов]

> Let's worry about that after the user interface and manuals of Emacs
> have been localized.

Hope this never happens. Those half English and half Russian man pages
are already enough pain to deal with.

Best wishes,
Andrey Paramonov