change font base size mid document

[Gregory Jefferis]

I have an 11 pt article. I want to switch to a base size of 10pt for the 
Appendix. Is there a way to do this that will not cause trouble with e.g. text 
in superscripts or figure legends with different size fonts? I found these 
suggestions 


http://tex.stackexchange.com/questions/4139/how-to-change-font-size-mid-document

but

\input{size#1.clo}%

completely reset margins etc

while 

 \fontsize{10}{12}\selectfont

had no effect.



Many thanks,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology
MRC Laboratory of Molecular Biology 
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

change font base size mid document

[Gregory Jefferis]

I have an 11 pt article. I want to switch to a base size of 10pt for the 
Appendix. Is there a way to do this that will not cause trouble with e.g. text 
in superscripts or figure legends with different size fonts? I found these 
suggestions 


http://tex.stackexchange.com/questions/4139/how-to-change-font-size-mid-document

but

\input{size#1.clo}%

completely reset margins etc

while 

 \fontsize{10}{12}\selectfont

had no effect.



Many thanks,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology
MRC Laboratory of Molecular Biology 
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

change font base size mid document

[Gregory Jefferis]

I have an 11 pt article. I want to switch to a base size of 10pt for the 
Appendix. Is there a way to do this that will not cause trouble with e.g. text 
in superscripts or figure legends with different size fonts? I found these 
suggestions 


http://tex.stackexchange.com/questions/4139/how-to-change-font-size-mid-document

but

\input{size#1.clo}%

completely reset margins etc

while 

 \fontsize{10}{12}\selectfont

had no effect.



Many thanks,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology
MRC Laboratory of Molecular Biology 
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: Spellchecking not working on Mac OS X

[Gregory Jefferis]

On 19 Apr 2013, at 08:25, Grant Jacobs wrote:

 A work-around seems to be to select the document language to be what you
 want (e.g. English (UK)) and select that to become LyX's default
 document language.

This isn't particularly intuitive (one might expect it to be accessible from 
the main Preferences window, Language tab, perhaps it isn't because it is 
somehow tied to different document classes) but it does work just fine for me 
with 2.0.5-1 with English (UK). Is there an outstanding issue that this doesn't 
solve?

Best wishes,

Greg.

Re: Spellchecking not working on Mac OS X

[Gregory Jefferis]

On 19 Apr 2013, at 08:25, Grant Jacobs wrote:

 A work-around seems to be to select the document language to be what you
 want (e.g. English (UK)) and select that to become LyX's default
 document language.

This isn't particularly intuitive (one might expect it to be accessible from 
the main Preferences window, Language tab, perhaps it isn't because it is 
somehow tied to different document classes) but it does work just fine for me 
with 2.0.5-1 with English (UK). Is there an outstanding issue that this doesn't 
solve?

Best wishes,

Greg.

Re: Spellchecking not working on Mac OS X

[Gregory Jefferis]

On 19 Apr 2013, at 08:25, Grant Jacobs wrote:

> A work-around seems to be to select the document language to be what you
> want (e.g. English (UK)) and select that to become LyX's default
> document language.

This isn't particularly intuitive (one might expect it to be accessible from 
the main Preferences window, Language tab, perhaps it isn't because it is 
somehow tied to different document classes) but it does work just fine for me 
with 2.0.5-1 with English (UK). Is there an outstanding issue that this doesn't 
solve?

Best wishes,

Greg.

Re: OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

On 14 Feb 2013, at 09:58, Mukhtar Ullah wrote:

 Scribus is what you need.
 http://scribus.net/canvas/Scribus

Thanks a lot for the suggestion, I'll look into that more carefully. But do you 
know if it can 

1) include linked pdfs (ie so that content will update when the external file 
updates)
2) do so retaining vector elements in the linked PDF (rather than immediately 
rasterising).

Many thanks,

Greg.

Re: OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

On 14 Feb 2013, at 09:58, Mukhtar Ullah wrote:

 Scribus is what you need.
 http://scribus.net/canvas/Scribus

Thanks a lot for the suggestion, I'll look into that more carefully. But do you 
know if it can 

1) include linked pdfs (ie so that content will update when the external file 
updates)
2) do so retaining vector elements in the linked PDF (rather than immediately 
rasterising).

Many thanks,

Greg.

Re: OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

On 14 Feb 2013, at 09:58, Mukhtar Ullah wrote:

> Scribus is what you need.
> http://scribus.net/canvas/Scribus

Thanks a lot for the suggestion, I'll look into that more carefully. But do you 
know if it can 

1) include linked pdfs (ie so that content will update when the external file 
updates)
2) do so retaining vector elements in the linked PDF (rather than immediately 
rasterising).

Many thanks,

Greg.

OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

Hello,

We currently used Adobe Illustrator to construct quite complex figures for 
Biological Science manuscripts. We save in PDF compatible format and then 
directly place these in my lyx document. Apart from being expensive, the main 
problem is that Illustrator always saves the absolute path to any linked file 
causing trouble when colleagues edit these files on different machines.

Our figures mostly consist of linked PDFs, some type e.g. for labels and a 
small amount of drawing for annotation. I would like to switch to a FOSS 
alternative that allows PDFs to be linked (not embedded). The detailed layout 
of the elements is important. The closest I have found so far is Inkscape, but 
this always embeds PDF on import. Likewise it does not yet seem to be able to 
support linked SVG files.

