Include modern-cpp-font-lock into GNU Emacs

Include modern-cpp-font-lock into GNU Emacs

[Ludwig PACIFICI]

Hello emacs-devel

After a reddit post[1], I'd like to discuss with you the possibility to 
integrate modern-cpp-font-lock into GNU Emacs.

modern-cpp-font-lock[2] is a font lock improvement for recent version of 
C++ - so far, up to C++17. It can be seen as an add-on of the c++-mode 
(part of CC Mode).

I published this package to improve the C++ support in Emacs. The 
release cycle of C++ and Emacs are slow. Especially if not in synced, it 
can lead to a long time with lack of support for the language. Melpa[3] 
is a good place to release modern-cpp-font-lock, because it enables 
quicker release cycles.

Let me know what are your opinions.

Best regards
Ludwig

[1]: 
https://www.reddit.com/r/emacs/comments/94j39z/modern_c_font_lock_in_emacs/
[2]: https://github.com/ludwigpacifici/modern-cpp-font-lock
[3]: https://melpa.org/#/modern-cpp-font-lock

Re: Include modern-cpp-font-lock into GNU Emacs

[Alan Mackenzie]

Hello, Ludwig.

On Mon, Aug 06, 2018 at 21:24:51 +0100, Ludwig PACIFICI wrote:
> Hello emacs-devel

> After a reddit post[1], I'd like to discuss with you the possibility to 
> integrate modern-cpp-font-lock into GNU Emacs.

> modern-cpp-font-lock[2] is a font lock improvement for recent version of 
> C++ - so far, up to C++17. It can be seen as an add-on of the c++-mode 
> (part of CC Mode).

In what respects is this package an improvement over the fontification
in standard C++ Mode?

> I published this package to improve the C++ support in Emacs. The 
> release cycle of C++ and Emacs are slow. Especially if not in synced, it 
> can lead to a long time with lack of support for the language. Melpa[3] 
> is a good place to release modern-cpp-font-lock, because it enables 
> quicker release cycles.

I've briefly skimmed modern-cpp-font-lock.el.  It seems there is a _lot_
of duplication with C++ Mode - m-c-f-l attempts to fontify all C++
keywords, even though nearly all will be already fontified by C++ Mode;
raw strings are now handled by C++ Mode; nullptr, false, true are also
handled by C++ Mode; and so on.

Do you have an up to date diff betweeen m-c-f-l.el and C++ Mode - things
that m-c-f-l handles, but C++ Mode doesn't?  I suspect that difference
will be small to medium, rather than large.

> Let me know what are your opinions.

I think I would prefer to integrate missing font locking into CC Mode,
rather than introducing a new ad-hoc package which doesn't fit well with
CC Mode.  But I do accept your comment about the rate of release of C++
Mode.

> Best regards
> Ludwig

> [1]: 
> https://www.reddit.com/r/emacs/comments/94j39z/modern_c_font_lock_in_emacs/
> [2]: https://github.com/ludwigpacifici/modern-cpp-font-lock
> [3]: https://melpa.org/#/modern-cpp-font-lock

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Include modern-cpp-font-lock into GNU Emacs

[Stefan Monnier]

> But I do accept your comment about the rate of release of C++ Mode.

I think it would be very easy to make elpa.gnu.org automatically
generate GNU ELPA packages from the code in emacs.git's master branch,
so as to make changes available before the next Emacs release.

Should I try and set it up?


        Stefan

Re: Include modern-cpp-font-lock into GNU Emacs

[Ludwig PACIFICI]

Hello Alan,

Thank you for your reply.

> In what respects is this package an improvement over the fontification
> in standard C++ Mode?

About two years ago, when I was writing C++ programs, I wanted to have a 
quick fix for the missing fontification. It is not an improvement from 
standard C++ mode, but a quicker way to get the font lock up to date.

> Do you have an up to date diff betweeen m-c-f-l.el and C++ Mode - things
> that m-c-f-l handles, but C++ Mode doesn't?

No. In my opinion, I should do that diff, and, if any, contact you via 
cc-mode project to reduce the gap?

> I think I would prefer to integrate missing font locking into CC Mode,
> rather than introducing a new ad-hoc package which doesn't fit well with
> CC Mode.  But I do accept your comment about the rate of release of C++
> Mode.

I believe the issue is broader than m-c-f-l and cc-mode. The difference 
between an Emacs release cycle (where Emacs provides a built-in support 
for some languages, like cc-mode, python, ruby-mode, etc.) and the 
release cycle of a language can lead to a long delay to get things right 
(such as font locking). Having the language support delivered via a 
package manager makes the updates less dependent of release cycles.

Ludwig

Re: Include modern-cpp-font-lock into GNU Emacs

[Stefan Monnier]

> I believe the issue is broader than m-c-f-l and cc-mode. The difference
> between an Emacs release cycle (where Emacs provides a built-in support for
> some languages, like cc-mode, python, ruby-mode, etc.) and the release cycle
> of a language can lead to a long delay to get things right (such as font
> locking). Having the language support delivered via a package manager makes
> the updates less dependent of release cycles.

So, distributing CC-mode as a GNU ELPA package (like we already do for
python.el, org-mode, and a few other bundled packages) would solve this
problem, right?


        Stefan

Re: Include modern-cpp-font-lock into GNU Emacs

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

  > So, distributing CC-mode as a GNU ELPA package (like we already do for
  > python.el, org-mode, and a few other bundled packages) would solve this
  > problem, right?

The Emacs release needs to include CC-mode.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Include modern-cpp-font-lock into GNU Emacs

[Andy Moreton]

On Sun 19 Aug 2018, Richard Stallman 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. ]]]
>
>   > So, distributing CC-mode as a GNU ELPA package (like we already do for
>   > python.el, org-mode, and a few other bundled packages) would solve this
>   > problem, right?
>
> The Emacs release needs to include CC-mode.

Releasing an ELPA package in addition to the built-in version allows
users an easy way to upgrade their emacs installation to use a newer
version of CC mode without having to wait for the next emacs release.

    AndyM

Re: Include modern-cpp-font-lock into GNU Emacs

[Jostein Kjønigsen]

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


On Mon, Aug 20, 2018, at 10:38 AM, Andy Moreton wrote:
> On Sun 19 Aug 2018, Richard Stallman 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. ]]]>> 
>> > So, distributing CC-mode as a GNU ELPA package (like we already
>> > do for>> > python.el, org-mode, and a few other bundled packages) would
>> > solve this>> > problem, right?
>> 
>> The Emacs release needs to include CC-mode.
> 
> Releasing an ELPA package in addition to the built-in version allows
> users an easy way to upgrade their emacs installation to use a newer
> version of CC mode without having to wait for the next emacs release.> 
>     AndyM
> 
> 

As I've mentioned in another reply on this subject, decoupling cc-mode
releases from Emacs-releases will make it harder for third-party major-
modes deriving from cc-mode to maintain compatibility when cc-mode
introduces breaking changes.
Currently we can inspect "cc-mode version" by checking emacs-version,
and dispatching compatible code based on that.
With such a decoupling, this will no longer be possible, and we should
find a new way to give third-party major-modes dependant on cc-mode to
ensure compatibility.
Maybe cc-mode should ship with its own programmatically accessible version-
number to check against?
--
Regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net




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

Re: Include modern-cpp-font-lock into GNU Emacs

[Noam Postavsky]

On 20 August 2018 at 05:28, Jostein Kjønigsen
<jostein@secure.kjonigsen.net> wrote:

> Currently we can inspect "cc-mode version" by checking emacs-version, and
> dispatching compatible code based on that.
>
> With such a decoupling, this will no longer be possible, and we should find
> a new way to give third-party major-modes dependant on cc-mode to ensure
> compatibility.
>
> Maybe cc-mode should ship with its own programmatically accessible
> version-number to check against?

I think this already exists:

c-version is a variable defined in ‘cc-defs.el’.
Its value is "5.33.1"

  This variable may be risky if used as a file-local variable.

Documentation:
CC Mode version number.

Re: Include modern-cpp-font-lock into GNU Emacs

[Andy Moreton]

On Mon 20 Aug 2018, Jostein Kjønigsen wrote:
> As I've mentioned in another reply on this subject, decoupling cc-mode
> releases from Emacs-releases will make it harder for third-party major-
> modes deriving from cc-mode to maintain compatibility when cc-mode
> introduces breaking changes.
> Currently we can inspect "cc-mode version" by checking emacs-version,
> and dispatching compatible code based on that.

Checking version numbers is the wrong approach for feature detection,
and should only be a last resort if checking behaviour is not practical.

If an ELPA package results in more frequent updates to cc-mode then
third party extension authors will simply have to adapt to a slightly
faster release cadence.

    AndyM

Re: Include modern-cpp-font-lock into GNU Emacs

[Jostein Kjønigsen]

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

On Mon, Aug 20, 2018, at 1:28 PM, Andy Moreton wrote:
> On Mon 20 Aug 2018, Jostein Kjønigsen wrote:
>> As I've mentioned in another reply on this subject, decoupling
>> cc-mode>> releases from Emacs-releases will make it harder for third-party major->> modes deriving from cc-mode to maintain compatibility when cc-mode
>> introduces breaking changes.
>> Currently we can inspect "cc-mode version" by checking emacs-version,>> and dispatching compatible code based on that.
> 
> Checking version numbers is the wrong approach for feature detection,> and should only be a last resort if checking behaviour is not
> practical.> 
> If an ELPA package results in more frequent updates to cc-mode then
> third party extension authors will simply have to adapt to a slightly> faster release cadence.
> 
>     AndyM
> 

Agreed, but (to my knowledge) Emacs lacks proper introspection
capacities, and there's no way up front to know if  a function requires
3 or 5 parameters until you've called it and your code has crashed.
Compared to that, verifying version numbers against known points of
change seem like a much better strategy. It is also the advice I've
received from other people around in the Emacs-community.
--
Regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net




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

Re: Include modern-cpp-font-lock into GNU Emacs

[Michael Albinus]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> Agreed, but (to my knowledge) Emacs lacks proper introspection
> capacities, and there's no way up front to know if  a function
> requires 3 or 5 parameters until you've called it and your code has
> crashed.

--8<---------------cut here---------------start------------->8---
(defun my-executable-find (command &optional remote)
  "Run `executable-find', and ignore optional REMOTE on older Emacsen."
  (condition-case err
      (executable-find command remote)
    (wrong-number-of-arguments (executable-find command))
    (error (signal (car err) (cdr err)))))
--8<---------------cut here---------------end--------------->8---

> Regards
> Jostein Kjønigsen

Best regards, Michael.

Re: Include modern-cpp-font-lock into GNU Emacs

[Noam Postavsky]

On 20 August 2018 at 15:45, Michael Albinus <michael.albinus@gmx.de> wrote:

> (defun my-executable-find (command &optional remote)
>   "Run `executable-find', and ignore optional REMOTE on older Emacsen."
>   (condition-case err
>       (executable-find command remote)
>     (wrong-number-of-arguments (executable-find command))
>     (error (signal (car err) (cdr err)))))

The last line can be dropped: if you don't handle the error type, it
will already propagate upward so there is no need to catch and
re-signal.