[hackers] [slock] Exit as soon as possible on input grabbing error || Quentin Rameau

2016-08-30 Thread git
commit c2f975773d720e734dbdab9a1e9ae51b0972ae0c Author: Quentin Rameau AuthorDate: Tue Aug 30 17:33:09 2016 +0200 Commit: Markus Teich CommitDate: Tue Aug 30 19:54:26 2016 +0200 Exit as soon as possible on input grabbing error We want to know at once if slock failed or not t

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Quentin Rameau
> if you guys really care that much about line length and other vague > points from the style guide, please start another thread and I'll be > happy to participate in the discussion and help to update projects > after a decision is made. As I said, I don't really mind. :) Of course, amend the chang

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Markus Teich
Heyho Quentin, Quentin Rameau wrote: > 1/Why report later what you can do now? I value consistency more than iterative style improvements. See also the very first paragraph of the style guide. > 2/What don't you like in my suggested solution? The answer is again consistency. The style of one li

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Quentin Rameau
> since there are multiple other lines even longer than those two > fprintf calls, I'd just put them in one line and address the issue on > a project level in a separate patch when the community has agreed on > the definition on "reasonable" used in the style guide[0]. > > fprintf(stderr, "s

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Markus Teich
FRIGN wrote: > Quentin Rameau wrote: > > + fprintf(stderr, > > + "slock: unable to grab mouse pointer for screen %s\n", > > + screen); > > this looks like a good compromise. :) Heyho, since there are multiple other lines even longer than those two f

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread FRIGN
On Tue, 30 Aug 2016 19:12:26 +0200 Quentin Rameau wrote: Hey Quentin, > Personally I don't mind, but you could break the lines after each > argument and satisfy both churches. ;) > ie: > + fprintf(stderr, > + "slock: unable to grab mouse pointer for > screen %s\

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Dimitris Papastamos
On Tue, Aug 30, 2016 at 07:06:14PM +0200, FRIGN wrote: > On Tue, 30 Aug 2016 18:48:20 +0200 > Markus Teich wrote: > > Hey Markus, > > > The error message strings should not be split over different lines, > > even if they break the 80 character line length rule. On failure you > > want to be able

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Quentin Rameau
> Hey Markus, Hi Makus, FRIGN :) > > The error message strings should not be split over different lines, > > even if they break the 80 character line length rule. On failure you > > want to be able to grep for the exact error string in the source > > code and > > > > grep "unable to grab keybo

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread FRIGN
On Tue, 30 Aug 2016 18:48:20 +0200 Markus Teich wrote: Hey Markus, > The error message strings should not be split over different lines, > even if they break the 80 character line length rule. On failure you > want to be able to grep for the exact error string in the source code > and > >

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread Markus Teich
Heyho, Quentin Rameau wrote: > We want to know at once if slock failed or not to lock the screen, not seing a > black screen for a whole second (or two) and then die. Thanks to ^7heo for > reporting this. Thanks for the patch. I'd like to apply it with one change: > + fprintf(stderr

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread FRIGN
On Tue, 30 Aug 2016 17:33:09 +0200 Quentin Rameau wrote: > We want to know at once if slock failed or not to lock the screen, not > seing a black screen for a whole second (or two) and then die. > Thanks to ^7heo for reporting this. I support this patch. We intensely discussed this on IRC and it