> As others already have pointed out this metric isn't that useful in > itself. What it does indicate is that some projects are beyond repair > (e.g. vim).
I agree it's not useful beyond getting a ballpark estimate, esp without taking into account external deps. The 10k figure includes mlbuf but excludes termbox, uthash, and tests[0] arbitrarily. I include the figure mainly to differentiate from giants like vim and emacs. I apply the same 'small' label to vis, or any project which packs a punch given its size. > Having said that, I like that you took inspiration from sam (unfortunately > it seems like either your documentation is lacking or you have left out some > of the most useful features) and try to use/integrate external tools. I began to question whether sam features belonged, so I didn't finish porting. Similarly I had a vim emulation mode that I took out. > That is already better than most editors. Keep having fun. Appreciate the feedback. Thank you. Adam [0] https://github.com/adsr/mle/blob/1e9a467/Makefile#L33-L36 On Wed, Mar 29, 2017 at 4:38 PM, Marc André Tanner <m...@brain-dump.org> wrote: > On Wed, Mar 29, 2017 at 10:54:36AM -0400, a...@php.net wrote: >> > WTF. Did you write a program to generate this much? I've seen >> > operating systems that ran really well at that line count. >> >> Not sure I follow your q, but yes some of it is codegen (the stdio >> scripting part). >> >> My definition of sloc is roughly `cat *.c *.h | wc -l`. Using this >> metric on other editors: > > As others already have pointed out this metric isn't that useful in > itself. What it does indicate is that some projects are beyond repair > (e.g. vim). > > You should at very least use something like cloc(1) which besides comments > also filters out duplicated files. Mind you, it is still a bad metric. > Also I felt like your numbers are a bit off/misleading, hence I took > a quick look. > >> vim: 430k > > No comment required ... > >> kakoune: 27k > > Comparing SLOC of different programming languages makes even less sense. > With C++ you can fit way more complexity into the same number of lines. > The standard library includes a lot more functionality. This doesn't even > yet take boost into consideration. > >> nano: 25k >> vis: 22k > > This includes stuff like the vis-digraph (basically 1 large lookup table) > and vis-menu utilities. You didn't include fzf(1) in your mle tally, > did you? > > If you are fine with disabling more compile time features you could > further subtract: > > 2012 vis-digraph.c > 605 vis-menu.c > 118 text-regex-tre.c > 217 ui-terminal-vt100.c > 2869 vis-lua.c > 5821 total > >> mle: 10k > > After having a quick look, this also feels misleading. Your suggested > shell counting glob doesn't include the core data structure of your > editor because it was moved to an external library. A more accurate > result would be: > > $ wc -l *.[ch] mlbuf/*.[ch] > ... > 13908 total > > Having said that, I like that you took inspiration from sam (unfortunately > it seems like either your documentation is lacking or you have left out some > of the most useful features) and try to use/integrate external tools. > That is already better than most editors. Keep having fun. > > Marc
