From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: function for inserting a block Date: Thu, 9 Nov 2017 08:55:59 +0100 Message-ID: References: <877exghblx.fsf@ericabrahamsen.net> <87tvyyvpst.fsf@ericabrahamsen.net> <87fuaiz069.fsf@nicolasgoaziou.fr> <87lgk9eo4d.fsf@ericabrahamsen.net> <87fuahxxvs.fsf@nicolasgoaziou.fr> <87r2u1cuwj.fsf@ericabrahamsen.net> <87infdctzq.fsf@ericabrahamsen.net> <87k1zsbizs.fsf@ericabrahamsen.net> <87k1zp4rxj.fsf@ericabrahamsen.net> <871slx4j6p.fsf@ericabrahamsen.net> <87376btslq.fsf@nicolasgoaziou.fr> <87vaj7oyxb.fsf@ericabrahamsen.net> <871sl9ow44.fsf@gnu.org> <87fu9pgfkj.fsf@nicolasgoaziou.fr> <87375ouanr.fsf@gmx.us> <871sl8e76c.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1a1d1acabe84055d882376" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eChhI-0004gp-4f for emacs-orgmode@gnu.org; Thu, 09 Nov 2017 02:56:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eChhG-00023B-No for emacs-orgmode@gnu.org; Thu, 09 Nov 2017 02:56:24 -0500 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34658) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eChhG-00022s-EC for emacs-orgmode@gnu.org; Thu, 09 Nov 2017 02:56:22 -0500 Received: by mail-wm0-x22d.google.com with SMTP id n74so1149479wmi.1 for ; Wed, 08 Nov 2017 23:56:21 -0800 (PST) In-Reply-To: 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" To: "Thomas S. Dye" Cc: Takaaki Ishikawa , "emacs-orgmode@gnu.org" , Rasmus , Nicolas Goaziou , "Berry, Charles" --94eb2c1a1d1acabe84055d882376 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 9, 2017 at 5:31 AM, Thomas S. Dye wrote: > Aloha Nicolas, > > Nicolas Goaziou writes: > > > Hello, > > > > Takaaki Ishikawa writes: > > > >> I also support the idea of keeping " >> Please give importance to the backward compatibility in this case. > > > > I explained why I thought it could be removed. I also suggested > > solutions to get an equivalent feature without implementing it in Org. > > > > What is wrong with Abbrev mode, skeletons, tempo.el, expand.el, all > > bundled with Emacs, or YASnippet, in the Emacs ecosystem? It sounds like > > NIH. Or, to put it differently: why in the world would Org implement its > > own template system? > > The "why in the world" question is likely one that can be answered by > the author of the Org template system. > I guess that would be me. The reason why I implemented it was the same reason why I implemented org-mode. It scratched an itch that I was having, and so I implemented it to solve this issue, without much regard for existing expansion systems - back then, I am not sure which of them did even exist and how easy it would have been to deal with dependencies. The reason why the leading character is "<" lies in the fact that, at the time, I was experimenting with HTML tags, mainly because this was how emacs MUSE was handling markup. I left it at that because it led to very few conflicts and because "<" is a character that is easily typed. I have always come down on the side of NOT breaking backward compatibility unless we really HAVE TO in order to make progress. The reason for this bias is because most Org users are not reading this maling list and just want the system to function and to continue to function the way they are used to, while it is hopefully improving. It will stop them from upgrading if such breakage happens too often. So I would support reimplement the expansion (including org-try-structure-completion for people who use that in custom code), if possible of course on the back of one of the built-in expansion systems in Emacs, before pushing this change out in a release. I would certainly reimplement this in some way for myself, because using these abbreviations is already hardcoded in my spine, I think. That does not take away from that fact that I am really happy we now can wrap existing text into a block structure. Very useful indeed. Carsten > > > The only argument so far is "<" cannot be expanded since it not word > > constituent. Seriously. "<" has no meaning anyway. You can use "@", > > which is word constituent and just as meaningless. So, you can define, > > e.g., a skeleton, that will expand "@s" to "#+begin_src\n#+end_src". > > > > We can even document how to do it in the manual. > > For me, the issue isn't about how the template system is implemented, it > is about backwards compatibility of (org-try-structure-completion). > > All the best, > Tom > > -- > Thomas S. Dye > http://www.tsdye.com > > --94eb2c1a1d1acabe84055d882376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 9, 2017 at 5:31 AM, Thomas S. Dye <tsd@tsdye.com> wrote:
Aloha Nicolas= ,

Nicolas Goaziou writes:

> Hello,
>
> Takaaki Ishikawa <takaxp@ieee.or= g> writes:
>
>> I also support the idea of keeping "<s" as it was. >> Please give importance to the backward compatibility in this case.=
>
> I explained why I thought it could be removed. I also suggested
> solutions to get an equivalent feature without implementing it in Org.=
>
> What is wrong with Abbrev mode, skeletons, tempo.el, expand.el, all > bundled with Emacs, or YASnippet, in the Emacs ecosystem? It sounds li= ke
> NIH. Or, to put it differently: why in the world would Org implement i= ts
> own template system?

The "why in the world" question is likely one that can be = answered by
the author of the Org template system.

= I guess that would be me.

The reason why I impleme= nted it was the same reason why I implemented org-mode.=C2=A0 It scratched = an itch that I was having, and so I implemented it to solve this issue, wit= hout much regard for existing expansion systems - back then, I am not sure = which of them did even exist and how easy it would have been to deal with d= ependencies.

The reason why the leading character = is "<" lies in the fact that, at the time, I was experimenting= with HTML tags, mainly because this was how emacs MUSE was handling markup= .=C2=A0 I left it at that because it led to very few conflicts and because = "<" is a character that is easily typed.

<= div>I have always come down on the side of NOT breaking backward compatibil= ity unless we really HAVE TO in order to make progress.=C2=A0 The reason fo= r this bias is because most Org users are not reading this maling list and = just want the system to function and to continue to function the way they a= re used to, while it is hopefully improving.=C2=A0 It will stop them from u= pgrading if such breakage happens too often.

So I = would support=C2=A0reimplement the expansion (including=C2=A0org-try-structure-completion for people who use that in = custom code), if possible of course on the back of one of the built-= in expansion systems in Emacs, before pushing this change out in a release.= =C2=A0 I would certainly reimplement this in some way for myself, because u= sing these abbreviations is already hardcoded in my spine, I think.

That does not take away from that fact that I am really h= appy we now can wrap existing text into a block structure.=C2=A0 Very usefu= l indeed.

Carsten
=C2=A0

> The only argument so far is "<" cannot be expanded since = it not word
> constituent. Seriously. "<" has no meaning anyway. You ca= n use "@",
> which is word constituent and just as meaningless. So, you can define,=
> e.g., a skeleton, that will expand "@s" to "#+begin_src= \n#+end_src".
>
> We can even document how to do it in the manual.

For me, the issue isn't about how the template system is impleme= nted, it
is about backwards compatibility of (org-try-structure-completion).

All the best,
Tom

--
Thomas S. Dye
http:= //www.tsdye.com


--94eb2c1a1d1acabe84055d882376--