Unclear if buttercup-level problem, but ... before-each block doesn't seem to work more than once sometimes.

[Trevoke]

This test file has a describe block, a before-each block, an after-each block, a nested describe block, then two tests.

https://github.com/Trevoke/org-gtd.el/blob/master/test/projects-test.el

The setup code is in:

• https://github.com/Trevoke/org-gtd.el/blob/master/test/helpers/setup.el#L5
• https://github.com/Trevoke/org-gtd.el/blob/master/test/helpers/setup.el#L12 (empty function)
• https://github.com/Trevoke/org-gtd.el/blob/master/test/helpers/setup.el#L25
• https://github.com/Trevoke/org-gtd.el/blob/master/test/helpers/processing.el#L6

The first test runs fine. The second test needs a chunk of the before block added to it otherwise it will fail, for reasons I cannot understand. I am setting variables with setq so I don't think that's it.

You can see a commented-out test in the test file. That test fails telling me that C-c c is not an existing keybinding, even though that is defined in (ogt--configure-emacs), which is bound to a function in the before-each block.

Can you help me figure out what's breaking here?

[snogge]

Sorry for not seeing this sooner. Turns out gmail has stopped showing me notifications on my phone :( Anyway.

I think your buffer management is messed up somehow. The current buffer in before-each is *scratch*, so some of the project content end up in that buffer. You add the C-c c p keyboard macro to org-gtd-process-map but you then invoke the macro in the *scratch* buffer. Is the keymap active there?

I also see problems with org-add-log-note in post-command-hook. Don't know if that is relevant.

I have not tried to really understand org-gtd, but I think the items above are probably some things you need to look at.

[snogge]

Hi @Trevoke , did you figure out what the problem was?

[Trevoke]

Hello, thanks for the ping!

Alright, so you're right, some of the project content does end up in that buffer. Here's what's interesting though.

In the first test ("on a task in the agenda") this does not happen. And it should not happen.

ogt--add-and-process-project leverages org-capture, so it shouldn't be putting anything in the scratch buffer (this, I think, does not happen).

org-gtd-process-inbox, however, sets the current buffer to (org-gtd--inbox-file) - the buffer returned by that function - and that should never be the scratch buffer, which means that for some reason in that second test, the following code does not work as expected:

  (set-buffer (org-gtd--inbox-file))
  (display-buffer-same-window (org-gtd--inbox-file) '())
  (delete-other-windows) ;; included in case it's relevant
  (org-gtd-process-mode t) ;; this enables the keymap with `C-c c`

According to the setup code in before-each, emacs should always be looking at a new temporary directory :

  (setq org-gtd-directory (make-temp-file "org-gtd" t)
        org-gtd-process-item-hooks '()
        org-gtd-refile-to-any-target nil)

  (define-key org-gtd-process-map (kbd "C-c c") #'org-gtd-choose))

So I don't understand why in that test I have to set the org-gtd-directory myself, in the test.

[snogge]

Hi again @Trevoke,

I did some digging, and it seems that when the before-each block executes for the second test ("when on the heading"), an error is thrown from post-command-hook (org-add-log-note) (error "Marker does not point anywhere").

This is while executing the M-> RET kbd macro. For some reason this will make *scratch* the current buffer again. And then all bets are off as the current buffer is not the right mode and does not have the expected content.

I have no idea why the second before-each behaves differently from the first one.

[snogge]

This does not look like a buttercup problem, and there has been no response from the OP for 4 months. I'll close this issue now. Feel free to open it again for further discussion.