Re: finding the hork point in ~/.emacs

[ken <gebser@mousecar.com>]

On 8/26/20 4:52 PM, Emanuel Berg via Users list for the GNU Emacs text
editor wrote:
> ken wrote:
>
>> In another thread I spoke too soon about my
>> ~/.emacs fully working.  A lot of it isn't being
>> executed.  This, to my understanding, means that
>> some code is no longer working (since my recent
>> emacs upgrade).  Is there some really good method
>> or log file or something else which would help
>> finding where the hork point is?
> You can do the so-called binary search, which is
> a fancy name for this method
>
>   code_1
>   code_2
>   code_n
>   code_m
>
> then do
>
>   code_1
>   code_2
>   ;; code_n
>   ;; code_m
>
> if it still doesn't work, problem is in 1 or 2, so
>
>   code_1
>   ;; code_2
>   ;; code_n
>   ;; code_m
>
> if it ... etc

Yes, good.  I know that technique, and I think it's better known as,
"isolating the problem."  I've done lots of error chasing using that
method, not only looking at code, but also looking for a problem with a
car, or in my house's electrical system, fixing the washing machine,
lots and lots of places.  Everywhere really.  However, my ~/.emacs is a
bit over a thousand lines long (well, more than half is probably
documentation, but still), a lot of code to look at line by line, even
if the binary method narrows it down to roughly a third of those lines.

What I've done in the past and could still do:  I put a line in my
~/.emacs like this:

(set-cursor-color "red") ;;if cursor isn't the spec'd color, error is above

In fact, I can put two or three such lines in my code, using different
colors (blue, limegreen, whatever), telling me (very approximately)
where the problem is depending upon what color the cursor is.  It's also
much easier to find and remove-back-to-normal my .emacs.  But frankly,
with so much code, even this method is still tedious.

Most programming languages has some facility which actually pinpoints,
down to the line, sometimes down to the character, where a coding error
is, at least where the compiler or interpreter thinks it is.  I thought
shure elisp would have something like that.

>
> And: the better you write the code to begin with, the
> better this method will work :)

The code in my ~/.emacs (and elsewhere) has been working fine for
years.  It's only when I do a major upgrade to emacs that I have these
problems... for some strange reason newer emacs versions remove working
functions that my code uses, so obviously it's not going to work
anymore.  I've been using C and bash as my two main progamming platforms
for decades and have never had such a problem.  Bash is planning on
obsoleting some small bit of code, but they've been warning people about
it for over five years now.  That much is considerate.  On the other
hand, I wrote one small piece of code in Tk/Tcl and another for Gnome
and both of them made changes which obsoleted support code (or
libraries) which made my code useless.. so I doubt I'll ever write code
for either of those platforms again.  Same reason I'd never choose to
live in a hurricane zone.