Committing Newlines in SCIM-Tables ?

[Daniel Yacob]

Greetings,

I'm developing IM tables for the SCIM-Tables 0.5.7 package and would like the "Enter" key to both commit the character under the blue composition highlight and insert a newline into the text buffer.

How can this be done?

thanks!

-Daniel

[Ryo Dairiki-2]

Daniel Yacob wrote:

> Greetings,
>
> I'm developing IM tables for the SCIM-Tables 0.5.7 package and would like
> the "Enter" key to both commit the character under the blue composition
> highlight and insert a newline into the text buffer.
>
> How can this be done?
>
> thanks!
>
> -Daniel
>  

Hi Daniel,

    I'm not sure, but I haven't heard that there's such feature in
SCIM-Tables.
For what do you need it? I'll prepare such feature in the next release
if it really needed.

Regards,
Ryo Dairiki <[hidden email]>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

Ryo,

Thank you for the reply. The need to have a single newline both commit a character and enter into the text buffer as a newline is simply to meet user expectations for Ethiopic input methods.  This is also in keeping with the behavior of other input method systems such as GTK+, KMFL, M17N (MIM) and Windows Keyman. Having to hit the "Enter" key twice to commit a single newline is unexpected behavior for these users.

So an option for newlines to terminate composition AND commit as text would solve the problem.

Related, I have some SCIM tables to submit to the SCIM-Tables project (http://keyboards.ethiopic.org/) but need to prepare an update before doing so. I'm available and quite happy to test any SCIM updates for this feature request.

thank you,

Daniel

[Ryo Dairiki-2]

I'm sorry, Daniel, but I don't know what to do exactly.
I don't know well about Ethiopic input methods.

Please give me step by step example for both expected result and actual
result.
Don't forget to mention the preedit text or the lookup text if they appear.
Maybe they sould appear, as you said "commit".

And does hitting of "Enter" always commit and break lines at the same time?
Or should it be controlled by characters you type?

Ryo

Daniel Yacob wrote:

> Ryo,
>
> Thank you for the reply. The need to have a single newline both commit a
> character and enter into the text buffer as a newline is simply to meet user
> expectations for Ethiopic input methods.  This is also in keeping with the
> behavior of other input method systems such as GTK+, KMFL, M17N (MIM) and
> Windows Keyman. Having to hit the "Enter" key twice to commit a single
> newline is unexpected behavior for these users.
>
> So an option for newlines to terminate composition AND commit as text would
> solve the problem.
>
> Related, I have some SCIM tables to submit to the SCIM-Tables project
> (http://keyboards.ethiopic.org/) but need to prepare an update before doing
> so. I'm available and quite happy to test any SCIM updates for this feature
> request.
>
> thank you,
>
> Daniel
>  

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

Greetings Ryo,

My regrets that I could not reply before now.  I'll try an example of the expected behavior -hoping now that the forum is UTF-8 safe, if not I can prepare a PDF file.

Lets start with a simple Ethiopic series for the "be" family of syllables:

 በ       ቡ     ቢ     ባ      ቤ      ብ     ቦ      ቧ
(be)  (bu)  (bi)  (ba)  (bie)  (b)  (bo)  (bua)

The first row is Ethiopic in UTF-8, the second is a token form applying the transliteration used in input that I'll use to make the examples easier to read.  I'll use ↵ for the "Enter" key and we can ignore if "Enter" inserts \n or \r\n .

So typing the text:

b:  (b)              [ "(b)" is underlined because other candidates are composable ]
be: (b) ⇒ (be)    [ "(be)" is no longer underlined, no further candidates remain, it is "committed" ]

However, if we typed "Enter" after (b):

b↵: (b) ⇒ (b)     ["(b)" is no longer underlined, it is committed, but ↵ is absorbed ]

as a consequence, to get ↵ inserted into the text buffer one must type "Enter" twice:

b↵↵: (b) ⇒ (b)↵

The desired behavior is:

b↵: (b) ⇒ (b)↵   ["(b)" is no longer underlined, both (b) and ↵ are committed ]


I hope this illustration communicates the issue.  In a nutshell one might say "Enter is always Enter", it is never interpreted. If there is an existing option or setting to enable this behavior, please let me know. Also please let me know if further explanation is needed.

thank you,

-Daniel

[Ryo Dairiki-2]

Hi Daniel,

Thank you for the mail.
Now I see what you mean exactly.
I promise you to fix this bug in this developing cycle. :)

Daniel Yacob wrote:

> Greetings Ryo,
>
> My regrets that I could not reply before now.  I'll try an example of the
> expected behavior -hoping now that the forum is UTF-8 safe, if not I can
> prepare a PDF file.
>
> Lets start with a simple Ethiopic series for the "be" family of syllables:
>
>  በ       ቡ     ቢ     ባ      ቤ      ብ     ቦ      ቧ
> (be)  (bu)  (bi)  (ba)  (bie)  (b)  (bo)  (bua)
>
> The first row is Ethiopic in UTF-8, the second is a token form applying the
> transliteration used in input that I'll use to make the examples easier to
> read.  I'll use ↵ for the "Enter" key and we can ignore if "Enter" inserts
> \n or \r\n .
>  

Don't worry, I can see all of your words correctly. :)

> So typing the text:
>
> b:  (b)              [ "(b)" is underlined because other candidates are
> composable ]
> be: (b) ⇒ (be)    [ "(be)" is no longer underlined, no further candidates
> remain, it is "committed" ]
>
> However, if we typed "Enter" after (b):
>
> b↵: (b) ⇒ (b)     ["(b)" is no longer underlined, it is committed, but ↵ is
> absorbed ]
>
> as a consequence, to get ↵ inserted into the text buffer one must type
> "Enter" twice:
>
> b↵↵: (b) ⇒ (b)↵
>
> The desired behavior is:
>
> b↵: (b) ⇒ (b)↵   ["(b)" is no longer underlined, both (b) and ↵ are
> committed ]
>  

Now I know what's the problem.
We can fix this problem by adding an optional column in table files as
follows:

b    ብ    option1,option2    // something written in the last column,
optional features are enabled
bo    ቦ                      // nothing written, no option is specified

> I hope this illustration communicates the issue.  In a nutshell one might
> say "Enter is always Enter", it is never interpreted. If there is an
> existing option or setting to enable this behavior, please let me know. Also
> please let me know if further explanation is needed.
>  

Is this only the case of "Enter"?
What if I type "bb"?
The first "b" should be commited, and the second "b" remain underlined,
shouldn't you?
If so, we should not call this option "Enter is always Enter", but just
"Auto commit".

> thank you,
>
> -Daniel
>  
thanks, you too.

Regards,
Ryo Dairiki <[hidden email]>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

Ryo,

Some responses inline:


> Is this only the case of "Enter"?

It appears to be so.  I went back and checked with other control characters like TAB, SHIFT, BACKSPACE and the correct behavior is found.


> What if I type "bb"?
> The first "b" should be commited, and the second "b" remain underlined,
> shouldn't you?

Yes.  This works correctly at present.


> If so, we should not call this option "Enter is always Enter", but just
> "Auto commit".

That sounds good.  In my previous description I was relying on memory from the time I made the opening post.  When I was checking on the behavior with TAB, etc, last evening I found that my memory was in error.  Only a small difference that I suspect has no big consequence, anyway the following is a correction:


b↵: (b) ⇒ b     ["(b)" is replaced with the ASCII keystroke "b", it is committed, and ↵ is absorbed ]


When ↵ is entered it seems to cause the mapping to fail and the literal key sequence then appears in the output.

thank you,

-Daniel

[Ryo Dairiki-2]

Hi Daniel,

Daniel Yacob wrote:

> Ryo,
>
> Some responses inline:
>
>
>  
>> Is this only the case of "Enter"?
>>    
>
> It appears to be so.  I went back and checked with other control characters
> like TAB, SHIFT, BACKSPACE and the correct behavior is found.
>  

Hum.

>> What if I type "bb"?
>> The first "b" should be commited, and the second "b" remain underlined,
>> shouldn't you?
>>    
>
> Yes.  This works correctly at present.
>  

So, "Enter" key is not a special (exception), isn't you?

>> If so, we should not call this option "Enter is always Enter", but just
>> "Auto commit".
>>    
>
> That sounds good.  In my previous description I was relying on memory from
> the time I made the opening post.  When I was checking on the behavior with
> TAB, etc, last evening I found that my memory was in error.  Only a small
> difference that I suspect has no big consequence, anyway the following is a
> correction:
>
>
> b↵: (b) ⇒ b     ["(b)" is replaced with the ASCII keystroke "b", it is
> committed, and ↵ is absorbed ]
>
>
> When ↵ is entered it seems to cause the mapping to fail and the literal key
> sequence then appears in the output.
>  

You mean that the "b" is replaced with the ASCII "b" in the current
version of SCIM-Tables?
Is this what you desired or just a bug to be fixed?

> thank you,
>
> -Daniel
>  

Regards,
Ryo Dairiki <[hidden email]>


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

>>> What if I type "bb"?
>>> The first "b" should be commited, and the second "b" remain underlined,
>>> shouldn't you?
>>>    
>>
>> Yes.  This works correctly at present.
>>  
>
> So, "Enter" key is not a special (exception), isn't you?


"Enter" is no more special than "Tab"  (/should not be/ any more special than "Tab").


>>
>> b↵: (b) ⇒ b     ["(b)" is replaced with the ASCII keystroke "b", it is
>> committed, and ↵ is absorbed ]
>>
>>
>> When ↵ is entered it seems to cause the mapping to fail and the literal key
>> sequence then appears in the output.
>>  


> You mean that the "b" is replaced with the ASCII "b" in the current
> version of SCIM-Tables?


Yes. The "Enter" seems to abort whatever composition had occurred up to that point and inserts the composing keystrokes (replacing the underlined symbol).  Other examples:

bi↵:  (bi) ⇒ bi
bu↵:  (bu) ⇒ bu

(bi) and (bu) were both underlined in the above example because further composition was still possible.  "Enter" caused the underlined Ethiopic to be replaced with the composing ASCII keystrokes.


> Is this what you desired or just a bug to be fixed?

It is not desired, but not necessarily a "bug" -perhaps a missing feature ;-)  "Enter" should follow the behavior of "Tab" in that it terminates a composition at its present underlined state, and the "Enter" is added to the text stream.

