Re: APA6 class with LyX?

[Wolfgang Engelmann]

Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
Rob, those links are very helpful and clarifying things which are not 
obvious to the novice!
Wolfgang
 http://blog.oak-tree.us/index.php/2009/11/02/custom-lyx-nih
 http://blog.oak-tree.us/index.php/2009/11/14/customize-lyx-character-sty
 les (Character styles)
 http://blog.oak-tree.us/index.php/2010/05/19/latex-cv-part4

Re: APA6 class with LyX?

[José Matos]

On 12/11/2012 09:29 AM, Wolfgang Engelmann wrote:
 Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
 Rob, those links are very helpful and clarifying things which are not 
 obvious to the novice!
 Wolfgang

If other doubts arrive (probability ~= 1) do not hesitate to use this list.

Now that I have used that symbol above I am craving for a coffee. ~=] :-D

Regards,

-- 
José Matos

Re: APA6 class with LyX?

[Rob Oakes]

Hi Wolfgang,

I'm glad they were helpful:

On Tue, 2012-12-11 at 10:36 +0100, Wolfgang Engelmann wrote:
 Am Montag, 10. Dezember 2012, 21:31:25 schrieben Sie:
 
 Hi, Rob, 
 
 has this been done already:
 
 TeXLive 2009 is included with Ubuntu 10.04, if you are able to update your 
 Linux distribution. If not, it is possible to install newer versions of 
 TeXLive alongside an existing install. I am currently working on a blog 
 post that explains how this is done and I will post it when finished.

A lot of those entries have gotten a bit long in the tooth (though I
think everything is still applicable, one of the really nice thing about
TeX and LyX, it never feels like there is a system of planned
obsolescence).

Regarding how to upgrade TeX Live, I did write a post describing how to
do it: http://blog.oak-tree.us/index.php/2010/07/15/latex-custom

Though it talks about LaTeX 2010, the instructions can be adapted to
nearly any LaTeX distribution, as far as I know. I used the same
procedure recently to install TeXLive 2012.

(Speaking of which, if you use TeXLive 2012 and luaTeX, be very careful.
They've made some big changes, and it's caused a bunch of things to
break. Or, at least none of my luaTeX documents will compile anymore;
both from LyX and pure TeX. I haven't yet had time to sort out where the
problem is.)

I'd love to link to a more updated set of instructions. When you finish
your post, let me know, I'll to post a link.

Cheers,

Rob

Re: No bibliography environment in DocBook document class

[Nico Williams]

On Mon, Dec 10, 2012 at 5:22 PM, José Matos jama...@lyx.org wrote:
 On 12/10/2012 10:46 PM, Nico Williams wrote:
 Why is there no bibliography environment in the DocBook document
 classes?  There must be a reason, of course, but then, bibtex is still
 supported, so that's strange...

 The reason why it was never implemented is/was lake of time, no more no
 less. :-)

OK, thanks :) that's the answer I was hoping for.  Not that I have
time to contribute code here, but just for my edification: where would
I look in the source code?  In particular I'm using the docbook class
but exporting to LyXHTML.  I'm not sure why I'm doing that -- only
that I've found that to work best for my purposes (namely: that more
metadata gets preserved in the resulting XHTML).

Thanks!

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

[Pavel Sanda]

Gregory Jefferis wrote:
 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.

We currently use integrated SVN support of LyX for this. 
The merge conflicts are avoided by locking the whole document or childern 
(parts of the text).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

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

[Nico Williams]

On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda sa...@lyx.org wrote:
 We currently use integrated SVN support of LyX for this.
 The merge conflicts are avoided by locking the whole document or childern 
 (parts of the text).

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).

 While we are at possible LyX support of git, can you explicitly name the 
 commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

 I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
 immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

 To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
 SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: APA6 class with LyX?

[Jacob Bishop]

 Hi Mateo, John, Ray, Jacob (and everyone else),

 It seems APA6 is useful to a lot of people and in particular to you
 guys. How about we make a layout for it together then?


I will be happy to help. As soon as I get caught up on some things, I will
clean up what I am using and see if we can use or modify it to fit the
need. Expect to hear back sometime this weekend (when I get a bit more free
time).

Jacob

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

[Pavel Sanda]

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).

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)
- 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
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: Pipe in FlexInset Names

[Andrew Parsloe]

On 11/12/2012 5:23 a.m., Richard Heck wrote:

On 12/08/2012 04:17 AM, Andrew Parsloe wrote:

(1) If an inset name contains a vertical bar, |, the part after the
bar is not shown in the Insert  Custom Insets list, but is retained
in LyX format. Using the schema, inset definition = Custom Insets
list = LyX file format,

InsetLayout Flex:foo|bah = foo = \begin_inset Flex foo|bah

(This works also with quotes around inset names containing spaces.)
This is surprisingly useful, but doesn't seem to be documented in the
Customization manual. It allows information, which doesn't need to be
shown to the user, to be passed in the name of the inset from the
module in which it is defined to LyX. I've used this 'to serious
purpose' and without ill effect so far, but would like to be sure,
given the lack of documentation, that it is not going to snag on some
other feature of LyX.


The | character is used in Qt4 to specify menu shortcuts. See e.g. the
stdmenus.inc file. So whatever follows it is being interpreted as an
attempt to specify a menu shortcut. So I'd not recommend using it this
way, but I'm not sure what we should do about it. At least, we should
put something into the documentation.

...


Richard

Thanks for the responses to this and my other custom inset queries 
Richard. I've put in a bug report about ResetsFont in custom insets. I'm 
going to continue to use the pipe symbol for its unintended purpose -- 
I've yet to see any deleterious side-effects and some deliberate 
trying-to-break-it experimenting suggests Qt4 is fairly robust in the 
way it handles inappropriate shortcut suggestions.


Andrew

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

[Nico Williams]

On Tue, Dec 11, 2012 at 12:25 PM, Pavel Sanda sa...@lyx.org 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).

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

 - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

 - 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)

Again, merging is not hard.

 In such world even knowing what merging or branching means qualifies
 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this trick?


JMarc

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

[Pavel Sanda]

Nico Williams wrote:
 I believe merging is easier than locking, even for small teams.

That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is push red
button, push green button and I know what I'm talking about :)

Pavel

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

[Nico Williams]

On Tuesday, December 11, 2012, Pavel Sanda wrote:

 Nico Williams wrote:
  I believe merging is easier than locking, even for small teams.

 That's because you probably work with people with computer science
 background.
 The moment you step out of these waters the most you can expect is push
 red
 button, push green button and I know what I'm talking about :)


Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

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?

[Jean-Marc Lasgouttes]

Le 12/12/12 00:06, Nico Williams a écrit :

Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.


Sure, but not trivial to implement...

JMarc

Re: Pipe in FlexInset Names

[Richard Heck]

On 12/11/2012 05:02 PM, Jean-Marc Lasgouttes wrote:

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this trick?


And I am sure we can find some way legitimately to provide the same 
functionality in 2.1, which may not be insanely far away now.


rh

Re: APA6 class with LyX?

[Wolfgang Engelmann]

Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
Rob, those links are very helpful and clarifying things which are not 
obvious to the novice!
Wolfgang
 http://blog.oak-tree.us/index.php/2009/11/02/custom-lyx-nih
 http://blog.oak-tree.us/index.php/2009/11/14/customize-lyx-character-sty
 les (Character styles)
 http://blog.oak-tree.us/index.php/2010/05/19/latex-cv-part4

Re: APA6 class with LyX?

[José Matos]

On 12/11/2012 09:29 AM, Wolfgang Engelmann wrote:
 Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
 Rob, those links are very helpful and clarifying things which are not 
 obvious to the novice!
 Wolfgang

If other doubts arrive (probability ~= 1) do not hesitate to use this list.

Now that I have used that symbol above I am craving for a coffee. ~=] :-D

Regards,

-- 
José Matos

Re: APA6 class with LyX?

[Rob Oakes]

Hi Wolfgang,

I'm glad they were helpful:

On Tue, 2012-12-11 at 10:36 +0100, Wolfgang Engelmann wrote:
 Am Montag, 10. Dezember 2012, 21:31:25 schrieben Sie:
 
 Hi, Rob, 
 
 has this been done already:
 
 TeXLive 2009 is included with Ubuntu 10.04, if you are able to update your 
 Linux distribution. If not, it is possible to install newer versions of 
 TeXLive alongside an existing install. I am currently working on a blog 
 post that explains how this is done and I will post it when finished.

A lot of those entries have gotten a bit long in the tooth (though I
think everything is still applicable, one of the really nice thing about
TeX and LyX, it never feels like there is a system of planned
obsolescence).

Regarding how to upgrade TeX Live, I did write a post describing how to
do it: http://blog.oak-tree.us/index.php/2010/07/15/latex-custom

Though it talks about LaTeX 2010, the instructions can be adapted to
nearly any LaTeX distribution, as far as I know. I used the same
procedure recently to install TeXLive 2012.

(Speaking of which, if you use TeXLive 2012 and luaTeX, be very careful.
They've made some big changes, and it's caused a bunch of things to
break. Or, at least none of my luaTeX documents will compile anymore;
both from LyX and pure TeX. I haven't yet had time to sort out where the
problem is.)

I'd love to link to a more updated set of instructions. When you finish
your post, let me know, I'll to post a link.

Cheers,

Rob

Re: No bibliography environment in DocBook document class

[Nico Williams]

On Mon, Dec 10, 2012 at 5:22 PM, José Matos jama...@lyx.org wrote:
 On 12/10/2012 10:46 PM, Nico Williams wrote:
 Why is there no bibliography environment in the DocBook document
 classes?  There must be a reason, of course, but then, bibtex is still
 supported, so that's strange...

 The reason why it was never implemented is/was lake of time, no more no
 less. :-)

OK, thanks :) that's the answer I was hoping for.  Not that I have
time to contribute code here, but just for my edification: where would
I look in the source code?  In particular I'm using the docbook class
but exporting to LyXHTML.  I'm not sure why I'm doing that -- only
that I've found that to work best for my purposes (namely: that more
metadata gets preserved in the resulting XHTML).

Thanks!

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

[Pavel Sanda]

Gregory Jefferis wrote:
 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.

We currently use integrated SVN support of LyX for this. 
The merge conflicts are avoided by locking the whole document or childern 
(parts of the text).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

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

[Nico Williams]

On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda sa...@lyx.org wrote:
 We currently use integrated SVN support of LyX for this.
 The merge conflicts are avoided by locking the whole document or childern 
 (parts of the text).

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).

 While we are at possible LyX support of git, can you explicitly name the 
 commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

 I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
 immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

 To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
 SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: APA6 class with LyX?

[Jacob Bishop]

 Hi Mateo, John, Ray, Jacob (and everyone else),

 It seems APA6 is useful to a lot of people and in particular to you
 guys. How about we make a layout for it together then?


I will be happy to help. As soon as I get caught up on some things, I will
clean up what I am using and see if we can use or modify it to fit the
need. Expect to hear back sometime this weekend (when I get a bit more free
time).

Jacob

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

[Pavel Sanda]

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).

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)
- 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
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: Pipe in FlexInset Names

[Andrew Parsloe]

On 11/12/2012 5:23 a.m., Richard Heck wrote:

On 12/08/2012 04:17 AM, Andrew Parsloe wrote:

(1) If an inset name contains a vertical bar, |, the part after the
bar is not shown in the Insert  Custom Insets list, but is retained
in LyX format. Using the schema, inset definition = Custom Insets
list = LyX file format,

InsetLayout Flex:foo|bah = foo = \begin_inset Flex foo|bah

(This works also with quotes around inset names containing spaces.)
This is surprisingly useful, but doesn't seem to be documented in the
Customization manual. It allows information, which doesn't need to be
shown to the user, to be passed in the name of the inset from the
module in which it is defined to LyX. I've used this 'to serious
purpose' and without ill effect so far, but would like to be sure,
given the lack of documentation, that it is not going to snag on some
other feature of LyX.


The | character is used in Qt4 to specify menu shortcuts. See e.g. the
stdmenus.inc file. So whatever follows it is being interpreted as an
attempt to specify a menu shortcut. So I'd not recommend using it this
way, but I'm not sure what we should do about it. At least, we should
put something into the documentation.

...


Richard

Thanks for the responses to this and my other custom inset queries 
Richard. I've put in a bug report about ResetsFont in custom insets. I'm 
going to continue to use the pipe symbol for its unintended purpose -- 
I've yet to see any deleterious side-effects and some deliberate 
trying-to-break-it experimenting suggests Qt4 is fairly robust in the 
way it handles inappropriate shortcut suggestions.


Andrew

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

[Nico Williams]

On Tue, Dec 11, 2012 at 12:25 PM, Pavel Sanda sa...@lyx.org 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).

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

 - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

 - 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)

Again, merging is not hard.

 In such world even knowing what merging or branching means qualifies
 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this trick?


JMarc

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

[Pavel Sanda]

Nico Williams wrote:
 I believe merging is easier than locking, even for small teams.

That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is push red
button, push green button and I know what I'm talking about :)

Pavel

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

[Nico Williams]

On Tuesday, December 11, 2012, Pavel Sanda wrote:

 Nico Williams wrote:
  I believe merging is easier than locking, even for small teams.

 That's because you probably work with people with computer science
 background.
 The moment you step out of these waters the most you can expect is push
 red
 button, push green button and I know what I'm talking about :)


Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

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?

[Jean-Marc Lasgouttes]

Le 12/12/12 00:06, Nico Williams a écrit :

Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.


Sure, but not trivial to implement...

JMarc

Re: Pipe in FlexInset Names

[Richard Heck]

On 12/11/2012 05:02 PM, Jean-Marc Lasgouttes wrote:

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this trick?


And I am sure we can find some way legitimately to provide the same 
functionality in 2.1, which may not be insanely far away now.


rh

Re: APA6 class with LyX?

[Wolfgang Engelmann]

Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
Rob, those links are very helpful and clarifying things which are not 
obvious to the novice!
Wolfgang
> http://blog.oak-tree.us/index.php/2009/11/02/custom-lyx-nih
> http://blog.oak-tree.us/index.php/2009/11/14/customize-lyx-character-sty
> les (Character styles)
> http://blog.oak-tree.us/index.php/2010/05/19/latex-cv-part4

Re: APA6 class with LyX?

[José Matos]

On 12/11/2012 09:29 AM, Wolfgang Engelmann wrote:
> Am Montag, 10. Dezember 2012, 21:31:25 schrieb Rob Oakes:
> Rob, those links are very helpful and clarifying things which are not 
> obvious to the novice!
> Wolfgang

If other doubts arrive (probability ~= 1) do not hesitate to use this list.

Now that I have used that symbol above I am craving for a coffee. ~=] :-D

Regards,

-- 
José Matos

Re: APA6 class with LyX?

[Rob Oakes]

Hi Wolfgang,

I'm glad they were helpful:

On Tue, 2012-12-11 at 10:36 +0100, Wolfgang Engelmann wrote:
> Am Montag, 10. Dezember 2012, 21:31:25 schrieben Sie:
> 
> Hi, Rob, 
> 
> has this been done already:
> 
> TeXLive 2009 is included with Ubuntu 10.04, if you are able to update your 
> Linux distribution. If not, it is possible to install newer versions of 
> TeXLive alongside an existing install. I am currently working on a blog 
> post that explains how this is done and I will post it when finished.

A lot of those entries have gotten a bit long in the tooth (though I
think everything is still applicable, one of the really nice thing about
TeX and LyX, it never feels like there is a system of planned
obsolescence).

Regarding how to upgrade TeX Live, I did write a post describing how to
do it: http://blog.oak-tree.us/index.php/2010/07/15/latex-custom

Though it talks about LaTeX 2010, the instructions can be adapted to
nearly any LaTeX distribution, as far as I know. I used the same
procedure recently to install TeXLive 2012.

(Speaking of which, if you use TeXLive 2012 and luaTeX, be very careful.
They've made some big changes, and it's caused a bunch of things to
break. Or, at least none of my luaTeX documents will compile anymore;
both from LyX and pure TeX. I haven't yet had time to sort out where the
problem is.)

I'd love to link to a more updated set of instructions. When you finish
your post, let me know, I'll to post a link.

Cheers,

Rob

Re: No bibliography environment in DocBook document class

[Nico Williams]

On Mon, Dec 10, 2012 at 5:22 PM, José Matos  wrote:
> On 12/10/2012 10:46 PM, Nico Williams wrote:
>> Why is there no bibliography environment in the DocBook document
>> classes?  There must be a reason, of course, but then, bibtex is still
>> supported, so that's strange...
>
> The reason why it was never implemented is/was lake of time, no more no
> less. :-)

OK, thanks :) that's the answer I was hoping for.  Not that I have
time to contribute code here, but just for my edification: where would
I look in the source code?  In particular I'm using the docbook class
but exporting to LyXHTML.  I'm not sure why I'm doing that -- only
that I've found that to work best for my purposes (namely: that more
metadata gets preserved in the resulting XHTML).

Thanks!

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

[Pavel Sanda]

Gregory Jefferis wrote:
> 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.

We currently use integrated SVN support of LyX for this. 
The merge conflicts are avoided by locking the whole document or childern 
(parts of the text).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

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

[Nico Williams]

On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda  wrote:
> We currently use integrated SVN support of LyX for this.
> The merge conflicts are avoided by locking the whole document or childern 
> (parts of the text).

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).

> While we are at possible LyX support of git, can you explicitly name the 
> commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

> I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
> immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

> To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
> SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: APA6 class with LyX?

[Jacob Bishop]

>
> Hi Mateo, John, Ray, Jacob (and everyone else),
>
> It seems APA6 is useful to a lot of people and in particular to you
> guys. How about we make a layout for it together then?
>

I will be happy to help. As soon as I get caught up on some things, I will
clean up what I am using and see if we can use or modify it to fit the
need. Expect to hear back sometime this weekend (when I get a bit more free
time).

Jacob

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

[Pavel Sanda]

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).

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)
- 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
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: Pipe in FlexInset Names

[Andrew Parsloe]

On 11/12/2012 5:23 a.m., Richard Heck wrote:

On 12/08/2012 04:17 AM, Andrew Parsloe wrote:

(1) If an inset name contains a vertical bar, |, the part after the
bar is not shown in the Insert > Custom Insets list, but is retained
in LyX format. Using the schema, inset definition => Custom Insets
list => LyX file format,

InsetLayout Flex:foo|bah => foo => \begin_inset Flex foo|bah

(This works also with quotes around inset names containing spaces.)
This is surprisingly useful, but doesn't seem to be documented in the
Customization manual. It allows information, which doesn't need to be
shown to the user, to be passed in the name of the inset from the
module in which it is defined to LyX. I've used this 'to serious
purpose' and without ill effect so far, but would like to be sure,
given the lack of documentation, that it is not going to snag on some
other feature of LyX.


The | character is used in Qt4 to specify menu shortcuts. See e.g. the
stdmenus.inc file. So whatever follows it is being interpreted as an
attempt to specify a menu shortcut. So I'd not recommend using it this
way, but I'm not sure what we should do about it. At least, we should
put something into the documentation.

...


Richard

Thanks for the responses to this and my other custom inset queries 
Richard. I've put in a bug report about ResetsFont in custom insets. I'm 
going to continue to use the pipe symbol for its unintended purpose -- 
I've yet to see any deleterious side-effects and some deliberate 
trying-to-break-it experimenting suggests Qt4 is fairly robust in the 
way it handles inappropriate shortcut suggestions.


Andrew

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

[Nico Williams]

On Tue, Dec 11, 2012 at 12:25 PM, 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).
>
> Conditions I had in mind were:
> a)
> - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

> - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

> - 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)

Again, merging is not hard.

> In such world even knowing what "merging" or "branching" means qualifies
> you as someone who really does not need LyX to manipulate version tracking
> and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this "trick"?


JMarc

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

[Pavel Sanda]

Nico Williams wrote:
> I believe merging is easier than locking, even for small teams.

That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is "push red
button, push green button" and I know what I'm talking about :)

Pavel

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

[Nico Williams]

On Tuesday, December 11, 2012, Pavel Sanda wrote:

> Nico Williams wrote:
> > I believe merging is easier than locking, even for small teams.
>
> That's because you probably work with people with computer science
> background.
> The moment you step out of these waters the most you can expect is "push
> red
> button, push green button" and I know what I'm talking about :)
>

Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

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?

[Jean-Marc Lasgouttes]

Le 12/12/12 00:06, Nico Williams a écrit :

Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.


Sure, but not trivial to implement...

JMarc

Re: Pipe in FlexInset Names

[Richard Heck]

On 12/11/2012 05:02 PM, Jean-Marc Lasgouttes wrote:

Le 11/12/12 23:00, Andrew Parsloe a écrit :

Thanks for the responses to this and my other custom inset queries
Richard. I've put in a bug report about ResetsFont in custom insets. I'm
going to continue to use the pipe symbol for its unintended purpose --
I've yet to see any deleterious side-effects and some deliberate
trying-to-break-it experimenting suggests Qt4 is fairly robust in the
way it handles inappropriate shortcut suggestions.


If you are ready to have your layout broken one day this is OK. Could 
you give an example of the usefulness of this "trick"?


And I am sure we can find some way legitimately to provide the same 
functionality in 2.1, which may not be insanely far away now.


rh