Re: default dir when save for first time is not cwd

[Scott Kostyshak]

On Sat, Jul 02, 2016 at 11:57:14PM +0200, Guillaume Munch wrote:

> I only have an opinion for the working directory. Also I do not
> understand which path field you are referring to (lost in translation).

It is the first one in the paths tab. In English "Working directory", in
French "Répertoire de travail". Is that what you were asking about?

> > > If all, then instead of a tool tip since
> > > the behavior would be consistent for all the paths we could put a note
> > > at the top/bottom explaining something like "you may use relative paths
> > > or absolute paths. Relative paths will be expanded with respect to the
> > > directory you start LyX from, and thus could change each LyX session".
> 
> I see other paths that do not make much sense as relative directories.

Agreed. Let's take an example, e.g. "Thesaurus dictionaries". It would
be strange to use '.' intending for it to be a relative path. But I also
think it would be strange to use '.' the way that '.' is currently
interpreted (which is that '.' is immediately substituted for the current
working directory and that absolute path is then stored in preferences).
Thus, because both scenarios are strange, I do not think that users who
enter '.' will be confused by the new behavior.

> However this could provide a more uniform interface. I already read for
> the "TEXINPUTS prefix" tooltip: ". designates the current directory".
> What you suggest would be less hidden and more uniform.

Yes this is indeed the advantage.

In the end, I don't have a strong opinion on this. If others would
prefer making the change only for "Working directory", I'm fine with
that.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Fix CAS input on windows (bug 10262)

[Scott Kostyshak]

On Sat, Jul 02, 2016 at 06:59:46PM +0200, Georg Baum wrote:
> commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
> Author: Georg Baum 
> Date:   Sat Jul 2 18:58:30 2016 +0200
> 
> Fix CAS input on windows (bug 10262)
> 
> This is the well known file locking problem: The TempFile class keeps the
> created file locked for the own process, and this prevents the CAS to 
> read it.
> ---
>  src/mathed/MathExtern.cpp |9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
> index b3443fa..8b1e0f0 100644
> --- a/src/mathed/MathExtern.cpp
> +++ b/src/mathed/MathExtern.cpp
> @@ -1001,8 +1001,13 @@ namespace {
>   {
>   // In order to avoid parsing problems with command interpreters
>   // we pass input data through a file
> - TempFile tempfile("casinput");
> - FileName const cas_tmpfile = tempfile.name();
> + // Since the CAS is supposed to read the temp file we need
> + // to unlock it on windows (bug 10262).
> + unique_ptr tempfile(new TempFile("casinput"));
> + tempfile->setAutoRemove(false);
> + FileName const cas_tmpfile = tempfile->name();
> + tempfile.reset();
> +
>   if (cas_tmpfile.empty()) {
>   lyxerr << "Warning: cannot create temporary file."
>  << endl;

Any chance that similar fixes could fix the following two bugs?
http://www.lyx.org/trac/ticket/10043
http://www.lyx.org/trac/ticket/10091

Scott


signature.asc
Description: PGP signature

Re: Trojan warning from Windows defender

[Pavel Sanda]

Richard Heck wrote:
> On 07/01/2016 04:00 PM, Pavel Sanda wrote:
>> Cyrille Artho wrote:
>>> Without https the signatures are not very useful.
>> I fail to follow what do you mean by this.
>
> Without https, a man-in-the-middle attack is possible, and of course
> the signatures could also be faked. But I'm not sure that makes them
> "not very useful". It just makes them not perfect.

Man-in-the middle for pgp signature? You stay in the middle and you send
me whatever packet you want. However you don't have my secret key for
the signature. So what you are going to do to fake it?

Pavel

Re: ancient history, v 0.10.7 beta

[Guillaume Munch]

Le 30/06/2016 12:01, Jean-Marc Lasgouttes a écrit :

Le 30/06/2016 à 11:57, José Abílio Matos a écrit :

On Thursday, June 30, 2016 10:51:09 AM WEST Jean-Marc Lasgouttes wrote:

We have a lot of these old thing on our ftp actually:
http://www.lyx.org/misc/archaeology/lyx-time.html

This web page is not up to date, unfortunately...


I did that initally and then Angus has improved it a lot but we lost
it when
changing machine and Angus did not had a backup. As far as I remember, of
course.


Happy 21st birthday, LyX!


Not yet 21, considering the release date of Lyrix 1.05 in September
1995.

And the LyX 0.7 distribution was 197K :)

JMarc


0.10.7 was the first version I have used. :-)


0.8.3 was the first to which I contributed. It did not compile properly
on my DEC alpha... (and I had finished my thesis)



I have been using LyX since 2004 and version 1.3.4. I feel like a
newcomer, but I now realise that it is closer from the first release
than from now. And it was definitely a good call not to contribute
before I was done with my thesis ;)