Would anyone have any suggestions? Many thanks,

Greg.

http://inkscape.org/

--
Gregory Jefferis Lab:  jefferis...@gmail.com
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

Hello,

We currently used Adobe Illustrator to construct quite complex figures for 
Biological Science manuscripts. We save in PDF compatible format and then 
directly place these in my lyx document. Apart from being expensive, the main 
problem is that Illustrator always saves the absolute path to any linked file 
causing trouble when colleagues edit these files on different machines.

Our figures mostly consist of linked PDFs, some type e.g. for labels and a 
small amount of drawing for annotation. I would like to switch to a FOSS 
alternative that allows PDFs to be linked (not embedded). The detailed layout 
of the elements is important. The closest I have found so far is Inkscape, but 
this always embeds PDF on import. Likewise it does not yet seem to be able to 
support linked SVG files.

Would anyone have any suggestions? Many thanks,

Greg.

http://inkscape.org/

--
Gregory Jefferis Lab:  jefferis...@gmail.com
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

OTish: Illustrator alternative to collect linked PDFs into single figure

[Gregory Jefferis]

Hello,

We currently used Adobe Illustrator to construct quite complex figures for 
Biological Science manuscripts. We save in PDF compatible format and then 
directly place these in my lyx document. Apart from being expensive, the main 
problem is that Illustrator always saves the absolute path to any linked file 
causing trouble when colleagues edit these files on different machines.

Our figures mostly consist of linked PDFs, some type e.g. for labels and a 
small amount of drawing for annotation. I would like to switch to a FOSS 
alternative that allows PDFs to be linked (not embedded). The detailed layout 
of the elements is important. The closest I have found so far is Inkscape, but 
this always embeds PDF on import. Likewise it does not yet seem to be able to 
support linked SVG files.

Would anyone have any suggestions? Many thanks,

Greg.

http://inkscape.org/

--
Gregory Jefferis Lab:  jefferis...@gmail.com
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: moderncv

[Gregory Jefferis]

On 14 Jan 2013, at 18:35, Hansen, Glenn J. wrote:

 Thank you in advance for the help. I am new to lyx/tex.
 
 I have been trying to get my cv moved to lyx/tex format and have ran into a 
 problem that I am not able to solve. I have nearly everything done but 
 getting a multiple sectioned bibliography to work(e.g., section for journal 
 articles and conference papers). I get the following error:
 
 ! Package bibtopic Error: Found unknown `thebibliography' environment. 

The error message includes the additional information:

You should either use a package providing a known bibliography
environment (such as natbib), or use the `defaultbib' package
option as a workaround; please see the section about `Warnings
and error messages' in `bibtopic.dvi' for details.

If you go to: Document ... Settings ... Document Class ... 

and then edit the Custom field to add

defaultbib

then as far as I can see things should work. 

Best,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: moderncv

[Gregory Jefferis]

On 14 Jan 2013, at 18:35, Hansen, Glenn J. wrote:

 Thank you in advance for the help. I am new to lyx/tex.
 
 I have been trying to get my cv moved to lyx/tex format and have ran into a 
 problem that I am not able to solve. I have nearly everything done but 
 getting a multiple sectioned bibliography to work(e.g., section for journal 
 articles and conference papers). I get the following error:
 
 ! Package bibtopic Error: Found unknown `thebibliography' environment. 

The error message includes the additional information:

You should either use a package providing a known bibliography
environment (such as natbib), or use the `defaultbib' package
option as a workaround; please see the section about `Warnings
and error messages' in `bibtopic.dvi' for details.

If you go to: Document ... Settings ... Document Class ... 

and then edit the Custom field to add

defaultbib

then as far as I can see things should work. 

Best,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: moderncv

[Gregory Jefferis]

On 14 Jan 2013, at 18:35, Hansen, Glenn J. wrote:

> Thank you in advance for the help. I am new to lyx/tex.
> 
> I have been trying to get my cv moved to lyx/tex format and have ran into a 
> problem that I am not able to solve. I have nearly everything done but 
> getting a multiple sectioned bibliography to work(e.g., section for journal 
> articles and conference papers). I get the following error:
> 
> "! Package bibtopic Error: Found unknown `thebibliography' environment." 

The error message includes the additional information:

You should either use a package providing a known bibliography
environment (such as natbib), or use the `defaultbib' package
option as a workaround; please see the section about `Warnings
and error messages' in `bibtopic.dvi' for details.

If you go to: Document ... Settings ... Document Class ... 

and then edit the Custom field to add

defaultbib

then as far as I can see things should work. 

Best,

Greg.


--
Gregory Jefferis, PhD  
Division of Neurobiology   
MRC Laboratory of Molecular Biology,   
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 3 Jan 2013, at 15:35, Gour wrote:

 I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
 interesting.

maybe cc yourself on ticket to indicate your interest, but existing document 
comparison produces poor results as noted here:

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

