I need an idea for practise!

[Chris Angelico]

On Fri, Jul 18, 2014 at 2:34 AM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> If the text editor is simply an app that allows: opening raw
> text files, editing them, and then saving the changes, you
> have a *whole* universe of functionality you could add to
> that.
>
>   How about writing a colorizer for source code, and why
>   stop with *only* a Python colorizer? You can learn about
>   regexs by doing this, AND about other languages also.
>
>   How about source code analyzers or debuggers, or smart
>   indent/dedent features and such...
>
>   How about any number of text editing tools that an average
>   user would want: like wrapping tools, searching and
>   replacing tools, etc...
>
>   Heck, how about extending a raw text editor to handle
>   rich text!

To the OP: Ranting Rick's words shouldn't be taken to heart, although
it's plenty possible to learn from him.

My recommendation is: Scratch your own itch. Don't add features for
the sake of adding features - that's a recipe for useless piles of
mess. Instead, add exactly the feature that you need right now (even
if adding that feature means it's no longer "right now" when you get a
chance to use it), and then you know it's being useful. For instance,
I have a mini-editor built into my MUD client [1] which is inferior to
most decent code editors, but it has a few special features that make
it useful *to me* and *in specific circumstances*; for most of my real
work, I still use SciTE, because it's a much better editor. But the
pop-out editor lets me:

* Work with my server via a TELNET-like connection, and simply pop up an editor
* Send the contents of the edit box back to the server. Since the
server controls what's edited, it'll begin with an appropriate command
that says "Hey server, here's that file I was editing".
* Place the initial cursor position, again under server control -
handy when I pop up a "git commit" message editor
* Explicitly hard-wrap text to a specific column width, or auto-wrap on send
* Integrate editing of text into any server-side command - it might
not be a file that's being edited

All this makes it distinctly superior to either ssh'ing to the server
and editing a file (possible only for actual files, possible only for
people with ssh logins to the server, etc, etc, etc), or explicitly
copying and pasting to another editor window (much easier to let the
program do it). And since it's a feature I use on a regular basis,
there's a guarantee that it's actually useful, and therefore will be
developed as it has need. In contrast, features that I added to a
program only because someone said they'd use it (and then probably
never even used it themselves) tend to languish, left as an artifact
of a previous era rather than constantly improved.

By the way, one specific point about RR's advice: A colorizer should
*not* be written using regexps. It'd make for an absolute nightmare of
impossible-to-debug regexp strings, plus there are fundamental
limitations on what you can accomplish with them. You need to use a
lexer - a lexical analyzer. Basically, to correctly colorize code, you
need to have something equivalent to the first part of the language
interpreter, but with a lot more tolerance for errors. That's a pretty
big thing to write as regexps.

ChrisA


[1] Code here: https://github.com/Rosuav/Gypsum/blob/master/plugins/editor.pike