#821 Allow moving the cursor anywhere in the editor

[Masao Kasuya]

It would be helpful if we could select words in any original segment on the Editor pane by using the keyboard rather than the mouse. It would facilitate, for example, copy and search operations on the original segments. This feature would require a keyboard shortcut to switch the cursor position between the original and target segments.

[Didier Briel]

I suggest "F2" for the shortcut. In a number of systems, "F2" means "switch to edition" mode. I'm not sure F2 should selection to the original segment, rather than let the user move freely (one could want to select something from the previous segment, etc.). A subsequent F2 would bring back the cursor in the usual "locked mode" inside the current target segment.

Didier

[Masao Kasuya]

Didier,
The user may want to select a portion that is not in the current original segment, so I like your idea of allowing the user to move the cursor freely between segments. F2 is fine with me, too.

[Masao Kasuya]

Pressing F2 a second time brings the cursor back to the current target segment. This is nice. It would be all the more nice if the same thing happens when the cursor is in the search window or one of the subordinate panes.

[Jean-Christophe Helary]

I was trying the cursor displacement feature in the "accessory" panes yesterday and the problem was that to move out of the editor, you need to use the mouse and click on the target pane because [tab] will always add a [tab] character to the target field instead of moving to other panes (like it does when it is in other panes).

Using F2 (for ex) should trigger the selection mode in the Editor with free movement in the Editor window using the standard shortcuts *and* lock the [tab] key so that it can be used to move from pane to pane directly from the Editor window.

[Didier Briel]

<< [tab] will always add a
[tab] character to the target field instead of moving to other panes (like
it does when it is in other panes).>>

No, you can use Ctrl+Tab to go to another pane (Ctrl+Shift+Tab brings you back to the previous pane).

So, there's no need to develop something specific for moving between panes.

Didier

[Jean-Christophe Helary]

Indeed. I was not aware of that. That's a shortcut that should be documented in the manual.

[Kos Ivantsov]

Is it worth integrating this into OmegaT?
https://gist.github.com/yu-tang/a6833d687e436ddd5135

From my tests I can tell it works exactly as requested.
The shortcut might be moved into MainMenuShortcuts.properties, and script messages into Status bar and/or Log (and Bundle.properties)

--
Kos

[Aaron Madlon-Kay]

To be honest, that script is a clever hack but it's something I would never want to incorporate as-is. It's a conceptual nightmare for non-expert users: Why is the text editable? What happens if you edit the text? If you can edit the text, are the changes saved to the source files? Why not?

And all that for what? So you can copy parts of the source with the keyboard. But what is the use case for that that isn't covered by something simpler like copying the source text to the clipboard? And what is the majority use case for that if not search, which will be covered by the Edit menu anyway?

[Kos Ivantsov]

In my work there are often long sentences with whole bunch of digits (references to volumes and chapters, or chapters and verses, and the like). Inserting the whole source and deleting original non-numeric parts to keep only the numbers is annoying, and currently I have to use mouse to select parts or the source I want to use.

It's trivial to disable editing by eding:
setEditable false getCaret().setVisible(true))
in the part of the script where JEditorPane is defined. Of course there might be a more elegant way, as I ain't no programmer.

It would be cool if there was a way to trigger the way Editor response to key strokes (ie pressing F2 would make the whole Editor pane uneditable, but the caret would still be shown, arrow keys would move the caret through the whole pane, and select with keyboard would be possible, pressing it again would bring caret back to target, make target editable and focus it). Then this hack wouldn't be needed.

And as to using it for the search, I much more often need to search for substrings than for the whole source segment, so being able to select the search substring with the keyboard rather than putting the whole source segment and deleting the parts I don't need, would be very much appreciated.

--
Kos

[Didier Briel]

Why is the text editable?

I think that's the major issue with the script. When the cursor is available in the Glossary pane, for instance, it doesn't allow editing the source text.

But what is the use case for that that isn't covered by something simpler like copying the source text to the clipboard?

Having the full source text in the clipboard isn't a straightforward way of selecting a part of the source text.

And what is the majority use case for that if not search, which will be covered by the Edit menu anyway?

