#121 Even more shortcuts

[DanielAjoy]

Similar to #103...

In the Command center line, when I pressed Ctrl+Home I expected the cursor to go to the first line of the Command History.

Also, in the Command center line, when I press Ctrl+Shift+Home I expected the whole history to be selected/highlighted.

In the Command center line, when I pressed Page Up I expected to cursor to move a page-full of lines within the Command History (as if the cursor was in the Command History area already)

[David Costanzo]

Those seem reasonable. I see you had suggested them previously as comments on Feature #103.

I hestitated to do the shortcuts mentioned in 103, mostly because workspace operations like LOAD and ERASE CONTENTS are a big deal and not something that needs to be made easy (and that Ctrl+L is not much easier than Alt+F, L). I think Jan was brainstorming ways to make FMSLogo "modern", not suggesting something which he personally would use (unlike you). Then I forgot about the request.

I hesitate even more at making the shortcuts configurable, not just because it's a lot of work to implement well, but it means that for shared user accounts, like "Student", it's possible for one user to mess up the shortcuts for another user without the other user being aware that such a thing is possible or how to fix it. That would be a frustration with little educational value, counter to the design goals of Logo.

Do you have opinions shortcuts mentioned in #103, or is all you want Ctrl+Home, Ctrl+Shift+Home, and PgUp?

[DanielAjoy]

I think

• Ctrl++
• Ctrl+-
• Ctrl+0

for zooming could be added too, though I don't personally use them.

Do you have opinions shortcuts mentioned in #103, or is all you want Ctrl+Home, Ctrl+Shift+Home, and PgUp?

Yes and I'm thinking that the Delete key within the Command History should delete selected text or otherwise delete the character to the right of the cursor within the Command History.

I remember that you added the Remove selected lines option, but I can't remember why not just use the Delete key.

And, in any case, I notice that the Number Pad Delete key does not have the same behaviour as the regular Delete key, the Number Pad Delete does nothing when the cursor is in the Command History box.

Also, I don't remember why the Right, Home and End keys when used in the Command History box have special behaviours, but I'm thinking that having all the arrow keys work the same way within the Command History box makes more sense.

The standard way to move back to the Command Line is the TAB key, or

• moving all the way down (out of the Command History box) using the Down arrow key, or
• moving all the way down using the Page Down key (this does not currently happen), or
• pressing Ctrl-End

I think that the current behaviour of marking text within the Command History using SHIFT-PgDown is the most useful behaviour:

• It does not leave the Command History box
• It preserves what was marked.
• It marks everything until the end of the Command History

This useful behaviour is lost when repeated SHIFT-Down arrow presses are used:

• It does not preserve what was marked.
• It does not mark everything until the end of the Command History

A demostration of this:

https://i.imgur.com/oxgZWXD.gif

The behaviour is also not implemented for Shift-Ctrl-End. "Ctrl-End" should mean the end of the Command History and Shift-Ctrl-End should mean: mark from here until the end of the Command History.

[David Costanzo]

I remember that you added the Remove selected lines option, but I can't remember why not just use the Delete key.

This is explained in the discussion on Feature Request 108. In short, I didn't like the idea of deleting the read-only history, especially if it could happen by accident because someone is used to the current behavior. I'd be surprised if anyone else (other than you) wants to delete select chunks of their history. I consider you an important user, so I wanted to give you a way to remove history, but not to make it so frictionless that it could be done by accident.

I notice that the Number Pad Delete key does not have the same behaviour as the regular Delete key, the Number Pad Delete does nothing when the cursor is in the Command History box.

