Martin Vermeer wrote:
> You're even righter than you think: these conditions are not needed when
> you think about it, so I just removed all of them.
Why are they not needed? I must be blind, but I don't see it. And if they
are really not needed, then there is IMHO no need for the new methods at
all, simply call rowinfo_[row].lines_++; etc. in dispatch().
>> Another question: What about lines above the first row and below the
>> last? I believe that this is possible in LaTeX, but how to support it
>> here? I can't think of a better way than having an addHLineBelow() etc.
>
> No, neither can I. But as there is no support for this in the current
> mathed infrastructure, implementing this would go much further than just
> fixing a broken UI. For 1.5?
This is supported, at least for hlines (OK, the display in LyX is broken,
but LaTeX output is alright). It is not for vlines, but since this is
possible in LaTeX and mathed reads and writes (a reasonable subset of)
LaTeX this qualifies IMO rather as bug and not as new feature.
I'll have a look wether it is easy to fix.
>> And getStatus needs to be updated to disable addHLineAbove if the cursor
>> is in the first row.
>
> How? If I look at getStatus for math_gridinset, I see a lot of stuff
> commented out. Is this supposed to work at all, and how?
I don't understand this one:
if (v_align_ == '\0') {
flag.enabled(true);
break;
}
but the rest looks as if it should be reenabled.
What I meant is something like in MathHullInset: E.g disable add-hline-above
if (row == 0 && s == "add-hline-above") {
flag.message(N_("Can't add a hline above the first row"));
flag.enabled(false);
return true;
}
But the problem is that we don't know row here!
Georg