thanks,

-Daniel

[Ryo Dairiki-2]

Daniel Yacob wrote:

>>>> What if I type "bb"?
>>>> The first "b" should be commited, and the second "b" remain underlined,
>>>> shouldn't you?
>>>>    
>>>>        
>>> Yes.  This works correctly at present.
>>>  
>>>      
>> So, "Enter" key is not a special (exception), isn't you?
>>    
>
>
> "Enter" is no more special than "Tab"  (/should not be/ any more special
> than "Tab").

I'm confused.
Please make the list for test cases, expected results, and actual results.
What is the special keys?
Should they work all the same?
Is there any other key that doesn't work properly?

>>> b↵: (b) ⇒ b     ["(b)" is replaced with the ASCII keystroke "b", it is
>>> committed, and ↵ is absorbed ]
>>>
>>>
>>> When ↵ is entered it seems to cause the mapping to fail and the literal
>>> key
>>> sequence then appears in the output.
>>>
>>>      
>> You mean that the "b" is replaced with the ASCII "b" in the current
>> version of SCIM-Tables?
>>    
>
> Yes. The "Enter" seems to abort whatever composition had occurred up to that
> point and inserts the composing keystrokes (replacing the underlined
> symbol).  Other examples:
>
> bi↵:  (bi) ⇒ bi
> bu↵:  (bu) ⇒ bu
>
> (bi) and (bu) were both underlined in the above example because further
> composition was still possible.  "Enter" caused the underlined Ethiopic to
> be replaced with the composing ASCII keystrokes.
>  

Actual results:

bi↵:  (bi) ⇒ bi
bu↵:  (bu) ⇒ bu


Expected results:

bi↵:  (bi) ⇒ bi↵
bu↵:  (bu) ⇒ bu↵

My understanding is this.
Is this correct?

>> Is this what you desired or just a bug to be fixed?
>>    
>
> It is not desired, but not necessarily a "bug" -perhaps a missing feature
> ;-)  "Enter" should follow the behavior of "Tab" in that it terminates a
> composition at its present underlined state, and the "Enter" is added to the
> text stream.
>
> thanks,
>
> -Daniel
>  

Please give me exactly what you want.
I cannot determine what to do without your help.

How does "Tab" works for now? How about "Backspace"?
Please write in expected results, and actual results.

Btw, how could you commit "b" in Ethiopic?
It seems like there is no way to enter it.

Regards,
Ryo Dairiki <[hidden email]>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

Ryo,

I have prepared this document to explain visually what the expected behavior is:

  http://keyboards.ethiopic.org/notes/SCIMCompositionNotes.pdf

I've tried to keep it simple and only discuss correct behavior, not incorrect.

thank you,

-Daniel

[Ryo Dairiki-2]

Hi, Daniel.

You use "Enter" as the forwarding key in the definition tables, don't you?
I've found the following entry in gff-ethiopic-7-scim-table.txt.
> ### The key strokes to forward the inputted string to client.
> FORWARD_KEYS = Return

It should work as you said if you delete "Return" here.
The forwarding key is the key to send the raw (not converted) text,
so this is very rational feature.
Maybe, you don't know this feature, don't you?

Regards,
Ryo Dairiki <[hidden email]>

Daniel Yacob wrote:

> Ryo,
>
> I have prepared this document to explain visually what the expected behavior
> is:
>
>   http://keyboards.ethiopic.org/notes/SCIMCompositionNotes.pdf
>
> I've tried to keep it simple and only discuss correct behavior, not
> incorrect.
>
> thank you,
>
> -Daniel
>  

------------------------------------------------------------------------------
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

[Daniel Yacob]

Ryo,

This suggestion does work perfectly!  Thank you!

I had tried it in the past but saw no effect, I thought I didn't understand clearly what the parameter was for.  Trying it again last night I still saw that it had no effect -even after restarting the SCIM server and verifying with the configuration tool that the parameter was removed.

When using SCIM this morning, having restarted my computer, I found that the input started working!  Fortunately I had not un-done the change.  I regret that it took so many email exchanges to get to this point, thanks for hanging in there.  When restarting SCIM is there an option that should be used to clear cache? Or if not cache, to do the equivalent of what restarting the computer accomplished?

thanks!

-Daniel

[Ryo Dairiki-2]

Hi Daniel.

Daniel Yacob wrote:
> Ryo,
>
> This suggestion does work perfectly!  Thank you!
>
> I had tried it in the past but saw no effect, I thought I didn't understand
> clearly what the parameter was for.  Trying it again last night I still saw
> that it had no effect -even after restarting the SCIM server and verifying
> with the configuration tool that the parameter was removed.
>  

I'm happy to hear that.

> When using SCIM this morning, having restarted my computer, I found that the
> input started working!  Fortunately I had not un-done the change.  I regret
> that it took so many email exchanges to get to this point, thanks for
> hanging in there.  When restarting SCIM is there an option that should be
> used to clear cache? Or if not cache, to do the equivalent of what
> restarting the computer accomplished?
>  

SCIM-Tables loads the definition files only when it starts.
So you have to restart SCIM to reload the definition.

> thanks!
>
> -Daniel
>  

Thank you, you too.
I'll close this report as "not a bug".

Regards,
Ryo Dairiki <[hidden email]>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel