From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Rename headline to heading
Date: Mon, 16 Aug 2021 09:17:00 +1000 [thread overview]
Message-ID: <877dgmi89p.fsf@gmail.com> (raw)
In-Reply-To: <sfc4lm$ggf$1@ciao.gmane.io>
Jim Porter <jporterbugs@gmail.com> writes:
> On 8/14/2021 3:54 PM, Tim Cross wrote:
>> I'm not convinced a transition period will help in this case. At some
>> point, users will need to update their capture templates regardless.
>> Provided this impact is clearly outlined in the NEWS.org file (I think
>> there should be a specific reference to capture templates added in the
>> patch to NEWS.org) and provided this change is applied to the next
>> release only, no transition period is necessary.
>
> I think having a transition period would be helpful here. First, this helps to
> account for users who may run multiple versions of Emacs with the same config.
> This could happen for a few reasons, such as running on different revisions of a
> GNU/Linux distribution, or even just because the user is testing out the
> latest/next version of Emacs.
>
> In addition, a transition period makes it easy to inform users about what they
> need to do to upgrade. Without any compatibility code, the error message
> (likely) won't be very helpful, whereas even some minimal compatibility code
> could tell the user what edits to make to their config. While everyone *should*
> read the manual/NEWS, it's easy to miss things sometimes, and errors like this
> can be non-obvious, especially if the compatibility issue isn't directly in the
> user's config, but in some other third-party package.
>
> As such, I think it would be nice to have a transition period of at least one
> Emacs version. Beyond that, I don't see any problems with excising old
> compatibility code. As you say, users will have to upgrade at *some* point.
>
While I understand the intent here, I think it is a false sense of
helpfulness.
At some point, your transition period will end. If it isn't with the
transition to v9.5, it will be the transition to 9.6. At this point, all
of the issues you point out will still exist. There will still be people
who are running multiple versions, there will still be people who failed
to read or comprehend the impact of the change. All that the transition
does is delay the pain point while adding additional complexity to the
code base. Admittedly, in this case, the additional complexity is very
small.
I would certainly agree that we should try to make the error message as
informative as possible. However, that should be a general aim anyway
and if the error messages are not sufficiently informative, they should
be improved. Poor error messages are frequently a greater source of
frustration than unexpected change. Today I have been fighting with a
javascript library where the error message literally just says "Failure"
- absolutely pointless error message which adds nothing. In fact, it
would be better if there was no error handler and it just crashed with a
stacktrace.
This is a change in the transition to a new major version. I think users
should be prepared for breaking changes when upgrading to a new major
version. If it was a minor version change, a transition would be
mandatory. .
A transition period also delays the goal for this change i.e. to improve
consistency in terminology and concepts.
next prev parent reply other threads:[~2021-08-15 23:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 12:12 [PATCH] Rename headline to heading André A. Gomes
2021-08-05 15:04 ` Maxim Nikulin
2021-08-14 22:54 ` Tim Cross
2021-08-15 16:22 ` No Wayman
2021-08-15 16:50 ` No Wayman
2021-08-15 22:32 ` Jim Porter
2021-08-15 23:17 ` Tim Cross [this message]
2021-08-16 0:38 ` Jim Porter
2021-08-16 1:18 ` Tim Cross
2021-08-08 16:59 ` Tom Gillespie
2021-08-14 23:19 ` Tim Cross
2021-09-19 11:06 ` Timothy
2021-09-30 12:08 ` André A. Gomes
2021-09-26 9:27 ` Bastien
2021-09-30 12:21 ` André A. Gomes
2021-10-01 8:38 ` Bastien
2021-10-15 8:52 ` André A. Gomes
2021-10-15 9:56 ` Timothy
2021-10-15 10:18 ` André A. Gomes
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 \
--in-reply-to=877dgmi89p.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).