Re: [PATCH v1] Let input queue deal gracefully with up-events

[David Kastrup]

Ivan Shmakov <address@hidden> writes:

>>>>>> David Kastrup <address@hidden> writes:
>>>>>> Stefan Monnier <address@hidden> writes:
>
>  >>> <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19746>.  Judging
>  >>> from the number of wishlist items in the tracker including a patch,
>  >>> that does not appear to increase its chances of getting applied but
>  >>> at least it is then rotting in the proper place.
>
>  >> What would increase the chances, would be you requesting
>  >> write-access, of course ;-)
>
>  > Basically you say that the patch submission and vetting process is
>  > fundamentally broken and useless and that people should ignore the
>  > developer list and bug tracker and just dump their code into the
>  > repository instead and see whether others want to fix it.
>
>       I’m unsure if this comment of mine will help or not, but I /do/
>       see the difference between “the change is OK and I will install
>       the patch” and “the change is OK, but I will /not/ install the
>       patch (because of…)” as the outcomes of the review process.
>
>       In this particular case, the review process (AIUI) resulted in
>       the latter, due to the disagreement on the wording of a single
>       comment in the code.

Not at all.  Comments are part of a change, and the review process
resulted in "the change is not OK.  Should anybody be so unreasonable to
install it in this form, it will be necessary for Stefan to clean up
afterwards".  Since the original author refuses to make the suggested
changes (as opposed to other change suggestions he heeded) because of
being inaccessible to reason, these changes have to be made by
reasonable people instead.

A developer unwilling to keep the Emacs repository in acceptable state
should not have write access.  I can, of course, offer to make the
requested change myself, in a separate commit specifying Stefan's
authorship, with a commit message of his choosing, and then push both
commits.  However, I would then also file a bug report suggesting to
revert the commit attributed to Stefan, referring to my explanation why
it is wrong.

I think we are better off sparing ourselves such silliness.

I am able to work around this shortcoming in the binary by messing with
the modifier cache internals from the Lisp side.  It's ugly and does not
lend itself to further extensibility, but it's not an ultimate
showstopper.

>       Should the review process result in the “the change is NOT OK”
>       outcome, it would indeed be inappropriate for a developer to
>       push the change.  But that’s not the case for #19746.

Comments are an important part of code crucially affecting its
maintainability.  So it _is_ the case.

-- 
David Kastrup