Re: [O] 45048eb78359fc742097982fc1adc5ca5e4b2509 Fix `C-e' with visible lines and arguments

[Clément Pit-Claudel]

On 2017-04-30 16:28, Nicolas Goaziou wrote:
> Have you tried C-S-RET?

I have not :) Thanks a lot!

Re: [O] 45048eb78359fc742097982fc1adc5ca5e4b2509 Fix `C-e' with visible lines and arguments

[Nicolas Goaziou]

Hello,

Clément Pit-Claudel  writes:

> Hi all,
>
> Commit 45048eb78359fc742097982fc1adc5ca5e4b2509 (Fix `C-e' with
> visible lines and arguments,
> http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=45048eb78359fc742097982fc1adc5ca5e4b2509)
> breaks my usual org-mode workflow, in which I commonly press C-e to go
> past the ellipses of a folded headline and press M-S-RET to insert
> a new TODO item. With the change, C-e M-S-RET now moves the body of
> the current todo entry below the new todo header.
>
> It used to be the case that C-e moved past ellipses, which made it
> very easy to insert a new TODO item below the current one. Is there an
> easy way to do the same thing now that C-e leaves the point before
> ellipses? C-u C-u M-S-RET inserts at the end of the current list,
> unfortunately.

Have you tried C-S-RET?

Regards,

-- 
Nicolas Goaziou

[O] 45048eb78359fc742097982fc1adc5ca5e4b2509 Fix `C-e' with visible lines and arguments

[Clément Pit-Claudel]

Hi all,

Commit 45048eb78359fc742097982fc1adc5ca5e4b2509 (Fix `C-e' with visible lines 
and arguments, 
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=45048eb78359fc742097982fc1adc5ca5e4b2509)
 breaks my usual org-mode workflow, in which I commonly press C-e to go past 
the ellipses of a folded headline and press M-S-RET to insert a new TODO item.  
With the change, C-e M-S-RET now moves the body of the current todo entry below 
the new todo header.

It used to be the case that C-e moved past ellipses, which made it very easy to 
insert a new TODO item below the current one.  Is there an easy way to do the 
same thing now that C-e leaves the point before ellipses?  C-u C-u M-S-RET 
inserts at the end of the current list, unfortunately.  

I realize that the change in behavior isn't an accident (the commit updated the 
docstring to say "Go to the end of the line, but before ellipsis, if any."), 
but I'm curious to know whether I was doing something wrong before, and whether 
there is a simple way to achieve the behavior I described now (short of 
flet-ing end-of-line to end-of-visual-line around calls to org-end-of-line).

Thanks!
Clément.

Re: [O] Specifying document-specific settings: line breaks and unusual spacing

[GRAWeeLD]

I tried something like this:

#+FREE_FLOW
U n res train  ed text
#+FREE_FLOW

and while this did admittedly came somewhat closer to what I desire by
exporting the escaped characters and new lines as being a little
smaller than those which were typed normally. This, however, still
wasn't a full free text formatting.


On Tue, Apr 25, 2017 at 6:18 PM, GRAWeeLD  wrote:

> Hello Org-Mode community,
>
> I am rather new to Org-mode itself and have still a lot to read about in
> the official manual, but I cannot seem to find a method for specifying
> document specific behaviour in Org-Mode.
>
> For example, if I want all line breaks to be exported exactly with the
> same indentation as I have for them in my specific document, there seems to
> be no way to do this.
>
> Sure, I can use \\ to create a new line break, and that works great, but
> if I indent my text differently,
>
> for
>   example
>   like
>
>
>  a straircase
>
> this indentation will not be preserved as such upon PDF export.
>
> Now, I found that AsciiDoc solved this somewhat by allowing the user to
> insert
>
> [/hardbreaks]
>
>format   your   text o d d l y
>
>
> [hardbreaks/]
>
> at the beginning of a particular section within a document, and if this is 
> inserted, then everything would be rendered as it is seen on screen upon 
> export as well.
>
> Granted, I am not suggesting that this preservation should be Org-Mode's 
> default behaviour, not at all. I want only certain portions of my book to be 
> formatted in this odd way, the rest should be perfectly precisely aligned, as 
> is the case at this very time.
>
>
> Thank you for your time and considerations towards this proposal.
>
>

[O] displaying icons in heading or subheadings

[Cédric ODY]

Hi,

I'd like to be able to display icons just after the stars in heading or 
subheadings, by defining the icon as a property. For instance



* Emacs heading
  :PROPERTIES:
  :ICON:  /tmp/emacs.png
  :END:

I have tried something like

#+BEGIN_SRC elisp :results value raw
(let ((parsetree (org-element-parse-buffer 'headline)))
  (org-element-map parsetree 'headline
(lambda (hl) (org-back-to-heading t) (insert-image (create-image 
(org-element-property :ICON hl))

#+END_SRC

which inserts the icon before the star.

Any hint to do it? Is this smart enough?

Thanks,

co


--
--

02 98 49 86 04

[O] [PATCH] Resolving %bibtex vs %bib inconsistency

[Mohammad Alaggan]

Hi,

I believe there’s a bug in org-mode 9.0.5 in LaTeX export, when substituting 
the template parameters in org-latex-pdf-process. 

To reproduce

1. Create conf.el file containing:

 (add-to-list 'load-path "/path/to/org-plus-contrib-20170210")
 (require 'ox-latex)
 (setq org-latex-pdf-process '("%bib %b"))

2. Launch emacs:
 emacs -Q -l conf.el

2. Create an empty org-mode file "test.org"
3. Export it to a PDF : C-c C-e l p

Expected Result
===
bibtex is invoked and producing an error message complaining about nonexisting 
.aux file, producing the following message in *Org PDF LaTeX Output* buffer:

 I couldn’t open file name `test.aux’

Actual Result
=
An error will show in *Org PDF LaTeX Output* buffer:

 /bin/bash: testib: command not found 

Discussion
==

What happened is that the template "%bib" was not replaced by "bibtex" (the 
default value of "org-latex-bib-compiler"), but instead, the "%b" part was 
replaces by the file basename "test".

The problem is an inconsistency between, on one hand the documentation string 
of org-latex-bib-compiler and the built-in value list of org-latex-pdf-process, 
who believe the bibtex compiler’s template is "%bib", and the function 
org-latex-compile, which believes (both in comments and in code) that the 
template should be "%bibtex" instead. All of them are in lisp/ox-latex.el.

For users it can be easily fixed by using %bibtex instead of %bib, so it is not 
critical. It is also easy to fix in the codebase as well, but I am not sure 
which way to go: set it to %bib everywhere, or to %bibtex. I settled with 
setting it to %bib and removing %bibtex from org-latex-compile since this is 
most likely to not break existing configurations of users. The corresponding 
patch is attached at the end of the message. It is my first patch, so please 
forgive me if there is something wrong with the formatting, the commit message, 
or with this message; I would appreciate any pieces of advice as well.

Thank you, 

Replace %bib instead of %bibtex, in org-latex-pdf-process.
* lisp/ox-latex.el (org-latex-compile): Changed regex accordingly.
---
 lisp/ox-latex.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6fe05e0..262bcb2 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3663,12 +3663,12 @@ produced."
 (match-string 0)))
  "pdflatex"))
 (process (if (functionp org-latex-pdf-process) org-latex-pdf-process
-   ;; Replace "%latex" and "%bibtex" with,
+   ;; Replace "%latex" and "%bib" with,
;; respectively, "%L" and "%B" so as to adhere to
;; `format-spec' specifications.
(mapcar (lambda (command)
  (replace-regexp-in-string
-  "%\\(?:bib\\|la\\)tex\\>"
+  "%\\(?:bib\\|latex\\)\\>"
   (lambda (m) (upcase (substring m 0 2)))
   command))
org-latex-pdf-process)))
-- 
2.6.4 (Apple Git-63)

[O] Specifying document-specific settings: line breaks and unusual spacing

[GRAWeeLD]

Hello Org-Mode community,

I am rather new to Org-mode itself and have still a lot to read about in
the official manual, but I cannot seem to find a method for specifying
document specific behaviour in Org-Mode.

For example, if I want all line breaks to be exported exactly with the same
indentation as I have for them in my specific document, there seems to be
no way to do this.

Sure, I can use \\ to create a new line break, and that works great, but if
I indent my text differently,

for
  example
  like


 a straircase

this indentation will not be preserved as such upon PDF export.

Now, I found that AsciiDoc solved this somewhat by allowing the user to
insert

[/hardbreaks]

   format   your   text o d d l y


[hardbreaks/]

at the beginning of a particular section within a document, and if
this is inserted, then everything would be rendered as it is seen on
screen upon export as well.

Granted, I am not suggesting that this preservation should be
Org-Mode's default behaviour, not at all. I want only certain portions
of my book to be formatted in this odd way, the rest should be
perfectly precisely aligned, as is the case at this very time.


Thank you for your time and considerations towards this proposal.

[O] [R]Somehow orgmode doesn't export code to pdf in MINTED environment!

[vendo.li...@libero.it]

Hello again, I've opened my .emacs file and "refreshed" it by clicking on the 
menu Emacs-Lisp > Evaluate Buffer. After doing this, somehow EMACS now knows it 
must put code within MINTED environment in the .tex file and not use LISTINGS 
instead.
I guess Nick was right -- my EMACS doesn't see its init file every time I 
launch it by double clicking the icon!
Now that's matter for another thread...

[O] Somehow orgmode doesn't export code to pdf in MINTED environment!

[vendo.li...@libero.it]

Hello, 
I've already posted a few days ago on my MINTED problem. On someone's 
suggestion on this mailing list, I cleared up my init file and only left the 
following settings:

-

 (server-start)
; (add-hook 'LaTeX-mode-hook 'turn-on-reftex)
 (setq reftex-plug-into-AUCTeX t)

;;; a key for tilde symbol
(define-key key-translation-map (kbd "M-2") (kbd "~"))
;;; a key for backquote symbol
(define-key key-translation-map (kbd "M-6") "")
(define-key key-translation-map (kbd "M-9") (kbd "`"))
;;this one's only for CDLaTeX math insertion
(define-key key-translation-map (kbd "C-1") (kbd "`"))

;; visual line word wrapping
(global-visual-line-mode t)

;;automatically recognize org files
(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))

;; MINIMAL init FILE 

(add-to-list 'load-path "~/src/emacs/org/org-mode/lisp")

(require 'org-loaddefs)
(require 'org)

(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))

(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-ca" 'org-agenda)

;;; 

(setq org-latex-listings 'minted
  org-latex-packages-alist '(("" "minted"))
  org-latex-pdf-process
  '("pdflatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode -output-directory %o %
f"))

(setq org-latex-minted-options
   '(("fontsize" "\\footnotesize")("bgcolor" "white")("obeytabs" "true")))

;; -shell-escape for minted pkg (COMMENT WHEN NOT IN USE)
(add-hook 'TeX-mode-hook
  (lambda ()
(setq TeX-command-extra-options "-shell-escape")
  )
 )
;;;

-


The above is my ENTIRE .emacs file. There's nothing else on it beyond those 
lines.
After this tweak, all was working fine but today the problem has come up 
again. I DON'T KNOW WHY! Essentially, when going from .org to .tex, it exports 
the contents of #+BEGIN_SRC inside LISTINGS environment, not MINTED, in spite 
of being told to do so! 

This is the minted.org file that I'm trying to export to pdf via .tex (C-c C-e 
l o). I'm on a 32-bit Windows 7, emacs 24, org-mode 8.2, TeXlive 2015 with 
MINTED package and pygmentize correctly installed. Sumatra as pdf viewer.

--

#+TITLE: My Minted Experiment
#+AUTHOR: me
#+DATE: 
#+STARTUP: nolatexpreview
#+OPTIONS: toc:nil
#+LATEX_CLASS: article
#+LATEX_CLASS_OPTIONS: [a4paper,10pt]
#+ATTR_LATEX: :mode table :booktabs
#+LATEX_HEADER: \usepackage{esdiff}
#+LATEX_HEADER: \usepackage[version=4]{mhchem}
#+LATEX_HEADER: \usepackage{amssymb}
#+LATEX_HEADER: \usepackage{siunitx}
#+LATEX_HEADER: \usepackage{booktabs}
#+LATEX_HEADER: \setcounter{secnumdepth}{0}
#+LATEX_HEADER: \usepackage[margin=1in]{geometry}
#+LATEX_HEADER: \frenchspacing \allowdisplaybreaks
#+LATEX_HEADER: \usepackage{fancyhdr}
#+LATEX_HEADER: \pagestyle{fancy} % choose page-style
#+LATEX_HEADER: \fancyhf{}  % erase and clean up
#+LATEX_HEADER: \fancyhf[HLE,HRO]{\thepage} % H or F=Header or Footer, 
LCR=Left, Centre, Right
#+LATEX_HEADER: \fancyhf[HC]{My minted experiment}

* SECTION
#+BEGIN_SRC python
 print "there's some code here";
 a= True;
#+END_SRC

--
Sorry to bother you with the same problem!

[O] org-export-preprocess-apply-macros ?

[D Bro]

Is this still a thing?  I can’t seem to find it anywhere but a very few online 
references, no where in the org code, and it doesn’t seem work…
https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00857.html

   (add-hook 'org-babel-tangle-body-hook (lambda () 
(org-export-preprocess-apply-macros)))

I only found 'org-macro-replace-all’, which I’m not sure how to apply while in 
the tangle context.

Many thanks,
Ed B.

Re: [O] More clocktable breakage

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> That's what I've been asking the whole time: when you changed that
> predicate, you've basically cut off some of its consumers.  It looks
> like bad factoring to me to then splitting the same predicate based on
> some argument.  I'd rather pull out the old sloppy matching into a new
> predicate for instance.

There are drawbacks in both choices. More on this below.

> I don't use planning, so no.  But it seems to me that the only way for
> org-element-context to deliver a 'timestamp is when pos is on a planning
> line (that may be wrong, I just don't see where else a 'timestamp would
> be returned).  In that case we've already left the cond, so testing for it
> doesn't do anything useful.  I'm also not really sure why the existing
> exceptions from the "true" timestamp (planning, property and clock-log)
> are any different than "dynamic block" would be (with the appropriate
> change of the doc string of course).y

I start to see where the confusion comes from. 

Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
there are three categories of "timestamps".

Let's consider the following examples:

  (1)
  SCHEDULED: <2017-04-30 dim.>

  (2)
  CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] =>  0:01

  (3)
  : <2017-04-30 dim.>

  (4)
  :PROPERTIES:
  :DATE: <2017-04-30 dim.>
  :END:

  (5)
  # <2017-04-30 dim.>

  (6)
  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"

The first category is the "strict" one, which follows Org syntax
definition. None of the examples above belong to that category.
`org-element-context' should be the relative predicate, which means that
it probably shouldn't return a timestamp object on planning lines, as it
does at the moment.

The second category, which is a super-set of the previous one, is
"agenda" one. Historically, Org allowed to insert timestamps in property
drawers, e.g., as in (4), and use them in the agenda. So basically, this
category contains "every timestamp that would appear as a plain
timestamp in the agenda if it were active". `org-at-timestamp-p' is
currently the relative predicate for that category. Note that the
category also contains (2) if inactive timestamps are meant to be
displayed in the agenda.

The last category, a super-set of the "agenda" one, is the "convenience"
category. Basically, it contains every occurrence of what looks like
a timestamp, but isn't necessarily one. Obviously, every example given
above fits in there, as in every case, you can ignore that Org has
a context-dependant grammar and pretend you are on a timestamp. There is
no predicate relative to that category, but `org-at-timestamp-p'
docstring suggests to use (org-in-regexp org-ts-regexp).

So, about the predicates, I guess we could move the second one into
"org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However,
using `org-at-timestamp-p' for the last category seems a bit
far-stretched to me, since it doesn't always match timestamps. In
particular, (3) and (5) sound counter-intuitive to me and I wouldn't
like it from a developer standpoint. `org-at-timestamp' is also not
really needed for the first category, since there is already
`org-element-context'.

Yet, `org-at-timestamp-p' is something users are going to look after.
Different names may also introduce confusion (remember `org-at-regexp-p'
and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
a single predicate, or even two if we set "agenda" apart, with
a docstring explaining the different categories and how to select them
may also be a good natural choice. Hence my suggestion.

WDYT? Do you have any other concrete proposal?

Regards,

-- 
Nicolas Goaziou