bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

[Par Kurlberg]

Hi,

This is perhaps more of a feature request than a bug report, but only
luck prevented me from being bitten badly:

When upgrading from emacs24 to emacs26 I found out the hard way that
mark-diary-entries-in-calendar has been removed, and replaced by
calendar-view-diary-initially-flag . The last week I've been puzzled
about missing a few, fortunately not too important, meetings, and
thinking "what, I thought I put that in my emacs diary file?!".  When an
upcoming important meeting, that I strongly recalled putting into the
diary, was not indicated in the calender (i.e., the days are usually
marked by red) I started digging and found out about the now completely
obselete variable.

Of course, in theory I've been amply warned - the documentation states
"mark-diary-entries-in-calendar is obsolete since 23.1".  However, given
that anyone who relies on keeping track of meetings via
emacs/diary/calender easily might miss a few meetings before noticing
this, perhaps emacs26+ could warn if mark-diary-entries-in-calendar is
true whereas calendar-view-diary-initially-flag is unset?

More generally, some sort of mechanisms for "important" upgrade warnings
on obsolete variables having been removed would be very helpful, but it
is perhaps hard to figure out / agree on exactly what are "important
enough" changes.

Best,
Pär

PS: Missing unimportant meetings is perhaps a feature rather than a
bug. :-)


In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian built on lcy01-amd64-020
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description:	Ubuntu 20.04.1 LTS

bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

[Lars Ingebrigtsen]

Par Kurlberg <kurlberg@math.kth.se> writes:

> Of course, in theory I've been amply warned - the documentation states
> "mark-diary-entries-in-calendar is obsolete since 23.1".  However, given
> that anyone who relies on keeping track of meetings via
> emacs/diary/calender easily might miss a few meetings before noticing
> this, perhaps emacs26+ could warn if mark-diary-entries-in-calendar is
> true whereas calendar-view-diary-initially-flag is unset?
>
> More generally, some sort of mechanisms for "important" upgrade warnings
> on obsolete variables having been removed would be very helpful, but it
> is perhaps hard to figure out / agree on exactly what are "important
> enough" changes.

Yeah, I don't think this is generally possible.  The variable in
question was obsoleted about a decade ago, which should be sufficient
time for people to adjust.  Adding more code to Emacs to warn people
about things happening that far in the past would not be productive use
of our time.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yeah, I don't think this is generally possible.  The variable in
  > question was obsoleted about a decade ago, which should be sufficient
  > time for people to adjust.  Adding more code to Emacs to warn people
  > about things happening that far in the past would not be productive use
  > of our time.

The event that causes these problems to happen _now_
was the deletion of the variable, which we did recently.
Given that the problems that result are silent and mysterious,
we should look for ways to help the people affected,
not reasons to justify not doing so.

One way would be to check, after loading the init files,
whether that variable exists.  If it does, pop up buffer
to call users' attention to the problem, with advice.
We could put that in Emacs 27.2, and remove it in Emacs 29.

That is the fix that occurred to me.  It is pretty easy.
If someone finds a better fix, by all means let's use that.
But there is no reason to even considered doing nothing about this.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> One way would be to check, after loading the init files,
> whether that variable exists.  If it does, pop up buffer
> to call users' attention to the problem, with advice.
> We could put that in Emacs 27.2, and remove it in Emacs 29.

I don't think futzing around like this is good use of our limited
resources.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43537: 26.3; "lost" diary entries - mark-diary-entries-in-calendar obsolete

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > One way would be to check, after loading the init files,
  > > whether that variable exists.  If it does, pop up buffer
  > > to call users' attention to the problem, with advice.
  > > We could put that in Emacs 27.2, and remove it in Emacs 29.

  > I don't think futzing around like this is good use of our limited
  > resources.

When our change causes users problems, that is a bug.
Doing a good job includes fixing such bugs.  We should
fix that bug before we make more changes

Since this fix would do it with a small amount of work, that would be
very efficient use of our resources.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)