emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: [PATCH] Add prettify symbols to python-mode
Date: Wed, 23 Sep 2015 21:39:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Wed, 23 Sep 2015 19:58:18 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: David Kastrup <address@hidden>
>> >> Date: Wed, 23 Sep 2015 18:52:16 +0200
>> >> Cc: Xue Fuqiao <address@hidden>, address@hidden, address@hidden
>> >> 
>> >> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]