On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > Dear Martin et al., > > do you need some more comments? Ok, here are mine :-) > > > Yes, box removing by <Backspace> is 'direct manipulation' according to > > this definition. > > > Nobody, not a single person! complained about this since 1.3.0 is out. > > I am really tempted to call this argument 'FUD'. > > Personally, I have no problem with this feature. Although I consider > myself a power-user, I have never noticed it in mathed. This also means > that it has never been an obstacle when writing some formula :-) > > HOWEVER... and now I will make you very angry ... I don't like the > CharStyle inset approach at all - at least in the way it is planned at > the moment. > > Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!!
You have to press C-e for emphasized anyway. Whether the result is realized by an inset or some other structure internally is irrelevant for the users. If the inset is visibly indistinguishable from the current display (which is at least for short stuff possible but requires Asger's three-box-drawing model for long) nobody will notice anyway. The only point to discuss IMO is whether there could/should be two physical cursor positions (boxes/mathed model) or just one (OOo/Word) Personally, having the two logicaly positions (just before some change/at the beginning of a change) is _the_ > But instead of starting a discussion on how to display insets in the > most comfortable way, we have to clarify the general concepts of > character styles first. IMHO there should be no fixed set of char > styles. Instead the user should be able to define his own styles and > change them later (similar to branches). This, of course, requires > additional dialogs, etc. etc. As a first step, reading them from the layout would be ok. Second step is to incorporate '.layout' snippets into the .lyx. Last step is to provide some gui... > So... do we really want such a mammoth project while LyX is broken at > each corner? This is pretty independent from the core fixes. > Last night, I worked four hours on a simple > insetcollapsable/insertert code merge just to find out that the > crashes I experienced also occur with the latest cvs :-( (The fact > that my 1Ghz 128MB computer spent more than half of the time on > compiling and swapping did not improve my bad mood). Hm yes. This is still bad and got suddenly worse again a few weeks ago... > Shouldn't we concentrate on bug fixing rather than starting new > projects? For those people willing and able to work on the core, probably yes. But I don't see a reason why the others should be stopped... Andre'
