Re: Problem with message "The file ... changed on disk."

2018-04-17 Thread racoon

On 08/04/2018 04:17, Richard Kimberly Heck wrote:

On 04/07/2018 06:13 PM, Scott Kostyshak wrote:

On Fri, Apr 06, 2018 at 10:47:29PM +, Richard Kimberly Heck wrote:

On 04/06/2018 04:03 AM, racoon wrote:

Hi,

I am getting the message "The file ... changed on disk." even though I
just saved the file a minute ago or so and it isn't opened anywhere
else. My hunch is that it relates to the syncing with Spider Oak. Did
anyone experience a similar problem or know what's going on?

That seems likely. Did the timestamp change?

Not sure how useful it is, but I tested (on Linux) and if I have the
.lyx file open and just use the touch command externally, I am not given
the message.


Wild guess on my part, and apparently not a good one.

I suppose the first thing to do is to turn off Spider Oak's autosync and
see if that makes the problem
go away.


With Spider Oak tuned off I did not get the messages and they reappeared 
once it was turned on again.


Daniel





Re: Problem with message "The file ... changed on disk."

2018-04-17 Thread racoon

On 16/04/2018 21:01, Richard Kimberly Heck wrote:

On 04/14/2018 05:38 PM, Scott Kostyshak wrote:

On Sun, Apr 08, 2018 at 02:17:22AM +, Richard Kimberly Heck wrote:


I suppose the first thing to do is to turn off Spider Oak's autosync and
see if that makes the problem
go away.

Racoon, does the above make the problem go away? It would be nice to
know, just make sure that this is the problem.

Also, after a Spider Oak sync, can you check the properties of the .lyx
file. Do they change, compared to before a Spider Oak sync?

Are you sure that the .lyx file before/after a Spider Oak sync is
identical? How did you check?


Part of the reason I'd asked about that I often seem to get surprise
recompilations when switching between git branches, even though
timestamps and files should not have changed.


I am not using any versioning system, if that was your question.

Daniel




Re: Problem with message "The file ... changed on disk."

2018-04-17 Thread racoon

On 14/04/2018 23:38, Scott Kostyshak wrote:

On Sun, Apr 08, 2018 at 02:17:22AM +, Richard Kimberly Heck wrote:


I suppose the first thing to do is to turn off Spider Oak's autosync and
see if that makes the problem
go away.


Racoon, does the above make the problem go away? It would be nice to
know, just make sure that this is the problem.

Also, after a Spider Oak sync, can you check the properties of the .lyx
file. Do they change, compared to before a Spider Oak sync?

Are you sure that the .lyx file before/after a Spider Oak sync is
identical? How did you check?


I didn't check. I have no idea how to check.

I was just guessing what the cause might be since Spider Oak is the only 
other application that does something with the files I am using.


Daniel



Re: Problem with message "The file ... changed on disk."

2018-04-11 Thread racoon

On 09/04/2018 17:36, Kornel Benko wrote:

Am Samstag, 7. April 2018 22:17:22 CEST schrieb Richard Kimberly Heck
<rikih...@lyx.org>:

On 04/07/2018 06:13 PM, Scott Kostyshak wrote:

On Fri, Apr 06, 2018 at 10:47:29PM +, Richard Kimberly Heck wrote:

On 04/06/2018 04:03 AM, racoon wrote:

Hi,

I am getting the message "The file ... changed on disk." even though I
just saved the file a minute ago or so and it isn't opened anywhere
else. My hunch is that it relates to the syncing with Spider Oak. Did
anyone experience a similar problem or know what's going on?


That seems likely. Did the timestamp change?


Not sure how useful it is, but I tested (on Linux) and if I have the
.lyx file open and just use the touch command externally, I am not given
the message.


Wild guess on my part, and apparently not a good one.

I suppose the first thing to do is to turn off Spider Oak's autosync and
see if that makes the problem
go away.

All of this seems to use QFileSystemWatcher in the background, so we are
beholden to whatever it
thinks counts as a file change. A momentary renaming or whatever seems
as if it could trigger that,
from what I can tell, and that kind of thing might well happen during
syncing. I wonder if even the
locking and unlocking that has caused other problems might trigger it?

Riki


Suppose the time settings on this two computers are different.
What would be used as time stamp, the one of the lyx-executable
or the one on which the file is stored?


I just wanted to say that LyX also asks me whether to overwrite the file 
after the "changed on disk" message is shown and I try to save. Maybe 
that helps in knowing what kind of change happened to the file.


Not sure whether I can help somehow by testing something particular. 
Please let me know if so.


Daniel



Re: Problem with message "The file ... changed on disk."

2018-04-07 Thread racoon
Do you happen to know whether there is a way to turn this feature in LyX 
off?


On 07/04/2018 16:02, Richard Kimberly Heck wrote:

On 04/07/2018 09:46 AM, racoon wrote:

On 07/04/2018 15:42, Richard Kimberly Heck wrote:

On 04/07/2018 04:31 AM, racoon wrote:

On 07.04.2018 00:47, Richard Kimberly Heck wrote:

On 04/06/2018 04:03 AM, racoon wrote:

Hi,

I am getting the message "The file ... changed on disk." even
though I
just saved the file a minute ago or so and it isn't opened anywhere
else. My hunch is that it relates to the syncing with Spider Oak. Did
anyone experience a similar problem or know what's going on?


That seems likely. Did the timestamp change?


I don't know how to figure that out. Wouldn't it be strange if syncing
changes the timestamp?


Not necessarily. It very much depends upon how Spider Oak is working.


If it is not totally strange for a syncing app to work that way, does
that mean LyX's check for file changes is problematic?


Possibly. I think we may depend upon both the timestamp and a hash of
the file, but I'm not sure.

Riki



Re: Problem with message "The file ... changed on disk."

2018-04-07 Thread racoon

On 07/04/2018 15:42, Richard Kimberly Heck wrote:

On 04/07/2018 04:31 AM, racoon wrote:

On 07.04.2018 00:47, Richard Kimberly Heck wrote:

On 04/06/2018 04:03 AM, racoon wrote:

Hi,

I am getting the message "The file ... changed on disk." even though I
just saved the file a minute ago or so and it isn't opened anywhere
else. My hunch is that it relates to the syncing with Spider Oak. Did
anyone experience a similar problem or know what's going on?


That seems likely. Did the timestamp change?


I don't know how to figure that out. Wouldn't it be strange if syncing
changes the timestamp?


Not necessarily. It very much depends upon how Spider Oak is working.


If it is not totally strange for a syncing app to work that way, does 
that mean LyX's check for file changes is problematic?


Daniel




Re: Problem with message "The file ... changed on disk."

2018-04-07 Thread racoon

On 07.04.2018 00:47, Richard Kimberly Heck wrote:

On 04/06/2018 04:03 AM, racoon wrote:

Hi,

I am getting the message "The file ... changed on disk." even though I
just saved the file a minute ago or so and it isn't opened anywhere
else. My hunch is that it relates to the syncing with Spider Oak. Did
anyone experience a similar problem or know what's going on?


That seems likely. Did the timestamp change?


I don't know how to figure that out. Wouldn't it be strange if syncing 
changes the timestamp?


Daniel



Re: Update on 2.3.0 situation and Windows-specific issues

2018-04-06 Thread racoon

On 06.04.2018 11:18, Jean-Marc Lasgouttes wrote:

Le 06/04/2018 à 00:40, Uwe Stöhr a écrit :

Am 05.04.2018 um 04:47 schrieb Scott Kostyshak:


In my opinion it is that important, because updating LyX could break
something else on a user's computer.


No! Why do you claim this again? Don't mix potential bugs in a LaTeX 
package on CTAN with LyX. With this argumentation every package update 
could introduce bugs. LyX is not responsible for bugs on CTAN.


Aren't we discussing bugs in miktex here? CTAN is a different beast, 
although living on the bleeding edge is probably a bad decision for 
"average" users.


Yet another attempt to clarify a bit (maybe just for me):

I was hoping the discussion moved past the point discussed above. If 
not, we should first try to answer the following question:


(Q1) Does installing a new version of (or update) MiKTeX can break the 
compilation of LaTeX documents that were compiled fine before (because 
it can introduce bugs that an already installed previous version did not 
have)?


It seemed to me that there is agreement on this. Please correct me if I 
am wrong.


Only because (Q1) can be affirmed, the second question became important:

(Q2) During installation, should there be a question asking the user 
whether to update (and, alternatively), cancel the installation?


At least two principled approaches have been suggested:

First, what I call

*the consent approach*: Yes to Q2, because LyX should not do without 
consent what can break documents that compiled fine before.


If I see it correctly, this approach was applied in previous version 
where the user could decline an update of MiKTeX (though it was 
recommended to update).


Second, what I call

*the silent approach*: No to Q2, because the LyX installation should 
automatically do what is best for (most?) unexperienced users and a 
dialog could confuse them.


Now, if I see it correctly, the matter to decide the issue is one of 
importance. It's a value judgment. And there is no dominant approach 
that is better in all respects. Notice also that one can find both what 
is best for unexperienced users *and* not to break documents that 
compiled fine before valuable. It is just that one comes out on one or 
the other side because of an overall judgment, a favorable combination 
of these values.


In so far, I think no side is being stupid by overlooking an totally 
obviously better approach. If this is correct, I think it is very 
important that everyone sees this since it helps both to understand the 
other side and not to feel like others think that one is just being stupid.


Some have tried to lessen the strength of the reasons in favor of the 
silent approach by making the dialog easier to understand. If this would 
be fully successful, then the consent approach could come closer to 
being dominant in all respects. (For example, Scott is following this line.)


On the other hand, it might be possible to lessen the reason in favor of 
the consent approach, for example, if MiKTex updates almost never break 
a LaTeX system. This might be doubted given the reason the current 
problem was arrived at.


I see the following ways forward:

1. Further trying to discuss the basic values at stake and see whether 
one approach comes out - even if not in all respects - overall 
favorable. (For example, Uwe and Jean-Marc are following this approach 
by discussing analogue cases, like starting a car.)


2. Act on a set of basic principles (like a charter) the LyX development 
should follow, if there is one. Maybe there is a rule like: Never do 
anything without consent that could break the LaTeX compilation, or 
always do what is best for the unexperienced user.


3. Use some collective method of decision making common in democracies, 
like majority or two-thirds majority (among developers). And then just 
act on it together. Obviously, decision making using vetoes would not 
work at the moment.


All other alternatives I can think of are kind of sad... but maybe I 
overlooked something.


Best,
Daniel



Problem with message "The file ... changed on disk."

2018-04-06 Thread racoon

Hi,

I am getting the message "The file ... changed on disk." even though I 
just saved the file a minute ago or so and it isn't opened anywhere 
else. My hunch is that it relates to the syncing with Spider Oak. Did 
anyone experience a similar problem or know what's going on?


As a fix I can just click on "Ignore" but it is a bit annoying.

Best,
Daniel




Re: SVG figure wrong preview size

2018-04-03 Thread racoon

On 03.04.2018 17:57, racoon wrote:

Hi,

I still get some strange previews with SVG figure (external material), 
see "wrong size.png".


It looks like the svg content and the text are applied in different 
sizes. This happens with ps output but not with pdflatex, see "wrong 
size output with ps2pdf.png" and "right size with pdflatex.png", 
respectively.


I have also attached the svg if you want to try it yourself.


ps. It might look a bit different for you since I realized that I have 
an '--export-area-page' in my svg2pstex.py. However, even without it the 
preview and output with ps is way off.




SVG figure wrong preview size

2018-04-03 Thread racoon

Hi,

I still get some strange previews with SVG figure (external material), 
see "wrong size.png".


It looks like the svg content and the text are applied in different 
sizes. This happens with ps output but not with pdflatex, see "wrong 
size output with ps2pdf.png" and "right size with pdflatex.png", 
respectively.


I have also attached the svg if you want to try it yourself.

Best,
Daniel


Re: Tab stop width in Preamble

2018-04-03 Thread racoon

On 02.04.2018 21:31, Richard Kimberly Heck wrote:

On 04/02/2018 06:08 AM, racoon wrote:

On 27.03.2018 11:16, racoon wrote:

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces
wide? That seems an awful lot to me. Is there a way to change it
something narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that
be changed to 2 spaces? (And maybe preamble and ERT tab stops should
be the same in general?)


I've found a couple of links concerning setting the tab stop width.
Maybe someone knows how to use them.


I've committed this to master and to 2.3.2-staging for the preamble, set
to four spaces, which seems to work pretty well. If you want to change
it elsewhere, have a look at b4d885ac for the code.


There is actually at least one more instance where a smaller tab stop 
might be good: the code preview.


Daniel




Re: Tab stop width in Preamble

2018-04-03 Thread racoon

On 02.04.2018 21:31, Richard Kimberly Heck wrote:

On 04/02/2018 06:08 AM, racoon wrote:

On 27.03.2018 11:16, racoon wrote:

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces
wide? That seems an awful lot to me. Is there a way to change it
something narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that
be changed to 2 spaces? (And maybe preamble and ERT tab stops should
be the same in general?)


I've found a couple of links concerning setting the tab stop width.
Maybe someone knows how to use them.


I've committed this to master and to 2.3.2-staging for the preamble, set
to four spaces, which seems to work pretty well. If you want to change
it elsewhere, have a look at b4d885ac for the code.


Thanks!

Daniel




Re: Tab stop width in Preamble

2018-04-02 Thread racoon

On 27.03.2018 11:16, racoon wrote:

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces wide? 
That seems an awful lot to me. Is there a way to change it something 
narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that be 
changed to 2 spaces? (And maybe preamble and ERT tab stops should be the 
same in general?)


I've found a couple of links concerning setting the tab stop width. 
Maybe someone knows how to use them. I guess at least the Preamble 
should set to a smaller tab stop width, like 4 spaces which would be the 
same as in ERTs.


http://www.qtcentre.org/threads/10253-setTabStopWidth-doesn-t-work?s=8a66c7e7178cf45ad9d36db4b73a9316=54413#post54413

https://stackoverflow.com/questions/13027091/how-to-override-tab-width-in-qt#15247253

http://doc.qt.io/archives/qt-4.8/qtextedit.html#tabStopWidth-prop



Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 15:45, Joel Kulesza wrote:
I regret that continually sending URLs about what "fn" means will not 
change my mind that (a) fn comes first as "function" and (b) foot->fn is 
an improvement.


Abbreviations are contextual and these links feel like selection bias to 
me.  Clearly, by just using two letters one can mean a lot of things (my 
own Google'd URL: https://www.abbreviations.com/FN). 


Yes, I agree context is important. That is why I send the scholarly 
texts which LyX is clearly related to.


Further, I wonder 
how translations of just the two letters would work.


I don't think English abbreviations on labels should be chosen based on 
whether they work in other languages as well. It would also be a pretty 
tricky aim given the variety in languages.



To the remark:


Yes, "footnote" might be better than "foot". But I think there is reason to prefer a short labels 
since labels clutter the text. Hence, I suggest "fn" or, maybe, "fn.".


I wonder why you think brevity is preferable to clarity.  I suspect 
"foot" was attempting to strike a balance.  I'd rather see no change 
than moving too hard in one direction (brevity) versus the other.  


The argument was not based on brevity alone. (Though I still consider it 
a virtue.) There was also the reason for "fn" being a common 
abbreviation for footnote in texts while "foot" is none. Hence, also, my 
favoring "footnote" over "foot".


Further, regarding context: because LaTeX can and is used with 
mathematics, "fn" could easily be misunderstood as function by a new 
user and not taken immediately as a footnote even by an experienced one 
if collapsable mathematical insets were to be used.
I don't think "fn" is a common abbreviation for function in mathematics. 
At least I can't remember having come across it in my studies. Do you 
have any evidence?


The only place I see "Fn" is right in front of me on my keyboard. There 
it actually stands for "function", so that might be where the connection 
is coming from. But it is not mathematical at all. Still the connection 
might be made by enough people. I don't know that.


Daniel


P.S. Said in jest: it's interesting to have a conversation with someone on how to 
properly name/identify something who goes by the handle "racoon".  I imagine a 
character from Guardians of the Galaxy on the far end of this email 
(https://en.wikipedia.org/wiki/Rocket_Raccoon).
I am just too lazy to change my sender address. Notice the addition "c" 
though. Two more tries. :)




Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 12:34, racoon wrote:

On 31.03.2018 12:33, racoon wrote:

On 31.03.2018 12:23, racoon wrote:

On 31.03.2018 00:03, Scott Kostyshak wrote:

On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote:

On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote:

I'd like to get your take on an enhancement request for changing the
label for footnotes from "foot x" too "fn x". I think the latter is a
much more common abbreviation than the former.


I agree but for me fn remembers FuNction. :-)


My first thought was of "function" also.


Come on, there are so much more FUN abbreviations for function. ;)

Here is some evidence that the abbreviation fn is actually used for 
footnotes:


https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= 



Wikipedia uses the fn abbreviation in the code:

https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references 



https://en.wiktionary.org/wiki/fn


https://www.merriam-webster.com/dictionary/fn

https://en.oxforddictionaries.com/definition/us/fn.

https://www.collinsdictionary.com/dictionary/english/fn

https://www.encyclopedia.com/humanities/dictionaries-thesauruses-pictures-and-press-releases/fn

https://www.quora.com/What-is-the-correct-abbreviation-for-footnote?share=1



Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 12:33, racoon wrote:

On 31.03.2018 12:23, racoon wrote:

On 31.03.2018 00:03, Scott Kostyshak wrote:

On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote:

On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote:

I'd like to get your take on an enhancement request for changing the
label for footnotes from "foot x" too "fn x". I think the latter is a
much more common abbreviation than the former.


I agree but for me fn remembers FuNction. :-)


My first thought was of "function" also.


Come on, there are so much more FUN abbreviations for function. ;)

Here is some evidence that the abbreviation fn is actually used for 
footnotes:


https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= 



Wikipedia uses the fn abbreviation in the code:

https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references 


https://en.wiktionary.org/wiki/fn

Daniel




Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 12:23, racoon wrote:

On 31.03.2018 00:03, Scott Kostyshak wrote:

On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote:

On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote:

I'd like to get your take on an enhancement request for changing the
label for footnotes from "foot x" too "fn x". I think the latter is a
much more common abbreviation than the former.


I agree but for me fn remembers FuNction. :-)


My first thought was of "function" also.


Come on, there are so much more FUN abbreviations for function. ;)

Here is some evidence that the abbreviation fn is actually used for 
footnotes:


https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22=


Wikipedia uses the fn abbreviation in the code:

https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references

Daniel



Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 01:30, Joel Kulesza wrote:
On Fri, Mar 30, 2018 at 4:03 PM, Scott Kostyshak <skost...@lyx.org 
<mailto:skost...@lyx.org>> wrote:


On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote:
> On Wednesday, 28 March 2018 20.26.52 <tel:2018%2020.26.52> WEST racoon 
wrote:
> > I'd like to get your take on an enhancement request for changing the
> > label for footnotes from "foot x" too "fn x". I think the latter is a
> > much more common abbreviation than the former.
>
> I agree but for me fn remembers FuNction. :-)

My first thought was of "function" also.


"fn" is also function in my mind.  Is "foot" too verbose?  For clarity, 
why not "footnote"?


