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
On 6/2/11, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com 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
On Thu, Jun 2, 2011 at 6:49 AM, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com 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/1/11, pancake panc...@youterm.com 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 06/01/11 10:22, John Matthewman wrote: On 6/1/11, pancakepanc...@youterm.com 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 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
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 m...@brain-dump.orgwrote: 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
Hi,
On Tue, May 31, 2011 at 4:40 PM, pancake panc...@youterm.com 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 comments are not properly
highlighted, this is
Re: [dev] Sandy editor
On 5/31/11, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com 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
Hi, Thanks for your input. On Tue, May 31, 2011 at 8:07 PM, Bjartur Thorlacius svartma...@gmail.com wrote: On 5/31/11, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com 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 hills...@gmail.com wrote: On Tue, May 31, 2011 at 12:51 PM, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com 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
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
rafael.garcia.gall...@gmail.com 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,
On Tue, May 31, 2011 at 10:56 PM, Connor Lane Smith c...@lubutu.com 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
rafael.garcia.gall...@gmail.com 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
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 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
On Fri, May 27, 2011 at 4:52 AM, John Matthewman jmatthew...@gmail.com 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
On Fri, 27 May 2011 10:29:17 +0200 Aurélien Aptel aurelien.ap...@gmail.com wrote: On Fri, May 27, 2011 at 4:52 AM, John Matthewman jmatthew...@gmail.com 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:54 AM, Dieter Plaetinck die...@plaetinck.be 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
*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 nbir...@gmail.com 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
Sam has sane keybindins. On May 27, 2011 2:26 PM, Noah Birnel nbir...@gmail.com 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 10:55:53PM +0200, Arian Kuschki wrote: On 27 May 2011 10:46, Aur?lien Aptel aurelien.ap...@gmail.com wrote: On Fri, May 27, 2011 at 10:29 AM, Aur?lien Aptel aurelien.ap...@gmail.com 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
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
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
+--- 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
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
On 26 May 2011 14:14, pancake panc...@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.. 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
Hi, Thanks a lot for your detailed mail. On Thu, May 26, 2011 at 12:33 AM, pancake panc...@youterm.com wrote: About moving sandy to hg.suckless.orgshould be discussed with Anselm. We can setup a cron sync to clone your repo.. But it would be better to have it there. I'm fine with moving the main repo to suckless.org. I'm not specially attached to sourceforge. 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, but Ctrl+Shift+X bindings seemed cumbersome for text
