VCBackend::SVN code

Pavel, I had a look at the locking code (because of bug #6433), but I have some questions. Typo ? : void SVN::scanMaster() { locker_.clear(); vcstatus = NOLOCKING; if (checkLockMode()) { if (isLocked()) { locker_ = "Locked"; vcstatus = LOCKED; } el

Re: #6430: Run BibTeX on every .aux-file for biblatex option "refsection=chapter"

Hello Jürgen, thank you for the hint with the workaround! I would be glad if you could explain, where to put the script in the path. Would, on OSX, library>texmf>tex>latex be fine? Or has it got to be in the usr- folder, in temf-dist, where I also could find a bibtex-folder? Would it be ex

Re: About the new Debug Window

Am Dienstag, den 05.01.2010, 15:12 +0100 schrieb Abdelrazak Younes: > Vincent van Ravesteijn - TNW wrote: > > > > > >> Pavel, Peter, > >> > >> Shouldn't the "All debug" and "No debug" be in radio buttons > >> instead? I guess I'd like to have 3 radio buttons: > >> > >> * All debug > >> * No de

LyXAction.cpp Question

Not that it's a big deal, but it seems a bit of a waste to have both lyx_func_map and lyx_info_map here, since lyx_info_map actually contains the info that lyx_func_map does. The changes needed if we eliminate lyx_func_map seem pretty minor, too. Anyone know of a reason not to do this? I thi

Re: r32770 - lyx-devel/trunk/src

On 01/05/2010 12:17 PM, Jean-Marc Lasgouttes wrote: rgh...@lyx.org writes: Author: rgheck Date: Tue Jan 5 16:01:32 2010 New Revision: 32770 URL: http://www.lyx.org/trac/changeset/32770 Log: Kill warning: string::npos was the wrong type, and does not reflect what max is supposed to be. JM

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On Tue, Jan 05, 2010 at 06:10:03PM +0100, Jean-Marc Lasgouttes wrote: > "Vincent van Ravesteijn - TNW" writes: > > So, why are we discussing it then .. Because we need it ? > > > > Isn't the use of cur.dispatched(), cur.undispatched(), > > cur.result().dispatched() basically a work-around for miss

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On 01/05/2010 10:58 AM, Vincent van Ravesteijn - TNW wrote: I'd also want to figure out some way to allow just the DispatchResult member to be modified, even when FuncRequest is const. You mean you want to declare it "mutable" ? That is one possibility, though the way Tomasso ha

Re: r32771 - lyx-devel/trunk/src

rgh...@lyx.org writes: > By the way, this is extremely inefficient. We have e.g. this code in > Buffer.cpp: > string target = func.getArg(0); > string target_name = func.getArg(1); > string command = func.getArg(2); > As a result, we parse the argument string three times! It seems

Re: r32770 - lyx-devel/trunk/src

rgh...@lyx.org writes: > Author: rgheck > Date: Tue Jan 5 16:01:32 2010 > New Revision: 32770 > URL: http://www.lyx.org/trac/changeset/32770 > > Log: > Kill warning: string::npos was the wrong type, and does not reflect what > max is supposed to be. > > JMarc: I assume you are intending to use th

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

"Vincent van Ravesteijn - TNW" writes: > So, why are we discussing it then .. Because we need it ? > > Isn't the use of cur.dispatched(), cur.undispatched(), > cur.result().dispatched() basically a work-around for missing the > DispatchResult which only works in places where there is a Cursor > av

RE: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

>>> 3) let the LFUN dispatch in lyxfind.cpp return the required >>> information (match position and length) to the caller; for example, >>> by means of a DispatchResult sub-class (any strong objection to >>> adding a "DispatchResult &" to some of the existing ::dispatch() >>> methods? >>> >> I

RE: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

>I'd also want to figure out some way to allow just the >DispatchResult member to be modified, even when FuncRequest >is const. You mean you want to declare it "mutable" ? Vincent

Re: #4065: Support BibLaTeX

Jürgen Spitzmüller wrote: I think so, yes. AFAICS trac has no notion of dependencies at all (maybe there's a plugin for that, though). perhaps this http://trac-hacks.org/wiki/MasterTicketsPlugin

Re: #4065: Support BibLaTeX

Jürgen Spitzmüller writes: > Jürgen Spitzmüller wrote: >> I think so, yes. AFAICS trac has no notion of dependencies at all (maybe >> there's a plugin for that, though). > > http://trac-hacks.org/wiki/TracDependencyPlugin This looks very complicated. JMarc

FuncRequest::getArg()

I probably should just have sent this to the list: By the way, [FuncRequest::getArg()] is extremely inefficient. We have e.g. this code in Buffer.cpp: string target = func.getArg(0); string target_name = func.getArg(1); string command = func.getArg(2); As a result, we pa

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On 01/05/2010 09:12 AM, Tommaso Cucinotta wrote: Tommaso Cucinotta wrote: 3) let the LFUN dispatch in lyxfind.cpp return the required information (match position and length) to the caller; for example, by means of a DispatchResult sub-class (any strong objection to adding a "DispatchRes

Re: For branch ?

On 01/05/2010 09:36 AM, Abdelrazak Younes wrote: Vincent van Ravesteijn - TNW wrote: I think it was there just because people didn't see why dialogs that don't apply to read-only documents should be updated. The bug was found by Bo: In e.g. the User Guide, you might want to right click on a

Re: For branch ?

"Vincent van Ravesteijn - TNW" writes: > I felt like it was put there for some reason, so I searched through > the svn history to find out when and where it was introduced. However, > the code was moved a few times around and it seems that this specific > line was there forever. It might be some

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

rgheck writes: > On 01/04/2010 06:37 PM, Tommaso Cucinotta wrote: >> 3) let the LFUN dispatch in lyxfind.cpp return the required >> information (match position and length) to the caller; for example, >> by means of a DispatchResult sub-class (any strong objection to >> adding a "DispatchResult &"

Re: For branch ?

Vincent van Ravesteijn - TNW wrote: I think it was there just because people didn't see why dialogs that don't apply to read-only documents should be updated. The bug was found by Bo: In e.g. the User Guide, you might want to right click on an InsetInfo to see the cor

RE: For branch ?

>>> I think it was there just because people didn't see why dialogs that >>> don't apply to read-only documents should be updated. The bug was >>> found by Bo: In e.g. the User Guide, you might want to right click on >>> an InsetInfo to see the corresponding data, even though you can't change it

Re: For branch ?

On 01/05/2010 08:50 AM, Jürgen Spitzmüller wrote: rgheck wrote: I think it was there just because people didn't see why dialogs that don't apply to read-only documents should be updated. The bug was found by Bo: In e.g. the User Guide, you might want to right click on an InsetInfo to see the

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

Tommaso Cucinotta wrote: 3) let the LFUN dispatch in lyxfind.cpp return the required information (match position and length) to the caller; for example, by means of a DispatchResult sub-class (any strong objection to adding a "DispatchResult &" to some of the existing ::dispatch() method

Re: About the new Debug Window

Vincent van Ravesteijn - TNW wrote: Pavel, Peter, Shouldn't the "All debug" and "No debug" be in radio buttons instead? I guess I'd like to have 3 radio buttons: * All debug * No debug * Custom debug Choosing the first two would disable all checkboxes and choosing the last one will enable

RE: About the new Debug Window

>Pavel, Peter, > >Shouldn't the "All debug" and "No debug" be in radio buttons >instead? I guess I'd like to have 3 radio buttons: > >* All debug >* No debug >* Custom debug > >Choosing the first two would disable all checkboxes and >choosing the last one will enable them. >From the r32764 threa

RE: For branch ?

>> I agree on the fix in general, it's just that the condition strikes me >> as if it was put there intentionally in order to prevent some specific >> behaviour (other than just updating the dialog). >> > >Or this framework was just a big pile of bugs and I just didn't know >what to do with th

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

rgheck wrote: On 01/05/2010 08:54 AM, Abdelrazak Younes wrote: The multi-file search need not be, but could call that LFUN repeatedly. Or rather call the Buffer method. Because we don't want to create a BufferView for that search. Or we could also duplicate LFUN_FINDADV in Buffer in addtio

Re: #4065: Support BibLaTeX

Jürgen Spitzmüller wrote: > I think so, yes. AFAICS trac has no notion of dependencies at all (maybe > there's a plugin for that, though). http://trac-hacks.org/wiki/TracDependencyPlugin Jürgen

About the new Debug Window

Pavel, Peter, Shouldn't the "All debug" and "No debug" be in radio buttons instead? I guess I'd like to have 3 radio buttons: * All debug * No debug * Custom debug Choosing the first two would disable all checkboxes and choosing the last one will enable them. Abdel.

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On 01/05/2010 08:54 AM, Abdelrazak Younes wrote: The multi-file search need not be, but could call that LFUN repeatedly. Or rather call the Buffer method. Because we don't want to create a BufferView for that search. Or we could also duplicate LFUN_FINDADV in Buffer in addtion to BufferView

Re: For branch ?

Abdelrazak Younes wrote: > Or this framework was just a big pile of bugs and I just didn't know > what to do with these tests at the time... IOW Vincent is most probably > correct :-) OK then. Jürgen

Re: For branch ?

Jürgen Spitzmüller wrote: rgheck wrote: I think it was there just because people didn't see why dialogs that don't apply to read-only documents should be updated. The bug was found by Bo: In e.g. the User Guide, you might want to right click on an InsetInfo to see the corresponding data, ev

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

rgheck wrote: On 01/05/2010 08:44 AM, Abdelrazak Younes wrote: Tommaso Cucinotta wrote: Abdelrazak Younes wrote: You can use the paragraph id and the position in that paragraph. Else there is the StableDocIterator IIRC. I can see operator<<() but not operator>>(), both for StableDocIterator a

Re: #4065: Support BibLaTeX

rgheck wrote: > Is this the only way to handle dependencies in trac? That's the one > thing I miss about bugzilla. I think so, yes. AFAICS trac has no notion of dependencies at all (maybe there's a plugin for that, though). I've put it in the description, because separate comments tend to get

Re: #4065: Support BibLaTeX

On 01/05/2010 08:39 AM, LyX Ticket Tracker wrote: #4065: Support BibLaTeX -+-- Reporter: rgheck |Owner: rgheck Type: enhancement | Status: new Priority: low |Milestone: Compone

Re: For branch ?

rgheck wrote: > I think it was there just because people didn't see why dialogs that > don't apply to read-only documents should be updated. The bug was found > by Bo: In e.g. the User Guide, you might want to right click on an > InsetInfo to see the corresponding data, even though you can't cha

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On 01/05/2010 08:44 AM, Abdelrazak Younes wrote: Tommaso Cucinotta wrote: Abdelrazak Younes wrote: You can use the paragraph id and the position in that paragraph. Else there is the StableDocIterator IIRC. I can see operator<<() but not operator>>(), both for StableDocIterator and for CursorSl

Re: For branch ?

On 01/05/2010 05:55 AM, Jürgen Spitzmüller wrote: Vincent van Ravesteijn - TNW wrote: New Revision: 32694 URL: http://www.lyx.org/trac/changeset/32694 Log: Update the view also when the document is read-onl

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

Tommaso Cucinotta wrote: Abdelrazak Younes wrote: You can use the paragraph id and the position in that paragraph. Else there is the StableDocIterator IIRC. I can see operator<<() but not operator>>(), both for StableDocIterator and for CursorSlice. I guess the operator<<()s are there just for

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

On 01/04/2010 06:37 PM, Tommaso Cucinotta wrote: 3) let the LFUN dispatch in lyxfind.cpp return the required information (match position and length) to the caller; for example, by means of a DispatchResult sub-class (any strong objection to adding a "DispatchResult &" to some of the existing ::

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

Abdelrazak Younes wrote: You can use the paragraph id and the position in that paragraph. Else there is the StableDocIterator IIRC. I can see operator<<() but not operator>>(), both for StableDocIterator and for CursorSlice. I guess the operator<<()s are there just for debugging purposes, not r

Re: For branch ?

Vincent van Ravesteijn - TNW wrote: > New Revision: 32560 > URL: > http://www.lyx.org/trac/changeset/32560 > > Log: Correctly paint the background of the instant preview of a > displayed equation. pen

Re: Branch won't link: Mac 10.6

Anders Ekberg wrote: > > BH wrote: > >> I've just upgraded from Mac 10.5 to 10.6. Trunk compiles fine, but > >> branch gives me this error: > > > > > > Is this issue still relevant? > > > > Jürgen > > Yes. Still the same crash. So we should record this on trac, probably. Jürgen

Re: Building LyX from shared libraries

Manoj Rajagopalan wrote: Hi developers, I just successfully completed an experiment with using libtool to build all LyX component libraries as shared libraries and building the lyx executable to link with these instead of the static libs. Is this something that might be worth submitting? W

Re: Building LyX from shared libraries

Manoj Rajagopalan wrote: There is no explanation for why libtool was removed last year. Does anyone know? Because it slows down compilation a lot. Abdel.

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

Tommaso Cucinotta wrote: Vincent van Ravesteijn - TNW wrote: This is not only caused by the fact that you're using LFUN_BUFFER_SWITCH instead of GuiView::setBuffer, but also by the fact that you now call LFUN_FINDADV for each buffer, so it will be shown anyway when dispatching this LFUN. If you