• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Awkwardness positioning the cursor while editing

Participant ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

I am using FM 2020, structured, DITA 1.3.

When I edit DITA files, I find that positioning the cursor for an insertion point and selecting text for copy/cutting to be awkward. In particular, the default behaviour of the <home> and <end> keys, mouse-clicks and cursor keys is often inconsistent and unintuitive (and therefore inefficient). For example:

  • There are some inconsistencies in whether or not the end result includes or excludes element tags.
  • There are some inconsistencies in the end result depending on whether you press a key on the keyboard vs. clicking on the text with a mouse.
  • The more common behaviour, which is to include element tags in the selection, makes editing inefficient

 

NOTE: while I can make some reasonable guesses as to the programmatical reasons for why FM behaves this way, I am raising these concerns/observations from a usability perspective.

 

NOTE: I have created https://tracker.adobe.com/#/view/FRMAKER-12635, Please vote if you also want this issue addressed

 

Positioning an Insertion Point.

The following examples are all inside a <taskbody> element

  • Using <Home> key on keyboard
    • Example #1: cursor is on first line of text of a <p> element (in a <context> element)
      • Desired behaviour: move to beginning of text, INSIDE of the <p> element
      • Actual behaviour: moves cursor to BEFORE the <p> element.
    • Example #2: cursor is on second line of text of a <p> element (in a <context> element)
      • Desired behaviour: move to beginning of line of text
      • Actual behaviour: works as desired.
    • Example #3: cursor is in middle of <title> element inside a <fig>
      • Desired behaviour: move to beginning of text, INSIDE of the <title> element
      • Actual behaviour: moves cursor to BEFORE the <fig> element.
    • Example #4: cursor is on first line of a text in a <cmd> element (inside a <step>)
      • Desired behaviour: move to beginning of text, INSIDE of the <cmd> element
      • Actual behaviour: works as desired
        • NOTE: this behaviour is inconsistent with Example #1
      • Using <End> key on keyboard
        • The desired and actual behaviours are the same as for the analogous four examples for the <Home> button.
      • Using cursor keys
        • Example #5: cursor is at start of second line of text of a <p> element (in a <context> element), then the <up> cursor is pressed
          • Desired behaviour: move to beginning of text of first line, INSIDE of the <p> element
          • Actual behaviour: moves cursor to BEFORE the <p> element.
        • Example #6: cursor is at end of second last line of text of a <p> element (in a <context> element), then the <down> cursor is pressed
          • Desired behaviour: move to end of text of last line, INSIDE of the <p> element
          • Actual behaviour: moves cursor to AFTER the <p> element.
        • Using the mouse (all mouse clicks are in the editor, NOT in the Structure View)
          • Example #7: click at beginning of first line of text in a paragraph (in a <context> element)
            • Desired behaviour: move to beginning of text, INSIDE of the <p> element
            • Actual behaviour: works as desired
              • NOTE: this behaviour is inconsistent with using the <Home> button
            • Example #8: click at beginning of second line of text in a paragraph (in a <context> element)
              • Desired behaviour: move to beginning of line of text
              • Actual behaviour: works as desired.
            • Example #9: click at beginning of text for a <title> element inside a <fig>)
              • Desired behaviour: move to beginning of text, INSIDE of the <title> element
              • Actual behaviour: works as desired.
                • NOTE: this behaviour is inconsistent with using the <Home> button
              • Example #10: click at end of last line of a paragraph (in a <context> element)
                • Desired behaviour: move to end of text, INSIDE of the <p> element
                • Actual behaviour: moves cursor to AFTER the <p> element.
                  • NOTE: this behaviour is inconsistent with clicking at the start of the first line of a paragraph
                  • NOTE: if one is very careful to click ON the second half of the last character, then the actual behaviour matches the desired. But that requires careful positioning of the mouse.
                • Example #11: click after the end of a line to text of a <cmd> element (inside a <step>)
                  • Desired behaviour: move to end of text, INSIDE of the <cmd> element
                  • Actual behaviour: works as desired
                    • NOTE: this behaviour is inconsistent with Example #10, because it does not matter where the click is (i.e. clicking on the last character or well after the last character have same result in this example)

 

 

Selecting text for copying/cutting.

When selecting text for copying/cutting, I often position my cursor at some point, then hold the <shift> key down, and either use <home|end> keys, cursors, or mouse-clicks. All of the above issues occur as well here, but with a couple of additional issues related to multiple presses of the <home> (or <end> keys).

  • Example #12: cursor is on second line of FIRST paragraph (in a <context> element)
    • First press of <shift> + <home>
      • Desired behaviour: select all text up to beginning of line of text
      • Actual behaviour: works as desired.
        • NOTE: this behaviour is consistent with Example #2 above
      • Second press of <shift> + <home>
        • Desired behaviour: select all text up to beginning of first line of text, INSIDE of the <p> element
        • Actual behaviour: selects everything in the entire <taskbody>
          • NOTE: this behaviour is not consistent with Example #1 above, which is what I was expecting…
        • Third press of <shift> + <home>
          • Desired behaviour: select the entire <p> element
          • Actual behaviour: selects everything in the entire <task> element
        • Example #13: cursor is on second line of SECOND paragraph (in a <context> element)
          • First press of <shift> + <home>
            • Same as Example #12
          • Second press of <shift> + <home>
            • Desired behaviour: select all text up to beginning of first line of text, INSIDE of the <p> element
            • Actual behaviour: selects the entire <p> element >
              • NOTE: this behaviour is inconsistent with Example #12
            • Third press of <shift> + <home>
              • Desired behaviour: select the entire <p> element
                • NOTE: this desired behaviour for the third press is the same what actually happens after the Second press
              • Actual behaviour: adds the entire previous element to the selection
                • NOTE: this behaviour is inconsistent with Example #12

 

 

TOPICS
Feature request , Structured

Views

205

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

Not being a structured dude myself, have you test-driven FM2022 to see if your concerns are happening in there? Because if they are, then FM2022+ would get any fixes, not FM2020.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

No I have not tested out FM2022 (and I agree that if there are still problems, then they should get fixed in 2022+). 

We are in the middle of finishing a project, and I am loathe to try out a new version of FM (unfortunately, most of the bugs that I have reported with FM2020 were not fixed in FM2022, so there has been little incentive to spend the time installing/configuring/setting up a new version).

 

If anyone else has FM2022 installed - do they experience the same issues or has it been fixed/addressed?

Also - is anyone else as frustrated by this behaviour as I am (or am I just the odd one out...?)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

Much of what you're seeing is the result of the visibility of the boundaries, and whether you are making selections in the structure view or the document view.

I find that working with the Element Boundaries on (without using the Element Boundaries as Tags option) helps with many functions, and I use the Structure View for selecting and navigating whenever I can.

 

-Matt

 

* And I agree with Jeff, that if you're waiting for an update to Fm 2020, you'll likely be disappointed.

-Matt Sullivan
FrameMaker Course Creator, Author, Trainer, Consultant

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

Matt - thanks for the pointer on Element Boundaries. I had not used that feature before, and while that addresses the mouse-clicking issues (which is helpful - Thanks!), it does not appear to address the keyboard selection issues I mentioned (i.e. cursors, home/end). It is still annoying/frustrating in terms of just trying to position my cursor at the start/end of text (or select just some text). Using Element Boundaries does let me see what is happening (again, that is quite useful and therefore "better" than before), but it is still awkward and in some cases not possible to do what I want.

 

Using the Structured view for positioning the cursor at the start/end of text does appear to work (which is the first half of what I was describing), but if trying to select a portion of text in an element (e.g. First sentence in a paragraph), it does not appear possible (unless there is something I am missing).

 

* I also agree with both you and Jeff that any updates should be in FM2022.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 22, 2022 Dec 22, 2022

Copy link to clipboard

Copied

Agreed, there are (by design) limitations on what you can do in the Structure View, but now that you have some guard rails, you should find you can move about more easily. There are also shortcuts for selecting things, but specifics might best be put into separate posts so they're easier to answer and easier to find by others.

Circle back in a week or two to let us know if you're feeling better about the nav options!

 

-Matt

-Matt Sullivan
FrameMaker Course Creator, Author, Trainer, Consultant

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Dec 28, 2022 Dec 28, 2022

Copy link to clipboard

Copied

Hi folks,

 

Couple of updates:

  • I installed FM2022, and as far as I can tell, it behaves identically to FM2020
  • What are people's thoughts/suggestion on selecting text, particularly if using just a keyboard? Are there any tricks that one uses? Typical patterns of keystrokes that work efficiently in other editors seem to fail with FM (i.e. in other editors, holding <shift> always maintains the “initial” cursor position, which allows you to continuously move the “end” cursor position after you have selected a region of text, allowing you to dynamically change the selected text, e.g. with  <left> and <right> cursor keys; I cannot do that with FM…)
    • Note: my original post was written mostly about cursor positioning, however, the issue that actually bothers me more is selecting text (e.g. first sentence of a paragraph). With Element Boundaries OFF, positioning the cursor and selecting text issues are very similar, so I did not emphasize one over the other. However, with Element Boundaries ON, cursor positioning is much simpler. So I am now re-emphasizing the "other" remaining problem

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 28, 2022 Dec 28, 2022

Copy link to clipboard

Copied

LATEST

Keyboard functions will vary, based on Structure versus Doc View, and whether your boundaries are visible.

I focus more on behavior of the insert, wrap, and change element functions, as I use those functions more often than straight selection options. Within nested structured content, I find it easiest to use the mouse to select things, and generally in the structure view.

-Matt Sullivan
FrameMaker Course Creator, Author, Trainer, Consultant

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines