From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Refiling list items Date: Mon, 08 Aug 2011 20:20:25 -0400 Message-ID: <13875.1312849225@alphaville.americas.hpqcorp.net> References: <8762m8ns2e.fsf@gmail.com> <87d3gfmrpy.fsf@gmail.com> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:39230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqa3X-0002Hq-Ty for emacs-orgmode@gnu.org; Mon, 08 Aug 2011 20:20:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qqa3W-0001EO-Nm for emacs-orgmode@gnu.org; Mon, 08 Aug 2011 20:20:27 -0400 Received: from g5t0009.atlanta.hp.com ([15.192.0.46]:27816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqa3W-0001EK-K3 for emacs-orgmode@gnu.org; Mon, 08 Aug 2011 20:20:26 -0400 In-Reply-To: Message from Jeff Horn of "Mon, 08 Aug 2011 19:47:33 EDT." 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Jeff Horn Cc: Org-mode ml , nicholas.dokos@hp.com, Nicolas Goaziou Jeff Horn wrote: > > What would be the specifications of that function? Would it only send > > the item at point to the end of the headline specified through the > > refile interface? > > I hope its clear that this is all above my head. I know enough to make > suggestions, but not contribute to implementing them. That makes me a > free-rider, but a free-rider that recognizes he's at the mercy of > others' talents. > Ah, no - you don't get off that easily! This is not "implementing" anything. He is asking about your expectations: "If I have a list item here and I do an org-refile with such and such arguments in a file that looks like so and so, I expect it to do such and such. Instead it did this and that, which was rather surprising. OTOH, if the list item is *there*..." etc. etc. I haven't read the thread (apologies) but ISTR you provided such a description to begin with. What Nicolas is asking is: what should happen in other cases of interest? You may want to cover just that one special case, but an implementation has to worry about *all* cases[fn:1]: otherwise, there *will* be bug reports in the very near future and guess who their target will be (hint: it won't be you :-) ) Hope-your-sense-of-humor-is-working-today-ly yours, Nick Footnotes: [fn:1] It might punt of course: cover the special case only and raise an error in all other cases e.g., but that's not particularly appealing.