so you might want to comment on that one / cc as well.

 
 After deciding to use LyX as the tool for writing manual for software
 application which will be kept under DVCS (not git, but most probably
 Fossil), I just wonder what are your experiences with different diff
 tools?
 
 In one blog post, I saw that Emacs' ediff was much better thant e.g
 KDiff, Vim's diff...
 (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
 but considering that so far I only keep my own docs under DVCS, I'm
 interested what one can expect when diff-ing LyX documents in order to
 try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 3 Jan 2013, at 15:35, Gour wrote:

 I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
 interesting.

maybe cc yourself on ticket to indicate your interest, but existing document 
comparison produces poor results as noted here:

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

so you might want to comment on that one / cc as well.

 
 After deciding to use LyX as the tool for writing manual for software
 application which will be kept under DVCS (not git, but most probably
 Fossil), I just wonder what are your experiences with different diff
 tools?
 
 In one blog post, I saw that Emacs' ediff was much better thant e.g
 KDiff, Vim's diff...
 (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
 but considering that so far I only keep my own docs under DVCS, I'm
 interested what one can expect when diff-ing LyX documents in order to
 try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 3 Jan 2013, at 15:35, Gour wrote:

> I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
> interesting.

maybe cc yourself on ticket to indicate your interest, but existing document 
comparison produces poor results as noted here:

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

so you might want to comment on that one / cc as well.

> 
> After deciding to use LyX as the tool for writing manual for software
> application which will be kept under DVCS (not git, but most probably
> Fossil), I just wonder what are your experiences with different diff
> tools?
> 
> In one blog post, I saw that Emacs' ediff was much better thant e.g
> KDiff, Vim's diff...
> (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
> but considering that so far I only keep my own docs under DVCS, I'm
> interested what one can expect when diff-ing LyX documents in order to
> try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

 I think the idea of merging is pretty obvious ? 
 
 If you mean git merge then I'm happy to tell you that some people I need to 
 work with even don't
 know what is command line in which you can write the command or decrypt 
 whatever comes from git
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

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

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

 I think the idea of merging is pretty obvious ? 
 
 If you mean git merge then I'm happy to tell you that some people I need to 
 work with even don't
 know what is command line in which you can write the command or decrypt 
 whatever comes from git
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

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

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

>> I think the idea of merging is pretty obvious ? 
> 
> If you mean "git merge" then I'm happy to tell you that some people I need to 
> work with even don't
> know what is command line in which you can write the command or decrypt 
> whatever comes from git
> in case of conflict :)
> 
> One solution would be to detect merge conflicts and call our diff algorithm 
> for the different versions.

that is exactly what I had in mind

> This would be beautiful but an order of magnitude harder to implement (surely 
> not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) "pull" (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

>> if you wanted to have bare bones support for git in lyx you would need
>> * commit (saving your changes)
>> * push (share your work)
>> * pull (fetch changes and merge with your work)
> 
> I know what I need, but the question was about your workflow.
> In particular, does it make sense in your case to automatically push after 
> commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

>> After testing out the existing svn implementation I think this is actually 
>> simpler to automatically merge with git than to lock files with svn.
> 
> Maybe more powerful, but simpler? I have hard time to understand how 
> resolving merge conflicts is _simpler_ than automatical locking part of the 
> document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

> But Ok, we don't agree here, let is sleep.

OK!

>> what would be more important for my workflow is the ability to do merges by 
>> a functional diff in lyx.
> 
> This is the key point and I recommend that you add some comment or 
> CC-yourself in bug #6889
> to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

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

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(wrote this up and noticed that much of it duplicates what Nico said – merging 
is easy and branching is not so bad either)

On 11 Dec 2012, at 18:25, Pavel Sanda wrote:

 Nico Williams wrote:
 It is precisely because locking doesn't scale that we have branching
 and merging.  Locking simply does not scale.  This is true even of
 documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper
 - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

 - only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
 b)
 - private document where VCS is used just to store history (just for sure)
 
 In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for branches aka different 
versions of the same document, which is a related idea.

 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so git in LyX would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(wrote this up and noticed that much of it duplicates what Nico said – merging 
is easy and branching is not so bad either)

On 11 Dec 2012, at 18:25, Pavel Sanda wrote:

 Nico Williams wrote:
 It is precisely because locking doesn't scale that we have branching
 and merging.  Locking simply does not scale.  This is true even of
 documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper
 - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

 - only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
 b)
 - private document where VCS is used just to store history (just for sure)
 
 In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for branches aka different 
versions of the same document, which is a related idea.

 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so git in LyX would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(wrote this up and noticed that much of it duplicates what Nico said – merging 
is easy and branching is not so bad either)

On 11 Dec 2012, at 18:25, Pavel Sanda wrote:

> Nico Williams wrote:
>> It is precisely because locking doesn't scale that we have branching
>> and merging.  Locking simply does not scale.  This is true even of
>> documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

> Conditions I had in mind were:
> a)
> - small team working on e.g. scientific paper
> - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

> - only subset of people are "IT-aware" while the others are capable at
>  most of "push the red button" to commit the change and unlock the
>  given chapter.
> b)
> - private document where VCS is used just to store history ("just for sure")
> 
> In such world even knowing what "merging" or "branching" means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for "branches" aka different 
versions of the same document, which is a related idea.

> you as someone who really does not need LyX to manipulate version tracking
> and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so "git in LyX" would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 7 Dec 2012, at 17:46, Nico Williams wrote:

 On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
 On 07/12/12 12:45, Gregory Jefferis wrote:
 Has anyone tried using latexdiff for change comparison in not merging? 
 Presumably a small script to export both versions to latex, invoke 
 latexdiff and then generate the marked-up PDF (which is what you get with 
 latexdiff) would work. For latexdiff there are already scripts to handle 
 git revisions which should allow one to diff a pair of arbitrary revisions 
 in a git repository.
 
 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.
 
 Right, the goal is to merge LyX documents.  Unless converstion to/from
 LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

