bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's mk, mkfile

[Stefan Kangas <stefankangas@gmail.com>]

close 63235
tags 63235 wontfix
thanks

Van Ly <van.ly@sdf.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 63235@debbugs.gnu.org
>> Date: Wed, 03 May 2023 07:39:12 +0800
>> Content-Type: text/plain
>>
>> The way I understand it, mk is not a variant of Make, and is certainly
>> not close enough to be supported by Makefile mode.  For starters,
>> commands are not indented with tabs, but with spaces.
>>
>> Besides, who uses it in the real world?
>
> The real world is surreal is the sense I get.  Plan 9 User Space is
> packaged as 9base on the debian gnu/linux distribution.  Enough people
> use it I guess.  Finding the words list in Plan 9 preserved from old
> times was useful for me.  I have come across a recommended approach
> guide to customizing the use of make and one tip changes the indented
> tab convention.
>
> Anyway, if it is not too difficult for me, since I have done the fsf
> emacs copyright assignment paperwork, perhaps I can volunteer to widen
> Makefile mode to play well with mk.

We are not likely to take any patches that adds Plan9 mk support to
make-mode.el, even if the change is very minimal.  It will add to the
maintenance burden going forward, and it is just not widely used enough
to be worth it.

I recommend creating a new major mode and submitting it as a GNU ELPA
package instead.  This can be based on make-mode.el, a complete rewrite,
or written from scratch, as you prefer.  It's probably best to avoid
code duplication, perhaps by inheriting make-mode, if that makes sense
here.

I will be closing this bug as wontfix, but please don't take that as an
indication that a Plan9 mk package won't be a welcome addition to GNU
ELPA.  On the contrary, we will be happy to distribute such a package,
so that it can benefit users interested in this.

Please request your package to be included when it is ready.  The
process for that is described here:

    https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

> Tangentially in connection to Unicode and definitions for CJKrV
> characters, before I had the paperwork done, I offered a patch
> containing a readtable for feeding into Emacs and having a way to map
> character to definition, can that be included to the dictionary lookup
> function?
>
> The uni-unihan-readings.el file looks like
>
> QUOTE
> ;; -*-no-byte-compile: t; -*-
> (defvar readings-table
> 	(make-char-table 'readings-table nil)
> 	"Char table of definitions for East Asian characters.")
>
> (aset readings-table #x3400 "(same as U+4E18 X) hillock or mound")
> (aset readings-table #x3401 "to lick; to taste, a mat, bamboo bark")
> QUOTE ENDS

Please submit a separate bug report for this if it's still an issue, and
include a clear description of the issue.  I couldn't make it out from
the above.