Ask HN: What do you want in a text editor?

[fizzbucket]

I'm making a simple open-source text editor (Qt5 wrapper around pandoc, markdown) intended more for journalists, academics and students than web developers -- so it has things like reference support and easy adaption of different citation styles baked in, accurate wordcounts, a distraction free mode, etc. Themes and previewing, as well as pdf creation without tex are already included, and pandoc means almost any output format is trivially easy to implement.

But what features would you like to see added to this list? Draft has its Hemingway mode, for example. What's missing from text editors you think you'd really like?

[orbifold]

I don't want to discourage you, but Emacs will beat you in pretty much any respect. It has org mode, which can generate html, latex, markdown etc. from a very intelligent and easy to use outline mode plus a ton of other features (literal programming, calendar, tables). It pretty much blows any other personal information management system out of the water. You could view the google talk by its creator for more information.

Auctex mode for latex editing, with in buffer preview of formulas and you are a few keystrokes away from compiling and previewing in an external viewer aswell. It also has distraction free mode, as you can fullscreen it and remove all chrome you don't want.

I think you would need to work really long and hard to get something substantially better than emacs as a tool. That being said there still will be people who pay money for inferior products if it has enough flashy features.

[dahart]

Emacs is awesome, and I totally love it. I've used it for more than 20 years. But, it's too complicated even for most programmers, and it's way too complicated for the majority of non-programmers. I can't handle maintaining my .emacs file anymore, and for me sublime is easier to use, even if it is less "powerful".

As much as I still love emacs, it's not a reason to be discouraged. I might even suggest it's a reason to be encouraged. I would absolutely love to see something that actually competes with emacs on functionality and generality, while also being modern and usable, and without having to be a programmer.

[fizzbucket]

I know! But I'm not interested in money, and it seems possible to provide something much easier to use then emacs, which, although inferior, can still help people who can't invest the time in learning to use emacs. (There's actually a sociologist, Kieran Healy, who's devoted lots of time to carefully explaining his emacs-centred workflow, with almost no uptake. There's just an enormous class of people who use Word -- horrendously inappropriate for this class of work -- when it's easier to make something much better, though still a long way off emacs.

[yk]

For academics, you can pry Latex from their cold dead hands, so better include a Latex mode. Personally, I like emacs and I think that modes, aka the plug-in architecture has really a lot of merit, so try to expose as much as possible of the documents to a plug-in api. ( That one only becomes important when your project is very successful, but perhaps it is good thing to keep in mind.)

One thing I would like to see in emacs is something similar to scrivener's corkboard, basically a virtual corkboard were you can place index cards and group them together.

[fizzbucket]

Awesome; but what do you reckon the best way to implement a corkboard is when it's entirely possible that you're dealing with individual documents, not Scrivener's groups of them? (Sorry, that sounds snarky; it's a genuine question; one global corkboard, per folder, or what?)

[yk]

Sorry for the late answer, just seen your reply.

Again I am thinking about emacs, there you could have multiple cork boards, with multiple Windows. So basically, you open a cork board view, which in the background has a cork board buffer. And in principle you can then open a second cork board window to the same buffer, so that you can lock at two different places at once.

As for how to implement it, I am not sure, my crazy first idea would be as a clip board on steroids. So you mark some text and a index card with the text appears in the cork board.

[veddox]

Different colour themes. I find it a lot easier working with light text on a dark background, others may differ in their preference. The Scratch editor written by the elementaryOS guys has some very nice themes, Gedit for the Gnome DE is not bad either.

[dahart]

Diffs! Ability to see, track, and rollback a document's changes. With a nice side by side interface, of course, not raw display of a diff format.

[hysan]

Toggleable tree view for navigating, opening, closing, creating, and deleting files. You also mentioned previewing, but it'd be nice if you could have toggleable split screen mode for live previews (or wysiwyg mode). Last would be a way for contributors to write extensions to add additional features.

[fizzbucket]

Got the split screen live preview already; tree view sounds a very useful addition, though.

Extensions are also a good plan; the interesting thing is that many of them end up being routed to pandoc, so they can be done with document metadata in any case. For others, one easy thing to do might be to rewrite some of the bits in C++ in PyQt, then have the possibility of importing classes that inherit from the originals and override functions. Does that make sense, do you think?

[hysan]

I've never written any software that had an extension system so I can't comment on whether or not it's a good design. My guess is that so long as the system is well documented, then it can work. Hopefully someone better qualified can address this.

