witheve / Eve

Better tools for thought
http://witheve.com
Apache License 2.0
7.15k stars 256 forks source link

Plain text view #514

Open ohAitch opened 7 years ago

ohAitch commented 7 years ago

Adding a single code fence to the line after "Eve Quick Start Tutorial" causes a JS error to be thrown (and the UI to be variously broken), which persists refreshes until localstorage is cleared. I appreciate the markup-hiding, but could there be a fallback mode that displays all the md decorators for editing, perhaps invoked by default in case of parse error?

pranaygp commented 7 years ago

I'm gonna take a stab at implementing this

joshuafcole commented 7 years ago

@pranaygp: This is going to be a sticky issue due to the method we use for rendering the state of the document. This is going to be documented in the code itself in the coming weeks, but the gist of it is that the language service sends us the text stripped of all markdown decorations, along with information on which ranges of text (called spans in the code) to markup and how. When we send the code back to the language service, the markdown is reconstructed from these spans. In essence, that means the editor never really works with the raw text, so it behaves more like a structured editor than a regular text editor.

The changes required to make this work extend from the language service, through the span-syncing logic (since the LS parser is currently effectively stateless), to fundamentally changing the way the editor interacts with the text (otherwise Cmd-B would try to markup a span instead of correctly decorating the range with asterisks).

Most of the time when issues like this come up, the problem isn't a truly malformed file (though that certainly does happen), but a user trying to use markdown-isms (e.g. typing # for headers or for a code block) directly in the editor. That's a much simpler case to handle I think, in which the editor catches those markdown-isms and does an appropriate structured transform of the document. For example, when a user types, the editor can markdown a new codeblock span, without doing the (frankly nonsensical) thing of trying to mark the rest of the document til the next codeblock as a new codeblock.

It seems worth discussing what the appropriate behavior is in the malformed document scenario, but if the latter approach meets your needs I think that's a much more achievable goal with a (typically) better UX.

pranaygp commented 7 years ago

@joshuafcole while looking at the codebase earlier, I had a hard time understanding what Spans were. This clears up a bunch of things. I think it's an interesting method of handling markdown transforms. I'll have to go over the span-syncing code from the LS, and find a way to implement a plain text view (if possible).

With reference to @ohAitch 's initial issue, I believe the problem still exists with other bugs/issues we should be able to grind out and fix. Ideally, nobody ever needs to see/work with a plain text version of the code. Do you have any thoughts on that?

cmontella commented 7 years ago

Ideally, nobody ever needs to see/work with a plain text version of the code. Do you have any thoughts on that?

Right, I think that's ideally, but there are a lot of bugs with the editing experience such that fixing the markdown directly is necessary. But I'm not sure what's harder -- implementing a plain text view or straight up fixing the editing experience.

tbodt commented 7 years ago

I've had some really bad experiences with rich WYSIWYG editors, such as TinyMCE. In my opinion, the best way to do rich text right is what StackEdit.io does. They have a Markdown editor, along with some script that parses the Markdown and applies context-sensitive styling to the Markdown. I'd like something similar to that for Eve.

ohAitch commented 7 years ago

Yeah, the answer to "what's harder -- implementing a plain text view or straight up fixing the editing experience" when accounting for all possible corner cases is definitely the former. I think I remember earlier eve screenshots, where the code fences were minimized but still very much directly editable, which looked far more likely to generally fail gracefully

On Thursday, 24 November 2016, Theodore Dubois notifications@github.com wrote:

I've had some really bad experiences with rich WYSIWYG editors, such as TinyMCE. In my opinion, the best way to do rich text right is what stackedit.io does. They have a Markdown editor, along with some script that parses the Markdown and applies context-sensitive styling to the Markdown. I'd like something similar to that for Eve.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/witheve/Eve/issues/514#issuecomment-262857307, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxXhlf4_-x-CrtBX4wNdG0w_jPJJKCiks5rBiRRgaJpZM4KpJEA .

hammerandtongs commented 7 years ago

With a plaintext view I could happily use wasavi for my editing of eve documents, it's broken as is because of the stripping of markdown text.

http://appsweets.net/wasavi/

mndrix commented 7 years ago

When I modify Eve code in the editor, it's automatically saved to disk. Maybe sync the other way too: modify Eve code on disk and it's updated in the editor. Then people wanting a plain text view can use their favorite editor on the .eve file directly.

alltom commented 7 years ago

That's what I do to side-step the various editor bugs: edit files in vim and reload the page to execute. I used the built-in editor to demo Eve to a user group the other day and it fatally crashed multiple times. (I think Github issues already exist for all the problems I bumped into.)