From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: emacs IDE features Date: Sat, 17 Oct 2015 16:51:48 -0700 Organization: New Artisans LLC Message-ID: References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> <83oag3oosv.fsf@gnu.org> <6909324d6de8929192a27fc0be8267d4@mail.iq.pl> <561D6773.4080003@cumego.com> <87d1wijwfs.fsf@fastmail.fm> <87eggxemca.fsf@russet.org.uk> <83y4f23puw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445125941 30875 80.91.229.3 (17 Oct 2015 23:52:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 23:52:21 +0000 (UTC) Cc: Sacha Chua To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 01:52:12 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 1ZnbGl-0003Eu-6x for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 01:52:11 +0200 Original-Received: from localhost ([::1]:60109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnbGk-0007Jj-GP for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 19:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnbGX-0007JO-JP for emacs-devel@gnu.org; Sat, 17 Oct 2015 19:51:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnbGU-000250-C5 for emacs-devel@gnu.org; Sat, 17 Oct 2015 19:51:57 -0400 Original-Received: from mail-pa0-x22d.google.com ([2607:f8b0:400e:c03::22d]:34393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnbGU-00023y-4y for emacs-devel@gnu.org; Sat, 17 Oct 2015 19:51:54 -0400 Original-Received: by pacfa8 with SMTP id fa8so1574992pac.1 for ; Sat, 17 Oct 2015 16:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=gyUuM8fXThi27ngWFZjiKmlDIEpLvbYSsWuw5VOuemk=; b=YGyLvEt8UzxIWGSq//6Dv1bZVDhyuzKI88lwopq64Bl87ZjQBx8LSThMxDUbPotsga U0L0PPqCOMLw33EPEXGnUHAXKMvQNSHpTbCjaNr+eNxf+q6FFVBFdncL6V6ujb+CAbA/ +aX+zAMJMgo3PxzUwjW2YuCtQ9YwEM9SjMhIx/6AlEfJhwjjrKiiUpWM7rjKAHryvp3r Qa2R/ar2umnWK18aSiOqdd4Ah3OkY7ML5F5BL+vFIvySlKTrd7Yn9Vg7zvoWtTVGqGsO JfG33cOw/kaSKA62I0bto7RrC/bVxeCdKqXVtMmGQSjDPQK3nMpw8+FNMSqnrpQRJQT3 hoAA== X-Received: by 10.68.228.101 with SMTP id sh5mr25274816pbc.157.1445125913226; Sat, 17 Oct 2015 16:51:53 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id pf7sm28490590pbc.6.2015.10.17.16.51.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 17 Oct 2015 16:51:51 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id D18E6F4598B3; Sat, 17 Oct 2015 16:51:50 -0700 (PDT) In-Reply-To: <83y4f23puw.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Oct 2015 10:40:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org, Sacha Chua X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22d 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:191902 Archived-At: >>>>> Eli Zaretskii writes: >> - Core libraries > You mean "each core library", I presume. IMO, it is impractical to have one > lead and one team for all, or even most of them. Right, I did mean that. >> - External resources > Not sure what that means. Someone who is willing to keep an eye on things like reddit.com/r/emacs, emacswiki.org, and other external resources, that really have nothing to do with emacs-devel at all. This would largely be a non-technical role: more a "community liaison" type of thing. Are the informational and educational needs of the community being mit? If I could pick anyone for this, it would be Sacha Chua. She has already been serving in this capacity more or less, so I'd like to invite her to "report" on the State of The Emacs Community with a touch more formality. >> - Each supported platform > This needs more detailed description. What is a "platform"? We have Posix > systems with and without GTK/Lucid/Motif, with and without Cairo. Are those > the same platform, or do we need experts for each toolkit? Are all Posix > systems the same "platforms", or do we need separate experts on GNU/Linux, > *BSD, Solaris, and Irix? I suppose these dividing lines need to be drawn "as needed" and based on available volunteers. If a group of platforms can be served by one person (say, the *BSD family), great; if it becomes too big a job, or we've divided it wrong, we make a change. >> - Performance > I don't think this should be a separate team. Each core team should be > responsible for performance in their area, because solution of any > performance problems in each area is specific to that area. I agree, but I also don't agree. I'd like to nominate a "performance czar", whose job is to construct and maintain a performance benchmarking suite, run on all platforms as part of the build, and whose output would be tracked over time to detect degradations and inform us of the impact of changes. In the Haskell world, we have exactly this for the GHC compiler: https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html The dashboard linked to in that message measures the performance impact of every commit automatically, presents graphs, etc. The software behind it is freely available, and its author is keen to receive usability suggestions. I know that some don't believe performance is an issue in Emacs, but I would counter with: maybe not the way *you* use it, or the environment you use it in. There are performance issues in nextstep Emacs on OS X, for example, that make it unusable for me. A benchmarking suite would help pinpoint why, and ensure that once fixed, it wouldn't break again. There's no harm in knowledge. If someone out there is interested, it really could help improve our project. Plus, it doesn't require knowledge of either C or Emacs Lisp. This could be a good starter project for someone who wants to get involved, but doesn't feel confident submitting code or documentation just yet. John