elisp + company completion patches, v7
This round contains several bug fixes from Mark, and a slightly re-organized initialization from me. In particular, TAB should now behave sanely under company. Also there's a stub notmuch-address-message-insinuate to prevent peoples emacs startup from failing. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp + company completion patches, v7
On Sun, Oct 25 2015, David Bremner wrote: > This round contains several bug fixes from Mark, and a slightly > re-organized initialization from me. In particular, TAB should now > behave sanely under company. Also there's a stub > notmuch-address-message-insinuate to prevent peoples emacs startup > from failing. Looks pretty good, I, like Mark, noticed some newline changes in patch 1 (which is fixed in patch 2 so I personally would not care of that). The another indentation thing Mark noticed is easy to amend. I, if this does not sound nitpicking, would amend those 'This patch' and 'With this patch' texts in commit messages away by some rewording -- those pose as a bad example for someone reading the code -- and diminish the effect when I complain that again in future patched ;) The basic completion with this new system using notmuch address output and (supposedly) caching the values seems to work very well and I believe is welcome feature to (new) users. I did not test how company mode works as I don't have it (and there is no company mode for this mixed environment what I use now -- except that I could install it from elpa; maybe I try that in near future...) BTW: if anyone knows how to enable lexical-binding to a block of code (i.e. alternative to -*- lexical-binding: t -*- (or can give hints, like s/\([^-]\)let/\1lexical-let/) I'd like to know...) Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp + company completion patches, v7
2015ko urriak 25an, David Bremner-ek idatzi zuen: > > This round contains several bug fixes from Mark, and a slightly > re-organized initialization from me. In particular, TAB should now > behave sanely under company. Also there's a stub > notmuch-address-message-insinuate to prevent peoples emacs startup > from failing. Guess who wrote a reply before catching up on all the list mail. :P -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp + company completion patches, v7
On Sun, Oct 25 2015, Tomi Ollila wrote: > I, if this does not sound nitpicking, would amend those 'This patch' and > 'With this patch' texts in commit messages away by some rewording -- those > pose as a bad example for someone reading the code -- and diminish the > effect when I complain that again in future patched ;) What's the motivation here? It's often the case that a good commit message needs to describe the way things were working prior to a commit, (describing the bug or missing feature or what have you), and also needs to describe the change that is affected by the commit itself. So I actually like seeing commit messages that say things like: Prior to this commit... (some bug existed...) In this commit... (some code is reworked to fix the bug...) But maybe I've missed the point of your message. -Carl signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp + company completion patches, v7
On Mon, Oct 26 2015, Carl Worth wrote:
> On Sun, Oct 25 2015, Tomi Ollila wrote:
>> I, if this does not sound nitpicking, would amend those 'This patch' and
>> 'With this patch' texts in commit messages away by some rewording -- those
>> pose as a bad example for someone reading the code -- and diminish the
>> effect when I complain that again in future patched ;)
>
> What's the motivation here?
>
> It's often the case that a good commit message needs to describe the way
> things were working prior to a commit, (describing the bug or missing
> feature or what have you), and also needs to describe the change that is
> affected by the commit itself.
>
> So I actually like seeing commit messages that say things like:
>
> Prior to this commit... (some bug existed...)
>
> In this commit... (some code is reworked to fix the bug...)
>
> But maybe I've missed the point of your message.
>
>
> -Carl
Probably the missing point is the fine distinction between
'this patch' and 'this commit'
While we do sets of changes and then that leads to commit series the final
step of running 'git format-patch' somehow leads people writing commit
message to add words 'this patch' to the message...
... or (what just come into my mind) they just think these changes as
patches (is that linux-kernel influence ?)
To me the commit history does not look like series of patches (but series
of commits or changes -- and changes are usually shown as "diffs") --
patching gives a connotation of fixing something (with glue or gum ;)
That is how I see it. That doesn't mean I am right there (and in this mailing
list I've been wrong in statistically significant amount (*) of times).
Un{less,til} decided otherwise I'll continue with delicate efforts to
keep this style issue in the minds of developers; despite (**) informing
me that will be doomed...
Tomi
(*) https://en.wikipedia.org/wiki/Statistical_significance
(**) https://en.wikipedia.org/wiki/Wiio%27s_laws
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
