where-is-internal's firstonly

where-is-internal's firstonly

[Kenichi Handa]

It seems that where-is-internal handle the arg FIRSTONLY not
well.

Provided that the current active maps are MAP1 and MAP2
in this order, and we have these key bindings:
  MAP1: "1" -> func, "2" -> func
  MAP2: "A" -> func, "B" -> func
  
The function where_is_internal at first accumulates keys for
MAP1 in the variable SEQUENCES as ("2" "1") and then store
them in the variable FOUND as ("1" "2"), next accumulates keys
for MAP2 in SEQUENCES as ("B" "A") and then store them in
FOUND as ("A" "B" "1" "2").  Next FOUND is reversed to ("2"
"1" "B" "A").  So "2" is returned.  
 
In short, where-is-internal finds the last binding in the
first active map.

Is this a bug?  Or, is the important thing for
where-is-internal is to find a binding in first map, and
it's not important to find which binding in that map?

---
Ken'ichi HANDA
handa@m17n.org

Re: where-is-internal's firstonly

[Stefan]

> In short, where-is-internal finds the last binding in the
> first active map.

> Is this a bug?

It's not a bug in the sense that the documentation is silent about this part
of the behavior.  Usually the selection of "which binding to use" uses other
criterions such as "simple ascii char vs. mouse binding".

But that also means that changing the behavior such that "1" is returned in
your example would not introduce a bug either and it can be argued that it'd
be a better behavior.


        Stefan

Re: where-is-internal's firstonly

[Kenichi Handa]

In article <m1fz4ylinv.fsf-monnier+emacs@gnu.org>, Stefan <monnier@iro.umontreal.ca> writes:

>>  In short, where-is-internal finds the last binding in the
>>  first active map.

>>  Is this a bug?

> It's not a bug in the sense that the documentation is silent about this part
> of the behavior.  Usually the selection of "which binding to use" uses other
> criterions such as "simple ascii char vs. mouse binding".

Thank you for the clarification.

> But that also means that changing the behavior such that "1" is returned in
> your example would not introduce a bug either and it can be argued that it'd
> be a better behavior.

I put this issue in my todo-list.  As it is not a bug, let's
fix it after the release.

---
Ken'ichi HANDA
handa@m17n.org