Import OpenBSD's Mg version 7.0

[jrm]

Summary

Mg is a small [1], fast, and free (public domain) editor with Emacs-like
keybindings. This portable version is maintained by OpenBSD.

When learning Unix-like systems, many of us came to a symbolic fork in
the road. For text editing, one could either learn a modal editor like
vi, or an editor that uses key combinations like Emacs. Those
comfortable with modal editing have /usr/bin/vi. For those accustomed
to key combinations, it is simple enough to install the mg package,
however it is also convenient to have something like Mg in the base
system when using tools like poudriere that use an unmodified image.

[1] Mg's binary is currently 247K.

Obtained from: https://github.com/ibara/mg
Sponsored by: The FreeBSD Foundation

Add 'contrib/mg/' from commit '9ea517e076481fce96fce4c641884f3a5ca25cb1'

git-subtree-dir: contrib/mg
git-subtree-mainline: 92ef98b8fa9273049af3cf2fcb4f5e13a6775ff8
git-subtree-split: 9ea517e076481fce96fce4c641884f3a5ca25cb1

usr.bin/mg: Add build components for contrib/mg

For details, refer to commits:

• 326a0ce38327c301fe11154ba3c4faf0e9ac7534
• 9ea517e076481fce96fce4c641884f3a5ca25cb1

Sponsored by: The FreeBSD Foundation

[pauamma_gundo.com]

contrib/mg/README-Mg

56

Not being able to support UTF-8 should be right here IMO. (See CAVEATS in mg.1.)

76

contrib/mg/mg.1

110

"command" missing here?

1141

I'd move this to the start of its section instead of burying out at the bottom, at the very least. Or better, to an UNREDEEMABLE FLAWS section, because if not supporting UTF-8 at all in 2022 isn't one, I don't know what is.

[jrm]

These are reasonable suggestions, but they would be best submitted as a pull request at https://github.com/ibara/mg. Upstream does well to keep the code portable, so these would benefit all consumers and it would keep our diff small (or nil as it is currently).

[imp]

Despite not supporting UTF-8, I support this. the license is good. The functionality is needed. And pkg base willl make the 'bloat' issue a non-issue.

[pauamma_gundo.com]

In D34411#779780, @jrm wrote:

These are reasonable suggestions, but they would be best submitted as a pull request at https://github.com/ibara/mg. Upstream does well to keep the code portable, so these would benefit all consumers and it would keep our diff small (or nil as it is currently).

Fair enough, and thanks for the repo URL. No time for a pull request for now, but filed https://github.com/ibara/mg/issues/40 and will revisit it time permitting.

Turns out that wasn't upstream enough, so I poked OpenBSD too.

[pauamma_gundo.com]

No obvious language problem jumps out to me in the manual page, but I can't vouch for its accuracy.

[manu]

usr.bin/mg/Makefile

8

This needs to have a PACKAGE= mg
and also some new files/modification for it in release/packages

[jrtc27]

usr.bin/mg/Makefile

11

Leave debugging, optimisation and warnings up to bsd.prog.mk and friends (and warning overrides belong in CWARNFLAGS if you need them)

16

One per line is nicer for diffs but I suspect this isn't going to be changed very often

[jrm]

usr.bin/mg/Makefile: Incorporate suggestions from jrtc27

• Leave debugging, optimization, and warnings up to bsd.prog.mk and friends
• Put warning overrides in CWARNFLAGS
• List each source file in SRCS on its own line for simpler diffs

[jrm]

Add missing entry in usr.bin/Makefile

[jrm]

usr.bin/mg/Makefile: Add PACKAGE=mg

[jrm]

usr.bin/mg/Makefile

8

I added PACKAGE=mg, but I'm unclear what belongs in release/packages. Is there any documentation or place in the code you can point me to understand what PACKAGE= and release/packages are for?

[manu]

usr.bin/mg/Makefile

8

