Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release
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
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
Am 2018-03-11 04:21, schrieb Anselm Garbe: On 10 March 2018 at 06:08, Markus Teich 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
(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
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
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
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
Heyho, Hiltjo Posthuma wrote: > Minor nitpick, I'd prefer a space after the wildcard: > > + snprintf(msg, sizeof(msg), "* %s %s", nick, > > &buf[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 ? &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
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
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
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
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
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
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
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
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&pathrev=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
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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.
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
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
--- 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] suckless debugger?
u...@netbeisser.de wrote: > do you know of a suckless linux debugger? what is an alternative to ptrace? Heyho Stefan, just use printf debugging. --Markus
Re: [dev] [slcon3] preliminary schedule and registration deadline
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?
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
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
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
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
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
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
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?
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
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] Languages that suck (was "Note On Webkit Versions")
Heyho, seeing the new subject I feel obligated to leave this link here: https://www.destroyallsoftware.com/talks/wat --Markus
Re: [dev] Re: [slock] red color on control keys?
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?
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
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
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
Martin Kühne wrote: > stdout could print an api secret "[locked]" and the calling script could act > upon that. > > slock | { > read > if [[ "$REPLY" = "[locked]" ]]; then > suspend > else > yell at user or power off for added security > fi > } Heyho Martin, thats basically the same solution. It just uses another channel to signal the "locked" event from slock. I don't think any one is more powerful than the other and the fork exec solution seems to be cleaner. --Markus
Re: [dev] [ANNOUNCE] slock-1.3
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
Re: [dev] [ANNOUNCE] slock-1.3
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
[dev] [ANNOUNCE] slock-1.3
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] tag new slock release?
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?
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
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
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?
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
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
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
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
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
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
Re: [dev] [PATCH] Change an eprintf to a die to stop child from running its own slideshow
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
[dev] [vis] text_line_end() in insert mode
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
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] [slock] won't lock if unclutter grabbed mouse pointer
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
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] [bugs] st clears up upon resize and other little things
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
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] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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 i
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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
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
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
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)
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)
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)
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
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
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
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
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
[dev] [sent] 0.2 release
Heyho, I am happy to announce the version 0.2 release of sent. This is just a bugfix release to help package maintainers before the migration to farbfeld is done for version 0.3. http://tools.suckless.org/sent http://git.suckless.org/sent http://dl.suckless.org/tools/sent-0.2.tar.gz --Markus
[dev] [surf] background window color
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, &bla); 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
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
Re: [dev] [sent] 0.1 release
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
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
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
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
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 release
Joerg Jung wrote: > Here comes another one... > > As mentioned in this thread: > http://marc.info/?t=14477246942&r=1&w=2 in this mail: > http://marc.info/?l=oss-security&m=144774881126397&w=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] sent-0.1 or libxft bug
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
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
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] Space to advance to the next slide
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 release
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
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] sent-0.1 or libxft bug
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
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