From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Future Worg publishing failure :) Date: Fri, 18 Mar 2011 12:02:59 -0400 Message-ID: <29538.1300464179@alphaville.dokosmarshall.org> References: <15689.1300433701@alphaville.dokosmarshall.org> <87y64cg2n5.fsf@gnu.org> <874o708usn.fsf@gmail.com> <27408.1300458859@alphaville.dokosmarshall.org> <87vczg77uu.fsf@gmail.com> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=46747 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0c8z-0005SF-9j for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 12:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0c8y-00045r-95 for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 12:03:17 -0400 Received: from vms173011pub.verizon.net ([206.46.173.11]:62429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0c8y-000439-3q for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 12:03:16 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LI900A9NGKZ4RA0@vms173011.mailsrvcs.net> for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 11:03:05 -0500 (CDT) In-reply-to: Message from Nicolas of "Fri, 18 Mar 2011 16:42:49 BST." <87vczg77uu.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien , emacs-orgmode@gnu.org Cc: nicholas.dokos@hp.com Nicolas wrote: > Hello, > > Nick Dokos writes: > > >> The only solution I could think of is somewhere in the patchwork server > >> ("Auto-fill shouldn't insert new items"). > >> > > > > Are you saying that the patchwork server introduced this? Or that the > > patchwork server should solve it? In the case I stumbled upon (a Worg > > file), the patchwork server is nowhere in sight, I think: the change was > > (I'm guessing here) directly committed, so maybe the original writer had > > auto-fill turned on, but maybe not and just typed it that way. So > > neither the patchwork server nor making auto-fill smarter would provide > > a guaranteed solution. But maybe there is no such thing. > > I'm not sure to understand. I mean that there is a patch waiting to be > processed in the patchwork server, that should get us as close to the > solution as I can think of (so, probably not very close). > Ah, OK - I was just dense: I misread it completely. > It is true that the patch only solves the problem if it would happen > with auto-fill (or fill-paragraph). On the other hand, if the original > writer typed it that way, it's an user problem, and I don't think we > should add cruft to solve it. > > > Perhaps a heuristic in html export to just take care of the error: if > > it looks like a numbered list item but there is no item body, bail and > > assume it's part of the text. > > I introduced support for empty items on purpose. That would be > a regression. > > > Or a combination of that together with the item number > 1. Would that > > work? > > It would partly work. But: > - You would get false positives (rarely, but still), > - It wouldn't handle case when line, beside the bullet, isn't empty, > - It isn't only about HTML export, not even about export, as the same > situation happens in Org buffers. > > Again, preventing the problem to happen automatically, i.e. without the > user knowing for sure about it, is taken care of by the patch (provided > it doesn't break anything else, thus its journey on the patchwork > server). In every other case, we can assume that the user knows (should > know) both Org syntax and what he is doing. > > Now, for already introduced problems, it is indeed possible to build > a function using heuristics to scan files, and when matching, offer to > join lines and fill-paragraph. I don't think there are enough cases to > justify this, though. > OK: agreed - we just fix existing org files on a case-by-case basis. So manually inserting "14." at the beginning of the line is user error, auto-fill is taken care of by your patch. However, there is still the problem that an empty item in a numbered list will trigger the error that I posted, so org-html-export-list-line will need to be taught how to deal with an empty list item - correct? Nick