On Tue, 2025-05-20 at 19:05 +0200, Enrico Forestieri wrote:
> I don't know what to do. On the one hand the attached patch solves the
> issue for me with version 1.15, but I don't have any info on the return
> codes from dvipng and it very possible that that return code (136) is
> not specific to
On Mon, May 19, 2025 at 11:39:32PM +0200, Enrico Forestieri wrote:
On Mon, May 19, 2025 at 02:44:06PM +0200, Jean-Marc Lasgouttes wrote:
Dear all,
With UserGuide, I get a lot of output concerning previews:
Warning: dvipng failed to generate images from
lyxpreviewSZhsFp.dvi... fallback to lega
On Mon, May 19, 2025 at 02:44:06PM +0200, Jean-Marc Lasgouttes wrote:
Dear all,
With UserGuide, I get a lot of output concerning previews:
Warning: dvipng failed to generate images from lyxpreviewSZhsFp.dvi...
fallback to legacy method
Warning: epstopdf failed on page 1, file lyxpreviewSZhsFp
On Sat, 2024-07-27 at 16:14 +0100, José Matos wrote:
> I am not sure if this is from LyX or from KDE.
Followup to this:
This issue is/seems to be from KDE from calling okular through xgd-
open.
Best regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/m
On Thu, Dec 15, 2022 at 12:38:28AM +0100, Thibaut Cuvelier wrote:
> On Sat, 26 Nov 2022 at 20:33, Scott Kostyshak
> wrote:
>
> > On Wed, Nov 09, 2022 at 10:41:17AM +0100, Jean-Marc Lasgouttes wrote:
> > > Hi,
> > >
> > > I get this warning when compiling in C++11 mode :
> > >
> > > ../../master/s
On Sat, 26 Nov 2022 at 20:33, Scott Kostyshak
wrote:
> On Wed, Nov 09, 2022 at 10:41:17AM +0100, Jean-Marc Lasgouttes wrote:
> > Hi,
> >
> > I get this warning when compiling in C++11 mode :
> >
> > ../../master/src/insets/InsetIndex.cpp: In member function ‘virtual void
> > lyx::InsetIndex::docb
On Wed, Nov 09, 2022 at 10:41:17AM +0100, Jean-Marc Lasgouttes wrote:
> Hi,
>
> I get this warning when compiling in C++11 mode :
>
> ../../master/src/insets/InsetIndex.cpp: In member function ‘virtual void
> lyx::InsetIndex::docbook(lyx::XMLStream&, const lyx::OutputParams&) const’:
> ../../mast
On Wed, Dec 09, 2020 at 05:20:41PM +0100, Jean-Pierre Chrétien wrote:
> I just compiled 2.3.6 today.
>
> I see this, whic is harmless I guess.
Once you check the code in depth its actually harmless indeed.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listi
Le 16/10/2020 à 12:14, Stephan Witt a écrit :
Yes, it works. Thank you.
Thank you for proposing the right idea :)
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am 16.10.2020 um 10:05 schrieb Jean-Marc Lasgouttes :
>
> Le 11/10/2020 à 21:06, Stephan Witt a écrit :
>> Am 11.10.2020 um 20:55 schrieb Stephan Witt :
>> Oh, that was the wrong patch. The correct one is attached now.
>
> Does what I pushed to master work well?
Yes, it works. Thank you.
Stepha
Le 11/10/2020 à 21:06, Stephan Witt a écrit :
Am 11.10.2020 um 20:55 schrieb Stephan Witt :
Oh, that was the wrong patch. The correct one is attached now.
Does what I pushed to master work well?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-
On 2020-10-12 11:11, Jean-Marc Lasgouttes wrote:
Le 12/10/2020 à 11:06, Daniel a écrit :
In case I have managed to correctly revert a change (first time), it
did not make any difference to the warning. I am not sure which change
triggered it then. Or maybe I need to update/change something else
Le 12/10/2020 à 11:06, Daniel a écrit :
In case I have managed to correctly revert a change (first time), it did
not make any difference to the warning. I am not sure which change
triggered it then. Or maybe I need to update/change something else for
it to take effect?
Did you run ./autogen.s
On 2020-10-09 12:18, Jean-Marc Lasgouttes wrote:
[reply on lyx-devel, since this is not something I 100% understand]
Le 08/10/2020 à 09:32, racoon a écrit :
I am getting lots of
warning: unknown warning option '-Wno-deprecated-copy'; did you mean
'-Wno-deprecated'?
[-Wunknown-warning-op
Am Sun, 11 Oct 2020 22:07:27 +0200
schrieb Jean-Marc Lasgouttes :
> Le 11/10/2020 à 21:06, Stephan Witt a écrit :
> >> What do you think of the attached patch? It tests the compiler behavior
> >> instead of
> >> relying on the version.
> >>
> >> With Apple clang on missing -Wno-deprecated-copy su
Le 11/10/2020 à 21:06, Stephan Witt a écrit :
What do you think of the attached patch? It tests the compiler behavior instead
of relying on the version.
With Apple clang on missing -Wno-deprecated-copy support it works.
Oh, that was the wrong patch. The correct one is attached now.
It is in
Am 11.10.2020 um 20:55 schrieb Stephan Witt :
>
> Am 09.10.2020 um 12:18 schrieb Jean-Marc Lasgouttes :
>>
>> [reply on lyx-devel, since this is not something I 100% understand]
>>
>> Le 08/10/2020 à 09:32, racoon a écrit :
>>> I am getting lots of
>>> warning: unknown warning option '-Wno-depre
Am 09.10.2020 um 12:18 schrieb Jean-Marc Lasgouttes :
>
> [reply on lyx-devel, since this is not something I 100% understand]
>
> Le 08/10/2020 à 09:32, racoon a écrit :
>> I am getting lots of
>> warning: unknown warning option '-Wno-deprecated-copy'; did you mean
>> '-Wno-deprecated'?
>>
[reply on lyx-devel, since this is not something I 100% understand]
Le 08/10/2020 à 09:32, racoon a écrit :
I am getting lots of
warning: unknown warning option '-Wno-deprecated-copy'; did you mean
'-Wno-deprecated'?
[-Wunknown-warning-option]
I have
% clang --version
Apple clang versi
On Sun, Jul 14, 2019 at 07:58:46AM +0200, Kornel Benko wrote:
> Am Sonntag, 14. Juli 2019, 01:17:57 CEST schrieb Jean-Marc Lasgouttes:
> > Le 14/07/2019 à 00:15, Kornel Benko a écrit :
> > > Am Samstag, 13. Juli 2019, 23:13:50 CEST schrieb Jean-Marc Lasgouttes:
> > >> Le 13/07/2019 à 23:01, Kornel
Am Sonntag, 14. Juli 2019, 01:17:57 CEST schrieb Jean-Marc Lasgouttes:
> Le 14/07/2019 à 00:15, Kornel Benko a écrit :
> > Am Samstag, 13. Juli 2019, 23:13:50 CEST schrieb Jean-Marc Lasgouttes:
> >> Le 13/07/2019 à 23:01, Kornel Benko a écrit :
> >>> At least the message should be easy identifiable
Le 14/07/2019 à 00:15, Kornel Benko a écrit :
Am Samstag, 13. Juli 2019, 23:13:50 CEST schrieb Jean-Marc Lasgouttes:
Le 13/07/2019 à 23:01, Kornel Benko a écrit :
At least the message should be easy identifiable as error, so that
we can parse it while testing layouts.
Can you tell me more abo
Am Samstag, 13. Juli 2019, 23:13:50 CEST schrieb Jean-Marc Lasgouttes:
> Le 13/07/2019 à 23:01, Kornel Benko a écrit :
> > At least the message should be easy identifiable as error, so that
> > we can parse it while testing layouts.
>
> Can you tell me more about how this works? I did not try the
Le 13/07/2019 à 23:01, Kornel Benko a écrit :
At least the message should be easy identifiable as error, so that
we can parse it while testing layouts.
Can you tell me more about how this works? I did not try the cmake side
of things. From what I read, you parse the stderr output and assume an
Am Samstag, 13. Juli 2019, 19:57:29 CEST schrieb Jean-Marc Lasgouttes:
> While running tests I get this for layouts:
>
> Testing ./../lib/layouts/acmart.layout...
> TextClass.cpp (1533): The layout does not provide a list command for the
> float `sidebar'. LyX will not be able to produce a float
On Tue, Sep 04, 2018 at 12:23:34PM -0400, Richard Kimberly Heck wrote:
> On 09/04/2018 11:04 AM, Scott Kostyshak wrote:
> > On Tue, Sep 04, 2018 at 02:03:45PM +0200, Uwe Stöhr wrote:
> >> Am 29.08.2018 um 03:30 schrieb Uwe Stöhr:
> >>
> >>> I hope this issue will be fixed soon and report back.
> >>
On 09/04/2018 11:04 AM, Scott Kostyshak wrote:
> On Tue, Sep 04, 2018 at 02:03:45PM +0200, Uwe Stöhr wrote:
>> Am 29.08.2018 um 03:30 schrieb Uwe Stöhr:
>>
>>> I hope this issue will be fixed soon and report back.
>> Status report: The problem persists. The fix for MiKTeX was already released
>> bu
On Tue, Sep 04, 2018 at 02:03:45PM +0200, Uwe Stöhr wrote:
> Am 29.08.2018 um 03:30 schrieb Uwe Stöhr:
>
> > I hope this issue will be fixed soon and report back.
>
> Status report: The problem persists. The fix for MiKTeX was already released
> but the main update server of MiKTeX is down. One c
Am 29.08.2018 um 03:30 schrieb Uwe Stöhr:
I hope this issue will be fixed soon and report back.
Status report: The problem persists. The fix for MiKTeX was already
released but the main update server of MiKTeX is down. One cannot
retrieve any update yet, no matter what update server is chose
On 29/08/2018 1:30 p.m., Uwe Stöhr wrote:
Dear LyX Windows users,
yesterday I noticed a severe bug in the LaTeX system "MiKTeX" that LyX
is usually using under Windows. The problem is that if you
- upgrade MiKTeX or LyX
or
- install a new LaTeX package
or
- refresh the MiKTeX package databa
Am Dienstag, 18. April 2017 um 01:43:30, schrieb Uwe Stöhr
> El 17.04.2017 a las 22:04, Kornel Benko escribió:
>
> > It may be that the python output is not in the messages pane, only messages
> > created by lyx executable.
> > I am in favour of bug report.
>
> I reported a bug:
> http://www.ly
On Mon, Apr 17, 2017 at 08:33:04AM +0200, Kornel Benko wrote:
> Am Montag, 17. April 2017 um 05:04:29, schrieb Uwe Stöhr
> > El 17.04.2017 a las 04:40, Scott Kostyshak escribió:
> >
> > > I tested just "PDF-form" tests and the ones that were failing pass now.
> > > Thanks for the fixes.
> >
> >
El 17.04.2017 a las 22:04, Kornel Benko escribió:
It may be that the python output is not in the messages pane, only messages
created by lyx executable.
I am in favour of bug report.
I reported a bug:
http://www.lyx.org/trac/ticket/10628
However, I am stuck. open the attached LyX file (which
Am Montag, 17. April 2017 um 21:15:12, schrieb Uwe Stöhr
> El 17.04.2017 a las 19:41, Kornel Benko escribió:
>
> > Confirmed. Thanks Uwe.
>
> Thank you. I'll send the patch for LyX 2.2 now.
>
> Nevertheless I could not get all the errors/warnings you got with
>
> lyx -e lyx16x PDF-form.lyx
> l
El 17.04.2017 a las 19:41, Kornel Benko escribió:
Confirmed. Thanks Uwe.
Thank you. I'll send the patch for LyX 2.2 now.
Nevertheless I could not get all the errors/warnings you got with
lyx -e lyx16x PDF-form.lyx
lyx -batch PDF-form.16.lyx
In only got the Lexer.cpp warnings which led me to
Am Montag, 17. April 2017 um 19:20:32, schrieb Uwe Stöhr
> El 17.04.2017 a las 18:14, Uwe Stöhr escribió:
>
> > There is however an error in a conversion routine from 1.6.x to 2.0x
> > because the length \totalheight is mangled. Therefore the opened file
> > fails to compile to a PDF.
>
> This
El 17.04.2017 a las 18:14, Uwe Stöhr escribió:
There is however an error in a conversion routine from 1.6.x to 2.0x
because the length \totalheight is mangled. Therefore the opened file
fails to compile to a PDF.
This bug is now also fixed:
http://www.lyx.org/trac/changeset/bc0591a2/lyxgit
N
Am Montag, 17. April 2017 um 18:14:41, schrieb Uwe Stöhr
> El 17.04.2017 a las 08:33, Kornel Benko escribió:
>
> >> LyX is made for users. It is impossible to use PDF forms in LyX < 2.1 so
> >> there won't be users. Therefore testing this file export to LyX 1.6 is
> >> senseless.
> >
> > Makes s
El 17.04.2017 a las 08:33, Kornel Benko escribió:
LyX is made for users. It is impossible to use PDF forms in LyX < 2.1 so
there won't be users. Therefore testing this file export to LyX 1.6 is
senseless.
Makes sense.
Therefore I opt to remove the test for LyX 1.6x and 2.0x for PDF-form
and
Am Montag, 17. April 2017 um 05:04:29, schrieb Uwe Stöhr
> El 17.04.2017 a las 04:40, Scott Kostyshak escribió:
>
> > I tested just "PDF-form" tests and the ones that were failing pass now.
> > Thanks for the fixes.
>
> Thanks. I'll send the patch for branch then.
>
> > In the above, what does
El 17.04.2017 a las 04:40, Scott Kostyshak escribió:
I tested just "PDF-form" tests and the ones that were failing pass now.
Thanks for the fixes.
Thanks. I'll send the patch for branch then.
In the above, what does "a valid document which can be read by an
older LyX" mean? Does it just mean
On Mon, Apr 17, 2017 at 04:19:13AM +0200, Uwe Stöhr wrote:
> El 16.04.2017 a las 23:50, Uwe Stöhr escribió:
>
> > My today's change in PDF-form.lyx where I use 2 nested colored boxes
> > bring the new warning you see. I'll fix this lyx2lyx issue.
>
> I fixed it now:
> www.lyx.org/trac/changeset/
El 16.04.2017 a las 23:50, Uwe Stöhr escribió:
My today's change in PDF-form.lyx where I use 2 nested colored boxes
bring the new warning you see. I'll fix this lyx2lyx issue.
I fixed it now:
www.lyx.org/trac/changeset/5b4cc6b6/lyxgit
In fact I had to rewrite the whole colorbox routine and e
El 16.04.2017 a las 23:41, Uwe Stöhr escribió:
I'll have a look.
My today's change in PDF-form.lyx where I use 2 nested colored boxes
bring the new warning you see. I'll fix this lyx2lyx issue.
regards Uwe
El 16.04.2017 a las 19:12, Kornel Benko escribió:
Should we ignore this messages?
No because this means there is a bug in the lyxl2yx conversion routine.
You get this when creating the 21 file and then opening with LyX 2.3,
right? Do you also get the same error when opening with LyX 2.2?
I
On Sun, Apr 16, 2017 at 07:12:23PM +0200, Kornel Benko wrote:
> #ctest export/examples/PDF-form_lyx21
> shows this message on stderr:
>
> -- check structures of PDF-form.21.lyx
> -- Executing /BUILD/BUILDMint17/BuildLyxGitQt5.9alpha-gcc6.2/bin/lyx2.3
> -userdir "/BUILD/BUILDMint17/BuildLyxGitQt5
Le 24/02/2016 18:32, Jean-Pierre Chrétien a écrit :
Hello,
When I open either the UserGuide or the Math manual (in English or in
French), I get this in the calling command window:
Warning: Failed to produce 1 preview snippet(s)
I don't think so.
Is this a serious problem ?
Any clue to find
Am 12.05.2015 um 11:01 schrieb Jean-Marc Lasgouttes:
It seem that there is another parenthesing problem. I won't touch it
because I do not know what the intended logic is.
Thanks JMarc,
I improved the logic in
http://www.lyx.org/trac/changeset/858c12c6bb850b7ed7a708e3e66fd58ba6f06cb9/lyxgit
On Fri, Jun 7, 2013 at 11:45 AM, Richard Heck wrote:
> On 06/06/2013 05:30 PM, Scott Kostyshak wrote:
>>
>> Inside float and note insets (and others I'm guessing), if I do a
>> return when I'm not supposed to, I get the following:
>>
>> frontends/qt4/LayoutBox.cpp (564): Trying to select non exi
On 06/06/2013 05:30 PM, Scott Kostyshak wrote:
Inside float and note insets (and others I'm guessing), if I do a
return when I'm not supposed to, I get the following:
frontends/qt4/LayoutBox.cpp (564): Trying to select non existent
layout type Standard
I expected to get nothing, which is what
On 01/10/2011 07:46 AM, Stephan Witt wrote:
Am 10.01.2011 um 01:06 schrieb Pavel Sanda:
Abdel,
CXXUndo.o
Undo.cpp: In member function 'void lyx::Undo::clear()':
Undo.cpp:250: warning: statement has no effect
pavel
I'd say it looks like a real problem.
Just commit the fix then :-)
Am 10.01.2011 um 01:06 schrieb Pavel Sanda:
> Abdel,
> CXXUndo.o
> Undo.cpp: In member function 'void lyx::Undo::clear()':
> Undo.cpp:250: warning: statement has no effect
> pavel
I'd say it looks like a real problem.
Stephan
Index: src/Undo.cpp
==
On 03/31/2010 04:21 PM, Pavel Sanda wrote:
1. new file
2. insert child doc, eg Additional.lyx
3. console output:
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: th
John McCabe-Dansted wrote:
> 1) The buffer is not dirty: then this isn't really a problem, the user
> might not even intend to edit the document.
> 2) The buffer is dirty: It is too late to avoid the need for a merge;
> a merge will be required anyway. notifying the user earlier rather
> than later
On Thu, Mar 4, 2010 at 3:21 PM, Pavel Sanda wrote:
> John McCabe-Dansted wrote:
>> On Thu, Mar 4, 2010 at 6:05 AM, Pavel Sanda wrote:
>> > John McCabe-Dansted wrote:
>> >> Below I present very preliminary support for warning the user when
>> >> their LyX file is externally modified. Does the foll
John McCabe-Dansted wrote:
> On Thu, Mar 4, 2010 at 6:05 AM, Pavel Sanda wrote:
> > John McCabe-Dansted wrote:
> >> Below I present very preliminary support for warning the user when
> >> their LyX file is externally modified. Does the following approach
> >> sound worthwhile?
> >
> > this has eve
On Thu, Mar 4, 2010 at 6:05 AM, Pavel Sanda wrote:
> John McCabe-Dansted wrote:
>> Below I present very preliminary support for warning the user when
>> their LyX file is externally modified. Does the following approach
>> sound worthwhile?
>
> this has even some bug number. the reason why its not
John McCabe-Dansted wrote:
> Below I present very preliminary support for warning the user when
> their LyX file is externally modified. Does the following approach
> sound worthwhile?
this has even some bug number. the reason why its not implementeed
yet is that its not easy to find a point where
On Sun, Jan 3, 2010 at 9:14 PM, Pavel Sanda wrote:
> hehehe. you should really try to use it in a real life. just consider we are
> having different header for lyx 1.6.4, lyx 1.6.5, so single resave will do MC
Then there are all the hundreds of changes to open/close insets. I get
this even with a
we are going to the endless flame, ...
No we're not, I was just wondering whether I was really supposed to
count the rain drops while my colleagues are writing... ;-) I have no
problems with that.
pavel
Vincent
Vincent van Ravesteijn wrote:
>> the only way how to reasonably avoid merge conflicts which are
>> unresolvable by
>> the normal user.
>
> That's why my colleagues just send me the new file: "If you want to do
> version control, well here is the file and commit it then".
well, the point was that
Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
It feels like it is a bit too specific to have a new rc value just for
showing a warning that only effects a specific case that I don't even
understand that can only happen when using a feature which is probably only
used by you.
i s
Vincent van Ravesteijn wrote:
> It feels like it is a bit too specific to have a new rc value just for
> showing a warning that only effects a specific case that I don't even
> understand that can only happen when using a feature which is probably only
> used by you.
i still hope there is (or w
Pavel Sanda schreef:
hi,
i would like to introduce new rc for some kind of pop-up (unset by default)
which would
warn about unreleased file lock when working with version control.
any objections?
pavel
It feels like it is a bit too specific to have a new rc value just for
showing a warning
Pavel Sanda schreef:
currently i see
GuiImage.cpp: In member function 'bool lyx::graphics::GuiImage::scale(const
lyx::graphics::Params&)':
GuiImage.cpp:168: warning: comparison of unsigned expression < 0 is always false
which is because
unsigned int scale;
if (params.scale < 0 || pa
Kornel Benko writes:
> ...
> /usr/src/lyx/lyx-devel/src/Counters.cpp:157: warning: control reaches end of
> non-void function
> ...
>
> In trunk. It may not harm, but should return the corect value.
I wonder why my compiler did not slap me on the hand. It is so
obvious...
Thanks.
JMarc
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
>
> > this is in current branch & qt 4.4.2:
> >
> > /usr/bin/uic -tr lyx::qt_ ui/ExternalUi.ui -o ui_ExternalUi.h
> > Warning: name gridLayout is already used
> > 'displayscaleLA' isn't a valid widget
>
> better now?
yes
pavel
Pavel Sanda wrote:
> this is in current branch & qt 4.4.2:
>
> /usr/bin/uic -tr lyx::qt_ ui/ExternalUi.ui -o ui_ExternalUi.h
> Warning: name gridLayout is already used
> 'displayscaleLA' isn't a valid widget
better now?
Jürgen
Bo Peng wrote:
When I open documents using the current trunk, I see a lot of
Warning: Malformed LyX document: No \end_modules.
Should be OK now.
rh
Bo Peng wrote:
When I open documents using the current trunk, I see a lot of
Warning: Malformed LyX document: No \end_modules.
My fault. I'm on it.
rh
> Uwe, could you have a look please?
This was a copy paste error that I've overseen. It's now fixed.
thanks and regards
Uwe
On Fri, Aug 17, 2007 at 02:25:14PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Fri, Aug 17, 2007 at 02:08:17PM +0200, Abdelrazak Younes wrote:
> >> Martin Vermeer wrote:
> >>> On Fri, Aug 17, 2007 at 11:00:07AM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >
Enrico Forestieri wrote:
On Fri, Aug 17, 2007 at 02:08:17PM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Fri, Aug 17, 2007 at 11:00:07AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
Martin,
This is f
On Fri, Aug 17, 2007 at 02:08:17PM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> > On Fri, Aug 17, 2007 at 11:00:07AM +0200, Abdelrazak Younes wrote:
> >> Martin Vermeer wrote:
> >>> On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
> Martin,
>
> This
Martin Vermeer wrote:
On Fri, Aug 17, 2007 at 11:00:07AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
Martin,
This is for you I guess:
src\insets\insetcollapsable.cpp(71) : warning C4715:
'lyx::InsetCollapsable
On Fri, Aug 17, 2007 at 11:00:07AM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> > On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
> >> Martin,
> >>
> >> This is for you I guess:
> >>
> >> src\insets\insetcollapsable.cpp(71) : warning C4715:
> >> 'lyx::InsetColl
Martin Vermeer wrote:
On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
Martin,
This is for you I guess:
src\insets\insetcollapsable.cpp(71) : warning C4715:
'lyx::InsetCollapsable::geometry' : not all control paths return a value
Abdel.
Yes, I am getting that too: c
On Fri, Aug 17, 2007 at 09:22:16AM +0200, Abdelrazak Younes wrote:
> Martin,
>
> This is for you I guess:
>
> src\insets\insetcollapsable.cpp(71) : warning C4715:
> 'lyx::InsetCollapsable::geometry' : not all control paths return a value
>
> Abdel.
Yes, I am getting that too: control reac
Stefan Schimanski wrote:
The attached patch fixes that. It should fix also a number of other
situation where cursor may be invalidated.
I had to add a test in Cursor::fixIfBroken() for the case were we are
not inside an Inset but in the main Text.
Nice! Testing it for a few minutes now. Looks
The attached patch fixes that. It should fix also a number of other
situation where cursor may be invalidated.
I had to add a test in Cursor::fixIfBroken() for the case were we
are not inside an Inset but in the main Text.
Nice! Testing it for a few minutes now. Looks fine. Couldn't cause a
Stefan Schimanski wrote:
Am 23.05.2007 um 11:34 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck
<[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do
Richard> now have multiple views, either there is a bug here or else
Ric
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do now
Richard> have multiple views, either there
Stefan Schimanski wrote:
Am 23.05.2007 um 11:34 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck
<[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do
Richard> now have multiple views, either there is a bug here or else
Ric
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Put text "abcde" in two windows. Put the cursor of window 2 in
Stefan> the middle of the text. Select the text in window 2 and delete
Stefan> it. The cursor in window 2 is now invalid. Switch to Window 2
Stefan> and crash!
Ou
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>>> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>>
Richard> This is from Text2.cpp, around line 1220. Since we do now
Richard> have multiple views, either there is a bug here o
Michael Gerz wrote:
> E.g., when I tried to fix #3160 (sorry, fix is still pending - I am very
> busy these days :-( ), I noticed that a proper solution would drop DEPM
> support (including double-space deletion, leading space deletion). This
> can lead to ugly cases with empty paragraphs.
>
> IM
Am 23.05.2007 um 11:34 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do
Richard> now have multiple views, either there is a bug here or else
Richard> the warning can be r
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do
Richard> now have multiple views, either there is a bug here or else
Richard> the warning can be removed.
I think we have a bug, but it is not easy t
Jean-Marc Lasgouttes schrieb:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> With multiple views every edit gets kind of global because
Stefan> some other cursor can be inside the edited inset.
Stefan> I guess there is no infra structure in place for all that,
Stefan> right
On Tue, May 22, 2007 at 09:58:58AM +0200, Jean-Marc Lasgouttes wrote:
> > "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>
> Stefan> With multiple views every edit gets kind of global because
> Stefan> some other cursor can be inside the edited inset.
>
> Stefan> I guess there is n
Andre Poenitz wrote:
On Mon, May 21, 2007 at 05:59:45PM -0400, Richard Heck wrote:
Just wanted to bring this to people's attention:
#ifdef WITH_WARNINGS
#warning This will not work anymore when we have multiple views of the
same buffer
// In this case, we will have to correct also the cursors he
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> With multiple views every edit gets kind of global because
Stefan> some other cursor can be inside the edited inset.
Stefan> I guess there is no infra structure in place for all that,
Stefan> right? I had trouble with exactly
Do I see it correctly that there are two cases of cursor updates:
local edits around the cursor, partly from inside the cursor class;
global edits (e.g. search/replace). The latter must check that the
cursor is not inside the area that is changed. Otherwise the cursor
is invalidated or must
Andre Poenitz wrote:
> On Mon, May 21, 2007 at 05:59:45PM -0400, Richard Heck wrote:
>
>> Just wanted to bring this to people's attention:
>> #ifdef WITH_WARNINGS
>> #warning This will not work anymore when we have multiple views of the
>> same buffer
> Do we officially have multiple views now?
On Mon, May 21, 2007 at 05:59:45PM -0400, Richard Heck wrote:
>
> Just wanted to bring this to people's attention:
> #ifdef WITH_WARNINGS
> #warning This will not work anymore when we have multiple views of the
> same buffer
> // In this case, we will have to correct also the cursors held by
> //
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> This is from Text2.cpp, around line 1220. Since we do
Richard> now have multiple views, either there is a bug here or else
Richard> the warning can be removed.
I think we have a bug, but it is not easy to trigger :)
It goes lik
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Lars,
| > Could you please check in your changes to my branch so that we can
| > merge the branch to trunk?
| > IMHO, I believe qt4 and qt3 are fully functional now s
I resolved my svn problem and I am going to check in now!
Abdel.
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hello,
I am going to merge my branch now so please wait for a few minutes if
you want to commit something that touches the GUI API cleanup work.
I will wait until tomorrow be
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Hello,
| > I am going to merge my branch now so please wait for a few minutes
| > if you want to commit something that touches the GUI API cleanup
| > work.
|
| I will wait until tomorrow because I need to find out how r
Abdelrazak Younes wrote:
Hello,
I am going to merge my branch now so please wait for a few minutes if
you want to commit something that touches the GUI API cleanup work.
I will wait until tomorrow because I need to find out how renamed files
are handled when you do a merging. Right now I see
1 - 100 of 152 matches
Mail list logo
