Bo Peng wrote:
1. lyx-code
2. enter
aaaaa
123456 (there are four leading spaces)
3. change environment to standard
4. select aaaaa and 1
5. cut
aaaaa, 12345 are removed.
It is pretty easy to avoid the crash by adding something like right =
min(right, par[pit].size() + 1) after line 304 of CutAndPaste.cpp,
but I believe that a better treatment is required.
Isn't every crash a critical bug? Why nobody is interested?
I mostly agree with Edwin on this...
Also, the issue you've raised actually seems to be conceptually quite
complicated, and I'm not sure that there's a good answer ---- but I'll
give it a shot anyhow:
The complicated part is: what did the user *mean* by doing this? Can you
think of a realistic case in which the user would want to do what you're
describing (namely, switch from LyX-Code to standard text) --- and if
so, what does the user mean by it? And how would the user want the
spaces to be treated?
I would tend to say that the correct solution would be that when
changing from LyX-Code to standard (or more generally, from any
"verbatim" type environment to any "regular" LyX text environment), the
text should be "converted" to make sure that it is legal LyX text:
leading spaces, adjacent spaces, etc., should all be removed (or
depending on what we think the user means, perhaps converted to "hard
spaces").
The problems with this solution are that (a) it may not be that simple
to implement, and (b) do we really want to make an irreversible change
to the text? What if the user laboriously typed in some code with
indentation and all, and then switched the environment by accident? I
guess (b) could be addressed by either or both of these solutions: (1)
when doing this, a dialog should be opened which warns the user about
the change about to happen, or (2) make sure that the change is atomic
with regard to "undo".
Now that I think of it, solution (2) seems to be good, so we're only
left with the question (a) of how difficult it would be to implement all
this. But I think that this is the "correct" approach.
I must agree with Edwin here again, though: I don't know that this is
high priority, just because it's probably quite rare...
Dov
