unofficial mirror of emacs-orgmode@gnu.org
 help / color / mirror / Atom feed
* Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)]
@ 2020-09-25  0:16 this nkk
  2020-10-06 10:15 ` Nicolas Goaziou
  0 siblings, 1 reply; 3+ messages in thread
From: this nkk @ 2020-09-25  0:16 UTC (permalink / raw)
  To: emacs-orgmode


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.
------------------------------------------------------------------------
** what happened
when running org-id-find-id-in-file on an id and an unvisited file, the
buffer it creates to visit file isn't
closed after finding id.

** what should have happened
I was expecting it to close the buffer if the
file wasn't already visited by another buffer.

Is this desired behavior?

** background info and possible fix
I stumbled on this while looking at an issue with org-roam at
https://github.com/org-roam/org-roam/issues/1129.

For now a guard clause like the following in the calling function closes the
buffer if need be.

      (let (file-already-open-p return-val)
        (setq file-already-open-p (find-buffer-visiting file))
        (setq return-val (org-id-find-id-in-file id file markerp))
        (unless file-already-open-p (kill-buffer (find-buffer-visiting file)))
        (print return-val))

This logic can be propagated to the function to squash this possible
bug.


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3)
 of 2020-08-20
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)]
  2020-09-25  0:16 Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)] this nkk
@ 2020-10-06 10:15 ` Nicolas Goaziou
  2020-10-06 21:36   ` Samuel Wales
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Goaziou @ 2020-10-06 10:15 UTC (permalink / raw)
  To: this nkk; +Cc: emacs-orgmode

Hello,

this nkk <thisnkk@gmail.com> writes:

> when running org-id-find-id-in-file on an id and an unvisited file, the
> buffer it creates to visit file isn't
> closed after finding id.
>
> ** what should have happened
> I was expecting it to close the buffer if the
> file wasn't already visited by another buffer.
>
> Is this desired behavior?

It depends. If MARKERP is non-nil, you certainly don't want to close the
newly created buffer. Otherwise, it could be closed, indeed.

I patched master along these lines. Thank you.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)]
  2020-10-06 10:15 ` Nicolas Goaziou
@ 2020-10-06 21:36   ` Samuel Wales
  0 siblings, 0 replies; 3+ messages in thread
From: Samuel Wales @ 2020-10-06 21:36 UTC (permalink / raw)
  To: this nkk, emacs-orgmode

thank you to both of you from me too.

i have noticed that the same problem occurs for me with refile targets
alist.  putting a file there seems to open the buffer for some reason
and not close it even if it had not been closed.  this might require a
refile or an id lookup or so.

however, it does not require doing anything with that file.

i frequently get org archive files sticking around.  i am guessing
this is due to id lookup.


On 10/6/20, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,
>
> this nkk <thisnkk@gmail.com> writes:
>
>> when running org-id-find-id-in-file on an id and an unvisited file, the
>> buffer it creates to visit file isn't
>> closed after finding id.
>>
>> ** what should have happened
>> I was expecting it to close the buffer if the
>> file wasn't already visited by another buffer.
>>
>> Is this desired behavior?
>
> It depends. If MARKERP is non-nil, you certainly don't want to close the
> newly created buffer. Otherwise, it could be closed, indeed.
>
> I patched master along these lines. Thank you.
>
> Regards,
> --
> Nicolas Goaziou
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-06 21:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25  0:16 Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)] this nkk
2020-10-06 10:15 ` Nicolas Goaziou
2020-10-06 21:36   ` Samuel Wales

unofficial mirror of emacs-orgmode@gnu.org

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/orgmode/0 orgmode/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 orgmode orgmode/ https://yhetil.org/orgmode \
		emacs-orgmode@gnu.org
	public-inbox-index orgmode

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git