On Fri, Nov 21, 2014 at 4:37 PM, Alfredo Braunstein <abrau...@lyx.org> wrote: > Btw, what you describe is similar to the behaviour of gedit (gtk), but > LyX behaviour is the same as the one of kate (qt)... So it seems that > there is no general consensus. There is a notable difference in what > happens when you move (arrows) with a selection going on: with the > current behaviour, the cursor is shown and you will move to the right > or left of that position. With the behaviour you describe, the only > rational thing is that if you go left you will move from the start of > the selection, if you move right you will move from the end of it.
I actually prefer the way that Jerry describes. However, I do not think that the way LyX does things is unarguably wrong. As Alfredo says, because of how LyX currently handles <Left> and <Right> (based on cursor position and does not depend on whether there is a selection), we show the cursor so that the user can know exactly where the cursor will be if she presses an arrow key. Further, we depend on the cursor position for various things. For example, if you have "abc<LyX note>" , if your cursor is right before "<LyX note>", then when you go to the Edit menu, you will get "Note settings". I do not like this behavior at all, but I mention this just to point out that LyX needs to know the cursor position. And if that is true, then it is useful for the user to also know the cursor position (so she can predict what LyX will do). The reason I like what Jerry describes is because I like the idea that once there is a selection, it doesn't matter how you got that selection (whether you double-clicked or dragged from left or dragged from right). Depending on the how the selection was made does not seem intuitive to me. Further, this leads to arbitrary cursor positioning. For example, when I double-click a word, the cursor goes to the end of that word. Why not the beginning? Under our system, it has to go somewhere so at the end makes sense, but it would be nice if it didn't have to go anywhere and was invisible. Scott > On Wed, Oct 29, 2014 at 9:30 AM, Jerry <lancebo...@qwest.net> wrote: >> >> On Oct 28, 2014, at 11:13 PM, Scott Kostyshak <skost...@lyx.org> wrote: >> >>> On Tue, Oct 28, 2014 at 11:24 PM, Jerry <lancebo...@qwest.net> wrote: >>>> >>>> On Oct 28, 2014, at 4:03 AM, Scott Kostyshak <skost...@lyx.org> wrote: >>>> >>>>> I have a patch that enables "word selection mode" on double click. It >>>>> seems to work well. The patch is here: >>>>> >>>>> http://www.lyx.org/trac/attachment/ticket/7890/0001-Fix-9160-and-7890.patch >>>>> >>>>> The only major issue is that when dragging to the left, you cannot >>>>> highlight the first word. Does anyone have an idea for where to fix >>>>> this? >>>>> >>>>> The following patch might give a clue as to where the problem is. When >>>>> applied, you can select the first word. It is not meant to be taken as >>>>> a correct patch: >>>>> >>>>> http://www.lyx.org/trac/attachment/ticket/7890/0002-HACK-just-to-show-where-the-problem-is.patch >>>>> >>>>> Scott >>>> >>>> Does this mean that upon a click-and-a-half, dragging extends the >>>> selection by whole words? >>> >>> Yes. See http://www.lyx.org/trac/ticket/7890 >>> >>> Scott >> >> I just looked at the patch, and I not understanding it but recalling how LyX >> currently works, I should add that after a multi-word selection has been >> made, either in character-selection mode (including possibly partial words) >> or word-selection mode, there should be no cursor. Gone. Only the selected >> text, highlighted. Lyx currently shows selected text _and_ a blinking >> cursor, which is wrong by Mac standards and arguably just wrong. The reason, >> I suppose, is that having selected text and a blinking cursor present >> confusing signals: where will text appear if I type now? The answer is, of >> course, that all of the selected text will be replaced with the newly typed >> text, and the replacement will begin as soon as the first new character is >> typed. Thus, any blinking cursor before typing new text is sending the wrong >> message and is also irrelevant. >> >> Jerry
