Re: [dev] Sandy editor
On 5 June 2011 02:34, Rafa Garcia Gallego wrote: > Well, those are the ASCII characters you have to produce. My keyboard > (fairly standard setxkbmap us altgr-intl -option ctrl:nocaps), > produces them as follows: > C-_ with Ctrl-/ and Ctrl-7 > C-^ with Ctrl-6 > > If this were standard (though I'm afraid it won't be) we'd definitely > have to change the manpage to reflect it. I've tried it again and the bindings seem to work, at least, though they're a little unpleasant. On my keyboard (UK Qwerty) the keys are: C-_ with Ctrl-/ and Ctrl-_ (Ctrl-Shift-Dash) C-^ with Ctrl-6 I understand we're a little short bindings, thanks to curses, so I'm unsure what to suggest. But as Ctrl-/ works it's better than I thought; Ctrl-_ is an awful chord. I also committed a patch which stops certain extra GCC warnings, mostly from signed / unsigned comparisons, and replaced kill with abort so we don't need -D_POSIX_SOURCE. Thanks, cls
Re: [dev] Sandy editor
Hi, On Sat, Jun 4, 2011 at 9:48 PM, Connor Lane Smith wrote: > Some things I've noticed: > 1. Vertical movement doesn't take tabs into account for horizontal offset. Yeah, that's the first item in my TODO list, yet I keep postponing it even though it seems simple enogh. It also includes moving by screen-lines rather than file-lines: when you have a very long line, moving around it is so painful I sometimes even reach for the mouse. > 2. The manpage seems incomplete -- it doesn't mention undo, for instance. Will add, I see you have reformatted the page a couple of times. Thanks for that. I don't really speak troff either, so I dont know what is kosher. > 3. The config.h undo/redo bindings seem really obscure, at least on > my keyboard, and I couldn't actually get redo to work. > (C-_ = Ctrl-Shift-Dash? C-^ = Ctrl-Shift-6?) Well, those are the ASCII characters you have to produce. My keyboard (fairly standard setxkbmap us altgr-intl -option ctrl:nocaps), produces them as follows: C-_ with Ctrl-/ and Ctrl-7 C-^ with Ctrl-6 If this were standard (though I'm afraid it won't be) we'd definitely have to change the manpage to reflect it. Thanks a lot for your input. And don't be shy about commiting changes to the code :) Other than that, I've recently pushed a way to repeat the last insertion (or pipe) to tip. It took some SLOC, but it is quite cool and binds to C-^ if there is nothing to redo. This lets you for instance to have a pretty simple, modeless interactive search-and-replace (or even search-and-pipe, which I seem to like more) functionality: just search for some term with a regex, type the replacement in (or pipe to obtain it), then search next and repeat the insert or pipe. Heck, I we weren't so short of keybindings in the default config, I'd even consider binding "repeat and find next" to a single key. Cheers, Rafa.
Re: [dev] Sandy editor
Hey, Some things I've noticed: 1. Vertical movement doesn't take tabs into account for horizontal offset. 2. The manpage seems incomplete -- it doesn't mention undo, for instance. 3. The config.h undo/redo bindings seem really obscure, at least on my keyboard, and I couldn't actually get redo to work. (C-_ = Ctrl-Shift-Dash? C-^ = Ctrl-Shift-6?) Thanks, cls
Re: [dev] Sandy editor
On Thu, Jun 2, 2011 at 6:49 AM, Rafa Garcia Gallego wrote: > Answering direct questions: accepting a number modifier to commands > seems cool and simple enough and I do use it a lot in vim. I was > trying to avoid it for simplicity's sake, but if you lot feel it is > necessary, then we can go ahead and add it. Let me know what you > think. How would you add a number modifier in the Ctrl-only bind system? Chain it with Ctrl (Ctrl-1 Ctrl-2 to mean 12), or a new bind (also a chain) for selecting numbers (Ctrl-X 12 to mean 12)? I think regex-selection should be good enough to replace this feature. --Andrew Hills
Re: [dev] Sandy editor
On 6/2/11, Rafa Garcia Gallego wrote: > - Most "normal" editors *do* have a slight modality (e.g. replace > instead of insert, etc). Sandy does have a different behavior when > selecting text vs. when moving, but it is bearable and IMHO it does no > lead to confussion. Some questions: do we want to avoid modes as much > as possible? even if that means losing some "power-user" > functionality? I suppose the answers to those questions depend on what the goal of this project is. If the goal truly is a simple editor, then -- according to my definition of simple, anyways -- it ought to be modeless. And if that means sacrificing some power-user functionality then that's fine. It can't necessarily do _everything_. And if it does, then.. it would probably end up being just another bad clone of vi or Emacs. > - Vi OTOH *does* have keybinding chains / compound commands (try > typing a simple text in English, then do "d2Fe" in command mode and > think what went on there), though I think we can all agree their > damage is lesser than in emacs. Some more questions: do we want to > avoid prefixes and modifiers as much as possible? even if this means > having to repeat a keybinding a couple of times? > > If the answer to all these questions is 'yes', then we will probably > end up with a quite simple, suckless editor. As long as it lets me > select text using a regex and then filter the selection trough an > arbitrary command, it ought to be enough for me. At least in theory. I'm all for simple. John
Re: [dev] Sandy editor
Hi,
I've pushed a couple of changes: the control-only keymap is now the
default (the former one is there as config.old.h, but should be
removed soon unless someone reports using and preferring it), Ctrl-Q
warns before quitting, Ctrl-t copies and the prompt commands are a bit
more vi-like now ('/' and '?' search, '|' pipes, 'w' saves) for
convenience and speed since some actions as changing syntax or saving
with a different filename, etc., did not find their own keybinding.
Please test and comment.
Back to the modal/non-modal conundrum:
- Most "normal" editors *do* have a slight modality (e.g. replace
instead of insert, etc). Sandy does have a different behavior when
selecting text vs. when moving, but it is bearable and IMHO it does no
lead to confussion. Some questions: do we want to avoid modes as much
as possible? even if that means losing some "power-user"
functionality?
- Vi OTOH *does* have keybinding chains / compound commands (try
typing a simple text in English, then do "d2Fe" in command mode and
think what went on there), though I think we can all agree their
damage is lesser than in emacs. Some more questions: do we want to
avoid prefixes and modifiers as much as possible? even if this means
having to repeat a keybinding a couple of times?
If the answer to all these questions is 'yes', then we will probably
end up with a quite simple, suckless editor. As long as it lets me
select text using a regex and then filter the selection trough an
arbitrary command, it ought to be enough for me. At least in theory.
Answering direct questions: accepting a number modifier to commands
seems cool and simple enough and I do use it a lot in vim. I was
trying to avoid it for simplicity's sake, but if you lot feel it is
necessary, then we can go ahead and add it. Let me know what you
think.
BR,
Rafa.
Re: [dev] Sandy editor
i think this is what most people is missing http://vim.wikia.com/wiki/Avoid_the_escape_key http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_XWindows i was not sure what was my favorite(vim/emacs) until i read this now with TAB+x+y+z look asowme compared with C-x+C-y+C-z -- Guilherme Lino On Wed, Jun 1, 2011 at 1:24 PM, Marc Andre Tanner wrote: > On Wed, Jun 01, 2011 at 11:46:54AM +0200, pancake wrote: > > But i'm pretty sure it will be more comfortable to move along the code > > with hjkl (modes) than ^n^p... but le'ts first try to make it smarter. > > For what it's worth I also think multiple modes make sense. Moving > around with hjkl is too familiar and comfortable for me to live without. > Also having the ability to specify a multiplier for commands (think 3y > to yank 3 lines in vi) comes in handy. > > Just my 2 centimes. > > -- > Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 > >
Re: [dev] Sandy editor
On Wed, Jun 01, 2011 at 11:46:54AM +0200, pancake wrote: > But i'm pretty sure it will be more comfortable to move along the code > with hjkl (modes) than ^n^p... but le'ts first try to make it smarter. For what it's worth I also think multiple modes make sense. Moving around with hjkl is too familiar and comfortable for me to live without. Also having the ability to specify a multiplier for commands (think 3y to yank 3 lines in vi) comes in handy. Just my 2 centimes. -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] Sandy editor
On 06/01/11 10:22, John Matthewman wrote: On 6/1/11, pancake wrote: and this is why im telling why modal editor is necessary if we dont want to fall into a emacs-like hell. I wouldn't go so far as to say that it's necessary -- or that not going modal will result in falling into an Emacs-like hell. Isn't the goal a simple, little editor? We just have to work within the limitations that we have (the number of keys that actions can be bound to). I'm sure all of the most important things can be covered in the default binding configuration. And users will have the option to add their own bindings -- even bindings using the Meta key if they want -- or change the default bindings to suit their tastes. John yep, that's the plan. first try to live without it. and when we get the proper control-based keybindings we can evaluate if modal matters or not. But i'm pretty sure it will be more comfortable to move along the code with hjkl (modes) than ^n^p... but le'ts first try to make it smarter. --pancake
Re: [dev] Sandy editor
On 6/1/11, pancake wrote: > and this is why im telling why modal editor is necessary if we dont want > to fall into a emacs-like hell. I wouldn't go so far as to say that it's necessary -- or that not going modal will result in falling into an Emacs-like hell. Isn't the goal a simple, little editor? We just have to work within the limitations that we have (the number of keys that actions can be bound to). I'm sure all of the most important things can be covered in the default binding configuration. And users will have the option to add their own bindings -- even bindings using the Meta key if they want -- or change the default bindings to suit their tastes. John
Re: [dev] Sandy editor
On 05/31/11 20:43, Andrew Hills wrote: On Tue, May 31, 2011 at 12:51 PM, Rafa Garcia Gallego wrote: - ^A / ^E go to bol / eol or, if already there, move by one full page. I find this weirdly comfortable. Is a page some standard size or is it determined by the size of the terminal? --Andrew Hills emacs uses ^L to mark end of pages. i always find it sucky. i think that a page should be a screen.
Re: [dev] Sandy editor
maybe I was not clear enought when I said that ^j = return and ^h = backspace. this is something done by the terminal, so you CANT bind them. and there are other control-keys that cannot be handled like control+shift. this is why vi was done in this way. to work in all terminals without problems. and this is why im telling why modal editor is necessary if we dont want to fall into a emacs-like hell. On 05/31/11 16:48, Bryan Bennett wrote: (Consider this my thoughts on a general text editor and not a review of Sandy - I've not tried Sandy since I found it on the Arch forums a ways back - long before being brought up here) I've recently thought a lot about editors, as I'm not satisfied with vi/vim and emacs chains are shitty beyond belief. I honestly think a modeless editor (in the vein of a 'windows editor') but with sane home-row keybindings would be the best of both worlds - the efficiency of vi's hand placement paired with an ability to just edit text that I feel vi (and ilk) lack. Some very important commands (undo, cut, copy, paste, Save, Quit, Close) would not need to move much from the Windows world, but we'd need to come up with bindings for movement. I'd like ^j/^k/^l/^; for linewise movement and another modifier for pagewise movement - possibly ctrl +alt? but since ^j is return, we may not be able to do so without trouble. (we'd also need to devise some system for "go to end of line" and "Beginning of line") Honestly, I dislike 'modal text editors' as I feel they make the task at hand more difficult that it was to begin with. Sure there's a lot to be said for the power they bring, but with some forethought and planning I think that most of the power and all of the 'usefulness' of a modal editor to a modeless one.
Re: [dev] Sandy editor
Hi,
On Tue, May 31, 2011 at 10:56 PM, Connor Lane Smith wrote:
> I've just got around to properly trying sandy. I'm not a fan of the
> curses approach, but I'm otherwise quite impressed. (I've not read the
> code yet, but the editor itself has a nice feel to it.)
Yeah. Ncurses is really the lesser evil. Thanks for your support!
> On 31 May 2011 17:51, Rafa Garcia Gallego
> wrote:
>> - ^U works as it should.
>> - ^C kills the next word (former META-D). Sorry, I seem to use this one a
>> lot.
>> - ^K, ^W, ^H and ^D complete your killing family as usual. I don't
>> know how much you guys use these.
>
> I use C-u, C-k and C-w constantly. I've also found myself longing for C-c.
Those are pretty standard and IMO should remain there if possible.
>> - ^X saves or quits, ^Q quits without asking (!!)
>
> imo C-q should say "unsaved changes!" and a second C-q should quit
> regardless, ed-style. This way, C-q C-q can be a quick-quit.
Sure, we'll get there.
>> - Sadly, there is no easy way to move word-by-word
>
> Can curses handle C-Left and C-Right?
Not per-se. Urxvt reports the up arrow wit no mod, shift, control as
^[[A , ^[[a and ^[Oa respectively, but Ncurses only collects KEY_LEFT
and KEY_SLEFT.
I now see that xterm reports the modifiers in a different way and st
does not report control at all, which is probably healthy if there is
no standard way of doing so.
>> - Sadly, there is no immediate way to copy to the clipboard: it is
>> either cut and paste (e.g. ^W^Y) or move your hand and press INS.
>
> Could 'go-to-line' be rebound to C-: or so, and C-t be 'copy'?
> Rationale: sam's copy command is 't'.
Again, the problem is C-: does not really report anything but ':'.
I'll try to find an alternative, but I had not thought of ^T for copy.
>> As I already said, I have mixed feelings about modality. In case we go
>> modal, we'd probably use something akin to vi's command mode bindings
>> I guess. Let's hear some opinions before acting.
>
> Don't Mode Me In.
>
> Seriously, if you want Vi, use Vi. (I do, but hope to change that.)
Yeah, actually that's pretty much why I started sandy.
>> He reached to me this morning, ought to have the repo in place tonight.
>
> Yep, it's there. What's your opinion on commits, btw? Are you happy
> with others committing, or do you want us to talk to you instead?
I'm happy with others commiting reasonable stuff as long as it does
not clutter the source much, etc, etc
> Related: you need the CPPFLAGS -D_BSD_SOURCE and -D_POSIX_SOURCE, for
> {set,get}env and kill, respectively.
Added that, thanks!
By the way, the mercurial repo for sandy is now at
http://hg.suckless.org/sandy/ , go clone it, play with it, commit
interesting changes!
Regards,
Rafa.
Re: [dev] Sandy editor
Hey,
I've just got around to properly trying sandy. I'm not a fan of the
curses approach, but I'm otherwise quite impressed. (I've not read the
code yet, but the editor itself has a nice feel to it.)
On 31 May 2011 17:51, Rafa Garcia Gallego
wrote:
> - ^U works as it should.
> - ^C kills the next word (former META-D). Sorry, I seem to use this one a lot.
> - ^K, ^W, ^H and ^D complete your killing family as usual. I don't
> know how much you guys use these.
I use C-u, C-k and C-w constantly. I've also found myself longing for C-c.
> - ^X saves or quits, ^Q quits without asking (!!)
imo C-q should say "unsaved changes!" and a second C-q should quit
regardless, ed-style. This way, C-q C-q can be a quick-quit.
> - Sadly, there is no easy way to move word-by-word
Can curses handle C-Left and C-Right?
> - Sadly, there is no immediate way to copy to the clipboard: it is
> either cut and paste (e.g. ^W^Y) or move your hand and press INS.
Could 'go-to-line' be rebound to C-: or so, and C-t be 'copy'?
Rationale: sam's copy command is 't'.
> As I already said, I have mixed feelings about modality. In case we go
> modal, we'd probably use something akin to vi's command mode bindings
> I guess. Let's hear some opinions before acting.
Don't Mode Me In.
Seriously, if you want Vi, use Vi. (I do, but hope to change that.)
> He reached to me this morning, ought to have the repo in place tonight.
Yep, it's there. What's your opinion on commits, btw? Are you happy
with others committing, or do you want us to talk to you instead?
Related: you need the CPPFLAGS -D_BSD_SOURCE and -D_POSIX_SOURCE, for
{set,get}env and kill, respectively.
Thanks,
cls
Re: [dev] Sandy editor
Hi, Thanks for your input. On Tue, May 31, 2011 at 8:07 PM, Bjartur Thorlacius wrote: > On 5/31/11, Rafa Garcia Gallego wrote: >> A tad unrelated, but not really... I was quite sure about using >> keyboard positioned bindings before (be them hjkl, ijkl, the wordstar >> thingy or even wasd as it has been suggested). However, a lot of >> suckless software users seem to have a non-qwerty keyboard layout. > Then bind to button three on row three, and second to fourth button on > row four. What characters they represent in insert mode (or when the > control modifier is not down) is irrelevant. That's got to be hard enough, considering the terminal just provides characters on the standard input. We can have a reverse lookup table for each keymap, but that definitely would suck hard. On Tue, May 31, 2011 at 8:43 PM, Andrew Hills wrote: > On Tue, May 31, 2011 at 12:51 PM, Rafa Garcia Gallego > wrote: >> - ^A / ^E go to bol / eol or, if already there, move by one full page. >> I find this weirdly comfortable. > > Is a page some standard size or is it determined by the size of the terminal? So far it is the size of the text window, i.e. the terminal unless there is no status line and the status has to be printed to the window too. Would you guys be more comfortable with less (e.g. one or two lines less) than the full window size? Best regards, Rafa.
Re: [dev] Sandy editor
On Tue, May 31, 2011 at 12:51 PM, Rafa Garcia Gallego wrote: > - ^A / ^E go to bol / eol or, if already there, move by one full page. > I find this weirdly comfortable. Is a page some standard size or is it determined by the size of the terminal? --Andrew Hills
Re: [dev] Sandy editor
On 5/31/11, Rafa Garcia Gallego wrote: > A tad unrelated, but not really... I was quite sure about using > keyboard positioned bindings before (be them hjkl, ijkl, the wordstar > thingy or even wasd as it has been suggested). However, a lot of > suckless software users seem to have a non-qwerty keyboard layout. Then bind to button three on row three, and second to fourth button on row four. What characters they represent in insert mode (or when the control modifier is not down) is irrelevant.
Re: [dev] Sandy editor
On 31 May 2011 15:40, pancake wrote: > PD: Anselm, are you still alive? Yes, June is approaching and my agenda will start very soon :) Cheers, Anselm
Re: [dev] Sandy editor
Hi,
On Tue, May 31, 2011 at 4:40 PM, pancake wrote:
> After reading the libregex9 code (1200LOC, and probably the best regexp
> library out there)
> (because openbsd regex is about 3KLOC and musl 5KLOC and have some
> documented bugs,
> gnu one is about 35.000LOC...
>
> the thing is that \b is the posix implementation and \< is a gnu extension,
> but both are quite
> new, and well.. after reading the code of the p9 regexp lib i realized that
> it is completely
> unnecessary, as long as you can write a (^| |\t|;|{|\(|\{|\[)... regexp that
> matches the same.
> it's a bit annoying if you have to type it manually, but this can be done in
> a #define B as I
> told you by xmpp yesterday.
>
> Please commit the fix and we will get portable regexp support.
Thanks a lot for researching this. I have commited this to the default
config file though there is some weirdness in using the boundary chars
to delimit the match (e.g. "else if" does not get coloured properly
unless you double the space). I also added $ (i.e. eol) to the list of
delimiters.
> Another thing is that it would be great to be able to disable the syntax
> highlight:
>
> diff -r e2542c05953f sandy.c
> --- a/sandy.c Tue May 31 01:39:32 2011 +0200
> +++ b/sandy.c Tue May 31 16:34:39 2011 +0200
> @@ -1614,6 +1614,8 @@
> tabstop=atoi(argv[i]);
> } else
> i_usage();
> + } else if(!strcmp(argv[i], "-S")) {
> + local_syn="";
> } else if(!strcmp(argv[i], "-s")) {
> if(++i < argc) {
> local_syn=argv[i];
>
> add this patch to have -S to not use any syntax highlight
You could already do this with -s none (or -s hjklhjkl really), but I
agree -S seems cleaner. Thanks again and commited.
> i'm preparing a control-only based keyboard layout for sandy.. i'll have a
> look
> at your version, but I still think that modes will allow us to keep some
> sane
> control commands and be more productive for moving without
> meta/control/shift
> keys on the command mode.
Yeah, me too. As agreed, mine will follow more or less the emacs
defaults. It was difficult to remove many keybindings and adding a
condition was maybe a hacky solution. I have commited my attempt as
config.control_only.h Please feel free to try and provide feedback.
Some differences from the emacs default or the default config:
- ^U works as it should.
- ^C kills the next word (former META-D). Sorry, I seem to use this one a lot.
- ^K, ^W, ^H and ^D complete your killing family as usual. I don't
know how much you guys use these.
- ^A / ^E go to bol / eol or, if already there, move by one full page.
I find this weirdly comfortable.
- ^S / ^R as for a search term or, if there is any selection (e.g.
right a search match), search for the next occurrence of the previous
search.
- ^@ sets (the one) mark
- ^O goes to the other side of the selection, or to the mark if there
is no selection.
- ^T prompts you for a line to go to.
- ^[ (also Esc) prompts you for syntax, but it may as well be a
command line writing directly to the pipe. It has a slight lag while
attempting to read a META sequence. NCurses fault, not mine. Will try
to solve.
- ^X saves or quits, ^Q quits without asking (!!), ^] extends the
selection as the former ^X.
- Sadly, there is no easy way to move word-by-word: Shift+Left/Right
is the current only binding. You can still kill words left and right
with ^W/^C.
- Sadly, there is no immediate way to copy to the clipboard: it is
either cut and paste (e.g. ^W^Y) or move your hand and press INS.
I do not intend to keep two default config files in the repo except
for tests and such, so try and report any weirdness and we can make
this the default; unless we like pancake's version more, of course. We
can have a wiki page, a separate repo or something for alternative
configurations.
> Vi is great, and it's great for something, the only bad thing is that most
> implementations
> are bloated.. but with the codebase of sandy we can do an almost decent vi
> clone.
>
> Most basic editor functionality in sandy will be possible without changing
> between
> modes, but having the possibility to use the commands mode will provide a
> more
> decent interface. (IMHO).
>
> Anybody more wanna give your opinion?
As I already said, I have mixed feelings about modality. In case we go
modal, we'd probably use something akin to vi's command mode bindings
I guess. Let's hear some opinions before acting.
A tad unrelated, but not really... I was quite sure about using
keyboard positioned bindings before (be them hjkl, ijkl, the wordstar
thingy or even wasd as it has been suggested). However, a lot of
suckless software users seem to have a non-qwerty keyboard layout.
> PD: Anselm, are you still alive?
He reached to me this morning, ought to have the repo in place tonight.
> PD: it's an already known bug, but multiline comm
Re: [dev] Sandy editor
> Honestly, I dislike 'modal text editors' as I feel they make the task at > hand more difficult that it was to begin with. Sure there's a lot to be > said for the power they bring, but with some forethought and planning > I think that most of the power and all of the 'usefulness' of a modal > editor to a modeless one. you're reinventing emacs badly
Re: [dev] Sandy editor
(Consider this my thoughts on a general text editor and not a review of Sandy - I've not tried Sandy since I found it on the Arch forums a ways back - long before being brought up here) I've recently thought a lot about editors, as I'm not satisfied with vi/vim and emacs chains are shitty beyond belief. I honestly think a modeless editor (in the vein of a 'windows editor') but with sane home-row keybindings would be the best of both worlds - the efficiency of vi's hand placement paired with an ability to just edit text that I feel vi (and ilk) lack. Some very important commands (undo, cut, copy, paste, Save, Quit, Close) would not need to move much from the Windows world, but we'd need to come up with bindings for movement. I'd like ^j/^k/^l/^; for linewise movement and another modifier for pagewise movement - possibly ctrl +alt? but since ^j is return, we may not be able to do so without trouble. (we'd also need to devise some system for "go to end of line" and "Beginning of line") Honestly, I dislike 'modal text editors' as I feel they make the task at hand more difficult that it was to begin with. Sure there's a lot to be said for the power they bring, but with some forethought and planning I think that most of the power and all of the 'usefulness' of a modal editor to a modeless one.
Re: [dev] Sandy editor
hi,
On 05/29/11 13:00, Rafa Garcia Gallego wrote:
Thinking about a couple of issues now:
1.- The regexes used for syntax highlight relied on a GNU extension
(\< \> to mark word boundaries). We changed those to \b, which is the
POSIX equivalent, but some testing has determied this does not work in
some systems (MacOS as far as we know).
We looked at alternative regex engine implementations, but they either
suck (perl and the like) or do not implement the rather-useful \b (go,
plan9). Maybe it's time for a suckless regex library? Maybe we should
extend plan9's libregexp?
Actually, it was pancake who researched all this, so kudos to him.
After reading the libregex9 code (1200LOC, and probably the best regexp
library out there)
(because openbsd regex is about 3KLOC and musl 5KLOC and have some
documented bugs,
gnu one is about 35.000LOC...
the thing is that \b is the posix implementation and \< is a gnu
extension, but both are quite
new, and well.. after reading the code of the p9 regexp lib i realized
that it is completely
unnecessary, as long as you can write a (^| |\t|;|{|\(|\{|\[)... regexp
that matches the same.
it's a bit annoying if you have to type it manually, but this can be
done in a #define B as I
told you by xmpp yesterday.
Please commit the fix and we will get portable regexp support.
Another thing is that it would be great to be able to disable the syntax
highlight:
diff -r e2542c05953f sandy.c
--- a/sandy.c Tue May 31 01:39:32 2011 +0200
+++ b/sandy.c Tue May 31 16:34:39 2011 +0200
@@ -1614,6 +1614,8 @@
tabstop=atoi(argv[i]);
} else
i_usage();
+ } else if(!strcmp(argv[i], "-S")) {
+ local_syn="";
} else if(!strcmp(argv[i], "-s")) {
if(++i < argc) {
local_syn=argv[i];
add this patch to have -S to not use any syntax highlight
2.- There is a (very) limited subset of keys we can bind to to comply
with everyone's requests: there are 33 Control chars: Control +
@A-Z[\]^_? but some are taken (^[ is ESC, ^I is TAB, ^M and/or ^J is
Enter). Because of the way terminals work, we can't bind to
Control+Shift... no wonder they used to call them dumb terminals.
I have tried to reduce the number of bindings to use, but going below
30 seems impossible if we want full keyboard control. There are a few
ways to go from here, but they mostly suck:
- Screw full keyboard control, drop things like deleting/moving
through lines, words, etc. bind the rest and end up with an
uncomfortable editor.
- Reduce our bindings as much as possible, then bind the least used
actions to the function keys, hoping they do not collide with your
software.
- Implement a very little amount of key chains (possibly one prefix
only) a-la emacs, again only for the least used actions.
- Bite the bullet and bind with Meta, trying to avoid an overlap with
other popular suckless software (read dwm, wmii).
- Go modal, though this would probably end with us writing yet another vi clone.
- Draw our text editor in an X window instead of a terminal/curses and
then bind Control+Shift; this potentially sucks the most and you
wouldn't be able to use sandy on console/ssh.
NOTE: common movement keys (arrows, home/end, repag/avpag...) are also
bound to the usual suspects; we are talking additional keybindings to
avoid leaving the default typing position here.
NOTE: in the meantime, you can use the current sandy code by tapping
on te original sucky way to use meta in the console: press ESC, then
the key within some millisecs. Go usability.
Any thoughts on either topic are more than welcome,
Rafa.
i'm preparing a control-only based keyboard layout for sandy.. i'll have
a look
at your version, but I still think that modes will allow us to keep some
sane
control commands and be more productive for moving without
meta/control/shift
keys on the command mode.
Vi is great, and it's great for something, the only bad thing is that
most implementations
are bloated.. but with the codebase of sandy we can do an almost decent
vi clone.
Most basic editor functionality in sandy will be possible without
changing between
modes, but having the possibility to use the commands mode will provide
a more
decent interface. (IMHO).
Anybody more wanna give your opinion?
PD: Anselm, are you still alive?
PD: it's an already known bug, but multiline comments are not properly
highlighted, this is
because of performance reasons.. syntax highlight is nice.. but it's
probably overbloating
the execution. Dunno if we should drop them.. at least now they work
everywhere. :)
--pancake
Re: [dev] Sandy editor
On 5/29/11, Rafa Garcia Gallego wrote: > Thinking about a couple of issues now: > > 1.- The regexes used for syntax highlight relied on a GNU extension > (\< \> to mark word boundaries). We changed those to \b, which is the > POSIX equivalent, but some testing has determied this does not work in > some systems (MacOS as far as we know). > > We looked at alternative regex engine implementations, but they either > suck (perl and the like) or do not implement the rather-useful \b (go, > plan9). Maybe it's time for a suckless regex library? Maybe we should > extend plan9's libregexp? Maybe it syntax highlighting should be dropped for now, for the sake of simplicity? The door would always be open for adding it again later, once you've found a regex library that you're happy with which can be used to implement highlighting nicely. (Or just drop highlighting and leave it that way -- wouldn't bother me ;) > 2.- There is a (very) limited subset of keys we can bind to to comply > with everyone's requests: there are 33 Control chars: Control + > @A-Z[\]^_? but some are taken (^[ is ESC, ^I is TAB, ^M and/or ^J is > Enter). Because of the way terminals work, we can't bind to > Control+Shift... no wonder they used to call them dumb terminals. > > I have tried to reduce the number of bindings to use, but going below > 30 seems impossible if we want full keyboard control. There are a few > ways to go from here, but they mostly suck: > > ... When it comes to keybindings you're never going to make everbody happy, so aim for a simple set of default keybindings; those who don't like them can change them, add more, etc. Just try to avoid things that a majority of people will probably not like, such as Emacs style chained keybindings. John
Re: [dev] Sandy editor
Thinking about a couple of issues now: 1.- The regexes used for syntax highlight relied on a GNU extension (\< \> to mark word boundaries). We changed those to \b, which is the POSIX equivalent, but some testing has determied this does not work in some systems (MacOS as far as we know). We looked at alternative regex engine implementations, but they either suck (perl and the like) or do not implement the rather-useful \b (go, plan9). Maybe it's time for a suckless regex library? Maybe we should extend plan9's libregexp? Actually, it was pancake who researched all this, so kudos to him. 2.- There is a (very) limited subset of keys we can bind to to comply with everyone's requests: there are 33 Control chars: Control + @A-Z[\]^_? but some are taken (^[ is ESC, ^I is TAB, ^M and/or ^J is Enter). Because of the way terminals work, we can't bind to Control+Shift... no wonder they used to call them dumb terminals. I have tried to reduce the number of bindings to use, but going below 30 seems impossible if we want full keyboard control. There are a few ways to go from here, but they mostly suck: - Screw full keyboard control, drop things like deleting/moving through lines, words, etc. bind the rest and end up with an uncomfortable editor. - Reduce our bindings as much as possible, then bind the least used actions to the function keys, hoping they do not collide with your software. - Implement a very little amount of key chains (possibly one prefix only) a-la emacs, again only for the least used actions. - Bite the bullet and bind with Meta, trying to avoid an overlap with other popular suckless software (read dwm, wmii). - Go modal, though this would probably end with us writing yet another vi clone. - Draw our text editor in an X window instead of a terminal/curses and then bind Control+Shift; this potentially sucks the most and you wouldn't be able to use sandy on console/ssh. NOTE: common movement keys (arrows, home/end, repag/avpag...) are also bound to the usual suspects; we are talking additional keybindings to avoid leaving the default typing position here. NOTE: in the meantime, you can use the current sandy code by tapping on te original sucky way to use meta in the console: press ESC, then the key within some millisecs. Go usability. Any thoughts on either topic are more than welcome, Rafa.
Re: [dev] Sandy editor
On 5/27/11, Dieter Plaetinck wrote: > how ironic you pledge for "sane" keybindings and suggest > bindings optimized for qwerty users... > > I use dvorak, so I would prefer bindings optimized for that, but I > realise different people use different layouts, so everyone should be > able to choose how they like it. > 'Up' shouldn't be bound to a character. Neither 'w' nor ','. It should be bound to a button. That would usually be an arrow key between the textpad and the numpad. My point is that keyboard translation tables are at a lower layer than text editing. You shouldn't need to download a different editor for your different keyboard layout; you merely have to redefine some constants or edit a keyboard translation table. BTW, does anyone know how to configure "latch keys" in Linux, i.e. how to make it so that pressing and releasing the Shift button will affect the following keypress? I like modifier keys, but detest pressing multiple keys simultaneously.
Re: [dev] Sandy editor
On Sat, May 28, 2011 at 03:19:15AM +0200, Rafa Garcia Gallego wrote: > I asked around, found about a couple of very keybind maps using only Control: > > http://www.wordstar.org/wordstar/history/wmvswscmds.htm Go joe! Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Sandy editor
I asked around, found about a couple of very keybind maps using only Control: http://www.wordstar.org/wordstar/history/wmvswscmds.htm Then again they do not implement the unix standard ^U ^W ^H, which sucks a bit. Also, WordMaster may be unfeasible straight up as the Return key generates ^J and all, but this might be another starting point.
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 10:55:53PM +0200, Arian Kuschki wrote: > On 27 May 2011 10:46, Aur?lien Aptel wrote: > > > On Fri, May 27, 2011 at 10:29 AM, Aur?lien Aptel > > wrote: > > > arrows on them. A triangle layout (wqsd or ijkl for example) is much > > > easier to type. > > > > I meant wasd (on qwerty), obviously. > > > > that would be just sweet for the myriads of colemak users like myself Colemak user here. Most of the time I'm editing with sam, however if for whatever reason I do use vim, I have the hjkl keybindings remapped to colemak's neio. This is shifted over one key to the right (qwerty jkl;), but I think it makes much more sense since that's where you hand is placed already. I also have tab mapped to escape (with shift-tab inserting a literal tab character).
Re: [dev] Sandy editor
On 27 May 2011 10:46, Aurélien Aptel wrote: > On Fri, May 27, 2011 at 10:29 AM, Aurélien Aptel > wrote: > > arrows on them. A triangle layout (wqsd or ijkl for example) is much > > easier to type. > > I meant wasd (on qwerty), obviously. > > that would be just sweet for the myriads of colemak users like myself
Re: [dev] Sandy editor
Sam has sane keybindins. On May 27, 2011 2:26 PM, "Noah Birnel" wrote: >> *Please*, use sane keybindings. Emacs and vi were made with a specific >> keyboard from the 70s in mind. A time were the hjkl keys had little >> arrows on them. A triangle layout (wqsd or ijkl for example) is much >> easier to type. > > Puke. Triangle layout may be more intuitive to learn for single char/line > movement, but is probably not easier to type. Certainly not WASD layout, > laying on the weak fingers of the left hand. > > Vi's ergonomic problems lay with @ and ESC on the modern keyboard, not > with hjkl. > > Does anyone *know* what sane keybindings are? Vi seems less insane than > most to me (once you restore @ and ESC to their 70's positions, and swap > CTRL / ALT), but - it's still pretty insane. > > - Noah > >
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 8:26 PM, Noah Birnel wrote: > Puke. Triangle layout may be more intuitive to learn for single char/line > movement, but is probably not easier to type. Certainly not WASD layout, > laying on the weak fingers of the left hand. wasd is only an example... Pick another triangle layout if this one doesn't suit you. Besides, I use the same fingers with hjkl and ijkl so I really don't know what you're talking about. > Does anyone *know* what sane keybindings are? Vi seems less insane than > most to me (once you restore @ and ESC to their 70's positions, and swap That's a good improvement. Update the default layout to the most common keyboard type: ibm pc keyboard clone.
Re: [dev] Sandy editor
> *Please*, use sane keybindings. Emacs and vi were made with a specific > keyboard from the 70s in mind. A time were the hjkl keys had little > arrows on them. A triangle layout (wqsd or ijkl for example) is much > easier to type. Puke. Triangle layout may be more intuitive to learn for single char/line movement, but is probably not easier to type. Certainly not WASD layout, laying on the weak fingers of the left hand. Vi's ergonomic problems lay with @ and ESC on the modern keyboard, not with hjkl. Does anyone *know* what sane keybindings are? Vi seems less insane than most to me (once you restore @ and ESC to their 70's positions, and swap CTRL / ALT), but - it's still pretty insane. - Noah
Re: [dev] Sandy editor
On Thu, May 26, 2011 at 3:53 PM, Rafa Garcia Gallego wrote: > 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. Please, please, please do not use Emacs-style "chains". They make no sense and hurt the hands. > 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. I did for about an hour, then switched it back. Mod4 is too close to (read: right next to) Ctrl on my keyboard, and isn't as easy to reach with my thumb while typing, so it slowed me down considerably. --Andrew Hills
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 10:54 AM, Dieter Plaetinck wrote: > how ironic you pledge for "sane" keybindings and suggest > bindings optimized for qwerty users... I've used qwerty bindings for the example so anyone could follow. I don't use qwerty myself.
Re: [dev] Sandy editor
On Fri, 27 May 2011 10:29:17 +0200 Aurélien Aptel wrote: > On Fri, May 27, 2011 at 4:52 AM, John Matthewman > wrote: > > Yea, probably a good idea (of course, ignoring Emacs' chained > > keybindings). Sandy would benefit from a better set of default > > bindings. Though for reference you might want to look at something > > like mg [http://www.openbsd.org/cgi-bin/man.cgi?query=mg], or one of > > the other micro Emacs implementations, as they'll have the most > > important bindings and commands, and you won't have to sift through > > all of the extra garbage that is Emacs. > > *Please*, use sane keybindings. Emacs and vi were made with a specific > keyboard from the 70s in mind. A time were the hjkl keys had little > arrows on them. A triangle layout (wqsd or ijkl for example) is much > easier to type. > > Highly recommended readings from the (in?)famous Xah Lee: > http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html > http://xahlee.org/kbd/vi_emacs_keybinding_design.html > http://xahlee.org/comp/keyboard_shortcut_design.html > > Keyboard related (prepare for some time warp if you start reading): > http://xahlee.org/Periodic_dosage_dir/keyboarding.html > how ironic you pledge for "sane" keybindings and suggest bindings optimized for qwerty users... I use dvorak, so I would prefer bindings optimized for that, but I realise different people use different layouts, so everyone should be able to choose how they like it. Dieter
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 10:29 AM, Aurélien Aptel wrote: > arrows on them. A triangle layout (wqsd or ijkl for example) is much > easier to type. I meant wasd (on qwerty), obviously.
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 4:52 AM, John Matthewman wrote: > Yea, probably a good idea (of course, ignoring Emacs' chained > keybindings). Sandy would benefit from a better set of default > bindings. Though for reference you might want to look at something > like mg [http://www.openbsd.org/cgi-bin/man.cgi?query=mg], or one of > the other micro Emacs implementations, as they'll have the most > important bindings and commands, and you won't have to sift through > all of the extra garbage that is Emacs. *Please*, use sane keybindings. Emacs and vi were made with a specific keyboard from the 70s in mind. A time were the hjkl keys had little arrows on them. A triangle layout (wqsd or ijkl for example) is much easier to type. Highly recommended readings from the (in?)famous Xah Lee: http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html http://xahlee.org/kbd/vi_emacs_keybinding_design.html http://xahlee.org/comp/keyboard_shortcut_design.html Keyboard related (prepare for some time warp if you start reading): http://xahlee.org/Periodic_dosage_dir/keyboarding.html
Re: [dev] Sandy editor
+ John Matthewman ---+ > > I also have two wishes: > > - Make it possible to turn off highlighting (syntax highlighting, > highlighting the current line) and colour. I'm sure I'm not the only > person who doesn't need that stuff..? > - Keep it as a modeless editor! ;) > > John > i really like your wishes !
Re: [dev] Sandy editor
Hi there - I had been looking for a simple little editor for a while. Thanks for sharing. On 5/27/11, Rafa Garcia Gallego wrote: > 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. Yea, probably a good idea (of course, ignoring Emacs' chained keybindings). Sandy would benefit from a better set of default bindings. Though for reference you might want to look at something like mg [http://www.openbsd.org/cgi-bin/man.cgi?query=mg], or one of the other micro Emacs implementations, as they'll have the most important bindings and commands, and you won't have to sift through all of the extra garbage that is Emacs. I also have two wishes: - Make it possible to turn off highlighting (syntax highlighting, highlighting the current line) and colour. I'm sure I'm not the only person who doesn't need that stuff..? - Keep it as a modeless editor! ;) John
Re: [dev] Sandy editor
Im in the irc.oftc.net#suckless right now. On 26/05/2011, at 21:53, Rafa Garcia Gallego wrote: > Hi, > > On Thu, May 26, 2011 at 3:14 PM, pancake 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 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 >>> >>> h. 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
Re: [dev] Sandy editor
> That might be the screen updating every time you move the mouse. You > probably have a 64bit ncurses with NCURSES_MOUSE_VERSION 2 (or > greater?). I run 32-bit ncurses (i686). > If you try defining NCURSES_MOUSE_VERSION to 1, you'll get what I have > in my netbook: fast mouse selection without screen updates > (REPORT_MOUSE_POSITION simply does not fit in the mouse mask, yet > another example of why ncurses sucks). Thanks I'll give that a try.
Re: [dev] Sandy editor
On Thu, May 26, 2011 at 9:53 PM, Rafa Garcia Gallego wrote: > 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. That was really dumb. I defined the regexes to match for a quoted text (several times) as (read as a C string): "\"(\\.|[^\"])*\"" when I meant: "\"(.|[^\"])*\"" AFAIK \. is not standard regex, whereas \\ is. But I forgot to double-escape in C. Fixed in local, will push to tip. Sorry for the noise.
Re: [dev] Sandy editor
Hey, On Thu, May 26, 2011 at 10:41 AM, Hiltjo Posthuma wrote: > I agree with pancake. I also noticed the selection of text using the > mouse is very laggy / slow (using xterm). Anyway I'll keep an eye on > this project since it seems promising to me. That might be the screen updating every time you move the mouse. You probably have a 64bit ncurses with NCURSES_MOUSE_VERSION 2 (or greater?). If you try defining NCURSES_MOUSE_VERSION to 1, you'll get what I have in my netbook: fast mouse selection without screen updates (REPORT_MOUSE_POSITION simply does not fit in the mouse mask, yet another example of why ncurses sucks). Cheers, Rafa.
Re: [dev] Sandy editor
Hi,
On Thu, May 26, 2011 at 3:14 PM, pancake 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 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
>>
>> h. 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 us
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 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
h. 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
Re: [dev] Sandy editor
On 26 May 2011 14:14, pancake 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.. This is the problem with curses: it's the common denominator, and as a result is rather awful. I honestly think a true 'suckless editor' has to drop curses in favour of actually being able to interact with keyboard events, instead of just reading a stream of escape sequences. That doesn't really help with sandy, admittedly, but I think it's worth keeping in mind. cls
Re: [dev] Sandy editor
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.. 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? On 05/26/11 13:53, Yoshi Rokuko wrote: +--- Rafa Garcia Gallego ---+ * I tend to prefer a mode editor, because there are less keybindings [...] 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. i tend to prefer a modeless editor - we shouldn't need that many commands 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). what we really want is: ^U -> Delete from cursor to start of line. ^W -> Delete word before the cursor. ^H -> Delete character before the cursor. ^A -> Move cursor to start of the line. ^E -> Move cursor to end of the line. regards, yoshi
Re: [dev] Sandy editor
+--- Rafa Garcia Gallego ---+ > > > > * I tend to prefer a mode editor, because there are less keybindings [...] > > 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. > i tend to prefer a modeless editor - we shouldn't need that many commands > > 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). > what we really want is: ^U -> Delete from cursor to start of line. ^W -> Delete word before the cursor. ^H -> Delete character before the cursor. ^A -> Move cursor to start of the line. ^E -> Move cursor to end of the line. regards, yoshi
Re: [dev] Sandy editor
Anselm please make HTML mails bounce. Every year at my birthday I get HTML mail with happy smileys and large, colored, full-caps fonts. I tried to read suckless instead and now I got eye cancer. I'll also leave the last piece of cake for you.
Re: [dev] Sandy editor
I agree with pancake. I also noticed the selection of text using the mouse is very laggy / slow (using xterm). Anyway I'll keep an eye on this project since it seems promising to me. Kind regards, Hiltjo
Re: [dev] Sandy editor
Hi, Thanks a lot for your detailed mail. On Thu, May 26, 2011 at 12:33 AM, pancake 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 h. 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,
