Re: [BUG] error after reading in contents of other file [9.6 (9.6-??-e7ea951 @ /home/user/.emacs.d/.local/straight/build-28.0.50/org/)]

[Mark Edgington]

On Sat, Mar 12, 2022 at 7:53 AM Ihor Radchenko  wrote:
>
> Thanks for the report!
> Are you still seeing the traceback if you update Org to latest main?
> 5da9d6810 in more recent versions should help with some cases when the
> error like in your backtrace appears.

Yes, I'm still getting the following:

Emacs  : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2022-01-15
Package: Org mode version 9.6 (9.6-??-e7ea951ac @
/home/user/.emacs.d/.local/straight/build-28.0.50/org/)
Warning (org-element-cache): org-element--cache: Org parser error in
FOO-test.org::21. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
nil

[BUG] error after reading in contents of other file [9.6 (9.6-??-e7ea951 @ /home/user/.emacs.d/.local/straight/build-28.0.50/org/)]

[Mark Edgington]

I manually opened a new daily file, and read in some content from
another file (using ':r filename.txt' with Evil).  After doing this, the
content was inserted, but the following traceback occurred:

Warning (org-element-cache): org-element--cache: Org parser error in 
2022-03-10.org::193. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-element-context()
  (and t (org-element-context))
  (let* ((context (and t (org-element-context))) (path (and context 
(org-element-property :path context (if path (let* ((val 
(org-element-property :type context))) (cond ((equal val '\"kbd\") (let nil 
(format \"%s %s\" (propertize \"Key sequence:\" ... ...) (propertize ... ... 
... ((equal val '\"doom-module\") (let nil (format \"%s %s\" (propertize 
\"Doom module:\" ... ...) (propertize ... ... ... ((equal val 
'\"doom-package\") (let nil (format \"%s %s\" (propertize \"Doom package:\" ... 
...) (propertize ... ... ... (t (let ((type val)) (format \"Link: %s\" 
(org-element-property :raw-link context
  +org-display-link-in-eldoc-a(#f(compiled-function (string  plist) 
#))
  apply(+org-display-link-in-eldoc-a #f(compiled-function (string  plist) 
#))
  org-eldoc-documentation-function(#f(compiled-function (string  plist) 
#))
  eldoc-documentation-default()
  eldoc--invoke-strategy(nil)
  eldoc-print-current-symbol-info()
  #()
  apply(# nil)
  timer-event-handler([t 0 0 50 nil # nil idle 0])
"



Emacs  : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo version 1.16.0)
 of 2022-01-15
Package: Org mode version 9.6 (9.6-??-e7ea951 @ 
/home/user/.emacs.d/.local/straight/build-28.0.50/org/)

current state:
==
(setq
 org-link-elisp-confirm-function nil
 org-directory "~/org/"
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-crypt-key nil
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]
 org-roam-mode-hook '(+org-roam-detach-magit-section-mode-map-h 
turn-on-visual-line-mode)
 org-roam-dailies-capture-templates '(("d" "daily" plain 
#'org-roam-capture--get-point "" :immediate-finish t :kill-buffer t :file-name 
"dailies/%<%Y-%m-%d>" :head "#+TITLE: %<%Y-%m-%d>\n%(org-time-stamp-inactive 
'(16))\n\n"))
 org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h +org-init-attachments-h +org-init-babel-h 
+org-init-babel-lazy-loader-h +org-init-capture-defaults-h 
+org-init-capture-frame-h
 +org-init-custom-links-h +org-init-export-h +org-init-habit-h 
+org-init-hacks-h +org-init-keybinds-h +org-init-popup-rules-h 
+org-init-protocol-h +org-init-protocol-lazy-loader-h +org-init-smartparens-h
 +org-init-roam-h)
 org-startup-folded nil
 org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
 org-link-abbrev-alist '(("doom-repo" . 
"https://github.com/hlissner/doom-emacs/%s;) ("wolfram" . 
"https://wolframalpha.com/input/?i=%s;) ("wikipedia" . 
"https://en.wikipedia.org/wiki/%s;)
 ("duckduckgo" . "https://duckduckgo.com/?q=%s;) 
("gmap" . "https://maps.google.com/maps?q=%s;) ("gimages" . 
"https://google.com/images?q=%s;) ("google" . "https://google.com/search?q=;)
 ("youtube" . "https://youtube.com/watch?v=%s;) 
("github" . "https://github.com/%s;))
 org-agenda-files '("~/org/")
 org-capture-templates '(("t" "Personal todo" entry (file+headline 
+org-capture-todo-file "Inbox") "* [ ] %?\n%i\n%a" :prepend t)
 ("n" "Personal notes" entry (file+headline 
+org-capture-notes-file "Inbox") "* %u %?\n%i\n%a" :prepend t)
 ("j" "Journal" entry (file+olp+datetree 
+org-capture-journal-file) "* %U %?\n%i\n%a" :prepend t) ("p" "Templates for 
projects")
 ("pt" "Project-local todo" entry (file+headline 
+org-capture-project-todo-file "Inbox") "* TODO %?\n%i\n%a" :prepend t)
 ("pn" "Project-local notes" entry (file+headline 
+org-capture-project-notes-file "Inbox") "* %U %?\n%i\n%a" :prepend t)
 ("pc" "Project-local changelog" entry (file+headline 
+org-capture-project-changelog-file "Unreleased") "* %U %?\n%i\n%a" :prepend t) 
("o" "Centralized templates for projects")
 ("ot" "Project todo" entry 
#'+org-capture-central-project-todo-file "* TODO %?\n %i\n %a" :heading "Tasks" 
:prepend nil)
 ("on" "Project notes" entry 
#'+org-capture-central-project-notes-file "* %U %?\n %i\n %a" :heading "Notes" 
:prepend t)
 ("oc" "Project changelog" entry 
#'+org-capture-central-project-changelog-file "* %U %?\n %i\n %a" :heading 
"Changelog" :prepend t))
 

Re: [O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

Ken, I believe Bastien's signing comment was also directed towards me, and
I am fine with signing a FSF assignment document, but this had simply
gotten buried in my emails.

I do still have it on my list to take a look at this at some point, but if
one of you is inclined to merge it, by all means do!  I don't think I've
needed to change the function I've been using for this (works with a
relatively recent org-mode release).  But it sounds like you're saying that
it won't work with the latest git versions?

Regards,

Mark


On Thu, Mar 28, 2019, 2:14 PM Ken Mankoff  wrote:

>
> On Tue, May 1, 2018 at 11:01 AM Bastien  wrote:
>
>> Hi Mark,
>>
>> Mark Edgington  writes:
>>
>> > I don't know why not -- I'm OK with the code being used in
>> > org-archive.el.  As far as I'm concerned, you can use it however you
>> > wish (it is based on Ken's code though, so he would also need to sign
>> > off on its use, I suppose).
>>
>> Would you like to contribute by submitting a patch against master?
>>
>> For this you would need to sign FSF copyright assignment.
>>
>> See http://orgmode.org/request-assign-future.txt
>>
>>
> Replying to an email almost 1 year old. I've lost archive-to-subtree
> functionality recently and don't know how to get it back w/ the recent Org
> code changes. While searching I found this old thread where Mark & Bastien
> suggest I'd need to sign off on someone using some code I pasted. I got
> that code from elsewhere, and only did minor customizations. In my original
> email I link to where I got the code from (
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-08/msg00109.html ).
> I don't think I have the rights to sign off on this, but sure, you can use
> what I pasted and my customizations. I've signed the FSF documents already,
> a long time ago. It seems like archive-to-subtree should be a core
> functionality, and if someone were to get that working again I'd be happy
> to test and use it.
>
>   -k.
>

Re: [O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

Hi Bastien,

On Thu, Apr 26, 2018 at 7:34 PM, Bastien  wrote:

> I'd be interested in integrating such a functionality in
> org-archive.el.
>
> Do you think that is feasible?


I don't know why not -- I'm OK with the code being used in org-archive.el.
As far as I'm concerned, you can use it however you wish (it is based on
Ken's code though, so he would also need to sign off on its use, I suppose).

Regards,

Mark

Re: [O] FILETAGS tags hidden by TAGS option

[Mark Edgington]

Hi Nicolas,

>>
>> For example, with the following options, the foo tag will not show up
>> when trying to do tab-completion, but only bar and baz will:
>>
>> #+TAGS:  bar baz
>> #+FILETAGS:  foo
>
> FWIW, I cannot reproduce it (from master, I didn't check maint). You may
> want to update Org and try again.

Thanks for the suggestion, and sorry, I should have tried updating
first.  This issue apparently has been fixed in 9.1, as I am also
unable to reproduce it with 9.1 installed.

Regards,

Mark

[O] FILETAGS tags hidden by TAGS option

[Mark Edgington]

When using org-tags-view, the list of tags used for tab-completion
fails to include tags specified via the #+FILETAGS option when there
exists a #+TAGS option in the file which doesn't contain the
#+FILETAGS tags.

For example, with the following options, the foo tag will not show up
when trying to do tab-completion, but only bar and baz will:

#+TAGS:  bar baz
#+FILETAGS:  foo

Is this the expected behavior?  A "workaround" is to simply add foo to
#+TAGS, but should this be necessary?

Re: [O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

While further evaluating my code, I realized that it wasn't working
when target headlines contained tags.  I've updated the code to handle
this case -- the result is posted as a gist since it may change later
on, and all of you esteemed elisp hackers can more easily contribute
to it that way, until it's worthy to be considered for inclusion in
contrib.

Here's the gist URL:

  https://gist.github.com/edgimar/072d99d8650abe81a9fe7c8687c0c993

Re: [O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

On Mon, Feb 12, 2018 at 1:54 AM, Ken Mankoff  wrote:
>
> Does the attached file here work for you? I use it and it seems to do what 
> you describe.
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-08/msg00109.html
>

Ken, I tried the code you included from your config file, and while it does
satisfy my requirement 2 (the subtree will be merged into an existing path
under the target if an appropriate path already exists), the first requirement
of it being moved to be "beneath" a specified target location seems not to be
working correctly.

I've modified your code so that it can at least handle archiving subtrees
beneath a specified target headline.  The new code assumes that the specified
target headline is at level 1 (has a single asterisk), but it would be nice if
this could be made to work with a target headline having a larger depth.  Note
that I changed the behavior from what you had so that hierarchical archiving is
used whether or not the target is in the current buffer.

Although archiving is a bit less painful for me now with this new code, there
are still a few things it would be nice to have:

 - arbitrary-depth target-headline
 - option to prefix target-headline with source filename (this probably won't 
take too much work)
 - option to add archival properties to each archived item (e.g. date archived)


Here's a diff from the code you posted:

--- old 2018-02-12 10:14:07.646226775 -0500
+++ new 2018-02-12 14:51:20.676703024 -0500
@@ -1,18 +1,11 @@
-(setq org-archive-location (concat org-directory "/archive/%s_archive::"))
+; (setq org-archive-location (concat org-directory "/archive/%s_archive::"))
+(setq org-archive-location "archive/archived_%s::")
 
+; unmap org-archive-subtree
 (define-key org-mode-map (kbd "C-c C-x C-s") nil)
-(setq org-archive-default-command 'kdm/org-archive-local-or-hierarchical) ;; 
C-c C-x C-a
 
-;; only do hierarchical archiving if default var used. If archiving into
-;; local file, then just use default org-archive-subtree command
-(defun kdm/org-archive-local-or-hierarchical ()
-  "Archive locally if location set to local file; Otherwise use 
org-archive-subtree-hierarchical"
-  (interactive)
-  (if (let ((arch-file (org-extract-archive-file))
-(this-file (buffer-file-name)))
-   (equal arch-file this-file))
-  (org-archive-subtree)
-  (org-archive-subtree-hierarchical)))
+; select command to execute via org-archive-subtree-default (C-c C-x C-a)
+(setq org-archive-default-command 'org-archive-subtree-hierarchical)
 
 (require 'org-archive)
 
@@ -23,16 +16,17 @@
 (buffer-substring-no-properties
  (line-beginning-position) (line-end-position
 
-(defun org-child-list ()
+(defun org-child-list ( top-level)
   "This function returns all children of a heading as a list. "
   (interactive)
   (save-excursion
 ;; this only works with org-version > 8.0, since in previous
 ;; org-mode versions the function (org-outline-level) returns
 ;; gargabe when the point is not on a heading.
-(if (= (org-outline-level) 0)
-(outline-next-visible-heading 1)
-  (org-goto-first-child))
+(unless top-level
+(if (= (org-outline-level) 0)
+(outline-next-visible-heading 1)
+(org-goto-first-child)))
 (let ((child-list (list (line-content-as-string
   (while (org-goto-sibling)
 (setq child-list (cons (line-content-as-string) child-list)))
@@ -68,6 +62,11 @@
 infile-p (equal file (abbreviate-file-name (or afile ""
   (unless afile
 (error "Invalid `org-archive-location'"))
+  (if (not (equal heading ""))
+  (progn
+(setq org-tree (cons heading
+   (mapcar (lambda (s) (concat "*" s)) org-tree)))
+(org-demote-subtree)))
   (if (> (length afile) 0)
   (setq newfile-p (not (file-exists-p afile))
 visiting (find-buffer-visiting afile)
@@ -79,16 +78,18 @@
   (set-buffer buffer)
   (org-mode)
   (goto-char (point-min))
+  (setq top-level-p t)
   (while (not (equal org-tree nil))
-(let ((child-list (org-child-list)))
+(let ((child-list (org-child-list top-level-p)))
   (if (member (car org-tree) child-list)
   (progn
-(search-forward (car org-tree) nil t)
+(re-search-forward (concat "^" (regexp-quote (car org-tree))) 
nil t)
 (setq org-tree (cdr org-tree)))
 (progn
-  (newline)
+  (if (not top-level-p) (newline))
   (org-insert-struct org-tree)
-  (setq org-tree nil)
+  (setq org-tree nil
+(setq top-level-p nil))
   (newline)
   (org-yank)
   ;; Save and kill the buffer, if it is not the same buffer.
@@ -103,5 +104,6 @@
   (interactive)
   (when struct
 (insert (car struct))
-(newline)
+(if  (not (equal (length struct) 1))
+

[O] CI for worg

[Mark Edgington]

Is there any kind of build-server connected with publishing org-mode
documentation and/or the worg website?  I ask because I have seen
problems like the dead link here:

https://orgmode.org/worg/org-contrib/babel/languages.html

(which is referred to in https://orgmode.org/worg/org-contrib/babel).
Things like this should be possible to avoid by having appropriate
tests / checks run on committed code or pull-requests.

Also, on a related note, it seems to me like there should be a
standalone build-script or Makefile for publishing the worg org-files
to a local html_export folder -- that way contributors can at least
check that everything publishes correctly on their own machines before
pushing changes.

It may be that the dead link above has nothing to do with committed
changes, and is just a server configuration problem, but having some
kind of testing/CI in place still makes sense to have.

[O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

Hello all,

I have looked at a few threads related to the archiving of subtrees,
but haven't found anything that matches what I think would be a very
sensible archiving behavior.  I already posted this as a question on
the emacs stack-exchange site
(https://emacs.stackexchange.com/questions/38530/how-to-archive-an-org-mode-subtree-along-with-its-parent-headlines),
but realize that the mailing list is probably more likely to get some
feedback from people.  So here's what I'm trying to figure out how to
do:

Say I start with an org-file that looks like:

#+ARCHIVE: ::* Archived

* Foo
  * Tasks
* Task1
  * Thoughts
* Thought1
* Thought2

* Archived

Now I put the point (i.e. cursor) on Thought1 and run
org-super-archive (the magical command I'm hoping to find). The result
should be:

#+ARCHIVE: ::* Archived

* Foo
  * Tasks
* Task1
  * Thoughts
* Thought2

* Archived
  * Foo
* Thoughts
  * Thought1

Now I move the point to Thought2 and again run org-super-archive,
which should give me:

#+ARCHIVE: ::* Archived

* Foo
  * Tasks
* Task1
  * Thoughts

* Archived
  * Foo
* Thoughts
  * Thought1
  * Thought2

So the basic operation I'm seeking is the ability to archive a subtree
to whatever target location is specified with #+ARCHIVE (or
org-archive-location) where (1) the full path of the archived subtree
is mirrored beneath that target location, and (2) the subtree will be
merged into an existing path under the target if an appropriate path
already exists (e.g. a path consisting of all of the subtree's parent
headlines, regardless of the content of the bodies of these
headlines).

As an added bonus, it would be nice if it were possible to choose
whether or not the "full path" of a subtree to be archived will
include the org-file name as the root of the path. This would be
useful in cases where you archive from multiple org-files to a single
archive.org file.

Any thoughts on this -- has it already been done, or would it be easy to do?

Re: [O] Blank lines in LaTeX output due to org-mode comments

[Mark Edgington]

On Thu, Jun 30, 2016 at 5:23 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Mark Edgington <edgi...@gmail.com> writes:
>
>> I'm inclined to view it more as a bug, because it makes it impossible to
>> place comments within a paragraph.
>
> This is per Org syntax. "# ..." is not meant as an inline paragraph. You
> can comment inline with something like @@comment:...@@.

For me, using the "@@comment:..@@" syntax gives exactly the same
results as using "# ..." (an extra blank line in the output).  Of
course I can do something like "#+LaTeX: % ..." which will work, but
then the convenience of being able to quickly comment and uncomment
lines is lost.

Regardless of what the current org syntax is defined as, I am trying
to argue that it is counter-intuitive, and also makes doing useful
things difficult.

Re: [O] Need to update documentation to reflect export block syntax

[Mark Edgington]

Kaushal Modi  gmail.com> writes: 
>   Mark The online documentation corresponds to the stable releases of
org-mode only.
> The master branch is the dev branch. The only way to access the latest
documentation is via the Info manual (M-x info in emacs to access that is
the best way IMO).

Thanks, I see that now -- I had mistakenly assumed that because the current
stable release date was later than the date of Nicolas' commit, that it had
been included in the release.

Re: [O] Blank lines in LaTeX output due to org-mode comments

[Mark Edgington]

One other use case:  when you want to comment out a single line in a
paragraph, or have a few different lines within a paragraph that you wish to
be able to select among by leaving only only one of them uncommented.

Re: [O] Blank lines in LaTeX output due to org-mode comments

[Mark Edgington]

Nicolas Goaziou  nicolasgoaziou.fr> writes:
> Mark Edgington  gmail.com> writes:
> 
> > Assume we have the following sample org-mode document:
> >
> > * Test Heading
> > test test test test test test test
> > test test test test test test test
> > test test test test test test test
> > # HERE IS A COMMENT
> > TEST TEST TEST TEST TEST TEST TEST
> > TEST TEST TEST TEST TEST TEST TEST
> > TEST TEST TEST TEST TEST TEST TEST
> >
> > I would assume that in org-mode the comment line would be completely
> > ignored when exporting the document, however this seems not to be the
> > case -- notice the difference when exporting the following to LaTeX:
> 
> The behavior is correct. Actually, what you suggest was reported as
> a bug a couple of years ago. Comments separate paragraphs, so you really
> have two paragraphs in the first example, but only one in the second
> example.
> 
> You can handle comments differently by adding a function in, e.g.
> `org-export-before-processing-hook', that will take care of removing
> commented lines. These are easy to recognize. See
> `org-export--delete-comments' for an example.

I'm inclined to view it more as a bug, because it makes it impossible to
place comments within a paragraph.  Paragraphs consist of sentences, and
perhaps you'd like to make a note related to one of those sentences (in fact
I do).

On the other hand, if the behavior was to not create blank lines, it
wouldn't be difficult to add a blank line either before or after a comment
if desired.  Furthermore, the behavior is inconsistent with how LaTeX
comments behave (which may not matter, but it may be easier for people who
know both org-mode and LaTeX for the behavior to be consistent).

At the least, I think it would be helpful to have a built-in option that
allows one to select the preferred behavior.

[O] Blank lines in LaTeX output due to org-mode comments

[Mark Edgington]

Assume we have the following sample org-mode document:

* Test Heading
test test test test test test test
test test test test test test test
test test test test test test test
# HERE IS A COMMENT
TEST TEST TEST TEST TEST TEST TEST
TEST TEST TEST TEST TEST TEST TEST
TEST TEST TEST TEST TEST TEST TEST

I would assume that in org-mode the comment line would be completely
ignored when exporting the document, however this seems not to be the
case -- notice the difference when exporting the following to LaTeX:

* Test Heading
test test test test test test test
test test test test test test test
test test test test test test test
TEST TEST TEST TEST TEST TEST TEST
TEST TEST TEST TEST TEST TEST TEST
TEST TEST TEST TEST TEST TEST TEST

In the first example, there is a blank line inserted at the location
of the comment, and in the second example, obviously there is not a
blank line at this location.  Let me know if there's a way to make it
so that org-mode doesn't insert the blank line.  Thanks!

Re: [O] Need to update documentation to reflect export block syntax

[Mark Edgington]

It also might be worthwhile to have org-mode warn users (at least for a
number of new releases) who happen to be using the old format, explaining
that they need to use the new one to avoid problems when exporting.

[O] Need to update documentation to reflect export block syntax

[Mark Edgington]

I recently updated my org-mode git repository (for a long time I've
had an older git version that I was using), and I am now having
problems when doing latex exports.

I bisected with git to find that the "problem" starts with this revision:

commit 54318add34f09ff39d3fd034a4c1a89f60fd8759
Author: Nicolas Goaziou 
Date:   Tue Feb 3 16:16:54 2015 +0100

Change export block syntax

It seems that #+begin_latex is no longer supported, and that when
using it, it results in escaped latex comment symbols (e.g. \% in the
tex file instead of just %), as well as \begin{latex} and \end{latex}
in the exported code.

If it is no longer supported, then it is important that the org-mode
documentation be updated (see e.g.
http://orgmode.org/manual/Quoting-LaTeX-code.html ), since those using
the latest release will have trouble exporting using the old syntax.

Re: [O] org-export-with-broken-links doesn't apply to footnotes

[Mark Edgington]

Nicolas Goaziou  nicolasgoaziou.fr> writes:

> No, it isn't. However I could only reproduce it with empty footnote
> definitions.
> 
> In any case, this is now fixed. Thank you.

I am providing a minimal example that still exhibits the problem for me (on
the latest git rev):

--- BEGIN EXAMPLE ---
* Heading 1   :ignore:
** Heading 2  :export:
*** Heading 3 :ignore:
Here's a footnote[fn:20].

* Footnotes   :export:
[fn:20] Footnote content.
--- END EXAMPLE ---

If you narrow the buffer to Heading 2, and try to export, it fails.

Among other things, I have the following in my .emacsd file:

(require 'ox-extra)
(ox-extras-activate '(ignore-headlines))

[O] org-export-with-broken-links doesn't apply to footnotes

[Mark Edgington]

The org-export-with-broken-links option was introduced in order to
allow exports to proceed when a link isn't able to be resolved.
Sometimes this happens when trying to export a narrowed region of a
buffer.

I have noticed, however, that even if I have (setq
org-export-with-broken-links 't), I am still unable to export a
narrowed buffer that contains a footnote reference ("Definition not
found for footnote...").  Is this behavior intentional?  If so, is
there a way to get the same effect as org-export-with-broken-links for
footnotes?

Regards,

Mark

Re: [O] Restoring the org-freemind-to-org-mode function

[Mark Edgington]

On Dec 21, 2015 5:14 AM, "Vaidheeswaran C" <
vaidheeswaran.chinnar...@gmail.com> wrote:
>
> Note: I would like to ensure that the file moves out of it's current
> obscure place in contrib/lisp of Orgmode to a more visible place like
> GNU ELPA before I expend any efforts on improving it.

Why is ELPA less obscure than org-contrib?  It would seem that every org
mode installation (e.g. Ubuntu packages) will include the org-contrib
source files, though they aren't enabled by default.  Not including then in
org-contrib will effectively remove them from all debian based Linux
distributions, and from git based installations..

ELPA is a fine place for it, but does it require for it to not be in
contrib?

Re: [O] Restoring the org-freemind-to-org-mode function

[Mark Edgington]

On Dec 17, 2015 8:36 AM, "Nicolas Goaziou"  wrote:
>
> org-freeming.el was replaced with ox-freeming.el, in contrib directory.
> You may want to contact its author (which may not read this list) and
> discuss if it would be possible to include the feature in that library
> instead.
>

Hi Nicolas,

I can certainly do that, but it seems like the wrong place for it, unless
there's some precedent for it.  ox-anything should be associated with the
export from org-mode, and not the import into it, if I'm not mistaken.
Maybe it's appropriate to have oi-something libraries?

Regards,

Mark

[O] Restoring the org-freemind-to-org-mode function

[Mark Edgington]

I have in the past used the org-freemind-to-org-mode function, which
is no longer included in org-mode.  It used to be part of
org-freemind.el file (see
http://orgmode.org/w/org-mode.git?p=org-mode.git;a=blob_plain;f=lisp/org-freemind.el;hb=8f49547aaf0f9396f2a0bcfb25ce2c33be5e91fd
).

I have since tried this function, and it does still work, so I am
wondering if we could add it back into the org-mode source tree.  I am
attaching a stripped-down version of org-freemind.el in which most of
the code that is irrelevant to org-freemind-to-org-mode has been
removed.

Regards,

Mark
;;; org-freemind.el --- Export Org files to freemind

;; Copyright (C) 2009-2012 Free Software Foundation, Inc.

;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Keywords: outlines, hypermedia, calendar, wp
;; Homepage: http://orgmode.org
;;
;; This file is part of GNU Emacs.
;;
;; GNU Emacs 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 of the License, or
;; (at your option) any later version.

;; GNU Emacs 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 .

;; 
;; Features that might be required by this library:
;;
;; `backquote', `bytecomp', `cl', `easymenu', `font-lock',
;; `noutline', `org', `org-compat', `org-faces', `org-footnote',
;; `org-list', `org-macs', `org-src', `outline', `syntax',
;; `time-date', `xml'.
;;
;;
;;
;;; Commentary:
;;
;; This file tries to implement some functions useful for
;; transformation between org-mode and FreeMind files.
;;
;; Here are the commands you can use:
;;
;;M-x `org-freemind-from-org-mode'
;;M-x `org-freemind-from-org-mode-node'
;;M-x `org-freemind-from-org-sparse-tree'
;;
;;M-x `org-freemind-to-org-mode'
;;
;;M-x `org-freemind-show'
;;
;;
;;
;;; Change log:
;;
;; 2009-02-15: Added check for next level=current+1
;; 2009-02-21: Fixed bug in `org-freemind-to-org-mode'.
;; 2009-10-25: Added support for `org-odd-levels-only'.
;; Added y/n question before showing in FreeMind.
;; 2009-11-04: Added support for #+BEGIN_HTML.
;;
;;; Code:

(require 'xml)
(require 'org)
	;(require 'rx)
;(require 'org-exp)
(eval-when-compile (require 'cl))

(defgroup org-freemind nil
  "Customization group for org-freemind export/import."
  :group 'org)

;; Fix-me: I am not sure these are useful:
;;
;; (defcustom org-freemind-main-fgcolor "black"
;;   "Color of main node's text."
;;   :type 'color
;;   :group 'org-freemind)

;; (defcustom org-freemind-main-color "black"
;;   "Background color of main node."
;;   :type 'color
;;   :group 'org-freemind)

;; (defcustom org-freemind-child-fgcolor "black"
;;   "Color of child nodes' text."
;;   :type 'color
;;   :group 'org-freemind)

;; (defcustom org-freemind-child-color "black"
;;   "Background color of child nodes."
;;   :type 'color
;;   :group 'org-freemind)

(defvar org-freemind-node-style nil "Internal use.")

(defcustom org-freemind-node-styles nil
  "Styles to apply to node.
NOT READY YET."
  :type '(repeat
  (list :tag "Node styles for file"
(regexp :tag "File name")
(repeat
 (list :tag "Node"
   (regexp :tag "Node name regexp")
   (set :tag "Node properties"
(list :format "%v" (const :format "" node-style)
  (choice :tag "Style"
  :value bubble
  (const bubble)
  (const fork)))
(list :format "%v" (const :format "" color)
  (color :tag "Color" :value "red"))
(list :format "%v" (const :format "" background-color)
  (color :tag "Background color" :value "yellow"))
(list :format "%v" (const :format "" edge-color)
  (color :tag "Edge color" :value "green"))
(list :format "%v" (const :format "" edge-style)
  (choice :tag "Edge style" :value bezier
  (const :tag "Linear" linear)
  (const :tag "Bezier" bezier)
  (const :tag "Sharp Linear" sharp-linear)

[O] Comment lines interfere with figure options

[Mark Edgington]

If I have some org-mode content that looks like this...

#+NAME: fig-myimage
#+CAPTION: Caption of Figure
#+ATTR_LaTeX: :width 5cm
#+RESULTS: myimage
[[file:images/myimage.png]]

then I get a centered figure with the appropriate width and caption
when exporting to LaTeX.  If, however, I add a comment (or two)
in-between one of the option-lines...

#+NAME: fig-myimage
#+CAPTION: Caption of Figure
# (this was the original width)
# +ATTR_LaTeX: width 10cm
#+ATTR_LaTeX: :width 5cm
#+RESULTS: myimage
[[file:images/myimage.png]]

then all of the settings above the comments are lost.  Would it be
difficult to modify org-mode so that comment-lines are ignored when
looking for a block of settings lines that precede an image?  This
seems like sensible behavior to me, and there are cases when it would
be convenient to annotate the options you've used, or to temporarily
replace one option-line with another by commenting one out.

Re: [O] org-collector unable to handle macros

[Mark Edgington]

Aaron Ecay  gmail.com> writes:

> 
> This looks like the same problem I reported (and provided a patch for) here:
> .  Some orgtbl-*
> functions can’t cope with macro (or macro-resembling) text, because they
> use the exporter, which expects all macros to have valid definitions.
> 
> Hopefully this time the bug can actually get fixed, instead of becoming
> bogged down in irrelevant aspects of the context in which it is
> reported.
> 

The link you provided doesn't seem to be a valid URL.  Can you check it, and
post a new one?

Re: [O] org-collector unable to handle macros

[Mark Edgington]

Nicolas Goaziou  nicolasgoaziou.fr> writes:

> 
> Mark Edgington  gmail.com> writes:
> 
> > On Aug 31, 2015 6:43 PM, "Nicolas Goaziou"  nicolasgoaziou.fr>
wrote:
> >>
> >> Hello,
> >>
> >> Mark Edgington  gmail.com> writes:
> >> >
> >> > Have you (or anyone else) been able to reproduce the problem given the
> >> > example which I provided?  Is this indeed a bug, or am I
> > misunderstanding
> >> > something?
> >>
> >>   :INCLASS:  ABC {{{c(stuff)}}} DEF
> >>
> >> looks incorrect. Macros are not expanded in node properties (with an
> >> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).
> >
> > It is not intended to be expanded when generating the table, but the table
> > should have the macro in it, so that it gets expanded when the table is
> > exported.
> 
> OK. Then another problem:
> 
>   :ID: sched_table
> 
> ID properties are meant to be set with `org-id'. What about using
> CUSTOM_ID instead?

Hi Nicolas,

Can you explain what you mean about using CUSTOM_ID in the context of
org-collector?  Maybe I misunderstood something.  Do you think the reason
that a table can't be generated from my example code is that org-collector
is somehow trying to expand the macros when the table is generated?  I
assume that the correct behavior should be for it to *not* expand macros,
and just pass them through verbatim into the table-fields.

Regards,

Mark

Re: [O] org-collector unable to handle macros

[Mark Edgington]

Charles Millar  verizon.net> writes:

> This may be related to the problem or is the same that I reported in 
> April and May and again earlier this month when Bastien's requested 
> details in his August 4th message.

Have you (or anyone else) been able to reproduce the problem given the
example which I provided?  Is this indeed a bug, or am I misunderstanding
something?

Re: [O] org-collector unable to handle macros

[Mark Edgington]

On Aug 31, 2015 6:43 PM, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> Mark Edgington <edgi...@gmail.com> writes:
>
> > Charles Millar  verizon.net> writes:
> >
> >> This may be related to the problem or is the same that I reported in
> >> April and May and again earlier this month when Bastien's requested
> >> details in his August 4th message.
> >
> > Have you (or anyone else) been able to reproduce the problem given the
> > example which I provided?  Is this indeed a bug, or am I
misunderstanding
> > something?
>
>   :INCLASS:  ABC {{{c(stuff)}}} DEF
>
> looks incorrect. Macros are not expanded in node properties (with an
> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).

It is not intended to be expanded when generating the table, but the table
should have the macro in it, so that it gets expanded when the table is
exported.

Re: [O] org-collector unable to handle macros

[Mark Edgington]

> >>
> >>   :INCLASS:  ABC {{{c(stuff)}}} DEF
> >>
> >> looks incorrect. Macros are not expanded in node properties (with an
> >> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).
> >
> > It is not intended to be expanded when generating the table, but the
table
> > should have the macro in it, so that it gets expanded when the table is
> > exported.
>
> OK. Then another problem:
>
>   :ID: sched_table
>
> ID properties are meant to be set with `org-id'. What about using
> CUSTOM_ID instead?

When using CUSTOM_ID, I get the following message (and the table generation
fails):

condition-case: (error Cannot find entry with :ID: sched_table)

Is this not the case for you?  I have enabled org-collector via M-x
customize-variable  org-modules.

[O] org-collector unable to handle macros

[Mark Edgington]

I have had problems getting org-collector.el to generate tables where the
content of the tables should include macros.  At some point in the past this
worked, but at this time (latest git version of org-mode), the following
example fails (unless you remove the macro from the property definition):

# comment-macro
#+MACRO: c 

* Notes
:PROPERTIES: 
:ID: sched_table
:COLUMNS:  %WEEKNUM(Week #) %DAY(Day) %INCLASS(In-class Content)
%READINGS(Readings) %PRECLASS(Pre-class Assignments / Homework)
:END:
** WEEK 1
*** DAY
:PROPERTIES:
:INCLASS:  ABC {{{c(stuff)}}} DEF
:DAY:  T
:WEEKNUM:  1
:END:
blah

* Schedule
# type C-c C-c on the #BEGIN line to attempt to generate the table
#+BEGIN: propview :id sched_table :defaultval  :conds ((not (string= DAY
))) :cols (WEEKNUM DAY INCLASS READINGS PRECLASS) :noquote t :colnames
(Week # Day In-class Content Readings Pre-class Assignments / Homework)

#+END:


Any help in resolving this problem would be appreciated!  Thanks.

[O] bad interaction between yasnippet and org-mode

[Mark Edgington]

I have a yas snippet that looks like the following:

*  $1   :sometag:
$0

When I try to expand this snippet (on an empty line) in an org-mode
buffer, there seems to be a bad interaction happening between org-mode
and yasnippet, such that when entering in text at the $1 location,
typing something like abc results in a b c  being inserted (spaces
get interspersed).

This behavior does not happen if there is no tag at the end of the
headline, or if the $1 is replaced with $0 (so yas mode is exited
after expanding the snippet).

I'm using yas 0.8.0beta (latest git), and Org-mode 8.3beta
(release_8.3beta-1206-g2f0bcc)

Is there a way to work around or fix this?

[O] Bug: todo states not logged to drawer when using narrowed indirect buffer [8.3beta (release_8.3beta-1203-g93cc5f) ]

[Mark Edgington]

To reproduce this bug, do the following:

1.  edit / open the following org file:

#+TODO: TODO(t) WAIT(w!) | DONE(d!) CANCELED(c!)
#+STARTUP: logdrawer
* testing A
some stuff
* testing B

2.  execute (org-tree-to-indirect-buffer) on the 'testing A' headline

3.  go to the end of the indirect buffer, and add a new headline.  for example:

* testing C

4. change the TODO state of this new headline to TODO, and then to WAIT.

You should now notice that a drawer was created in the initial
(non-indirect) buffer, but is not visible in the indirect buffer.
Furthermore, the logged state change appears *above* the drawer, and
not inside it.


Emacs  : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.9)
 of 2015-03-21 on kissel, modified by Debian
Package: Org-mode version 8.3beta (release_8.3beta-1203-g93cc5f @
/home/edgimar/.emacs.d/scripts/org-mode/lisp/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
  org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook org-show-block-all append
local]
   5]
 #[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] LaTeX_HEADER blocks

[Mark Edgington]

I noticed there was also a newer thread (around a year old) on this
topic.  It seems that what Nicolas Goaziou proposed earlier (about
using #+attr_latex to modify whether a latex block is a header block
or not) has not yet been implemented.  This would be an alternative,
though I find it more cryptic than just having a #+begin_latex_header
block, so it would probably be more difficult for org-mode users to
find (or remember) this, and as I mentioned in my last message, it
lacks the benefit of consistency with how #+latex and #+begin_latex
relate to each other.

Nicolas' message is here:

http://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00841.html.

[O] LaTeX_HEADER blocks

[Mark Edgington]

Hi Everyone,

It is possible in org-mode to do either

#+LaTeX: \somecommand

or

#+BEGIN_LaTeX
\somecommand
#+END_LaTeX

I typically use the latter (the block form) because I often have
multiple lines of LaTeX I would like to include at certain locations
of a document.

Similar to #+LaTeX, there is also #+LaTeX_HEADER, which ensures that
something is included as part of the preamble.  Unfortunately,
however, there is no equivalent block form for #+LaTeX_HEADER.  As a
result, when there are several items one wishes to have in the
preamble, it's necessary to have many such lines, each with a
#+LaTeX_HEADER:  prefix.

For the sake of consistency and convenience, wouldn't it be worthwhile
to add a LaTeX_HEADER block type to accompany the LaTeX block
type?

It seems like this was proposed a couple years ago by Eric Fraga, but
didn't go anywhere because of concerns over how to decide where to
place the content of such blocks relative to the content of
#+LaTeX_HEADER lines.  It would seem sensible to make it work
identically to how #+LaTeX lines and #+BEGIN_LaTeX blocks work -- they
are simply included in the order in which they are encountered in the
org file.

Regards,

Mark

Re: [O] math in footnotes not exported correctly when a buffer is narrowed

[Mark Edgington]

Rasmus rasmus at gmx.us writes:
 
 It was fixed a while ago in master.  Are you using 8.2?


Oh, I thought I was using something more recent, since the version was named
8.3beta, but apparently that's old.  Thanks!

A slight digression:  I noticed, when cloning the git repo, that the current
repo size is around 67 MB.  That seems somewhat large for a repo consisting
primarily of source code (when all the source compresses to under 3MB). 
Have there been discussions about splitting the repository so that older
content is relegated to a 'historic' repo?  Also, org.el is nearly 1MB in
size, which is crazy -- maybe it could use some splitting also!

[O] math in footnotes not exported correctly when a buffer is narrowed

[Mark Edgington]

I've noticed a bug in org-mode's LaTeX exporting of footnotes when a
buffer is narrowed to a particular section.  To reproduce, try to
export the following org-file to a LaTeX document, and inspect the
resulting LaTeX code -- it will have stripped the math environment off
of \tau_s:


* Test Section
Here we test whether the footnote is exported correctly [1].  Be sure to narrow
the buffer to this section only before doing a LaTeX export.
* Footnotes
[1] $\tau_s$ is blah blah blah.


Let me know if there's a workaround for this (apart from just don't
narrow the buffer).  Thanks!

Regards,

Mark

[O] Babel blocks get unindented when making changes outside the blocks

[Mark Edgington]

Hello all,

Given the following code:
- BEGIN CODE -
* some headline
- blah
  - blah
- blah
  - blah
- blah
#+begin_src octave
first line

if (num = 2)
stuff
end
#+end_src

- blah
  # some comments
  #   more comments
  1. item 1
- END CODE -

If I go to the end of the 'item 1' line, and do 'M-x org-meta-return',
the code in the preceding source-block gets un-indented, so that it
looks like:

#+begin_src octave
first line

if (num = 2)
stuff
end
#+end_src

This behavior has been confirmed by another via IRC, and supposedly
the problem lies somewhere in org-list-struct-apply-struct.

I just wanted to report this strange behavior in the hope that someone
might have an idea on how to remedy it.

Regards,

Mark

[O] fontification of comment blocks (or any other kind of block)

[Mark Edgington]

It seems that there is nothing in place to allow the text inside blocks like:

#+BEGIN_COMMENT
...
#+END_COMMENT

from having its face customized.  It is possible to do this with quote and
verse blocks, only not comment blocks.  Would it be sensible to have a
default block face which applies to *any* block of the form

#+BEGIN_FOO
...
#+END_FOO

as long as it doesn't have a more specific face associated with it?

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

[Mark Edgington]

Hi Bastien,

I've attached a patch for ox-extra which doesn't yet include the
option for choosing specific tag names (the 'ignore' tag is currently
hard-coded).  Feel free to modify / commit it.

Regards,

Mark


On Tue, Jul 29, 2014 at 10:31 AM, Bastien b...@gnu.org wrote:
 Hi Nicolas,

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Filters are _not_ meant to be in core since they are hardly a generic
 solution for a class of problem. They are entry points for user-level
 hacking. Generic patches should operate at the parse tree level, not
 using regexps.

 Eric's filter, like any other filter, has flaws that cannot be fixed.
 Useful filters ought to be published in Worg, not included in core.

 Fair enough.

 Still, can someone add Eric's solution to contrib/lisp/ox-extra.el?

 Thanks,

 --
  Bastien
From 7b60eefcb21c2a62b1ab7f248f6a0b993d89cc4d Mon Sep 17 00:00:00 2001
From: Mark Edgington edgi...@gmail.com
Date: Sat, 2 Aug 2014 00:32:29 -0400
Subject: [PATCH] * ox-extra.el: add ignore-headlines filter

---
 contrib/lisp/ox-extra.el | 82 +++-
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-extra.el b/contrib/lisp/ox-extra.el
index f4f0b76..01368cb 100644
--- a/contrib/lisp/ox-extra.el
+++ b/contrib/lisp/ox-extra.el
@@ -23,6 +23,12 @@
 ;; are not part of org's core.  Call `ox-extras-activate' passing a
 ;; list of symbols naming extras, which will be installed globally in
 ;; your org session.
+;;
+;; For example, you could include the following in your .emacs file:
+;;
+;;(require 'ox-extra)
+;;(ox-extras-activate '(latex-header-blocks ignore-headlines))
+;;
 
 ;; Currently available extras:
 
@@ -35,6 +41,12 @@
 ;;   ...
 ;; #+end_latex
 
+;; - `ignore-headlines' -- allow a headline (but not its children) to
+;; be ignored.  Any headline tagged with the 'ignore' tag will be
+;; ignored (i.e. will not be included in the export), but any child
+;; headlines will not be ignored (unless explicitly tagged to be
+;; ignored), and will instead have their levels promoted by one.
+
 ;; TODO:
 ;; - add a function to org-mode-hook that looks for a ox-extras local
 ;;   variable and activates the specified extras buffer-locally
@@ -75,8 +87,76 @@
 	;; earlier in the file
 	(reverse positions)
 
+
+;; During export headlines which have the ignore tag are removed
+;; from the parse tree.  Their contents are retained (leading to a
+;; possibly invalid parse tree, which nevertheless appears to function
+;; correctly with most export backends) all children headlines are
+;; retained and are promoted to the level of the ignored parent
+;; headline.
+;;
+;; This makes it possible to add structure to the original Org-mode
+;; document which does not effect the exported version, such as in the
+;; following examples.
+;;
+;; Wrapping an abstract in a headline
+;;
+;; * Abstract:ignore:
+;; #+LaTeX: \begin{abstract}
+;; #+HTML: div id=abstract
+;;
+;; ...
+;;
+;; #+HTML: /div
+;; #+LaTeX: \end{abstract}
+;;
+;; Placing References under a headline (using ox-bibtex in contrib)
+;;
+;; * References :ignore:
+;; #+BIBLIOGRAPHY: dissertation plain
+;;
+;; Inserting an appendix for LaTeX using the appendix package.
+;;
+;; * Appendix   :ignore:
+;; #+LaTeX: \begin{appendices}
+;; ** Reproduction
+;; ...
+;; ** Definitions
+;; #+LaTeX: \end{appendices}
+;;
+(defun org-export-ignore-headlines (data backend info)
+  Remove headlines tagged \ignore\ retaining contents and promoting children.
+Each headline tagged \ignore\ will be removed retaining its
+contents and promoting any children headlines to the level of the
+parent.
+  (org-element-map data 'headline
+(lambda (object)
+  (when (member ignore (org-element-property :tags object))
+(let ((level-top (org-element-property :level object))
+  level-diff)
+  (mapc (lambda (el)
+  ;; recursively promote all nested headlines
+  (org-element-map el 'headline
+(lambda (el)
+  (when (equal 'headline (org-element-type el))
+(unless level-diff
+  (setq level-diff (- (org-element-property :level el)
+  level-top)))
+(org-element-put-property el
+  :level (- (org-element-property :level el)
+level-diff)
+  ;; insert back into parse tree
+  (org-element-insert-before el object))
+(org-element-contents object)))
+(org-element-extract-element object)))
+info nil)
+  data)
+
+;(add-hook 'org-export-filter-parse-tree-functions 'org-export-ignore-headlines)
+
 (defconst ox-extras
-  '((latex-header-blocks org-latex-header-blocks-filter org

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

[Mark Edgington]

Hi Bastien,

On Sun, Jul 27, 2014 at 1:21 PM, Bastien b...@gnu.org wrote:


 I suggest renaming ox-extra.el to ox-filters-extra.el and to have
 org-mode/lisp/ox-filters.el for filters that are important enough
 to be in core.


Your suggestion sounds sensible, but of course I'm biased, as I've been
using Eric's filter daily now (thanks Eric!), and would be pleased to have
something like this in core.

Regards,

Mark

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

[Mark Edgington]

Hi Rasmus,

Rasmus rasmus at gmx.us writes:

 
 Bastien bzg at gnu.org writes:
 
  I think Eric's filter is important enough to be in core, together
  with an option to let users decide what tag should be used instead
  of ignore (with ignore as a default).
 
 How about ignoreheading as this is already the appropriate tag for a
 similar type of action in ox-beamer.el?  See e.g. the variable
 org-beamer-environments-special and consider this awkward headline:
 
* my ignored headline :ignored:ignoreheading:
  Ignored in Beamer and in LaTeX
 

I am partial to ignore because it is simpler, and if manually typing in,
requires less effort.  But anyway, wouldn't it be the case that you would
only need to use ignore (and not also ignoreheading), since it would
filter out such headlines and ox-beamer wouldn't even see them?  If this
isn't the case, it would be sensible for things to work that way nonetheless.

Regards,

Mark

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

[Mark Edgington]

Nicolas Goaziou mail at nicolasgoaziou.fr writes:
 
 Moreover, that task is highly specific; I'm not convinced we should have
 a dedicated keyword for each of them. I'd rather have a simple solution
 for selective export problems, even if, as a generic solution, it may
 look clumsier.

Hi Nicolas,

I agree that the nested use of :export: and :noexport: symmetric is a good
feature to implement.  I think the main point of contention that I and
others may have is that even if the :ignoreexport: (or whatever you wish to
call it) tag is highly specific w.r.t. the variety of export/noexport
arrangements one can have, it is also highly useful.

While implementing a specific tag for this task may not be wise to implement
at this time, there should be *some* way that an org-mode user can avoid
being required to manually add export tags to every child of a noexport node
in order to achieve this summary node functionality.  In order to make it
possible to add a non-exported summary-node (i.e. a node which we might have
marked as :ignoreexport:) at any location in the tree without needing to add
N more tags for all of the children, one would need to somehow by default
have :export: tags implicit on all nodes, unless a :noexport: tag was on a
node which would override the behavior of the :export: tag.

Maybe there needs to be a way to decide whether a specific tag (i.e. on a
specific headline) will be applied recursively or not -- e.g. if the tag has
a * suffix appended to it, then it is applied to all descendants
recursively, but otherwise it applies only to the single headline it is on.
 Ultimately I see the problem of having to tag all of the children as
stemming from this default behavior of tags being recursive.  Having control
of their recursivitiy would alleviate the problem.

Regards,

Mark

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

[Mark Edgington]

Nicolas Goaziou mail at 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.

[O] proposal to have ignoreheading tags/properties

[Mark Edgington]

In using org-mode, there is one problem that has always irked me (and
is apparently also closely related to the FAQ How do I ignore a
headline?).  When I am writing something, I sometimes want to group
things by concept or by work to be done, or any other number of
groupings.  BUT I do not want these groupings to be part of the
exported document itself.  In fact, I would like it to be as if the
grouping did not exist at all (i.e. a headline that is ignored).

The problem with using an ignored headline for grouping things is that
it still does have an effect on exported document structure, in that
all of the elements contained inside / in the scope of the ignored
headline still keep their depth (one level deeper than the level of
the ignored headline).

What I want is for the nested items to have their levels all promoted
by one, so that it's truly as if the ignored headline wasn't there at
all, and that it invisibly wrapped around a group of items without
requiring them to have a deeper level.  Perhaps this could be done by
use of an ignoreheading and an ignoreheadingpromote tag (one
promotes the level of contained items, another doesn't), or some
equivalent set of properties that could be set on a headline.

Would there be any chance that something like this could be built in
to org-mode?  I think it would make it far more flexible in terms of
organizing things, making this organization process orthogonal to the
selection of sections/subsections of a document.

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

[Mark Edgington]

Thorsten Jolitz tjolitz at gmail.com writes:

 
 In a tree structure, when ignoring the parent node, it seems only
 logical that the siblings are ignored too. 
 
 You seem to use the wrong tool for the task (headlines), this looks like
 a perfect use case for TAGS, i.e. define your (concept) groups as
 tags. If these tags are not part of `org-export-exclude-tags' they won't
 affect exporting, but you can still use them to build your agenda or a
 sparse tree or so.
 

Why do you suppose this is the wrong tool?  It is a quite natural and
sensible tool, because it allows grouping, folding, and nesting collections
of items together.  I cannot do that with tags.  If you don't like the idea
of having a headline serve this purpose, then perhaps we can invent a new
kind of pseudo-headline which behaves in this way.  How would you propose
to use tags alone to do something like the following which allows folding
and unfolding the contents, without a lot of extra work? -- for example:

* Chapters about Topic A  :pseudo:
** Chapter 1 Title
** Chapter 2 Title
* Chapters about Topic B  :pseudo:
** Chapter 3 Title
List of interesting things:
*** items relevant to X   :pseudo:
- item 1
- item 2
- item 3
*** items relevant to Y   :pseudo:
- item 4
- item 5


Another example would be, say, if you wanted to divide up some kind of
text-file (e.g. source code, or prose), dividing it into groupings that make
sense to you, but not wanting to actually bring these changes into the
document's exported structure.  Here's an example of a letter:

* Addresses / date   :pseudo:
123 Cherry Lane
City, ST 12345

October 5, 2014

Ms. Jane Doe
Accounts Payable


* Greeting   :pseudo:
Dear Ms. Johnson:

* Body   :pseudo:
It has come to my attention that ..

* Closing:pseudo:
Sincerely,


John Doe

* Postscript :pseudo:
P.S. .


Perhaps one could make it so that when a headline bullet (sequence) has a
'#' character tacked on after the sequence, it is no longer a headline, but
a summary node having the property that it promotes the levels of all its
children.  It doesn't much matter to me *how* one makes such a node, but I
think the availability of nodes/headlines like this is important.

In any case, it's not clear that this is the wrong tool.  I would use it,
and for me (and presumably others) it would be the right (kind of) tool. 
Furthermore tags are limited by their brevity -- with a pseudo headline I
can describe a concept or category with much more detail / clarity.

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

[Mark Edgington]

Eric Schulte schulte.eric at gmail.com writes:

 Ken Mankoff mankoff at gmail.com writes:
 
  I don't think the word inline signifies that a heading will or won't
  be exported and/or its children promoted.
 
 
 Can you suggest a more intuitive/appropriate tag name?

Would it be possible / sensible to allow user-specified aliases for the
different canonical tags (whatever they turn out to be), just like it's
possible to specify tags other than noexport which will not be exported?

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

[Mark Edgington]

Eric Abrahamsen eric at ericabrahamsen.net writes:
 
 It looks like a groundswell for remove-andor-promote tags for headlines,
 but for the sake of argument let me propose the use of blocks. It seems
 to me that something like a generic block (a block that does nothing
 but delete its begin/end delimiters on export) fits the use-case better:
 

Consider the following:

* Test
#+begin_block abc
* test2
#+begin_block def
* test3
** test4 
#+end_block
** test5
#+end_block


Some remarks on this, and on blocks vs. headlines:

- For me, the above example ends up being indented very poorly with
org-indent-mode active.  Also folding the nested headlines swallows up the
end-block lines.

- I find that it's difficult to identify what belongs to what block, and the
need to have both start and end lines to delineate the blocks is a bit more
noisy and can be a pain to work with (what if I want to remove the abc
frame -- I will need not only to delete the begin line, but also to locate
where the corresponding end line is, and delete it as well).

- creating a block (manually, at least) requires more effort than creating a
headline (= more RSI).

- It also may be convenient at times to be able to remove the :promote:,
etc. tags in order to have the exporter include the grouping as part of the
exported document's structure.

- Likewise, what if I want to add a :noexport: tag so that all of the
content is ignored -- easy with headlines, more work to do the same thing
with a block.

[O] bug in org-element-footnote-definition-parser?

[Mark Edgington]

I have encountered the following error message when trying to export
to latex the attached example org file:

org-element-footnote-definition-parser: Invalid search bound (wrong
side of point)

What is curious is that changing the number of 's in [fn:1] to 2
instead of 3 allows it to compile.  Likewise, just changing the number
of 'words' in the second macro (5th column of the table) also can
eliminate the error and allow the document to compile.  Also, getting
rid of the #+BEGIN line also allows it to compile...

I have omitted the tree which contains data for generating the table,
which isn't relevant for reproducing the error / bug.  All of the
above comments are based on using git rev. 95416856 (Dec 26).

I also recently updated to d310a87605 (Jan 8), and instead get the error:

byte-code: Wrong number of arguments: #[(tree data) ...[binary
omitted]... [tree cl-struct-avl-tree--tags data avl-tree--do-delete 0
error avl-tree--cmpfun accessing a non-avl-tree- 2
avl-tree--dummyroot accessing a non-avl-tree- 1] 5
(/usr/share/emacs/23.3/lisp/emacs-lisp/avl-tree.elc . 14229)], 4

Is there something wrong with my org-file? -- it seems like it
shouldn't be so hard to get it to compile, and that the errors
shouldn't be so obscure.

Regards,

Mark
* Schedule
#+LATEX: {}\begin{landscape}
x x xx.
#+BEGIN: propview :id sched_table :defaultval  :conds ((not (string= A ))) :cols (A B C D E) :noquote t :colnames ( x xxx  xxx [fn:1] x xxx / [fn:2])
#+ATTR_LaTeX: :environment longtable :align lllp{3cm}l
|  x | xxx |  xxx  | [fn:1] | x xxx / [fn:2] |
|+-+---++|
|  x | x   |  {{{c(xxx)}}} |  x | x {{{c(xxx xx x xxx)}}} |
|+-+---++|
#+END:
#+LATEX: \end{landscape}

[fn:1]   
[fn:2] xx xx 


* File Options  :ARCHIVE:
** Export
#+LaTeX_HEADER: \usepackage[margin=0.75in]{geometry}
#+LaTeX_HEADER: \setlength{\marginparwidth}{1cm}
#+LaTeX_HEADER: \usepackage{lscape}
#+OPTIONS: toc:nil
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+OPTIONS: arch:nil
#+OPTIONS: ^:{}
** Macros
#+MACRO: c 

Re: [O] bug in org-element-footnote-definition-parser?

[Mark Edgington]

Nick Dokos ndokos at gmail.com writes:

 
 Nicolas Goaziou n.goaziou at gmail.com writes:
 
  Hello,
 
  Mark Edgington edgimar at gmail.com writes:
 
  I have encountered the following error message when trying to export
  to latex the attached example org file:
 
  org-element-footnote-definition-parser: Invalid search bound (wrong
  side of point)
 
 
 I 'm not sure but I believe this was a bug in emacs that Eli Zaretskii
 fixed recently.  You will need to update your emacs. In the git mirror I
 use, the commit appears like this:
 
 commit b2b5f414358a7835b56613f67d2b0278ee804290
 Author: Eli Zaretskii eliz at gnu.org
 Date:   Wed Jan 1 19:44:48 2014 +0200

Hi Nick,

I can confirm that updating emacs to 24.3.1 does eliminate the problem. 
But, what this means is that the problem will exist for any users who are
still using Emacs 23 -- and maybe this shouldn't concern anyone since
normally using bleeding-edge org-mode code would coincide with using newer
versions of emacs...

Regards,

Mark

Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together

[Mark Edgington]

On Wed, Dec 11, 2013 at 3:46 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote:
 Mark Edgington edgi...@gmail.com writes:

 [...]

 Is there any way that I can make it so that without a lot of hacks I
 can make the previews appear as white-on-black, and the PDFs print
 black on white?  Would something need to change with how org-mode
 handles previewing to make this possible?

[...]

 I think the key is the =org-format-latex-options= variable.  I have no
 idea whether this is used by the exporter or just for previewing LaTeX
 in org.

Hi Eric,

I tried modifying org-format-latex-options (and disabling the global
'gray' TikZ setting I had previously had) like you have it, where
:foreground and :background are specified explicitly, but the result
is the same as when :foreground and :background are set to 'default'
-- the electrical components aren't visible.

It seems like what is needed is an extra key in
org-format-latex-options that allows one to add the equivalent of
#+LaTeX_HEADER: options (which only apply when (pre)viewing fragments
within emacs.  Or is there some other way to make this work?

Regards,

Mark

Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together

[Mark Edgington]

Ok, I dug into the problem a little deeper, and it seems that it
really can be considered a bug in the circuitikz code -- in order to
remedy it for the present time, the circuitikz.code.tex file from this
package should be modified, and the line:

\ctikzset{color/.initial=black}

must be removed / commented-out.

Nonetheless, I do think that to make it easier for people to share
org-mode files that use packages that are in some way buggy, having a
way to specify #+LaTeX_HEADER options which only apply when generating
preview images would be useful, so that workarounds for bugginess
could be added on the org-mode side, instead of requiring all
collaborators to patch their buggy libraries / packages.

Regards,

Mark

Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together

[Mark Edgington]

Nicolas Goaziou n.goaziou at gmail.com writes:
 
 You can remove offending packages with `org-export-before-parsing-hook'
 if you don't want them to be used during the export process.
 

Yes, but I need the package which is buggy.  If I were to remove it, I
couldn't preview latex fragements or export a PDF file.

[O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together

[Mark Edgington]

Hello everyone,

Assume I have an org-mode file that contains the following:

--

#+OPTIONS: tex:imagemagick
#+LaTeX_HEADER: \usepackage[siunitx]{circuitikz}

* Test circuit
#+begin_lateX
\begin{circuitikz}[scale = 1.0] \draw
(0,0) node[anchor=east]{$V_{in} -$}
to[short, o-] (4,0)
to[V, v_=$V_{s}(t)$] (4,2)
to[L, l_=$L_m$] (2,2)
to[R, l_=3\kilo\ohm] (1,2) -- (0,2)
to[short, o-] (0,2)
node[anchor=east]{$V_{in} +$};
\end{circuitikz}
#+end_latex



If my current emacs color-theme background is black, running
org-preview-latex-fragment on the latex block results in all
electrical-elements being invisible (only labels and lines are
visible).  The only (poor) workaround I have for this is to add the
configuration option:

#+LaTeX_HEADER: \tikzset{every picture/.style={color=gray}}

Which means that I can barely see the picture when previewed in emacs,
and that it appears in gray on the exported PDF instead of black.

Is there any way that I can make it so that without a lot of hacks I
can make the previews appear as white-on-black, and the PDFs print
black on white?  Would something need to change with how org-mode
handles previewing to make this possible?

Regards,

Mark

[O] [PATCH] org-collector: enable specifying a default table-value as a parameter

[Mark Edgington]

Hi Bastien,

Sorry about the formatting -- that's annoying.  I've attached the patch. 
 Here's its description:


Currently there isn't an easy way to have default cell values which 
differ from one propview block to another.  This patch enables one to 
specify what a cell's default value for a block should be.  For example, 
with this patch applied, you can do something like:


#+BEGIN: propview :id  mytable :defaultval  :cols (PROP1 PROP2)

in order to make the default value for this block to be  instead of 0 
in the case that PROP1 or PROP2 isn't contained as a property of a headline.


Regards,

Mark
* contrib/lisp/org-collector.el (org-dblock-write:propview): if a 'defaultval'
  property has been set, then use this in place of org-propview-default-value.

TINYCHANGE
---
 contrib/lisp/org-collector.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/org-collector.el b/contrib/lisp/org-collector.el
index 60b9069..d62a462 100644
--- a/contrib/lisp/org-collector.el
+++ b/contrib/lisp/org-collector.el
@@ -121,6 +121,7 @@ preceeding the dblock, then update the contents of the dblock.
 	(scope (plist-get params :scope))
 	(noquote (plist-get params :noquote))
 	(colnames (plist-get params :colnames))
+	(defaultval (plist-get params :defaultval))
 	(content-lines (org-split-string (plist-get params :content) \n))
 	id table line pos)
 	(save-excursion
@@ -133,9 +134,10 @@ preceeding the dblock, then update the contents of the dblock.
 		  (t (error Cannot find entry with :ID: %s id
 	  (unless (eq id 'global) (org-narrow-to-subtree))
 	  (setq stringformat (if noquote %s %S))
-	  (setq table (org-propview-to-table
-		   (org-propview-collect cols stringformat conds match scope inherit
-	 (if colnames colnames cols)) stringformat))
+	  (let ((org-propview-default-value (if defaultval defaultval org-propview-default-value)))
+	(setq table (org-propview-to-table
+			 (org-propview-collect cols stringformat conds match scope inherit
+	   (if colnames colnames cols)) stringformat)))
 	  (widen))
 	(setq pos (point))
 	(when content-lines

[O] [PATCH] org-collector: enable specifying a default table-value as a parameter

[Mark Edgington]

Currently there isn't an easy way to have default cell values which 
differ from one propview block to another.  This patch enables one to 
specify what a cell's default value for a block should be.  For example, 
with this patch applied, you can do something like:


#+BEGIN: propview :id  mytable :defaultval  :cols (PROP1 PROP2 
PROP3)


in order to make the default value for this block to be  instead of 0.

* contrib/lisp/org-collector.el (org-dblock-write:propview): if a 
'defaultval'
  property has been set, then use this in place of 
org-propview-default-value.


TINYCHANGE
---
 contrib/lisp/org-collector.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/org-collector.el b/contrib/lisp/org-collector.el
index 60b9069..d62a462 100644
--- a/contrib/lisp/org-collector.el
+++ b/contrib/lisp/org-collector.el
@@ -121,6 +121,7 @@ preceeding the dblock, then update the contents of 
the dblock.

(scope (plist-get params :scope))
(noquote (plist-get params :noquote))
(colnames (plist-get params :colnames))
+   (defaultval (plist-get params :defaultval))
(content-lines (org-split-string (plist-get params 
:content) \n))

id table line pos)
(save-excursion
@@ -133,9 +134,10 @@ preceeding the dblock, then update the contents of 
the dblock.

  (t (error Cannot find entry with :ID: %s id
  (unless (eq id 'global) (org-narrow-to-subtree))
  (setq stringformat (if noquote %s %S))
- (setq table (org-propview-to-table
-  (org-propview-collect cols stringformat conds 
match scope inherit
-(if colnames colnames 
cols)) stringformat))
+ (let ((org-propview-default-value (if defaultval defaultval 
org-propview-default-value)))

+   (setq table (org-propview-to-table
+(org-propview-collect cols stringformat conds 
match scope inherit
+  (if colnames colnames 
cols)) stringformat)))

  (widen))
(setq pos (point))
(when content-lines

[O] Difference between LaTeX and HTML exported documents for bold verbatim text

[Mark Edgington]

Hello all,

I have noticed that it if you have text like the following in org-mode:

A *B* *=C=*

then exporting to HTML causes A to be normal, B to be bold, and C to
be bold and fixed-width font.

Exporting the same to LaTeX, however, causes A to be normal, B to be
bold, and C to be only fixed-width but not bold.

It would be nice if both exporters were consistent in how they export
the styles for these cases (it seems like the HTML exporter gets it
right, while the LaTeX exporter doesn't).

Regards,

Mark

Re: [O] Difference between LaTeX and HTML exported documents for bold verbatim text

[Mark Edgington]

Aaron Ecay aaronecay at gmail.com writes:

  It would be nice if both exporters were consistent in how they export
  the styles for these cases (it seems like the HTML exporter gets it
  right, while the LaTeX exporter doesn't).
 
 This is an issue of the default font in LaTeX not providing the right
 glyphs.  See:

http://tex.stackexchange.com/questions/33039/using-ttfamily-with-bfseries-or-how-to-enable-bold-in-fixed-width-font
 

Hi Aaron,

Thanks for your message -- it is now clear why this happens, and that it
isn't an issue with org-mode.  I guess it's best to leave the org-mode
defaults as they are, but maybe this would be good information to add to the
documentation if it isn't already there -- that one can have something like

#+LATEX_HEADER: \usepackage{courier}

in their file (or the corresponding setting in their emacs config) in order
to ensure that bold fixed-width fonts work properly.

Regards,

Mark

Re: [O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

Hi Bastien,

On Tue, Nov 5, 2013 at 4:06 PM, Bastien b...@gnu.org wrote:

 One possible negative effect I can see is that users have to be extra
 careful what type of output such functions will produce, so that this
 output can be used by a summary type.

Wouldn't the output of a function be something mutually exclusive with
summary types?  In other words, a column can be defined to use a
summary type, or it could be defined (with the proposed idea) as the
output of a function, but not both at the same time.

 ... we should try every other ways (like Babel, org-collector, etc.)
 before going down this road -- and someone will have to implement this
 anyway... but that's just not me :)  (I don't want to close a door.)

After playing around some more with org-collector, I found that it can
in fact do some of the things I had previously thought it couldn't do,
like specifying custom values for column headers.  The documentation
on worg for org-collector seems a bit lacking, in that it doesn't
cover all of the available properties you can use on a #+BEGIN:
propview ... line.  I had to read through the code to identify some
additional properties I could use.

Nonetheless, it seems that org-collector doesn't make the level of a
headline available as a property, so there isn't a good way to achieve
an equivalent to column-view's :maxlevel property in org-collector.
If this were made possible in org-collector, it would be able to do
(at least) most of what column-view can do.  But, there are also the
:hlines, :vlines, and :skip-empty-rows properties for column-view,
each which don't appear to have an equivalent with org-collector.

One other difference has to do with the default value when a
property isn't defined -- org-collector sets the default value to 0,
while for column-view it seems to be an empty string.  I therefore
modified org-collector to make it easier to set this default value
when defining a dynamic block:

--- org-collector.el
+++ org-coll-new.el
@@ -121,6 +121,7 @@
 (scope (plist-get params :scope))
 (noquote (plist-get params :noquote))
 (colnames (plist-get params :colnames))
+(defaultval (plist-get params :defaultval))
 (content-lines (org-split-string (plist-get params :content) \n))
 id table line pos)
 (save-excursion
@@ -133,9 +134,10 @@
   (t (error Cannot find entry with :ID: %s id
   (unless (eq id 'global) (org-narrow-to-subtree))
   (setq stringformat (if noquote %s %S))
-  (setq table (org-propview-to-table
+  (let ((org-propview-default-value (if defaultval defaultval
org-propview-default-value)))
+  (setq table (org-propview-to-table
(org-propview-collect cols stringformat conds match
scope inherit
- (if colnames colnames cols)) stringformat))
+ (if colnames colnames cols)) stringformat)))
   (widen))
 (setq pos (point))
 (when content-lines


Regards,

Mark

Re: [O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

Bastien bzg at gnu.org writes:
 
 FWIW, I'd be inclined to say this is a bit *too much* -- but I'm
 curious to see if others have the same need.
 

Hi Bastien,

What about it seems too much?  Or put differently, what do you think would
be the negative effects of having something like this possible?

From my (obviously biased) point of view, making it available would mean
that the dynamic column view becomes much more flexible, and it would reduce
the need in the future for lots of new hard-coded features/functions to be
added to the related org-mode code.  Instead, features can start out as
functions which people create and share, and if they become popular enough
among many people, they can be incorporated as a built-in feature that
comes with org-mode, or as a contributed module.

Regards,

Mark

Re: [O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

 How about using an elisp babel block, with tabular results?  Something
 like (tested only very lightly):

 #+BEGIN_SRC elisp :results table
   (cons
(list Header A Header B)
(cons 'hline
  (org-map-entries
   (lambda ()
 (list
  (princ (org-entry-get (point) FOO))
  (princ (identity (org-entry-get (point) BAR
 #+END_SRC

 Replace ‘identity’ with your desired lisp-level processing.

Hi Aaron,

I think this could be useful for doing some more general processing of
the properties of trees (e.g. using functions of multiple properties),
but it requires more low-level programming than just using a COLUMNS
definition.  Furthermore, as far as I can tell, you would need to use
something other than org-entry-get to get an entry's headline (e.g.
'ITEM' in the COLUMNS definition).  If you used babel to do this, you
would also not be able to (without reinventing them in elisp) use any
of the special summary functions, like when you specify COLUMNS to
include %MYPROP(Col Title){mean}.  Also, it requires extra conditional
code to limit the results to the properties of a particular subtree.
With dynamic blocks, I can just specify an ID.

I do like the flexibility that the babel-block method offers, but
maybe this same flexibility could be offered via a different kind of
column-attribute definition -- perhaps a syntax like %FUNC(Col
Title){myfunc,PROP1NAME,PROP2NAME,...}   (or simply omit 'FUNC') which
would pass PROP1NAME and PROP2NAME to myfunc.  Thoughts?

Regards,

Mark

Re: [O] Org-Mode newbie, configuration?

[Mark Edgington]

Hi Joe,

While it isn't org-mode specific, you might want to take a look at Eric
Schulte's Emacs Starter Kit configuration
(http://eschulte.github.io/emacs24-starter-kit/) -- it includes some
org-mode settings, and is an example of a great way of maintaining your
emacs configuration.

Regards,

Mark

Re: [O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

Hi Aaron,

I hadn't actually foreseen using it for column-view so much, but
rather for a dynamic-block which generates a column-view of a tree.
These are, as far as I understand, read-only.

I don't think it would work well with read-write column-views, so if
such a function were defined in the :COLUMNS: property, it should
either be ignored and not displayed in the R/W column-view, or it
could be displayed if there were some way of ensuring that the
associated column was R/O.

Maybe others have a better idea on how to handle this?  I am somewhat
partial to the scheme used in org-collector, where columns are defined
at the beginning of a dynamic block, and not in the original tree.
This way you can have several different dynamic blocks which summarize
the tree-data in different ways.  It would also allow the
column-definitions defined in the tree to be used only for the R/W
column-view of that tree.

Regards,

Mark

On Thu, Oct 31, 2013 at 1:56 PM, Aaron Ecay aarone...@gmail.com wrote:
 Hi Mark,

 This seems like an intriguing idea.  I have just one question: how would
 this interact with editing in column view?  Would function-valued
 property columns be read only?  Or do you have something different in
 mind?

 --
 Aaron Ecay

Re: [O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

Hello all,

Since the formatting on my earlier post was bad, I'm re-posting this
with a bit more information:

I would really appreciate it if it were possible to specify an
arbitrary lisp function to process node-properties when creating a
column view.  Currently it is possible to have something like:

* Top node for columns view
   :PROPERTIES:
   :COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
   :END:


But I'd like to be able to do something like:

   :COLUMNS: %ITEM{fn:process_item}(My Column Heading Name) %TAGS
%PRIORITY %TODO

which would pass the ITEM property's value as a single argument to the
process_item function.  The returned value/string of the function
would be what appears in the column view.

Of course one should also be able to use a lambda expression in place
of the function name.

Does this sound like something worth working on?  I would certainly
have various uses for such functionality, so I imagine it would be
useful to others as well.

I understand that there is the org-collector module, but this isn't
quite sufficient. Although it permits arbitrary lisp expressions, it
doesn't allow one to customize what's printed for the column-headers,
like a normal columnview block would allow.

Regards,

Mark

[O] Arbitrary lisp functions in column-attributes

[Mark Edgington]

Hello all,

I would really appreciate it if it were possible to specify an arbitrary
lisp function to process node-properties when creating a column view.  For
example, you can currently have something like:

* Top node for columns view
   :PROPERTIES:
   :COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
   :END:


But I'd like to be able to do something like:

   :COLUMNS: %ITEM{fn:process_item} %TAGS %PRIORITY %TODO

which would pass the ITEM property's value as a single argument to the
process_item function.  The returned value/string of the function would be
what appears in the column view.

Of course it would be good if one could also use a lambda expression in
place of the function name.

Does this sound like something worth working on?  I would certainly have
various uses for such functionality, so I imagine it would be useful to
others as well.

Regards,

Mark

[O] org-babel generated images and +ATTR_LATEX

[Mark Edgington]

Hello all,

I have noticed that it seems not possible to evaluate a babel block of code
which generates an image, and to have a #+ATTR_LATEX line exist which
immediately precedes the generated link to the image.  In other words, If
there's already a #+ATTR_LATEX line, I need to move it after the block is
evaluated, or else it doesn't immediately precede the generated link.

For example, if I have the following...

#+begin_src python :exports none :results file
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig=plt.figure(figsize=(3,2))
plt.plot([1,3,2])
fig.tight_layout()
figname = '/tmp/myfig.jpg'
plt.savefig(figname)
return(figname) # return this to org-mode
#+end_src

#+RESULTS:
#+ATTR_LATEX: :float figure :placement [htb!] :width 0.38\textwidth

... when I evaluate the code-block, the image-link gets inserted directly
after the #+RESULTS line, and before the #+ATTR_LATEX line.  Without the
+ATTR_LATEX line, directly preceding the image-link, no image is inserted
into the PDF which is created when exporting via the latex-exporter.

So, it would be ideal if either:
 (1) #+ATTR_LATEX lines applied to whatever image link which appears next,
even if there are additional lines starting with # that are between the
image-link and the #+ATTR_LATEX line,
OR (2) when evaluating an org-babel block, the results were placed *after*
any #... lines that follow a #+RESULTS line.

Does this make sense, or am I possibly not understanding something about
how to make it so that I don't have to modify my document anywhere else
after I change and evaluate an org-babel block?  (currently I need to
relocate the #+ATTR_LATEX line any time I evaluate an image-generating
block)

I'm using the latest org-mode (8.2.1-117-gaff4f1).

Regards,

Mark

Re: [O] org-babel generated images and +ATTR_LATEX

[Mark Edgington]

Hi Mike,

That does help -- when testing it, I found that the problem had more to do
with my header options than to do with the presence or absence of a #+NAME
line.  But still, with the header options I gave in my original example,
org-babel's behavior does seem strange (maybe buggy?) to me.  My working
code now looks like:

#+begin_src python :exports results :results file :eval no-export
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig=plt.figure(figsize=(3,2))
plt.plot([1,3,2])
fig.tight_layout()
figname = '/tmp/myfig.jpg'
plt.savefig(figname)
return(figname) # return this to org-mode
#+end_src

#+ATTR_LATEX: :float figure :placement [htb!] :width 0.38\textwidth 
#+RESULTS:

Anyhow, something that wasn't clear to me about your example is how you make
the filename which is generated via org-babel-temp-file available for use
within the code-block?

Regards,

Mark

[O] Orgmode fails to export specific web-links as latex/pdf

[Mark Edgington]

Hello all-

When trying to export via latex - pdf, the following org-mode snippet
fails to compile.  Presumably there's something that should be changed
in the export filters?

Here's the org-mode snippet:
-
*** 
[[http://www.example.com:90/search~S2?/Xsearchtermsearchscope%3D2SORT%3DD/Xsearchtermsearchscope%3D2SORT%3DDSUBKEY%3Dsearchterm/1%252C742%252C742%252CB/framesetFF%3DXsearchtermsearchscope%3D2SORT%3DD16%252C16%252C][Title
(mediatype) / Publisher]]
-

Relevant generated tex code:
-
\subsubsection{\href{http://www.example.com:90/search~S2?/Xsearchtermsearchscope=2SORT=D/Xsearchtermsearchscope=2SORT=DSUBKEY=searchterm/1%2C742%2C742%2CB/framesetFF=Xsearchtermsearchscope=2SORT=D16%2C16%2C}{Title
(mediatype) / Publisher}}
\label{sec-1-6-1}
(Does this work?)
-

Relevant snippet from the latex log:
-
Runaway argument?
{\href {http://www.example.com:90/search~S2?/Xsearchtermsearchscope=\ETC.
! File ended while scanning use of \@xdblarg.
inserted text
\par
* /tmp/test.tex

! Emergency stop.
* /tmp/test.tex

!  == Fatal error occurred, no output PDF file produced!
Transcript written on .//test.log.
-

I'm using org-mode release_8.0.5-316-g878d6c.  Let me know if you have
any ideas on what is going on, and how to make this work correctly.

Regards,

Mark

[O] Unable to use +LaTeX_HEADER: \input{...} with latex-preview-fragment

[Mark Edgington]

I attempted recently to have org-mode use a preamble file when
previewing latex-fragments.  I used a line like the following:

+LaTeX_HEADER: \input{relative-path-to-file.tex}

Unfortunately, the file referenced by the \input{} command doesn't get
copied to the location where the preview tex file is compiled.
Certainly a way of making it work would be to use an absolute path
instead of a relative path, but I really want to have a self-contained
portable directory containing both org-mode and preamble files.

Would it be possible or sensible to make an option which makes
latex-preview-fragment parse +LaTeX_HEADER lines for \input{}
commands, and attempt to copy the input files to the preview
compilation-folder?

Regards,

Mark

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hello Nicolas,

I'm sorry for not having provided more explanation of the patch's
purpose.  The motivation is basically to permit any kind of manual
(in contrast to automatic) control over the section-numbering
behavior connected with a particular headline.  In LaTeX, for example,
you are able to make any section numbered or un-numbered, however in
org-mode, there is an artificial restriction when using numbering that
sections of a particular depth must be either all numbered, or all
un-numbered.

A couple possible use-cases:

1. a document (or chapter of a document) where the first  headline
contains general introduction information explaining what the rest
of the document (chapter) is about (similar to an abstract, but not
identical -- something that might contain sub-headings, lists, tables,
etc.), and the remainder of the document (chapter) is the real
content of the document -- the place where you want the numbering to
begin.

2. a document where only one of the headlines and its child-headlines
halfway through the document should be un-numbered (maybe they
represent an example docoument embedded within an
instruction-manual).

The reason there are two different properties (a normal, and an
inherited version) is because use-case #2 could be painful if you
had to add a :NUMBERED: n property to every node of the
sub-document.  There are probably several other use-cases to be
discovered that this allows.  Simply put, the patch makes it possible
to control the numbering for a single headline (one specific headline,
not a headline-level), or to set a manual default numbering behavior
for a sub-tree of headlines.  All other headlines behave according to
the current org-mode numbering rules.

Regards,

Mark

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hi Samuel,

I'd guess it isn't exactly the same as what you did -- I assume you
are making it possible to modify the numbering level threshold via
properties.  Is this modification inherited by child-headlines or not?
 Either way, there would be a lot of hackery required to use this to
achieve the kinds of things my patch intends to do  (e.g. you might
have to use different num:x properties in multiple places to cause
just a single-headline's numbering to be changed).

Regards,

Mark


On Mon, May 13, 2013 at 12:39 AM, Samuel Wales samolog...@gmail.com wrote:
 I just did this, is this related?

 :PROPERTIES:
 :EXPORT_OPTIONS: num:1
 :END:

 --
 The Kafka Pandemic: http://thekafkapandemic.blogspot.com

 The disease DOES progress.  MANY people have died from it.  ANYBODY can get 
 it.

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Also, I forgot to mention that the patch is tested, and behaves as expected.

On Mon, May 13, 2013 at 2:18 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 Thanks for your patch.

 Though, I don't get what you are trying to achieve nor what a use case
 would be. Have you tested this patch ? It may not behave as you expect
 it to.

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hi Nicolas,

On Mon, May 13, 2013 at 6:54 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:

 You can still number these parts manually with, e.g.,

   #+latex: \section*{Introduction}

 before the first section in your Org document.


While this is possible, wouldn't this break the structure of the
org-document, so that a section no longer corresponds to a headline in
some cases.  Also, when the un-numbered section is at the same level
as the top-level headlines, then there would be no way of cleanly
folding away its content in emacs.  Furthermore, by manually inserting
LaTeX code, you make it non-portable for other exporters.

 2. a document where only one of the headlines and its child-headlines
 halfway through the document should be un-numbered (maybe they
 represent an example docoument embedded within an
 instruction-manual).

 I may be wrong, but this sounds like a hypothetical use case to me.

I have certainly encountered cases like this, where I will resort to
using pure LaTeX, but it would be obviously more convenient to be able
to work on such documents via org-mode.

 Anyway, your patch will not work on back-ends that rely on Org to
 compute section numbers (e.g., ascii, html...) because even if you
 ignore numbering for a particular headline, it still adds up internally.
 IOW, you also need to patch `org-export--collect-headline-numbering'.

 But that's not quite it, yet. Some back-ends (e.g., html) use that
 internal number as a unique identifier for the headline. Actually, the
 artificial restriction you are talking about is a way to allow every
 headline to be numbered in a unique way, even if that number doesn't
 appear in the output.

I can see what you mean here -- but it doesn't exactly break
anything -- it just makes the section-numbering within html, etc.
documents to be non-consecutive *if these properties are used*.  If
the main intent is to use these properties in conjunction with the
LaTeX exporter, then this isn't a big problem (i.e. those who want to
use them will just need to understand that they currently only work
correctly with LaTeX, but that this will be fixed in the future).

 Since I wouldn't use this, I can hardly judge, but I would appreciate
 some feedback from other users before we go too far in the
 implementation.

Agreed, but my (obviously biased) opinion is that it makes manual
numbering-control more natural within org-mode, and something which
doesn't require as much hacking with embedded LaTeX (or HTML, etc.)
code.

Regards,

Mark

[O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

* lisp/ox.el (org-export-numbered-headline-p): If the `:NUMBERED' property is
defined for a headline, turn numbering on when the property value is y
(otherwise turn numbering off).  Do the same if the `:INHERITED_NUMBERED'
property is defined for a headline, except make this property inherited by
child nodes.  If both properties are nil or not defined, resort to the
default numbering
behavior.

TINYCHANGE
---
 lisp/ox.el | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 06513d2..137db9e 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3721,8 +3721,14 @@ INFO is a plist holding contextual information.
   Return a non-nil value if HEADLINE element should be numbered.
 INFO is a plist used as a communication channel.
   (let ((sec-num (plist-get info :section-numbers))
-   (level (org-export-get-relative-level headline info)))
-(if (wholenump sec-num) (= level sec-num) sec-num)))
+   (level (org-export-get-relative-level headline info))
+(numbered (org-export-get-node-property :NUMBERED headline))
+(inherited-numbered (org-export-get-node-property
:INHERITED_NUMBERED headline t))) ; y, n, or nil
+(if numbered ; if the numbered property is defined
+(equal numbered y) ; anything other than y means un-numbered
+(if inherited-numbered
+(equal inherited-numbered y)
+(if (wholenump sec-num) (= level sec-num) sec-num) ;
default behavior

 (defun org-export-number-to-roman (n)
   Convert integer N into a roman numeral.
--
1.8.2.2

[O] keymap for read-date-minibuffer

[Mark Edgington]

Hello all,

I recently spent a while figuring out how to add custom-keybindings to
the read-date-minibuffer which appears when org-read-date is called.
The only way to do it currently is to use the
org-read-date-minibuffer-setup hook, and add keybindings to the
minibuffer-local-map there.  I'm wondering if it wouldn't be more
natural to just define an org-read-date-minibuffer-map that the end
user can modify, and to overlay this on top of the
minibuffer-local-map when org-read-date is called.  Thoughts?

Regards,

Mark

[O] Announcing a script that connects org-mode and google-tasks

[Mark Edgington]

Hello all-

I hacked together a python script based on some already-existing code,
which allows one to push an org file to a google-tasks list, or to
pull the contents of a google-tasks list into an org file.  Though the
code isn't beautiful at the moment, it is functional.  Feel free to
improve it.

Get it at:  https://bitbucket.org/edgimar/michel-orgmode

Regards,

Mark