Re: [dev] Sandy editor

Im in the irc.oftc.net#suckless right now.

On 26/05/2011, at 21:53, Rafa Garcia Gallego <rafael.garcia.gallego_AT_gmail.com> wrote:

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

Maybe its a terminal limitation.. I think emacs this this my chaining over nine thousand control keycodes.
>
>> 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.
>

Ok. Will try that way
>
> 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 :)
>

Yay. Anselm is silent.
>
>> 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.
>

Not really :/ unless we write one or use the one in awk.
>
>> 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.
>

What about naming it Cursless? I think dvtm did some work on it.

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

Yep. Its not something to focus now.
>
>>>> * 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.
>

Why not just remove that utf const?
>
>>>> * 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.

Indent shoild fix this. In vim i use gg=G to indent the whole file, so spaces/tabs are fixed.

I tend to edit the code in a proper way. The editor shouldnt help on crappy sources. (imho) you can use sed or grep to find files with wrong spacings. And this is something should not happen many times.
>
> 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.
>

Oh , right. Didnt notice the DISPLAY check. But i will probably keep my idea of having an internal entry input inside sandy. Just for consistency and because if you dont have dmenu the functionality is just broken partially.
>
>>> 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.
>

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

Chaining control keybindings. Which is tricky. Because of the huge number of keys.
>
>> 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.
>
Waiting for this to happen :)
>
>>>> - 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.
>
Yup
>
>> 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 :)
>

Join irc or add my jid pancake at nopcode.org
>
> Best regards,
> Rafa.
>

--pancake
Received on Thu May 26 2011 - 23:22:51 CEST