Re: revision 3: easing access to the cryptographic envelope
On Sun, May 26 2019, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote:
>>> Daniel Kahn Gillmor writes:
>>>
This is the third revision of the series originally posted at
id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at
id:20190520032228.27420-1-...@fifthhorseman.net)
This series addresses comments raised by David Bremner in his review.
Thanks, Bremner!
>>>
>>> I pushed this version, with 4 minor whitespace fixups (inserted spaces
>>> and/or deleted blank lines) that I missed in my previous review.
>>
>> Thanks for these fixes, Bremner. If you have a specific set of tooling
>> that you use that i can adopt to catch those kinds of coding convention
>> mishaps before submitting, i'd be happy to adopt it so things are
>> "clean". Bonus points if it integrates into emacs via .dir-locals.el or
>> something :P
>
> To be honest my main mechanism for catching those problems is Tomi
> ;).
I used to have simple trailing whitespace cleanup hook
(with its problems). Since Now 2012 I've used ethan-wspace.el which
does cleanups only initially clean content (and higlights if not --
my favorite feature). Like w/ notmuch I also use a bit different version:
localhost$ diff -u vc/ext/ethan-wspace/lisp/ethan-wspace.el
dotdir/elisp/ethan-wspace.el
--- vc/ext/ethan-wspace/lisp/ethan-wspace.el 2019-05-27 23:32:26.625456294
+0300
+++ dotdir/elisp/ethan-wspace.el 2019-05-27 23:38:34.150404797 +0300
@@ -800,8 +800,7 @@
(setq require-final-newline nil))
(when indent-tabs-mode
- (setq ethan-wspace-errors
-(remove 'tabs ethan-wspace-errors)))
+ (ethan-wspace-highlight-tabs-mode))
(run-hooks 'ethan-wspace-errors-in-buffer-hook)
(ethan-wspace-update-buffer)
zsh: exit 1 diff -u ~/vc/ext/ethan-wspace/lisp/ethan-wspace.el
(applied latest change from github just now, changed there 2019-05-21)
> There is also a reasonable uncrustify configuration that I don't use
> as often as I should, mainly because the baseline in various files is
> not there. Perhaps if we did more some global whitespace cleanup this
> would be more helpful. To try it out run
>
> % uncrustify -c devel/uncrustify.cfg --replace $files
>
> then
>
> % git diff
>
> to see what changed.
>
> % find -name .git -prune -o -type f -a -regex '.*[.]\(c\|h\|cc\)' -print
> -exec uncrustify -c devel/uncrustify.cfg --replace {} \;
>
> yields a whopping 1933 insertions and 1903 deletions. Perhaps there are
> some places where the uncrustify config needs tuning, but none of the
> output looked crazy to me. Two things I noticed causing lots of changes
>
> 1) "!foo" -> "! foo"
> 2) putting a leading * in front of multi-line comments
Last time I played w/ uncrustify it was like 2014 -- and I recall there
were things that uncrustify just could not do (more than above) -- like
indenting differently than emacs would do (and IMO something ugly way).
So I wonder if we ever can use uncrustify as tool to verify change
formatting (i.e. identical output or FAIL)...
... perhaps newer uncrustify (latest 0.69, in 2014 version was 0.60)
(with modified uncrustify.cfg) could help there (I also have done
some experiments with "uncrustify postprocessor"; I should take some
time to see how that works with latest tool...)
> If we do decide to rip off the bandage, that will cause a certain amount
> of rebasing pain for any patch series in flight; now (i.e after the
> release) is actually a pretty good time from my point of view, but
> others (e.g. you) might feel differently.
If uncrustifying can be done (even partially), IMO it could be done;
patch series authors just have to revisit their changes (keeping those
live is their duty anyway).
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
On Sun 2019-05-26 13:54:29 -0300, David Bremner wrote: > % uncrustify -c devel/uncrustify.cfg --replace $files thanks for this pointer, i will experiment with it. > If we do decide to rip off the bandage, that will cause a certain amount > of rebasing pain for any patch series in flight; now (i.e after the > release) is actually a pretty good time from my point of view, but > others (e.g. you) might feel differently. I can live with this kind of pain, if it means less frustration later, but what makes you think that "after the release" == "now" ? :P we still have ~5 days till the proposed feature freeze, right? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
Daniel Kahn Gillmor writes:
> On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote:
>> Daniel Kahn Gillmor writes:
>>
>>> This is the third revision of the series originally posted at
>>> id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at
>>> id:20190520032228.27420-1-...@fifthhorseman.net)
>>>
>>> This series addresses comments raised by David Bremner in his review.
>>> Thanks, Bremner!
>>
>> I pushed this version, with 4 minor whitespace fixups (inserted spaces
>> and/or deleted blank lines) that I missed in my previous review.
>
> Thanks for these fixes, Bremner. If you have a specific set of tooling
> that you use that i can adopt to catch those kinds of coding convention
> mishaps before submitting, i'd be happy to adopt it so things are
> "clean". Bonus points if it integrates into emacs via .dir-locals.el or
> something :P
To be honest my main mechanism for catching those problems is Tomi
;). There is also a reasonable uncrustify configuration that I don't use
as often as I should, mainly because the baseline in various files is
not there. Perhaps if we did more some global whitespace cleanup this
would be more helpful. To try it out run
% uncrustify -c devel/uncrustify.cfg --replace $files
then
% git diff
to see what changed.
% find -name .git -prune -o -type f -a -regex '.*[.]\(c\|h\|cc\)' -print -exec
uncrustify -c devel/uncrustify.cfg --replace {} \;
yields a whopping 1933 insertions and 1903 deletions. Perhaps there are
some places where the uncrustify config needs tuning, but none of the
output looked crazy to me. Two things I noticed causing lots of changes
1) "!foo" -> "! foo"
2) putting a leading * in front of multi-line comments
If we do decide to rip off the bandage, that will cause a certain amount
of rebasing pain for any patch series in flight; now (i.e after the
release) is actually a pretty good time from my point of view, but
others (e.g. you) might feel differently.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> This is the third revision of the series originally posted at >> id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at >> id:20190520032228.27420-1-...@fifthhorseman.net) >> >> This series addresses comments raised by David Bremner in his review. >> Thanks, Bremner! > > I pushed this version, with 4 minor whitespace fixups (inserted spaces > and/or deleted blank lines) that I missed in my previous review. Thanks for these fixes, Bremner. If you have a specific set of tooling that you use that i can adopt to catch those kinds of coding convention mishaps before submitting, i'd be happy to adopt it so things are "clean". Bonus points if it integrates into emacs via .dir-locals.el or something :P --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
Daniel Kahn Gillmor writes: > This is the third revision of the series originally posted at > id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at > id:20190520032228.27420-1-...@fifthhorseman.net) > > This series addresses comments raised by David Bremner in his review. > Thanks, Bremner! I pushed this version, with 4 minor whitespace fixups (inserted spaces and/or deleted blank lines) that I missed in my previous review. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
