Re: [dev] Sandy editor

Hi,

On Thu, May 26, 2011 at 3:14 PM, pancake <pancake_AT_youterm.com> wrote:
> i have noticed that the sucky terminal cannot handle shift+control, so my
> bindings for
> ^[hjkl] ^[HJKL] does not work... So i'll think in other keybindings for it..

Yeah. If I recall, the old sandy prototype (ugly gtk+) used
Control+Shift keybindings, but they went away when I noticed terminal
emulators don't report them as such. Once you press Ctrl, the next key
you hit gives you one control char. That's it. Not sure it's a curses
thing as much as a terminal limitation.

> Another thing that i have noticed is that you can't nest keybindings. This
> is, i want to have
> a single key to save and quit, so i put the same key hook twice but first is
> saving, which popups
> a filename dialog if no filename defined and if save is success then quits,
> else just shows an
> error.
> This is probably the only case there I think this is useful, so it will be
> probably better to
> define a specific function instead of nesting keybindings.
> What do you think?

That's definitely keep the source simpler and I'm not sure we need
chain keybindings. You can define the conditions (e.g. t_mod) and get
it to do a different thing depending on whether the file has been
modified or not (somewhat close to what Ctrl-Q does right now). If in
need, you can write your own t_ function real easy.

On Thu, May 26, 2011 at 5:44 PM, pancake <pancake_AT_youterm.com> wrote:
> sourceforge sucks a lot. full of security bugs, filled with banners, bloated
> interface... i would prefer to fetch suckless code from a suckless site :)

Great then. So long sourceforge, hello suckless.

> Anselm?

He already asked my for my ssh key :)

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

I'm not even sure all embedded libc variants have a regex engine
(maybe bionic didn't when I looked at it a while back? I don't really
remember). We absolutely should get rid of a GNU dependency if
possible, compile to static, use a saner curses implementation if
there is any.

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

Maybe that's right. The thing may fail also if you search for an empty
regex tho. I should probably try to get my hands on a BSD box to try
these things. Maybe using libc's regcomp/regexec was not that
realiable after all. Any saner alternatives?

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

Well, if there is a suckless framework (gods, do I hate that word!),
be it "slcurses", or a suckless X toolkit really, to write a text-only
program, I'd be glad to find time and port sandy to that.

Writing the framework itself is probably out of my scope right now, sadly.

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

Yeah, you got me on this one. I'll drop the flag, declare isutf8 a
const and let everyone figure it out. Will push when the repo is
hosted at suckless.

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

Now that you mention it, that was the main reason for printing spaces
and tabs!!! I hate it when trailing spaces go unnoticed.

Both control chars and space/tab fill-ins are printed in their own
colour each so you can distinguish them from the characters proper. If
anybody likes this (I found it cute, but it is not really that useful)
then we could keep it and print \n too. Otherwise it goes and make our
life simpler.

Please keep in mind that right now those fill-in chars don't go to the
selection as that is handled internally via xsel. They do go there if
you select with the mouse skipping the xterm mouse interface (e.g. by
holding Shift). Not really gracious.

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

Well, the default config does not call dmenu if DISPLAY is not set,
but instead cleans the first line, prints a prompt and reads before
updating the screen. A while back I tried to create a dmenu clone for
console, but soon figured out there is no way to discern between stdin
for options and keyboard input proper, so I just left it. Did you say
you have something like that? How do you separate input? Maybe you are
right and we should have a routine to read a line from inside sandy.

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

That is indeed a great idea. I'll try to stick with the UNIX defaults,
fill in with Emacs when in doubt and remove META when possible.

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

Yeah, almost makes me want to go back to gtk+.... almost :)

Btw, how does emacs handle this? I haven't really used the
monstrosity, but I recall they do different in ^J and Ret. Or is that
in their GUI version only? Anybody using emacs kind enough to check?

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

Sure, I will drop them from the default list now and push the changes
once the repo is hosted at suckless. I just handed Anselm a tar copy
this morning and don't want any changes to be lost meanwhile.

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

Real sorry for the Meta-Shift-q. I changed (as most people? that's
what I thought at least) dwm's MODKEY to Mod4Mask a long time back.

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

Ok, we can add that later.

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

I'll take a quick look at the quote regexes now, but since I don't
really know which are working where :S I hope nothing bad comes out of
this.

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

Really useful indeed. We ought to implement this.

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

We should definitely have that chat. You seem to have great ideas and
I sincerely hope you can contribute some code :)

Best regards,
Rafa.
Received on Thu May 26 2011 - 21:53:18 CEST