Words: marking, deleting, jumping over skips insets

[hha4491@…]

Take the following example:

setzen, stellen OBJEKT, legen

With OBJEKT I mean anything that is not text (picture, special character etc.)
If you double-click on one of the three words, it gets marked, and the Del-
button deletes it. If you put the cursor before/in the word "setzen", Ctrl+Del
deletes "setzen, ". If you do the same with "stellen", "stellen OBJEKT, " gets
deleted.
A more extreme example is

Paragraph REFERENCE FIGURE ERT.

If you put the cursor before "P" Ctrl+Del deletes everything. That is certainly
not correct.
Similar is true for Ctrl+-->

[Uwe Stöhr]

Confirmed.

[sualk@…]

This bug makes it impossible to mark, copy and cut larger text-areas. It did
already occur in version 1.4.x, but in former versions I were still able to use
the keyboard for marking. Since version 1.5.1, I am not even able to use this
workaround.

(system environment: Debian lenny, gnome2, utf8-charset)

[hha4491@…]

Klaus, I cannot see what you describe. On my system (kubuntu606, KDE, utf8-
charset) the bug is for lyx151 and lyx160svn still as I described, but I can
mark, copy and cut larger text-areas. Maybe in your case it has to do with
Debian or Gnome or both.

[hha4491@…]

Klaus, did you configure with Qt4?

[sualk@…]

Hartmut, I'm sorry for my inaccuracy. Cut&paste is working in principle, but if
not able to mark larger areas, tex-environments etc. it is eventually
impossible to use this function for larger amounts of data. However you are
absolutely right: The bug is the *marking* NOT the cut&paste!
Thanks for your specification!

[sualk@…]

Heureka! Problem solved! It's Glipper, the gnome-clipboard which is messing
around. (Sometimes in open office, too!) Disabling this feature removes the bug!

[hha4491@…]

It's always astonishing: as soon as you do the right thing, it works.

But that doesn't have to do with the bug.

[Juergen Spitzmueller]

* #4289 has been marked as a duplicate of this bug. *

[Juergen Spitzmueller]

* #3662 has been marked as a duplicate of this bug. *

[Juergen Spitzmueller]

* #4581 has been marked as a duplicate of this bug. *

[milde@…]

While #4581 is a duplicate of this bug, its bug-report contains additional
discussion (from the lyx-users list) as well as a patch by JMarc that fixes it.

The basic failure is not deleting, nor marking but *moving*:

word-forward skips not only the word but also trailing non-word characters and
object (white-space, punctuation, insets (footnotes, graphics, floats,
math-boxes, minipages, ...)).

As the inability of word-wise movement by keyboard as well as accitential
deletion of insets (as large as a float or minipage) is very annoying,
I vote to give this bug a more-than-normal priority.

Günter

[Juergen Spitzmueller]

would be good if we could solve this problem for the next release.

[Juergen Spitzmueller]

LyX 1.5.5svn is frozen.

[Juergen Spitzmueller]

Jean-Marc, I tested your patch, and I think it's a big improvement over the
current situation (the only remaining glitch I found is with quotation marks:
word-forward on the string «text» jumps in front of the closing quote instead
of after it; thus word-delete-forward when the cursor is in front of the
opening quotation mark leaves the closing quotation mark, which should be
deleted IMHO; however, this can be adjusted later).

I'd like include this fix to 1.5.6. Could you forward-port the fix to trunk and
apply it to both trees?

[Juergen Spitzmueller]

You might also want to have another look at #2815. The behaviour on the
outlined test case has changed, but is not good yet IMHO. A constructed dash
(--, ---) is deleted piece by piece instead of at once, and a hyphen preceded
by a blank is regarded as part of the preceeding word, which should not be the
case.

Try word-delete-backward on
a.) test --- test
b.) test - test

Should result in
a.) test --- ; test
b.) test - ; test

Does (with the patch) result in:

a.) test --- ; test -- ; test - ; <nothing>
b.) <nothing>

[Juergen Spitzmueller]

You might also want to have another look at #2815. The behaviour on the
outlined test case has changed,

I mean: with the patch in comment 14.

b.) test - test

Does (with the patch) result in:

b.) <nothing>

Correction: Does (with the patch) result in:

b.) test - ; <nothing>

[lasgouttes]

I am currently (slowly) looking at it. In particular, it jumps over texts
insets (think charstyles), which is not good.

[Juergen Spitzmueller]

Jean Marc's patch (against current 1.5.6svn)

[Juergen Spitzmueller]

Excellent. I'll have a look soon.

[lasgouttes]

The same idea, but re-using the isChar concept instead of creating a new isOther.

[lasgouttes]

A new try (against trun, but works for branch too)

[lasgouttes]

Patch committed to trunk:

URL: ​http://www.lyx.org/trac/changeset/25373
Log:
Fix bug #3580

• Paragraph.cpp (isChar): new method; returns true when pointer is on a character that is not a letter. Note that a footnote inset, for example is neither a letter nor a character.

• Text.cpp (cursorForwardOneWord, cursorBackwardOneWord): rewrite by using 3 character categories: letters, characters and others.

Modified:

lyx-devel/trunk/src/Paragraph.cpp
lyx-devel/trunk/src/Paragraph.h
lyx-devel/trunk/src/Text.cpp

[lasgouttes]

Stupid typo, so:

