Re: why people give up on open source software

[Jean-Marc Lasgouttes]

24/10/2013 15:59, Ken Springer:

There is also the segment of the open source area where they actively
ask you to file bugs that can be fixed.  Then the bugs just sit there,
never getting fixed.  If you aren't going to actively fix the bugs, then
don't ask for help in identifying those bugs.  This is the non
professional attitude I'm talking about.  Even worse are the developers
who say this and also say they want to compete against a commercial
product.


I cannot speak for other free (as in freedom) software, but the deal is 
simple: programmers do what they can and scratch their own itches, 
either because they need a feature or they want to implement it, and 
users do what they want and scratch their own itches by sending bug 
reports. Their is nothing more in the implied contract. We do have 10 
years old bugs in LyX; it is not only because we do not care about them, 
but many of them require work that is difficult to get right. For 
example, we will have one of these 10-year-old bugs fixed due to a 
Google Summer of Code project, and I can say I am very happy about that.


That said, I have to admit that there are bugs I have no interest in 
fixing. The magic of open source is that, if the bug is important 
enough, it should annoy one of the developers and it will eventually get 
fixed.


About the way bugs are labeled, I can tell you that regression is a 
very important term for us. We do not let such bugs linger too long.
In the opposite, a bug accompanied by a comment like OMG LYX IS 
WORTHLESS DUE TO THIS BUG is not likely to get much attention.


That's how it works. We don't owe you anything, you don't owe us 
anything either, but by some mystery the ecosystem is viable.


JMarc

Re: why people give up on open source software

[Jean-Marc Lasgouttes]

24/10/2013 15:59, Ken Springer:

There is also the segment of the open source area where they actively
ask you to file bugs that can be fixed.  Then the bugs just sit there,
never getting fixed.  If you aren't going to actively fix the bugs, then
don't ask for help in identifying those bugs.  This is the non
professional attitude I'm talking about.  Even worse are the developers
who say this and also say they want to compete against a commercial
product.


I cannot speak for other free (as in freedom) software, but the deal is 
simple: programmers do what they can and scratch their own itches, 
either because they need a feature or they want to implement it, and 
users do what they want and scratch their own itches by sending bug 
reports. Their is nothing more in the implied contract. We do have 10 
years old bugs in LyX; it is not only because we do not care about them, 
but many of them require work that is difficult to get right. For 
example, we will have one of these 10-year-old bugs fixed due to a 
Google Summer of Code project, and I can say I am very happy about that.


That said, I have to admit that there are bugs I have no interest in 
fixing. The magic of open source is that, if the bug is important 
enough, it should annoy one of the developers and it will eventually get 
fixed.


About the way bugs are labeled, I can tell you that regression is a 
very important term for us. We do not let such bugs linger too long.
In the opposite, a bug accompanied by a comment like OMG LYX IS 
WORTHLESS DUE TO THIS BUG is not likely to get much attention.


That's how it works. We don't owe you anything, you don't owe us 
anything either, but by some mystery the ecosystem is viable.


JMarc

Re: why people give up on open source software

[Jean-Marc Lasgouttes]

24/10/2013 15:59, Ken Springer:

There is also the segment of the open source area where they actively
ask you to file bugs that can be fixed.  Then the bugs just sit there,
never getting fixed.  If you aren't going to actively fix the bugs, then
don't ask for help in identifying those bugs.  This is the "non
professional" attitude I'm talking about.  Even worse are the developers
who say this and also say they want to compete against a commercial
product.


I cannot speak for other free (as in freedom) software, but the deal is 
simple: programmers do what they can and scratch their own itches, 
either because they need a feature or they want to implement it, and 
users do what they want and scratch their own itches by sending bug 
reports. Their is nothing more in the implied contract. We do have 10 
years old bugs in LyX; it is not only because we do not care about them, 
but many of them require work that is difficult to get right. For 
example, we will have one of these 10-year-old bugs fixed due to a 
Google Summer of Code project, and I can say I am very happy about that.


That said, I have to admit that there are bugs I have no interest in 
fixing. The magic of open source is that, if the bug is important 
enough, it should annoy one of the developers and it will eventually get 
fixed.


About the way bugs are labeled, I can tell you that "regression" is a 
very important term for us. We do not let such bugs linger too long.
In the opposite, a bug accompanied by a comment like "OMG LYX IS 
WORTHLESS DUE TO THIS BUG" is not likely to get much attention.


That's how it works. We don't owe you anything, you don't owe us 
anything either, but by some mystery the ecosystem is viable.


JMarc

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

11/10/2013 11:33, Jerry:

Surely this is a Qt problem since there are many Qt programs that don't have 
this issue. In fact, there are text-related windows in OS X LyX that don't have 
this problem. (Written by a casual bystander, of course.)


This is definitely a LyX bug. However, this part of the code is not well 
understood by active developers and we have to thank pdv [*] who 
provided an initial implementation of this idea and gave me motivation 
to start this rewrite.


The branch has not landed yet because it did not get substantial 
testing. It is however more or less complete.


JMarc

[*] see the thread here: 
http://comments.gmane.org/gmane.editors.lyx.devel/145311

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

11/10/2013 11:33, Jerry:

Surely this is a Qt problem since there are many Qt programs that don't have 
this issue. In fact, there are text-related windows in OS X LyX that don't have 
this problem. (Written by a casual bystander, of course.)


This is definitely a LyX bug. However, this part of the code is not well 
understood by active developers and we have to thank pdv [*] who 
provided an initial implementation of this idea and gave me motivation 
to start this rewrite.


The branch has not landed yet because it did not get substantial 
testing. It is however more or less complete.


JMarc

[*] see the thread here: 
http://comments.gmane.org/gmane.editors.lyx.devel/145311

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

11/10/2013 11:33, Jerry:

Surely this is a Qt problem since there are many Qt programs that don't have 
this issue. In fact, there are text-related windows in OS X LyX that don't have 
this problem. (Written by a casual bystander, of course.)


This is definitely a LyX bug. However, this part of the code is not well 
understood by active developers and we have to thank pdv [*] who 
provided an initial implementation of this idea and gave me motivation 
to start this rewrite.


The branch has not landed yet because it did not get substantial 
testing. It is however more or less complete.


JMarc

