Re: Differences between Org-Mode and Hyperbole (Was: Call for testers for GNU Hyperbole 5.12, a large, useful Emacs package)

Re: Differences between Org-Mode and Hyperbole (Was: Call for testers for GNU Hyperbole 5.12, a large, useful Emacs package)

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

On Wed, Jun 15, 2016 at 3:56 PM, Tom <adatgyujto@gmail.com> wrote:

>
> It would be useful if you could compare it to something which
> people know. For example, Org mode is part of Emacs and from the
> description it seems to me Hyperbole has some overlapping functionality
> with Org (e.g. org also has outlining ability, it can also be a
> personal information manager, can link to other files, etc.)
>
> What are the differences?


Although on the surface this comes up a lot, once you use both of these,
you'll quickly see how different they are.  Because they are so different,
it is likely that there will be some integration in the future.

Org-mode is a major-mode that works on structured files built atop Emacs
outlining mode.
Hyperbole is a system that spans across much of Emacs' functionality,
providing quick access keys and hyperbuttons wherever needed.

Org-mode's outliner is like Emacs outliner.
Hyperbole's Koutliner is unique; every node/paragraph has a unique id and
settable attributes plus a relative id that is auto-updated as you move
trees around the outline, so you know that node 2b4 is a child of 2b and is
the next sibling of the 2b3 node.

Org-mode has explicit hyperlinks that you create.
Hyperbole has these too, allowing you to create them in any type of text
file, with simple drags between windows.  But Hyperbole also recognizes
hyperlinks embedded in many different types of files and buffers and can
easily support new types.  You simply press one button and Hyperbole
figures out what to do in dozens of contexts.

Org-mode manages todos, time entries and some basic project management.
Hyperbole does none of this except you can integrate with whatever todo
management you like.

Org-mode doesn't have any contact management as far as I know (which is not
much since I have not yet used it).
Hyperbole has a fast, effective hierarchical contact manager.

Org-mode does nothing with your buffers, windows and frames since it is
just a major mode.
Hyperbole has a fast, thoughtfully designed window and frame manager that
lets you quickly arrange your Emacs artifacts as you like.  Eventually,
these window and frame configurations will be saveable and will be able to
be the target of links, so you can have quick access buttons that arrange
things for different work tasks (similar to Workspaces but integrated with
all of Hyperbole's other features).

Org-mode does nothing for management of libraries of information.
Hyperbole helps organize, link, search and retrieve libraries of text files.

Hyperbole also has features that speed code browsing and structured code
editing and support for using the mouse keys as Control and Meta modifiers
so you can point and operate on screen entities quickly.

Does that help?

If you want to know more, sit down after work and read the manual.  It will
tell you a lot.

Bob

[-- Attachment #2: Type: text/html, Size: 3591 bytes --]

Re: Differences between Org-Mode and Hyperbole

[John Wiegley]

>>>>> Robert Weiner <rsw@gnu.org> writes:

> Org-mode doesn't have any contact management as far as I know (which is not
> much since I have not yet used it).

There is org-contacts.

> Org-mode does nothing for management of libraries of information.

Deft has integration with Org-mode for this, among others (like Helm).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On Wed, Jun 15, 2016 at 5:53 PM, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Robert Weiner <rsw@gnu.org> writes:
>
> > Org-mode doesn't have any contact management as far as I know (which is
> not
> > much since I have not yet used it).
>
> There is org-contacts.
>

Good to know.  It looks like it is field-based, requiring you to create or
reuse a template and then fill in fields in particular locations.  This is
one of the things I hated about other contact managers and why Hyperbole's
was developed.  It uses free-from records and full-text search for
retrieval across any number of contact files desired.  It even looks up
BBDB records automatically, all with no configuration.  The Hyperbole
contact manager uses Emacs outlining so you can have hierarchies of
records, e.g. departments or other organizations and find them all at once
grouped together and many other features without the need to add extensions
or configure much of anything.

> Org-mode does nothing for management of libraries of information.
>
> Deft has integration with Org-mode for this, among others (like Helm).
>

I had not heard of Deft.  I'll have to check it out.

John, if you can remember that far back, maybe you could tell people what
you liked about Hyperbole and how you used it to give people an idea.

Bob

