Re: [O] (message "Greedy org-protocol handler. Killing client.")
Samuel Wales writes: > org-protocol works less than half the time now. > > i try it with the org-capture firefox extension on iceweasel. i also > try it with a manual bookmark created by some instruction somewhere. > > today every click puts this in my messages buffer: > > "Greedy org-protocol handler. Killing client." > > could somebody please explain what this means? i do not understand the code. org-protocol works by advising `server-visit-files' in an obsolete way. I encountered this problem this week when I tried to advice `server-done' to do something clever with Itsalltext. It seems the `defadvice' on `server-visit-files' is incompatible with any other advice in that vicinity. I would get "Greedy org-protocol handler. Killing client." when I advised `server-done'. This error would disappear immediately after I disabled the advice. So I suggest examining your custom advises. And see if disabling some of them fixes the problem. And maybe someone could look into using something better than `defadvice' in org-protocol.el. Oleh
Re: [O] "No link found" for after <2016-02-21 Sun>
Hello, Josef Atmin writes: > So there remains my wishlist item, namely that typing after a > link results in a newline rather than activation of the link. I would > find it much better if only a on the link would activate it, > because I am often in the situation where I am at the end of a line > and I want to insert a newline, but because there is a link at the end > of the line right before the curser (not at the cursor), the link is > activated, which is mostly harmless but anoying. To avoid that, I > have to either first tiype a and then a or first > Ctrl-o and then . But it is hard for me to always be aware of > the link and change my automatism of simply typing . AFAIR, this was also fixed in the same commit. Regards, -- Nicolas Goaziou
Re: [O] "No link found" for after <2016-02-21 Sun>
Dear Nicolas, that would be great. Thanks for letting me know. Josef. On Wed, Feb 24, 2016 at 11:58:16AM +0100, Nicolas Goaziou wrote: > Hello, > > Josef Atmin writes: > > > So there remains my wishlist item, namely that typing after a > > link results in a newline rather than activation of the link. I would > > find it much better if only a on the link would activate it, > > because I am often in the situation where I am at the end of a line > > and I want to insert a newline, but because there is a link at the end > > of the line right before the curser (not at the cursor), the link is > > activated, which is mostly harmless but anoying. To avoid that, I > > have to either first tiype a and then a or first > > Ctrl-o and then . But it is hard for me to always be aware of > > the link and change my automatism of simply typing . > > AFAIR, this was also fixed in the same commit. > > > Regards, > > -- > Nicolas Goaziou
[O] orgtbl-insert-radio-table, latex and org-time-stamp-custom-formats
Hello
I use from time to time in my latex files orgtbl-mode and
orgtbl-insert-radio-table (since org-time-stamp does not work in
orgtbl-mode I insert the stamps in a org file and then copy the content
into the radio table. However
the format
<2016-02-24 Wed>
Is not suited for LaTeX: < generates a ?
There are at least two solutions:
- use the format $<2016-02-24 Wed>$
- or «2016-02-24 Wed»
Now I used (customize-option (quote org-time-stamp-custom-formats))
and set it to ("«%m/%d/%y %a»" . "«%m/%d/%y %a %H:%M»")
but it had no effect so far.
Any comments?
Thanks
Uwe Brauer
[O] format of orgtbl-insert-table: format {|l|l|} and longtabu
% BEGIN RECEIVE ORGTBL test
\begin{tabular}{ll}
Name & Date\\ \hline
Joe Doe & «2016-02-24 Wed»\\ \hline
\end{tabular}
% END RECEIVE ORGTBL test
\begin{comment}
#+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline"
| Name| Date |
| Joe Doe | «2016-02-24 Wed» |
\end{comment}
This is the usual setting, but I would like to obtain the following
% BEGIN RECEIVE ORGTBL test
\begin{longtabu}{|l|l|}
\hline
Name & Date\\ \hline
Joe Doe & «2016-02-24 Wed»\\ \hline
\end{longtabu}
% END RECEIVE ORGTBL test
\begin{comment}
#+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline"
| Name| Date |
| Joe Doe | «2016-02-24 Wed» |
\end{comment}
How can I obtain it?
Thanks
Uwe Brauer
Re: [O] orgtbl-insert-radio-table, latex and org-time-stamp-custom-formats
Hello,
Uwe Brauer writes:
> I use from time to time in my latex files orgtbl-mode and
> orgtbl-insert-radio-table (since org-time-stamp does not work in
> orgtbl-mode I insert the stamps in a org file and then copy the content
> into the radio table. However
> the format
> <2016-02-24 Wed>
>
> Is not suited for LaTeX: < generates a ?
>
> There are at least two solutions:
>
> - use the format $<2016-02-24 Wed>$
>
> - or «2016-02-24 Wed»
>
> Now I used (customize-option (quote org-time-stamp-custom-formats))
> and set it to ("«%m/%d/%y %a»" . "«%m/%d/%y %a %H:%M»")
> but it had no effect so far.
>
> Any comments?
What is the value of `org-display-custom-times'?
Regards,
--
Nicolas Goaziou
Re: [O] format of orgtbl-insert-table: format {|l|l|} and longtabu
Hello,
Uwe Brauer writes:
> This is the usual setting, but I would like to obtain the following
>
> % BEGIN RECEIVE ORGTBL test
> \begin{longtabu}{|l|l|}
> \hline
> Name & Date\\ \hline
> Joe Doe & «2016-02-24 Wed»\\ \hline
> \end{longtabu}
> % END RECEIVE ORGTBL test
> \begin{comment}
> #+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline"
> | Name| Date |
> | Joe Doe | «2016-02-24 Wed» |
> \end{comment}
>
>
> How can I obtain it?
#+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline" :environment
longtabu
| / | <> | <> |
| | Name| Date |
| | Joe Doe | «2016-02-24 Wed» |
Regards,
--
Nicolas Goaziou
Re: [O] Cannot export bash src: more details
On Tuesday, 23 Feb 2016 at 10:54, Giuseppe Lipari wrote: [...] > byte-code: Invalid search bound (wrong side of point) I have also run into this problem lately (well, early last week or the week before that) with src blocks that work just fine if moved to another place. Drove me crazy trying to debug this and got nowhere other than I found that adding some text before and/or after the src block made things work. Like you, coming up with an ECM has proven impossible. My case was also a complex file. Sorry that I cannot help directly but just wanted you to know that there is a problem somewhere in current org... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa
Re: [O] "atomic knowledge" modeling tool
On Monday, 22 Feb 2016 at 10:04, Samuel Loury wrote: [...] > Reproducing a slow behavior is not easy. Today, the agenda is produced > in about 10s with almost the same contents. I included the profiler > report anyway, hoping that you will find something useful in it. > > - command-execute3301 91% [...] >- ad-Advice-org-agenda2868 79% > - # 1922 53% > - byte-code 1922 53% out of curiousity, what or how are you advising org-agenda? also, the profile information would be most useful without compiled code (although obviously slower...). -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa
Re: [O] format of orgtbl-insert-table: format {|l|l|} and longtabu
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> This is the usual setting, but I would like to obtain the following
>>
>> % BEGIN RECEIVE ORGTBL test
>> \begin{longtabu}{|l|l|}
>> \hline
>> Name & Date\\ \hline
>> Joe Doe & «2016-02-24 Wed»\\ \hline
>> \end{longtabu}
>> % END RECEIVE ORGTBL test
>> \begin{comment}
>> #+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline"
>> | Name| Date |
>> | Joe Doe | «2016-02-24 Wed» |
>> \end{comment}
>>
>>
>> How can I obtain it?
> #+ORGTBL: SEND test orgtbl-to-latex :lend " \\hline" :environment
longtabu
> | / | <> | <> |
> | | Name| Date |
> | | Joe Doe | «2016-02-24 Wed» |
> Regards,
Thanks this is very useful, but still some tiny bit is missing.
I obtain
% BEGIN RECEIVE ORGTBL this
\begin{longtabu}{l|l|}
hallo & this\\ \hline
\end{longtabu}
% END RECEIVE ORGTBL this
\begin{comment}
#+ORGTBL: SEND this orgtbl-to-latex :lend " \\hline" :environment longtabu
| / | <> |
| hallo | this |
\end{comment}
But would prefer to obtain one | and one \hline more as in
% BEGIN RECEIVE ORGTBL this
\begin{longtabu}{|l|l|}
\hline
hallo & this\\ \hline
\end{longtabu}
% END RECEIVE ORGTBL this
\begin{comment}
#+ORGTBL: SEND this orgtbl-to-latex :lend " \\hline" :environment longtabu
| / | <> |
| hallo | this |
\end{comment}
The additional \hline I can generate via
% BEGIN RECEIVE ORGTBL this
\begin{longtabu}{l|l|}
\hline
hallo & this\\ \hline
\end{longtabu}
% END RECEIVE ORGTBL this
\begin{comment}
#+ORGTBL: SEND this orgtbl-to-latex :lend " \\hline" :environment longtabu
| / | <> |
|---+--|
| hallo | this |
\end{comment}
But I don't know how to obtain
\begin{longtabu}{|l|l|}
Thanks
Uwe Brauer
Re: [O] * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Hello, Josef Atmin writes: >> when a shell command in an unnumbered list includes '::', it is not >> recognized as a shell >> command anymore. >> >> To reproduce the bug, paste the following two lines in file 'tmp' >> >> asdf :: asdf >> asdf :: qwer >> >> and add the following shell commands to an org file >> >>* [[shell:cat ~/tmp | grep "asdf :"]] >>* [[shell:cat ~/tmp | grep "asdf ::"]] >>* [[shell:cat ~/tmp | grep "asdf :: "]] >> >> If you klick on them you will probably find that the first two work while >> the last one >> does not, presumably because it is interpreted as a description list entry. >> Interestingly, if you use a numbered list >> >>1. [[shell:cat ~/tmp | grep "asdf :"]] >>2. [[shell:cat ~/tmp | grep "asdf ::"]] >>3. [[shell:cat ~/tmp | grep "asdf :: "]] >> >> then all three work. This is not a bug. - :: *is* description list syntax, no matter how you look at it. You can easily work around this, e.g., by starting the link on the next line. Regards, -- Nicolas Goaziou
[O] bug#22735: please close 22735 (i would like to replace it with 22776)
Hello, David Caldwell writes: > After more experimentation, I got a better understanding of the > functionality and now consider bug 22735 to be invalid as written. I > now think it's a more fundamental issue of not handling an Effort_ALL > with more than 10 entries. > > That issue is documented in bug #22776(interactive org-set-effort (C-c > C-x e) and column view direct index selection do not handle Effort_ALL > with more than 10 entries). I made some substantial changes to Column view recently. I think this issue is fixed already. Regards, -- Nicolas Goaziou
Re: [O] format of orgtbl-insert-table: format {|l|l|} and longtabu
Hello,
Uwe Brauer writes:
> But I don't know how to obtain
>
> \begin{longtabu}{|l|l|}
Like this:
| / | <>| <> |
| | hallo | this |
Notice the empty special column at the beginning.
Regards,
--
Nicolas Goaziou
Re: [O] orgtbl-insert-radio-table, latex and org-time-stamp-custom-formats
> Hello, > Uwe Brauer writes: > What is the value of `org-display-custom-times'? Nil > Regards, thanks Uwe
Re: [O] (message "Greedy org-protocol handler. Killing client.")
thank you. i don't have any defadvice on anything server-related, or anything likely to be called by a library. does that also count? On 2/24/16, Oleh Krehel wrote: >> org-protocol works less than half the time now. > So I suggest examining your custom advises. And see if disabling some of > them fixes the problem. And maybe someone could look into using > something better than `defadvice' in org-protocol.el. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Nicolas Goaziou writes: > Hello, > > Josef Atmin writes: > >>> when a shell command in an unnumbered list includes '::', it is not >>> recognized as a shell >>> command anymore. >>> >>> To reproduce the bug, paste the following two lines in file 'tmp' >>> >>> asdf :: asdf >>> asdf :: qwer >>> >>> and add the following shell commands to an org file >>> >>>* [[shell:cat ~/tmp | grep "asdf :"]] >>>* [[shell:cat ~/tmp | grep "asdf ::"]] >>>* [[shell:cat ~/tmp | grep "asdf :: "]] >>> >>> If you klick on them you will probably find that the first two work while >>> the last one >>> does not, presumably because it is interpreted as a description list entry. >>> Interestingly, if you use a numbered list >>> >>>1. [[shell:cat ~/tmp | grep "asdf :"]] >>>2. [[shell:cat ~/tmp | grep "asdf ::"]] >>>3. [[shell:cat ~/tmp | grep "asdf :: "]] >>> >>> then all three work. > > This is not a bug. - :: *is* description list syntax, no matter how > you look at it. You can easily work around this, e.g., by starting the > link on the next line. > Count me confused - although the OP is talking about unnumbered lists, his example only has headlines and numbered lists. Is the link broken when in the headline or only when it's an unnumbered list item? -- nick
Re: [O] format of orgtbl-insert-table: format {|l|l|} and longtabu
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> But I don't know how to obtain
>>
>> \begin{longtabu}{|l|l|}
> Like this:
> | / | <>| <> |
> | | hallo | this |
> Notice the empty special column at the beginning.
Cool!! Thanks very much
Re: [O] * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Hello, Nick Dokos writes: > Nicolas Goaziou writes: > >> Josef Atmin writes: >> when a shell command in an unnumbered list includes '::', it is not recognized as a shell command anymore. To reproduce the bug, paste the following two lines in file 'tmp' asdf :: asdf asdf :: qwer and add the following shell commands to an org file * [[shell:cat ~/tmp | grep "asdf :"]] * [[shell:cat ~/tmp | grep "asdf ::"]] * [[shell:cat ~/tmp | grep "asdf :: "]] If you klick on them you will probably find that the first two work while the last one does not, presumably because it is interpreted as a description list entry. Interestingly, if you use a numbered list 1. [[shell:cat ~/tmp | grep "asdf :"]] 2. [[shell:cat ~/tmp | grep "asdf ::"]] 3. [[shell:cat ~/tmp | grep "asdf :: "]] then all three work. >> >> This is not a bug. - :: *is* description list syntax, no matter how >> you look at it. You can easily work around this, e.g., by starting the >> link on the next line. >> > > Count me confused - although the OP is talking about unnumbered lists, > his example only has headlines and numbered lists. Is the link broken > when in the headline or only when it's an unnumbered list item? IIUC, the OP is using unnumbered lists with an asterisk bullet. Hence, the problem is probably limited to unnumbered lists, not headlines. Regards, -- Nicolas Goaziou
Re: [O] * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Nicolas Goaziou writes: >> Count me confused - although the OP is talking about unnumbered lists, >> his example only has headlines and numbered lists. Is the link broken >> when in the headline or only when it's an unnumbered list item? > > IIUC, the OP is using unnumbered lists with an asterisk bullet. Hence, > the problem is probably limited to unnumbered lists, not headlines. > A (light dawns...) Thanks! -- Nick
Re: [O] bug report: "File mode specification error: (error "before first heading")
On Thursday, 18 Feb 2016 at 15:24, ilya shlyakhter wrote: > When loading any org file, I'm getting "File mode specification error: > (error "before first heading")" . This happens starting with > release_8.3.3 ; with release_8.3.2 , no error. Emacs version is > GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.6) of > 2015-03-26 on scs-build-rhel6 . Maybe M-x toggle-debug-on-error RET and then try again? This may give you a hint. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa
[O] what happened to :wrap HTML ?
Hello, I used to generate html code with a python script using org-babel, like this: %--- example.org -% * This is an example of export in HTML #+BEGIN_SRC python :exports results :results output :wrap HTML print " first item" print " second item " print "" #+END_SRC %--- example.org -% This used to work just fine and produce a nice unordered list in html. Until the moment I updated to the current development version: Org-mode version 8.3.4 (release_8.3.4-588-g924431 @ /home/lipari/elisp/org-mode/lisp/) Now, it produces the attached screenshot: [image: snapshot-org1.jpg] Hence my question: what happened to ":wrap HTML" ?? Is there an equivalent way to express the same behaviour as before? Giuseppe Lipari
Re: [O] Cannot export bash src: more details
Hello, thank you, although for the moment it does not help. Unfortunately I have *a lot* of old slides that I am correcting and regenerating step by step. They used to compile just fine with the previous version, and now this strange problem make me lose a lot of time just for changing indentation... Maybe I should just revert to the old version of org. I will tell you if I find a somehow smaller example. Giuseppe Lipari Le mer. 24 févr. 2016 à 18:30, Eric S Fraga a écrit : > On Tuesday, 23 Feb 2016 at 10:54, Giuseppe Lipari wrote: > > [...] > > > byte-code: Invalid search bound (wrong side of point) > > I have also run into this problem lately (well, early last week or the > week before that) with src blocks that work just fine if moved to > another place. Drove me crazy trying to debug this and got nowhere > other than I found that adding some text before and/or after the src > block made things work. > > Like you, coming up with an ECM has proven impossible. My case was also > a complex file. > > Sorry that I cannot help directly but just wanted you to know that there > is a problem somewhere in current org... > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa >
Re: [O] what happened to :wrap HTML ?
Giuseppe Lipari writes: > Hello, > > I used to generate html code with a python script using org-babel, like this: > > %--- example.org -% > * This is an example of export in HTML > #+BEGIN_SRC python :exports results :results output :wrap HTML > print " first item" > print " second item " > print "" > #+END_SRC > %--- example.org -% > > This used to work just fine and produce a nice unordered list in html. Until > the moment I updated to the > current development version: > > Org-mode version 8.3.4 (release_8.3.4-588-g924431 @ > /home/lipari/elisp/org-mode/lisp/) > > Now, it produces the attached screenshot: > > snapshot > > Hence my question: what happened to ":wrap HTML" ?? Is there an equivalent > way to express the same > behaviour as before? > I bet :wrap HTMP produces #+BEGIN_HTML ... #+END_HTML instead of #+BEGIN_EXPORT HTML #+END_EXPORT -- Nick
Re: [O] what happened to :wrap HTML ?
Hello, Nick Dokos writes: > Giuseppe Lipari writes: > >> Hello, >> >> I used to generate html code with a python script using org-babel, like this: >> >> %--- example.org -% >> * This is an example of export in HTML >> #+BEGIN_SRC python :exports results :results output :wrap HTML >> print " first item" >> print " second item " >> print "" >> #+END_SRC >> %--- example.org -% >> >> This used to work just fine and produce a nice unordered list in html. Until >> the moment I updated to the >> current development version: >> >> Org-mode version 8.3.4 (release_8.3.4-588-g924431 @ >> /home/lipari/elisp/org-mode/lisp/) >> >> Now, it produces the attached screenshot: >> >> snapshot >> >> Hence my question: what happened to ":wrap HTML" ?? Is there an equivalent >> way to express the same >> behaviour as before? >> > > I bet :wrap HTMP produces > > #+BEGIN_HTML > ... > #+END_HTML > > instead of > > #+BEGIN_EXPORT HTML > #+END_EXPORT So I guess the OP should write :wrap export HTML. We could also add the export part automatically, but that would limit the value of the parameter (e.g., impossible to do anything else than export blocks) Regards, -- Nicolas Goaziou
Re: [O] what happened to :wrap HTML ?
Nicolas Goaziou writes: > Hello, > > Nick Dokos writes: > >> Giuseppe Lipari writes: >> >>> Hello, >>> >>> I used to generate html code with a python script using org-babel, like >>> this: >>> >>> %--- example.org -% >>> * This is an example of export in HTML >>> #+BEGIN_SRC python :exports results :results output :wrap HTML >>> print " first item" >>> print " second item " >>> print "" >>> #+END_SRC >>> %--- example.org -% >>> >>> This used to work just fine and produce a nice unordered list in >>> html. Until the moment I updated to the >>> current development version: >>> >>> Org-mode version 8.3.4 (release_8.3.4-588-g924431 @ >>> /home/lipari/elisp/org-mode/lisp/) >>> >>> Now, it produces the attached screenshot: >>> >>> snapshot >>> >>> Hence my question: what happened to ":wrap HTML" ?? Is there an equivalent >>> way to express the same >>> behaviour as before? >>> >> >> I bet :wrap HTMP produces >> >> #+BEGIN_HTML >> ... >> #+END_HTML >> >> instead of >> >> #+BEGIN_EXPORT HTML >> #+END_EXPORT > > So I guess the OP should write :wrap export HTML. > > We could also add the export part automatically, but that would limit > the value of the parameter (e.g., impossible to do anything else than > export blocks) We need to allow special blocks. But the question is whether we can "guess" when something is a backend and do the right thing. It’s probably a "can of worms" to try to guess. Rasmus -- Nothing's wrong with an email that ends in a minor key
[O] streamlined capture on iphone
MobileOrg on the iPhone is not very useful to me. As many people do, I use my iPhone as a way to capture input on the go, usually in the form of short text snippets or notes. One thing that has made this work better for me is a streamlined process for getting the text into Org via org-feed. My preferred iOS text editor is Drafts 4 ($10) because it allows custom actions to be performed in a single tap. I have one action in Drafts that emails the current note to my gmail account. Any iOS editor that can share notes via email will work. But Drafts is particularly convenient because the customized action takes care of addressing and sending the message with one tap. Using a filter, gmail applies the label "capture" to each note sent from Drafts. The magic happens through a Google script that I found, modified, and adapted that takes all messages with a specific label in Gmail and turns them into an Atom feed. The script runs on Google's servers, constantly scanning for new messages with the "capture" label. The resulting Atom feed is served up by Google via a URL (non-secure, but quite obscure) that I use with org-feed. My Org is set up to check the feed for new posts every 5 minutes or so, grab them and put them as headlines into capture.org. When I start up Org, I tag and refile new items from capture.org into an appropriate file such as actions.org or projects.org. This workflow automates the whole capture process as much as possible. If anyone is interested in the Drafts action, Gmail filter, Google script, and org-feed configuration that make this work, I would be happy to share. This setup can easily be adapted for Android phones.
[O] How to stop () or [] from messing up text color
Hello - As soon as I put braces or parens in a heading the rest of the line turns black. Adding a priority can trigger this. The black text after the braces shows as being the default face not an org mode face. Is there any workaround for this? Thanks Roman
Re: [O] How to stop () or [] from messing up text color
Hello, Roman Milner writes: > > As soon as I put braces or parens in a heading the rest of the line turns > black. Adding a priority can trigger this. > > The black text after the braces shows as being the default face not an org > mode face. I cannot reproduce it. Regards, -- Nicolas Goaziou
Re: [O] How to stop () or [] from messing up text color
Can you tell me what version of org you are on? I'm on 8.3.3. Thanks Roman On Feb 24, 2016 5:03 PM, "Nicolas Goaziou" wrote: > Hello, > > Roman Milner writes: > > > > As soon as I put braces or parens in a heading the rest of the line turns > > black. Adding a priority can trigger this. > > > > The black text after the braces shows as being the default face not an > org > > mode face. > > I cannot reproduce it. > > > Regards, > > -- > Nicolas Goaziou >
Re: [O] How to stop () or [] from messing up text color
Roman Milner writes: > Can you tell me what version of org you are on? I'm on 8.3.3. Development version (i.e, git HEAD). Regards,
[O] [ANN] Small improvements in Columns view
Hello,
It is now possible to use custom summaries in Columns view, and re-use
the same property in multiple columns.
In the latter situation, the first columns referencing the property
determines how the values for that property are to be computed.
The following example illustrates these features:
(defun my-Med (values printf)
(let ((v (sort (mapcar #'string-to-number values) #'<))
(l (length values)))
(number-to-string
(if (= (% l 2) 1) (nth (floor l 2) v)
(let ((m (/ l 2)))
(/ (+ (nth m v) (nth (1+ m) v)) 2.0))
(defun my-Q1 (values printf)
(number-to-string
(nth (floor (length values) 4)
(sort (mapcar #'string-to-number values) #'<
(defun my-Q3 (values printf)
(number-to-string
(nth (floor (* (length values) 0.75))
(sort (mapcar #'string-to-number values) #'<
(add-to-list 'org-columns-summary-types '("Med" . my-Med))
(add-to-list 'org-columns-summary-types '("Q1" . my-Q1))
(add-to-list 'org-columns-summary-types '("Q3" . my-Q3))
#+COLUMNS: %ITEM %VALUE(Min){min} %VALUE(Q1){Q1} %VALUE(Med){Med}
%VALUE(Q3){Q3} %VALUE(Max){max}
* H
** S1
:PROPERTIES:
:VALUE: 2
:END:
** S2
:PROPERTIES:
:VALUE: 1
:END:
** S3
:PROPERTIES:
:VALUE: 9
:END:
** S4
:PROPERTIES:
:VALUE: 7
:END:
Feedback welcome.
Regards,
--
Nicolas Goaziou0x80A93738
Re: [O] * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
* Since your situation, is one like this: "This is not a bug. - :: *is* description list syntax"--i.e. you are grep-ing for what Emacs Org-Mode is seeing as a "description list"; and, this is "by design" e.g.: * Lord of the Rings - Elijah Wood :: He plays Frodo - Sean Astin :: He plays Sam, Frodo's friend. I still remember him very well from his role as Mikey Walsh in The Goonies. ** In such a case: I reiterate my earlier suggestion--and my opinion is one should always strive to do it this way too--its POSIX compliant--its easier to read and you won't run into inconsistencies in your code: Suggest you do it this way instead: Use "POSIX character classes" like [:blank:] whenever possible--so in this case you could try to do something like this (you'd have to test it yourself--if you're still interested--again my environment throws no error exceptions): ** In your shell: export BLANK="[[:blank:]]" ** Then load your Emacs OrgMode buffer as you did before; and, try something like this instead: * [[shell:cat ~/tmp | grep "asdf :"]] * [[shell:cat ~/tmp | grep "asdf ::"]] * [[shell:cat ~/tmp | grep "asdf$BLANK::$BLANK]] --again, this all worked for me--but they all worked for me before too while yours failed ** Say, anyone no how to do something like this: export PIPE="|" * [[shell:cat ~/tmp $PIPE grep "asdf ::"]] ---I mean, does anyone know how to use some other character or whatever instead of "|" within the "[[...]]"?---I often find myself wanting to insert a pipe in there and then put the whole thing in an OrgTable cell--but we all know "|" is the cell divider in OrgMode ** Or does anyone know how to easily change the OrgTable cell barrier to a key other than "|"? (then I could freely use the "|" in an OrgTable cell) On Wed, Feb 24, 2016 at 2:53 PM, Nick Dokos wrote: > Nicolas Goaziou writes: > > >> Count me confused - although the OP is talking about unnumbered lists, > >> his example only has headlines and numbered lists. Is the link broken > >> when in the headline or only when it's an unnumbered list item? > > > > IIUC, the OP is using unnumbered lists with an asterisk bullet. Hence, > > the problem is probably limited to unnumbered lists, not headlines. > > > > A (light dawns...) > > Thanks! > > -- > Nick > > > >
