[O] How to indent source block when export to PDF/ODT

[Enzo Chi]

When I export file to PDF/ODT, the source block is start from left without
indent.

How to add some indent?

Re: [O] problems with export and :cache

[Andreas Leha]

Hi all,

Andreas Leha  writes:
> Hi all,
>
> babel's :cache seems to be ignored during export.  At least on #+call
> lines.
>
> In the example below the caching works fine for interactive evaluation,
> i.e. C-c C-c on the #+call line returns immediately.
>
> If I export the subtree with the #+call line, however, the code block
> gets executed and the export is slow.
>
> I'd expect no evaluation even during export.
>
> Is this a bug or am I missing something?
>
> Regards,
> Andreas
>
> PS: The example:
>
> * Test Cached Export
> ** A long running code block.
> #+name: foo
> #+begin_src emacs-lisp :var bar="baz"
>   (sit-for 15)
>   (message "bar=%S" bar)
> #+end_src
>
> #+RESULTS: foo
> : bar="baz"
>
> ** Calling
>
> Exporting this subtree will demonstrate my problem.  I expect the call
> line below to not execute anything.  This works for interactive
> execution (C-c C-c).  But if I export this subtree only, the code is
> executed.
>
> This returns immediately thanks to the cached result.
> #+call: foo("qux") :cache yes
>
> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
> : bar="qux"


I should have added that adding :eval no-export to the #+call line does
not help either.

To me this seems to be a bug.

Best,
Andreas

[O] problems with export and :cache

[Andreas Leha]

Hi all,

babel's :cache seems to be ignored during export.  At least on #+call
lines.

In the example below the caching works fine for interactive evaluation,
i.e. C-c C-c on the #+call line returns immediately.

If I export the subtree with the #+call line, however, the code block
gets executed and the export is slow.

I'd expect no evaluation even during export.

Is this a bug or am I missing something?

Regards,
Andreas

PS: The example:
--8<---cut here---start->8---
* Test Cached Export
** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src

#+RESULTS: foo
: bar="baz"

** Calling

Exporting this subtree will demonstrate my problem.  I expect the call
line below to not execute anything.  This works for interactive
execution (C-c C-c).  But if I export this subtree only, the code is
executed.

This returns immediately thanks to the cached result.
#+call: foo("qux") :cache yes

#+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
: bar="qux"
--8<---cut here---end--->8---

Re: [O] Links in comments

[Samuel Wales]

(highlight-regexp org-ts-regexp3 'org-date)

Re: [O] Links in comments

[Samuel Wales]

On 10/28/15, John Kitchin  wrote:
> Your mileage may vary, but this seems to show links in comments for me:
>
> #+BEGIN_EXAMPLE
> (highlight-regexp org-any-link-re 'org-link)
> #+END_EXAMPLE

nice workaround!  thanks!

it's a matter of perspective.  comments mean two separate things:

  1] "commenting out"
  2] "note to self"

note that org-mouse does [and should if and only if fontified] allow
clicks on commented links, following the "note to self" principle.

[O] Update hangs on compiling org-timer.el

[Christian Moe]

Hi,

Anyone else seeing this?

I'm trying to update Org for the first time in ages, using "make
update2" on Mac OS X 10.6.8. (No, haven't upgraded that for a while,
either.)

The process gets as far as "Compiling path/to/lisp/org-timer.el" and
hangs there until I kill it.

Yours,
Christian

Re: [O] Agenda to iCal not working

[Jorge A. Alfaro-Murillo]

Matt Lundin writes:

Jorge A. Alfaro-Murillo writes: 

Ken Mankoff writes: 

I'm using the examples from 
https://www.gnu.org/software/emacs/manual/html_node/org/Exporting-Agenda-Views.html 

Specifically,  

