Re: [dev] Sandy editor

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.

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

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

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

> * 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.

> * 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.

> * Strings with escaped quotes are not correctly highlighted
> * i_die does not resets terminal configuration

I called reset_shell_mode() there. Thanks!

> * 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!

> * 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.

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

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

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

>  - 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!

> * 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.

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

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

> * 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.
Received on Thu May 26 2011 - 01:33:15 CEST