You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
deleting the space before the word “find” in the second line, then adding a tab, then pressing down arrow puts the cursor in the wrong position. Moving the cursor back to the space between the vertical bar and the following blank in the third line, then deleting the space causes the first tab to shrink to a single space, ignoring the “Minimum space between elastic columns” setting.
The minimum space problem appears to happen only when monospaced font optimization is in effect.
Using v1.0.3; to be verified that this is not a regression from v1.0.2.
Edit: This happens in v1.0.2 as well. The minimum space problem appears to happen only when monospaced font optimization is active; the wrong position after the first tab is entered happens in both in the specific example given above, but it is unclear exactly what circumstances trigger it in v1.0.3 (which contains a fix for this that works in most, but not all, cases).
The text was updated successfully, but these errors were encountered:
The odd cursor positioning is not related to the minimum space problem, and is hopefully fixed in v1.0.3.1.
The minimum space problem occurs only when DirectWrite is enabled. There are other problems as well; for example, text following elastic tabs does not always align with untabbed text, even though a fixed width font is in use. The cause appears to be that character and text widths in DirectWrite can be fractions of a pixel, but Scintilla only returns widths and x-positions in whole pixels. A solution is yet to be determined.
Starting with this file, using a monospaced font with Elastic tabs profile General enabled:
deleting the space before the word “find” in the second line, then adding a tab, then pressing down arrow puts the cursor in the wrong position. Moving the cursor back to the space between the vertical bar and the following blank in the third line, then deleting the space causes the first tab to shrink to a single space, ignoring the “Minimum space between elastic columns” setting.
The minimum space problem appears to happen only when monospaced font optimization is in effect.
Using v1.0.3; to be verified that this is not a regression from v1.0.2.
Edit: This happens in v1.0.2 as well. The minimum space problem appears to happen only when monospaced font optimization is active; the wrong position after the first tab is entered happens in both in the specific example given above, but it is unclear exactly what circumstances trigger it in v1.0.3 (which contains a fix for this that works in most, but not all, cases).
The text was updated successfully, but these errors were encountered: