From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Knotwell Subject: org-note-abort Date: Tue, 10 Apr 2018 21:48:52 +0000 (UTC) Message-ID: <371527828.1457872.1523396932915@mail.yahoo.com> References: <371527828.1457872.1523396932915.ref@mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1457871_992001978.1523396932913" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f618Q-0006iY-WB for emacs-orgmode@gnu.org; Tue, 10 Apr 2018 17:49:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f618N-0006y4-0l for emacs-orgmode@gnu.org; Tue, 10 Apr 2018 17:49:03 -0400 Received: from sonic308-11.consmr.mail.ne1.yahoo.com ([66.163.187.34]:43523) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f618M-0006xo-SF for emacs-orgmode@gnu.org; Tue, 10 Apr 2018 17:48:58 -0400 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: emacs-orgmode@gnu.org ------=_Part_1457871_992001978.1523396932913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good day all-- Earlier, I had written about the unreliability of adding a table-line.=C2= =A0 Well, I ran into a similar problem with the (significantly simpler) ent= ry capability.=C2=A0 Unlike the table-line, this was an easier debug and I = determined that org-note-abort was set to t which ensures capture will alwa= ys fail. While I don't know exactly how I did it, I suspect it was something like th= e following:* edit a template, test it and find it isn't quite what you wan= t* make an (incorrect) change that sets breaks on insertion, sets org-note-= abort to t and you're stuck until you reset it to nil by hand (remarkably, = I've had to do the same thing with inhibit-trace as well). Searching the mailing list and looking at Google hasn't been any more illum= inating on this.=C2=A0 It's important to note that while org-capture-kill s= ets org-note-abort to t, it's reset correctly when used in the normal way. Version: 9.1.7 Thx and I'm guessing something similar happened with the table-line issue. --Brad ------=_Part_1457871_992001978.1523396932913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good day all--

Earlier, I had written about the unreliability of adding a table-li= ne.  Well, I ran into a similar problem with the (significantly simple= r) entry capability.  Unlike the table-line, this was an easier debug = and I determined that org-note-abort was set to t which ensures capture wil= l always fail.

While I don't know exactly how I di= d it, I suspect it was something like the following:
* edit a tem= plate, test it and find it isn't quite what you want
* make an (i= ncorrect) change that sets breaks on insertion, sets org-note-abort to t an= d you're stuck until you reset it to nil by hand (remarkably, I've had to d= o the same thing with inhibit-trace as well).

Sear= ching the mailing list and looking at Google hasn't been any more illuminat= ing on this.  It's important to note that while org-capture-kill sets = org-note-abort to t, it's reset correctly when used in the normal way.

Version: 9.1.7

Thx and I'm gu= essing something similar happened with the table-line issue.

=
--Brad
------=_Part_1457871_992001978.1523396932913--