Coding bug in insert-file-contents-internal

[David Kastrup]

Nix <nix at esperi.org.uk> writes:

> but the single largest RSI-saver (voice recognition) doesn't work
> well when you enunciate as poorly and variably as I do. So a Maltron
> keyboard it is, and now, after only a few weeks, I can't imagine why
> these keyboards aren't in use *everywhere*.  They whip the flat
> pasty white rear of QWERTY keyboards. :)

Please remember that the "R" in "RSI" stands for "repetitive".  RSI is
something you can't predict after only a few weeks.  The question is
what will happen once your usage patterns and motoric patterns
stabilize.

>>     nix> Finsert_file_contents_internal: would that be acceptable?
>>     nix> If it is, I can spin a patch in the next day or so.
>> 
>> I don't know if it would be acceptable; I'll need to make time to
>> look at this and I also want a second opinion from "Dr." Wing.  I
>> would
>
> Please! The last thing I want to do is cause a repeat of the
> XEmacs-21.4.8 fiasco.

A little fiasco now and then builds character.

>> appreciate having a patch to look at without promising application,
>> but that's up to you.
>
> Will do...
>
> This is a completely tentative patch, bceause I'm still not quite clear
> on the interactions of bindings, GCPRO, unwind-protect and the like in
> the C layer. I *think* it's pointless to specbind() DEFVAR_LISPed
> variables, because it seems to me that this would break the magic link
> between the C variable and the Lisp symbol --- the magic forwarding
> symbol would wind up on the specbinding stack --- and the C code uses
> the variable...  so I've tried to record_unwind_protect it instead. I'm
> not quite sure if I've done it right, or if I need to GCPRO something (I
> don't think so: stuff on the specbinding stack and stuff in
> DEFVAR_LISPed variables are both found by the garbage collector anyway,
> right?)  record_unwind_protect()?)

Hopeless.  Let me summarize this, you guilt-ridden pest[1]:

a) you have recently had some bit of recovery from severe RSI
b) this RSI has struck as bad as to cut you off from computer related
   work pretty much completely
c) you have provided all the necessary details for the bug now,
   describing it very completely so that people in the know can
   recognize what to do and do it easily enough.
d) you show a lack of clue about the involved internals
   yourself.  So you obviously have to experiment around a lot, which
   involves typing a lot, leafing through computerized documentation
   and code a lot, prepare a complete patch including changelog entry
   without even knowing whether the resulting code actually is the
   right thing to do.

One ought to whack you with your Maltron keyboard.  Though that may be
just what you are in effect doing yourself.

With regard to RSI avoidance and speech recognition: there is just
that _amazing_ speech recognition technology that can deal with
varying pronunciation by using specialized dictionaries.  You may even
have one of the specialized speech access devices around somewhere.  I
happen to know that the access code for AUCTeX/preview-latex-related
dictionaries is 0049234680713.

So will someone please pick up what Nix provided here and finish the
matter off before he incapacitates himself over it?

I am completely clueless about the matter at hand, but since dired and
stuff are probably supposed to be loosely synchronized with Emacs and
I can't remember having seen any symptom like this on Emacs, maybe
some approach to the problem that the faulty code/hooks are supposed
to be dealing with could be gleaned from there, too.

Whatever.  Somebody else may want to take a look there.

Anyway, glad to hear you are around after all.  Don't you worry too
much about us.  You have no cause to feel worse than the many people
that would not even have thought of starting to help in the first
place.

Footnotes: 
[1]  Not that the preview-latex project has not profited from it.
Feeling guilty about XEmacs not doing preview-latex was what got you
on the project on the first place.  All other developers were also
active users of the software.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum