Re: [O] New Citation syntax on the master branch?

[Bastien]

Hi Vaidheeswaran/Jambunathan,

Rasmus  writes:

>> (My future assignment is through, so the route is clear.)
>
> Can you clarify on this?  My understanding was that it was retracted a
> while back under much fuss.

This is also my understanding.

If I'm wrong, I'll happily stand corrected and we will be allowed
to integrate your patches into org-mode's core code.

Also, we need to know under what identity you want to file your
change: "Jambunathan" or "Vaidheeswaran"?

Thanks,

-- 
 Bastien

[O] Incomplete org-plus-contrib

[Kaushal]

I was following the installation instructions on http://
orgmode.org /
elpa.html 

because I wanted to have the org and the contrib packages installed via the
emacs package manager.

I installed the org-plus-contrib "package" from the package manager as per
the instructions but it is missing the org-eww.el (the very reason I wanted
to install the contrib stuff).

But I see that org-eww.el is indeed still present in the org git: http://

orgmode.org
/

cgit.cgi
/

org-mode.git

/tree/

contrib

/lisp/

org-eww.el


Can you please review why that file is not present in org-plus-contrib?

Thanks.

[O] How to export to pdf and link to other pdf-files?

[Dov Grobgeld]

What do I need to do to inhibit the inclusion of pdf files as graphics
files, when exporting an org file to pdf?

Ideally I would like to have links to referenced pdf files and not have
them treated as embedded graphics.

Thanks!
Dov

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Andreas Leha  writes:
>
>> * Test code block names
>>
>> #+name: test
>> #+begin_src R :results none
>> 1:10
>> #+end_src
>
> OK. It was a R-specific bug. It should now be fixed.
>

Thank you!  Fix confirmed.  The last warning is gone.

Thanks,
Andreas

Re: [O] can't find src blocks

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Hello,
>
> Andreas Leha  writes:
>
>> Since some time (sorry, no bisect, I am afraid) I am having issues
>> with `org-babel-goto-named-src-block'.
>>
>> I simply can not find any source block any more -- even with "emacs -Q"
>>
>> Here is the MWE:
>>
>> * Test code block names
>>
>> Try C-c C-v g  t e s t RET
>>
>> I expect to be taken to the code block, but I get [no match].
>
> Fixed in de8302c65a54b4c8bcdd313a64cf766a02ae3b79. Thank you.
>

Thanks for the quick fix!  Which I can confirm.

Regards,
Andreas

Re: [O] [RFC] Org linting library

[Nicolas Goaziou]

Andreas Leha  writes:

> * Test code block names
>
> #+name: test
> #+begin_src R :results none
> 1:10
> #+end_src

OK. It was a R-specific bug. It should now be fixed.

Thank you.

Regards,

Re: [O] can't find src blocks

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> Since some time (sorry, no bisect, I am afraid) I am having issues
> with `org-babel-goto-named-src-block'.
>
> I simply can not find any source block any more -- even with "emacs -Q"
>
> Here is the MWE:
>
> * Test code block names
>
> Try C-c C-v g  t e s t RET
>
> I expect to be taken to the code block, but I get [no match].

Fixed in de8302c65a54b4c8bcdd313a64cf766a02ae3b79. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Andreas Leha  writes:
>
>> But I still get
>>
>> 191 low Unknown value "none" for header ":results"
>
> Could you show an ECM? I cannot reproduce it.
>

Sure:

--8<---cut here---start->8---
* Test code block names

#+name: test
#+begin_src R :results none
1:10
#+end_src
--8<---cut here---end--->8---

Tested with "emacs -Q" with the same result:

--8<---cut here---start->8---
 4 low   Unknown value "none" for header ":results"
--8<---cut here---end--->8---

Regards,
Andreas

Re: [O] [RFC] Org linting library

[Nicolas Goaziou]

Andreas Leha  writes:

> But I still get
>
> 191 low Unknown value "none" for header ":results"

Could you show an ECM? I cannot reproduce it.

Regards,

[O] can't find src blocks

[Andreas Leha]

Hi all,

