Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
On 2015-04-27 20:46, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Set-up (e.g., link abbreviations) is not refreshed after expanding INCLUDE keywords. I cannot remember why, tho. Maybe for (dubious) efficiency reasons. If you don't remember, may be it would be possible to try it out? Would love it and as a feature it looks natural for an included file! I agree. I added this in 2965f8fb0c048a20b52ba90627e7cca6fe706c93. Thank you. Does this mean that #+INCLUDE is now a superset of #+SETUPFILE (I've had some cases where I needed to do both)? Thanks, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 signature.asc Description: PGP signature
Re: [O] Bug: Priority #B in Agenda causes invalid face reference [8.2.1 (8.2.1-15-ge5cecc-elpa @ /Users/Paul/.emacs.d/elpa/org-20131021/)]
Hello, Yes you are right, i digged deeper in the problem and it seems to be that the cond: (cond ((org-face-from-face-or-color 'priority nil (cdr (assoc p org-priority-faces ((and (listp org-agenda-fontify-priorities) (org-face-from-face-or-color 'priority nil (cdr (assoc p org-agenda-fontify-priorities) ((equal p l) 'italic) ((equal p h) 'bold)) returns nil altogether for priorities which are neither the highest (equal p h) or the lowest (equal p l) (hence the bug appearing on #B priorities by default). That gives (nil . org-priority) so: (overlay-put ov 'face (nil . 'org-priority)) Which triggers the message the second time it runs. From the elisp manual for (overlay-put ... 'face (a-cons . cell)): • A cons cell of the form ‘(foreground-color . COLOR-NAME)’ or ‘(background-color . COLOR-NAME)’. This specifies the foreground or background color, similar to ‘(:foreground COLOR-NAME)’ or ‘(:background COLOR-NAME)’. This form is osupported for backward compatibility only, and should be avoided. Which makes me think the whole cond inside it: (overlay-put ov 'face (cons (cond ...))) is kinda wrong from the start. But i don't know, just guessing because overlay-put is a C function. Anyways, for the ECM: (setq org-priority-faces nil) (setq org-agenda-fontify-priorities 'cookies) (setq org-highest-priority ?A) (setq org-lowest-priority ?C) Create an .org with: * TODO [#B] Test Start the agenda for TODO items with buffer restriction on that file. When it loads and everytime you pass the cursor on the line with the TODO item it gives the message: Invalid face reference: nil I hope that helps, thanks already for looking into it! Renato Ferreira
Re: [O] Marking/highlighting text temporarily
Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Regards, -- Nicolas Goaziou
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@andrew.cmu.edu writes: Eric Abrahamsen writes: John Kitchin jkitc...@andrew.cmu.edu writes: Hi Eric, I added some functions in the attachment. they colorize the comments, add an org-comment menu to the org-menu, and some functions for pop to and delete comments from the list mode, and a hydra for commands to insert comments. Do you want to get this up on github to facilitate developing it? Oh great! Thanks a lot. We are duplicating effort a bit here (but only a bit, I'd also written display/delete functions for the list buffer), so yes, it would be good to coordinate development. I suppose it depends a bit on where this is going to end up: I'm assuming either org/contrib/lisp, or else as an Elpa package. I don't see much difference, except in terms of accessibility to contributors -- I don't have access to the Org repo, but putting it there might get more contributors on balance. As a package only I would have direct access. What do you think? I think on github you can give others direct access, or respond to pull requests. Either way works. Sure, but even if it's on Github, there's still the question of how we make it available to users. That will probably influence how we handle development. If it's in contrib, for instance, it probably just makes more sense for people to send patches to this list. I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Thanks! Eric The hydra thing is interesting -- I wasn't aware of that package. Better not to require it unconditionally though, right? You could make this conditional if hydra is installed. It is sufficiently simple that you could leave it out too. Thanks, Eric Eric Abrahamsen writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- 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 -- 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
Re: [O] navigate between source code blocks
Thanks very much Oleh. Best, Zhihao On 28 Apr 2015, at 08:22, Oleh Krehel ohwoeo...@gmail.com wrote: Hi Zhihao, I’ve got a simple question: how to speed up jumping between code blocks? You might be interested in https://github.com/abo-abo/worf. It allows you to traverse anything that starts with * or #+ with just hjkl keys. See the docs here: http://oremacs.com/worf/README.html. regards, Oleh
Re: [O] org-mode and python pandas
Using the tabulate python module it is possible to have the following
inline workaround:
8888888
#+BEGIN_SRC python :results raw
import pandas as pd
import numpy as np
from tabulate import tabulate
df = pd.DataFrame(np.random.random((4,3)), columns=['A','B','C'])
print(foo)
return(tabulate(df, headers=keys, tablefmt=orgtbl))
#+END_SRC
#+RESULTS:
| |A |B |C |
|---+--+--+--|
| 0 | 0.754799 | 0.492722 | 0.144595 |
| 1 | 0.198475 | 0.417721 | 0.083459 |
| 2 | 0.645011 | 0.444857 | 0.278874 |
| 3 | 0.314883 | 0.7521 | 0.789418 |
8888888
However, this is not optimal, mainly because it pollutes the code block.
Note, that the :results is set to `raw`.
A brief discussion with Dov, yielded the following better workaround:
8888
888
(setq org-babel-python-wrapper-method
def main():
%s
res = main()
if 'pandas.core.frame.DataFrame' in str(type(res)):
from tabulate import tabulate
out = tabulate(res, headers='keys', tablefmt='orgtbl')
else:
out = str(res)
open('%s', 'w').write(out))
8888
888
This allows a nice output of pandas.DataFrame (again when using :results
raw). Unfortunately, this wrapper has no influence in the case when
:session is used. To that end, it is possible to hack
8888
888
(defun org-babel-python-evaluate-session
(session body optional result-type result-params)
Pass BODY to the Python process in SESSION.
If RESULT-TYPE equals 'output then return standard output as a
string. If RESULT-TYPE equals 'value then return the value of the
last statement in BODY, as elisp.
(let* ((send-wait (lambda () (comint-send-input nil t) (sleep-for 0 5)))
(dump-last-value
(lambda
(tmp-file pp)
(mapc
(lambda (statement) (insert statement) (funcall send-wait))
(if pp
(list
import pprint
(format open('%s', 'w').write(pprint.pformat(_))
(org-babel-process-file-name tmp-file 'noquote)))
(list (format _org_tmp = _;
if 'pandas.core.frame.DataFrame' in str(type(_org_tmp)):
from tabulate import tabulate
_org_out = tabulate(_org_tmp, headers='keys', tablefmt='orgtbl')
else:
_org_out = _org_tmp
open('%s', 'w').write(str(_org_out))
(org-babel-process-file-name tmp-file
'noquote)))
(input-body (lambda (body)
(mapc (lambda (line) (insert line) (funcall send-wait))
(split-string body [\r\n]))
(funcall send-wait)))
(results
(case result-type
(output
(mapconcat
#'org-babel-trim
(butlast
(org-babel-comint-with-output
(session org-babel-python-eoe-indicator t body)
(funcall input-body body)
(funcall send-wait) (funcall send-wait)
(insert org-babel-python-eoe-indicator)
(funcall send-wait))
2) \n))
(value
(let ((tmp-file (org-babel-temp-file python-)))
(org-babel-comint-with-output
(session org-babel-python-eoe-indicator nil body)
(let ((comint-process-echoes nil))
(funcall input-body body)
(funcall dump-last-value tmp-file
(member pp result-params))
(funcall send-wait) (funcall send-wait)
(insert org-babel-python-eoe-indicator)
(funcall send-wait)))
(org-babel-eval-read-file tmp-file))
(unless (string= (substring org-babel-python-eoe-indicator 1 -1)
results)
(org-babel-result-cond result-params
results
(org-babel-python-table-or-string results)
8888
888
This works, but I would be surprised if this hack meets org-mode's
standards. Nevertheless, maybe someone would find it useful.
What do you think? How can it be improved?
Best,
Dror
[O] PNG images on Worg not appearing in the browser
Hello, I don't understand why the 2 screenshots I added on Worg (in the following section of `org-hacks.org') do not appear in the browser: --8---cut here---start-8--- *** Where can I find nice themes for HTML export? You can find great looking HTML themes (CSS + JS) at https://github.com/fniessen/org-html-themes, currently: - Bigblow, and [[file:images/org-html-themes/bigblow.png]] - ReadTheOrg, a clone of Read The Docs. [[file:images/org-html-themes/readtheorg.png]] See https://www.youtube.com/watch?v=DnSGSiXYuOk for a demo of the Org HTML theme Bigblow. --8---cut here---end---8--- Link where they should be made visible: http://orgmode.org/worg/org-hacks.html#orgheadline88 The export process seems to run fine, and the links seem right (images are correctly displayed in the Org buffer), and the images are well pushed in the repo!? Any idea what I'm missing? Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] Marking/highlighting text temporarily
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? Because [[comment:X][Y]] is displayed (by default) as Y which can be misleading as X and Y grow out of sync. Perhaps I'm wrong, but I see no point in Y for a comment. Further, nasty stuff is sometimes applied to X such as escaping spaces. In addition, export filters cannot easily be pointed to links (you'd have to make a check on the type of link), and you need a bit more hassle to map over them with org-element etc. Again, that's just my opinion so feel free to ignore it! Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. It's only a concern if you want to advocate for including this in Org 8.3. Cheers, Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). Wow, I just went back and looked at the cite thread. That was bewildering. I don't see a direct connection here, though -- cite was needed for very specific academic purposes, with very clearly-defined needs. Comment is much floppier: good for anything from notes-to-self, to notes-to-editor, to notes-to-no-one. *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. Thanks, Eric
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. But to be honest, I think it sits pretty comfortably on top of what's already available. The only slight awkwardness comes when you'd like a different face for the annotation links (currently solved with John Kitchin's hi-lock trick), and the fact that the link export routines don't have access to the exportation info/plist channels (ie, when exporting an annotation link to ODT, I'd like to be able to give the annotation an author element, but as far as I know I can't get access to that). These aren't major flaws. All that said, I do think this is an important feature that fills a bit of gap in Org. TODOs are fundamental, but they are discrete entities. Those of us who use Org for authoring could use a method of decorating spans of text with pertinent information. As org-comment stands now, the tabular list buffer serves as a pseudo Agenda for text comments: I have been using it, for example, as a way of keeping track of translation problems that I need to resolve. I'll admit I have dreamed of a syntax that looks like: [[body text to annotate][TODO:Look this up on the internet:@work]]. The thought of plugging that in to the existing Agenda machine is exhausting even to contemplate, though. I know we've got inlinetodos. They bug me, though: the absurd number of stars (even if they are invisible), and the fact that you're still not really attaching the TODO to specific text, which is what I want. I know these aren't reasonable objections, but still. Now I wish we'd named it org-annotate. I'm done, Eric
Re: [O] Freemind import
stephen's mailinglist account stephen4mailinglists at gmail.com writes: I have tried Freemind export via ox-freemind and this seems to work well and opens the file in Docear (derived from Freemind/jabref). I wondered if anyone knew of any translation tools to come in the opposite direction from the mindmap format to org mode format? regards Stephen Hi Stephen, I have the same problem - did you find a solution in the meantime? Kind regards Martin
Re: [O] Marking/highlighting text temporarily
Hi,
Eric Abrahamsen e...@ericabrahamsen.net writes:
Just to be clear, you think it fits into the category of
incubation-prior-to-core?
I think inlinetasks/comments that are actually *inline* would be nice!
If anyone thinks that this mechanism warrants actual new Org syntax, I'd
be happy to work on implementing that. But to be honest, I think it sits
pretty comfortably on top of what's already available. The only slight
awkwardness comes when you'd like a different face for the annotation
links (currently solved with John Kitchin's hi-lock trick), and the fact
that the link export routines don't have access to the exportation
info/plist channels (ie, when exporting an annotation link to ODT, I'd
like to be able to give the annotation an author element, but as far
as I know I can't get access to that). These aren't major flaws.
See my other post. In addition you'd need to be able to turn them off via
#+OPTIONS: annotations:nil
I'll admit I have dreamed of a syntax that looks like: [[body text to
annotate][TODO:Look this up on the internet:@work]].
I don't like the example. The ordering is weird. Do the first and the
second bracket need to be tied together? Or would something like this
work:
body text to annotate [todo@work: Look this up on the internet]
Or
[todo@work: Look this up on the internet]{body text to annotate}
[todo@work look this up on the internet: body text to annotate]
—Rasmus
--
With monopolies the cake is a lie!
Re: [O] PNG images on Worg not appearing in the browser
On Wednesday, 29 Apr 2015 at 11:47, Fabrice Niessen wrote: Hello, I don't understand why the 2 screenshots I added on Worg (in the following section of `org-hacks.org') do not appear in the browser: Because the files are not there? Going to http://orgmode.org/worg/images/org-html-themes/bigblow.png directly gives 404 Not Found... The export process seems to run fine, and the links seem right (images are correctly displayed in the Org buffer), and the images are well pushed in the repo!? Any idea what I'm missing? Maybe the publishing process on worg, from repo to web site, doesn't push through .PNG images? -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Cheers, Rasmus -- A page of history is worth a volume of logic
Re: [O] BUG: org-block face not working
Michal Koval koval.m...@gmail.com writes: I see `(defface org-block' in org-faces.el and I see it used it in org.el `org-fontify-meta-lines-and-blocks-1' where the bug probably is. `org-block' face is used for verbatim blocks (e.g, example block) and src blocks without a language specified. If language is specified, fontification mechanism is done with `org-src-font-lock-fontify-block', which doesn't use `org-block' face. It was already the case in maint. Regards,
[O] [Bug?] Link fontification in captions
Hello, A link in a caption: #+CAPTION: [[link]] Initially receives org-link face when I type it. After some action (moving to the next line or saving the buffer), it is redrawn with org-block face. In neither case does [[ and ]] receive the invisibility attribute typically given to links. In both cases, it receives the typical overlay when moused-over. It also exports correctly, which is what I really care about. Could links in captions be given the same treatment as in the rest of the buffer? Regards, Jake
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? I think so. If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. I also think a new syntax is needed. But, please, let's keep it as simple as possible. Regards,
Re: [O] Bug: Priority #B in Agenda causes invalid face reference [8.2.1 (8.2.1-15-ge5cecc-elpa @ /Users/Paul/.emacs.d/elpa/org-20131021/)]
Renato Ferreira renatof...@gmail.com writes: Yes you are right, i digged deeper in the problem and it seems to be that the cond: (cond ((org-face-from-face-or-color 'priority nil (cdr (assoc p org-priority-faces ((and (listp org-agenda-fontify-priorities) (org-face-from-face-or-color 'priority nil (cdr (assoc p org-agenda-fontify-priorities) ((equal p l) 'italic) ((equal p h) 'bold)) returns nil altogether for priorities which are neither the highest (equal p h) or the lowest (equal p l) (hence the bug appearing on #B priorities by default). That gives (nil . org-priority) so: (overlay-put ov 'face (nil . 'org-priority)) Which triggers the message the second time it runs. Indeed. From the elisp manual for (overlay-put ... 'face (a-cons . cell)): • A cons cell of the form ‘(foreground-color . COLOR-NAME)’ or ‘(background-color . COLOR-NAME)’. This specifies the foreground or background color, similar to ‘(:foreground COLOR-NAME)’ or ‘(:background COLOR-NAME)’. This form is osupported for backward compatibility only, and should be avoided. Actually, the function uses the second point: • A list of faces. Each list element should be either a face name or an anonymous face. This specifies a face which is an aggregate of the attributes of each of the listed faces. Faces occurring earlier in the list have higher priority. It should be fixed in c763faf529ef2e8f257a27df29531a4f77d633f5. Thank you for reporting it. Regards,
Re: [O] [PATCH] TINYCHANGE - fix Fix use of org-open-at-point with shell and midnight cleaning
Hello, Luke Amdor luke.am...@gmail.com writes: Subject: [PATCH] org.el: Fix use of org-open-at-point with shell and midnight cleaning * lisp/org.el (org-open-at-point): Make sure org shell output buffer is a string of buffer name before appending to `clean-buffer-list-kill-buffer-names' for cleaning later. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-timer.el: Use hh:mm:ss format instead of minutes
I have took in consideration all of your points, is it better now? The current patch doesn't overwrite the present behavior of org-set-timer it only add the possibility to use hh:mm:ss format. 2015-04-24 18:49 GMT+02:00 Kyle Meyer k...@kyleam.com: Brice Waegenire brice@gmail.com wrote: Hello, I've hacked a patch that use hh:mm:ss format instead of minutes for org-timer-set-timer. I'm really not sure I did it in the right way, any sugestions are welcome. [...] Thanks. I think it's nice to be able to specify seconds, but now you have to type 'N:00' (or at least 'N:0') instead of 'N' to get N minutes. Should a plain number default to minutes? I don't use org-timer very much, so I don't have a strong preference. This seems like a better behavior --- a/lisp/org-timer.el +++ b/lisp/org-timer.el @@ -429,17 +429,14 @@ using three `C-u' prefix arguments. (minutes (or (and (not (equal opt '(64))) effort-minutes (number-to-string effort-minutes)) - (and (numberp opt) (number-to-string opt)) - (and (listp opt) (not (null opt)) - (number-to-string org-timer-default-timer)) By removing the listp check, you no longer get the C-u behavior described in the docstring. I've re-added the C-u functionality, I didn't understood the whole meaning of those lines. + (and (stringp opt) (prin1 opt)) Why not `(and (stringp opt) opt)'? Because I don't really know how to program, but I was already thinking that this prin1 function wasn't the right way do to this. (read-from-minibuffer - How many minutes left? + How many time left? s/many/much/. Also, it'd be nice to specify the format in the prompt. (if (not (eq org-timer-default-timer 0)) - (number-to-string org-timer-default-timer)) + (prin1 org-timer-default-timer)) The defcustom for org-timer-default-timer still says it should be a number. If set to a number other than 0, this will fail. Perhaps org-timer-default-timer should be updated to be a string in the hh:mm:ss format. -- Kyle 2015-04-24 18:49 GMT+02:00 Kyle Meyer k...@kyleam.com: Brice Waegenire brice@gmail.com wrote: Hello, I've hacked a patch that use hh:mm:ss format instead of minutes for org-timer-set-timer. I'm really not sure I did it in the right way, any sugestions are welcome. [...] Thanks. I think it's nice to be able to specify seconds, but now you have to type 'N:00' (or at least 'N:0') instead of 'N' to get N minutes. Should a plain number default to minutes? I don't use org-timer very much, so I don't have a strong preference. --- a/lisp/org-timer.el +++ b/lisp/org-timer.el @@ -429,17 +429,14 @@ using three `C-u' prefix arguments. (minutes (or (and (not (equal opt '(64))) effort-minutes (number-to-string effort-minutes)) - (and (numberp opt) (number-to-string opt)) - (and (listp opt) (not (null opt)) - (number-to-string org-timer-default-timer)) By removing the listp check, you no longer get the C-u behavior described in the docstring. + (and (stringp opt) (prin1 opt)) Why not `(and (stringp opt) opt)'? (read-from-minibuffer - How many minutes left? + How many time left? s/many/much/. Also, it'd be nice to specify the format in the prompt. (if (not (eq org-timer-default-timer 0)) - (number-to-string org-timer-default-timer)) + (prin1 org-timer-default-timer)) The defcustom for org-timer-default-timer still says it should be a number. If set to a number other than 0, this will fail. Perhaps org-timer-default-timer should be updated to be a string in the hh:mm:ss format. -- Kyle From 8d6e379f3ed432511c613a0cf40804d2de1764b8 Mon Sep 17 00:00:00 2001 From: Brice Waegeneire brice@gmail.com Date: Fri, 24 Apr 2015 14:18:45 +0200 Subject: [PATCH] org-timer.el: hh:mm:ss format for setting a timer * lisp/org-timer.el (org-timer-set-timer): Add support for hh:mm:ss format. * testing/lisp/test-org-timer.el (test-org-timer/set-timer): Add hh:mm:ss format in the test. --- lisp/org-timer.el | 23 --- testing/lisp/test-org-timer.el | 8 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/lisp/org-timer.el b/lisp/org-timer.el index 0593573..022125f 100644 --- a/lisp/org-timer.el +++ b/lisp/org-timer.el @@ -65,12 +65,12 @@ the value of the timer. :group 'org-time :type 'string) -(defcustom org-timer-default-timer 0 - The default timer when a timer is set. +(defcustom org-timer-default-timer 0 + The default timer when a timer is
Re: [O] [Bug?] Link fontification in captions
Hello, Jacob Gerlach jacobgerl...@gmail.com writes: A link in a caption: #+CAPTION: [[link]] Initially receives org-link face when I type it. I cannot reproduce this. After some action (moving to the next line or saving the buffer), it is redrawn with org-block face. I can't remember why it is `org-block' instead of `org-meta-line', like #+caption. In neither case does [[ and ]] receive the invisibility attribute typically given to links. This is done on purpose, actually. In both cases, it receives the typical overlay when moused-over. It also exports correctly, which is what I really care about. Could links in captions be given the same treatment as in the rest of the buffer? This is quite tricky. Meta line face overrides link face. Underlining disappears. If link becomes invisible you cannot distinguish it anymore from regular text. As a safety measure, links are displayed in full. Regards, -- Nicolas Goaziou
[O] [PATCH] TINYCHANGE - fix Fix use of org-open-at-point with shell and midnight cleaning
Patch is attached. I was running into this when I'd run a shell script through an org link and later a clean-buffers would run. Thanks! 0001-org.el-Fix-use-of-org-open-at-point-with-shell-and-m.patch Description: Binary data
Re: [O] Marking/highlighting text temporarily
Hello all, I have been following this whole thread with great interest, having posted very early on the use of inline tasks as a solution for the OP. I use inline tasks a lot for both annotations and for TODO tasks when writing papers. I like the link syntax proposed but would much prefer something that includes tasks as well as comments. What is missing, by the way, with the proposed link based comment syntax that inline tasks give is the ability to find them quickly within a (large) document. Maybe I missed this functionality in what has been proposed. Inline tasks are easy to find using C-c / t... And to add to yet another element of the discussion, I have no problem with the [[comment:X][Y]] in the sense of X being hidden in normal view. Back to your regular programming :) thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
I think it could benefit from a dedicated syntax in the following context: There are different types of annotation you might like, e.g. delete, insert, replace, comment (I am drawing from ideas of annotations in PDF, and the idea of track changes). In multi-author documents you might want to know who wrote the annotation, and when. Finally, you might want some way to mark that the annotation has been seen. These might be stand-alone or attached to text. To follow something like the cite syntax, here is an example that shows a comment type, author, timestamp, checked status, and content. I have not thought about how these would be displayed much except that you would almost always want an overlay to hide most of this, and show only the important stuff with an appropriate face (e.g. crossout for delete, ^^ for insert, tooltip for comment, +old text+=new text=, etc... [@annote :type comment :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :content This is just a comment] [@annote :type insert :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :content some new content] [@annote :type delete :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :old-content Some words to delete] [@annote :type replace :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :old-content This is just a comment :new-content replacement text] Most of this information would be inserted by emacs, not by the author. Eric is right about the functionality provided to create and manipulate these annotations. Maybe some kind of minor mode to enable what could act like track changes, with commands to accept or reject the changes, etc... I would use this a lot with my students in writing papers. Eric Abrahamsen writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. But to be honest, I think it sits pretty comfortably on top of what's already available. The only slight awkwardness comes when you'd like a different face for the annotation links (currently solved with John Kitchin's hi-lock trick), and the fact that the link export routines don't have access to the exportation info/plist channels (ie, when exporting an annotation link to ODT, I'd like to be able to give the annotation an author element, but as far as I know I can't get access to that). These aren't major flaws. All that said, I do think this is an important feature that fills a bit of gap in Org. TODOs are fundamental, but they are discrete entities. Those of us who use Org for authoring could use a method of decorating spans of text with pertinent information. As org-comment stands now, the tabular list buffer serves as a pseudo Agenda for text comments: I have been using it, for example, as a way of keeping track of translation problems that I need to resolve. I'll admit I have dreamed of a syntax that looks like: [[body text to annotate][TODO:Look this up on the internet:@work]]. The thought of plugging that in to the existing Agenda machine is exhausting even to contemplate, though. I know we've got inlinetodos. They bug me, though: the absurd number of stars (even if they are invisible), and the fact that you're still not really attaching the TODO to specific text, which is what I want. I know these aren't reasonable objections, but still. Now I wish we'd named it org-annotate. I'm done, Eric -- 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
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen writes: Rasmus ras...@gmx.us writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). Wow, I just went back and looked at the cite thread. That was bewildering. I don't see a direct connection here, though -- cite was needed for very specific academic purposes, with very clearly-defined needs. Comment is much floppier: good for anything from notes-to-self, to notes-to-editor, to notes-to-no-one. *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? The only reason I can see (coming from someone who uses links liberally for other purposes ;) is just to avoid the hacks required to get extra functionality, e.g. as you alluded to applying different faces, storing additional information (author, timestamp, etc...), avoiding a need to add a link type-checking for collecting comments (although, this is not a very difficult step). On the link side, they work perfectly well for the simplest kind of comment, and because of that, there is a working prototype already. But, I think extending it beyond this will require the hackery described above. I don't have a sense if it is more work than defining a new syntax, or the long term maintenance costs of that approach. For me, it is work I already know how to do. I admit though, that does not mean it is better than a new syntax ;) Maybe a study of the cite syntax code would clarify the differences. Can anyone point me to a code repository where we could read that code? On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. Thanks, Eric -- 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
Re: [O] Marking/highlighting text temporarily
Eric S Fraga writes: Hello all, I have been following this whole thread with great interest, having posted very early on the use of inline tasks as a solution for the OP. I use inline tasks a lot for both annotations and for TODO tasks when writing papers. I like the link syntax proposed but would much prefer something that includes tasks as well as comments. What is missing, by the way, with the proposed link based comment syntax that inline tasks give is the ability to find them quickly within a (large) document. Maybe I missed this functionality in what has been proposed. Inline tasks are easy to find using C-c / t... There is in org-comment a command `org-comment-display-comments' which will generate a buffer you can see all the comments in, and from that pop to a comment, delete it, etc... And to add to yet another element of the discussion, I have no problem with the [[comment:X][Y]] in the sense of X being hidden in normal view. Back to your regular programming :) thanks, eric -- 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
Re: [O] org-latex question
You have num:2, so subsubsections are not TOC'ed, so they don't get the alternative. If you set it to 3, all should work. That is what we have been discussing. There are situations where you do not want a headline to appear in TOC, but still want the ALT_TITLE used. It is now possible in org-mode, but there was some bug because of which it did not always work. I figured I was missing something, but I have a question (which means I'm still missing something :-) : what are ALT_TITLEs good for if not for the TOC? I think some styles put them in the header, regardless of TOC. Also needed if you need to add a footnote to a section heading. Vikas
Re: [O] Marking/highlighting text temporarily
On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote: [...] Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? [...] Now I wish we'd named it org-annotate. Is it too late? Simple refactoring of the code? I find org-annotate more expressive of its purpose and doesn't conflict with e.g. org-toggle-comment... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Rasmus writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? Because [[comment:X][Y]] is displayed (by default) as Y which can be misleading as X and Y grow out of sync. Perhaps I'm wrong, but I see no point in Y for a comment. Further, nasty stuff is sometimes applied to X such as escaping spaces. In addition, export filters cannot easily be pointed to links (you'd have to make a check on the type of link), and you need a bit more hassle to map over them with org-element etc. Again, that's just my opinion so feel free to ignore it! I would mostly use comments in a transient way during an editing process. e.g. I expect my students to delete my comments after they have addressed them, otherwise, they are out of sync. The only point of Y in the syntax above is to attach the comment to the text as opposed to just having an inline comment. There could be reasons to want super good export, but my main use case is in collaborative editing of org-source, and i would expect in the final version for there to be no remaining comments. There are still reasons to have annotations present, e.g. as tooltips, or file attachments in exported content though, so your point is a good one that funny things may happen with a link type solution. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. It's only a concern if you want to advocate for including this in Org 8.3. Cheers, Rasmus -- 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
Re: [O] Marking/highlighting text temporarily
On Wednesday, 29 Apr 2015 at 10:00, John Kitchin wrote: [...] There is in org-comment a command `org-comment-display-comments' which will generate a buffer you can see all the comments in, and from that pop to a comment, delete it, etc... Ah, thanks. That's good. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] [PATCH] org-timer.el: Use hh:mm:ss format instead of minutes
Brice Waegenire brice@gmail.com wrote: I have took in consideration all of your points, is it better now? The current patch doesn't overwrite the present behavior of org-set-timer it only add the possibility to use hh:mm:ss format. Thanks. From 8d6e379f3ed432511c613a0cf40804d2de1764b8 Mon Sep 17 00:00:00 2001 From: Brice Waegeneire brice@gmail.com Date: Fri, 24 Apr 2015 14:18:45 +0200 Subject: [PATCH] org-timer.el: hh:mm:ss format for setting a timer * lisp/org-timer.el (org-timer-set-timer): Add support for hh:mm:ss format. * testing/lisp/test-org-timer.el (test-org-timer/set-timer): Add hh:mm:ss format in the test. Minor: ChangeLog lines tend to be filled at around 72 characters. [...] (read-from-minibuffer - How many minutes left? + How much time left? (minutes or h:mm:ss) (if (not (eq org-timer-default-timer 0)) - (number-to-string org-timer-default-timer)) + (eval org-timer-default-timer)) The defcustom for org-timer-default-timer now specifies a string and is set to 0, so `(not (eq org-timer-default-timer 0))` will return t for the default value of org-timer-default-timer. Something like (and (not (string= org-timer-default-timer 0)) org-timer-default-timer) would be needed to keep the old behavior (i.e., only insert the value of org-timer-default-timer as the initial prompt input if the user has changed it). +(if (string-match ^[0-9]+$ minutes) + (setq minutes (concat minutes :00))) Minor: `when` could be used here. Aside from that, this looks good to me. Thoughts from Nicolas or others?
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? I think so. If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. I also think a new syntax is needed. But, please, let's keep it as simple as possible. We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? From what I can tell, rasmus seems to be proposing an in-text TODO, while John's headed in the direction of replicating Track Changes functionality. I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Assuming we're just talking about annotations on steriods, here are some things I'd personally like to have: 1. Annotations attached to arbitrary text in the buffer. The buffer text should be visible, the annotation data invisible (basically the way links work right now). 2. Plain annotation: just a chunk of free-form paragraph text that is attached to the buffer text. 3. Replacement text: an alternate version of the buffer text; this could be the basis of track changes stuff. 4. Timestamps 5. Custom highlighting 6. Full element status: this would allow parsing of the various properties, and more fully-featured export options. 7. Author metadata would probably be unnecessary with full access to the export channels, but it might still be desirable. 8. Options-line switches to export with annotation, export without annotation, and export using replacement text. That's all I can think of, just trying to get the ball rolling. I don't have any opinions about actual syntax, though something with curly braces might be nice. Eric
[O] Continuing a numbered list
Can't figure this out from the org mode manual. I want to use org mode for doing math assignments. This will be a lot easier than using latex directly, I think. But, I want to use numbered lists in org mode, and often there are multiple paragraphs that belong under one list item. I want to be able to use org mode tables instead of latex tabular, and these tables sometimes appear in the middle of a bunch of paragraphs under a single list item. I know how to get multiple paragraphs in one numbered list item. But how can I stick a table in the middle of my multiple-paragraph list item without terminating the list? Such as: 1. blah blah\\ yatta yatta | m | n | foo | |---+---+-| | x | y | z | and this text should be part of item 1. That is the real problem - a paragraph AFTER the table which should belong to item 1. 2. This is the next item. I could use a cookie here to force start at 2, I know. TIA. Best, Jake.
[O] Numbering only *some* subheadings?
I would like to number only a single subset of subheadings in an html export, so that, e.g., * Introduction lorem ipsum * Coiurse Requirements lorem ipsum * Course Outline ** Introduction some long multi paragraph text. ** Origins of the French Revolution more text. Readings. ** Liberty, Equality, Fraternity? ... etc becomes: Introduction Course Requirements Course Outline 1. Introduction bla bla bla 2. Origins of hte French Revolution bla bla bla. Readings: bla bla bla 3. Liberty, Eaquality, Fraternity ... etc Is this possible? Anyone have a suggestion? Thanks as always, Matt
Re: [O] BUG: org-block face not working
On 04/29/15 12:26 PM, Nicolas Goaziou wrote: Michal Koval koval.m...@gmail.com writes: I see `(defface org-block' in org-faces.el and I see it used it in org.el `org-fontify-meta-lines-and-blocks-1' where the bug probably is. `org-block' face is used for verbatim blocks (e.g, example block) and src blocks without a language specified. If language is specified, fontification mechanism is done with `org-src-font-lock-fontify-block', which doesn't use `org-block' face. It was already the case in maint. I have just tried the latest maint version and it works as I described in my first mail. The background specified in `org-block' is applied to the language named begin_src blocks, too. The language specific fontification of the foreground faces is applied as well. I really like the feature. In the master branch it works only for unnamed begin_src blocks (and quote, verbatim, and example). I like the behavior of the maint better, but in case that `org-block' was really meant to apply only to unnamed src blocks + quote, verbatim and example, please change the documentation string of the `org-block' from Face text in #+begin ... #+end blocks. to something more descriptive. Is it possible to change the background of the src blocks in a different way? Thank you, best regards, Michal
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes:
Hi,
Eric Abrahamsen e...@ericabrahamsen.net writes:
Just to be clear, you think it fits into the category of
incubation-prior-to-core?
I think inlinetasks/comments that are actually *inline* would be nice!
If anyone thinks that this mechanism warrants actual new Org syntax, I'd
be happy to work on implementing that. But to be honest, I think it sits
pretty comfortably on top of what's already available. The only slight
awkwardness comes when you'd like a different face for the annotation
links (currently solved with John Kitchin's hi-lock trick), and the fact
that the link export routines don't have access to the exportation
info/plist channels (ie, when exporting an annotation link to ODT, I'd
like to be able to give the annotation an author element, but as far
as I know I can't get access to that). These aren't major flaws.
See my other post. In addition you'd need to be able to turn them off via
#+OPTIONS: annotations:nil
I'll admit I have dreamed of a syntax that looks like: [[body text to
annotate][TODO:Look this up on the internet:@work]].
I don't like the example. The ordering is weird. Do the first and the
second bracket need to be tied together? Or would something like this
work:
body text to annotate [todo@work: Look this up on the internet]
Or
[todo@work: Look this up on the internet]{body text to annotate}
[todo@work look this up on the internet: body text to annotate]
Okay, so you're basically proposing taking this to a much higher level.
I'm totally in favor, in principle, and don't actually care too much
what the actual syntax looks like. I do think it would be important to
specify the text being annotated, so your first example above wouldn't
be too ideal. The others I'd be happy with.
As the veteran of several small projects that have died of mission
creep, I still wouldn't mind keeping org-comments (I do think it should
be renamed org-annotate) as-is, and letting the real inline todo
project progress separately.
Eric
Re: [O] Marking/highlighting text temporarily
Eric S Fraga e.fr...@ucl.ac.uk writes: On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote: [...] Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? [...] Now I wish we'd named it org-annotate. Is it too late? Simple refactoring of the code? I find org-annotate more expressive of its purpose and doesn't conflict with e.g. org-toggle-comment... No, it's definitely not too late. Depending on the outcome of this whole conversation, I'd like to rename it.
Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
Hello, Alan Schmitt alan.schm...@polytechnique.org writes: Does this mean that #+INCLUDE is now a superset of #+SETUPFILE (I've had some cases where I needed to do both)? No, it isn't. INCLUDE are expanded only during export. SETUPFILE are read whenever you open a document or use C-c C-c on a keyword. Regards, -- Nicolas Goaziou
