Re: [O] how to use :options-alist in org-export-define-derived-backend ?

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> Anyway, this bug is due to a cheesy workaround in order to get original
>> file name or buffer name if no title is provided. It should work in
>> maint now, but I suggest to get rid of that behaviour in master, as
>> suggested in a recent thread.
>
> sorry I lost track -- what is the behavior you want to get rid on
> exactly?

Automatically set document's title to file name or buffer name when no
TITLE keyword is provided.


Regards,

-- 
Nicolas Goaziou

Re: [O] still seeing semi-regular lockups

[Nicolas Goaziou]

Daimrod  writes:

> My guess is that the lockup happens in `org-element--cache-key-less-p',
> called by `org-element--cache-process-request'.

Probably, but it doesn't mean that this particular function is buggy.
The lockup happens there because the cache gets corrupted at some point.

After investigating a little while, it appears that switching
input-method to "latin-postfix" alone is sufficient to corrupt it.
Though, setting `org-element-cache-sync-idle-time' to a high value
prevents the problem, which means that the corruption happens only when
cache is synchronized during idle time.

That's where I am for the time being. I don't know much about input
methods, so I have no clue about the reasons behind this. I'm still
investigating.


Regards,

-- 
Nicolas Goaziou

[O] Linked tasks

[Fletcher Charest]

Dear all,

I was wondering if there was a way to link the status of two tasks in an
agenda file (or even across multiple agenda files). Sometimes, a single
task (in my case, updating my CV) might be a useful step in two different
projects. If the tasks is marked DONE in one project (in one subtree), I
would like the other one to be marked DONE as well. Is it possible or even
implemented?

Cheers,

FC

Re: [O] #+BEAMER not defined?

[Nicolas Goaziou]

Hello,

Sebastien Vauban 
writes:

> #+Beamer_BEGIN:
> \bold{BeamerFoo}
> #+Beamer_END:

I don't know this syntax

> #+LaTeX_BEGIN:
> \bold{LaTeXBaz}
> #+LaTeX_END:

nor this one.

> outputs this:
>
> \bold{BeamerFoo} \bold{LaTeXBaz} \bold{LaTeXFooBar}

I cannot reproduce it.


Regards,

-- 
Nicolas Goaziou

Re: [O] #+BEAMER not defined?

[Bastien]

Hi Sébastien,

Sebastien Vauban 
writes:

> - the construct #+Beamer_BEGIN/END exists, but not #+Beamer?

Your subconscious wants something that does not exists :)
This file works fine for me:


#+TITLE: Beamer blocks

#+BEGIN_BEAMER
\bold{beamer block}
#+END_BEAMER

#+begin_beamer
\bold{beamer block}
#+end_beamer

#+BEAMER: \bold{BEAMER}

#+Beamer: \bold{Beamer}

#+beamer: \bold{beamer}



-- 
 Bastien

Re: [O] Linked tasks

[Eric Abrahamsen]

Fletcher Charest  writes:

> Dear all,
>
> I was wondering if there was a way to link the status of two tasks in
> an agenda file (or even across multiple agenda files). Sometimes, a
> single task (in my case, updating my CV) might be a useful step in
> two different projects. If the tasks is marked DONE in one project
> (in one subtree), I would like the other one to be marked DONE as
> well. Is it possible or even implemented?
>
> Cheers,
>
> FC

There's an org-depend package in the contrib directory that's supposed
to do this, but I haven't looked at it before... Vanilla Org only does
dependencies within the same subtree.

E

[O] Capturing outgoing gnus e-mail

[Ivan Kanis]

Hi,

I would like to capture outgoing e-mail in my org file.

I use the gcc mechanism in gnus with a nnml backend.

I think I have read on the org mailing list that someone has implemented
that feature. I did a search but could not find the article.

I tried implementing it myself. I had a look at the function
gnus-inews-do-gcc. It has the group and the article number. However org
link expect the Message-ID header. How do I get it?

Thanks,

Ivan
-- 
Software uses US measurements, but the OS is in metric...
-- BOFH excuse #24

Re: [O] Capturing outgoing gnus e-mail

[Bastien]

Hi Ivan,

this is what I use :


;; Hack to store Org links upon sending Gnus messages

(defun bzg-message-send-and-org-gnus-store-link (&optional arg)
  "Send message with `message-send-and-exit' and store org link to message copy.
If multiple groups appear in the Gcc header, the link refers to
the copy in the last group."
  (interactive "P")
