Re: 2.1.0 Blocker

2013-10-16 Thread Helge Hafting 

On 12. okt. 2013 20:43, Enrico Forestieri wrote:


I still simply wait for a latex run to finish before doing anything
else, so multithreading is of no help to me.


Latex sometimes takes a long time, due to a big document or
costly features (tikz, or external insets that runs export
functions in other sw)

In such cases I keep working. And it is ok even if I change stuff,
for while the latex run can take minutes, the initial
lyx-.tex export is still fast. And with the export done, changes should 
not matter any more.


Multithreading is also nice when my document is full of images or math 
previews. Such stuff take time to load, especially from a congested 
fileserver accessed via congested wifi - displayed on a remote display.

But I can still edit!

And lets not forget the more trivial cases of working on document B 
while document A is printing.


Helge Hafting

Re: minor re-definition of the chunk inset

2013-10-16 Thread Scott Kostyshak 
On Sat, Oct 12, 2013 at 4:58 AM, Liviu Andronic landronim...@gmail.com wrote:
 Dear all,
 I would suggest that we perform a minor redefinition of the new chunk inset.

 As I recently found out, in some instances LyX can place the inset on
 the same line as some other LaTeX command (see attached):
 \centering{}=
 2+2 #chunk
 @

 My patch would ensure that there is always a break between the inset
 content and the surrounding LaTeX code. To my understanding there are
 no downsides, as LaTeX simply ignores redundant empty lines. But the
 upside is that in some instances compilation of Sweave/knitr documents
 wouldn't break.

 With the attached patch applied, the above construct becomes:
 \centering{}
 =
 2+2 #chunk
 @

 and compilation proceeds without a hitch.

 What do you think? Regards,

Seems reasonable to me. Does anyone object?

Scott

Re: minor re-definition of the chunk inset

2013-10-16 Thread Liviu Andronic 
On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak skost...@lyx.org wrote:
 With the attached patch applied, the above construct becomes:
 \centering{}
 =
 2+2 #chunk
 @

 and compilation proceeds without a hitch.

 What do you think? Regards,

 Seems reasonable to me. Does anyone object?

I had a quick chat with JMarc off-list, and it seems that the
additional breaks could in some cases create a double \n and thus an
unwanted paragraph break. Personally, I'm not sure how to reproduce
such a case, but then I'm no LaTeX expert. Any ideas?

Liviu

git help!

2013-10-16 Thread Tommaso Cucinotta 
Hi,

a question for git-ers:
- just messed up too much with git reset --soft HEAD^
- apparently, I rolled back some work, and I don't have it in my file system 
any more
- however, I can see the interesting patch still is stored some way into 
HEAD@{27}, but when I git-show it, I can see all things marked with double ++ 
and -- (or space +, space -)
- if I try to pick that patch with cherry-pick, it refuses

$ git cherry-pick  2db35095
error: Commit 2db35095d3c1ac47d9181dcc178c3e9238953b1a is a merge but no -m 
option was given.
fatal: cherry-pick failed

is there a way I can still recover that patch from git ? Or, should I resign to 
copy manually the changes that I can see with show view HEAD@{27} ?

Thx,

T.

Re: git help!

2013-10-16 Thread John Tapsell 
Like it says, that commit is a merge..

You can just checkout that commit:  git checkout HEAD@{27}

or reset to that commit:   git reset HEAD@{27}

or view the commits that are in that merge:  gitk HEAD@{27}

Re: minor re-definition of the chunk inset

2013-10-16 Thread Scott Kostyshak 
On Wed, Oct 16, 2013 at 2:43 PM, Liviu Andronic landronim...@gmail.com wrote:
 On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak skost...@lyx.org wrote:
 With the attached patch applied, the above construct becomes:
 \centering{}
 =
 2+2 #chunk
 @

 and compilation proceeds without a hitch.

 What do you think? Regards,

 Seems reasonable to me. Does anyone object?

 I had a quick chat with JMarc off-list, and it seems that the
 additional breaks could in some cases create a double \n and thus an
 unwanted paragraph break. Personally, I'm not sure how to reproduce
 such a case, but then I'm no LaTeX expert. Any ideas?

Ah, that could be. That's too bad because I thought your example was a
good use case.

Scott

Re: 2.1.0 Blocker

2013-10-16 Thread Helge Hafting 

On 12. okt. 2013 20:43, Enrico Forestieri wrote:


I still simply wait for a latex run to finish before doing anything
else, so multithreading is of no help to me.


Latex sometimes takes a long time, due to a big document or
costly features (tikz, or external insets that runs export
functions in other sw)

In such cases I keep working. And it is ok even if I change stuff,
for while the latex run can take minutes, the initial
lyx->.tex export is still fast. And with the export done, changes should 
not matter any more.


Multithreading is also nice when my document is full of images or math 
previews. Such stuff take time to load, especially from a congested 
fileserver accessed via congested wifi - displayed on a remote display.

But I can still edit!

And lets not forget the more trivial cases of working on document B 
while document A is printing.


Helge Hafting

Re: minor re-definition of the chunk inset

2013-10-16 Thread Scott Kostyshak 
On Sat, Oct 12, 2013 at 4:58 AM, Liviu Andronic  wrote:
> Dear all,
> I would suggest that we perform a minor redefinition of the new chunk inset.
>
> As I recently found out, in some instances LyX can place the inset on
> the same line as some other LaTeX command (see attached):
> \centering{}<<>>=
> 2+2 #chunk
> @
>
> My patch would ensure that there is always a break between the inset
> content and the surrounding LaTeX code. To my understanding there are
> no downsides, as LaTeX simply ignores redundant empty lines. But the
> upside is that in some instances compilation of Sweave/knitr documents
> wouldn't break.
>
> With the attached patch applied, the above construct becomes:
> \centering{}
> <<>>=
> 2+2 #chunk
> @
>
> and compilation proceeds without a hitch.
>
> What do you think? Regards,

Seems reasonable to me. Does anyone object?

Scott

Re: minor re-definition of the chunk inset

2013-10-16 Thread Liviu Andronic 
On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak  wrote:
>> With the attached patch applied, the above construct becomes:
>> \centering{}
>> <<>>=
>> 2+2 #chunk
>> @
>>
>> and compilation proceeds without a hitch.
>>
>> What do you think? Regards,
>
> Seems reasonable to me. Does anyone object?
>
I had a quick chat with JMarc off-list, and it seems that the
additional breaks could in some cases create a double \n and thus an
unwanted paragraph break. Personally, I'm not sure how to reproduce
such a case, but then I'm no LaTeX expert. Any ideas?

Liviu

git help!

2013-10-16 Thread Tommaso Cucinotta 
Hi,

a question for git-ers:
- just messed up too much with git reset --soft HEAD^
- apparently, I rolled back some work, and I don't have it in my file system 
any more
- however, I can see the interesting patch still is stored some way into 
HEAD@{27}, but when I git-show it, I can see all things marked with double ++ 
and -- (or space +, space -)
- if I try to pick that patch with cherry-pick, it refuses

$ git cherry-pick  2db35095
error: Commit 2db35095d3c1ac47d9181dcc178c3e9238953b1a is a merge but no -m 
option was given.
fatal: cherry-pick failed

is there a way I can still recover that patch from git ? Or, should I resign to 
"copy" manually the changes that I can see with show view HEAD@{27} ?

Thx,

T.

Re: git help!

2013-10-16 Thread John Tapsell 
Like it says, that commit is a merge..

You can just checkout that commit:  git checkout HEAD@{27}

or reset to that commit:   git reset HEAD@{27}

or view the commits that are in that merge:  gitk HEAD@{27}

Re: minor re-definition of the chunk inset

2013-10-16 Thread Scott Kostyshak 
On Wed, Oct 16, 2013 at 2:43 PM, Liviu Andronic  wrote:
> On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak  wrote:
>>> With the attached patch applied, the above construct becomes:
>>> \centering{}
>>> <<>>=
>>> 2+2 #chunk
>>> @
>>>
>>> and compilation proceeds without a hitch.
>>>
>>> What do you think? Regards,
>>
>> Seems reasonable to me. Does anyone object?
>>
> I had a quick chat with JMarc off-list, and it seems that the
> additional breaks could in some cases create a double \n and thus an
> unwanted paragraph break. Personally, I'm not sure how to reproduce
> such a case, but then I'm no LaTeX expert. Any ideas?

Ah, that could be. That's too bad because I thought your example was a
good use case.

Scott