You might also like Etherpad :) https://etherpad.org although Etherpad doesn't natively support tables and some other features this has they are optionally installed as plugins.
I wish we had a WYSIWYG focused on extremely explicit whitelist of nodes and attributes permitted, and in what configuration (you can put X in Y, but not Y in X).
CKEditor allows that level of customization. I think TinyMCE may as well. You also can massage your data as it comes in and out of the editor. I have a React wrapper for our editor that walks an HTML tree, and if nodes match criteria I've coded, I act on them in various ways before loading it all into the editor.
The point being that there is no lack of options for building out such features. I'm not sure you'll ever get an editor to do it out-of-the-box, though, because everyone's needs are going to be different.
I almost wish it was Electron based. A bunch of things made the usage almost impossible.
- MacOS has handy text navigation shortcuts: alt-arrow to go back a word, alt+shift+arrow to select a word, etc. These don't work, and I'm too used to them to stop using.
- I'm using Colemak keyboard layout (L key inserts letter "i"), but keyboard shortcuts don't respect it. So in my mind I have to press Cmd + U ("u" is mapped to I key) to make text Italic. Again, this broke my usual habbits.
- Common MacOS shortcuts (even Cmd + Q to quit) don't work.
I like the ideas behind this editor, but now I hope someone ports it to HTML + JavaScript, so it works keeping all the OS-provided affordances.
It is just that at some point someone asked me to make distribution so I've created that web site.
Another question was to understand: donation-ware, is it a sustainable solution. Apparently it is not - donation does not even cover sums asked by Apple for allowance to develop software for their platform.
This feels a bit like the old reddit post about how now one would ever use Dropbox because you can just roll your own FTP server. Good points though on OS tracked features.
Tangential, but for the pain of alternate keyboard layouts, I've found it easiest to use a keyboard that allows remapping of keys in hardware to alternate layouts (sends the 'wrong' keycode when you press a key). It's a bit of a hack, but it works much better than equivalent software hacks.
System having "both views" -- software view (where "i" might be on key L) and hardware view (of physical key placements) -- is very useful. For example, when using Colemak on Windows, I can play using WASD physical keys, but many games correctly name them WARS.
Can you give me some info on "new Sciter - the one that uses JavaScript"
Last time I played with Sciter it was based on a proprietary JS engine that wasn't fully exchangeable with common JS. Is that not the case any more, and Sciter will now understand ECMA standard JS?
QuickJS complies to ES2020 specification. And Sciter exposes most popular and modern DOM API so MithrilJS, PReactJS and other libraries work as they are.
Sciter implements far not whole set of DOM API - just essential ones. In fact DOM API and so browsers are full of garbage - old historical layers of stuff from initial Netscape JS API, IE6, etc. For example there is no XMLHttpRequest but there is Fetch API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Sciter goal is not to support browser API as it is - with all its bells and whistles, after all desktop use cases require features that are not available in browsers anyway.
But all non-UI libraries from NPM collection should work as they are in Sciter. Most of pure Vanilla JS UI components should also work as they are, for example LeafletJS (maps) https://sciter.com/sciter-js-runs-leafletjs-as-it-is/
This was my first question. I am an avid user of older technology, and I regularly do lots of writing for the web in HTML format. I cannot use any of the new Electron-based programs on my laptop due to their exorbitant resource usage. This program in its current form is perfect. However I would not continue to use it if it were upgraded to a modern JS based framework.
I have a question; if I get Sciter can I use (I mean does it expose) your lower-level cross-platform abstraction instead of the DOM and CSS? I don't want to make documents, nor do I think HTML's layout(s) nor CSS are appropriate for applications. But I would very much like a cross-platform scene graph like that exposed by Flash back in the day, which I could build atop the same sort of foundation one would want underneath their CSS/DOM impl.
DOM is tree of lightweight nodes and elements. In Sciter each DOM element may have native controllers, known as behaviors. Examples of those: https://github.com/c-smile/sciter-js-sdk/tree/main/include/b... . So you can create single DOM node - document and attach your native behavior to it. It will receive all events and will do drawing if you want.
Some applications are using mixed model: DOM where it makes sense, and custom native behavior where high performant handling is required.
In fact DOM and ImGraphics have their strong points but in different situations. Sciter allows to have best of two worlds by combining them.
In any case when you say "I don't need DOM", it means that you will implement it on your side. Been there, seen that many times.
It's not that I don't want any DOM, it's that I specifically don't want "the" DOM as seen in web browsers. What I want is a scene graph without layout or CSS, but with events and transform nodes and the like. You can get close to this in web DOM just by making everything absolute and just not using CSS, but without a way to measure text before drawing it, you can't do your own layout properly.
It looks like Sciter might be what I need to build on top of though, I will look into it further.
Honestly it seems like this would be one of the few justifications for using electron. You're literally rendering HTML, getting that as accurate as possible is a plus.
This is the first thing I checked, and was so relieved to see that it wasn't one-more ElectronJS app wasting the resources of my PC for to simplify the life of the programmer
What's exactly the use case, here? When would I want to use this and not a markdown editor, or word/gdocs/lowriter/…'s HTML export? Or something like TinyMCE?
Static site generators, maybe? Assuming it can be taught to handle their non-HTML metadata…?
The notepad allows you to edit the document in markdown form.
That editor is essentially for "Internet Content Writers" - people who create textual content. It is definitely not for creating websites - "HTML-NOTEPAD is not a “web page editor”. Don’t even expect to create “cool web pages” with it" from the front page.
I by myself use it with WordPress and GitHub - write content and then by using either html source or markdown source publish it on those platforms.
> I by myself use it with WordPress and GitHub - write content and then by using either html source or markdown source publish it on those platforms.
I'm not too familiar with Github pages, but in Wordpress's case it sounds incredibly wasteful as you lose all the benefits of Wordpress's modular editor. Why even bother with Wordpress at that point and not use a more lightweight CMS?
I am not using modular editor in WordPress - found it too limited and not keyboard friendly. But that's just my own experience - for someone it could be OK.
One use case would be to integrate it blog sites for adding blog content (with markdown). But I don't know whether it supports this integration or not.
Technically possible but practically having source of the document available (html or markdown) is enough for most cases for copy-pasting to destination. Otherwise passwords to web sites / blogs need to be stored outside of browser, all that...
Looks really cool. I tried to add some CSS (inline/local/from CDN) but it didn't work. If it worked I would use it instead Notion to make some nice looking notes. Some feedback - would be nice to have shortcut to source. Portable version have unnecessary folders (sciter\sciter\sdk\bin\32\files). When I have one note (tilted 'new') opened the title is written vertically as:
N
E
W
If I change title or create another note then it's written horizontally.
The CSS still works in the browser so it isn't cleared just ignored. This is enough for me, I could use something like Parcel or Vite to observe folder with notes to reload changes in browser. This way (HTML Notepad + live reload) I can combine WYSWYIG + inline CSS to create good looking single page notes and replace Notion in some cases (it's slow and I don't own files as they are in cloud).
1. the markdown source button does nothing. I have no idea what it's supposed to do, but I didn't see any effect whatsoever.
2. If you type * or h1 etc. then space, it will automatically convert to list/heading etc. However, this doesn't work in the first line.
3. In the `pre` block, when you press enter the cursor doesn't move to the next line. But if you type something then, you will find it will start on the next line. Probably some CRLF shenanigans going on but it's definitely not what the user would expect for a WYSIWYG editor.
+1 It looks like the result of a collaboration between a good designer and a good programmer. The app is intuitive and the homepage is well designed too.
I did it by myself. It is not that I am good designer even that I have artistic education (oil painting) but my primary is MS in Applied Physics/Maths (the combination specific for GUI/UX developers I think).
It feels a lot like the built-in WordPad that comes with Windows, or TextEdit that comes with Macs, in that they both support similar basic formatting but are also both historically built on RTF rather than HTML.
I'll admit I don't really understand the intended audience for this, however. Since it's not for webpages, it seems to be aiming at more basic text editing.
But hasn't Markdown pretty much become the de facto standard for that? For text documents, why would you ever want to write and edit in HTML directly, rather than easier-to-use Markdown that can be converted to HTML on the fly? (Especially with WYSIWYG Markdown editors existing.)
It does support editing as in WYSIWIG as in Markdown form.
Actually markdown is also form of WYSIWYG. But WYSIWYG on steroids I would say. Markdown format was explicitly designed to emulate WYSIWYG but in plaintext.
One could call documentation a very specific domain for writing and perhaps Markdown is not ideal for that?
Personally I use it to write letters, notes, blog articles, and such. When I need to write something more complex I might or might not use markdown while embedding some other language. Eg. my thesis is written in Markdown but uses Latex.
Depending on the context you can indeed use the concrete code you wrote as Markdown. You could insist on embedding the the <section> pieces into a Markdown document and use a markdown to HTML preprocessor.
But you are the judge on whether this is a good idea.
HTML supports wide range of applications. Even basic HTML provided more semantic value.
You can use it as for articles as for structured documentation. As it supports hierarchical structure + classes.
And pure markdown is not structural and not extendable by design - essentially just a flat list of paragraphs.
Yes, you may have some containers there like <blockquote> and <ol> but that's pretty much it. Why there are no sections or any other form of grouping content?
Markdown has exactly the same problem as MS Word / Richtext - they are very good in WYSIWYG but are terrible in semantic.
Markdown.Next shall be in the golden middle between HTML and current MD - with modularity built-in by design.
This is a very pretty application, and very fast. It reminds me of older text editors.
However right now it's very buggy. I used it for 5min and encountered bug after bug. Even ⌘Q types in "q" and beeps instead of quitting the app.
Also, I suggest you use markdown shortcuts (e.g. typing # will create a header, *text* will make your text italic, etc.) I'm used to them in most text editors and they make editing super easy and fast. Of course keep the content WYSIWYG, just markdown shortcuts, and you can add an option to turn them off in case someone doesn't like them.
Overall though I hope you keep working on this and iron out the bugs, because otherwise it's a great app.
I understand that this project is to showcase Sciter SDK (https://sciter.com) a nice project.
Here I'm showing something I did some time ago https://meimporta.eu/htmleditor/ it's a crude WYSIWYG html editor for people that already knows HTML/CSS and uses basically the browser contenteditable capabilities. It was inpired by Webflow (https://webflow.com/) but very simple and basic, it has 4 main sections: editor shortcuts, wysiwyg editor, html editor, tree view. Some things are easy done in the wysiwyg editor but sometimes the raw html editor is better, we can edit in both of then and get instant result.
Don't bother comment on the UI/UX it's an personal naive tool straight to the point I needed. Anyway any feedback to improve is welcome.
Yes you should pull it from the link, it's almost self contained and you'll need to edit the source to point to you html source or copy and paste it on the editor.
Reading arbitrary css and html into something editable sounds like hell. On the other hand, translating an arbitrary layout to html doesn't sound particularly hard.
This is an interesting app, but the English on the landing page needs some editing by a native speaker/writer. It doesn't look like English is the first language of whoever wrote that text.
I've had a lot of fun in the Sciter SDK. It's one of the few desktop UIs with hooks for golang that just works. I remember the learning curve to be up there though.
The fact that you can edit the elements and they persist is really cool. I wrote a markdown editor for my website that renders HTML and Vue components at request time, but you have no control over component properties. Impressive stuff.
This program has a very responsive, minimal feel that I am really enjoying. One minor problem that I've found is that (on Linux) you cannot copy text out of HTML notepad's default view.
There is no standard way of representing HTML in clipboard on Linux/GTK. Unfortunately.
Even plain text has multiple, conflicting formats.
Sciter definitely puts text in GTK clipboard. And it works as far as I can tell, proof: https://sciter.com/linuxnotepad/ on my Linux Mint. So your problem needs some details.
HTML/CSS renderer: takes HTML+CSS as input and produces rendering.
WYSIWYG editor: takes rendering (what you see) and tries to produce HTML+CSS (what you get).
With pure HTML (v 3.2, before styles) WYSIWYG was possible as, for example, to change color of the text you had only one option: <FONT color="red">. With CSS you can apply color the span in many ways: you can use any element for span and apply CSS in various ways.
Rendering, the direct task, is N(rules) -> 1(rendering).
And editing, the opposite task, is 1 -> N. Mathematically speaking this task is unsolvable - has no determined solution.
Every graphic on the intro screen says "ctrl+whatever" instead of "cmd+whatever".
The standard text editing shortcuts don't work. You can't hold option to jump word by word, you can't use ctrl+e or ctrl+a to jump to the end or start of a line, etc.
This alone makes me not want to use it. Every other program I've run supports these things.
87 comments
[ 2.8 ms ] story [ 152 ms ] threadAlso HTML that is pasted from external sources (browsers, MS Office, etc.) gets "cannibalized" on pasting:
https://github.com/c-smile/sciter-sdk/blob/master/notepad/re...
with white listed tags and attributes.
The point being that there is no lack of options for building out such features. I'm not sure you'll ever get an editor to do it out-of-the-box, though, because everyone's needs are going to be different.
For example in Sciter I've added transactional DOM mutations feature
Such mutation is performed as single UNDOable operation.Also Sciter supports immediate mode painting a la ImGUI that helps a lot to make lightweight editing solutions.
The lack of needed API forced Google Docs to switch to Canvas based rendering and editing : https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
html-notepad is Sciter based application so its distribution is only 5 MB.
It's sources are here https://github.com/c-smile/sciter-sdk/tree/master/notepad . This still uses old Sciter.TIS and I am porting it to new Sciter - the one that uses JavaScript.
I am an author of the editor (and Sciter).
- MacOS has handy text navigation shortcuts: alt-arrow to go back a word, alt+shift+arrow to select a word, etc. These don't work, and I'm too used to them to stop using.
- I'm using Colemak keyboard layout (L key inserts letter "i"), but keyboard shortcuts don't respect it. So in my mind I have to press Cmd + U ("u" is mapped to I key) to make text Italic. Again, this broke my usual habbits.
- Common MacOS shortcuts (even Cmd + Q to quit) don't work.
I like the ideas behind this editor, but now I hope someone ports it to HTML + JavaScript, so it works keeping all the OS-provided affordances.
In fact I've created the notepad as a demo project for Sciter SDK (https://sciter.com). The same as Sciter Notes: https://notes.sciter.com
It is just that at some point someone asked me to make distribution so I've created that web site.
Another question was to understand: donation-ware, is it a sustainable solution. Apparently it is not - donation does not even cover sums asked by Apple for allowance to develop software for their platform.
Will sadly make it unusable for me. Thanks for saving me the time.
I don't mind if it will be commercial product or not - I'll help anyway.
As I said - it can be ported to new Sciter (it uses JS now) as it is - relatively easy.
Just drop me a message at https://sciter.com/contact_us/
https://news.ycombinator.com/item?id=8863
Sciter was born from my old WYSIWYG editor that I did for EverNote. Here is the story: https://sciter.com/10-years-road-to-sciter/ and here with photo: https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-...
Sciter was born at times when term Smart Client was the thing.
So it is "Smart Client, next ITERation". So it is pronounced that way: skiter.
Last time I played with Sciter it was based on a proprietary JS engine that wasn't fully exchangeable with common JS. Is that not the case any more, and Sciter will now understand ECMA standard JS?
Mainstream Sciter now uses QuickJS of Fabrice the Magnificent (https://bellard.org/quickjs/).
QuickJS complies to ES2020 specification. And Sciter exposes most popular and modern DOM API so MithrilJS, PReactJS and other libraries work as they are.
Sciter implements far not whole set of DOM API - just essential ones. In fact DOM API and so browsers are full of garbage - old historical layers of stuff from initial Netscape JS API, IE6, etc. For example there is no XMLHttpRequest but there is Fetch API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Sciter goal is not to support browser API as it is - with all its bells and whistles, after all desktop use cases require features that are not available in browsers anyway.
But all non-UI libraries from NPM collection should work as they are in Sciter. Most of pure Vanilla JS UI components should also work as they are, for example LeafletJS (maps) https://sciter.com/sciter-js-runs-leafletjs-as-it-is/
Also Sciter provides rich set of built-in components like JSX, Reactor, Virtual List (https://sciter.com/behaviorvirtual-list-for-sciter-and-scite...) and others.
But anyway Sciter provides an option for host application to link SQLite statically and expose it to JS: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/usc... as set of native objects.
usciter from SDK is an example of application that has SQLite on board.
For example Sciter exposes Graphics API https://github.com/c-smile/sciter-js-sdk/blob/main/include/s..., is this close to what you mean? It allows to render stuff a la ImGUI - immediate mode painting.
And what's in principle wrong with DOM?
DOM is tree of lightweight nodes and elements. In Sciter each DOM element may have native controllers, known as behaviors. Examples of those: https://github.com/c-smile/sciter-js-sdk/tree/main/include/b... . So you can create single DOM node - document and attach your native behavior to it. It will receive all events and will do drawing if you want.
Some applications are using mixed model: DOM where it makes sense, and custom native behavior where high performant handling is required.
In fact DOM and ImGraphics have their strong points but in different situations. Sciter allows to have best of two worlds by combining them.
In any case when you say "I don't need DOM", it means that you will implement it on your side. Been there, seen that many times.
It's not that I don't want any DOM, it's that I specifically don't want "the" DOM as seen in web browsers. What I want is a scene graph without layout or CSS, but with events and transform nodes and the like. You can get close to this in web DOM just by making everything absolute and just not using CSS, but without a way to measure text before drawing it, you can't do your own layout properly.
It looks like Sciter might be what I need to build on top of though, I will look into it further.
Static site generators, maybe? Assuming it can be taught to handle their non-HTML metadata…?
That editor is essentially for "Internet Content Writers" - people who create textual content. It is definitely not for creating websites - "HTML-NOTEPAD is not a “web page editor”. Don’t even expect to create “cool web pages” with it" from the front page.
I by myself use it with WordPress and GitHub - write content and then by using either html source or markdown source publish it on those platforms.
I'm not too familiar with Github pages, but in Wordpress's case it sounds incredibly wasteful as you lose all the benefits of Wordpress's modular editor. Why even bother with Wordpress at that point and not use a more lightweight CMS?
N
E
W
If I change title or create another note then it's written horizontally.
Treat it as pure markdown editor that edits content in WYSIWYG form.
1. the markdown source button does nothing. I have no idea what it's supposed to do, but I didn't see any effect whatsoever.
2. If you type * or h1 etc. then space, it will automatically convert to list/heading etc. However, this doesn't work in the first line.
3. In the `pre` block, when you press enter the cursor doesn't move to the next line. But if you type something then, you will find it will start on the next line. Probably some CRLF shenanigans going on but it's definitely not what the user would expect for a WYSIWYG editor.
You just need notepad.exe + sciter.dll in the same folder.
I did it by myself. It is not that I am good designer even that I have artistic education (oil painting) but my primary is MS in Applied Physics/Maths (the combination specific for GUI/UX developers I think).
It feels a lot like the built-in WordPad that comes with Windows, or TextEdit that comes with Macs, in that they both support similar basic formatting but are also both historically built on RTF rather than HTML.
I'll admit I don't really understand the intended audience for this, however. Since it's not for webpages, it seems to be aiming at more basic text editing.
But hasn't Markdown pretty much become the de facto standard for that? For text documents, why would you ever want to write and edit in HTML directly, rather than easier-to-use Markdown that can be converted to HTML on the fly? (Especially with WYSIWYG Markdown editors existing.)
Just curious what I'm missing here.
Latest version: https://github.com/c-smile/sciter-sdk/tree/master/bin.win/x3... , two files from there: notepad.exe and sciter.dll
It does support editing as in WYSIWIG as in Markdown form.
Actually markdown is also form of WYSIWYG. But WYSIWYG on steroids I would say. Markdown format was explicitly designed to emulate WYSIWYG but in plaintext.
For most article writing, the markdown workflow is inferior to using even a basic word processor.
Often, when I write, I want to see the structure of the document visually.
Markdown doesn't allow that.
Also, I'm always writing for the web.
I don't need the extra markdown to HTML step. What does that buy me?
I think this aspect of HTML Wysiwyg is somewhat overlooked.
Is this the next Hemingway app? Probably not.
But for many of us, who write a lot of content intended for the web, this is a great tool to add to the toolbox.
I wanted to write documentation in Markdown, it should be perfectly suitable for that, right?
But this construct for example:
has no Markdown representation at all.in html5 you would ommit the unnecessary closing tags for p, dt and dd.
One could call documentation a very specific domain for writing and perhaps Markdown is not ideal for that?
Personally I use it to write letters, notes, blog articles, and such. When I need to write something more complex I might or might not use markdown while embedding some other language. Eg. my thesis is written in Markdown but uses Latex.
Depending on the context you can indeed use the concrete code you wrote as Markdown. You could insist on embedding the the <section> pieces into a Markdown document and use a markdown to HTML preprocessor.
But you are the judge on whether this is a good idea.
HTML supports wide range of applications. Even basic HTML provided more semantic value. You can use it as for articles as for structured documentation. As it supports hierarchical structure + classes.
And pure markdown is not structural and not extendable by design - essentially just a flat list of paragraphs. Yes, you may have some containers there like <blockquote> and <ol> but that's pretty much it. Why there are no sections or any other form of grouping content?
Markdown has exactly the same problem as MS Word / Richtext - they are very good in WYSIWYG but are terrible in semantic.
Markdown.Next shall be in the golden middle between HTML and current MD - with modularity built-in by design.
Sounds like restructuredtext ("That weird markup language used by Sphinx") from around 2000.
Well, Markdown accepts body HTML verbatim. Sure, this makes it non-homogeneous, but nevertheless possible, when needed.
https://docs.oracle.com/javafx/2/ui_controls/img/editor-get-...
it shows <font class="Apple-span-style">, this means the text was pasted from a WebKit browser (or that editor is WebKit itself).
Ideally such (as MS Office one) garbage shall be removed while pasting.
However right now it's very buggy. I used it for 5min and encountered bug after bug. Even ⌘Q types in "q" and beeps instead of quitting the app.
Also, I suggest you use markdown shortcuts (e.g. typing # will create a header, *text* will make your text italic, etc.) I'm used to them in most text editors and they make editing super easy and fast. Of course keep the content WYSIWYG, just markdown shortcuts, and you can add an option to turn them off in case someone doesn't like them.
Overall though I hope you keep working on this and iron out the bugs, because otherwise it's a great app.
CTRL + NUMPAD 1...6 will convert paragraph to a header. CTRL + I - will apply <em> to the selection.
These are common shortcuts for all specialized markdown editors. And I believe shortcuts are better - more reliable and explicit.
Here I'm showing something I did some time ago https://meimporta.eu/htmleditor/ it's a crude WYSIWYG html editor for people that already knows HTML/CSS and uses basically the browser contenteditable capabilities. It was inpired by Webflow (https://webflow.com/) but very simple and basic, it has 4 main sections: editor shortcuts, wysiwyg editor, html editor, tree view. Some things are easy done in the wysiwyg editor but sometimes the raw html editor is better, we can edit in both of then and get instant result.
Don't bother comment on the UI/UX it's an personal naive tool straight to the point I needed. Anyway any feedback to improve is welcome.
Is it open source? I'd like to get it working with my own stylesheets and such.
> With modern CSS, WYSIWYG Web design is simply impossible. Web pages are crafted manually by editing CSS, that is by nature of CSS.
mmm.page[1] would like a word with you!
[1] https://news.ycombinator.com/item?id=27128424
[1] https://motherfuckingwebsite.com/
The fact that you can edit the elements and they persist is really cool. I wrote a markdown editor for my website that renders HTML and Vue components at request time, but you have no control over component properties. Impressive stuff.
Sciter definitely puts text in GTK clipboard. And it works as far as I can tell, proof: https://sciter.com/linuxnotepad/ on my Linux Mint. So your problem needs some details.
And try recent version from GitGub: https://github.com/c-smile/sciter-sdk/tree/master/bin.lnx/x6...
You will need 2 files from there: html-notepad and libsciter-gtk.so
HTML/CSS renderer: takes HTML+CSS as input and produces rendering. WYSIWYG editor: takes rendering (what you see) and tries to produce HTML+CSS (what you get).
With pure HTML (v 3.2, before styles) WYSIWYG was possible as, for example, to change color of the text you had only one option: <FONT color="red">. With CSS you can apply color the span in many ways: you can use any element for span and apply CSS in various ways.
Rendering, the direct task, is N(rules) -> 1(rendering). And editing, the opposite task, is 1 -> N. Mathematically speaking this task is unsolvable - has no determined solution.
Every graphic on the intro screen says "ctrl+whatever" instead of "cmd+whatever".
The standard text editing shortcuts don't work. You can't hold option to jump word by word, you can't use ctrl+e or ctrl+a to jump to the end or start of a line, etc.
This alone makes me not want to use it. Every other program I've run supports these things.