[PATCH] Flymake support for C/C++

[PATCH] Flymake support for C/C++

[João Távora]

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

Hi,

Here's a proposal for supporting Flymake in C/C++. This patch:

- Sets up Flymake in c-mode buffers (heads up Alan), but doesn't
  automatically enable it.

- Adds a special target to src/Makefile so that Flymake can work with
  Emacs's C sources (using a default cc-flymake-use-special-make-target
  method).

- The special target's name is 'check-syntax' and uses CHK_SOURCES,
  which lets older Emacsen edit new Emacs sources with old Flymake
  implementations (dubious but harmless advantage).

- Is customizable by the user to use a zero-configuration method that
  guesses GCC flags from Makefiles (see
  cc-flymake-use-cc-directly). This probably works in the simplest
  scenarios(*)

- Is programmable by the user to use any other self-configuration
  technique (this includes per-file/dir manual configuration using a
  file-local cc-flymake-command)

*: Sadly, GNU Hello no longer works since it uses a backquoted shell
  expression that the current implementation can't intercept (my old
  use-emacs-as-a-shell-parser )
  Here it is, for reference

gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I. -I. -I.. -I../intl -I../intl    -g -O2 -c `test -f 'hello.c' || echo './'`hello.c

Also, FTR, discovered that -M flags do not seem to harm syntax-checking.
No idea if dependencies files are still created anyway though.

João