(save-excursion
  (save-restriction
(message-narrow-to-headers)
(let ((gcc (car (last
 (message-unquote-tokens
  (message-tokenize-header
   (mail-fetch-field "gcc" nil t) " ,")
  (buf (current-buffer))
  (message-kill-buffer-on-exit nil)
  id to from subject desc link newsgroup xarchive)
(message-send-and-exit arg)
(or
 ;; gcc group found ...
 (and gcc
  (save-current-buffer
(progn (set-buffer buf)
   (setq id (org-remove-angle-brackets
 (mail-fetch-field "Message-ID")))
   (setq to (mail-fetch-field "To"))
   (setq from (mail-fetch-field "From"))
   (setq subject (mail-fetch-field "Subject"
  (org-store-link-props :type "gnus" :from from :subject subject
:message-id id :group gcc :to to)
  (setq desc (org-email-link-description))
  (setq link (org-gnus-article-link
  gcc newsgroup id xarchive))
  (setq org-stored-links
(cons (list link desc) org-stored-links)))
 ;; no gcc group found ...
 (message "Can not create Org link: No Gcc header found."))

(define-key message-mode-map [(control c) (control meta c)]
  'bzg-message-send-and-org-gnus-store-link)


Then, in a message, I use C-c C-M-c instead of C-c C-c to send the
message and create a link to it that I can reinsert later one.  This
is not really capturing, but it's good enough for my needs.

HTH,

-- 
 Bastien

Re: [O] Capturing outgoing gnus e-mail

[Eric Abrahamsen]

Ivan Kanis  writes:

> Hi,
>
> I would like to capture outgoing e-mail in my org file.
>
> I use the gcc mechanism in gnus with a nnml backend.
>
> I think I have read on the org mailing list that someone has implemented
> that feature. I did a search but could not find the article.
>
> I tried implementing it myself. I had a look at the function
> gnus-inews-do-gcc. It has the group and the article number. However org
> link expect the Message-ID header. How do I get it?
>
> Thanks,
>
> Ivan

Hi Ivan,

That's something that Gnorb[1] can do. Make a capture template that
you want to use for outgoing mail TODOs, and identify it:

(setq gnorb-gnus-new-todo-capture-key "O")

Then, while you're composing the email, call
`gnorb-gnus-outgoing-do-todo' in the message buffer, which I have bound
to "C-c t".

You can also call it *after* sending the message, if you forgot, and it
will initiate the same process from the last sent message.

It works best when you're using Gcc, as that means Org is able to make a
real link to the sent message. Gnorb will try to fake it, if you're not.

If you set (setq gnorb-gnus-hint-relevant-article t), Gnorb will even
notify you when you get a reply to your sent message.

It's early days for Gnorb, but this part of it works well for me. I'd
love a little more road-testing, if you're interested!

I'm going to stick it in ELPA in a month or so, but for now:

[1]: https://github.com/girzel/gnorb

Hope it helps!
E

Re: [O] [PATCH] Add DEVONthink Pro to Org Mac Link

[Mike-Personal]

On June 14, 2014 at 2:47:26 AM, Bastien (b...@gnu.org(mailto:b...@gnu.org)) 
wrote:

> Hi Mike,
>  
> Mike McLean writes:
>  
> > This patch adds support for DEVONthink Pro Office
> >  
> > to Org Mac Links. This likely works for all versions of DEVONthink, but
> > that is not tested.
>  
> thanks -- the patch got mangled, can you resend it as an attachment or
> not use HTML emails?

That’s what I get for 12:30 submissions 😃 

I have attached the patch to this email. 

Mike 




Add-DEVONthink-Pro-to-Org-Mac-Link.patch
Description: Binary data

Re: [O] controling width of graphviz source block result

[Nicolas Goaziou]

Hello,

regcl  writes:

> Thank you for your earlier comments.  In order to adjust the scaling of
> a graphic generated by a R source block I am doing this ...
>
> ** adjusting scaling of a figure generated from source
> #+begin_src R :results graphics silent :file foo2.pdf :exports results 
>   plot(c(1:10), c(10:1))
>   #+end_src
> #+attr_latex: :width .35\textwidth
> file:foo2.pdf 
>
> While this does work, it is a wee bit unsatisfying to type "foo2.pdf""
> twice.
>
> Is there a better way to apply the latex keyword to the results?

I don't know what the current state of the art is, but I usually add
a name to the block, generate the result link, and add attributes above.


Regards,

-- 
Nicolas Goaziou

Re: [O] proposal to have ignoreheading tags/properties

[Nicolas Goaziou]

Hello,

Eric Schulte  writes:

> Why TODO types rather than a tag?  IMO using a TODO type would conflate
> task management and document structuring.  What do you think about the
> attached patch which should add this functionality to the core.

Thank you. Unfortunately, in many cases this code will make the parse
tree invalid. Consider the example below:

  * H1
Text1
  ** H2 :inline:
Text2

A simplified version of the parse tree is:

  (headline
   (section
(paragraph "Text1"))
   (headline
(section
 (paragraph "Text2"

With your function, it becomes

  (headline
   (section
(paragraph "Text1"))
   (section
(paragraph "Text2")))

which is invalid, as a given headline is not expected to have more than
one section.

Of course, it is possible to add code in order to merge both sections
and get

  (headline
   (section
(paragraph "Text1")
(paragraph "Text2")))

which is exactly what you obtain in the first answer of the FAQ, along
with its limitations (see the :noexport: example in the same question).

Actually, the problem is deeper than that. This :inline: tag is just
a convoluted way to ask for a positive answer to another FAQ: « Can
I close an outline section without starting a new section? »
(http://orgmode.org/worg/org-faq.html#closing-outline-sections). Indeed,
allowing :include: tags is equivalent to allowing to close sections
before the next one, at least at the export level:

  * Section one

  Some text

  ** Subsection one

  Some text

  ** Subsection two

  Some text

  ** end Subsection Two 
:inline:

  Continue text in section one.

This is not possible and goes against so many assumptions in Org that it
will always introduce problems, as your function does.

Since it cannot work in the general case, I do not think it should go in
core. Fortunately, a simple function in `org-export-before-parsing-hook'
provides a decent solution already. Users requiring more sophistication
can always implement their own function and add it to that hook.

OTOH, the situation could be improved wrt :export: and :noexport: tags.
We could allow nesting :export: tags within :noexport: tags with the
following rule: the :export: headline with the lowest level within
the :noexport: tree gets promoted to the root of the tree.
Other :export: headlines have their level set relatively to this one.
Thus:

  Text before first headline
  * H1
  Body1
  ** H2 :noexport:
  Body2
  *** H3
  Body3
  *** H4 :export:
  Body4
   H5
  Body5

will be seen as

  Text before first headline
  * H1
  Body1
  ** H4
  Body4
  *** H5
  Body5

This is not inlining, since "Body2" is lost anyway, and it may require
to tag all children of a given headline, but it's already better than
the current situation, is robust enough for inclusion in core, and
doesn't require introducing a plethora of new special tags.

The reverse situation (with swapped :noexport: and :export: tags) is
already handled by the exporter.

Also, I recall that it is possible to exclude from export some parts of
the document with drawers and an appropriate value for
`org-export-with-drawers'. The only limitation is that you cannot have
a headline or another drawer within a drawer.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Add DEVONthink Pro to Org Mac Link

[Bastien]

Hi Mike,

Mike-Personal  writes:

> I have attached the patch to this email. 

Applied, thanks.  I updated the changelog:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c57ecf26

-- 
 Bastien

[O] org-weather for openweathermap.org

[Chris Raschl]

Hi everybody,

recently I wanted to add a weather forecast to my org-agenda. I found
org-google-weather, but this package is obsolete since 2012, because the
API is not available any more. So I wrote my own version which is backed
by the openweathermap.org API.

I implemented the minimal usecase which works for me, if somebody else
dares to use it, its available here:

https://github.com/kautsig/org-weather

Regards,
Chris

Re: [O] org-weather for openweathermap.org

[Fletcher Charest]

Hi,

Nothing particular to say except that it is nice, and working well!

Thank you for this!

FC


On Sat, Jun 14, 2014 at 3:11 PM, Chris Raschl  wrote:

>
> Hi everybody,
>
> recently I wanted to add a weather forecast to my org-agenda. I found
> org-google-weather, but this package is obsolete since 2012, because the
> API is not available any more. So I wrote my own version which is backed
> by the openweathermap.org API.
>
> I implemented the minimal usecase which works for me, if somebody else
> dares to use it, its available here:
>
> https://github.com/kautsig/org-weather
>
> Regards,
> Chris
>
>

Re: [O] org-weather for openweathermap.org

[Thorsten Jolitz]

Chris Raschl  writes:

> Hi everybody,
>
> recently I wanted to add a weather forecast to my org-agenda. I found
> org-google-weather, but this package is obsolete since 2012, because the
> API is not available any more. So I wrote my own version which is backed
> by the openweathermap.org API.
>
> I implemented the minimal usecase which works for me, if somebody else
> dares to use it, its available here:
>
> https://github.com/kautsig/org-weather

Nice, thank you, never made org-google-weather, but this works
out-of-the-box:

  ,-
  | City: Weather: light rain, 10.43°C - 17.58°C
  `-

A few suggestions wrt

,--
| (defun org-weather-add-to-cache (item)
|   "Adds the one result 'list' item to the data cache"
|   (let* ((timestr (cdr (assoc 'dt item)))
|  (cache-key (format-time-string "%F" (seconds-to-time timestr)))
|  (weather (cdr (assoc 'weather item)))
|  (temperature (cdr (assoc 'temp item)))
|  (temp-min (number-to-string (org-weather-temp-min temperature)))
|  (temp-max (number-to-string (org-weather-temp-max temperature)))
|  (data (concat (org-weather-description weather) ", "
|  temp-min org-weather-unit " - " temp-max org-weather-unit)))
| (puthash cache-key data  org-weather-data)))
`--

- why not use (round ...) for the temperature data, 10-17°C would be
  more than accurate enough?

- why not include city/country info in the weather string? I added 

  * Weather
:PROPERTIES:
:CATEGORY: City
:END:
  %%(org-weather)

  to get the above, but it would be much better to take the return
  values for city/country and include them in the weather string, to
  make sure one did not mess up the configuration and gets the weather
  from another place than expected.

- maybe make the whole thing a bit customizable by adding a few
  defcustoms, so the user can decide which info he wants to print in the
  agenda

  the return string looks like this, there are many options:

,-
| Contacting host: api.openweathermap.org:80 ((list . [((rain . 0.5)
| (clouds . 92) (deg . 353) (speed . 4.41) (weather . [((icon . 10d)
| (description . light rain) (main . Rain) (id . 500))]) (humidity . 88)
| (pressure . 1023.69) (temp (morn . 18.53) (eve . 17.32) (night . 11.63)
| (max . 19.01) (min . 11.63) (day . 18.53)) (dt . 1402743600)) ((clouds
| . 68) (deg . 334) (speed . 2.97) (weather . [((icon . 04d) (description
| . broken clouds) (main . Clouds) (id . 803))]) (humidity . 75) (pressure
| . 1027.85) (temp (morn . 15.35) (eve . 18.45) (night . 9.04) (max
| . 19.62) (min . 9.04) (day . 19.62)) (dt . 140283)) ((rain . 0.5)
| (clouds . 80) (deg . 264) (speed . 3.46) (weather . [((icon . 10d)
| (description . light rain) (main . Rain) (id . 500))]) (humidity . 75)
| (pressure . 1024.55) (temp (morn . 14.54) (eve . 16.83) (night . 14.58)
| (max . 19.07) (min . 14.54) (day . 19.07)) (dt . 1402916400)) ((clouds
| . 0) (deg . 248) (speed . 2.25) (weather . [((icon . 01d) (description
| . sky is clear) (main . Clear) (id . 800))]) (humidity . 88) (pressure
| . 1024.46) (temp (morn . 14.99) (eve . 17.74) (night . 9.9) (max
| . 20.82) (min . 9.9) (day . 20.82)) (dt . 1403002800)) ((clouds . 76)
| (deg . 261) (speed . 6.56) (weather . [((icon . 04d) (description
| . broken clouds) (main . Clouds) (id . 803))]) (humidity . 78) (pressure
| . 1024.87) (temp (morn . 14.25) (eve . 19.07) (night . 14.95) (max
| . 19.37) (min . 14.25) (day . 18.81)) (dt . 1403089200)) ((rain . 4.45)
| (clouds . 35) (deg . 288) (speed . 6.29) (weather . [((icon . 10d)
| (description . moderate rain) (main . Rain) (id . 501))]) (humidity . 0)
| (pressure . 1016.64) (temp (morn . 15.26) (eve . 18.07) (night . 13.78)
| (max . 19.68) (min . 13.78) (day . 19.68)) (dt . 1403175600)) ((rain
| . 1.34) (clouds . 36) (deg . 289) (speed . 5.59) (weather . [((icon
| . 10d) (description . light rain) (main . Rain) (id . 500))]) (humidity
| . 0) (pressure . 1016.73) (temp (morn . 15.05) (eve . 18.08) (night
| . 15.57) (max . 18.86) (min . 15.05) (day . 18.86)) (dt . 1403262000))])
| (cnt . 7) (city (sys (population . 0)) (population . 0) [...]
`-



-- 
cheers,
Thorsten

Re: [O] Capturing outgoing gnus e-mail

[Marvin Doyley]

I love it 
Thanks
Cheers,
M
Sent from my iPhone
** May contain typos**

[O] [PATCH 2/2] Keep window position in agenda when changing todo states

[Bernt Hansen]

Allow changing task state in agenda without moving point.  I
use this when reviewing projects weekly and I need to change the
state of some of the tasks.  I found jumping to the top of the
agenda after each state change especially annoying when it causes
the agenda to scroll.
---
 lisp/org-agenda.el |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 2d1bafe..d7632b4 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8907,9 +8907,10 @@ If FORCE-TAGS is non nil, the car of it returns the new 
tags."
(org-agenda-highlight-todo 'line)
(beginning-of-line 1))
   (t (error "Line update did not work")))
- (save-restriction
-   (narrow-to-region (point-at-bol) (point-at-eol))
-   (org-agenda-finalize)))
+ (save-window-excursion
+   (save-restriction
+ (narrow-to-region (point-at-bol) (point-at-eol))
+ (org-agenda-finalize
(beginning-of-line 0)
 
 (defun org-agenda-align-tags (&optional line)
-- 
1.7.9.48.g85da4d

[O] Two patches I have been using for 6-12 months

[Bernt Hansen]

Hi Bastien,

Attached are two patches I use on top of master.  I have been using these
for 6-12 months so I consider them to be well tested.

Please consider including these in the code base.

Thanks,
Bernt

[O] [PATCH 1/2] Remove striction when finding task by id

[Bernt Hansen]

Allows find task by id to locate a task outside a current
restriction.  I restrict to subtrees regularly and when I want to
jump to another task outside the current restriction but in the
same file this patch is required to locate the appropriate
heading.  Without this patch point ends up at the top of my
restricted area which is on the wrong task.
---
 lisp/org-macs.el |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index ddd6e2e..e6af5da 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -154,9 +154,11 @@ We use a macro so that the test can happen at compilation 
time."
 `(let ((,mpom ,pom))
(save-excursion
 (if (markerp ,mpom) (set-buffer (marker-buffer ,mpom)))
-(save-excursion
-  (goto-char (or ,mpom (point)))
-  ,@body)
+(save-restriction
+  (widen)
+  (save-excursion
+(goto-char (or ,mpom (point)))
+,@body))
 (def-edebug-spec org-with-point-at (form body))
 (put 'org-with-point-at 'lisp-indent-function 1)
 
-- 
1.7.9.48.g85da4d

Re: [O] [PATCH 1/2] Remove striction when finding task by id

[Nicolas Goaziou]

Hello,

Bernt Hansen  writes:

> Allows find task by id to locate a task outside a current
> restriction.  I restrict to subtrees regularly and when I want to
> jump to another task outside the current restriction but in the
> same file this patch is required to locate the appropriate
> heading.  Without this patch point ends up at the top of my
> restricted area which is on the wrong task.

Thank you. Could you provide a changelog with that?

> +  (save-restriction
> +(widen)
> +(save-excursion

`save-restriction' + `widen' + `save-excursion' = `org-with-wide-buffer'


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH 1/2] Remove striction when finding task by id

[Bernt Hansen]

Nicolas Goaziou  writes:

> Thank you. Could you provide a changelog with that?
>
>> + (save-restriction
>> +   (widen)
>> +   (save-excursion
>
> `save-restriction' + `widen' + `save-excursion' = `org-with-wide-buffer'

Sure thing!

I will update and resend both later today.

(and fix the typo in 'restriction' in the subject above)

Thanks,
Bernt

Re: [O] [PATCH 2/2] Keep window position in agenda when changing todo states

[Bastien]

Hi Bernt,

Bernt Hansen  writes:

> Allow changing task state in agenda without moving point.  I
> use this when reviewing projects weekly and I need to change the
> state of some of the tasks.  I found jumping to the top of the
> agenda after each state change especially annoying when it causes
> the agenda to scroll.

I think the bug this patches is supposed to fix (i.e. point jumping
at the top when changing the state of an agenda item) does not exist
anymore, neither in the maint branch nor in the master one.

Can you double-check?

Also, `save-window-excursion' is sort of a brute-force approach when
we only need to save the point position in a window.  There is a big
warning in `save-window-excursion' docstring that I slowly learned to
appreciate...

Anyway, I just looked at it quickly, maybe that's a correct fix.
Thanks for further confirmation.

-- 
 Bastien

[O] Bug: Commit cece23 'fix'-ed call to 'type' breaks my agenda sorting [8.2.7 (8.2.7-elpa @ /home/trevor/.emacs.d/elpa/org-20140613/)]

[Trevor Murphy]

Hi, all!   The commit named in the subject line is causing me 
grief.  Specifically, the commit made three changes to the 
`org-cmp-ts' function: 

1. Change the function signature to require the `type' argument. 
Doesn't 
   cause me any issues. 
2 & 3. Make two changes from (get-text-property 1 'type FOO) to 
   (get-text-property 1 type FOO).  These cause problems for me. 

Near as I can tell, get-text-property really is supposed to look 
up the `type' property of FOO (returning "scheduled" or "deadline" 
or w/e) so the function can check that against the restriction 
passed in through the argument.


This commit has the function checking the `scheduled', `deadline', 
or other property of FOO based on the passed-in argument.  In this 
case get-text-property always returns nil and the function never 
returns anything useful.   Steps to reproduce: 
 (setq org-agenda-sorting-strategy '((agenda deadline-up))) [pull 
 up an agenda view with some deadline entries and some other 
 stuff] (setq org-agenda-sorting-strategy '((agenda 
 deadline-down))) [refresh the same agenda view] 

What I expect to see: 
 Deadline entries flipping from top to bottom of the agenda view. 

What I actually see: 
 No changes ... org-agenda-sorting-strategy doesn't appear to do 
 anything. 


Is this affecting anybody else?

Emacs  : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.10.7) 
of 2014-01-28 on var-lib-archbuild-extra-i686-juergen 
Package: Org-mode version 8.2.7 (8.2.7-elpa @ 
/home/trevor/.emacs.d/elpa/org-20140613/) --

Trevor Murphy
GnuPG Key: 0x83881C0A

Re: [O] proposal to have ignoreheading tags/properties

[Mark Edgington]

Nicolas Goaziou  nicolasgoaziou.fr> writes:

> Actually, the problem is deeper than that. This :inline: tag is just
> a convoluted way to ask for a positive answer to another FAQ: « Can
> I close an outline section without starting a new section? »
> (http://orgmode.org/worg/org-faq.html#closing-outline-sections). Indeed,
> allowing :include: tags is equivalent to allowing to close sections
> before the next one, at least at the export level:
> 
>   * Section one
> 
>   Some text
> 
>   ** Subsection one
> 
>   Some text
> 
>   ** Subsection two
> 
>   Some text
> 
>   ** end Subsection Two  
  :inline:
> 
>   Continue text in section one.
>

If I understand your example correctly, it seems like you are assuming that
the :inline: tag should promote a section's contents to the level *above*
the level of the section having the :inline: tag.  To me this behavior
doesn't make sense, and that's also not what I would expect such a tag to do
-- instead, the section's text (anything which comes before the next
headline at any level) should be merged with the text of the nearest
preceding headline.  Then all nested headlines contained in the :inline:
section should be promoted.

It is true that this could sometimes be confusing.  For example:

  * A
  text1
  ** B
  text2
  * C  :inline:
  text3
  ** D
  text 4

would get treated like:

  * A
  text1
  ** B
  text2
  text3
  * D
  text 4

In this case, one would likely omit 'text3' from the first part of the
example, since it doesn't make much sense to have it there.  For the most
part, though, it would be a behavior that makes sense (e.g. if "* C" were
replaced with "** C" in the example).

It may be that "inline" isn't the best word to describe this behavior, which
is why something with "ignore" or "promotechildren" has been mentioned.

Re: [O] [PATCH 2/2] Keep window position in agenda when changing todo states

[Bernt Hansen]

Will check. Thanks. 

Bernt

> On Jun 14, 2014, at 11:51 AM, Bastien  wrote:
> 
> Hi Bernt,
> 
> Bernt Hansen  writes:
> 
>> Allow changing task state in agenda without moving point.  I
>> use this when reviewing projects weekly and I need to change the
>> state of some of the tasks.  I found jumping to the top of the
>> agenda after each state change especially annoying when it causes
>> the agenda to scroll.
> 
> I think the bug this patches is supposed to fix (i.e. point jumping
> at the top when changing the state of an agenda item) does not exist
> anymore, neither in the maint branch nor in the master one.
> 
> Can you double-check?
> 
> Also, `save-window-excursion' is sort of a brute-force approach when
> we only need to save the point position in a window.  There is a big
> warning in `save-window-excursion' docstring that I slowly learned to
> appreciate...
> 
> Anyway, I just looked at it quickly, maybe that's a correct fix.
> Thanks for further confirmation.
> 
> -- 
> Bastien

[O] [FR] fill caption

[Daniele Pizzolli]

Hello @ll,

I noticed that multi line caption works as expected, but there is no
way to fill it (at least to my knowledge).

I added a test case that should speak by itself.

I do not know a lot of elisp, but if you have some pointer I could try
to implement it by myself.

Maybe this could be extended to handle also OPTIONS and LocalWords
and others.

Thanks in advance,
Daniele
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 39db5bf..7ebac61 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -362,6 +362,19 @@
 	  (end-of-line)
 	  (org-auto-fill-function)
 	  (buffer-string))
+  ;; Correctly fill the caption.
+  (should
+   (equal "#+CAPTION: this is a very very\n#+CAPTION: long caption"
+	  (org-test-with-temp-text "#+CAPTION: this is a very very long caption"
+	(let ((fill-column 30))
+	  (org-fill-paragraph)
+	  (buffer-string)
+  (should
+   (equal "#+CAPTION: this is a very short caption"
+	  (org-test-with-temp-text #+CAPTION: this is a very \n#+CAPTION: short caption"
+	(let ((fill-column 80))
+	  (org-fill-paragraph)
+	  (buffer-string)
 
 
 

Re: [O] [PATCH 2/2] Keep window position in agenda when changing todo states

[Bernt Hansen]

Yes you are correct. This patch is no longer required.
Please disregard this patch. 

Thanks,
Bernt

> On Jun 14, 2014, at 1:01 PM, Bernt Hansen  wrote:
> 
> Will check. Thanks. 
> 
> Bernt
> 
>> On Jun 14, 2014, at 11:51 AM, Bastien  wrote:
>> 
>> Hi Bernt,
>> 
>> Bernt Hansen  writes:
>> 
>>> Allow changing task state in agenda without moving point.  I
>>> use this when reviewing projects weekly and I need to change the
>>> state of some of the tasks.  I found jumping to the top of the
>>> agenda after each state change especially annoying when it causes
>>> the agenda to scroll.
>> 
>> I think the bug this patches is supposed to fix (i.e. point jumping
>> at the top when changing the state of an agenda item) does not exist
>> anymore, neither in the maint branch nor in the master one.
>> 
>> Can you double-check?
>> 
>> Also, `save-window-excursion' is sort of a brute-force approach when
>> we only need to save the point position in a window.  There is a big
>> warning in `save-window-excursion' docstring that I slowly learned to
>> appreciate...
>> 
>> Anyway, I just looked at it quickly, maybe that's a correct fix.
>> Thanks for further confirmation.
>> 
>> -- 
>> Bastien

Re: [O] [FR] fill caption

[Nicolas Goaziou]

Hello,

Daniele Pizzolli  writes:

> I noticed that multi line caption works as expected, but there is no
> way to fill it (at least to my knowledge).
>
> I added a test case that should speak by itself.
>
> I do not know a lot of elisp, but if you have some pointer I could try
> to implement it by myself.

This was requested before.

In a nutshell, this can be done, but there are some caveats (see
http://permalink.gmane.org/gmane.emacs.orgmode/82083).


Regards,

-- 
Nicolas Goaziou

Re: [O] proposal to have ignoreheading tags/properties

[Aaron Ecay]

Hi Nicolas,

Thanks for your thoughts.

2014ko ekainak 14an, Nicolas Goaziou-ek idatzi zuen:
> OTOH, the situation could be improved wrt :export: and :noexport: tags.
> We could allow nesting :export: tags within :noexport: tags with the
> following rule: the :export: headline with the lowest level within
> the :noexport: tree gets promoted to the root of the tree.
> Other :export: headlines have their level set relatively to this one.
> Thus:
> 
>   Text before first headline
>   * H1
>   Body1
>   ** H2 :noexport:
>   Body2
>   *** H3
>   Body3
>   *** H4 :export:
>   Body4
>    H5
>   Body5
> 
> will be seen as
> 
>   Text before first headline
>   * H1
>   Body1
>   ** H4
>   Body4
>   *** H5
>   Body5

I’m confused.  In the text, you say “promoted to the root level of the
tree”, which I expect to mean promotion to a top-level headline.  In the
example, though, H4 is promoted to second-level.  Do you mean “promoted
to the level of the highest dominating :noexport: headline”?  That seems
correct to me (but I have not thought about it extensively).

Regardless, I like it very much.

> 
> This is not inlining, since "Body2" is lost anyway, and it may require
> to tag all children of a given headline, but it's already better than
> the current situation, is robust enough for inclusion in core, and
> doesn't require introducing a plethora of new special tags.

I think under your proposal it would be possible to add a single special
tag which is equivalent (by definition) to tagging a headline noexport
and all its children export.  This could be implemented as a parse tree
transformation adding the (no)export tags at an early stage in the export
code.

I agree with Mark and others that “ignore” (or some variant like
“exportignore” or “ignoreheading”) are better names for this tag than
“inline”.  My vote, FWIW, is that the level of sustained user interest
justifies the inclusion of this new tag.  But I hope it will not be too
burdensome, since it just serves as a sort of syntactic sugar and
doesn’t require any substantial new semantics (beyond your proposal for
the extension of (no)export).  To borrow your example, this would look
like:

  Text before first headline
  * H1
  Body1
  ** H2 :ignore:
  Body2
  *** H3
  Body3
  *** H4
  Body4
   H5
  Body5

exports to:

  Text before first headline
  * H1
  Body1
  ** H3
  Body3
  ** H4
  Body4
  *** H5
  Body5

(Note lack of “Text2”)

-- 
Aaron Ecay

Re: [O] proposal to have ignoreheading tags/properties

[Nicolas Goaziou]

Hello,

Mark Edgington  writes:

> If I understand your example correctly, it seems like you are assuming that
> the :inline: tag should promote a section's contents to the level *above*
> the level of the section having the :inline: tag.

I'm always assuming the worst.

> To me this behavior doesn't make sense, and that's also not what
> I would expect such a tag to do -- instead, the section's text
> (anything which comes before the next headline at any level) should be
> merged with the text of the nearest preceding headline. Then all
> nested headlines contained in the :inline: section should be promoted.
>
> It is true that this could sometimes be confusing.  For example:
>
>   * A
>   text1
>   ** B
>   text2
>   * C  :inline:
>   text3
>   ** D
>   text 4
>
> would get treated like:
>
>   * A
>   text1
>   ** B
>   text2
>   text3
>   * D
>   text 4
>
> In this case, one would likely omit 'text3' from the first part of the
> example, since it doesn't make much sense to have it there.  For the most
> part, though, it would be a behavior that makes sense (e.g. if "* C" were
> replaced with "** C" in the example).

As I said, you cannot solve that confusing situation in the general
case. If we allow the confusing part (i.e "text3") altogether, then my
suggestion still holds:

  - if you don't need to nest headlines, use a drawer.
  - if you do need sub-headings, extending :export: and :noexport: is
sufficient.

Example:

  * A
  text1
  ** B
  text2
  * C :noexport:
  text3
  ** D :export:
  text

If you really need the exact behaviour that you describe, I suggest to
extend the first answer to the relative FAQ so that it also promotes
sub-headings besides removing the headline.

> It may be that "inline" isn't the best word to describe this behavior, which
> is why something with "ignore" or "promotechildren" has been
> mentioned.

The fact that it's difficult to find a good descriptive name for that
feature is a good indication that it isn't meant for general
consumption. ;)


Regards,

-- 
Nicolas Goaziou

Re: [O] proposal to have ignoreheading tags/properties

[Aaron Ecay]

Hi Mark,

2014ko ekainak 14an, Mark Edgington-ek idatzi zuen:

[...]


> It is true that this could sometimes be confusing.  For example:
> 
>   * A
>   text1
>   ** B
>   text2
>   * C  :inline:
>   text3
>   ** D
>   text 4
> 
> would get treated like:
> 
>   * A
>   text1
>   ** B
>   text2
>   text3
>   * D
>   text 4

The problem with this example which Nicolas alludes to arises if B is
tagged noexport.  Then text3 will also be not exported, even though it
seems like it should be.

-- 
Aaron Ecay

Re: [O] proposal to have ignoreheading tags/properties

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> I’m confused.  In the text, you say “promoted to the root level of the
> tree”, which I expect to mean promotion to a top-level headline.  In the
> example, though, H4 is promoted to second-level.  Do you mean “promoted
> to the level of the highest dominating :noexport: headline”?  That seems
> correct to me (but I have not thought about it extensively).

Exactly. I meant "promoted to the root of the :noexport: tree", which is
basically what you describe.

> I think under your proposal it would be possible to add a single special
> tag which is equivalent (by definition) to tagging a headline noexport
> and all its children export.  This could be implemented as a parse tree
> transformation adding the (no)export tags at an early stage in the export
> code.

I'd rather not introduce more special tags, if possible.

I think that this feature should be implemented with :export:/:noexport:
before we start pondering about the relevance of some syntactic sugar.

There are other ways to handle "same tag on all children", e.g., an
interactive function.


Regards,

-- 
Nicolas Goaziou

[O] Creating project-wide navigation, org links in HTML preamble

[psycho_punch]

I'm trying to find a way to dynamically create navigation links on my notes
published as HTML pages. I've seen the TOC on the official org manual,
which is something I'd also be fine with, but I'm not sure how to create
such project-wide TOC. At the moment, I'm looking for a way to add
navigation links in my HTML preamble but it only accepts HTML. Something
like,

[[file:~/Documents/org-project/home.org][Home]] |
[[file:~/Documents/org-project/science/index.org][Science]] |
[[file:~/Documents/org-project/philosophy/index.org][Philosophy]]

What I really want is for my notes to be able to provide navigation to
anywhere in my project. Notes should be aware of what directory they are
in, and provide links to home, and to other directories. As much as
possible I want it to be automatically inserted upon publishing as I want
the notes to remain as simple org notes as I can make them to be.

Is there a relatively simple way to achieve this?

Re: [O] #+BEAMER not defined?

[Sebastien Vauban]

Hi Nicolas and Bastien,

Bastien wrote:
> Sebastien Vauban writes:
>
>> - the construct #+Beamer_BEGIN/END exists, but not #+Beamer?
>
> Your subconscious wants something that does not exists :)

Though I still don't understand the results I got with my ECM, here is
a right ECM...

--8<---cut here---start->8---
#+OPTIONS: H:1

** ECM

#+BEGIN_Beamer
\bold{BeamerFoo}
#+END_Beamer

#+BEAMER: \bold{BeamerBar}

#+BEGIN_LaTeX
\bold{LaTeXBaz}
#+END_LaTeX

#+LaTeX: \bold{LaTeXFooBar}
--8<---cut here---end--->8---

... which acts as EXPECTED.

Sorry for my mental confusion -- must have been very very tired.

Best regards,
  Seb

-- 
Sebastien Vauban

[O] navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Charles Berry]

Start with emacs -q, then load today's org-mode.

Execute the source block in this file:

=== start of file

#+NAME: AAA
#+BEGIN_SRC x

#+END_SRC


#+BEGIN_SRC emacs-lisp :results raw output
  (let ((i ?a))
(while (< i ?z)
  (princ (format "* %s\n\n\n#+NAME: %s\n\n" 
 (char-to-string i) 
 (char-to-string i)))
  (setq i (1+ i

#+END_SRC


#+NAME: BBB
#+BEGIN_SRC x

#+END_SRC

=== end of file

Now try 

C-c C-v g AAA RET
C-c C-v g BBB RET
C-c C-v n

or 

M-x occur RET \+name RET

then try to click on each of the matches in the *Occur* buffer.
The first few work, then failure set in. Seems like local moves of
a few lines work, but longer jumps fail.

I've tried using edebug on org-reveal. When I step through by pressing
'n', occur works fine. When I skip stepping by pressing 'c', it often fails.


What gives?

Chuck

p.s.

Org-mode version 8.2.7 (release_8.2.7-1096-g23496c [...]
GNU Emacs 24.3.1 [...]

[O] [RFC] [PATCH] org-mtags: remove

[Aaron Ecay]

* contrib/lisp/org-mtags.el: Delete file.
* lisp/org.el (org-structure-template-alist): Remove -style tags.
(org-complete-expand-structure-template): Don't handle -style tags.
---
 contrib/lisp/org-mtags.el | 255 --
 lisp/org.el   |  43 
 2 files changed, 20 insertions(+), 278 deletions(-)
 delete mode 100644 contrib/lisp/org-mtags.el

The recent discussion of org-structure-template-alist[1] made me take
a look at that variable, and I realized it includes infrastructure for
an outdated method of using -style tags instead of canonical org
syntax.  The implementation in contrib was never updated to the new
exporter, and the approach seems out of line with the goals of that
project.  So this patch removes this extension from core and contrib.

Does anyone have an opinion on whether this is a good idea?

Thanks,
Aaron

[1] http://mid.gmane.org/87egz0sbfc@gmail.com

diff --git a/contrib/lisp/org-mtags.el b/contrib/lisp/org-mtags.el
deleted file mode 100644
index 5342184..000
--- a/contrib/lisp/org-mtags.el
+++ /dev/null
@@ -1,255 +0,0 @@
-;;; org-mtags.el --- Muse-like tags in Org-mode
-
-;; Copyright (C) 2008-2014 Free Software Foundation, Inc.
-;;
-;; Author: Carsten Dominik 
-;; Keywords: outlines, hypermedia, calendar, wp
-;; Homepage: http://orgmode.org
-;; Version: 0.01
-;;
-;; This file is not yet part of GNU Emacs.
-;;
-;; This program is free software; you can redistribute it and/or modify
-;; it under the terms of the GNU General Public License as published by
-;; the Free Software Foundation; either version 3, or (at your option)
-;; any later version.
-
-;; This program is distributed in the hope that it will be useful,
-;; but WITHOUT ANY WARRANTY; without even the implied warranty of
-;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-;; GNU General Public License for more details.
-
-;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs.  If not, see .
-;
-;;
-;;; Commentary:
-;;
-;; This modules implements some of the formatting tags available in
-;; Emacs Muse.  This is not a way if adding new functionality, but just
-;; a different way to write some formatting directives.  The advantage is
-;; that files written in this way can be read by Muse reasonably well,
-;; and that this provides an alternative way of writing formatting
-;; directives in Org, a way that some might find more pleasant to type
-;; and look at that the Org's #+BEGIN..#+END notation.
-
-;; The goal of this development is to make it easier for people to
-;; move between both worlds as they see fit for different tasks.
-
-;; The following muse tags will be translated during export into their
-;; native Org equivalents:
-;;
-;;   
-;;Needs to be at the end of a line.  Will be translated to "\\".
-;;
-;;   
-;;Needs to be on a line by itself, similarly the  tag.
-;;Will be translated into Org's #+BEGIN_EXAMPLE construct.
-;;
-;;   
-;;Needs to be on a line by itself, similarly the  tag.
-;;Will be translated into Org's #+BEGIN_QUOTE construct.
-;;
-;;   
-;;Needs to be on a line by itself, similarly the  tag.
-;;Will be translated into Org's #+BEGIN_COMMENT construct.
-;;
-;;   
-;;Needs to be on a line by itself, similarly the  tag.
-;;Will be translated into Org's #+BEGIN_VERSE construct.
-;;
-;;   
-;;This gets translated into "[TABLE-OF-CONTENTS]".  It will not
-;;trigger the production of a table of contents - that is done
-;;in Org with the "#+OPTIONS: toc:t" setting.  But it will define
-;;the location where the TOC will be placed.
-;;
-;;   ;; only latex, html, and docbook supported
-;;in Org.
-;;Needs to be on a line by itself, similarly the  tag.
-;;
-;;   
-;;Needs to be on a line by itself, similarly the  tag.
-;;Will be translated into Org's BEGIN_SRC construct.
-;;
-;;   
-;;Needs to be on a line by itself.
-;;Will be translated into Org's #+INCLUDE construct.
-;;
-;; The lisp/perl/ruby/python tags can be implemented using the
-;; `org-eval.el' module, which see.
-
-(require 'org)
-
-;;; Customization
-
-(defgroup org-mtags nil
-  "Options concerning Muse tags in Org mode."
-  :tag "Org Muse Tags"
-  :group 'org)
-
-(defface org-mtags; similar to shadow
-  (org-compatible-face 'shadow
-'class color grayscale) (min-colors 88) (background light))
-   (:foreground "grey50"))
-  (((class color grayscale) (min-colors 88) (background dark))
-   (:foreground "grey70"))
-  (((class color) (min-colors 8) (background light))
-   (:foreground "green"))
-  (((class color) (min-colors 8) (background dark))
-   (:foreground "yellow"
-  "Face for Muse-like tags in Org."
-  :group 'org-mtags
-  :group 'org

Re: [O] [FR] fill caption

[Aaron Ecay]

Hi Daniele,

2014ko ekainak 14an, Daniele Pizzolli-ek idatzi zuen:
> 
> Hello @ll,
> 
> I noticed that multi line caption works as expected, but there is no
> way to fill it (at least to my knowledge).
> 
> I added a test case that should speak by itself.
> 
> I do not know a lot of elisp, but if you have some pointer I could try
> to implement it by myself.
> 
> Maybe this could be extended to handle also OPTIONS and LocalWords
> and others.

I have the following function in my org-mode-hook:

(defun awe-org-setup-fill-hook ()
  (make-local-variable 'filladapt-token-table)
  (make-local-variable 'filladapt-token-match-table)
  (make-local-variable 'filladapt-token-conversion-table)
  (cl-pushnew `(,(rx "#+" (or "caption" "CAPTION") ": ") org-caption)
  filladapt-token-table :test #'equal)
  (cl-pushnew '(org-caption org-caption)
  filladapt-token-match-table :test #'equal)
  (cl-pushnew '(org-caption . exact)
  filladapt-token-conversion-table :test #'equal))

It uses filladapt  to fill
caption keywords properly (it doesn’t handle the case of short captions,
since these are complicated, as Nicolas points out in his reply).

There’s a warning in the Org manual about using filladapt with org, but
I’ve never noticed any problems.

If you use ispell’s facility for adding to LocalWords (pressing A
(i.e. shift+a) at the spelling correction prompt, or “Accept (buffer)”
in the context menu), it will handle breaking the LocalWords lines for
you.

Hope this is useful,

-- 
Aaron Ecay

Re: [O] proposal to have ignoreheading tags/properties

[Aaron Ecay]

Hi Nicolas,

2014ko ekainak 14an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> I’m confused.  In the text, you say “promoted to the root level of the
>> tree”, which I expect to mean promotion to a top-level headline.  In the
>> example, though, H4 is promoted to second-level.  Do you mean “promoted
>> to the level of the highest dominating :noexport: headline”?  That seems
>> correct to me (but I have not thought about it extensively).
> 
> Exactly. I meant "promoted to the root of the :noexport: tree", which is
> basically what you describe.
> 
>> I think under your proposal it would be possible to add a single special
>> tag which is equivalent (by definition) to tagging a headline noexport
>> and all its children export.  This could be implemented as a parse tree
>> transformation adding the (no)export tags at an early stage in the export
>> code.
> 
> I'd rather not introduce more special tags, if possible.
> 
> I think that this feature should be implemented with :export:/:noexport:
> before we start pondering about the relevance of some syntactic sugar.

I understand your point about gradualism.

> 
> There are other ways to handle "same tag on all children", e.g., an
> interactive function.

I think a parse tree filter might work better, since then there is no
possibility of the tags inadvertently getting out of sync.  But either
way, it will be easy to implement based on the extension to (no)export
functionality you proposed.

Thanks,

-- 
Aaron Ecay

Re: [O] still seeing semi-regular lockups

[Daimrod]

Nicolas Goaziou  writes:

> Daimrod  writes:
>
>> My guess is that the lockup happens in `org-element--cache-key-less-p',
>> called by `org-element--cache-process-request'.
>
> Probably, but it doesn't mean that this particular function is buggy.
> The lockup happens there because the cache gets corrupted at some point.

I see.

> After investigating a little while, it appears that switching
> input-method to "latin-postfix" alone is sufficient to corrupt it.
> Though, setting `org-element-cache-sync-idle-time' to a high value
> prevents the problem, which means that the corruption happens only when
> cache is synchronized during idle time.

Ok.

> That's where I am for the time being. I don't know much about input
> methods, so I have no clue about the reasons behind this. I'm still
> investigating.

I would help if I knew about input-methods or the caching mechanism, but
I do not. :-(

Thanks for investigating.

Best,

-- 
Daimrod/Greg

Re: [O] [PATCH] Add DEVONthink Pro to Org Mac Link

[Anthony Lander]

Hi Mike,

Thank you for extending org-mac-link. Much appreciated!

And thank you Bastien for taking care of applying the patch.

Have a good weekend,

 -Anthony


On Sat, Jun 14, 2014 at 8:48 AM, Bastien  wrote:

> Hi Mike,
>
> Mike-Personal  writes:
>
> > I have attached the patch to this email.
>
> Applied, thanks.  I updated the changelog:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c57ecf26
>
> --
>  Bastien
>
>

[O] [PATCH] Remove restriction when locating markers

[Bernt Hansen]

* org-macs.el: Remove restriction when locating markers

Allows org-with-point-at to locate point outside the current
restriction.
---
 lisp/org-macs.el |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index ddd6e2e..96265ec 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -154,9 +154,9 @@ We use a macro so that the test can happen at compilation 
time."
 `(let ((,mpom ,pom))
(save-excursion
 (if (markerp ,mpom) (set-buffer (marker-buffer ,mpom)))
-(save-excursion
-  (goto-char (or ,mpom (point)))
-  ,@body)
+(org-with-wide-buffer
+ (goto-char (or ,mpom (point)))
+ ,@body)
 (def-edebug-spec org-with-point-at (form body))
 (put 'org-with-point-at 'lisp-indent-function 1)
 
-- 
1.7.9.48.g85da4d