Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

[Markus Teich]

Am 2019-06-07 15:21, schrieb ilf:

Jochen Sprickerhof:
Up to dwm 6.1, the status bar text had a padding space on the very 
left edge. In 6.2, that's not there any more. Even if specifically 
adding one or more space glyphs to the text passed to "xsetroot 
-name", these are stipped.

Should be this on:
http://git.suckless.org/dwm/commit/a137a86a234476bc3c7128fecbf845e6fc1de995.html


Yes, that's it. But I don't unserstand why this was merged.


Very simple: It was out for review for over a month and nobody 
complained.


The status bar has multiple text areas: tags, layout symbol, window 
name, status.

In the first three, the text content is padded. This change removes
the padding only for the status area.


I had another look at the patch and as I understand it it only removes 
left padding
which should be a NOP as status text is overdrawn by window name anyway. 
How do you
notice the behavior change? Are you using a different background color 
for status text
and window name? Can you send screenshots of correct and wrong behavior 
and list all

patches and the config.h you are using?

I disagree with that design decision, IMHO it be padded, too. Was there 
a debate on
this and rough consensus? If so, I'd love an option, but that's not the 
suckless way,

so someone would need to maintain a patch.


As mentioned above, it was out for review for over a month and no 
discussion. This
was no intentional design decision by me. I just wanted to sync what the 
code does and
what the comment says. Meanwhile I thought this would simplify the code, 
but apparently

it didn't.

If you can provide more details about what exactly is failing and how to 
reproduce,
I may come up with a fix. You're welcome to propose a patch yourself 
though. ;)


--Markus

Re: [dev] securiy guidance

[Markus Teich]

Am 2018-03-11 01:48, schrieb Sergey Matveev:

*** Markus Teich [2018-03-10 17:09]:
I don't know crypto_argon2i. I'd use the standardized HKDF2 scheme to 
derive

the key.


HKDF algorithm is not aimed to be used with passwords. It is ok to be
used with Diffie-Hellman outputs for example. Password-derived keys are
required (ideally) to use CPU and memory hard one. Argon2, beeing the
PHC winner is a good choice (however I prefer Balloon for its 
simplicity
and (seems to be) higher security margin 
(https://crypto.stanford.edu/balloon/),

but it is not standardized).


Ah, thanks for the reminder! I always forget about this caveat of HKDF2 
with

passwords… -.-

I'm not sure why you would need a mac if you don't use a malleable 
encryption

scheme.


Encryption with authentication is *always* right. Modern encryption
techniques always use authenticated encryption schemes (deprecating
unauthenticated modes at all). MAC is not only about malleability and
integrity, but about authenticity. No data should be decrypted (or any
kind processed) before it is authenticated. It is always right.


You are correct that it doesn't hurt to add a MAC. I was thinking it 
wouldn't
make sense to authenticate to myself. Could you point me to an attack 
scenario

where not having a MAC in this scheme is bad?

--Markus

Re: [dev] securiy guidance

[Markus Teich]

Am 2018-03-11 04:21, schrieb Anselm Garbe:
On 10 March 2018 at 06:08, Markus Teich <markus.te...@stusta.mhn.de> 
wrote:

Should be fine, but the salt should not be secret (you need to sync it
between devices where you want to use this system after all). The 
point is
that you can give your encrypted database as it is stored on disk to 
anyone

and they would not be able to derive anything (you care about) from it
without the master password. Depending on what you care about, the 
whole

[..]

In the end the master password should be the only thing that needs to 
be

kept
secret and you can easily "sync" that between devices by remembering 
it. ;)


I tried to grasp the overall suggestion, but how is that different to
a single text stream of the format:

user@domain: password\n*

being encrypted using your own PGP public key into a single file? Each
time you want to know a username or password, you decrypt the file,
look it up and are done with it.

Are you concerned about portions becoming decrypted in memory on your
local host?


Using a single file encrypted with gpg would certainly work too. You 
just have
to be a bit more careful with the handling as you risk leaking the 
complete file
instead of just a single password. For example the file needs some 
structure
that you may want to enforce to some degree to make it usable for tools 
like
selecting and pasting your password into login forms. In my experiment I 
found
it easier to have one file per key (e.g. domain) and then use the first 
line
as the canonical password while additional lines could be used for those 
annoying

security questions some websites require or other related information.

--Markus

Re: [dev] securiy guidance

[Markus Teich]

(1)
Setup:
- Generate a random salt and store somewhere safe.


Note that it should not be required to keep the salt secret.


Encryption:
- Read the salt from its location and the master password from the
console. Use those to generate a key with crypto_argon2i.


I don't know crypto_argon2i. I'd use the standardized HKDF2 scheme to 
derive

the key.


- Read password from the console (or generate randomly) and encrypt it
with the key and a randomly generated nonce using crypto_lock.
- Write the mac, nonce, and encrypted password to a file.


I'm not sure why you would need a mac if you don't use a malleable 
encryption

scheme.

How do you address the (non-encryption) key part of the key-value store?
If you planned to use the filename as key (e.g. "amazon.com"), see my 
other

mail.


Decryption:
- Read the salt from its location and the master password from the
console. Use those to generate a key with crypto_argon2i.
- Read the mac, nonce, and encrypted password from the file.
- Decrypt the password using the mac, nonce, and key using 
crypto_unlock.


It's not clear to me if it's okay to use the plain crypto_argon2i with
just a fixed secret salt.


Should be fine, but the salt should not be secret (you need to sync it
between devices where you want to use this system after all). The point 
is
that you can give your encrypted database as it is stored on disk to 
anyone

and they would not be able to derive anything (you care about) from it
without the master password. Depending on what you care about, the whole
password storage thing get's more and more complex, but this is a nice
development process where you can add features one after another:

- Okay to publish which sites I use?
- Okay to publish how long my passwords are (roughly)?
- Okay to publish when I changed the password for a specific site 
regularly?

- Okay to publish when I changed my master password?
- Okay to publish when I changed anything?

In the end the master password should be the only thing that needs to be 
kept
secret and you can easily "sync" that between devices by remembering it. 
;)


Keeping the salt fixed is okay as long as you don't change the content 
it is

used for, in this case the master password.


A related scheme might be to use
crypto_argon2i_general with a salt generated for each encryption and a
single saved key. Then, the salts could be stored as plain text the
output file (and probably authenticated with crypto_lock_aead).
Perhaps one benefit is if someone somehow figured out the encryption
key for one password, they still wouldn't be able to decrypt the
others.

(2)
Setup:
- Generate a random salt.
- Read a master password from the console and generate a master key
from it and the salt using crypto_argon2i.
- Use crypto_key_exchange_public_key to compute the master public key
from the secret key.
- Save the salt and the master public key somewhere safe.

Encryption:
- Read the master public key from its location.
- Randomly generate a single-use key, and compute a shared key from it
and the master public key using crypto_key_exchange.
- Compute the single-use public key using 
crypto_key_exchange_public_key.

- Read password from the console (or generate randomly) and encrypt it
with this shared key, a randomly generated nonce, and the single-use
public key as additional data using crypto_lock_aead.
- Write the mac, nonce, single-use public key, and encrypted password 
to a file.


Decryption:
- Read the salt from its location.
- Read a master password from the console and compute the master key
from it and the salt using crypto_argon2i.
- Read the mac, nonce, single-use public key, and encrypted password
from the file.
- Compute the shared key from the single-use public key and the master 
key.

- Decrypt the password using the mac, nonce, single-use public key,
and shared key using crypto_unlock_aead.

For (2) I'm not sure if the nonce is necessary or not, since passwords
are encrypted with randomly generated single-use keys (so maybe a
fixed value is sufficient; it is still only used once per key).

The main differences are that (1) requires the master password for
every encryption, but not setup, and (2) requires the master password
only for setup. I think (2) is more similar to how gpg works.

Perhaps somebody who knows more about these crypto primitives could
point out any flaws with these schemes.


That one seems a bit complicated due to the creative (ab?)use of key 
exchange.
Using asymetric encryption is the right approach though if you aim for 
not
needing the password on encryption and I couldn't come up with a simpler 
system

quickly, so maybe it's not so bad after all. ;)

Re: [dev] securiy guidance

[Markus Teich]

Am 2018-03-08 18:47, schrieb pet...@riseup.net:

Looking at the chacha API one needs to use a nonce, in the monocypher
implementation it is 24 bits wide, which would give the option of 
almost

17M runs with a single key. IIUC adding a salt would further randomize
the output and possibly prevent some other forms of attacks but won't
replace the nonce as the salt cannot be secret either.


I don't know the chacha API. Please check the wikipedia pages for salt 
vs. nonce.
TLDR: They are similar, but for passwords the term salt is used while 
nonce is used
in network protocol context. An important difference is that the salt is 
always
okay to publish/store, while some nonces have to be kept secret. However 
the "only
use once" concept also applies to salts, so make sure you generate a new 
salt each

time you recompute the hash of a key/password.


What is a profiling attack? A quick search didn't bring up anything
relevant. I see many people are disturbed by the idea that the keys of
the password key-value store are visible on the filesystem. I will have
to think about that.


I don't know if there is a specific term for this. You want your system 
to be good
enough that you can publish the encrypted password database 
(Kerckhoffs's 2nd
principle). For my project I envisioned using git for db 
synchronization. So if
the keys ("google.com", "facebook.com", "nastypr0nsite.sexy", …) are not 
encrypted
equally well, everyone can see where you have accounts. That's what 
people are

concerned about.

In the meantime I am realizing that security is really, really hard. 
All

the sorts of attacks there are, memory swapping, wiping disk and memory
properly after finished... And I haven't even gotten to the agent part,
which needs to store the password in memory. Thinking about that part
I'm not even sure how can that be done safely. Well, at least I
understand better why are people relying on GPG to do that part. Lesson
learned :)


Well it is hard indeed, but it's also interesting to learn all that 
stuff.
If you don't push your first attempts at cryptography to thousands of 
users,
it is usually fine. After all, the best way to learn is to make 
mistakes. You
just have to accept that you will definitely be making mistakes and 
willing to

fix them. :)

Re: [dev] securiy guidance

[Markus Teich]

