[Top][All Lists]

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

[ELPA] New package: GNU Hyperbole 6.0

From: Mats Lidell
Subject: [ELPA] New package: GNU Hyperbole 6.0
Date: Sat, 16 Jul 2016 01:45:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)


I'm the maintainer of GNU Hyperbole together with its original author Bob
Weiner. Active development of the package has started again thanks to Bob
putting in lot of time and energy in the project.  We would now like the soon
upcoming release to be added to ELPA.

This is a short description of what Hyperbole is. (Top of the HY-ABOUT file
included below.)
GNU Hyperbole (pronounced Ga-new Hi-per-bo-lee), or just Hyperbole, is
an open, efficient, and programmable hypertextual information
management and hypertext system implemented as a GNU Emacs package.
It works well on GNU Emacs 24.3 or above.

It includes easy-to-use, powerful hypertextual button types without
the need to learn a markup language; a hierarchical, record-based
contact manager; a rapid window and frame control system; and a
powerful multi-level auto-numbered outliner.  All features are aimed
at making textual information management and display fast and easy.

Hyperbole allows hypertext buttons to be embedded within unstructured
and structured files, mail messages and news articles.  It offers
intuitive keyboard and mouse-based control of information display
within multiple windows.  It also provides point-and-click access to
World-Wide Web URLs, Info manuals, ftp archives, etc.

The Hyperbole wiki page, "https://www.emacswiki.org/emacs/Hyperbole";,
explains the many ways it differs from and is complementary to Org mode.


The package has been maintained at


There is more info about the package there but that has not been updated yet
with the latest release. This is partly due to questions about what the best
way is to do the packaging and if that puts requirements on where and how to
maintain it.

The plan now is to continue to maintain it at savannah and include it in ELPA
as a subtree. The package is rather big so we think it would be wise to keep
the daily development outside of ELPA and only sync when doing releases.

What do you think? I that the right approach?

Since we don't have push rights to the ELPA repository we would need that. Or
for a speedier handling maybe someone with those rights already can help us,
if only initially, to get the first release out?

The technical details - that the package follows the right conventions etc is
best inspected when we have it uploaded to the repo at savannah I think. Could
that be an acceptable plan? 

Yours Mats

reply via email to

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