Re: [O] [export] Should sidewaystable option automatically add rotating package?
On 13.9.2013, at 10:01, Detlef Steuer wrote: > Hi! > >> Hello, >> >> Rasmus writes: >> >>> So the question is should it be a default package? >>> >>> I think not. E.g. tabu isn't loaded. Amsmath isn't loaded if you >>> generate a matrix. >> >> I think the "tabu" case (and longtable...) is different from "rotating". >> >> No feature in Org requires "tabu" or "longtable" unless user explicitly >> writes "tabu" or "longtable" somewhere in the buffer (i.e. >> in :environment attribute). >> >> On the other hand, "rotating" or "wrapfig" may be needed without the >> user knowing about it (e.g. when setting :float or :wrap attributes). >> >> Therefore, I think "wrapfig" and "rotating" belong to the same boat. >> Either we require them both in default packages, or we do not require >> any and add a footnote about it in the manual. I have no preference. >> > > I think it is more consistent to provide these packages automagically. > > There seems no downside besides slightly longer latex startup times. > Org already loads some default packages to perform its export magic. > Why not try to be "feature" complete in the sense Nicloas describes: > User doesn't try something special with latex, but uses > commands/options provided by org, so a bare bone export can be expected > work. > > Personally I would appreciate it very much if org followed the > principle of least surprise in these cases, as these surprises tend to > show up, if time is running out ;-) OK, let me ask like this: Does anyone know about conflicts arising from loading wrapfig and rotating? - Carsten > > Just my two user cents. > > Detlef > > >> On the same line, we could remove "longtable" from >> `org-latex-default-packages-alist', if only to spare a few kittens. >> >> WDYT? >> >> >> Regards, >> >> -- >> Nicolas Goaziou >> >> > > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [PATCH] Recenter around #+begin_src when moving to previous/next code block
Hi Sebastien, I don't think this patch is the right thing - is feels different from standard Emacs behavior. - Carsten On 13.9.2013, at 12:02, Sebastien Vauban wrote: > Hello, > > When moving with C-c C-v C-n (or p) from one code block to the next (or > previous), it's much better if the code block gets centered (vs hidden, > forcing the user to scroll down, as it currently is). > > This is the purpose of this easy patch. > > Best regards, > Seb > > From: "Sebastien Vauban" > Date: Fri, 13 Sep 2013 11:56:56 +0200 > Subject: [PATCH] Recenter around #+begin_src when moving to previous/next > code block > > * ob-core.el (org-babel-next-src-block): Recenter after jumping to next code > block. > (org-babel-previous-src-block): Recenter after jumping to previous code > block. > > --- > lisp/ob-core.el |6 -- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index d57806b..fd4b1bd 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -1748,14 +1748,16 @@ buffer or nil if no such result exists." > "Jump to the next source block. > With optional prefix argument ARG, jump forward ARG many source blocks." > (interactive "p") > - (org-next-block arg nil org-babel-src-block-regexp)) > + (org-next-block arg nil org-babel-src-block-regexp) > + (recenter)) > > ;;;###autoload > (defun org-babel-previous-src-block (&optional arg) > "Jump to the previous source block. > With optional prefix argument ARG, jump backward ARG many source blocks." > (interactive "p") > - (org-previous-block arg org-babel-src-block-regexp)) > + (org-previous-block arg org-babel-src-block-regexp) > + (recenter)) > > (defvar org-babel-load-languages) > > -- > 1.7.9 > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [PATCH 1/1] Fix typo 'org-ctags-create-tags in comment
Applied, thanks. - Carsten On 14.9.2013, at 12:08, Gregor Zattler wrote: > --- > Fix a minor typo. > > lisp/org-ctags.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el > index 98d47e5..9d8ed6c 100644 > --- a/lisp/org-ctags.el > +++ b/lisp/org-ctags.el > @@ -131,7 +131,7 @@ > ;; > ;; (progn > ;; (message "-- rebuilding tags tables...") > -;; (mapc 'org-create-tags tags-table-list)) > +;; (mapc 'org-ctags-create-tags tags-table-list)) > > ;;; Code: > > -- > 1.8.4.rc3 > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
On 14.9.2013, at 19:16, Suvayu Ali wrote: > Hi Nicolas, > > On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote: >> Hello, >> >> Carsten Dominik writes: >> >>> When the functions are done, please go ahead and commit them and bind >>> them to C-up/down. >> >> Done. > > Do you think it would be nicer if org-forward-paragraph takes arguments > like forward-paragraph? Would be more consistent, specially if someone > writes wrappers (confession: I'm actually writing one myself). Hi, while I never use these commands with arguments, I think it would be nice if they had this ability. Regards - Carsten > > Cheers, > > -- > Suvayu > > Open source is the future. It sets us free. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
On Sat, Sep 14, 2013 at 9:16 PM, James Harkins wrote: > Suvayu Ali gmail.com> writes: > >> I think it is unwise to keep coming up with ways to support semantically >> wrong behaviour just for the sake of backwards compatibility. This was >> changed with good reason and after a lot of discussions. If you >> continue on this path, you will have to keep maintaining this yourself >> for all eternity (sorry about the hyperbole :-p). It's a lot of work >> for a long time just to avoid some annoying work now. > I mostly agree, but as others are noting some of us had months and months worth of presentations in the old format, so it's not always trivial to update and old .org file and re-export. I don't think we need to semantically (or syntactically?) support the old behavior (I wouldn't say wrong), but it's worth coming up with solutions for those who especially aren't using git or quasi-frequent snapshots. Keep in mind that a majority of users may very well be using distro-specific releases. I have no idea how, say, Ubuntu's releases compare to Org's. In any case, I'm mostly in agreement that Org's changed and thus the file structure should change... but not all of us use the git and/or snapshot Org version with regular frequency and thus I expect a fair amount of trickling in of users surprised at the incompatibility. John > FWIW, I hit this issue about half a year ago, and argued pretty strenuously > that breaking backward compatibility was a Terrible Terrible Thing. But, > having adapted to the new markup spec, I find it's more logically consistent > *and* easier to read while editing. > > I still have a semester's worth of class slides to convert from the old > format, week by week, but it's worth it -- do it once per presentation, and > that's the end of it. > > The new way really is better (I say this as someone who was horrified six > months ago to find that my old presentations were broken). > > hjh > >
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
Suvayu Ali gmail.com> writes: > I think it is unwise to keep coming up with ways to support semantically > wrong behaviour just for the sake of backwards compatibility. This was > changed with good reason and after a lot of discussions. If you > continue on this path, you will have to keep maintaining this yourself > for all eternity (sorry about the hyperbole :-p). It's a lot of work > for a long time just to avoid some annoying work now. FWIW, I hit this issue about half a year ago, and argued pretty strenuously that breaking backward compatibility was a Terrible Terrible Thing. But, having adapted to the new markup spec, I find it's more logically consistent *and* easier to read while editing. I still have a semester's worth of class slides to convert from the old format, week by week, but it's worth it -- do it once per presentation, and that's the end of it. The new way really is better (I say this as someone who was horrified six months ago to find that my old presentations were broken). hjh
Re: [O] Contributing Without Patches ...
On 9/14/13, Suvayu Ali wrote: > (I took the liberty to re-order the quoting below to clarify my argument.) I found this funny. :) Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Change org-back-to-heading to use org's heading regex
Hi Aditya, I do not support this idea. 1. sometimes Org functions are used in other modes, with a different value for the outline regexp. WHile this will not work for many Org functions, it is useful to have it work for some. 2. For just searching headings, it is efficient to use a regexp that is as simple as possible and does not need to do any back tracking. 3. You can easily use the simple regexps to find a heading. If you need detailed info, match again with looking-at and then use the match data. Regards - Carsten On 14.9.2013, at 23:30, aditya siram wrote: > Hi all, > Org-mode uses two regex's to find headings, one from outline.el and one > defined internally and captures more information. I propose we stop using the > one from outline.el. > > org-mode uses `org-back-to-heading` a lot to navigate point back to the > nearest heading. > > This just delegates to `outline-back-to-heading` from the outline.el package, > which uses a regex for finding headlines: "[*\^L]+" > > Org also defines another heading regex which is more capable and captures > more information: "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$". > > I would propose changing org-back-to-heading to use that so that a user (like > me :) ) can use `match-string` to grab the relevant parts of the string. > > Since this is a pretty simple, but sweeping change, I thought I'd bring it up > here first before patching. > > Thanks! > -deech > > >
Re: [O] Contributing Without Patches ...
On Sat, Sep 14, 2013 at 10:09:42PM +0200, Achim Gratz wrote: > Suvayu Ali writes: (I took the liberty to re-order the quoting below to clarify my argument.) > > Isn't that two commands away: > > > > $ git remote add > > $ git pull > > … and if you are a maintainer, then you'll have hundresds of remotes in > no time. > > > Not solely. It depends on the developer. Here are two random examples > > from a Google search of "lkml pull request". > > These are subsystem maintainers which all have their own public branches > for their staging repositories. That is exactly the thing that pull was > meant for. But isn't this the whole point: Linus pulls from subsystem maintainers, they pull from the group of people they work with; an expanding circle of trust? So in the end no one ends up with hundreds of remotes. > > If you use patches, you do lose committer information. > > You might want to check that assumption. You can do it in many ways, > but by default you don't lose information: the author, the time of > change and the complete commit message is kept. I think you are overlooking that I make a distinction between author and committer. But probably I'm being unnecessarily pedantic; after all that's why git format-patch has --signoff. > > I hear this advise often: rebase before adding features. > > Features are not patches and the other way around. I've been working > with feature branches as well as rebased features before pushing them > out. It depends a lot on what you want to achieve and who you are > working with. There is no single right choice here. In the context of the OP's contributions, you are right. His patches are just patches. My comment to Eric's message was more general, but I admit I wasn't clear in my response. > > But isn't that trying to work in the old ways of linear history. > > There is nothing inherently wrong with linear history. I tend to > rewrite a lot of history when it helps to make the intention of the code > more clear. Me too. > > If there is a need (when working on large features), then there is no > > harm in using separate branches and merging from time to time. If Git > > allows you to, why not take advantage of it. After all that is one of > > the strongest points about Git, it's branching and merging abilities. > > I often find a lot of useful information (about design decisions, > > choices) hidden in the history. > > If that is important to you, by all means do it. But often I think it's > more important to present the code changes in a more coherent fashion > than to stress the fact that I thought of some base functionality only > after I've dithered about on some accidental detail. In particular if > I'm going to send a patch series to a maintainer, I would rather want > him to understand the code to decide if the patch is good or needs more > work. Publishing code is like publishing text: sometimes the notes are > interesting and important, but most often they are not. I guess here the social context of the software project matters. In my most common use case (software implementing physics analysis), I find historical information (e.g. design decisions, physics choices, updated findings, correctness compromises, ...) are equally important to code clarity. So if I can keep historical information, I do. Sometimes I simplify history when it is too messy, but document it in commit messages. (A very OT comment) I came across a few discussions on the Git mailing list where a user wanted to document historical information of a (non-software) project as a Git repository! The particular case I have in mind was to document legal history. What I intend to illustrate with this is: Git history is an amazingly versatile repository of information. Sometimes it is not obvious exactly what it holds. So I go by "keep the info unless you are sure there is no need". Anyway, we have deviated from Org mode way too much. I will shut up now, I mean it this time :-p. Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Change org-back-to-heading to use org's heading regex
Hi all, Org-mode uses two regex's to find headings, one from outline.el and one defined internally and captures more information. I propose we stop using the one from outline.el. org-mode uses `org-back-to-heading` a lot to navigate point back to the nearest heading. This just delegates to `outline-back-to-heading` from the outline.el package, which uses a regex for finding headlines: "[*\^L]+" Org also defines another heading regex which is more capable and captures more information: "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$". I would propose changing org-back-to-heading to use that so that a user (like me :) ) can use `match-string` to grab the relevant parts of the string. Since this is a pretty simple, but sweeping change, I thought I'd bring it up here first before patching. Thanks! -deech
Re: [O] Contributing Without Patches ...
Suvayu Ali writes: > Isn't that two commands away: > > $ git remote add > $ git pull … and if you are a maintainer, then you'll have hundresds of remotes in no time. > If you use patches, you do lose committer information. You might want to check that assumption. You can do it in many ways, but by default you don't lose information: the author, the time of change and the complete commit message is kept. > I hear this advise often: rebase before adding features. Features are not patches and the other way around. I've been working with feature branches as well as rebased features before pushing them out. It depends a lot on what you want to achieve and who you are working with. There is no single right choice here. > But isn't that trying to work in the old ways of linear history. There is nothing inherently wrong with linear history. I tend to rewrite a lot of history when it helps to make the intention of the code more clear. > If there is a need (when working on large features), then there is no > harm in using separate branches and merging from time to time. If Git > allows you to, why not take advantage of it. After all that is one of > the strongest points about Git, it's branching and merging abilities. > I often find a lot of useful information (about design decisions, > choices) hidden in the history. If that is important to you, by all means do it. But often I think it's more important to present the code changes in a more coherent fashion than to stress the fact that I thought of some base functionality only after I've dithered about on some accidental detail. In particular if I'm going to send a patch series to a maintainer, I would rather want him to understand the code to decide if the patch is good or needs more work. Publishing code is like publishing text: sometimes the notes are interesting and important, but most often they are not. > Not solely. It depends on the developer. Here are two random examples > from a Google search of "lkml pull request". These are subsystem maintainers which all have their own public branches for their staging repositories. That is exactly the thing that pull was meant for. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Contributing Without Patches ...
Hi Achim, On Sat, Sep 14, 2013 at 08:12:57PM +0200, Achim Gratz wrote: > Suvayu Ali writes: > > On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote: > >> Pull requests are a github thing, not a git thing. > > > > Well actually I think it is a Git thing. I believe it just says: my > > changes are in the public branch , kindly pull from there; > > eliminating the need to attach patches. As an added advantage, it > > preserves the commit hashes and many other committer/author information. > > That requires that the repository in question is configured as a remote, > so you aren't usually in a position to tell upstream to pull from your > repository (it only ever gets pushed to). The "Github thing" with the > pull request is that you can make a feature branch to any repo and then > ask the maintainer to pull from there, which merges your changes. Isn't that two commands away: $ git remote add $ git pull > There is no author information lost when you send patches as long as > they are created by format-patch. As with any rebase, the history is > thrown away, but that is mostly a good thing for patches. If you use patches, you do lose committer information. I hear this advise often: rebase before adding features. But isn't that trying to work in the old ways of linear history. If there is a need (when working on large features), then there is no harm in using separate branches and merging from time to time. If Git allows you to, why not take advantage of it. After all that is one of the strongest points about Git, it's branching and merging abilities. I often find a lot of useful information (about design decisions, choices) hidden in the history. > > > As far as I have seen, many projects work this way: Linux kernel, Git. > > Linux kernel works via mail, just like Orgmode. Not solely. It depends on the developer. Here are two random examples from a Google search of "lkml pull request". https://lkml.org/lkml/2013/9/4/184 https://lkml.org/lkml/2013/9/5/125 Actually if you read the messages above, the author refers to commit hashes. I think that is an extremely important advantage of a pulling from remote branches over using git am, ensuring commit integrity. Anyway, this discussion is way OT here. So I'll shut up :). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Contributing Without Patches ...
Suvayu Ali writes: > On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote: >> Pull requests are a github thing, not a git thing. > > Well actually I think it is a Git thing. I believe it just says: my > changes are in the public branch , kindly pull from there; > eliminating the need to attach patches. As an added advantage, it > preserves the commit hashes and many other committer/author information. That requires that the repository in question is configured as a remote, so you aren't usually in a position to tell upstream to pull from your repository (it only ever gets pushed to). The "Github thing" with the pull request is that you can make a feature branch to any repo and then ask the maintainer to pull from there, which merges your changes. There is no author information lost when you send patches as long as they are created by format-patch. As with any rebase, the history is thrown away, but that is mostly a good thing for patches. > As far as I have seen, many projects work this way: Linux kernel, Git. Linux kernel works via mail, just like Orgmode. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] error when publishing
Hi,
With org-mode 8.0.7 (emacs 23.4.1), I have some problems to publish a
project.
I have this error : "Publishing file /home/xxx/site/org/index.org using
`org-publish-org-to-html'
find-buffer-visiting: Wrong type argument: stringp, (:base-directory
"~/site/org/" :base-extension "org" :publishing-directory
"~/site/public_html/" :recursive t :publishing-function
org-publish-org-to-html ...)"
I also had once this error : "org-publish-file: Symbol's function
definition is void: org-publish-org-to-html"
I have this code into my .emacs :
-
;; org-mode publishing
(require 'org-publish)
(setq org-publish-project-alist
'(("org-notes"
:base-directory "~/site/org/"
:base-extension "org"
:publishing-directory "~/site/public_html/"
:recursive t
:publishing-function org-publish-org-to-html
:section-numbers nil
:table-of-contents nil
:export-creator-info nil
:export-author-info nil
:auto-preamble t
)
("org-static"
:base-directory "~/site/org/"
:base-extension "css\\|js\\|png\\|jpg\\|pdf\\|mp3\\|ogg"
:publishing-directory "~/site/public_html/"
:recursive t
:publishing-function org-publish-attachment
)
("site" :components ("org-notes" "org-static"
---
Any ideas ?
pw
[O] Amazing demonstration by John Kitchin
Hi, I don't know if this has been linked to before on this mailing list. At SciPy 2013, John Kitchin has made an amazing demonstration of Org-mode as a tool for reproducible research. Really amazing to watch. http://www.youtube.com/watch?v=1-dUkyn_fZA - Carsten
[O] Memacs: Twitter module added (was: tweets2org.py: Update to v0.2)
* Karl Voit wrote: > > Now tweets2org.py is working flawlessly on my Twitter export > data-set and converts it to Org-mode format for my Memacs[2]. By coincidence a brand-new twitter module was added to Memacs[2] today as well. Many thanks to Ian Barton for this module which is using the Twitter API to get tweets. Summary: If you want to use the official (manual) Twitter download archive, feel free to use the tweets2org[1]. If you want to use the Twitter API to get to a local copy of your tweets in time, please do use the Twitter module from Memacs[2]. 1. https://github.com/novoid/twitter-json_to_orgmode 2. https://github.com/novoid/Memacs -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Contributing Without Patches ...
On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote: > > > Is there some way for me to issue a pull-request? > > > > Pull requests are a github thing, not a git thing. Well actually I think it is a Git thing. I believe it just says: my changes are in the public branch , kindly pull from there; eliminating the need to attach patches. As an added advantage, it preserves the commit hashes and many other committer/author information. As far as I have seen, many projects work this way: Linux kernel, Git. Github just provides a convenient web-interface for this, don't you think? -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote: > Hello, > > Carsten Dominik writes: > > > When the functions are done, please go ahead and commit them and bind > > them to C-up/down. > > Done. Do you think it would be nicer if org-forward-paragraph takes arguments like forward-paragraph? Would be more consistent, specially if someone writes wrappers (confession: I'm actually writing one myself). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Jumping from source block to Org block ...
I've included new versions of both patches with most of the changes you suggested. I guess you'll apply the longer one when you've been notified by the FSF? Is this a one-time deal that covers future patches or do I have to do this with every patch that's over 15 lines long? Thanks! -deech On Sat, Sep 14, 2013 at 10:53 AM, aditya siram wrote: > Thanks for your feedback and your work on org-babel! > > Oops, the maintain-point was a hold-over and isn't actually used in the > code. I'll remove it. > > I will incorporate your suggestions. > > However, regarding the cascading if statements, how would I use `cond` > when the predicates are `and`ed and when I need different behavior in the > else cases? > > > On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte wrote: > >> aditya siram writes: >> >> > Attached is a patch that fixes a bug with jumping from source block >> back to >> > the Org file. The problem is that the current detangling behavior does >> not >> > take the :padlline flag into account. This stopped. >> > >> > Hopefully this is helpful to others ... >> > -deech >> > >> >> Hi deech, >> >> Please see the Org-mode contribution instructions at [1]. A patch of >> this length would require that you fill out the FSF copyright assignment >> paperwork before the patch could be applied. >> >> As for the content of the patch, my only question is why do you add an >> optional maintain-point argument to `org-babel-tangle-jump-to-org'? Is >> there ever a case when you would not want to maintain the point? >> >> Of much less importance I have a couple of stylistic notes about the >> code which are largely unrelated to its functionality and are included >> to make future changes easier to read and because I'm a cranky old lisp >> programmer. >> >> - you should indent the code s.t. no lines are longer than 79 characters >> - comments which float after code (e.g., ";; end of first delimiter") >> should only use 1 ; character >> - the series of if statements (if should-be-padded... if >> possibly-padded... if actually-padded...) would be more legible if >> written as a single `cond' form. >> >> Thanks for this change. It appears to pass all tests, so after the >> above have been addressed I'd be very happy to apply it. >> >> Thanks for contributing, this is much appreciated! >> >> If you have the time and inclination to include a test which fails >> without this patch applied that would be icing on the cake. >> >> Best, >> >> Footnotes: >> [1] http://orgmode.org/worg/org-contribute.html >> >> -- >> Eric Schulte >> https://cs.unm.edu/~eschulte >> PGP: 0x614CA05D >> > > From 791a41a9cb97ae9a237b74c839a1fc2c0f4970db Mon Sep 17 00:00:00 2001 From: Aditya Siram Date: Sat, 14 Sep 2013 11:47:17 -0500 Subject: [PATCH 2/2] Detangling and jumping back now correctly compensate for padded chunks --- lisp/ob-tangle.el | 102 +++--- 1 file changed, 97 insertions(+), 5 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 8141943..42fa31c 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -506,8 +506,8 @@ which enable the original code blocks to be found." "Jump from a tangled code file to the related Org-mode file." (interactive) (let ((mid (point)) - start body-start end done -target-buffer target-char link path block-name body) + start body-start end done depadded-body +target-buffer offset target-char link path block-name body) (save-window-excursion (save-excursion (while (and (re-search-backward org-bracket-link-analytic-regexp nil t) @@ -526,7 +526,7 @@ which enable the original code blocks to be found." (setq end (point-at-bol (unless (and start (< start mid) (< mid end)) (error "Not in tangled code")) -(setq body (org-babel-trim (buffer-substring start end +(setq body (buffer-substring start end))) (when (string-match "::" path) (setq path (substring path 0 (match-beginning 0 (find-file path) (setq target-buffer (current-buffer)) @@ -537,12 +537,18 @@ which enable the original code blocks to be found." (org-babel-goto-named-src-block block-name)) ;; position at the beginning of the code block body (goto-char (org-babel-where-is-src-block-head)) + (let* ((pad-adjusted-values + (org-babel-detangle-adjust-for-padlines start mid body)) +(depadded-body (car pad-adjusted-values)) +(depadded-point (cdr pad-adjusted-values))) + (progn + (setq offset depadded-point) + (setq body depadded-body))) (forward-line 1) - ;; Use org-edit-special to isolate the code. (org-edit-special) ;; Then move forward the correct number of characters in the ;; code buffer. - (forward-char (- mid body-start)) + (forward-char offset) ;; And return to the Org-mode buffer with the
[O] no fontification of #+BEGIN_LaTeX blocks
org-src-fontify-natively doesn't fontify quoted LaTeX code like #+BEGIN_LaTeX #+END_LaTeX the same as it does for LaTeX src blocks like #+BEGIN_SRC latex #+END_SRC Why is that, and is there a way to get fontification for both ? Julien.
Re: [O] Jumping from source block to Org block ...
Thanks for your feedback and your work on org-babel! Oops, the maintain-point was a hold-over and isn't actually used in the code. I'll remove it. I will incorporate your suggestions. However, regarding the cascading if statements, how would I use `cond` when the predicates are `and`ed and when I need different behavior in the else cases? On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte wrote: > aditya siram writes: > > > Attached is a patch that fixes a bug with jumping from source block back > to > > the Org file. The problem is that the current detangling behavior does > not > > take the :padlline flag into account. This stopped. > > > > Hopefully this is helpful to others ... > > -deech > > > > Hi deech, > > Please see the Org-mode contribution instructions at [1]. A patch of > this length would require that you fill out the FSF copyright assignment > paperwork before the patch could be applied. > > As for the content of the patch, my only question is why do you add an > optional maintain-point argument to `org-babel-tangle-jump-to-org'? Is > there ever a case when you would not want to maintain the point? > > Of much less importance I have a couple of stylistic notes about the > code which are largely unrelated to its functionality and are included > to make future changes easier to read and because I'm a cranky old lisp > programmer. > > - you should indent the code s.t. no lines are longer than 79 characters > - comments which float after code (e.g., ";; end of first delimiter") > should only use 1 ; character > - the series of if statements (if should-be-padded... if > possibly-padded... if actually-padded...) would be more legible if > written as a single `cond' form. > > Thanks for this change. It appears to pass all tests, so after the > above have been addressed I'd be very happy to apply it. > > Thanks for contributing, this is much appreciated! > > If you have the time and inclination to include a test which fails > without this patch applied that would be icing on the cake. > > Best, > > Footnotes: > [1] http://orgmode.org/worg/org-contribute.html > > -- > Eric Schulte > https://cs.unm.edu/~eschulte > PGP: 0x614CA05D >
Re: [O] Jumping from source block to Org block ...
aditya siram writes: > Attached is a patch that fixes a bug with jumping from source block back to > the Org file. The problem is that the current detangling behavior does not > take the :padlline flag into account. This stopped. > > Hopefully this is helpful to others ... > -deech > Hi deech, Please see the Org-mode contribution instructions at [1]. A patch of this length would require that you fill out the FSF copyright assignment paperwork before the patch could be applied. As for the content of the patch, my only question is why do you add an optional maintain-point argument to `org-babel-tangle-jump-to-org'? Is there ever a case when you would not want to maintain the point? Of much less importance I have a couple of stylistic notes about the code which are largely unrelated to its functionality and are included to make future changes easier to read and because I'm a cranky old lisp programmer. - you should indent the code s.t. no lines are longer than 79 characters - comments which float after code (e.g., ";; end of first delimiter") should only use 1 ; character - the series of if statements (if should-be-padded... if possibly-padded... if actually-padded...) would be more legible if written as a single `cond' form. Thanks for this change. It appears to pass all tests, so after the above have been addressed I'd be very happy to apply it. Thanks for contributing, this is much appreciated! If you have the time and inclination to include a test which fails without this patch applied that would be icing on the cake. Best, Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Contributing Without Patches ...
aditya siram writes: > Hi all > I've made a couple of changes to the latest source tree but I can't seem to > create patches because of some merges that happened subsequently. First you'll need to rebase [1] your changes over the current head of the git repository, then you can generate patches with git format-patch and send those patches to the list. The git-scm site below is a great resource for using git. See also [2] for Org-mode specific contribution information. > Is there some way for me to issue a pull-request? > Pull requests are a github thing, not a git thing. > > -deech Cheers, Footnotes: [1] http://git-scm.com/book/en/Git-Branching-Rebasing [2] http://orgmode.org/worg/org-contribute.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [Babel] Parsing source block bug ...
Thanks for this patch! I've just applied it. For future patches it is good form to keep the first line of the commit message <= 50 characters long (used to summarize the patch), the second line should be blank, and all subsequent lines should be <=70 characters long. Thanks again. aditya siram writes: > Hi all, > This patch fixes a bug where the regexp for parsing source blocks is too > greedy on the body and so fails in the presence of empty code blocks. For > instance given the following: > > #+begin_src c > #+end_src > #+begin_src c > hello world > #+end_src > > , doing (org-babel-get-src-block-info) the first #+begin_src will include > everything up to the second #+end_src as part of the body. > -deech > -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
Hi Christoph and John,
I'll take an extreme view here. So apologies in advance.
On Sat, Sep 14, 2013 at 09:40:50AM -0500, John Hendy wrote:
> On Sat, Sep 14, 2013 at 9:28 AM, Christoph LANGE
> wrote:
> > Dear all,
> >
> > here is another problem that I have with reusing old Beamer
> > presentations (Org version 7) with the new exporter.
> >
> > The manual says that "all frame's children become `block' environments".
> >
> > Is there a way of reverting to the default behaviour of the old
> > exporter, which by default exported frame's children as list items?
> > E.g. by setting a certain property on the frame's children?
> >
>
> Tricky problem, and I could see how this would be an issue. I guess I
> always held to using unordered lists (- blah) for my lists vs. relying
> on the nested headling functionality (** blah). I wonder if you could
> tweak the beamer definition somehow to make a sort of "legacy beamer"
> class for exporting these?
I think it is unwise to keep coming up with ways to support semantically
wrong behaviour just for the sake of backwards compatibility. This was
changed with good reason and after a lot of discussions. If you
continue on this path, you will have to keep maintaining this yourself
for all eternity (sorry about the hyperbole :-p). It's a lot of work
for a long time just to avoid some annoying work now.
> For example, I have the default template in my .emacs from the Beamer
> setup instructions on Worg:
>
> #+begin_src .emacs
>
> (add-to-list 'org-latex-classes
> '("beamer"
>"\\documentclass\[presentation\]\{beamer\}"
>("\\section\{%s\}" . "\\section*\{%s\}")
>("\\subsection\{%s\}" . "\\subsection*\{%s\}")
>("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
>
>
> #+end_src
>
> Perhaps something there could be tweaked? I'm no lisp or org -> latex
> mapping person, but perhaps others will have an idea of how you can
> map something dynamically so that "One level below the H:number
> setting gets converted to \itemize" (vs. the current conversion to
> \begin{example} ?
I think the answer is in your response; the template is for headlines up
to a depth n as specified by H:n. The old (and new) behaviour was (is)
for all headlines deeper than n (n+1 and onwards). This is
core-functionality, not something that is configurable.
That said, I think converting headlines to lists is not difficult. You
should be able to define a keyboard macro to semi-automate it. You can
mark a headline, C-c @, followed by C-c - to convert to a list.
Actually, I think it should be possible to write a custom function to
traverse a buffer and convert all headlines deeper than n to lists using
these same functions.
How about a combination of org-map-entries with a custom function which
does something like this (semi-pseudo-code):
(lambda nil
(if (> depth 3) ; assuming n=3 in H:n
(progn
(org-mark-subtree)
(org-ctrl-c-minus
I think you can get depth with something like this:
(car (org-heading-components))
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
[O] [PATCH 1/1] Fix typo 'org-ctags-create-tags in comment
--- Fix a minor typo. lisp/org-ctags.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el index 98d47e5..9d8ed6c 100644 --- a/lisp/org-ctags.el +++ b/lisp/org-ctags.el @@ -131,7 +131,7 @@ ;; ;; (progn ;; (message "-- rebuilding tags tables...") -;; (mapc 'org-create-tags tags-table-list)) +;; (mapc 'org-ctags-create-tags tags-table-list)) ;;; Code: -- 1.8.4.rc3
[O] [export] Beamer frames containing lstlisting are no longer made fragile
Dear all, having created a number of Beamer presentations with the old exporter (Org version 7), I'm now working on the first Beamer presentation with the new exporter. Frames that contain an lstlisting environment are no longer made fragile automatically. (Thus I'm not sure the documentation in manual section 12.5 "Beamer export" is still correct, which says "`fragile' option is added automatically if it contains source code that uses any verbatim environment".) My intuition after browsing the Org source code and documentation is that I should now use #+BEGIN_SRC and that then everything will be handled automatically. However the language of my listings is a non-standard one, which requires a lot of custom options to the lstlisting environment. Could anyone kindly point me to an example? Cheers, and thanks in advance, Christoph -- Christoph Lange-Bever, http://www.facebook.com/ch.lange, Skype duke4701
Re: [O] Remove Org and Tbl from menubar for derived mode
Christian Wittern writes: > I am developing a mode derived from org for special editing and > browsing purposes. I will add my own menu to the menubar and would > like to remove the menus added by org, "Org" and "Tbl", in order not > to confuse my users Try this (add-hook 'org-mode-hook (lambda nil (local-unset-key [menu-bar Org])))
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou writes:
>> Should there be a pit-stop at #+END in the segment below.
> You can use `org-forward-element' to go there.
It makes no difference if I use `org-forward-element' or
`org-forward-linear-element'. The reason is clear if one examines the
parser output.
#+BEGIN and #+END are considered NOT as a pair but as standalone
paragraphs.
(paragraph
()
#("#+BEGIN RECEIVE ORGTBL exdoc\n" 0 29
()))
(paragraph
()
#("#+END RECEIVE ORGTBL exdoc\n" 0 27
()))
I just picked up a random worg file to take a real-world test drive.
Speaking of expectations, cursor's stop points within #+BEGIN_BACKEND
and #+END_BACKEND are decided based on whether the respective backend is
loaded. So is the case with inlinetasks.
I am just making a note of behaviour that is surprising. Surprising
only if the underlying mechanics aren't sufficiently understood or
known.
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
On Sat, Sep 14, 2013 at 9:28 AM, Christoph LANGE
wrote:
> Dear all,
>
> here is another problem that I have with reusing old Beamer
> presentations (Org version 7) with the new exporter.
>
> The manual says that "all frame's children become `block' environments".
>
> Is there a way of reverting to the default behaviour of the old
> exporter, which by default exported frame's children as list items?
> E.g. by setting a certain property on the frame's children?
>
Tricky problem, and I could see how this would be an issue. I guess I
always held to using unordered lists (- blah) for my lists vs. relying
on the nested headling functionality (** blah). I wonder if you could
tweak the beamer definition somehow to make a sort of "legacy beamer"
class for exporting these?
For example, I have the default template in my .emacs from the Beamer
setup instructions on Worg:
#+begin_src .emacs
(add-to-list 'org-latex-classes
'("beamer"
"\\documentclass\[presentation\]\{beamer\}"
("\\section\{%s\}" . "\\section*\{%s\}")
("\\subsection\{%s\}" . "\\subsection*\{%s\}")
("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
#+end_src
Perhaps something there could be tweaked? I'm no lisp or org -> latex
mapping person, but perhaps others will have an idea of how you can
map something dynamically so that "One level below the H:number
setting gets converted to \itemize" (vs. the current conversion to
\begin{example} ?
Just a thought.
Sorry to not be more help to you!
John
> Of course I would be able to manually change all lists to plain lists
> within Org tree entries, but before starting to do this I would like to
> make sure that there is no other way.
>
> Cheers, and thanks in advance,
>
> Christoph
>
> --
> Christoph Lange, School of Computer Science, University of Birmingham
> http://cs.bham.ac.uk/~langec/, Skype duke4701
>
> → Mathematics in Computer Science Special Issue on “Enabling Domain
> Experts to use Formalised Reasoning”; submission until 31 October.
> http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
>
Re: [O] need help with complicated idea>send/export org header+content to email/other (for cooking in kitchen :) )
Xebar Saram writes: > Hi all and sorry about the complicated topic :) > > among the many many many things i use org for is to collect cooking recipes > :) > > i have zero coding knowledge and my emacs understanding is limited :) > > what i basically wanted to ask is if anyone could show me a simple function > (at least it seems like it should be simple ;-) to allow me to stand on a > org heading (a single recipe) press a hotkey/issue a command and then have > that header+content exported to pdf/html and emailed to a specific address > so i can view it on my android tablet in kitchen while i cook :) > is it to crazy? You haven't said what version of org you are using. Assuming you are up to date, i.e. version 8, you can export a subtree to PDF by M-x org-export-dispatch RET C-s l p you can then send the PDF to yourself however you wish. Alternatively, if you use Emacs to send your emails, i.e. with message-mode, the following two commands will do the job nicely, sending an HTML message (not my choice normally): M-x org-mime-subtree RET M-x org-mime-htmlize RET C-c C-c HTH, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.1.1-17-gf76e8c
Re: [O] [export] Beamer frames containing lstlisting are no longer made fragile
Hello,
Christoph LANGE writes:
> Still I think the following sentence in the documentation (section 12.5)
> is easy to misunderstand:
>
> "`fragile' option is added automatically if it contains source code that
> uses any verbatim environment".
What would you suggest instead?
> I think it means that when I use a proper "source block" using
> #+BEGIN_SRC, the exporter automatically sets the [fragile] option as
> needed.
It isn't just about source blocks, see `org-beamer-verbatim-elements'.
> Anyway, you told me how to make my legacy {lstlisting} environments
> work. Is this approach, of manually setting "BEAMER_OPT: fragile" the
> preferred way whenever you have a listing in a non-standard language,
> where the {lstlisting} environment requires special arguments (e.g.
> "morekeywords")? Or is there some way of passing extra arguments into
> the {lstlisting} environment that is created from #+BEGIN_SRC?
At the moment, the only way to pass extra arguments to lstlisting is
using `org-latex-listings-options'. IOW, it isn't possible to set
specific options for a given block.
Though, it should be fairly easy to implement an :extra attribute for
source blocks. E.g.,
#+attr_latex: :extra key1=val1,key2=val2
#+begin_src
...
#+end_src
Regards,
--
Nicolas Goaziou
Re: [O] removing "Figure x" from a caption
Matt Price writes: > Unfortunatey, I'm exporting to HTML (deck.js) not Beamer. I guess I > still on't understand how to use beamer -- I tried it just now and it > seemed to produce a very plain pdf, not a slideshow at all. sigh. It may or may not have worked. I cannot tell from your comment. It depends on what you mean by "plain PDF" and "slideshow". Beamer is a document style and a collection of macros for LaTeX. The output of LaTeX will be a PDF file typically. For a beamer document, the PDF output is a set of pages where each page corresponds to a single "slide". The slide show is the sequence of these PDF pages. Whether this corresponds to your meaning of a slide show, I cannot tell. I hope that makes some sort of sense... -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.1.1-17-gf76e8c
[O] [export] Easy way to make children of Beamer frames generate list items?
Dear all, here is another problem that I have with reusing old Beamer presentations (Org version 7) with the new exporter. The manual says that "all frame's children become `block' environments". Is there a way of reverting to the default behaviour of the old exporter, which by default exported frame's children as list items? E.g. by setting a certain property on the frame's children? Of course I would be able to manually change all lists to plain lists within Org tree entries, but before starting to do this I would like to make sure that there is no other way. Cheers, and thanks in advance, Christoph -- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701 → Mathematics in Computer Science Special Issue on “Enabling Domain Experts to use Formalised Reasoning”; submission until 31 October. http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
Re: [O] Contributing Without Patches ...
On Sat, Sep 14, 2013 at 08:14:36AM -0500, aditya siram wrote: > I believe I may have fixed the problem. I submitted two patches yesterday. > Hopefully they're formatted ok. I tried applying them, seemed to go fine. Note: I did not review the patches. A small pointer: I'm guessing you are using the Gmail web-interface. In the future you might want to rename the files to something .txt; say, src_block_regexp_fix_patch.txt. It's one of those weird things Gmail does, it sets the MIME type based on extensions. Without the trailing .txt they are encoded as application/octet-stream! Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [export] Beamer frames containing lstlisting are no longer made fragile
Hi Nicolas,
2013-09-13 17:32 Nicolas Goaziou:
> If you're inserting the environment manually, Beamer export back-end
> will not be able to detect that a "fragile" option is required. In that
> case, you can also insert that option manually, by setting BEAMER_OPT
> property to fragile in the headline representing your frame:
>
> * My frame
> :PROPERTIES:
> :BEAMER_OPT: fragile
> :END:
Thanks, that works – indeed I should have tried this first, as the
documentation actually mentions it.
Still I think the following sentence in the documentation (section 12.5)
is easy to misunderstand:
"`fragile' option is added automatically if it contains source code that
uses any verbatim environment".
I think it means that when I use a proper "source block" using
#+BEGIN_SRC, the exporter automatically sets the [fragile] option as
needed. However the sentence could also be interpreted as reflecting
the behaviour of the old exporter, which indeed scanned the full _LaTeX_
source code (e.g. in #+BEGIN_LaTeX) for certain environments and then
set the [fragile] option.
Anyway, you told me how to make my legacy {lstlisting} environments
work. Is this approach, of manually setting "BEAMER_OPT: fragile" the
preferred way whenever you have a listing in a non-standard language,
where the {lstlisting} environment requires special arguments (e.g.
"morekeywords")? Or is there some way of passing extra arguments into
the {lstlisting} environment that is created from #+BEGIN_SRC?
Cheers, and thanks in advance,
Christoph
--
Christoph Lange, School of Computer Science, University of Birmingham
http://cs.bham.ac.uk/~langec/, Skype duke4701
→ Mathematics in Computer Science Special Issue on “Enabling Domain
Experts to use Formalised Reasoning”; submission until 31 October.
http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
Re: [O] Link with spaces does not export properly in html
Nicolas Goaziou gmail.com> writes: > > This was fixed in 8.1 release. You need to update Org. > > Regards, > Hi, updated to 8.1, but problem persists, does anyone know a way to solve this? Thanks, Simon.
Re: [O] Contributing Without Patches ...
I believe I may have fixed the problem. I submitted two patches yesterday. Hopefully they're formatted ok. -deech On Fri, Sep 13, 2013 at 7:27 PM, Suvayu Ali wrote: > Hello Aditya, > > On Fri, Sep 13, 2013 at 06:42:13PM -0500, aditya siram wrote: > > Hi all > > I've made a couple of changes to the latest source tree but I can't seem > to > > create patches because of some merges that happened subsequently. Is > there > > some way for me to issue a pull-request? > > What problems are you having? A little more details would help us help > you. > > -- > Suvayu > > Open source is the future. It sets us free. > >
[O] tweets2org.py: Update to v0.2
Hi! I just wanted to post a quick reminder that I finally found time to debug the issue that caused tweets2org.py [1] to stop working: Twitter changed their time-stamp format in the JSON files. I very much do hate changing standards :-) Now tweets2org.py is working flawlessly on my Twitter export data-set and converts it to Org-mode format for my Memacs[2]. HTH 1. https://github.com/novoid/twitter-json_to_orgmode 2. https://github.com/novoid/Memacs -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
[O] One more question about org-element parse-tree
Hi List, Hi Nicolas, I (still) have a question about the parser and the yielded parse-tree: - Circular List :: used for - headline hierarchies (:parent attribute) - plain-lists/items (:structure attribute) - :CATEGORY attribute - [somewhere else too??] w.r.t. the :CATEGORY attribute: Is this :CATEGORY attribute special somehow? When it is not set explicitly, it seems to be set automatically as non-directory part of the org-file name (sans-extension) in the first first-level headline and then referenced (via the circular list mechanism) in the other first-level headlines. Are there other cases like this where attribute values are tagged and reused? PS 1 [BUG?] I use outorg to write my emails in full Org-mode, and the strange indentation you see above results from applying `fill-region' on paragraphs (that are part of a list item) while writing this post. Bug or wrong use? Org Version too old? (Org-mode version 8.0.6 (release_8.0.6-341-g338603) PS 2 BTW, does a MWE org-file exist that contains _all_ syntactical elements of Org-mode and thus serves as a test-file for all cases? -- cheers, Thorsten
