

Godit - A very religious text editor written in Go - obilgic
https://github.com/nsf/godit

======
alisnic
"the tab size is always an equivalent to 8 spaces/characters" - our faiths are
incompatible

~~~
klapinat0r
<https://github.com/nsf/godit/blob/master/godit.go#L14>

> _\- tabstop_length = 8_

> _\+ tabstop_length = 4_

~~~
stiff
The so-called Plan9 way of providing customizable features.

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

~~~
salgernon
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.

------
frozenport

      And no wonder, for Satan himself masquerades as an angel of light.
      ~ 2 Corinthians 11:15
    

Emacs is the devil

------
buster
8 characters tab width is insane. :(

~~~
mich41
Roundness of the Earth is equally insane. But both are facts.

    
    
      m@sauron:~ $ echo -e '\tx'
              x

~~~
yati
From PEP-8, "Use 4 spaces per indentation level. For really old code that you
don't want to mess up, you can continue to use 8-space tabs." [1].

While I agree on ending the '\r\n' mania(which itself is a very hard task),
pushing tab stops down my throat is not cool.

[1]: <http://www.python.org/dev/peps/pep-0008/>

~~~
mich41
I have no problem with people using 4 spaces for indentation.

However, damned shall be those who think that tabs are anything but 8 spaces
wide and actually use them this way in their code. Tabs _really are_ 8 spaces
wide and every terminal will tell you so.

Real world example: just yesterday I've been bitten by Eclipse defaulting to
use "4 space wide tabs" for indentation in otherwise space-indented codebase.
Everything looked nice and cool until I ran _git diff_. How could Eclipse
developers think that it was a good idea?

~~~
spacemanaki
Eclipse is very goofy about this, and it's something I loathed about using it
(having recently switched to IntelliJ, which is better but not by an order of
magnitude). In my experience, it will sometimes indent according to your
settings, spaces or tabs, but at other times, based on some other setting that
is in a different place than the first, it will indent based on the _line
previous to the one you are indenting_. This results in a kind of slow creep
of badly formatted code entering the codebase, if you have a lot of developers
who don't care or don't know to check whitespace upon commit, and don't
explicitly share a well-customized settings file.

At least IntelliJ has Emacs-style DWIM tab, but still has a whole host of
problems with its better than Eclipse but still subpar editor.

------
densh
Performance is truly impressive. And I really love how small the codebase
actually is. I've been dreaming about writing my own text editor for quite
some time. This will really help me to get started, thanks a lot nsf!

p.s. panic on opening a directory isn't really a best way to say that you
don't support viewing directories...

~~~
nsf
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.. :)

------
dbaupp
Is it a Go thing to have no file organisation? (Is this tooling sufficiently
nice that this is manageable?)

~~~
nsf
Do you want me to write code like that?
<https://github.com/Mikkeren/FizzBuzzEnterpriseEdition>

~~~
TheZenPsycho
<https://yourlogicalfallacyis.com/black-or-white>

~~~
nsf
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.

~~~
dbaupp
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.

~~~
nsf
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.

~~~
dbaupp
Ah, ok, that does sound much easier.

(Thanks for the explanation! :) )

------
human_error
I think Gomacs or Gemacs would've been better name. It looks so similar to
emacs.

~~~
nsf
Perhaps, but it's too late to change the name.

------
nemo1618
if only it had Vim bindings instead of Emacs bindings :/

I've been searching for something less bloated than Vim for a while (straight
vi doesn't cut it).

------
jaequery
why not just emacs?

~~~
nsf
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.

~~~
martinced
_"Emacs is big, startup is slow..."_

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.

~~~
4ad
_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.

------
martinced
But why oh why immitate the Emacs shortcuts?

I love Emacs. I use it all the time. But the default shortcuts are the most
stupid thing ever. That Control-x (C-x in Emacs lingua) is insanity at its
best: due to the stupid non-symmetric layout of typical staggered keyboards
'x' in itself is one the hardest key to type (the equivalent with the right
hand is way easier : '>' on a QWERTY keyboard). I'm a touch-typist and to hit
'x' I need to move my whole hand a bit. To hit '>' I just need to move on
finger. I blame this on the fact that keyboard are using a staggered layout
instead of a matrix or symmetric layout but whatever.

Then Control. Zomg. Control has to be accessed with the left pinky if you're a
touch-typist: some _very_ touch-typist friendly keyboards like the HHKB Pro 2
don't even botter with a right control key.

So to hit "C-x" you're supposed to use the two leftmost fingers of your left
hand: this alone has to be one of the most RSI inducing keyboard shortcut
ever.

But in Emacs everything is configurable. So I'm using "C-," to replace "C-x"
and "M-," to replace "M-x".

It shall never cease to amaze me (in a very sad way) that when people "copy
Emacs", the first thing they copy are the Emacs shortcuts. The Emacs shortcuts
are the lamest thing ever in Emacs.

I love Emacs but I hate its default shortcuts. Emacs is not about its
shortcuts: Emacs is about tailoring it to your needs by using Lisp.

I'm also wondering why that constant loss of energy in editors which shall
_never_ produce anything close to what one million lines of elisp code are
providing. I'd much rather see that energy spend on creating a bridge for the
Go-completion facility in Emacs, the real thing.

~~~
nsf
I hope no emacs users use control, there is a caps lock for that.

It's ok to disagree with godit, it's not meant for everybody. Frankly, just
for me. And if someone else likes it, I don't mind sharing it.

Go-completion facility in Emacs is available. `github.com/nsf/gocode` has two
plugins for emacs (auto-complete-mode and company-mode).