(setq org-agenda-custom-commands [...]  




But the HTML, PS, and ICS files are not being created. If I'm 
visiting an Org file and run (org-icalendar-export-to-ics) 
then the ICS is generated.  

Can someone offer advice why the ICS isn't generated when I 
generate a specific agenda view? 


Setting up the agenda custom commands is not related to ical 
export. 


In fact, it is. 


Yes, sorry what I meant to say is that that alone does not produce 
the files. You have to use org-store-agenda-views (C-c a e) from 
the agenda view or export directly using 
org-icalendar-combine-agenda-files.


--
Jorge.

Re: [O] Some projects

[Matt Price]

On Wed, Oct 28, 2015 at 10:36 AM, Matt Price  wrote:

>
> That does seem to be an issue, but I bet it wouldn't be too hard to fix.
> Currently outputformat is hardcoded on line 94 of lib/citeServer.js; I'm a
> little slow at reading JS but I think replacing line 259 with a switch
> statement analogous to the one for responseformat at line 291 would allow
> one to use the full capacities of citeproc.js.  I think the best route
> would probably be to submit a patch to citeproc.js adding an org-mode
> output format, propagating that up to citeproc-node, submitting a second
> patch to citeproc-node, and then writing the org-internal functions
> properly.  We might also want to add an additional responseformat option.
>
>> Matt
>>
>
>
here is a very half-assed aproach that adds an org-mode outputformat to
citeproc.  it's incomplete but does much of wha it ought to.  some of the
elements I left in html b/c I'm not sure how they oughtto be handled in
org.  e.g., how do we handle smallcaps?

(this is a patch to citeproc-node, so requires installing the repo from
github first).
diff --git a/lib/citeServer.js b/lib/citeServer.js
index 691ca78..a5d82c7 100644
--- a/lib/citeServer.js
+++ b/lib/citeServer.js
@@ -91,7 +91,7 @@ var defaultCiteserverConfig = {
 var defaultRequestConfig = {
 bibliography: '1',
 citations: '0',
-outputformat: 'html',
+outputformat: 'org',
 responseformat: 'json',
 locale: 'en-US',
 style: 'chicago-author-date',
diff --git a/lib/citeproc.js b/lib/citeproc.js
index 08a8008..8622533 100644
--- a/lib/citeproc.js
+++ b/lib/citeproc.js
@@ -13140,6 +13140,106 @@ CSL.Output.Formats.prototype.html = {
 return "http://dx.doi.org/"; + str + "\">" + str + "";
 }
 };
+
+CSL.Output.Formats.prototype.org = {
+"text_escape": function (text) {
+if (!text) {
+text = "";
+}
+return text.replace(/&/g, "&")
+.replace(//g, ">")
+.replace("  ", "  ", "g")
+.replace(CSL.SUPERSCRIPTS_REGEXP,
+ function(aChar) {
+ return "" + CSL.SUPERSCRIPTS[aChar] + "";
+ });
+},
+"bibstart": "* Bibliography\n",
+"bibend": "\n",
+"@font-style/italic": "/%%STRING%%/",
+"@font-style/oblique": "/%%STRING%%/",
+"@font-style/normal": "%%STRING%%",
+"@font-variant/small-caps": "%%STRING%%",
+"@passthrough/true": CSL.Output.Formatters.passthrough,
+"@font-variant/normal": false,
+"@font-weight/bold": "*%%STRING%%*",
+"@font-weight/normal": false,
+"@font-weight/light": false,
+"@text-decoration/none": false,
+"@text-decoration/underline": "_%%STRING%%_",
+"@vertical-align/sup": "^{%%STRING%%}",
+"@vertical-align/sub": "_{%%STRING%%}",
+"@vertical-align/baseline": false,
+"@strip-periods/true": CSL.Output.Formatters.passthrough,
+"@strip-periods/false": CSL.Output.Formatters.passthrough,
+"@quotes/true": function (state, str) {
+if ("undefined" === typeof str) {
+return state.getTerm("open-quote");
+}
+return state.getTerm("open-quote") + str + state.getTerm("close-quote");
+},
+"@quotes/inner": function (state, str) {
+if ("undefined" === typeof str) {
+return "\u2019";
+}
+return state.getTerm("open-inner-quote") + str + state.getTerm("close-inner-quote");
+},
+"@quotes/false": false,
+"@cite/entry": function (state, str) {
+return state.sys.wrapCitationEntry(str, this.item_id, this.locator_txt, this.suffix_txt);
+	},
+"@bibliography/entry": function (state, str) {
+var insert = "";
+if (state.sys.embedBibliographyEntry) {
+insert = state.sys.embedBibliographyEntry(this.item_id) + "\n";
+}
+return "  \n" + str + "\n" + insert;
+},
+"@display/block": function (state, str) {
+return "\n\n" + str + "\n";
+},
+"@display/left-margin": function (state, str) {
+return "\n" + str + "";
+},
+"@display/right-inline": function (state, str) {
+return "" + str + "\n  ";
+},
+"@display/indent": function (state, str) {
+return "" + str + "\n  ";
+},
+"@showid/true": function (state, str, cslid) {
+if (!state.tmp.just_looking && ! state.tmp.suppress_decorations) {
+if (cslid) {
+return "" + str + "";
+} else if ("string" === typeof str) {
+var prePunct = "";
+if (str) {
+var m = str.match(CSL.VARIABLE_WRAPPER_PREPUNCT_REX);
+prePunct = m[1];
+str = m[2];
+}
+var postPunct = "";
+if (str && CSL.SWAPPING_PUNCTUATION.indexOf(str.slice(-1)) > -1) {
+postPunct = str.slice(-1);
+str = str.slice(0,-1);
+}
+return state.sys.va

Re: [O] Can't email multipart/alternative anymore

[Peter Davis]

Aaron Ecay  writes:

>
> As Nicolas said, it would be good to know if upgrading org fixes the
> issue that you see.

I just tried updated via the list-packages, but ...

1) org-version now says 8.3.2 (formerly 8.2.10)

2) I now get this error:

Making completion list...
Quit
Mark set [2 times]
org-babel-exp process dot at line 9...
executing Dot code block...
Wrote 
/var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-27532hcO/ob-input-27532inY
Code block evaluation complete.
apply: Wrong type argument: listp, #("Org Mime Org Buffer HTMLize test" 0 32 
(:parent (#0)))

3) The stackdump for this:

Debugger entered--Lisp error: (wrong-type-argument listp #("Org Mime Org Buffer 
HTMLize test" 0 32 (:parent (#1
  org-element-set-contents(#("Org Mime Org Buffer HTMLize test" 0 32 (:parent 
(#0
  apply(org-element-set-contents #("Org Mime Org Buffer HTMLize test" 0 32 
(:parent (#0))) nil)
  #[(s) "\306\307\310#\311\312   
\211:\204\313\202\"@9\203!AA\202\")\"\210\314\315\n 
\211:\2043\313\202@@9\203?AA\202@)#\210  
\316\211\n;\203V\317\320\f#\202\\\321A@\f\"*\211;\203n\322\313\f
$\202zA\323A@\f
#\240\210+\210\nA  A@\240\210\n@\240*\207" [s new old element property 
value replace-regexp-in-string "\n" " " mapc #[(blob) "\305
\211;\203\306\f\307\n$\202 \fA\310\fA@\n#\240\210\f+\207" [blob old value 
property element :parent org-add-props nil plist-put] 6] nil apply 
org-element-set-contents :parent get-text-property 0 plist-get org-add-props 
plist-put] 6](#("Org Mime Org Buffer HTMLize test" 0 32 (:parent (#0
  #[(--data) "\211:\204   ;\205\306\202 @9\205 
@)?\206\337\203,\307\310\">\206\337\n\2047\311\f\"\202\337\n\312=\203\\\311\f\211:\204J\313\202W
  @9\203V AA\202W )\"\202\337\n
>\203\202!\211\203\201\203z\314\315\"\210\202\201B)\316=\203\312;\204\312\n\236A\313\211\203\311@\f
>   ;\203\266\317\320  #\202\275\307   
>A@\"*!\210A\211\204\234*\203\202\316=\203\202\n>\203\202\313 
>\211\203\201@\211 @ A  ;\203
\317\320 #\202\307  
>A@\"*!\"!\203w\"#\235\203_\"$\235\203P\321!!\313%\211\203L@%\f%A!\210\f%@!\210A\211\2042*\202w\f!A!\210\f!@!\210\202w\"$\235\203r\311\f\321!!\"\210\202w\f!!\210*A\211\204\350*\n&>\206\337\211:\204\224\313\202\241
> @9\203\240  AA\202\241  
>)?\206\337\322=\203\265\n'>?\206\337\323=\203\303\n(>\206\337\311\f\211:\204\320\313\202\335
> @9\203\334  AA\202\335  )\")\207" [--data element --type info 
>--walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw 
>--map-first-match objects get-text-property 0 reverse greater-elements 
>elements fun result first-match --acc --category 
>org-element-secondary-value-alist p --dolist-tail-- property with-affiliated 
>org-element-all-elements org-element--parsed-properties-alist kwd-pair value 
>kwd org-element-dual-keywords org-element-multiple-keywords line no-recursion 
>org-element-greater-elements org-element-all-objects] 6](#("Org Mime Org 
>Buffer HTMLize test" 0 32 (:parent (#0
  mapc(#[(--data) "\211:\204  ;\205\306\202 @9\205 
@)?\206\337\203,\307\310\">\206\337\n\2047\311\f\"\202\337\n\312=\203\\\311\f\211:\204J\313\202W
  @9\203V AA\202W )\"\202\337\n
>\203\202!\211\203\201\203z\314\315\"\210\202\201B)\316=\203\312;\204\312\n\236A\313\211\203\311@\f
>   ;\203\266\317\320  #\202\275\307   
>A@\"*!\210A\211\204\234*\203\202\316=\203\202\n>\203\202\313 
>\211\203\201@\211 @ A  ;\203
\317\320 #\202\307  
>A@\"*!\"!\203w\"#\235\203_\"$\235\203P\321!!\313%\211\203L@%\f%A!\210\f%@!\210A\211\2042*\202w\f!A!\210\f!@!\210\202w\"$\235\203r\311\f\321!!\"\210\202w\f!!\210*A\211\204\350*\n&>\206\337\211:\204\224\313\202\241
> @9\203\240  AA\202\241  
>)?\206\337\322=\203\265\n'>?\206\337\323=\203\303\n(>\206\337\311\f\211:\204\320\313\202\335
> @9\203\334  AA\202\335  )\")\207" [--data element --type info 
>--walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw 
>--map-first-match objects get-text-property 0 reverse greater-elements 
>elements fun result first-match --acc --category 
>org-element-secondary-value-alist p --dolist-tail-- property with-affiliated 
>org-element-all-elements org-element--parsed-properties-alist kwd-pair value 
>kwd org-element-dual-keywords org-element-multiple-keywords line no-recursion 
>org-element-greater-elements org-element-all-objects] 6] (#("Org Mime Org 
>Buffer HTMLize test" 0 32 (:parent #0
  #[(--data) "\211:\204   ;\205\306\202 @9\205 
@)?\206\337\203,\307\310\">\206\337\n\2047\311\f\"\202\337\n\312=\203\\\311\f\211:\204J\313\202W
  @9\203V AA\202W )\"\202\337\n
