From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roland Kaufmann <roland.kaufmann@gmail.com>
Subject: Re: [PATCH] Markup on same line as text
Date: Wed, 16 Feb 2011 22:53:53 +0100
Message-ID: <4D5C4771.7030600@gmail.com>
References: <4D263E3B.5030407@gmail.com> <87zkpvkape.fsf@xemacs.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from [140.186.70.92] (port=53116 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PppJw-00025I-Bn
	for emacs-orgmode@gnu.org; Wed, 16 Feb 2011 16:54:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <roland.kaufmann@gmail.com>) id 1PppJu-0000z4-Vn
	for emacs-orgmode@gnu.org; Wed, 16 Feb 2011 16:54:00 -0500
Received: from mail-ew0-f41.google.com ([209.85.215.41]:37053)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <roland.kaufmann@gmail.com>) id 1PppJu-0000yj-RU
	for emacs-orgmode@gnu.org; Wed, 16 Feb 2011 16:53:58 -0500
Received: by ewy27 with SMTP id 27so701084ewy.0
	for <emacs-orgmode@gnu.org>; Wed, 16 Feb 2011 13:53:57 -0800 (PST)
In-Reply-To: <87zkpvkape.fsf@xemacs.org>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Hrvoje Niksic <hniksic@xemacs.org>
Cc: emacs-orgmode@gnu.org

> Your patch may work in this particular case, but the idea behind
> htmlize is to describe the state of the buffer.  If a property ends
> after the newline, it is intended that the generated HTML reflect

The philosophical question is then: Is the newline character part of the 
syntax construct that is being fontified, or rather a "formatting code" 
that should be kept separate?

Being whitespace it (mostly) doesn't matter visually, which makes it an 
easy choice to include in tokens to preserve formatting continuity 
between lines.

However, any further line processing by other modules is complicated 
significantly if the terminator is put inside the markup.

> I am not familiar with org-mode, so I will need a description of
> exactly how to reproduce this bug.  Specifically I don't know how to
> put a reference on the next line.

This Elisp will create/overwrite a buffer called foo.org in the /tmp 
directory containing problematic code and export it to foo.html:

(let ((filename (expand-file-name "foo.org" temporary-file-directory)))
   (switch-to-buffer (find-file-noselect filename))
   (erase-buffer)
   (insert "*
#+BEGIN_SRC emacs-lisp
(let ((x 42)) ; meaning of l.u.e.
   (print x))  ; (ref:2)
#+END_SRC")
   (save-buffer)
   (org-mode)
   (org-export-as-html nil))

-- 
    Roland.