all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Include modern-cpp-font-lock into GNU Emacs
@ 2018-08-06 20:24 Ludwig PACIFICI
  2018-08-11 14:51 ` Alan Mackenzie
  0 siblings, 1 reply; 13+ messages in thread
From: Ludwig PACIFICI @ 2018-08-06 20:24 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-06 20:24 Include modern-cpp-font-lock into GNU Emacs Ludwig PACIFICI
@ 2018-08-11 14:51 ` Alan Mackenzie
  2018-08-12  0:22   ` Stefan Monnier
  2018-08-19 11:16   ` Ludwig PACIFICI
  0 siblings, 2 replies; 13+ messages in thread
From: Alan Mackenzie @ 2018-08-11 14:51 UTC (permalink / raw)
  To: Ludwig PACIFICI; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-11 14:51 ` Alan Mackenzie
@ 2018-08-12  0:22   ` Stefan Monnier
  2018-08-19 11:16   ` Ludwig PACIFICI
  1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2018-08-12  0:22 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-11 14:51 ` Alan Mackenzie
  2018-08-12  0:22   ` Stefan Monnier
@ 2018-08-19 11:16   ` Ludwig PACIFICI
  2018-08-19 12:31     ` Stefan Monnier
  1 sibling, 1 reply; 13+ messages in thread
From: Ludwig PACIFICI @ 2018-08-19 11:16 UTC (permalink / raw)
  To: acm; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-19 11:16   ` Ludwig PACIFICI
@ 2018-08-19 12:31     ` Stefan Monnier
  2018-08-20  3:03       ` Richard Stallman
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2018-08-19 12:31 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-19 12:31     ` Stefan Monnier
@ 2018-08-20  3:03       ` Richard Stallman
  2018-08-20  8:38         ` Andy Moreton
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2018-08-20  3:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[[[ 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)





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20  3:03       ` Richard Stallman
@ 2018-08-20  8:38         ` Andy Moreton
  2018-08-20  9:28           ` Jostein Kjønigsen
  0 siblings, 1 reply; 13+ messages in thread
From: Andy Moreton @ 2018-08-20  8:38 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20  8:38         ` Andy Moreton
@ 2018-08-20  9:28           ` Jostein Kjønigsen
  2018-08-20 10:51             ` Noam Postavsky
  2018-08-20 11:28             ` Andy Moreton
  0 siblings, 2 replies; 13+ messages in thread
From: Jostein Kjønigsen @ 2018-08-20  9:28 UTC (permalink / raw)
  To: Andy Moreton, emacs-devel; +Cc: Alan Mackenzie

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20  9:28           ` Jostein Kjønigsen
@ 2018-08-20 10:51             ` Noam Postavsky
  2018-08-20 11:28             ` Andy Moreton
  1 sibling, 0 replies; 13+ messages in thread
From: Noam Postavsky @ 2018-08-20 10:51 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: Alan Mackenzie, Andy Moreton, Emacs developers

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20  9:28           ` Jostein Kjønigsen
  2018-08-20 10:51             ` Noam Postavsky
@ 2018-08-20 11:28             ` Andy Moreton
  2018-08-20 17:54               ` Jostein Kjønigsen
  1 sibling, 1 reply; 13+ messages in thread
From: Andy Moreton @ 2018-08-20 11:28 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20 11:28             ` Andy Moreton
@ 2018-08-20 17:54               ` Jostein Kjønigsen
  2018-08-20 19:45                 ` Michael Albinus
  0 siblings, 1 reply; 13+ messages in thread
From: Jostein Kjønigsen @ 2018-08-20 17:54 UTC (permalink / raw)
  To: Andy Moreton, emacs-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20 17:54               ` Jostein Kjønigsen
@ 2018-08-20 19:45                 ` Michael Albinus
  2018-08-22 12:46                   ` Noam Postavsky
  0 siblings, 1 reply; 13+ messages in thread
From: Michael Albinus @ 2018-08-20 19:45 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: jostein, Andy Moreton, emacs-devel

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Include modern-cpp-font-lock into GNU Emacs
  2018-08-20 19:45                 ` Michael Albinus
@ 2018-08-22 12:46                   ` Noam Postavsky
  0 siblings, 0 replies; 13+ messages in thread
From: Noam Postavsky @ 2018-08-22 12:46 UTC (permalink / raw)
  To: Michael Albinus
  Cc: Jostein Kjønigsen, Jostein Kjønigsen, Andy Moreton,
	Emacs developers

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-08-22 12:46 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-06 20:24 Include modern-cpp-font-lock into GNU Emacs Ludwig PACIFICI
2018-08-11 14:51 ` Alan Mackenzie
2018-08-12  0:22   ` Stefan Monnier
2018-08-19 11:16   ` Ludwig PACIFICI
2018-08-19 12:31     ` Stefan Monnier
2018-08-20  3:03       ` Richard Stallman
2018-08-20  8:38         ` Andy Moreton
2018-08-20  9:28           ` Jostein Kjønigsen
2018-08-20 10:51             ` Noam Postavsky
2018-08-20 11:28             ` Andy Moreton
2018-08-20 17:54               ` Jostein Kjønigsen
2018-08-20 19:45                 ` Michael Albinus
2018-08-22 12:46                   ` Noam Postavsky

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.