From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add prettify symbols to python-mode Date: Thu, 24 Sep 2015 17:31:07 +0300 Message-ID: <83d1x7khxw.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443105094 27937 80.91.229.3 (24 Sep 2015 14:31:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Sep 2015 14:31:34 +0000 (UTC) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: Xue Fuqiao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 24 16:31:25 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 1Zf7YQ-0000mL-1J for ged-emacs-devel@m.gmane.org; Thu, 24 Sep 2015 16:31:22 +0200 Original-Received: from localhost ([::1]:39476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf7YP-0000n7-Ci for ged-emacs-devel@m.gmane.org; Thu, 24 Sep 2015 10:31:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf7YG-0000kv-Np for emacs-devel@gnu.org; Thu, 24 Sep 2015 10:31:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zf7YD-0008CG-B6 for emacs-devel@gnu.org; Thu, 24 Sep 2015 10:31:12 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:52720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf7YC-0008Bh-Uz for emacs-devel@gnu.org; Thu, 24 Sep 2015 10:31:09 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NV600M00Q82CT00@mtaout24.012.net.il> for emacs-devel@gnu.org; Thu, 24 Sep 2015 17:23:51 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV600FWNQNR6S70@mtaout24.012.net.il>; Thu, 24 Sep 2015 17:23:51 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:190331 Archived-At: > Date: Thu, 24 Sep 2015 11:57:24 +0800 > From: Xue Fuqiao > Cc: Stromeko@nexgo.de, Emacs-devel > > >> * 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