Awkwardness positioning the cursor while editing

Report · Dec 22, 2022

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 element (in a <context> element)
 - Desired behaviour: move to beginning of text, INSIDE of the element
 - Actual behaviour: moves cursor to BEFORE the element.
- Example #2: cursor is on second line of text of a 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 element (in a <context> element), then the <up> cursor is pressed
 - Desired behaviour: move to beginning of text of first line, INSIDE of the element
 - Actual behaviour: moves cursor to BEFORE the element.
 - Example #6: cursor is at end of second last line of text of a element (in a <context> element), then the <down> cursor is pressed
 - Desired behaviour: move to end of text of last line, INSIDE of the element
 - Actual behaviour: moves cursor to AFTER the 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 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 element
 Actual behaviour: moves cursor to AFTER the 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 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 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 element
 Actual behaviour: selects the entire element >
 NOTE: this behaviour is inconsistent with Example #12
 Third press of <shift> + <home>
 Desired behaviour: select the entire 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

Report · Dec 22, 2022

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.

Report · Dec 22, 2022

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...?)

Report · Dec 22, 2022

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

Report · Dec 22, 2022

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.

Report · Dec 22, 2022

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

Report · Dec 28, 2022

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

Report · Dec 28, 2022

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