Re: [O] erroneous clocktable for November 2018 - possible DST problem
OK, I can confirm that the 20181112 release has this problem but the development version from github does not. Thanks, Jeff On Sat, Nov 17, 2018 at 12:50 PM Nicolas Goaziou wrote: > Hello, > > Jeff Trull writes: > > > Clocktables containing work in November of 2018 are reported incorrectly, > > showing the wrong day (typically one earlier than the correct date). For > > example, in the attached repro.org, work is performed on the 3rd and > 5th of > > November, but when daily reports are used in the clocktable the work on 5 > > November is reported as occurring on 4 November. Reporting 1-4 November > and > > 5-30 November separately works around the problem. > > > > In the US, Daylight Savings ended on 4 November; this fact plus a > previous > > problem (reported here: > > > https://stackoverflow.com/questions/42821604/why-is-emacs-org-mode-missing-one-date-from-clocktable > ) > > suggests DST is involved. > > I think something like this was fixed in development branch. Please test > it if you can. > > Regards, > > -- > Nicolas Goaziou >
[O] Display org-clock info in header line
I found there are configuration like this:
#+begin_src emacs-lisp
;;; display org-clock in head-line.
(setq org-clock-clocked-in-display nil)
(defun my/show-org-clock-in-header-line ()
(setq-default header-line-format '((" " org-mode-line-string " "
(defun my/remove-org-clock-in-header-line ()
(setq-default header-line-format nil))
(add-hook 'org-clock-in-hook #'my/show-org-clock-in-header-line)
(add-hook 'org-clock-out-hook #'my/remove-org-clock-in-header-line)
(add-hook 'org-clock-cancel-hook #'my/remove-org-clock-in-header-line)
#+end_src
But this header-line is displayed in every window. I wish there is a global
header-line to display org-clock info.
Why I want this?
Because my notebook screen is small, when I split window, the mode-line is very
small not enough to display much info for org-clock. I don't want to display
org-clock info in frame-title. That's not the right place.
I saw some Emacs extensions like tabs package (for example: nerdtab
https://github.com/casouri/nerdtab) display a global top line instead of
per-window.
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, > I'm not sure I follow your suggestion regarding changing the > implementation. But anyhow I don't think the implementation is heavy > and at risk of cumbersome code duplication. My opinion ofc Sure. The code is not that complicated. > I like the idea of a function that would symbolically links folders > from "ID"-folder structure to a hierarchy-folder structure, based on > the name and path of the org-file and its headings containing the > links. I probably wouldn't use it much myself though. Not until > org-mode starts working better with multiple files, allowing us to > more easily define "org-mode libraries". I am wondering what you mean by "org-mode libraries". Can you explain further? Also, another thought about the attachment: links. It would be useful to implement links to attachments, which are not in the current org entry. For example, something like "attachment:ORG-ID:file-name", where ORG-ID refers to ID of an arbitrary org entry. Best, Ihor Gustav Wikström writes: > Hi Ihor, > > I'm not sure I follow your suggestion regarding changing the implementation. > But anyhow I don't think the implementation is heavy and at risk of > cumbersome code duplication. My opinion ofc > > I like the idea of a function that would symbolically links folders from > "ID"-folder structure to a hierarchy-folder structure, based on the name and > path of the org-file and its headings containing the links. I probably > wouldn't use it much myself though. Not until org-mode starts working better > with multiple files, allowing us to more easily define "org-mode libraries". > > /G > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 3 november 2018 04:38 >> To: Gustav Wikström ; Marco Wahl >> Cc: emacs-orgmode >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> Hi Gustav, >> >> Thanks for the patch! >> I am a heavy user of org attachments, so it is pleasant that someone >> spent a time to implement this useful feature into org. >> >> A comment regarding the code. >> Your new link types appears to reimplement some of the code for the >> "file:" links. >> Would it make more sense to implement the "attachment:" link type as >> abbreviation? >> I mean something like the code below: >> >> >> (defun yant/process-att-abbrev (arg) >> "Return `org-attach-dir' for the current entry." >> (s-concat (org-attach-dir 'CREATE) arg)) >> >> (add-to-list 'org-link-abbrev-alist (cons "att" >> "file:%(yant/process-att-abbrev)")) >> >> (defun org-att-link-complete ( arg) >> "Completion function for att: link." >> (let* ((ref-dir (org-attach-dir 'CREATE)) >> (filelink (let ((default-directory ref-dir)) >> (org-file-complete-link))) >> (filepath (apply #'s-concat (cdr (s-split ":" filelink) >> (format "att:%s" filepath))) >> >> (org-link-set-parameters "att" >> :complete #'org-att-link-complete) >> >> >> Also, is anyone interested in automatic placing of org attachments into >> a folder structure, which mirrors the org path? >> Something like in the following Stack Exchange question: >> https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org- >> attach >> >> Best, >> Ihor >> >> Gustav Wikström writes: >> >> > Hi Marco, >> > >> > Nice to hear you like it! Yeah, I'm pretty happy with that functionality >> > as well. Use it >> all the time to quickly add links to attached files. >> > >> > One use case I have for this (as an example) is for projects and tasks. I >> > have a >> 'tasks.org' file with nodes for each of my tasks and each of my projects. >> Usually, if the >> task is about some digital work, there are files involved with it. So I have >> a convention >> to add folders next to the 'tasks.org' file with names like 'YYMM >> [task/project title]', >> and attach the folder to each task/project node. C-c C-l attached RET then >> makes it super- >> easy to refer to particular files within that folder, from within the node >> in the >> 'tasks.org' file! >> > >> > Another use case is for my 'digital brain', where it's also fairly common >> > for me to have >> attachment folders where I want to refer to files within them. Images for >> example, that >> then will be displayed in the org-mode file. Haven't settled on whether I >> should use auto- >> managed ID's for these folders, or :ATTACH_DIR: properties though. Currently >> using a bit >> of both... >> > >> > I'm not familiar with the 'next' branch and the plans for integrating it >> > into 'master'. >> But if 'master' is to offensive to merge into straight away, 'next' sounds >> like a good >> option! >> > >> > Kind regards >> > Gustav >> > >> > -Original Message- >> > From: Marco Wahl >> > Sent: den 1 november 2018 17:01 >> > To: Gustav Wikström >> > Subject: Re: FW: [RFC] Link-type for attachments, more attach options >> > >> > The following message is a
Re: [O] Local COLUMNS and columnview block
Hello,
Lele Gaifax writes:
> As said, a the local COLUMNS setting is honored by the transient columns view,
> but it is ignored by org-clock-report and org-dbclock-update.
>
> Am I doing something wrong or isn't it possible?
COLUMNS property, or keyword, are not related to clocktable and such.
Moreover, in the "columnview" dynamic block, you use ":id global", which
means calling `org-columns' on the whole buffer, using global COLUMNS
keyword.
You can use :format property to use the appropriate columns:
:format "%40ITEM(Item) %13Effort(Effort){:} %CLOCKSUM(Spent)"
Regards,
--
Nicolas Goaziou
Re: [O] Bug: no more fontifying in org mode [9.1.14 (9.1.14-dist @ /home/abel/git-ext/org-9.1.14/lisp/)]
Hello, boris martin writes: > same issue occured with the master branch of > https://code.orgmode.org/bzg/org-mode.git > > - is there a way for me to know for sure that there is not interference > from any other git-org > > installation file ? With the minimal init file you provided, I doubt you have any interference whatsoever. > > - is there a way for me to put emacs in a verbose debug mode so i can > trace what currently > happened when i open a org file ? Besides , you can also add a (debug) call somewhere in "org.el", perhaps in "org-do-emphasis-faces". Regards, -- Nicolas Goaziou
Re: [O] erroneous clocktable for November 2018 - possible DST problem
Hello, Jeff Trull writes: > Clocktables containing work in November of 2018 are reported incorrectly, > showing the wrong day (typically one earlier than the correct date). For > example, in the attached repro.org, work is performed on the 3rd and 5th of > November, but when daily reports are used in the clocktable the work on 5 > November is reported as occurring on 4 November. Reporting 1-4 November and > 5-30 November separately works around the problem. > > In the US, Daylight Savings ended on 4 November; this fact plus a previous > problem (reported here: > https://stackoverflow.com/questions/42821604/why-is-emacs-org-mode-missing-one-date-from-clocktable) > suggests DST is involved. I think something like this was fixed in development branch. Please test it if you can. Regards, -- Nicolas Goaziou
Re: [O] [feature] Handle recurrence in <> and [] dates
>> AFAICT the performance of marking tasks done which contain *a lot* of >> inactive timestams has degraded considerably with this change. >> >> Example: >> >> #v+ >> * TODO task >> SCHEDULED: <2018-11-15 .+1d> >> :PROPERTIES: >> :STYLE:habit >> :LAST_REPEAT: [2018-11-14 16:26] >> :END: >> >> [2018-07-10 Tue 11:29]--[2018-07-10 Tue 12:10] >> [2018-07-09 Mon 15:20]--[2018-07-09 Mon 15:23] >> [2018-07-08 Sun 09:01]--[2018-07-08 Sun 09:20] >> ... >> >> ... >> [2013-07-08 Sun 09:01]--[2013-07-08 Sun 09:20] >> #v- >> >> Sorry for not having digged deeper into this issue yet. > > I think it should now be fixed in master. Could you confirm it? Looks fine to me! Thanks! Ciao, -- Marco
Re: [O] [feature] Handle recurrence in <> and [] dates
Hello, Marco Wahl writes: > AFAICT the performance of marking tasks done which contain *a lot* of > inactive timestams has degraded considerably with this change. > > Example: > > #v+ > * TODO task > SCHEDULED: <2018-11-15 .+1d> > :PROPERTIES: > :STYLE:habit > :LAST_REPEAT: [2018-11-14 16:26] > :END: > > [2018-07-10 Tue 11:29]--[2018-07-10 Tue 12:10] > [2018-07-09 Mon 15:20]--[2018-07-09 Mon 15:23] > [2018-07-08 Sun 09:01]--[2018-07-08 Sun 09:20] > ... > > ... > [2013-07-08 Sun 09:01]--[2013-07-08 Sun 09:20] > #v- > > Sorry for not having digged deeper into this issue yet. I think it should now be fixed in master. Could you confirm it? Thank you. Regards, -- Nicolas Goaziou
Re: [O] [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
On Sat, Nov 17 2018, Mark H Weaver wrote: [...] >> Ah, system* is a scheme call! So yeah, maybe we could add that call to >> Geiser's guile initialization... i don't really see how that would cause >> any problem elsewhere. > > I think something like this should be done, not only in the Guile > initialization, but ideally in the generic Geiser code that connects to > inferior processes via pseudo-tty. After the pseudo-tty is allocated > but before launching the inferior Scheme process, something like "stty > --file=/dev/pts/N -icanon" should be run. > > However, before doing this, some warnings are in order: > > When in noncanonical mode, the normal processing of ERASE (usually DEL > or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, and input > characters are delivered to the subprocess immediately as they are > typed, rather than waiting for the newline as normally happens in > canonical mode. > > At least in the case of the Guile REPL, one notable side effect of > running in noncanonical mode is that when a list is entered at the REPL, > the 'read' returns as soon as the final close parenthesis is entered. > Nothing after that is read, not even the usual newline. The final > newline is only read if the reader is not yet sure that it has finished > reading the token, e.g. if a number or symbol is entered. In those > cases, typically any delimiter may be typed to terminate the read, > e.g. space. > > To see this, you can try running Guile from a traditional terminal > program (e.g. xterm or GNOME Terminal), and type: > > (system* "stty" "-icanon") > > and then: > > (display "hello") > > You will see that as soon as you type that close paren, "hello" is > immediately printed, followed by another REPL prompt, all on the same > line. I think this is not an actual problem in Geiser. In comint mode, the stdin of the Guile process doesn't receive any input bytes until higher level elisp functions send them, and that's totally under our control. Repeating that experiment in a Geiser REPL, nothing is printed before a RET (and, in fact, we might not even send the RET to Guile). > > You might also try (use-modules (ice-9 rdelim)) and then: > > (read-line) > > and you'll see that the newline you type at the end of that line is read > by 'read-line', which then immediately returns the empty string. The > input that you wish for 'read-line' to see must be typed on the same > line, immediately after the close parenthesis. Again, a comint/geiser REPL doesn't have this problem. > So, it might be that Geiser needs to be adjusted somewhat to deal with > these differences. Seems we're lucky enough to be already adjusted :) > Finally, you might consider the possibility that 'stty' might not be > available in PATH, or fails for some reason, and ideally this case > should be handled as well. Yes, that's a real concern. We should at least provide some kind of warning. > It might be simpler to always use REPL servers over a socket, than to > deal with these headaches, although I don't know if that will be an > option for the other Scheme implementations. Not for all of them. For Guile it's doable, but definitely not "simpler", it requires some work and solving some unrelated corner cases; but it might be worth the effort, because it's a cleaner interaction mode (for instance, behaves much better in the presence of multiple threads). Cheers, jao -- Beware of the stories you read or tell; subtly, at night, beneath the waters of consciousness, they are altering your world. -Ben Okri, poet and novelist
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Ihor, I'm not sure I follow your suggestion regarding changing the implementation. But anyhow I don't think the implementation is heavy and at risk of cumbersome code duplication. My opinion ofc I like the idea of a function that would symbolically links folders from "ID"-folder structure to a hierarchy-folder structure, based on the name and path of the org-file and its headings containing the links. I probably wouldn't use it much myself though. Not until org-mode starts working better with multiple files, allowing us to more easily define "org-mode libraries". /G > -Original Message- > From: Ihor Radchenko > Sent: den 3 november 2018 04:38 > To: Gustav Wikström ; Marco Wahl > Cc: emacs-orgmode > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi Gustav, > > Thanks for the patch! > I am a heavy user of org attachments, so it is pleasant that someone > spent a time to implement this useful feature into org. > > A comment regarding the code. > Your new link types appears to reimplement some of the code for the > "file:" links. > Would it make more sense to implement the "attachment:" link type as > abbreviation? > I mean something like the code below: > > > (defun yant/process-att-abbrev (arg) > "Return `org-attach-dir' for the current entry." > (s-concat (org-attach-dir 'CREATE) arg)) > > (add-to-list 'org-link-abbrev-alist (cons "att" > "file:%(yant/process-att-abbrev)")) > > (defun org-att-link-complete ( arg) > "Completion function for att: link." > (let* ((ref-dir (org-attach-dir 'CREATE)) >(filelink (let ((default-directory ref-dir)) >(org-file-complete-link))) >(filepath (apply #'s-concat (cdr (s-split ":" filelink) > (format "att:%s" filepath))) > > (org-link-set-parameters "att" >:complete #'org-att-link-complete) > > > Also, is anyone interested in automatic placing of org attachments into > a folder structure, which mirrors the org path? > Something like in the following Stack Exchange question: > https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org- > attach > > Best, > Ihor > > Gustav Wikström writes: > > > Hi Marco, > > > > Nice to hear you like it! Yeah, I'm pretty happy with that functionality as > > well. Use it > all the time to quickly add links to attached files. > > > > One use case I have for this (as an example) is for projects and tasks. I > > have a > 'tasks.org' file with nodes for each of my tasks and each of my projects. > Usually, if the > task is about some digital work, there are files involved with it. So I have > a convention > to add folders next to the 'tasks.org' file with names like 'YYMM > [task/project title]', > and attach the folder to each task/project node. C-c C-l attached RET then > makes it super- > easy to refer to particular files within that folder, from within the node in > the > 'tasks.org' file! > > > > Another use case is for my 'digital brain', where it's also fairly common > > for me to have > attachment folders where I want to refer to files within them. Images for > example, that > then will be displayed in the org-mode file. Haven't settled on whether I > should use auto- > managed ID's for these folders, or :ATTACH_DIR: properties though. Currently > using a bit > of both... > > > > I'm not familiar with the 'next' branch and the plans for integrating it > > into 'master'. > But if 'master' is to offensive to merge into straight away, 'next' sounds > like a good > option! > > > > Kind regards > > Gustav > > > > -Original Message- > > From: Marco Wahl > > Sent: den 1 november 2018 17:01 > > To: Gustav Wikström > > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > > > The following message is a courtesy copy of an article that has been posted > > to > gmane.emacs.orgmode as well. > > > > Hi Gustav, > > > > I played a bit with your proposition. I like it; in particular the > > completion function > to insert links from the attachment directory with > > > > C-c C-l attached RET > > > > It seems natural to me to have a more specific link type for attached files. > > > > In my opinion your patch should be applied to the 'next' branch. > > > > > > My 2ct, > > Marco > >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Nicolas, Thanks for your detailed comments. Much appreciated. > -Original Message- > From: Nicolas Goaziou > Sent: den 4 november 2018 23:37 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > Hello, > > Gustav Wikström writes: > > > I’ve attached a patch with some suggested additions to org-attach. > > Patch comments below. Please review. > > Thank you. Some comments follow. > > > * Add new linktype "attached" for attachments > > This seem a bit long. Why not "att" links? Yeah - I liked "attached" because I prefer clear keywords. But sure, we can keep it shorter. I'd suggest "@" instead in that case. Patch updated with that. > > > * Add further options for ATTACH_DIR > > > > When working with ATTACH_DIR there are now a couple of new options > > available: > > - org-attach-dir-inherit-by-default > > What is the difference between this and `org-attach-allow-inheritance'? > > > - org-attach-dir-create-if-not-exist > > What is the use-case for this one? It doesn't seem terribly useful at > first glance. If you try to open attachments on a node where there is no ID or ATTACH_DIR, the default behavior is to add an ID and create a folder based on that ID. I would like Org-mode to not do that. This customization give the user the option to change that. Instead of providing this customization one could just change the default behavior of org-attach, since it's a bit offensive to create folders when I didn't ask for it. But instead of changing the default, I thought this way was more graceful. I wouldn't mind skipping this customization though, if the behavior was changed to what I implemented with org-attach-dir-create-if-not-exist set to nil. > > > - org-attach-dir-relative > > I'm not sure to understand this one. When adding folders to nodes using option "s" in org-attach, the path is absolute. This makes attachment-directory paths relative to location of the file instead. > > > > +This list shows the full set of built-in external link types: > > +| http | web | > > +| https | secure web | > > +| doi| DOI for electronic resources| > > +| file | file-links | > > +| file+sys | file-links forced to open via OS| > > +| file+emacs | file-links forced to open via emacs | > > +| attached | links to attachments for nodes | > > +| docview| doc-view mode | > > +| id | Link to heading by id | > > +| news | Usenet link | > > +| mailto | mail link | > > +| mhe| MH-E folder link| > > +| rmail | Rmail link | > > +| gnus | Gnus link | > > +| bbdb | BBDB link | > > +| irc| IRC link| > > +| info | Info link | > > +| shell | shell command | > > +| elisp | interactive elisp command link | > > + > > +The following list shows examples for each link type. > > + > > +| =http://www.astro.uva.nl/=dominik=| on the web > >| > > +| =doi:10.1000/182= | DOI for an electronic > > resource | > > +| =file:/home/dominik/images/jupiter.jpg= | file, absolute path > >| > > +| =/home/dominik/images/jupiter.jpg=| same as above > >| > > +| =file:papers/last.pdf=| file, relative path > >| > > +| =./papers/last.pdf= | same as above > >| > > +| =file:/ssh:me@some.where:papers/last.pdf= | file, path on remote machine > >| > > +| =/ssh:me@some.where:papers/last.pdf= | same as above > >| > > +| =file:sometextfile::NNN= | file, jump to line number > >| > > +| =file:projects.org= | another Org file > >| > > +| =file:projects.org::some words= | text search in Org > > file[fn:28] | > > +| =file:projects.org::*task title= | heading search in Org file > >| > > +| =file+sys:/path/to/file= | open via OS, like > > double-click | > > +| =file+emacs:/path/to/file=| force opening by Emacs > >| > > +| =attached:projects.org= | file in folder attached to > > headline | > > +| =attached:projects.org::some words= | text search in attached file > >| > > +| =docview:papers/last.pdf::NNN=| open in doc-view mode at > > page | > > +| =id:B7423F4D-2E8A-471B-8810-C40F074717E9= | link to heading by ID > >| > > +| =news:comp.emacs=
Re: [O] Local COLUMNS and columnview block
Sorry, hit C-c C-c in the wrong buffer... Lele Gaifax writes: > The local property in the "Work" node is honored by org-columns (C-c C-x > C-c), As said, a the local COLUMNS setting is honored by the transient columns view, but it is ignored by org-clock-report and org-dbclock-update. Am I doing something wrong or isn't it possible? Thank you, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929.
[O] Local COLUMNS and columnview block
Hi all,
I tried to use a local definition of the COLUMNS property and have a "private"
(that is, not exported to PDF) view of the time spent on something, something
like this:
# -*- coding: utf-8 -*-
#+TITLE: Test local columns
#+COLUMNS: %40ITEM(Item) %13Effort(Effort){:}
#+BEGIN: columnview :id global :maxlevel 1 :skip-empty-rows t
| Item| Effort | Spent |
|-++---|
| Preliminary | 1:00 | |
#+END:
* Preliminary
:PROPERTIES:
:Effort: 1:00
:END:
:LOGBOOK:
CLOCK: [2018-11-16 fri 09:40]--[2018-11-16 fri 10:00] => 0:20
:END:
* Soon
:PROPERTIES:
:Effort: 1:00
:END:
:LOGBOOK:
CLOCK: [2018-11-16 fri 11:00]--[2018-11-16 fri 12:00] => 1:00
:END:
#+BEGIN: columnview :id local :indent t :skip-empty-rows t
| Item | Effort |
|--+|
| Soon | 1:00 |
#+END:
* COMMENT Work
:PROPERTIES:
:COLUMNS: %40ITEM(Item) %13Effort(Effort){:} %CLOCKSUM(Spent)
:END:
#+BEGIN: clocktable :scope file :maxlevel 2
#+END:
#+BEGIN: columnview :id global :indent t :skip-empty-rows t
| Item| Effort |
|-+|
| Preliminary | 1:00 |
| Soon| 1:00 |
#+END:
The local property in the "Work" node is honored by org-columns (C-c C-x C-c),
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it | -- Fortunato Depero, 1929.
[O] erroneous clocktable for November 2018 - possible DST problem
Clocktables containing work in November of 2018 are reported incorrectly,
showing the wrong day (typically one earlier than the correct date). For
example, in the attached repro.org, work is performed on the 3rd and 5th of
November, but when daily reports are used in the clocktable the work on 5
November is reported as occurring on 4 November. Reporting 1-4 November and
5-30 November separately works around the problem.
In the US, Daylight Savings ended on 4 November; this fact plus a previous
problem (reported here:
https://stackoverflow.com/questions/42821604/why-is-emacs-org-mode-missing-one-date-from-clocktable)
suggests DST is involved.
Thanks and Regards,
Jeff Trull
Emacs : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.23.2)
of 2018-08-27, modified by Debian
Package: Org mode version 9.1.14 (9.1.14-9-g131531-elpa @
/home/jet/.emacs.d/elpa/org-20181112/)
current state:
==
(setq
org-export-backends '(confluence md latex icalendar html ascii)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-html-format-drawer-function '(closure
(htmlize-buffer-places
org-html-format-table-no-css
htmlize-css-name-prefix
htmlize-output-type htmlize-output-type
htmlize-css-name-prefix t)
(_name contents) contents)
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-duration-format 'h:mm
org-confirm-shell-link-function 'yes-or-no-p
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-latex-format-headline-function
'org-latex-format-headline-default-function
org-latex-listings-options '(("keywordstyle" "\\color{keywordcolor}")
("basicstyle" "\\footnotesize\\ttfamily")
("backgroundcolor" "\\color{backcolor}")
("showstringspaces" "false")
("moredelim"
"**[is][\\only<+>{\\color{black}\\lstset{style=highlight}}]{@}{@}")
("breaklines" "true"))
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-latex-format-drawer-function '(closure (t) (_ contents) contents)
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all
append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
(closure
(org-inlinetask-min-level buffer-face-mode-face
org-struct-menu org-last-state
org-id-track-globally texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula
align-mode-rules-list ffap-url-regexp t)
nil
(add-hook (quote change-major-mode-hook) (quote
org-show-block-all)
(quote append) (quote local))
)
(closure (*this* org-babel-confirm-evaluate-answer-no t)
nil
(add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all)
(quote append) (quote local))
)
(closure
(org-inlinetask-min-level buffer-face-mode-face
org-mode-map org-tbl-menu
org-org-menu org-struct-menu org-entities org-last-state
org-id-track-globally
org-clock-start-time texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula
align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components
org-export-registered-backends org-modules
org-babel-load-languages
org-element-paragraph-separate ffap-url-regexp t)
nil
(add-hook (quote change-major-mode-hook) (quote
org-show-block-all)
(quote append) (quote local))
)
(closure
(org-bracket-link-regexp org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no
org-src-preserve-indentation
