On 5/29/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> On 5/29/07, Dov Feldstern
> <[EMAIL PROTECTED]> wrote:
>> Elazar Leibovich wrote:
>> > The inset makes it crystal clear and intuitive as to where the next
>> > character w
hat's means lower learning curve.
On 5/29/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> The inset makes it crystal clear and intuitive as to where the next
> character will be placed. It has it's problems though.
> I was aware to the F12 key,
o the F12 key, but I thought (and still think) it's
preferable not to use it, as now Lyx recieves input from the cursor.
On 5/29/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> I'm having a new idea for RTL in Lyx. Why won't we put RTL (or LTR i
On 5/29/07, Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
I have tested the suggestion and it works, except that the "question mark"
comes before its previous word! But the rest is ok as far as I can test.
I feel that LyX is now somehow faster.
One problem is, that Qt's RTL algorithm does not accep
On 5/29/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> In lyx it does. As an output it wouldn't be typesetted as RTL
Elazar> hebrew, but maybe as Hebrew characters. Anyho
When clicking home in an RTL mathed, it gets into the end of the
mathed, instead of the beginning of it.
I'll check it out when I'll get some time to breathe.
When clicking Ctrl+Left in a mathed, it goes left, even though it
supposed to go right. I don't see why, my goto patch affects both
LFUN_LEFT and LFUN_WORD_LEFT.
Any ideas?
In lyx it does. As an output it wouldn't be typesetted as RTL hebrew,
but maybe as Hebrew characters.
Anyhow there's no reason anyone would want it to be there.
On 5/29/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovi
On 5/29/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> Thanks! I also think that way. Moreover, we should force the
Elazar> language to be English in math insets, even for our
On 5/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> On 5/29/07, Abdelrazak Younes <[EMAIL PROTECTED]>
> wrote:
>> Elazar Leibovich wrote:
>> > I'm having a new idea for RTL in Lyx. Why won't we put RTL (or LTR in
>
Mostafa - can you type the paranthesis in lyx when in Arabic mode, do
you get them straight or reverse.
On 5/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Mostafa Vahedi wrote:
> Parenthesis are not handled correctly in LyX.
We made a change in that domain lately. This was asked by Elazar
On 5/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Well, have your words for lunch dude. Bon apetite.
> In your example all English words are separated by neutral characters
> like ," or space. In MS word, one controls the directional
On 5/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> I'm having a new idea for RTL in Lyx. Why won't we put RTL (or LTR in
> RTL paragraph) content in insets? that way, it'll be intuitive for the
> user to change the directionality (s
I'm having a new idea for RTL in Lyx. Why won't we put RTL (or LTR in
RTL paragraph) content in insets? that way, it'll be intuitive for the
user to change the directionality (step out of the inset, like you do
in math), and we can trigger new RTL inset insertion upon inputting an
Hebrew letter. P
On 28 May 2007 23:07:36 +0200, Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote:
"Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| Isn't that wise that the language will be automatically detected by
| the input-language. ie, English letters will always be English,
|
On 5/29/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Isn't that wise that the language will be automatically detected by
> the input-language. ie, English letters will always be English,
> Hebrew/Arabic letters will always be Hebrew/Arabic and neutr
Isn't that wise that the language will be automatically detected by
the input-language. ie, English letters will always be English,
Hebrew/Arabic letters will always be Hebrew/Arabic and neutral
characters will be the same language of the paragraph.
That way, the user won't be forced to learn new
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 b
Can you please refer me to where in the source code is a single
character directionality is handled?
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
ּ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
On 5/25/07, 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 ERT-inset is
> > always "la
On 5/25/07, Mostafa Vahedi <[EMAIL PROTECTED]> 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 ERT-inset is always "latex" and can not be
changed.
Therefore:
the RTL words inside an ERT-inset are not d
On 25 May 2007 13:55:56 +0200, Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote:
"Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| That's what Einstein said. "Documentation is more important than good
| coding". Someone *MUST* set up a decent overall documentati
On 5/25/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> I don't like the reference to the BufferView cursor. cursorX
Stefan> gets a arbitrary CursorSlice. It shouldn't depend on the
Stefan> cursor or some other sidecondi
On 5/25/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
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.
> What I did is I added a better test for that. I tested whether or not
> the cur
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. the '|' is the cursor, the
[] is inset I, inside some outer inset A.
WORD [in
On 5/24/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
On Thu, May 24, 2007 at 10:34:26AM +0300, Elazar Leibovich wrote:
> On 5/22/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
> >On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote:
> >> Well,
On 5/22/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote:
> Well, I'm in cursorX() so I'm having
> BufferView bv,
> CursorSlice sl,
> and finally boundary. Which does nothing AFAIK, it's just al
On 5/22/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
On Tue, May 22, 2007 at 08:51:20AM +0300, Elazar Leibovich wrote:
> I documented the problem in the patch itself.
> I suspect that the reason it didn't happen in previous releases is,
> that the "boundary" va
On 5/22/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> I'm well aware for it, but I haven't the slightest idea of
Elazar> what does it mean, and according to i
On 5/22/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> Well, I'm in cursorX() so I'm having BufferView bv,
Elazar> CursorSlice sl, and finally boundary. Which
s broken.
Thanks for your quick reply!
On 5/22/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> I thought of a way to know whether or not the cursor is
Elazar> editing the current pa
I thought of a way to know whether or not the cursor is editing the
current paragraph. One should compare cursor.inset() with
par.getInset(position).
However there's no operator== in the inset objects.
Is it easy to make one? Is that the way to go?
Are you being SERIOUS, about the loudness?
On 5/22/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> I asked for information about it in the list a few days ago (how can I
> find which inset are we EDITING), but no one answered :-).
Try to ask LOUDER,
bout it in the list a few days ago (how can I
find which inset are we EDITING), but no one answered :-).
Thanks for forcing me to further document my change! I'll update and repatch.
On 5/22/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> The proposed patch
The proposed patch affects RTL documents only, and fixes partially the
bug that made the cursor "jump" to the inset's end, when it was just
before the inset.
Index: Cursor.h
===
--- Cursor.h (revision 18129)
+++ Cursor.h (working copy
There's a slight bug with cursor position.
In the end of the cursorX function, the width of the inset is being
added to the x position, to fix it in the correct position despite
bidirectionality. However, Lyx doesn't know if you are just in front
of a mathed, or if you're in the mathed, your posit
BTW, I think we absolutely MUST someday (TM) to include an explicit
paragraph direction setting. Having the user to read documentation and
ignoring the current defacto standard is not an option.
On 5/20/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Martin Vermeer wrote:
> On Sat, May 19, 2007 at
TED]> wrote:
Elazar Leibovich wrote:
> Dov comment was that he was not able to recreate the problem. However
> my patch does not have any bad effect, so I guess we can try it out.
> Grrr... we need some more beta testers. I'll ask linux-il for volunteers.
>
I'm not able to
Dov comment was that he was not able to recreate the problem. However
my patch does not have any bad effect, so I guess we can try it out.
Grrr... we need some more beta testers. I'll ask linux-il for volunteers.
On 5/15/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leib
What about my patch of RTL pasting? It's very important and it always
occurs in windows.
On 5/15/07, José Matos <[EMAIL PROTECTED]> wrote:
On Tuesday 15 May 2007 10:49:01 Abdelrazak Younes wrote:
> I think Farsi support from Mostafa should go in ASAP.
We still need to decided what to do with
ting english text environment.
Can you please send me a sample document which you typed this way?
Attached
Thanks!
Dov
Elazar Leibovich wrote:
> Sure thing. It's running like a wild beast. Working with 100%.
> If you define the whole paragraph to be in Hebrew then you don't n
uages. The
main thing that that does is not to set the keyboard input, but also
tell latex about the language change. Have you been able to generate
latex output without using F12 up until now?
Elazar Leibovich wrote:
> Nice to see another Lyx hebrew user!
> IIRC the hebrew binding where only
Nice to see another Lyx hebrew user!
IIRC the hebrew binding where only needed in older versions of LyX,
where it wouldn't respect input from X, there, we'd define F12 to
replace between Hebrew and English key binding internally. Now, you
should just switch to Hebrew and it should work out of the
7;t affect regular paranthesis cutNpaste, checked it out.
Do commit, it's very safe.
On 5/14/07, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
It's definitely not a non standard. I'll try to find the place where the
paste function uses getUChar and replace it with getChar
On
It's definitely not a non standard. I'll try to find the place where the
paste function uses getUChar and replace it with getChar
On 5/14/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Dov Feldstern wrote:
> Elazar Leibovich wrote:
>> The attached patch disable Paragrap
Sorry for the delay.
Problem:
Be in a hebrew paragraph, start a formula with some under score (say a_1)
copy it, paste it in some mathematical inset. It comes out garbled.
That what it solves;
On 5/13/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> The attac
Can anyone *PLEASE* have a look at it?
It's a very crucial bugfix, the patch has nothing to do with no RTL text,
and I really like it to be included in the beta.
It's three days and no one has made any remark.
Please.
On 5/10/07, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
Th
w.
There's NO documentation about it in the code.
On 5/11/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> There's a slight bug with cursor drawing code in Hebrew paragraphs. When
> the
> cursor is logically before a math inset, it appears vis
There's a slight bug with cursor drawing code in Hebrew paragraphs. When the
cursor is logically before a math inset, it appears visually after it.
Can you give me a hint where the cursor drawing code is? I searched
rowpaint.cpp, and grep'd for cursordraw/paint but no luck so far.
Any hint.
Thanks
The attached patch disable Paragraph::getUChar functionality of inversing
the paranthesis. I grep'ed for the function and it seems to be used only by
math inset's pasting getPlainText mechanism, and indeed it has no effect on
regular paranthesis.
Please have a look at this very simple patch and ap
The problem is that when in RTL mode the paste thing inverse the paranthesis
for instance
a_}a+b{
vs.
a_{a+b}
Now I need to find what's bugging it, and the patch would come.
On 5/10/07, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
I'm pasting the c_str() representation of the do
I'm pasting the c_str() representation of the docstring recieved by
cap::getSelection(cur.buffer(), n); method, it is not useful just a memory
location. How can I represent the documentation string in a useful manner?
Can it be that without bidirectionality set we're not getting to the
LFUN_PASTE?
can't we block his bugzilla username?
On 5/9/07, Juergen Spitzmueller <[EMAIL PROTECTED]> wrote:
Some moron is uploading links to spam sites as attachments to bugzilla,
e.g.
here:
http://bugzilla.lyx.org/show_bug.cgi?id=227
Is there something we can do against that?
Jürgen
That is, if I'll get to write a patch that fixes it, will it be included in
1.5.0 final?
On 5/9/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> Thanks! Can we have this patch in the 1.5.0 final?
What patch?
JMarc
Thanks!
Can we have this patch in the 1.5.0 final?
On 5/9/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>>>>> "Elazar" == Elazar Leibovich <[EMAIL PROTECTED]> writes:
Elazar> There's a big bug with pasting math data into math insets in
El
There's a big bug with pasting math data into math insets in RtL paragraphs.
I assume that something traverses the math text before entering it into the
buffer.
Can anyone point me to the location in the code where pasting stuff
(specifically into matheds) is?
27;s language). So to figure out where the cursor really
needs to go, all you do is place it at vis2log(x+1). There are still
some issue to work out, but basically, I definitely think that this is
the way to go.
Good luck!
Dov
Elazar Leibovic
There's a small bug I'd like to fix about the Bidirectional cursor drawing.
When is an RTL paragraph the cursor is right before a mathed inset, that is
HEBREW TEXT |math
it is drawn after the inset, ie
HEBREW TEXT math|
Where is the code that is responsible of drawing the cursor?
I think this is a very clever approach. Nowadays 99% of modern
program supports Unicode and thus RTL out of the box.
On 5/6/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Dov Feldstern wrote:
> While looking into the issue of cursor direction in RTL paragraphs,
> using the latest svn version,
Please try this patch for second approach. Please make sure I'm not
breaking anything.
See discussion here http://bugzilla.lyx.org/show_bug.cgi?id=3551
Index: Text2.cpp
===
--- Text2.cpp (revision 18129)
+++ Text2.cpp (working copy)
@
to answer.
On 4/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Checks the directionality of the paragraph, and makes cursor Forward
> requests into cursor backwards and vice versa.
> Extremly easy, relies on cursor's isRTL()
My patch "Works for me" very well, the cursor never got stuck.
Can you specify me how to recreate the problem?
On 4/30/07, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
Hmm... I'll look at it. But what can cause this? Is it still
recognizing we're in RTL there?
Hmm... I'll look at it. But what can cause this? Is it still
recognizing we're in RTL there? My code simply reverse the dispatcher
signal.
On 4/30/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Hold on. It does segfaults, but this is not me
called? What if the cursor is moved in-out of an inset?
On 4/30/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Hold on. It does segfaults, but this is not me, this is the isRTL
> function implemented in Cursor.cpp. It's fails when it tries to ask
that the inset my cursor is currently pointing at, is found?
Any references?
On 4/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> Checks the directionality of the paragraph, and makes cursor Forward
> requests into cursor backwards and vice versa.
> E
Checks the directionality of the paragraph, and makes cursor Forward
requests into cursor backwards and vice versa.
Extremly easy, relies on cursor's isRTL() method.
Index: src/mathed/InsetMathNest.cpp
===
--- src/mathed/InsetMathNest
{
cur.posLeft();
cur.push(*cur.nextAtom().nucleus());
On 4/29/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> When trying to determine the directionality of a mathed inset the
> cursor is currently located in, I
When trying to determine the directionality of a mathed inset the
cursor is currently located in, I'm having the following troubles.
I cannot get the paragraph directly from the cursor (I don't know why,
but someone explicitly disallowed that, having a
"BOOST_ASSERT(inTexted());" when calling cur.
Sorry, it's bug #904
here:
http://bugzilla.lyx.org/show_bug.cgi?id=904
On 4/27/07, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
Hi,
There's an obnoxious bug described in bugzilla bug #1820, where the
cursor movement is wrong in a math inset inside a RTL paragraph. Can
you plea
Hi,
There's an obnoxious bug described in bugzilla bug #1820, where the
cursor movement is wrong in a math inset inside a RTL paragraph. Can
you please point me to a documentation or portion of the code where I
can check whether or not the cursor is located inside a math inset.
I believe the fix s
72 matches
Mail list logo
