Discussion:
[PATCH] LFUN_DOWN: if cursor is on last line, move to end
Scott Kostyshak
2013-06-18 04:38:37 UTC
Permalink
This is consistent with gedit and gmail. The LFUN_DOWN_SELECT part is
consistent with Qt Creator; the rest is not, except breaking the
selection. It is not consistent with Libre Office, except for breaking
the selection.

It looks like this might be a personal preference.

Any thoughts?

Scott
Pavel Sanda
2013-06-18 06:02:48 UTC
Permalink
Scott Kostyshak wrote:
> It looks like this might be a personal preference.

Most probably ;) I wouldn't welcome this kind of behaviour.
Pavel
Kornel Benko
2013-06-18 07:43:39 UTC
Permalink
Am Montag, 17. Juni 2013 um 23:02:48, schrieb Pavel Sanda <***@lyx.org>
> Scott Kostyshak wrote:
> > It looks like this might be a personal preference.
>
> Most probably ;)

+1

> I wouldn't welcome this kind of behaviour.
> Pavel

And I like it (being consistent, that is). ;)
Kornel
Scott Kostyshak
2013-06-19 18:36:22 UTC
Permalink
On Tue, Jun 18, 2013 at 3:43 AM, Kornel Benko <***@lyx.org> wrote:
> Am Montag, 17. Juni 2013 um 23:02:48, schrieb Pavel Sanda <***@lyx.org>
>
>> Scott Kostyshak wrote:
>
>> > It looks like this might be a personal preference.
>
>>
>
>> Most probably ;)
>
>
>
> +1

Good to know. Thanks for the confirmation.

Scott
Pavel Sanda
2013-06-19 19:55:47 UTC
Permalink
Kornel Benko wrote:
> being consistent, that is). ;)

Consistent with what?
I just tried OpenOffice and M$ Word, both are consistent not to do it by default.
(None terminal editors I use do this by default, but that's not fair comparison
in similar way as gmail is not co be counted ;)

Should we do begining-of-line when in the first lien to be consistent as well?

Pavel
Scott Kostyshak
2013-06-20 02:06:03 UTC
Permalink
On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda <***@lyx.org> wrote:
> Should we do begining-of-line when in the first lien to be consistent as well?

This is what I was suggesting (and is implemented in the patch). It is
clearly not popular though.

Scott
Cyrille Artho
2013-06-20 02:56:07 UTC
Permalink
I actually don't mind that much if the behavior changes. It may be nice to
have a setting for this, though (even though most users will not change the
default).

Scott Kostyshak wrote:
> On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda <***@lyx.org> wrote:
>> Should we do begining-of-line when in the first lien to be consistent as well?
>
> This is what I was suggesting (and is implemented in the patch). It is
> clearly not popular though.
>
> Scott
>

--
Regards,
Cyrille Artho - http://artho.com/
Military justice is to justice what military music is to music.
-- Groucho Marx
Pavel Sanda
2013-06-20 06:56:09 UTC
Permalink
Scott Kostyshak wrote:
> This is what I was suggesting (and is implemented in the patch). It is
> clearly not popular though.

You really find this useful? Single hit of end key bring me to the end while
there is no comparable jump back to original row in case I hit down arrow more
times than actually needed (which is typical if I just quickly move through the
document).

Pavel
Kornel Benko
2013-06-20 07:31:13 UTC
Permalink
Am Mittwoch, 19. Juni 2013 um 23:56:09, schrieb Pavel Sanda <***@lyx.org>
> Scott Kostyshak wrote:
> > This is what I was suggesting (and is implemented in the patch). It is
> > clearly not popular though.
>
> You really find this useful? Single hit of end key bring me to the end while
> there is no comparable jump back to original row in case I hit down arrow more
> times than actually needed (which is typical if I just quickly move through the
> document).

It is not only move the cursor, but also selecting parts of text.
1.) Start selection somewhere in the middle of last paragraph
2.) Select with keys (at least in emacs bind) Shift-Down till the end
3.) Now you have to change to Shift-Ctrl-E to reach the the end