I never noticed that. I don't have a Num Pad on my laptop, so it's only when I plug in a real keyboard that I can use one (even then, I usually don't use it). I suppose that Num Pad Delete should act the same as Delete. Is that what you're saying? Or are you hinting that it could act like the Delete within the history box.

Also, I don't remember why the Right, Home and End keys when used in the Command History box have special behaviours, but I'm thinking that having all the arrow keys work the same way within the Command History box makes more sense.

The way I used the history is not to navigate through it as a distinct UI control, but like a readline history on a UNIX command shell, closer to how UCBLogo works. That is, even though the history has focus and the cursor is moving around in it, I'm really looking at what is selected in the "Command Line" box and trying to select an instruction to re-run. The right arrow has the behavior I use (which is to edit the selected instruction before running it). I also use End, if I want to modify the end of the selected instruction. I left the left arrow for you, aware the lack of symmetry leads to confusing behavior.

I think our disagreement on the keyboard shortcuts comes from our different mental conception of what the commander history is. You think of it as a distinct control and I think of it as a poor implementation of a command shell history.

I don't mind adding alternate ways to jump from the Commander Line to the History when Ctrl or PgUp is used (as initially requested in this ticket). I'm less comfortable with alterating the ways of from getting from the History to the Command Line, especially when it takes away a navigation shortcut that I use.

This useful behaviour is lost when repeated SHIFT-Down arrow presses are used:

That looks like a bug. I think if SHIFT is held down, then Down arrow shouldn't hop to the "next instruction" box. It also shouldn't unselect stuff.

The behaviour is also not implemented for Shift-Ctrl-End. "Ctrl-End" should mean the end of the Command History and Shift-Ctrl-End should mean: mark from here until the end of the Command History.

I thought that was the behavior. Are you saying this should be the behavior when focus is in the Command Line? Or are you saying the current "Ctrl+End" behavior of the Command History is correct and it's how "Ctrl+Down Arrow" should behave?

[David Costanzo]

I think this is funny. It looks like I had gone out of my way to add that bug that makes the "down arrow" clear the selection. At the time, I was trying to make the wxWidgets version to act exactly like the OWL version, no matter how stupid the behavior was.

From commanderhistory.cpp:

    else if (keyCode == WXK_DOWN || keyCode == WXK_NUMPAD_DOWN)
    {
        // If the caret is already at the bottom, then give focus to edit box.
        if (!HasSelection() && IsCursorAtBottom())
        {
            GetCommander()->GetInput()->SetFocus();
        }
        else if (IsCursorAtBottom())
        {
            // The cursor is already at the bottom
            // so we don't have to move it.
            if (!Event.ControlDown())
            {
                // clear the selection to be consistent with MSWLogo
                SelectNone();
            }
        }
        else
        {
            MoveDown(1, flags);
            movedCaret = true;
        }
    }

[David Costanzo]

I was trying to make the wxWidgets version to act exactly like the OWL version, no matter how stupid the behavior was.

Turns out it was me that was stupid, not the OWL version. MSWLogo merely hid the selection, so if you moved back up, it would still be there. I don't see an easy way to do this with wxWidgets, so I made Shift+Down do nothing when at the bottom (the selection and focus remain the same). Pressing Down (without Shift) still clears the selection and moves to the Commander Line. This is done in [r4990].

[DanielAjoy]

I like this :)

[DanielAjoy]

I suppose that Num Pad Delete should act the same as Delete. Is that what you're saying?

Thanks, yes

Or are you hinting that it could act like the Delete within the history box.

No, I think the behavior should be consistent.

Or are you saying the current "Ctrl+End" behavior of the Command History is correct and it's how "Ctrl+Down Arrow" should behave?

Yes, I'm saying that in my opinion the Shift-Ctrl-End behaviour should be similar to the repeated application of Shift-PgDown:

• It does not leave the Command History box
• It preserves what was marked.
• It marks everything until the end of the Command History

[David Costanzo]

I suppose that Num Pad Delete should act the same as Delete. Is that what you're saying?

Thanks, yes

The fix for Num Pad Delete is now committed as [r4992]. It now behaves like Delete in the contexts where Delete is redirected to the Command Line.

[David Costanzo]

Daniel Ajoy wrote:

Yes, I'm saying that in my opinion the Shift-Ctrl-End behaviour should be similar to the repeated application of Shift-PgDown:
+ It does not leave the Command History box
+ It preserves what was marked.
+ It marks everything until the end of the Command History

Daniel, I've spent hours trying to undertand your request because, on my machine, on Wine, and on GNU/Linux, FMSLogo 7.5.0 behaves exactly like you've asked me to make it. However, I think I just figured it out. Please confirm that all you're asking for is that "End" on the NumPad behave like the normal "End".