Since some time (sorry, no bisect, I am afraid) I am having issues
with `org-babel-goto-named-src-block'.

I simply can not find any source block any more -- even with "emacs -Q"

Here is the MWE:

--8<---cut here---start->8---
* Test code block names

Try C-c C-v g  t e s t RET

I expect to be taken to the code block, but I get [no match].


#+name: test
#+begin_src R
1:10
#+end_src
--8<---cut here---end--->8---

Regards,
Andreas

Re: [O] use of 'system in ox-odt.el

[Suvayu Ali]

On Tue, May 19, 2015 at 02:19:10PM -0400, Matt Price wrote:
> On Tue, May 19, 2015 at 10:57 AM, Rasmus  wrote:
> 
> > Matt Price  writes:
> >
> > > When I export-and-open to odt, org doesn't open the resultant odt, even
> > > though I get a message:
> > >
> > > Running xdg-open /home/matt/RLG231/RLG231Syllabus.odt...done
> > >
> > > org-open-file works fine on links in an org buffer, and an anser on the
> > > following stackoverflow page suggests the issue is in ox-odt.el:
> >
> > With your change it open the odt file as a tar-mode file from Emacs -q.
> > Without your change it doesn't open it at all.  BTW: My Emacs also doesn't
> > open html exports in Fx files when I use C-c C-e h-o.  I never tried to
> > debug it though...
> >
> >
> Yeah, I just got that too -- I realized I hadn't been testing it in the
> right environment, shoot.  this modification worked for me (also form the
> same forum):
> 
> 
>  (setcdr (assq 'system org-file-apps-defaults-gnu ) '(call-process
> "xdg-open" nil 0 nil file))
> 
> Not sure why this should work when the default fails.  Fx opens html
> exports for me with C-c C-e h-o -- also not sure why that should work and
> odt fail.

Do you have a mailcap which says otherwise?  That's what I would suspect
given the doc string for org-file-apps and the default value of
org-file-apps-defaults-gnu on my system.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Andreas Leha  writes:
>
>> I just pulled and rebased again.  The "never-export" issue is
>> gone, indeed. The others are still there.  What am I missing
>> here?
>
> Nothing. I overlooked a typo. It should be fixed in wip-lint.

Thanks.  Now the :tangle header argument does not produce a
warning.

But I still get

--8<---cut here---start->8---
191 low Unknown value "none" for header ":results"
--8<---cut here---end--->8---


Ahh, and one more thing: The :tangle property in my test case was set
buffer wide through

--8<---cut here---start->8---
#+PROPERTY: header-args:R :tangle "myfile.R"
--8<---cut here---end--->8---

But still, it produced a warning for each code block.  It would
be nicer if that warning was issued only once, IMO.  But that is
very minor.

Regards,
Andreas

Re: [O] [RFC] Org linting library

[Nicolas Goaziou]

Andreas Leha  writes:

> I just pulled and rebased again.  The "never-export" issue is
> gone, indeed. The others are still there.  What am I missing
> here?

Nothing. I overlooked a typo. It should be fixed in wip-lint.

Thank you.

Regards,

Re: [O] attachments in parent

[Andreas Leha]

Hi all,

Andreas Leha  writes:
> As it seems, attachments are not found when they are attached to
> a parental header.  Is that on purpose?
>
> IMO, it would be nice if attachments would be searched for up the
> hierarchy as well.  The attachment directory is not inherited, as
> it seems.

I was reminded off-line that there is a
property (`ATTACH_DIR_INHERIT') controlling this behaviour.

I have even set that property in the past but only when I had
explicitly set the attachment directory as well.

Anyway, for future reference here is the MWE again, this time
working as expected:

--8<---cut here---start->8---
* Example
** Test Attachments  :ATTACH:
:PROPERTIES:
:Attachments: sample_attachment.pdf
:ATTACH_DIR_INHERIT: t
:ID:   B1024BF6-48F1-4300-9D0D-831A410BB40B
:END:

[[att:sample_attachment.pdf][This]] is found.

*** In Subsections

[[att:sample_attachment.pdf][This]] is also found.
--8<---cut here---end--->8---

Sorry for the noise,
Andreas

Re: [O] use of 'system in ox-odt.el

[Matt Price]

Resenting to list (sorry rasmus)
-- Forwarded message --
From: "Matt Price" 
Date: May 19, 2015 11:04
Subject: Re: [O] use of 'system in ox-odt.el
To: "Rasmus" 
Cc:



On Tue, May 19, 2015 at 10:57 AM, Rasmus  wrote:

> Matt Price  writes:
>
> > When I export-and-open to odt, org doesn't open the resultant odt, even
> > though I get a message:
> >
> > Running xdg-open /home/matt/RLG231/RLG231Syllabus.odt...done
> >
> > org-open-file works fine on links in an org buffer, and an anser on the
> > following stackoverflow page suggests the issue is in ox-odt.el:
>
> With your change it open the odt file as a tar-mode file from Emacs -q.
> Without your change it doesn't open it at all.  BTW: My Emacs also doesn't
> open html exports in Fx files when I use C-c C-e h-o.  I never tried to
> debug it though...
>
>
Yeah, I just got that too -- I realized I hadn't been testing it in the
right environment, shoot.  this modification worked for me (also form the
same forum):


 (setcdr (assq 'system org-file-apps-defaults-gnu ) '(call-process
"xdg-open" nil 0 nil file))

Not sure why this should work when the default fails.  Fx opens html
exports for me with C-c C-e h-o -- also not sure why that should work and
odt fail.

m


> Rasmus
>
> --
> 9000!
>
>
>

Re: [O] math in footnotes not exported correctly when a buffer is narrowed

[Rasmus]

Mark Edgington  writes:

> Rasmus  gmx.us> writes:
>> 
>> It was fixed a while ago in master.  Are you using 8.2?
>
>
> Oh, I thought I was using something more recent, since the version was named
> "8.3beta", but apparently that's old.  Thanks!

8.3beta is the name used for master.  If your version of Org is up to date
you should not see this problem.

> Also, org.el is nearly 1MB in size, which is crazy -- maybe it could use
> some splitting also!

Patches are welcome of course.

Thanks,
Rasmus

-- 
C is for Cookie

Re: [O] org-latex-custom-lang-environments

[Rasmus]

Jacob Gerlach  writes:

> Hello,
>
> On Tue, May 19, 2015 at 11:29 AM, Rasmus  wrote:
>> If I explicitly eval:
>>
>> (org-babel-do-load-languages 'org-babel-load-languages '((sh . t)))
>> (setq org-latex-custom-lang-environments '((sh "myverbatim"))
>>   org-latex-listings t)
>>
>> And export
>>
>> #+BEGIN_SRC sh :exports code
>> echo "Hello"
>> #+END_SRC
>>
>> I get the the block wrapped in the desired environment.  I don't know why
>> your local variables are ignored, but it seems the result is the same when
>> using the Org-specific BIND keyword...
>
>
> Yes, I see the same - setting them with setq gives the desired
> behavior. I must have done this during my initial experimentation
> which is why it worked until I restarted emacs.
>
> I know the local variables are parsed - I get asked for confirmation
> on potentially unsafe values, and after confirming, C-h v ... shows
> that the value has been set correctly.
>
> Does this maybe have to do with export happening in a temporary
> buffer? I would assume that file local variables get copied over to
> the temp buffer as buffer local variables. Is that the case?

No.  And actually it works, only it shouldn't be quoted.

# -*- org-export-allow-bind-keywords: t; -*-
#+BIND: org-latex-listings t
#+BIND: org-latex-custom-lang-environments ((sh "myverbatim"))

#+BEGIN_SRC sh :exports code
echo "Hello"
#+END_SRC


Or

#+BEGIN_SRC sh :exports code
echo "Hello"
#+END_SRC

# Local Variables:
# org-latex-listings: t
# org-latex-custom-lang-environments:  ((sh "myverbatim"))
# END:


Hope it helps,
Rasmus

-- 
Don't panic!!!

Re: [O] math in footnotes not exported correctly when a buffer is narrowed

[Mark Edgington]

Rasmus  gmx.us> writes:
> 
> It was fixed a while ago in master.  Are you using 8.2?


Oh, I thought I was using something more recent, since the version was named
"8.3beta", but apparently that's old.  Thanks!

A slight digression:  I noticed, when cloning the git repo, that the current
repo size is around 67 MB.  That seems somewhat large for a repo consisting
primarily of source code (when all the source compresses to under 3MB). 
Have there been discussions about splitting the repository so that older
content is relegated to a 'historic' repo?  Also, org.el is nearly 1MB in
size, which is crazy -- maybe it could use some splitting also!

Re: [O] org-latex-custom-lang-environments

[Jacob Gerlach]

Hello,

On Tue, May 19, 2015 at 11:29 AM, Rasmus  wrote:
> If I explicitly eval:
>
> (org-babel-do-load-languages 'org-babel-load-languages '((sh . t)))
> (setq org-latex-custom-lang-environments '((sh "myverbatim"))
>   org-latex-listings t)
>
> And export
>
> #+BEGIN_SRC sh :exports code
> echo "Hello"
> #+END_SRC
>
> I get the the block wrapped in the desired environment.  I don't know why
> your local variables are ignored, but it seems the result is the same when
> using the Org-specific BIND keyword...


Yes, I see the same - setting them with setq gives the desired
behavior. I must have done this during my initial experimentation
which is why it worked until I restarted emacs.

I know the local variables are parsed - I get asked for confirmation
on potentially unsafe values, and after confirming, C-h v ... shows
that the value has been set correctly.

Does this maybe have to do with export happening in a temporary
buffer? I would assume that file local variables get copied over to
the temp buffer as buffer local variables. Is that the case?

Regards,
Jake

Re: [O] org-latex-custom-lang-environments

[Rasmus]

Hi Jake,

Jacob Gerlach  writes:

> I thought I had successfully used this variable, but after restarting
> emacs, I can no longer reproduce the documented behavior.
>
> Given the following org file:
> --
> #+BEGIN_SRC sh :exports code
> echo "Hello"
> #+END_SRC
>
> # Local Variables:
> # org-latex-listings: t
> # org-latex-custom-lang-environments: (quote ((sh "myverbatim")))
> # END:
> --

If I explicitly eval: 

(org-babel-do-load-languages 'org-babel-load-languages '((sh . t)))
(setq org-latex-custom-lang-environments '((sh "myverbatim"))
  org-latex-listings t)

And export

#+BEGIN_SRC sh :exports code
echo "Hello"
#+END_SRC

I get the the block wrapped in the desired environment.  I don't know why
your local variables are ignored, but it seems the result is the same when
using the Org-specific BIND keyword...

Rasmus




-- 
And I faced endless streams of vendor-approved Ikea furniture. . .

[O] org-latex-custom-lang-environments

[Jacob Gerlach]

Hello,

I thought I had successfully used this variable, but after restarting
emacs, I can no longer reproduce the documented behavior.

Given the following org file:
--
#+BEGIN_SRC sh :exports code
echo "Hello"
#+END_SRC

# Local Variables:
# org-latex-listings: t
# org-latex-custom-lang-environments: (quote ((sh "myverbatim")))
# END:
--

I expect to export
--
\begin{myverbatim}
echo "Hello"
\end{myverbatim}
--
(and I thought I had observed this behavior the first time I tried it).
Instead, I get
--
\lstset{language=sh,label= ,caption= ,captionpos=b,numbers=none}
\begin{lstlisting}
echo "Hello"
\end{lstlisting}
--

Am I missing something?

Regards,
Jake

Re: [O] New papers published on using org-mode in scientific publishing

[Leo Ufimtsev]

Nice.

- Original Message -
> From: "John Kitchin" 
> To: emacs-orgmode@gnu.org
> Sent: Sunday, May 17, 2015 2:40:42 PM
> Subject: [O] New papers published on using org-mode in scientific publishing
> 
> Hi All,
> 
> I recently had two "perspectives" published on using org-mode to write
> scientific papers, and on reusing the data that is embedded in them! One
> was published in an American Chemical Society journal:
> 
> http://kitchingroup.cheme.cmu.edu/blog/2015/05/17/New-publication-in-ACS-Catalysis-on-data-sharing-practices/
> 
> and another in an Elsevier journal:
> 
> http://kitchingroup.cheme.cmu.edu/blog/2015/05/17/New-publication-in-Surface-Science-on-data-sharing/
> 
> This is pretty exciting for me, and a testament to what org-mode
> enables! Thanks to everyone who has contributed to this great project.
> This makes about a dozen peer-reviewed papers we have written in
> org-mode now.
> 
> --
> 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
> 
> 

-- 
Leo Ufimtsev | Intern Software Engineer @ Eclipse Team

[O] Exporting custom dynamic blocks

[Bernhard Schmitz]

Hi,

What is the canonical way of exporting custom dynamic blocks? Is there a 
mechanism similar to org-dblock-write: only for exporting dblocks? I cannot 
find any documentation on this.

To give a little background to my question: I am currently writing a conversion 
from deadlines/schedules/effort to pgf-gantt charts. This was discussed before 
on this list, but I couldn't find anyone actually implementing it. (In case 
someone wants to try: 
https://github.com/HeyFlash/emacs-stuff/blob/master/experiments/org-gantt-experiment.el
 )
Ideally I would like to create a custom dynamic block that contains the result 
of my parsing and computation, and then have a custom exporter for that dynamic 
block that creates the pgf-gantt code, so that I can later add exporters for 
other formats, e.g. html.

If there is no such mechanism, what is the best way of storing that pgf-gantt 
source code so that it gets integrated into latex export, but doesn't interfere 
with other exporters? Currently I'm simply writing the pgf-gantt code into the 
custom block, and this does get exported correctly to latex, but produces boxes 
with error messages in html.

Thank you & regards,
Bernhard

Re: [O] use of 'system in ox-odt.el

[Rasmus]

Matt Price  writes:

> When I export-and-open to odt, org doesn't open the resultant odt, even
> though I get a message:
>
> Running xdg-open /home/matt/RLG231/RLG231Syllabus.odt...done
>
> org-open-file works fine on links in an org buffer, and an anser on the
> following stackoverflow page suggests the issue is in ox-odt.el:

With your change it open the odt file as a tar-mode file from Emacs -q.
Without your change it doesn't open it at all.  BTW: My Emacs also doesn't
open html exports in Fx files when I use C-c C-e h-o.  I never tried to
debug it though...


Rasmus

-- 
9000!

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
>> I have finally made some time to test this. I get some
>> unexpected warnings:
>>
>>79 low   Unknown value "myfile.R" for header ":tangle"
>>   192 low   Unknown value "none" for header ":results"
>
> Make sure you rebased the wip-lint branch on top of master.
>
>> 22985 low   Unknown value "never-export" for header ":eval"
>
> I added it to allowed value. You need to update Org.
>

