Feature needed

Feature needed

[Richard Stallman]

There should be a help command to ask, "How can I enter
the character after point using an input method?"
It should display a list of which input methods can
generate the character and how to do it.

Re: Feature needed

[Juri Linkov]

> There should be a help command to ask, "How can I enter
> the character after point using an input method?"
> It should display a list of which input methods can
> generate the character and how to do it.

`C-u C-x =' displays this information.  For instance,

        character: Ä (196, #o304, #xc4)
         to input: type "\"{A}" or "\"A" with TeX

where the name of the input method has a link to its description.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Feature needed

[Davis Herring]

> `C-u C-x =' displays this information.  For instance,
>
>         character: Ä (196, #o304, #xc4)
>          to input: type "\"{A}" or "\"A" with TeX
>
> where the name of the input method has a link to its description.

Doesn't it only check the current input method?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Feature needed

[James Cloos]

>>>>> "DH" == Davis Herring <herring@lanl.gov> writes:

>> `C-u C-x =' displays this information.  For instance,
>> 
>> character: Ä (196, #o304, #xc4)
>> to input: type "\"{A}" or "\"A" with TeX
>> 
>> where the name of the input method has a link to its description.

DH> Doesn't it only check the current input method?

Indeed.  And even then it does't always report.  [See below.]

Checking every input method might be too ram or i/o intensive for all
users, but would make a reasonable option.

Or, given that the C-u C-x = output already has a link to customize what
Character code properties to show, it could have one to customize which
input methods to check, with the default being 'current.

Another possibility might be to have a script -> input mapping and to
use that to show a useful input method if the current one cannot input
the character in question.

I just tried out the name »παν語« (cf http://www.pango.org/), and even
with the japanese input method selected -- which I used to input the go --
the C-u C-x = output for 語 did not explain how to enter it.

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

Re: Feature needed

[Miles Bader]

James Cloos <cloos@jhcloos.com> writes:
> I just tried out the name »παν語« (cf http://www.pango.org/), and even
> with the japanese input method selected -- which I used to input the go --
> the C-u C-x = output for 語 did not explain how to enter it.

I think this is not reasonable though -- the Japanese input method is
more context-dependent than most, since input is usually done in larger
units than one character, and often this is necessary for correctness.
It seems like it would actually be kind of hard for Emacs to give the
"right" description of how to input a particular character in a
particular context.

OTOH, perhaps some kind of alternative help output for unusual input
methods would be useful (e.g. for Japanese, giving a list of entries in
Emacs' kana-kanji translation dictionary that contain that character,
but ... maybe that would be kinda large...).

-Miles

-- 
Omochiroi!

Re: Feature needed

[Geoff Gole]

> Checking every input method might be too ram or i/o intensive for all
> users, but would make a reasonable option.

> Or, given that the C-u C-x = output already has a link to customize what
> Character code properties to show, it could have one to customize which
> input methods to check, with the default being 'current.

How about checking all of the input methods in input-method-history?

Re: Feature needed

[Richard Stallman]

    > Or, given that the C-u C-x = output already has a link to customize what
    > Character code properties to show, it could have one to customize which
    > input methods to check, with the default being 'current.

    How about checking all of the input methods in input-method-history?

That would only occasionally be different
from checking only the current input method.

It would give no info about most characters.

Re: Feature needed

[Geoff Gole]

>
> That would only occasionally be different
> from checking only the current input method.
>
> It would give no info about most characters.
>

True, but it's easy and no worse than just checking the current method.

Re: Feature needed

[Richard Stallman]

    True, but it's easy and no worse than just checking the current method.

Indeed it is easy, but it doesn't do the job.  It doesn't even come
close.  For me, it would be no change.

Re: Feature needed

[James Cloos]

>>>>> "MB" == Miles Bader <miles@gnu.org> writes:

MB> James Cloos <cloos@jhcloos.com> writes:
>> I just tried out the name »παν語« (cf http://www.pango.org/), and
>> even with the japanese input method selected -- which I used to input
>> the go -- the C-u C-x = output for 語 did not explain how to enter it.

(As a side note, it seems the pango homepage no longer mentions παν語,
you have to click through to http://www.pango.org/ScriptGallery .)

MB> I think this is not reasonable though -- the Japanese input method
MB> is more context-dependent than most, since input is usually done in
MB> larger units than one character, and often this is necessary for
MB> correctness.  It seems like it would actually be kind of hard for
MB> Emacs to give the "right" description of how to input a particular
MB> character in a particular context.

I see.  I'm not sufficiently familar with either that IM or a sufficient
number of kana or kanji to make heavy use of it; I only know 語 because
of παν語 and 日本語¹.

-JimC

1] Which took me quite a bit of trial and error to correctly input just
   now.  I either only just learned or just re-learned that the first
   two syllables need to be entered as a unit to get 日本.  So I can
   see, now, just how difficult it would be to provide that info.

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

Re: Feature needed

[Stephen J. Turnbull]

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

James Cloos writes:
 > >>>>> "DH" == Davis Herring <herring@lanl.gov> writes:
 > 
 > >> `C-u C-x =' displays this information.  For instance,
 > >> 
 > >> character: Ä (196, #o304, #xc4)
 > >> to input: type "\"{A}" or "\"A" with TeX
 > >> 
 > >> where the name of the input method has a link to its description.
 > 
 > DH> Doesn't it only check the current input method?
 > 
 > Indeed.  And even then it does't always report.  [See below.]
 > 
 > Checking every input method might be too ram or i/o intensive for all
 > users, but would make a reasonable option.

No, it's not.  The vast majority of character inputs are embedded in
self-modifying tries, ie, East Asian phonetic input for Han ideographs
in complex system-wide servers.  I don't see how you plan to get this
information out of SCIM/Anthy, for example, or Xlib/XIM for Greek for
that matter.

[-- Attachment #2: Type: text/plain, Size: 2293 bytes --]


I really don't understand the purpose of this request.  If you can
*see* a character in Emacs, with few exceptions you can copy it (and
if you can't copy it, you won't be able to query it for properties,
either).  You can also get its Unicode code point, and then make-char
wins.  So for one-off situations (eg, a particular math character or 
παν語) you can make your own input method (put the thing in a
register).

Regular users will know how to use some input method, pretty much by
definition.  So really we're talking language learners (FVO "language"
including "math and science notation").  If people want to write
language tutorials in Emacs Lisp, great!  But I don't think that just
providing input method advice is particularly valuable.

For math and science, TeX wins.  The current C-x = will give that, it
seems.

For Japanese and Korean, if you can say it, you can type it.  So the
information you need to type 語 is the reading "go" (and most Japanese
prefer entering the Roman letters g o, while Koreans prefer a Hangul
keyboard but can use Roman letters, so this works on the bare minimum
keyboard such as the Happy Hacker).

For Chinese, I don't know, but I believe that essentially all
computer-using Chinese can handle Mandarin or Cantonese, and both of
those have phonetic input methods (how tones are handled, I'm not
sure).

For non-Han-using natural languages, Emacs users mostly use ISO Level
3 shift (which would be a pain to deal with) or Quail.  Point to the
language's registered Quail input method -- which can display one or
two pages of keystroke mappings -- and add a note that there may be
other methods that the user may prefer.

That leaves languages like Thai and Devanagari, which leaves me
out. :-)  Handa-san?

I don't think the current "to input, use:" feature should be removed,
but I think that teaching people how to use any input method that
happens to be available on the host is beyond Emacs' scope.

Note that trying to infer language from characters is probably not a
great idea, either, given the amount of overlap of non-ASCII
characters: far greater than 0%, far less than 100%.  But it's pretty
likely that the character the user wants to know about can't be input
using the current input method, either, I should think.

Re: Feature needed

[Daniel Clemente]

> I really don't understand the purpose of this request. 
I see many:
- to discover other input methods which may also work for your characters; for instance you might have been using an input method for mathematical characters but then you discover that your preferred-language input method can also output them
- to compare input sequences needed for each character. For instance "古" is "gu32" in chinese-tonepy but it is just "jr" in chinese-cns-tsangchi, so I will be tempted to use the shorter version
- to learn a particular input method by example, just by seeing how to touch type a character and typing it below… without having to resort to searching that character in the Internet. I have needed such a feature many times.

> I don't think the current "to input, use:" feature should be removed,
> but I think that teaching people how to use any input method that
> happens to be available on the host is beyond Emacs' scope.

It doesn't have to be on C-u C-x = necessarily, it could be another function.

Re: Feature needed

[Stephen J. Turnbull]

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

Daniel Clemente writes:

 > > I really don't understand the purpose of this request. 

 > I see many:
 > - to discover other input methods which may also work for your
 >   characters; for instance you might have been using an input
 >   method for mathematical characters but then you discover that
 >   your preferred-language input method can also output them

Let me rephrase: I see no purposes that can be fulfilled beyond what
is already available that wouldn't cost an inordinate amount of
effort.  Eg, good luck if your preferred method is deeply embedded in
the OS (Mac, Windows) or X server.  I don't know about your
environment, but in Japanese, outside of very experienced users like
Handa-san, nobody wants to use Quail because the system methods are
way more efficient, especially for beginners.

 > - to compare input sequences needed for each character. For
 >   instance "古" is "gu32" in chinese-tonepy but it is just "jr" in
 >   chinese-cns-tsangchi, so I will be tempted to use the shorter
 >   version

Since you're not going to do C-x C-m C-\ ch TAB c TAB ts RET jr to
achieve efficient input, obviously what you're really interested in is
which methods are on average more concise.  For that, we should fix
the description strings for the methods if they don't already say so.

[-- Attachment #2: Type: text/plain, Size: 1125 bytes --]


 > - to learn a particular input method by example, just by seeing how
 >   to touch type a character and typing it below~ without having to
 >   resort to searching that character in the Internet. I have needed
 >   such a feature many times.

What's wrong with M-x find-library RET chinese-cns-tsangchi RET M-x
occur <use mouse to copy character> RET, aside from being clumsy
(which you should expect from a proof of concept)?

With a little bit of effort (eg, limit the size of the popup window to
4-5 lines, sort shortest first so you get the single character, add an
option to pick the whole string in the region if the region is active,
add a mode which waits five seconds on each character in the example,
then prompts with the appropriate keystrokes, etc), that can easily be
turned into a generic tutor for any Quail input method.  But it won't
work at all for anything based on XIM or SCIM.

Another way to put my position is that by the time you've accumulated
enough diverse purposes for this feature, you have accumulated a bunch
of purposes that can be better served by much simpler special-purpose
programs.

Re: Feature needed

[Kevin Rodgers]

Daniel Clemente wrote:
>> I don't think the current "to input, use:" feature should be removed,
>> but I think that teaching people how to use any input method that
>> happens to be available on the host is beyond Emacs' scope.
> 
> It doesn't have to be on C-u C-x = necessarily, it could be another function.

How about C-u C-u C-x =

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Feature needed

[Richard Stallman]

    > It doesn't have to be on C-u C-x = necessarily, it could be another function.

    How about C-u C-u C-x =

It is better to make it a button in the output from C-u C-x =.
That way, it won't require people to recall yet another key sequence.

Re: Feature needed

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> I don't think the current "to input, use:" feature should be removed,
> but I think that teaching people how to use any input method that
> happens to be available on the host is beyond Emacs' scope.

I've wished for this on occasion, usually when I want to input some odd
character (e.g., "trademark sign", "gamma", etc), and would like to know
how to type it in the future, but am not even sure which IMs can produce
it.  [This is less true now that Emacs supports input by unicode name,
but still...]

Luckily, fsbot[*] on #emacs (IRC) actually has this functionality, so I
usually just use that!

-miles

[*] I think it's fsbot, anyway, whichever #emacs bot is written in elisp

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

Re: Feature needed

[James Cloos]

>>>>> "SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:

>> Checking every input method might be too ram or i/o intensive for all
>> users, but would make a reasonable option.

SJT> No, it's not.  The vast majority of character inputs are embedded in
SJT> self-modifying tries, ie, East Asian phonetic input for Han ideographs
SJT> in complex system-wide servers.  I don't see how you plan to get this
SJT> information out of SCIM/Anthy, for example, or Xlib/XIM for Greek for
SJT> that matter.

Sorry.  I thought that it went w/o saying that I was referring to quail.
And, as I found out trying to input 日本語 yesterday, even then only a
subset are doable.  Perhaps if the char is in a UCS/TUS script which is
supported by one or more 'simple' quail IMs it could optionally iterate
through those looking for matches?

As for why, Miles and Daniel hit the nail on the head; to know how to
input it in the future.

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

Re: Feature needed

[Stephen J. Turnbull]

James Cloos writes:

 > Sorry.  I thought that it went w/o saying that I was referring to quail.
 > And, as I found out trying to input 日本語 yesterday, even then only a
[...]
 > As for why, Miles and Daniel hit the nail on the head; to know how to
 > input it in the future.

For Japanese, the answer is EDICT and edict.el.  All popular methods
for Japanese are phonetic, and the phonetics are extremely regular, so
an ordinary dictionary does the trick and edict.el will pick up the
character from the Emacs buffer.

Ditto Korean Hangul (without need for even a dictionary for the
syllabary, although Hanja might be an issue if there is no equivalent
to EDICT for Korean).

Dunno about Chinese, where many methods seem to be quite arbitrary
mappings.  I would suppose to the extent that these are not
context-sensitive, reverse-indexing on the character in the quail
table would work.

For small-repertoire input methods like latin-1-prefix, reverse
indexing should work.

Japanese (and similarly for phonetic input of Chinese and Korean
Hanja) is probably hardest since context (neighboring characters) is
used to drastically prune the list presented to the user.  But I don't
understand why the reverse indexing method for single characters
doesn't already work, even for Japanese, to be honest.

Re: Feature needed

[Richard Stallman]

    No, it's not.  The vast majority of character inputs are embedded in
    self-modifying tries, 

Tries what?

			  ie, East Asian phonetic input for Han ideographs
    in complex system-wide servers. I don't see how you plan to get this
    information out of SCIM/Anthy, for example, or Xlib/XIM for Greek for
    that matter.

What are SCIM/Anthy and Xlib/XIM?  Maybe they are input methods
outside Emacs.  I agree they might be difficult.

Surely we can easily handle all of Emacs's own input methods.

Re: Feature needed

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> What are SCIM/Anthy and Xlib/XIM?  Maybe they are input methods
> outside Emacs.  I agree they might be difficult.

SCIM is kinda the "UI" part of an external IM, and Anthy is the
"backend" part, which I think does most of the actual work (looking up
in a translation dictionary, applying grammatical heuristics, etc).

I think it's possible to use Anthy as a backend for Emacs too, but I've
never done this and I'm not sure how; perhaps Emacs should try harder to
autodetect such things (there are others as well) and use them if
present?  That should allow much better quality while maintaining Emacs'
nice IM UI (SCIM is usable enough, but can be kind of clunky compared to
Emacs).

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

Re: Feature needed

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> I think it's possible to use Anthy as a backend for Emacs too, but I've
> never done this and I'm not sure how;

The anthy package comes with an Emacs binding that registers a new input
method.

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: Feature needed

[Richard Stallman]

    I really don't understand the purpose of this request.  If you can
    *see* a character in Emacs, with few exceptions you can copy it

I saw a character I did not know about, and I wanted to know how to
input it in the future.  Yes, I could have copied it to a file and
saved the file, so as to copy it from there.  But I wanted to know how
to insert it cleanly.

Remembering a unicode code point is not a good solution, since that
would be hard to remember.

Re: Feature needed

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I saw a character I did not know about, and I wanted to know how to
> input it in the future.  Yes, I could have copied it to a file and
> saved the file, so as to copy it from there.  But I wanted to know how
> to insert it cleanly.
>
> Remembering a unicode code point is not a good solution, since that
> would be hard to remember.

One very convenient way to enter unusual characters these days is
via the unicode character _name_, via "C-x 8 RET".  The resulting
prompt supports completion (including non-initial completion by
using "* something TAB"), it's reasonably easy to find the name even
if you only know part of it.

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: Feature needed

[Richard Stallman]

    The resulting
    prompt supports completion (including non-initial completion by
    using "* something TAB"), it's reasonably easy to find the name even
    if you only know part of it.

That was quite interesting.  It is nice.  Except that constructing the
value of ucs-completions is so slow.

Reading the same list with `read' is much faster.

So it seems to me there must be a way to speed up the
creation of this list.

Re: Feature needed

[Stephen J. Turnbull]

Miles Bader writes:

 > One very convenient way to enter unusual characters these days is
 > via the unicode character _name_, via "C-x 8 RET".

This doesn't help with CJK ideographs, though.  As far as I know, it
is still the case that the Unicode name is the Unicode code point.

Re: Feature needed

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > One very convenient way to enter unusual characters these days is
>  > via the unicode character _name_, via "C-x 8 RET".
>
> This doesn't help with CJK ideographs, though.  As far as I know, it
> is still the case that the Unicode name is the Unicode code point.

Yup, it's just a handy method for the "hmm how do I type in the
trademark symbol again" problem.

-Miles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Feature needed

[Richard Stallman]

    Checking every input method might be too ram or i/o intensive for all
    users, but would make a reasonable option.

If for each input method we record the range of character codes it can
possibly generate, we could quickly eliminate most input methods for
any given code.  Then checking the remaining few would be fast enough
that we could do it every time,

Another input method feature needed

[Richard Stallman]

It would be nice to have a mode in which you can browse through all
the various character sets, move to a character you are interested in,
and ask how to input it.  (The other feature I suggested would serve
for the last step.)

This would make it easy to take advantage of all the characters that
are available in Emacs.

Re: Another input method feature needed

[Juri Linkov]

> It would be nice to have a mode in which you can browse through all
> the various character sets, move to a character you are interested in,
> and ask how to input it.

This is already implemented by dynamically generated Info manuals
in info-help.el.

You can browse through all available character sets using Info menus
where each character set and each character has a separate Info node
containing the full information.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Štěpán Němec]

Juri Linkov <juri@jurta.org> writes:

>> It would be nice to have a mode in which you can browse through all
>> the various character sets, move to a character you are interested in,
>> and ask how to input it.
>
> This is already implemented by dynamically generated Info manuals
> in info-help.el.
>
> You can browse through all available character sets using Info menus
> where each character set and each character has a separate Info node
> containing the full information.

Details?
Documentation?
NEWS entry?
How do I do that?

(I shall be happy to RTFM, but I have no idea where to look).


    Štěpán

Re: Another input method feature needed

[Juri Linkov]

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

>>> It would be nice to have a mode in which you can browse through all
>>> the various character sets, move to a character you are interested in,
>>> and ask how to input it.
>>
>> This is already implemented by dynamically generated Info manuals
>> in info-help.el.
>>
>> You can browse through all available character sets using Info menus
>> where each character set and each character has a separate Info node
>> containing the full information.
>
> Details?
> Documentation?
> NEWS entry?
> How do I do that?

It's unfinished since after posting it I got no reaction.
If it turns out to be useful, I could finish it.
Please note that this virtual Info manual is not a replacement
of Help.  Help is still better to quickly get the information,
but for browsing Info is better.


[-- Attachment #2: info-help.el --]
[-- Type: application/emacs-lisp, Size: 23774 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Štěpán Němec]

Juri Linkov <juri@jurta.org> writes:

>>>> It would be nice to have a mode in which you can browse through all
>>>> the various character sets, move to a character you are interested in,
>>>> and ask how to input it.
>>>
>>> This is already implemented by dynamically generated Info manuals
>>> in info-help.el.
>>>
>>> You can browse through all available character sets using Info menus
>>> where each character set and each character has a separate Info node
>>> containing the full information.
>>
>> Details?
>> Documentation?
>> NEWS entry?
>> How do I do that?
>
> It's unfinished since after posting it I got no reaction.
> If it turns out to be useful, I could finish it.
> Please note that this virtual Info manual is not a replacement
> of Help.  Help is still better to quickly get the information,
> but for browsing Info is better.

Ah... (you have to admit speaking of that as "this is already
implemented" was a bit confusing).

Yeah, I remember you posting that and me thinking "wow, that looks
useful"; and now that I actually tried it, I'm all for its inclusion.

[it does seem to have some rough edges -- e.g. when I tried browsing the
`ucs' charset, I got `(error ("Can only list 1- and 2-dimensional
charsets"))'; or the weird 8x and 9x ranges in iso-8859-2]

Thanks!

    Štěpán

Re: Another input method feature needed

[Juri Linkov]

> Ah... (you have to admit speaking of that as "this is already
> implemented" was a bit confusing).

It's basically implemented but unfinished ;-)

> Yeah, I remember you posting that and me thinking "wow, that looks
> useful"; and now that I actually tried it, I'm all for its inclusion.
>
> [it does seem to have some rough edges -- e.g. when I tried browsing the
> `ucs' charset, I got `(error ("Can only list 1- and 2-dimensional
> charsets"))'

That's because it relies on the output of the existing command
`M-x list-charset-chars RET ucs RET' that reports this error
(I don't know why it can only list 1- and 2-dimensional charsets).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Kenichi Handa]

In article <87pqzm21fp.fsf@mail.jurta.org>, Juri Linkov <juri@jurta.org> writes:
> That's because it relies on the output of the existing command
> `M-x list-charset-chars RET ucs RET' that reports this error
> (I don't know why it can only list 1- and 2-dimensional charsets).

Listing all ucs characters takes looong time and thus I limitted the
size to 1- and 2-dimensional charsets.  For listing ucs charset,
perhaps, one idea is that the first buffer shown just lists blocks
as this:
  U+000000..U+00FFFF  
  U+010000..U+01FFFF
  ...
  U+100000..U+10FFFF
and allow users to select which block of characters to list.

---
Kenichi Handa
handa@m17n.org

Re: Another input method feature needed

[Juri Linkov]

>> That's because it relies on the output of the existing command
>> `M-x list-charset-chars RET ucs RET' that reports this error
>> (I don't know why it can only list 1- and 2-dimensional charsets).
>
> Listing all ucs characters takes looong time and thus I limitted the
> size to 1- and 2-dimensional charsets.

The output of `M-x list-charset-chars RET ucs RET' is exactly like
the output of `M-x list-charset-chars RET unicode-bmp RET' that
is not disabled.  And Miles said that he sometimes uses
`M-x list-charset-chars RET unicode-bmp RET' without problems.
So maybe it would be better not disable `ucs' along with
`unicode-bmp' because they are quick enough on modern computers.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Stephen J. Turnbull]

Juri Linkov writes:
 > > Ah... (you have to admit speaking of that as "this is already
 > > implemented" was a bit confusing).
 > 
 > It's basically implemented but unfinished ;-)

Please say, "I have implemented in a local branch" (if you have a plan
for completion, even if unfinished and unscheduled) or "I have a proof
of concept for this" (if the code is still too shamefully ugly to show
anyone without making excuses first ;-).  Then everybody is on the
same page, no expensive cache misses. :-)

Re: Another input method feature needed

[Juri Linkov]

>  > It's basically implemented but unfinished ;-)
>
> Please say, "I have implemented in a local branch" (if you have a plan
> for completion, even if unfinished and unscheduled) or "I have a proof
> of concept for this" (if the code is still too shamefully ugly to show
> anyone without making excuses first ;-).  Then everybody is on the
> same page, no expensive cache misses. :-)

Yes, the code is still shamefully ugly because it relies on Help
commands (calls a Help command and tries to parse its output.)

If this proof of concept proves useful, the proper implementation
will require some refactoring and generalization of Help commands
(to avoid code duplication between Help and Info.)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Štěpán Němec]

Juri Linkov <juri@jurta.org> writes:

>>>> It would be nice to have a mode in which you can browse through all
>>>> the various character sets, move to a character you are interested in,
>>>> and ask how to input it.
>>>
>>> This is already implemented by dynamically generated Info manuals
>>> in info-help.el.
>>>
>>> You can browse through all available character sets using Info menus
>>> where each character set and each character has a separate Info node
>>> containing the full information.
>>
>> Details?
>> Documentation?
>> NEWS entry?
>> How do I do that?
>
> It's unfinished since after posting it I got no reaction.
> If it turns out to be useful, I could finish it.
> Please note that this virtual Info manual is not a replacement
> of Help.  Help is still better to quickly get the information,
> but for browsing Info is better.
>
> ;; info-help.el --- Emacs on-line help system as a virtual Info manual

Let's not let this fall into oblivion the second time. Any objections
against Juri including the library into Emacs and continuing integrating
it/working on it (or the other way round)?

Re: Another input method feature needed

[Juri Linkov]

> Let's not let this fall into oblivion the second time. Any objections
> against Juri including the library into Emacs and continuing integrating
> it/working on it (or the other way round)?

In any case it would be useful to split help functions into two parts:

1. data collection that returns data structures with help information;
2. view generation that renders the output according to defined layouts.

The first could be used by any package that wants raw information
to process it.  The second will allow the user to configure
the layout of the *Help* buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Stefan Monnier]

>> Let's not let this fall into oblivion the second time.  Any objections
>> against Juri including the library into Emacs and continuing integrating
>> it/working on it (or the other way round)?

If it's in a usable state, it can be installed.  If not, then maybe it
can be split into smaller steps where each step is in a usable state.

> In any case it would be useful to split help functions into two parts:

> 1. data collection that returns data structures with help information;
> 2. view generation that renders the output according to defined layouts.

Feel free to install refactoring patches that do that.


        Stefan

Re: Another input method feature needed

[Juri Linkov]

>>> Let's not let this fall into oblivion the second time.  Any objections
>>> against Juri including the library into Emacs and continuing integrating
>>> it/working on it (or the other way round)?
>
> If it's in a usable state, it can be installed.  If not, then maybe it
> can be split into smaller steps where each step is in a usable state.

Currently the code is too ugly to install.  I'd like to refactor
help functions first.

>> In any case it would be useful to split help functions into two parts:
>
>> 1. data collection that returns data structures with help information;
>> 2. view generation that renders the output according to defined layouts.
>
> Feel free to install refactoring patches that do that.

Refactoring patches are not ready yet.  I'm thinking about
what is the best way of doing that.  Actually for the data part
there is already exists something similar to what we need:
for advised functions `ad-get-advice-info' returns an alist with
information about an advised function:

      ((active . t/nil)
       (before adv1 adv2 ...)
       (around adv1 adv2 ...)
       (after  adv1 adv2 ...)
       (activation  adv1 adv2 ...)
       (deactivation  adv1 adv2 ...)
       (origname . <symbol fbound to origdef>)
       (cache . (<advised-definition> . <id>)))

We could create a new function `describe-function-info' that will return
a similar alist with information about all functions with association keys
like `docstring', `file-name', `keybindings', `arglist', `obsolete', etc.
And similarly for other help functions: `describe-variable-info',
`describe-face-info', ...

For the view part we need a templating library.  I think the most suitable
is skeleton.el.  It is used successfully in autoinsert.el to generate
large complex text blocks.  So we could use skeleton.el and add new
variables `describe-function-skeleton', `describe-variable-skeleton', ...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Richard Stallman]

    This is already implemented by dynamically generated Info manuals
    in info-help.el.

Is this documented in the Emacs Manual?
Is there a C-h command for it?  If not, should there be one?

I can't check -- my sources are rather old and I don't have
info-help.el, and my attempt to update them just failed.
I did

      cd trunk/
      bzr pull

And it says "No pull location known or specified."
I had initially done

      cd trunk/
      echo "public_branch = http://bzr.savannah.gnu.org/sources/emacs/trunk" >>
.bzr/branch/config
      bzr bind http://bzr.savannah.gnu.org/sources/emacs/trunk/

so it ought to know where to pull from.  trunk/.bzr/branch/config does
not exist now; instead there is a file branch.conf with this text:

    bound_location = sftp://rms@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
    bound = True

Re: Another input method feature needed

[Juri Linkov]

>     This is already implemented by dynamically generated Info manuals
>     in info-help.el.
>
> Is this documented in the Emacs Manual?

At the current stage it is just a proof of concept.
I posted the code to emacs-devel for comments.

> Is there a C-h command for it?  If not, should there be one?

A possible C-h prefix key map would be `C-h h', whereas `view-hello-file'
could be bound to `C-h H' (where `H' is mnemonic for `HELLO').

> I can't check -- my sources are rather old and I don't have
> info-help.el, and my attempt to update them just failed.

info-help.el is not in the Savannah repository anyway.

> I did
>
>       cd trunk/
>       bzr pull
>
> And it says "No pull location known or specified."
> I had initially done
>
>       cd trunk/
>       echo "public_branch = http://bzr.savannah.gnu.org/sources/emacs/trunk" >>
> .bzr/branch/config
>       bzr bind http://bzr.savannah.gnu.org/sources/emacs/trunk/
>
> so it ought to know where to pull from.  trunk/.bzr/branch/config does
> not exist now; instead there is a file branch.conf with this text:
>
>     bound_location = sftp://rms@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
>     bound = True

http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs says nothing
about `trunk/.bzr/branch/config'.  I suggest to follow instructions
from this page to avoid possible problems with using Bazaar.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another input method feature needed

[Richard Stallman]

    http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs says nothing
    about `trunk/.bzr/branch/config'.

I think that is where I got the instructions to use these commands:

       cd trunk/
       echo "public_branch = http://bzr.savannah.gnu.org/sources/emacs/trunk" >> .bzr/branch/config
       bzr bind http://bzr.savannah.gnu.org/sources/emacs/trunk/

Maybe it has been changed since then, so I will send mail to fetch it
again.  Nonetheless, I already have a repository and I wonder how
to update it.

Re: Another input method feature needed

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Maybe it has been changed since then, so I will send mail to fetch it
> again.  Nonetheless, I already have a repository and I wonder how
> to update it.

$ bzr pull $URL

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."

Another input method feature needed

[Stephen J. Turnbull]

Richard Stallman writes:

 > It would be nice to have a mode in which you can browse through all
 > the various character sets, move to a character you are interested in,
 > and ask how to input it.

A naive implementation won't cut it.  There are an *awful lot* of
characters, and browsing gets painful if you do it by Unicode blocks
unless you already know pretty much exactly what you're looking for.
Eg, "accented Latin" requires browsing through maybe 700 characters,
and they all start to look alike after the first two rows.  It's easy
to miss what you're looking for.

Besides information on Unicode blocks (which should be already
available), I would suggest using an NFD decompostion, and then allow
the user to select components (based characters and composing forms,
eg, turning the Angstrom symbol into an A and a circle).

Re: Another input method feature needed

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > It would be nice to have a mode in which you can browse through all
>  > the various character sets, move to a character you are interested in,
>  > and ask how to input it.
>
> A naive implementation won't cut it.  There are an *awful lot* of
> characters, and browsing gets painful if you do it by Unicode blocks
> unless you already know pretty much exactly what you're looking for.
> Eg, "accented Latin" requires browsing through maybe 700 characters,
> and they all start to look alike after the first two rows.  It's easy
> to miss what you're looking for.

Point taken, but I think browsing _can_ be a lot more useful that the
above description suggests -- the human visual system is pretty good at
that kind of thing.

Sometimes when I don't have a more efficient way find a character, I do
"M-x list-charset-chars RET unicode-bmp RET" and scroll around.  The
table format used there seems well suited to quick scanning, and one can
just auto-repeat C-v to quickly search for likely-looking code blocks...

-Miles

-- 
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.