On Mon, May 04, 2015 at 07:38:40PM +, non...@inventati.org wrote:
> It handles the case when Button1 is released. In this case either
> selcopy is called and there is no need to set dirty flag as selection is
> already rendered, or selclear is called, and it sets dirty flag by
> itself.
Ok, ca
On Mon, May 04, 2015 at 11:47:18PM +0200, Hiltjo Posthuma wrote:
> I think the use of uncommon "VL Gothic" and "WenQuanYi Micro Hei" is a
> bit strange atleast. But yea maybe it should be left unchanged, it's
> easy enough to change anyway.
They may be uncommon for users that only care about Roman
On Mon, May 4, 2015 at 11:18 PM, Eric Pruitt wrote:
> On Mon, May 04, 2015 at 10:46:51PM +0200, Hiltjo Posthuma wrote:
>> These are some fixes and improvements for dwm.
>
> You changed the dmenufont argument, but mainline dmenu
> (http://git.suckless.org/dmenu) does not support Xft which is why I
On Mon, May 04, 2015 at 10:46:51PM +0200, Hiltjo Posthuma wrote:
> These are some fixes and improvements for dwm.
You changed the dmenufont argument, but mainline dmenu
(http://git.suckless.org/dmenu) does not support Xft which is why I left
it unchanged when I submitted that patch.
I also don't
Hi guys,
These are some fixes and improvements for dwm.
Kind regards,
HIltjo
From ef3ee18387b8cfe3282d53a33f0f47fb58b6d8c9 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Mon, 4 May 2015 20:30:57 +0200
Subject: [PATCH 1/4] drw: drw_rect: use specified w and h
---
drw.c | 9 +++--
1 fi
On Tue, Apr 21, 2015 at 11:37 PM, Markus Teich
wrote:
> + if (filled)
> + XFillRectangle(drw->dpy, drw->drawable, drw->gc, x, y, w, h);
I think this should be:
XFillRectangle(drw->dpy, drw->drawable, drw->gc, x, y, w + 1, h + 1);
(see diffed code).
Kind regards,
HIltjo
Hi guys,
Based on the work of libsl I have modified dmenu to use the new
libsl/libdraw code which adds Xft and fallback-fonts support aswell.
Addtionally I fixed a few oddities in libsl which were mentioned on
this ML by Markus Teich and Eric Pruitt before.
- libdraw, util: add drw.{c,h}, util.{
On Mon, May 04, 2015 at 12:09:06PM +0200, Roberto E. Vargas Caballero wrote:
> > - tsetdirt(sel.nb.y, sel.ne.y);
>
>
> Can you explain why is not needed?
It handles the case when Button1 is released. In this case either
selcopy is called and there is no need to set dirty flag as select
> > > Second I don't have any warning with any of the compilers I use.
> >
> > Good for you. How is that in any way relevant? There is no prescribed
> > compiler, is there? Also, the idea with this sort of distribution model
> > is that the users also catch things that the maintainer won't.
>
> I w
On 4 May 2015 at 11:30, Roberto E. Vargas Caballero wrote:
> But uint32_t is not guaranteed to be present in all the implementations
uint32_t is guaranteed in POSIX 2004, but you may not want to rely on that.
uint32_least_t, which would suffice, is guaranteed in C99.
cls
Hi,
>
> In Plan 9, when one executes a graphical program from a terminal
> window it will take over that window, so that running a graphical text
> editor like Sam from a terminal is not so different from running a
> line editor. This was one of my favourite things from the Plan 9 GUI.
Indeed.
> > Second I don't have any warning with any of the compilers I use.
>
> Good for you. How is that in any way relevant? There is no prescribed
> compiler, is there? Also, the idea with this sort of distribution model
> is that the users also catch things that the maintainer won't.
I wanted to sa
>
> Sorry, there aren't actually two extra padding bytes, even though the
> struct is two bytes longer in length. Don't know what I was thinking.
> Time for a coffee.
>
The problem with this kind of things is they depend too much
of the implementations, because you can have the padding or
not, s
>
> For what it's worth, I agree with this approach. uint32_t is
> guaranteed (since C99) to be just the right size to hold all Unicode
> points (as well as their UTF-8 representation) without wasting (too
> much) space.
But uint32_t is not guaranteed to be present in all the implementations,
alt
> > It is no casuality they added this rule to the standard. They added
> > it because is the idiomatic way of running over an array in C. Of
> > course CS teachers that liked pascal don't teach it anymore when
> > they were forced to move to C, but it is the best way for experienced
> The code in
Applied, thanks.
> - tsetdirt(sel.nb.y, sel.ne.y);
Can you explain why is not needed?
Regards,
Applied, thanks.
Applied, thanks.
Applied, thanks.
I prefer the current code, because the responsability of each function
is better designed. In the current code selsnap does all the work related
to SNAP_LINE and SNAP_WORD, but in your commit, a part is done in
selnormalize and other part in selsnap.
Regards,
Applied, thanks.
On Thu, Apr 30, 2015 at 09:23:15PM +, noname wrote:
> It is equal to term.col-1 in any case.
Can you explain why xt is equal to term.col-1 in any case? I cannot see
it from your comments. Please, could you extend explanations in your
commits?
Regards,
> @@ -753,14 +752,13 @@ selsnap(int *x, int *y, int direction) {
>
> gp = &term.line[newy][newx];
> delim = ISDELIM(gp->u);
> - if(!(gp->mode & ATTR_WDUMMY) && (delim != prevdelim
> + if(!(gp->mode & ATTR_WDUMMY)
> - if (sel.type == SEL_RECTANGULAR)
> - return;
...
> + if(sel.type == SEL_REGULAR) {
> + int len = tlinelen(sel.nb.y);
This patch inverts the logic. In the current code the function returns
when sel.type == SEL_RECTANGULAR, but in your code it test len only
when
Applied, thanks.
* koneu [2015-04-23 21:09]:
> Careful though, arg.v is _not_ the address you want to pass to
> evascript(), *(arg.v) is! (or at least that's what the old code suggests)
Yeah, I'm chaging the API here. But as eval() is not used in surf and
the old version is broken, I don't the point not to apply
Hi,
I am going to apply the original patch. I think there is
space for improvements, so new patches are welcome.
Regards,
> Non-maintainers like us can't push to the repository. Mailing list only.
The idea is to use the mailing list as a peer review mechanism. I am
one of the maintainer of st and I also send the patches first to the
mailing list to see the opinion of another hackers.
Regards,
29 matches
Mail list logo