Guillaume

Re: default dir when save for first time is not cwd

[Guillaume Munch]

Le 01/07/2016 03:01, Scott Kostyshak a écrit :

On Fri, Jun 17, 2016 at 07:21:32PM -0400, Scott Kostyshak wrote:

On Fri, Jun 17, 2016 at 10:33:03AM +0200, Jean-Marc Lasgouttes wrote:

Le 17/06/2016 à 10:10, Scott Kostyshak a écrit :

I guess the main question is: do you think a user would enter a relative
path in that dialog intending for it to be immediately converted to an
absolute path? The more I think about it, I cannot think of such a case
for any of the fields (although I agree that for some of the fields a
relative path would not makes much sense, like the templates path).


I like the idea. We can have a tooltip explaining how it works.


Do you support allowing relative paths for all the fields in the paths
tab or only working directory?


I only have an opinion for the working directory. Also I do not
understand which path field you are referring to (lost in translation).


If all, then instead of a tool tip since
the behavior would be consistent for all the paths we could put a note
at the top/bottom explaining something like "you may use relative paths
or absolute paths. Relative paths will be expanded with respect to the
directory you start LyX from, and thus could change each LyX session".


I see other paths that do not make much sense as relative directories.
However this could provide a more uniform interface. I already read for
the "TEXINPUTS prefix" tooltip: ". designates the current directory".
What you suggest would be less hidden and more uniform.

Re: Weird KDE Bug in LyX

[Guillaume Munch]

Le 30/06/2016 22:26, Richard Heck a écrit :


For anyone running LyX 2.2.0 under KDE (or using a KDE-based window
manager, or anything of that sort):

There is an annoying new feature, KDE's "accelerator manager", that
automatically adds shortcuts. This causes conflicts and so forth in many
Qt-based programs, when those programs are run with Qt5. If you are
experiencing this issue, please see
 http://www.lyx.org/trac/ticket/10261#comment:16
for a workaround.




On the other hand, it is possible to prioritise LyX shortcuts by using
the shortcut override mechanism. This would solve both bugs
http://www.lyx.org/trac/ticket/10261 and
http://www.lyx.org/trac/ticket/10119 (probably),
and alleviate the occasional developer's or translator's mistake in
assigning accelerators.

Guillaume

Re: 5 more compiler warnings in master

[Guillaume Munch]

Le 02/07/2016 20:28, Uwe Stöhr a écrit :


I understand the compiler warnings but it is not easy for me to decide
if a truncation of values was intended or not. I mean if it is intended
one should use int().(…)


Hi Uwe,

you are right, asking somebody to fix a warning when they are not
familiar with the code defeats the purpose of a warning. Then better
just turn off the warning.

Even better, could we have the same warning with gcc so that we have
both the benefit of encouraging clearer code and have it right on the
first try?



Since you know the background of the truncation, could you please apply
the fixes?



Thank you Richard for applying the fixes.


Guillaume

Re: [LyX/master] Compile fix after change 4b64aaf, replace missing constructor for C-string with docstring variant

[Guillaume Munch]

Another way to answer your question is to look at the old code. It used
to call from_utf8 already, so it appears that you are right.


Le 02/07/2016 10:35, Stephan Witt a écrit :

Hi Benjamin,

I’ve had to change your code to make it compilable again.

The constructor for the FuncRequest with char* for args was removed.
To construct a docstring instead one has to know the encoding of the
arguments. You’ve converted the result of the FuncRequest dispatch
to UTF-8. So I presumed the input is UTF-8 too. Am I right?

Stephan

Am 02.07.2016 um 08:30 schrieb Stephan Witt :


commit 1440b6a2fc6d39782a486f045d72506eb9215712
Author: Stephan Witt 
Date:   Sat Jul 2 08:29:39 2016 +0200