[*] see the thread here: 
http://comments.gmane.org/gmane.editors.lyx.devel/145311

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

Le 10/10/13 01:03, Gwen Barnes a écrit :

Hi folks,

I am using LyX 2.0.6 on Mac 10.8.5.  Whenever I try to scroll, for
instance, with the mouse wheel, or with trackpad gestures, there is
almost a full second lag before the screen starts to change, and then it
moves jerkily until it gets to where it's going.  Based on some comments
I found online, I have found that the lag goes away if I make my LyX
window tiny -- but then the window is not useful to me.

Any ideas what the problem might be, and things I could try to fix it?


The problem is a weakness in LyX display mechanism: text is drawn 
several characters at a time, while metrics (measurement of size) is 
done character-per-character. On windows and linux, it is not a problem, 
but on a Mac, where fonts use ligatures, it means that the cursor does 
not appear where it should.


To alleviate that, by default mac builds draws the screen char-by-char 
too. It works, but it is quite slow...

You can see what the effect is by adding
\force_paint_single_char 0
in the preferences file.

Unfortunately, this situation will not improve in version 2.1.

There is a branch that tackles this problem, but it is not ready yet.

JMarc

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

Le 10/10/13 01:03, Gwen Barnes a écrit :

Hi folks,

I am using LyX 2.0.6 on Mac 10.8.5.  Whenever I try to scroll, for
instance, with the mouse wheel, or with trackpad gestures, there is
almost a full second lag before the screen starts to change, and then it
moves jerkily until it gets to where it's going.  Based on some comments
I found online, I have found that the lag goes away if I make my LyX
window tiny -- but then the window is not useful to me.

Any ideas what the problem might be, and things I could try to fix it?


The problem is a weakness in LyX display mechanism: text is drawn 
several characters at a time, while metrics (measurement of size) is 
done character-per-character. On windows and linux, it is not a problem, 
but on a Mac, where fonts use ligatures, it means that the cursor does 
not appear where it should.


To alleviate that, by default mac builds draws the screen char-by-char 
too. It works, but it is quite slow...

You can see what the effect is by adding
\force_paint_single_char 0
in the preferences file.

Unfortunately, this situation will not improve in version 2.1.

There is a branch that tackles this problem, but it is not ready yet.

JMarc

Re: LyX 2.0.6 scroll lag on Mac 10.8.5

[Jean-Marc Lasgouttes]

Le 10/10/13 01:03, Gwen Barnes a écrit :

Hi folks,

I am using LyX 2.0.6 on Mac 10.8.5.  Whenever I try to scroll, for
instance, with the mouse wheel, or with trackpad gestures, there is
almost a full second lag before the screen starts to change, and then it
moves jerkily until it gets to where it's going.  Based on some comments
I found online, I have found that the lag goes away if I make my LyX
window tiny -- but then the window is not useful to me.

Any ideas what the problem might be, and things I could try to fix it?


The problem is a weakness in LyX display mechanism: text is drawn 
several characters at a time, while metrics (measurement of size) is 
done character-per-character. On windows and linux, it is not a problem, 
but on a Mac, where fonts use ligatures, it means that the cursor does 
not appear where it should.


To alleviate that, by default mac builds draws the screen char-by-char 
too. It works, but it is quite slow...

You can see what the effect is by adding
\force_paint_single_char 0
in the preferences file.

Unfortunately, this situation will not improve in version 2.1.

There is a branch that tackles this problem, but it is not ready yet.

JMarc

Re: enumitem module, enumerate start= lyx bug?

[Jean-Marc Lasgouttes]

Le 17/09/13 08:33, Guenter Milde a écrit :

Using normal fonts it works, but if I use eg. small font for the list, I
get error messages, since the optional start=x argument is put inside 
\small{},
like:



\begin{enumerate}[{\small{start=3}}]



and latex chokes on this.



I think this is an enumitem module bug.


I suppose it is a limitation that cannot be fixed in enumitem module.
Maybe the code for short title (i.e. optional arguments) insets could
be modified.


Juergen,

Is there something like PassThru for insets arguments?

JMarc

Re: enumitem module, enumerate start= lyx bug?

[Jean-Marc Lasgouttes]

Le 17/09/13 08:33, Guenter Milde a écrit :

Using normal fonts it works, but if I use eg. small font for the list, I
get error messages, since the optional start=x argument is put inside 
\small{},
like:



\begin{enumerate}[{\small{start=3}}]



and latex chokes on this.



I think this is an enumitem module bug.


I suppose it is a limitation that cannot be fixed in enumitem module.
Maybe the code for short title (i.e. optional arguments) insets could
be modified.


Juergen,

Is there something like PassThru for insets arguments?

JMarc

Re: enumitem module, enumerate start= lyx bug?

[Jean-Marc Lasgouttes]

Le 17/09/13 08:33, Guenter Milde a écrit :

Using normal fonts it works, but if I use eg. small font for the list, I
get error messages, since the optional "start=x" argument is put inside 
\small{},
like:



\begin{enumerate}[{\small{start=3}}]



and latex chokes on this.



I think this is an enumitem module bug.


I suppose it is a limitation that cannot be fixed in enumitem module.
Maybe the code for "short title" (i.e. optional arguments) insets could
be modified.


Juergen,

Is there something like PassThru for insets arguments?

JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

26/08/2013 18:41, John Kane:

This is very amusing indeed. Do they describe this particular obsession
in their catalog of mental illnesses? At least they dropped the
'underscore instead of emphasize' madness some time ago.


They don't have acatalog of mental illnesses. That's the American
Psychiatric Association you're thinking of.


I stand corrected. I plead a trauma after trying to format a paper for a 
cognitive psychology journal on behalf of my wife :)


JMarc

Re: error in LyX with Turkish language using knitr

[Jean-Marc Lasgouttes]

30/08/2013 18:26, Yihui Xie:

I can reproduce the problem after I enable babel in the document.
Normally I disable it because it often causes me trouble for unknown
reasons. To disable it globally: Preferences--Language
Settings--Language package--None. Or disable it only for this
document: Document--Settings--Language--Language package--None.

Without babel, it compiles fine.


From the top of my head, problems with turkish include

1/ in Turkish locale, `I' is not the uppercase of `i', because dotted 
and dotless versions of this letter exist.


