Re: [O] [patch, ox] Unnumbered headlines

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Thanks for all time you've put into the comments.  I appreciate it,
> and I will try to revise the patches over the weekend.

Thanks. Again, there's no rush.

> I worry about this approach based on some observations Alan sent
> off-list.  When you export the quoted document with num:nil all labels
> will be of the form "unnumbered-N", loosing all structure in labels.

I don't think how that would be a problem. A label is expected to refer
uniquely to a headline. Reflecting structure of the document is not
a requisite. "sec-NUM" is but a bonus. As far as labels go, we could
also use "headline-X" for all headlines, numbered or not.

> Also, some labels are still unassigned in html for unnumbered
> headlines, e.g. the "text-" (which is a function of parents' section
> numbers) and outline-container-sec-.

Couldn't they be turned into "text-unnumbered-X" and
"outline-container-unnumbered-X" instead?

> Do you think it's better to solve the remaining issues, and accept
> that when num:nil exported documents will be quite altered compared to
> previously, or should I try to introduce a more informative ID for
> numbered an unnumbered headlines alike?

The former.

> If following the latter path, the most obvious approach (to me) would
> be to have a separate :headline-id
> and :headline-numbering.  :headline-id could be collected using
> something like `org-export--collect-headline-numbering', but labels
> would not necessarily reflect the printed section numbers,
> though :headline-numbering would still be "correct".

I think we don't need this added complexity.


Regards,

-- 
Nicolas Goaziou

Re: [O] How to re-bind C-,?

[Teika Kazura]

How about this?
(define-key org-mode-map [(control ?,)] 'your-lambda-expression)

Teika (Teika kazura)

Re: [O] Boxquote for code in UTF-8 export

[Nicolas Goaziou]

Hello,

Sebastien Vauban 
writes:

> * ox-ascii.el (org-ascii--box-string): Choose more universal Unicode
> characters for boxquote corners.

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou

[O] line numbers in a code block?

[John Kitchin]

Does anyone know a way to get dedicate line numbers in an org code
block?

I know how to get buffer code lines, but when we run a code block and
there is an error, the error line number is relative to line 1 of the
code block. Currently, we type C-c ' to get a code buffer, and navigate
to the line. I would like to see code block numbers on the right hand
side of the buffer, and only inside the code block. Any ideas?

Thanks,

-- 
---
John Kitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] How to get the link the point is on?

[Sebastien Vauban]

Marcin Borkowski wrote:
> On 2014-09-25, at 23:50, Thorsten Jolitz wrote:
>> Marcin Borkowski  writes:
>>>
>>> my question is as in subject.  It is done by org-open-at-point
>>> (somehow), but the logic seems to be buried in that function.  What I'd
>>> like to have is a function that would just extract the link portion
>>> (which is normally invisible) and displayed it in the echo area
>>> (something like hovering over a link in a web browser).
>>>
>>> I skimmed through org.el, and either I couldn't find a function which
>>> does it, or this email is a feature request;).
>>
>> you know about 
>>
>> ,[ C-h f org-toggle-link-display RET ]
>> | org-toggle-link-display is an interactive compiled Lisp function in
>> | `org.el'.
>> | 
>> | It is bound to,
>> |.
>> | 
>> | (org-toggle-link-display)
>> | 
>> | Toggle the literal or descriptive display of links.
>> `
>
> Yes, I do, but this is not what I'm looking for.  I want to see the
> `descriptive' links, only to be able (sometimes) to look up the actual
> target of the link.  (And I don't like the idea of moving the point to
> the end, pressing  to delete the rightmost bracket, and then
> pressing C-\ to undo it...)

When I want to see *all* the contents in my Org file (that is LOGBOOK
entries, URL in links, etc.), I use M-x visible-mode.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] How to re-bind C-,?

[Grant Rettke]

That works as expected.

Thank very much Jorge and Teika.

Bit of a mystery why that local-set-key didn't work; and I'm OK with
it remaining so :).