Compile fix after change 4b64aaf, replace missing constructor for C-string 
with docstring variant
---
src/support/AppleScriptProxy.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/support/AppleScriptProxy.cpp b/src/support/AppleScriptProxy.cpp
index b40a145..8ff1d76 100644
--- a/src/support/AppleScriptProxy.cpp
+++ b/src/support/AppleScriptProxy.cpp
@@ -27,7 +27,7 @@ using namespace lyx;

extern "C" LyXFunctionResult applescript_execute_command(const char *cmd, const 
char *arg) {
LYXERR(Debug::ACTION, "Running command [" << cmd << "] with arguments [" << arg 
<< "]");
-   FuncRequest fr(lyxaction.lookupFunc(cmd), arg);
+   FuncRequest fr(lyxaction.lookupFunc(cmd), from_utf8(arg));
fr.setOrigin(FuncRequest::LYXSERVER);
DispatchResult dr;
theApp()->dispatch(fr, dr);

Re: 5 more compiler warnings in master

[Richard Heck]

On 07/02/2016 02:28 PM, Uwe Stöhr wrote:
> Am 02.07.2016 um 20:15 schrieb Richard Heck:
>
>> All harmless.
>>
>> In future, you can fix these sorts of warnings easily.
>
> I understand the compiler warnings but it is not easy for me to decide
> if a truncation of values was intended or not. I mean if it is
> intended one should use int(). Since this is not done, I must assume
> that this was not intended.

This sort of thing is known as an "implicit conversion". It happens all
the time. For example, consider the following:
Type * type_ptr;

if (type_ptr) {
...do something...
}
This involves an implicit conversion from Type* to a bool.

You get the warning in the case of a conversion from double to int
because, as it says, there /could/ be a loss of data. But such
conversions are still quite common.

>
>> int const y_bar = deleted() ? y - fm.maxAscent() / 3
>> : y + 2 * pi.base.solidLineOffset() +
>> pi.base.solidLineThickness();
>>
>> Here, we clearly do want to do that, since the function to which
>> we're about to
>> pass y_bar wants an int, too.
>
> That is not clear to me. How can I know that we want to floor the
> result of a division. Do we really want to get 2 if fm.maxAscent() is
> either 6, 7 or 8? That is quite strange to me. Another question arises
> if we want the truncation: why do we divide by 3 not e.g. 4?

Well, there's a comment just above:

// Calculate 1/3 height of font

Granted, one might have used rounding here. But, so far as I am aware,
no bug has been reported about the drawing of change markers. And adding
int(...) does not change behavior.

> That is why I report the warnings uncommented. It might be that it is
> obvious for others but for me they are not.

As I said, you just have to read the code. If you don't understand it,
or can't figure out what's intended, then that would be the right time
to report the warning.

Richard

Re: 5 more compiler warnings in master

[Uwe Stöhr]

Am 02.07.2016 um 20:15 schrieb Richard Heck:


All harmless.

In future, you can fix these sorts of warnings easily.


I understand the compiler warnings but it is not easy for me to decide 
if a truncation of values was intended or not. I mean if it is intended 
one should use int(). Since this is not done, I must assume that this 
was not intended.



int const y_bar = deleted() ? y - fm.maxAscent() / 3
: y + 2 * pi.base.solidLineOffset() + pi.base.solidLineThickness();

Here, we clearly do want to do that, since the function to which we're about to
pass y_bar wants an int, too.


That is not clear to me. How can I know that we want to floor the result 
of a division. Do we really want to get 2 if fm.maxAscent() is either 6, 
7 or 8? That is quite strange to me. Another question arises if we want 
the truncation: why do we divide by 3 not e.g. 4?


That is why I report the warnings uncommented. It might be that it is 
obvious for others but for me they are not.


Since you know the background of the truncation, could you please apply 
the fixes?


thanks and regards
Uwe

LyX 2.2.1

[Richard Heck]

We have already fixed at least 43 bugs for 2.2.1, and we now also have
the possibility, thanks to Dima, to release a binary that will run on
Windows Vista. So it looks like a good time to start thinking about the
release of LyX 2.2.1.

The question at the moment is whether there is anything pressing we need
to do before that release. You can find a list of open bugs with a 2.2.1
milestone here:

   
http://www.lyx.org/trac/wiki/BugTrackerHome#Unresolvedbugstargetedtonextmaintenancerelease2.2.1

Other suggestions are also acceptable

Richard

Re: Contextual shortcuts

[Richard Heck]

On 07/02/2016 04:44 AM, Franck Vasseur wrote:
>
> Hello,
>
>  
>
> I am just discovering LyX, which seems to be a very nice tool to edit
> all kind of documents.
>
>  
>
> I am most interested by editing mathematic texts, and when using LyX,
> I have wondered if it were possible to create contextual shortcuts (as
> these used in TeXmacs).
>
> For instance, when one writes mathematics, why do they have to begin
> every shortcut with “Alt-M” ?
>
>  
>
> Moreover, some shortcuts which could be very useful in a precise
> situation are already used: with a contextual shortcut, they could be
> used in a different way.
>
> Example : you type a sum (capital sigma) and then, Up and Down arrow
> buttons will allow you to type the beginning and end of the summing.
>
>  
>
> So, the idea is to simplify and improve the speed of typing by using
> shortcuts which depend from:
>
>   * the environment (text, formula...)
>   * the previous symbol you have typed
>
> Another idea (also used in TeXmacs) is to group a few similar
> mathematical symbols: you type one of them and replace it by the next
> of the group by using “Tab”. This is a way to avoid remembering all
> the shortcuts for all the symbols of the group.
>
> Example: the symbol of multiplication is typed with “*” and displayed
> as a small space, but can be replaced by a “×”, or a “.” or even a “*”
> by using “Tab”.
>
>  
>
> Whatever you decide, thank you very much for your amazing work.
>

Please file an enhancement request for this. It's an idea that's been
suggested before, and one that would make certain things much easier.

Note that there are some cases in which keys work differently depending
upon where you are. See the documentation under Help> LyX Functions for
"command-alternatives". But this only works when some of the commands
aren't legal in certain contexts.

Richard

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Uwe Stöhr]

