From mboxrd@z Thu Jan 1 00:00:00 1970 From: "numbchild@gmail.com" Subject: Re: [RFC] Remove Org Struct mode Date: Mon, 21 Aug 2017 10:48:18 +0800 Message-ID: References: <87mv6ul4u6.fsf@nicolasgoaziou.fr> <87r2w5c2sk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0d23d0ad43bf05573a842e" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djclr-00054u-09 for emacs-orgmode@gnu.org; Sun, 20 Aug 2017 22:48:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djclp-0004n0-CD for emacs-orgmode@gnu.org; Sun, 20 Aug 2017 22:48:55 -0400 Received: from mail-wr0-x231.google.com ([2a00:1450:400c:c0c::231]:37518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djclp-0004mJ-1m for emacs-orgmode@gnu.org; Sun, 20 Aug 2017 22:48:53 -0400 Received: by mail-wr0-x231.google.com with SMTP id z91so85506632wrc.4 for ; Sun, 20 Aug 2017 19:48:50 -0700 (PDT) In-Reply-To: <87r2w5c2sk.fsf@gmail.com> 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: Tim Cross Cc: Org Mode List , Nicolas Goaziou --94eb2c0d23d0ad43bf05573a842e Content-Type: text/plain; charset="UTF-8" I agree too, because the OrgStruct mode functions is so limited for basic Org-mode viewing/editing/navigating etc. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Mon, Aug 21, 2017 at 6:06 AM, Tim Cross wrote: > > One of the reasons I moved to using mu4e for email was because I was > told I could use orgStruct mode and write my email using org structured > editing. > > The reality has been somewhat disappointing. One of the main things I > wanted was better handling of lists and this is one area of orgstruct > mode which certainly doesn't work correctly. > > So, given what you say and the fact the mode isn't working as > advertised, I tend to agree. Just adding a note to my org task list to > look at outshine.el, which I wasn't aware of. If I really need org > structural editing for writing an email, I'll write it in an org-mode > file and then transfer it to a message buffer - as you point out, there > is lots in org mode which makes no sense in an email buffer anyway! > > Tim > > Nicolas Goaziou writes: > > > 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, > > > -- > Tim Cross > > --94eb2c0d23d0ad43bf05573a842e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree too, because the OrgStruct mode functions is so li= mited for basic Org-mode viewing/editing/navigating etc.

[s= tardiviner]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= ;Hack this world!>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GPG key ID: 47C32433IRC(freeenode): stardiviner =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 Twitt= er:=C2=A0 @numbchild
Key fingerprint =3D 9BAA 92BC CDDD B9EF 3B36=C2=A0 = CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
<= /div>

On Mon, Aug 21, 2017 at 6:06 AM, Tim Cross <= span dir=3D"ltr"><theophilusx@gmail.com> wrote:

One of the reasons I moved to using mu4e for email was because I was
told I could use orgStruct mode and write my email using org structured
editing.

The reality has been somewhat disappointing. One of the main things I
wanted was better handling of lists and this is one area of orgstruct
mode which certainly doesn't work correctly.

So, given what you say and the fact the mode isn't working as
advertised, I tend to agree. Just adding a note to my org task list to
look at outshine.el, which I wasn't aware of. If I really need org
structural editing for writing an email, I'll write it in an org-mode file and then transfer it to a message buffer - as you point out, there
is lots in org mode which makes no sense in an email buffer anyway!

Tim

Nicolas Goaziou writes:

> 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 i= t
>=C2=A0 =C2=A0 is not. In particular, it just cannot cope with lists, in= dentation,
>=C2=A0 =C2=A0 filling in, e.g., Message mode, as soon as we try somethi= ng
>=C2=A0 =C2=A0 non-trivial. Really, that's a poor-man's Org mode= .
>
> 2. Its implementation is very hackish. In particular, it is not modula= r
>=C2=A0 =C2=A0 at all. It rewrites some core functions according to the = major mode
>=C2=A0 =C2=A0 in use. For example `org-fill-function' tries to hand= le specially
>=C2=A0 =C2=A0 text in a Message mode buffer, basically short-circuiting= regular
>=C2=A0 =C2=A0 behaviour. There no support for other major modes. If we = want some,
>=C2=A0 =C2=A0 we need to hard-code it.
>
> 3. Due to previous point, some basic Org functions are sub-optimal
>=C2=A0 =C2=A0 because they preserve compatibility with Org Struct mode.= For example
>=C2=A0 =C2=A0 `org-forward-heading-same-level' must process ev= ery headline past the
>=C2=A0 =C2=A0 current one and check their level until an appropriate on= e is found.
>=C2=A0 =C2=A0 It would be faster to go looking for the next headline ac= cording to
>=C2=A0 =C2=A0 the number of stars we want.
>
> 4. It is somewhat outside Org mode's scope to provide such a featu= re. It
>=C2=A0 =C2=A0 is tempting to provide everything we can think of, but we= should
>=C2=A0 =C2=A0 focus on the main task: handle Org files, i.e., files wri= tten in Org
>=C2=A0 =C2=A0 compatible syntax.
>
> 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ...<= br> >
> 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 poin= ted
> 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' fun= ction. 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 t= o
> anyone willing to extract some `list-minor-mode' and `table-minor-= mode'
> from Org.
>
> WDYT?
>
>
> Regards,


--
Tim Cross


--94eb2c0d23d0ad43bf05573a842e--