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