Am 02.07.2016 um 20:09 schrieb Dima Ruinskiy:


And if nobody else has a Vista system around, I will happily pre-test the
official 2.2.1 build on my PC.


Sure, I will inform you when it is available.

regards Uwe

Re: [LyX/master] Fix windows dependencies download

[Uwe Stöhr]

Am 19.06.2016 um 13:03 schrieb Georg Baum:


The paths and servers have changed, and a MSVC 2013 version is not
provided anymore.


Thanks Georg for having a look.

However, this ZIP-file should be put on ftp.lyx.org and be used:

http://ftp.lyx.de/LyX-Windows-Deps/

Richard, could you please do this?

If this is done, please apply the patch also from 2.2.x.

thanks and regards
Uwe

Re: [LyX/master] Fix CAS input on windows (bug 10262)

[Richard Heck]

On 07/02/2016 01:09 PM, Georg Baum wrote:
> Georg Baum wrote:
>
>> commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
>> Author: Georg Baum 
>> Date:   Sat Jul 2 18:58:30 2016 +0200
>>
>> Fix CAS input on windows (bug 10262)
>> 
>> This is the well known file locking problem: The TempFile class keeps
>> the created file locked for the own process, and this prevents the CAS
>> to read it.
>> ---
>>  src/mathed/MathExtern.cpp |9 +++--
>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
>> index b3443fa..8b1e0f0 100644
>> --- a/src/mathed/MathExtern.cpp
>> +++ b/src/mathed/MathExtern.cpp
>> @@ -1001,8 +1001,13 @@ namespace {
>>  {
>>  // In order to avoid parsing problems with command interpreters
>>  // we pass input data through a file
>> -TempFile tempfile("casinput");
>> -FileName const cas_tmpfile = tempfile.name();
>> +// Since the CAS is supposed to read the temp file we 
> need
>> +// to unlock it on windows (bug 10262).
>> +unique_ptr tempfile(new TempFile("casinput"));
>> +tempfile->setAutoRemove(false);
>> +FileName const cas_tmpfile = tempfile->name();
>> +tempfile.reset();
>> +
>>  if (cas_tmpfile.empty()) {
>>  lyxerr << "Warning: cannot create temporary file."
>>  << endl;
> Richard, OK for 2.2 (with auto_ptr instead of unique_ptr)?

Yes, looks good.

Richard

Re: [LyX/master] By default, charstyles should not permit layout changes internally.

[Richard Heck]

On 07/02/2016 11:45 AM, Georg Baum wrote:
> Richard Heck wrote:
>
>> commit 152817576adaefaa1be8f124b9feecd5c2bfd7c2
>> Author: Richard Heck 
>> Date:   Mon Jun 20 11:30:32 2016 -0400
>>
>> By default, charstyles should not permit layout changes internally.
>> 
>> Fixes #10237.
> This makes the tex2lyx tests fail (see attachment). I guess the new version 
> is correct?

Yes, that's right.

Richard

Re: 5 more compiler warnings in master

[Richard Heck]

On 07/02/2016 11:42 AM, Uwe Stöhr wrote:
> Since I am now able to compile master again with the latest MSVC 2015
> compiler, I get these new warnings:
>
> D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing':
> conversion from 'double' to 'const int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument':
> conversion from 'const double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\RowPainter.cpp(208): warning C4244: 'argument':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]

All harmless.

In future, you can fix these sorts of warnings easily.  For the first
one, just go to line 562 of Changes.cpp. What was there was:

int const y_bar = deleted() ? y - fm.maxAscent() / 3
: y + 2 * pi.base.solidLineOffset() + pi.base.solidLineThickness();

The compiler is complaining that y - fm.maxAscent() / 3 is a double (as
is the other expression), and it is being assigned to an int. Here, we
clearly do want to do that, since the function to which we're about to
pass y_bar wants an int, too. So the solution is just:

int const y_bar = int(deleted() ? y - fm.maxAscent() / 3
: y + 2 * pi.base.solidLineOffset() + pi.base.solidLineThickness());

I.e., we tell the compiler that we definitely do want to convert the
value to an int.

Richard

Re: [LyX/2.2.x] * Math.lyx : add few maxima examples to ch. 23.1.

[Uwe Stöhr]

Am 13.06.2016 um 10:16 schrieb Jean-Pierre Chrétien:


Uwe, if the changes are inserted via change tracking so I can found them
easily, I can take care of the transfer to French doc files when I see
commits to the English docs, that will relax a bit your task. But in
that case change tracking acceptation shiould wait for that transfer to
be done.


Yes, change tracking is very important. Nevertheless I need to test the 
changes nevertheless and so modifying all language versions is not the 
big deal.



I can test with Pavel's improvement to Math.lyx if you want.


Yes, please do so. I committed his patch to the 2.2.x branch.

thanks and regards
Uwe

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Dima Ruinskiy]

Uwe Stöhr  web.de> writes:

> Good. It would be nice to have the 2.2.1 release soon.


And if nobody else has a Vista system around, I will happily pre-test the
official 2.2.1 build on my PC.

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Uwe Stöhr]

Am 02.07.2016 um 17:30 schrieb Richard Heck:


I was planning to write about this early next week, anyway, so perhaps
this is the best way to go.


+1

I can confirm that the 2.2.x compiled from current branch (with the 
Vista flag) works fine on Wind 7 and 10 too.



I'll send a "Planning for 2.2.1" email soon.


Good. It would be nice to have the 2.2.1 release soon.

regards Uwe

Re: compilation error in branch and master

[Uwe Stöhr]

Am 02.07.2016 um 18:39 schrieb Georg Baum:


Did you recompile at least once after the compiler upgrade?


i tried but it was not possible due to the error.


Please try again. My old code contained a thinko and did not do what I
wanted it to do.


Thanks, this works now.

I can also compile the 2.2.x branch successfully.

regards Uwe

Re: [LyX/master] Fix CAS input on windows (bug 10262)

[Georg Baum]

Georg Baum wrote:

> commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
> Author: Georg Baum 
> Date:   Sat Jul 2 18:58:30 2016 +0200
> 
> Fix CAS input on windows (bug 10262)
> 
> This is the well known file locking problem: The TempFile class keeps
> the created file locked for the own process, and this prevents the CAS
> to read it.
> ---
>  src/mathed/MathExtern.cpp |9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
> index b3443fa..8b1e0f0 100644
> --- a/src/mathed/MathExtern.cpp
> +++ b/src/mathed/MathExtern.cpp
> @@ -1001,8 +1001,13 @@ namespace {
>  {
>  // In order to avoid parsing problems with command interpreters
>  // we pass input data through a file
> - TempFile tempfile("casinput");
> - FileName const cas_tmpfile = tempfile.name();
> + // Since the CAS is supposed to read the temp file we 
need
> + // to unlock it on windows (bug 10262).
> + unique_ptr tempfile(new TempFile("casinput"));
> + tempfile->setAutoRemove(false);
> + FileName const cas_tmpfile = tempfile->name();
> + tempfile.reset();
> +
>  if (cas_tmpfile.empty()) {
>  lyxerr << "Warning: cannot create temporary file."
>  << endl;

Richard, OK for 2.2 (with auto_ptr instead of unique_ptr)?


Georg

Re: compilation error in branch and master

[Georg Baum]

Uwe Stöhr wrote:

> Am 02.07.2016 um 17:34 schrieb Uwe Stöhr:
> 
>> I still get the same compilation error:
> 
> Very, very weird: I just recompiled it without changing anything. it is
> incredible but now it compile.

Did you recompile at least once after the compiler upgrade? If not this was 
most likely a side effect of mixing old and new compilation results.

> So I can now compile master again. I'll now try 2.2.x. Please modify
> your today's commit so that at least c++11 is used for MSVC. I can also
> not see a reason why c++14 should not be used with MSVC since this works
> fine for me.

Please try again. My old code contained a thinko and did not do what I 
wanted it to do.

Note that I did not disable C++11 or C++14 for MSVC. In fact, MSVC does not 
have a compiler switch to select the standard you want to use, it always 
decides itself which features are enabled, so what my commit was supposed to 
solve was to get rid of the warning message

cl : Command line warning D9002: ignoring unknown option '--std=c++11'


Georg

Re: [LyX/master] By default, charstyles should not permit layout changes internally.

[Georg Baum]

Richard Heck wrote:

> commit 152817576adaefaa1be8f124b9feecd5c2bfd7c2
> Author: Richard Heck 
> Date:   Mon Jun 20 11:30:32 2016 -0400
> 
> By default, charstyles should not permit layout changes internally.
> 
> Fixes #10237.

This makes the tex2lyx tests fail (see attachment). I guess the new version 
is correct?


Georgdiff --git a/src/tex2lyx/test/test-structure.lyx.lyx b/src/tex2lyx/test/test-structure.lyx.lyx
index d8bc008..d08fcd6 100644
--- a/src/tex2lyx/test/test-structure.lyx.lyx
+++ b/src/tex2lyx/test/test-structure.lyx.lyx
@@ -213,7 +213,7 @@ This causes the
 \begin_inset Flex Flex:Strong
 status collapsed
 
-\begin_layout Standard
+\begin_layout Plain Layout
 logikalmkup
 \end_layout
 

Re: compilation error in branch and master

[Uwe Stöhr]

Am 02.07.2016 um 17:34 schrieb Uwe Stöhr:


I still get the same compilation error:


Very, very weird: I just recompiled it without changing anything. it is 
incredible but now it compile.


So I can now compile master again. I'll now try 2.2.x. Please modify 
your today's commit so that at least c++11 is used for MSVC. I can also 
not see a reason why c++14 should not be used with MSVC since this works 
fine for me.


many thanks and regards
Uwe

5 more compiler warnings in master

[Uwe Stöhr]

Since I am now able to compile master again with the latest MSVC 2015 
compiler, I get these new warnings:


D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing': 
conversion from 'double' to 'const int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument': 
conversion from 'const double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


D:\LyXGit\Master\src\RowPainter.cpp(208): warning C4244: 'argument': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


regards Uwe

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Richard Heck]

On 07/02/2016 04:28 AM, Georg Baum wrote:
> Richard Heck wrote:
>> Now we just need an installer built this way.
> My proposal would be to release 2.2.1 soon and do not build an additional 
> 2.2.0 installer. This avoids confusion for users (why so many 2.2.0 
> installers?), contradicting news items (2.2.0 does not support vista, 2.2.0 
> supports vista), and additional testing work. Also, 2.2.1 has already 
> accumulated lots of bug fixes, including a rather important lyx2lyx bug 
> 10243 which could lead to data loss. The 2.2.1 announcement could then state 
> that vista is supported again.

I was planning to write about this early next week, anyway, so perhaps
this is the best way to go.

I'll send a "Planning for 2.2.1" email soon.

Richard

Contextual shortcuts

[Franck Vasseur]

Hello,



I am just discovering LyX, which seems to be a very nice tool to edit all kind 
of documents.



I am most interested by editing mathematic texts, and when using LyX, I have 
wondered if it were possible to create contextual shortcuts (as these used in 
TeXmacs).

For instance, when one writes mathematics, why do they have to begin every 
shortcut with “Alt-M” ? 



Moreover, some shortcuts which could be very useful in a precise situation are 
already used: with a contextual shortcut, they could be used in a different 
way. 

Example : you type a sum (capital sigma) and then, Up and Down arrow buttons 
will allow you to type the beginning and end of the summing.



So, the idea is to simplify and improve the speed of typing by using shortcuts 
which depend from:

  a.. the environment (text, formula...) 
  b.. the previous symbol you have typed
Another idea (also used in TeXmacs) is to group a few similar mathematical 
symbols: you type one of them and replace it by the next of the group by using 
“Tab”. This is a way to avoid remembering all the shortcuts for all the symbols 
of the group.

Example: the symbol of multiplication is typed with “*” and displayed as a 
small space, but can be replaced by a “×”, or a “.” or even a “*” by using 
“Tab”.



Whatever you decide, thank you very much for your amazing work.



Best regards,

Franck Vasseur

-- 
This email was Malware checked by UTM 9. http://www.sophos.com

Re: compilation error in branch and master

[Georg Baum]

Am 02.07.2016 um 03:19 schrieb Uwe Stöhr:
No, I created separate folders for every git branch to be able to use 
different CMake configs for every branch.


Very good.


Please send CMakeError.log


There is no such file.


and CMakeOutput.log


This one is attached.


Here we need to distinguish branch and master: Your file is from branch, 
where the manual configCompiler.h is used. Therefore the checks for 
setenv/putenv are missing, this is expected.


For master please delete CMakeCache.txt, run cmake again, and then send 
CMakeError.log and CMakeOutput.log again (this time CMakeError.log 
should be produced because nothing is cached, and some checks will 
produce an error).



There must be something new in MSVC 2015 update 3:
https://www.visualstudio.com/en-us/news/releasenotes/vs2015-update3-vs


I don't think that any change is relevant here. This looks rather like a 
configuration issue.


but I cannot find anything about putenv. Obviously neither HAVE_SETENV 
nor HAVE_PUTENV is detected as being defined but in configCompiler.h 
there is

#define HAVE_PUTENV 1
So it should be defined.


Did you delete CMakeCache.txt after the compiler update? If not, please 
do that and if the problem still persists on branch then please send 
CMakeError.log and CMakeOutput.log for branch as well.



Georg

Re: #10119: Shortcut Control-M

[Luca Brandolini]

I confirm that also LyX 2.1.5 works correctly. 
I will be happy to try Ly-2.3.0.


 
> Il giorno 02 lug 2016, alle ore 10:49, LyX Ticket Tracker  ha 
> scritto:
> 
> #10119: Shortcut Control-M
> -+-
> Reporter:  luca.brandolini  |   Owner:  lasgouttes
> Type:  defect   |  Status:  new
> Priority:  normal   |   Milestone:  2.2.x
> Component:  keyboard | Version:  2.2.0dev
> Severity:  normal   |  Resolution:
> Keywords:  os=macos |
> -+-
> 
> Comment (by stwitt):
> 
> Replying to [comment:11 gadmm]:
>> [ab41c1d1/lyxgit] says that it fixes, but I got confused in bug numbers.
> If someone notices that it happens to be fixed in master please mark it as
> such.
> 
> Do you mean there is a chance you've fixed it? Then I can provide a
> LyX-2.3.0 level build for Luca to test it...
> 
> -- 
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor

Re: #8353: Lyx spellcheck (dialog) crashes on Mac OSX Lion 10.8.1

[Tomasz Koziara]

Hi,

I just tested on OS X 10.10.1 using LyX 2.2.0 and worked fine. I think we
can close this ticket.

Thank you,
Tomek

On 2 July 2016 at 11:05, LyX Ticket Tracker  wrote:

> #8353: Lyx spellcheck (dialog) crashes on Mac OSX Lion 10.8.1
> ---+-
>  Reporter:  t.koziara  |   Owner:  stwitt
>  Type:  defect |  Status:  new
>  Priority:  high   |   Milestone:  2.2.x
> Component:  spell  | Version:  2.0.4
>  Severity:  critical   |  Resolution:
>  Keywords: |
> ---+-
>
> Comment (by stwitt):
>
>  It would be nice to know if the crash is reproducible with LyX 2.2.0
>  anymore. If not I propose to close this ticket.
>
> --
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor
>

Re: Do we want to keep any temporary files after a compilation error?

[Georg Baum]

Scott Kostyshak wrote:

> If not, it seems we can just have a fresh start when compiling again
> after an error. That is, instead of using the hard-coded list, we just
> remove all temporary files.

+1

The temporary files can be useful for error analysis, so they should not be 
deleted right after compilation, but deleting them just before a new 
compilation after an errornous one starts can only improve things IMHO.


Georg

Re: [LyX/master] Compile fix after change 4b64aaf, replace missing constructor for C-string with docstring variant

[Stephan Witt]

Hi Benjamin,

I’ve had to change your code to make it compilable again.

The constructor for the FuncRequest with char* for args was removed.
To construct a docstring instead one has to know the encoding of the
arguments. You’ve converted the result of the FuncRequest dispatch
to UTF-8. So I presumed the input is UTF-8 too. Am I right?

Stephan

Am 02.07.2016 um 08:30 schrieb Stephan Witt :
> 
> commit 1440b6a2fc6d39782a486f045d72506eb9215712
> Author: Stephan Witt 
> Date:   Sat Jul 2 08:29:39 2016 +0200
> 
>Compile fix after change 4b64aaf, replace missing constructor for C-string 
> with docstring variant
> ---
> src/support/AppleScriptProxy.cpp |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/support/AppleScriptProxy.cpp 
> b/src/support/AppleScriptProxy.cpp
> index b40a145..8ff1d76 100644
> --- a/src/support/AppleScriptProxy.cpp
> +++ b/src/support/AppleScriptProxy.cpp
> @@ -27,7 +27,7 @@ using namespace lyx;
> 
> extern "C" LyXFunctionResult applescript_execute_command(const char *cmd, 
> const char *arg) {
>   LYXERR(Debug::ACTION, "Running command [" << cmd << "] with arguments 
> [" << arg << "]");
> - FuncRequest fr(lyxaction.lookupFunc(cmd), arg);
> + FuncRequest fr(lyxaction.lookupFunc(cmd), from_utf8(arg));
>   fr.setOrigin(FuncRequest::LYXSERVER);
>   DispatchResult dr;
>   theApp()->dispatch(fr, dr);

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Georg Baum]

Richard Heck wrote:

> On 07/01/2016 04:13 PM, Georg Baum wrote:
>>
>> Richard, OK for branch as well?
> 
> Yes, that's fine.

OK, it is in.

> Did anyone add Dima to the credits?

I did forget that originally, but now it is done. Someone just needs to 
update the credits on the web page (I do not have a working setup for that 
anymore).

> Now we just need an installer built this way.

My proposal would be to release 2.2.1 soon and do not build an additional 
2.2.0 installer. This avoids confusion for users (why so many 2.2.0 
installers?), contradicting news items (2.2.0 does not support vista, 2.2.0 
supports vista), and additional testing work. Also, 2.2.1 has already 
accumulated lots of bug fixes, including a rather important lyx2lyx bug 
10243 which could lead to data loss. The 2.2.1 announcement could then state 
that vista is supported again.


Georg

Do we want to keep any temporary files after a compilation error?

[Scott Kostyshak]

Dear all,

Several bugs have occurred because of LyX not deleting certain temporary
files before recompiling. For example:
http://www.lyx.org/trac/ticket/9963
and there have been others.

If you are interested, you can read the comments on that ticket, but I
think the problem is simple enough that I can summarize it below.

The potential problem is pretty obvious in that we have a hard-coded
list of temporary files that we think we should remove before compiling
again after an error (you can see this list in
LaTeX::removeAuxiliaryFiles()). I think that the list is imperfect and
will always be imperfect (don't some packages have their own temporary
files that they keep?). As for why keeping temporary files can lead to
an error, I don't actually know, but I've seen it happen often enough.

From what I understand, the reason why we keep temporary files around at
all is that they can speed up subsequent compilations. It seems to me
that this caching works well in the case where there is no error, so
unless others disagree we do not need to debate about this situation.

On the other hand, keeping temporary files around has been a source of
bugs for the situation where we are compiling after there was an error.
I think the main question that needs an answer is:

Are there any temporary files that we want to keep after a compilation
error?

If not, it seems we can just have a fresh start when compiling again
after an error. That is, instead of using the hard-coded list, we just
remove all temporary files.

Scott


signature.asc
Description: PGP signature