Re: [dev] Sandy editor

On 05/26/11 01:33, Rafa Garcia Gallego wrote:
> Hi,
>
> Thanks a lot for your detailed mail.
>
> On Thu, May 26, 2011 at 12:33 AM, pancake<pancake_AT_youterm.com> wrote:
>> About moving sandy to hg.suckless.orgshould be discussed with Anselm. We can
>> setup a cron sync to clone your repo.. But it would be better to have it
>> there.
> I'm fine with moving the main repo to suckless.org. I'm not specially
> attached to sourceforge.
sourceforge sucks a lot. full of security bugs, filled with banners,
bloated interface... i would prefer to fetch suckless code from a
suckless site :)
>> I think this editor fits very well in the suckless philosophy and project.
>> Maybe other projects like star should then also move.. So this requires some
>> discussion in other trhread.
> I'm glad you think that :-D.
>
Anselm?
>> BUGS:
>> ====
>> bug1) In BSDs regcomp(3) if you pass "" as first argument, you get a
>> segfault.
> I didn't really have a BSD at hand to test it. I have tried applying
> your patch about this, but it seems to make sandy segfault in my linux
> if I open a .c file. It's late, I'll try again tomorrow.
>
>
yep, my patch is not right at all.. i have noticed that there are other
regexpes that does not compile well without a GNU libc.. what about
musl? sandy runs fine if you just remove the i_die() when regcomp() fails.

In fact, i dont think an editor should not allow you to edit a file
because a highlight regexp does not compiles :) I would make this
silently fail. And prepare a bunch of regexp test suite to ensure
everything works in all available libc's.
>> bug2) Segfault I commented in the previous mail
>>
>> I was able to reproduce the segfault:
>>
>> - write some text
>> - press ^x
>> - move cursor to select some text
>> - press 'y'
>> - got segflute in sandy.c:636
> Applied, thanks!
>
>
>> NOTES
>> =====
>> * ncurses sucks. but it's the only portable solution atm. at some point we
>> can
>> write a suckless curses library, removing all the old stuff and make it
>> cleaner.
>> - So.. minor changes would be required to make your editor run without
>> ncurses.
> That'd really be great. I tried to get it working against pdcurses,
> but then I couldn't select() stdin and the command pipe at the same
> time. I looked for a fd to select() for input and got tired of
> pdcurses soon :)
>
>
yep.. i saw some comments talking about nonblocking stdin problems.. so
this should be rethinked/bugfixed.

In r2 i wrote libr_cons, a library for working on text mode on *nix and
w32 terminals without depending on curses. We can get code from there to
build our
curses-like-suckless-library.
>> * Remove utf8 enable/disable option. or make it compile-time option-only (-u
>> flag)
>> - I think nowadays all our apps should be utf8 ready
> Will do. You wouldn't belive how old can a Solaris installation get around, tho.
>
>
uhm, do we mind about crappy systems? I still think that sandy will work
fine on a non-UTF8 terminal editing non-UTF8 text if you remove the
display of hidden chars (tab, space)

>> * Non-printable characters are printed (i know this is in config.h)
>> - I prefer not to see what it's not going to be seen
>> - What do you guys like? do you
>> - If you print those chars, I suggest you to also display \r and \n chars
>> - Imho it's smarter if you just see the text
> mmmmh. Do you mean printing non-printing characters like ^A? Or are
> you talking about the funny little dots and arrows that appear in
> place of spaces and tabs? I'm unsure about those.
im talking about the space+tab funny chars. those are utf8 and they
would break on a non-utf8 console.. and just makes the code a little
more complicated, without any aparent benefit (at least for me, i never
display invisible chars in my coding sessions..)

btw, put this in config.h to remove those chars.

static const char tabstr[3] = { ' ', 0 };
static const char spcstr[3] = { ' ', 0 };

but I would like to discuss with the rest of ppl in the ml to know if
somebody find useful to view those chars. Else i would prefer to get rid
of them.

BTW; if you print those special chars, also print newline, as long as
sometimes is useful to know if any line is longer than expected.

but IMHO i would prefer to drop it.
>> * Strings with escaped quotes are not correctly highlighted
>> * i_die does not resets terminal configuration
> I called reset_shell_mode() there. Thanks!
>
good. much better now :)
>> * Linking fails in OSX because missing ncursesw name
>> - there's a ncurses5-config that works like pkg-config and this
>> should be used to make this portable
>> - Or just drop the 'w' in the ncursesw5 libname (-lncurses works fine)
> Just dropped the 'w' for simplicity's sake. Thanks!
>
>
thanks
>> * I would prefer not to depend on dmenu/xsel
>> - The terminal is usually implementing this copypasta into the Xselection
>> buffer
>> - On OSX/WayLand/W32 takes no sense to use this
>> - I have an implementation of dmenu in text mode (ANSI, without curses)
>> - about xsel... i would prefer to be able to use copypasta, without
>> depending on X11
>> - write 'csel' which stores the buffer in a file at home and uses xsel if
>> possible.
>> - the text input can be done in ncurses inside the editor, adding a text
>> input
>> entry at the bottom of the screen (or on top?), so dmenu is not a
>> dependency.
>> - Do you think it's important to have the possibility to use an external
>> program
>> to get text? in a text editor, which it's primary use is for entering
>> text?
> You are probably right about this. I just figured there are too many
> ways to simply read a line of text from the keyboard, and dmenu is the
> one I like the most. Of course you can configure this in config.h, but
> maybe dmenu and xsel should not be in the default config file.
>
>
yeah, dmenu is great, but I dont think it should be the default method for a
console text editor.. because it's aimed to run in a terminal, not
necesarily in X11.

