Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Roberto E . Vargas Caballero 
> I wrote a patch[0] for mg which sort of adds Unicode support a while

I wrote a 1 line editor for st [1]. It allows you to edit a page of text
and then print it to stdout or to some other file using -o.


Regards,

[1] http://lists.suckless.org/dev/1401/19894.html

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág 

Thanks, it works.

-- 
caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread S. Gilles 
On 2017-04-10T11:54:29+, Cág wrote:
> S. Gilles wrote:
>  
> > I wrote a patch[0] for mg which sort of adds Unicode support a while
> > back via wchar_t. Upstream interest was low, as they were just about
> > to release 6.0 and I got the impression they'd rather write it
> > themselves, but as far as I can tell it works. At the very least,
> > it could be used as a guide towards which parts of mg need to be
> > ripped out and rewritten.
> 
> Do you have a .diff file? I keep Alpine ports locally, so I could've
> added it without copying the whole tree.
> 
> Does mg in 6.0 support Unicode? For some reason our version is
> 20140414 and I can't compile 20170401:
> ---
> fileio.c:104:17: error: 'DEFFILEMODE' undeclared (first use in this function)
> 
> fileio.c: In function 'copy':
> fileio.c:384:17: error: 'DEFFILEMODE' undeclared (first use in this function)
> 
> fileio.c: In function 'make_file_list':
> fileio.c:504:25: error: 'MAXNAMLEN' undeclared (first use in this function)
> ---
> 
> with warnings before.

I've attached the patch I'm using against hboetes' portable branch
(rebased just now).  I also run a few musl machines, and for them
I have a patches for the issue you describe. The patches aren't
anything clever (I just give definitions for MAXNAMELEN and
DEFFILEMODE), but it works as of 2017-04-10.

 - It should just work by default.

 - If you want to restore old octal
   expansion behavior, run `M-x show-raw-mode'.

 - If you want to insert a character by unicode codepoint, run `M-x
   insert-char' (I have `global-set-key "\^x\^i" insert-char' in
   my .mg).

 - Motion is on a byte-by-byte level, which for some reason
   I thought was a good idea (so you can wade into the middle of a
   wide character and insert bytes in the middle). (I predict you'll
   get fed up with this and change it.)

 - If you have a silly machine where wchar_t doesn't hold unicode
   codepoints, the results will be silly.

-- 
S. Gilles
diff --git a/README.md b/README.md
index 994d6be..2f5d2c1 100644
--- a/README.md
+++ b/README.md
@@ -1,49 +1,50 @@
-# PORTING MG AND USING LIBBSD
+# mg with wide display support.
 
-I've maintained and ported mg for quite some time now and at first it
-was easy recently it got harder and harder since it was a moving
-target. Especially the inclusion of some system specific libraries since
-about 2 years ago made it too much of an effort for my humble coding
-skills.
-
-So recently Jasper Lievisse Adriaanse asked me to try it again and I
-restarted working on the project and ran into exactly the same problems
-again. While googling for solutions I ran into libbsd:
-
-  http://libbsd.freedesktop.org/wiki/
-
-It's a porting library for OpenBSD code! And after installing that it
-was a piece of pie to get mg ported again.
-
-## PORTING TO ALL OTHER PLATFORMS
-
-Okay, that was debian. Now I have to get the rest of all the previously
-suported platforms working again. All help is welcome and as always:
-Please provide patches that do not break stuff for other platforms.
-
-## BUILDING MG
-
-So, basic instructions for building mg:
-
- - Get libbsd installed.
- - Run the following commands:
+I just received this amazing patch from S. Giles. For those impatient
+people: check it out (tihihi) and add this line to your `.mg`
 
 ```
-make
-sudo make install
+set-default-mode "wide"
 ```
 
