Re: [O] Org campture recursively expands %-escapes
Hi Nicolas On Tue, Jan 12, 2016 at 12:05 AM, Nicolas Goaziou wrote: > > Michael Brand writes: > >> (ert-deftest test-org-capture/fill-template () >> - "Test `org-capture-fill-template' specifications." >> + "Test `org-capture-fill-template' specifications. >> +The tests here are very similar to those in >> +`test-org-feed/fill-template'." > > Not sure the last sentence above is really interesting. Ditto for the > other occurrences. Maybe this and vice versa is better?: (ert-deftest test-org-capture/fill-template () "Test `org-capture-fill-template' specifications." ;; When working on these tests consider to also change ;; `test-org-feed/fill-template'. ;; %(sexp) placeholder. (should [...] >> - (string-match-p >> -(format-time-string (substring (car org-time-stamp-formats) 1 -1)) >> + (equal >> +(concat "[" (format-time-string >> + (substring (car org-time-stamp-formats) 1 -1)) "]\n") >> (org-capture-fill-template "%u"))) >>(should >> - (string-match-p >> -(format-time-string (substring (cdr org-time-stamp-formats) 1 -1)) >> + (equal >> +(concat "[" (format-time-string >> + (substring (cdr org-time-stamp-formats) 1 -1)) "]\n") > > I discovered recently (!) `org-time-stamp-formats' which avoids doing > the substring dance. You may want to use it instead. Ditto for the other > occurrences. I don't understand because the org-time-stamp-formats you mention is already used and does not cover inactive timestamps. Michael
Re: [O] Dangling Citation
gongzhitaao writes: > First time to post here. If inappropriate, please let me know. > > The lisp function insert-file-contents used in ox-bibtex does not move point > and insertion-marker to the end of inserted text (I'm not sure it is a bug or > an intention). The result is that the citation is a dangling table not > included in the bibliography div. > > A visual explanation is here: http://gongzhitaao.org/orgcss/#sec:dangling- > element Thanks for reporting this. Should be fixed with ba5e1be. -- Kyle
Re: [O] org-agenda-filter-by-tag-refine defaults to exclude
Hi Viktor, Viktor Rosenfeld writes: > Hi, > > I noticed that org-agenda-filter-by-tag-refine started to exclude > selected tags by default recently because the 'refine in the call to > org-agenda-filter-by-tag is interpreted as an exclude flag. This seems to have been introduced by 6c6ae99 (org-agenda: Filtering in the agenda on grouptags, 2015-01-24). > The attached patch fixes this. > > However, it seems that the function is superfluous because > org-agenda-filter-by-tag can filter on multiple tags as well if called > multiple times (that used not to be the case earlier). So maybe it > should be deprecated and removed? I agree. Gustav, does that make sense given your changes in 6c6ae99? > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index d91b64d..21928de 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -7580,7 +7580,7 @@ to switch between filtering and excluding." > (defun org-agenda-filter-by-tag-refine (arg &optional char) >"Refine the current filter. See `org-agenda-filter-by-tag'." >(interactive "P") > - (org-agenda-filter-by-tag arg char 'refine)) > + (org-agenda-filter-by-tag arg char)) > (defun org-agenda-filter-make-matcher (filter type &optional expand) >"Create the form that tests a line for agenda filter. Optional -- Kyle
[O] bug#2409: bug#2409: 23.0.90; org-mode + viper-mode + ns make typing unresponsive
On Mon, Jan 11, 2016 at 5:43 PM Michael Brand wrote: > Hi Andrew > > I would like to give some feedback to what you originally asked Steve: > > > On Mon, Jan 11, 2016 at 5:19 AM, Andrew Hyatt wrote: > > I can't reproduce this under Emacs 25. As this bug is a bit old, I'm > > guessing it has been fixed in the meantime. Please let me know if you > > can still reproduce it, though. I'll mark this as unreproducible now, > > and close it in a few weeks if you can't reproduce it either under Emacs > > 25. > > Did you check on OS X? > > On GNU/Linux I never saw the issue, on OS X regularly under certain > circumstances which are not clear to me. With the recipe of Steve I > can reproduce on build GNU Emacs 25.1.50.1 (x86_64-apple-darwin13.4.0, > NS appkit-1265.21 Version 10.9.5 (Build 13F1507)) from > > http://emacsformacosx.com/emacs-builds/Emacs-2016-01-11_01-40-53-eb0643c-universal.dmg > > Seeing as you can reproduce, I'll consider this reproducible... but I cannot reproduce it myself on OS X. > > Michael >
Re: [O] Bug: Habit Logging in incorrect place [8.3.2 (release_8.3.2-490-g157f91 @ /home/swflint/.emacs.d/org-mode/lisp/)]
> Nicolas Goaziou writes: NG> Hello, swfl...@flintfam.org (Samuel W. Flint) writes: >> I use habits, and until recently, there was a problem with habit >> repeaters. Now that this is fixed, there's a new problem. When I >> try to set a habit's TODO state to DONE, aside from correctly setting >> the SCHEDULED line, and the TODO state back to TODO, the logging is >> done incorrectly. >> >> The buffer starts out as so: * TODO Weekly Review SCHEDULED: >> <2016-01-17 Sun .+1w/2w> :PROPERTIES: :STYLE: habit :CREATED: >> <2015-12-21 Mon 17:42> :LAST_REPEAT: [2016-01-10 Sun 19:23] :END: - >> State "DONE" from "TODO" [2016-01-10 Sun 19:23] - State "DONE" from >> "TODO" [2016-01-02 Sat 00:05] - State "DONE" from "TODO" [2015-12-29 >> Tue 18:22] >> >> When I run C-c C-t d on the headline, changing the TODO state to >> DONE, the following occurs: >> >> - State "DONE" from "TODO" [2016-01-10 Sun 19:34] * TODO Weekly >> Review SCHEDULED: <2016-01-17 Sun .+1w/2w> :PROPERTIES: :STYLE: habit >> :CREATED: <2015-12-21 Mon 17:42> :LAST_REPEAT: [2016-01-10 Sun 19:34] >> :END: - State "DONE" from "TODO" [2016-01-10 Sun 19:23] - State >> "DONE" from "TODO" [2016-01-02 Sat 00:05] - State "DONE" from "TODO" >> [2015-12-29 Tue 18:22] >> >> I have no idea why this is. NG> FWIW I cannot reproduce it. Could you try again with a minimal NG> configuration? Sure, with emacs -q -Q, the same thing happens. I also get the following error: Error in post-command-hook (org-add-log-note): (error "Before first headline at position 1 in buffer test.org") I have absolutely no idea why this happens. NG> Regards, NG> -- Nicolas Goaziou Thanks, Sam -- Samuel W. Flint 4096R/266596F4 (9477 D23E 389E 40C5 2F10 DE19 68E5 318E 2665 96F4) (λs.s s) λs.s s signature.asc Description: PGP signature
Re: [O] [PATCH] org-clock.el: Fix column count for :formula %
Hello, Fernando Varesi writes: > * lisp/org-clock.el (org-clocktable-write-default): Count properties > columns when using special :formula % > > The previous count did not consider properties columns, so the generated > formula was incorrect. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Org campture recursively expands %-escapes
Hello, Michael Brand writes: > I would like to push the attached change to add some ERTs with the > commit msg below and would like to ask you for a review first. It looks good. Thank you. Minor suggestions follow. > (ert-deftest test-org-capture/fill-template () > - "Test `org-capture-fill-template' specifications." > + "Test `org-capture-fill-template' specifications. > +The tests here are very similar to those in > +`test-org-feed/fill-template'." Not sure the last sentence above is really interesting. Ditto for the other occurrences. > - (string-match-p > -(format-time-string (substring (car org-time-stamp-formats) 1 -1)) > + (equal > +(concat "[" (format-time-string > + (substring (car org-time-stamp-formats) 1 -1)) "]\n") > (org-capture-fill-template "%u"))) >(should > - (string-match-p > -(format-time-string (substring (cdr org-time-stamp-formats) 1 -1)) > + (equal > +(concat "[" (format-time-string > + (substring (cdr org-time-stamp-formats) 1 -1)) "]\n") I discovered recently (!) `org-time-stamp-formats' which avoids doing the substring dance. You may want to use it instead. Ditto for the other occurrences. Regards, -- Nicolas Goaziou
Re: [O] Bug: Habit Logging in incorrect place [8.3.2 (release_8.3.2-490-g157f91 @ /home/swflint/.emacs.d/org-mode/lisp/)]
Hello, swfl...@flintfam.org (Samuel W. Flint) writes: > I use habits, and until recently, there was a problem with habit > repeaters. Now that this is fixed, there's a new problem. When I try > to set a habit's TODO state to DONE, aside from correctly setting the > SCHEDULED line, and the TODO state back to TODO, the logging is done > incorrectly. > > The buffer starts out as so: > * TODO Weekly Review > SCHEDULED: <2016-01-17 Sun .+1w/2w> > :PROPERTIES: > :STYLE:habit > :CREATED: <2015-12-21 Mon 17:42> > :LAST_REPEAT: [2016-01-10 Sun 19:23] > :END: > - State "DONE" from "TODO" [2016-01-10 Sun 19:23] > - State "DONE" from "TODO" [2016-01-02 Sat 00:05] > - State "DONE" from "TODO" [2015-12-29 Tue 18:22] > > When I run C-c C-t d on the headline, changing the TODO state to DONE, > the following occurs: > > - State "DONE" from "TODO" [2016-01-10 Sun 19:34] > * TODO Weekly Review > SCHEDULED: <2016-01-17 Sun .+1w/2w> > :PROPERTIES: > :STYLE:habit > :CREATED: <2015-12-21 Mon 17:42> > :LAST_REPEAT: [2016-01-10 Sun 19:34] > :END: > - State "DONE" from "TODO" [2016-01-10 Sun 19:23] > - State "DONE" from "TODO" [2016-01-02 Sat 00:05] > - State "DONE" from "TODO" [2015-12-29 Tue 18:22] > > I have no idea why this is. FWIW I cannot reproduce it. Could you try again with a minimal configuration? Regards, -- Nicolas Goaziou
Re: [O] Bug: Capture prompt - white space throws a [no match] (resent with version info)
Hello,
Charles Millar writes:
> Given the following template
>
> "\| %(org-read-date)\| %^{InputSomething}"
>
> org-read-date works fine , but
>
> any attempt to enter a space character in "InputSomething"
>
> gives the following in the minibuffer
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
[O] bug#2409: bug#2409: 23.0.90; org-mode + viper-mode + ns make typing unresponsive
Hi Andrew I would like to give some feedback to what you originally asked Steve: On Mon, Jan 11, 2016 at 5:19 AM, Andrew Hyatt wrote: > I can't reproduce this under Emacs 25. As this bug is a bit old, I'm > guessing it has been fixed in the meantime. Please let me know if you > can still reproduce it, though. I'll mark this as unreproducible now, > and close it in a few weeks if you can't reproduce it either under Emacs > 25. Did you check on OS X? On GNU/Linux I never saw the issue, on OS X regularly under certain circumstances which are not clear to me. With the recipe of Steve I can reproduce on build GNU Emacs 25.1.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1507)) from http://emacsformacosx.com/emacs-builds/Emacs-2016-01-11_01-40-53-eb0643c-universal.dmg Michael
Re: [O] Seeing Actual Emphasis in Orgmode Buffer
> > Are you sure you have a font that supports italic or boldface variants? > Hmmm ... not sure I know how to check that ... Might you suggest a "variable", "function" or "menu item" that would indicate whether the needed "font support" was there/enabled? > It works out of the box on my Emacs, but I didn't mess up with the > default font. I don't *think* I did anything with the "default font" either ... So you actually see the "bold" rendering in the "buffer" corresponding to the ".org" file ? If so, there is "hope" for me ;-) Thanks for your comments! -Kenneth
[O] Dangling Citation
First time to post here. If inappropriate, please let me know. The lisp function insert-file-contents used in ox-bibtex does not move point and insertion-marker to the end of inserted text (I'm not sure it is a bug or an intention). The result is that the citation is a dangling table not included in the bibliography div. A visual explanation is here: http://gongzhitaao.org/orgcss/#sec:dangling- element Is there a way around this problem? Thanks!
Re: [O] Seeing Actual Emphasis in Orgmode Buffer
On 2016-01-11, at 19:30, Kenneth Jacker wrote: > [ Orgmode v8.3.1 ] > > How can I have Emacs actually display /foo/, *bar*, _blah_ emphasis *in an > Orgmode buffer*? > Note that I am not "exporting" HTML, LaTeX, or friends (where I assume the > above markups get correctly styled as italics, bold, etc.). > > Is there some way to do this? > > "org-fontify-emphasized-text" is non-nil. > > Anyone know how to do this? Sorry if I'm missing the obvious! Are you sure you have a font that supports italic or boldface variants? It works out of the box on my Emacs, but I didn't mess up with the default font. > Thanks, > > -Kenneth Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
[O] Seeing Actual Emphasis in Orgmode Buffer
[ Orgmode v8.3.1 ] How can I have Emacs actually display /foo/, *bar*, _blah_ emphasis *in an Orgmode buffer*? Note that I am not "exporting" HTML, LaTeX, or friends (where I assume the above markups get correctly styled as italics, bold, etc.). Is there some way to do this? "org-fontify-emphasized-text" is non-nil. Anyone know how to do this? Sorry if I'm missing the obvious! Thanks, -Kenneth -- Prof Kenneth H Jacker k...@cs.appstate.edu Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA
[O] [PATCH] org-clock.el: Fix column count for :formula %
* lisp/org-clock.el (org-clocktable-write-default): Count properties columns when using special :formula % The previous count did not consider properties columns, so the generated formula was incorrect. --- lisp/org-clock.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 5976872..dfc7d4c 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2627,12 +2627,14 @@ from the dynamic block definition." ((eq formula '%) ;; compute the column where the % numbers need to go (setq pcol (+ 2 + (if properties (length properties) 0) (if multifile 1 0) (if level-p 1 0) (if timestamp 1 0) (min maxlevel (or ntcol 100 ;; compute the column where the total time is (setq tcol (+ 2 + (if properties (length properties) 0) (if multifile 1 0) (if level-p 1 0) (if timestamp 1 0))) -- 2.6.4
[O] Bug: Capture prompt - white space throws a [no match] (resent with version info)
Given the following template
"\| %(org-read-date)\| %^{InputSomething}"
org-read-date works fine , but
any attempt to enter a space character in "InputSomething"
gives the following in the minibuffer
[No match]
GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of
2015-03-07 on trouble, modified by Debian
Org-mode version 8.3.3 (release_8.3.3-430-g9db786 @
/usr/local/share/emacs/site-lisp/org-mode/lisp/)
Charlie Millar
[O] Bug: Capture prompt - white space throws a [no match]
Given the following template
"\| %(org-read-date)\| %^{InputSomething}"
org-read-date works fine , but
any attempt to enter a space character in "InputSomething"
gives the following in the minibuffer
[No match]
Charlie Millar
Re: [O] [ANN] Export block syntax change
Hello, Kaushal Modi writes: > Out of curiosity, which org-mode version will see this change in > export-block syntax? Org 9.0. See ORG-NEWS in development branch. Regards, -- Nicolas Goaziou
