> Is there a reason you chose PCRE over Lua/LPEG? My internal debate went something like this: LPEG is great for syntax highlighting but not a great fit for regular end-user search+replace. PCRE is ok for syntax highlighting and great for search+replace. I didn't want to require both, and I personally didn't care about perfect highlighting, so I went with PCRE.
Adam On Wed, Mar 29, 2017 at 5:25 PM, <a...@php.net> wrote: >> 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