> Pavel

Kornel
Pavel Sanda
2013-06-20 07:42:41 UTC
Permalink
Kornel Benko wrote:
> It is not only move the cursor, but also selecting parts of text.

I agree that for selecting text it feels more natural (basically
because one tends to be more careful about each keystroke compared
to the situation when you just move in the document).

But that does not explain why don't you simply use ctrl+shift+end.

Pavel
Kornel Benko
2013-06-20 07:47:36 UTC
Permalink
Am Donnerstag, 20. Juni 2013 um 00:42:41, schrieb Pavel Sanda <***@lyx.org>
> Kornel Benko wrote:
> > It is not only move the cursor, but also selecting parts of text.
>
> I agree that for selecting text it feels more natural (basically
> because one tends to be more careful about each keystroke compared
> to the situation when you just move in the document).
>
> But that does not explain why don't you simply use ctrl+shift+end.
>

Have you tried? It feels uhm complicated.

Kornel
Pavel Sanda
2013-06-20 08:48:29 UTC
Permalink
Kornel Benko wrote:
> > But that does not explain why don't you simply use ctrl+shift+end.
>
> Have you tried? It feels uhm complicated.

Yes I have. It didn't look so bad to me, bad as said in the selection
scenario the proposal makes more sense compared to just movement.

Pavel
Scott Kostyshak
2013-06-20 14:07:15 UTC
Permalink
On Thu, Jun 20, 2013 at 2:56 AM, Pavel Sanda <***@lyx.org> wrote:
> Scott Kostyshak wrote:
>> This is what I was suggesting (and is implemented in the patch). It is
>> clearly not popular though.
>
> You really find this useful?

I do, but I recognize that I'm strange in this sense.

Scott
Jean-Marc Lasgouttes
2013-06-20 08:37:51 UTC
Permalink
What does OSX do? This could be part of our mac-like cursor handling.

JM arc


Scott Kostyshak <***@lyx.org> a écrit :

>On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda <***@lyx.org> wrote:
>> Should we do begining-of-line when in the first lien to be consistent
>as well?
>
>This is what I was suggesting (and is implemented in the patch). It is
>clearly not popular though.
>
>Scott

--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la briÚveté.
Stephan Witt
2013-06-20 10:33:06 UTC
Permalink
Am 20.06.2013 um 10:37 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> What does OSX do?

It moves to the very end of the last paragraph and does the same while extending the selection.

> This could be part of our mac-like cursor handling.

Yes, indeed. It should be part of it, IMHO.

Stephan

>
> JM arc
>
>
> Scott Kostyshak <***@lyx.org> a écrit :
> On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda <***@lyx.org> wrote:
> Should we do begining-of-line when in the first lien to be consistent as well?
>
> This is what I was suggesting (and is implemented in the patch). It is
> clearly not popular though.
>
> Scott
>
> --
> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Stephan Witt
2013-06-20 11:01:40 UTC
Permalink
Am 20.06.2013 um 12:33 schrieb Stephan Witt <***@gmx.net>:

> Am 20.06.2013 um 10:37 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>
>> What does OSX do?
>
> It moves to the very end of the last paragraph and does the same while extending the selection.
>
>> This could be part of our mac-like cursor handling.
>
> Yes, indeed. It should be part of it, IMHO.

This patch would do it. It's a replacement of Scott's patch.

Stephan

>>
>> Scott Kostyshak <***@lyx.org> a écrit :
>> On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda <***@lyx.org> wrote:
>> Should we do begining-of-line when in the first lien to be consistent as well?
>>
>> This is what I was suggesting (and is implemented in the patch). It is
>> clearly not popular though.
>>
>> Scott
>>
>> --
>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Jean-Marc Lasgouttes
2013-06-20 14:09:37 UTC
Permalink
20/06/2013 13:01, Stephan Witt:
> Am 20.06.2013 um 12:33 schrieb Stephan Witt <***@gmx.net>:
>
>> Am 20.06.2013 um 10:37 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>
>>> What does OSX do?
>>
>> It moves to the very end of the last paragraph and does the same while extending the selection.
>>
>>> This could be part of our mac-like cursor handling.
>>
>> Yes, indeed. It should be part of it, IMHO.
>
> This patch would do it. It's a replacement of Scott's patch.

