Jude DaShiell | 1 Jun 2011 03:47

getting org-mode to display its version

Is this possible?  I think when I export a web page, I'd like to have a 
line like: Exported by org-mode version x.y.z ondate ... in that way 
org-mode can get well deserved credit.

Jambunathan K | 1 Jun 2011 03:59
Picon

Re: getting org-mode to display its version

Jude DaShiell <jdashiel <at> shellworld.net> writes:

> Is this possible?  I think when I export a web page, I'd like to have a 
> line like: Exported by org-mode version x.y.z ondate ... in that way 
> org-mode can get well deserved credit.

Isn't it already? You are talking of creator info down below.

,----
| org-export-html-postamble is a variable defined in `org-html.el'.
| Its value is auto
| 
| Documentation:
| Non-nil means insert a postamble in HTML export.
| 
| When `t', insert a string as defined by the formatting string in
| `org-export-html-postamble-format'.  When set to a string, this
| string overrides `org-export-html-postamble-format'.  When set to
| 'auto, discard `org-export-html-postamble-format' and honor
| `org-export-author/email/creator-info' variables.  When set to a
| function, apply this function and insert the returned string.
| The function takes the property list of export options as its
| only argument.
| 
| Setting :html-postamble in publishing projects will take
| precedence over this variable.
| 
| You can customize this variable.
| 
| [back]
(Continue reading)

Steven Haryanto | 1 Jun 2011 03:53
Picon

Re: A simpler way to write literal examples?

On Wed, May 25, 2011 at 10:25 PM, Nick Dokos <nicholas.dokos <at> hp.com> wrote:
Steven Haryanto <stevenharyanto <at> gmail.com> wrote:

> I plan to document some parts of Perl source code (more specifically, description in subroutine
> Sub::Spec specification, http://search.cpan.org/dist/Sub-Spec) using Org format instead of the
> canonical POD, hoping to have better table support, more customizable links, and overall markups
> that are nicer to look at (IMO).
>
> However, one of the nice things of POD (and Wiki, Markdown, etc) for documenting source code is the
> relative simplicity of writing literal examples: an indented paragraph. In Org we either have to use
> the colon+space prefix syntax:
>
>  : this is an example
>  : another line
>  : another line
>
> or the example block:
>
>  #+BEGIN_EXAMPLE
>  this is an example
>  another line
>  another line
>  #+END_EXAMPLE
>
> Is there an alternative syntax? If there isn't, would people consider an alternative syntax (e.g.
> say a setting which toggles parsing an indented paragraph as a literal example)?
>

What is the problem with #+BEGIN_EXAMPLE/#+END_EXAMPLE? IOW, why do you need
an alternative syntax? If your answer is "too much typing", check out
section 15.2, "Easy templates", in the Org manual.

The problem is visual clutter (yes, I guess Emacs can be told to hide the markup, but I'm talking about when text is displayed as-is and/or outside Emacs) and copy-pasteability (especially with the colon syntax). I know Org format is not optimized for fixed width section, but perhaps there is a way?

--
sh
ishi soichi | 1 Jun 2011 05:10
Picon

Google Analytics tracking code for org-export-as-html

Hi. I would like to add a Google Analytics tracking code to the exported html file from an org-file.

According to the instruction of GAnalytics, the tracking code must be right before "</head>" tag. And I assume it's OK as long as the code is between <head> and </head>.

The tracking code needs to be in the html file every time I export it as html.  So, I need to somehow add the code segment in the org-file.

#+BEGIN_HTML
...
#+END_HTML

This seems to add whatever between to a location after <body> tag. 

Is there anyway to achieve this?

soichi
Mark Cox | 1 Jun 2011 07:17
Picon

[PATCH] Common Lisp source blocks are now wrapped in a LET form which binds the symbol *default-pathname-defaults* to the directory in which the org file resides.

Hi,

This may be contentious and break backward compatibility for some people.

Currently, relative pathnames in Common Lisp source blocks are
meaningless as the *default-pathname-defaults* symbol is set to
whatever the value is when SLIME was invoked. This behaviour is
contrary to the shell source block processor (I haven't checked the
others).

This is in /tmp/example1/test.org
#+begin_src sh
pwd
#+end_src

#+results:
: #P"/tmp/example1/"

This is in /tmp/example2/test.org
#+begin_src sh
pwd
#+end_src

#+results:
: #P"/tmp/example2/"

The attached patch brings this expected behaviour (well from my point
of view) to lisp source blocks. Given the behaviour of Emacs commands
like DIRED and COMPILE, I think the patch makes things more
consistent.

I couldn't figure out how the sh block processor determines the path
to the org file so I hacked together something that works using some
of the Org hooks.

Thanks
Mark

lisp/ob-lisp.el: Added new variable ORG-BABEL-LISP-CURRENT-BUFFER
which is used to store a reference to the currently being processed org file.
This variable is setq'd in the hooks for
ORG-BABEL-PRE-TANGLE-HOOK, ORG-CTRL-C-CTRL-C-HOOK and
ORG-EXPORT-FIRST-HOOK.

lisp/ob-lisp.el (org-babel-expand-body:lisp): The code sent to SLIME
is now wrapped in a LET block which binds
COMMON-LISP:*DEFAULT-PATHNAME-DEFAULTS* to the directory where the
currently being processed org file resides.

diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index a875d55..db06182 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
 <at>  <at>  -40,6 +40,14  <at>  <at> 

 (defvar org-babel-default-header-args:lisp '())
 (defvar org-babel-header-arg-names:lisp '(package))
+(defvar org-babel-lisp-current-buffer nil)
+
+(let ((fn (lambda ()
+           (setq org-babel-lisp-current-buffer (current-buffer))
+           nil)))
+  (dolist (hook '(org-babel-pre-tangle-hook org-ctrl-c-ctrl-c-hook
org-export-first-hook))
+    (add-hook hook fn)))
+

 (defun org-babel-expand-body:lisp (body params)
   "Expand BODY according to PARAMS, return the expanded body."
 <at>  <at>  -73,8 +81,10  <at>  <at> 
                (read (org-bable-lisp-vector-to-list (cadr result)))
              (error (cadr result)))))
       (slime-eval `(swank:eval-and-grab-output
-                   ,(format "(progn %s)" (buffer-substring-no-properties
-                                          (point-min) (point-max))))
+                   ,(format "(let
((common-lisp:*default-pathname-defaults* #P%S)) %s)"
+                            (file-name-directory (buffer-file-name
org-babel-lisp-current-buffer))
+                            (buffer-substring-no-properties
+                             (point-min) (point-max))))
                  (cdr (assoc :package params)))))
    (org-babel-pick-name (cdr (assoc :colname-names params))
                        (cdr (assoc :colnames params)))

Tomas Hlavaty | 1 Jun 2011 07:06
Favicon

Re: Google Analytics tracking code for org-export-as-html

Hi soichi,

> Hi. I would like to add a Google Analytics tracking code to the
> exported html file from an org-file.

ah, please don't do that.

> code is between <head> and </head>.

You could sneak it in using #+STYLE or org-publish-project-alist :style.

Cheers,

Tomas

Carsten Dominik | 1 Jun 2011 08:30
Picon

Re: Broken LaTeX export of tables


On 31.5.2011, at 19:16, suvayu ali wrote:

> Hi,
> 
> I think LaTeX export of tables broke sometime between these two commits

Thanks for the report, this works again now.

- Carsten

> 
> Works:
> 
> commit 2a8fbc4b464d10dda3ceebf70e4f99825f179dd5
> Author: Carsten Dominik <carsten.dominik <at> gmail.com>
> Date:   Mon May 16 08:36:56 2011 +0200
> 
>    Bury calendar buffer
> 
>    * lisp/org.el (org-read-date): Bury Calendar buffer after
>    using it for selecting a date.
> 
>    Patch by Ben North
> 
>    TINYCHANGE
> 
> 
> Stopped working:
> 
> commit bc161ded3693f752616dcd247fc9d638789025ee
> Author: Carsten Dominik <carsten.dominik <at> gmail.com>
> Date:   Fri May 27 20:50:09 2011 +0200
> 
>    Capture: Store time from prompt in file+datetree+prompt target
> 
>    * lisp/org-capture.el (org-capture-current-plist): Improve docstring.
>    (org-capture-put): Add docstring.
>    (org-capture-get): Add docstring.
>    (org-capture-member): Add LOCAL argument. Add docstring.
>    (org-capture-set-target-location): Store the time received from a date
>    prompt into the :prompt-time property.
> 
>    When using the file+datetree+prompt target for capture, the time set
>    by the prompt is now stored in the :prompt-time property.
> 
> I have attached a minimal org file reproducing the problem. The problem
> is subscripts and superscripts inside a table are not put inside math
> environments when exporting to LaTeX.
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.
> <test.org><test.tex>

David Maus | 1 Jun 2011 09:16
Picon

Re: [bug, babel] export corruption bug and 3 more bugs

At Fri, 27 May 2011 07:15:10 -0700,
Samuel Wales wrote:
>
> Hi David,
>
> Thank you.  I am unable to debug this further so I appreciate it.

I've just pushed a fix for compatibility with Emacs22 and the
`activate-mark' function.

> Were you able to reproduce the corruption bug?  Did anybody else?
> Emacs -Q, minimal test case.

I suppose I reproduced the corruption bugs: It's the Babel regexp
problem.

>
> Is it necessary to construct this regexp for babel if babel is not used?
>

Suppose so. A temporary work-around could be

(setq org-babel-data-names nil)

before you load Org. This will cause Babel to not create the offending
regexp.

HTH,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena <at> jabber.org
Email..... dmaus <at> ictsoc.de
Carsten Dominik | 1 Jun 2011 09:29
Picon

Re: A simpler way to write literal examples?


On 25.5.2011, at 11:43, Steven Haryanto wrote:

> I plan to document some parts of Perl source code (more specifically, description in subroutine
Sub::Spec specification, http://search.cpan.org/dist/Sub-Spec) using Org format instead of the
canonical POD, hoping to have better table support, more customizable links, and overall markups that
are nicer to look at (IMO).
> 
> However, one of the nice things of POD (and Wiki, Markdown, etc) for documenting source code is the
relative simplicity of writing literal examples: an indented paragraph. In Org we either have to use the
colon+space prefix syntax:
> 
>  : this is an example
>  : another line
>  : another line
> 
> or the example block:
> 
>  #+BEGIN_EXAMPLE
>  this is an example
>  another line
>  another line
>  #+END_EXAMPLE
> 
> Is there an alternative syntax? If there isn't, would people consider an alternative syntax (e.g. say a
setting which toggles parsing an indented paragraph as a literal example)?

No, since indentation has other uses in org (for example for list structure).
I find it often helps to write #+begin_example instead of #+BEGIN_EXAMPLE.
I guess one could set up font-lock to hide the #+begin and #+end lines, but
how would you then change them.
The bug advantage in Org is that you can say
#+begin_src perl
to get correct indentation and syntax highlighting to the language of the snippet.....

- Carsten

Sebastien Vauban | 1 Jun 2011 09:36

Re: Some remarks on org-contacts

Hi Sven and al,

"Sven Bretfeld" wrote:
> After some days of using org-contacts with Gnus, I would like to make
> some comments. I know that this is an early stage of the development,
> but I think some views and suggestions by users could help Julien or
> other developers to decide what could be done in the next steps of their
> work. There seems to be no roadmap on the homepage of the project.
>
> - The buffers displaying the contacts file(s) get the "changed mark"
>   whenever something is done with org-contacts. Even if only a name was
>   searched and no changes have happened at all. Is it a bug or some
>   feature that I don't understand?
>
> - The last-read-mail property is a good idea, but it has the
>   disadvantage of changing the file. People using Dropbox or other
>   synchronization tools have a problem here, because they have to
>   remember to manually save the file before they start to work on
>   another computer. There should be an auto-save-hook or something
>   similar. 
>
> - What I deem most important: For quite a few contacts most people will
>   use to have more than one email address. Org-contacts stores all
>   addresses under the same property with no preference on one of them
>   (unlike BBDB which uses the first entry as a default for completion).
>   It is annoying to hit tab 3 to 4 times before the To-header is
>   complete. It would perhaps be best to have only one address in the
>   EMAIL property and to store alternate addresses in another property
>   (SECONDARY_EMAIL). The SECONDARY_EMAIL could be called by a special
>   function that could be set to a key different from TAB (maybe C-u
>   TAB). Maybe it is even possible to expand to the default address by
>   hitting TAB once, and to give a list of the other addresses by hitting
>   TAB once again.
>
> - What can you do with ICONS? Arte they only for chatting? It would be
>   nice to have a small window automatically opening below an Article
>   buffer in Gnus that displays information about the author including
>   his/her image.
>
> - Email, phone numbers and postal address should be displayed in the
>   Agenda buffer when a name is searched by org-contacts. Maybe it would
>   be possible to display different information by hitting certain keys:
>   "m": mobile-phone, "e": email, "b": birthday, "a": all etc. At the
>   moment one has to switch on follow-mode to display the information. I
>   deem this not very beautiful. For my taste, the look-and-feel of an
>   org-file with lots of property lines is not an aesthetic pleasure. A
>   tabular output (including a picture of the person) would be much
>   nicer.
>
> - There should be a function to sort the entries of the same level in
>   contacts files alphabetically.
>
> Thank you very much for org-contacts.

And the cherry on the cake would be: snarfing data from received email, asking
the user what to do when a new email address is detected for a known contact,
or a new name detected for a known email address...

Having those definitely would make org-contacts more powerful than BBDB --
though, I don't know what's planned in v3 of BBDB.

Best regards,
  Seb

--

-- 
Sebastien Vauban


Gmane