From: Timothy <email@example.com> To: Bastien <firstname.lastname@example.org> Cc: Matt Huszagh <email@example.com>, firstname.lastname@example.org, Nicolas Goaziou <email@example.com> Subject: Re: Supported Emacs version Date: Mon, 22 Nov 2021 14:12:44 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 1373 bytes --] Hi Bastien, >> I’m tempted to make some patches to remove all the Emacs < 26 >> compatibility code if we no longer need it. What do you think? > > We should NOT remove this code: many people probably use/need it. > > Anything that helps keeping Org compatible with Emacs < 26 is > still useful, the more compatible the better. > > If for some reason, some backward-compatibility code becomes too > difficult to maintain then perhaps yes we can remove it, but not > before. Hmm, I’m not entirely sure what to think here. On one hand, I very much agree with you that it’s better if Org is compatible with older versions just by having a bit of extra code left in org-compat.el. However, if many bits of Org use Emacs 24/25/26 functions that /aren’t/ covered in org-compat.el (as I think is currently the case) that leads to bits of Org that are covered by org-compat.el and bits that aren’t, and so I imagine this currently produces inconsistently buggy behaviour in old versions of Emacs. If this were just a question of fully supporting older Emacs versions at no extra cost, I’d be inclined to respond as you have, but I think the problem we really have is whether it’s better to provide /partial/ support for older versions of Emacs? Personally I’m more inclined towards an all-or-nothing approach. All the best, Timothy
next prev parent reply other threads:[~2021-11-22 6:19 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-21 18:41 [PATCH] Fix window width when line numbers present Matt Huszagh 2021-11-21 19:14 ` Timothy 2021-11-21 21:08 ` Nicolas Goaziou 2021-11-21 21:14 ` Matt Huszagh 2021-11-21 21:16 ` Bastien 2021-11-21 21:22 ` Matt Huszagh 2021-11-22 5:14 ` Bastien 2021-11-22 5:31 ` Timothy 2021-11-22 5:44 ` Bastien 2021-11-22 5:51 ` Supported Emacs version (was: [PATCH] Fix window width when line numbers present) Timothy 2021-11-22 6:05 ` Supported Emacs version Bastien 2021-11-22 6:12 ` Timothy [this message] 2021-11-22 6:39 ` Bastien 2021-11-22 8:04 ` Timothy 2021-11-22 10:26 ` Bastien 2021-11-22 11:55 ` [PATCH] Fix window width when line numbers present Ihor Radchenko 2021-11-22 12:40 ` Tim Cross 2021-11-23 5:59 ` Bastien 2021-11-23 7:05 ` Tim Cross 2021-11-22 3:16 ` Timothy 2021-11-21 19:19 ` Timothy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Supported Emacs version' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).