I just pulled and rebased again.  The "never-export" issue is
gone, indeed. The others are still there.  What am I missing
here?

Thanks,
Andreas

[O] use of 'system in ox-odt.el

[Matt Price]

Hi,

When I export-and-open to odt, org doesn't open the resultant odt, even
though I get a message:

Running xdg-open /home/matt/RLG231/RLG231Syllabus.odt...done

org-open-file works fine on links in an org buffer, and an anser on the
following stackoverflow page suggests the issue is in ox-odt.el:

http://stackoverflow.com/questions/24434854/emacs-org-odt-export-as-odf-and-open-odt-outside-emacs

Below is a git diff for the suggested change:

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 163f580..80650b1 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -94,7 +94,7 @@
 (?O "As ODT file and open"
 (lambda (a s v b)
   (if a (org-odt-export-to-odt t s v)
-(org-open-file (org-odt-export-to-odt nil s v) 'system))
+(org-open-file (org-odt-export-to-odt nil s v) ))
   :options-alist
   '((:odt-styles-file "ODT_STYLES_FILE" nil nil t)
 (:description "DESCRIPTION" nil nil newline)



I'm not sure what 'system does in the changed line -- the documentation
suggests a non-nil argument here will result in the odt file being opened
in a buffer rather than in a browser. Nocolas, others, does this look like
a bug? sorry I don't know more.

M

[O] Suspected bug: Invisible cursor in calendar buffer.

[Alain . Cochard]

[8.2.10 (release_8.2.10 @ /usr/share/emacs/24.5/lisp/org/)] 
GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.14.12) of
2015-04-17 on buildvm-04.phx2.fedoraproject.org

Hello.

I do: 'emacs -Q new_file.org'.

Once in the file I do: 'C-c .'  I see in the minibuffer:
  
   Date+time [2015-05-19]:   => < 2015-05-19 Tue > 

I then click with the mouse inside the calendar buffer at an inactive
place, say just before the '17' of May.  In the minibuffer, the part
after the colon disappears.

I then type 'C-f' (calendar-forward-day); the (red) cursor in the
calendar buffer does not move at all.  However, I can see that it is
somehow working because after a single 'C-f' and , the string
inserted in the file is '<2015-05-17 Sun>'; after two 'C-f' and ,
it is '<2015-05-18 Mon>', etc.  Simply, nothing shows cursor movement.

Is this behavior normal?  If so, is there a way to get the behavior I
expect (i.e., to see the cursor move to the next day after each
'C-f')?

Thank you.

By contrast, if I stay in the minibuffer and use, say, , the
cursor in the calendar buffer moves as expected, and the part after
the colon in the minibuffer changes accordingly.

Also, if I do 'emacs -Q -nw new_file.org', 'C-c .' and twice 'C-x o'
so as to go to the calendar buffer, then a green cursor does move as
expected after each 'C-f' (even though the red cursor remains on
today's date).

Finally, on another computer with configuration 
   Org-mode version 6.21b
   GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.9) of
   2013-07-17 on c6b10.bsys.dev.centos.org
I do get the behavior I expect.

Re: [O] [RFC] Org linting library

[Nicolas Goaziou]

Rainer M Krug  writes:

> This sounds very interesting and I would like to try it out. I
> understand that it can't be put into master, but could it be put into a
> branch?

It already lives in "wip-lint" branch.

Regards,

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> The following library implements linting for Org syntax. The sole public
>> function is `org-lint', which see.
>>
>> Internally, the library defines a new structure: `org-lint-checker',
>> with the following slots:
>>
>>   - NAME: Unique check identifier, as a symbol. The check is done
>> calling the function `org-lint-NAME' with one mandatory argument,
>> the parse tree describing the current Org buffer. Such function
>> calls are wrapped within a `save-excursion' and point is always at
>> `point-min'. Its return value has to be an alist (POSITION MESSAGE)
>> when POSITION refer to the buffer position of the error, as an
>> integer, and MESSAGE is a strings describing the error.
>>
>>   - DESCRIPTION: Summary about the check, as a string.
>>
>>   - CATEGORIES: Categories relative to the check, as a list of symbol.
>> They are used for filtering when calling `org-lint'. Checkers not
>> explicitly associated to a category are collected in the `default'
>> one.
>>
>>   - TRUST: The trust level one can have in the check. It is either `low'
>> or `high', depending on the heuristics implemented and the nature of
>> the check. This has an indicative value only and is displayed along
>> reports.
>>
>> All checks have to be listed in `org-lint--checkers'.
>>
>> Results are displayed in a special "*Org Lint*" buffer with a dedicated
>> major mode, derived from `tabulated-list-mode'. In addition to the usual
>> key-bindings inherited from it, "C-j" displays problematic line reported
>> under point and "RET" jumps to it.
>>
>> Checks currently implemented are:
>>
>>   - duplicates CUSTOM_ID properties
>>   - duplicate NAME values
>>   - duplicate targets
>>   - duplicate footnote definitions
>>   - orphaned affiliated keywords
>>   - obsolete affiliated keywords
>>   - missing language in src blocks
>>   - NAME values with a colon
>>   - wrong header arguments in src blocks
>>   - misuse of CATEGORY keyword
>>   - "coderef" links with unknown destination
>>   - "custom-id" links with unknown destination
>>   - "fuzzy" links with unknown destination
>>   - "id" links with unknown destination
>>   - links to non-existent local files
>>   - special properties in properties drawer
>>   - obsolete syntax for PROPERTIES drawers
>>   - missing definition for footnote references
>>   - missing reference for footnote definitions
>>   - non-footnote definitions in footnote section
>>   - probable invalid keywords
>>   - invalid blocks
>>   - probable incomplete drawers
>>   - obsolete QUOTE section
>>
>> Since it relies on lexical binding, `pcase' and `string-prefix-p', it
>> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
>> useful enough.
>>
>
> This sounds very interesting and I would like to try it out. I
> understand that it can't be put into master, but could it be put into a
> branch?
>
> This would make testing a bit easier.
>

It is.  The branch is called `wip-lint'.

Regards,
Andreas

[O] attachments in parent

[Andreas Leha]

Hi all,

As it seems, attachments are not found when they are attached to
a parental header.  Is that on purpose?

IMO, it would be nice if attachments would be searched for up the
hierarchy as well.  The attachment directory is not inherited, as
it seems.

Here is an example illustrating my question (you'll have to
attach something yourself to make it work, though):

--8<---cut here---start->8---
* Example
** Test Attachments  :ATTACH:
:PROPERTIES:
:Attachments: sample_attachment.pdf
:ID:   B1024BF6-48F1-4300-9D0D-831A410BB40B
:END:

[[att:sample_attachment.pdf][This]] is found.

*** In Subsections

[[att:sample_attachment.pdf][This]] is not found.
--8<---cut here---end--->8---

Regards,
Andreas

PS: the relevant part of my setup:
--8<---cut here---start->8---
(require 'org-attach)
(setq org-link-abbrev-alist '(("att" . org-attach-expand-link)))
--8<---cut here---end--->8---

Re: [O] [RFC] Org linting library

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> I have finally made some time to test this. I get some
> unexpected warnings:
>
>79 low   Unknown value "myfile.R" for header ":tangle"
>   192 low   Unknown value "none" for header ":results"

Make sure you rebased the wip-lint branch on top of master.

> 22985 low   Unknown value "never-export" for header ":eval"

I added it to allowed value. You need to update Org.

> Thanks for this very useful tool!

Thanks for the feedback.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Org linting library

[Rainer M Krug]

Nicolas Goaziou  writes:

> Hello,
>
> The following library implements linting for Org syntax. The sole public
> function is `org-lint', which see.
>
> Internally, the library defines a new structure: `org-lint-checker',
> with the following slots:
>
>   - NAME: Unique check identifier, as a symbol. The check is done
> calling the function `org-lint-NAME' with one mandatory argument,
> the parse tree describing the current Org buffer. Such function
> calls are wrapped within a `save-excursion' and point is always at
> `point-min'. Its return value has to be an alist (POSITION MESSAGE)
> when POSITION refer to the buffer position of the error, as an
> integer, and MESSAGE is a strings describing the error.
>
>   - DESCRIPTION: Summary about the check, as a string.
>
>   - CATEGORIES: Categories relative to the check, as a list of symbol.
> They are used for filtering when calling `org-lint'. Checkers not
> explicitly associated to a category are collected in the `default'
> one.
>
>   - TRUST: The trust level one can have in the check. It is either `low'
> or `high', depending on the heuristics implemented and the nature of
> the check. This has an indicative value only and is displayed along
> reports.
>
> All checks have to be listed in `org-lint--checkers'.
>
> Results are displayed in a special "*Org Lint*" buffer with a dedicated
> major mode, derived from `tabulated-list-mode'. In addition to the usual
> key-bindings inherited from it, "C-j" displays problematic line reported
> under point and "RET" jumps to it.
>
> Checks currently implemented are:
>
>   - duplicates CUSTOM_ID properties
>   - duplicate NAME values
>   - duplicate targets
>   - duplicate footnote definitions
>   - orphaned affiliated keywords
>   - obsolete affiliated keywords
>   - missing language in src blocks
>   - NAME values with a colon
>   - wrong header arguments in src blocks
>   - misuse of CATEGORY keyword
>   - "coderef" links with unknown destination
>   - "custom-id" links with unknown destination
>   - "fuzzy" links with unknown destination
>   - "id" links with unknown destination
>   - links to non-existent local files
>   - special properties in properties drawer
>   - obsolete syntax for PROPERTIES drawers
>   - missing definition for footnote references
>   - missing reference for footnote definitions
>   - non-footnote definitions in footnote section
>   - probable invalid keywords
>   - invalid blocks
>   - probable incomplete drawers
>   - obsolete QUOTE section
>
> Since it relies on lexical binding, `pcase' and `string-prefix-p', it
> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
> useful enough.
>

This sounds very interesting and I would like to try it out. I
understand that it can't be put into master, but could it be put into a
branch?

This would make testing a bit easier.

Thanks,

Rainer

> Feedback welcome.
>
>
> Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Indicate on collapsed code block if in "editing mode"

[Nicolas Goaziou]

Rainer M Krug  writes:

> Scrolling delays when having non-collapsed code blocks, as my document
> is relatively long and contains many code blocks (literate
> programming).
>
> I already disabled fontification for the code blocks, but it does not
> make a big difference.

I meant: why do you need to know if a collapsed code block is being
edited?

Regards,

Re: [O] Indicate on collapsed code block if in "editing mode"

[Rainer M Krug]

Nicolas Goaziou  writes:

> Hello,
>
> Rainer M Krug  writes:
>
>> Due to scrolling speed, I prefer to leave the source blocks collapsed,
>> but then I do not see if they are in "editing mode", i.e. if I did C-'
>> on them for editing.
>>
>> Is there a way of indicating on the collapsed code block if it is in
>> "editing mode"?
>
> I don't think there is one. Why do you need such an indication?

Scrolling delays when having non-collapsed code blocks, as my document
is relatively long and contains many code blocks (literate
programming).

I already disabled fontification for the code blocks, but it does not
make a big difference.

Rainer

>
>
> Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] [RFC] Org linting library

[Andreas Leha]

Nicolas Goaziou  writes:
> Hello,
>
> The following library implements linting for Org syntax. The sole public
> function is `org-lint', which see.
>
> Internally, the library defines a new structure: `org-lint-checker',
> with the following slots:
>
>   - NAME: Unique check identifier, as a symbol. The check is done
> calling the function `org-lint-NAME' with one mandatory argument,
> the parse tree describing the current Org buffer. Such function
> calls are wrapped within a `save-excursion' and point is always at
> `point-min'. Its return value has to be an alist (POSITION MESSAGE)
> when POSITION refer to the buffer position of the error, as an
> integer, and MESSAGE is a strings describing the error.
>
>   - DESCRIPTION: Summary about the check, as a string.
>
>   - CATEGORIES: Categories relative to the check, as a list of symbol.
> They are used for filtering when calling `org-lint'. Checkers not
> explicitly associated to a category are collected in the `default'
> one.
>
>   - TRUST: The trust level one can have in the check. It is either `low'
> or `high', depending on the heuristics implemented and the nature of
> the check. This has an indicative value only and is displayed along
> reports.
>
> All checks have to be listed in `org-lint--checkers'.
>
> Results are displayed in a special "*Org Lint*" buffer with a dedicated
> major mode, derived from `tabulated-list-mode'. In addition to the usual
> key-bindings inherited from it, "C-j" displays problematic line reported
> under point and "RET" jumps to it.
>
> Checks currently implemented are:
>
>   - duplicates CUSTOM_ID properties
>   - duplicate NAME values
>   - duplicate targets
>   - duplicate footnote definitions
>   - orphaned affiliated keywords
>   - obsolete affiliated keywords
>   - missing language in src blocks
>   - NAME values with a colon
>   - wrong header arguments in src blocks
>   - misuse of CATEGORY keyword
>   - "coderef" links with unknown destination
>   - "custom-id" links with unknown destination
>   - "fuzzy" links with unknown destination
>   - "id" links with unknown destination
>   - links to non-existent local files
>   - special properties in properties drawer
>   - obsolete syntax for PROPERTIES drawers
>   - missing definition for footnote references
>   - missing reference for footnote definitions
>   - non-footnote definitions in footnote section
>   - probable invalid keywords
>   - invalid blocks
>   - probable incomplete drawers
>   - obsolete QUOTE section
>
> Since it relies on lexical binding, `pcase' and `string-prefix-p', it
> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
> useful enough.
>
> Feedback welcome.
>
>
> Regards,

Hi Nicolas,

I have finally made some time to test this.  I get some
unexpected warnings:

   79 low   Unknown value "myfile.R" for header ":tangle"
  192 low   Unknown value "none" for header ":results"
22985 low   Unknown value "never-export" for header ":eval"

Thanks for this very useful tool!

Thanks,
Andreas

Re: [O] Indicate on collapsed code block if in "editing mode"

[Nicolas Goaziou]

Hello,

Rainer M Krug  writes:

> Due to scrolling speed, I prefer to leave the source blocks collapsed,
> but then I do not see if they are in "editing mode", i.e. if I did C-'
> on them for editing.
>
> Is there a way of indicating on the collapsed code block if it is in
> "editing mode"?

I don't think there is one. Why do you need such an indication?


Regards,

-- 
Nicolas Goaziou

Re: [O] A Microsoftesque detail in org

[Suvayu Ali]

Hi Rasmus,

On Mon, May 18, 2015 at 05:39:36PM +0200, Rasmus wrote:
> Suvayu Ali  writes:
> 
> > As for Rasmus's examples of similar behaviour in other modes, I don't
> > like them either.  Unfortunately again, I'm too short on time to fix the
> > behaviour in my setup.
> 
> So far nobody has felt strongly enough about this to supply a patch, even
> to org.texi or, I think, worg.
> 
> Here's an untested start to get rid of those pesky Microsoftesque detail
> in org-mode
> 
> (with-eval-after-load 'org
>   (add-hook 'org-mode-hook
> (defun org-keyboard-purist ()
> (org-defkey org-mode-map (kbd "RET") nil)
> (mapc (lambda (key)
> (org-defkey org-mode-map key nil))
>   (list [(control return)]
> [(shift control return)]
> [(meta return)])

I didn't realise it is this simple!  I'm always afraid of fiddling with
Org key bindings because of all the context sensitive magic going on.

Thank you.

-- 
Suvayu

Open source is the future. It sets us free.

[O] Indicate on collapsed code block if in "editing mode"

[Rainer M Krug]

Hi

Due to scrolling speed, I prefer to leave the source blocks collapsed,
but then I do not see if they are in "editing mode", i.e. if I did C-'
on them for editing.

Is there a way of indicating on the collapsed code block if it is in
"editing mode"?

Thanks,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Marking/highlighting text temporarily

[Nicolas Goaziou]

Rasmus  writes:

> Nicolas Goaziou  writes:

>> Then it cannot even replace inlinetasks.
>
> Is that a goal?

It should be. 

We don't need another syntax for something that does almost the same
thing as an inlinetask but, yet, isn't one. Inline todo/inlinetasks,
there can only be one.

> I think "totally useless" stretching it.  Two examples.
>
>[@:1] My sentence on foo [@] and something else
>
>* Annotations
>  [@:1:Nicolas] Remember to refer to bar
>
>
>  #+TODO: Notes/Nicolas
>  My sentence on foo [Notes/Nicolas: Remember to refer to bar] and
>  something else.
>
> The latter is less precise, but I would still prefer it.  I guess you
> could add references to an endnote for long notes, which would bring it
> closer to killing org-inlinetasks.

I think you are missing my point. 

My goal is to be able to /mark/ a very specific part of the document
(ranging from a word to a whole section). Your syntax cannot achieve
that, because you need two markers, one at the beginning and one at the
end of the area you need to mark. This is a dead-end.

Also, I don't want to clutter the document with annotations, hence
moving them to a specific section, while retaining a minimal syntax in
the document.

No matter how much you like it, your syntax isn't general enough for
annotations. This is understandable, since you're after inline TODO, not
annotations.

Regards,