[PATCH] Add prettify symbols to python-mode

[PATCH] Add prettify symbols to python-mode

[Mark Oteiza]

lisp/progmodes/python.el (python-prettify-symbols-alist): New variable
lisp/progmodes/python.el (python-mode): Use it
---
 lisp/progmodes/python.el | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 243125e..0837919 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -620,6 +620,11 @@ The type returned can be `comment', `string' or `paren'."
    ((python-rx string-delimiter)
     (0 (ignore (python-syntax-stringify))))))
 
+(defconst python-prettify-symbols-alist
+  '(("lambda"  . ?\u03bb)
+    ("and" . ?\u2227)
+    ("or" . ?\u2228)))
+
 (defsubst python-syntax-count-quotes (quote-char &optional point limit)
   "Count number of quotes around point (max is 3).
 QUOTE-CHAR is the quote char to count.  Optional argument POINT is
@@ -5104,6 +5109,9 @@ returned as is."
            "`outline-level' function for Python mode."
            (1+ (/ (current-indentation) python-indent-offset))))
 
+  (set (make-local-variable 'prettify-symbols-alist)
+       python-prettify-symbols-alist)
+
   (python-skeleton-add-menu-items)
 
   (make-local-variable 'python-shell-internal-buffer)
-- 
2.5.3

Re: [PATCH] Add prettify symbols to python-mode

[Xue Fuqiao]

On Mon, Sep 21, 2015 at 3:28 AM, Mark Oteiza <mvoteiza@udel.edu> wrote:

> +(defconst python-prettify-symbols-alist

IMHO 'python--prettify-symbols-alist' is a better name, see (info
"(elisp) Coding Conventions").

> +  (set (make-local-variable 'prettify-symbols-alist)
> +       python-prettify-symbols-alist)
> +

You can use

  (setq-local prettify-symbols-alist python--prettify-symbols-alist)

here.

Re: [PATCH] Add prettify symbols to python-mode

[Mark Oteiza]

On 21/09/15 at 06:48am, Xue Fuqiao wrote:
> On Mon, Sep 21, 2015 at 3:28 AM, Mark Oteiza <mvoteiza@udel.edu> wrote:
> 
> > +(defconst python-prettify-symbols-alist
> 
> IMHO 'python--prettify-symbols-alist' is a better name, see (info
> "(elisp) Coding Conventions").

Thanks, I'll do that.

> > +  (set (make-local-variable 'prettify-symbols-alist)
> > +       python-prettify-symbols-alist)
> > +
> 
> You can use
> 
>   (setq-local prettify-symbols-alist python--prettify-symbols-alist)
> 
> here.

Looking at the python.el log, it looks like the maintainer is keeping
compatibility with 24.x, and setq-local was not added until 24.3.

Re: [PATCH] Add prettify symbols to python-mode

[Stefan Monnier]

> Looking at the python.el log, it looks like the maintainer is keeping
> compatibility with 24.x, and setq-local was not added until 24.3.

Indeed.  python.el will be distributed via GNU ELPA, so compatibility
with older Emacsen is relevant.


        Stefan

Re: [PATCH] Add prettify symbols to python-mode

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

  > Indeed.  python.el will be distributed via GNU ELPA, so compatibility
  > with older Emacsen is relevant.

Python is an important language -- shouldn't our support for Python
be in the main Emacs distribution?

-- 
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] Add prettify symbols to python-mode

[Stefan Monnier]

>> Indeed.  python.el will be distributed via GNU ELPA, so compatibility
>> with older Emacsen is relevant.
> Python is an important language -- shouldn't our support for Python
> be in the main Emacs distribution?

It is.  Python.el's maintainer has worked on the elpa scripts so that
GNU ELPA packages can be built directly from the emacs.git source code.
This way packages like python.el and seq.el which want to be bundled
with Emacs as well as distributed via GNU ELPA can do so without having
to duplicate them between elpa.git and emacs.git.

This is not quite ready yet, but ... any day now.


        Stefan

Re: [PATCH] Add prettify symbols to python-mode

[Rasmus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Indeed.  python.el will be distributed via GNU ELPA, so compatibility
>>> with older Emacsen is relevant.
>> Python is an important language -- shouldn't our support for Python
>> be in the main Emacs distribution?
>
> It is.  Python.el's maintainer has worked on the elpa scripts so that
> GNU ELPA packages can be built directly from the emacs.git source code.
> This way packages like python.el and seq.el which want to be bundled
> with Emacs as well as distributed via GNU ELPA can do so without having
> to duplicate them between elpa.git and emacs.git.
>
> This is not quite ready yet, but ... any day now.

Sounds awesome.  Thanks Fabián!

BTW Stefan, and sorry for hijacking, I want to merge Org 8.3.  Is that
still OK?  [I was waiting for 8.3.3, since there were some more bug
fixes].

Should I wait for Fabián's tool or do it the "old" way?

Thanks,
Rasmus

-- 
m-mm-mmm-mmmm bacon!

Re: [PATCH] Add prettify symbols to python-mode

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

  > It is.  Python.el's maintainer has worked on the elpa scripts so that
  > GNU ELPA packages can be built directly from the emacs.git source code.
  > This way packages like python.el and seq.el which want to be bundled
  > with Emacs as well as distributed via GNU ELPA can do so without having
  > to duplicate them between elpa.git and emacs.git.

Interesting.

-- 
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] Add prettify symbols to python-mode

[Achim Gratz]

Stefan Monnier writes:
> It is.  Python.el's maintainer has worked on the elpa scripts so that
> GNU ELPA packages can be built directly from the emacs.git source code.
> This way packages like python.el and seq.el which want to be bundled
> with Emacs as well as distributed via GNU ELPA can do so without having
> to duplicate them between elpa.git and emacs.git.

This is good, but I can't help thinking that the other way around would
have been infinitely more useful.  In other words, emacs.git wouldn't
contain any other eLisp than what it needs to bootstrap and pulling in
everything else as a proper ELPA package while building.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Wed, 23 Sep 2015 08:22:58 +0200
> 
> Stefan Monnier writes:
> > It is.  Python.el's maintainer has worked on the elpa scripts so that
> > GNU ELPA packages can be built directly from the emacs.git source code.
> > This way packages like python.el and seq.el which want to be bundled
> > with Emacs as well as distributed via GNU ELPA can do so without having
> > to duplicate them between elpa.git and emacs.git.
> 
> This is good, but I can't help thinking that the other way around would
> have been infinitely more useful.

Useful for whom, may I ask?

> In other words, emacs.git wouldn't contain any other eLisp than what
> it needs to bootstrap and pulling in everything else as a proper
> ELPA package while building.

It would be a nightmare for a small team of maintainers to keep such a
package in even an approximately good shape, QA-wise.  We currently
don't have enough manpower even for such a basic thing as timely
review of patches proposed by occasional contributors; how will we
ever be able to make sure hundreds of separately developed packages
could ever work together when pulled?

One of the gravest problems I see for the future of Emacs development
is that we slowly but steadily lose old-timers who know a lot about
the Emacs internals and have lots of experience hacking them, whereas
the (welcome) newcomers mostly prefer working on application-level
code in Lisp.  If this tendency continues, we will soon lose the
ability to make deep infrastructure changes, i.e. will be unable to
add new features that need non-trivial changes on the C level.

Moving most Lisp packages out of the core will give a tremendous boost
to this slippery slope, by even further detaching many contributors
from the core and segregating the core's ever dwindling bunch.  That
way lies stagnation and death.

Please don't even think about suggesting this, unless you plan to come
on board and become a very active member of the core team, responsible
for these aspects specifically.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> One of the gravest problems I see for the future of Emacs development
> is that we slowly but steadily lose old-timers who know a lot about
> the Emacs internals and have lots of experience hacking them, whereas
> the (welcome) newcomers mostly prefer working on application-level
> code in Lisp.  If this tendency continues, we will soon lose the
> ability to make deep infrastructure changes, i.e. will be unable to
> add new features that need non-trivial changes on the C level.

To quote from the famous "Four Yorkshire Men" sketch
<URL:https://www.youtube.com/watch?v=VKHFZBUTA4k>: Luxury.

We've just recently had a sort of informal user poll of LilyPond users
on the the LilyPond mailing list (LilyPond is a music typesetter
extensible in Scheme and with a plain-text input language that is
compiled into scores and Midi renditions, so its basic workflow is
non-graphic and somewhat reminiscent of LaTeX or *roff).

About 90% of the user base was in the 50-80 range.  One of the first
well-matured posters wrote "Well, apparently you _can_ teach old dogs
new tricks" but as the thread progressed, the picture looked much more
like you can actually teach rather few new dogs old tricks.

> Moving most Lisp packages out of the core will give a tremendous boost
> to this slippery slope, by even further detaching many contributors
> from the core and segregating the core's ever dwindling bunch.  That
> way lies stagnation and death.

Shrug.  LaTeX had its last major release (LaTeX2e) in 1994.  The basis
of packages and style files built on top of that is ever expanding
(I suspect a similar age distribution to that of LilyPond, though).  It
is not clear that its designated successor, LaTeX3, will ever gain
serious traction once it is finally released as a coherent offering
(rather than a bunch of add-ons).

And make no mistake: the basic _executable_ LaTeX is built around,
namely TeX, is rather unsuitable for general purpose programming.

> Please don't even think about suggesting this, unless you plan to come
> on board and become a very active member of the core team, responsible
> for these aspects specifically.

Projects may behave like stars when the balance between matter and
expansion shifts and eventually collapse under their own weight when
there is not enough of a chain reaction going on any more.

Is our twin star XEmacs a gas giant or a red dwarf these days?  Or on
the way to either?

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Xue Fuqiao]

On Wed, Sep 23, 2015 at 3:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> One of the gravest problems I see for the future of Emacs development
> is that we slowly but steadily lose old-timers who know a lot about
> the Emacs internals and have lots of experience hacking them, whereas
> the (welcome) newcomers mostly prefer working on application-level
> code in Lisp.  If this tendency continues, we will soon lose the
> ability to make deep infrastructure changes, i.e. will be unable to
> add new features that need non-trivial changes on the C level.

Yes, this is also what I see.  As a "newcomer" (in comparison with most
Emacs hackers on this list, who have been contributing to Emacs for much
longer than me, and have a deeper understanding of the system as a
whole), some possible causes for this problem are:

* Hacking on the C level is inherently more difficult than the Lisp
  (application) level.

* Perhaps our effort on (info "(elisp) GNU Emacs Internals") is not
  enough.  (Although it's almost impossible to document the ins and outs
  of the Emacs Lisp interpreter, the redisplay code, and other C
  infrastructure in Emacs, let alone having them updated.)

* There is a deeper going split between the core developers and the rest
  of the community (this one is not specific to C/Lisp, and has many
  technical and non-technical reasons).

* Many times, discussions on emacs-devel are defensive rather than
  constructive (not specific to C either).

* Emacs runs on all versions of Windows from Windows 98 and Windows NT
  4.0 through to Windows 10, and even MS-DOS (although msdos.c is pretty
  easy to read).  I'm not sure whether the maintenance burden is worthy.
  (Anyway, Eli, I have great respect for you and your contributions to Emacs.)

* Many developers think that the indentation style of the GNU Coding
  Standards is ugly (as condemned by the Linux kernel coding style guide
  ;-).

Currently, I don't have any concrete proposal to figuring out a
practical solution, but I'll do my bit and try to improve Emacs's
condition.

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> Date: Wed, 23 Sep 2015 22:12:30 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: Achim Gratz <Stromeko@nexgo.de>, Emacs-devel <emacs-devel@gnu.org>
> 
> On Wed, Sep 23, 2015 at 3:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > One of the gravest problems I see for the future of Emacs development
> > is that we slowly but steadily lose old-timers who know a lot about
> > the Emacs internals and have lots of experience hacking them, whereas
> > the (welcome) newcomers mostly prefer working on application-level
> > code in Lisp.  If this tendency continues, we will soon lose the
> > ability to make deep infrastructure changes, i.e. will be unable to
> > add new features that need non-trivial changes on the C level.
> 
> Yes, this is also what I see.  As a "newcomer" (in comparison with most
> Emacs hackers on this list, who have been contributing to Emacs for much
> longer than me, and have a deeper understanding of the system as a
> whole), some possible causes for this problem are:
> 
> * Hacking on the C level is inherently more difficult than the Lisp
>   (application) level.

I don't see why.  C is not a complicated language, and a large part of
the Emacs source code never touches its relatively more problematic
parts, like memory allocation.

> * Perhaps our effort on (info "(elisp) GNU Emacs Internals") is not
>   enough.  (Although it's almost impossible to document the ins and outs
>   of the Emacs Lisp interpreter, the redisplay code, and other C
>   infrastructure in Emacs, let alone having them updated.)

This is a red herring: the C-level internals are extensively
documented in comments to the respective source files.  Many source
files have large commentaries at their beginning describing their
design and implementation.  Having those in Texinfo will not change
anything.

If someone comes up with a list of specific design aspects that are in
their opinion under-documented, post them.  I'd be surprised to see
there anything that someone active here can tell which isn't already
in the comments, but who knows.

> * There is a deeper going split between the core developers and the rest
>   of the community (this one is not specific to C/Lisp, and has many
>   technical and non-technical reasons).

So not really relevant to the issue at hand.

> * Many times, discussions on emacs-devel are defensive rather than
>   constructive (not specific to C either).

Likewise.

> * Emacs runs on all versions of Windows from Windows 98 and Windows NT
>   4.0 through to Windows 10, and even MS-DOS (although msdos.c is pretty
>   easy to read).  I'm not sure whether the maintenance burden is worthy.

No one needs to hack on code specific to these platforms if they don't
feel like it.  Our problem is falling behind on Posix platforms, not
on the rest of them.  Most of the Emacs internals are
platform-independent anyway.  Just pretend that this issue doesn't
exist.

> Currently, I don't have any concrete proposal to figuring out a
> practical solution, but I'll do my bit and try to improve Emacs's
> condition.

There's no other practical solution except volunteering and getting
your hands dirty.  Knowledge and experience will come with time.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 23 Sep 2015 22:12:30 +0800
>> From: Xue Fuqiao <xfq.free@gmail.com>
>> Cc: Achim Gratz <Stromeko@nexgo.de>, Emacs-devel <emacs-devel@gnu.org>
>> 
>> On Wed, Sep 23, 2015 at 3:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > One of the gravest problems I see for the future of Emacs development
>> > is that we slowly but steadily lose old-timers who know a lot about
>> > the Emacs internals and have lots of experience hacking them, whereas
>> > the (welcome) newcomers mostly prefer working on application-level
>> > code in Lisp.  If this tendency continues, we will soon lose the
>> > ability to make deep infrastructure changes, i.e. will be unable to
>> > add new features that need non-trivial changes on the C level.
>> 
>> Yes, this is also what I see.  As a "newcomer" (in comparison with most
>> Emacs hackers on this list, who have been contributing to Emacs for much
>> longer than me, and have a deeper understanding of the system as a
>> whole), some possible causes for this problem are:
>> 
>> * Hacking on the C level is inherently more difficult than the Lisp
>>   (application) level.
>
> I don't see why.  C is not a complicated language, and a large part of
> the Emacs source code never touches its relatively more problematic
> parts, like memory allocation.

C may not be a complicated language but it offers no significant
in-language features for integrating data structures and their
manipulators.  As a consequence, working with Elisp data in C does not
resemble either working with C or with Lisp.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 23 Sep 2015 18:52:16 +0200
> Cc: Xue Fuqiao <xfq.free@gmail.com>, Stromeko@nexgo.de, emacs-devel@gnu.org
> 
> C may not be a complicated language but it offers no significant
> in-language features for integrating data structures and their
> manipulators.  As a consequence, working with Elisp data in C does not
> resemble either working with C or with Lisp.

We have a small set of macros that make this a non-issue.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 23 Sep 2015 18:52:16 +0200
>> Cc: Xue Fuqiao <xfq.free@gmail.com>, Stromeko@nexgo.de, emacs-devel@gnu.org
>> 
>> C may not be a complicated language but it offers no significant
>> in-language features for integrating data structures and their
>> manipulators.  As a consequence, working with Elisp data in C does not
>> resemble either working with C or with Lisp.
>
> We have a small set of macros that make this a non-issue.

Lisp_Object x[2];
x[0] = a;
x[1] = b;
return Fplus (2, x);

does not resemble either a+b or (+ a b).  A non-issue is something else.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Achim Gratz]

Eli Zaretskii writes:
>> This is good, but I can't help thinking that the other way around would
>> have been infinitely more useful.
>
> Useful for whom, may I ask?

Users who want to have more control over which packages and versions
they use, system administrators that need to deal with multiple versions
of Emacs on the same system or across a bunch of systems and packagers
of distribution packets.  Last but not least the very maintainers of
said packages who will be relieved from the burden of keeping their
packages in sync with Emacs both ways.

>> In other words, emacs.git wouldn't contain any other eLisp than what
>> it needs to bootstrap and pulling in everything else as a proper
>> ELPA package while building.
>
> It would be a nightmare for a small team of maintainers to keep such a
> package in even an approximately good shape, QA-wise.  We currently
> don't have enough manpower even for such a basic thing as timely
> review of patches proposed by occasional contributors; how will we
> ever be able to make sure hundreds of separately developed packages
> could ever work together when pulled?

It works by specifying the exact Git revisions (or tags) that are paired
up with that Emacs release (and these packages would be in the tarball
so no extra download happens when building from those).  If it's all in
ELPA anyway and already maintained from outside Emacs, then why should
these be copied again in emacs.git?

If you look around you'll find that quite a few other projects are doing
very similar things.  For instance, Perl bundles certain CPAN modules.
Yes, there's a constant discussion of what should be pure CPAN, what
should be "dual-life" modules and what should be purely core.

> One of the gravest problems I see for the future of Emacs development
> is that we slowly but steadily lose old-timers who know a lot about
> the Emacs internals and have lots of experience hacking them, whereas
> the (welcome) newcomers mostly prefer working on application-level
> code in Lisp.  If this tendency continues, we will soon lose the
> ability to make deep infrastructure changes, i.e. will be unable to
> add new features that need non-trivial changes on the C level.

That's an entirely different discussion, and one that I do not intend to
address in this thread.

> Moving most Lisp packages out of the core will give a tremendous boost
> to this slippery slope, by even further detaching many contributors
> from the core and segregating the core's ever dwindling bunch.  That
> way lies stagnation and death.

I don't see how what I proposed would even remotely cause that.  The
same people would develop the eLisp packages in the same way they are
doing it today and for each Emacs release the Emacs devs can chose which
version of those packages gets bundled.  If Emacs QA finds out there are
bugs to fix you can adress it to the package maintainers in the same way
as today (just the commits go to a different repository).

> Please don't even think about suggesting this, unless you plan to come
> on board and become a very active member of the core team, responsible
> for these aspects specifically.

No offense taken, but you can't be serious about telling me what to
think or what I can say or not under whichever conditions.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: xfq.free@gmail.com,  Stromeko@nexgo.de,  emacs-devel@gnu.org
> Date: Wed, 23 Sep 2015 19:58:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Wed, 23 Sep 2015 18:52:16 +0200
> >> Cc: Xue Fuqiao <xfq.free@gmail.com>, Stromeko@nexgo.de, emacs-devel@gnu.org
> >> 
> >> C may not be a complicated language but it offers no significant
> >> in-language features for integrating data structures and their
> >> manipulators.  As a consequence, working with Elisp data in C does not
> >> resemble either working with C or with Lisp.
> >
> > We have a small set of macros that make this a non-issue.
> 
> Lisp_Object x[2];
> x[0] = a;
> x[1] = b;
> return Fplus (2, x);
> 
> does not resemble either a+b or (+ a b).  A non-issue is something else.

Where's "Elisp data" in this example?

I thought by "working with Elisp data in C" you meant using Lisp data
structures passed to C functions, in which case the following is what
I had in mind (where 'value' is some Lisp data type):

  if (EQ (value, Qunspecified) || (EQ (value, QCignore_defface)))
    return Qt;
  else if (EQ (attribute, QCheight))
    return INTEGERP (value) ? Qnil : Qt;
  else if (CONSP (value) && EQ (XCAR (value), QCwhatever))
    return XCDR (value);
  else
    return Qnil;

Re: [PATCH] Add prettify symbols to python-mode

[Paul Eggert]

On 09/23/2015 10:58 AM, David Kastrup wrote:
> Lisp_Object x[2];
> x[0] = a;
> x[1] = b;
> return Fplus (2, x);
>
> does not resemble either a+b or (+ a b).

Sure, but that's not using the C macros properly.  Better is this:

    return CALLN (Fplus, a, b);

which is not so far from (+ a b).

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: xfq.free@gmail.com,  Stromeko@nexgo.de,  emacs-devel@gnu.org
>> Date: Wed, 23 Sep 2015 19:58:18 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Date: Wed, 23 Sep 2015 18:52:16 +0200
>> >> Cc: Xue Fuqiao <xfq.free@gmail.com>, Stromeko@nexgo.de, emacs-devel@gnu.org
>> >> 
>> >> C may not be a complicated language but it offers no significant
>> >> in-language features for integrating data structures and their
>> >> manipulators.  As a consequence, working with Elisp data in C does not
>> >> resemble either working with C or with Lisp.
>> >
>> > We have a small set of macros that make this a non-issue.
>> 
>> Lisp_Object x[2];
>> x[0] = a;
>> x[1] = b;
>> return Fplus (2, x);
>> 
>> does not resemble either a+b or (+ a b).  A non-issue is something else.
>
> Where's "Elisp data" in this example?
>
> I thought by "working with Elisp data in C" you meant using Lisp data
> structures passed to C functions, in which case the following is what
> I had in mind (where 'value' is some Lisp data type):
>
>   if (EQ (value, Qunspecified) || (EQ (value, QCignore_defface)))
>     return Qt;
>   else if (EQ (attribute, QCheight))
>     return INTEGERP (value) ? Qnil : Qt;
>   else if (CONSP (value) && EQ (XCAR (value), QCwhatever))
>     return XCDR (value);
>   else
>     return Qnil;

Which is supposed to resemble perfectly ordinary C code or perfectly
ordinary Lisp code?

You can call it a "non-issue" all you like, but it is limiting the
number of people comfortable working with the Emacs C core.  As long as
Emacs is expressive enough outside of the core, that's not really
limiting its usefulness all that much, but for things like new window
systems, one clearly cannot get around investing into C.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Wed, 23 Sep 2015 21:07:53 +0200
> 
> Eli Zaretskii writes:
> >> This is good, but I can't help thinking that the other way around would
> >> have been infinitely more useful.
> >
> > Useful for whom, may I ask?
> 
> Users who want to have more control over which packages and versions
> they use

They have that control now.  No package will start itself, unless the
user invokes it.

> system administrators that need to deal with multiple versions
> of Emacs on the same system or across a bunch of systems and packagers
> of distribution packets.

This is just going to be far more complex if we off-load large
portions of Emacs to elsewhere: there will be more combinations of
different versions to consider and support.

> Last but not least the very maintainers of said packages who will be
> relieved from the burden of keeping their packages in sync with
> Emacs both ways.

That burden is what allows users to be sure their packages will work
with future versions of Emacs.  Take that away, and the QA problem I
was talking about will rear its head.

> >> In other words, emacs.git wouldn't contain any other eLisp than what
> >> it needs to bootstrap and pulling in everything else as a proper
> >> ELPA package while building.
> >
> > It would be a nightmare for a small team of maintainers to keep such a
> > package in even an approximately good shape, QA-wise.  We currently
> > don't have enough manpower even for such a basic thing as timely
> > review of patches proposed by occasional contributors; how will we
> > ever be able to make sure hundreds of separately developed packages
> > could ever work together when pulled?
> 
> It works by specifying the exact Git revisions (or tags) that are paired
> up with that Emacs release (and these packages would be in the tarball
> so no extra download happens when building from those).

If we are going to tie specific versions to specific Emacs releases,
then what is this all about?  Why all the overhead?  What do we gain?

> If you look around you'll find that quite a few other projects are doing
> very similar things.  For instance, Perl bundles certain CPAN modules.
> Yes, there's a constant discussion of what should be pure CPAN, what
> should be "dual-life" modules and what should be purely core.

Yes, and whenever I need to install some package from CPAN, I end up
installing dozens of its dependencies first.  Do we really want that
for Emacs users?  I don't.

> > One of the gravest problems I see for the future of Emacs development
> > is that we slowly but steadily lose old-timers who know a lot about
> > the Emacs internals and have lots of experience hacking them, whereas
> > the (welcome) newcomers mostly prefer working on application-level
> > code in Lisp.  If this tendency continues, we will soon lose the
> > ability to make deep infrastructure changes, i.e. will be unable to
> > add new features that need non-trivial changes on the C level.
> 
> That's an entirely different discussion, and one that I do not intend to
> address in this thread.

That is the slippery slope I don't want us to take.  Not even the
first step.

> > Moving most Lisp packages out of the core will give a tremendous boost
> > to this slippery slope, by even further detaching many contributors
> > from the core and segregating the core's ever dwindling bunch.  That
> > way lies stagnation and death.
> 
> I don't see how what I proposed would even remotely cause that.

I tried to explain how.

> The same people would develop the eLisp packages in the same way
> they are doing it today and for each Emacs release the Emacs devs
> can chose which version of those packages gets bundled.  If Emacs QA
> finds out there are bugs to fix you can adress it to the package
> maintainers in the same way as today (just the commits go to a
> different repository).

Packages that are not in core get much less attention from the core
maintainers.  It starts with the fact that I don't see them compiling
on my machine each time I build Emacs, so any warnings I might have
seen and taken care of, if only be letting the maintainer know, will
be lost for me.  It goes on with me not watching commits to ELPA
packages, so I don't have a chance of timely catching problematic
code.  Etc. etc. -- the Emacs QA doesn't cover unbundled packages.

> > Please don't even think about suggesting this, unless you plan to come
> > on board and become a very active member of the core team, responsible
> > for these aspects specifically.
> 
> No offense taken, but you can't be serious about telling me what to
> think or what I can say or not under whichever conditions.

I'm not telling you anything -- that "please" was there for a reason.
And how's that different from your suggestion, anyway?  If you can
tell us that "the other way around would have been infinitely more
useful", why cannot I tell you what I did?

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 09/23/2015 10:58 AM, David Kastrup wrote:
>> Lisp_Object x[2];
>> x[0] = a;
>> x[1] = b;
>> return Fplus (2, x);
>>
>> does not resemble either a+b or (+ a b).
>
> Sure, but that's not using the C macros properly.  Better is this:
>
>    return CALLN (Fplus, a, b);
>
> which is not so far from (+ a b).

dak@lola:/usr/local/tmp/emacs$ git grep CALLN src|wc -l
85

That's not exactly ubiquitous.  And we have the self-estimate

src/lisp.h:   CALLN is overkill for simple usages like 'Finsert (1, &text);'.  */

which actively discourages using a C macro when you can use a direct
call.

Emacs C just is pretty far from a "non-issue".  Pretending otherwise is
not useful.  The number of people working on it will always be limited
to people comfortable working with interpreters and non-native data
types.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: xfq.free@gmail.com,  Stromeko@nexgo.de,  emacs-devel@gnu.org
> Date: Wed, 23 Sep 2015 21:39:45 +0200
> 
> > I thought by "working with Elisp data in C" you meant using Lisp data
> > structures passed to C functions, in which case the following is what
> > I had in mind (where 'value' is some Lisp data type):
> >
> >   if (EQ (value, Qunspecified) || (EQ (value, QCignore_defface)))
> >     return Qt;
> >   else if (EQ (attribute, QCheight))
> >     return INTEGERP (value) ? Qnil : Qt;
> >   else if (CONSP (value) && EQ (XCAR (value), QCwhatever))
> >     return XCDR (value);
> >   else
> >     return Qnil;
> 
> Which is supposed to resemble perfectly ordinary C code or perfectly
> ordinary Lisp code?

No, it's supposed to be mnemonically easy to understand and write.
And yes, it's reasonably close to ordinary C code, IMO.

> You can call it a "non-issue" all you like, but it is limiting the
> number of people comfortable working with the Emacs C core.  As long as
> Emacs is expressive enough outside of the core, that's not really
> limiting its usefulness all that much, but for things like new window
> systems, one clearly cannot get around investing into C.

I don't see it that way, but in any case, people should try overcoming
that obstacle.  It's not very hard.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> From: David Kastrup <dak@gnu.org>
>
>> Which is supposed to resemble perfectly ordinary C code or perfectly
>> ordinary Lisp code?
>
> No, it's supposed to be mnemonically easy to understand and write.
> And yes, it's reasonably close to ordinary C code, IMO.

C is a language with more operators than just function calls.

>> You can call it a "non-issue" all you like, but it is limiting the
>> number of people comfortable working with the Emacs C core.  As long
>> as Emacs is expressive enough outside of the core, that's not really
>> limiting its usefulness all that much, but for things like new window
>> systems, one clearly cannot get around investing into C.
>
> I don't see it that way, but in any case, people should try overcoming
> that obstacle.  It's not very hard.

There is not much to gain by basing one's plans on "people should"
rather than "people will".

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 23 Sep 2015 21:56:29 +0200
> Cc: xfq.free@gmail.com, Stromeko@nexgo.de, emacs-devel@gnu.org
> 
> There is not much to gain by basing one's plans on "people should"
> rather than "people will".

I am not making any plans in this regard.  If you are right (which is
by no means a given), and people "will not", then Emacs has no future.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 23 Sep 2015 21:56:29 +0200
>> Cc: xfq.free@gmail.com, Stromeko@nexgo.de, emacs-devel@gnu.org
>> 
>> There is not much to gain by basing one's plans on "people should"
>> rather than "people will".
>
> I am not making any plans in this regard.  If you are right (which is
> by no means a given), and people "will not", then Emacs has no future.

Emacs has no future shaped by drive-by C programmers.  That's quite
different from, say, the Linux kernel where you can improve some
internal data structure or algorithm without having to relearn how to
express yourself.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Paul Eggert]

On 09/23/2015 12:46 PM, David Kastrup wrote:
> dak@lola:/usr/local/tmp/emacs$ git grep CALLN src|wc -l
> 85
>
> That's not exactly ubiquitous.

Shrug.  It's common enough.  Fconcat is called in only 11 lines, but 
that doesn't mean people shouldn't be expected to know about concatenation.

> Emacs C just is pretty far from a "non-issue".  Pretending otherwise is
> not useful.

Neither is it useful to imply that this is a bigger issue than it is, 
which your example did.

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 09/23/2015 12:46 PM, David Kastrup wrote:
>> dak@lola:/usr/local/tmp/emacs$ git grep CALLN src|wc -l
>> 85
>>
>> That's not exactly ubiquitous.
>
> Shrug.  It's common enough.  Fconcat is called in only 11 lines, but
> that doesn't mean people shouldn't be expected to know about
> concatenation.
>
>> Emacs C just is pretty far from a "non-issue".  Pretending otherwise is
>> not useful.
>
> Neither is it useful to imply that this is a bigger issue than it is,
> which your example did.

Shrug.  So you're right and all those people not programming Emacs in C
are wrong.  Too bad there's no prize for that.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Stephen J. Turnbull]

David Kastrup writes:

 > Shrug.  So you're right and all those people not programming Emacs
 > in C are wrong.  Too bad there's no prize for that.

Nobody in their right mind would *want* to program in Emacs in C just
because it's there.  IME, most people get involved in writing Emacs in
C because they have performance needs that can't be addressed by
programming Emacs in Lisp, or because their Lisp skills are near zero.
Other languages (Python is one whose dev community is known to me) are
doing a pretty good job of keeping and acquiring C programming skills,
despite having similar C APIs to Emacs's.

While David is correct that the C API is off-putting because you
really do have to take care of the sensibilities of the Lisp engine
when programming, Emacs has done a pretty good job of minimizing that,
with macros like CALLN and (much more important, IMO) by getting rid
of GCPROs (at least for "proof of concept" on all major platforms for
quite a long time, and today there are no supported platforms that
need them).

So the reason that Emacs seems to have a problem recruiting C-level
hackers is elsewhere, IMO.[1]  People who want to program Emacs in C for
some reason can learn the "syntax" pretty quickly.  The semantics of
things like FFuncall are another matter, and the requirement that C
routines handle all possible Lisp error conditions and all possible
Lisp data without crashing is pretty stiff for people coming from the
safety of Lisp (or Python!) programming.  But those are unavoidable
barriers of low-level systems programming.


Footnotes: 
[1]  Indeed, it may be non-existent, merely a matter of "grass is
greener over there" perception vs. other projects.

Re: [PATCH] Add prettify symbols to python-mode

[Xue Fuqiao]

On Thu, Sep 24, 2015 at 12:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> * Hacking on the C level is inherently more difficult than the Lisp
>>   (application) level.
>
> I don't see why.  C is not a complicated language, and a large part of
> the Emacs source code never touches its relatively more problematic
> parts, like memory allocation.

Maybe because the display engine is so complex that people don't want to
spend too much time on it.

>> * Perhaps our effort on (info "(elisp) GNU Emacs Internals") is not
>>   enough.  (Although it's almost impossible to document the ins and outs
>>   of the Emacs Lisp interpreter, the redisplay code, and other C
>>   infrastructure in Emacs, let alone having them updated.)
>
> This is a red herring: the C-level internals are extensively
> documented in comments to the respective source files.  Many source
> files have large commentaries at their beginning describing their
> design and implementation.  Having those in Texinfo will not change
> anything.
>
> If someone comes up with a list of specific design aspects that are in
> their opinion under-documented, post them.  I'd be surprised to see
> there anything that someone active here can tell which isn't already
> in the comments, but who knows.

Although, Lisp code has documentation strings and the `;;; Commentary:'
header, there's also lispref.  In-code documentation isn't enough
sometimes.

For example, if a developer wants to hack on the display engine, first,
she needs to know where the code of the display engine is (She may
wonder, is character.c part of the display engine, which is used to
display characters?  What about cmds.c?  composite.c?  disptab.h?
emacs.c?  fringe.c?  image.c?  textprop.c?  And xdisp.c?); second, she
wants to know how to debug a redisplay problem
("--enable-checking='yes,glyphs'"?  How to use its facilities?).  She
also need to know whether she can use C11 features, how to DEFUN, which
language should the test suite be written in for C code (C or Lisp?),
and all kinds of details that long-time core hackers are familiar with
but a newcomer doesn't have any clue.

(To my understanding, the display engine is composed of xdisp.c,
 dispnew.c, fringe.c, and perhaps some platform-dependent code like
 nsfns.m, w32fns.c, and xfns.c.  Please correct me if I'm wrong.)

Re: [PATCH] Add prettify symbols to python-mode

[Xue Fuqiao]

BTW, I was just trying making an analysis of the this problem, and of
course my analysis could be wrong.  Do you have any idea why newcomers
mostly prefer working on application-level code in Lisp?

(Let's try and stay constructive.  If we can find the causes, then we
have the possibility to improve the current condition.)

Re: [PATCH] Add prettify symbols to python-mode

[David Kastrup]

Xue Fuqiao <xfq.free@gmail.com> writes:

> BTW, I was just trying making an analysis of the this problem, and of
> course my analysis could be wrong.  Do you have any idea why newcomers
> mostly prefer working on application-level code in Lisp?

In my opinion that's a feature, not a bug.  Elisp is there for a reason.

> (Let's try and stay constructive.  If we can find the causes, then we
> have the possibility to improve the current condition.)

We have Elisp exactly in order not to have to address problems by
reverting to C programming.  In my opinion it is entirely the wrong idea
to have people start solving problems in C because they prefer it to
Elisp.  The main reason to solve problems in C is because there is no
reasonably workable solution to be created in Elisp.  If beginners turn
to C first, they will not even know whether there would be a reasonably
workable solution available in Elisp.

Elisp code can be debugged reasonably nicely, manages its memory and
data structures reliably.  It's concise, memory-efficient and
expressive.

-- 
David Kastrup

Re: [PATCH] Add prettify symbols to python-mode

[Kaushal Modi]

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

I believe that the "beginner" here in question is not someone who just
started using emacs but a beginner contributor who is already comfortable
with emacs and is interested in contributing to the C code but isn't
because there isn't enough "Getting started with C tinkering in emacs"
documentation.

I like the points that Xue made there with an example of what a "beginner"
would go through when trying to understand the display engine.

--
Kaushal Modi
On Sep 24, 2015 4:35 AM, "David Kastrup" <dak@gnu.org> wrote:

> Xue Fuqiao <xfq.free@gmail.com> writes:
>
> > BTW, I was just trying making an analysis of the this problem, and of
> > course my analysis could be wrong.  Do you have any idea why newcomers
> > mostly prefer working on application-level code in Lisp?
>
> In my opinion that's a feature, not a bug.  Elisp is there for a reason.
>
> > (Let's try and stay constructive.  If we can find the causes, then we
> > have the possibility to improve the current condition.)
>
> We have Elisp exactly in order not to have to address problems by
> reverting to C programming.  In my opinion it is entirely the wrong idea
> to have people start solving problems in C because they prefer it to
> Elisp.  The main reason to solve problems in C is because there is no
> reasonably workable solution to be created in Elisp.  If beginners turn
> to C first, they will not even know whether there would be a reasonably
> workable solution available in Elisp.
>
> Elisp code can be debugged reasonably nicely, manages its memory and
> data structures reliably.  It's concise, memory-efficient and
> expressive.
>
> --
> David Kastrup
>
>

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

Re: [PATCH] Add prettify symbols to python-mode

[Xue Fuqiao]

On Thu, Sep 24, 2015 at 4:35 PM, David Kastrup <dak@gnu.org> wrote:
> Xue Fuqiao <xfq.free@gmail.com> writes:
>
>> BTW, I was just trying making an analysis of the this problem, and of
>> course my analysis could be wrong.  Do you have any idea why newcomers
>> mostly prefer working on application-level code in Lisp?
>
> In my opinion that's a feature, not a bug.  Elisp is there for a reason.
>
>> (Let's try and stay constructive.  If we can find the causes, then we
>> have the possibility to improve the current condition.)
>
> We have Elisp exactly in order not to have to address problems by
> reverting to C programming.  In my opinion it is entirely the wrong idea
> to have people start solving problems in C because they prefer it to
> Elisp.  The main reason to solve problems in C is because there is no
> reasonably workable solution to be created in Elisp.  If beginners turn
> to C first, they will not even know whether there would be a reasonably
> workable solution available in Elisp.
>
> Elisp code can be debugged reasonably nicely, manages its memory and
> data structures reliably.  It's concise, memory-efficient and
> expressive.

I completely agree with these views, and that's one of the reasons I use
Emacs.  But Eli said:

   If this tendency continues, we will soon lose the ability to make
   deep infrastructure changes, i.e. will be unable to add new features
   that need non-trivial changes on the C level.

Solving problems in C is useful for "deep infrastructure changes", like
xwidget, dynload/modules, bidi, lexical scoping, GnuTLS support, font
rendering, Emacs server etc.

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> Date: Thu, 24 Sep 2015 11:57:24 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: Stromeko@nexgo.de, Emacs-devel <emacs-devel@gnu.org>
> 
> >> * Hacking on the C level is inherently more difficult than the Lisp
> >>   (application) level.
> >
> > I don't see why.  C is not a complicated language, and a large part of
> > the Emacs source code never touches its relatively more problematic
> > parts, like memory allocation.
> 
> Maybe because the display engine is so complex that people don't want to
> spend too much time on it.

It's not very complex, as long as you don't try to make too deep
changes in it, like a complete redesign.  Most of the time you don't
need a detailed understanding of the entire display design, just of
some small area you want to change.

And the display engine is just one part of the C code; there are quite
a few others, like searching, input handling, text properties, syntax,
the Lisp interpreter, etc.

> Although, Lisp code has documentation strings and the `;;; Commentary:'
> header, there's also lispref.  In-code documentation isn't enough
> sometimes.

Documentation is never enough.  The question is: is it a reasonably
good start?  I think in many parts of the C code we have now, it is,
although additions are always welcome, of course.

> For example, if a developer wants to hack on the display engine, first,
> she needs to know where the code of the display engine is (She may
> wonder, is character.c part of the display engine, which is used to
> display characters?  What about cmds.c?  composite.c?  disptab.h?
> emacs.c?  fringe.c?  image.c?  textprop.c?  And xdisp.c?)

The same problem exists for stuff implemented in Lisp.  And the
solution is the same: "C-h f" and "C-h v" for built-in functions and
variables relevant to the issue at hand will guide you to the source
file you are looking for, and the ELisp manual will describe the
purpose and effect they are supposed to have.  From those starting
points, use source browsing tools to find their subroutines, relevant
other functions, etc.

This text from CONTRIBUTE should be a starting point:

  ** Understanding Emacs Internals.

  The best way to understand Emacs Internals is to read the code,
  but the nodes "Tips" and "GNU Emacs Internals" in the Appendix
  of the Emacs Lisp Reference Manual may also help.  Some source files,
  such as xdisp.c, have large commentaries describing the design and
  implementation in more detail.

  The file etc/DEBUG describes how to debug Emacs bugs.

> second, she wants to know how to debug a redisplay problem
> ("--enable-checking='yes,glyphs'"?  How to use its facilities?).

This is described in etc/DEBUG.

> She also need to know whether she can use C11 features

Covered in the ELisp manual (see the node "C Dialect" there).

> how to DEFUN

This is described in the ELisp manual, in the node "GNU Emacs
Internals".

> which language should the test suite be written in for C code
> (C or Lisp?)

Lisp is preferred, as always, but eventually it's up to the programmer
who writes the tests.

> and all kinds of details that long-time core hackers are familiar
> with but a newcomer doesn't have any clue.

You cannot demand to know everything before you start hacking; if you
do, you will never make any progress.  Find out enough to make the
first step, then make that step; then repeat for the next step.  Any
knowledge that is not immediately used in practice will be soon
forgotten, so it's futile to gather information you don't need to make
your next step.

> (To my understanding, the display engine is composed of xdisp.c,
>  dispnew.c, fringe.c, and perhaps some platform-dependent code like
>  nsfns.m, w32fns.c, and xfns.c.  Please correct me if I'm wrong.)

It depends on what you mean by "display engine".  The full list is
much longer:

  . core terminal-independent display code:

    xdisp.c, dispnew.c, bidi.c, dispextern.h, composite.[ch], scroll.c

  . terminal-specific back-ends:

    term.c, xterm.c, xfns.c, w32term.c, w2console.c, w32fns.c,
    nsterm.m, nsfns.m, msdos.c

  . text-mode terminal support code:

    terminal.c, termcap.c, terminfo.c, tparam.c, termhooks.h

  . font and complex script shaping support:

    font.c, fontset.c, ftfont.c, ftxfont.c, ftcrfont.c, xfont.c,
    xftfont.c, w32font.c, w32uniscribe.c, nsfont.m, macfont.m

  . faces: xfaces.c

  . fringes: fringe.c

  . images: image.c, nsimage.m

  . menus:

    menu.c, xmenu.c, term.c, w32menu.c, nsmenu.m, msdos.c

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Achim Gratz <Stromeko@nexgo.de>,  Emacs-devel <emacs-devel@gnu.org>
> Date: Thu, 24 Sep 2015 10:35:10 +0200
> 
> > BTW, I was just trying making an analysis of the this problem, and of
> > course my analysis could be wrong.  Do you have any idea why newcomers
> > mostly prefer working on application-level code in Lisp?
> 
> In my opinion that's a feature, not a bug.  Elisp is there for a reason.
> 
> > (Let's try and stay constructive.  If we can find the causes, then we
> > have the possibility to improve the current condition.)
> 
> We have Elisp exactly in order not to have to address problems by
> reverting to C programming.  In my opinion it is entirely the wrong idea
> to have people start solving problems in C because they prefer it to
> Elisp.  The main reason to solve problems in C is because there is no
> reasonably workable solution to be created in Elisp.  If beginners turn
> to C first, they will not even know whether there would be a reasonably
> workable solution available in Elisp.

110% agreement, of course.  Lisp is always preferable when it's
possible.

My fears are that when Lisp cannot be used, people just punt and say
it cannot (or won't) be done.

Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> Date: Thu, 24 Sep 2015 06:33:09 -0400
> From: Kaushal Modi <kaushal.modi@gmail.com>
> Cc: Achim Gratz <Stromeko@nexgo.de>, Xue Fuqiao <xfq.free@gmail.com>, 
> 	Emacs-devel <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
> 
> I believe that the "beginner" here in question is not someone who just started using emacs but a beginner contributor who is already comfortable with emacs and is interested in contributing to the C code but isn't because there isn't enough "Getting started with C tinkering in emacs" documentation.

In general, the level of documentation (or lack thereof) about the
internals is about the same in C and in Lisp, so I don't understand
why this is seen as a problem for C hacking, but not for Lisp.

> I like the points that Xue made there with an example of what a "beginner" would go through when trying to understand the display engine. 

As I wrote in response, those points are all but covered already,
starting with CONTRIBUTE, so the perceived lack of information seems
to be largely an illusion.

Re: [PATCH] Add prettify symbols to python-mode

[Dmitry Gutov]

On 09/23/2015 09:22 AM, Achim Gratz wrote:
> Stefan Monnier writes:
>> It is.  Python.el's maintainer has worked on the elpa scripts so that
>> GNU ELPA packages can be built directly from the emacs.git source code.
>> This way packages like python.el and seq.el which want to be bundled
>> with Emacs as well as distributed via GNU ELPA can do so without having
>> to duplicate them between elpa.git and emacs.git.
>
> This is good, but I can't help thinking that the other way around would
> have been infinitely more useful.

These issues are intertwined: as long as we can bundle packages from 
ELPA into Emacs distribution, we can move certain packages from the core 
into ELPA without losing them in the distribution.

> In other words, emacs.git wouldn't
> contain any other eLisp than what it needs to bootstrap and pulling in
> everything else as a proper ELPA package while building.

That would be overdoing it: Emacs is not that heavy, and as Eli points 
out, pulling out too many packages would lead to difficulties with 
keeping the whole thing together.

At the very least, each "moved out" package would have to have an active 
maintainer (or several).