[bariumbitmap]

You already have competition in the form of ReText:

https://github.com/retext-project/retext

(Unless that's the project?)

However, there are some things that ReText does poorly, like syncing between the output window and the input text:

https://github.com/retext-project/retext/issues/108

and some things ReText doesn't really do at all, such as autocompletion of citation labels, checking URLs to see if they are 404, or proper syntax highlighting in math mode.

Those kind of features tend to require doing difficult things like parsing the input, which is why most text editors don't bother.

[fizzbucket]

Nope, ReText is not the project. But it has quite different goals. I'm actually an academic in the humanities (though lots of my work uses digital tools). I got so thoroughly sick of marking essays with shoddy referencing and inconsistent formatting that it seemed like there must be people who could use things like your example of auto-completing citations; that isn't the purpose of retext at all, and its goals are much more to help people who know what they're doing.

ReText is also not very cross-platform, in practice for Linux only, although it's possible to install on a Mac with effort. It might be more justifiable to work on improving it, but the maintainer isn't interested in pandoc support, which, first makes citations very difficult, and second, means submission either to academic journals or university tools like Turnitin is more complex then it needs to be.

Then there's just little things -- like quoting verse in Markdown, which requires two spaces at the end of each line. That's easy enough to make happen automagically, but it's a feature that would never be used by a typical ReText user, or someone using Mou or MacDown, so they're unlikely to want to support it.

[henryscala]

I like the ideas of your text editor, that is for writers other than developers.

I would like the features of editing math equations, ways to draw simple pictures etc except for simple Markdown support.

[bendtherules]

1. Because stories are long, it should have multiple views for the same file. SO that writers can recap what they have written much earlier without losing their current context.

2. Quick find for "Markers" / sections of the writing, so that one can easily scroll up to Chapter 1.2, say.

3. Multi-cursor like Sublime Text to edit multiple mentions of the same name, say

4. Spell-check, it is rudimentary.

[markburns]

> intended more for journalists, academics and students than web developers

Have you asked somewhere else? Seems like you'd get a bias of things developers want here

[daturkel]

Versioning with diffs would be nice—maybe autosaves for recovery as well as user-indicated "draft" points to point out major revisions.

[Immortalin]

Hi! I am interested in this. Do you have an email?

[erkose]

emacs

[halosghost]

Continuing my streak of posts regarding preference which likely apply nearly only to me[1], I will gladly take on this question! As with the others, I should reiterate that I am a niche user and that the things I want will likely not be wanted by everyone else.

1. Terminal-only (^Z is still something I want/need)

2. Not ncurses (as much as I like ncurses and what it did for TUIs, it's got too many pain points and short-comings to make sense lately).

3. Configurable/Extensible/Scriptable through the host language or one DSL (i.e., allowing a ton of different languages for plugins (I'm looking at you vim, ಠ_ಠ) is a SadTime™). Given this and (2), I would be tempted to say I'd prefer this editor to be written in Haskell and use Brick[2]; there is at least one editor that attempts this [3].

4. Incredibly stripped-down core functionality with officially maintained extensions for likely-to-be-wanted features (e.g., syntax highlighting). This is not because I don't want syntax highlighting (I definitely do), but rather the recognition that one size does not fit all and that making the whole system as configurable as possible is often a huge win. Note, this cannot be done at the expense of performance (which is why I would be tempted to say that accomplishing this sensibly would require (3) be accomplished through the host language (and that it would add another strong argument for Haskell)).

5. Modal (One of vim's greatest triumphs is the brilliance and simplicity of function in modal editing—yes, it's a very odd concept when you're starting out, but it's irreplacable once you get used to it)

6. Asynchronous (One of vim's greatest failings is an interface that is completely incapable of dealing with asynchronicity)[4]

7. Some or all of what Gary Bernhardt mentions in "A Whole New World"[5] (great talk anyway if you haven't seen it). Particularly, layers and a flexible auditor.

---

[1] https://news.ycombinator.com/item?id=10072796

[2] https://github.com/jtdaugherty/brick

[3] https://github.com/yi-editor/yi

[4] http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

[5] https://www.destroyallsoftware.com/talks/a-whole-new-world

[emilronnback]

vim

[ymse]

As an Evil user, I concur. Perhaps it could be implemented through a plug-in architecture, with some LISP-like interface.. :)

[Immortalin]

Spacemacs