On Sun, Apr 10, 2005 at 09:14:32PM +0300, Martin Vermeer wrote:
> If you can do it more efficiently, why not. I don't like special casing,
> but if you can do it in MathRootInset::doDispatch() it would even be
> clean.
>
> One reason I didn't consider this (not recognize what was meant,
> actually
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Indeed. Right now we should just add the missing 'cur.undispatched()'
| calls.
And we should work to make the cursor a bit simpler, not even more
complex. It is quite fat you know...
--
Lgb
> So I wonder if this was the right approach - or would a special
> case in pasting be better?
...
> I wonder if this was the right approach - or would a special
> case in pasting be better?
>
> Helge Hafting
Attached the special-casing solution. You were right, even if special
casing is
On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote:
> 1. Applying n-root over a selection improved.(Good)
> 2. DVI output still matches what's on screen(no change)
> 3. "edit->math->computer algebra->maxima"
>results still correct. (no c
On Sun, Apr 10, 2005 at 05:22:12PM +0300, Martin Vermeer wrote:
> I do believe that we should have "read" methods in all the insets to
> replace the monolithic math parser. How to do that, is another question.
It's on the agenda, but not for 1.4.0. Each inset would have to register
it's 'reader' w
On Sun, Apr 10, 2005 at 10:47:37AM +0300, Martin Vermeer wrote:
> This sounds great... to make it perfectly clear, you propose to replace
> the loop at
>
> 204 for (; depth(); pop()) {
> ...
> 214 disp_.update(true);
> 215 disp_
On Sun, Apr 10, 2005 at 06:48:33PM +0200, Georg Baum wrote:
> Am Sonntag, 10. April 2005 16:22 schrieb Martin Vermeer:
> > On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote:
> > > I wonder if this was the right approach - or would a special
> > > case in pasting be better?
> > >
> > >
Am Sonntag, 10. April 2005 16:22 schrieb Martin Vermeer:
> On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote:
> > I wonder if this was the right approach - or would a special
> > case in pasting be better?
> >
> > Helge Hafting
>
> I am afraid I must apologize for underestimating thi
On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote:
> On Sun, Apr 10, 2005 at 10:52:54AM +0300, Martin Vermeer wrote:
> > On Sun, Apr 10, 2005 at 12:05:29AM +0200, Andre Poenitz wrote:
> > > On Sat, Apr 09, 2005 at 04:46:45PM +0200, Helge Hafting wrote:
> > > > The problem is mostly the
> The "write" part in math_rootinset.C was changed, and we need
> a corresponding change wherever the "read" takes place.
It takes place here (math_parser.C):
1026 if (ar.size()) {
1027 cell->push_back(MathAtom(new MathRootInset));
1028 cell->bac
...
> 4. An old saved document with the fourth root of 81
>now loaded as the 81th root of four. Saving and
>reloading also swaps the n-root components. (Quite bad!)
...
> 6. The third root special now sticks the "3" under
>the root sign. (Wr
On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote:
> On Sun, Apr 10, 2005 at 10:52:54AM +0300, Martin Vermeer wrote:
> > On Sun, Apr 10, 2005 at 12:05:29AM +0200, Andre Poenitz wrote:
> > > On Sat, Apr 09, 2005 at 04:46:45PM +0200, Helge Hafting wrote:
> > > > The problem is mostly the
On Sun, Apr 10, 2005 at 10:52:54AM +0300, Martin Vermeer wrote:
> On Sun, Apr 10, 2005 at 12:05:29AM +0200, Andre Poenitz wrote:
> > On Sat, Apr 09, 2005 at 04:46:45PM +0200, Helge Hafting wrote:
> > > The problem is mostly the same if applying the n-root, one expect
> > > the selection to go under
On Sun, Apr 10, 2005 at 12:05:29AM +0200, Andre Poenitz wrote:
> On Sat, Apr 09, 2005 at 04:46:45PM +0200, Helge Hafting wrote:
> > The problem is mostly the same if applying the n-root, one expect
> > the selection to go under the root, not above it. So perhaps
> > the n-root ought to be a little
On Sun, Apr 10, 2005 at 12:02:35AM +0200, Andre Poenitz wrote:
> On Sat, Apr 09, 2005 at 05:33:18PM +0300, Martin Vermeer wrote:
> > Here is the next patch... adding a cur.undispatched() statement did
> > the job. So the LFUN_FINISHED mechanism seems to work... in this
> > case, it allowed he curs
On Sat, Apr 09, 2005 at 05:33:18PM +0300, Martin Vermeer wrote:
> Here is the next patch... adding a cur.undispatched() statement did
> the job. So the LFUN_FINISHED mechanism seems to work... in this
> case, it allowed he cursor to skip out of the inset, immediately to
> the right of the parentes
On Sat, Apr 09, 2005 at 11:47:41AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Don't know right now and don't have access to sources.
>
> What chance of you getting access to the sources and some time to do
> something to them in the next month or so?
Getting access to the sources migh
On Sat, Apr 09, 2005 at 04:46:45PM +0200, Helge Hafting wrote:
> The problem is mostly the same if applying the n-root, one expect
> the selection to go under the root, not above it. So perhaps
> the n-root ought to be a little special? It'd be consistent
> with the square root.
Simply swap the m
>
> Here is the next patch... adding a cur.undispatched() statement did the job.
> So the LFUN_FINISHED mechanism seems to work... in this case, it allowed
> he cursor to skip out of the inset, immediately to the right of the
> parentesis, when pressing the END key. But how now do I get it to go
On Sat, Apr 09, 2005 at 10:35:53AM +0200, Andre Poenitz wrote:
> On Wed, Apr 06, 2005 at 03:30:25PM +0200, Helge Hafting wrote:
> > The general problem: where should the selected stuff go, if the user
> > applies something that have more than one input box?
> > For a fraction, the stuff goes on top
On Sat, Apr 09, 2005 at 05:11:01PM +0300, Martin Vermeer wrote:
> On Sat, Apr 09, 2005 at 11:20:09AM +0200, Andre Poenitz wrote:
> > On Thu, Apr 07, 2005 at 07:40:26AM +0300, Martin Vermeer wrote:
...
> > > @@ -564,7 +563,8 @@
> > > cur.idx() = cur.lastidx();
> > >
On Sat, Apr 09, 2005 at 11:20:09AM +0200, Andre Poenitz wrote:
> On Thu, Apr 07, 2005 at 07:40:26AM +0300, Martin Vermeer wrote:
> > See the attached patch, which does the job.
> >
> > There are obvious further simplifications possible.
> >
> > - Martin
> >
> >
>
> > Index: math_nestinset.C
>
Andre Poenitz wrote:
> Don't know right now and don't have access to sources.
What chance of you getting access to the sources and some time to do
something to them in the next month or so?
--
Angus
On Wed, Apr 06, 2005 at 10:56:44PM +0300, Martin Vermeer wrote:
>if (cur.posRight() || idxRight(cur)
> || cur.popRight() || cur.selection())
> ;
>else
> cmd = Func
On Wed, Apr 06, 2005 at 03:38:52PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Hmmm, it might be nice to enable END at the last position to
> Martin> exit the parentheses. Opinions?
>
> Or rather to dispatch the END to the enclosin
On Wed, Apr 06, 2005 at 04:52:48PM +0300, Martin Vermeer wrote:
> Is this a new feature? Or a regression fix?
The latter. Navigation was ok in 1.3, so if end gets stuck it's a
regression.
Andre'
On Wed, Apr 06, 2005 at 04:04:43PM +0300, Martin Vermeer wrote:
> > Pressing END inside matching parantheses no longer kills lyx, nice.
> > Instead, the cursor goes to the last paranthesis.
>
> By design :-)
>
> > I can't
> > get to the end of line with END alone, but maybe the key isn't
> > mea
On Wed, Apr 06, 2005 at 03:30:25PM +0200, Helge Hafting wrote:
> The general problem: where should the selected stuff go, if the user
> applies something that have more than one input box?
> For a fraction, the stuff goes on top which is ok. For a
> n-root it goes into the n-part, which is less us
On Thu, Apr 07, 2005 at 07:40:26AM +0300, Martin Vermeer wrote:
> See the attached patch, which does the job.
>
> There are obvious further simplifications possible.
>
> - Martin
>
>
> Index: math_nestinset.C
> ===
> RCS file: /u
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> See the attached patch, which does the job.
Martin> There are obvious further simplifications possible.
It looks simple indeed. Let's wait until next monday to have Andre's
views on this...
JMarc
On Wed, Apr 06, 2005 at 10:56:44PM +0300, Martin Vermeer wrote:
> On Wed, Apr 06, 2005 at 04:22:18PM +0200, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> > I am not able to follow the logic, though.
>
>
> You're in good company.
>
> I see t
On Wed, Apr 06, 2005 at 04:22:18PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Is this a new feature? Or a regression fix?
>
> Don't now :)
>
> Martin> As you seem to know these things, I'm sure you also know a
> Martin> really c
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Is this a new feature? Or a regression fix?
Don't now :)
Martin> As you seem to know these things, I'm sure you also know a
Martin> really code-efficient way to do this :-)
In math_nestinset.C::doDispatch, I see plenty of cod
On Wed, 2005-04-06 at 16:38, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Hmmm, it might be nice to enable END at the last position to
> Martin> exit the parentheses. Opinions?
>
> Or rather to dispatch the END to the enclosing inset.
>
>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Hmmm, it might be nice to enable END at the last position to
Martin> exit the parentheses. Opinions?
Or rather to dispatch the END to the enclosing inset.
JMarc
Martin Vermeer wrote:
On Wed, 2005-04-06 at 15:38, Helge Hafting wrote:
...
It does help. Attached a new patch doing two things:
1) it tests for ncols() > 0 (I.e., establishes that this is
a "grid-type" nest inset) before trying to update anything involving
column numbers. This fixes your bug, H
Martin Vermeer wrote:
On Wed, 2005-04-06 at 15:38, Helge Hafting wrote:
...
It does help. Attached a new patch doing two things:
1) it tests for ncols() > 0 (I.e., establishes that this is
a "grid-type" nest inset) before trying to update anything involving
column numbers. This fixes your bug, H
On Wed, 2005-04-06 at 15:55, Helge Hafting wrote:
> Helge Hafting wrote:
...
> I added the "cut/paste in nestinsets" patch to this, and
> it made no difference. It applied with no errors, but it didn't
> seem to make a difference.
Don't. It's a wrong patch, superseded by the 12:55 PM one. Othe
On Wed, 2005-04-06 at 15:38, Helge Hafting wrote:
...
> >It does help. Attached a new patch doing two things:
> >
> >1) it tests for ncols() > 0 (I.e., establishes that this is
> >a "grid-type" nest inset) before trying to update anything involving
> >column numbers. This fixes your bug, Helge.
>
Helge Hafting wrote:
Pressing END inside matching parantheses no longer kills lyx, nice.
Instead, the cursor goes to the last paranthesis. I can't
get to the end of line with END alone, but maybe the key isn't
meant to do that in math?
The selection stuff did not improve for me, though.
Type C-M 1+
Martin Vermeer wrote:
On Tue, 2005-04-05 at 20:27, Martin Vermeer wrote:
On Tue, Apr 05, 2005 at 07:23:40PM +0200, Helge Hafting wrote:
I typed h_1 (k)=2654435769k/2^32-11 into math.
Then, I wanted the part after "=" in brackets, so I marked
it and inserted matching brackets from the math
On Tue, 2005-04-05 at 20:27, Martin Vermeer wrote:
> On Tue, Apr 05, 2005 at 07:23:40PM +0200, Helge Hafting wrote:
> >
> > I typed h_1 (k)=2654435769k/2^32-11 into math.
> > Then, I wanted the part after "=" in brackets, so I marked
> > it and inserted matching brackets from the math panel. Thi
On Tue, Apr 05, 2005 at 07:23:40PM +0200, Helge Hafting wrote:
>
> I typed h_1 (k)=2654435769k/2^32-11 into math.
> Then, I wanted the part after "=" in brackets, so I marked
> it and inserted matching brackets from the math panel. This
> works fine i lyx 1.3
>
> Now I got this:
>
> [265443576
43 matches
Mail list logo
