search

hboetes / mg

Portable version of the OpenBSD maintained mg, micro emacs clone
183 stars 25 forks source link

Consolidate with other OpenBSD mg ports? #5

Closed lassik closed 6 years ago

lassik commented 6 years ago

Greetings. I found the following other OpenBSD mg ports:

Considering that these are now 4 repos for the same purpose, would you be willing to contact their maintainers and merge your work with one of them? :) IMHO, ibara's version seems to be the best maintained. It "aggressively tracks upstream" and is "Tested on recent versions of Arch, Cygwin, Debian, DragonFly BSD, FreeBSD, Mac OS X (10.10 or later), NetBSD, Slackware, and Ubuntu." It would be great to have a single portable OpenBSD mg repo that could be added to all OS package managers.

ghost commented 6 years ago

@lassik they look too complex compared to this repo, I am not surprised FreeBSD, DragonFlyBSD, NetBSD, Arch Linux, Ubuntu and Debian prefer hboetes's version. I prefer hboetes's version too, it is simple.

@ibara and @troglobit what do you think?

troglobit commented 6 years ago

Hi! Great to get a summary of the best MicroEmacs (Mg) forks out there, thanks :)

Generally we all have our different reasons for creating (and maintaining!) a fork. My own goals are:

  1. Track OpenBSD mg, they are the effective upstream these days
  2. Be stand-alone, not dependent on libbsd or any other library for *BSD-specific APIs
  3. Track other forks, for fixes and features, e.g. the forgotten Mg3a by Bengt Larsson
  4. Allow users to easily enable all hidden features, e.g. no-tab-mode which is disabled in OpenBSD
  5. Be nice to embedded systems, test cross compiling and deploy

When tracking upstream (1) I try to preserve the OpenBSD commit messages and original authors/committers. I think this is important, even though the code is in the public domain.

I use a configure script to detect the capabilities (2) of the target system and to enable/disable features (4). From my perspective this is simpler than having to edit a Makefile or similar, it also fits in the workflow of most other projects and can therefore also simplify pre-packaging into a .deb-file or similar. When I tag a new release I upload versioned tarballs to the GitHub releases page, unlike the GIT repo itself which only contains the configure.ac file (and Makefile.am's), the tarballs include the generated configure script. Meaning a user only needs a POSIX compliant shell, a termcap/nurses library, and cc to build ... sometimes it's not about looking "simple" from a GIT point of view but how you package the experience to the user.

My users are developers and end-users of embedded systems (5), this is what I'll safeguard and develop further. I've even considered a non-termcap backend for the TTY for small systems that cannot carry the weight of ncurses.

I've been maintaining software for a long time and will likely continue doing so. My little Mg port is not the highest prioritized project, nor is it the brightest shining star, so it will not be "aggressively" maintained, but I will cycle back to it every three months or so, because it's fun (!) and I continuously track what the OpenBSD project does by subscribing to openbsd-tech.

So I dunno, merging forks is generally a good idea, but it's also a lot of work. Having to compromise and find common grounds when opposing goals surface. Maybe we can just consider our forks/clones just various co-existing distributions of the true upstream OpenBSD?

Cheers /Joachim

troglobit commented 6 years ago

Update: Slow weekend, so I've spent some time hand merging all (relevant) changes and additions from the above mentioned clones. I've also tested on all systems I could lay my hands on: Debian GNU/Linux, Ubuntu, Alpine Linux, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, macOS >= 10.10, Cygwin, and a few embedded Linux systems.

A new release, v3.2, will be out tonight (CET). Building from the versioned tarball includes the genereated configure script, and thus does not require GNU autotools, only a POSIX shell and make. Even BSD pmake works.

lassik commented 6 years ago

Thanks for the detailed writeup @troglobit ! @hboetes What is your take on this?

hboetes commented 6 years ago

Leave me alone!

On Thu, Sep 27, 2018 at 6:06 PM Lassi Kortela notifications@github.com wrote:

@hboetes https://github.com/hboetes What is your take on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hboetes/mg/issues/5#issuecomment-425150101, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLeqUAotPXcUs-Q4DrUsZIXdB3InqxPks5ufPdogaJpZM4WL6_A .

lassik commented 6 years ago

That came out of nowhere. As you wish.

ulm commented 6 years ago

@lassik they look too complex compared to this repo, I am not surprised FreeBSD, DragonFlyBSD, NetBSD, Arch Linux, Ubuntu and Debian prefer hboetes's version. I prefer hboetes's version too, it is simple.

As the maintainer of the Gentoo package, I can only agree to this. What we want is a minimalistic implementation that we can include with our install media. It should have very few dependencies, and the basic keybindings should be similar to those of GNU Emacs.

We used to have Zile, but when it started to acquire too many features and external dependencies, we dropped it in favour of mg. See the Gentoo bug at https://bugs.gentoo.org/384451 for details.

@hboetes: Thank you for mg, and keep up the good work!

troglobit commented 6 years ago

I think we should respect Han's wishes, he clearly doesn't want this discussion here. I can only re-iterate what I said earlier, we all have our different reasons for doing what we do and opting for different technical solutions. This should be fine, let the best code win.

@ulm If you really want a minimalistic implementation with few dependencies you could try my dist; a configure --disable-all gives a 131 kiB stripped binary which only requires libtermcap.

Take care people! :)