[PATCH] Fix bug in org-num check for commented headlines

2020-08-25 Thread Anders Johansson
I found an easily solved bug in org-num.

This happens when org-num-skip-commented is non-nil.
When creating a new headline, often org-num--skip-value is invoked
before any headline text is created. This means that ‘title‘ is nil
and the string-match check breaks. Checking if title is non-nil fixes
this.

TINYCHANGE
---
 lisp/org-num.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org-num.el b/lisp/org-num.el
index e816080..a5b044e 100644
--- a/lisp/org-num.el
+++ b/lisp/org-num.el
@@ -254,6 +254,7 @@ (defun org-num--skip-value ()
  org-footnote-section
  (equal title org-footnote-section))
 (and org-num-skip-commented
+ title
  (let ((case-fold-search nil))
(string-match org-num--comment-re title))
  t)
-- 
2.28.0



[O] [PATCH] Use regexp-opt in org-set-tag-faces

2019-01-31 Thread Anders Johansson
I just noticed a place where it would be appropriate to use 
regexp-opt instead of doing:

(concat ":\\(" (mapconcat 'car value "\\|") "\\):"

regexp-opt promises to be more efficient.


--
Anders Johansson
>From 2a70a709dcbdb1ff7d00b20de8410935d725ac70 Mon Sep 17 00:00:00 2001
From: Anders Johansson 
Date: Thu, 31 Jan 2019 15:04:30 +0100
Subject: [PATCH] org-faces.el: Use regexp-opt in org-set-tag-faces

* org-faces.el (org-set-tag-faces): Use appropriate call to regexp-opt

TINYCHANGE
---
 lisp/org-faces.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 1ba5b5e..1b9118f 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -311,7 +311,7 @@ determines if it is a foreground or a background color."
   (if (not value)
   (setq org-tags-special-faces-re nil)
 (setq org-tags-special-faces-re
-	  (concat ":\\(" (mapconcat 'car value "\\|") "\\):"
+	  (concat ":" (regexp-opt (mapcar 'car value) t) ":"
 
 (defface org-checkbox '((t :inherit bold))
   "Face for checkboxes."
-- 
2.20.1



Re: [O] Tracking Tags ??

2019-01-23 Thread Anders Johansson
Anyone have a good method of tracking the Tags that you've use 
across
all of your Org files?  Some sort of Tag Index to help you keep 
track of
the tags you've used and where you've used them so that you 
don't start
creating new tags that differ from old ones by (say) 
capitalization?  Or
to help you find everything tagged a certain when you're moving 
to a new
tagging style?  Perhaps an index where you could keep a note on 
why and

when you created the tag?



Is there any tools for this?


I have struggled with similar issues in the context of using tags 
for coding in qualitative data analysis. The stuff that I’ve 
hacked together for solving this (pretty particular) use case are 
available here: https://gitlab.com/andersjohansson/orgqda


Maybe some of the ideas there can help?

This is centred around projects (a bunch of files with research 
material in text form) and I haven’t thought much about adapting 
it to be used for all my org files.


For a project, you can easily extract a list of all used tags, 
rename and merge them. You can define a file for each project as a 
codebook, where the use of each tag is documented. There is also a 
more fancy tag-completion via helm that optionally fetches info 
from the codebook file.


Another approach for keeping a sort of index is John Kitchin’s 
org-db


http://kitchingroup.cheme.cmu.edu/blog/2017/01/03/Find-stuff-in-org-mode-anywhere/
Current code:
https://github.com/jkitchin/scimax/blob/master/org-db.el

--
Anders Johansson



[O] Better org-indent alignment when using variable-pitch-mode

2019-01-16 Thread Anders Johansson
I suggest a possible change to org-indent--compute-prefixes to 
alleviate the problem.


When using variable-pitch-mode (which I particularly like as I 
write a lot of prose in org-mode), the indent between headlines 
and body text can be off, depending on the difference in the width 
of asterisk and space characters in the variable-pitch font.


A workaround is to customize the org-indent face to a monospace 
font to get it to match somewhat better, but this does not lead to 
perfect results.


The indent of headlines and text is constructed like this:

!!!##* Headline
!!!Body text

This is for a third-level headline where ! denotes invisible 
space, # invisible asterisks (in buffer text, but hidden here 
because org-indent by default enables org-hide-leading-stars), and 
* visible asterisks. This means we can still have misalignment 
since it is only the invisible characters (added as wrap-prefix 
and line-prefix with the org-indent face)  that will (possibly if 
the user intervenes) be set to a monospace font. We can’t assume 
that the last two (I think) invisible (line-prefix) spaces before 
the body text will have the same width as the indent characters.


One solution that seemed to work pretty well for me however was to 
force org-indent to use the same character (*) for all indents and 
let the face org-indent use the variable-pitch face (no 
customization of face org-indent). This results in:


#* Headline
##!Body text

That is, exactly the same characters (#=hidden asterisks, !=hidden 
space) preceding the beginning of the text in the headline and the 
body (the last character before the body text is given by 
org-indent-boundary-char, which is by default set to a space).


So for this use-case we get a much better alignment with the 
prefix characters set to asterisk. That is changing line 155 in 
org-indent, org-indent--compute-prefixes from:

(concat (make-string (+ n indentation) ?\s)
to:
(concat (make-string (+ n indentation) ?*)

If people configure the org-indent face in some other way (with 
visible characters for example, although I don’t know why this 
would be a good idea) this could be a bad idea though.


Could it perhaps be made an option? What do you think?

A case which won’t be completely solved by this however, is if the 
headline faces are customized to be larger than text (some like to 
do that for a more word-processor-like editing experience). Then 
the “* ” in the beginning of the headline will probably be taking 
up more space than any character set for indent with a default 
size.


There may have been other cases I overlooked as well.


An earlier discussion of this was here:
https://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00014.html


--
Anders Johansson



[O] Bug? Encoding trouble in org-id-locations-load

2017-11-03 Thread Anders Johansson

Hi,
I use org-id and got some surprising reports of duplicate IDs. It 
seems that the issue is that one of my files containing IDs has a 
filename consisting of some non-ascii characters (a Swedish ä). 
When this filename is read in from ~org-id-locations-file~ in 
~org-id-locations-load~ the ä is interpreted as “\303\244”.
But ~org-id-files~ and ~org-id-locations~ is also populated from 
currently open files, so I usually get that file represented twice 
as two different files in ~org-id-files~. So I get both 
“j-allmänt.org” and j-allm\303\244nt.org“. Both seem to be scanned 
correctly by ~org-id-update-id-locations~ and this results in 
duplicate IDs.


I tried changing the call to ~insert-file-contents-literally~ in 
~org-id-locations-load~ to just ~insert-file-contents~ and this 
seemed to fix the behaviour (as correct decoding is done then?). I 
don’t know if there are other unwanted effects from using 
~insert-file-contents~, but otherwise this seems to me to be a 
more correct solution.


Cheers,
Anders Johansson



[O] [PATCH 1/1] org.el: Make faces org-quote and org-verse be appended

2017-02-22 Thread Anders Johansson


This means fontification of emphasis, links etc. is kept in quote 
and

verse blocks even with org-fontify-quote-and-verse-blocks non-nil.

TINYCHANGE
---
lisp/org.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3290a2b..282c078 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5934,9 +5934,9 @@ by a #."
			 '(org-block))) ; end of source 
block

 ((not org-fontify-quote-and-verse-blocks))
 ((string= block-type "quote")
-	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
  '(face org-quote)))
+	  (add-face-text-property beg1 (min (point-max) (1+ end1)) 
'org-quote t))

 ((string= block-type "verse")
-	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
  '(face org-verse
+	  (add-face-text-property beg1 (min (point-max) (1+ end1)) 
'org-verse t)))
	(add-text-properties beg beg1 '(face 
org-block-begin-line))
	(add-text-properties (min (point-max) (1+ end)) (min 
(point-max) (1+ end1))

 '(face org-block-end-line))
--
2.11.1




[O] Why does quote and verse block fontification have to override local fontification?

2017-02-22 Thread Anders Johansson

Hi,
I want to fontify quote blocks (i use them a lot for note taking 
and writing paper) so that they stand out (and so I enable 
org-fontify-quote-and-verse-blocks) but it would be useful to 
preserve the local fontification of emphasis, links etc. inside 
quote blocks. This can easily be achieved with a patch like this 
org.el:


6096,6099c6096,6099
<  ((string= block-type "quote")
<   (add-face-text-property beg1 (min (point-max) (1+ 
end1)) 'org-quote t))

<  ((string= block-type "verse")
<   (add-face-text-property beg1 (min (point-max) (1+ 
end1)) 'org-verse t)))

---

 ((string= block-type "quote")
	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
'(face org-quote)))

 ((string= block-type "verse")
	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
'(face org-verse



In this invocation add-face-text-property appends org-quote to the 
face property, and hence all other fontification is kept.


Does this interfere with something else or what people would 
expect? In my view it looks much better, but I guess that can 
depend on the appearance of org-quote and org-verse (I have them 
as font-lock-comment-face, just a slightly different colour, on 
top of which italics etc. look good).



--
Anders Johansson



Re: [O] Some projects

2015-10-25 Thread Anders Johansson
Anders Johansson  gmail.com> writes:

> I hacked together something like this a while ago when I needed to add
> inline-comments that would later be exported as odt-comments (but I also
> made it work for latex).
> 
> I chose to implement it via a unicode-bracket ❰❙❱, like this:
> 
> ❰Simple comment❱
> ❰Text that is commented on❙Comment❱
> ❰[Author] Simple comment❱
> ❰Commented text❙[Author] Comment❱
> 
> These are inserted with a custom command to make it easy (including an
> author-history-list selectable with helm).
> 
> I've put it up in a gist if anyone finds it useful:
> https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125
> 
> Cheers,
> Anders Johansson
> 

But taking a look at org-annotate (https://github.com/girzel/org-annotate) i
see that it is a much more complete first attempt at a solution. Stupid that
I didn't find that when I needed it this summer.

/Anders Johansson



Re: [O] Some projects

2015-10-25 Thread Anders Johansson
Marcin Borkowski  mbork.pl> writes:

> 
> 
> On 2015-10-25, at 19:12, Nicolas Goaziou  nicolasgoaziou.fr> wrote:
> 
> > Fabrice Popineau  supelec.fr> writes:
> >
> >> 2015-10-25 18:57 GMT+01:00 Thomas S. Dye  tsdye.com>:
> >>
> >>
> >>> would suggest an alternate wording.  In this case, it would be super
> >>> helpful to have a function that replaced annotated text with the
> >>> annotation, so the author could easily accept the editor's suggestion.
> >>>
> >>>
> >> In this case, it would be nice if annotations could have an author
> >> too!
> >
> > The full proposal was at
> > <http://permalink.gmane.org/gmane.emacs.orgmode/97468> but it didn't get
> > much positive feedback. Therefore I suggested a simplified version, with
> > a single author.
> 
> I like it!  I'm not sure I would use it a lot (and definitely not with
> other people - there are not many people using Org-mode in my
> institution, in fact I guess I'm the only one), but it does seem
> useful.
> 
> One thing: there /must/ be a way to export annotations.  For LaTeX, the
> todonotes package (https://www.ctan.org/pkg/todonotes) seems a natural
> choice.
> 

I hacked together something like this a while ago when I needed to add
inline-comments that would later be exported as odt-comments (but I also
made it work for latex).

I chose to implement it via a unicode-bracket ❰❙❱, like this:

❰Simple comment❱
❰Text that is commented on❙Comment❱
❰[Author] Simple comment❱
❰Commented text❙[Author] Comment❱

These are inserted with a custom command to make it easy (including an
author-history-list selectable with helm).

I've put it up in a gist if anyone finds it useful:
https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125

Cheers,
Anders Johansson


Re: [O] Organizing and taming hectic Academia work (faculty viewpoint)? Tips or a good guides sought after :)

2015-08-26 Thread Anders Johansson
Xebar Saram zeltakc at gmail.com writes:

 
 Hi all
 Im a young assistant professor (in humanities and thus my horrific coding
skills..basically non ) and having been using orgmode for a year or two now.
I love orgmode dearly and use it mainly for note taking, lists etc
 
 I am aware of the fantastic orgmode capabilities that could benefit me
greatly such as exporting, email tie-ins, beamer support, organizing my
bibliography (i have switched to a .bib file recently for my references),
agenda capabilities and so much moreand have tried several of these with
mild success. 
 
 unfortunately (and this maybe due to me not being very technical and lack
of coding skills) i still feel like im really not using orgmode to its
potential and still feel miserably lost in terms of organizing my work in
academia from all aspects.
 
 i am looking for 2 things really: 
 1. as i said in the post topic a good guide if anyone is aware of or
detailed examples of using org in Academia (mainly aimed at faculty :))
 
 2. related to that as a young researcher with multiple students, paper
writing, grant applications, department duties, endless TODOS, endless email
i would really be grateful for even non org specific tips on how other
people organize all this to make life more..well..organized :)
 
 thanks alot in advance and sorry for the long mail
 
 best
 
 Z
 
 

I have to collaborate in Word but can at least start out writing my papers
in org-mode. I use Zotero for reference management and with the help of
several tools I can insert citations that can be formatted by Zotero in the
final version of the paper.
Here is my configuration:
https://gist.github.com/andersjohansson/324a01364eb5a5435c65

It uses Erik Hetzners org-zotxt and org-pdcite, ox-odt for converting to
odt, and then the tool http://zotero-odf-scan.github.io/zotero-odf-scan/ to
convert the generated citations like { | Smith, (2012) | |
|zu:2433:WQVBH98K} to Zotero citation marks in the odt-file.

Perhaps someone else will have use for this as well,

Cheers,
Anders Johansson








[O] Bug: Inlinetask bodies begun with a link (or other invisible elements) are not folded correctly

2015-05-17 Thread Anders Johansson

Hi,
I had an inlinetask that started with a link, like this:

 Inlinetask heading
[[file:filename][link desc]] some text. Some more text.
 END

It didn't fold on TAB. Looking into org-inlinetask-toggle-visibility I see

;; Inlinetask was folded: expand it.
 ((get-char-property (1+ start) 'invisible)

which is true for all kind of chars that are invisible I guess (even if 
the value of the 'invisible property is 'org-link)


A quick test showed that adding a test for if the hiding is outline 
worked:


;; Inlinetask was folded: expand it.
 ((eq 'outline (get-char-property (1+ start) 'invisible))

I don't know if this has any unwanted side-effects though. Or if this 
should be avoided for some reason.


This is using the latest org from git.

Cheers,
Anders Johansson

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.2.10 (release_8.2.10-417-g0e5069 @ 
/home/aj/kodat/elisp/org-mode/)




Re: [O] Bug? Changed behaviour makes tags in headlines without a title parsed as the title

2015-04-10 Thread Anders Johansson



Den 2015-04-10 18:24, Nicolas Goaziou skrev:

Hello,

Anders Johansson mejlaande...@gmail.com writes:


I have been using degenerate inlinetasks with empty titles but many
tags for implementing a kind of coding scheme for coding texts for
qualitative data analysis. Like this:
-

Some text that I want to tag (The inlinetask in my scheme refers to
the paragraph above it)
*** :tag1:tag2:tag3:

Other text (no inlinetask-END, mostly)
-

Building org from the master branch, I recently noticed a changed
behaviour in that these tags as are not parsed as tags but instead as
the title, meaning my exports don't work as expected (and possibly
other things, but searching for tags etc.doesn't seem to be affected.
Those functions don't use org-element perhaps?).


Indeed.


As far as I could see, this comes from the changes in commit

98ee73: org-element: Avoid `org-element-parse-secondary-string',

where tags are matched with the regexp:
(org-re [ \t]+\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$)

which needs whitespace after the non-existent title.

I haven't checked all the different changes going on in org-element though.

I don't know if this changed behaviour is intended. Otherwise I guess
it's a bug.


Empty headings are a pathological case. What if I want to write

   *** :title:

? Your interpretation prevents that.

Of course, Org is expected to be consistent. However I'm not convinced
supporting empty headlines with tags is a good thing.

Regards,



Great, that sounds reasonable.
I guess I'll change my practice then.

Cheers,



[O] Bug? Changed behaviour makes tags in headlines without a title parsed as the title

2015-04-08 Thread Anders Johansson

Hi,
I have been using degenerate inlinetasks with empty titles but many 
tags for implementing a kind of coding scheme for coding texts for 
qualitative data analysis. Like this:

-

Some text that I want to tag (The inlinetask in my scheme refers to the 
paragraph above it)

*** :tag1:tag2:tag3:

Other text (no inlinetask-END, mostly)
-

Building org from the master branch, I recently noticed a changed 
behaviour in that these tags as are not parsed as tags but instead as 
the title, meaning my exports don't work as expected (and possibly other 
things, but searching for tags etc.doesn't seem to be affected. Those 
functions don't use org-element perhaps?).


As far as I could see, this comes from the changes in commit

98ee73: org-element: Avoid `org-element-parse-secondary-string',

where tags are matched with the regexp:
(org-re [ \t]+\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$)

which needs whitespace after the non-existent title.

I haven't checked all the different changes going on in org-element though.

I don't know if this changed behaviour is intended. Otherwise I guess 
it's a bug.


Cheers,



Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode

2014-12-01 Thread Anders Johansson
Anders Johansson mejlaandersj at gmail.com writes:

 
 Anders Johansson mejlaandersj at gmail.com writes:
 
  
  Tobias Getzner tobias.getzner at gmx.de writes:
  
   
   Hello,
   
   After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that
   org-indent-mode now underindents item bodies when variable-pitch-mode is
   used. I. e., in the following document, «lorem», «ipsum», and «etc.» will
   fall successively short of the item’s respective indent level.
   
   * first
   lorem
   ** second
   ipsum
   *** third
   etc.
   
   My last working version was 20140915 on Emacs 24.3.
   
   Kind regards,
   Tobias
   
  
  Hi,
  I'm experiencing the exact same problem. Debugging might be a little tricky
  if it involves changes in both Emacs and org.
  
  I think the problem depends on the text-properties wrap-prefix and
  line-prefix being set to a number of spaces and a number of stars,
  respectively, in headlines and only spaces in body text. When variable-pitch
  fonts don't have as wide stars as spaces we get a mismatch. But I don't know
  how this can have worked better before.
  
  Doesn't anyone else use variable-pitch-mode for org and suffer from this?
  
  Cheers,
  Anders Johansson  
  
  
 
 Hi again,
 Ok, I have tracked it down a bit. It must be due to changes in Emacs outside
 of org.
 I tried with the combination Emacs 24.3.1 and org:
 Org-mode version 8.2.10 (8.2.10-20-gaa65ac-elpa  at 
 /home/aj/.emacs.d/elpa/org-20141124/) 
 
 There it works. But never in 24.4, regardless of org version.
 
 How Emacs handles line-prefix and wrap-prefix must have changed in some way.
 I don't know if that is a bug in Emacs or something org should accommodate
 for though.
 
 Cheers,
 Anders Johansson
 
 And then it worked.
 
 

Ok,

I'm quite sure this depends on the changes discussed here:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00776.html

which (as far as I understand it) means that wrap-prefix (and line-prefix?)
now uses the currently active face (or something like that) instead of
default. The working indent in variable-pitch-mode thus depended on
wrap-prefix and line-prefix having the wrong (default) face instead of the
variable-pitch face that is now used.

One workaround is to customize the face org-indent in some way to make it
roughly match the width of your stars:

(set-face-attribute 'org-indent nil :family YOUR_DEFAULT_FAMILY)

This worked ok for me.
Just inheriting default didn't seem to work. I think that is overridden by
variable-pitch mode.

I don't know if this could be generalized in a good way that could be put
into org-mode since the desired width (or family) depends on each users
configuration.

One possibility could be if it would be possible to get the pixel-width of a
star in some way and then set line-prefix to a correct pixel-width (multiple
of this).

Cheers,
Anders Johansson




Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode

2014-11-27 Thread Anders Johansson
Tobias Getzner tobias.getzner at gmx.de writes:

 
 Hello,
 
 After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that
 org-indent-mode now underindents item bodies when variable-pitch-mode is
 used. I. e., in the following document, «lorem», «ipsum», and «etc.» will
 fall successively short of the item’s respective indent level.
 
 * first
 lorem
 ** second
 ipsum
 *** third
 etc.
 
 My last working version was 20140915 on Emacs 24.3.
 
 Kind regards,
 Tobias
 

Hi,
I'm experiencing the exact same problem. Debugging might be a little tricky
if it involves changes in both Emacs and org.

I think the problem depends on the text-properties wrap-prefix and
line-prefix being set to a number of spaces and a number of stars,
respectively, in headlines and only spaces in body text. When variable-pitch
fonts don't have as wide stars as spaces we get a mismatch. But I don't know
how this can have worked better before.
 
Doesn't anyone else use variable-pitch-mode for org and suffer from this?

Cheers,
Anders Johansson  







Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode

2014-11-27 Thread Anders Johansson
Anders Johansson mejlaandersj at gmail.com writes:

 
 Tobias Getzner tobias.getzner at gmx.de writes:
 
  
  Hello,
  
  After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that
  org-indent-mode now underindents item bodies when variable-pitch-mode is
  used. I. e., in the following document, «lorem», «ipsum», and «etc.» will
  fall successively short of the item’s respective indent level.
  
  * first
  lorem
  ** second
  ipsum
  *** third
  etc.
  
  My last working version was 20140915 on Emacs 24.3.
  
  Kind regards,
  Tobias
  
 
 Hi,
 I'm experiencing the exact same problem. Debugging might be a little tricky
 if it involves changes in both Emacs and org.
 
 I think the problem depends on the text-properties wrap-prefix and
 line-prefix being set to a number of spaces and a number of stars,
 respectively, in headlines and only spaces in body text. When variable-pitch
 fonts don't have as wide stars as spaces we get a mismatch. But I don't know
 how this can have worked better before.
 
 Doesn't anyone else use variable-pitch-mode for org and suffer from this?
 
 Cheers,
 Anders Johansson  
 
 

Hi again,
Ok, I have tracked it down a bit. It must be due to changes in Emacs outside
of org.
I tried with the combination Emacs 24.3.1 and org:
Org-mode version 8.2.10 (8.2.10-20-gaa65ac-elpa @
/home/aj/.emacs.d/elpa/org-20141124/) 

There it works. But never in 24.4, regardless of org version.

How Emacs handles line-prefix and wrap-prefix must have changed in some way.
I don't know if that is a bug in Emacs or something org should accommodate
for though.

Cheers,
Anders Johansson




And then it worked.







[O] Suggestion, ox-latex: Perhaps a line break should be inserted into low-level headlines

2014-10-03 Thread Anders Johansson

Hi,
Currently low-level headlines in latex export to:

\item HEADLINE-TEXT
\label{sec-1-3}
CONTENTS

This makes the headline text and contents go together in the same line 
with just a space in between. I think there should be a line break or 
paragraph break between them.


Something like

\item HEADLINE-TEXT
\label{sec-1-3}\\
CONTENTS

Or:

\item HEADLINE-TEXT
\label{sec-1-3}

CONTENTS

The first variant means modifying the headline-label variable (or 
something like that) in org-latex-headline. The second is less messy to 
implement.


Cheers,
Anders Johansson



Re: [O] Suggestion, ox-latex: Perhaps a line break should be inserted into low-level headlines

2014-10-03 Thread Anders Johansson

Nicolas Goaziou writes:

Hello,

Anders Johansson mejlaande...@gmail.com writes:


Currently low-level headlines in latex export to:

\item HEADLINE-TEXT
\label{sec-1-3}
CONTENTS

Not really. Export respects blank lines between the headline an its
contents. So

   * Headline

 Contents

will be exported as

   \item Headline
   \label{whatever}

   Contents


This makes the headline text and contents go together in the same line
with just a space in between. I think there should be a line break or
paragraph break between them.

I don't think is should be mandatory.

   * Low-level-headline ---
 Some conents

is meant to be inserted on the same line.


Regards,


Hi,
I see. This just didn't really fit with my use-case. I seldom decide 
before what will be considered low-level headlines and make them 
special. For my large generated documents I'll hack something together 
then.


I guess that even if it's not mandatory it could always be an option :-)

Cheers,



[O] Bug in org-paste-subtree

2014-06-19 Thread Anders Johansson

Hi,

The force-level check in org-paste-subtree seems to contain a small bug.

If I try to paste a subtree at the end of a line only containing some 
stars, I get an error Wrong type argument: number-or-marker-p, nil.


The problem is (- (match-end 1) (match-end 1)) (see below)

We have no subexpression to match, it should be zero.

(force-level (cond (level (prefix-numeric-value level))
 ((and (looking-at [ \t]*$)
   (string-match
^\\*+$ (buffer-substring
  (point-at-bol) (point
  (- (match-end 1) (match-beginning 1)))
 ((and (bolp)
   (looking-at org-outline-regexp))
  (- (match-end 0) (point) 1


Cheers,
Anders Johansson



[O] Bug: ob-ditaa fails in generating pdf correctly

2014-05-22 Thread Anders Johansson

Hi,
Example input:
#+header: :eps t
#+header: :file hello.pdf
#+BEGIN_SRC ditaa
+--+
|  |
|Hello |
|  |
+--+
#+END_SRC


When using the above code (which I guessed should be the correct way) 
with ob-ditaa to produce a pdf (through  DitaaEps - epstopdf) it fails 
in producing the pdf correctly and instead writes an eps to hello.pdf. 
This isn't surprising, looking at the code where cmd should be 
constructed to produce the eps as an intermediary file in /tmp (which is 
expected in the construction of pdf-cmd) but doesn't.


An ugly patch to fix it is attached (this is ugly because it repeats the 
line:

(org-babel-process-file-name (concat in-file .eps))
)

Cheers,
Anders Johansson
--- /home/aj/H\303\244mtningar/ob-ditaa.el2014-05-22 17:15:35.489071991 
+0200
+++ ob-ditaa.el 2014-05-22 17:08:46.617089186 +0200
@@ -90,6 +90,12 @@
 (java (cdr (assoc :java params)))
 (in-file (org-babel-temp-file ditaa-))
 (eps (cdr (assoc :eps params)))
+(pdf-cmd (when (and (or (string= (file-name-extension out-file) pdf)
+(cdr (assoc :pdf params
+   (concat
+epstopdf
+  (org-babel-process-file-name (concat in-file .eps))
+ -o= (org-babel-process-file-name out-file
 (cmd (concat org-babel-ditaa-java-cmd
java   org-ditaa-jar-option  
  (shell-quote-argument
@@ -97,13 +103,10 @@
(if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
cmdline
(org-babel-process-file-name in-file)
-   (org-babel-process-file-name out-file)))
-(pdf-cmd (when (and (or (string= (file-name-extension out-file) pdf)
-(cdr (assoc :pdf params
-   (concat
-epstopdf
-  (org-babel-process-file-name (concat in-file .eps))
- -o= (org-babel-process-file-name out-file)
+   (if pdf-cmd
+ (org-babel-process-file-name (concat 
in-file .eps))
+ (org-babel-process-file-name 
out-file
+)
 (unless (file-exists-p org-ditaa-jar-path)
   (error Could not find ditaa.jar at %s org-ditaa-jar-path))
 (with-temp-file in-file (insert body))


[O] Bug: org-beamer-select-environment (ox-beamer.el) should temporarily disable persistent tags

2014-05-19 Thread Anders Johansson

Hi,
Having some persistent tags configured (in org-tag-persistent-alist) 
means those get added to the selection window for 
org-beamer-select-environment possibly interfering with the selection of 
beamer environments.


These tags should be explicitly disabled in the let in 
org-beamer-select-environment:


(org-tag-persistent-alist nil)


Cheers,
Anders Johansson



Re: [O] Bug? org-set-tags never uses ido

2014-04-02 Thread Anders Johansson
A hack to get ido selection for multiple tags. It uses 
ido-completing-read-multiple (available here and included below: 
https://gist.github.com/mgalgs/1329188) to allow for completing one tag 
at a time and ending it by typing :.


I haven't tested it much and it might possibly break things (or most 
certainly it's implemented in an ugly way). Perhaps someone more than me 
will find it useful.


Cheers,
Anders



(defadvice org-icompleting-read
  (around org-use-ido-for-tags
  (prompt coll optional pred reqm initial hist def)
  activate)
  Advised to use ido for multiple completion of tags
  (setq ad-return-value
(if (string= Tags:  prompt)
(mapconcat 'identity
   (ido-completing-read-multiple
prompt
(mapcan
 'copy-list org-last-tags-completion-table)
pred reqm initial hist def :)
   :)
  ad-do-it)))


(defun ido-completing-read-multiple (prompt choices optional predicate 
require-match initial-input hist def sentinel)

  Read multiple items with ido-completing-read. Reading stops
  when the user enters SENTINEL. By default, SENTINEL is
  \*done*\. SENTINEL is disambiguated with clashing completions
  by appending _ to SENTINEL until it becomes unique. So if there
  are multiple values that look like SENTINEL, the one with the
  most _ at the end is the actual sentinel value. See
  documentation for `ido-completing-read' for details on the
  other parameters.
  (let
  ((sentinel (if sentinel sentinel *done*))
   (done-reading nil)
   (res ()))

;; uniquify the SENTINEL value
(while (find sentinel choices)
  (setq sentinel (concat sentinel _)))
(setq choices (cons sentinel choices))

;; read some choices
(while (not done-reading)
  (setq this-choice (ido-completing-read prompt choices predicate 
require-match initial-input hist def))

  (if (equal this-choice sentinel)
  (setq done-reading t)
(setq res (cons this-choice res

;; return the result
res
))




[O] org-entities: Another issue [was: org-entities: why \lang instead of \langle?]

2014-03-25 Thread Anders Johansson

(I continue in the same thread as this is related)

org-entities has:  (slash / nil / / / /)

A LaTeX user entering \slash would probably expect to have this exported 
as \slash (which produces a breaking /, not the same thing as just 
entering / in LaTeX).


So it should rather be:  (slash \\slash nil / / / /)

Could this be changed without breaking people's documents?


Cheers,
Anders Johansson



Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits

2014-03-15 Thread Anders Johansson

2014-02-23 16:20, Anders Johansson wrote:



Hi,
I used the configuration:

org-catch-invisible-edits 'show
org-pretty-entities t

together with org-cdlatex. This breaks the insertion of subscripts
and superscripts through org-cdlatex because _{} is fontified and the
{} are hidden so typing for example: a _ bc results in a_{b}c (or
sometimes a_bc, but should be a_{bc}) and gives the message
Unfolding invisible region around point before editing.

Setting org-catch-invisible-edits to nil let's cdlatex do it's work
so I guess an easy solution would be to let that in
org-cdlatex-underscore-caret.


Hi,
I realized that my solution won't work since
org-check-before-invisible-edit does it's work after
org-cdlatex-underscore-caret has called cdlatex-sub-superscript
and inserted _{}.

Maybe then org-catch-invisible-edits should be nil all the time in
org-cdlatex-mode? But this would be unexpected. Maybe this can be
treated as a special case in org-check-before-invisible-edit in some
way?


Digging into it some more it's actually the pretty entities folding
which is the problem, regardless of org-check-before-invisible-edit. The
cursor jumps out of the {}-brackets after the first character, when the
hiding/folding is done. I have no idea what should be done about this.




In case anyone has the same problem, my current workaraound for this is 
disabling pretty entities for sub/superscript when using cdlatex:


(add-hook 'cdlatex-mode-hook
 (lambda () (when (eq major-mode 'org-mode)
  (make-local-variable 'org-pretty-entities-include-sub-superscripts)
   (setq org-pretty-entities-include-sub-superscripts nil


Cheers,
Anders Johansson



[O] Suggestion for improvement, org-read-date: prefer-closest-date instead of only prefer-future*

2014-03-15 Thread Anders Johansson

Hi.

I sometimes use timestamps for scheduling, sometimes for logging things 
(manually and a few days later). It would be pretty convenient if one 
could define a preferred range of time for incomplete dates, instead of 
just prefer-future or default to current month or year.


Example:
It's 2013-12-25 and I want to schedule something for 2014-01-05 and add 
a log timestamp for something last week, 2013-12-20.


It would be convenient if entering 01-05 and 12-20 would do the 
right thing regardless of the setting of org-read-date-prefer-future.


This could be to prefer the closest date, but even more configurability 
would be added if a sliding range of dates along a year were preferred. 
For example, 9 months into the future and 3 in the past so that entering 
9-26 would give 2013-09-26 and entering 9-24

would give 2014-09-24.

I think something like this is reasonable as it might be more common to 
enter a date a few months back than one almost a year into the future.


I don't know if this applies as much to the case of only entering a day 
number though, maybe there entering -x covers the case of wanting to 
enter a date a few days back and preferring the future otherwise.



Perhaps this would add to much complexity to org-read-date, with little 
gain, and there may certainly be complications I haven't thought of, but 
I think it would be an interesting option for many people.


Cheers,
Anders Johansson



Re: [O] Bug? org-set-tags never uses ido

2014-03-04 Thread Anders Johansson
Looking at this again I realize that the reason for this behavior is 
that we want completion of possibly several tags. This is what the 
org-tags-completion-function does when supplied as the second argument 
of completing-read. As ido-completing-read and 
org-iswitchb-completing-read doesn't support this, they are not used.


I don't know if there would be a way of getting both ido and multiple 
input. As it is now though, it's pretty meaningless to have that call to 
org-icompleting-read there as it never gets activated. It could as well be:


(completing-read Tags: 
'org-tags-completion-function
nil nil current 'org-tags-history)


Cheers,
Anders Johansson


2013-11-01 02:33, Eric Abrahamsen skrev:

Anders Johansson mejlaande...@gmail.com writes:


Greetings,
I want to use ido everywhere and wanted to know why this doesn't seem
to work for setting org-mode tags (it never has for me).

Using edebug to step through the call to org-icompleting-read which
org-set-tags does I can see that it never gets to using ido since the
last condition below is false:
org.el:10147-10150 (package repository version 20131028):
(if (and org-completion-use-ido
 (fboundp 'ido-completing-read)
 (boundp 'ido-mode) ido-mode
 (listp (second args)))

This is not strange, since org-icompleting-read is called like this in
org-set-tags:

org.el:14519-14521
(org-icompleting-read Tags: 
  'org-tags-completion-function
  nil nil current 'org-tags-history))

Hmm, shouldn't that 'org-tags-completion-function be replaced with
org-last-tags-completion-table? A quick test shows that works, and from
glancing at the code it seems like org-last-tags-completion-table should
hold the proper assortment of tags...

E


ido apparently needs a list of possible completions, not a single symbol.

I don't understand much more of this really.
Is it a bug? Have I misunderstood something?

Greetings,
Anders Johansson







Re: [O] Bug? org-set-tags never uses ido

2014-03-04 Thread Anders Johansson

2014-03-05 01:20, Samuel Wales wrote:

There are several packages that allow ido to work everywhere.  The one
I use, ido-hacks, works fine for tags out of the box.


A quick look at ido-hacks.el here: 
https://github.com/scottjad/ido-hacks/blob/master/ido-hacks.el suggests 
that this doesn't really solve the problem of being able to select 
multiple tags separated by colon at the same time with ido.


I haven't tried it but the docstring for the advice of completing-read says:

Advice `completing-read' to always use `ido-read-internal',
unless `this-command' has a (ido ignore) property or the
inherit-input-method argument is non-nil or the collection
argument is a function (which ido can't handle).

which seems to suggest that passing 'org-tags-completion-function as the 
second argument (collection) to the advised completing-read wouldn't use 
ido in this case either


Cheers,
Anders Johansson




[O] org-entities: why \lang instead of \langle?

2014-02-23 Thread Anders Johansson

Hi,
I noticed that in org-entities these symbols are defined:

   (lang \\langle t lang;   ⟨)
   (rang \\rangle t rang;   ⟩)


But nothing for langle and rangle. I guess it seems pretty confusing 
when you try to use the latex-macros you are used to.


Maybe these aliases could also be added, like what is done for e.g. clubs:

   (langle \\langle t lang;   ⟨)
   (rangle \\rangle t rang;   ⟩)


Cheers,
Anders Johansson




[O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits

2014-02-23 Thread Anders Johansson

Hi,
I used the configuration:

org-catch-invisible-edits 'show
org-pretty-entities t

together with org-cdlatex. This breaks the insertion of subscripts and 
superscripts through org-cdlatex because _{} is fontified and the {} are 
hidden so typing for example: a _ bc results in a_{b}c (or sometimes 
a_bc, but should be a_{bc}) and gives the message Unfolding 
invisible region around point before editing.


Setting org-catch-invisible-edits to nil let's cdlatex do it's work so I 
guess an easy solution would be to let that in 
org-cdlatex-underscore-caret.



Cheers,
Anders Johansson



Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits

2014-02-23 Thread Anders Johansson

Hi,
I used the configuration:

org-catch-invisible-edits 'show
org-pretty-entities t

together with org-cdlatex. This breaks the insertion of subscripts and 
superscripts through org-cdlatex because _{} is fontified and the {} 
are hidden so typing for example: a _ bc results in a_{b}c (or 
sometimes a_bc, but should be a_{bc}) and gives the message 
Unfolding invisible region around point before editing.


Setting org-catch-invisible-edits to nil let's cdlatex do it's work so 
I guess an easy solution would be to let that in 
org-cdlatex-underscore-caret.



Cheers,
Anders Johansson

Hi,
I realized that my solution won't work since 
org-check-before-invisible-edit does it's work after 
org-cdlatex-underscore-caret has called cdlatex-sub-superscript and 
inserted _{}.


Maybe then org-catch-invisible-edits should be nil all the time in 
org-cdlatex-mode? But this would be unexpected. Maybe this can be 
treated as a special case in org-check-before-invisible-edit in some way?



Cheers,
Andes Johansson



Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits

2014-02-23 Thread Anders Johansson



Hi,
I used the configuration:

org-catch-invisible-edits 'show
org-pretty-entities t

together with org-cdlatex. This breaks the insertion of subscripts 
and superscripts through org-cdlatex because _{} is fontified and the 
{} are hidden so typing for example: a _ bc results in a_{b}c (or 
sometimes a_bc, but should be a_{bc}) and gives the message 
Unfolding invisible region around point before editing.


Setting org-catch-invisible-edits to nil let's cdlatex do it's work 
so I guess an easy solution would be to let that in 
org-cdlatex-underscore-caret.



Hi,
I realized that my solution won't work since 
org-check-before-invisible-edit does it's work after 
org-cdlatex-underscore-caret has called cdlatex-sub-superscript 
and inserted _{}.


Maybe then org-catch-invisible-edits should be nil all the time in 
org-cdlatex-mode? But this would be unexpected. Maybe this can be 
treated as a special case in org-check-before-invisible-edit in some 
way?


Digging into it some more it's actually the pretty entities folding 
which is the problem, regardless of org-check-before-invisible-edit. The 
cursor jumps out of the {}-brackets after the first character, when the 
hiding/folding is done. I have no idea what should be done about this.


Cheers,
Anders Johansson







[O] Suggestion/bug: Parse inlinetask END with level sensitivity

2014-02-17 Thread Anders Johansson

Hi.
I recently started using inlinetasks to be able to tag and comment long 
texts (a kind of simple qualitative data analysis).


I thought that I would be able to use both tasks with and without an 
END line interchangeably:


*** inlinetask without end
some text

*** inlinetask with end
text inside inlinetask
*** END

The problem (not so surprising really) is that the parser finds the 
END of the second inlinetask and makes them nested in an export.


I thought this could be solved with using different numbers of stars for 
tasks with and without END, judging from these lines in org-inlinetask.el:

;; If you need to have a time planning line (DEADLINE etc), drawers,
;; for example LOGBOOK of PROPERTIES, or even normal text as part of
;; the inline task, you must add an END headline with the same
;; number of stars.

But the search for END in the parser is actually star-insensitive so 
this didn't solve my problem either.


I suggest requiring the END-line to contain as many stars as it's 
beginning line by doing something like this (there is certainly a 
cleaner way doing it) to org-element-inlinetask-parser:


@@ -972,7 +972,9 @@
   plist
(task-end (save-excursion
(end-of-line)
-   (and (re-search-forward ^\\*+ END limit t)
+   (and (re-search-forward
+ (concat ^ (mapconcat 'identity (make-list (nth 1 
components) \\*) )  END)

+ limit t)
 (match-beginning 0
(contents-begin (progn (forward-line)
   (and task-end ( (point) task-end) (point

But perhaps this is too unstable? (Although it could be expected from 
the comments above).


Cheers,
Anders Johansson



Re: [O] Suggestion/bug: Parse inlinetask END with level sensitivity

2014-02-17 Thread Anders Johansson

Great!
Taking a look at your solution I realize where the bug lay as well. 
Level is unimportant, it just scanned too long previously (it should 
only look if the next headline contains END, not look for the next 
headline with END).


Regards,
Anders Johansson

Den mån 17 feb 2014 23:05:02 skrev Nicolas Goaziou:

Hello,

Anders Johansson mejlaande...@gmail.com writes:


I thought that I would be able to use both tasks with and without an
END line interchangeably:

*** inlinetask without end
some text

*** inlinetask with end
 text inside inlinetask
*** END

The problem (not so surprising really) is that the parser finds the
END of the second inlinetask and makes them nested in an export.


This should be fixed in maint. Thank you for reporting it.

For the record, inlinetasks cannot be nested, and the number of stars is
not meaningful, as long as it is greater than `org-inlinetask-min-level'.


Regards,





[O] Bug: org-beamer-select-environment (ox-beamer.el) assumes org-use-fast-tag-selection is on

2014-01-07 Thread Anders Johansson

Hi,
I recently set org-use-fast-tag-selection to nil in my configuration. 
This meant org-beamer-select-environment stopped working since it 
assumes that org-set-tags will launch the fast-tag-selection mechanism 
when it has set org-tag-alist to it's special value.


Fix: Explicitly set org-use-fast-tag-selection to t in the 
let*-construct in org-use-fast-tag-selection, as is now done with 
org-fast-tag-selection-single-key.


Greetings,
Anders Johansson





[O] Bug? org-set-tags never uses ido

2013-10-31 Thread Anders Johansson

Greetings,
I want to use ido everywhere and wanted to know why this doesn't seem to 
work for setting org-mode tags (it never has for me).


Using edebug to step through the call to org-icompleting-read which 
org-set-tags does I can see that it never gets to using ido since the 
last condition below is false:

org.el:10147-10150 (package repository version 20131028):
   (if (and org-completion-use-ido
(fboundp 'ido-completing-read)
(boundp 'ido-mode) ido-mode
(listp (second args)))

This is not strange, since org-icompleting-read is called like this in 
org-set-tags:


org.el:14519-14521
   (org-icompleting-read Tags: 
 'org-tags-completion-function
 nil nil current 'org-tags-history))

ido apparently needs a list of possible completions, not a single symbol.

I don't understand much more of this really.
Is it a bug? Have I misunderstood something?

Greetings,
Anders Johansson




[O] Suggestion: Weektree

2013-10-01 Thread Anders Johansson

Greetings,
It's very nice to keep a journal in a datetree (using the capture 
mechanism) but for my uses it would actually be even more useful to keep 
it in a /weektree/. Something like this:


* 2013
** W39 (September 23 - September 29)
*** 2013-09-23 Monday
 note 1
 note 2
*** 2013-09-24 Tuesday
*** 2013-09-25 Wednesday
** W52 (December 23 - December 29)
*** 2013-09-25 Wednesday
 Christmas, no work done.
* 2014
** W1 (December 30 - January 5)
*** 2013-09-31 Tuesday
 New year's eve party!

(with names of months and days localised as usual)

Motivations:
This would keep working weeks together (not broken over month boundaries).
At least here in Sweden it's pretty common to refer to weeks by number 
so this would perhaps be useful for that reason.


Problems:
My suggestion above uses ISO-weeks 
(http://en.wikipedia.org/wiki/ISO_week_date), maybe other conventions 
should also be an option 
(http://en.wikipedia.org/wiki/Seven-day_week#Week_numbering).


Implementation:
I tried to see if this could be implemented on top of the datetree code, 
but as far as I could tell, to much of that mechanism was hardcoded into 
months etc. The task seemed to difficult for me.


If someone else thinks this is a good idea I think there are more people 
than me that would find it quite useful though.


Greetings from Sweden,
Anders Johansson



[O] Bug: Setting HTML_INCLUDE_STYLE: nil doesn't work [8.0.3 (8.0.3-32-g0c789f-elpa @ /home/aj/.emacs.d/elpa/org-20130617/)]

2013-06-20 Thread Anders Johansson

I put:
#+HTML_INCLUDE_STYLE: nil
at the top of my org-file and expect the exported html file to not 
include the standard styles in it's header (documentation section 
12.6.9 CSS support).

This does not work and the styles are included as usual.

A quick debugging with edebug reveals that nil is interpreted as a 
string, nil, in the info-plist and therefore evaluates as true in the 
check in org-html--build-head:


  (when (plist-get info :html-head-include-default-style)
  (org-element-normalize-string org-html-style-default))

(from: ox-html.el:1448)

Greetings,
Anders Johansson


Emacs  : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4)
 of 2013-04-14 on marid, modified by Debian
Package: Org-mode version 8.0.3 (8.0.3-32-g0c789f-elpa @ 
/home/aj/.emacs.d/elpa/org-20130617/)


current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 outline-minor-mode-hook '((lambda nil (local-set-key  
outline-mode-prefix-map)
(define-key outline-minor-mode-map 
[(control tab)] (quote org-cycle))
(define-key outline-minor-mode-map [(shift 
tab)] (quote org-global-cycle)))

   )
 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-capture-after-finalize-hook '(orgaj-after-capture-options)
 org-confirm-shell-link-function 'yes-or-no-p
 org-speed-commands-user '((p ded/org-show-previous-heading-tidily)
   (n ded/org-show-next-heading-tidily))
 org-startup-folded nil
 org-default-notes-file ~/org/notes.org
 org-startup-indented t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-capture-mode-hook '((lambda nil
  (remove-hook (quote 
org-capture-after-finalize-hook)

   (quote (lambda nil (delete-frame
  )
 )
 org-from-is-user-regexp \\Anders Johansson\\
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

 org-tags-column -90
 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-use-speed-commands t
 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-hide-inline-tasks
  org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)

 org-M-RET-may-split-line '((headline . t) (default . t))
 org-hide-emphasis-markers t
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-fontify-whole-heading-line t
 org-agenda-files '(~/org/attsalja.org ~/org/attkopa.org 
~/org/sakerattfixa.org)

 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-after-todo-statistics-hook '(org-summary-todo)
 )




[O] Icalendar-export, priorities missing, possible bug

2013-02-10 Thread Anders Johansson

Hi,
When I'm exporting to icalendar, the priorities of todo items (or 
perhaps any items) don't get carried through correctly. It always falls 
back to priority 5 (the default).


After doing some edebugging I found that

(string-match org-priority-regexp hd)   [org-icalendar.el:539]

never seems to match.

This might be because 'hd' is group 4 True headline from the matching 
done with 'org-complex-heading-regexp' whereas group 3 according to this 
variable's docstring should hold the Priority cookie.


I guess someone who has greater knowledge of the code could see if this 
is really the case and fix it.


I can provide more debugging output and examples if needed and if others 
can't reproduce this.


Greetings,
Anders Johansson




Re: [O] Icalendar-export, priorities missing, possible bug

2013-02-10 Thread Anders Johansson

Hi,

2013-02-10 20:31, Nicolas Goaziou skrev:

Hello,

Anders Johansson mejlaande...@gmail.com writes:


When I'm exporting to icalendar, the priorities of todo items (or
perhaps any items) don't get carried through correctly. It always
falls back to priority 5 (the default).

After doing some edebugging I found that

 (string-match org-priority-regexp hd)   [org-icalendar.el:539]

never seems to match.

This might be because 'hd' is group 4 True headline from the
matching done with 'org-complex-heading-regexp' whereas group
3 according to this variable's docstring should hold the Priority
cookie.

I guess someone who has greater knowledge of the code could see if
this is really the case and fix it.

I can provide more debugging output and examples if needed and if
others can't reproduce this.

iCalendar export back-end has been rewritten. It is accessible from the
git distribution of Org. I didn't check if that bug is still present
though.


Regards,

Oh, that looks completely different. Taking a look at the newest git 
source, priority is now found like this (ox-icalendar.el)


 705  (let ((pri (or (org-element-property 
:priority entry)

 706 org-default-priority)))

and assuming this is consistent with the new framework it should of 
course work, but I haven't tested yet.


Funny that I found this problem now, using the less than a week old 
ELPA-package (20130204), when the new export framework was moved into 
core (commit 8dd2bf) just three days ago.


Greetings,
Anders Johansson