Returning to the original question of merging + VCS, we currently use git + lyx 
for collaborative editing of papers in the lab (normally =3 people) using 
git's built in merge. For us this a tremendous improvement over the emailed 
word file strategy. We have not managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

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

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 7 Dec 2012, at 17:46, Nico Williams wrote:

 On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
 On 07/12/12 12:45, Gregory Jefferis wrote:
 Has anyone tried using latexdiff for change comparison in not merging? 
 Presumably a small script to export both versions to latex, invoke 
 latexdiff and then generate the marked-up PDF (which is what you get with 
 latexdiff) would work. For latexdiff there are already scripts to handle 
 git revisions which should allow one to diff a pair of arbitrary revisions 
 in a git repository.
 
 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.
 
 Right, the goal is to merge LyX documents.  Unless converstion to/from
 LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

Returning to the original question of merging + VCS, we currently use git + lyx 
for collaborative editing of papers in the lab (normally =3 people) using 
git's built in merge. For us this a tremendous improvement over the emailed 
word file strategy. We have not managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

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

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 7 Dec 2012, at 17:46, Nico Williams wrote:

> On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug <r.m.k...@gmail.com> wrote:
>> On 07/12/12 12:45, Gregory Jefferis wrote:
>>> Has anyone tried using latexdiff for change comparison in not merging? 
>>> Presumably a small script to export both versions to latex, invoke 
>>> latexdiff and then generate the marked-up PDF (which is what you get with 
>>> latexdiff) would work. For latexdiff there are already scripts to handle 
>>> git revisions which should allow one to diff a pair of arbitrary revisions 
>>> in a git repository.
>> 
>> This should work, but it would be really nice if these changes were on LyX 
>> level and that one could
>> save a file LyX file containing the differences as tracked changes.
> 
> Right, the goal is to merge LyX documents.  Unless converstion to/from
> LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

Returning to the original question of merging + VCS, we currently use git + lyx 
for collaborative editing of papers in the lab (normally <=3 people) using 
git's built in merge. For us this a tremendous improvement over the emailed 
word file strategy. We have not managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

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

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 6 Dec 2012, at 08:05, Rainer M Krug wrote:

 I agree with this comment - I wanted to use the comparison tool for comparing 
 two revisions, and
 the result was simply unusable.

Has anyone tried using latexdiff for change comparison in not merging? 
Presumably a small script to export both versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

 But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 6 Dec 2012, at 08:05, Rainer M Krug wrote:

 I agree with this comment - I wanted to use the comparison tool for comparing 
 two revisions, and
 the result was simply unusable.

Has anyone tried using latexdiff for change comparison in not merging? 
Presumably a small script to export both versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

 But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 6 Dec 2012, at 08:05, Rainer M Krug wrote:

> I agree with this comment - I wanted to use the comparison tool for comparing 
> two revisions, and
> the result was simply unusable.

Has anyone tried using latexdiff for change comparison in not merging? 
Presumably a small script to export both versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

> But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: Download problem... LyX dmg not recognized

[Gregory Jefferis]

On 2010-10-07 10:12, Bettina bettina.rehm...@gmail.com wrote:

 Hey - I want to dl LyX for Mac. I tried it on the Download page
 (http://www.lyx.org/Download#toc4), but ftp login and password are required.
 When I downloaded the LyX-1.6.7-Mac-Universal.dmg file from CNET, the disk
 image
 could not be mounted... Anyone who could help me out?

Seems like ftp.lyx.org is accessible but anonymous ftp is off at the moment.

Greg.

Re: Download problem... LyX dmg not recognized

[Gregory Jefferis]

On 2010-10-07 10:12, Bettina bettina.rehm...@gmail.com wrote:

 Hey - I want to dl LyX for Mac. I tried it on the Download page
 (http://www.lyx.org/Download#toc4), but ftp login and password are required.
 When I downloaded the LyX-1.6.7-Mac-Universal.dmg file from CNET, the disk
 image
 could not be mounted... Anyone who could help me out?

Seems like ftp.lyx.org is accessible but anonymous ftp is off at the moment.

Greg.

Re: Download problem... LyX dmg "not recognized"

[Gregory Jefferis]

On 2010-10-07 10:12, "Bettina"  wrote:

> Hey - I want to dl LyX for Mac. I tried it on the Download page
> (http://www.lyx.org/Download#toc4), but ftp login and password are required.
> When I downloaded the LyX-1.6.7-Mac-Universal.dmg file from CNET, the disk
> image
> could not be mounted... Anyone who could help me out?

Seems like ftp.lyx.org is accessible but anonymous ftp is off at the moment.

Greg.

Re: more on collaboration

[Gregory Jefferis]

On 2010-09-25 06:51, Jose Quesada ques...@gmail.com wrote:

 I tried Gobby. it's as simple as notepad, so for serious programming/writing
 it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that
 right. I think Gobby is actually feature-wise worse than in-browser
 alternatives.

For anyone who wants to do real time latex editing, then I have come across
two possibilities.

1) SubEthaEdit 

as already mentioned, really nice collaborative editing for many users,
simple to setup, fairly simple latex mode, macosx only, commercial

2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in
particular the DocShare plugin.

basic collaborative editing, appears to be limited to 2 people, a bit of a
pain to setup, good latex support, cross-platform, open source

ECF provides an example of how building a collaborative editor can be
layered on top of existing work.  See:

http://wiki.eclipse.org/RT_Shared_Editing

I guess if LyX had a round-trip consistent latex export/import these might
even provide an option for online collaborative editing of text from a LyX
document.

Best,

Greg.

Re: more on collaboration

[Gregory Jefferis]

On 2010-09-25 06:51, Jose Quesada ques...@gmail.com wrote:

 I tried Gobby. it's as simple as notepad, so for serious programming/writing
 it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that
 right. I think Gobby is actually feature-wise worse than in-browser
 alternatives.

For anyone who wants to do real time latex editing, then I have come across
two possibilities.

1) SubEthaEdit 

as already mentioned, really nice collaborative editing for many users,
simple to setup, fairly simple latex mode, macosx only, commercial

2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in
particular the DocShare plugin.

basic collaborative editing, appears to be limited to 2 people, a bit of a
pain to setup, good latex support, cross-platform, open source

ECF provides an example of how building a collaborative editor can be
layered on top of existing work.  See:

http://wiki.eclipse.org/RT_Shared_Editing

I guess if LyX had a round-trip consistent latex export/import these might
even provide an option for online collaborative editing of text from a LyX
document.

Best,

Greg.

Re: more on collaboration

[Gregory Jefferis]

On 2010-09-25 06:51, "Jose Quesada"  wrote:

> I tried Gobby. it's as simple as notepad, so for serious programming/writing
> it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that
> right. I think Gobby is actually feature-wise worse than in-browser
> alternatives.

For anyone who wants to do real time latex editing, then I have come across
two possibilities.

1) SubEthaEdit 

as already mentioned, really nice collaborative editing for many users,
simple to setup, fairly simple latex mode, macosx only, commercial

2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in
particular the DocShare plugin.

basic collaborative editing, appears to be limited to 2 people, a bit of a
pain to setup, good latex support, cross-platform, open source

ECF provides an example of how building a collaborative editor can be
layered on top of existing work.  See:

http://wiki.eclipse.org/RT_Shared_Editing

I guess if LyX had a round-trip consistent latex export/import these might
even provide an option for online collaborative editing of text from a LyX
document.

Best,

Greg.

Re: more on collaboration

[Gregory Jefferis]

Hi Kevin, Jose et al,

We use version control (git) + to write papers in the lab.  It works fine
but handling merge conflicts is still difficult; the chaps in the lab are
all very computer literate but I regularly have to help out with a broken
merge. It's certainly too complicated for me to insist on with external
collaborators. For them I initially suggested LyX + track changes. However
LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only
partly solved in 2.0.

The beauty of real time editing is that it handles merge conflicts in a way
that is easy to understand and really pretty transparent.  Of course for it
to be transparent, there has to be a clear way to see who (and ideally when)
last edited any piece of text.  For my group and colleagues beyond the lab,
collaborative editing (a la SubEthaEdit) would be the killer feature that
would really expand the audience for LyX.  I hope that at some point this
will resonate with one of the developers with the skills to implement this
kind of feature.

Best,

Greg.

-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: more on collaboration

[Gregory Jefferis]

Hi all,

I would distinguish two kinds of collaborative editing.

* interactive collaborative editing - 2 or more people working
simultaneously on a document

* non-interactive collaborative editing - only one person actually modifying
the document at any one time BUT others always having live access to the
latest version if required.

I think typically you would spend 5% of writing time in the first mode but
that implementing it solves nasty problems with collaborating in the second
mode.

More specifically: 

On 2010-09-24 17:41, Richard Heck rgh...@comcast.net wrote:

 On 09/24/2010 11:43 AM, Les Denham wrote:
 On Friday 24 September 2010 10:29:10 Rob Oakes wrote:
 I have to confess that I too am somewhat puzzled by this, but I can see
 a use case that would be good for me. Say I've written a paper with a
 collaborator. We are now at a pretty late stage in the process. It might
 be useful to be able to read through the document together and make
 changes we can both see in real time. I'm not saying this really would
 be all that great, but I can see using it.

This is the kind of situation where actively using real time editing is
really useful and for me it crops up whenever I am writing something with a
colleague for another institution.  It is incredibly motivating and leads to
better writing if you can skype and write in an _interactive_ and
collaborative fashion. There are potential low tech ways to do this using
screen sharing, but they do lose the significant benefit of attaching edits.
Furthermore since you don't usually want to have a permanent share of your
desktop you can't leave them on the whole time and that for me is the
problem - in my view the real benefit of a rich collaborative editing
implementation is that allows much easier and more consistent -
non-interactive collaborative editing.

Non-interactive collaborative editing means that there can always be one
live version of a document to which anyone can apply changes that are
versioned, identified and much more likely.  Essentially it solves the
conflicting merge problem by automatically merging all the time so that you
are always looking at the latest version (and can be alerted to recent
changes).  You can try and do this with traditional version control
arrangements but you will always run into a conflict if the system isn't
designed for the possibility of interactive collaborative editing.

Does this seem reasonable to others?  Or have other people found ways to
solve the non-interactive collaborative writing situation when people end up
modifying the same document.  In my experience this happens often enough
that it's a problem and existing software that I am aware of makes it too
hard to solve for most researchers.

Greg.

Re: more on collaboration

[Gregory Jefferis]

Hi Kevin, Jose et al,

We use version control (git) + to write papers in the lab.  It works fine
but handling merge conflicts is still difficult; the chaps in the lab are
all very computer literate but I regularly have to help out with a broken
merge. It's certainly too complicated for me to insist on with external
collaborators. For them I initially suggested LyX + track changes. However
LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only
partly solved in 2.0.

The beauty of real time editing is that it handles merge conflicts in a way
that is easy to understand and really pretty transparent.  Of course for it
to be transparent, there has to be a clear way to see who (and ideally when)
last edited any piece of text.  For my group and colleagues beyond the lab,
collaborative editing (a la SubEthaEdit) would be the killer feature that
would really expand the audience for LyX.  I hope that at some point this
will resonate with one of the developers with the skills to implement this
kind of feature.

Best,

Greg.

-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: more on collaboration

[Gregory Jefferis]

Hi all,

I would distinguish two kinds of collaborative editing.

* interactive collaborative editing - 2 or more people working
simultaneously on a document

* non-interactive collaborative editing - only one person actually modifying
the document at any one time BUT others always having live access to the
latest version if required.

I think typically you would spend 5% of writing time in the first mode but
that implementing it solves nasty problems with collaborating in the second
mode.

More specifically: 

On 2010-09-24 17:41, Richard Heck rgh...@comcast.net wrote:

 On 09/24/2010 11:43 AM, Les Denham wrote:
 On Friday 24 September 2010 10:29:10 Rob Oakes wrote:
 I have to confess that I too am somewhat puzzled by this, but I can see
 a use case that would be good for me. Say I've written a paper with a
 collaborator. We are now at a pretty late stage in the process. It might
 be useful to be able to read through the document together and make
 changes we can both see in real time. I'm not saying this really would
 be all that great, but I can see using it.

This is the kind of situation where actively using real time editing is
really useful and for me it crops up whenever I am writing something with a
colleague for another institution.  It is incredibly motivating and leads to
better writing if you can skype and write in an _interactive_ and
collaborative fashion. There are potential low tech ways to do this using
screen sharing, but they do lose the significant benefit of attaching edits.
Furthermore since you don't usually want to have a permanent share of your
desktop you can't leave them on the whole time and that for me is the
problem - in my view the real benefit of a rich collaborative editing
implementation is that allows much easier and more consistent -
non-interactive collaborative editing.

Non-interactive collaborative editing means that there can always be one
live version of a document to which anyone can apply changes that are
versioned, identified and much more likely.  Essentially it solves the
conflicting merge problem by automatically merging all the time so that you
are always looking at the latest version (and can be alerted to recent
changes).  You can try and do this with traditional version control
arrangements but you will always run into a conflict if the system isn't
designed for the possibility of interactive collaborative editing.

Does this seem reasonable to others?  Or have other people found ways to
solve the non-interactive collaborative writing situation when people end up
modifying the same document.  In my experience this happens often enough
that it's a problem and existing software that I am aware of makes it too
hard to solve for most researchers.

Greg.

Re: more on collaboration

[Gregory Jefferis]

Hi Kevin, Jose et al,

We use version control (git) + to write papers in the lab.  It works fine
but handling merge conflicts is still difficult; the chaps in the lab are
all very computer literate but I regularly have to help out with a broken
merge. It's certainly too complicated for me to insist on with external
collaborators. For them I initially suggested LyX + track changes. However
LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only
partly solved in 2.0.

The beauty of real time editing is that it handles merge conflicts in a way
that is easy to understand and really pretty transparent.  Of course for it
to be transparent, there has to be a clear way to see who (and ideally when)
last edited any piece of text.  For my group and colleagues beyond the lab,
collaborative editing (a la SubEthaEdit) would be the killer feature that
would really expand the audience for LyX.  I hope that at some point this
will resonate with one of the developers with the skills to implement this
kind of feature.

Best,

Greg.

-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: more on collaboration

[Gregory Jefferis]

Hi all,

I would distinguish two kinds of collaborative editing.

* interactive collaborative editing - 2 or more people working
simultaneously on a document

* non-interactive collaborative editing - only one person actually modifying
the document at any one time BUT others always having live access to the
latest version if required.

I think typically you would spend 5% of writing time in the first mode but
that implementing it solves nasty problems with collaborating in the second
mode.

More specifically: 

On 2010-09-24 17:41, "Richard Heck"  wrote:

> On 09/24/2010 11:43 AM, Les Denham wrote:
>> On Friday 24 September 2010 10:29:10 Rob Oakes wrote:
> I have to confess that I too am somewhat puzzled by this, but I can see
> a use case that would be good for me. Say I've written a paper with a
> collaborator. We are now at a pretty late stage in the process. It might
> be useful to be able to read through the document together and make
> changes we can both see "in real time". I'm not saying this really would
> be all that great, but I can see using it.

This is the kind of situation where actively using real time editing is
really useful and for me it crops up whenever I am writing something with a
colleague for another institution.  It is incredibly motivating and leads to
better writing if you can skype and write in an _interactive_ and
collaborative fashion. There are potential low tech ways to do this using
screen sharing, but they do lose the significant benefit of attaching edits.
Furthermore since you don't usually want to have a permanent share of your
desktop you can't leave them on the whole time and that for me is the
problem - in my view the real benefit of a rich collaborative editing
implementation is that allows much easier and more consistent -
non-interactive collaborative editing.

Non-interactive collaborative editing means that there can always be one
live version of a document to which anyone can apply changes that are
versioned, identified and much more likely.  Essentially it solves the
conflicting merge problem by automatically merging all the time so that you
are always looking at the latest version (and can be alerted to recent
changes).  You can try and do this with traditional version control
arrangements but you will always run into a conflict if the system isn't
designed for the possibility of interactive collaborative editing.

Does this seem reasonable to others?  Or have other people found ways to
solve the non-interactive collaborative writing situation when people end up
modifying the same document.  In my experience this happens often enough
that it's a problem and existing software that I am aware of makes it too
hard to solve for most researchers.

Greg.

Bibunits example only generates one of 2 bibliographies

[Gregory Jefferis]

I am trying to make an article with 2 bibliographies.  To get me going I am
starting with the example on the wiki:

http://wiki.lyx.org/Examples/Bibunits

However when I make a PDF I do not get one of the bibliographies.
Apparently it is not being processed by bibtex.   When I copy the bib files
(refs.bib) into LyX's temp dir, and run bibtex manually and regenerate the
PDF, everything works.

There is a hint on the wiki which is supposed to solve this problem:

Hint: The problem that LyX does not find the extra aux files for bibunits
can be solved without running bibtex manually and without a shell script.
Just add the following to the preamble, and LyX will automatically run
bibtex on the extra files:
  \makeatletter  
  \renewcomman...@bibunitname}{\jobname.\the\@bibunitauxcnt}
  \makeatother

But it is obviously not working for me.  Would anyone have any
fixes/workarounds/insight?

Thank you very much your help,

Greg.

Sys details:

OS X 10.5.8
LyX 1.6.4.2
MacTex/TeXLive 2009


-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Bibunits example only generates one of 2 bibliographies

[Gregory Jefferis]

I am trying to make an article with 2 bibliographies.  To get me going I am
starting with the example on the wiki:

http://wiki.lyx.org/Examples/Bibunits

However when I make a PDF I do not get one of the bibliographies.
Apparently it is not being processed by bibtex.   When I copy the bib files
(refs.bib) into LyX's temp dir, and run bibtex manually and regenerate the
PDF, everything works.

There is a hint on the wiki which is supposed to solve this problem:

Hint: The problem that LyX does not find the extra aux files for bibunits
can be solved without running bibtex manually and without a shell script.
Just add the following to the preamble, and LyX will automatically run
bibtex on the extra files:
  \makeatletter  
  \renewcomman...@bibunitname}{\jobname.\the\@bibunitauxcnt}
  \makeatother

But it is obviously not working for me.  Would anyone have any
fixes/workarounds/insight?

Thank you very much your help,

Greg.

Sys details:

OS X 10.5.8
LyX 1.6.4.2
MacTex/TeXLive 2009


-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Bibunits example only generates one of 2 bibliographies

[Gregory Jefferis]

I am trying to make an article with 2 bibliographies.  To get me going I am
starting with the example on the wiki:

http://wiki.lyx.org/Examples/Bibunits

However when I make a PDF I do not get one of the bibliographies.
Apparently it is not being processed by bibtex.   When I copy the bib files
(refs.bib) into LyX's temp dir, and run bibtex manually and regenerate the
PDF, everything works.

There is a hint on the wiki which is supposed to solve this problem:

Hint: The problem that LyX does not find the extra aux files for bibunits
can be solved without running bibtex manually and without a shell script.
Just add the following to the preamble, and LyX will automatically run
bibtex on the extra files:
  \makeatletter  
  \renewcomman...@bibunitname}{\jobname.\the\@bibunitauxcnt}
  \makeatother

But it is obviously not working for me.  Would anyone have any
fixes/workarounds/insight?

Thank you very much your help,

Greg.

Sys details:

OS X 10.5.8
LyX 1.6.4.2
MacTex/TeXLive 2009


-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Re: Cross References with Export to HTML (Word)

[Gregory Jefferis]

Replying to my own question:

On 2009-06-03 22:40, Gregory Jefferis jeffe...@gmail.com wrote:

 I want to do a respectable export of to something that Word can open for final
 submission to a journal. My document has bibtex references and multiple
 figures (present as floats from which I have removed the actual graphics file
 because I only need the text in my export).  After a lot of experimenting the
 best looking output so far comes from Export to HTML (MS Word).  However
 although the main body of the text and the citations and reference list come
 out ok the figures are causing trouble.  Specifically the cross references to
 figures in the text are all rendered as ??.
 

It seems that there is an interaction with the babel package.  When I turn
off babel, export of figure cross references work fine. Perhaps my babel
(from MacTex2008) is broken - I have not tried to update.

(Preferences ... Language ... Language Settings: Use babel checkbox)

 Suggestions for alternative export paradigms are also welcome but for me:
 
 1) Export to ODT produces a corrupt output file.

This is also true for Open Document (ODT) export which previously zipped up
all of the latex intermediate files in the temporary directory producing a
file that was unintelligible to OpenOffice.

Best wishes,

Greg.

 LyX 1.6.2 on Mac 10.5.6

Re: Cross References with Export to HTML (Word)

[Gregory Jefferis]

Replying to my own question:

On 2009-06-03 22:40, Gregory Jefferis jeffe...@gmail.com wrote:

 I want to do a respectable export of to something that Word can open for final
 submission to a journal. My document has bibtex references and multiple
 figures (present as floats from which I have removed the actual graphics file
 because I only need the text in my export).  After a lot of experimenting the
 best looking output so far comes from Export to HTML (MS Word).  However
 although the main body of the text and the citations and reference list come
 out ok the figures are causing trouble.  Specifically the cross references to
 figures in the text are all rendered as ??.
 

It seems that there is an interaction with the babel package.  When I turn
off babel, export of figure cross references work fine. Perhaps my babel
(from MacTex2008) is broken - I have not tried to update.

(Preferences ... Language ... Language Settings: Use babel checkbox)

 Suggestions for alternative export paradigms are also welcome but for me:
 
 1) Export to ODT produces a corrupt output file.

This is also true for Open Document (ODT) export which previously zipped up
all of the latex intermediate files in the temporary directory producing a
file that was unintelligible to OpenOffice.

Best wishes,

Greg.

 LyX 1.6.2 on Mac 10.5.6

Re: Cross References with Export to HTML (Word)

[Gregory Jefferis]

Replying to my own question:

On 2009-06-03 22:40, "Gregory Jefferis" <jeffe...@gmail.com> wrote:

> I want to do a respectable export of to something that Word can open for final
> submission to a journal. My document has bibtex references and multiple
> figures (present as floats from which I have removed the actual graphics file
> because I only need the text in my export).  After a lot of experimenting the
> best looking output so far comes from Export to HTML (MS Word).  However
> although the main body of the text and the citations and reference list come
> out ok the figures are causing trouble.  Specifically the cross references to
> figures in the text are all rendered as ??.
> 

It seems that there is an interaction with the babel package.  When I turn
off babel, export of figure cross references work fine. Perhaps my babel
(from MacTex2008) is broken - I have not tried to update.

(Preferences ... Language ... Language Settings: Use babel checkbox)

> Suggestions for alternative export paradigms are also welcome but for me:
> 
> 1) Export to ODT produces a corrupt output file.

This is also true for Open Document (ODT) export which previously zipped up
all of the latex intermediate files in the temporary directory producing a
file that was unintelligible to OpenOffice.

Best wishes,

Greg.

> LyX 1.6.2 on Mac 10.5.6

Cross References with Export to HTML (Word)

[Gregory Jefferis]

Hello All,

I want to do a respectable export of to something that Word can open for
final submission to a journal. My document has bibtex references and
multiple figures (present as floats from which I have removed the actual
graphics file because I only need the text in my export).  After a lot of
experimenting the best looking output so far comes from Export to HTML (MS
Word).  However although the main body of the text and the citations and
reference list come out ok the figures are causing trouble.  Specifically
the cross references to figures in the text are all rendered as ??.

I'm sure this is an FAQ, but I've searched both wiki and archives and can't
seem to find anything.  I would really appreciate any help at this point.

Suggestions for alternative export paradigms are also welcome but for me:

1) Export to ODT produces a corrupt output file.
2) Export to RTF does not render citations but just produces the labels (ie
\citep{root2008} in the source goes to root2008 in the output)

Thank you so much for your help,

Greg Jefferis.

LyX 1.6.2 on Mac 10.5.6
-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/NB/jefferis_g
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Cross References with Export to HTML (Word)

[Gregory Jefferis]

Hello All,

I want to do a respectable export of to something that Word can open for
final submission to a journal. My document has bibtex references and
multiple figures (present as floats from which I have removed the actual
graphics file because I only need the text in my export).  After a lot of
experimenting the best looking output so far comes from Export to HTML (MS
Word).  However although the main body of the text and the citations and
reference list come out ok the figures are causing trouble.  Specifically
the cross references to figures in the text are all rendered as ??.

I'm sure this is an FAQ, but I've searched both wiki and archives and can't
seem to find anything.  I would really appreciate any help at this point.

Suggestions for alternative export paradigms are also welcome but for me:

1) Export to ODT produces a corrupt output file.
2) Export to RTF does not render citations but just produces the labels (ie
\citep{root2008} in the source goes to root2008 in the output)

Thank you so much for your help,

Greg Jefferis.

LyX 1.6.2 on Mac 10.5.6
-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/NB/jefferis_g
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu

Cross References with Export to HTML (Word)

[Gregory Jefferis]

Hello All,

I want to do a respectable export of to something that Word can open for
final submission to a journal. My document has bibtex references and
multiple figures (present as floats from which I have removed the actual
graphics file because I only need the text in my export).  After a lot of
experimenting the best looking output so far comes from Export to HTML (MS
Word).  However although the main body of the text and the citations and
reference list come out ok the figures are causing trouble.  Specifically
the cross references to figures in the text are all rendered as ??.

I'm sure this is an FAQ, but I've searched both wiki and archives and can't
seem to find anything.  I would really appreciate any help at this point.

Suggestions for alternative export paradigms are also welcome but for me:

1) Export to ODT produces a corrupt output file.
2) Export to RTF does not render citations but just produces the labels (ie
\citep{root2008} in the source goes to root2008 in the output)

Thank you so much for your help,

Greg Jefferis.

LyX 1.6.2 on Mac 10.5.6
-- 
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.

http://www2.mrc-lmb.cam.ac.uk/NB/jefferis_g
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu