Re: A Cygwin related patch

Georg Baum <[EMAIL PROTECTED]> writes: > > Enrico Forestieri wrote: > > > Really? I had thought the second one was more cleaner. Actually I had to > > figure out that when latex_path() is called for generating the argument > > of \input path it is assumed that a trailing / is present, and the >

Re: A Cygwin related patch

Enrico Forestieri wrote: > Trailing, not heading /. But it seems I was misunderstanding the code. And I was misunderstanding your post :-( >> I am not really sure how things work on cygwin. Can we always assume that >> all external paths are either windows or posix style? Or do we need posix >>

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

> > src/lastfiles.C: > > I do not want to change the Files structure so I use a map to store > > position information. lastfile format is changed to " > > filename" if position information is available, and "filename" if not. > > Would it be easier to always have the filename

Re: [PATCH] update vs repaint

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> There was a consensus that this patch is the right thing to Jean-Marc> do, even though it might not speed things up per se. I Jean-Marc> tested it and propose to apply to trunk and branch. I applied it. JMarc

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Anyway, I have an additional patch for this bug. Anyone Jean-Marc> disagrees? Applied. JMarc

[PATCH] bug 2217: getting out of mathed is slow

I would like to apply the following to branch and trunk. Any objection? To recap, what it does is restrict bruteFind to search only in the paragraphs that are in the coordcache. The old code searched through the whole document but acted only on the paragraphs in the coordcache (the test for

[PATCH] bug 675: cannot insert a graphics in a caption

http://bugzilla.lyx.org/show_bug.cgi?id=675 As discussed in the bug, this "fixes" the bug by making graphics in caption generate proper latex (with \protect). It is then up to the user to realize that the graphics is in the wrong place (note that there may be proper reason for inserting a

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

An updated patch that loads all position information while keeping only num_files Files entries. Question: is 0 a valid paragraph ID? I currently use -1 to indicate invalid ID. Bo Index: src/BufferView_pimpl.C === ---

Re: Feature request: Remember the editing location when a file is closed.

Jose' Matos <[EMAIL PROTECTED]> writes: | On Wednesday 22 March 2006 22:44, [EMAIL PROTECTED] wrote: | > On Wed, 22 Mar 2006, Bo Peng wrote: | > > Dear list, | > > | > > I am not sure if others will like this idea. When I edit a long file, | > > it may be troublesome to locate and continue from

Re: [PATCH] bug 2217: getting out of mathed is slow

On Thu, Mar 23, 2006 at 03:08:16PM +0100, Jean-Marc Lasgouttes wrote: > > I would like to apply the following to branch and trunk. Any > objection? > > To recap, what it does is restrict bruteFind to search only in the > paragraphs that are in the coordcache. The old code searched through > the

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | Dear list, | | It does not look so difficult to implement this feature so I tried to | implement it by myself. Attached is my patch. Since I rarely submit a | patch here so I am afraid that there might be many problems (format, | logic, bugs). Please have

Re: [PATCH] bug 675: cannot insert a graphics in a caption

On Thu, Mar 23, 2006 at 03:24:55PM +0100, Jean-Marc Lasgouttes wrote: > > http://bugzilla.lyx.org/show_bug.cgi?id=675 > > As discussed in the bug, this "fixes" the bug by making graphics in > caption generate proper latex (with \protect). > > It is then up to the user to realize that the

Re: A Cygwin related patch

Georg Baum <[EMAIL PROTECTED]> writes: | Enrico Forestieri wrote: | | > The attached patch fixes the bug reported here: | > http://thread.gmane.org/gmane.editors.lyx.general/29227 | > | > In my intention this is the first of a series of patches aimed at | > polishing the Cygwin target, which I

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

Helge Hafting <[EMAIL PROTECTED]> writes: | John McCabe-Dansted wrote: | | >>John> If LyX locked files which were open in a still running LyX | >>John> process, that would have saved me some confusion. | >> | >>Yes, but I am sure this can cause a lot of confusion too... | >> | > | >I am not sure

Re: A Cygwin related patch

Lars Gullik Bjønnes wrote: > I feel the exact opposite. the cygwin_path_fix pollutes the "portable" > code, pollutes the "not cygwin files" But it makes it explicit why external_path() is needed. > The second patch is the nice one IMO. Now I don't like either anymore. The problem of both

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | An updated patch that loads all position information while keeping | only num_files Files entries. | | Question: is 0 a valid paragraph ID? I currently use -1 to indicate | invalid ID. As said, I'd prefere a separate file in .lyx/; but even if I didn't:

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Please have a look at how emacs does this. (I am in favor of the Lars> 'when in doubt do as emacs' camp.) It uses a ~/.emacs-places file which contains a list of files and offsets. JMarc

Re: A Cygwin related patch

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Now I don't like either anymore. The problem of both fixes is Georg> that they use a trailing '/' as flag whether external_path() is Georg> needed or not. This will strike back sooner or later. Sure, this is not good. Is the problem

Re: [PATCH] bug 2217: getting out of mathed is slow

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Thu, Mar 23, 2006 at 03:08:16PM +0100, Jean-Marc Lasgouttes Martin> wrote: >> I would like to apply the following to branch and trunk. Any >> objection? >> >> To recap, what it does is restrict bruteFind to search only in

Re: [PATCH] bug 2217: getting out of mathed is slow

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> OK, since you insist, I'll attach it :) Wrong one. I need sleep. JMarc Index: src/cursor.C === --- src/cursor.C (revision 13257) +++ src/cursor.C

Re: [PATCH] bug 2217: getting out of mathed is slow

On Thu, Mar 23, 2006 at 04:52:10PM +0100, Jean-Marc Lasgouttes wrote: > > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > Jean-Marc> OK, since you insist, I'll attach it :) > > Wrong one. I need sleep. > > JMarc This is the one that I tested, right? - Martin

Re: Problem compiling Lyx 1.4. svn

Charles de Miramon wrote: Before make, type export CC=gcc-3.3 export CXX=g++-3.3 Nice! For 1.5, this also works with export CC=gcc-4.1 export CXX=g++-4.1 gcc/g++ version 4.1 is available debian users in the experimental distribution. Helge Hafting

Is the qt4 frontend ready for (experimental) use?

I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools & libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look

Re: Is the qt4 frontend ready for (experimental) use?

Helge Hafting wrote: > Is qt4 simply not ready for testing yet, or broken in svn right now, > or should I look for errors in my setup? It compiles fine here with gcc 3.3. Please send the error messages, maybe some error is tolerated by older gccs but not by gcc 4.1 Georg

amazon problem

I have unsubbed the amazon.com address. Please let me know immediately if the problem occurs again, and I will then block amazon.com from the LyX lists. At this point I am just not sure if some people could have an email account at amazon.com. The problem was--besides that amazon.com somehow

Re: Is the qt4 frontend ready for (experimental) use?

Helge Hafting a écrit : I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools & libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right

Re: [patch] remove wheel mouse ui from qt2

Abdelrazak Younes a écrit : Done, patch attached (not tested). I will apply that once I get some spare time to compile and test (if you don't beat me at this :-)). Committed. Abdel.

Re: A Cygwin related patch

Georg Baum <[EMAIL PROTECTED]> writes: > What I meant was: Do we need for one setting of cygwin_path_fix_needed both > windos/posix styles, or does cygwin_path_fix_needed simply switch > external_path() between the windows and posix version? As it is now, cygwin_path_fix_needed simply switch

Re: qtwin compilation

Angus Leeming wrote: Could you glance over http://wiki.lyx.org/Windows/LyX14x Is that enough info? Feel free to add anything else. Hi Angus, some comments/questions: - First bullet: "LyX files will be associated with the LyX application that has been installed most recently" (I guess it

Re: [PATCH] bug 2217: getting out of mathed is slow

> This is the one that I tested, right? Yes. JMarc

Re: A Cygwin related patch

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> Now I don't like either anymore. The problem of both fixes is > Georg> that they use a trailing '/' as flag whether external_path() is > Georg> needed or not. This will strike

Re: amazon problem

[EMAIL PROTECTED] writes: | I have unsubbed the amazon.com address. Please let me know immediately if | the problem occurs again, and I will then block amazon.com from the LyX | lists. Thanks. -- Lgb

Re: A Cygwin related patch

Enrico Forestieri wrote: > The problem is that I have not a full grasp of the overall code and don't > want introduce changes without fully knowing the consequences. I repeat, > my idea is of only fixing what is broken, making changes that I fully > understand. As a problem arised with [EMAIL

[PATCH} Was: Feature request: Remember the editing location when a file is closed.

Dear list, This time, a formal patch. Here are the rationals: > I am not sure if I like lastfiles to be the files that store this > info. One of the reason is that we only store a very limited number of > files there... lastpostion info should hold more files. Using a separate file like

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | Dear list, | | This time, a formal patch. Here are the rationals: | | > I am not sure if I like lastfiles to be the files that store this | > info. One of the reason is that we only store a very limited number of | > files there... lastpostion info should

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

On Thursday 23 March 2006 18:39, Lars Gullik Bjønnes wrote: > Too old gcc. I think only gcc > 4.1 warns/errors about this. gcc >= 4.1 :-) > -- > Lgb -- José Abílio

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | Index: src/BufferView_pimpl.C | === | --- src/BufferView_pimpl.C(revision 13463) | +++ src/BufferView_pimpl.C(working copy) | @@ -293,6 +293,20 @@ | | setBuffer(b); |

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

> I do not like this one bit. > IMO completely ortogonal feature that happens to share some of the > omplementation. IMHO you have just made a super simple LastFiles a lot > more complex. It is much more troublesome to have a separate implementation. Afterall, lastfiles do mean information

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

> Alternatively, more similar to what you had earlier: > > int pit; > int pos; > boost::tie(pit, pos) = LyX::ref().lastfiles().loadFilePosition(s); This is good to know. > Can you please drop the bookmark part of the patch for now? > If we decide that we do want

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | > I do not like this one bit. | > IMO completely ortogonal feature that happens to share some of the | > omplementation. IMHO you have just made a super simple LastFiles a lot | > more complex. | | It is much more troublesome to have a separate

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | > Just as a test... load a document move the cursor save. | > Exit lyx. Start lyx. Load a different document. Load the first doc. | > Where is the cursor placed now? | | It will move to the position when the first file was closed. My test | goes well

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

Am Mittwoch, 22. März 2006 17:18 schrieb Georg Baum: > Yes. It would be a pity to ditch this code together with the xforms frontend > if it is useful somewhere else. > I think I am going to apply the patch this evening (will send Changelog > then, too). OK, here comes the patch + log. It is

Re: A Cygwin related patch

Georg Baum <[EMAIL PROTECTED]> writes: > I think that you can safely call it unconditionally. I looked it up, and > latex_path() is only called on filenames that are written to .tex files. I > would be very surprised if a TeX compiler exists on windows that needs win > style paths in \inputa

Re: A Cygwin related patch

Am Donnerstag, 23. März 2006 21:26 schrieb Enrico Forestieri: > Your theory is right and I wasn't fearless enough, not having the time > to study the code. So, the attached is apparently the right fix. While > testing this patch I run up against another bug. > > 1) File->New > 2)

Bug in most recent svn -stable branch

When compiling lyx on Solaris 10, using an up-to-date gnu setup (updated autoconf, automake, etc). Compilation of the recent svn stable branch completes without problems. At startup however, lyx displays the main window, reports a SIGSEGV, displays the 'please report a bug message' and core

[patch] fix layout2layout

The attached patch is the outcome of a discussion with Jean-Marc at http://bugzilla.lyx.org/show_bug.cgi?id=2355. The problem is that I did not realize that TocLevel was a new keyword when I wrote layout2layout. This patch adds this keyword for sectioning styles. Comments? Georg Index:

Re: A Cygwin related patch

Georg Baum <[EMAIL PROTECTED]> writes: > > Many thanks for your helpful and appreciated comments. > > I hope they are not too disappointing Oh, not at all... > Here you basically revert external_path on non-cygwin windows. This is a > bit ugly, so I moved this into a new function >

Possible charstyle bug

Hi, I think I may have found a bug in the way character styles are handled. See attached sample document and sample styles. If a character style is used in an "itemize" environment, LyX genereates LaTeX code like this: \begin{itemize} \item item 1 \item item 2 \item item 3 has a

Re: Bug in most recent svn -stable branch

Lodewijk Bonebakker <[EMAIL PROTECTED]> writes: | When compiling lyx on Solaris 10, using an up-to-date gnu setup | (updated autoconf, automake, etc). Compilation of the recent svn | stable branch completes without problems. | | At startup however, lyx displays the main window, reports a

LyX/Win 1.4.1 pre 1

Just installed 1.4.1pre1 on another machine (Win XP Pro) and noticed a couple of things. 1. While the configuration script was running, I noticed the following output: Checking for a LaTeX -> LyX converter +checking for "/c/Program" ... no That 'no' doesn't surprise me. I'm not sure what

Re: Possible charstyle bug

Hi, I just tried editing the .lyx file manually changing \begin_inset CharStyle command status inlined \begin_layout Itemize command \end_layout \end_inset to \begin_inset CharStyle command status inlined \begin_layout Standard command \end_layout

Re: configure failure... (latest CVS) missing file?

"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | Yes. This gets me past the initial problem. Now there is a link issue (see | my other email). I am unable to find your other mail, can you repost? -- Lgb

Re: Bug in most recent svn -stable branch

Lodewijk Bonebakker <[EMAIL PROTECTED]> writes: > > When compiling lyx on Solaris 10, using an up-to-date gnu setup (updated > autoconf, automake, etc). Compilation of the recent svn stable branch > completes without problems. > > At startup however, lyx displays the main window, reports a

Potential 1.4 patches

Hi, my new hobby-horse: Keeping track of patches to the trunk that may also be relevant for LyX 1.4.X :-) Michael = Change Tracking r13339 - Fix bug 880, or the multi-paragraph change tracking patch r13356 - fix painting of change bar

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

> No. We need to have the "last position" feature in addition, not mixed > with lastfile. OK, since you insist, here comes a much larger patch. The patch works on my system. However, there are two problems that make this feature almost useless. Please help me resolve them. 1. Alt-F4 and

Re: Possible charstyle bug

On Thu, Mar 23, 2006 at 01:31:03PM -0800, Markus Mayer wrote: > Hi, > > I think I may have found a bug in the way character styles are handled. > See attached sample document and sample styles. > > If a character style is used in an "itemize" environment, LyX > genereates LaTeX code like this: >

Re: Potential 1.4 patches

Am Freitag, 24. März 2006 00:38 schrieb Michael Gerz: > Change Tracking > > r13339 - Fix bug 880, or the multi-paragraph change tracking patch > r13356 - fix painting of change bar with only paragraph break changed > r13385 - Change tracking -related bug fixes (reported by Juergen) > r13408 - fix

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

"Bo Peng" <[EMAIL PROTECTED]> writes: | > No. We need to have the "last position" feature in addition, not mixed | > with lastfile. | | OK, since you insist, here comes a much larger patch. I like this patch a lot better. Thanks for doing this. One thing we should think about though; not

<    1   2