Subject: bug#69171: Moving packages out of core to ELPA

From: JD Smith <[email-masked]>
Date: Sat, 24 Feb 2024 16:27:46 -0500

Just a brief update.  I updated the version to 6.5.0 across the board, and squashed a few compiler complaints.  In some simple testing of idlwave-mode (only in the buffer for .pro files) everything seems to be working well.  I am fairly critical of my old idea to refactor everything, but that's where we are.  It's a bear to compile everything without putting it on the load-path (I'm curious if you just append to the load-path when dealing with this kind of thing).

Because of stupid licensing issues, I will have to wait more than a week to test idlw-shell capabilities (which are more complex and therefore more likely to encounter issues).  Will do more testing and fix any encountered errors, then we can proceed with the ELPAfication.  At that point there will be a good argument to remove from core: the ELPA version will be the superset of my changes over a decade and those from core.

> On Feb 20, 2024, at 9:12 AM, JD Smith <[email-masked]> wrote:
> 
> Thanks for your work on this.  I encountered just a few merge conflicts.  Most had to do with assoc-ignore-case -> assoc-string, which I had already fixed on my local repo, and loop -> cl-loop as well. 
> 
> I unarchived my repo and pushed these changes to a new branch: https://github.com/jdtsmith/idlwave/commits/emacs-upstream-merge/.  
> 
> I will look into the compiler results, fix those up, and give it a test in the next week or so.
> 
> 
>> On Feb 19, 2024, at 6:06 PM, Stefan Monnier <[email-masked]> wrote:
>> 
>>> I agree.  I think this has even been suggested before, but I don't have the
>>> resources to take it on myself (though I'm happy to test it).  Maybe it's
>> 
>> Can you test the patch below (which basically applies the
>> diff between commits 627e0a14e87 to 77576cd7626e on `emacs.git).
>> Clearly, the code reorg made the work harder.
>> 
>> But it's a bit worse: the split chosen for the reorganization tends
>> to create circular dependencies (e.g. all the files need to depend on
>> `idlw-variables`, so `idlw-variables` can't depend on anything at all).
>> So it's harder to get rid of all the warnings.
>> 
>> I also attach the warnings resulting from compiling the code (after
>> applying the patch).
>> 
>> 
>