Re: [dev] Testing suckless programs

[Martti Kühne]

You shouldn't need to test if it might just work for you by accident.

cheers!
mar77i

Re: [dev] dmenu and dwm: is exec really needed

[Martti Kühne]

Greg, if you want to limit your dmenu to executables, use this line
instead of the pipe-to-$SHELL:

exec $(dmenu_path | dmenu "$@")

I left the substitution unquoted, so you can still pass arguments to
commands which are run.

cheers!
mar77i

Re: [dev] dmenu and dwm: is exec really needed

[Martti Kühne]

To allow for shell expressions is a neat thing, and if you don't need
them, I can provide you with a patch.
I did look into this topic another time, actually. I think I had
modified dmenu_run to use exec in some way on one of my installations,
but I appear to have currently misplaced it.

cheers!
mar77i

Re: [dev] Hi, newb here.

[Martti Kühne]

Sorry, but I feel inclined to fill my so many dropped words and
thoughts in between.

On Mon, Apr 18, 2016 at 8:29 PM, Martti Kühne <mysat...@gmail.com> wrote:
> [...] You most easily get
> off the ground if you also run the stuff you're reading and maybe
> you'll like on git.suckless.org, only surf is probably outside that

you'll like [a project or another] on git.suckless.org

> "getting into practical c" domain. Quark, the suckless httpd is hosted

quark is hosted on the above url, but its developer used to have a
more current branch somewhere else.

> somewhere else if you want to look at sockets and networking. DWM, the
> window manager was the thing that got me off the ground with after

with [C programming] after

> only shallow encounters in the past.
> [...]

cheers!
mar77i

Re: [dev] Hi, newb here.

[Martti Kühne]

On Mon, Apr 18, 2016 at 8:18 PM, ab  wrote:
> What kind of advice could you guys give to a novice? I'd like to get
> myself more familiar with Linux and C (because I have a copy of K).
> I'm asking you guys because you seem to know what you're doing and
> you're the only community I know which are committed to what you do.


work through k, and then read code written by other people to get an
impression about the libraries that are out there. You most easily get
off the ground if you also run the stuff you're reading and maybe
you'll like on git.suckless.org, only surf is probably outside that
"getting into practical c" domain. Quark, the suckless httpd is hosted
somewhere else if you want to look at sockets and networking. DWM, the
window manager was the thing that got me off the ground with after
only shallow encounters in the past.

I can also recommend the ##c channel on freenode which is not only
extremely entertaining (never be scared on the internet) but it's also
also very good place to learn about the subtleties of the c
programming language in its various forms as a working tool. That'll
probably lead to you downloading a copy of some version of the C
Programming Language Specification if you want to go portable, general
(non-gnu!) C - which is a good thing for all the various reasons.

cheers!
mar77i

Re: [dev] [dwm][PATCH] implement ARGB color support

[Martti Kühne]

On Mon, Mar 7, 2016 at 4:04 PM, Eon S. Jeon  wrote:
> Hello,
>
> My obsession for transparency never knows when to stop, so I couldn't resist
> writing this patch.
>
> This patch allows dwm to have translucent bars, while keeping all the text on
> it opaque, just like my ARGB patch for st[1].
>
> The patch also allows changing the opacity of borders, but it only works for
> ARGB-enabled applications(i.e. ARGB-patched st). This is because each border 
> is
> drawn using the visual of the window it is wrapping. Thus, windows with 24-bit
> visuals will still have opaque borders even after this patch is applied.
>
> I'll upload this to http://dwm.suckless.org , hoping someone find it useful
>
> Sincerely,
> Eon
>
> [1]: http://st.suckless.org/patches/argbbg
>


Taking this further with a fade-in at mouse coord 0 or some kind of
meta-click event as well as fade-out on timer would make it possible
to have all the screen space for clients. I like it.

cheers!
mar77i

Re: [dev] suckless shared tools

[Martti Kühne]

People here won't agree on building a framework.

cheers!
mar77i

Re: [dev] [sbase] missing tool - awk

[Martti Kühne]

On Sat, Feb 20, 2016 at 11:36 AM, Alba Pompeo  wrote:
> What I mean is, wouldn't it be duplicated work to create your own awk
> when there's already a good version out there? Or is there something
> wrong with bwk's One True Awk?
>


That's more or less what Dimitris said. Why should suckless maintain a
copy of OTA, if OTA just can be built on the system where you want it?
How's duplicating one effort removing duplication in another?

cheers!
mar77i

Re: [dev] [ANNOUNCE] slock-1.3

[Martti Kühne]

On Mon, Feb 15, 2016 at 10:55 AM, Markus Teich
 wrote:
>> slock < password-file
>
> This is an interesting idea. I would not use it for mainline (users don't want
> to change their password in many places), but you can push a patch to the 
> wiki.
>


Essentially, password hashing is a thing that could be done through
another tool, maybe on fd 3?

I'd be interested whether hiro would also work with different fds for
optimal separation of conerns instead of the current solution. We
could split it up into several rather generally useful binaries.

cheers!
mar77i

Re: [dev] [surf] Why yank to primary instead of clipboard?

[Martti Kühne]

On Wed, Feb 3, 2016 at 10:17 AM, Kamil Cholewiński  wrote:
>
> This is even weirder. It pastes primary selection in terminals, but
> clipboard in surf or emacs. It's even more confusing, I will
> purposefully pretend it doesn't exist.
>


Seriously, if you don't like it, much of this isn't the fault of sl.
That GTK programs use a different paste buffer for ^Ins is completely
arbitrary and probably the wrong thing GTK does there, but now that
doesn't force sl software to succumb to the same weirdness - see also:
Argumentum ad popolum (developum? - totally winging this one).
You know where to find the source, so it won't be hard for you to
figure out how to apply patches.

cheers!
mar77i

Re: [dev] [bugs] st clears up upon resize and other little things

[Martti Kühne]

On Tue, Jan 19, 2016 at 11:36 AM, famfop  wrote:
>
> Hi,
> what 'sh are you using? E.g. using mksh it worked out of the box (for me).
> As I'm using zsh I followed [0]. I suppose thats the cleanest way of doing
> it. _My_ problem now is, that some applications, e.g. ipython, don't
> recognize the del key. But I guess this has not to do with st.
> As I don't use bash I can't tell for sure, but you may find something
> interesting here [1].
>

Bash inherits the settings in $HOME/.inputrc which holds the settings
for all software that depend on readline.

cheers!
mar77i

Re: [dev] [website] Project ideas page

[Martti Kühne]

On Tue, Jan 12, 2016 at 10:15 PM, hiro <23h...@gmail.com> wrote:
> Yes, I also don't see a reason not to try. I've seen many hipsterops
> lately that use dwm in my university. Since google is all about
> prestige there is definitely a chance.
>


