Re: [O] computing the size of a tikz to png image during export

[Eric S Fraga]

On Wednesday, 24 Jan 2018 at 08:54, Alan Schmitt wrote:
> If I understand how it works in the png case, a standalone latex file is
> first generated, then it is compiled to pdf and converted to png using
> imagemagick. Instead of specifying the geometry of the image (width of
> 800 pixels above), I would like to compute it using its original size.
> Is it possible?

Have you tried removing the -geometry setting?  Imagemagick should be
fine with just the density option.
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-39-gc82c21


signature.asc
Description: PGP signature

Re: [O] properties using other properties

[Ihor Radchenko]

I recommend looking into org-edna
(http://www.nongnu.org/org-edna-el/#conditional_forms).
You can try to use "has-property" in combination with "set-property" as
a TRIGGER.

Alternatively, you can customize org-property-changed-functions (see
https://www.reddit.com/r/emacs/comments/7gr9ps/add_logbook_entry_and_note_on_orgmode_property/)
and reimplement org-edna functionality for your purposes.

Regards,
Ihor

cpb  writes:

> Is there a way to set properties using other properties?  Doesn't matter
> if its on export only, though it would be nice to have it in-situ.
>
> here's an example (obviously doesn't work), where a project properties
> for the project client only needs the CLIENT property filled, the rest
> of it automatically populates on export.  Would save having to duplicate
> the data where there are a lot of projects.
>
>
> * client1
> :PROPERTIES:
> :CUSTOM_ID:client1
> :NAME: a client
> :ADDRESS:  an address
> :EMAIL:an email
> :URL:  a website
> :END:
>
> * project1
> :PROPERTIES:
> :CUSTOM_ID:project1
> :NAME: a project
> :CLIENT:   client1
> :CLIENT_NAME:  {{{property(NAME,#{{{property(CLIENT)}}})}}}
> :CLIENT_ADDRESS:   {{{property(ADDRESS,#{{{property(CLIENT)}}})}}}
> :CLIENT_EMAIL: {{{property(EMAIL,#{{{property(CLIENT)}}})}}}
> :EXPORT_FILE_NAME: ./a_project
> :END:
>
> project: {{{property(NAME)}}}
> for: {{{property(CLIENT)}}}
>  {{{property(CLIENT_ADDRESS)}}}
>  {{{property(CLIENT_EMAIL)}}}
>

-- 
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977


signature.asc
Description: PGP signature

[O] computing the size of a tikz to png image during export

[Alan Schmitt]

Hello,

I use this great trick to have both a pdf and html export of tikz
images:

#+header: :file (by-backend (latex "tp6-tree.tikz") (t "tp6-tree.png"))
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 800
#+header: :results file raw
#+header: :fit yes
#+header: :headers '("\\usepackage{tikz}")
#+begin_src latex
\begin{tikzpicture}
…
\end{tikzpicture}
#+end_src

If I understand how it works in the png case, a standalone latex file is
first generated, then it is compiled to pdf and converted to png using
imagemagick. Instead of specifying the geometry of the image (width of
800 pixels above), I would like to compute it using its original size.
Is it possible?

Thanks a lot,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-12: 406.82, 2016-12: 404.42


signature.asc
Description: PGP signature

Re: [O] iCal export & skipping entries

[Ken Mankoff]

Hi,

Following up on this, I've been looking in the source code. It seems that both 
:noexport: tags and ~org-icalendar-exclude-tags~ should be excluded from export 
according to ox-icalendar.el: 
https://github.com/emacsmirror/org/blob/master/lisp/ox-icalendar.el#L77
And more on line 258

However, with "emacs -Q" and then evaluating these settings:

(setq org-icalendar-include-todo "all")
(setq org-icalendar-use-deadline '(event-if-todo event-if-not-todo todo-due))
(setq org-icalendar-use-scheduled '(event-if-todo event-if-not-todo todo-start))
(org-icalendar-combine-agenda-files)
(setq org-icalendar-exclude-tags "noicalexport")

And then this simple Org file:

* Foo   :noexport:noicalexport:
  SCHEDULED: <2018-01-24 Wed>

And then exporting with C-e c f it creates an ics file with

CATEGORIES:noicalexport,noexport,???

instead of skipping the entry.

   -k.

On 2018-01-24 at 07:31, Ken Mankoff  wrote:
> I've set up iCal export to export everything:
>
> (setq org-icalendar-include-todo "all")
> (setq org-icalendar-use-deadline '(event-if-todo event-if-not-todo todo-due))
> (setq org-icalendar-use-scheduled '(event-if-todo event-if-not-todo 
> todo-start))
>
> There are some daily repeating habits (and TODOs) that I would like to
> NOT export. Is there a way to tell the exporter to skip habits, or a
> PROPERTY I can set? I've looked into :noexport: tag and the
> EXPORT_OPTIONS property, but cannot find a way to skip something.

Re: [O] Lower-casing blocks and keywords

[Eric S Fraga]

Ignore previous email.  Slightly misread your request.  Not as trivial... ;-)
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-352-g92176c


signature.asc
Description: PGP signature

Re: [O] Lower-casing blocks and keywords

[Eric S Fraga]

On Wednesday, 24 Jan 2018 at 15:21, Kaushal Modi wrote:
> Did you do that lower-casing by hand? Or do you have an elisp snippet or
> some script that does that?

I have no idea how Nicolas did the changes but, remember, org has the
full power of Emacs behind it (it's all text ;-)) so a simple
query-replace-regexp (or without query) using an appropriate regex to
catch all directives will do the job?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-352-g92176c


signature.asc
Description: PGP signature

[O] Lower-casing blocks and keywords

[Kaushal Modi]

Hello Nicolas,

I also like the blocks and keywords to be lower-cased. I see this in the
latest commit on master:
https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0

Did you do that lower-casing by hand? Or do you have an elisp snippet or
some script that does that?

Thanks.
-- 

Kaushal Modi

Re: [O] Fwd: asynch ical export

[Ken Mankoff]

Hi Nicolas,

On 2018-01-24 at 13:31, Nicolas Goaziou  wrote:
> Ken Mankoff  writes:
>> If I evaluate (org-icalendar-combine-agenda-files t) the target ics
>> file is not updated, but it is if I change 't' to 'nil'. When I run
>> that from the command line with, for example:
>
> Have a look at "*Org Export Process*" buffer. It should give you a
> clue about what is wrong.

That buffer didn't give any hints, but when I looked again the ICS file was 
generated. I don't know if this is related to me restarting emacs at some point 
today, or if it was working before and it was human error.

Thanks for the advice.

  -k.

Re: [O] Fwd: asynch ical export

[Nicolas Goaziou]

Hello,

Ken Mankoff  writes:

> When I try asynchronous ical export via (org-icalendar-combine-agenda-files 
> t), it does not appear to work. I'm using org 9.1.6.
>
> If I evaluate (org-icalendar-combine-agenda-files t) the target ics file is 
> not updated, but it is if I change 't' to 'nil'. When I run that from the 
> command line with, for example:

Have a look at "*Org Export Process*" buffer. It should give you a clue
about what is wrong.

Regards,

-- 
Nicolas Goaziou

Re: [O] [feature] prepend comment char before org-babel-ref

[Nicolas Goaziou]

Hello,

"numbch...@gmail.com"  writes:

> I think this function should be in Org-mode itself.
> Because when you're editing the source code, will not want this src-coderef
> like `(ref:example)` be editable. It should be in comment.

Thank you for the suggestion. However I have some doubts about this.

What it the comment syntax is not properly defined? What if the coderef
format already contains comment syntax? What if the language does not
support inline comments and you're in the middle of a line (e.g.,
FORTRAN)?

I'm wondering if this is really a panacea. The current situation, albeit
imperfect, is simple and easy to understand.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

Hello,

Yasushi SHOJI  writes:

> How about using org-lint or some other formatter on git commit hook?
> after go lang introduced gofmt, many projects adapted the method to
> keep the code constant.

Org Lint is not a formatter. It detects common mistakes or hypothetical
mistakes in an Org document, e.g., invalid links. In particular, it
doesn't detect stylistic issues like those discussed above.

It doesn't mean we couldn't run it automatically. However, it also emits
warnings (see `trust' property) on perfectly valid syntax.

As a side note, writing an Org formatter is trivial:

(when (yes-or-no-p "Really format current buffer ? ")
  (let ((document (org-element-interpret-data (org-element-parse-buffer
(erase-buffer)
(insert document)
(goto-char (point-min

Regards,

-- 
Nicolas Goaziou

[O] Fwd: asynch ical export

[Ken Mankoff]

Hi List,

[Apologies if you get this 2x. I got the first one bounced back claiming the 
list address did not exist]

When I try asynchronous ical export via (org-icalendar-combine-agenda-files t), 
it does not appear to work. I'm using org 9.1.6.

If I evaluate (org-icalendar-combine-agenda-files t) the target ics file is not 
updated, but it is if I change 't' to 'nil'. When I run that from the command 
line with, for example:

emacsclient --eval '(org-icalendar-combine-agenda-files t)'

I see the following printed to the terminal:

(lambda
  (p status)
  (let
  ((proc-buffer
(process-buffer p)))
(when
(eq
 (process-status p)
 'exit)
  (unwind-protect
  (if
  (zerop
   (process-exit-status p))
  (unwind-protect
  (let
  ((results
(with-current-buffer proc-buffer
  (goto-char
   (point-max))
  (backward-sexp)
  (read
   (current-buffer)
(funcall
 #[257 "\301\30!\303\"\207"
   [org-icalendar-combined-agenda-file 
org-export-add-to-stack expand-file-name icalendar]
   4 "\n\n(fn _)"]
 results))
(unless org-export-async-debug
  (and
   (get-buffer proc-buffer)
   (kill-buffer proc-buffer
(org-export-add-to-stack proc-buffer nil p)
(ding)
(message "Process `%s' exited abnormally" p))
(unless org-export-async-debug
  (delete-file 
"/var/folders/7y/lbz1bs057398tql00m7fz0hrgn/T/org-export-process1310Sqq"))


Can someone help me understand why asynch export might not be working?

Thanks,

  -k.

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Mon, Jan 22, 2018 at 10:54 PM, Rasmus  wrote:
> Bastien Guerry  writes:
>
>> I'm all for editing manual.org instead of org.texi in the long run.
>>
>> Before moving manual.org into doc/, I'd suggest we agree on editing
>> variables like `fill-column' and the like:
>>
>> fill-column: 70
>> org-list-description-max-indent: 5
>> org-edit-src-content-indentation: ?
>> org-src-preserve-indentation: ?
>>
>> This is necessary so that contributors don't mess up accidentally with
>> the desired format.
>
> Could we use .dir-locals.el to ensure that the correct settings are
> loaded?

How about using org-lint or some other formatter on git commit hook?
after go lang introduced gofmt, many projects adapted the method to
keep the code constant.

too much / slow?
-- 
  yashi