Peter Kümmel wrote:
> Bo Peng wrote:
>> On 5/26/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>>> Abdelrazak Younes wrote:
Elazar Leibovich wrote:
> ּstill segfaults for me in rev 18528
I will solve that once I agree with Bo how to go forward.
>>> Should we revert until we know what to
Bo Peng wrote:
> On 5/26/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>> Abdelrazak Younes wrote:
>> > Elazar Leibovich wrote:
>> >> ּstill segfaults for me in rev 18528
>> > I will solve that once I agree with Bo how to go forward.
>> Should we revert until we know what to do?
>
> I can not apply
Dov Feldstern wrote:
> (I hope I'm referring to the correct version of the patch:) As Helge
> already reported, on very slow systems (I tested this by running under
> valgrind), if you type quickly, some keystrokes get swallowed...
Nice idea to slow down with valgrind.
I've reproduced the error a
On 5/27/07, Martin Vermeer <[EMAIL PROTECTED]> wrote:
On Fri, May 25, 2007 at 01:01:54AM +0300, Elazar Leibovich wrote:
> This patch solves completely the issue of wrong display of the
> cursor
> when it is right in front of an RTL set.
> Normally when a cursor is in an inset in RTL mode, it's po
On Sat, May 26, 2007 at 09:57:35PM -0400, Richard Heck wrote:
> Dov Feldstern wrote:
> >Stefan Schimanski wrote:
> >>In the last patch there was a bug with the script code in math.
> >>Fixed that. So here it is again. While looking through the
> >>FINISHED_UP/DOWN stuff I am starting to think tha
On Fri, May 25, 2007 at 01:01:54AM +0300, Elazar Leibovich wrote:
> This patch solves completely the issue of wrong display of the
> cursor
> when it is right in front of an RTL set.
> Normally when a cursor is in an inset in RTL mode, it's position
> is
> being calculated in the following manner
On 5/26/07, Richard Heck <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Elazar Leibovich wrote:
>> ּstill segfaults for me in rev 18528
> I will solve that once I agree with Bo how to go forward.
Should we revert until we know what to do?
I can not apply Abdel's patch (gmail space/tab pr
Abdelrazak Younes wrote:
Elazar Leibovich wrote:
ּstill segfaults for me in rev 18528
I will solve that once I agree with Bo how to go forward.
Should we revert until we know what to do?
rh
Dov Feldstern wrote:
Stefan Schimanski wrote:
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I
don't create those LFUNs anymore, and still
Peter Kümmel wrote:
José Matos wrote:
On Friday 25 May 2007 18:11:28 Peter Kümmel wrote:
I still think my scrolling patch
http://marc.info/?l=lyx-devel&m=117968102228177&w=2
is better than nothing. Try to scroll on Linux
with and without the patch, and at least when scrolling
with keys you will
Stefan --- now that you're an expert on cursor movement and boundary and
all, do you think you could tackle a small remaining problem with bidi
cursor movement, which I think is very much connected with what you've
been working on here? I just created a new bug for it in bugzilla:
http://bugzil
Stefan Schimanski wrote:
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I don't
create those LFUNs anymore, and still cursor handling seems
> Objections, patches to consider, etc...
Only a patch: I would like to have the next unicodesymbols patch in because this is another step to
better unicode support:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg118499.html
If this is too late for pre1 it would be nice if it can go in
The attached patch implements all, except of 5, characters reported by the
users in bug 3673.
- the math characters used by Windows also for text that are not
supported by textcomp are implemented as math characters using
\ensuremath. Instead of \ensuremath{..} I can also use $..$, what is
better
The attached patch implements all characters reported by the users in bug 3673.
- the math characters used by Windows also for text that are not supported by textcomp are
implemented as math characters using \ensuremath. Instead of \ensuremath{..} I can also use $..$,
what is better?
- the fr
Le 26 mai 07 à 22:11, Mael Hilléreau a écrit :
I found in the source (LyX 1.4.4) the function call (file
converter.C, line 313):
bool Converters::convert(Buffer const * buffer,
string const & from_file, string const & to_file_base,
string cons
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug
3639. Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more gu
Jean-Marc Lasgouttes wrote:
I would tend to think that _some_ of the callers to cursorX need to
apply Martin's test by themselves, but that the code does not belong
in the method itself. However, I am just waving hands, I do not have
time to look at the code long enough.
I don't see why you fe
> It depends on what LateX accept. If \alpha can be recognized directly by
LateX (maybe with
> textcomp?), I see no reason to encasulate that in a TeX formula.
No, \alpha can't be read by LaTeX in text mode and I don't want to add all greek characters, only
the math characters widely used also
Uwe Stöhr wrote:
While working on the unicodesymbols stuff I took some Word-files to test
if I can copy text from Word to LyX. This is still not in every case
working because Windows and Word provide the following math characters
to be used directly in texts that have curently no entry in the
I just see that I yesterday accidentally used the CJK brackets and not the misc. math symbols-a
brackets. The webpage I referred to is in this case wrong. Again a corrected patch attached.
As the patch is obvious and I got the OK from José and Jürgen to add all textcomp-characters I'll
put this
Bo Peng wrote:
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
p
This issue should be solved before LyX 1.5.0 because we promise unicode support
and I expect many
complains when the users can't copy text into LyX without getting encoding
errors.
I agree with this although I have no idea about the implementation.
Bo
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
parValidator(key)
>> -- let the user choose from a list a delimiter, or
>> -- do not choose \ & @ # ^ _ ~ $ as delimiter
Fixed in r18529.
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp(revision 18528)
+++ src/insets
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]>
wrote:
Bo Peng wrote:
>> It is cleaner,
>
> I prefer {} initialization to a bunch of assignments. I like neither
> static bool firsttime, nor the fact that stylehint is repeated several
> times.
This is just cosmetic, I could have
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> It is cleaner,
>
> I prefer {} initialization to a bunch of assignments. I like neither
> static bool firsttime, nor the fact that stylehint is repeated several
> times.
This is just cosmetic, I could have just put the in
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I
don't create those LFUNs anymore, and still cursor handling seems ok.
Stefan
cursor
Bo Peng wrote:
> On 5/26/07, Herbert Voss
> <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED]
>> as inline listing doesn't work, because the inset uses
>> # as delimiter, which is not allowed.
>>
>> -- let the user choose from a list a delimiter, or
>> -- do not choose \ & @ # ^ _ ~ $ as delimiter
>
Elazar Leibovich wrote:
ּstill segfaults for me in rev 18528
I will solve that once I agree with Bo how to go forward.
Abdel.
On 5/26/07, Richard Heck <[EMAIL PROTECTED]> wrote:
As said. I believe this has to do with the use of _() in initialization
code.
Richard
--
ּstill segfaults for me in rev 18528
On 5/26/07, Richard Heck <[EMAIL PROTECTED]> wrote:
As said. I believe this has to do with the use of _() in initialization
code.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left arrow
key, starting from the top, the cursor will be stucked between the end
of the third (RTL) line and the beginning of the f
Le 26 mai 07 à 18:31, Mael Hilléreau a écrit :
Would it be possible to enable the MacOS version of LyX to work
with graphics stored as MacOS packages? I mean would it be possible
to replace the kind of "test -f $$i" by a kind of "test -r $$i" in
order to check for folders too?
I found in
Mostafa Vahedi wrote:
Dov Feldstern <[EMAIL PROTECTED]> wrote:
> Mostafa Vahedi wrote:
I have sent this email before but it was forgotten.
> > I am sending the patches again. To add Farsi
> > Support these four files are modified namely:
Encoding.cpp, Text.cpp, rowpainter.cpp, and
>
atm it is not possible to set horizontal lines that don't span the whole
column (*except* by resorting to multicolumn cells). in other words we
don't have proper cline support.
moreover, the behavior of the toolbar and dialog are inconsistent: the
toolbar only sets complete lines whereas the d
Bo Peng wrote:
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
This is just cosmetic, I could have just put the initialisation code in
the ParValidator constructor.
saves co
While working on the unicodesymbols stuff I took some Word-files to test if I can copy text from
Word to LyX. This is still not in every case working because Windows and Word provide the following
math characters to be used directly in texts that have curently no entry in the unicodesymbols file:
Uwe Stöhr schrieb:
I forgot yesterday to add some symbols that are supported by textcomp. I
promised to include all supported characters so attached is the trivial
patch to achieve this now really.
I forgot the minus sign. Take the attached patch.
Uwe
Index: unicodesymbols
==
I forgot yesterday to add some symbols that are supported by textcomp. I promised to include all
supported characters so attached is the trivial patch to achieve this now really.
The patch also fixes a bug about the paragraph symbol: The unicode name is "PILCROW SIGN" but
\textpilgrow produces
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
saves code for the searching
maybe.
and the sorting is automatic.
Why is that? You mean things in a map is ordered by keyword?
So here is a version using the dispatch system. The table works now
as well (though some behavior is questionable. But it's as well in
the Beta 3, so not matter of my patch).
As written in previous mail, I have no clue about the FINISHED_UP/
DOWNs. I don't "send" them anymore from anywhere, an
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Ozgur Ugras BARAN wrote:
>> Attached patch sorts listings inset params, and hence solves bug
3639.
>> Please somebody review and apply the patch.
>>
>> I could also sort the listings_param_table[
For some reason, changing the type of the dialog switches the default
button from OK to Cancel. This restores the correct default. Must be a
QT bug.
Seeking two OKs.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown Univers
I had a very nice version of the patch, until I found out that tables
navigation is gone. The reason is that we have to use the LFUN_UP/
DOWN architecture with the dispatch mechanism to reach all the insets
which might want to implement custom cursor movement.
So I converted everything back
On 5/26/07, Herbert Voss <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED]
as inline listing doesn't work, because the inset uses
# as delimiter, which is not allowed.
-- let the user choose from a list a delimiter, or
-- do not choose \ & @ # ^ _ ~ $ as delimiter
I think I tested #, as well as _ ^
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Ozgur Ugras BARAN wrote:
>> Attached patch sorts listings inset params, and hence solves bug 3639.
>> Please somebody review and apply the patch.
>>
>> I could also sort the listings_param_table[] entries manually
Abdelrazak Younes wrote:
> Richard Heck wrote:
>> Abdelrazak Younes wrote:
>>> Richard Heck wrote:
The attached patch addresses this bug. The idea is to leave the TOC
(e.g.) open when closing one buffer, if there is still one open.
>>> Instead, I think we should rather make the TOC non b
As said. I believe this has to do with the use of _() in initialization
code.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
[EMAIL PROTECTED]
as inline listing doesn't work, because the inset uses
# as delimiter, which is not allowed.
-- let the user choose from a list a delimiter, or
-- do not choose \ & @ # ^ _ ~ $ as delimiter
Herbert
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one st
http://bugzilla.lyx.org/show_bug.cgi?id=3522
reviewed and approved by Georg.
The patch does the following:
- it moves all the encoding checks in BufferParams::writeLaTeX to
an own function "writeEncodingPreamble" and (so in BufferParams.cpp
most is just code-shuffling)
- accesses that from
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one step further and used a map
Jürgen Spitzmüller wrote:
> Herbert Voss wrote:
>> -> XeTeX
>
> So dvipdfmx is still the right thing to choose, unless people use XeTeX
> (where
> they currently need to change the converters manually anyway).
I never used it but I suppose, that using xdvipdfmx doesn't hurt, it
does the same an
Hi developers,
I wrote an applescript to enable converters for OmniGraffle graphics
format (see "A shell for launching figure editor under Mac OS" thread
in lyx-users list, or the LyX Mac wiki). However, I found that LyX
doesn't support graphics if they are stored as Mac OS X packages. Mac
Herbert Voss wrote:
> -> XeTeX
So dvipdfmx is still the right thing to choose, unless people use XeTeX (where
they currently need to change the converters manually anyway).
Jürgen
Michael Gerz wrote:
> [EMAIL PROTECTED] schrieb:
>> Author: rgheck
>> Date: Mon May 21 17:34:29 2007
>> New Revision: 18445
>>
>> @@ -405,6 +410,18 @@
>> return 0;
>>
>> +if (buffer.fileName() == included_file.toFilesystemEncoding()) {
>> +Alert::error(_("Recursive input"), +
Martin Vermeer wrote:
> I'm impressed that somebody actually understands this stuff.
>
Me, too.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
===
Jürgen Spitzmüller wrote:
> Herbert Voss wrote:
>>> dvipdfmx is neither useless nor outdated:
>>> http://project.ktug.or.kr/dvipdfmx/
>> dvipdfm is useless ...
>
> But we use dvipdfmx (if available).
>
>> there is also a xdvipdfmx
>
> what's its benefit?
-> XeTeX
Herbert
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Here
On Fri, 25 May 2007 07:02:58 -0700 (PDT)
Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
>
> Dov Feldstern <[EMAIL PROTECTED]> wrote:
> > Mostafa Vahedi wrote:
> > > I noticed that:
> > > 1) in Bidi.cpp the computeTables method does not
> > > process the text inside ERT-inset.
> > > 2) the language of
On Fri, 25 May 2007 07:32:21 -0700 (PDT)
Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
>
> Elazar Leibovich <[EMAIL PROTECTED]> wrote:
>
> > > Yes. The backend is OK. The problem is just the
> > > presentation. I encounter the same problem when I want
> > > to use "Box" (i.e. "\mbox{}" in LaTeX te
Bo Peng wrote:
+docstring empty_hint;
+docstring style_hint = _("Use \\footnotesize, \\small, \\itshape,
\\ttfamily or something like that");
+docstring frame_hint = _("none, leftline, topline, bottomline, lines,
single, shadowbox or subset of trblTRBL");
+docstring frameround_hint =_("Ente
Abdelrazak Younes wrote:
> Already done ;-)
merci beaucoup :-)
Jürgen
+docstring empty_hint;
+docstring style_hint = _("Use \\footnotesize, \\small, \\itshape, \\ttfamily or
something like that");
+docstring frame_hint = _("none, leftline, topline, bottomline, lines, single,
shadowbox or subset of trblTRBL");
+docstring frameround_hint =_("Enter four letters (
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
+ { "emptylines", "", false, ALL, "", from_ascii("Expect a number
with an optional * before it") },
please mark this translatable as well:
+ { "emptylines", "", false, ALL, "", _("Expect a number with an
optional * before it") },
Abdelrazak Younes wrote:
> + { "emptylines", "", false, ALL, "", from_ascii("Expect a number
> with an optional * before it") },
please mark this translatable as well:
+ { "emptylines", "", false, ALL, "", _("Expect a number with an
optional * before it") },
Jürgen
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Here is it. The bonus is that
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Abdel.
ugras
On 5/26/07, Bo Peng <[EMAIL PROTECTED]>
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
ugras
On 5/26/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> Indeed, I am agree with Alfredo on this issue. Therefore I have
> attached another patch
Bo Peng wrote:
> In the good old days,
laudatio temporis acti ...
> string is considered as expensive compared to
> char *, and now you want to use docstring?
saves us a few conversions.
> I agree to change it to docstring. :-)
Fine.
Jürgen
Bo Peng wrote:
On 5/26/07, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> -char const * hint;
> +string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *,
Memory and CPU wise the overhead is minima
Do you like if I apply other suggestions of the web site for lyx development? :)
Sure, just do not bring up the 'char const' issue. :-)
Cheers,
Bo
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
OK.
Abdel.
Indeed, I am agree with Alfredo on this issue. Therefore I have
attached another patch which uses string() for comparison. Use
whichever you think is best.
+ string suffix(name,1);
+ string pars;
+ for(pariter = parlist.begin(); pariter != parlist.end();
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table) ?
> But it is more difficult to read, IMHO.
Yes. You could as well use:
if (listings_param_table[idx].name[0])
:D I guess, I remember this from hilarious web site "how to write an
Yes. You could as well use:
if (listings_param_table[idx].name[0])
This is what lyx usually uses, and what I will do if I am awake enough
not to use == "".
Cheers,
Bo
On 5/26/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> -char const * hint;
> +string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *, and now you want to use docstring?
I agree to change it to
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place
Abdelrazak Younes wrote:
> - char const * hint;
> + string hint;
Can you make it a docstring instead?
Jürgen
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table)
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
But it is more difficult to read, IMHO.
Ugras
Use string::empty() instead.
Abdel.
Herbert Voss wrote:
> > dvipdfmx is neither useless nor outdated:
> > http://project.ktug.or.kr/dvipdfmx/
>
> dvipdfm is useless ...
But we use dvipdfmx (if available).
> there is also a xdvipdfmx
what's its benefit?
Jürgen
Jürgen Spitzmüller wrote:
> Michael Gerz wrote:
>> I wonder whether we should drop the dvipdfm path for 1.5.X. Is anybody
>> actually using this (possibly outdated) tool? Offering tree ways to
>> generate PDF may cause more confusion than it brings benefits.
>
> No.
> dvipdfmx is neither useless n
Jean-Marc Lasgouttes schrieb:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> As said. This seems a very sensible idea. Accidental
Richard> reversion is bad.
I like it. In the same vein, I would propose to add the following. It
is not an action that requires a sho
Michael Gerz wrote:
> I wonder whether we should drop the dvipdfm path for 1.5.X. Is anybody
> actually using this (possibly outdated) tool? Offering tree ways to
> generate PDF may cause more confusion than it brings benefits.
No.
dvipdfmx is neither useless nor outdated:
http://project.ktug.or.k
Neal Becker schrieb:
Oh, I did get an answer. Unfortunately, I can't seem to find the message
right now, but the answer is, that I need to make that agr->pdf instead of
agr->pdf2.
There was also a discussion that the use of pdf{,2,3} was really a broken
design.
I wonder whether we shoul
I'm impressed that somebody actually understands this stuff.
- Martin
[EMAIL PROTECTED] schrieb:
Author: rgheck
Date: Mon May 21 17:34:29 2007
New Revision: 18445
@@ -405,6 +410,18 @@
return 0;
+ if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+ Alert::error(_("Recursive input"),
+ bformat(_("Attempted to includ
Stefan Schimanski wrote:
Am 26.05.2007 um 11:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release.
Am 26.05.2007 um 11:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today
than tomorrow evening ten minutes before the release. As far as
I can tell i
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell
it works fine and there are no immediate show stoppers
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today
than tomorrow evening ten minutes before the release. As far as I
can tell it works fine and there are no immediate show stoppers in
the patch. But by
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell it
works fine and there are no immediate show stoppers in the patch. But by
committing it now others might test it at least a bit be
Ozgur Ugras BARAN wrote:
5. I would appreciate it you can also implement
?xx ==> all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx ==> all parameters that
prefixIs(xx), and other paramet
5. I would appreciate it you can also implement
?xx ==> all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx ==> all parameters that
prefixIs(xx), and other parameters that contains(xx).
I
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell
it works fine and there are no immediate show stoppers in the patch.
But by committing it now others might test it at least a bit before
releasing it to
Am 26.05.2007 um 10:16 schrieb Alfredo Braunstein:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Stefan Schimanski wrote:
So, the first P.S. is history now. I added an offset from the
x_target after moving to the next line. Using that the cursor knows
when it is actually meant to be o
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Stefan Schimanski wrote:
>>
>>> So, the first P.S. is history now. I added an offset from the
>>> x_target after moving to the next line. Using that the cursor knows
>>> when it is actually meant to be on the target, but had to move
>>> slig
Am 26.05.2007 um 09:51 schrieb Stefan Schimanski:
Am 26.05.2007 um 09:32 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left
arrow key, starting from the top, the cursor wi
Am 26.05.2007 um 09:32 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left
arrow key, starting from the top, the cursor will be stucked
between the end of the third (RTL) li
1 - 100 of 109 matches
Mail list logo
