From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pip Cet Subject: Re: beamer_env tag issue with empty headlines Date: Thu, 27 Aug 2015 21:42:32 +0000 Message-ID: References: <871tezbqrb.fsf@nicolasgoaziou.fr> <87r3mzaanp.fsf@nicolasgoaziou.fr> <878u8wtvfb.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c31f743d557b051e51d80c Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV4wM-0000FP-MX for emacs-orgmode@gnu.org; Thu, 27 Aug 2015 17:42:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV4wL-0000il-BB for emacs-orgmode@gnu.org; Thu, 27 Aug 2015 17:42:34 -0400 Received: from mail-ig0-x233.google.com ([2607:f8b0:4001:c05::233]:37273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV4wL-0000iX-4j for emacs-orgmode@gnu.org; Thu, 27 Aug 2015 17:42:33 -0400 Received: by igui7 with SMTP id i7so4124881igu.0 for ; Thu, 27 Aug 2015 14:42:32 -0700 (PDT) In-Reply-To: <878u8wtvfb.fsf@nicolasgoaziou.fr> 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: Pip Cet , Prateek Mehta , emacs-orgmode@gnu.org --001a11c31f743d557b051e51d80c Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 6:53 PM, Nicolas Goaziou wrote: > Pip Cet writes: > > > Could you explain your reasoning for this in some more detail? I use > > empty headlines + tags (properties, actually) in my "set properties in > > headlines rather than special drawers" code, and I wouldn't want it to > > break even more than it currently is because of this limitation. > > The reasoning is that it is a tricky situation, which may not be handled > everywhere in code base, e.g., depending on the regexp used. As > a consequence you're in /terra incognita/ anytime you use such > constructs. > IMHO it would be a good idea to reduce the number of regexps anyway; for example, there are more than twenty regexps trying to match the tags at the end of the line. (I've fixed that here, and will submit a patch as soon as the copyright papers have been accepted) > I don't, but empty headlines are useful for setting tags (or, in my > > case, properties) without making up a title, so in my humble opinion > > it's a clear-cut case to support empty headlines + tags. > > Possible. The fact that we're having this discussion means we should > probably choose one option, write it down in Org syntax, then deal with > the bugs. Which option is open for debate. I am not married to any of > them. > I think we have three options: 1. declare empty headlines forbidden 2. declare empty headlines allowed, and hope everything goes well 3. declare empty headlines allowed and go through the code making sure we deal with them everywhere. My preference is 3, but 1 is better than 2. I'm volunteering to try to find the time for #3 (if only there were some sort of Emacs extension to help me organize things better), but can't really promise anything. However, I think we should make the decision first so it's not a total waste of effort. I should clarify that I consider only headlines with at least one space following the stars "empty headlines". A star on a line of its own doesn't count. Thanks! Pip --001a11c31f743d557b051e51d80c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 27, 2015 at 6:53 PM, Nicolas Goaziou <ma= il@nicolasgoaziou.fr> wrote:
Pip Cet <<= a href=3D"mailto:pipcet@gmail.com" target=3D"_blank">pipcet@gmail.com&g= t; writes:

> Could you explain your reasoning for this in some more detail? I use > empty headlines + tags (properties, actually) in my "set properti= es in
> headlines rather than special drawers" code, and I wouldn't w= ant it to
> break even more than it currently is because of this limitation.

The reasoning is that it is a tricky situation, which may not be han= dled
everywhere in code base, e.g., depending on the regexp used. As
a consequence you're in /terra incognita/ anytime you use such
constructs.

IMHO it would be a good ide= a to reduce the number of regexps anyway; for example, there are more than = twenty regexps trying to match the tags at the end of the line. (I've f= ixed that here, and will submit a patch as soon as the copyright papers hav= e been accepted)

<= span> > I don't, but empty headlines are useful for setting tags (or, in m= y
> case, properties) without making up a title, so in my humble opinion > it's a clear-cut case to support empty headlines + tags.

Possible. The fact that we're having this discussion means we sh= ould
probably choose one option, write it down in Org syntax, then deal with
the bugs. Which option is open for debate. I am not married to any of
them.

I think we have three options:
1. declare empty headlines forbidden
2. declare e= mpty headlines allowed, and hope everything goes well
3. decl= are empty headlines allowed and go through the code making sure we deal wit= h them everywhere.

My preference is 3, but 1 is better th= an 2. I'm volunteering to try to find the time for #3 (if only there we= re some sort of Emacs extension to help me organize things better), but can= 't really promise anything. However, I think we should make the decisio= n first so it's not a total waste of effort.

I should= clarify that I consider only headlines with at least one space following t= he stars "empty headlines". A star on a line of its own doesn'= ;t count.

Thanks!
Pip
<= /div>
--001a11c31f743d557b051e51d80c--