bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Richard Stallman]

C-h f dired-hide-details-mode says

  Probably introduced at or before Emacs version 24.4.

Why doesn't it _know_ precisely which versiob that function was
introduced in?  It was only a few versions ago, so this was not
something lost in prehistory.  What causes the uncertainty?



In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32, cairo version 1.15.10)
 of 2021-05-12 built on freetop
Repository revision: 47070ed39eda524d334e5f82dc7f4a50b8d3252c
Repository branch: master
System Description: Trisquel GNU/Linux Etiona (9.0)

Configured using:
 'configure --with-gnutls=ifavailable 'CFLAGS=-g -O0''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GPM GSETTINGS HARFBUZZ JPEG LIBOTF
LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug cl-print dired-x rect unrmail time-stamp smerge-mode
diff vc vc-dispatcher texinfo texinfo-loaddefs eieio-opt speedbar
ezimage dframe find-func shortdoc help-fns radix-tree novice
two-column kmacro etags fileloop generator xref project ispell
compare-w diff-mode easy-mmode cl-extra parse-time iso8601 vc-cvs
mhtml-mode css-mode smie eww xdg url-queue mm-url gnus nnheader
wid-edit color js imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode facemenu
mule-util format-spec battery dbus misearch multi-isearch epa-mail
dabbrev rmailkwd rmailout quail help-mode jka-compr shell pcomplete
thingatpt files-x grep compile comint ansi-color ring rmailsum
mailalias shr kinsoku svg xml dom sendmail qp rmailmm message rmc puny
rfc822 mml mml-sec epa epg epg-config gnus-util text-property-search
time-date mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader mail-parse rfc2231 rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils dired-aux dired
dired-loaddefs t-mouse term/linux view derived paren cus-load advice
finder-inf package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet
lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese composite charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 640240 128758)
 (symbols 48 18299 8)
 (strings 32 81921 18767)
 (string-bytes 1 4331746)
 (vectors 16 47013)
 (vector-slots 8 1315534 161084)
 (floats 8 241 358)
 (intervals 56 91315 5202)
 (buffers 992 95))
[[[ 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. ]]]

bcc: rms-outgoing@gnu.org
Reply-To: rms@gnu.org


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

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 18 Jul 2021 20:08:29 -0400
> 
> 
> C-h f dired-hide-details-mode says
> 
>   Probably introduced at or before Emacs version 24.4.
> 
> Why doesn't it _know_ precisely which versiob that function was
> introduced in?  It was only a few versions ago, so this was not
> something lost in prehistory.  What causes the uncertainty?

The feature works by searching the etc/NEWS* files, and finding a
symbol there doesn't necessarily mean the Emacs release in which it's
mentioned is the actual release where the symbol was introduced.  For
example, we sometimes forget to announce features and only do that
later.  Thus the uncertainty and the cautious language.

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> C-h f dired-hide-details-mode says
>> 
>>   Probably introduced at or before Emacs version 24.4.
>> 
>> Why doesn't it _know_ precisely which versiob that function was
>> introduced in?  It was only a few versions ago, so this was not
>> something lost in prehistory.  What causes the uncertainty?
>
> The feature works by searching the etc/NEWS* files, and finding a
> symbol there doesn't necessarily mean the Emacs release in which it's
> mentioned is the actual release where the symbol was introduced.  For
> example, we sometimes forget to announce features and only do that
> later.  Thus the uncertainty and the cautious language.

And Richard may not know that we've discussed, innumerable times, whether
we should maintain an actual registry to avoid the guessing, and we've
concluded that this would be too much work.

Which is still the conclusion.

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

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[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. ]]]

  > The feature works by searching the etc/NEWS* files, and finding a
  > symbol there doesn't necessarily mean the Emacs release in which it's
  > mentioned is the actual release where the symbol was introduced.

I think we can implement an efficient, accurate, automatic way to
determine which release each function appeared in.

We could run a script on each Emacs release to find all the function
definitions in it, then make a sorted list of their names.  By
comparing these, we can find for each function the first release it
was defined in.

We only need to scan each release once, all in the same way.  We would
scan the old releases at the start, and scan each new release when it
is made, adding new functions to the records.

There could be a few functions for which that does not give correct
results, as they were defined in weird ways.  We could add those
functions manually to the records.  Since they won't be many, we could
afford to do that by hand.

Scanning a new release will never alter the information about
functions in previous releases, so once we have fixed an exception, it
will stay fixed.

We don't have to include these records in the release.  It's enough to
compare them with the results of checking the NEWS files.  Then
generate a file listing the exceptions: functions whose first release
differs from the result obtained by checking NEWS files.  It should be
short.

help-fns--first-release could check that file of exceptions first.

Then it could state its results as exact, not an approximation.

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

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: 49631@debbugs.gnu.org
> Date: Tue, 20 Jul 2021 20:52:12 -0400
> 
> I think we can implement an efficient, accurate, automatic way to
> determine which release each function appeared in.
> 
> We could run a script on each Emacs release to find all the function
> definitions in it, then make a sorted list of their names.  By
> comparing these, we can find for each function the first release it
> was defined in.
> 
> We only need to scan each release once, all in the same way.  We would
> scan the old releases at the start, and scan each new release when it
> is made, adding new functions to the records.
> 
> There could be a few functions for which that does not give correct
> results, as they were defined in weird ways.  We could add those
> functions manually to the records.  Since they won't be many, we could
> afford to do that by hand.
> 
> Scanning a new release will never alter the information about
> functions in previous releases, so once we have fixed an exception, it
> will stay fixed.

Yes, this could work.  Patches are welcome to implement this.

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> There could be a few functions for which that does not give correct
> results, as they were defined in weird ways.  We could add those
> functions manually to the records.  Since they won't be many, we could
> afford to do that by hand.

I see you're using the word "we" a lot here -- are you volunteering to
do this work?

If there's one thing Emacs doesn't need, it's yet more formalism around
adding/changing functionality.

We already have a procedure for this that is more than 99% accurate.
Adding all this work for getting to 100% and being able to remove the
word "probably" in the *Help* buffers seems like a very strange
prioritisation.

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

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I see you're using the word "we" a lot here -- are you volunteering to
> do this work?

(Sorry for the tone here -- that came off way more grouchy than I had
intended.)

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

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> C-h f dired-hide-details-mode says
>>>
>>>   Probably introduced at or before Emacs version 24.4.
>>>
>>> Why doesn't it _know_ precisely which versiob that function was
>>> introduced in?  It was only a few versions ago, so this was not
>>> something lost in prehistory.  What causes the uncertainty?
>>
>> The feature works by searching the etc/NEWS* files, and finding a
>> symbol there doesn't necessarily mean the Emacs release in which it's
>> mentioned is the actual release where the symbol was introduced.  For
>> example, we sometimes forget to announce features and only do that
>> later.  Thus the uncertainty and the cautious language.
>
> And Richard may not know that we've discussed, innumerable times, whether
> we should maintain an actual registry to avoid the guessing, and we've
> concluded that this would be too much work.
>
> Which is still the conclusion.

(With copy to Steve Purcell.)

Steve Purcell has some code to do this, or at least parts of it, here:

    https://github.com/purcell/package-lint/tree/master/tools

It comes out to this:

    https://github.com/purcell/package-lint/blob/master/data/stdlib-changes

Perhaps Steve would be willing to contribute his work, or even help us
integrate his tools into Emacs?

bug#49631: 28.0.50; dired-hide-details-mode Probably introduced at or before Emacs version 24.4

[Steve Purcell]

> On 29 Sep 2021, at 13:48, Stefan Kangas <stefan@marxist.se> wrote:
> 
> (With copy to Steve Purcell.)
> 
> Steve Purcell has some code to do this, or at least parts of it, here:
> 
>    https://github.com/purcell/package-lint/tree/master/tools
> 
> It comes out to this:
> 
>    https://github.com/purcell/package-lint/blob/master/data/stdlib-changes
> 
> Perhaps Steve would be willing to contribute his work, or even help us
> integrate his tools into Emacs?


You’re very willing to integrate that code if it helps. It’s quite rough and ready, so not completely sure how useful it would be to you. You’ll see it relies on loading all features in all emacs versions, and then diffing the various sets of symbols. It works okay for package-lint’s purposes at least.