-## USING CVS
-
-This code is the cvs checkout from the OpenBSD project so if you install
-cvs you can see what I changed to port mg. Like this:
-
-```
-cvs diff -uw
-```
-
-## ABOUT fgetln()
-
-Incase you are wondering about that deprecation warning, here is a nice 
explanation about why it is hard to fix:
-
-  
http://niallohiggins.com/2009/10/03/read-a-file-line-by-line-in-c-secure-fgets-idiom/
+## Introduction by S. Giles
+
+Hi,
+
+I've got a patch that allows mg to display wide characters, if you're
+interested.
+
+It can be turned on by show-wide-mode (better name welcome), and is
+fairly limited in regard to what types of wide characters are
+displayed. Everything goes through mbrtowc(3), so you get exactly one
+supported encoding: whatever LC_* says. Everything else is displayed
+as octal escape sequences (as normal current behavior). Motion is
+still on a byte level, so multibyte characters are slow to travel
+through, and you can insert bytes in the middle of them (which works
+fine). A limited version of insert-char is also included, which works
+through wchar_t, so that on any system with __STDC_ISO_10646__ set,
+inserting unicode codepoints by number is possible.
+
+It also fixes some odd bugs related to wide character display and
+extended lines. For example: in a file with enough wide characters
+(such as ＡＢＣ) to make a line extend far (say, 200 characters on an
+80-wide display), moving to the right one character at a time will (in
+20160118) corrupt the display, then eventually segfault, because
+vtpute doesn't perform the same octal expansion as vtputc and the
+columns get out of sync.

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág 
S. Gilles wrote:
 
> I wrote a patch[0] for mg which sort of adds Unicode support a while
> back via wchar_t. Upstream interest was low, as they were just about
> to release 6.0 and I got the impression they'd rather write it
> themselves, but as far as I can tell it works. At the very least,
> it could be used as a guide towards which parts of mg need to be
> ripped out and rewritten.

Do you have a .diff file? I keep Alpine ports locally, so I could've
added it without copying the whole tree.

Does mg in 6.0 support Unicode? For some reason our version is
20140414 and I can't compile 20170401:
---
fileio.c:104:17: error: 'DEFFILEMODE' undeclared (first use in this function)

fileio.c: In function 'copy':
fileio.c:384:17: error: 'DEFFILEMODE' undeclared (first use in this function)

fileio.c: In function 'make_file_list':
fileio.c:504:25: error: 'MAXNAMLEN' undeclared (first use in this function)
---

with warnings before.

Thanks

-- 
caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág 
robin wrote:

> I wrote a vi like editor in <1k lines.
> Fairly shitty, but maybe it inspires to something.
> https://github.com/byllgrim/svi

