Documenting the documentation patch submission process.
The References.lyx file invites us to submit corrections to lyx-docs. I am writing an explanation of how to submit a patch/correction to a .lyx file. How does this sound: Patches against .lyx files can be made using diff -u -p oldfile newfile. If this generates irrelevant changes you should open oldfile with your current version of lyx and save it again. This will submit the relevant changes without changing the lyx version. If you wish the patch to change the version of the lyx file, adding the -B option without resaving oldfile should safely eliminate the irrelevant whitespace changes. Also, although the file suggests we submit to lyx-docs, the actual discussion of documentation patches seems to occur on lyx-devel. Should I change this? Also the lyx team does not want to use change tracking for the LyX documentation? -- John C. McCabe-Dansted Masters Student
Documenting the documentation patch submission process.
The References.lyx file invites us to submit corrections to lyx-docs. I am writing an explanation of how to submit a patch/correction to a .lyx file. How does this sound: "Patches against .lyx files can be made using diff -u -p oldfile newfile. If this generates irrelevant changes you should open oldfile with your current version of lyx and save it again. This will submit the relevant changes without changing the lyx version. If you wish the patch to change the version of the lyx file, adding the "-B" option without resaving oldfile should safely eliminate the irrelevant whitespace changes." Also, although the file suggests we submit to lyx-docs, the actual discussion of documentation patches seems to occur on lyx-devel. Should I change this? Also the lyx team does not want to use change tracking for the LyX documentation? -- John C. McCabe-Dansted Masters Student
Is diff -B -c the correct way of submitting patches against .lyx documentation?
I have made a patch against References.lyx. (posted to -doc) This patch includes a suggestion to use diff -B -c to create patches against lyx files. These are the only set of options to diff I found that did not corrupt the whitespace in References.lyx or create hundreds of irrelevant changes due to automatic reformatting of the entire References.lyx file. However, I would like to check: are these the correct flags we should use for diff-ing .lyx files? -- John C. McCabe-Dansted Masters Student
Is "diff -B -c" the correct way of submitting patches against ".lyx" documentation?
I have made a patch against References.lyx. (posted to -doc) This patch includes a suggestion to use "diff -B -c" to create patches against lyx files. These are the only set of options to diff I found that did not corrupt the whitespace in References.lyx or create hundreds of irrelevant changes due to automatic reformatting of the entire References.lyx file. However, I would like to check: are these the correct flags we should use for diff-ing .lyx files? -- John C. McCabe-Dansted Masters Student
Problems trying to implement preview selection.
I thought that it would be very useful to be able to select a piece of text and view the DVI output for (only) that selection. I thought that I might be able to implement it simply by adding the following line to my bind file: \bind F11 copy buffer-new paste buffer-view buffer-close However I came across some problems. Does anyone know how I can overcome them? 1. The bind file does not seem to support multiple commands attached to a single function key. I could use LyX-Server, but is there some way I can make this less inconvenient? 2. Next, buffer-view fails with the Error Cannot export file No information for exporting to I am not sure what this means. Cntl-d works just fine. The documentation for buffer-view appears to be out-of-date. E.g. it claims that buffer-view is in the File menu, but it has been in the view menu for as long as I can remember. 3. When I do a buffer-close, I return to the first buffer rather than the buffer than was open when I did the buffer-new. IMHO buffer-new followed by buffer-close should not change the current buffer. 4. buffer-close prompts me whether I want to discard changes, even if I use undo first so that technically no change has been made. BTW, Reference.lyx does not seem to be available through the help menu. Why is this? if Reference.lyx does not deserve a whole menu item, perhaps we could have a new menuitem Other docs which includes Reference.lyx as a child document. -- John C. McCabe-Dansted Masters Student
Problems trying to implement "preview selection".
I thought that it would be very useful to be able to select a piece of text and view the DVI output for (only) that selection. I thought that I might be able to implement it simply by adding the following line to my bind file: \bind "F11" "copy" "buffer-new" "paste" "buffer-view" "buffer-close" However I came across some problems. Does anyone know how I can overcome them? 1. The bind file does not seem to support multiple commands attached to a single function key. I could use LyX-Server, but is there some way I can make this less inconvenient? 2. Next, buffer-view fails with the Error "Cannot export file No information for exporting to" I am not sure what this means. Cntl-d works just fine. The documentation for buffer-view appears to be out-of-date. E.g. it claims that "buffer-view" is in the File menu, but it has been in the view menu for as long as I can remember. 3. When I do a buffer-close, I return to the first buffer rather than the buffer than was open when I did the "buffer-new". IMHO "buffer-new" followed by "buffer-close" should not change the current buffer. 4. "buffer-close" prompts me whether I want to discard changes, even if I use "undo" first so that technically no change has been made. BTW, Reference.lyx does not seem to be available through the help menu. Why is this? if Reference.lyx does not deserve a whole menu item, perhaps we could have a new menuitem "Other docs" which includes Reference.lyx as a child document. -- John C. McCabe-Dansted Masters Student
New Chktex.C patch.
I have been playing with Chktex.C, and have made a patch against lyx1.4.0pre3/Chktex.C which: - Drops the -v0 flag and uses the less cryptic default (-v1) ChkTeX format. - Uses error titles more informative than 'Chktex warning # n'. - Fixes the bug where filenames containing ':' do not parse correctly. - Removes the USE_BOOST_FORMAT #ifdef, and always uses the std C++ code which is simpler anyway. I understand that due to the feature freeze this code is unlikely to included before 1.4.1. -- John C. McCabe-Dansted Masters Student Chktex.C.patch.gz Description: GNU Zip compressed data
New Chktex.C patch.
I have been playing with Chktex.C, and have made a patch against lyx1.4.0pre3/Chktex.C which: - Drops the -v0 flag and uses the less cryptic default (-v1) ChkTeX format. - Uses error titles more informative than 'Chktex warning # n'. - Fixes the bug where filenames containing ':' do not parse correctly. - Removes the USE_BOOST_FORMAT #ifdef, and always uses the std C++ code which is simpler anyway. I understand that due to the feature freeze this code is unlikely to included before 1.4.1. -- John C. McCabe-Dansted Masters Student Chktex.C.patch.gz Description: GNU Zip compressed data
Math subscript deletion causes crash in 1.3
I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following steps I get a crash. 1. Enter mathmode 2. type: T_E X 3. move the cursor before the E 4. press delete 5. press the up arrow twice. This bug does not occur in 1.4.0pre3. My system: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5 -- John C. McCabe-Dansted Masters Student
Math subscript deletion causes crash in 1.3
I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following steps I get a crash. 1. Enter mathmode 2. type: T_E X 3. move the cursor before the E 4. press delete 5. press the up arrow twice. This bug does not occur in 1.4.0pre3. My system: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5 -- John C. McCabe-Dansted Masters Student
Re: Various change tracking issues
I cannot replicate the following two bugs on lyx-1.4.0pre3-Qt, My system is as follows: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5. What version of LyX and QT (or xforms or...) are you using? Are these MS-Windows only bugs? On Sunday 01 January 2006 01:15, Michael Gerz wrote: SCREEN IS NOT UPDATED AFTER DELETION 1. New doc 2. Enter hello 3. Activate change tracking 4. Place cursor in front of hello 5. Press delete key = The character is deleted internally but the screen is not updated (row signature problem?) SCREEN IS NOT UPDATED AFTER BACKSPACE dito The other bugs occur on my system as well. -- John C. McCabe-Dansted Masters Student
Re: Various change tracking issues
I cannot replicate the following two bugs on lyx-1.4.0pre3-Qt, My system is as follows: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5. What version of LyX and QT (or xforms or...) are you using? Are these MS-Windows only bugs? On Sunday 01 January 2006 01:15, Michael Gerz wrote: > SCREEN IS NOT UPDATED AFTER DELETION > > 1. New doc > 2. Enter "hello" > 3. Activate change tracking > 4. Place cursor in front of "hello" > 5. Press delete key > => The character is deleted internally but the screen is not updated > (row signature problem?) > > SCREEN IS NOT UPDATED AFTER BACKSPACE > > dito The other bugs occur on my system as well. -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - Locale en_NZ could not be set
Please report all issues with these packages to lyx-devel@lists.lyx.org I am using Kubuntu 5.10 with kde 3.5 and QT 3.3.4. I get the following warnings at startup: ... Locale en_NZ could not be set Warning: this system's locale uses Unicode. Language code:en_NZ Setting new locale for Qt:en_NZ Locale en_NZ could not be set ... Although this warning does not seem to be serious, Locale en_NZ could not be set fills STDERR... every character I type prints 5 copies of the line Locale en_NZ could not be set. Simply clicking in the window adds 8 copies of the line Locale en_NZ could not be set. -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - Wheel mouse too slow
Please report all issues with these packages to lyx-devel@lists.lyx.org On my system the wheel mouse moves the screen too slowly to be useful in LyX-1.4.0pre3 (QT). Also, the setting Wheel mouse scroll in LyX: Preferences/Look and feel/User Interface/Scrolling/ does not seem to have any effect on the speed at which the wheel mouse moves the screen. The wheel mouse moved the screen much faster with LyX 1.3.6 (also using the QT ui). My System: kubuntu 5.10 (upgraded from preview) quatro FX 1100 (128MB) AGP 4x KDE 3.5 QT 3.3.4 gcc 4.02 Intel(R) Pentium(R) 4 CPU 1500MHz -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - Wheel mouse too slow
Yes, I can set the global Mouse wheel scrolls by (n) lines in system settings/mouse/advanced. However LyX seems to use a third or less of the global value. When I set 3 lines per wheel mouse click, LyX-1.4.0pre3 moves ~1/2 lines per wheel mouse click. When I set 12 lines per wheel mouse click, LyX-1.4.0pre3 moves ~4 lines per wheel mouse click. Would it be possible to resolve this discrepancy? Also, should I be posting these bugs at bugzilla.lyx.org as well as/instead of here? On Tuesday 27 December 2005 23:12, Georg Baum wrote: On Tuesday 27 December 2005 10:46, Juergen Spitzmueller wrote: John C. McCabe-Dansted wrote: Also, the setting Wheel mouse scroll in LyX: Preferences/Look and feel/User Interface/Scrolling/ does not seem to have any effect on the speed at which the wheel mouse moves the screen. This setting is actually ignored in the qt frontend (we should consider hiding it). Yes. See also http://bugzilla.lyx.org/show_bug.cgi?id=783 Georg -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - LaTeX/chktex error handling problems.
The new latex Errors Error dialog box has some problems: - It always jumps back to and highlights the first error when I go back to the main LyX window, regardless of which error I clicked on in the dialog box. - It makes it hard to edit the text, as it keeps the (first) error selected/highlighted, typing anything deletes the error text. - Cntl-G no longer selects the next error. This may be intentional, but it seems that it would be very handy if Cntl-G brought the latex errors dialog to the foreground and jumped to the next error. -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - "Locale en_NZ could not be set"
> Please report all issues with these packages to > lyx-devel@lists.lyx.org I am using Kubuntu 5.10 with kde 3.5 and QT 3.3.4. I get the following warnings at startup: ... Locale en_NZ could not be set Warning: this system's locale uses Unicode. Language code:en_NZ Setting new locale for Qt:en_NZ Locale en_NZ could not be set ... Although this warning does not seem to be serious, "Locale en_NZ could not be set" fills STDERR... every character I type prints 5 copies of the line "Locale en_NZ could not be set". Simply clicking in the window adds 8 copies of the line "Locale en_NZ could not be set". -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - Wheel mouse too slow
> Please report all issues with these packages to > lyx-devel@lists.lyx.org On my system the wheel mouse moves the screen too slowly to be useful in LyX-1.4.0pre3 (QT). Also, the setting "Wheel mouse scroll" in does not seem to have any effect on the speed at which the wheel mouse moves the screen. The wheel mouse moved the screen much faster with LyX 1.3.6 (also using the QT ui). My System: kubuntu 5.10 (upgraded from preview) quatro FX 1100 (128MB) AGP 4x KDE 3.5 QT 3.3.4 gcc 4.02 Intel(R) Pentium(R) 4 CPU 1500MHz -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - Wheel mouse too slow
Yes, I can set the global "Mouse wheel scrolls by (n) lines" in "system settings/mouse/advanced". However LyX seems to use a third or less of the global value. When I set 3 lines per wheel mouse click, LyX-1.4.0pre3 moves ~1/2 lines per wheel mouse click. When I set 12 lines per wheel mouse click, LyX-1.4.0pre3 moves ~4 lines per wheel mouse click. Would it be possible to resolve this discrepancy? Also, should I be posting these bugs at bugzilla.lyx.org as well as/instead of here? On Tuesday 27 December 2005 23:12, Georg Baum wrote: > On Tuesday 27 December 2005 10:46, Juergen Spitzmueller wrote: > > John C. McCabe-Dansted wrote: > > > Also, the setting "Wheel mouse scroll" in > > Preferences/Look and feel/User Interface/Scrolling/> does not seem to > > > have any effect on the speed at which the wheel mouse moves the screen. > > > > This setting is actually ignored in the qt frontend (we should consider > > hiding it). > > Yes. See also http://bugzilla.lyx.org/show_bug.cgi?id=783 > > > Georg -- John C. McCabe-Dansted Masters Student
Re: [prerelease] LyX 1.4.0pre3 - LaTeX/chktex error handling problems.
The new "latex Errors" Error dialog box has some problems: - It always jumps back to and highlights the first error when I go back to the main LyX window, regardless of which error I clicked on in the dialog box. - It makes it hard to edit the text, as it keeps the (first) error selected/highlighted, typing anything deletes the error text. - Cntl-G no longer selects the next error. This may be intentional, but it seems that it would be very handy if Cntl-G brought the latex errors dialog to the foreground and jumped to the next error. -- John C. McCabe-Dansted Masters Student
New LyX with Grammar Checker Prototype (v0.3)
I have decided to keep my grammar checker small, mostly just a wrapper around ChkTeX and JLanguageTool. Thus my code is likely to remain small enough to be included in LyX. However my prototype is easy to distribute separately from LyX and does not require any (re)compiling or installing. It would probably be best for my code to remain separate for the time being. I have changed this prototype to use the chktex error interface. I may need to use IPC; I know LyX-server uses named pipes. Out of TCP sockets, unnamed sockets, named pipes and unnamed pipes which are portable across the architectures LyX supports? Although this is a prototype (written in Perl) it provides full featured grammar checking with probabilistic grammar parsing thanks to JLanguageTool. It seems to be ready for real world use; it does not generate errors if it is too stupid to understand your grammar. Instead it will report an error if your text matches one of ~400 rules describing common errors. It is relatively easy for a technical person to disable or customize each rule. HOW TO USE: Unpack lyx-gc (11KB download) http://dansted.org/lyx-gc-0.3.tar.bz2 and run lyx-gc-0.3/lyx-gc. Reconfigure if the Edit-Check Tex option is not available. Now, when you activate the Edit-Check Tex option, lyx-gc will check your document for grammatical errors. If no grammar errors are found, the Check Tex option will check your document for tex errors as normal. For more information, see the README. -- John C. McCabe-Dansted Masters Student
New "LyX with Grammar Checker" Prototype (v0.3)
I have decided to keep my grammar checker small, mostly just a wrapper around ChkTeX and JLanguageTool. Thus my code is likely to remain small enough to be included in LyX. However my prototype is easy to distribute separately from LyX and does not require any (re)compiling or installing. It would probably be best for my code to remain separate for the time being. I have changed this prototype to use the chktex error interface. I may need to use IPC; I know LyX-server uses named pipes. Out of TCP sockets, unnamed sockets, named pipes and unnamed pipes which are portable across the architectures LyX supports? Although this is a prototype (written in Perl) it provides full featured grammar checking with probabilistic grammar parsing thanks to JLanguageTool. It seems to be ready for real world use; it does not generate errors if it is too stupid to understand your grammar. Instead it will report an error if your text matches one of ~400 rules describing common errors. It is relatively easy for a technical person to disable or customize each rule. HOW TO USE: Unpack lyx-gc (11KB download) http://dansted.org/lyx-gc-0.3.tar.bz2 and run lyx-gc-0.3/lyx-gc. Reconfigure if the Edit->Check Tex option is not available. Now, when you activate the Edit->Check Tex option, lyx-gc will check your document for grammatical errors. If no grammar errors are found, the Check Tex option will check your document for tex errors as normal. For more information, see the README. -- John C. McCabe-Dansted Masters Student
Re: Grammar Checker for LyX.
On Wednesday 23 November 2005 23:51, Angus Leeming wrote: Asger Ottar Alstrup wrote: John C. McCabe-Dansted wrote: I am working on a grammar checker for LyX. It outputs the errors to LaTeX .log format so it can integrate itself into LyX without need for any modification to existing LyX binary. Hi, John. This is really nice and at 722 lines long (including copious commentary) is really small. That's great because it means that it'll be maintainable in the future. Thanks, though I expect it will be 1500+ lines of code and 50+ KB of data files for the English language when feature complete. I'd second Asger's suggestion that you investigate chktex. Most of the hooks are there already to able you to get on-screen notification of grammar problems, essentially for free. Yes, at this point I think I should write it as chktex v2, and ignore anything LyX specific for the meanwhile, particularly while there is feature freeze. Ultimately I would want to add hooks to LyX to support new features like This is not a grammatical error, because..., but there is no point in adding these hooks until my code is robust. The final version will be at least 50KB uncompressed including data files for the English language. If I don't try to integrate the core into LyX I won't have to worry about keeping it small enough to be a patch. Interested? Yes. Asger's suggestion that you rewrite this thing in C++ is also worthy of serious consideration. We know C++. We don't know Perl. That means If I was aiming it as a replacement for chktex, I may want to write it as ANSI C (as with chktex), but then it probably wouldn't be the LyX programmers I would be asking to maintain the code. that you'll get little or no help in maintaining your creation ATM, for purely practical reasons. Given that the heart of your beast is a bunch of regexes, you should have no problems moving to C++. (Boost.Regex which we use already provides a drop in replacement for your Perl regexes.) I had a look at Boost.Regex. I am not sure if I need or want regexes in the final release anyway. -- John C. McCabe-Dansted Masters Student
Re: Grammar Checker for LyX.
On Wednesday 23 November 2005 23:51, Angus Leeming wrote: > Asger Ottar Alstrup wrote: > > John C. McCabe-Dansted wrote: > >> I am working on a grammar checker for LyX. It outputs the errors to > >> LaTeX .log format so it can integrate itself into LyX without need > >> for any modification to existing LyX binary. > > Hi, John. This is really nice and at 722 lines long (including copious > commentary) is really small. That's great because it means that it'll > be maintainable in the future. Thanks, though I expect it will be 1500+ lines of code and 50+ KB of data files for the English language when feature complete. > I'd second Asger's suggestion that you investigate chktex. Most of the > hooks are there already to able you to get on-screen notification of > grammar problems, essentially for free. Yes, at this point I think I should write it as chktex v2, and ignore anything LyX specific for the meanwhile, particularly while there is feature freeze. Ultimately I would want to add hooks to LyX to support new features like "This is not a grammatical error, because...", but there is no point in adding these hooks until my code is robust. The final version will be at least 50KB uncompressed including data files for the English language. If I don't try to integrate the core into LyX I won't have to worry about keeping it small enough to be a patch. > Interested? Yes. > Asger's suggestion that you rewrite this thing in C++ is also worthy > of serious consideration. We know C++. We don't know Perl. That means If I was aiming it as a replacement for chktex, I may want to write it as ANSI C (as with chktex), but then it probably wouldn't be the LyX programmers I would be asking to maintain the code. > that you'll get little or no help in maintaining your creation ATM, > for purely practical reasons. Given that the heart of your beast is a > bunch of regexes, you should have no problems moving to C++. > (Boost.Regex which we use already provides a drop in replacement for > your Perl regexes.) I had a look at Boost.Regex. I am not sure if I need or want regexes in the final release anyway. -- John C. McCabe-Dansted Masters Student
Grammar Checker for LyX.
I am working on a grammar checker for LyX. It outputs the errors to LaTeX .log format so it can integrate itself into LyX without need for any modification to existing LyX binary. Three questions. First, I understand that to tell LyX 1.3.6 that a converter generates errors in a LaTeX .log format you have to set the Extra Flag to be latex. However then it seems to ignore the converter option, and run latex instead. Why is this? Secondly, I am currently getting around this problem by naming my grammar checker latex and then getting it to call the real LaTeX when it is done. Is there a better way? Thirdly, is there any interest in including this in an official release (it is under 50KB), and if so is there some procedure I should follow? I have placed an experimental-yet-functional version up at: http://dansted.org/latexgc.tar.gz -- John C. McCabe-Dansted Masters Student
Grammar Checker for LyX.
I am working on a grammar checker for LyX. It outputs the errors to LaTeX .log format so it can integrate itself into LyX without need for any modification to existing LyX binary. Three questions. First, I understand that to tell LyX 1.3.6 that a converter generates errors in a LaTeX .log format you have to set the "Extra Flag" to be "latex". However then it seems to ignore the converter option, and run latex instead. Why is this? Secondly, I am currently getting around this problem by naming my grammar checker "latex" and then getting it to call the real LaTeX when it is done. Is there a better way? Thirdly, is there any interest in including this in an official release (it is under 50KB), and if so is there some procedure I should follow? I have placed an experimental-yet-functional version up at: http://dansted.org/latexgc.tar.gz -- John C. McCabe-Dansted Masters Student
