Bo Peng wrote:
Hi Bo,
1. table[idx].name is char * so != is better because no conversion
would be needed.
... and then you'll be comparing pointers, which is probably not what you
want... afaict the original patch was correct in this respect.
Regards
A/
PS: incidentally this may work
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 buffer-dependant.
But it's not just the
Am 26.05.2007 um 09:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
P.S.: One minor known problem is that big insets (like labels)
might move the target_x value. This should be tackled later as
well, but not now.
Hum, this problem is not so minor as the the up/down arrow key are
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 fourth (LTR) line.
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
slightly left or right to be between character.
It's strange that an
Stefan Schimanski wrote:
Am 26.05.2007 um 09:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
P.S.: One minor known problem is that big insets (like labels) might
move the target_x value. This should be tackled later as well, but
not now.
Hum, this problem is not so minor as the the
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
slightly left or right to be between character.
Trying to find the in-mathed blocking reason now
This is caused (again) by a wrong boundary flag :-/ There must be
more place than cursorLeft/Right which do not care about boundaries.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
It's strange that an additional offset is needed. It is something
specific
for RTL? It used to work as following: target_x was never touched
on cursor
up and down, but adjusted on all other cursor movements.
When I cleaned up this, the target_x was touched everywhere :-). So
I decided
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)
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
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
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
slightly left or
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
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
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
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
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:
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
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
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
[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 include
I'm impressed that somebody actually understands this stuff.
- Martin
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 should
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:
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
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 nor
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
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.
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)
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
Jürgen
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
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
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
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
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 !=
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
OK.
Abdel.
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
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 minimal.
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
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
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]
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
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
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) },
Already done
+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
Abdelrazak Younes wrote:
Already done ;-)
merci beaucoup :-)
Jürgen
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 =_(Enter
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 terms) inside
math
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 the text of an
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.
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
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/
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), +
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
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
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 and it
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
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
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
[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
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/
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 buffer-dependant.
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, but I
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 _ ^ $
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
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
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[] entries
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, and
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
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 a
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
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
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
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
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
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 the
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
ּ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
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
--
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
I think I
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
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
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 just
-- 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)
+++
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
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
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
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
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
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
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
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
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 const
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
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
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
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
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:
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-develm=117968102228177w=2
is better than nothing. Try to scroll on Linux
with and without the patch, and at least when scrolling
with keys you will
1 - 100 of 212 matches
Mail list logo