pet...@riseup.net wrote:

I have to yet read up if it is safe to use
with a single key, i.e. encrypting n passwords with the same secret 
key.


Make sure to use salting in this case. Otherwise using the same password 
for multiple sites/keys would be visible.


You also want to hide the keys themselves to protect your password 
storage from profiling attacks. For example encrypt a dictionary that 
maps the real key to some randomized filename where the encrypted 
password is stored). I've done something like this with horrible shell 
scripting and using gpg for encryption: https://github.com/schachmat/pkv


--Markus

Re: [dev] Writing subtitles for videos

[Markus Teich]

Thomas Levine wrote:
> I settled on the following mpv configuration.
> https://thomaslevine.com/scm/langrompiloj/artifact/6a086022d93af1a1
> https://thomaslevine.com/scm/langrompiloj/artifact/161b62d352fec4f7
> 
> This produces a file like the one below, which I edit until the subtitles are
> acceptably timed. Each line marks the beginning of the next cue and the end of
> the previous cue.
> https://thomaslevine.com/scm/langrompiloj/artifact/49ddb891f1f0b6fd
> 
> Texts for the subtitles are stored in other files, one file per language.
> These files have one line per cue, so they have one fewer line than the
> corresponding timings file.
> https://thomaslevine.com/scm/langrompiloj/artifact/f01066b80ae8fe3b
> https://thomaslevine.com/scm/langrompiloj/artifact/cf93e6b1b7967053
> 
> I then produce a WebVTT file for each combination of a timing file and
> language.

Heyho Thomas,

I did not look up the format, so it might be trivial, but do you mind sharing
your tooling for the WebVTT translation as well?

--Markus

Re: [dev] [ii]: path to apply action command

[Markus Teich]

Heyho,

Hiltjo Posthuma wrote:
> Minor nitpick, I'd prefer a space after the wildcard:
> > +   snprintf(msg, sizeof(msg), "* %s %s", nick, 
> > [3]);

I think that looks weird. No actual research, but I think I've seen the format
without a space more often and the `*` is not allowed in nick names, so no
source of confusion there either.

> > -   snprintf(msg, sizeof(msg), "<%s> %s", argv[TOK_NICKSRV],
> > -   argv[TOK_TEXT] ? argv[TOK_TEXT] : "");
> > +   if (sscanf(argv[TOK_TEXT], "\01ACTION%[^\01]\01", text) == 1)
> > +   snprintf(msg, sizeof(msg), "*%s %s", argv[TOK_NICKSRV],
> > +*text ? [1] : "");
> 
> You should use a regular check here (strncmp?) without the extra text buffer.

if (strncmp(argv[TOK_TEXT], "\01ACTION", strlen("\01ACTION")) == 0 && 
argv[TOK_TEXT][strlen(argv[TOK_TEXT])-1] == '\01')

is not much better imho…

> With the changes I think its reasonable to include this in the upstream
> version.  Any thoughts or is it bloat?

According to my limited IRC usage the /me actions are used frequently and thus
this is worhtwhile to add upstream. In the end it's up to you as the maintainer.
If you don't want to put it upstream, I'd like to see it at least replace the
current action patch in the patches/ section.

--Markus

[dev] [sent] release version 1

[Markus Teich]

Heyho,

I am happy to announce the version 1 release of sent. It was already released a
few days ago, I just forgot the announcement. Sorry, all you hungry package
maintainers. The release numbering has been changed to only single numbers, so
the next releases will be 2, 3, and so on.

Notable changes since the last version 0.2 include:

- Use farbfeld for images. No libpng support anymore (but farbfeld can handle
  png as well as many more formats, so not a regression).
- Bind key r to refresh the slide set from file. Useful when drafting/writing
  slides.
- Support for transparent images.
- Many bug fixes and simplifications.
- More key mappings by default.

https://tools.suckless.org/sent
https://git.suckless.org/sent
https://dl.suckless.org/tools/sent-1.tar.gz

The git commit and tag are signed with my PGP key and if you don't trust that as
it has another mail adress, just read the source, it's not that long. You should
do that anyway and not trust that code is good, just because someone put a
signature on it.

--Markus

Re: [dev] Congrats on HTTPS, and other thoughts

[Markus Teich]

Hiltjo Posthuma wrote:
> Some directories indeed did not have a checksums file (it didn't have these
> before either).

The script generating the .tar.gz archives and checksums does not yet copy them
to the dl.suckless.org hierarchy. We might want to remove the subdirectories
(like tools/) level on dl.suckless.org to make that easier. I mentioned it on
IRC yesterday as well.

--Markus

Re: [dev] dl.suckless.org file integrity github project

[Markus Teich]

Mattias Andrée wrote:
> * An alternative to signature files is to sign the tags in Git, and those
>   that care enough could pull releases from git instead.

That is a nice idea. It doesn't require any extra signature/checksum file cruft
on the webserver. It can easily be made optional and is in the maintainers
hands if he wants to provide the signatures or not (with his own key).

--Markus

Re: [dev] dl.suckless.org file integrity github project

[Markus Teich]

Mattias Andrée wrote:
> If the server's authenticity can be proven with HTTPS,
> what additional secure does PGP-signatures provide?

Some people trust persons they know more than they trust random corporations
with questionable security policies. Other people think PGP sucks. I don't know
which group has the majority in the suckless community, thus I asked for a
gentle vote by flamewar.

I count myself to the PGP proponents, but have to admit, that I might be too
lazy to check the PGP signatures myself.

--Markus

Re: [dev] dl.suckless.org file integrity github project

[Markus Teich]

Hiltjo Posthuma wrote:
> Checksums are available in each project directory, yesterday I've added
> SHA256 checksums.
> 
> For example:
>   SHA256: http://dl.suckless.org/dwm/sha256sums.txt
>   SHA1:   http://dl.suckless.org/dwm/sha1sums.txt
>   MD5:http://dl.suckless.org/dwm/md5sums.txt
> 
> HTTPs will be coming in a few weeks when some things are sorted. Maybe in the
> future we can add also add PGP signed releases.

Heyho,

I don't see the benefit of checksums without signatures. We already kind of have
transmission integrity by IP for release downloads or by git. We really need
https, but PGP is probably controversial enough to be discussed. Maybe we have
some time for that at the hackathon, but that would exclude people who cannot
attend.

Thus, start flaming your highly valued opinions about PGP-signing releases to
the list nao! ;P

--Markus

Re: [dev][all] Hello

[Markus Teich]

Lennart Poeterring wrote:
> …

Greetings Lennart,

you seem to have misspelled your last name. Also, stop talking, send patches!

I wish you have the loveliest of days!
--Markus

Re: [dev] [slock] 1.4 no longer working on freebsd with ldap/kerberos

[Markus Teich]

Andrew Cobaugh wrote:
> Trying one more time to bisect this, I ended up at
> 04143fd68dbc656905714eff5c208fadb3464e25 as the commit that introduced
> the "slock: getpwuid: cannot retrieve shadow entry (make sure to suid
> or sgid slock)" error for my environment. This was with replacing
> HAVE_SHADOW with HAVE_PAM.

Heyho Andrew,

This cannot work as vanilla slock does not have PAM support.

> I tried the pam_auth patches and none of them applied cleanly against 1.4.

The patch format was weird. I fixed it, please try again.

--Markus

Re: [dev] [slock] 1.4 no longer working on freebsd with ldap/kerberos

[Markus Teich]

Andrew Cobaugh wrote:
> I'm actually having a hard time bisecting, because even vanilla 1.3 fails to
> work correctly. The screen locks, but then it doesn't accept my password.
> 
> There is this patch in the ports tree which is necessary to make 1.3 work for
> me, but it doesn't seem to apply cleanly much after 1.3.  Perhaps that's a
> clue?
> 
> https://svnweb.freebsd.org/ports/head/x11/slock/files/patch-slock.c?view=markup=434733

Heyho Andrew,

If the PAM patch is not part of your distributions 1.4 release and your
authentication system needs PAM (which I assume), you can try the latest PAM
patch from the wiki: http://tools.suckless.org/slock/patches/pam_auth .

If this solves your problem, you can follow up with your maintainer and ask him
to integrate this patch to the ports tree as it was done for 1.3.

--Markus

Re: [dev] [slock] 1.4 no longer working on freebsd with ldap/kerberos

[Markus Teich]

Heyho Andrew,

Andrew Cobaugh wrote:
> I believe this is related to this change:
> 
>
> http://git.suckless.org/slock/commit/?id=04143fd68dbc656905714eff5c208fadb3464e25

Can you confirm this commit is the cause of the regression by using git bisect?

> In my case, my passwd field contains '*' because my user exists in ldap,
> and my password is coming through Kerberos.
> 
> This was all working on 1.3. Please advise.

Are `__OpenBSD__`, `HAVE_SHADOW_H`, `HAVE_BSD_AUTH` set on your system?

--Markus

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

doug livesey wrote:
> Could you advise me on how to apply the patch to the st project?  (Does it
> maybe need to be done in a broader context of a suckless project?) Oh, and I
> couldn't find any mention of resizehints in the code to set to false, so I
> think I've misunderstood there, too.

Heyho,

As you should have noticed from the URL the patch is for dwm. The resizehints
config is also for dwm.

We also have documentation about how to patch[0], so please do your research
next time.

--Markus


0: http://suckless.org/hacking

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

Greg Reagle wrote:
> If it were possible to get st to do the same thing, such a feature would
> probably not be included in the main repository due to the preference for
> small fast and simple that characterizes suckless programs.

Heyho,

I agree. The main point here is imho that dwm already has a fullscreen "mode"
(like I described in my other mails), so why should we add it to our X clients
as well? It would be redundant.

--Markus

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

doug livesey wrote:
> I shall have a play with that after work, thankyou!

Heyho,

I just noticed I did not update the patch on the website yet. I did this now, so
make sure to use the latest one[0], which is also simpler than the previous ones
and probably does not produce as many merge conflicts if you have other patches
in use.

Also note that you have to set resizehints to false, because st will try to fix
its size to an exact multiple of one character which probably leaves some gaps
around the window.

--Markus

0: http://dwm.suckless.org/patches/dwm-noborder-20170207-bb3bd6f.diff

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

