From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: Emacs bug 37890; killing capture buffer
Date: Tue, 17 Dec 2019 12:53:12 -0600 [thread overview]
Message-ID: <87h81yrdgn.fsf@alphapapa.net> (raw)
In-Reply-To: 87v9qedd4f.fsf@web.de
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Adam Porter <adam@alphapapa.net> writes:
>
>> I guess you're asking me, since I'm the only other person in this
>> thread--but I'm not an Org maintainer, so my opinion isn't very
>> important. IMO, the hooks are worth considering, however they should
>> be done very, very carefully, because bad things can happen when
>> functions called in kill hooks don't work as expected (e.g. they can
>> make it very difficult to kill a buffer or the Emacs process,
>> especially for an average user).
>
> Yes, all true. I didn't even check if the code I posted breaks any
> org commands that kill the buffer. So far it's only meant for
> demonstration (and my personal usage).
>
> Will my request be noticed here, or do you think I should report it to
> some other place?
I can't speak for what the maintainers are reading. They are active on
this list, as you can see, but I doubt they have time to read every
message. If you don't get the response you're looking for, you might
post the proposal in a separate thread, perhaps prefixed with [RFC] or
[PATCH] as appropriate. They're definitely more likely to notice and
respond to actual patches, but that's not a requirement; if you ask for
specific feedback about a specific idea or code, that usually gets
noticed.
>> > BTW, what about my question whether my original bug report can be
>> > closed?
>>
>> I haven't seen your bug report. Was there discussion about it
>> previously?
>
> No, no discussion at all. As I said, it is Emacs bug #37890, this was
> my issue:
>
> | I want to capture an APPT with `org-capture'. I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference). That loses the final newline in
> | CAPTURE-todo.org. As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> | <2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item. The user should somehow be prevented from that
> | happening.
>
> It seems it has been resolved, just without noticing my bug report.
> If you can confirm that the cited issue has been cared about, I'll
> close it as done.
I can neither confirm nor deny. ;) I do seem to recall discussion of
that issue here recently (the problem, not necessarily your official bug
report of it), and maybe seeing that a fix was made. If you search the
list archive for this month or November, you should find something--I
think that's the right timeframe. You might also search the git log for
capture-related commits. Shouldn't be hard to find if there was
something.
If it helps, none of my capture templates seem to end with newlines, and
I don't see anything in the docstring for org-capture-templates that
suggests one is required, so I don't think one is. If you're still
having the problem, I'd suggest trying to reproduce it in a clean Emacs
configuration with the latest version of Org. You may find this script
helpful for that:
https://github.com/alphapapa/alpha-org/blob/master/emacs-sandbox.sh
> BTW, what is the canonical place to report org-mode bugs? Emacs bug
> reports are not (takes a long time until someone even notices) -- I
> thought this list would be good...or is there a better place?
I think this list is a canonical place. Some people do report Org bugs
as official bug reports on the Emacs bug tracker. I don't know whether
the Org maintainers read them all. Since Org is officially part of
Emacs, sometimes the Emacs maintainers Cc this list about such reports.
Anyway, here is a fine place.
If you're not sure that something is a bug, you might consider
mentioning it on https://old.reddit.com/r/orgmode before posting it
here, since /r/orgmode has a wider audience.
> @Adam it's ok if you answer, though I'm a bit disappointed that no one
> else seems to care so far...
People do care! But everyone here works on Org in their spare time, and
Org is a big project, and things slip through the cracks.
next prev parent reply other threads:[~2019-12-17 18:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 21:48 Emacs bug 37890; killing capture buffer Michael Heerdegen
2019-12-14 5:05 ` Adam Porter
2019-12-15 22:31 ` Michael Heerdegen
2019-12-16 23:00 ` Michael Heerdegen
2019-12-17 17:40 ` Adam Porter
2019-12-17 18:24 ` Michael Heerdegen
2019-12-17 18:53 ` Adam Porter [this message]
2019-12-20 0:10 ` Michael Heerdegen
2019-12-18 1:20 ` Kyle Meyer
2019-12-18 2:16 ` Ihor Radchenko
2019-12-20 0:40 ` Michael Heerdegen
2019-12-18 0:07 ` Samuel Wales
2019-12-18 6:17 ` Fraga, Eric
2019-12-20 0:17 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h81yrdgn.fsf@alphapapa.net \
--to=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).