From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [New Latex Exporter][BABEL][BUG] lists and inline src Date: Thu, 20 Sep 2012 19:07:24 +0200 Message-ID: <87392ctygj.fsf@gmail.com> References: <87haqvf1e0.fsf@tajo.ucsd.edu> <87392eqv0e.fsf@bzg.ath.cx> <87627a3tk9.fsf@tajo.ucsd.edu> <878vc57et0.fsf_-_@gmx.com> <87vcf8dh93.fsf@gmail.com> <87zk4k4vl3.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkHo-0007I8-Uj for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:11:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEkHh-00069S-88 for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:11:36 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:52450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkHh-000672-0Y for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:11:29 -0400 Received: by weys10 with SMTP id s10so1540978wey.0 for ; Thu, 20 Sep 2012 10:11:27 -0700 (PDT) In-Reply-To: <87zk4k4vl3.fsf@gmx.com> (Eric Schulte's message of "Thu, 20 Sep 2012 08:28:40 -0600") 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: Eric Schulte Cc: cberry@tajo.ucsd.edu, emacs-orgmode@gnu.org Hello, Eric Schulte writes: > Thanks for finding the source of this problem. The preceding character > is checked so that inline source blocks can be commented. E.g., a user > may want =src_sh{date}= to appear verbatim. =src_sh{date}= won't be expanded by `org-babel-exp-non-block-elements' (is there another function executing them?) since the current version checks object at point (in this case, it is a verbatim object, not an inline-src-block). So, in this case, there's no need for the check. > Similarly if the preceding character is a letter e.g., > notsrc_sh{date}, then the source block should not be executed. I don't understand why it wouldn't be expanded in that situation. It can be useful if results are raw: it becomes a beefed-up macro. > Ideally there would be a way to specify that *if* a character exists > before the code block it must have some property, or to match the > beginning of the element as another regexp option. I would say we can > go ahead and remove the leading portion of the regexp, but as I recall I > wrote it in response to legitimate complaints on the mailing list about > the overly permissive behavior of inline source blocks, and I do not > want for those problems to re-emerge. I understand, but it looks like a very drastic solution. It may be worth reconsidering it for 8.x branch. If problems re-emerge then, test cases will be provided. What do you think about it? For 7.9.x, I'll just commit the workaround. Regards, -- Nicolas Goaziou