> 1. Does it fix the reported problem (assuming it is a problem, and not
> an otherwise potentially desirable change in behaviour)?
It does fix the problem.
It reintroduces the previous behaviour, I gather. Can you explain
quickly why it was "a problem"?
> 2. Do any of you have suspicions that it might introduce problems
> elsewhere?
I'm unsure. It seems to be undoing a small part of [fd94312443]
2019-01-22 "electric-layout-mode kicks in before electric-pair-mode", so
I guess it might rebreak whatever that commit is fixing. But I don't
quite understand what that commit is fixing (in particular, where the
commit message says "which can be a problem in some modes", which modes
are those? What is "a problem"?).
Sorry, can't say without investigating much more than time allows. Can you
post the complete sentence?
I vaguely remember that if electric-pair-mode kicked in before
electric-layout-mode we would need more complex layout specs and more
painful indentation logic. That's why I changed it. There is a thread of
discussion with Stefan somewhere about this, not sure if public or off-list.
> 3. Does it pass the automated test suite?
No, it breaks 3 tests in tests/lisp/electric.el:
3 unexpected results:
FAILED electric-layout-int-main-kernel-style
FAILED electric-layout-plainer-c-mode-use-c-style
FAILED electric-modes-int-main-allman-style
In each case, the reason for failure is that the expected result has
trailing whitespace that the actual result misses. I guess
electric-layout does want to put trailing whitespace in certain cases?
Yes, it certainly does. That trailing whitespace is indentation, I believe. And
the cursor should be left at that indentation. Can you confirm? Anyway, if it's
breaking tests it's almost certainly not what we want. And if it breaks in
"plainer-c-mode" (a slightly better behaved c-mode), then its even more
certain that it's not what we want.
... unless the tests are demading something unreasonable from the electric
modes, of course.
--
João Távora