5 ms·

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%

by nsf 13y ago

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).

sergiosgc 13y ago
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).
- nsf 13y ago
  I totally agree with that, but you know how it goes with sensitive tools like editors. "Nya nya nya, but where is my feature X?" Writing the right combination of what I want is a perfect way to solve this problem.
- salgernon 13y ago
  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.
- Ziomislaw 13y ago
  there is also zile[1] [1]: https://www.gnu.org/software/zile/ https://www.gnu.org/software/zile/
stiff 13y ago
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/ 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.
- nsf 13y ago
  I know, I know. I don't take it that personally, just was clarifying why I wrote it and that it's not necessary how I write software.
  - sigzero 13y ago
    Good on you! Is this just for editing "go" or more generic?
    - nsf 13y ago
      I use it for all text editing. Starting from config files and ending with Go/C/C++/Python/bash.
- papsosouid 13y ago
  >the Plan9 and suckless communities Are two totally separate things and you are painting them both with the suckless brush. The plan9 community is nothing like that at all.
  - stiff 13y ago
    I remember some poor guy asking about syntax highlighting in Acme and the reaction was pretty similar...
    - papsosouid 13y ago
      Syntax highlighting is not a simple configuration option, it is a whole huge subsystem that has to be written.
unwind 13y ago
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.
- nsf 13y ago
  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. Anyways.. It works very well in practice.

by nsf 13y ago

sergiosgc 13y ago

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).

nsf 13y ago
I totally agree with that, but you know how it goes with sensitive tools like editors. "Nya nya nya, but where is my feature X?" Writing the right combination of what I want is a perfect way to solve this problem.
salgernon 13y ago
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.
Ziomislaw 13y ago
there is also zile[1] [1]: https://www.gnu.org/software/zile/ https://www.gnu.org/software/zile/

stiff 13y ago

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/ 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.

nsf 13y ago
I know, I know. I don't take it that personally, just was clarifying why I wrote it and that it's not necessary how I write software.
- sigzero 13y ago
  Good on you! Is this just for editing "go" or more generic?
  - nsf 13y ago
    I use it for all text editing. Starting from config files and ending with Go/C/C++/Python/bash.
papsosouid 13y ago
>the Plan9 and suckless communities Are two totally separate things and you are painting them both with the suckless brush. The plan9 community is nothing like that at all.
- stiff 13y ago
  I remember some poor guy asking about syntax highlighting in Acme and the reaction was pretty similar...
  - papsosouid 13y ago
    Syntax highlighting is not a simple configuration option, it is a whole huge subsystem that has to be written.

unwind 13y ago

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.

nsf 13y ago
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. Anyways.. It works very well in practice.