Georg Baum wrote:
This smells like a boost thing. Does it happen also if you compile against
system boost? Do you have that at all?
No, I haven't installed that currently. Anyway, I think SuSE 10 ships the same
version than LyX 1.5 (1.33.1).
Or maybe with the boost directory
of 1.4?
How
Juergen Spitzmueller wrote:
The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog
currently. Abdel, while you are at it, could you please remove the wheel
mouse spinbox?
OK to apply to branch and trunk?
I would think so.
Juergen Spitzmueller wrote:
Georg Baum wrote:
Or maybe with the boost directory
of 1.4?
How can I compile against that?
I think it would work if you temporarily exchange the boost subdirectory of
LyX with that of 1.4, but I am not sure. Of course you should rerun
autogen.sh etc. and do a
Martin Vermeer wrote:
On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
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
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 think is lagging behind. Please, tell
me if this ok with
On Wednesday 22 March 2006 20:06, Georg Baum wrote:
I think you should put that in. Even if we are going to fix the xurrent
problems it will LyX make more robust wrt incomoplete layout files, which
is a Good Thing (TM).
I agree, otherwise layouts looks like black magic for users. Really. :-)
christian == christian ridderstrom [EMAIL PROTECTED] writes:
christian 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 where I was
working on, after the file is re-opened.
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 where I was working
on, after the file is re-opened. I would
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen The attached patch finally eliminates the gui element. I did
Juergen not touch qt4, since Abdel is reorganizing the Prefs dialog
Juergen currently. Abdel, while you are at it, could you please
Juergen remove the wheel mouse
On Thu, 23 Mar 2006, Jean-Marc Lasgouttes wrote:
I can think of two ways to do this:
1. (More intrusive). Remember the location under .lyx and jump to
it when a lyx file is opened. I think this is what vim is doing.
christian For good or worse, this also means that when working with
Georg Baum wrote:
I would think so. Since the system wheel setting is obeyed now it is only
logical to remove this setting in the same release (1.4.1).
It would be nice if you could lookup whether gtk uses this setting at all,
and make a comment in lyxrc.h stating which frontedns actually use
Martin Vermeer [EMAIL PROTECTED] writes:
On Wed, Mar 22, 2006 at 09:29:35PM +, 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
Juergen Spitzmueller a écrit :
The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently.
I am done for now with the Prefs reorg. Feel free to modify it (or even
better process to phase 2 of my reorg ;-)).
I will
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 think is
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico Really? I had thought the second one was more cleaner.
Enrico Actually I had to figure out that when latex_path() is called
Enrico for generating the argument of [EMAIL PROTECTED] it is assumed that
Enrico a trailing / is present, and
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars This is the correct fix.
I applied it.
JMarc
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 [EMAIL PROTECTED] it is assumed that a trailing / is present, and the
second
patch makes this clear not only for
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 why this would cause confusion. You could have a dialog
box warning
Juergen Spitzmueller wrote:
I cannot compile gtk.
You don't need to compile it in order to find out whether wheel_jump is used
or not :-)
Anyway, I looked now myself and will commit the attached patch.
GeorgIndex: src/lyxrc.h
===
* Open anyway.
fine, assume the user sorts it out after being warned
Letting the user Open anyway after being warned still seems a lot
better than not warning the user at all. I thought that not letting
the user open the file rw may not be popular in certain quarters...
this was the only reason I
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico Really? I had thought the second one was more cleaner.
Enrico Actually I had to figure out that when latex_path() is called
Enrico for generating the argument of \input at path it
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 at path it is assumed that a trailing / is present, and the
second
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
paths
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 id, pos
filename if position information is available, and filename if not.
Would it be easier to always have the id, pos filename format? And id
=
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
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
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
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
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
===
---
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 where I was
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 whole
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 a
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 graphics is in
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 think
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 why this would
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 fixes is
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:
|
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
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 that
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 the
paragraphs that
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 (working
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
pgplNNJEXXofL.pgp
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
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 for
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
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
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
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.
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
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
This is the one that I tested, right?
Yes.
JMarc
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 back sooner or
[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
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
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
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 hold
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
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);
|
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 regarding
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 bookmark[0] to
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 implementation.
|
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 except that
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 going in
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 at path
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) Insert-File-Child
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
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:
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
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
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 SIGSEGV,
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
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
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
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 SIGSEGV,
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
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
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:
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
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 caused by
Georg Baum wrote:
> This smells like a boost thing. Does it happen also if you compile against
> system boost? Do you have that at all?
No, I haven't installed that currently. Anyway, I think SuSE 10 ships the same
version than LyX 1.5 (1.33.1).
> Or maybe with the boost directory
> of 1.4?
Juergen Spitzmueller wrote:
> The attached patch finally eliminates the gui element.
> I did not touch qt4, since Abdel is reorganizing the Prefs dialog
> currently. Abdel, while you are at it, could you please remove the wheel
> mouse spinbox?
>
> OK to apply to branch and trunk?
I would think
Juergen Spitzmueller wrote:
> Georg Baum wrote:
>> Or maybe with the boost directory
>> of 1.4?
>
> How can I compile against that?
I think it would work if you temporarily exchange the boost subdirectory of
LyX with that of 1.4, but I am not sure. Of course you should rerun
autogen.sh etc. and
Martin Vermeer wrote:
> On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
>> 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
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 think is lagging behind. Please, tell
> me if this ok
On Wednesday 22 March 2006 20:06, Georg Baum wrote:
> I think you should put that in. Even if we are going to fix the xurrent
> problems it will LyX make more robust wrt incomoplete layout files, which
> is a Good Thing (TM).
I agree, otherwise layouts looks like black magic for users. Really.
> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:
christian> 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 where I was
>> working on, after
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 where I was working
> > on, after the file is
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> The attached patch finally eliminates the gui element. I did
Juergen> not touch qt4, since Abdel is reorganizing the Prefs dialog
Juergen> currently. Abdel, while you are at it, could you please
Juergen> remove the wheel
On Thu, 23 Mar 2006, Jean-Marc Lasgouttes wrote:
> >> I can think of two ways to do this:
> >>
> >> 1. (More intrusive). Remember the location under .lyx and jump to
> >> it when a lyx file is opened. I think this is what vim is doing.
>
> christian> For good or worse, this also means that when
Georg Baum wrote:
> I would think so. Since the system wheel setting is obeyed now it is only
> logical to remove this setting in the same release (1.4.1).
> It would be nice if you could lookup whether gtk uses this setting at all,
> and make a comment in lyxrc.h stating which frontedns actually
Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> On Wed, Mar 22, 2006 at 09:29:35PM +, 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
Juergen Spitzmueller a écrit :
The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently.
I am done for now with the Prefs reorg. Feel free to modify it (or even
better process to phase 2 of my reorg ;-)).
I will
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
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> Really? I had thought the second one was more cleaner.
Enrico> Actually I had to figure out that when latex_path() is called
Enrico> for generating the argument of [EMAIL PROTECTED] it is assumed that
Enrico> a trailing / is
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> This is the correct fix.
I applied it.
JMarc
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 [EMAIL PROTECTED] it is assumed that a trailing / is present, and the
> second
> patch makes this clear not only for
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 why this would cause confusion. You could have a dialog
box
Juergen Spitzmueller wrote:
> I cannot compile gtk.
You don't need to compile it in order to find out whether wheel_jump is used
or not :-)
Anyway, I looked now myself and will commit the attached patch.
GeorgIndex: src/lyxrc.h
>* Open anyway.
>fine, assume the user sorts it out after being warned
Letting the user "Open anyway" after being warned still seems a lot
better than not warning the user at all. I thought that not letting
the user open the file rw may not be popular in certain quarters...
this was the only
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> Really? I had thought the second one was more cleaner.
> Enrico> Actually I had to figure out that when latex_path() is called
> Enrico> for generating the argument of
1 - 100 of 158 matches
Mail list logo