Re: [dev] [st] bitmap font and chscale 1< line drawing bug

2016-09-07 Thread Eric Pruitt 
On Wed, Sep 07, 2016 at 09:20:39PM -0700, le...@bitmessage.ch wrote:
> This did not happen in st-0.6. Okay I'll check out git-bisect and see if
> I can figure it out. I'll submit a patch or pull request if I find a
> solution. Thanks.

Even if you don't debug and / or fix the problem, at least post the
offending commit, and I will take a look.

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

2016-09-07 Thread lemon 
On Wed, Sep 07, 2016 at 06:02:53PM -0700, Eric Pruitt wrote:
> On Wed, Sep 07, 2016 at 06:01:48PM -0700, Eric Pruitt wrote:
> > On Wed, Sep 07, 2016 at 05:51:49PM -0700, le...@bitmessage.ch wrote:
> > > After moving to st-0.7, I am experiencing a bug with line drawing. When
> > > using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
> > > vertical line has gaps in it (ex tree or tmux). This persists for 
> > > different
> > > bitmap fonts
> > > but goes away when chscale is set to 1.0.
> >
> > Did this not happen before st-0.7? I implemented the ch* factors in a
> > simple way just to control the invisible bounding boxes for each
> > character, and they don't scale the font itself; the behavior you're
> > seeing is working as intended, and it's also what I observed when I was
> > testing the feature and experimented with different scaling factors. I
> > have noticed that on some operating systems, even using the exact same
> > st compile options and fonts, I get slightly different results -- on my
> > work computer, there are 1-pixel gaps between vertical lines (not pipe
> > but "│"), but at home, the gaps aren't there. I don't find this annoying
> > enough to invest any effort into figuring out why that happens despite
> > both computers being Debian-based.
> 
> Also, if this doesn't happen in earlier versions, you could use
> git-bisect (https://git-scm.com/docs/git-bisect) to figure out which
> commit introduced the problem.
> 
> Eric
 
This did not happen in st-0.6. Okay I'll check out git-bisect and see if
I can figure it out. I'll submit a patch or pull request if I find a
solution. Thanks.

lemon

Re: [dev] Shell style guide

2016-09-07 Thread Marc Collin 
What people here think of heredoc?

cat << EOF
1st line
2nd line
3rd line
4th line
EOF

OR

echo "1st line"
echo "2nd line"
echo "3rd line"
echo "4th line"

OR

printf "1st line\n"
printf"2nd line\n"
printf"3rd line\n"
printf"4th line\n"


On Wed, Sep 7, 2016 at 6:46 PM, Tiago Natel de Moura
 wrote:
> Good compilation of best practices. That's one of the causes I created
> nash[1], a shell with sane defaults.
>
>
> 1. https://github.com/NeowayLabs/nash
>
> --
> []'s
> i4k
>

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

2016-09-07 Thread Eric Pruitt 
On Wed, Sep 07, 2016 at 06:01:48PM -0700, Eric Pruitt wrote:
> On Wed, Sep 07, 2016 at 05:51:49PM -0700, le...@bitmessage.ch wrote:
> > After moving to st-0.7, I am experiencing a bug with line drawing. When
> > using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
> > vertical line has gaps in it (ex tree or tmux). This persists for different
> > bitmap fonts
> > but goes away when chscale is set to 1.0.
>
> Did this not happen before st-0.7? I implemented the ch* factors in a
> simple way just to control the invisible bounding boxes for each
> character, and they don't scale the font itself; the behavior you're
> seeing is working as intended, and it's also what I observed when I was
> testing the feature and experimented with different scaling factors. I
> have noticed that on some operating systems, even using the exact same
> st compile options and fonts, I get slightly different results -- on my
> work computer, there are 1-pixel gaps between vertical lines (not pipe
> but "│"), but at home, the gaps aren't there. I don't find this annoying
> enough to invest any effort into figuring out why that happens despite
> both computers being Debian-based.

Also, if this doesn't happen in earlier versions, you could use
git-bisect (https://git-scm.com/docs/git-bisect) to figure out which
commit introduced the problem.

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

2016-09-07 Thread Eric Pruitt 
On Wed, Sep 07, 2016 at 05:51:49PM -0700, le...@bitmessage.ch wrote:
> After moving to st-0.7, I am experiencing a bug with line drawing. When
> using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
> vertical line has gaps in it (ex tree or tmux). This persists for different 
> bitmap fonts
> but goes away when chscale is set to 1.0.

Did this not happen before st-0.7? I implemented the ch* factors in a
simple way just to control the invisible bounding boxes for each
character, and they don't scale the font itself; the behavior you're
seeing is working as intended, and it's also what I observed when I was
testing the feature and experimented with different scaling factors. I
have noticed that on some operating systems, even using the exact same
st compile options and fonts, I get slightly different results -- on my
work computer, there are 1-pixel gaps between vertical lines (not pipe
but "│"), but at home, the gaps aren't there. I don't find this annoying
enough to invest any effort into figuring out why that happens despite
both computers being Debian-based.

Eric

[dev] [st] bitmap font and chscale 1< line drawing bug

2016-09-07 Thread lemon 
After moving to st-0.7, I am experiencing a bug with line drawing. When
using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
vertical line has gaps in it (ex tree or tmux). This persists for different 
bitmap fonts
but goes away when chscale is set to 1.0. 

gcc version 5.4.0 (CRUX-x86_64-multilib)
ncurses version 6.0

Re: [dev] Shell style guide

2016-09-07 Thread Tiago Natel de Moura 
Good compilation of best practices. That's one of the causes I created
nash[1], a shell with sane defaults.


1. https://github.com/NeowayLabs/nash

-- 
[]'s
i4k

Re: [dev] Shell style guide

2016-09-07 Thread Adrian Grigore 
Thanks!

On Thu, Sep 8, 2016 at 12:29 AM, Evan Gates  wrote:
> On Wed, Sep 7, 2016 at 2:11 PM, Adrian Grigore
>  wrote:
>> Rendering was just an example, I doubt a shell script would be rendering.
>>
>> Example of camelCase I find ok is here:
>> https://raw.githubusercontent.com/adriangrigore/bootstrap/master/bootstrap
>>
>> Be free to critique the script, but note that I'm new to the whole
>> UNIX/C scene so learning as I go (if I did some blatant mistakes,
>> please point them).
>>
>
> In this line:
>
>>&2 echo usage: bootstrap name [description] [license]
>
> You must quote. [description] is a glob, if you have a file named e in
> the directory it will print: usage: bootstrap name e e
>
> This line:
>
> if [ $(license -list | tail -n +3 | awk '{ print $1 }' | grep "$type") ]; then
>
> No need for [] nor $(), just useif license -list | ... | grep -q
> "$type"; then
> Also you should rarely, if ever, need both awk and grep in a single
> pipeline (you can get rid of tail too and just license | awk)
>



-- 
Thanks,
Adi

Re: [dev] Shell style guide

2016-09-07 Thread Evan Gates 
On Wed, Sep 7, 2016 at 2:11 PM, Adrian Grigore
 wrote:
> Rendering was just an example, I doubt a shell script would be rendering.
>
> Example of camelCase I find ok is here:
> https://raw.githubusercontent.com/adriangrigore/bootstrap/master/bootstrap
>
> Be free to critique the script, but note that I'm new to the whole
> UNIX/C scene so learning as I go (if I did some blatant mistakes,
> please point them).
>

In this line:

>&2 echo usage: bootstrap name [description] [license]

You must quote. [description] is a glob, if you have a file named e in
the directory it will print: usage: bootstrap name e e

This line:

if [ $(license -list | tail -n +3 | awk '{ print $1 }' | grep "$type") ]; then

No need for [] nor $(), just useif license -list | ... | grep -q
"$type"; then
Also you should rarely, if ever, need both awk and grep in a single
pipeline (you can get rid of tail too and just license | awk)

Re: [dev] Shell style guide

2016-09-07 Thread Adrian Grigore 
Rendering was just an example, I doubt a shell script would be rendering.

Example of camelCase I find ok is here:
https://raw.githubusercontent.com/adriangrigore/bootstrap/master/bootstrap

Be free to critique the script, but note that I'm new to the whole
UNIX/C scene so learning as I go (if I did some blatant mistakes,
please point them).

On Thu, Sep 8, 2016 at 12:04 AM, Charlie Kester  wrote:
> On Wed 07 Sep 2016 at 11:43:48 PDT Adrian Grigore wrote:
>>
>> Tbh, I'm nor a big fan of camelCase either, but when dealing with
>> names composed of multiple words, it looks cleaner to me.
>>
>> renderimage vs renderImage
>
>
> It's mostly a matter of taste.  But as someone whose tastes
> were formed by the naming conventions of K and the C runtime
> library, I think the camelcased version of your example looks
> less "clean".
>
> And I have to ask: what else would your script be rendering?
> Is it really necessary to specify the object if "render" will
> suffice?
>
>
>



-- 
Thanks,
Adi

Re: [dev] Shell style guide

2016-09-07 Thread Charlie Kester 

On Wed 07 Sep 2016 at 11:43:48 PDT Adrian Grigore wrote:

Tbh, I'm nor a big fan of camelCase either, but when dealing with
names composed of multiple words, it looks cleaner to me.

renderimage vs renderImage


It's mostly a matter of taste.  But as someone whose tastes
were formed by the naming conventions of K and the C runtime
library, I think the camelcased version of your example looks
less "clean".

And I have to ask: what else would your script be rendering?
Is it really necessary to specify the object if "render" will
suffice?

Re: [dev] Shell style guide

2016-09-07 Thread Adrian Grigore 
Tbh, I'm nor a big fan of camelCase either, but when dealing with
names composed of multiple words, it looks cleaner to me.

renderimage vs renderImage

On Wed, Sep 7, 2016 at 8:21 PM, Adrian Grigore
 wrote:
> Tbh, I'm nor a big fan of camelCase either, but when dealing with names
> composed of multiple words, it looks cleaner to me.
>
> renderimage vs renderImage
>
>
> On Wednesday, September 7, 2016, Antenore Gatta 
> wrote:
>> On Wed, 7 Sep 2016 03:23:55 +0300
>> Adrian Grigore  wrote:
>>
>>> What do you think of camelCase names for functions/variables?
>>
>> For me it's important being consistent, at least on a project level
>> (across projects would be the best).
>>
>> I personally dislike camelCase but are good to save columns.
>>
>>
>> --
>> -BEGIN GEEK CODE BLOCK-
>> Version: 3.12
>> GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w---
>> O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++
>> G e+ h r+++ y
>> --END GEEK CODE BLOCK--
>>
>>
>
> --
> Thanks,
> Adi



-- 
Thanks,
Adi

Re: [dev] Shell style guide

2016-09-07 Thread Antenore Gatta 
On Tue, 6 Sep 2016 11:35:35 -0700
Evan Gates  wrote:

> suckless.org projects have traditionally been small amounts of pure C.
> The code tends towards simplicity and correctness. I value this and
> have learned much over the past years from reading and contributing to
> various projects.
> 
> The addition of stali means there will probably be a fair amount of
> shell scripting. In my experience the vast majority of shell scripts
> are complete crap. Worse than poor style are poor practices that
> create broken code. As such I propose that we add a shell scripting
> style guide to go along with the existing C style guide in hopes of
> keeping suckless.org's shell scripts as clean, simple, and correct as
> the C code.

I hope this is not a too stupid question, do we have anything we can
work on already (script, a document draft, whatever)?

Thanks!
 

-- 
Antenore
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w--- 
O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++ 
G e+ h r+++ y 
--END GEEK CODE BLOCK--

Re: [dev] Shell style guide

2016-09-07 Thread Antenore Gatta 
On Wed, 7 Sep 2016 03:23:55 +0300
Adrian Grigore  wrote:

> What do you think of camelCase names for functions/variables?

For me it's important being consistent, at least on a project level
(across projects would be the best).

I personally dislike camelCase but are good to save columns.


-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w--- 
O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++ 
G e+ h r+++ y 
--END GEEK CODE BLOCK--

Re: [dev] Shell style guide

2016-09-07 Thread Greg Reagle 
On Tue, Sep 6, 2016, at 08:23 PM, Adrian Grigore wrote:
> What do you think of camelCase names for functions/variables?

Fine with me.  I don't have a_strong_preference forEitherStyle.