Emacs is big, startup is slow and you have to carry a pile of elisp scripts which fulfil your feature needs. All features has to be written in elisp of course that could be an issue too. Just a matter of taste.
Please. I don't even bother compiling my .el to .elc and I've got a shitload of modes and a gigantic .emacs file (which I should split btw).
Emacs, from the scratch, takes two seconds to fully load, including all the modes and my solarized color theme etc. I'm not talking about always running an Emacs server to which you can connect in a split second: no, I'm talking about a cold start.
It's 2013 and that's on a Core i5 3450s with 4 GB of RAM. Hardly a speed/memory demon.
If I was motivated I'd compile all my .el to .elc and always run emacs in server/daemon mode to connect lightweight windows to it but why bother!? The friggin' entire thing launches in two seconds!
Regarding the "Emacs is big", I know the joke was funny when people, 20 years ago, were writing that Emacs meant "Eight Megabytes And Constantly Swapping" but in this day and age where most devs are using IntelliJ IDEA, Eclipse or other super-fat IDEs, you have to admit that Emacs is really in the "very very very lightweight camp".
Yes, you need lot of elisp scripts: and preferrably as much as possible written by yourself, because this means you're tailoring your editor to your needs, not the other way around.
Two seconds? Is this a joke? My browser starts faster than that. Often it takes me less than two seconds to open a file, make a minor edit, save it, exit, and recompile.
I agree this panic is quite annoying sometimes. Will make a proper error message when I have time. A very minor issue at the moment. You see I'm not really actively working on it anymore, I use the godit for all of my text editing tasks and if some feature/bug annoys me a lot in godit - I fix it. Directory opening by accident happens sometimes, lol, and when you see a panic message, you panic as well, but then phew.. :)
Never used plan9 in my life. The reason why I wrote this editor is because I don't like bloated emacs and I use this many of its features. Go produces nice 100% statically linked binaries, so eventually I can just wget the godit to any of my linux machines and just use it.
The editor is never meant to be used by anyone except me. But if someone finds it nice, I don't mind sharing it. Plus it's the only serious example of termbox library usage (I wrote it too).
I was semi-joking in reference to the comment, the Plan9 and suckless communities are famous for being very hard-headed about programming being the only way to customize their software. For example, I use dwm - http://dwm.suckless.org/ and like it a lot, though I wish they would change this aspect. I am not criticizing what you did in any way, in fact it looks very nice in comparison to great many similar projects, nice code and interesting design.
Did you read that? It does not support your notion that the plan9 community thinks programming is the way to customize software. It shows that the plan9 community thinks you shouldn't do those things, at all. They are not missing because you should edit the code to change them, they are missing because they should never exist.
Hi! I think I got (I'm not a Go programmer, reading Go is slow and not very reliable for me) that buffers are represented as linked lists of lines.
If this is true, do you still find the performance satisfactory when editing large-ish files (tens of thousands of lines)?
It used to be that buffer representation for general-purpose editing was kind of a Real Problem, so it's interesting if a basic linked list of strings representing lines cuts it, these days.
Godit is quite fast. I tested the godit on intel atom netbook, it keeps CPU usage fairly low.
In my opinion linked list of lines is perfect here. Because the only time you need to go through it in a linear fashion is the actual "goto line" operation. The rest is mostly O(1). Of course line insertion is much more common than "goto line" in editors.
The only problem in godit is that it still doesn't handle long lines very well, here most of the operations are O(N). In fact in godit every time you move a cursor or basically do anything it will do O(N) operation on a current line. I checked this kind of stuff on long enough line (10k), no problems here. I don't think there are that many docs with lines longer than 10k.
So, yes, it will work on very large files without any problems. I've just tested it by creating a 56M file with ~660k lines. Can't see any performance issues on my i5-3470, except for loading and saving, it feels like 0.5s for both or so.
Of course contiguous buffer is not an efficient way to do an editor, I guess "advanced" editors use rope data structure or something. Although most of the editors load large files slower than godit. In a perfect world on files bigger than say 50M you should do memory mapping or something. But most editors like to know the amount of lines in a file they're showing to you, so, no mmap here.
Writing software is always a good idea, at least for the experience, so don't be offended by the following comment.
In the case of this particular itch, there are many small statically linked editors, some of them quite powerful. I don't think a small emacs was ever spotted, but the original vi (not vim) is often statically linked and present in /bin in Linux installs (it's a rescue thing).
Micromacs was favorite in the late 80s. JOVE early 90s. And the commercial unipress emacs. GNU emacs outlived them, probably because situations where a light spot editor was desired are now fast enough that there is very little additional cost to a full featured editor.
That being said, I still have EDITOR set to /usr/bin/emacsclient.
Sure, but honestly the original complaint was implying that godit is badly structured. Yes, I don't use Go packages for it, because it's just a small 5k lines of code project and I don't need to use 100 packages to avoid namespace clashes. I use a separate file for most of editor modes and concepts, what else the author wants me to do? Hence, the irony in the answer.
Sorry, my original comment was way harsher than necessary. I wasn't meaning to imply you had structured it badly, the use of files is certainly clear.
I was just wondering if the lack of folders was a typical Go thing. For example, I probably would have something like modes/{all _mode.go files}, and maybe view/{view files}, but I've never touched Go, so I was wondering whether this was unidiomatic.
Well in Go there are no makefiles, but there is a tool called "go". It can build stuff for you. It maintains an assumption that all *.go files within the same directory belong to the same package. So you can't actually store multiple packages in the same dir or span files of one package across multiple dirs and use the go tool at the same time. Since the go tool makes like really easier, I choose to obey its conventions. That's why all files are in the same dir.
And I can't just add "modes" and "view" packages, because there are parts in them which depend on core concepts, which leads me to another "core" package or something. And that's 3 packages already. When there's 3, there's 4. It's easier the way it is.
You can do either. Folders are packages, so if you had /modes, that would be a modes sub-package which could be included in the top level code with import.
That's just my english. Of course I meant that the tab size is the same as the size of 8 space characters. And it sounds like the tab _character_ is an equivalent to 8 spaces, which is not true. Sorry for confusing description.
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
I do agree that there comes a point where you can get over zealous with indentation, but 3 levels deep is pretty common. In fact you idle at one level of indentation just with having your code inside a function. So basically all you need is one conditional inside a loop and you're already maxed out.
