emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs bug 37890; killing capture buffer


From: Adam Porter
Subject: Re: Emacs bug 37890; killing capture buffer
Date: Tue, 17 Dec 2019 12:53:12 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Michael Heerdegen <address@hidden> writes:

> Adam Porter <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]