On Sat, Sep 27, 2014 at 7:30 AM, Teika Kazura  wrote:
> How about this?
> (define-key org-mode-map [(control ?,)] 'your-lambda-expression)
>
> Teika (Teika kazura)



-- 
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: [O] Header Arguments of Code Blocks - problems and challenges

[Grant Rettke]

On Fri, Sep 26, 2014 at 3:20 AM, Rainer M Krug  wrote:
> OK - I hope we can geth this going and make a usefull contribution to
> org babel,

Three ideas for ways work on this:
• Purely technically driven
  • Learn the current test framework
  • Identify property permutations
  • Verify tests and documentation
• Purely scenario driven
  • Identify common development scenarios
  • Define the desired results and actual
  • Create vignette's for other users to pull from
• Combination of both
  • Allows for more focus on coding of desired
  • Allows for more focus on using if desired
  • We all are curious about and have invested in both already

[O] How to export to S5 HTML presentation

[Jay Iyer]

Hi,
I would like to use the S5 backend for HTML presentations but I am not able
to figure out how: (1) to set up headlines for incremental slide builds and
(2) to add speaker notes.  I spent a lot of time on the mailing list
archive and other places but couldn’t find clear instructions on what
property values and/or tags are needed on the headlines and their
subheadings.  Are there any additional exporter settings needed in the
buffer?  I am using Org 8.2.5h on Emacs 24.3.1 (Apple build) and the built
in exporter engines.
Thank you in advance to this wonderful community.
-jay

Re: [O] line numbers in a code block?

[Charles Berry]

John Kitchin  andrew.cmu.edu> writes:

> 
> Does anyone know a way to get dedicate line numbers in an org code
> block?
> 
> I know how to get buffer code lines, but when we run a code block and
> there is an error, the error line number is relative to line 1 of the
> code block. Currently, we type C-c ' to get a code buffer, and navigate
> to the line. I would like to see code block numbers on the right hand
> side of the buffer, and only inside the code block. Any ideas?

You mean like

   (org-add-hook 'org-src-mode-hook 'linum-mode)

only with line numbers on the right side? (linum puts them on the left)

Or did you mean in the org-mode buffer itself? 

Maybe (just a guess) hack `linum-update-window' to reset `line' to 0 
whenever `(forward-line))'gives you a line that matches `#+begin_src'.


HTH,

Chuck

Re: [O] Enforcing newlines in plain text export

[Richard Lawrence]

Hi Kaushal, 

Kaushal  writes:

> I am requesting a consistent solution.
>
> If "//" at the end of a line inserts newline when exporting in all formats,
> then it should do the same when used in between a line too for ALL export
> formats.
>
> Example: #+TITLE: Line one // Line two
>
> I am simply trying to explain why we need another solution for the sake of
> consistency across all org exported formats.

Like I said, I agree that something like this would be useful; I
occasionally would like "\\" to have more general behavior, too.
Anyway, it seems worth discussing.

My point is that this would be a new feature, which is technically
*inconsistent* with the currently-documented behavior.  Implementing it
would take some work and would involve breaking backward
compatibility. (At least in theory -- I don't know if anyone out there
relies on "\\" *not* being translated when it does not appear at the end
of a line, but someone might be.)  So it's not something to be taken
lightly.

Does anyone know why the behavior of "\\" is presently restricted to
appearing at the end of the line in a paragraph?  Does anyone need it to
be exported literally when it appears elsewhere?

Best,
Richard

[O] [bug, ox-html] Invalid html output

[Rasmus]

Hi,

Using emacs -q an exporting the following document using ox-html

* h1

The html contains



According to the W3 online validator this is an error.  When I change
it to 

 

I only get a warning.

Should we worry about this?  If we should, perhaps ox-html can fall
back on the file-name as title or space if warnings are OK?

—Rasmus

-- 
This space is left intentionally blank

Re: [O] Bug: Export to html inserts strange unicode characters at line breaks because of fci-mode [8.2.7c (8.2.7c-64-g01f736-elpa @ /home/kmodi/.emacs.d/elpa/org-20140915/)]

[Aaron Ecay]

Hi Nicolas and Kaushal,

2014ko irailak 26an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Kaushal  writes:
> 
>> I have fci-mode installed and enabled for programming modes.
>> 
>> When org exports to html, htmlize figures out the syntax highlighting of
>> the code by calling  =(funcall lang-mode)=.
>> 
>> That activates =fci-mode=.
>> 
>> =fci-mode= shows the fill column using a unicode character. The issue is
>> that org export to html exports that character as well.
>> 
>> Those characters show up in html as below!
>> http://i.imgur.com/8WplTqw.png
>> 
>> So the solution is to fix the =orx-html-fontify-code= function.
> 
> I don't think so. `fill-column-indicator' is not even in core Emacs. We
> shouldn't provide a workaround for every package out there.

For better or for worse, Bastien already installed this fix on master as
commit 44d8, in response to Kaushal’s earlier bug report on this
issue.  See .

The fix has not yet been merged to the release branch, so it won’t yet
show up in the ELPA version of org which Kaushal seems to be using.

-- 
Aaron Ecay

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Aaron Ecay]

Hi Ken,

2014ko irailak 26an, Ken Mankoff-ek idatzi zuen:
> debug-on-error doesn't help because there isn't actually an error as far
> as I can tell. It is a bug, not an error. Nothing shows up in
> *Messages*

How about setting debug-on-quit and hitting C-g when the prompt shows
up?

-- 
Aaron Ecay

Re: [O] line numbers in a code block?

[John Kitchin]

Charles Berry  writes:

> John Kitchin  andrew.cmu.edu> writes:
>
>> 
>> Does anyone know a way to get dedicate line numbers in an org code
>> block?
>> 
>> I know how to get buffer code lines, but when we run a code block and
>> there is an error, the error line number is relative to line 1 of the
>> code block. Currently, we type C-c ' to get a code buffer, and navigate
>> to the line. I would like to see code block numbers on the right hand
>> side of the buffer, and only inside the code block. Any ideas?
>
> You mean like
>
>(org-add-hook 'org-src-mode-hook 'linum-mode)