I frequently select part of the source text for:
Searching in a external resource (using the ExternalFinder plugin)
Select what to put in the glossary (before pressing Ctrl+Shift+G)

Didier

[Aaron Madlon-Kay]

Regarding partial selection, fair enough.

Another thing I'm not a fan of in the script is the use of a separate dialog to house the source text. The only benefit I can see to it is that you can Ctrl+A to select all. Otherwise I would prefer to simply (temporarily) disable the cursor-locking functionality of the EditorTextArea and let the cursor roam around the entire editor.

Do people see significant utility in the separate dialog?

[Didier Briel]

I would prefer to simply (temporarily) disable the cursor-locking functionality of the EditorTextArea and let the cursor roam around the entire editor.

That was the idea of the RFE, and I would much prefer it.

Didier

[Kos Ivantsov]

I would prefer to simply (temporarily) disable the cursor-locking functionality of the EditorTextArea and let the cursor roam around the entire editor.

That was the idea of the RFE, and I would much prefer it.

If that was possible, I would prefer that too. Besides, in the script there are provisions only for adding glossary term and searching. There's no way to use ExternalFinder pluging, and the context menu isn't invokable. Probably, none of this would be an issue if the Editor pane let the cursor roam across the whole thing.

--
Kos

[Yu Tang]

I don't want to integrate my script as is. It's just a workaround until RFE closed (as crearly wrote in Japanese readme).
If I've satisfied that approach, I might committed changes to trunk few months ago instead of script wrote.
It's just a "something better than nothing" until someone implements REAL fix.

Another thing I'm not a fan of in the script is the use of a separate dialog to house the source text.

Me too. :)
It's easy and safe to use dialog than manipurating Editor directly from script, for me. I don't want to see accidentally changing real source text in Editor. That's the reason.

[Aaron Madlon-Kay]

Thanks, Yu Tang. I think your intent was clear from the readme, but of course it wasn't apparent to many of us.

I have a prototype implementation of this here:
https://omegat.ci.cloudbees.com/job/omegat-prototype/3/

[Aaron Madlon-Kay]

It would be useful to have feedback on behavior in the following situation:

1. Disable cursor locking with F2
2. Place cursor outside of current segment's editable area
3. Press a key that would input text (i.e. not a navigation key or modifier key)
   → Should the input be ignored (cursor is not in editable area)? Or should the cursor snap back to the editing area and the input text be accepted?

[Kos Ivantsov]

I really like the way it's implemented in topic/aaron/cursor-lock. I like the way the user can type in the text and still select and copy in the whole Editor area.

--
Kos

[Masao Kasuya]

Thank you Aaron! This is a revolutionary feature.
One problem I face is that I can't type Japanese in Step 3.
I'm on Windows 7.

[Aaron Madlon-Kay]

Depending on the OS and the IME, Java doesn't even receive the key events until you confirm your input. Java's API for interacting with IMEs is pretty poor, so I'll take a look, but I don't think I can fix that.

[Masao Kasuya]

I think I can get along without having the capability to type Japanese in Step 3. I even don't mind if all inputs (excluding shortcuts) are ignored in Step 3.

On the other hand, I would like to have the following function of Yu Tang's groovy script preserved:
Highlighting a text in the non-editable area and then pressing F2 results in returning to "Cursor lock on" and inserting the text at the initial cursor position (or highlighted area) of the target segment. You can hit Esc if you don't want to insert the highlighted text.

[Didier Briel]

Highlighting a text in the non-editable area and then pressing F2 results in returning to "Cursor lock on" and inserting the text at the initial cursor position (or highlighted area) of the target segment.

I don't think that's something I would like. If I go outside of the source segment to select something, that doesn't mean I want to insert it in the target segment. If I want to do that, I press Ctrl+C on the selection and Ctrl+V after returning to the target segment with F2.

Didier

[Kos Ivantsov]

If I want to do that, I press Ctrl+C on the selection and Ctrl+V after returning to the target segment with F2.

The way it's implemented now in Aaron's prototype you don't necessarily have to press F2 again to be able to paste (or type), and I really like it.

--
Kos

[Didier Briel]

Agreed. What I meant is that I don't want F2 to do something other than bringing me back to the target segment in restricted edition.

Didier