Re: Emacs bug 37890; killing capture buffer

[Michael Heerdegen <michael_heerdegen@web.de>]

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?

> > 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.

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?   @Adam
it's ok if you answer, though I'm a bit disappointed that no one else
seems to care so far...


Thanks,

Michael.