Re: [LyX/2.2.x] Fix monolithic build.

2016-10-14 Thread Richard Heck
On 10/14/2016 12:48 PM, Scott Kostyshak wrote:
> On Mon, Oct 10, 2016 at 04:24:45PM +0200, Richard Heck wrote:
>> commit 3fe8c04274b0cbc16577965207b4d98aec58d0cd
>> Author: Richard Heck 
>> Date:   Mon Oct 10 10:24:08 2016 -0400
>>
>> Fix monolithic build.
> Is this needed for master also?

Probably, but I didn't check.

rh



Re: LyX 2.2.2 Tarballs

2016-10-14 Thread racoon

On 15.10.2016 00:12, racoon wrote:

On 14.10.2016 17:14, racoon wrote:

On 13.10.2016 10:46, Guillaume Munch wrote:

Le 12/10/2016 à 20:02, racoon a écrit :

On 10.10.2016 17:49, Richard Heck wrote:

Here:

ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/

Please prepare binaries.


I am on 2.2.2 now. There is something strange happening when I
*replace*
stuff from the beginning of a paragraph before a space by pasting some
inset, e.g. note, label, citation, etc. It removes the following space.
Maybe someone can test it on 2.2.1 whether this is a new or old bug.

Details:

Steps to reproduce:
1. Start a new paragraph write two (or three or four or ...) words
(separated by a space)
2. Select the first (or first two or first three or ...) word(s) and
insert a label (or a citation or paste a note or ...)

Actual result:
- The space between the words vanishes

Expected result:
- It does not



I can reproduce with 2.1.5. I think this is an old bug.


It actually affects not only insets but any kind of pasting operation,
including text. Quite nasty bug I think. I can try to have a look at it
but it probably concerns areas I haven't looked at before.


Not sure what exactly it is yet. There is some (unnecessary) cleaning
going on when removing a selection. It is probably in the
eraseSelectionHelper in CutAndPaste.cpp. It seems to remove the leading
space in a paragraph when deleting from the beginning of the paragraph
up to a space. I guess the idea was that LyX does not allow for leading
spaces that's why they should be automatically removed.

But I guess they should not be. They will be cleaned up anyway after the
cursor leaves the paragraph. This is also the case at other places. For
example, when selecting the first word and replacing it by entering a
character the bug does not occur. Also, the leading space is not removed
when deleting the first word without selection, i.e. one character after
the other. That's why there must be a bug here as well or, what I find
more likely, the deletion of the leading space is really unnecessary.


Attached is a fix. Ironically the problem was actually a passage that is 
commented as 'necessary' (commented it out for now). It does not seem 
necessary to me. Maybe there is some advantage in erasing the leading 
space but, if at all, it has to be done more careful.


Daniel

From 967d723b5915e52dfbf5a230b8b9c440af1f01a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=B6ller?= 
Date: Sat, 15 Oct 2016 00:35:17 +0200
Subject: [PATCH] Fixes that cutting selection from beginning of paragrph
 removes space after selection.

---
 src/CutAndPaste.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index 4ec9811..888da0c 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -888,9 +888,9 @@ void cutSelection(Cursor & cur, bool doclear, bool realcut)
cur.pit() = endpit;
 
