From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 17 Oct 2015 10:39:51 +0200 Message-ID: <87h9lpriqw.fsf@fencepost.gnu.org> References: <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <871tcyexa9.fsf@fimbulvetr.bsc.es> <87612a7my2.fsf@fencepost.gnu.org> <561DC925.5050001@siege-engine.com> <561E32D2.4060501@yandex.ru> <83wpum3ozk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445096670 667 80.91.229.3 (17 Oct 2015 15:44:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:44:30 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 17:44:29 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 1ZnTem-0000wc-NR for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 17:44:28 +0200 Original-Received: from localhost ([::1]:58782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTel-00021o-N1 for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 11:44:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTeg-00021N-Uv for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:44:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnTef-0007dm-65 for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:44:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTef-0007dg-33; Sat, 17 Oct 2015 11:44:21 -0400 Original-Received: from localhost ([127.0.0.1]:41973 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZnTee-0000Dg-4u; Sat, 17 Oct 2015 11:44:20 -0400 Original-Received: by lola (Postfix, from userid 1000) id 543D2E0DB0; Sat, 17 Oct 2015 10:39:51 +0200 (CEST) In-Reply-To: <83wpum3ozk.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Oct 2015 10:58:55 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:191838 Archived-At: Eli Zaretskii writes: >> From: "John Wiegley" >> Date: Fri, 16 Oct 2015 15:58:57 -0700 >> >> >>>>> Dmitry Gutov writes: >> >> > My already-stated impression is that it's over-specialized and tightly >> > coupled. >> > >> > Not saying that the problem domain is easy, but being able to use different >> > pieces of the solution separately would go a long way towards alleviating >> > the complaint that certain other parts are incomplete. >> > >> > Especially if it were easier to swap in different solutions for some of >> > those parts (and do entirely without some others), and do that in not too >> > many lines, all as part of the user's configuration. >> >> You've taken the reply right out of my mouth, Dmitry. David's response was >> also very much in line with my thinking. As I said before, if CEDET were the >> answer to our questions, we wouldn't still be asking them. > > Could it be that we don't understand the answer? > > I'd suggest to be very careful with such conclusions. They can only > be valid when based on a detailed analysis of what is and isn't in > CEDET, and on good knowledge and understanding of its design and > implementation. If we wanted that, we would be using vi. The amount of functionality available with Emacs is so diversified that it needs to fall apart into pieces that can be comprehended on their own with reasonable effort. Actually, I am being cheeky here: a morning with vi documentation will get you set. A week with CEDET documentation won't. An IDE is principally a tool that is supposed to make things easier for the programmer and let him figure out fewer things on his own rather than more. CEDET didn't do that for me. I'm old and experienced enough that I have the arrogance to claim that something that is too hard for me to understand and/or use effectively after putting in a reasonable amount of effort is not a generally useful tool. > My impression so far is that neither is particularly true, and my > evidence is the number of times Eric and David Engster described some > CEDET features that came as a surprise to us. Is that supposed to be a good thing? > I'm quite sure CEDET has collected and expressed in code a lot of > experience and solutions to many problems that arise in the context of > building an IDE. It's OK to discard that, if we sure that's the > proverbial 1st variant everyone throws away, but we need first to be > sure we know what we are discarding. I am not qualified to have much of an opinion about the substance, the raw functionality implemented in CEDET. That's probably 90% of the work, and redoing that will not likely make a decisive difference with regard to the remaining 10% that are for putting that functionality at the fingertips of the programmer. My refactoring work tends to be done using stuff like git grep '^MAKE_[_A-Z]*SCHEME_CALLBACK[_A-Z]* ' lily|sed -n 's/^\([^:]*\):MAKE_[_A-Z]*SCHEME_CALLBACK[_A-Z]* (\([^,]*\), \([^,]*\), \([^)]*\)).*$/\1 \2 \3 \4/p' | while read file class name args do argname=$(sed -n "s/^$class::$name (SCM \\?\\([^,)]*\\)[,)].*\$/\\1/p" $file) sed -i "/^\\(class\\|struct\\) $class\\( {\\)\\?\$/,/^}/s/^\\( *DECLARE_\\)SCHEME\\(_CALLBACK ($name, (\\)SCM[^,)]*\\(, \\)\\?/\\1MEMBER\\2/" $(git grep -l "^\\(class\\|struct\\) $class\\( \\|\$\\)") && case "$argname" in [a-zA-Z]*) thisexpr=$(echo "unsmob<[_a-zA-Z]*> *($argname)" sed -n "/^$class::$name (/,/^}/s/^ *\\([_a-zA-Z]\\+\\) *\\* *\\([_a-zA-Z]\\+\\) *= *unsmob *<\\1> ($argname);\$/\\2/p" $file | while read alias do sed -i "/^$class::$name (/,/^}/{/^ *\\([_a-zA-Z]\\+\\) *\\* *$alias *= *unsmob *<\\1> ($argname);\$/d;}" $file echo $alias done) thisexpr=$(echo "$thisexpr"|sed -n '1h;1!H;${x;s/\n/\\|/g;p}') sed -i "/^$class::$name (/,/^}/{s/\\b\\($thisexpr\\)\\b/this/g;s/\\bthis *-> *//g;s/\\*this\\.//g;}" $file sed -i "s/^\\(MAKE_[_A-Z]*\\)SCHEME\\(_CALLBACK[_A-Z]* ($class, $name,\\)/\\1MEMBER\\2/ s/^\\($class::$name (\\)SCM \\?[^,)]*\\(, \\)\\?\\(.*\\)\$/\\1\\3/" $file ;; *) sed -i "s/^\\(MAKE_[_A-Z]*\\)SCHEME\\(_CALLBACK[_A-Z]* ($class, $name,\\)/\\1MEMBER\\2/ s/^\\($class::$name (\\)SCM \\?[^,)]*\\(, \\)\\?\\(.*\\)\$/\\1\\3/" $file esac # sed "/^MAKE_SCHEME_CALLBACK ($class, $name, $args)/d; # echo $file $class $name $args $argname $argtype $param done Yes, this is for real, bulk rewriting certain types of static member functions into proper member functions, changing certain constructs systematically while doing that. Doing that kind of stuff requires knowing about 5 pages of sed programming and shell programming that mostly worked already 20 years ago (quoting constructs have become more robust). I don't relish doing stuff in that manner. It's not the kind of job an automated tool could do easily, but an automated tool could at least find the code that needs changing and possibly even offer some way to do replacements that are a bit more syntactically conscious than sed. I've had bulk changes touching several thousands of lines and I prefer investing two days into creating a one-shot automated tool than 6 hours doing everything manually. I'm pretty sure that somewhere between those two-days sed scripting and 6 hours of completely manual work there must be a sweet spot where an IDE/refactoring/thing-aware tool tied into Emacs should save both time and nerves. M-x grep RET works a lot smoother than M-! grep and the kind of difference between the two are where Emacs shines, providing the editor connection to technology. -- David Kastrup