[-- Attachment #2: 0001-Add-a-Flymake-backend-for-C.patch --]
[-- Type: text/x-diff, Size: 11225 bytes --]

From 41ef8318c8c539e475080e3b240b9c941d39caa9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
Date: Thu, 12 Oct 2017 14:04:51 +0100
Subject: [PATCH] Add a Flymake backend for C(++)

* lisp/progmodes/cc-flymake.el: New file.

* lisp/progmodes/cc-mode.el (c-mode): Call c--setup-flymake.
(c--setup-flymake): New function.

* src/Makefile.in: Add check-syntax target.
---
 lisp/progmodes/cc-flymake.el | 214 +++++++++++++++++++++++++++++++++++++++++++
 lisp/progmodes/cc-mode.el    |   9 ++
 src/Makefile.in              |   5 +
 3 files changed, 228 insertions(+)
 create mode 100644 lisp/progmodes/cc-flymake.el

diff --git a/lisp/progmodes/cc-flymake.el b/lisp/progmodes/cc-flymake.el
new file mode 100644
index 0000000000..4baffdd3be
--- /dev/null
+++ b/lisp/progmodes/cc-flymake.el
@@ -0,0 +1,214 @@
+;;; cc-flymake.el --- Flymake backends for C/C++     -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2017 Free Software Foundation, Inc.
+
+;; Author: João Távora <joaotavora@gmail.com>
+;; Keywords: languages, c
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Flymake support for C/C++.
+
+;;; Code:
+
+(require 'subr-x) ; when-let*
+
+(defcustom cc-flymake-command 'cc-flymake-use-special-make-target
+  "Command used by the CC flymake backend.
+A list of strings, or a symbol naming a function that produces one
+such list when called with no arguments in the buffer where the
+variable `flymake-mode' is active.
+
+The command should invoke a GNU-style compiler that checks the
+syntax of a (Obj)C(++) program passed to it via its standard
+input and prints the result on its standard output."
+  :type '(choice
+          (symbol :tag "Function")
+          ((repeat :) string))
+  :group 'cc-flymake)
+
+(defvar-local cc-flymake--cached-flags nil)
+
+(defun cc-flymake--guess-flags (cc-program &optional trash-cache)
+  "Guess C(++) flags for compiling current buffer.
+Do this with by finding a suitable Makefile and intercepting an
+invocation of CC-PROGRAM, a string naming a C(++) compiler, in
+the output of \"make --just-print <file.o>\".
+
+Cache the result. TRASH-CACHE of a change to the Makefile rests
+the cache.
+
+This function signals an error if it encounters any problems,
+which normally causes using backends to be disabled.
+
+Can also function interactively for debug purposes."
+  (interactive (list (read-from-minibuffer "Compiler? ")
+                     current-prefix-arg))
+  (when trash-cache (setq cc-flymake--cached-flags nil))
+  (catch 'retval
+    (unless (buffer-file-name)
+      ;; don't error and don't cache, so that when the buffer is saved
+      ;; we get another chance.
+      (throw 'retval nil))
+    (when-let* ((makefile-dir
+                 (locate-dominating-file default-directory "Makefile"))
+                (makefile (expand-file-name "Makefile" makefile-dir))
+                (mtime (file-attribute-modification-time
+                        (file-attributes makefile))))
+      (cond
+       ((equal (list cc-program makefile mtime)
+               (cdr cc-flymake--cached-flags))
+        (when (called-interactively-p 'interactive)
+          (message "cache HIT for %s flags: %S" cc-program
+                   (car cc-flymake--cached-flags)))
+        (throw 'retval (car cc-flymake--cached-flags)))
+       (t
+        (let*
+            ((sans-nothing
+              (file-name-nondirectory
+               (file-name-sans-extension
+                (buffer-file-name))))
+             (blob (shell-command-to-string
+                    (format "make -C %s -f %s --just-print %s.o"
+                            makefile-dir
+                            makefile
+                            sans-nothing)))
+             (match (string-match
+                     (format "%s[[:space:]]+\\(\\(?:-.*\\)*\\)%s"
+                             cc-program
+                             sans-nothing)
+                     blob))
+             (flag-string (and match
+                               (match-string 1 blob)))
+             (flags (and flag-string
+                         ;; FIXME: shell unescaping: Nothing here to
+                         ;; deal with simple backslash-escaped spaces,
+                         ;; like quoted and backquoted expressions,
+                         ;; etc.
+                         (split-string
+                          flag-string
+                          nil
+                          nil
+                          "[[:space:]]+"))))
+          (when (or flags (string= "" flag-string))
+            (setq cc-flymake--cached-flags
+                  (list flags cc-program makefile mtime))
+            (when (called-interactively-p 'interactive)
+              (message "cache MISS for %s flags: %S" cc-program flags))
+            (throw 'retval flags))))))
+    (error "Could not guess %s flags" cc-program)))
+
+(require 'compile)
+(defun cc-flymake--make-diagnostics (source)
+  "Parse the current buffer of compilation messages.
+Return a list of diagnostics for the source buffer SOURCE."
+  ;; TODO: if you can understand it, use `compilation-mode's regexps
+  ;; or even some of its machinery here.
+  ;;
+  ;;    (set (make-local-variable 'compilation-locs)
+  ;;         (make-hash-table :test 'equal :weakness 'value))
+  ;;    (compilation-parse-errors (point-min) (point-max)
+  ;;                              'gnu 'gcc-include)
+  ;;    (while (next-single-property-change 'compilation-message)
+  ;;       ...)
+  ;;
+  ;; For now, this works minimaly well.
+  (cl-loop
+   while
+   (search-forward-regexp
+    "^\\(In file included from \\)?<stdin>:\\([0-9]+\\):\\([0-9]+\\):\n?\\(.*\\): \\(.*\\)$"
+    nil t)
+   for msg = (match-string 5)
+   for (beg . end) = (flymake-diag-region
+                      source
+                      (string-to-number (match-string 2))
+                      (string-to-number (match-string 3)))
+   for type = (if (match-string 1)
+                  :error
+                (assoc-default
+                 (match-string 4)
+                 '(("error" . :error)
+                   ("note" . :note)
+                   ("warning" . :warning))
+                 #'string-match))
+   collect (flymake-make-diagnostic source beg end type msg)))
+
+(defun cc-flymake-use-special-make-target ()
+  "Build command for checking a file with Make directly."
+  (unless (executable-find "make") (error "Make not found"))
+  `("make" "check-syntax" "CHK_SOURCES=-x c -"))
+
+(defvar-local cc-flymake-program "cc"
+  "C(++) compiler used by `cc-flymake-use-cc-directly'.")
+
+(defun cc-flymake-use-cc-directly ()
+  "Build command for checking a file with a C(++) compiler."
+  (unless (executable-find cc-flymake-program)
+    (error "%s not found" cc-flymake-program))
+  `(,cc-flymake-program
+    "-fsyntax-only"
+    ,@(cc-flymake--guess-flags cc-flymake-program)
+    "-x" "c" "-"))
+
+(defvar-local cc-flymake--proc nil
+  "Internal variable for `flymake-gcc'")
+
+;;;###autoload
+(defun cc-flymake (report-fn &rest _args)
+  "Flymake backend for GNU-style C compilers.
+This backend uses `cc-flymake-command' (which see) to launch a
+process that is passed the current buffer's contents via stdin.
+REPORT-FN is Flymake's callback."
+  (when (process-live-p cc-flymake--proc)
+    (kill-process cc-flymake--proc))
+  (let ((source (current-buffer)))
+    (save-restriction
+      (widen)
+      (setq
+       cc-flymake--proc
+       (make-process
+        :name "gcc-flymake"
+        :buffer (generate-new-buffer "*gcc-flymake*")
+        :command (if (symbolp cc-flymake-command)
+                     (funcall cc-flymake-command)
+                   cc-flymake-command)
+        :noquery t :connection-type 'pipe
+        :sentinel
+        (lambda (p _ev)
+          (when (eq 'exit (process-status p))
+            (unwind-protect
+                (when (eq p cc-flymake--proc)
+                  (with-current-buffer (process-buffer p)
+                    (goto-char (point-min))
+                    (let ((diags
+                           (cc-flymake--make-diagnostics source)))
+                      (if (or diags
+                              (zerop (process-exit-status p)))
+                          (funcall report-fn diags)
+                        ;; non-zero exit with no diags is cause
+                        ;; for alarm
+                        (funcall report-fn
+                                 :panic :explanation
+                                 (buffer-substring
+                                  (point-min) (progn (goto-char (point-min))
+                                                     (line-end-position))))))))
+              ;; (display-buffer (process-buffer p)) ; for debug
+              (kill-buffer (process-buffer p)))))))
+      (process-send-region cc-flymake--proc (point-min) (point-max))
+      (process-send-eof cc-flymake--proc))))
+
+(provide 'cc-flymake)
+;;; cc-flymake.el ends here
diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index b0e5fe47a7..37c8ecfa98 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -1842,6 +1842,7 @@ c-mode
   (c-common-init 'c-mode)
   (easy-menu-add c-c-menu)
   (cc-imenu-init cc-imenu-c-generic-expression)
+  (c--setup-flymake)
   (c-run-mode-hooks 'c-mode-common-hook))
 
 (defconst c-or-c++-mode--regexp
@@ -2297,6 +2298,14 @@ c-submit-bug-report
 	(insert (format "Buffer Style: %s\nc-emacs-features: %s\n"
 			style c-features)))))))
 
+(defun c--setup-flymake ()
+  "Setup flymake for cc buffers."
+  (add-hook 'flymake-diagnostic-functions 'cc-flymake nil t)
+  (defvar flymake-proc-allowed-file-name-masks)
+  ;; hackinly convince the legacy `flymake-proc' backend to disable
+  ;; itself.
+  (setq-local flymake-proc-allowed-file-name-masks nil))
+
 \f
 (cc-provide 'cc-mode)
 
diff --git a/src/Makefile.in b/src/Makefile.in
index 9a8c9c85f0..66c259902f 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -746,3 +746,8 @@ bootstrap-emacs$(EXEEXT):
 endif
 	@: Compile some files earlier to speed up further compilation.
 	$(MAKE) -C ../lisp compile-first EMACS="$(bootstrap_exe)"
+
+### Flymake support (for C only)
+check-syntax:
+	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) ${CHK_SOURCES} || true
+.PHONY: check-syntax
-- 
2.11.0

Re: [PATCH] Flymake support for C/C++

[Mark Oteiza]

joaotavora@gmail.com (João Távora) writes:

> +;; Flymake support for C/C++.
> +
> +;;; Code:
> +
> +(require 'subr-x) ; when-let*

Should only need it at compile time, then.

> +(defun cc-flymake-use-cc-directly ()
> +  "Build command for checking a file with a C(++) compiler."
> +  (unless (executable-find cc-flymake-program)
> +    (error "%s not found" cc-flymake-program))
> +  `(,cc-flymake-program
> +    "-fsyntax-only"
> +    ,@(cc-flymake--guess-flags cc-flymake-program)
> +    "-x" "c" "-"))

If we're handling multiple languages, a case for the major mode seems
appropriate:

 ...
 "-x" (pcase major-mode
        (`c-mode "c")
        ...)
 "-")

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, João.

On Thu, Oct 12, 2017 at 16:09:15 +0100, João Távora wrote:
> Hi,

> Here's a proposal for supporting Flymake in C/C++. This patch:

> - Sets up Flymake in c-mode buffers (heads up Alan), but doesn't
>   automatically enable it.

I must admit not to being too keen on CC Mode changing like this; it
would spoil the unity of purpose of the mode.  I've glanced through the
new code, but can't quite see why it needs to be an integral part of CC
Mode.  What is stopping the needed setup and initialisation being in a
function to be added to one of the mode's hooks: say c-mode-common-hook,
or even c-initialization-hook (which are documented in the CC Mode
manual)?

If there is any reason why it couldn't work on a CC Mode hook, I'd far
rather solve that reason (thus making the solution available for other
libraries too, and preserving the unity of CC Mode).

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> What is stopping the needed setup and initialisation being in a
> function to be added to one of the mode's hooks: say c-mode-common-hook,
> or even c-initialization-hook (which are documented in the CC Mode
> manual)?

The same could apply to font-lock support in CC-mode, or indentation
support in CC-mode, or imenu support, or ...

I'm not saying that the flymake support for C code has to be in CC-mode,
but I think it's a natural place for it.


        Stefan

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hi Alan,

Thanks for the quick reply.

Alan Mackenzie <acm@muc.de> writes:

> I must admit not to being too keen on CC Mode changing like this; it
> would spoil the unity of purpose of the mode.  I've glanced through the
> new code, but can't quite see why it needs to be an integral part of CC
> Mode.

Does setting a variable in the mode function make it an "integral part"?

> What is stopping the needed setup and initialisation being in a
> function to be added to one of the mode's hooks: say c-mode-common-hook,
> or even c-initialization-hook (which are documented in the CC Mode
> manual)?

I may be wrong, but I thought hooks were reserved for the user and
should be empty by default. But even if they weren't I don't think it
would work:

c-initialization-hook doesn't work, as flymake-diagnostic-functions is
a hook which needs a buffer-local value.

c-mode-common-hook is where a user would turn on `flymake-mode'. I, for
example, have this in my .emacs, which is the recommended way to turn on
a minor mode:

  (add-hook 'c-mode-common-hook 'flymake-mode)

If the setup is also moved to c-mode-common-hook, then this won't work
(because flymake-mode activation comes before its setup).

> If there is any reason why it couldn't work on a CC Mode hook,

Absolutely no reason, but those two don't seem to fit. Perhaps some new
hook run before c-mode-common-hook.

> I'd far rather solve that reason (thus making the solution available
> for other libraries too, and pres<erving the unity of CC Mode).

I don't understand what the boundaries of that "unity" are, but I do
understand cc-mode.el seems to be a special citizen in Emacs
major-mode-land.

Anyway Flymake wants to be a part of the global infrastructure for major
modes, which includes setting variables for recent "fancy" stuff like
ElDoc (eldoc-documentation-function), and older stuff like newcomment.el
(comment-*), to give just two examples. My patch does the same for
Flymake and flymake-diagnostic-functions.

João

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello again, João.

On Thu, Oct 12, 2017 at 19:46:20 +0100, João Távora wrote:
> Hi Alan,

> Alan Mackenzie <acm@muc.de> writes:

> > I must admit not to being too keen on CC Mode changing like this; it
> > would spoil the unity of purpose of the mode.  I've glanced through the
> > new code, but can't quite see why it needs to be an integral part of CC
> > Mode.

> Does setting a variable in the mode function make it an "integral part"?

Yes.  It tightly couples Flymake Mode with CC Mode.  It would render CC
Mode non-functional in the absence of Flymake Mode.  Distinct
functionalities should not be tightly coupled.

> > What is stopping the needed setup and initialisation being in a
> > function to be added to one of the mode's hooks: say c-mode-common-hook,
> > or even c-initialization-hook (which are documented in the CC Mode
> > manual)?

> I may be wrong, but I thought hooks were reserved for the user and
> should be empty by default. 

But it would surely be a user action which would enable flymake-mode,
thus adding to a CC Mode hook.  Major mode hooks are usually not used by
Emacs itself, but I'm not aware of any convention which prohibits it.

> But even if they weren't I don't think it would work:

> c-initialization-hook doesn't work, as flymake-diagnostic-functions is
> a hook which needs a buffer-local value.

OK, so f-d-functions could be set in c-mode-common-hook then, couldn't
it?

> c-mode-common-hook is where a user would turn on `flymake-mode'. I, for
> example, have this in my .emacs, which is the recommended way to turn on
> a minor mode:

>   (add-hook 'c-mode-common-hook 'flymake-mode)

> If the setup is also moved to c-mode-common-hook, then this won't work
> (because flymake-mode activation comes before its setup).

I don't understand that last bit.  What's the difference between
activation and setup?  It would seem then, the activation has nothing to
do with the major mode, or else it could be done in a major mode hook.
What am I missing here?

> > If there is any reason why it couldn't work on a CC Mode hook,

> Absolutely no reason, but those two don't seem to fit. Perhaps some new
> hook run before c-mode-common-hook.

"Those two" being activation and setup?

What do they need which is in CC Mode?  And how would a new CC Mode hook
help?  Would you be wanting it to be run before CC Mode is fully
initialised?

> > I'd far rather solve that reason (thus making the solution available
> > for other libraries too, and pres<erving the unity of CC Mode).

> I don't understand what the boundaries of that "unity" are, ....

"Do one thing and do it well".  Let's not get into the "do it well" bit
here, but the "do one thing" is "edit C/C++/... buffers".  Flymake would
appear to be distinct from that one thing.  What does Flymake do,
anyway?  There's nothing in the Emacs manual about it, and it's doc
string consists purely of boilerplate, at least in Emacs 25.3.

> .... but I do understand cc-mode.el seems to be a special citizen in
> Emacs major-mode-land.

:-)  As a matter of interest CC Mode consists of ~14 files, one of which
is cc-mode.el.

> Anyway Flymake wants to be a part of the global infrastructure for major
> modes, which includes setting variables for recent "fancy" stuff like
> ElDoc (eldoc-documentation-function), and older stuff like newcomment.el
> (comment-*), to give just two examples. My patch does the same for
> Flymake and flymake-diagnostic-functions.

But it should be loosely coupled with major modes, not tightly coupled,
surely?

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, Stefan.

On Thu, Oct 12, 2017 at 14:45:39 -0400, Stefan Monnier wrote:
> > What is stopping the needed setup and initialisation being in a
> > function to be added to one of the mode's hooks: say c-mode-common-hook,
> > or even c-initialization-hook (which are documented in the CC Mode
> > manual)?

> The same could apply to font-lock support in CC-mode, or indentation
> support in CC-mode, or imenu support, or ...

Font-lock and indentation support are essential to the major mode.  But
all of these, bar indentation, are connected to major modes via hooks of
one sort or another.

> I'm not saying that the flymake support for C code has to be in CC-mode,
> but I think it's a natural place for it.

What does Flymake mode do, anyway?  There's no documentation for it in
the Emacs manual, and its doc string, at least in 25.3, only says how to
turn it on and off, not what it's for.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

>> > What is stopping the needed setup and initialisation being in a
>> > function to be added to one of the mode's hooks: say c-mode-common-hook,
>> > or even c-initialization-hook (which are documented in the CC Mode
>> > manual)?
>> The same could apply to font-lock support in CC-mode, or indentation
>> support in CC-mode, or imenu support, or ...
> Font-lock and indentation support are essential to the major mode.  But
> all of these, bar indentation, are connected to major modes via hooks of
> one sort or another.

AFAICT, imenu support in CC-mode is enabled by having the major mode
function explicitly calling cc-imenu-init, not via some kind of hook.

Maybe all you want is for flymake support to be moved to cc-flymake.el
and then calls to `cc-flymake-init` be added to the relevant major
mode functions?

>> I'm not saying that the flymake support for C code has to be in CC-mode,
>> but I think it's a natural place for it.
> What does Flymake mode do, anyway?

It runs a code-checker in the background and highlights the source code
with the various error/warnings found.  It's very much like flyspell
except design to check code sanity rather spelling.

I think nowadays Emacs should strive to enable flymake automatically as
much as possible.  It's currently not really possible because *very* few
major modes support it, and because for most major modes you can't get
it to work without some user intervention (typically we need to have
some knowledge of the overall project organization in order to know how
this file relates to others, in C code typically we need at least
information about -I and -D compilation options).

But for Emacs-27, we should at the very least aim to enable it in
emacs-lisp-mode (where checking can be done without needing extra user
intervention).

> There's no documentation for it in the Emacs manual,

It's definitely in the manual in the emacs-26 branch.


        Stefan

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

>> Does setting a variable in the mode function make it an "integral part"?
> Yes.  It tightly couples Flymake Mode with CC Mode.  It would render CC
> Mode non-functional in the absence of Flymake Mode.

No.  It just sets a variable.  This variable is then only used if the
user elects to enable flymake mode.  Without flymake mode, or if the
user decides not to enable flymake mode, it will have no effect at all.


        Stefan

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hello again, Alan.

Alan Mackenzie <acm@muc.de> writes:

> Yes.  It tightly couples Flymake Mode with CC Mode.  It would render CC
> Mode non-functional in the absence of Flymake Mode.

If this your criteria for "tightly coupled", then it does not apply
here. c--setup-flymake simply adds to a(n abnormal) hook, using
add-hook, which is designed to be used even if the hook variable isn't
defined yet.

(There is actually a bit of unglyness in the current patch, in which
c--setup-flymake also `defvar's and `setq-local's another obsolete
variable. I could remove that bit and come up with a pure add-hook
solution.)

> thus adding to a CC Mode hook.  Major mode hooks are usually not used by
> Emacs itself, but I'm not aware of any convention which prohibits it.

Perhaps the example that I gave you is one of the reaons.

> OK, so f-d-functions could be set in c-mode-common-hook then, couldn't
> it?

No, for the reasons that I restate below.

> I don't understand that last bit.  What's the difference between
> activation and setup?

Activation is enabling the minor mode via the flymake-mode
function. Setup is ensuring that that activation is met with suitable
circunstances for the correct operation of the minor mode, in this case
that cc-specific "backends" are set.

> It would seem then, the activation has nothing to
> do with the major mode, or else it could be done in a major mode hook.
> What am I missing here?

You are not mistaken that activation has nothing to do with the major
mode, but you are missing that there are two steps, activation and
setup, that the differ in the ways I hope to have clarified above.

> "Those two" being activation and setup?

No sorry, those two being the two hooks that you suggested.

> What do they need which is in CC Mode?

They need to hook on to the major mode's function.

> And how would a new CC Mode hook
> help?

That would appease your wish for very loose coupling in that no mention
of the word "flymake" needed to appear in cc-mode.el

> Would you be wanting it to be run before CC Mode is fully initialised?

Doesn't matter really, before the user's c-mode-common-hook is fine.

> "Do one thing and do it well".  Let's not get into the "do it well"
> bit here, but the "do one thing" is "edit C/C++/... buffers".  Flymake
> would appear to be distinct from that one thing.

Ah, I so do agree with you Alan... and let's get not into the million
ways Emacs is already the kitchen sink. Flymake can be as useful to a
pretty broad definition of "editing" as font-locking, or imenu, or
outline.el, or supporting add-log-current-defun-function. All those
things that really aren't "editing", but help you edit.

> What does Flymake do, anyway?

It highlights the bits where you make mistakes as you type, or are about
to.

> There's nothing in the Emacs manual
> about it, and it's doc string consists purely of boilerplate, at least
> in Emacs 25.3.

That is true, but the situation changes considerably, if not immensely,
in emacs 26 :-). I rewrote Flymake and wrote a fair amount of
documention. You can read the documentaion in Texinfo format in the
"Flymake" node (which is separate from the Emacs user manual, for now)
or just C-h f flymake-mode RET in a recent emacs-26 or master build.

> But it should be loosely coupled with major modes, not tightly coupled,
> surely?

For sure, we agree. If you analyse the situation I think you'll come to
the conclusion that it is.

João

Re: [PATCH] Flymake support for C/C++

[Eli Zaretskii]

> Date: Thu, 12 Oct 2017 20:45:23 +0000
> Cc: sdl.web@gmail.com, eliz@gnu.org, npostavs@users.sourceforge.net,
>   João Távora <joaotavora@gmail.com>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> What does Flymake mode do, anyway?  There's no documentation for it in
> the Emacs manual, and its doc string, at least in 25.3, only says how to
> turn it on and off, not what it's for.

Flymake has its own manual, it should be in your info subdirectory.

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > *: Sadly, GNU Hello no longer works since it uses a backquoted shell
  >   expression that the current implementation can't intercept (my old
  >   use-emacs-as-a-shell-parser )

It is important to fix this, since it is not good for Flymake to fail
on the GNU example of proper packaging.

It could be fixed in Flymake or fixed in GNU Hello.
Which one is better?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 14 October 2017 at 02:34, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > *: Sadly, GNU Hello no longer works since it uses a backquoted shell
>   >   expression that the current implementation can't intercept (my old
>   >   use-emacs-as-a-shell-parser )
>
> It is important to fix this, since it is not good for Flymake to fail
> on the GNU example of proper packaging.
>
> It could be fixed in Flymake or fixed in GNU Hello.
> Which one is better?
>

These days, it seems much better to use Flycheck than Flymake (that's
certainly what I do). See https://github.com/flycheck/flycheck

It would be a pity for Flymake to become yet another part of Emacs that
developers spend time updating and users largely ignore; better to spin it
off into ELPA, and if people still want to work on it there, fine.
Meanwhile, why not use Flycheck by default (in the same way as we've
"in-sourced" Org and other packages)?

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

Re: [PATCH] Flymake support for C/C++

[Sami Kerola]

On 14 October 2017 at 08:10, Reuben Thomas <rrt@sc3d.org> wrote:
> On 14 October 2017 at 02:34, Richard Stallman <rms@gnu.org> wrote:
>>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > *: Sadly, GNU Hello no longer works since it uses a backquoted shell
>>   >   expression that the current implementation can't intercept (my old
>>   >   use-emacs-as-a-shell-parser )
>>
>> It is important to fix this, since it is not good for Flymake to fail
>> on the GNU example of proper packaging.
>>
>> It could be fixed in Flymake or fixed in GNU Hello.
>> Which one is better?
>
>
> These days, it seems much better to use Flycheck than Flymake (that's
> certainly what I do). See https://github.com/flycheck/flycheck
>
> It would be a pity for Flymake to become yet another part of Emacs that
> developers spend time updating and users largely ignore; better to spin it
> off into ELPA, and if people still want to work on it there, fine.
> Meanwhile, why not use Flycheck by default (in the same way as we've
> "in-sourced" Org and other packages)?

