Re: [Bug 339] Cursor up/down in nested insets
Juergen Vigna wrote: > On 22-Apr-2002 Eran Tromer wrote: > Now in this special case you don't have a row below the inset so it just > stays there. But IMO this is the right thing to do, so you just can go > on editing from that spot on. Ah. If it happens only this case then ignoring it is fine by me. :-) As for the more general "what should " do issue, please consider making the inset narrower by a few pixels, to give a better visual cue for the behavior. Won't hurt anyone with a sane number of nesting levels. A naive question of Bugzilla policy -- if this is an acknowledged by all as a problematic issue, why mark it WONTFIX as opposed to setting a far-away milestone or something? Definitely not 1.2.x stuff, but you do want it addressed *sometime* by *someone*, don't you? BTW, did you notice how LyX gets horribly slow when you create comments that are nested 15 levels deep? >>>I don't agree here to this is not a bug in my opinion and the behaviour >>>should not be changed, so as simple as that I will close the bug with a >>>WONTFIX. >> >>Uhm? I thought you admitted this one is a bug. > > No not really. I didn't admit it is a bug. I only admited that depending > on who uses it, the one could have different tastes. We obiously could just > create a dummy row below so when moving down we will go there, but I guess > this is really not worthwise the time. About this SPECIFIC subissue you said "It should go into the footnote not ERT though, I agree there." Regards, Eran Tromer
Re: [Bug 339] Cursor up/down in nested insets
Juergen Vigna wrote: > On 19-Apr-2002 Eran Tromer wrote: > >>(Note: the old screenshot was inaccurate, since I faked the cursor (it >>wasn't captured) just to show where I'm putting it logically. I've now >>updated the screenshow to be perfectly accurate.) >> >>The inset is one line below and 1 pixel to the right of the cursor. Are > > > Yes that 1 pixel makes the difference and for that single pixel (actually I > think there are 2 of them ;) you move to the right and not down. > >>so makes more sense than . > > Sorry but I don't agree with you here. I still think that a line is longer than a pixel, but I guess this is a matter of taste... If the effect on navigation is so dramatic, perhaps the visual indication can be made more obvious. Anyway, at least now we're in sync: the criterion is strictly visual, to the level of single pixels. Got it. Please allow me to try your patience and go back to the original example (ERT in footnote). >>Cursor at beginning of footnote (right before ERT): >> goes outside footnote, should enter ERT > > Again you are left of the ERT inset in the last row of the footnote if > pressing DOWN you shouldn't go right you should navigate down! There's nothing strictly below the cursor, so by your criterion should do nothing. Instead, it goes up and right. >>Cursor at beginning of ERT: >> goes outside footnote, should do nothing > > Why again! You are in the last row of the ERT and in the last of the > footnote Down should leave the ERT and the Footnote! Similarly -- this seems like some sort of logical behavior, with no visual justification. >>Cursor at beginning of ERT: >> goes outside footnote, should go to beginning of foonote > > Same as above you are in the first row of ERT and first of footnote! The thing directly above the cursor is the inside of the footnote inset, so I reckon the cursor should remain in the footnote. >>Cursor at end of footnote (right after ERT): >> goes outside footnote, should go into ERT Again -- by your criterion it should do nothing, not go up and right. > It should go into the footnote not > ERT though, I agree there. But that's so minor as to not be even worth > thinking about IMHO >>Minor indeed, but these sort of minor annoyances are a major part >>of the mythical "user experience". This is the sort of stuff that makes >>things "feel wrong". Not 1.2.0 stuff, but there should be a bug filed on >>this (unless it's fixed as a by-product of this one). > > I don't agree here to this is not a bug in my opinion and the behaviour > should not be changed, so as simple as that I will close the bug with a > WONTFIX. Uhm? I thought you admitted this one is a bug. Regards, Eran Tromer
Re: [Bug 339] Cursor up/down in nested insets
John Levon wrote: > On Fri, Apr 19, 2002 at 11:34:24PM +0300, Eran Tromer wrote: >>>>http://dl.tromer.org/nested.png >>> >>This prefers logical behavior to visual behavior, in contradiction to >>what you said earlier. Visually, the thing directly below the cursor is >>the inset, so if you want visual behavior then that's where >>should go. > > Sorry I'm afraid you're quite wrong. Imagine the cursor is of infinite > height. It wouldn't enter the footnote. So how can it possibly be > below it ? > > You argue for "visual" behaviour and then claim that "to the right and > down a little bit" means "down". That won't wash with me :) (Note: the old screenshot was inaccurate, since I faked the cursor (it wasn't captured) just to show where I'm putting it logically. I've now updated the screenshow to be perfectly accurate.) The inset is one line below and 1 pixel to the right of the cursor. Are you saying this single pixel makes the difference? That's not "to the right and a little bit down" but rather "down and a little bit to the right" so makes more sense than . Unless... Maybe by "inset" you refer to the label, while I refer to the editable region? Indeed the former is to the right and the latter is below, so that would explain things (both here and in the added-text case). If so, then I claim that my view makes more sense: when entering the inset the cursor goes into the editable region, so the "location" of the inset, for the purpose of cursor navigation, should be defined by its editable region (rather than its label). Thinking of the cursor as going "into" the label and thus being "teleported" into an "alternative universe" that happens to be drawn below the label is very strange indeed... > It should go into the footnote not > ERT though, I agree there. But that's so minor as to not be even worth > thinking about IMHO Minor indeed, but these sort of minor annoyances are a major part of the mythical "user experience". This is the sort of stuff that makes things "feel wrong". Not 1.2.0 stuff, but there should be a bug filed on this (unless it's fixed as a by-product of this one). Regards, Eran Tromer
Re: [Bug 339] Cursor up/down in nested insets
John Levon wrote: > On Fri, Apr 19, 2002 at 10:24:15PM +0300, Eran Tromer wrote: > > >>We're missing something. Here's what I see with current CVS: >> http://dl.tromer.org/nested.png >>Since the footnote inset is the only thing visually below the cursor, I >>would expect to go there. >> > > Down should move down to the next text row. Ad some text after the inset > and press down - it goes to where it should. Imagine how rritating your > behaviour would be in the general case. I'm on a row and I press down to > go to the next row, but it moves right instead !? This prefers logical behavior to visual behavior, in contradiction to what you said earlier. Visually, the thing directly below the cursor is the inset, so if you want visual behavior then that's where should go. Anyway, if what you write *is* the intended rule, then it fails when there's some text before the footnote -- pressing while in that text *does* go into the inset (in fact, it goes into the nested ERT inset, which is wrong any way you look at it). Regards, Eran Tromer
Re: [Bug 339] Cursor up/down in nested insets
Juergen Vigna wrote: > It's easier to discuss this on lyx-devel so I go for that way. > >>As before, in a new document create a footnote and within it an ERT inset. >>Don't enter any text. >> >>Cursor right before footnote: >> does nothing, should enter footnote > > Why you are at the left of the footnote and press DOWN why should the > cursor go right??? We're missing something. Here's what I see with current CVS: http://dl.tromer.org/nested.png Since the footnote inset is the only thing visually below the cursor, I would expect to go there. > I think moving the cursor visually is the on with least astonishment! Yup, that's what I'm saying too... Regards, Eran
Bug: cursor up/down in nested insets
Bug in current CVS: In a new document, create an ERT inset inside a footnote inset. Watch how and misbehave in each of the four possible cursor locations. By the way, should I report bugs here or directly into Bugzilla? Regards, Eran Tromer
Bug: \\ in author footnote
A bug in current CVS:
Create a footnote in an Author environment (class=article). Insert some
linebreaks in the footnote using Ctrl-Enter. View DVI. LaTeX chokes:
-
! Use of \@xfootnotemark doesn't match its definition.
\@ifnextchar ... \reserved@d =#1\def \reserved@a {
#2}\def \reserved@b
{#3}\f...
l.10 \maketitle
-
The problem is caused by the '\\' line separators in the footnote.
Editing the tex file to change all '\\' to '\newline' fixes this. If the
original footnote is placed outside the author environment then all is well.
Maybe it's a problem with the article class (I'm using RedHat's
tetex-1.0.7-46), but author footnotes are very common so LyX should work
around it anyway.
By the way, the parsing of latex output into error insets is way off in
this case.
Regards,
Eran Tromer
Bug: paragraph separation in AMS environments
Howdy, Many paragraph environments in the "Article (AMS)" layout do not respect the the paragraph separation setting. If you change the setting from Indent to Skip, the on-screen rendering still uses indented paragraphs. The affected environments are Theorem, Claim, Proof, etc. The TeX output is OK. Regards, Eran
Adjacent identical environments
Howdy, For many types of paragraph environments, LyX merges adjacet identical paragraph environments. This can be inappropriate, as in the following case: \layout Theorem My first theorem \layout Theorem My second theorem Horribly, in the LyX file format this is indistinguishable from \layout Theorem First paragraph of my only theorem \layout Theorem Second paragraph of my only theorem LyX always renders and exports as in the latter case. Can this be controlled? Regards, Eran
Crash on creation of math macro
Type "\newcommand{\foo}{\bar}", select it and press C-m.
LyX crashes.
Likewise if you replace "\bar" by other commands that have arguments,
like "\vec", or "\frac".
Regards,
Eran Tromer
Caption undo bug+crash
Here's an Undo bug in current CVS: Open a new document. Insert an Algorithm float. Write some text. Press to open a new paragraph above the text. Change the paragraph style to Caption, but don't write anything. Press . ---> the caption paragraph disappears Undo. ---> the algorithm float is killed, though the caption paragraph reappears (labeled "Senseless" because it is). I did a similar operation in a larger document, resulting in LyX shutting down with an emergency save. However, the emergency save contained only the content of the float, not the whole document -- major data loss. I can provide that document if needed. Regards, Eran
Re: [noreply@sourceforge.net: [ lyxbugs-Bugs-438548 ] Cursor placement when exiting mathmode]
Andre Poenitz wrote:
> You can bind this f***ing LFUN to whatever key you want - including
> C- - in your personal math.bind.
>
> _I_ cannot do so since it conflicts with the binding for
> LFUN_PROTECTED_SPACE.
Andre, I know this, and I know you're not happy with it either. I
mentioned my opinion for the benefit of that collective 'WE'.
Customization obiously isn't a proper solution if I need to change the
binding of LFUN_PROTECTED_SPACE.
> > and \vec (2 extra
> > keystrokes every time you past it).
>
> Since \vec{vv} is perfectly legal input (even if I don't know why someone
> would use it) it has to be a inset that might contain anything. Once it
> is one, it gets "insetish" behaviour. That's life.
>
> You could always define a macro \newcommand{\v}{\vec{v}} that behaves
> exactly like you want. But that's a personal preference and I don't see a
> compelling reason to sacrifies greater flexibility for such.
\vec{vv} is legal in the sense that LaTeX won't choke on it, but it
doesn't do what the user expects (because the arrow has a fixed width).
So in this case the extra flexibility is a nuisance, not a benefit. I
*want* to be restricted to do only things that make sense, especially if
the restriction makes them easier.
Hmmm. But \vec{\mathcal{V}} may make sense. OK, how about a compromise:
Allow arbitrary content in \vec insets, but lock it as an atomic unit
once the cursor exits the inset, just like you do for math ERT. This
gets rid of the extra keystrokes. The need to retype in case of change
is a minor concern since it *really* doesn't make sense to put more than
a few tokens in \vec.
Anyway, mathed should render \vec correctly (fixed width arrow, unlike
\overrightarrow).
Regards,
Eran Tromer
Member of the "STOP THE KEYSTROKE BLOAT" Campaign
Re: [noreply@sourceforge.net: [ lyxbugs-Bugs-438548 ] Cursor placement when exiting mathmode]
Andre Poenitz wrote: > > This bug is out of date. Space in a math inset does nothing > > now. > It's C-m nowadays. Why the two extra keystrokes? A mere is perfectly consistent and nonambiguous. Inserting a single mathmode letter used to take 4 keystrokes, with this change it's 6. The old mathed had things *really* right and tight in respect to keyboard actions -- it never seemed to require more than logically necessary. That made mathed a joy to use. Please don't lose that elegance. Ditto for LFUN MATH_SPACE (1 extra keystroke) and \vec (2 extra keystrokes every time you past it). BTW, \vec is broken in cvs -- try "M-v v". Regards, Eran Tromer Who is parading with a "STOP THE KEYSTROKE BLOAT" sign
Re: cursor movement
Andre Poenitz wrote: > > longer a concern and you can use a clearer implementation. Coming to > > think of it, you can completely do away with the integer 'floor' by > > moving some of the logic into the virtual methods -- something like the > > following (please excluse fictive class names): > > virtual array getSubinsetsBelow(MathInset* subinset); > > or possibly even: > > virtual MathInset* getSubinsetBelow(MathInset* subinset, > > CursorPosition pos); > > Now it looks pretty similar to > > bool MathInset::idxDown(int & idx, int & pos) > > which tries to move the cursor cell idx "down" (and adjust the position > "pos" in that cell), and returns success or failure... > > So, indeed, we are not too far away from each other now. Yup, it's better without the C-think of my original proposal. :-) But we still want to traverse the tree (to recall: upon we move up the tree until we reach a node that has a lower subinset, switch to that subinset, then go down always picking the highest descendant; in the process, whenever there are several choices with the same vertical positioning, choose visually according to horizontal cursor location). So we have three sets of queries (each consisting of an up+down couple): 1. "Where to go upon keypress?" == idxDown() 2. "Here's a subinset of yours. What is the highest subinset that's below it?" 3. "Here's a subinset of yours. What is the highest subinset that's below it and can be entered from outside?" The up-traversal uses Type 2 queries and the down-traversal uses Type 3 queries. They differ since you want to enter some insets in Type 2 but not in Type 3 (anything except script insets in this category?), but they're often identical so it's reasonable to implement them using the same function with a bool parameter. It's not *that* far from the 50 LOC goal, I think. Eran
Re: lyx file format changes
Herbert Voss wrote: > > Dekel Tsur wrote: > > > > On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: > > > > | > | Since we are continuously adding new features to LyX, reLyX stays behind, > > > > | > | so a lyx->latex->lyx cycle can loose information. > > > > > > as I said: from a users sight lyx->latex is only important > > > to find critical errors or to convert some stuff to whatelse > > > ever. > > > why should I do a lyx->latex->lyx cycle? > > > > You need it if you work on a document with a coauthor which doesn't have LyX. > > this is the only reason?? Last week I had to write a largish document in raw LaTeX for precisely this reason. Anyway, there's also this related scenario: you need to make some changes to your document on somebody else's computer. You don't have LyX 1.2.x installed, so you edit the exported LaTeX. Later back home, you struggle to spot all the changes and retype them into LyX. Regards, Eran Tromer
Re: cursor movement
Hi,
Andre Poenitz wrote:
> > Do you mean the same as what I proposed on 2001-07-24 (copy below)? If
> > not, what's the difference?
> You use information about the "parent" inset. I don't like that.
Sure, you can keep "who's below me" and "who's above me" pointers in
each inset using the same rules I proposed. But then you need to keep
them up to date. Compared to traversing the tree on per-need basis, this
has the following disadvantages:
* Takes memory memory: you need to save explicit pointers for any inset,
including leaves, and you can't use virtual methods to save memory
* Slower: any change requires updating the pointers throughout the
tree.
* More complex: additional code to make sure the pointers are kept up
to date. If you try to prune unnnecessary checks, you get even more
complexity.
Or am I missing the point?
> > Gotcha:
> > in $\frac{|xxx}{ \frac{y}{z} }$ we want to do
> >$\frac{xxx}{ \frac{|y}{z} }$ so the above logic works nicely.
> > However, in $\frac{xxx|}{ y^{s} }$ we want to do
> > $\frac{xxx}{ y^{s|} }$ rather than
> > $\frac{xxx}{ y^{|s| }$ even though the superscript is
> > than the 'y'. This is true in general for scripts. So, give the
> > script insets a floor value of +1000 (superscript) and -1000, and
> > tell topmost_subinset to ignore insets with these floor values.
>
> And that's a hack.
The different treatment or the proposed implementation of the
difference? The latter is a hack, yes -- I was trying to preserve memory
in the xcell array. If you use virtuals to implement it then that's no
longer a concern and you can use a clearer implementation. Coming to
think of it, you can completely do away with the integer 'floor' by
moving some of the logic into the virtual methods -- something like the
following (please excluse fictive class names):
virtual array getSubinsetsBelow(MathInset* subinset);
or possibly even:
virtual MathInset* getSubinsetBelow(MathInset* subinset,
CursorPosition pos);
Regards,
Eran
Re: cursor movement
Andre Poenitz wrote:
> I could create something intermediate: insets that "know" waht is "below"
> could say so (i.e. a numerator "knows" that there is something below, since
> they belong to the same fracinset).
Do you mean the same as what I proposed on 2001-07-24 (copy below)? If
not, what's the difference?
BTW, it's possible to save memory by using virtual methods in the inset
instead of actually storing the 'floor' values in the xcell array.
In the xcell array of math insets, assign an integer called 'floor' to
each cell, denoting relative vertical level: for instance, in \frac the
numerator is on floor 1 and the denominator on floor 0. This gives an
implicit tree structure on all the insets in the formula, with ordering
among the edges of each node (actually partially ordering, in case when
several subinsets are on the same floor). There remains only to traverse
this tree when needed:
Define the pseudofunctions (square brackets mark magic):
// Return next lowest sibling inset, if any:
MathInset inset_below(MathInset current, MathInset parent,
[horizontal cursor location])
{
if [all subinsets of parent have floor >= current.floor]
return null;
else {
floor_below = [ max{ x s.t. x < current->floor and
exists subinset S of 'parent' s.t.
x = S->floor } ];
candidates = [ subinsets of 'parent' that have
floor == floor_below ];
return [ element of 'candidates' that's horizontally
closest to the cursor ];
}
}
// Return topmost subinset:
MathInset topmost_subinset(MathInset current,
[horizontal cursor position] )
{
topmost_floor = [ max floor among all subinsets
of current];
candidates = [ subinsets of of 'parent' that have
floor == topmost_floor ];
return [ element of 'candidates' that's horizontally
closest to the cursor ];
}
Upon MathCursor action upon :
{
// Pop up insets until we can move down:
while ( (below = inset_below(current, parent, [something]) == null )
{
if (!pop()) [ do something smart ];
}
// Go to the topmost subsubsub...sub inset:
while ( (topmost = topmost_subinset(current, [something]) ) {
below = topmost;
}
[go to inset 'below']
}
Gotcha:
in $\frac{|xxx}{ \frac{y}{z} }$ we want to do
$\frac{xxx}{ \frac{|y}{z} }$ so the above logic works nicely.
However, in $\frac{xxx|}{ y^{s} }$ we want to do
$\frac{xxx}{ y^{s|} }$ rather than
$\frac{xxx}{ y^{|s| }$ even though the superscript is
than the 'y'. This is true in general for scripts. So, give the
script insets a floor value of +1000 (superscript) and -1000, and
tell topmost_subinset to ignore insets with these floor values.
Mathed buglist
Updated buglist attached. A few new ones at the end.
Also attached is a testcase for the last bug on the list.
Regards,
Eran
- When exiting the formula during selection, the anchor moves to the
left of the formula and there's no way to go back.
- You need two to get past \vec{v}, and all sort of other
insetish behavior.
- Strange cursor behavior in \vec insets:
In a new document, type C-m M-v v
- \vec{several-characters} doesn't work. \overrightarrow does.
- When the cursor is in a subscript (and either isn't at the end of
the subscript or there's no subsubscript), pressing should
try to *really* go down (to the next line, or denumerator, or
whatever). Currently it goes *up*. Ditto for superscripts.
:: Please see comment to Dekel's report on the same problem.
I've posted a proposal for a semi-logical meaning of . --Eran
- Formula inside tabular cell: red frame of cell inset and purple
frame of formula can overlap, causing leftovers when leaving
formula. To get an example, insert a 1x1 tabular into a new document,
enter the cell its cell and press
M-m ( M-f 1 (zoom=100, screenDPI=100)
- When selecting multiple cells in a array using the keyboard,
etc. should can move whole cell at a time -- no need to navigate
within cells.
- C-v always pastes into the end of the current math inset, instead of
the cursor location.
- Placement of cursor using mouse is seriously broken.
Example 1: large fractions.
Example 2: type into a new document:
"M-d x M-x footnote-insert"
Can't reach most places in the formula using mouse.
- Can't insert spaces using C-space or Maths Panel:
"LyXFunc::Dispatch: protected-space-insert [61] is disabled ad this
location"
- When there's math stuff in the clipboard, pressing "_"
puts the stuff in the created subscript.
- "\log_{s}" in displayed formula: subscript is shown as limit
(below the log) when the file is reloaded.
- Newly created ERT in mathed isn't red.
- at beginning of empty row in an array deletes the whole array.
- at the beginning of an empty row in an \eqnarray (displayed
multiline equation) should delete current row.
- Opening a macro in the numerator of a \frac causes incorrect
rendering (1) unless the file is scrolled to the very top
(2) only the first time; reopen file to reset state
Example: macro-draw.lyx (attached)
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\begin_preamble
\def\solitude{1}
\input{/home/eran/gold/def}
% \input{/home/erant/l12/def}
\usepackage{algorithm}
\usepackage{amsfonts}
\usepackage{amsmath}
\DeclareMathOperator{\Var}{Var}
\DeclareMathOperator{\median}{median}
\end_preamble
\options fullpage
\language english
\inputencoding auto
\fontscheme default
\graphics default
\float_placement !h
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4wide
\use_geometry 1
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
[scroll down until you don't see this line]
\layout Standard
a
\layout Standard
b
\layout Standard
c
\layout Standard
d
\layout Standard
e
\layout Standard
f
\layout Standard
g
\layout Standard
h
\layout Standard
i
\layout Standard
j
\layout Standard
[click on the macro]
\layout Standard
\begin_inset Formula $\frac{\binom{}{}}{}$
\end_inset
\layout Standard
j
\layout Standard
a
\layout Standard
b
\layout Standard
c
\layout Standard
d
\layout Standard
e
\layout Standard
f
\layout Standard
g
\layout Standard
h
\layout Standard
i
\layout Standard
j
\the_end
Mathed buglets
Howdy,
Some bugs in current cvs:
* Can't insert spaces using C-space or Maths Panel:
"LyXFunc::Dispatch: protected-space-insert [61] is disabled ad this
location"
* Strange cursor behavior in \vec insets:
In a new document, type C-m M-v v
* When there's math stuff in the clipboard, pressing "_"
puts the stuff in the created subscript.
* "\log_{s}" in displayed formula: subscript is shown as limit
(below the log) when the file is reloaded.
* Newly created ERT in mathed isn't red (which makes it merely ET :-)
This seems OK now:
// * Scripts are too large. $\log_2$ exceeds inset frame
(non-displayed).
By the way, any possibility of cut&paste beween normal text and mathed's
math text?
Regards,
Eran
Re: todo
Howdy,
Andre Poenitz wrote:
> Dekel and Eran (I suppose that are your given names, aren't they?)
Yup.
> Eran Tromer:
> * When exiting the formula during selection, the anchor moves to the
>left of the formula and there's no way to go back.
>
> :: Once you are out of mathed you are out. The cursor is completely dead and
> :: will be recreated from scratch once you re-enter the inset. I could either
> :: save anchor state (which is not exactly nice) or
The overshooting-the-end problem (described in my longish post about
anchors) is quite annoying.
Proposal:
Define a small MathSelectionState class that contains anchor location
information. When existing mathed during selection, before deleting the
MathCursor, call "MathSelectionState MathCursor::getSelectionState()"
and store the result somewhere outside mathed. If the cursor re-enters
the same formula during the same selection, initialize the new
MathCursor using the remembered object.
For extra effect, make the object opaque (the Memento design pattern).
This requires some additions to code outside mathed, but I can't see how
that's avoidable without adding nasty state to formulas.
> * \vec and friends have inset-ish behavior --
>
> :: Probably due to being insets ;-}
>
>you need two to
>get past \vec{v}. Bad because the vecor signs don't look as if its
>in the left-to-right "stream", and arguably not needed since you
>can't edit the vector sign (unlike scripts) and making a new one is
>very easy.
My text contains many \vec{v} thingies, now I need extra and
in all sort of situations. I think this is a very common case.
Also, $\vec{several-characters}$ doesn't produce the output you expect
--- the arrow has a fixed width.
\overrightarrow insets work in current cvs and handles the
multicharacter case very well, so think M-v v should be made to work as
before.
> ?? * When the cursor is in a subscript (and either isn't at the end of
> ?? the subscript or there's no subsubscript), pressing should
> ?? try to *really* go down (to the next line, or denumerator, or
> ?? whatever). Currently it goes *up*. Ditto for superscripts.
>
> :: Yes. It leaves one inset. Broken as designed. Changes this _logically_ is a
> :: mess. I could work around by introducing _physical_ movements, i.e. get the
> :: cursor position, increase it in small steps until SetPos() would go to
> :: another position. Take that position. I don't like it
Won't work: consider $\frac{_{|s}}{y}$.
Maybe there's a need for an explicit notion of vertical relation between
insets.
Here's a proposal. Rather complex, but logically clean.
In the xcell array of math insets, assign an integer called 'floor' to
each cell, denoting relative vertical level: for instance, in \frac the
numerator is on floor 1 and the denominator on floor 0. This gives an
implicit tree structure on all the insets in the formula, with ordering
among the edges of each node (actually partially ordering, in case when
several subinsets are on the same floor). There remains only to traverse
this tree when needed:
Define the pseudofunctions (square brackets mark magic):
// Return next lowest sibling inset, if any:
MathInset inset_below(MathInset current, MathInset parent,
[horizontal cursor location])
{
if [all subinsets of parent have floor >= current.floor]
return null;
else {
floor_below = [ max{ x s.t. x < current->floor and
exists subinset S of 'parent' s.t.
x = S->floor } ];
candidates = [ subinsets of 'parent' that have
floor == floor_below ];
return [ element of 'candidates' that's horizontally
closest to the cursor ];
}
}
// Return topmost subinset:
MathInset topmost_subinset(MathInset current,
[horizontal cursor position] )
{
topmost_floor = [ max floor among all subinsets
of current];
candidates = [ subinsets of of 'parent' that have
floor == topmost_floor ];
return [ element of 'candidates' that's horizontally
closest to the cursor ];
}
Upon MathCursor action upon :
{
// Pop up insets until we can move down:
while ( (below = inset_below(current, parent, [something]) == null )
{
if (!pop()) [ do something smart ];
}
// Go to the topmost subsubsub...sub inset:
while ( (topmost = topmost_subinset(current, [something]) ) {
below
Some mathed bugs
Hi,
A few more mathed bugs ("|" denotes cursor as usual) in current
1.2.0cvs:
* in $2^{x|}$ makes $x|$ (i.e., kills script inset). Very
annoying when changing scripts. Perhaps require a second
to delete the inset, as done for parenthesis?
* C-v always pastes into the end of the current math inset, instead of
the cursor location.
* Placement of cursor using mouse is seriously broken in fractions.
I've already reported this in the presence of foonotes, but it also
happens without them. Examples available upon request.
Note that currently working with complicated fractions is well nigh
impossible, since both mouse and keyboard cursor movement are broken
(see my earlier post, subject "mathed bugs").
Regards,
Eran
Re: mathed103.diff
Andre Poenitz wrote: > > BTW, do you intend to make do exactly what C-x does except for > > changing the clipboard? Many applications handle these slightly > > differently. MS Word 97, for instance, just clears the cells upon > > but sometimes removes them upon C-x (with the above rules). > > I think don't like that. There should be one or two easy-to-follow rules, > and there should not be more than twenty lines of dedicated code for such a > feature. I agree. > I think I will implement 'pasting over' as well as 'copy/swap' > rows/columns and then wait until people complain. I don't think you can count on that. People will manage with what they get (hell, they managed for many versions without any row/col operations), but that doesn't mean they're appy with it. There should be an intuitive GUI way to do this. We two options, one somewhat inconsistent and one somewhat complex but both within reason. Let's pick one. BTW, in the "somewhat complex" option: in regard to distinguishing cell selection from row selection when using the mouse, maybe it would suffice to add "Cut rows" and "Delete rows" options to the rightclick menu when the selection is full-width. For keyboard, I think my last proposal ( off the edge -> whole row selected) is very consistent with the spirit of insets even though it's cheating. Regards, Eran
Re: mathed103.diff
Hi, Andre Poenitz wrote: > > Am I missing something? In a matrix, current cvs lets me select only a > > rectangular set of whole cells (which is right IMO). > > Yes, you are looking at the First Amendment (due to Dekel's intervention) OK, that part is good. > > C-x should certainly not delete rows or columns unless all of their > > cells are selected. > > That's what I had in the original > > > In tabulars, cut and paste currently act like in a spreadsheet -- cells > > are never added or deleted, just changed. I think this is reasonable > > behavior. > So should I overwrite the region when I paste? Yes, just like a spreadsheet. > > On the other hand, there are times when it's useful to think of an array > > as a one-dimensional sequence of rows (or columns). Maybe we can > > distinguish selecting a 2D rectangular range of cells (which might > > indeed be full-width or full-height) from selection of a 1D range of > > rows (or columns). The two should be visually distinct (e.g., make the > > colored rectangle exceed the selected rows by a few pixels to the left > > and right). > > Tell me again when you need such behaviour _next_ time ;-) > > > To change 2D cell selection to 1D row/col selection using > > the keyboard: while selecting, try to move past the edge of the array. > > at the rightmost edge causes row selection, etc. To actually > > take the cursor outside the table a second is needed. As for the > > mouse, maybe use Shift-drag but I hope there's a better way. > > Too complex for my taste... It's actually quite useful. The point is that these 1D ranges have the usual cut and paste semantics (cut removes columns, paste inserts columns), unlike 2D ranges. This is useful in a number of common situations, such as: - Exchanging two columns -- simple cut&paste instead of moving one aside (where?!), moving one, retrieving other - Duplicating some columns - Removing several columns in an intuitive way I think this is really needed. If you don't want two selection modes (2D rectangle of cells vs. 1D range of rows/cols), the alternative is to specialcase 2D selection so that if the cell rectangle happens to be the full width of the array, C-x suddently removes rows and C-v suddenly inserts rows, ditto for columns. It's better than nothing, but there's definitely a consistency problem here. Here's what MS Word 97 does. Columns: behave like spreadsheets (overwrite), except: if you cut a full-height cell block, C-x removes columns. If the cursor is at the top row, C-v inserts new columns. Rows: if you select using the keyboard it behaves like spreadsheets, period. You can't insert or delete rows using C-x or C-v. However, using the mouse you can get 1D row selections (by clicking slightly to the left of the table). These selections are always removed upon C-x, and when you paste them they always insert new rows. If the cursor is N cells away from the bottom and you paste a block M>N cells high, M-N new rows are added. Ditto for columns. Yes, the behavior is completely different between rows and columns, so we have examples of both options I proposed... BTW, do you intend to make do exactly what C-x does except for changing the clipboard? Many applications handle these slightly differently. MS Word 97, for instance, just clears the cells upon but sometimes removes them upon C-x (with the above rules). > > Another thing: suppose you copy a range of array cells to the clipboard > > and then pase them when the cursor isn't in an array. It would be nice > > to automatically create an array of appropriate size and paste into it. > > Can be useful when you want to exchange two blocks of cells in an array > > and need to place a copy of one block somewhere while you move the > > other. > > I can imagine quite a few sensible behaviours in such a case, so I probably > would go for something that is used in tabulars or in any other > "well-known" application... MS Word 97 indeed creates a new table in this case. Regards, Eran
Re: mathed103.diff
Hi, Andre Poenitz wrote: > This is a (somewhat longer) shot at multicell selection and "old" anchor > behaviour. Selection within formula looks great now. Thanks! > I'd like to get some feedback whether selection with cursor keys works as > one would expect and verify that cursor positioning using the mouse and > single cell Cut&Paste work properly. I'll soon send a list of bugs, some of which relate to this. > In order to prepare multicell Cut&Paste: Suppose I have a 4x4 array, cursor > in the middle of cell (1,2), anchor in the middle of cell(3,1). Am I missing something? In a matrix, current cvs lets me select only a rectangular set of whole cells (which is right IMO). > - What should happen when pressing C-x (should I delete row 2 and clear > the part of row 1 right of the cursor and the part of row 3 left of the > anchor?) > > - What should happen if I place the cursor in the middle of cell 2,2 of > another array later and presse C-v there? C-x should certainly not delete rows or columns unless all of their cells are selected. In tabulars, cut and paste currently act like in a spreadsheet -- cells are never added or deleted, just changed. I think this is reasonable behavior. On the other hand, there are times when it's useful to think of an array as a one-dimensional sequence of rows (or columns). Maybe we can distinguish selecting a 2D rectangular range of cells (which might indeed be full-width or full-height) from selection of a 1D range of rows (or columns). The two should be visually distinct (e.g., make the colored rectangle exceed the selected rows by a few pixels to the left and right). To change 2D cell selection to 1D row/col selection using the keyboard: while selecting, try to move past the edge of the array. at the rightmost edge causes row selection, etc. To actually take the cursor outside the table a second is needed. As for the mouse, maybe use Shift-drag but I hope there's a better way. Is there currently an easy way to remove and add rows and columns (other than for rows)? If not, are there plans for a rightclick menu or something? Another thing: suppose you copy a range of array cells to the clipboard and then pase them when the cursor isn't in an array. It would be nice to automatically create an array of appropriate size and paste into it. Can be useful when you want to exchange two blocks of cells in an array and need to place a copy of one block somewhere while you move the other. Regards, Eran Tromer
mathed bugs
Here are a few mathed-related bugs in current 1.2.0cvs.
'|' denotes the cursor.
* Type into a new document: "M-d x M-x footnote-insert"
Can't reach most places in the formula using mouse.
* When exiting the formula during selection, the anchor moves to the
left of the formula and there's no way to go back.
* Scripts are too large. $\log_2$ exceeds inset frame (non-displayed).
* \vec and friends have inset-ish behavior -- you need two to
get past \vec{v}. Bad because the vecor signs don't look as if its
in the left-to-right "stream", and arguably not needed since you
can't edit the vector sign (unlike scripts) and making a new one is
very easy.
* When the cursor is in a subscript (and either isn't at the end of
the subscript or there's no subsubscript), pressing should
try to *really* go down (to the next line, or denumerator, or
whatever). Currently it goes *up*. Ditto for superscripts.
* When choosing to insert "\left\Vert \right\Vert" parenthesis using
the maths [sic] panel, a "\left( \right." is inserted instead.
* Pressing in $\left( |foo \right)$ causes
$\left( foo \right) |foo$" instead of $|foo$.
* in $\left( foo| \right)$ does nothing, should do $foo|$.
* Formula inside tabular cell: red frame of cell inset and purple
frame of formula can overlap, causing leftovers when leaving
formula. To get an example, insert a 1x1 tabular into a new document,
enter the cell its cell and press
M-m ( M-f 1
* When selecting multiple cells in a array using the keyboard,
etc. should can move whole cell at a time -- no need to navigate
within cells.
* When selecting, maybe give a visual indication of the "original"
anchor, when it differs from the "actual" one.
Regards,
Eran Tromer
Multiparagraph ERT
Should multiple paragraphs in ERT insets be allowed? What do they mean
anyway? Current cvs lets you create them ("C-l foo bar").
I think the right thing to do would be to disallow the concept of a
paragraph in ERT insets. Make both and C- insert a linebreak,
and ditto for LyXfuncs paste and primary-selection-paste. Keep the
linebreak marks -- they're useful for low-level stuff. If some really
wants a new paragraph he should just use \par or a completely blank line
because hey, he's talking to LaTeX.
Bug: multiparagraph ERTs are exported to .tex incorrectly (only the
first paragraph is written).
Regards,
Eran Tromer
\SpecialChar ~ in ERT
Hi, Another minor format compatibility issue with NO_LATEX: "\SpecialChar ~" in ERT is now ignored when reading .lyx files. Should do one of the these instead: * Import it as "~" * Close the ERT inset, insert a "\SpecialChar ~", open a new ERT inset. BTW, I agree that the ERT insets should (always/by default) be inlined. Some of my documents look *really* awful now. Regards, Eran Tromer
Re: math font changes while moving
Andre Poenitz wrote: > > > I propose the following. Upon cursor movement: > > If the new cursor location is between mathtext character then enable > > mathtext mode. > > How would you insert "normal math" between two math text chars then? Get in there and use C-m, of course. Just like you would if you were typing mathtext and wanted to insert some normal math. > > If the new cursor location is between non-mathtext thingies then disable > > mathtext mode. > > Otherwise: for and preserve current mathmode modality, > > for the rest disable mathtext mode. > > Above, "between X" also includes "at beginning of inset and before X" > > and "at end of inset and after X". > > Too complex for my taste. I don't want to look at "contextual information". I do see your point, but that's really the behavior I would expect as a user. Principle of Least Astonishment, etc. > I'd rather have either: > - leave it as it is, or It's currently horrible. into mathtext while in mathtextmode leaving mathtextmode?! > - C-m toggle math text mode, or Doesn't it already? > - make math text an proper inset with all pro's and con's The end result would be exactly like I described, except for the transition points (mathtext<->math) where you'll have to use extra "logical" cursor movements to decide whether you're in or out of the inset instead of relying on heuristics and C-m. Could a mathtext inset include nested math? If so, how do you export that? If not, typing mixed math+mathtext would be very unnatural. > > BTW, I noticed that lately it's possible to enter digits, hiphens etc. > > in mathtext -- that's a very good thing > > That was done in Italy. Hmmm. Last time I was in Italy I spent most of my time avoiding the suicidial drivers in Rome. Staying in my hotel room and coding indeed would have been, uhm, much safer. :-) Regards, Eran Tromer
Re: math font changes while moving
Hi, Andre Poenitz wrote: > Would it be acceptable or even desirable, if ordinary math cursor movements > (using the arrow keys) would _not_ leave math text mode anymore? I propose the following. Upon cursor movement: If the new cursor location is between mathtext character then enable mathtext mode. If the new cursor location is between non-mathtext thingies then disable mathtext mode. Otherwise: for and preserve current mathmode modality, for the rest disable mathtext mode. Above, "between X" also includes "at beginning of inset and before X" and "at end of inset and after X". Backspace should always preserve mathtext modality (both true and false), as opposed to above and to current cvs. BTW, I noticed that lately it's possible to enter digits, hiphens etc. in mathtext -- that's a very good thing Regards, Eran Tromer
Re: super/subscript insets
Andre Poenitz wrote:
> Could you accept the following:
Sounds good (the parts I grok, at least).
One gotcha:
LaTeX will choke on double scripts such as "A_{s}_{t}", so we can't have
two script insets in sequence. But then, what happens if you have
"A_{s}B_{t}"? and delete the B (e.g., in order to replace it by C)? The
intermediate state would be the illegal "A_{s}_{t}", but we must allow
it somehow. Possibilities:
* Allow the sequential script insets and display them similarly to
A_{s\,t}. Provide an informative error when exporting. This is the case
now, except the error is LaTeX's.
* Keep silent, export as "A_{s}{}_{t}". Problem: will be created
unintentionally and go unnoticed.
* In this special case, show an empty (blue) cell in front of the _{t},
and export as "A_{s}{}_{t}" (empty cell = "{}").
I think the last one would be best despite the unusual behavior.
Related issue:
In the situation (cursor = |)
A_{s}|
pressing '_' should take you to
A_{s|}
rather than 1.2.0cvs's
A_{|s}
or 1.1.6fix2's
A_{s}_{|}
But, in the situation
A|_{s}
pressing '_' should do the same as and take you to
A_{|s}
like 1.2.0cvs does.
Regards,
Eran Tromer
Re: super/subscript insets
Andre Poenitz wrote:
>
> > cursor position -- hard to explain/draw cursor-at-the-left-of-base vs.
> >.
>
> I am thinking about a special box around "current inset" - something not
> too visible - maybe with 'linen' colour. So one gets a hint where the
> cursor really is.
Interesting.
For "$foo{X_{s}}bar$", that would mean:
* cursor to the left of "X_{s}" -> whole formula highlighted
* cursor to the left of "X" -> just "X" highlighted
There's no case where "X_{s}" gets highlighed, so there's no indication
that it's treated as a unit. But you *could* play loose and not adhere
precisely to the inset structure: things would look OK if you highlight
"X_{s}" instead of just "X" in the second case. Doesn't solve the extra
cursor movement problem, though.
Pracital problem: can't rely on fine color distinctions, some people
have bad screens (laptops) or run in 256 color modes. On the other hand,
the highlight of the whole formula turns off and on when you enter an
inset, so a strong color difference may be nauseating. Can draw a frame
instead, or something of the sorts.
About semantics, BTW, what's wrong with the current (and TeX's) implicit
"the base is the first thing to the left"? While the representation is
not explicit, the semantics are well-defined and easy to retrieve and
that's the important part.
Regards,
Eran Tromer
Re: super/subscript insets
Alejandro Aguilar Sierra wrote:
>
> Another one against:
> - If the *script is part of the base inset, when you delete the base you
> delete the script too, which is not always what you want.
Well, in principle there's "delete the whole inset, both base and
scripts" and there's "delete the base (put an empty blue box), leave the
scripts alone". Just like in \sqrt, for instance.
Two problems with this distinction. First, cursor position -- hard to
explain/draw cursor-at-the-left-of-base vs.
cursor-to-the-left-of-whole-inset. Second, extra cursor movement needed
to support this, and that would get very annoying.
Related issue: it must remain easy to take $X_{long+subscript}$ and
change the 'X' to 'Y'.
I can't think of any interface that preserves script semantics without
UI bloat.
Regards,
Eran Tromer
Re: bugs: NO_LATEX and old lyx files
Lars Gullik Bjønnes wrote:
> use of tex-mode with insets inside is a harder nut to crack...
> (especially if we speck of insets that can themselves have tex-mode
> inside)
Maybe I'm missing something, but why won't the following work?
While parsing, keep a stack (or piggyback on an existing stack)
corresponding to inset nesting levels, with an "are we in tex-mode" flag
per level. When pushing due to new inset, set the flag of the new level
to false. Upon "\latex latex" etc, change the flag in the current level
only.
I think that's how it used to work, at least in effect. If you think
about fonts and footnotes ("\emph{foo \footnote{bar} baz}") and similar
cases, they seem to have those semantics too.
Since tex-mode wasn't properly terminated, there must be lots of
documents out there with this problem.
Regards,
Eran
Re: 666
Hi,
Lars Gullik Bjønnes wrote:
> I have done some changes to the compability code and it would be nice
> if those of you seeing problems you check and report again.
Yippy!
Both the label and \newline issues look fine now.
A couple of new ones. The attached ert4-{old,new}.lyx show these
problems:
* When latex mode is entered before a displayed formula and there's ERT
immediately afterwards, the current code forgets it was in latex mode
and parses the ERT as text.
* Something spooky with the handling of \sqrt. The new code both saves
and exports it incorrectly (forgets the 'sqrt', keeps the backlash).
Perhaps related to above.
But these are mere trifles, now that LyX starts with Juergen's new
development banner... :-)
Regards,
Eran Tromer
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\latex latex
\begin_inset Formula \[
\begin{array}{l}
\\
\\
\sqrt{r} \\
\\
\\
\end{array}
\]
\end_inset
\backslash
textsc{moose}
\the_end
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Formula \[
\begin{array}{l}
\\
\\
\{r} \\
\\
\\
\end{array}
\]
\end_inset
\backslash
textsc{moose}
\the_end
Couple of mathed bugs
Hi,
The attached .lyx file demonstrates two bugs in current 1.2.0cvs (sorry,
couldn't reduce it further):
1. You can't reach the numerator using mouse click, except for the few
rightmost digits. If you click on the middle or left of the numerator,
the cursor is placed elsewhere.
2. Select the rightmost digit of the numerator and press 'r' to replace
it. LyX crashes with the lovely backtrace seen below (my STL is RedHat's
gcc-2.96-85).
Regards,
Eran Tromer
(gdb) bt
#0 0x80080501 in ?? ()
#1 0x402ad648 in ?? ()
#2 0x402ad648 in ?? ()
#3 0x402ad648 in ?? ()
#4 0x402ad648 in ?? ()
#5 0x402ad648 in ?? ()
:
:
:
#10073 0x402ad648 in ?? ()
#10074 0x402ad648 in ?? ()
#10075 0x402ad648 in ?? ()
#10076 0x402ad648 in ?? ()
#10077 0x082ce277 in vector
>::insert (
this=0x840d9c0, __position=0x84061bc "\001", __n=3, __x=@0xbfffed4b)
at /usr/include/g++-3/stl_algobase.h:271
#10078 0x0818ef4d in MathArray::insert (this=0x840d9c0, pos=180, b=114,
t=LM_TC_VAR) at array.C:150
#10079 0x0817d01b in MathCursor::insert (this=0x840b8f0, c=114 'r',
t=LM_TC_VAR) at math_cursor.C:372
#10080 0x08178050 in InsetFormulaBase::localDispatch (this=0x840f820,
bv=0x83f56b8, action=LFUN_SELFINSERT, arg=@0xb230) at
formulabase.C:890
#10081 0x0817a639 in InsetFormula::localDispatch (this=0x840f820,
bv=0x83f56b8, action=LFUN_SELFINSERT, arg=@0xb230) at
formula.C:275
#10082 0x08103f65 in LyXFunc::Dispatch (this=0x83c9388, ac=86,
do_not_use_this_arg=@0xb290) at lyxfunc.C:756
#10083 0x08102379 in LyXFunc::processKeySym (this=0x83c9388, keysym=114,
state=0) at lyxfunc.C:348
#10084 0x08056ca7 in BufferView::Pimpl::workAreaKeyPress
(this=0x83f56d0,
keysym=114, state=0) at BufferView_pimpl.C:506
#10085 0x08283573 in SigC::ObjectSlot2_::callback (d=0x83f68f4, p1=114, p2=0)
at ../sigc++/object_slot.h:250
#10086 0x0829522d in SigC::Signal2 >::emit (this=0x83f5704, p1=@0xb38c, p2=@0xb388)
at ../sigc++/slot.h:456
#10087 0x0809960f in WorkArea::work_area_handler (ob=0x83f6200, event=9,
key=114, xev=0x400e64c0) at WorkArea.C:432
#10088 0x08098733 in C_WorkArea_work_area_handler (ob=0x83f6200,
event=9,
key=114, xev=0x400e64c0) at WorkArea.C:58
#10089 0x4008712b in ?? ()
#10090 0x400871d4 in ?? ()
#10091 0x4005b7e1 in ?? ()
#10092 0x4005bbd9 in ?? ()
#10093 0x4005bf16 in ?? ()
#10094 0x4005c5bd in ?? ()
#10095 0x4005cbb1 in ?? ()
#10096 0x4005cbf0 in ?? ()
#10097 0x081ed5f8 in GUIRunTime::runTime () at GUIRunTime.C:86
#10098 0x080f1320 in LyXGUI::runTime (this=0x8391278) at lyx_gui.C:314
#10099 0x080f33df in LyX::LyX (this=0xb870, argc=0xb8b0,
argv=0xb91c) at ../src/lyx_main.C:178
#10100 0x0812cc15 in main (argc=2, argv=0xb91c) at ../src/main.C:38
#10101 0x4029c177 in ?? ()
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Formula \begin{eqnarray*}
& & \frac{123456789012345678901234567890123456789012345678901234567890}{} \\
& & \end{eqnarray*}
\end_inset
\the_end
Re: [666] grey-boxes around inlined math
Lars Gullik Bjønnes wrote: > rather a problem with how we place the error boxes. You mean, "all over the place"? Even in the absence of floats or large insets, errors sometime show up a few pages too early, and sometimes *in the the wrong order*. Plus their dialog box doesn't give enough context to find out where they belong. I often export and run latex outside lyx to see what's going on. But I guess you know this. I've got examples if you need'em, though. Eran
bugs: NO_LATEX and old lyx files
A couple of issues with the way NO_LATEX parses old .lyx files:
1. Labels right after old-style ERT are incorrectly placed before the
ERT inset
(see attachments: loading ert+label-old.lyx in 1.2.0cvs results
ert+label-new.lyx).
2. Old-style ERT with '\newline' inside is parsed as two ERT insets
separated by a \newline, which seems wrong and ugly. There's a related
compatibility issue: previously the linebreak was ignored in export to
latex, but now it's exported as '\\'
(see attachments: ert+nl-old.{lyx,tex}, after load and save:
ert+nl-new.{lyx,tex}).
Regards,
Eran Tromer
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\latex latex
\backslash
ert
\begin_inset LatexCommand \label{label}
\end_inset
\latex default
Text
\the_end
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset LatexCommand \label{label}
\end_inset
\begin_inset ERT
collapsed false
\layout Standard
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color latex
\backslash
ert
\end_inset
Text
\the_end
ert+nl-old.tex
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\begin_preamble
\def\solitude{1}
\input{/home/eran/gold/def}
% \input{/home/erant/l99/def}
\usepackage{algorithm}
\usepackage{amsfonts}
\usepackage{amsmath}
\DeclareMathOperator{\Var}{Var}
\DeclareMathOperator{\Samples}{Samples}
\end_preamble
\options fullpage
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4wide
\use_geometry 1
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\latex latex
\backslash
ERT1
\newline
\backslash
ERT2
\the_end
ert+nl-new.tex
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\begin_preamble
\def\solitude{1}
\input{/home/eran/gold/def}
% \input{/home/erant/l99/def}
\usepackage{algorithm}
\usepackage{amsfonts}
\usepackage{amsmath}
\DeclareMathOperator{\Var}{Var}
\DeclareMathOperator{\Samples}{Samples}
\end_preamble
\options fullpage
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4wide
\use_geometry 1
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset ERT
collapsed false
\layout Standard
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color latex
\backslash
ERT1
\end_inset
\newline
\begin_inset ERT
collapsed false
\layout Standard
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color latex
\backslash
ERT2
\end_inset
\the_end
buffer-update race condition
Hi, When I open xdvi using 'buffer-view dvi', and later update the DVI file using 'buffer-update dvi' and immediately switch to xdvi, I sometime get the following message in the xdvi window: "DVI file corrupted" and next time I xdvi gets focus it terminates. Obviously there's a race condition between latex writing the .dvi file and xdvi reading it. A similar race condition happens with PostScript and presumably other formats. Just waiting until latex finishes works, but... Perhaps it would be possible to create the file under another name and rename it when done? Regards, Eran Tromer
Re: Format compatibility - algorithm insets
"Garst R. Reese" wrote: > Eran Tromer wrote: > Hint: There is no guarantee expressed or implied that you can read files > saved with 1.n.xx with 1.n-k.xx No guarantee assumed. I just thought it would be kind of nice to be able to read my own files on other computers. I don't necessarily have the permissions/diskspace/time to install the latest LyX on every computer I chance upon, you see. If the formats are nearly identical then it just might be possible to support transparent upwards compatibility. Otherwise, a converter utility and/or a "Save as version 1.1.x" function would be very useful. Regards, Eran Tromer
Format compatibility - algorithm insets
Hi, There's an issue with reading .lyx files saved by 1.2.0cvs using 1.1.6fix2. Algorithms saved by LyX 1.2.0cvs look like -- \begin_inset Float algorithm placement htbp wide false collapsed false \layout Standard Moose \end_inset -- LyX 1.1.6fix2 parses this as: (obtained by reading above and saving) -- \begin_inset Float algorithm placement htbp collapsed false \layout Standard Moosefalsecollapsed false \end_inset -- Maybe this happens with other floats as well. If it's not possible to add the new options in a way that's compatible with 1.1.6fix2, please at least make the upcoming 1.1.6fix3 properly ignore unknown options. Regards, Eran Tromer
bug: undo in formula
Open a new document and type: M-m [// You get "[]|" where | denotes cusror // (note wrong cursor position -- bug by itself!) x // You get "[x|]" S- y // You get "[y|]" C-z // Formula is now empty, which is incorrect. Tested on yesterday's 1.2.0cvs (sheesh does LyX take a long time to build!). Regards, Eran Tromer
mathed bug: backspace exits math text mode
Hi, Pressing backspace while in math text mode exits math text mode. It shouldn't. Tested in yesterday's 1.2.0cvs. Was OK in 1.1.6fix2. Regards, Eran Tromer
Re: patch: changing math space size
OK, this doesn't work. The 'sp' variable is a local static of InsetFormulaBase::localDispatch, so if you go to another formula it will remember the 'sp' variable of the previous one. This causes funny stuff. For example, if you deleted the previous forumula in the mean while, you get a crash (verified). LyX 1.1.6fix2 has exactly these problems. Was the code intentionally disabled due to this? (no comments, no way to know) I guess 'sp' (current space inset) should be made a member variable of InsetFormulaBase, and should be set to NULL when the formula gets focus. 'sp' should also be set to NULL whenever the space inset it points to is deleted (e.g., using mouse selection and menus), which currently it isn't. Yikes. I hope there's some way to get an "I'm being removed" notification from the space inset, or at least an "I'm changing" notification from the formula. I think I'll leave this to the pros after all. Eran Eran Tromer wrote: > > In current 1.2.0cvs it's no longer possible to increase the size of > spaces in mathed using > C- ... > > immediately after C- is interpreted as usual, i.e., a > mathcursor->pop() is executed. > > The attached patch seems to fix this. > > Regards, > Eran Tromer > > > Name: patch.diff >patch.diffType: Plain Text (text/plain) > Encoding: 7bit
patch: changing math space size
In current 1.2.0cvs it's no longer possible to increase the size of
spaces in mathed using
C- ...
immediately after C- is interpreted as usual, i.e., a
mathcursor->pop() is executed.
The attached patch seems to fix this.
Regards,
Eran Tromer
Index: lyx-devel/src/mathed/formulabase.C
===
RCS file: /cvs/lyx/lyx-devel/src/mathed/formulabase.C,v
retrieving revision 1.10
diff -c -r1.10 formulabase.C
*** lyx-devel/src/mathed/formulabase.C 2001/07/07 09:19:51 1.10
--- lyx-devel/src/mathed/formulabase.C 2001/07/08 03:12:49
***
*** 763,769
case LFUN_PROTECTEDSPACE:
bv->lockedInsetStoreUndo(Undo::INSERT);
! mathcursor->insert(new MathSpaceInset(1));
space_on = true;
updateLocal(bv);
break;
--- 763,770
case LFUN_PROTECTEDSPACE:
bv->lockedInsetStoreUndo(Undo::INSERT);
! sp = new MathSpaceInset(1); // remember current space inset
! mathcursor->insert(sp);
space_on = true;
updateLocal(bv);
break;
Re: crash: BadWindow (invalid Window parameter)
Dekel Tsur wrote: > On Mon, Jul 02, 2001 at 12:20:56AM +0200, Eran Tromer wrote: > > Every once in a while my LyX 1.1.6fix2 crashes with the following > > message: ... > Perhaps the crash is due to an incorrect version of your XForms library > (compiled for glibc 2.0 when your glibc is 2.1). Update: Using current LyX 1.2.0cvs and the "glibc2.1.92"" xforms 0.89-6 from http://www.vjet.demon.co.uk/xforms/, the problem apparently no longer occurs (no crash for ~3 days of use). Hard to tell which upgrade (lyx or xforms) fixed it, but if you think it's important I can try to find out. Regards, Eran Tromer
crash: Weird selections in mathed
Hi, The attached file shows two problems problems. It contains a single equation, consisting of a 2x1 array and then some math characters: [ [UP ] ] [ []NEXT ] [ [DOWN] ] Crash #1 (during Cut): Select using the mouse by dragging from the middle of "UP" to the *middle* of "NEXT". Press C-x. LyX crashes (see dump#1 below). Crash #2 (during Undo): Select using the mouse by dragging from the middle of "UP" to the *very end* of "NEXT". Note only "NEXT" is highlighted. Press C-x. Note only "NEXT" is deleted. Press C-z for undo. Note the crash (see dump#2 below). Both problems don't occur in 1.1.6fix2. Regards, Eran Tromer dump#1: #0 0x402ad801 in __kill () from /lib/i686/libc.so.6 #1 0x402ad5da in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x402aed82 in abort () at ../sysdeps/generic/abort.c:88 #3 0x0826d09f in lyx::abort () at abort.C:9 #4 0x080fcdc8 in error_handler (err_sig=11) at ../src/lyx_main.C:877 #5 #6 0x0818e8f0 in MathXArray::Metrics (this=0x83eb748, st=LM_ST_TEXT) at xarray.C:37 #7 0x081833c7 in MathInset::Metrics (this=0x8406448, st=LM_ST_TEXT) at math_inset.C:193 #8 0x0818171e in MathGridInset::Metrics (this=0x8406448, st=LM_ST_TEXT) at math_grid.C:83 #9 0x081862d5 in MathMatrixInset::Metrics (this=0x8406448, st=LM_ST_TEXT) at math_matrixinset.C:96 #10 0x08176918 in InsetFormulaBase::updateLocal (this=0x8408870, bv=0x83f4668) at formulabase.C:372 #11 0x0817912b in InsetFormulaBase::localDispatch (this=0x8408870, bv=0x83f4668, action=LFUN_CUT, arg=@0xb220) at formulabase.C:950 #12 0x0817a809 in InsetFormula::localDispatch (this=0x8408870, bv=0x83f4668, action=LFUN_CUT, arg=@0xb220) at formula.C:272 #13 0x0810439d in LyXFunc::Dispatch (this=0x83c7410, ac=21, do_not_use_this_arg=@0xb280) at lyxfunc.C:720 #14 0x08102689 in LyXFunc::processKeySym (this=0x83c7410, keysym=120, state=4) at lyxfunc.C:347 #15 0x08056c7b in BufferView::Pimpl::workAreaKeyPress (this=0x83f4680, keysym=120, state=4) at BufferView_pimpl.C:503 #16 0x08281ac3 in SigC::ObjectSlot2_::callback (d=0x83f5894, p1=120, p2=4) at ../sigc++/object_slot.h:250 #17 0x0829377d in SigC::Signal2 >::emit (this=0x83f46b4, p1=@0xb37c, p2=@0xb378) at ../sigc++/slot.h:456 #18 0x08099a0b in WorkArea::work_area_handler (ob=0x83f51a0, event=9, key=24, xev=0x400e64c0) at WorkArea.C:432 #19 0x08098b2f in C_WorkArea_work_area_handler (ob=0x83f51a0, event=9, key=24, xev=0x400e64c0) at WorkArea.C:58 #20 0x4008712b in fl_handle_it () from /usr/X11R6/lib/libforms.so.0.89 #21 0x400871d4 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89 #22 0x4005b7e1 in fl_keyboard () from /usr/X11R6/lib/libforms.so.0.89 #23 0x4005bbd9 in fl_handle_form () from /usr/X11R6/lib/libforms.so.0.89 #24 0x4005bf16 in do_keyboard () from /usr/X11R6/lib/libforms.so.0.89 #25 0x4005c5bd in do_interaction_step () from /usr/X11R6/lib/libforms.so.0.89 #26 0x4005cbb1 in fl_treat_interaction_events () from /usr/X11R6/lib/libforms.so.0.89 #27 0x4005cbf0 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89 #28 0x081ebb14 in GUIRunTime::runTime () at GUIRunTime.C:86 #29 0x080f1234 in LyXGUI::runTime (this=0x838fa78) at lyx_gui.C:314 #30 0x080f32f3 in LyX::LyX (this=0xb860, argc=0xb8a0, argv=0xb90c) at ../src/lyx_main.C:174 #31 0x0812d099 in main (argc=2, argv=0xb90c) at ../src/main.C:38 dump#2: #0 0x402ad801 in __kill () from /lib/i686/libc.so.6 #1 0x402ad5da in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x402aed82 in abort () at ../sysdeps/generic/abort.c:88 #3 0x0826d09f in lyx::abort () at abort.C:9 #4 0x080fcdc8 in error_handler (err_sig=11) at ../src/lyx_main.C:877 #5 #6 0x0818dcf2 in MathArray::MathArray (this=0x83eb798, array=@0x83eb748) at array.C:35 #7 0x082c665e in MathXArray * __uninitialized_copy_aux ( __first=0x83eb748, __last=0x83eb76c, __result=0x83eb798) at /usr/include/g++-3/stl_construct.h:48 #8 0x081861d3 in MathMatrixInset::clone (this=0x8406448) at /usr/include/g++-3/stl_uninitialized.h:152 #9 0x08176355 in InsetFormulaBase::InsetFormulaBase (this=0x840e8b0, f=@0x8408870) at formulabase.C:213 #10 0x0817972a in InsetFormula::clone (this=0x8408870) at formula.C:76 #11 0x0812f293 in Paragraph::Paragraph (this=0x840e888, lp=@0x8401568) at paragraph.C:136 #12 0x08165076 in LyXText::createUndo (this=0x8406828, buf=0x84062a8, kind=DELETE, before=0x0, behind=0x0) at text2.C:2761 #13 0x08164a93 in LyXText::textUndo (this=0x8406828, bview=0x83f4668) at text2.C:2544 #14 0x08052dbf in BufferView::menuUndo (this=0x83f4668) at BufferView2.C:230 #15 0x081040ca in LyXFunc::Dispatch (this=0x83c7410, ac=16, do_not_use_this_arg=@0xb280) at ly
Re: Keyboard selection in mathed
Hi, "Asger K. Alstrup Nielsen" wrote: [snip] > Let me try to explain the more strategic parts of the LyX development > effort at this moment: [snip] Thanks for the explanations! This really cleared things up for me, especially about what you were all up to in Italy... Now where's LDN when you really need it? I wasn't expecting an immediate rewrite of MathCusror, of course. It simply seemed like a good suggestion to file. > > * S- and S- (with the nested behavior of ,) > > * S-C- and S-C- > > and possibly others. > > Yes, those would be nice. However, they should have low priority at the > moment. Specifically, S- and S- would be quite useful *because* of the current anchor behavior. Most of the time I try to mark until the end of an equation I overshoot on first attempt (because cursor "velocity" is hard to predict when it jumps over insets), which is quite annoying. I see your point about priorities, though. > Regarding the undo information, this is also a mayor task > that takes days to implement, and Juergen is still fighting hard to do > this. Please help by testing his patches as much as you can. > It seems Andre is > continuing the good work, and focusing on fixing all the problems that > appear. So hopefully, a stable mathed is not too far away. Please keep > testing and providing fast feedback for Andre in this critical phase. Is the lyx-devel cvs root kept up to date about these, or are they hiding in a branch? Regards, Eran Tromer
Math text export
Hi,
Me again, with an issue in the current 1.2.0cvs.
"Math text" (stuff inserted using M-m m in mathed) is saved as
--
\begin_inset Formula
\(\textrm{m}\textrm{o}\textrm{o}\textrm{s}\textrm{e}\)
\end_inset
--
and exported as
--
\(\textrm{m}\textrm{o}\textrm{o}\textrm{s}\textrm{e}\)
--
LyX 1.1.6fix2 saves the same file as
--
\begin_inset Formula \( \textrm{moose} \)
\end_inset
--
and exports it as
--
\( \textrm{moose} \)
--
which seems like a much better idea.
I hope this isn't intentional...
Regards,
Eran Tromer
Re: Crash and rendering bug in tabular row
Addenum: Attached is a further simplified case that still exhibits the crash (but not the rendering problem). The 3x3 table is now empty, but deleting its first row causes a crash. BTW, note that in my previous file there was an empty formula on the bottom line. Regards, Eran Tromer Eran Tromer wrote: > > Hi, > > The attached .lyx file demonstrates two problems. It contains a LyX > macro definition and a single 3x3 tabular that's all-empty except for > the middle cell which contains an instance of the macro. : > Second, if you try to delete the first row (using "Delete Row" from the > Tabular Layout rightclick menu), LyX dumps core. Backtrace below. : #LyX 1.2 created this file. For more info see http://www.lyx.org/ \lyxformat 218 \textclass article \options fullpage \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize 11 \spacing single \papersize Default \paperpackage a4wide \use_geometry 1 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation skip \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \end_inset \the_end
Crash and rendering bug in tabular row
Hi,
The attached .lyx file demonstrates two problems. It contains a LyX
macro definition and a single 3x3 tabular that's all-empty except for
the middle cell which contains an instance of the macro.
First, when displayed in LyX the tabular is allocated too little height
so the last row is clipped off. It's probably a problem in calculating
the height of the macro instance in the second row.
Second, if you try to delete the first row (using "Delete Row" from the
Tabular Layout rightclick menu), LyX dumps core. Backtrace below.
The attached file was created purely using the current LyX 1.2.0cvs.
Backtrace:
--
#0 0x402ad801 in __kill () from /lib/i686/libc.so.6
#1 0x402ad5da in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x402aed82 in abort () at ../sysdeps/generic/abort.c:88
#3 0x0826d09f in lyx::abort () at abort.C:9
#4 0x081d3ffe in InsetText::getLyXText (this=0x88fd850, lbv=0x83f4680,
recursive=false) at
../../src/support/LAssert.h:24
#5 0x081cfac9 in InsetText::update (this=0x88fd850, bv=0x83f4680,
font=@0xb450,
reinit=false) at insettext.C:426
#6 0x081c92c4 in InsetTabular::calculate_dimensions_of_cells
(this=0x88fcc80, bv=0x83f4680,
font=@0xb450, reinit=false) at insettabular.C:1155
#7 0x081c6c1f in InsetTabular::update (this=0x88fcc80, bv=0x83f4680,
font=@0xb450,
reinit=false) at insettabular.C:469
#8 0x081527aa in LyXText::setHeightOfRow (this=0x88f7d48,
bview=0x83f4680,
row_ptr=0x88fcea0) at text.C:1220
#9 0x08153b6b in LyXText::breakAgain (this=0x88f7d48, bview=0x83f4680,
row=0x88fcea0)
at text.C:1543
#10 0x08162fa2 in LyXText::checkParagraph (this=0x88f7d48,
bview=0x83f4680, par=0x88ff1a0,
pos=0) at text2.C:2034
#11 0x08163283 in LyXText::updateInset (this=0x88f7d48, bview=0x83f4680,
inset=0x88fcc80)
at text2.C:2096
#12 0x0806684d in BufferView::Pimpl::updateInset (this=0x83f4698,
inset=0x88fcc80,
mark_dirty=true) at BufferView_pimpl.C:3419
#13 0x080540d5 in BufferView::updateInset (this=0x83f4680,
inset=0x88fcc80, mark_dirty=true)
at BufferView2.C:497
#14 0x081c6e76 in InsetTabular::updateLocal (this=0x88fcc80,
bv=0x83f4680, what=INIT,
mark_dirty=true) at insettabular.C:539
#15 0x081caa88 in InsetTabular::tabularFeatures (this=0x88fcc80,
bv=0x83f4680,
feature=DELETE_ROW, value=@0xb680) at insettabular.C:1645
#16 0x08238c45 in FormTabular::input (this=0x83eda58, ob=0x863aa40) at
FormTabular.C:522
#17 0x08266f10 in FormBaseDeprecated::InputCB (ob=0x863aa40, data=0)
at FormBaseDeprecated.C:186
#18 0x0826689d in C_FormBaseDeprecatedInputCB (ob=0x863aa40, d=0) at
FormBaseDeprecated.C:46
#19 0x4004d048 in fl_object_qread () from
/usr/X11R6/lib/libforms.so.0.89
#20 0x4005cbe2 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#21 0x081ebb14 in GUIRunTime::runTime () at GUIRunTime.C:86
#22 0x080f1234 in LyXGUI::runTime (this=0x838fa78) at lyx_gui.C:314
#23 0x080f32f3 in LyX::LyX (this=0xb870, argc=0xb8b0,
argv=0xb91c)
at ../src/lyx_main.C:174
#24 0x0812d099 in main (argc=2, argv=0xb91c) at ../src/main.C:38
#25 0x4029c177 in __libc_start_main (main=0x812cf40 , argc=2,
ubp_av=0xb91c,
init=0x804f4c8 <_init>, fini=0x8304300 <_fini>, rtld_fini=0x4000e184
<_dl_fini>,
------
Regards,
Eran Tromer
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\begin_preamble
\def\solitude{1}
\input{/home/eran/gold/def}
% \input{/home/erant/l99/def}
% \usepackage{algorithm}
\end_preamble
\options fullpage
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4wide
\use_geometry 1
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset FormulaMacro
\newcommand{\ei}{\frac{1}{\varepsilon }}
\end_inset
\layout Standard
\begin_inset Tabular
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\begin_inset Formula \(\ei \)
\end_inset
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\begin_inset Text
\layout Standard
\begin_inset Formula \(\)
\end_inset
\end_inset
\begin_inset Text
\layout Standard
\end_inset
\end_inset
\layout Standard
f
\the_end
Re: [PATCH] first minibuffer completion thing
Hi, Lars Gullik Bjønnes wrote: > | > No not really but you need a separate shortcut to jump to the popup. > | > > | > And since this is gui... to use the mouse to move to the popup should > | > be ok. > | Physically reaching over from the keyboard to the mouse and back is very > | slow (even if we don't notice it much). When I use LyX I usually never > | use the mouse, except for some hairy cases of navigation in mathed or > | tabulars. If the whole point is to speed things up, bringing in the > | mouse doesn't make much sense to me. > You read the note about "you need a separate shortcut to jump to the > popup"? Oh. I misconstrued your second sentance as implying the shortcut isn't needed. Sorry, I guess I'm just edgy about the cavalier dismissal of GUI keyboard shortcuts which is so prominent in the Unix world (and isn't *that* ironic!). LyX certainly doesn't suffer from that one, as my own comment shows. > | How about C- and C- for entering/navigating the completion > | menu? > > That is another option... but the pop up does not (or should not) have > focus, until you move explitly to the popup by mouse or key. Praise to that. By the way, the autocompletion popup in the File Open dialog of Windows 2000 behaves like you said, and is good inspiration in general (if not the source of the idea...). Regards, Eran Tromer
Keyboard selection in mathed
Howdy,
Posting a copy of my new feature request #438563 for discussion:
Keyboard selection in mathed using Shift-movement should act as
similarly as possible to normal movement inside mathed. Specifically,
the following should be supported:
* S- and S- (with the nested behavior of ,)
* S-C- and S-C-
and possibly others.
A related issue: when holding down Shift and pressing until the
cursor leaves the math inset, pressing should undo the last
. Typical scenario: you want to select to to the end of an
equation (or nearly so), but overshoot. Currently (1.2.0cvs), the above
sequence causes a zero-sized selection to the right of the inset, with
no way to recover the original selection. The same happens when you
overshoot the end of a parenthesis and try to go back. In short, I
don't like the following part of MathCursor::Right():
--
result = array().next(cursor_);
if (!result && pop()) {
anchor_ = cursor_;
result = array().next(cursor_);
}
--
I propose the following semantics:
When Shift-movement selection is initiated in mathed, record the anchor
(starting position) and *keep it fixed* as long as the Shift key is
down. Let the cursor move normally using all the usual navigation keys,
except for the following: each inset that is not an ancestor of the one
where the anchor resides should be treated atomically, i.e., like a
single character (this is the current behavior). This maintains the
invariant that the inset where the cursor resides is an
ancestor-or-same-as of the inset where the anchor resides. At any
moment, the current selection is defined as follows:
* If the cursor is in the same inset as the anchor, you know what to do.
* Otherwise, the selection is defined at the inset where the cursor
resides, and contains everything from the cursor to the (child) inset
which contains the anchor, inclusive.
Does this sound reasonable?
This also seems like the right behavior in general wherever nesting is
involved, such as tabulars.
By the way, in current 1.2.0cvs: when you start selection from within a
math inset inside a tabular you can exit the tabular cell during
selection (using mathed's selection semantics), but if you start it from
normal text inside a cell you can't exit the cell.
And finally: Should mouse selection should have the same anchor&cursor
semantics as keyboard semantics? Currently it doesnt. Example:
typeC-m x M-m ( y to get x([])y
then S- to select the parenthesis
It's impossible to get the same selection using the mouse.
Regards,
Eran Tromer
Re: [PATCH] first minibuffer completion thing
Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > | On Wed, Jul 04, 2001 at 02:56:27PM +0200, Lars Gullik Bjønnes wrote: > | > should still work on the history. > | > should try to exec what is in the minibuffer now. > | > will try again to complete what you already have > | > should just be added to what already is in the > | > minibuffer. > | > | in this case it will be impossible to use the menu from the keyboard. This will > | apply to any popup you care to mention. > > No not really but you need a separate shortcut to jump to the popup. > > And since this is gui... to use the mouse to move to the popup should > be ok. Physically reaching over from the keyboard to the mouse and back is very slow (even if we don't notice it much). When I use LyX I usually never use the mouse, except for some hairy cases of navigation in mathed or tabulars. If the whole point is to speed things up, bringing in the mouse doesn't make much sense to me. How about C- and C- for entering/navigating the completion menu? Regards, Eran Tromer
Re: mathed bug: double subscript
Herbert Voss wrote:
>
> Eran Tromer wrote:
> >
> > It's possible to create a double subscript by typing the following in
> > mathed:
> > x_1y_2
>
> the y is a typo???
No it's not. I'm writing
x y
1 2
and then I delete the 'y'.
Regards,
Eran Tromer
mathed bug: double subscript
Hello,
It's possible to create a double subscript by typing the following in
mathed:
x_1y_2
The generated latex code contains "x_{1}_{2}", and so does the saved
.lyx file.
The bug exists in the current 1.2.0cvs, and the double subscript is
displayed just like "x_{12}" but with a some space between the digits.
It also exists in 1.1.6fix2 and earlier, where the two subscript are
rendered on top of each other.
Regards,
Eran Tromer
crash: BadWindow (invalid Window parameter)
Howdy, Every once in a while my LyX 1.1.6fix2 crashes with the following message: --- lyx: Attempting to save document newfile1.lyx as... /home/eran/newfile1.lyx.emergency Save seems successful. Phew. BadWindow (invalid Window parameter) --- and the following stack: --- (gdb) bt #0 0x40144801 in __kill () from /lib/i686/libc.so.6 #1 0x401445da in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40145d82 in abort () at ../sysdeps/generic/abort.c:88 #3 0x081d348b in lyx::abort () at abort.C:9 #4 0x080b51fe in LyX_XErrHandler (display=0x838cc38, xeev=0xb4b8) at lyx_gui.C:95 #5 0x402a2d87 in _XError () from /usr/X11R6/lib/libX11.so.6 #6 0x402a13f3 in _XReply () from /usr/X11R6/lib/libX11.so.6 #7 0x40297a3e in XQueryPointer () from /usr/X11R6/lib/libX11.so.6 #8 0x400befdd in fl_get_win_mouse () from /usr/X11R6/lib/libforms.so.0.88 #9 0x400884a8 in fl_compress_motion () from /usr/X11R6/lib/libforms.so.0.88 #10 0x400884fe in fl_compress_event () from /usr/X11R6/lib/libforms.so.0.88 #11 0x40096383 in get_next_event () from /usr/X11R6/lib/libforms.so.0.88 #12 0x40095213 in do_interaction_step () from /usr/X11R6/lib/libforms.so.0.88 #13 0x40095b5d in fl_treat_interaction_events () from /usr/X11R6/lib/libforms.so.0.88 #14 0x40095b9e in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.88 #15 0x0818df25 in GUIRunTime::runTime () at GUIRunTime.C:79 #16 0x080b6787 in LyXGUI::runTime (this=0x8389940) at lyx_gui.C:419 #17 0x080b83cd in LyX::LyX (this=0xb8ac, argc=0xb8f8, argv=0xb95c) at ../src/lyx_main.C:168 #18 0x080e872b in main (argc=2, argv=0xb95c) at ../src/main.C:40 #19 0x40133177 in __libc_start_main (main=0x80e8610 , argc=2, ubp_av=0xb95c, init=0x804eb70 <_init>, fini=0x825876c <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xb954) at ../sysdeps/generic/libc-start.c:129 --- Frequency: about every couple of hours of active work. I'm not able to reproduce it deterministically. It's not related to any specific document. I suspect it's related to X window switching, since I often discover that LyX has crashed when I have another window focused and then try to return to the LyX window (the above backtrace is from such an incident). My X server is StarNet X-Win32 (various versions, e.g., v5.1.2). LyX runs on a RedHat 7.1 box, and the crash happens with both XForms 0.88 and 0.89. There are two issues here 1. The X error, which may be LyX's fault -- I've never had other apps crash like this. 2. The fatalistic approach taken by LyX_XErrHandler -- it may be possible to ignore some errors or even actively recover. Regards, Eran Tromer
Selection from within double space
I found a bug in LyX 1.1.6fix2 (installed on RedHat7.1 using Sylvan's RPMs). To reproduce, open a new document. Type: a b Place the cursor after the 'a' and press SPACE to obtain (| denotes cursor): a | b Press Shift-Home to select from beginning of line. You can already tell that something's wrong, since you obtain (^ denotes selection): a b| ^ Now press Ctrl-X. LyX dumps core. Here's the top of the backtrace: - #0 0x40144801 in __kill () from /lib/i686/libc.so.6 #1 0x401445da in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40145d82 in abort () at ../sysdeps/generic/abort.c:88 #3 0x081d348b in lyx::abort () at abort.C:9 #4 0x080bd542 in error_handler (err_sig=11) at ../src/lyx_main.C:873 #5 #6 Row::par (this=0x1f) at lyxrow.C:34 #7 0x08121736 in LyXText::RedoParagraphs (this=0x84005e8, bview=0x83af7d0, cur=@0x84006b8, endpar=0x0) at text2.C:1050 #8 0x081268de in LyXText::CutSelection (this=0x84005e8, bview=0x83af7d0, doclear=true) at text2.C:2273 #9 0x08054507 in BufferView::cut (this=0x83af7d0) at BufferView2.C:590 #10 0x080c7ad1 in LyXFunc::Dispatch (this=0x83b11f0, ac=22, do_not_use_this_arg=@0xb2a0) at lyxfunc.C:962 #11 0x080c4b9f in LyXFunc::processKeySym (this=0x83b11f0, keysym=120, state=4) at lyxfunc.C:308 : : ----- Regards, Eran Tromer
Re: Selection not working in 1.1.6pre3
The fault lay in a spurious "\bind_file menus.bind" line in my ~/lyx/preferences. I can't for the life of me imagine where that came from. Eran Tromer "Garst R. Reese" wrote: > > Eran Tromer wrote: > > > > Hello, > > > > In LyX 1.1.6pre3, selection using Shift+arrows doesn't work -- when > > holding Shift and pressing an arrow key, nothing happens (the cursor > > doesn't move). > > > > Using RPM from ftp://ftp.sylvan.com/pub/lyx/, on a Linux box vaguely > > based on RedHat 7.0. Happens using either XFree 4.0.1 or X-Win32 5.1.1b > > as X server. > > > > LyX 1.1.5fix2 and earlier (installed from RPM) work fine on the same > > box. > > > > Is this a bug or a surprising change in the default UI? > > > > Eran Tromer > Try reconfigure. Works here. > Garst
Selection not working in 1.1.6pre3
Hello, In LyX 1.1.6pre3, selection using Shift+arrows doesn't work -- when holding Shift and pressing an arrow key, nothing happens (the cursor doesn't move). Using RPM from ftp://ftp.sylvan.com/pub/lyx/, on a Linux box vaguely based on RedHat 7.0. Happens using either XFree 4.0.1 or X-Win32 5.1.1b as X server. LyX 1.1.5fix2 and earlier (installed from RPM) work fine on the same box. Is this a bug or a surprising change in the default UI? Eran Tromer
Re: Bitmapped T1 fonts
Hello,
Jean-Marc Lasgouttes wrote:
> Sorry, it should have been "ae" fonts. Point your browser here for an
> explanation:
> ftp://ftp.loria.fr/pub/unix/tex/ctan/help/Catalogue/entries/ae.html
The AE fonts are included in RedHat 6.2 and Mandrake 7.0. They seem to
work fine (at least for my current paper...), and are properly exported
as Type 1. All it takes is adding:
\usepackage{ae}
\usepackage{aecompl}
(the latter provides bitmapped versions of a few missing characters).
Regards,
Eran Tromer
Re: Bitmapped T1 fonts
Jean-Marc Lasgouttes wrote: > Note however that it is a matter of setting up correctly the latex > system. While LyX should try to help, we do not want to change it just > because of the choice redhat has done... Would aec fonts solve the > problem? I must confess that I have no idea what are the aec fonts. I searched for public EC fonts and found none. If this is caused by lack of availability (rather than search skills) then I'd expect the problem not to be generally resolved very soon. BTW, the latest Mandrake doesn't have Type 1 EC fonts either. Regards, Eran Tromer
Re: Bitmapped T1 fonts
Hello,
Jean-Marc Lasgouttes wrote:
> The right solution is for us to have a correct handling of PDF, I
> guess. And, of course, we should have a way to change all the lyxrc
> options via GUI. So much to do...
The issue applies to PostScript as well. On one hand, some printers have
effective resolutions higher than 600dpi. On the other hand, I'd expect
lower-resolution devices to render outline fonts better than scaled-down
600dpi bitmapped fonts. Not to mention that the .ps file is typically
smaller for Type 1.
Regards,
Eran Tromer
Bitmapped T1 fonts
By default LyX uses the T1 font encoding, and therefore the EC fonts.
This is caused by the following line included in the .tex output:
\usepackage[T1]{fontenc}
Some LaTeX distributions (e.g., RedHat Linux 6.2) contain Type 1 fonts
for Computer Modern, but not for EC. Therefore, on these distributions
both dvips and pdflatex use bitmapped fonts for normal text. This
reduces rendering quality on high-resolution devices, and produces
horrible PDF files.
The problem can be solved by manually removing the above line after
export, or by adding the following line to lyxrc:
\font_encoding default
Of course, the font map needs to be properly configured (it is on
RedHat).
I was unable to find any reference to this issue in the LyX
documentation, and not being a TeX expert it took me quite a while to
figure this out.
I don't think the T1 encoding should be disabled by default, since it
solves the hyphenation problem with accents, and since the problem is
distribution-specific. However, I would expect this to be a common
problem, given the popularity of PDF. Please consider making the T1
encoding selectable from the LyX GUI and documenting the implications.
Regards,
Eran Tromer
amsfonts
Hello,
In my installation, \mathbb and \mathfrak are not available unless I add
\usepackage{amsfonts} to the LaTeX preamble. This contradicts the User's
Guide, which states that enabling "Use AMS Math" should suffice.
I suggest to either document this or (preferably) change "Use AMS Math"
to use amsfonts in addition to amsmath.
Using LyX v1.1.4fix3 on RedHat Linux 6.2.
Regards,
Eran Tromer
