* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars [not found] ` <20190522202920.3CA7920498@vcs0.savannah.gnu.org> @ 2019-05-22 21:06 ` Stefan Monnier 2019-05-23 19:57 ` Paul Eggert 2019-05-23 13:47 ` Andy Moreton 1 sibling, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2019-05-22 21:06 UTC (permalink / raw) To: emacs-devel; +Cc: Paul Eggert > * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-22 21:06 ` [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars Stefan Monnier @ 2019-05-23 19:57 ` Paul Eggert 2019-05-24 14:32 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Paul Eggert @ 2019-05-23 19:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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.... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-23 19:57 ` Paul Eggert @ 2019-05-24 14:32 ` Stefan Monnier 2019-05-24 20:13 ` Paul Eggert 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2019-05-24 14:32 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-24 14:32 ` Stefan Monnier @ 2019-05-24 20:13 ` Paul Eggert 2019-05-24 20:30 ` Eli Zaretskii 2019-05-25 12:08 ` Stefan Monnier 0 siblings, 2 replies; 9+ messages in thread From: Paul Eggert @ 2019-05-24 20:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-24 20:13 ` Paul Eggert @ 2019-05-24 20:30 ` Eli Zaretskii 2019-05-24 21:31 ` Paul Eggert 2019-05-25 12:08 ` Stefan Monnier 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2019-05-24 20:30 UTC (permalink / raw) To: Paul Eggert; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-24 20:30 ` Eli Zaretskii @ 2019-05-24 21:31 ` Paul Eggert 0 siblings, 0 replies; 9+ messages in thread From: Paul Eggert @ 2019-05-24 21:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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". ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars 2019-05-24 20:13 ` Paul Eggert 2019-05-24 20:30 ` Eli Zaretskii @ 2019-05-25 12:08 ` Stefan Monnier 1 sibling, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2019-05-25 12:08 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: master dfed333: Remove fixnum restriction on some display vars [not found] ` <20190522202920.3CA7920498@vcs0.savannah.gnu.org> 2019-05-22 21:06 ` [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars Stefan Monnier @ 2019-05-23 13:47 ` Andy Moreton 2019-05-23 20:02 ` Paul Eggert 1 sibling, 1 reply; 9+ messages in thread From: Andy Moreton @ 2019-05-23 13:47 UTC (permalink / raw) To: emacs-devel 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; ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: master dfed333: Remove fixnum restriction on some display vars 2019-05-23 13:47 ` Andy Moreton @ 2019-05-23 20:02 ` Paul Eggert 0 siblings, 0 replies; 9+ messages in thread From: Paul Eggert @ 2019-05-23 20:02 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel 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%). ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-05-25 12:08 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20190522202917.27067.49863@vcs0.savannah.gnu.org> [not found] ` <20190522202920.3CA7920498@vcs0.savannah.gnu.org> 2019-05-22 21:06 ` [Emacs-diffs] master dfed333: Remove fixnum restriction on some display vars Stefan Monnier 2019-05-23 19:57 ` Paul Eggert 2019-05-24 14:32 ` Stefan Monnier 2019-05-24 20:13 ` Paul Eggert 2019-05-24 20:30 ` Eli Zaretskii 2019-05-24 21:31 ` Paul Eggert 2019-05-25 12:08 ` Stefan Monnier 2019-05-23 13:47 ` Andy Moreton 2019-05-23 20:02 ` Paul Eggert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.