No, that is not quite what I need. We already have those line numbers on
the left. I wanted a new set of numbers, only in the src-block, and on
the right so they do not get mixed up with the linum-mode numbers. This
is to avoid having to go into the org-src-mode at all.
>
> only with line numbers on the right side? (linum puts them on the left)
>
> Or did you mean in the org-mode buffer itself? 
>
> Maybe (just a guess) hack `linum-update-window' to reset `line' to 0 
> whenever `(forward-line))'gives you a line that matches `#+begin_src'.

I suppose it would involve creating new overlays the way that linum-mode
does. 

>
>
> HTH,
>
> Chuck
>
>
>

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

Re: [O] line numbers in a code block?

[John Kitchin]

I came up with a reasonable solution to this that I think is pretty
nice. It doesn't put linenumbers on the src block, but it does something
even better!

The gist is to write the block to a temporary file, then run pyflakes,
pep8 and pylint on it. The output of those goes into a temporary
org-buffer, with links back to the positions in the code block where the
errors are!

The code is laid out here:
http://kitchingroup.cheme.cmu.edu/blog/2014/09/27/Improved-debugging-of-Python-code-blocks-in-org-mode/

I am going to try it out with my students next week!

j

John Kitchin  writes:

> Does anyone know a way to get dedicate line numbers in an org code
> block?
>
> I know how to get buffer code lines, but when we run a code block and
> there is an error, the error line number is relative to line 1 of the
> code block. Currently, we type C-c ' to get a code buffer, and navigate
> to the line. I would like to see code block numbers on the right hand
> side of the buffer, and only inside the code block. Any ideas?
>
> Thanks,

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

Re: [O] autosave in org-src buffer only works ones

[Nicolas Goaziou]

Hello,

Adriaan Sticker  writes:

> Hi, is it possible that these function cause the buffer automatically
> scrolling when saving?
> When I save My buffer jumps/scrolls up so that my cursor is on the last row
> on my screen.

I do not understand. Are you saying that auto-saving feature in src
blocks moves point?

If so, I cannot reproduce it.


Regards,

-- 
Nicolas Goaziou

Re: [O] Enforcing newlines in plain text export

[Nicolas Goaziou]

Hello,

Richard Lawrence  writes:

> Does anyone know why the behavior of "\\" is presently restricted to
> appearing at the end of the line in a paragraph? 

I certainly can see a good reason for it, although I don't know if it is
the historical one.

Org syntax is primarily intended for Org documents. When in an _Org_
buffer, what would be the meaning of a line break in the middle of
a line?


Regards,

-- 
Nicolas Goaziou

Re: [O] Is it possible to export Org properties as ODT user defined fields?

[Nicolas Goaziou]

Hello,

"Kevin D. Robbins"  writes:

> I would like to export some Org document properties as ODT user defined
> fields for use in ODT templates.  For example, it would be great if
> something like
>
> #+ODT_FIELD: FOO:17 BAR:"Hello, world!"
>
> in the Org document exported the following user defined fields in the
> content.xml.
>
> 
>  text:name="FOO"/>
>  office:string-value="Hello, world!" text:name="BAR"/>
> 
>
> Is this currently possible?

You can generate this using macros (for simple cases) or Babel. In both
cases, you need to generate an export block containing the desired
output:

  #+begin_odt
  
  ...
  
  #+end_odt

See manual for more information.


Regards,

-- 
Nicolas Goaziou

Re: [O] Enforcing newlines in plain text export

[Kaushal]

I needed to have multi line titles exported in all formats consistently and
that's when I need to use '\\' mid-line.

--
Kaushal Modi
On Sep 27, 2014 5:16 PM, "Nicolas Goaziou"  wrote:

> Hello,
>
> Richard Lawrence  writes:
>
> > Does anyone know why the behavior of "\\" is presently restricted to
> > appearing at the end of the line in a paragraph?
>
> I certainly can see a good reason for it, although I don't know if it is
> the historical one.
>
> Org syntax is primarily intended for Org documents. When in an _Org_
> buffer, what would be the meaning of a line break in the middle of
> a line?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Changed behaviours of LaTeX exporter in version 8.0+

[Nicolas Goaziou]

Hello,

"Kyeong Soo (Joseph) Kim"  writes:

> Below I provide ECM for LaTeX cross-referencing you requested, which itself
> summarizes the issues in the current export engine: We see that there are
> mix of results for different cases of heading title (i.e., \texttt{},
> \hyperref[]{}, & \ref{}) and that only referring by custom_id results in a
> correct cross-reference.

See below.

> Note that, as mentioned in the list several time
> before, there is currently no way to customizing hyperref format using
> 'org-export-latex-hyperref-format' varible, which becomes obsolete
> now.