It is a good base, thanks, even though it lacks a delete functionality
(backspace doesn't work on already written to a file characters),
undo and a ruler.

-- 
caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-09 Thread S. Gilles 
On 2017-03-29T19:00:03+, Cág wrote:
> Wolfgang Corcoran-Mathe wrote:
> 
> > mle is too complex for my taste (scripting and syntax highlighting
> > seem unecessary, though I’m in the grumpy minority here)
> 
> Personally I'd like to see more of something like mg or busybox' vi.
> Unfortunately they both don't support UTF-8. nvi is pretty good as
> well.

I wrote a patch[0] for mg which sort of adds Unicode support a while
back via wchar_t. Upstream interest was low, as they were just about
to release 6.0 and I got the impression they'd rather write it
themselves, but as far as I can tell it works. At the very least,
it could be used as a guide towards which parts of mg need to be
ripped out and rewritten.

[0] https://github.com/hboetes/mg/tree/display-wide-characters

-- 
S. Gilles

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-09 Thread robin 
On Wed, Mar 29, 2017 at 07:00:03PM +, Cág wrote:
> 
> Personally I'd like to see more of something like mg or busybox' vi.
> Unfortunately they both don't support UTF-8. nvi is pretty good as
> well.
> 
> -- 
> caóc
> 

I wrote a vi like editor in <1k lines.
Fairly shitty, but maybe it inspires to something.

https://github.com/byllgrim/svi

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-31 Thread Snobb 
On 30/03/17 10:02P, Kamil Cholewiński wrote:
> On Wed, 29 Mar 2017, Snobb  wrote:
> > So without lua, the editor goes with default hard-coded settings and
> > no way for even minor customisation like number of spaces per tab,
> > tabs or spaces, etc.
> 
> Same for dwm. Use Awesome if you want dwm with Lua.
> 
Heh?! Not sure how dwm is related here. You're right, some of the
configuration can still be done in config.h, but as Mark said you won't be
able to use 100% of the features. Actually, I don't see much of the
configuration in config.def.h apart from default key mappings, so it looks
like even basic editor configuration will require tinkering and perhaps
patching (if compiled without lua).
Speaking of dwm and awesome, as I said I very much prefer config.h to lua.
IMHO, awesome does not really add much functionality apart from awkward
configuration files. Not the functionality I commonly use anyway.

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-30 Thread as 
> 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,   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  
> 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

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-30 Thread Kamil Cholewiński 
On Wed, 29 Mar 2017, Snobb  wrote:
> So without lua, the editor goes with default hard-coded settings and
> no way for even minor customisation like number of spaces per tab,
> tabs or spaces, etc.

Same for dwm. Use Awesome if you want dwm with Lua.

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Roberto E . Vargas Caballero 
> purposes. Both approaches are better than writing your own configuration
> parser.

You can write your parser configurator using:


scanf(" %40s = %40s", key, value);

Regards,

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Snobb 
On 29/03/17 10:53P, Marc André Tanner wrote:
> On Wed, Mar 29, 2017 at 08:22:04PM +0100, Snobb wrote:
> > I liked the idea of vis in its early stage until it went the "lua" way.
> 
> I'm sorry that you feel that way, but you can still completely disable Lua
> during compile time and get a working editor (albeit with less features).
My understanding is that if lua isn't compiled in you can't even have an .rc
file, correct? So without lua, the editor goes with default hard-coded
settings and no way for even minor customisation like number of spaces per
tab, tabs or spaces, etc.

> In my opinion Lua is among the least sucking languages for the purpose it
> is used in vis. It is simple (almost everything is a table) but still
> versatile and powerful. Also the implementation is rather nice. Up
> to a point you can think of Lua as a runtime replacement for the C
> pre-processor commonly used by suckless projects for configuration
> purposes. Both approaches are better than writing your own configuration
> parser.
I haven't had much experience with Lua (apart from writing a fairly trivial
Wireshark dissector a while back, but no C embedding) but from what I've seen
it does look pretty good. It still sounds like a bit of an overkill to use Lua
for config parsing alone unless there are some scripting features on the
roadmap, which they are in case of vis.
I never use plugins/scripts in editors, so I for one would have opted for
suckless config.h. :)

