On Thu, Dec 04, 2003 at 11:43:16AM +0100, Helge Hafting wrote:
Andre Poenitz wrote:
I can't even unapply a change of some text to bold in mathed without running round the houses.
What's wrong with <Pos1> <Backspace>?
People don't think of text as formulas. In the text, I expect
backspace to erase the character (or other object) to the left of the
cursor.
And what do you expect if the cursor is at the beginning of some chunk of text in a box?
'Nothing' is certainly a valid option, but 'remove the thing before', i.e. the box itself, is another sensible choice. Don't you think so?
Now we're getting an exception if there happens to be a style change where the cursor is. This will surprise users, some of which don't use math so they haven't seen it there either. There'll be complaints like: "I was removing some text (holding down backspace) and suddenly the formatting (emphasis/bold/font) screwed up?"
When you reach the beginning of the format change, the format change will be removed. Yes. Well, you get what you ordered.
"You get what you ordered" isn't a valid response when that is what I'm complaining about. :-/
Same argument as John's when he opposed equivalent changes in mathed. Nobody, not a single person! complained about this since 1.3.0 is out. I am really tempted to call this argument 'FUD'.
Mathed is fine. It is so different from lines of text that there is no reason to complain about differences in the way of editing. It works well for me.
Btw note that this 'magic key to remove formatting' does not have to be backspace. Could be any key you want. Heck, you could even deactivate it if having that feature makes you sick. It just happens to work like that in mathed for six years or so...
Also, inability to select half of the emphasized text plus some text outside the emphasis will be a problem. You are probably right that people rarely apply styles this way, but I often enough mark text this way in order to _remove_ it. It'll be interesting to see if that becomes a problem with the box-oriented approach.
As I said, 'non balanced selection' is implementable, but I don't see a point in implementing it before a real user actually complains.
I am a user, I have written a book in lyx. I am a bit worried. I'd like to try first though, before complaining. There might be positive surprises around. :-) So far, I haven't been able to.
Another thing I worry about is on-screen appearance. The text gets too full of boxes in 1.3 due to index entries, having visible boxes for markup might make reading harder. Still, I have to try before complaining on this one too.
I tried compiling lyx in order to test this, unfortunately the
resulting binary won't let me write anything with the keyboard, only
move around & paste.
Huh?
Compiling with the qt frontend failed with a syntax error in some file.
Compiling with xforms (ouch, clunky menus and non-antialiased text) gave me a src/lyx that don't want keyboard input. I can't type,
only move around and/or paste text.
I thought this just was the sort of things that might happen when trying 1.4cvs versions.
Helge Hafting
