Re: Emacs bug 37890; killing capture buffer

[Samuel Wales <samologist@gmail.com>]

i might be completely off on this, but it seems the problem is that
there is a corrupted buffer.

in particular, there is a missing newline at the end of the narrowed
region in the capture buffer.  this causes the next header to join the
last line in the captured buffer.

i encountered this problem today.  i added a task and duplicated it.
this caused the corruption.  it also screwed up the stars level, but
never mind that.

so if i'm not completely off, which i might be, it's not so much
killing the buffer as the fact that the state is corrupted in the
first place.

if the state is corrupted by the lack of a newline at the end of the
capture buffer, that can be fixed by adding one there.  but the user
can screw that up by deleting it.

if the state is corrupted by the lack of a newline just after the
capture buffer, then that can be fixed -- maybe partly -- by adding a
newline there.

this seems to me to be the right thing to do.

i don't think this will create any blank lines.

but *if* it does, it is much better to have the computer crash with
the only corruption being the addition of a blank line, than to have a
header corrupted.

i am the designer of the indirect buffer capture idea.  i did not
implement it, however.

the indirect buffer capture mechanism was to be an improvement on
remember.el, and replaced it.  you might still be able to find
remember.el if you prefer the separate file idea.

not sure if my brain is working properly right now, but that's the basic idea.


<michael_heerdegen@web.de> wrote:
> Hi,
>
> I want to speak about my Emacs bug report 37890 about org-capture.
> Seems my main point:
>
> | 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.
>
> has been resolved with the latest merge into Emacs master - is that
> correct?  Then I will close that report.
>
> The report also included a feature request which I now want to tell
> here: I often kill the capture buffer instead of hitting C-c C-k.  Just
> by habit.  It's wrong and I now it but I guess it happens to others.
>
> I guess the capture buffer is just a narrowed indirect buffer copy of
> the buffer visiting the according org file.  Because of this, when you
> kill the capture buffer, the original buffer reflects the partial and
> uncomplete entry one tried to add.  This may damage your file.  But such
> internals are not known to all, so it would be good if killing the
> capture buffer, or even just closing the window, would warn the user and
> offer to undo the partial changes.  Or (really better IMHO) consider a
> different implementation where the original buffer is not modified until
> the user explicitly confirms the stuff to capture with C-c C-c.
>
> TIA,
>
> Michael.
>
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.