Approving a wiki link (Hebrew instructions)
Hi, guys! Long time no see! I'm just hopping by for a short visit -- not planning to stay long term... Could someone please approve the link that I just added to this wiki page [1], or send me the password? Thanks! Dov [1] http://wiki.lyx.org/LyX/HebrewOnLinux
Re: Bug 6454: Where Things Stand
On Fri, Mar 19, 2010 at 1:25 AM, Dov Feldstern wrote: > On Fri, Mar 19, 2010 at 1:22 AM, rgheck wrote: >> On 03/18/2010 07:01 PM, Dov Feldstern wrote: >>> >>> So, in order to figure this out, I added the debug prints mentioned >>> above, and then I noticed that only when we're at the end of a word, >>> but not anywhere else, then a line is printed every time the cursor >>> blinks --- whether or not the cursor is on the screen. >>> >>> >> >> I've seen this, too. Surely it would make sense to disable the cursor >> blinking when the little guy is off screen, right? Perhaps that is the real >> bug. But still, I think my patch makes sense. I see TONS of metrics being >> calculated when I move the mouse, which is very weird---the point being that >> we can't be quite sure when isRTLBoundary might be called. So we should make >> sure we have metrics, like we make sure we have a non-null pointer. >> >> I think the issue here, in a way, is that >> par_metrics_[pit] >> has a nasty side effect. Maps can be dangerous. >> >>> In other words: something is causing isRTLBoundary to be called every time >>> the >>> cursor blinks when it is at the end of the word, even if it is off the >>> screen, and the first time that that happens, there are no metrics! >>> >>> >> >> As Vincent notes, the "end of the word" thing is due to something in >> getFont(). >> >> So I'd suggest we do two things: (i) commit the check for metrics, which >> makes sense anyway; and (ii) disable the cursor blinking when the cursor is >> off-screen, which also makes sense anyway. >> > > Sounds good to me... I just want to double check that your change > doesn't adversely affect the test-case for which that code was > originally added --- I'll get back to you on that in a few minutes... > >> rh >> >> > hmpph, it's broken both with and without your changes, and even without getting RTL involved: abc\n <- soft line break def if you are after the 'd', it takes 4 presses of Left to get to before the 'c', but only 3 presses of Right to then get back to the same position, because of the boundary... But anyhow, yeah, the patch seems fine. However, it may be worth revisiting http://www.lyx.org/trac/ticket/5061 (though the behavior I describe as problematic is not exactly that described in the bug, I think...).
Re: Bug 6454: Where Things Stand
On Fri, Mar 19, 2010 at 1:22 AM, rgheck wrote: > On 03/18/2010 07:01 PM, Dov Feldstern wrote: >> >> So, in order to figure this out, I added the debug prints mentioned >> above, and then I noticed that only when we're at the end of a word, >> but not anywhere else, then a line is printed every time the cursor >> blinks --- whether or not the cursor is on the screen. >> >> > > I've seen this, too. Surely it would make sense to disable the cursor > blinking when the little guy is off screen, right? Perhaps that is the real > bug. But still, I think my patch makes sense. I see TONS of metrics being > calculated when I move the mouse, which is very weird---the point being that > we can't be quite sure when isRTLBoundary might be called. So we should make > sure we have metrics, like we make sure we have a non-null pointer. > > I think the issue here, in a way, is that > par_metrics_[pit] > has a nasty side effect. Maps can be dangerous. > >> In other words: something is causing isRTLBoundary to be called every time >> the >> cursor blinks when it is at the end of the word, even if it is off the >> screen, and the first time that that happens, there are no metrics! >> >> > > As Vincent notes, the "end of the word" thing is due to something in > getFont(). > > So I'd suggest we do two things: (i) commit the check for metrics, which > makes sense anyway; and (ii) disable the cursor blinking when the cursor is > off-screen, which also makes sense anyway. > Sounds good to me... I just want to double check that your change doesn't adversely affect the test-case for which that code was originally added --- I'll get back to you on that in a few minutes... > rh > >
Re: Bug 6454: Where Things Stand
On Thu, Mar 18, 2010 at 11:47 PM, rgheck wrote: > > And adding the list here, too > > On 03/18/2010 05:22 PM, Dov Feldstern wrote: >> >> On Thu, Mar 18, 2010 at 5:48 PM, rgheck wrote: >> . >> . >> >>> I'm guessing that this is the cause of the problem. >>> >>> >>> Where ought the position to have been set? >>> >>> >> I'm not sure I understand this question... Isn't the real question: >> why have the metrics not been calculated? >> >> > Yes, pretty much, though some of the other metrics have been calculated, > from what I can tell. We end up in redoParagraph, which sets lots of things. > But not position. > >> Mmmm, reading your description again, could this be an answer to my >> question: if the cursor is in par 58, and then par 58 is scrolled off >> the screen (but the cursor is still in it!), so then since par 58 is >> not painted (it's off the screen) no metrics have been calculated for >> it. >> >> > Yes, that's right. So does the attached make sense? It seems to solve it for > me, but I have no idea what it does to the RTL stuff. > I don't remember: is it correct that boundary only affect the cursor's display? If so, and if we're correct that the metrics will not exist only when the cursor's paragraph is off the screen, then your fix would seem to be safe... But then the question is: why is a function which only affects the cursor's display being called when the cursor is off the screen? In other words, if our above assumptions are correct, then the function should not actually be called at all when we're off the screen --- but it is... So, in order to figure this out, I added the debug prints mentioned above, and then I noticed that only when we're at the end of a word, but not anywhere else, then a line is printed every time the cursor blinks --- whether or not the cursor is on the screen. And that's also the only time when we see the error occur, when the paragraph is moved off the screen (so it's the end of a word that matters, not a word that has a completion, as someone mentioned somewhere). In other words: something is causing isRTLBoundary to be called every time the cursor blinks when it is at the end of the word, even if it is off the screen, and the first time that that happens, there are no metrics! It's 100% reproducible this way: create a document with just enough paragraphs such that the last one can be scrolled entirely off the screen. Now, stand at the end of any word in the paragraph. you'll see a line printed every cursor blink. Now, if you scroll, then as soon as the paragraph is entirely off the screen, there'll be a single printout which says "empty", and then again printouts which have the metrics... I have no idea what this means yet, but thought this is interesting information... Dov
Re: Bug 6454: Where Things Stand
Whoops, adding back the list (haven't done this for a while...!) On Thu, Mar 18, 2010 at 11:22 PM, Dov Feldstern wrote: > On Thu, Mar 18, 2010 at 5:48 PM, rgheck wrote: > . > . >> I'm guessing that this is the cause of the problem. >> >> >> Where ought the position to have been set? >> >> > > I'm not sure I understand this question... Isn't the real question: > why have the metrics not been calculated? > > Mmmm, reading your description again, could this be an answer to my > question: if the cursor is in par 58, and then par 58 is scrolled off > the screen (but the cursor is still in it!), so then since par 58 is > not painted (it's off the screen) no metrics have been calculated for > it. > > Does this make any sense at all? > > Dov >
slashdot thread on Collaborative Academic Writing Software
http://ask.slashdot.org/article.pl?sid=09/03/13/1925238 : "...One solution to this is to simply pair up LaTeX with version control software (such as Subversion) to allow multiple collaborators to work on the same document at one time. But adding Subversion to the mix only seems to increase the learning curve... The closest I can approximate would be to have something like Lyx (to hide the learning curve of LaTeX) with integrated svn (to hide the learning curve of svn). However, this doesn't seem available." I recall that there was some development work done in this respect fairly recently, someone from the dev team may want to pipe in on the thread there. Actually, a few people already point out there that LyX *does* support svn, if anyone has mod points you could mod those up! There are also some other interesting, not necessarily collaboration-related, opinions on LyX in the thread... Enjoy! Dov
Re: Location in SVN for work on developing build scripts?
Christian Ridderström wrote: Hi, I'm currently using Mercurial (hg) for working on some build scripts because I don't know where I should put them in the SVN tree. Could someone point me to a good place in the SVN tree? I'd rather not put them in lyx-devel at the moment as that tree is just too big. For me a simple alternative is to keep using Mercurial, but I'd like to make the repository available to others, which means an installation of Mercurial is needed on Aussie. Would other developers benefit from having Mercurial on aussie? If so, I'll ask Jean-Marc to install it. (I know that Dov has installed it locally already). regards /Christian You could host your repository at bitbucket (http://www.bitbucket.org) --- it's a mercurial-hosting site. You can open a free account with 150MB. Their customer service is very good, even for free accounts. Not that I'm opposed to having mercurial installed on Aussie, by any means... ;) A bit off-topic: if anyone's interested in using mercurial for LyX itself: I created a mercurial mirror of the LyX repository, and that's what I've been using for the past year or so (except for committing back to svn, which still requires svn itself); however, there are still a few problems with it, which is why I never made it public. But if anyone's interested, let me know and we can see what can be done. The problems are these: 1) the svn->mercurial conversion tools do not deal well with branches that are not directly under the branches/ directory. In the LyX repo, although most branches are directly under branches/, those under branches/personal are not. The conversion scripts recognize branches/personal itself as a branch, and so all the branches under personal are not recognized as versions of trunk, but as hierarchies within a single version. This means that the repository size grows to over 1GB. I have reported this issue to mercurial, but no solution yet, as far as I know. 2) When I first created the mercurial mirrors, I was automatically updating it every half hour, using a cron job on Aussie. However, at some point the conversion tool was updated, which caused it to enter a very very long loop (endless, for practical purposes --- it was being killed by cron after taking too long) after every update; so now the conversion does not take place automatically anymore. The issue is reported at http://www.selenic.com/mercurial/bts/issue1133. 3) There's a newer mercurial extension for interacting with subversion (called hgsubversion), which also allows pushing back to svn from a mercurial repo --- something which was not possible until now. However, it requires the svn server to be at least 1.4 or 1.5 (I don't remember which). Any plans for upgrading LyX's subversion server? Dov
Re: Hebrew and Proof Environment
Jürgen Spitzmüller wrote: Dov Feldstern wrote: Hmm, it looks like there's a missing newline in the tex output which is causing the problem: attached find the tex output I'm getting from Amir's LyX file in 2.0svn (in which the problem he describes exists), and a fixed tex output which displays correctly, I think (Amir, can you confirm that the fixed output is correct?). Does anyone have any ideas why that newline disappeared? In order to fix this bug probably: http://bugzilla.lyx.org/show_bug.cgi?id=4993 Yes, I can confirm that undoing r25416 and r27236, r27237 fixes the problem Amir reported. Adding a ---Separator--- environment before the proof *does* help, but I doubt that that can be considered more than a workaround... Is this a bug in article(Hebrew) (i.e., should it not be sensitive to a newline before it, given that it is an environment)? Or is it a bug in LyX? I'm not familiar enough with bugs 5436, 4993 (which the above changesets solve), but I see that there's a comment there (added by Richard) with a FIXME, so I presume that this is a LyX issue? Should Amir open a bug for this? Dov
Re: [Fwd: [Cvslog] r27656 - /lyx-devel/trunk/src/TextMetrics.cpp]
Jürgen Spitzmüller wrote: Dov Feldstern wrote: Jürgen, OK for branch? OK. Jürgen Should this kind of thing --- which is purely "under the hood" --- be documented in status.16x, or no need? (reminder: code reuse in overloaded versions of isRTLBoundary)
Re: Hebrew and Proof Environment
Amir Rachum wrote: How do I compile these? When I use Import > LaTeX (plain) I get a weird file, with both those files. I can attach a screen shot if you want me to. I'm not sure how it's done in Windows; in linux I just run the latex command on them to see that the output is correct: latex produces a dvi file (I'm attaching a pdf of the fixed output, just so that you can confirm it's correct). If import isn't working, that may be another problem, but I never import latex into LyX, so I'm just not sure... proofexample-fixed.pdf Description: Adobe PDF document
Re: Hebrew and Proof Environment
Amir Rachum wrote: Here is an example, hope that helps. thanks On Sat, Nov 22, 2008 at 6:31 PM, Dov Feldstern <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: rgheck wrote: Amir Rachum wrote: I've recently upgraded to LyX 1.6 and using Windows XP. I use the document class article (Hebrew). I use the proof environment, but in the new version, after I render to pdf, the proof doesn't start at a new line. i.e in LyX I see: bla bla bla proof: bla bla 2 and after I render I see: bla bla bla proof bla bla 2 This happens with documents I edited with the previous version of LyX and they render fine with 1.5. What can I do? Hi, Amir! Can you please send a minimal example which includes this problem? I'd like to see three files: the LyX file itself, an export to latex from 1.5 (i.e., an example with correct output), and an export to latex from 1.6 (with incorrect output). That'll help us figure out what's wrong. Dov -- Amir Rachum Hmm, it looks like there's a missing newline in the tex output which is causing the problem: attached find the tex output I'm getting from Amir's LyX file in 2.0svn (in which the problem he describes exists), and a fixed tex output which displays correctly, I think (Amir, can you confirm that the fixed output is correct?). Does anyone have any ideas why that newline disappeared? On a separate note, just out of curiosity: I'm not able to compile the 1.6 tex output Amir sent --- I'm getting LaTeX Error: Command \textquotedbl unavailable in encoding LHE Juergen -- this looks like it may be related to what you just fixed? But I don't understand why it seems to be compiling for Amir without any trouble? Anyhow, I don't know if this is important; I don't think it's related to his problem, in any case Dov proofexample-2.0.tex Description: TeX document proofexample-fixed.tex Description: TeX document
Re: Hebrew and Proof Environment
rgheck wrote: Amir Rachum wrote: I've recently upgraded to LyX 1.6 and using Windows XP. I use the document class article (Hebrew). I use the proof environment, but in the new version, after I render to pdf, the proof doesn't start at a new line. i.e in LyX I see: bla bla bla proof: bla bla 2 and after I render I see: bla bla bla proof bla bla 2 This happens with documents I edited with the previous version of LyX and they render fine with 1.5. What can I do? Hi, Amir! Can you please send a minimal example which includes this problem? I'd like to see three files: the LyX file itself, an export to latex from 1.5 (i.e., an example with correct output), and an export to latex from 1.6 (with incorrect output). That'll help us figure out what's wrong. Dov
[Fwd: [Cvslog] r27656 - /lyx-devel/trunk/src/TextMetrics.cpp]
Jürgen, OK for branch? Original Message Subject: [Cvslog] r27656 - /lyx-devel/trunk/src/TextMetrics.cpp Date: Fri, 21 Nov 2008 11:32:57 - From: [EMAIL PROTECTED] Reply-To: lyx-devel@lists.lyx.org To: [EMAIL PROTECTED] Author: dov Date: Fri Nov 21 12:32:56 2008 New Revision: 27656 URL: http://www.lyx.org/trac/changeset/27656 Log: get rid of code duplication between overloaded versions of isRTLBoundary This is in preparation of some changes to be made in this function, now the change will only have to be done once... Modified: lyx-devel/trunk/src/TextMetrics.cpp Modified: lyx-devel/trunk/src/TextMetrics.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/TextMetrics.cpp?rev=27656 == --- lyx-devel/trunk/src/TextMetrics.cpp (original) +++ lyx-devel/trunk/src/TextMetrics.cpp Fri Nov 21 12:32:56 2008 @@ -321,15 +321,9 @@ if (pos == 0) return false; - Paragraph const & par = text_->getPar(pit); - - bool left = displayFont(pit, pos - 1).isVisibleRightToLeft(); - bool right; - if (pos == par.size()) - right = par.isRTL(bv_->buffer().params()); - else - right = displayFont(pit, pos).isVisibleRightToLeft(); - return left != right; + Font const & left_font = displayFont(pit, pos - 1); + + return isRTLBoundary(pit, pos, left_font); } ___ Cvslog mailing list [EMAIL PROTECTED] http://www.lyx.org/mailman/listinfo/cvslog
Re: [PATCH 2 of 3] two fixes of RTL boundary calculation:
Abdelrazak Younes wrote: Andre Poenitz wrote: On Wed, Nov 19, 2008 at 08:59:17PM +0100, Vincent van Ravesteijn wrote: Dov Feldstern schreef: 1) boundary should not be set to true at a (intra-paragraph) line break; fixes this: abc|\n-> move right -> abc\n (and not:abc\n| FED FED| FED ) 2) boundary should not be set (even if left_font is provided) at pos == 0; fixes this: abc\n -> toggle to RTL -> abc\n (and not:abc\n| | | ) Hi Dov, The second example you give here is quite a special case. In this case, there a three possible locations. At the upper row after \n, at the lower row in the R-part and at the lower row in the L-part. I think that this shows that we it is not enough to have a single boundary member. I would suggest that we introduce two members: row_boundary and rtl_boundary. I personally feel that the boundary is a little bit misused to represent two different boundaries. If we add a second boundary member, I think that this is solved much more easily, and the code will be better understandable. Besides, the third patch you supplied is then no longer needed (I hope). What do you think of this proposal ? Sounds good. I was always confused by the different meanings of the boundary. +1. I'm not so sure... I think that if anything, adding another 'state' will make things even more confused. I agree that the 'boundary' concept is confused, but I'd like to suggest a way of looking at 'boundary' which makes it less confusing (at least to me). I think of 'boundary' purely in functional terms: set it to true in order to paint cursor *after* the *previous* (logical) position, rather than before the current position, which is the usual behavior. This way, RTL/LTR, or line endings, or whatever are totally irrelevant. The only question you should ask when deciding whether or not to turn on the boundary is: where do I want the cursor painted? (Obviously, this *does* depend on RTL/LTR, line endings, etc. --- but not as a 'concept', only as a concrete decision in a concrete situation). So, I would suggest just changing the name of 'boundary' to reflect this 'functional' point of view, I think that would help to alleviate much of the confusion. (I'm having trouble coming up with a good name, though...) This won't make it easier to deal with the special cases, but I don't think that adding another state would make it easier, either. The special cases are complex, and so require complex handling. That said, I'm open to looking at concrete proposals (i.e., code) along the lines you suggested, maybe it *will* turn out to be easier to follow... Stefan --- I think you rewrote much of the boundary code last year, do you have any thoughts on this issue? Dov
[PATCH 3 of 3] more cursor RTL boundary fixes
After inserting a character, cursor boundary was not being recalculated. This may have been OK up until now, but after the previous fix, there is now a case where the boundary *does* change as the result of a character insertion: abc\n -> toggle to RTL -> abc\n -> insert A -> abc\n (and not: abc\n | ||AA|) pos = 4 pos = 4 pos = 5 boundary = 0 boundary = 0 boundary = 1 ^ boundary needs to be switched to true here # HG changeset patch # User Dov Feldstern <[EMAIL PROTECTED]> # Date 1226858131 -7200 # Node ID ae691e6ca722b1a5d50f2db963d4244ffbd34d52 # Parent 5fa28578a852bd8dffb413457a674f61fde94de4 more cursor RTL boundary fixes After inserting a character, cursor boundary was not being recalculated. This may have been OK up until now, but after the previous fix, there is now a case where the boundary *does* change as the result of a character insertion: abc\n -> toggle to RTL -> abc\n -> insert A -> abc\n (and not: abc\n | ||AA|) pos = 4 pos = 4 pos = 5 boundary = 0 boundary = 0 boundary = 1 ^ boundary needs to be switched to true here diff -r 5fa28578a852 -r ae691e6ca722 src/Text.cpp --- a/src/Text.cpp Sun Nov 16 19:52:16 2008 +0200 +++ b/src/Text.cpp Sun Nov 16 19:55:31 2008 +0200 @@ -542,7 +542,8 @@ cur.checkBufferStructure(); // cur.updateFlags(Update::Force); - setCursor(cur.top(), cur.pit(), cur.pos() + 1); + bool boundary = tm.isRTLBoundary(cur.pit(), cur.pos() + 1); + setCursor(cur, cur.pit(), cur.pos() + 1, false, boundary); charInserted(cur); }
[PATCH 2 of 3] two fixes of RTL boundary calculation:
1) boundary should not be set to true at a (intra-paragraph) line break; fixes
this:
abc|\n-> move right -> abc\n (and not:abc\n|
FED FED| FED )
2) boundary should not be set (even if left_font is provided) at pos == 0;
fixes this:
abc\n -> toggle to RTL -> abc\n (and not:abc\n|
| | )
This fixes some manifestations of http://bugzilla.lyx.org/show_bug.cgi?id=5061
# HG changeset patch
# User Dov Feldstern <[EMAIL PROTECTED]>
# Date 1226857936 -7200
# Node ID 5fa28578a852bd8dffb413457a674f61fde94de4
# Parent 8b73bd1b76ee5a0bd85b66dfcd4dbd3862cf7361
two fixes of RTL boundary calculation:
1) boundary should not be set to true at a (intra-paragraph) line break; fixes
this:
abc|\n-> move right -> abc\n (and not:abc\n|
FED FED| FED )
2) boundary should not be set (even if left_font is provided) at pos == 0;
fixes this:
abc\n -> toggle to RTL -> abc\n (and not:abc\n|
| | )
This fixes some manifestations of http://bugzilla.lyx.org/show_bug.cgi?id=5061
diff -r 8b73bd1b76ee -r 5fa28578a852 src/TextMetrics.cpp
--- a/src/TextMetrics.cpp Sun Nov 16 19:47:20 2008 +0200
+++ b/src/TextMetrics.cpp Sun Nov 16 19:52:16 2008 +0200
@@ -317,7 +317,7 @@
if (!lyxrc.rtl_support)
return false;
- // no RTL boundary at line start
+ // no RTL boundary at paragraph start
if (pos == 0)
return false;
@@ -331,6 +331,23 @@
Font const & font) const
{
if (!lyxrc.rtl_support)
+ return false;
+
+ // no RTL boundary at paragraph start
+ if (pos == 0)
+ return false;
+
+ ParagraphMetrics & pm = par_metrics_[pit];
+ // no RTL boundary in empty paragraph
+ if (pm.rows().empty())
+ return false;
+
+ pos_type endpos = pm.getRow(pos - 1, false).endpos();
+ pos_type startpos = pm.getRow(pos, false).pos();
+ // no RTL boundary at line start:
+ // abc\n -> toggle to RTL ->abc\n (and not:abc\n|
+ // | | )
+ if (pos == startpos && pos == endpos) // start of cur row, end of prev row
return false;
Paragraph const & par = text_->getPar(pit);
@@ -340,6 +357,16 @@
right = par.isRTL(bv_->buffer().params());
else
right = displayFont(pit, pos).isVisibleRightToLeft();
+
+ // no RTL boundary at line break:
+ // abc|\n-> move right -> abc\n (and not:abc\n|
+ // FED FED| FED )
+ if (startpos == pos && endpos == pos && endpos != par.size()
+ && (par.isNewline(pos - 1)
+ || par.isLineSeparator(pos - 1)
+ || par.isSeparator(pos - 1)))
+ return false;
+
return left != right;
}
[PATCH 1 of 3] get rid of code duplication between overloaded versions of isRTLBoundary
This is in preparation of some changes to be made in this function, now the change will only have to be done once... # HG changeset patch # User Dov Feldstern <[EMAIL PROTECTED]> # Date 1226857640 -7200 # Node ID 8b73bd1b76ee5a0bd85b66dfcd4dbd3862cf7361 # Parent 1791e3372c7978e2bffb6fb59d4f6105f71bf7bc get rid of code duplication between overloaded versions of isRTLBoundary This is in preparation of some changes to be made in this function, now the change will only have to be done once... diff -r 1791e3372c79 -r 8b73bd1b76ee src/TextMetrics.cpp --- a/src/TextMetrics.cpp Fri Nov 14 10:05:07 2008 + +++ b/src/TextMetrics.cpp Sun Nov 16 19:47:20 2008 +0200 @@ -321,15 +321,9 @@ if (pos == 0) return false; - Paragraph const & par = text_->getPar(pit); + Font const & left_font = displayFont(pit, pos - 1); - bool left = displayFont(pit, pos - 1).isVisibleRightToLeft(); - bool right; - if (pos == par.size()) - right = par.isRTL(bv_->buffer().params()); - else - right = displayFont(pit, pos).isVisibleRightToLeft(); - return left != right; + return isRTLBoundary(pit, pos, left_font); }
[PATCH 0 of 3] fix further manifestations of bug 5061
Hi!
The following patches fix the remaining manifestations of bug 5061 ("Wrong
painting of cursor after newline" http://bugzilla.lyx.org/show_bug.cgi?id=5061).
All of the situations being fixed are RTL/LTR boundary cases.
I'm quite confident the first patch is correct, and will commit it if there are
no objections.
Parts 2 and 3 I'm less certain about -- they do the job, but I can't say that I
really like the way they do it, and I'm a bit worried that they may impact
performance. It would be great to get some feedback (Vincent? Stefan?).
Dov
(P.S. let me know if you find this format of sending patches annoying; this is
how it's done by default in mercurial, and I find it quite convenient. The
patches should apply cleanly with -p1)
Re: [PATCH] Bug 5061
Vincent van Ravesteijn - TNW wrote: (2) However, #5061 still exists when boundary is set to true for a correct reason; for example, try this recipe: - create a new file - insert an equation - press the right arrow key to jump out of the equation - press Ctrl-Return - switch the language to an RTL language (e.g., Hebrew) Result: The cursor jumps back up to the same line as the newline, and must type some character to get correctly rendered on the new line. Why is it correct that the boundary is true in this case ? I probably haven't thought enough about RTL-LTR boundaries, but either - you don't want the cursor to be painted on the row of the newline, which means boundary should be false, or - you want to paint the cursor before the newline, but then the cur.pos() is wrong. Yes, you're right. After looking over the code, I agree that the problem is that boundary should not be set to true in this case. I've started working on a fix, but every fix breaks some other edge case. For now, the fact that the main case is fixed should be good enough. (All remaining problematic cases that I've noticed involve Bidi text.) I'll try to get a fix for the other cases in the next few days, but I'm not sure I'll have time for this... Dov
Re: [PATCH] Bug 5061
Dov Feldstern wrote: Enrico Forestieri wrote: On Thu, Oct 30, 2008 at 07:51:41AM -0400, rgheck wrote: http://bugzilla.lyx.org/show_bug.cgi?id=5061 Can someone who knows about InsetMathNest review the patch Vincent attached to this bug? It looks like it's probably correct, but I don't know about this stuff. Me neither, but looking at cs22930 this seems to be an oversight by Dov. Indeed, I don't think that he meant replacing FuncRequest(LFUN_FINISHED_FORWARD); by cmd = FuncRequest(finish_lfun); where finish_lfun is either LFUN_FINISHED_RIGHT or LFUN_FINISHED_LEFT. So, I think that the patch does the right thing. No, I don't think it was an oversight, Vincent's patch breaks visual cursor movements in math. There may still be a bug in my original code, though, I'm looking this over now with respect to 5061. I'll let you know when I have something... Dov Okay, there are actually two separate issues here: (1) boundary is incorrectly set to true in this case (my bug, correctly diagnosed, but incorrectly fixed, by Vincent); The attached patch fixes it. If nobody has objections to it, I'll check it in tomorrow evening. This is good enough to fix #5061 in the normal case. (2) However, #5061 still exists when boundary is set to true for a correct reason; for example, try this recipe: - create a new file - insert an equation - press the right arrow key to jump out of the equation - press Ctrl-Return - switch the language to an RTL language (e.g., Hebrew) Result: The cursor jumps back up to the same line as the newline, and must type some character to get correctly rendered on the new line. I think the correct solution is that even when boundary==true, the cursor should *not* be painted after the previous character, if the previous character is Ctrl-Enter or Ctrl-Shift-Enter. I can't think of *any* situation where we would legitimately want to paint the cursor *after* such a character. Opinions? Dov BTW, Enrico --- thanks for checking svn blame (or are you using git?) for this! --- I don't think I would have noticed this issue otherwise... diff -r dc325cbabe98 src/Cursor.cpp --- a/src/Cursor.cpp Fri Oct 31 01:26:11 2008 + +++ b/src/Cursor.cpp Fri Oct 31 13:14:48 2008 +0200 @@ -507,10 +507,11 @@ new_cur.pos() = right_pos + 1; // set the boundary to true in two situations: if ( - // 1. if new_pos is now lastpos (which means that we're moving - // right to the end of an LTR chunk which is at the end of an - // RTL paragraph); -new_cur.pos() == lastpos() + // 1. if new_pos is now lastpos, and we're in an RTL paragraph + // (this means that we're moving right to the end of an LTR chunk + // which is at the end of an RTL paragraph); +(new_cur.pos() == lastpos() + && paragraph().isRTL(buffer().params())) // 2. if the position *after* right_pos is RTL (we want to be // *after* right_pos, not before right_pos + 1!) || paragraph().getFontSettings(bv().buffer().params(), @@ -598,10 +599,11 @@ new_cur.pos() = left_pos + 1; // set the boundary to true in two situations: if ( - // 1. if new_pos is now lastpos (which means that we're moving left - // to the end of an RTL chunk which is at the end of an LTR - // paragraph); -new_cur.pos() == lastpos() + // 1. if new_pos is now lastpos and we're in an LTR paragraph + // (this means that we're moving left to the end of an RTL chunk + // which is at the end of an LTR paragraph); +(new_cur.pos() == lastpos() + && !paragraph().isRTL(buffer().params())) // 2. if the position *after* left_pos is not RTL (we want to be // *after* left_pos, not before left_pos + 1!) || !paragraph().getFontSettings(bv().buffer().params(),
Re: [PATCH] Bug 5061
Enrico Forestieri wrote: On Thu, Oct 30, 2008 at 07:51:41AM -0400, rgheck wrote: http://bugzilla.lyx.org/show_bug.cgi?id=5061 Can someone who knows about InsetMathNest review the patch Vincent attached to this bug? It looks like it's probably correct, but I don't know about this stuff. Me neither, but looking at cs22930 this seems to be an oversight by Dov. Indeed, I don't think that he meant replacing FuncRequest(LFUN_FINISHED_FORWARD); by cmd = FuncRequest(finish_lfun); where finish_lfun is either LFUN_FINISHED_RIGHT or LFUN_FINISHED_LEFT. So, I think that the patch does the right thing. No, I don't think it was an oversight, Vincent's patch breaks visual cursor movements in math. There may still be a bug in my original code, though, I'm looking this over now with respect to 5061. I'll let you know when I have something... Dov
Re: [patch] Selection painting in Insets
Abdelrazak Younes wrote:
On 13/10/2008 16:23, Dov Feldstern wrote:
Abdelrazak Younes wrote:
+if (row.end_margin_sel) {
if (text_->isRTL(buffer, beg.paragraph())) {
-int rm = bv_->rightMargin();
-pi.pain.fillRectangle(x + rm, y1, x2 - rm, y2 - y1,
Color_selection);
+pi.pain.fillRectangle(x + lm, y1, x2 - lm, y2 - y1,
+Color_selection);
} else {
-int lm = bv_->leftMargin();
-pi.pain.fillRectangle(x + x2, y1, width() - lm - x2, y2
- y1, Color_selection);
+pi.pain.fillRectangle(x + x2, y1, width() - rm - x2, y2
- y1,
+Color_selection);
Are you sure? You just replaced left with right and right with left
here...
Otherwise the patch is just renaming and cosmetics so, provided that
you explain the above, I am OK with the patch. Putting Dov in copy so
that he is aware of your activity.
Abdel
Hi!
Hi Dov,
I'm not familiar enough with the painting code in order to be able to
provide any intelligent input. Best I can do at the moment is just to
test this to make sure that it works correctly also for RTL text. What
exactly should I look at?
Just check that the text and rectangle selection painting is fine within
insets.
Abdel.
Looks good. There's still a minor problem with RTL text, but it's not any worse
off with this patch than it was before. I think I actually know what the cause
may be, I'll provide more details tomorrow evening --- I've got to go now...
But meanwhile, this patch is OK by me...
Dov
Re: [patch] Selection painting in Insets
Abdelrazak Younes wrote:
On 12/10/2008 21:24, Vincent van Ravesteijn wrote:
Vincent van Ravesteijn wrote:
This patch solves some problems with painting selections in Insets.
These are:
- multiline selections paint in left margin of the main text
(bug 5270),
- the margins to the left and right side of the inset are not correct,
- wrong painting of e.g. a multiline selection of a caption in a
float.
I renamed the Row::left_margin_sel back to Row::begin_margin_sel
because
of RTL text.
Is there yet a verdict for this patch ?
+if (row.end_margin_sel) {
if (text_->isRTL(buffer, beg.paragraph())) {
-int rm = bv_->rightMargin();
-pi.pain.fillRectangle(x + rm, y1, x2 - rm, y2 - y1,
Color_selection);
+pi.pain.fillRectangle(x + lm, y1, x2 - lm, y2 - y1,
+Color_selection);
} else {
-int lm = bv_->leftMargin();
-pi.pain.fillRectangle(x + x2, y1, width() - lm - x2, y2 -
y1, Color_selection);
+pi.pain.fillRectangle(x + x2, y1, width() - rm - x2, y2 - y1,
+Color_selection);
Are you sure? You just replaced left with right and right with left here...
Otherwise the patch is just renaming and cosmetics so, provided that you
explain the above, I am OK with the patch. Putting Dov in copy so that
he is aware of your activity.
Abdel
Hi!
I'm not familiar enough with the painting code in order to be able to provide
any intelligent input. Best I can do at the moment is just to test this to make
sure that it works correctly also for RTL text. What exactly should I look at?
Thanks for keeping me posted, though! I'm still lurking on the list, but I've
just been very busy lately, and don't have much LyX-time...
Dov
Re: Bidi painting
Uwe Stöhr wrote: Dov Feldstern schrieb: Can you try the attached "patch" to see if it speeds things up? Note that this is not really a patch --- the painting will be *incorrect* with it applied; but it's just to diagnose whether the problem is where I think it is. Your "patch" solves the problem for me. regards Uwe Hmmm..., this means that the main slowdown stems from the fact that we paint RTL text a character-at-a-time instead of a word-at-a-time. The reason we do that is that we have already performed our own bidi on the strings passed to Qt for painting, but Qt applies its own bidi algorithm, the end result being that the strings are painted backwards. We have already applied bidi internally, because we use that information extensively in other settings besides painting --- high-level layout (metrics) and cursor movement being the main places that I'm aware of. I basically see three approaches for solving this issue: (1) Get Qt to offer an option for painting which says "already visual, don't apply bidi". In fact, I'm pretty sure that when I was originally looking into the bidi problems in pre-1.5 LyX, I saw that Qt has such an option in their internal API, but it's not exposed; so it may not be hard for them to offer such an option. (2) Perhaps we could re-apply our bidi algorithm again just before passing the strings to Qt. That would mean that bidi is applied to the strings 3 times instead of once, which sounds a bit wasteful, but it's probably negligible next to the cost of the painting. (3) Perhaps we could entirely re-work our handling of bidi, such that we would not need our own bidi at all, and could rely entirely on Qt for providing this service. I think this would require major reworking, since, as explained, we use bidi information not only for painting, and I'm not sure how that would work. Personally, (1) seems like the easiest solution for us (it also best represents what we really want to do); but it would only work for users using Qt versions which would support this option. Should we file an enhancement request with Qt? (3) would require major work, and it would also break GUI independence (if we still care about that at all); however, it might be the cleanest solution in the long term. (2) might be a good compromise, which would allow us to apply a relatively quick patch, without needing third-party assistance. BTW, I'm afraid I won't have much time to put into this anytime soon... If there's anyone who wants to pursue this, though, I can try and help out. Anyhow, I opened a bug for this issue, we should move the discussion there http://bugzilla.lyx.org/show_bug.cgi?id=5188 . Dov
Bidi painting (was: Re: Problom with LYX)
Uwe Stöhr wrote:
> When I use LYX to create Persian texts, it's going so slow when you
> scroll the document, even you type only 3 or 4 pages. But I don't
occur this
> problem when writing in English. I attached a sample file to this mail.
What version of LyX are you using? Scrolling is indeed slower as for
English. The strange thing is that when I highlight all text of your
document and mar it as English too, I can scroll as fast as for English
text, although I still have the Farsi characters and the document
language is still Farsi.
So this is definitively a bug in our RTL (bidi) support.
Could you please report this bug at bugzilla.lyx.org?
thanks and regards
Uwe
Can you try the attached "patch" to see if it speeds things up? Note that this
is not really a patch --- the painting will be *incorrect* with it applied; but
it's just to diagnose whether the problem is where I think it is.
If it is, then we have to think about how to solve it --- I don't really have
any good suggestions... :( . But let's worry about that once we confirm that
that's really the problem...
Dov
diff -r 19a9abc0bcf0 src/rowpainter.cpp
--- a/src/rowpainter.cpp Sat Aug 09 17:01:20 2008 +
+++ b/src/rowpainter.cpp Sun Aug 10 23:16:20 2008 +0300
@@ -274,8 +274,8 @@
* Arabic characters, but rather paint them one at a time.
* See also http://thread.gmane.org/gmane.editors.lyx.devel/79740
*/
- if (hebrew)
- break;
+// if (hebrew)
+// break;
/* FIXME: these checks are irrelevant, since 'arabic' and
* 'hebrew' alone are already going to trigger a break.
@@ -298,7 +298,7 @@
c = '(';
c = par_.transformChar(c, pos);
/* see comment in hebrew, explaining why we break */
- break;
+ //break;
}
str.push_back(c);
Re: The text completer is eating the Tab key.
Abdelrazak Younes wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: Hi! I want to bring up this issue again as it is not solved yet. The problem is simple: TAB is used for completion, but also for jumping to the next cell in a table. So it's a key conflict. AFAIK TAB is quite common for completion and therefore intuitive for users, but probably also for jumping in a table. Well, this is not exactly true as, in conventional word processors (OO, MSWord, etc), TAB is used for formatting purpose when used in text and for cell jumping in table (you have to use Ctrl-tab to have tabulation). I am not suggesting that we should do the same but that'd be the least surprise behavior for a newbie. There are also other approaches like in OpenOffice for example: they use enter to accept the completion, but I don't see how to cycle through the alternatives. With the up/down arrow keys? I never got used to OpenOffice's completion. For me it's pretty annoying. Xcode on Mac uses Escape to open the popup, but also TAB to complete. Escape is strange in the beginning, but you get used to it. Qt appends the completion as selection. So if you continue typing, the selection (i.e. = completion) is replaced with the typed text. To accept the completion, you can move the cursor to remove the selection. This approach does not work with the iterative completion up to the end of the unique part. I don't really like it either. So what are the opinion about this issue? I agree with Abdel that it should be solved for 1.6, but I don't see how without making completion less intuitive. Here's a proposal: - Use the right arrow key instead of the TAB key for the initial combo popup. Sorry, I meant 'Alt-right arrow' here. right arrow should of course be reserved for navigation. - Use the down/up arrow and/or TAB to select another suggestion. As long as the completion combo, it is OK to let it have precedence for the TAB key. - Use the right arrow to accept the currently selected - Continue typing if you don't want to accept the current selection. - Use the left arrow to dismiss the completion combo. The only drawback of this proposal compared to the current TAB based one is that the TAB ley is closer to the character keys than the arrow keys. Abdel. Well, how about borrowing from text editors? Emacs uses Alt-/ , I believe; Vim uses Ctrl-P and Ctrl-N (previous and next). These both initiate completion, and cycle between the different completion options. Although only programmers may consider these "standard", we might as well use them, since there doesn't really seem to be anything that is *more* standard... Is it possible for completion to be bound to a key through the bind files? Last time I looked, the completion key was hard-coded? If it can be done with the bind files, then users could also change it if necessary; emacs style (Alt-/) could (should) be used in emacs.bind, without necessarily choosing that for all other styles. So IMO, the focus should be on enabling this through the regular bind mechanism. I also agree with Abdel, though, that once the completion popup is up, the up and down keys also seem pretty natural for cycling between the options... Dov
Re: problem compiling (linking) trunk
Pavel Sanda wrote: Dov Feldstern wrote: Abdelrazak Younes wrote: Dov Feldstern wrote: Hi! Linux, Qt 4.2.1: frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function `lyx::frontend::GuiApplication::setGuiLanguage()': /home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031: undefined reference to `lyx::Messages::main_lang_' collect2: ld returned 1 exit status make[4]: *** [lyx] Error 1 I don't understand. main_lang_ is declared here: src\support\Messages.cpp(87):string Messages::main_lang_; Are you sure support/ was correctly recompiled? Abdel. Hmm, looks like it isn't... I checked and saw that there was a file src/support/Messages.o; but it doesn't seem to contain (checked with nm and with strings) and mention of 'lang'. So I deleted it, and it wasn't even rebuilt. If I'm the only one seeing this, maybe it's my problem --- I'll try from a clean install again. Has anyone successfully compiled trunk recently on linux, with gcc and with autotools? here no problem. try make distclean. pavel OK, the problem is this: it doesn't compile with the --disable-nls flag; without this flag it compiles cleanly. I always compile with this flag, though I don't know if it still has any significance? But I guess it should either be fixed, or the flag should be removed... Dov
Re: problem compiling (linking) trunk
Abdelrazak Younes wrote: Dov Feldstern wrote: Hi! Linux, Qt 4.2.1: frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function `lyx::frontend::GuiApplication::setGuiLanguage()': /home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031: undefined reference to `lyx::Messages::main_lang_' collect2: ld returned 1 exit status make[4]: *** [lyx] Error 1 I don't understand. main_lang_ is declared here: src\support\Messages.cpp(87):string Messages::main_lang_; Are you sure support/ was correctly recompiled? Abdel. Hmm, looks like it isn't... I checked and saw that there was a file src/support/Messages.o; but it doesn't seem to contain (checked with nm and with strings) and mention of 'lang'. So I deleted it, and it wasn't even rebuilt. If I'm the only one seeing this, maybe it's my problem --- I'll try from a clean install again. Has anyone successfully compiled trunk recently on linux, with gcc and with autotools? I'll report back if there are any developments. Thanks!
Re: translate to arabic
Abdelrazak Younes wrote: Dov Feldstern wrote: I'm forwarding Ran's response about this; sounds like it's a problem also in Hebrew... I'm not sure what the current status is --- is this already fixed in trunk? Yes, it is fixed :-) Abdel. Great! Ran --- are you able to compile the latest trunk to check this out? I'll also try to check, as soon as I'm able to compile again. Abdel --- I think the fix may be what's causing the link error that I just reported to the list --- it's complaining about something in setGuiLanguage(). Could you take a look at this? Thanks! Dov
Re: translate to arabic
I'm forwarding Ran's response about this; sounds like it's a problem also in Hebrew... I'm not sure what the current status is --- is this already fixed in trunk? Ran Rutenberg wrote: Hi, Right now, LyX's menus in Hebrew are aligned to the left. Hebrew and Arabic are both RTL languages and it is preferred that the menus will be aligned to the right (File menu is supposed to be the rightmost one). This is the case in most Hebrew localized software. I planned to make a feature request regarding this issue, and if it is possible to make this adjustment it would be great. Sincerely, Ran Rutenberg 2008/7/30, Dov Feldstern <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: Abdelrazak Younes wrote: Uwe Stöhr wrote: The menu positions itself are not changed, so the File menu will always be the first one at the left side of the screen. Abdel, do you know if Qt supports this? I guess so. I am actually surprised that this is not the default. QMenuBar doc doesn't say anything about RTL languages... What about Hebrew Dov, is it the same? Abdel. Hi! Sorry, I haven't been following the list on a daily basis lately... Also, I'm afraid I can't help much in this respect, since I don't use localization (i.e., my interface is English) so I don't know how this works. If it's still relevant, I guess the best bet would be to ask Ran about this, I'm pretty sure that he uses localized Hebrew...? Dov
problem compiling (linking) trunk
Hi! Linux, Qt 4.2.1: frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function `lyx::frontend::GuiApplication::setGuiLanguage()': /home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031: undefined reference to `lyx::Messages::main_lang_' collect2: ld returned 1 exit status make[4]: *** [lyx] Error 1 Thanks! Dov
Re: [Fwd: add equation from RTL]
Uwe Stöhr wrote: hatim ali wrote: i hope you can add written Mathematical equation from right to left, like the image in attachment, i do it with texmaker program. I think that this is already possible. Dov, Ran, is this the case? regards Uwe Mmmm, no, I'm afraid not; AFAIK, LyX does not currently support RTL text inside math... I'm not sure why; OTOH, I'm not sure how to do it in LaTeX. Hatim, could you send the list the latex which produces a minimal example of Arabic inside a math equation? Though I'm not going to have much time anytime soon to work on it... Dov
Re: translate to arabic
Abdelrazak Younes wrote: Uwe Stöhr wrote: The menu positions itself are not changed, so the File menu will always be the first one at the left side of the screen. Abdel, do you know if Qt supports this? I guess so. I am actually surprised that this is not the default. QMenuBar doc doesn't say anything about RTL languages... What about Hebrew Dov, is it the same? Abdel. Hi! Sorry, I haven't been following the list on a daily basis lately... Also, I'm afraid I can't help much in this respect, since I don't use localization (i.e., my interface is English) so I don't know how this works. If it's still relevant, I guess the best bet would be to ask Ran about this, I'm pretty sure that he uses localized Hebrew...? Dov
Re: bug due to r25666
Richard heck wrote: rgheck wrote: rgheck wrote: Dov Feldstern wrote: Hi! By bisecting, I've determined the following bug is due to r25666 (http://www.lyx.org/trac/changeset/25666). I've tried to fix this at r. The fix is horrible, basically, but I don't see any better way to do it. I've put a long FIXME in InsetTabular.h describing the problem---basically, we need to make a certain decision in the InsetTableCell objects, but the information we need is in the Tabular object. This at least solves the reported problem. Please let me know if there are other issues. rh Thanks, Richard! It seems to be working fine now.
bug due to r25666
Hi! By bisecting, I've determined the following bug is due to r25666 (http://www.lyx.org/trac/changeset/25666). This is the bug: the attached LyX file (r25666-bug.lyx), when opened in r25665, correctly produces the dvi output correct.dvi; when opened in r25666, however, the output is incorrect.dvi. The thing is this: the file can initially be created also in r25666, and then it displays correctly. If you then save it, the saved file is identical to that created in r25665. But when you load it, the layout is no longer preserved inside the cell; and there is no option to change the layout: the layout box is now grayed out, and trying to set itemize with 'Alt-p i' produces the message 'Command disabled' in the status bar. Thanks! Dov r25666-bug.lyx Description: application/lyx correct.dvi Description: TeX dvi file incorrect.dvi Description: TeX dvi file
Re: Still no composing, and a crash...
Moving this discussion from lyx-users to lyx-devel...
The crash (trace below) seems to be related to file management in general, not
to keyboard maps per se.
So there are really two problems here:
(1) the crash
(2) getting compose keys to work (with or without using keymaps --- my guess is
probably without, since it appears to work in other applications)
I'm afraid I'm not familiar with either of these areas...
Dov
John Coppens wrote:
On Fri, 04 Jul 2008 18:49:22 +0300
Dov Feldstern <[EMAIL PROTECTED]> wrote:
John Coppens wrote:
Hello people.
I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.
I reported the accented character composing problem a while ago (it
just doesn't work - I can't type Compose-e-', and get é, as I _can_
with other programs, like sylpheed).
If it works in other programs, that probably means that your os is
setup to handle this, so there should be no need for LyX's built-in
keymaps. Try disabling the "use keyboard map" option, and see if that
helps.
LyX starts with the keyboard disabled - compose doesn't work. I wanted to
try and enable it, which caused the crash.
I have xmodmap definitions for the compose character:
keycode 116 = Multi_key
Running LyX in gdb:
[New Thread 0xb6da2af0 (LWP 16563)]
[New Thread 0xb695ab90 (LWP 16566)]
[New Thread 0xb5f88b90 (LWP 16568)]
[New Thread 0xb5788b90 (LWP 16569)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6da2af0 (LWP 16563)]
QFileSystemModel::parent (this=0x892eb58, [EMAIL PROTECTED])
at dialogs/qfilesystemmodel_p.h:200
200 dialogs/qfilesystemmodel_p.h: No such file or directory.
in dialogs/qfilesystemmodel_p.h
Current language: auto; currently c++
And the backtrace:
#0 QFileSystemModel::parent (this=0x892eb58, [EMAIL PROTECTED])
at dialogs/qfilesystemmodel_p.h:200
#1 0xb7c3afee in QUrlModel::dataChanged (this=0x8c20ba0,
[EMAIL PROTECTED],
[EMAIL PROTECTED])
at ../../include/QtCore/../../src/corelib/kernel/qabstractitemmodel.h:350
#2 0xb7d76a52 in QUrlModel::qt_metacall (this=0x8c20ba0,
_c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbff6c1c0)
at .moc/release-shared/moc_qsidebar_p.cpp:67
#3 0xb7364e5a in QMetaObject::activate (sender=0x892eb58,
from_signal_index=4, to_signal_index=4, argv=0xbff6c1c0)
at kernel/qobject.cpp:3081
#4 0xb73653c5 in QMetaObject::activate (sender=0x892eb58, m=0xb73fe6a8,
local_signal_index=0, argv=0xbff6c1c0) at kernel/qobject.cpp:3140
#5 0xb73857c3 in QAbstractItemModel::dataChanged (this=0x892eb58,
[EMAIL PROTECTED],
[EMAIL PROTECTED]) at .moc/release-shared/moc_qabstractitemmodel.cpp:123
#6 0xb7c46cb1 in QFileSystemModelPrivate::_q_fileSystemChanged (
this=0x8c0deb0, [EMAIL PROTECTED], [EMAIL PROTECTED])
at dialogs/qfilesystemmodel.cpp:1575
#7 0xb7d76f77 in QFileSystemModel::qt_metacall (this=0x892eb58,
_c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xb600ccf8)
at .moc/release-shared/../../dialogs/qfilesystemmodel_p.h:150
#8 0xb736105b in QMetaCallEvent::placeMetaCall (this=0x18, object=0x1)
at kernel/qobject.cpp:536
#9 0xb7366fe7 in QObject::event (this=0x892eb58, e=0x892eb58)
at kernel/qobject.cpp:1122
#10 0xb77befb0 in QApplicationPrivate::notify_helper (this=0x8790550,
receiver=0x892eb58, e=0xb6008f28) at kernel/qapplication.cpp:3556
#11 0xb77bf111 in QApplication::notify (this=0x8793a20,
#receiver=0x892eb58,
e=0xb6008f28) at kernel/qapplication.cpp:3497
#12 0x083edd3a in lyx::frontend::GuiApplication::notify ()
#13 0xb7352cef in QCoreApplication::notifyInternal (this=0x8793a20,
receiver=0x892eb58, event=0xb6008f28) at
kernel/qcoreapplication.cpp:530
#14 0xb735718f in QCoreApplicationPrivate::sendPostedEvents
#(receiver=0x0,
event_type=0, data=0x8738da8)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:200
#15 0xb7357305 in QCoreApplication::sendPostedEvents (receiver=0x0,
event_type=-1) at kernel/qcoreapplication.cpp:1001
#16 0xb7379182 in postEventSourceDispatch (s=0x8798740)
at ../../include/QtCore/../../src/corelib/global/qglobal.h:1794
#17 0xb719d56c in IA__g_main_context_dispatch (context=0x87986c0)
at gmain.c:2065
#18 0xb71a0bbf in g_main_context_iterate (context=0x87986c0, block=1,
dispatch=1, self=0x87964c0) at gmain.c:2698
#19 0xb71a1122 in IA__g_main_context_iteration (context=0x87986c0,
#may_block=1)
at gmain.c:2761
#20 0xb7379085 in QEventDispatcherGlib::processEvents (this=0x8796538,
#flags=
flags={i = -1208935320})
at ../../include/QtCore/../../src/corelib/global/qglobal.h:1773
#22 0xb73521d8 in QEventLoop::processEvents (this=0x18, flags=Cannot
#access memory at address 0x18
)
at ../../include/QtCore/../../src/corelib/global/qglobal.h:1773
#23 0xb73523c1 in QEventLoop::exec (this=0xbff6cc30, flags={i = 0})
at ../../include/QtCore/../../src
view source, outliner open on startup?
Hi! Starting quite recently (within the last two weeks?) the view source and outliner widgets are open when LyX starts; this didn't used to be the case. I don't see any preference controlling this. can the old behavior be restored? Thanks! Dov
Re: problem compiling trunk (Qt 4.2.1)
Abdelrazak Younes wrote: Dov Feldstern wrote: Abdelrazak Younes wrote: Dov Feldstern wrote: Thanks! Dov imagetools.cpp:18:24: error: QImageReader: No such file or directory Really? http://doc.trolltech.com/4.2/qimagereader.html Hmmm, yes... Well, I see that all the generated ui_XXX.h files include it this way: , and that does solve the issue... Oh... I thought this was a QtCore module... sorry, I'll move that to the frontend then. Abdel. That did it, thanks!
Re: problem compiling trunk (Qt 4.2.1)
Abdelrazak Younes wrote: Dov Feldstern wrote: Thanks! Dov imagetools.cpp:18:24: error: QImageReader: No such file or directory Really? http://doc.trolltech.com/4.2/qimagereader.html Hmmm, yes... Well, I see that all the generated ui_XXX.h files include it this way: , and that does solve the issue...
problem compiling trunk (Qt 4.2.1)
Thanks! Dov imagetools.cpp:18:24: error: QImageReader: No such file or directory imagetools.cpp: In function '__gnu_debug_def::vectorstd::char_traits, std::allocator >, std::allocator, std::allocator > > > lyx::support::loadableImageFormats()': imagetools.cpp:31: error: 'QImageReader' has not been declared make[4]: *** [imagetools.lo] Error 1 make[4]: Leaving directory `/home/dovf/lyx-trunk-new/src/support' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/dovf/lyx-trunk-new/src/support' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dovf/lyx-trunk-new/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/dovf/lyx-trunk-new/src' make: *** [all-recursive] Error 1
Re: [Cvslog] r25108 - in /lyx-devel/trunk/src/frontends/qt4: GuiComple...
Bernhard Roider wrote: [EMAIL PROTECTED] schrieb: Author: broider Date: Wed Jun 4 00:00:47 2008 New Revision: 25108 URL: http://www.lyx.org/trac/changeset/25108 Log: Fix item delegate for qt 4.2: In the completion-listbox rtl-Text does not work like it does for newer qt and icons are not displayed for math symbols. The rtl handling is incorrect atm but now it works the same way for all versions of qt. Dov, will you correct the rtl issue in the list box? Done (http://www.lyx.org/trac/changeset/25118) Thinking of it there is another issue/feature: ATM the completion list contains all words from the whole document. If the document is composed of different languages, then the words are mixed up in the list. Maybe it would be nice to associate the language to the word and - Display only the words from the current language and, after a shortcut display all words OR - Indicate the language for each entry OR - group the entries by language in the list box - When inserting a word from the completion list then change the language for the new inserted word to the associated one. opinions? I'm not sure I follow you here. I only use completion, well, to complete a word that I started typing, and then I only see those words that already exist in the document, which complete it? bernhard
Re: [PATCH] GuiCompeter problems with qt 4.2.x
Stefan Schimanski wrote:
I tried the patch now and it looks good. The RTL issues I will leave to
Dov to judge.
In fact I wonder whether it also fixes my other crash with Qt 4.4 on Mac
which I reported some time ago. At least in my little testing I was not
able to make it crash again.
Stefan
OK, here's what I think should be removed for RTL. This is to be applied *after*
Bernhard's patch. Feel free to apply them together, if you want.
Dov
diff -r a839cad6131a src/frontends/qt4/GuiCompleter.cpp
--- a/src/frontends/qt4/GuiCompleter.cppMon Jun 02 20:28:55 2008 +0300
+++ b/src/frontends/qt4/GuiCompleter.cppMon Jun 02 21:07:28 2008 +0300
@@ -47,31 +47,18 @@
{
public:
explicit CompleterItemDelegate(QObject * parent)
- : QItemDelegate(parent), enabled_(false)
+ : QItemDelegate(parent)
{}
~CompleterItemDelegate()
{}
- void setEnabled(bool enabled = true)
- {
- enabled_ = enabled;
- }
-
protected:
void drawDisplay(QPainter * painter,
QStyleOptionViewItem const & option,
QRect const & rect, QString const & text) const
{
- if (!enabled_) {
- QItemDelegate::drawDisplay(painter, option, rect, text);
- return;
- }
-
- // FIXME: do this more elegantly
- docstring stltext = qstring_to_ucs4(text);
- reverse(stltext.begin(), stltext.end());
- QItemDelegate::drawDisplay(painter, option, rect,
toqstr(stltext));
+ QItemDelegate::drawDisplay(painter, option, rect, text);
}
void paint(QPainter *painter, const QStyleOptionViewItem &option,
@@ -97,9 +84,6 @@
drawFocus(painter, opt, option.rect);
painter->restore();
}
-
-private:
- bool enabled_;
};
class GuiCompletionModel : public QAbstractListModel
@@ -474,19 +458,16 @@
if (old.length() == 0)
old = last_selection_;
+
// set whether rtl
bool rtl = false;
if (cur.inTexted()) {
Paragraph const & par = cur.paragraph();
Font const font =
- par.getFontSettings(cur.bv().buffer().params(), cur.pos());
+ par.getFontSettings(cur.bv().buffer().params(),
cur.pos());
rtl = font.isVisibleRightToLeft();
}
popup()->setLayoutDirection(rtl ? Qt::RightToLeft : Qt::LeftToRight);
-
- // turn the direction of the strings in the popup.
- // Qt does not do that itself.
- itemDelegate_->setEnabled(rtl);
// set new model
CompletionList const * list = cur.inset().createCompletionList(cur);
diff -r a839cad6131a src/rowpainter.cpp
--- a/src/rowpainter.cppMon Jun 02 20:28:55 2008 +0300
+++ b/src/rowpainter.cppMon Jun 02 21:07:28 2008 +0300
@@ -838,8 +838,6 @@
// right to left?
if (rtl) {
swap(s1, s2);
- reverse(s1.begin(), s1.end());
- reverse(s2.begin(), s2.end());
swap(c1, c2);
}
Re: Beta 2 (private announcement)
José Matos wrote: Hi all, as discussed during the weekend and in order to fix the problems that appeared with beta 1 I have tagged a new release (beta 2). As it happened previously I am asking for help to guarantee that there are no embarrassing bugs. I mean in this case a failure to compile, on any of our traditional platforms, or any dataloss bug. In the context of the first beta a crash under certain circumstances is not embarrassing although it is certainly a bug that should be fixed. So let us please test this release and when there is some confidence in the release tar ball let us announce this also in the users list. Compiles fine on Linux with qt 4.2.1
Re: Introduction and Armenian language support
Suren Karapetyan wrote:
Hi there!
I'm Suren Karapetyan from Armenia.
I've spent the last few hours trying to understand how I'm supposed to
write Armenian book with LyX.
I'm trying to rewrite the book I wrote with a friend of mine
(http://www.pocpp.org) in LyX.
And of course I have a problem embedding English words in Armenian text.
I do speak/read/write Armenian quite excellent and also I have
programming skills.
And I'm really interested in making it work better.
So if someone takes his time explaining what to do and from where to
start I'll be happy to help the project (and myself) adding good
Armenian support.
Regards
Suren
Hi, Suren!
Exactly what kind of problem are you having "embedding English words" --- are
you having trouble typing it in as English, or does LaTeX complain when you try
to compile, or what?
One thing you should realize is that it is important to tell LaTeX that you are
switching languages when you do --- in other words: it's not enough to just type
in some English words by switching the keyboard (I believe Armenian uses a
non-Latin character set?), you also have to mark those words as 'english', so
that LaTeX can process it correctly. There are a few ways to do this:
1. In Edit -> Text Style -> customized..., you can switch the Language to
English (I'm assuming your default language is set to Armenian)
2. in the minibuffer (View->Toolbars->Command Buffer, or Alt-x with the cua
bindings), type 'language english' to switch from the default language to
english, and then again 'language english' to switch back to the default
language ('language ' is a toggle between the default language and the
language ).
3. You can create your own binding for the 'language xxx' command, so that you
can toggle the language with a single keystroke. In Hebrew we use F12 for this,
I suggest you do the same. The file should just contain something like the
following two lines, and then you have to tell LyX to use it as you bind file:
\bind_file cua # "includes" the normal bind file
\bind "F12" "language armenian"
I'm not sure if this at all addresses the issues you're having; if not, try to
provide more details about what exactly is and isn't working.
Hope this helps!
Dov
Re: Request to test beta 1
José Matos wrote: Hi, temporarily I have placed the source for lyx-1.6.0beta1 in http://lyx.org/~jamatos/lyx-1.6/ If it goes well we could/should announce it publically and then it would be nice to have packages to test this under different scenarios. If the sources have some unseen problem I would like to fix those issues as soon as possible and then release the second beta immediately. Regards, FWIW, seems to be working fine for me (linux, qt 4.2.1). I do get the message "unknown Inset type 'Space'", though... Dov
Re: [PATCH] GuiCompeter problems with qt 4.2.x
Bernhard Roider wrote:
Hello Stefan,
today i finally found some time to investigate the problem we discussed
at the beginning of march concerning the completion list: rtl text does
not work and icons are not displayed for math symbols.
Here is a patch that solves that issue for me using qt 4.2.3. There are
two things that caused the problem:
1. QCompleter::setModel() changed the item delegates internally, so the
specialized ones vanished
2. item delegates for columns are not used --> qt bug?
The attached patch solves both issues so that it works with my qt
version. It should be tested for newer versions of qt.
...
bernhard
Hi!
What exactly is the problem with RTL completion that this patch is trying to
solve? Can you separate out the part dealing with RTL from the rest of the patch?
Without your patch, I'm seeing (Linux, Qt 4.2.1) RTL completion behave
correctly, except for the fact that the inline completion (the grayed out part)
is reversed; the list of completions, though, behaves correctly.
With your patch applied, also the strings in the completions list are reversed.
Applying the attached (very complicated ;) ) patch *instead* of yours fixes the
problem of the inlined strings, without adversely affecting the completions list.
I believe that what's happening is this: the completions list is presumably
getting the strings in "logical" order (the way they're held in memory). When
the strings are painted (both in the list and inlined), since they are being
painted as an entire string at once (and not one character at a time, as we
normally do with RTL text) Qt is applying its own bidi algorithm, and thus the
strings are painted correctly, *provided* that the strings are really composed
of true RTL characters (Qt does not know about our marking text as RTL, it only
knows if text is RTL or not based on the unicode values). You guys were probably
testing the RTL capabilities with Latin characters, so Qt was *not* reversing
the strings, and thus the strings appeared to you to be painted backwards, which
is why you were applying an extra reversal.
I'm not sure whether locale settings affect this or not, but I think that they
don't, as long as there is a *legal* locale setting.
In summary, I think that the reversals should be removed, as in the attached
patch. If most of Bernhard's patch is still relevant for non-RTL issues, then
the RTL-specific issues should be removed from it, as well.
To be sure, this solution isn't perfect, because we're being inconsistent by
letting Qt do some of the bidi work, and doing some of it ourselves; and this
becomes visible precisely in the pathological cases where there's a difference
between us and Qt, such as Latin text which we mark as RTL; but for normal RTL
usage, I believe the reversals should *not* be done.
Dov
diff -r bc5502bbefc5 src/rowpainter.cpp
--- a/src/rowpainter.cppThu May 29 23:11:06 2008 +
+++ b/src/rowpainter.cppFri May 30 11:45:00 2008 +0300
@@ -838,8 +838,6 @@
// right to left?
if (rtl) {
swap(s1, s2);
- reverse(s1.begin(), s1.end());
- reverse(s2.begin(), s2.end());
swap(c1, c2);
}
Re: The text completer is eating the Tab key.
Abdelrazak Younes wrote: Hello Stefan, It is thus not possible to use the Tab key to navigate in a table or in an equation. ... I am not sure how this can be fixed but this needs to be fixed IMHO. Abdel. I agree. We discussed this a while back (http://thread.gmane.org/gmane.editors.lyx.devel/104985), it seems that the first problem is deciding how the completion interface *should* work... I think it would be best if it could be delegated to an LFUN(s), and then the exact interface can be handled through the bind-files. I don't know the internals of how it's working, so I'm not sure that what I'm saying makes sense... Dov
Re: [Cvslog] r24802 - /lyx-devel/trunk/src/frontends/qt4/GuiApplicatio...
[EMAIL PROTECTED] wrote: Author: younes Date: Fri May 16 16:30:46 2008 New Revision: 24802 URL: http://www.lyx.org/trac/changeset/24802 Log: Compil fix for Qt4.2 Great, thanks Abdel!
trunk doesn't compile with Qt 4.2.1
Hi! I'm getting the following error on linux, qt 4.2.1: GuiApplication.cpp: In member function 'QAbstractItemModel* lyx::frontend::GuiApplication::languageModel()': GuiApplication.cpp:479: error: 'class QSortFilterProxyModel' has no member named 'setSortLocaleAware' Thanks! Dov (Sorry if this was already reported, I haven't had a chance yet to go over the list this week.)
Re: RCS usage in lyx, git
Bo Peng wrote: I've thought many time about this too. That would be very, very nice. But my understanding is that git is current unix (even linux) only so this feature will only benefit a few users. Bo There's also mercurial, which I find very very nice, and which is cross-platform (python based). More on topic, though, I've never used the Version Control options from within LyX, nor have I ever really had the urge to; if I want to version control a document, I do it externally, and prefer it that way. Dov
visual cursor in tables
Hi! I just committed another stage of the visual cursor work (http://www.lyx.org/trac/changeset/24235) --- this makes this work in tables, too. Please pay attention to cursor movement within tables to make sure that I didn't break anything! Thanks! Dov
selection out of math insert (was: Re: [OT] templating latex)
Dov Feldstern wrote: Dov Feldstern wrote: Andre Poenitz wrote: On Fri, Apr 04, 2008 at 12:15:24PM +0300, Dov Feldstern wrote: [something unrelated ;-)] Hi Dov. Since you are around: I have a suspicion tha change 22930 removed the possibility do extend a selection in mathed using Shift+Left/Right outside the current cell. This was possible at some point of time, and still works out side math. I wouldn't mind if you could have a look... Andre' Hi, Andre'! Yes, I see the problem, I'll try to take a look at it tonight. Thanks for the heads-up! Dov Hmmm, I can confirm that my change introduced the problem. I'll see what I can do about it... Hi, Andre'! OK, I have a fix for this issue, attached. 1) Is there an open bug in bugzilla for this issue (just so that I can write it in the commit log)? 2) Do you understand why this works? For the life of me, I can't figure it out: it seems to me that I had been preserving the original behavior, which only the current fix is now breaking: In the old code (i.e., 22929), we would have reached http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed/InsetMathNest.cpp?rev=22929#L513, cur.selection() would be true, and therefore we would *not* dispatch LFUN_FINISHED_FORWARD. So, in 22930 I tried to keep that behavior: we would reach http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed/InsetMathNest.cpp?rev=22930#L559, enter cursorMathForward, and at http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed/InsetMathNest.cpp?rev=22930#L1597 cur.selection() would again be true, we would return true, and therefore again *not* dispatch lfun_finish (back at http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed/InsetMathNest.cpp?rev=22930#L562). Now, with the fix, I'm changing that. Did I just get mixed up with a De Morgan or something? Thanks! Dov diff -r 034d677c3be2 src/mathed/InsetMathNest.cpp --- a/src/mathed/InsetMathNest.cpp Sun Feb 10 19:57:00 2008 + +++ b/src/mathed/InsetMathNest.cpp Sun Apr 06 20:41:23 2008 +0300 @@ -1594,7 +1594,7 @@ cur.inset().idxFirst(cur); return true; } - if (cur.posForward() || idxForward(cur) || cur.selection()) + if (cur.posForward() || idxForward(cur)) return true; // try to pop forwards --- but don't pop out of math! leave that to // the FINISH lfuns @@ -1613,7 +1613,7 @@ cur.inset().idxLast(cur); return true; } - if (cur.posBackward() || idxBackward(cur) || cur.selection()) + if (cur.posBackward() || idxBackward(cur)) return true; // try to pop backwards --- but don't pop out of math! leave that to // the FINISH lfuns
Re: Completion, cell-forward and the Tab key
Stefan Schimanski wrote: Am 29.03.2008 um 19:54 schrieb Dov Feldstern: Hi! How is the tab key bound to the completion function? I don't see it anywhere in the bind files... In fact it is not in the bind files. It's hardcoded right now in the gui, but should be a LFUN probably. Yeah, I think so... My problem is this: in tables, Tab is already bound to cell-forward (in site.bind, which is hardcoded to be read --- in two places, no less: Lyx::init and PrefShortcuts::apply), but now with the completion code, Tab is not doing cell-forward anymore --- I'm guessing because it now does completion. IMO, Tab should remain cell-forward --- it's quite standard, and Shift-Tab still does cell-backward. OTOH, Tab for completion, while standard in the shell, is not, I think, standard in editors (vim uses Ctrl-p, emacs uses Alt-\ if I remember correctly?). So I think it would be better if LyX would adopt a different key-binding for completion, and keep the Tab as cell-forward. Tab is natural in mathed IMO. But you are right about tabulars for sure. If we could have it behave one way in mathed, and another way in tabulars (and therefore also in regular text), that sounds good to me. I'm not sure how one would go about that, though. Are the key bindings context-sensitive? Something like Ctrl-p is not intuitive though, Alt-\ neither. Yeah, I agree, unless you're coming from vim/emacs... ;) Wondering about a good shortcut. Any idea? What is e.g. OpenOffice doing? Does OpenOffice even have this feature?! I don't think MS-Word does (but I wouldn't really know, I use both of these as little as possible). I think that LyX may be breaking new ground here, by transferring this feature which is used a lot by programmers, to writers. Hmmm, I just found http://en.wikipedia.org/wiki/Word_completion, which is actually interesting (and yes, apparently OO *does* have this feature!). But didn't help in terms of suggesting a shortcut... :( Stefan Thanks! Dov
Completion, cell-forward and the Tab key
Hi! How is the tab key bound to the completion function? I don't see it anywhere in the bind files... My problem is this: in tables, Tab is already bound to cell-forward (in site.bind, which is hardcoded to be read --- in two places, no less: Lyx::init and PrefShortcuts::apply), but now with the completion code, Tab is not doing cell-forward anymore --- I'm guessing because it now does completion. IMO, Tab should remain cell-forward --- it's quite standard, and Shift-Tab still does cell-backward. OTOH, Tab for completion, while standard in the shell, is not, I think, standard in editors (vim uses Ctrl-p, emacs uses Alt-\ if I remember correctly?). So I think it would be better if LyX would adopt a different key-binding for completion, and keep the Tab as cell-forward. Thanks! Dov
Re: [Cvslog] r23763 - in /lyx-devel/trunk/src: Text.cpp Text.h TextMet...
[EMAIL PROTECTED] wrote: Author: sts Date: Sat Mar 15 13:22:28 2008 New Revision: 23763 URL: http://www.lyx.org/trac/changeset/23763 Log: * moved text completion logic into Text class * added completion support to InsetTabular Thanks!
Re: [Cvslog] r23743 - /lyx-devel/trunk/src/frontends/qt4/ui/PrefLangua...
[EMAIL PROTECTED] wrote: Author: sanda Date: Sat Mar 15 00:50:02 2008 New Revision: 23743 URL: http://www.lyx.org/trac/changeset/23743 Log: Try to deuglify RTL in Language preferences a bit. I guess it's a matter of taste, but I don't really think that this is an improvement... ;)
Re: 1.6svn regression: enum/item in tables
rgheck wrote: Richard Heck wrote: Dov Feldstern wrote: Dov Feldstern wrote: Hi! It seems that enumeration/itemize (perhaps other layouts as well?) are no longer working inside a table. See the attached lyx file, created with r23573 from March 8, which still works fine. Try opening it in current svn (by r23669 from March 11 the problem already exists) --- the itemize and enumeration layouts are not recognized --- not in the GUI, nor in the latex output --- the text just appears in standard layout. Using mercurials bisect extension (http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension), I was able to track this bug down to r23662. Richard --- any ideas? I'll have a look. I'm probably overdoing it by requiring tables to use the EmptyLayout. The solution is presumably to put the enumeration inside an empty layout. I've tested your file with the patch committed at r23756, and it seems to work. Let me know if there are any additional problems. Yes, this seems to solve the problem. Thanks! rh
Re: Text completion and RTL
Stefan Schimanski wrote: Am 14.03.2008 um 15:25 schrieb Dov Feldstern: Stefan Schimanski wrote: Am 14.03.2008 um 15:05 schrieb Dov Feldstern: Hi! There's a small problem with the text completion and RTL text: The grayed-out inline completion appears backwards in RTL text (see attached image). I have to check my code as well. The idea was to reverse the string if needed before telling Qt about. But maybe I got something wrong in this logic. Take a look at RowPainter::paintInlineCompletion. That's the code for the text mode. It's a bit more involved than you might expect, because the inline completion consists of the unique part (drawn in dark grey) and the non-unique part (drawn in light grey). I do a reversal of the rtl text there. No idea why it does not work. Or maybe Qt its own bidi magic? Thanks, I'll take a look at this. But I'll be a few days though... Sure, no problem. Btw, do you use a rtl locale for the gui? I mean maybe your Qt does some RTL magic which mine does not. Just an idea... I'll keep this possibility in mind, thanks... Stefan
Re: Text completion not working in tables?
Stefan Schimanski wrote: Am 14.03.2008 um 14:14 schrieb Dov Feldstern: Hi! Stefan --- the completion stuff looks really, really nice. Thanks! It seems to me that text completion is not working in tables. Math completion *does* work, though. Can anything be done about this? It can. But at the moment the support is only in InsetMathNest and InsetText. Have to try it for InsetTabular. Probably one can just copy the code from InsetText. Is the text inside a table cell not an InsetText? I sort of assumed that every cell contains an InsetText for its text... Stefan
Re: Text completion and RTL
Stefan Schimanski wrote: Am 14.03.2008 um 15:05 schrieb Dov Feldstern: Hi! There's a small problem with the text completion and RTL text: The grayed-out inline completion appears backwards in RTL text (see attached image). I have to check my code as well. The idea was to reverse the string if needed before telling Qt about. But maybe I got something wrong in this logic. Take a look at RowPainter::paintInlineCompletion. That's the code for the text mode. It's a bit more involved than you might expect, because the inline completion consists of the unique part (drawn in dark grey) and the non-unique part (drawn in light grey). I do a reversal of the rtl text there. No idea why it does not work. Or maybe Qt its own bidi magic? Thanks, I'll take a look at this. But I'll be a few days though... Stefan
Text completion and RTL
Hi! There's a small problem with the text completion and RTL text: The grayed-out inline completion appears backwards in RTL text (see attached image). I can explain why it is happening (and why this problem wasn't observed when RTL was tested with latin characters), but I don't know how to easily solve the issue. The reason is something like this: when painting text, LyX applies the bidi algorithm, so that the string that it ultimately passes to Qt for painting is already in visual order; however, Qt 4 now applies its own bidi algorithm to all strings that it paints, and it doesn't seem to provide any API for saying "the string is already in visual order, just paint it as it is". To get around this problem, we paint RTL strings one character at a time (see http://www.lyx.org/trac/browser/lyx-devel/trunk/src/rowpainter.cpp?rev=23522#L259). But I imagine that the grayed-out inline completion is painted as a full string... I haven't looked at the completion code at all, so I'm not sure exactly what's going on; but I'm pretty sure that this is the correct explanation of the problem. Any ideas on what can be done to solve it? Thanks! Dov <>
Text completion not working in tables?
Hi! Stefan --- the completion stuff looks really, really nice. Thanks! It seems to me that text completion is not working in tables. Math completion *does* work, though. Can anything be done about this? Thanks! Dov
Re: 1.6svn regression: enum/item in tables
Dov Feldstern wrote: Hi! It seems that enumeration/itemize (perhaps other layouts as well?) are no longer working inside a table. See the attached lyx file, created with r23573 from March 8, which still works fine. Try opening it in current svn (by r23669 from March 11 the problem already exists) --- the itemize and enumeration layouts are not recognized --- not in the GUI, nor in the latex output --- the text just appears in standard layout. Using mercurials bisect extension (http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension), I was able to track this bug down to r23662. Richard --- any ideas? Thanks! Dov
1.6svn regression: enum/item in tables
Hi! It seems that enumeration/itemize (perhaps other layouts as well?) are no longer working inside a table. See the attached lyx file, created with r23573 from March 8, which still works fine. Try opening it in current svn (by r23669 from March 11 the problem already exists) --- the itemize and enumeration layouts are not recognized --- not in the GUI, nor in the latex output --- the text just appears in standard layout. (I've been away for the past few weeks, and didn't go over the mailing list very thoroughly, so I apologize if this has already been reported). Thanks! Dov enum_item_in_table.lyx Description: application/lyx
Re: Trunk: Fonts Are a Mess
Hi! First of all, I just want to repeat what others have already said: this completion stuff looks really great, Stefan! Way to go! Secondly, I want to thank you on behalf of the RTL users, for not forgetting to deal with RTL issues related to this. I see that it's causing some trouble, and I appreciate your making the effort to sort this out. So good luck with that! (Unfortunately, I'm going to be offline from Monday for two-and-a-half weeks, so I won't offer my help; and anyhow, you seem to be managing just fine on your own ;) . But if there are any issues for which any RTL-user advice is needed, I'll be happy to try and help out when I get back.) Thanks again! Dov
Re: Warnings for Pavel
Angus Leeming wrote:
Pavel Sanda wrote:
Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because
something is fishy about it. AFAICT, this function doesn't do
anything... JMarc took a look and I think he also wasn't sure about
it... So before just fixing the warnings, we ought to try and
figure out what this function *should* be doing, and whether it's
necessary at all. I'm pretty sure I went quite far back in history,
and it hasn't been doing anything for ages...
but there is some code for certain cases, no?
Yes, but that code is never executed, which is even more disturbing.
Notice that the just before the switch, tag is set to RC_LAST, which
is the *last* case in the switch...
Looks like I was smoking something funny at the time ;-)
i see now. i would ask Angus http://www.lyx.org/trac/changeset/9485 ,
whats the purpose of that
code.
If memory serves, the idea was to enable LyX to handle updates to the
preferences that traditionally required the user to restart LyX for the
changed preference to take effect.
I've no idea why I initialized tag as I did. Maybe, LyX just blew up
when the switch was executed?
1876LyXRC::LyXRCTags tag = LyXRC::RC_LAST;
1877switch (tag) {
Angus
So now the question is: do we need this function at all at this point?
Since it seems to have been doing nothing for the past three years, can
we just get rid of it? Does anyone know if what the code that's in there
*should* have been doing is still needed?
Re: Warnings for Pavel
Pavel Sanda wrote: I purposely left RC_VISUAL_CURSOR out of this function, because something is fishy about it. AFAICT, this function doesn't do anything... JMarc took a look and I think he also wasn't sure about it... So before just fixing the warnings, we ought to try and figure out what this function *should* be doing, and whether it's necessary at all. I'm pretty sure I went quite far back in history, and it hasn't been doing anything for ages... but there is some code for certain cases, no? Yes, but that code is never executed, which is even more disturbing. Notice that the just before the switch, tag is set to RC_LAST, which is the *last* case in the switch... pavel
Re: Warnings for Pavel
Richard Heck wrote: LyXFunc.cpp: In function 'void lyxactOnUpdatedPrefs(const lyx::LyXRC&, const lyx::LyXRC&)': LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_LIMIT' not handled in switch LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_SCROLLBAR' not handled in switch LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_TABBAR' not handled in switch LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_TOOLBARS' not handled in switch LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_WIDTH' not handled in switch LyXFunc.cpp:1885: warning: enumeration value 'RC_VISUAL_CURSOR' not handled in switch I purposely left RC_VISUAL_CURSOR out of this function, because something is fishy about it. AFAICT, this function doesn't do anything... JMarc took a look and I think he also wasn't sure about it... So before just fixing the warnings, we ought to try and figure out what this function *should* be doing, and whether it's necessary at all. I'm pretty sure I went quite far back in history, and it hasn't been doing anything for ages... Dov
Re: [patch] visual bidi cursor movement
Pavel Sanda wrote: Committed: http://www.lyx.org/trac/changeset/22928 http://www.lyx.org/trac/changeset/22929 http://www.lyx.org/trac/changeset/22930 don't forget to add some entry into wiki news for 1.6 :) pavel Right, thanks for the reminder! Couldn't do it tonight, though, because of the shape Aussie's in...
Re: BIDI Fix (was Re: r22935 - /lyx-devel/trunk/src/insets/InsetTabular.cpp
Abdelrazak Younes wrote:
Dov, please verify this.
-void InsetTabular::edit(Cursor & cur, bool, EntryDirectionType)
+void InsetTabular::edit(Cursor & cur, bool, EntryDirectionType
direction)
{
//lyxerr << "InsetTabular::edit: " << this << endl;
cur.finishUndo();
cur.selection() = false;
cur.push(*this);
-if (left) {
+if (direction == ENTER_FROM_LEFT) {
if (isRightToLeft(cur))
cur.idx() = tabular.getLastCellInRow(0);
else
This was an oversight on my part --- I didn't realize that 'left' was
being used in the function. I don't understand how it compiled, though?
Anyhow, I fixed it in r22967. This is now equivalent to what used to be
there, and I didn't intend to change anything --- I haven't gotten
around to implementing visual mode in tables, yet --- that's what I
intend to do next.
The reason that this is the equivalent of what was there previously, and
not what you put in, is this: What my visual patches did was to change
the name of 'left' to 'front'. This parameter signifies that we are
entering the inset at the 'front' (which is the 'left' in LTR, but not
in RTL, and that's why I changed the name).
'direction' is a new beast, which is only relevant to visual mode. In
this mode, we *do* want to know what direction visually we are entering
the inset from, in addition to whether it's from the front or back. But
as I said, visual mode is not implemented for tables, yet, so for now
this function should remain unchanged.
BTW, I also tested this out in an RTL document, just to make sure...
Anyhow, thanks Abdel for spotting my bug, and drawing my attention to it!
Dov
Re: [patch] visual bidi cursor movement
Dov Feldstern wrote: Hi! Attached please find the latest versions of the visual mode for bidi cursor movement patches. I fixed them up based on feedback (mainly from Pavel and Abdel --- thanks!) Also, right movement is now included as well. If there are no objections I will commit soon. I believe that once I get some user feedback, some tweaking will be necessary; and there are still some follow up fixes which I'll try to get to. But the basic functionality is now in, and works well enough that that I would now like to get feedback from (bidi) users. I'll post a message to the users' list once I commit. Dov Committed: http://www.lyx.org/trac/changeset/22928 http://www.lyx.org/trac/changeset/22929 http://www.lyx.org/trac/changeset/22930
trouble compiling branch
Qt 4.2.1, Linux: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_ST R -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I ../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/i nclude/qt4/QtCore -I/usr/include/qt4/QtGui -I../../../boost -I../../../src/front ends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tp o -c Dialogs.cpp -o Dialogs.o ui/WrapUi.h: In member function 'void Ui_QWrapUi::setupUi(QDialog*)': ui/WrapUi.h:55: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/WrapUi.h:56: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/WrapUi.h:57: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/WrapUi.h:58: error: 'class QVBoxLayout' has no member named 'setBottomMargin' ui/WrapUi.h:61: error: 'class QGridLayout' has no member named 'setLeftMargin' ui/WrapUi.h:62: error: 'class QGridLayout' has no member named 'setTopMargin' ui/WrapUi.h:63: error: 'class QGridLayout' has no member named 'setRightMargin' ui/WrapUi.h:64: error: 'class QGridLayout' has no member named 'setBottomMargin' ui/WrapUi.h:65: error: 'class QGridLayout' has no member named 'setHorizontalSpa cing' ui/WrapUi.h:66: error: 'class QGridLayout' has no member named 'setVerticalSpaci ng' ui/WrapUi.h:119: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/WrapUi.h:120: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/WrapUi.h:121: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/WrapUi.h:122: error: 'class QHBoxLayout' has no member named 'setBottomMargin '
Re: trunk doesn't compile
Andre Poenitz wrote: On Sun, Feb 10, 2008 at 02:18:01AM +0200, Dov Feldstern wrote: Linux, Qt 4.2.1, autotools, g++ 4.1.2: g++ -g -O -o lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o PrinterParams.o Thesaurus.o ./.libs/liblyxcore.a ./.libs/liblyxmathed.a ./.libs/liblyxinsets.a frontends/.libs/liblyxfrontends.a frontends/qt4/.libs/liblyxqt4.a -L/build/buildd/qt4-x11-4.2.1/lib -L/usr/X11R6/lib ./.libs/liblyxgraphics.a support/.libs/liblyxsupport.a ../boost/.libs/liblyxboost.a /usr/lib/libaspell.so /usr/lib/libglib-2.0.so -lQtGui -laudio -lXt -lpng -lSM -lICE -lQtCore -lpthread -lXrender -lXrandr -lXfixes -lXcursor -lXinerama /usr/lib/libfreetype.so -lz -lfontconfig -lXext -lX11 -lm -ldl support/.libs/liblyxsupport.a(SignalSlot.o): In function `SlotImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:37: undefined reference to `vtable for lyx::SlotImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SignalImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:23: undefined reference to `vtable for lyx::SignalImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `lyx::Signal::fire()': /home/dovf/lyx-trunk/src/support/SignalSlot.cpp:38: undefined reference to `lyx::SignalImpl::fire()' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SlotImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:37: undefined reference to `vtable for lyx::SlotImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SignalImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:23: undefined reference to `vtable for lyx::SignalImpl' collect2: ld returned 1 exit status Is 'SignalSlotPrivate.cpp' compiled and linked in? Andre' Hmmm... it turns out to be a problem with automake 2.59, which I'd been using. I was getting errors about 'OBJC' during autogen.sh, and it turns out that upgrading to automake 2.60 is supposed to solve that. After upgrading to 2.61, trunk compiles fine... Thanks! Dov
[patch] visual bidi cursor movement
isChecked();
rc.language_auto_end = autoEndCB->isChecked();
@@ -1492,7 +1497,11 @@ void PrefLanguage::update(LyXRC const &
void PrefLanguage::update(LyXRC const & rc)
{
// FIXME: remove rtl_support bool
- rtlCB->setChecked(rc.rtl_support);
+ rtlGB->setChecked(rc.rtl_support);
+ if (rc.visual_cursor)
+ visualCursorRB->setChecked(true);
+ else
+ logicalCursorRB->setChecked(true);
markForeignCB->setChecked(rc.mark_foreign_language);
autoBeginCB->setChecked(rc.language_auto_begin);
autoEndCB->setChecked(rc.language_auto_end);
diff -r b1e35cc03de0 src/frontends/qt4/ui/PrefLanguageUi.ui
--- a/src/frontends/qt4/ui/PrefLanguageUi.uiSat Feb 02 16:48:58 2008 +0100
+++ b/src/frontends/qt4/ui/PrefLanguageUi.uiSat Feb 02 23:08:50 2008 +0200
@@ -5,8 +5,8 @@
0
0
-329
-300
+345
+401
@@ -19,6 +19,95 @@
6
+
+
+
+ Use b&abel
+
+
+
+
+
+
+
+
+
+
+
+
+ Language pac&kage:
+
+
+ languagePackageED
+
+
+
+
+
+
+
+
+
+ Qt::Vertical
+
+
+ QSizePolicy::Expanding
+
+
+
+ 20
+ 20
+
+
+
+
+
+
+
+ Mark &foreign languages
+
+
+
+
+
+
+ &Default language:
+
+
+ defaultLanguageCO
+
+
+
+
+
+
+ Command s&tart:
+
+
+ startCommandED
+
+
+
+
+
+
+
+
+
+ Command e&nd:
+
+
+ endCommandED
+
+
+
+
+
+
+ &Global
+
+
+
@@ -32,36 +121,6 @@
-
-
-
- Use b&abel
-
-
-
-
-
-
- Mark &foreign languages
-
-
-
-
-
-
- Qt::Vertical
-
-
- QSizePolicy::Expanding
-
-
-
- 20
- 20
-
-
-
-
@@ -69,20 +128,6 @@
-
-
-
- &Right-to-left language support
-
-
-
-
-
-
- &Global
-
-
-
@@ -90,56 +135,65 @@
-
-
-
- Language pac&kage:
-
-
- languagePackageED
-
-
-
-
-
-
- Command e&nd:
-
-
- endCommandED
-
-
-
-
-
-
- &Default language:
-
-
- defaultLanguageCO
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Command s&tart:
-
-
- startCommandED
-
+
+
+
+ Select to enable support of right-to-left languages (e.g.
Hebrew, Arabic).
+
+
+ &Right-to-left language support
+
+
+ false
+
+
+ true
+
+
+
+ 4
+
+
+ 6
+
+
+
+
+ 0
+
+
+ 6
+
+
+
+
+ Cursor movement:
+
+
+ false
+
+
+
+
+
+
+ Logical
+
+
+ true
+
+
+
+
+
+
+ Visual
+
+
+
+
+
+
@@ -154,7 +208,6 @@
autoBeginCB
autoEndCB
markForeignCB
- rtlCB
qt_helpers.h
diff -r 6500b2fb9551 src/Cursor.cpp
--- a/src/Cursor.cppSun Feb 10 01:14:38 2008 +0200
+++ b/src/Cursor.cppSun Feb 10 01:42:38 2008 +0200
@@ -5,6 +5,7 @@
*
* \author Alejandro Aguilar Sierra
* \author Alfredo Braunstein
+ * \author Dov Feldstern
* \author André Pönitz
* \author Stefan Schimanski
*
@@ -450,6 +451,276 @@ bool Cursor::posForward()
return false;
++pos();
return true;
+}
+
+
+void Cursor::getSurroundingPos(pos_type & left_pos, pos_type & right_pos)
+{
+ // preparing bidi tables
+ Paragraph const & par = paragraph();
+ Buffer const & buf = buffer();
+ Row const & row = textRow();
+ Bidi bidi;
+ bidi.computeTables(par, buf, row);
+
+ LYXERR(Debug::RTL, "bidi: " << row.pos() << "--" << row.endpos());
+
+ // The cursor is painted *before* the character at pos(), or, if
'boundary'
+ // is true, *after* the character at (pos() - 1). So we already have one
+ // known position around the cursor:
+ pos_type known_pos = boundary() ? pos() - 1 : pos();
+
+ // Whether 'known_pos' is to the left or to the right of the cursor
depends
+ // on whether it is an RTL or LTR character...
+ bool
trunk doesn't compile
Linux, Qt 4.2.1, autotools, g++ 4.1.2: g++ -g -O -o lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o PrinterParams.o Thesaurus.o ./.libs/liblyxcore.a ./.libs/liblyxmathed.a ./.libs/liblyxinsets.a frontends/.libs/liblyxfrontends.a frontends/qt4/.libs/liblyxqt4.a -L/build/buildd/qt4-x11-4.2.1/lib -L/usr/X11R6/lib ./.libs/liblyxgraphics.a support/.libs/liblyxsupport.a ../boost/.libs/liblyxboost.a /usr/lib/libaspell.so /usr/lib/libglib-2.0.so -lQtGui -laudio -lXt -lpng -lSM -lICE -lQtCore -lpthread -lXrender -lXrandr -lXfixes -lXcursor -lXinerama /usr/lib/libfreetype.so -lz -lfontconfig -lXext -lX11 -lm -ldl support/.libs/liblyxsupport.a(SignalSlot.o): In function `SlotImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:37: undefined reference to `vtable for lyx::SlotImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SignalImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:23: undefined reference to `vtable for lyx::SignalImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `lyx::Signal::fire()': /home/dovf/lyx-trunk/src/support/SignalSlot.cpp:38: undefined reference to `lyx::SignalImpl::fire()' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SlotImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:37: undefined reference to `vtable for lyx::SlotImpl' support/.libs/liblyxsupport.a(SignalSlot.o): In function `SignalImpl': /home/dovf/lyx-trunk/src/support/../../src/support/SignalSlotPrivate.h:23: undefined reference to `vtable for lyx::SignalImpl' collect2: ld returned 1 exit status make[3]: *** [lyx] Error 1 make[3]: Leaving directory `/home/dovf/lyx-trunk/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dovf/lyx-trunk/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/dovf/lyx-trunk/src' make: *** [all-recursive] Error 1
Re: visual cursor preference
Pavel Sanda wrote: btw visual bidi box is wrongly initialized now. What do you mean? It should default to false, which it does (unless you've already saved the preferences otherwise)... sorry this reply was to much delayed and i dont remember :) my fault, I took too long to reply... :) Anyhow, I think it's OK. pavel Thanks for your feedback! Dov
Re: visual cursor preference
Pavel Sanda wrote:
Thanks, Pavel! Attached is the patch, after fixing it up as you suggested.
Also, I added tooltips for rtl_support and visual_cursor, but see my
separate post regarding this issue ("LyXRC descriptions / tooltips").
i used the tooltips in the same way.
Good, then that's settled... ;) .
The only thing is that I don't love the visual appearance --- specifically,
the fact that the checkboxes are not all in one line. I don't see any way
to fix this, though, without breaking the layout and placing the widgets
manually, which I imagine is not a very good idea?
why not?
Well, I don't know how cross-platform manual placement would be ---
like, are pixel placements the same on every platform? aren't they
dependent on screen resolution and things like that? I'm just guessing,
I don't really know, this is the first time I'm using Qt Designer...
Anyhow, it's not relevant anymore: I changed the visual design so that
now 'visual_cursor' is controlled by a radio button logical/visual --- I
think it makes more sense that way, and I no longer have the problem
with the checkboxes aligning...
maybe not entirely manually - you can put the other checboxes into
one big groupbox and rtl box remain in line with the box above or even on left,
as you wish.
i'm not sure what exactly the rtl patch should do, but i had some doubts it
belongs
to languge tab - does it have something to do with latex output or its just
editing
issue which belongs to UI tab?
hmmm, I see what you mean. All of the options "Mark foreign languages",
"RTL support" and now "Visual Bidi" are related only to the GUI, and
don't affect the LaTeX output at all... However, the current situation
doesn't seem too strange to me, as these are all "Language" related.
Also, that's where the equivalent options appear in OpenOffice or Word,
for example, so I think that this is where a user would expect to find
them...
btw visual bidi box is wrongly initialized now.
What do you mean? It should default to false, which it does (unless
you've already saved the preferences otherwise)...
pavel
Anyhow, attached is the latest version of this patch (just the part for
adding the preference).
Thanks!
Dov
diff -r b1e35cc03de0 src/LyXRC.cpp
--- a/src/LyXRC.cpp Sat Feb 02 16:48:58 2008 +0100
+++ b/src/LyXRC.cpp Sat Feb 02 23:08:50 2008 +0200
@@ -163,7 +163,8 @@ keyword_item lyxrcTags[] = {
{ "\\user_name", LyXRC::RC_USER_NAME },
{ "\\view_dvi_paper_option", LyXRC::RC_VIEWDVI_PAPEROPTION },
// compatibility with versions older than 1.4.0 only
- { "\\viewer", LyXRC::RC_VIEWER}
+ { "\\viewer", LyXRC::RC_VIEWER},
+ { "\\visual_cursor" ,LyXRC::RC_VISUAL_CURSOR}
};
const int lyxrcCount = sizeof(lyxrcTags) / sizeof(keyword_item);
@@ -247,6 +248,7 @@ void LyXRC::setDefaults() {
isp_use_esc_chars = false;
use_kbmap = false;
rtl_support = true;
+ visual_cursor = false;
auto_number = true;
mark_foreign_language = true;
language_auto_begin = true;
@@ -993,6 +995,11 @@ int LyXRC::read(Lexer & lexrc)
case RC_RTL_SUPPORT:
if (lexrc.next()) {
rtl_support = lexrc.getBool();
+ }
+ break;
+ case RC_VISUAL_CURSOR:
+ if (lexrc.next()) {
+ visual_cursor = lexrc.getBool();
}
break;
case RC_AUTO_NUMBER:
@@ -2144,6 +2151,13 @@ void LyXRC::write(ostream & os, bool ign
}
if (tag != RC_LAST)
break;
+ case RC_VISUAL_CURSOR:
+ if (ignore_system_lyxrc ||
+ visual_cursor != system_lyxrc.visual_cursor) {
+ os << "\\visual_cursor " <<
convert(visual_cursor) << '\n';
+ }
+ if (tag != RC_LAST)
+ break;
case RC_LANGUAGE_PACKAGE:
if (ignore_system_lyxrc ||
language_package != system_lyxrc.language_package) {
@@ -2654,6 +2668,10 @@ string const LyXRC::getDescription(LyXRC
str = _("Select to enable support of right-to-left languages
(e.g. Hebrew, Arabic).");
break;
+ case RC_VISUAL_CURSOR:
+ str = _("Select to have visual bidi cursor movement, unselect
for logical movement.");
+ break;
+
case RC_SCREEN_DPI:
str = _("DPI (dots per inch) of your monitor is auto-detected
by LyX. If that goes wrong, override the setting here.");
break;
diff -r b1e35cc03de0 src/LyXRC.h
--- a/src/LyXRC.h Sat Feb 02 16:48:58 2008 +0100
+++ b/src/LyXRC.h Sat Feb 02 23:08:50 2008 +0200
@@ -145,6 +145,7 @@ public:
RC_USE_SPELL_LIB,
RC_VIEWDVI_PAPEROPTION,
RC_VIEWER,
+
Re: r22854 - /lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: dov
Date: Thu Feb 7 23:46:47 2008
New Revision: 22854
URL: http://www.lyx.org/trac/changeset/22854
Log:
compilation fix
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
Modified: lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp?rev=22854
==
--- lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp Thu Feb 7
23:46:47 2008
@@ -283,7 +283,7 @@
SymbolsList::const_iterator const end = symbols.end();
for (SymbolsList::const_iterator it = symbols.begin(); it !=
end; ++it) {
char_type c = *it;
-QChar::Category cat = QChar::category((uint) c);
+QChar::Category cat = QChar::Category((uint) c);
What's that? It sure is wrong, please revert.
Abdel.
Below is the error I was getting; I don't understand at all what this
is about, so it's quite possible that my fix is wrong --- but then
something else is also wrong, too, and should be fixed.
Qt 4.2.1, Linux:
Oh well you're right, this is new in 4.3:
http://doc.trolltech.com/4.3/qchar.html#category
But the bloody documentation doesn't states so. I'll correct that.
Abdel.
OK, thanks!
Re: r22854 - /lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: dov
Date: Thu Feb 7 23:46:47 2008
New Revision: 22854
URL: http://www.lyx.org/trac/changeset/22854
Log:
compilation fix
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
Modified: lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp?rev=22854
==
--- lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiSymbols.cpp Thu Feb 7
23:46:47 2008
@@ -283,7 +283,7 @@
SymbolsList::const_iterator const end = symbols.end();
for (SymbolsList::const_iterator it = symbols.begin(); it != end;
++it) {
char_type c = *it;
-QChar::Category cat = QChar::category((uint) c);
+QChar::Category cat = QChar::Category((uint) c);
What's that? It sure is wrong, please revert.
Abdel.
Below is the error I was getting; I don't understand at all what this is
about, so it's quite possible that my fix is wrong --- but then
something else is also wrong, too, and should be fixed.
Qt 4.2.1, Linux:
GuiSymbols.cpp: In member function 'void
lyx::frontend::GuiSymbols::updateSymbolList()':
GuiSymbols.cpp:286: error: no matching function for call to
'QChar::category(uint)'
/usr/include/qt4/QtCore/qchar.h:203: note: candidates are:
QChar::Category QChar::category() const
make[5]: *** [GuiSymbols.lo] Error 1
make[5]: Leaving directory `/home/dovf/lyx-trunk/src/frontends/qt4'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/dovf/lyx-trunk/src/frontends/qt4'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/dovf/lyx-trunk/src/frontends'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dovf/lyx-trunk/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/dovf/lyx-trunk/src'
make: *** [all-recursive] Error 1
visual cursor preference
Pavel Sanda wrote:
b. Probably the visual_cursor option should only be enabled if
rtl_support is on --- if rtl_support is false, visual_cursor should
definitely be false, and should be disabled in the GUI (only because it
uses the bidi tables, which will not be computed in the non-rtl_support
case). What's the best way of going about this --- both in terms of the GUI
presentation,
one possibility is the way how Use hyperref support checkbox is done - you get
the disabling for free as qt do it for you.
pavel
Thanks, Pavel! Attached is the patch, after fixing it up as you
suggested. Also, I added tooltips for rtl_support and visual_cursor, but
see my separate post regarding this issue ("LyXRC descriptions / tooltips").
The only thing is that I don't love the visual appearance ---
specifically, the fact that the checkboxes are not all in one line. I
don't see any way to fix this, though, without breaking the layout and
placing the widgets manually, which I imagine is not a very good idea?
But I guess it's fine this way...
Thanks!
Dov
diff -r d6f32a79034d src/LyXRC.cpp
--- a/src/LyXRC.cpp Thu Jan 31 23:50:16 2008 +0100
+++ b/src/LyXRC.cpp Fri Feb 01 15:34:57 2008 +0200
@@ -163,7 +163,8 @@ keyword_item lyxrcTags[] = {
{ "\\user_name", LyXRC::RC_USER_NAME },
{ "\\view_dvi_paper_option", LyXRC::RC_VIEWDVI_PAPEROPTION },
// compatibility with versions older than 1.4.0 only
- { "\\viewer", LyXRC::RC_VIEWER}
+ { "\\viewer", LyXRC::RC_VIEWER},
+ { "\\visual_cursor" ,LyXRC::RC_VISUAL_CURSOR}
};
const int lyxrcCount = sizeof(lyxrcTags) / sizeof(keyword_item);
@@ -247,6 +248,7 @@ void LyXRC::setDefaults() {
isp_use_esc_chars = false;
use_kbmap = false;
rtl_support = true;
+ visual_cursor = false;
auto_number = true;
mark_foreign_language = true;
language_auto_begin = true;
@@ -993,6 +995,11 @@ int LyXRC::read(Lexer & lexrc)
case RC_RTL_SUPPORT:
if (lexrc.next()) {
rtl_support = lexrc.getBool();
+ }
+ break;
+ case RC_VISUAL_CURSOR:
+ if (lexrc.next()) {
+ visual_cursor = lexrc.getBool();
}
break;
case RC_AUTO_NUMBER:
@@ -2144,6 +2151,13 @@ void LyXRC::write(ostream & os, bool ign
}
if (tag != RC_LAST)
break;
+ case RC_VISUAL_CURSOR:
+ if (ignore_system_lyxrc ||
+ visual_cursor != system_lyxrc.visual_cursor) {
+ os << "\\visual_cursor " <<
convert(visual_cursor) << '\n';
+ }
+ if (tag != RC_LAST)
+ break;
case RC_LANGUAGE_PACKAGE:
if (ignore_system_lyxrc ||
language_package != system_lyxrc.language_package) {
@@ -2654,6 +2668,10 @@ string const LyXRC::getDescription(LyXRC
str = _("Select to enable support of right-to-left languages
(e.g. Hebrew, Arabic).");
break;
+ case RC_VISUAL_CURSOR:
+ str = _("Select to have visual bidi cursor movement, unselect
for logical movement.");
+ break;
+
case RC_SCREEN_DPI:
str = _("DPI (dots per inch) of your monitor is auto-detected
by LyX. If that goes wrong, override the setting here.");
break;
diff -r d6f32a79034d src/LyXRC.h
--- a/src/LyXRC.h Thu Jan 31 23:50:16 2008 +0100
+++ b/src/LyXRC.h Fri Feb 01 15:34:57 2008 +0200
@@ -145,6 +145,7 @@ public:
RC_USE_SPELL_LIB,
RC_VIEWDVI_PAPEROPTION,
RC_VIEWER,
+ RC_VISUAL_CURSOR,
RC_LAST
};
@@ -336,6 +337,8 @@ public:
bool language_use_babel;
///
bool rtl_support;
+ /// bidi cursor movement: true = visual, false = logical
+ bool visual_cursor;
///
bool auto_number;
///
diff -r d6f32a79034d src/frontends/qt4/GuiPrefs.cpp
--- a/src/frontends/qt4/GuiPrefs.cppThu Jan 31 23:50:16 2008 +0100
+++ b/src/frontends/qt4/GuiPrefs.cppFri Feb 01 15:34:57 2008 +0200
@@ -1438,7 +1438,9 @@ PrefLanguage::PrefLanguage(QWidget * par
{
setupUi(this);
- connect(rtlCB, SIGNAL(clicked()),
+ connect(rtlGB, SIGNAL(clicked()),
+ this, SIGNAL(changed()));
+ connect(visualCursorCB, SIGNAL(clicked()),
this, SIGNAL(changed()));
connect(markForeignCB, SIGNAL(clicked()),
this, SIGNAL(changed()));
@@ -1476,7 +1478,8 @@ void PrefLanguage::apply(LyXRC & rc) con
void PrefLanguage::apply(LyXRC & rc) const
{
// FIXME: remove rtl_support bool
- rc.rtl_support = rtlCB->isChecked();
+ rc.rtl_support = rtlGB->isChecked();
+
Re: [patch-RFC] visual mode for bidi cursor movement
Abdelrazak Younes wrote:
Dov Feldstern wrote:
b. Probably the visual_cursor option should only be enabled if
rtl_support is on --- if rtl_support is false, visual_cursor should
definitely be false, and should be disabled in the GUI (only because
it uses the bidi tables, which will not be computed in the
non-rtl_support case). What's the best way of going about this ---
both in terms of the GUI presentation, and should there be any further
enforcement in the code, or is it enough if the GUI will take care of it?
I think it should be enough.
OK, good.
2. the actual visual-mode functionality. Currently only Left has been
implemented, Right will more or less mirror it. I hope to get to it in
the next few days, but I figured I might as well get feedback now that
the framework is in place.
Sorry Dov, this is an area I am interested in but I don't have the time
to properly review your patches. Just a stylish issue: I just had a
quick glance at the code and I noticed that you almost never make use of
the "return early" idiom. Just in case, I will explain what this is about:
Bad style:
if (foo) {
return false;
} else {
bar;
return true;
}
Good Style:
if (foo)
return false;
bar;
return true;
Please try to make those corrections before you commit.
Thanks, I'll look into this and see what I can do about it.
Debug printouts --- I'd like to leave them in for future debugging.
How do I add, and make use of, a debug category for them (or is there
an existing category which I should use)?
What about RTL? i.e. instead of 'lyxerr << xxx' you should use
'LYXERR(Debug::RTL, xxx)'
Great, thanks!
Abdel.
LyXRC descriptions / tooltips
Hi! I just noticed that LyXRC::getDescription (in which I made some changes for the visual cursor stuff) is #if-fed out because it's not used. 1. So is there any point in my making changes in it? 2. Should we just get rid of it? 3. Can I add the description as a tooltip, instead? Thanks! Dov
[patch-RFC] visual mode for bidi cursor movement
Hi!
For the past few months I've been working on visual mode for bidi cursor
movement. After a few false starts, I finally feel that I've got an
implementation which is relatively clean. It's not totally finished yet,
but it is well enough along to submit for comments.
Attached are three patches:
1. Adding a preference for visual cursor, which will later be used for
determining how the arrow keys should behave. Nothing very sophisticated
here, but I have a couple of questions:
a. I'm getting the warning
LyXFunc.cpp:2162: warning: enumeration value 'RC_VISUAL_CURSOR' not
handled in switch
and I see the nice comment at the top explaining why we use a
switch. But why is there anything at all? Why do *any* elements need to
be handled? Isn't the function doing absolutely nothing? What are all
the if statements in there about --- they'll never be reached as far as
I can see? What am I missing, and what should I do about my new item?
(BTW, the option seems to be working just fine as-is)
b. Probably the visual_cursor option should only be enabled if
rtl_support is on --- if rtl_support is false, visual_cursor should
definitely be false, and should be disabled in the GUI (only because it
uses the bidi tables, which will not be computed in the non-rtl_support
case). What's the best way of going about this --- both in terms of the
GUI presentation, and should there be any further enforcement in the
code, or is it enough if the GUI will take care of it?
2. the actual visual-mode functionality. Currently only Left has been
implemented, Right will more or less mirror it. I hope to get to it in
the next few days, but I figured I might as well get feedback now that
the framework is in place.
The functionality itself is somewhat complicated (there are lots of edge
cases that need to be dealt with), but given that, I hope the code
should be relatively easy to follow (I added lots of comments, some may
say too many...). I'm purposely not explaining anything about what I did
--- I want to see how well the code+comments speak for themselves.
I don't really expect anyone to test the functionality right now ---
I'll leave that to actual bidi users --- but it would be nice if the
developers could look this over to make sure it makes sense from a
design point-of-view; that it doesn't break normal cursor behavior; and
if you're adventurous, you can try setting this option and seeing how it
works (visual mode should work perfectly fine for plain LTR text; there
are a few cases where I've implemented behavior which is intentionally
different than the current cursor movement --- e.g., boundaries around
insets --- but this will still have to be tweaked).
Debug printouts --- I'd like to leave them in for future debugging. How
do I add, and make use of, a debug category for them (or is there an
existing category which I should use)?
Another question I have --- though it may be premature optimization ---
is this: is there any way for me to avoid recomputing the bidi tables
--- perhaps multiple times --- for every cursor movement? It would seem
to me like these could be cached in the Row object or something; but I
vaguely remember Abdel and/or Stefan getting rid of various bidi_
members that were lying around in various classes? Any ideas here?
3. Adding the functionality to math insets.
Thanks!
Dov
diff -r 2990f91034f0 src/LyXRC.cpp
--- a/src/LyXRC.cpp Tue Nov 13 16:30:29 2007 +0100
+++ b/src/LyXRC.cpp Tue Nov 13 20:12:54 2007 +0200
@@ -176,7 +176,8 @@ keyword_item lyxrcTags[] = {
{ "\\user_name", LyXRC::RC_USER_NAME },
{ "\\view_dvi_paper_option", LyXRC::RC_VIEWDVI_PAPEROPTION },
// compatibility with versions older than 1.4.0 only
- { "\\viewer", LyXRC::RC_VIEWER}
+ { "\\viewer", LyXRC::RC_VIEWER},
+ { "\\visual_cursor" ,LyXRC::RC_VISUAL_CURSOR}
};
const int lyxrcCount = sizeof(lyxrcTags) / sizeof(keyword_item);
@@ -261,6 +262,7 @@ void LyXRC::setDefaults() {
isp_use_esc_chars = false;
use_kbmap = false;
rtl_support = true;
+ visual_cursor = false;
auto_number = true;
mark_foreign_language = true;
language_auto_begin = true;
@@ -989,6 +991,11 @@ int LyXRC::read(Lexer & lexrc)
case RC_RTL_SUPPORT:
if (lexrc.next()) {
rtl_support = lexrc.getBool();
+ }
+ break;
+ case RC_VISUAL_CURSOR:
+ if (lexrc.next()) {
+ visual_cursor = lexrc.getBool();
}
break;
case RC_AUTO_NUMBER:
@@ -2121,6 +2128,13 @@ void LyXRC::write(ostream & os, bool ign
}
if (tag != RC_LAST)
break;
+ case RC_VISUAL_CURSOR:
+ if (ignore_system_lyxrc ||
+ visual_
Re: Keymaps
Pavel Sanda wrote: hi, in http://www.lyx.org/devel/translation.php we have: Keyboard maps allow users to type in various languages. They allow you either to remap single keys, or to map combinations of keys to certain accented or other characters. To make a new kmap, you just have to create a .kmap file. can somebody enlighten me about this? are keymaps still used or this is some leftover from the time there was no propoer keyboard support under X11? don't remember i need it any time i worked with lyx still our FAQ suggest thats needed for typing in various languages. pavel Hi! Yes, keymaps are still used! This comes up every few months, see the last discussion we had about this at http://thread.gmane.org/gmane.editors.lyx.devel/88939 . I still hope to one day get to the possible improvements that I mention in that thread, but it won't be anytime soon... Meanwhile, please don't do anything that will hurt the keymaps! Dov
paragraph alignment (GUI) not working in trunk?
Hi! It looks to me like paragraph alignment is not working in the GUI in the latest builds? Everything appears to be aligned left, regardless of its true alignment. Also in RTL documents, everything is aligned left. Thanks! Dov
Re: trunk doesn't compile
Abdelrazak Younes wrote: Dov Feldstern wrote: make[5]: Entering directory `/home/dovf/lyx-trunk/src/frontends/qt4' make[5]: *** No rule to make target `../ButtonPolicy.cpp', needed by `ButtonPolicy.lo'. Stop. Thanks! try 'autogen.sh' Abdel. 'make distclean' and autogen.sh did it, Thanks!
trunk doesn't compile
make[5]: Entering directory `/home/dovf/lyx-trunk/src/frontends/qt4' make[5]: *** No rule to make target `../ButtonPolicy.cpp', needed by `ButtonPolicy.lo'. Stop. Thanks! Dov
Re: [tentative patch 1.5] towards a working CJK implementation
Jürgen Spitzmüller wrote:
Opinions?
Jürgen
Jurgen --- I wanted to take a look at this, but something really weird
is going on: I'm trying to apply your patch to r21683 (which is what
it's supposedly against), but it's not applying cleanly. And the line
numbers in the patch are off:
in Paragraph.cpp, for example, second hunk, off by 200 lines:
@@ -2163,11 +2164,21 @@
open_font = false;
}
matches this:
http://www.lyx.org/trac/browser/lyx-devel/trunk/src/Paragraph.cpp?rev=21683#L1964
What's going on here?
Dov
Index: src/output_latex.h
===
--- src/output_latex.h (Revision 21683)
+++ src/output_latex.h (Arbeitskopie)
@@ -48,7 +48,7 @@
/// \return (did the encoding change?, number of characters written to \p os)
std::pair switchEncoding(odocstream & os,
BufferParams const & bparams,
-bool moving_arg, Encoding const & oldEnc,
+OutputParams const &, Encoding const & oldEnc,
Encoding const & newEnc);
} // namespace lyx
Index: src/Font.cpp
===
--- src/Font.cpp(Revision 21683)
+++ src/Font.cpp(Arbeitskopie)
@@ -787,7 +787,7 @@
if (language()->encoding()->package() == Encoding::CJK) {
pair const c = switchEncoding(os, bparams,
- runparams.moving_arg, *(runparams.encoding),
+ runparams, *(runparams.encoding),
*(language()->encoding()));
if (c.first) {
open_encoding_ = true;
@@ -948,7 +948,7 @@
// to do correct environment nesting
Encoding const * const ascii =
encodings.getFromLyXName("ascii");
pair const c = switchEncoding(os, bparams,
- runparams.moving_arg, *(runparams.encoding),
+ runparams, *(runparams.encoding),
*ascii);
BOOST_ASSERT(c.first);
count += c.second;
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 21683)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -68,6 +68,7 @@
using support::contains;
using support::prefixIs;
+using support::subst;
using support::suffixIs;
using support::rsplit;
@@ -2163,11 +2164,21 @@
open_font = false;
}
+ // close babel's font environment before opening CJK.
+ if (!running_font.language()->babel().empty() &&
+ font.language()->encoding()->package() == Encoding::CJK) {
+ string end_tag =
subst(lyxrc.language_command_end,
+ "$$lang",
+
running_font.language()->babel());
+ os << from_ascii(end_tag);
+ column += end_tag.length();
+ }
+
// Switch file encoding if necessary
- if (runparams.encoding->package() == Encoding::inputenc &&
- font.language()->encoding()->package() ==
Encoding::inputenc) {
+ if (runparams.encoding->package() != Encoding::none &&
+ font.language()->encoding()->package() != Encoding::none) {
std::pair const enc_switch =
switchEncoding(os, bparams,
- runparams.moving_arg,
*(runparams.encoding),
+ runparams, *(runparams.encoding),
*(font.language()->encoding()));
if (enc_switch.first) {
column += enc_switch.second;
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(Revision 21683)
+++ src/output_latex.cpp(Arbeitskopie)
@@ -43,6 +43,16 @@
namespace {
+
+enum OpenEncoding {
+ none,
+ inputenc,
+ CJK
+ };
+
+static int open_encoding_ = none;
+
+
ParagraphList::const_iterator
TeXEnvironment(Buffer const & buf,
ParagraphList const & paragraphs,
@@ -113,7 +123,8 @@
lyxrc.language_command_end,
"$$lang",
prev_par_language->babel()))
- << '\n';
+ // the '%' is necessary to prevent unwanted
whitespace
+ << '%' << '\n';
texrow.newline();
}
@@ -124,7 +135,8 @@
lyxrc.language_command_begi
Re: Planning for 1.6 alpha 1?
José Matos wrote: And no last minute changes this time. As soon as the alpha is released no more big features should go in. As soon as the first beta is released I will not allow more small features, only bug fixing. Abdel. I would like to hear what others think about this, theirs plans and advices about this release cycle. What are the features that are only half implemented and what is Estimated Time Arrival for code completion. Hi! I'm still hoping to get visual bidi cursor movement in. I hope that I can get it in within the next 6 weeks to two months --- it's mostly just an issue of having the time to spend on it --- and then I'm sure it will require some tweaking once I get some feedback from other users. However, at this point the changes for this should be very localized, and would be in effect only if a "visual cursor" flag is on, so I don't think that this would be risky or disruptive. Dov
Re: 1.6svn module URL in use, but doesn't show up in charstyle menu :-(
Helge Hafting wrote: I opened an old document with yesterdays 1.6svn. Old URL insets were converted to URL charstyle - nice. But I can't make more URL's, except by copy+pasting the existing ones. Edit->charstyle offers "code" and such from "logical markup", URL is not offered. URL is in a separate module (not in logical markup). I'm not sure why this is, though...
trunk doesn't compile
gcc, linux g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I./minizip -Wextra -Wall -g -O -MT FileName.lo -MD -MP -MF .deps/FileName.Tpo -c FileName.cpp -o FileName.o FileName.cpp: In member function 'const std::string lyx::support::DocFileName::mangledFilename(const std::string&) const': FileName.cpp:629: error: 'max' was not declared in this scope Thanks! Dov
Re: [Cvslog] r21407 - in /lyx-devel/trunk/src: Paragraph.cpp insets/In...
Martin Vermeer wrote: On Mon, Nov 05, 2007 at 11:13:34PM +0200, Dov Feldstern wrote: Martin Vermeer wrote: On Mon, 05 Nov 2007 15:49:22 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: Jean-Marc Lasgouttes wrote: Martin Vermeer writes: But I am not sure I understand. Why is forceLTR true for ERT? Just for display purpose? The truth is, it shouldn't be. We're overloading the usage of forceLTR --- a slight misunderstanding between me and Martin. I actually suggested having *two* separate options in the layout: "forceLTR" and "Language". I think that was _my_ original idea... or then I missed your proposal. I dropped it thinking that you only wanted forceLRT, and that that was a good idea ;-) Hmmm... let's start this over again: Normally, if within an RTL paragraph we insert an inset whose contents are LTR, then the language/direction will be switched *inside* the inset; this is taken care of automatically by the inset itself. However, there are some situations in which we won't be able to switch the language/direction once we're inside the inset --- for example, inside a \url, where any language switch commands would just be output verbatim. For this reason, in these cases we need to force the language/direction to LTR *before* opening the inset. That's what forceLTR is used for, and so far it's the *only* case where it's required, I think. A (separate?) issue is that sometimes we want to force the language/encoding to Latin. For example, again, inside \url. The reason that we want to force Latin in this case, is that we don't know how to tell latex to switch the encoding inside the \url --- if we try to use the encoding switch commands, they will be output verbatim. So in fact, we're forced to use only a single encoding --- and that might as well be Latin. In ERT we need to force Latin for a similar, but different, reason: currently, LyX recognizes the encoding (to be used by iconv when generating the latex file) based on the LyX language of the text. However, (I think, but I'm not sure about this) we don't want to allow multiple LyX languages inside ERT, because then the language switching latex commands would go to the ERT text in the latex file. But if we were to allow multiple encodings inside ERT, but not multiple Languages (which would be OK in terms of our requirements, as we agree below) then LyX would be presented with Unicode text inside the ERT which it would not know how to encode when generating the latex file, because there is no language associated with it! Note that we *need* the language information here, because the same characters might be encoded differently depending on the language with which they're associated. And latex is later going to have to know how they were encoded in the latex file. The best solution here might be to somehow make sure that language switch commands are *not* output in ERT, and to then allow true natural languages inside ERT. Doesn't sound very clean, though... So, for better or for worse, at the moment we want to force Latin in these cases --- and this also implies disabling the language switching commands. The question is, do these things (force Latin, forceLTR, disable language switching in the GUI) always go together? I'm not sure, but ATM the only exception I can think of is ERT... Almost always, these properties would be set together. But ERT is a good example where only "Language" should be set. But you need to suppress the \L thingy too... As explained above, forceLTR is used to *add* the \L thingy, which is normally *not* output; so forceLTR does the opposite of what we want in this respect... So now, the question becomes "Why is Language set to latex_language for ERT?" And I believe the answer is: "Yes, just for display purpose". Hmmm. It is to force the language, and thus the encoding, to Latin1. LaTeX needs that; LyX display would be happy with Unicode, but isn't smart enough to convert it to Latin1 without some help (i.e., the language attribute). This is not accurate. It's true for URL, for example, but not for ERT. I agree with Abdel that ideally, in ERT we should allow any encoding the user wants, and it should be up to the user to make sure that any necessary commands are included in the ERT for letting latex know about the encoding changes. Why? Because the point of ERT is to as much as possible let the user do whatever he wants, just as if he had the .tex file and could now touch it up however he likes. Actually I believe you can do that now. Insert your own encoding commands, and insert, e.g., Hebrew byte sequences, by copy/paste from the surrounding text. Yes, they will display wrong, but hey, it's ERT, and it comes out right in print. And if that's what you want to do, it's really easier to
Re: [Cvslog] r21407 - in /lyx-devel/trunk/src: Paragraph.cpp insets/In...
Andre Poenitz wrote:
On Mon, Nov 05, 2007 at 11:13:34PM +0200, Dov Feldstern wrote:
Martin Vermeer wrote:
On Mon, 05 Nov 2007 15:49:22 +0100
Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Jean-Marc Lasgouttes wrote:
Martin Vermeer writes:
But I am not sure I understand. Why is forceLTR true for ERT? Just for
display purpose?
The truth is, it shouldn't be. We're overloading the usage of forceLTR ---
a slight misunderstanding between me and Martin. I actually suggested
having *two* separate options in the layout: "forceLTR" and "Language".
Almost always, these properties would be set together. But ERT is a good
example where only "Language" should be set.
So now, the question becomes "Why is Language set to latex_language for
ERT?"
And I believe the answer is: "Yes, just for display purpose".
Urm... I think we have already too many overloads of everything
according to _what it is_ ('language' / 'ERT') instead of how it
acts ('display LTR without fancy guessing').
Why not have virtual function in Inset for all 'acting'?
I'm not sure how this would work in practice: do you mean that instead
of having "forceRTL", "allowEmpty", "isFreeSpacing"..., to have only a
single method which would output the contents accordingly? Wouldn't that
be a step back from being able to have custom insets which are
configurable just by changing a layout?
[And yes, I know, the asFooInset are a bad precedence...]
Andre'
Re: [Cvslog] r21407 - in /lyx-devel/trunk/src: Paragraph.cpp insets/In...
Martin Vermeer wrote: On Mon, 05 Nov 2007 15:49:22 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: Jean-Marc Lasgouttes wrote: Martin Vermeer writes: But I am not sure I understand. Why is forceLTR true for ERT? Just for display purpose? The truth is, it shouldn't be. We're overloading the usage of forceLTR --- a slight misunderstanding between me and Martin. I actually suggested having *two* separate options in the layout: "forceLTR" and "Language". Almost always, these properties would be set together. But ERT is a good example where only "Language" should be set. So now, the question becomes "Why is Language set to latex_language for ERT?" And I believe the answer is: "Yes, just for display purpose". Hmmm. It is to force the language, and thus the encoding, to Latin1. LaTeX needs that; LyX display would be happy with Unicode, but isn't smart enough to convert it to Latin1 without some help (i.e., the language attribute). This is not accurate. It's true for URL, for example, but not for ERT. I agree with Abdel that ideally, in ERT we should allow any encoding the user wants, and it should be up to the user to make sure that any necessary commands are included in the ERT for letting latex know about the encoding changes. Why? Because the point of ERT is to as much as possible let the user do whatever he wants, just as if he had the .tex file and could now touch it up however he likes. However, in practice it may be a little more complicated. First of all, I think that switching *languages* (as opposed to encodings) should *not* be allowed in ERT. So we have to decouple the language from the encoding; and this would be quite confusing to the user, I think. So until we work out exactly how that should work, I'm OK with having ERT be "force Language latex_language". But the forceERT really should be separated in two, I guess... I would be surprised that LaTeX really need latin1 (why not latin2, after all). Looks like the use of forceLTR for this effect is very weird. Indeed. In addition, one may think also that typing in RTL mode should be allowed within ERT. Abdel. Why? (I honestly cannot think of a situation where this is useful) - Martin Dov
Re: [Cvslog] r21407 - in /lyx-devel/trunk/src: Paragraph.cpp insets/In...
Andre Poenitz wrote:
On Mon, Nov 05, 2007 at 02:16:52PM +0100, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Modified: lyx-devel/trunk/src/Paragraph.cpp
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.cpp?rev=21407
==
--- lyx-devel/trunk/src/Paragraph.cpp (original)
+++ lyx-devel/trunk/src/Paragraph.cpp Sat Nov 3 19:12:52 2007
@@ -725,7 +725,11 @@
if ((inset->lyxCode() == GRAPHICS_CODE
|| inset->lyxCode() == MATH_CODE
-|| inset->lyxCode() == HYPERLINK_CODE)
+|| inset->lyxCode() == HYPERLINK_CODE
+|| (inset->asInsetCollapsable()
+&& inset->asInsetCollapsable()->forceLTR()
+// ERT is an exception, since it doesn't go to output
+&& inset->lyxCode() != ERT_CODE))
&& running_font.isRightToLeft()) {
if (running_font.language()->lang() == "farsi")
os << "\\beginL{}";
What about declaring forceLTR in the Inset class (returning
false by default) and overriding it for graphics, math and hyperlink?
This would simplify this code and avoid the cast to insetcollapsable.
Yes, please *extra sugar added*.
OK, I'll do it. Is this one of those commits which should get a message
"make Andre' happy"? ;)
Andre'
Re: [Cvslog] r21407 - in /lyx-devel/trunk/src: Paragraph.cpp insets/In...
Martin Vermeer wrote:
On Mon, 05 Nov 2007 14:16:52 +0100
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
What about declaring forceLTR in the Inset class (returning
false by default) and overriding it for graphics, math and hyperlink?
This would simplify this code and avoid the cast to insetcollapsable.
Yes... and doesn't consume any storage.
Sorry, I missed this thread. Yes, I like JMarc's suggestion, too. Should
I go ahead with this?
Also, why exactly is ERT a special case?
At least that I can answer ;-) Because we want ERT output to be
"naked". In any locale. No \L stuff or the like around it.
Correct. Otherwise, the ERT is surrounded by \L{}, and does not have any
effect outside the brackets (depending on what exactly the ERT contains).
- Martin
Re: Use of uncrustify to standardize lyx source file format.
Bo Peng wrote: Personally, I don't like code beautifiers that much. There are just too many times when I like to do things which I doubt a code beautifier would preserve (and I want to do it that way nonetheless). E.g: look for "if (// not for ArabTeX" in output_latex.cpp. Uncrustify seems to preserve this. And you call that a good beautifier?! ;) Bo
Re: aussie is really slow
Dov Feldstern wrote: hg clone [--ssh="ssh -C"] ssh://[EMAIL PROTECTED]/~dov/lyx-devel/all that's "ssh:// user _at_ lyx.org /..."
Re: Use of uncrustify to standardize lyx source file format.
Bo Peng wrote: Dear all, It is not always easy to write code that conforms to lyx' coding rules so I have been searching for an open-source code beautifier. I have tried bcpp, greatcode, astyle, indent etc, but none of them is powerful enough. I tried again yesterday and found that uncrustify (http://uncrustify.sourceforge.net/ ) has achieved a useful level. I think it is now possible to standardize lyx source file format in terms of a uncrusitify configuration file so that uncrustify can be applied before patches are generated. I have attached a draft configuration file that is close to our coding rules. More adjustment can be made using universalindentgui (http://universalindent.sourceforge.net/). Once we agree on a standard configuration file, it would be good to apply it to all source files and result in a uniform format. What do you think? Cheers, Bo Personally, I don't like code beautifiers that much. There are just too many times when I like to do things which I doubt a code beautifier would preserve (and I want to do it that way nonetheless). E.g: look for "if (// not for ArabTeX" in output_latex.cpp. Dov
Re: aussie is really slow
Bernhard Roider wrote: and bugzilla does not respond i logged on with ssh and saw that there are many httpd tasks in uninterruptible sleep mode bernhard Hurry up and download your own, personal copy of the lyx repository while aussie is still alive! See http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg126441.html for more details. What has changed since that post is that there is now a single repository containing trunk, 1.5.x, 1.4.x and 1.3.x, updated every half-hour. After installing mercurial, get your copy of the repository like this: hg clone [--ssh="ssh -C"] ssh://[EMAIL PROTECTED]/~dov/lyx-devel/all Where the --ssh argument tells ssh to use compression (and you might have to replace the tilde with an absolute path). The repository is about ~160MB, with a working copy it comes to ~200MB, but additional working directories take up much less space (at least on hardlink-capable systems). I've been using mercurial exclusively in the past couple of months (except for commits back to svn), and am very pleased with it so far. I strongly recommend that you try it out (even if aussie stays alive). Dov
