On Mon, 28 May 2007, Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
| > | + ListingsParam(string const & v, bool o, param_type t,
| > | + string const & i, docstring const & h)
| > | : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| > |{}
| > | - ///
|
Angus Leeming wrote:
> Peter Kümmel wrote:
>> Yes, I also don't like the hardcoding. The problem is that if we start
>> to drop events we have to differentiate between good and bad events, and
>> it is hard to find a solution for all cases. So it would be better not
>> to drop any key. But what is
Angus Leeming wrote:
Koji, could you grant LyX permission to license your contributions
under the Gnu General Public License version 2 *or later*.
That will give us the flexibility to upgrade the LyX licence to
version 3 of the GPL as and when it arrives.
Angus, there is no problem in doing so
Peter Kümmel wrote:
feed_the_troll("Do we really wanna upgrade to version 3?") ;)
That's for you guys, the active developers, to decide. What I'm trying to
do here is to give you the freedom to make that decision.
Angus
Peter Kümmel wrote:
Yes, I also don't like the hardcoding. The problem is that if we start
to drop events we have to differentiate between good and bad events, and
it is hard to find a solution for all cases. So it would be better not
to drop any key. But what is the alternative? A XSync call cou
Angus Leeming wrote:
> Koji Yokota wrote:
>> Uwe Stöhr wrote:
>>> could you give us the permission to use your work under the GPL
>>> version 2?
>> Yes. I agree with it.
>
> Sorry to butt in guys, but...
>
> Koji, could you grant LyX permission to license your contributions under
> the Gnu Genera
Koji Yokota wrote:
No, I have to be more formal :)
---
Hereby I grant permission to use the Japanese message file (ja.po) of
LyX under the GPL version 2.
Thanks, but it would be nice if
1. Your permission statement didn't mention ja.po explicitly.
2. Allowed us to upgrade to version 3 of the
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> I've reproduced the error and fixed it. The problem was, not
> Peter> only page up/down keys were dropped. This code does not work
> Peter> (because of the implicit casts?)
>
> Peter> static const in
Koji Yokota wrote:
Uwe Stöhr wrote:
could you give us the permission to use your work under the GPL
version 2?
Yes. I agree with it.
Sorry to butt in guys, but...
Koji, could you grant LyX permission to license your contributions under
the Gnu General Public License version 2 *or later*.
Uwe Stöhr wrote:
could you give us the permission to use your work under the GPL
version 2?
If you agree, please reply an email to this list stating:
"Hereby I grant permission...
thanks and regards
Uwe
No, I have to be more formal :)
---
Hereby I grant permission to use the Japanese mess
Peter Kümmel wrote:
> Lars Gullik Bjønnes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik Bjønnes wrote:
>> | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>> | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
>> | > writes:
>> | > | | | > "Peter" == Peter Kümmel
>>
Lars Gullik Bjønnes wrote:
> | > (At the time I felt that the patch was a bit hackish, X11 only and had
> | > too little testing.)
Do you know QApplication::syncX, but it is maybe call to XSync with false.
I've also used XSync in the scroll event but then the scrolling behavior
was really bad.
Uwe Stöhr wrote:
could you give us the permission to use your work under the GPL
version 2?
Yes. I agree with it.
Koji
Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
> | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
> | > writes:
> | > | | | > "Peter" == Peter Kümmel
> | > <[EMAIL PROTECTED]> write
Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> |
> | | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
> | |
> | | Peter> I've reproduced the error and fixed it. The problem was, not
> | | Peter> onl
Dov Feldstern wrote:
> Jean-Marc Lasgouttes wrote:
>>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>>
>> Peter> I've reproduced the error and fixed it. The problem was, not
>> Peter> only page up/down keys were dropped. This code does not work
>> Peter> (because of the implicit casts?)
Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
> |
> | Peter> I've reproduced the error and fixed it. The problem was, not
> | Peter> only page up/down keys were dropped. This code does not work
> | Pet
On 5/27/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Can you please refer me to where in the source code is a single
> character directionality is handled?
>
What exactly do you mean? The "direction" (RTL/LTR) of a character is
determined by it's language, and each char
Attached is the patch including Georg's advices. Can this go in?
+1 for RC1 testing.
Cheers,
Bo
Hello Koji,
could you give us the permission to use your work under the GPL version 2?
If you agree, please reply an email to this list stating:
"Hereby I grant permission...
thanks and regards
Uwe
Peter Kümmel wrote:
Hasn't Abdel fixed it today? Maybe updating helps.
Yeah, right. With a newer version, Lyx at least proceeds with a
successful initialization and its GUI appears. However, trial of File ->
New, File -> Open, or start of lyx with a parameter like 'lyx -dbg any'
leads to the
Edwin Leuven wrote:
updated patch attached:
igonore the previous one, and use the one attached instead and it:
- takes into account booktabs
- fixes a bug where topline in 1st row and bottom line in last row were
not set with booktabs (create a booktabs table without lines to check)
- fixes
> Seems obvious enought that it can't be wrong:
>
> OK from me.
+1
regards Uwe
Lars Gullik Bjønnes wrote:
| > | + ListingsParam(string const & v, bool o, param_type t,
| > | + string const & i, docstring const & h)
| > |: value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| > |{}
| > | - ///
| > | + /// Validate a paramate
| > Are multiline comments usgin '//' really nice? I'd say that /* */ is
| > better suited for multiline comments.
|
| I don't really care.
And suddenly you showed me why I stay away from this list.
It has been a while since we saw this kind of Lars vs Abdel fight last
time, and I enjoy it.
T
José Matos wrote:
On Sunday 27 May 2007 19:27:10 Edwin Leuven wrote:
i am not on a crusade here, but as said, it is tiny and gives something
relatively big.
oh, and it solves an inconsistency between the dialog and the toolbar
(am i allowed to call that a bug? ;-)
Jürgen what is your opinio
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | | + ListingsParam(string v, bool o, param_type t, string i,
docstring h)
| > | > | + : value_(v), onoff_(o), type_(
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > | > writes:
| > | > | | | >>>
Dov Feldstern wrote:
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4
exactly (see attached).
I think this is one step too far. There were bugs with the 1.4 logic
that were causing a crash, that's what I fixed a couple of weeks ago
(r18389). I thin
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| | + ListingsParam(string v, bool o, param_type t, string i, docstring h)
| > | + : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| > const ref strings please.
|
| I've don
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4 exactly
(see attached).
I think this is one step too far. There were bugs with the 1.4 logic
that were causing a crash, that's what I fixed a couple of weeks ago
(r18389). I think you copied the bug t
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > writes:
| > | | | > "Peter" == Peter Kümmel
| > <[EMAIL PROTECTED]> writes:
| > | | | |
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > writes:
| > | | | > "Peter" == Peter Kümmel
| > <[EMAIL PROTECTED]> writes:
| > | | | | Peter> I've reproduced the e
Stefan Schimanski wrote:
Patch is attached to the bug: http://bugzilla.lyx.org/show_bug.cgi?id=3310
Seems obvious enought that it can't be wrong:
Index: src/BufferView.cpp
===
--- src/BufferView.cpp (Revision 18515)
+++ src/Buffe
Am 28.05.2007 um 00:43 schrieb Dov Feldstern:
Dov Feldstern wrote:
In cursorLeft, for example: what is the condition "cur.lastpos() !
= cur.pos()" for?
And "cur.textRow().pos() == cur.pos()" (what does it even mean?)?
textRow().pos() returns the position of the first character in the
pa
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| | + ListingsParam(string v, bool o, param_type t, string i, docstring h)
| > | + : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| > const ref strings please.
|
| I've done that and added/fixed some more D
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/dow
Patch is attached to the bug: http://bugzilla.lyx.org/show_bug.cgi?
id=3310
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
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 wi
Lars Gullik Bjønnes wrote:
| +ListingsParam(string v, bool o, param_type t, string i, docstring h)
| + : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
const ref strings please.
I've done that and added/fixed some more Doxygen comments.
Abdel.
Author: younes
Date: Mon Ma
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/dow
Yes, I think your explanation of the concept is correct. Andre' gave a
few other examples, such as between italics and normal text. If you're
exactly on the boundary, should the next typed character be italic or
normal? And of course there's a similar situation between RTL and
LTR...
What I do
Dov Feldstern wrote:
In cursorLeft, for example: what is the condition "cur.lastpos() !=
cur.pos()" for?
And "cur.textRow().pos() == cur.pos()" (what does it even mean?)?
textRow().pos() returns the position of the first character in the
paragraph which belongs to the current row. So this
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/down keys were dropped. This code
Stefan Schimanski wrote:
As far as I think to understand, boundary is set on line limits. If you
have a line like
"foo "
"bar"
the boundary flag is set if you are behind the space in the first line.
In the beginning of the first the boundary flag is false, but you use
the same position. That
This drawer patch should go in:
http://bugzilla.lyx.org/show_bug.cgi?id=3500
Stefan
Am 25.05.2007 um 16:57 schrieb José Matos:
Hi,
are we ready for RC1, in the goals that I have stated to RC1 I had
proposed a
week between beta 3 and release candidate 1 to avoid any error that
had
evaded
As far as I think to understand, boundary is set on line limits. If
you have a line like
"foo "
"bar"
the boundary flag is set if you are behind the space in the first
line. In the beginning of the first the boundary flag is false, but
you use the same position. That's why it needed.
As
Jean-Marc Lasgouttes wrote:
"Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I've reproduced the error and fixed it. The problem was, not
Peter> only page up/down keys were dropped. This code does not work
Peter> (because of the implicit casts?)
Peter> static const int delayed_keys =
Jean-Marc Lasgouttes wrote:
"Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> So, if we move Martin's test out of cursorX, we're going to have
Dov> to add it in 4 or 5 new places.
Very good argument. Thanks for checking.
Dov> Finally, (a) Martin's test has been in for a while (since r10
Elazar Leibovich wrote:
Can you please refer me to where in the source code is a single
character directionality is handled?
What exactly do you mean? The "direction" (RTL/LTR) of a character is
determined by it's language, and each character has a language
associated with it... but I'm not
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
|
| Peter> I've reproduced the error and fixed it. The problem was, not
| Peter> only page up/down keys were dropped. This code does not work
| Peter> (because of the implicit casts?)
|
|
Stefan Schimanski wrote:
Fixed that and restored the old behaviour.
Stefan
I see we're playing this game again :) . I just sent in a slightly
different solution! As I keep saying though, I don't really understand
what's going on here... So if you *understand* your solution, it's
probably
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I've reproduced the error and fixed it. The problem was, not
Peter> only page up/down keys were dropped. This code does not work
Peter> (because of the implicit casts?)
Peter> static const int delayed_keys = Qt::Key_PageDown |
Peter
Can you please refer me to where in the source code is a single
character directionality is handled?
Dov Feldstern wrote:
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch d
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> So, if we move Martin's test out of cursorX, we're going to have
Dov> to add it in 4 or 5 new places.
Very good argument. Thanks for checking.
Dov> Finally, (a) Martin's test has been in for a while (since r10513,
Dov> 10/2005), I don
Hmmm... there are some minor changes in the behavior of LyX due to
your patches. For example, in a paragraph which spans multiple
lines: if you move back (left in LTR) from the first position in
the line, you used to be placed immediately after the last letter
on the previous line. Now, y
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch does and these issues.
Stefan Schimanski wrote:
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
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 w
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch does and these issues.
On Sunday 27 May 2007 19:27:10 Edwin Leuven wrote:
> i am not on a crusade here, but as said, it is tiny and gives something
> relatively big.
>
> oh, and it solves an inconsistency between the dialog and the toolbar
> (am i allowed to call that a bug? ;-)
Jürgen what is your opinion on this?
>> - 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?
>
> \ensuremath.
OK.
> I agree with Jürgen that the ordinary greek characters 0
José Matos wrote:
On Sunday 27 May 2007 18:32:16 Edwin Leuven wrote:
the only problem with my cline support patch comes from the fact lyx
spits out a lot of garbage in the tabular settings (so not really a
problem with my patch but rather with our crappy tabular code)
Edwin,
I am not sure now
>> c/o,
>
> I'm not aware of an approach to directly access the symbol, but this is the
> most frequent macro (used in tugboat):
>
> \def\careof{\leavevmode\hbox{\raise.75ex\hbox{c}\kern-.15em
> /\kern-.125em\smash{\lower.3ex\hbox{o}}} \ignorespaces}
Thanks, this looks good but I
On Sunday 27 May 2007 18:32:16 Edwin Leuven wrote:
> the only problem with my cline support patch comes from the fact lyx
> spits out a lot of garbage in the tabular settings (so not really a
> problem with my patch but rather with our crappy tabular code)
Edwin,
I am not sure now is the r
Am Sonntag, 27. Mai 2007 02:06 schrieb Uwe Stöhr:
> 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.
the only problem with my cline support patch comes from the fact lyx
spits out a lot of garbage in the tabular settings (so not really a
problem with my patch but rather with our crappy tabular code)
to illustrate -- and remember: line settings at the cell level are
currently ignored *except*
On Sunday 27 May 2007 14:59:15 Jürgen Spitzmüller wrote:
> OK to apply?
OK.
> Jürgen
--
José Abílio
On Sunday 27 May 2007 14:00:17 Peter Kümmel wrote:
> Too many mails to lyx-devel... ;)
I was surprised that we had dbus integration and nobody told me about it. ;-)
--
José Abílio
On Sunday 27 May 2007 16:27:35 Jürgen Spitzmüller wrote:
> I'm waiting for José's turn. I don't want to interfere his RC1 work.
I will release RC1 later today, you can proceed. :-)
> Thanks for testing.
> Jürgen
--
José Abílio
Koji Yokota wrote:
> Jean-Marc Lasgouttes wrote:
>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>
>> Abdelrazak> Maybe Koji could try to enable that unconditionally:
>>
>> Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) &&
>> Abdelrazak> defined(__GNUC_MINOR__) &&
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Maybe Koji could try to enable that unconditionally:
Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) &&
Abdelrazak> defined(__GNUC_MINOR__) && __GNUC__ == 3 && __GNUC_MINOR__
Abdelr
Uwe Stöhr wrote:
> Works here on Windows too.
> It is also reviewed by Georg so I say, put it in.
I'm waiting for José's turn. I don't want to interfere his RC1 work.
Thanks for testing.
Jürgen
reviewed and approved by Georg.
I tested it with several encodings. Seems to work fine (more testing is
appreciated, though).
Works here on Windows too.
It is also reviewed by Georg so I say, put it in.
regards Uwe
This simple patch seems to be doing it -- tested by Bennett.
There's still an issue with the layout of the widgets, but that can be
addressed later IMO.
OK to apply?
Jürgen
Index: src/frontends/qt4/Dialogs.cpp
===
--- src/frontends/
Uwe Stöhr wrote:
> Note that the characters
> ∆, ∏, ∑
>
> are no Greek characters, they are math characters defined in a different
> unicode chart region than Greek!
I see. I suppose it's o.k. to transfer them to math, then.
Jürgen
Uwe Stöhr schrieb:
I never wrote that I intend to change greek characters, only the
characters I listed.
Here's the list again:
∂, ∆, ∏, ∑, ∕, ∙, ∞, ∟, ∩, ∫, ≈, ≤, ≥, ≡, and ≠
Note that the characters
∆, ∏, ∑
are no Greek characters, they are math characters defined in a different unicode ch
> I'm not sure it's a good idea to encapsulate greek characters in mathed. After
> all, they're _primarily_ greek characters (rather than math symbols). If I,
> as a human scientist, copy some greek quotation in my paper, I don't want
> them to appear as a formula.
I never wrote that I intend to
Too many mails to lyx-devel... ;)
Peter Kümmel wrote:
> Havoc, maybe it has not become clear:
> I seriously try to go your route.
>
> I hope I'm not completely wrong.
>
> Peter
>
>
> Peter Kümmel wrote:
>> I've tried to remove dbus_getuid calls from the "platform independent"
>> code. The fir
[EMAIL PROTECTED] writes:
| Author: younes
| Date: Sun May 27 13:55:46 2007
| New Revision: 18533
|
| URL: http://www.lyx.org/trac/changeset/18533
| Log:
| * InsetListingsParams.cpp: Code reorganization. Should fix bug 3639 and open
the way to more advanced gui controls.
|
| Modified:
| lyx
Havoc, maybe it has not become clear:
I seriously try to go your route.
I hope I'm not completely wrong.
Peter
Peter Kümmel wrote:
> I've tried to remove dbus_getuid calls from the "platform independent"
> code. The first step was to introduce _dbus_append_uid, first patch.
>
> Internally I s
Abdelrazak Younes wrote:
> Does LateX support utf8 greek?
You have to switch to language greek, I think.
Jürgen
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 Abdel's patch (gm
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The attached updated patch works the same and goes farther in the
cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
OK, thanks, I've committed a further cleanup version where ListingsParam
is a full blown class which do its own v
Jürgen Spitzmüller wrote:
Uwe Stöhr wrote:
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,
Richard Heck wrote:
As said. I believe this has to do with the use of _() in initialization
code.
I've committed my last patch. Should be fine now.
Abdel.
Edwin Leuven wrote:
proper cline support.
slightly updated patch attached.
1. lyx's default lines are now set, and
2. double check on reading line settings in existing docs
ping!
Index: src/frontends/controllers/ControlTabular.cpp
=
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
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
Edwin Leuven wrote:
> > as a human scientist
>
> i see you've attended an intergalactic conference recently
Yes, Dr. Strangelove, I did.
Jürgen
I think this version of the patch is ready to commit. I have tested
it on many examples and think the behavior is as it should be (up to
some minor points which can and should be addressed later). Below you
find some explanation of what the patch does and these issues. If you
haven't tried
Jürgen Spitzmüller wrote:
as a human scientist
i see you've attended an intergalactic conference recently
unsettling isn't it?
;-)
Am 27.05.2007 um 02:24 schrieb Dov Feldstern:
My only comment regarding the code itself: I would suggest
separating the fix for bug 3720 from the rest of the patch here,
and applying them separately. They are not logically interdependent
(the fix for bug 3720 could be applied independently
Uwe Stöhr wrote:
> > 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 mat
Uwe Stöhr wrote:
> With this patch only these 5 characters remain:
> c/o,
I'm not aware of an approach to directly access the symbol, but this is the
most frequent macro (used in tugboat):
\def\careof{\leavevmode\hbox{\raise.75ex\hbox{c}\kern-.15em
/\kern-.125em\smash{\lower.3
Abdelrazak Younes wrote:
> The attached updated patch works the same and goes farther in the
> cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
Jürgen
95 matches
Mail list logo