2/ there is a common problem with babel due to the fact that the = 
character is made active. This breaks in particular the keyval package. 
See bug 2005 for background.

http://www.lyx.org/trac/ticket/2005

JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

26/08/2013 18:41, John Kane:

This is very amusing indeed. Do they describe this particular obsession
in their catalog of mental illnesses? At least they dropped the
'underscore instead of emphasize' madness some time ago.


They don't have acatalog of mental illnesses. That's the American
Psychiatric Association you're thinking of.


I stand corrected. I plead a trauma after trying to format a paper for a 
cognitive psychology journal on behalf of my wife :)


JMarc

Re: error in LyX with Turkish language using knitr

[Jean-Marc Lasgouttes]

30/08/2013 18:26, Yihui Xie:

I can reproduce the problem after I enable babel in the document.
Normally I disable it because it often causes me trouble for unknown
reasons. To disable it globally: Preferences--Language
Settings--Language package--None. Or disable it only for this
document: Document--Settings--Language--Language package--None.

Without babel, it compiles fine.


From the top of my head, problems with turkish include

1/ in Turkish locale, `I' is not the uppercase of `i', because dotted 
and dotless versions of this letter exist.


2/ there is a common problem with babel due to the fact that the = 
character is made active. This breaks in particular the keyval package. 
See bug 2005 for background.

http://www.lyx.org/trac/ticket/2005

JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

26/08/2013 18:41, John Kane:

This is very amusing indeed. Do they describe this particular obsession
in their catalog of mental illnesses? At least they dropped the
'underscore instead of emphasize' madness some time ago.


They don't have acatalog of mental illnesses. That's the American
Psychiatric Association you're thinking of.


I stand corrected. I plead a trauma after trying to format a paper for a 
cognitive psychology journal on behalf of my wife :)


JMarc

Re: error in LyX with Turkish language using knitr

[Jean-Marc Lasgouttes]

30/08/2013 18:26, Yihui Xie:

I can reproduce the problem after I enable babel in the document.
Normally I disable it because it often causes me trouble for unknown
reasons. To disable it globally: Preferences-->Language
Settings-->Language package-->None. Or disable it only for this
document: Document-->Settings-->Language-->Language package-->None.

Without babel, it compiles fine.


From the top of my head, problems with turkish include

1/ in Turkish locale, `I' is not the uppercase of `i', because dotted 
and dotless versions of this letter exist.


2/ there is a common problem with babel due to the fact that the = 
character is made active. This breaks in particular the keyval package. 
See bug 2005 for background.

http://www.lyx.org/trac/ticket/2005

JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

Le 24/08/2013 16:13, John Kane a écrit :

I found a discussion of exactly that issue on a Zotero forum and came
across a reference to the American Psychology Association blog that, as
far as I can see, is almost exclusively devoted to advice on how to deal
with the Publication Manual of the American Psychological Association.


This is very amusing indeed. Do they describe this particular obsession 
in their catalog of mental illnesses? At least they dropped the 
'underscore instead of emphasize' madness some time ago.


JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

Le 24/08/2013 16:13, John Kane a écrit :

I found a discussion of exactly that issue on a Zotero forum and came
across a reference to the American Psychology Association blog that, as
far as I can see, is almost exclusively devoted to advice on how to deal
with the Publication Manual of the American Psychological Association.


This is very amusing indeed. Do they describe this particular obsession 
in their catalog of mental illnesses? At least they dropped the 
'underscore instead of emphasize' madness some time ago.


JMarc

Re: The tyranny of the APA Manual (more or less on topic)

[Jean-Marc Lasgouttes]

Le 24/08/2013 16:13, John Kane a écrit :

I found a discussion of exactly that issue on a Zotero forum and came
across a reference to the American Psychology Association blog that, as
far as I can see, is almost exclusively devoted to advice on how to deal
with the Publication Manual of the American Psychological Association.


This is very amusing indeed. Do they describe this particular obsession 
in their catalog of mental illnesses? At least they dropped the 
'underscore instead of emphasize' madness some time ago.


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

22/08/2013 21:09, Steve Litt of Troubleshooters.Com:

Yeah, now that you mention it, I remember KLyX. Thank you, thank you,
THANK YOU for winning that battle!


The problem was not only around KDE (although there were ideological 
ideas behind this port that we did not share), but rather that we were 
very busy at that time turning the code base into something usable. The 
original implementations of footnotes and and tabulars were, err, 
interesting :) The priority was clearly not in a shiny interface.


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

22/08/2013 21:09, Steve Litt of Troubleshooters.Com:

Yeah, now that you mention it, I remember KLyX. Thank you, thank you,
THANK YOU for winning that battle!


The problem was not only around KDE (although there were ideological 
ideas behind this port that we did not share), but rather that we were 
very busy at that time turning the code base into something usable. The 
original implementations of footnotes and and tabulars were, err, 
interesting :) The priority was clearly not in a shiny interface.


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

22/08/2013 21:09, Steve Litt of Troubleshooters.Com:

Yeah, now that you mention it, I remember KLyX. Thank you, thank you,
THANK YOU for winning that battle!


The problem was not only around KDE (although there were ideological 
ideas behind this port that we did not share), but rather that we were 
very busy at that time turning the code base into something usable. The 
original implementations of footnotes and and tabulars were, err, 
interesting :) The priority was clearly not in a shiny interface.


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

Le 22/08/13 20:42, Steve Litt of Troubleshooters.Com a écrit :

In the history of LyX, did anyone campaign for it to be a KDE app, and
if so, how was that (in my opinion mistake) prevented?


This is KLyX, a fork attempted by Matthias without telling us. But we 
won in the end :)


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

Le 22/08/13 20:42, Steve Litt of Troubleshooters.Com a écrit :

In the history of LyX, did anyone campaign for it to be a KDE app, and
if so, how was that (in my opinion mistake) prevented?


This is KLyX, a fork attempted by Matthias without telling us. But we 
won in the end :)


JMarc

Re: Question: Using LyX as your daily word processor

[Jean-Marc Lasgouttes]

Le 22/08/13 20:42, Steve Litt of Troubleshooters.Com a écrit :

In the history of LyX, did anyone campaign for it to be a KDE app, and
if so, how was that (in my opinion mistake) prevented?


This is KLyX, a fork attempted by Matthias without telling us. But we 
won in the end :)


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

23/07/2013 01:31, Scott Kostyshak:

+1. Do you also think we should get rid of OK vs Apply? For example,
http://www.lyx.org/trac/ticket/3964


Yes, but someone's got to do it :)

JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

23/07/2013 01:31, Scott Kostyshak:

+1. Do you also think we should get rid of OK vs Apply? For example,
http://www.lyx.org/trac/ticket/3964


Yes, but someone's got to do it :)

JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

23/07/2013 01:31, Scott Kostyshak:

+1. Do you also think we should get rid of OK vs Apply? For example,
http://www.lyx.org/trac/ticket/3964


Yes, but someone's got to do it :)

JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

22/07/2013 10:29, Alexandre de S. Thiago Lemke:

Have no idea how to call LyX on terminal. It was a drag'n'drop install.


Something like (from memory):

/Application/LyX.app/Contents/MacOSX/lyx

Do you have support for English language installed on your mac?

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

22/07/2013 16:34, Richard Heck:

Steve, you can copy the stdmenus.inc file into your local LyX user
directory, e.g., to
 ~/.lyx/ui/stdmenus.inc
LyX will then use your local version, and you do not have to modify the
system version.


I think that creating a dummy file that includes default.ui and then 
does other things is safer. Otherwise, your stdmenus.inc file will be 
obsolete every time LyX gets updated.


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

Le 23/07/13 00:09, Alexandre de S. Thiago Lemke a écrit :

Oh! I was hitting apply. LyX only have European Portuguese and the EP
and BP words for save are different. I totally miss the button.

Now everything is working fine. There was no bug, just idiomatic
misleading.


I think we should get rid of this Save vs. Apply thing. Prefs should 
always be saved.


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

22/07/2013 10:29, Alexandre de S. Thiago Lemke:

Have no idea how to call LyX on terminal. It was a drag'n'drop install.


Something like (from memory):

/Application/LyX.app/Contents/MacOSX/lyx

Do you have support for English language installed on your mac?

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

22/07/2013 16:34, Richard Heck:

Steve, you can copy the stdmenus.inc file into your local LyX user
directory, e.g., to
 ~/.lyx/ui/stdmenus.inc
LyX will then use your local version, and you do not have to modify the
system version.


I think that creating a dummy file that includes default.ui and then 
does other things is safer. Otherwise, your stdmenus.inc file will be 
obsolete every time LyX gets updated.


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

Le 23/07/13 00:09, Alexandre de S. Thiago Lemke a écrit :

Oh! I was hitting apply. LyX only have European Portuguese and the EP
and BP words for save are different. I totally miss the button.

Now everything is working fine. There was no bug, just idiomatic
misleading.


I think we should get rid of this Save vs. Apply thing. Prefs should 
always be saved.


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

22/07/2013 10:29, Alexandre de S. Thiago Lemke:

Have no idea how to call LyX on terminal. It was a drag'n'drop install.


Something like (from memory):

/Application/LyX.app/Contents/MacOSX/lyx

Do you have support for English language installed on your mac?

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

22/07/2013 16:34, Richard Heck:

Steve, you can copy the stdmenus.inc file into your local LyX user
directory, e.g., to
 ~/.lyx/ui/stdmenus.inc
LyX will then use your local version, and you do not have to modify the
system version.


I think that creating a dummy file that includes default.ui and then 
does other things is safer. Otherwise, your stdmenus.inc file will be 
obsolete every time LyX gets updated.


JMarc

Re: Changing LyX language

[Jean-Marc Lasgouttes]

Le 23/07/13 00:09, Alexandre de S. Thiago Lemke a écrit :

Oh! I was hitting apply. LyX only have European Portuguese and the EP
and BP words for "save" are different. I totally miss the button.

Now everything is working fine. There was no bug, just idiomatic
misleading.


I think we should get rid of this Save vs. Apply thing. Prefs should 
always be saved.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 02:39, Andrew Parsloe a écrit :

I find it convenient to also have a shortcut to jump out of an inset.
The right arrow key is a bit of a stretch and I like to have something
lying more naturally under the fingers. I use Ctrl+J (J for Jump) for
that purpose, assigned to


What's wrong with Ctrl+I? Is it because it goes to the left of the 
inset? I think we have a bug about changing that so that the cursor is 
after the inset.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 00:56, Steve Litt a écrit :

You know what I'd like to see? For starters, put Customize, Capitalize,
Uppercase, Lowercase, and Dissolve somewhere else, leaving only true
character styles on the Alt+E,S menu. Second, code the Alt+E,S menu so
typing a letter would move the highlight to the next character
style beginning with that letter. That would start to make applying
character styles a reflex that doesn't interfere with thought about
content. For extra credit, have a single hotkey bring up the floating
menu of character styles.


For the shortcut solution, I think you can do it by yourself: bind some 
key to menu-open charstyles, where the menu is defined as


Menu charstyles
CharStyles
Separator
Elements
End

For selecting by typing, we need something like a combox. However this 
is not really adapted to _inserting_ something.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 12:53, Steve Litt a écrit :

In which file do I define the menu this way?


Here is what I would try : create a file mydefault.ui

Format 1

Include default.ui

Menu charstyles
CharStyles
Separator
Elements
End

Put the file in the ui/ subdirectory of your lyx user directory.

Then in Preferences dialog, User Interface pane, type mydefault as UI 
file name.


Note that I never tried this myself...

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 13:21, Steve Litt a écrit :

My only question is this: Other than
modifying /usr/share/lyx/ui/stdmenus.inc, what file can I put it in? I'd
like to modify some file under my home directory so it survives LyX
upgrades.


It seems that I anwered 1 minute too late :) Is it clearer with my other 
message?


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 20:30, Steve Litt a écrit :

Anyway, today I'm going to try almost exactly what you suggested,
except I'm not going to include the separator or the elements. I want
this thing to be 100% pure character styles and nothing else. If it
works, this is going to significantly speed up my work.


I was not sure what Elements are, so I kept them :) And for good measure 
I put a separator there, just in case...


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 23:41, Steve Litt a écrit :

Elements are, as I remember, that thing where you can apply italics, or
small caps, or bold, etc with radio buttons. In other words,
fingerpainting without ERT. The sworn enemy of WYSIWYM.


