Introducing e4r, a Script to Make Vim Useless

As some of you may be aware, there exist a few dark heretics who have yet to embrace the One True Editor and instead go around peddling their evil ways (via m-x peddle-evil-ways) or their primitive superstitions (yes, ^O to save makes perfect sense!).

Although Exherbo would ordinarily go out of its way to smite those wicked sinners, unfortunately it seems that some of them are so set in their ways that even removing their satanic instruments from the basic install will not quell their iniquity. Thus, in a rare and display of compromise that risks turning Exherbo into… uh, no, wait, I can’t think of any distributions capable of sensible compromises. Anyway:

e4r is a small script that turns Vim into a very crude, minimally functional non-modal editor that approximately resembles Nano. It has no dependencies other than Vim, and is extremely tiny, making it practical to include it in stages for people whose time isn’t valuable enough for them to learn how to use an effective text editor.

Some screenshots:

Editing a file using e4r

Loading a file with e4r

e4r Help Menu

Git format-patches welcome.

What’s Not in EAPI 3?

I’ve already covered everything that made it into EAPI 3; for those interested, I’ll briefly discuss some of the things that were voted out or didn’t make it.

First, things that made it into the draft proposal, but were voted out:

• A ban on || ( use? ( foo ) ). This construct is impossible to use correctly (despite misinformation to the contrary from certain people who keep trying very hard to come up with a perverse justification for it), is used incorrectly everywhere it is currently used and has lots of special wording for it in PMS. Unfortunately, the Council weaselled out of outright banning it in favour of maybe introducing a repoman check and maybe banning it later.
• doexample and doinclude. Nobody cared enough to make a convincing defence of their necessity, so they were voted out.
• More econf option changes. --enable-fast-install was snuck into the --disable-dependency-tracking feature request with no explanation. The Council voted against it.
• unpack --if-compressed, which would make it otherwise fatal for unpack to be called with an unsupported extension, was voted out. This means that when you explicitly call unpack doesnotexist or unpack foo.tar.bz3, unpack will continue to do nothing silently and not indicate any error.

Then, things that were getting ready before the Council decided that in the interests of getting things done, anything not already on the list would be postponed for consideration for a future EAPI:

• Merger mtime preservation. This one, as worded, received much objection from the secret cabal directing Gentoo’s future from the shadows since it would mandate emulating Portage’s broken behaviour that results in files being merged with ridiculous timestamps.
• Prefix variables. The Gentoo prefix people wanted to sneak a few prefix variables into PMS by the back door, presumably in a way of getting prefix accepted without them having to discuss or address design, goals or implementation — this discussion getting postponed is probably good for Gentoo, since it’s well known that anyone who dares suggest that prefix is anything less than perfect ends up mysteriously no longer being a Gentoo developer.

EAPI 3: Utilities Die, and New nonfatal Utility

This is part of a series on EAPI 3.

With older EAPIs, econf (being a shell function) would die on failure, as do most eclass-provided functions, but emake (being an external, since people call it via xargs) and most package-manager-provided utilities (external or not) merely return non-zero.

In EAPI 3, most utilities (consult PMS for exact details) will now die when an error is encountered. This in turn means the package manager has to be able to die from an external utility.

Occasionally, this isn’t desired behaviour. You might need to call a function, but do something else if it fails rather than aborting. In this case, use the nonfatal utility with the command to run as its arguments. Mostly this is just used to give better error messages, but there are sometimes other cases:

nonfatal emake plugins || die "Making plugins failed. Do you need to frozbinate your zorgons?"

# these usually exist, but sometimes don't, and we're too lazy to check manually
nonfatal dodoc foo bar baz

This feature originated with exheres-0.

EAPI 3: No More RDEPEND=DEPEND

This is part of a series on EAPI 3.

With EAPI 3, the much-hated and overly complicated RDEPEND from DEPEND automagic assignment (along with its highly weird rules for eclasses, which no-one ever remembers) is dead. Developers should set DEPEND and RDEPEND explicitly, and if any sharing is required, a (non-package-manager-handled) COMMON_DEPEND variable of some kind can be used.

EAPI 3: S to WORKDIR Fallback Reduced

This is part of a series on EAPI 3.

The introduction of a default src_install has one weird side effect that probably wouldn’t have been noticed before EAPI 3’s release without extensive use in Exherbo: if S is incorrect, developers will often end up accidentally installing an empty package rather than seeing the expected error. This is because the S to WORKDIR fallback happens even when it probably shouldn’t; with developers often no longer coding a src_install that will die if the expected Makefile isn’t found, this gets through unnoticed until it’s too late.

EAPI 3 therefore removes the S to WORKDIR fallback, except under certain carefully chosen circumstances: if the ebuild has empty A, and it defines none of src_unpack, src_prepare, src_configure, src_compile and src_install, the fallback will occur as normal.

Thus, ebuilds that install nothing don’t have worry; other ebuilds must set S=${WORKDIR} in global scope if necessary.

EAPI 3: AA, KV Gone; New REPLACING_VERSIONS and REPLACED_BY_VERSION Variables

This is part of a series on EAPI 3.

First, two removals: AA and KV. AA has been deprecated for ages, and isn’t useful for ebuilds — it’s like A, but contains every component, even those in unselected conditional branches. KV, meanwhile, contains “the kernel version”. Ebuilds that need that kind of thing should use one of the eclasses that provides similar but more useful functionality instead.

Now the more interesting part: two additions. In the good old days, you could use convoluted has_version magic in pkg_ phases to work out whether we’re in an upgrade, downgrade, reinstall or fresh install. The devmanual used to contain examples. Unfortunately, Zac went and broke all this when he changed phase ordering without an EAPI bump, leaving all the widely used and documented techniques for detecting upgrades unusable. Thus, EAPI 3 adds two new variables to fix this mess.

The REPLACING_VERSIONS variable contains a space separated list of all the versions of the current package name that will be replaced. It is only valid in pkg_preinst and pkg_postinst; if set during pkg_pretend and pkg_setup, it will contain valid values, but it may be misleading in the case of binary package building.

Note that REPLACING_VERSIONS is a list, not a single value. This is to deal with weird cases like having foo-1:2 and foo-2:1 installed, and installing foo-1:1.

The REPLACED_BY_VERSION variable contains the version of the current package name that has been replaced. It is only valid in pkg_prerm and pkg_postrm. If it is unset, it indicates a simple uninstall.