From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Subject: Re: Future Worg publishing failure :) Date: Fri, 18 Mar 2011 16:42:49 +0100 Message-ID: <87vczg77uu.fsf@gmail.com> References: <15689.1300433701@alphaville.dokosmarshall.org> <87y64cg2n5.fsf@gnu.org> <874o708usn.fsf@gmail.com> <27408.1300458859@alphaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=45138 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0bys-0000J1-2s for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 11:52:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0byq-0001en-MP for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 11:52:49 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:43787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0bpw-0006oh-UN for emacs-orgmode@gnu.org; Fri, 18 Mar 2011 11:43:37 -0400 Received: by fxm18 with SMTP id 18so4338960fxm.0 for ; Fri, 18 Mar 2011 08:43:36 -0700 (PDT) In-Reply-To: <27408.1300458859@alphaville.dokosmarshall.org> (Nick Dokos's message of "Fri, 18 Mar 2011 10:34:19 -0400") 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: nicholas.dokos@hp.com Cc: Bastien , emacs-orgmode@gnu.org 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). 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. Regards, -- Nicolas