[O] [RFC] [PATCH] Introduce org-specific functions for (next/previous)-visible-heading

[Aaron Ecay]

Hello,

By default, org uses outline-next-visible-heading and the -previous-
variant for the C-c C-n and C-c C-p keys, which means these commands
stop on inline tasks (since they don’t know to skip them).  This seems
incorrect.

The attached patch adds inlinetask-aware org functions for these keys.
Comments are welcome.

Thanks,
>From e3a61ab42c6e3d411a955473535bac80d69e9d7e Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Sun, 18 Jan 2015 23:57:55 -0500
Subject: [PATCH] Add new functions to move to the next/prev headline skipping
 inline tasks.

* lisp/org.el (org-next-visible-heading):
(org-previous-visible-heading): New functions.
(org-speed-commands-default, org-mode-map): Use them.
---
 lisp/org.el | 67 +
 1 file changed, 45 insertions(+), 22 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1222a69..2e0335c 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19420,34 +19420,38 @@ boundaries."
 (define-key org-mode-map [remap outline-promote] 'org-promote-subtree)
 (define-key org-mode-map [remap outline-demote] 'org-demote-subtree)
 (define-key org-mode-map [remap outline-insert-heading] 'org-ctrl-c-ret)
+(define-key org-mode-map [remap outline-next-visible-heading]
+  'org-next-visible-heading)
+(define-key org-mode-map [remap outline-previous-visible-heading]
+  'org-previous-visible-heading)
 
 ;; Outline functions from `outline-mode-prefix-map' that can not
 ;; be remapped in Org:
-;;
+
 ;; - the column "key binding" shows whether the Outline function is still
 ;;   available in Org mode on the same key that it has been bound to in
 ;;   Outline mode:
 ;;   - "overridden": key used for a different functionality in Org mode
 ;;   - else: key still bound to the same Outline function in Org mode
-;;
-;; | Outline function   | key binding | Org replacement   |
-;; |+-+---|
-;; | `outline-next-visible-heading' | `C-c C-n'   | still same function   |
-;; | `outline-previous-visible-heading' | `C-c C-p'   | still same function   |
-;; | `outline-up-heading'   | `C-c C-u'   | still same function   |
-;; | `outline-move-subtree-up'  | overridden  | better: org-shiftup   |
-;; | `outline-move-subtree-down'| overridden  | better: org-shiftdown |
-;; | `show-entry'   | overridden  | no replacement|
-;; | `show-children'| `C-c C-i'   | visibility cycling|
-;; | `show-branches'| `C-c C-k'   | still same function   |
-;; | `show-subtree' | overridden  | visibility cycling|
-;; | `show-all' | overridden  | no replacement|
-;; | `hide-subtree' | overridden  | visibility cycling|
-;; | `hide-body'| overridden  | no replacement|
-;; | `hide-entry'   | overridden  | visibility cycling|
-;; | `hide-leaves'  | overridden  | no replacement|
-;; | `hide-sublevels'   | overridden  | no replacement|
-;; | `hide-other'   | overridden  | no replacement|
+
+;; | Outline function   | key binding | Org replacement  |
+;; |+-+--|
+;; | `outline-next-visible-heading' | `C-c C-n'   | better: skip inlinetasks |
+;; | `outline-previous-visible-heading' | `C-c C-p'   | better: skip inlinetasks |
+;; | `outline-up-heading'   | `C-c C-u'   | still same function  |
+;; | `outline-move-subtree-up'  | overridden  | better: org-shiftup  |
+;; | `outline-move-subtree-down'| overridden  | better: org-shiftdown|
+;; | `show-entry'   | overridden  | no replacement   |
+;; | `show-children'| `C-c C-i'   | visibility cycling   |
+;; | `show-branches'| `C-c C-k'   | still same function  |
+;; | `show-subtree' | overridden  | visibility cycling   |
+;; | `show-all' | overridden  | no replacement   |
+;; | `hide-subtree' | overridden  | visibility cycling   |
+;; | `hide-body'| overridden  | no replacement   |
+;; | `hide-entry'   | overridden  | visibility cycling   |
+;; | `hide-leaves'  | overridden  | no replacement   |
+;; | `hide-sublevels'   | overridden  | no replacement   |
+;; | `hide-other'   | overridden  | no replacement   |
 
 ;; Make `C-c C-x' a prefix key
 (org-defkey org-mode-map "\C-c\C-x" (make-sparse-keymap))
@@ -19687,8 +19691,8 @@ boundaries."
 (defconst org-speed-commands-default
   '(
 ("Outline Navigation")
-("n" . (org-speed-mo

Re: [O] Table calculations with hline references

[Aaron Ecay]

Hi Daniel,

What version of org are you using?  Using a hline-relative reference on
the lhs of a formula is not allowed in the current development version
of org (i.e. the master branch).  Presumably because it doesn’t work
correctly, as you have discovered.

The patch to prevent this was made over a year ago (2013-11-05).  However,
as far as I can tell it has not been in any released version of org.  I
tried to ascertain this using the command:

git tag --contains a2c71a6

Which returns only:

beta_8.3
release_8.3beta

Sorry that there’s not a more satisfying answer,

-- 
Aaron Ecay

[O] [OT] org-caldav and radicale

[Eric Abrahamsen]

I'm finally getting around to trying to have an Org-generated calendar
available on my Android tablet. I looked at a few caldav servers, and
settled on Radicale as looking like about the right level of
usability/configurability.

I don't think I'm doing it right, and can't find any examples online.
Can someone who's doing this (I know there are some of you) just show me
the basic configuration? Specifically, how do I create a new calendar on
the server, and how do I refer to it? My Radicale config has this:

[storage]
type = filesystem
filesystem_folder = /home/eric/apps/cal/collections

If I touch a file called "eric" in the "collections" directory, and then
access the server via HTTP (ie http://cal.myserver.com/eric), the file
is correctly served as an (empty) calendar and downloaded by my browser.

How do I get org-caldav to mesh with that? I thought this would do it:

(setq org-caldav-url "http://cal.myserver.com";)
(setq org-caldav-calendar-id "eric")

But when I call `org-caldav-sync' it first collects all the headings
it's supposed to, and then gives me:

org-caldav-get-event-etag-list: Error while getting eventlist from
http://cal.myserver.com/eric/. Got status code: 207.

If I run it again, it offers to delete all the relevant Org headings.

I suspect I've just got something configured wrong, but can't think of
what. Any pointers?

Thanks!
Eric

Re: [O] org-download.el

[Chao Lu]

Hi Oleh,

Thanks a lot for the detailed instruction again, and the screencast is a
good job as well! I just did the testing. Please see below.

1. Have you made any customizations to `org-download`? It's easier for
me to proceed with the defaults.

*-- No, all I did is (require 'org-download)*

2. As I'm testing now, I can get a "Wrong type argument:
   number-or-marker-p, nil" error if the org-mode file in question is
   empty or the cursor is before the first heading. Is this the case for
you?
   I'll fix this case soon anyway.
-- *Not really, I made a test.org  then insert some
heading, then tried (org-download-yank) with the web address on top of
kill-ring, which did not trig the download events as well.*

3. If this doesn't work, try the following simplified function:

(defun org-download-yank-1 ()
  (interactive)
  (let ((filename "./foo.png"))
(org-download--image
 "https://www.google.nl/images/srpr/logo11w.png";
 filename)
(insert (format "[[%s]]" filename))
(org-display-inline-images)))



*-- This one works! The google logo gets into my test.org 
buffer, which is a good signal~*
Please let me know if there's any further instruction. And thanks for the
help~~

Best,

Chao


On Sun, Jan 18, 2015 at 6:10 AM, Oleh  wrote:

> > Thanks for the detailed instruction. I just checked following your
> advice,
> > by copying the address of the image (and by looking at the browser-ring,
> I
> > can make sure the address has been there), then M-x org-download-yank,
> > returns error: "if: Wrong type argument: number-or-marker-p, nil".
> >
> > Also I tried (org-download-yank "the-address-to-the-image"), which does
> not
> > work either.
> >
> > Do you have any insight? Thanks.
>
> Alright, we're getting somewhere now.
>
> 1. Have you made any customizations to `org-download`? It's easier for
> me to proceed with the defaults.
> 2. As I'm testing now, I can get a "Wrong type argument:
>number-or-marker-p, nil" error if the org-mode file in question is
>empty or the cursor is before the first heading. Is this the case for
> you?
>I'll fix this case soon anyway.
> 3. If this doesn't work, try the following simplified function:
>
> (defun org-download-yank-1 ()
>   (interactive)
>   (let ((filename "./foo.png"))
> (org-download--image
>  "https://www.google.nl/images/srpr/logo11w.png";
>  filename)
> (insert (format "[[%s]]" filename))
> (org-display-inline-images)))
>
> If this one doesn't work as well, I can proceed from there.
>
> regards,
> Oleh
>

Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Fri, 16 Jan 2015, Nicolas Goaziou wrote:


"Charles C. Berry"  writes:


I've attached three patches and two files that show the behavior under
the current master (12 Jan 2015,
e0879b03d08bb4acc663084076370482f61e8698) and under the patched
version.


Thank you. Some comments follow.



[snip]



I don't think inline Babel blocks should be able to generate lists or
tables. Org cannot contain inline lists or tables. If you need a real
table or list, a regular Babel call will do.

I suggest to ignore :results table and :results list, or even return an
error, since this is bound to breaking the document structure.



OK. Now those cases (and some others) insert `*Inline error:' and a
comment as to what the error is and ignore the actual value.

Based on my own experience, I thought it best to allow Babel to run 
without stopping when there are problems with inline src blocks rather 
than stop with an error.


[snip]



I think the "protect commas and backslashes commas" should be factored
out of "ob-core.el" (and "org-element.el") and moved into
"org-macro.el".



OK.

I hope the approach I took modifies `org-macro-expand'.

The "as-is" template returns the macro element :value stripped of the 
leading "{{{(" and the trailing "[\n]?)}}}".  The template allows 
macros that mark text - possibly including commas - but do not modify it.


I am not sure why you mentioned org-element.el.

[snip]

Other comments from Nicolas 16 Jan email are addresed in the attached 
patches.


These patches address inline babel calls and apply the same logic to them.

A file with examples is attached.

n.b. the patch prefix numbers are 0002-0005.

HTH,

ChuckFrom 28e91c6dc718bef24b2e960864f458da046df225 Mon Sep 17 00:00:00 2001
From: chasberry 
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 2/5] lisp/ob-core.el: Inline source block / babel call results
 are replaceable

 * lisp/ob-core.el (org-babel-insert-result): Delete any `results'
   macro following current inline src block; insert current value in
   'results' macro possibly wrapping RESULT in an export snippet or
   inline source block first.

  * lisp/ob-core.el (org-babel-remove-inline-result): Delete results
 of current inline src block or inline babel call if it is wrapped
 in a "{{{results(.*)}}}" macro call.

* lisp/ob-core.el (org-babel-get-lob-one-liner-matches): Ensure that
  the point ends up on the same line as, and just before, `call_' when
  searching backward.

Inline source block or babel call results can be removed by
re-executing the source blocks or babel calls if they are wrapped in a
`{{{results(...)}}}' macro.  The schema for the RESULT-PARAMS is:

  |-+--|
  | Param   | Example output   |
  |-+--|
  | default/replace | {{{results(42)}}}|
  | raw | 42   |
  | drawer  | {{{results(42)}}}|
  | org | {{{results(src_org{...})}}}  |
  | html| {{{results(@@html:...@@)}}}  |
  | latex   | {{{results(@@latex:...@@)}}} |
  | code| {{{results(src_xxx{...})}}}  |
  | file| {{{results([[file:something.pdf]])}}}|
  | table   | {{{results(*Inline error:* `:results table')}}}  |
  | list| {{{results(*Inline error:* `:results list')}}}   |
  |-+--|

 where the default is `src_emacs{42}' and subsequent rows give the `:results' 
arg.

The `:wrap something' header arg gives an effect similar to `:results
 html' or `:results latex'.

Results that are lists or tables or strings with more than one line
(excepting a trailing "\n") output *Inline error:* messages wrapped in
the `results' macro.

On export, the `results' macro is stripped away before the buffer is
parsed.
---
 lisp/ob-core.el | 116 +---
 1 file changed, 85 insertions(+), 31 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 93fcb2a..63ccabc 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -251,7 +251,8 @@ Returns non-nil if match-data set"
 Returns non-nil if match-data set"
   (save-excursion
 (unless (= (point) (point-at-bol)) ;; move before inline block
-  (re-search-backward "[ \f\t\n\r\v]" nil t))
+  (re-search-backward "\\([^[:alpha:]]\\|[ \f\t\n\r\v]\\)call_" nil t)
+  (goto-char (match-end 1)))
 (if (looking-at org-babel-inline-lob-one-liner-regexp)
t
   nil)))
@@ -2073,13 +2074,18 @@ If the path of the link is a file path it is expanded 
using
 (defun org-babel-insert-result
   (result &optional result-params info hash indent lang)
   "Insert RESULT into the curre

[O] Table calculations with hline references

[Daniel Hornung]

Hi,
I am trying to calculate a field using references to horizontal lines 
according to http://orgmode.org/manual/References.html

For example:

| col1 | col2 |
|--+--|
| foo  |1 |
| bar  |2 |
| baz  |4 |
|--+--|
| sum  |  |
|  |  |
#+TBLFM: @II+1$2=vsum(@I$2..@II$2)

The field to the right of "sum" (@5$2 as a fixed reference) should be "7".

The output is as follows though (the cursor was in the "baz" field
when I pressed "C-u C-c *" to recalculate all formulas):

| col1 | col2 |
|--+--|
| foo  |1 |
| bar  |2 |
| 7|7 |
|--+--|
| 10   |   10 |
|  |  |
#+TBLFM: @II+1$2=vsum(@I$2..@II$2)

Could anyone enlighten me where I made a mistake here?

Thanks a lot,
Daniel


-- 
Mein öffentlicher Schlüssel / My public key: 4096R/600ACB3B 2012-04-01
Fingerabdruck / Fingerprint:
9902 575B B9A0 C339 CFDF  250B 9267 CA6B 600A CB3B
Runterladen z.B. bei/ Get it e.g. from:
pgp.mit.edu, subkeys.pgp.net, pgp.uni-mainz.de, pool.sks-keyservers.net, ...


signature.asc
Description: This is a digitally signed message part.

Re: [O] [PATCH] org-rss-headline

[Nicolas Petton]

Indeed, sorry about that.
Here's a new patch with a short description of the RSS_TITLE property.

diff --git a/contrib/lisp/ox-rss.el b/contrib/lisp/ox-rss.el
index fddaa1d..6681336 100644
--- a/contrib/lisp/ox-rss.el
+++ b/contrib/lisp/ox-rss.el
@@ -42,6 +42,9 @@
 ;; PUBDATE property.  If `org-rss-use-entry-url-as-guid', it will also add
 ;; an ID property, later used as the guid for the feed's item.
 ;;
+;; The top-level headline is used as the title of each RSS item unless an
+;; RSS_TITLE property is set on the headline.
+;;
 ;; You typically want to use it within a publishing project like this:
 ;;
 ;; (add-to-list
@@ -244,11 +247,12 @@ communication channel."
 			  (format-time-string
 			   "%a, %d %b %Y %H:%M:%S %z"
 			   (org-time-string-to-time pubdate0)
-	   (title (replace-regexp-in-string
-		   org-bracket-link-regexp
-		   (lambda (m) (or (match-string 3 m)
-   (match-string 1 m)))
-		   (org-element-property :raw-value headline)))
+	   (title (or (org-element-property :RSS_TITLE headline)
+		  (replace-regexp-in-string
+		   org-bracket-link-regexp
+		   (lambda (m) (or (match-string 3 m)
+   (match-string 1 m)))
+		   (org-element-property :raw-value headline
 	   (publink
 	(or (and hl-perm (concat (or hl-home hl-pdir) hl-perm))
 		(concat

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Nicolas,

2015ko urtarrilak 18an, Nicolas Goaziou-ek idatzi zuen:
> 
> Aaron Ecay  writes:
> 
>> 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
>>> It would be more flexible, but it would also defeat the whole point of
>>> the "results" macro, that is to be able to mark /unambiguously/ the
>>> output of an inline block. Indeed, even if you can get the name of the
>>> macro from the parameter, you cannot be sure the macro was generated by
>>> the code block, unlike to a results macro.
>> 
>> Well, you could examine the code block’s :wrap header arg to determine
>> what kind of macro it generates, rather than hardcoding “results.”
>> (This would break when :wrap’s value was changed, though).
> 
> As I said above, even if you read :wrap parameter, this is ambiguous,
> since the use can insert any "foo" macro after a ":wrap foo":
> 
>   src_emacs-lisp[:wrap foo]{(+ 1 1)} {{{foo(this is something else)}}}
> 
>> Probably a better solution is that the results macro could wrap the
>> custom macro:
>> 
>> {{{results({{{mymacro(foo)}}})}}}
> 
> You cannot nest macros.

OK, I didn’t know that.

> 

[...]

> You probably can use some Babel code instead.

Indeed, it looks like the system I had in mind wouldn’t work very well.
Thanks for this suggestion, I’ll look into it.

Thanks,

-- 
Aaron Ecay

Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock

[Nicolas Goaziou]

Nikolai Weibull  writes:

> I realize that you have to update it manually, but wouldn’t it make
> sense to have it be updated automatically when you call
> org-agenda-(set|remove)-restriction-lock?  At least when you do so
> from the Agenda itself?

It could make sense, but the current behaviour is simple and
consistent : always refresh manually, no exception.

The other solution is to have all actions started from the agenda
trigger an automatic update. I don't know if that's the spirit of the
original sticky agenda feature, but it is certainly more work for little
benefit.


Regards,

Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Aaron Ecay  writes:

> 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
>> It would be more flexible, but it would also defeat the whole point of
>> the "results" macro, that is to be able to mark /unambiguously/ the
>> output of an inline block. Indeed, even if you can get the name of the
>> macro from the parameter, you cannot be sure the macro was generated by
>> the code block, unlike to a results macro.
>
> Well, you could examine the code block’s :wrap header arg to determine
> what kind of macro it generates, rather than hardcoding “results.”
> (This would break when :wrap’s value was changed, though).

As I said above, even if you read :wrap parameter, this is ambiguous,
since the use can insert any "foo" macro after a ":wrap foo":

  src_emacs-lisp[:wrap foo]{(+ 1 1)} {{{foo(this is something else)}}}

> Probably a better solution is that the results macro could wrap the
> custom macro:
>
> {{{results({{{mymacro(foo)}}})}}}

You cannot nest macros.

>> Also, I don't think we really need this flexibility since any twist to
>> the output can be made at the Babel level, or even using
>> `org-babel-inline-result-wrap'.
>
> o-b-inline-result-wrap can’t be specified on a per-block basis like
> header args can.  And doing it within babel would lead to extra
> verbosity.  As an example use case, I sometimes write things like:
>
> src_R{round(100*78/7065,2)}
>
> What I’m really interested in is the value 100*78/7065,¹ but I don’t want
> it spilling its many decimal places into the exported document (I don’t
> particularly mind them in the org file).  I think the following would be a
> better way of writing things like this, since it separates the presentation
> (round to two decimal places) from the content (100*78/7065):
>
> src_R[:wrap round2]{100*78/7065}
>
> I would write a round2 macro to arrange the rounding.  (round2 and
> round0/truncate would probably cover 90+% of my use of inline R
> blocks).  For latex, this would use one of the packages like siunitx
> or pgfplots which offer number formatting (including other fancy
> options like scientific notation for large numbers).  For other
> backends, I’d probably use an eval-type macro to do the rounding in
> elisp.

No matter how appealing this feature sounds to you, it would be flawed
and is not strictly necessary. You probably can use some Babel code
instead.

Note that your hypothetical code would sometimes fail, too, as regular
macros are expanded before Babel code is executed. IOW, macros can
produce Babel code, but not the other way (at least not consistently).


Regards,

[O] More helm awesomeness

[Simon Thum]

Hi all,

I recently updated my helm install so it includes 
helm-org-agenda-headings which is just AWESOME (to me at least). A bit 
like org-goto but across all agenda files at once, with goto, refile, 
linking built in. If you haven't tried it, I definitely recommend to do so.



Yet I'm missing a few things so far, I would like to have different 
datasources differentiated by tags, in particular the ARCHIVE tag, and 
the infamous FILETAGS so I cannot just regex my way through as the 
current approach does.


This requires making more use of org-ode when filling helm's buffers. My 
elisp isn't great but I might be able to get there if the approach is sane.


Any pointers are welcome! If you might help me please read on.

I would like to ask what would be the best approach for better utilising 
org infrastructure so I may have separate helm sources for 
live/archived, private/work, the clocking history, stuff like that.


The helm-org definition looks deceptively simple:

https://github.com/emacs-helm/helm/blob/master/helm-org.el

(defun helm-org-agenda-files-headings ()
(interactive)
(helm :sources (helm-source-org-headings-for-files (org-agenda-files))
:candidate-number-limit 9
:buffer "*helm org headings*"))


FWICT, in effect helm-org is chewing itself through the buffers:

(defun helm-get-org-candidates-in-file (filename min-depth max-depth
&optional fontify)
(with-current-buffer (find-file-noselect filename)
(and fontify (jit-lock-fontify-now))
(let ((match-fn (if fontify 'match-string 'match-string-no-properties)))
(save-excursion
(goto-char (point-min))
(cl-loop while (re-search-forward org-complex-heading-regexp nil t)
if (let ((num-stars (length (match-string-no-properties 1
(and (>= num-stars min-depth) (<= num-stars max-depth)))
collect `(,(funcall match-fn 0) . ,(point-marker)))

I don't really get what it does but I have a hunch that org-element or 
other org-mode functions could be used to achieve the same with more 
precision. That's what I would need to do. FWIW I'd be happy to take a 
performance hit.


Thanks in advance,

Simon

Re: [O] three bugs/misfeatures in org-reveal (or is org-reveal the wrong way to reveal around point?)

[Samuel Wales]

On 1/18/15, Nicolas Goaziou  wrote:
>   ((default . 2)
>(occur-tree . 1)
>(tags-tree . 1)
>(isearch . 3)
>(bookmark-jump . 3))
>
> where
>
>   1. means only the minimal location is shown, i.e., top level
>  headline + headline, and section (no child) if match is not on
>  a headline.
>
>   2. means context 1 + hierarchy above
>
>   3. means context 2 + siblings
>
>   4. means canonical view, i.e, show full hierarchy above and siblings,
>  and, if match is within a section, show also section and all
>  children.

i definitely like the idea of a single place to set visibility.  i
imagine that would clarify the code and make it so that users can
quickly determine what is possible.

please refresh me on the grammar.  does section mean something like
header + body text + children as a whole?

as a ui note, it might work to use symbols instead of numbers.  if the
code could support it bloatlessly, maybe even allow mix and match so
that you can do 3 without 2 if you want?

===

as a brainstorm, a new visibility command could cycle among the
available visibility states locally [i.e. as if you had set the
variable differently].  that might be implementationally troublesome,
but i would use it if it existed.  of course i'd use canonical as the
default.

in such a cycling, if it were implemented, i personally would want a
state that is like canonical visibility, but without body text.

it would be similar to doing show-branches in a highly time-consuming
way where you show siblings and hierarchy above and siblings above but
no body text.  this is /almost/ canonical, in that it does not leave
out anything except body text.  i think that would be particularly
useful for people who write books or blog posts as you'd get
everything related to structure and nothing not related to it.  i.e.
never surprised at the lack of a headline.

> We lose a bit of control, but I think left out combinations are not very
> interesting. But I may be wrong.
>
> WDYT?

one issue with existing code is that isearch-mode-end-hook and
defadvice of org-show-context seem not to always work, perhaps because
org sets a post-command-hook, which i find confusing. still have not
figured it out.  getting rid of post-command-hook stuff might be
useful?

another issue is speed; the existing code is slow for me, although
perhaps not much can be improved.


samuel

-- 
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] org-download.el

[Oleh]

Hi all,

I've made a blog post regarding today's improvements to org-download
at http://oremacs.com/2015/01/18/sprucing-up-org-download/.
The post also links to a video demo: https://www.youtube.com/watch?v=dAojpHR-6Uo

regards,
Oleh

Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Nicolas,

2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
> It would be more flexible, but it would also defeat the whole point of
> the "results" macro, that is to be able to mark /unambiguously/ the
> output of an inline block. Indeed, even if you can get the name of the
> macro from the parameter, you cannot be sure the macro was generated by
> the code block, unlike to a results macro.

Well, you could examine the code block’s :wrap header arg to determine
what kind of macro it generates, rather than hardcoding “results.”
(This would break when :wrap’s value was changed, though).

Probably a better solution is that the results macro could wrap the
custom macro:

{{{results({{{mymacro(foo)}}})}}}

> 
> Also, I don't think we really need this flexibility since any twist to
> the output can be made at the Babel level, or even using
> `org-babel-inline-result-wrap'.

o-b-inline-result-wrap can’t be specified on a per-block basis like
header args can.  And doing it within babel would lead to extra
verbosity.  As an example use case, I sometimes write things like:

src_R{round(100*78/7065,2)}

What I’m really interested in is the value 100*78/7065,¹ but I don’t want
it spilling its many decimal places into the exported document (I don’t
particularly mind them in the org file).  I think the following would be a
better way of writing things like this, since it separates the presentation
(round to two decimal places) from the content (100*78/7065):

src_R[:wrap round2]{100*78/7065}

I would write a round2 macro to arrange the rounding.  (round2 and
round0/truncate would probably cover 90+% of my use of inline R
blocks).  For latex, this would use one of the packages like siunitx
or pgfplots which offer number formatting (including other fancy
options like scientific notation for large numbers).  For other
backends, I’d probably use an eval-type macro to do the rounding in
elisp.

¹ This is just a particularly simple example; often the value is not
just the result of some arithmetic, but rather a coefficient extracted
from a statistical model by a series of function calls etc.

Thanks,

-- 
Aaron Ecay

Re: [O] org-todo-recursive

[Rasmus]

Hi David,

David Arroyo Menendez  writes:

>>> How can I do a org-todo-recursive? The idea is replace TODO by DONE in
>>> a tree. Someone with a snippet?
>>
>> Does org-depend.el do what you need?  [Your message is not very clear]
>>
> I'm not an user of org-depend.el, but from my point of view, org-depend
> is for triggers, I want make a request to a full subtree in org, not triggers.

Can you give a simple example of what you have got in mind?  Do you want
to change the TODO-state of all subheadings relative to the current heading?

—Rasmus

-- 
Summon the Mothership!

Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock

[Nikolai Weibull]

On Sun, Jan 18, 2015 at 11:26 AM, Nicolas Goaziou
 wrote:

> Nikolai Weibull  writes:
>
>> I’m bumping this again, as this feels like a bug and I’m surprised
>> that no one has at least responded to it.
>>
>> On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull  wrote:
>>> Hi!
>>>
>>> Anyone else experiencing this?  Or is my configuration wrong in some way?
>>>
>>> On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull  wrote:
 Hi!

 It seems that agendas created when org-agenda-sticky-mode is t aren’t
 automatically redone when calling
 org-agenda-(set|remove)-restriction-lock.  The reason is that
 (org-agenda-maybe-redo) checks whether there’s a window displaying a
 buffer named org-agenda-buffer-name.  Org-agenda-buffer-name is, for
 some reason, not set to the (buffer-name) for these sticky agendas
 (which get the key that was selected as a suffix, for example, “*Org
 Agenda(p)*”).

 I don’t know whether there’s a reason for this, but it seems like it’s
 a bug.  Either org-agenda-buffer-name isn’t being set correctly or
 (org-agenda-maybe-redo) should be using (buffer-name) instead of
 org-agenda-buffer-name.

 If there’s a reason for this, I’d really like to know what it is, so
 that I can begin to try to remember to press g whenever I’ve updated
 the restriction lock.
>
> According to the manual

I realize that you have to update it manually, but wouldn’t it make
sense to have it be updated automatically when you call
org-agenda-(set|remove)-restriction-lock?  At least when you do so
from the Agenda itself?

Re: [O] org-download.el

[Oleh]

> Thanks for the detailed instruction. I just checked following your advice,
> by copying the address of the image (and by looking at the browser-ring, I
> can make sure the address has been there), then M-x org-download-yank,
> returns error: "if: Wrong type argument: number-or-marker-p, nil".
>
> Also I tried (org-download-yank "the-address-to-the-image"), which does not
> work either.
>
> Do you have any insight? Thanks.

Alright, we're getting somewhere now.

1. Have you made any customizations to `org-download`? It's easier for
me to proceed with the defaults.
2. As I'm testing now, I can get a "Wrong type argument:
   number-or-marker-p, nil" error if the org-mode file in question is
   empty or the cursor is before the first heading. Is this the case for you?
   I'll fix this case soon anyway.
3. If this doesn't work, try the following simplified function:

(defun org-download-yank-1 ()
  (interactive)
  (let ((filename "./foo.png"))
(org-download--image
 "https://www.google.nl/images/srpr/logo11w.png";
 filename)
(insert (format "[[%s]]" filename))
(org-display-inline-images)))

If this one doesn't work as well, I can proceed from there.

regards,
Oleh

Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock

[Nicolas Goaziou]

Hello,

Nikolai Weibull  writes:

> I’m bumping this again, as this feels like a bug and I’m surprised
> that no one has at least responded to it.
>
> On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull  wrote:
>> Hi!
>>
>> Anyone else experiencing this?  Or is my configuration wrong in some way?
>>
>> On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull  wrote:
>>> Hi!
>>>
>>> It seems that agendas created when org-agenda-sticky-mode is t aren’t
>>> automatically redone when calling
>>> org-agenda-(set|remove)-restriction-lock.  The reason is that
>>> (org-agenda-maybe-redo) checks whether there’s a window displaying a
>>> buffer named org-agenda-buffer-name.  Org-agenda-buffer-name is, for
>>> some reason, not set to the (buffer-name) for these sticky agendas
>>> (which get the key that was selected as a suffix, for example, “*Org
>>> Agenda(p)*”).
>>>
>>> I don’t know whether there’s a reason for this, but it seems like it’s
>>> a bug.  Either org-agenda-buffer-name isn’t being set correctly or
>>> (org-agenda-maybe-redo) should be using (buffer-name) instead of
>>> org-agenda-buffer-name.
>>>
>>> If there’s a reason for this, I’d really like to know what it is, so
>>> that I can begin to try to remember to press g whenever I’ve updated
>>> the restriction lock.

According to the manual

 By default, Org maintains only a single agenda buffer and rebuilds
 it each time you change the view, to make sure everything is always
 up to date. If you often switch between agenda views and the build
 time bothers you, you can turn on sticky agenda buffers or make
 this the default by customizing the variable ‘org-agenda-sticky’.
 With sticky agendas, the agenda dispatcher will not recreate agenda
 views from scratch, it will only switch to the selected one, and
 you need to update the agenda by hand with ‘r’ or ‘g’ when needed.
 You can toggle sticky agenda view any time with
 ‘org-toggle-sticky-agenda’.

So the whole point of sticky agenda is that you need to update it
manually.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-download.el

[Chao Lu]

Hi Oleh,

Thanks for the detailed instruction. I just checked following your advice,
by copying the address of the image (and by looking at the browser-ring, I
can make sure the address has been there), then M-x org-download-yank,
returns error: "if: Wrong type argument: number-or-marker-p, nil".

Also I tried (org-download-yank "the-address-to-the-image"), which does not
work either.

Do you have any insight? Thanks.

Best,

Chao

On Thu, Jan 15, 2015 at 7:11 AM, Oleh  wrote:

> Hello,
>
> > Does anyone get org-download.el to work under Mac OSX? I'm struggling to
> get
> > it work, but it seems to help a lot, empowering org to handle images a
> lot
> > easier.
> >
> > I believe I've installed org-download.el correctly, but when I'm dragging
> > and drop the image into an org buffer, all I get is the link address
> > inserted into the buffer, no downloading events trigger.
>
> I'm the org-download author. I've mentioned these things on the tracker,
> but there's no harm to posting here additionally.
>
> I don't have OSX, so I can't test it. However, it should work in
> theory, since all tools used are portable.
>
> Try using `org-download-yank' first: this one does everything except
> drag-and-drop. Just right click and copy the image url in the browser,
> and call `org-download-yank' in Emacs. If it doesn't work, the issue is
> with dnd, otherwise it's with the downloading itself.
>
> The default `org-download-backend 'uses `url-retrieve', which is a part of
> Emacs, so if it doesn't work then it's an Emacs bug.
>
> regards,
> Oleh
>

Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock

[Nikolai Weibull]

I’m bumping this again, as this feels like a bug and I’m surprised
that no one has at least responded to it.

On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull  wrote:
> Hi!
>
> Anyone else experiencing this?  Or is my configuration wrong in some way?
>
> On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull  wrote:
>> Hi!
>>
>> It seems that agendas created when org-agenda-sticky-mode is t aren’t
>> automatically redone when calling
>> org-agenda-(set|remove)-restriction-lock.  The reason is that
>> (org-agenda-maybe-redo) checks whether there’s a window displaying a
>> buffer named org-agenda-buffer-name.  Org-agenda-buffer-name is, for
>> some reason, not set to the (buffer-name) for these sticky agendas
>> (which get the key that was selected as a suffix, for example, “*Org
>> Agenda(p)*”).
>>
>> I don’t know whether there’s a reason for this, but it seems like it’s
>> a bug.  Either org-agenda-buffer-name isn’t being set correctly or
>> (org-agenda-maybe-redo) should be using (buffer-name) instead of
>> org-agenda-buffer-name.
>>
>> If there’s a reason for this, I’d really like to know what it is, so
>> that I can begin to try to remember to press g whenever I’ve updated
>> the restriction lock.
>>
>> Thanks!

Re: [O] org-todo-recursive

[David Arroyo Menendez]

Rasmus  writes:

> Hi,
>
> davi...@es.gnu.org (David Arroyo Menéndez) writes:
>
>> How can I do a org-todo-recursive? The idea is replace TODO by DONE in
>> a tree. Someone with a snippet?
>
> Does org-depend.el do what you need?  [Your message is not very clear]
>
> Cheers,
> Rasmuse

I'm not an user of org-depend.el, but from my point of view, org-depend
is for triggers, I want make a request to a full subtree in org, not triggers.

Cheers.

Re: [O] bug: isearch hides text that should be shown, ignoring all show variables

[Nicolas Goaziou]

Samuel Wales  writes:

> is it the case that doing org-reveal as an after defadvice to
> org-show-context should guarantee canonical visibility?

It guarantees canonical visibility with optional argument, i.e.,
(org-reveal t)

I'm pondering if (org-reveal nil) is really useful or if it should
always be (org-reveal t), in a sense.


Regards,

Re: [O] three bugs/misfeatures in org-reveal (or is org-reveal the wrong way to reveal around point?)

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> thanks for clarifying.  that seems to eliminate all possibility of
> specifying canonical visibility using org show variables.

Indeed.

> thus, this is a feature that is strangely missing in org, as opposed
> to a bug.

I agree. Also, I find the configuration in this area overly complicated.

> canonical visibility roughly means a visibility state that can be
> created at any time using org-cycle and arrow keys.
>
> for example, if only the first child is showing, then it is not
> canonical visibility.  the only things that should NOT show are
> entirely folded headers, blocks, etc.
>
> this is the only kind of visibility that i ever use unless i am doing
> a sparse tree, which is extremely rare.

I think we could simplify the show context configuration and, at the
same time, provide a way to show "canonical visibility". 

For example, we can merge `org-show-hierarchy-above',
`org-show-following-heading', `org-show-siblings' and
`org-show-entry-below' into a single variable,
`org-show-context-detail', where each context is associated to a level,
e.g., for current default configuration,

  ((default . 2)
   (occur-tree . 1)
   (tags-tree . 1)
   (isearch . 3)
   (bookmark-jump . 3))

where

  1. means only the minimal location is shown, i.e., top level
 headline + headline, and section (no child) if match is not on
 a headline.

  2. means context 1 + hierarchy above

  3. means context 2 + siblings

  4. means canonical view, i.e, show full hierarchy above and siblings,
 and, if match is within a section, show also section and all
 children.

We lose a bit of control, but I think left out combinations are not very
interesting. But I may be wrong.

WDYT?


Regards,

-- 
Nicolas Goaziou