I tried to reproduce following comple output[1] without luck[2].

gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.
-I. -I.. -I../intl -I../intl    -g -O2 -c `test -f 'hello.c' || echo
'./'`hello.c

Perhaps backticks are coming from autotools. Mine are:

autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.15.1

[1] as mentioned in earlier in thread:
https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00432.html

[2] tested using hello-2.10 distribution package, and latest upstream
version 4d0301f23b1666cf466a0ac281a0ea008abe70bb.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: [PATCH] Flymake support for C/C++

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 14 Oct 2017 08:10:44 +0100
> Cc: João Távora <joaotavora@gmail.com>, 
> 	Sami Kerola <kerolasa@iki.fi>, emacs-devel@gnu.org, Alan Mackenzie <acm@muc.de>, 
> 	Eli Zaretskii <eliz@gnu.org>, Noam Postavsky <npostavs@users.sourceforge.net>, sdl.web@gmail.com, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> These days, it seems much better to use Flycheck than Flymake (that's certainly what I do). See
> https://github.com/flycheck/flycheck
> 
> It would be a pity for Flymake to become yet another part of Emacs that developers spend time updating and
> users largely ignore; better to spin it off into ELPA, and if people still want to work on it there, fine. Meanwhile,
> why not use Flycheck by default (in the same way as we've "in-sourced" Org and other packages)?

I don't understand: Flycheck is an external package; why should we
prefer it to Flymake, assuming that the latter will become supported
well by the built-in major modes?

IOW, what I see here is a serious effort to make Flymake a
sophisticated and flexible syntax-checking tool bundled with Emacs.  I
don't see why should we object to such an effort, when one of our
major goals is to provide a modern program development environment.
If this effort is successful, I presume that users will not ignore
Flymake.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 14 Oct 2017 08:10:44 +0100
> > Cc: João Távora <joaotavora@gmail.com>,
> >       Sami Kerola <kerolasa@iki.fi>, emacs-devel@gnu.org, Alan
> Mackenzie <acm@muc.de>,
> >       Eli Zaretskii <eliz@gnu.org>, Noam Postavsky <
> npostavs@users.sourceforge.net>, sdl.web@gmail.com,
> >       Stefan Monnier <monnier@iro.umontreal.ca>
> >
> > These days, it seems much better to use Flycheck than Flymake (that's
> certainly what I do). See
> > https://github.com/flycheck/flycheck
> >
> > It would be a pity for Flymake to become yet another part of Emacs that
> developers spend time updating and
> > users largely ignore; better to spin it off into ELPA, and if people
> still want to work on it there, fine. Meanwhile,
> > why not use Flycheck by default (in the same way as we've "in-sourced"
> Org and other packages)?
>
> I don't understand: Flycheck is an external package; why should we
> prefer it to Flymake, assuming that the latter will become supported
> well by the built-in major modes?
>

​See ​
http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake
​

And I suggested precisely bundling Flycheck with Emacs.​

IOW, what I see here is a serious effort to make Flymake a
> sophisticated and flexible syntax-checking tool bundled with Emacs.  I
> don't see why should we object to such an effort, when one of our
> major goals is to provide a modern program development environment.
>

​Because with Flycheck this is already accomplished. Why not work instead
on things that Emacs lacks?​ There are already far too many duplicated
packages, leading to duplicated maintenance effort.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3451 bytes --]

Re: [PATCH] Flymake support for C/C++

[Dmitry Gutov]

On 10/14/17 11:15 AM, Reuben Thomas wrote:

> ​Because with Flycheck this is already accomplished. Why not work 
> instead on things that Emacs lacks?​ There are already far too many 
> duplicated packages, leading to duplicated maintenance effort.

See the second part of this comment: 
https://github.com/flycheck/flycheck/issues/1177#issuecomment-267445833

"...I'd rather let Flycheck die if no maintainer was left to work on it 
than moving it into Emacs..."

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 14 October 2017 at 09:22, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10/14/17 11:15 AM, Reuben Thomas wrote:
>
> ​Because with Flycheck this is already accomplished. Why not work instead
>> on things that Emacs lacks?​ There are already far too many duplicated
>> packages, leading to duplicated maintenance effort.
>>
>
> See the second part of this comment: https://github.com/flycheck/fl
> ycheck/issues/1177#issuecomment-267445833
>
> "...I'd rather let Flycheck die if no maintainer was left to work on it
> than moving it into Emacs..."
>

​It doesn't have to be moved, just as Org was not moved into Emacs, but
continues to be maintained externally, and its sources imported.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1557 bytes --]

Re: [PATCH] Flymake support for C/C++

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 14 Oct 2017 09:15:52 +0100
> Cc: Richard Stallman <rms@gnu.org>, João Távora <joaotavora@gmail.com>, 
> 	Sami Kerola <kerolasa@iki.fi>, emacs-devel@gnu.org, Alan Mackenzie <acm@muc.de>, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>, sdl.web@gmail.com, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
>  I don't understand: Flycheck is an external package; why should we
>  prefer it to Flymake, assuming that the latter will become supported
>  well by the built-in major modes?
> 
> ​See ​http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake​

That compares with the old Flymake.

> And I suggested precisely bundling Flycheck with Emacs.​

Is this likely to happen?  The comments here seem to be clear evidence
to the contrary:

  https://github.com/flycheck/flycheck/issues/323#issuecomment-38094131
  https://github.com/flycheck/flycheck/issues/323#issuecomment-38169115

> ​Because with Flycheck this is already accomplished. Why not work instead on things that Emacs lacks?​
> There are already far too many duplicated packages, leading to duplicated maintenance effort.

See above: the Flycheck developers seem to be unwilling to work with
this project.  Having a good bundled alternative could very well
become a better one.

Re: [PATCH] Flymake support for C/C++

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> It could be fixed in Flymake or fixed in GNU Hello.
> Which one is better?

It's too soon to tell, but I lean towards Flymake. I think a slightly
better compiler flag guesser can be evolved there (in fact, my previous
version worked, though it probably has other problems) that works with
Hello and many others. As a bonus, this compiler flag guesser could work
for many other assistance functionality, like auto-completion, etc...

I think it would be bad for Flymake's popularity if it demanded too
strict compliance from the projects it is trying to check.

João

Re: [PATCH] Flymake support for C/C++

[João Távora]

Reuben Thomas <rrt@sc3d.org> writes:
> On 14 October 2017 at 02:34, Richard Stallman <rms@gnu.org> wrote:
>  It is important to fix this, since it is not good for Flymake to fail
>  on the GNU example of proper packaging.
>
>  It could be fixed in Flymake or fixed in GNU Hello.
>  Which one is better?
>
> These days, it seems much better to use Flycheck than Flymake (that's
> certainly what I do). See https://github.com/flycheck/flycheck

In the context of this specific subthread, can you tell us if Flycheck
automatically infers the compilation flags of, say, GNU Emacs and GNU
Hello when checking C code? Does it do so for any other project?

João

Re: [PATCH] Flymake support for C/C++

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 14 Oct 2017 09:29:52 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>, Sami Kerola <kerolasa@iki.fi>, emacs-devel@gnu.org, 
> 	João Távora <joaotavora@gmail.com>, 
> 	Alan Mackenzie <acm@muc.de>, Leo Liu <sdl.web@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
>  "...I'd rather let Flycheck die if no maintainer was left to work on it than moving it into Emacs..."
> 
> ​It doesn't have to be moved, just as Org was not moved into Emacs, but continues to be maintained
> externally, and its sources imported.

You mean, import Flycheck over its developer's objections?  I very
much doubt we'd want to do that.  It's the developer's legitimate
right not to allow it.  And even if we did, how will this work once
bug reports will come in, and we will expect/request the Flycheck
developers to handle them?

I simply don't see how something like that can work well enough for us
to make it the endorsed solution.

Re: [PATCH] Flymake support for C/C++

[guillaume papin]

flycheck used to invoke Make, at least for checking Makefiles.
However they removed this feature[1],
after user complained about the security implication of invoking Make[2] [3].

The issue being that even in --just-print mode, Make can do some work.

On a side note, at some point earlier they changed the --dry-run flag (equivalent to --just-print) by -n,
because the latter is POSIX compliant, working with more make implementations[4].

To answer your questions, which weren't addressed to me but I will share what I know:

> In the context of this specific subthread, can you tell us if Flycheck
> automatically infers the compilation flags of, say, GNU Emacs and GNU
> Hello when checking C code? Does it do so for any other project?

Out-of-the-box, Flycheck does not seem to infer the flags for GNU Hello.
For example I have the following error when I open src/hello.c:

    error           config.h: No such file or directory (c/c++-gcc)

