Jürgen Spitzmüller wrote:
Joost Verburg wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory called lyx16), while CMake sets
it to 1.6 (directory called LyX1.6). There should be an option to
change this otherwise user preferences
Peter Kümmel wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory called lyx16), while CMake sets
it to 1.6 (directory called LyX1.6). There should be an option to
change this otherwise user preferences will not be preserved.
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory called lyx16), while CMake sets
it to 1.6 (directory called LyX1.6). There should be an option to
change this otherwise user preferences
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now with 1.6.7.
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that
if you ask on command line to write output over the input file it gets
overwritten
like the infamous 'cat file1 file2 file1' mistake. don't see the
On Wed, Jul 14, 2010 at 10:05:49AM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory called lyx16), while CMake sets
it to 1.6 (directory called LyX1.6).
Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now with 1.6.7.
Just discovered another issue. The user directory suffix for the 1.6
series has always
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:05:49AM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been 16 (directory called lyx16), while CMake sets
it to 1.6
Am Mittwoch 14 Juli 2010 schrieb Peter Kümmel:
Don't understand. The user directory is ~/.lyx without setting
environmate variables.
On Linux. He talks about the user dir on Windows, were it gets the PACKAGE
name which is LyX1.6 and not LyX16, therefore my patch which doesn't touch
Linux
On Wed, Jul 14, 2010 at 10:42:19AM +0200, Peter Kümmel wrote:
Do you build with autotools on Windows? It's a windows only patch.
Yes, I happily build with autotools on Windows using MinGW.
--
Enrico
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now with 1.6.7.
Just discovered another issue. The user
Enrico Forestieri wrote:
Here a patch. OK to commit?
I don't think so. This would break building with autotools.
PACKAGE is used all over the place in the lyx sources, so adapt
cmake to it, please.
agree with Enrico.
Jürgen
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal
that
if you ask on command line to write output over the input file it gets
overwritten
like the
Enrico Forestieri wrote:
commands can be changed if they are wrong, but the exotic case invented
just for
this debate like lyx -e lyx foo.lyx is hardly enough reason.
it looks as fixing acrobatic usecases never reported by anybody for
the price of introducing new problems. typical
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now with 1.6.7.
Just discovered
Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is lyx16 (in case case matters on win).
Jürgen
Stephan Witt wrote:
One remark here (nitpick):
In the first example cat is not the program which overwrites the original.
It is the shell - and to avoid that stupid mistake they introduced the
variable noclobber.
When it is set and if your scripts assume overwrite of already existent files
With so much recompiles I would like to fix the merged build.
Peter
Index: development/cmake/src/CMakeLists.txt
===
--- development/cmake/src/CMakeLists.txt(Revision 34893)
+++ development/cmake/src/CMakeLists.txt
Am 14.07.2010 um 11:57 schrieb Pavel Sanda:
Stephan Witt wrote:
One remark here (nitpick):
In the first example cat is not the program which overwrites the original.
It is the shell - and to avoid that stupid mistake they introduced the
variable noclobber.
When it is set and if your
Peter Kümmel wrote:
With so much recompiles I would like to fix the merged build.
OK.
Jürgen
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is lyx16 (in case case matters on win).
Windows is case insensitive. Cygwin?
Peter
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
i still maintain that the backward compatibility will cause less user's
frustration for this particular switch (ie default RC setting would need to
be set on main file overwrite) than new gun-discharged-course but i let
the responsibility on
On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is lyx16 (in case case matters on win).
Windows is case insensitive. Cygwin?
Cygwin
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is lyx16 (in case case matters on win).
Windows is case insensitive.
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
So, let's have a poll:
1) Leave things as they are (need -f to overwrite)
2) The main file should always be overwritten
3) If no -f switch is given, use preferences settings for overwriting
as i
Pavel Sanda wrote:
I don't stop 1.6.7 because of this.
which means that you dont want to postpone it for other discussions or that
Enricos's patch is no-go for 1.6.7?
the former. On the patch itself, I do not have a strong opinion.
Jürgen
Peter Kümmel wrote:
Seems now 1.6.7 is ready for Windows.
Famous last words :-)
I'll set up yet another tarball.
Jürgen
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
I don't stop 1.6.7 because of this.
which means that you dont want to postpone it for other discussions or that
Enricos's patch is no-go for 1.6.7?
the former. On the patch itself, I do not have a strong opinion.
ok unless Enrico is not
Pavel Sanda wrote:
ok unless Enrico is not against i would be thaknful if we could put
his patch into branch now...
As said, I do not want to unfreeze 1.6.7svn again.
Jürgen
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
ok unless Enrico is not against i would be thaknful if we could put
his patch into branch now...
As said, I do not want to unfreeze 1.6.7svn again.
aha i misunderstood.
pavel
Uwe Stöhr uwestoehr at web.de writes:
There is another issue: The text on page is not yet translated to the
document language.
One manually has to add this preamble code:
\renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}}
auf Seite is hereby the German translation of on
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now
Jürgen Spitzmüller wrote:
I'll set up yet another tarball.
Done. The new tarballs are on the server. Let's hope for the best.
Jürgen
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
On Wed, Jul 14, 2010 at 02:24:56PM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this
On Wed, Jul 14, 2010 at 01:48:38PM +0200, Peter Kümmel wrote:
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is
Jean-Pierre Chrétien jeanpierre.chretien at free.fr writes:
Why not
{\nameref{#1}~\vpageref{#1}}
This will use all variants of varioref page handling.
Rather {\nameref{#1} \vpageref{#1}}, the unbrealkable space is not necessary
here (nor with \reftextfaraway in fact, page~xxx
Am 14.07.2010 um 14:25 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
I'll set up yet another tarball.
Done. The new tarballs are on the server. Let's hope for the best.
Tested it with msvc10, and saw now problems. userdir is now lyx16,
merged build also works, so Joost could release a little bit earlier.
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 02:24:56PM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
On
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 01:48:38PM +0200, Peter Kümmel wrote:
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
Is it OK when I set PACKAGE to
Enrico Forestieri wrote:
what would be the implicit value? if 'none', its kind of equivalent with
the rc patch.
if 'main' then i like it more, of course ;)
Yes, of course none would be the default if anything other than all or
main is specified. See the attached patch. I like this
Am 09.07.2010 um 20:37 schrieb LyX Ticket Tracker:
#6740: Zoom using mouse wheel conflicts with momentum scrolling
--+-
Reporter: theophys | Owner: stwitt
Type: defect| Status: accepted
On 14/07/2010 4:15 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that
if you ask on command line to write output over the input file it gets
overwritten
like the infamous 'cat
On 07/14/2010 08:25 AM, Enrico Forestieri wrote:
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
and, of course, you can
export LYX_FORCE_OVERWRITE=main
from .bash_profile if you want.
rh
Stephan Witt wrote:
Am 09.07.2010 um 20:37 schrieb LyX Ticket Tracker:
#6740: Zoom using mouse wheel conflicts with momentum scrolling
--+-
Reporter: theophys | Owner: stwitt
Type: defect|
On Wed, Jul 14, 2010 at 03:18:50PM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
So, it seems that cmake doesn't follow the LyX conventions even on posix
systems (let alone on Windows). You should be able to *specify* a version
suffix other than accepting a
On Wed, Jul 14, 2010 at 03:24:24PM +0200, Kornel Benko wrote:
This is nice. We may overcome this. But someone has to check it on a cygwin.
The only (small?) problem may be to detect we are on cygwin.
I am not going to play guinea-pig ;-)
--
Enrico
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think you're missing the point, too. On July 14 you
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:24:24PM +0200, Kornel Benko wrote:
This is nice. We may overcome this. But someone has to check it on a
cygwin. The only (small?) problem may be to detect we are on cygwin.
I am not going to play guinea-pig ;-)
On 14/07/2010 11:52 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think you're missing the
Pavel Sanda wrote:
Juergen, status file for 1.6.7 does not clearly warns about the issue,
you maybe want at least put some note about commandline incompatibility
into web annoucement.
I think this can go into the wiki version of the RELEASE_NOTES.
Jürgen
Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:24:24PM +0200, Kornel Benko wrote:
This is nice. We may overcome this. But someone has to check it on a
cygwin. The only (small?) problem may be to detect we are on cygwin.
I am not
Am 14.07.2010 um 17:33 schrieb Pavel Sanda:
Stephan Witt wrote:
Am 09.07.2010 um 20:37 schrieb LyX Ticket Tracker:
#6740: Zoom using mouse wheel conflicts with momentum scrolling
--+-
Reporter: theophys |
Stephan Witt wrote:
# math-macros
-\bind C-plus math-macro-unfold
+#\bind C-plus math-macro-unfold
shouldn't be this put elsewhere so other archs are not affected?
How can I do this? I want to avoid the binding here because I want to bind
another command for Mac.
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
Note that cp also has a -n (don't overwrite) flag. This seems pretty
pointless for a cp command, no? Imagine if this was the default
behavior. cp /path/file.tex . does nothing... sounds strange, no?
$ lyx -e latex foo.lyx
Am 14.07.2010 um 18:57 schrieb Pavel Sanda:
Stephan Witt wrote:
# math-macros
-\bind C-plus math-macro-unfold
+#\bind C-plus math-macro-unfold
shouldn't be this put elsewhere so other archs are not affected?
How can I do this? I want to avoid the binding here because I
On Wed, Jul 14, 2010 at 06:05:17PM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:24:24PM +0200, Kornel Benko wrote:
This is nice. We may overcome this. But someone has to check it on a
cygwin. The only (small?) problem may be to
Stephan Witt wrote:
As said, I propose to change that for other archs too.
i dont use macros myself so i really have no idea how is this unfold macro
important.
pavel
Am 14.07.2010 um 19:12 schrieb Stephan Witt:
Am 14.07.2010 um 18:57 schrieb Pavel Sanda:
Stephan Witt wrote:
# math-macros
-\bind C-plus math-macro-unfold
+#\bind C-plus math-macro-unfold
shouldn't be this put elsewhere so other archs are not affected?
How can I do
On Wed, Jul 14, 2010 at 06:41:13PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 06:05:17PM +0200, Kornel Benko wrote:
Am Mittwoch 14 Juli 2010 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:24:24PM +0200, Kornel Benko wrote:
This is nice. We may overcome this. But someone has to
On 14/07/2010 1:10 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
Note that cp also has a -n (don't overwrite) flag. This seems pretty
pointless for a cp command, no? Imagine if this was the default
behavior. cp /path/file.tex . does nothing...
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear* consensus emerges about what should be the default
Am 13.07.2010 23:10, schrieb Richard Heck:
So now we just have to figure out the translation issue. Are you sure the
nameref folks have no
interest in fixing this?
Yes, because I asked them to add this feature some time ago when i met the hyperref developer
personally. But it is OK that the
On 07/14/2010 04:05 PM, Uwe Stöhr wrote:
p.s. sorry for my harsh words in my previous email
No problem, Uwe. I know you get over-animated sometimes. But you do owe
me a beer.
rh
ps thanks for the apology, anyway.
On 07/14/2010 02:47 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear*
Am 14.07.2010 22:41, schrieb Richard Heck:
p.s. sorry for my harsh words in my previous email
No problem, Uwe. I know you get over-animated sometimes. But you do owe me a
beer.
What, what, what?
You do the mistakes, I correct them, I'm the brave one speaking out the truth, fix all
Am 14.07.2010 um 19:43 schrieb Stephan Witt:
Am 14.07.2010 um 19:12 schrieb Stephan Witt:
Am 14.07.2010 um 18:57 schrieb Pavel Sanda:
Stephan Witt wrote:
# math-macros
-\bind C-plus math-macro-unfold
+#\bind C-plus math-macro-unfold
shouldn't be this put elsewhere so
On 7/14/2010 8:24 AM, Jürgen Spitzmüller wrote:
Done. The new tarballs are on the server. Let's hope for the best.
Thanks for all your help. The installers have been uploaded to the usual
location (incoming on devel).
They come with all the latest goodies like Qt 4.6.3, gettext 0.18,
Hi,
LyX is working great, and alpha4 is looking excellent.
First, a question. I can build 2.0-alpha4, and its additional features (like
the advanced search) nicely augment my install of 1.6 when I need ot use
them, but I'd like it to use a different local user config directory (i.e.,
not
On 07/14/2010 10:49 PM, Jacob Barandes wrote:
Hi,
LyX is working great, and alpha4 is looking excellent.
First, a question. I can build 2.0-alpha4, and its additional features
(like the advanced search) nicely augment my install of 1.6 when I
need ot use them, but I'd like it to use a
Joost Verburg wrote:
Thanks for all your help. The installers have been uploaded to the usual
location (incoming on devel).
They come with all the latest goodies like Qt 4.6.3, gettext 0.18,
libiconv 1.13.1 etc. All compiled with MSVC 2010.
Everything seems to work well.
Excellent!
Jürgen
Jürgen Spitzmüller wrote:
> Joost Verburg wrote:
>> Just discovered another issue. The user directory suffix for the 1.6
>> series has always been "16" (directory called lyx16), while CMake sets
>> it to "1.6" (directory called LyX1.6). There should be an option to
>> change this otherwise user
Peter Kümmel wrote:
> >> Just discovered another issue. The user directory suffix for the 1.6
> >> series has always been "16" (directory called lyx16), while CMake sets
> >> it to "1.6" (directory called LyX1.6). There should be an option to
> >> change this otherwise user preferences will not
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
Just discovered another issue. The user directory suffix for the 1.6
series has always been "16" (directory called lyx16), while CMake sets
it to "1.6" (directory called LyX1.6). There should be an option to
change this
Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
> On 7/13/2010 6:12 PM, Joost Verburg wrote:
> > I think this should definitely be fixed for 1.6.8 but maybe we can go
> > ahead now with 1.6.7.
>
> Just discovered another issue. The user directory suffix for the 1.6
> series has always been "16"
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
>
> you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that
> if you ask on command line to write output over the input file it gets
> overwritten
> like the infamous 'cat file1 file2 > file1' mistake. don't see
On Wed, Jul 14, 2010 at 10:05:49AM +0200, Peter Kümmel wrote:
> Jürgen Spitzmüller wrote:
> > Peter Kümmel wrote:
> Just discovered another issue. The user directory suffix for the 1.6
> series has always been "16" (directory called lyx16), while CMake sets
> it to "1.6"
Kornel Benko wrote:
> Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
>> On 7/13/2010 6:12 PM, Joost Verburg wrote:
>>> I think this should definitely be fixed for 1.6.8 but maybe we can go
>>> ahead now with 1.6.7.
>> Just discovered another issue. The user directory suffix for the 1.6
>> series
Enrico Forestieri wrote:
> On Wed, Jul 14, 2010 at 10:05:49AM +0200, Peter Kümmel wrote:
>> Jürgen Spitzmüller wrote:
>>> Peter Kümmel wrote:
>> Just discovered another issue. The user directory suffix for the 1.6
>> series has always been "16" (directory called lyx16), while CMake sets
Am Mittwoch 14 Juli 2010 schrieb Peter Kümmel:
> > Don't understand. The user directory is "~/.lyx" without setting
> > environmate variables.
>
> On Linux. He talks about the user dir on Windows, were it gets the PACKAGE
> name which is LyX1.6 and not LyX16, therefore my patch which doesn't
On Wed, Jul 14, 2010 at 10:42:19AM +0200, Peter Kümmel wrote:
>
> Do you build with autotools on Windows? It's a windows only patch.
Yes, I happily build with autotools on Windows using MinGW.
--
Enrico
On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
> Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
> > On 7/13/2010 6:12 PM, Joost Verburg wrote:
> > > I think this should definitely be fixed for 1.6.8 but maybe we can go
> > > ahead now with 1.6.7.
> >
> > Just discovered another
Enrico Forestieri wrote:
> > Here a patch. OK to commit?
>
> I don't think so. This would break building with autotools.
> PACKAGE is used all over the place in the lyx sources, so adapt
> cmake to it, please.
agree with Enrico.
Jürgen
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri:
> On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
>>
>> you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal
>> that
>> if you ask on command line to write output over the input file it gets
>> overwritten
>>
Enrico Forestieri wrote:
> > commands can be changed if they are wrong, but the exotic case invented
> > just for
> > this debate like "lyx -e lyx foo.lyx" is hardly enough reason.
> > it looks as fixing acrobatic usecases never reported by anybody for
> > the price of introducing new problems.
Enrico Forestieri wrote:
> On Wed, Jul 14, 2010 at 10:13:37AM +0200, Kornel Benko wrote:
>> Am Mittwoch 14 Juli 2010 schrieb Joost Verburg:
>>> On 7/13/2010 6:12 PM, Joost Verburg wrote:
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now with 1.6.7.
>>> Just
Peter Kümmel wrote:
> Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
I think the current is "lyx16" (in case case matters on win).
Jürgen
Stephan Witt wrote:
> One remark here (nitpick):
> In the first example "cat" is not the program which overwrites the original.
> It is the shell - and to avoid that stupid mistake they introduced the
> variable noclobber.
> When it is set and if your scripts assume overwrite of already existent
With so much recompiles I would like to fix the merged build.
Peter
Index: development/cmake/src/CMakeLists.txt
===
--- development/cmake/src/CMakeLists.txt(Revision 34893)
+++ development/cmake/src/CMakeLists.txt
Am 14.07.2010 um 11:57 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> One remark here (nitpick):
>> In the first example "cat" is not the program which overwrites the original.
>> It is the shell - and to avoid that stupid mistake they introduced the
>> variable noclobber.
>> When it is set and
Peter Kümmel wrote:
> With so much recompiles I would like to fix the merged build.
OK.
Jürgen
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
>> Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
>
> I think the current is "lyx16" (in case case matters on win).
Windows is case insensitive. Cygwin?
Peter
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > i still maintain that the backward compatibility will cause less user's
> > frustration for this particular switch (ie default RC setting would need to
> > be set on main file overwrite) than new gun-discharged-course but i let
> > the
On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
> Jürgen Spitzmüller wrote:
> > Peter Kümmel wrote:
> >> Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
> >
> > I think the current is "lyx16" (in case case matters on win).
>
>
> Windows is case insensitive.
Enrico Forestieri wrote:
> On Wed, Jul 14, 2010 at 12:25:35PM +0200, Peter Kümmel wrote:
>> Jürgen Spitzmüller wrote:
>>> Peter Kümmel wrote:
Is it OK when I set PACKAGE to 'LyX16' instead 'LyX1.6' on Windows?
>>> I think the current is "lyx16" (in case case matters on win).
>>
>> Windows is
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > So, let's have a poll:
> >
> > 1) Leave things as they are (need -f to overwrite)
> > 2) The main file should always be overwritten
> > 3) If no -f switch is given, use preferences settings for overwriting
1 - 100 of 150 matches
Mail list logo
