Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Scott Kostyshak
On Sat, Feb 15, 2020 at 10:26:15PM -0500, Richard Kimberly Heck wrote:
> On 2/15/20 10:07 PM, Scott Kostyshak wrote:
> >
> >> I'm curious, why is it necessary to support Python 2?
> > I forget what the discussion is regarding why we chose those versions.
> > From what I understand, requiring 2.7 (as opposed to some earlier 2.x)
> > makes things easier. Probably we will not allow 2.7 after some time or
> > whenever it would be a pain to maintain 2.7 compatibility for a
> > particular issue.
> 
> It's only quite recently that we've managed to make all of our scripts
> compatible with Python 3. Like, in the 2.3.x series? The reason why we
> did not just switch to Python 3 had originally to do with two things, I
> think. First, the Windows installer has used Python 2 for a while, and
> we are reluctant to change that lest we break things. Second, there have
> long been issues about detecting the right version of Python, especially
> (again) on Windows.

Thanks for the explanation. That makes sense.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Richard Kimberly Heck
On 2/15/20 10:07 PM, Scott Kostyshak wrote:
>
>> I'm curious, why is it necessary to support Python 2?
> I forget what the discussion is regarding why we chose those versions.
> From what I understand, requiring 2.7 (as opposed to some earlier 2.x)
> makes things easier. Probably we will not allow 2.7 after some time or
> whenever it would be a pain to maintain 2.7 compatibility for a
> particular issue.

It's only quite recently that we've managed to make all of our scripts
compatible with Python 3. Like, in the 2.3.x series? The reason why we
did not just switch to Python 3 had originally to do with two things, I
think. First, the Windows installer has used Python 2 for a while, and
we are reluctant to change that lest we break things. Second, there have
long been issues about detecting the right version of Python, especially
(again) on Windows.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Valgrind "definitely lost" backtrace

2020-02-15 Thread Scott Kostyshak
On Sat, Feb 15, 2020 at 09:42:52PM +0100, Pavel Sanda wrote:
> On Fri, Feb 14, 2020 at 08:09:09PM -0500, Scott Kostyshak wrote:
> > Thanks to both of you for taking a look. I was hoping to investigate
> > this memory leak but it seems to be beyond my knowledge.
> 
> Do you have recipy to reproduce valgrind's warning?