suckless programs that use dmenu are somewhat linked to X11 (dwm, surf, ..)
>> - Another option would be to copy this buffer inside the editor which is
>> simpler
>> than using files or running programs, but letting the user to put in
>> config.h
>> a keybinding to pass the selection to a external program for stdin.
>>
>> * I don't think support for modes is that important, and in fact, it makes
>> the editor suck
>> more, as long as you will never use the command mode for batch mode, and
>> duplicates the
>> input for doing the same thing in different ways. So imho it's more
>> suckless if there are
>> no modes. But emacs keybindings are a bit insame imho, we can think in a
>> mix of the vim
>> and emacs (see above)
>>
>>
>> * I tend to prefer a mode editor, because there are less keybindings in each
>> mode
>> and im am addicted to vim. These are the changes I propose for the
>> keybindings. Let
>> me know your feelings.
> I too have mixed feelings about this. On one hand modeless editing
> seems saner and we shouldn't really need that many commands. On the
> other hand, vi-like modal editing feels so powerful it is almost a
> pity to abandon.
>
> Right now there is just a bit of modality: it is different to move
> around while selecting text or not. I did not like it, but
> Ctrl+Shift+X bindings seemed cumbersome for text selection.
>
> Maybe somebody else can weigh-in and contribute an opinion.
>
>
I think that we should review first all the keybindings, remove the
non-essential
ones and modify the ones that looks weird to end up in proper default ones.

In DWM we discussed this topic for years until we got the current default
keybindings. This is just a matter of usability and this requires people
to test
the program and give feedback.

I'm preparing a config.h with some changes in the keybindings.. prepare
yours
and get ready for the keybindings war! muahah.

btw, i think that the editor should only handle Control key. Because
META is usually handled by GTK/dwm/gnome-terminal, ... and this can
cause issues like killing dwm when closing the editor.

>> - Maybe an Emacs guy would be happy with those keybindings. But i think
>> these ones
>> will be saner (without modes):
>> - ^[hjkl] - move around
>> - ^[HJKL] - move around selecting text
>> - ^[fb] - go next/prev page
>> - ^[np] - go next/prev page
>> - ^k - find manpage on word under cursor
>> - ^w - save
>> - ^W - save as
>> - ^q - quit
>> - ^Z - save+quit (it's similar to vim's ZZ)
>> - ^! - prompt to run program on selected/full text (indent, etc..)
>> - ^z - must not be handled, because it's used by the shell for
>> backgrounding apps
> Those seem fine for now. There should be something to move around
> word-by-word (and also reminder to self: I have to reimplement
> word-by-word movement).
>
>
as i said in my previous mails ^HJKL is not possible, so we should think
in a non-hjkl form because ^J is also handled as \n, so you can't make
^J just move the cursor down. :/// stupid terminals.
>> - Whats the point of having aliases for newline for example? ^j, ^M, ..
> Oh! That was a door open to autoindenting. For now ^J and ^M alias to
> newline but in the future they may call a function that does
> autoindenting if needed. It should work without them.
>
I would like to have the minimum possible keybindings configured by default.
Maybe we can meet in irc to discuss it, mailing list discussion for this can
take too much time.
>> - meta shift q: is something that some ppl use in dwm to quit. It can be
>> dangerous :) i think is better to only handle control and shift. At least
>> for default keybindings
>> * Use -ggdb instead of -g, in OSX you have to specify the dwarf format to
>> make gdb work with it.
>> - I dont think -g should be in default makefile, it's useful for now, but
>> must be
>> removed when release.
> Done in the default config.mk. Thanks!
>
>
thanks again :P
>> * support for ascii art mode (do not limit cursor to end of text line
>> - add support for inline copy and paste (select rectangle of text, and
>> paste respecting
>> the horitzontal position and replacing text. (like ^v in vim)
> I'd think about it. A patch would help of course.
>
>
that's not really prioritary, and it will probably be sucky, so forget
about it :)
>> Other features
>> ============
>> * show number line at the begining of line
>> * BUG: i_die() does not closes ncurses
>> * BUG: escaped quotes are not detected by syntax highlight
>> printf ("hello \"world\""); -> stop highlight at first '"'
>> * FEATURE: add support for marks (like ma/'a in vim)
>> * Match brackets and go opening/closing bracket
>> * Find next/prev apparition of word under cursor
> I'll look at the rest tomorrow. The escaped quotes should work by
> refining the regex. There is a single mark now and it is automatically
> set when you search for stuff and all, but maybe we should add support
> for named marks. The matching brackets are on the TODO list already [
> :-) ]. As for searching for stuff under the cursor, you can select the
> word (e.g. via Ctrl-x once it works better) and then Meta-S or Meta-R
> to search for the current selection.
Today is the new tomorrow.

In VIM i use a lot the '%' key to move between matching parenthesis,
brackets,...

About select+search,... i would like to review this stuff when we get a
non-dmenu
input and proper keybindings, so first things first :)

>> Btw.. i loved this macro:
>>
>> #define UTF8LEN(ch) ((unsigned char)ch>=0xFC ? 6 : \
>> ((unsigned char)ch>=0xF8 ? 5 : \
>> ((unsigned char)ch>=0xF0 ? 4 : \
>> ((unsigned char)ch>=0xE0 ? 3 : \
>> ((unsigned char)ch>=0xC0 ? 2 : 1)))))
> I looked at wchar with the best light... I promise.... but I simply couldn't.
>
>
wchar is pure oldie shit.
>> * I'm sorry about your ferret
> Gee, thanks! It's funny how sometimes we feel down over the smallest
> thing while being impervious to others. I should probably remove that
> bit from the page.
>
It's ok for me to leave this here.. it's an historical reason :)

--pancake
Received on Thu May 26 2011 - 17:44:17 CEST