Heyho doug,

doug livesey wrote:
> I'd have to figure out how to code that patch, first! :)

Nope, just use that[0] patch.

> However, everything I've tried so far hasn't enabled me to run st in
> full-screen mode, so it's looking like the window manager doesn't enable full
> screen without the app enabling it.

After applying the patch just switch to monocle mode and toggle the bar. I use
it all the time, also for videos. I don't like application level fullscreen
modes.

Use the force, read the source!
--Markus


0: http://dwm.suckless.org/patches/noborder

Re: [dev] Internet privacy/decentralisation projects

[Markus Teich]

hiro wrote:
> try with a small group of people first that actually has a need for privacy.

Heyho,

in the special case where this privacy is to be achieved not with encryption,
authentication and authorization (to limit the number of entities who are
allowed to learn the secret which should be protected), but with an
anonymity/pseudonymity system (where actions are not attributable to the actors
identity), be aware that it is not a good idea to use this system only if you
need it. It would be too easy for third parties to filter all the users of the
system out and assume everyone of them has something to hide. An anonymity
system needs users who don't actually have a reason to use it. This is why the
NSA or other investigation agencies don't have their own anonymity system to spy
on their targets (they could be blocked relatively easily), but also use the
more widespread systems like Tor. If you want to know more, research "cover
traffic" and "anonymity set size".

--Markus

Re: [dev] [st/dwm] Alt-Shift-C and Mod1-Shift-C

[Markus Teich]

Patrick Bucher wrote:
> On Fri, Jan 13, 2017 at 11:23:28PM +0800, Ivan Tham wrote:
> > Windows key is a better choice most of the time since it's unused
> > 
> As you and many others suggested, I am now using the Windows key as well. It's
> a bit strange at the beginning, for my thumb has to move a bit more to the
> left,

Heyho,

setxkbmap BLA -option altwin:swap_lalt_lwin

--Markus

Re: [dev] [announce] wjt-0.1 - slider widget

[Markus Teich]

Ian Remmler wrote:
> There's not much to see, really. I don't think a picture tells enough to
> justify adding to the repo. I'll likely flesh out the readme a bit. But it's
> easy to build and run to see what it does.

Heyho Ian,

I also think an image would be helpful but should not be added to the master
branch where your code is. You have two sane options: Add the image to your own
webspace instead of committing it to the repository. Or create a new orphan
branch `gh-pages`, where you can commit the image without cluttering up the
master branch.

--Markus

Re: [dev] [slock] 1.4 not working in fedora

[Markus Teich]

Ricardo M. Vilchis wrote:
> slock: getgrnam nogroup: group entry not found

Heyho Ricardo,

then you (or even the fedora package maintainer of slock) should change the
value in config.h accordingly.

--Markus

Re: [dev] Fwd: [slock] 1.4 not working from i3

[Markus Teich]

Martin Kühne wrote:
> This reminds me, we're talking about i3 here.

Heyho,

if you're using unclutter, this thread[0] could also help you out. Either way it
seems that something else on your system already has an active keyboard/mouse
grab preventing slock from starting.

--Markus


0: http://lists.suckless.org/dev/1601/28100.html

[dev] [ANNOUNCE] slock-1.4

[Markus Teich]

Heyho,

I am happy to announce the release of slock version 1.4. slock is a simple X
display locker.

You can download it at: http://dl.suckless.org/tools/slock-1.4.tar.gz

The changes since version 1.3 are:
- fix CVE-2016-6866
- add proper priviledge dropping
- use explicit_bzero from OpenBSD to clear password from memory
- major code audit and rewrite of some parts (thanks, Laslo!)

--Markus

Re: [dev] Collecting sins of Apple

[Markus Teich]

Martin Kühne wrote:
> TL;DR, while I'm sure most of this stuff holds further scrutiny, I just doubt
> it's generally a good idea to list so many problems while providing no
> technical context whatsoever.

Heyho Martin,

I didn't want to do the whole schoolwork for Lukáš, so I just gave a
hint/possible fact which he should be able to check himself. It's important to
learn how to research arguments to build your own oppinion. Providing Lukáš with
ready-to-use text blocks would just increase the filter-bubble problem. I think
other responses had similar intentions.

--Markus

Re: [dev] Collecting sins of Apple

[Markus Teich]

lukáš Hozda wrote:
> Do you know about some bad things Apple has done in their pursuit of
> ever-increasing profits? Do you know about ways Apple is against free and
> open-source software? Please let me know. Naturally, if you know about some
> good deeds of Apple, I accept them as well.

Heyho Lukáš,

a point not mentioned yet is their cruel manufacturing conditions for the
workers in asia. This point is certainly not unique to Apple(c)(r)(tm), but it's
one of the best known offenders with this problem.

--Markus

Re: [dev] [surf] badssl.com

[Markus Teich]

Alexander Keller wrote:
> If the alternative is too much, perhaps changing
> strictssl = FALSE \* Refuse untrusted SSL connections *\
> to
> strictssl = FALSE \* Validate SSL certificates from server *\
> would help better inform what it does. My initial understanding when I
> used surf was that this would simply deny me the option of bypassing SSL
> errors. Not silently ignore them.

Heyho Alexander,

surf is not _silently_ ignoring them. If the validation fails, `sslfailed` will
be true and in the window title you can see a `…:U` for untrusted instead of
`…:T` for trusted. I don't think the change is good, since surf does the
validation always.

--Markus

Re: [dev] [discussion] editors

[Markus Teich]

pranomes...@gmail.com wrote:
> I can't be bothered with writing an own vi/vis/vim layout for the keyboard
> layout I use (neo2).

Heyho,

I also use the neo2 keyboard layout with vim for a few years now. I don't
understand why you would have to change the keybindings at all, since the
mapping of letters to functions is quite self-explanatory. If you fear you would
screw up any existing muscle memory of qwerty-mappings, let me encourage you to
try the switch, it doesn't take long to adapt. Another benefit of using vim with
neo2 is that you free up the hjkl keys since neo2 has them included on layer 4.

--Markus

Re: [dev] I'm leaving.

[Markus Teich]

Christoph Lohmann wrote:
> I  am  stepping  back  from my maintainership and my role as an admin of
> suckless.

Heyho Christoph,

keep those global warming causers in check with whatever you are focusing on
now! ;)

On a more serious note:

Thanks for your work, especially on st (which showed me that I mostly don't need
scrollback at all and can use `less` otherwise) and surf (which I never imagined
me to be using when discovering suckless, but soon I learned to love the
interface more than firefox, chrome or the bugged heap of js crap that was
called vimperator/pentadactyl).

All the best!

--Markus

Re: [dev] name for ii-like chatting

[Markus Teich]

Martin Kühne wrote:
> On Tue, Sep 27, 2016 at 2:40 PM, FRIGN  wrote:
> > however, "bioc" or "binoc" might be nice memorable names for the
> 
> Why not carry the IRC back into the name and make it binoirc or even birco?

Heyho,

This is intended to be used with other chat protocols as well, so I would not
force the "irc" into the name. "binoc" seeems nice, I like the "C" at the end.
;)

--Markus

[dev] [sent] [PATCH] infinite mode

[Markus Teich]

---


Jo dawg, I heard you like presentations so I put a presentation after your
presentation so you can have infinite presentations.


 sent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sent.c b/sent.c
