bug#19502: 24.4; Emacs 24.4 on windows: the contents of the system-configuration variable has changed, but its docstring has not. I prefer the behaviour described in the docstring.

bug#19502: 24.4; Emacs 24.4 on windows: the contents of the system-configuration variable has changed, but its docstring has not. I prefer the behaviour described in the docstring.

[Albert]

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]

Evaluating (insert system-configuration) gives
in emacs 24.3: i386-mingw-nt6.2.9200
in emacs 24.4: i686-pc-mingw32

The important difference here is the absence of the "nt6.2.9200" part in
emacs 24.4. I have use cases that need to know the version of the
windows emacs is currently running on. I would therefore prefer
something like "i686-pc-mingw32-nt6.2.9200" if that is somehow better or
more accurate than the original string from 24.3. Perhaps the "pc" part
is not needed?

In emacs 24.4, the docstring for the variable system-configuration is:
"system-configuration is a variable defined in `C source code'.
Its value is "i686-pc-mingw32"

Documentation:
Value is string indicating configuration Emacs was built for.
On MS-Windows, the value reflects the OS flavor and version on which
Emacs is running."

I would prefer if this docstring would remain correct.

But, while checking the contents of this entire mail, I see a version
number of 6.3.9600 reported just a few lines below. I am running
windows 8.1 nowadays so that one is more accurate. Could it be that
the windows version reported in the system-configuration variable of
emacs 24.3 is the version under which that emacs was build? In that
case, the version wouldn't be useful and even confusing.

So it seems the old emacs 24.3 behaviour is not following the
docstring either. Still, I would prefer it if the variable could live
up to its current docstring, if possible. If that is not possible, is
there another way of asking emacs on which windows version it is
running? Is it documented somewhere where I could find it?
The bug-reporting code obviously manages to do it, but when I searched
for alternatives yesterday I couldn't find any.

Thank "you" for the new version,

Albert.


In GNU Emacs 24.4.1 (i686-pc-mingw32)
 of 2014-10-24 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix=/c/usr'

Important settings:
  value of $LANG: NLD
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<menu-bar> <buffer> C-a ( i n s e r t SPC s y s t e
m - c o n f i g u r a t i o n ) C-x C-e <left> <left>
<left> <left> <left> <left> <left> <left> <left> <left>
<left> <left> <left> <left> <left> <return> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
nil

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils dired time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

Memory information:
((conses 8 81100 7139)
 (symbols 32 17758 0)
 (miscs 32 38 158)
 (strings 16 11946 4623)
 (string-bytes 1 305328)
 (vectors 8 9285)
 (vector-slots 4 385622 6114)
 (floats 8 56 301)
 (intervals 28 423 131)
 (buffers 508 13))

