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-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: org-note-abort Date: Sat, 21 Apr 2018 15:23:57 +0200 Message-ID: <87d0ysd76a.fsf@nicolasgoaziou.fr> References: <371527828.1457872.1523396932915.ref@mail.yahoo.com> <371527828.1457872.1523396932915@mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f9sUm-00009G-H0 for emacs-orgmode@gnu.org; Sat, 21 Apr 2018 09:24:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f9sUj-0007lO-Dy for emacs-orgmode@gnu.org; Sat, 21 Apr 2018 09:24:04 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:47785) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f9sUj-0007hs-8M for emacs-orgmode@gnu.org; Sat, 21 Apr 2018 09:24:01 -0400 In-Reply-To: <371527828.1457872.1523396932915@mail.yahoo.com> (Brad Knotwell's message of "Tue, 10 Apr 2018 21:48:52 +0000 (UTC)") 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: Brad Knotwell Cc: emacs-orgmode@gnu.org Hello, Brad Knotwell writes: > 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) entry capability.=C2=A0 Unlike the table-line, th= is > was an easier debug and I determined that org-note-abort was set to > t which ensures capture will always fail. > While I don't know exactly how I did it, I suspect it was something > like the following:* edit a template, test it and find it isn't quite > what you want* 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 > illuminating on this.=C2=A0 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 guessing something similar happened with the table-line > issue. I pushed a fix in maint. Could you test it and report if it solves your issue ? Regards, --=20 Nicolas Goaziou From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Knotwell Subject: Re: org-note-abort Date: Sun, 22 Apr 2018 16:12:24 +0000 (UTC) Message-ID: <952347247.3665436.1524413544180@mail.yahoo.com> References: <371527828.1457872.1523396932915.ref@mail.yahoo.com> <371527828.1457872.1523396932915@mail.yahoo.com> <87d0ysd76a.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3665435_20633595.1524413544178" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAHbM-0003Vl-Vj for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 12:12:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fAHbJ-0004hr-EX for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 12:12:32 -0400 Received: from sonic307-11.consmr.mail.ne1.yahoo.com ([66.163.190.34]:36919) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fAHbJ-0004gq-7q for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 12:12:29 -0400 In-Reply-To: <87d0ysd76a.fsf@nicolasgoaziou.fr> 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org ------=_Part_3665435_20633595.1524413544178 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good day Nicolas-- I had some time to test your changes (though not fully as I never could fig= ure out how to reproduce getting org-note-abort to stick at 't) and they ap= pear to be working.=C2=A0 In doing so, I noticed the following behaviors on= the table addition usecase: * regarding my earlier email that the table row was inconsistently added to= the file...I now understand how to make it work consistently.=C2=A0 If=C2= =A0 your "saved point" is *anywhere* in the file up to the start (inclusive= ) of the last line, your row will be added as you expect.=C2=A0 However, if= your point is even one character position forward, a new table will be cre= ated.* adding a row and aborting it (Ctrl-X Ctrl-K) on aquamacs is always u= nable to clean itself up in the table case.Thoughts on both issues: * I thought this might be due to an interaction with desktop mode (or maybe= it's aquamacs specific) and that I could workaround it by excluding the ta= rget file by customizing desktop-buffers-not-to-save.=C2=A0 Unfortunately, = that doesn't appear to work and it's possible a code change is necessary.* = When things work, this isn't a big deal as you can easily fixup/delete the = row yourself.=C2=A0 However, when you hit the previous issue, you need to s= eparately edit the file by hand. Thanks for the fixes. --Brad On Saturday, April 21, 2018, 6:24:01 AM PDT, Nicolas Goaziou wrote: =20 =20 Hello, Brad Knotwell writes: > 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) entry capability.=C2=A0 Unlike the table-line, th= is > was an easier debug and I determined that org-note-abort was set to > t which ensures capture will always fail. > While I don't know exactly how I did it, I suspect it was something > like the following:* edit a template, test it and find it isn't quite > what you want* 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 > illuminating on this.=C2=A0 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 guessing something similar happened with the table-line > issue. I pushed a fix in maint. Could you test it and report if it solves your issue ? Regards, --=20 Nicolas Goaziou =20 ------=_Part_3665435_20633595.1524413544178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Good day Nicolas--

I had some tim= e to test your changes (though not fully as I never could figure out how to= reproduce getting org-note-abort to stick at 't) and they appear to be wor= king. In doing so, I noticed the following behaviors on the table add= ition usecase:

* regarding my earlier email that t= he table row was inconsistently added to the file...I now understand how to= make it work consistently. If your "saved point" is *anywhere*= in the file up to the start (inclusive) of the last line, your row will be= added as you expect. However, if your point is even one character po= sition forward, a new table will be created.

* adding a row and a= borting it (Ctrl-X Ctrl-K) on aquamacs is always unable to clean itself up = in the table case.

Thoughts on both issues:

<= div>* I thought this might be due to an interaction with desktop mode (or m= aybe it's aquamacs specific) and that I could workaround it by excluding th= e target file by customizing desktop-buffers-not-to-save. Unfortunate= ly, that doesn't appear to work and it's possible a code change is necessar= y.

* When things work, this isn't a big deal as you can easily fi= xup/delete the row yourself. However, when you hit the previous issue= , you need to separately edit the file by hand.

Thanks for the fixes.

--Brad

=20

On Saturday, April 21, 2018, 6:24:01 AM PDT, Nicola= s Goaziou <mail@nicolasgoaziou.fr> wrote:

Hello,

Brad Knotwell <bknotwell@yahoo.com> = writes:

> Good day all--
> Earlier, I had written about the unreliability of adding
> a table-line. Well, I ran into a similar problem = with the
> (significantly simpler) entry capability.&n= bsp; Unlike the table-line, this
> was an easier debug= and I determined that org-note-abort was set to
> t w= hich ensures capture will always fail.
> While I don't= know exactly how I did it, I suspect it was something
&g= t; like the following:* edit a template, test it and find it isn't quite> what you want* make an (incorrect) change that sets br= eaks on
> insertion, sets org-note-abort to t and you'= re stuck until you reset
> it to nil by hand (remarkab= ly, 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
> illuminating on this.&n= bsp; It's important to note that while
> org-capture-k= ill sets org-note-abort to t, it's reset correctly when
&= gt; used in the normal way.
> Version: 9.1.7
> Thx and I'm guessing something similar happened with the tab= le-line
> issue.

= I pushed a fix in maint. Could you test it and report if it solves your
issue ?

=

Regards,

--
Nicolas Goaziou