Re: [O] org-image-actual-width has no effect
Claudius Mueller writes: > Thanks for trying to help! I really appreciate that! > > (image-type-available-p 'imagemagick) ==> output: "t" > org-image-actual-width ==> output: "10" > > I had set org-image-actual-width to 10 in the .emacs file to make sure > I really notice the difference once the problem is solved. > OK - this looks correct. Inline images work by creating an overlay on a portion of a text, and then giving the overlay a property (a key-value pair) where the key is 'display and the value is an image. The following is a minimal example (you'll have to change the path to the image of course to suit your situation). If you execute the first code block with C-c C-c, you should see the image replacing the word "foo"; executing the second code block should get rid of the overlay and let you see "foo" again. Changing the width (but not too much: from 50 to 100 and back should work, but larger overlays tend to make the buffer visually a mess because the code is not robust enough - you can always recover by killing the buffer and revisiting the file) and reexecuting the first code block should give you an image with the new width: --8<---cut here---start->8--- foo #+BEGIN_SRC emacs-lisp :results none (setq ov (make-overlay 1 4)) (overlay-put ov 'display (create-image "/home/nick/src/org/inline/hello-world.png" 'imagemagick nil :width 50)) #+END_SRC #+BEGIN_SRC emacs-lisp :results none (delete-overlay ov) #+END_SRC --8<---cut here---end--->8--- In any case, the experiment takes org out of the picture, so if it works by itself then there is probably a problem with your org-mode. If it doesn't work, then there is something more basic that's busted. -- Nick
[O] Org habit graph can't see
I can't see graph in org-agenda. At the moment, I only have one entry from todo to done - is one entry too little information to develop graph and will it develop later as I put in more entries? * Habits *** TODO Do dishes SCHEDULED: <2014-08-31 Sun +1d> - State "DONE" from "TODO" [2014-08-30 Sat 12:09] :PROPERTIES: :STYLE:habit :LAST_REPEAT: [2014-08-30 Sat 12:09] :END:
Re: [O] org-image-actual-width has no effect
Thanks for trying to help! I really appreciate that! (image-type-available-p 'imagemagick) ==> output: "t" org-image-actual-width ==> output: "10" I had set org-image-actual-width to 10 in the .emacs file to make sure I really notice the difference once the problem is solved. Claudius On 08/29/2014 06:27 PM, Nick Dokos wrote: Claudius Mueller writes: I tried your file - but whatever I do the images are shown the same size. I also had to manually paste in ditaa.jar because my compiled emacs version (24.3) that includes org does not include the contributed org scripts. ditaa was just a quick way for me to get an image. It does not matter how you get the image, as long as you have one. I guess I'm at my wits end. Don't give up yet! Can you evaluate this and post the result? (image-type-available-p 'imagemagick) C-x C-e at the end of the line will evaluate the expression. Also evaluate org-image-actual-width just to make sure that the value is correct. -- Nick
Re: [O] org-image-actual-width has no effect
Claudius Mueller writes: > I tried your file - but whatever I do the images are shown the same > size. I also had to manually paste in ditaa.jar because my compiled > emacs version (24.3) that includes org does not include the > contributed org scripts. > ditaa was just a quick way for me to get an image. It does not matter how you get the image, as long as you have one. > I guess I'm at my wits end. > Don't give up yet! Can you evaluate this and post the result? (image-type-available-p 'imagemagick) C-x C-e at the end of the line will evaluate the expression. Also evaluate org-image-actual-width just to make sure that the value is correct. -- Nick
Re: [O] org-image-actual-width has no effect
I tried your file - but whatever I do the images are shown the same size. I also had to manually paste in ditaa.jar because my compiled emacs version (24.3) that includes org does not include the contributed org scripts. I guess I'm at my wits end. Thank you, Claudius On 08/29/2014 10:43 AM, Nick Dokos wrote: Claudius Mueller writes: Thank you for pointing this out. I compiled emacs 24.3 with imagemagick support: "ldd /usr/local/bin/emacs | grep Magick" > libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x7f3946278000) libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x7f3945dd9000) However, inline images are still not scaled at all if I include: (setq org-image-actual-width 50) in my .emacs file. Any other ideas of what I am doing wrong? Maybe check your *Messages* buffer for errors? FWIW, it works fine here with the following file: --8<---cut here---start->8--- * Inline images This is a test: [[file:hello-world.png]] #+BEGIN_SRC ditaa :file hello-world.png :cmdline -r +--+ | | | Hello World! | | | +--+ #+END_SRC #+RESULTS: [[file:hello-world.png]] * image width #+BEGIN_SRC emacs-lisp (setq org-image-actual-width 50) #+END_SRC #+BEGIN_SRC emacs-lisp (setq org-image-actual-width 500) #+END_SRC --8<---cut here---end--->8--- Depending on which emacs-lisp source block I evaluate, when I do C-c C-x C-v afterwards, I get small images or large images. Version info: Fedora 20 GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of 2014-08-11 Org-mode version 8.3beta (release_8.3beta-270-g4dd9f3.dirty @ /home/nick/elisp/org-mode/lisp/) Nick Thank you very much for your help! Claudius On 08/28/2014 07:50 PM, Charles Philip Chan wrote: On 28 Aug 2014, claudius.muel...@gmail.com wrote: I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs myself, but the core imagemagick libraries are part of the dependencies, which makes me assume that it's been compiled with imagemagick support. No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as, this is the output of my self-compiled version. ,[ ldd /usr/local/bin/emacs | grep Magick ] | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x7fe7e8072000) | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x7fe7e7bd3000 ` I can display inline images of several file types just fine (tif, png, gif, ...). This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc. Charles
Re: [O] org-ref "no key found"
Hi John, No, they still do not work even after I click on the bibliography link and get my .bib file opened. Julian John Kitchin writes: > "Julian M. Burgos" writes: > > If you click on the bibliography link to open the file, and then go back > to your org-file, do the cite links work? > > I suspect the notes problem is related to the no key found problem. > >> Hello everyone, >> >> I am playing around with Joh Kitchin's excellent org-ref, and I am >> having a few issues. In my .emacs file I have set up the values for the >> org-ref-bibliography-notes, org-ref-default-bibliography, and >> org-ref-pdf-directory. >> >> With this I can access my .bib database and use org-ref-insert-cite link >> to add a citation link with no problems. But when I press enter on the >> cite link, I get the following message: >> >> no key found >> (No key found) (p)df (u)rl (n)otes (q) quit >> >> If I press "p" I get the pdf file, but if I press "n" I get the >> following message: >> >> "Wrong type argument: stringp, nil". >> >> Any ideas how to solve this? >> >> Many thanks, >> >> Julian -- Julian Mariano Burgos, PhD Hafrannsóknastofnun/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is
Re: [O] org-ref "no key found"
"Julian M. Burgos" writes: If you click on the bibliography link to open the file, and then go back to your org-file, do the cite links work? I suspect the notes problem is related to the no key found problem. > Hello everyone, > > I am playing around with Joh Kitchin's excellent org-ref, and I am > having a few issues. In my .emacs file I have set up the values for the > org-ref-bibliography-notes, org-ref-default-bibliography, and > org-ref-pdf-directory. > > With this I can access my .bib database and use org-ref-insert-cite link > to add a citation link with no problems. But when I press enter on the > cite link, I get the following message: > > no key found > (No key found) (p)df (u)rl (n)otes (q) quit > > If I press "p" I get the pdf file, but if I press "n" I get the > following message: > > "Wrong type argument: stringp, nil". > > Any ideas how to solve this? > > Many thanks, > > Julian -- --- John Kitchin Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu
Re: [O] org-indent-mode and erratic checkbox behavior?
Hello, Just for completeness purpose, if someone else comes across the same behavior and does the same wrong judgment. There is an issue opened about it on git-gutter - "with org mode, the indention is dancing around crazily" - https://github.com/syohex/emacs-git-gutter/issues/24. Cheers, ardumont writes: > Hello again, > >> I assume (but I can be wrong, thus feel free to correct me): > > And yes I were. > >> (I am unable to understand the reasons it does for some and not for >> others) > > Ok, so sorry for the noise. Now I do. > > I kept looking and I believe that it's 2 minor modes that do not like to work > with each other. > > git-gutter and org-indent. > > When no modification (git) on the current buffer, everything is good - > org/org-indent does as expected. > > When modifications if present, git-gutter add some information on the > left border and this messes around somehow with org-indent which then > does as described in the first part. > > In any case, no worry for the org team :D then. > > Again, apologies. > > Cheers, > Antoine > > ardumont writes: > >> Hello, >> >> I have a minor visual annoyance with checkboxes and `org-indent-mode`. >> As I move to next/previous line, headlines stay still (ok) but checkbox >> keeps going forward and backward (2 blank spaces). >> (I did not change the default binding C-n/C-p which are still bind to the >> default next-line/previous-line.) >> >> I assume (but I can be wrong, thus feel free to correct me): >> - it's not correct behavior because it does not do it to every checkbox (I >> am unable to understand the reasons it does for some and not for others) >> - it's org-indent minor-mode which does this because when deactivated, >> this behavior disappears >> >> An example can be worth more than trying to explain so I'll do my best to >> describe what I see (I'll use '|' as the caret) : >> >> - On header first character: >> #+begin_src org >> | IN-PROGRESS 0.5.6 [0%] >> - [ ] backlog >> #+end_src >> >> - C-n - move to the next line in the first character indented in the list >> #+begin_src org >> * IN-PROGRESS 0.5.6 [0%] >> | [ ] backlog >> #+end_src >> >> - C-n - move to the next line and here the first line `loses` its indentation >> #+begin_src org >> * IN-PROGRESS 0.5.6 [0%] >> - [ ] backlog >> | [ ] Update version >> - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of >> line in checkbox, we need to do it twice, fix. >> #+end_src >> >> - C-n - move to the next line and here the first previous `loses` its >> indentation too >> #+begin_src org >> * IN-PROGRESS 0.5.6 [0%] >> - [ ] backlog >> - [ ] Update version >> | [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of >> line in checkbox, we need to do it twice, fix. >> #+end_src >> >> - C-p - move to the previous line, the indentation does not change >> #+begin_src org >> * IN-PROGRESS 0.5.6 [0%] >> - [ ] backlog >> | [ ] Update version >> - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of >> line in checkbox, we need to do it twice, fix. >> #+end_src >> >> - C-p - move to the previous line, the indentation does not change but the >> indentation from the line I came from gets back >> #+begin_src org >> * IN-PROGRESS 0.5.6 [0%] >> | [ ] backlog >> - [ ] Update version >> - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of >> line in checkbox, we need to do it twice, fix. >> #+end_src >> >> - C-p - move to the previous line, the indentation does not change >> #+begin_src org >> | IN-PROGRESS 0.5.6 [0%] >> - [ ] backlog >> - [ ] Update version >> - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of >> line in checkbox, we need to do it twice, fix. >> #+end_src >> >> *Note* >> - source of the org file: >> https://github.com/ardumont/org-trello/blob/0.5.6/TODO.org >> - The same behavior is seen if the caret is elsewhere than the first >> character, only the position changes but the behavior stays. >> - org-indent-mode is cool, I'd like to keep it since I like the heading >> display rendering. >> >> Some more information you may wish: >> - emacs-version: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version >> 2.24.23) of 2014-06-06 on localhost >> - org-version: Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @ >> /home/tony/.emacs.d/elpa/org-20140811/) >> - minor-mode activated in org buffer >> (M-x describe-mode RET >> Enabled minor modes: Anzu Auto-Composition Auto-Compression >> Auto-Encryption Blink-Cursor Buffer-Pack Column-Number >> Company Delete-Selection Diff-Auto-Refine Erc-Spelling Erc-Track >> Erc-Truncate Eval-Sexp-Fu-Flash File-Name-Shadow >> Flx-Ido Font-Lock Git-Pack Global-Anzu Global-Auto-Revert >> Global-Buffer-Pack Global-Company Global-Diff-Hl >> Global-Flycheck Global-Font-Lock Global-Git-Gutter Global-Git-Pack >> Global-Hl-Line Global-Page-Break-Lines >> Global-Theme-Pack Global-Undo-Tree Guide-Key Id
Re: [O] [babel-R][RFC] Customizing the R prompt for babel sessions approach, advice, discussion
Gotcha thanks for explaining that because I didn't understand how it would fix it and just wanted to communicate my intent here. Love that we can make customizations and am sure to enjoy the end result of that discussion. Grant Rettke | ACM, ASA, FSF g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson On Thu, Aug 28, 2014 at 12:12 AM, Aaron Ecay wrote: > Hi Grant, > > 2014ko abuztuak 27an, Grant Rettke-ek idatzi zuen: > > [...] > >> >> Question: >> • What do you think of such a change? >> • Do you have a desired approach? >> • Would you like a patch? >> • My change would be really basic, just add a new defcustom to store >> the regex and reference it in the session evalution function > > I think this patch will be made superfluous by the approach that Charles > Berry and I are working on in the thread I linked in my response to your > previous email (with useful contributions also from others). Babel will > no longer need to know about the user’s prompt customizations (or lack > thereof) at all. > > It’s taking a little bit for me to digest the discussion in that thread, > but I hope that if you can live with your local modifications a bit > longer you will be pleased with the end result. > > -- > Aaron Ecay
Re: [O] make orgtbl-ascii-plot easier to install
Le 29/08/2014 11:54, Nicolas Goaziou a écrit : > > Patch applied (with tiny changes to comments formatting, and a few > trailing whitespaces). > Great! I will now write a few words of documentation. This page [[info:org#Org-Plot]] seems to be the right place, unless someone has a better idea.
[O] Debug (ox-odt): No OpenDocument schema files installed
I'm trying to set up the odt exporter which is disabled by default. After loading the exporter with: (require 'ox-odt) I got the message about missing files. I inspected the org-odt-data-dir and found that it points to non-existant directory. So I did: (setq org-odt-data-dir "/usr/share/emacs/24.3/etc/org") (the directory with the proper xml files) before loading the ox-odt library. The result did not changed. I still got the message about missing files. I use emacs-24.3.1 and org-mode-8.2.7b from Debian repositories. What am I doing wrong? (Or is it disabled by default because it's broken?) Thanks ahead.
[O] org-ref "no key found"
Hello everyone, I am playing around with Joh Kitchin's excellent org-ref, and I am having a few issues. In my .emacs file I have set up the values for the org-ref-bibliography-notes, org-ref-default-bibliography, and org-ref-pdf-directory. With this I can access my .bib database and use org-ref-insert-cite link to add a citation link with no problems. But when I press enter on the cite link, I get the following message: no key found (No key found) (p)df (u)rl (n)otes (q) quit If I press "p" I get the pdf file, but if I press "n" I get the following message: "Wrong type argument: stringp, nil". Any ideas how to solve this? Many thanks, Julian -- Julian Mariano Burgos, PhD Hafrannsóknastofnun/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is
Re: [O] org-image-actual-width has no effect
Claudius Mueller writes: > Thank you for pointing this out. I compiled emacs 24.3 with > imagemagick support: > > "ldd /usr/local/bin/emacs | grep Magick" > > libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 > (0x7f3946278000) > libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 > (0x7f3945dd9000) > > However, inline images are still not scaled at all if I include: > > (setq org-image-actual-width 50) > > in my .emacs file. > > Any other ideas of what I am doing wrong? > Maybe check your *Messages* buffer for errors? FWIW, it works fine here with the following file: --8<---cut here---start->8--- * Inline images This is a test: [[file:hello-world.png]] #+BEGIN_SRC ditaa :file hello-world.png :cmdline -r +--+ | | | Hello World! | | | +--+ #+END_SRC #+RESULTS: [[file:hello-world.png]] * image width #+BEGIN_SRC emacs-lisp (setq org-image-actual-width 50) #+END_SRC #+BEGIN_SRC emacs-lisp (setq org-image-actual-width 500) #+END_SRC --8<---cut here---end--->8--- Depending on which emacs-lisp source block I evaluate, when I do C-c C-x C-v afterwards, I get small images or large images. Version info: Fedora 20 GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of 2014-08-11 Org-mode version 8.3beta (release_8.3beta-270-g4dd9f3.dirty @ /home/nick/elisp/org-mode/lisp/) Nick > Thank you very much for your help! > Claudius > > On 08/28/2014 07:50 PM, Charles Philip Chan wrote: >> On 28 Aug 2014, claudius.muel...@gmail.com wrote: >> >>> I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs >>> myself, but the core imagemagick libraries are part of the >>> dependencies, which makes me assume that it's been compiled with >>> imagemagick support. >> No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick >> support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as, >> this is the output of my self-compiled version. >> >> ,[ ldd /usr/local/bin/emacs | grep Magick ] >> | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 >> (0x7fe7e8072000) >> | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 >> (0x7fe7e7bd3000 >> ` >> >>> I can display inline images of several file types just fine (tif, png, >>> gif, ...). >> This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc. >> >> Charles >> > > > -- Nick
Re: [O] [ANN] Merge export-block type within special-block
Hi Nicolas, This is nice, but it brought a bug, `[N]' in HTML block is recognized as footnote, e.g.: #+BEGIN_HTML ONE[1] console.log(v1[0]); #+END_HTML There are two footnotes in the generated HTML. Would you fix this please? Thanks. On Sun, Jul 27, 2014 at 8:37 PM, Nicolas Goaziou wrote: > Hello, > > Export blocks are blocks dedicated to export back-ends, e.g., > "#+BEGIN_LATEX". The way they are currently parsed is flawed. > > Export blocks are back-end dependent. At the moment, back-ends register > their own export block in a variable, `org-element-block-name-alist', so > the parser can know if it needs to parse an export block or not. As > a consequence, the same block can be parsed differently if a given > export back-end is loaded or not. E.g., > > #+BEGIN_HTML > ... > #+END_HTML > > will be parsed as a `special-block' if "ox-html.el" is not loaded, or an > `export-block' otherwise. This is slightly... ugly. And it gets worse if > we include the cache, which will not update the block if it is not > modified. > > I just committed a set of patches that solve the problem: `export-block' > elements do not exist anymore. Instead, such blocks are now parsed as > `special-block', always. This does not depend on the libraries loaded so > far. > > Of course, special blocks are not treated exactly as export blocks. The > latter's contents are included as-is in the output whereas the former's > are interpreted. Therefore, special blocks now include another > property, :raw-value, which stores the pristine initial contents of the > block, and "ox.el" provides a new function, > `org-export-raw-special-block-p', which tells the difference between > a former export block and a special block. This makes sense since an > "export-block" is clearly, and only, an export concept. This is not > related to Org syntax. > > This is more simple to handle than it sounds, and can be described with > two steps: > > 1. `export-block' elements, translators and filters are now ignored. > These can be removed from export back-ends (unless you want to > preserve compatibility with Org 8.2, in which case leaving them > will not hurt: they will be used in Org 8.2 and ignored in Org > 8.3). > > 2. Translators for special blocks, e.g. `org-BACKEND-special-block' > need to be updated and check first if current block is a raw > special block or not. The following template is a suggestion. > > #+BEGIN_SRC emacs-lisp > (defun org-latex-special-block (special-block contents info) >(if (org-export-raw-special-block-p special-block info) >(org-element-property :raw-value special-block) > ;; Usual handling for special blocks goes here. > )) > #+END_SRC > > Note that if BACKEND is a derived back-end and doesn't implement > its own special block translator already, there is nothing to > change. The parent back-end will take care of such blocks. > > All back-ends in core and in contrib have been updated this way > already. > > I included `org-export-raw-special-block-p' in Org 8.2, as > a forward-compatibility measure, so back-end maintainers do not have to > do the `fboundp' dance. > > BTW, for those in the back of the room: I didn't remove > "#+BEGIN_LATEX"-like constructs. > > > Regards, > > -- > Nicolas Goaziou0x80A93738 > > -- -- KDr2, http://kdr2.com
Re: [O] org-image-actual-width has no effect
Thank you for pointing this out. I compiled emacs 24.3 with imagemagick support: "ldd /usr/local/bin/emacs | grep Magick" > libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x7f3946278000) libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x7f3945dd9000) However, inline images are still not scaled at all if I include: (setq org-image-actual-width 50) in my .emacs file. Any other ideas of what I am doing wrong? Thank you very much for your help! Claudius On 08/28/2014 07:50 PM, Charles Philip Chan wrote: On 28 Aug 2014, claudius.muel...@gmail.com wrote: I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs myself, but the core imagemagick libraries are part of the dependencies, which makes me assume that it's been compiled with imagemagick support. No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as, this is the output of my self-compiled version. ,[ ldd /usr/local/bin/emacs | grep Magick ] | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x7fe7e8072000) | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x7fe7e7bd3000 ` I can display inline images of several file types just fine (tif, png, gif, ...). This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc. Charles
Re: [O] Bug: (org-clock-in 64) leads to redundant clock entries [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
I have tried in the cleanest environment I could think of, but still get duplicated clock line. Here are the steps. - CTRL+ALT+F1 login to get a console - env -i TERM=linux HOME=/tmp bash --login --norc --noprofile almost empty enviroment, except TERM and HOME, which emacs need - git clone git HEAD, ccf52269aa670ef6f46012bafdec90aee953282b, Mon Aug 25 18:16:01 2014 +0200. - cd org-mode; make autoloads; rm lisp/*.elc without make autoloads, org-clock-in will not be available. - emacs -nw -q --no-site-file -l minimal-org.el minimal-org.el as said in section 1.4 Feedback. what added to load-path is org-mode/lisp. org-mode is the freshly cloned work copy. - create a new .org file - add one header - clock in - add another header - clock out - c-u c-u c-u c-c c-x c-i Are there any other place where an error in my Emacs or Org mode setup might hide? I do not know if these are relevant. But if I replace the recursively call with setq, there will be no duplicated line. There is a similar situation with superfluous clock lines. After idling for more than org-clock-idle-time, there will be multiple "[jkKgGSscCiq]?" question waiting for me in mini buffer. After resolving 10, 10.1, 11 minutes of idle time, I get, again, multiple clock lines, some of which contains start time bigger than end time. I suppose the 2 lines bellow are meant to prevent re-entering org-resolve-clocks-if-idle. 876: (let ((org-clock-resolving-clocks t)) 1056:(let ((org-clock-resolving-clocks t)) But they do not suffice in my case. I have to replace (run-with-timer 60 60 with (run-with-time 60 nil, and add another timer at the end of org-resolve-clocks-if-idle to be asked only once. Shadowing the value with local one is not enough. Does my emacs use different thread / variable binding / foo bar model than yours? My Emacs Version is GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-06-07 on barber, modified by Debian On Fri, Aug 29, 2014 at 6:01 PM, Nicolas Goaziou wrote: > REN Lifeng writes: > >> Sorry. I gave the wrong steps. The last step should be C-u C-u C-u C-c >> C-x C-i. Could you try again? > > This is what I did. I still cannot reproduce your problem. I also tried > different values for `org-clock-into-drawer', namely nil, t and "CLOCK", > to no avail. > > > Regards, > > -- > Nicolas Goaziou
Re: [O] Marks not visible in column view
Hi, we have had a conversation about this issue on the org-mode IRC channel and have agreed to follow up on this list in case anybody has further ideas. The function org-agenda-bulk-marked-p indicates whether or not an entry is marked. Would it be possible to use it somehow to define a special property that could be shown in column view? Any other ways to attack this problem (i.e., to make marked entries visually distinct in column view) would also be appreciated. Thanks, Gonzalo On 26/08/2014 3:59 PM, Gonzalo Camarillo wrote: > Hi, > > I forgot to mention I am using Emacs 24.2.1 on Windows. > > Cheers, > > Gonzalo > > On 22/08/2014 10:00 PM, Gonzalo Camarillo wrote: >> Hi, >> >> in the agenda we can mark several entries for bulk processing. In the >> following example, the second and third agenda entries are marked. To >> indicate they are marked, a '>' symbol is shown right before them: >> >> Projects: TODO Write the document >>> Projects: TODO Call Bob >>> Projects: TODO Arrange meeting with Laura >> >> Now, if we enter column view, those marks are not visible. For example, >> the following column view shows the title, the TODO keyword, and the >> estimated effort for all entries: >> >> Write the document | TODO | 0:30 | >> Call Bob | TODO | 0:15 | >> Arrange meeting with Laura | TODO | 0:10 | >> >> Is it possible to have the column view show which entries are marked? >> >> Thanks, >> >> Gonzalo >> >
Re: [O] org-indent-mode and erratic checkbox behavior?
Hello again, > I assume (but I can be wrong, thus feel free to correct me): And yes I were. > (I am unable to understand the reasons it does for some and not for > others) Ok, so sorry for the noise. Now I do. I kept looking and I believe that it's 2 minor modes that do not like to work with each other. git-gutter and org-indent. When no modification (git) on the current buffer, everything is good - org/org-indent does as expected. When modifications if present, git-gutter add some information on the left border and this messes around somehow with org-indent which then does as described in the first part. In any case, no worry for the org team :D then. Again, apologies. Cheers, Antoine ardumont writes: > Hello, > > I have a minor visual annoyance with checkboxes and `org-indent-mode`. > As I move to next/previous line, headlines stay still (ok) but checkbox keeps > going forward and backward (2 blank spaces). > (I did not change the default binding C-n/C-p which are still bind to the > default next-line/previous-line.) > > I assume (but I can be wrong, thus feel free to correct me): > - it's not correct behavior because it does not do it to every checkbox (I am > unable to understand the reasons it does for some and not for others) > - it's org-indent minor-mode which does this because when deactivated, > this behavior disappears > > An example can be worth more than trying to explain so I'll do my best to > describe what I see (I'll use '|' as the caret) : > > - On header first character: > #+begin_src org > | IN-PROGRESS 0.5.6 [0%] > - [ ] backlog > #+end_src > > - C-n - move to the next line in the first character indented in the list > #+begin_src org > * IN-PROGRESS 0.5.6 [0%] > | [ ] backlog > #+end_src > > - C-n - move to the next line and here the first line `loses` its indentation > #+begin_src org > * IN-PROGRESS 0.5.6 [0%] > - [ ] backlog > | [ ] Update version > - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of > line in checkbox, we need to do it twice, fix. > #+end_src > > - C-n - move to the next line and here the first previous `loses` its > indentation too > #+begin_src org > * IN-PROGRESS 0.5.6 [0%] > - [ ] backlog > - [ ] Update version > | [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of > line in checkbox, we need to do it twice, fix. > #+end_src > > - C-p - move to the previous line, the indentation does not change > #+begin_src org > * IN-PROGRESS 0.5.6 [0%] > - [ ] backlog > | [ ] Update version > - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of > line in checkbox, we need to do it twice, fix. > #+end_src > > - C-p - move to the previous line, the indentation does not change but the > indentation from the line I came from gets back > #+begin_src org > * IN-PROGRESS 0.5.6 [0%] > | [ ] backlog > - [ ] Update version > - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of > line in checkbox, we need to do it twice, fix. > #+end_src > > - C-p - move to the previous line, the indentation does not change > #+begin_src org > | IN-PROGRESS 0.5.6 [0%] > - [ ] backlog > - [ ] Update version > - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of > line in checkbox, we need to do it twice, fix. > #+end_src > > *Note* > - source of the org file: > https://github.com/ardumont/org-trello/blob/0.5.6/TODO.org > - The same behavior is seen if the caret is elsewhere than the first > character, only the position changes but the behavior stays. > - org-indent-mode is cool, I'd like to keep it since I like the heading > display rendering. > > Some more information you may wish: > - emacs-version: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version > 2.24.23) of 2014-06-06 on localhost > - org-version: Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @ > /home/tony/.emacs.d/elpa/org-20140811/) > - minor-mode activated in org buffer > (M-x describe-mode RET > Enabled minor modes: Anzu Auto-Composition Auto-Compression > Auto-Encryption Blink-Cursor Buffer-Pack Column-Number > Company Delete-Selection Diff-Auto-Refine Erc-Spelling Erc-Track > Erc-Truncate Eval-Sexp-Fu-Flash File-Name-Shadow > Flx-Ido Font-Lock Git-Pack Global-Anzu Global-Auto-Revert > Global-Buffer-Pack Global-Company Global-Diff-Hl > Global-Flycheck Global-Font-Lock Global-Git-Gutter Global-Git-Pack > Global-Hl-Line Global-Page-Break-Lines > Global-Theme-Pack Global-Undo-Tree Guide-Key Ido-Ubiquitous Line-Number > Magit-Auto-Revert Mouse-Wheel Page-Break-Lines > Popwin Prelude Prelude-Global Projectile Projectile-Global Recentf > Repl-Toggle Savehist Shell-Dirtrack > Show-Smartparens-Global Size-Indication Theme-Pack Tooltip > Transient-Mark Undo-Tree Volatile-Highlights Which-Function > Winner > ) > > Hoping I provided everything needed. > Thanks in advance for your time. > > Cheers, > > -- > @ardumont -- @ardumont
Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group
Aaron Ecay wrote: > I’ve noticed that the faces defined by org-copy-face are not added to > the org-faces customize group. This is in accordance with the docstring > of ‘copy-face’, which says (in part) “This function does not copy face > customization data, so NEW-FACE will not be made customizable. Most > Lisp code should not call this function; use `defface' with :inherit > instead.” > > I think it’s at best an odd surprise and at worst a bug that all org’s > faces are not accessible from the org-faces customize group. Would > there be any objection to replacing all uses of this function with > :inherit as recommended by the docstring, and removing the org-copy-face > function? > > For reference, here are the uses of the function, as returned by rgrep: > > ./lisp/org-faces.el:431:(org-copy-face 'org-todo 'org-checkbox-statistics-todo > ./lisp/org-faces.el:434:(org-copy-face 'org-done 'org-checkbox-statistics-done > ./lisp/org-faces.el:540:(org-copy-face 'org-meta-line 'org-block-begin-line > ./lisp/org-faces.el:543:(org-copy-face 'org-meta-line 'org-block-end-line > ./lisp/org-faces.el:560:(org-copy-face 'org-block 'org-quote > ./lisp/org-faces.el:562:(org-copy-face 'org-block 'org-verse > ./lisp/org-faces.el:600:(org-copy-face 'org-agenda-structure 'org-agenda-date > ./lisp/org-faces.el:603:(org-copy-face 'org-agenda-date 'org-agenda-date-today > ./lisp/org-faces.el:607:(org-copy-face 'secondary-selection > 'org-agenda-clocking > ./lisp/org-faces.el:610:(org-copy-face 'org-agenda-date > 'org-agenda-date-weekend > ./lisp/org-faces.el:719:(org-copy-face 'org-time-grid 'org-agenda-current-time > ./lisp/org-faces.el:791:(org-copy-face 'mode-line 'org-mode-line-clock > ./lisp/org-faces.el:793:(org-copy-face 'mode-line 'org-mode-line-clock-overrun I think it's related to an Emacs bug (#16440) which I reported on the Org mailing list in February. As stated by Eli (in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440+): ╭ │ Org uses org-copy-face to define the faces that you show in your │ screencast, and org-copy-face assumes the face it inherits from │ already exists. But loading a theme now doesn't create the faces, it │ only prepares the data for when the face will be created. So :inherit │ in org-copy-face doesn't do what you expect. │ │ I guess either some change is needed in how themes are handled, or │ org-copy-face needs to change to follow suit. (CC to Bastien for │ that.) ╰ In the same functional area, there is also the bug #15298 still pending (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15298) about "Background color lost when highlighting a string". Best regards, Seb -- Sebastien Vauban
[O] org-indent-mode and erratic checkbox behavior?
Hello, I have a minor visual annoyance with checkboxes and `org-indent-mode`. As I move to next/previous line, headlines stay still (ok) but checkbox keeps going forward and backward (2 blank spaces). (I did not change the default binding C-n/C-p which are still bind to the default next-line/previous-line.) I assume (but I can be wrong, thus feel free to correct me): - it's not correct behavior because it does not do it to every checkbox (I am unable to understand the reasons it does for some and not for others) - it's org-indent minor-mode which does this because when deactivated, this behavior disappears An example can be worth more than trying to explain so I'll do my best to describe what I see (I'll use '|' as the caret) : - On header first character: #+begin_src org | IN-PROGRESS 0.5.6 [0%] - [ ] backlog #+end_src - C-n - move to the next line in the first character indented in the list #+begin_src org * IN-PROGRESS 0.5.6 [0%] | [ ] backlog #+end_src - C-n - move to the next line and here the first line `loses` its indentation #+begin_src org * IN-PROGRESS 0.5.6 [0%] - [ ] backlog | [ ] Update version - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of line in checkbox, we need to do it twice, fix. #+end_src - C-n - move to the next line and here the first previous `loses` its indentation too #+begin_src org * IN-PROGRESS 0.5.6 [0%] - [ ] backlog - [ ] Update version | [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of line in checkbox, we need to do it twice, fix. #+end_src - C-p - move to the previous line, the indentation does not change #+begin_src org * IN-PROGRESS 0.5.6 [0%] - [ ] backlog | [ ] Update version - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of line in checkbox, we need to do it twice, fix. #+end_src - C-p - move to the previous line, the indentation does not change but the indentation from the line I came from gets back #+begin_src org * IN-PROGRESS 0.5.6 [0%] | [ ] backlog - [ ] Update version - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of line in checkbox, we need to do it twice, fix. #+end_src - C-p - move to the previous line, the indentation does not change #+begin_src org | IN-PROGRESS 0.5.6 [0%] - [ ] backlog - [ ] Update version - [ ] Fix behavior orgtrello-buffer/goto-end-of-line! When going to end of line in checkbox, we need to do it twice, fix. #+end_src *Note* - source of the org file: https://github.com/ardumont/org-trello/blob/0.5.6/TODO.org - The same behavior is seen if the caret is elsewhere than the first character, only the position changes but the behavior stays. - org-indent-mode is cool, I'd like to keep it since I like the heading display rendering. Some more information you may wish: - emacs-version: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2014-06-06 on localhost - org-version: Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @ /home/tony/.emacs.d/elpa/org-20140811/) - minor-mode activated in org buffer (M-x describe-mode RET Enabled minor modes: Anzu Auto-Composition Auto-Compression Auto-Encryption Blink-Cursor Buffer-Pack Column-Number Company Delete-Selection Diff-Auto-Refine Erc-Spelling Erc-Track Erc-Truncate Eval-Sexp-Fu-Flash File-Name-Shadow Flx-Ido Font-Lock Git-Pack Global-Anzu Global-Auto-Revert Global-Buffer-Pack Global-Company Global-Diff-Hl Global-Flycheck Global-Font-Lock Global-Git-Gutter Global-Git-Pack Global-Hl-Line Global-Page-Break-Lines Global-Theme-Pack Global-Undo-Tree Guide-Key Ido-Ubiquitous Line-Number Magit-Auto-Revert Mouse-Wheel Page-Break-Lines Popwin Prelude Prelude-Global Projectile Projectile-Global Recentf Repl-Toggle Savehist Shell-Dirtrack Show-Smartparens-Global Size-Indication Theme-Pack Tooltip Transient-Mark Undo-Tree Volatile-Highlights Which-Function Winner ) Hoping I provided everything needed. Thanks in advance for your time. Cheers, -- @ardumont
Re: [O] Using Buffer name in :include export property
Julien Cubizolles writes:
> Thanks for the pointer, it works:
>
> (defun jc-org-publish-project-options ()
> (setq org-publish-project-alist
> `(("TeX"
>:base-directory "./"
>:publishing-directory "./"
>:publishing-function org-beamer-publish-to-latex
>:exclude ".*"
>:latex-class "mpsi_beamer"
>:include , (list (file-name-nondirectory buffer-file-name))
>)
> ( several other projects...)
> )))
>
> (add-hook 'org-mode-hook 'jc-org-publish-project-options)
> (add-hook 'org-export-before-processing-hook 'jc-org-publish-project-options)
Arg, it doesn't: org-export-before-processing-hook calls its functions
with the backend as an argument, so I could do
--8<---cut here---start->8---
(defun jc-org-publish-project-options (backend)
--8<---cut here---end--->8---
but the call to jc-org-publish-project-options in org-mode-hook doesn't
work anymore then...
Julien.
Re: [O] Beamer export of columns should use \columnwidth
Nicolas Goaziou writes: > Hello, > > Julien Cubizolles writes: > >> I don't think there would be any inconvenients to changing \textwidth to >> \columnwidth for regular beamer files (it's fine with my beamer files so >> far). > > I agree. Done in master. Thank you for suggesting it. Thank you. Julien.
Re: [O] Bug: (org-clock-in 64) leads to redundant clock entries [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
REN Lifeng writes: > Sorry. I gave the wrong steps. The last step should be C-u C-u C-u C-c > C-x C-i. Could you try again? This is what I did. I still cannot reproduce your problem. I also tried different values for `org-clock-into-drawer', namely nil, t and "CLOCK", to no avail. Regards, -- Nicolas Goaziou
Re: [O] make orgtbl-ascii-plot easier to install
Hello, Thierry Banel writes: > This new patch takes into account all your feedback. > Thanks again for the time spent ! Patch applied (with tiny changes to comments formatting, and a few trailing whitespaces). Thank you for this work. Regards, -- Nicolas Goaziou
Re: [O] Beamer export of columns should use \columnwidth
Hello, Julien Cubizolles writes: > I don't think there would be any inconvenients to changing \textwidth to > \columnwidth for regular beamer files (it's fine with my beamer files so > far). I agree. Done in master. Thank you for suggesting it. Regards, -- Nicolas Goaziou
Re: [O] Using Buffer name in :include export property
Nick Dokos writes:
> Julien Cubizolles writes:
>
>> I'm using the following elisp source block in my org files to choose the
>> publication options.
>>
>> (setq org-publish-project-alist
>> '(("TeX"
>>:base-directory "./"
>>:publishing-directory "./"
>>:publishing-function org-beamer-publish-to-latex
>>:exclude ".*"
>>:latex-class "mpsi_beamer"
>>:include ("test.org"))
>> ))
>>
>> I'd like to define it once and for all in my emacs
>> configuration files but I'd need to replace the
>>
>>:include ("test.org")
>>
>> line with the result of (buffer-name). Is it possible ?
>>
>
> Do you mean buffer-file-name?
Yes that's better.
> When you publish a project, it does not matter what your current buffer
> is. So why would you want to include the random file that you just
> happen to be visiting? And what if the buffer is not associated with a
> file at all (so buffer-file-name returns nil)?
> Can you explain what exactly you are trying to do?
I need to export the same org file with different latex classes and
package options. I do so by using different projects for the same file.
> The usual method of splicing in a variable into a list is with
> backquote - see e.g.
>
> http://thread.gmane.org/gmane.emacs.orgmode/9583/focus=9603
>
> but I don't think that would work here in any case.
Thanks for the pointer, it works:
--8<---cut here---start->8---
(defun jc-org-publish-project-options ()
(setq org-publish-project-alist
`(("TeX"
:base-directory "./"
:publishing-directory "./"
:publishing-function org-beamer-publish-to-latex
:exclude ".*"
:latex-class "mpsi_beamer"
:include , (list (file-name-nondirectory buffer-file-name))
)
( several other projects...)
)))
(add-hook 'org-mode-hook 'jc-org-publish-project-options)
(add-hook 'org-export-before-processing-hook 'jc-org-publish-project-options)
--8<---cut here---end--->8---
I'm not sure file-name-nondirectory is necessary. As you can see I need
to hook this function twice:
- the org-mode-hook is so that the project names are available in any
org file
- the org-export-before-processing-hook is to adapt the :include option
to each org file before export.
That's not very elegant, if someone has any idea.
Julien.
[O] [babel, R] Commands are not copied in the iESS buffer upon evaluation
Hello, I execute the following block of R code by going in the temporary buffer (via `C-c '') and by sending the lines to the =*R*= buffer (via `C-c C-b'). #+begin_src R :eval yes id.etp <- as.data.frame(c(111:113, 444, 555, 666)) names(id.etp) <- "Id" id.etp #+end_src The commands are outputted in the iESS buffer. Though, if I eval the following block with `C-c C-v C-e', the commands are not copied in the iESS buffer. Only "complex" sequences of ">" and "+" are visible. #+begin_src R :eval yes id.stg <- as.data.frame(c(222:224, 777, 888, 999)) names(id.stg) <- "Id" id.stg #+end_src See for yourself on http://screencast.com/t/dq3w3vAp. Does it have something to do with `ess-eval-visibly' not being respected (whose default is `t')? Best regards, Seb -- Sebastien Vauban
