From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [New Latex Exporter][BABEL][BUG] lists and inline src Date: Thu, 20 Sep 2012 11:26:00 -0600 Message-ID: <87sjac38t3.fsf@gmx.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> <87392ctygj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkxB-0000Kp-Sh for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:54:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEkxA-0004cG-ES for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:54:21 -0400 Received: from mailout-eu.gmx.com ([213.165.64.43]:34314) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TEkxA-0004cB-4t for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 13:54:20 -0400 In-Reply-To: <87392ctygj.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 20 Sep 2012 19:07:24 +0200") 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org, cberry@tajo.ucsd.edu, Eric Schulte Nicolas Goaziou writes: > 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. > Yea, that sounds reasonable, thanks for taking care of this. If I find time I'll dig through the mailing list and see if I can find the exact reason why that portion of the regexp was added. I've had the experience before of reverting a piece of code that seemed superfluous to then have old bugs re-emerge and finally revert my reversion. So I now try to err on the side of deference towards existing code. Cheers, > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte