[O] [Bug] org-get-outline-path includes headline at point

2016-02-29 Thread Tobias Getzner

When using the current git HEAD, I’ve noticed that my agenda has become
rather messy. This is because I’m including the outline-path in agenda
entries, and it seems that the changes following aa78158 (possibly
66fbceb?) have changed the org-get-outline-path semantics.

The documentation says that this function returns the path *to* the
current headline, i.e., it used to exclude the current headline itself.
So for a top-level headline, the path would be nil, etc. This doesn’t
seem to be the case anymore in HEAD, where running org-get-outline-path
on a top-level headline will now return the headline string.

Best regards,
Tobias



Re: [O] [PATCH] org.el: fix org--get-outline-path-1

2016-02-29 Thread Tobias Getzner
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Tobias Getzner <tobias.getz...@gmx.de> writes:
>
>> Headline titles may be empty, in which case the respective match group
>> will be nil. This would throw an error when trying to regexp-replace
>> checkbox cookies.
>
> Indeed. Thank you for the report. I applied a slightly different fix,
> tho.

Thanks for fixing!

>> TODO: Depending on preference, a place-holder string might be a better
>> choice (for user-display) rather than leaving the outline-path element
>> empty.
>
> This makes sense. Maybe something like "[Empty]". WDYT?

[Empty] seems good to me.

Regards,
Tobias



[O] [PATCH] org.el: fix org--get-outline-path-1

2016-02-29 Thread Tobias Getzner
Headline titles may be empty, in which case the respective match group
will be nil. This would throw an error when trying to regexp-replace
checkbox cookies.

TODO: Depending on preference, a place-holder string might be a better
choice (for user-display) rather than leaving the outline-path element empty.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3e2f1c1..f45b9fc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11611,7 +11611,7 @@ (defun org--get-outline-path-1 ( use-cache)
 ;; Remove statistical/checkboxes cookies.
 (replace-regexp-in-string
  "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" ""
- (org-match-string-no-properties 4))
+ (or (org-match-string-no-properties 4) ""))
(if (org-up-heading-safe)
(let ((path (cons heading (org--get-outline-path-1 use-cache
  (when use-cache
-- 
2.7.2

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

2014-10-21 Thread Tobias Getzner
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





Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c (8.2.7c-64-g01f736-elpa @/home/tbg/.emacs.d/elpa/org-20140915/)]

2014-10-02 Thread Tobias Getzner
Hello Nicolas,

On So, 2014-09-28 at 23:50 +0200, Nicolas Goaziou wrote:
 Hello,
 
 Tobias Getzner tobias.getz...@gmx.de writes:
 
  When using LaTeX-based export targets that produce a .tex file as output
  (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
  foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
  no .tex file is produced, and «latexmk» fails with «no such file».
 
 Try killing foo.tex beforehand.

The foo.tex buffer was produced during the export (even when no «export
to buffer» is done), so I cannot kill it beforehand.

  Both after issuing the file-producing exports, and when issuing
  exports to buffer only (export to LaTeX buffer), the keybindings in the
  original org-mode buffer become garbled; e. g., issuing another «C-c
  C-e» after attempting a LaTeX export no longer invokes the export menu,
  but is now bound to the command «LaTeX-enviroment». Actions such as
  «fill-paragraph» also no longer work the way they usually work in
  org-mode. The mode-line still reports «Org» as the major mode, though.
  To get the expected commands back, I have to invoke «M-x org-mode».
 
 I cannot reproduce it. Did you find anything new?
 
 
 Regards,
 

Cf. my follow up at [1]. The issue seems to be related to the issue
(reported at [2]) when using org-mode together with follow-mode. It
should be reproducible when follow-mode is used and
«(TeX-source-correlate-mode)» is hooked into TeX-mode-hook. In contrast
to [2], aliasing «yes-or-no-p» to «y-or-n-p» does not seem to make a
difference, though. For the time being I had to disable follow-mode to
be able to do exports and eval code blocks.

Best regards,
T.

[1] http://article.gmane.org/gmane.emacs.orgmode/91009
[2] http://article.gmane.org/gmane.emacs.orgmode/90981





Re: [O] [BUG] Mark-up handling chokes on Unicode white-space

2014-09-24 Thread Tobias Getzner
Hi Aaron,

On Di, 2014-09-23 at 14:15 -0400, Aaron Ecay wrote:
 org-emphasis-regexp-components is known to be a wart.  You can search
 for posts on the mailing list.  Some people are trying to figure out how
 to get rid of it.  (You can search in particular for Nicolas Goaziou’s
 posts...)  Here’s one thread where you can see the lay of the land:
 http://mid.gmane.org/87zjl6ktu2@gmail.com.

Thank you for the background info!

 All that to say, the longer-term solution is to figure out some radically
 different approach.  In the meantime though, if you can provide a list of
 characters (by unicode name and/or code point) that you think should be
 added to that variable, someone might be able to add them. 

I guess the straightforward way of defining white-space would be just
using the set of characters with the Unicode property WSpace=Y, and
this would be what «[:space:]», «\s«, etc., should be expected to match
on Unicode-based locales. I’m supplying a list of code-points below,
for convenience.

I agree though that defining what counts as «white space» within the
confines of org-mode is putting the cart before the horse. I’ll try to
ascertain whether the Emacs implementation of «[:space:]» really only
does 8-bit spaces, and if so I’ll see whether I can poke someone on the
Emacs bug tracker about this.

Best regards,
T.


──
List of Unicode white-space

Below is the list of characters with the property White_Space set,
taken from the Unicode 7.0.0 character database. This includes
line-breaking white-space such as «line feed». If these are not
relevant, one can use the subset of space separators (Zs; these do not
include control characters such as Tab) and control chars (Cc).

0009..000D; White_Space # Cc   [5] control-0009..control-000D
0020  ; White_Space # Zs   SPACE
0085  ; White_Space # Cc   control-0085
00A0  ; White_Space # Zs   NO-BREAK SPACE
1680  ; White_Space # Zs   OGHAM SPACE MARK
2000..200A; White_Space # Zs  [11] EN QUAD..HAIR SPACE
2028  ; White_Space # Zl   LINE SEPARATOR
2029  ; White_Space # Zp   PARAGRAPH SEPARATOR
202F  ; White_Space # Zs   NARROW NO-BREAK SPACE
205F  ; White_Space # Zs   MEDIUM MATHEMATICAL SPACE
3000  ; White_Space # Zs   IDEOGRAPHIC SPACE
──





Re: [O] [Bug?] Results of code block printed in wrong place

2014-09-24 Thread Tobias Getzner
On Di, 2014-09-23 at 14:32 -0400, Aaron Ecay wrote: 
 I can reproduce this.
 Babel uses yes-or-no-p to confirm evaluation of the code block on export.
 yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must
 be the case that the lisp code allows some hook to run, which follow-mode
 uses to futz with which buffer/window is current, confusing org-mode.
 The C implementation I guess doesn’t run the same hook.

Thanks for investigating this. That «yes-or-no-p» vs. «y-or-n-p» should
make such a difference is quite bewildering.

 Sounds like the best advice for the moment is “don’t use follow-mode
 with org”.  Maybe it’s worth adding to the section on package conflicts
 in the manual?

Aw, that’s a pity. Given the vertically sparse nature of the tree
outline, follow-mode was quite naturally suited to complement org-mode,
in particular on a wide-screen monitor.

Considering you analysis above, should this be considered a bug in
follow-mode or Emacs core? If so, I could then pass this on to the
appropriate bug tracker.

Though I wonder how «(TeX-source-correlate-mode)» figures into this
(cf. my cross-link in this thread; hooking that mode into AucTeX will
break exporting horribly when both follow-mode and org-mode are active.
I thumbed through tex.el, and while it’s mostly Greek to me, I noticed
that some correlate-related functions also seem to be using y-or-n-p
directly. Follow-mode and plain LaTeX-mode appear to work in
conjunction, though.

Best,
T.





Re: [O] [Bug?] Results of code block printed in wrong place

2014-09-23 Thread Tobias Getzner
Hello Nicolas,

On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote:
 FWIW, I cannot reproduce it.

This was quite painful to isolate, but I’ve now identified a minimal
configuration which should trigger this bug.

──
;; BEGIN minimal.el
(add-to-list 'load-path (expand-file-name ~/.emacs.d/elpa/org-20140922))

;; Example needs sh; might also trigger with other langs.
(org-babel-do-load-languages
  'org-babel-load-languages
  '((sh .t)))

(fset 'yes-or-no-p 'y-or-n-p)

(defun my-org-mode-hook ()
   (follow-mode))
(add-hook 'org-mode-hook 'my-org-mode-hook)
;; END minimal.el
──

This seems rather bizarre. Both follow-mode and the y-or-n-p alias work
in isolation, but when both are used at the same time, I observe the
bug initially described. Can you confirm this?

Best regards,
Tobias



Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c(8.2.7c-64-g01f736-elpa@/home/tbg/.emacs.d/elpa/org-20140915/)]

2014-09-23 Thread Tobias Getzner
On Wed, 17 Sep 2014 09:29:48 +, Tobias Getzner wrote:

 On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote:
 
 When using LaTeX-based export targets that produce a .tex file as output
 (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
 foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
 no .tex file is produced, and «latexmk» fails with «no such file».
 
 Both after issuing the file-producing exports, and when issuing
 exports to buffer only (export to LaTeX buffer), the keybindings in the
 original org-mode buffer become garbled; e. g., issuing another «C-c
 C-e» after attempting a LaTeX export no longer invokes the export menu,
 but is now bound to the command «LaTeX-enviroment». 
 
 I seem to have located the trigger. Inter alia, my TeX-mode-hook invokes 
 «(TeX-source-correlate-mode)» which sets a variable so that synctex files 
 are generated when running AucTeX commands. When this command is removed, 
 exporting to .tex files appears to work again and the keybindings remain 
 unchanged after export. Is this a bug, or is some configuration required 
 to make org-mode not trip over the TeX-mode hook?

This behavior seems to be related to [1] in that it only triggers when
follow-mode is used. I’ve noticed I can keep my TeX-mode-hook unchanged if
I disable follow-mode. I contrast to [1], no interaction with aliasing
yes-or-no-p to y-or-n-p seemed to be present, though.

[1] http://article.gmane.org/gmane.emacs.orgmode/91006




Re: [O] [Bug?] Results of code block printed in wrong place

2014-09-23 Thread Tobias Getzner
On Tue, 23 Sep 2014 10:22:45 +0200, Tobias Getzner wrote:

 This was quite painful to isolate, but I’ve now identified a minimal
 configuration which should trigger this bug.
 
 ──
 ;; BEGIN minimal.el
 (add-to-list 'load-path (expand-file-name ~/.emacs.d/elpa/org-20140922))
 
 ;; Example needs sh; might also trigger with other langs.
 (org-babel-do-load-languages
   'org-babel-load-languages
   '((sh .t)))
 
 (fset 'yes-or-no-p 'y-or-n-p)
 
 (defun my-org-mode-hook ()
(follow-mode))
 (add-hook 'org-mode-hook 'my-org-mode-hook)
 ;; END minimal.el
 ──
 
 This seems rather bizarre. Both follow-mode and the y-or-n-p alias work
 in isolation, but when both are used at the same time, I observe the
 bug initially described.

I’ve found this bug might be related to [1], where org-mode seems to trip
when both follow-mode and TeX-source-correlate-mode are active. [1] does
not seem to interact with aliasing yes-or-no-p, though.

[1] http://article.gmane.org/gmane.emacs.orgmode/91009




[O] [BUG] Mark-up handling chokes on unicode whitespace

2014-09-23 Thread Tobias Getzner
When mark-up such as =monospace=, /italic/, etc. is preceded by a 
non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break 
space» (U+00A0), org-mode will not recognize the mark-up content 
correctly; i. e., this content will fail to be syntax-highlighted, and 
the mark-up syntax will be exported in verbatim by the exporter.

Best regards,
Tobias




Re: [O] [BUG] Mark-up handling chokes on unicode whitespace

2014-09-23 Thread Tobias Getzner
Hello Aaron!

On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote:

 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
 
 When mark-up such as =monospace=, /italic/, etc. is preceded by a
 non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or
 «no-break space» (U+00A0), org-mode will not recognize the mark-up
 content correctly
 
 You will need to change the variable org-emphasis-regexp-components; see
 the documentation thereof.

Thank you very much! This seems to do it.

Might I suggest amending unicode whitespace to the default? That variable 
seems a bit opaque and I might probably never have discovered it on my 
own; it also appears as if one has to ensure that this is set before org-
mode is «required», and one cannot easily just extend the default without 
also setting the rest. For type-setting purposes, at least the class of 
non-breaking whitespace is very useful.

At first I thought it might be easy to cleanly solve such problems by 
using the whitespace character class throughout, but to my chagrin it 
seems that at least «search-forward-regexp» will only match 8-bit 
whitespace this way, so I suppose Emacs regex isn’t aware of non-ASCII 
whitespace? :'| 

Best,
Tobias




[O] [Bug] Errors when evaluating LaTeX source block with new SVG headers patch

2014-09-22 Thread Tobias Getzner
Evaluating LaTeX source blocks had an issue where header options would be 
ignored when exporting to SVG; this appears to have been addressed in 
246df88. I have patched this commit into my 8.2.7c installation. While 
the headers now seem to work, I’ve noticed that LaTeX still doesn’t like 
the generated temporary files when SVG-output is selected. Below is an 
example which fails to work when SVG output is chosen, but which will 
work when PNG is used.

#+HEADERS: :headers '(\\usepackage{tikz} \\usetikzlibrary
{shapes,arrows,positioning})
#+BEGIN_src latex :file test.svg :imagemagick
\begin{tikzpicture}
  \node {quux quux quux};
\end{tikzpicture}
#+END_SRC

The generated temporary LaTeX file is shown below.

\documentclass[preview]{standalone}
\def\pgfsysdriver{pgfsys-tex4ht.def}
\usepackage[usenames]{color}
\usepackage{tikz}
\usepackage{color}
\usepackage{listings}
\usepackage{amsmath}
\usepackage{tikz}
\usetikzlibrary{shapes,arrows,positioning}
\begin{document}\begin{tikzpicture}
\node {quux};
\end{tikzpicture}\end{document}

By default, LaTeX will choke on this with a lot of undefined command 
errors. I have no clue about PGF, but I’ve noticed that if I insert 
«\usepackage{pgf}» before the «\def\pgfsysdriver» line, this will resolve 
those errors. Should this be done in ob-latex too?

After these errors are resolved, though, LaTeX will still complain about 
an option clash for the color package. At first I thought this might be 
because the colors package is imported twice. But apparently PGF will 
also import colors, so that both the «\usepackage{pgf}» and the «\def
\pgfsysdriver» had to come after «\usepackage[usenames]{color}».

Best regards,
T.




[O] [Bug?] Results of code block printed in wrong place

2014-09-22 Thread Tobias Getzner
Hello,

I have a strange problem when exporting the following file:

* heading 1
#+BEGIN_SRC sh :eval never
echo baz
#+END_SRC

* heading 2
#+BEGIN_SRC sh :exports results
echo quux
#+END_SRC

When I export this document, and point is on heading 1 when issuing the
«C-c C-e», the results of the code in heading 2 are added under the code
block in heading 1 (sic). o_O So I am seeing:

* heading 1
#+BEGIN_SRC sh :eval never
echo baz
#+END_SRC

#+RESULTS:
: quux

When point is at heading 2 when issuing «C-c C-e» (or when doing a manual
eval), the results are as expected.

When point is after #+END_SRC of heading 2 when issuing the export, I’m
also seeing that the results are now suddenly added inline:

* heading 2
#+BEGIN_SRC sh :exports results
echo quux
#+END_SRC=quux
=

Additionally, the results of the code are not actually exported until I
run the export a second time; I’m not sure whether this is the expected
behavior. Should the export already take into account any results produced
during the export run?

Any ideas where to look or what the problem might be?

Best,
T.

Org-mode version 8.2.7c (8.2.7c-71-g60418c-elpa @ /home/tzg/.emacs.d/elpa/
org-20140922/)





[O] Bug: Face defined for quote/verse blocks, but not used?

2014-09-18 Thread Tobias Getzner
Hello,

I was looking into applying a custom font to certain org-mode faces, when 
I noticed that no dedicated face seems to be set for verse and quote 
blocks. Looking into org-faces.el, it looked (to non-Elisp-trained eyes) 
like there are faces set-up for these blocks, but for some reason they 
don’t seem to be applied. At least M-x describe-text-properties doesn’t 
show any face properties at point when in these blocks.

Best regards,
Tobias


Org-mode version 8.2.7c (8.2.7c-64-g01f736-elpa @ /home/tbz/.emacs.d/elpa/
org-20140915/)




[O] «Macro» expansion in source blocks; code-sharing between blocks

2014-09-18 Thread Tobias Getzner
Hello,

I was wondering whether there exists some way of sharing literal code 
(or, possibly, code results) between subsequent code blocks. E.g., I was 
trying to create a document containing several tikz graphics, and I would 
like to share a number of style definitions between these. When I only 
export to LaTeX, I can of course just use isolated BEGIN_LATEX blocks, 
and refer to shared stuff using LaTeX semantics. But I was wondering if 
something like this could possibly be done using code blocks only.

It seemed to me that there are two «expansion mechanisms» for source code 
in org: 1. Calling named source blocks; 2. macro expansion.

As for 1., calling a named block from within another isn’t currently 
handled, is it? As for 2., macro expansion only occurs upon export, 
right? While I found an interesting proposal to expand macros within 
source code at [1], this supposedly only works when either doing an 
export or when tangling an external file.

Are there any convenient inline-expansion methods I might have overlooked?

Best regards,
Tobias


[1] https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00843.html




Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

2014-09-18 Thread Tobias Getzner
On Thu, 18 Sep 2014 13:17:14 +, Tobias Getzner wrote:

 Are there any convenient inline-expansion methods I might have
 overlooked?

To illustrate, I was wondering if any of the following is feasible 
somehow:

* Semantic expansion
  #+name setup_fu
  #+begin_src sh :results raw
  echo 2
  #+end_src

  #+begin_src sh :results raw
  echo 1
  echo {{{call_setup_fu()}}} ← some sort of escape syntax
  echo 3
  #+end_src

  #+results:
  1
  2
  3

* Syntactic expansion
  #+begin_macro setup_fu
  echo 2
  #+end_macro

  #+begin_src sh :results raw
  echo 1
  {{{setup_fu()}}}
  echo 3
  #+end_src

  #+results:
  1
  2
  3




Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

2014-09-18 Thread Tobias Getzner
On Thu, 18 Sep 2014 15:01:37 +0100, Eric S Fraga wrote:

 Are there any convenient inline-expansion methods I might have
 overlooked?
 Org src blocks can reference other src blocks.  Note the :noweb yes
 option and the use of 

Nice! And I see I get «semantic» expansion when I add call syntax after 
the block’s name. This is quite awesome.

Not being familiar with the term, «noweb» must have slipped my attention 
when I was skimming through that section. Thanks very much for the 
pointer!

Best,
T.




[O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c (8.2.7c-64-g01f736-elpa @/home/tbg/.emacs.d/elpa/org-20140915/)]

2014-09-17 Thread Tobias Getzner
Hello,

When using LaTeX-based export targets that produce a .tex file as output
(export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
no .tex file is produced, and «latexmk» fails with «no such file».

Exporting to a LaTeX buffers seems to work.

Both after issuing the file-producing exports, and when issuing
exports to buffer only (export to LaTeX buffer), the keybindings in the
original org-mode buffer become garbled; e. g., issuing another «C-c
C-e» after attempting a LaTeX export no longer invokes the export menu,
but is now bound to the command «LaTeX-enviroment». Actions such as
«fill-paragraph» also no longer work the way they usually work in
org-mode. The mode-line still reports «Org» as the major mode, though.
To get the expected commands back, I have to invoke «M-x org-mode».

I’ve also tested exporting to HTML, and this seems to work as usual. I
haven’t been using the LaTeX exporter in a while, so I’m not sure since
when this issue has been present.

I’d welcome any suggestions as to what might be the problem.

Best regards,
Tobias



Emacs  : GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc
Package: Org-mode version 8.2.7c (8.2.7c-64-g01f736-elpa @ 
/home/tbg/.emacs.d/elpa/org-20140915/)

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)
 org-latex-classes '((sr-article
  \\documentclass[11pt]{article}\n
[DEFAULT-PACKAGES]\n[PACKAGES]\n[EXTRA]
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\paragraph{%s} . \\paragraph*{%s})
  (\\subparagraph{%s} . \\subparagraph*{%s}))
 (article \\documentclass[11pt]{article}
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\subsubsection{%s} . \\subsubsection*{%s})
  (\\paragraph{%s} . \\paragraph*{%s})
  (\\subparagraph{%s} . \\subparagraph*{%s}))
 (report \\documentclass[11pt]{report}
  (\\part{%s} . \\part*{%s}) (\\chapter{%s} . 
\\chapter*{%s})
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\subsubsection{%s} . \\subsubsection*{%s}))
 (book \\documentclass[11pt]{book} (\\part{%s} . 
\\part*{%s})
  (\\chapter{%s} . \\chapter*{%s})
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\subsubsection{%s} . \\subsubsection*{%s}))
 )
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-ellipsis  ▼
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-log-done t
 org-latex-format-inlinetask-function 'ignore
 org-confirm-shell-link-function 'yes-or-no-p
 org-image-actual-width '(500)
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-startup-folded nil
 org-latex-pdf-process '(latexmk -pdf %f latexmk -c %f)
 org-file-apps '((auto-mode . emacs) (.* . xdg-open %s))
 org-special-ctrl-a/e t
 org-shiftleft-hook '((lambda nil (org-ref-swap-citation-link -1)))
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-startup-indented t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(lambda (name contents) contents)
 org-from-is-user-regexp nil
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-tags-column 0
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(org-mode-reftex-setup my-org-mode-hook (lambda nil 
(org-bullets-mode 1))
 #[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-ac/setup-current-buffer)
 org-outline-path-complete-in-steps nil
 org-ascii-format-drawer-function '(lambda (name contents width) contents)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point 
org-babel-execute-safely-maybe)
 

Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c (8.2.7c-64-g01f736-elpa@/home/tbg/.emacs.d/elpa/org-20140915/)]

2014-09-17 Thread Tobias Getzner
On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote:

 When using LaTeX-based export targets that produce a .tex file as output
 (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
 foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
 no .tex file is produced, and «latexmk» fails with «no such file».
 
 Both after issuing the file-producing exports, and when issuing
 exports to buffer only (export to LaTeX buffer), the keybindings in the
 original org-mode buffer become garbled; e. g., issuing another «C-c
 C-e» after attempting a LaTeX export no longer invokes the export menu,
 but is now bound to the command «LaTeX-enviroment». 

I seem to have located the trigger. Inter alia, my TeX-mode-hook invokes 
«(TeX-source-correlate-mode)» which sets a variable so that synctex files 
are generated when running AucTeX commands. When this command is removed, 
exporting to .tex files appears to work again and the keybindings remain 
unchanged after export. Is this a bug, or is some configuration required 
to make org-mode not trip over the TeX-mode hook?

Best regards,
T.




Re: [O] Multi-line links

2014-08-04 Thread Tobias Getzner
Hello Nicolas,

On Sa, 2014-07-26 at 15:32 +0200, Nicolas Goaziou wrote:
 In the long run, I'm pretty sure the project will benefit more if you
 bring in your own, temporary, inexperience and start hacking from there.

I’ll definitely look into this once I get a hang of Elisp. When I
(unsuccessfully) tried to figure out how links are handled, it occurred
to me some more inline docs would be useful; but then again maybe once
one is used to Elisp the code becomes more transparent. When I have
some time for another attempt to wrap my head around the code, maybe
I could try adding in some comments as I go along.

  since multi-line descriptions seemed to be working (though only for 
  3 lines) and since the raw-path seemed to contain the needed
  line-breaks already. But if I understand you correctly, the
  complication is that the path parsing is the same across different
  link types, and so one cannot simply fix it up so that :path is
  equivalent to :raw-path, just with the link prefix stripped of?
 
 I fixed it in maint. org-element.el used an inadequate regexp to
 analyze the path. Could you confirm it?

If I understand correctly, this change addresses the issue of truncated
«path» and «raw-link»? These seem to return the expected results for
multi-line links now. Wonderful! Thank you very much for this!

The syntax highlighting seems to also work, though it requires
refreshing the buffer display.

The only remaining issue would be that these links can only be
triggered from the first line. Clicking on another line will yield «No
link found», so I cannot get org-ref to return the BibTeX entry
appropriate for the line from which the action is triggered.

Strangely, when I inspect the other lines using org-element-context,
the link type is correctly shown, even though it’s a few lines before
point. But when issuing org-open-at-point, it seems no handler is found
when point is not on the first line of a multi-line link.

Best regards,
Tobias





Re: [O] Multi-line links

2014-07-22 Thread Tobias Getzner
Nicolas, thank you for reply. Due to some health issues I’m only
responding now.

On So, 2014-07-06 at 21:28 +0200, Nicolas Goaziou wrote:
 Tobias Getzner tobias.getz...@gmx.de writes:
 
  If there is some strong reason for a hard-coded limit, would it be
  possible to expose the limit as a user-definable variable, and to fix
  the :path truncation issue?
 
 I don't think there is a strong reason for that limitation.
 
 RFC 3986 (Appendix C) suggests how to handle multi-lines URI. We could
 use it to handle such links.
 
 Note that there is more than org-element.el to change though (e.g.,
 `org-make-link-regexps') and some parts of Org relying only on regexps
 to extract the path, may not work properly with such links.
 
 Do you want to work on such a patch?

I’m afraid given my nigh complete inexperience with elisp it is
unlikely I’ll be able to provide a good, generic solution for this. My
original hope was that for someone familiar with the code, there
wouldn’t be many changes needed, since multi-line descriptions seemed
to be working (though only for  3 lines) and since the raw-path seemed
to contain the needed line-breaks already. But if I understand you
correctly, the complication is that the path parsing is the same across
different link types, and so one cannot simply fix it up so that :path
is equivalent to :raw-path, just with the link prefix stripped of?

When I experimented with making multi-line BibTeX links work, I tried
working around the issue of the path being truncated by using raw-path
instead. But it seems that this breaks when doing export, since the
handler seems to only be given the normal (truncated) path as an
argument. Is there any way to make the exporter call the export handler
with the raw-path as an argument, currently?

Best regards,
T.





Re: [O] Multi-line links

2014-07-06 Thread Tobias Getzner
Hello Nicolas,

On Sun, 2014-07-06 at 09:23 +0200, Nicolas Goaziou wrote:
 Tobias Getzner tobias.getz...@gmx.de writes:
  On Wed, 2014-07-02 at 12:39 +0200, Tobias Getzner wrote:
  One additional issue I’ve hit upon is that the link :path returned by
  org-mode is also truncated after a newline, while the :raw-link is
  correctly returned in full.
 
 Could you provide an example?

My original example also applies to this issue.

[[citet:green1994hybridreasoningmodel,
  green1994generatingindirectanswers,
  green1992conversationalimplicaturesindirect]]

Clicking on the first line in the above link, the returned :path will
be just be «green1994hybridreasoningmodel,», i. e., the :path is
truncated after the newline. The raw-path will be correct, however,
i. e., «citet:green1994hybrid…,\ngreen1994generating…,\ngreen1992…».

Apart from the truncation issue, the link itself can be triggered only
via the first two lines, while the last line yields «no link found»,
despite the fact that the last line is syntax-highlighted and
clickable.

 Note that Org links do not allow newline characters in the link part.
 Is it really an issue or a limitation?

According to the syntax spec, newlines should be allowed both in the
link path and in the description, but I realize the syntax spec is kind
of after-the-fact. On the other hand, the implementation seems to
already support n-line links for the arbitrary value of 2 (with the
caveat that the :path value currently breaks).

The reason why I consider it a limitation is cases like the one I
initially outlined. An extension like org-ref might want to internally
parse the link path, and it makes sense to allow newlines as separators
here, so that the links remain legible and so one can have hard
line-breaks at 80 cols. In particular, BibTeX-based links can become
very long. If one prefers hard line-breaks, these links will impair the
readability of the document.

On the other hand, it’s an inconsistency that these links will be
correctly syntax-highlighted and clickable on every line, with the
handler then breaking on lines  2 and with a truncated :path. 

Since link paths and descriptions cannot contain square brackets, would
it be possible to rely just on these to terminate link parsing?

In an earlier post of yours, you seem to have identified the relevant
code responsible for this:

http://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00532.html

If there is some strong reason for a hard-coded limit, would it be
possible to expose the limit as a user-definable variable, and to fix
the :path truncation issue?

Best regards,
Tobias





[O] Multi-line links

2014-07-02 Thread Tobias Getzner
Dear org-mode list,

It appears that multi-line links in org-mode will only work with if
they span no more than two lines:

http://comments.gmane.org/gmane.emacs.orgmode/19919

I was wondering if this hard-coded limit could be removed in future
versions, also given the fact that the syntax spec. does not preclude
newline characters from appearing within links.

In my case, I was trying to set-up the org-ref extension so that it
would handle multi-line links like the following, which makes them more
legible than a single long line.

[[citet:green1994hybridreasoningmodel,
  green1994generatingindirectanswers,
  green1992conversationalimplicaturesindirect]]

The problem with this is that org-mode will only invoke the link
handler for the first to lines, apparently due to the hard-coded limit,
and for the third line, org-mode will only report «no link found».

Since org-ref parses the links internally (i. e., the link-open action
is different for each bibkey), this cannot be worked around by clicking
on the first two lines.

Best regards,
Tobias