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
=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
------=_Part_3665435_20633595.1524413544178--