There are options to configure flycheck with the following customization variables:
    flycheck-c/c++-gcc-executable
      User option: The executable of the c/c++-gcc syntax checker.
    flycheck-gcc-args
      User option: A list of additional command line arguments.
    flycheck-gcc-definitions
      User option: Additional preprocessor definitions for GCC.
    flycheck-gcc-include-path
      User option: A list of include directories for GCC.
    flycheck-gcc-includes
      User option: A list of additional include files for GCC.
    flycheck-gcc-language-standard
      User option: The language standard to use in GCC.
    flycheck-gcc-no-exceptions
      User option: Whether to disable exceptions in GCC.
    flycheck-gcc-no-rtti
      User option: Whether to disable RTTI in GCC.
    flycheck-gcc-openmp
      User option: Whether to enable OpenMP in GCC.
    flycheck-gcc-pedantic
      User option: Whether to warn about language extensions in GCC.
    flycheck-gcc-pedantic-errors
      User option: Whether to error on language extensions in GCC.
    flycheck-gcc-warnings
      User option: A list of additional warnings to enable in GCC.

M-x customize-variable RET flycheck-gcc-args RET can be sufficient, the other options preceded this generic option.
However settings the option per file manually does not really scale IMHO.
Also, many other features would benefit from knowing these compile options, for example ff-find-other-file, c-macro-expand, and maybe more in the futur: disassembler plugin, company mode, GCC fix-it hints[6] integration, 

Then there is flycheck extension, like one I maintain (irony-mode) and others,
such as cmake-ide and ede-compdb, that uses the compilation database I mentioned earlier[5].
For example ede-compdb works for both flymake and flycheck:
- https://github.com/randomphrase/ede-compdb#flymake-support

I'm not sure that the best solution is for flymake to invent it's own way of getting the compile options.
IMHO it would be best if it only provided a way to customize them,
letting the burden of how to do it to "something else", but I may not be practical here.

[1] https://github.com/flycheck/flycheck/blob/cfe02c0b2f0ad09ff0555583b5cf43125f549108/CHANGES.old#L129
[2] https://github.com/flycheck/flycheck/issues/572
[3] https://github.com/flycheck/flycheck/issues/573
[4] https://github.com/flycheck/flycheck/issues/322
[5] https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00398.html
[6] GCC -fdiagnostics-parseable-fixits option, from https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 14 October 2017 at 11:36, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 14 Oct 2017 09:29:52 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>,
> >       Noam Postavsky <npostavs@users.sourceforge.net>, Sami Kerola <
> kerolasa@iki.fi>, emacs-devel@gnu.org,
> >       João Távora <joaotavora@gmail.com>,
> >       Alan Mackenzie <acm@muc.de>, Leo Liu <sdl.web@gmail.com>,
> >       Stefan Monnier <monnier@iro.umontreal.ca>
> >
> >  "...I'd rather let Flycheck die if no maintainer was left to work on it
> than moving it into Emacs..."
> >
> > ​It doesn't have to be moved, just as Org was not moved into Emacs, but
> continues to be maintained
> > externally, and its sources imported.
>
> You mean, import Flycheck over its developer's objections?


​Its developer seems to object to its becoming part of Emacs; I'm not
suggesting that.​

It's the developer's legitimate
> ​ ​
> right not to allow it.


(It's released under GPLv3+, so the developer can't disallow it. But it
doesn't matter here, and maintaining good relations with upstream is of
course important.)​

And even if we did, how will this work once
> bug reports will come in, and we will expect/request the Flycheck
> developers to handle them?
>

​As for any other external package (and with other packages such as Org and
CEDET), bug reports should go to the package developers.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3375 bytes --]

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> ​See ​
> http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake
> ​

Note also that the flymake in emacs-26 is quite different from the
flymake described above.


        Stefan

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hello Guillaume, Reuben,

I hope you don't mind that I am replying to you both in the same
message.
        
Reuben Thomas <rrt@sc3d.org> writes:

> On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote:
> ​See
> ​http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake​

That page is now completely outdated. If you have a serious interest in
updating it, I can provide you with information about the new Flymake
that isn't already in its manual. Otherwise, please don't advertise a
misleading comparison.

>>  don't see why should we object to such an effort, when one of our
>>  major goals is to provide a modern program development environment.
> ​Because with Flycheck this is already accomplished.

I believe it is generally naive to think such a thing.  But
specifically, I've had a look at flycheck.el and (again, if you are
really interested) I am willing to debate why I think parts of its
implementation are inferior to my rewrite of Flymake.

guillaume papin <guillaume.papin@epitech.eu> writes:

> flycheck used to invoke Make, at least for checking Makefiles.
> However they removed this feature[1],
> after user complained about the security implication of invoking Make[2] [3].

flymake-mode isn't (yet) turned on by default on visiting a file, so I
think there aren't these implications yet (I might be overseeing
others).

> To answer your questions, which weren't addressed to me but I will
> share what I know:

No problem, this is always welcome.

> Out-of-the-box, Flycheck does not seem to infer the flags for GNU Hello.

I suppose it's safe to say it doesn't try to infer flags for any
project.  So here's one (apparently useful) thing that Flymake might do
that Flycheck doesn't. My point obviously being that there is no "end of
History" for on-the-fly buffer checkers (or for anything by that
matter), there are always things to work on.

> M-x customize-variable RET flycheck-gcc-args RET can be sufficient, the other options preceded this generic option.
> However settings the option per file manually does not really scale
> IMHO.

In Flymake/Emacs, you would use .dir-locals to set it for the dir. I'd
be surprised to learn that doesn't work for Flycheck, too.

> Also, many other features would benefit from knowing these

That's my idea too.

> I'm not sure that the best solution is for flymake to invent it's own
> way of getting the compile options.

I, on the contrary, am quite sure it is not.  But this is precisely the
point of Flymake being in Emacs: it means that functionality that begins
by being specific to a package can more easily be refactored so it is
used by other parts of Emacs.

This also works in the reverse direction: Flymake can benefit early from
improvements done to other parts of Emacs.  Perhaps Flymake will take
earlier advantage from improvements to project.el backends (which are,
in my opinion, the natural place for such a flag-guessers to live).  And
Flymake can be the catalyst for improvements to other packages, like
checkdoc or Flyspell, to name just two.

Finally, being in Emacs also means it gets the care and attention of a
very talented group of programmers that share the common goal of
improving GNU and Emacs as a whole.

João

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 14 October 2017 at 17:29, João Távora <joaotavora@gmail.com> wrote:

>
> Reuben Thomas <rrt@sc3d.org> writes:
>
> > On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > ​See
> > ​http://www.flycheck.org/en/latest/user/flycheck-versus-
> flymake.html#flycheck-versus-flymake​
>
> That page is now completely outdated. If you have a serious interest in
> updating it, I can provide you with information about the new Flymake
> that isn't already in its manual. Otherwise, please don't advertise a
> misleading comparison.
>

The page invites corrections, so ​I suggest you edit it yourself and submit
a pull request, or ​simply list some updates in an issue at

https://github.com/flycheck/flycheck/issues

​It's certainly good to have it up to date; the page does contain a
disclaimer about the versions of Flymake and Flycheck being compared, at
least, so I don't think it's misleading.​

I believe it is generally naive to think such a thing.  But
> specifically, I've had a look at flycheck.el and (again, if you are
> really interested) I am willing to debate why I think parts of its
> implementation are inferior to my rewrite of Flymake.
>

It sounds as though I've underestimated your improvements; I'm sorry. I
agree that it's good to have a strong alternative.

Finally, being in Emacs also means it gets the care and attention of a
> very talented group of programmers that share the common goal of
> improving GNU and Emacs as a whole.
>

​It's not necessary for it to be in Emacs for that to happen (though I
admit it will probably get more attention as a part of Emacs), and the more
code that is in Emacs, the greater the maintenance burden for any change or
new feature.

I would like to see more packages being spun out into independent projects,
and packages that are currently imported into git from upstream (such as
Org and CEDET) removed from git (though I appreciate that to have them
available for all users it will be necessary to test them with releases,
and it may be necessary to include them in source releases).

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 4089 bytes --]

Re: [PATCH] Flymake support for C/C++

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this likely to happen?  The comments here seem to be clear evidence
> to the contrary:
>
>   https://github.com/flycheck/flycheck/issues/323#issuecomment-38094131
>   https://github.com/flycheck/flycheck/issues/323#issuecomment-38169115
>
>> ​Because with Flycheck this is already accomplished. Why not work
>> instead on things that Emacs lacks?​
>> There are already far too many duplicated packages, leading to duplicated maintenance effort.
>
> See above: the Flycheck developers seem to be unwilling to work with
> this project.  Having a good bundled alternative could very well
> become a better one.

Sebastian doesn't maintain flycheck any more and the new developers make
thing differently. Regardless, getting copyright assignment would be a
substantial effort.

His general points about Emacs releases are pretty much still true. A
package like flycheck would be better of in something like ELPA and
bundled into an Emacs+ELPA package.

Phil

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 17 October 2017 at 11:53, Phillip Lord <phillip.lord@russet.org.uk>
wrote:

> His general points about Emacs releases are pretty much still true. A
> package like flycheck would be better of in something like ELPA and
> bundled into an Emacs+ELPA package.
>

​I'm having a hard time here making myself clear, it seems! I am not
suggesting copyright assignment, I am not suggesting pulling the sources
into the Emacs repo, I am merely suggesting shipping Flycheck with Emacs.

I'm also saying that's a good model for other third-party code like Org and
CEDET.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1403 bytes --]

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ​I'm having a hard time here making myself clear, it seems! I am not
  > suggesting copyright assignment, I am not suggesting pulling the sources
  > into the Emacs repo, I am merely suggesting shipping Flycheck with Emacs.

If we did that sort of thing, we would make trouble for ourselves, so
our policy is not to do so.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 18 October 2017 at 05:03, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > ​I'm having a hard time here making myself clear, it seems! I am not
>   > suggesting copyright assignment, I am not suggesting pulling the
> sources
>   > into the Emacs repo, I am merely suggesting shipping Flycheck with
> Emacs.
>
> If we did that sort of thing, we would make trouble for ourselves, so
> our policy is not to do so.
>

We use various non-FSF-copyright C libraries. We don't ship their sources,
it's true
​.


​
We're already working on making it possible to remove from git Emacs Lisp
packages that are shipped in source releases:​


http://lists.gnu.org/archive/html/emacs-orgmode/2016-12/msg00401.html

[I wrote:]

> 2. Is there any possibility to make org-mode a build-time dependency of
> Emacs, like the C libraries that it requires, or is that a silly idea?
That
> could permit it to be shipped as built-in, without having its source
> duplicated in Emacs's repository.

[Philip Lord replied:]

This kind of idea is, indeed, being actively considered on
emacs-devel. In fact, I managed to get a simple version of this working
using package.el during the build process. The idea would be that
packages in ELPA format could be made available to Emacs during the

We have been doing this with C code for years; I look forward to our
working out how to do it with Elisp too, so that we can reap the same
benefits: a wider range of functionality combined with more loosely-coupled
code and development processes.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3434 bytes --]

Re: [PATCH] Flymake support for C/C++

[Clément Pit-Claudel]

On 2017-10-14 04:33, Eli Zaretskii wrote:
> See above: the Flycheck developers seem to be unwilling to work with
> this project.

That's incorrect, Eli. The former maintainer didn't want to assign copyright to FSF.  Most of the code is still his, so there's not much we can do.  But that doesn't mean we (the new developers) are unwilling to work with the Emacs project.

Re: [PATCH] Flymake support for C/C++

[Clément Pit-Claudel]

On 2017-10-14 12:29, João Távora wrote:
>> On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote: ​
>> See ​
>> http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake
>> ​
> 
> That page is now completely outdated [...] please don't advertise a 
> misleading comparison.

That's a strong statement, and I don't think it's fair: this page is intended to help users chose between Flycheck and Flymake *now*. Your Flymake update hasn't been released yet, so an update to that page comparing against the unreleased Flymake would mislead readers into thinking that Flymake can do more for them that it really can at this point.

> If you have a serious interest in updating it, I can provide you with
> information about the new Flymake that isn't already in its manual.

We do have a serious interest in updating it :) Could you help? I'd love to mention that a new release of FLymake, fixing most of these deficiencies, is in the works.

Clément.

Re: [PATCH] Flymake support for C/C++

[João Távora]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2017-10-14 12:29, João Távora wrote:
>>> On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote: ​
>>> See ​
>>> http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake
>>> ​
>> 
>> That page is now completely outdated [...] please don't advertise a 
>> misleading comparison.
>
> That's a strong statement, and I don't think it's fair: this page is
> intended to help users chose between Flycheck and Flymake *now*.

I don't know if we agree, but to me, "misleading" is not the same as
"ill-intentioned": I don't think I in any way implied that the page, its
authors or its proponents are or have ever been ill-intentioned (and for
the record, I don't believe so).

I just don't think it makes any sense to advertise that comparison
and/or to make any decisions based on it right now. You must agree that
decisions are things that affect the future and that when they are based
on outdated information, they have a higher probability of being
misled. So that's why I characterized the page as "misleading" and
that's why I politely asked Reuben to stop advertising it.

> Your Flymake update hasn't been released yet, so an update to that
> page comparing against the unreleased Flymake would mislead readers
> into thinking that Flymake can do more for them that it really can at
> this point.

I also didn't ask anyone to update the page, though I volunteered to
help. Again, I just asked to stop advertising it as a decision-making
premise and explained why.

> We do have a serious interest in updating it :) Could you help?

I can certainly fill in the gaps that aren't clear from the Flymake
manual, if you have already read it.

> I'd love to mention that a new release of FLymake, fixing most of
> these deficiencies, is in the works.

I think that this very phrase added somewhere visible is just fine, with
optional love of course :-)

João

Re: [PATCH] Flymake support for C/C++

[John Wiegley]

>>>>> "CP" == Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

PC> On 2017-10-14 04:33, Eli Zaretskii wrote:
>> See above: the Flycheck developers seem to be unwilling to work with this
>> project.

CP> That's incorrect, Eli. The former maintainer didn't want to assign
CP> copyright to FSF. Most of the code is still his, so there's not much we
CP> can do. But that doesn't mean we (the new developers) are unwilling to
PC> work with the Emacs project.

Thanks for the clarification, Clément. The original flycheck author did not
want to assign copyright.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We use various non-FSF-copyright C libraries. We don't ship their sources,

To "use" a library has many possible meanings.
Some of them are ok, some would violate our principles or our license.
Could you explain concretely?

Also, who are "we"?

  > We're already working on making it possible to remove from git Emacs Lisp
  > packages that are shipped in source releases:​

Remove what?  From what?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 19 October 2017 at 04:26, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > We use various non-FSF-copyright C libraries. We don't ship their
> sources,
>
> To "use" a library has many possible meanings.
> Some of them are ok, some would violate our principles or our license.
> Could you explain concretely?
>

​I'm talking about the various library dependencies of Emacs.​


> Also, who are "we"?
>

​We Emacs maintainers.​
​

>   > We're already working on making it possible to remove from git Emacs
> Lisp
>   > packages that are shipped in source releases:​
>
> Remove what?  From what?
>

​Remove what? Emacs Lisp packages, e.g. Org mode (see above: "remove…Emacs
Lisp packages").​

From what? the Emacs git repository (see above: "remove from git").

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2404 bytes --]

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > We use various non-FSF-copyright C libraries. We don't ship their
  > > sources,
  > >
  > > To "use" a library has many possible meanings.
  > > Some of them are ok, some would violate our principles or our license.
  > > Could you explain concretely?
  > >

  > ​I'm talking about the various library dependencies of Emacs.​

I think you are talking about linking Emacs with nonfree libraries
that are part of the operating system it is being compiled for.  Right?

That's a special case, permitted by the system library exception
in GPL version 3.

We don't distribute these libraries at all, neither sources nor binaries.
Emacs uses them because they are standardly present on the target platform.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 23 October 2017 at 00:18, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >   > We use various non-FSF-copyright C libraries. We don't ship their
>   > > sources,
>   > >
>   > > To "use" a library has many possible meanings.
>   > > Some of them are ok, some would violate our principles or our
> license.
>   > > Could you explain concretely?
>   > >
>
>   > ​I'm talking about the various library dependencies of Emacs.​
>
> I think you are talking about linking Emacs with nonfree libraries
> that are part of the operating system it is being compiled for.  Right?
>

​No, I mean the various libre libraries it uses, such as libjpeg, libpng,
librsvg etc.​

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1599 bytes --]

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ​No, I mean the various libre libraries it uses, such as libjpeg, libpng,
  > librsvg etc.​

Anyone that distributes Emacs binaries linked with these libraries
is supposed to distribute their source code too.

Is someone distributing Emacs binaries and failing to include those
libraries' source code?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 24 October 2017 at 05:12, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > ​No, I mean the various libre libraries it uses, such as libjpeg,
> libpng,
>   > librsvg etc.​
>
> Anyone that distributes Emacs binaries linked with these libraries
> is supposed to distribute their source code too.
>
​
I'm not sure how we ended up here. I was not talking about binaries, or
indeed, anyone's distribution of Emacs but ours.

I was saying that, just as we do not insist that all our C dependencies be
a) installed in Emacs's git repository and b) distributed as part of Emacs
source releases, there is no reason in principle why we cannot have
external Elisp dependencies, for example Org and CEDET.

[-- Attachment #2: Type: text/html, Size: 1674 bytes --]

Re: [PATCH] Flymake support for C/C++

[Dmitry Gutov]

On 10/24/17 12:45 PM, Reuben Thomas wrote:

> I was saying that, just as we do not insist that all our C dependencies 
> be a) installed in Emacs's git repository and b) distributed as part of 
> Emacs source releases, there is no reason in principle why we cannot 
> have external Elisp dependencies, for example Org and CEDET.

We distribute both Org and CEDET with Emacs, and require copyright 
assignment for that code.

Irrespective of which repositories the development happens in.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 24 October 2017 at 10:48, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10/24/17 12:45 PM, Reuben Thomas wrote:
>
> I was saying that, just as we do not insist that all our C dependencies be
>> a) installed in Emacs's git repository and b) distributed as part of Emacs
>> source releases, there is no reason in principle why we cannot have
>> external Elisp dependencies, for example Org and CEDET.
>>
>
> We distribute both Org and CEDET with Emacs, and require copyright
> assignment for that code.
>
> Irrespective of which repositories the development happens in.
>

Copyright assignment is a different matter: that's a consequence of their
being GNU packages. We require copyright assignment for GNU make, which is
required to build Emacs, but we do not put its sources in Emacs's git
repository, or distribute it in source releases.

It's really the question of where development happens that I'm interested
in. Just as we don't need to maintain our own version of GNU make, or any
of the other C dependencies, it's no longer essential, now that we have a
good way of packaging Elisp, to maintain Org, CEDET etc. in the Emacs
repository.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2066 bytes --]

Re: [PATCH] Flymake support for C/C++

[Dmitry Gutov]

On 10/24/17 12:52 PM, Reuben Thomas wrote:

> It's really the question of where development happens that I'm 
> interested in.

We've been talking about Flycheck, haven't we? It's not the real issue 
with it.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 24 October 2017 at 10:57, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10/24/17 12:52 PM, Reuben Thomas wrote:
>
> It's really the question of where development happens that I'm interested
>> in.
>>
>
> We've been talking about Flycheck, haven't we? It's not the real issue
> with it.
>

​The argument was made that we couldn't use it by default because we can't
get its copyright assigned to the FSF, so we can't include it as part of
Emacs.​

I was arguing that it shouldn't be necessary to have an Elisp package in
the repository.

However, it might still be necessary to have a default dependency be
FSF-copyright; a quick look suggests that, apart from system libraries
(libc), all the mandatory dependencies of Emacs are indeed FSF-copyright.

Therefore, it might still not be possible to use Flycheck by default (as it
might not be possible to obtain copyright assignment even if the current
maintainers supported it), but there's no reason why it couldn't be
supported at build time, like the various optional C libraries, so that it
could "out of the box", just like support for various image formats.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2530 bytes --]

Re: [PATCH] Flymake support for C/C++

[Dmitry Gutov]

On 10/24/17 1:07 PM, Reuben Thomas wrote:
> we 
> can't get its copyright assigned to the FSF, so we can't include it as 
> part of Emacs.​

Or, to be more accurate, include it as a part of the distribution.

In the tarball, in the .deb packages builds by GNU/Linux distributions, etc.

> I was arguing that it shouldn't be necessary to have an Elisp package in 
> the repository.

I'm not sure who you're arguing against.

> However, it might still be necessary to have a default dependency be 
> FSF-copyright; a quick look suggests that, apart from system libraries 
> (libc), all the mandatory dependencies of Emacs are indeed FSF-copyright.
> 
> Therefore, it might still not be possible to use Flycheck by default (as 
> it might not be possible to obtain copyright assignment even if the 
> current maintainers supported it), but there's no reason why it couldn't 
> be supported at build time, like the various optional C libraries, so 
> that it could "out of the box", just like support for various image formats.

How would it even be used? Will you write an abstraction over Flycheck 
and Flymake that Emacs would integrate with instead?

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

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

On 24 October 2017 at 11:21, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10/24/17 1:07 PM, Reuben Thomas wrote:
>
>> we can't get its copyright assigned to the FSF, so we can't include it as
>> part of Emacs.​
>>
>
> Or, to be more accurate, include it as a part of the distribution.
>
> In the tarball, in the .deb packages builds by GNU/Linux distributions,
> etc.
>
> I was arguing that it shouldn't be necessary to have an Elisp package in
>> the repository.
>>
>
> I'm not sure who you're arguing against.


Currently, we don't have any external Elisp dependencies.​ There's an
assumption that Elisp dependencies must be in the repo and source release.
I'm arguing against that status quo, not anyone in particular.

How would it even be used? Will you write an abstraction over Flycheck and
> Flymake that Emacs would integrate with instead?
>

It could be similar to movemail vs GNU mailutils: if you build against the
latter, you get its mail support out of the box; if you don't, it falls
back to the former.​

I don't think there's a huge need for a common abstraction for Flycheck and
Flymake, as they're largely passive in use: you switch them on and they
work in the background. Certainly, I didn't find I had to migrate a huge
number of settings when I switched from one to the other.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2682 bytes --]

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> Copyright assignment is a different matter:

Indeed.  By policy the Emacs project wants copyright assignments for the
code we distribute.  So in order to include flycheck in Emacs, we'd need
a copyright assignment, and AFAIK this is going to be difficult to get,
so by and large, the discussion to include flycheck ends here.

> It's really the question of where development happens that I'm
> interested in.

Once we decide to include a package, there are indeed many ways we can
do that:
A- just include in the tarball a copy of the code freshly downloaded
   from upstream.
B- keep a local branch tracking upstream and include that in the tarball
C- keep a local branch tracking upstream and publish it in GNU ELPA
D- keep a local copy in emacs.git tracking upstream
E- move upstream into elpa.git
F- move upstream into emacs.git
G- ...

I don't think (A) is a good option because it means distributing code over
which we don't have any control (this said, to some extent that's what
we do with the GNU ELPA version of Org, and indeed, I consider this as
a problem).

(C), (D), (E), and (F) are all common cases.

(B) is something I was hoping we'd be doing for Emacs-26 (well,
actually doing both B and C at the same time), but for some reason this
has not materialized yet.


        Stefan

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I was saying that, just as we do not insist that all our C dependencies be
  > a) installed in Emacs's git repository and b) distributed as part of Emacs
  > source releases, there is no reason in principle why we cannot have
  > external Elisp dependencies, for example Org and CEDET.

Dependencies of Emacs are lower-level programs that Emacs depends on.
They are not specifically for Emacs; other packages use them too.  We
accept general-purpose lower-level dependencies, and we don't have any
reason to distribute them unless we have made a modified version.
(Which we prefer to avoid, except when really necessary.)

Org and CEDET are not dependencies of Emacs.  Rather, they build on
the core of Emacs.

We don't want Emacs to become a mishmash of pieces we distribute and
maintain and pieces we don't distribute and don't maintain.  That
would be untenable.  So we have two ways of dealing with code that
builds on the core of Emacs:

