Re: [dev] [sandy] Implement copy/paste/replace?
On Mon, Jul 14, 2014 at 6:50 PM, Charlie Kester corky1...@comcast.net wrote: I just wanted your opinion in implementing a feature inside the code or calling it via sh. Let's try to keep as many possible text operations scripted out as possible. Right now this holds true for: - Buffer CP (xsel | tee) - Autoindent (awk) - Capitalize / Uppercase / Lowercase (awk / tr) - Line joining (tr) And it should be easy to add more. We pass a bunch of env variables to anything we spawn and take commands on a named pipe, so even more complex operations (e.g. search and replace with confirmation) could be implemented as a external command. Which are the advantages for calling a script? First and foremost: simplicity. Any code we write we have to maintain. More code is the way of vim. Let's make less code the way of sandy. Other than that, see Charlie's mail, which has some very good points. Text piping is the sanest interface. Your question is an interesting one. It has me looking at the internal commands I do still use in vim and wondering how they might be implemented as external programs. Good! Please share your conclusions when you are done. One thing an editor could do to improve on vi(m)'s ! command, btw, is to pass arbitrary ranges of text to the external command, instead of a range of *lines*. Sandy already does this. Let's try to add a ! command.
[dev] [sandy] Undo, redo and repeat
Hi, With Dimitris' recent vi(m) bindings came a bug. BUG: operations added via multiplication appear as a set of unchained single Undo(s). They should be chained so they are undone / redone together. Which made me realize: TODO: need to extend the repeat framework (i.e. the '.' command) to store operations, multiplication and their parameters. TODO: may need a replace implementation if we want to repeat commands like 'c2w' properly. We could use that to implement the 'R' mode too. Cheers, Rafa
Re: [dev] [sandy] [PATCH] VIM key bindings.
On Sun, Jul 13, 2014 at 2:29 AM, Dimitris Zervas dzer...@dzervas.gr wrote: I think that the patch is ready. It has some little bugs and some beautiful vim keys were not implemented (such as r), but I'll work on them... I'm not into creating a dozen more functions, so it will take me some time to think a way to implement them... Great work! I found a couple of bugs, but they should be easy to fix. There is room for some more code, but I appreciate you keeping things simple. I think we could aim for maximum expectability while keeping the amount of code at a minimum: anyone using basic vi commands should feel mostly at home when using sandy. As a personal opinion, I'd rather not implement complex text operations that can be piped out (e.g. :s/foo/bar/, upper/lower case...) but other than that feel free to code away. So, here you go! :) You can also get the latest commit from my repo (https://git.dzervas.gr, it won't crash :P) I have applied this after changing t_nocomm()'s name to t_ins(). I've also added your name to the LICENSE file. However, I tried pushing to git.suckless.org, but I can no longer login to my account (r...@suckless.org) with my SSH key. Sigh. I have pushed it to my personal fork at https://bitbucket.org/rafaelgg/sandy I've not touched the data structures, and I won't, until I reach sandy's features up to a point that it can be my main editor. Thanks for that. Let's try to make a decent simple vi-like editor and then start worrying about performance and whatnot. Cheers, Rafa
Re: [dev] [sandy] [PATCH] VIM key bindings.
On Sun, Jul 13, 2014 at 2:40 PM, Dimitris Zervas dzer...@dzervas.gr wrote: Great work! I found a couple of bugs, but they should be easy to fix. Add a comment to be able to track them 'm', 'n' and 'N' were not working in command mode (the Arg was 0 so it was starting a sequence). I fixed it by creating a stub m_adjective and checking for it in code. I pushed that and a couple of extra bindings. The way of chaining commands if the test pointers for n+1 match is brilliant. We need a way to execute those *after* the adjective returns so we can easily implement 'y' and 'c'. Could I have write access to sandy? Right now I don't have write access to suckless.org either. IMO you can have it, but it's up to the suckless.org gods really. In the meantime I added you to my own bitbucket remote. Thanks for that. Let's try to make a decent simple vi-like editor and then start worrying about performance and whatnot. I wait the day that I'll edit sandy with sandy :P That sounds like a good rule of thumb.
Re: [dev] [patch] sandy
On Mon, Jun 30, 2014 at 6:42 AM, strake...@gmail.com wrote: Subject: [PATCH 1/5] call endwin on suspend Subject: [PATCH 2/5] better regcomp failure messages Subject: [PATCH 3/5] simplify c file regex Subject: [PATCH 4/5] optionalize to use term status feature Subject: [PATCH 5/5] possibilize title bar at bottom Thanks for your contribution. I have applied all but [2/5]. I do like the detailed messages when compiling a regex fails, but: - I think it can be extended at failed searches as those are, by far, the ones that will fail most often. - Actually, if regcomp() fails at f_syntax(), calling i_die() seems kind of excessive and will lose any changes. I consider this a bug. This last case should not be a common situation; it will only happen with a buggy regex in config.h, so thank goodness we don't have a runtime config file. As stated before, I don't have access to the git repo at suckless.org anymore, but in the meantime you can find the changes at https://bitbucket.org/rafaelgg/sandy Sorry for the delay. Please, next time try to attach the patches as independent files. Cheers, Rafa
Re: [dev] [sandy] [PATCH] VIM key bindings.
On Fri, Jul 11, 2014 at 12:32 AM, Dimitris Papastamos s...@2f30.org wrote: There are many ways to do this, I'd go for the simplest approach in terms of code readability and stop worrying about performance. That. The reason sandy uses a double-linked list of lines is obviously not performance, but code simplicity. Sandy's performance is a joke: we memmove() the rest of the line when typing a character, allocate new memory every 128 characters or '\n' and memcpy() the whole file when matching a regexp. You can do worse than that, but you have to try really hard. Do you know what? It does not really matter. Both memory and CPU cycles are a cheap commodity these days. Most of the time you will be editing very small files. Unless you plan on having ed-like usability, the UI will take most of te CPU cycles anyway. I remember a friend came to me about editing a several megabyte XML with longish lines... and sandy did not perform as bad as I expected. Not having multi-line syntax highlighting (or XML highlighting) helped. And boy, is a linked-list convenient. Implementing text manipulation functions is a breeze. The screen painting is kinda hellish (line wrapping takes most of the fall), but it would be worse if we had to intertwine yet another data structure. Don't get me wrong. We probably need another data structure in the long run, but let's first make the editor we want and then consider the performance implications.
Re: [dev] [sandy] [PATCH] VIM key bindings.
Hi Dimitris, Thanks for working on sandy! I'm skimming over the changes and they look promising. When you are done polishing, they would fit nicely upstream. In fact... does anyone use the default / non-modal sandy bindings on a daily basis? I find they work nicely for simple edits or when typing from scratch, but find myself falling back to vi(m) for heavier changes. We can try and keep two different config files for a while. As a side note: the first version of sandy was actually a GTK+ editor and had two different config files for Emacs and CUA/windows-like keybindings. Yikes. If suckless-vi ends up based on sandy I'll be as happy as a clam. I don't have a lot of free time, but I'd be happy to help. BR, Rafa
Re: [dev] [sandy] Undo redo man page entries
On Sat, May 3, 2014 at 6:55 AM, Wolfgang Corcoran-Mathe first.lord.of.t...@gmail.com wrote: The man page mentions sandy's undo feature, but does not the appropriate keybinding. No mention is made of the redo/repeat feature. Good catch. Applied.
Re: [dev][sandy][patch] minor typo correction
On Wed, Apr 23, 2014 at 7:26 AM, jos...@cubesolving.com wrote: Minor typo correction. diff --git a/TODO b/TODO index 6e01237..535a8e4 100644 --- a/TODO +++ b/TODO @@ -13,7 +13,7 @@ In no particular order, at sandy.c: At config.def.h: - Bindings! - Use local/system script path and all -- Choose color-set for either black of white bg +- Choose color-set for either black or white bg - Define more syntaxes - Refine syntax regexes Merged. However, I cant seem to push to git.suckless.org: $ git push origin fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Can any suckless.org admin take a look? In the meantime find sandy at https://bitbucket.org/rafaelgg/sandy Cheers, Rafa
[dev] [st][patch] Fix segfault when pressing PrintScr without a selection
Hi,
Attached is a silly patch to prevent a segmentation fault in st when
you accidentally press PrintScr with no text selected.
BTW does anybody use this with a plumber? Care to explain the details?
BR,
Rafa
diff --git a/st.c b/st.c
index 69b2491..97abcbb 100644
--- a/st.c
+++ b/st.c
@@ -2315,9 +2315,10 @@ tdumpsel(void)
{
char *ptr;
- ptr = getsel();
- tprinter(ptr, strlen(ptr));
- free(ptr);
+ if((ptr = getsel())) {
+ tprinter(ptr, strlen(ptr));
+ free(ptr);
+ }
}
void
[dev] [st] Tip adds non-existing trailing whitespace upon mouse selection + fix
Hi, Upon selecting text with the mouse, st tip fills the selection straight from its term matrix and replaces unset glyphs with a whitespace. This results in some really annoying trailing whitespace at the end of each line when you paste/pipe the selection. Is there any reason for this? The attached patch fixes this behavior. Cheers, Rafa. st-tip-do-not-select-trailing-whitespaces.diff Description: Binary data
Re: [dev] Missing hg repo after move?
Should I do the hg --config format.dotencode=0 trick that the hg docs suggest and push it? It seems fair since other repos don't seem to need dotencode. I did that for now, so the sandy repo is back online. It's not like we were going to have files starting with ._ or anyways Apologies for the inconvenience, Rafa.
Re: [dev] Missing hg repo after move?
Hi, On Thu, Sep 29, 2011 at 9:28 PM, Rob robpill...@gmail.com wrote: On 29 September 2011 20:08, Jeremy Jackins jeremyjack...@gmail.com wrote: hg clone http://hg.suckless.org/sandy gives abort: HTTP Error 500: Internal Server Error Also, if I do: $ hg -v pull running ssh r...@suckless.org hg -R /repos/sandy serve --stdio remote: abort: There is no Mercurial repository here (.hg not found)! abort: no suitable response from remote hg! yet .hg seems to be there: $ ssh r...@suckless.org ls -A /repos/sandy config.def.h config.mk .hg .hgtags LICENSE Makefile README sandy.1 sandy.c TODO however... $ ssh r...@suckless.org hg -R /repos/sandy -v status abort: requirement 'dotencode' not supported! Looking at hg docs at http://mercurial.selenic.com/wiki/RequiresFile#Older_Mercurial_versions it seems like the new suckless host has an old mercurial version: $ hg --version Mercurial Distributed SCM (version 1.9.2) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2011 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ssh r...@suckless.org hg --version Mercurial Distributed SCM (version 1.6.4) Copyright (C) 2005-2010 Matt Mackall m...@selenic.com and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Is there any reason for this? Should I do the hg --config format.dotencode=0 trick that the hg docs suggest and push it? It seems fair since other repos don't seem to need dotencode. Cheers, Rafa.
Re: [dev] Commit messages
On Sun, Sep 18, 2011 at 12:04 PM, Connor Lane Smith c...@lubutu.com wrote: It looks like sandy's hgrc wasn't set up properly. I checked the other repos and sandy was the only full project missing this mercurial hook. I've fixed it, and future commits should be mailed to hack...@suckless.org as expected. Oooops. My bad, I didn't know this was needed.
[dev] [st] Scroll selection patch
Hi,
One thing from st that bugs me a little: whenever I select some text
with the mouse it remains marked even if I type in the same line and
change its content. The same happens if I keep typing and the window
scrolls, since the selection box does not scroll along with it. In
either case, a new piece of text seems to be selected, but this new
selection is of course not copied to the clipboard, which feels
annoying.
This patch solves this problem with a behavior akin to that of
xterm/urxvt: scrolling the selection box with the screen and hiding it
if you type in its line or clear the screen.
Cheers,
Rafa
PS: I tried looking both at xterm and urxvt source for a minute;
almost ripped my eyes off
diff -r 1c8e6796c6fe st.c
--- a/st.c Sun Aug 14 17:15:19 2011 +0200
+++ b/st.c Wed Sep 14 15:38:20 2011 +0200
@@ -231,6 +231,7 @@
static inline int selected(int, int);
static void selcopy(void);
static void selpaste();
+static void scrollsel(int, int);
static int utf8decode(char *, long *);
static int utf8encode(long *, char *);
@@ -801,6 +802,8 @@
term.line[i] = term.line[i-n];
term.line[i-n] = temp;
}
+
+ scrollsel(orig, n);
}
void
@@ -816,6 +819,29 @@
term.line[i] = term.line[i+n];
term.line[i+n] = temp;
}
+
+ scrollsel(orig, -n);
+}
+
+void
+scrollsel(int orig, int n) {
+ if(sel.bx == -1) return;
+ if(BETWEEN(sel.by, orig, term.bot) || BETWEEN(sel.ey, orig, term.bot)) {
+ if((sel.by+=n) term.bot || (sel.ey+=n) term.top) {
+ sel.bx=-1;
+ return;
+ }
+ if(sel.byterm.top) {
+ sel.by=term.top;
+ sel.bx=0;
+ }
+ if(sel.eyterm.bot) {
+ sel.ey=term.bot;
+ sel.ex=term.col;
+ }
+ sel.b.y=sel.by; sel.b.x=sel.bx;
+ sel.e.y=sel.ey; sel.e.x=sel.ex;
+ }
}
void
@@ -1072,6 +1098,7 @@
break;
/* XXX: (CSI n I) CHT -- Cursor Forward Tabulation n tab stops */
case 'J': /* ED -- Clear screen */
+ sel.bx = -1;
switch(escseq.arg[0]) {
case 0: /* below */
tclearregion(term.c.x, term.c.y, term.col-1, term.c.y);
@@ -1377,6 +1404,7 @@
}
}
} else {
+ if(sel.bx != -1 BETWEEN(term.c.y, sel.by, sel.ey)) sel.bx =
-1;
switch(ascii) {
case '\t':
tputtab();
Re: [dev] slmenu - dmenu spinoff for the console
On Thu, Sep 1, 2011 at 7:46 PM, Bjartur Thorlacius svartma...@gmail.com wrote: Şann miğ 31.ágú 2011 12:09, skrifaği Rafa Garcia Gallego: I sometimes use sandy in a SSH session, so I wrote some code around dmenu to have it work in the console. The resulting program takes input from stdin, reopens the tty, prints the UI to stderr, gets your input (again from stdin) and prints the result to stdout, so it mostly works as a drop-in replacement for dmenu. Stuff I don't use such as the multiline menu and runtime selectable colors is not implemented. Why not write the UI to tty directly? Or do you suppose redirecting stderr to null to get rid of the UI is worth supporting? Actually I might as well had done this. However, I had nothing to write to stderr anyways and it seems cleaner this way: the file descriptor is open and points to the tty, so why not use it?. Bonus feature: you may redirect it to another tty for -say- debugging. Anyways, I doubt anyone redirects stderr to /dev/null by default, much less for an interactive program. You could (maybe should) redirect stderr in the command you use to feed slmenu its options (unlike say for dmenu, which usually just pollutes your .xsession-errors a bit). Either way, slmenu does not print its UI until it's finished reading stdin, same as dmenu.
[dev] [st] Fix terminfo op for light backgrounds
Hi, Attached is a tiny change to st's terminfo entry to set 'op' (original pair) to \E[39;49m. This is akin to what urxvt and xterm do, and fixes some issues in certain curses apps (e.g. top) if your terminal had a color scheme other than white on black. Cheers, Rafa. st-terminfo_op.patch Description: Binary data
Re: [dev] How to monitor battery status
A while back I put together a crappy C monitor, which I still use to the day.
Find the .c attached, compile with -lX11 as normal, peruse at will.
Cheers,
Rafa.
#include stdlib.h
#include stdio.h
#include time.h
#include sys/types.h
#include regex.h
#include unistd.h
#include signal.h
#include string.h
#include Xutil.h
#include Xatom.h
#define BATTERY BAT1
#define BATT_INFO_PATH /proc/acpi/battery/BATTERY/info
#define BATT_STATE_PATH /proc/acpi/battery/BATTERY/state
#define BATT_FULL_REGEX ^last full capacity:[ ]+([0-9]*) .*$
#define BATT_CUR_REGEX ^remaining capacity:[ ]+([0-9]*) .*$
#define DATE_FORMAT %H:%M (%Z) - %a %d.%m.%Y
#define BUFFER_SIZE 4096
#define STATUS_SIZE 256
static char *buf;
static regex_t *batt_full_re, *batt_cur_re;
static Display *dpy;
static Window root;
static XTextProperty name;
void update_status(char *c) {
name.value=(unsigned char*)c;
name.nitems=strlen(c);
XSetWMName(dpy, root, name);
XSync(dpy, False);
}
void cleanup(void) {
regfree(batt_full_re);
regfree(batt_cur_re);
free(buf);
}
void die(int unused) {
update_status(dwmrc died!);
exit(EXIT_FAILURE);
}
int read_batt(const char *batt_path, const regex_t *batt_re) {
FILE *f;
int batt_total = -1;
regmatch_t result_re[2];
f = fopen(batt_path, r);
fread(buf, 1, BUFFER_SIZE, f);
regexec(batt_re, buf, 2, result_re, 0);
if(result_re[1].rm_so != -1 result_re[1].rm_eo != -1) {
buf[result_re[1].rm_eo]='\0';
batt_total = atoi(buf+result_re[1].rm_so);
}
fclose(f);
return batt_total;
}
int main(int argc, char **argv) {
time_t cur_t;
struct tm *cur_lt;
char *status;
int batt_full, batt_cur;
int n;
if( !(dpy = XOpenDisplay(NULL)) ||
!(buf = calloc(1, sizeof(char)*BUFFER_SIZE)) ||
!(status = calloc(1, sizeof(char)*STATUS_SIZE)) ||
!(batt_full_re = calloc(1, sizeof(regex_t))) ||
!(batt_cur_re = calloc(1, sizeof(regex_t))) ) die(0);
regcomp(batt_full_re, BATT_FULL_REGEX, REG_EXTENDED|REG_NEWLINE);
regcomp(batt_cur_re, BATT_CUR_REGEX, REG_EXTENDED|REG_NEWLINE);
root = RootWindow(dpy, DefaultScreen(dpy));
name.encoding=XA_STRING;
name.format=8;
signal(SIGINT, die);
signal(SIGILL, die);
signal(SIGTERM, die);
while(1) {
batt_full=read_batt(BATT_INFO_PATH, batt_full_re);
batt_cur =read_batt(BATT_STATE_PATH, batt_cur_re);
if(batt_full 0 batt_cur = 0) n=snprintf(status, STATUS_SIZE, %3d%% -- , (100*batt_cur/batt_full));
else n=snprintf(status, STATUS_SIZE, NAN -- );
cur_t = time(NULL);
cur_lt = localtime(cur_t);
strftime(status[n], STATUS_SIZE-n, DATE_FORMAT, cur_lt);
update_status(status);
sleep(10);
}
return EXIT_SUCCESS;
}
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.
[dev] [st] Statusline terminfo entries patch
Hi, Attached is a patch to add terminfo entries asserting st has indeed an statusline (i.e. you can change the window title) and how to write to it. The code to do so is already there, but it has not been properly specified in the terminfo file. Some software (e.g. sandy O:-)) uses those entries to write to the statusline without hardcoding the escape sequences used to get to/from there; other software should probably do this instead of assuming xterm compatibility straight forward. For some reason I fail to understand, this is not standard in the xterm terminfo file, but is instead in xterm+sl. It is also there in rxvt-unicode-256color, which is what my current terminal uses. If anyone knows of a good reason to avoid this, please let me know so I can scrap this patch and thik of something else for sandy. Best regards, Rafa. diff -r 2effc50d2c4f st.info --- a/st.info Sun May 22 16:57:27 2011 +0200 +++ b/st.info Wed Jun 01 16:35:00 2011 +0200 @@ -33,8 +33,10 @@ ed=\E[J, el=\E[K, el1=\E[1K, + fsl=^G, home=\E[H, hpa=\E[%i%p1%dG, + hs, ht=^I, hts=\EH, ich=\E[%p1%d@, @@ -93,6 +95,7 @@ smso=\E[7m, smul=\E[4m, tbc=\E[2g, + tsl=\E]0;, ul, xenl,
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
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
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] Re: sbase
On Wed, May 25, 2011 at 10:54 AM, pancake panc...@youterm.com wrote: On 05/24/11 19:12, Rafa Garcia Gallego wrote: On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen chneukirc...@gmail.com wrote: Remotely reminds me of http://code.google.com/p/aoeui/ which also is pretty lightweight, has UTF8, is binary-safe, and has infinite undo. ~7KLOC, no curses dependency. This reminds me of my very own sandy[1]. Sorry for the blatant publicity. Ok, mine depends on ncurses, but the again it weights some 1700 SLOC only. The idea of using external tools to process text seems quite suckless to me. [1] http://sandyeditor.sf.net/ Wow. sandy sources looks great. I managed to reproduce some segfaults and I feel not comfortable with a non-hjkl editor. but as long as it's configurable in the config.h. Well, I tried to go for an almost modeless editor because I like it better in theory. But I keep falling back to vi(m) to do serious edits, even on the sandy code (shame on me!). Maybe I should try adding two modes to it, see how it plays out. The default bindings are there to be changed, of course. I imagined emacs-like bindings (read bash-like too) would be comfy for most people. About the segfaults, argh! Could you please point them out to me? Or maybe patch them yourself if you have the time :) What about moving that repo to hg.suckless.org ? Sure! don't I need a SSH account or something? Cheers, Rafa.
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
Re: [dev] Re: sbase
On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen chneukirc...@gmail.com wrote: Remotely reminds me of http://code.google.com/p/aoeui/ which also is pretty lightweight, has UTF8, is binary-safe, and has infinite undo. ~7KLOC, no curses dependency. This reminds me of my very own sandy[1]. Sorry for the blatant publicity. Ok, mine depends on ncurses, but the again it weights some 1700 SLOC only. The idea of using external tools to process text seems quite suckless to me. [1] http://sandyeditor.sf.net/
