Re: Feedback on info insets
On Tue, Aug 7, 2018 at 10:29 AM, Scott Kostyshak wrote: > Thanks to Jürgen for improving these insets and the interface to them. I > just tested the feature and am impressed with all of the possibilities > available. Very cool! > I agree, this is quite slick. A comment/question for consideration: with this improved interface to environment information, can/should there be a "standard debugging information inset" that contains the information typically useful for...debugging? This may be somewhat intrusive (e.g., querying OS version, display information, etc.). However, it might provide a one-click solution for folks reporting problems/bugs to gather and consistently present environment information useful to categorizing and/or resolving bugs. Perhaps instead of making something to insert, an otherwise "vanilla" template could be constructed with this information laid out that a user could construct a MWE out of to demonstrate the unexpected/aberrant behavior? In any case, thanks for your continued hard work on new and interesting features. - Joel
Re: Feedback on info insets
On 08/07/2018 11:30 PM, Richard Kimberly Heck wrote: > On 08/07/2018 12:29 PM, Scott Kostyshak wrote: >> Thanks to Jürgen for improving these insets and the interface to them. I >> just tested the feature and am impressed with all of the possibilities >> available. Very cool! >> >> To Jürgen: I don't expect you to fix these. You've already done so much >> work on this. I just provide this feedback since I am trying out these >> insets for the first time (I'm on master at 781b1030). I can make trac >> tickets if anyone suggests. >> >> 1. If I insert Field > User Name, then change the name in Preferences >> and click "OK" or "Apply", the inset is not updated in the LyX display >> until I do something like . I think this behavior is more >> general than this specific inset (e.g., I remember a similar issue with >> Instant Preview), but since I noticed it here I report it here. > Missing updateBuffer call. We need to add forceBufferUpdate somewhere in > the dispatch that changes the preferences. Did this. Riki
Re: The patch for the Dropbox + Windows locking issue
On 08/07/2018 07:13 PM, Scott Kostyshak wrote: > The following issue seems to affect a lot of users: > > https://www.lyx.org/trac/ticket/10091 > > Riki posted a patch (see comment 42), but from what I can tell it has > not had any testing on Windows since no one who can reproduce the issue > can also compile on Windows. > > It seems that the risk to including the patch is that it does not fix > the issue and actually makes the issue worse by introducing a 5 second > delay. However, perhaps that risk is worth it. > > Riki, can you provide the commands that I need to make a test binary for > Windows users? This way I can try to save you some time from creating it > yourself since you have already done so much. Well, actually it might > take you more time to explain to me how to do it, but I would volunteer > to make test binaries for Windows users in the future. Yes, I am thinking it might take more time to explain it. The code is currenty in a branch in my developers' repo. I'll put it into 2.3.x at some point soon, and then others will be able to use it. Riki
Re: Feedback on info insets
On 08/07/2018 12:29 PM, Scott Kostyshak wrote: > Thanks to Jürgen for improving these insets and the interface to them. I > just tested the feature and am impressed with all of the possibilities > available. Very cool! > > To Jürgen: I don't expect you to fix these. You've already done so much > work on this. I just provide this feedback since I am trying out these > insets for the first time (I'm on master at 781b1030). I can make trac > tickets if anyone suggests. > > 1. If I insert Field > User Name, then change the name in Preferences > and click "OK" or "Apply", the inset is not updated in the LyX display > until I do something like . I think this behavior is more > general than this specific inset (e.g., I remember a similar issue with > Instant Preview), but since I noticed it here I report it here. Missing updateBuffer call. We need to add forceBufferUpdate somewhere in the dispatch that changes the preferences. Riki
Re: The patch for the Dropbox + Windows locking issue
The following issue seems to affect a lot of users: https://www.lyx.org/trac/ticket/10091 racoon, Klaus, and Joon, can you still reproduce the issue and would you be willing to test the binary that includes a patch for this annoying issue? Hi - Of course I'm happy to test it! But I recently updated to LyX 2.3, and one thing I noticed is that on top of the writing error (I just reproduced this): --- LyX: Write failure --- Cannot move saved file to: C:/Users/joon/Dropbox (Personal)/lyx. But the file has successfully been saved as: C:/Users/joon/Dropbox (Personal)/...-O12160.lyx. --- I also started to get "The file ~\Dropbox (Personal)\lyx. changed on disk [Reload] [Ignore]" messages as well. It feels like this new messages shows up more frequently than the error, and I think it may be actually more dangerous since I'm not sure which version is the newer one and I'm afraid that I may lose my changes. Best Regards, Joon
Re: [LyX/master] Fix LyX server on Windows
On 08/07/2018 12:05 PM, Enrico Forestieri wrote: > commit cf5f2661dc0a902e541704172ab369ba3e5a54d6 > Author: Enrico Forestieri > Date: Tue Aug 7 17:56:07 2018 +0200 > > Fix LyX server on Windows > > On some recent Windows versions, GetLastError() may also return > NO_ERROR instead of ERROR_IO_PENDING during an overlapped write > operation to a pipe. This was confusing the state machine in > Server.cpp so that replies to commands were scheduled but were > never actually output. If this is needed on stable, which I assume it is, then please go ahead. Riki
The patch for the Dropbox + Windows locking issue
The following issue seems to affect a lot of users: https://www.lyx.org/trac/ticket/10091 Riki posted a patch (see comment 42), but from what I can tell it has not had any testing on Windows since no one who can reproduce the issue can also compile on Windows. It seems that the risk to including the patch is that it does not fix the issue and actually makes the issue worse by introducing a 5 second delay. However, perhaps that risk is worth it. Riki, can you provide the commands that I need to make a test binary for Windows users? This way I can try to save you some time from creating it yourself since you have already done so much. Well, actually it might take you more time to explain to me how to do it, but I would volunteer to make test binaries for Windows users in the future. racoon, Klaus, and Joon, can you still reproduce the issue and would you be willing to test the binary that includes a patch for this annoying issue? Also, is there a reasonable chance that the write succeeds after a smaller delay than 1 second? For example, might we want to try again after 0.25 seconds for the first time, 0.5 seconds after the second, 1 second after the third, and then stay at 1 second for the fourth, fifth, and sixth try? I can update the patch, if this change would be desired. I have no intuition for the cost of trying more frequently, so I don't have a strong opinion. Scott signature.asc Description: PGP signature
Do we want to catch a QT_SCALE_FACTOR that is too large?
The following might crash your system, so be cautious if trying: QT_SCALE_FACTOR=100 lyx For me, it does not crash my system. It just opens a very large window with jibberish, and in the terminal I see the following: ... QPainter::setPen: Painter not active QPainter::restore: Unbalanced save/restore QPainter::end: Painter not active, aborted I think that not crashing and not running out of memory is actually pretty good, compared to what I expected. Should we exit gracefully? Should we set a max? I'm fine with a "wontfix" on this. I was just curious what others thought. I'm not sure what kind of sanity checks LyX is responsible for. Note that the Qt application CopyQ just put in the following fix for this: https://github.com/hluk/CopyQ/commit/3d43b8b98a52249b7df35fdabc6e6070992bdb29 Scott signature.asc Description: PGP signature
Re: [LyX/master] Add date-related info insets
Am Dienstag, den 07.08.2018, 18:56 +0100 schrieb José Abílio Matos: > On Sunday, 5 August 2018 09.05.07 WEST Juergen Spitzmueller wrote: > > The lyx2lyx reversion routine has lots of room for improvement and > > attractive tasks for pythons (file timestamp, switch of > > localization). > > Please feel invited! > > Is this invitation still worth it? Yes! > > Regards, :-) > > PS: I think you meant pythonistas as you are targeting the people and > not the > ophidian. ;-) I basically meant you :-) Jürgen signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Add date-related info insets
On Sunday, 5 August 2018 09.05.07 WEST Juergen Spitzmueller wrote: > The lyx2lyx reversion routine has lots of room for improvement and > attractive tasks for pythons (file timestamp, switch of localization). > Please feel invited! Is this invitation still worth it? Regards, :-) PS: I think you meant pythonistas as you are targeting the people and not the ophidian. ;-) -- José Abílio
Re: Feedback on info insets
On Tue, Aug 07, 2018 at 05:07:46PM +, Jürgen Spitzmüller wrote: > Am Dienstag, den 07.08.2018, 13:05 -0400 schrieb Scott Kostyshak: > > > > 4. If I do Insert > Field > Other, the "immediate apply" checkbox > > > > is > > > > enabled. I wonder if it should only be enabled if we are editing > > > > an > > > > inset (rather than creating a new one)? > > > > > > It's only enabled if you had it enabled. We save the state for all > > > dialogs. I don't think we should make an exception here. > > > > I meant "enabled" in the Qt sense. I did not mean "checked". > > I see. But then, this would have to be done generally for all > InsetWidget dialogs. OK, I'm fine with a "wontfix" then. Scott signature.asc Description: PGP signature
Re: Feedback on info insets
Am Dienstag, den 07.08.2018, 13:05 -0400 schrieb Scott Kostyshak: > > > 4. If I do Insert > Field > Other, the "immediate apply" checkbox > > > is > > > enabled. I wonder if it should only be enabled if we are editing > > > an > > > inset (rather than creating a new one)? > > > > It's only enabled if you had it enabled. We save the state for all > > dialogs. I don't think we should make an exception here. > > I meant "enabled" in the Qt sense. I did not mean "checked". I see. But then, this would have to be done generally for all InsetWidget dialogs. Jürgen signature.asc Description: This is a digitally signed message part
Re: Feedback on info insets
On Tue, Aug 07, 2018 at 04:50:57PM +, Jürgen Spitzmüller wrote: > Am Dienstag, den 07.08.2018, 12:29 -0400 schrieb Scott Kostyshak: > > 2. When I first went to Inset > Field > User name, I wasn't sure > > whether > > my computer user name, or my LyX user name would show up. When I go > > to > > the inset settings, it is clear because it is in the category "LyX > > Preferences Entry", but just from the menus, it was not clear to me. > > We > > could change the menu entry to "LyX user name" and "LyX user email", > > but > > unless someone also had the same uncertainty that I did, this is > > probably a "wontfix". > > I don't like "LyX user name", but I am open for good suggestions. In > any case, I wanted to differentiate it from "Author", which can differ. I don't have a better suggestion. > > 3. I find the category name "All Keyboard Shortcuts" inconsistent > > with > > the other category names. For example, there is "LyX Preferences > > Entry", > > not "All LyX Preferences Entry". I think the intent was to > > differentiate > > the category from the closely related "Last Assigned Keyboard > > Shortcut" > > (which I don't actually know what this one does). Perhaps we could > > change "All Keyboard Shortcuts" to "Keyboard Shortcuts"? > > There are two info types here: one only displays the last shortcut in > the list of potentially multiple shortcuts assigned to a function, the > other displays the whole list. > > There is no such thing for preferences entries. > > So "All keyboard shortcuts" means "All shortcuts for the function > selected", not "display all keyboard shortcuts in the dialog". I think > removing the "all" does not make it more transparent. I see, makes sense. > > 4. If I do Insert > Field > Other, the "immediate apply" checkbox is > > enabled. I wonder if it should only be enabled if we are editing an > > inset (rather than creating a new one)? > > It's only enabled if you had it enabled. We save the state for all > dialogs. I don't think we should make an exception here. I meant "enabled" in the Qt sense. I did not mean "checked". > > 5. What is the purpose of having the "Unknown" option in the combo > > box? > > I imagine it has a use, but would it make sense to internally allow > > the > > combo box to be set to that value, but just not provide it as an > > option > > in the interface? I guess what I'm asking is: would a user ever want > > to > > manually set the value to "Unknown"? > > No. I am not sure, though, that we can add a hidden item to the combo. Fair enough. > > 6. I get the following warning: > > frontends/qt4/Menus.cpp (763): Menu warning: menu entries "Index > > Entry|d" and "Field|d" share the same shortcut. > > OK, this comes from one of the dynamic menu parts. You only get it if > you have an index. That's why I missed it. Having to deal with detecting and fixing those is annoying. I wish there were some automatic way to catch these conflicts. > > 7. Are we concerned about any security/privacy issues related to this > > feature? This item is not really relevant to the recent changes, > > since > > some (all?) of this information was already available. I don't have > > any > > particular concern here, but since we are exposing e.g. LyX user > > name, > > LyX user email, and LyX preferences, I'm curious if someone can think > > of > > a privacy issue. The biggest "security threat" I could think of is if > > I'm helping someone who sends me a .lyx file and asks me to send them > > the corresponding .pdf, perhaps I don't expect that my "LyX user > > name" > > (which I think defaults to my computer's user name) could be > > contained. > > I suppose that knowing one's computer name makes it easier to e.g. > > SSH > > into their box. This is not a personal concern of mine, and I expose > > my > > computer user name and host name all over the place. I was just > > attempting to think of what might be a concern to other LyX users. > > I think due to this security issue we do not set the user name > automatically. Users need to deliberately set it. I don't think it is > related to the computer name. Ah thanks for the correction. Thanks for the quick reply! Scott signature.asc Description: PGP signature
Re: Feedback on info insets
Am Dienstag, den 07.08.2018, 12:29 -0400 schrieb Scott Kostyshak: > To Jürgen: I don't expect you to fix these. You've already done so > much > work on this. I just provide this feedback since I am trying out > these > insets for the first time (I'm on master at 781b1030). I can make > trac > tickets if anyone suggests. Thanks for testing. I will respond in the kind of first thoughts: > 1. If I insert Field > User Name, then change the name in Preferences > and click "OK" or "Apply", the inset is not updated in the LyX > display > until I do something like . I think this behavior is more > general than this specific inset (e.g., I remember a similar issue > with > Instant Preview), but since I noticed it here I report it here. It actually updates if you click on the inset, so I suppose a prefs apply should trigger a buffer update. > 2. When I first went to Inset > Field > User name, I wasn't sure > whether > my computer user name, or my LyX user name would show up. When I go > to > the inset settings, it is clear because it is in the category "LyX > Preferences Entry", but just from the menus, it was not clear to me. > We > could change the menu entry to "LyX user name" and "LyX user email", > but > unless someone also had the same uncertainty that I did, this is > probably a "wontfix". I don't like "LyX user name", but I am open for good suggestions. In any case, I wanted to differentiate it from "Author", which can differ. > 3. I find the category name "All Keyboard Shortcuts" inconsistent > with > the other category names. For example, there is "LyX Preferences > Entry", > not "All LyX Preferences Entry". I think the intent was to > differentiate > the category from the closely related "Last Assigned Keyboard > Shortcut" > (which I don't actually know what this one does). Perhaps we could > change "All Keyboard Shortcuts" to "Keyboard Shortcuts"? There are two info types here: one only displays the last shortcut in the list of potentially multiple shortcuts assigned to a function, the other displays the whole list. There is no such thing for preferences entries. So "All keyboard shortcuts" means "All shortcuts for the function selected", not "display all keyboard shortcuts in the dialog". I think removing the "all" does not make it more transparent. > 4. If I do Insert > Field > Other, the "immediate apply" checkbox is > enabled. I wonder if it should only be enabled if we are editing an > inset (rather than creating a new one)? It's only enabled if you had it enabled. We save the state for all dialogs. I don't think we should make an exception here. > 5. What is the purpose of having the "Unknown" option in the combo > box? > I imagine it has a use, but would it make sense to internally allow > the > combo box to be set to that value, but just not provide it as an > option > in the interface? I guess what I'm asking is: would a user ever want > to > manually set the value to "Unknown"? No. I am not sure, though, that we can add a hidden item to the combo. > 6. I get the following warning: > frontends/qt4/Menus.cpp (763): Menu warning: menu entries "Index > Entry|d" and "Field|d" share the same shortcut. OK, this comes from one of the dynamic menu parts. You only get it if you have an index. That's why I missed it. > 7. Are we concerned about any security/privacy issues related to this > feature? This item is not really relevant to the recent changes, > since > some (all?) of this information was already available. I don't have > any > particular concern here, but since we are exposing e.g. LyX user > name, > LyX user email, and LyX preferences, I'm curious if someone can think > of > a privacy issue. The biggest "security threat" I could think of is if > I'm helping someone who sends me a .lyx file and asks me to send them > the corresponding .pdf, perhaps I don't expect that my "LyX user > name" > (which I think defaults to my computer's user name) could be > contained. > I suppose that knowing one's computer name makes it easier to e.g. > SSH > into their box. This is not a personal concern of mine, and I expose > my > computer user name and host name all over the place. I was just > attempting to think of what might be a concern to other LyX users. I think due to this security issue we do not set the user name automatically. Users need to deliberately set it. I don't think it is related to the computer name. Jürgen > > I am enjoying this new feature. I think I will find some nice uses > for > it in my work. > > Best, > > Scott signature.asc Description: This is a digitally signed message part
Feedback on info insets
Thanks to Jürgen for improving these insets and the interface to them. I just tested the feature and am impressed with all of the possibilities available. Very cool! To Jürgen: I don't expect you to fix these. You've already done so much work on this. I just provide this feedback since I am trying out these insets for the first time (I'm on master at 781b1030). I can make trac tickets if anyone suggests. 1. If I insert Field > User Name, then change the name in Preferences and click "OK" or "Apply", the inset is not updated in the LyX display until I do something like . I think this behavior is more general than this specific inset (e.g., I remember a similar issue with Instant Preview), but since I noticed it here I report it here. 2. When I first went to Inset > Field > User name, I wasn't sure whether my computer user name, or my LyX user name would show up. When I go to the inset settings, it is clear because it is in the category "LyX Preferences Entry", but just from the menus, it was not clear to me. We could change the menu entry to "LyX user name" and "LyX user email", but unless someone also had the same uncertainty that I did, this is probably a "wontfix". 3. I find the category name "All Keyboard Shortcuts" inconsistent with the other category names. For example, there is "LyX Preferences Entry", not "All LyX Preferences Entry". I think the intent was to differentiate the category from the closely related "Last Assigned Keyboard Shortcut" (which I don't actually know what this one does). Perhaps we could change "All Keyboard Shortcuts" to "Keyboard Shortcuts"? 4. If I do Insert > Field > Other, the "immediate apply" checkbox is enabled. I wonder if it should only be enabled if we are editing an inset (rather than creating a new one)? 5. What is the purpose of having the "Unknown" option in the combo box? I imagine it has a use, but would it make sense to internally allow the combo box to be set to that value, but just not provide it as an option in the interface? I guess what I'm asking is: would a user ever want to manually set the value to "Unknown"? 6. I get the following warning: frontends/qt4/Menus.cpp (763): Menu warning: menu entries "Index Entry|d" and "Field|d" share the same shortcut. 7. Are we concerned about any security/privacy issues related to this feature? This item is not really relevant to the recent changes, since some (all?) of this information was already available. I don't have any particular concern here, but since we are exposing e.g. LyX user name, LyX user email, and LyX preferences, I'm curious if someone can think of a privacy issue. The biggest "security threat" I could think of is if I'm helping someone who sends me a .lyx file and asks me to send them the corresponding .pdf, perhaps I don't expect that my "LyX user name" (which I think defaults to my computer's user name) could be contained. I suppose that knowing one's computer name makes it easier to e.g. SSH into their box. This is not a personal concern of mine, and I expose my computer user name and host name all over the place. I was just attempting to think of what might be a concern to other LyX users. I am enjoying this new feature. I think I will find some nice uses for it in my work. Best, Scott signature.asc Description: PGP signature
Re: Debugging LyX server on Windows
On Thu, Aug 02, 2018 at 01:58:37AM +0200, Pavel Sanda wrote: > Will S wrote: > > I have been helping a user debug a problem with a tool (LyZ, > > https://github.com/willsALMANJ/lyz) that I maintain that interfaces with > > LyX through the LyX server. The main symptom is that the lyxserver.out file > > appears to be empty. Specifically, when LyZ writes a command into > > lyxserver.in, LyX performs that command as normal (so the "statistics" > > command causes the statistics window to pop up in LyX), but when a command > > (like "server-get-filename") is run that requires a response from LyX that > > response does not get written to lyxserver.out (lyxserver.out still appears > > empty). This problem is seen on some Windows systems but not all. More > > details about the specific issue can be found at this page: > > https://github.com/willsALMANJ/lyz/issues/14 > > > > Are there any techniques we could use to debug this issue further? It seems > > Shot in the dark: buffering output to lyxserver.out? If this was the cause > then running "server-get-filename" 100x times will at certain moment output > the whole buffer with all answers at once. No, this seems to be an issue introduced in recent versions of Windows. When an overlapped write operation to a pipe is in progress, GetLastError() used returning ERROR_IO_PENDING while now it seems to also return NO_ERROR. This was confusing the software so that the scheduled replies were never actually output. Should be now fixed in master at cf5f2661. -- Enrico
Re: Bug Report for LYX.
On Tue, Aug 07, 2018 at 08:32:39AM +, Valmikanathan S wrote: > Hi, > > > > Please update the details on how to install with sequence and packages to > install for engineering mathematics and mathematical drawing. > > > > I am attaching the bug Hi Valmikanathan, can you please send a minimal .lyx file that can reproduce the bug that you're seeing? For more information, please see here: https://wiki.lyx.org/FAQ/MinimalExample Thanks for your help in tracking down this bug, Scott signature.asc Description: PGP signature
Re: [LyX/master] Further extend Info insets: * Add time type (time, modtime, fixtime) * Add "name-noext" buffer type (file name w/o extension)
Am Dienstag, den 07.08.2018, 14:15 +0200 schrieb Kornel Benko: > Works nice. The localization is super. Thanks. I am glad to hear Qt localization works for you this time. Jürgen > > Kornel signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Further extend Info insets: * Add time type (time, modtime, fixtime) * Add "name-noext" buffer type (file name w/o extension)
Am Dienstag, 7. August 2018 12:19:31 CEST schrieb Juergen Spitzmueller : > commit 7efdf98fc8f0d4d78d4c9db0e268004a95f03a40 > Author: Juergen Spitzmueller > Date: Tue Aug 7 12:14:45 2018 +0200 > > Further extend Info insets: > * Add time type (time, modtime, fixtime) > * Add "name-noext" buffer type (file name w/o extension) > Works nice. The localization is super. Kornel signature.asc Description: This is a digitally signed message part.
Bug Report for LYX.
Hi,
Please update the details on how to install with sequence and packages to
install for engineering mathematics and mathematical drawing.
I am attaching the bug
When I try to export to pdf from LYX after
typing the mathematics 12th grade exam papers.
Please do the needful.
Regards
Valmikanathan S
13:51:30.553: Exporting ...
13:51:30.584: (buffer-export odt)
13:51:30.631: pdflatex "+2_10_Marks.tex"Undo.cpp (566): +++ Creating new
group 236 for buffer 0x703f6d0
frontends/qt4/GuiApplication.cpp (1576): cmd: action: 337 [buffer-export]
arg: 'odt' x: 0 y: 0
support/FileName.cpp (423): Directory D:/Latex is writable
BufferParams.cpp (2438): setBaseClass: article
TextClass.cpp (333): Reading cite engine: [citeengines/basic.citeengine]
Lexer.cpp (257): lyxlex: UNcompressed
Lexer.cpp (336): Comment read: `35 \DeclareLyXCiteEngine{Basic (BibTeX)}'
Lexer.cpp (336): Comment read: `35 DescriptionBegin'
Lexer.cpp (336): Comment read: `35 The basic citation capabilities provided
by BibTeX.'
Lexer.cpp (336): Comment read: `35 Mainly simple numeric styles primarily
suitable for science and maths.'
Lexer.cpp (336): Comment read: `35 DescriptionEnd'
Lexer.cpp (336): Comment read: `35 Author: Julien Rioux '
Lexer.cpp (336): Comment read: `35 The framework (biblatex|bibtex)'
Lexer.cpp (336): Comment read: `35 Cite style variants
(default|authoryear|natbib)'
Lexer.cpp (336): Comment read: `35 We provide only default citations'
Lexer.cpp (336): Comment read: `35 Default style file'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 CITE COMMAND DEFINITIONS for either engine
type'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 (cf. natbib.citeengine for a decription of
the syntax)'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 CITE FORMAT'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Input standard format definitions for the
bibliography'
TextClass.cpp (333): Reading input file: [layouts/stdciteformats.inc]
Lexer.cpp (257): lyxlex: UNcompressed
Lexer.cpp (336): Comment read: `35 Standard formats for bibliography entries.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 This defines how LyX displays bibliographic
information in the GUI'
Lexer.cpp (336): Comment read: `35 as well as in text/xhtml output. The format
of citation references'
Lexer.cpp (336): Comment read: `35 is defined in the *.citeengines files, which
might override the'
Lexer.cpp (336): Comment read: `35 default formatting defined here.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 This file is included by the citation
engines, so there is no need'
Lexer.cpp (336): Comment read: `35 to include it in individual classes.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Author: Richard Heck '
Lexer.cpp (336): Comment read: `35 Jürgen Spitzmüller '
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Translatable bits (need to be marked by _
prefix, if translated to the GUI language,'
Lexer.cpp (336): Comment read: `35 or B_, if translated to the buffer language)'
Lexer.cpp (336): Comment read: `35 Note that preceding and trailing spaces
matter.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 The following are handled by BiblioInfo.
Note that preceding and trailing spaces matter'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Macros'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Scheme of the first author in the
bibliography'
Lexer.cpp (336): Comment read: `35 Scheme of other authors in the bibliography'
Lexer.cpp (336): Comment read: `35 Scheme of the first name in later parts
(such as book editor)'
Lexer.cpp (336): Comment read: `35 Scheme of other authors in later parts (such
as book editor)'
Lexer.cpp (336): Comment read: `35 Scheme of authors in citation references'
Lexer.cpp (336): Comment read: `35 pagination'
Lexer.cpp (336): Comment read: `35 ed. or eds.'
Lexer.cpp (336): Comment read: `35 author or editor, as fullnames, following
the schemes above'
Lexer.cpp (336): Comment read: `35 "vol. 1, no.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Entry types. Note that final punctuation
will be added later, if needed.'
Lexer.cpp (336): Comment read: `35'
TextClass.cpp (346): Finished reading input file: [layouts/stdciteformats.inc]
Lexer.cpp (336): Comment read: `35 The following defines how the commands are
represented in the GUI'
Lexer.cpp (336): Comment read: `35 (inset button and citation dialog) as well
as in XHTML, docbook and'
Lexer.cpp (336): Comment read: `35 plain text output.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 MACROS'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 1. Translatable bi
