Package Details: textadept 9.4-1

Git Clone URL: (read-only)
Package Base: textadept
Description: A fast, minimalist, and remarkably extensible cross-platform text editor
Upstream URL:
Keywords: editor lua
Licenses: MIT
Conflicts: textadept-bin
Provides: textadept
Replaces: textadept-bin
Submitter: bitwave
Maintainer: reztho
Last Packager: reztho
Votes: 21
Popularity: 0.327316
First Submitted: 2015-09-04 11:30
Last Updated: 2017-06-10 23:35

Latest Comments

lastweakness commented on 2017-06-08 23:40

9.4 has been out for some time now.

sleepywitti commented on 2016-10-05 12:13

Just small addition: `hg config -e` always opens $HOME/.hgrc for editing and ignores $HGRCPATH if set. But Mercurial itself will ignore $HOME/.hgrc if $HGRCPATH is set. So make sure to open the right hgrc file.

reztho commented on 2016-10-03 18:14

fusion809, it's explained inside the PKGBUILD:

,line 19 onward.

But here's the text anyway:
"If textadept can't be compiled try the following things in this order:

- Run: hg config -e , and then add these lines:
[hostsecurity] = tls1.0

- Run makepkg with the -C argument"

fusion809 commented on 2016-10-03 03:26

I'm getting the error:
-> Cloning textadept hg repo...
(could not negotiate a common security protocol (tls1.1+) with; the likely cause is Mercurial is configured to be more secure than the server can support)
(consider contacting the operator of this server and ask them to support modern TLS protocol versions; or, set to allow use of legacy, less secure protocols when communicating with this server)
(see for more info)
abort: error: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:590)
==> ERROR: Failure while downloading textadept hg repo

chetgray commented on 2016-05-09 19:30

@reztho, I didn't flag the package out-of-date to demand you update it (I already had for my local PKGBUILD), merely to helpfully send notification that a new version was released, in case it fell by the wayside. No rush intended; I appreciate you maintaining a package for a mighty fine text editor. Cheers!

reztho commented on 2016-05-08 16:00

Ok, it's done. Make sure you build this package like this:
makepkg -C

, so makepkg cleans the src folder before compiling.

reztho commented on 2016-05-08 15:50

duarnimator, chetgray: I made the package the way it is now, because that was what was available at the time. EDIT: well, the modules link can be versioned, but still no tag for the latest version in the hg repository, so I'll keep using a revision changeset number.

I'm going to update the package now. I'm sorry if I can't update the package the very same day a new version is released. I have things to do in real life, you know. So please, be patient next time. Anyways I think this text editor is very interesting and should be in [community]. The more of you ask for it in the mailing list so a TU would like to get in charge of it, the better. Thanks for the help though.

daurnimator commented on 2016-05-05 04:21

diff --git a/PKGBUILD b/PKGBUILD
index 60f686d..8274716 100644
@@ -2,7 +2,7 @@
# Based on a contribution of: bitwave
pkgdesc="A fast, minimalist, and remarkably extensible cross-platform text editor"
arch=('i686' 'x86_64')
@@ -12,8 +12,8 @@ makedepends=('mercurial' 'wget' 'unzip')
- '')
+ "${pkgver}")

build() {
cd "$srcdir/$pkgname/src"

chetgray commented on 2016-05-03 13:17

Better sources, using pkgver:


Currently, points to, breaking package() that expects 8.6.

N.b. There is currently no Hg tag for 8.7, but there are binary tgz packages for both i386 and x64_86 (

Tre0n commented on 2016-03-10 08:35

This depends on wget and unzip to build. (Possibly more, haven't checked)

reztho commented on 2016-03-06 10:36

Notice that the dependencies in this package are managed by its build system unfortunately, so it downloads them the first time. What that error is telling you is that the scintilla363.tgz file wasn't successfully downloaded from Sourceforge. I suggest removing your "pkg" and "src" dirs and make the package again.

test0 commented on 2016-03-06 10:18

mkdir scintilla && tar xzf scintilla363.tgz -C scintilla && mv scintilla/*/* scintilla

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Makefile:408: recipe for target 'scintilla' failed
make: *** [scintilla] Error 2
==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build textadept.
==> Restart building textadept ? [y/N]

reztho commented on 2016-02-28 16:31

I finally finished it. In the future, I'll consider converting the PKGBUILD into a multipackage one.

reztho commented on 2016-02-02 20:32

It's going to take a while till I prepare the new package. In the mean time, disown this package to see if another one wants it besides me.

bitwave commented on 2016-02-02 07:21

Hey folks,

due to the comments from reztho, I will drop this package. He would like to contribute a source-only package under this name. This binary package will be available now under:

Please update to this package, so you can receive the latest updates or use the new textadept source only package.


bitwave commented on 2015-11-26 16:53

because this is a binary package, the textadept-curses elf is linked against an old version of curses:

ldd /usr/bin/textadept-curses (0x00007fff731a8000) => not found => /usr/lib/ (0x00007f8fb192e000) => /usr/lib/ (0x00007f8fb15ac000) => /usr/lib/ (0x00007f8fb12ae000) => /usr/lib/ (0x00007f8fb1098000) => /usr/lib/ (0x00007f8fb0cf4000)
/lib64/ (0x00007f8fb1b32000)

but arch linux current version is 6:

ncurses /usr/lib/
ncurses /usr/lib/
ncurses /usr/lib/
ncurses /usr/lib/

you can use a symbolic link or the LD_PRELOAD variable, to point the elf to the correct location or you wait until the lib is updated upstream.


ke7ofi commented on 2015-11-24 21:52

textadept-curses won't start and says `textadept-curses: error while loading shared libraries: cannot open shared object file: No such file or directory`. Is that an issue with the program, the package, or something on my end?

A bit of Ducking indicates that it may have to do with library architecture for curses, but I don't see that set as a dependency here (which could be part of the problem if multilib is required).