You can use a link filter. Also, `org-export-latex-hyperref-format'
doesn't exist in Org 8.0+.

> - By name (using C-c l & C-c C-l): Sec. [[*Two%20Words][Two Words]]

[...]

> [[*With%20&%20in%20the%20Title][With & in the Title]]

This is the problem. The path isn't expected to be url-encoded. AFAICT,
"C-c l" doesn't encoded headlines. I don't know how yours generates such
a link.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: aborting capture to new file leaves 1-byte file behind [8.2.7c]

[Nicolas Goaziou]

Hello,

Ben Winslow  writes:

> I'm using a capture template to create a new file (via read-file-name)
> with some pre-filled #+STARTUP options.  I'm using immediate-finish,
> but while I was setting it up I noticed that captures to a new file
> will leave behind a 1-byte file (containing a newline) if aborted with
> org-capture-kill.
>
> To replicate, just add a new capture template pointing to
> a non-existent file, start capturing to it, then abort.

Thanks for you report. I can reproduce it, but I hardly consider it as
a bug.

Since your template is meant to populate the file, it is expected to be
created at some point anyway.

Note that it can contain more than a newline if you call, for example,
`time-stamp' from `before-save-hook'.


Regards,

-- 
Nicolas Goaziou

[O] How to extend the HTML exporter for e-learning stuff

[Marcin Borkowski]

Hi list,

some time ago i asked about extending the exporter, but I did not
experiment with it yet.  Now the time has come - I'll need to generate
some HTML + CSS + JS e-learning materials, and I want to do it with
Org-mode.  I think I'll manage the CSS and JS parts, but what gets
tricky is the HTML part: I'd like to minimize hassle.

Assume that I want to have a multiple choice test.  What I want to
obtain is e.g. this:


  
Which text editors are reasonable?
  
  
Emacs
  
  
Vim
  
  
Notepad
  
  
Microsoft Word
  


Now I know that I can obtain all of this using properties like
:HTML_CONTAINER_CLASS: and :CUSTOM_ID:, but this seems very cumbersome.

So, my question is twofold.  First, what would you suggest as the input
(on the Org side)?  In other words, are there any ideas of how to
mark-up the semantics of a mct in Org-mode?  Here's one of my attempts:


* Which text editors are reasonable?:mct:
** Emacs:yes:
** Vim  :yes:
** Notepad   :no:
** Microsoft Word:no:


(based on tags).  (I think tags are better than properties here, since
they are more easily visible in the Org source.)

Here's another one:


* Which text editors are reasonable?
:PROPERTIES:
:test-type: mct
:END:
- [X] Emacs
- [X] Vim
- [ ] Notepad
- [ ] Microsoft Word


Both seem to have one disadvantage: long questions = long headings,
which looks bad.

And yet another, completely different:


* Question on text editors  :mct:
** Question
Which text editors are reasonable?
** Right answer
Emacs
** Right answer
Vim
** Wrong answer
Notepad
** Wrong answer
Microsoft Word


Any other ideas?

Second, how to extend the exporter to get what I want?  (I don't want
anyone to code that for me, just a general reading guideline so that I
can get my hands dirty and ask more specific questions later.)

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] How to utilize the vc package inside of the edit source block buffer?

[Grant Rettke]

Thank you Aaron and Jonathan.

Here is what I did:

(defadvice vc-next-action (before vc-next-action-in-org-src-block last activate)
  "If in org source block, exit it."
  (when (condition-case nil
(org-src-in-org-buffer)
  (error nil))
(org-edit-src-exit)))

I had trouble with the latter and I suspect it is due to my personal
configuration. That would be quite nice indeed to be able to keep the
org source edit buffer open.

On Tue, Sep 23, 2014 at 1:52 PM, Jonathan Leech-Pepin
 wrote:
> Hello,
>
> On 23 September 2014 14:19, Aaron Ecay  wrote:
>>
>> Hi Grant,
>>
>> 2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
>> >
>> > Good afternoon,
>> >
>> > The ability to org-edit-special inside of source block is truly
>> > priceless.
>> >
>> > There is a delightful workflow to be found with approach.
>> >
>> > It has got me spending more and more time in the edit buffer though,
>> > wanting to utilize
>> > vc-next-action to initiate a commit. This is not possible because the
>> > buffer is not associated
>> > with a file.
>> >
>> > Is there some way to get tell Emacs to execute the action on the
>> > source buffer from which the
>> > source edit block buffer originated?
>>
>> One approach might be to advise the vc commands like (pseudocode):
>>
>> (defadvice vc-foo (around org-src activate)
>>   (when (in-src-edit-p)
>> (org-edit-src-exit))
>>   ad-do-it)
>>
>
> The following would work as a wrapper:
>
> (defun test-buffer ()
>   (interactive)
>   (when org-edit-src-from-org-mode
> (let ((buffer (marker-buffer org-edit-src-beg-marker)))
>   (with-current-buffer buffer
> (message "%s is current for file: %s"
>  (current-buffer)
>  (buffer-file-name))
>
> Replace (message ...) with `vc-next-action` or use the above as advice
> [adjusting from (when..) to (if..)].
>
> Regards,
> Jonathan
>
>>
>> --
>> Aaron Ecay
>>
>



-- 
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Ken Mankoff]

> On Sep 27, 2014, at 15:27, Aaron Ecay  wrote:
> 
> Hi Ken,
> 
> 2014ko irailak 26an, Ken Mankoff-ek idatzi zuen:
>> debug-on-error doesn't help because there isn't actually an error as far
>> as I can tell. It is a bug, not an error. Nothing shows up in
>> *Messages*
> 
> How about setting debug-on-quit and hitting C-g when the prompt shows
> up?

Still nothing in *Messages*. I know this is related to fill-paragraph, because 
that triggers this too, even if used below the CAPTION line. CAPTION doesn't 
let fill-paragraph do its thing, which I assume is part of the issue. 

  -k. 

[O] Bug: Buffer restriction lost with org-agenda-sticky enabled

[Thomas Morgan]

Dear Org mode hackers,

I discovered a bug where refreshing a sticky agenda view
can cause a buffer restriction to be lost.

I'm using the maint branch of Org-mode
version 8.2.7c (`release_8.2.7c-85-g4f4002')
and GNU Emacs 24.3.1 (`x86_64-unknown-linux-gnu',
X toolkit, Xaw3d scroll bars).

I started Emacs with the command `emacs -Q -l setup.el'
(file `setup.el' is attached).  Note that `org-agenda-sticky'
is set in `setup.el'.

I then visited the file `foo.org' (attached): `C-x C-f foo.org RET'.

Then I made a list of TODO items in the current file:
`M-x org-agenda RET < t'.  It appeared as expected like this:

,
| Global list of TODO items of type: ALL
| Available with `N r': (0)[ALL]
|   foo:TODO Foo 
:foo:
`

Next I made a list of headlines (in all files) matching the tag `bar':
`M-x org-agenda RET m bar RET'.  It appeared as expected like this:

,
| Headlines with TAGS match: bar
| Press `C-u r' to search again with new search string
|   bar:TODO Bar 
:bar:
`

Then I quit the second agenda buffer (the tags query) with `q',
which reselected the first agenda buffer without refreshing it.

I then refreshed the TODO list with `g'.  It appeared like this:

,
| Global list of TODO items of type: ALL
| Available with `N r': (0)[ALL] (1)TODO (2)DONE
|   foo:TODO Foo 
:foo:
|   bar:TODO Bar 
:bar:
`

It was evidently no longer restricted to the file `foo.org'.
I expected the restriction would continue to apply.

Best,

Thomas



setup.el
Description: application/emacs-lisp
* TODO Foo  :foo:
* TODO Bar  :bar:

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Aaron Ecay]

Hi Ken,

2014ko irailak 27an, Ken Mankoff-ek idatzi zuen:
>> How about setting debug-on-quit and hitting C-g when the prompt shows
>> up?
> 
> Still nothing in *Messages*. I know this is related to fill-paragraph,
> because that triggers this too, even if used below the CAPTION
> line. CAPTION doesn't let fill-paragraph do its thing, which I assume
> is part of the issue.

Odd; my suggestion should have given you a backtrace after hitting C-g,
but I guess for some reason it didn’t work.

Since you can trigger the undesired behavior with fill-paragraph, what
about using edebug (info "(elisp) Edebug") to instrument that function
and then stepping through to see where the prompt is triggered?

-- 
Aaron Ecay

Re: [O] Enforcing newlines in plain text export

[Alexis]

Richard Lawrence writes:

> Does anyone know why the behavior of "\\" is presently restricted to
> appearing at the end of the line in a paragraph?  Does anyone need it
> to be exported literally when it appears elsewhere?

When exporting code listings in any programming language which uses '\'
for escaping characters in strings, and subsequently uses '\\' to mean
"literal backslash", literal export is required. For example, one might
have an Org document with Emacs Lisp source:

  -
 ' * A
 | ** B
 | #+begin_src emacs-lisp
 |   (setq my-regex "(.+)")
 | #+end_src
 `-


Alexis.

Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group

[Aaron Ecay]

Hi Seb,

2014ko irailak 23an, Sebastien Vauban-ek idatzi zuen:
>> OK, thanks for the followup.  I’m attaching the patch to this email.  If
>> I don’t hear any further feedback, I’ll commit it to master in a few
>> days.
> 
> I'd say: commit it now, so that it really gets to a broad audience.
> 
> Anyway, would there be problems, they would be very, very limited: face
> problems, that's all!

The patch is now pushed to master.

Thanks,

-- 
Aaron Ecay

Re: [O] Call speed-commands with prefix-arg?

[Aaron Ecay]

Hi Thorsten,

2014ko irailak 23an, Aaron Ecay-ek idatzi zuen:
>> 2. when not edebugging, C-u 4 : seems to work in both Org and Outshine
>> 
>> -> "All tags realigned to column 0"
> 
> Good.  :)

I pushed this patch to the master branch.  Thanks for testing it out.

-- 
Aaron Ecay

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Ken Mankoff]

* On 2014-09-27 at 21:02, Aaron Ecay wrote:
> Hi Ken,
>
> 2014ko irailak 27an, Ken Mankoff-ek idatzi zuen:
>>> How about setting debug-on-quit and hitting C-g when the prompt shows
>>> up?
>> 
>> Still nothing in *Messages*. I know this is related to fill-paragraph,
>> because that triggers this too, even if used below the CAPTION
>> line. CAPTION doesn't let fill-paragraph do its thing, which I assume
>> is part of the issue.
>
> Odd; my suggestion should have given you a backtrace after hitting C-g,
> but I guess for some reason it didn’t work.
>
> Since you can trigger the undesired behavior with fill-paragraph, what
> about using edebug (info "(elisp) Edebug") to instrument that function
> and then stepping through to see where the prompt is triggered?

Triggered by the line (funcall function justify)

I find it strange that y'all can't re-create this since I can do it with
emacs -Q, although perhaps it is specific to the emacs-mac port. I'm
happy to keep following instructions and dig deeper, but this is way
outside the scope of my emacs/elisp skills. I'm happy to just invoke new
frames with C-x 5 2 rather than emacsclient to work around this for now.

  -k.

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Aaron Ecay]

Hi Nicolas,

Thanks for the feedback.

2014ko irailak 23an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> Um...but the patch I sent works precisely by defining a macro translator,
>> which does get called for any unexpanded (because undefined) macros.
> 
> Macros are not expected to be seen by export back-ends. It happens when
> a macro is undefined, but this is not a reliable feature.
> 
>> I guess you’re saying the code ought to block this at a lower/earlier
>> level.
> 
> Yes, at "org-macro.el" level.
> 
>> I think error is better than obnoxious message, because it’s possible
>> for the latter to slip through into a “production” document.  (We ought
>> to proofread our documents carefully, of course...but no one’s
>> perfect).
> 
> Sounds good.
> 
>> One issue is that the exporter does two macro expansion passes – one
>> for garden-variety macros, and the second for author, date, email, and
>> title.  So, we can’t make the macro expansion unconditionally barf on
>> undefined macros (since for the first pass e.g. author is undefined).
>> I see three options:
>> 1. explicitly whitelist the few “blessed” macros like author, and error
>> on any other undefined macro
>> 2. add an optional “final” arg to org-macro-replace-all, which will
>> activate the undefined checking only if non-nil, and pass this flag
>> in the exporter’s second (and last) call to org-macro-replace-all
>> 3. in ‘org-export-as’, manually walk the parse tree after expanding
>> macros, and make sure no 'macro type objects are left
>> 
>> WDYT?
> 
> I have no strong opinion here but I lean towards option 2 as the error
> stays internal to "org-macro.el" and is only triggered with an optional
> argument. It also doesn't require to hardcode special macro names.

Attached is a revised patch.  WDYT?
>From e386809601d99291885136de1d9be84193b69a2c Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Sat, 27 Sep 2014 23:50:23 -0400
Subject: [PATCH] Warn about unexpanded macros on export

* lisp/org-macro.el (org-macro-replace-all): Add optional `finalize'
argument.
* lisp/ox.el (org-export-as): Use it.
---
 lisp/org-macro.el | 35 ++-
 lisp/ox.el|  3 ++-
 2 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 50ce438..307e232 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -155,10 +155,14 @@ default value.  Return nil if no template was found."
 ;; Return string.
 (format "%s" (or value ""))
 
-(defun org-macro-replace-all (templates)
+(defun org-macro-replace-all (templates &optional finalize)
   "Replace all macros in current buffer by their expansion.
+
 TEMPLATES is an alist of templates used for expansion.  See
-`org-macro-templates' for a buffer-local default value."
+`org-macro-templates' for a buffer-local default value.
+
+If optional arg FINALIZE is non-nil, raise an error if a macro is
+found in the buffer with no definition in TEMPLATES."
   (save-excursion
 (goto-char (point-min))
 (let (record)
@@ -176,17 +180,22 @@ TEMPLATES is an alist of templates used for expansion.  See
 	  (if (member signature record)
 		  (error "Circular macro expansion: %s"
 			 (org-element-property :key object))
-		(when value
-		  (push signature record)
-		  (delete-region
-		   begin
-		   ;; Preserve white spaces after the macro.
-		   (progn (goto-char (org-element-property :end object))
-			  (skip-chars-backward " \t")
-			  (point)))
-		  ;; Leave point before replacement in case of recursive
-		  ;; expansions.
-		  (save-excursion (insert value)))
+		(if value
+		(progn
+		  (push signature record)
+		  (delete-region
+		   begin
+		   ;; Preserve white spaces after the macro.
+		   (progn (goto-char (org-element-property :end object))
+			  (skip-chars-backward " \t")
+			  (point)))
+		  ;; Leave point before replacement in case of recursive
+		  ;; expansions.
+		  (save-excursion (insert value)))
+		  (when finalize
+		(error "Macro %s was undefined at line %s"
+			   (org-element-property :key object)
+			   (line-number-at-pos
 
 
 (provide 'org-macro)
diff --git a/lisp/ox.el b/lisp/ox.el
index 59091fc..216a375 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3136,7 +3136,8 @@ Return code as a string."
 		;; EMAIL is not a parsed keyword: store it as-is.
 		(cons "email" (or (plist-get info :email) ""))
 		(cons "title"
-		  (org-element-interpret-data (plist-get info :title)
+		  (org-element-interpret-data (plist-get info :title
+	  'finalize)
 	 ;; Parse buffer.
 	 (setq tree (org-element-parse-buffer nil visible-only))
 	 ;; Handle left-over uninterpreted elements or objects in
-- 
2.1.1

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Aaron Ecay]

Hi Rasmus,

2014ko irailak 23an, Rasmus-ek idatzi zuen:
> 
> Hi, 
> 
> Aaron Ecay  writes:
> 
>>> You have two options. Either report an error, as you suggested, or
>>> insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", à la
>>> "DEFINITION NOT FOUND." for footnote definitions. In any case, this
>>> should happen in "org-macro.el", not in the export framework.
> 
> This is pretty annoying for footnotes.

This turned out to be very easy to change; attached is a patch.  The
links issue (re-)raised by Jacob in

is a bit harder to deal with, since each backend currently does
something a little different.  It would be possible to make every
backend’s org-X-link function error out at the end, but I’m not sure if
that’s the right thing to do or not.
>From 123d5fcd4f4594c04210ab873395e7def8790450 Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Sat, 27 Sep 2014 23:57:01 -0400
Subject: [PATCH 2/2] [export] Raise an error if footnote definition is not
 found.

* lisp/ox.el (org-export-get-footnote-definition): Raise an error if
footnote definition is not found.
---
 lisp/ox.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 216a375..2516a22 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3711,12 +3711,12 @@ INFO is the plist used as a communication channel."
 (defun org-export-get-footnote-definition (footnote-reference info)
   "Return definition of FOOTNOTE-REFERENCE as parsed data.
 INFO is the plist used as a communication channel.  If no such
-definition can be found, return \"DEFINITION NOT FOUND\"."
+definition can be found, raise an error."
   (let ((label (org-element-property :label footnote-reference)))
 (or (if label
 	(cdr (assoc label (plist-get info :footnote-definition-alist)))
 	  (org-element-contents footnote-reference))
-	"DEFINITION NOT FOUND.")))
+	(error "Definition not found for footnote %s" label
 
 (defun org-export-get-footnote-number (footnote info)
   "Return number associated to a footnote.
-- 
2.1.1

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] ox-latex: support :float no with caption for minted listings

[Aaron Ecay]

Hi Nicolas,

2014ko irailak 23an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> Thanks for all your feedback.  The patch is now applied on master.
> 
> Thank you.
> 
>> I’m confused about how ‘org-latex--wrap-label’ works.  It tries to
>> put \label commands outside of floats.  That will yield links that
>> jump to the preceding section, not the specific point in the document
>> where the \label command occurs.  Probably this command should insert
>> \phantomsection before the \label, so that resultant links jump to
>> the right point.  (I’ll make this change if no one objects.)
> 
> I have no objection.

Done on master.

> 
>> Merging the functions might only be worth doing if there were any more
>> places where \captionof needed to be used.
> 
> That's the intent, yes. It would be a waste not to use a package now
> residing in the default list. Among the transcoders where
> `org-latex--wrap-label' is used, some could probably benefit from
> a non-float caption, if requested by the user.

OK.  I’ll think about this.  One question is what type of caption this
should be.  (i.e. \captionof{what?}{the caption}).  Using the catch-all
figure caption type seems most sensible to me, but feedback from other
latex users is welcome.

Thanks,

-- 
Aaron Ecay

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Ken Mankoff]

* On 2014-09-27 at 23:45, Ken Mankoff wrote:
> I find it strange that y'all can't re-create this since I can do it
> with emacs -Q, although perhaps it is specific to the emacs-mac
> port.

Just checked and it isn't in latest emacs HEAD. I'll submit a bug report
to the emacs-mac project.

  -k.

Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)

[Ken Mankoff]

* On 2014-09-28 at 00:27, Ken Mankoff wrote:
> * On 2014-09-27 at 23:45, Ken Mankoff wrote:
>> I find it strange that y'all can't re-create this since I can do it
>> with emacs -Q, although perhaps it is specific to the emacs-mac port.
>
> Just checked and it isn't in latest emacs HEAD. I'll submit a bug
> report to the emacs-mac project.

For record-keeping purposes, google, Bing, other people, and future
versions of me, this bug has been reported here:
https://github.com/railwaycat/emacs-mac-port/issues/59

  -k.

Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists

[Aaron Ecay]

Hi Nicolas,

2014ko irailak 26an, Nicolas Goaziou-ek idatzi zuen:
> 
>> Why?  Babel’s representation is for babel.
> 
> Which I strongly frown upon.

Let’s back up a step.  The representation I am targeting with my change
is what babel uses to ship a list off as input to code in a babel block.
This code could be emacs lisp, but it could also be R, python, etc.  So
the question is, how to provide a consistent language-agnostic view of
org structure to other languages.  The resultant structure doesn’t hang
around inside babel, it just gets handed off to a code block.

> 
>> org-list-parse-list/-to-generic’s is for radio lists (although as I’ve
>> said this connection seems accidental rather than essential).  Babel
>> calls org-list-parse-list, but I don’t see why it should be forbidden
>> from doing more processing on the result before passing it along
>> (indeed, it already does some processing to remove the list type
>> indicators, remove nested structure, etc.).
> 
> It is best to use as much common ground as possible. We should strive to
> decrease need for such processing, not the other way.
> 
> As I already stated in my first answer, in the long run, it is the only
> sane way to proceed. I agree it is less work to simply tweak Babel right
> now and ignore the whole Org ecosystem, but it does no good to Org as
> a whole.

It’s not work that I’m afraid of: I offered to rewrite both babel and
radio lists in terms of org-elements.  Maybe I am insane, as you imply.

What I’m afraid of is old and disused sort-of-APIs like
org-list-parse-list calcifying and preventing good things from happening
to parts of org that people actually use.

What if I rewrote org-babel-read-list in terms of org-elements?  That
would satisfy me wrt. babel, and wouldn’t necessitate disturbing
org-list-parse-list, radio lists, or indeed anything outside of babel.

> 
> `org-list-parse-list' handles nested lists just fine. Another advantage
> of not re-inventing the wheel in every part of Org.

I know.  But babel’s processing of parse-list’s output strips the nested
structure:

#+name: a-list
- foo
- bar
  - abc
  - def
- baz

#+begin_src emacs-lisp :var lst=a-list
  (pp-to-string lst)
#+end_src

#+RESULTS:
: ("foo" "bar" "baz")

That’s because it’s hard to come up with a good representation of a nested
list in a language-agnostic way.  “List of strings” is a straightforward
datatype in every language babel supports, but not all of them have a
convenient “labeled n-ary tree with string leaves” (which you’d need for
arbitrarily nested lists).

Thanks,

-- 
Aaron Ecay

Re: [O] [ANN] Merge export-block type within special-block

[Aaron Ecay]

Hi Nicolas,

I like the thrust of your initial patch very much; I would like to help
you make it happen.  Here’s some discussion as you requested in a
follow-up message.

2014ko abuztuak 31an, Nicolas Goaziou-ek idatzi zuen:
>
> Unfortunately, no, I cannot fix it.
> 
> The problem is even deeper. Indeed, my approach is fundamentally wrong:
> it is impossible to postpone choosing between parsed or raw data at
> export time. This information must be obtained at parsing time.
> 
> Yet, I think syntax should not depend on the libraries loaded. So the
> initial problem still needs a solution.
> 
> Special blocks and export blocks are just too similar.  We could make
> them slightly different. One solution is to mark explicitly blocks meant
> to insert raw code. E.g.,
> 
>   #+BEGIN_SOMETHING :special t
>   ...
>   #+END_SOMETHING
> 
> vs
> 
>   #+BEGIN_SOMETHING
>   ...
>   #+END_SOMETHING
>

I have a hunch that this is backwards.  It seems like the convention
has been to allow arbitrary special blocks in org files.  Sticking to
what I know best, these create arbitrarily-named environments in Latex.
Export blocks seem like the special case (e.g. the number of types is
constrained by the available export modules), and so they should have
to bear special marking.

What if you used the convention that all export blocks had the form
#+begin_export_latex, #+begin_export_html, etc.?  This should be
unambiguous to parse.  (It’s possible to bikeshed about the name, of
course: perhaps #+begin_literal_latex etc.)

HTH,

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> Attached is a revised patch.  WDYT?

Looks good. Some small comments follow.

> + (if value
> + (progn
> +   (push signature record)
> +   (delete-region
> +begin
> +;; Preserve white spaces after the macro.
> +(progn (goto-char (org-element-property :end object))
> +   (skip-chars-backward " \t")
> +   (point)))
> +   ;; Leave point before replacement in case of recursive
> +   ;; expansions.
> +   (save-excursion (insert value)))
> +   (when finalize
> + (error "Macro %s was undefined at line %s"
> +(org-element-property :key object)
> +(line-number-at-pos

Nitpick: I find the following more readable

  (cond (value (push signature record)
   ...)
(finalize (error ...)))

Also, don't provide error line as macro are replaced after include
keywords are expanded. IOW, in some cases, the line number will be
misleading. The key is sufficient, e.g.,

  (error "Undefined Org macro: %s.  Aborting"
 (org-element-property :key object))

You can commit it once this is fixed. Thank you for the patch.


Regards,

-- 
Nicolas Goaziou