Re: [O] Weird Headline Behavior
On 2/12/19 5:37 PM, Nicolas Goaziou wrote: > Hello, > > Scott Randby writes: > >> I've been noticing some unusual behavior when I manipulate headlines (Org >> 9.2). >> >> I have the following (or something similar) at the very end of many Org >> files: >> >> * LOCAL VARIABLES >> # Local Variables: >> # mode: org >> # coding: utf-8-unix >> # End: >> >> If I copy this subtree (C-c C-x M-w) and then yank it (C-c C-x C-y) >> into into the same file or another file, only the headline is yanked, >> the rest of the subtree is not. > > This is because Org now has some code preserving file local variables at > the end of the document. Some headings related commands -- e.g., moving > or sorting them -- just ignore these comments. > > If you really want to copy them, mark the section, with > `org-mark-subtree' and copy it with M-w. Okay, I understand now. > >> In addition, if I decide to delete a different headline in the file >> (C-c C-x C-w) while the LOCAL VARIABLES headline is folded, then this >> appears on the display: >> >> * LOCAL VARIABLES...# Local Variables: >> # mode: org >> # coding: utf-8-unix >> # End: > > I fixed it. Thank you. Thank you. Scott
Re: [O] [PATCH] When testing, fake the current time more robustly
Kyle Meyer writes: > Paul Eggert writes: > >> The old approach required Lisp code to use (current-time) >> explicitly when calling other primitives, e.g., (float-time >> (current-time)). The new approach fakes all the primitives, >> so that Lisp code can now use expressions like plain (float-time). > > Great, thanks! I'll go through all the spots where I've > s/nil/(current-time)/ for the sake of testing and restore nil. Pushed (2cd1f9b028b) along with a follow-up commit removing current-time calls that were kept for testing purposes.
Re: [O] [PATCH] When testing, fake the current time more robustly
Paul Eggert writes: > The old approach required Lisp code to use (current-time) > explicitly when calling other primitives, e.g., (float-time > (current-time)). The new approach fakes all the primitives, > so that Lisp code can now use expressions like plain (float-time). Great, thanks! I'll go through all the spots where I've s/nil/(current-time)/ for the sake of testing and restore nil. -- Kyle
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't > use in Org. Mmm ok :). I proposed it because it is easy to remember if you think you're modifying a base action by S and also because it's easier to keep C pressed (versus simply S-l or M-l). So lets play with minus as a modifier, I like that idea. (A) Here is a variation of my proposal: [C- -] [C-u] [C-u] C-c C-x C-l The modifier [C- -] means force preview. The modifier [C-u] means section scope. The modifier [C-u][C-u] means document scope. So - means force, C-u means section, C-u C-u means document. One advantage of this approach is backwards compatibility. (B) Here is a variation of your proposal. In it - means clear (I find this a good mnemonic since "minus removes stuff"): - C-c C-x C-l :: Toggle preview on the fragment at point, raise an error outside a fragment - C-u C-c C-x C-l :: *Preview* for current section - C-- C-u C-c C-x C-l :: *Clear preview* from the current section - C-u C-u C-c C-x C-l :: *Preview* the whole document - C-- C-u C-u C-c C-x C-l :: *Clear preview* for the whole document So - means clear, C-u means section, C-u C-u means document. > This doesn't solve the overlapping between `C-c C-x C-l' and `C-u C-x > C-l' either. I know I mentioned this overlapping but that was the result of a confusion of mine: at first I mistakenly thought the C-u modifiers were there to force preview clearing. But I don't think the section-scope overlapping between C-u C-c C-x C-l and C-c C-x C-l when used outside a fragment is a such bad thing. The C-u modifiers can be thought as setting "strict scopes" of operation while the vanilla operation tries to be smart. The problem with this smartness is not the overlapping per se but that the meaning of "toggle" is ill defined when you have a mixed set of un/previewed fragments. Therefore, although I'm ok with the section-scope overlapping, I agree that it could be convenient to ban the toggling behavior altogether except for single fragments, for which it's well defined. But backwards compatibility is a balancing consideration. I'm fine with both (A) and (B) above. (A) is backwards compatible and (B) removes the somewhat surprising toggle behavior when outside a fragment (which motivated this report). Best regards -- Carlos
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Carlos Pita writes: > What about leaving everything as it is now and adding C-c C-x C-S-l to mean > "force preview", of course with the C-u and C-u C-u variants. This is a bit > more orthogonal in the sense that the numerical argument controls scope and > the S modifier controls "forcing". Also, it's backwards compatible with > established muscle memory. What do you think? I could write a patch. `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't use in Org. This doesn't solve the overlapping between `C-c C-x C-l' and `C-u C-x C-l' either.
[O] [PATCH] When testing, fake the current time more robustly
The old approach required Lisp code to use (current-time) explicitly when calling other primitives, e.g., (float-time (current-time)). The new approach fakes all the primitives, so that Lisp code can now use expressions like plain (float-time). * testing/org-test.el (org-test-at-time): New macro. * testing/lisp/test-org-colview.el (test-org-colview/columns-summary): * testing/lisp/test-org-timer.el (test-org-timer/with-current-time): * testing/lisp/test-org.el (test-org/org-read-date) (test-org/deadline-close-p, test-org/deadline) (test-org/schedule, test-org/time-stamp): Use it. --- testing/lisp/test-org-colview.el | 15 ++--- testing/lisp/test-org-timer.el | 3 +- testing/lisp/test-org.el | 57 testing/org-test.el | 52 + 4 files changed, 69 insertions(+), 58 deletions(-) diff --git a/testing/lisp/test-org-colview.el b/testing/lisp/test-org-colview.el index 532515b53..ed75090df 100644 --- a/testing/lisp/test-org-colview.el +++ b/testing/lisp/test-org-colview.el @@ -510,10 +510,7 @@ (should (equal "0min" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time - (org-parse-time-string "<2014-03-04 Tue>") +(org-test-at-time "<2014-03-04 Tue>" (org-test-with-temp-text "* H ** S1 @@ -529,10 +526,7 @@ (should (equal "2d" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time - (org-parse-time-string "<2014-03-04 Tue>") +(org-test-at-time "<2014-03-04 Tue>" (org-test-with-temp-text "* H ** S1 @@ -548,10 +542,7 @@ (should (equal "1d 12h" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time - (org-parse-time-string "<2014-03-04 Tue>") +(org-test-at-time "<2014-03-04 Tue>" (org-test-with-temp-text "* H ** S1 diff --git a/testing/lisp/test-org-timer.el b/testing/lisp/test-org-timer.el index f6bd5ab1a..27156dfa9 100644 --- a/testing/lisp/test-org-timer.el +++ b/testing/lisp/test-org-timer.el @@ -40,8 +40,7 @@ Also, mute output from `message'." (defmacro test-org-timer/with-current-time (time &rest body) "Run BODY, setting `current-time' output to TIME." (declare (indent 1)) - `(cl-letf (((symbol-function 'current-time) (lambda () ,time))) - ,@body)) + `(org-test-at-time ,time ,@body)) ;;; Time conversion and formatting diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index feaacf673..c3bd07923 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -198,18 +198,14 @@ (should (equal "2015-03-04" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2014-03-04") +(org-test-at-time "2014-03-04" (org-read-date t nil "+1y" nil (apply #'encode-time (org-parse-time-string "2012-03-29")) (should (equal "2013-03-29" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2014-03-04") +(org-test-at-time "2014-03-04" (org-read-date t nil "++1y" nil (apply #'encode-time (org-parse-time-string "2012-03-29")) @@ -219,25 +215,19 @@ (should (equal "2014-04-01" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2014-03-04") +(org-test-at-time "2014-03-04" (let ((org-read-date-prefer-future t)) (org-read-date t nil "1") (should (equal "2013-03-04" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2012-03-29") +(org-test-at-time "2012-03-29" (let ((org-read-date-prefer-future t)) (org-read-date t nil "3-4") (should (equal "2012-03-04" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2012-03-29") +(org-test-at-time "2012-03-29" (let ((org-read-date-prefer-future nil)) (org-read-date t nil "3-4") ;; When set to `org-read-date-prefer-future' is set to `time', read @@ -247,17 +237,13 @@ (should (equal "2012-03-30" -(cl-letf (((symbol-function 'current-time) - (lambda () -(apply #'encode-time (org-parse-time-string "2012-03-29 16:40") +(org-test-at-time "2012-03-29 16:40" (let ((org-read-date-prefer-future 'time)) (org-read-date t nil "00:40" nil) (should-not (equal "2012-03-30" -(cl-letf (((symbol-function 'current-time) - (lambda
Re: [O] Weird Headline Behavior
Hello, Scott Randby writes: > I've been noticing some unusual behavior when I manipulate headlines (Org > 9.2). > > I have the following (or something similar) at the very end of many Org files: > > * LOCAL VARIABLES > # Local Variables: > # mode: org > # coding: utf-8-unix > # End: > > If I copy this subtree (C-c C-x M-w) and then yank it (C-c C-x C-y) > into into the same file or another file, only the headline is yanked, > the rest of the subtree is not. This is because Org now has some code preserving file local variables at the end of the document. Some headings related commands -- e.g., moving or sorting them -- just ignore these comments. If you really want to copy them, mark the section, with `org-mark-subtree' and copy it with M-w. > In addition, if I decide to delete a different headline in the file > (C-c C-x C-w) while the LOCAL VARIABLES headline is folded, then this > appears on the display: > > * LOCAL VARIABLES...# Local Variables: > # mode: org > # coding: utf-8-unix > # End: I fixed it. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
What about leaving everything as it is now and adding C-c C-x C-S-l to mean "force preview", of course with the C-u and C-u C-u variants. This is a bit more orthogonal in the sense that the numerical argument controls scope and the S modifier controls "forcing". Also, it's backwards compatible with established muscle memory. What do you think? I could write a patch.
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Hello, Carlos Pita writes: > A last suggestion. Incidentally the toggle returns nil when at least a > fragment is unpreviewed and non-nil otherwise (as a side effect of > message). This can be documented and made part of the interface, so > that something like the following can be put together by the end user: > > (defun my-org-preview-latex (&optional arg) > (interactive "P") > (unless (org-toggle-latex-fragment arg) > (org-toggle-latex-fragment arg))) > I insist on the importance of the use case "force preview" because > it's very useful to quickly jot down a paragraph or part of a > paragraph with many simple latex fragments like $x_i$, $f(x)$, etc. > and then, afterwards, type C-c C-x C-l to preview the last entered > part of the paragraph, instead of painfully entering C-c C-x C-l after > any single $x$ or similar. Now, if the toggle prefers removing > previews as it's the case, this won't work because, in general, you > already have some preview in the same section or paragraph. Here is my take on the issue. First, I think the current behaviour is as it is because deleting overlays is fast, whereas checking if some LaTeX fragments are not previewed is slow. So, there is little overhead to first delete them: if that is what you wanted, you win, if you wanted to preview more fragments, you only need to hit `C-c C-x C-l` a second time. OTOH, if we do the opposite, as you suggest, you gain one `C-c C-x C-l' -- or any shorter binding -- in the latter case, but can waste a lot of time in the former case, i.e., quitting preview is not fast anymore. In any case, I agree the current behavior is slightly confusing. At least, we could clean the overlapping between `C-u C-c C-x C-l' and `C-c C-x C-l'. For example : - C-c C-x C-l :: Toggle preview on the fragment at point, *raise an error outside a fragment* - C-u C-c C-x C-l :: Toggle preview for current section - C-u C-u C-c C-x C-l :: Toggle preview for the whole document Or, if we consider that previewing the whole document is not very useful and can be given a more cumbersome binding, - C-c C-x C-l :: Toggle preview on the fragment at point, raise an error outside a fragment - C-u C-c C-x C-l :: *Preview* for current section, incrementally (what you suggest) - C-u C-u C-c C-x C-l :: *Clear preview* from the whole section - C-u 0 C-u C-c C-x C-l :: *Preview* the whole document - C-u - C-c C-x C-l :: *Clear preview* for the whole document Regards, -- Nicolas Goaziou
Re: [O] Lowercase keywords in 9.2?
On Tue, Feb 12, 2019 at 3:59 PM Carlos Pita wrote: > > What do you mean with the "uppercase legacy"? You mean all the current > documents we already have? > > Specifically what motivated this post: collections of snippets that > have been written with the historical convention in mind. It's easy to > convert them but it's not that easy to convert users :). > I am one of those who prefer the lower-case keywords :) I started converting my Org documents to use the new convention around the time it landed in the Org mode master branch little more than a year back: https://scripter.co/org-keywords-lower-case/.
Re: [O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Not a big deal, but here is a slightly better fix that avoids adding some spaces before the closing }. The difference wrt to the previous one is just: - (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n")) - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) + (insert "\n") + (when (or ingroup intaggroup) (insert " "))) That is, the when clause is inside the unless clause. From 49775847f6db729dfb726ac098cc8039fceb9346 Mon Sep 17 00:00:00 2001 From: memeplex Date: Tue, 12 Feb 2019 17:49:40 -0300 Subject: [PATCH] org: Fix fast tag selection menu alignment * lisp/org.el (org-fast-tag-selection): - Avoid lines with just a closing delimiter. - Correctly align grouped and ungrouped tags. --- lisp/org.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e2258749b..003058434 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14502,13 +14502,14 @@ Returns the new tags string, or nil to not change the current settings." ((member tg inherited) i-face (when (equal (caar tbl) :grouptags) (org-add-props tg nil 'face 'org-tag-group)) - (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) + (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) (insert "[" c "] " tg (make-string (- fwidth 4 (length tg)) ?\ )) (push (cons tg c) ntable) (when (= (cl-incf cnt) ncol) - (insert "\n") - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) + (insert "\n") + (when (or ingroup intaggroup) (insert " "))) (setq cnt 0) (setq ntable (nreverse ntable)) (insert "\n") -- 2.20.1
Re: [O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Ok, this was easier than I initially thought. Here is a patch. I've tested it with a number of configurations: a few grouped tags, many grouped tags, grouped tags that fill the last line entirely, grouped and ungrouped tags. Notice that even ungrouped tags are indented by two spaces. This is done because some tags may be grouped while other not. In case no tag is grouped this is adding an extra initial space but I think removing it is not worth the check "is everything ungrouped?". Best regards -- Carlos From 4a79d1355ec35c711bddd06be0d99b0af287c182 Mon Sep 17 00:00:00 2001 From: memeplex Date: Tue, 12 Feb 2019 17:49:40 -0300 Subject: [PATCH] org: Fix fast tag selection menu alignment * lisp/org.el (org-fast-tag-selection): - Avoid lines with just a closing delimiter. - Correctly align grouped and ungrouped tags. --- lisp/org.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e2258749b..7f04cee18 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14502,13 +14502,13 @@ Returns the new tags string, or nil to not change the current settings." ((member tg inherited) i-face (when (equal (caar tbl) :grouptags) (org-add-props tg nil 'face 'org-tag-group)) - (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) + (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) (insert "[" c "] " tg (make-string (- fwidth 4 (length tg)) ?\ )) (push (cons tg c) ntable) (when (= (cl-incf cnt) ncol) - (insert "\n") - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n")) + (when (or ingroup intaggroup) (insert " ")) (setq cnt 0) (setq ntable (nreverse ntable)) (insert "\n") -- 2.20.1
Re: [O] Lowercase keywords in 9.2?
> What do you mean with the "uppercase legacy"? You mean all the current > documents we already have? Specifically what motivated this post: collections of snippets that have been written with the historical convention in mind. It's easy to convert them but it's not that easy to convert users :). Anyway I was just asking for opinions about what should be done, although I guess the answer is to not procrastinate conversion to the new convention.
Re: [O] Lowercase keywords in 9.2?
What do you mean with the "uppercase legacy"? You mean all the current documents we already have? In my case, those will remain with the upper case tags until I need to edit them. I guess it would be enough to patch the sites affected by > > https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 > and also the templates definition in org-tempo. Looking at that diff, the changes are not so simple as I initially thought, I was just thinking about patching org-tempo, but I guess they should cover all the uppercase tags. Now I don't feel so confident about doing it :-( Regards On Tue, Feb 12, 2019 at 11:10 AM Carlos Pita wrote: > > At first I didn't like the lowercase tags for the blocks, but I got used > to them after a couple of days. > > I prefer the lowercase convention hands down. The problem I pointed > out is with the uppercase legacy. > > > Someone suggested adding a defcustom option to org-tempo to let the user > choose between lower and upper case tags. > > It seems a simple enough feature for a first contribution. Maybe we > could add it? I have never done it before, but I am willing to try. > > I wouldn't mind (helping you) doing it as far as there is agreement > whether this is a desired option or not. > > I guess it would be enough to patch the sites affected by > > https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 > and also the templates definition in org-tempo. > > Regards > -- > Carlos >
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
Hi there; Agreed, hiding properties entirely seems overkill and quite limited in use cases. However, I think this stems from a more general need to hide properties that are irrelevant to the user—for instance, UIDs created by ox-icalendar, or other internal properties. As a user, I see no need whatsoever to see—let alone edit—such a property, and feel that it clutters the display. Assuming that properties are edited using the suitable commands, no clash would be created by having a set P of properties such that drawers with only P-properties would be hidden. What do you think? Cheers; M. On Tue, 12 Feb 2019 at 08:38, Nicolas Goaziou wrote: > > Hello, > > Keith David Bershatsky writes: > > > A few years ago, I wrote up an answer to my own question on > > Stackoverflow to completely hide the :PROPERTIES: drawer, including > > the line that says :PROPERTIES:. Since then, it has received nearly > > 5,000 views, 11 stars, 17 upvotes on the initial question, and 15 > > upvotes on the answer. > > > > Today, a forum participant posted a comment underneath my answer asking why > > not send this upstream. So, here is the link to the answer: > > > > https://stackoverflow.com/a/17492723/2112489 > > Thank you for the suggestion. > > However, I think hiding completely stuff from the user is not great. How > would you edit it, or even know there are properties there? > > You can write ":properties:" instead of ":PROPERTIES:", dim them with an > appropriate face… > > Regards, > > -- > Nicolas Goaziou >
[O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
For example, with:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) @xxx(x) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
[x] @xxx}
where [c] and [x] are clearly misaligned.
If I remove the last tag:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
}
where the closing brace should be in the line before.
org-last-tag-selection-key is a bit overwhelming in size but I might try
my luck and see what I can get.
Regards
--
Carlos
---
Emacs : GNU Emacs 26.1.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2019-02-10
Package: Org mode version 9.2.1 (release_9.2.1-60-gb0379f @
/home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)
Re: [O] Lowercase keywords in 9.2?
> At first I didn't like the lowercase tags for the blocks, but I got used to > them after a couple of days. I prefer the lowercase convention hands down. The problem I pointed out is with the uppercase legacy. > Someone suggested adding a defcustom option to org-tempo to let the user > choose between lower and upper case tags. > It seems a simple enough feature for a first contribution. Maybe we could add > it? I have never done it before, but I am willing to try. I wouldn't mind (helping you) doing it as far as there is agreement whether this is a desired option or not. I guess it would be enough to patch the sites affected by https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 and also the templates definition in org-tempo. Regards -- Carlos
Re: [O] Lowercase keywords in 9.2?
Carlos, I recently updated to 9.2 and was also confronted with the org-tempo change. At first I didn't like the lowercase tags for the blocks, but I got used to them after a couple of days. Someone suggested adding a defcustom option to org-tempo to let the user choose between lower and upper case tags. It seems a simple enough feature for a first contribution. Maybe we could add it? I have never done it before, but I am willing to try. On Tue, Feb 12, 2019 at 10:30 AM Carlos Pita wrote: > > Here are two previous threads about the subject: > > > > Last month: > http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html > > A year ago: > http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html > > Interesting, thanks! Although the issue of mostly uppercase external > snippet collections was not raised there. For now I'm disabling yas in > org mode and using org-tempo exclusively. >
Re: [O] Lowercase keywords in 9.2?
> Here are two previous threads about the subject: > > Last month: > http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html > A year ago: > http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html Interesting, thanks! Although the issue of mostly uppercase external snippet collections was not raised there. For now I'm disabling yas in org mode and using org-tempo exclusively.
Re: [O] Lowercase keywords in 9.2?
Carlos Here are two previous threads about the subject: - Last month: http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html - A year ago: http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html Regards On Tue, Feb 12, 2019 at 9:51 AM Carlos Pita wrote: > > before, didn't they? Is this implying that now lowercase is preferred? > > I dug this up from the repo: > >org-element: Prefer lower case letters for blocks and keywords > > > https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 > > So the answer is yes. Also the begin/end pairs are lowercase hardcoded > in org-tempo.el. > > This is a problem for available (ya)snippet databases. I've reported > it in https://github.com/AndreaCrotti/yasnippet-snippets/issues/303, > requesting an update. But I guess people will prefer uppercase for a > time so I'm now sure how should they should cope with the transition. > > Best regards > -- > Carlos > > > > > Regards > > -- > > Carlos > >
Re: [O] Lowercase keywords in 9.2?
> before, didn't they? Is this implying that now lowercase is preferred? I dug this up from the repo: org-element: Prefer lower case letters for blocks and keywords https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 So the answer is yes. Also the begin/end pairs are lowercase hardcoded in org-tempo.el. This is a problem for available (ya)snippet databases. I've reported it in https://github.com/AndreaCrotti/yasnippet-snippets/issues/303, requesting an update. But I guess people will prefer uppercase for a time so I'm now sure how should they should cope with the transition. Best regards -- Carlos > > Regards > -- > Carlos
Re: [O] Bug: in agenda: when searching for a tag, an error occurs (maybe connected to bbdb) [9.1.14 (release_9.1.14-1059-gadec50 @ /home/oub/emacs/site-lisp/packages/org/)]
>>> "NG" == Nicolas Goaziou writes: > Hello, > Uwe Brauer writes: >> In an org file >> >> 1. I run org-agenda >> >> 2. Then m (for search tags) >> >> 3. Then the tag, which is displayed but also an annoying error >> message which I attach > It doesn't look like an Org bug. You may need to update BBDB (mine, 3.2, > contains said function) or check `gnorb-org-popup-bbdb'. I'd like to configure org mode such that function is not executed, but I don't know how. Meanwhile I set a dummy function (defun bbdb-record-xfield () (interactive) (message "this is a dummy function.")) But I was only partially successful. Any ideas what to do? smime.p7s Description: S/MIME cryptographic signature
[O] Lowercase keywords in 9.2?
Hi all, I noticed that the default expansions for org-tempo in 9.2 are lowercase. I think they followed the uppercase informal convention before, didn't they? Is this implying that now lowercase is preferred? Regards -- Carlos
Re: [O] [PATCH] ob-emacs-lisp: Set `lexical-binding' in source editing buffers
Hello, Sebastian Miele writes: > * lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp, > org-babel-emacs-lisp-lexical): Factor out the conversion of the > :lexical source block argument to a form that is appropriate for > `lexical-binding' and the LEXICAL argument to `eval'. > > * lisp/ob-emacs-lisp.el (org-babel-edit-prep:emacs-lisp): Set > `lexical-binding'. > > * lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp): > Update docstring. Thank you! Some comments follow. > -`eval', which see.") > +`eval', which see. And it is used as the value for > +`lexical-binding' in buffers created by `org-edit-src-code'.") You need to add two spaces after full stops. > +(defun org-babel-emacs-lisp-lexical (lexical) > + "Convert :lexical source block argument LEXICAL into the form > +appropriate for `lexical-binding' and the LEXICAL argument to > +`eval'." The first sentence in a docstring needs to fit on a single line. Could you add a test or two for that feature? Could you also add an ORG-NEWS entry? Regards, -- Nicolas Goaziou
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
Hello, Keith David Bershatsky writes: > A few years ago, I wrote up an answer to my own question on > Stackoverflow to completely hide the :PROPERTIES: drawer, including > the line that says :PROPERTIES:. Since then, it has received nearly > 5,000 views, 11 stars, 17 upvotes on the initial question, and 15 > upvotes on the answer. > > Today, a forum participant posted a comment underneath my answer asking why > not send this upstream. So, here is the link to the answer: > > https://stackoverflow.com/a/17492723/2112489 Thank you for the suggestion. However, I think hiding completely stuff from the user is not great. How would you edit it, or even know there are properties there? You can write ":properties:" instead of ":PROPERTIES:", dim them with an appropriate face… Regards, -- Nicolas Goaziou
Re: [O] org-icalendar: Change dates to today in VEVENT export
Hello,
Michaël Cadilhac writes:
> Well, certainly. I may not have had the best discipline in writing
> these, so turning them into patches is a bit painful. Let me know if
> I can make things better. (I believe my FSF paperwork is still
> alright, if need be.)
Thank you! Comments follow.
> +(defcustom org-icalendar-bump-todos nil
> + "Non-nil means that pending TODO VEVENTs are bumped to today.
> +In addition, if non-nil, the number of late days is indicated in the
> summary."
> + :group 'org-export-icalendar
> + :type 'boolean)
This variable is missing :package-version '(Org . "9.3") and :safe
keywords. This is also true for other defcustom introduced throughout
your patches.
> +(defun org-icalendar-today-timestamp ()
> + "Return a TIMESTAMP object for today, at 00:00."
> + (let ((dt (decode-time)))
> +(list 'timestamp
> + (nconc (list :year-start (nth 5 dt)
> +:year-end (nth 5 dt)
> +:month-start (nth 4 dt)
> +:month-end (nth 4 dt)
> +:day-start (nth 3 dt)
> +:day-end (nth 3 dt))
This function already exists: `org-timestamp-from-time'.
> +(defun org-icalendar-days-until-timestamp (timestamp)
> + "Return the number of days until TIMESTAMP.
> +
> +If TIMESTAMP occurs today, return 0.
> +If TIMESTAMP occurs yesterday, return -1."
> + (floor
> + (/ (float-time
> + (time-subtract (org-timestamp--to-internal-time timestamp)
> + (apply 'encode-time
> + (append '(0 0 0) (nthcdr 3 (decode-time))
(time-substract (org-timestamp-to-time timestamp)
(current-time))
> + (* 60 60 24
>
> - (concat "DL: " summary) loc desc cat tz class)))
> +(concat "DL: " summary) loc desc cat tz class))
> +
Spurious blank line.
> + ;; Case 2: pending TODO overdue and should bump.
> + ((and org-icalendar-bump-todos
> +(< days-until-deadline 0))
> + (org-icalendar--vevent
> +entry (org-icalendar-today-timestamp) (concat "DL-" uid)
> +(concat "DL (" (number-to-string (- days-until-deadline))
> +"x): " summary)
Nitpick:
(format "DL (%d)x): %s" (- days-until-deadline) summary
is more readable.
> +loc desc cat tz class))
> + ;; Case 3: in the future and should warn.
> + (t
> + (concat
> +;; If in the warning zone.
> +(when (<= days-until-deadline org-deadline-warning-days)
> + (org-icalendar--vevent
> + entry (org-icalendar-today-timestamp) (concat "DL-" uid)
> + (concat "DL (in " (number-to-string days-until-deadline)
> + "d.): " summary)
See above.
> + ;; Overdue and should bump.
> + (t
> + (org-icalendar--vevent
> +entry (org-icalendar-today-timestamp) (concat "SC-" uid)
> +(concat "S (" (number-to-string (- days-until-scheduled))
> "x): "
> +summary)
Ditto.
> Subject: [PATCH 2/6] Include tags in SUMMARY if so desired.
I'm ignoring this patch since it is superseded by the fifth. Could you
merge them?
> #+vindex: org-icalendar-categories
> #+vindex: org-icalendar-alarm-time
> +#+vindex: org-icalendar-summary-uses-tags
> For tags on the headline, the iCalendar export back-end makes them
> into iCalendar categories. To tweak the inheritance of tags and TODO
> states, configure the variable ~org-icalendar-categories~. To assign
> clock alarms based on time, configure the ~org-icalendar-alarm-time~
> -variable.
> +variable. Additionally, the variable
> +~org-icalendar-summary-uses-tags~ can be configured to have tags
> +appear in the title of the event, when SUMMARY is not provided.
I think this should go near the paragraph about
`org-calendar-include-body'.
> (defcustom org-icalendar-summary-uses-tags nil
> - "Non-nil means that TITLE+TAGS is used when SUMMARY is not provided.
> -If nil, then TITLE is used alone."
> + "Whether tags should be added to the title to create the summary.
Nitpick.
"Non-nil means" > "Whether" because it is more unambiguously informative
When non-nil, tags are added to ...
or
Non-nil means tags are added to ...
> (let ((tags (apply 'concat
> - (mapcar (lambda (x) (concat ":" x))
> - (org-export-get-tags entry info nil t)
> + (mapcar
> +(lambda (x) (concat ":" x))
> +(org-export-get-tags
> + entry info nil
> + (eq org-icalendar-summary-uses-tags
> 'all-tags))
(apply 'concat (lambda ...) ...) => (mapconcat (lambda ...) ...)
Could you send
