From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xue Fuqiao Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add prettify symbols to python-mode Date: Thu, 24 Sep 2015 11:57:24 +0800 Message-ID: References: <1442777283-27514-1-git-send-email-mvoteiza@udel.edu> <20150921005306.GA29147@holos> <87h9mlwt6l.fsf@Rainer.invalid> <83bnctliay.fsf@gnu.org> <83oagtjemn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1443067067 14996 80.91.229.3 (24 Sep 2015 03:57:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Sep 2015 03:57:47 +0000 (UTC) Cc: Stromeko@nexgo.de, Emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 24 05:57:45 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZexfC-00024d-Jn for ged-emacs-devel@m.gmane.org; Thu, 24 Sep 2015 05:57:42 +0200 Original-Received: from localhost ([::1]:52449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZexfB-0004It-WA for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 23:57:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zexey-0004Ik-0m for emacs-devel@gnu.org; Wed, 23 Sep 2015 23:57:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zexex-0004gh-0E for emacs-devel@gnu.org; Wed, 23 Sep 2015 23:57:27 -0400 Original-Received: from mail-ig0-x22c.google.com ([2607:f8b0:4001:c05::22c]:33382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zexev-0004fZ-7G; Wed, 23 Sep 2015 23:57:25 -0400 Original-Received: by igbkq10 with SMTP id kq10so6688941igb.0; Wed, 23 Sep 2015 20:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lxksDKFLsgM+bE/gfdHJqxnxgHyj+8hjFG9cJ8hcJ5A=; b=Rekpmg0q/ES6zVtbNi2PlVGbbAbXSIeIj+Th3+GkRYD2PwuXOpJYfNL5G6G90TdquU HziD9MaPFOKxyJThn0Q/a7/oOHHuIRPekjPqBh2wsNZ5h1lnrPjJ8eD0UzIhabqp7YE9 yYzCnStQi9/Rz6xz7kIjEigcj5GG5T4oN+CZoVLL0Oz9zG0mAssrygBBu3iUSkqfwR4q +EqhTT3BxmFjRtqJLe77tngFVKkujjERlRLBXoe6IDJkCP4OaReIBzkAHkexsadTbS5M HX3Zw+u0jEOb7/MWYFV5x5TokYZAw0a2bCx36utEllrn4FUbhfWWH88qS9VGZcqf5xyo 1Vgg== X-Received: by 10.50.126.2 with SMTP id mu2mr27982912igb.4.1443067044627; Wed, 23 Sep 2015 20:57:24 -0700 (PDT) Original-Received: by 10.79.94.2 with HTTP; Wed, 23 Sep 2015 20:57:24 -0700 (PDT) In-Reply-To: <83oagtjemn.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190320 Archived-At: On Thu, Sep 24, 2015 at 12:15 AM, Eli Zaretskii 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.)