Page MenuHomePhabricator

cursor word start position issue
Needs RevisionPublic

Authored by AbdullehGhujeh on Apr 7 2019, 9:07 AM.

Details

Summary

case 1 :

evas_textblock_cursor_text_prepend(cur, "hello");
evas_textblock_cursor_word_start(cur); 
evas_textblock_cursor_pos_get(cur); // cursor set to pos 0, expected pos 5

case 2 :

evas_textblock_cursor_text_prepend(cur, "hello");
evas_textblock_cursor_word_end(cur); 
evas_textblock_cursor_pos_get(cur); // cursor at pos 5, expected pos 5

case 3 :

evas_textblock_cursor_text_append(cur, "Hello");
evas_textblock_cursor_char_next(cur);
evas_textblock_cursor_word_end(cur);
evas_textblock_cursor_pos_get(cur); // cursor at pos 4, expected pos 4
evas_textblock_cursor_word_start(cur); 
evas_textblock_cursor_pos_get(cur); // cursor at pos 0, expected pos 0

based on current behaviour the word start in case 1 must stay in the postion 5 as the word end in case 2 stays at position 5 because we are after the end of "hello".

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 10790
Build 8379: arc lint + arc unit
AbdullehGhujeh created this revision.Apr 7 2019, 9:07 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

AbdullehGhujeh requested review of this revision.Apr 7 2019, 9:07 AM
AbdullehGhujeh edited the summary of this revision. (Show Details)Apr 7 2019, 9:11 AM
bu5hm4n requested changes to this revision.Apr 17 2019, 10:42 PM
bu5hm4n added a subscriber: bu5hm4n.

Can you elaborate why you expect 5 in the first case ? I think 0 is pretty much fine there, as it seems to be the start of the word. I also don't believe that the addition here is correct, when we explicitly ask the cursor to go to the word start, and the cursor is currently at the END of a world, why would that be okay ?

This revision now requires changes to proceed.Apr 17 2019, 10:42 PM

@bu5hm4n
based on current behavior
If cursor at position zero or middle of the word and asked for word start and end , word start is 0 and word end is 4 (see case 3)
but if cursor is at position 5 (for the same word) and asked for word start and end, word start is 0 and word end is 5 (see case 1 & case 2)
based on this behavior I expected the word start to be 5 because we are on position after the word end which is 4, so word start & end needs to be 5.

This will require a bit more investigation, in elementary_test -to "Entry 4" you can check and see where the cursor position is. So when somewhere is 4 returned then this is a bug. As this will imply the end of the word is in the middle of the of the word. That sound a little bit wrong to me.

@bu5hm4n
It sounds a little bit wrong to me also but in "evas_test_textblock" they check word end to be 4 not 5 (not exact values but same case).
For elementary_test -to "Entry 4" i didn't see its code but it seems like it uses entry, entry does not export functionality for word end I think.
I already saw some code in entry for word selection or moving cursor by Ctrl+Arrow, it calls textblock word end then move to next character :)

I think the behavior in case 1 is correct. Even still after reading the textblock code.

So a word is seperated by either a linebreak or a whitespace. Lets take a more complex character sequece, like `Hello World'

012345678910
HelloWorld

The range of words:

  • hello: [0,5]
  • world: [6,11]

Note that the cursor is always placed at the beginning of each cell.

So with a cursor position of 11:
cursor_word_start would move it to 6
cusor_word_end would move it to 10

What your example shows is that the word_end code has probebly a bug in case 3. However, i would claim that the behavior in case 1 and 2 are right.

@bu5hm4n
This is what I thought also, but when I saw textblock test code i thought that this behavior are intended to be like this.
anyway in GTK word end for 'hello' is 5 not 4.
So I need to fix word end bug and remove all workarounds for it and commit it as a new patch

There is workaround code for this ? Where ?

My take on this is that this is clearly a bug. And should be fixed.

@bu5hm4n
For example "_elm_entry_efl_access_text_string_get" function in elm_entry.c
call word end then call next character for "EFL_ACCESS_TEXT_GRANULARITY_WORD" case.

bu5hm4n added a subscriber: zmike.Apr 21 2019, 3:05 AM

Mhm, @cedric @zmike what do you say ? Should we provide bug compatibility here, or just fix the bug ?