I'll play around with it and see if I can reproduce.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Scott Kostyshak
On Sat, Feb 15, 2020 at 09:25:40PM +0100, Kornel Benko wrote:
> Am Sat, 15 Feb 2020 21:15:17 +0100
> schrieb Kornel Benko :
> 
> > Am Sat, 15 Feb 2020 14:03:43 -0500
> > schrieb Scott Kostyshak :
> > 
> > > Attached is a patch for lyxpreview_tools.py, but I don't know Python
> > > well and I don't know how to test whether this code works as intended
> > > now or not. All I know is it gets rid of the error.
> > > 
> > > I originally saw that error on master when opening the User Guide with
> > > Preview enabled.
> > > 
> > > Can someone give the patch a check?
> > > 
> > > Best,
> > > 
> > > Scott  
> > 
> > Definitely better as the original. Works here as expected.
> > Still one element making problems:
> > Warning: Failed to produce 1 preview snippet(s)
> > Looking at the lyxpreviewkn4998.log here, looks like it is not related to 
> > your patch.
> > 
> > Preview: Snippet 85 338603 0 465893
> > [85]
> > ! Undefined control sequence.
> > l.628 x^{2}-2x-2\Rightarrow\question
> > 
> > {x_{1}}\answer{x_{2}}=1\question{+\sqrt{...
> > The control sequence at the end of the top line
> > of your error message was never \def'ed. If you have
> > misspelled it (e.g., `\hobx'), type `I' and the correct
> > spelling (e.g., `I\hbox'). Otherwise just continue,
> > and I'll forget about whatever was undefined.
> > 
> > Other snippets are OK.
> > 
> > Kornel
> 
> OK, found the offending piece, attached

I see the same. I guess it's difficult to expect it to work there, since
it requires a \newcommand that is defined in a previous paragraph. I
thought I could be sneaky and fix it by wrapping the \newcommand TeX box
in a preview inset, but that didn't work. Even the following gives an
undefined error since I guess the scope of the \newcommand is local to
the preview environment (?):

  \begin{preview}
  \newcommand{\question}[1]{#1}
  \newcommand{\answer}[1]{}
  \end{preview}
  
  \begin{preview}
  
  \[
  
x^{2}-2x-2\Rightarrow\question{x_{1}}\answer{x_{2}}=1\question{+\sqrt{3}}\answer{-\sqrt{3}}.
  \]
  
  \end{preview}

That would have been a hackish patch anyway.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Scott Kostyshak
On Sat, Feb 15, 2020 at 07:46:56PM +, Neven Sajko wrote:
> Hmm, after looking at the last few commits, it seems this may be a
> more involved issue
> than I first thought. On the one hand one has to take care to use the
> proper choice
> between "Unicode" and "byte" strings,

Thanks for the suggestions on the patch, Neven. Your alternative
suggestions give me something to look into and learn more about Python
quoting and encoding.

> on the other hand it seems like
> the Lyx guys want
> the script to work for both Python 2 and Python 3.

The current 2.4.0dev README says the following:

  Python (2.7 or 3.5 and newer) to convert old LyX files and for
  helper scripts.

> I'm curious, why is it necessary to support Python 2?

I forget what the discussion is regarding why we chose those versions.
From what I understand, requiring 2.7 (as opposed to some earlier 2.x)
makes things easier. Probably we will not allow 2.7 after some time or
whenever it would be a pain to maintain 2.7 compatibility for a
particular issue.

Best,

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Scott Kostyshak
On Sun, Feb 16, 2020 at 01:37:34AM +0100, Enrico Forestieri wrote:
> On Sat, Feb 15, 2020 at 02:03:43PM -0500, Scott Kostyshak wrote:
> 
> > Attached is a patch for lyxpreview_tools.py, but I don't know Python
> > well and I don't know how to test whether this code works as intended
> > now or not. All I know is it gets rid of the error.
> > 
> > I originally saw that error on master when opening the User Guide with
> > Preview enabled.
> > 
> > Can someone give the patch a check?
> 
> I think your patch is correct. Initially it was rb"..." but this gives a
> syntax error with python2. I changed it to b"..." but forgot to escape the
> backslashes (without r, to get a backslash you have to write two of them).

Thanks for taking a look, Enrico. Pushed at 562917dc.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Stephan Witt
Am 16.02.2020 um 01:25 schrieb Enrico Forestieri :
> 
> On Sat, Feb 15, 2020 at 04:09:14PM +0100, Stephan Witt wrote:
>> Am 15.02.2020 um 15:31 schrieb Enrico Forestieri :
>>> 
>>> On Sat, Feb 15, 2020 at 02:41:19PM +0100, Stephan Witt wrote:
 
 I came up with another path. IMHO easier to understand. 
 And it works with all variants of Qt and input.
>>> 
>>> Unfortunately, it confuses me more than the previous one.
>>> Please, can you apply the attached debug patch and report the
>>> results you obtain with both Qt 5.9 and 5.12?
>> 
>> Here you are:
>> 
>> version: 5.9.8
>> file_name: 
>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
>> abstmp:
>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712
>> realtmp:   
>> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712
>> 
>> Qt version: 5.12.3
>> file_name: 
>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
>> abstmp:
>> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp
>> realtmp:   
>> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp
> 
> Something really fishy is going on here. Note that you get the *same*
> file_name with both 5.9.8 and 5.12.3. This is already really strange,
> but the stranger thing is that the last component of abstmp and realtmp
> changes, becoming lyx_tmpdir.rHrJLJU14712 in one case and
> lyx_tmpdir.BOxdOihSBXEp in the other one. Seemingly, they are unrelated
> to file_name…

To simplify my testing I’m using the mini-buffer command input to debug the
whole thing. I’ve used the arrow up in mini-buffer to repeat the previous 
command.
Sorry for not telling you this.

The entire point is: if you send the file name with private prefix and receive 
the 
file name without it it works with Qt-5.9 and break with Qt-5.12 because 
Qt-folks
decided to use the real path name as result of QDir::tempPath().

We have no control over Qt and over Skim.

That’s my situation with Qt-5.12.

Did you try my patch and did you saw any problem with it on Linux?

> I tried to reproduce your configuration on linux by creating a /tmpriv
> symlink pointing to /private/tmp and trying to set the temporary dir
> to /tmpriv. I did non succeed because it seems that the temporary
> directory cannot be changed and is always /tmp, whatever you set
> in Preferences->Paths->Temporary directory !

Yes, probably it’s platform specific if it’s /tmp or 
/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn

The latter is simply more secure.

Stephan

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Enrico Forestieri
On Sat, Feb 15, 2020 at 02:03:43PM -0500, Scott Kostyshak wrote:

> Attached is a patch for lyxpreview_tools.py, but I don't know Python
> well and I don't know how to test whether this code works as intended
> now or not. All I know is it gets rid of the error.
> 
> I originally saw that error on master when opening the User Guide with
> Preview enabled.
> 
> Can someone give the patch a check?

I think your patch is correct. Initially it was rb"..." but this gives a
syntax error with python2. I changed it to b"..." but forgot to escape the
backslashes (without r, to get a backslash you have to write two of them).

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Enrico Forestieri
On Sat, Feb 15, 2020 at 04:09:14PM +0100, Stephan Witt wrote:
> Am 15.02.2020 um 15:31 schrieb Enrico Forestieri :
> > 
> > On Sat, Feb 15, 2020 at 02:41:19PM +0100, Stephan Witt wrote:
> >> 
> >> I came up with another path. IMHO easier to understand. 
> >> And it works with all variants of Qt and input.
> > 
> > Unfortunately, it confuses me more than the previous one.
> > Please, can you apply the attached debug patch and report the
> > results you obtain with both Qt 5.9 and 5.12?
> 
> Here you are:
> 
> version: 5.9.8
> file_name: 
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
> abstmp:
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712
> realtmp:   
> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712
> 
> Qt version: 5.12.3
> file_name: 
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
> abstmp:
> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp
> realtmp:   
> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp

Something really fishy is going on here. Note that you get the *same*
file_name with both 5.9.8 and 5.12.3. This is already really strange,
but the stranger thing is that the last component of abstmp and realtmp
changes, becoming lyx_tmpdir.rHrJLJU14712 in one case and
lyx_tmpdir.BOxdOihSBXEp in the other one. Seemingly, they are unrelated
to file_name...

I tried to reproduce your configuration on linux by creating a /tmpriv
symlink pointing to /private/tmp and trying to set the temporary dir
to /tmpriv. I did non succeed because it seems that the temporary
directory cannot be changed and is always /tmp, whatever you set
in Preferences->Paths->Temporary directory !

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Valgrind "definitely lost" backtrace

2020-02-15 Thread Pavel Sanda
On Fri, Feb 14, 2020 at 08:09:09PM -0500, Scott Kostyshak wrote:
> Thanks to both of you for taking a look. I was hoping to investigate
> this memory leak but it seems to be beyond my knowledge.

Do you have recipy to reproduce valgrind's warning?

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Kornel Benko
Am Sat, 15 Feb 2020 21:15:17 +0100
schrieb Kornel Benko :

> Am Sat, 15 Feb 2020 14:03:43 -0500
> schrieb Scott Kostyshak :
> 
> > Attached is a patch for lyxpreview_tools.py, but I don't know Python
> > well and I don't know how to test whether this code works as intended
> > now or not. All I know is it gets rid of the error.
> > 
> > I originally saw that error on master when opening the User Guide with
> > Preview enabled.
> > 
> > Can someone give the patch a check?
> > 
> > Best,
> > 
> > Scott  
> 
> Definitely better as the original. Works here as expected.
> Still one element making problems:
>   Warning: Failed to produce 1 preview snippet(s)
> Looking at the lyxpreviewkn4998.log here, looks like it is not related to 
> your patch.
> 
> Preview: Snippet 85 338603 0 465893
> [85]
> ! Undefined control sequence.
> l.628 x^{2}-2x-2\Rightarrow\question
> 
> {x_{1}}\answer{x_{2}}=1\question{+\sqrt{...
> The control sequence at the end of the top line
> of your error message was never \def'ed. If you have
> misspelled it (e.g., `\hobx'), type `I' and the correct
> spelling (e.g., `I\hbox'). Otherwise just continue,
> and I'll forget about whatever was undefined.
> 
> Other snippets are OK.
> 
>   Kornel

OK, found the offending piece, attached

Kornel


pgpueSVJMO1an.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Questions regarding compiler warnings

2020-02-15 Thread Pavel Sanda
On Thu, Feb 13, 2020 at 06:28:05PM +0100, Jean-Marc Lasgouttes wrote:
> >I can replace asserts with explicit checks if you agree.
> >Or completely delete those checks because for most of them getStatus won't 
> >let
> >you in without buffer anyway.
> 
> Either solution will be OK. And do not forget #11725 ;)

It's in. #11725 is very old ghost :) P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Kornel Benko
Am Sat, 15 Feb 2020 14:03:43 -0500
schrieb Scott Kostyshak :

> Attached is a patch for lyxpreview_tools.py, but I don't know Python
> well and I don't know how to test whether this code works as intended
> now or not. All I know is it gets rid of the error.
> 
> I originally saw that error on master when opening the User Guide with
> Preview enabled.
> 
> Can someone give the patch a check?
> 
> Best,
> 
> Scott

Definitely better as the original. Works here as expected.
Still one element making problems:
Warning: Failed to produce 1 preview snippet(s)
Looking at the lyxpreviewkn4998.log here, looks like it is not related to your 
patch.

Preview: Snippet 85 338603 0 465893
[85]
! Undefined control sequence.
l.628 x^{2}-2x-2\Rightarrow\question
{x_{1}}\answer{x_{2}}=1\question{+\sqrt{...
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

Other snippets are OK.

Kornel


pgppdDs5Csaze.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Neven Sajko
Hmm, after looking at the last few commits, it seems this may be a
more involved issue
than I first thought. On the one hand one has to take care to use the
proper choice
between "Unicode" and "byte" strings, on the other hand it seems like
the Lyx guys want
the script to work for both Python 2 and Python 3.

I'm curious, why is it necessary to support Python 2?

Regards,
Neven Sajko
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Neven Sajko
Actually, do something like this (no "using distributivity" like in my
first message, to get a minimal git diff)

def_re = 
re.compile(r"(\newcommandx|\renewcommandx|\global\long\def)(\[a-zA-Z]+)(.+)")

Regards,
Neven Sajko
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Neven Sajko
Two notes: it would be better to use raw strings (r"string") and to maybe do
r"\(a|b|c|d)" instead of r"(\a|\b|\c|\d)" (use distributivity, in other words).

So, I think you want this:

def_re = 
re.compile(r"\(newcommandx|renewcommandx|global\long\def)(\[a-zA-Z]+)(.+)")

Regards,
Neven Sajko
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1826

2020-02-15 Thread ci-lyx
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/1826/
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


[PATCH] lyxpreview_tools.py: fix a regular expression

2020-02-15 Thread Scott Kostyshak
Attached is a patch for lyxpreview_tools.py, but I don't know Python
well and I don't know how to test whether this code works as intended
now or not. All I know is it gets rid of the error.

I originally saw that error on master when opening the User Guide with
Preview enabled.

Can someone give the patch a check?

Best,

Scott
From b3e30d0f2c21d195415e7d44fbf7b9d17d084c52 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Sat, 15 Feb 2020 13:27:45 -0500
Subject: [PATCH] lyxpreview_tools.py: fix a regular expression

Three backslashes are needed before a LaTeX command, not one. Before
this commit, the code gave the following error with Python >= 3.6:

  re.error: bad escape \g at position 29

This error was introduced with Python 3.6, as documented [1] by the
following line of documentation:

  Changed in version 3.6: Unknown escapes in pattern consisting of
  '\' and an ASCII letter now are errors.

Although previous Python versions did not give an error, the regular
expression was not working as intended: for example, the "\\n" in
"\\newcommandx" would be interpreted as a new line.

[1] https://docs.python.org/3.6/library/re.html#re.sub
---
 lib/scripts/lyxpreview_tools.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/scripts/lyxpreview_tools.py b/lib/scripts/lyxpreview_tools.py
index 05c5aad616..93964083a5 100644
--- a/lib/scripts/lyxpreview_tools.py
+++ b/lib/scripts/lyxpreview_tools.py
@@ -219,7 +219,7 @@ def write_metrics_info(metrics_info, metrics_file):
 # Reads a .tex files and create an identical file but only with
 # pages whose index is in pages_to_keep
 def filter_pages(source_path, destination_path, pages_to_keep):
-def_re = re.compile(b"(\\newcommandx|\\renewcommandx|\\global\\long\\def)(\\[a-zA-Z]+)(.+)")
+def_re = re.compile(b"(newcommandx|renewcommandx|globallongdef)(\\[a-zA-Z]+)(.+)")
 source_file = open(source_path, "rb")
 destination_file = open(destination_path, "wb")
 
-- 
2.20.1



signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Building windows installer questions

2020-02-15 Thread Richard Kimberly Heck
On 2/15/20 6:26 AM, Yu Jin wrote:
> Looks like I got it working now. Here few more questions:
> 1. How to do the GPG signature?

Only a few of us can do that, because only a few of us have the key, for
obvious reasons. If you want to send yours to me---just put it somewhere
I can download it---then I can make a signature for it.

FYI, I updated ImageMagick in the most recent installers. I haven't
uploaded the new stuff yet to the dependencies file online.


> 2. Are we bothering with the 64 bit version?

I have not to this point. Uwe (who used to maintain the installer) never
did, though I am not sure why. It probably would not be that difficult
to do, at least for testing.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Stephan Witt
Am 15.02.2020 um 15:31 schrieb Enrico Forestieri :
> 
> On Sat, Feb 15, 2020 at 02:41:19PM +0100, Stephan Witt wrote:
>> 
>> I came up with another path. IMHO easier to understand. 
>> And it works with all variants of Qt and input.
> 
> Unfortunately, it confuses me more than the previous one.
> Please, can you apply the attached debug patch and report the
> results you obtain with both Qt 5.9 and 5.12?

Here you are:

version: 5.9.8
file_name: 
/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
abstmp:
/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712
realtmp:   
/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.rHrJLJU14712

Qt version: 5.12.3
file_name: 
/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.aScQxky52159/lyx_tmpbuf0/Tutorial.tex
abstmp:
/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp
realtmp:   
/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.BOxdOihSBXEp

The question is: to be private or not.

The idea is as follows:
1. file_name may be private or not -> convert it to real path -> private
2. buffers temporary directory may be private or not -> check it 
(using the internal info buffer’s using abstmp as base - not good)
3. if abstemp and realtmp are different make real path of file_name abstemp 
based

Stephan
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Enrico Forestieri
On Sat, Feb 15, 2020 at 02:41:19PM +0100, Stephan Witt wrote:
> 
> I came up with another path. IMHO easier to understand. 
> And it works with all variants of Qt and input.

Unfortunately, it confuses me more than the previous one.
Please, can you apply the attached debug patch and report the
results you obtain with both Qt 5.9 and 5.12?

-- 
Enrico
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index eec1b7ae6e..36b06130c7 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -3678,6 +3678,10 @@ bool GuiView::goToFileRow(string const & argument)
Buffer * buf = 0;
string const abstmp = package().temp_dir().absFileName();
string const realtmp = package().temp_dir().realPath();
+   lyxerr << "Qt version: " << qVersion() << endl;
+   lyxerr << "file_name: " << file_name << endl;
+   lyxerr << "abstmp:" << abstmp << endl;
+   lyxerr << "realtmp:   " << realtmp << endl;
// We have to use os::path_prefix_is() here, instead of
// simply prefixIs(), because the file name comes from
// an external application and may need case adjustment.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Stephan Witt
Am 15.02.2020 um 13:12 schrieb Enrico Forestieri :
> 
> On Fri, Feb 14, 2020 at 10:10:06PM +0100, Stephan Witt wrote:
>> Am 14.02.2020 um 21:00 schrieb Stephan Witt :
>>> 
>>> Hi all,
>>> 
>>> I’ve a problem in LyX master with reverse search I don’t have in 2.3.x.
>>> Unfortunately I cannot see the difference in LyX code causing it.
>>> 
>>> The situation is: on Mac the directory /var is an symlink to private/var.
>>> So the temporary files are with real path below /private/var/. The SyncTex
>>> file contains this path name, e.g.
>>> 
>>> Input:1:/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/./Tutorial.tex
>>> 
>>> But the reverse search script is called with file name:
>>> 
>>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/Tutorial.tex
>>> 
>>> Some normalization happens here. I’ve changed the lyxeditor script to see 
>>> the call. It’s not
>>> the operation in line 85 (were sed is used to remove /private from path 
>>> name).
>>> 
>>> To make the GuiView::goToFileRow() implementation more robust I came to the 
>>> attached patch.
>>> 
>>> I’m confident it cannot hurt. But as I don’t understand the situation 
>>> completely I ask for comments.
>> 
>> I think I got it myself. The difference is the Qt5 implementation of 
>> QDir::tempPath() probably.
>> I’ve armed the 2.3.4.2 sources with debug output and with Qt-5.9.8 I get 
>> this:
>> 
>> frontends/qt4/GuiView.cpp (3505): goToFileRow: row 628 in file 
>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126/lyx_tmpbuf0/Tutorial.tex
>> frontends/qt4/GuiView.cpp (3506): goToFileRow: abstmp 
>> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126
>> frontends/qt4/GuiView.cpp (3507): goToFileRow: realtmp 
>> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126
>> 
>> So the correction in LyX goToFileRow implementation is triggered. But with 
>> Qt-5.12.6 this has changed.
>> 
>> What’s your opinion how to solve that?
> 
> I may be dense, but I still fail to see the problem here and thus why your
> patch corrects it.

I don’t like the patch anymore either. Much to complex, IMO.

The problem is as follows:

The buffer lookup uses package().temp_dir().absFileName() as temporary 
directory base name.
This name isn’t the real path of it for Qt-5.9.8 and with Qt-5.12.6 it’s the 
real path name.

One example for the result of package().temp_dir().absFileName() is:

Qt-5.9.8 has 
/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126
Qt-5.12.6 has 
/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126

The path name externally given may be the real path or not. In my case it’s not 
(Skim output).
With this scenario the lookup is done with the non real path but the buffer 
uses the real path
and the lookup fails because of that.

I came up with another path. IMHO easier to understand. 
And it works with all variants of Qt and input.

A more generic fix would be to change the buffer lookup to use real path all 
the time internally.

Stephan



goToFileRow-2.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Enrico Forestieri
On Fri, Feb 14, 2020 at 10:10:06PM +0100, Stephan Witt wrote:
> Am 14.02.2020 um 21:00 schrieb Stephan Witt :
> > 
> > Hi all,
> > 
> > I’ve a problem in LyX master with reverse search I don’t have in 2.3.x.
> > Unfortunately I cannot see the difference in LyX code causing it.
> > 
> > The situation is: on Mac the directory /var is an symlink to private/var.
> > So the temporary files are with real path below /private/var/. The SyncTex
> > file contains this path name, e.g.
> > 
> > Input:1:/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/./Tutorial.tex
> > 
> > But the reverse search script is called with file name:
> > 
> > /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/Tutorial.tex
> > 
> > Some normalization happens here. I’ve changed the lyxeditor script to see 
> > the call. It’s not
> > the operation in line 85 (were sed is used to remove /private from path 
> > name).
> > 
> > To make the GuiView::goToFileRow() implementation more robust I came to the 
> > attached patch.
> > 
> > I’m confident it cannot hurt. But as I don’t understand the situation 
> > completely I ask for comments.
> 
> I think I got it myself. The difference is the Qt5 implementation of 
> QDir::tempPath() probably.
> I’ve armed the 2.3.4.2 sources with debug output and with Qt-5.9.8 I get this:
> 
> frontends/qt4/GuiView.cpp (3505): goToFileRow: row 628 in file 
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126/lyx_tmpbuf0/Tutorial.tex
> frontends/qt4/GuiView.cpp (3506): goToFileRow: abstmp 
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126
> frontends/qt4/GuiView.cpp (3507): goToFileRow: realtmp 
> /private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.akFIHtU22126
> 
> So the correction in LyX goToFileRow implementation is triggered. But with 
> Qt-5.12.6 this has changed.
> 
> What’s your opinion how to solve that?

I may be dense, but I still fail to see the problem here and thus why your
patch corrects it.

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC][PATCH] Change to GuiView::goToFileRow

2020-02-15 Thread Enrico Forestieri
On Fri, Feb 14, 2020 at 09:00:48PM +0100, Stephan Witt wrote:
> Hi all,
> 
> I’ve a problem in LyX master with reverse search I don’t have in 2.3.x.
> Unfortunately I cannot see the difference in LyX code causing it.
> 
> The situation is: on Mac the directory /var is an symlink to private/var.
> So the temporary files are with real path below /private/var/. The SyncTex
> file contains this path name, e.g.
> 
> Input:1:/private/var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/./Tutorial.tex
> 
> But the reverse search script is called with file name:
> 
> /var/folders/1x/zm63s22x7s591xrlgm4rl9v4gn/T/lyx_tmpdir.pfyyHSvCxUfX/lyx_tmpbuf0/Tutorial.tex
> 
> Some normalization happens here. I’ve changed the lyxeditor script to see the
> call. It’s not
> the operation in line 85 (were sed is used to remove /private from path name).
> 
> To make the GuiView::goToFileRow() implementation more robust I came to the
> attached patch.
> 
> I’m confident it cannot hurt. But as I don’t understand the situation
> completely I ask for comments.
> 
> Stephan

> [-- mutt.octet.filter file type: "unified diff output, ASCII text" --]
> 
> diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
> index eec1b7ae6e..f215389adc 100644
> --- a/src/frontends/qt/GuiView.cpp
> +++ b/src/frontends/qt/GuiView.cpp
> @@ -3675,9 +3675,17 @@ bool GuiView::goToFileRow(string const & argument)
>   LYXERR0("Wrong argument: " << argument);
>   return false;
>   }
> + LYXERR(Debug::FILES, "goToFileRow: row " << row << " in file " << 
> file_name);
>   Buffer * buf = 0;
>   string const abstmp = package().temp_dir().absFileName();
> - string const realtmp = package().temp_dir().realPath();
> + string realtmp = package().temp_dir().realPath();
> +
> +#ifdef Q_OS_MAC
> + if (realtmp == abstmp &&
> + os::path_prefix_is(realtmp,"/private/var/",os::CASE_ADJUSTED)) {
> + realtmp = realtmp.substr(8);
> + }
> +#endif
>   // We have to use os::path_prefix_is() here, instead of
>   // simply prefixIs(), because the file name comes from
>   // an external application and may need case adjustment.

I think I don't understand what is the problem. The code snippet you are
changing is as follows:
...
string const abstmp = package().temp_dir().absFileName();
string const realtmp = package().temp_dir().realPath();
// We have to use os::path_prefix_is() here, instead of
// simply prefixIs(), because the file name comes from
// an external application and may need case adjustment.
if (os::path_prefix_is(file_name, abstmp, os::CASE_ADJUSTED)
|| os::path_prefix_is(file_name, realtmp, os::CASE_ADJUSTED)) {
// Needed by inverse dvi search. If it is a file
// in tmpdir, call the apropriated function.
// If tmpdir is a symlink, we may have the real
// path passed back, so we correct for that.
if (!prefixIs(file_name, abstmp))
file_name = subst(file_name, realtmp, abstmp);
buf = theBufferList().getBufferFromTmp(file_name);
} else {
...

meaning that file_name is compared with both abstmp (with possibly
unexpanded symlink) and realtmp (with expanded symlink). Hence both
cases are considered and your patch should not be needed.

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Building windows installer questions

2020-02-15 Thread Yu Jin
Looks like I got it working now. Here few more questions:
1. How to do the GPG signature?
2. Are we bothering with the 64 bit version?

Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1825

2020-02-15 Thread ci-lyx
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/1825/--
[...truncated 1221 lines...]
Making check in autotests
make[1]: Entering directory '/build/workspace/autotests'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/autotests'
Making check in config
make[1]: Entering directory '/build/workspace/config'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/config'
Making check in development
make[1]: Entering directory '/build/workspace/development'
make[2]: Entering directory '/build/workspace/development'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/development'
make[1]: Leaving directory '/build/workspace/development'
Making check in po
make[1]: Entering directory '/build/workspace/po'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/po'
Making check in 3rdparty
make[1]: Entering directory '/build/workspace/3rdparty'
make[2]: Entering directory '/build/workspace/3rdparty'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/3rdparty'
make[1]: Leaving directory '/build/workspace/3rdparty'
Making check in src
make[1]: Entering directory '/build/workspace/src'
  CHK  lyx_commit_hash.h
make  check-recursive
make[2]: Entering directory '/build/workspace/src'
Making check in support
make[3]: Entering directory '/build/workspace/src/support'
make  check-am
make[4]: Entering directory '/build/workspace/src/support'
make  check_convert check_filetools check_lstrings check_trivstring
make[5]: Entering directory '/build/workspace/src/support'
  CXX  tests/check_convert.o
  CXX  tests/dummy_functions.o
  CXX  tests/boost.o
  CXXLDcheck_convert
  CXX  tests/check_filetools.o
  CXXLDcheck_filetools
  CXX  tests/check_lstrings.o
  CXXLDcheck_lstrings
  CXX  tests/check_trivstring.o
  CXXLDcheck_trivstring
make[5]: Leaving directory '/build/workspace/src/support'
make  check-TESTS
make[5]: Entering directory '/build/workspace/src/support'
make[6]: Entering directory '/build/workspace/src/support'
PASS: tests/test_convert
PASS: tests/test_filetools
PASS: tests/test_lstrings
PASS: tests/test_trivstring

Testsuite summary for LyX 2.4.0dev

# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[6]: Leaving directory '/build/workspace/src/support'
make[5]: Leaving directory '/build/workspace/src/support'
make[4]: Leaving directory '/build/workspace/src/support'
make[3]: Leaving directory '/build/workspace/src/support'
Making check in frontends
make[3]: Entering directory '/build/workspace/src/frontends'
Making check in qt
make[4]: Entering directory '/build/workspace/src/frontends/qt'
make  check-am
make[5]: Entering directory '/build/workspace/src/frontends/qt'
make[5]: Nothing to be done for 'check-am'.
make[5]: Leaving directory '/build/workspace/src/frontends/qt'
make[4]: Leaving directory '/build/workspace/src/frontends/qt'
Making check in .
make[4]: Entering directory '/build/workspace/src/frontends'
make  biblio
make[5]: Entering directory '/build/workspace/src/frontends'
  CXX  tests/biblio.o
  CXX  tests/boost.o
  CXXLDbiblio
make[5]: Leaving directory '/build/workspace/src/frontends'
make  check-TESTS
make[5]: Entering directory '/build/workspace/src/frontends'
make[6]: Entering directory '/build/workspace/src/frontends'
PASS: tests/test_biblio

Testsuite summary for LyX 2.4.0dev

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[6]: Leaving directory '/build/workspace/src/frontends'
make[5]: Leaving directory '/build/workspace/src/frontends'
make[4]: Leaving directory '/build/workspace/src/frontends'
make[3]: Leaving directory '/build/workspace/src/frontends'
Making check in .
make[3]: Entering directory '/build/workspace/src'
  CHK  lyx_commit_hash.h
make  check_ExternalTransforms check_Length check_ListingsCaption check_layout
make[4]: Entering directory '/build/workspace/src'
  CXX  tests/check_ExternalTransforms-check_ExternalTransforms.o
  CXX  tests/check_ExternalTransforms-dummy_functions.o
  CXX  tests/check_ExternalTransforms-boost.o
  CXXLDcheck_ExternalTransforms
  CXX  tests/check_Length-check_Length.o
  CXX  tests/check_Length-dummy_functions.o
  CXX  tests/check_Length-boost.o
  CXXLDcheck_Length
  CXX  

Re: [LyX/2.3.x] Cmake build: Remove cmake warnings about mismatched values of FindPackageHandleStandardArgs()

2020-02-15 Thread Stephan Witt
Am 15.02.2020 um 09:28 schrieb Kornel Benko :
> 
> Am Sat, 15 Feb 2020 09:17:53 +0100
> schrieb Kornel Benko :
> 
>> Am Sat, 15 Feb 2020 09:02:45 +0100
>> schrieb Stephan Witt :
>> 
>>> Am 15.02.2020 um 08:32 schrieb Kornel Benko :  
 
 Am Fri, 14 Feb 2020 17:37:28 +0100
 schrieb Stephan Witt :
 
> Changes not staged for commit:
> (use "git add ..." to update what will be committed)
> (use "git checkout -- ..." to discard changes in working directory)
> 
>   modified:   development/cmake/modules/FindHUNSPELL.cmake
> 
> no changes added to commit (use "git add" and/or "git commit -a“)
> ==
> 
> No luck. I’d guess on Windows with case insensitive FS it’s the same.
> 
 
 Should it be not enough to say here:
   git checkout development/cmake/modules/FindHUNSPELL.cmake
   git checkout development/cmake/modules/FindENCHANT.cmake
 ?
>>> 
>>> No. I‘ve tried this already.
>>> 
>>> IMO you can’t have two files with different cases in name only. Didn’t you 
>>> add a
>>> second one instead of rename it? Actually there’s a problem because it’s 
>>> duplicated
>>> and changed.  
>> 
>> No, I did 'git mv'.
>> 
>> Possibly it is better to
>>  git rm; git commit
>>  git add; git commit;
>> 
>>> I can rename it on my end. But I don’t know what happens on your side when 
>>> I push the
>>> change.   
>> 
>> 
>>> I‘ll try to post the diffs later.
>>> 
>>> Another option is: you remove the misnamed duplicates from git if they’re 
>>> present on
>>> your side. 
>>> 
>>> Stephan
>>> 
>> 
>>  Kornel
>> 
> 
> 
> I see now, that the cherry-pick went probably wrong at 2.3.x, because I have 
> now two
> pairs. (With and without the case diff)

Yes, that’s the problem.

> I could remove the wrong one, but what would happen on your side?

And now it’s ok again. Although I had to drop my experimental clone.
But fortunately with a fresh one I can switch to 2,3,x branch again.

Stephan
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/2.3.x] Cmake build: Remove cmake warnings about mismatched values of FindPackageHandleStandardArgs()

2020-02-15 Thread Kornel Benko
Am Sat, 15 Feb 2020 09:17:53 +0100
schrieb Kornel Benko :

> Am Sat, 15 Feb 2020 09:02:45 +0100
> schrieb Stephan Witt :
> 
> > Am 15.02.2020 um 08:32 schrieb Kornel Benko :  
> > > 
> > > Am Fri, 14 Feb 2020 17:37:28 +0100
> > > schrieb Stephan Witt :
> > > 
> > >> Changes not staged for commit:
> > >>  (use "git add ..." to update what will be committed)
> > >>  (use "git checkout -- ..." to discard changes in working 
> > >> directory)
> > >> 
> > >>modified:   development/cmake/modules/FindHUNSPELL.cmake
> > >> 
> > >> no changes added to commit (use "git add" and/or "git commit -a“)
> > >> ==
> > >> 
> > >> No luck. I’d guess on Windows with case insensitive FS it’s the same.
> > >> 
> > > 
> > > Should it be not enough to say here:
> > >git checkout development/cmake/modules/FindHUNSPELL.cmake
> > >git checkout development/cmake/modules/FindENCHANT.cmake
> > > ?
> > 
> > No. I‘ve tried this already.
> > 
> > IMO you can’t have two files with different cases in name only. Didn’t you 
> > add a
> > second one instead of rename it? Actually there’s a problem because it’s 
> > duplicated
> > and changed.  
> 
> No, I did 'git mv'.
> 
> Possibly it is better to
>   git rm; git commit
>   git add; git commit;
> 
> > I can rename it on my end. But I don’t know what happens on your side when 
> > I push the
> > change.   
> 
> 
> > I‘ll try to post the diffs later.
> > 
> > Another option is: you remove the misnamed duplicates from git if they’re 
> > present on
> > your side. 
> > 
> > Stephan
> >   
> 
>   Kornel
> 


I see now, that the cherry-pick went probably wrong at 2.3.x, because I have 
now two
pairs. (With and without the case diff)

I could remove the wrong one, but what would happen on your side?

Kornel


pgpmuLjQi47aG.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/2.3.x] Cmake build: Remove cmake warnings about mismatched values of FindPackageHandleStandardArgs()

2020-02-15 Thread Kornel Benko
Am Sat, 15 Feb 2020 09:02:45 +0100
schrieb Stephan Witt :

> Am 15.02.2020 um 08:32 schrieb Kornel Benko :
> > 
> > Am Fri, 14 Feb 2020 17:37:28 +0100
> > schrieb Stephan Witt :
> >   
> >> Changes not staged for commit:
> >>  (use "git add ..." to update what will be committed)
> >>  (use "git checkout -- ..." to discard changes in working directory)
> >> 
> >>modified:   development/cmake/modules/FindHUNSPELL.cmake
> >> 
> >> no changes added to commit (use "git add" and/or "git commit -a“)
> >> ==
> >> 
> >> No luck. I’d guess on Windows with case insensitive FS it’s the same.
> >>   
> > 
> > Should it be not enough to say here:
> >git checkout development/cmake/modules/FindHUNSPELL.cmake
> >git checkout development/cmake/modules/FindENCHANT.cmake
> > ?  
> 
> No. I‘ve tried this already.
> 
> IMO you can’t have two files with different cases in name only. Didn’t you 
> add a second
> one instead of rename it? Actually there’s a problem because it’s duplicated 
> and
> changed.

No, I did 'git mv'.

Possibly it is better to
git rm; git commit
git add; git commit;

> I can rename it on my end. But I don’t know what happens on your side when I 
> push the
> change. 


> I‘ll try to post the diffs later.
> 
> Another option is: you remove the misnamed duplicates from git if they’re 
> present on
> your side. 
> 
> Stephan
> 

Kornel



pgpp2r3Mv5vuv.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/2.3.x] Cmake build: Remove cmake warnings about mismatched values of FindPackageHandleStandardArgs()

2020-02-15 Thread Stephan Witt
Am 15.02.2020 um 08:32 schrieb Kornel Benko :
> 
> Am Fri, 14 Feb 2020 17:37:28 +0100
> schrieb Stephan Witt :
> 
>> Changes not staged for commit:
>>  (use "git add ..." to update what will be committed)
>>  (use "git checkout -- ..." to discard changes in working directory)
>> 
>>modified:   development/cmake/modules/FindHUNSPELL.cmake
>> 
>> no changes added to commit (use "git add" and/or "git commit -a“)
>> ==
>> 
>> No luck. I’d guess on Windows with case insensitive FS it’s the same.
>> 
> 
> Should it be not enough to say here:
>git checkout development/cmake/modules/FindHUNSPELL.cmake
>git checkout development/cmake/modules/FindENCHANT.cmake
> ?

No. I‘ve tried this already.

IMO you can’t have two files with different cases in name only. Didn’t you add 
a second one instead of rename it? Actually there’s a problem because it’s 
duplicated and changed.

I can rename it on my end. But I don’t know what happens on your side when I 
push the change. 

I‘ll try to post the diffs later.

Another option is: you remove the misnamed duplicates from git if they’re 
present on your side. 

Stephan

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel