Re: Pipe in FlexInset Names
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: LyX document diff/merge tools for cooperative editing?
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: LyX document diff/merge tools for cooperative editing?
(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?
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?
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: Pipe in FlexInset Names
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?
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
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 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: APA6 class with LyX?
> > 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?
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: LyX document diff/merge tools for cooperative editing?
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: No bibliography environment in DocBook document class
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: APA6 class with LyX?
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: APA6 class with LyX?
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?
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