Yes, "footnote" might be better than "foot". But I think there is reason 
to prefer a short labels since labels clutter the text. Hence, I suggest 
"fn" or, maybe, "fn.".


Daniel



Re: Poll: change "foot x" too "fn x"

2018-03-31 Thread racoon

On 31.03.2018 00:03, Scott Kostyshak wrote:

On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote:

On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote:

I'd like to get your take on an enhancement request for changing the
label for footnotes from "foot x" too "fn x". I think the latter is a
much more common abbreviation than the former.


I agree but for me fn remembers FuNction. :-)


My first thought was of "function" also.


Come on, there are so much more FUN abbreviations for function. ;)

Here is some evidence that the abbreviation fn is actually used for 
footnotes:


https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22=

Daniel



Poll: change "foot x" too "fn x"

2018-03-28 Thread racoon
I'd like to get your take on an enhancement request for changing the 
label for footnotes from "foot x" too "fn x". I think the latter is a 
much more common abbreviation than the former.


https://www.lyx.org/trac/ticket/11092#comment:2

(Probably someone will tell me that it is actually from Latin or so. :) )



Re: Tab stop width in Preamble

2018-03-27 Thread racoon

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces wide? 
That seems an awful lot to me. Is there a way to change it something 
narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that be 
changed to 2 spaces? (And maybe preamble and ERT tab stops should be the 
same in general?)


Daniel



Tab stop width in Preamble

2018-03-27 Thread racoon

Hi,

Could it be that the tab stop width in the preamble is 12 spaces wide? 
That seems an awful lot to me. Is there a way to change it something 
narrower, like 2 spaces?


Daniel



Re: New Win installer ready for LyX 2.3.0

2018-03-23 Thread racoon

On 23.03.2018 10:33, Uwe Stöhr wrote:

Am 23.03.2018 um 05:22 schrieb Scott Kostyshak:


I understand your argument. I disagree that adding a dialog would hurt
the vast majority more than it would help it


That is the fundamental disagreement.

It doesn't help if you ask users who knows what a package is, if they 
would understand such a dialog. My experience is that the majority of 
LyX users (under Windows of course) don't know this. My experience will 
not change the longer we discuss.
People like my mother can and do use LyX. She would not understand what 
you want but she should be able to use LyX in future.

Just an idea involving previous experience.

I seem to remember that since I am using LyX, which goes back many 
versions, there was always a dialog recommending but *asking* the user 
to run the MiKTeX update.


As I see it, due to the problems Uwe pointed out, many developers seem 
to accept that, at least for 2.3, LyX should not be installed without a 
forced MiKTeX update. (I might be wrong on this.)


However, also many developers seem to agree that, *as in all the 
versions before*, there should be a dialog asking the user before making 
changes to MiKTeX. (If the user denies to update MiKTeX, LyX will not be 
installed. So any amateur user will finally answer the question 
affirmative, I believe.)


Is there any strong evidence (maybe from many questions on the list or 
emails) that the dialog that LyX was showing before confused users? If 
not, what is the main difference between the old dialog and the new 
dialog in terms of how comprehensible it is?


I don't claim that many developers will follow my reasoning here. It is 
just a desperate attempt to make progress in some way.


Best,
Daniel



Windows installer: install for all users

2018-03-19 Thread racoon

Hi,

Under windows some installers ask the user whether the installation 
should be performed for all or only the current user. See for example:


https://ca.nctu.edu.tw/images/how-to-use/2-ftp-client-installation/en-gb/2-Me_or_everyone.png

With the current LyX installer one can only do one or the other 
depending on whether the installer is executed with administrator 
privileges or not. If it is feasible, I think it is helpful to give this 
option - especially for


- those not familiar with how to execute an installation as an 
administrator and


- those who don't know that LyX will install only the one or the other 
depending on how the installation is executed.


Daniel



Re: Update on 2.3.0 situation and Windows-specific issues

2018-03-15 Thread racoon

On 15.03.2018 04:13, Scott Kostyshak wrote:

On Wed, Mar 14, 2018 at 01:48:02AM +, Uwe Stöhr wrote:


Why don't you add a sentence or two to the release notes for the experienced
users that they can set in MiKTeX "never" to package updates. Experienced
users will understand this. That is the most suitable solution.


I think a dialog is more appropriate, because problems from upgrading
MiKTeX could affect anyone, not just experienced users.


I tend to agree. However, maybe the dialog should state only true things?

So, either it should come up only when the 'never' option isn't set 
(preferably), or indicate that


* MiKTeX will be updated (unless 'Install missing packages on-the-fly' 
is set to 'never')


I know, that makes things worse in one respect (complicating the dialog)...

Daniel



Re: Update on 2.3.0 situation and Windows-specific issues

2018-03-08 Thread racoon
I just tried the windows installer. Here is what it does (no evaluation 
intended since I probably don't understand enough of this).


1. LyX installs fine.

2. The user is not asked whether to update MiKTeX or cancel the setup.

3. There are a couple of messages that seem fine but are also a bit 
strange (see below).


Daniel

 below 

Package "miktex-bin-2.9" is up to date.

Sorry, but "MiKTeX Package Manager" did not succeed for the following 
reason:


  Package "miktex-console-bin-2.9" is already installed.

The log file hopefully contains the information to get MiKTeX going again:

  C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log

You may want to visit the MiKTeX project page, if you need help.

Sorry, but "MiKTeX Package Manager" did not succeed.

The log file hopefully contains the information to get MiKTeX going again:

  C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log

You may want to visit the MiKTeX project page, if you need help.
There are currently no updates available.



Re: Solution: Summary for the Win installer problem

2018-03-05 Thread racoon

On 05.03.2018 20:16, Uwe Stöhr wrote:

Am 05.03.2018 um 19:37 schrieb racoon:

However, it does not give the user a choice on whether to update 
MiKTeX or not.


Yes, that is correct and I explained now in several mails why and that 
there is no other option.


Sorry, I have a bit of a hard time following the discussion.

Why is forcing the user to make a choice between going ahead with the 
setup and cancelling no option?


Feel free to just ignore my question if you have answered that as well 
before.


Also, I noticed that the MiKTeX Package Manager opens up for some 
reason and stays open. I am not sure why that is happening.


This is another bug in MiKTeX I mentioned. There will therefore be a 
sentence I the announcement text. However, I just see that MiKTeX 
released a new installer as promised. This bug will then be fixed.


Sorry, I must have missed that, too.

Daniel



Re: Solution: Summary for the Win installer problem

2018-03-05 Thread racoon

On 05.03.2018 19:37, racoon wrote:

On 04.03.2018 19:36, Uwe Stöhr wrote:

Am 04.03.2018 um 16:19 schrieb Uwe Stöhr:

Good news: There will be a new MiKTeX installer soon and the MiKTeX 
maintainer proposed a workaround for the main bug. I cannot promise 
that I will find time today to check if this will work for all cases. 


OK, I could check it and it works. The new installer can be found here:
http://ftp.lyx.de/LyXWinInstaller/LyX2.3.0/

Now the users is not bothered at all. Everything that needs to be done 
is done by the installer silently.


I would nevertheless wait with the announcement because the MiKTeX 
developer promised to make a release just for us soon. If it will be 
available by Tuesday, I will create a new installer, if not, let's 
release LyX 2.3.0 with the installer version 3 I linked above.


Thanks Uwe. I have tried the installer.

However, it does not give the user a choice on whether to update MiKTeX 
or not. One is only told that MiKTeX must be updated and can only click 
"OK". I guess it would be preferable to let the user choose to at least 
update or cancel the whole installation. But maybe that is hard to 
implement since the message comes up only after parts of LyX are already 
installed? But maybe one could inform the user at an earlier stage where 
she then has to click "Next" or so?


Also, I noticed that the MiKTeX Package Manager opens up for some reason 
and stays open. I am not sure why that is happening.


And the installation also worked without an active internet connection.



Re: Solution: Summary for the Win installer problem

2018-03-05 Thread racoon

On 04.03.2018 19:36, Uwe Stöhr wrote:

Am 04.03.2018 um 16:19 schrieb Uwe Stöhr:

Good news: There will be a new MiKTeX installer soon and the MiKTeX 
maintainer proposed a workaround for the main bug. I cannot promise 
that I will find time today to check if this will work for all cases. 


OK, I could check it and it works. The new installer can be found here:
http://ftp.lyx.de/LyXWinInstaller/LyX2.3.0/

Now the users is not bothered at all. Everything that needs to be done 
is done by the installer silently.


I would nevertheless wait with the announcement because the MiKTeX 
developer promised to make a release just for us soon. If it will be 
available by Tuesday, I will create a new installer, if not, let's 
release LyX 2.3.0 with the installer version 3 I linked above.


Thanks Uwe. I have tried the installer.

However, it does not give the user a choice on whether to update MiKTeX 
or not. One is only told that MiKTeX must be updated and can only click 
"OK". I guess it would be preferable to let the user choose to at least 
update or cancel the whole installation. But maybe that is hard to 
implement since the message comes up only after parts of LyX are already 
installed? But maybe one could inform the user at an earlier stage where 
she then has to click "Next" or so?


Also, I noticed that the MiKTeX Package Manager opens up for some reason 
and stays open. I am not sure why that is happening.


Daniel


Re: Summary for the Win installer problem

2018-03-03 Thread racoon



On 03.03.2018 18:17, Scott Kostyshak wrote:

On Sat, Mar 03, 2018 at 12:26:35AM +, Uwe Stöhr wrote:

Am 02.03.2018 um 20:59 schrieb Richard Heck:


I don't know a lot about Windows, but let me just ask: Do we really want
to force people to upgrade some other package when they install LyX?


As I wrote in a previous post, the thing is that MiKTeX released in February
a new package handling system. In order to be able to set up LyX the LyX
installer needs to use this new system and therefore MiKTeX needs to be
updated.


I have a similar concern to Richard (and a similar disclaimer that I
don't know much about Windows). Even if what you put is the case, I
would prefer for the LyX installer to just give an error such as "Cannot
install LyX without the newest version of MiKTeX. Please update your
MiKTeX installation as follows: ..."


But couldn't LyX ask the user to make a decision? Like

"Cannot install LyX without the newest version of MiKTeX. Click Next to 
update MiKTeX or Cancel."


Daniel


Re: Summary for the Win installer problem

2018-03-02 Thread racoon

On 02.03.2018 20:16, Uwe Stöhr wrote:

Here is the final analysis:
- I created a new installer that forces a silent MiKTeX update. This 
assures that every user gets the current MiKTeX package handling system.


Do you know how I can check whether I already have the current MiKTeX 
package handling system (without actually updating)?


Daniel


Re: Tar balls and binaries have been uploaded

2018-03-02 Thread racoon

On 02.03.2018 13:07, Uwe Stöhr wrote:

Am 02.03.2018 um 08:14 schrieb racoon:


I am quite sure that MiKTeX wasn't the problem in my case.


Well, I worked a lot:


Thanks a lot for your efforts.



Scott, for the announcement I propose to write that users who have 
problems of getting the UserGuide compiled to a PDF should

- uninstall LyX _and_ MiKTeX
- install LyX 2.3.0 using the bundle installer that will automatically 
reinstall MiKTeX


Since in my case an anti-virus software seemed to be the culprit, I 
suggest to add that


- if one has a virus scanner installed and LyX cannot find "latex.exe", 
as a first step just close the installer and rerun it


since this message appears even before LyX is installing this saves a 
lot of work and time compared to the alternatives.


Daniel


Re: Tar balls and binaries have been uploaded

2018-03-01 Thread racoon

On 01.03.2018 19:31, Uwe Stöhr wrote:

Am 28.02.2018 um 10:25 schrieb racoon:


Strange. I just ran the installer again and now it works.


Have you run MiKTeX update on every run of the installer as the 
installer suggested? If so your virus scanner is not to blame.


I have not yet a solution for this other than to reinstall MiKTeX. That 
MiKTeX changed 3 weeks ago (therefore the RC2 installer has no issues) 
the packaging system one can describe the problem like this:


The LyX installer uses a "key" for the "lock" of the package handling. 
Since the lock was replaced, the installer needs a new key. This key 
works for an updated MiKTeX but not for the old one. On top of this 
problem comes that one needs 2 runs of the MiKTeX update to get the new 
packaging system (lock). And even more there is a bug in the new 
packaging system of MiKTeX and the MiKTeX maintainer is currently away.


The LyX installer has no chance to detect what MiKTeX packaging system 
is used on the PC. I think the only way is to build a special installer 
for LyX 2.3.0 that forces 2 update runs of MiKTeX. This will assure the 
success but annoys the user since maybe they already updated and 2 dry 
update runs can consume up to 4 minutes installation time in which 
nothing happens. I know how annoyed users are by every single button 
click they have to do unnecessarily. They will be confronted with 8 
additional clicks because of the mentioned bug in MiKTeX. I think 
assuring a working installation is more important but if they refuse to 
do all the clicks I cannot force 2 update runs.


Give me some time to think about this.


I am quite sure that MiKTeX wasn't the problem in my case. In my first 
run of the installer I did not even get to the point where MiKTeX is 
searching for updates. And I just cancelled the installation before 
MiKTeX update was invoked. And I did not update MiKTeX between the first 
and second run and still, on the second, MiKTeX was found even before 
the updating by the installer.


Daniel



Re: Tar balls and binaries have been uploaded

2018-03-01 Thread racoon

On 01.03.2018 18:50, Uwe Stöhr wrote:

Am 01.03.2018 um 17:18 schrieb Scott Kostyshak:


If this is the cause of all the problems, I guess all we can do is put
a note in the announcement. I do not think we can officially recommend
disabling anti-virus during the installation, but at least we can
explain the situation.


I am opposed to this. This is bad advertisement. We deliver a fully 
functional product. There will always be cases with problems restricted 
to software used by some persons. We should not announce this! I mean 
look in the forums of e.g. LibreOffice or InkScape for virus alarms, 
mangled registry settings and the like. Such cases will always happen. 
We are only responsible to things done by the product we deliver.


I am not sure I understand why this is bad advertisement. Maybe you can 
explain this a bit more.


I think, if the situation is explained that might be rather helpful. 
Otherwise we end up with some users being frustrated if they cannot 
install LyX. Worst case, they will not use LyX.


And while true that forums of LibreOffice contain some discussion about 
false positives, they also clarify this on their pages:


https://www.libreoffice.org/about-us/security/

Daniel



Re: Tar balls and binaries have been uploaded

2018-03-01 Thread racoon

On 28.02.2018 23:31, Scott Kostyshak wrote:

On Wed, Feb 28, 2018 at 08:41:43PM +, racoon wrote:

Yes, I can do it. But the earliest is tomorrow morning (so in about 10
hours).

Just to be sure: The virus scanner did not detect anything. And I left the
scanner activated during the second, successful installation process. It is
just that the scanner did not do a deep scan the second time around probably
because the scanner was already familiar with the file or so.


Ah I see. I did not read carefully enough. In that case, since you
already installed rc2, the scanner would also be familiar with it. So
I no longer think it is worth the time to try to reproduce (unless
someone else does) with rc2.

It would be nice if we could find a way to reproduce with the 2.3.0
installer (so that we could perhaps find a solution). Do you know if the
scanner keeps temporary files somewhere?  Maybe if you restart your
computer, the temporary directory will be cleared, and the scanner will
re-scan if you install it again. Otherwise, is there a folder where
Windows typically caches files? Is this something that the virus scanner
might store in the registry? I would guess not, but I have no idea.


So, I have checked but could not find a way to reproduce yet. However, I 
think I know what was going on.


I was using Avast Antivirus and it has a feature called "CyberCapture". 
It is a bit explained here:


https://support.avast.com/en-ww/article/Antivirus-CyberCapture-FAQ/

"CyberCapture is a feature in Avast Antivirus that detects and analyzes 
rare, suspicious files. If you attempt to run such a file, CyberCapture 
locks the file from your PC and sends it to the Avast Threat Lab where 
it is analyzed in a safe, virtual environment."


It also states that

"CyberCapture is able to handle large files, but it may take longer to 
deliver such files to the Avast Threat Lab."


So, here is what I think happened. Avast did not recognize the large 
file and send it to its server which took quite a bit. I believe there 
was a colored frame with "Avast CyberCapture" around the installer while 
Avast still locked the installer but I kept going on with the 
installation which led to the installer not being able to communicate 
with my system and detect latex.


I am not sure there is anything to be done about this on the LyX side. 
Apart from the privacy hazard this feature seems to be it is also 
strange that it still lets you use the program with limited 
functionality which leads to obvious problems for installers. I will 
disable this feature and see what will happen in the future.


Daniel



Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon
Or it might be even enough to just download a fresh file... I'll try in 
a bit.


Daniel

On 2018-02-28 23:31, Scott Kostyshak wrote:

On Wed, Feb 28, 2018 at 08:41:43PM +, racoon wrote:

Yes, I can do it. But the earliest is tomorrow morning (so in about 10
hours).

Just to be sure: The virus scanner did not detect anything. And I left the
scanner activated during the second, successful installation process. It is
just that the scanner did not do a deep scan the second time around probably
because the scanner was already familiar with the file or so.


Ah I see. I did not read carefully enough. In that case, since you
already installed rc2, the scanner would also be familiar with it. So
I no longer think it is worth the time to try to reproduce (unless
someone else does) with rc2.

It would be nice if we could find a way to reproduce with the 2.3.0
installer (so that we could perhaps find a solution). Do you know if the
scanner keeps temporary files somewhere?  Maybe if you restart your
computer, the temporary directory will be cleared, and the scanner will
re-scan if you install it again. Otherwise, is there a folder where
Windows typically caches files? Is this something that the virus scanner
might store in the registry? I would guess not, but I have no idea.

Thanks,

Scott



Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon
Yes, I can do it. But the earliest is tomorrow morning (so in about 10 
hours).


Just to be sure: The virus scanner did not detect anything. And I left 
the scanner activated during the second, successful installation 
process. It is just that the scanner did not do a deep scan the second 
time around probably because the scanner was already familiar with the 
file or so.


Daniel

On 2018-02-28 21:30, Scott Kostyshak wrote:

On Wed, Feb 28, 2018 at 07:20:38PM +, racoon wrote:


Uwe and racoon, do you recommend going forward with the release? Why was
the above not a problem for rc2?


My guess is that I did not have the virus scanner activated when installing
rc2 but can't say for sure.


We've decided to delay the release.

racoon, I'm sorry to ask you to spend more time on this (especially now
that you have things working and probably do not want to change
anything), but would you be willing to uninstall 2.3.0 and see if you
can reproduce the issue with the 2.3.0rc2 installer (e.g. having the
virus scanner activated)? I'm curious in whether there is a difference
between 2.3.0rc2 and 2.3.0. I do not blame you if you do not want to
touch your working installation. You've already been so helpful in
testing.

Scott



Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon



On 2018-02-28 17:50, Scott Kostyshak wrote:

On Wed, Feb 28, 2018 at 11:36:33AM +, racoon wrote:

On 28.02.2018 12:04, Uwe Stöhr wrote:



Strange. I just ran the installer again and now it works.


The installer checks the Windows registry to locate LaTeX program. If you have 
MiKTeX or TeXLive  installed but the installer cannot find it, your virus 
scanner blocks that the installer have read access to the registry. This should 
not happen but virus scanners ate often over eager. Blocking read permission 
makes no sense in my opinion.

In general I cannot recommend using virus scanners because the make make 
problems than they solve. I am not using such scanners for years now and I am 
virus-free nevertheless. The best way to stay safe us to use consequently only 
non-admin accounts. If you need to install things that should be available for 
all users of the PC, allow elevated rights only for the installer. Thus way 
virus programs cannot modify e.g. the registry. Only if there are bugs in 
Windows itself, this method can be unsafe but in this case also virus scanners 
don't help.

Just my opinion.


Thanks. I guess a blind spot is when an installer is actually infected with
a virus and one gives the installer elevated right. That's where a virus
scanner might be handy. Though most of the time I do not use one either.


Uwe and racoon, do you recommend going forward with the release? Why was
the above not a problem for rc2?


My guess is that I did not have the virus scanner activated when 
installing rc2 but can't say for sure.


Daniel


Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon

On 2018-02-28 17:58, Scott Kostyshak wrote:

On Wed, Feb 28, 2018 at 09:25:47AM +, racoon wrote:


Strange. I just ran the installer again and now it works.


To be clear, the installer works and after the installation you can
successfully compile e.g. the user guide?


That is correct.

Daniel


Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon

On 28.02.2018 12:04, Uwe Stöhr wrote:



Strange. I just ran the installer again and now it works.


The installer checks the Windows registry to locate LaTeX program. If you have 
MiKTeX or TeXLive  installed but the installer cannot find it, your virus 
scanner blocks that the installer have read access to the registry. This should 
not happen but virus scanners ate often over eager. Blocking read permission 
makes no sense in my opinion.

In general I cannot recommend using virus scanners because the make make 
problems than they solve. I am not using such scanners for years now and I am 
virus-free nevertheless. The best way to stay safe us to use consequently only 
non-admin accounts. If you need to install things that should be available for 
all users of the PC, allow elevated rights only for the installer. Thus way 
virus programs cannot modify e.g. the registry. Only if there are bugs in 
Windows itself, this method can be unsafe but in this case also virus scanners 
don't help.

Just my opinion.


Thanks. I guess a blind spot is when an installer is actually infected 
with a virus and one gives the installer elevated right. That's where a 
virus scanner might be handy. Though most of the time I do not use one 
either.


Daniel


Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon

On 28.02.2018 07:03, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote:

Yes.


What is the exact error message that is given and when is it given? Can
you provide a screenshot?


Also, have you uninstalled all previous 2.3.0 pre-release versions
before trying to install 2.3.0 final?


Strange. I just ran the installer again and now it works.

I noticed that the virus scanner scanned the installer at the first run. 
Maybe that somehow interfered with the installer?!?


Daniel


Re: Tar balls and binaries have been uploaded

2018-02-28 Thread racoon

On 28.02.2018 07:03, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote:

Yes.


What is the exact error message that is given and when is it given? Can
you provide a screenshot?


Screenshot attached. The installer cannot find my LaTeX distribution.

Daniel


Re: Tar balls and binaries have been uploaded

2018-02-27 Thread racoon
Yes, uninstalled all 2.3.0 pre-release version before trying to install 
LyX.


I think the dialog asks whether I want to use LaTeX and asks me to 
provide the location of latex.exe manually. I think I never saw that 
before. I'll look more closely at it and provide a screenshot in an hour 
or so when I am at my windows 7 computer.


Daniel

On 2018-02-28 07:03, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote:

Yes.


What is the exact error message that is given and when is it given? Can
you provide a screenshot?


Also, have you uninstalled all previous 2.3.0 pre-release versions
before trying to install 2.3.0 final?

Scott



Re: Tar balls and binaries have been uploaded

2018-02-27 Thread racoon

Yes.

Daniel

On 2018-02-27 18:07, Scott Kostyshak wrote:

On Tue, Feb 27, 2018 at 05:08:23PM +, racoon wrote:

I tried to install the windows binary but the installer does not find the
latex.exe.


So 2.3.0rc2 worked for you, but 2.3.0 does not?

Scott



Re: Tar balls and binaries have been uploaded

2018-02-27 Thread racoon
I tried to install the windows binary but the installer does not find 
the latex.exe.


Best,
Daniel



Re: Extending layouts

2018-02-07 Thread racoon

On 24.01.2018 21:22, Richard Heck wrote:

On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote:


Now that I think about it, the advantage of using a special syntax is
that there is not need to specify the file name, which makes the code
safer.

Idead of syntax:
   Input 
   Input *
   InputParent


I had a similar thought: something like class inheritance. The last of
these looks best to me.


And seems to get the job done I need at the moment. So, I'd be happy is 
something like this existed.


Daniel



Re: Extending layouts

2018-01-23 Thread racoon

On 23.01.2018 11:50, Jean-Marc Lasgouttes wrote:
When is it useful to extend an extension in the same user directory? I 
do not see the point...


For example, you might have a module locally installed in the user dir 
which you want to extend. This is not strictly speaking an extension of 
an extension but maybe a good enough use case to consider it seriously?


Daniel



Re: Extending layouts

2018-01-23 Thread racoon

On 23.01.2018 11:02, racoon wrote:

On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote:

Le 23/01/2018 à 09:35, racoon a écrit :
Yes, that would work for my case. However, it will fail if I want to 
extend an extension since it will not search my user directory.


Let's say in the user directory there is

1. user_dir/foo.layout.ext

which extends an extension


Actually, what I proposed would be an alternative to the .ext 
proposal. It is not meant to be used at the same time.


I see. Would your suggestion be able to allow the extension of extensions?

If I see it correctly, my example could be changes as follows to extend 
your suggestion:


1. user_dir/foo.layout
2. user_dir/foo.ext
3. sys_dir/foo.layout

1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout".


The last line should of course be

1 has a line line "Input *foo*.ext" and 2 has a line "Input foo.layout".



If "Input filename" not only searches in the higher order directory as I 
suggested before, this might work. (Notice that the 2's extension ".ext" 
is non-essential to the example.)


Daniel







Re: Extending layouts

2018-01-23 Thread racoon

On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote:

Le 23/01/2018 à 09:35, racoon a écrit :
Yes, that would work for my case. However, it will fail if I want to 
extend an extension since it will not search my user directory.


Let's say in the user directory there is

1. user_dir/foo.layout.ext

which extends an extension


Actually, what I proposed would be an alternative to the .ext proposal. 
It is not meant to be used at the same time.


I see. Would your suggestion be able to allow the extension of extensions?

If I see it correctly, my example could be changes as follows to extend 
your suggestion:


1. user_dir/foo.layout
2. user_dir/foo.ext
3. sys_dir/foo.layout

1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout".

If "Input filename" not only searches in the higher order directory as I 
suggested before, this might work. (Notice that the 2's extension ".ext" 
is non-essential to the example.)


Daniel



Re: Extending layouts

2018-01-23 Thread racoon

On 23.01.2018 07:11, Richard Heck wrote:

On 01/22/2018 04:23 AM, Jean-Marc Lasgouttes wrote:

Le 22/01/2018 à 10:10, racoon a écrit :

So LyX should load the library's stdinset.inc first and then load the
code that extends it next.

Richard, who ran into similar problems as I did, suggested that LyX
could be enhanced by automatically looking for and loading an .ext
file, e.g. stdinset.inc.ext.

I think that is a good idea and this concept could be used for other
sorts of layout files, like .modules.


One idea that I do not like about the .ext file idea is that it does
not scale when you want to extend a file that has already been
extended, which might happen if we had a site directory as proposed in
http://www.lyx.org/trac/ticket/10326.

One idea I had about that is to change the behavior of Input (which
searches for files in user dir, then build dir, and finally system
dir) so that it skips to the next level when doing recursive input.
Example:

* In user_dir/foo.layout, if I do "Input foo.layout", it will search
in build dir, and then system dir
* in build_dir/foo.layout, it will try only sys_dir/foo.layout

The same will work if we add a site directory.

Would that fix your issue, or are there cases where it would not do
what you expect?


My sense, from our previous discussion, is that this would work in the
cases racoon had in mind. But I'm not sure why this wouldn't scale. We
could of course look also for *.ext.ext.

These ideas could also probably be combined.


I guess a benefit of Jean-Marc's suggestion is that it provides the user 
with more freedom to choose filenames (if his suggestion is extended in 
some way like I proposed in reply to him).


Daniel



Re: Extending layouts

2018-01-23 Thread racoon

On 22.01.2018 11:23, Jean-Marc Lasgouttes wrote:

Le 22/01/2018 à 10:10, racoon a écrit :
So LyX should load the library's stdinset.inc first and then load the 
code that extends it next.


Richard, who ran into similar problems as I did, suggested that LyX 
could be enhanced by automatically looking for and loading an .ext 
file, e.g. stdinset.inc.ext.


I think that is a good idea and this concept could be used for other 
sorts of layout files, like .modules.


One idea that I do not like about the .ext file idea is that it does not 
scale when you want to extend a file that has already been extended, 
which might happen if we had a site directory as proposed in 
http://www.lyx.org/trac/ticket/10326.


One idea I had about that is to change the behavior of Input (which 
searches for files in user dir, then build dir, and finally system dir) 
so that it skips to the next level when doing recursive input. Example:


* In user_dir/foo.layout, if I do "Input foo.layout", it will search in 
build dir, and then system dir

* in build_dir/foo.layout, it will try only sys_dir/foo.layout

The same will work if we add a site directory.

Would that fix your issue, or are there cases where it would not do what 
you expect?


Yes, that would work for my case. However, it will fail if I want to 
extend an extension since it will not search my user directory.


Let's say in the user directory there is

1. user_dir/foo.layout.ext

which extends an extension

2. user_dir/foo.layout

of

3. sys_dir/foo.layout

Since

Input foo.layout

will search only in the higher order directories, sys_dir and build_dir, 
there is no way to reach 2 from 1. A way around would be to start search 
the user directory (but, obviously, only if the filename differs from 
itself) and then upwards.


Daniel



Extending layouts

2018-01-22 Thread racoon

I am bringing over a topic from the general list for dev discussion:

By default LyX loads standard layouts and insets. Is there a way to 
extend them without overwriting the default .inc file and without using 
a module?


Let's say I want to extend the standard Note style.

I don't want to use a module since I want to make a non-optional change 
to the Note inset. For example, I want to use another font size for all 
LyX notes.


If I understood correctly, I can just put a copy of the stdinset.inc 
file from the library to the user directory. But this will have the 
unwelcome effect to overwrite whatever is in the stdinset.inc in the 
library directory. So, to avoid unwanted consequences, I will have to 
update my user stdinset.inc every time the library stdinset.inc changes, 
for example, in a new version of LyX.


So I would rather like to *extend* the current library file by just the 
font-size changes by


InsetLayout Note:Note
CopyStyle Note
Font
Size Small
EndFont
End

So LyX should load the library's stdinset.inc first and then load the 
code that extends it next.


Richard, who ran into similar problems as I did, suggested that LyX 
could be enhanced by automatically looking for and loading an .ext file, 
e.g. stdinset.inc.ext.


I think that is a good idea and this concept could be used for other 
sorts of layout files, like .modules.


Daniel



AddToToc does not work as expected

2018-01-18 Thread racoon

Hi,

I boldly tried to add all enumerated items to the outliner by adding the 
following to the Local Layout:



OutlinerName enum "Enumerates"

Style Enumerate
CopyStyle Enumerate
AddToToc enum
IsTocCaption true
End


Unfortunately, it seems not to work. And I am wondering whether this is 
as intended or not.


First, when adding different items to a list, like

1. One
2. Two
3. Three

They do not get separated in the toc. The output will be one item that reads

1. One 2. Two 3. Three

Second, the toc item gets updated only after a new item or paragraph is 
started after it. So if one only writes


Test
1. One

and then does not add another paragraph after it but sets the cursor 
only back to the first "Test" line, then no item is generated.


Daniel



Discussion for ticket #10975

2018-01-13 Thread racoon

Hi!

Richard suggested to get some comments on enhancement request #10975.

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

When working with cross references one often uses the same format. The 
Cross-reference dialog already takes this into account by suggesting the 
last used format by default. The same would be helpful when using Copy 
as Reference from a label context menu.


Daniel



Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:15, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 18:41 +0200 schrieb racoon:

On 02.11.2017 19:22, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:

The opening of Document Settings takes about 8 seconds for some
Documents on my system. LyX becomes unresponsive in the
meanwhile.
(Core
2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much
faster
still.


Do you have local layout setting in these documents? If so, does
the
speed improve if you convert these to the current format (via the
"Convert" button)?


No local layout present.


Could you provide us with such a document?


Not at the moment. But I'll look into that.

Daniel



Jürgen






Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 21:34, Andrew Parsloe wrote:



On 3/11/2017 5:44 a.m., racoon wrote:

On 02.11.2017 17:21, racoon wrote:
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. 
(Core 2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much 
faster still.


Seems like these delays change. After a fresh start of LyX it takes 
about 8 seconds. But sometimes this gets quicker when LyX has been in 
use for a while.


Daniel
I can't reproduce. I'm running rc1 (Uwe's installer), Windows 7, 
standard 'High Street' laptop from about 4 years ago. I start LyX, open 
a document, access Document Settings and it shows in a second or less.


Did you see the "for some documents" part? It is definitely quicker for 
new files (just a bit over a second). I haven't figured out what it 
correlates with. For example, the User Manual seems fine.


Daniel



Andrew

PS Following this thread results in weird timings on my computer.

racoon  4:21 a.m.
racoon  5:40 a.m. (reply to Scott 6:02)
racoon  5:41 a.m. (reply to Juergen 6:22)
racoon  5:44 a.m.
Scott   6:02 a.m.
Juergen 6:22 a.m.
Juergen 7:15 a.m.


Could be that my computer was on the wrong settings after switching time 
zones...




I once spent some weeks inadvertently using US Pacific time but I've 
checked and it is correctly set for New Zealand.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus







Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:22, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:

The opening of Document Settings takes about 8 seconds for some
Documents on my system. LyX becomes unresponsive in the meanwhile.
(Core
2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much
faster
still.


Do you have local layout setting in these documents? If so, does the
speed improve if you convert these to the current format (via the
"Convert" button)?


No local layout present.

Daniel



Jürgen



Daniel





Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 17:21, racoon wrote:
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 
2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much faster 
still.


Seems like these delays change. After a fresh start of LyX it takes 
about 8 seconds. But sometimes this gets quicker when LyX has been in 
use for a while.


Daniel




Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:02, Scott Kostyshak wrote:

On Thu, Nov 02, 2017 at 03:21:02PM +, racoon wrote:

The opening of Document Settings takes about 8 seconds for some Documents on
my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much faster
still.


Can you give an approximate guess on how long it was in each version?

2.3.0rc1: 8 seconds

2.3.0beta1 about how long??
2.3.0alpha1 about how long?
In 2.2.3 about how long?


For sure I did not notice such a long delay before. My guess is about 
2-4 seconds. With LyX 2.2.3 at the lower and beta 1at the upper 
boundary. I don't know about alpha1.


Daniel


I thought Uwe had reported something like this particularly for document
settings, but I could not find the trac ticket.

Thanks,

Scott






Re: Beta1 is slow on undo

2017-11-02 Thread racoon

On 07.10.2017 19:09, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my 
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a 
second to respond to it.


Did anyone notice this? I don't have a very fast computer though.


In RC1 the undo speed is back to normal, i.e. barely noticeable delay. 
Thanks!


Daniel



Best,

Daniel







Re: Color reset in 2.3.0rc1

2017-11-02 Thread racoon

On 02.11.2017 17:30, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 13:55 +0200 schrieb racoon:

It seems that rc1 resets a couple of colors for some reason.


The reason is the renaming of the colors collapsable and
collapsableframe to collapsible and collapsibleframe, respectively. We
forgot to increase the prefs format.

Fixed now in master. We should backport this to 2.3.x as well, Scott.


The other I noticed was the frame of insets. Unfortunately, none of
the
colors in Preferences seems to change that frame color back. Was the
possibility of a customization of the frame abandoned?


collapsibleframe should work.


Thanks. I can verify that using collapsibleframe in the preferences file 
works.




Jürgen


Daniel





Slow opening of Document Settings in RC1

2017-11-02 Thread racoon
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 
2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much faster 
still.


Daniel



Color reset in 2.3.0rc1

2017-11-02 Thread racoon
It seems that rc1 resets a couple of colors for some reason. (I don't 
know about beta1 since I started with fresh settings with that version.)


One was collapsable, aka "collapsible inset text".

The other I noticed was the frame of insets. Unfortunately, none of the 
colors in Preferences seems to change that frame color back. Was the 
possibility of a customization of the frame abandoned?


Daniel




Re: Show changes don't work with URL (and maybe other insets)

2017-10-25 Thread racoon

On 20.10.2017 09:46, racoon wrote:
Open and typeset the attached file with a deleted URL and active show 
changes. It shows both the actual and expected result.


Notes: While the current algorithm seems fine for some insets, like 
footnotes, it falters at other insets, like URL, which do not interpret 
its content as LaTeX code.


Okay, it seems pretty impossible to solve this. The problem is that when 
only plain text is allowed in an inset, like URL, changes can be marked 
as on whole inset but not different changes within it.


However, here is what one might reasonably do:

if the content is only plain, i.e. forceplain is true, to not end the 
\lyxadded and \lyxdeleted before it but just wrap it around the inset.


and additionally, but I guess this is not such a simple change,

have an inset setting that disables change tracking within it, so that 
there will be no \lyxadded and \lyxdeleted within the inset.


Daniel



Re: List of notes not in beta1

2017-10-22 Thread racoon

On 21.10.2017 11:31, Jürgen Spitzmüller wrote:

Am Samstag, den 21.10.2017, 11:12 +0300 schrieb racoon:

On 21.10.2017 10:28, Jean-Marc Lasgouttes wrote:

Le 20 octobre 2017 23:37:53 GMT+02:00, racoon <xraco...@gmx.de> a
écrit :

Thanks. Well, I guess there must be something wrong with my
configuration then...


Did you customize your layout file(s) related to notes?


Thanks. Yes, I did. And now that I removed the layout file it works.

However, the exact same layout file works in LyX 2.2. Now I have to
figure out what's going on.


You probably miss these two lines in your own definition of notes:

AddToToc  note
IsTocCaption  true


Great, that does the trick. I haven't looked at the AddToToc and 
IsTocCaption yet. Sounds good.


Daniel



Jürgen



Daniel





Re: List of notes not in beta1

2017-10-21 Thread racoon

On 21.10.2017 10:28, Jean-Marc Lasgouttes wrote:

Le 20 octobre 2017 23:37:53 GMT+02:00, racoon <xraco...@gmx.de> a écrit :

Thanks. Well, I guess there must be something wrong with my
configuration then...


Did you customize your layout file(s) related to notes?


Thanks. Yes, I did. And now that I removed the layout file it works.

However, the exact same layout file works in LyX 2.2. Now I have to 
figure out what's going on.


Daniel



Re: Windows: bring window to front

2017-10-20 Thread racoon

On 17.10.2017 14:07, Enrico Forestieri wrote:

On Tue, Oct 17, 2017 at 11:50:23AM +0300, racoon wrote:

On 17.10.2017 06:42, Scott Kostyshak wrote:

On Mon, Oct 16, 2017 at 01:09:34PM +, racoon wrote:

Hi,

Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If
so, it seems not to work. If not, maybe it can make it to rc1?


The patch is in beta1. If the feature doesn't work, then that means the
fix didn't work for you.


Yes, when opening LyX files from the explorer, LyX still does not come to
the top.

Strange, I thought I tested the patch before and it worked. But I probably
did not try it from the explorer but rather from the command line. I am not
sure there is a difference wrt the problem.


It works for me. Make sure that you have "Single Instance" checked and
"LyXServer pipe" defined in the preferences.


I have it checked and defined, respectively. (Though I am wondering why 
"Single instance" should make a difference at all and "LyXServer pipe" 
at least for opening documents from the explorer.)


But it doesn't work. Just to be sure, you tested on Windows beta1, right?

Daniel




Re: List of notes not in beta1

2017-10-20 Thread racoon

On 20.10.2017 23:20, Andrew Parsloe wrote:



On 20/10/2017 6:50 p.m., racoon wrote:

On 19.10.2017 15:25, Kornel Benko wrote:
Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon 
<xraco...@gmx.de>

My documents do not show the "Notes" list in the Outline pane in beta1.
Is that a bug?

Daniel


Insert a note first?

Kornel

Yes, I have plenty of them. Does your question suggest that it works 
for you?


Daniel

I'm using beta1 on windows7. The current document includes notes and 
there *is* a Notes option in the Outliner. (I need to use the slider to 
bring it into view.) When I choose it, a list of notes is presented.


Andrew


Thanks. Well, I guess there must be something wrong with my 
configuration then...


Daniel





Re: List of notes not in beta1

2017-10-20 Thread racoon

On 20.10.2017 17:06, Kornel Benko wrote:

Am Freitag, 20. Oktober 2017 um 16:39:01, schrieb racoon <xraco...@gmx.de>

On 20.10.2017 12:20, Kornel Benko wrote:

Am Freitag, 20. Oktober 2017 um 08:50:57, schrieb racoon <xraco...@gmx.de>

On 19.10.2017 15:25, Kornel Benko wrote:

Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de>

My documents do not show the "Notes" list in the Outline pane in beta1.
Is that a bug?

Daniel


Insert a note first?

Kornel


Yes, I have plenty of them. Does your question suggest that it works for
you?

Daniel


Yes, I tried with every note type.

Kornel


That is strange then.

Daniel


What about MWE?

Kornel



Attached. Also a screenshot of what I (not) see.

Maybe I messed up my UI with some customizations? Is there a way to edit 
the lists that show up?


Daniel


a_note.lyx
Description: application/lyx


Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported

2017-10-20 Thread racoon

On 20.10.2017 23:56, Scott Kostyshak wrote:

Please make sure to add your thoughts to the ticket, so they don't get
lost.


Done. http://www.lyx.org/trac/ticket/3072#comment:11

Daniel



Re: List of notes not in beta1

2017-10-20 Thread racoon

On 20.10.2017 12:20, Kornel Benko wrote:

Am Freitag, 20. Oktober 2017 um 08:50:57, schrieb racoon <xraco...@gmx.de>

On 19.10.2017 15:25, Kornel Benko wrote:

Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de>

My documents do not show the "Notes" list in the Outline pane in beta1.
Is that a bug?

Daniel


Insert a note first?

Kornel


Yes, I have plenty of them. Does your question suggest that it works for
you?

Daniel


Yes, I tried with every note type.

Kornel


That is strange then.

Daniel



Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported

2017-10-20 Thread racoon

On 20.10.2017 11:06, racoon wrote:
For example, if a column with a \cmidrule underneath is set to "align 
center" then this should be inherited by its \cmidrule, i.e.


\cmidrule(c){...}
Or maybe if all columns just below a \cmidrule are set to "align 
center"? In this way it is still possible to use some other custom 
distribution of columns.


Daniel



Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported

2017-10-20 Thread racoon
Maybe some arguments of \cmidrule could be set automatically without 
additional UI?


For example, if a column with a \cmidrule underneath is set to "align 
center" then this should be inherited by its \cmidrule, i.e.


\cmidrule(c){...}

Also, a \cmidrule should never stretch over more than one (multi)column. 
This makes possible to to have rules with small breaks in between.


See both cases here in action here:

https://tex.stackexchange.com/a/60604/36836

I know that this might not be the wanted result in all cases. But maybe 
it is what is wanted in almost all cases. And once a UI gets implemented 
to set these optional arguments, in the Border dialog or so, then this 
could override the default as outlined above.


Daniel



Show changes don't work properly with display math

2017-10-20 Thread racoon
Open and typeset the attached file with a deleted text immediately 
followed by a display math (the way one should typeset display math 
without extra space in LyX) and active show changes. It shows both the 
original results without deletions and the actual results.


Notes:
The main problem is shown at 2 compared to 1 where the display math is 
translated to the top.


But there is also a minor problem. When preceded by a new paragraph, as 
shown in 3 and 4, the display math is translated to the right and bottom 
which does not seem fully correct either.


(The result is independent of the enumerations.)

Daniel


show_changes_display_math.lyx
Description: application/lyx


Show changes don't work with URL (and maybe other insets)

2017-10-20 Thread racoon
Open and typeset the attached file with a deleted URL and active show 
changes. It shows both the actual and expected result.


Notes: While the current algorithm seems fine for some insets, like 
footnotes, it falters at other insets, like URL, which do not interpret 
its content as LaTeX code.


Daniel


show_changes_url.lyx
Description: application/lyx


Re: List of notes not in beta1

2017-10-19 Thread racoon

On 19.10.2017 15:25, Kornel Benko wrote:

Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de>

My documents do not show the "Notes" list in the Outline pane in beta1.
Is that a bug?

Daniel


Insert a note first?

Kornel

Yes, I have plenty of them. Does your question suggest that it works for 
you?


Daniel



List of notes not in beta1

2017-10-19 Thread racoon
My documents do not show the "Notes" list in the Outline pane in beta1. 
Is that a bug?


Daniel



Wrong citation preview format

2017-10-18 Thread racoon

Hi!

I noticed that in beta1 the preview of the second type of author format, 
in the list in the citation dialog and the work area, is wrong. It 
should display as


Author (Year, After)

but displays as

Author (Year), After

Best,
Daniel



Re: Windows: bring window to front

2017-10-17 Thread racoon

On 17.10.2017 06:42, Scott Kostyshak wrote:

On Mon, Oct 16, 2017 at 01:09:34PM +, racoon wrote:

Hi,

Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If
so, it seems not to work. If not, maybe it can make it to rc1?


The patch is in beta1. If the feature doesn't work, then that means the
fix didn't work for you.


Yes, when opening LyX files from the explorer, LyX still does not come 
to the top.


Strange, I thought I tested the patch before and it worked. But I 
probably did not try it from the explorer but rather from the command 
line. I am not sure there is a difference wrt the problem.




Equation tracked changes and slight paint issues

2017-10-16 Thread racoon

Hi

Open the attached file.

First, it seems that the underline for tracked inserts on display 
equations is at the correct position now. However, the hook that marks 
the end of a paragraph did not move with it.


Second, to the slight paint issues:

- Select the z below the display equation.

Now, part of the hook disappears. I guess this would be fixed by moving 
the hook to the right bottom corner as suggested above.


- Press and hold behind the z and move up slightly with the mouse cursor 
without selecting anything.


Now, not only disappears part of the hook but also the underline.

Best,
Daniel





tracked changes paint issue.lyx
Description: application/lyx


Windows: bring window to front

2017-10-16 Thread racoon

Hi,

Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? 
If so, it seems not to work. If not, maybe it can make it to rc1?


Daniel



Re: Beta1 is slow on undo

2017-10-09 Thread racoon

On 09.10.2017 07:28, Scott Kostyshak wrote:

On Sun, Oct 08, 2017 at 03:01:49PM +, Richard Heck wrote:

On 10/08/2017 10:19 AM, racoon wrote:

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any
bibliography. Test case attached.


That would make sense, at least in so far as bibliography handling was
changed a lot. But it's hard to imagine why it would affect undo. Do we
re-read the bibliography or something now after an undo?


Bisect points to 02847641. I want to emphasize though that I only see a
very minor increase in slowness. I would not have realized it if it
weren't pointed out. It is certainly not a second delay for me. So
perhaps this is not the change that Richard and racoon are seeing.


I think Richard mentioned as well that he does not get that much delay 
either. It might be due to my archaic system (Windows 7 Core 2 Duo @ 1.8 
GHz). I know I should try to get a new one.. But so far I have been able 
to use LyX with full satisfaction. And there may be others on slow machines.


Daniel



Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 16:19, racoon wrote:

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.


I just wanted to add that, at least on my slow machine, this delay is a 
bit annoying since sometimes I am not sure whether the undo was done and 
execute it again leaving me with uncertainty what exactly was undone. So 
I have to go back and forth in the undo sequence to figure out where I 
am in it.




Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.




test_undo_2.3.lyx
Description: application/lyx


Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Yes, those documents are fine at my side as well. I'll try to send a 
test case soon.





Beta1 is slow on undo

2017-10-07 Thread racoon

Hi,

I noticed that beta1 shows some slowness when undoing with some of my 
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a 
second to respond to it.


Did anyone notice this? I don't have a very fast computer though.

Best,

Daniel



Re: Strange itemize and selection in LyX 2.3beta1

2017-09-25 Thread racoon

On 24.09.2017 22:55, Jean-Marc Lasgouttes wrote:

Le 24/09/2017 à 20:15, racoon a écrit :

Sorry, just realized that I know how to reproduce:

1. Set Math Indentation (Document Settings)
2. Start a line with an inline math

The line will be indented (although I guess that should happen only 
with non-inline math) and the selection behaves strange.


My fault. Should be fixed now.


Yes, works now. Thanks!

Daniel



Re: Strange itemize and selection in LyX 2.3beta1

2017-09-24 Thread racoon

Sorry, just realized that I know how to reproduce:

1. Set Math Indentation (Document Settings)
2. Start a line with an inline math

The line will be indented (although I guess that should happen only with 
non-inline math) and the selection behaves strange.


Daniel

On 24.09.2017 20:08, racoon wrote:

Hi,

While writing in LyX 2.3beta1 I noticed a couple of times a strange 
problem. In the attached file the sub itemize item is too far to the 
right and selection from the end of that item with the mouse behaves 
strange.


Unfortunately, I don't know the steps to reproduce it. Maybe someone of 
you has an idea.


Daniel





Strange itemize and selection in LyX 2.3beta1

2017-09-24 Thread racoon

Hi,

While writing in LyX 2.3beta1 I noticed a couple of times a strange 
problem. In the attached file the sub itemize item is too far to the 
right and selection from the end of that item with the mouse behaves 
strange.


Unfortunately, I don't know the steps to reproduce it. Maybe someone of 
you has an idea.


Daniel


lyx2.3.lyx
Description: application/lyx


Re: Where are the preferences reset?

2017-09-08 Thread racoon

On 08.09.2017 14:11, Jürgen Spitzmüller wrote:

Am Freitag, den 08.09.2017, 07:32 +0200 schrieb racoon:

Hi,

Can someone point me to the place where the preferences modules are
reset when opening the Preferences for the second time, e.g. after
clicking Cancel the first time and then reopening it?

More specifically, I am looking for the resetting of colors. I
believe
that the colors are initially set in the constructor
"PrefColors::PrefColors" (GuiPrefs.cpp) but only when opening the
Preferences dialog for the first time. Where are they set when
opening
the second time?


Probably

PrefColors::updateRC


Works! Thanks.

Daniel




Re: Setting milestone for inverted cursor

2017-09-08 Thread racoon

On 08.09.2017 07:24, racoon wrote:

On 08.09.2017 02:45, Richard Heck wrote:

On 09/07/2017 09:00 AM, racoon wrote:

Maybe someone can set a reasonable milestone for an inverted cursor,
as is common to have in apps that can have different text colors and
backgrounds?

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


You should be able to do that?


I have no idea what to set it to. 2.3.0?


Ah. Isn't 2.3.0 closed for changes? In that case maybe 2.3.1? But isn't 
that the quick release version in case something needs to be quickly 
fixed with 2.3.0? Maybe 2.3.2 then? Anyway, I have set it to 2.3.1 for 
now. Just let me know if that isn't correct.


Daniel




Where are the preferences reset?

2017-09-07 Thread racoon

Hi,

Can someone point me to the place where the preferences modules are 
reset when opening the Preferences for the second time, e.g. after 
clicking Cancel the first time and then reopening it?


More specifically, I am looking for the resetting of colors. I believe 
that the colors are initially set in the constructor 
"PrefColors::PrefColors" (GuiPrefs.cpp) but only when opening the 
Preferences dialog for the first time. Where are they set when opening 
the second time?


Daniel



Re: Setting milestone for inverted cursor

2017-09-07 Thread racoon

On 08.09.2017 02:45, Richard Heck wrote:

On 09/07/2017 09:00 AM, racoon wrote:

Maybe someone can set a reasonable milestone for an inverted cursor,
as is common to have in apps that can have different text colors and
backgrounds?

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


You should be able to do that?


I have no idea what to set it to. 2.3.0?




Setting milestone for inverted cursor

2017-09-07 Thread racoon
Maybe someone can set a reasonable milestone for an inverted cursor, as 
is common to have in apps that can have different text colors and 
backgrounds?


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

Daniel



Re: Fix for vertical table border for added column

2017-08-24 Thread racoon

On 24.08.2017 16:16, Kornel Benko wrote:

Am Donnerstag, 24. August 2017 um 12:34:47, schrieb racoon <xraco...@gmx.de>
...

I am selecting (row 3, column 1) to (row 4, column 4).


3.) add the bottom of the row


In the dialog I click on the bottom of the previewed cell.


4.) use apply ==> the bottom line disappears


Use Apply ==> I get double lines below each cell within the selection.
But what is weird is that double lines to the left (except for the last)
are added too.


Now, this is weird, I don't get _any_ double lines here.


Okay, I need to check. Were you on latest master or beta?


Did I miss something?


Now try the same with the menu bar, this time it works.


I guess you mean tool bar? This time I get only double lines below each
cell.


Yes, I meant the tool bar.


Now, is there a relation to the patch I posted? Or maybe to something
else I said about adding a separate function for double lines? I still
don't see the relation.


I don't remember I made the relation. Merely seeing discrepancies in handling 
of borders.
And since you were at this, I felt I may as well mention it.
Sorry if that feels inappropriate.


No not inappropriate. Just unexpected and left me guessing.

Daniel



Re: Fix for vertical table border for added column

2017-08-23 Thread racoon

On 23.08.2017 20:39, Kornel Benko wrote:

Am Mittwoch, 23. August 2017 um 20:20:46, schrieb racoon <xraco...@gmx.de>

On 22.08.2017 18:20, Kornel Benko wrote:

Am Dienstag, 22. August 2017 um 09:30:48, schrieb racoon <xraco...@gmx.de>

On 21.08.2017 23:32, Kornel Benko wrote:

Am Montag, 21. August 2017 um 22:24:10, schrieb racoon <xraco...@gmx.de>

Playing with the new settings now ...
It is somehow requiring getting used to ... but I like it.


I am not sure I follow. What "new settings"?

Daniel


I am able to set arbitrary borders with the table toolbar, but
with the tabular settings dialog it is often not possible.

Kornel



Sorry, I am slow. I still don't know what you mean. Is that something
related to my patch of the add row/column or set all borders table toolbar?

Daniel


I mean the dialog you get with
right-click in a table -> Settings... -> Borders


Okay, so what about it? I am still lost in how this is related to my
patch, if it is.

Also, you say that you are able to set some borders with the toolbar
that you cannot with the dialog. Do you have an example?

And, you say that you can set arbitrary borders with the table toolbar.
Can you set double borders on the outermost border of the table?


I am still not getting it.


No, I was referring to the inner borders.

For instance, in the attached example:


The attached example has a 5x4 table with single border lines set.


1.) Open the dialog border


So I click second click into the table and choose

* Settings... -> Borders


2.) select fields 3.1 ..4.4


I am selecting (row 3, column 1) to (row 4, column 4).


3.) add the bottom of the row


In the dialog I click on the bottom of the previewed cell.


4.) use apply ==> the bottom line disappears


Use Apply ==> I get double lines below each cell within the selection. 
But what is weird is that double lines to the left (except for the last) 
are added too.


Did I miss something?


Now try the same with the menu bar, this time it works.


I guess you mean tool bar? This time I get only double lines below each 
cell.


Now, is there a relation to the patch I posted? Or maybe to something 
else I said about adding a separate function for double lines? I still 
don't see the relation.


Daniel



Re: Fix for vertical table border for added column

2017-08-23 Thread racoon

On 22.08.2017 18:20, Kornel Benko wrote:

Am Dienstag, 22. August 2017 um 09:30:48, schrieb racoon <xraco...@gmx.de>

On 21.08.2017 23:32, Kornel Benko wrote:

Am Montag, 21. August 2017 um 22:24:10, schrieb racoon <xraco...@gmx.de>

Playing with the new settings now ...
It is somehow requiring getting used to ... but I like it.


I am not sure I follow. What "new settings"?

Daniel


I am able to set arbitrary borders with the table toolbar, but
with the tabular settings dialog it is often not possible.

Kornel



Sorry, I am slow. I still don't know what you mean. Is that something
related to my patch of the add row/column or set all borders table toolbar?