This prompted me to actually read the source. Elements are one of the 
three kinds of Flex insets: Elements (for HTML?), CharStyles and Custom.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 02:39, Andrew Parsloe a écrit :

I find it convenient to also have a shortcut to jump out of an inset.
The right arrow key is a bit of a stretch and I like to have something
lying more naturally under the fingers. I use Ctrl+J (J for Jump) for
that purpose, assigned to


What's wrong with Ctrl+I? Is it because it goes to the left of the 
inset? I think we have a bug about changing that so that the cursor is 
after the inset.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 00:56, Steve Litt a écrit :

You know what I'd like to see? For starters, put Customize, Capitalize,
Uppercase, Lowercase, and Dissolve somewhere else, leaving only true
character styles on the Alt+E,S menu. Second, code the Alt+E,S menu so
typing a letter would move the highlight to the next character
style beginning with that letter. That would start to make applying
character styles a reflex that doesn't interfere with thought about
content. For extra credit, have a single hotkey bring up the floating
menu of character styles.


For the shortcut solution, I think you can do it by yourself: bind some 
key to menu-open charstyles, where the menu is defined as


Menu charstyles
CharStyles
Separator
Elements
End

For selecting by typing, we need something like a combox. However this 
is not really adapted to _inserting_ something.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 12:53, Steve Litt a écrit :

In which file do I define the menu this way?


Here is what I would try : create a file mydefault.ui

Format 1

Include default.ui

Menu charstyles
CharStyles
Separator
Elements
End

Put the file in the ui/ subdirectory of your lyx user directory.

Then in Preferences dialog, User Interface pane, type mydefault as UI 
file name.


Note that I never tried this myself...

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 13:21, Steve Litt a écrit :

My only question is this: Other than
modifying /usr/share/lyx/ui/stdmenus.inc, what file can I put it in? I'd
like to modify some file under my home directory so it survives LyX
upgrades.


It seems that I anwered 1 minute too late :) Is it clearer with my other 
message?


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 20:30, Steve Litt a écrit :

Anyway, today I'm going to try almost exactly what you suggested,
except I'm not going to include the separator or the elements. I want
this thing to be 100% pure character styles and nothing else. If it
works, this is going to significantly speed up my work.


I was not sure what Elements are, so I kept them :) And for good measure 
I put a separator there, just in case...


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 23:41, Steve Litt a écrit :

Elements are, as I remember, that thing where you can apply italics, or
small caps, or bold, etc with radio buttons. In other words,
fingerpainting without ERT. The sworn enemy of WYSIWYM.


This prompted me to actually read the source. Elements are one of the 
three kinds of Flex insets: Elements (for HTML?), CharStyles and Custom.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 02:39, Andrew Parsloe a écrit :

I find it convenient to also have a shortcut to jump out of an inset.
The right arrow key is a bit of a stretch and I like to have something
lying more naturally under the fingers. I use Ctrl+J (J for Jump) for
that purpose, assigned to


What's wrong with Ctrl+I? Is it because it goes to the left of the 
inset? I think we have a bug about changing that so that the cursor is 
after the inset.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 00:56, Steve Litt a écrit :

You know what I'd like to see? For starters, put Customize, Capitalize,
Uppercase, Lowercase, and Dissolve somewhere else, leaving only true
character styles on the Alt+E,S menu. Second, code the Alt+E,S menu so
typing a letter would move the highlight to the next character
style beginning with that letter. That would start to make applying
character styles a reflex that doesn't interfere with thought about
content. For extra credit, have a single hotkey bring up the floating
menu of character styles.


For the shortcut solution, I think you can do it by yourself: bind some 
key to "menu-open charstyles", where the menu is defined as


Menu "charstyles"
CharStyles
Separator
Elements
End

For selecting by typing, we need something like a combox. However this 
is not really adapted to _inserting_ something.


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 12:53, Steve Litt a écrit :

In which file do I define the menu this way?


Here is what I would try : create a file mydefault.ui

Format 1

Include "default.ui"

Menu "charstyles"
CharStyles
Separator
Elements
End

Put the file in the ui/ subdirectory of your lyx user directory.

Then in Preferences dialog, User Interface pane, type "mydefault" as UI 
file name.


Note that I never tried this myself...

JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 13:21, Steve Litt a écrit :

My only question is this: Other than
modifying /usr/share/lyx/ui/stdmenus.inc, what file can I put it in? I'd
like to modify some file under my home directory so it survives LyX
upgrades.


It seems that I anwered 1 minute too late :) Is it clearer with my other 
message?


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 20:30, Steve Litt a écrit :

Anyway, today I'm going to try almost exactly what you suggested,
except I'm not going to include the separator or the elements. I want
this thing to be 100% pure character styles and nothing else. If it
works, this is going to significantly speed up my work.


I was not sure what Elements are, so I kept them :) And for good measure 
I put a separator there, just in case...


JMarc

Re: LyX needs a quicker way to apply character styles

[Jean-Marc Lasgouttes]

Le 21/07/2013 23:41, Steve Litt a écrit :

Elements are, as I remember, that thing where you can apply italics, or
small caps, or bold, etc with radio buttons. In other words,
fingerpainting without ERT. The sworn enemy of WYSIWYM.


This prompted me to actually read the source. Elements are one of the 
three kinds of Flex insets: Elements (for HTML?), CharStyles and Custom.


JMarc

Re: How can I protect Japanese names / words?

[Jean-Marc Lasgouttes]

Le 19/07/2013 23:02, Jessy a écrit :

Hello all,

I'm currently writing my thesis in Japanese studies using LyX 2.0.6
on OS X 10.6.8. The document class of my choice is koma-script book.

While my thesis is mainly written in my native German, there are some
Japanese names, terms, and place names given in the text. What's
pretty annoying is that there sometimes are line breaks inside a
name, e.g. the last character only is placed in a new line. Is there
a way to prevent LyX from doing this? I've tried to achieve it by
preventing hyphenation, but that just makes everything look terrible
and still breaks the Japanese words in between - seems they're not
actually recognized as words.


Is this problem on screen or in the resulting PDF?

JMarc

Re: How can I protect Japanese names / words?

[Jean-Marc Lasgouttes]

Le 19/07/2013 23:02, Jessy a écrit :

