On Thursday 03 September 2009 Uwe Stöhr wrote:
> Alex Fernandez schrieb:
> >> elyxer.py --directory $r $i $o
At least in shell for this to work you would need to use:
elyxer.py --directory "$r" "$i" "$o"
so that if the expanding variables has an empty space the arguments will be
self-contained.
Alex Fernandez schrieb:
elyxer.py --directory $r $i $o
and if the directory $r contains spaces, eLyXer fails to parse the
parameter set correctly.
I found the bug: to handle paths with spaces, python files need to be called
with the option -tt.
That's what we already do for all python script
Hi again,
2009/9/1 Alex Fernandez :
> Uwe Stöhr and I are trying to debug a weird issue with eLyXer that
> appears only on Windows, and only on certain machines. In these cases
> it appears that eLyXer 0.27 is not able to parse directories with
> spaces, while on other similar machines it works pe
Hi all,
is there anyone on this list knowing if there exists any open C/C++
library for regular expressions, with the capability to match balanced
braces arbitrarily nested ? .NET seems to have some extension for
solving such problem:
http://blogs.msdn.com/bclteam/archive/2005/03/15/396452.
On 09/03/2009 02:49 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
* DOCUMENT INPUT/OUTPUT
+- Do an emergency save if LyX attempts to destroy a dirty document
buffer. + This is a last resort to try to avoid data loss.
Richard, the status file has an "Updates" and a "Bug Fixes" section
Hi Vincent,
As I explained in my previous email, that this piece of code is inserted
by Lyx itself.
I tried adding \makeletter before this piece of code, the problem
remains the smae.
Is there a way to restrict Lyx from inserting this piece of code?
Regards,
Tariq Abdullah
P.S: I copied the
>Can some help me in solving a Lyx problem described
>in the forwarded email?
It seems you're missing a \makeatletter before this piece of code. Did
you add this yourself in the preamble ?
>Regards,
>Tariq Abdullah
Vincent
Hi all,
Can some help me in solving a Lyx problem described in the forwarded email?
Regards,
Tariq Abdullah
--- Begin Message ---
Hi Vincent,
\...@ifundefined{showcaptionsetup}{}{%
\PassOptionsToPackage{caption=false}{subfig}}
\usepackage{subfig}
\makeatother
\usepackage{babel}
I get the fo
Uwe Stöhr wrote:
When I find the time, I'll try to build a portable LyX. (I don't know if
this is possible because LyX uses many other third-party programs that
might not be ready for that.)
It should be no problem. The Ghostscript and ImageMagick files that are
included in my installers are
Vincent van Ravesteijn - TNW ha scritto:
I'd think that backporting a few of those features
to the normal find dialog/bar is not a major task.
I mean, the search bar can use the same find&replace backend, right ?
If you mean using the Advanced F&R backend, I think it may be used as
wel
Abdelrazak Younes ha scritto:
I haven't said it was bad, I only (sort of) said that if you propose
a patch, you can ease the process by telling why you want to do it
and why it would be good.
It indeed looks a bit strange to have this hardcoded value instead of
the runparams, so I think the p
Vincent van Ravesteijn - TNW wrote:
I'd think that backporting a few of those features
to the normal find dialog/bar is not a major task.
I mean, the search bar can use the same find&replace backend, right ?
Right, easy stuff.
So, we only have to add the possibility to the GUI.
>I'd think that backporting a few of those features
>to the normal find dialog/bar is not a major task.
I mean, the search bar can use the same find&replace backend, right ?
So, we only have to add the possibility to the GUI.
>Abdel.
Vincent
>>
>> What is the others' opinion on this ?
>
>I agree, sort of. All "search" tickets should be
>migrated to F&R dialogue. But we need first a simple
>statusbar find ala firefox so we can kill current
>find dialog.
I already made such a statusbar find thingie, but didn't finish it yet.
And if we
Tommaso Cucinotta wrote:
As time elapses, more and more of the features attached to the
"search" component are likely to be implemented in the advanced F&R,
but still be missing in the simple search facility.
As of now, this forbids closure of corresponding bugs (in a few of
them there is the
Vincent van Ravesteijn wrote:
Tommaso Cucinotta schreef:
Tommaso Cucinotta ha scritto:
Vincent van Ravesteijn ha scritto:
anyone against this patch ? It uses OutputParams.linelen to
control newlines also on LaTeX exports, additionally to plaintext
ones.
Yes, I'm against.
You give no reason
16 matches
Mail list logo