* You distribute it, you're responsible for it, and we don't support
  it, promote it, or worry specifically about it.

* It's part of Emacs, we distribute it as such, and we can fix it when
  need be.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

On 25 October 2017 at 20:30, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I was saying that, just as we do not insist that all our C dependencies be
>   > a) installed in Emacs's git repository and b) distributed as part of Emacs
>   > source releases, there is no reason in principle why we cannot have
>   > external Elisp dependencies, for example Org and CEDET.
>
> Dependencies of Emacs are lower-level programs that Emacs depends on.
> They are not specifically for Emacs; other packages use them too.  We
> accept general-purpose lower-level dependencies, and we don't have any
> reason to distribute them unless we have made a modified version.
> (Which we prefer to avoid, except when really necessary.)
>
> Org and CEDET are not dependencies of Emacs.  Rather, they build on
> the core of Emacs.
>
> We don't want Emacs to become a mishmash of pieces we distribute and
> maintain and pieces we don't distribute and don't maintain.

Do you mean "distribute and don't maintain" rather than "don't
distribute and don't maintain" (as that sounds like the various
ELPAs)?

> So we have two ways of dealing with code that
> builds on the core of Emacs:
>
> * You distribute it, you're responsible for it, and we don't support
>   it, promote it, or worry specifically about it.
>
> * It's part of Emacs, we distribute it as such, and we can fix it when
>   need be.

These are not mutually exclusive, as demonstrated by the various
GNU/Linux distributions that offer some support for packages they do
not maintain: for example, distribution-specific integration, and,
often, bug fixes, either before they get upstream, or that for some
reason are approved by the distribution but not by upstream. This is
often found to be tenable.

In the case of Emacs, there's increasingly a tension: on the one hand,
Emacs is a platform. It has long been a platform for applications,
though applications tended to rot over time as Emacs evolved (because
it's never been as stable as, say, POSIX or X). Now, it's also a
platform for what one might call "distributions", like Spacemacs,
Aquamacs and ErgoEmacs.

At the same time, it is, increasingly, its own distribution. That's
great: there's more functionality built-in to GNU Emacs, and it's
quite distinctive as a distribution (in particular, taking a more
evolutionary and less revolutionary approach than the others I
mentioned). Good in particular for long-term users who are basically
happy with things.

However, it creates a maintenance problem: platform changes must bring
a large amount of application code with them. And, from looking at git
history, patches are often applied to Emacs first, and must presumably
then migrate upstream into their respective projects.

In short, we have the tight coupling of a monolithic project, plus the
disadvantages of a distribution.

It would be good to have a smaller codebase for the Emacs platform,
that does not have to be developed in sync with "distribution"
releases. This would permit improvements to be made to the underlying
system without the same level of heroics (and deep familiarity with a
huge amount of code) that is currently required to keep all the
application code working on top.

This applies not just to Lisp code: at present, it's necessary to
consider non-GNU platforms (in some places, even DOS, a proprietary
platform that has been obsolete for a quarter of a century!). Again,
it would be nice to be able to work more like an OpenSSH developer: in
our case, that means: develop the core platform purely for GNU, and
leave porting it to other platforms as a separate exercise. This also
has the potential to benefit other parts of GNU: for example, rather
than have Windows or macOS-specific functionality in Emacs, where it's
a burden on Emacs maintainers and only benefits Emacs, push it out to
gtk, where it benefits other applications and has many more developers
with a stake in its maintenance.

Emacs works on many systems, but in many cases that is achieved not by
being portable, but by a large amount of system-specific code.
Similarly, Emacs offers an increasingly-impressive array of "out of
the box" functionality, but still with considerable duplication and
dead wood. I do not slight the considerable efforts that have already
been made to improve this at both the platform and application level,
but a great deal more effort is needed to reduce the barriers to both
participation in Emacs development, and to platform-level
improvements.

Re: [PATCH] Flymake support for C/C++

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > We don't want Emacs to become a mishmash of pieces we distribute and
  > > maintain and pieces we don't distribute and don't maintain.

  > Do you mean "distribute and don't maintain" rather than "don't
  > distribute and don't maintain" (as that sounds like the various
  > ELPAs)?

What I meant was what I said, "don't distribute and don't maintain."
People are free to distribute packages that run on Emacs.
It isn't generally any problem for us.  It only leads to a problem
when we want to include it in Emacs and we can't get legal papers.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, João, after a delay.

On Thu, Oct 12, 2017 at 22:24:59 +0100, João Távora wrote:
> Hello again, Alan.

> Alan Mackenzie <acm@muc.de> writes:

> > Yes.  It tightly couples Flymake Mode with CC Mode.  It would render CC
> > Mode non-functional in the absence of Flymake Mode.

> If this your criteria for "tightly coupled", then it does not apply
> here. c--setup-flymake simply adds to a(n abnormal) hook, using
> add-hook, which is designed to be used even if the hook variable isn't
> defined yet.

I've had another look at your proposed cc-flymake.el.  It doesn't use
any CC Mode interfaces or data structures.  It uses lots of flymake
interfaces and data structures.  It has nothing to do with CC Mode's
source files; it is an integral part of flymake, and should be called
something like flymake-cc.el and maintained together with the rest of
flymake.

This was how CC Mode's font locking originally was, before it was
incorporated into the mode.  It was a comparatively simple (but too
simple) assemblage of font lock forms, maintained by the Emacs core
team together with the rest of font-lock in font-lock.el.  It wasn't
until Martin Stjernholm (the previous maintainer of CC Mode)
_integrated_ it into CC Mode's mechanisms that the source for it moved
into CC Mode's source.

cc-flymake.el is like the font locking patterns for CC Mode as they were
~20 years ago.  It has nothing in common with CC Mode.  It is likely to
stay that way for the forseeable future.  Isn't it?

> (There is actually a bit of unglyness in the current patch, in which
> c--setup-flymake also `defvar's and `setq-local's another obsolete
> variable. I could remove that bit and come up with a pure add-hook
> solution.)

> > thus adding to a CC Mode hook.  Major mode hooks are usually not
> > used by Emacs itself, but I'm not aware of any convention which
> > prohibits it.

> Perhaps the example that I gave you is one of the reasons.

> > OK, so f-d-functions could be set in c-mode-common-hook then,
> > couldn't it?

> No, for the reasons that I restate below.

> > I don't understand that last bit.  What's the difference between
> > activation and setup?

> Activation is enabling the minor mode via the flymake-mode
> function. Setup is ensuring that that activation is met with suitable
> circunstances for the correct operation of the minor mode, in this case
> that cc-specific "backends" are set.

So setup is major mode dependant.

> > It would seem then, the activation has nothing to do with the major
> > mode, or else it could be done in a major mode hook.  What am I
> > missing here?

> You are not mistaken that activation has nothing to do with the major
> mode, but you are missing that there are two steps, activation and
> setup, that they differ in the ways I hope to have clarified above.

The activation is done just once per Emacs session, then?  If the user
needed it with CC Mode, then this activation would be a prime use of
c-initialization-hook.

The setup would likewise be a prime use for c-mode-common-hook, or one
of (c-mode-hook, c++-mode-hook, java-mode-hook, ....)

> > "Those two" being activation and setup?

> No sorry, those two being the two hooks that you suggested.

> > What do they need which is in CC Mode?

> They need to hook on to the major mode's function.

Maybe I've lost information over the last few months, but how is
c-mode-common-hook not a suitable way for this to occur.

This is the sort of thing that major mode hooks are for.  They maintain
an arm's length relationship between unrelated parts of Emacs.

> > And how would a new CC Mode hook help?

> That would appease your wish for very loose coupling in that no mention
> of the word "flymake" needed to appear in cc-mode.el

:-).

> > Would you be wanting it to be run before CC Mode is fully
> > initialised?

> Doesn't matter really, before the user's c-mode-common-hook is fine.

Why does it need to be called before c-mode-common-hook rather than from
c-mode-common-hook?

> > "Do one thing and do it well".  Let's not get into the "do it well"
> > bit here, but the "do one thing" is "edit C/C++/... buffers".  Flymake
> > would appear to be distinct from that one thing.

> Ah, I so do agree with you Alan... and let's get not into the million
> ways Emacs is already the kitchen sink. Flymake can be as useful to a
> pretty broad definition of "editing" as font-locking, or imenu, or
> outline.el, or supporting add-log-current-defun-function. All those
> things that really aren't "editing", but help you edit.

As do flyspell, compile mode, trailing space mode (or whatever it's
called), #ifdef mode (or whatever that's properly called), and any
number of other minor modes.  None of them make an appearance in the CC
Mode source code, but are frequently enabled in major mode hooks.
outline.el doesn't either.

Imenu support (in cc-menus.el) isn't really part of CC Mode either, but
is there by tradition.  I once experimented with using CC Mode's
facilities to get better recognition of C++ Mode function names, but it
turned out not to be a good way to go.

> > What does Flymake do, anyway?

> It highlights the bits where you make mistakes as you type, or are about
> to.

OK.

> > There's nothing in the Emacs manual
> > about it, and it's doc string consists purely of boilerplate, at least
> > in Emacs 25.3.

> That is true, but the situation changes considerably, if not immensely,
> in emacs 26 :-). I rewrote Flymake and wrote a fair amount of
> documention. You can read the documentaion in Texinfo format in the
> "Flymake" node (which is separate from the Emacs user manual, for now)
> or just C-h f flymake-mode RET in a recent emacs-26 or master build.

This is good.  But the intro page to the flymake manual still says

    This manual is for GNU Flymake (version 0.3, April 2004)