Hello all,

I'm currently writing my thesis in Japanese studies using LyX 2.0.6
on OS X 10.6.8. The document class of my choice is koma-script book.

While my thesis is mainly written in my native German, there are some
Japanese names, terms, and place names given in the text. What's
pretty annoying is that there sometimes are line breaks inside a
name, e.g. the last character only is placed in a new line. Is there
a way to prevent LyX from doing this? I've tried to achieve it by
preventing hyphenation, but that just makes everything look terrible
and still breaks the Japanese words in between - seems they're not
actually recognized as words.


Is this problem on screen or in the resulting PDF?

JMarc

Re: How can I "protect" Japanese names / words?

[Jean-Marc Lasgouttes]

Le 19/07/2013 23:02, Jessy a écrit :

Hello all,

I'm currently writing my thesis in Japanese studies using LyX 2.0.6
on OS X 10.6.8. The document class of my choice is koma-script book.

While my thesis is mainly written in my native German, there are some
Japanese names, terms, and place names given in the text. What's
pretty annoying is that there sometimes are line breaks inside a
name, e.g. the last character only is placed in a new line. Is there
a way to prevent LyX from doing this? I've tried to achieve it by
preventing hyphenation, but that just makes everything look terrible
and still breaks the Japanese words in between - seems they're not
actually recognized as words.


Is this problem on screen or in the resulting PDF?

JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

Le 10/07/13 22:41, Rud Faden a écrit :

Thank you very much for your reply. Sadly the result is the same. The
app just bounces and the application is not responding.


What does the console application say? If you launch it, you should see 
some relevant error messages there.


JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

Le 10/07/13 22:41, Rud Faden a écrit :

Thank you very much for your reply. Sadly the result is the same. The
app just bounces and the application is not responding.


What does the console application say? If you launch it, you should see 
some relevant error messages there.


JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

Le 10/07/13 22:41, Rud Faden a écrit :

Thank you very much for your reply. Sadly the result is the same. The
app just bounces and the application is not responding.


What does the console application say? If you launch it, you should see 
some relevant error messages there.


JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

08/07/2013 23:21, Richard Heck:


Presumably it is possible to try to launch from the command line? Any
info there?


Or maybe look in the Console.app application (assuming it still exists).

JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

08/07/2013 23:21, Richard Heck:


Presumably it is possible to try to launch from the command line? Any
info there?


Or maybe look in the Console.app application (assuming it still exists).

JMarc

Re: lyx cannot be opened in maverick os 10.9

[Jean-Marc Lasgouttes]

08/07/2013 23:21, Richard Heck:


Presumably it is possible to try to launch from the command line? Any
info there?


Or maybe look in the Console.app application (assuming it still exists).

JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 27/06/2013 08:33, Pavel Sanda a écrit :

You mean we should pay Apple in order to be graciously allowed to improve
it's software environment? Sounds like black humor to me.


OKOK

JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 27/06/2013 08:33, Pavel Sanda a écrit :

You mean we should pay Apple in order to be graciously allowed to improve
it's software environment? Sounds like black humor to me.


OKOK

JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 27/06/2013 08:33, Pavel Sanda a écrit :

You mean we should pay Apple in order to be graciously allowed to improve
it's software environment? Sounds like black humor to me.


OKOK

JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 26/06/2013 23:26, Stephan Witt a écrit :

Am 26.06.2013 um 19:36 schrieb Eric Weir eew...@bellsouth.net:



New computer. Now on OS X Mountain Lion. When I started LyX after installing it, I got a 
message saying, LyX.app can't be opened because it's from an unidentified 
developer.


It's me :)
I didn't want to pay 100$ per year.
And I didn't want to sign a contract I don't understand 100%.


Shall LyX funds pay for that? If the contract part is not a problem, it 
would be a good solution.


JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 26/06/2013 23:26, Stephan Witt a écrit :

Am 26.06.2013 um 19:36 schrieb Eric Weir eew...@bellsouth.net:



New computer. Now on OS X Mountain Lion. When I started LyX after installing it, I got a 
message saying, LyX.app can't be opened because it's from an unidentified 
developer.


It's me :)
I didn't want to pay 100$ per year.
And I didn't want to sign a contract I don't understand 100%.


Shall LyX funds pay for that? If the contract part is not a problem, it 
would be a good solution.


JMarc

Re: LyX.app can't be opened

[Jean-Marc Lasgouttes]

Le 26/06/2013 23:26, Stephan Witt a écrit :

Am 26.06.2013 um 19:36 schrieb Eric Weir :



New computer. Now on OS X Mountain Lion. When I started LyX after installing it, I got a 
message saying, "LyX.app can't be opened because it's from an unidentified 
developer."


It's me :)
I didn't want to pay 100$ per year.
And I didn't want to sign a contract I don't understand 100%.


Shall LyX funds pay for that? If the contract part is not a problem, it 
would be a good solution.


JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 18:35, Richard Heck:

Span is more or less allowed everywhere. Of course, span is by default
inline. But you can get it to act like a div by setting display:block in
CSS. Cheating, no doubt.


So a span is designed to be included in the flow of the text, like a 
footnote is... Why is that cheating?


JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 18:35, Richard Heck:

Span is more or less allowed everywhere. Of course, span is by default
inline. But you can get it to act like a div by setting display:block in
CSS. Cheating, no doubt.


So a span is designed to be included in the flow of the text, like a 
footnote is... Why is that cheating?


JMarc

Re: Why in HTML exports instead of ?

[Jean-Marc Lasgouttes]

06/06/2013 18:35, Richard Heck:

Span is more or less allowed everywhere. Of course, span is by default
inline. But you can get it to act like a div by setting display:block in
CSS. Cheating, no doubt.


So a span is designed to be included in the flow of the text, like a 
footnote is... Why is that cheating?


JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 15:47, Richard Heck:

That said, the reason it is done this way is because the default
layout, Standard, is used inside other kinds of things, where p
would not be allowed. At least, I seem to remember that is why I did
it that way.


It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.

And what about h1/h2/h3... ?

JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 16:02, Richard Heck:

It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.


The use of div for paragraphs is not unusual. One sees it quite alot on the
web.


I can also find lots of interesting MSword documenta on the web :) It is 
a matter of semantics

