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

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

[Van Ly]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]


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




[-- Attachment #2: bug gnu emacs report --]
[-- Type: application/octet-stream, Size: 2872 bytes --]


In GNU Emacs 29.0.90 (build 1, aarch64-unknown-linux-gnu, GTK+ Version
 3.24.24, cairo version 1.16.0) of 2023-04-12 built on x23
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Makefile

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date cl-loaddefs cl-lib shell
pcomplete compile text-property-search comint ansi-osc ansi-color ring
make-mode subr-x rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 46529 7249)
 (symbols 48 6126 0)
 (strings 32 16262 1966)
 (string-bytes 1 484945)
 (vectors 16 10967)
 (vector-slots 8 163927 11590)
 (floats 8 23 18)
 (intervals 56 229 0)
 (buffers 984 12))

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Van Ly <van.ly@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?

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

[Van Ly]

> 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.

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

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

[Stefan Kangas]

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.