:-(  That could perhaps use an update.

> > But it should be loosely coupled with major modes, not tightly coupled,
> > surely?

> For sure, we agree. If you analyse the situation I think you'll come to
> the conclusion that it is.

But you're proposing tightening the coupling between flymake and CC
Mode, you're proposing explicitly calling flymake from CC Mode, you're
proposing putting flymake stuff inside the CC Mode source code.  I still
don't see the reason why.  Hooks were designed to allow loose coupling
between unrelated subsystems.  Why can't we use them?

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> cc-flymake.el is like the font locking patterns for CC Mode as they were
> ~20 years ago.  It has nothing in common with CC Mode.  It is likely to
> stay that way for the forseeable future.  Isn't it?

Yes. No problem. Will change to flymake-cc.el

>> Activation is enabling the minor mode via the flymake-mode
>> function. Setup is ensuring that that activation is met with suitable
>> circunstances for the correct operation of the minor mode, in this case
>> that cc-specific "backends" are set.
>
> So setup is major mode dependant.

Yes.

>
>> > It would seem then, the activation has nothing to do with the major
>> > mode, or else it could be done in a major mode hook.  What am I
>> > missing here?
>
>> You are not mistaken that activation has nothing to do with the major
>> mode, but you are missing that there are two steps, activation and
>> setup, that they differ in the ways I hope to have clarified above.
>
> The activation is done just once per Emacs session, then?

No, activation of a minor mode is done once per major-mode call. I.e
everytime you visit a c-mode buffer.

> If the user needed it with CC Mode, then this activation would be a
> prime use of c-initialization-hook.
>
> The setup would likewise be a prime use for c-mode-common-hook, or one
> of (c-mode-hook, c++-mode-hook, java-mode-hook, ....)

No, read below.

>> No sorry, those two being the two hooks that you suggested.
>
>> > What do they need which is in CC Mode?
>
>> They need to hook on to the major mode's function.
>
> Maybe I've lost information over the last few months, but how is
> c-mode-common-hook not a suitable way for this to occur.

Because c-mode-common-hook, AFAIU is where the user places his own hook.
And the user might want to *remove* the flymake-cc-backend from
flymake-diagnostic-functions in that hook.  Or he might want to add his
own backends, in which case he shouldn't have to worry whether that hook
element runs before or after the one that flymake-cc.el would have
placed there.  Or maybe some user with some old configuration does some
`setq' on the hook var, which has always worked, that user would be
surprised that M-x flymake-mode doesn't do what is neighbour's does.

> Why does it need to be called before c-mode-common-hook rather than from
> c-mode-common-hook?

>> Ah, I so do agree with you Alan... and let's get not into the million
>> ways Emacs is already the kitchen sink. Flymake can be as useful to a
>> pretty broad definition of "editing" as font-locking, or imenu, or
>> outline.el, or supporting add-log-current-defun-function. All those
>> things that really aren't "editing", but help you edit.
>
> As do flyspell, compile mode, trailing space mode (or whatever it's
> called), #ifdef mode (or whatever that's properly called), and any
> number of other minor modes.  None of them make an appearance in the CC
> Mode source code, but are frequently enabled in major mode hooks.
> outline.el doesn't either.

I was merely pointing out that a brief "flymake" appearance in
cc-mode.el would hardly be an exception. Of course Emacs has so many
other parts that some of them are bound to not appear in cc-mode :-).

> This is good.  But the intro page to the flymake manual still says
>
>     This manual is for GNU Flymake (version 0.3, April 2004)
>
> :-(  That could perhaps use an update.

Riiiight. Gotta fix that, thanks for reminding me.

> But you're proposing tightening the coupling between flymake and CC
> Mode, you're proposing explicitly calling flymake from CC Mode, you're
> proposing putting flymake stuff inside the CC Mode source code.

Now come on! :-) I propose a line that adds a symbol to a hook,
something that will never break if flymake disappears, or is redesigned
to become a specialized brocolli cooker instead.  And I've already
agreed to call the file something else that doesn't interfere with the
cc-*.el file-naming-space.

> I still don't see the reason why.  Hooks were designed to allow loose
> coupling between unrelated subsystems.  Why can't we use them?

We can, but I believe c-mode-common-hook in particular should be a
pristine nil after Emacs -Q.  Perhaps I am mistaken and it's not that
common a practice, but all the major modes flymake has entered in have
followed the same guideline.

Take care,
João

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

>> As do flyspell, compile mode, trailing space mode (or whatever it's
>> called), #ifdef mode (or whatever that's properly called), and any
>> number of other minor modes.  None of them make an appearance in the CC
>> Mode source code, but are frequently enabled in major mode hooks.
>> outline.el doesn't either.
>
> I was merely pointing out that a brief "flymake" appearance in
> cc-mode.el would hardly be an exception. Of course Emacs has so many
> other parts that some of them are bound to not appear in cc-mode :-).

Also note that most of those that don't appear in cc-mode are modes
which don't really need to be tweaked based on the buffer's language.

> We can, but I believe c-mode-common-hook in particular should be a
> pristine nil after Emacs -Q.

Agreed.

> Perhaps I am mistaken and it's not that common a practice, but all the
> major modes flymake has entered in have followed the same guideline.

CC-mode is not just another major mode ;-)


        Stefan

Re: [PATCH] Flymake support for C/C++

[Rolf Ade]

Stefan Monnier writes:
> CC-mode is not just another major mode ;-)

But?

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, João

On Fri, Jun 01, 2018 at 22:54:53 +0100, João Távora wrote:

> Alan Mackenzie <acm@muc.de> writes:

> > cc-flymake.el is like the font locking patterns for CC Mode as they were
> > ~20 years ago.  It has nothing in common with CC Mode.  It is likely to
> > stay that way for the forseeable future.  Isn't it?

> Yes. No problem. Will change to flymake-cc.el

And take all the symbol names out of CC Mode's namespace, please?

> >> Activation is enabling the minor mode via the flymake-mode
> >> function. Setup is ensuring that that activation is met with suitable
> >> circunstances for the correct operation of the minor mode, in this case
> >> that cc-specific "backends" are set.

> > So setup is major mode dependant.

> Yes.


> >> > It would seem then, the activation has nothing to do with the major
> >> > mode, or else it could be done in a major mode hook.  What am I
> >> > missing here?

> >> You are not mistaken that activation has nothing to do with the major
> >> mode, but you are missing that there are two steps, activation and
> >> setup, that they differ in the ways I hope to have clarified above.

> > The activation is done just once per Emacs session, then?

> No, activation of a minor mode is done once per major-mode call. I.e
> everytime you visit a c-mode buffer.

And the setup is also done once per major mode call.  At the moment I
can't see why these are distinct.  I'll try reading some earlier posts
again, maybe this will help.

> > If the user needed it with CC Mode, then this activation would be a
> > prime use of c-initialization-hook.

> > The setup would likewise be a prime use for c-mode-common-hook, or one
> > of (c-mode-hook, c++-mode-hook, java-mode-hook, ....)

> No, read below.

> >> No sorry, those two being the two hooks that you suggested.

> >> > What do they need which is in CC Mode?

> >> They need to hook on to the major mode's function.

> > Maybe I've lost information over the last few months, but how is
> > c-mode-common-hook not a suitable way for this to occur.

> Because c-mode-common-hook, AFAIU is where the user places his own hook.
> And the user might want to *remove* the flymake-cc-backend from
> flymake-diagnostic-functions in that hook.  Or he might want to add his
> own backends, in which case he shouldn't have to worry whether that hook
> element runs before or after the one that flymake-cc.el would have
> placed there.

The flymake hook which would be put into c-mode-common-hook should be
designed such that it doesn't matter whether it is executed before or
after the user's other hook functions.  A user doing something like
removing something from flymake-diagnostic-functions will surely be doing
this in flymake-mode-hook, no?

> Or maybe some user with some old configuration does some `setq' on the
> hook var, which has always worked, that user would be surprised that
> M-x flymake-mode doesn't do what his neighbour's does.

Hook variables get changed with add-hook and remove-hook.  Anybody using
setq for this has problems anyway.

[ .... ]

> I was merely pointing out that a brief "flymake" appearance in
> cc-mode.el would hardly be an exception. Of course Emacs has so many
> other parts that some of them are bound to not appear in cc-mode :-).

Calling flymake directly from C Mode would very much be an exception.
This would go against the fundamental architecture of Emacs.

[ .... ]

> > But you're proposing tightening the coupling between flymake and CC
> > Mode, you're proposing explicitly calling flymake from CC Mode, you're
> > proposing putting flymake stuff inside the CC Mode source code.

> Now come on! :-) I propose a line that adds a symbol to a hook,
> something that will never break if flymake disappears, or is redesigned
> to become a specialized brocolli cooker instead.  And I've already
> agreed to call the file something else that doesn't interfere with the
> cc-*.el file-naming-space.

CC Mode doesn't have, and shouldn't have direct interfaces with brocolli
cookers.  Cooks should use hooks.

