Le 14/01/2016 20:13, Enrico Forestieri a écrit :
On Thu, Jan 14, 2016 at 03:59:41PM +0000, Guillaume Munch wrote:
We might be speaking of two different issues:
* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).
* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).
To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.
I have now found where to tweak the sources and the attached x1.diff
patch solves the issue for me.
Thanks again for taking all these remarks into account.
x1.diff works as expected, it solves both issues, and I am ready to +1 you.
However, this reveals new ways of creating an "after" cursor position:
* A visually-after cursor position appears with Ctrl+Shift+Arrows
(LFUN_*_SELECT_WORD of something like this). It remains a right position
after deselection, for instance by doing copy and immediately paste.
* A logically-after cursor position appears when double clicking the
separator inset or the line.
A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)
I will have a look at this.
The attached x2.diff patch takes care of this. It seems that this
behavior was a deliberate choice of mine, but it was wrong, apparently.
Actually I think it was a good idea, but only when the separator is
alone on the line. Would you like to keep your code but add instead a
check for the separator being alone on its paragraph? Otherwise I can
vouch for the patch, if you prefer removing your code.
If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.
I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.
This would be accomplished by the attached patch.
Indeed the patch is trivial and I can vouch for it (if needed
symbolically). Please commit it if you are convinced as well that this
is a good solution.
I took this as a +1 and committed the patch.
Thanks.
Guillaume
