Re: [O] Latex image placement (...again. H vs. h!)
John Hendy writes: > Was just rediscovering how to properly get floats to drop in where I > want them in LaTeX export (right where I say vs. where LaTeX thinks > is convenient). Another way to tackle this problem may be to just not use floats. As the name suggests, these construct is meant to let things float. :) If you want a figure or table to be placed at exactly the point where you place it, why are you using a float environment? Most people answer at this point, because they want the captions and all examples with captions use the float environment. Thats because with captions and in the general case it makes sense to let LaTeX find the right place for these things. If you want exact, controlled placements and also a caption, have a look at the package 'caption' (version 3.1, author Axel Sommerfeldt). Then you can get rid of floats and don't have to bother with obscure placement rules. :) -- Until the next mail..., Stefan. pgpbWvwGJsXom.pgp Description: PGP signature
Re: [O] Bug: Column view does not function properly in Agenda buffers [7.7]
Hi Bastien first of all, thank you very much for your help! Bastien wrote: The first minor concern: There is a leading star '*' in front of the ITEM. Could you remove this star '*', too? Fixed. I can confirm, that this bug is fixed, too. Thanks a lot! The second minor concern: = In a column-view, that is invoked inside Agenda buffer, there are lines, that seperate the todos for each day in the agenda. In version 7.5 those lines contained the corresponding date to give orientation. Is this with a standard agenda view? Which one? It is with a standard agenda view: My commands: C-c a L --> Timeline for current buffer (standard) C-c C-x C-c --> column-view invoked inside Agenda buffer My example: === #+begin_src org * NEXTACTION [#B] Test1 :Tag_A: SCHEDULED: <2011-08-20 Sa> * DONE Test2:Tag_B: SCHEDULED: <2011-08-20 Sa> * WAITING [#C] Test3:Tag_C: SCHEDULED: <2011-08-21 So> * NEXTACTION [#A] Test4 :Tag_A: SCHEDULED: <2011-08-22 Mo> #+end_src The result in version 7.5: == | | Samstag20 August 2011 || | | | NEXTACTION | B | Test1 | :Tag_A:| | | 2011-08-20 Sa | DONE | | Test2 | :Tag_B:| | | 2011-08-20 Sa | | | Sonntag21 August 2011 || | | | WAITING| C | Test3 | :Tag_C:| | | 2011-08-21 So | | | Montag 22 August 2011 W34 || | | | NEXTACTION | A | Test4 | :Tag_A:| | | 2011-08-22 Mo | The result in version 7.7 (git yesterday): == | | || | | | NEXTACTION | B | Test1 | :Tag_A:| | | 2011-08-20 Sa | DONE | | Test2 | :Tag_B:| | | 2011-08-20 Sa | | | || | | | WAITING| C | Test3 | :Tag_C:| | | 2011-08-21 So | | | || | | | NEXTACTION | A | Test4 | :Tag_A:| | | 2011-08-22 Mo | The Bug: I am missing the lines that contain the name of the days and the date. In the example above, the first line contains "Samstag20 August 2011". I hope, that I did explain the bug clearly. Please let me know, if I can add some information to help you locating the bug. Please note: I am on vacation for two weeks from now. Thus I will not answer emails until 2nd of September. Best, Christian -- Christian Schmidt mailto: c...@canau.de
Re: [O] git diff: hunk header config
Hi Michael, On Sat, Aug 20, 2011 at 6:12 PM, Michael Brand wrote: > 1) Since there has been no feedback yet I'd like to bump my previous > post repeated below. I would like to have the config of the repo > orgmode.org/org-mode.git to be extended to support more useful diff > hunk headers containing e. g. the prototype of the current function > for *.el files. Like > "@@ -12991,7 +12991,7 @@ (defun org-align-tags-here (to-col)" > instead of the current > "@@ -12991,7 +12991,7 @@ If ONOFF is `on' or `off', don't toggle but set to > thi" > Can this be done in the repo orgmode.org/org-mode.git at all? > Effective for everyone after only git pull? > This is a very useful config. Thanks for pointing it out. But don't you think this is a client side setting? As far as I am aware, settings don't carry over from the remote repository. Its distributed versioning after all. :) To make this a server side setting, you would have to add .git/config and .gitattributes to the repo. But I think that is not correct as many users might have their own settings that will have to be remerged at every update. What do you think? In any case, I think this would be a wonderful addition to org-faq.org on Worg. -- Suvayu Open source is the future. It sets us free.
Re: [O] Git merge tool for Org files
Carsten Dominik writes: > One of the obstacle for using Org-mode for collaborative programs is > that many operations add or remove text from the beginning or end of a > file, or which add or remove a subnode from an outline tree. On of the things that I think would be necessary is a way to put an Org document into a "normalized" representation and then evaluate the differences between two of these. The generic exporter started by Bastien could probably deliver such a representation. > These are operations that confuse the git merger, in particular > if two people have added something to a file, or removed/added > sequential sibling nodes. Git merge only works reasonably well for program code (and only if there's no changelog stuff inside the file). The merge driver functionality is there to solve that problem for when you _can_ be smarter. It is absolutely not necessary to write that driver in any particular language, all that git does is to call the driver with three versions of the same file as the argument. > I believe that this could be solved with a dedicated merge driver > that understands the integrity of an outline (sub)tree, and that > knows that the sequence of two new subtrees added by different people > does not matter. You ask a potentially very big question here, this should be constrained to keep it manageable. I think a reasonable strategy is to merge two Org documents "from the outside in", that is starting with the topmost tree elements. If you are merging at the tree level, anything inside the tree should not matter at all. I'm not sure the sequence doesn't matter, but that can hardly be decided by the merge driver unless it figures out how to sort elements of a tree. The second step would then be to check the leaf nodes of the tree for concurrent changes, which probably still need to be resolved manually. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] org-paste-subtree and org-refile broken
At Sat, 13 Aug 2011 09:03:40 -0500, Matt Lundin wrote: > > David Maus writes: > > > At Sat, 13 Aug 2011 09:25:19 +0200, > > David Maus wrote: > >> > >> Hi Matt, > >> Hi Sebastien, > >> > >> I pushed a temporary workaround to master that should fix the problem > >> with refile and capture. Both depend on a buggy behavior of > >> org-paste-subtree, i.e. pasting a subtree *above* the target headline > >> when called with point at the beginning of the target headline. > > > > If you have already pulled, please pull again. Had confused something, > > fixed now. > > Thanks for fixing this! Refiling is working well now. Could you explain > what you mean by a "buggy behavior of org-paste-subtree." AFAIK, > org-paste-subtree has always pasted the subtree above the current tree > if the point is at the beginning of the headline. Is there something in > the documentation that suggests that this should not be the case? I > believe this behavior is consistent with > org-insert-heading-respect-content, which inserts a new heading above > the current heading if called at the beginning of a headline. For > instance, in the following example... > > --8<---cut here---start->8--- > * One > Text in one > * Two > Text in two > ** Subpoint two >Text in subpoint two. > * Three > Text in three > * Four > Text in four > --8<---cut here---end--->8--- > > If I kill headline four, move the point to the beginning of headline > three, and yank (i.e., call org-paste-subtree), I get the following, > which seems to me correct: > > --8<---cut here---start->8--- > * One > Text in one > * Two > Text in two > ** Subpoint two >Text in subpoint two. > * Four > Text in four > > * Three > Text in three > --8<---cut here---end--->8--- > > Similarly, if I place the cursor on three and call > org-insert-heading-respect-content (M-RET), the new headline is inserted > above the headline: > > --8<---cut here---start->8--- > * One > Text in one > * Two > Text in two > ** Subpoint two >Text in subpoint two. > * > * Three > Text in three > * Four > Text in four > --8<---cut here---end--->8--- > What bothers me is the fact that paste-subtree operates on the previous sibling of a headline if called with explicit level and point at the beginning of a headline. --8<---cut here---start->8--- * One Text in one * Two Text in two ** Subpoint two Text in subpoint two. * Three Text in three * Four Text in four --8<---cut here---end--->8--- Cut Four, move point at the beginning of Three and paste with a level of 2 (C-u 2 C-c C-x C-y) and you get: --8<---cut here---start->8--- * One Text in one * Two Text in two ** Subpoint two Text in subpoint two. ** Four Text in four * Three Text in three --8<---cut here---end--->8--- For refile this means that if you refile Four to Two, refile operates on Two by operating on Two's following-sibling, Three. There seems to be no practical problem, it's just... strange. Especially if you consider pasting a subtree with point somewhere on a headline but not at the beginning. Here [] represents point. --8<---cut here---start->8--- * One Text in one * T[]wo Text in two ** Subpoint two Text in subpoint two. * Three Text in three --8<---cut here---end--->8--- I've noticed that Org did not cover this case, e.g. calculated the paste level correctly but pasted above. What I expected Org to do in this case is to paste the subtree as last child of Two. If this expectation is implemented (I am on it) then pasting above if point is at beginning of headline is strange because point is still on the heading but the direction of paste is reversed. It's not a practical problem if the subtree is pasted with the same level as the target headline (i.e. its sibling), but still... Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgphGox1OIwbu.pgp Description: PGP signature
Re: [O] Latex image placement (...again. H vs. h!)
John Hendy writes:
> Was just rediscovering how to properly get floats to drop in where I
> want them in LaTeX export (right where I say vs. where LaTeX thinks is
> convenient). I knew I'd posted on this about a year ago and was trying
> to search for the thread. In the process, I came across this from the
> manual [1]:
>
> ,---
> | To modify the placement option of the floating environment,
> | add something like ‘placement=[h!]’ to the attributes.
> `---
>
> Now, I'm not sure what all the options are, but this didn't work for
> me. Only [H] properly dropped my floats in where I wanted them. Is
> there a reason for this? In looking in wikibooks, they seem to
> indicate that there are a few variants on the "here" option: [2]
>
> ,---
> | h: Place the float here, i.e., approximately at the same point it occurs
> | in the source text (however, not exactly at the spot)
> |
> | !: Override internal parameters Latex uses for determining "good"
> float positions.
> |
> | H: Places the float at precisely the location in the LaTeX code.
> | Requires the float package,[1] e.g., \usepackage{float}.
> | This is somewhat equivalent to h!.
> `---
>
> So, does my need for [H] mean that LaTeX just really, really, really
> wanted to space my images differently than I wanted? It does seem like
> h! *should* work based on the wikibooks description, but it didn't. Is
> [H] the only absolutely positive way to make sure floats are right
> where you want them based on the surrounding text?
>
> Thanks,
> John
>
> ---
> [1] http://orgmode.org/manual/Images-in-LaTeX-export.html
> [2] http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions
>
>
Hi John,
I think of [h!] as "try really hard to place the float here" and [H] as
"place the float here regardless of the consequences."
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Markup in BEGIN_EXAMPLE and alike block
Vladimir Lomov gmail.com> writes: > Hi. > I want to emphasize (using bold monospace font when exporting to HTML) > some parts of text in example block. Consider the following example: > *** Determining adapter chipset and used driver > #+BEGIN_EXAMPLE > zbox$ lspci -v > ... > 04:00.0 Network controller: *RaLink RT2860* > Subsystem: Device 1a3b:1059 > Flags: bus master, fast devsel, latency 0, IRQ 19 > Memory at febf (32-bit, non-prefetchable) [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Kernel driver in use: *rt2800pci* > Kernel modules: rt2800pci > #+END_EXAMPLE > But in exported html file the '*'s are remain. Is it possible to use > markup in BEGIN_EXAMPLE? Or I have to use another type of block? This would do the trick: *** Determining adapter chipset and used driver #+BEGIN_HTML zbox$ lspci -v ... 04:00.0 Network controller: RaLink RT2860 Subsystem: Device 1a3b:1059 Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at febf (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel driver in use: rt2800pci Kernel modules: rt2800pci #+END_HTML #+OPTIONS: f:nil Ciao, Renzo
[O] Latex image placement (...again. H vs. h!)
Was just rediscovering how to properly get floats to drop in where I
want them in LaTeX export (right where I say vs. where LaTeX thinks is
convenient). I knew I'd posted on this about a year ago and was trying
to search for the thread. In the process, I came across this from the
manual [1]:
,---
| To modify the placement option of the floating environment,
| add something like ‘placement=[h!]’ to the attributes.
`---
Now, I'm not sure what all the options are, but this didn't work for
me. Only [H] properly dropped my floats in where I wanted them. Is
there a reason for this? In looking in wikibooks, they seem to
indicate that there are a few variants on the "here" option: [2]
,---
| h: Place the float here, i.e., approximately at the same point it occurs
| in the source text (however, not exactly at the spot)
|
| !: Override internal parameters Latex uses for determining "good"
float positions.
|
| H: Places the float at precisely the location in the LaTeX code.
| Requires the float package,[1] e.g., \usepackage{float}.
| This is somewhat equivalent to h!.
`---
So, does my need for [H] mean that LaTeX just really, really, really
wanted to space my images differently than I wanted? It does seem like
h! *should* work based on the wikibooks description, but it didn't. Is
[H] the only absolutely positive way to make sure floats are right
where you want them based on the surrounding text?
Thanks,
John
---
[1] http://orgmode.org/manual/Images-in-LaTeX-export.html
[2] http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions
[O] [PATCH] New function org-find-timestamps
Hello ! I would like to submit the attached patch for org.el. This patch introduces the new function org-find-timestamps, which has the documentation given below. Part of its functionality is also added as a new option to the function org-sparse-tree. However, the full functionality of org-find-timestamps can only be used if it is called directly. This is my first patch to org-mode so I would be grateful for any advice and comments. (There already has been some very helpful discussion with Bastien see news://news.gmane.org:119/4e29c4ba.5090...@online.de) If this patch is deemed acceptable I would be glad to submit a secound patch to the documentation as well. By the way: There are surely official documentation standards, that I could adhere for this. However, at present I cannot find them. Could anyone provide me a pointer please ? with kind regards, Marc-Oliver Ihm org-find-timestamps is an interactive Lisp function in `org.el'. (org-find-timestamps &optional FIRST-DATE LAST-DATE BUFFER-NAME WHICH COLLECT-METHOD SORT) Find inactive timestamps within a date-range and maybe sort them. This function can help to bring the notes, that you take within org-mode, into a chronological order, even if they are scattered among many different nodes. The result is somewhat like a diary, listing the timestamps of the notes, that you have taken on each day. Such a listing might help to provide an answer to the common question 'What have I done last Week ?' Please be aware however: This intended usage requires, that you routinely insert (inactive) timestamps into the notes that you write, which is a prerequisite habit that you may or may not want to adopt. org-find-timstamps works in these steps: Create a regular expression to match a given range of dates; search for it and display the results either as a sparse tree or with the help of occur. The original buffer is not modified. The Arguments FIRST-DATE and LAST-DATE (-mm-dd) define the range of timestamps to search for. In general anything, that can be understood by `org-read-date' will be accepted. BUFFER-NAME specifies the name of the buffer to search. If nil, use the current buffer. The Argument WHICH (one of the symbols `active', `inactive' or `both'), tells the function, which timestamps to search for. COLLECT-METHOD can be one of `org-occur', `occur' and `multi-occur' and determines, Which buffers to search (current or all org-mode buffers) and how to present the matches. Results will be sorted according to SORT (either the symbol `y' or `n'). Sorting however is only possible, if results are presented with `occur' or `multi-occur'. All Arguments can be `nil' (or ommitted), in which case their values are queried interactively. diff --git a/lisp/org.el b/lisp/org.el index de8c72b..baffde4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12256,10 +12256,11 @@ p Enter a property name and its value (both with completion on existing r Show entries matching a regular expression (`/' can be used as well) d Show deadlines due within `org-deadline-warning-days'. b Show deadlines and scheduled items before a date. -a Show deadlines and scheduled items after a date." +a Show deadlines and scheduled items after a date. +i Show inactive or active timestamps within a date interval." (interactive "P") (let (ans kwd value) -(message "Sparse tree: [r]egexp [/]regexp [t]odo [T]odo-kwd [m]atch [p]roperty\n [d]eadlines [b]efore-date [a]fter-date") +(message "Sparse tree: [r]egexp [/]regexp [t]odo [T]odo-kwd [m]atch [p]roperty\n [d]eadlines [b]efore-date [a]fter-date [i]nterval") (setq ans (read-char-exclusive)) (cond ((equal ans ?d) @@ -12268,6 +12269,8 @@ a Show deadlines and scheduled items after a date." (call-interactively 'org-check-before-date)) ((equal ans ?a) (call-interactively 'org-check-after-date)) + ((equal ans ?i) + (org-find-timestamps nil nil nil nil 'org-occur nil)) ((equal ans ?t) (org-show-todo-tree nil)) ((equal ans ?T) @@ -20665,6 +20668,198 @@ Still experimental, may disappear in the future." ;; make tree, check each match with the callback (org-occur "CLOSED: +\\[\\(.*?\\)\\]" nil callback))) +(defun org-find-timestamps (&optional first-date last-date buffer-name which collect-method sort) + "Find inactive timestamps within a date-range and maybe sort them. + +This function can help to bring the notes, that you take within +org-mode, into a chronological order, even if they are scattered +among many different nodes. The result is somewhat like a diary, +listing the timestamps of the notes, that you have taken on each day. +Such a listing might help to provide an answer to the common question +'What have I done last Week ?' +Please be aware however: This intended usage requires, +that you routinely insert (inactive) timestamps into the +notes that you write, which is a prereq
Re: [O] Git merge tool for Org files
Hello everyone,
On Sat, Aug 20, 2011 at 6:04 PM, Nick Dokos wrote:
> And emacs has the emerge tool already built in. In fact, Chacon
> mentions emerge as one of the presets in git, so it may be even
> simpler than what he describes.
When there is a conflict, this should work:
$ git mergetool --tool=emerge
This pops out an emacs window for every conflicting file. But I believe
it is possible to specify a custom mergetool rather easily using `emacs
-nw` or `emacsclient -t`.
Excerpt from `man git-config`:
merge.tool
Controls which merge resolution program is used by
git-mergetool(1). Valid built-in values are: "kdiff3", "tkdiff",
"meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", "diffuse",
"ecmerge", "tortoisemerge", "p4merge", "araxis" and "opendiff".
Any other value is treated is custom merge tool and there must be
a corresponding mergetool..cmd option.
However what I have found is it is rather difficult to merge blocks of
text reasonably trivially. Often diff (or git diff) is thrown off when:
1. There is a TODO/tag change very close to some other change in text
2. A headline is promoted or demoted without any change in the content
3. There is minor change in a body of text but line wrapping makes the
diff very difficult to follow as it lists many more changes.
I think the problem is all tools like patch/diff are made for source
code. So they understand source code structures like code blocks {..} in
most languages or methods/functions like someFunc() {..} in C/C++ or
(defun somefn () ...) in lisp. Where as plain text / Org text is
structured more as paragraphs and trees, line wrapping is usually
inconsequential. So a dedicated git driver to merge org files might be
worth it. It could automatically take care of differences solely due to
wrapping and other formatting changes like promoting or demoting a tree,
whereas only present to the users areas where text content has been
changed (a driver that understands the extra word is what I care about
and not the apparent 5 line change because of the wrapping).
Maybe the way to do this would be to first simplify the text into a form
where formatting is irrelevant. The driver could then take the
formatting merge related decisions and present the content merging
decisions to the user. Of course this is all talk and probably a *big*
project in itself. :-p
Hopefully I was able to express myself clearly.
--
Suvayu
Open source is the future. It sets us free.
[O] [PATCH] Documentation of Babel header arguments
Add a line to indicate header arguments are lowercase.
>From 4a8719c9e7f95fa76041077dfaf0f5d21241517d Mon Sep 17 00:00:00 2001
From: Tom Dye
Date: Sat, 20 Aug 2011 06:48:35 -1000
Subject: [PATCH] * doc/org.texi: Added a line to specify that header arguments are lowercase.
---
doc/org.texi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index f0a363b..fa051d0 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -12158,7 +12158,8 @@ evaluation of the @code{factorial} code block.
@node Specific header arguments, , Using header arguments, Header arguments
@subsection Specific header arguments
-The following header arguments are defined:
+Header arguments consist of an initial colon followed by the name of the
+argument in lowercase letters. The following header arguments are defined:
@menu
* var:: Pass arguments to code blocks
--
1.7.1
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] git diff: hunk header config
Hi all 1) Since there has been no feedback yet I'd like to bump my previous post repeated below. I would like to have the config of the repo orgmode.org/org-mode.git to be extended to support more useful diff hunk headers containing e. g. the prototype of the current function for *.el files. Like "@@ -12991,7 +12991,7 @@ (defun org-align-tags-here (to-col)" instead of the current "@@ -12991,7 +12991,7 @@ If ONOFF is `on' or `off', don't toggle but set to thi" Can this be done in the repo orgmode.org/org-mode.git at all? Effective for everyone after only git pull? 2) Note: Also a config of git, but for diff of crypted Org files is shown at the end of this recent post: http://thread.gmane.org/gmane.emacs.orgmode/45781/focus=45938 Michael On Sun, Jul 31, 2011 at 13:49, Michael Brand wrote: > Hi all > > I suggest to change the config of git diff in the org-mode.git repo to > the more helpful hunk header (the @@...@@ line) style: > > #+begin_src diff > @@ -12991,7 +12991,7 @@ (defun org-align-tags-here (to-col) > (goto-char (match-beginning 1)) > (insert " ") > (delete-region (point) (1+ (match-beginning 2))) > - (setq ncol (max (1+ (current-column)) > + (setq ncol (max (current-column) > (1+ col) > (if (> to-col 0) > to-col > #+end_src > > which is similar to GNU diff -p/--show-c-function. The current, not > configured default "style" is: > > #+begin_src diff > @@ -12991,7 +12991,7 @@ If ONOFF is `on' or `off', don't toggle but set to thi > (goto-char (match-beginning 1)) > (insert " ") > (delete-region (point) (1+ (match-beginning 2))) > - (setq ncol (max (1+ (current-column)) > + (setq ncol (max (current-column) > (1+ col) > (if (> to-col 0) > to-col > #+end_src > > Would that be commonly welcome for at least firstly Emacs Lisp and texinfo? > > If yes, the following is to be added to the org-mode.git repo: > > 1) new file .gitattributes: > #+begin_src > *.el diff=el > *.texi diff=texinfo > #+end_src > > 2) append to .git/config: > #+begin_src > [diff "el"] > xfuncname = "^(\\(def[a-z]+ .+)$" > [diff "texinfo"] > xfuncname="^(@(sub)*section.*)$" > #+end_src > > I hope that somebody can do this in the repo in such a way that it > will be effective after git pull and git clone automatically, so that > nobody has to care about later. > > Michael
Re: [O] Git merge tool for Org files
Andrea Crotti wrote: > On 08/18/2011 12:45 PM, Carsten Dominik wrote: > > Hi, > > > > I was wondering if anyone here has the skills and interest to write > > a git merge driver for Org mode files, in the way > > > > > > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c > > > > does this for GNU style ChangeLog files? > > > > One of the obstacle for using Org-mode for collaborative programs is that > > many operations add or remove text from the beginning or end of a file, > > or which add or remove a subnode from an outline tree. > > These are operations that confuse the git merger, in particular > > if two people have added something to a file, or removed/added > > sequential sibling nodes. > > > > I believe that this could be solved with a dedicated merge driver > > that understands the integrity of an outline (sub)tree, and that > > knows that the sequence of two new subtrees added by different people > > does not matter. > > > > The idea for this is actually (I believe) from Brian Gough who asked me > > about it at FOSDEM. I have now also run into this problem and would > > really find it great if such a merge driver could be written. > > Unfortunately, I do not have the skill for this. > > > > - Carsten > Does the merge driver need to be written in C? > It looks quite a complex task considering that org-mode files > are not so easy to parse... > and > On 08/20/2011 04:42 PM, Carsten Dominik wrote: > > I have no idea, but I would think that it could also be written in Perl, > > for example. > > > > Yes from what I understand from the source it can be any executable > that outputs things as git expects them. > There are no compile time dependencies on git as far as I see. > > So maybe why not writing it (even a prototype) directly in Elisp? > That would solve many things right? > > Perhaps a better way is to not insist on automatic conflict resolution (changelogs are relatively simple, whereas org files would be more complicated: one would have to impose lots of rules to make sure that the merge would be successful). A relatively painless manual, interactive merge might fit the bill better. In his book "Pro Git"[fn:1], Scott Chacon describes how to hook an external merge tool into git (he uses the -free- Perforce Visual Merge Tool for illustration, but it should be possible to use anything). And emacs has the emerge tool already built in. In fact, Chacon mentions emerge as one of the presets in git, so it may be even simpler than what he describes. This is all theory and we all know that [fn:2] "In theory, there is no difference between theory and practice - in practice, there is." But it seems worth investigating this a bit, before striking off into an unknown unknown. [fn:3] Nick Footnotes: [fn:1] Available on the web at http://progit.org/book, as well as on paper (see the website for details). Section 7.1 is the relevant part. [fn:2] ...in the words of that immortal philosopher, Yogi Berra, ... [fn:3] OK, ok - Donald Rumsfeld said the "unknown unknown" thing first.
Re: [O] Git merge tool for Org files
On 08/20/2011 04:42 PM, Carsten Dominik wrote: I have no idea, but I would think that it could also be written in Perl, for example. Yes from what I understand from the source it can be any executable that outputs things as git expects them. There are no compile time dependencies on git as far as I see. So maybe why not writing it (even a prototype) directly in Elisp? That would solve many things right?
Re: [O] Git merge tool for Org files
On 20.8.2011, at 16:17, Andrea Crotti wrote: > On 08/18/2011 12:45 PM, Carsten Dominik wrote: >> Hi, >> >> I was wondering if anyone here has the skills and interest to write >> a git merge driver for Org mode files, in the way >> >> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c >> >> does this for GNU style ChangeLog files? >> >> One of the obstacle for using Org-mode for collaborative programs is that >> many operations add or remove text from the beginning or end of a file, >> or which add or remove a subnode from an outline tree. >> These are operations that confuse the git merger, in particular >> if two people have added something to a file, or removed/added >> sequential sibling nodes. >> >> I believe that this could be solved with a dedicated merge driver >> that understands the integrity of an outline (sub)tree, and that >> knows that the sequence of two new subtrees added by different people >> does not matter. >> >> The idea for this is actually (I believe) from Brian Gough who asked me >> about it at FOSDEM. I have now also run into this problem and would >> really find it great if such a merge driver could be written. >> Unfortunately, I do not have the skill for this. >> >> - Carsten > Does the merge driver need to be written in C? I have no idea, but I would think that it could also be written in Perl, for example. > It looks quite a complex task considering that org-mode files > are not so easy to parse... > > Anyway a partly unrelated thing, with git attributes I'm able > to see the diff of crypted org files very easily (maybe someone > is interested), adding to .git/config: > > [diff "gpg"] > textconv = gpg2 --decrypt > > and to .gitattributes: > *.gpg diff=gpg interesting! - Carsten
Re: [O] Git merge tool for Org files
On 08/18/2011 12:45 PM, Carsten Dominik wrote: Hi, I was wondering if anyone here has the skills and interest to write a git merge driver for Org mode files, in the way http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c does this for GNU style ChangeLog files? One of the obstacle for using Org-mode for collaborative programs is that many operations add or remove text from the beginning or end of a file, or which add or remove a subnode from an outline tree. These are operations that confuse the git merger, in particular if two people have added something to a file, or removed/added sequential sibling nodes. I believe that this could be solved with a dedicated merge driver that understands the integrity of an outline (sub)tree, and that knows that the sequence of two new subtrees added by different people does not matter. The idea for this is actually (I believe) from Brian Gough who asked me about it at FOSDEM. I have now also run into this problem and would really find it great if such a merge driver could be written. Unfortunately, I do not have the skill for this. - Carsten Does the merge driver need to be written in C? It looks quite a complex task considering that org-mode files are not so easy to parse... Anyway a partly unrelated thing, with git attributes I'm able to see the diff of crypted org files very easily (maybe someone is interested), adding to .git/config: [diff "gpg"] textconv = gpg2 --decrypt and to .gitattributes: *.gpg diff=gpg
[O] [PATCH] Add customisable face for inlinetasks
Hi, Attached is a small patch that defines a customisable face for inlinetasks. -- Suvayu Open source is the future. It sets us free. >From 16359dd0352baa0e636aec6bf6573fbbb913bef4 Mon Sep 17 00:00:00 2001 From: Suvayu Ali Date: Tue, 2 Aug 2011 00:24:50 +0200 Subject: [PATCH] Define org-inlinetask face --- lisp/org-inlinetask.el |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index 7d0d691..33a8abd 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -405,6 +405,12 @@ Either remove headline and meta data, or do special formatting." (current-column))) (defvar org-indent-indentation-per-level) ; defined in org-indent.el + +(defface org-inlinetask + (org-compatible-face 'org-level-8 '((t (:bold t + "Face for inlinetask headlines." + :group 'org-faces) + (defun org-inlinetask-fontify (limit) "Fontify the inline tasks." (let* ((nstars (if org-odd-levels-only @@ -425,7 +431,7 @@ Either remove headline and meta data, or do special formatting." (add-text-properties (match-beginning 2) (match-end 2) '(face org-hide font-lock-fontified t)) (add-text-properties (match-beginning 3) (match-end 3) - '(face shadow font-lock-fontified t) + '(face org-inlinetask font-lock-fontified t) (defun org-inlinetask-toggle-visibility () "Toggle visibility of inline task at point." -- 1.7.4.4