http://stackoverflow.com/questions/2226562/what-is-the-difference-between-p-and-div

[do philosophers care about semantics?]


And what about h1/h2/h3... ?


This was just wrong. h1 is used for both part and chapter, with different
classes. h2 is used for sections, h3 for subsections, etc. See
stdsections.inc
for the details, all of which, again, can be modified via layout.


Good.

JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 16:33, Richard Heck:

Here's an example of what led to this:

p class=standardThis is a paragraph.div class=footnotep
class=standardThis is a footnote./pp class=standardWith two
paragraphs./p/div Rest of paragraph./p

That is invalid. Whereas if you replace p with div it is fine.


Which p? The inner one?


Again, we could try to detect this, but it's hard to know how to do it
without making assumptions. What if someone did use div for Standard?
Then there is nothing to detect.

It starts to feel like we need to code the entire DTD and check
everything we do against it.


This is not nice indeed.


For what it's worth, really solving the problem of footnotes inside
headings (div not allowed inside h2, e.g.) may require enough machinery
to do this too. The div paragraphs inside the footnote (which now has to
be treated as span) won't be permitted either.


What is the difference between div and span in in this case?

JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 15:47, Richard Heck:

That said, the reason it is done this way is because the default
layout, Standard, is used inside other kinds of things, where p
would not be allowed. At least, I seem to remember that is why I did
it that way.


It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.

And what about h1/h2/h3... ?

JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 16:02, Richard Heck:

It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.


The use of div for paragraphs is not unusual. One sees it quite alot on the
web.


I can also find lots of interesting MSword documenta on the web :) It is 
a matter of semantics

http://stackoverflow.com/questions/2226562/what-is-the-difference-between-p-and-div

[do philosophers care about semantics?]


And what about h1/h2/h3... ?


This was just wrong. h1 is used for both part and chapter, with different
classes. h2 is used for sections, h3 for subsections, etc. See
stdsections.inc
for the details, all of which, again, can be modified via layout.


Good.

JMarc

Re: Why div in HTML exports instead of p?

[Jean-Marc Lasgouttes]

06/06/2013 16:33, Richard Heck:

Here's an example of what led to this:

p class=standardThis is a paragraph.div class=footnotep
class=standardThis is a footnote./pp class=standardWith two
paragraphs./p/div Rest of paragraph./p

That is invalid. Whereas if you replace p with div it is fine.


Which p? The inner one?


Again, we could try to detect this, but it's hard to know how to do it
without making assumptions. What if someone did use div for Standard?
Then there is nothing to detect.

It starts to feel like we need to code the entire DTD and check
everything we do against it.


This is not nice indeed.


For what it's worth, really solving the problem of footnotes inside
headings (div not allowed inside h2, e.g.) may require enough machinery
to do this too. The div paragraphs inside the footnote (which now has to
be treated as span) won't be permitted either.


What is the difference between div and span in in this case?

JMarc

Re: Why in HTML exports instead of ?

[Jean-Marc Lasgouttes]

06/06/2013 15:47, Richard Heck:

That said, the reason it is done this way is because the default
layout, Standard, is used inside other kinds of things, where "p"
would not be allowed. At least, I seem to remember that is why I did
it that way.


It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.

And what about h1/h2/h3... ?

JMarc

Re: Why in HTML exports instead of ?

[Jean-Marc Lasgouttes]

06/06/2013 16:02, Richard Heck:

It would be nice to document what the reason really was. I agree with
Steve that outputting propper HTML is very important, in particular if
we plan to import it in other formats.


The use of div for paragraphs is not unusual. One sees it quite alot on the
web.


I can also find lots of interesting MSword documenta on the web :) It is 
a matter of semantics

http://stackoverflow.com/questions/2226562/what-is-the-difference-between-p-and-div

[do philosophers care about semantics?]


And what about h1/h2/h3... ?


This was just wrong. h1 is used for both part and chapter, with different
classes. h2 is used for sections, h3 for subsections, etc. See
stdsections.inc
for the details, all of which, again, can be modified via layout.


Good.

JMarc

Re: Why in HTML exports instead of ?

[Jean-Marc Lasgouttes]

06/06/2013 16:33, Richard Heck:

Here's an example of what led to this:

This is a paragraph.This is a footnote.With two
paragraphs. Rest of paragraph.

That is invalid. Whereas if you replace "p" with "div" it is fine.


Which ? The inner one?


Again, we could try to detect this, but it's hard to know how to do it
without making assumptions. What if someone did use "div" for Standard?
Then there is nothing to detect.

It starts to feel like we need to code the entire DTD and check
everything we do against it.


This is not nice indeed.


For what it's worth, really solving the problem of footnotes inside
headings (div not allowed inside h2, e.g.) may require enough machinery
to do this too. The div paragraphs inside the footnote (which now has to
be treated as span) won't be permitted either.


What is the difference between div and span in in this case?

JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

26/05/2013 03:32, David L. Johnson:

Here is what I mean.  I started the section, then immediately went into
a multiline equation envoronment, and got the error of TeX capacity
exceeded.   I've learned over the years to look for this whenever I get
that error.


Hello David,

This is not what was described above IMO. This was a case where LyX 
crashes with an exception with a string too long. A kind of LyX 
capacity exceeded, if you prefer :)


However, I have never seen something like that, and I am sure it comes 
from a bad bug in the code. This is why I would like to pinpoint it.


JMarc

Re: AW: String is too long ...?

[Jean-Marc Lasgouttes]

27/05/2013 10:07, Rilke Rainer Michael:

Hallo,

thank you for your comments. Eventually, an update of all the miktex packages 
and the lyx version (to 2.0.6) did it.


Too bad, in some way... I really would have liked to be able to see this 
bug in action. We'll see whether it returns (hopefully for you, not on 
your system!)


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

26/05/2013 03:32, David L. Johnson:

Here is what I mean.  I started the section, then immediately went into
a multiline equation envoronment, and got the error of TeX capacity
exceeded.   I've learned over the years to look for this whenever I get
that error.


Hello David,

This is not what was described above IMO. This was a case where LyX 
crashes with an exception with a string too long. A kind of LyX 
capacity exceeded, if you prefer :)


However, I have never seen something like that, and I am sure it comes 
from a bad bug in the code. This is why I would like to pinpoint it.


