Re: [dev] Sandy editor

hi,

On 05/29/11 13:00, Rafa Garcia Gallego wrote:
> Thinking about a couple of issues now:
>
> 1.- The regexes used for syntax highlight relied on a GNU extension
> (\< \> to mark word boundaries). We changed those to \b, which is the
> POSIX equivalent, but some testing has determied this does not work in
> some systems (MacOS as far as we know).
>
> We looked at alternative regex engine implementations, but they either
> suck (perl and the like) or do not implement the rather-useful \b (go,
> plan9). Maybe it's time for a suckless regex library? Maybe we should
> extend plan9's libregexp?
>
> Actually, it was pancake who researched all this, so kudos to him.
>
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.

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
> 2.- There is a (very) limited subset of keys we can bind to to comply
> with everyone's requests: there are 33 Control chars: Control +
> @A-Z[\]^_? but some are taken (^[ is ESC, ^I is TAB, ^M and/or ^J is
> Enter). Because of the way terminals work, we can't bind to
> Control+Shift... no wonder they used to call them dumb terminals.
>
> I have tried to reduce the number of bindings to use, but going below
> 30 seems impossible if we want full keyboard control. There are a few
> ways to go from here, but they mostly suck:
>
> - Screw full keyboard control, drop things like deleting/moving
> through lines, words, etc. bind the rest and end up with an
> uncomfortable editor.
> - Reduce our bindings as much as possible, then bind the least used
> actions to the function keys, hoping they do not collide with your
> software.
> - Implement a very little amount of key chains (possibly one prefix
> only) a-la emacs, again only for the least used actions.
> - Bite the bullet and bind with Meta, trying to avoid an overlap with
> other popular suckless software (read dwm, wmii).
> - Go modal, though this would probably end with us writing yet another vi clone.
> - Draw our text editor in an X window instead of a terminal/curses and
> then bind Control+Shift; this potentially sucks the most and you
> wouldn't be able to use sandy on console/ssh.
>
> NOTE: common movement keys (arrows, home/end, repag/avpag...) are also
> bound to the usual suspects; we are talking additional keybindings to
> avoid leaving the default typing position here.
>
> NOTE: in the meantime, you can use the current sandy code by tapping
> on te original sucky way to use meta in the console: press ESC, then
> the key within some millisecs. Go usability.
>
>
> Any thoughts on either topic are more than welcome,
> Rafa.
>
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.

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?

PD: Anselm, are you still alive?

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. :)

--pancake
Received on Tue May 31 2011 - 16:40:24 CEST