Re: [O] org-annotate/collaboration?
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 Abrahamsenwrote: > "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
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
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
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
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?
"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
"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
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
On Thu, 9 Feb 2017, Kyle Meyer wrote: Kyle Meyerwrites: 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
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
Samuel Waleswrites: > 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
On Thu, Feb 9, 2017 at 1:02 PM, Kyle Meyerwrote: > 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 Meyerwrites: > 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
David Talmagewrites: [...] >> 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
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
Nick Dokoswrites: > 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
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 Verawrote: > 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
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
Titus von der Malsburgwrites: > 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