I like the patch. Tow remarks:

* be acreful about indetation, use tabs instead of spaces

* are you sure that the nested if() do the right thing in all cases?

JMarc
Stephan Witt
2013-06-20 14:37:58 UTC
Permalink
Am 20.06.2013 um 16:09 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> 20/06/2013 13:01, Stephan Witt:
>> Am 20.06.2013 um 12:33 schrieb Stephan Witt <***@gmx.net>:
>>
>>> Am 20.06.2013 um 10:37 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>
>>>> What does OSX do?
>>>
>>> It moves to the very end of the last paragraph and does the same while extending the selection.
>>>
>>>> This could be part of our mac-like cursor handling.
>>>
>>> Yes, indeed. It should be part of it, IMHO.
>>
>> This patch would do it. It's a replacement of Scott's patch.
>
> I like the patch. Tow remarks:
>
> * be acreful about indetation, use tabs instead of spaces

I'll correct this… if I do the changes with Xcode it's always wrong.

>
> * are you sure that the nested if() do the right thing in all cases?

Yes. Originally it was:

if (!atFirstOrLastRow) {
do_something();
}

now it is:

if (atFirstOrLastRow) {
if (lyxrc.mac_like_cursor_movement) {
scotts_doing();
}
// do nothing - Pavels preference
} else {
do_something();
}

Ok?

Stephan
Jean-Marc Lasgouttes
2013-06-20 16:00:02 UTC
Permalink
20/06/2013 16:37, Stephan Witt:
> Yes. Originally it was:
>
> if (!atFirstOrLastRow) {
> do_something();
> }
>
> now it is:
>
> if (atFirstOrLastRow) {
> if (lyxrc.mac_like_cursor_movement) {
> scotts_doing();
> }
> // do nothing - Pavels preference
> } else {
> do_something();
> }
>
> Ok?

What would happen with
if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement)
?

I ask because I do not really understand why the last else{} clause is
removed.

I should probably try it myself :)

JMarc
Stephan Witt
2013-06-21 06:42:11 UTC
Permalink
Am 20.06.2013 um 18:00 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> 20/06/2013 16:37, Stephan Witt:
>> Yes. Originally it was:
>>
>> if (!atFirstOrLastRow) {
>> do_something();
>> }
>>
>> now it is:
>>
>> if (atFirstOrLastRow) {
>> if (lyxrc.mac_like_cursor_movement) {
>> scotts_doing();
>> }
>> // do nothing - Pavels preference
>> } else {
>> do_something();
>> }
>>
>> Ok?
>
> What would happen with
> if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement)
> ?

That's possible - to avoid another nesting level - with:

if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement) {
scotts_doing(); // new behavior - mac like
} else if (!atFirstOrLastRow) {
do_something(); // original "if" code
}

Looks good too.

Stephan

>
> I ask because I do not really understand why the last else{} clause is removed.
>
> I should probably try it myself :)
>
> JMarc
Scott Kostyshak
2013-06-24 06:34:53 UTC
Permalink
On Fri, Jun 21, 2013 at 2:42 AM, Stephan Witt <***@gmx.net> wrote:
> Am 20.06.2013 um 18:00 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>
>> 20/06/2013 16:37, Stephan Witt:
>>> Yes. Originally it was:
>>>
>>> if (!atFirstOrLastRow) {
>>> do_something();
>>> }
>>>
>>> now it is:
>>>
>>> if (atFirstOrLastRow) {
>>> if (lyxrc.mac_like_cursor_movement) {
>>> scotts_doing();
>>> }
>>> // do nothing - Pavels preference
>>> } else {
>>> do_something();
>>> }
>>>
>>> Ok?
>>
>> What would happen with
>> if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement)
>> ?
>
> That's possible - to avoid another nesting level - with:
>
> if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement) {
> scotts_doing(); // new behavior - mac like
> } else if (!atFirstOrLastRow) {
> do_something(); // original "if" code
> }
>
> Looks good too.
>
> Stephan
>
>>
>> I ask because I do not really understand why the last else{} clause is removed.
>>
>> I should probably try it myself :)
>>
>> JMarc
>

The patch I posted was wrong. When in an inset, if you go up, you go
to the beginning of the buffer. Using LFUN_INSET_BEGIN_SELECT is more
reasonable, but is that what we want? Do we want this behavior only on
the first and last line of the buffer? LFUN_UP inside an inset should
not be changed from the current behavior. It's less clear for
LFUN_UP_SELECT inside an inset.

Scott
Stephan Witt
2013-06-24 15:13:12 UTC
Permalink
Am 24.06.2013 um 08:34 schrieb Scott Kostyshak <***@lyx.org>:

> On Fri, Jun 21, 2013 at 2:42 AM, Stephan Witt <***@gmx.net> wrote:
>> Am 20.06.2013 um 18:00 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>
>>> 20/06/2013 16:37, Stephan Witt:
>>>> Yes. Originally it was:
>>>>
>>>> if (!atFirstOrLastRow) {
>>>> do_something();
>>>> }
>>>>
>>>> now it is:
>>>>
>>>> if (atFirstOrLastRow) {
>>>> if (lyxrc.mac_like_cursor_movement) {
>>>> scotts_doing();
>>>> }
>>>> // do nothing - Pavels preference
>>>> } else {
>>>> do_something();
>>>> }
>>>>
>>>> Ok?
>>>
>>> What would happen with
>>> if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement)
>>> ?
>>
>> That's possible - to avoid another nesting level - with:
>>
>> if (atFirstOrLastRow && lyxrc.mac_like_cursor_movement) {
>> scotts_doing(); // new behavior - mac like
>> } else if (!atFirstOrLastRow) {
>> do_something(); // original "if" code
>> }
>>
>> Looks good too.
>>
>> Stephan
>>
>>>
>>> I ask because I do not really understand why the last else{} clause is removed.
>>>
>>> I should probably try it myself :)
>>>
>>> JMarc
>>
>
> The patch I posted was wrong. When in an inset, if you go up, you go
> to the beginning of the buffer. Using LFUN_INSET_BEGIN_SELECT is more
> reasonable, but is that what we want? Do we want this behavior only on
> the first and last line of the buffer? LFUN_UP inside an inset should
> not be changed from the current behavior. It's less clear for
> LFUN_UP_SELECT inside an inset.

Ooops… You're right, of course. Thank you.

I've made another attempt to do it right.

This implements the mac-like behavior when being at the first/last line of the document.
I tried to find an application with the concept of an inset and couldn't find any.
So I decided to leave the behavior for inset boundaries untouched.

Stephan
Scott Kostyshak
2013-06-24 16:59:38 UTC
Permalink
On Mon, Jun 24, 2013 at 11:13 AM, Stephan Witt <***@gmx.net> wrote:
> Am 24.06.2013 um 08:34 schrieb Scott Kostyshak <***@lyx.org>:

>> The patch I posted was wrong. When in an inset, if you go up, you go
>> to the beginning of the buffer. Using LFUN_INSET_BEGIN_SELECT is more
>> reasonable, but is that what we want? Do we want this behavior only on
>> the first and last line of the buffer? LFUN_UP inside an inset should
>> not be changed from the current behavior. It's less clear for
>> LFUN_UP_SELECT inside an inset.
>
> Ooops… You're right, of course. Thank you.
>
> I've made another attempt to do it right.
>
> This implements the mac-like behavior when being at the first/last line of the document.
> I tried to find an application with the concept of an inset and couldn't find any.
> So I decided to leave the behavior for inset boundaries untouched.

Thanks, Stephan. I tested your patch and it works well. But since it
touches some important parts of the code, should we wait until 2.1.1?

Scott
Stephan Witt
2013-06-24 21:56:14 UTC
Permalink
Am 24.06.2013 um 18:59 schrieb Scott Kostyshak <***@lyx.org>:

> On Mon, Jun 24, 2013 at 11:13 AM, Stephan Witt <***@gmx.net> wrote:
>> Am 24.06.2013 um 08:34 schrieb Scott Kostyshak <***@lyx.org>:
>
>>> The patch I posted was wrong. When in an inset, if you go up, you go
>>> to the beginning of the buffer. Using LFUN_INSET_BEGIN_SELECT is more
>>> reasonable, but is that what we want? Do we want this behavior only on
>>> the first and last line of the buffer? LFUN_UP inside an inset should
>>> not be changed from the current behavior. It's less clear for
>>> LFUN_UP_SELECT inside an inset.
>>
>> Ooops… You're right, of course. Thank you.
>>
>> I've made another attempt to do it right.
>>
>> This implements the mac-like behavior when being at the first/last line of the document.
>> I tried to find an application with the concept of an inset and couldn't find any.
>> So I decided to leave the behavior for inset boundaries untouched.
>
> Thanks, Stephan. I tested your patch and it works well. But since it
> touches some important parts of the code, should we wait until 2.1.1?


Thanks for testing it.

Yes, I think it has to wait. I didn't want to duplicate code and therefor refactored it.
But, I'm not sure what the state of trunk currently is…

Stephan
Jean-Marc Lasgouttes
2013-06-25 09:30:18 UTC
Permalink
Le 24/06/2013 17:13, Stephan Witt a écrit :
> +bool Cursor::atFirstOrLastRowOfDocument(bool up)
> +{
> + Cursor dummy = *this;
> + bool result = dummy.atFirstOrLastRow(up);
> + for(; result && dummy.depth(); dummy.pop())
> + result = dummy.atFirstOrLastRow(up);
> + return result;
> +}

I do not understand this code. Why not just return
bottom().atFirstOrLastRow(up)
?

The value of result is overwritten until the bottom of the stack.

JMarc
Stephan Witt
2013-06-25 10:19:54 UTC
Permalink
Am 25.06.2013 um 11:30 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> Le 24/06/2013 17:13, Stephan Witt a écrit :
>> +bool Cursor::atFirstOrLastRowOfDocument(bool up)
>> +{
>> + Cursor dummy = *this;
>> + bool result = dummy.atFirstOrLastRow(up);
>> + for(; result && dummy.depth(); dummy.pop())
>> + result = dummy.atFirstOrLastRow(up);
>> + return result;
>> +}
>
> I do not understand this code. Why not just return
> bottom().atFirstOrLastRow(up)
> ?

