Re: [O] org-annotate/collaboration?

[Alan E. Davis]

Your thoughtful, incisive responses are appreciated.  It's hard to imagine
why that simple expedient---a directory listing with a comment field---has
failed to catch hold.  It was incredibly useful.

Thanks

Alan Davis

On Thu, Feb 9, 2017 at 2:07 PM, Eric Abrahamsen 
wrote:

> "Alan E. Davis"  writes:
>
> > I am looking for something a little different than this: annotated ls
> > listings.  I have been searching blindly for years for this.
> >
> > Back in the 90s was a Dos clone called 4dos, which featured directory
> > listings with annotations, such that typing whatever the command was
> > (dir?), gave a listing with the file name just like "dir" but also a
> > description of the file.
> >
> > It was exceedingly useful for me, in keeping track of a large number
> > of files.  I have never seen anything like it.
> >
> > Could org-annotate fulfill at least part of this requirement?  (I have
> > posted to this list a similar question quite some years ago.)
>
> org-annotate could do the annotation part of it, but really that part
> pales compared to the challenge of creating and maintaining directory
> listings in Org. Doing it once would be easy, but tracking
> additions/deletions/renames in the directory sounds like a *lot* of
> work, not to mention making sure the annotations follow the correct
> entry.
>
> I suppose if you *only* edited the directory listing through custom
> commands you implement from Org mode you could keep it under control,
> but still... Some challenges energize you when you start imaging how to
> solve them. Others make you exhausted just thinking about them!
>
> Eric
>
>
>


-- 
[I do not] carry such information in my mind since it is readily
available in books. …The value of a college education is not the
learning of many facts but the training of the mind to think.
  ---Albert Einstein



"Sweet instruments hung up in cases. . . keep their sounds to themselves."

 ---Shakespeare, _Timon of Athens_

Re: [O] HTML Export problem with org-ref -- SOLVED

[Alan L Tyree]

On 10/02/17 10:23, Alan L Tyree wrote:
I'm trying to export a large document (about 600 printed a4 pages) to 
html. It contains a lot of references.


The export fails with this message:

byte-code: abl-8 chicago limit:t does not seem to exist

Because of the "chicago", I am presuming that the failure is in my 
setup of org-ref, but I can't seem to find any info on it.


What information can I provide to help track this down? any help 
greatly appreciated.


Cheers,

Alan

Org mode version 9.0.4 (9.0.4-elpaplus @ 
/home/alant/.emacs.d/elpa/org-plus-contrib-20170124/)


GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 
2016-03-20 on trouble, modified by Debian


Debian Jessie installation.


Sorry for the noise. The problem was that I had some old (pre-org-ref I 
guess) bibliography stuff in the file. Commented out, but still picked 
up by org-ref. For the record:


# #+BIBLIOGRAPHY: abl-8 chicago limit:t
# #   \bibliographystyle{plain}
# #   \bibliography{refs,tyree}

Deleting from the file fixed everything.




--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel:  04 2748 6206  sip:typh...@iptel.org

Re: [O] HTML Export problem with org-ref

[Alan L Tyree]

On 10/02/17 10:23, Alan L Tyree wrote:
I'm trying to export a large document (about 600 printed a4 pages) to 
html. It contains a lot of references.


The export fails with this message:

byte-code: abl-8 chicago limit:t does not seem to exist

Because of the "chicago", I am presuming that the failure is in my 
setup of org-ref, but I can't seem to find any info on it.


What information can I provide to help track this down? any help 
greatly appreciated.


Cheers,

Alan

Org mode version 9.0.4 (9.0.4-elpaplus @ 
/home/alant/.emacs.d/elpa/org-plus-contrib-20170124/)


GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 
2016-03-20 on trouble, modified by Debian


Debian Jessie installation.



More information:
I didn't notice before, but hovering over a citation gives this message:

