Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Stefan Monnier]

>     * src/window.c (set_window_buffer): When buffer-display-count
>     is too large for a fixnum, make it a bignum.

Rather than convert to bignum, we should either crash or signal
a `hallelujah` error, depending on whether you think this is due to
a bug or too a supranatural power.


        Stefan

Re: master dfed333: Remove fixnum restriction on some display vars

[Andy Moreton]

On Wed 22 May 2019, Paul Eggert wrote:

> diff --git a/src/lisp.h b/src/lisp.h
> index 876b757..6db9059 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -2679,7 +2679,7 @@ struct Lisp_Buffer_Objfwd
>    {
>      enum Lisp_Fwd_Type type;	/* = Lisp_Fwd_Buffer_Obj */
>      int offset;
> -    /* One of Qnil, Qfixnump, Qsymbolp, Qstringp, Qfloatp or Qnumberp.  */
> +    /* One of Qnil, Qintegerp, Qsymbolp, Qstringp, Qfloatp or Qnumberp.  */
>      Lisp_Object predicate;
>    };

This fails to build if configured with "--enable-checking=structs" as
the hash has changed. This fixes it:

diff --git a/src/pdumper.c b/src/pdumper.c
index 28045d1959..5c14e950a0 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2305,7 +2305,7 @@ static dump_off
 dump_fwd_buffer_obj (struct dump_context *ctx,
                      const struct Lisp_Buffer_Objfwd *buffer_objfwd)
 {
-#if CHECK_STRUCTS && !defined (HASH_Lisp_Buffer_Objfwd_13CA6B04FC)
+#if CHECK_STRUCTS && !defined (HASH_Lisp_Buffer_Objfwd_611EBD13FF)
 # error "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
 #endif
   struct Lisp_Buffer_Objfwd out;

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Paul Eggert]

On 5/22/19 2:06 PM, Stefan Monnier wrote:
> Rather than convert to bignum, we should either crash or signal
> a `hallelujah` error, depending on whether you think this is due to
> a bug or too a supranatural power.

Crashing would be too strong, as one could then crash Emacs simply via 
(setq tab-width (1+ most-positive-fixnum)). For the variables involved 
with this patch, there should be no need to crash as it should be OK to 
treat bignums as out-of-range fixnums - e.g., a bignum tab-width is 
treated as if it were 8, which is how an out-of-range fixnum tab-width 
is treated.

I'm not a fan of invoking supernatural powers either....

Re: master dfed333: Remove fixnum restriction on some display vars

[Paul Eggert]

On 5/23/19 6:47 AM, Andy Moreton wrote:
> This fails to build if configured with "--enable-checking=structs" as
> the hash has changed. This fixes it:

Thanks, please install that patch at your convenience, and similarly in 
the future if this crops up later. I don't recommend or use 
--enable-checking=structs due to its too-high false-alarm rate (for me, 
it's been 100%).

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Stefan Monnier]

>> Rather than convert to bignum, we should either crash or signal
>> a `hallelujah` error, depending on whether you think this is due to
>> a bug or too a supranatural power.
> Crashing would be too strong, as one could then crash Emacs simply via (setq
> tab-width (1+ most-positive-fixnum)).

My comment was specifically about buffer-display-count (which counts
a number of distinct heap objects).  I haven't looked closely at the
other cases, but this one jumped at me as a prime example where a fixnum
is safe.


        Stefan

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Paul Eggert]

On 5/24/19 7:32 AM, Stefan Monnier wrote:
> My comment was specifically about buffer-display-count (which counts
> a number of distinct heap objects).

Actually it counts the number of times a buffer has been displayed in 
the past.

Plus, if I execute (setq buffer-display-count most-positive-fixnum) and 
then display the buffer in a new window, I wouldn't want Emacs to crash 
(or to convey the existence of a supernatural power :-) simply because 
the counter was incremented.

While we're on the topic, how about if we deprecate/obsolete 
buffer-display-count? As far as I can tell it's never been used in 
Emacs, and is not used elsewhere. It was introduced in 1997 and was 
superseded in 1998 by buffer-display-time, and the rare code that 
worries about whether a buffer has been displayed 
(ibuffer-mark-old-buffers, clean-buffer-list) uses the newer variable.

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 24 May 2019 13:13:14 -0700
> Cc: emacs-devel@gnu.org
> 
> While we're on the topic, how about if we deprecate/obsolete 
> buffer-display-count?

For what reason?  Not being used by applications we know of is not
enough, IMO.

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Paul Eggert]

On 5/24/19 1:30 PM, Eli Zaretskii wrote:
>> While we're on the topic, how about if we deprecate/obsolete
>> buffer-display-count?
> For what reason?  Not being used by applications we know of is not
> enough, IMO.

It's not worth arguing about, so I'll take that as a "no".

Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars

[Stefan Monnier]

>> My comment was specifically about buffer-display-count (which counts
>> a number of distinct heap objects).
> Actually it counts the number of times a buffer has been displayed in
> the past.

Oh, I confused it with the other counter we use for redisplay which
counts the number of windows that display this buffer.
Thanks for setting me straight.


        Stefan