Editor insensitivity to clicks in margins

Problem: The Editor is insensitive to clicks in the margins, so attempts to place the insertion point at the beginning or end of an editor line of text require care not to click in the margin regions.

Steps to reproduce:

  1. Display some text in the Editor.

  2. In Preferences/Editor, set the Left/Right margins to nonzero values > 2 points. Example: 24 points. Close the Preferences window.

  3. Position the cursor somewhere in the Editor’s window in the editor pane and inside the displayed text; and click the mouse button.

Result: The insertion point is placed where you clicked in the text; if there is only a carriage return, however, the insertion point is set at the beginning of that line. All of this is standard, as one would expect.

  1. Now position the cursor anywhere in the left or right margin. The cursor should still have the I beam appearance, which would indicate that it should be possible to set the insertion point with a click (mousedown) event. But avoid having the cursor within 2 pixels or so of the text column.

  2. Click the cursor.

Result: The insertion point does not move. It remains where it was positioned at step 3.

Expected Result: The insertion point would be expected to move to the beginning of the line nearest to the mouse click if the click position was in the left margin; if clicked in the right margin, the insertion point should move to the end of the nearest line.

  1. Now click in a margin within 2 pixels or so of the text.

Result: As expected above, the insertion point moves to the beginning or end of the closest line.

Comments: The Editor window is composed of three vertical panels: the left margin, the text, and the right margin. It is evident that mousedown events are not sensed if clicks occur in the left margin or the right margin. If the Preferences/Editor Left/Right Margin setting is small, e.g. 2 points, the behavior upon clicking in the thin margin region is more or less as expected given that the user will be manually targeting the beginning or end of the line more accurately.

Workaround: The user has to click close to the beginning or end of the line, avoiding the dead margins, if the mousedown event is to be detected as expected.

Discussion: The reason this is a problem is that most other editors with displayed text margins, e.g. Microsoft Word, will register margin clicks by putting the insertion point as expected above at the beginning or end of the text line. I have been trained through years of practice to (sloppily) place the cursor well to the left or right of the text column when I want to place the insertion point at the beginning or end of a line.

Depending on the user’s opinion, this is either a bug or a feature. The left margin in particular is useful to allow distinction between the edge of the binder pane from the Editor text pane. I currently set the Editor Left/Right margin to about 5 points, and usually this problem doesn’t come up while I am editing, but I think this is a problem that might be addressable depending on how the text editor API is being handled.

Thanks for considering these comments.

By the way, I do not know whether this is a new or old behavior. I used Scrivener extensively around V1.5 and V2.0, but only recently with V2.7 have I begun using Scrivener again (and I think it seems markedly improved since V2.0).

Pardon the cliche, but I think this is a feature, not a bug.

Preferences > Editor > Wrap to Editor Mode > Default editor width: Enter 0 to force the windows to fit the screen.
Set L/R margin >2.
Use the Ruler to set whatever functional editor margins you want.
You’ll have live area from L/R margin to Ruler margins.

Or, you could work in Page View.


The reason I think this margin insensitivity is a UI problem that should be addressed, if possible, is because of the cursor pointer behavior.

As I noted in the original post, the I beam pointer suggests to the user that mousedown events will be detected and the insertion point placed. In the margin, however, the mousedown events are not registered.

As far as I know that is just how the text editor component works. Clicking outside of the text block area (into visual margins) isn’t registered as an editor action. You can test this with TextEdit set to “Wrap to Page” mode.

But in wrap to window mode, and for rtfd documents, the small margin between the text column and the window edge in TextEdit does register mousedown events. In TextEdit’s wrap to page mode, there is a textbox with displayed margin limits. The UI is at least transparent to the user, and there is no misunderstanding.

It is not so clear in Scrivener that there is a dead region, again, because of the behavior of the cursor pointer, which indicates that mousedown events will be registered, and the lack of a visible text box margin.

In any case, it would be nice if there was not a dead region. MS Word is a good example of making use clicks in the left margin. Maybe it is not practically doable, given the reliance on the built-in text system, but I am thinking this one counts as desirable if doable.

One can certainly programmatically detect the margin clicks and presumably its coordinates in the interface. It is really a matter of how tricky/reliably one can calculate the desired behavior from there. Might be a ticklish matter.


For reference here is a prior request for this with comments from the developer.