Error running timer `org-ref-link-message': (error #("abl-8 chicago 
limit:t does not seem to exist" 0 21 (fontified nil)))






--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel:  04 2748 6206  sip:typh...@iptel.org

[O] HTML Export problem with org-ref

[Alan L Tyree]

I'm trying to export a large document (about 600 printed a4 pages) to 
html. It contains a lot of references.


The export fails with this message:

byte-code: abl-8 chicago limit:t does not seem to exist

Because of the "chicago", I am presuming that the failure is in my setup 
of org-ref, but I can't seem to find any info on it.


What information can I provide to help track this down? any help greatly 
appreciated.


Cheers,

Alan

Org mode version 9.0.4 (9.0.4-elpaplus @ 
/home/alant/.emacs.d/elpa/org-plus-contrib-20170124/)


GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 
2016-03-20 on trouble, modified by Debian


Debian Jessie installation.


--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel:  04 2748 6206  sip:typh...@iptel.org

Re: [O] Exporting blocks of text completely verbatim

[Vicente Vera]

You're absolutely right. The MWE I made had a nasty typo that blew
everything up! I'm sorry for the noise.

The information in the manual still looks misleading to me:

#+BEGIN_EXPORT ascii
All lines in this block will appear only when using this back-end.
#+END_EXPORT

(Taken from "12.7 ASCII/Latin-1/UTF-8 export")

This doesn't seem to be related to verbatim text.

2017-02-09 19:19 GMT+00:00 Charles C. Berry :

> On Thu, 9 Feb 2017, Vicente Vera wrote:
>
> Hello. This discussion
>> https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
>> points out that Org tables are converted to HTML tables when exporting
>> through "ox-md". Leaving Markdown-related issues aside, I've stumbled
>> upon this problem a while back.
>>
>> It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
>> md" should leave it as-is in the exported document but that is not the
>> case. The table gets converted to HTML anyway.
>>
>>
> Not in recent versions of org. Here is an example of a table that is
> exported as a table without any html-ization:
>
> #+BEGIN_SRC emacs-lisp :results raw
>   (org-export-string-as
>"
>   ,#+begin_export md
>   | a |
>   | b |
>   ,#+end_export"
>'md t)
>
> #+END_SRC
>
> #+RESULTS:
> | a |
> | b |
>
>
> Of course, the comma escapes are stripped before `org-export-string-as'
> sees the string.
>
> HTH,
>
> Chuck
>

Re: [O] org-annotate/collaboration?

[Eric Abrahamsen]

"Alan E. Davis"  writes:

> I am looking for something a little different than this: annotated ls
> listings.  I have been searching blindly for years for this.  
>
> Back in the 90s was a Dos clone called 4dos, which featured directory
> listings with annotations, such that typing whatever the command was
> (dir?), gave a listing with the file name just like "dir" but also a
> description of the file.  
>
> It was exceedingly useful for me, in keeping track of a large number
> of files.  I have never seen anything like it.
>
> Could org-annotate fulfill at least part of this requirement?  (I have
> posted to this list a similar question quite some years ago.)

org-annotate could do the annotation part of it, but really that part
pales compared to the challenge of creating and maintaining directory
listings in Org. Doing it once would be easy, but tracking
additions/deletions/renames in the directory sounds like a *lot* of
work, not to mention making sure the annotations follow the correct
entry.

I suppose if you *only* edited the directory listing through custom
commands you implement from Org mode you could keep it under control,
but still... Some challenges energize you when you start imaging how to
solve them. Others make you exhausted just thinking about them!

Eric

Re: [O] Help checking orgcard.pdf

[Kyle Meyer]

"Charles C. Berry"  writes:

> Sorry not to be sending a patch, but I figured I should at least mention 
> that these are not current:
>
> \key{export visible part only}{C-c C-e v}
> \key{insert template of export options}{C-c C-e t}
>
> Also `C-c C-e' brings up the export dispatcher menu (by default) where 
> options to select the visible part or insert a template are revealed. So, 
> mention of the correct incantations need not appear in the refcard.
>
>
> Also AFAICS, this one is not current either:
>
> \key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}

Thanks.

I'll update these in the next couple days, grouped together with any
other stale bindings/descriptions that others have spotted.

-- 
Kyle

[O] Bug: Latex fragments: snippet-flag in packages alist ignored in 9.0.4

[plus]

Steps to reproduce:
1. emacs -Q
2. load org 9.0.4
3. (add-to-list 'org-latex-packages-alist '("" "polyglossia" nil))
4. switch to org-mode and attempt to render any fragment, e.g. $test$
5. error

If you look at the tex file produced, polyglossia has been included in
the preamble even though snippet-flag is nil. Additionally longtable,
wrapfig, rotating, capt-of, hyperref are all included in the preamble
despite the fact their snippet-flag is nil. (These are packages in
org-latex-default-packages-alist).

The relevant function that has been changed in 9.0.4 is
`org-create-formula-image'. It looks like the function used to generate
latex-header, `org-create-formula--latex-header', has been replaced with
`org-latex-make-preamble' (defined in ox-latex.el).

Restoring org-create-formula--latex-header from 9.0.3 and redefining
org-create-formula-image again restores the old behaviour for me. Of
course I don’t know what the problem actually is with the new function.

I should say I am not sure if this problem is specific to my
environment. Please let me know if you can reproduce it.