index fc319be..8580d0a 100644
--- a/sent.c
+++ b/sent.c
@@ -437,7 +437,7 @@ load(FILE *fp)
 void
 advance(const Arg *arg)
 {
-   int new_idx = idx + arg->i;
+   int new_idx = (idx + slidecount + arg->i) % slidecount;
LIMIT(new_idx, 0, slidecount-1);
if (new_idx != idx) {
if (slides[idx].img)
-- 
2.7.3

Re: [dev] [slcon3] preliminary schedule and registration deadline

[Markus Teich]

Anselm R Garbe wrote:
> I'm glad to announce the preliminary slcon3 schedule[0].

Heyho,

I'll arrive on friday around noon. If someone else wants to join early, we can
meet at the hotel lobby and work on some projects until the official welcome in
the evening.

--Markus

Re: [dev] Sane office alternative?

[Markus Teich]

Kevin Michael Frick wrote:
> people keep sending me word documents :/

Heyho,

respond with a plain text document without file name extension and laugh
at their silly faces when they don't know how to open it.

--Markus

Re: [dev] [st] most suckless way to scroll & multiplex

[Markus Teich]

Joseph Graham wrote:
> I am accustomed to having scrolling and multiplexing (in > xfce4-terminal).
> To get these the suckless way should I:
> a. use tmux/screen
> b. use tabbed and the st scrollback patch
> c. something else

Heyho Joseph,

for local multiplexing I use tabbed, since its keybindings are way easier to use
(mod+BLA instead of mod+prefixkey, then BLA). For remote multiplexing I use tmux
since it is mostly available on those systems and tmux is easier than opening up
another ssh connection even with "ControlMaster auto". Scrollback I don't use as
normal user, I just learned to use less for things which do not fit on one
screen page. For root however I use tmux for it's scrollback (and multiplexing,
no need to become root multiple times) feature, since there might be some
unexpectedly long output on e.g. package updates, which I would want to scroll
back to and I'm too lazy to always use less as root to be prepared for all
corner-cases.

--Markus

Re: [dev] Allow secure access to Web site suckless.org

[Markus Teich]

FRIGN wrote:
> Even if you use self-signed certificates on your server, which provide 0
> guarantee that the server you are contacting really is the "right" one, it
> still means the traffic itself is encrypted, with all benefits of it.

Heyho,

In our case it would do nothing. There is no "secret" data available through the
suckless site, since there is no login mechanism, everything is publicly
available. Therefore encryption does not help at all. I don't see any other
possible benefits of encryption besides confidency.

What we want to achieve is authentication. We want to be sure the data received
is actually from suckless.org and not from some random governments MitM. A
self-signed certificate connection can still easily be attacked by a MitM if you
don't establish trust to the used certificate and maintain it (pinning) which is
hard without a CA or WoT.

--Markus

Re: [dev] Allow secure access to Web site suckless.org

[Markus Teich]

Paul Menzel wrote:
> I noticed, that it’s currently not possible to securely browse the Web site
> [1].
> 
> Are there plans to allow access using HTTP over SSL?

Heyho,

I'd also like that. My main argument is that it helps against MitM attacks when
our precious software is downloaded. However I'm not sure if swerc supports it.

--Markus

Re: [dev] [st] Division by zero

[Markus Teich]

Paul Menzel wrote:
> If I am not mistaken, this is really a corner case. The user has to set 
> `actionfps` to zero in `config.def.h`.
> 
> ```
> config.def.h:static unsigned int actionfps = 30;
> ```

Heyho Paul,

maybe you can make your compiler happy by making the variable const? It should
then be able to see that the value can not be zero if you don't assign zero to
it in the first place.

--Markus

Re: [dev] [dwm] Unnecessary scoping blocks

[Markus Teich]

Eric Pruitt wrote:
> @@ -944,40 +944,36 @@ void
>  grabbuttons(Client *c, int focused)
>  {
>   updatenumlockmask();
> - {
> - unsigned int i, j;
> - unsigned int modifiers[] = { 0, LockMask, numlockmask, 
> numlockmask|LockMask };
> …
> + unsigned int i, j;
> + unsigned int modifiers[] = { 0, LockMask, numlockmask, 
> numlockmask|LockMask };

Heyho Eric,

you should shift the declarations above the updatenumlockmask() call acording to
"Do not mix declarations and code" from http://suckless.org/coding_style. The
same for the second removed pair of braces.

--Markus

Re: [dev] [slock] [PATCH] Ctrl-u now resets the input

[Markus Teich]

Anselm R Garbe wrote:
> I'm not sure if this feature is really required. Typing a wrong password can
> be corrected on second attempt anyways.
> 
> What is the opinion of other users to this change?

Heyho,

I also don't think adding this patch to mainline is neccessary. You can still
put it on the patches section[0] in the wiki, Troy.

--Markus


0: http://suckless.org/wiki

Re: [dev] [sup] Bring the simple user privilege escalation tool back home?

[Markus Teich]

Marc Collin wrote:
> Original sup by pancake is copyleft. (loose term, could be many things)
> Jaromil's sup (which is based on pancake's) is LGPLv3.

Heyho,

ISC or MIT should be compatible with LGPL, so I think it's fine to pull the
fixes if we relicense sup under one of those.

--Markus

Re: [dev] [slock] PAM support

[Markus Teich]

Eric Pruitt wrote:
> I think you should add another color option to the configuration.

Heyho,

if you add that to the patch be sure to also run `sed -i s/slock/nyanlock/` on
all files before submitting the new version.

--Markus

Re: [dev] Re: [slock] red color on control keys?

[Markus Teich]

David Phillips wrote:
> This /may/ not achieve quite the behaviour that Frostyfrog is after. By
> example, I would appreciate if slock was able to only show failcolor when the
> buffer is empty and a key which actually modifies the buffer was pressed.

Heyho David,

we already discussed this. There are two settings, one for the "normal" people
and one for the paranoid ones. The setting you propose is mostly the same as the
paranoid one, but slightly less paranoid. Why should paranoid people settle for
something less paranoid? You are very welcome to push a patch to the wiki
changing the paranoid setting to ignore modifier and function keys.

On the other hand we can of course discuss changing the default of the
`failonclear` setting to `0`. However I already pushed a little explanation to
the slock home page (not yet online) which might help people to first read the
config file before asking here on the ML.

Since slock is a security oriented program I would stick to the `1` default
paranoid setting.

--Markus

Re: [dev] Re: [slock] red color on control keys?

[Markus Teich]

Frostyfrog wrote:
> So, I understand that the red background color is supposed to signify that
> someone tried to log into the machine, but does it really need to turn the
> screen red when I press a no-op key?

Heyho,

Just set failonclear to false in config.h.

--Markus

Re: [dev] using tabbed with dwm and st

[Markus Teich]

Heyho,

Rashad Kanavath wrote:
> How do i configure dwm to have tabbed + st for default terminal window?
> 
> currently when I do Ctrl+Shift+Enter I have an st terminal. I want to
> have it inside a tabbed.

I use this:
static const char *termcmd[] = {"tabbed", "-c", "-r", "2", "st", "-w", "''", 
NULL};

> First time, i willl have a new tabbed with a single st. The next
> 'Ctrl+Shift+Enter' will give another st inside the same tabbed.

You need to use the tabbed keybinding for opening a new tab then, not the dwm
one. Read the man page

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
> Anyway, it would be more useful to concentrate on the password checking part,
> it segfaults commonly (which is fucking ridiculous!!) because ldap, linux,
> etc. suck.

Heyho hiro,

Same argument as for surf applies here: If you can't fix the suckyness, you have
to build a nice interface for it. If you would not abuse this segfault, I'd
recommend you debug it and send in a patch to fix it, but I have access to a
sucky LDAP setup as well, so I might be able to reproduce it myself…

> I suggest this very platform-independent alternative interface (you can remove
> special-casing for linux,bsd and such bullshit):
> 
> 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.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
> How does your integrated execution of s2ram change that?  Your slock can still
> fail in just the same way.

Heyho hiro,

with the patch first the cover window is created and the keyboard and mouse are
grabbed. I consider this setup. If it fails, slock exits and does *not* execute
s2ram. If it succeeded, s2ram is executed and the loop handling user input is
entered. Of course there could be a crash inside that loop, but we cannot know
that in advance and we also cannot fork-exec s2ram at any later stage.

The most common case for slock failing was that the grabbing of input devices
failed when some other application still had a grab active. This failure is
fixed by the patch.

--Markus

[dev] [ANNOUNCE] slock-1.3

[Markus Teich]

Heyho,

I am happy to announce the release of slock version 1.3. slock is a simple X
display locker.

You can download it at: http://dl.suckless.org/tools/slock-1.3.tar.gz

The changes since version 1.2 are:
- bugfix: The cover window now resizes correctly when new screens are added or
  the resolution is changed while the lock is active.
- new: slock now has a third color. The three colors are used for startup,
  typing and failed login attempt.
- new: slock now allows to run any command after the screen has been locked, for
  example suspending to ram.
- slock now has a man page.
- a few small fixes and code style updates to make it more consistent with the
  rest of the suckless projects.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
>  - new: slock now allows to run any command after the screen has been
> locked, for
>example suspending to ram.
> 
> how come you can't just run slock from a shell script instead?

Heyho hiro,

you don't know when the screen is locked, since slock does not fork itself. If
you want to run `echo` after the screen is unlocked, you can just do `slock;
echo`, and if you want to run it before the screen gets locked the other way
around. But there was no possibility to run something after the screen got
locked and while it is still locked. The s2ram example from the man page is a
good one:

If you run it beforehand, then the screen is at least visible for a moment after
resuming from sleep and in the worst case slock fails to start correctly and you
don't know that in advance. Running s2ram afterwards is obviously a stupid idea
as well and using a backgrounded `sleep 5; s2ram` before starting slock also is
kind of stupid if slock fails to start up correctly.

If you have a better solution, let me know, I would be happy to reduce code
complexity again by reverting that commit.

--Markus

Re: [dev] tag new slock release?

[Markus Teich]

Anselm R Garbe wrote:
> Fine by me, don't forget to update config.mk and LICENSE as well with 1.3
> version info and copyright update.

Heyho,

I think its ready to ship, even added a man page. Is anything missing? If not,
feel free to tag and create the release tar.gz. I already pushed the updated
link to the sites repo and will write the announcement with a changelog when the
tar.gz is up.

--Markus

[dev] tag new slock release?

[Markus Teich]

Heyho,

I propose to tag a new v1.3 release for slock. I have no open patches or bug
reports on my list and my attention was brought to it a few times already. A
major thing noted by most people was the fix for resizing the cover window on
xrandr resize events (f5ef1b8), which can be considered a security issue. A new
release would make packaging easier for the distributions.

--Markus

Re: [dev] [surf] Switching to webkit2 as default

[Markus Teich]

Louis Santillan wrote:
>  One of the things I don't like about the Chrome (and specifically v8)
>  codebase is how google-centric the build process is.  By that I mean the
>  build basically assumes you're a googler with dozens of cores and TBs of
>  RAM and infrastructure to throw at the build process.  And if you're trying
>  to build on your laptop, fine, it'll work, but it'll take an hour or two.
>  Heck [3] says bring 6GB RAM & 40GB of disk to build a browser. :P
> 
>  [0] https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial
>  [1] https://bitbucket.org/chromiumembedded/cef
>  [2]
>  http://blog.nalates.net/2015/10/10/tutorial-chromium-embedded-framework-cef/
>  [3]
>  
> https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart#markdown-header-linux-setup

Heyho Louis,

yeah the web sucks and to conform to all those (non-)standards browser engines
are growing bigger and bigger. Webkit also takes quite a while to build on
laptops. The suckless browsers goal is to provide a suckless interface to a
sucking necessity. You don't have to build CEF yourself, you can just use the
binaries provided by google if you trust them.

That being said, I experimented with CEF a year ago[0], but I did not have the
time to continue the project. There is also a huge PR from autumn updating to
the then latest CEF version, but I did not have the time to check that either.
If someone wants to pick up the code, you're very welcome, I think a suckless
interface to CEF would be a great thing that could distinguish the suckless
browser from all the other simple browsers which are mostly based on webkit1.

The point I struggled most with CEF is the low level graphical stuff. I did not
know, if I want to use GTK or just plain X and had some trouble achieving
keybindings passed correctly between the interface and the web page.

--Markus


0: https://github.com/schachmat/smurf

Re: [dev] [vis] text_line_end() in insert mode

[Markus Teich]

Marc André Tanner wrote:
> The END-mapping was actually using text_line_lastchar not text_line_end.  I
> now added a new key action for text_line_end. The behaviour might still be
> inconsistent (for example in vim's visual modes `$` seems to behave like
> ) but at least it can now be configured via config.def.h.

Heyho Marc,

vim seems to be inconsistent here. It does not allow to move the cursor over
line break characters in normal mode (with empty lines as an exception), but
allows to do so in insert mode. However this inconsistency is ok, since it
prevents for example the following "mistake":

If you yank a word (without line breaks) and want to insert it at the end of a
line, the easiest way is to type `$p` in normal mode. If vim would allow you to
move the cursor above the line break, the word would be inserted *after* the
linebreak = at the beginning of the next line.

I don't know, if you think that inconsistency is worth keeping.

I also noticed some weird behaviours on files with \r\n line endings. Try
`$ll$$` for example.

--Markus

Re: [dev] [slock] chown to root:root on install?

[Markus Teich]

Nick wrote:
> I had forgotten about this until today, but the above fix still hasn't been
> applied to the Makefile, and I think it should be.

Heyho Nick,

sorry for the delay. I decided to add the hint to the error message on failing
to disable the OOM killer instead of the Makefile. Should be up now.

--Markus

Re: [dev] [PATCH] [slock] React to key release rather than key press events

[Markus Teich]

Brad Luther wrote:
> Say somebody manages to "clamp" any letter or number key without you noticing,
> and you for the better of it cannot type in your password (not because it's
> all-caps, but because it's spamming lots of chars).
> 
> So we want the screen to turn red on key down? Any key? Why just shift?

Heyho Brad,

In this case the screen actually turns blue and you will notice that as well.
Just press Esc to clear the buffer and if it turns blue right away, you know
some key is jammed.

--Markus

Re: [dev] [PATCH] [slock] React to key release rather than key press events

[Markus Teich]

FRIGN wrote:
> So we want the screen to turn red on key down.

Heyho,

another even more annoying example is: I actually type my password so fast, the
key release events are sometimes in the wrong order. You can test it with xev,
just type some text as fast as you can and you will find something like a-press,
b-press, b-release, a-release, especially if the two keys are on the middle row
and on different hands.

--Markus

Re: [dev] [PATCH] [slock] React to key release rather than key press events

[Markus Teich]

David Phillips wrote:
> Previously, if failonclear was set to True and a modifier key (especially
> shift) was pressed and held in order to modify the next keypress, slock would
> detect that a keypress had been made, observe that the buffer was clear and
> set the screen to the failure colour.
> 
> That behaviour is unwanted if the first key in a password is 'shift'.  The new
> behaviour will still turn slock to the failure colour if the shift key is
> pressed, but only once it is released and the buffer is still clear.

Heyho David,

I don't think we should change the current behaviour. As already explained there
are two different ways of operation:

- The paranoid option / failonclear = true:
  Here you will leave your screen green and will notice ANY fiddling with the
  keyboard. Let's say someone assumes he has to press shift 20 times to crash
  the screenlocker. This will get noticed in the current code state as it will
  turn the screen red.

- The not so paranoid option / failonclear = false:
  Here the screen will only turn red after a failed unlock attempt. Therefore
  you would not notice a coworker playing some drum line on the shift key or
  even on any other key if he resets the buffer before you come back.

You propose to make the first option less paranoid, but I cannot see a reason
for that. I also don't think introducing another mode of operation is a good
idea. We have basically covered both ends of the paranoia range and a third
option would just compicate the code.

--Markus

Re: [dev] [bug] slock gets red before submitting pass

[Markus Teich]

Brad Luther wrote:
> But if the behavior for Markus is different, then his slock is bugged :)

Heyho Brad,

nope, I just have the failonclear set to false in config.h. Then the empty input
state only turns red after a failed attempt. Otherwise it always is red except
right after starting slock. And as FRIGN explained, the non-empty input state
always is blue.

--Markus

Re: [dev] [bug] slock gets red before submitting pass

[Markus Teich]

Brad Luther wrote:
> If you're typing your password and gets a char wrong, you go and delete the
> char, then continue to type the pass and 'enter' to unlock the screen. All
> good, screen is blue all the time.  Unless... you get the first char wrong. If
> you mistype the first char of your password and 'backspace' to delete it, the
> screen goes red even though you didn't 'enter' the wrong password.

Heyho Brad,

I cannot reproduce the described behaviour. Are you using git HEAD? Can you
try to debug it yourself?

--Markus

[dev] [vis] text_line_end() in insert mode

[Markus Teich]

Heyho Marc,

something I don't seem to be able to figure out: When pressing the END key in
insert mode, in vim the cursor moves after the last regular character in the
current line, basically over the newline character, if you choose to display it.
In vis however it does only move to the last regular character, like in normal
mode. The text_line_end function called by the END-mapping seems to do the right
thing. I'm lost, where the differentiation between normal mode (the cursor
cannot move beyond the last regular character) and insert mode has to be done in
this case.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Marc,

Marc André Tanner wrote:
> > I don't know the best way to fix it, but it would
> > be possible to strip the newline from within the `cmd_set` function.
> 
> I have taken this route for now. Should be fixed?

Yep, works.

> > Ah right, I see it's used for `~` now. Could you add this mapping to the
> > bindings_visual and bindings_visual_line in config.def.h?
> 
> There were some other (slightly ugly) changes necessary, but it should now
> work as you want?

In visual line mode it still behaves a little strange. Shifting right seems to
work fine, but when shifting left, the selection is lost. In the character
visual mode it works for both directions.

> > > > I also was surprised, `\` works as it should. I propose to change
> > > > CURSOR_SEARCH_WORD_… to use `\` as regex instead of just `WORD` 
> > > > to
> > > > achieve the same functionality as in vim.
> > > 
> > > Yes I agree.
> > 
> > This patch for vis-motions.c works for me:
> 
> Thanks, some care must be taken with the integration into the search
> history though. I will take another look once I have more time ... 


> The till/to changes are also committed.

Thanks. However there were still some corner cases with wrong behaviour, see my
other mail on hackers@ for the patch.

--Markus

Re: [dev] [PATCH] Change an eprintf to a die to stop child from running its own slideshow

[Markus Teich]

David Phillips wrote:
> On Thu, Jan 14, 2016 at 09:47:37AM +, Dimitris Papastamos wrote:
> > On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> > > diff --git a/sent.c b/sent.c
> > > index fc5e389..88abe90 100644
> > > --- a/sent.c
> > > +++ b/sent.c
> > > @@ -153,7 +153,7 @@ filter(int fd, const char *cmd)
> > >   close(fds[0]);
> > >   close(fds[1]);
> > >   execlp(cmd, cmd, (char *)0);
> > > - eprintf("execlp %s:", cmd);
> > > + die("execlp %s:", cmd);
> > >   }
> > >   close(fds[1]);
> > >   return fds[0];
> > > -- 
> > > 2.6.2
> > > 
> > 
> > I should mention there are many more places in the code where this
> > issue happens.
> 
> You are probably right, but this one was the most annoying one to try and
> understand the cause of up until the penny finally dropped.

Heyho,

oops, I already had that merged localy, but forgot to push. Should be upstream
now.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Jan,

Jan Christoph Ebersbach wrote:
> - Setting defaults requires patching some c file instead of config.def.h

have you tried the visrc.lua file in the repository root? You can do any `set`
command in there for your defaults. See my other mails in this thread.

> - It took me ages to start vis with the proper VIS_PATH and VIS_THEME
>   settings.  My installation directory for vis is ~/.local which is not
>   part of the default locations.  Furthermore, the manpage still refers
>   to ~/.vis as the location where to put my personal configuration but
>   it is actually ~/.config/vis.  I had to create a little shell script
>   that sets VIS_PATH and VIS_THEME before starting vis.  In my opinion
>   these obstacles make it very hard to start playing around with it.

I have vis checked out in ~/code/vis and just set an
`alias v="VIS_PATH=~/code/vis ~/code/vis/vis"` for my shell. Works fine so far.

--Markus

Re: [dev] [slock] won't lock if unclutter grabbed mouse pointer

[Markus Teich]

Andreas Doll wrote:
> On 2016-01-15 at 23:21, Markus Teich wrote:
> > I don't like the man-page approach. Documentation always looses
> > synchronization to the codebase, so my proposal would be to output a similar
> > error message in slock. The link from "slock: could not grab pointer" to
> > `unclutter -grab` should be easy enough to discover then.
> 
> I also think this would be sufficient.

Heyho Andreas,

I just pushed a patch introducing the error messages. slock still tries for a
second to get the grab with the cover window already visible, but when failing
you can see the error message in your terminal.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Marc André Tanner wrote:
> > Maybe a global default 'syntax highlighter' applied regardless of file type
> > could do the job?
> 
> Maybe, yes. However you probably want these features in combination with
> regular syntax highlighting. Maybe a layered approach would somehow work

Thats what I meant. It would basically run independently of the filetype
specific syntax highlighting, probably before it and create the
backgrounds/visual replacements for whitespace, the colorcolumn, another
background for all lines with a cursor and maybe even the line numbers. One
could also add such a global highlighter running after the filetype specific one
to override some stuff. First things that come to mind would be highligthing the
searchterm (hlsearch) or the word, the cursor is currently above.

> > Still does not work. After enabling one of the `show` settings, I am unable
> > to reset it again. I have to restart vis.
> 
> Strange, seems to work fine here.

Okay, I got the issue. `parse_bool` is called with `0\n` as first argument. The
newline character should not be there for the intended behaviour. I also managed
to unset the setting by _not_ using the history. So it seems to be a bug with
the history imlementation. To reproduce it, `:set show tabs` and then
`:0`. I don't know the best way to fix it, but it would
be possible to strip the newline from within the `cmd_set` function.

> The vis way of doing this would be an alias to `gv`

Ah right, I see it's used for `~` now. Could you add this mapping to the
bindings_visual and bindings_visual_line in config.def.h?

> > I also was surprised, `\` works as it should. I propose to change
> > CURSOR_SEARCH_WORD_… to use `\` as regex instead of just `WORD` to
> > achieve the same functionality as in vim.
> 
> Yes I agree.

This patch for vis-motions.c works for me:

@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include "vis-core.h"
@@ -17,8 +18,12 @@ static char *get_word_at(Text *txt, size_t pos) {
 /** motion implementations */

 static size_t search_word_forward(Vis *vis, Text *txt, size_t pos) {
+   char expr[512];
char *word = get_word_at(txt, pos);
-   if (word && !text_regex_compile(vis->search_pattern, word, 
REG_EXTENDED))
+   if (!word)
+   return pos;
+   snprintf(expr, sizeof(expr), "\\<%s\\>", word);
+   if (!text_regex_compile(vis->search_pattern, expr, REG_EXTENDED))
pos = text_search_forward(txt, pos, vis->search_pattern);
free(word);
return pos;

Should be adapted for search_word_backward accordingly. I also noticed, that the
search order is not permanently stored. When using `#` or `?`, I am used to
still search backwards when pressing `n` and forwards when pressing `N`.

> > - Could you replace the `0` in relativenumber mode with the actual line
> >   number?
> 
> should be implemented now.

Thanks.

> > > The fix is to adjust the cursor position before performing the subsequent
> > > motions similarly to how it is done for text objects with a count.
> > 
> > Hm, maybe changing the imlementation of TO_…/TILL_… to ignore the one
> > character under/after the cursor is less of a workaround?
> 
> But this would break the entering `tX` multiple times use case ...

The only stuff that "breaks" with the following patch to vis-motions.c is when
the cursor is over the `X` in `abcabcXdefdef` and you expect `td` or `Tc` to
move the cursor to the last `d` / first `c` in the line. I don't think it's that
useful to don't move the cursor, if you are directly before `d` and want to move
"till" the next `d`.  The behaviour I am proposing is nonstandard in vim (but
more consistent imho).  Little side-note: The `to` commands can more easily
distinguished from the `till` commands when thinking of them as `find` (`f`
shortcut). They move the cursor above the search char, just like a normal search
would.

@@ -57,7 +62,7 @@ static size_t to(Vis *vis, Text *txt, size_t pos) {
 }

 static size_t till(Vis *vis, Text *txt, size_t pos) {
-   size_t hit = to(vis, txt, pos);
+   size_t hit = to(vis, txt, pos+1);
if (hit != pos)
return text_char_prev(txt, hit);
return pos;
@@ -74,7 +79,7 @@ static size_t to_left(Vis *vis, Text *txt, size_t pos) {
 }

 static size_t till_left(Vis *vis, Text *txt, size_t pos) {
-   size_t hit = to_left(vis, txt, pos);
+   size_t hit = to_left(vis, txt, pos-1);
if (hit != pos)
return text_char_next(txt, hit);
return pos;

--Markus

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

[Markus Teich]

Brad Luther wrote:
> On the geometry being a multiple of the font, you say that "In the
> past there was some work to avoid this situation adding pagging pixel
> lines, and it generated a lot of problems". But ACE said there's still
> a way touse it like that, by setting resizehints = False in config.h.
> Would this bring problems?

Heyho Brad,

Just set it to 0 in dwm's config.h. It just enforces the client to use more
space than requested and st handles it fine. I've used it for years now.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Marc,

Marc André Tanner wrote:
> On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> > - Why did you choose to use full black instead of the base03 color from
> > solarized?
> > 
> > - Even after "fixing" the above the colors don't look like solarized in any
> > way.  If you don't know about this yet, I can provide a screenshot.
> 
> Yes I noticed this too and it is the reason why full black was used (to
> increase the contrast). As vis currently uses curses there seems to be no
> clean way to support true colors[0]? What happens at the moment is that the
> given 24bit color is converted to the closest color of the terminal 256 color
> palette. This color conversion code was imported from tmux.
> 
> Strictly speaking we do not need to display many colors we just want to
> specify them as RGB values. Curses provides a init_color(3) API to change the
> defintion of the color palette. However I'm not sure how many terminals
> actually support these color chaning capability.
> 
> Anyway up until now I didn't realize solarized had a 256 color degraded
> version[1,2]. I changed the default 256 color theme to that. Is it better now?

Actually it did not help. Here is a screenshot of the new standalone build of
vis with the solarized.lua file opened in st:
http://fs.tum.de/~teichm/Media/vis_wrong_colors.png

My st already has the solarized theme set up for the first 16 color slots, so
setting theme to default-16 kind of works (background color is base02 instead of
base03, but I might figure that out myself).

> > - Could you make `~` an instant action? Changing stuff to upper xor lower
> > case can already be done by `gu` and `gU` and switching case on more than
> > one character rarely makes sense. Also you could use visual mode for that.
> 
> I personally don't really care, but it was requested before. Changed.

Thanks.

> > - How am I supposed to set my default theme/tabwidth/relativenumber/…
> > settings?  I could not find the option in config.h.
> 
> By changing visrc.lua:
> 
>  vis.command('set ')

Thanks, I missed that in the README. However there should be a few examples. I
just tried to insert the vis.command in global context and got a SEGFAULT. After
moving it to the win_open event handler context, it worked. :)

> > - In vim I have setup tabs not to display a special "tab" character, but to
> > use a slightly different background color (base02 instead of base03). This
> > also applies to whitespace at EOL. How could I achieve that with vis without
> > patching every syntax lexer?
> 
> At the moment this can not be done easily. The tab replacement symbols are
> currently hard coded in view.c and there is no distinction made between
> "regular" whitepace and trailing whitespace.
> 
> In the long term it might be a good idea to move the implementation of all
> these display related things (i.e. :set show tabs newlines spaces, cursorline,
> colorcolumn etc.) from the C core into Lua.

Maybe a global default 'syntax highlighter' applied regardless of file type
could do the job?

> > - Using `set show newlines 0` (also for tabs and spaces) does not work.
> 
> Use `set show newlines=0` for now.

Still does not work. After enabling one of the `show` settings, I am unable to
reset it again. I have to restart vis.

> > - I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)
> 
> In general this is already implemented i.e. a shortest unique prefix match is
> used. The problem was that `:e` was ambiguous it could either refer to `:edit`
> or `:earlier`. I have now added an explicit alias to break the tie.

Thanks.

> > - What about automatic text wrapping?
> 
> Are you referring to the automatic insertion of new lines? Not a big fan.  I
> prefer an external tool such as fmt(1) which is hooked up to the `=` 
> operator. 

I have a pretty wide screen (>250 symbols in default zoom levels), where editing
long blocks of text becomes much easier with the automatic wrap after 80
columns. Without it, navigating gets a little tedious without running the
formater manually each time I have to jump around in the text. Maybe an event
could be introduced as well here, so you can enter the newline from lua?

> > - Why do you keep the default vim behaviour of `Y`? Please make it
> > consistent and just yank until EOL and not the whole line.
> 
> Is this really consistent? For example `S` also operates on the whole line ...

Thats right, `s` is a little different, since it is an instantaneous action. For
applying an opperand to the whole current line, there is already the "double"
shortcut (e.g. `dd`, `yy`, …), so I thing changing Y to only yank until EOL is
at least making it consistent with D and C. If you want "

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Marc André Tanner wrote:
> Did you (or anyone else) try it? First impressions? Which features did you
> miss the most?

Heyho Marc,

I built the standalone version and tried some stuff. I also went through my
vimrc to find any features I would like to use. Here are my comments in no
particular order.

- Why did you choose to use full black instead of the base03 color from
  solarized?

- Even after "fixing" the above the colors don't look like solarized in any way.
  If you don't know about this yet, I can provide a screenshot.

- Could you make `~` an instant action? Changing stuff to upper xor lower case
  can already be done by `gu` and `gU` and switching case on more than one
  character rarely makes sense. Also you could use visual mode for that.

- How am I supposed to set my default theme/tabwidth/relativenumber/… settings?
  I could not find the option in config.h.

- In vim I have setup tabs not to display a special "tab" character, but to use
  a slightly different background color (base02 instead of base03). This also
  applies to whitespace at EOL. How could I achieve that with vis without
  patching every syntax lexer?

- Using `set show newlines 0` (also for tabs and spaces) does not work.

- I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)

- What about automatic text wrapping?

- Why do you keep the default vim behaviour of `Y`? Please make it consistent
  and just yank until EOL and not the whole line. Also with `<` and `>` in
  visual mode: It should not loose the visual selection, so you can (un)indent
  the lines multiple levels without using `gv` inbetween.

- `*` does not behave the same as in vim. When using star on `view->bla` it
  should search for `\`, but it also found `view_draw`, so there seems to
  be something wrong with the word delimiters when used by `*` (searching for
  `\` produces the expected result. Also the search string generated by
  pressing `*` should be added to the search history.

- Is hlsearch planned?

- I frequently use C-a and C-x to do basic addition/subtraction in vim.

- Any possibility to hook up a setting depending on the currently active mode? I
  like to have relativenumber in normal+visual mode while having normal line
  numbers in insert mode. Changing all the bindings in config.h seems a little
  tedious.

- Could you replace the `0` in relativenumber mode with the actual line number?
  Moving up/down 0 lines is not that hard without having the `0` in front. ;)

- Could you explain the concept behind the commandline history? When I used it
  to run a slightly changed previous command, the history was changed as well.

- Why the `:saveas` command? Couldn't you just use an optional argument to `:w`?

- Are you planning to implement buffers / having multiple files open at the same
  time? I often use the `switch to last used buffer` feature of vim.

- I noticed `d2tX` is not working as it is in vim. Is there a way to achieve the
  same deletion within vis in >= 4 keystrokes or is this also the "bug"
  mentioned in the README?

- What about word/file/line completion in insert mode?

- Why you no implement `g?`? ;)

I can probably help implementing a few of the mentioned features, but I would
like to hear your oppinion on them first. Great work so far, I planned to check
vis out quite a while ago and finally found the time.

--Markus

Re: [dev] [slock] won't lock if unclutter grabbed mouse pointer

[Markus Teich]

Andreas Doll wrote:
> I've just tested with i3lock 2.6 (on Debian stable), which also returns after
> a short moment to the desktop without verification, complaining
> 
> $ i3lock
> i3lock: Cannot grab pointer/keyboard

Heyho Andreas,

I assume this is the same issue for slock. From XGrabKeyboard(3):

> If the keyboard is actively grabbed by some other client, XGrabKeyboard fails
> and returns AlreadyGrabbed.

For screenlockers grabbing the keyboard is a must so no other client can
intercept the password when entered to unlock the screen. Users of `unclutter
-grab` could kill the unclutter process before running slock/i3lock and restart
it after the screen has been unlocked. For i3lock this is not so easy, since the
i3lock process daemonizes itself and returns immediately, so the naive `pkill
unclutter && i3lock && unclutter -grab` approach won't work.

> so the issue seems to be caused by unclutter.  Hence maybe a manpage entry
> warning about that behaviour is sufficient. Do you agree, or are you still
> planning to fix this within slock?

I don't think it can be fixed in slock. I'm not sure, if we can "blame"
unclutter for the issue, but if we can, then the hint should go into their man
page or even better it should be fixed there.

--Markus

Re: [dev] [slock] won't lock if unclutter grabbed mouse pointer

[Markus Teich]

Andreas Doll wrote:
> By the way, xscreensaver successfully locks the screen, and prints
> 
> couldn't grab pointer! (AlreadyGrabbed)
> 
> and displays the verification window only upon keyboard activity. Without
> unlcutter this window appears also on mouse input.

Heyho Andreas,

This is probably because xscreensaver doesn't mind if the Pointer could not be
grabbed. However for screen lockers which are meant to be a security feature I
think it is a good idea to prevent *any* input except the password entry to
unlock the screen.

> Personally I'd prefer to have the hint in slocks manpage, as it took me some
> time to realize what's going on. The Debian maintainer chose to write a
> distro-specific manpage for slock - for now I'll report the behavior to him
> and let him decide whether he wants to include this.

I don't like the man-page approach. Documentation always looses synchronization
to the codebase, so my proposal would be to output a similar error message in
slock. The link from "slock: could not grab pointer" to `unclutter -grab` should
be easy enough to discover then.

By the way: Why are you using the `-grab` switch? According to the man page this
seems to be the old version. The developer probably noticed that grabbing the
pointer is not the best idea and implemented another method of hiding the
cursor.

> -grab  means use the original method of grabbing the pointer […]

--Markus

Re: [dev] [slock] won't lock if unclutter grabbed mouse pointer

[Markus Teich]

Andreas Doll wrote:
> I've tested with slock 1.1 and 1.2. Upon researching this issue I found that
> it was already noticed by others. Arch wiki [1] blames unclutter for this and
> notes that is also breaks i3lock, which isn't confirmed in [2].
> 
> I'm not sure if you are fine with the current behaviour (by indeed blaming
> unclutter), or unaware of this issue.
> 
> [1] 
> https://wiki.archlinux.org/index.php/Unclutter#Misbehaviour_of_the_mouse_cursor
> [2] http://comments.gmane.org/gmane.os.netbsd.devel.pkgsrc.user/22667

Heyho Andreas,

I was not aware of that issue. The man page of unclutter says for the `-grab`
option "This often doesn't interoperate too well with some window managers" so
it might actually be not slocks fault. Since this does not seem to be a critical
issue, I will dig deeper into this when I can spare the appropriate amount of
time. Any further information or even patches are welcome.

--Markus

Re: [dev] libutil/eprintf clarification patch (to the Evil_Bob's request)

[Markus Teich]

FRIGN wrote:
> I had that floating in my mind as well, but the thing is, that some utils call
> usage() pretty often.  You would have to specify the long usage-string every
> time which makes it unfeasable.

Heyho FRIGN,

yeah right…

$ grep -r "usage()" | wc -l
219
$ ls *.c | wc -l
87

I thought about introducing a constant/define for that, but that would mess
things up even worse.

--Markus

Re: [dev] libutil/eprintf clarification patch (to the Evil_Bob's request)

[Markus Teich]

FRIGN wrote:
> I thought about this tonight and came to the conclusion that this "hack"
> doesn't introduce too many problems.

Heyho FRIGN,

what do you think about making `usage(int status, char *shortargs)` an
eprintf-like function in eprintf.c? This might clear things up for everyone.

--Markus

Re: [dev] libutil/eprintf clarification patch (to the Evil_Bob's request)

[Markus Teich]

e...@bestmx.net wrote:
> http://file.bestmx.net/ee/suckless/

Heyho,

you have a line with just an indentation tab in eprintf and enprintf.

Also why upload it instead of just sending the patch via mail?

--Markus

Re: [dev] Female contributions

[Markus Teich]

e...@bestmx.net wrote:
> how about "age" and "size" attributes too,
> just to ensure age and size "equalities".

Heyho,

I am looking forward to 1% commits adding the word "mum" or "dad" in random
places. How do you plan to check if all the SLoC are evenly distributed between
the different attributes? Or do you plan to even look at a character-level
distribution? Is a suckless pre-receive hook already in the making rejecting all
commits which break the equality?

--Markus

Re: [dev] slock size is not changed at resolution change

[Markus Teich]

Heyho,

Martin Ueding wrote:
> I think I did not mention properly that the external screen is additional to
> the laptop screen. slock would have to create a second window to cover both
> displays.

I don't remember if I tested with automatically adding another screen while
locked. Let me know, when you managed to run the latest version.

> I have version 1.2 here, so from the tree I think that this January commit[1]
> is missing then?
> 
> [1]:
> http://git.suckless.org/slock/commit/?id=a31b919572dafaa8366415b89a4472aa4626

Nope, the next one[0].

--Markus


0: 
http://git.suckless.org/slock/commit/?id=f5ef1b8ebda11e81d92d8d05acd4aba1ef40

Re: [dev] slock size is not changed at resolution change

[Markus Teich]

FRIGN wrote:
> usually, slock should get a XRRScreenChangeNotifyEvent when the screen size
> changes. I wonder why it isn't fired; maybe there's a bug in slock or in
> awesome wm not sending proper events.

Heyho,

this should be fixed since January. Martin, can you confirm the bug persists
when using current git HEAD?

--Markus

Re: [dev] dwm: drw_draw does too much

[Markus Teich]

David Kennedy wrote:
> However, this new function still needs to know three things:
> 
> 1. The font to use
> 2. The text to be rendered
> 3. The length in bytes of the utf8 encoded string
> 
> No. 2 is easy. No. 1 and 3 are all tangled up in drw_text. So, before calls to
> drw_text and TEXTW can be replaced with drw_get_width, those pieces need to be
> decoupled somehow.
> 
> I'll start working on that, but it may be a while. I'm very new to C.

Heyho,

you guys might have a look at the drw.c code from sent. I think I already
grappled with that "inconvenience" and kind of "solved" it. I currently don't
have time to do it myself, but might look into it in a few days, if you don't.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Heyho,

Claudio wrote:
> I've implemented a web-based "port" of sent called wsent.  I agree to not
> use the web for anything so I decided to abandon the project after reading
> the Quenting Rameau post where he suggests a slide to image conversion.
> Though, since I've put some effort on writing wsent (which is in still in a
> early stage) I though someone may be interested. I created the repository
> again.

ACE wrote:
> It's true that the web sucks, however I'd consider presenting text and
> some images totally OK for use on the web platform:
> + You're publishing this; it's a good idea if a lot of people can view
>   the content.
> + The text can be copied
> - We're dealing with web browsers; there will be issues.
> 
> Ofcourse you could just release the .txt file however I can see some
> non-technical people prefer to have the slides as you presented them, the web
> platform will fit well for this.
> 
> If I publish a sent presentation it will be in the original .txt and web
> format.
> 
> Alternatively I've seen LaTeX Beamer presentations released in a "paper"
> format where the slides are reformatted so they fit into the paper like
> regular text and only some small "ticks" which works as indicators of where
> slide bounderies are.
> 
> Another thing to think about; what about printing the slides?

I am willing to accept a patch of a sed/awk shell script converting a slide file
to static html (just use  and  blocks) page or a .tex input file
for a latex document (no beamer presentation, you already have sent for
presenting) to be printed.

> Maybe Takahashi method slides don't fit well on paper slides?

The takahashi and monte methods are not meant for sharing in any other way than
the real presentation or a recording of it.

--Markus

[dev] [surf] background window color

[Markus Teich]

Heyho,

a little annoyance, that bugged me for quite a while is that you get a short
white "flash" when changing between different tabbed clients running surf. This
is mostly only visible when both websites have a dark background. I tested it
and I can "fix" it for these cases with the following lines:

GdkColor bla = {0,0,0,0};
gdk_window_set_background(GTK_WIDGET(c->win)->window, );

This effectively sets the XWindows background to black. Now for bright websites
its obviously counterproductive, so my plan was to set the XWindow background
color to the same color used for the  tag of the website displayed.
I tried two methods to get this color from webkit, but both failed (returning an
empty string). If you know, how to extract this value from webkit, please let me
know. It should of course also work with custom stylesheets, so basically it
should return the "background-color" value of the "computed" style of the 
tag from the inspector.

Here are the two approaches I tried (I put them into the keypress function to
test it on demand during or after pageload has finished):

WebKitDOMDocument *doc;
WebKitDOMElement *body;
WebKitDOMCSSStyleDeclaration *stil;
gchar *color;
if ((doc = webkit_web_view_get_dom_document(c->view))
&& (body = webkit_dom_document_query_selector(doc, "body", NULL))
&& (stil = webkit_dom_element_get_style(body))
&& (color = webkit_dom_css_style_declaration_get_property_value(stil, 
"background-color")))
puts(color);


WebKitDOMDocument *doc;
WebKitDOMHTMLBodyElement *body;
WebKitDOMCSSStyleDeclaration *stil;
gchar *color;
if ((doc = webkit_web_view_get_dom_document(c->view))
&& (body = (WebKitDOMHTMLBodyElement*)webkit_dom_document_get_body(doc))
&& (color = webkit_dom_html_body_element_get_background(body)))
puts(color);

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

hiro wrote:
> I have done some presentations in word, fixing errors that i did in the night
> before while still presenting. people *love* the instant gratification of
> having their contribution incorporated into the "slide" in the most visible
> way.

Heyho hiro,

you're welcome to provide a patch implementing a reload keybinding. Then you
could have the source file open, fix stuff during the presentation and then just
reload the file. Should not be too hard.

> Afterwards I compiled it all to latex and then pdf and everyone got something
> to take home and copy-and-paste from much more efficiently.

Not sure if sarcasm… I don't think copying from a pdf is more efficient than
copying from a text file. I don't know any pdf reader, that does it right, it's
a mess.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Joerg Jung wrote:
> Have you compiled sent with address sanitizer as suggested in the link, or
> enabled the malloc.conf J option on OpenBSD, as mentioned above?

Heyho Joerg,

sorry, I missed that point. Please check again, I just pushed a fix, which
should work. I could not test it, since I don't have a BSD system and
compilation with address sanitizer enabled failed (probably due to the required
libs not being compiled with it). Let me know if it works now.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Qentin Rameau wrote:
> > > > 'sent empty' with empty being a 0-length file will produce a
> > > > memory access error.
> 
> I think I was able to fix that, please try the recent patch I posted on
> hackers@.

Heyho,

Yeah, sorry, I forgot to commit and push my fix, but now it should really be
fine, since we even have two fixes now.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Joerg Jung wrote:
> However, can you tag/roll a new release/tarball please?

Heyho Joerg,

I plan to make a 0.2 bugfix release before merging the farbfeld change. However
I would like to wait a few days before that to see if you guys find some more
bugs. ;)

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Greg Reagle wrote:
> There are indeed some people on this list who interpret plain bug reports as
> rude and react in a hostile manner to them, even though
> http://suckless.org/community says that dev@ is appropriate for bug reports.
> I wish these people would adjust their attitude.  Not only are they
> contradicting the written policy on the suckless website, they are
> discouraging bug reports.  Is it better to have unreported bugs?

Heyho,

there are bug reports and there are "bug reports". The first report for the
segfault issue from Stephen Whitmore was more of a "bug report". I could not
reproduce it as described (the imgage slide rendered fine without a crash) and
there was no backtrace or other information helping me hunt it down. Therefore I
assumed it had something to do with the png scaling and postponed the fix due to
the coming switch to farbfeld.

The second report from "ret set" was better. It actually helped me reproduce the
bug (the python example) and contained a backtrace in case I would not be able
to reproduce it myself to at least have a hint on where to look for the bug. I
don't mind such kinds of bug reports if the sender actually is not able to fix
it himself but no one should expect such bugs to be fixed immediately by the
maintainer or some one else.

Luckily both reports were for the same bug and that one was easily fixable and I
had the spare time to actually do it myself.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

FRIGN wrote:
> A better way, as I suggested at hackers@, would be to find a way to ad-hoc
> convert png's, gif's, whatever, to farbfeld.  This would simplify the
> sent-code dramatically and also actually bring the benefits of the farbfeld
> format.

Heyho ACE,

as explained in further detail this is the plan. sent will natively support only
pure farbfeld images in the future. However a config array will be added where
you can specify how to convert the formats you would like to use to ff format.
All the ff-supplied conversion tools (currently there is only png, but I expect
jpg and gif to be revived soon) and some compressed ff formats will be available
through config.def.h default. So for using sent you will have to install the
farbfeld conversion tools and then png will work like you are used to from the
current state.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Marc Collin wrote:
> Is there any way to export the 'sent' presentation in case I need to use it on
> another machine that doesn't have 'sent' installed, but supports .png ?

Heyho Marc,

no such feature is planned. If you look at e.g. Powerpoint you also need the
application installed. For latex-beamer presentations you need a pdf viewer
installed. sent is easy enough to install in probably less time it takes
Powerpoint to boot up.

If you really think an image viewer with much more complexity than
sent is a better programm to hold your presentation, you can still make
automated screenshots with a simple shell script using xdotool+(screenshot
application of your choice). However this looses quality if you have different
screen resolutions on your capturing and the presentation monitor.

--Markus

Re: [dev] sent-0.1 or libxft bug

[Markus Teich]

u...@netbeisser.de wrote:
> On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote:
> > Segmentation fault
> > ~/src/sent-0.1$
> 
> different crash with zzuf:
> 
> zzuf -r 0.06 ./sent sent.c
> …
> error, cannot load font: 'ubuntu:size=10'
> error, cannot load font: 'roboto:size=10'
> error, cannot load font: 'dejavu:size=10'
> …
> error, cannot load font: 'ubuntu:size=335'
> error, cannot load font: 'roboto:size=335'
> error, cannot load font: 'dejavu:size=335'

Heyho,

nice, you aparently used input fuzzing to find out that your font setup is
broken?

Try the latest commit, it should not segfault anymore, but just die since none
of the fonts are available on your system. Install one of them or select an
installed one in config.h to actually get some slides on the screen.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Joerg Jung wrote:
> Here comes another one...
> 
> As mentioned in this thread:
> http://marc.info/?t=14477246942=1=2 in this mail:
> http://marc.info/?l=oss-security=144774881126397=2
> 
> 'sent empty' with empty being a 0-length file will produce a memory
> access error.  On OpenBSD with malloc.conf -> J it happily dereferences a
> 0xd0d0d0d0d0d0d0 pointer since there is not such input as line[0] if the
> file is empty.
> 
> Same for a file with blank lines.

Heyho Joerg,

I cannot reproduce both of these bugs with current HEAD. I get the usage message
as it is expected due to the following two lines in main():

if (!slides || !slides[0].lines)
usage();

Maybe you or they are running an old version? Please try the latest one.

--Markus

Re: [dev] Space to advance to the next slide

[Markus Teich]

Jan Christoph Ebersbach wrote:
> Since Space is very common in other presentation tools to advance to the next
> slide it would be a great default for sent as well.  The attached patch adds
> the Space key as another way to advance to the next slide.

Heyho Jan,

merged. Thanks for the contribution.

--Markus

Re: [dev] sent-0.1 or libxft bug

[Markus Teich]

Nick wrote:
> But regardless, as far as I can see this is fixed in the latest code 
> in git, aa713a8a342ec0e6eca173cd4489834f8baa0a86.

Heyho,

Yes indeed, it was the same segfault mentioned earlier. I replied to both of
them, but probably your MUA does not show my reply in both threads in threading
view.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Heyho,

ret set wrote:
> $ make && ./sent <(python -c 'print "A\n"*4000')
> …
> Segmentation fault

Stephen Whitmore wrote:
> When running the example presentation, I hit a segfault when I reached the
> first slide with an image (@nyan.png). See attached for backtrace.  This only
> seems to happen if the window is smaller than certain dimensions.
> I can repro for large text lines in small windows, too.

Thanks for submitting the bug report. They should be fixed in the latest commit.
I could not reproduce the image problem, but it should also be fixed, please
test, Stephen. I also remind you, that this is a developers list and not a user
support list (suckless has no users, just developers). Just sending in bug
reports without at least a proposal of how to fix it is seen as rude.

> Tangential nit: The README still seems to say that slides are per-line vs
> per-paragraph.

Also fixed.

> Please let me know if there's a better place for me to post this -- I didn't
> see a specific mailing list mentioned on the project page.

This is the correct list, but as already explained you should have submitted a
patch with the bug report. The bug really was not that hard to find, so please
at least try to find a solution next time. ;)

Thanks anyway.

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

KIMURA Masaru wrote:
> > ... takahashi style presentations ...
> 
> you might also check monta method?

Heyho,

Interesting. Just set the first font to something like `dejavu sans mono` then
you can duplicate the slides where you want to apply the monta method and use
`_` as a placeholder for the characters to be revealed on the next slide.

--Markus

Re: [dev] sent-0.1 or libxft bug

[Markus Teich]

Heyho,

v4hn wrote:
> > and what you think was causing it.
> 
> On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote:
> >> Subject: [dev] sent-0.1 or libxft bug
> >> [...]
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x77529980 in XftCharExists () from 
> >> /usr/lib/x86_64-linux-gnu/libXft.so.2

Yeah right, so we just have to put a `if (addr == 0x77529980)` check in
there to fix it… (that was sarcasm)

> I do think the current behavior w.r.t. long lines or long paragraphs could be
> improved though.
> 
> Over here using the latest HEAD ret set's example yields a slide with *one*
> rather small "A" at the top center.  Also I just noticed that `./sent <(python
> -c 'print "A"*4000')` (might vary with screen size/available fonts?) gives me
> a number of rather big As partially overlaying each other, whereas `./sent
> <(python -c 'print "A"*400')` works pretty much as expected: the line is too
> long for the screen with a reasonable font size, so a long string of rather
> small As is printed from side to side.

You are welcome to work on this, but huge patches just to fix non-usecases would
not be helpful and be rejected. However if the fix is simple enough, I would
merge it.

The font sizes are calculated with the formula given in config.h so you can
adjust them to your screen size/resolution and font settings. You should make
sure the biggest Font size fits the usableheight of your screen (Just one 'A'
and see, if it gets bigger when you increase NUMFONTSCALES) and the smallest one
should fill the longest line in the usablewidth and also the slide with the most
lines vertically (If these two test cases are not rendered within the usable
space of your screen, then you have to modify the FONTSZ function to start at
even smaller font sizes).

The default values work well for me with a 1366x768 screen and the default
dejavu font. On my larger 2560x1440 screen the largest fontsize produced by
FONTSZ is too small, so I just increased NUMFONTSCALES accordingly.

--Markus

Re: [dev] [sbase] cal doesn't highlight current day

[Markus Teich]

hiro wrote:
> otoh i'd really like to see anyone use cal for anything useful, how do you use
> it in practice?

Heyho hiro,

I sometimes use it to get a quick reference about which weekday a specific day
in the near future is.

--Markus

[dev] [sent] 0.1 release

[Markus Teich]

Heyho,

I am happy to announce the version 0.1 release of sent, a suckless presentation
tool. Yesterday I finished the multiline support and now sent is not anymore
only useful for takahashi style presentations. The next big step for the 0.2
release is to migrate from png to farbfeld.

http://tools.suckless.org/sent
http://git.suckless.org/sent
http://dl.suckless.org/tools/sent-0.1.tar.gz

--Markus

Re: [dev] [sent] 0.1 release

[Markus Teich]

Dimitris Papastamos wrote:
> Nice!  You might also want to update the news page on the site.

Heyho Dimitris,

Oh right, thanks. Did it just now.

--Markus

Re: [dev] [sent] initialize .img

[Markus Teich]

Szabolcs Nagy wrote:
> without the attached patch ./sent example segfaults here

Heyho,

thanks, I applied the fix.

--Markus