[O] freshly setting up MobileOrg and org-id-add-location problem
org-mode 7.4
MacOSX SnowLeopard
Hi. I have tried to re-set-up the MobileOrg environment using Dropbox.
I have succeeded in creating and making use of MobileOrg application before,
so the procedure of setting up should be OK.
I wrote the directory of org files and so on...
Then I implemented "org-mobile-push" but it gives a long error like
org-id-add-location: Wrong type argument: hash-table-p, (("~/Dropbox/Org/
main-todo.org" "5CFEA79D-5E11-406B-8C63-2DAE8DFC619B") ("~/Dropbox/Org/
main-todo.org" "4D2E2BF7-8245-4B52-9F54-9C312255CF61") ("~/Dropbox/Org/
web_service.org" "2C4C4F7F-C193-4DB0-910F-9171F590A5D0") ("~/Dropbox/Org/
main-todo.org" "8B559866-07C8-45C0-8C53-37A3A42CF10B") ("~/Dropbox/Org/
main-todo.org" "5B591CDD-6335-436C-9CDF-FA3272A9318B") ("~/Dropbox/Org/
main-todo.org" "2339B93C-66AB-4715-9789-545A506ADA8B") ("~/Dropbox/Org/
main-todo.org" "9FE39471-3919-4354-BBF9-363278FE2261") ("~/Dropbox/Org/
web_service.org" "BB07BF21-53A4-4DA9-B708-422FB045E176") ("~/Dropbox/Org/
main-todo.org" "9A7DF4AB-EAB2-437B-B97E-1A8CB331B508") ("~/Dropbox/Org/
main-todo.org" "F8DCA33A-B480-4E03-8DEF-47913C66555A") ...)
It shows the id's of the old set-up. And I found the file,
".org-id-locations" which is in ~/.emacs.d/ directory.
So, I erased it and restarted Emacs, but the same problem occurred. Every
time Emacs starts, it seems to create the file, .org-id-locations.
I think that this is the problem but not sure how to deal with it.
Could anyone help me out ?
soichi
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nicolas Goaziou writes:
> Hello,
>
> Eric S Fraga writes:
>
>> Very true. I missed this. Given the indentation, the listing should
>> indeed belong to the enumeration item.
>>
>> Nicolas?
>
> If I export this:
>
> -
> * Test
> 1. Try and use =org-export-as-latex=, it will produce error segment.
>#+BEGIN_SRC C
>MODULE m_global_precision
> IMPLICIT NONE
> INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
>END MODULE m_global_precision
>#+END_SRC
> -
>
> I get this:
>
> #+begin_src latex
> \section{Test}
> \label{sec-1}
>
>
> \begin{enumerate}
> \item Try and use \texttt{org-export-as-latex}, it will produce error segment.
> \lstset{language=C}
> \begin{lstlisting}
> MODULE m_global_precision
> IMPLICIT NONE
> INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
> END MODULE m_global_precision
> \end{lstlisting}
> \end{enumerate}
> #+end_src
>
> It looks ok, or am I missing something?
>
> Regards,
Nicolas,
It does look okay but that's not what I get; same input, I get:
--8<---cut here---start->8---
\section{Test}
\label{sec-1}
\begin{enumerate}
\item Try and use \verb=org-export-as-latex=, it will produce error segment.
\end{enumerate}
\lstset{language=C}
\begin{lstlisting}
MODULE m_global_precision
IMPLICIT NONE
INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
END MODULE m_global_precision
\end{lstlisting}
ORG-LIST-END-MARKER
\end{document}
--8<---cut here---end--->8---
I guess I have some variable set that you do not or vice versa. For
instance, I have org-list-end-marker set to 'both. Are there any
variable settings you need to know to figure out why my behaviour is
different? I'm at git head.
Thanks,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
[O] [babel] using #+call for inline results
Hello,
I have been playing with org babel for putting results inline within an
exported latex file. A simple example is here:
--8<---cut here---start->8---
* testing inline evaluation of babel source blocks
#+srcname: benzene-chlorobenzene-relative-volatility
#+begin_src octave :exports none :results output raw :var T=25
format bank
pb = 10^(6.89272 - 1203.531/(T+219.888));
pc = 10^(7.10690 - 1500.0 /(T+224.000));
alpha = pb/pc;
disp(alpha)
#+end_src
1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ}
C\):
#+call: benzene-chlorobenzene-relative-volatility[:results output
raw](T=25) :exports results
2. Compare this to the value we get at 50 \(^{\circ}C\):
#+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results
3. Next we use this value to draw an equilibrium curve.
--8<---cut here---end--->8---
If I evaluate the code block, I get what I expect:
,
| #+results: benzene-chlorobenzene-relative-volatility
| 7.86
`
However, when I export the file, the #+call lines get wrapped in a
verbatim environment regardless of what or where I specify for
the :results header arguments. E.g.:
,
| \begin{enumerate}
| \item The first step is to evaluate the relative volatility at \(T=25
^{\circ} C\):
|
|
| \begin{verbatim}
| 7.86
| \end{verbatim}
|
| \item Compare this to the value we get at 50 \(^{\circ}C\):
|
|
| \begin{verbatim}
| 6.32
| \end{verbatim}
`
What am I doing wrong? I have tried various permutations of the
placement of the :results header and various options for it but do not
seem to have hit on the right combination.
Ideally, I would like the number to appear completely inline with the
text the precedes and follows the #+call statement. I would prefer to
not have a new paragraph started, for instance.
On a related note, although the manual seems to indicate that "raw" and
"org" are synonymous, they behave differently when evaluating a code
block with the latter encapsulating the output within #+begin_org
and #+end_org. The behaviour is fine but maybe the documentation,
assuming I have understand things correctly, should be changed to
reflect the difference in behaviour?
Thanks,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Eric S Fraga writes:
> It does look okay but that's not what I get; same input, I get:
>
>
> \section{Test}
> \label{sec-1}
>
>
> \begin{enumerate}
> \item Try and use \verb=org-export-as-latex=, it will produce error segment.
> \end{enumerate}
> \lstset{language=C}
> \begin{lstlisting}
>MODULE m_global_precision
> IMPLICIT NONE
> INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
>END MODULE m_global_precision
> \end{lstlisting}
>
> ORG-LIST-END-MARKER
>
> \end{document}
>
>
> I guess I have some variable set that you do not or vice versa. For
> instance, I have org-list-end-marker set to 'both. Are there any
> variable settings you need to know to figure out why my behaviour is
> different? I'm at git head.
I've tried with a minimal setup, and I still get the correct export. If
you confirm this, we have two options left: either you bisect your
config until you get the offending variable, or you send me that config
so I can do the same.
Note that variable may even be unrelated to Org.
Regards,
--
Nicolas Goaziou
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nicolas Goaziou writes: [...] > I've tried with a minimal setup, and I still get the correct export. If > you confirm this, we have two options left: either you bisect your > config until you get the offending variable, or you send me that config > so I can do the same. I can confirm that it works fine with minimal setup. Definitely something wrong with my config. > Note that variable may even be unrelated to Org. Yes; I've found some strange behaviour that may be related to emacs 24.0.50.1 which I will follow up on in a different thread; for completeness, what version of Emacs are you using? thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Eric S Fraga wrote: > Nicolas Goaziou writes: > > [...] > > > I've tried with a minimal setup, and I still get the correct export. If > > you confirm this, we have two options left: either you bisect your > > config until you get the offending variable, or you send me that config > > so I can do the same. > > I can confirm that it works fine with minimal setup. Definitely > something wrong with my config. > > > Note that variable may even be unrelated to Org. > > Yes; I've found some strange behaviour that may be related to emacs > 24.0.50.1 which I will follow up on in a different thread; for > completeness, what version of Emacs are you using? > I don't even have the variable (org-list-end-marker) defined at all. Where is it defined? The only ones my emacs finds with that prefix are , | Possible completions are: | org-list-end-re | org-list-end-regexp | org-list-ending-method ` And, btw, I can't reproduce the problem either. Nick
[O] [bug] problem with org-install.el paths
Hello, for some reason, recently I have had problems getting emacs to autoload different bits of org when required. I've tracked this down to my org-install file having entries like this: : (autoload 'org-babel-do-load-languages "lisp/org" " ..." t nil) : (autoload 'org-agenda "lisp/org-agenda" "..." t nil) Note the =lisp/org= and =lisp/org-agenda= paths. I would have expected these to be simply =org= and =org-agenda=. I have removed org-install.el (=make cleanall= specifically) and done =make all=. The file that is created has those entries. These entries obviously do not work well with my usual: : (add-to-list 'load-path "~/git/org-mode/lisp") : (add-to-list 'load-path "~/git/org-mode/contrib/lisp") so I have had to add a number of explicit '(require org-xxx) lines in my config. Should I remove the "lisp" part from the first line? If so, the documentation in the manual is out of sync with the behaviour required: : (setq load-path (cons "~/path/to/orgdir/lisp" load-path)) I am tracking Emacs development so am using a fairly recent snapshot of emacs 24.0.50.0. Could this be the problem? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Eric S Fraga writes: > Yes; I've found some strange behaviour that may be related to emacs > 24.0.50.1 which I will follow up on in a different thread; for > completeness, what version of Emacs are you using? The good ol' 23.3.1 -- Nicolas Goaziou
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nicolas Goaziou wrote: > Eric S Fraga writes: > > > Yes; I've found some strange behaviour that may be related to emacs > > 24.0.50.1 which I will follow up on in a different thread; for > > completeness, what version of Emacs are you using? > > The good ol' 23.3.1 > I'm on 24.0.50.1, so I don't think that's the problem. Nick
Re: [O] [babel] using #+call for inline results
Hi Eric,
So the problem is that the results are inserted as a separate block,
when you want them to be inserted inline? If so perhaps using an
"inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
would result in the desired behavior.
Please let me know if I've misunderstood the question.
Best -- Eric
Eric S Fraga writes:
> Hello,
>
> I have been playing with org babel for putting results inline within an
> exported latex file. A simple example is here:
>
> * testing inline evaluation of babel source blocks
>
> #+srcname: benzene-chlorobenzene-relative-volatility
> #+begin_src octave :exports none :results output raw :var T=25
> format bank
> pb = 10^(6.89272 - 1203.531/(T+219.888));
> pc = 10^(7.10690 - 1500.0 /(T+224.000));
> alpha = pb/pc;
> disp(alpha)
> #+end_src
>
> 1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ}
> C\):
> #+call: benzene-chlorobenzene-relative-volatility[:results output
> raw](T=25) :exports results
>
> 2. Compare this to the value we get at 50 \(^{\circ}C\):
> #+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results
>
> 3. Next we use this value to draw an equilibrium curve.
>
>
> If I evaluate the code block, I get what I expect:
>
> ,
> | #+results: benzene-chlorobenzene-relative-volatility
> | 7.86
> `
>
> However, when I export the file, the #+call lines get wrapped in a
> verbatim environment regardless of what or where I specify for
> the :results header arguments. E.g.:
>
> ,
> | \begin{enumerate}
> | \item The first step is to evaluate the relative volatility at \(T=25
> ^{\circ} C\):
> |
> |
> | \begin{verbatim}
> | 7.86
> | \end{verbatim}
> |
> | \item Compare this to the value we get at 50 \(^{\circ}C\):
> |
> |
> | \begin{verbatim}
> | 6.32
> | \end{verbatim}
> `
>
> What am I doing wrong? I have tried various permutations of the
> placement of the :results header and various options for it but do not
> seem to have hit on the right combination.
>
> Ideally, I would like the number to appear completely inline with the
> text the precedes and follows the #+call statement. I would prefer to
> not have a new paragraph started, for instance.
>
> On a related note, although the manual seems to indicate that "raw" and
> "org" are synonymous, they behave differently when evaluating a code
> block with the latter encapsulating the output within #+begin_org
> and #+end_org. The behaviour is fine but maybe the documentation,
> assuming I have understand things correctly, should be changed to
> reflect the difference in behaviour?
>
> Thanks,
> eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] [Use Question] Capture and long lines
I have one structured org file I use for school that I leave in long lines. The capture template I have setup has \n at the end of what I would want to be a line but is still stringing them together in one long line until i reach my wrap point. My headline has my deadline in it and org recognizes the deadline but that isn't working to get a new line inserted (an actual hard return). Org is recongnizing it as a new line but it just runs in one long line. Am I missing something obvious or If it isn't something obvious I will make up a sample target file, example of a capture and send them out to the group * WORKING Read Chapter 9 :ENGL102: \n DEADLINE:<2011-06-28 Tue 18:30>\n ADDEND:<2011-06-28 Tue 00:00>\n : Also the logbook just keeps adding in as one long line :LOGBOOK: -State "STARTED from "TODO" [2011-06-22 Wed 09:56] :END: Is this inherent in the way it works with longlines or is their a way to insert: ¶ when I want an actual hard return in the template that is going into the longlines file? Matthew
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nick Dokos writes: > Eric S Fraga wrote: > >> Nicolas Goaziou writes: >> >> [...] >> >> > I've tried with a minimal setup, and I still get the correct export. If >> > you confirm this, we have two options left: either you bisect your >> > config until you get the offending variable, or you send me that config >> > so I can do the same. >> >> I can confirm that it works fine with minimal setup. Definitely >> something wrong with my config. >> >> > Note that variable may even be unrelated to Org. >> >> Yes; I've found some strange behaviour that may be related to emacs >> 24.0.50.1 which I will follow up on in a different thread; for >> completeness, what version of Emacs are you using? >> > > I don't even have the variable (org-list-end-marker) defined at all. > Where is it defined? The only ones my emacs finds with that prefix are > > , > | Possible completions are: > | org-list-end-re > | org-list-end-regexp > | org-list-ending-method > ` Apologies but that was my auto-completion completing on the wrong term! ooops. I have the same three org-list-end* variables as you. I've gone through my whole config and have tracked down the problem: : (setq org-src-preserve-indentation t) if I have this line present, the latex export doesn't work; if I remove this line, the export works as it should. This would appear to be a bug in the exporter? thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
Re: [O] [babel] How to set multiple variables with properties
Hi again, I was referring to these functions: - org-entry-put-multivalued-property - org-entry-get-multivalued-property - org-entry-add-to-multivalued-property - org-entry-remove-from-multivalued-property - org-entry-member-in-multivalued-property described here: http://orgmode.org/manual/Using-the-property-API.html I've found a few discussions: - http://comments.gmane.org/gmane.emacs.orgmode/33457 - http://lists.gnu.org/archive/html/emacs-orgmode/2010-02/msg00251.html I don't have anything working with them, as such,[1] and I was curious if anyone did. They don't currently seem to be integrated into completion, search functions, Babel, and so on, which would limit their usefulness (though searching can be done with regexps). And I think implementing wider support for them would run into a problem with distinguishing between properties that are meant to be multivalued, or and properties that just contain a single value which happens to contain spaces. But handling multiple var=value expressions in a :var: property for Babel, as Darlan asked about, might perhaps be doable...? Stuff might break, though. Yours, Christian [1] I do have a small research database with some "multivalued" properties in it. For queries, I use your org-collector and regular expression matching against properties with multiple values. The multivalued-properties functions didn't really come into it, except that knowing they were there made me go ahead and put multiple values in one property. (As it turned out, that wasn't a very good design choice.) On 6/21/11 11:03 PM, Eric Schulte wrote: Hi Christian, That's the first I've heard of that variable? If you do get something working with multivalued properties please do share. Cheers -- Eric Christian Moe writes: Hi, Eric, Just curious: What about the org-entry--multivalued-property functions mentioned in "Using the properties API"? Is anybody using multivalued properties for anything? Yours, Christian On 6/21/11 10:17 PM, Eric Schulte wrote: Unfortunately org-mode properties only allow a single entry for any given key, so you can only specify one variable using properties. However the following workaround does exist. *** alternative :PROPERTIES: :var: vars=variables :END: #+tblname: variables | var1 | 1 | | var2 | 2 | #+begin_src python print vars[0][1] print vars[1][1] #+end_src Best -- Eric Darlan Cavalcante Moreira writes: I'm using org-babel to automate a few tasks and I'd like to define a few variables that are common to several code blocks as sub-tree properties. It works when I have only one variable, where I can use * Heading :PROPERTY: :var: variable1="value1" :END: #+begin_src python :results output print variable1 #+end_src #+results: : value1 Is it possible to set multiples variables in this way? I tried things like :PROPERTY: :var: variable1="value1" variable2="value2" :END: :PROPERTY: :var: variable1="value1",variable2="value2" :END: :PROPERTY: :variable1: "value1" :variable2: "value2" :END: but none of them worked. -- Darlan Cavalcante
Re: [O] [babel] using #+call for inline results
Hi,
The documentation for #+call is rather confusing:
It is also possible to evaluate named code blocks from anywhere in
an Org-mode buffer or an Org-mode table. #+call (or synonymously
#+function or #+lob) lines can be used to remotely execute code
blocks...
Because aparently #+call only works on on a line by itself. Check the
following in ob-lob.el:
#+begin_src emacs-lisp
(defconst org-babel-lob-one-liner-regexp
(concat
"^\\([ \t]*\\)#\\+\\(?:"
(mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
"\\):[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
"\(\\([^\n]*\\)\)\\(\\[.+\\]\\|\\)[ \t]*\\([^\n]*\\)")
"Regexp to match calls to predefined source block functions.")
#+end_src
This only matches whitespace at the beginning of line followed by
#+call (or lob or function), unlike the embedded calls of the form
src_{body} which can be inlined.
Regards,
.j.
On Wed, Jun 22, 2011 at 12:07:57PM +0100, Eric S Fraga wrote:
> I have been playing with org babel for putting results inline within an
> exported latex file. A simple example is here:
>
> --8<---cut here---start->8---
> * testing inline evaluation of babel source blocks
>
> #+srcname: benzene-chlorobenzene-relative-volatility
> #+begin_src octave :exports none :results output raw :var T=25
> format bank
> pb = 10^(6.89272 - 1203.531/(T+219.888));
> pc = 10^(7.10690 - 1500.0 /(T+224.000));
> alpha = pb/pc;
> disp(alpha)
> #+end_src
>
> 1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ}
> C\):
> #+call: benzene-chlorobenzene-relative-volatility[:results output
> raw](T=25) :exports results
>
> 2. Compare this to the value we get at 50 \(^{\circ}C\):
> #+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results
>
> 3. Next we use this value to draw an equilibrium curve.
>
> --8<---cut here---end--->8---
>
> If I evaluate the code block, I get what I expect:
>
> ,
> | #+results: benzene-chlorobenzene-relative-volatility
> | 7.86
> `
>
> However, when I export the file, the #+call lines get wrapped in a
> verbatim environment regardless of what or where I specify for
> the :results header arguments. E.g.:
>
> ,
> | \begin{enumerate}
> | \item The first step is to evaluate the relative volatility at \(T=25
> ^{\circ} C\):
> |
> |
> | \begin{verbatim}
> | 7.86
> | \end{verbatim}
> |
> | \item Compare this to the value we get at 50 \(^{\circ}C\):
> |
> |
> | \begin{verbatim}
> | 6.32
> | \end{verbatim}
> `
>
> What am I doing wrong? I have tried various permutations of the
> placement of the :results header and various options for it but do not
> seem to have hit on the right combination.
>
> Ideally, I would like the number to appear completely inline with the
> text the precedes and follows the #+call statement. I would prefer to
> not have a new paragraph started, for instance.
>
> On a related note, although the manual seems to indicate that "raw" and
> "org" are synonymous, they behave differently when evaluating a code
> block with the latter encapsulating the output within #+begin_org
> and #+end_org. The behaviour is fine but maybe the documentation,
> assuming I have understand things correctly, should be changed to
> reflect the difference in behaviour?
>
> Thanks,
> eric
>
Re: [O] [Use Question] Capture and long lines
Matthew Sauer wrote:
> I have one structured org file I use for school that I leave in long
> lines. The capture template I have setup has \n at the end of what I
> would want to be a line but is still stringing them together in one
> long line until i reach my wrap point. My headline has my deadline in
> it and org recognizes the deadline but that isn't working to get a new
> line inserted (an actual hard return). Org is recongnizing it as a
> new line but it just runs in one long line. Am I missing something
> obvious or If it isn't something obvious I will make up a
> sample target file, example of a capture and send them out to the
> group
>
> * WORKING Read Chapter 9 :ENGL102: \n
> DEADLINE:<2011-06-28 Tue 18:30>\n ADDEND:<2011-06-28 Tue
> 00:00>\n :
>
> Also the logbook just keeps adding in as one long line
> :LOGBOOK: -State "STARTED from "TODO" [2011-06-22 Wed 09:56] :END:
>
>
Looks as if you are escaping the newlines - are you using \\n in your
templates? If so, try losing one of the backslashes - or put explicit
newlines in the string which should amount to the same thing:
(setq org-capture-templates
'( ("t" "" entry (file+headline "~/lib/org/todo.org" "Tasks")
"* TODO %?
%U %a" :prepend t)
...
))
Nick
Re: [O] [babel] using #+call for inline results
Eric Schulte writes: > Hi Eric, Hi Eric! ;-) > So the problem is that the results are inserted as a separate block, > when you want them to be inserted inline? If so perhaps using an > "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html > would result in the desired behavior. > > Please let me know if I've misunderstood the question. Yes and no. I *do* want the effect that is achieved by using an inline block but I do *not* want to write the whole block inline as that can be difficult to do or, at the very best, hard to read even if possible... I would like to invoke/evaluate, inline, a particular source code block with a specific value of an argument. >From the documentation, I don't see how to "call" a src block inline. That's why I thought of using =#+call=. Am I missing something? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.418.ge860.dirty)
[O] org-insert-link and partial-completion-mode incompatibility?
Hi,
in emacs 23.3 with the org-mode release_7.5-421-ge734e I experience an
incompatibility between org-insert-link and partial-completion-mode.
org-insert-link in an org-mode buffer results in:
"Symbol's definition is void: t"
The trace back looks like
Debugger entered--Lisp error: (void-function t)
t(-1)
org-icompleting-read("Link: " (("http:") ("https:") ("ftp:") ("mailto:";)
("file:") ("news:";) ("shell:") ("elisp:") ("doi:") ("message:") ("file+sys:")
("file+emacs:") ("bbdb:") ("bibtex:") ("docview:") ("gnus:") ("info:") ("irc:")
("mew:") ("mhe:") ("rmail:") ("vm:") ("wl:")) nil nil nil tmphist nil)
apply(org-icompleting-read ("Link: " (("http:") ("https:") ("ftp:")
("mailto:";) ("file:") ("news:";) ("shell:") ("elisp:") ("doi:") ("message:")
("file+sys:") ("file+emacs:") ("bbdb:") ("bibtex:") ("docview:") ("gnus:")
("info:") ("irc:") ("mew:") ("mhe:") ("rmail:") ("vm:") ("wl:")) nil nil nil
tmphist nil))
org-completing-read("Link: " (("http:") ("https:") ("ftp:") ("mailto:";)
("file:") ("news:";) ("shell:") ("elisp:") ("doi:") ("message:") ("file+sys:")
("file+emacs:") ("bbdb:") ("bibtex:") ("docview:") ("gnus:") ("info:") ("irc:")
("mew:") ("mhe:") ("rmail:") ("vm:") ("wl:")) nil nil nil tmphist nil)
org-insert-link(nil)
call-interactively(org-insert-link nil nil)
Deactivating partial-completion-mode let me insert the link with no
problems.
Then it looks like org-insert-link doesn't call org-completing-read at
all.
Using the org version that comes with emacs 23.3 doesn't exhibit this
behaviour.
Kind regards,
Holger
[O] Patch on org-read-property-name
Hello, Please find a patch for setting properties. A name is proposed when the pointer is on a property line, the name in that line is set as default. Changelog: --- 2011-06-22 Vincent Belaïche * org.el (org-read-property-name): Propose default proerty name value by looking at whether current line is already some property setting. --- diff --git a/lisp/org.el b/lisp/org.el index b1edfa3..8318968 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6591,7 +6591,7 @@ in an indirect buffer, in overview mode. You can dive into the tree in that copy, use org-occur and incremental search to find a location. When pressing RET or `Q', the command returns to the original buffer in which the visibility is still unchanged. After RET is will also jump to -the location selected in the indirect buffer and expose the headline +the location selected in the indirect buffer and expose the headline hierarchy above." (interactive "P") (let* ((org-refile-targets `((nil . (:maxlevel . ,org-goto-max-level @@ -14095,7 +14095,20 @@ This is computed according to `org-property-set-functions-alist'." "Read a property name." (let* ((completion-ignore-case t) (keys (org-buffer-property-keys nil t t)) - (property (org-icompleting-read "Property: " (mapcar 'list keys + (default-prop (save-excursion + (save-match-data + (beginning-of-line) + (and (looking-at "^\\s-*:\\([^:\n]+\\):") +(null (string= (match-string 1) "END")) +(match-string 1) + (property (org-icompleting-read + (concat "Property" + (if default-prop (concat " [" default-prop "]") "") + ": ") + (mapcar 'list keys) + nil nil nil nil + default-prop + ))) (if (member property keys) property (or (cdr (assoc (downcase property) @@ -16120,7 +16133,7 @@ sequence appearing also before point. Even though the matchers for math are configurable, this function assumes that \\begin, \\(, \\[, and $$ are always used. Only the single dollar delimiters are skipped when they have been removed by customization. -The return value is nil, or a cons cell with the delimiter and the +The return value is nil, or a cons cell with the delimiter and the position of this delimiter. This function does a reasonably good job, but can locally be fooled by
[O] Typo in 'org-without-partial-completion'
I think there's an error in 'org-without-partial-completion' in org-macs.el. The variable pc-mode gets bound to the value of partial-completion-mode - but this is a VARIABLE (t if that mode is enabled). Funcalling the value of the variable produces an error, unsurprisingly. This breaks insertion of properties with 'org-set-property'. Fixing it involves quoting the the symbol as shown below: (defmacro org-without-partial-completion (&rest body) `(let ((pc-mode (and (boundp 'partial-completion-mode) 'partial-completion-mode))) ; <-- quote added (unwind-protect (progn (when pc-mode (funcall pc-mode -1)) ,@body) (when pc-mode (funcall pc-mode 1)
Re: [O] [Bug] Doc string for org-clock-into-drawer truncated?
Carsten Dominik writes: >> For symmetry it seems that one should be able to specify a property >> CLOCK_INTO_DRAWER specifically for clocking or fall back onto LOG_INTO >> DRAWER, just like the customization variables allow one to do. > > > This does make sense, can you make a patch? I've had a closer look at the code and would think yes, hopefully I'll find a hour or two to work on this over the weekend. 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] [babel] How to set multiple variables with properties
One of the things I tried (that didn't work, otherwise I would not have sent any e-mail) was :PROPERTY: :var: variable1="value1" :var variable2="value2" :END: I thought that maybe babel would just ask org what is the value of :var:, put ":var" before it, and include this in the block header. Therefore I would get the effect of adding ":var variable1="value1" :var variable2="value2"" in the block header and it could work. However, even if this method had worked It would not be flexible. One of the nice things about properties is inheritance. I would like to define "general variables" as properties in level-1 headings and define more specific variables in the sub-headings as necessary. However, if babel always use :var: as the property then defining a variable in a subheading will overwrite the upper level variable. The best option in my use-case-scenario would be some name scheme to identify variable definitions for org-babel. For instance --8<---cut here---start->8--- :PROPERTY: :ob-someVariable: "some string maybe with\nline breaks" :ob-someOtherVariable: 123456 :END: --8<---cut here---end--->8--- would make the variables "someVariable" and "someOtherVariable" known to org-babel. -- Darlan Cavalcante At Wed, 22 Jun 2011 20:27:00 +0200, Christian Moe wrote: > > Hi again, > > I was referring to these functions: > - org-entry-put-multivalued-property > - org-entry-get-multivalued-property > - org-entry-add-to-multivalued-property > - org-entry-remove-from-multivalued-property > - org-entry-member-in-multivalued-property > described here: > http://orgmode.org/manual/Using-the-property-API.html > > I've found a few discussions: > - http://comments.gmane.org/gmane.emacs.orgmode/33457 > - http://lists.gnu.org/archive/html/emacs-orgmode/2010-02/msg00251.html > > I don't have anything working with them, as such,[1] and I was curious > if anyone did. They don't currently seem to be integrated into > completion, search functions, Babel, and so on, which would limit > their usefulness (though searching can be done with regexps). And I > think implementing wider support for them would run into a problem > with distinguishing between properties that are meant to be > multivalued, or and properties that just contain a single value which > happens to contain spaces. > > But handling multiple var=value expressions in a :var: property for > Babel, as Darlan asked about, might perhaps be doable...? Stuff might > break, though. > > Yours, > Christian > > > [1] I do have a small research database with some "multivalued" > properties in it. For queries, I use your org-collector and regular > expression matching against properties with multiple values. The > multivalued-properties functions didn't really come into it, except > that knowing they were there made me go ahead and put multiple values > in one property. (As it turned out, that wasn't a very good design > choice.) > > On 6/21/11 11:03 PM, Eric Schulte wrote: > > Hi Christian, > > > > That's the first I've heard of that variable? If you do get something > > working with multivalued properties please do share. > > > > Cheers -- Eric > > > > Christian Moe writes: > > > >> Hi, Eric, > >> > >> Just curious: What about the org-entry--multivalued-property functions > >> mentioned in "Using the properties API"? > >> > >> Is anybody using multivalued properties for anything? > >> > >> Yours, > >> Christian > >> > >> > >> On 6/21/11 10:17 PM, Eric Schulte wrote: > >>> Unfortunately org-mode properties only allow a single entry for any > >>> given key, so you can only specify one variable using properties. > >>> > >>> However the following workaround does exist. > >>> > >>> *** alternative > >>> :PROPERTIES: > >>> :var: vars=variables > >>> :END: > >>> > >>> #+tblname: variables > >>> | var1 | 1 | > >>> | var2 | 2 | > >>> > >>> #+begin_src python > >>> print vars[0][1] > >>> print vars[1][1] > >>> #+end_src > >>> > >>> Best -- Eric > >>> > >>> Darlan Cavalcante Moreira writes: > >>> > I'm using org-babel to automate a few tasks and I'd like to define a few > variables that are common to several code blocks as sub-tree properties. > > It works when I have only one variable, where I can use > * Heading > :PROPERTY: > :var: variable1="value1" > :END: > #+begin_src python :results output > print variable1 > #+end_src > > #+results: > : value1 > > Is it possible to set multiples variables in this way? > I tried things like > :PROPERTY: > :var: variable1="value1" variable2="value2" > :END: > > :PROPERTY: > :var: variable1="value1",variable2="value2" > :END: > > :PROPERTY: > :variable1: "value1" > :variable2: "value2" > :END: > but none of them worked. > > >>>
[O] how to turn off capitalization
Ive just found that org is capitalizing my titles in html export. [I had not noticed this earlier] I would like to capitalize my titles slightly differently: for example propositions like 'to' 'with' etc I would like to leave as lowercase. Is it possible to turn off capitalization of titles?
[O] A new org-mode release for Emacs 24.1
It seems it has been a long time since last release. Any plan to update the orgmode included in Emacs upstream? Thanks. Leo
Re: [O] A new org-mode release for Emacs 24.1
Leo wrote: > It seems it has been a long time since last release. Any plan to update > the orgmode included in Emacs upstream? Thanks. > Yes - there was a short discussion a few days ago on the ML: Quaerendo invenietis. Nick
Re: [O] [babel] using #+call for inline results
Eric S Fraga writes:
> Eric Schulte writes:
>
>> Hi Eric,
>
> Hi Eric! ;-)
>
>> So the problem is that the results are inserted as a separate block,
>> when you want them to be inserted inline? If so perhaps using an
>> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
>> would result in the desired behavior.
>>
>> Please let me know if I've misunderstood the question.
>
> Yes and no. I *do* want the effect that is achieved by using an inline
> block but I do *not* want to write the whole block inline
I find the following pattern
#+source: big-block
#+begin_src emacs-lisp :exports none
"something complex"
#+end_src
Here is some text with src_emacs-lisp[:var it=big-block]{it} in the
middle.
to be helpful in these situations.
> as that can be difficult to do or, at the very best, hard to read even
> if possible... I would like to invoke/evaluate, inline, a particular
> source code block with a specific value of an argument.
>
> From the documentation, I don't see how to "call" a src block inline.
> That's why I thought of using =#+call=. Am I missing something?
>
nope, there is no way to issue an in-line call, although maybe this
wouldn't be the worst idea if only for the added brevity over an inline
code block.
I'll put it on my long-term low-priority stack. :)
Cheers -- Eric
>
> Thanks,
> eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
