[dev] [tabbed] [PATCH] Fix a bug with mouse-selecting (particularly nasty when closing tabs).
If not all tabs are shown, trying to select a tab with a mouse checked
against coordinates of tabs when they were last drawn. This lead to
incorrectly choosing tabs not even on screen. Checking only drawn ones
should help.
You can reproduce the bug by running old version of tabbed, opening 8 tabs,
switching to 1st, switching to 8th, and clicking on 3rd tab name – 1st
tab gets focused. With new code, this behaviour is gone.
---
tabbed.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tabbed.c b/tabbed.c
index 6c8a986..5b1fb9a 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -170,15 +170,18 @@ void
buttonpress(const XEvent *e) {
const XButtonPressedEvent *ev = &e->xbutton;
int i;
+ int fc;
Arg arg;
- if((getfirsttab() != 0 && ev->x < TEXTW(before)) || ev->x < 0)
+ fc = getfirsttab();
+
+ if((fc > 0 && ev->x < TEXTW(before)) || ev->x < 0)
return;
if(ev->y < 0 || ev-> y > bh)
return;
- for(i = 0; i < nclients; i++) {
+ for(i = (fc > 0) ? fc : 0; i < nclients; i++) {
if(clients[i]->tabx > ev->x) {
switch(ev->button) {
case Button1:
--
1.8.4.rc2
[dev] [surf] [PATCH] Be more consistent with command-line toggles.
---
surf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/surf.c b/surf.c
index 42bc393..b89c0e2 100644
--- a/surf.c
+++ b/surf.c
@@ -1326,6 +1326,9 @@ main(int argc, char *argv[]) {
case 'f':
runinfullscreen = 1;
break;
+ case 'F':
+ runinfullscreen = 0;
+ break;
case 'g':
allowgeolocation = 0;
break;
--
1.8.4.rc2
Re: [dev] [sbase] [patch] Add strings(1)
2013/8/14 sin : > Hi, > > Added a barebones strings(1) implementation. Let me know > if you guys want this. > > Thanks, > sin Aren't you printf() ing non-null-terminated string? This can explode.
[dev] The new version of wondrous swaprootname (1)!
The version 2.0 of swaprootname (1) has seen the world, now with less race conditions! swaprootname [1] is your tool of choice for permanently or temporarily changing root window name, in scripts or regularly in shell. Unfortunately, previous version suffered from an issue: if you launched two instances of it, sometimes it will not restore original name properly, which is indeed annoying. The new version fixes this, and now you can have as many scripts concurrently showing useful information in root name as you want! [2] Download one today and rejoice! [1] https://github.com/ElectronicRU/swaprootname [2] Technically, X11 text properties may or may not have some maximum length, so amount of scripts is tecnically limited, but I expect this bound to be large enough. Also, race conditions may still occur, due to name changing not being instant, but chances are, they will not.
[dev] [st] [PATCH] Fixed memory leak in xsettitle().
---
st.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/st.c b/st.c
index 289ecb8..0b1e97a 100644
--- a/st.c
+++ b/st.c
@@ -3211,6 +3211,7 @@ xsettitle(char *p) {
Xutf8TextListToTextProperty(xw.dpy, &p, 1, XUTF8StringStyle,
&prop);
XSetWMName(xw.dpy, xw.win, &prop);
+ XFree(prop.value);
}
void
--
1.8.3.2
[dev] [tabbed] [PATCH] Limit mouse handling to top bar area.
It's rather annoying when you e.g. scroll in Surf, move your mouse a little bit
too low, and Tabbed starts to switching tabs because you got caught in lower
border area. I don't think this behaviour is intentional or desirable.
---
tabbed.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tabbed.c b/tabbed.c
index 9ece904..6c8a986 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -175,6 +175,9 @@ buttonpress(const XEvent *e) {
if((getfirsttab() != 0 && ev->x < TEXTW(before)) || ev->x < 0)
return;
+ if(ev->y < 0 || ev-> y > bh)
+ return;
+
for(i = 0; i < nclients; i++) {
if(clients[i]->tabx > ev->x) {
switch(ev->button) {
--
1.8.3.2
[dev] [tabbed] [PATCH] Fixed obscure miscalculation when a client is closed.
This crops up whenever you just switched from tab # N+1 to tab # N
and close current tab. unmanage() first decreases lastsel
(so it becomes N) then erroneously tests it against sel and focuses first tab
instead. One can see that focus() would never set lastsel == sel,
so I took liberty to fix this annoying behaviour which happens to frequently
with newposition = 0 and npisrelative = True settings.
---
tabbed.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tabbed.c b/tabbed.c
index ba1df21..9ece904 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -1008,7 +1008,11 @@ unmanage(int c) {
}
if(c == sel) {
- if(lastsel > 0 && lastsel != sel) {
+ /* Note that focus() will never set lastsel == sel,
+* so if here lastsel == sel, it was decreased by above
if() clause
+* and was actually (sel + 1) before.
+*/
+ if(lastsel > 0) {
focus(lastsel);
} else {
focus(0);
--
1.8.3.2
Re: [dev] [surf] [PATCH 1/1] remove unused function eval()
It is meant to be used in key bindings.
2013/7/26 Christian Hesse :
> Hello everybody,
>
> the function eval() is unused, so remove it. Patch is attached. Thanks!
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
> putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
Re: [dev] [PATCH] Add RGB color definition
2013/7/19 Roberto E. Vargas Caballero :
> From: "Roberto E. Vargas Caballero"
>
> It is impossible allocate all the RGB colors using a static
> array, so it is necessary move DC.col into a pointer and use
> dinamic memory.
>
> Since the color definition is not used to much is not a bad idea
> use realloc each time. It means the color definition arry will
> increase its size until user resets the terminal.
>
> If this sequence is used a lot we should check if the color
> is already defined and look for a way ef releasing colors
> not used (and maybe a better allocation scheme).
I disapprove of this patch, since it does not work the way advertised.
Particularly, added colors can be palette-swapped with another
sequence. Also, replacing static memory with malloc() feels dirty.
You also turn if () {...} to if () ... for absolutely no reason, even
though it's quite against the guidelines.
What I'd suggest is using special colour indices (like 0x1RRGGBB, 1 is
for ensuring large numbers) for true colors, and wrapping colour
access in xdraws(). Much cleaner, doesn't touch heap.
[dev] [st] Screen clearing problems
Hi. I've noticed some odd screen clearing problems with TUI aptitude (which switches to alternate screen when invoking dpkg, and instead of clearing it just prints "0" and overwrites whatever text it has) and transmission-remote-cli, which does the same upon exiting. This is most likely due to mis-handled escape/wrong tinfo entry/"xterm compliance". If anyone has the same problem with these or other programs, please respond.
Re: [dev] lisp
2013/7/2 Craig Brozefsky : > > Good morning, some good-natured trollbait to go with my coffee! > I've spent about half my professional career (15+ yrs) working on Lisp > products -- Common Lisp, and Clojure specifically. In both > cases, accomplishing what we had to do in the time we had would not have > been possible with the tools available in other languages at the time -- > we had to make new tools and take new approaches to solving the > problems. You know, we had to like do programming, motherfucker. [1] > > I would suggest the set of possible programs and programmers is much > larger than you perceive it to be. > > Or, maybe you're just fanning some flames for entertainment. May I get links to your hard works or at least to your papers, or all you have is some stuff you failed to sell to Yahoo, like that one guy? You must be really proud about making new tools for solving new problems, except it's what programmers do, isn't it? Also, the tools have really advanced in all that years, check them out. Nobody is writing in BCML anymore. There is nothing entertaining in the fact that my excitement over Lisp concepts one day met my disappointment that it provides no advantage whatsoever over other modern languages. I do recognize the value of Lisp in the history of programming languages, it served good, but I'm afraid this language family is no more. We should call it "ex-Lisp". > You DO realize that it's been passe to bitch about parens for > years. Also, you complain that lack of syntax in a language with first > class functions and macros and damn near unlimited control over phase(s) > of evaluation like Racket makes your work less 'terse' than you want -- > well, here's a nickle kid, get yourself a real program that writes > programs that writes programs that writes *your* program. 8^) What? I didn't bitch about parens. I bitched about getting an element of vector being a function with a long name, mostly. It's funny how you Lispers like to think that metaprogramming in-language is a feature unique to Lisp and not something adopted by, well, most of languages with level higher than C. Also, it won't save you from lack of terseness. You cannot get away from Kolmogorov length, and when you are doing Lisp, you need to count words instead of characters because (see above). >> And no libraries. > > Trollolololol. If your "Trolololol" means "you just cannot google", then links please. If however it does mean "tr00 programmers don't need libraries", then I shall agree that Lisp is on par with Forth in that it allows you to rewrite stuff that had already been written in other, less ideal, languages, VERY elegantly. But some people need to write something new, too. Having reread my answer, I apologize if you find it unusually rude, but you are pronouncing the same empty words that I heard many times. > [1] http://programming-motherfucker.com/ > > -- > Craig Brozefsky > Premature reification is the root of all evil > Thanks for the link, and nice signature.
Re: [dev] lisp
2013/7/2 Andrew Gwozdziewycz : > SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most > cases. SBCL, since it is more or less an interactive native code compiler is > faster yet. You'll have to qualify painful. Are you referring to syntax? If > so, no Lisper even sees parentheses. Nah, I like parens, and I understand that they are usually made as pale as possible, and all text editors do everything to make you write less parens by yourself. What I was referring to is -no consistent OS interface, -keywords straight from the land of CREAT, and -funky (personal opinion here) abstractions of Common Lisp. Racket is great, as it is Scheme implementation that is not slow, but the absence of syntax still makes programs a bit less terse than I like them to be. > Yes, the Racket (previously PLT Scheme) has certainly made it even more > viable, but they've also made a practical, quality implementation for real > work. Many other Lisps are similar, certainly many of the Common Lisps. Yet there is apparently nothing non-proof-of-concept-y written in Racket, which is sad. Maybe it's because Racket still provides nothing other than theoretical beauty compared to C, as all other Schemes do? There is just no niche for it. > I urge you to check out Quicklisp (for Common Lisp, > http://www.quicklisp.org/) and reevaluate your statement. While the > Quicklisp + other Common Lisp library repos aren't as exhaustive as CPAN, > they usually contain very high quality code (unlike CPAN, or PyPi, or > whatever the fuck PHP and Ruby use). The fact that "nobody uses Lisp" is a > huge advantage since the people who do are actually smart and very > productive. Or have nothing better to do... Quicklisp is splendid. 700 packages, about a half of which are some network protocol wrappers, and others are numeric utils in experimental state, image handling, and html5 parsing. So, all in all, Common Lisp looks like glue language with all these packages. Do we seriously need another poorly supported glue language with a small amount of libraries? And I don't really care for the quality of library code as long as it works and has tolerable API. > You should not forget Kawa, Clojure and ABCL from where you have > access to all java library stack. And there is CFFI, implemented by almost > all Common Lisp implementation, from where you can access all shared > libraries installed on the system. > > Best. Well, nowadays every toy language out there has CFFI, and it's far less pleasant to use than native libraries. I have nothing to say about Java library stack because I haven't used it, bu I doubt its usage is seamless. Correct me if I'm wrong.
Re: [dev] lisp
2013/6/29 oneofthem : > is there any reason why lisp isn't mentioned much in the suckless > community? > considered irrelevant, harmful or what? I personally consider it irrelevant. People just don't actually write in Lisp, because it's either painful or results in slowness. Lisp is a great language for teaching abstract CS concepts and language designs, but that's it. And no libraries.
[dev] [st] [PATCH] Remove long text being cropped/wrapped to standard 80x24 on launch.
To be more specific, now tty creation is delayed until X window is
actually mapped; last ConfigureNotify before mapping determines
initial tty size.
Please report problems if there are any.
---
TODO |4
st.c | 21 ++---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/TODO b/TODO
index afd6401..4fc1346 100644
--- a/TODO
+++ b/TODO
@@ -26,10 +26,6 @@ bugs
* fix rows and column definition in fixed geometry
* fix -e handling
* remove DEC test sequence when appropriate
-* When some application outputting long text is run in the shell init scripts,
- then this text might be stripped to the standard 80x25 due to st running the
- virtual terminal at first priority. Maybe the vt initialisation could be
- moved somewhere after knowing the right window size.
misc
diff --git a/st.c b/st.c
index 2811876..ef17e90 100644
--- a/st.c
+++ b/st.c
@@ -3532,10 +3532,28 @@ resize(XEvent *e) {
void
run(void) {
XEvent ev;
+ int w = xw.w, h = xw.h;
fd_set rfd;
int xfd = XConnectionNumber(xw.dpy), xev, blinkset = 0, dodraw = 0;
struct timeval drawtimeout, *tv = NULL, now, last, lastblink;
+ /* Waiting for window mapping */
+ while(1) {
+ XNextEvent(xw.dpy, &ev);
+ if(ev.type == ConfigureNotify) {
+ w = ev.xconfigure.width;
+ h = ev.xconfigure.height;
+ } else if(ev.type == MapNotify) {
+ break;
+ }
+ }
+
+ if(!xw.isfixed)
+ cresize(w, h);
+ else
+ cresize(xw.fw, xw.fh);
+ ttynew();
+
gettimeofday(&lastblink, NULL);
gettimeofday(&last, NULL);
@@ -3685,10 +3703,7 @@ run:
XSetLocaleModifiers("");
tnew(80, 24);
xinit();
- ttynew();
selinit();
- if(xw.isfixed)
- cresize(xw.h, xw.w);
run();
return 0;
--
1.7.10.4
Re: [dev] st: Large pile of code
2013/4/25 Roberto E. Vargas Caballero : > When you want pass it any type of data? (of course, without using typeof) Do you already want it? Also, you can have multiple functions, as math.h does.
Re: [dev] st: Large pile of code
2013/4/25 Kent Overstreet : > So, to restate - code should be harder to understand to keep people > from contributing? Code should look compact to keep people from adding bloat. Multiple files by themselves add nothing to understanding, other than need to constantly switch contexts when one file's function is called from other file's.
Re: [dev] st: Large pile of code
There's no such thing as "doing it wrong", there are people who know how to use macros and people who do not. As suckless aims advanced users, I think we can safely assume that most people here know how to use them, and won't blow their leg off with it. Linux kernel can enjoy luxury of being compileable with one specific compiler (heck, there are specific CONFIG_ options just for gcc), but I'm afraid st cannot. Also, you are naming macros in lowercase, which is really bad, because macros are STILL not functions, and swap can STILL blow your leg off if, for example, contains index expression with side effect. Thus you should not make them look like functions, never. As for the swap: it is used once in the whole code. You introduced typeof for that and broken "declare all variables in function header" convention. Ain't broken, don't fix.
Re: [dev] st: Large pile of code
Personally, I suspect that this is not going to be positive change in long run. Dividing into multiple files lowers tolerance threshold for adding new code. If before that somebody would not add 500 sloc, no matter what, now he can convince yourself and others that it is REALLY useful, and make a new file just for that.
[dev] [st] [PATCH] Allow selecting single character.
Previously, when releasing Button 1, if only single character was
selected, selection was silently cleared. This is no longer the case with
this patch, which ensures more intuitive handling of this situation, while
still providing a way of clearing selection.
---
st.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/st.c b/st.c
index b0d0cb0..58e9b1b 100644
--- a/st.c
+++ b/st.c
@@ -138,6 +138,11 @@ enum selection_type {
SEL_RECTANGULAR = 2
};
+enum selection_mode {
+ SEL_START = 1,
+ SEL_ACTIVE = 2
+};
+
enum selection_snap {
SNAP_WORD = 1,
SNAP_LINE = 2
@@ -689,6 +694,7 @@ getbuttoninfo(XEvent *e) {
int type;
uint state = e->xbutton.state &~Button1Mask;
+ sel.mode = SEL_ACTIVE;
sel.alt = IS_SET(MODE_ALTSCREEN);
sel.ex = x2col(e->xbutton.x);
@@ -779,7 +785,7 @@ bpress(XEvent *e) {
tsetdirt(sel.b.y, sel.e.y);
draw();
}
- sel.mode = 1;
+ sel.mode = SEL_START;
sel.type = SEL_REGULAR;
sel.ex = sel.bx = x2col(e->xbutton.x);
sel.ey = sel.by = y2row(e->xbutton.y);
@@ -806,10 +812,11 @@ bpress(XEvent *e) {
sel.e.y = sel.ey;
/*
-* Draw selection, unless it's regular and we don't want to
-* make clicks visible
+* Draw selection, unless it's regular and it is unclear
+* if user intended to select or merely clicked
*/
if (sel.snap != 0) {
+ sel.mode = SEL_ACTIVE;
tsetdirt(sel.b.y, sel.e.y);
draw();
}
@@ -987,14 +994,14 @@ brelease(XEvent *e) {
if(e->xbutton.button == Button2) {
selpaste(NULL);
} else if(e->xbutton.button == Button1) {
- sel.mode = 0;
- getbuttoninfo(e);
- term.dirty[sel.ey] = 1;
- if(sel.bx == sel.ex && sel.by == sel.ey) {
+ if(sel.mode == SEL_START) {
sel.bx = -1;
} else {
+ getbuttoninfo(e);
selcopy();
}
+ sel.mode = 0;
+ term.dirty[sel.ey] = 1;
}
}
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Roberto E. Vargas Caballero : > > I can not see your patch, I only can see you send twice the same patch, > maybe did you mistake the second mail? > Yeah, sorry, accidentally sent the same patch two times. Now it should be correct, I think.
[dev] [st] [PATCH] Clear selection when tclearregion() touches its range.
---
st.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/st.c b/st.c
index 11b9b51..7e79358 100644
--- a/st.c
+++ b/st.c
@@ -1425,6 +1425,9 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(x = x1; x <= x2; x++) {
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, " ", 2);
+ if(selected(x, y)) {
+ sel.bx = -1;
+ }
}
}
}
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Roberto E. Vargas Caballero :
> You are talking here about our Selection data structure, and you are right,
> if we mark it as not enabled (sel.bx = -1), all the problem will be fixed,
> and maybe in a cleaner way.
> We can test it in tclearregion in this form:
>
>
>
> for(y = y1; y <= y2; y++) {
> term.dirty[y] = 1;
> for(x = x1; x <= x2; x++) {
> if(selected(y, x))
> selclear(NULL);
> term.line[y][x] = term.c.attr;
> memcpy(term.line[y][x].c, " ", 2);
> }
> }
>
>
> If all the people like this solution, I can send the patch.
Too late -- I already sent almost that exact patch :P.
Yes, I think this is the right thing to do, because st currently
clears selection on putting character inside it. So, changing a
characted with tclearregion() should clear it as well.
[dev] [st] [PATCH] Removed redundant check in draw code.
We're now clearing empty areas with spaces, so there is no point to check
if character contains non-empty string.
---
st.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 71e5b83..11b9b51 100644
--- a/st.c
+++ b/st.c
@@ -3077,7 +3077,7 @@ drawregion(int x1, int y1, int x2, int y2) {
ic = ib = ox = 0;
for(x = x1; x < x2; x++) {
new = term.line[y][x];
- if(ena_sel && *(new.c) && selected(x, y))
+ if(ena_sel && selected(x, y))
new.mode ^= ATTR_REVERSE;
if(ib > 0 && (ATTRCMP(base, new)
|| ib >= DRAW_BUF_SIZ-UTF_SIZ)) {
--
1.7.10.4
[dev] [st] [PATCH] Removed redundant check in draw code.
We're now clearing empty areas with spaces, so there is no point to check
if character contains non-empty string.
---
st.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 71e5b83..11b9b51 100644
--- a/st.c
+++ b/st.c
@@ -3077,7 +3077,7 @@ drawregion(int x1, int y1, int x2, int y2) {
ic = ib = ox = 0;
for(x = x1; x < x2; x++) {
new = term.line[y][x];
- if(ena_sel && *(new.c) && selected(x, y))
+ if(ena_sel && selected(x, y))
new.mode ^= ATTR_REVERSE;
if(ib > 0 && (ATTRCMP(base, new)
|| ib >= DRAW_BUF_SIZ-UTF_SIZ)) {
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Random832 : > On 04/23/2013 05:27 PM, Roberto E. Vargas Caballero wrote: >> >> It is very confusing see a hightlight blank line, that really is selecting >> the previous content of the line. If the selecting mark keeps in the >> screen >> it is only some garbage in it. If you can find other terminal emulator >> with >> this behaviour please let me know it. >> > Maybe the behavior is wrong - but if the problem is that it is _still > selected_ (i.e. hilight goes away when you select something else), it's not > something that can be solved with anything to do with visual attributes > only. > > That was why I was asking for clarification whether it is _still selected_, > or just _still hilighted_. > > I wasn't able to view the video or run st at the time when you posted the > video... now I've run st and confirmed that the problem is that it is _still > selected_. I can work on a patch to fix this today. > > This really has nothing to do with the visual attribute, it's that the logic > for removing the selection when its content changes (whether by erasing or > by text being printed within it) is broken or missing. First, thanks k0ga for reporting redundant 'if' predicate. Second, yes, this is correct, the code for clearing the selection when something is printed into it is currently absent, although should be relatively easy to add.
Re: [dev] [st] Need help implementing combining characters
2013/4/22 Alexander Sedov : > URxvt uses another approach that can be summarized as "do Xft > work" (by looking throughout URxvt code base, one understands that > they are really tired of this shit; transparency support in Xft, for > example, is yet another wonder, and we're lucky we ain't touching it). > They create buffer for XftGlyphSpec and then proceed manually getting > extents for each character and forcing it into appropriate, > hand-calculated coordinates. This seems to work. Looks like I lied. What they do is drawing all combined runes on top of each other, first with fg, bg and others with fg, Color_none. They also replace combined rune pair with one rune from PRIVATE_USE when writing text to a terminal and then expanding it elsewhere, but that's irrelevant. So, the only solution I see here is write a specific function for drawing one combined character sequence and always break normal drawing on them. May be slow, but at least it will work. Fuck you, Xft. -- Best regards, Alexander Sedov.
Re: [dev] [st] Need help implementing combining characters
Okay, so the rendering is expectedly nearly as before. The real problem we have here is that most TrueType monospace font designers do not care about combining characters, as opposed to X font designers. (Saying about which, X font support in st is now HORRIBLY broken for me for some arcane reason). Qouting for example DejaVu page on topic: http://dejavu-fonts.org/wiki/Typography : > In DejaVu Sans Mono combining marks look like any other monospaced glyph GTK+ apps use Pango library for magical work around this unfortunate fact. URxvt uses another approach that can be summarized as "do Xft work" (by looking throughout URxvt code base, one understands that they are really tired of this shit; transparency support in Xft, for example, is yet another wonder, and we're lucky we ain't touching it). They create buffer for XftGlyphSpec and then proceed manually getting extents for each character and forcing it into appropriate, hand-calculated coordinates. This seems to work.
[dev] [dmenu] [PATCH] Added -d delim option.
Allows to configure which characters are used for tokenizing input string.
Passing empty string disables tokenizing.
---
This is the patch that adds configurable behaviour for this feature.
If maintainer feels like including it in upstream, fine.
Else, topicstarter may download this email and apply it with git am,
and I'll add it into wiki after a short time.
dmenu.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dmenu.c b/dmenu.c
index a06ae15..05db5bf 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -40,6 +40,7 @@ static void run(void);
static void setup(void);
static void usage(void);
+static const char *delim = " ";
static char text[BUFSIZ] = "";
static int bh, mw, mh;
static int inputw, promptw;
@@ -82,6 +83,8 @@ main(int argc, char *argv[]) {
else if(i+1 == argc)
usage();
/* these options take one argument */
+ else if(!strcmp(argv[i], "-d"))
+ delim = argv[++i];
else if(!strcmp(argv[i], "-l")) /* number of lines in
vertical list */
lines = atoi(argv[++i]);
else if(!strcmp(argv[i], "-p")) /* adds prompt to left of
input field */
@@ -405,7 +408,7 @@ match(void) {
strcpy(buf, text);
/* separate input text into tokens to be matched individually */
- for(s = strtok(buf, " "); s; tokv[tokc-1] = s, s = strtok(NULL, " "))
+ for(s = strtok(buf, delim); s; tokv[tokc-1] = s, s = strtok(NULL,
delim))
if(++tokc > tokn && !(tokv = realloc(tokv, ++tokn * sizeof
*tokv)))
eprintf("cannot realloc %u bytes\n", tokn * sizeof
*tokv);
len = tokc ? strlen(tokv[0]) : 0;
@@ -612,7 +615,7 @@ setup(void) {
void
usage(void) {
- fputs("usage: dmenu [-b] [-f] [-i] [-l lines] [-p prompt] [-fn font]\n"
+ fputs("usage: dmenu [-b] [-f] [-i] [-d delim] [-l lines] [-p prompt]
[-fn font]\n"
" [-nb color] [-nf color] [-sb color] [-sf color]
[-v]\n", stderr);
exit(EXIT_FAILURE);
}
--
1.7.10.4
[dev] [st] [PATCH] Selection now handles empty lines less counter-intuitively.
Now, when you are selecting a region, you will get all empty lines that happen
to be in it, including trailing ones. Last line terminator is omitted as it
previously
was, though.
---
st.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/st.c b/st.c
index 27d0be8..44fffda 100644
--- a/st.c
+++ b/st.c
@@ -815,7 +815,7 @@ bpress(XEvent *e) {
void
selcopy(void) {
char *str, *ptr;
- int x, y, bufsize, isselected = 0, size;
+ int x, y, bufsize, size;
Glyph *gp, *last;
if(sel.bx == -1) {
@@ -826,7 +826,6 @@ selcopy(void) {
/* append every set & selected glyph to the selection */
for(y = sel.b.y; y < sel.e.y + 1; y++) {
- isselected = 0;
gp = &term.line[y][0];
last = gp + term.col;
@@ -837,8 +836,6 @@ selcopy(void) {
for(x = 0; gp <= last; x++, ++gp) {
if(!selected(x, y)) {
continue;
- } else {
- isselected = 1;
}
size = utf8size(gp->c);
@@ -855,7 +852,7 @@ selcopy(void) {
* st.
* FIXME: Fix the computer world.
*/
- if(isselected && y < sel.e.y)
+ if(y < sel.e.y)
*ptr++ = '\n';
}
*ptr = 0;
--
1.7.10.4
Re: [dev] [dmenu] What is the status of the project?
2013/4/17 Jente Hidskes : > I see you are open for patches now. Have you heard of the xyw offsets patch? > It allows to you, for example, have dmenu spawn in the center of the screen > at coördinates x and y, and width w. Note that the patch is not mine, I don't > know where I picked it up. I just made it apply to dmenu 4.5 That's what I meant to send instead of wmii patch. Sorry, must've pressed ^Y over wrong link.
Re: [dev] [dmenu] What is the status of the project?
2013/4/17 Hiltjo Posthuma : > Hehe, just to clarify: the patch I submitted which adds mouse support > is not meant to be included in the upstream dmenu, because I think > most people won't like it. However you're free to do whatever you want > with it. That's rather surprising, as I found it small and useful. (Especially the scroll feature). As Martti said, if you don't want a patch to be in upstream, you can commit to the wiki.
Re: [dev] [PATCH] dmenu_run: Don't leave a shell running
2013/4/16 Ross Lagerwall : > How did it handle command-line arguments before? > Command-line arguments are passed to dmenu as before. > Running "dmenu_run -b" would pass the -b to dmenu. > > AFAICT, the pipeline outputs an executable with no other arguments. I mean, previously I could write 'gimp Images/01.png' in dmenu, and it would run. Now, it won't. If I wanted spaces in commands, I could've escaped them. I think something along the lines of eval "exec "$(dmenu_path|dmenu "$@") would be better.
Re: [dev] [PATCH] dmenu_run: Don't leave a shell running
2013/4/16 Ross Lagerwall :
> The previous logic leaves a shell running for the duration that the
> launched application runs.
> This changes it so that the only application that is left running is
> the launched application.
>
> In addition, it can now handle launching applications with spaces in
> the filename.
> ---
> dmenu_run | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dmenu_run b/dmenu_run
> index 834ede5..191d4db 100755
> --- a/dmenu_run
> +++ b/dmenu_run
> @@ -1,2 +1,2 @@
> #!/bin/sh
> -dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &
> +exec "$(dmenu_path | dmenu "$@")"
> --
> 1.8.2.1
>
...and cannot handle command-line arguments anymore.
Re: [dev] [st] wide characters
2013/4/15 Strake :
> On 15/04/2013, random...@fastmail.us wrote:
>> On Mon, Apr 15, 2013, at 10:58, Martti Kühne wrote:
>>> According to a quick google those chars can become as wide as 6
>>> bytes,
>>
>> No, they can't. I have no idea what your source on this is.
>
> In UTF-8 the maximum encoded character length is 6 bytes [1]
>
> [1] Linux docs: man 7 utf-8
>
> This is more than a four-byte integer ('‿')
>
1. That's outdated information. Unicode range was reduced since then.
2. That's relevant to multibyte characters, not to wide. Wide are
always fixed size.
Re: [dev] [st] wide characters
2013/4/15 Martti Kühne : > -1 from me. > It is utter madness to waste 32 (64 on x86_64) bits for a single > glyph. According to a quick google those chars can become as wide as 6 > bytes, and believe me you don't want that, as long as there are > mblen(3) / mbrlen(3)... int is always 32 bits, and given we are already wasting that exact amount of space for each glyph (char[4]), your point is somewhat weak. I think the real reason is future diacritics support and potential abitily to store multiple runes at one glyph.
Re: [dev] [st] [PATCH] Got rid of Glyph state, because it was redundant anyway.
Before anyone tries to apply this: this patch is incorrect, use the one that has been sent later, or else you might and will experience horrible segfaults. I'm really sorry.
[dev] [st] [PATCH] Got rid of redundant Glyph state.
Now, newly allocated Glyphs are set to spaces and current cursor colors
with tclearregion() routine.
---
st.c | 79 --
1 file changed, 34 insertions(+), 45 deletions(-)
diff --git a/st.c b/st.c
index fc07a46..ec5d828 100644
--- a/st.c
+++ b/st.c
@@ -98,11 +98,6 @@ enum cursor_state {
CURSOR_ORIGIN = 2
};
-enum glyph_state {
- GLYPH_SET = 1,
- GLYPH_DIRTY = 2
-};
-
enum term_mode {
MODE_WRAP= 1,
MODE_INSERT = 2,
@@ -154,7 +149,6 @@ typedef struct {
uchar mode; /* attribute flags */
ushort fg; /* foreground */
ushort bg; /* background */
- uchar state; /* state flags*/
} Glyph;
typedef Glyph *Line;
@@ -757,7 +751,7 @@ bpress(XEvent *e) {
void
selcopy(void) {
- char *str, *ptr, *p;
+ char *str, *ptr;
int x, y, bufsize, isselected = 0, size;
Glyph *gp, *last;
@@ -773,8 +767,8 @@ selcopy(void) {
gp = &term.line[y][0];
last = gp + term.col;
- while(--last >= gp && !((last->state & GLYPH_SET) && \
- selected(last - gp, y) &&
strcmp(last->c, " ") != 0))
+ while(--last >= gp && !(selected(last - gp, y) && \
+ strcmp(last->c, " ") != 0))
/* nothing */;
for(x = 0; gp <= last; x++, ++gp) {
@@ -784,9 +778,8 @@ selcopy(void) {
isselected = 1;
}
- p = (gp->state & GLYPH_SET) ? gp->c : " ";
- size = utf8size(p);
- memcpy(ptr, p, size);
+ size = utf8size(gp->c);
+ memcpy(ptr, gp->c, size);
ptr += size;
}
@@ -943,13 +936,11 @@ brelease(XEvent *e) {
} else if(TIMEDIFF(now, sel.tclick1) <=
doubleclicktimeout) {
/* double click to select word */
sel.bx = sel.ex;
- while(sel.bx > 0 &&
term.line[sel.ey][sel.bx-1].state & GLYPH_SET &&
-
term.line[sel.ey][sel.bx-1].c[0] != ' ') {
+ while(sel.bx > 0 &&
term.line[sel.ey][sel.bx-1].c[0] != ' ') {
sel.bx--;
}
sel.b.x = sel.bx;
- while(sel.ex < term.col-1 &&
term.line[sel.ey][sel.ex+1].state & GLYPH_SET &&
-
term.line[sel.ey][sel.ex+1].c[0] != ' ') {
+ while(sel.ex < term.col-1 &&
term.line[sel.ey][sel.ex+1].c[0] != ' ') {
sel.ex++;
}
sel.e.x = sel.ex;
@@ -1374,7 +1365,6 @@ tsetchar(char *c, Glyph *attr, int x, int y) {
term.dirty[y] = 1;
term.line[y][x] = *attr;
memcpy(term.line[y][x].c, c, UTF_SIZ);
- term.line[y][x].state |= GLYPH_SET;
}
void
@@ -1396,7 +1386,6 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(x = x1; x <= x2; x++) {
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, " ", 2);
- term.line[y][x].state |= GLYPH_SET;
}
}
}
@@ -2264,11 +2253,12 @@ tputc(char *c, int len) {
int
tresize(int col, int row) {
- int i, x;
+ int i;
int minrow = MIN(row, term.row);
int mincol = MIN(col, term.col);
int slide = term.c.y - row + 1;
bool *bp;
+ Line *orig;
if(col < 1 || row < 1)
return 0;
@@ -2304,10 +2294,6 @@ tresize(int col, int row) {
term.dirty[i] = 1;
term.line[i] = xrealloc(term.line[i], col * sizeof(Glyph));
term.alt[i] = xrealloc(term.alt[i], col * sizeof(Glyph));
- for(x = mincol; x < col; x++) {
- term.line[i][x].state = 0;
- term.alt[i][x].state = 0;
- }
}
/* allocate any new rows */
@@ -2332,6 +2318,17 @@ tresize(int col, int row) {
tsetscroll(0, row-1);
/* make use of the LIMIT in tmoveto */
tmoveto(term.c.x, term.c.y);
+ /* Clearing both screens */
+ orig = term.line;
+ do {
+ if(mincol < col && 0 < minrow) {
+ tclearregion(mincol, 0, col - 1, minrow - 1);
+ }
+ if(0 < col && minrow < row) {
+ tclearregion(0, minrow, col - 1, row - 1);
+
Re: [dev] Re: [dmenu] What is the status of the project?
> I'd love to see this one in mainline, despite it's title: > > http://tools.suckless.org/dmenu/patches/xmms-like_pattern_matching > > Sadly the wiki has no link to a current version: > > http://tools.suckless.org/dmenu/patches/dmenu-4.4-tok.diff > > I might be inclined to try porting it myself sooner than later, if there > is any chance it will be included. But i'd like to know because im a > little tight on time. Isn't multi-matching like this a default behaviour now?
Re: [dev] [dmenu] What is the status of the project?
I went through the mailing list archives since the date of last commit and collected all patches that seem relevant/interesting to me. Sorry if you have already seen some of these. http://lists.suckless.org/dev/1108/9114.html http://lists.suckless.org/dev/1110/9742.html http://lists.suckless.org/dev/1303/14982.html http://lists.suckless.org/dev/1304/15300.html
[dev] [dmenu] [PATCH] Configuration header file added.
---
Makefile |6 +-
config.def.h | 15 +++
dmenu.c | 10 ++
3 files changed, 22 insertions(+), 9 deletions(-)
create mode 100644 config.def.h
diff --git a/Makefile b/Makefile
index f011ad7..0f7dfbd 100644
--- a/Makefile
+++ b/Makefile
@@ -18,7 +18,11 @@ options:
@echo CC -c $<
@${CC} -c $< ${CFLAGS}
-${OBJ}: config.mk draw.h
+config.h:
+ @echo creating $@ from config.def.h
+ @cp config.def.h $@
+
+${OBJ}: config.h config.mk draw.h
dmenu: dmenu.o draw.o
@echo CC -o $@
diff --git a/config.def.h b/config.def.h
new file mode 100644
index 000..35fc227
--- /dev/null
+++ b/config.def.h
@@ -0,0 +1,15 @@
+/* See LICENSE file for copyright and license details. */
+/* vim: expandtab
+ */
+/* Default settings; can be overrided by command line. */
+
+static Bool topbar = True; /* -b option; if False, dmenu
appears at bottom */
+static const char *font = NULL; /* -fn option; default X11 font or
font set */
+static const char *prompt = NULL; /* -p option; prompt to the elft
of input field */
+static const char *normbgcolor = "#22"; /* -nb option; normal background
*/
+static const char *normfgcolor = "#bb"; /* -nf option; normal foreground
*/
+static const char *selbgcolor = "#005577"; /* -sb option; selected background
*/
+static const char *selfgcolor = "#ee"; /* -sf option; selected foreground
*/
+/* -l option; if nonzero, dmenu uses vertical list with given number of lines
*/
+static unsigned int lines = 0;
+
diff --git a/dmenu.c b/dmenu.c
index 86f8c46..b750a46 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -43,17 +43,9 @@ static char text[BUFSIZ] = "";
static int bh, mw, mh;
static int inputw, promptw;
static size_t cursor = 0;
-static const char *font = NULL;
-static const char *prompt = NULL;
-static const char *normbgcolor = "#22";
-static const char *normfgcolor = "#bb";
-static const char *selbgcolor = "#005577";
-static const char *selfgcolor = "#ee";
-static unsigned int lines = 0;
static unsigned long normcol[ColLast];
static unsigned long selcol[ColLast];
static Atom clip, utf8;
-static Bool topbar = True;
static DC *dc;
static Item *items = NULL;
static Item *matches, *matchend;
@@ -61,6 +53,8 @@ static Item *prev, *curr, *next, *sel;
static Window win;
static XIC xic;
+#include "config.h"
+
static int (*fstrncmp)(const char *, const char *, size_t) = strncmp;
static char *(*fstrstr)(const char *, const char *) = strstr;
--
1.7.10.4
Re: [dev] [dmenu] What is the status of the project?
2013/4/15 Anselm R Garbe : > Hi, > > I'm the current maintainer of dmenu. > > I intend to get dmenu and dwm back on track during the next days. So feel > free to compile me a mail with all the patches you want to see in mainline > dmenu. Glad to hear this! Is it fine if I send you links to mailing archives?
[dev] [st] [PATCH] Added support for double/triple click+dragging.
Now double-click+dragging automatically snaps both ends to word boundaries
(unless on series of spaces), and triple-click selects whole lines.
As a side effect, snapping now occurs on button press, not button release
like it previously was, but I hope that won't be inconvenient for anyone.
---
st.c | 90 ++
1 file changed, 63 insertions(+), 27 deletions(-)
diff --git a/st.c b/st.c
index 73099a6..a164bfb 100644
--- a/st.c
+++ b/st.c
@@ -135,6 +135,11 @@ enum selection_type {
SEL_RECTANGULAR = 2
};
+enum selection_snap {
+ SNAP_WORD = 1,
+ SNAP_LINE = 2
+};
+
/* bit macro */
#undef B0
enum { B0=1, B1=2, B2=4, B3=8, B4=16, B5=32, B6=64, B7=128 };
@@ -232,6 +237,7 @@ typedef struct {
typedef struct {
int mode;
int type;
+ int snap;
int bx, by;
int ex, ey;
struct {
@@ -372,6 +378,7 @@ static void selinit(void);
static inline bool selected(int, int);
static void selcopy(void);
static void selscroll(int, int);
+static void selsnap(int, int *, int *, int);
static int utf8decode(char *, long *);
static int utf8encode(long *, char *);
@@ -658,6 +665,25 @@ selected(int x, int y) {
}
void
+selsnap(int mode, int *x, int *y, int direction) {
+ switch(mode) {
+ case SNAP_WORD:
+ while(*x > 0 && *x < term.col-1 && term.line[*y][*x +
direction].c[0] != ' ') {
+ *x += direction;
+ }
+ break;
+
+ case SNAP_LINE:
+ *x = (direction < 0) ? 0 : term.col - 1;
+ break;
+
+ default:
+ /* do nothing */
+ break;
+ }
+}
+
+void
getbuttoninfo(XEvent *e) {
int type;
uint state = e->xbutton.state &~Button1Mask;
@@ -667,6 +693,15 @@ getbuttoninfo(XEvent *e) {
sel.ex = x2col(e->xbutton.x);
sel.ey = y2row(e->xbutton.y);
+ if (sel.by < sel.ey
+ || (sel.by == sel.ey && sel.bx < sel.ex)) {
+ selsnap(sel.snap, &sel.bx, &sel.by, -1);
+ selsnap(sel.snap, &sel.ex, &sel.ey, +1);
+ } else {
+ selsnap(sel.snap, &sel.ex, &sel.ey, -1);
+ selsnap(sel.snap, &sel.bx, &sel.by, +1);
+ }
+
sel.b.x = sel.by < sel.ey ? sel.bx : sel.ex;
sel.b.y = MIN(sel.by, sel.ey);
sel.e.x = sel.by < sel.ey ? sel.ex : sel.bx;
@@ -730,9 +765,13 @@ mousereport(XEvent *e) {
void
bpress(XEvent *e) {
+ struct timeval now;
+
if(IS_SET(MODE_MOUSE)) {
mousereport(e);
} else if(e->xbutton.button == Button1) {
+ gettimeofday(&now, NULL);
+ /* Clear previous selection, logically and visually. */
if(sel.bx != -1) {
sel.bx = -1;
tsetdirt(sel.b.y, sel.e.y);
@@ -742,6 +781,30 @@ bpress(XEvent *e) {
sel.type = SEL_REGULAR;
sel.ex = sel.bx = x2col(e->xbutton.x);
sel.ey = sel.by = y2row(e->xbutton.y);
+ /*
+* Snap handling.
+* If user clicks are fasst enough (e.g. below timeouts),
+* we ignore if his hand slipped left or down and accidentally
selected more;
+* we are just snapping to whatever we're snapping.
+*/
+ if(TIMEDIFF(now, sel.tclick2) <= tripleclicktimeout) {
+ /* Snap to line */
+ sel.snap = SNAP_LINE;
+ } else if(TIMEDIFF(now, sel.tclick1) <= doubleclicktimeout) {
+ sel.snap = SNAP_WORD;
+ } else {
+ sel.snap = 0;
+ }
+ selsnap(sel.snap, &sel.bx, &sel.by, -1);
+ selsnap(sel.snap, &sel.ex, &sel.ey, 1);
+ sel.b.x = sel.bx, sel.b.y = sel.by, sel.e.x = sel.ex, sel.e.y =
sel.ey;
+ /* Draw selection, unless it's regular and we don't want to
make clicks visible */
+ if (sel.snap != 0) {
+ tsetdirt(sel.b.y, sel.e.y);
+ draw();
+ }
+ sel.tclick2 = sel.tclick1;
+ sel.tclick1 = now;
} else if(e->xbutton.button == Button4) {
ttywrite("\031", 1);
} else if(e->xbutton.button == Button5) {
@@ -910,8 +973,6 @@ xsetsel(char *str) {
void
brelease(XEvent *e) {
- struct timeval now;
-
if(IS_SET(MODE_MOUSE)) {
mousereport(e);
return;
@@ -925,35 +986,10 @@ brelease(XEvent *e) {
term.dirty[sel.ey] = 1;
if(sel.bx == sel.ex && sel.by == sel.ey) {
sel.bx = -1;
- gettimeofday(&now, NULL);
-
- if(TIMEDIFF(now, sel.tclick2) <= tripleclicktimeout) {
- /* triple click on the line *
[dev] [dmenu] What is the status of the project?
As per subject. It seems that last maintainer commit was an year ago, and patches sent to mailing list are left unresponded. In case this project has been orphaned, may I take over it? There is popular demand for being able to statically configure dmenu (e.g. to have config.h), security bug discovered by me, and mouse support patch by hiltjo, which is small and convenient. I think that the situation should be addressed.
[dev] [st] [PATCH] Got rid of Glyph state, because it was redundant anyway.
---
st.c | 73 +-
1 file changed, 28 insertions(+), 45 deletions(-)
diff --git a/st.c b/st.c
index fc07a46..73099a6 100644
--- a/st.c
+++ b/st.c
@@ -98,11 +98,6 @@ enum cursor_state {
CURSOR_ORIGIN = 2
};
-enum glyph_state {
- GLYPH_SET = 1,
- GLYPH_DIRTY = 2
-};
-
enum term_mode {
MODE_WRAP= 1,
MODE_INSERT = 2,
@@ -154,7 +149,6 @@ typedef struct {
uchar mode; /* attribute flags */
ushort fg; /* foreground */
ushort bg; /* background */
- uchar state; /* state flags*/
} Glyph;
typedef Glyph *Line;
@@ -757,7 +751,7 @@ bpress(XEvent *e) {
void
selcopy(void) {
- char *str, *ptr, *p;
+ char *str, *ptr;
int x, y, bufsize, isselected = 0, size;
Glyph *gp, *last;
@@ -773,8 +767,8 @@ selcopy(void) {
gp = &term.line[y][0];
last = gp + term.col;
- while(--last >= gp && !((last->state & GLYPH_SET) && \
- selected(last - gp, y) &&
strcmp(last->c, " ") != 0))
+ while(--last >= gp && !(selected(last - gp, y) && \
+ strcmp(last->c, " ") != 0))
/* nothing */;
for(x = 0; gp <= last; x++, ++gp) {
@@ -784,9 +778,8 @@ selcopy(void) {
isselected = 1;
}
- p = (gp->state & GLYPH_SET) ? gp->c : " ";
- size = utf8size(p);
- memcpy(ptr, p, size);
+ size = utf8size(gp->c);
+ memcpy(ptr, gp->c, size);
ptr += size;
}
@@ -943,13 +936,11 @@ brelease(XEvent *e) {
} else if(TIMEDIFF(now, sel.tclick1) <=
doubleclicktimeout) {
/* double click to select word */
sel.bx = sel.ex;
- while(sel.bx > 0 &&
term.line[sel.ey][sel.bx-1].state & GLYPH_SET &&
-
term.line[sel.ey][sel.bx-1].c[0] != ' ') {
+ while(sel.bx > 0 &&
term.line[sel.ey][sel.bx-1].c[0] != ' ') {
sel.bx--;
}
sel.b.x = sel.bx;
- while(sel.ex < term.col-1 &&
term.line[sel.ey][sel.ex+1].state & GLYPH_SET &&
-
term.line[sel.ey][sel.ex+1].c[0] != ' ') {
+ while(sel.ex < term.col-1 &&
term.line[sel.ey][sel.ex+1].c[0] != ' ') {
sel.ex++;
}
sel.e.x = sel.ex;
@@ -1374,7 +1365,6 @@ tsetchar(char *c, Glyph *attr, int x, int y) {
term.dirty[y] = 1;
term.line[y][x] = *attr;
memcpy(term.line[y][x].c, c, UTF_SIZ);
- term.line[y][x].state |= GLYPH_SET;
}
void
@@ -1396,7 +1386,6 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(x = x1; x <= x2; x++) {
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, " ", 2);
- term.line[y][x].state |= GLYPH_SET;
}
}
}
@@ -2264,7 +2253,7 @@ tputc(char *c, int len) {
int
tresize(int col, int row) {
- int i, x;
+ int i;
int minrow = MIN(row, term.row);
int mincol = MIN(col, term.col);
int slide = term.c.y - row + 1;
@@ -2304,10 +2293,6 @@ tresize(int col, int row) {
term.dirty[i] = 1;
term.line[i] = xrealloc(term.line[i], col * sizeof(Glyph));
term.alt[i] = xrealloc(term.alt[i], col * sizeof(Glyph));
- for(x = mincol; x < col; x++) {
- term.line[i][x].state = 0;
- term.alt[i][x].state = 0;
- }
}
/* allocate any new rows */
@@ -2332,6 +2317,12 @@ tresize(int col, int row) {
tsetscroll(0, row-1);
/* make use of the LIMIT in tmoveto */
tmoveto(term.c.x, term.c.y);
+ if(mincol < col && 0 < minrow) {
+ tclearregion(mincol, 0, col - 1, minrow - 1);
+ }
+ if(0 < col && minrow < row) {
+ tclearregion(0, minrow, col - 1, row - 1);
+ }
return (slide > 0);
}
@@ -2933,22 +2924,17 @@ void
xdrawcursor(void) {
static int oldx = 0, oldy = 0;
int sl;
- Glyph g = {{' '}, ATTR_NULL, defaultbg, defaultcs, 0};
+ Glyph g = {{' '}, ATTR_NULL, defaultbg, defaultcs};
LIMIT(oldx, 0, term.col-1);
LIMIT(oldy, 0,
[dev] [st] [PATCH] Got rid of code duplication in tnew() and tresize().
---
st.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/st.c b/st.c
index 56dc94c..fc07a46 100644
--- a/st.c
+++ b/st.c
@@ -1195,22 +1195,10 @@ treset(void) {
void
tnew(int col, int row) {
- /* set screen size */
- term.row = row;
- term.col = col;
- term.line = xmalloc(term.row * sizeof(Line));
- term.alt = xmalloc(term.row * sizeof(Line));
- term.dirty = xmalloc(term.row * sizeof(*term.dirty));
- term.tabs = xmalloc(term.col * sizeof(*term.tabs));
-
- for(row = 0; row < term.row; row++) {
- term.line[row] = xmalloc(term.col * sizeof(Glyph));
- term.alt [row] = xmalloc(term.col * sizeof(Glyph));
- term.dirty[row] = 0;
- }
-
+ /* setting "zero" terminal to resize it later */
+ memset(&term, 0, sizeof(Term));
+ tresize(col, row);
term.numlock = 1;
- memset(term.tabs, 0, term.col * sizeof(*term.tabs));
/* setup screen */
treset();
}
--
1.7.10.4
[dev] [st] [PATCH] Strip trailing spaces from lines when copying selection.
---
st.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 7250da2..56dc94c 100644
--- a/st.c
+++ b/st.c
@@ -773,7 +773,8 @@ selcopy(void) {
gp = &term.line[y][0];
last = gp + term.col;
- while(--last >= gp && !(last->state & GLYPH_SET))
+ while(--last >= gp && !((last->state & GLYPH_SET) && \
+ selected(last - gp, y) &&
strcmp(last->c, " ") != 0))
/* nothing */;
for(x = 0; gp <= last; x++, ++gp) {
--
1.7.10.4
Re: [dev] [st] pasting to gvim sucks
2013/4/13 Christoph Lohmann <2...@r-36.net>: > Greetings. > I merged the patches from the list and applied them. St now does on copy > replace ’\r’ with ’\n’ and when it receives some paste item ’\n’ is re‐ > placed with ’\r’. Thanks, that's much better than before! Every combination I'm aware of works now.
Re: [dev] [st] [PATCH] Clearer cursor style, like xterm
2013/4/12 Mark Hills : > I find when a window is un-focused that the cursor location looks too > much like display content. > > Please consider this patch, which mimics xterm behaviour by displaying > a hollow rectangle, and makes a saving of one colourmap entry :) st uses XRender throughout its source base, but that's probably fine. What confuses me is code complexity. Also, it is non-optional. Don't know if it is worth it.
Re: [dev] [st] windows port?
> Oh and, how comes you're writing a terminal emulator with your views? > Because writing stuff for geeks is easier? Hey, I'm not writing terminal emulator. I'm submitting patches to st and get shouted at by __20h__, and that's it. But the answer is: because writing stuff for myself is usually worth my time, and because, well, I'm not a professional programmer.
Re: [dev] [st] windows port?
> This. Knowledge and money do not correlate where I come from - how > else can those biggest idiots be so successful in capitalism? > Money in more ancient times was about trust, and you pay him because > you trust him with your health. So the doctor has, in that sense, as > much responsibility for your health as you pay him, except his taking > responsibility does not mean he can solve your health problem. > > Yes, apple do a comparably good job at taking responsibility and, > obviously, and then responding to issues. But in the case of M$ > Windows, you pay for a system that will likely abuse your cpu and > bandwidth for cyber crime and spyware which must be such a profitable > business that they are probably funding M$ by now, keeping up the > fishy business just a wee longer. Thanks to windows 8 the dark age may > finally have ended - when "no one" using this shit any more may become > true. Yeah, Win8 is pitiful, but Win7 was a great breakthrough compared to WinXP. Also, common sense protects you from spyware rather well. The bad thing is, I don't see any alternatives to Win7 for clueless user. MacOsX is just too expensive, "Ubuntu" is synonym for "unreliable", and other Linux distributions and OS like like FreeBSD still lack is usability and support. Hopefully everyone will eventually switch to Kolibri, but that's only my dream. > The first question you need to answer yourself is what are your > priorities. I'm currently working for non-engineers and have to > struggle for my sanity sometimes from all the FUD and need to find > something fun to tinker with. RADs are a great idea to work WITH, > except for the poor guy who needs to work AROUND them - and that's the > spot where code use, code reuse and code abuse will ever be done > wrong, just because Excel is good enough for a 3d rendering engine, > not many people have been using it as such. I guess Excel could boot > linux, if you ask it nicely enough. If you work with computers you'll > write programs that are useful and may use the subset of the features > an OS and an environment provides you with. The point is, how hard is > it for a programmer to write an alarm script based on cron and his > favorite music player, and then, exactly the opposite happens when you > switch the target audience, how in the world can you let a non-savvy > do that. Then we obviously need more .NET I'm not sure about needing more dotnet, but I'd like to point out that most programmers write stuff for non-programmers nowadays. So, letting non-savvy people do stuff is the new reality. About code reuse and code abuse, I couldn't agree more. > Stop asking the question in a way that requires .NET. Well, and then > there is scratch, obviously [1]. Where again, most people will give up > on scratch when they can't make things work like they have in mind, > because they just don't care to think about all the edge cases and > details they suddenly have to take care of. "If beer and women are not the answer, then you're asking wrong questions" :). >From my point of view, dotnet is mediocre realization of great idea: language interoperability by design and free JIT for everyone. The problem is, learning C# cannot make one a good programmer, I've seen many Javaists that have no frigging clue about what's call stack, how long does it take to compare strings, et cetera. Also, I've never seen any actual Scratch programs aside from short flash animations and "games". I'm rather surprised that something of this level of quality/usefulness originated in MIT.
Re: [dev] [st] windows port?
> Form your sentiment one gets impression that you think that situation is any > better with windows software, and if you tink like that thats not even funny. It's not better in average, yes. But dispersion is much greater. There are IE search bars and there are nice professional tools. And one usually avoids IE bars. > As for "normal users" they need a good kick in a nuts to wake up and learn to > learn tools that they use. If people got behind car wheel with atitude they > get > behind computer life would get terrible very quickly for everyone. As someone > in some comment on slashdot stated: computig is only field where people come > knowing nothing about it, work with computer for 10 years and still do no know > shit about thier tool. That is pathetic. No, they do not. Computers are complex. If you understand computing – or you think so – doesn't mean everybody should. They need to do what they need to do, not spending their time trying to figure how to do something with computer harder better faster stronger. Especially not reading those manual pages. Also, slashdot guy is wrong. Another example is buying physics against common cold, for example. > I bet my ass you have encounteres some "data entrants" in public places like > bank or some such where entran selects every field with fuckin mouse, cause > they cant bother to know that there ara button right under the finger that > tkes > one to next field. And I bet if you come to same entrant after couple of yers > he/she will still be doing same thing. Because a) they are accustomed to it, b) it works fine, c) nobody told them better? Also, I should say that most operators actually know about Tab. > Pandering to ignorance and "making things user friendly" does not solve shit. > Ever heard saying about making shit idiot proof? It's just a chalange for > nature to make better idiots. To improve society one needs to educati people. You want to make everyone major in CS? I got some news for you, I guess. Making things user friendly DOES solve shit, I'm talking from experience. There is a trend to use Ubuntu arising here, and Ubuntu breaks in such funny ways with almost every update that WinXP just chokes envily. And people say "hey, what the fuck is this shit", and they're back to Windows, where Microsoft ensures software compatibility and developers are not from Cloud Cuckoo Land, either. Those stong who survive are usually people who like programming to some extent. Or to Mac, y'know. My uncle uses Mac, and their support centers can do everything in a day. He even never upgrades his OS himself. I understand him, because nobody has got time for this shit out there. > Sure there is compasion and stuff, no everyone has time to achieve even > moderatly in depth knowledge of computers. But man things should have limits, > and sometimes it seems to me that in current world almost everyone is spouting > endless compasion. Or maybe just everyone likes the concept of non existent > personal responsibilty. And of course there always are such nice wendors like > apple who are there to "remove your confusion" for a price of course. I see nothing wrong in providing technical support for money. (And user-friendliness too). It's like taking advice from doctor: you pay for visit, although it seems that he has not done much. You pay him for the fact that he knows better than you. (Although Apple guys actually fix your stuff, eliminating the need to go to farmacy). If you can't bear the fact that somebody can know better, well, sucks to be you. To me, your mail is just another sign of elitism. "People are so fucking stupid, they can't use broken software! Come on, spend five years, learn something about computers!" Go tell your mom she needs to learn shit about Linux kernel, next time it breaks. Or that she needs to switch from Windows to OpenBSD because it's somehow better. You won't do this, right? So stop being a zealot. It does not suit you well.
[dev] [st] [PATCH] Switched a few things around to make pasting from/to GUI a bit better.
Now, on selcopy, st generates traditional Unix newlines ('\n'), because
apparently that's what GUI applications are used to see. But some
terminal applications do not handle '\n' very well, so, when pasting to st,
line feeds are replaced with carriage returns, codes that Return key generates.
---
st.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/st.c b/st.c
index 93058b9..726b8f9 100644
--- a/st.c
+++ b/st.c
@@ -790,7 +790,7 @@ selcopy(void) {
}
/* \n at the end of every selected line except for the
last one */
if(is_selected && y < sel.e.y)
- *ptr++ = '\r';
+ *ptr++ = '\n';
}
*ptr = 0;
}
@@ -801,7 +801,7 @@ void
selnotify(XEvent *e) {
ulong nitems, ofs, rem;
int format;
- uchar *data;
+ uchar *data, *repl, *last;
Atom type;
ofs = 0;
@@ -812,6 +812,14 @@ selnotify(XEvent *e) {
fprintf(stderr, "Clipboard allocation failed\n");
return;
}
+
+ /* Working around inconsistent behaviour of GUI and terminal
apps */
+ last = data + nitems * format / 8;
+ repl = data;
+ while((repl = memchr(repl, '\n', last - repl))) {
+ *repl++ = '\r';
+ }
+
ttywrite((const char *) data, nitems * format / 8);
XFree(data);
/* number of 32-bit chunks returned */
--
1.7.10.4
Re: [dev] [st] pasting to gvim sucks
> This is the reason why st is writing '\r', because is the code that is > generated when you press return. Yeah, it makes sense for pasting from st to st. But pasting from, for one, surf to st suffers from ^J instead of ^M (mcabber, nano, who knows what else), and pasting to file and, as topicstarter states, to gvim is pain, too. In text files, one usually sees ^J, so if selection is a chunk of data, I'd rather expect it to obey Unix newlines.
Re: [dev] [st] windows port?
Oh, look, how nice, religious wars at dev@suckless, and my favourite "argument" about Windows being crappy operating system with absolutely no justification. Religious people never justify their views, I guess. About the "lock-in": drivers may be the case, but applications can not be "lock-in". If somebody goes and creates amazingly beautiful operating system called, for example, Plot C right now, incompatible with either Linux drivers (which KolibriOS for example is compatible with), Windows drivers, and every app out there in the world because it doesn't conform to outdated standards nor does it attempts to provide compatibility, and then he'll cry about how all users are locked in and nobody uses his beauty, I'll call him stupid. It's not "lock-in", it's he hasn't attempted to make his OS usable. Same thing applies, with two orders of magnitude lower, to Linux. Go open your package manager or open Github if you don't have one, and look what's there. Mostly some arcane shit, as fruitless as a proverbial fig tree, some clones of Windows apps, clones of clones of Windows apps, attempts to rewrite and revise libraries, magically make less buggy changing an API, and so on. We have so many music players, each better and slicker that others, but still unusable as hell. We have buggy applications written in GTK+ that crash depending on moon phase. We have I don't know how many libraries for data serialization and datetime handling and whatnot, and I'd bet fifty bucks that almost all of them started "this bloatware sucks, let's come with something simple and funny to write". All that unbearable crap actually helps greatly. If you do not give up trying to make all that shit actually kind of work, because their developers thought only about fun and elegance, not usability, you learn a lot of new things, and that's very cool. But it's not for normal people, no. It's either for masochists or elitists.
Re: [dev] [st] pasting to gvim sucks
> Maybe pasting to st should be fixed too, so when newlines are pasted, > they are translated to ^M. But '\n' should be copied, otherwise pasting > to graphical programs is broken. That's how urxvt does it and this is what my patch originally done (sort of, translation was in ttywrite while in should've been in selection notify or whatever is it called), but __20h__ applied it that way. If someone would convince him, that would be great, because making files with xclip -o is also terrible now.
[dev] [surf] [PATCH] A typo in SETPROP macro: should be ``printf %b'', not ``printf''.
---
I'm sorry I introduced this bug.
config.def.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.def.h b/config.def.h
index 3ddfaf8..ed8fbbe 100644
--- a/config.def.h
+++ b/config.def.h
@@ -23,7 +23,7 @@ static Bool hidebackground = FALSE;
#define SETPROP(p, q) { \
.v = (char *[]){ "/bin/sh", "-c", \
- "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 printf |
dmenu`\" &&" \
+ "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 printf
%b | dmenu`\" &&" \
"xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
p, q, winid, NULL \
} \
--
1.7.10.4
[dev] [dmenu] [PATCH] Fix buffer overrun problem on Tab keypress.
---
When trying to Tab-complete on strings with length >= BUFSIZ, dmenu incorrectly
handles copying and then calls strlen() on non-null-terminated buffer.
On my system, this led to freeze rather that just crash, which is much worse
due to dmenu grabbing keyboard.
This patch fixes that behaviour with the most correct one.
An arguably better solution would be to use strlcpy() instead of strncpy(),
but it's not in POSIX, not in string.h, and requires -lbsd, all of which are
really sad.
dmenu.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dmenu.c b/dmenu.c
index 3962801..86f8c46 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -380,7 +380,8 @@ keypress(XKeyEvent *ev) {
case XK_Tab:
if(!sel)
return;
- strncpy(text, sel->text, sizeof text);
+ strncpy(text, sel->text, sizeof text - 1);
+ text[sizeof text - 1] = '\0';
cursor = strlen(text);
match();
break;
--
1.7.10.4
Re: [dev] [surf] [PATCH] Fixed SETPROP() macro behaviour in config.def.h to handle escapes correctly.
Let's face it: xargs default behaviour is not well-defined. It would probably work with xprop output, where quotes are escaped, but it's better not to risk. Also, we probably want to keep occasional spaces on their places. I believe that xargs implementation that doesn't implement -0 is unheard of. 2013/3/21 Joseph BOUDOU : > xargs -0 isn't POSIX neither. > > -- > Joseph BOUDOU >
[dev] [surf] [PATCH] Fixed SETPROP() macro behaviour in config.def.h to handle escapes correctly.
xprop prints information in format PROPERTY(STRING) = "escaped string",
which causes problem with repeated Ctrl-F: any non-ascii turns into
\ooo\ooo, this later turns into \\ooo\\ooo, and so on. To de-escape
string, printf(1) is used, getting information from xargs -0; without -0
xargs will try to handle escapes by itself and also do shenanigans
with quotes, which is totally undesired.
---
config.def.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.def.h b/config.def.h
index 052313c..3ddfaf8 100644
--- a/config.def.h
+++ b/config.def.h
@@ -23,7 +23,7 @@ static Bool hidebackground = FALSE;
#define SETPROP(p, q) { \
.v = (char *[]){ "/bin/sh", "-c", \
- "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | dmenu`\" &&" \
+ "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 printf |
dmenu`\" &&" \
"xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
p, q, winid, NULL \
} \
--
1.7.10.4
Re: [dev] [surf] [PATCH] Fixed SETPROP() macro behaviour in config.def.h to handle escapes correctly.
2013/3/21 Nick : > On Thu, Mar 21, 2013 at 07:26:23PM +0400, Alexander Sedov wrote: > Can this be done with printf? ISTR echo -en isn't posix, whereas > printf is well defined. You make a point.
Re: [dev][surf] [PATCH] Disabling WebKit deletion interface feature by default.
2013/3/15 Christoph Lohmann <2...@r-36.net>: > Greetings. > I need a screenshot to apply this, because I’ve never seen this. Here you go. This is Gmail interface screenshot, but it appears on some other sites as well. Reasons why it does seem to be not connected to sites itself, but rather to some weird heuristics. <>
[dev] [surf] [PATCH] Fixed SETPROP() macro behaviour in config.def.h to handle escapes correctly.
xprop prints information in format PROPERTY(STRING) = "escaped string",
which causes problem with repeated Ctrl-F: any non-ascii turns into
\ooo\ooo, this later turns into \\ooo\\ooo, and so on. To de-escape
string, echo -en is used, getting information from xargs -0; without
-0 xargs will try to handle escapes by itself and also do shenanigans
with quotes, which is totally undesired.
---
config.def.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.def.h b/config.def.h
index 052313c..3ddd6d7 100644
--- a/config.def.h
+++ b/config.def.h
@@ -23,7 +23,7 @@ static Bool hidebackground = FALSE;
#define SETPROP(p, q) { \
.v = (char *[]){ "/bin/sh", "-c", \
- "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | dmenu`\" &&" \
+ "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 echo -en
| dmenu`\" &&" \
"xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
p, q, winid, NULL \
} \
--
1.7.10.4
[dev] [st] [PATCH] Making rectangular selection actually work.
---
st.c |4
1 file changed, 4 deletions(-)
diff --git a/st.c b/st.c
index 0923cec..9f0474d 100644
--- a/st.c
+++ b/st.c
@@ -652,10 +652,6 @@ selected(int x, int y) {
return BETWEEN(x, bx, ex);
}
- return ((sel.b.y < y && y < sel.e.y)
- || (y == sel.e.y && x <= sel.e.x))
- || (y == sel.b.y && x >= sel.b.x
- && (x <= sel.e.x || sel.b.y != sel.e.y));
switch(sel.type) {
case SEL_REGULAR:
return ((sel.b.y < y && y < sel.e.y)
--
1.7.10.4
Re: [dev] [st] clipboard selection behavior (patch applied)
When selecting text, st provides result in *both* PRIMARY and CLIPBOARD. 2013/3/16 Uli Armbruster : > * Alexander Sedov [15.03.2013 09:31]: >> clippaste() is meant for CLIPBOARD. >> For PRIMARY, it has selpaste(). > > Ok, thanks! > > Then what's the correct way to make st use PRIMARY when text is selected? >
[dev][surf] [PATCH] Disabling WebKit deletion interface feature by default.
Webkit has an amazing "feature" that shows black outline with cross
around some randomly chosen text fields. Its only fucntion is to
clear field. It's ugly and gets in the way when trying to actually
ready what you've written, so here's a patch to disable it.
---
surf.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/surf.c b/surf.c
index 830665a..62f7114 100644
--- a/surf.c
+++ b/surf.c
@@ -105,6 +105,8 @@ static gboolean decidedownload(WebKitWebView *v,
WebKitWebFrame *f,
static gboolean decidewindow(WebKitWebView *v, WebKitWebFrame *f,
WebKitNetworkRequest *r, WebKitWebNavigationAction *n,
WebKitWebPolicyDecision *p, Client *c);
+static gboolean deletion_interface(WebKitWebView *view,
+ WebKitDOMHTMLElement *arg1, Client *c);
static void destroyclient(Client *c);
static void destroywin(GtkWidget* w, Client *c);
static void die(const char *errstr, ...);
@@ -369,6 +371,12 @@ decidewindow(WebKitWebView *view, WebKitWebFrame *f,
WebKitNetworkRequest *r,
return FALSE;
}
+static gboolean
+deletion_interface(WebKitWebView *view,
+ WebKitDOMHTMLElement *arg1, Client *c) {
+ return FALSE;
+}
+
static void
destroyclient(Client *c) {
Client *p;
@@ -696,6 +704,9 @@ newclient(void) {
g_signal_connect(G_OBJECT(c->view),
"resource-request-starting",
G_CALLBACK(beforerequest), c);
+ g_signal_connect(G_OBJECT(c->view),
+ "should-show-delete-interface-for-element",
+ G_CALLBACK(deletion_interface), c);
/* Scrolled Window */
c->scroll = gtk_scrolled_window_new(NULL, NULL);
--
1.7.10.4
Re: [dev][surf] [PATCH] Fixed keys handling for multilayout environments.
2013/3/15 : > Does this mean that with cyrillic layout, mappings defined as GDK_r > would work? > > If this is the case -- thank youvery much for hounding down and fixing! > This has annoyed me for a long time. This will cause me to put some work > in updating my ancient heavily patched surf in the next days. Yes, this is the exact case I was aiming for. You're welcome.
[dev][surf] [PATCH] Fixed keys handling for multilayout environments.
There is a bug in GTK+ that does not allow capturing shortcuts using
letter keys on layouts other than "us". The bug is there for ages and
there is probably no hope that it will get fixed. This patch switches
shortcut handling method to GtkAccelGroup, which handles this case
correctly. Enjoy!
---
surf.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/surf.c b/surf.c
index 830665a..c5755ab 100644
--- a/surf.c
+++ b/surf.c
@@ -80,6 +80,7 @@ static gboolean usingproxy = 0;
static char togglestat[6];
static char pagestat[3];
+static void add_accels(Client *c);
static void beforerequest(WebKitWebView *w, WebKitWebFrame *f,
WebKitWebResource *r, WebKitNetworkRequest *req,
WebKitNetworkResponse *resp, gpointer d);
@@ -124,7 +125,9 @@ static gboolean inspector_show(WebKitWebInspector *i,
Client *c);
static gboolean inspector_close(WebKitWebInspector *i, Client *c);
static void inspector_finished(WebKitWebInspector *i, Client *c);
-static gboolean keypress(GtkWidget *w, GdkEventKey *ev, Client *c);
+static gboolean keypress(GtkAccelGroup *group,
+ GObject *obj, guint key, GdkModifierType mods,
+ Client *c);
static void linkhover(WebKitWebView *v, const char* t, const char* l,
Client *c);
static void loadstatuschange(WebKitWebView *view, GParamSpec *pspec,
@@ -166,6 +169,18 @@ static void zoom(Client *c, const Arg *arg);
#include "config.h"
static void
+add_accels(Client *c) {
+ int i;
+ GtkAccelGroup *group = gtk_accel_group_new();
+ for(i = 0; i < LENGTH(keys); i++) {
+ GClosure *closure = g_cclosure_new(G_CALLBACK(keypress), c,
NULL);
+ gtk_accel_group_connect(group, keys[i].keyval, keys[i].mod,
+ 0, closure);
+ }
+ gtk_window_add_accel_group(GTK_WINDOW(c->win), group);
+}
+
+static void
beforerequest(WebKitWebView *w, WebKitWebFrame *f, WebKitWebResource *r,
WebKitNetworkRequest *req, WebKitNetworkResponse *resp,
gpointer d) {
@@ -514,14 +529,17 @@ inspector_finished(WebKitWebInspector *i, Client *c) {
}
static gboolean
-keypress(GtkWidget* w, GdkEventKey *ev, Client *c) {
+keypress(GtkAccelGroup *group, GObject *obj,
+ guint key, GdkModifierType mods, Client *c) {
guint i;
gboolean processed = FALSE;
+ mods = CLEANMASK(mods);
+ key = gdk_keyval_to_lower(key);
updatewinid(c);
for(i = 0; i < LENGTH(keys); i++) {
- if(gdk_keyval_to_lower(ev->keyval) == keys[i].keyval
- && CLEANMASK(ev->state) == keys[i].mod
+ if(key == keys[i].keyval
+ && mods == keys[i].mod
&& keys[i].func) {
keys[i].func(c, &(keys[i].arg));
processed = TRUE;
@@ -645,9 +663,7 @@ newclient(void) {
"destroy",
G_CALLBACK(destroywin), c);
if(!kioskmode) {
- g_signal_connect(G_OBJECT(c->win),
- "key-press-event",
- G_CALLBACK(keypress), c);
+ add_accels(c);
}
/* Pane */
--
1.7.10.4
Re: [dev] [st] clipboard selection behavior (patch applied)
clippaste() is meant for CLIPBOARD. For PRIMARY, it has selpaste(). 2013/3/15 Uli Armbruster : > Hi guys! > > First of all, don't kill me if the patch isn't perfect, because I'm not > really a coder (but use suckless software nevertheless)! But this patch is > trivial enough. Actually it's the first time ever that I provide a patch! :) > > I discovered that for selected text st uses the CLIPBOARD selection. Me > coming from rxvt-unicode, I was used to PRIMARY selection in this case and > frankly, I think it makes more sense. I think this should be configurable > with the config.h. That's what my patch changes. > > Best > Army
[dev][st] [PATCH] Fix output redirection in surf-open.sh
Incorrect order of output rediection specifiers was causing useless text appearing in terminal when starting surf-open (for example, BadWindow error from xprop when tabbed window is already closed). It isn't now. --- surf-open.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/surf-open.sh b/surf-open.sh index 29036f8..c22edc2 100755 --- a/surf-open.sh +++ b/surf-open.sh @@ -21,12 +21,12 @@ then runtabbed else xid=$(cat "$xidfile") - xprop -id "$xid" 2>&1 >/dev/null + xprop -id "$xid" >/dev/null 2>&1 if [ $? -gt 0 ]; then runtabbed else - surf -e "$xid" "$uri" 2>&1 >/dev/null & + surf -e "$xid" "$uri" >/dev/null 2>&1 & fi fi -- 1.7.10.4
[dev][surf] [PATCH] Added default font size setting.
Added font size option, because I think it's pretty common and useful.
Full-featured font options are probably not worth doing, though.
---
config.def.h |2 ++
surf.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/config.def.h b/config.def.h
index 85bfe47..90f8d5b 100644
--- a/config.def.h
+++ b/config.def.h
@@ -19,6 +19,8 @@ static Bool enableinspector = TRUE;
static Bool loadimages = TRUE;
static Bool hidebackground = FALSE;
+static guint font_size = 12;
+
#define SETPROP(p, q) { \
.v = (char *[]){ "/bin/sh", "-c", \
"prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | dmenu`\" &&" \
diff --git a/surf.c b/surf.c
index ee4ab75..8c29148 100644
--- a/surf.c
+++ b/surf.c
@@ -752,6 +752,8 @@ newclient(void) {
enableinspector, NULL);
g_object_set(G_OBJECT(settings), "enable-default-context-menu",
kioskmode ^ 1, NULL);
+ g_object_set(G_OBJECT(settings), "default-font-size",
+ font_size, NULL);
if(enableinspector) {
c->inspector = WEBKIT_WEB_INSPECTOR(
--
1.7.10.4
Re: [dev] [dmenu] sorted unlimited history
Chris, functionality that you demand could easily be provided by this simple script. Syntax is obvious and even described inside the script. Enjoy! https://gist.github.com/ElectronicRU/5138928 2013/3/12 Chris Johnson : > I thought of the check for whether or not it exists when I was working on > it, but I wasn't sure what all to check for. I only use it to run > executable files so for my case it's easy, but I wasn't sure what all might > get put in there. When I asked in the irc channel there was some mention of > things other than files that would show up in the list, so I decided not to > worry about the check and let the user prune bogus history items some other > way. I think someone put together an example to do the pruning that was > basically a one line bash script which could be run separately from dmenu > itself. > > > On Mon, Mar 11, 2013 at 4:37 PM, Peter Hartman > wrote: >> >> 2013/3/11 Chris Johnson : >> > I created a patch to have sorted (first by number of previous runs, then >> > by >> > most recent) and unlimited history. It is similar to the patch from >> > Peter >> > John Hartman, but modified in the following ways: >> >> Hi Chris, >> >> That's neat. I moved to using a shell script wrapper to dmenu to do >> history --- I believe those scripts are on the website --- but it >> won't do the neat trick of moving things to the top based on how often >> they are used. I'd advocate something like this get moved into dmenu >> tip. >> >> It'd also be nice (more generally, even without the history patch, but >> especially with it) to have a check to verify that the file still >> exists. For instance, I use the history feature on dmenu when I open >> pdf files on my system, e.g. [1] where .dmenu_cache_pdfs is generated >> via a cron script. But, of course, sometimes I will move or rename >> pdf files around, and then the history file will be all dumb. It'd be >> a one-line fix. >> >> [1] pdf-opener >> >> #!/bin/bash >> HISTFILE=~/.dmenu_cache_pdfs.hist >> CACHEFILE=~/.dmenu_cache_pdfs >> exe=$(tac $HISTFILE $CACHEFILE | sed 's|^/home/peterjh/||'| dmenu -p >> "*" -i -l 10) >> >> echo "$exe" >> case "$exe" in >> o*) opt="okular" >> exe=$(echo "$exe" | sed 's/^o //') >> ;; >> *) opt="mailcap" >> ;; >> esac >> >> if [ ! -f "/home/peterjh/$exe" ] ; then >> exit >> fi >> >> if [ $? -eq 0 ]; then >> exe="/home/peterjh/$exe" >> sed -i "\|$exe|d" $HISTFILE >> echo "$exe" >> $HISTFILE >> case "$opt" in >> okular) >> okular "$exe" & >> ;; >> mailcap) >> run-mailcap "$exe" & >> ;; >> esac >> fi >> >> >> >> >> -- >> sic dicit magister P >> Université du Québec à Montréal / Loyola University Chicago >> http://individual.utoronto.ca/peterjh >> gpg 1024D/ED6EF59B (7D1A 522F D08E 30F6 FA42 B269 B860 352B ED6E F59B) >> gpg --keyserver pgp.mit.edu --recv-keys ED6EF59B >> >
Re: [dev] [st] Two small patches for string handling.
It still conforms to C89/C99, which is the chosen standard for compiling st according to default config.mk. Also, good thing about separate patches is that you don't need to apply all of them. It looks like zero field handling was already casted upon strtok_r, although in slightly more complicated manner, so this patch is not really in great need to be applied. 2013/2/27 Roberto E. Vargas Caballero > > 1. Replaced strtok_r with strsep in strparse, because strsep can > handle > > zero-width fields (manpage says so) and because resulting code is > > clearer. > > As far as I know strsep is a BSD extension and it is not a POSIX function, > so I think we should look for other solution. > > > Best regards, > >
Re: [dev] [st] Two small patches for string handling.
Same things, with style error fixed. 2013/2/27 Alexander Sedov > 1. Replaced strtok_r with strsep in strparse, because strsep can handle > zero-width fields (manpage says so) and because resulting code is clearer. > 2. Fixed potential problem with calling strtol on non-null-terminated > buffer. > 0001-Replaced-strtok_r-with-strsep-for-correct-empty-fiel.patch Description: Binary data 0002-Fixed-various-bugs-with-CSI.patch Description: Binary data
Re: [dev] [st] strange behaviour with feh and ranger
I do believe the goal of this project is not writing rxvt clone, or "replacement", as you call it. Also, your description of a problem is twisted and seems to touch feh, not st. If urxvt works for you, use urxvt, it's a decent terminal emulator. 2013/2/26 Andreas Marschall > Good evening, > > I just tested the latest git version of st with feh, which is my image > viewer of choice, and ranger, which I sometimes use as file manager. st > behaves like this; > > when I open a folder of images in a simple st session and type: feh *.JPG > to see all images in that folder it opens up the first image in tiling mode > (tested with dwm and monsterwm). When I hit "v" to go to fullscreen the > image goes fullscreen but then nothing works anymore. The arrow keys don't > work for skipping through the other images, "q" for quitting doesn't work > and I can't leave fullscreen with "v". Only MOD4 + x which is my "kill > application" shortcut works after a while. > > Besides the above behaviour, when I open ranger first in an st session, go > to the image folder and mark all the images with "v" and hit enter the > images are in tile mode. I hit "v" again the image goes fullscreen. If I > hit arrow keys in order to got to the next image, it leaves fullscreen, > goes into tiling and places a few of the images even behind the tiling > windows overlapping even my taskbar. If I leave the images in tiling mode > and skip through them with the arrow keys and hit "v", then it jumpst back > to the very first image. > > needless to say that urxvt on the other hand handles these tasks just > fine, so at this point unfortunately st is not a full replacement for > urxvt, yet. > > but I'm shure you guys keep up the good work :-) > >
[dev] [st] Two small patches for string handling.
1. Replaced strtok_r with strsep in strparse, because strsep can handle zero-width fields (manpage says so) and because resulting code is clearer. 2. Fixed potential problem with calling strtol on non-null-terminated buffer. 0001-Replaced-strtok_r-with-strsep-for-correct-empty-fiel.patch Description: Binary data 0002-Fixed-various-bugs-with-CSI.patch Description: Binary data
Re: [dev] [st] strange behaviour with nano
2013/2/25 Roberto E. Vargas Caballero > On Mon, Feb 25, 2013 at 04:44:11AM +0400, Alexander Sedov wrote: > >Commenting on this even further: > > - tested whether st rightfully extracts selection contents. It does, > as > >debug output told me, so the problem is in nano. > > Usually we try don't add code for fixing bugs in others programs. If you > find such case, then it is more logical you send the patch to the bugsy > application, in this case alpine. > You meant nano :P. Well, we are pasting text using keyboard emulation (writing to fd). Keyboard sends \n, not \r. So it makes total sense. > >Conclusion: as it is unheard of an application which can't handle > carriage > >returns, but some buggy applications cannot handle linefeeds well due > to > >mysterious and arcane reasons, and because workaround costs three > lines of > >code, I would propose this patch to be applied to upstream. > > + char *p; > + for(p = memchr(s, '\n', n); p != NULL; p = memchr(p, '\n', s + n - > p)) > + *p = '\r'; > > I would prefer something like: > > > char *p = s, *q = s + n; > > while(p = memchr(p, '\n', q - p)) > *p = '\r'; > q is kinda superfluous (or maybe call it char *end then?). But yeah, 'while' is better. Also, I discovered that ttywrite is passed const char *, so it's invalid to modify contents. So, a new patch. 0001-Replacing-linefeeds-with-returns-in-ttywrite.patch Description: Binary data
Re: [dev] [st] strange behaviour with nano
Commenting on this even further: - tested whether st rightfully extracts selection contents. It does, as debug output told me, so the problem is in nano. - compared rxvt tt_write() with st ttywrite. rxvt's does one more thing: replaces linefeeds with carriage returns. - wrote a patch and test. Syntax hilight still goes mad, but pasting behaves right. Conclusion: as it is unheard of an application which can't handle carriage returns, but some buggy applications cannot handle linefeeds well due to mysterious and arcane reasons, and because workaround costs three lines of code, I would propose this patch to be applied to upstream. 2013/2/25 Alexander Sedov > Commenting on this: you don't really need to open a new file, either; just > try to paste to a line that has no empty line before it. > As a bonus, it wrecks syntax highlighting. > > > 2013/2/24 Andreas Marschall > >> hello, >> >> this is my first post in a mailing list ever so I hope you guys are not >> too harsh on me. >> >> One thing I noticed when using st in combination with nano (which I >> usually don't do but rather vim) >> >> Opening a text file in nano and marking a few lines with the mouse to >> copy it to another file with shift + insert the whole text is screwed up >> and even deletes other parts of the text. >> >> Ways to reproduce: >> -open nano in an st session >> -open a text file >> -mark a few lines with the mouse >> -open a new text file >> -hit shift + insert >> >> >> > 0001-Replacing-linefeeds-with-returns-in-ttywrite.patch Description: Binary data
Re: [dev] [st] strange behaviour with nano
Commenting on this: you don't really need to open a new file, either; just try to paste to a line that has no empty line before it. As a bonus, it wrecks syntax highlighting. 2013/2/24 Andreas Marschall > hello, > > this is my first post in a mailing list ever so I hope you guys are not > too harsh on me. > > One thing I noticed when using st in combination with nano (which I > usually don't do but rather vim) > > Opening a text file in nano and marking a few lines with the mouse to copy > it to another file with shift + insert the whole text is screwed up and > even deletes other parts of the text. > > Ways to reproduce: > -open nano in an st session > -open a text file > -mark a few lines with the mouse > -open a new text file > -hit shift + insert > > >
Re: [dev] [PATCH] Changed the way title is set to support UTF-8.
Thank you! 2013/2/22 Lukas Fleischer > On Fri, Feb 22, 2013 at 09:25:19PM +0400, Alexander Sedov wrote: > > Fair enough. Looks like automatic sending via git has its downsides. > > You can use `git send-email --annotate HEAD^` and add a prefix to the > subject. Or just change the "format.subjectprefix" configuration value > to something like "st] [PATCH". > > > To clarify: it's for st. > > > > > > 2013/2/22 Carlos Torres > > > > Next time why not mention the app the patch is for in the subject > i.e. > > [dev][dwm] that way its not ambiguous. > > > > --Carlos > > > > > > > >
Re: [dev] [PATCH] Changed the way title is set to support UTF-8.
Fair enough. Looks like automatic sending via git has its downsides. To clarify: it's for st. 2013/2/22 Carlos Torres > Next time why not mention the app the patch is for in the subject i.e. > [dev][dwm] that way its not ambiguous. > > --Carlos > >
Re: [dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
No, it's just not ready for anyone's eyes yet. 2013/2/22 Hugues Moretto-Viry > Good. > > Btw, your purg[1] repo is empty too. Maybe it's the same issue. > > [1] https://github.com/ElectronicRU/purg > > H.Mo. >
[dev] [PATCH] Changed the way title is set to support UTF-8.
---
TODO |1 -
st.c | 17 +++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/TODO b/TODO
index 2f42720..67615f8 100644
--- a/TODO
+++ b/TODO
@@ -18,7 +18,6 @@ bugs
* fix shift up/down (shift selection in emacs)
* fix selection paste for xatom STRING
-* fix umlaut handling in settitle
* fix rows and column definition in fixed geometry
* fix -e handling
* remove DEC test sequence when appropriate
diff --git a/st.c b/st.c
index c25f24c..094e8ca 100644
--- a/st.c
+++ b/st.c
@@ -352,6 +352,7 @@ static void xloadcols(void);
static int xsetcolorname(int, const char *);
static int xloadfont(Font *, FcPattern *);
static void xloadfonts(char *, int);
+static void xsettitle(char *);
static void xresettitle(void);
static void xseturgency(int);
static void xsetsel(char*);
@@ -1891,11 +1892,8 @@ strhandle(void) {
case 0:
case 1:
case 2:
- /*
-* TODO: Handle special chars in string, like umlauts.
-*/
if(narg > 1)
- XStoreName(xw.dpy, xw.win, strescseq.args[2]);
+ xsettitle(strescseq.args[2]);
break;
case 4: /* color set */
if(narg < 3)
@@ -1917,7 +1915,7 @@ strhandle(void) {
}
break;
case 'k': /* old title set compatibility */
- XStoreName(xw.dpy, xw.win, strescseq.buf);
+ xsettitle(strescseq.arg[1]);
break;
case 'P': /* DSC -- Device Control String */
case '_': /* APC -- Application Program Command */
@@ -2986,8 +2984,15 @@ xdrawcursor(void) {
}
void
+xsettitle(char *p) {
+ XTextProperty prop;
+ Xutf8TextListToTextProperty(xw.dpy, &p, 1, XUTF8StringStyle, &prop);
+ XSetWMName(xw.dpy, xw.win, &prop);
+}
+
+void
xresettitle(void) {
- XStoreName(xw.dpy, xw.win, opt_title ? opt_title : "st");
+ xsettitle(opt_title ? opt_title : "st");
}
void
--
1.7.10.4
Re: [dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
Yeah, I ran git push and forgot to enter passphrase. It's OK now. 2013/2/22 Hugues Moretto-Viry > Hi, > > For now, your repo seems to be kinda empty. > > H.Mo. >
Re: [dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
There's github page now: https://github.com/ElectronicRU/swaprootname with brand new manpage and use case for EOF feature. (I personally use it for displaying time and xmms2 currently-playing: I wrote a small helper script named `blink' for this purpose). 2013/2/22 Christoph Lohmann <2...@r-36.net> > Greetings. > > On Fri, 22 Feb 2013 12:53:22 +0100 Alexander Sedov > wrote: > > From README: > > > Use > > > swaprootname "New name" > > > to persistently change root window name, or > > > echo "New name1\nNew name2\n..." | swaprootname > > > to temporarily set root window name(s) and revert it to original one on > > EOF. > > Feel free to use it for your pleasure. > > What’s your use case for that EOF feature? > > The tool is missing a manpage. > > > Sincerely, > > Christoph Lohmann > > >
Re: [dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
Yeah, using time sleeps in a script is an intended way to use it. It's simple, and controlling the delay with which to show information is really the job of user scripts. 2013/2/22 Daniel Bryan > > On 23 Feb 2013 00:13, "Alexander Sedov" wrote: > > > > It does completely different job. > > Wouldn't the new message be replaced with the old so quickly as to be > unnoticeable, unless you passed it many lines or delayed EOF with a script? >
Re: [dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
It does completely different job. 2013/2/22 Anselm R Garbe > fyi > > http://tools.suckless.org/wmname > > On 22 February 2013 03:34, Alexander Sedov wrote: > > From README: > >> Use > >> swaprootname "New name" > >> to persistently change root window name, or > >> echo "New name1\nNew name2\n..." | swaprootname > >> to temporarily set root window name(s) and revert it to original one on > >> EOF. > > Feel free to use it for your pleasure. > > -Anselm > >
[dev] swaprootname -- a tool just a little bit more useful than xsetroot -name.
>From README: > Use > swaprootname "New name" > to persistently change root window name, or > echo "New name1\nNew name2\n..." | swaprootname > to temporarily set root window name(s) and revert it to original one on EOF. Feel free to use it for your pleasure. swaprootname-0.1.tar.gz Description: GNU Zip compressed data
[dev] [PATCH] Made terminal title support UTF-8 strings.
From: Alexander Sedov
---
TODO |1 -
st.c | 14 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/TODO b/TODO
index 2f42720..67615f8 100644
--- a/TODO
+++ b/TODO
@@ -18,7 +18,6 @@ bugs
* fix shift up/down (shift selection in emacs)
* fix selection paste for xatom STRING
-* fix umlaut handling in settitle
* fix rows and column definition in fixed geometry
* fix -e handling
* remove DEC test sequence when appropriate
diff --git a/st.c b/st.c
index 300e5ec..5c26d22 100644
--- a/st.c
+++ b/st.c
@@ -1858,6 +1858,7 @@ csireset(void) {
void
strhandle(void) {
char *p;
+ XTextProperty prop;
/*
* TODO: make this being useful in case of color palette change.
@@ -1872,15 +1873,18 @@ strhandle(void) {
case '0':
case '1':
case '2':
- /*
-* TODO: Handle special chars in string, like umlauts.
-*/
if(p[1] == ';') {
- XStoreName(xw.dpy, xw.win, strescseq.buf+2);
+ p += 2;
+ Xutf8TextListToTextProperty(xw.dpy, &p, 1,
XUTF8StringStyle,
+ &prop);
+XSetWMName(xw.dpy, xw.win, &prop);
}
break;
case ';':
- XStoreName(xw.dpy, xw.win, strescseq.buf+1);
+ p += 1;
+ Xutf8TextListToTextProperty(xw.dpy, &p, 1,
XUTF8StringStyle,
+ &prop);
+ XSetWMName(xw.dpy, xw.win, &prop);
break;
case '4': /* TODO: Set color (arg0) to "rgb:%hexr/$hexg/$hexb"
(arg1) */
break;
--
1.7.10.4
Re: [dev] Re: st colour shenanigans
That's the problem I was trying to fix. :) You're welcome! 2013/2/20 Charlie Kester > On 02/19/2013 06:53, Christoph Lohmann wrote: > >> Greetings. >> >> On Tue, 19 Feb 2013 15:53:15 +0100 Alexander Sedov >> wrote: >> >>> St colour shenanigans part two: I read the code of Xft library and >>> figured >>> out what the error is. This patch is really really simple (and is made >>> relative to prior-first-patch) and finally fixes color behaviour. >>> >> >> Thanks for the simple patch, it works. It’s applied. >> >> > FWIW, this fixes the problem I had with fgcolor > 16 being unreadably > bright against a light background. > > So, Alexander, please accept my thanks as well. > > >
Re: [dev] [PATCH] Added basic xterm-ish palette swap support.
While writing this patch, I accidentally intoduced off-by-one error that caused empty terminal window names and could, in theory, lead to crash. This patch is fixing this accident. 2013/2/19 Christoph Lohmann <2...@r-36.net> > Greetings. > > On Tue, 19 Feb 2013 19:14:18 +0100 Alexander Sedov > wrote: > > --- > > st.c | 111 > +++--- > > 1 file changed, 93 insertions(+), 18 deletions(-) > > Thanks, it’s applied. What’s the application needing this? > > > Sincerely, > > Christoph Lohmann > > > 0001-Fixed-off-by-one-error.-It-happens.patch Description: Binary data
Re: [dev] st patch: rectangular selection support
Enjoy these well-formed patches.
2013/2/19 Alexander Sedov
> Here it is, the new version.
>
>
> 2013/2/19 Christoph Lohmann <2...@r-36.net>
>
>> Greetings.
>>
>> On Tue, 19 Feb 2013 15:54:06 +0100 Alexander Sedov
>> wrote:
>> > This patch adds support for rectangular selections a-la urxvt, which
>> come
>> > in handy when using applications like irssi or mcabber.
>>
>> You are commenting out code and leave it there without any notice, if it
>> should be reused later. Next you are using a different style than the st
>> style, which means you use »if (« instead of »if(«. The same applies for
>> the switch case and the simple if clause, which should be
>>
>> if() {
>> } else {
>> }
>>
>> If that’s fixed your patch will be applied. The hard case why I’m not
>> applying it and notice you is because of commenting out the code. That’s
>> unclean.
>>
>>
>>
>> Sincerely,
>>
>> Christoph Lohmann
>>
>>
>>
>
0002-Rectangular-selection-support-added.patch
Description: Binary data
0007-Fixed-some-problems-with-rectsel-patch.patch
Description: Binary data
0009-Fixed-selection-redrawing-quirks.patch
Description: Binary data
[dev] [PATCH] Added basic xterm-ish palette swap support.
---
st.c | 111 +++---
1 file changed, 93 insertions(+), 18 deletions(-)
diff --git a/st.c b/st.c
index 4b21380..82f935b 100644
--- a/st.c
+++ b/st.c
@@ -302,6 +302,7 @@ static void execsh(void);
static void sigchld(int);
static void run(void);
+static inline int parse_int(char *);
static void csidump(void);
static void csihandle(void);
static void csiparse(void);
@@ -348,6 +349,7 @@ static void xclear(int, int, int, int);
static void xdrawcursor(void);
static void xinit(void);
static void xloadcols(void);
+static int xsetcolorname(int, const char *);
static int xloadfont(Font *, FcPattern *);
static void xloadfonts(char *, int);
static void xresettitle(void);
@@ -1848,34 +1850,58 @@ csireset(void) {
memset(&csiescseq, 0, sizeof(csiescseq));
}
+inline int
+parse_int(char *s) {
+ int x = 0;
+ char c;
+ while(isdigit(c = *s)) {
+ if((INT_MAX - c + '0') / 10 >= x) {
+ x = x * 10 + c - '0';
+ } else
+ return -1;
+ s++;
+ }
+ if(*s != '\0')
+ return -1;
+ return x;
+}
+
void
strhandle(void) {
- char *p;
+ char *p = NULL;
+ int i, j;
+ int narg;
/*
* TODO: make this being useful in case of color palette change.
*/
strparse();
-
- p = strescseq.buf;
+ narg = strescseq.narg;
switch(strescseq.type) {
case ']': /* OSC -- Operating System Command */
- switch(p[0]) {
- case '0':
- case '1':
- case '2':
+ switch(i = parse_int(strescseq.args[0])) {
+ case 0:
+ case 1:
+ case 2:
/*
* TODO: Handle special chars in string, like umlauts.
*/
- if(p[1] == ';') {
- XStoreName(xw.dpy, xw.win, strescseq.buf+2);
- }
- break;
- case ';':
- XStoreName(xw.dpy, xw.win, strescseq.buf+1);
+ if(narg > 1)
+ XStoreName(xw.dpy, xw.win, strescseq.args[2]);
break;
- case '4': /* TODO: Set color (arg0) to "rgb:%hexr/$hexg/$hexb"
(arg1) */
+ case 4: /* color set */
+ if(narg < 3)
+ break;
+ p = strescseq.args[2];
+ /* fall through */
+ case 104: /* color reset, here p = NULL */
+ j = (narg > 1) ? parse_int(strescseq.args[1]) : -1;
+ if (!xsetcolorname(j, p))
+ fprintf(stderr, "erresc: invalid color %s\n",
p);
+ else {
+ redraw(0); /* TODO if defaultbg color is
changed, borders are dirty */
+ }
break;
default:
fprintf(stderr, "erresc: unknown str ");
@@ -1903,7 +1929,19 @@ strparse(void) {
* TODO: Implement parsing like for CSI when required.
* Format: ESC type cmd ';' arg0 [';' argn] ESC \
*/
- return;
+ int narg = 0;
+ char *start = strescseq.buf, *end = start + strescseq.len;
+ strescseq.args[0] = start;
+ while(start < end && narg < LEN(strescseq.args)) {
+ start = memchr(start, ';', end - start);
+ if(!start)
+ break;
+ *start++ = '\0';
+ if(start < end) {
+ strescseq.args[++narg] = start;
+ }
+ }
+ strescseq.narg = narg + 1;
}
void
@@ -2318,6 +2356,11 @@ xresize(int col, int row) {
XftDrawChange(xw.draw, xw.buf);
}
+static inline ushort
+sixd_to_16bit(int x) {
+ return x == 0 ? 0 : 0x3737 + 0x2828 * x;
+}
+
void
xloadcols(void) {
int i, r, g, b;
@@ -2336,9 +2379,9 @@ xloadcols(void) {
for(i = 16, r = 0; r < 6; r++) {
for(g = 0; g < 6; g++) {
for(b = 0; b < 6; b++) {
- color.red = r == 0 ? 0 : 0x3737 + 0x2828 * r;
- color.green = g == 0 ? 0 : 0x3737 + 0x2828 * g;
- color.blue = b == 0 ? 0 : 0x3737 + 0x2828 * b;
+ color.red = sixd_to_16bit(r);
+ color.green = sixd_to_16bit(g);
+ color.blue = sixd_to_16bit(b);
if(!XftColorAllocValue(xw.dpy, xw.vis, xw.cmap,
&color, &dc.col[i])) {
die("Could not allocate color %d\n", i);
}
@@ -2356,6 +2399,38 @@ xloadcols(void) {
Re: [dev] st patch: rectangular selection support
Here it is, the new version.
2013/2/19 Christoph Lohmann <2...@r-36.net>
> Greetings.
>
> On Tue, 19 Feb 2013 15:54:06 +0100 Alexander Sedov
> wrote:
> > This patch adds support for rectangular selections a-la urxvt, which come
> > in handy when using applications like irssi or mcabber.
>
> You are commenting out code and leave it there without any notice, if it
> should be reused later. Next you are using a different style than the st
> style, which means you use »if (« instead of »if(«. The same applies for
> the switch case and the simple if clause, which should be
>
> if() {
> } else {
> }
>
> If that’s fixed your patch will be applied. The hard case why I’m not
> applying it and notice you is because of commenting out the code. That’s
> unclean.
>
>
>
> Sincerely,
>
> Christoph Lohmann
>
>
>
rect_sel.patch
Description: Binary data
[dev] Re: st colour shenanigans
St colour shenanigans part two: I read the code of Xft library and figured out what the error is. This patch is really really simple (and is made relative to prior-first-patch) and finally fixes color behaviour. 2013/2/19 Alexander Sedov > Due to some shenanigans to be further investigated, colors allocated with > XftColorAllocValue behave badly with ATTR_REVERSE (namely, are much whiter > than they should be). This carefully crafted yet ugly patch provides > temporary workaround for this problem. > color.patch Description: Binary data
[dev] st patch: rectangular selection support
This patch adds support for rectangular selections a-la urxvt, which come in handy when using applications like irssi or mcabber. 0001-Rectangular-selection-support-added.patch Description: Binary data
[dev] st colour shenanigans
Due to some shenanigans to be further investigated, colors allocated with XftColorAllocValue behave badly with ATTR_REVERSE (namely, are much whiter than they should be). This carefully crafted yet ugly patch provides temporary workaround for this problem. 0001-Ugly-workaround-for-X-shenanigans.patch Description: Binary data
Re: [dev] [surf] zero percent in title bug
2012/10/12 Christoph Lohmann <2...@r-36.net>: > Greetings. > > On Fri, 12 Oct 2012 19:42:11 +0200 Carlos Pita > wrote: >> Hi, >> >> I found this patch for the bug but I don't think it's right to just >> hide the [0%] because there is the legitimate case when the page >> hasn't started to load yet. >> >> http://www.digipedia.pl/usenet/thread/15253/9123/ >> >> So I did this instead: >> >> case WEBKIT_LOAD_FINISHED: >> c->progress = 100; // <--- previously = 0 >> >> Seems like it's working till now. > > Could you please send patches instead of complex inline gibberish? > > > Sincerely, > > Christoph Lohmann If you think this is complex, I don't even know what to say. If you're attempting to be someone's momma, that's just lame.
Re: [dev] POLL: most beautiful suckless cloud
2012/9/19 Christoph Lohmann <2...@r-36.net>: > Greetings. > > Suckless can't stand behind the developments of the sucking world. > Because of this I have a request. Please vote for your most favourite > suckless cloud implementation. Both are attached. > > The winner will be shown in art galleries all over Europe. > > > Sincerely, > > Christoph Lohmann I'd like to know is this kind of jokes is considered funny here.
