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: Sat, 01 Mar 2014 15:52:11 +0200 Message-ID: <83bnxquius.fsf@gnu.org> References: <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <8338j717oe.fsf@gnu.org> <87zjlf6tdx.fsf@fencepost.gnu.org> <83sir7yue7.fsf@gnu.org> <8761o3dlak.fsf@wanadoo.es> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87vbvzcjv9.fsf@engster.org> <87iorz18fy.fsf@fencepost.gnu.org> <83vbvyv08q.fsf@gnu.org> <87lhwuyycb.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1393681942 5389 80.91.229.3 (1 Mar 2014 13:52:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 13:52:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 14:52:30 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 1WJkL7-0001Uk-Qk for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 14:52:30 +0100 Original-Received: from localhost ([::1]:59732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJkL7-0002bT-Fp for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 08:52:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJkKy-0002bM-WD for emacs-devel@gnu.org; Sat, 01 Mar 2014 08:52:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJkKt-0006HT-3H for emacs-devel@gnu.org; Sat, 01 Mar 2014 08:52:20 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:51842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJkKl-0006FQ-Ad; Sat, 01 Mar 2014 08:52:07 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N1R00100F1FY600@mtaout25.012.net.il>; Sat, 01 Mar 2014 15:50:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1R00LNHFS5WD70@mtaout25.012.net.il>; Sat, 01 Mar 2014 15:50:29 +0200 (IST) In-reply-to: <87lhwuyycb.fsf@fencepost.gnu.org> 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.181 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:169992 Archived-At: > From: David Kastrup > Date: Sat, 01 Mar 2014 12:04:04 +0100 > > > I actually don't understand why are we talking about compilers as the > > only viable infrastructure for the features being discussed. > > It's basically the UNIX philosophy to employ dedicated tools for the job > they have been written for. I'm not at all sure this philosophy is applicable to the issue at hand, or to complex interactive environments the kind of Emacs in general. We are a long way from the classic batch-mode Unix pipeline, where (AFAIK) this philosophy originated. This is a topic worthy of a separate non-trivial discussion, but just to hint on the potential problems, you may wish to reflect on Emacs features that do try to use this approach: Dired, GUD, and spellers. My take from that is that the success is limited at best, and even then only when those "dedicated tools" go out of their way to support Emacs, i.e. became "dedicated" to Emacs. That's already a far cry from the Unix philosophy mentioned above, which assumes tools dedicated to their respective tasks, not to their consumers, certainly not to one particular consumer. But even if one accepts the philosophy, all we are talking about is whether to prefer one parser to another. That one of them is written in Emacs Lisp is an implementation detail; it is still a "dedicated tool", just like GCC. (GCC can, and usually does, do much more than just parsing and semantic analysis, but that is not important for the issue at hand.) OTOH, using an ELisp-based package brings a tremendous advantage, starting with the fact that such a parser has no problems accessing Emacs buffers, something external programs can only dream about. This alone tells me that CEDET based solutions could be integrated with interactive editing much more easily than any other solution, and in particular, several problems simply don't exist with CEDET. > Well, if we get to stage where we can say "get a language supported by > GCC, and Emacs will provide good highlighting, semantic completion, nice > formatting", then that would be a very strong selling point for GCC as > well as Emacs. It cannot be Emacs's task to provide selling points for GCC, exactly as GCC doesn't provide selling points for Emacs. If GCC acquires these features, it will make sense to add support for them in Emacs; but as long as it doesn't, no one can or should ask Emacs to sell GCC by refraining from using a similar tool that already exists in Emacs. No project can be requested to be that altruistic. > And that's exactly because it would avoid duplication of work. However, > it would also require incremental parsing to be really good. Could an > incremental and/or differential parser (reparse just part of a file and > update all info about the whole compilation unit) be fit in the GCC > framework? An interesting starting point would be, of course, trying to > make Bison skeletons that work for that purpose. Unfortunately, the > highest-profile languages by GCC don't use Bison IIRC. It is IMO impractical to expect that this particular development will be advanced by Emacs. Emacs is the main interested party in this development, but our knowhow is nowhere near what is needed for any serious hacking of GCC internals, especially on the level of GIMPLE representation. By contrast, improving infrastructure for this written in Emacs Lisp is a much more practical solution, especially since it already exists and does its job. It is IMO silly not to exploit the potential we have there. > An any rate, it is a much more realistic goal to get 60% of all computer > users to use GCC than it is to get 60% of all computer users to use > Emacs. That's not the correct comparison, IMO. We are talking about a user who already has Emacs and uses it, and who will be using it even if those advanced features will not be available. When that user doesn't have, or cannot use GCC, asking her to install GCC is not practical at best. > We have the statement here (and far too little attention has been paid > to it) that -fdump-xref and associated programs of the GNAT project > would do the trick for the editing task currently at issue. So there is > a prototype people could be testing and experimenting with instead of > doing flame wars. I agree that prototyping and comparative testing would be a much better use of time and efforts invested in this discussion (and many others similar to it). But the question that bothers me is what would be the next step? It is almost certain that trying to use that option will discover shortcomings -- who will fix them when they are found? Unless GCC as a project supports that option and is willing to maintain and improve it, we are again at a dead end. > > This is IMO > > the preferred direction: make Emacs features depend on nothing but > > Emacs packages. [...] > > If we need policy decisions in this matter, _that_ is the only one > > that should be made. To me, it is almost a no-brainer; I wonder why > > it is not clear-cut to others here. > > Well, that is not really much in need of a policy since Emacs can > support multiple feature sets. Emacs can only support features that exist for which the corresponding front ends were written in Emacs Lisp. I don't quite see those queuing up for providing the features we are discussing. So there are no multiple feature sets to support, as yet. When several potential ways exist for implementing a feature, it is the task of the project leadership to define the preferences, and then encourage volunteers to go in those directions that are preferred. These are the policy decisions I alluded to. They should remove the confusion over what we want as a project, and let volunteers work in those directions without risking that their work will not be used. > I would prefer if we needed no policy decisions at all in this > matter. We don't get that, obviously. But my next preference is to > have GCC move/develop in a manner where we would not have needed a > policy decision. I think it is impractical to base our development on something extremely non-trivial that another project needs to do. Read the GCC mailing lists, and you will see that the current focus of the project is very different. Why should we build our plans on the slim hope that this focus will change? It makes very little sense to me. OTOH, we have a potentially viable solution at our fingertips, and we have it _now_. Why trade that for some unsubstantiated hope? > In other words: things are going wrong with GCC policies upstream > regarding reusability in Free Software applications that Emacs, as one > compiler user, is too small too fix. And we shouldn't. If GCC acquires these features, we should support them then, but no earlier. > If this is not approached in a more general manner in GCC, we'll have > this problem reoccuring in various iterations on the Emacs list, and it > will be reoccuring for the maintainers other Free Software which will > then choose to pick non-copyleft compilers entirely instead of playing > mix-and-match games or writing their own parsers. This is a GCC problem, and GCC as a project should solve it. It could also be serious enough to become a general problem for the GNU Project, in which case the FSF should work together with the GCC project on resolving it. Emacs cannot do anything constructive to speed up that resolution. The only constructive way open to us for now is to use CEDET; let's not wait and do it sooner rather than later. If we do that now, then by the time GCC developers get their act together, we will either have an alternative solution against which to measure theirs, or at least the necessary front-end for interfacing with them, and enough knowhow to present them with suitable requirements and to integrate their solution into Emacs. In both cases, we win. The alternative is to effectively do nothing, or, worse, continue these flame wars.