Just FYI and completely out of scope: In my most recent vis "takes" I went as
far as installing lua and all required lua modules, but there were little
things that needed to be fixed. Eg. /usr/local/share/vis/* files were
installed with wrong permissions, termkey may be a pain to install on some
OSs, some lua errors that lexers cannot be found even though they're there
(and with fixed permissions), etc. I wouldn't use the color schemes and all
that stuff anyway, so couldn't motivate myself to get it to work and
eventually gave up.
Vis looks impressive in a video demo I've seen somewhere in the web though and
I like the idea of blending vi and sam.

/Alex

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Marc André Tanner 
On Wed, Mar 29, 2017 at 08:22:04PM +0100, Snobb wrote:
> I liked the idea of vis in its early stage until it went the "lua" way.

I'm sorry that you feel that way, but you can still completely disable Lua
during compile time and get a working editor (albeit with less features).

In my opinion Lua is among the least sucking languages for the purpose it
is used in vis. It is simple (almost everything is a table) but still
versatile and powerful. Also the implementation is rather nice. Up
to a point you can think of Lua as a runtime replacement for the C
pre-processor commonly used by suckless projects for configuration
purposes. Both approaches are better than writing your own configuration
parser.

Marc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread as 
> The idea of having php installed just to have my editor working terrifies me
> (or a mandatory dependency of any language interpreter for that matter). I
> liked the idea of vis in its early stage until it went the "lua" way.

No need for php at runtime or even build-time. It's used only for
codegen and the artifact is included in the repo.

> The termbox requires python for compilation. So to get this editor working one
> does need a gorilla holding a banana and entire jungle. :)
> It definitely has more then 1 external deps (eg. php, pcre). Not sure why
> dep[1-2] are not considered external? You need to build/install them
> separately, don't you?

It's true there are actually 4 deps (pcre, uthash, mlbuf, termbox).
However, if building from the repo, the end-user only needs to satisfy
the pcre requirement. The rest of the deps are included, and a single
`make` at the top level builds everything. As you point out,
unfortunately python (waf) is required to build termbox. I went with
termbox over ncurses as I vastly prefer its api, and the library
itself is cleaner. I'll see if the maintainer will merge a plain
Makefile.

Adam


On Wed, Mar 29, 2017 at 3:22 PM, Snobb  wrote:
> The idea of having php installed just to have my editor working terrifies me
> (or a mandatory dependency of any language interpreter for that matter). I
> liked the idea of vis in its early stage until it went the "lua" way.
>
> The termbox requires python for compilation. So to get this editor working one
> does need a gorilla holding a banana and entire jungle. :)
>
> I agree with others here that syntax highlighting is mostly useless, even
> though I like tinting comments in my editor.
>
> On 29/03/17 09:57P, a...@php.net wrote:
>> Hello,
>>
>> I am announcing mle, a small terminal-based text editor written in C:
>>
>> https://github.com/adsr/mle
>>
>> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
>
> It definitely has more then 1 external deps (eg. php, pcre). Not sure why
> dep[1-2] are not considered external? You need to build/install them
> separately, don't you?
>
>> extensible / scriptable, and fast. The default setup is nano- or
>> emacs-like, but it supports modes as well. I've used it daily for 2+
>> years. You can view some demos here:  http://imgur.com/a/ZBmmQ
>>
>> ### Aims
>>
>> * Keep codebase small
>> * Require minimal dependencies
>> * Make extensibile and configurable
>> * Favor simplicity over portability
>> * Use shell commands to enhance functionality (e.g., grep, tree)
>> * Enjoy writing C
>> * Annoy the world with another text editor
>>
>> ### Features
>>
>> * Small codebase (~10k sloc)
>> * Only 1 out-of-repo dependency (pcre)
>> * Full UTF-8 support
>> * Syntax highlighting (via pcre)
>> * Stackable key maps (modes)
>> * Extensible via any program capable of stdio
>> * Scriptable rc file
>> * Built-in text editing language (lel)
>> * Key macros
>> * Multiple splittable windows
>> * Regex search and replace (with capture groups)
>> * Large file support (beats vim in this benchmark
>> http://i.imgur.com/VGGMmGg.gif)
>> * Incremental search
>> * Linear undo and redo
>> * Multiple cursors
>> * Headless mode
>> * Movement via less
>> * Fuzzy file search via fzf
>> * File browsing via tree
>> * File grep via grep
>> * Decently portable (tested on Linux, cygwin, macOS)
>>
>> ### Notes
>>
>> * There is a TODO list here[1].
>> * The editor back-end, mlbuf[2], is a standalone library which can be
>> repurposed.
>> * mlbuf's main data structure is a linked list of C strings, similar to nano.
>> * The built-in editing language, lel, is an experiment. I question
>> whether it belongs.
>> * There is a fork of mle called eon[3] which adds mouse support, Lua
>> plugins, and notepad-like defaults.
>>
>> As always, patches and feedback are welcome.
>>
>> Thanks,
>> Adam
>>
>> [0] pcre; termbox and uthash are included in-repo
>> [1] https://github.com/adsr/mle/blob/1e9a467/mle.h#L637
>> [2] https://github.com/adsr/mlbuf
>> [3] https://github.com/tomas/eon
>>

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Snobb 
The idea of having php installed just to have my editor working terrifies me
(or a mandatory dependency of any language interpreter for that matter). I
liked the idea of vis in its early stage until it went the "lua" way.

The termbox requires python for compilation. So to get this editor working one
does need a gorilla holding a banana and entire jungle. :)

I agree with others here that syntax highlighting is mostly useless, even
though I like tinting comments in my editor.

On 29/03/17 09:57P, a...@php.net wrote:
> Hello,
> 
> I am announcing mle, a small terminal-based text editor written in C:
> 
> https://github.com/adsr/mle
> 
> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,

It definitely has more then 1 external deps (eg. php, pcre). Not sure why
dep[1-2] are not considered external? You need to build/install them
separately, don't you?

> extensible / scriptable, and fast. The default setup is nano- or
> emacs-like, but it supports modes as well. I've used it daily for 2+
> years. You can view some demos here:  http://imgur.com/a/ZBmmQ
> 
> ### Aims
> 
> * Keep codebase small
> * Require minimal dependencies
> * Make extensibile and configurable
> * Favor simplicity over portability
> * Use shell commands to enhance functionality (e.g., grep, tree)
> * Enjoy writing C
> * Annoy the world with another text editor
> 
> ### Features
> 
> * Small codebase (~10k sloc)
> * Only 1 out-of-repo dependency (pcre)
> * Full UTF-8 support
> * Syntax highlighting (via pcre)
> * Stackable key maps (modes)
> * Extensible via any program capable of stdio
> * Scriptable rc file
> * Built-in text editing language (lel)
> * Key macros
> * Multiple splittable windows
> * Regex search and replace (with capture groups)
> * Large file support (beats vim in this benchmark
> http://i.imgur.com/VGGMmGg.gif)
> * Incremental search
> * Linear undo and redo
> * Multiple cursors
> * Headless mode
> * Movement via less
> * Fuzzy file search via fzf
> * File browsing via tree
> * File grep via grep
> * Decently portable (tested on Linux, cygwin, macOS)
> 
> ### Notes
> 
> * There is a TODO list here[1].
> * The editor back-end, mlbuf[2], is a standalone library which can be
> repurposed.
> * mlbuf's main data structure is a linked list of C strings, similar to nano.
> * The built-in editing language, lel, is an experiment. I question
> whether it belongs.
> * There is a fork of mle called eon[3] which adds mouse support, Lua
> plugins, and notepad-like defaults.
> 
> As always, patches and feedback are welcome.
> 
> Thanks,
> Adam
> 
> [0] pcre; termbox and uthash are included in-repo
> [1] https://github.com/adsr/mle/blob/1e9a467/mle.h#L637
> [2] https://github.com/adsr/mlbuf
> [3] https://github.com/tomas/eon
>

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Cág 
Wolfgang Corcoran-Mathe wrote:

> mle is too complex for my taste (scripting and syntax highlighting
> seem unecessary, though I’m in the grumpy minority here)

Personally I'd like to see more of something like mg or busybox' vi.
Unfortunately they both don't support UTF-8. nvi is pretty good as
well.

-- 
caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Laslo Hunhold 
On Wed, 29 Mar 2017 09:57:49 -0400
a...@php.net wrote:

> I am announcing mle, a small terminal-based text editor written in C:
> 
> https://github.com/adsr/mle
> 
> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
> extensible / scriptable, and fast. The default setup is nano- or
> emacs-like, but it supports modes as well. I've used it daily for 2+
> years. You can view some demos here:  http://imgur.com/a/ZBmmQ

The output of sloccount yields:

SLOCDirectory   SLOC-by-Language (Sorted)
8211top_dir ansic=7930,php=281
71  tests   sh=71
0   mlbuf   (none)
0   termbox (none)


Totals grouped by language (dominant language first):
ansic: 7930 (95.75%)
php:281 (3.39%)
sh:  71 (0.86%)


Total Physical Source Lines of Code (SLOC)= 8,282
Development Effort Estimate, Person-Years (Person-Months) = 1.84 (22.09)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.68 (8.11)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 2.73
Total Estimated Cost to Develop   = $ 248,704
 (average salary = $56,286/year, overhead = 2.40).

-- 
Laslo Hunhold

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread as 
> 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:

vim: 430k
kakoune: 27k
nano: 25k
vis: 22k
mle: 10k
kilo: 1k

Naturally it's not perfect as it counts comments and blank lines etc.
But at least in that sense it is on the small side.

Adam


On Wed, Mar 29, 2017 at 10:34 AM, Martin Kühne  wrote:
> tl;dr
>
>> mle weighs in at ~10k sloc
>
> WTF. Did you write a program to generate this much? I've seen
> operating systems that ran really well at that line count.
>
> cheers!
> mar77i

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Martin Kühne 
tl;dr

> mle weighs in at ~10k sloc

WTF. Did you write a program to generate this much? I've seen
operating systems that ran really well at that line count.

cheers!
mar77i

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread hiro 
hahahahaha, the right people are turning up finally.
php.net

On 3/29/17, a...@php.net  wrote:
> Hello,
>
> I am announcing mle, a small terminal-based text editor written in C:
>
> https://github.com/adsr/mle
>
> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
> extensible / scriptable, and fast. The default setup is nano- or
> emacs-like, but it supports modes as well. I've used it daily for 2+
> years. You can view some demos here:  http://imgur.com/a/ZBmmQ
>
> ### Aims
>
> * Keep codebase small
> * Require minimal dependencies
> * Make extensibile and configurable
> * Favor simplicity over portability
> * Use shell commands to enhance functionality (e.g., grep, tree)
> * Enjoy writing C
> * Annoy the world with another text editor
>
> ### Features
>
> * Small codebase (~10k sloc)
> * Only 1 out-of-repo dependency (pcre)
> * Full UTF-8 support
> * Syntax highlighting (via pcre)
> * Stackable key maps (modes)
> * Extensible via any program capable of stdio
> * Scriptable rc file
> * Built-in text editing language (lel)
> * Key macros
> * Multiple splittable windows
> * Regex search and replace (with capture groups)
> * Large file support (beats vim in this benchmark
> http://i.imgur.com/VGGMmGg.gif)
> * Incremental search
> * Linear undo and redo
> * Multiple cursors
> * Headless mode
> * Movement via less
> * Fuzzy file search via fzf
> * File browsing via tree
> * File grep via grep
> * Decently portable (tested on Linux, cygwin, macOS)
>
> ### Notes
>
> * There is a TODO list here[1].
> * The editor back-end, mlbuf[2], is a standalone library which can be
> repurposed.
> * mlbuf's main data structure is a linked list of C strings, similar to
> nano.
> * The built-in editing language, lel, is an experiment. I question
> whether it belongs.
> * There is a fork of mle called eon[3] which adds mouse support, Lua
> plugins, and notepad-like defaults.
>
> As always, patches and feedback are welcome.
>
> Thanks,
> Adam
>
> [0] pcre; termbox and uthash are included in-repo
> [1] https://github.com/adsr/mle/blob/1e9a467/mle.h#L637
> [2] https://github.com/adsr/mlbuf
> [3] https://github.com/tomas/eon
>
>

[dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread as 
Hello,

I am announcing mle, a small terminal-based text editor written in C:

https://github.com/adsr/mle

mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
extensible / scriptable, and fast. The default setup is nano- or
emacs-like, but it supports modes as well. I've used it daily for 2+
years. You can view some demos here:  http://imgur.com/a/ZBmmQ

### Aims

* Keep codebase small
* Require minimal dependencies
* Make extensibile and configurable
* Favor simplicity over portability
* Use shell commands to enhance functionality (e.g., grep, tree)
* Enjoy writing C
* Annoy the world with another text editor

### Features

* Small codebase (~10k sloc)
* Only 1 out-of-repo dependency (pcre)
* Full UTF-8 support
* Syntax highlighting (via pcre)
* Stackable key maps (modes)
* Extensible via any program capable of stdio
* Scriptable rc file
* Built-in text editing language (lel)
* Key macros
* Multiple splittable windows
* Regex search and replace (with capture groups)
* Large file support (beats vim in this benchmark
http://i.imgur.com/VGGMmGg.gif)
* Incremental search
* Linear undo and redo
* Multiple cursors
* Headless mode
* Movement via less
* Fuzzy file search via fzf
* File browsing via tree
* File grep via grep
* Decently portable (tested on Linux, cygwin, macOS)

### Notes

* There is a TODO list here[1].
* The editor back-end, mlbuf[2], is a standalone library which can be
repurposed.
* mlbuf's main data structure is a linked list of C strings, similar to nano.
* The built-in editing language, lel, is an experiment. I question
whether it belongs.
* There is a fork of mle called eon[3] which adds mouse support, Lua
plugins, and notepad-like defaults.

As always, patches and feedback are welcome.

Thanks,
Adam

[0] pcre; termbox and uthash are included in-repo
[1] https://github.com/adsr/mle/blob/1e9a467/mle.h#L637
[2] https://github.com/adsr/mlbuf
[3] https://github.com/tomas/eon