[PATCH] Fix indentation in test-org.el

buffer and re-indent. From 69ddca72e4744c8f3d3a552b760108bd17c676ae Mon Sep 17 00:00:00 2001 From: Allen Li Date: Sat, 25 Nov 2023 03:06:06 -0800 Subject: [PATCH] testing/lisp/test-org.el: Fix indentation The indentation in this file is all messed up. Fix it by loading test-org.el and org-test.el

[PATCH] Raise gc-cons-threshold for org-element-cache-map

: Allen Li Date: Wed, 23 Aug 2023 00:22:06 -0700 Subject: [PATCH] org-element: Raise gc-cons-threshold for org-element-cache-map This garbage collects many times when calling org-get-buffer-tags (such as during tag completion) in a large file with many tags. Raise gc-cons-threshold as this may

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

Attached On Sat, Jun 25, 2022 at 9:48 PM Ihor Radchenko wrote: > Allen Li writes: > > >> Would you also be interested to write a test checking org-todo ARGS? > >> > > > > Attached > > Thanks! However, it is unclear what this test is checking for. &g

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

On Fri, Jun 17, 2022 at 11:09 PM Ihor Radchenko wrote: > Ihor Radchenko writes: > > > Allen Li writes: > > > >> On Sat, Jan 1, 2022 at 9:31 AM Allen Li > wrote: > >> > >>> It seems like the right fix here is to make - behave the same

[BUG] C-u C-u C-u TAB regression on master

There appears to be a regression in the behavior of C-u C-u C-u TAB on master (at aea24b3feafb9c389dc5933005928462bb20c4f8). C-u C-u C-u TAB is supposed to show everything including drawers, but on this test file it does not show property drawers: Make a file containing 2000 copies of the

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

Ihor Radchenko writes: > Unfortunately, fixing the occurrences of (defvar foo nil) is not > completely straightforward. Some of them are real defvars. I see, I thought you meant those defvars were also used for dynamic scoping. > > If someone is willing to check all the occurrences of > (defvar

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

Ihor Radchenko writes: > Allen Li writes: > >>> I agree. The question is whether changing to >>> (defvar org-id-link-to-org-use-id) >>> solves your problem. >> >> Thanks for your concern. By editing ob-tangle.el, I can confirm that >> chan

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

Ihor Radchenko writes: > Allen Li writes: >> Even if org-id-link-to-org-use-id were always set at this point, there >> would be no reason to use >> >> (defvar org-id-link-to-org-use-id nil) >> >> instead of >> >> (defvar org-id-link-to-org-us

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

Ihor Radchenko writes: > Allen Li writes: > >> In ob-tangle.el, the line >> >> (defvar org-id-link-to-org-use-id nil) ; Dynamically scoped >> >> appears to override the user's customization of >> org-id-link-to-org-use-id. > > Have you seen

[BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

In ob-tangle.el, the line (defvar org-id-link-to-org-use-id nil) ; Dynamically scoped appears to override the user's customization of org-id-link-to-org-use-id. Specifically, this happens if the user has python in org-babel-do-load-languages, which leads to the require chain: require

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

On Sat, Jan 1, 2022 at 9:31 AM Allen Li wrote: > It seems like the right fix here is to make - behave the same as -1, and > raise a user error for any other negative numeric prefix, since it is > likely not doing whatever the user wanted. > Attached a small patch fixing this, wh

[BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

The docstring for org-todo (C-c C-t) is unclear about the handling of - prefix compared to -1 prefix. Here is the relevant part of the docstring: With ‘C-u’ prefix ARG, force logging the state change and take a logging note. With a ‘C-u C-u’ prefix, switch to the next set of TODO

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: >> Yes, I think using only ":" and "," is the best default option. I >> still >> don't think there is a need to make it customizable (I doubt anyone >> is >> typing tags separated with ! or @ or #), but I suppose >> there's minimal harm from doing so. > > I don't see the need to

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: > Allen Li writes: >> The question here is, which behavior do we want? My philosphy >> is that >> programs shouldn't try to silently re-interpret the user's >> intentions. >> For example, if I accidentally mistyped the tag "green_blue

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: > org-set-tags-command correctly parses the tags when using a comma > (the default > crm-separator) to separate them, but completion is broken unless > ":" is used as > the separator. > org-capture-fill-template incorrectly parses this. > > Reproducible from emacs -Q: > >

Re: Bug: Unexpected behavior marking recurring tasks as DONE

On Fri, Jul 9, 2021 at 7:49 AM Alan Ristow wrote: > On 7/8/21 8:19 PM, Bhavin Gandhi wrote: > >>> Second, if I bulk-process a habit via org-agenda-bulk-action, the task > >>> is simply marked DONE. Bot the recurrence and the LAST_REPEAT field > >>> are ignored, but the time stamp is only entered

Bug: [PATCH] Use crm for tag completion [9.4.6 (9.4.6-gab9f2a @ /home/ionasal/.emacs.d/elpa/org-9.4.6/)]

attached a patch for this change, which I have tested manually a few times and also fixed the existing tests. I have tested this with vertico, which claims to strictly follow Emacs's completion API. >From 933dc914694c14889af86c06ba0a8bbd88a316cf Mon Sep 17 00:00:00 2001 From: Allen Li Date: Thu

Adding a goto-heading protocol to org-protocol

I have a feature request that I'm wondering whether it would be suitable. The idea is to add a new protocol that looks like "org-protocol://goto-heading?id=UUID-HERE" that jumps to the specified Org heading in Emacs. The implementation is really simple: ;;;###autoload (defun goto-heading (arg)

Re: Starting from 9.5, Org contrib will be distributed as a separate NonGNU ELPA package

Bastien writes: > Hi all, > > starting from Org 9.5, org-contrib will be distributed as a NonGNU > ELPA package. You will find it here: https://elpa.nongnu.org/nongnu/ > > See for https://orgmode.org/list/87wnzfy60h@bzg.fr/ for context. > > Thanks, Will there be an overlapping period (and

Re: [PATCH] Query when exiting with running clock

On Wed, Feb 3, 2021 at 5:45 AM Kyle Meyer wrote: > > Allen Li writes: > > > This is a patch adding a query function when exiting Emacs, warning the > > user if there is a running clock. This is useful for preventing the > > user from accidentally leaving dangling

[PATCH] Query when exiting with running clock

cal functions that I noticed when preparing the first patch. >From f6145afd7d457cec533c44c8a3297d28f11d7255 Mon Sep 17 00:00:00 2001 From: Allen Li Date: Tue, 12 Jan 2021 00:26:47 -0800 Subject: [PATCH 1/2] org-clock: Replace org-clocking-buffer with org-clock-is-active org-clocking-buffer

Bug: 9.4 Regression in handling of empty #+TAGS: [9.4 (9.4-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200914/)]

Previously, placing an empty #+TAGS: in a file would override org-file-tags for the file. In 9.4, an empty #+TAGS: is ignored and org-file-tags is used. The relevant code in org.el: (setq org-current-tag-alist (org--tag-add-to-alist org-tag-persistent-alist

Re: [feature request] A new cookie type [!] showing the last note taken

On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko wrote: > > Over the years of using Org I often have a need to add a short note > about how to proceed with some task: > > * REVIEW check again, subscribe | sindresorhus/awesome:  Awesome > lists about all kinds of interesting topics :BOOKMARK:

Re: Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

On Fri, Aug 21, 2020 at 8:39 AM Allen Li wrote: > > Kyle Meyer writes: > > > That looks good as far as fixing the misbehavior you report. I wonder > > though whether there's a deeper org-get-tags issue here worth > > considering. Its documentation says > > >

Re: Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

Kyle Meyer writes: > That looks good as far as fixing the misbehavior you report. I wonder > though whether there's a deeper org-get-tags issue here worth > considering. Its documentation says > > ... the returned list of tags contains tags in this order: file > tags, tags inherited

Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

will be refiled to a different location later). Attached patch. >From 934d65537e46c68c10edbfa2d7140cebfe89d271 Mon Sep 17 00:00:00 2001 From: Allen Li Date: Tue, 18 Aug 2020 15:34:38 -0700 Subject: [PATCH] org.el: Don't exclude local tags that are also inherited * lisp/org.el (org-set-t

Re: Delete duplicate subtrees?

On Wed, Aug 5, 2020 at 6:16 PM David Rogers wrote: > > Hello > > I've copied text from several different sources into an org > buffer, and now I find I have a large number of subtrees that are > exactly the same. All headlines are at the top level, so there are > no duplicates at different levels

Bug: New agenda filtering multiple tags broken [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)]

The new agenda filtering doesn't seem to work properly with multiple tags. Opening the file below, e.g., at /tmp/tmp.org * TODO foo :foo: * TODO bar :foo:bar: * TODO baz Open

Bug: C-c C-k show branches also expands archived headings [9.3.1 (9.3.1-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191226/)]

The command org-kill-note-or-show-branches bound to C-c C-k when used to show branches also expands headings tagged with :ARCHIVE:. This is contrary to expectations, as the manual states: ‘C-c C-k’ (‘outline-show-branches’) Expose all the headings of the subtree, CONTENTS view for just one

Re: Properties Drawer versus tags

On Fri, Dec 20, 2019 at 3:25 PM Lawrence Bottorff wrote: > > Very simple, largely philosophical question: When/why use a properties drawer > below a heading versus just using tags on the heading? What are the > advantages, disadvantages of both? I believe tag filtering has better performance

Re: Can Org warn me if I create a time conflict?

On Wed, Dec 18, 2019 at 7:06 AM David Rogers wrote: > > It's currently possible for me to create two meeting times, one from > 8:00-10:00 tomorrow and the other from 9:00-11:00 tomorrow. > > When both are mentioned in the same sentence, as above, it's easy to > recognize that the two meetings

Re: Bug: org-use-fast-todo-selection prefix option removed [9.3 (9.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20191203/)]

On Thu, Dec 12, 2019 at 10:48 AM Kyle Meyer wrote: > > Allen Li writes: > > > The option to set org-use-fast-todo-selection to 'prefix was removed > > without my noticing. This breaks my workflow since I like the default > > cycling behavior and only occasiona

Bug: org-use-fast-todo-selection prefix option removed [9.3 (9.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20191203/)]

The option to set org-use-fast-todo-selection to 'prefix was removed without my noticing. This breaks my workflow since I like the default cycling behavior and only occasionally use fast todo selection to switch between todo state sets. It was removed in commit

Bug: org-agenda-skip-unavailable-files removes files instead of skipping [9.2.6 (9.2.6-5-g9c611f-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191111/)]

The docstring for org-agenda-skip-unavailable-files says: Non-nil means to just skip non-reachable files in ‘org-agenda-files’. A nil value means to remove them, after a query, from the list. However, doing a grep over the org mode code, the only place where this variable is checked is in

[O] Bug: org-agenda-set-tags with certain options sets tags on wrong entry [9.2.3 (9.2.3-13-g727c3f-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20190506/)]

Repro: 1. emacs -Q 2. Eval: (setq org-tag-alist '(("agenda" . ?a))) (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20190506") (define-key global-map (kbd "C-c a") #'org-agenda) (setq switch-to-buffer-preserve-window-point t) 3. Make a tmp.org containing: * TODO foo * TODO bar 4.

[O] Bug: Preserving agenda settings per buffer? [9.2.3 (9.2.3-7-g222408-elpaplus @ .emacs.d/elpa/org-plus-contrib-20190415/)]

Example variables: org-agenda-todo-list-sublevels org-agenda-dim-blocked-tasks If org-agenda-dim-blocked-tasks is default true, and you have custom agenda views foo and bar, where bar sets this to false, opening bar will result in an agenda view where blocked tasks are not dimmed, but if you go

[O] Bug: Capture prepend checkbox doesn't handle scheduled [9.2.3 (9.2.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20190402/)]

Make file /tmp/tmp.org containing: * TODO Foo SCHEDULED: <2019-04-08 Mon> 1. emacs -Q 2. Eval (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-plus-contrib-20190402/")) (setq org-capture-templates '(("c" "Capture" checkitem (file+headline "/tmp/tmp.org" "Foo") "" :prepend t))) 3.

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

e two variable names are somewhat confusing. Could > `org-agenda-local-overriding-columns-format' be renamed into > `org-local-columns-format'? Since it is defined in "org-colview.el", it > doesn't deserve the "org-agenda" prefix (and neither does the original > `org-agenda

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

On Wed, Feb 13, 2019 at 8:17 AM Allen Li wrote: > > 0. Make /tmp/tmp.org containing > > * TODO foo bar > > 1. emacs -Q > 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" > ((org-agenda-overriding-columns-format "%TODO"

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

Apologies for the spam. On Wed, Feb 13, 2019 at 9:11 AM Allen Li wrote: > I don't see an easy good fix due to how Emacs's dynamic variable > binding works with respect to buffer local variables. > > One way to fix is redefine: > > (defun org-let (list body) > (eval `(wi

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

On Wed, Feb 13, 2019 at 8:37 AM Allen Li wrote: > > I'm suspicious of org-agenda-mode -> kill-all-local-variables= > > One oddity is that repeatedly reverting the buffer swaps between the > "correct" overriding column format and the default. It seems like what is happ

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

On Wed, Feb 13, 2019 at 8:17 AM Allen Li wrote: > > 0. Make /tmp/tmp.org containing > > * TODO foo bar > > 1. emacs -Q > 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" > ((org-agenda-overriding-columns-format "%TODO"

[O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

0. Make /tmp/tmp.org containing * TODO foo bar 1. emacs -Q 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" ((org-agenda-overriding-columns-format "%TODO") 3. Eval (setq org-agenda-files '("/tmp/tmp.org")) 4. M-x org-agenda RET n 5. Move point to item 6. C-c C-x C-c (column

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Wed, Dec 19, 2018 at 6:11 AM Nicolas Goaziou wrote: > > Hello, > > Allen Li writes: > > > Okay, thanks. I guess we can see how this works out with respect to users > > like Brent using org-tags-match-list-sublevels or otherwise using > > hierarchy

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Tue, Dec 18, 2018 at 3:18 AM Nicolas Goaziou wrote: > > Hello, > > Allen Li writes: > > > Perhaps the stars should only be shown if > > org-tags-match-list-sublevels is set to indented, so that the agenda > > view matches > > the column view with re

Re: [O] Package System questions ?

On Fri, Dec 14, 2018 at 3:46 PM David Masterson wrote: > > Am I reading the startup process right? > > In GNU Emacs v26+, it appears that package-initialize is run out of > startup.el which is run (I think) before the various "init" files. > Therefore, it is hardcoding the assumptions that: > >

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Fri, Dec 14, 2018 at 6:36 AM Bernt Hansen wrote: > > > In my custom agenda view for Projects I set > (org-tags-match-list-sublevels 'indented) Good to know, although I see that setting org-tags-match-list-sublevels to anything other than t is semi-obsolete. However, we are talking mostly

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Thu, Dec 13, 2018 at 6:28 AM Bernt Hansen wrote: > > Allen Li writes: > > > On Wed, Dec 12, 2018 at 10:00 AM Nicolas Goaziou > > wrote: > >> > >> This is not satisfying, actually. If every item has a single asterisk, > >> you miss hierarc

Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

On Wed, Dec 12, 2018 at 9:59 AM Nicolas Goaziou wrote: > > Could you give more context about the bug you're encountering? What does > mean "function correctly if a URL was not provided"? What is the use > case? What result did you expect, besides not encountering an error > message? The issue

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Wed, Dec 12, 2018 at 10:00 AM Nicolas Goaziou wrote: > > This is not satisfying, actually. If every item has a single asterisk, > you miss hierarchy between headlines in the same tree. I don't know what you mean. Hierarchy is not displayed normally in agenda view anyway, I don't know why

Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

-capture is documented to need a URL, it seems wrong for it to corrupt org-stored-links but otherwise function correctly if a URL was not provided. On Tue, Dec 11, 2018 at 7:18 PM Allen Li wrote: > > Using Org protocol capture without supplying a URL inserts a corrupt > entry into org-sto

[O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

Using Org protocol capture without supplying a URL inserts a corrupt entry into org-stored-links (nil ""). The nil causes a type error later in org-insert-link. (defun org-protocol-do-capture (info) "Perform the actual capture based on INFO." (let* ((temp-parts (org-protocol-parse-parameters

Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou wrote: > > (((headline (:raw-value "stuff" :begin 17 :end 36 :pre-blank 0 > > :contents-begin 26 :contents-end 36 ...)) 17 35)) > > `org-element-at-point' ignores narrowing. Yes, but my issue is with the fact that the entry bounds reported by

[O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

org-map-entries narrows the buffer to narrower than the given entry. 1. Run: cat > /tmp/tmp.org <

[O] [PATCH] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

Attached patch fixing this. This was caused by a bug in a feature that I did not realize existed (prefixing each line in %i). I have also included patches to clarify the documentation. On Fri, Dec 7, 2018 at 6:12 PM Allen Li wrote: > > There's an escaping bug in Org capture: > >

[O] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

There's an escaping bug in Org capture: 1. emacs -Q 2. Evaluate: (setq org-capture-templates '(("Z" "org-protocol capture" entry (file "/tmp/tmp") "* %? %(let ((x \"%:annotation\")) (if (string= x \"\") \"\" (concat x \"\\n\")))%i"))) 3. Evaluate (require 'org-protocol) 4.

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Thu, Dec 6, 2018 at 6:35 AM Nicolas Goaziou wrote: > We could ignore the level when displaying ITEM in agenda column view. As > a consequence, every item would start with a single star, which is > shorter and still not confusing. Sounds good to me. > > WDYT? > > Regards, > > -- > Nicolas

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Tue, Dec 4, 2018 at 2:14 AM Allen Li wrote: > > Or did you mean ITEM omits the stars? That doesn't appear to be the > case as of 04641c4bbefc5f90e05fe4e846f4aeab15f1c262 on master > yesterday. So org-entry-properties does indeed return ITEM without the leading stars, but the colu

Re: [O] Bug: Special property ITEM without stars [9.1.14]

On Mon, Dec 3, 2018 at 2:57 PM Nicolas Goaziou wrote: > > Hello, > > Allen Li writes: > > > (I used org-submit-bug-report, but this is a feature request.) > > > > It would be nice to have a special property like ITEM > > without the leading stars, which

[O] Bug: Special property ITEM without stars [9.1.14]

(I used org-submit-bug-report, but this is a feature request.) It would be nice to have a special property like ITEM without the leading stars, which is annoying in, e.g., the agenda column view. I imagine that this will be easy to implement. There may be some UI implications (confusing in some

Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

On Tue, Oct 2, 2018 at 2:14 PM Bernt Hansen wrote: > > Nicolas Goaziou writes: > > > Hello, > > > > Allen Li writes: > > > >> org-insert-structure-template (C-c C-,) leaves point at an inconvenient > >> place (X marks the spot): > &g

Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

On Tue, Oct 2, 2018 at 8:06 AM Nicolas Goaziou wrote: > > Hello, > > Allen Li writes: > > > org-insert-structure-template (C-c C-,) leaves point at an inconvenient > > place (X marks the spot): > > > > #+begin_example > > X#+end_example > &g

[O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

org-insert-structure-template (C-c C-,) leaves point at an inconvenient place (X marks the spot): #+begin_example X#+end_example My expectation is that right after inserting the template, I can start typing or yank right into it: #+begin_example X #+end_example Emacs : GNU Emacs 26.1 (build

[O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]

org-toggle-tag always marks the buffer as modified due to how it is implemented. It would be better if it did not mark the buffer modified if it does not change anything. This is annoying for org-depend.el (which is contrib, not officially supported) because the org-blocker-hook set by

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

On Wed, Feb 28, 2018 at 12:25 AM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > Allen Li <darkfel...@felesatra.moe> writes: > >> > I modified the example a bit and made the undesired behavior unclear. > >> > > >> > * foo >

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

On Mon, Feb 26, 2018 at 3:11 PM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > Allen Li <darkfel...@felesatra.moe> writes: > > I modified the example a bit and made the undesired behavior unclear. > > > > * foo > > :PROPERTIES: > > :ID

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

On Mon, Feb 26, 2018 at 5:54 PM Samuel Wales wrote: > On 2/26/18, Nicolas Goaziou wrote: > > I guess these are rhetorical questions because I answered them above. > real questions, fyi, but never mind. > >> if not, then i will have to use local

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

On Thu, Feb 15, 2018 at 1:02 PM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > Allen Li <darkfel...@felesatra.moe> writes: > > With the org file: > > > > * foo > > some content > > * bar > > some content 1 > > some content

[O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

With the org file: * foo some content * bar some content 1 some content 2 1. C-s foo RET 2. C-c C-x C-w 3. C-r some RET 4. C-c C-x C-y Final content is * bar some content 1 * foo some content some content 2 The behavior is insidious when the contents are folded: * foo... * bar... turns into

Re: [O] [Bug] M-S Ret keybinding translated to M-Ret

Thanks, your new patch looks acceptable to me. On Fri, Feb 9, 2018 at 7:02 AM Matt Lundin <m...@imapmail.org> wrote: > Allen Li <vianchielfa...@gmail.com> writes: > > > On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin <m...@imapmail.org> wrote: > > > &g

Re: [O] [Bug] M-S Ret keybinding translated to M-Ret

On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin wrote: > Matt Lundin writes: > > I discovered that when trying to insert a new item with a checkbox using > > M-S Return (org-insert-todo-heading), the keybinding is "translated" to > > M-Return (org-meta-return).

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

On Tue, Jan 30, 2018 at 3:15 PM, Samuel Wales wrote: > On 1/30/18, Nicolas Goaziou wrote: >> With local ring, you do, not with global one. That is standard Emacs >> behaviour. > > does this constitute a change in org behavior? i'd want the same >

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

I was not aware Org had its own mark ring, and I see no use for it personally when Emacs's mark ring exists. On Mon, Jan 29, 2018 at 3:21 PM, Nicolas Goaziou wrote: > Hello, > > As the title suggests, I'm wondering if we could remove Org's own > implementation of the mark

Re: [O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]

On Fri, Jan 19, 2018 at 1:35 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> C-c C-k unfolds archived headings. I am using it/interpreting it as a >> subtree variant to S-TAB, which shows the CON

[O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]

C-c C-k unfolds archived headings. I am using it/interpreting it as a subtree variant to S-TAB, which shows the CONTENTS headlines only view without unfolding archived headings. Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26) of 2017-12-04 Package: Org mode version 9.1.6

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Tue, Jan 2, 2018 at 6:36 AM, Robert Horn <rjhorn...@gmail.com> wrote: > > Allen Li writes: > >> On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter <a...@alphapapa.net> wrote: >> >> I don’t see a use case for checking all heading data. >> > > I

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Tue, Jan 2, 2018 at 7:28 AM, Florian Beck wrote: > >> AFAIK, this is the first time this need is expressed on this ML. There >> is no equivalent in "org-list.el" either. > > > A way to handle duplicates would be useful, indeed. But a basic function > should only remove

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Tue, Jan 2, 2018 at 8:36 AM, Nick Dokos <ndo...@gmail.com> wrote: > Allen Li <vianchielfa...@gmail.com> writes: >> >> There is always undo and automatic Emacs file backups. >> > > There be dragons. > > The problem is that some things happen invisi

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter <a...@alphapapa.net> wrote: > Allen Li <vianchielfa...@gmail.com> writes: > >> I don’t know if a more intelligent way of handling tags and todo >> keywords is worth the extra complexity, but in the use case that I >> i

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Mon, Jan 1, 2018 at 10:26 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Allen Li <vianchielfa...@gmail.com> writes: > >> Org mode is fundamentally an outliner, and one often makes lists with >> an outliner. Filtering out duplicates from a list see

Re: [O] New feature? Remove duplicate subheadings, preserving order

On Mon, Jan 1, 2018 at 2:04 AM, Nicolas Goaziou wrote: > Duplicates headings are not necessarily wrong. I think this is too > specific to be integrated in Org proper. > > Maybe we could add a check for duplicates headings in Org Lint instead, > and add this to Worg, in a

[O] New feature? Remove duplicate subheadings, preserving order

I wrote a command to remove duplicate subheadings, which I use to remove duplicate captured links among other things. Would this be a useful addition to Org mode? I have included it below for reference. I will clean it up a bit if it's a worthy feature. (defun mir-org-uniq () "Remove

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

On Sat, Dec 30, 2017 at 3:57 AM, Bastien wrote: > Hi Achim, > > Achim Gratz writes: > >> Am 29.12.2017 um 13:26 schrieb Bastien Guerry: >>> Migrating to a new vultr instance was easier than trying to upgrade >>> the rackspace hosting service and the vultr pricing

Re: [O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

Bastien From 21d8d507474ac3faa5b1ea9dfa7aa3647cddd8af Mon Sep 17 00:00:00 2001 From: Allen Li <darkfel...@felesatra.moe> Date: Sat, 30 Dec 2017 03:41:51 -0800 Subject: [PATCH] Remove agenda-archives even with buffer restriction * lisp/org-agenda.el (org-search-view): Remove agenda-archives eve

Re: [O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

On Sat, Dec 30, 2017 at 3:38 AM, Allen Li <vianchielfa...@gmail.com> wrote: > Doing a text agenda search with org-agenda-text-search-extra-files > set to (agenda-archives) and with a buffer restriction results in an error: > > Debugger entered--Lisp error: (wrong-type-argum

[O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

Doing a text agenda search with org-agenda-text-search-extra-files set to (agenda-archives) and with a buffer restriction results in an error: Debugger entered--Lisp error: (wrong-type-argument stringp agenda-archives) file-exists-p(agenda-archives) #[(a b) "\302 !\205 \302 !\205 \303

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

On Fri, Dec 29, 2017 at 4:26 AM, Bastien Guerry wrote: > Hi Achim, > > Achim Gratz writes: > >> And if you'd read through the entirety of the Register article you >> linked to you'd find that presumably any existing OSS hosting would >> continue to be free, so

Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

On Thu, Dec 21, 2017 at 5:55 PM, Ihor Radchenko wrote: > > org-clock-in in org-clock.el calculates org-clock-total-time via calling > (org-clock-sum-current-item (org-clock-get-sum-start)). > However, org-clock-get-sum-start returns the time in UTC, which is not

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

On Mon, Dec 11, 2017 at 6:10 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> On Wed, Dec 6, 2017 at 12:19 PM, Allen Li <vianchielfa...@gmail.com> wrote: >>> (Can reproduce with Org 9

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

On Sat, Dec 9, 2017 at 4:41 PM, Nathan Aclander wrote: > > Nicolas Goaziou writes: > >> I don't qualify this as a bug. These commands explicitly work when point >> is at the beginning of an item. Indeed, the sub-item may be arbitrarily >> large,

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

On Mon, Dec 4, 2017 at 11:59 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> >> wrote: >>> He

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

On Wed, Dec 6, 2017 at 12:19 PM, Allen Li <vianchielfa...@gmail.com> wrote: > (Can reproduce with Org 9.1.3, submitting with emacs -Q) > > Using a file tmp.org: > > * Foo > ** Archive :ARCHIVE: > *** Test > :PROPERTIES: > :ARCHIVE_TIME:

[O] bug#28263: bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

On Wed, Dec 6, 2017 at 7:23 AM, Drew Adams wrote: > [paraphrased] Org should not suggest user reserved key bindings I agree with you in general. However, when I first started using Emacs for Org mode years ago, I found the documentation very helpful. Furthermore, I did

[O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

(Can reproduce with Org 9.1.3, submitting with emacs -Q) Using a file tmp.org: * Foo ** Archive :ARCHIVE: *** Test :PROPERTIES: :ARCHIVE_TIME: 2017-12-06 Wed 12:13 :END: ** Bar This appears like so with default visibility: * Foo ** Archive :ARCHIVE:...

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

On Tue, Dec 5, 2017 at 7:15 AM, Drew Adams wrote: > > That's even worse, IMHO. And hardly "as neutral as possible". > > > > Just one opinion. Could you summarize how you think the situation could be improved in one or two sentences? I think what you are trying to say

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[O] Bug: org-attach-directory should be safe [9.1.3 (9.1.3-10-gadfbfd-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)]

org-attach-directory should be safe to set as a file local or directory local string. This allows the user to set a directory local attachment directory for all Org files in a directory tree recursively. I do not believe there are any security issues to enable arbitrary Org files to set

[O] Org mode bug submission and viewing?

What's the proper way to submit an Org mode bug, and are the bugs collected anywhere for viewing their status? I see the mailing list has bugs generated using org-submit-bug-report (containing "Bug:" in the subject) and other bugs that have numbers ("bug#:" in the subject). Is there a

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou wrote: > Hello, > > Jan Böhm writes: > >> Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave >> just like normally setting todo state to "DONE" with org-todo. >> Specifically, the

Re: [O] Bug: ordered property blocks grandchildren [9.1.3 (9.1.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171116/)]

On Mon, Nov 20, 2017 at 5:18 PM, Allen Li <vianchielfa...@gmail.com> wrote: > Create a file tmp.org with contents > > * TODO parent > :PROPERTIES: > :ORDERED: t > :END: > ** TODO child1 > ** TODO child2 > *** TODO grandchild1

  1   2   >