[-- Attachment #2: Type: text/html, Size: 5849 bytes --]

bug#19502: 24.4; Emacs 24.4 on windows: the contents of the system-configuration variable has changed, but its docstring has not. I prefer the behaviour described in the docstring.

[Eli Zaretskii]

> Date: Sun, 4 Jan 2015 10:55:14 +0100
> From: Albert <ab.for.lists@gmail.com>
> 
> Evaluating (insert system-configuration) gives
> in emacs 24.3: i386-mingw-nt6.2.9200
> in emacs 24.4: i686-pc-mingw32
> 
> The important difference here is the absence of the "nt6.2.9200" part in
> emacs 24.4. I have use cases that need to know the version of the
> windows emacs is currently running on. I would therefore prefer
> something like "i686-pc-mingw32-nt6.2.9200" if that is somehow better or
> more accurate than the original string from 24.3. Perhaps the "pc" part
> is not needed?

The native MS-Windows build of Emacs now uses the same code as on
other platforms to compute this string, so the OS version is not
included.

I fixed the doc string, thanks for pointing out the discrepancy.

> In emacs 24.4, the docstring for the variable system-configuration is:
> "system-configuration is a variable defined in `C source code'.
> Its value is "i686-pc-mingw32"
> 
> Documentation:
> Value is string indicating configuration Emacs was built for.
> On MS-Windows, the value reflects the OS flavor and version on which
> Emacs is running."
> 
> I would prefer if this docstring would remain correct.
> 
> But, while checking the contents of this entire mail, I see a version
> number of 6.3.9600 reported just a few lines below.

Exactly.  So in fact the OS version in old value was redundant, and no
information is lost with this change.

> Could it be that the windows version reported in the
> system-configuration variable of emacs 24.3 is the version under
> which that emacs was build?

No, it reported the version of the OS where Emacs was running.

> So it seems the old emacs 24.3 behaviour is not following the
> docstring either.

It will in the next release.

> Still, I would prefer it if the variable could live up to its
> current docstring, if possible.

Given that the information you want is still available, both in the
bug report and independently (see below), why would you need that
information in system-configuration as well?

> If that is not possible, is there another way of asking emacs on
> which windows version it is running?  Is it documented somewhere
> where I could find it?  The bug-reporting code obviously manages to
> do it, but when I searched for alternatives yesterday I couldn't
> find any.

You want x-server-version (a function), it is what report-emacs-bug
calls to get that info.

bug#19502: 24.4; Emacs 24.4 on windows: the contents of the system-configuration variable has changed, but its docstring has not. I prefer the behaviour described in the docstring.

[Albert]

[-- Attachment #1: Type: text/plain, Size: 5323 bytes --]

Thank you!

The function x-server-version indeed serves my needs. You are right,
no need to have non-standard behaviour for the system-configuration
variable. In hindsight it is even documented in an obvious
place. However, the wording in the documentation of x-server-version
and x-server-vendor is a little confusing (the relevant snippets are
included at the end of this mail):

- The elisp manual says "specifically about X displays". I would
expect a word about mswindows here.

- The docstring of x-server-version is compatible with that, but I
would again expect a word about mswindows.

- The docstring of x-server-vendor seems to ONLY mention W32 and
Microsoft. I would expect more or less the same text as in the elisp
manual with an extra remark about W32.

Best regards,

Albert.

From elisp manual: "Display Feature Testing":
--8><---------------
These functions obtain additional information specifically about X
displays.

 -- Function: x-server-version &optional display
     This function returns the list of version numbers of the X server
     running the display.  The value is a list of three integers: the
     major and minor version numbers of the X protocol, and the
     distributor-specific release number of the X server software
     itself.

 -- Function: x-server-vendor &optional display
     This function returns the "vendor" that provided the X server
     software (as a string).  Really this means whoever distributes the
     X server.

     When the developers of X labeled software distributors as
     "vendors", they showed their false assumption that no system could
     ever be developed and distributed noncommercially.
--8><---------------

And in the docstring of both of them it says:

--8><---------------
x-server-version is a built-in function in `w32fns.c'.

(x-server-version &optional DISPLAY)

Return the version numbers of the server of DISPLAY.
The value is a list of three integers: the major and minor
version numbers of the X Protocol in use, and the distributor-specific
release number.  See also the function `x-server-vendor'.

The optional argument DISPLAY specifies which display to ask about.
DISPLAY should be either a frame or a display name (a string).
If omitted or nil, that stands for the selected frame's display.

[forward]
--8><---------------

--8><---------------
x-server-vendor is a built-in function in `w32fns.c'.

(x-server-vendor &optional DISPLAY)

Return the "vendor ID" string of the W32 system (Microsoft).
The optional argument DISPLAY specifies which display to ask about.
DISPLAY should be either a frame or a display name (a string).
If omitted or nil, that stands for the selected frame's display.

[back]
--8><---------------


On 4 January 2015 at 16:57, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 4 Jan 2015 10:55:14 +0100
> > From: Albert <ab.for.lists@gmail.com>
> >
> > Evaluating (insert system-configuration) gives
> > in emacs 24.3: i386-mingw-nt6.2.9200
> > in emacs 24.4: i686-pc-mingw32
> >
> > The important difference here is the absence of the "nt6.2.9200" part in
> > emacs 24.4. I have use cases that need to know the version of the
> > windows emacs is currently running on. I would therefore prefer
> > something like "i686-pc-mingw32-nt6.2.9200" if that is somehow better or
> > more accurate than the original string from 24.3. Perhaps the "pc" part
> > is not needed?
>
> The native MS-Windows build of Emacs now uses the same code as on
> other platforms to compute this string, so the OS version is not
> included.
>
> I fixed the doc string, thanks for pointing out the discrepancy.
>
> > In emacs 24.4, the docstring for the variable system-configuration is:
> > "system-configuration is a variable defined in `C source code'.
> > Its value is "i686-pc-mingw32"
> >
> > Documentation:
> > Value is string indicating configuration Emacs was built for.
> > On MS-Windows, the value reflects the OS flavor and version on which
> > Emacs is running."
> >
> > I would prefer if this docstring would remain correct.
> >
> > But, while checking the contents of this entire mail, I see a version
> > number of 6.3.9600 reported just a few lines below.
>
> Exactly.  So in fact the OS version in old value was redundant, and no
> information is lost with this change.
>
> > Could it be that the windows version reported in the
> > system-configuration variable of emacs 24.3 is the version under
> > which that emacs was build?
>
> No, it reported the version of the OS where Emacs was running.
>
> > So it seems the old emacs 24.3 behaviour is not following the
> > docstring either.
>
> It will in the next release.
>
> > Still, I would prefer it if the variable could live up to its
> > current docstring, if possible.
>
> Given that the information you want is still available, both in the
> bug report and independently (see below), why would you need that
> information in system-configuration as well?
>
> > If that is not possible, is there another way of asking emacs on
> > which windows version it is running?  Is it documented somewhere
> > where I could find it?  The bug-reporting code obviously manages to
> > do it, but when I searched for alternatives yesterday I couldn't
> > find any.
>
> You want x-server-version (a function), it is what report-emacs-bug
> calls to get that info.
>

[-- Attachment #2: Type: text/html, Size: 7053 bytes --]

bug#19502: 24.4; Emacs 24.4 on windows: the contents of the system-configuration variable has changed, but its docstring has not. I prefer the behaviour described in the docstring.

[Eli Zaretskii]

> Date: Sun, 4 Jan 2015 18:17:14 +0100
> From: Albert <ab.for.lists@gmail.com>
> Cc: 19502@debbugs.gnu.org
> 
> The function x-server-version indeed serves my needs. You are right,
> no need to have non-standard behaviour for the system-configuration
> variable. In hindsight it is even documented in an obvious
> place. However, the wording in the documentation of x-server-version
> and x-server-vendor is a little confusing (the relevant snippets are
> included at the end of this mail):
> 
> - The elisp manual says "specifically about X displays". I would
> expect a word about mswindows here.
> 
> - The docstring of x-server-version is compatible with that, but I
> would again expect a word about mswindows.
> 
> - The docstring of x-server-vendor seems to ONLY mention W32 and 
> Microsoft. I would expect more or less the same text as in the elisp 
> manual with an extra remark about W32.

Thanks, I fixed all these discrepancies, and I'm therefore closing the
bug report.