emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Differences between Org-Mode and Hyperbole


From: Eli Zaretskii
Subject: Re: Differences between Org-Mode and Hyperbole
Date: Sat, 02 Jul 2016 10:05:15 +0300

> Cc: address@hidden
> From: Scott Randby <address@hidden>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]