changing default output of Hebrew docs to pdflatex
I can now compile all Hebrew documents with both ps2pdf and pdflatex. When I compile with luatex, I get the following error: << To avoid this error message, run TeX--XeT or e-TeX engine instead of regular TeX. ! Right-to-Left Support Error: use TeX--XeT or e-TeX engine. l.77 engine} >> I will set pdflatex as the default output format, unless someone objects. Scott
Re: trac 'easyfix' tag
On 05/25/2013 01:58 AM, Pavel Sanda wrote: Given the fact that I can't remember single case that some newcomer started by 'easyfix' bugs during last x years (heh, how many of easyfixes have been targeted by the students applying for GSOC?) I think that this whole discussion is purely academic and not worth of nitpicking. I'll disagree slightly. I think it actually would be worthwhile to mark bugs that would be a good place for people to start. We do sometimes get people asking about this kind of thing on the list. True, they usually disappear, but perhaps that is because we aren't seen as very responsive. Richard
Re: trac 'easyfix' tag
Scott Kostyshak wrote: > I propose the following description (and perhaps a new keyword name?): > > easyfix: fixing this bug is achievable for a newcommer to LyX > development and would be a good learning experience. Feel free to change it. > Two questions I have are: > > How confident should I be that criterion (a) is satisfied? I would > only be 100% sure that a ticket is easy to fix if I actually fix it. I > plan to be a little risky in assigning this tag and hope that other > developers will remove it if I do so mistakenly or that a newcommer > will still learn if they try to tackle a bug that is actually too > complicated. > > Should current developers be discouraged from working on 'easyfix' > tickets? In my opinion, no. Otherwise, one has to think very carefully > before assigning the tag. If developers wants to work on a ticket for > any reason, they should be unconstrained. I don't think current developers care much about this keyword, it was meant for newbies. Again, feel free to add keywords for the bugs which would be straightforward for you. > Any thoughts? Given the fact that I can't remember single case that some newcomer started by 'easyfix' bugs during last x years (heh, how many of easyfixes have been targeted by the students applying for GSOC?) I think that this whole discussion is purely academic and not worth of nitpicking. Pavel
trac 'easyfix' tag
During GSoC applications and even after, there was demand for small bugs to work on that was not met. I would like to start marking tickets as 'easyfix' tags to indicate that such tickets would be a good learning process for someone that is not very familiar with LyX's code. I'm interested in knowing (1) how others think that the above demand for easy bugs should be addressed and (2) how the 'easyfix' tag should be used. Here, I'm suggesting that (2) be the solution to (1). My thoughts are below. Currently the keyword's description [1] is: easyfix: this bug is easy to fix First, let me argue for why I think the current description/use of the keyword is not very useful. Why is it helpful to know if a bug is easy to fix? Perhaps if developers were looking for the best way to spend time, they could look for bugs with a high ratio of priority to easyfix or milestone to easyfix. That would give the best bang for the buck. But I don't think that's how developers think when searching for bugs to work on . I propose the following description (and perhaps a new keyword name?): easyfix: fixing this bug is achievable for a newcommer to LyX development and would be a good learning experience. Thus, boring or repetitive work would not fall under this category (as opposed to the current description of easyfix). What is the ideal ticket to be marked as an easyfix? (a) The fix should be easy in theory. Easy does not necessarily mean it should not take much time. It means that it's clear what needs to be done. (b) One that is not high priority. These should probably be fixed by current developers. (c) It should be a good learning exercise. It should teach a newcommer how to do something, such as introduce a new (but trivial) LFUN, or maybe implement a validation function. (Anything that will likely be useful in the future.) Two questions I have are: How confident should I be that criterion (a) is satisfied? I would only be 100% sure that a ticket is easy to fix if I actually fix it. I plan to be a little risky in assigning this tag and hope that other developers will remove it if I do so mistakenly or that a newcommer will still learn if they try to tackle a bug that is actually too complicated. Should current developers be discouraged from working on 'easyfix' tickets? In my opinion, no. Otherwise, one has to think very carefully before assigning the tag. If developers wants to work on a ticket for any reason, they should be unconstrained. Any thoughts? Scott
Re: a bind works on Ubuntu but not on Windows
On Thu, Mar 28, 2013 at 1:57 AM, Scott Kostyshak wrote: > On Fri, Mar 22, 2013 at 3:03 PM, Scott Kostyshak wrote: >> On Wed, Jan 9, 2013 at 10:25 PM, Scott Kostyshak wrote: >>> On Thu, Oct 11, 2012 at 5:06 PM, Jean-Marc Lasgouttes >>> wrote: Le 11/10/12 12:50, Scott Kostyshak a écrit : > Regarding ticket http://www.lyx.org/trac/ticket/8364, > > the following bind does not work for Michael (on Windows?): > \bind "S-C-parenleft" "math-delim ( )" > > It does work for me on Ubuntu. > > Michael found that the following does work > \bind "S-C-9" "math-delim ( )" > > but JMarc pointed out that this is not the right solution because it's > only for US keyboards and suggested > \bind "~S-C-parenleft" "math-delim ( )" > > This also works for me on Ubuntu, but not for Michael. > > Why do the two parenleft binds work on Ubuntu and not on Windows? I did not have time to look but the first thing to chck of course is whether the keyboard layouts are the same. We do not want to use S-C-9 anyway because it would not work on a non-US keyboard. But their may be a specific windows problem indeed. JMarc >>> >>> Any ideas on this? I'm not sure whether to try to go ahead with the >>> patch without that particular change or to wait until someone who >>> knows about bindings can look into this. >> >> Assuming no one has time to look into this Windows-specific behavior, >> I propose the following, which would close #8364 (and I would open a >> separate ticket just for the particular bind issue): >> >> Can we add the following Windows-centric and US-keyboard-centric lines >> to sciword.bind? >> >> \bind "S-C-9" "math-delim ( )" >> \bind "S-C-0" "math-delim ( )" >> >> My argument is that already in the bind file we have >> >> \bind "C-9" "math-delim ( )" >> \bind "C-0" "math-delim ( )" >> >> so the bind file is already US-keyboard-centric in this sense. Also I >> don't think there's much of a cost to adding the lines because there >> is no other binding for S-C-9 or S-C-0. For example, on a French >> keyboard, if I understand correctly, S-C-9 would be like doing C-9 or >> S-C-ç, which is not intuitive but it does not seem incorrect to me >> because we are not overriding any other command. >> >> Any thoughts? > > Does anyone have an objection? If not, I will send the sciword bind > file out for testing to see if I get positive feedback. > > Scott I attached the patch to #8364. Please let me know if anyone has comments. Scott
Re: lyx2lyx conversion routines (was: Re: #8588: add Sweave Chunk inset)
On 05/24/2013 05:55 PM, Liviu Andronic wrote: On Thu, May 23, 2013 at 10:11 PM, Richard Heck wrote: I have posted a lyx2lyx conversion routine to the bug report http://www.lyx.org/trac/ticket/8588#comment:23 Please test and let me know if there are problems. If so, please post the Richard, I'm afraid I'm having problems with applying the patches. Using latest trunk I tried all combinations between patch < %f to patch -p3 < %f but I keep getting skipped patches and rejected hunks. How should I apply the patches? Try: git apply FILE.patch That should work. The patches are based off 01add2d52f, so you could do: git checkout -b Chunks 01add2d52f first, if you want. rh
Re: lyx2lyx conversion routines (was: Re: #8588: add Sweave Chunk inset)
On Thu, May 23, 2013 at 10:11 PM, Richard Heck wrote:
>
> I have posted a lyx2lyx conversion routine to the bug report
> http://www.lyx.org/trac/ticket/8588#comment:23
> Please test and let me know if there are problems. If so, please post the
>
Richard, I'm afraid I'm having problems with applying the patches.
Using latest trunk I tried all combinations between
patch < %f
to
patch -p3 < %f
but I keep getting skipped patches and rejected hunks. How should I
apply the patches?
Thanks,
Liviu
> file causing the problems here, stripped down to be as minimal as possible.
>
> I have not yet written the REversion routine. I'll do that after this is
> right.
>
> Richard
>
>
>
> On 05/23/2013 12:25 PM, Liviu Andronic wrote:
>
> On Thu, May 23, 2013 at 6:14 PM, Richard Heck wrote:
>
> So we take what's in the first Chunk paragraph, strip off the << and >>=
> delimiters, and put that into the argument of the Chunk inset.
>
> Yes. Often after stripping the contents will be an empty string ("").
> Then I think there is no need to include the Chunk argument inset.
>
>
> Then we take
> everything up to the last Chunk paragraph, put that as a sequence of
> paragraphs into the Chunk inset, and discard the last Chunk paragraph. Yes?
>
> That is my understanding, too. I attach a new pair of examples that
> contain multiple lines of code. Old Style version:
> \begin_layout Chunk
> <>=
> \end_layout
>
> \begin_layout Chunk
> 2+2
> \end_layout
>
> \begin_layout Chunk
> 3+3
> \end_layout
>
> \begin_layout Chunk
> @
> \end_layout
>
>
> New Inset version:
> \begin_layout Standard
> \begin_inset Flex Chunk
> status open
>
> \begin_layout Plain Layout
>
> \begin_inset Argument 1
> status open
>
> \begin_layout Plain Layout
> TEST
> \end_layout
>
> \end_inset
>
> 2+2
> \end_layout
>
> \begin_layout Plain Layout
>
> 3+3
> \end_layout
>
> \end_inset
>
>
> \end_layout
>
>
> Liviu
>
>
> Richard
>
>
>
> On 05/23/2013 12:11 PM, Liviu Andronic wrote:
>
> Richard,
> I'm sorry but I gave you an imperfect equivalent for the inset
> example. The attached knitr-new.lyx is better, and also uses the
> argument inset. The relevant bits are:
>
> \begin_layout Standard
> \begin_inset Flex Chunk
> status open
>
> \begin_layout Plain Layout
>
> \begin_inset Argument 1
> status open
>
> \begin_layout Plain Layout
>
> TEST
> \end_layout
>
> \end_inset
>
> 2+2
> \end_layout
>
> \end_inset
>
>
> \end_layout
>
>
> The code below is the old-style equivalent of the above.
>
>
> On Thu, May 23, 2013 at 5:17 PM, Richard Heck wrote:
>
> \begin_layout Chunk
> <>=
> \end_layout
>
> \begin_layout Chunk
> 2+2
> \end_layout
>
> \begin_layout Chunk
> @
> \end_layout
>
> Is it correct, then, to remove the first and last chunks, and leave only
> the
> middle bit?
>
> I do not have a good understanding of the LyX file format. Maybe JMarc
> knows better?
>
> Liviu
>
>
>
>
--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
Re: Mac-style paragraph movement
Le 23/05/13 23:51, Stephan Witt a écrit : It jumps to the end of this paragraph here. I've tried the mac-cursor4.diff patch. I tested it with the Users Guide and the Beamer Doc. I'm fine with it. Let's apply it, then. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 15:40, Vincent van Ravesteijn a écrit : Did you reset your local empty-length branch to 85e391e43 ? (That's your last commit before hell broke loose) OK, I think I pushed it correctly now. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On 05/24/2013 09:07 AM, Vincent van Ravesteijn wrote: By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. Yes, in that case, it would seem merging into master makes the most sense. # Now rebase against master git rebase master You could just as well had rebased to master in the previous step (avoiding the problem I stated above). It's somewhat easier, for me, at least, to handle these two steps separately: (i) Deal with cleaning up the history locally; (ii) Rebase (or merge), and fix the conflicts. Mixing the two tasks gets confusing. Richard
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Did you reset your local empty-length branch to 85e391e43 ? (That's your last commit before hell broke loose) Vincent On Fri, May 24, 2013 at 3:18 PM, Jean-Marc Lasgouttes wrote: > Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : > > I've reset the branch now to the last commit you made. All commits from >> master were somehow rebased or cherry-picked on top of the feature branch. >> >> You can merge it into master by: >> >>git checkout master >>git merge empty-length -m "Please supply a commit message instead of >> the default" >> > > I get lots of errors like: > > Auto-merging src/tests/test_layout > CONFLICT (add/add): Merge conflict in src/tests/test_layout > Auto-merging src/insets/InsetBox.cpp > Auto-merging src/frontends/qt4/qt_helpers.h > Auto-merging src/frontends/qt4/qt_helpers.**cpp > Auto-merging src/TextClass.cpp > CONFLICT (content): Merge conflict in src/TextClass.cpp > > These should not happen. > > JMarc >
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" I get lots of errors like: Auto-merging src/tests/test_layout CONFLICT (add/add): Merge conflict in src/tests/test_layout Auto-merging src/insets/InsetBox.cpp Auto-merging src/frontends/qt4/qt_helpers.h Auto-merging src/frontends/qt4/qt_helpers.cpp Auto-merging src/TextClass.cpp CONFLICT (content): Merge conflict in src/TextClass.cpp These should not happen. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On Fri, May 24, 2013 at 3:00 PM, Richard Heck wrote: > > My procedure for doing this kind of thing is similar but avoids the last > merge step > It is the question whether we want to have the merge commit, or we don't want it. If a feature consists of 20 small changes, it might be more useful to have a single merge commit on the master branch instead of 20 to avoid cluttering. > git checkout mybranch > # Make sure the history here is the way I want it to be, e.g.: > git log > git rebase -i HEAD~5 > That's `git merge-base master`. By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. > # Now rebase against master > git rebase master > You could just as well had rebased to master in the previous step (avoiding the problem I stated above). Vincent
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
My procedure for doing this kind of thing is similar but avoids the last merge step: git checkout mybranch # Make sure the history here is the way I want it to be, e.g.: git log git rebase -i HEAD~5 # Now rebase against master git rebase master # We'll push this branch to master using a custom command to do it git pushto master The script that implements pushto is attached. It has a few nice features. (i) It first shows you what commits will be pushed and then asks you if you want to proceed. (ii) It then pushes the commits one by one, as a way of dealing with the fact that our email script currently sends only one bulk email for the whole push. Activate the pushto script by putting it in your path and doing: git config --global alias.pushto=!git-pushto Richard #!/bin/bash REMOTE="origin"; RBRANCH="$1"; BRANCH=$(git br | grep '^\*' | cut -d' ' -f2); if [ -z "$RBRANCH" ]; then RBRANCH="$BRANCH"; if [ "$RBRANCH" != "master" -a "$RBRANCH" != "2.0.x" ]; then echo "Do you want to push to $RBRANCH?"; select answer in Yes No; do if [ "$answer" != "Yes" ]; then echo "Aborting push."; exit 1; break; else break; fi done fi fi if ! git push -n $REMOTE $BRANCH:$RBRANCH >/dev/null 2>&1; then echo "Branch is not up to date!"; exit 1; fi LOGS=$(git push -n $REMOTE $BRANCH:$RBRANCH 2>&1 | tail -n 1 | grep -v "Everything" | sed -e 's/^ *//' -e 's/ .*//'); if [ -z "$LOGS" ]; then echo "Everything up to date"; exit 0; fi echo $LOGS git log $LOGS; #Do we want to go ahead? echo echo "Do you want to push these commits to $RBRANCH?" select answer in Yes No; do if [ "$answer" != "Yes" ]; then exit 0; break; else break; fi done COMMITS=""; for i in `git log $LOGS | grep -P '^commit' | cut -d' ' -f2`; do COMMITS="$i $COMMITS"; done for i in $COMMITS; do git push $REMOTE $i:$RBRANCH; done
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. Thanks, I am not sure what I did wrong. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" Will do. or you can rebase onto master and fix the history: git checkout empty-length git rebase master -i "Remove" is not remove, right? Shouldn't I use squash instead? git checkout master git merge empty-length (this will fast-forward master) I understand this one; but the following ones made my head explode. So, what should I do about the kill-gettext branch now? JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On Fri, May 24, 2013 at 10:46 AM, Jean-Marc Lasgouttes wrote: > Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit : > > The branch, empty-length, has been updated. >> >> - Log --**--** >> - >> >> commit 85e391e43a6d7188683dacae729475**e77597415d >> Author: Jean-Marc Lasgouttes >> Date: Wed May 22 15:50:44 2013 +0200 >> >> Latest changes from Uwe for tex2lyx and lyx2lyx >> >> I amended Uwe patches a bit, since empty width should be output as >>width "" >> in the LyX file. >> > > > Could someone (Vincent?) take a look at this branch and tell me why the > commits seem to be in random order wrt dates? What did I do wrong? Can I > merge it as it is? > > JMarc > I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" or you can rebase onto master and fix the history: git checkout empty-length git rebase master -i git checkout master git merge empty-length (this will fast-forward master) or you can rebase onto master and fix the history and make a merge commit: git checkout empty-length git rebase master -i git checkout master git merge empty-length --commit -m "Message" (this will create a merge commit) or you can first fix history and then merge: git checkout empty-length git rebase -i `git merge-base master empty-length` git checkout master git merge empty-length -m "Please supply a commit message instead of the default" (this makes a merge commit) Vincent
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit : The branch, empty-length, has been updated. - Log - commit 85e391e43a6d7188683dacae729475e77597415d Author: Jean-Marc Lasgouttes Date: Wed May 22 15:50:44 2013 +0200 Latest changes from Uwe for tex2lyx and lyx2lyx I amended Uwe patches a bit, since empty width should be output as width "" in the LyX file. Could someone (Vincent?) take a look at this branch and tell me why the commits seem to be in random order wrt dates? What did I do wrong? Can I merge it as it is? JMarc
Re: LyX 2.0.6 Source
Jean-Pierre Chrétien free.fr> writes: > > Compiles fine on Debian squeeze, , happy that you could commit patch > correcting bug #8648. > > Configuration [] > C++ Compiler: g++ (4.4.5) [] > Qt 4 Frontend: > Qt 4 version: 4.6.3 [] I've upgraded from squeeze to wheezy, lyx-2.0.6 still compiles fine with C++ Compiler: g++ (4.7) [] Qt 4 Frontend: Qt 4 version: 4.8.2 -- Jean-Pierre
