Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
Hi Eric, > I personally don't have time to make these changes right now, but I'd be > happy to provide guidance and answer questions to anyone who wanted to > try to submit a patch. Also, there are a number of files which can > serve as examples of how to compile and execute code with Babel e.g., > ob-java.el and ob-C.el. That's what I suspected judging from the behaviour I've seen. Is anyone else interested in such work? I don't have much time either, in particular I'm not sufficiently familiar with emacs and Lisp to do something useful quickly. > I would prefer to keep haskell as the source block type if only so that > the blocks are fontified with haskell-mode. However something like an > :engine or :compiler keyword could be used to specify ghc or hugs. Good idea, but specifying ghc is ambiguous: it'll have to be either ghci, runghc/runhaskell, oder hugs, or maybe some other interpreter/compiler someone else would like to use (nhc98, etc., there a quite a few). At least the three options I listed all have incompatibilities in even the simplest use cases, owing to the peculiarities of Haskell as a pure, declarative language. Also, using runghc would require the code block to be tangled first into a temporary file. Is that easily done in babel? András
[O] talk about org-mode
Hi, is anyone interested in giving a blistering talk about org-mode at the Snow headquarters in the Netherlands (the town of Geldermalsen)? Our original plan to have someone talk about hacking DECT and other protocols had to be postponed. The public consists of about 80 Unix and Security Specialists. The date is September 1st. Regards, Joost Helberg -- Snow B.V.http://snow.nl
Re: [O] indenting nested TODOs in agenda views
On Mon, Aug 22 2011, Sebastien Vauban wrote: > Hi Eric, > > Eric Abrahamsen wrote: >> On Mon, Aug 22 2011, Bernt Hansen wrote: >> >>> Eric Abrahamsen writes: >>> What would it take to get an Agenda tags view that indented nested TODOs? I've always been bothered by the fact that nested TODOs within a subtree are all flattened for the agenda view, so sometimes it's hard to tell that several TODOs all belong to one "bigger" TODO. I guess it would have to go in `org-finalize-agenda-entries', after the filter function is run, and somehow instead of the way org entries are currently fed to the sorting function. Would this be a desirable option? >>> >>> Set >>> >>> (org-tags-match-list-sublevels 'indented) >>> >>> in your agenda view. >> >> That's pretty interesting, but not quite what I meant: I was thinking >> that TODOs would be first sorted by outline level, and then only TODOs >> that belonged to a subtree with "higher" TODOs would be indented. With >> "indented", a second-level TODO can come after a first-level TODO and >> appear to be subordinate to it, though they belong to completely >> different subtrees. >> >> But stating the problem this way makes me realize it's more complicated >> than I thought… > > Just an incentive to tell you I'd also would love that feature. > > Best regards, > Seb I'm going to have a whack at this, will probably take me a week or more… E
[O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi,
here is an example that delivers an error "reference 'table1' not
found in this buffer" when trying to export to HTML (others not tried
yet):
#+tblname: table1 :noexport:
| n | x | y1 | y2 |
|---+---+-+--|
| 0 | 1 | 2.0 | 3.0 |
| 1 | 2 | 2.1 | 2.0 |
| 2 | 3 | 2.0 | 0.3 |
| 3 | 4 | 1.0 | 0.6 |
| 4 | 5 | 1.4 | -0.1 |
| 5 | 6 | 1.6 | 1.2 |
#+begin_src gnuplot :file bug_gnuplot.png :var t=table1
set size square
plot t u 2:3 w lp, t u 2:4 w lp
#+end_src
If I remove the :noexport: tag, everything works fine.
Am I doing something wrong here? I don't think that :noexport: should
affect the use of the table for other purposes.
András
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
of 2010-12-11 on raven, modified by Debian
Package: Org-mode version 7.7 (release_7.7.167.gfceb)
current state:
==
(setq
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t)
(gnuplot . t) (haskell . t) (latex . t)
(octave . t) (R . t) (ruby . t) (scheme . t) (sh .
t))
org-metaup-hook '(org-babel-load-in-session-maybe)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex")
("haskell" . "hs") ("asymptote" . "asy")
("emacs-lisp" . "el"))
org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
org-export-latex-format-toc-function 'org-export-latex-format-toc-default
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-blank-before-new-entry nil
org-babel-pre-tangle-hook '(save-buffer)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-export-preprocess-before-normalizing-links-hook
'(org-remove-file-link-modifiers)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append local] 5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all
append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src
org-babel-exp-inline-src-blocks))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-occur-hook '(org-first-headline-recenter)
org-from-is-user-regexp nil
org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
org-confirm-babel-evaluate nil
org-export-latex-final-hook '(org-beamer-amend-header
org-beamer-fix-toc org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-blocks '((src org-babel-exp-src-block nil) (comment
org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil) (dot
org-export-blocks-format-dot nil))
)
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András & al., András Major wrote: > here is an example that delivers an error "reference 'table1' not > found in this buffer" when trying to export to HTML (others not tried > yet): > > #+tblname: table1 :noexport: > | n | x | y1 | y2 | > |---+---+-+--| > | 0 | 1 | 2.0 | 3.0 | > | 1 | 2 | 2.1 | 2.0 | > | 2 | 3 | 2.0 | 0.3 | > | 3 | 4 | 1.0 | 0.6 | > | 4 | 5 | 1.4 | -0.1 | > | 5 | 6 | 1.6 | 1.2 | > > #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 > set size square > plot t u 2:3 w lp, t u 2:4 w lp > #+end_src > > If I remove the :noexport: tag, everything works fine. > > Am I doing something wrong here? I don't think that :noexport: should > affect the use of the table for other purposes. I will let answer the ones who decide on such things. Though, I am amazed you put a tag on the table itself. I'd have expected the noexport tag to be on a section containing the table. So, my extra question (to the same persons) is: is this an allowed use of a tag? Or just an undocumented feature which temporarily works? -- euh, or not even works, in fact... Best regards, Seb -- Sebastien Vauban
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Sebastian, > I will let answer the ones who decide on such things. Though, I am amazed you > put a tag on the table itself. > > I'd have expected the noexport tag to be on a section containing the table. I forgot to mention in the report that of course I tried that too: if I place the table and the code in two sections and tag the section containing the table with :noexport:, the result is exactly the same. Omitting the tag makes it work again. > So, my extra question (to the same persons) is: is this an allowed use of a > tag? Or just an undocumented feature which temporarily works? -- euh, or not > even works, in fact... In my little experience, it work, and I think it's a desirable feature too. I'm not really keen on creating a section for a table just so that I can hide it. András
[O] Bug: named columns in tables not working if name contains "_"
Hi, Yet another one I just stumbled across: if I create a table and use "!" in the first column to assign names to the columns, I can only reference those columns by name in #+TBLFM: if the names don't contain a "_" character. This isn't mentioned in the docs and shouldn't be so, IMHO. I haven't checked for other common characters that are prohibited, but the "_" bites me quite a bit. András
Re: [O] Bug: named columns in tables not working if name contains "_"
András Major wrote: > Yet another one I just stumbled across: if I create a table and use > "!" in the first column to assign names to the columns, I can only > reference those columns by name in #+TBLFM: if the names don't contain > a "_" character. This isn't mentioned in the docs and shouldn't be > so, IMHO. I haven't checked for other common characters that are > prohibited, but the "_" bites me quite a bit. > Try adding an underscore to the regexp on line 2179 of org-table.el - something like this (untested): ... (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name) (push (cons name (int-to-string cnt)) org-table-column-names The only characters permitted are alphanumerics. That can probably be easily relaxed. Nick
Re: [O] Bug: named columns in tables not working if name contains
> Try adding an underscore to the regexp on line 2179 of org-table.el - > something like this (untested): > > ... > (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name) > (push (cons name (int-to-string cnt)) org-table-column-names > > The only characters permitted are alphanumerics. That can probably be > easily relaxed. Thanks Nick. It would be nice if the documentation reflected such an arbitrary choice of characters you can use... András
Re: [O] Bug: named columns in tables not working if name contains "_"
On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote: > András Major wrote: > > >> Yet another one I just stumbled across: if I create a table and use >> "!" in the first column to assign names to the columns, I can only >> reference those columns by name in #+TBLFM: if the names don't contain >> a "_" character. This isn't mentioned in the docs and shouldn't be >> so, IMHO. I haven't checked for other common characters that are >> prohibited, but the "_" bites me quite a bit. >> > > Try adding an underscore to the regexp on line 2179 of org-table.el - > something like this (untested): > > ... > (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name) > (push (cons name (int-to-string cnt)) org-table-column-names > > > The only characters permitted are alphanumerics. That can probably be > easily relaxed. Hi Nick, I don't think it can be easily relaxed. Many other characters are operators in Calc and would lead to confusion. But amending the docs is certainly a good idea. Thanks - Carsten
Re: [O] Bug: named columns in tables not working if name contains "_"
Carsten Dominik wrote:
>
> On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote:
>
> > András Major wrote:
> >
> >
> >> Yet another one I just stumbled across: if I create a table and use
> >> "!" in the first column to assign names to the columns, I can only
> >> reference those columns by name in #+TBLFM: if the names don't contain
> >> a "_" character. This isn't mentioned in the docs and shouldn't be
> >> so, IMHO. I haven't checked for other common characters that are
> >> prohibited, but the "_" bites me quite a bit.
> >>
> >
> > Try adding an underscore to the regexp on line 2179 of org-table.el -
> > something like this (untested):
> >
> > ...
> > (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name)
> > (push (cons name (int-to-string cnt)) org-table-column-names
> >
> >
> > The only characters permitted are alphanumerics. That can probably be
> > easily relaxed.
>
> Hi Nick, I don't think it can be easily relaxed. Many other characters are
> operators in Calc and would lead to confusion.
>
So add more syntax: formulas can use {this+is-a*/strange\@name}.
OK, ok - just kidding.
Thanks,
Nick
PS. This is a paraphrase of the indirection principle: Any problem can
be solved by adding yet another layer of syntax...
[O] [odt] equation labels
Hello,
I am using the excellent org-odt, so thanks to Jambunathan K, and
everyone who has ever contributed to orgmode.
This may be quite simple so I am asking before making an minimal
example. Does anyone know how to cause a label such as "Figure 1." in
the odt (for the resulting png), and set the caption for an equation
such as:
#+CAPTION: some caption
#+LABEL: eqn:psychrometric
\begin{equation*}
\label{eq:psychrometric}
\capillaryPressure = ln(RH)\cdot \dens_w\frac{RT}{M_w}
\end{equation*}
?
The orgmode manual says that captions and labels are for images and
tables so unless there is a special trick I would probably try to wrap
the latex in something first, for dvipng to return the png to org, to
apply the CAPTION to, before exporting to odt.
Extra points for making it "Equation 1." instead of "Figure 1.".
Thanks,
Myles
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major writes:
> Hi,
>
> here is an example that delivers an error "reference 'table1' not
> found in this buffer" when trying to export to HTML (others not tried
> yet):
>
> #+tblname: table1 :noexport:
> | n | x | y1 | y2 |
> |---+---+-+--|
> | 0 | 1 | 2.0 | 3.0 |
> | 1 | 2 | 2.1 | 2.0 |
> | 2 | 3 | 2.0 | 0.3 |
> | 3 | 4 | 1.0 | 0.6 |
> | 4 | 5 | 1.4 | -0.1 |
> | 5 | 6 | 1.6 | 1.2 |
>
> #+begin_src gnuplot :file bug_gnuplot.png :var t=table1
> set size square
> plot t u 2:3 w lp, t u 2:4 w lp
> #+end_src
>
> If I remove the :noexport: tag, everything works fine.
>
> Am I doing something wrong here? I don't think that :noexport: should
> affect the use of the table for other purposes.
>
This is the first time I've seen a tag applied to a table. I've updated
the results regular expression so that it will now admit examples like
yours above. Please let me know if this doesn't work with the latest
Org-mode.
Best -- Eric
>
> András
>
>
>
>
>
> Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
> of 2010-12-11 on raven, modified by Debian
> Package: Org-mode version 7.7 (release_7.7.167.gfceb)
>
> current state:
> ==
> (setq
> org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
> org-speed-command-hook '(org-speed-command-default-hook
> org-babel-speed-command-hook)
> org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t)
> (gnuplot . t) (haskell . t) (latex . t)
> (octave . t) (R . t) (ruby . t) (scheme . t) (sh .
> t))
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-after-todo-state-change-hook '(org-clock-out-if-current)
> org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex")
> ("haskell" . "hs") ("asymptote" . "asy")
> ("emacs-lisp" . "el"))
> org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
> org-export-latex-format-toc-function 'org-export-latex-format-toc-default
> org-tab-first-hook '(org-hide-block-toggle-maybe
> org-src-native-tab-command-maybe
> org-babel-hide-result-toggle-maybe)
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-confirm-shell-link-function 'yes-or-no-p
> org-export-first-hook '(org-beamer-initialize-open-trackers)
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-blank-before-new-entry nil
> org-babel-pre-tangle-hook '(save-buffer)
> org-cycle-hook '(org-cycle-hide-archived-subtrees
> org-cycle-hide-drawers org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-export-preprocess-before-normalizing-links-hook
> '(org-remove-file-link-modifiers)
> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook org-show-block-all
> append local] 5]
>#[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook
> org-babel-show-result-all
> append local] 5]
>org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
> org-babel-execute-safely-maybe)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src
> org-babel-exp-inline-src-blocks))
> org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> org-occur-hook '(org-first-headline-recenter)
> org-from-is-user-regexp nil
> org-export-preprocess-before-selecting-backend-code-hook
> '(org-beamer-select-beamer-code)
> org-confirm-babel-evaluate nil
> org-export-latex-final-hook '(org-beamer-amend-header
> org-beamer-fix-toc org-beamer-auto-fragile-frames
> org-beamer-place-default-actions-for-lists)
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-export-blocks '((src org-babel-exp-src-block nil) (comment
> org-export-blocks-format-comment t)
>(ditaa org-export-blocks-format-ditaa nil) (dot
> org-export-blocks-format-dot nil))
> )
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
András Major writes: > Hi Eric, > >> I personally don't have time to make these changes right now, but I'd be >> happy to provide guidance and answer questions to anyone who wanted to >> try to submit a patch. Also, there are a number of files which can >> serve as examples of how to compile and execute code with Babel e.g., >> ob-java.el and ob-C.el. > > That's what I suspected judging from the behaviour I've seen. Is > anyone else interested in such work? I don't have much time either, > in particular I'm not sufficiently familiar with emacs and Lisp to do > something useful quickly. > >> I would prefer to keep haskell as the source block type if only so that >> the blocks are fontified with haskell-mode. However something like an >> :engine or :compiler keyword could be used to specify ghc or hugs. > > Good idea, but specifying ghc is ambiguous: it'll have to be either > ghci, runghc/runhaskell, oder hugs, or maybe some other > interpreter/compiler someone else would like to use (nhc98, etc., > there a quite a few). At least the three options I listed all have > incompatibilities in even the simplest use cases, owing to the > peculiarities of Haskell as a pure, declarative language. > A more open-ended :compiler or :interpreter header argument accepting ghc, rungch, hugs and nhc98 among others, sounds like a good idea. > > Also, using runghc would require the code block to be tangled first > into a temporary file. Is that easily done in babel? > Very easily, see ob-java.el. Adopting the compile-then-run functionality from there should not be a large task. Best -- Eric > > András > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] git repository over http?
Bastien writes: > Hi Jason, > > Jason Dunsmore writes: > >> I ran some tests and found that the download speed is proportional to >> the size of the repo: > > Good to know, thanks. > >> If you clone via git://, it does some optimizations during the transfer, >> whereas cloning via http:// does not. If I do a "git gc" on the repo, >> it reduces the size of the repo on the server and the time to download >> via http:// > > Okay -- can you "git gc" on the server? Okay, done: --8<---cut here---start->8--- orgmode@org:~$ du -sh org-mode.git 225Morg-mode.git orgmode@org:~/org-mode.git$ find objects/|wc -l 6523 orgmode@org:~/org-mode.git$ git gc Counting objects: 52023, done. Delta compression using up to 4 threads. Compressing objects: 100% (14474/14474), done. Writing objects: 100% (52023/52023), done. Total 52023 (delta 41421), reused 46864 (delta 37483) Removing duplicate objects: 100% (256/256), done. orgmode@org:~/org-mode.git$ du -sh 56M . orgmode@org:~/org-mode.git$ find objects/|wc -l 66 --8<---cut here---end--->8--- I lowered the git auto-gc threshold from the default of 6700 (loose objects) to 1000. orgmode@org:~/org-mode.git$ git config gc.auto 1000 Regards, Jason
Re: [O] Blog-like sitemap for org-publish
On Thu 2011-08-18 at 19:09, Bastien wrote: > Hi Jon, > > Jon Anders Skorpen writes: > > > I have made a function which creates a blog-like sitemap. It works as > > an alternative sitemap function to org-publish. > > This looks very interesting -- do you have a webpage we can look at to > see the result? > > Thanks! > > -- > Bastien > Yes. Here is a link to a test blog with some test posts, and one real post in norwegian. http://beta.mindmutation.net Since my initial email I have found a couple of things that should be done a little different, but I haven't had time to fix them. This includes the way keywords and dates are exported, and a couple of other things. -Jon Anders
Re: [O] Bug: named columns in tables not working if name contains "_"
On Aug 23, 2011, at 4:32 PM, Nick Dokos wrote:
> Carsten Dominik wrote:
>
>>
>> On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote:
>>
>>> András Major wrote:
>>>
>>>
Yet another one I just stumbled across: if I create a table and use
"!" in the first column to assign names to the columns, I can only
reference those columns by name in #+TBLFM: if the names don't contain
a "_" character. This isn't mentioned in the docs and shouldn't be
so, IMHO. I haven't checked for other common characters that are
prohibited, but the "_" bites me quite a bit.
>>>
>>> Try adding an underscore to the regexp on line 2179 of org-table.el -
>>> something like this (untested):
>>>
>>> ...
>>> (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name)
>>> (push (cons name (int-to-string cnt)) org-table-column-names
>>>
>>>
>>> The only characters permitted are alphanumerics. That can probably be
>>> easily relaxed.
>>
>> Hi Nick, I don't think it can be easily relaxed. Many other characters are
>> operators in Calc and would lead to confusion.
>>
>
> So add more syntax: formulas can use {this+is-a*/strange\@name}.
>
> OK, ok - just kidding.
>
> Thanks,
> Nick
>
> PS. This is a paraphrase of the indirection principle: Any problem can
>be solved by adding yet another layer of syntax...
:) Yes, true!
- Carsten
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, > This is the first time I've seen a tag applied to a table. I've updated > the results regular expression so that it will now admit examples like > yours above. Please let me know if this doesn't work with the latest > Org-mode. That's good news! Well, the bad news is that it doesn't work. I've just pulled the current version (release_7.7.174.g63fae) and now the behaviour is different: - :noexport: in the #+tblname: has no effect. - The :noexport: tag in a section including the table still has the same effect as before: table1 is not available as an input to the code block. - There are certain subtleties which I will report separately as they probably were there before and are unrelated, I just never bumped into them. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major writes: > Hi Eric, > >> This is the first time I've seen a tag applied to a table. I've updated >> the results regular expression so that it will now admit examples like >> yours above. Please let me know if this doesn't work with the latest >> Org-mode. > > That's good news! Well, the bad news is that it doesn't work. I've > just pulled the current version (release_7.7.174.g63fae) and now the > behaviour is different: > > - :noexport: in the #+tblname: has no effect. > I'm not sure that it is legal to apply tags to tables, so I'm not sure if this is a bug. > > - The :noexport: tag in a section including the table still has the > same effect as before: table1 is not available as an input to the > code block. > Oh, this was actually due to a slightly different issue, which I've just fixed. Specifically the following org-mode file now exports as successfully. * top ** not to be exported :noexport: #+data: something | 0 | | 1 | | 1 | | 2 | | 3 | | 5 | | 8 | ** to be exported #+begin_src emacs-lisp :var fib=something :exports results (car (nth 4 fib)) #+end_src > > - There are certain subtleties which I will report separately as they > probably were there before and are unrelated, I just never bumped > into them. > > András > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, > > That's good news! Well, the bad news is that it doesn't work. I've > > just pulled the current version (release_7.7.174.g63fae) and now the > > behaviour is different: > > > > - :noexport: in the #+tblname: has no effect. > > I'm not sure that it is legal to apply tags to tables, so I'm not sure > if this is a bug. Certainly, I'm just saying that it used to work but now it doesn't. I think that anything that works despite being designed and documented otherwise is confusing to the user and should be considered a bug. I'm happy that it no longer works and hope that it stays that way. > > - The :noexport: tag in a section including the table still has the > > same effect as before: table1 is not available as an input to the > > code block. > > Oh, this was actually due to a slightly different issue, which I've just > fixed. Specifically the following org-mode file now exports as > successfully. Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major writes: > here is an example that delivers an error "reference 'table1' not > found in this buffer" when trying to export to HTML (others not tried > yet): > > #+tblname: table1 :noexport: > | n | x | y1 | y2 | > |---+---+-+--| > | 0 | 1 | 2.0 | 3.0 | > | 1 | 2 | 2.1 | 2.0 | > | 2 | 3 | 2.0 | 0.3 | > | 3 | 4 | 1.0 | 0.6 | > | 4 | 5 | 1.4 | -0.1 | > | 5 | 6 | 1.6 | 1.2 | > > #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 > set size square > plot t u 2:3 w lp, t u 2:4 w lp > #+end_src > > If I remove the :noexport: tag, everything works fine. > > Am I doing something wrong here? Yes -- :noexport: is to be used on headlines only, not on tables. If you remove the :noexport: you should get the correct png (see attached.) HTH, <> -- Bastien
Re: [O] Bug: named columns in tables not working if name contains
Hi András, András Major writes: > Thanks Nick. It would be nice if the documentation reflected such an > arbitrary choice of characters you can use... I added a footnote. -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major writes: >> I'd have expected the noexport tag to be on a section containing the table. > > I forgot to mention in the report that of course I tried that too: if > I place the table and the code in two sections and tag the section > containing the table with :noexport:, the result is exactly the same. I'm not sure I understand -- does it mean that C-cC-c on #+begin_src fails in the example below? , | * Headline :noexport: | | #+tblname: table1 | | n | x | y1 | y2 | | |---+---+-+--| | | 0 | 1 | 2.0 | 3.0 | | | 1 | 2 | 2.1 | 2.0 | | | 2 | 3 | 2.0 | 0.3 | | | 3 | 4 | 1.0 | 0.6 | | | 4 | 5 | 1.4 | -0.1 | | | 5 | 6 | 1.6 | 1.2 | | | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 | set size square | plot t u 2:3 w lp, t u 2:4 w lp | #+end_src ` It works for me. > In my little experience, it work, and I think it's a desirable feature > too. I'm not really keen on creating a section for a table just so > that I can hide it. Tags only have meaning on headlines, whether it's for really tagging the headlines or for (un)selecting them during the export process. If we want export-related function specifically for tables, I'd rather use something like #+export_table: and a list of options. HTH, -- Bastien
Re: [O] Bug: Toggle descriptive and literal links [7.4]
Hi Thomas, t...@tsdye.com (Thomas S. Dye) writes: > Thanks for adding this. I work with literal links and this potentially > saves time and effort. > > I wonder if I'm using it correctly? In .emacs I set > org-link-display-descriptive nil and have: > > > org-link-display-descriptive is a variable defined in `org.el'. > Its value is nil > > Documentation: > Non-nil means Org will display descriptive links. > E.g. [[http://orgmode.org][Org website]] will be displayed as > "Org Website", hiding the link itself and just displaying its > description. When set to `nil', Org will display the full links > literally. > > You can interactively set the value of this variable using the > `org-toggle-link-display'. > > > But when I open an Org-mode buffer I find the links displayed > descriptively. The initialization of the link display relied on `org-descriptive-links' and I discover this variable (doh!) So I've now remove `org-link-display-descriptive' and use `org-descriptive-links' instead for backward compatibility. Please use this variable too and let me know if things are all right now. Best, -- Bastien
Re: [O] Bug: named columns in tables not working if name contains "_"
Hi Nick, Nick Dokos writes: > Try adding an underscore to the regexp on line 2179 of org-table.el - > something like this (untested): > > ... > (if (string-match "^[a-zA-Z][a-zA-Z0-9_]*$" name) > (push (cons name (int-to-string cnt)) org-table-column-names > > The only characters permitted are alphanumerics. That can probably be > easily relaxed. Thanks for the suggested fix. I've pushed a change to allow the underscore char in both field and column names. Best, -- Bastien
Re: [O] Error because org-refile calls org-back-to-heading
Matt Lundin writes: > Matt Lundin writes: > >> Since the commit c25165c25dc9fdb5b57b3c66b2e0ec0efdbeb7ad on August 18, >> I can only call this function when I am beneath the first level heading >> of an org-mode file. Otherwise I receive the following error: > > Here's a patch that allows one to call (org-refile t) in a non org-mode > buffer without resulting in an error. Applied, thanks! -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, Eric Schulte writes: > I'm not sure that it is legal to apply tags to tables, so I'm not sure > if this is a bug. I confirm tags are for headlines only. If we want to add more export options to tables, let's use the usual "#+[option] syntax -- like #+caption does. -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major writes: > I think that anything that works despite being designed and documented > otherwise is confusing to the user and should be considered a bug. > I'm happy that it no longer works and hope that it stays that way. I think tags are clearly documented as being properties of the headlines -- if there is places in the manual that we can improve in this respect, please suggest a patch. I don't think it's reasonable to document the fact that tags are not meant to be used in tables, blocks, lists, timestamps, etc. But there are some borderline cases that may happen, and I'm happy to fix the doc in these cases. Also, your question raises again the issue of a full description of Org's (implicit) syntax -- so let's try to make progress on this. Best, -- Bastien
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Michael Brand writes: > If the shell is a special case for babel anyway, why not something > like the following? Ehm, no. But I think that it would be generally useful (not just for shell blocks) to be able to capture stderr, either together with stdout or separately into a result target block and have the return status available as a variable (although that does not work for consecutive invocations in a session). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Bug: named columns in tables not working if name contains "_"
Hi Carsten, Carsten Dominik writes: >> The only characters permitted are alphanumerics. That can probably be >> easily relaxed. > > Hi Nick, I don't think it can be easily relaxed. Many other characters are > operators in Calc and would lead to confusion. So perhaps my recent commit is wrong. I did a few tests and found no problem, but I'm certainly not using calc operators that much. Please feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if necessary... > But amending the docs is certainly a good idea. ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. Thanks! -- Bastien
Re: [O] Problem with shift-up [solved]
Hi Peter, Peter Frings writes: > Yes, I did. I did find the offending command. Hooray! Great -- thanks for sharing! > (setq org-replace-disputed-keys t) > > Was set in the init.el file of the starter-kit. > > Now, is it just me or is the relation between this variable and > ‘org-support-shift-select’ slightly confusing? Mhh... maybe. I need to investigate further. If you have time to investigate on your side, please share your results! > Thanks for the patience and the support! You're welcome, Best, -- Bastien
Re: [O] Bug: named columns in tables not working if name contains "_"
Nick Dokos writes: > The only characters permitted are alphanumerics. That can probably be > easily relaxed. Only if you don't want to have _underlined_ still working and perhaps never use calc on that table. The problem with simple syntax is that the quoting rules become bizarre and the other way around. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] [babel] [bug] inline src_R breaks downstream src block
Eric Schulte writes: > It will probably be a couple of days before I have sufficient time to > address these issues, but rest assured it is only my TODO list. Thanks for your persistence in fixing this! -- Bastien
Re: [O] git repository over http?
Jason Dunsmore writes: >> Okay -- can you "git gc" on the server? > > Okay, done: Great -- thanks a lot! -- Bastien
Re: [O] Bug: named columns in tables not working if name contains "_"
On 23.8.2011, at 18:20, Bastien wrote: > Hi Carsten, > > Carsten Dominik writes: > >>> The only characters permitted are alphanumerics. That can probably be >>> easily relaxed. >> >> Hi Nick, I don't think it can be easily relaxed. Many other characters are >> operators in Calc and would lead to confusion. > > So perhaps my recent commit is wrong. I did a few tests and found no > problem, but I'm certainly not using calc operators that much. Please > feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if > necessary... I'll take a look. - Carsten > >> But amending the docs is certainly a good idea. > > ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. > > Thanks! > > -- > Bastien
Re: [O] Bug: Toggle descriptive and literal links [7.4]
Bastien writes: > Hi Thomas, > > t...@tsdye.com (Thomas S. Dye) writes: > >> Thanks for adding this. I work with literal links and this potentially >> saves time and effort. >> >> I wonder if I'm using it correctly? In .emacs I set >> org-link-display-descriptive nil and have: >> >> >> org-link-display-descriptive is a variable defined in `org.el'. >> Its value is nil >> >> Documentation: >> Non-nil means Org will display descriptive links. >> E.g. [[http://orgmode.org][Org website]] will be displayed as >> "Org Website", hiding the link itself and just displaying its >> description. When set to `nil', Org will display the full links >> literally. >> >> You can interactively set the value of this variable using the >> `org-toggle-link-display'. >> >> >> But when I open an Org-mode buffer I find the links displayed >> descriptively. > > The initialization of the link display relied on > `org-descriptive-links' and I discover this variable (doh!) > > So I've now remove `org-link-display-descriptive' and use > `org-descriptive-links' instead for backward compatibility. > > Please use this variable too and let me know if things are > all right now. > > Best, Aloha Bastien, I pulled from git and put this in .emacs: (setq org-descriptive-links nil) Now links display as expected on startup. Thanks for looking into this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Achim Gratz writes: > Michael Brand writes: >> If the shell is a special case for babel anyway, why not something >> like the following? > > Ehm, no. But I think that it would be generally useful (not just for > shell blocks) to be able to capture stderr, either together with stdout > or separately into a result target block and have the return status > available as a variable (although that does not work for consecutive > invocations in a session). > Hmm, I do think that a ":results stderr" option could be useful, however this would not be a trivial implementation as it may require adjustments to all of the language files. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Michael Brand writes:
> Hi Eric
>
> 2011/8/20 Eric Schulte :
>> [...] I would lean towards thinking
>> that passing along error messages is more important than returning error
>> codes, but if the community thinks differently I'm happy to change the
>> ob-sh behavior.
>
> A non-zero exit status and stderr of a process are not necessarily
> related. Because a process may also use
> - a non-zero exit status without error situation (e. g. grep, diff)
> - stderr for output not related with errors
> - stdout for error messages
> I would like very much to be able to collect all available feedback
> from a process at the same run. Even with an optional indication of
> the origin, for ambiguity like the "hello" below or just for clarification.
>
I agree that some mechanism for collecting output from STDERR could be
useful, however its implementation would not be trivial.
>
>> Unfortunately it seems that in either case the sh code blocks will need
>> to be different than other languages either in its handling of errors or
>> of return values. This is unavoidable due to the overloading of return
>> values in the shell as error indicators.
>
> If the shell is a special case for babel anyway, why not something
> like the following?
>
> #+begin_src sh :exports stdout stderr exit_status -v
> echo hello
> echo hello >&2
> false
> #+end_src
>
> #+results:
> : 2: hello
> : 1: hello
> : exit status: 1
>
> This would have been
> - with an option -v for verbosity to prefix
> stdout with "1: ", stderr with "2: " and the exit status
> - with the exit status of the last command without the need of an
> extra "echo $?".
>
> My habit as a background info: To learn more from the shell I use
> - a shell prompt with the exit status of the last command
> - when I sometimes want to visually divide stdout and stderr (bash):
> { { echo hello; echo hello >&2; } 3>&1 1>&2 2>&3 | sed 's/^/2: /'; } \
> 3>&1 1>&2 2>&3 | sed 's/^/1: /'; 3>&-
> to output:
> 2: hello
> 1: hello
>
I think that in general mixing the output status with STDOUT would not
be a clean solution, as it would require parsing to use. Also, I don't
think that the example above would help to bring the behavior of sh code
blocks more in-line with other code blocks.
Note that during interactive evaluation if the exit status is non-0 then
STDERR will be dumped into a babel error buffer which will be poped up,
so this information will not be silently discarded.
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
> > Your file uses #+data: where I use #+tblname: -- which one is the > official one? I have the impression that it's #+data:, but I haven't > come across that in the manual or elsewhere before. If #+tblname: > isn't supposed to be used as a target for a variable in the code > block, then we should make sure that it *never* behaves as such. > In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] how to add font-lock keywords
Hi all, I wasn't able to google a clear examples of how to do this. For example, I'd like to highlight all text between double-quotes. -- Le
Re: [O] org-odt numbering (Applying custom templates)
sort of hijacking this thread with a quick note: In order to remove numbering from the headings produced by org-odt, simply export a file, go to Tools -> Outline Numbering in libreoffice/openoffice, and turn numbering off for levels 1-10 (probalby you only need about 4 levels anyway). Then save the resulting file somewhere safe, customize the variable org-export-odt-styles-file to the path to that file, and you're done. I only write this because I had a little trouble figuring out how outline numbering works in openoffice. It would be pretty cool if the org option num: had an effect here, but I think that would require some work to implement (you'd have to have org override settings in styles.xml, presumably introducing the possibility of various errors).
Re: [O] Bug: named columns in tables not working if name contains "_"
On 23.8.2011, at 18:20, Bastien wrote: > Hi Carsten, > > Carsten Dominik writes: > >>> The only characters permitted are alphanumerics. That can probably be >>> easily relaxed. >> >> Hi Nick, I don't think it can be easily relaxed. Many other characters are >> operators in Calc and would lead to confusion. > > So perhaps my recent commit is wrong. I did a few tests and found no > problem, but I'm certainly not using calc operators that much. Please > feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if > necessary... I have checked, underscore is aceptable, calc allows it in variables names. However, I would not recommend adding any more characters to this regexp. - Carsten > >> But amending the docs is certainly a good idea. > > ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. > > Thanks! > > -- > Bastien
[O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
Here is a different solution. It is from my notes from long ago. To me, one issue with indenting is that you expect the previous line to be a direct parent, analogously with the outline. This conflicts with sorting and non-child descendents. If you sort, you can't take advantage of the feature and have it look right. If it's not a direct child, you can't take advantage of it either because you either confusingly indent too much or modify the semantics. Also, indenting interferes with putting as much information on the line as possible. Those with large fonts or small (e.g. mobile) displays value the real estate. === Here is an alternate, which might or might not satisfy the OP's needs tangentially, but might spark discussion in either case. One feature I have long wanted, but have not been able to implement, is to dim (or color) any agenda entry that has a descendant in the same agenda view. === This is a completely different thing from dimming blocked tasks, because it only looks at other tasks in the same view, and doesn't care about todo keywords. The pseudocode is this: loop for i in all headlines in agenda (even a combined agenda) if i has an ancestor in agenda, dim that ancestor Motivation is that sometimes I mark a task as important (or any other tag), and mark its child as important. When I look at the agenda view for important items without inheritance, I am less interested in the parent because there is something important in a descendent. But when B is done, I am interested in A again. I don't want to manipulate tags. I just want to have both there all the time in the agenda, but one dimmed. * deal with company A :important: * call B at company A :important: * call C === Hope this idea helps the OP's indenting need or similar ones. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com I support the Whittemore-Peterson Institute (WPI) === Bigotry against people with serious diseases is still bigotry.
Re: [O] Bug: named columns in tables not working if name contains "_"
Carsten Dominik writes: > I have checked, underscore is aceptable, calc allows it in variables > names. However, I would not recommend adding any more characters to > this regexp. Thanks for the quick feedback! -- Bastien
Re: [O] ebib configuration for org-bibtex
Hi Eric, Bastien writes: >> I think this fix is causing some mischief. > > I reverted this commit -- let's wait Eric is back and can fix this with > a better solution. Eric -- just making sure this is under your radar. I reverted your fix because it was not answering Thomas' problem, but it looks like your fix is right anyway, though not addressing the issue at hand. Could you have another look? Thanks in advance! -- Bastien
Re: [O] ebib configuration for org-bibtex
Bastien writes: > Hi Eric, > > Bastien writes: > >>> I think this fix is causing some mischief. >> >> I reverted this commit -- let's wait Eric is back and can fix this with >> a better solution. > > Eric -- just making sure this is under your radar. > Thanks, I had lost track of the end of this thread. > > I reverted your fix because it was not answering Thomas' problem, > but it looks like your fix is right anyway, though not addressing > the issue at hand. Could you have another look? > I've just reverted your reversion :). I'll take a look at Toms problem (which does appear to be separate) separately. Thanks -- Eric > > Thanks in advance!
Re: [O] ebib configuration for org-bibtex
t...@tsdye.com (Thomas S. Dye) writes: > Eric Schulte writes: > >> t...@tsdye.com (Thomas S. Dye) writes: >> >>> Aloha all, >>> >>> I'm trying, partially successfully, to configure org-bibtex so it mimics >>> some useful features of ebib. In particular, I'm wanting to add several >>> optional fields that ebib uses. >>> >>> >>> I have this in .emacs: >>> >>> #+begin_src emacs-lisp :tangle yes >>> (dolist (type org-bibtex-types) >>> (push :url (cdr (assoc :optional (cdr type >>> (push :annote (cdr (assoc :optional (cdr type >>> (push :abstract (cdr (assoc :optional (cdr type >>> (push :keywords (cdr (assoc :optional (cdr type >>> (push :file (cdr (assoc :optional (cdr type >>> ) >>> >>> (push (cons :url "A URL for the reference") org-bibtex-fields) >>> (push (cons :annote "Annotation is typically not exported") >>> org-bibtex-fields) >>> (push (cons :abstract "Abstract for annotated bibliography") >>> org-bibtex-fields) >>> (push (cons :keywords "Keywords for sorting with ebib") org-bibtex-fields) >>> (push (cons :file "A local file path used by ebib to open the >>> reference in an appropriate application") org-bibtex-fields) >>> #+end_src >>> >>> Most of it works fine, but the optional :file field doesn't respect its >>> argument. So, the following entry in the Org-mode file: >>> >> >> Hi Tom, >> >> The :file property is treated in a special manner when Org-mode resolves >> properties (notice it is an element of the `org-special-properties' >> variable). I've just pushed up a change which temporarily removes :file >> from this list while resolving bibtex entries. This change should fix >> your reported problem -- please let me know if it doesn't. If any other >> elements of `org-special-properties' seem likely to cause problems we >> can temporarily remove them as well. >> >> Best -- Eric > > Hi Eric, > > I think this fix is causing some mischief. In the Org-mode file where > a :FILE: property is set to preza-thesis.pdf R source code blocks > misbehave, as follows: > > #+source: land-sale-plot > #+begin_src R :var y=sales > str(y) > #+end_src > > #+results: land-sale-plot > [[file:preza-thesis.pdf]] > Hi Tom, Are you still experiencing the problem mentioned above? I'm unable to reproduce it locally. If so, would you mind trying to recreate the problem with an emacs session launched using "emacs -Q" to see if the cause lies somewhere in your personal configuration? I *do* have a file header argument for code blocks inside of subtrees which explicitly specify a file property (which can be easily checked using C-c C-v I), e.g., ** inheriting the file property :PROPERTIES: :FILE: something.png :END: #+begin_src ditaa +-+ | | |+-+ | || | +-+| || | | || |+-+ | || | | || | file | || | inheritance +-+| | | +-+ #+end_src #+results: [[file:something.png]] However when I do not specify such a FILE property, then no :file entry is present in the code blocks parameters. Thanks -- Eric
[O] Bug: typo in org-list - "point-maker"
Commit 08ca5be491f5704cc0c6cb87013a5e8537218488 causes an error because of typo: i.e., "point-maker" instead of point-marker Best, Matt
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Bastien, > I'm not sure I understand -- does it mean that C-cC-c on #+begin_src > fails in the example below? No, it means that exporting to HTML fails with that error message. It should actually evaluate the code and include the resulting PNG in the output (and that's what it does when :noexport: isn't present). András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Bastien, > > I think that anything that works despite being designed and documented > > otherwise is confusing to the user and should be considered a bug. > > I'm happy that it no longer works and hope that it stays that way. > > I think tags are clearly documented as being properties of the > headlines -- if there is places in the manual that we can improve > in this respect, please suggest a patch. I'm not talking about the manual. In my opinion, if there is a function that works only on headlines according to the manual, then it *must not* work in any other place. Otherwise some users might try the function they once heard of in a sense not specified in the documentation (here: in a table) and see that it works, and be surprised when it no longer does (in a future version of org-mode, or on a different computer). Therefore such "ghost features" must actively be eliminated. To me, the documentation is the leading specification of a piece of software. Anything the software doesn't do that is in the docs is a bug, but likewise anything it does do which the docs don't cover is also a bug. > I don't think it's reasonable to document the fact that tags are > not meant to be used in tables, blocks, lists, timestamps, etc. I fully agree. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, > > Your file uses #+data: where I use #+tblname: -- which one is the > > official one? I have the impression that it's #+data:, but I haven't > > come across that in the manual or elsewhere before. If #+tblname: > > isn't supposed to be used as a target for a variable in the code > > block, then we should make sure that it *never* behaves as such. > > > > In the interest of backwards compatibility and convenience there are a > number of equivalent options here, see the value of the > `org-babel-data-names' variable for all possible names. OK, in that case the example still doesn't work for me. Whether I use #+data or #+tblname, specifying the :noexport: tag in the section containing the table causes the HTML export to report the error "reference 'table1' not found in this buffer". As Bastien pointed out earlier, I'm not talking about simple evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so far). András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major wrote: > Hi Eric, > > > > Your file uses #+data: where I use #+tblname: -- which one is the > > > official one? I have the impression that it's #+data:, but I haven't > > > come across that in the manual or elsewhere before. If #+tblname: > > > isn't supposed to be used as a target for a variable in the code > > > block, then we should make sure that it *never* behaves as such. > > > > > > > In the interest of backwards compatibility and convenience there are a > > number of equivalent options here, see the value of the > > `org-babel-data-names' variable for all possible names. > > OK, in that case the example still doesn't work for me. Whether I use > #+data or #+tblname, specifying the :noexport: tag in the section > containing the table causes the HTML export to report the error > "reference 'table1' not found in this buffer". > > As Bastien pointed out earlier, I'm not talking about simple > evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so > far). > This is probably caused by org-export-preprocess-string: it does things in a certain order, and it probably kills the :noexport: stuff before it gets to the evaluation of the source block. It might be possible to change the order (ISTR a couple of cases, where behavior was changed by doing exactly this), but it's probably fraught with peril: approach with caution. Nick PS. Warning: the above is a guess: it may have nothing to do with reality.
Re: [O] ebib configuration for org-bibtex
Eric Schulte writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> Eric Schulte writes: >> >>> t...@tsdye.com (Thomas S. Dye) writes: >>> Aloha all, I'm trying, partially successfully, to configure org-bibtex so it mimics some useful features of ebib. In particular, I'm wanting to add several optional fields that ebib uses. I have this in .emacs: #+begin_src emacs-lisp :tangle yes (dolist (type org-bibtex-types) (push :url (cdr (assoc :optional (cdr type (push :annote (cdr (assoc :optional (cdr type (push :abstract (cdr (assoc :optional (cdr type (push :keywords (cdr (assoc :optional (cdr type (push :file (cdr (assoc :optional (cdr type ) (push (cons :url "A URL for the reference") org-bibtex-fields) (push (cons :annote "Annotation is typically not exported") org-bibtex-fields) (push (cons :abstract "Abstract for annotated bibliography") org-bibtex-fields) (push (cons :keywords "Keywords for sorting with ebib") org-bibtex-fields) (push (cons :file "A local file path used by ebib to open the reference in an appropriate application") org-bibtex-fields) #+end_src Most of it works fine, but the optional :file field doesn't respect its argument. So, the following entry in the Org-mode file: >>> >>> Hi Tom, >>> >>> The :file property is treated in a special manner when Org-mode resolves >>> properties (notice it is an element of the `org-special-properties' >>> variable). I've just pushed up a change which temporarily removes :file >>> from this list while resolving bibtex entries. This change should fix >>> your reported problem -- please let me know if it doesn't. If any other >>> elements of `org-special-properties' seem likely to cause problems we >>> can temporarily remove them as well. >>> >>> Best -- Eric >> >> Hi Eric, >> >> I think this fix is causing some mischief. In the Org-mode file where >> a :FILE: property is set to preza-thesis.pdf R source code blocks >> misbehave, as follows: >> >> #+source: land-sale-plot >> #+begin_src R :var y=sales >> str(y) >> #+end_src >> >> #+results: land-sale-plot >> [[file:preza-thesis.pdf]] >> > > Hi Tom, > > Are you still experiencing the problem mentioned above? I'm unable to > reproduce it locally. If so, would you mind trying to recreate the > problem with an emacs session launched using "emacs -Q" to see if the > cause lies somewhere in your personal configuration? > > I *do* have a file header argument for code blocks inside of subtrees > which explicitly specify a file property (which can be easily checked > using C-c C-v I), e.g., > > > ** inheriting the file property >:PROPERTIES: >:FILE: something.png >:END: > > #+begin_src ditaa >+-+ >| | >|+-+ | >|| | +-+| >|| | | || >|+-+ | || >| | || >| file | || >| inheritance +-+| >| | >+-+ > #+end_src > > #+results: > [[file:something.png]] > > > However when I do not specify such a FILE property, then no :file entry > is present in the code blocks parameters. > > Thanks -- Eric Hi Eric, I think the confusion leading to my messages has been the cause of some mischief. Apologies for that. The change you implemented to let the :FILE: property work correctly with ebib does what it is supposed to do. It does not cause the "mischief" that I was experiencing. AFAICT, your re-reversion of the code back into Org-mode was the correct action. I ran into the problem when I tried to include in my reading notes an R graphic for some newly reported data. The R source block was immediately below the bibliographic subheading with the :FILE: property. Babel saw the :FILE: property for the bibliographic subheading and applied that to the R code block, as I now believe it is supposed to do. My confusion came from the fact that I didn't recognize at the time that Babel sees the :FILE: property for the bibliographic subheading the same way it sees the :FILE: property for any other heading. When I move the R code away from the bibliographic subheading it all works as expected, as you note. Again, sorry for my noise, and thanks for your fix for the ebib integration. All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] org-odt numbering (Applying custom templates)
Matt > sort of hijacking this thread with a quick note: > > In order to remove numbering from the headings produced by org-odt, > simply export a file, go to Tools -> Outline Numbering in > libreoffice/openoffice, and turn numbering off for levels 1-10 > (probalby you only need about 4 levels anyway). Then save the > resulting file somewhere safe, customize the variable > org-export-odt-styles-file to the path to that file, and you're done. > > I only write this because I had a little trouble figuring out how > outline numbering works in openoffice. It would be pretty cool if the > org option num: had an effect here, but I think that would require > some work to implement (you'd have to have org override settings in > styles.xml, presumably introducing the possibility of various errors). I have fixed this issue a few minutes ago. If you set "num:nil" in OPTIONS line, outline numbering will be turned off. Could you please unapply the custom styles and try again. Thanks for reporting this. Jambunathan K.
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Detlef > Will you take care of org-odt working in orgmode for the foreseeable > future or don`t you care about orgmode anymore? I pushed a commit just a few minutes ago. So things are back to normal. Jambunathan K.
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major writes: > Hi Bastien, > >> > I think that anything that works despite being designed and documented >> > otherwise is confusing to the user and should be considered a bug. >> > I'm happy that it no longer works and hope that it stays that way. >> >> I think tags are clearly documented as being properties of the >> headlines -- if there is places in the manual that we can improve >> in this respect, please suggest a patch. > > I'm not talking about the manual. In my opinion, if there is a > function that works only on headlines according to the manual, then it > *must not* work in any other place. Otherwise some users might try > the function they once heard of in a sense not specified in the > documentation (here: in a table) and see that it works, and be > surprised when it no longer does (in a future version of org-mode, or > on a different computer). Therefore such "ghost features" must > actively be eliminated. > > To me, the documentation is the leading specification of a piece of > software. Anything the software doesn't do that is in the docs is a > bug, but likewise anything it does do which the docs don't cover is > also a bug. Aloha Andras, As an avocational programmer who has had the pleasure of making small changes to the Org-mode manual and on-line documentation, this last bit seems to raise the bar impractically high. Part of Org-mode's appeal to me is that people frequently find new, and at least to me unexpected, ways to use it productively. I find it interesting to see how best to change the documentation to incorporate the new "discovery." That said, the idea that the docs cover *everything* that Org-mode is capable of doing is wonderful and I'll be happy to chip in when I can to help you achieve that goal. All the best, Tom > >> I don't think it's reasonable to document the fact that tags are >> not meant to be used in tables, blocks, lists, timestamps, etc. > > I fully agree. > > András > > > > -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Nick Dokos writes: > András Major wrote: > >> Hi Eric, >> >> > > Your file uses #+data: where I use #+tblname: -- which one is the >> > > official one? I have the impression that it's #+data:, but I haven't >> > > come across that in the manual or elsewhere before. If #+tblname: >> > > isn't supposed to be used as a target for a variable in the code >> > > block, then we should make sure that it *never* behaves as such. >> > > >> > >> > In the interest of backwards compatibility and convenience there are a >> > number of equivalent options here, see the value of the >> > `org-babel-data-names' variable for all possible names. >> >> OK, in that case the example still doesn't work for me. Whether I use >> #+data or #+tblname, specifying the :noexport: tag in the section >> containing the table causes the HTML export to report the error >> "reference 'table1' not found in this buffer". >> >> As Bastien pointed out earlier, I'm not talking about simple >> evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so >> far). >> > Are you /sure/ that this doesn't work for you? On my system C-c C-e A in the following attached org-mode file (posted earlier in this thread) * top ** not to be exported :noexport: #+data: something | 0 | | 1 | | 1 | | 2 | | 3 | | 5 | | 8 | ** to be exported #+begin_src emacs-lisp :var fib=something :exports results (car (nth 4 fib)) #+end_src Does export and correctly resolves the variable in the :noexport:'d section resulting in the following output. , |noexport | | | Author: Eric Schulte | Date: 2011-08-23 17:37:28 MDT | | | Table of Contents | = | 1 top | 1.1 to be exported | | | 1 top | -- | | 1.1 to be exported | === | | | 3 | ` > > This is probably caused by org-export-preprocess-string: it does things > in a certain order, and it probably kills the :noexport: stuff before it > gets to the evaluation of the source block. > > It might be possible to change the order (ISTR a couple of cases, where > behavior was changed by doing exactly this), but it's probably fraught with > peril: approach with caution. > The above analysis is correct. Babel has to deal with this when resolving header arguments, noweb references and variable expansions. It does this by resolving these things in the original org-mode buffer rather than in the temporary export buffer which is often missing portions which are not to be exported. See the definition of the `org-babel-exp-in-export-file' macro for details. Best -- Eric > > Nick > > PS. Warning: the above is a guess: it may have nothing to do with reality. > -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Implement history facility for org-occur searches
Hi Bastien and everyone, I wanted to implement a history facility for sparse trees. Since sparse trees use org-occur and org-scan-tags any such facility would need to be aware of both functions. My lisp foo proved to be too weak to understand org-scan-tags, so I implemented this only for org-occur searches. With this patch one can traverse the sparse tree history for date, regular expression and TODO keyword searches with the org-occur-history-forward and org-occur-history-backward functions. One can also call the org-occur-history-next function interactively to jump to the nth history entry. This should also work for any other searches that uses org-occur as the backend. Please feel free to modify the patch if there are better ways to implement this facility. Thank you. -- Suvayu Open source is the future. It sets us free. >From 11c36f42d1471629fd783aaf1db4aaf3d1d01ef6 Mon Sep 17 00:00:00 2001 From: Suvayu Ali Date: Tue, 23 Aug 2011 14:25:08 +0200 Subject: [PATCH] Implement history facility for org-occur searches Changed function: * org.el (org-occur): Add history functionality and corresponding documentation New functions: * org.el (org-occur-history-next): Function for history traversal (org-occur-history-forward) and (org-occur-history-backward): User funtions for moving forward and backward in search history New variables: * org.el (org-occur-match-history): Search history variable (org-occur-match-history-len): Search history size --- lisp/org.el | 65 +- 1 files changed, 63 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index bbc6a75..d419a04 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12294,6 +12294,15 @@ (defvar org-occur-parameters nil as well.") (make-variable-buffer-local 'org-occur-parameters) + Org occur history variables +(defvar org-occur-match-history nil + "History list of `org-occur' searches.") +(make-variable-buffer-local 'org-occur-match-history) +(defcustom org-occur-match-history-len 10 + "Length of `org-occur-match-history'." + :type 'integer + :group 'org) + (defun org-occur (regexp &optional keep-previous callback) "Make a compact tree which shows all matches of REGEXP. The tree will show the lines where the regexp matches, and all higher @@ -12303,7 +12312,15 @@ (defun org-occur (regexp &optional keep-previous callback) call to `org-occur' will be kept, to allow stacking of calls to this command. If CALLBACK is non-nil, it is a function which is called to confirm -that the match should indeed be shown." +that the match should indeed be shown. + +The org-occur search history is stored in the variable +`org-occur-match-history'. The length of the history is determined by the +variable `org-occur-match-history-len'. The function +`org-occur-history-next' can be used to traverse the org-occur history. +Two user functions `org-occur-history-forward' and +`org-occur-history-backward' are provided to conveniently traverse the +org-occur history one step at a time." (interactive "sRegexp: \nP") (when (equal regexp "") (error "Regexp cannot be empty")) @@ -12322,7 +12339,17 @@ (defun org-occur (regexp &optional keep-previous callback) (save-match-data (funcall callback))) (setq cnt (1+ cnt)) (when org-highlight-sparse-tree-matches - (org-highlight-new-match (match-beginning 0) (match-end 0))) + (org-highlight-new-match (match-beginning 0) (match-end 0)) + ;; remove duplicate element + (setq org-occur-match-history + (delete regexp org-occur-match-history)) + ;; add last search at the front + (add-to-list 'org-occur-match-history regexp) + ;; curtail history to max history length + (if (eq org-occur-match-history-len + (length org-occur-match-history)) + (setq org-occur-match-history + (butlast org-occur-match-history (org-show-context 'occur-tree (when org-remove-highlights-with-change (org-add-hook 'before-change-functions 'org-remove-occur-highlights @@ -12360,6 +12387,40 @@ (defun org-occur-next-match (&optional n reset) (goto-char p1) (error "No more matches" +(defun org-occur-history-next (steps) +"Traverse org occur history by STEPS steps in the forward direction +with respect to the current position. The search history is saved after +removing any duplicate searches. It is reordered to reflect the most +recent search. Before traversing the history the following transformation +is applied: STEPS MODULO `org-occur-match-history-len'. + +For negative STEPS, history traversal is done in the backward direction +starting at the end of the history list. When called interactively it +prompts for the number of steps." +(interactive "NSteps: ") +(let (match) + (if (< steps 0) + (setq match + (car (last org-occur-match-history + (mod (- steps) org-occur-match-history-len + (setq match (nth (mod steps org-occur-match-history-len)
Re: [O] Bug: typo in org-list - "point-maker"
Hello, Matt Lundin writes: > Commit 08ca5be491f5704cc0c6cb87013a5e8537218488 causes an error because > of typo: i.e., "point-maker" instead of point-marker Fixed, thanks. -- Nicolas Goaziou
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Eric Schulte writes: > Nick Dokos writes: > >> András Major wrote: >> >>> Hi Eric, >>> >>> > > Your file uses #+data: where I use #+tblname: -- which one is the >>> > > official one? I have the impression that it's #+data:, but I haven't >>> > > come across that in the manual or elsewhere before. If #+tblname: >>> > > isn't supposed to be used as a target for a variable in the code >>> > > block, then we should make sure that it *never* behaves as such. >>> > > >>> > >>> > In the interest of backwards compatibility and convenience there are a >>> > number of equivalent options here, see the value of the >>> > `org-babel-data-names' variable for all possible names. >>> >>> OK, in that case the example still doesn't work for me. Whether I use >>> #+data or #+tblname, specifying the :noexport: tag in the section >>> containing the table causes the HTML export to report the error >>> "reference 'table1' not found in this buffer". >>> >>> As Bastien pointed out earlier, I'm not talking about simple >>> evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so >>> far). >>> >> > > Are you /sure/ that this doesn't work for you? On my system C-c C-e A > in the following attached org-mode file (posted earlier in this thread) > > * top > ** not to be exported :noexport: > #+data: something > | 0 | > | 1 | > | 1 | > | 2 | > | 3 | > | 5 | > | 8 | Hi Eric, Your example works here, too. It fails, however, if there is an empty line between #+data: something and the first row of the table. Then a listp, nil error is raised. Perhaps this is what Andras is seeing? I haven't gone back to take a specific look at the manual, but in the past I've thought that the documentation of table naming isn't as good as it might be. In fact, I often have a hard time finding it in the first place :) hth, Tom > > ** to be exported > #+begin_src emacs-lisp :var fib=something :exports results > (car (nth 4 fib)) > #+end_src > > > Does export and correctly resolves the variable in the :noexport:'d > section resulting in the following output. > > , > |noexport > | > | > | Author: Eric Schulte > | Date: 2011-08-23 17:37:28 MDT > | > | > | Table of Contents > | = > | 1 top > | 1.1 to be exported > | > | > | 1 top > | -- > | > | 1.1 to be exported > | === > | > | > | 3 > | > ` > >> >> This is probably caused by org-export-preprocess-string: it does things >> in a certain order, and it probably kills the :noexport: stuff before it >> gets to the evaluation of the source block. >> >> It might be possible to change the order (ISTR a couple of cases, where >> behavior was changed by doing exactly this), but it's probably fraught with >> peril: approach with caution. >> > > The above analysis is correct. Babel has to deal with this when > resolving header arguments, noweb references and variable expansions. > It does this by resolving these things in the original org-mode buffer > rather than in the temporary export buffer which is often missing > portions which are not to be exported. See the definition of the > `org-babel-exp-in-export-file' macro for details. > > Best -- Eric > >> >> Nick >> >> PS. Warning: the above is a guess: it may have nothing to do with reality. >> -- Thomas S. Dye http://www.tsdye.com
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> I personally would really like to see important contribution such > as yours become more and more integrated into the 'standard' > Org ditribution - and not pushed further away. Precisely my point. Bastien's idea of merge is to make it into a long drawn affair. I disagree. Jambunathan K. --
Re: [O] how to add font-lock keywords
> Le Wang writes: > I wasn't able to google a clear examples of how to do this. For example, > I'd like to highlight all text between double-quotes. Typically it looks something like this: (font-lock-add-keywords org-mode (list (list (concat "\\(\"[^\"]+\"\\)") 1 highlight-face t))) Where `highlight-face' is the face you'd like to use. The regexp doesn't handle cases where \" legitimately occurs in a string, either. The part between the \\(\\) is what gets colorized. John
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> Precisely my point. Bastien's idea of merge is to make it into a long > drawn affair. I disagree. It would help if you or Bastien could explain what is going on. As is clear, everyone is hoping that the issues will be resolved and your valuable contributions will remain a part of org-mode. It does seem that you are, for now, letting them be within org-mode (your other mail). But it would still help if you express your apprehensions and discuss them openly on this list. Vikas
Re: [O] how to add font-lock keywords
> John Wiegley writes: > Le Wang writes: >> I wasn't able to google a clear examples of how to do this. For example, >> I'd like to highlight all text between double-quotes. > Typically it looks something like this: > (font-lock-add-keywords org-mode [...] Sorry, that should be 'org-mode, to name the symbol, not attempt to use its value. John
Re: [O] how to add font-lock keywords
Thanks for the hint, I tried this, but all my beautiful salad bowl
colours went away.
(font-lock-add-keywords 'org-mode '(("\"\\(\\(?:.\\|\n\\)*?[^\\]\\)\""
0 font-lock-string-face)))
Notice that I made a bad attempt to handle escaped quotation mark in
the string. Does anyone know a better solution to handle escaped
characters in font-lock?
On Wed, Aug 24, 2011 at 9:17 AM, John Wiegley wrote:
>> John Wiegley writes:
>
>> Le Wang writes:
>>> I wasn't able to google a clear examples of how to do this. For example,
>>> I'd like to highlight all text between double-quotes.
>
>> Typically it looks something like this:
>
>> (font-lock-add-keywords org-mode
> [...]
>
> Sorry, that should be 'org-mode, to name the symbol, not attempt to use its
> value.
>
> John
>
>
>
--
Le
[O] [PATCH] Fix regression introduced in 15798836
Log [[[ * lisp/org-agenda.el (org-agenda-get-todos): Set category-pos before usage. ]]] Thanks and Regards Noorul diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index e3236e5..8d869be 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4607,6 +4607,7 @@ the documentation of `org-diary'." (goto-char (match-beginning 1)) (setq marker (org-agenda-new-marker (match-beginning 0)) category (org-get-category) + category-pos (get-text-property (point) 'org-category-position) txt (match-string 1) tags (org-get-tags-at (point)) txt (org-format-agenda-item "" txt category tags)
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> Hi Jambunathan, > >> I have made a decision not to merge org-lparse, org-xhtml & org-odt in >> to Orgmode core. It is a very difficult decision for me to take >> considering that I had put all my heart in to it. (Btw, this decision >> has nothing to with me not having enough time at hand.) > > As all, I'm puzzled by this statement, and wonder what went wrong > somehow. Without mincing words, Bastien has to learn how to respect and engage with serious contributors. He should take time to look at the data presented to him and put some serious effort before sending out an email. I am willing to overlook the fact that he seriously pissed me off with unkind words and committed a greater faux paus by inviting Lennart Borgman in to merge discussions. I am sorry to say this - Lennart Borgman did a half-baked work. I have been patient and tried my best to be as co-operative as possible. He just manages to get me on my nerves somehow. He simply didn't have the courtesy to reply to my mails when he simply disappeared from the list for 3 months or so. I hate to such callous attitude who claims to be a maintainer and wants to act like a maintainer. > What you did is a really important piece of the puzzle, as it finally > let us cooperate more easily with people we can't convert as > Org'ers. At least, they won't bother us to fit their software > requirement: we can work in Org up till the very end, and then produce > a final result in the expected (by others) format. > >> I leave it up to the community on what would be the best place to "host" >> this software. > > For me, the answer to this was/is clear: Org-mode itself, hence the reason > why I don't understand the above. I have definite ideas on how the merge should proceed. He should be willing to concede to the fact that I have a far better understanding on what the most effective method of merge is. Bastien has stepped in to big shoes and he has to measure up. > Best regards, > Seb --
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Tom, > > To me, the documentation is the leading specification of a piece of > > software. Anything the software doesn't do that is in the docs is a > > bug, but likewise anything it does do which the docs don't cover is > > also a bug. > > Aloha Andras, > > As an avocational programmer who has had the pleasure of making small > changes to the Org-mode manual and on-line documentation, this last bit > seems to raise the bar impractically high. Part of Org-mode's appeal to > me is that people frequently find new, and at least to me unexpected, > ways to use it productively. I find it interesting to see how best to > change the documentation to incorporate the new "discovery." That said, > the idea that the docs cover *everything* that Org-mode is capable of > doing is wonderful and I'll be happy to chip in when I can to help you > achieve that goal. I fully agree with you, but it looks like I didn't express my point clearly enough. I'm talking about very particular behaviour when, for instance, a certain keyword is encountered. The example in this bug report is a good illustration: if the tag :noexport: is only supposed to work in headlines, then I consider it a bug if it works elsewhere, so the developers must actually make sure that this never happens. Otherwise, an unsuspecting new user (like myself) reads the documentation, and accidentally tries the tag on something other than what's in the documentation. "Hooray, it works, and what a great piece of software this is" -- but that doesn't last long since a newer version of org-mode behaves differently and his undocumented and unintended "feature" no longer works. As a software user (in this case), I want to have a clear idea of what works and what doesn't, and if I try something and it works, I suppose it to be an official way of doing it. Had I not filed this bug report, I might have carried on using :noexport: on tables until, one day, suddenly all my documents break because this "feature" silently goes away. By saying that a "feature" must work if and only if it is so documented I refer to individual features (such as keywords, tags, keystrokes, etc.), not use cases. András
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> It does seem that you are, for now, letting them be within org-mode > (your other mail). But it would still help if you express your > apprehensions and discuss them openly on this list. There is another mail that is on it's way. (Replies to Sebastien Vauban always appear longer time to appear in the list) Let me wash all the linen in open because Bastien wanted all the criticism to be made public. (This suggestion is against my own experience how a criticism is perceived) I would like to ask (again), does Bastien know the difference between copyright and license (not in legal terms but just the dictionary meaning of it). I doubt he knows it. This cropped up because he made the absurd suggestion that OpenDocument Schema file (which is distributed by OASIS) should be GPLv3. He is asking me to name the schema files to be 8+3 when they are already fixed up right in contrib dir [1]. How long does it take a look at a person to cross verify whether or not a file is renamed. He wants to give him the elpa tarball again and have him upload it to Emacs bzr repo when only a few days ago I had built the tarball and shared a pointer to it [2]. Jason Dunsmor can vouch for what I say here. He had the audacity even to suggest that he is HELPING me committing my changes to Bzr. It is as though getting a commit access to Emacs elpa bzr is like getting an appointment to meet President Obama just to exchange pleasantries. I started my negotiation with emacs-devel when I lost trust in Bastien. How else can you feel about a person who disappears from the list without even returning mails. He has hijacked every single thread in emacs-devel since his re-appearance. Bastien could be a busy man. But not keeping track of conversation and asking meaningless questions is not how a maintainer shows appreciation of hard work one has done. When I criticized him he is labelling me insulting, patronizing and frustrated. Seriously to how low a level this person has to go. Footnotes [1] http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg00671.html [2] http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00666.html > Vikas > > --
