Re: IDE

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "John Wiegley" <johnw@newartisans.com>
>> Date: Fri, 16 Oct 2015 15:58:57 -0700
>> 
>> >>>>> Dmitry Gutov <dgutov@yandex.ru> 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