README.markdown @master — view markup · raw · history · blame
We don't drink yaedit here... we drink tideay.
It aims to keep my development environment neat and... tideay (ugh.)
See "Notes", below, for my thoughts (= rant) on editors, and why I decided to start this project.
- Python 2.7
Ctrl+O open (or create) a file into a buffer Ctrl+W close buffer Ctrl+I jump to line Ctrl+F find text Ctrl+P alter common prefix of selected lines Ctrl+Enter execute shell command and insert result Tab "productively" rewrite string to left of cursor Shift+Backspace "destructively" rewrite string to left of cursor Ctrl+Z undo Ctrl+Shift+Z redo Ctrl+X cut Ctrl+C copy Ctrl+V paste Ctrl+A select all Ctrl+Q quit tideay
Standard yaedit features
- Continual sync of file under edit to and from disk
- Awesome Ctrl+P multi-line-prefix editing
- No dialog boxes, etc; see yaedit page for more
In the editing pane, pressing the Tab key rewrites the string to the left of the cursor, based on some internal rewriting rules. For example,
--is replaced by
—. See the source code for the full set of rules. The rewriting rules also implement tabs, in the following way:
- four spaces are replaced by eight spaces
- an empty string is replaced by four spaces
- a tab character is replaced by two tab characters
^Irewrites to tab, so you can otherwise insert a real tab character
What Tab does we call "productive" rewriting. There is also a set of rules for "destructive" rewriting, which are applied when Shift+Backspace is pressed. The only rule in this set, thus far, is replacing four spaces with an empty string. This is useful for unindenting, especially when tideay thought you might want an indent but you really didn't.
Typing Enter after a
:, or on a line that begins with
-followed by three spaces, indents the next line (another) four spaces. Most languages benefit from the brackets, Python benefits from the colon, and Markdown benefits from the
Attempted workflow integration
It's definitely not an IDE, but...
Only one copy of tideay can be started from any given directory. This is to discourage two copies from trampling each others' files. (It doesn't outright prevent it, because you can open a file like
../otherproj/README, but that case is less common.)
Typing Ctrl+Enter interprets the line (everything left of the cursor) as a shell command and executes it. Note that this is a little experimental, and the exact usage may vary in the future, but for now, there are three styles:
- Ordinarily, the command that is executed is replaced by the standard
output produced by running the command. This is, among other things,
a neat way to include snippets into the file
- If the line begins with
%, the command is not replaced; the output is appended underneath it, along with another line prefaced with
%. The resultant effect of is that of a pseudo-shell of sorts. This could be useful for inserting shell "how-to" instructions into documentation.
- If the line begins with
|, the current file is piped into the command, and the entire buffer is replaced by the result. (This is a single user action, so it can be undone with Ctrl+Z.) This can be useful in oh-so-many ways, for example
|indentto indent your C source code,
|grep -v blahto delete all lines from the buffer containing
blah, and so forth.
- If the line begins with
cd, the current directory is changed to what follows this (if that text names a valid directory). Since the current directory is a property of the process, this cannot be done by executing a
cdcommand in the shell.
- Ordinarily, the command that is executed is replaced by the standard output produced by running the command. This is, among other things, a neat way to include snippets into the file (e.g.
Other changes/improvements over yaedit
- Editor pane uses a smaller font. Window is initially sized to show 80
columns (on my equipment; with different fonts or whatnot, YMMV. Window
size can be specified with the
- Notebook's tab pane (on the left) has a fixed width. Long filenames will not expand it and ruin the 80-column width of the editor pane.
- Height of each label in the tab pane is smaller.
- Only the basename (not the directory name) of the file is displayed in the label. Full (relative) path to file is shown in the window title.
- No tooltips (they don't show up on hover for me anyway.) Controls are documented in this README for now.
- The hashbang line of the file will be sniffed if the language cannot be determined from the the file extension. Currently supports Python, Ruby, Lua, and shell.
- Special read-only editor panes can show output from a periodically-run
command. The only one implemented so far is a pane that shows the
git diff, created by Ctrl+D.
- To get Markdown syntax highlighting, install gtksourceview-3.0, and copy
language-specsshare directory into gtksourceview-2.0's
language-specsshare directory. Also make sure your
/etc/mimetypesfile contains a line like this one:
text/x-markdown markdown md
- When notebook tab pane exceeds height of window, you can only scroll down as far as the "open" entry. You can't seem to use "find" etc properly. Ensuring the controls are visible, while only the buffer tabs scroll, would be nice (but it doesn't look like GtkNotebook supports this much.)
- Visible whitespace (space, tab, LF) would be really nice. Doesn't look like GtkSourceView supports changing the displayed appearance of a character, but can you make your own syntax highlighting rules, and could you make one for whitespace?
- Pressing Tab or Shift-Tab with some text selected should not do whatever it is that GtkSourceView thinks should be done when that happens.
- Check to see if a rewrite can happen for Tab/Shift+Bkspc. If not, don't start a user action (less to undo.)
- Ctrl+P will de-focus the editing pane, even if no lines/a single line is selected. This can be annoying. Not sure how to handle this yet.
$1(or something?) with the name of the current file.
- Another variant that opens the result in a new buffer, and switches
to it? I'm thinking
hg diff $1. This would require a buffer temp filename strategy. (And it would be nice if, in this case, the filename ended with
.diff, to get the highlighting.) Maybe we could just check to see if the command string included a string like
>foo.txtwith spaces on either side, and use that as the name.
find and replace
- Ctrl+F find should populate find-entry with selected text.
- Find should support case-sensitive and maybe whole-world-only search.
- Replace found text with new text. (This can be done with
|sed, but I don't like
sed, so maybe supply a command-line tool with a simpler interface, like
replace foo bar.)
- Mark and move to mark (like Ctrl+F2/F2 in SciTE)
- Next and Prev should have keyboard shortcuts.
- Some way to switch to a buffer by typing in part of its filename.
- Should be able to populate buffers from all "interesting" files in the current directory tree. (repository <=> workspace)
- Some nice way to move/copy a buffer while inside the editor.
- When file backing buffer is deleted by the system, close the buffer? (Argument against: maybe it was accidental and buffer is only remaining copy of what was there. Maybe "deaden" the buffer. Maybe recreate the file...)
other wild ideas
- One-letter commands could be dealt with specially, so
|r foo barreplaces text. Or something.
- Workspace files, that contain a list of files, and open them all when the workspace file is opened. It could also contain rewrite rules. And be a good place for jotting miscellaneous notes and running miscellaneous commands without wrecking a buffer.
- Plugins. These should just be Python files, in a subdirectory of your home directory (maybe?) which are sourced upon startup. tideay could ship with some, but you'd have to install them yourself. The rewriting maps could be among them, so you could override the builtin rewrite rules with your own. But the builtin ones could also be plugins, in a dir in the distribution... which tideay also reads... or something. But then, this is my editor, so, why? If someone else wants to fork it, that's great, and they can just make the changes to their fork. I dunno.
- VTE widget. For... I don't know. The thing is, the shell commands do
not stream their output, and if you say, like,
nanoCtrl+Enter, it's your funeral. So maybe the commands could be run in a terminal pane, with their output
teed to a file, and it's this file that's inserted when it's done. This would also let you run commands which require a password to be entered.
- Key combination to select URL under cursor (double/triple-clicking doesn't cut it; Ctrl+clicking might) and (further key combination to?) open it using the default browser.
- Should destructive rewriting be the inverse map of productive? If
''is a special case in the map then this could work, because
''rewrites to four spaces.
- Changing directory should support toolshelf — look to see if
toolshelfis present on the path, and if so, call
toolshelf pwdand see if that returns a sensible result, and if so, change dir to that instead.
- Indicate the 80-column mark in the editing pane.
- Some way to force source language highlighting.
- Show column position of cursor.
I guess this fork was precipitated by this article in a roundabout way.
OK, I guess I can't talk about editing without first talking about typing. There are developers who consider typing ability to be a paramount skill. I'm not one of them. I'm only a touch-typist in the loosest sense; the words "home row" mean nothing to me; I favour my right hand while my left hand is sometimes close to useless. For a software developer, being able to type quickly is a "nice-to-have". Here are some skills that are more valuable than typing quickly: ability to conceptualize, ability to explain things clearly, ability to break large problems into smaller parts, foresight, mathematical maturity, ability to step back and see the bigger picture, time management, insight into how humans deal with change... (point made yet, or should I go on?)
And I also guess I can't talk about editors without talking about Those Two.
My first exposure to Emacs was its port to the Amiga that came with Amiga OS 1.3. Consider that, wow, this new computer is one of the next generation: it has a mouse, and a GUI, with windows and menus and... and you want me to edit with... what's this terminal-based thing? This makes no sense. Amiga Basic was naff, but at least its program editor was comprehensible.
My first exposure to Vim was
vi, on the servers at the university. I failed
to see the attraction (but, of course, did not fail to meet people who had
seen the attraction, and hear them talk about the attraction.) If I had to
edit something on the server, I would use
pico (these days it's
on FreeBSD and friends,
easyedit). If I didn't have to edit something on the
server, I wouldn't. To this day,
:q! is pretty much all the
vi I know.
I've never seen the attraction of editors that insist on putting you into one of several "modes" and which only grudgingly accept that we're now in the age of the GUI.
When I first switched to FreeBSD as my development platform, I used nedit. It was OK, but I wasn't a fan of its mass of dependencies.
At some point, I switched to SciTE, for two reasons:
- It supports code folding — although I don't remember if I switched to it before or after reading Nikolai Bezroukov's paper on Orthodox Editors
- I was switching between Windows and FreeBSD a lot, and wanted an editor that was the same on both of them
At some other point, I also read Raskin's The Humane Interface and had some thoughts about some of his points about UI's.
A few years ago, Elliott Hird pointed me at yaedit, not really as a recommendation so much as a "this is interesting, this is how one guy has approached building his own editor." I took it for a spin and couldn't really get the hang of it. When you've built up that Ctrl+S habit to save your work, and it's no longer needed, bleah, it feels so awkward; and it rubs that inner engineer of yours wrong for any program to be constantly writing to the disk like that when it doesn't "have" to.
But then, fast forward a few years to now, and I come across that article I mentioned, and I start to think about how I use SciTE. Taking inventory, I realize I only use a fraction of its features. Code folding is nice, but I only use it once in a blue moon. I seriously under-use its Lua scripting. I don't use any of its IDE-like features (except by accident, at which point they annoy me.) I always seem to be losing track of its configuration files, so features I'd like to use, like abbreviation expansion, I haven't always taken the time to set up.
And I have developed some bad habits with SciTE. The worst, which surely
predates SciTE itself, is probably that I'll start and close the editor in a
very ad-hoc fashion. I want to edit some files, OK,
scite *.py in the shell.
OK, I'm done editing, oh, should I close SciTE, or suspend it and
bg and keep
it up? But then I might forget that it's running and run
scite foo.py again
and have two copies of
foo.py open and out of sync and OK, I better just
close SciTE, I'll open it again for the next edit...
So — all in all, I thought, you know, maybe I could just find a bare-bones editor, and add the things I do use to it, in ways that suit me. And I remembered yaedit, and that it was good enough, and small enough to hack on. And, in the age of version control, maybe saving constantly — treating the disk as if it were the main volatile store, the "core memory" for works of text — is not a bad paradigm. Maybe, in fact, it's a better one. And maybe with it, I can figure out a way to keep my editor running all the time instead of starting and closing it randomly.
As a closing note, I have to say, it's a somewhat odd feeling, both acclimating yourself to a new editor (oh but that urge to press Ctrl+S will die hard!), and at the same time hacking on it, to acclimate it to you.