MacViews: Correct behavior of move and select commands when selection direction changes.

ui/strings/ui_strings.grd

 <?xml version="1.0" encoding="UTF-8"?>
 
 <!-- This file contains definitions of resources that will be translated for
 each locale. Specifically, these are UI strings that are used by app/ that
 need to be translated for each locale.-->
 
 <grit base_dir="." latest_public_release="0" current_release="1"
       source_lang_id="en" enc_check="möl">
   <outputs>
     <!-- TODO add each of your output files.  Modify the three below, and add
@@ skipping 424 matching lines @@
       </message>
       <message name="IDS_MOVE_WORD_RIGHT_AND_MODIFY_SELECTION" desc="A command to move the cursor right to the next word break and modify the selection.">
         Move Word Right And Modify Selection
       </message>
       <message name="IDS_MOVE_TO_BEGINNING_OF_LINE" desc="A command to move the cursor to the beginning of the line.">
         Move To Beginning Of Line
       </message>
       <message name="IDS_MOVE_TO_BEGINNING_OF_LINE_AND_MODIFY_SELECTION" desc="A command to move the cursor to the beginning of the line and modify the selection.">
         Move To Beginning Of Line And Modify Selection
       </message>
+      <message name="IDS_MOVE_TO_BEGINNING_OF_LINE_AND_EXTEND_SELECTION" desc="A command to move the cursor to the beginning of the line and extend the existing selection.">

[tapted, 2016/05/20 06:47:36]

I think this is the point where we really need to stop using IDS_* for these,
and switch over to an enum. It doesn't make sense to send these to translators,
since the string doesn't appear in the UI anywhere. I think these were once just
a "convenient" way to represent editing commands, since some of the actions
appeared in menu items as well (e.g. cut / copy / paste, etc.).

A lot of the others should be removed from this file :/

[karandeepb, 2016/05/24 07:47:15]

Have started working on a patch for this
https://codereview.chromium.org/2007503002/. But it may be some time before it's
ready. Since this and the transpose patch are ready, can they land first?

[tapted, 2016/05/25 04:31:06]

That approach isn't widely used for chrome development. There's not really any
rush, so we should ensure we're only adding stuff that we'll still need at the
endpoint. And, e.g., ui_strings.grd gets sent to translators - there's no reason
to have "Move To Beginning Of Line And Extend Selection" translated into dozens
of languages, so these really do not belong.

But if it's a big divergence, I don't want to send you down a path that OWNERS
disagree with. It's probably worth looping in, e.g., msw@ for an opinion about
what to do here. Maybe there's an underlying reason why these have historically
appeared in ui_strings.grd that I don't know about.

[karandeepb, 2016/05/25 05:04:11]

These commands were added here - https://codereview.chromium.org/211593006.
Can't really see any significant reason for it. Will hold this patch till the
refactoring is done.

+        Move To Beginning Of Line And Extend Selection
+      </message>
+      <message name="IDS_MOVE_TOWARDS_BEGINNING_OF_LINE_AND_MODIFY_SELECTION" desc="A command to move the cursor towards the beginning of the line and modify the selection. If the selection direction changes, the existing selection reduces to a caret.">

[karandeepb, 2016/05/20 04:41:47]

I can't think of a good name for this command. Suggestions?

[tapted, 2016/05/25 04:31:06]

IDS_MOVE_TO_BEGINNING_OF_LINE_OR_CURSOR_BOUNDARY_AND_MODIFY_SELECTION ?

But would the same logic apply to DOCUMENT and PARAGRAPH? We don't want a
combinatorial explosion of these.

Once we have an enum, or a better encapsulation of the edit command, it might
make sense to mask one of the bytes in the edit command with a selection
behaviour. Or to pass two arguments through the TextInputClient, or attach
selection behaviour on to the KeyEvent itself.

[karandeepb, 2016/05/25 05:04:11]

It wouldn't for the time being since Document and Paragraph commands are being
mapped to line commands. However, when we start supporting multi line
textfields, then of course, we'll have to add more commands (and instead of
using SelectionReversedBehavior enum, we can add #ifdef code as you suggested,
and as is done by Blink.)

+        Move Towards Beginning Of Line And Modify Selection
+      </message>
       <message name="IDS_MOVE_TO_END_OF_LINE" desc="A command to move the cursor to the end of the line.">
         Move To End Of Line
       </message>
       <message name="IDS_MOVE_TO_END_OF_LINE_AND_MODIFY_SELECTION" desc="A command to move the cursor to the end of the line and modify the selection.">
         Move To End Of Line And Modify Selection
       </message>
+      <message name="IDS_MOVE_TO_END_OF_LINE_AND_EXTEND_SELECTION" desc="A command to move the cursor to the end of the line and extend the existing selection.">
+        Move To End Of Line And Extend Selection
+      </message>
+      <message name="IDS_MOVE_TOWARDS_END_OF_LINE_AND_MODIFY_SELECTION" desc="A command to move the cursor towards the end of the line and modify the selection. If the selection direction changes, the existing selection reduces to a caret.">
+        Move Towards End Of Line And Modify Selection
+      </message>
       <message name="IDS_MOVE_UP" desc="A command to move the cursor up.">
         Move Up
       </message>
       <message name="IDS_APP_REDO" desc="A command to redo an action.">
         Redo
       </message>
 
       <!-- Generic terms -->
       <message name="IDS_APP_OK" desc="Used for Ok on buttons">
         OK
@@ skipping 231 matching lines @@
       </message>
       <message name="IDS_APP_LIST_SPEECH_HINT_TEXT" desc="The text label in the speech recognition UI to ask the user to speak the search query">
         Speak now
       </message>
       <message name="IDS_APP_LIST_SPEECH_NETWORK_ERROR_HINT_TEXT" desc="The text label in the speech recognition UI to show the speech recognition can't start because of network error.">
         No internet connection
       </message>
     </messages>
   </release>
 </grit>