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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63235 in the body.
You can then email your comments to 63235 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.90; makefile-mode does not recognize Plan 9's mk, mkfile
Date: Tue, 2 May 2023 16:34:23 GMT

[Message part 1 (text/plain, inline)]

The makefile-mode is not general enough to make use of Plan 9's user
space mkfile format and mk command.

This is likely to be considered not a bug.  The expected behavior is
Emacs would be smart with Plan 9's user space tools.  Specifically,
the mk command and mkfile format in this case.

The unexpected behavior attempts to compile using the make command and
not the mk command.  I tried to locate a PLAN9Makefile-mode but didn't
find one in the command completion mechanism.

steps to reproduce
 - set PLAN9 and PATH environment variables in shell
 - verify, mk all, works at the plain shell
 - start, emacs -Q
 - visit /tmp/mkfile; makefile-mode does not recognize mkfile
 - M-x makefile-mode
 - M-x compile RET; Compile command: make -k, should adapt to mk command

quote
# example /tmp/mkfile
all:V:
  echo This line is left blank intentionally.
  
quote ends

[bug-gnu-emacs-report.text (application/octet-stream, attachment)]

Message #8 received at 63235 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 63235 <at> debbugs.gnu.org
Subject: Re: bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's
 mk, mkfile
Date: Wed, 03 May 2023 07:39:12 +0800

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

> The makefile-mode is not general enough to make use of Plan 9's user
> space mkfile format and mk command.
>
> This is likely to be considered not a bug.  The expected behavior is
> Emacs would be smart with Plan 9's user space tools.  Specifically,
> the mk command and mkfile format in this case.
>
> The unexpected behavior attempts to compile using the make command and
> not the mk command.  I tried to locate a PLAN9Makefile-mode but didn't
> find one in the command completion mechanism.
>
> steps to reproduce
>  - set PLAN9 and PATH environment variables in shell
>  - verify, mk all, works at the plain shell
>  - start, emacs -Q
>  - visit /tmp/mkfile; makefile-mode does not recognize mkfile
>  - M-x makefile-mode
>  - M-x compile RET; Compile command: make -k, should adapt to mk command
>
> quote
> # example /tmp/mkfile
> all:V:
>   echo This line is left blank intentionally.
>   
> quote ends

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?

Message #11 received at 63235 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63235 <at> debbugs.gnu.org
Subject: Re: bug#63235: 29.0.90; makefile-mode does not recognize Plan 9's
 mk, mkfile
Date: Thu, 4 May 2023 16:11:26 GMT

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 63235 <at> 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.

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

Message #16 received at 63235 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 63235 <at> debbugs.gnu.org
Subject: Re: 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 <at> sdf.org> writes:

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: 63235 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.