
Ask HN: What do you want in a text editor? - fizzbucket
I&#x27;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.<p>But what features would you like to see added to this list? Draft has its Hemingway mode, for example. What&#x27;s missing from text editors you think you&#x27;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.

------
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](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](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](https://news.ycombinator.com/item?id=10072796)

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

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

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

[5] [https://www.destroyallsoftware.com/talks/a-whole-new-
world](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

