Re: Math.lyx export to latex

Guenter Milde wrote: > On 2015-03-31, Kornel Benko wrote: > > >> What is a good name for the subdir? > > Similar to the behaviour of web browsers when downloading HTML+images, I'd > name it "-files/" i.e. for "math.tex" it > would becomd "math-files/" This looks good. I have a vague memory

Re: what does ... mean in our GUI menus/buttons?

Scott Kostyshak wrote: In the LaTeX Errors dialog, what doe the ... mean in View Complete Log... ? Does it have anything to do with signalling to the user that another menu will follow? In some of the menu entries with following dialogs I see ... but in others I do not. For example, why is

Re: Compiling the new europasscv.lyx with ps2pdf or dvipdfmx or dviluatex?

Scott Kostyshak wrote: Is it possible to compile europasscv.lyx using ps2pdf or dvipdfmx or dviluatex? When I try it, I get an error cannot determine size of graphic... Stefan (the author of europasscv.lyx) was kind enough to take a look, reproduce the errors I got, and give a detailed

Re: [ugly patch] fix bug 9418

Jean-Marc Lasgouttes wrote: Could you tell us a little bit about ArgumentProxy and what is is good for? It is used for macros with arguments. Each argument of a math macro is one cell of the macro. An ArgumentProxy is the expanded representation of such a cell. It has basically no own data

Re: Text::autoBreakRow_ , is it dead code???

Jean-Marc Lasgouttes wrote: One is supposed to use inset-toggle to put a math inset (e.g. a fraction in a formula) in a closed state, where the cursor cannot eenter in the inset. This state is saved in the .lyx file. Thanks for the explanation. Actually, I am not sure anymore that it is a

Re: [ugly patch] fix bug 9418

Jean-Marc Lasgouttes wrote: > Could you tell us a little bit about ArgumentProxy and what is is good > for? It is used for macros with arguments. Each argument of a math macro is one cell of the macro. An ArgumentProxy is the expanded representation of such a cell. It has basically no own data

Re: what does "..." mean in our GUI menus/buttons?

Scott Kostyshak wrote: > In the LaTeX Errors dialog, what doe the "..." mean in "View Complete > Log..." ? Does it have anything to do with signalling to the user that > another menu will follow? In some of the menu entries with following > dialogs I see "..." but in others I do not. For example,

Re: Compiling the new europasscv.lyx with ps2pdf or dvipdfmx or dviluatex?

Scott Kostyshak wrote: > Is it possible to compile europasscv.lyx using ps2pdf or dvipdfmx or > dviluatex? When I try it, I get an error "cannot determine size of > graphic..." > > Stefan (the author of europasscv.lyx) was kind enough to take a look, > reproduce the errors I got, and give a

Re: Text::autoBreakRow_ , is it dead code???

Jean-Marc Lasgouttes wrote: > One is supposed to use inset-toggle to put a math inset (e.g. a fraction > in a formula) in a closed state, where the cursor cannot eenter in the > inset. This state is saved in the .lyx file. Thanks for the explanation. > Actually, I am not sure anymore that it is

Re: Math.lyx export to latex

Kornel Benko wrote: This is a recipe to observe creation of files in lyx-source 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/. This is not needed, but shows that the behaviour does not depend on the path of Math.lyx 2.) use your lyx from the build directory

Re: [ugly patch] fix bug 9418

Richard Heck wrote: On 03/22/2015 09:14 AM, Georg Baum wrote: Jean-Marc Lasgouttes wrote: Le 20/03/15 21:53, Georg Baum a écrit : The real cause for the bug is that ArgumentProxy::mathMacro_ is a reference to an object which is stored in a MathData, which is a std::vector storing MathAtoms

Re: Math.lyx export to latex

Kornel Benko wrote: Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum georg.b...@post.rwth-aachen.de Unfortunately I don't have time to investigate now, but I'd guess that neither Exporter.cpp nor TempFile is the culprit. It is normal for the conversion process to use temporary files

