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: Emacs contributions, C and Lisp Date: Sun, 16 Feb 2014 19:50:39 +0200 Message-ID: <83r4739cb4.fsf@gnu.org> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <83mwhucg1h.fsf@gnu.org> <878ute589i.fsf@fencepost.gnu.org> <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <5300F51C.7040204@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392573057 18472 80.91.229.3 (16 Feb 2014 17:50:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2014 17:50:57 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 16 18:51:04 2014 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 1WF5rr-0000Rt-0C for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 18:51:03 +0100 Original-Received: from localhost ([::1]:34420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5rq-0000US-M3 for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 12:51:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5ri-0000PC-Gr for emacs-devel@gnu.org; Sun, 16 Feb 2014 12:51:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WF5rd-0001ft-3s for emacs-devel@gnu.org; Sun, 16 Feb 2014 12:50:54 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:47855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5rR-0001aw-QJ; Sun, 16 Feb 2014 12:50:38 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N1300O00NT8Q800@mtaout26.012.net.il>; Sun, 16 Feb 2014 19:49:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N13000G3O5QRC20@mtaout26.012.net.il>; Sun, 16 Feb 2014 19:49:02 +0200 (IST) In-reply-to: <5300F51C.7040204@yandex.ru> 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.182 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:169653 Archived-At: > Date: Sun, 16 Feb 2014 19:27:56 +0200 > From: Dmitry Gutov > CC: dak@gnu.org, emacs-devel@gnu.org > > On 16.02.2014 18:45, Eli Zaretskii wrote: > >> People like to say that, but C being simple and having a weak typing > >> system just means one has to learn more things beyond the language > >> syntax itself. > > > > Not sure what you mean. Also, how is this different from Lisp? > > Manual memory management? Mostly a red herring in Emacs's C layers, unless you are inventing a new Lisp data type or mess with GC. > And when I'm writing Lisp, I usually don't > have to worry about standard library including both modern and obsolete > (and unsecure!) functions doing the same thing, working with baroque > build system and not breaking things on different (often old) compilers > and platforms I can't test. These problems exist in Lisp as they do (or don't) in C, as far as Emacs is concerned. E.g., see the latest discussion of crypto features. > > What I would suggest is to collect the requirements in a single list, > > and file a wishlist bug report with them. I wouldn't expect > > interested people, if there are any, to glean the requirements from > > that longish discussion. > > Ok, I'll try to get around to it in the near future. Thanks! > >> You may want to look at the Emacs community at large, not limited to the > >> core. There are a lot of packages created and added to MELPA, every week. > > > > Yes, everybody plays with their favorite toys. But how does this > > advance Emacs > > They also share their toys. And many people rely on certain "toys" for > their work. Of course. And that's OK. I'm just saying that advancing Emacs needs more than that. > > and do we even have a roadmap for where we want it to go? > > That's a rhetorical question, isn't it? I guess so. > > There was a discussion about this some time ago, although I cannot > > find it now. But how about starting with those GUI code folding > > decorations like every IDE nowadays has, while Emacs doesn't? > > hs-minor-mode? outline-minor-mode? I think CEDET also includes something > similar. See the other mail for what I (and Jorgen) had in mind. I don't think we have anything like that in Emacs, even with CEDET. ECB (which isn't bundled) is the only thing that comes close, but IMO we should have had this in Emacs core for a long time. > I dislike code folding, so this is not an area I examined thoroughly. I don't use it much myself, but it can be invaluable when studying the structure of a large and complex source file. > > (ECB > > comes close, but why shouldn't an Emacs user have that out of the box, > > especially when Speedbar does something very similar for ages?) > > Speedbar is a part of Emacs, isn't it? Yes, it is. But it only does this with lists of files and tags, not with source buffers. > >> It's true that CEDET hasn't seen a lot of progress feature-wise lately, > >> but that's not very surprising: it's complex, it's relatively hard to > >> set up for a novice, it has a weird separation of extra features between > >> the versions in Emacs and its own trunk, and it's not really suitable > >> for dynamic languages, or languages with type inference. AFAIK, that is. > > > > Then the immediate task would be to make it simpler to set up and > > Maybe someone who programs in languages it supports well (such as > yourself?) can write up a short "quickstart" text, or at least formulate > the requirements for one. I certainly hope so. > > suitable for those languages. > > I don't really know, but this may be nearly impossible given the current > CEDET architecture. I certainly hope not, but I don't know enough about CEDET. > >> As far as code completion interface goes, Company development continues. > > > > I hope this will some day be bundled with Emacs. > > Maybe it will. But not everything has to be bundled with Emacs. Things that we consider central and important should be. > >> What other features are missing? Class diagrams? > > > > Yes, that too. > > Again, this is something left up to external tools to implement. I'm not > sure if Jedi or OmniSharp implement an editor-agnostic interfaces for > this feature, but probably not yet. CEDET has COGRE that supports this already, at least according to http://cedet.sourceforge.net/ (search for "UML"). Somewhat clunky and based on "ASCII art", though.