JMarc

Re: AW: String is too long ...?

[Jean-Marc Lasgouttes]

27/05/2013 10:07, Rilke Rainer Michael:

Hallo,

thank you for your comments. Eventually, an update of all the miktex packages 
and the lyx version (to 2.0.6) did it.


Too bad, in some way... I really would have liked to be able to see this 
bug in action. We'll see whether it returns (hopefully for you, not on 
your system!)


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

26/05/2013 03:32, David L. Johnson:

Here is what I mean.  I started the section, then immediately went into
a multiline equation envoronment, and got the error of "TeX capacity
exceeded".   I've learned over the years to look for this whenever I get
that error.


Hello David,

This is not what was described above IMO. This was a case where LyX 
crashes with an exception with a string too long. A kind of "LyX 
capacity exceeded", if you prefer :)


However, I have never seen something like that, and I am sure it comes 
from a bad bug in the code. This is why I would like to pinpoint it.


JMarc

Re: AW: String is too long ...?

[Jean-Marc Lasgouttes]

27/05/2013 10:07, Rilke Rainer Michael:

Hallo,

thank you for your comments. Eventually, an update of all the miktex packages 
and the lyx version (to 2.0.6) did it.


Too bad, in some way... I really would have liked to be able to see this 
bug in action. We'll see whether it returns (hopefully for you, not on 
your system!)


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 08:00, Rainer Michael Rilke a écrit :

Hallo, I am working with a co author on a lyx file. This file is located
in a dropbox folder. Everything worked out fine for the last month. But
recently, although I only changed thing in the text (nothing
substantial) my co author is unable to open the lyx file. He receives an
error message: exception: string too long... What could this possibly
mean?


This looks really weird. Can we have the complete error message?

JMarc

Re: testing compiled lyx 2.0.6

[Jean-Marc Lasgouttes]

Le 25/05/13 17:54, Steve Litt a écrit :

Why is what you did above any better than ./configure; make; make
install from lyxhome itself? I didn't even know the separate build
directory could be done. Do you recommend the separate build directory
for compiling all programs where you need
to ./configure;make;make_install?


I would recommend building out of source tree any package. Package which 
do not support this are buggy IMO. In theory, you can set your source 
directory tree to read-only and still compile.


The advantage is that starting from scratch is trivial. This is even 
more important when compiling from a git check out, where you do not 
want old file to cause problems. In this case a rm -rf * (or the 
windows equivalent that I forgot (deltree?)), will start over cleanly.


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 22:06, David L. Johnson a écrit :

As a guess, look for some displayed equation or something similar which
is accidentally in a section-style environment.  Every time I have
seen a similar message that was the culprit.  Look at those areas where
you made changes just to be sure everything is in the correct environment.


I would be very interested by a reproducible case. If you can share a 
document, even privately, we are interested.


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 08:00, Rainer Michael Rilke a écrit :

Hallo, I am working with a co author on a lyx file. This file is located
in a dropbox folder. Everything worked out fine for the last month. But
recently, although I only changed thing in the text (nothing
substantial) my co author is unable to open the lyx file. He receives an
error message: exception: string too long... What could this possibly
mean?


This looks really weird. Can we have the complete error message?

JMarc

Re: testing compiled lyx 2.0.6

[Jean-Marc Lasgouttes]

Le 25/05/13 17:54, Steve Litt a écrit :

Why is what you did above any better than ./configure; make; make
install from lyxhome itself? I didn't even know the separate build
directory could be done. Do you recommend the separate build directory
for compiling all programs where you need
to ./configure;make;make_install?


I would recommend building out of source tree any package. Package which 
do not support this are buggy IMO. In theory, you can set your source 
directory tree to read-only and still compile.


The advantage is that starting from scratch is trivial. This is even 
more important when compiling from a git check out, where you do not 
want old file to cause problems. In this case a rm -rf * (or the 
windows equivalent that I forgot (deltree?)), will start over cleanly.


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 22:06, David L. Johnson a écrit :

As a guess, look for some displayed equation or something similar which
is accidentally in a section-style environment.  Every time I have
seen a similar message that was the culprit.  Look at those areas where
you made changes just to be sure everything is in the correct environment.


I would be very interested by a reproducible case. If you can share a 
document, even privately, we are interested.


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 08:00, Rainer Michael Rilke a écrit :

Hallo, I am working with a co author on a lyx file. This file is located
in a dropbox folder. Everything worked out fine for the last month. But
recently, although I only changed thing in the text (nothing
substantial) my co author is unable to open the lyx file. He receives an
error message: "exception: string too long..." What could this possibly
mean?


This looks really weird. Can we have the complete error message?

JMarc

Re: testing compiled lyx 2.0.6

[Jean-Marc Lasgouttes]

Le 25/05/13 17:54, Steve Litt a écrit :

Why is what you did above any better than ./configure; make; make
install from lyxhome itself? I didn't even know the separate build
directory could be done. Do you recommend the separate build directory
for compiling all programs where you need
to ./configure;make;make_install?


I would recommend building out of source tree any package. Package which 
do not support this are buggy IMO. In theory, you can set your source 
directory tree to read-only and still compile.


The advantage is that starting from scratch is trivial. This is even 
more important when compiling from a git check out, where you do not 
want old file to cause problems. In this case a "rm -rf *" (or the 
windows equivalent that I forgot (deltree?)), will start over cleanly.


JMarc

Re: String is too long ...?

[Jean-Marc Lasgouttes]

Le 25/05/13 22:06, David L. Johnson a écrit :

As a guess, look for some displayed equation or something similar which
is accidentally in a "section"-style environment.  Every time I have
seen a similar message that was the culprit.  Look at those areas where
you made changes just to be sure everything is in the correct environment.


I would be very interested by a reproducible case. If you can share a 
document, even privately, we are interested.


JMarc

Re: LyX 2.06

[Jean-Marc Lasgouttes]

Le 09/05/2013 09:53, Alain Didierjean a écrit :

I just installed lyx 2.06 on my gentoo computer. The problem is I
can't find any reference to this version on the lyx website, the last
being cited is 2.05.1. What about 2.06 ? stable ? new features ?


Hello,

It will be release today probably, but it has been tagged a couple days 
ago. This is why you see it on gentoo presumably.


JMarc