From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [POLL] Syntax change: make \[...\] non-inline (+1) Date: Sun, 03 Aug 2014 14:19:31 -0400 Message-ID: <8761i977ws.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XE0Nv-000667-KZ for emacs-orgmode@gnu.org; Sun, 03 Aug 2014 14:20:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XE0No-0004As-1R for emacs-orgmode@gnu.org; Sun, 03 Aug 2014 14:19:55 -0400 Received: from plane.gmane.org ([80.91.229.3]:43516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XE0Nn-0004Al-RM for emacs-orgmode@gnu.org; Sun, 03 Aug 2014 14:19:47 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XE0Nm-0002pn-EM for emacs-orgmode@gnu.org; Sun, 03 Aug 2014 20:19:46 +0200 Received: from pool-173-48-174-104.bstnma.fios.verizon.net ([173.48.174.104]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Aug 2014 20:19:46 +0200 Received: from ndokos by pool-173-48-174-104.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Aug 2014 20:19:46 +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: emacs-orgmode@gnu.org Federico Beffa writes: >>> 5. Existing documents are very easy to fix. >>> >> >>Backwards compatibility is important. It has been broken >>before, for very good reasons, and even though it was done very >>carefully, it still caused many problems (still does). >>So I don't buy the "very easy to fix" part: it will bite somebody >>two minutes before he/she has to make a presentation (or even during the >>presentation - DAMHIKT). > > Don't get me wrong, I value backward compatibility. > > However, here for the end user the change would amount to something like > > if \[ is not at the beginning of a line, then insert \n before \[ > if \] does not end a line, then insert \n after \] > > for the whole document (or something similar). This should obviously > be documented in the release notes where an exact procedure to fix the > document can be detailed (possibly two query-replace expressions). > > And if somebody updates just before a presentation and without reading > the release notes, then it's his own fault. > It's a bit more complicated than that: one upgrades org at some opportune moment, then three months/years/centuries later, tries to use that presentation that worked perfectly before - boom. If you go back and check all your old presentations each time you upgrade org, you are, I would guess, the exception, not the rule. I certainly don't do that Just to be clear: on the whole issue you bring up, I'm more or less neutral (slightly negative to be sure, mostly because I'm not convinced that it's a serious problem, but I could live with it either way). I generally put displays in separate paragraphs, I rarely use autofill[fn:1] and I'm happy to do M-q on individual paragraphs instead, but if I happen to do it on the wrong paragraph (backtraces, code fragments, displayed equations), undo is easy enough. Footnotes: [fn:1] I use it in gnus message composition modes by default, and I often swear at it and turn it off because it does things that I don't want it to do - mostly mangles backtraces and code fragments; I probably should turn it off completely. -- Nick