> 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, <as_AT_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 <mat_AT_brain-dump.org> wrote:
>> On Wed, Mar 29, 2017 at 10:54:36AM -0400, as_AT_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
Received on Thu Mar 30 2017 - 18:53:31 CEST