Does your keyboard even have a regular (non-numpad) end? If you're using a laptop, can you try plugging in a full keyboard and seeing how End and NumPad End behave with the variations on Shift, Ctrl+Shift, and Ctrl?

[DanielAjoy]

I think our disagreement on the keyboard shortcuts comes from our different mental conception of what the commander history is. You think of it as a distinct control and I think of it as a poor implementation of a command shell history.

I think I might use it in a similar way to how you use it.

It is just that I usually to a lot of exploration running longer and longer commands in the Command Line and, some of those explorations lead nowhere, and I want to go back to a point higher in the Command History and forget about the dozens of lines of the most recent (unfruitful) exploration, by deleting it.

I do often use the option you kindly provided in the context menu "Eliminar Lineas Seleccionadas", it is just not as convenient as pressing the Delete key :)

[DanielAjoy]

Attached is that I use. I does have a separate NumPad, but it is a laptop.

However, I think I just figured it out. Please confirm that all you're asking for is that "End" on the NumPad behave like the normal "End".

You are correct, I hadn't noticed that Shift-Ctrl-NormalEnd does work as I expected:

• It does not leave the Command History box
• It preserves what was marked.
• It marks everything until the end of the Command History

I was expecting Shift-Ctrl-NumPadEnd to have the same behaviour. But instead when I press this key combination no text is highlighted in the Command History.

I would like Shift-Ctrl-NumPadEnd to behave like Shift-Ctrl-NormalEnd.

But also, currently, when I press Shift-NormalDown and Shift-NumPadDown repeatedly I'm eventually taken out of the Command History. I was expecting these key combinations to preserve what was marked.

(All these behaviours where identified using just the laptop, with no keyboard attached.)

[David Costanzo]

Daniel Ajoy wote:

You are correct, I hadn't noticed that Shift-Ctrl-NormalEnd does work as I expected:
[snip]
I was expecting Shift-Ctrl-NumPadEnd to have the same behaviour.

Great. Your laptop has the opposite problem as mine: mine doesn't have a NumPad and yours only has a NumPad. It's no wonder that I never noticed that NumPad navigation doesn't work as expected.

I'd classify the Ctrl+NumPad End as a bug, same as the NumPad+Delete thing. I can't think of a good reason why the NumPad navigation keys should act differently than the non-NumPad ones. (For reference, there's no practical difference between a feature request and a bug, except that calling it a bug is an admission of guilt.)

I know the conversation in this ticket has gotten a bit messy, so I'll summarize all of the changes that I think I'm done and provide you with an fmslogo-1034.exe to test out, just to make sure that I didn't miss anything. In the meantime, I'll continue to post updates as I fix things.

[David Costanzo]

I have made NumPad End act like End and NumPad Home act like Home in [r5000].

I have made Ctrl+Home and Ctrl+Shift+Home (and NumPad equivalents) from the commander input act as requested in [r5002].

I have made PageUp and Shift+PageUp (and NumPad equivalents) from the commander input act as requested in [r5004].

To summarize, the changes I have made for this feature request are:

1. Shift+Down at bottom of commander history no longer jumps to commander input box.
2. NumPad Delete now acts like Delete in commander history and on commander buttons (gives focus to commander input and deletes a character).
3. NumPad Home now acts like Home in the commander history.
4. NumPad End now acts like End in the commander history.
5. Ctrl+Home from commander input now jumps to top of the commander history.
6. Ctrl+Shift+Home from commander input now select everything in the
   commander history and jumps to the top of it.
7. PageUp and Shift+PageUp from commander input now act like as if the caret
   were at the bottom of the commander history.

I have attached a pre-release Spanish build (fmslogo-1034.exe) that includes these changes for you to evaluate them. Some of the new asymmetry feels a bit awkward to me (for example, PageDown at the bottom of the commander history not jumping to the commander input), but since I never use PageUp/PageDown for navigation, this won't affect my usage.

I haved marked this request as closed because I believe I have implemented everything that was request. If you find problems with it, post back and I will re-open it request, as waranted.

[DanielAjoy]

thanks! I'll start using this new version right away.