[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's mk, mkfile
From: |
Stefan Kangas |
Subject: |
bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's mk, mkfile |
Date: |
Sun, 17 Sep 2023 08:19:26 -0700 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's mk, mkfile,
Stefan Kangas <=