Le 02/02/2016 23:23, Uwe Stöhr a écrit :
Am 02.02.2016 um 22:02 schrieb Guillaume Munch:
I am sceptical, since the other patches which made your software crash
were based against master. You can try again with the same diff since
InsetMathGrid.cpp with hash 12e871a... is now in master.
I trie
Am 02.02.2016 um 22:02 schrieb Guillaume Munch:
I am sceptical, since the other patches which made your software crash
were based against master. You can try again with the same diff since
InsetMathGrid.cpp with hash 12e871a... is now in master.
I tried your patch again and now it applied with
Le 25/01/2016 23:49, Uwe Stöhr a écrit :
Am 25.01.2016 um 07:21 schrieb Stephan Witt:
I cannot apply your patch. I get the 2 attached errors and the
TortoiseGit crashes.
It tells me that it cannot find the revision 12e871a for
InsetMathGrid.cpp. And indeed this revsion does not exists.
Guill
Le 25/01/2016 00:32, Uwe Stöhr a écrit :
Am 25.01.2016 um 00:28 schrieb Guillaume Munch:
> Georg's commit indeed fixed the alignment, but not the width of the
column, which sometimes makes it hard to see that the first line is
left-aligned and the last one right-aligned. So you are saying that
Am 25.01.2016 um 07:21 schrieb Stephan Witt:
I cannot apply your patch. I get the 2 attached errors and the TortoiseGit
crashes.
It tells me that it cannot find the revision 12e871a for
InsetMathGrid.cpp. And indeed this revsion does not exists.
Guillaume, can you please send a patch file
Am 25.01.2016 um 01:37 schrieb Uwe Stöhr :
>
> Am 24.01.2016 um 23:29 schrieb Guillaume Munch:
>
>> Here are the patches as a single diff. Can you please confirm that this
>> triggers your issue?
>
> I cannot apply your patch. I get the 2 attached errors and the TortoiseGit
> crashes.
I was cu
Am 24.01.2016 um 23:29 schrieb Guillaume Munch:
Here are the patches as a single diff. Can you please confirm that this
triggers your issue?
I cannot apply your patch. I get the 2 attached errors and the
TortoiseGit crashes.
I seems that your patches make problems for TortoiseGit (I use the
Am 25.01.2016 um 00:28 schrieb Guillaume Munch:
> Georg's commit indeed fixed the alignment, but not the width of the
column, which sometimes makes it hard to see that the first line is
left-aligned and the last one right-aligned. So you are saying that the
fix of multline was not sufficient to
Le 24/01/2016 12:04, Uwe Stöhr a écrit :
Am 22.01.2016 um 20:30 schrieb Guillaume Munch:
Can you please tell me what issue you are referring to precisely in
#1497 then?
Open the testfile I attached to
http://www.lyx.org/trac/ticket/1497
Compare the appearance in lyx with that in the PDF outp
Le 24/01/2016 11:15, Uwe Stöhr a écrit :
Am 22.01.2016 um 02:07 schrieb Uwe Stöhr:
I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied.
I still had your patch applied and this caused a crash:
http://www.lyx.org/trac/ticket/9944
Can you please have
Am 22.01.2016 um 20:30 schrieb Guillaume Munch:
Can you please tell me what issue you are referring to precisely in
#1497 then?
Open the testfile I attached to
http://www.lyx.org/trac/ticket/1497
Compare the appearance in lyx with that in the PDF output:
- for multline (first formula in the
Am 22.01.2016 um 02:07 schrieb Uwe Stöhr:
I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied.
I still had your patch applied and this caused a crash:
http://www.lyx.org/trac/ticket/9944
Can you please have a look and provide a new patch? (if possi
Le 21/01/2016 20:07, Uwe Stöhr a écrit :
Am 21.01.2016 um 07:06 schrieb Guillaume Munch:
The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one
Le 21/01/2016 20:07, Uwe Stöhr a écrit :
Am 21.01.2016 um 07:06 schrieb Guillaume Munch:
The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one
Am 21.01.2016 um 07:06 schrieb Guillaume Munch:
The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one.
I tried this but cannot see a problem
Le 19/01/2016 20:10, Uwe Stöhr a écrit :
Am 19.01.2016 um 23:45 schrieb Guillaume Munch:
Note that I do not know if it applies cleanly now.
Hmm, seems the bug in my git client is to "apply patch serial". This
means to apply 2 or more patches at once. When I apply them one after
another no pro
Am 19.01.2016 um 23:45 schrieb Guillaume Munch:
Note that I do not know if it applies cleanly now.
Hmm, seems the bug in my git client is to "apply patch serial". This
means to apply 2 or more patches at once. When I apply them one after
another no problem occurs.
I did this (applied patch
Le 19/01/2016 16:52, Uwe Stöhr a écrit :
Am 11.01.2016 um 03:21 schrieb Guillaume Munch:
See the attached for two "safe" (and easy to read) patches, if you agree
that a safe patch that we have been discussing for a month can still get
in for 2.2.
I wanted to apply the patches at once and this
Am 19.01.2016 um 22:52 schrieb Uwe Stöhr:
However, I think I fixed it
No, my Git is completely broken. It tells me that I have never committed
anything the last hour but I made several commits that played ping pong.
It also telly me that my tree is completely clean and that there are no
ch
Am 11.01.2016 um 03:21 schrieb Guillaume Munch:
See the attached for two "safe" (and easy to read) patches, if you agree
that a safe patch that we have been discussing for a month can still get
in for 2.2.
I wanted to apply the patches at once and this way destroyed my complete
git folder. Se
Guillaume Munch wrote:
> However, if you do not have the time, this is a sufficient reason by
> itself. I am not forcing you to read these patches, and you do not need
> an excuse.
time is unfortunately really an issue for me currently.
> Maybe one more thing we are in disagreement about is your
Le 11/01/2016 21:41, Georg Baum a écrit :
Guillaume Munch wrote:
I replace stored alignment and spacing values with computed values, only
in the case of specific grids under discussion (Eqnarray, AMS...). Thus,
defaultColAlign() can still make sense in the future for grids that rely
on stored a
Guillaume Munch wrote:
> I replace stored alignment and spacing values with computed values, only
> in the case of specific grids under discussion (Eqnarray, AMS...). Thus,
> defaultColAlign() can still make sense in the future for grids that rely
> on stored alignment and spacing, and I do not se
Le 11/01/2016 20:30, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
What is BTW the reason why you skip recordUndo in these cases?
My understanding is that these changes do not modify the document if
store_user_prefs is false, and therefore nothing can be undone.
Yes. BTW this correspon
Jean-Marc Lasgouttes wrote:
> What is BTW the reason why you skip recordUndo in these cases?
My understanding is that these changes do not modify the document if
store_user_prefs is false, and therefore nothing can be undone.
Georg
Guillaume Munch wrote:
> Le 10/01/2016 19:08, Georg Baum a écrit :
>>
>> You don't need to do anything in tex2lyx besides writing the new
>> parameter with a default value as you did in the patch.
>
> I mean it for the tests, as I have no familiarity with the latter.
This is easy: How to update
Le 10/01/2016 23:56, Guillaume Munch a écrit :
Some questions on the second patch:
1/ can OUTPUT_CHANGES be toggled for a read-only document if user prefs
are not stored?
No. Currently one cannot enable "output changes" on a
read-only document (on 2.1.5dev). If you think that this is a bug, the
Kornel Benko wrote:
> This all is getting more and more confusing. Too complicated (at least for me)
You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.
.. and sometimes you
Am Montag, 11. Januar 2016 um 01:38:28, schrieb Pavel Sanda
> Georg Baum wrote:
> > Guillaume Munch wrote:
> >
> > > I agree that the current situation regarding \output_change and
> > > \tracking_change is bad and should be fixed. I gave what I think is the
> > > proper solution, taking into acc
Georg Baum wrote:
> Guillaume Munch wrote:
>
> > I agree that the current situation regarding \output_change and
> > \tracking_change is bad and should be fixed. I gave what I think is the
> > proper solution, taking into account the debate that was on the list.
> > The patch is very simple (see t
Le 06/01/2016 20:51, Georg Baum a écrit :
Guillaume Munch wrote:
Le 03/01/2016 11:04, Georg Baum a écrit :
Really? The amount of code changes is big, and I cannot see from the
patch that it has no influence on the .tex input/output or mathml/xhtml
output. If it can not be 100% guaranteed that
Le 10/01/2016 21:11, Jean-Marc Lasgouttes a écrit :
Le 08/01/16 23:05, Guillaume Munch a écrit :
I agree that the current situation regarding \output_change and
\tracking_change is bad and should be fixed. I gave what I think is the
proper solution, taking into account the debate that was on the
Le 10/01/2016 19:08, Georg Baum a écrit :
>
I looked at the patches in http://www.lyx.org/trac/ticket/9841, and I think
it is a good implementation of the consensus that has been reached earlier.
You have a +1 from me, but because this has been discussed with some strong
opinions I suggest that t
Le 08/01/16 23:05, Guillaume Munch a écrit :
I agree that the current situation regarding \output_change and
\tracking_change is bad and should be fixed. I gave what I think is the
proper solution, taking into account the debate that was on the list.
The patch is very simple (see the earlier mess
Guillaume Munch wrote:
> I agree that the current situation regarding \output_change and
> \tracking_change is bad and should be fixed. I gave what I think is the
> proper solution, taking into account the debate that was on the list.
> The patch is very simple (see the earlier message:
> http://a
Le 06/01/2016 20:51, Georg Baum a écrit :
BTW, a proper solution for 9841 is much more important than these alignment
issues IMHO. The current situation is worse than before dc016de34ea.
I agree that the current situation regarding \output_change and
\tracking_change is bad and should be fi
Guillaume Munch wrote:
> Le 03/01/2016 11:04, Georg Baum a écrit :
>>
>> Really? The amount of code changes is big, and I cannot see from the
>> patch that it has no influence on the .tex input/output or mathml/xhtml
>> output. If it can not be 100% guaranteed that only the display is changed
>> t
Le 03/01/16 19:27, Guillaume Munch a écrit :
I thought that the separation in three patches was already enough to see
what each does... Which one are you discussing exactly? I fail to see
what you would like to see separated/avoided, can you give me an example?
You are right of course. Sorry ab
Le 03/01/2016 13:30, Jean-Marc Lasgouttes a écrit :
Le 03/01/2016 12:04, Georg Baum a écrit :
Yes , sort of. I cannot tell that it really works, but if it does not,
it would not be too dangerous :)
Really? The amount of code changes is big, and I cannot see from the
patch
that it has no influe
Le 03/01/2016 11:04, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Le 01/01/16 18:57, Guillaume Munch a écrit :
Dear list,
Here's the latest version of the patch after discussion during the ML
shortage here: http://www.lyx.org/trac/ticket/9908. As I explained
there, this only affects the d
On 01/03/2016 08:30 AM, Jean-Marc Lasgouttes wrote:
> Le 03/01/2016 12:04, Georg Baum a écrit :
>>> Yes , sort of. I cannot tell that it really works, but if it does not,
>>> it would not be too dangerous :)
>>
>> Really? The amount of code changes is big, and I cannot see from the
>> patch
>> that
Le 03/01/2016 12:04, Georg Baum a écrit :
Yes , sort of. I cannot tell that it really works, but if it does not,
it would not be too dangerous :)
Really? The amount of code changes is big, and I cannot see from the patch
that it has no influence on the .tex input/output or mathml/xhtml output.
Jean-Marc Lasgouttes wrote:
> Le 01/01/16 18:57, Guillaume Munch a écrit :
>> Dear list,
>>
>> Here's the latest version of the patch after discussion during the ML
>> shortage here: http://www.lyx.org/trac/ticket/9908. As I explained
>> there, this only affects the display. Jean-Marc, was your co
Le 01/01/16 18:57, Guillaume Munch a écrit :
Dear list,
Here's the latest version of the patch after discussion during the ML
shortage here: http://www.lyx.org/trac/ticket/9908. As I explained
there, this only affects the display. Jean-Marc, was your comment an
encouragement to push?
Yes , sor
Dear list,
Here's the latest version of the patch after discussion during the ML
shortage here: http://www.lyx.org/trac/ticket/9908. As I explained
there, this only affects the display. Jean-Marc, was your comment an
encouragement to push?
Guillaume
>From 1361409246f89b043bc215183a171d469dccf69
Le 17/12/2015 16:50, Guillaume Munch a écrit :
Le 14/12/2015 12:27, Jean-Marc Lasgouttes a écrit :
Le 14/12/2015 12:05, Guillaume Munch a écrit :
You're right, see now second patch attached. It's a fairly simple
change, only adding some information to Georg's displayColAlign(), in
addition to
Le 14/12/2015 12:27, Jean-Marc Lasgouttes a écrit :
Le 14/12/2015 12:05, Guillaume Munch a écrit :
You're right, see now second patch attached. It's a fairly simple
change, only adding some information to Georg's displayColAlign(), in
addition to some mechanical refactoring and disabling of hori
Le 14/12/2015 12:05, Guillaume Munch a écrit :
> You're right, see now second patch attached. It's a fairly simple
> change, only adding some information to Georg's displayColAlign(), in
> addition to some mechanical refactoring and disabling of horizontal
> alignment buttons which were wrongly ena
Le 13/12/2015 11:41, Jean-Marc Lasgouttes a écrit :
Le 13/12/2015 04:37, Guillaume Munch a écrit :
Dear list
This has been annoying me for a while. OK to push?
It would deserve a commit log with explanations of what this fixes. The
patch does many things it is difficult for me to say whether
Le 13/12/2015 04:37, Guillaume Munch a écrit :
Dear list
This has been annoying me for a while. OK to push?
It would deserve a commit log with explanations of what this fixes. The
patch does many things it is difficult for me to say whether this is
correct. Anyway this could also be somethin
Dear list
This has been annoying me for a while. OK to push?
Sincerely
Guillaume
>From 4a13412d56ff1c528e7a0bf39b64910f5042e058 Mon Sep 17 00:00:00 2001
From: Guillaume Munch
Date: Sun, 13 Dec 2015 03:32:32 +
Subject: [PATCH] Display the correct horizontal alignment in AMS environme
51 matches
Mail list logo