// sometimes necessary
-   if (doclear
+   /*if (doclear
&& 
text->paragraphs()[begpit].stripLeadingSpaces(bp.track_changes))
-   cur.fixIfBroken();
+   cur.fixIfBroken();*/
 
// need a valid cursor. (Lgb)
cur.clearSelection();
-- 
2.9.0.windows.1



Re: LyX 2.2.2 Tarballs

2016-10-14 Thread racoon

On 14.10.2016 17:14, racoon wrote:

On 13.10.2016 10:46, Guillaume Munch wrote:

Le 12/10/2016 à 20:02, racoon a écrit :

On 10.10.2016 17:49, Richard Heck wrote:

Here:

ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/

Please prepare binaries.


I am on 2.2.2 now. There is something strange happening when I *replace*
stuff from the beginning of a paragraph before a space by pasting some
inset, e.g. note, label, citation, etc. It removes the following space.
Maybe someone can test it on 2.2.1 whether this is a new or old bug.

Details:

Steps to reproduce:
1. Start a new paragraph write two (or three or four or ...) words
(separated by a space)
2. Select the first (or first two or first three or ...) word(s) and
insert a label (or a citation or paste a note or ...)

Actual result:
- The space between the words vanishes

Expected result:
- It does not



I can reproduce with 2.1.5. I think this is an old bug.


It actually affects not only insets but any kind of pasting operation,
including text. Quite nasty bug I think. I can try to have a look at it
but it probably concerns areas I haven't looked at before.


Not sure what exactly it is yet. There is some (unnecessary) cleaning 
going on when removing a selection. It is probably in the 
eraseSelectionHelper in CutAndPaste.cpp. It seems to remove the leading 
space in a paragraph when deleting from the beginning of the paragraph 
up to a space. I guess the idea was that LyX does not allow for leading 
spaces that's why they should be automatically removed.


But I guess they should not be. They will be cleaned up anyway after the 
cursor leaves the paragraph. This is also the case at other places. For 
example, when selecting the first word and replacing it by entering a 
character the bug does not occur. Also, the leading space is not removed 
when deleting the first word without selection, i.e. one character after 
the other. That's why there must be a bug here as well or, what I find 
more likely, the deletion of the leading space is really unnecessary.


Daniel



Re: LyX docs: cleaning up math options

2016-10-14 Thread Guenter Milde
On 2016-10-14, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> On Fri, Oct 14, 2016 at 03:36:11PM +, Guenter Milde wrote:

>> For the end-user the difference is:

>> * with "no", there is a safeguard against relying on additional packages
>>   without real need -> less dependencies when compiling the docs.

> Wouldn't this be a LyX bug if we rely on an unneededed depencency? To be
> clear, I believe Jean-Pierre and I were on the same page of porposing
> that the options be changed to "Load automatically". We are not
> proposing "Load always".

Not a LyX bug. With "safeguard", I only mean the feadback by the compilation
error if the editor/maintainer uses a feature requiring an additional package.
If we decide now to allow this, we should set the options to "auto".
I agree that this is a (small) benefit for the documentation people with a
negligible impact on the average user.
I.e. I am in favour of setting the math-package settings to "auto".

Günter



Re: LyX docs: cleaning up math options

2016-10-14 Thread Uwe Stöhr

Am 14.10.2016 um 17:36 schrieb Guenter Milde:


For the documentation people, the difference is:...


Hi Scott and Günter,

convinced, so fine with me to change everything to automatic. Please 
commit directly if the tests were passed to branch (when it is open 
again) and master (please keep there the fileformat).


Please also take care of the non-English files.

many thanks for your help and best regards
Uwe


Re: LyX 2.2.2 Tarballs

2016-10-14 Thread Uwe Stöhr

Am 14.10.2016 um 08:30 schrieb racoon:


Could you please give it a try and report if this fixes
http://www.lyx.org/trac/ticket/10017


Awesome. Yes, now I can actually open menus with the primary mouse
button and open more than one sub menu.


Many thanks for testing. So this new installer version will become the 
one for LyX 2.2.2.


regards Uwe


Re: LyX 2.2.2 Tarballs

2016-10-14 Thread Uwe Stöhr

Am 13.10.2016 um 19:04 schrieb Richard Heck:


On 10/12/2016 07:33 PM, Uwe Stöhr wrote:



are my final ones ready to be put on ftp.lyx.org.


Thanks, I've got them and will plan to do the release tomorrow,
probably, or Saturday.


Hi Richard,

Daniel gave me the feedback that my installer version 2 fixes the Qt 
bugs we was encountering. Could you therefore please grab installer 
version 2 from

http://ftp.lyx.de/LyX%202.2.2/
and put them on ftp.lyx.org?

many thanks and regards
Uwe


Re: [patch] Fix color when branch name has a space

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 07:16:36PM +0200, Jean-Marc Lasgouttes wrote:
> Le 14/10/2016 à 17:51, Scott Kostyshak a écrit :
> > Any thoughts?
> 
> I would propose instead to use the helpers getArg and getLongArg in
> FuncRequest. Two possibilities:
> 
> lyx_name = cmd.getArg(0);
> x11_name = cmd.getLongArg(1);
> 
> This will do what you want, at the price of a badly defined syntax: it would
> make more sense to keep the space as a parameter separator.
> 
> The second solution would be to use
> 
> lyx_name = cmd.getArg(0);
> x11_name = cmd.getArg(1);
> 
> In this case, the syntax for set-color would be
> set-color foo bar
> set-color "foo bar" baz
> set-color foo "bar baz"
> ...
> 
> I really prefer this second solution. And any of these is better than
> relying on split and rtrim.

Makes sense. I'll work on a better patch.

> Final remark: it seems to me that this LFUN should be named "color-set"
> (set-graphics-group has the same problem).

I agree.

Scott


signature.asc
Description: PGP signature


Re: [patch] Fix color when branch name has a space

2016-10-14 Thread Jean-Marc Lasgouttes

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

Any thoughts?


I would propose instead to use the helpers getArg and getLongArg in 
FuncRequest. Two possibilities:


lyx_name = cmd.getArg(0);
x11_name = cmd.getLongArg(1);

This will do what you want, at the price of a badly defined syntax: it 
would make more sense to keep the space as a parameter separator.


The second solution would be to use

lyx_name = cmd.getArg(0);
x11_name = cmd.getArg(1);

In this case, the syntax for set-color would be
set-color foo bar
set-color "foo bar" baz
set-color foo "bar baz"
...

I really prefer this second solution. And any of these is better than 
relying on split and rtrim.


Final remark: it seems to me that this LFUN should be named "color-set" 
(set-graphics-group has the same problem).


JMarc



Re: [LyX/2.2.x] Fix monolithic build.

2016-10-14 Thread Scott Kostyshak
On Mon, Oct 10, 2016 at 04:24:45PM +0200, Richard Heck wrote:
> commit 3fe8c04274b0cbc16577965207b4d98aec58d0cd
> Author: Richard Heck 
> Date:   Mon Oct 10 10:24:08 2016 -0400
> 
> Fix monolithic build.

Is this needed for master also?

Scott


signature.asc
Description: PGP signature


[patch] Fix color when branch name has a space

2016-10-14 Thread Scott Kostyshak
Any thoughts?

Scott
From dfd265bbcb4c00d06ddd064fa64da5000ebc5cb2 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Fri, 14 Oct 2016 10:41:11 -0400
Subject: [PATCH] Fix color when branch name has a space

The argument to set-color is " ", where in the
case of branches  is the name of the branch. Since branch
names are allowed to contain spaces, instead of splitting on the
first space in the argument we now split on the last space.
---
 src/LyXAction.cpp| 1 +
 src/frontends/qt4/GuiApplication.cpp | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 836f97b..fdf736a 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3566,6 +3566,7 @@ void LyXAction::init()
  * \li Action: Set the given LyX color to the color defined by the X11 name 
given.
  * \li Notion: A new color entry is created if the color is unknown.
Color names can be stored as a part of user settings.
+   Color names may contain spaces.
  * \li Syntax: set-color  
  * \li Origin: SLior, 11 Jun 2000
  * \endvar
diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 81d5373..6b30ed7 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1736,7 +1736,8 @@ void GuiApplication::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
 
case LFUN_SET_COLOR: {
string lyx_name;
-   string const x11_name = split(to_utf8(cmd.argument()), 
lyx_name, ' ');
+   // *r*split because lyx_name (e.g. branch name) might have 
spaces
+   string const x11_name = rsplit(to_utf8(cmd.argument()), 
lyx_name, ' ');
if (lyx_name.empty() || x11_name.empty()) {
if (current_view_)
current_view_->message(
-- 
2.7.4



signature.asc
Description: PGP signature


Re: LyX docs: cleaning up math options

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 03:36:11PM +, Guenter Milde wrote:

> For the end-user the difference is:
> 
> * with "no", there is a safeguard against relying on additional packages
>   without real need -> less dependencies when compiling the docs.

Wouldn't this be a LyX bug if we rely on an unneededed depencency? To be
clear, I believe Jean-Pierre and I were on the same page of porposing
that the options be changed to "Load automatically". We are not
proposing "Load always".

Scott


signature.asc
Description: PGP signature


Re: Git command for fetching the current master

2016-10-14 Thread Richard Heck
On 10/14/2016 10:01 AM, racoon wrote:
> On 14.10.2016 15:50, Scott Kostyshak wrote:
>> On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote:
>>> Thanks. Unfortunately, the final step "git pull" gives me this:
>>>
>>> There is no tracking information for the current branch.
>>> Please specify which branch you want to merge with.
>>> 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/ master
>>
>> Try the following command:
>>
>>  git branch --set-upstream-to=origin/master master
>>
>> The command says that your local master branch should be linked to the
>> remote's master branch. That way when you do a git pull it will update.
>
> Thanks. That worked.

I recommend pulling with
git pull --rebase
This will avoid stupid merge commits by rebasing your current work on
top of whatever is getting pulled in from upstream.

Richard



Re: LyX docs: cleaning up math options

2016-10-14 Thread Guenter Milde
On 2016-10-13, Uwe Stöhr wrote:
> Am 07.10.2016 um 19:01 schrieb Scott Kostyshak:

Dear Uwe,

>> My proposal is to change everything in all .lyx files to "Automatic".
>> Then run the ctests to see which exports start failing and revert the
>> changes to those corresponding documents.

> OK, if all test are passed, we don't risk anything. the question is 
> however, if this is really necessary. Setting a package to no or to 
> automatic does not change anything since if it works when setting to no, 
> it will also not be used wit automatic. So what is the benefit for the 
> user, what for LyX and what for us documentation people?

For the documentation people, the difference is:

* with "no", inserting any character from a package that is (currently)
  blocked will lead to a compilation error.
  
  It is up to the editor or maintainer to decide whether to go without this
  character or change the package-loading setting.

* with "automatic", you can use characters requiring any of the supported
  packages without further discussion or decision.


For the end-user the difference is:

* with "no", there is a safeguard against relying on additional packages
  without real need -> less dependencies when compiling the docs.
  

It is up to you to decide which is the more important.

Günter



Re: LyX 2.2.2 Tarballs

2016-10-14 Thread racoon

On 13.10.2016 10:46, Guillaume Munch wrote:

Le 12/10/2016 à 20:02, racoon a écrit :

On 10.10.2016 17:49, Richard Heck wrote:

Here:

ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/

Please prepare binaries.


I am on 2.2.2 now. There is something strange happening when I *replace*
stuff from the beginning of a paragraph before a space by pasting some
inset, e.g. note, label, citation, etc. It removes the following space.
Maybe someone can test it on 2.2.1 whether this is a new or old bug.

Details:

Steps to reproduce:
1. Start a new paragraph write two (or three or four or ...) words
(separated by a space)
2. Select the first (or first two or first three or ...) word(s) and
insert a label (or a citation or paste a note or ...)

Actual result:
- The space between the words vanishes

Expected result:
- It does not



I can reproduce with 2.1.5. I think this is an old bug.


It actually affects not only insets but any kind of pasting operation, 
including text. Quite nasty bug I think. I can try to have a look at it 
but it probably concerns areas I haven't looked at before.


Daniel




Re: modules multiple columns not support arabic

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 03:20:07AM +0200, Uwe Stöhr wrote:
> Am 14.10.2016 um 00:43 schrieb Scott Kostyshak:
> 
> > Does the attached .lyx file work for you?
> 
> This fixes one of the 3 bugs we are facing here. But how did you manage to
> get rid of \beginL?

I deleted the number "4", then created an ERT and put "4" in the ERT,
then I dissolved the ERT inset.

> The point is that as user you just insert the number of columns but LyX does
> not take the number as verbatim.
> 
> I guess I only forgot to protect the inset as plain/verbatim in the modules
> file. I will hae a look.

OK. I didn't know it would be that simple. That's good news.

Scott


signature.asc
Description: PGP signature


Re: LyX docs: cleaning up math options

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 01:21:17AM +0200, Uwe Stöhr wrote:
> Am 07.10.2016 um 19:01 schrieb Scott Kostyshak:
> 
> OK, if all test are passed, we don't risk anything. the question is however,
> if this is really necessary. Setting a package to no or to automatic does
> not change anything since if it works when setting to no, it will also not
> be used wit automatic.

It is not a necessary change and I don't think the benefits would be
enormous. I do think that the small benefits would outweigh the very
small risks.

> So what is the benefit for the user

Users often use our examples and templates as the base of a new file. If
they do this and then try to use a feature of a package that we have
disabled, they will have problems and might not understand why.

> what for LyX and what for us documentation people?

For example, see the thread reported by Jean-Pierre here that was solved
by fixing the math options:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196026.html

Scott


signature.asc
Description: PGP signature


Re: [PATCH] Re: Return + Return in nested environments

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 03:22:09PM +0200, Jean-Marc Lasgouttes wrote:
> Le 07/10/2016 à 03:48, Scott Kostyshak a écrit :
> > > I don't know much about layout nesting, but my first reaction is that I
> > > agree with you regarding the expected behavior.
> > 
> > Did we figure out what the correct behavior for this is?
> 
> Please try that and tell me whether it works for you.

Tested and I think there is a minor issue. In the attached .lyx file,
put the cursor at the end of "hello". Press return three times. The
first two times show that the issue initially reported is fixed (because
it is itemize instead of ennumerate), but the third return is unexpected
for me. I expected it to go out of itemize, but instead it created an
item with a separator.

Can you reproduce the above with your patch?

Scott
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Itemize
one
\end_layout

\begin_deeper
\begin_layout Enumerate
hello
\end_layout

\end_deeper
\end_body
\end_document


signature.asc
Description: PGP signature


Re: LyXVC::registrer ???

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 04:37:21PM +0200, Jean-Marc Lasgouttes wrote:
> Le 14/10/2016 à 15:57, Scott Kostyshak a écrit :
> > On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote:
> > > Am I right that it should be "register" instead?
> > 
> > Yes.
> 
> Amusingly, `register' is a reserved word in C++ (even though it is
> deprecated).
> 
> Any idea of what I could use  instead? Or I can just keep registrer (which
> is not worse than `collapsable', after all).

Here are a few ideas:

- track
- index ('man git add' makes me think we could use the word "index" as a verb
   meaning to add the file to the VC index)
- record
- enter (into the VC index)
- catalog

Scott


signature.asc
Description: PGP signature


Re: LyXVC::registrer ???

2016-10-14 Thread Jean-Marc Lasgouttes

Le 14/10/2016 à 15:57, Scott Kostyshak a écrit :

On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote:

Am I right that it should be "register" instead?


Yes.


Amusingly, `register' is a reserved word in C++ (even though it is 
deprecated).


Any idea of what I could use  instead? Or I can just keep registrer 
(which is not worse than `collapsable', after all).


JMarc



Re: LyXVC::registrer ???

2016-10-14 Thread Jean-Marc Lasgouttes

Le 14/10/2016 à 15:57, Scott Kostyshak a écrit :

On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote:

Am I right that it should be "register" instead?


Yes.

Note here and in the future though that I only have knowledge of English
(USA).


Google tends to think that this is Norwegian (ar least booking.com tends 
to think so).


JMarc



Re: Git command for fetching the current master

2016-10-14 Thread racoon

On 14.10.2016 15:50, Scott Kostyshak wrote:

On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote:

Thanks. Unfortunately, the final step "git pull" gives me this:

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
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/ master


Try the following command:

 git branch --set-upstream-to=origin/master master

The command says that your local master branch should be linked to the
remote's master branch. That way when you do a git pull it will update.


Thanks. That worked.

Daniel



Re: LyXVC::registrer ???

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote:
> Am I right that it should be "register" instead?

Yes.

Note here and in the future though that I only have knowledge of English
(USA).

Scott


signature.asc
Description: PGP signature


Re: Git command for fetching the current master

2016-10-14 Thread Scott Kostyshak
On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote:
> Thanks. Unfortunately, the final step "git pull" gives me this:
> 
> There is no tracking information for the current branch.
> Please specify which branch you want to merge with.
> 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/ master

Try the following command:

 git branch --set-upstream-to=origin/master master

The command says that your local master branch should be linked to the
remote's master branch. That way when you do a git pull it will update.

Scott


signature.asc
Description: PGP signature


[PATCH] Re: Return + Return in nested environments

2016-10-14 Thread Jean-Marc Lasgouttes

Le 07/10/2016 à 03:48, Scott Kostyshak a écrit :

I don't know much about layout nesting, but my first reaction is that I
agree with you regarding the expected behavior.


Did we figure out what the correct behavior for this is?


Please try that and tell me whether it works for you.

JMarc



>From 43658068801ad9772728973103414e81373e5a75 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 13 Oct 2016 20:33:57 +0200
Subject: [PATCH] When breaking an empty paragraph reduces depth, set layout
 too

---
 src/Text.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/Text.cpp b/src/Text.cpp
index 007271d..16bf899 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -738,9 +738,13 @@ void Text::breakParagraph(Cursor & cur, bool inverse_logic)
 	Layout const & layout = cpar.layout();
 
 	if (cur.lastpos() == 0 && !cpar.allowEmpty()) {
-		if (changeDepthAllowed(cur, DEC_DEPTH))
+		if (changeDepthAllowed(cur, DEC_DEPTH)) {
 			changeDepth(cur, DEC_DEPTH);
-		else {
+			pit_type const prev = depthHook(cpit, cpar.getDepth());
+			docstring const & lay = pars_[prev].layout().name();
+			if (lay != layout.name())
+setLayout(cur, lay);
+		} else {
 			docstring const & lay = cur.paragraph().usePlainLayout()
 			? tclass.plainLayoutName() : tclass.defaultLayoutName();
 			if (lay != layout.name())
-- 
2.7.4



LyXVC::registrer ???

2016-10-14 Thread Jean-Marc Lasgouttes

Am I right that it should be "register" instead?

JMarc


Re: Git command for fetching the current master

2016-10-14 Thread racoon

Thanks. Unfortunately, the final step "git pull" gives me this:

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
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/ master

Daniel

On 14.10.2016 14:05, Joel Kulesza wrote:

I'm not part of the development team; however, my thoughts:

Command-line wise from the LyX directory, check your settings to make
sure they are to the right place with with

git remote -v

Once satisfied (and with any of your changes stashed or committed), try

git checkout master
git fetch
git merge

-or-

git checkout master
git pull

- Joel

On Fri, Oct 14, 2016 at 3:47 AM, racoon > wrote:

Hi,

How do I update my local copy to the current master?

In git gui I tried

Fetch from > origin

But this seems not to work. I can now type any git command line
commands using

Repository > Git Bash

So I am even happy about command line commands on how to update to
the current master.

Daniel




Re: Git command for fetching the current master

2016-10-14 Thread Joel Kulesza
I'm not part of the development team; however, my thoughts:

Command-line wise from the LyX directory, check your settings to make sure
they are to the right place with with

git remote -v

Once satisfied (and with any of your changes stashed or committed), try

git checkout master
git fetch
git merge

-or-

git checkout master
git pull

- Joel

On Fri, Oct 14, 2016 at 3:47 AM, racoon  wrote:

> Hi,
>
> How do I update my local copy to the current master?
>
> In git gui I tried
>
> Fetch from > origin
>
> But this seems not to work. I can now type any git command line commands
> using
>
> Repository > Git Bash
>
> So I am even happy about command line commands on how to update to the
> current master.
>
> Daniel
>
>


Git command for fetching the current master

2016-10-14 Thread racoon

Hi,

How do I update my local copy to the current master?

In git gui I tried

Fetch from > origin

But this seems not to work. I can now type any git command line commands 
using


Repository > Git Bash

So I am even happy about command line commands on how to update to the 
current master.


Daniel



Re: Creating new files

2016-10-14 Thread racoon

On 13.10.2016 22:28, Kornel Benko wrote:

Am Donnerstag, 13. Oktober 2016 um 15:22:30, schrieb Richard Heck 


On 10/13/2016 03:17 PM, racoon wrote:

On 13.10.2016 21:13, Richard Heck wrote:

On 10/13/2016 02:31 PM, racoon wrote:

Hi,

I think I could solve

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

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

The idea is to create a new statistics dialog. I think I can just take
over the code from the About dialog, i.e. create .cpp, .h, and .ui
files accordingly.

However, I have never created new files in the LyX project - only
changed existing files. Can someone tell me how to go about?

I tried to just copy existing files and then renamed them. But Visual
Studio does not find those files in the Project Explorer.

Or creating new files actually quite tricky and as a beginner I'd
rather keep my hands off of this?


You'll have to update src/frontends/qt4/Makefile.am to add the new
files. I assume cmake then knows about them, too, but someone else will
know better.


Thanks. So after updating these files I will have to run cmake then
again, right?


Not after 'updating'. But after creating, yes.
We (in cmake build) still use globbing in configure stage to create makefiles 
(or project files).


For me as a beginner it sounds pretty much like: better keep your hands 
off. (I have not even understood what globbing is.)


All right there are other things to do I guess.

Daniel




reducing file size of images shipped within LyX

2016-10-14 Thread mn
These are really low hanging fruit:
Image files are suboptimally compressed.
Using both
(just examples, there may be better ways or programs)

imgopt
https://github.com/kormoc/imgopt

for raster images and

SVG-Cleaner
https://sourceforge.net/projects/svgcleaner/

for the vector images

I get the following results:

Raster: processed 269 files saving 277087 bytes ( 24% )
in about a minute

Vector: processed 1435 files saving 2.2 MB ( 56% )
in about 20 seconds

Results from a fresh download of 2.2.2 mac.

If someone could just once recompress those files in the devel-tree the
benefits should propagate from there.

greetings
Mike


Re: LyX 2.2.2 Tarballs

2016-10-14 Thread racoon

On 14.10.2016 00:43, Uwe Stöhr wrote:

Am 11.10.2016 um 00:50 schrieb racoon:


Which Qt version will be used for LyX 2.2.2? Qt 5.6.2 is around the
corner (possibly next week). Any chance on a binary with that version? I
am so annoyed by the menus (http://www.lyx.org/trac/ticket/10017). And
the fix for it is in 5.6.2.


I just uploaded a new installer version for 2.2. that uses
- Qt 5.6.2
- Perl 5.22.2
- latest updates of MSVC 2015

http://ftp.lyx.de/LyX%202.2.2/LyX-222-Installer-2.exe

Could you please give it a try and report if this fixes
http://www.lyx.org/trac/ticket/10017


Awesome. Yes, now I can actually open menus with the primary mouse 
button and open more than one sub menu.


Thanks a lot Uwe!

Daniel