I'm awaiting the hour when you guys start sighing in despair over a
gsoc fork of dwm that makes linux look like windows' dwm.exe because
the hipsters were all about feature creep instead. Some others would
argue that's what they signed up for on @sl lists xD

cheers!
mar77i

Re: [dev] [PATCH] Reload on SIGHUP

[Martti Kühne]

On Mon, Jan 11, 2016 at 7:55 PM, Marc Collin  wrote:
> Isn't /rocks and /other_projects redundant?
> I mean, software listed on /other_projects rocks and software on
> /rocks are other projects.
>
>


Projects that can be associated suckless or suckless developers in one
way or another might fall into the /other_projects category. Just
because somebody around here works on something doesn't mean they do
something that the high priests of suckless fancy.

cheers!
mar77i

Re: [dev] Z-ordering in dwm based on size

[Martti Kühne]

On Thu, Dec 24, 2015 at 1:35 AM, Eric Pruitt  wrote:
> When using dwm, I sometimes "lose" windows in floating mode because
> they're hidden behind another window. I am thinking about writing a
> patch that adjusts the z-order of windows based on the size of the
> windows relative to one another to prevent this. Is anyone sitting on
> patch that already does this?
>
> Eric
>


I'm rather surprised you'd have such an issue, at all. The way I
understood floating mode is that such windows should be on top of
those which aren't floating. Also, if you write a size-based z-order
sort, you should have dwm to cycle through windows with the same size
or a size greater than the client area... and then things start to get
real funky. There should be some kind of previous/next focused window
functionality somewhere, which might find a lost window more easily.

cheers!
mar77i

Re: [dev] Female contributions

[Martti Kühne]

On Sat, Dec 19, 2015 at 5:03 PM, e...@bestmx.net  wrote:
>> If  we  really  want  to add »gender« as an attribute to all committers,
>> please add »race« too, for further politcal debates and distraction.
>
> how about "age" and "size" attributes too,
> just to ensure age and size "equalities".
>

I'm all for having contributions by people with dwarfism, gigantism,
males, females, sentient non-humans, infants and seniors. However, as
you may guess, I'm somewhat concerned enough over the quality of the
submitted code by the people who *already* contribute, which, we must
conclude, can only improve with a more thorough blending of traits.
What steps can be taken to reach the people (plus the sentient
non-humans) in question?

cheers!
mar77i

Re: [dev] Female contributions

[Martti Kühne]

On Sat, Dec 19, 2015 at 5:39 PM, e...@bestmx.net  wrote:
> pardon me, i failed to follow you,
> how do you want to achieve the "trait blending" amongst the existing 
> contributors.
> do you want to ALTER THEIR CURRENT TRAITS?
> change their gender? cut legs? something else?
>

The sentences somewhat relate. I said that we needed more of the
blending and then suggested trying to reach them. Your suggestions
however make me remember other nonetheless important minorities like
amputees and transsexuals. You cannot equate them to women as you
cannot equate people with dwarfism with amputees either. Of course,
causing amputees and transsexuality would probably be a viable way to
have them included. Thanks for your important contribution.

cheers!
mar77i

Re: [dev] Female contributions

[Martti Kühne]

As a completely oversexualized sidenote, there's "suck" in suckless,
which should be appealing to people who do not approve of the
oversexualized culture we're stuck with on the internet. Now, we might
not oversexualize issues and just accept the fact that the people who
get here are from an industry which got into this mess.

cheers!
mar77i

Re: [dev] High Order Calculator

[Martti Kühne]

Yay. Nice find. That's the most non-bullshit interpreter I've seen.

cheers!
mar77i

Re: [dev] Mailing lists sucks.

[Martti Kühne]

We could write our own time-diluted message transmission protocol.

cheers!
mar77i

[dev] Announcement: Backporting the fun into C

[Martti Kühne]

Hello community

>From the perspective of someone who started off with the fairy-tale
technologies in web development, I find working with C proves as quite
an interesting experiment. I used to slip into rewriting more or less
the same things for different code bases and it really irks me that
there are virtually no interfaces that depict flows and
transformations that are used all the time when writing code. So I
started working on my own "STL", a library which I use as my main code
pivot [0].

With the techniques applied by the two central data types/interfaces,
bulk.{c,h} and buffer.{c,h}, my code becomes more or less memory safe
and fun to work with, as if I was using one of those fancy languages
that take all that work away from me, without having to leave the
realms of standard C. This might partially be the case because these
data types are of my own design and I have their details in the back
of my mind, but I think it does go further than just that. I coded up
a few more projects [1], [2] based on the prospects this has added to
my programming capacities and they enabled me to catch up with my own
webserver [3] as well.

My experience with suckless software has shown me pretty clearly that
the tradeoffs in code quality around here are not really acceptable
for code that I wanted both to release or work on myself, and let's
face it, it doesn't help to just pretend these issues don't exist.
That also means, no, I won't cut corners like to leave the releasing
of resources and file descriptors to the operating system or use die()
in what is supposed to be library code where error handling must
clearly be up to the caller. Other people should actually be able to
write programs with it, too, as that's a legitimate aspect of the term
library.

Really, thanks for getting me into C, but no thanks for the dragons
that I started to recognize learning it.

cheers!
mar77i

[0] https://github.com/mar77i/bulk77i/
[1] https://github.com/mar77i/calc77i/
[2] https://github.com/mar77i/ccheck/
[3] https://github.com/mar77i/web77i/

Re: [dev] Announcement: Backporting the fun into C

[Martti Kühne]

On Sun, Nov 22, 2015 at 7:22 PM, hiro <23h...@gmail.com> wrote:
> martti: you wanna build a framework?
>

...is it reinventing the wheel every time you live for?

cheers!
mar77i

Re: [dev] Announcement: Backporting the fun into C

[Martti Kühne]

Currently this work is about exploring the possibilities, the
limitations and the ease that comes from bulk and buffer which I can
tune precisely to fit my needs. I looked at all the languages that
were fun to work with and asked myself whether I was capable to take
that fun into standard C. I wrote the library to fit my personal
needs, so no I don't aim at deploying this as enterprise framework
code, which would be... a bit creepy, since I do *not* know how well
it fits security standards or any particular purpose blah blah.

The thought process is, I let you laugh just that much, quite the same
as if I said yes, however to simply dismiss the cause of all your
programming errors stemming from best-guessing the problems at hand
becomes not more, but evidently less appealing to work with, harder to
debug and all these bad things over time. If the point where two
concepts would naturally meet isn't utilised to ultimately draw a line
of abstraction, what good would come of the term "development" even
and, let me be blunt, what good does it do to even have functions if
you can't tell which of them even calls another.

cheers!
mar77i

Re: [dev] [st] Reporting a Segmentation fault

[Martti Kühne]

On Fri, Nov 20, 2015 at 9:00 PM, Greg Reagle  wrote:
> That's right--buf is accessed without bounds checked.  The problem is in
> ttyread() in the while loop, buf gets overflowed, i.e. ptr - buf exceeds
> BUFSIZ (8192).  Haven't figured out how to remedy the problem (yet).
>
>


What makes you think this is an overflow? The leading one-bits in clen
to me clearly hint that this happens through forming a negative
buflen, hence my use of the word underflow.
Apart from that, I still get segfaults with even this overly
pessimistic check in the code:

while ((charsize = utf8decode(ptr, , buflen)) &&
  buflen - charsize > 0 && ptr - buf + charsize < BUFSIZ - 4) {
tputc(unicodep);
ptr += charsize;
buflen -= charsize;
}

The underflow on my gdb test being in the minus hundred thousands even
makes it look as if it was something else like the read() call that
overflowed. Eww.

cheers!
mar77i

Re: [dev] [st] Reporting a Segmentation fault

[Martti Kühne]

On Fri, Nov 20, 2015 at 2:09 PM, Marc Collin  wrote:
> I am using the grsec kernel, for better security. Maybe st doesn't
> play well with that?
> Just tested on a clean st and it segfaults too.
>

I'm not familiar with the details of grsecurity, but it's definitely
not about parsing escape sequences.
Do you have a .vimrc or /etc/vimrc file, and if you have, can we get it?

cheers!
mar77i

Re: [dev] [st] Reporting a Segmentation fault

[Martti Kühne]

Hahaha.
I can clearly see this happen in the code in ttyread().
You don't even exist for this code.

cheers!
mar77i

Re: [dev] [st] Reporting a Segmentation fault

[Martti Kühne]

I can generally reproduce this reliably using
$ st -e cat /dev/urandom
In what way the underflow of buflen is caused though, I have not yet
been able to determine.
One aspect of the problem is definitely that buflen is generally never
range-checked.

cheers!
mar77i

Re: [dev] [farbfeld] announce

[Martti Kühne]

Since your original announcement contained no information on the
matter, all your 16 and 32 bit numbers are network endian, right?

cheers!
mar77i

Re: [dev] paste@

[Martti Kühne]

Reading what hiro had to say about the topic makes it sound as if we
just needed a wiki "pastebin" section that has built-in "archiving"
(git rm) feature that builds on git's built-in feature of preserving
history.
Maybe we could write clients that don't give a shit whether such an
entry was archived and BAM - problem solved?

cheers!
mar77i

Re: [dev] paste@

[Martti Kühne]

On Fri, Nov 6, 2015 at 4:00 PM, Christoph Lohmann <2...@r-36.net> wrote:
> Yes,  that’s  a good proposal. Then all available Unix tools can be used
> to sort, find duplicates and make some order. Maybe it could be  a  dif‐
> ferent  git repository to avoid overlapping merges. There could be still
> discussions on hackers@ about pastes. A web  interface  couldsatisfy
> the hipsters fraction and Google.
> By  having  a  separate repository it could run without moderation. Only
> a file limit restriction would be needed. If things go wrong, remove the
> repository.  By  still  sending changes to hackers@ we have some control
> over abuse.
>

A separate git repository will do. I do not have the power to open it
and hook it up to the mailing list. Volunteers?

> The  problem  here is a bit the Wikipedia problem: I would like to setup
> my own Wikipedia mirror but PHP and some ugly SQL backend are keeping me
> away  from  it. There is no sane data export available but SQL dumps. If
> Wikipedia would be some public git repository it would be easier to have
> overlays by using something like the unionfs and running the common wiki
> web interface on top of this new directory. That seems easier than  hav‐
> ing  some  SQL  database  doing  an inefficient sync every month. And it
> doesn’t add the PHP dependency. This problem adheres to the web and  its
> cruft we need to solve.
>

Please move your outline of a antioraclepedia (in the tradition of
antiword) converter to a different thread if you have serious
intentions to discuss it further.

cheers!
mar77i

Re: [dev] dmenu segfaults when pressing control+enter without a selection

[Martti Kühne]

On Sun, Oct 18, 2015 at 1:22 AM,   wrote:
> [...] why reply to this thread? [...]
> [it] is just a waste of time.

Enlightenment was so close that day.

cheers!
mar77i

Re: [dev] dmenu segfaults when pressing control+enter without a selection

[Martti Kühne]

On Fri, Oct 16, 2015 at 10:38 PM, 7heo <7...@mail.com> wrote:
> Sent: Friday, October 16, 2015 at 10:28 PM
> From: "Matthew of Boswell" 
> To: dev@suckless.org
> Subject: Re: [dev] dmenu segfaults when pressing control+enter without a 
> selection
>
>> [...] willing to clone from git and compile
>> from source
>
> You make it sound like an achievement...
>


You make it sound as if a mortal found the way to this place.

cheers!
mar77i

Re: [dev]

[Martti Kühne]

Congratulations.
You put the email address you were supposed to use into the message body.

cheers!
mar77i

Re: [dev] [dwm] Fullscreen clients not resized on X display resolution change

[Martti Kühne]

If a patch that implements said _NET_WM_STATE_FULLSCREEN won't add a
lot of boilerplate code, it'll probably be accepted in mainline, least
of all it's definitely welcome on the wiki. Other than that, I'm not
sure how hard it is to un- and refullscreen the sxiv window.

cheers!
mar77i

Re: [dev] A chance for a suckless web?

[Martti Kühne]

I read about AMP some time this week.
Reading into it, I think prohibiting all input elements except for the
button seems like a huge step towards interactivity, so that websites
could use image maps as on-screen keyboards and, like, build huge
microsoft access like applications, webshops and all.
Let's write a php framework around that.

cheers!
mar77i

Re: [dev] [dvtm] dvtm seems to be only terminal not affected by GNU/Linux ecosystem bug I found

[Martti Kühne]

I think the bug is located in the terminal emulation code related to
handling of alternate screens with regards to resizing. It's not
technically wrong to truncate a screen area that is located off
screen.

While we're at it, can we give you something relevant to work on?

Cheers!
mar77i

Re: [dev] [st] vim mouse not working

[Martti Kühne]

Generally, mouse interaction is fully implemented and produce the
correct sequences.
As I don't use vim, however, I'm not sure what vim does right or wrong
in this case.
A quick google reveals that there are several different mouse-related
options, one of which is ttymouse. What's that set to in your config?

cheers!
mar77i

Re: [dev] surf release?

[Martti Kühne]

On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung m...@umaxx.net wrote:
 You're right in that package maintainers can't tell where the fixes
 and new features are coming in, they'll not introduce their own
 releases.

 Right, you disproved your own sentence above.


No need to get nitpicking, I saw and still see the counterargument
beneath overweighing the one in favor.

  in that configuration
  changes require recompiling of the respective binary.

 There are package managers which allow very easy re-compiling of
 packages with own patch-sets, especially due to projects like suckless.
 Several people, still prefer re-compiling of packages based on the given
 releases. Because from sysadmin point of view, packages are always
 wanted and preferred over random source builds.


From the average suckless user's view, knowing what source is compiled
and what config included is always wanted and preferred over other
people's builds.

 Releases hence make sense for software that fits everyone's needs with
 their configuration files, which is untrue either for most suckless
 projects.

 Releases make sense for several reasons, even for suckless projects and
 and adding a tag is not hard, right?


I'm not going to tell other people what to do. Good luck.

cheers!
mar77i.

Re: [dev] [Idea] Using GitTorrent

[Martti Kühne]

On Mon, Jun 1, 2015 at 5:06 PM, Ivan Tham ivanthamjun...@gmail.com wrote:
 On Sun, May 31, 2015 at 05:01:46PM +0200, Martti Kühne wrote:

 ...everywhere...

 that should obviously git.suckless.org there. :-)


 It is just in case that there are 10,000 downloads per minute,
 git.suckless.org will be seeding and those other downloader will help in
 the progress.




How by Dennis Ritchie's beard don't you see that's not gonna happen?
Nobody cares about suckless, give or take a few afficionados.

cheers!
mar77i

Re: [dev] [Idea] Using GitTorrent

[Martti Kühne]

On Mon, Jun 1, 2015 at 5:16 PM, Ivan Tham ivanthamjun...@gmail.com wrote:
 Be confident for apps that suck less. Drop confident for apps that suck
 more. More importantly, **The Author Should Suck Less**

 I don't mean any insults. And if I did it, sorry.


I don't see suckless software shipped to people who wouldn't know why
to prefer this confusing and pretty terrifying setup from the
1980ies (paraphrasing my former employer) over Ubuntu Unity. there's
no reason for most people in the world to ever use a terminal
emulator.

Re: [dev] surf release?

[Martti Kühne]

No it wouldn't help downstream package maintainers.
You're right in that package maintainers can't tell where the fixes
and new features are coming in, they'll not introduce their own
releases.
However upstream is not everyone's taste either, in that configuration
changes require recompiling of the respective binary.
Releases hence make sense for software that fits everyone's needs with
their configuration files, which is untrue either for most suckless
projects.

cheers!
mar77i

Re: [dev] surf release?

[Martti Kühne]

On Mon, Jun 1, 2015 at 7:08 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote:
 Martti Kühne said:
 However upstream is not everyone's taste either, in that configuration
 changes require recompiling of the respective binary.

 Exactly!  I have a big patch for surf 0.6; it takes time to adopt these
 changes to current snapshot, and there are better ways to waste that
 time then to cherry-pick the changes.

 You may argue that I could follow the development closely and update my
 patch with every commit.  But that actually requires even more time, and
 yet more time to build every revision.

 My solution is simple - I have a patch against surf package (which is -
 wait for it! - of latest *version*).  This way I only have to modify my
 patch with every release.  This works perfectly when maintainer indeed
 bumps package version when user-visible feature lands in source tree.
 Of course, this fails miserably when maintainer doesn't grasp the
 concept of version.



You raise a valid point there regarding patches. surf is one of the
larger projects in suckless, and porting a patch to HEAD may not be as
trivial as an additional function in, say, a majority of dwm patches,
which usually fail because the patch tool can't fit them into the
right context. Did you release your big patch to the public? Is it
that hard to port it to HEAD?

I am not the guy who maintains the surf repository. And it's his
decision and his behind to lift, and I also can't tell you how heavy
that is.

cheers!
mar77i

Re: [dev] [Idea] Using GitTorrent

[Martti Kühne]

On Sun, May 31, 2015 at 8:59 PM, Anselm R Garbe garb...@gmail.com wrote:
 The good thing about elite projects is, that only a bunch of people
 will actually clone per day ;)



...which stumps the argument about whether to implement bittorrent for
a bunch of clones per day. Bt's decentral design only makes sense
for a few high traffic repositories like the linux kernel. But for the
more or less sucking hipster repo, the correct wording for it can be
assumed an utterly pointless waste of time.

cheers!
mar77i

Re: [dev] [Idea] Using GitTorrent

[Martti Kühne]

...
 Also what's wrong with git repos at a central project-related place?


It's good thinking by OP, there's just too much traffic to host dwm
everywhere if 100,000 people per minue are cloning.

cheers!
mar77i

Re: [dev] [sbase] [PATCH v2] tar: support -f - as stdin/out

[Martti Kühne]

On Tue, May 12, 2015 at 3:59 PM, FRIGN d...@frign.de wrote:
 On Tue, 12 May 2015 13:57:11 +
 Eivind Uggedal eiv...@uggedal.com wrote:

 Hey Eivind,

   tarfd = 1;
 + tarfd = 1;
 - tarfd = 0;
 + tarfd = 0;

 don't use explicit file-numbers. Use the names provided
 by the stdlib (stdin, stdout, stderr) instead.
 And next time, please write some text to accomodate your
 patches, so people know what you changed.
 Additionally, this is common E-Mail etiquette, which I
 value highly.



I'd suggest STDIN_FILENO and STDOUT_FILENO?

cheers!
mar77i

Re: [dev] [dwm] [PATCH] support _NET_SUPPORTING_WM_CHECK

[Martti Kühne]