No docs afaik.
You need entries in release/packages/Makefile.packages
mg_COMMENT= blah
mg_DESC= blah

[bapt]

despite the fact that I think we already have 2 editor (not counting ed), I personally think we should not import into base an editor which is not able to handle UTF-8.

[jrm]

In D34411#780273, @bapt wrote:

despite the fact that I think we already have 2 editor (not counting ed), I personally think we should not import into base an editor which is not able to handle UTF-8.

Lack of UTF-8 support is certainly a deficiency, but I don't expect it to be a major drawback for what importing mg is hoping to solve. The main motivation is to make editing configuration files easier for those of us who have decades of experience editing with the other major set of keybindings. It's certainly possible for anyone to stumble around in ee or vi, but it feels, I imagine, what it would be like for a vi user to use emacs.

Also

• if I'm not mistaken, ee doesn't support UTF-8
• mg is a single 247K binary
• as @imp pointed out, the clutter factor shoot be moot when pkgbase lands.

[jrm]

release/packages/Makefile.package: Add mg entries

[manu]

In D34411#780346, @jrm wrote:

In D34411#780273, @bapt wrote:

despite the fact that I think we already have 2 editor (not counting ed), I personally think we should not import into base an editor which is not able to handle UTF-8.

Lack of UTF-8 support is certainly a deficiency, but I don't expect it to be a major drawback for what importing mg is hoping to solve. The main motivation is to make editing configuration files easier for those of us who have decades of experience editing with the other major set of keybindings. It's certainly possible for anyone to stumble around in ee or vi, but it feels, I imagine, what it would be like for a vi user to use emacs.

Well, importing a tool that doesn't (and probably never will) support utf8 in 2022 is not good I think.

Also

• if I'm not mistaken, ee doesn't support UTF-8

It does.

• mg is a single 247K binary

Yes but this + this + that + this + that is how we ended up having a very bloated base right now.

• as @imp pointed out, the clutter factor shoot be moot when pkgbase lands.

Which is why I've asked you to take care of this as I don't want this on my system, now it looks good wrt pkgbase.

[imp]

Well, importing a tool that doesn't (and probably never will) support utf8 in 2022 is not good I think.

I don't disagree. My attitudes towards UTF-8's importance are likely an echo of my first job. I had a VT50 being the new guy that only understood upper case and was happy to get an upgrade to the VT52 which understood both lower and upper case... But cool high school stories aside...

https://github.com/hboetes/mg/issues/18 talks about this. There's two branches that support UTF-8, but one is a bit outdated, and the other is an avowed hack. So the 'likely never' part may be too strong. I'll take a look at https://github.com/paaguti/mg3a locally to see what's up with that.

Both of these clones are similar to, but a bit different than the OpenBSD mg fork. I'm unsure of the relationship there.

[danfe]

@bapt wrote:

Despite the fact that I think we already have 2 editors [in the base]

That's already good enough reason not to import the third one. We've got vi(1) for seasoned users, ee(1) for newcomers. Literally nothing begs for another one.

I personally think we should not import into base an editor which is not able to handle UTF-8.

And that nails it.

[jrm]

In D34411#780400, @danfe wrote:

@bapt wrote:

Despite the fact that I think we already have 2 editors [in the base]

That's already good enough reason not to import the third one. We've got vi(1) for seasoned users, ee(1) for newcomers. Literally nothing begs for another one.

I personally think we should not import into base an editor which is not able to handle UTF-8.

And that nails it.

To be clear I am not advocating taking something away from you or other users who prefer vi. You won't lose UTF-8 support or be required to edit configuration files with mg. For the cost of one 247K binary (which I understand you will soon be able to easily exclude when pkgbase lands), seasoned [1] users will be able to work the way they are most comfortable. Can you articulate what it is that you would be losing if this were imported?

[1] I won't label myself a seasoned user, but I know others here who prefer emacs keybindings.

[gbe]

LGTM for the man page parts.