[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

Re: Differences between Org-Mode and Hyperbole

[John Wiegley]

>>>>> Robert Weiner <rsw@gnu.org> writes:

> John, if you can remember that far back, maybe you could tell people what
> you liked about Hyperbole and how you used it to give people an idea.

I remember liking the way I could build up a highly cross-linked set of
heterogenous data. But I think I realized I was spending too much time making
those connections, so I later moved to Wikis and their auto-linkify of
CamelCase (which Hyperbole probably does, but maybe I didn't know it then).

I'll have to try out the public release once its out, to see how it relates to
Org-mode, which is currently how I manage the sea of tasks and textual
information that I deal with.  But I keep my calendar and contacts outside of
Emacs these days, because it's necessary to have them on my phone as well,
since that's the primary place I use that data nowadays.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re:Re: Differences between Org-Mode and Hyperbole (Was: Call for testers for GNU Hyperbole 5.12, a large, useful Emacs package)

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]

Today I have tried Rolo， I think it is a very good contact manager， simple and powful，
but I need a feature which is like bbdb-handy （https://github.com/tumashu/bbdb-handy）



在 2016-06-16 04:55:02，"Robert Weiner" <rsw@gnu.org> 写道：

On Wed, Jun 15, 2016 at 3:56 PM, Tom <adatgyujto@gmail.com> wrote:

It would be useful if you could compare it to something which
people know. For example, Org mode is part of Emacs and from the
description it seems to me Hyperbole has some overlapping functionality
with Org (e.g. org also has outlining ability, it can also be a
personal information manager, can link to other files, etc.)

What are the differences?


Although on the surface this comes up a lot, once you use both of these, you'll quickly see how different they are.  Because they are so different, it is likely that there will be some integration in the future.


Org-mode is a major-mode that works on structured files built atop Emacs outlining mode.
Hyperbole is a system that spans across much of Emacs' functionality, providing quick access keys and hyperbuttons wherever needed.


Org-mode's outliner is like Emacs outliner.
Hyperbole's Koutliner is unique; every node/paragraph has a unique id and settable attributes plus a relative id that is auto-updated as you move trees around the outline, so you know that node 2b4 is a child of 2b and is the next sibling of the 2b3 node.


Org-mode has explicit hyperlinks that you create.
Hyperbole has these too, allowing you to create them in any type of text file, with simple drags between windows.  But Hyperbole also recognizes hyperlinks embedded in many different types of files and buffers and can easily support new types.  You simply press one button and Hyperbole figures out what to do in dozens of contexts.


Org-mode manages todos, time entries and some basic project management.
Hyperbole does none of this except you can integrate with whatever todo management you like.


Org-mode doesn't have any contact management as far as I know (which is not much since I have not yet used it).
Hyperbole has a fast, effective hierarchical contact manager.




Org-mode does nothing with your buffers, windows and frames since it is just a major mode.
Hyperbole has a fast, thoughtfully designed window and frame manager that lets you quickly arrange your Emacs artifacts as you like.  Eventually, these window and frame configurations will be saveable and will be able to be the target of links, so you can have quick access buttons that arrange things for different work tasks (similar to Workspaces but integrated with all of Hyperbole's other features).


Org-mode does nothing for management of libraries of information.
Hyperbole helps organize, link, search and retrieve libraries of text files.


Hyperbole also has features that speed code browsing and structured code editing and support for using the mouse keys as Control and Meta modifiers so you can point and operate on screen entities quickly.


Does that help?


If you want to know more, sit down after work and read the manual.  It will tell you a lot.


Bob


[-- Attachment #2: Type: text/html, Size: 4149 bytes --]

Re: Re: Differences between Org-Mode and Hyperbole (Was: Call for testers for GNU Hyperbole 5.12, a large, useful Emacs package)

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Thu, Jun 16, 2016 at 4:44 AM, tumashu <tumashu@163.com> wrote:

> Today I have tried Rolo， I think it is a very good contact manager， simple
> and powful，
>
but I need a feature which is like bbdb-handy （
> https://github.com/tumashu/bbdb-handy）
>

Doesn't BBDB support inline completion of email addresses already?  Maybe
bbdb-handy just extends that a bit.

Right now, you can just use BBDB with the Hyperbole Rolo to get something
like this and the Rolo will search your BBDB addresses automatically as
well.
I think it is a good idea that the Rolo also offer email address completion
if desired, so I will add this to the future todo/possible feature list.

Thanks for the feedback.

Bob

[-- Attachment #2: Type: text/html, Size: 1582 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

On Wed, Jun 15, 2016 at 8:39 PM, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Robert Weiner <rsw@gnu.org> writes:
>
> > John, if you can remember that far back, maybe you could tell people what
> > you liked about Hyperbole and how you used it to give people an idea.
>
> I remember liking the way I could build up a highly cross-linked set of
> heterogenous data. But I think I realized I was spending too much time
> making
> those connections, so I later moved to Wikis and their auto-linkify of
> CamelCase


Could you explain in a bit more detail or provide a pointer as to how this
works?

(which Hyperbole probably does, but maybe I didn't know it then).
>

Hyperbole started out as a toolkit with the idea that multiple UIs would be
developed for it.  Now we do more of the UI development as part of
Hyperbole.
This could be a useful area to improve once we understand it better.

I'll have to try out the public release once its out, to see how it relates
> to
> Org-mode, which is currently how I manage the sea of tasks and textual
> information that I deal with.


Org-mode is ripe to be the next thing integrated with Hyperbole.  One thing
that would speed this process a bit is if someone could provide me with a
real-world org-mode sample
(it would only be used for technical reference internally and the
information not shared anywhere) exercising a reasonable bit of its
capabilities.  I'm not sure whether the samples
offered with org-mode do enough of this.  Maybe we will have some
discussions with the org-mode developers as well.  I see the two packages
as very complementary at this point
rather than duplicative (some of the extensions are duplicative).


>   But I keep my calendar and contacts outside of
> Emacs these days, because it's necessary to have them on my phone as well,
> since that's the primary place I use that data nowadays.
>

Another user has brought this up.  Our main thought here is to allow for
importation from Google contacts and calendar as there are many tools that
can import to these and they provide a good set of exports for which there
are tools to convert to yet more formats.  There is an Emacs library that
takes an export of Google contacts and exports a basic set of the
information to BBDB which the Hyperbole Rolo can then search.  This kind of
process could be streamlined as the specific use cases are identified.

Bob


> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[-- Attachment #2: Type: text/html, Size: 3809 bytes --]

Re: Differences between Org-Mode and Hyperbole

[raman]

Another thought re contact  management -- LDAP support in Emacs has been
hard to configure -- EUCD fell by the wayside for nearly 10 years, and
ldapsearch.el only supported older versions of LDAP. About a year or
more ago there was some work done on EUDC, but getting EUDC to talk to
various LDAP servers is still somewhat  of a black art --- and this gets
worse when encountering LDAP servers that have security configured
---it's a complete mystery as to how to set up authentication. Getting
some of this abstracted away by wrolo would make it a really nice
front-end -- especially if one could achieve consistency across LDAP and BBDB.
-- 

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Thu, Jun 16, 2016 at 11:38 AM, raman <raman@google.com> wrote:

> Another thought re contact  management -- LDAP support in Emacs has been
> hard to configure -- EUCD fell by the wayside for nearly 10 years, and
> ldapsearch.el only supported older versions of LDAP. About a year or
> more ago there was some work done on EUDC, but getting EUDC to talk to
> various LDAP servers is still somewhat  of a black art --- and this gets
> worse when encountering LDAP servers that have security configured
> ---it's a complete mystery as to how to set up authentication. Getting
> some of this abstracted away by wrolo would make it a really nice
> front-end -- especially if one could achieve consistency across LDAP and
> BBDB.
>

This could be done, though authentication these days is always a bit
difficult.
We would need a test LDAP server though and corporate sponsorship for  such
work
wouldn't be a bad idea either :-)  I will add it to the new feature
wishlist for now as a
good idea.

See this wiki page for EUDC status:

https://www.emacswiki.org/emacs/EUDC

Bob

[-- Attachment #2: Type: text/html, Size: 1586 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Org mode is an example of how Emacs development went astray.

Emacs has many different modes and features.  Users should be able to
use them all either separately or (when meaningful) in combination.
The problem with Org mode is that many separate features have been
tied together inside it.  You can't use them separately.

The right way to integrate Org mode into Emacs would be to pry out
each of those subfeatures and integrate it individually -- so that a
user could use each of them either with or without Org mode.  It is
not too late for people to do this sort of thing, but it should have
been done before.

It may be that this issue applies to Hyperbole too.  If so, I hope
that we will handle Hyperbole better than we handled Org mode.

For instance, Emacs should have a calendar which does not depend on
Hyperbole or BBDB or Org mode (but can work well with any of them).

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> The right way to integrate Org mode into Emacs would be to pry out each of
> those subfeatures and integrate it individually -- so that a user could use
> each of them either with or without Org mode. It is not too late for people
> to do this sort of thing, but it should have been done before.

However, the super-tight coupling of Org-mode's features allows them to
cooperate in ways that are usually "to the point", and sometimes elegant.

I find that when we try to develop separate submodules from scratch, and then
combine them, so many compromises get made during the effort to integrate
these modules (because who can design such a complex system right the first
time, understanding both the best way to abstract features, and the proper way
to expose their functionality?), that we end up with a huge, unwieldly system
that barely delivers on its promises. Some examples do come to mind...

I'm not saying Org-mode represents an ideal design. I'm saying that in the
real world, it represent an effective strategy for making a system that is
maximally *useful*. Hence it's extreme popularity. Even Carsten will admit
he's not a software architect by trade; he did what he did based on what he
wanted to achieve with Org-mode, and not based on engineering decisions.

Now that all the useful work has been done, and experiences gained, it could
be a good time to sift out some of the best of its functionality into separate
modules. However, I disagree with the assessment that it "went astray" by not
striving from separation from the beginning. I would even argue that some
projects that begin that way go astray by doing so.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

On Thu, Jun 16, 2016 at 7:18 PM, Richard Stallman <rms@gnu.org> wrote:

>
> Org mode is an example of how Emacs development went astray.
>
> Emacs has many different modes and features.  Users should be able to
> use them all either separately or (when meaningful) in combination.
> The problem with Org mode is that many separate features have been
> tied together inside it.  You can't use them separately.
>

It is a big ball of wax from what I have seen.  Here someone goes into
extreme detail on his
setup and you can see what Richard is talking about:
http://doc.norang.ca/org-mode.html.

But a lot of people seem to be using it and like it, so we should try to
understand the fundamental
things that the bulk of users like and then work to provide them in a clean
manner.  One such feature
is the ability to write a note about an email message you are reading and
have the note automatically
hyperlinked to the mail message for later reference.  Rapid time and task
tracking are others.

>
> The right way to integrate Org mode into Emacs would be to pry out
> each of those subfeatures and integrate it individually -- so that a
> user could use each of them either with or without Org mode.  It is
> not too late for people to do this sort of thing, but it should have
> been done before.
>
> It may be that this issue applies to Hyperbole too.  If so, I hope
> that we will handle Hyperbole better than we handled Org mode.
>

There is a bit of that but I suspect much less than with org-mode, as data
abstraction is used throughout
with clean highlighting of public and private parts.  It was designed from
the beginning to allow for other
user interfaces to be developed but since that never happened we have just
extended the user interface
ourselves to encompass its functionality.  The various tools (the
Koutliner, the Rolo and HyControl) could
all be used separately if needed with small amounts of work; using them as
part of Hyperbole just makes
them more convenient.

For instance, Emacs should have a calendar which does not depend on
> Hyperbole or BBDB or Org mode (but can work well with any of them).
>

Calendar and diary mode used to be this way.  Is that not the case any more?

So clean abstractions, explicit programming where one can follow the code
rather than having much of the
source be internally generated via macros, and consistent user interfaces
should be a goal, I would think.

Bob

[-- Attachment #2: Type: text/html, Size: 3323 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Thu, Jun 16, 2016 at 7:51 PM, John Wiegley <jwiegley@gmail.com> wrote:

> Even Carsten will admit
> he's not a software architect by trade; he did what he did based on what he
> wanted to achieve with Org-mode, and not based on engineering decisions.
>

Well that explains a lot to those of us unfamiliar with the history.  Maybe
the
popularity is based on two things: 1. they provided a welcoming community
that allowed for many people to contribute; 2. they provided the only
significant
solution in these areas to people who wanted to do them within Emacs.


> Now that all the useful work has been done, and experiences gained, it
> could
> be a good time to sift out some of the best of its functionality into
> separate
> modules.


Or produce a coherent set of requirements and have an Emacs-familiar
architect
and programmer (or team) work to produce new implementations with clean
data abstractions, improved visual formats and even higher usability.  Task
tracking, agendas, outlining and literate programming are important daily
work
areas for  many technical people, so Emacs should have excellent tools in
these
areas.  Has anyone examined the org-mode code to see whether it is well
written or not?

Bob

[-- Attachment #2: Type: text/html, Size: 1832 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Tom]

Robert Weiner <rsw <at> gnu.org> writes:
> 
> Or produce a coherent set of requirements and have an Emacs-familiar architect
> and programmer (or team) work to produce new implementations with clean
> data abstractions, 

In the real word these abstractions always lag behind practical
development like adding new features, because development constantly
moves forward amd while you come up with an abstraction, the new 
developments may already have surpassed that.

In addition, emacs doesn't have a surplus of developers who have
the ability and time to rewrite a huge piece of existing code, so
striving for clean implementation rewrites is not really practical
with the current developer base. There's lot of work to do already
without rewrites too.


> Emacs should have excellent tools in these
> areas.  Has anyone examined the org-mode code to see whether it is well
> written or not?

Org is an excellent, practical tool. That's why people use it.

It may have room for improvement in its internals, but it can be
said about other parts of emacs also. In software development there 
is rarely time to rewrite a big piece of existing code and it's
especially true for volunteer projects with constrained resources.

Re: Differences between Org-Mode and Hyperbole

[Eric Abrahamsen]

Robert Weiner <rsw@gnu.org> writes:

> On Thu, Jun 16, 2016 at 7:51 PM, John Wiegley <jwiegley@gmail.com>
> wrote:
>
>     Even Carsten will admit
>     he's not a software architect by trade; he did what he did based
>     on what he
>     wanted to achieve with Org-mode, and not based on engineering
>     decisions.
>
> Well that explains a lot to those of us unfamiliar with the history. 
> Maybe the
> popularity is based on two things: 1. they provided a welcoming
> community
> that allowed for many people to contribute; 2. they provided the only
> significant
> solution in these areas to people who wanted to do them within Emacs.

Another important reason is that Org is kind of "the Emacs of Emacs".
Meaning a big homogenized, generalized environment, where you can put
"all your stuff", and it all operates according to the same basic set of
rules. Once you've grasped those rules, you feel as if you're truly in
control of your environment.

In this sense, Org is essentially a simplified version of Emacs: meaning
that a greater number of people with a lower programming skill level can
reach that same feeling of flexibility, control, and freedom. That's
what drew me into it, at any rate.

No one has yet tried to make an email client based on Org, thank god,
but it looms on the horizon as a terrible possibility.

>     Now that all the useful work has been done, and experiences
>     gained, it could
>     be a good time to sift out some of the best of its functionality
>     into separate
>     modules.
>
> Or produce a coherent set of requirements and have an Emacs-familiar
> architect
> and programmer (or team) work to produce new implementations with
> clean
> data abstractions, improved visual formats and even higher usability. 
> Task
> tracking, agendas, outlining and literate programming are important
> daily work
> areas for  many technical people, so Emacs should have excellent tools
> in these
> areas.  Has anyone examined the org-mode code to see whether it is
> well
> written or not?

Nicolas Goaziou did heroic work cleaning up and rationalizing the Org
document structure, and its export framework. To me, this one of Org's
"base units".

Someone will correct me if I'm wrong, but the Agenda/TODO system
(another of Org's "base units") hasn't undergone the same cleanup, so
far as I'm aware. This is a potential area for refactoring and
separation from the Org codebase, since theoretically there's no reason
why the Agenda should be limited to Org.

The amount of work that would entail is staggering.

E

Re: Differences between Org-Mode and Hyperbole

[raman]

1+.

Systems like org-mode, the browser platform etc that grow "organically"
often reflect both the goodness and the badness that we later perceive.
-- 

Re: Differences between Org-Mode and Hyperbole

[raman]

Tom <adatgyujto@gmail.com> writes:

Also, this is an excellent example of the purist vs pragmatist view --
getting closer to home, Common Lisp or Scheme proponents have likely
said the same about emacs Lisp:-)> Robert Weiner <rsw <at> gnu.org> writes:
>> 
>> Or produce a coherent set of requirements and have an Emacs-familiar architect
>> and programmer (or team) work to produce new implementations with clean
>> data abstractions, 
>
> In the real word these abstractions always lag behind practical
> development like adding new features, because development constantly
> moves forward amd while you come up with an abstraction, the new 
> developments may already have surpassed that.
>
> In addition, emacs doesn't have a surplus of developers who have
> the ability and time to rewrite a huge piece of existing code, so
> striving for clean implementation rewrites is not really practical
> with the current developer base. There's lot of work to do already
> without rewrites too.
>
>
>> Emacs should have excellent tools in these
>> areas.  Has anyone examined the org-mode code to see whether it is well
>> written or not?
>
> Org is an excellent, practical tool. That's why people use it.
>
> It may have room for improvement in its internals, but it can be
> said about other parts of emacs also. In software development there 
> is rarely time to rewrite a big piece of existing code and it's
> especially true for volunteer projects with constrained resources.

-- 

Re: Differences between Org-Mode and Hyperbole

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>Org mode is an example of how Emacs development went astray.
>
>Emacs has many different modes and features.  Users should be able to
>use them all either separately or (when meaningful) in combination.
>The problem with Org mode is that many separate features have been
>tied together inside it.  You can't use them separately.
>
>The right way to integrate Org mode into Emacs would be to pry out
>each of those subfeatures and integrate it individually -- so that a
>user could use each of them either with or without Org mode.  It is
>not too late for people to do this sort of thing, but it should have
>been done before.
>
>It may be that this issue applies to Hyperbole too.  If so, I hope
>that we will handle Hyperbole better than we handled Org mode.
>
>For instance, Emacs should have a calendar which does not depend on
>Hyperbole or BBDB or Org mode (but can work well with any of them).

I think (probably agreeing with John W) that this is oversimplifying.

Org Mode, like Emacs, requires a fair amount of investment on the part of the user before the rewards arrive.  Once the rewards finally start arriving, the investment becomes worth it -- but until until then, one makes the effort on faith.  Unfortunately, the investment of effort required for Org Mode is not the _same_ effort as for Emacs.  First one makes the Emacs investment, and then later one makes the Org Mode investment on top of that.  Both will pay off, if the investment is done right.

But if one hasn't made that investment for Org Mode, then it is easy to view Org Mode as having gone astray.

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

On Fri, Jun 17, 2016 at 1:02 AM, Tom <adatgyujto@gmail.com> wrote:

> Robert Weiner <rsw <at> gnu.org> writes:
> >
> > Or produce a coherent set of requirements and have an Emacs-familiar
> architect
> > and programmer (or team) work to produce new implementations with clean
> > data abstractions,
>
> In the real word these abstractions always lag behind practical
> development like adding new features, because development constantly
> moves forward amd while you come up with an abstraction, the new
> developments may already have surpassed that.
>

I have seen a lot of counterexamples to this where abstraction and
architecture are worked on first and the code that comes after far exceeds
comparable work that started with a code first, see what sticks attitude.
I am sure there are examples on both sides.


> In addition, emacs doesn't have a surplus of developers who have
> the ability and time to rewrite a huge piece of existing code, so
> striving for clean implementation rewrites is not really practical
> with the current developer base. There's lot of work to do already
> without rewrites too.
>

Fair enough, people have to be interested in attacking large problems and
volunteers choose what they attack.


> > Emacs should have excellent tools in these
> > areas.  Has anyone examined the org-mode code to see whether it is well
> > written or not?
>
> Org is an excellent, practical tool. That's why people use it.
>
> It may have room for improvement in its internals, but it can be
> said about other parts of emacs also. In software development there
> is rarely time to rewrite a big piece of existing code and it's
> especially true for volunteer projects with constrained resources.


It can be difficult to redesign running and deployed code but it has been
done many times and there is no specific timeframe.  It would be great to
hear from the authors on what they feel about the codebase and what parts
if any could use attention so people might look there.

Bob

[-- Attachment #2: Type: text/html, Size: 2880 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Fabrice Popineau]

Tom <adatgyujto <at> gmail.com> writes:

> 
> In addition, emacs doesn't have a surplus of developers who have
> the ability and time to rewrite a huge piece of existing code, so

I don't want to diminish the role of all the other contributors
nor the official maintainers but
in the case of Org mode, there is at least one person who 
specifically introduced such abstractions by rewriting large parts
of the code base and he should be praised for that:
Nicolas Goaziou <mail@nicolasgoaziou.fr>

He is certainly not the only contributor, but he definitely took 
the lead in this area of abstractions at the root of the 
current Org mode. IMHO, this is what makes Org mode rock solid
today. 
 
Fabrice

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Sat, Jun 18, 2016 at 12:47 PM, Fabrice Popineau <
fabrice.popineau@gmail.com> wrote:

> I don't want to diminish the role of all the other contributors
> nor the official maintainers but
> in the case of Org mode, there is at least one person who
> specifically introduced such abstractions by rewriting large parts
> of the code base and he should be praised for that:
> Nicolas Goaziou <mail@nicolasgoaziou.fr>
>

That is great to hear.  Thanks Nicolas!

Bob

[-- Attachment #2: Type: text/html, Size: 953 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Another important reason is that Org is kind of "the Emacs of Emacs".
  > Meaning a big homogenized, generalized environment, where you can put
  > "all your stuff",

The problem is that this walls off sub-Org facilities from the rest of
Emacs.  They depend on org and are not usable on their own.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Org Mode, like Emacs, requires a fair amount of investment on the
  > part of the user before the rewards arrive.  Once the rewards
  > finally start arriving, the investment becomes worth it -- but
  > until until then, one makes the effort on faith.

That may be true, but I stand by what I said.
It is fine to have a structured editing mode, but it was
bad design to make other facilities depend on it in this way.
That makes a distortion in the overall design of Emacs.

The other facilities should be separate things, even if they
can work with the structured editing mode.  Even if they ALWAYS
use the structured editing mode, they should be separate
as far as the user is concerned, not "part of" it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Fabrice Popineau]

Richard Stallman <rms <at> gnu.org> writes:

> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Another important reason is that Org is kind of "the Emacs of Emacs".
>   > Meaning a big homogenized, generalized environment, where you can put
>   > "all your stuff",
> 
> The problem is that this walls off sub-Org facilities from the rest of
> Emacs.  They depend on org and are not usable on their own.
> 

Org mode is built around '.org' files (and a 'philosophy'). 
Albeit they are text files, they have some syntax and semantics
provided by the associated mode. Not everyone will adhere to that.

Somehow, you could say the same from the VI emulation modes under Emacs.
There is a whole universe around Evil under Emacs : 52 packages on MELPA.

This is the problem with a programmable editor: 
people start to program it and they use it 
because they can program it :-)

Regards,

Fabrice

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

I think Richard is saying that if you implement a subsystem like a to do manager then that subsystem should be all you need, not a bunch of other unrelated parts that happen to ship in one package.  Then that subsystem could be loaded by itself and relied upon for both programming and interactive purposes by other packages, to maximize reuse not to limit it.  This does often require more work to provide better cross-module separation. -- Bob

Re: Differences between Org-Mode and Hyperbole

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

2016-06-19 13:49 GMT+02:00 Robert Weiner <rswgnu@gmail.com>:

> I think Richard is saying that if you implement a subsystem like a to do
> manager then that subsystem should be all you need, not a bunch of other
> unrelated parts that happen to ship in one package.


To manage your todo list, you need some kind of format.
There are lots of alternatives.
Org has its own.
Look at org-element.el, the parser for the Org syntax.
Org is built around that.
I don't see Org as a bunch of unrelated parts:
they are very related by the shared syntax and parser.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1050 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>  > Org Mode, like Emacs, requires a fair amount of investment on the
>  > part of the user before the rewards arrive.  Once the rewards
>  > finally start arriving, the investment becomes worth it -- but
>  > until until then, one makes the effort on faith.
>
>That may be true, but I stand by what I said.
>It is fine to have a structured editing mode, but it was
>bad design to make other facilities depend on it in this way.
>That makes a distortion in the overall design of Emacs.
>
>The other facilities should be separate things, even if they
>can work with the structured editing mode.  Even if they ALWAYS
>use the structured editing mode, they should be separate
>as far as the user is concerned, not "part of" it.

Ah, sorry to make you [sort of] repeat yourself.  Yes, this is a separate point from the one I was addressing, and may well be true.

In general, I'm not sure how one would start extracting Org Mode features to make them independent from Org Mode.  I think each feature would have to be handled on a case-by-case basis, because each of them depends on different aspects of Org Mode -- though what most of the features have in common is that they depend at least on the *syntax* of Org Mode files.

Overall, this could be viewed as one of them most massive piles of technical debt in Emacs.  Gulp.

Re: Differences between Org-Mode and Hyperbole

[Tom]

Karl Fogel <kfogel <at> red-bean.com> writes:

> though what most of the features have in common is that they
> depend at least on the *syntax* of Org Mode files.
> 

Not necessarily. I mean it's hard to imagine that when someone
wrote a new feature for org then he always reimplemented parsing
of orgmode entries and such instead of calling some internal api
function like (orgmode-get-node-property "x").

I don't know the code, but at least there is a possibility that
there's some internal api which orgmode features use, instead of
dealing with text entries directly.

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Friday, 17 Jun 2016 at 05:02, Tom wrote:
> Robert Weiner <rsw <at> gnu.org> writes:
>> Emacs should have excellent tools in these
>> areas.  Has anyone examined the org-mode code to see whether it is well
>> written or not?
>
> Org is an excellent, practical tool. That's why people use it.

Indeed.  Pragmatic approach.  It may be lacking in design, although much
has been rewritten over the years, more recently by Nicolas, but it
works and works very well.

It may consist of a number of distinct functionalities but the reality
is that actually being productive while working (writing text and code
while managing projects and emails) requires using many of these
distinct functionalities (export, babel, agenda, capture).  For me, org
provides a unifying experience that has enriched my emacs use (and I
speak as an emacs user from the 80s...).

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Saturday, 18 Jun 2016 at 14:06, Richard Stallman wrote:

[...]

> That may be true, but I stand by what I said.
> It is fine to have a structured editing mode, but it was
> bad design to make other facilities depend on it in this way.

But it is the structure that provides the basis for those facilities?

Without the facilities, you end up with outline mode which, to me, never
really seemed to fulfil any useful task in my normal work practices
beyond simply writing hierarchical text...

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Tue, Jun 28, 2016 at 11:23 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> t may consist of a number of distinct functionalities but the reality
> is that actually being productive while working (writing text and code
> while managing projects and emails) requires using many of these
> distinct functionalities (export, babel, agenda, capture).  For me, org
> provides a unifying experience that has enriched my emacs use (and I
> speak as an emacs user from the 80s...).
>

​Yes.  Hyperbole is similar; it has distinct subsystems that can all be
used together and are unified via a simple menu interface.  Although there
is presently no support for org-mode in Hyperbole because we haven't
gotte​n to it yet, there is little overlap in their detailed
functionalities, so you can improve your productivity further by using both
of them.

A new Hyperbole release for emacs developers should be out by the end of my
workday today.

Bob

[-- Attachment #2: Type: text/html, Size: 1757 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Because the various subfeatures of Org mode were designed inside Org mode,
they turn Org mode into a separate editor within Emacs.

  > Indeed.  Pragmatic approach.  It may be lacking in design, although much
  > has been rewritten over the years, more recently by Nicolas, but it
  > works and works very well.

It must be good to use, to have so many users.  But that's a different
issue.  These submodes should be designed so that they individually
fit into Emacs.

  > > That may be true, but I stand by what I said.
  > > It is fine to have a structured editing mode, but it was
  > > bad design to make other facilities depend on it in this way.

  > But it is the structure that provides the basis for those facilities?

Since I don't know Org mode, I don't know what you mean by this
statement.  "The basis" has various possible meanings and I can't tell
what you mean.

The reason I don't know Org mode is that I'd have to start by learning
basic Org mode, which I am not interested in, before I see what its
specific features are.  At that point, I gave up.

In any case, there are many Emacs facilities that use other Emacs
facilities and avoid causing this kind of problem.  I am sure
it would be possible to define a structure editing library package
and have various modes use it.  These modes would have a similarity,
but you would be able to learn any one of them on its own.

Indeed, if you learned two of them, you'd see a similarity, and that
similarity might be called "Orgmode".  Nothing wrong with that.
It would avoid the problem that Org mode has now.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

On Wed, Jun 29, 2016 at 10:34 AM, Richard Stallman <rms@gnu.org> wrote:
> The reason I don't know Org mode is that I'd have to start by learning
> basic Org mode, which I am not interested in, before I see what its
> specific features are.  At that point, I gave up.

This seems to be a major part of your issue with Org mode.  Could you
explain in some detail what you mean specifically by having to learn
basic Org mode before seeing what its features are?  Give some
examples of what you would have to learn that you do not want to learn
and then give one example of a specific feature that you would be
interested in using, e.g. time tracking, and why it should not require
this.  This will help everyone understand more precisely what your
objections are.

Bob

Re: Differences between Org-Mode and Hyperbole

[Tom]

Richard Stallman <rms <at> gnu.org> writes:
> 
> The reason I don't know Org mode is that I'd have to start by learning
> basic Org mode, which I am not interested in, before I see what its
> specific features are.  At that point, I gave up.

Orgmode has a very well written manual in info and therefore in html
too: 

https://www.gnu.org/software/emacs/manual/html_node/org/index.html

The top level page of the manual lists org features and you can 
dig down a node if you want to know more about it.

Re: Differences between Org-Mode and Hyperbole

[Allen S. Rout]

On 06/29/2016 10:34 AM, Richard Stallman wrote:

> The reason I don't know Org mode is that I'd have to start by learning
> basic Org mode, which I am not interested in, before I see what its
> specific features are.  At that point, I gave up.

IMO, The simplest "start learning Org mode" case is to write plain text
with some structure, export the text with all default behavior, and be
pleasantly surprised at how sufficient it is for e.g. a whitepaper or
other professional communication.

I've written TeX and LaTeX since the 80's.  There's much to love about
it, but much to keep track of.  Since I started using Org as my "source
code" for documents,   I've been able to use as much TeX clue as I care
to, and ignore everything else, because it more or less Just Works.

There's not much overhead in exercising this use case:  Just compose a
speech, and insert

*  headers
** representing some
*** heirarchy

you feel appropriate.


Not to be whiny, but if you aren't willing to give that a shot, I think
it's reasonable to interpret that you have set your cap against Org,
rather than rejecting it on the merits.   Nothing wrong with that, but
it helps folks understand that there's no point prosecuting the
persuasive goal. :)

---

The next iteration is when you want to include a figure or such, and
instead of copying a PNG from the filesystem, you conceive the desire:
"Here's the gnuplot process to generate the image I want... I wish I
could just generate the image at document 'compile' time..."   and hey
presto, you can.

For me, that was the thing that turned org-mode from an interesting
environment into pure electronic heroin.  I have infrastructure status
report documents which contain all the instructions necessary to query
my universe for the data necessary to generate the report.   Critically,
all the instructions are _enclosed_ in the document, which represents an
aesthetic and semantic completeness I find very powerful.   It's the
literate programming thing:  Here's what I'm going to do, and [here it
is being done].


- Allen S. Rout

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Wed, 29 Jun 2016 16:33:47 +0000 (UTC)
> 
> Richard Stallman <rms <at> gnu.org> writes:
> > 
> > The reason I don't know Org mode is that I'd have to start by learning
> > basic Org mode, which I am not interested in, before I see what its
> > specific features are.  At that point, I gave up.
> 
> Orgmode has a very well written manual in info and therefore in html
> too: 
> 
> https://www.gnu.org/software/emacs/manual/html_node/org/index.html
> 
> The top level page of the manual lists org features and you can 
> dig down a node if you want to know more about it.

I'm not talking for Richard, but if I understand his point correctly,
you are missing it.

Let's take your suggestion, for example.  I go to the main menu of the
Org manual, and I see this list:

  * Menu:

  * Introduction::                Getting started
  * Document Structure::          A tree works like your brain
  * Tables::                      Pure magic for quick formatting
  * Hyperlinks::                  Notes in context
  * TODO Items::                  Every tree branch can be a TODO item
  * Tags::                        Tagging headlines and matching sets of tags
  * Properties and Columns::      Storing information about an entry
  * Dates and Times::             Making items useful for planning
  * Capture - Refile - Archive::  The ins and outs for projects
  * Agenda Views::                Collecting information into views
  * Markup::                      Prepare text for rich export
  * Exporting::                   Sharing and publishing notes
  * Publishing::                  Create a web site of linked Org files
  * Working With Source Code::    Export, evaluate, and tangle code blocks
  * Miscellaneous::               All the rest which did not fit elsewhere
  * Hacking::                     How to hack your way around
  * MobileOrg::                   Viewing and capture on a mobile device
  * History and Acknowledgments::  How Org came into being
  * GNU Free Documentation License::  The license for this documentation.
  * Main Index::                  An index of Org's concepts and features
  * Key Index::                   Key bindings and where they are described
  * Command and Function Index::  Command names and some internal functions
  * Variable Index::              Variables mentioned in the manual

Let's say, I'm interested in exporting my documents in various
formats, being told by many people that Org is excellent in that
area.  So I go to the "Exporting" menu item above, and I read this:

  12 Exporting
  ************

  The Org mode export facilities can be used to export Org documents or
  parts of Org documents to a variety of other formats.  In addition,
  these facilities can be used with `orgtbl-mode' and/or `orgstruct-mode'
  in foreign buffers so you can author tables and lists in Org syntax and
  convert them in place to the target language.

This sounds like saying that only documents formatted in Org formats
can be exported.  But I have plain-text documents, not Org documents,
so does this mean I cannot do this with Org?

Next, I try "Working With Source Code", because my friends tell meOrg
has this fascinating feature whereby you can embed source fragments in
your documents.  And I read this:

  14 Working with source code
  ***************************

  Source code can be included in Org mode documents using a `src' block,
  e.g.:

       #+BEGIN_SRC emacs-lisp
	 (defun org-xor (a b)
	    "Exclusive or."
	    (if a (not b) b))
       #+END_SRC

Once again, this sounds like saying that my documents _must_ be Org
formatted, or the feature won't work.

Do you see the point now?

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You've done a good job of explaining a part of the problem.  I think
that is a consequence of a bigger point: that various facilities are
presented as _part of_ Org mode.

Maybe some of these facilities could actually work without using Org
mode as such.  But it is inconvenient that they are _presented_ as
part of Org mode.

It appears that some of these facilities can't work at all apart from
Org mode.

Now, imagine that instead of Org mode we had a library of common
commands for structure editing modes.  They might perhaps be the same
commands that Org mode has now.  But suppose this were something for
various modes to use -- just as various read-only modes use SPC and
DEL for scrolling, but more so.  That could have the same useful
similarities, without the drawback.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There's not much overhead in exercising this use case:  Just compose a
  > speech, and insert

  > *  headers
  > ** representing some
  > *** heirarchy

  > you feel appropriate.

  > Not to be whiny, but if you aren't willing to give that a shot,

Give what a shot, exactly?  I already put such text in the buffer,
when such text is what I want.  So I think I've already "given that a shot".
Or do you mean something else?  Like, editing it in Org mode?

How would that be different from editing it in Fundamental mode?
What benefit would it give me?

  > The next iteration is when you want to include a figure or such, and
  > instead of copying a PNG from the filesystem, you conceive the desire:
  > "Here's the gnuplot process to generate the image I want... I wish I
  > could just generate the image at document 'compile' time..."   and hey
  > presto, you can.

It might be useful if I used gnuplot.  But I have never used it.

I am sure Org mode is useful for the people who use it.
I'm not disputing that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>        #+BEGIN_SRC emacs-lisp
> 	 (defun org-xor (a b)
> 	    "Exclusive or."
> 	    (if a (not b) b))
>        #+END_SRC
>
> Once again, this sounds like saying that my documents _must_ be Org
> formatted, or the feature won't work.
>
> Do you see the point now?

I see your point, but you can't blame Org for it.  For all those
powerful features to work - under plain text - the Org people had to
invent some sort of "markup" language.  I guess they were just the first
to succeed with this "organiser" idea, utilising disparate Emacs modules
(folding, Calc, calendar, BBDB, GNUS, Elisp, dired, ...) from *one*
major mode.  It is this unifying approach which is most important, I
want my document for capturing, organising and storing information, I
need to calculate and visualise information and also that the very same
sources can be published as well.

And I don't have a problem with its formatting (just an unavoidable
thing in general) because I experience Org as an enabler of Emacs'
functionality triggered from *one* document.  So for me Org is as much
Emacs and more as, for example, dired is!

         Dieter

-- 
Best wishes
H. Dieter Wilhelm
Kelkheim, Germany

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
> Date: Thu, 30 Jun 2016 00:15:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >        #+BEGIN_SRC emacs-lisp
> > 	 (defun org-xor (a b)
> > 	    "Exclusive or."
> > 	    (if a (not b) b))
> >        #+END_SRC
> >
> > Once again, this sounds like saying that my documents _must_ be Org
> > formatted, or the feature won't work.
> >
> > Do you see the point now?
> 
> I see your point, but you can't blame Org for it.

No one is blaming Org.  If you can understand how the above turns down
potential users, you can appreciate the advantages of the alternative
design principles suggested by Richard.

> And I don't have a problem with its formatting (just an unavoidable
> thing in general) because I experience Org as an enabler of Emacs'
> functionality triggered from *one* document.  So for me Org is as much
> Emacs and more as, for example, dired is!

For a casual user, these requirements are a disadvantage.

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Wednesday, 29 Jun 2016 at 10:34, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Because the various subfeatures of Org mode were designed inside Org mode,
> they turn Org mode into a separate editor within Emacs.
>
>   > Indeed.  Pragmatic approach.  It may be lacking in design, although much
>   > has been rewritten over the years, more recently by Nicolas, but it
>   > works and works very well.
>
> It must be good to use, to have so many users.  But that's a different
> issue.  These submodes should be designed so that they individually
> fit into Emacs.

I think there is some basic misunderstanding here.

One way to look at org mode is as an enhanced text-mode.  The
enhancements are that org will look for special markup in the text to
provide extra capabilities.  If there is no markup, it is essentially
text mode and does not get in the way.  The advantage is that if you
start using some of the markup, akin to outline-mode, you can start
making use of the rather extensive features.  But you don't have to.

For the features above and beyond text mode, you can start slowly,
e.g. just using it as an outliner that works much better than outline
mode.  You can then start adding project management aspects, if you
wish, through simple keywords on outline headings.  Or you can start
using lists (numbered, unnumbered, boxed).

If you want to export for pretty printing, you can export even simple
text that has no markup.

If you want literate programming, not only is this just plain text
markup, you have access to the programming languages' own modes and
fontification.

>   > But it is the structure that provides the basis for those facilities?
>
> Since I don't know Org mode, I don't know what you mean by this
> statement.  "The basis" has various possible meanings and I can't tell
> what you mean.

Simply that if markup is there, org can use it.  If there is no markup,
the text is just text.  Nothing more.  Org mode is then just text mode.

> The reason I don't know Org mode is that I'd have to start by learning
> basic Org mode, which I am not interested in, before I see what its
> specific features are.  At that point, I gave up.

Well, basic org mode is just text mode so learning it is a no-op.  My
default mode now for text files is org mode because it does not get in
the way at all even if you do not wish to use any of the features.

However, as soon as you want to try some of the features out, they are
extras that do not stop you from working normally.  Adding "TODO" to a
headline automatically gives you task management.  Obviously, this being
emacs, there are many customisations and key bindings you can use (or
change) but you can simply type text and all features become available.

> Indeed, if you learned two of them, you'd see a similarity, and that
> similarity might be called "Orgmode".  Nothing wrong with that.
> It would avoid the problem that Org mode has now.

But org mode is not really about modes; it is about markup in a text
file.  That's what makes it powerful.  If need be, you can edit your org
files in text mode, or even fundamental mode.  Obviously, to make use of
the features the markup supports, you have to invoke the various org
functions.

In terms of software design, the key problems (many or most of which
have been addressed) were related to regexps and fontification for large
documents.  The structure that org expects (but does not require) to
support some of the more fancy issues has been cleaned up to improve
scalability.

Finally, in many ways, org exemplifies what is special about emacs:
being able to work with simple text files but work the way I want
through customisation and extension via elisp.  

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

Re: Differences between Org-Mode and Hyperbole

[Allen S. Rout]

On 06/29/2016 04:04 PM, Richard Stallman wrote:
> 
> Give what a shot, exactly?  I already put such text in the buffer, 
> when such text is what I want.  So I think I've already "given that
> a shot". Or do you mean something else?  Like, editing it in Org
> mode?

I have composed and discarded three replies to this, and gave up.  Then
I read Dieter's phrase:


On 06/29/2016 06:15 PM, H. Dieter Wilhelm wrote:
> 
> It is this unifying approach which is most important, I want my 
> document for capturing, organising and storing information, I need to
> calculate and visualise information and also that the very same 
> sources can be published as well.

and it crystallized.

Richard, I summarize your desire as "Org should be implemented so that
its features can be composed."   I reply:  "Org is an attempt to
-perform- just that composition."  I can use more of the various
packages in Emacs, simultaneously, in org-mode, than in any other
environment I've used.

So when you talk about wanting to use "org-mode features" somewhere
else, it registers on my brain like a category error.   "Can't you
please make the intersection where all roads meet, be over here where
there's just one road? " ....

I know the description of org-mode as purely alloy of other things is
incorrect: nothing's pure.

But maybe this will help the conversation.

- Allen S. Rout

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This seems to be a major part of your issue with Org mode.  Could you
  > explain in some detail what you mean specifically by having to learn
  > basic Org mode before seeing what its features are?

I don't remember -- it was years ago that I took a look at it
and gave up.  I don't have time to revisit it now.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 06/30/2016 01:58 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    > This seems to be a major part of your issue with Org mode.  Could you
>    > explain in some detail what you mean specifically by having to learn
>    > basic Org mode before seeing what its features are?
>
> I don't remember -- it was years ago that I took a look at it
> and gave up.  I don't have time to revisit it now.
>

It is hard to take this criticism of Org seriously when it comes from 
the uninformed position of not knowing how to use either old or recent 
versions of it. Org has its flaws, but the the alleged failure of 
various unspecified pieces to work outside of Org isn't one of them.

Org originated as a project outside of Emacs and it wasn't an official 
part of Emacs until recent years. It is natural that its elements are 
meant to work in Org. If an element happens to work outside of Org, that 
is just a lucky circumstance. If there is a desire to use Org elements 
outside of Org, then please write the code to do that, or fork Org, or 
start a new project. Org is free software after all.

The Org community is very open to suggestions for improvement. If anyone 
has specific suggestions for improvements to Org, instead of vague 
pronouncements about alleged failures, then please send them to the Org 
mailing list.

I started using Org long before it was an official part of Emacs, and it 
appears to me that perhaps incorporating Org into official Emacs was the 
failure, not the inability of some of its components to work outside of Org.

Scott Randby

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Scott Randby <srandby@gmail.com>
> Date: Thu, 30 Jun 2016 19:02:42 -0400
> 
> On 06/30/2016 01:58 PM, Richard Stallman wrote:
> >    > This seems to be a major part of your issue with Org mode.  Could you
> >    > explain in some detail what you mean specifically by having to learn
> >    > basic Org mode before seeing what its features are?
> >
> > I don't remember -- it was years ago that I took a look at it
> > and gave up.  I don't have time to revisit it now.
> 
> It is hard to take this criticism of Org seriously

This discussion will be much more useful if people would not take it
as an attack on Org.  In particular, the criticism is not about Org
from POV of the end user, it's about its design principles.  IOW, the
real subject of this discussion is how should we design large Emacs
packages, and Org is just being used as an example, to have some
context and some concrete instances of the abstract ideas.  See the
beginning of the discussion.

If people could stop being defensive about Org, and instead think more
broadly, and perhaps bring some other examples into this discussion,
we might actually reach some useful conclusions that could help us in
the future.

Please note that I am an Org user myself, albeit not a heavy user.
When I need to make sense out of many tasks and manage them in a
GTD-like manner, I use Org.  Some of the more serious tasks of my work
on Emacs, such as the bidirectional display, were managed via Org.

But using Org and being fond of it doesn't mean we cannot learn from
its design for the future, and it doesn't mean we cannot decide that
an alternative design could yield a more useful set of feature that
would be easier to learn than what we have now.  It's a legitimate
conclusion, and it doesn't in any way denigrate Org, because a package
design isn't determined solely by its designers, it is determined by
many other factors, like the available time and resources, on which no
one has full control.  Therefore, saying that an alternative design
could yield better results doesn't put any blame on those who worked
on the package, and shouldn't put those people on the defensive.

> The Org community is very open to suggestions for improvement. If anyone 
> has specific suggestions for improvements to Org, instead of vague 
> pronouncements about alleged failures, then please send them to the Org 
> mailing list.

This is exactly what this discussion is NOT about.  Org's design is a
fait accompli, and no one in their right mind will come up with
suggestions to redesign it.  Once again, this is not about some flaw
in Org, it's about design principles of large Emacs packages.

> it appears to me that perhaps incorporating Org into official Emacs
> was the failure

Now, this is uncalled-for, and factually incorrect.

Re: Differences between Org-Mode and Hyperbole

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Scott Randby <srandby@gmail.com>
>> Date: Thu, 30 Jun 2016 19:02:42 -0400
>> 
>> On 06/30/2016 01:58 PM, Richard Stallman wrote:
>> >    > This seems to be a major part of your issue with Org mode.  Could you
>> >    > explain in some detail what you mean specifically by having to learn
>> >    > basic Org mode before seeing what its features are?
>> >
>> > I don't remember -- it was years ago that I took a look at it
>> > and gave up.  I don't have time to revisit it now.
>> 
>> It is hard to take this criticism of Org seriously
>
> This discussion will be much more useful if people would not take it
> as an attack on Org.  In particular, the criticism is not about Org
> from POV of the end user, it's about its design principles.  IOW, the
> real subject of this discussion is how should we design large Emacs
> packages, and Org is just being used as an example, to have some
> context and some concrete instances of the abstract ideas.  See the
> beginning of the discussion.
>
> If people could stop being defensive about Org, and instead think more
> broadly, and perhaps bring some other examples into this discussion,
> we might actually reach some useful conclusions that could help us in
> the future.

Here are a few thoughts in terms of the practical "modularization" of
Org -- whether that actually might happen, or whether this is all just
an abstract for-instance.

1. Document structure and export. The org document structure is already
   pretty darn simple, and export "just works". You need some kind of
   markup and structure before you can export, and I don't see how Org
   could get any simpler, or easier to use. Customizing export gets
   pretty complicated, but customization always does. I don't see how
   (or why) you'd do this part differently.
2. The spreadsheet. Apparently table.el was either too complicated or
   too limiting to be easily used. Probably what should have happened
   here is that table.el should have been improved. There's no intrinsic
   reason why the spreadsheet aspect of Org needs to rely on Org's
   markup, or its major mode. (Though then you start getting into
   something like multiple major modes.)
3. Babel. I don't use this, but it's obviously a really, really powerful
   feature that users cannot find elsewhere. In a sense it *is* multiple
   major modes, done in a very regimented and bounded way. Again, no
   real reason why it needs to be part of Org structure or markup. But
   it would need to be part of *some* markup -- it wouldn't be possible
   without structure. Right now, that structure is Org mode.
4. The agenda. Similar to the spreadsheet and table.el, I think the
   agenda came about because diary.el wasn't doing the trick (I don't
   know the history, maybe someone else will chime in). So again, it's a
   re-working of an existing functionality. The agenda itself is a
   special mode, and there's no reason at all why it needs to be tied to
   Org mode document structure. In fact I've often wanted a way to
   simply inject TODO items programmatically into the Agenda, without
   needing them in Org. I think it would be a great advance to have a
   generalized way of creating TODO data structures (structs or objects,
   maybe) and feeding them to the Agenda. Then Org mode headings would
   simply be one of multiple ways of doing that.

So one observation is, Org got where it is by taking some existing Emacs
libraries, making them easier to use, and allowing them all to coexist
in a single document.

Another is, babel is an interesting take on the problem of multiple
interacting major modes. Not in the HTML/PHP sense, necessarily, but...

Eric

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Friday,  1 Jul 2016 at 16:17, Eric Abrahamsen wrote:

[...]

> So one observation is, Org got where it is by taking some existing Emacs
> libraries, making them easier to use, and allowing them all to coexist
> in a single document.

I think this is the key issue: no other (or maybe some which I don't
know) major packages in Emacs attempt to bring together such disparate
functionalities.  It may be that this goes against some design
principles, most notably Unix with the basic idea of small tools which
connect via pipes, but it does mean that it is possible to manage a
significant project all within one file, or a collection files which are
bound quite seamlessly.

As a prose writing, programming and project management tool, it does
(for me) what other tools have been unable to do.  

I am not being defensive when I say that org has changed how I
work.  Whether this is due to its design or in spite of its design, I
cannot say, but having task management, babel, exporting and outlining
all in one place is fantastic and makes org indispensable to my work
now.

I now just need gnus to be integrated within org and I will be set for
life! :-)

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 07/01/2016 03:45 AM, Eli Zaretskii wrote:
>> From: Scott Randby <srandby@gmail.com>
>> Date: Thu, 30 Jun 2016 19:02:42 -0400
>>
>> On 06/30/2016 01:58 PM, Richard Stallman wrote:
>>>     > This seems to be a major part of your issue with Org mode.  Could you
>>>     > explain in some detail what you mean specifically by having to learn
>>>     > basic Org mode before seeing what its features are?
>>>
>>> I don't remember -- it was years ago that I took a look at it
>>> and gave up.  I don't have time to revisit it now.
>>
>> It is hard to take this criticism of Org seriously
>
> This discussion will be much more useful if people would not take it
> as an attack on Org.  In particular, the criticism is not about Org
> from POV of the end user, it's about its design principles.  IOW, the
> real subject of this discussion is how should we design large Emacs
> packages, and Org is just being used as an example, to have some
> context and some concrete instances of the abstract ideas.  See the
> beginning of the discussion.

I have been following the entire discussion closely. It contains a 
direct attack on Org by someone who clearly doesn't even know the basics 
of Org. No other examples were given, and none other than Org have been 
given so far by anyone else. If Org is being used as just one example, 
please give other examples of Emacs packages that don't live up to the 
vague "design standards" that are desired, and explain why these 
packages violate those standards so that we can understand exactly what 
the problem is.

>
> If people could stop being defensive about Org, and instead think more
> broadly, and perhaps bring some other examples into this discussion,
> we might actually reach some useful conclusions that could help us in
> the future.

Yes, what are those other examples. Please be specific. The statement 
that advocates of Org aren't thinking broadly is false, and it isn't the 
job of Org users to bring other examples into the discussion. I'm not 
concerned about the design of Org because its design is fine and it 
works. Can the design be improved? Obviously. Telling us the design is 
flawed without suggesting how it can be fixed is saying nothing useful.

>
> Please note that I am an Org user myself, albeit not a heavy user.
> When I need to make sense out of many tasks and manage them in a
> GTD-like manner, I use Org.  Some of the more serious tasks of my work
> on Emacs, such as the bidirectional display, were managed via Org.
>
> But using Org and being fond of it doesn't mean we cannot learn from
> its design for the future, and it doesn't mean we cannot decide that
> an alternative design could yield a more useful set of feature that
> would be easier to learn than what we have now.  It's a legitimate
> conclusion, and it doesn't in any way denigrate Org, because a package
> design isn't determined solely by its designers, it is determined by
> many other factors, like the available time and resources, on which no
> one has full control.  Therefore, saying that an alternative design
> could yield better results doesn't put any blame on those who worked
> on the package, and shouldn't put those people on the defensive.

Of course we can learn from the design of Org, but saying that doesn't 
contribute anything to the so-called discussion of design principles. I 
haven't been defensive. Instead, I would like to see specifics. Without 
specifics, then a small number of the comments about Org that have been 
made in this thread are simply uninformed attacks and are therefore 
useless. So someone please fork Org and show us how an alternative 
design is better. We could then compare Org with its fork and see which 
one is better. It would be a great test case for the design principles 
which have yet to be specified.

>
>> The Org community is very open to suggestions for improvement. If anyone
>> has specific suggestions for improvements to Org, instead of vague
>> pronouncements about alleged failures, then please send them to the Org
>> mailing list.
>
> This is exactly what this discussion is NOT about.  Org's design is a
> fait accompli, and no one in their right mind will come up with
> suggestions to redesign it.  Once again, this is not about some flaw
> in Org, it's about design principles of large Emacs packages.

No, the discussion hasn't been about large Emacs packages, it has 
focused on Org. No other packages have been mentioned.

>
>> it appears to me that perhaps incorporating Org into official Emacs
>> was the failure
>
> Now, this is uncalled-for, and factually incorrect.

I did not mean that Org was unsuccessfully incorporated into Emacs. Such 
a claim would be false. What I meant was that the repeated attacks on 
Org (on this thread and others) from a tiny segment of the Emacs 
community have made some Org users (such as myself and a few of my 
friends) regret the merging of Org into Emacs. From my perspective, the 
incorporation was a failure because a small number of influential people 
clearly do not accept Org and have offered no constructive ways of 
making it better. If I had the technical ability, I would fork Org and 
start another project outside of Emacs.

> .
>

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Scott Randby <srandby@gmail.com>
> Date: Fri, 1 Jul 2016 14:38:23 -0400
> 
> > This discussion will be much more useful if people would not take it
> > as an attack on Org.  In particular, the criticism is not about Org
> > from POV of the end user, it's about its design principles.  IOW, the
> > real subject of this discussion is how should we design large Emacs
> > packages, and Org is just being used as an example, to have some
> > context and some concrete instances of the abstract ideas.  See the
> > beginning of the discussion.
> 
> I have been following the entire discussion closely. It contains a 
> direct attack on Org by someone who clearly doesn't even know the basics 
> of Org. No other examples were given, and none other than Org have been 
> given so far by anyone else. If Org is being used as just one example, 
> please give other examples of Emacs packages that don't live up to the 
> vague "design standards" that are desired, and explain why these 
> packages violate those standards so that we can understand exactly what 
> the problem is.

Having just one example in a discussion doesn't constitute an attack
on that single example.

Besides, I think the fact that Richard was turned off by Org so early
in his attempts to learn it should tell us something important.
Richard cannot be accused of being an Emacs outsider, or of not being
capable of learning complex Emacs stuff.

> > If people could stop being defensive about Org, and instead think more
> > broadly, and perhaps bring some other examples into this discussion,
> > we might actually reach some useful conclusions that could help us in
> > the future.
> 
> Yes, what are those other examples. Please be specific. The statement 
> that advocates of Org aren't thinking broadly is false, and it isn't the 
> job of Org users to bring other examples into the discussion.

AFAIU, this discussion was meant for Emacs developers, not for Org
users/advocates.  The suggestion to think broadly was aimed at all of
us, not just for those who think Org was designed in the best way
possible.  Think broadly in this context means think about more than
just Org.

> Telling us the design is flawed without suggesting how it can be
> fixed is saying nothing useful.

AFAIU, Richard's comment was that the design principles were wrong,
not that the design itself was flawed.  The main design principle in
question is that of tight integration between unrelated parts of a
large package.

> Of course we can learn from the design of Org, but saying that doesn't 
> contribute anything to the so-called discussion of design principles. I 
> haven't been defensive. Instead, I would like to see specifics. Without 
> specifics, then a small number of the comments about Org that have been 
> made in this thread are simply uninformed attacks and are therefore 
> useless.

I tried to give a few specific examples up-thread.

> >> it appears to me that perhaps incorporating Org into official Emacs
> >> was the failure
> >
> > Now, this is uncalled-for, and factually incorrect.
> 
> I did not mean that Org was unsuccessfully incorporated into Emacs. Such 
> a claim would be false. What I meant was that the repeated attacks on 
> Org (on this thread and others) from a tiny segment of the Emacs 
> community have made some Org users (such as myself and a few of my 
> friends) regret the merging of Org into Emacs.

AFAIR, Org became part of Emacs in 2005, merely 2 years since its
inception.  I was there when it happened.  To me, this means Org has
been part of Emacs almost from its very beginning.

Re: Differences between Org-Mode and Hyperbole

[Tom]

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> 
> 1. Document structure and export. The org document structure is already
>    pretty darn simple, and export "just works". You need some kind of
>    markup and structure before you can export, and I don't see how Org
>    could get any simpler, or easier to use. 

There is way to abstract it, by using a function to retrieve the 
code to export.

So, for example, instead of accessing the text markup directly the
code should call some (get-code-for-export ...) function which returns
the code pieces, instead of handling org markup directly. This way,
the export feature would not be dependent on the specific org markup,
because it would be hidden behind the implementation of this function.

I don't know org internals, but if the DRY principle is followed then
there already should be exactly one place in the code for each specific
markup handling, because if the same markup is accessed from two 
different places then it should already be abstracted out to a function,
instead having the same implementation of accessing a specific markup at
multiple places.

So if DRY was applied then org should already have internal api functions
for markup access and manipulations, so the export part of the code 
should in theory already be separated from the actual org text format,
and it could also use some other backend implementation.

Re: Differences between Org-Mode and Hyperbole

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> Besides, I think the fact that Richard was turned off by Org so early
> in his attempts to learn it should tell us something important.
> Richard cannot be accused of being an Emacs outsider, or of not being
> capable of learning complex Emacs stuff.

No one doubts his ability to learn complex stuff, but Richard
often says he doesn't have time and I don't know how much time
he spent on it, but Org is a complex package which cannot be appreciated
by just giving it a quick glance.

It's very much like Emacs which if a new a user gives it a quick try 
he will say it's strange looking editor with arcane keybindings and
that's it. We know Emacs is much more than that, but in order to get
a sense of that one has to spend some time with it, immersed in 
the environment.

Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 07/01/2016 03:09 PM, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Scott Randby <srandby@gmail.com>
>> Date: Fri, 1 Jul 2016 14:38:23 -0400
>>
>>> This discussion will be much more useful if people would not take it
>>> as an attack on Org.  In particular, the criticism is not about Org
>>> from POV of the end user, it's about its design principles.  IOW, the
>>> real subject of this discussion is how should we design large Emacs
>>> packages, and Org is just being used as an example, to have some
>>> context and some concrete instances of the abstract ideas.  See the
>>> beginning of the discussion.
>>
>> I have been following the entire discussion closely. It contains a
>> direct attack on Org by someone who clearly doesn't even know the basics
>> of Org. No other examples were given, and none other than Org have been
>> given so far by anyone else. If Org is being used as just one example,
>> please give other examples of Emacs packages that don't live up to the
>> vague "design standards" that are desired, and explain why these
>> packages violate those standards so that we can understand exactly what
>> the problem is.
>
> Having just one example in a discussion doesn't constitute an attack
> on that single example.

Again, what are other examples? If Org is the only example, then what 
makes it different from all the other Emacs packages? If there are more 
examples, then what is it they have in common so that a design 
philosophy can be developed that is universally useful?

I could spend all day being critical of Gnus, but I've never been able 
to figure out how to use it so I don't have any legitimate reason to 
present my uninformed opinion about it. Nobody cares about my opinion 
anyway since I have no standing in the Emacs community. Richard or 
others with influence can make a vague statement that something is wrong 
with Org and the community will think that the opinion has merit when in 
fact it doesn't.

>
> Besides, I think the fact that Richard was turned off by Org so early
> in his attempts to learn it should tell us something important.
> Richard cannot be accused of being an Emacs outsider, or of not being
> capable of learning complex Emacs stuff.

Yes, it says that Richard doesn't know how to use Org. I never accused 
Richard of being an Emacs outsider. Such an accusation would be 
completely false and mean. I wouldn't dare question Richard's ability to 
learn Org either. What I don't see in his statements about Org are 
concrete facts and suggestions except for the fact that much of Org 
doesn't work outside of Org and that this is bad for some unstated 
reason backed up by no evidence.

>
>>> If people could stop being defensive about Org, and instead think more
>>> broadly, and perhaps bring some other examples into this discussion,
>>> we might actually reach some useful conclusions that could help us in
>>> the future.
>>
>> Yes, what are those other examples. Please be specific. The statement
>> that advocates of Org aren't thinking broadly is false, and it isn't the
>> job of Org users to bring other examples into the discussion.
>
> AFAIU, this discussion was meant for Emacs developers, not for Org
> users/advocates.  The suggestion to think broadly was aimed at all of
> us, not just for those who think Org was designed in the best way
> possible.  Think broadly in this context means think about more than
> just Org.

I'm sorry I said anything since I'm not an Emacs developer. But I never 
claimed that Org was designed in the best way possible. Yes, I care more 
about Org than other packages because I use Org for almost all of my 
work, it is a fantastic tool. I'm just tired of these digs at Org from 
people who don't use it.

>
>> Telling us the design is flawed without suggesting how it can be
>> fixed is saying nothing useful.
>
> AFAIU, Richard's comment was that the design principles were wrong,
> not that the design itself was flawed.  The main design principle in
> question is that of tight integration between unrelated parts of a
> large package.

Though I'm not an Emacs or an Org developer, I have to disagree 
slightly. The tight integration between pieces of Org is one of the 
features that makes it so useful. I don't see how modularization of Org 
is going to be easy or even desirable.

>
>> Of course we can learn from the design of Org, but saying that doesn't
>> contribute anything to the so-called discussion of design principles. I
>> haven't been defensive. Instead, I would like to see specifics. Without
>> specifics, then a small number of the comments about Org that have been
>> made in this thread are simply uninformed attacks and are therefore
>> useless.
>
> I tried to give a few specific examples up-thread.

I will read those carefully.

>
>>>> it appears to me that perhaps incorporating Org into official Emacs
>>>> was the failure
>>>
>>> Now, this is uncalled-for, and factually incorrect.
>>
>> I did not mean that Org was unsuccessfully incorporated into Emacs. Such
>> a claim would be false. What I meant was that the repeated attacks on
>> Org (on this thread and others) from a tiny segment of the Emacs
>> community have made some Org users (such as myself and a few of my
>> friends) regret the merging of Org into Emacs.
>
> AFAIR, Org became part of Emacs in 2005, merely 2 years since its
> inception.  I was there when it happened.  To me, this means Org has
> been part of Emacs almost from its very beginning.

I didn't think that Org had been part of Emacs for that long since I 
didn't research the matter. But I started using Org before it was part 
of Emacs, so I too was there when it happened and it didn't happen until 
after Org was fully functional. I supported the move at that time even 
though I never use the version of Org included in Emacs.

>

Re: Differences between Org-Mode and Hyperbole

[John Mastro]

Hi Scott,

Scott Randby <srandby@gmail.com> wrote:
>
> Again, what are other examples? If Org is the only example, then what makes
> it different from all the other Emacs packages? If there are more examples,
> then what is it they have in common so that a design philosophy can be
> developed that is universally useful?
>
> I could spend all day being critical of Gnus, but I've never been able to
> figure out how to use it so I don't have any legitimate reason to present my
> uninformed opinion about it. Nobody cares about my opinion anyway since I
> have no standing in the Emacs community. Richard or others with influence
> can make a vague statement that something is wrong with Org and the
> community will think that the opinion has merit when in fact it doesn't.

In Richard's first email in this thread, he said:

> Org mode is an example of how Emacs development went astray.
>
> Emacs has many different modes and features.  Users should be able to
> use them all either separately or (when meaningful) in combination.
> The problem with Org mode is that many separate features have been
> tied together inside it.  You can't use them separately.
>
> The right way to integrate Org mode into Emacs would be to pry out
> each of those subfeatures and integrate it individually -- so that a
> user could use each of them either with or without Org mode.  It is
> not too late for people to do this sort of thing, but it should have
> been done before.

I hope coming back to this helps make the context more clear. He is
criticizing how Org was integrated into Emacs, not Org itself.

Beyond that, I hope that we can all dial back the negative emotions in
this conversation. Org is an important, well-loved Emacs package. At the
same time, some people don't like it, or don't like particular aspects
of its implementation. Nothing is equally liked by everyone, and that's
okay, even if you're pretty sure those people are mistaken!

        John

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1. Document structure and export. The org document structure is already
  >    pretty darn simple, and export "just works". You need some kind of
  >    markup and structure before you can export, and I don't see how Org
  >    could get any simpler, or easier to use.

Maybe you're right.  I don't see anything bad about having such a structured
editing mode.

  > 2. The spreadsheet. Apparently table.el was either too complicated or
  >    too limiting to be easily used. Probably what should have happened
  >    here is that table.el should have been improved. There's no intrinsic
  >    reason why the spreadsheet aspect of Org needs to rely on Org's
  >    markup, or its major mode.

This could be an instance of the problem I mean.  If the spreadsheet
were a separate facility from Org mode, so that you could use either
one without the other, that doesn't mean they could not work together
well also.

				  (Though then you start getting into
  >    something like multiple major modes.)

Indeed, people are working gradually on support for having multiple
major modes in one buffer.

  > 3. Babel. I don't use this, but it's obviously a really, really powerful
  >    feature that users cannot find elsewhere. In a sense it *is* multiple
  >    major modes, done in a very regimented and bounded way. Again, no
  >    real reason why it needs to be part of Org structure or markup. But
  >    it would need to be part of *some* markup -- it wouldn't be possible
  >    without structure. Right now, that structure is Org mode.

What is Babel?

I'm not against having various other things use the markup of Org format
when they need such a format.

  > 4. The agenda. Similar to the spreadsheet and table.el, I think the
  >    agenda came about because diary.el wasn't doing the trick (I don't
  >    know the history, maybe someone else will chime in). So again, it's a
  >    re-working of an existing functionality. The agenda itself is a
  >    special mode, and there's no reason at all why it needs to be tied to
  >    Org mode document structure.

I've never been able to come up with a concept that includes both an agenda
and the other features of Org mode.

  > So one observation is, Org got where it is by taking some existing Emacs
  > libraries, making them easier to use, and allowing them all to coexist
  > in a single document.

But it didn't make those things easier to use.  It replaced them --
but not each one by one.  Rather, it replaced all of them with one
complex combined thing.  That's what I see as a problem.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Another example of the same kind of lumping together of features is
Gnus.  Including a mail-sending mode in Gnus made Emacs complicated in
an unnecessary way.

If someone wanted features that Mail mode didn't have,
the best way to add them to Emacs would have been to add them to Mail mode.
The second best way to add them to Emacs,
in case they did not fit into Mail mode,
would have been to make an alternate mail-sending mode,
as an independent feature.

Being independent features doesn't mean they can't work together.
Rmail and Mail mode are both independent features, but they work
together through clean interfaces.

I think Hyperbole is such an example, so I asked Robert to separate
some of its functionalities before we install it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Allen S. Rout]

On 07/01/2016 06:09 PM, Richard Stallman wrote:
>
> 
>   > 3. Babel. I don't use this, but it's obviously a really, really powerful
>   >    feature that users cannot find elsewhere. [...]
> 
> What is Babel?
> 

Babel is a facility that lets a document author include pieces of code
in a document, which may be used either as their text ("Here is the code
I mean") or as their results. ("Here is the output of that code") or both.


Taking a recent example I used at work:  I was attempting to articulate
a system architecture.  I enjoy doing this in graphviz.  I created a
section of my document that was a dot input

#+BEGIN_SRC dot :file fedam.png :cmdline -Kdot -Tpng
digraph  fedam {
  // graph from left to right
  splines=true;
  node [shape=box];
  edge [arrowhead=none,arrowtail=none];
[....]
#+END_SRC

and the babel facility of org took that 'dot document' which I had
written, and inserted the result of 'compiling' that source code.

If my goals had included demonstrating the features of graphviz, I could
have changed some of the declaration, and also displayed the dot source.

The result is analogous to:

LaTeX source file including an image.
dot source file in which the source for the image is recorded
Makefile recording the dependency between the files.


This is the use which is most relevant from the perspective of a
technical document author, but babel goes further:  it defines calling
conventions so that one can pass values from one code block to another.
  This enables one to write a code path which uses, for example from my
own history: PERL to preprocess; shell to fiddle with files; and R to
collate, analyze and generate graphics.

This is all in one document, with the ability to generate and retain
intermediate results if one so desires.

Many languages all trying to work together as one.  Babel.


There is nothing there that couldn't be written with a bunch of
compilers and a makefile.   But expressing them as a single,
literate-programming document is -profoundly- more accessible,
especially to folks who might not think of themselves as systems
integrators.

This polyglot facility is an important reason that Org is very useful to
the 'reproducible research' folks.


http://orgmode.org/worg/org-contrib/babel/


- Allen S. Rout

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Fri, 1 Jul 2016 21:11:54 +0000 (UTC)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 
> > Besides, I think the fact that Richard was turned off by Org so early
> > in his attempts to learn it should tell us something important.
> > Richard cannot be accused of being an Emacs outsider, or of not being
> > capable of learning complex Emacs stuff.
> 
> No one doubts his ability to learn complex stuff, but Richard
> often says he doesn't have time and I don't know how much time
> he spent on it

With his efficiency I came to know and appreciate through many years,
I'm sure he spent "enough time" on it.  Please accept that as an
assumption that doesn't need to be questioned.

> but Org is a complex package which cannot be appreciated by just
> giving it a quick glance.

Which is exactly the problem we are talking about.  Does a package
that includes several major and disparate feature have to be so
complex to learn and start using, when just one of its features is
required?  Is there a better way to design such packages?  These are
the questions that should be the core of this discussion.

> It's very much like Emacs which if a new a user gives it a quick try 
> he will say it's strange looking editor with arcane keybindings and
> that's it.

As I said, RMS is not a new user of Emacs.  So that analogy is not
just wrong, it's misleading: it takes us in the wrong direction.  It
would be best to avoid it in this discussion, IMO.

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Scott Randby <srandby@gmail.com>
> Date: Fri, 1 Jul 2016 17:34:44 -0400
> 
> > Having just one example in a discussion doesn't constitute an attack
> > on that single example.
> 
> Again, what are other examples?

Why do we need more?  An idea can be explained using a single example.

> If Org is the only example, then what makes it different from all
> the other Emacs packages?

It includes several features that are very loosely coupled.  E.g.,
what does spreadsheet-like table have to do with outline-structured
notes?  What does the ability to embed source code in several
programming languages has to do with diary features?  Sure, we can
come up with use cases where it makes sense to use these features
together in the same file, but I think use cases where they are
unrelated are much more abundant.

> If there are more examples, then what is it they have in common so
> that a design philosophy can be developed that is universally
> useful?

An argument in a discussion doesn't have to move from examples to
their generalization.  It can do it the other way around: first state
a principle or an idea, and then illustrate it with a single example.
Both methodologies are valid and are widely used.

> I could spend all day being critical of Gnus, but I've never been able 
> to figure out how to use it so I don't have any legitimate reason to 
> present my uninformed opinion about it.

Once again, this is explicitly NOT about the user POV.  It is beyond
any argument that Org is a very successful package, as far as its
users are concerned.  So let's not bring this issue into this
discussion, it is not relevant here.

Btw, it might be relevant to point out that quite a few features
originally provided by Gnus were over the years refactored into
separate Emacs packages, and are nowadays available in general-purpose
subdirectories, like lisp/net, lisp/mail, and others.  Perhaps the
most prominent example is Message mode, which was several years ago
made the default Emacs mail composing mode.  This tendency continues
with Gnus to this day.  My interpretation of that is that Gnus, too,
had/has some features included that shouldn't have been there in the
first place _as_part_of_Gnus_.

> > Besides, I think the fact that Richard was turned off by Org so early
> > in his attempts to learn it should tell us something important.
> > Richard cannot be accused of being an Emacs outsider, or of not being
> > capable of learning complex Emacs stuff.
> 
> Yes, it says that Richard doesn't know how to use Org.

I think it tells us much more than that.

> > AFAIU, this discussion was meant for Emacs developers, not for Org
> > users/advocates.  The suggestion to think broadly was aimed at all of
> > us, not just for those who think Org was designed in the best way
> > possible.  Think broadly in this context means think about more than
> > just Org.
> 
> I'm sorry I said anything since I'm not an Emacs developer. But I never 
> claimed that Org was designed in the best way possible. Yes, I care more 
> about Org than other packages because I use Org for almost all of my 
> work, it is a fantastic tool. I'm just tired of these digs at Org from 
> people who don't use it.

As I said already several times, there's no "digging" here.  This is a
discussion about design principles of large Emacs packages.

> > AFAIU, Richard's comment was that the design principles were wrong,
> > not that the design itself was flawed.  The main design principle in
> > question is that of tight integration between unrelated parts of a
> > large package.
> 
> Though I'm not an Emacs or an Org developer, I have to disagree 
> slightly. The tight integration between pieces of Org is one of the 
> features that makes it so useful.

Well, here's where we disagree.  Tight integration of unrelated
features is not a good thing, IMO, since it makes learning each one
harder, and it makes maintenance more vulnerable to a loss of a single
central individual who knows all the ins and outs.

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 01 Jul 2016 18:09:35 -0400
> Cc: emacs-devel@gnu.org
> 
> If someone wanted features that Mail mode didn't have,
> the best way to add them to Emacs would have been to add them to Mail mode.
> The second best way to add them to Emacs,
> in case they did not fit into Mail mode,
> would have been to make an alternate mail-sending mode,
> as an independent feature.

As life would have it, we've already done this: Message mode, which
came from Gnus, is now the default mail-composing mode in Emacs.

> Being independent features doesn't mean they can't work together.
> Rmail and Mail mode are both independent features, but they work
> together through clean interfaces.

Indeed, Rmail now by default invokes message.el when you compose the
reply.

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

Hi all,

I come a little late to this discussion, but I can't help chiming in.

On 2016-06-29, at 16:34, Richard Stallman <rms@gnu.org> wrote:

> Because the various subfeatures of Org mode were designed inside Org mode,
> they turn Org mode into a separate editor within Emacs.

I find the above claim to be false.  It is like saying that python-mode
is a separate Python editor within Emacs.

An important reason for Org's success is that it works /in Emacs/.  All
of my customizations, keybindings, usage habits work across most of the
modes.  Org-mode is not an exception.

> It must be good to use, to have so many users.  But that's a different
> issue.  These submodes should be designed so that they individually
> fit into Emacs.

They do, don't they?  Another Org's strength is that you don't have to
use all of its features.

> Since I don't know Org mode, I don't know what you mean by this
> statement.  "The basis" has various possible meanings and I can't tell
> what you mean.
>
> The reason I don't know Org mode is that I'd have to start by learning
> basic Org mode, which I am not interested in, before I see what its
> specific features are.  At that point, I gave up.

Let me help you begin.

By typing a letter or other "normal ASCII character", you insert it.
You move point with arrow keys of C-b/C-f/C-n/C-p.
By pressing C-a and C-e, you get to the beginning/end of line.
By pressing DEL, you delete a character before point.
By pressing C-d, you delete a character after point.
By typing one or more asterisks followed by space at the beginning of
a line, you start a heading (like in vanilla Emacs' Outline mode).
By pressing TAB when point is on a headline, you cycle through various
possible visibility states.

Bam!  Now you know basic Org-mode.

You're welcome.

;-)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Sat, 02 Jul 2016 09:18:21 +0200
> Cc: emacs-devel@gnu.org, Eric S Fraga <e.fraga@ucl.ac.uk>
> 
> By typing a letter or other "normal ASCII character", you insert it.
> You move point with arrow keys of C-b/C-f/C-n/C-p.
> By pressing C-a and C-e, you get to the beginning/end of line.
> By pressing DEL, you delete a character before point.
> By pressing C-d, you delete a character after point.
> By typing one or more asterisks followed by space at the beginning of
> a line, you start a heading (like in vanilla Emacs' Outline mode).
> By pressing TAB when point is on a headline, you cycle through various
> possible visibility states.
> 
> Bam!  Now you know basic Org-mode.

Forgive me, but the above doesn't even begin to scratch the surface of
Org.  And you certainly know that.

Mocking your opponents is not an efficient method of convincing them.

Re: Differences between Org-Mode and Hyperbole

[Joost Kremers]

On Fri, Jul 01 2016, Eli Zaretskii wrote:
> I tried to give a few specific examples up-thread.

I had started a reply to that message but got side-tracked and never
finished it. The TL;DR is that there are aspects of Org that I suspect
can't really be separated out, there are aspects that probably could and
there are aspects that already are. (So the situation isn't as bad as
one might think after reading this thread.)

The longer version: exporting (your first example) would probably be
difficult to separate from Org mode. Although Org files are essentially
just plain text files, in order for the exporters to know which parts of
the text are headers, which are lists, which phrases need to be set in
italic or bold, etc. etc., the source file needs some markup, and this
markup happens to be Org's markup. (Personally, I would have preferred
something Markdown-based, but that's just me. Currently, it *is*
possible to change the visual appearance of markup elements in Org, so
you can define *text* to appear as italic instead of bold, but the
exporters ignore such configurations, unfortunately.)

In order to separate the exporters from the actual markup, you'd need
something similar to Pandoc[1], which has an internal
(markup-independent) representation of a document's structure and can
therefore translate X different markup languages into Y different markup
languages, but AFAIK Org doesn't have such an internal representation,
so the exporters need to rely on the markup itself.

For other parts of Org (I think you also mentioned Babel), it would
probably be easier to convert them into minor modes that aren't
dependent on Org (or on the file they're used with being an Org file).
In fact, this has already been done for at least one feature: table
editing. There's an orgtbl-mode that provides Org's table editing
facilities and that can be used outside of org-mode. (I use it
occasionally in Markdown files, for example). I think there's also
orgstruct-mode or something similar, a minor mode that provides Org's
structure handling in non-Org files (i.e., headers and lists).

The agenda (another example that came up here) is very much bound to Org
if only because the agenda information (appointments, deadlines, etc.
etc.) are stored in Org files. But that could of course be hidden from
the user entirely, if so desired.

In sum, although I know little about Org's internals, I guess it should
be possible to turn Org into a small base system containing the major
mode, combined with a number of minor modes that provide additional
functionality, which are not tied directly to org-mode itself. Such a
design might even benefit Org mode itself, because not every Org user
uses all features.

I haven't got a clue as to the amount of work that would be involved,
though, to turn Org into such a modular system.





Footnotes: 
[1]  http://www.pandoc.org

-- 
Joost Kremers
Life has its moments

Re: Differences between Org-Mode and Hyperbole

[Achim Gratz]

Eli Zaretskii writes:
> It [Org] includes several features that are very loosely coupled.

The coupling of these features is via Org the document format, not Org
the major mode.  This document format used to be whatever Org chose to
interpret some piece of text as, but is now more formally specified and
the implemented as a parser (org-element) in elisp.  There are probably
still parts of Org that work directly on the text, but they're on the
way out.

> E.g., what does spreadsheet-like table have to do with
> outline-structured notes?

That people writing an outline expect the ability to include tables
without needing to get out of the document they're editing?  That it's
vastly easier to maintain these tables when you can do the calculations
right there?  BTW, org-table uses Calc and there's enough of an API to
use it from outside Org if you wanted to.  In fact, if anybody really
wants to separate out something from Org, then the spreadsheet is a
pretty obvious candidate.  Keeping a separate spreadsheet working from
within Org will be a non-trivial exercise, though.

> What does the ability to embed source code in several programming
> languages has to do with diary features?

See above.  Again, these are provided by Org because that's what users
expect to do from within their Org documents.  It doesn't prescribe
implementation within Org.

> Sure, we can come up with use cases where it makes sense to use these
> features together in the same file, but I think use cases where they
> are unrelated are much more abundant.

Cases of using a computer that do not involve the Emacs are also
abundant, I hope you agree that this as not an argument against Emacs.

[…]
> Once again, this is explicitly NOT about the user POV.  It is beyond
> any argument that Org is a very successful package, as far as its
> users are concerned.  So let's not bring this issue into this
> discussion, it is not relevant here.

Then why do keep mentioning use cases and features, which are inherently
user-centric?  It should tell you something that you are unable to keep
the discussion going without resorting to user issues and indeed I think
you shouldn't be trying.  Emacs is about users getting things done first
and about Emacs developers spending their time efficiently second.

> Btw, it might be relevant to point out that quite a few features
> originally provided by Gnus were over the years refactored into
> separate Emacs packages, and are nowadays available in general-purpose
> subdirectories, like lisp/net, lisp/mail, and others.  Perhaps the
> most prominent example is Message mode, which was several years ago
> made the default Emacs mail composing mode.  This tendency continues
> with Gnus to this day.  My interpretation of that is that Gnus, too,
> had/has some features included that shouldn't have been there in the
> first place _as_part_of_Gnus_.

Hindsight is 20/20.  I could claim plausibly enough that separating
message out from GNUS from the outset would have stalled development of
both Gnus and message.  But in fact both these interpretations are
unprovable and of questionable utility to the future of different
packages already in Emacs like Org or new ones coming in like Hyperbole.

[…]
> As I said already several times, there's no "digging" here.  This is a
> discussion about design principles of large Emacs packages.

I've yet to see that discussion starting.  Emacs would need a way to
specify API, indicate various degrees to indicate whether they are
internal or external or how stable they can expected to be and backwards
compatibility to the public API of at least the immediately prior major
API version before the componentization of Emacs as alluded to in this
thread can take off on a larger scale.

> Well, here's where we disagree.  Tight integration of unrelated
> features is not a good thing, IMO, since it makes learning each one
> harder, and it makes maintenance more vulnerable to a loss of a single
> central individual who knows all the ins and outs.

More user POV, which you said was irrelevant.  Just because one file has
an "org-" prefix doesn't necessarily mean "tight integration" in the
design principles sense either.  I personally don't use the agenda for
instance and the fact that org-agenda.el exists is irrelevant to my
daily work.  Org doesn't care much either, it could just as well import
some Emacs facility in that same place if one was existing.  Despite
allusions to the contrary, org-agenda also doesn't replace existing
Emacs facilities, most of it is customization and UI, but the bulk work
is done via calendar.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Sat, 02 Jul 2016 11:00:14 +0200
> Cc: Scott Randby <srandby@gmail.com>, emacs-devel@gnu.org
> 
> exporting (your first example) would probably be
> difficult to separate from Org mode. Although Org files are essentially
> just plain text files, in order for the exporters to know which parts of
> the text are headers, which are lists, which phrases need to be set in
> italic or bold, etc. etc., the source file needs some markup, and this
> markup happens to be Org's markup.

At least in principle, the markup commands and what it inserts into
the buffer could be separate from the rest of Org.

> I haven't got a clue as to the amount of work that would be involved,
> though, to turn Org into such a modular system.

I'm not sure such a move is intended by this discussion.  I think this
discussion is more about the principles than about their practical
implications on Org specifically.

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 02 Jul 2016 11:13:50 +0200
> 
> Eli Zaretskii writes:
> > It [Org] includes several features that are very loosely coupled.
> 
> The coupling of these features is via Org the document format, not Org
> the major mode.

Yes, I know.  But the format requires one to use some minimum amount
of commands and customizations, before it becomes usable enough in
practical use cases.  And those are part of Org the mode.

> > E.g., what does spreadsheet-like table have to do with
> > outline-structured notes?
> 
> That people writing an outline expect the ability to include tables
> without needing to get out of the document they're editing?

Like I said, use cases where these are useful in the same document
clearly exist.  That's not the issue here.

> > What does the ability to embed source code in several programming
> > languages has to do with diary features?
> 
> See above.

See above.

> > Sure, we can come up with use cases where it makes sense to use these
> > features together in the same file, but I think use cases where they
> > are unrelated are much more abundant.
> 
> Cases of using a computer that do not involve the Emacs are also
> abundant, I hope you agree that this as not an argument against Emacs.

You are missing the point.  The point is how much of the basic
functionality one needs to master before they can use a single feature
of a large package.  If the answer for your Emacs analogy is "too
much", then it _is_ indeed an argument "against Emacs".

> > Btw, it might be relevant to point out that quite a few features
> > originally provided by Gnus were over the years refactored into
> > separate Emacs packages, and are nowadays available in general-purpose
> > subdirectories, like lisp/net, lisp/mail, and others.  Perhaps the
> > most prominent example is Message mode, which was several years ago
> > made the default Emacs mail composing mode.  This tendency continues
> > with Gnus to this day.  My interpretation of that is that Gnus, too,
> > had/has some features included that shouldn't have been there in the
> > first place _as_part_of_Gnus_.
> 
> Hindsight is 20/20.

We _are_ talking hindsight here.  This is not a discussion of whether
the Org designers made the right decisions when they made them.  This
is a discussion about whether _in_hindsight_ some alternative design
could have yielded a better result.

> > As I said already several times, there's no "digging" here.  This is a
> > discussion about design principles of large Emacs packages.
> 
> I've yet to see that discussion starting.

Sadly, I agree.

> > Well, here's where we disagree.  Tight integration of unrelated
> > features is not a good thing, IMO, since it makes learning each one
> > harder, and it makes maintenance more vulnerable to a loss of a single
> > central individual who knows all the ins and outs.
> 
> More user POV, which you said was irrelevant.

No, I did not.  What I did say that we need to look at this via
software designer's eyes, using the resulting user experience as the
test.

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> Date: Sat, 02 Jul 2016 13:07:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Achim Gratz <Stromeko@nexgo.de>
> > Date: Sat, 02 Jul 2016 11:13:50 +0200
> > > Sure, we can come up with use cases where it makes sense to use these
> > > features together in the same file, but I think use cases where they
> > > are unrelated are much more abundant.
> > 
> > Cases of using a computer that do not involve the Emacs are also
> > abundant, I hope you agree that this as not an argument against Emacs.
> 
> You are missing the point.  The point is how much of the basic
> functionality one needs to master before they can use a single feature
> of a large package.  If the answer for your Emacs analogy is "too
> much", then it _is_ indeed an argument "against Emacs".

Btw, while there might be a sufficient justification for having a high
entry bar into Emacs, having yet another high bar _inside_ Emacs for
using one of its features is an additional annoyance, and so not a
good thing.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The issue at hand is how to develop new features so that they extend
Emacs in a clean way that reduces the added difficulty of learning new
features.

You've explicitly said that you don't care about Emacs.  You care only
about Org mode.  It appears that you don't want Emacs to be easier for
users to learn.  However, that is our goal even if you don't support
it.  We will have to disregard your views.  We don't need to win you
over.  It appears you're not a major Emacs contributor; I don't see
your email address in the log.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Org is a complex package which cannot be appreciated
  > by just giving it a quick glance.

That is the problem that concerns me.

I am sure Org is very useful.  I know that because many people say
they like using it.  However, bundling together several conceptually
separate features makes it harder to start using any of them, and also
makes Emacs overall less clean.

If these various functionalities were carefully separated out, they
could still work together, and in combination they could be just as
useful as they are now.  And each one, separately, would be more
useful than it is now.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > By typing a letter or other "normal ASCII character", you insert it.
  > You move point with arrow keys of C-b/C-f/C-n/C-p.
  > By pressing C-a and C-e, you get to the beginning/end of line.
  > By pressing DEL, you delete a character before point.
  > By pressing C-d, you delete a character after point.

That is simply basic Emacs usage.

  > By typing one or more asterisks followed by space at the beginning of
  > a line, you start a heading (like in vanilla Emacs' Outline mode).
  > By pressing TAB when point is on a headline, you cycle through various
  > possible visibility states.

This feature seems to make sense, but I don't see that it does something
useful for me.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The second best way to add them to Emacs,
  > > in case they did not fit into Mail mode,
  > > would have been to make an alternate mail-sending mode,
  > > as an independent feature.

  > As life would have it, we've already done this: Message mode, which
  > came from Gnus, is now the default mail-composing mode in Emacs.

The crucial words are "as an independent feature".
message.el was not developed as an independent feature.
It was developed as a part of Gnus, and it was tied in with Gnus.

Is that still the case?  I think so.  The source code for message is
still in the gnus directory, and I think it is still maintained
outside Emacs along with Gnus.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Babel is a facility that lets a document author include pieces of code
  > in a document, which may be used either as their text ("Here is the code
  > I mean") or as their results. ("Here is the output of that code") or both.

Thanks.

It seems like a useful feature, though I don't know
if I personally have a use for it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Richard, I summarize your desire as "Org should be implemented so that
  > its features can be composed."

I don't entirely understand what you mean by "composed", or "can be
composed", but I think we are talking about different issues.

  >    I reply:  "Org is an attempt to
  > -perform- just that composition."

Now I am sure we are miscommunicating.

What I want is not composability, it's separation.  I would like the
various features of Org mode (or at least some of them) to be
conceptually separate, and documented separately.  If they also work
together, as they do now in Org mode, I would agree that's a plus.

The problem might be partly a matter of how Org mode is presented.
When I looked at its documentation, it started teaching me how to
enter structured text -- which I personally didn't need, so I decided
not to learn Org mode.

If Org mode does other things besides that, I might perhaps find them
worth learning if they were presented separately.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 07/02/2016 08:05 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The issue at hand is how to develop new features so that they extend
> Emacs in a clean way that reduces the added difficulty of learning new
> features.
>
> You've explicitly said that you don't care about Emacs.  You care only
> about Org mode.  It appears that you don't want Emacs to be easier for
> users to learn.  However, that is our goal even if you don't support
> it.  We will have to disregard your views.  We don't need to win you
> over.  It appears you're not a major Emacs contributor; I don't see
> your email address in the log.
>

I understand that my views are not so important since I am not an Emacs 
contributor, but please don't misrepresent what I've said on this 
thread. It is completely unfair of you to say that I explicitly claimed 
that I don't care about Emacs and that I care only for Org. I said no 
such thing, and you are 100% wrong in thinking I said such a thing. Here 
is what I said:

"Yes, I care more about Org than other packages because I use Org for 
almost all of my work, it is a fantastic tool."

Caring more for Org than other packages says nothing about how I care 
for Emacs (unless Emacs is a package of itself), it says nothing about 
the level of my regard for packages other than Org except that I care 
more for Org than them, and it says nothing about how I feel about 
making Emacs easier to use.

Since I am not an Emacs developer, I will cease to make comments on this 
list.

Scott Randby

Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 07/02/2016 08:05 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The issue at hand is how to develop new features so that they extend
> Emacs in a clean way that reduces the added difficulty of learning new
> features.
>
> You've explicitly said that you don't care about Emacs.  You care only
> about Org mode.  It appears that you don't want Emacs to be easier for
> users to learn.  However, that is our goal even if you don't support
> it.  We will have to disregard your views.  We don't need to win you
> over.  It appears you're not a major Emacs contributor; I don't see
> your email address in the log.
>

I must break the promise I made in my last post. For the record, I want 
to be clear about one final thing. Please forgive me for making an 
off-topic post.

I love Emacs and I use it to do almost all of my work. I have great 
appreciation for all the people who make Emacs the superb piece of 
software that it is. The key Emacs package for me is the amazing Org 
package. Org is the reason I use Emacs.

Finally, I completely support all efforts to make Emacs easier to use 
and I look forward to the results of those efforts. I know my views 
don't matter on this list, but I don't want anyone to think I'm opposed 
to Emacs.

No more irrelevant traffic from me will appear on this list.

Scott Randby

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Adding "TODO" to a
  > headline automatically gives you task management.

The usual Emacs way of selecting a command set for a specific job is
to specify a major mode.  Using a line that says "TODO" as to select a
command set seems inconsistent.  Why not make this a major mode?

Emacs already has a To-do mode, but if this one is better, it could
replace the old one.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

On Sun, Jul 3, 2016, 6:37 PM Richard Stallman <rms@gnu.org> wrote:

>
> The usual Emacs way of selecting a command set for a specific job is
> to specify a major mode.  Using a line that says "TODO" as to select a
> command set seems inconsistent.  Why not make this a major mode?
>

The beauty is that only that specific line has to contain the TODO
information. The whole buffer is not a TODO list. If you think along those
lines, org-mode has made it possible to have different major mode like
behaviors in the same buffer.

A single TODO headline could have the following:
- Different face for displaying and different export style based on the
headline level of that TODO line.
- Under those TODO headlines, you can have regular or check-list style
children TODO headlines.
- Some of those could have just regular paragraphs or
numbered/plain/definition lists or source blocks or quotation blocks or
..... which should behave in display/export as per the org mode convention.
- The TODO headlines can have a "property block" which can contain a wide
range of meta properties to be used during export, tangling, etc.
- They can have internal/external links, footnotes, etc.

This is barely skimming everything that one can have in a single headline
in the same org buffer. Unless we have a way in the core to support
multiple major modes in a single buffer, we cannot break out hundreds of
different properties that org mode applies on the same buffer into
individual major modes.

> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2110 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The beauty is that only that specific line has to contain the TODO
  > information.

In what sense is that beautiful?

I don't put a lot of effort, or a lot of text, into TODO lists that I
make.

  > The beauty is that only that specific line has to contain the TODO
  > information. The whole buffer is not a TODO list. If you think along those
  > lines, org-mode has made it possible to have different major mode like
  > behaviors in the same buffer.

If you want to keep a todo list in the same file as your code, and
have special editing commands, you'd want to be able to do that in any
kind of file, with any major mode.  Not only in files for which you
use Org mode.  In C files, and Lisp files, and LaTeX files, and HTML
files, and so on.

Correct me if I'm wrong, but I think Org mode doesn't do that.

So what we would want is a general package for having different major
modes in different parts of a buffer.  I believe there is at least one
such project under way.

  > - The TODO headlines can have a "property block" which can contain a wide
  > range of meta properties to be used during export, tangling, etc.

What does it mean to "export", and why would you want to do that to a
TODO list?  Why would it be important to put properties on parts
of a TODO list?

  > - Different face for displaying and different export style based on the
  > headline level of that TODO line.
  > - Under those TODO headlines, you can have regular or check-list style
  > children TODO headlines.
  > - Some of those could have just regular paragraphs or
  > numbered/plain/definition lists or source blocks or quotation blocks or
  > ..... which should behave in display/export as per the org mode convention.

  > - They can have internal/external links, footnotes, etc.

Why is it useful to do these fancy things for a TODO list?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Mon, Jul 4, 2016 at 5:20 PM, Richard Stallman <rms@gnu.org> wrote:

>
>   > - The TODO headlines can have a "property block" which can contain a
> wide
>   > range of meta properties to be used during export, tangling, etc.
>
> What does it mean to "export", and why would you want to do that to a
> TODO list?  Why would it be important to put properties on parts
> of a TODO list?
>

​Org mode is part markup language and some of this markup is used when
exporting org mode files into different formats like HTML and PDF for all
the reasons those formats are used by anyone, just like you would with a
Texinfo file.

Bob

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]

Re: Differences between Org-Mode and Hyperbole

[Phillip Lord]

On Mon, July 4, 2016 10:20 pm, Richard Stallman wrote:
>> The beauty is that only that specific line has to contain the TODO
>> information. The whole buffer is not a TODO list. If you think along
>> those lines, org-mode has made it possible to have different major mode
>> like behaviors in the same buffer.
>
> If you want to keep a todo list in the same file as your code, and
> have special editing commands, you'd want to be able to do that in any kind
> of file, with any major mode.  Not only in files for which you use Org
> mode.  In C files, and Lisp files, and LaTeX files, and HTML files, and so
> on.
>
> Correct me if I'm wrong, but I think Org mode doesn't do that.
>
>
> So what we would want is a general package for having different major
> modes in different parts of a buffer.  I believe there is at least one
> such project under way.

My own package (lentic) achieves this already although by a different
mechanism from having two major modes in one buffer -- rather it allows
two buffers to share related text. It allows use of org-mode TODO lists
(or any other org-mode markup) in lisp files (also, currently, lua, bash,
python). Or you can mix and match lisp and latex.



>> - The TODO headlines can have a "property block" which can contain a
>> wide range of meta properties to be used during export, tangling, etc.
>
> What does it mean to "export", and why would you want to do that to a
> TODO list?

So you can put it on the web. I think exporting is more useful for things
other than a TODO list though. This is the source code of lentic, for
example, turned into org-mode, then exported to HTML with skinned with an
info like javascript.

http://homepages.cs.ncl.ac.uk/phillip.lord/lentic/lenticular.html


>> - Different face for displaying and different export style based on the
>>  headline level of that TODO line. - Under those TODO headlines, you can
>> have regular or check-list style children TODO headlines. - Some of those
>> could have just regular paragraphs or numbered/plain/definition lists or
>> source blocks or quotation blocks or ..... which should behave in
>> display/export as per the org mode convention.
>
>> - They can have internal/external links, footnotes, etc.
>>
>
> Why is it useful to do these fancy things for a TODO list?

For all of these I cannot say (although it is useful to do these things
for other reasons). But checkboxes are great. Org counts how many you have
done as you check them off.

Phil

RE: Differences between Org-Mode and Hyperbole

[Drew Adams]

>   > The beauty is that only that specific line has to contain the TODO
>   > information. The whole buffer is not a TODO list. If you think along
>   > those lines, org-mode has made it possible to have different major
>   > mode like behaviors in the same buffer.
> 
> If you want to keep a todo list in the same file as your code, and
> have special editing commands, you'd want to be able to do that in any
> kind of file, with any major mode.  Not only in files for which you
> use Org mode.  In C files, and Lisp files, and LaTeX files, and HTML
> files, and so on.
> 
> Correct me if I'm wrong, but I think Org mode doesn't do that.
> 
> So what we would want is a general package for having different major
> modes in different parts of a buffer.  I believe there is at least one
> such project under way.

Not to get into the meat of this discussion about Org mode (which
seems already to have drifted from the subject of RMS's original
message), but here's a quick comment about TODO items.

Judging by the Org doc (http://orgmode.org/manual/TODO-Items.html):

  Org mode does not maintain TODO lists as separate documents.
  Instead, TODO items are an integral part of the notes file,
  because TODO items usually come up while taking notes!  With
  Org mode, simply mark any entry in a tree as being a TODO item.
  In this way, information is not duplicated, and the entire context
  from which the TODO item emerged is always present.

  Of course, this technique for managing TODO items scatters them
  throughout your notes file. Org mode compensates for this by
  providing methods to give you an overview of all the things that
  you have to do.

  * TODO basics: Marking and displaying TODO entries
  * TODO extensions: Workflow and assignments
  * Progress logging: Dates and notes for progress
  * Priorities: Some things are more important than others
  * Breaking down tasks: Splitting a task into manageable pieces
  * Checkboxes: Tick-off lists

Org mode thus lets you mark bits of a notes file as TODO items,
and it gives you easy ways to change their state, including their
progress and priorities.  It lets you easily split (and I presume
combine) items.  In this it is a bit like a workflow application.
It also apparently provides ways to filter and display TODO items.

The TODO items are bits of structured text - essentially markup.

I'll mention another approach that Emacs offers, for at least some
of this: bookmarks.  Not that bookmarks are specifically designed
for this, but they do offer you some similar features, with this
difference:

Bookmarks are saved separately from the file, so they do not require
(or take advantage of, out of the box) a particular text structure.

To get some of what is described for Org TODO items, Bookmark+ can
help.  The various bits of metadata that you can associate with a
TODO item - priority, class, dates, associated other items or other
TODO lists, etc. can be associated with a TODO-item bookmark using
Bookmark+ tags,which are a bit different from Org tags.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkTags

Bookmark tags are delicious-style: they are arbitrary strings (or
arbitrary strings associated with arbitrary Lisp values).  They
create, in effect, ad hoc sets of bookmarks, which you can use to
organize them.  It is easy to add, remove, and edit tags for a
bookmark, or for several bookmarks together.

(You can also create specialized types of bookmarks, in effect
associating any metadata you like in a way you define.)

A bookmark can also have an associated annotation, which with
Bookmark+ can be external: a separate file, a URL, or another
bookmark of metadata.  Or it can be internal: included as part
of the bookmark it annotates.  In Bookmark+, the default mode
for viewing and editing an annotation is Org-mode.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkAnnotations

There are various other possibilities for organizing and
displaying sets of bookmarks.

Bookmarks do not replace Org TODO features.  I don't think
that Org TODO or Org mode replaces a solid multiple-major-mode
feature (TBD) - or vice versa, for that matter.

Just wanted to point to bookmarks as a way to do some of the
same things without needing to use markup.  And yes of course,
there are uses for markup (or more generally, structured text)
that really do require a specific text structure (aka schema).

Re: Differences between Org-Mode and Hyperbole

[Etienne Prud'homme]

On Mon, 4 Jul 2016 22:33:42 +0100,
"Phillip Lord" <phillip.lord@russet.org.uk> wrote:

> So you can put it on the web. I think exporting is more useful for
> things other than a TODO list though. This is the source code of
> lentic, for example, turned into org-mode, then exported to HTML with
> skinned with an info like javascript.

Another important thing to note about org-mode is its flexibility to do
things. I just started using it one month ago and I can already see
what it could do.

For example, in my to-do list, I’ve got several projects that aren’t
related and I would like to keep them private. I also got several task
categories like documentation, implementation, testing, etc. Using
Org-mode, I can select a project and configure org-mode in a way that
it would generate a time report and a summary of my work. That report
could then be exported in a convenient file format and be given to my
client.

However, I can’t agree more with RMS that this mode is monolithic.
That’s a major problem. However, if we take CEDET as an example,
Org-mode components can’t work on their own given the complexity of
their relations. Could CEDET be refactored in ways that we could enjoy
many of its functions? Maybe, but that should be done on a case-by-case
basis.

Etienne Prud'homme

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> Date: Tue, 5 Jul 2016 09:11:01 -0400
> From: Etienne Prud'homme <e.e.f.prudhomme@gmail.com>
> 
> Could CEDET be refactored in ways that we could enjoy many of its
> functions? Maybe, but that should be done on a case-by-case basis.

With CEDET, this is already been done, and continues being done.  (I
wish we could do that more and more quickly, but at least we are under
way.)

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-02, at 10:18, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Sat, 02 Jul 2016 09:18:21 +0200
>> Cc: emacs-devel@gnu.org, Eric S Fraga <e.fraga@ucl.ac.uk>
>> 
>> By typing a letter or other "normal ASCII character", you insert it.
>> You move point with arrow keys of C-b/C-f/C-n/C-p.
>> By pressing C-a and C-e, you get to the beginning/end of line.
>> By pressing DEL, you delete a character before point.
>> By pressing C-d, you delete a character after point.
>> By typing one or more asterisks followed by space at the beginning of
>> a line, you start a heading (like in vanilla Emacs' Outline mode).
>> By pressing TAB when point is on a headline, you cycle through various
>> possible visibility states.
>> 
>> Bam!  Now you know basic Org-mode.
>
> Forgive me, but the above doesn't even begin to scratch the surface of
> Org.  And you certainly know that.

Of course it doesn't.  But this is what somebody might call "Basic
Org-mode".  My point was that you do not really need to "learn" basic
Org-mode too much.

> Mocking your opponents is not an efficient method of convincing them.

I'm not sure "mocking" is the right word here; if this looked so,
sorry.  I just could not resist the joke.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-03, at 02:06, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > By typing a letter or other "normal ASCII character", you insert it.
>   > You move point with arrow keys of C-b/C-f/C-n/C-p.
>   > By pressing C-a and C-e, you get to the beginning/end of line.
>   > By pressing DEL, you delete a character before point.
>   > By pressing C-d, you delete a character after point.
>
> That is simply basic Emacs usage.

That was my point!  (Or one of my points.)  That Org is built on top of
Emacs, it's not a "separate editor".

>   > By typing one or more asterisks followed by space at the beginning of
>   > a line, you start a heading (like in vanilla Emacs' Outline mode).
>   > By pressing TAB when point is on a headline, you cycle through various
>   > possible visibility states.
>
> This feature seems to make sense, but I don't see that it does something
> useful for me.

Well, it does something useful for a lot of people.  This is also
a point about Org: various people find various parts of Org useful.
I almost never run code embedded in Org files, for instance, but I use
clocking on a daily basis.  OTOH, I have yet to use effort estimates.
And so on.

On a more serious note, did anyone recommend Carsten Dominik's talk from
2008
(http://orgmode.org/worg/org-tutorials/org-screencasts/org-mode-google-tech-talk.html)?
Even though it's been ages ago, and Org acquired a lot of nice things
since then, I find it a good introduction to Org; also, it shows the
main motivation for Org's development.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-04, at 23:20, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > The beauty is that only that specific line has to contain the TODO
>   > information.
>
> In what sense is that beautiful?

You may keep many things in one file.

For instance, I prepare my blog entries in some Org file.  Each entry is
at the same time a TODO item, with todo keywords TODO, READY and DONE
("READY" means ready for publishing, "DONE" means published).  Each
entry has also a "LOGBOOK drawer", which is normally hidden, with
clocking (= time-tracking) information.  All in one place.  This is
beautiful.

>   > - The TODO headlines can have a "property block" which can contain a wide
>   > range of meta properties to be used during export, tangling, etc.
>
> What does it mean to "export", and why would you want to do that to a
> TODO list?  Why would it be important to put properties on parts
> of a TODO list?

Eg. convert them to LaTeX for printing on paper.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-04, at 23:20, Richard Stallman <rms@gnu.org> wrote:

> If you want to keep a todo list in the same file as your code, and
> have special editing commands, you'd want to be able to do that in any
> kind of file, with any major mode.  Not only in files for which you
> use Org mode.  In C files, and Lisp files, and LaTeX files, and HTML
> files, and so on.
>
> Correct me if I'm wrong, but I think Org mode doesn't do that.

Well, actually, it does (sort of).
http://orgmode.org/manual/Working-With-Source-Code.html

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Nikolaus Rath]

On Jul 04 2016, Kaushal Modi <kaushal.modi@gmail.com> wrote:
> On Sun, Jul 3, 2016, 6:37 PM Richard Stallman <rms@gnu.org> wrote:
>
>>
>> The usual Emacs way of selecting a command set for a specific job is
>> to specify a major mode.  Using a line that says "TODO" as to select a
>> command set seems inconsistent.  Why not make this a major mode?
>>
>
> The beauty is that only that specific line has to contain the TODO
> information.

In my opinion that's not beautiful, but a rather unfortunate
restriction. I'd rather be able to use several lines to specify one todo
item :-P.


Best,
-Niko
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-01, at 09:45, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Scott Randby <srandby@gmail.com>
>> Date: Thu, 30 Jun 2016 19:02:42 -0400
>> 
>> On 06/30/2016 01:58 PM, Richard Stallman wrote:
>> >    > This seems to be a major part of your issue with Org mode.  Could you
>> >    > explain in some detail what you mean specifically by having to learn
>> >    > basic Org mode before seeing what its features are?
>> >
>> > I don't remember -- it was years ago that I took a look at it
>> > and gave up.  I don't have time to revisit it now.
>> 
>> It is hard to take this criticism of Org seriously
>
> This discussion will be much more useful if people would not take it
> as an attack on Org.  In particular, the criticism is not about Org
> from POV of the end user, it's about its design principles.  IOW, the
> real subject of this discussion is how should we design large Emacs
> packages, and Org is just being used as an example, to have some
> context and some concrete instances of the abstract ideas.  See the
> beginning of the discussion.

Well said.  I agree that Org could be designed much better internally.
OTOH, I feel that the criticism might have been taken better if it had
been founded in at least rudimentary knowledge of Org.

> If people could stop being defensive about Org, and instead think more
> broadly, and perhaps bring some other examples into this discussion,
> we might actually reach some useful conclusions that could help us in
> the future.
>
> Please note that I am an Org user myself, albeit not a heavy user.
> When I need to make sense out of many tasks and manage them in a
> GTD-like manner, I use Org.  Some of the more serious tasks of my work
> on Emacs, such as the bidirectional display, were managed via Org.
>
> But using Org and being fond of it doesn't mean we cannot learn from
> its design for the future, and it doesn't mean we cannot decide that
> an alternative design could yield a more useful set of feature that
> would be easier to learn than what we have now.  It's a legitimate
> conclusion, and it doesn't in any way denigrate Org, because a package
> design isn't determined solely by its designers, it is determined by
> many other factors, like the available time and resources, on which no
> one has full control.  Therefore, saying that an alternative design
> could yield better results doesn't put any blame on those who worked
> on the package, and shouldn't put those people on the defensive.
>
>> The Org community is very open to suggestions for improvement. If anyone 
>> has specific suggestions for improvements to Org, instead of vague 
>> pronouncements about alleged failures, then please send them to the Org 
>> mailing list.

+1.

> This is exactly what this discussion is NOT about.  Org's design is a
> fait accompli, and no one in their right mind will come up with
> suggestions to redesign it.  Once again, this is not about some flaw
> in Org, it's about design principles of large Emacs packages.
>
>> it appears to me that perhaps incorporating Org into official Emacs
>> was the failure
>
> Now, this is uncalled-for, and factually incorrect.

Actually, I'd agree with that: Emacs release cycle is much longer than
Org's, and quite a few problems on Org's ML are results of mixing
included and installed versions of Org.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-03, at 02:05, Richard Stallman <rms@gnu.org> wrote:

> The issue at hand is how to develop new features so that they extend
> Emacs in a clean way that reduces the added difficulty of learning new
> features.

I do not understand this.  I had similar reservations at the beginning,
but then I actually tried and I found Org _very_ easy to learn.  One of
the guiding principles of Org is that you don't have to learn anything
you don't want to use (apart from the very basics, like the tree
structure of an Org file).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-02, at 12:07, Eli Zaretskii <eliz@gnu.org> wrote:

> You are missing the point.  The point is how much of the basic
> functionality one needs to master before they can use a single feature

As I said, in case of Org, next to none.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-03, at 02:05, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Org is a complex package which cannot be appreciated
>   > by just giving it a quick glance.
>
> That is the problem that concerns me.
>
> I am sure Org is very useful.  I know that because many people say
> they like using it.  However, bundling together several conceptually
> separate features makes it harder to start using any of them, and also
> makes Emacs overall less clean.
>
> If these various functionalities were carefully separated out, they
> could still work together, and in combination they could be just as
> useful as they are now.  And each one, separately, would be more
> useful than it is now.

I'll try to stop, but for the last time: they are not "bundled" from the
user's POV!!!  You really don't have to learn a lot to start being
productive with Org.  This is one of its main strengths.

OTOH, the design of Org is a different thing: there are quite a few huge
functions, and it happens sometimes that I need something for my
customizations, and I have to copy a half of some function, because
I can't easily hook into it.  The same can be said about AUCTeX (I know
because it happened to me, too), and probably a bunch of other packages,
including Emacs core itself.  (See e.g. the code of `mark-defun', which
is one big hack around buggy `beginning-of-defun'.)  So I agree that Org
could be made better.  Almost nobody actually wants to do it, I'm
afraid...  Adding new features (and even fixing bugs) is just more
fun/rewarding.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-02, at 11:00, Joost Kremers <joostkremers@fastmail.fm> wrote:

> In order to separate the exporters from the actual markup, you'd need
> something similar to Pandoc[1], which has an internal
> (markup-independent) representation of a document's structure and can
> therefore translate X different markup languages into Y different markup
> languages, but AFAIK Org doesn't have such an internal representation,
> so the exporters need to rely on the markup itself.

AFAIU, it does (I mean Nicolas' "new" exporter).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-02, at 00:09, Richard Stallman <rms@gnu.org> wrote:

>   > 2. The spreadsheet. Apparently table.el was either too complicated or
>   >    too limiting to be easily used. Probably what should have happened
>   >    here is that table.el should have been improved. There's no intrinsic
>   >    reason why the spreadsheet aspect of Org needs to rely on Org's
>   >    markup, or its major mode.
>
> This could be an instance of the problem I mean.  If the spreadsheet
> were a separate facility from Org mode, so that you could use either
> one without the other, that doesn't mean they could not work together
> well also.

Org spreadsheet can use values in headline's properties.  That _might_
be tricky to do if it were a separate mode.
>   > So one observation is, Org got where it is by taking some existing Emacs
>   > libraries, making them easier to use, and allowing them all to coexist
>   > in a single document.
>
> But it didn't make those things easier to use.  It replaced them --
> but not each one by one.  Rather, it replaced all of them with one
> complex combined thing.  That's what I see as a problem.

I'm not sure I agree.  Indeed, Org replaced the Outline mode with
something a lot better.  Most of other features of Org seem to me to be
something new.  (Agenda is similar to diary, but that's about it.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-01, at 22:53, Tom <adatgyujto@gmail.com> wrote:

> So if DRY was applied then org should already have internal api functions
> for markup access and manipulations, so the export part of the code 
> should in theory already be separated from the actual org text format,
> and it could also use some other backend implementation.

This is more or less how the "new" exporter works.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
> Date: Tue, 05 Jul 2016 20:07:02 +0200
> 
> 
> On 2016-07-02, at 12:07, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > You are missing the point.  The point is how much of the basic
> > functionality one needs to master before they can use a single feature
> 
> As I said, in case of Org, next to none.

That is false (I do use Org seriously).

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Tue, 05 Jul 2016 20:21:30 +0200
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
> 
> On 2016-07-02, at 00:09, Richard Stallman <rms@gnu.org> wrote:
> 
> >   > 2. The spreadsheet. Apparently table.el was either too complicated or
> >   >    too limiting to be easily used. Probably what should have happened
> >   >    here is that table.el should have been improved. There's no intrinsic
> >   >    reason why the spreadsheet aspect of Org needs to rely on Org's
> >   >    markup, or its major mode.
> >
> > This could be an instance of the problem I mean.  If the spreadsheet
> > were a separate facility from Org mode, so that you could use either
> > one without the other, that doesn't mean they could not work together
> > well also.
> 
> Org spreadsheet can use values in headline's properties.  That _might_
> be tricky to do if it were a separate mode.

Which, of course, flies in the face of your assertion that no previous
knowledge of Org is needed before its features can be used.

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-05, at 21:44, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Tue, 05 Jul 2016 20:21:30 +0200
>> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
>> 
>> On 2016-07-02, at 00:09, Richard Stallman <rms@gnu.org> wrote:
>> 
>> >   > 2. The spreadsheet. Apparently table.el was either too complicated or
>> >   >    too limiting to be easily used. Probably what should have happened
>> >   >    here is that table.el should have been improved. There's no intrinsic
>> >   >    reason why the spreadsheet aspect of Org needs to rely on Org's
>> >   >    markup, or its major mode.
>> >
>> > This could be an instance of the problem I mean.  If the spreadsheet
>> > were a separate facility from Org mode, so that you could use either
>> > one without the other, that doesn't mean they could not work together
>> > well also.
>> 
>> Org spreadsheet can use values in headline's properties.  That _might_
>> be tricky to do if it were a separate mode.
>
> Which, of course, flies in the face of your assertion that no previous
> knowledge of Org is needed before its features can be used.

How?  "Can" does not mean "must".  I used that feature exactly _once_,
and I even don't remember how to use it.  Yet, I use other features of
Org on a daily basis.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-05, at 21:41, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
>> Date: Tue, 05 Jul 2016 20:07:02 +0200
>> 
>> 
>> On 2016-07-02, at 12:07, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > You are missing the point.  The point is how much of the basic
>> > functionality one needs to master before they can use a single feature
>> 
>> As I said, in case of Org, next to none.
>
> That is false (I do use Org seriously).

No, it isn't.

In order to start to use outlining (one feature) you only need to know
how to mark up headlines (bol + stars + space + title) and how to use
TAB to cycle visibility.  Next is M-RET (or C-RET) and C-c C-p/C-c C-n.

Next feature - TODO items - you only need 

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[joakim]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   >   Adding "TODO" to a
>   > headline automatically gives you task management.
>
> The usual Emacs way of selecting a command set for a specific job is
> to specify a major mode.  Using a line that says "TODO" as to select a
> command set seems inconsistent.  Why not make this a major mode?
>
> Emacs already has a To-do mode, but if this one is better, it could
> replace the old one.

One way of viewing org, is that it is a document preparation system like
Latex. Or, a programming language. Or, a wiki like system.

The document preparation system org happens to have keywords like TODO
and so on.

Users of org, such as me, like to have all the features of the org
language available to us while we work on org files.

This does not contradict the opinion that the org language could in
someway be partitioned such that parts of it could be reused in other
contexts. Indeed, this is already the case for some of orgs features.
It might go some way to explain why there is no particular momentum to
implement such a language partitioning though. 


-- 
Joakim Verona

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ​Org mode is part markup language and some of this markup is used when
  > exporting org mode files into different formats like HTML and PDF for all
  > the reasons those formats are used by anyone, just like you would with a
  > Texinfo file.

Why would you want to convert a todo list into HTML or PDF?
I just don't see the utility.

I think that editing todo lists should be an orthogonal feature from
markup/export.  That way, you could use both features together in one
file (which is what you're thinking about), but you could also use
(and learn) just one of the features.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >  Using
  > Org-mode, I can select a project and configure org-mode in a way that
  > it would generate a time report and a summary of my work. That report
  > could then be exported in a convenient file format and be given to my
  > client.

Since projects generally have different files (or even different
directories), the usual Emacs way to handle this would be that if you
visit something in one project and look for the todo list, you get
that project's todo list.

That has the advantage that it requires no special knowledge or
configuration.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-06, at 00:59, Richard Stallman <rms@gnu.org> wrote:

>   > ​Org mode is part markup language and some of this markup is used when
>   > exporting org mode files into different formats like HTML and PDF for all
>   > the reasons those formats are used by anyone, just like you would with a
>   > Texinfo file.
>
> Why would you want to convert a todo list into HTML or PDF?
> I just don't see the utility.

I do this regularly (to PDF, not HTML) so that I can print it out with
LaTeX.

> I think that editing todo lists should be an orthogonal feature from
> markup/export.  That way, you could use both features together in one
> file (which is what you're thinking about), but you could also use
> (and learn) just one of the features.

You _can_ do it both ways.  You can use Org-mode for authoring (and
exporting to a variety of formats) knowing _nothing_ about managing TODO
lists in Org, and vice versa.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Nikolai Weibull]

On Wed, Jul 6, 2016 at 12:59 AM, Richard Stallman <rms@gnu.org> wrote:
>   > Org mode is part markup language and some of this markup is used when
>   > exporting org mode files into different formats like HTML and PDF for all
>   > the reasons those formats are used by anyone, just like you would with a
>   > Texinfo file.

> Why would you want to convert a todo list into HTML or PDF?
> I just don't see the utility.

To share it with others in paper form.

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Tuesday,  5 Jul 2016 at 22:59, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > ​Org mode is part markup language and some of this markup is used when
>   > exporting org mode files into different formats like HTML and PDF for all
>   > the reasons those formats are used by anyone, just like you would with a
>   > Texinfo file.
>
> Why would you want to convert a todo list into HTML or PDF?
> I just don't see the utility.

For distribution of project progress reports, minutes of meetings, ...

-- 
: Eric S Fraga, GnuPG: 0xFFFCF67D

Re: Differences between Org-Mode and Hyperbole

[Joost Kremers]

On Tue, Jul 05 2016, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   >  Using
>   > Org-mode, I can select a project and configure org-mode in a way that
>   > it would generate a time report and a summary of my work. That report
>   > could then be exported in a convenient file format and be given to my
>   > client.
>
> Since projects generally have different files (or even different
> directories), the usual Emacs way to handle this would be that if you
> visit something in one project and look for the todo list, you get
> that project's todo list.

To be fair, the OP (the attribution is missing, so I'm not sure who
you're responding to) was talking about a "time report and a summary of
[their] work", which is more than just the todo list.

> That has the advantage that it requires no special knowledge or
> configuration.

Yeah, but that's trivial, isn't it? I mean, I could (in fact, sometimes
do) keep an Org file in a project's directory with a todo list in it and
if I want to see the project's todo list, I just open that Org file.

Actually using the todo list effectively will require investing some
time in learing the mode itself, regardless of whether I use todo-mode
or org-mode.



-- 
Joost Kremers
Life has its moments

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-06, at 01:03, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   >  Using
>   > Org-mode, I can select a project and configure org-mode in a way that
>   > it would generate a time report and a summary of my work. That report
>   > could then be exported in a convenient file format and be given to my
>   > client.
>
> Since projects generally have different files (or even different
> directories), the usual Emacs way to handle this would be that if you
> visit something in one project and look for the todo list, you get
> that project's todo list.

With Org, it is simple to implement.  In fact, I coded something like
this some time ago, using file-local variables; switching to
directory-local variables or a similar device should be easy.

OTOH, an "Org way" (if there is something like that at all) could be
have e.g. many projects in one Org file, and have links to the projects'
directories.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: rms@gnu.org, eric@ericabrahamsen.net, emacs-devel@gnu.org
> Date: Tue, 05 Jul 2016 21:53:47 +0200
> 
> >> Org spreadsheet can use values in headline's properties.  That _might_
> >> be tricky to do if it were a separate mode.
> >
> > Which, of course, flies in the face of your assertion that no previous
> > knowledge of Org is needed before its features can be used.
> 
> How?  "Can" does not mean "must".

But once you do, you have to use Org-specific commands and features to
make that happen, instead of using standard Emacs features, like text
properties etc.  What's more, the file records these properties in
Org-specific manner.

> Yet, I use other features of Org on a daily basis.

Surely, much more than just C-f, C-b, and TAB?

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
> Date: Tue, 05 Jul 2016 21:57:16 +0200
> 
> >> On 2016-07-02, at 12:07, Eli Zaretskii <address@hidden> wrote:
> >> 
> >> > You are missing the point.  The point is how much of the basic
> >> > functionality one needs to master before they can use a single feature
> >> 
> >> As I said, in case of Org, next to none.
> >
> > That is false (I do use Org seriously).
> 
> No, it isn't.
> 
> In order to start to use outlining (one feature) you only need to know
> how to mark up headlines (bol + stars + space + title) and how to use
> TAB to cycle visibility.

If I need only outlining, I don't need Org, I can use the Outline
mode.  We are talking about features that are in Org and only in Org.

Come on, let's be serious in this discussion!

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-06, at 16:27, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
>> Date: Tue, 05 Jul 2016 21:57:16 +0200
>> 
>> >> On 2016-07-02, at 12:07, Eli Zaretskii <address@hidden> wrote:
>> >> 
>> >> > You are missing the point.  The point is how much of the basic
>> >> > functionality one needs to master before they can use a single feature
>> >> 
>> >> As I said, in case of Org, next to none.
>> >
>> > That is false (I do use Org seriously).
>> 
>> No, it isn't.
>> 
>> In order to start to use outlining (one feature) you only need to know
>> how to mark up headlines (bol + stars + space + title) and how to use
>> TAB to cycle visibility.
>
> If I need only outlining, I don't need Org, I can use the Outline
> mode.  We are talking about features that are in Org and only in Org.
>
> Come on, let's be serious in this discussion!

Sorry, Eli, but I can say the same.  Be serious.  As I wrote:

> I covered more than half a dozen extremely useful features

and you commented on _one_ of them.  And mentioning Outline mode in
a discussion on _ease of use_ as an alternative of Org is kind of
strange.  Compared to Org, Outline mode is almost unusable wrt
visibility cycling.  Yes, it has more capabilities, but it also has an
order of magnitude more commands to remember!

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-06, at 16:26, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: rms@gnu.org, eric@ericabrahamsen.net, emacs-devel@gnu.org
>> Date: Tue, 05 Jul 2016 21:53:47 +0200
>> 
>> >> Org spreadsheet can use values in headline's properties.  That _might_
>> >> be tricky to do if it were a separate mode.
>> >
>> > Which, of course, flies in the face of your assertion that no previous
>> > knowledge of Org is needed before its features can be used.
>> 
>> How?  "Can" does not mean "must".
>
> But once you do, you have to use Org-specific commands and features to
> make that happen, instead of using standard Emacs features, like text
> properties etc.  What's more, the file records these properties in
> Org-specific manner.

I do not understand this.  How could I use "standard Emacs features" in
order to use (Org-specific) headline properties in (Org-specific)
spreadsheet???  I don't see how I could use text properties for that -
AFAIK, they are something completely different.

>> Yet, I use other features of Org on a daily basis.
>
> Surely, much more than just C-f, C-b, and TAB?

Yes, I use quite a bunch of Org features, for instance clocking,
exporting, custom TODO keywords, agenda, links, capturing...  I've also
written some Elisp to interact with Org and enhance it for my use-cases.
And still there are a lot of features of Org I know next to nothing
about, both from the user's and from the programmer's POV.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
> Date: Wed, 06 Jul 2016 17:32:25 +0200
> 
> 
> On 2016-07-06, at 16:27, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Marcin Borkowski <mbork@mbork.pl>
> >> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
> >> Date: Tue, 05 Jul 2016 21:57:16 +0200
> >> 
> >> >> On 2016-07-02, at 12:07, Eli Zaretskii <address@hidden> wrote:
> >> >> 
> >> >> > You are missing the point.  The point is how much of the basic
> >> >> > functionality one needs to master before they can use a single feature
> >> >> 
> >> >> As I said, in case of Org, next to none.
> >> >
> >> > That is false (I do use Org seriously).
> >> 
> >> No, it isn't.
> >> 
> >> In order to start to use outlining (one feature) you only need to know
> >> how to mark up headlines (bol + stars + space + title) and how to use
> >> TAB to cycle visibility.
> >
> > If I need only outlining, I don't need Org, I can use the Outline
> > mode.  We are talking about features that are in Org and only in Org.
> >
> > Come on, let's be serious in this discussion!
> 
> Sorry, Eli, but I can say the same.  Be serious.  As I wrote:
> 
> > I covered more than half a dozen extremely useful features
> 
> and you commented on _one_ of them.  And mentioning Outline mode in
> a discussion on _ease of use_ as an alternative of Org is kind of
> strange.

It wasn't a discussion on ease of use.  Look back.  It was a
discussion of how much of the mode one needs to learn before one
becomes productive with one feature the mode provides.  You said: next
to none, and gave outlining as the example.  To which I responded that
outlining alone doesn't justify using Org at all, as there are simpler
alternatives.

> Compared to Org, Outline mode is almost unusable wrt visibility
> cycling.  Yes, it has more capabilities, but it also has an order of
> magnitude more commands to remember!

Remembering commands is not an issue when you use a mode frequently
enough, or infrequently enough.

Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski]

On 2016-07-06, at 17:42, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
>> Date: Wed, 06 Jul 2016 17:32:25 +0200
>> 
>> 
>> On 2016-07-06, at 16:27, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >> From: Marcin Borkowski <mbork@mbork.pl>
>> >> Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
>> >> Date: Tue, 05 Jul 2016 21:57:16 +0200
>> >> 
>> >> >> On 2016-07-02, at 12:07, Eli Zaretskii <address@hidden> wrote:
>> >> >> 
>> >> >> > You are missing the point.  The point is how much of the basic
>> >> >> > functionality one needs to master before they can use a single feature
>> >> >> 
>> >> >> As I said, in case of Org, next to none.
>> >> >
>> >> > That is false (I do use Org seriously).
>> >> 
>> >> No, it isn't.
>> >> 
>> >> In order to start to use outlining (one feature) you only need to know
>> >> how to mark up headlines (bol + stars + space + title) and how to use
>> >> TAB to cycle visibility.
>> >
>> > If I need only outlining, I don't need Org, I can use the Outline
>> > mode.  We are talking about features that are in Org and only in Org.
>> >
>> > Come on, let's be serious in this discussion!
>> 
>> Sorry, Eli, but I can say the same.  Be serious.  As I wrote:
>> 
>> > I covered more than half a dozen extremely useful features
>> 
>> and you commented on _one_ of them.  And mentioning Outline mode in
>> a discussion on _ease of use_ as an alternative of Org is kind of
>> strange.
>
> It wasn't a discussion on ease of use.  Look back.  It was a
> discussion of how much of the mode one needs to learn before one
> becomes productive with one feature the mode provides.  You said: next
> to none, and gave outlining as the example.  To which I responded that
> outlining alone doesn't justify using Org at all, as there are simpler
> alternatives.

Well, this discussion is like Org-mode itself: it is about many
things. ;-)

Still, I did not "gave outlining as an example": I gave outlining as
_one of eight examples_.  And you have yet to give an example a "simpler
alternative" to Org's outlining, since Outline mode is not one.  Indeed,
AFAIR, one of the first motivations for Org was that Outline mode had
a terrible UI.  See here: https://youtu.be/oJTwQvgfgMM?t=353 (3-4
minutes is enough to see what I mean).

>> Compared to Org, Outline mode is almost unusable wrt visibility
>> cycling.  Yes, it has more capabilities, but it also has an order of
>> magnitude more commands to remember!
>
> Remembering commands is not an issue when you use a mode frequently
> enough, or infrequently enough.

But introducing something like 6 or 8 commands where one is enough is
grossly inefficient, both for the user's (muscle) memory and for the
limited set of convenient keybindings.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For instance, I prepare my blog entries in some Org file.  Each entry is
  > at the same time a TODO item, with todo keywords TODO, READY and DONE
  > ("READY" means ready for publishing, "DONE" means published).  Each
  > entry has also a "LOGBOOK drawer", which is normally hidden, with
  > clocking (= time-tracking) information.  All in one place.  This is
  > beautiful.

It doesn't seem like a natural approach for me.
I'm glad it is useful for you.

Printing a todo list seems like a strange and unusual thing to want to
do.  I expect few Emacs users will want to do that.  So I'd rather
offer a todo mode which can be described in a self-contained way
and doesn't talk about embedding or exporting.

This doesn't mean it shouldn't allow embedding and exporting.  There's
no harm if it supports those, for the sake of users like you that want
to use those features together.  But users thinking of using a todo
mode shouldn't have to learn about those other things.

Is it possible to make a todo mode variant of Org mode, and document
that in a way that mentions only the features of basic todo list
editing?  (No mention of exporting or Babyl.)

In other words, it would not tell users, "Here's one of the great
things you can do with Org mode" but rather "Here's how to edit Todo
lists"?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'll try to stop, but for the last time: they are not "bundled" from the
  > user's POV!!!

Yes they are bundled from a user's point of view.
They are documented as a single bundle called "Org mode"
which can do many different things.

They are also bundled in implementation, and the code would
be clearer if they were separated in a modular way.

These are two different problems.  Perhaps a single redesign
could fix them both.

  > > This feature seems to make sense, but I don't see that it does something
  > > useful for me.

  > Well, it does something useful for a lot of people.

I am sure that is true, but that is not the issue.

When I said

  > This feature seems to make sense, but I don't see that it does something
  > useful for me.

I said it in the context of a particular argument.  You said

  > >   > By typing one or more asterisks followed by space at the beginning of
  > >   > a line, you start a heading (like in vanilla Emacs' Outline mode).
  > >   > By pressing TAB when point is on a headline, you cycle through various
  > >   > possible visibility states.

and I responded that this is not useful for me.

You seemed to take that as an attempt to prove that "Org mode is not
useful", but that's not what I am arguing for.  We are failing to
communicate.  Perhaps you think I am arguing that "Org mode is no
good."

However, my conclusion is something else.

This outline visibility feature seems to be the basic feature of Org
mode.  When I read about how to use Org mode, I saw things I wasn't
interested in, followed by more things I wasn't interested in.

After a while I got tired of spending time on it, so I didn't
read any more, and didn't try to actually use Org mode.

If there are other features in Org mode which I might find useful, I
didn't learn how to use them, because I had given up on reading
before I got to them.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That was my point!  (Or one of my points.)  That Org is built on top of
  > Emacs, it's not a "separate editor".

I agree, it is not a "separate editor".  I don't think I said it was.
What I say is that it is a bundle of various features that ought to be
separate (and be able to work together).

  > > This feature seems to make sense, but I don't see that it does something
  > > useful for me.

I never said Org mode was not useful (for other people).  That is not
the question.  You are defending something that I never attacked.

When I said

  > This feature seems to make sense, but I don't see that it does something
  > useful for me.

I said it in the context of a particular argument.  You said

  > >   > By typing one or more asterisks followed by space at the beginning of
  > >   > a line, you start a heading (like in vanilla Emacs' Outline mode).
  > >   > By pressing TAB when point is on a headline, you cycle through various
  > >   > possible visibility states.

and I responded that this is not useful for me.

This seems to be the basic feature of Org mode.  When I read about how
to use Org mode, I saw something that I didn't want to use.

At that point, I gave up reading about it.  If there are other
features in Org mode, which I might find useful, I didn't get that far.

  > I do not understand this.  I had similar reservations at the beginning,
  > but then I actually tried and I found Org _very_ easy to learn.

Apparently you _wanted_ to learn Org mode.  Perhaps you saw that it
did something that seemed useful to you.

That didn't happen for me.  The documentation for Org mode presented a
lot of things that I didn't even want to read about, let alone try to
learn.  So I gave up on it.

								     One of
  > the guiding principles of Org is that you don't have to learn anything
  > you don't want to use (apart from the very basics, like the tree
  > structure of an Org file).

That may be true, but it doesn't address this issue.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > One way of viewing org, is that it is a document preparation system like
  > Latex. Or, a programming language. Or, a wiki like system.

That's exactly the problem: Org mode's purpose is not conceptually
coherent.

If it were separated into different facilities, each one with a simple
purpose, and _each facility documented separately_, this particular
problem would be gone.

  > Users of org, such as me, like to have all the features of the org
  > language available to us while we work on org files.

If they were different facilities, each facility with a simple purpose
and each documented separately, they could still work together, so you
would still have all these facilities available for a certain file
when that's what you want.

We wouldn't think of that as an "Org file".  We would think of it as
a file in which you are using features A, B and C together.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think that editing todo lists should be an orthogonal feature from
  > > markup/export.  That way, you could use both features together in one
  > > file (which is what you're thinking about), but you could also use
  > > (and learn) just one of the features.

  > You _can_ do it both ways.  You can use Org-mode for authoring (and
  > exporting to a variety of formats) knowing _nothing_ about managing TODO
  > lists in Org, and vice versa.

We are totally miscommunicating.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Why would you want to convert a todo list into HTML or PDF?
  > > I just don't see the utility.

  > To share it with others in paper form.

I have never wanted to do that with my todo lists.
I just don't see the utility of doing it.

If you find it useful, by all means do it.
I am not arguing that you shouldn't be able to do this,
or that Emacs shouldn't facilitate it.
If you are trying to argue with me about that, you're missing the point.

Rather, I am an example of many users (I'm sure we are many) who don't
want to print out our todo lists, and the point is this: with us,
building a mode for editing todo lists on top of something for
printing out formatted files is unnatural.

I think the todo editing features should be presented as someting
simple and self-contained.

If they also work with structured editing designed for export, I see
nothing wrong with that.  But they should not be presented to users
as something based on the structured editing for export.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Nikolai Weibull]

> On Jul 7, 2016, at 00:30, Richard Stallman <rms@gnu.org> wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>>> Why would you want to convert a todo list into HTML or PDF?
>>> I just don't see the utility.
> 
>> To share it with others in paper form.
> 
> I have never wanted to do that with my todo lists.
> I just don't see the utility of doing it.

In my work, I’be been asked to report on progress and to have something to show and further discussion, I’ve used printouts of org buffers. In all honesty, this could have been done with equal effect as a text file. I wasn’t arguing for or against anything, just stating an “accidental” use case. 

> If you find it useful, by all means do it.
> I am not arguing that you shouldn't be able to do this,
> or that Emacs shouldn't facilitate it.
> If you are trying to argue with me about that, you're missing the point.

I am not.

> Rather, I am an example of many users (I'm sure we are many) who don't
> want to print out our todo lists, and the point is this: with us,
> building a mode for editing todo lists on top of something for
> printing out formatted files is unnatural.

Unnatural is hardly the right choice of word. 

> I think the todo editing features should be presented as someting
> simple and self-contained.

I agree. Org mode is far too many things at once and it’s very difficult to get a grip on what everything it includes is useful for. As an example, there are (as far as I am aware, there may be more) eight ways of categorizing “items” (“to dos”) in Org mode. File, heading, category, todo state, tags, and priority, and also sub-items and check lists. This gives the user great freedom in how they organize their tasks, at a rather large cost of making it hard for even a seasoned user to figure out a good workflow. And that’s just categorization. Then there’s all the different ways of filtering your items and the agenda and all its various concepts to actually manage the chaos (which doesn’t work very well, at least for me). I would very much appreciate something simpler, but at least I can get org mode to do most of what I currently know that I want it to do. 

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That has the advantage that it requires no special knowledge or
  > > configuration.

  > Yeah, but that's trivial, isn't it? I mean, I could (in fact, sometimes
  > do) keep an Org file in a project's directory with a todo list in it and
  > if I want to see the project's todo list, I just open that Org file.

I said that in the context of explaining a particular point.  Your
response has nothing to do with that point -- in effect, it changes
the subject.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For distribution of project progress reports, minutes of meetings, ...

I don't think that most developers will want to format their progress
reports, let alone and print them.  If you want to do these things,
I'm glad Emacs makes it easier for you.  But that should be presented
as an advanced feature.

What we tell users now is

  Here's a system for formatting and printing things.
    By the way, it's good for editing your todo lists
    (and you can then format and print them, if you wish).

What we should tell them is

  Here's a system for formatting and printing things.

  Here's a system for editing your todo lists.
    (By the way, you can then format and print them, if you wish).

It could be the same set of features, and more or less the same
commands, but presented differently.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It is very difficult to have a conversation with you, because you
frequently take a point out of context and respond in a way
that isn't relevant to the issue at hand.

For instance, I wrote

    > If you want to keep a todo list in the same file as your code, and
    > have special editing commands, you'd want to be able to do that in any
    > kind of file, with any major mode.  Not only in files for which you
    > use Org mode.  In C files, and Lisp files, and LaTeX files, and HTML
    > files, and so on.

You said, 

  > Well, actually, it does (sort of).
  > http://orgmode.org/manual/Working-With-Source-Code.html

but that is actually something very different.  It talks about
including pieces of source code in an Org file:

    Source code can be included in Org mode documents using a ‘src’ block

That is not the same thing, and it isn't a response to my point.

It seems as if you were a PR agent for the Org Mode Inc, aiming to
convince as many people as possible that "Org mode is awesome"
and never mind the issue at hand.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[Eric S Fraga]

On Thursday,  7 Jul 2016 at 21:54, Richard Stallman wrote:
>   > For distribution of project progress reports, minutes of meetings, ...
>
> I don't think that most developers will want to format their progress
> reports, let alone and print them.

Well, I guess this depends on what you label as developers and/or
whether it is just developers you are concerned with.  I manage projects
which consist of coordinating teams of researchers, developing
proposals, writing code, writing articles, holding meetings, writing
progress reports, etc.  org helps tremendously in keeping track of all
of these things.  I tend to have one org file for any given project.

> What we tell users now is
>
>   Here's a system for formatting and printing things.
>     By the way, it's good for editing your todo lists
>     (and you can then format and print them, if you wish).
>
> What we should tell them is
>
>   Here's a system for formatting and printing things.
>
>   Here's a system for editing your todo lists.
>     (By the way, you can then format and print them, if you wish).
>
> It could be the same set of features, and more or less the same
> commands, but presented differently.

Fine.  Maybe it's all about presentation then.  I don't see any conflict
between org and emacs generally.  But, then again, I use evil ;-)

For me, the key is that I can work on all project related aspects in one
document for each project.  YMMV, of course.

-- 
: Eric S Fraga, GnuPG: 0xFFFCF67D

Re: Differences between Org-Mode and Hyperbole

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, I guess this depends on what you label as developers and/or
  > whether it is just developers you are concerned with.  I manage projects
  > which consist of coordinating teams of researchers, developing
  > proposals, writing code, writing articles, holding meetings, writing
  > progress reports, etc.  org helps tremendously in keeping track of all
  > of these things.  I tend to have one org file for any given project.

That seems like a very high-power form of usage.
I think the fraction of users who would do things like this
must be rather small.

It is good for Emacs to support your high-power usage,
but the way we document these features for users should
show present the TODO feature in a simple way
aimed first of all at more basic users.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Differences between Org-Mode and Hyperbole

[chad brown]

> On 09 Jul 2016, at 09:56, Richard Stallman <rms@gnu.org> wrote:
> […]
> That seems like a very high-power form of usage.
> I think the fraction of users who would do things like this
> must be rather small.


Org is primarily a system for taking and managing notes in Emacs
(especially but not exclusively structured notes like task lists and
instruction steps). People use it for outlines (from whence it was
born), but also for research notes, papers, and books, among other
things.

Over the years, it has grown extra support for things like exporting
to various presentation formats like PDF, print, and the web; for
including marked-up, live, and/or runnable “chunks” of types other
than plain text (live-calculating tables, runnable code examples,
live-computed graphs from external sources); and for importing (called
“capturing”) bits from external sources like web browsers and PDFs.
Each of these extra pieces was added to address a desire to manage
more things using Emacs.

I do understand that looking at a (long!) list of org-related
packages, or looking at a (similarly long) list of org-related
features, it does seem like (for example) many of those importing or
exporting features could have been general Emacs features instead of
org-specific features. In some of those cases, this is almost
certainly true, but the practice is a bit more nuanced, because
usually those org features are glue between existing Emacs features
and the org structure that makes it easy for everything to work
together inside org (and also work inside Emacs without org).

Put another way: there are many parts of Emacs (outside org) that let
one use Emacs to interface with other parts of the world (both import
and export). Org provides a way to put *those* parts together, in a
manner that is both (relatively) simple and coherent.

*I believe* this is why there’s so much misunderstanding on this
topic: while it’s undoubtedly true that the software design of org
could be improved in hindsight, it’s very hard for the people deeply
involved in the org parts to see how the “glue that lets you combine
many disparate parts into one unifying structured approach” could
(much less “should”) have been designed as separate parts.

I hope that helps,
~Chad

Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: chad brown <chadpbrown@gmail.com>
> Date: Sat, 9 Jul 2016 23:47:37 -0700
> 
> I do understand that looking at a (long!) list of org-related
> packages, or looking at a (similarly long) list of org-related
> features, it does seem like (for example) many of those importing or
> exporting features could have been general Emacs features instead of
> org-specific features. In some of those cases, this is almost
> certainly true, but the practice is a bit more nuanced, because
> usually those org features are glue between existing Emacs features
> and the org structure that makes it easy for everything to work
> together inside org (and also work inside Emacs without org).

The point I believe Richard is trying to make is that such features
should have been designed and implemented differently, in a way that
they could be used outside of "Org the note-managing system", and then
integrated into Org.

> Put another way: there are many parts of Emacs (outside org) that let
> one use Emacs to interface with other parts of the world (both import
> and export). Org provides a way to put *those* parts together, in a
> manner that is both (relatively) simple and coherent.

I believe the main issue at hand is with those parts of Org that have
no other implementation except as part of Org, and which rely on Org
infrastructure for their operation.

> *I believe* this is why there’s so much misunderstanding on this
> topic: while it’s undoubtedly true that the software design of org
> could be improved in hindsight, it’s very hard for the people deeply
> involved in the org parts to see how the “glue that lets you combine
> many disparate parts into one unifying structured approach” could
> (much less “should”) have been designed as separate parts.

To give you a trivial example, think about font-lock.  Its design
allows both Org and any other major mode to do its specialized job of
fontifying the buffer.  The infrastructure on which font-lock is based
is not tied up to any particular mode, but instead is based on general
principles, such as the concept of "syntax", which has concrete (and
different) expression with each mode.

Why couldn't, for example, the "code blocks" feature offered by Org be
designed along the same principles?

Likewise with exports: the feature could be built around a set of
abstract principle, concepts, and APIs, and then each mode could
instantiate and customize those according to what it needs.