Re: [dev] st: Large pile of code
I like the seperation of term.c from st.c, I agree that makes reading st.c clearer. I can't comment on the removal of forward declarations, typedefs and static vars though the resulting difference is legible as well. (frankly code in alphabetical order makes me want to sort it according to code flow and surrounding context...) i think the choice of using the fontconfig utf8 functions was a good idea. I frowned when you switched to 'gnu99' from 'c99' (i pictured a lot of flames on that) Thank You, On Tue, Apr 23, 2013 at 8:27 PM, Kent Overstreet wrote: > First off - nice work! > > Awhile back I started hacking on st in my spare time. I haven't added > anything earth shaking - the majority of what I've been doing has been > refactoring and rewriting bits to make the code better. > > Anyways, the way I've been doing things has diverged enough that I don't > know if you'll want to pull in my changes (I follow the linux kernel > coding style, for one) - if it's too different a direction from what you > guys prefer that's ok. > > Unfortunately, I think I waited a bit too long to send this so if you > guys do want to merge my changes in that's going to be a pain... but, if > you like what I've been doing I can start working on that. > > Also, one of the big things I did was to libraryize the terminal > emulation code, and decouple it from the renderer. I figure there's > enough terminal emulators out there (including things like tmux) we > really should have a good library for this sort of thing instead of > reinventing the wheel all the time. Makes the code easier to understand > too, I think. > > If you want to have a look, my git repo is > http:/evilpiepirate.org/git/st.git > > Thanks! >
Re: [dev] st: Large pile of code
On Wed, Apr 24, 2013, at 9:32, Carlos Torres wrote: > I like the seperation of term.c from st.c, I agree that makes reading > st.c clearer. I can't comment on the removal of forward declarations, > typedefs and static vars though the resulting difference is legible as > well. (frankly code in alphabetical order makes me want to sort it > according to code flow and surrounding context...) i think the choice > of using the fontconfig utf8 functions was a good idea. I frowned > when you switched to 'gnu99' from 'c99' (i pictured a lot of flames on > that) If it _can_ be compiled in c99 mode, no reason it shouldn't be - then people can compile it using LLVM/clang, tendra, pcc, etc. How hard is it going to be to merge these changes with what changes have been made to the main version since he branched off from it?
Re: [dev] st: Large pile of code
i haven't tried rebasing his code yet. but if i have time later this week i might try it. for fun. --Carlos On Wed, Apr 24, 2013 at 10:23 AM, wrote: > On Wed, Apr 24, 2013, at 9:32, Carlos Torres wrote: >> I like the seperation of term.c from st.c, I agree that makes reading >> st.c clearer. I can't comment on the removal of forward declarations, >> typedefs and static vars though the resulting difference is legible as >> well. (frankly code in alphabetical order makes me want to sort it >> according to code flow and surrounding context...) i think the choice >> of using the fontconfig utf8 functions was a good idea. I frowned >> when you switched to 'gnu99' from 'c99' (i pictured a lot of flames on >> that) > > If it _can_ be compiled in c99 mode, no reason it shouldn't be - then > people can compile it using LLVM/clang, tendra, pcc, etc. > > How hard is it going to be to merge these changes with what changes have > been made to the main version since he branched off from it? >
Re: [dev] st: Large pile of code
On Wed, Apr 24, 2013 at 7:23 AM, wrote: > On Wed, Apr 24, 2013, at 9:32, Carlos Torres wrote: >> I like the seperation of term.c from st.c, I agree that makes reading >> st.c clearer. I can't comment on the removal of forward declarations, >> typedefs and static vars though the resulting difference is legible as >> well. (frankly code in alphabetical order makes me want to sort it >> according to code flow and surrounding context...) i think the choice >> of using the fontconfig utf8 functions was a good idea. I frowned >> when you switched to 'gnu99' from 'c99' (i pictured a lot of flames on >> that) > > If it _can_ be compiled in c99 mode, no reason it shouldn't be - then > people can compile it using LLVM/clang, tendra, pcc, etc. I switched to gnu99 for typeof() - it makes it possible to write min and max macros that don't evaluate their arguments twice, and IMO is a very worthwhile extension. clang definitely supports it. I haven't tried compiling with clang yet to check if it needs different arguments, but I'll do that. > How hard is it going to be to merge these changes with what changes have > been made to the main version since he branched off from it? Probably the easiest way is just going to be to cherry pick all the new upstream patches onto my branch one by one - shouldn't be that bad. I may work on that tonight.
Re: [dev] st: Large pile of code
On Wed, Apr 24, 2013, at 15:32, Kent Overstreet wrote: > I switched to gnu99 for typeof() - it makes it possible to write min > and max macros that don't evaluate their arguments twice, and IMO is a > very worthwhile extension. Wait, you switched _to_ gnu99? For _that_? A) Why do min and max need to be macros at all? Also, where do you call them on anything that's not an int? B) Where do you call them on anything that has side effects (i.e. that _needs_ to not be evaluated twice)?
[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] st: Large pile of code
On Wed, Apr 24, 2013 at 2:14 PM, wrote: > On Wed, Apr 24, 2013, at 15:32, Kent Overstreet wrote: >> I switched to gnu99 for typeof() - it makes it possible to write min >> and max macros that don't evaluate their arguments twice, and IMO is a >> very worthwhile extension. > > Wait, you switched _to_ gnu99? For _that_? Yep. > A) Why do min and max need to be macros at all? Also, where do you call > them on anything that's not an int? > B) Where do you call them on anything that has side effects (i.e. that > _needs_ to not be evaluated twice)? Honestly, I don't really care to bikeshed over this - but, making function or a macro that did evaluate its arguments twice would a) be _inviting_ bugs, tripping people up who are used to correctly implemented min() and max() elsewhere, and b) these versions are relatively standard (the Linux kernel, and it's one of the things the kernel gets right, IMO). If people are actually using compilers that don't support typeof, I'll just rip out all the min and max usage - better that than doing it wrong. Oh, it's not just min and max that use typeof, swap() too (and I think I use swap more).
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.
Re: [dev] st: Large pile of code
On Wed, Apr 24, 2013 at 11:48 PM, Alexander Sedov wrote: > 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. > So, to restate - code should be harder to understand to keep people from contributing?
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
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.