On Wed, May 6, 2015 at 10:25 PM, Jason Woofenden ja...@jasonwoof.com wrote:
 As documented here: 
 http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317670464
 ---

 I developed this in the hopes that it would fix issues with feh running
 fullscreen. It didn't help with that (feh using the innacurate _MOTIF_WM_HINTS
 method) but it should at least stop gtk+ 3.3.8+ from polling regularly for WM
 features.

 The change to gtk+ is discussed here: 
 https://bugzilla.gnome.org/show_bug.cgi?id=666921


  dwm.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/dwm.c b/dwm.c
 index 169adcb..1e53a68 100644
 --- a/dwm.c
 +++ b/dwm.c
 @@ -62,7 +62,7 @@ enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor 
 */
  enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */
  enum { NetSupported, NetWMName, NetWMState,
 NetWMFullscreen, NetActiveWindow, NetWMWindowType,
 -   NetWMWindowTypeDialog, NetClientList, NetLast }; /* EWMH atoms */
 +   NetWMWindowTypeDialog, NetClientList, NetSupportingWMCheck, NetLast 
 }; /* EWMH atoms */
  enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default 
 atoms */
  enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle,
 ClkClientWin, ClkRootWin, ClkLast }; /* clicks */
 @@ -1526,6 +1526,7 @@ setup(void) {
 netatom[NetWMWindowType] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE, 
 False);
 netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, 
 _NET_WM_WINDOW_TYPE_DIALOG, False);
 netatom[NetClientList] = XInternAtom(dpy, _NET_CLIENT_LIST, False);
 +   netatom[NetSupportingWMCheck] = XInternAtom(dpy, 
 _NET_SUPPORTING_WM_CHECK, False);
 /* init cursors */
 cursor[CurNormal] = drw_cur_create(drw, XC_left_ptr);
 cursor[CurResize] = drw_cur_create(drw, XC_sizing);
 @@ -1744,6 +1745,12 @@ updatebars(void) {
 m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh, 
 0, DefaultDepth(dpy, screen),
   CopyFromParent, DefaultVisual(dpy, 
 screen),
   
 CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
 +   XChangeProperty(dpy, root, netatom[NetSupportingWMCheck], 
 XA_WINDOW, 32,
 +   PropModeReplace, (unsigned char *) 
 (m-barwin), 1);
 +   XChangeProperty(dpy, m-barwin, 
 netatom[NetSupportingWMCheck], XA_WINDOW, 32,
 +   PropModeReplace, (unsigned char *) 
 (m-barwin), 1);
 +   XChangeProperty(dpy, m-barwin, netatom[NetWMName], 
 XA_STRING, 8,
 +   PropModeReplace, (unsigned char *) dwm, 3);
 XDefineCursor(dpy, m-barwin, cursor[CurNormal]-cursor);
 XMapRaised(dpy, m-barwin);
 }
 --
 2.1.4




Is this one for the wiki or mainline?

cheers!
mar77i

Re: [dev] [st] [PATCH] Fix sigchld

[Martti Kühne]

The initial patch seems to cover edge cases I fail to grasp and
probably doesn't cover all scenarios.
Could someone please tell me why SIGCHLD should be received while
requiring waitpid to WNOHANG, and why st prints an error message for
nonzero exit status instead of propagating it?

I haven't read koneu's suggestion yet, I hope it doesn't leave as much
room for questions.

cheers!
mar77i

Re: [dev] [st] [PATCH] Fix sigchld

[Martti Kühne]

Indeed the second question applies for koneu's patch, too.
I want the shell's exit status reflected in the terminal's. Otherwise,
to retreive the shell's exit status, one needs to make silly use of
pipe(), in case one uses st as an output layer, for whatever reason.

cheers!
mar77i

Re: [dev] books that rock

[Martti Kühne]

And from a time when unix was about to happen, or let's call it the
mindset that made it happen, I'm really very fond of Chris Brooks'
The Design Of Design.

cheers!
mar77i

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

[Martti Kühne]

On Wed, Apr 22, 2015 at 4:14 PM, Garrick Peterson garri...@gmail.com wrote:
[...]
   for (cp = dc.col; cp  dc.col[LEN(dc.col)]; ++cp)

 Forgive my ignorance of the LEN macro, but doesn’t this rely on accessing a 
 memory address outside of the allocated array? Wouldn’t that cause problems 
 if you’re up against memory boundaries? I would personally write it as either
 for (cp = dc.col; cp = dc.col[LEN(dc.col)-1]; ++cp)
 or even better
 for (cp = dc.col; cp - dc.col  LEN(dc.col); ++cp)



The only way to obtain the upper end pointer that cp is compared to
is to evaluate dc.col + sizeof(dc.col). No dereference of the value
that address holds is required.

cheers!
mar77i

Re: [dev] [st] [PATCH 2/5] Replace for with while.

[Martti Kühne]

Are we discussing something for which #include stdint.h does not
leave any questions open? int32_t, int_fast32_t or int_least32_t would
probably be the solution here?
Is there any problem with using stdint.h in general that I'm not aware of?

cheers!
mar77i

Re: [dev] [dwm] Style changes

[Martti Kühne]

On Sat, Apr 11, 2015 at 4:10 AM, Aaron Burrow burrows.l...@gmail.com wrote:
 If we're going to fix a bunch of formatting problems we should make
 sure the problem doesn't resurface.  Put a commit hook on the git
 server that either validates formatting or does auto-formatting.



It's a really awkward thing to suggest automagic for suckless.
But seriously, all we were looking for was a script that would modify
the contents of what users commit, because fuck their tastes, their
checksums and their general expectations.

cheers!
mar77i

Re: [dev] [style] variable declaration locations and varriable length arrays vs malloc

[Martti Kühne]

On Tue, Mar 3, 2015 at 12:56 AM, Anthony J. Bentley anth...@cathet.us wrote:
 Evan Gates writes:
 Declaring variables at the top of a block, as opposed to top of the
 function has a few uses, but the most useful (in my limited
 experience) is combining it with C99's variable length arrays to
 create buffers without calls to malloc/free. For example:

 while ((d = readdir(dp))) {
 char buf[strlen(path) + strlen(d-d_name) + 1];
 
 }

 VLAs are a fundamentally broken feature because they do not allow any
 error checking. alloca() is the same.



alloca() isn't even standard C, that's some black voodoo GNU sorcery
right there.
You should use one buffer, and that buffer's length is some PATH_MAX
or a balloonable realloc.

cheers!
mar77i

Re: [dev] script for launching surf

[Martti Kühne]

On Tue, Mar 3, 2015 at 10:14 PM, Greg Reagle greg.rea...@umbc.edu wrote:
 /usr/local/bin/surf is a lot of typing compared to surf.



There's probably a command builtin for your shell. However if you're
saving typing inside a launcher script you write, you might be saving
it in the wrong place.

This whole discussion appears awfully familiar.
http://xkcd.com/1319/

cheers!
mar77i

Re: [dev] Suckless unit testing in C?

[Martti Kühne]

1. You have a part you have to test, write a test program covering the
*important* functionality. If your module contains a few objects with
interfaces, write one test creating, modifying and destroying these
objects as you see fit.
Writing an interface is work, but it is also a set of strings that let
you forget the puppet and yes, you will spend some time debugging
errors *inside* the interfaced  objects.

2. If your program does X and uses the above-mentioned interfaces, the
mere fact that your program actually *does* X will be proof enough
that - wait, no, sorry openssl, it was not.
For debugging, you can write state and intermediate values to standard
file descriptors or valgrind/ltrace up to some point, and your
compiler may provide you with features that let you wrap function
calls so that you can profile the program in other ways in which you
see fit, which then still might not give you any more power as the
mentioned tools.

3. If you insist in using a test framework, here, have [0]. The
concept is a single line of preprocessing code you can extend to
whatever you want to do with it. However let me explain for a minute
why I think that mutest might not be such a good idea. Instead you
should read the specification for the programming language [1] and any
further tools and libraries you are using, because whatever interfaces
from third-parties you're going to use are what will be making your
life hell because you will at some point do something with these tools
they might not yet have covered.

cheers!
mar77i

[0] http://www.llucax.com.ar/proj/mutest/
[1] http://iso-9899.info/n1256.html

Re: [dev] [st] can't use Xterm font

[Martti Kühne]

Another option to find the font that I would apply for this class of
problem is to grep through strace's output... But maybe I'm just too
lazy to take the whole GUI magic too serious.

cheers!
mar77i

Re: [dev] [st] crash on font resize (patch inside)

[Martti Kühne]

Hmm. I have two style questions about that patch, or about the lines
it was crafted upon.
Firstly, I did not know C required backslashed newlines for
continuation, but a bit more confusingly, usage() IMHO shouldn't
really exit the program with nonzero, especially if there's a
non-erroneous way to trigger it like --help.

cheers!
mar77i

Re: [dev] A simple but flexible alternative to cron

[Martti Kühne]

On Sat, Feb 7, 2015 at 8:30 AM, Eric Pruitt eric.pru...@gmail.com wrote:

 Each of the scripts has two functions defined: condition, which exits
 [...]

SCNR, but didn't you mean to write crondition?

cheers!
mar77i

Re: [dev] [st] delele behaves as backspace... again

[Martti Kühne]

On Tue, Nov 4, 2014 at 7:24 PM,  k...@shike2.com wrote:
 If you are interested,

   - Modify the keys generated by st. This option is not dificult, 
 because you
   only have to modify the values in your config.h (I think I should put 
 this
   option in the FAQ to).

 If you are interested in this solution this is the patch:

 diff --git a/config.def.h b/config.def.h
 index 1667ed6..af7b2a0 100644
[...]


Thanks k0ga. I have not taken the time to check whether this is on the
wiki or on git, but last week I updated my suckless software packages
and patches and to have this was definitely a good thing.

cheers!
mar77i

Re: [dev] K, a low-level procedural imperative programming language

[Martti Kühne]

Urm, relevant. From [0]:

I always have it in the back of my head that I want to make a slightly
better C. Just to clean up some of the rough edges and fix some of the
more egregious problems. But getting everything to fit, top to bottom,
syntax, semantics, tooling, etc., might not be possible or even worth
the effort. As it stands today, C is unreasonably effective, and I
don't see that changing any time soon.

cheers!
mar77i

[0] http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

Re: [dev] Object-Oriented C for interface safety?

[Martti Kühne]

On Wed, Nov 26, 2014 at 10:55 PM, pancake panc...@youterm.com wrote:
 Try Cello



I did try Cello. Cello turned out absolutely useless for me as
interfacing it with other C standard types is a PITA / completely
broken. After fiddling around for a while I got sick from what Cello
does with code I would write and gave up. Seriously, any attempt to
emulating duck typing in C is a  joke and should be wiped off the face
of this planet. With fire. Creating an actual interface layer on top
of C as those intermediate languages do might look like an option, but
then you're left there with your own implementation of guile - or
worse, javascript. From where there's nothing left to do wrong any
longer.
I then started trusting my C skills again and wrote whatever I was
attempting to do in plain C - and it worked.

cheers!
mar77i

Re: [dev] Does suckless need a separate list for general discussion?

[Martti Kühne]

This thread is the usual meta-OT we keep running into here because
somebody's sarcasm detector had failed them. How can you even get up
in the morning without philosophical justification?

Re: [dev] Unsubscribe

[Martti Kühne]

https://youtu.be/nEF_-IcnQC4

Re: [dev] [sbase][patch]cat stdin if arg is exactly - not begins with '-'

[Martti Kühne]

On Tue, Nov 18, 2014 at 10:50 PM, Evan Gates evan.ga...@gmail.com wrote:
 This patch makes
 cat -- -foo
 cat the file ./foo and not stdin.


Wait ./foo or ./-foo ? IMHO it should output the latter.

cheers!
mar77i

Re: [dev]

[Martti Kühne]

Cold water, maybe?

https://i.ytimg.com/vi/zehSKo5CJWY/hqdefault.jpg

Re: [dev] slock segfault on rhel7

[Martti Kühne]

http://git.suckless.org/slock/tree/slock.c#n84

from manpage about line 69: getspnam,: Routines return NULL if no
more entries are available or if an error occurs during processing.

cheers!
mar77i

Re: [dev] slock segfault on rhel7

[Martti Kühne]

On a later note, I'm pretty sure I haven't read the preprocessing
#ifdef/#ifndef stuff correctly. But I'm pretty positive that there's
no LDAP password checking implemented (or a getenv(USER) that
wouldn't work on these functions). So, the question is, are we certain
over what Johan is expecting here? I do see there is indeed error
checking on these functions, and in what way should slock be behaving
in this case?

cheers!
mar77i

Re: [dev] [st] delele behaves as backspace... again

[Martti Kühne]

On Tue, Nov 4, 2014 at 9:11 PM, Henrique Lengler
henriquel...@openmailbox.org wrote:

 Output of infocmp attached: out.txt

 Output of ^VDelete:

 ^[[3~



You appear to have mistyped something. CSI requires only one bracket.

cheers!
mar77i

Re: [dev] environment variables versus runtime configuration (rc) files versus X resources

[Martti Kühne]

On Mon, Nov 3, 2014 at 10:30 PM, Brandon Mulcahy bran...@jangler.info wrote:
 choice (besides doing something like `export option=a; command; export
 option=b`). I do wish the concept of aliasing were a bit more general.


Did you hear of the shell feature where you could immediately pass
environment variables by prepending them to your command?
Like so:

export option=b;
option=a command;
echo $option # shows b

cheers!
mar77i

Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)

[Martti Kühne]

On Fri, Oct 31, 2014 at 4:48 PM, FRIGN d...@frign.de wrote:

 Or we go the Stalin-way, kill all members of the W3C and dictate our own
 standards.



How quickly do you think you can do that? This sounds just too good to
be true...

cheers!
mar77i

Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

[Martti Kühne]

On Mon, Oct 27, 2014 at 3:01 AM, dequis d...@dxzone.com.ar wrote:
 The background/foreground of selected text is currently set by setting
 ATTR_REVERSE, which flips its normal bg/fg. When the text being
 selected has the same bg and fg, it won't be readable after selecting
 it, either.



This may sound trivial, but.
How about you paste it somewhere else?

cheers!
mar77i

Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

[Martti Kühne]

in config.h something along the lines of

enum {

} color_mode;
struct {
}
static const int select_same[2] = { 7, 0 };
static const int select_different[2] = { REVERSE, REVERSE };

or any pair of ints

Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

[Martti Kühne]

in config.h something along the lines of

enum color_mode {
  REVERSE,
  COLOR,
};
struct selection_colors {
  enum color_mode;
  int colors[];
}
static const struct selection_colors same = { .color_mode = COLOR,
.colors = { 7, 0 } };
static const struct selection_colors different = { .color_mode = REVERSE };

Sorry for the previous email. My email client went crazy on me.

cheers!
mar77i

Re: [dev] SGI Irix look (4Dwm)

[Martti Kühne]

 Who are we talking about? *I* use free software. Despite that, I can't
 fully trust what my computer is doing, because I can't verify the
 hardware the software runs on isn't doing something malicious. I also
 can't verify that my hardware isn't emitting signals that some
 malicious person is picking up via some sort of device
 [https://www.usenix.org/legacy/events/sec09/tech/full_papers/vuagnoux.pdf
 and others], nor can I easily verify that a TLS key that I'm
 protecting my connection with isn't extremely weak, and in otherwords,
 my communication is actually completely insecure. Nor, can I assume,
 in this day and age, that there aren't a crap ton of other errors in
 the TLS protocol, or bugs (keep in mind this is in free software
 implementations) in the implementations that make me no more unsafe
 than running blobs.


Interesting. You're making it sound as if your TLS implementation
would be any safer if it wasn't free software. How safe do you want to
be, and for that matter, how safe do you *need* to be. Security is an
economic thought, after all.

cheers!
mar77i

Re: [dev] SGI Irix look (4Dwm)

[Martti Kühne]

Your top posting style is more than confusing. I first took your
quoting of Andrew's Email for plagiarism.
Could you at least prefix quoted lines?

cheers!
mar77i

Re: [dev] golang: time.Tick() and ntp

[Martti Kühne]

On Thu, Oct 9, 2014 at 3:54 PM,  sta...@cs.tu-berlin.de wrote:

 the status bar is not selectable, or modifiable, it is not even
 read-only (you can't save it, colpy it etc.), it is look-at-only.


...sorry, but what about screenshots?

cheers!
mar77i

Re: [dev] [RFC] Design of a vim like text editor

[Martti Kühne]

On Wed, Sep 24, 2014 at 10:50 AM, Marc Weber marco-owe...@gmx.de wrote:
 Rewriting an editor? Have a a look at existing solutions

You forgot to mention the historic example for a group of people that
aimed at everything DIY and got stuck with an over-bloated text editor
which some people jokingly call a great OS btw, lacking only a decent
text editor. You know, the one that comes with its own LISP
interpreter...

cheers!
mar77i

Re: [dev] [RFC] Design of a vim like text editor

[Martti Kühne]

I like javascript, and I would love to see more Javascript in
suckless software.

In JavaScript I can abuse the lack of a typesystem, and can
build functions that return configurable, callable
objects, returning other objects for which is given what data they
will hold and what functions they will execute.

With functions taking such factories as arguments
I have an even more powerful tool at hand than C++ templates
and only need to define in what spot what object can decide
what is done.

Would you, in memoriam of this accidental C++ thread,
include javascript highlighting in vis?

cheers!
mar77i

Re: [dev] ping

[Martti Kühne]

On Thu, Sep 4, 2014 at 11:57 AM, Dimitris Papastamos s...@2f30.org wrote:
 test e-mail.


Test failed.

cheers!
mar77i

Re: [dev] [st] Proposal of changing internal representation

[Martti Kühne]

On Sun, Aug 24, 2014 at 4:56 PM, Christoph Lohmann 2...@r-36.net wrote:
 [0] http://canonical.org/~kragen/strlen-utf8.html


A 503 page for which google puked a c++ snippet. Good joke...

cheers!
mar77i

Re: [dev] [st] Proposal of changing internal representation

[Martti Kühne]

Work on this is definitely appreciated. Whenever I come about to pull
newest versions of the suckless projects I use. I'm a rather lazy
compiler when it comes to these, tho... :D

Re: [dev] [st] will global-less changes be wanted upstream?

[Martti Kühne]

On Sun, Aug 17, 2014 at 7:04 PM, Steven Degutis sbdegu...@gmail.com wrote:
[...]
 does not allow. Otherwise the application would be limited to only
 ever having one terminal emulator open, which seems to me like a
 severe limitation.
[...]


This. This is a feature. You're seriously suggesting to only have one
terminal open ever? That's great, so I would always find my terminal
multiplexer session on that window...

cheers!
mar77i

Re: [dev] [st] possibly redundant check in techo

[Martti Kühne]

No.
Github isn't a workbench that is public by accident. By uploading to
Github you release your project to the public. Start treating it that
way and start treating projects you incorporate into your code in a
way that makes you look like a responsible human being.

cheers!
mar77i

Re: [dev] [st] possibly redundant check in techo

[Martti Kühne]

Do we sound like we want an additional clause in the license?

Addendum: In case source files are split from this license document in
a different directory structure, help us find the license by noting
the path with huge ASCII-art characters in every affected source file.

cheers!
mar77i

Re: [dev] Introducing the imagefile-format

[Martti Kühne]

On Tue, Jul 29, 2014 at 1:37 AM, Staven pvl.sta...@gmail.com wrote:

   width = (hdr[9]  24) | (hdr[10]  16) | (hdr[11]  8) | hdr[12]
   height = (hdr[13]  24) | (hdr[14]  16) | (hdr[15]  8) | hdr[16]



To reiterate this, each of these parenthesized expressions is in
native byte order *already*, if I understand the C standard correctly,
and ntohl/htonl would only have any impact if we bit off the whole
word in one byte. Pleasee don't make a mess with both of these
functions.

cheers!
mar77i

Re: [dev] Introducing the imagefile-format

[Martti Kühne]

On Tue, Jul 29, 2014 at 12:17 PM, Martti Kühne mysat...@gmail.com wrote:
 and ntohl/htonl would only have any impact if we bit off the whole
 word in one byte. Pleasee don't make a mess with both of these

..in one bite. Damn.

cheers!
mar77i

Re: [dev] [st] Colors

[Martti Kühne]

This might be a bit over the top, I'll still reuse it, as it's
somewhat relevant to the topic.
So, why would you only want to customize the colors? Why not go full
pikachu [0]!?

cheers!
mar77i

[0] http://jeanguyomarch.github.io/pikalogy/

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Fri, Jul 18, 2014 at 2:04 PM, Köhring, Norman ko...@mailbox.org wrote:
 I thought we already skipped the intermediate bytes? Is there any worth having
 them? Also, regarding the magic number: Image is a very common description. We
 could also think about words like “picture” (or “pic”) or use some 
 abbreviation
 of “simple image format”: SIF or SIMG?

 The format could look like MAGIC FORMAT WIDTH HEIGHT DATA. That results in for
 example:
 SIMGRGBA16000900[data]

... .SLG?

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Fri, Jul 18, 2014 at 2:14 PM, FRIGN d...@frign.de wrote:
 On Fri, 18 Jul 2014 14:04:17 +0200 (CEST)
 Köhring, Norman ko...@mailbox.org wrote:

 I thought we already skipped the intermediate bytes? Is there any worth 
 having
 them?

 No. I assumed we also already ditched the ASCII-approach and went for
 binary-16 or 32-bit-BE-integers


Let's just disagree. Let's build a meta image framework in python that
creates the format code you like.

cheers!
mar77i

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Fri, Jul 18, 2014 at 2:15 PM, Martti Kühne mysat...@gmail.com wrote:
 On Fri, Jul 18, 2014 at 2:14 PM, FRIGN d...@frign.de wrote:
 On Fri, 18 Jul 2014 14:04:17 +0200 (CEST)
 Köhring, Norman ko...@mailbox.org wrote:

 I thought we already skipped the intermediate bytes? Is there any worth 
 having
 them?

 No. I assumed we also already ditched the ASCII-approach and went for
 binary-16 or 32-bit-BE-integers


 Let's just disagree. Let's build a meta image framework in python that
 creates the format code you like.


Seriously. Enabling end users to create their own image formats they
want is a whole new scope we haven't considered yet. We just need an
image format specification server somewhere which provides a
webservice from where you could download the image decoding code. The
same thing is done with gpg keys already, so we could integrate gpg
keyservers into the whole process...

cheers!
mar77i

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Fri, Jul 18, 2014 at 2:19 PM, Martti Kühne mysat...@gmail.com wrote:
 webservice from where you could download the image decoding code. The
 same thing is done with gpg keys already, so we could integrate gpg
 keyservers into the whole process...



Business idea: Let's sell closed formats on those servers, serving
formats signed with secret keys and formats.

cert authorities likely won't approve, but we're not here to make
everyone happy, right?

cheers!
mar77i

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Wed, Jul 16, 2014 at 2:02 PM, FRIGN d...@frign.de wrote:
 Why not do it like this:

 9   imagefile
 1   0x20
 var width
 1   0x20
 var height
 1   0x00

 and work with it like this:


Yes. I had that in mind as well.

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

Neither the endianness nor the maximum width is in question for
space-separated human readable, variable width numbers.

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Mon, Jul 14, 2014 at 8:54 PM, Charlie Murphy cmsmur...@gmail.com wrote:
 Hello,

 Is there an image format that's simpler than PPM and that supports
 alpha transparency?  PPM's syntax is too flexible; to parse an image
 you have to skip arbitrary whitespace in the header.  You can't
 simply read() it.

 I'm looking for something like this[1] but with conversion tools for
 other formats.

 Charlie Murphy

 [1]: http://pastebin.com/vZEcxte3



Looks pretty okay to me, except, I'm in favor of replacing the last
blank in the header by NUL, because then you could avoid the dprintf,
of which I'm not sure how standardized it is.
Also, on line 49 you have a symbol naming error - no, you shouldn't
name one datap, and the other data.

cheers!
mar77i

Re: [dev] Looking for simple, alpha supporting image format

[Martti Kühne]

On Tue, Jul 15, 2014 at 1:51 PM, Martti Kühne mysat...@gmail.com wrote:
 Looks pretty okay to me

Meaning I would help you writing a converter to png, then some
standard library could do the rest, like *magick.

cheers!
mar77i

Re: [dev] [sandy] [PATCH] VIM key bindings.

[Martti Kühne]

On Wed, Jul 9, 2014 at 10:22 PM, Dimitris Zervas dzer...@dzervas.gr wrote:

 Yes! I was really worried about cancelling your precious work, but with 2 
 configs, we're happy :)
 I am now working on multiplying commands (5x will delete 5 chars, etc) and 
 then I'll clean up and submit the final patches.
 The whole code has a switch to turn completely off the whole vim-thing.

 I really hope that this is our suckless-vim :)



10/10 would learn keybindings for this.
As an aside, arch abandoned the ancient vi in favor of vim at some
point. Maybe this one might end up to hop in there. :D

cheers!
mar77i

Re: [dev] [PATCH] Add tab-completion file-name expansion.

[Martti Kühne]

I feel honored and desecrated for suckless.
But somebody obviously spent google's paid time on this and had,
therefore, to note so in the license... xD

Re: [dev] Re: [PATCH] Add tab-completion file-name expansion.

[Martti Kühne]

On Mon, Jul 7, 2014 at 3:07 PM, Michal Nazarewicz min...@mina86.com wrote:
 Wow, you guys are insane.

 Sorry for trying to improve dmenu, I won't make that mistake again.



I hope for your sake that you're able to differenciate between the
different criticisms.
We may very well appear insane, if you don't care that if you're with suckless

* you're in it rather as an individual
* you settle for less code complexity at the expense of feature and sloc creep
* and no we don't have to agree with everything
* and again, we will judge you based on what you disclose about yourself
* we smell. This I was told when I came here. I still think it's a
great way to put it.

cheers!
mar77i

Re: [dev] Re: Article about suckless on root.cz

[Martti Kühne]

On Mon, Jul 7, 2014 at 2:54 PM, Martin Kopta mar...@kopta.eu wrote:

 Alright, I am going for another article in the row. Still no topic set.
 Considering st.

 If st, what not to forget to mention?

 Otherwise, what should I write about?

 BTW, I thought about translating them into English and posting on some server.
 Ideas?

I would welcome a translation to English, as I have little to no
knowledge about your language. Maybe we could open a Press section
on suckless.org?

cheers!
mar77i

Re: [dev] network protocol packing

[Martti Kühne]

On Tue, Jul 1, 2014 at 2:56 PM, Markus Teich markus.te...@stusta.mhn.de wrote:
 thanks for your feedback. What about declaring a struct for each message-type:

 struct msg_signed_data {
 unsigned int op;
 struct foo data;
 struct bar signature;
 };

 This should also solve the alignment issues, or am I mistaken here? It also
 reduces the amount of memcpy.


Is this skipping the padding or including it now? Including it would
mean there would be more to memcpy?
if you want to look at struct paddings, here we go... [0]

cheers!
mar77i

[0] https://gist.github.com/mar77i/b2cbe1a6c0c2194d7804

Re: [dev] Plain text editor that sucks less - an alternative to VIM?

[Martti Kühne]

On Sun, Jun 29, 2014 at 2:37 PM, Silvan Jegen s.je...@gmail.com wrote:

 I don't really see the point of editors that use a terminal-based,
 clickable UI. If you want that, you can just use a regular-GUI-based
 editor like gedit, kate etc.



I know how much suck comes with GUI editors, but I switched from gedit
to geany when I discovered how gedit chokes with its super-smart
live-hilighting search on larger files. This means, if you have a
large text file and use ^F, when you start typing 't', you'll have to
wait until that pohs (piece and then something with horse) colorizes
every instance on the letter 't' in the whole file. I since cannot
recommend gedit...

cheers!
mar77i