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:
> 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
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 will not be preserve
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 Juergen or anybody else who wa
Enrico Forestieri wrote:
> > could you elaborate why strong disagreement? another utils i'm currently
> > using
> > around lyx work also like that - pdflatex rewrites ouput, dvips too. you are
> > strongly disagree with their doing also?
> > its really no fun to scan all the scripts in various pro
On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > some of my script do not work anymore due to the fact that lyx
> > > silently fails to overwrite exported files.
> >
> > This is rather a trunk regression, as in branch you get notified
> > when the file
On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote:
>
> core of my complaint was that changing semantics of traditional
> switch is pita and will be hardly changed by disputing nitpicks
> of selected examples inside coreutils.
Core of my answer was that switches of commands can be change
Enrico Forestieri wrote:
> > some of my script do not work anymore due to the fact that lyx
> > silently fails to overwrite exported files.
>
> This is rather a trunk regression, as in branch you get notified
> when the file is not overwritten.
which is not of much help in batch mode
pavel
Enrico Forestieri wrote:
> Funny that you mention that:
>
> host1> tail --version
> tail (GNU coreutils) 5.97
> ...
> host1> tail +20 foo
> [commands succeeds, showing last lines of foo starting from line 20]
>
> host2> tail --version
> tail (GNU coreutils) 8.5
> ...
> host2> tail +20 foo
> tail:
On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote:
> hi,
>
> some of my script do not work anymore due to the fact that lyx
> silently fails to overwrite exported files.
This is rather a trunk regression, as in branch you get notified
when the file is not overwritten.
--
Enrico
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 called lyx16), while CMake sets
it to "1.6" (direc
On 7/13/2010 10:44 AM, Peter Kümmel wrote:
Do you use the merged build? I've not tested it for several weeks.
OK so I got it to compile by:
* Disabling merged build
* Moving my files to C:\ to shorten the path
I think this should definitely be fixed for 1.6.8 but maybe we can go
ahead now wit
On 7/13/2010 4:22 AM, Peter Kümmel wrote:
Wouldn't it be better to disable LYX_INSTALL by default and to enable all
deploy releant options if LYX_INSTALL is set: aspell, nls, no console, more?
I'm always annoyed about all the translations and lyx file processing projects
which I really do not ne
On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > this is a showstoppper for anybody using lyx in scripts.
> >
> > Come on, simply add -f if you don't care overwriting existing files.
> > The way it worked before r34533 was fundamentally wrong.
>
> well
On 07/13/2010 11:30 AM, Uwe Stöhr wrote:
Am 13.07.2010 15:47, schrieb Richard Heck:
Again, this isn't the issue. What I do has the same effect,
No, it has not, the suer gets a number instead of the name of the
reference.
Sorry, I missed the difference between your first proposal and your
Enrico Forestieri wrote:
> > this is a showstoppper for anybody using lyx in scripts.
>
> Come on, simply add -f if you don't care overwriting existing files.
> The way it worked before r34533 was fundamentally wrong.
well, changing the semantics of commandline switches is a nightmare.
just imag
On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > hi,
> >
> > some of my script do not work anymore due to the fact that lyx silently
> > fails to overwrite exported files.
> > i vaguely remember introducing -f switch to enforce overwriting, which must
> > be
On 07/13/2010 12:13 PM, Pavel Sanda wrote:
disclaimer first - i know nothing about the subtleties of varisous XXXref
commands... anyway tend to agree here with Richard to consider this as nameref
bug. if nameref devs do not plan to fix/advance their work its question whether
our dependency on th
Pavel Sanda wrote:
> hi,
>
> some of my script do not work anymore due to the fact that lyx silently fails
> to overwrite exported files.
> i vaguely remember introducing -f switch to enforce overwriting, which must
> be related.
> in particular commands like:
> lyx file.lyx -e dvi
> won't rewri
hi,
some of my script do not work anymore due to the fact that lyx silently fails
to overwrite exported files.
i vaguely remember introducing -f switch to enforce overwriting, which must be
related.
in particular commands like:
lyx file.lyx -e dvi
won't rewrite main file, which shouldn't be... E
Uwe Stöhr wrote:
> Sorry, but I have the feeling that you are a bit lazy with your patch. If
> we are not able to translate the reference text, the new feature turns into
> a bug as it then only works for English documents. I therefore wanted to
> solve this issue before applying.
>
>> Could
Now, I've added the native spell checker interface for mac os x, I find it
strange to support only adding words in LyX.
It seems like the spell checker infrastructure doesn't support removing of
words from personal dictionary.
But this is possible with aspell at least, AFAICS.
The cool feature h
Uwe Stöhr wrote:
>> is simpler,
>> and doesn't use ERT: I just convert the command from \nameref to \ref or
>> \Nameref to \vref. The point is that this does not produce the same
>> output as \nameref does and there is no reasonable way to do this.
>
> But this is the reason why this is no option.
Am 13.07.2010 15:50, schrieb Richard Heck:
There's no lyx2lyx issue,
There is, see my previous mail! OK, I'll change the lyx2lyx routine so
that the result gives the same output for the user.
and the translation issue can be addressed
independently. You're welcome to add your code if you w
Am 13.07.2010 15:47, schrieb Richard Heck:
Again, this isn't the issue. What I do has the same effect,
No, it has not, the suer gets a number instead of the name of the reference.
is simpler,
and doesn't use ERT: I just convert the command from \nameref to \ref or
\Nameref to \vref. The poin
On 7/13/2010 10:44 AM, Peter Kümmel wrote:
Do you use the merged build? I've not tested it for several weeks.
Yes, LYX_MERGE_FILES is enabled in CMake. I will disable it and try again.
Joost
Joost Verburg wrote:
> On 7/13/2010 2:31 AM, Peter Kümmel wrote:
>> 'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not
>> part of the tarballs. Seems you've somehow used trunk code.
>
> I'm using the tarball, but somehow the line number if off here.
> I get a lot of other errors as well, su
On 7/13/2010 2:31 AM, Peter Kümmel wrote:
'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not
part of the tarballs. Seems you've somehow used trunk code.
I'm using the tarball, but somehow the line number if off here.
I get a lot of other errors as well, such as:
lyx\lyx-1.6.7\src\mathed
Joost Verburg wrote:
> On 7/13/2010 2:43 AM, Peter Kümmel wrote:
>> somehow it eats the dot before '.inc'
>
> Not just the dot. It's eating other characters here somewhere else in
> the string.
>
I've moved the sources to c:\s\lyx-1.6.7 and the build to c:\b then the command
line was short enou
On 7/13/2010 10:25 AM, Joost Verburg wrote:
On 7/13/2010 2:43 AM, Peter Kümmel wrote:
somehow it eats the dot before '.inc'
Not just the dot. It's eating other characters here somewhere else in
the string.
For example here:
Jost/LyX/lyx-1.6.7/lib/layouts/theorems-starred-equivalents.inc
^
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
>>> I switch to Linux now, and test there the patched tarball. I give you a
>>> Ok later, or ask for checkins ;)
>>>
>>>
>> The files or ok on linux.
>
> OK, thanks for testing.
>
> Joost, I've uploaded new tarballs. Awaiting your feedback.
Just to
On 7/13/2010 2:43 AM, Peter Kümmel wrote:
somehow it eats the dot before '.inc'
Not just the dot. It's eating other characters here somewhere else in
the string.
Joost
On 07/13/2010 02:08 AM, Jürgen Spitzmüller wrote:
Richard Heck wrote:
One idea is to mark such classes with an asterisk, as in the attached
patch and screenshot. Comments? Other ideas?
I think we had an asterisk at first and then changed it to the current text,
because people found th
On 07/13/2010 09:41 AM, Jürgen Spitzmüller wrote:
Liviu Andronic wrote:
Why not simply: 'missing latex classes'
because there's also DocBook and it could also be missing style files.
or 'missing dependencies'?
this is a bit vague, IMHO.
The other thing is that there
On 07/13/2010 08:06 AM, Uwe Stöhr wrote:
Am 13.07.2010 05:23, schrieb Richard Heck:
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 Seit
On 07/13/2010 08:11 AM, Uwe Stöhr wrote:
Am 13.07.2010 13:59, schrieb Uwe Stöhr:
We can easily convert this to:
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
\backslash
vref{
\end_layout
\end_inset
sec:dsf
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
}
\end_layo
Liviu Andronic wrote:
> Why not simply: 'missing latex classes'
because there's also DocBook and it could also be missing style files.
> or 'missing dependencies'?
this is a bit vague, IMHO.
Jürgen
Why not simply: 'missing latex classes' or 'missing dependencies'?
Liviu
On 7/13/10, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> One idea is to mark such classes with an asterisk, as in the attached
>> patch and screenshot. Comments? Other ideas?
>
> I think we had an asterisk at first and
Peter Kümmel wrote:
> > I switch to Linux now, and test there the patched tarball. I give you a
> > Ok later, or ask for checkins ;)
> >
> >
>
> The files or ok on linux.
OK, thanks for testing.
Joost, I've uploaded new tarballs. Awaiting your feedback.
Jürgen
Peter Kümmel wrote:
> Jürgen Spitzmüller wrote:
>
>>> But now it compiles and installs with your patched lyx tarballs
>>> (already checked in) on msvc10. But the final word has Joost.
>> So you're done? Then I set up a hopefully final tarball later today (and let
>> Joost test it once more).
>
>
Am 13.07.2010 13:59, schrieb Uwe Stöhr:
We can easily convert this to:
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
\backslash
vref{
\end_layout
\end_inset
sec:dsf
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
}
\end_layout
\end_inset
Sorry, I meant to convert
Am 13.07.2010 05:23, schrieb Richard Heck:
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
Am 13.07.2010 05:13, schrieb Richard Heck:
I did some test and your implementation works fine for me except of
these:
1. insert a reference, select the style "Textual reference" and press
APPLY (don't close the dialog)
2. change the style to e.g. "Textual reference plus "
Result: the apply butt
Stephan Witt wrote:
> In case it is of interest...
>
> These files (as of 12.07.2010,13:17) are ok on mac too.
> Built successfully with autotools.
Thanks.
Jürgen
Am 12.07.2010 um 13:27 schrieb Jürgen Spitzmüller:
> Enrico Forestieri wrote:
>>> Joost, can you please try the new tarballs at
>>>
>>>
>>>ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz
>>>ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2 ?
>>
>> The file src/sup
Jürgen Spitzmüller wrote:
>> But now it compiles and installs with your patched lyx tarballs
>> (already checked in) on msvc10. But the final word has Joost.
>
> So you're done? Then I set up a hopefully final tarball later today (and let
> Joost test it once more).
I switch to Linux now, and t
Peter Kümmel wrote:
> OK, we are in a freeze, but the changes were essential, and you would have
> agreed for sure.
Yes, I would have. But this is not the point.
Jürgen
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
>> You wanna discuss CMake related changes with me?
>
> I want to know what happens at this stage before commits are made. It is hard
> to plan a release if I don't know what's going on behind the curtains.
>
> I suppose "no commits to branch whats
Jürgen Spitzmüller wrote:
>> I also saw a not deployed cygwin file:
>> development/cygwin/lyxrc.dist
>
> This is not my doing. I guess we just release all *.cpp's. Anyway, nothing to
> touch now.
I miss interpreted my diff, this file is released but not checked in,
so no problem here.
Peter
Peter Kümmel wrote:
> You wanna discuss CMake related changes with me?
I want to know what happens at this stage before commits are made. It is hard
to plan a release if I don't know what's going on behind the curtains.
I suppose "no commits to branch whatsoever" should be a sufficiently clear
Peter Kümmel wrote:
> but Joost is switching to cmake for this release and and
> we must iron out all shortcoming.
Right. Nevertheless I prefer you post patches to the list first at this stage
of the release. We are in a freeze, after all.
> And my fault was to build a checkout of branch, not yo
Jürgen Spitzmüller wrote:
> kuemmel wrote:
>> Author: kuemmel
>> Date: Tue Jul 13 11:04:17 2010
>> New Revision: 34885
>> URL: http://www.lyx.org/trac/changeset/34885
>>
>> Log:
>> cmake: also build the tarball with its additional files
>
> Peter,
> http://marc.info/?l=lyx-devel&m=127892390317798&
kuemmel wrote:
> Author: kuemmel
> Date: Tue Jul 13 11:04:17 2010
> New Revision: 34885
> URL: http://www.lyx.org/trac/changeset/34885
>
> Log:
> cmake: also build the tarball with its additional files
Peter,
http://marc.info/?l=lyx-devel&m=127892390317798&w=2
Jürgen
Jürgen Spitzmüller wrote:
> Kornel Benko wrote:
>> Some cmake-files are missing in development/Makefile.am.
>
> *Sigh*
Sorry Jürgen,
but Joost is switching to cmake for this release and and
we must iron out all shortcoming.
And my fault was to build a checkout of branch, not your tarballs.
But
Peter Kümmel wrote:
> For this release I wouldn't touch it, it's not really a show stopper, and
> most people on windows download the binaries.
> But we could fix it for future releases, and I could remember we already
> fixed a python script so we can feed it with a file which lists all the
> file
Joost Verburg wrote:
> On 7/12/2010 9:35 PM, Uwe Stöhr wrote:
>> Very nice!
>>
>> Can you please tell me how to compile LyX to achieve this? I'm still
>> stuck with your new compilation option and don't know where to specify it.
>
> Use CMake in Trunk and set LYX_NOCONSOLE.
Wouldn't it be better
Kornel Benko wrote:
> Am Dienstag 13 Juli 2010 schrieb Peter Kümmel:
>> Peter Kümmel wrote:
>>> Peter Kümmel wrote:
Peter Kümmel wrote:
> But there are other ones: the po file geneartion does not
> work, haven't we replaced the perl scripts?
>
> I'm looking at this, but I'm no
Am Dienstag 13 Juli 2010 schrieb Peter Kümmel:
> Peter Kümmel wrote:
> > Peter Kümmel wrote:
> >> Peter Kümmel wrote:
> >>> But there are other ones: the po file geneartion does not
> >>> work, haven't we replaced the perl scripts?
> >>>
> >>> I'm looking at this, but I'm no python scriper.
> >>
Peter Kümmel wrote:
> Peter Kümmel wrote:
>> Peter Kümmel wrote:
>>> But there are other ones: the po file geneartion does not
>>> work, haven't we replaced the perl scripts?
>>>
>>> I'm looking at this, but I'm no python scriper.
>> here the error:
>> Traceback (most recent call last):
>> Fi
59 matches
Mail list logo