On Fri, Jul 18, 2014 at 2:34 AM, Rick Johnson <rantingrickjohn...@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 -- https://mail.python.org/mailman/listinfo/python-list
