From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: Emacs bug 37890; killing capture buffer Date: Tue, 17 Dec 2019 17:07:35 -0700 Message-ID: References: <87r217lwwz.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50843) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihMsO-0001Kl-N6 for emacs-orgmode@gnu.org; Tue, 17 Dec 2019 19:07:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihMsN-0000RW-Dx for emacs-orgmode@gnu.org; Tue, 17 Dec 2019 19:07:40 -0500 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:46488) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihMsN-0000NI-1X for emacs-orgmode@gnu.org; Tue, 17 Dec 2019 19:07:39 -0500 Received: by mail-lj1-x22c.google.com with SMTP id z17so10994ljk.13 for ; Tue, 17 Dec 2019 16:07:38 -0800 (PST) In-Reply-To: <87r217lwwz.fsf@web.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Michael Heerdegen Cc: emacs-orgmode@gnu.org 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. 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.