Daniel


I mean the dialog you get with
right-click in a table -> Settings... -> Borders


Okay, so what about it? I am still lost in how this is related to my 
patch, if it is.


Also, you say that you are able to set some borders with the toolbar 
that you cannot with the dialog. Do you have an example?


And, you say that you can set arbitrary borders with the table toolbar. 
Can you set double borders on the outermost border of the table?


Daniel



Re: Fix for vertical table border for added column

2017-08-21 Thread racoon

On 21.08.2017 23:32, Kornel Benko wrote:

Am Montag, 21. August 2017 um 22:24:10, schrieb racoon <xraco...@gmx.de>

Playing with the new settings now ...
It is somehow requiring getting used to ... but I like it.


I am not sure I follow. What "new settings"?

Daniel


I am able to set arbitrary borders with the table toolbar, but
with the tabular settings dialog it is often not possible.

Kornel



Sorry, I am slow. I still don't know what you mean. Is that something 
related to my patch of the add row/column or set all borders table toolbar?


Daniel



Re: Fix for vertical table border for added column

2017-08-21 Thread racoon

On 21.08.2017 22:31, Jean-Marc Lasgouttes wrote:

Le 21/08/2017 à 14:54, racoon a écrit :
I manually applied the second patch now. There was a missing line in 
your patch ...

    -    // fall through


Sorry for the inconvenience. I don't know how the comment got missing.


The was changed recently by Juergen. You should update your tree 
(equivalent to a "git pull") and your commit will be updated against the 
latest master (if everything goes right :).


Thanks! I did a "git pull -- rebase" on the master. But it seems neither 
to affect the branch I created for the table fixes, nor the patches I 
create relative to master.


When I do a "git pull" on my branch I get the following message:

"There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.

git pull  

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/ SomeTableFixes"

So what is the right command here?

Daniel



  1   2   3   4   >