cursor.bottom().atFirstOrLastRow(up) is not defined. :(

>
> The value of result is overwritten until the bottom of the stack.

The value of "result" is checked on every loop.
The loop stops at the first cursor slice not atFirstOrLastRow.
Then the method returns false.

Perhaps it's more readable to write "result && dummy.depth() > 0"?

The idea of the loop is copied (moved) from Cursor::upDownInText().

Stephan
Stephan Witt
2013-06-26 08:07:47 UTC
Permalink
Am 25.06.2013 um 12:19 schrieb Stephan Witt <***@gmx.net>:

> Am 25.06.2013 um 11:30 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>
>> Le 24/06/2013 17:13, Stephan Witt a écrit :
>>> +bool Cursor::atFirstOrLastRowOfDocument(bool up)
>>> +{
>>> + Cursor dummy = *this;
>>> + bool result = dummy.atFirstOrLastRow(up);
>>> + for(; result && dummy.depth(); dummy.pop())
>>> + result = dummy.atFirstOrLastRow(up);
>>> + return result;
>>> +}
>>
>> I do not understand this code. Why not just return
>> bottom().atFirstOrLastRow(up)
>> ?
>
> cursor.bottom().atFirstOrLastRow(up) is not defined. :(
>
>>
>> The value of result is overwritten until the bottom of the stack.
>
> The value of "result" is checked on every loop.
> The loop stops at the first cursor slice not atFirstOrLastRow.
> Then the method returns false.
>
> Perhaps it's more readable to write "result && dummy.depth() > 0"?


How does this look?

bool Cursor::atFirstOrLastRowOfDocument(bool up)
{
Cursor dummy = *this;
bool result = dummy.atFirstOrLastRow(up);
while (result && dummy.depth() > 1) {
dummy.pop();
result = dummy.atFirstOrLastRow(up);
}
return result;
}

Stephan
Jean-Marc Lasgouttes
2013-06-26 08:39:14 UTC
Permalink
Le 25/06/2013 12:19, Stephan Witt a écrit :
>> The value of result is overwritten until the bottom of the stack.
>
> The value of "result" is checked on every loop.
> The loop stops at the first cursor slice not atFirstOrLastRow.
> Then the method returns false.

Doh! The worst part is that I read it several times.

JMarc
Jean-Marc Lasgouttes
2013-06-26 08:41:18 UTC
Permalink
Le 26/06/2013 10:07, Stephan Witt a écrit :
> How does this look?
>
> bool Cursor::atFirstOrLastRowOfDocument(bool up)
> {
> Cursor dummy = *this;
> bool result = dummy.atFirstOrLastRow(up);
> while (result && dummy.depth() > 1) {
> dummy.pop();
> result = dummy.atFirstOrLastRow(up);
> }
> return result;
> }

Yes, I prefer this version.

JMarc
Stephan Witt
2013-06-26 09:49:59 UTC
Permalink
Am 26.06.2013 um 10:41 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> Le 26/06/2013 10:07, Stephan Witt a écrit :
>> How does this look?
>>
>> bool Cursor::atFirstOrLastRowOfDocument(bool up)
>> {
>> Cursor dummy = *this;
>> bool result = dummy.atFirstOrLastRow(up);
>> while (result && dummy.depth() > 1) {
>> dummy.pop();
>> result = dummy.atFirstOrLastRow(up);
>> }
>> return result;
>> }
>
> Yes, I prefer this version.
>
> JMarc

That's the final patch then.

Stephan
Scott Kostyshak
2013-07-06 00:50:00 UTC
Permalink
On Wed, Jun 26, 2013 at 5:49 AM, Stephan Witt <***@gmx.net> wrote:
> Am 26.06.2013 um 10:41 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>
>> Le 26/06/2013 10:07, Stephan Witt a écrit :
>>> How does this look?
>>>
>>> bool Cursor::atFirstOrLastRowOfDocument(bool up)
>>> {
>>> Cursor dummy = *this;
>>> bool result = dummy.atFirstOrLastRow(up);
>>> while (result && dummy.depth() > 1) {
>>> dummy.pop();
>>> result = dummy.atFirstOrLastRow(up);
>>> }
>>> return result;
>>> }
>>
>> Yes, I prefer this version.
>>
>> JMarc
>
> That's the final patch then.
>

Should this be committed to 2.1?

Scott
Scott Kostyshak
2014-05-07 22:18:00 UTC
Permalink
On Fri, Jul 5, 2013 at 8:50 PM, Scott Kostyshak <***@lyx.org> wrote:
> On Wed, Jun 26, 2013 at 5:49 AM, Stephan Witt <***@gmx.net> wrote:
>> Am 26.06.2013 um 10:41 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

>>> Yes, I prefer this version.
>>>
>>> JMarc
>>
>> That's the final patch then.
>>
>
> Should this be committed to 2.1?

Did this patch get forgotten or was this resolved in a different email thread?

Scott
Loading...