Emacs  : GNU Emacs 25.1.1 (x86_64-unknown-cygwin)
 of 2016-09-17
Package: Org mode version 9.0.4 (9.0.4-elpa @ 
/cygdrive/c/home/.emacs.d/elpa/org-20170124/)

Re: [O] Help checking orgcard.pdf

[Charles C. Berry]

On Thu, 9 Feb 2017, Kyle Meyer wrote:


Kyle Meyer  writes:



Sorry not to be sending a patch, but I figured I should at least mention 
that these are not current:



\key{export visible part only}{C-c C-e v}
\key{insert template of export options}{C-c C-e t}

Also `C-c C-e' brings up the export dispatcher menu (by default) where 
options to select the visible part or insert a template are revealed. So, 
mention of the correct incantations need not appear in the refcard.



Also AFAICS, this one is not current either:

\key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}

HTH,

Chuck

Re: [O] Exporting blocks of text completely verbatim

[Charles C. Berry]

On Thu, 9 Feb 2017, Vicente Vera wrote:


Hello. This discussion
https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
points out that Org tables are converted to HTML tables when exporting
through "ox-md". Leaving Markdown-related issues aside, I've stumbled
upon this problem a while back.

It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
md" should leave it as-is in the exported document but that is not the
case. The table gets converted to HTML anyway.



Not in recent versions of org. Here is an example of a table that is 
exported as a table without any html-ization:


#+BEGIN_SRC emacs-lisp :results raw
  (org-export-string-as
   "
  ,#+begin_export md
  | a |
  | b |
  ,#+end_export"
   'md t)

#+END_SRC

#+RESULTS:
| a |
| b |


Of course, the comma escapes are stripped before `org-export-string-as' 
sees the string.


HTH,

Chuck

Re: [O] [Ann] Tool to hack time

[Marco Wahl]

Samuel Wales  writes:

> it's great to have such a mechanism.
>
> my preference for such things is to use no-time for ones that are done later.
>
> On 2/8/17, Marco Wahl  wrote:
>>> |:LAST_REPEAT: [2017-02-08 Tue 12:01]
>
> nix the 12:01.

AFAICS this is not so easy to implement.  Thanks for sharing the idea,
though.


Best regards

   Marco

Re: [O] Help checking orgcard.pdf

[David Talmage]

On Thu, Feb 9, 2017 at 1:02 PM, Kyle Meyer  wrote:

> Kyle Meyer  writes:
>
> > David Talmage  writes:
>
> [...]
>
> >> There is a formatting bug in orgcard.tex.  The US letter version,
> >> orgcard_letter.pdf, does not fit on the front and back of a single page
> as
> >> orgcard.pdf does.
> >
> > Thanks for catching that.  It seems to be the extra line
> >
> > \metax{move the line at point up/down}{M-S-UP/DOWN}
> >
> > added in 4340cc78.  I'll play around with it a bit to see if I can get
> > things to fit.  At the worst, I'll remove that line.
>
> Should be fixed with fd565d6e6.  There was a stale line in the
> ...


I confirm that it is fixed.

Thanks!

Re: [O] Help checking orgcard.pdf

[Kyle Meyer]

Kyle Meyer  writes:

> David Talmage  writes:

[...]

>> There is a formatting bug in orgcard.tex.  The US letter version,
>> orgcard_letter.pdf, does not fit on the front and back of a single page as
>> orgcard.pdf does.
>
> Thanks for catching that.  It seems to be the extra line
>
> \metax{move the line at point up/down}{M-S-UP/DOWN}
>
> added in 4340cc78.  I'll play around with it a bit to see if I can get
> things to fit.  At the worst, I'll remove that line.

Should be fixed with fd565d6e6.  There was a stale line in the
"Filtering and Sparse Trees" section, and removing that made space for
the new entry.

-- 
Kyle

Re: [O] Help checking orgcard.pdf

[Kyle Meyer]

David Talmage  writes:

[...]

>> Pushed (4340cc78).
>
>
> There is a formatting bug in orgcard.tex.  The US letter version,
> orgcard_letter.pdf, does not fit on the front and back of a single page as
> orgcard.pdf does.

Thanks for catching that.  It seems to be the extra line

\metax{move the line at point up/down}{M-S-UP/DOWN}

added in 4340cc78.  I'll play around with it a bit to see if I can get
things to fit.  At the worst, I'll remove that line.

-- 
Kyle

Re: [O] Exporting blocks of text completely verbatim

[Vicente Vera]

Hmm nope. Still some modifications are introduced depending on the
back-end. Example blocks are generally indented.

There are cases where those changes makes sense such as in HTML export
but for ASCII and ASCII-based markups truly verbatim blocks would make
sense I believe.

For example, one could edit an Org document and keep some text blocks
completely unchanged so later another processing tool (such as Pandoc)
could deal with them accordingly.


2017-02-09 14:27 GMT+00:00 John Kitchin :

> Isn't
>
> #+BEGIN_EXAMPLE
> Long block
> #+END_EXAMPLE
>
> what you want?
>
> John
>
> ---
> 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
>
>
> On Thu, Feb 9, 2017 at 3:11 PM, Vicente Vera  wrote:
>
>> Hello. This discussion
>> https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
>> points out that Org tables are converted to HTML tables when exporting
>> through "ox-md". Leaving Markdown-related issues aside, I've stumbled
>> upon this problem a while back.
>>
>> It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
>> md" should leave it as-is in the exported document but that is not the
>> case. The table gets converted to HTML anyway.
>>
>> When skimming through the Org manual I found that
>> "#+(BEGIN|END)_EXPORT back-end" blocks are used to export text *only*
>> for the specified back-end. This appears in the ASCII back-end
>> documentation (does it work like this for others back-ends?).
>>
>> In a general level, is there a way to keep blocks of text completely
>> unmodified (without indentation also) on export?
>>
>>
>

Re: [O] org-time-stamp, day format

[Sebastien Vauban]

Nick Dokos  writes:
> Eric S Fraga  writes:
>> On Monday,  6 Feb 2017 at 22:33, Uwe Brauer wrote:
>>
>> [...]
>>
>>> No idea that is was set up like this do you know by change
>>> how and where can I change that?
>>
>> No idea really but I suggest you look at update-locale and locale
>> commands.  Have a look at /etc/default/locale which should contain the
>> actual defaults created by update-locale.
>>
>> I only have
>>
>> #  File generated by update-locale
>> LANG="en_GB.UTF-8"
>> LANGUAGE="en_GB:en"
>>
>> in my /etc/default/locale file and my environment has no LC_ variables
>> set, interestingly.
>
> If LANG is set, that's enough: all the LC_* default to whatever LANG says,
> but you can override them if you set them explicitly.

And if you want to fix this in Emacs only:

--8<---cut here---start->8---
  ;; System locale to use for formatting time values.
  (setq system-time-locale "C") ; Make sure that the weekdays in the
; time stamps of your Org mode files and
; in the agenda appear in English.
--8<---cut here---end--->8---

-- 
Best regards,
Sebastien Vauban

Re: [O] Exporting blocks of text completely verbatim

[John Kitchin]

Isn't

#+BEGIN_EXAMPLE
Long block
#+END_EXAMPLE

what you want?

John

---
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


On Thu, Feb 9, 2017 at 3:11 PM, Vicente Vera  wrote:

> Hello. This discussion
> https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
> points out that Org tables are converted to HTML tables when exporting
> through "ox-md". Leaving Markdown-related issues aside, I've stumbled
> upon this problem a while back.
>
> It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
> md" should leave it as-is in the exported document but that is not the
> case. The table gets converted to HTML anyway.
>
> When skimming through the Org manual I found that
> "#+(BEGIN|END)_EXPORT back-end" blocks are used to export text *only*
> for the specified back-end. This appears in the ASCII back-end
> documentation (does it work like this for others back-ends?).
>
> In a general level, is there a way to keep blocks of text completely
> unmodified (without indentation also) on export?
>
>

[O] Exporting blocks of text completely verbatim

[Vicente Vera]

Hello. This discussion
https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
points out that Org tables are converted to HTML tables when exporting
through "ox-md". Leaving Markdown-related issues aside, I've stumbled
upon this problem a while back.

It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
md" should leave it as-is in the exported document but that is not the
case. The table gets converted to HTML anyway.

When skimming through the Org manual I found that
"#+(BEGIN|END)_EXPORT back-end" blocks are used to export text *only*
for the specified back-end. This appears in the ASCII back-end
documentation (does it work like this for others back-ends?).

In a general level, is there a way to keep blocks of text completely
unmodified (without indentation also) on export?

Re: [O] Feature request: lists with letters

[Rasmus]

Titus von der Malsburg  writes:

> That’s a neat hack that might come in handy at some point.  However, it
> changes the bullet point to letters for /all/ ordered lists in the
> document, not just for those that use letters in the org source.

Yes, I use the simplest possible example.  Here's an example that changes
it for one list at the cost of an extra package.

#+latex_header: \usepackage[shortlabels]{enumitem}
#+attr_latex: :options [a.]
1. one
2. two
3. three


-- 
It was you, Jezebel, it was you