URL: ​http://www.lyx.org/trac/changeset/25375
Log:
stupid off-by-one error in r25373

Modified:

lyx-devel/trunk/src/Text.cpp

...

• if (pos != 0 && !par.isLetter(pos) && !par.isChar(pos - 1))

+ if (pos != 0 && !par.isLetter(pos - 1) && !par.isChar(pos - 1))
...

[hha4491@…]

This is one of the biggest problem of programming languages which start
counting with 0 instead of 1.
Anyway, your solution seems to do the job eventually. As Jürgen wrote:
Excellent, Jean-Marc.

[lasgouttes]

Not really, it is just that, when moving backwards, one has to condition on
character _before_ cursor.

[Juergen Spitzmueller]

It's a big improvement. However, there are still some glitches IMHO, but I
guess you are aware of them.

• word-forward jumps over punctuation after words, so if I delete the last word

of a sentence, the punctuation is also deleted, which should not be the case
IMHO.

• quotation marks handling

• #2815.

I don't have much time for testing myself ATM, but if people like the behaviour
in trunk, you can commit to branch as well.

[hha4491@…]

• word-forward jumps over punctuation after words, so if I delete the last

word of a sentence, the punctuation is also deleted, which should not be the
case IMHO.

• quotation marks handling
• #2815.

Although this behaviour is annoying many KDE programs and others like Opera do
exactly this. Some of course, like OpenOffice, Kate, KWrite ... do what they
are supposed to do, and this should be our aim.

[hha4491@…]

The jumps and deletions should take that part of the text that a double-click
wouild select.

[Juergen Spitzmueller]

My idea is the following: we should follow the idea of "nested entities", which
are not syntactic entities in a linguistic sense (this is not possible to get
right technically), but rather (and much more trivial) "formal" entities. Words
are nested into sentence parts and sentences, and those are nested into
paragraphs. And we should never delete two entities in one step. That's why
punctuation should not be deleted when the final word is deleted: this
would "delete" the parent entity (the sentence) together with one nested entity
(a word) (delete insofar as we end up with one sentence where we had two). For
the same reason, a dash should not be deleted together with the preceeding word
(#2815), because a dash is a boundary signal between two formal parts of a
sentence. The same applies to quotation marks that are some kind of semantic
boundary signals, and we should either delete the whole expression including
the quotation mark or just the quotation mark (ideally we should delete the
pair of quotation marks in one step, but since this is too tricky, just each
single quotation mark -- but not, as we do now, the word and just the opening
quotation mark).

[lasgouttes]

Regarding comment 26:

• word-forward jumps over punctuation after words, so if I delete the last word

of a sentence, the punctuation is also deleted, which should not be the case

IMHO.

This is what mac osx and emacs do. My plan is to implement both this (the
current one) and the windows/qt version of work skipping. I think I'll just copy
the qt algorithm (note that qt/mac does not do the right mac thing).

• quotation marks handling

These are handled like any other punctuation character.

Regarding comment 28:

The jumps and deletions should take that part of the text that a double-click
wouild select.

Yes, I will eventually take care of that.

comment 29:

My idea is the following: we should follow the idea of "nested entities", which
are not syntactic entities in a linguistic sense (this is not possible to get
right technically), but rather (and much more trivial) "formal" entities.

My plan is simpler: implement the windows way and the mac way, and let people
choose.

[lasgouttes]

I implemented both mac-like movement and windows-like movement in trunk now.
​http://www.lyx.org/trac/changeset/25413

Word-level cursor movement is almost correct now, except maybe

• a GUI access to the new lyxrc setting. Is it really necessar, or is it a

OS-dependent settng?

• special tretment for single quote, as in "don't"?

[Juergen Spitzmueller]

both #2815 and this one are fixed on linux now, IMO. Word movement is as I
would expect it.

Jean-Marc, I'd appreciate if you could backport and commit these changes to
branch.

[lasgouttes]

The patch(es) have been applied to branch too.
URL: ​http://www.lyx.org/trac/changeset/25417
Log:

• Paragraph.cpp (isChar): new method; returns true when pointer is on a character that is not a letter. Note that a footnote inset, for example is neither a letter nor a character. (isSpace): new method too.

• LyXRC.cpp:
• development/MacOSX/lyxrc.dist.in: new variable mac_like_word_movement, set to true on Mac OS X. There is no GUI for it now.

• src/Text.cpp (cursorForwardOneWord, cursorBackWardOneWord): implement mac-like and windows like cursor movement. Fix bugs 2815 and 3580.

[hha4491@…]

It looks o. k. for me, too.

[Juergen Spitzmueller]

1.5.6 is ready. Marking FIXED.

[karlrt@…]

hi, i have the 1.6.1 backport for ubuntu hardy, i386, just tried it out with
glipper, and it still produces (with or without compiz) weard behaviour when
trying to mark things with the mouse

But only under the following curcumstances:

glipper on, with the option "middle mouse-button" on too.

Then in lyx, you just cant mark things: While holding mousebutton and moving
the mouse, it will mark and change the color(sometimes not even this is done),
but when releasing the mousebutton, the marking is just gone.

Works like charm when the described glipper option is not on!

I was not shure if i should open a new bug, or if its this one, as i never
tried out 1.5.x, i thought as it says it should have been fixed in 1.6. So i
decided to reopen this one. If im wrong pls point it out...

[Juergen Spitzmueller]

Please open a new report. This was about something different.