>\203\202!\211\203\201\203z\314\315\"\210\202\201B)\316=\203\312;\204\312\n\236A\313\211\203\311@\f
>   ;\203\266\317\320  #\202\275\307   
>A@\"*!\210A\211\204\234*\203\202\316=\203\202\n>\203\202\313 
>\211\203\201@\211 @ A  ;\203

[O] how can I debug an async export error?

[Alan Schmitt]

Hello,

I have a file that exports well synchronously, but that fails when
exporting asynchronously. I set the `org-export-async-debug' to t but
the Org Export Process buffer that is left behind in not very useful.

--8<---cut here---start->8---
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/ob.el' newer than 
byte-compiled file
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/ob-exp.el' newer 
than byte-compiled file
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/ob-lob.el' newer 
than byte-compiled file
Loading /Users/schmitta/.emacs.d/custom.el (source)...
Loading delsel...
Loading time...
Loading company...
Loading recentf...
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/org-info.el' 
newer than byte-compiled file
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/org-mhe.el' newer 
than byte-compiled file
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/org-rmail.el' 
newer than byte-compiled file
Source file `/Users/schmitta/.emacs.d/org/emacs/site-lisp/org/org-w3m.el' newer 
than byte-compiled file
Loading /Users/schmitta/.emacs.d/recentf...
Cleaning up the recentf list...
Cleaning up the recentf list...done (0 removed)
[yas] Prepared just-in-time loading for /Users/schmitta/.emacs.d/snippets
[yas] Reloaded everything (snippets will load just-in-time)
[yas] Loading for `emacs-lisp-mode', just-in-time: (lambda nil 
(yas--load-directory-1 (quote 
/Users/schmitta/.emacs.d/snippets/emacs-lisp-mode) (quote emacs-lisp-mode)))!
[yas] Loading compiled snippets from 
/Users/schmitta/.emacs.d/snippets/emacs-lisp-mode
[yas] Prepared just-in-time loading for /Users/schmitta/.emacs.d/snippets
[yas] Reloaded everything (snippets will load just-in-time)
../../.emacs.d/init.el: `flet' is an obsolete macro (as of 24.3); use either 
`cl-flet' or `cl-letf'.
Loading reftex...
Compiling label environment definitions...
Compiling label environment definitions...done
Scanning entire document...
Scanning file /Users/schmitta/projets/org-mode/doc/library-of-babel.org
Scanning document... done
[yas] Loading for `text-mode', just-in-time: (lambda nil (yas--load-directory-1 
(quote /Users/schmitta/.emacs.d/snippets/text-mode) (quote text-mode)))!
[yas] Loading compiled snippets from /Users/schmitta/.emacs.d/snippets/text-mode
Invalid color
Saving file /Users/schmitta/.emacs.d/recentf...
Wrote /Users/schmitta/.emacs.d/recentf
--8<---cut here---end--->8---

The error seems to be the “Invalid color” near the end, but I have no
idea where it comes from.

Is it possible to ask org-async-export to leave a backtrace in this
buffer when it fails?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated October 26, 2015, Mauna Loa Obs.): 398.51 ppm


signature.asc
Description: PGP signature

Re: [O] Some projects

[Matt Price]

On Tue, Oct 27, 2015 at 11:31 PM, Matt Lundin  wrote:

> Matt Price  writes:
>
> > On Tue, Oct 27, 2015 at 9:51 AM, Rasmus  wrote:
> >
> >
> > Aaron Ecay  writes:
> >
> > Indeed. I guess this is what they use:
> >
> > https://github.com/zotero/citeproc-node
> >
> > It also looks rather complex...
> >
> >
> > FWIW, I just tried installing this on my Arch system, but it doesn't
> > work with node 0.12, and I am currently unable to switch to io.js due
> > to dependencies of several other projects. I guess tools like NVM can
> > help with this situation, but I worry that node is currently a moving
> > target and might lead to lots of platform-dependent buggy behaviour.
>
> Testing it now... Works fine on my Arch system. Arch's current nodejs is
> 4.2. As I understand it, io.js has been merged back into node 4.+
>

upgraded from 0.12, and it works fine.  My problem before was that some
important npm packages were still incompatible with node 4.2; it may be
that that's no longer an issue, and I spoke too soon.


>
> The citeproc-node server itself is not very complex. It's just a node
> wrapper around citeproc-js. The big limitation, it seems to me, is that
> it only accepts a json format as input. Also it seems to use html markup
> in all its output formats.
>

That does seem to be an issue, but I bet it wouldn't be too hard to fix.
Currently outputformat is hardcoded on line 94 of lib/citeServer.js; I'm a
little slow at reading JS but I think replacing line 259 with a switch
statement analogous to the one for responseformat at line 291 would allow
one to use the full capacities of citeproc.js.  I think the best route
would probably be to submit a patch to citeproc.js adding an org-mode
output format, propagating that up to citeproc-node, submitting a second
patch to citeproc-node, and then writing the org-internal functions
properly.  We might also want to add an additional responseformat option.

It might take a month or two to get all those changes accepted, but we
could probably do the org-mode development simultaneously, and it would be
worth the wait to have a stable solution.  My experience with the
citeproc-js maintainer is that he is very helpful and responsive to feature
requests.

I am a slow coder but would be happy to invest some time in this if it's
the direction the community wants to go in.  Adding a new output format to
citeproc-js is not that complex; see
https://bitbucket.org/fbennett/citeproc-js/src/tip/src/formats.js?fileviewer=file-view-default


> Though published by the Zotero programmers, citeproc-node, I believe, is
> distinct from the citeproc-js implementation in Zotero, which is a XUL
> application.
>
> I think that's right.  If we could avoid dependencies on Zotero that would
be good; it is a pretty substantial program, takes up a significant amount
of RAM at runtime, and relies on a GUI environment, which neither emacs nor
pandoc does.


> Matt
>

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Jan Malakhovski]

Matt Lundin  writes:

> Jan Malakhovski  writes:
>
>> I'm pretty sure that there are other org-mode users that are weeping
>> silently since that change. Suppose you have more than a screen of clock
>> lines in LOGBOOK under a heading (I have headings that have thousands).
>> (org-agenda-goto) before 9f5e698679aecbed872a2030e4157e5e2b1d87e0 is
>> very helpful when moving CLOCK lines between headings (think "refile
>> CLOCK line") or editing overlaps or gaps: you  or click on the
>> heading and here you are at the CLOCK, but after
>> 9f5e698679aecbed872a2030e4157e5e2b1d87e0 you have to *retype* the date
>> and time into search, which is annoying to say the least.
>
> Try typing RET in the agenda. That calls org-agenda-switch-to, which
> brings you to the relevant clock information in the agenda.(However, if
> the information is tucked away in a LOGBOOK, it remains somewhat
> inconveniently hidden from view).

Judging by the names and default key bindings alone I'd prefer
org-agenda-switch-to to do the new org-agenda-goto thing, and
org-agenda-goto have the previous behavior. This kinda makes more sense
to me, see below.

In any case, current org-agenda-switch-to behavior is no replacement for
old org-agenda-goto:

1) I'm not aware of a key sequence to do org-reveal for drawers (in
org-agenda-goto it's a nontrivial piece of code).
2) Even if there is such a sequence, the drawer should be open by default.

>> I'm willing to listen, but I seriously doubt there's such a compelling
>> argument defending the change. Even when out of `org-agenda-list` in
>> plain `org-agenda`, jumping to SCHEDULED or DEADLINE lines is nicer than
>> to the heading itself.
>
> I disagree that jumping to the SCHEDULED or DEADLINE lines from a normal
> agenda is always nicer than jumping to the headline. I can easily change
> planning info from within the agenda. But I cannot change the text of
> the headline itself -- that is usually why I jump from the agenda. If
> nothing else, we should have both options, which we seem to currently
> have with the difference between TAB (org-agenda-goto) and RET
> (org-agenda-switch-to). However, I am not sure how intentional this is,
> as I can find nothing highlighting this difference in the documentation.

Okay, that is a pretty valid use case, but even then, (below starts
here) org file syntax requires SCHEDULED and DEADLINE to be just under
the heading, which means that you can navigate to the heading pretty
easily, where as with CLOCK lines you can not. Which is why, I think,
both org-agenda-goto and org-agenda-goto-mouse should have the old
behavior, but, in principle, I can imagine  and  doing
different things in plain org-agenda and org-agenda-list.

So, to sum up, I see three possible solutions:

1) org-agenda-goto and org-agenda-goto-mouse jump to a line with the
   timestamp (old org-agenda-goto behavior), org-agenda-switch-to jumps
   to the heading (current org-agenda-goto behavior).
   (I vote for this).

2) org-agenda-switch-to gets the org-agenda-goto behavior.
   (I can live with it, but I think it is less pretty.)

3) org-agenda-goto and *-mouse (or just their key bindings) do
   different things in plain agenda and in agenda-list.
   (Seems complicated.)

Cheers,
  Jan

Re: [O] Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)

[Matt Lundin]

"Stefan-W. Hahn"  writes:
>
> For example of a link:
>
>[[link][description]]x
>
> If cursor was at position x the old behaviour of org-return (hitting )
> was to open a new line, and position the cursor at the beginning of the new
> line. The old behaviour of org-open-at-point was to say "no link".
>
> For me this seems consistent because if you go with the cursor over
> position x you see no hint and mouse-click do nothing. You have to go
> over the link to see face changing and be able to mouse-click top follow
> the link.

> Additonally description of org-open-at-point say "... When point is on a
> link, follow it", not "on or after".
>
> Also if you insert a link by yanking or org-insert-link cursor is positioned
> directly after inserted link, cursor pos x s.o. With old behaviour you can
> behaviour you can straight hit  to get a newline. With new behaviour
> you have to add space before  or call open-line and position the
> cursor.

I can confirm this bug. It affected me when I was trying to enter
scheduling information:

E.g., if I insert the following with org-time-stamp...

<2015-10-28 Wed>
^

...the cursor is located after the time stamp (as shown). But if I hit
return to create a new line and enter a new data (text, a time stamp,
etc.), I am taken unexpectedly to the agenda.

Best,
Matt

Re: [O] Can't email multipart/alternative anymore

[Peter Davis]

On 10/24/15 10:28 AM, Nicolas Goaziou wrote:

Peter Davis  writes:


Possibly. I'm not sure how to determine that. FWIW, org-version tells
me 8.2.5g.

I suggest to update Org and try again.


I will report back when I get a chance to do the upgrade.

Thanks,
-pd

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

cesar mena  writes:

> however the face is now `org-scheduled-today, as opposed to
> `org-scheduled-previously, and the agenda sorting is wrong. instead of
> bubbling to the top (since it is so late) it is staying within the
> "scheduled today" range.

I committed another attempt in master. Thank you.

Regards,

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Matt Lundin]

Jan Malakhovski  writes:

> I'm pretty sure that there are other org-mode users that are weeping
> silently since that change. Suppose you have more than a screen of clock
> lines in LOGBOOK under a heading (I have headings that have thousands).
> (org-agenda-goto) before 9f5e698679aecbed872a2030e4157e5e2b1d87e0 is
> very helpful when moving CLOCK lines between headings (think "refile
> CLOCK line") or editing overlaps or gaps: you  or click on the
> heading and here you are at the CLOCK, but after
> 9f5e698679aecbed872a2030e4157e5e2b1d87e0 you have to *retype* the date
> and time into search, which is annoying to say the least.

Try typing RET in the agenda. That calls org-agenda-switch-to, which
brings you to the relevant clock information in the agenda. (However, if
the information is tucked away in a LOGBOOK, it remains somewhat
inconveniently hidden from view).

> I'm willing to listen, but I seriously doubt there's such a compelling
> argument defending the change. Even when out of `org-agenda-list` in
> plain `org-agenda`, jumping to SCHEDULED or DEADLINE lines is nicer than
> to the heading itself.

I disagree that jumping to the SCHEDULED or DEADLINE lines from a normal
agenda is always nicer than jumping to the headline. I can easily change
planning info from within the agenda. But I cannot change the text of
the headline itself -- that is usually why I jump from the agenda. If
nothing else, we should have both options, which we seem to currently
have with the difference between TAB (org-agenda-goto) and RET
(org-agenda-switch-to). However, I am not sure how intentional this is,
as I can find nothing highlighting this difference in the documentation.

Best,
Matt

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Nicolas Goaziou]

Jan Malakhovski  writes:

> Okay, so I bisected and found that the offender is
> 9f5e698679aecbed872a2030e4157e5e2b1d87e0. Since then these lines have
> changed, so the following

[...]

> I'm willing to listen, but I seriously doubt there's such a compelling
> argument defending the change. Even when out of `org-agenda-list` in
> plain `org-agenda`, jumping to SCHEDULED or DEADLINE lines is nicer than
> to the heading itself.

I don't know either why that was changed, but there probably was
a reason for it. Bastien may remember it.

Regards,

Re: [O] Regression in Org triggered from helm

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> Fixed with 1c74002.  Thanks for reporting the issue.

Thank you for the patch, and the tests.


Regards,

-- 
Nicolas Goaziou

Re: [O] pdflatex not found?

[Alan Schmitt]

On 2015-10-27 17:06, "Cook, Malcolm"  writes:

>> 
>  > John Kitchin  writes:
>  > 
>  > > This reminds me that I think I have this problem unless I open Emacs 
> from a
>  > > command line.
>  > 
>  > Yup - this is one way of circumvent the problem: by starting emacs from
>  > the command line.
>
> And, just to chime in late in the conversation, if your emacs was installed as
> an mac application using, say, http://emacsformacosx.com/ then you can start
> it from the command line as:
>
>   open -a /Applications/path/to/emacs
>
> and get the environment variables you expect...

An alternative, that seems to be cross platform, is to populate
variables when emacs start. This is what I do here:

#+begin_src emacs-lisp
;;  fetch env variables from zshrc
(let ((vars (split-string-and-unquote (shell-command-to-string ". ~/.zshrc; 
export") "\n")))
  (mapcar (lambda (X) (let ((var_val (split-string-and-unquote X "=")))
(setenv (car var_val) (cadr var_val vars)
  (setq exec-path 
(append
 (split-string-and-unquote (getenv "PATH") ":")
 exec-path)))
#+end_src

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated October 26, 2015, Mauna Loa Obs.): 398.51 ppm


signature.asc
Description: PGP signature

Re: [O] Links in comments

[Eric S Fraga]

On Wednesday, 28 Oct 2015 at 07:07, Kaushal Modi wrote:
> Hi John, Eric,
>
> Thanks for the replies.
>
> I will try out the highlight-regexp trick today.
>
> The point I was trying to make was not that we should highlight links even
> in comments (though that was my suggested alternative). The main point I
> wanted to make was that links should not get hidden in comments.

Ah, sorry, I misunderstood.  I agree with you, again from a semantic
point of view of what a comment (to me) means.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Links in comments

[Kaushal Modi]

Hi John, Eric,

Thanks for the replies.

I will try out the highlight-regexp trick today.

The point I was trying to make was not that we should highlight links even
in comments (though that was my suggested alternative). The main point I
wanted to make was that links should not get hidden in comments.

If highlighting links in comments is not suggested, then at least we should
make them visible as,

# some [[link][desc]]

Instead of

# some desc

The use case is where I would have some org-mode text with links
temporarily commented out. But in the commented state, I would not know if
that text hid any links because the links don't show expanded in the
commented text. And also they don't have a different face.

I will update later on what I see on using highlight-regexp. I think that
will work for me too.

Re: [O] Links in comments

[John Kitchin]

Your mileage may vary, but this seems to show links in comments for me:

#+BEGIN_EXAMPLE
(highlight-regexp org-any-link-re 'org-link)
#+END_EXAMPLE


Eric S Fraga writes:

> On Monday, 26 Oct 2015 at 14:13, Kaushal Modi wrote:
>> Hi all,
>>
>> I am sending this out again in the event someone knowing a solution to it
>> can comment.
>
> I don't know a solution.  If I do C-u C-x = with the cursor on the link
> in a comment line, there is only one face shown.  Semantically, the line
> is a comment and the whole point of comments is that they are not parsed
> for any further meaning.  Representing the line, therefore, using the
> comment face throughout makes sense.
>
> Whether it's what *you* want or not is another issue, of course ;-)
>
> I suggest changing your usage?  If you want links to be visible, they
> should be in the main text?  Even within a COMMENT section say?

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Jan Malakhovski]

Jan Malakhovski  writes:

> Nicolas Goaziou  writes:
>
>> Could you provide an ECM with appropriate CLOCK lines?
>
> Attached.

Okay, so I bisected and found that the offender is
9f5e698679aecbed872a2030e4157e5e2b1d87e0. Since then these lines have
changed, so the following

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index bdb69c5..38baac2 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8411,10 +8411,10 @@ When called with a prefix argument, include all archive 
files as well."
 (org-flag-heading nil)))   ; show the next heading
   (when (outline-invisible-p)
(outline-show-entry))   ; display invisible text
-  (recenter (/ (window-height) 2))
-  (org-back-to-heading t)
-  (if (re-search-forward org-complex-heading-regexp nil t)
- (goto-char (match-beginning 4
+  (recenter (/ (window-height) 2)))
+;  (org-back-to-heading t)
+;  (if (re-search-forward org-complex-heading-regexp nil t)
+;(goto-char (match-beginning 4
 (run-hooks 'org-agenda-after-show-hook)
 (and highlight (org-highlight (point-at-bol) (point-at-eol)

makes all of my problems this go away.

If you read 9f5e698679aecbed872a2030e4157e5e2b1d87e0 you'll notice that
it changed both the behavior and the doc-string (that is to say that you
can't refer to doc-string as an argument against the previous behavior).

I'm pretty sure that there are other org-mode users that are weeping
silently since that change. Suppose you have more than a screen of clock
lines in LOGBOOK under a heading (I have headings that have thousands).
(org-agenda-goto) before 9f5e698679aecbed872a2030e4157e5e2b1d87e0 is
very helpful when moving CLOCK lines between headings (think "refile
CLOCK line") or editing overlaps or gaps: you  or click on the
heading and here you are at the CLOCK, but after
9f5e698679aecbed872a2030e4157e5e2b1d87e0 you have to *retype* the date
and time into search, which is annoying to say the least.

I'm willing to listen, but I seriously doubt there's such a compelling
argument defending the change. Even when out of `org-agenda-list` in
plain `org-agenda`, jumping to SCHEDULED or DEADLINE lines is nicer than
to the heading itself.

Cheers,
  Jan

Re: [O] Some projects

[Rasmus]

Rasmus  writes:

> Matt Lundin  writes:
>
>> Perhaps someone with more experience of pandoc could assess how well it
>> toggles between CSL and biblatex, especially for more complicated styles
>> (e.g., Chicago). 
>
> Can you point out an example of the expected format?  Bibtex.el does
> pretty well and perhaps it’s trivial to transform an arbitrary bibtex key
> into the json format on the Emacs side.

Looking at,

https://github.com/citation-style-language/schema/blob/master/csl-data.json

the main difficulty seems to be the author field, which is more "complex",
or perhaps just more sane, in the JSON equivalent.  It may be possible to
use bibtex-autokey-demangle-name to approximate a translation from bibtex
to JSON.

There are clearly other complex fields like "accessed", but I guess it
would rarely show up in an bib(la)tex entry.  But I have nothing to back
this claim up with.

Rasmus

-- 
When the facts change, I change my mind. What do you do, sir?

Re: [O] Some projects

[Rasmus]

Matt Lundin  writes:

> Perhaps someone with more experience of pandoc could assess how well it
> toggles between CSL and biblatex, especially for more complicated styles
> (e.g., Chicago). 

Can you point out an example of the expected format?  Bibtex.el does
pretty well and perhaps it’s trivial to transform an arbitrary bibtex key
into the json format on the Emacs side.

Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone