bugGforth - Bugs: bug #54559, Remove support for obsolete Emacsen


bug #54559: Remove support for obsolete Emacsen

Submitted by:  Reuben Thomas <rrt>
Submitted on:  Thu 23 Aug 2018 10:48:05 AM UTC  
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 09 Jun 2020 08:34:48 AM UTC, comment #6: 

Ping? If dealing with updates is not a priority for the GForth maintainers (which is fine, of course!), then would you be happy if I distributed (and maintained) a version on ELPA? You could deprecate the version shipped with GForth, and document that it is retained for old Emacsen, while users of current Emacsen should use the ELPA version.

Reuben Thomas <rrt>
Fri 08 Feb 2019 05:34:40 PM UTC, comment #5: 

Thanks for getting back to me, Anton!

I do not plan to add features. See the attached patch: it mainly removes ancient commented-out code so that the rest is easier to read, and removes some code that fills gaps in pre-Emacs 21, which is no longer needed.

There are a few other things that are noticeable: for example, on recent Emacsen (and computers) it seems sensible to default jit-parsing to t rather than nil. Another issue that I have come across in recent Emacsen, for example, is that forth-find-tag does not work for me, and indeed find-tag itself is deprecated; however, simply using the default xref-find-definitions works fine with current etags -l forth. So again, I have simply removed this code. I've filed a bug about forth-blocks-mode (#48406), and that would again be easier to look into in a cleaned-up gforth.el.

I would be quite happy with your suggestion of maintaining compatibility with pre-Emacs 21 by in that case loading an older version which itself is essentially frozen.

Reuben Thomas <rrt>
Fri 08 Feb 2019 03:22:24 PM UTC, comment #4: 

We are currently not adding features to gforth.el, so we do not feel the pain of maintaining backwards compatibility at the moment.  We have machines from the early 1990s that surely have not been upgraded to Emacs 21; but OTOH, they are turned on only when needed (e.g., for release-testing Gforth), and I probably won't run emacs with the latest gforth.el on them.

Anyway, do you plan to submit patches for adding features to gforth.el?  What do you have in mind?

One way to combine the desire to support legacy stuff with the desire to avoid checking the version in all new code would be to have a version switch at the start (or after common code, such as forth-words); on version<21, just load gforth-legacy.el (the current version); on new emacsen, load the newer code.

Anton Ertl <anton>
Project Administrator
Fri 08 Feb 2019 12:58:08 PM UTC, comment #3: 

Hi, I tried to address Anton's concerns in my comment of 27th August 2018. Any response? As I say, my patch does not remove any interfaces, and it remains compatible with Emacs versions up to 20 years old or so.

I'm finding other problems with gforth.el on newer Emacsen, and as I said before, it's more trouble than it is worth to me to maintain compatibility both with Emacs 19 and with Emacs 26.

I would be quite happy to make a friendly fork of gforth.el if my approach is not compatible with gforth upstream, and distribute it via ELPA, retaining support for all Emascen that can access ELPA.

Reuben Thomas <rrt>
Mon 27 Aug 2018 08:03:42 PM UTC, comment #2: 

I didn't mean to imply that support for old versions was a bug. Since the GForth project doesn't have a patch tracker, I posted my patch on the bug tracker.

The benefit of this patch is that it makes the code shorter, and making it possible to use features of newer Emacsen without workarounds, by defining a later minimum version of Emacs; in this case, 21.

Emacs 21 was released almost exactly 19 years ago; the oldest version on ftp.gnu.org is 21.4a, from 2005. The oldest version of Emacs supported by a supported version of Debian GNU/Linux is 23. Thus, the new version is unlikely to inconvenience users.

I have not removed any interfaces.

Reuben Thomas <rrt>
Mon 27 Aug 2018 07:22:12 AM UTC, comment #1: 

Support for old software is not a bug.  On the contrary, I find it annoying when I try to run old software on a new machine, and it does not work because the software on the new machine has old interfaces removed; or when I try to run new software on an old machine, and it does not work because the new version of the software has removed support for old interfaces.

What would the benefit of this patch be?

Anton Ertl <anton>
Project Administrator
Thu 23 Aug 2018 10:48:05 AM UTC, original submission:  

I attach a patch against git's gforth.el to remove support for obsolete Emacsen (older than Emacs 21).

Also remove some commented-out code that it doesn't seem will ever be resurrected.

If this patch or something based on it is acceptable, I'd be happy to submit further clean-up patches.

Reuben Thomas <rrt>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by rrt (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-23 rrt Attached File- => Added remove-obsolete-emacsen-support.patch, #44833

    Back to the top

    Powered by Savane 3.5