Re: [dev] Sandy editor

Hi,

On Tue, May 31, 2011 at 4:40 PM, pancake <pancake_AT_youterm.com> wrote:
> After reading the libregex9 code (1200LOC, and probably the best regexp
> library out there)
> (because openbsd regex is about 3KLOC and musl 5KLOC and have some
> documented bugs,
> gnu one is about 35.000LOC...
>
> the thing is that \b is the posix implementation and \< is a gnu extension,
> but both are quite
> new, and well.. after reading the code of the p9 regexp lib i realized that
> it is completely
> unnecessary, as long as you can write a (^| |\t|;|{|\(|\{|\[)... regexp that
> matches the same.
> it's a bit annoying if you have to type it manually, but this can be done in
> a #define B as I
> told you by xmpp yesterday.
>
> Please commit the fix and we will get portable regexp support.

Thanks a lot for researching this. I have commited this to the default
config file though there is some weirdness in using the boundary chars
to delimit the match (e.g. "else if" does not get coloured properly
unless you double the space). I also added $ (i.e. eol) to the list of
delimiters.

> Another thing is that it would be great to be able to disable the syntax
> highlight:
>
> diff -r e2542c05953f sandy.c
> --- a/sandy.c   Tue May 31 01:39:32 2011 +0200
> +++ b/sandy.c   Tue May 31 16:34:39 2011 +0200
> @@ -1614,6 +1614,8 @@
>                                tabstop=atoi(argv[i]);
>                        } else
>                                i_usage();
> +               } else if(!strcmp(argv[i], "-S")) {
> +                       local_syn="";
>                } else if(!strcmp(argv[i], "-s")) {
>                        if(++i < argc) {
>                                local_syn=argv[i];
>
> add this patch to have -S to not use any syntax highlight

You could already do this with -s none (or -s hjklhjkl really), but I
agree -S seems cleaner. Thanks again and commited.

> i'm preparing a control-only based keyboard layout for sandy.. i'll have a
> look
> at your version, but I still think that modes will allow us to keep some
> sane
> control commands and be more productive for moving without
> meta/control/shift
> keys on the command mode.

Yeah, me too. As agreed, mine will follow more or less the emacs
defaults. It was difficult to remove many keybindings and adding a
condition was maybe a hacky solution. I have commited my attempt as
config.control_only.h Please feel free to try and provide feedback.
Some differences from the emacs default or the default config:
- ^U works as it should.
- ^C kills the next word (former META-D). Sorry, I seem to use this one a lot.
- ^K, ^W, ^H and ^D complete your killing family as usual. I don't
know how much you guys use these.
- ^A / ^E go to bol / eol or, if already there, move by one full page.
I find this weirdly comfortable.
- ^S / ^R as for a search term or, if there is any selection (e.g.
right a search match), search for the next occurrence of the previous
search.
- ^@ sets (the one) mark
- ^O goes to the other side of the selection, or to the mark if there
is no selection.
- ^T prompts you for a line to go to.
- ^[ (also Esc) prompts you for syntax, but it may as well be a
command line writing directly to the pipe. It has a slight lag while
attempting to read a META sequence. NCurses fault, not mine. Will try
to solve.
- ^X saves or quits, ^Q quits without asking (!!), ^] extends the
selection as the former ^X.
- Sadly, there is no easy way to move word-by-word: Shift+Left/Right
is the current only binding. You can still kill words left and right
with ^W/^C.
- Sadly, there is no immediate way to copy to the clipboard: it is
either cut and paste (e.g. ^W^Y) or move your hand and press INS.

I do not intend to keep two default config files in the repo except
for tests and such, so try and report any weirdness and we can make
this the default; unless we like pancake's version more, of course. We
can have a wiki page, a separate repo or something for alternative
configurations.

> Vi is great, and it's great for something, the only bad thing is that most
> implementations
> are bloated.. but with the codebase of sandy we can do an almost decent vi
> clone.
>
> Most basic editor functionality in sandy will be possible without changing
> between
> modes, but having the possibility to use the commands mode will provide a
> more
> decent interface. (IMHO).
>
> Anybody more wanna give your opinion?

As I already said, I have mixed feelings about modality. In case we go
modal, we'd probably use something akin to vi's command mode bindings
I guess. Let's hear some opinions before acting.

A tad unrelated, but not really... I was quite sure about using
keyboard positioned bindings before (be them hjkl, ijkl, the wordstar
thingy or even wasd as it has been suggested). However, a lot of
suckless software users seem to have a non-qwerty keyboard layout.

> PD: Anselm, are you still alive?

He reached to me this morning, ought to have the repo in place tonight.

> PD: it's an already known bug, but multiline comments are not properly
> highlighted, this is
> because of performance reasons.. syntax highlight is nice.. but it's
> probably overbloating
> the execution. Dunno if we should drop them.. at least now they work
> everywhere. :)

I'm a sucker for pretty colors, but I understand not everyone likes
them that much. I'll add a few #ifs to make them optional later today
or tomorrow. Incidentally, it is now very easy to remove current line
highlighting and the weird chars painted in place of ' ' and '\t' by
editing config.h. Thanks to pancake again.

Best regards,
Rafa.
Received on Tue May 31 2011 - 18:51:11 CEST