Re: Math.lyx export to latex

Kornel Benko wrote: > This is a recipe to observe creation of files in lyx-source > > 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say > ~/lyx/test/. This is not needed, but shows that the behaviour does not > depend on the path of Math.lyx > 2.) use your lyx from the build

Re: [ugly patch] fix bug 9418

Richard Heck wrote: > On 03/22/2015 09:14 AM, Georg Baum wrote: >> Jean-Marc Lasgouttes wrote: >> >>> Le 20/03/15 21:53, Georg Baum a écrit : >>>> The real cause for the bug is that ArgumentProxy::mathMacro_ is a >>>> reference to an object wh

Re: Math.lyx export to latex

Kornel Benko wrote: > Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> >> Unfortunately I don't have time to investigate now, but I'd guess that >> neither Exporter.cpp nor TempFile is the culprit. It is normal for the >

Re: Text::autoBreakRow_ , is it dead code???

Jean-Marc Lasgouttes wrote: Hi all, Does anyone has an idea on the usefulness of Text::autoBreakRow_? It seems to be read in only one place (insertStringAsLines) and I am not even sure of why it could make sense there. Is it a remnant of something that used to make sense? Unfortunately

Re: Text::autoBreakRow_ , is it dead code???

Jean-Marc Lasgouttes wrote: > Hi all, > > Does anyone has an idea on the usefulness of Text::autoBreakRow_? It > seems to be read in only one place (insertStringAsLines) and I am not > even sure of why it could make sense there. > > Is it a remnant of something that used to make sense?

Re: Exporting from command line now crashes (SIGSEGV) for many docs

Enrico Forestieri wrote: On Mon, Mar 23, 2015 at 10:09:03PM +0100, Georg Baum wrote: Scott Kostyshak wrote: Enrico, can you reproduce? $ lyx -e pdf2 Math.lyx I can. Since lyx::support::iconScaleFactor() occurs in the call stack I believe the crash was caused

Re: Exporting from command line now crashes (SIGSEGV) for many docs

Enrico Forestieri wrote: > On Mon, Mar 23, 2015 at 10:09:03PM +0100, Georg Baum wrote: > >> Scott Kostyshak wrote: >> > Enrico, can you reproduce? >> > >> > $ lyx -e pdf2 Math.lyx >> >> I can. Since lyx::support::iconScaleFactor() occurs

Re: [LyX/master] Use the nominal theme's icon size for displaying the icon in an info inset.

Enrico Forestieri wrote: On Fri, Mar 13, 2015 at 12:40:21PM +0100, Kornel Benko wrote: Am Freitag, 13. März 2015 um 12:39:25, schrieb Kornel Benko kor...@lyx.org Am Freitag, 13. März 2015 um 00:42:40, schrieb Enrico Forestieri for...@lyx.org commit

Re: new compiler warnings in master

Jürgen Spitzmüller wrote: Perhaps: hyphen - softhyphen slash - breakableslash to make their semantics more explicit. Good idea, I did it like that. Georg

Re: Exporting from command line now crashes (SIGSEGV) for many docs

Scott Kostyshak wrote: Ctests are failing for many documents, such as Math.lyx Exporting Math.lyx from the command line gives me a SIGSEGV (I can export fine from GUI though). See the backtrace at the bottom of this email. A 'git bisect run' narrowed the issue down to 4 commits (I could

Re: new compiler warnings in master

Jürgen Spitzmüller wrote: > Perhaps: > hyphen -> softhyphen > slash -> breakableslash > > to make their semantics more explicit. Good idea, I did it like that. Georg

Re: [LyX/master] Use the nominal theme's icon size for displaying the icon in an info inset.

Enrico Forestieri wrote: > On Fri, Mar 13, 2015 at 12:40:21PM +0100, Kornel Benko wrote: >> Am Freitag, 13. März 2015 um 12:39:25, schrieb Kornel Benko >> >> > Am Freitag, 13. März 2015 um 00:42:40, schrieb Enrico Forestieri >> > >> > > commit

Re: Exporting from command line now crashes (SIGSEGV) for many docs

Scott Kostyshak wrote: > Ctests are failing for many documents, such as Math.lyx > > Exporting Math.lyx from the command line gives me a SIGSEGV (I can > export fine from GUI though). See the backtrace at the bottom of this > email. > > A 'git bisect run' narrowed the issue down to 4 commits (I

Re: [ugly patch] fix bug 9418

Jean-Marc Lasgouttes wrote: Le 20/03/15 21:53, Georg Baum a écrit : The real cause for the bug is that ArgumentProxy::mathMacro_ is a reference to an object which is stored in a MathData, which is a std::vector storing MathAtoms by value (not pointers). Therefore, each time when the MathData

Re: new compiler warnings in master

Georg Baum wrote: OK, I will change it. But since the LyX file format really has nothing to do with LaTeX (except for math), I will remove all backslashes and {} pairs from InsetSpecialChar. BTW, LaTeX2E is not the only one which is different. This would look like the attached. Before I

Re: [ugly patch] fix bug 9418

Jean-Marc Lasgouttes wrote: > Le 20/03/15 21:53, Georg Baum a écrit : >> The real cause for the bug is that ArgumentProxy::mathMacro_ is a >> reference to an object which is stored in a MathData, which is a >> std::vector storing MathAtoms by value (not pointers). Therefo

Re: new compiler warnings in master

Georg Baum wrote: > OK, I will change it. But since the LyX file format really has nothing to > do with LaTeX (except for math), I will remove all backslashes and {} > pairs from InsetSpecialChar. BTW, LaTeX2E is not the only one which is > different. This would look like the attach

[ugly patch] fix bug 9418

Georg Baum wrote: This problem would be easily avoided if one would iterate backwards through the macro insets (a macro can never reference another one which follows later), but unfortunately I failed to implement that, since I do not understand the DocIterator stuff well enough. I tried

Re: new compiler warnings in master

Jean-Marc Lasgouttes wrote: Le 18/03/15 20:27, Georg Baum a écrit : Oops! Thanks for the fix. Why do you think that the LyX file format needs to follow the LaTeX restrictions? IMHO it does not need to match (therefore I did not include the {} in the LyX file format, which is done for other

[ugly patch] fix bug 9418

Georg Baum wrote: > This problem would be easily avoided if one would iterate backwards > through the macro insets (a macro can never reference another one which > follows later), but unfortunately I failed to implement that, since I do > not understand the DocIterator stuff well eno

Re: new compiler warnings in master

Jean-Marc Lasgouttes wrote: > Le 18/03/15 20:27, Georg Baum a écrit : >> Oops! Thanks for the fix. >> >> Why do you think that the LyX file format needs to follow the LaTeX >> restrictions? IMHO it does not need to match (therefore I did not include >> the {} in t

Re: new compiler warnings in master

Jean-Marc Lasgouttes wrote: Georg, note that there was an error for LaTeX 2e (\LaTeX2e instead of \LaTeXe). I fixed it in LaTeX output, but I suspect that we should change the file format too for consistency sake. Oops! Thanks for the fix. Why do you think that the LyX file format needs to

Re: new compiler warnings in master

Jean-Marc Lasgouttes wrote: > Georg, note that there was an error for LaTeX 2e (\LaTeX2e instead of > \LaTeXe). I fixed it in LaTeX output, but I suspect that we should > change the file format too for consistency sake. Oops! Thanks for the fix. Why do you think that the LyX file format needs

help needed to fix bug 9418

bug 9418 is about a crash which happens during mathml generation after copying a math macro to the clipboard. The bug report shows several problems, which I'll address eventually, but the actual crash happens because Buffer::updateMacroInstances() iterates through the insets from begin to end.

help needed to fix bug 9418

bug 9418 is about a crash which happens during mathml generation after copying a math macro to the clipboard. The bug report shows several problems, which I'll address eventually, but the actual crash happens because Buffer::updateMacroInstances() iterates through the insets from begin to end.

Re: [LyX/master] Fix stmaryrd operators with limits (bug 9458)

Georg Baum wrote: commit 5ee6172b7b203a5fd019b55e7f71b454be763139 Author: Georg Baum b...@lyx.org Date: Fri Mar 13 18:34:39 2015 +0100 Fix stmaryrd operators with limits (bug 9458) LyX did not display the limits of the big math operators defined by stmaryrd.sty

Re: [LyX/master] Fix stmaryrd operators with limits (bug 9458)

Georg Baum wrote: > commit 5ee6172b7b203a5fd019b55e7f71b454be763139 > Author: Georg Baum <b...@lyx.org> > Date: Fri Mar 13 18:34:39 2015 +0100 > > Fix stmaryrd operators with limits (bug 9458) > > LyX did not display the limits of the

Re: [patch] LyX logo logoification

Jean-Marc Lasgouttes wrote: Le 13/03/2015 12:10, Jean-Marc Lasgouttes a écrit : In this patch, I change our new LyX logo inset to look like the real thing. Georg, is there a reason why your chose not to follow this route (or only lack of time/motivation). Simply lack of time. My most

Re: [patch] LyX logo logoification

Jean-Marc Lasgouttes wrote: > Le 13/03/2015 12:10, Jean-Marc Lasgouttes a écrit : >> In this patch, I change our new LyX logo inset to look like the real >> thing. Georg, is there a reason why your chose not to follow this route >> (or only lack of time/motivation). Simply lack of time. My most

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Juergen Spitzmueller wrote: commit 9d824a04d11c3223db26d2fe146e86e90a432a6e Author: Juergen Spitzmueller sp...@lyx.org Date: Tue Mar 10 18:31:55 2015 +0100 Properly define MultiPar status of caption in the layout definition. Also remove hardcoded paragraph break disabling.

Re: [patch] Prefer svg icons

Enrico Forestieri wrote: On Wed, Mar 11, 2015 at 10:50:00PM +0100, Enrico Forestieri wrote: I discovered the reason of this last thing. It is not related to the platform or the kind of inset (graphics or info) but to whether the directory containing the compressed svg is writable or not.

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Juergen Spitzmueller wrote: > commit 9d824a04d11c3223db26d2fe146e86e90a432a6e > Author: Juergen Spitzmueller > Date: Tue Mar 10 18:31:55 2015 +0100 > > Properly define MultiPar status of caption in the layout definition. > > Also remove hardcoded paragraph break

Re: [patch] Prefer svg icons

Enrico Forestieri wrote: > On Wed, Mar 11, 2015 at 10:50:00PM +0100, Enrico Forestieri wrote: >> >> I discovered the reason of this last thing. It is not related to the >> platform or the kind of inset (graphics or info) but to whether the >> directory containing the compressed svg is writable

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Georg Baum wrote: I still need to investigate why the old tex2lyx output was wrong (I suspect that it will be wrong in other places as well). Found it. The reason was that InsetCaption uses a hard coded plain layout for the InsetText constructor, and this was not consistent with the old

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Jürgen Spitzmüller wrote: Georg Baum wrote: The tex2lyx tests fail now because captions produce Plain Layout instead of Standard. If this is wanted then a file format change and lyx2lyx conversion are missing. If the plain layout is an unwanted side effect then some other fix is needed

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Jürgen Spitzmüller wrote: > Georg Baum wrote: > >> The tex2lyx tests fail now because captions produce "Plain Layout" >> instead of "Standard". If this is wanted then a file format change and >> lyx2lyx conversion are missing. If the plain layout is an

Re: [LyX/master] Properly define MultiPar status of caption in the layout definition.

Georg Baum wrote: > I still need to investigate why the old tex2lyx output was wrong (I > suspect that it will be wrong in other places as well). Found it. The reason was that InsetCaption uses a hard coded plain layout for the InsetText constructor, and this was not consistent with t

Re: Patch for \biggg not working: Format Change?

Richard Heck wrote: Seems quite safe, and in that sense I would think it is fine for stable. But... I suppose this isn't a format change, right? Or is it? It is not a format change of the .lyx file format. The output of any LyX file will be the same with and without this patch. One could

Re: \biggg not working

Richard Heck wrote: On 03/05/2015 02:49 PM, Georg Baum wrote: Richard Heck wrote: On 03/04/2015 04:07 PM, Georg Baum wrote: The idea is simply to give a better display for those users who use these packages. AFAIK these commands do not occur in any toolbar, menu or autocompletion

Re: \biggg not working

Richard Heck wrote: > On 03/05/2015 02:49 PM, Georg Baum wrote: >> Richard Heck wrote: >> >>> On 03/04/2015 04:07 PM, Georg Baum wrote: >>>> The idea is simply to give a better display for those users who use >>>> these packages. AFAIK

Re: Patch for "\biggg not working": Format Change?

Richard Heck wrote: > Seems quite safe, and in that sense I would think it is fine for stable. > But... > > I suppose this isn't a format change, right? Or is it? It is not a format change of the .lyx file format. The output of any LyX file will be the same with and without this patch. One

Re: Master: Unable to export to lyx2.1.x format

José Matos wrote: On Monday 02 March 2015 18:26:52 Kornel Benko wrote: To reproduce: Open new file 'xxx.lyx' write xxx File-Export-LyX 2.1.x Without testing I expect this patch to fix that. Yes, it does. Thanks to all, I must have been quite dumb when submitting that. Georg

Re: Retina support on OS X (sponsoring?)

Liviu Andronic wrote: Keeping in mind at least latest Ubuntu LTS seems not unreasonable to me, though. If we decide to go above this requirement, we shall incapacitate a good chunk of our user base. Right now Ubuntu Trusty 14.04 LTS ships Qt5 5.2.1. If technically not too cumbersome, I would

Re: Master: Unable to export to lyx2.1.x format

José Matos wrote: > On Monday 02 March 2015 18:26:52 Kornel Benko wrote: >> To reproduce: >> >> Open new file 'xxx.lyx' >> write xxx >> File->Export->LyX 2.1.x >> > > Without testing I expect this patch to fix that. Yes, it does. Thanks to all, I must have been quite dumb when submitting

Re: Retina support on OS X (sponsoring?)

Liviu Andronic wrote: > Keeping in mind at least latest Ubuntu LTS seems not unreasonable to > me, though. If we decide to go above this requirement, we shall > incapacitate a good chunk of our user base. Right now Ubuntu Trusty > 14.04 LTS ships Qt5 5.2.1. If technically not too cumbersome, I

Re: [LyX/master] Replace automatic logofication with insets

Scott Kostyshak wrote: ctests give a lot of errors after this commit. For example, open doc/UserGuide.lyx and try to compile. I get an undefined control sequence error and \SpecialCharNoPassThru \LaTeX no file found. Thanks, this is fixed now. One day I have to study the ctest machinery, so

Re: [LyX/master] Fix plaintext output of dashes (bug #3647)

Scott Kostyshak wrote: I think lyx2lyx converts some cases it should not. To reproduce an error, do the following: 1. In a LyX with a previous format (any commit before this one) start a new document and go to Insert Label and put a--b and press OK. 2. Save the document. 3. Open the

Re: [patches] Improve error reporting and log parsing

Scott Kostyshak wrote: On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum georg.b...@post.rwth-aachen.de wrote: Enrico Forestieri wrote: My vote is for a warning and an output produced in any case. If latex produces an output, that output has to be shown, IMO. Having the possibility of looking

Re: [LyX/master] Fix plaintext output of dashes (bug #3647)

Scott Kostyshak wrote: > I think lyx2lyx converts some cases it should not. To reproduce an > error, do the following: > > 1. In a LyX with a previous format (any commit before this one) start > a new document and go to Insert > Label and put "a--b" and press OK. > 2. Save the document. > 3.

Re: [patches] Improve error reporting and log parsing

Scott Kostyshak wrote: > On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum > <georg.b...@post.rwth-aachen.de> wrote: >> Enrico Forestieri wrote: >> >>> My vote is for a warning and an output produced in any case. >>> If latex produces an output, th

Re: [LyX/master] Replace automatic logofication with insets

Scott Kostyshak wrote: > ctests give a lot of errors after this commit. For example, open > doc/UserGuide.lyx and try to compile. I get an undefined control > sequence error and "\SpecialCharNoPassThru \LaTeX no file found". Thanks, this is fixed now. One day I have to study the ctest machinery,

Re: [patches] Improve error reporting and log parsing

Enrico Forestieri wrote: My vote is for a warning and an output produced in any case. If latex produces an output, that output has to be shown, IMO. Having the possibility of looking at the output may be of great help to pinpoint problems. This is a good argument actually. Then we should

[patch] Fix automatic logofication of LyX, TeX etc (bug 4752)

are made to tex2lyx and bugs are fixed in lyx2lyx. --- +2015-02-27 Georg Baum georg.b...@post.rwth-aachen.de + * Format incremented to 482 + LyX, TeX, LaTeX2e and LaTeX are not automatically converted + to LaTeX macros anymore. + Instead, these are new flavours

Re: [patch idea] TeX code inset for math

Guenter Milde wrote: OTOH, beware that e.g. $\sum_i$ is valid math inptu for a sum over index i! Thanks, this is the problem. I new I did forgot something, so we still need something which is no valid LaTeX to recognize the inset start. Georg

[patch] Fix automatic logofication of LyX, TeX etc (bug 4752)

are made to tex2lyx and bugs are fixed in lyx2lyx. --- +2015-02-27 Georg Baum <georg.b...@post.rwth-aachen.de> + * Format incremented to 482 + "LyX", "TeX", "LaTeX2e" and "LaTeX" are not automatically converted + to LaTeX macro

Re: [patch idea] TeX code inset for math

Guenter Milde wrote: > OTOH, beware that e.g. $\sum_i$ is valid math inptu for a sum over index > i! Thanks, this is the problem. I new I did forgot something, so we still need something which is no valid LaTeX to recognize the inset start. Georg

Re: [patches] Improve error reporting and log parsing

Enrico Forestieri wrote: > My vote is for a warning and an output produced in any case. > If latex produces an output, that output has to be shown, IMO. > Having the possibility of looking at the output may be of great > help to pinpoint problems. This is a good argument actually. Then we should

Re: [patches] Improve error reporting and log parsing

Scott Kostyshak wrote: 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch - To see why this patch is useful, open New New from Template ACM-sigplan.lyx and compile. It says that compilation was successful and shows the PDF. However, there was an error that was missed in parsing (the

Re: [patch idea] TeX code inset for math

Guenter Milde wrote: Can't we use the standard way of representing insets even if the inset is nested in math? E.g. \begin_layout Standard Was ist \begin_inset Formula $ \begin_inset ERT status open \begin_layout Plain Layout ert \end_layout \end_inset in math$

Re: [patch idea] TeX code inset for math

Richard Heck wrote: Is MathML anything like as expressive as LaTeX? I am no expert, but AFAIK not completely. However, for the math insets we have I believe it should be possible to create a somewhat clean MathML representation if one would want to invest the time. Georg

Re: [patches] Improve error reporting and log parsing

Scott Kostyshak wrote: > 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch > - To see why this patch is useful, open New > New from Template > > ACM-sigplan.lyx and compile. It says that compilation was successful > and shows the PDF. However, there was an error that was missed in >

Re: [patch idea] TeX code inset for math

Guenter Milde wrote: > Can't we use the standard way of representing insets even if the inset is > nested in math? > > E.g. > > \begin_layout Standard > Was ist > \begin_inset Formula $ > \begin_inset ERT > status open > > \begin_layout Plain Layout > > ert > \end_layout > > \end_inset > >

Re: [patch idea] TeX code inset for math

Richard Heck wrote: > Is MathML anything like as expressive as LaTeX? I am no expert, but AFAIK not completely. However, for the math insets we have I believe it should be possible to create a somewhat clean MathML representation if one would want to invest the time. Georg

Re: Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

José Matos wrote: One cosmetic change that I would like to propose is to change the condition + if len(words) 1 and words[0] == \\begin_inset and \ +(words[1] == ERT or words[1] == Formula or words[1] == IPA): to + if len(words) 1 and words[0] == \\begin_inset and \ +

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: Some remarks: * in Text::insertChar, you do not test for typewriter font. Why is that? What do you expect with LyX-Code, for example? You are right, I forgot that. * I still think that cycling would be good, that is \emdash+minus=minus. OK, I'll implement

Re: [LyX/master] Do not mix several names for the same variable

Jean-Marc Lasgouttes wrote: Georg, please check, this is recent code of yours. The new code works as well as the old one. I think this is an area where coverity could improve. Georg

Re: [LyX/master] Do not mix several names for the same variable

Jean-Marc Lasgouttes wrote: > Georg, please check, this is recent code of yours. The new code works as well as the old one. I think this is an area where coverity could improve. Georg

Re: Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

José Matos wrote: > One cosmetic change that I would like to propose is to change the > condition > > + if len(words) > 1 and words[0] == "\\begin_inset" and \ > +(words[1] == "ERT" or words[1] == "Formula" or words[1] == "IPA"): > > to > > + if len(words) > 1 and words[0] ==

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: > Some remarks: > > * in Text::insertChar, you do not test for typewriter font. Why is that? > What do you expect with LyX-Code, for example? You are right, I forgot that. > * I still think that cycling would be good, that is \emdash+minus=>minus. OK, I'll

Re: [LyX/master] Replace hardcoded hack with InsetLayout tag

Scott Kostyshak wrote: To reproduce the above ctest in an actual LyX session, open EmbeddedObjects with write permission, go to Document Settings Fonts, check Use non-TeX fonts and choose FreeSans for Roman, Sans, and Typewriter. Then save and go to File Export PDF (LuaTeX). Are you

Re: [patch idea] TeX code inset for math

Scott Kostyshak wrote: Probably a silly question, but just so I understand better, why not implement it using a direct analog of ERT (e.g. Ctrl L)? For insertion I would prefer Ctrl L as well (since anything starting with a backslash could be a true LaTeX macro). This is easy to do, the

Re: [patch idea] TeX code inset for math

Nico Williams wrote: On Tue, Feb 17, 2015 at 08:45:04PM +0100, Georg Baum wrote: One option which is probably easy to implement would be to mark the start and end of the ERT inset with two unicode symbols from the private use area (similar to META_INSET): We could define char_type const

Re: [patch idea] TeX code inset for math

Uwe Stöhr wrote: Since more about 10 years it has been a dream for me to have a TeX code inset for math. http://www.lyx.org/trac/ticket/2579 This is indeed an important feature and would remove the burden from the math TeX parser to understand 100% of all possible LaTeX formulas. I have

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: Le 16/02/2015 21:08, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: I'd prefer this solution, that would mean that the inset does not really exist. I do not like the idea of having a thing that the user does not understand because s/he cannot reproduce it. I

Re: [patch idea] TeX code inset for math

Uwe Stöhr wrote: > Since more about 10 years it has been a dream for me to have a TeX code > inset for math. > http://www.lyx.org/trac/ticket/2579 This is indeed an important feature and would remove the burden from the math TeX parser to understand 100% of all possible LaTeX formulas. I have

Re: [patch idea] TeX code inset for math

Scott Kostyshak wrote: > Probably a silly question, but just so I understand better, why not > implement it using a direct analog of ERT (e.g. Ctrl L)? For insertion I would prefer Ctrl L as well (since anything starting with a backslash could be a true LaTeX macro). This is easy to do, the

Re: [LyX/master] Replace hardcoded hack with InsetLayout tag

Scott Kostyshak wrote: > To reproduce the above ctest in an actual LyX session, open > EmbeddedObjects with write permission, go to Document Settings > > Fonts, check "Use non-TeX fonts" and choose FreeSans for Roman, Sans, > and Typewriter. Then save and go to File > Export > PDF (LuaTeX). > >

Re: [patch idea] TeX code inset for math

Nico Williams wrote: > On Tue, Feb 17, 2015 at 08:45:04PM +0100, Georg Baum wrote: >> One option which is probably easy to implement would be to mark the start >> and end of the ERT inset with two unicode symbols from the private use >> area (similar to META_IN

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: > Le 16/02/2015 21:08, Georg Baum a écrit : >> Jean-Marc Lasgouttes wrote: >> >>> I'd prefer this solution, that would mean that the inset does not really >>> exist. I do not like the idea of having a thing that the user does not &

Re: [patch] Prefer svg icons

Enrico Forestieri wrote: The attached patch let LyX use svg icons (if they exist) in preference to png ones. The svg icons automatically scale to the wanted dimension and the patch introduces 2 more resolutions (huge and giant icons) that should be useful to people with hires displays. It

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Enrico Forestieri wrote: I have a concern about usability. It is very easy to introduce en- and em-dashes by two or three hyphens. With this patch would one need to open the symbols dialog, search for the right thing, select it, and then hit paste? If so, this is very bad. I had the same

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: I'd prefer this solution, that would mean that the inset does not really exist. I do not like the idea of having a thing that the user does not understand because s/he cannot reproduce it. I would think that something can be done in Text::readParToken, in the

Re: [LyX/master] Make macro xhtml export more secure

Thanks for testing and bisecting! Scott Kostyshak wrote: This seems to have broken export of the Math manual to LyXhtml for me. Only in debug mode. A git bisect run based on the exit code of ctest -R doc/Math_xhtml lead me to this commit. So the LATTEST did its job! It found out that my

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Jean-Marc Lasgouttes wrote: > I'd prefer this solution, that would mean that the inset does not really > exist. I do not like the idea of having a thing that the user does not > understand because s/he cannot reproduce it. > > I would think that something can be done in Text::readParToken, in

Re: [patch] Introduce abstraction from LaTeX for -- and --- (needed for bug 3647)

Enrico Forestieri wrote: > I have a concern about usability. It is very easy to introduce en- and > em-dashes by two or three hyphens. With this patch would one need to > open the symbols dialog, search for the right thing, select it, and then > hit paste? If so, this is very bad. I had the same

Re: [patch] Prefer svg icons

Enrico Forestieri wrote: > The attached patch let LyX use svg icons (if they exist) in preference > to png ones. The svg icons automatically scale to the wanted dimension > and the patch introduces 2 more resolutions (huge and giant icons) that > should be useful to people with hires displays.

Re: [LyX/master] Make macro xhtml export more secure

Thanks for testing and bisecting! Scott Kostyshak wrote: > This seems to have broken export of the Math manual to LyXhtml for me. Only in debug mode. > A git bisect run based on the exit code of > ctest -R "doc/Math_xhtml" > lead me to this commit. So the LATTEST did its job! It found out

Re: View/compile reduced size PDF within LyX

Uwe Stöhr wrote: However, the export menu is now overcrowded in my opinion. The 150 dpi- converter has a very limited target audience and should therefore not be by default in the main export menu. I put it there because the cropped pdf was already in the export menu (which is IMHO needed by

<    5   6   7   8   9   10   11   12   13   14   >