And just a small point, your proposed patch is lacking clauses like

   (if (boundp 'flymake-diagnostic-functions) ....)

to check that flymake mode actually exists, and an assignment to it won't
throw an error if it doesn't exist.

> > I still don't see the reason why.  Hooks were designed to allow loose
> > coupling between unrelated subsystems.  Why can't we use them?

> We can, but I believe c-mode-common-hook in particular should be a
> pristine nil after Emacs -Q.  Perhaps I am mistaken and it's not that
> common a practice, but all the major modes flymake has entered in have
> followed the same guideline.

c-mode-common-hook should, indeed must, be nil on Emacs -Q.  And flymake
mode must equally remain disabled until explicitly enabled (e.g. by a
user customisation).  The whole point of -Q is to get an uncustomised
vanilla Emacs.

> Take care,
> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> And the setup is also done once per major mode call.  At the moment I
> can't see why these are distinct.

(setq font-lock-keywords ...) is part of font-lock's setup, whereas
(font-lock-mode 1) is part of activation.

They both needed to be executed "once per major mode call", yet
they're separate because they're not expected to be written by the same
person: one is a choice of the user, the other requires technical
knowledge which the mode's maintainer is more likely to have.

>> I was merely pointing out that a brief "flymake" appearance in
>> cc-mode.el would hardly be an exception. Of course Emacs has so many
>> other parts that some of them are bound to not appear in cc-mode :-).
> Calling flymake directly from C Mode would very much be an exception.
> This would go against the fundamental architecture of Emacs.

AFAICT the code he suggests does not make CC-mode call flymake.
It just sets a variable telling flymake how to do its job if/when it
gets enabled.

> And just a small point, your proposed patch is lacking clauses like
>
>    (if (boundp 'flymake-diagnostic-functions) ....)
>
> to check that flymake mode actually exists, and an assignment to it won't
> throw an error if it doesn't exist.

add-hook works just fine on an unbound variable, so there's no need for
such an `if` test.

> c-mode-common-hook should, indeed must, be nil on Emacs -Q.  And flymake
> mode must equally remain disabled until explicitly enabled (e.g. by a
> user customisation).  The whole point of -Q is to get an uncustomised
> vanilla Emacs.

Define "uncustomized": should M-x flymake-mode RET in a c-mode buffer
have a reasonable default behavior, like it does in an elisp-mode
buffer?


        Stefan

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> I must admit not to being too keen on CC Mode changing like this; it
> would spoil the unity of purpose of the mode.  I've glanced through the

What is "the unity of purpose of" CC-mode?

From where I stand, your position on this patch amounts to saying "I
don't want to make it easier for users of CC-mode to use flymake-mode".

Yet AFAIK the purpose of CC-mode is to help users of C-like languages
make the best use of Emacs.

I'm having trouble reconciling those different statements into
a coherent whole.


        Stefan

Re: [PATCH] Flymake support for C/C++

[Stefan Monnier]

> I've had another look at your proposed cc-flymake.el.  It doesn't use
> any CC Mode interfaces or data structures.  It uses lots of flymake
> interfaces and data structures.  It has nothing to do with CC Mode's
> source files; it is an integral part of flymake, and should be called
> something like flymake-cc.el and maintained together with the rest of
> flymake.

I agree that it's not specific to CC-mode.

It should also work for several languages not supported by CC-mode,
for example.  Maybe it'd be better to think of it as "flymake support
for GNU tools" (e.g. it relies on the GNU Coding Standard format of
error/warning messages).

But I think that the part of the code which tells flymake to use
this "flymake for GNU tools" code does belong with c-mode.

> Imenu support (in cc-menus.el) isn't really part of CC Mode either, but
> is there by tradition.

That makes it sound like you'd rather remove imenu support from CC-mode.
I think that would be a disservice to (y)our users.
For the same reason I think cc-mode should incorporate something like

    (add-hook 'flymake-diagnostic-functions #'flymake-cc nil t)

in its code.  Just as is the case for Imenu code, you (as maintainer of
CC-mode) don't really have to actively support the code, you just accept
to keep it under your roof as long as it doesn't misbehave.


        Stefan

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

>> Yes. No problem. Will change to flymake-cc.el
> And take all the symbol names out of CC Mode's namespace, please?

Yes, certainly.

> And the setup is also done once per major mode call.  At the moment I
> can't see why these are distinct.  I'll try reading some earlier posts
> again, maybe this will help.

I think Stefan provided a fine example with font-lock.

> The flymake hook which would be put into c-mode-common-hook should be
> designed such that it doesn't matter whether it is executed before or
> after the user's other hook functions.  A user doing something like
> removing something from flymake-diagnostic-functions will surely be doing
> this in flymake-mode-hook, no?

The "hook" put into the hook is a lisp expression, right? Well it
happens that this lisp expression is itself adding something to another,
completely different hook. And when adding things to hooks, order
matters. There is currently no (practival) way to say "add this to the
beginning of a hook so that, no matter what the user or other libraries
do, it is always the first element".

> Hook variables get changed with add-hook and remove-hook.  Anybody using
> setq for this has problems anyway.

I agree. But I'd rather not be the one introducing problems for these
poor souls.

> Calling flymake directly from C Mode would very much be an exception.
> This would go against the fundamental architecture of Emacs.

I agree. But we're not calling into it in any way.

> Cooks should use hooks.

You should thank me for setting you up such a fine maxim :-)

> And just a small point, your proposed patch is lacking clauses like
>    (if (boundp 'flymake-diagnostic-functions) ....)
> to check that flymake mode actually exists, and an assignment to it won't
> throw an error if it doesn't exist.

The boundp call is *not* needed at all. And perhaps this is the source
of our misunderstanding: `add-hook' is especially designed to throw
these errors and to work before or after the hook variable is defined.

So, forgoing my beloved broccoli metaphor:

   (add-hook 'flymake-diagnostic-functions 'flymake-whatever nil t)

to any major-mode in emacs and not break the call to that mode
function. It's only when flymake-mode starts in that buffer that we'll
see its effects.  The dependency is in fact the reverse. It's flymake
that is now susceptible to any mishandling of that line in cc-mode.el

> c-mode-common-hook should, indeed must, be nil on Emacs -Q.  And flymake
> mode must equally remain disabled until explicitly enabled (e.g. by a
> user customisation).  The whole point of -Q is to get an uncustomised
> vanilla Emacs.

In this last-paragraph, we are violent agreement, word for word. 

Let's summarize. I'd to make it so that:

  Emacs -Q
  visit a .c file
  M-x flymake-mode

starts Flymake suitably in that buffer. For this I'd need to add this
line:

  (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)

to a common point in cc-mode.el. That is, in my humble opinion, the
simplest alternative, and the one I've taken with all other major modes.

Alternatively, I can add to a hook that (a) does *not* need to be nil on
Emacs -Q and (b) is run once every time a buffer is put into the major
mode cc-mode, after kill-all-local-variables.  As it seems,
c-common-mode-hook fits (b) but not (a). So I ask if there is any such
hook in cc-model.el that fits both (a) and (b)?

I see `c-initialization-hook'. I see it run from c-initialize-cc-mode,
but not unconditionally. I cannot parse the exact conditions when it
runs, but perhaps you can. Does it fit (b) and/or (a)?

João

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jun 02, 2018 at 11:26:54 -0400, Stefan Monnier wrote:
> > I must admit not to being too keen on CC Mode changing like this; it
> > would spoil the unity of purpose of the mode.  I've glanced through the

> What is "the unity of purpose of" CC-mode?

That feels like a rhetorical question.  It's dealt with in standard
software engineering texts.

I think it's also clear.  If it's not, to anybody, it's probably not that
important.

> >>From where I stand, your position on this patch amounts to saying "I
> don't want to make it easier for users of CC-mode to use flymake-mode".

That's indeed the case, with empasis on the "I".  I've got enough other
things to do that I don't want to spend time contributing to
flymake-mode.  But I've got nothing against João or anybody else, doing
so.

However, I'm concerned to get the optimum interface between CC Mode and
flymake-mode, and right at the moment that would appear to be none
whatsoever.

> Yet AFAIK the purpose of CC-mode is to help users of C-like languages
> make the best use of Emacs.

CC Mode in concert with all the other facilities of Emacs.  CC Mode
doesn't include Cedet, trailing-space facilities, movement between
matching parentheses, font-locking infrastructure, redisplay
infrastructure, or any of the many other Emacs features useful with or
necessary to C(etc.) Mode.  Nor should it.  One of these other features
is flymake mode.  It shouldn't be included in CC Mode either.

> I'm having trouble reconciling those different statements into
> a coherent whole.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, João.

On Sat, Jun 02, 2018 at 19:13:59 +0100, João Távora wrote:

> Alan Mackenzie <acm@muc.de> writes:

> >> Yes. No problem. Will change to flymake-cc.el
> > And take all the symbol names out of CC Mode's namespace, please?

> Yes, certainly.

Thanks!

> > And the setup is also done once per major mode call.  At the moment I
> > can't see why these are distinct.  I'll try reading some earlier posts
> > again, maybe this will help.

> I think Stefan provided a fine example with font-lock.

Yes.  That was helpful.  Thanks, Stefan!

> > The flymake hook which would be put into c-mode-common-hook should be
> > designed such that it doesn't matter whether it is executed before or
> > after the user's other hook functions.  A user doing something like
> > removing something from flymake-diagnostic-functions will surely be doing
> > this in flymake-mode-hook, no?

> The "hook" put into the hook is a lisp expression, right? Well it
> happens that this lisp expression is itself adding something to another,
> completely different hook. And when adding things to hooks, order
> matters. There is currently no (practival) way to say "add this to the
> beginning of a hook so that, no matter what the user or other libraries
> do, it is always the first element".

> > Hook variables get changed with add-hook and remove-hook.  Anybody using
> > setq for this has problems anyway.

> I agree. But I'd rather not be the one introducing problems for these
> poor souls.

Fair enough!

> > Calling flymake directly from C Mode would very much be an exception.
> > This would go against the fundamental architecture of Emacs.

> I agree. But we're not calling into it in any way.

> > Cooks should use hooks.

> You should thank me for setting you up such a fine maxim :-)

Indeed!  Thanks for being my "straight man".  :-)

> > And just a small point, your proposed patch is lacking clauses like
> >    (if (boundp 'flymake-diagnostic-functions) ....)
> > to check that flymake mode actually exists, and an assignment to it won't
> > throw an error if it doesn't exist.

> The boundp call is *not* needed at all. And perhaps this is the source
> of our misunderstanding: `add-hook' is especially designed to throw
> these errors and to work before or after the hook variable is defined.

OK.  But a little way down there's a

    (setq-local flymake-proc-allowed-file-name-masks nil)

, which will create a buffer-local free variable if the variable doesn't
already exist.  This is somewhat untidy.  Not so important, either.

> So, forgoing my beloved broccoli metaphor:

>    (add-hook 'flymake-diagnostic-functions 'flymake-whatever nil t)

> to any major-mode in emacs and not break the call to that mode
> function. It's only when flymake-mode starts in that buffer that we'll
> see its effects.  The dependency is in fact the reverse. It's flymake
> that is now susceptible to any mishandling of that line in cc-mode.el

I think I now understand things better.  CC Mode deals with the syntax
(and, to a limited extent, the semantics) of C, C++, Java, .....
flycheck Mode deals with the embedding of the C, C++, ... build systems
in their environment - things like the compiler used, a command line to
activate parsing of the source, the parsing of its error output, things
like this.

There is NOTHING in common between these two realms, beyond the identity
of the major mode.  There is no other useful information CC Mode can
pass to flymake-mode.  But the major mode is a property of the buffer,
and thus not info that CC Mode can usefully supply.

There is nothing CC Mode can tell flymake-mode in any function call.
Looking at the proposed patch, the arguments passed over in
c--setup-flymake are flymake details, not CC Mode details.

Surely the same applies to all the other major modes with flymake
support.  Looking at elisp.el and perl.el, for example, and the proposed
CC Mode patch, there would seem to be a generic similarity between the
flymake bits in all of them.  This smells of code duplication, which, if
I'm right, is not a Good Thing.  These flymake pieces have much more to
do with eachother than with the major modes they're embedded in.

How about putting all these details in an alist in flymake-mode.el, the
key being the major mode?  That might then enable you to combine
cc-flymake and perl-flymake, etc., into a single function/macro with
more arguments than the current functions take, thus condensing the code
and making it easier to maintain.

> > c-mode-common-hook should, indeed must, be nil on Emacs -Q.  And flymake
> > mode must equally remain disabled until explicitly enabled (e.g. by a
> > user customisation).  The whole point of -Q is to get an uncustomised
> > vanilla Emacs.

> In this last-paragraph, we are in violent agreement, word for word. 

Excellent!

> Let's summarize. I'd to make it so that:

>   Emacs -Q
>   visit a .c file
>   M-x flymake-mode

> starts Flymake suitably in that buffer.  For this I'd need to add this
> line:

>   (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)

> to a common point in cc-mode.el. That is, in my humble opinion, the
> simplest alternative, and the one I've taken with all other major modes.

As I suggested above, why not simply build that information into
flymake.el at build (or customisation) time without troubling CC Mode at
all?

> Alternatively, I can add to a hook that (a) does *not* need to be nil on
> Emacs -Q and (b) is run once every time a buffer is put into the major
> mode cc-mode, after kill-all-local-variables.  As it seems,
> c-common-mode-hook fits (b) but not (a). So I ask if there is any such
> hook in cc-model.el that fits both (a) and (b)?

> I see `c-initialization-hook'. I see it run from c-initialize-cc-mode,
> but not unconditionally. I cannot parse the exact conditions when it
> runs, but perhaps you can. Does it fit (b) and/or (a)?

c-initialization-hook is run exactly once, when CC Mode itself is
loaded.  Maybe this could be useful here.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hello Alan,

Alan Mackenzie <acm@muc.de> writes:

> OK.  But a little way down there's a
>     (setq-local flymake-proc-allowed-file-name-masks nil)
> , which will create a buffer-local free variable if the variable doesn't
> already exist.  This is somewhat untidy.  Not so important, either.

Very much so. I will remove this line, it's not needed.

> How about putting all these details in an alist in flymake-mode.el,
> the key being the major-mode

That's something that flymake-mode.el had *before* the Emacs 26.1
redesign.  It's a natural approach when a package lives outside Emacs,
but obviously, suffers from the big drawback that flymake-mode.el itself
must be changed everytime a major-mode is added to Emacs, or to GNU
ELPA, or anywhere in the emacs ecosphere.

>>   (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)
>
> As I suggested above, why not simply build that information into
> flymake.el at build (or customisation) time without troubling CC Mode at
> all?

No, for the reasons detailed above. As it stands, I propose to add that
single to cc-mode.el.  As argued already:

1. it is much shorter than, say cc-mode's configuration of imenu, or
font-lock

2. in contrast to those two, because it uses add-hook, it will never
break or error even if flymake-mode.el is removed, reworked, etc..

> c-initialization-hook is run exactly once, when CC Mode itself is
> loaded.  Maybe this could be useful here.

Unfortunately, it doesn't meet criteria (b), so I can't use it.

João

Re: [PATCH] Flymake support for C/C++

[Alan Mackenzie]

Hello, João.

On Sun, Jun 03, 2018 at 17:28:20 +0100, João Távora wrote:
> Hello Alan,

> Alan Mackenzie <acm@muc.de> writes:

> > OK.  But a little way down there's a
> >     (setq-local flymake-proc-allowed-file-name-masks nil)
> > , which will create a buffer-local free variable if the variable doesn't
> > already exist.  This is somewhat untidy.  Not so important, either.

> Very much so. I will remove this line, it's not needed.

Thanks

> > How about putting all these details in an alist in flymake-mode.el,
> > the key being the major-mode

> That's something that flymake-mode.el had *before* the Emacs 26.1
> redesign.  It's a natural approach when a package lives outside Emacs,
> but obviously, suffers from the big drawback that flymake-mode.el itself
> must be changed everytime a major-mode is added to Emacs, or to GNU
> ELPA, or anywhere in the emacs ecosphere.

I suppose so.

> >>   (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)

> > As I suggested above, why not simply build that information into
> > flymake.el at build (or customisation) time without troubling CC Mode at
> > all?

> No, for the reasons detailed above. As it stands, I propose to add that
> single to cc-mode.el.

Oh, OK.  I suppose we've spent enough time arguing it out.  So feel free
to add that line to the c-mode code.  You'll probably want to add a
similar line to c++-mode, and possibly to the other modes, too, maybe
some time in the future.  I'll copy it into the standalone CC Mode, too,
sometime.

> As argued already:

> 1. it is much shorter than, say cc-mode's configuration of imenu, or
> font-lock

Well, font-lock is an essential part of CC Mode, but I take the point
about imenu.

> 2. in contrast to those two, because it uses add-hook, it will never
> break or error even if flymake-mode.el is removed, reworked, etc..

OK.

> > c-initialization-hook is run exactly once, when CC Mode itself is
> > loaded.  Maybe this could be useful here.

> Unfortunately, it doesn't meet criteria (b), so I can't use it.

Fine.  I think we're agreed.  Yes?

Have a good evening!

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Flymake support for C/C++

[João Távora]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> Oh, OK.  I suppose we've spent enough time arguing it out.  So feel free
> to add that line to the c-mode code.  You'll probably want to add a
> similar line to c++-mode, and possibly to the other modes, too, maybe
> some time in the future.  I'll copy it into the standalone CC Mode, too,
> sometime.

Alright!

>> Unfortunately, it doesn't meet criteria (b), so I can't use it.
>
> Fine.  I think we're agreed.  Yes?

Very much so!  From my part, it's been entertaining.  Thanks for
listening so attentively.

Have a very good evening,
João