Le 16/01/2016 22:26, Enrico Forestieri a écrit :
On Sat, Jan 16, 2016 at 06:29:32PM +0000, Guillaume Munch wrote:
Le 16/01/2016 17:06, Enrico Forestieri a écrit :
On Fri, Jan 15, 2016 at 07:45:35PM +0000, Guillaume Munch wrote:
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.
I could not reproduce this one.
I can reproduce it systematically.
1. New file 2. Type something in an itemize environment 3. Enter
three times, get a separator 4. Place the cursor at the beginning
of the document 5. Ctrl+Shift+Right until the after position is
reached
optionally:
6. Do copy+paste, to get the same cursor position but with the
selection removed.
This only occurs when the separator is the last character in the
document. In this case you don't need Ctrl+Shift+Right but simply
use → to get there.
I cannot reproduce your description. My recipe works as well if there is
some paragraph after. (Also you can probably deduce from the context
that I would have noticed.)
* A logically-after cursor position appears when double
clicking the separator inset or the line.
This one was easy. It was also occurring when triple clicking.
See attached.
It is somehow better, but it is very strange because the behaviour
is not consistent: most of the time it selects the word before, but
sometimes it selects the separator (i.e. separator is removed if I
type a key). I get the second behaviour if I quadruple-click (!!)
on the separator or after it (but this was not the only way).
So, what would be missing is a visual indication that the separator
was selected. I don't know how to do that, but maybe someone else
does.
Something else: if you place the cursor before a separator and
press enter, the separator stays on the same paragraph. Is this
voluntary?
Yes. Ideally, you are at the end of the line and pressing enter there
gets you a new paragraph.
Ok, this is just something to get used to.
Also, I was wondering whether we should remove superfluous
separators in the DEPM. This would make a lot of sense to me.
Then, the same should be done for the newline inset. For example,
hit 3 or more times Ctrl+Enter in a standard layout, then remove
everything in the paragraph before the first newline inset (such
that it is now alone on the line). Now you have an uncompilable
document. At least, it could be compiled if you had multiple
separators like that.
I disagree with your newline comparison. Having several newlines
compiles to a different latex code and makes sense, and compilation
issues have nothing to do with DEPM.
Please note that we can stay here finding much more quirks in LyX
that are annoying. The point is that they are not so annoying if
they can only be obtained with uncommon operations.
The "uncommon operations" are only recipes to reproduce consistently. Of
course they can look far-fetched. I got there by trying to reproduce
behaviour that happened by chance without trying too much. I believe you
are shooting the messenger.
The editing operations in the buffer view are a critical part of lyx,
and one that does not suffer from clumsiness so far, which is essential
in particular for the learning curve given that it is so much different
from other softwares. It worries me to introduce quirks and inconsistent
behaviour in this aspect, such as not knowing whether one has to hit del
of backspace, or why the thing suddenly disappeared.
Then, this being free software, if they annoy someone so much, he
can also propose patches.
I prefer not to reply to this or we could get into considerations quite
remote from our current concerns using the same logic.
If you are worried about my suggestion about DEPM being too much for 2.2
you can just say so. You may have noticed that I used a different
phrasing, and I was ready to say that this can be filed as an
enhancement request. Please do not worry about this last suggestion.
Guillaume
