Prevent `org-projectile-todo-completing-read` from opening `todo.org` in a new buffer

[xeijin]

I would like it to behave exactly as org-capture does today, that is pop-up a single buffer with the heading inserted ready to edit, and not additionally pop-up a buffer with the whole file (which seems to be the current, redundant behaviour of org-projectile-todo-completing-read

[colonelpanic8]

@xeijin This should be the behavior of org-projectile.

Can you reproduce this issue with a completely clean configuration? Org-projectile also offers a capture template so that you can use it through org-capture.

[xeijin]

Replicated with a fresh session emacs -q

;; org-projectile: issue with org file opening in separate buffer
;; when executing `org-projectile-project-todo-completing-read`

;; setup
(package-initialize)
(require 'package)
(setq package-selected-packages 'nil)
(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
             ("melpa" . "http://melpa.org/packages/")))
(package-refresh-contents)
(package-install 'projectile)
(package-install 'org-projectile)

;; add existing test project to list of projects
(projectile-add-known-project "~/projectile-issue-test")

;; from README (per-repo strategy)
(require 'org-projectile)
(org-projectile-per-project)
(setq org-projectile-per-project-filepath "my_project_todo_filename.org")
(setq org-agenda-files (append org-agenda-files (org-projectile-todo-files)))
(global-set-key (kbd "C-c c") 'org-capture)
(global-set-key (kbd "C-c n p") 'org-projectile-project-todo-completing-read)

here's a GIF of the test running - issue is visible at the end where you can see the additional buffer with the org file, separate to the capture buffer:

[xeijin]

@IvanMalison any news on this one?

[colonelpanic8]

I'm not really sure what would be causing this, it might have to do with recent changes.

[xeijin]

OK ... any plans to try and fix? If not going to need to roll my own ...

[colonelpanic8]

@xeijin No plans, but not sure why you wouldn't just try to fix the issue in org-projectile yourself rather than roll your own.

I've noticed that a few things have gotten wonky with the interaction with org-capture and this library recently. I would recommend you start by looking here:

https://github.com/IvanMalison/org-projectile/blob/0291ef425c96d02d634fc7e199146d7c3da0455b/org-category-capture.el#L71

and comparing that to the logic that it is attempting to emulate in org-capture. I suspect that some things have changed there, and fixing things might be as simple as making corresponding updates to this section of the code.

As evidenced by my comment there, I sort of always knew that something like this might happen. The real right way to fix this is to have org-capture be refactored so that the logic of setting up a capture is not so tightly intertwined with the UI/user interactions.

[xeijin]

@IvanMalison thanks! I was actually looking for a bit of a clue for where to get started, I did try taking a look myself initially, but I'm new to programming (as well as elisp) and haven't really wrapped my head around object-oriented stuff (which I assume is how you implemented).

I'll take a look and submit a PR if I get anywhere

[shrysr]

I was just about to ask for help on exactly the same issue and can confirm that the fix appears to solve it. Thank you both as this was getting rather annoying and I'm a elisp noob :).

Fwiw : I'm on Emacs 27.0.90 and using straight.el for my org mode files, and use a single file to capture all my project todo's.

[colonelpanic8]

@shrysr Yep, looks like #45 fixed this!

[colonelpanic8]

@jgrey4296 I had to revert #45 because of #46 . I would appreciate it if you could look in to it and try to come up with a fix that doesn't interfere with other stuff. #45 actually also broke the test suite. Make sure that whatever fix you come up with doesn't do that as well.

[komali2]

@IvanMalison thanks! I was actually looking for a bit of a clue for where to get started, I did try taking a look myself initially, but I'm new to programming (as well as elisp) and haven't really wrapped my head around object-oriented stuff (which I assume is how you implemented).

...then why were you demanding the author fix it for you, with threats of rolling your own? lmao

[xeijin]

@komali2 I'm not sure who you are, why you've decided you know -- and therefore can pass judgement on -- my intentions, why you've decided to publicly pick on a novice developer (hint: maybe someone on the same footing as you next time?) or even why you're replying to a comment that is almost a year old. What I do know is that you've contributed nothing to this thread and your comment doesn't reflect the values you proudly espouse. I spent time trying to debug the issue and presenting it best I could, the reply I received was ambiguous to me at the time, and I thought aloud. Hardly the salacious demand or threat you're so desperate to believe.

@IvanMalison for the avoidance of doubt, grateful for your work (which I still use today) and sincere apologies if that came across the wrong way at all.

[komali2]

Ayy haha I love when people hit me with my own value page.

No need to get heated man, I just get tired of people picking on OSS/Libre software people and call it out when I see it. You did a good thing by coming back here and apologizing to Ivan.

[colonelpanic8]

@xeijin The way that we emulate org-capture has completely changed now. I'm assuming this issue is gone, but feel free to reopen if it isn't.

[colonelpanic8]

Okay, I think I've understood what needs to happen. We need to reopen #46 and use separate functions for capture and goto location