Fundamental Line Editor Discipline

[mtanne 9]

Several ongoing editing bugs stem from one more fundamental problem I believe. Each has been discussed separately, but never fully resolved, so I'm making one post to draw attention to the bigger problem. Here are a few examples I've experienced for years:

• The "Quantum cursor" - cursor location after a paste is randomly above or below the inserted content
• Bullet list start/stop - item in a bullet list may include 0, 1 or 2 LF, sometimes you can end a list with 2 CR, sometimes it just keeps making more bullets
• Paste w/o formatting, sometimes you get the formatting of the line above, sometimes below
• removing formatting - sometimes it's impossible to remove formatting of a section of text, it's like tar stuck to your cursor, and every line it touches gets infected by it

I've come to accept Evernote's core line editor is just 'quirky'.  Apparently, so have others, since no one's screaming about it, and as basic as it is, release after release it just NEVER gets fixed.

My Theory: The core line editor functionality isn't based on a solid, adequately formalized and characterized design. It was probably hacked as one of the first bits of code at the very beginning and it is long overdue refactoring.  Normal issue when developing a complex codebase.

e.g. Paste. Insert XYZ into the sequence of characters ABC\rDEF<cursor>GHI\n at the cursor.
do you get ABC\rDEFXYZ<cursor>GHI\n or ABC\rDEF<cursor>XYZGHI\n.

This is a problem addressed since the very earliest line editors from IBM ed, Edlin, Wordstar, WordPerfect, vi, Emacs, and implemented in the editor used by this very forum.  The other issues listed, and several more not listed, suffer from the same lack of formal definition.

Perhaps, when moving the cursor, we are inadvertently placing it before or after hidden format markers, and sometimes invalid or inadequately terminated formatting, leaving dangling bits:

<b>this text is bold \r is this text still bold?

If this is an accurate conclusion what the editor needs is a fomal definition:

• for all editing function: character entry, cut, copy, paste, delete, (including the more complex ones: image paste, table paste, Web clipping, etc.)
• cursor location, rules for CR and LF, formatting start/stop, 
• does the end of the line include or not include the CF (e.g. in MSWord moving cursor to left margin guarantees you're selecting the entire line including LF or CR)
• Proper Bracket Matching on formatting markers.  e.g. HTML editor or Web browser parses nested formatting: <li><b>text</b></li>.

A helpful workaround would be "View Formatting" that exposed the underlying formatting structure so we could delete extraneous LF, CR, or unterminated formatting.

 

[upnix 36]

17 hours ago, mtanne said:

My Theory: The core line editor functionality isn't based on a solid, adequately formalized and characterized design. It was probably hacked as one of the first bits of code at the very beginning and it is long overdue refactoring. 

I'm sorry to say that the text editing functionality is quite new (around a year old). They implemented a new cross-platform editor for a common code base. It's written in Javascript, I'm fairly sure.

Pull up Activity monitor, sort by CPU use, and then beside it start typing at a normal pace in and Evernote note. You'll be baffled at how/why a computer function as old as computers themselves (text editing) needs to use ~40% of a modern CPU (on my system).

My theory: Evernote developers spend their days madly trying to build and fix a house built on sand, while management demands new additions be built yesterday. With 100 different problems, a Javascript editor to unify some of their code base seems like a great idea, but now they have 101 problems.