From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [RFC] Remove Org Struct mode Date: Tue, 22 Aug 2017 15:50:02 +0200 Message-ID: References: <87mv6ul4u6.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045c214a6e9e3c055757e010" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dk9Zc-000697-1E for emacs-orgmode@gnu.org; Tue, 22 Aug 2017 09:50:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dk9Za-0007u6-JE for emacs-orgmode@gnu.org; Tue, 22 Aug 2017 09:50:28 -0400 Received: from mail-wr0-x235.google.com ([2a00:1450:400c:c0c::235]:38772) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dk9Za-0007qb-9S for emacs-orgmode@gnu.org; Tue, 22 Aug 2017 09:50:26 -0400 Received: by mail-wr0-x235.google.com with SMTP id p8so62098318wrf.5 for ; Tue, 22 Aug 2017 06:50:23 -0700 (PDT) In-Reply-To: <87mv6ul4u6.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" To: Nicolas Goaziou Cc: Org Mode List --f403045c214a6e9e3c055757e010 Content-Type: text/plain; charset="UTF-8" Hi Nicolas, I have not problems with removing orgstruct-mode, it is indeed a bad hack and I am no longer using it. I am glad you are not planning to remove orgtbl-mode. In particular, in connection with radio tables, it is a feature that I use constantly, so I would object strongly to removing it. Carsten On Sun, Aug 20, 2017 at 3:57 PM, Nicolas Goaziou wrote: > Hello, > > I would like to remove Org Struct minor mode from Org code base. Here is > the rationale: > > 1. It is broken. It might look like using Org in another buffer, but it > is not. In particular, it just cannot cope with lists, indentation, > filling in, e.g., Message mode, as soon as we try something > non-trivial. Really, that's a poor-man's Org mode. > > 2. Its implementation is very hackish. In particular, it is not modular > at all. It rewrites some core functions according to the major mode > in use. For example `org-fill-function' tries to handle specially > text in a Message mode buffer, basically short-circuiting regular > behaviour. There no support for other major modes. If we want some, > we need to hard-code it. > > 3. Due to previous point, some basic Org functions are sub-optimal > because they preserve compatibility with Org Struct mode. For example > `org-forward-heading-same-level' must process every headline past the > current one and check their level until an appropriate one is found. > It would be faster to go looking for the next headline according to > the number of stars we want. > > 4. It is somewhat outside Org mode's scope to provide such a feature. It > is tempting to provide everything we can think of, but we should > focus on the main task: handle Org files, i.e., files written in Org > compatible syntax. > > 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ... > > I _do_ use `orgstruct++-mode'. But it is broken beyond repair. > Alternatives, which do not need to pay a technical debt, are certainly > better, or, at least, a saner ground for improvement. > > I'm not opposed to an Org struct mode living in ELPA. But, as pointed > out, it is difficult to extract from code base without rewriting it > completely. If alternatives are serious enough, that would be > re-inventing the wheel, too. > > The only thing that would be missing, AFAIK, is plain list handling. > However, I'm quite certain it is possible to re-use most code from > "org-list.el", using a dumbed down `org-list-struct' function. Indeed, > currently, `org-list-struct' requires to know about inlinetasks, > drawers, blocks... i.e., most of the Org syntax. This is not an option > in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p') > are simplified, other functions in "org-list.el" can be used as is. > > I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it > doesn't suffer from points 1, 3 end 5. It is easier to extract it as an > external library, which someone should ultimately do. > > To sum it up, I offer to remove `orgstruct-mode' (and > `orgstruct++-mode') from the code base. I can also offer my help to > anyone willing to extract some `list-minor-mode' and `table-minor-mode' > from Org. > > WDYT? > > > Regards, > > -- > Nicolas Goaziou 0x80A93738 > > --f403045c214a6e9e3c055757e010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nicolas,

I have not problems with re= moving orgstruct-mode, it is indeed a bad hack and I am no longer using it.=

I am glad you are not planning to remove=C2=A0org= tbl-mode.=C2=A0 In particular, in connection with radio tables, it is a fea= ture that I use constantly, so I would object strongly to removing it.

Carsten

On Sun, Aug 20, 2017 at 3:57 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
Hello,

I would like to remove Org Struct minor mode from Org code base. Here is the rationale:

1. It is broken. It might look like using Org in another buffer, but it
=C2=A0 =C2=A0is not. In particular, it just cannot cope with lists, indenta= tion,
=C2=A0 =C2=A0filling in, e.g., Message mode, as soon as we try something =C2=A0 =C2=A0non-trivial. Really, that's a poor-man's Org mode.

2. Its implementation is very hackish. In particular, it is not modular
=C2=A0 =C2=A0at all. It rewrites some core functions according to the major= mode
=C2=A0 =C2=A0in use. For example `org-fill-function' tries to handle sp= ecially
=C2=A0 =C2=A0text in a Message mode buffer, basically short-circuiting regu= lar
=C2=A0 =C2=A0behaviour. There no support for other major modes. If we want = some,
=C2=A0 =C2=A0we need to hard-code it.

3. Due to previous point, some basic Org functions are sub-optimal
=C2=A0 =C2=A0because they preserve compatibility with Org Struct mode. For = example
=C2=A0 =C2=A0`org-forward-heading-same-level' must process every h= eadline past the
=C2=A0 =C2=A0current one and check their level until an appropriate one is = found.
=C2=A0 =C2=A0It would be faster to go looking for the next headline accordi= ng to
=C2=A0 =C2=A0the number of stars we want.

4. It is somewhat outside Org mode's scope to provide such a feature. I= t
=C2=A0 =C2=A0is tempting to provide everything we can think of, but we shou= ld
=C2=A0 =C2=A0focus on the main task: handle Org files, i.e., files written = in Org
=C2=A0 =C2=A0compatible syntax.

5. There are alternatives. E.g., outshine.el, outline-minor-mode, ...

I _do_ use `orgstruct++-mode'. But it is broken beyond repair.
Alternatives, which do not need to pay a technical debt, are certainly
better, or, at least, a saner ground for improvement.

I'm not opposed to an Org struct mode living in ELPA. But, as pointed out, it is difficult to extract from code base without rewriting it
completely. If alternatives are serious enough, that would be
re-inventing the wheel, too.

The only thing that would be missing, AFAIK, is plain list handling.
However, I'm quite certain it is possible to re-use most code from
"org-list.el", using a dumbed down `org-list-struct' function= . Indeed,
currently, `org-list-struct' requires to know about inlinetasks,
drawers, blocks... i.e., most of the Org syntax. This is not an option
in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p= 9;)
are simplified, other functions in "org-list.el" can be used as i= s.

I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it doesn't suffer from points 1, 3 end 5. It is easier to extract it as an=
external library, which someone should ultimately do.

To sum it up, I offer to remove `orgstruct-mode' (and
`orgstruct++-mode') from the code base. I can also offer my help to
anyone willing to extract some `list-minor-mode' and `table-minor-mode&= #39;
from Org.

WDYT?


Regards,

--
Nicolas Goaziou=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80A93738


--f403045c214a6e9e3c055757e010--