Hi,
Thanks a lot for the patch! I have pushed it onto the master branch.
Thibaut Cuvelier
On Wed, 13 Nov 2024 at 15:39, Lorenzo Bertini
wrote:
> Dear devs,
> can somebody push this tiny patch for InsetMathCases::mathmlize that adds
> an mrow that makes the bracket stretch correctly? See attac
Dear devs,
can somebody push this tiny patch for InsetMathCases::mathmlize that adds
an mrow that makes the bracket stretch correctly? See attached image.
Thanks,
Lorenzo
From 8c48be4b0ef1ede8b91e5e4fb20566225cddc172 Mon Sep 17 00:00:00 2001
From: Lorenzo Bertini
Date: Wed, 13 Nov 2024 12:55:59 +
Am Tue, 26 Apr 2022 16:12:25 +0200
schrieb Pavel Sanda :
> On Tue, Apr 26, 2022 at 03:35:30PM +0200, Jean-Marc Lasgouttes wrote:
> > Le 26/04/2022 ?? 14:58, Pavel Sanda a écrit :
> > >On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
> > >>>I read somewhere that 64 bit for long long
On Tue, Apr 26, 2022 at 03:35:30PM +0200, Jean-Marc Lasgouttes wrote:
> Le 26/04/2022 ?? 14:58, Pavel Sanda a écrit :
> >On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
> >>>I read somewhere that 64 bit for long long was a 'should' and not a 'must'.
> >
> >There is subtlety here, which
Le 26/04/2022 à 14:58, Pavel Sanda a écrit :
On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
I read somewhere that 64 bit for long long was a 'should' and not a 'must'.
There is subtlety here, which might be the source of confusion. The standard
does not tell you
long long needs
On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
> > I read somewhere that 64 bit for long long was a 'should' and not a 'must'.
There is subtlety here, which might be the source of confusion. The standard
does not tell you
long long needs to be *implemented* by 64bits. It just tells
On Mon, Apr 25, 2022 at 09:35:46PM +0200, Kornel Benko wrote:
> > Can you explain to me what is the reason for "weakly opposing" it?
>
> Yes, the code does no harm, only gave me a guaranty.
> I read somewhere that 64 bit for long long was a 'should' and not a 'must'.
Nope, we are in the 'must' re
Am Mon, 25 Apr 2022 14:11:18 +0200
schrieb Pavel Sanda :
> On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote:
> > Am Sun, 24 Apr 2022 21:45:13 +0200
> > schrieb Pavel Sanda :
> >
> > > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> > > > Try to use
> > > > $ ly
On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote:
> Am Sun, 24 Apr 2022 21:45:13 +0200
> schrieb Pavel Sanda :
>
> > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> > > Try to use
> > > $ lyx -dbg
> > > it should display
> > > ...
> > > 4294967296 debug ...
> >
Am Sun, 24 Apr 2022 21:45:13 +0200
schrieb Pavel Sanda :
> On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> > Try to use
> > $ lyx -dbg
> > it should display
> > ...
> > 4294967296 debug ...
> > then 1L would be correct.
>
> Seems to be correct now.
>
> > > > +// M
On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> Try to use
> $ lyx -dbg
> it should display
> ...
> 4294967296 debug ...
> then 1L would be correct.
Seems to be correct now.
> > > +// Make sure at compile time that sizeof(unsigned long long) >= 8
> > > +typedef
Am Fri, 22 Apr 2022 13:56:20 +0200
schrieb Kornel Benko :
> then 1L would be correct.
>
We may need 1ULL here.
Kornel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
pgpQQ3tmnTSXa.pgp
Description: Digitale Signatur von OpenPGP
--
ly
Am Fri, 22 Apr 2022 13:40:19 +0200
schrieb Pavel Sanda :
> On Fri, Apr 22, 2022 at 12:28:06PM +0200, Kornel Benko wrote:
> > Am Thu, 21 Apr 2022 15:38:23 +0200
> > schrieb Pavel Sanda :
> >
> > > On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> > > > Do you have a bette
On Fri, Apr 22, 2022 at 12:28:06PM +0200, Kornel Benko wrote:
> Am Thu, 21 Apr 2022 15:38:23 +0200
> schrieb Pavel Sanda :
>
> > On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> > > Do you have a better idea?
> >
> > long long ?
> > Pavel
>
> Ok, is the attached working
Am Thu, 21 Apr 2022 15:38:23 +0200
schrieb Pavel Sanda :
> On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> > Do you have a better idea?
>
> long long ?
> Pavel
Ok, is the attached working for you?
Kornel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http:
On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> Do you have a better idea?
long long ?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Thu, 21 Apr 2022 14:45:39 +0200
schrieb Pavel Sanda :
> On Tue, Apr 19, 2022 at 11:12:06AM +0200, Kornel Benko wrote:
> > > I am not sure that we need a verbose level yet. What about
> > > -dbg find => FINDSHORT
> > > -dbg find --verbose => FIND
> > >
> > > JMarc
> >
> > I propose to do it
Le 21/04/2022 à 14:45, Pavel Sanda a écrit :
Well, not that small change. On some gcc versions you need to include cstdint
header to have uint64_t available (AFAIK we don't use uint64_t anywhere else
in the code).
Right.
And including in debug.h which is used everywhere is not great idea.
On Tue, Apr 19, 2022 at 11:12:06AM +0200, Kornel Benko wrote:
> > I am not sure that we need a verbose level yet. What about
> > -dbg find => FINDSHORT
> > -dbg find --verbose => FIND
> >
> > JMarc
>
> I propose to do it as a next step. Better not too many changes at once IMO.
make[5]: Entering
Am Tue, 19 Apr 2022 13:05:37 +0200
schrieb Jean-Marc Lasgouttes :
> Le 19/04/2022 à 11:07, Kornel Benko a écrit :
> >> Besides the discussion of FINDSHORT, I do not think that size_t is a
> >> good type, since the only guarantee is that it is more than 16 bits
> >> (even on 32bit architectures, it
Le 19/04/2022 à 11:12, Kornel Benko a écrit :
I am not sure that we need a verbose level yet. What about
-dbg find => FINDSHORT
-dbg find --verbose => FIND
JMarc
I propose to do it as a next step. Better not too many changes at once IMO.
As you prefer.
JMarc
--
lyx-devel mailing list
lyx-de
Le 19/04/2022 à 11:07, Kornel Benko a écrit :
Besides the discussion of FINDSHORT, I do not think that size_t is a
good type, since the only guarantee is that it is more than 16 bits
(even on 32bit architectures, it is probably 32 bits). int64_t is
probably what you are after.
Yes. I had the (a
Am Tue, 19 Apr 2022 10:53:40 +0200
schrieb Jean-Marc Lasgouttes :
> Le 19/04/2022 à 10:08, Kornel Benko a écrit :
> >> We do
> >> currently have a "--verbose" but what I mean is to change "--verbose" to
> >> accept a "" argument that determines how verbose the debug output
> >> is. So this way,
Am Tue, 19 Apr 2022 10:51:14 +0200
schrieb Jean-Marc Lasgouttes :
> Le 18/04/2022 à 12:21, Kornel Benko a écrit :
> > The output while debugging findadv is overwhelming, but sometimes
> > one needs only a small subset. Therefore the addition of -dbg findshort.
>
> Besides the discussion of FIND
Le 19/04/2022 à 10:08, Kornel Benko a écrit :
We do
currently have a "--verbose" but what I mean is to change "--verbose" to
accept a "" argument that determines how verbose the debug output
is. So this way, "lyx --debug find --verbose 1" would give the same
output as "FIND", and "lyx --debug f
Le 18/04/2022 à 12:21, Kornel Benko a écrit :
The output while debugging findadv is overwhelming, but sometimes
one needs only a small subset. Therefore the addition of -dbg findshort.
Besides the discussion of FINDSHORT, I do not think that size_t is a
good type, since the only guarantee is t
Am Mon, 18 Apr 2022 21:22:41 -0400
schrieb Scott Kostyshak :
> On Mon, Apr 18, 2022 at 12:21:40PM +0200, Kornel Benko wrote:
> > The output while debugging findadv is overwhelming, but sometimes
> > one needs only a small subset. Therefore the addition of -dbg findshort.
> >
> > Also it would be
On Mon, Apr 18, 2022 at 12:21:40PM +0200, Kornel Benko wrote:
> The output while debugging findadv is overwhelming, but sometimes
> one needs only a small subset. Therefore the addition of -dbg findshort.
>
> Also it would be possible to use constructions like
> LYXERR(Debug::FIND|Debug::FIN
The output while debugging findadv is overwhelming, but sometimes
one needs only a small subset. Therefore the addition of -dbg findshort.
Also it would be possible to use constructions like
LYXERR(Debug::FIND|Debug::FINDSHORT, "Setting regexp to : '" <<
regexp_str << "'")
(mark the '|' i
Am Sat, 12 Sep 2020 03:18:38 +0200
schrieb Thibaut Cuvelier :
> > In case of interest:
> >
> > The following tests FAILED:
> > 5946 -
> > export/examples/ru/Presentations/Beamer_Article_%28Standard_Class%29_docbook5
> > (Failed)
> > 6905 - export/templates/Posters/A0_Poster/Simple_docbook5 (Fail
On Fri, 11 Sep 2020 at 13:41, Kornel Benko wrote:
> Am Fri, 11 Sep 2020 13:01:29 +0200 (CEST)
> schrieb Thibaut Cuvelier :
>
> > commit 1fccfc24da4ad2f491b659ad7dcd8fbce29eef3d
> > Author: Thibaut Cuvelier
> > Date: Fri Sep 11 03:14:41 2020 +0200
> >
>
Am Fri, 11 Sep 2020 13:01:29 +0200 (CEST)
schrieb Thibaut Cuvelier :
> commit 1fccfc24da4ad2f491b659ad7dcd8fbce29eef3d
> Author: Thibaut Cuvelier
> Date: Fri Sep 11 03:14:41 2020 +0200
>
> DocBook: handle other cases of subfigures.
>
In case of interest:
The foll
Am Donnerstag, 31. August 2017 um 14:56:29, schrieb Jean-Marc Lasgouttes
> Le 31/08/2017 à 14:31, Kornel Benko a écrit :
> > Compiles fine with gcc7.1 and qt5.8/4.8 on ubuntu. Line alignments look
> > better than on master.
> > No errors found yet. The huge testing will start if it is merged.
>
Le 31/08/2017 à 14:31, Kornel Benko a écrit :
Compiles fine with gcc7.1 and qt5.8/4.8 on ubuntu. Line alignments look better
than on master.
No errors found yet. The huge testing will start if it is merged.
Line alignment should not be any different. What may be different is the
use of sub-pi
-
> >
> > commit 17de8a989da8ec950814e044a6419c6c3fd65d43
> > Author: Jean-Marc Lasgouttes
> > Date: Wed Aug 30 18:05:16 2017 +0200
> >
> > Update insets position in cache in more cases
> >
> > This patch makes sure that, every time a ParagraphMetr
Update insets position in cache in more cases
This patch makes sure that, every time a ParagraphMetrics has its
position set, the inset positions for the insets held by this
paragraph are remembered too.
This is complementary to BufferView::updatePosCache, but I do not
Hi,
I just recovered all working regexp rest-cases, both with std::regex and with
boost::regex.
A bit of worklog can be found at #10625.
The needed further changes in lyxfind.cpp (in addition to the crash fix) have
been pushed, along
with a few fixes to tests themselves (key shortcuts no more
Le 19/07/2016 à 23:42, Jean-Marc Lasgouttes a écrit :
As I understand it, it is a bug in RowPainter::paintOnlyInsets
introduced to fix #4889. I pushed a better fix for this bug, which also
fixes your use case.
Thanks, works well.
Le 12/06/2016 à 19:05, Guillaume Munch a écrit :
In some situations, LyX does not recognize that an inset is hovered with
the mouse: does not change cursor icon, does not paint the label in a
different color, and does not show tooltip. Bisect leads to the commit
above. If you would like to have a
Le 12/06/2016 18:54, Jean-Marc Lasgouttes a écrit :
Le 12/06/2016 19:05, Guillaume Munch a écrit :
In some situations, LyX does not recognize that an inset is hovered with
the mouse: does not change cursor icon, does not paint the label in a
different color, and does not show tooltip. Bisect lea
Le 12/06/2016 19:05, Guillaume Munch a écrit :
In some situations, LyX does not recognize that an inset is hovered with
the mouse: does not change cursor icon, does not paint the label in a
different color, and does not show tooltip. Bisect leads to the commit
above. If you would like to have a r
Le 30/05/2016 13:56, Jean-Marc Lasgouttes a écrit :
commit fc73ebc16c4f0aca76360415a94eca57f283e44e
Author: Jean-Marc Lasgouttes
Date: Mon Feb 29 16:07:35 2016 +0100
Make the non-drawing cases faster in TextMetrics::drawParagraph
There are two main cases:
* when drawing is
values that
> > * LaTeX allows,
> > * have use cases (maybe rare) and
> > * are not "dangerous".
> Negative margins has some use cases:
>
> * Dealing with a printer/driver that add its own margin, or doesn't support
> unusual paper sizes
> (A
Den 07. mai 2016 08:35, skrev Guenter Milde:
This leaves open the possibility to (re)activate the validator in 2.2.1
after a non-rushed discussion.
I still favour allowing values that
* LaTeX allows,
* have use cases (maybe rare) and
* are not "dangerous".
Negative margin
majority of developers did not like this change
- it was decided to keep the old behaviour for 2.2.0
This leaves open the possibility to (re)activate the validator in 2.2.1
after a non-rushed discussion.
I still favour allowing values that
* LaTeX allows,
* have use cases (maybe rare) and
* are not "dangerous".
Günter
On Fri, May 06, 2016 at 09:42:39AM +0200, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 04.05.2016, 02:21 -0400 schrieb Scott Kostyshak:
> > Attached is a patch. It seems that everyone in this thread is in
> > favor
> > of allowing negative values where LaTeX allows negative values. The
> > patch do
Le 06/05/16 à 09:42, Jürgen Spitzmüller a écrit :
Am Mittwoch, den 04.05.2016, 02:21 -0400 schrieb Scott Kostyshak:
Attached is a patch. It seems that everyone in this thread is in
favor
of allowing negative values where LaTeX allows negative values. The
patch does this.
Note however that (if I
Am Mittwoch, den 04.05.2016, 02:21 -0400 schrieb Scott Kostyshak:
> Attached is a patch. It seems that everyone in this thread is in
> favor
> of allowing negative values where LaTeX allows negative values. The
> patch does this.
>
> Note however that (if I understand correctly the comments at #10
On 05/04/2016 02:21 AM, Scott Kostyshak wrote:
> On Mon, Apr 25, 2016 at 02:25:29PM -0400, Richard Heck wrote:
>> On 04/25/2016 01:01 PM, Scott Kostyshak wrote:
>>> On Mon, Apr 25, 2016 at 11:48:00AM -0400, Richard Heck wrote:
On 04/24/2016 10:21 PM, Cyrille Artho wrote:
> Scott Kostyshak
opening the dialog. Further, unless the user
manually goes through each tab they will not see the red text next
to the input that is now considered invalid. This could lead to
confusion for users. One example of such confusion is [1].
The following settings now allow negative values, which is
On 2016-04-25, Richard Heck wrote:
> On 04/24/2016 09:46 PM, Scott Kostyshak wrote:
>> On Sun, Apr 24, 2016 at 04:24:48PM -0400, Richard Heck wrote:
>>> On 04/24/2016 01:10 PM, Scott Kostyshak wrote:
In 2.1.x, because of a bug in our validator code, we allowed negative
values to be input
On 04/25/2016 01:01 PM, Scott Kostyshak wrote:
> On Mon, Apr 25, 2016 at 11:48:00AM -0400, Richard Heck wrote:
>> On 04/24/2016 10:21 PM, Cyrille Artho wrote:
>>> Scott Kostyshak wrote:
In 2.1.x, because of a bug in our validator code, we allowed negative
values to be input into some docu
On Mon, Apr 25, 2016 at 11:48:00AM -0400, Richard Heck wrote:
> On 04/24/2016 10:21 PM, Cyrille Artho wrote:
> > Scott Kostyshak wrote:
> >> In 2.1.x, because of a bug in our validator code, we allowed negative
> >> values to be input into some document settings. This bug has been fixed
> >> for 2.
On 04/24/2016 10:21 PM, Cyrille Artho wrote:
> Scott Kostyshak wrote:
>> In 2.1.x, because of a bug in our validator code, we allowed negative
>> values to be input into some document settings. This bug has been fixed
>> for 2.2.0dev but what that means is that if you open such a document
>> with L
Scott Kostyshak wrote:
In 2.1.x, because of a bug in our validator code, we allowed negative
values to be input into some document settings. This bug has been fixed
for 2.2.0dev but what that means is that if you open such a document
with LyX 2.2.0dev, you will not be able to save any changes to
On 04/24/2016 09:46 PM, Scott Kostyshak wrote:
> On Sun, Apr 24, 2016 at 04:24:48PM -0400, Richard Heck wrote:
>> On 04/24/2016 01:10 PM, Scott Kostyshak wrote:
>>> In 2.1.x, because of a bug in our validator code, we allowed negative
>>> values to be input into some document settings. This bug has
On Sun, Apr 24, 2016 at 04:24:48PM -0400, Richard Heck wrote:
> On 04/24/2016 01:10 PM, Scott Kostyshak wrote:
> > In 2.1.x, because of a bug in our validator code, we allowed negative
> > values to be input into some document settings. This bug has been fixed
> > for 2.2.0dev but what that means i
On 04/24/2016 01:10 PM, Scott Kostyshak wrote:
> In 2.1.x, because of a bug in our validator code, we allowed negative
> values to be input into some document settings. This bug has been fixed
> for 2.2.0dev but what that means is that if you open such a document
> with LyX 2.2.0dev, you will not b
In 2.1.x, because of a bug in our validator code, we allowed negative
values to be input into some document settings. This bug has been fixed
for 2.2.0dev but what that means is that if you open such a document
with LyX 2.2.0dev, you will not be able to save any changes to document
settings unless
On 04/16/2016 05:58 PM, Guillaume Munch wrote:
> commit 112367ed4de65d1cd2456408bf8df54a3841bcf4
> Author: Guillaume Munch
> Date: Fri Apr 8 20:24:12 2016 +0200
>
> Correct col spacing in Cases environment
Fine for 2.2.2.
rh
ginal Message
Subject:Re: #7611: Cases do not nest properly (patch included)
Date: Thu, 08 Dec 2011 16:41:54 -
From: LyX Ticket Tracker
Reply-To: lyx-devel@lists.lyx.org
To: ru...@msu.edu, rgh...@comcast.net
#7611: Cases do not nest properly (patch inc
;
Thanks,
Xu
On Sun, Feb 20, 2011 at 3:35 PM, Richard Heck wrote:
> On 02/20/2011 11:21 AM, Xu Wang wrote:
>
> By default, when one use the cases environment and beginners do not know
> that they have to add the AMS math option. Could we either add the package
> whenever the use
On 02/20/2011 11:21 AM, Xu Wang wrote:
By default, when one use the cases environment and beginners do not
know that they have to add the AMS math option. Could we either add
the package whenever the user inserts a case environment or at least
alert the user that he must add the package when
Il 29/01/2011 14:24, Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
If you don't have objections, I'm going to commit the attached patch.
not at all, go for it. if you are going to simplify keytest and write some short
intro for other for easy reuse even better.
it's in: r37364.
T.
Tommaso Cucinotta wrote:
> If you don't have objections, I'm going to commit the attached patch.
not at all, go for it. if you are going to simplify keytest and write some short
intro for other for easy reuse even better.
security features are imho not usefl here. its written by us and for us.
tha
egressions again...
yes, that could be something to do. Last, this is e.g. the output of
run-tests.sh:
autotests$ ./run-tests.sh
Running test cases . . .
findadv-01: Ok
findadv-02: Ok
hello-world: Ok
All
Tommaso Cucinotta wrote:
> one possibility could be to keep a simplified copy of it just to
> support these tests in a separate folder dedicated to testing
> the Advanced F&R (I really need some automated tests,
> so that when fixing a bug I can verify it's still working in
Il 29/01/2011 00:26, Tommaso Cucinotta ha scritto:
A few comments:
-) what's the rationale behind the syntax "\Afn" (which stands for
menu voice "&File &New") ?
-) is there a simpler syntax to let LyX type text, i.e., something
like "HelloWorld" instead of the monster in the attached in-sample.
On Fri, Jan 28, 2011 at 7:17 PM, Tommaso Cucinotta wrote:
> In order to not get too much bored on the return flight to Pisa, I just went
> through the stuff in development/keystest. Apparently, it may also be used
> as an engine to trigger LyX with a sequence of keyboard-based actions.
Keytest ma
Il 28/01/2011 19:53, Tommaso Cucinotta ha scritto:
Il 28/01/2011 12:37, Pavel Sanda ha scritto:
keytest should be more powerful.
in fact, with that I can probably choose whether to test also the GUI
part (sending characters that push buttons or type stuff), or to test
only the LFUN (by sending
Il 28/01/2011 12:37, Pavel Sanda ha scritto:
keytest should be more powerful.
in fact, with that I can probably choose whether to test also the GUI
part (sending characters that push buttons or type stuff), or to test
only the LFUN (by sending [M-x ]). The lyxserver would probably only
all
Tommaso Cucinotta wrote:
> ? What would be pros and cons of going through the lyxserver ?
keytest should be more powerful.
on the other hand if you need only lfuns, lyxserver should be more easy to
setup.
most probably lyxclient works out of the box...
> Does keytest.py actually exploit the lyxs
Il 27/01/2011 02:02, Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
AFAIK, LyX incorporates something that allows me to achieve this.
afaik there is no such thing. on the other many things you have written should
be easily doable via lyx server (look on lyxclient binary). to get precise
info
On 2011-01-27, Tommaso Cucinotta wrote:
> I'd like to have a set of automated tests for:
> -) searching stuff in a number of cases (e.g., various combinations of
> options from the GUI) for a few simple test .lyx files;
> -) emulating the hit of the "Find Next" butt
Tommaso Cucinotta wrote:
> AFAIK, LyX incorporates something that allows me to achieve this.
afaik there is no such thing. on the other many things you have written should
be easily doable via lyx server (look on lyxclient binary). to get precise
info about cursor or selection info one may need ne
Hi,
I'd like to have a set of automated tests for:
-) searching stuff in a number of cases (e.g., various combinations of
options from the GUI) for a few simple test .lyx files;
-) emulating the hit of the "Find Next" button by the user and checking
whether the selected text ma
> Trac comments don't seem to go out to the lyx-devel list so I'm
forwarding this.
Those who are interested should look into the bug report once in a
while, or should add their name to the cc-list. I guess there's no need
to post it here.
Unless of course, you need some extra attention ;).
Vin
gt; -- Forwarded Message --
>
> Subject: Re: #6564: Crash on moving out of math-cases placed in table cell
> Date: Tuesday 02 March 2010
> From: "LyX Ticket Tracker"
> To: rma...@umich.edu, lasgout...@lyx.org
>
&g
Trac comments don't seem to go out to the lyx-devel list so I'm forwarding
this.
-- Manoj
-- Forwarded Message --
Subject: Re: #6564: Crash on moving out of math-cases placed in table cell
Date: Tuesday 02 March 2010
From: "LyX Ticket Tracker"
To: rma..
Hello Tommaso,
Coming back to FindAndAdvanced? ;-)
On 01/08/2009 15:38, Tommaso Cucinotta wrote:
Hi all,
with the current LyX from svn, open the attached file, then perform
the following actions:
-) 4 times [right], then 2 times [down] ==> CRASH
-) click on any "Q", then [down] ==> CRASH
-)
Tommaso Cucinotta schreef:
Hi all,
with the current LyX from svn, open the attached file, then perform
the following actions:
-) 4 times [right], then 2 times [down] ==> CRASH
-) click on any "Q", then [down] ==> CRASH
-) click on any "i\,j", then [up] ==> CRASH
Well, CRASH is actually an ass
.} boundary
going downwards or upwards.
Bye,
Tommaso
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso
cases-crash.lyx
Description: application/lyx
Andre Poenitz schrieb:
Ok. I don't see really the big problem here. #3035 is about getting a
few spaces not right as far as I can tell from the pdf output I see.
While this is certainly not nice it is hardly "major", and I also
don't understand why this is so fundamental that it stops any furt
On Sat, Oct 11, 2008 at 01:42:53PM +0200, Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>> I tend to send them in a second mail marked by "Urmph" or similar.
>
> I got it now, it is OK by me.
>
>>> But besides this, I'm very happy that someone started to work on
>>> tex2lyx's Unicode support. As I w
etc.).
>
>>> When e.g. the option is "cp1255", we use iconv to convert the file
>>> content from cp1255 to utf8 and then we can import the result as it
>>> is as we use for the resulting LyX file also utf8.
>>> What do you think?
>>
>> That woul
lt as it
is as we use for the resulting LyX file also utf8.
What do you think?
That would be ok if we knew the encoding. Right now it looks liken
we have to guess in some cases.
I don't understand the inputenc option _IS_ the encoding. When you have more than one option, the
last one is th
255", we use iconv to convert the
> file content from cp1255 to utf8 and then we can import the result as it
> is as we use for the resulting LyX file also utf8.
> What do you think?
That would be ok if we knew the encoding. Right now it looks liken
we have to guess in some cas
Andre Poenitz schrieb:
http://bugzilla.lyx.org/show_bug.cgi?id=4299
Well, the problem here, is of course, that the .tex file does not contain any
hint what kind of encoding the file contents has.
I don't think so. LaTeX has to be informed about the encoding a file has, the same as we have to
On Sat, Oct 11, 2008 at 01:42:53PM +0200, Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>> I tend to send them in a second mail marked by "Urmph" or similar.
>
> I got it now, it is OK by me.
>
>>> But besides this, I'm very happy that someone started to work on
>>> tex2lyx's Unicode support. As I w
Andre Poenitz schrieb:
I tend to send them in a second mail marked by "Urmph" or similar.
I got it now, it is OK by me.
But besides this, I'm very happy that someone started to work on
tex2lyx's Unicode support. As I wrote some times ago to the list,
tex2lyx cannot be developed for further
On Fri, Oct 10, 2008 at 09:29:37PM +0200, Andre Poenitz wrote:
>
> The attached patch makes tex2lyx convert the following correct to .lyx
> format:
>
> --- snip ---
> \documentclass{article}
> \usepackage{inputenc}
> \inputencoding{utf8}
> \begin{docume
Andre Poenitz wrote:
The attached patch makes tex2lyx convert the following correct to .lyx
format:
--- snip ---
\documentclass{article}
\usepackage{inputenc}
\inputencoding{utf8}
\begin{document}
\section{Őasdcsad}
\end{document}
-
The attached patch makes tex2lyx convert the following correct to .lyx
format:
--- snip ---
\documentclass{article}
\usepackage{inputenc}
\inputencoding{utf8}
\begin{document}
\section{Őasdcsad}
\end{document}
--- snip --
Paul A. Rubin wrote:
> I tweaked your patch slightly. Attached is my patch against the copy of
> amsmaths.inc that shipped with LyX 1.5.5. I don't have any version of
> 1.6, so I can't patch against that. Can you take care of that and also
> the corresponding patch against trunk?
OK, it's in (b
problem). Looks ok to me.
There seems to be no definite standard for labeling cases, so I suppose
someone will be unhappy down the road. The only remaining issue I can
see is that cases are not numbered in the GUI; we use a static label
with '#' as a placeholder for the actual cas
Jürgen Spitzmüller wrote:
> Russ, Paul,
>
> how about the attached? It fixes the problem Paul reported. Is that a
> formatting you both could live with?
Ping!
Jürgen
Jürgen Spitzmüller wrote:
> Paul A. Rubin wrote:
> > I only found one problem, illustrated by the attached DVI. If the cases
> > occur in the middle of ordinary text (rather than nested in something
> > like a proof environment), they violate the left margin of the docu
Paul A. Rubin wrote:
> I only found one problem, illustrated by the attached DVI. If the cases
> occur in the middle of ordinary text (rather than nested in something
> like a proof environment), they violate the left margin of the document.
Russ?
Jürgen
e the 1.6 alpha, and
theorems-ams.inc in 1.5.4 is different from the one against which Russ
is diffing. So I tested only the first patch (against 1.5.4).
I only found one problem, illustrated by the attached DVI. If the cases
occur in the middle of ordinary text (rather than nested in som
Russ Woodroofe wrote:
> ATTACHMENTS:
> Patch against 1.5.4
> Patch against 'trunk' as downloaded Mar 22, 2008
Paul, could you have a look at these patches, please?
Thanks,
Jürgen
1 - 100 of 206 matches
Mail list logo
