* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded [not found] ` <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> @ 2020-01-06 17:13 ` Pip Cet 2020-01-07 2:38 ` Paul Eggert 0 siblings, 1 reply; 14+ messages in thread From: Pip Cet @ 2020-01-06 17:13 UTC (permalink / raw) To: Daniel Colascione, emacs-devel; +Cc: niwtrx, 38912, Eli Zaretskii Summary, since I'm CCing emacs-devel: For bytecode objects, equal-equality does not imply sxhash-equality. That led to an assertion failure in the pdumper code, even though the pdumper code itself is apparently correct; it simply does not allow for paradoxical behavior of hash tables with bytecode keys. (The muffled sound you hear in the background is my trying not to point out that eq-vs-eql leads to similar paradoxes). On Mon, Jan 6, 2020 at 5:01 PM Daniel Colascione <dancol@dancol.org> wrote: > >> Again, I doubt this is related to the original bug. That `equal' > >> behaves weirdly like this is a problem I've mentioned before (when > >> (equal a b) signals but (equal b a) succeeds), but the consensus then > >> was not to change it, so it's possible this is only the rehashing > >> check needing to be more careful. > This consensus is wrong. We need to make equality imply sxhash equality or > very odd things (like this) will happen. I agree absolutely, of course, and maybe there's a consensus for fixing equal for bytecodes but leaving it unfixed for cases in which (equal a b) signals but (equal b a) does not. > C++ and Java both require this > relationship between hash code equality and object equality, and we should > too. We do document it, we just don't obey our documented API. > Can we just fix the bytecode sxhash bug? Is it too late to fix this for Emacs 27? If the answer is no, would a good fix be to make equal=eq for bytecode objects? That should come close to the old behavior, and we can fix things properly (by fixing sxhash to hash byte code objects) on master. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-06 17:13 ` bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Pip Cet @ 2020-01-07 2:38 ` Paul Eggert 2020-01-07 3:34 ` dancol 2020-01-07 15:47 ` Eli Zaretskii 0 siblings, 2 replies; 14+ messages in thread From: Paul Eggert @ 2020-01-07 2:38 UTC (permalink / raw) To: Pip Cet; +Cc: niwtrx, 38912, emacs-devel On 1/6/20 9:13 AM, Pip Cet wrote: > we can fix things properly (by fixing > sxhash to hash byte code objects) on master. It's not just bytecode objects; it's also markers and some other stuff. The worst case is window configurations, where there's a nontrivial function compare_window_configurations that Fequal delegates to. Does anyone know offhand why we don't simply use eq to compare window configurations? Might save me some work in patching this in master. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 2:38 ` Paul Eggert @ 2020-01-07 3:34 ` dancol 2020-01-07 14:16 ` Stefan Monnier 2020-01-07 15:47 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: dancol @ 2020-01-07 3:34 UTC (permalink / raw) To: Paul Eggert; +Cc: niwtrx, 38912, Pip Cet, emacs-devel [-- Attachment #1: Type: text/html, Size: 1040 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 3:34 ` dancol @ 2020-01-07 14:16 ` Stefan Monnier 2020-01-07 19:32 ` Paul Eggert 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2020-01-07 14:16 UTC (permalink / raw) To: dancol; +Cc: niwtrx, Paul Eggert, emacs-devel, 38912, Pip Cet, Eli Zaretskii > The worst case is window configurations, where there's a nontrivial > function compare_window_configurations that Fequal delegates to. Indeed, this is very strange. > Does anyone know offhand why we don't simply use eq to compare window > configurations? I'm curious about it too. As a long-time Elisp coder, I find this behavior very odd (I just discovered it while looking at the code) and I think having them compared by identity would make a lot more sense. > I think changing the equal behavior of these objects would be > a compatibility change. Indeed. It's clearly out of the question for Emacs-27. But I'd be in favor of introducing this backward incompatibility in Emacs-28, unless we can find a good use case where the structural-equality is needed for them. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 14:16 ` Stefan Monnier @ 2020-01-07 19:32 ` Paul Eggert 0 siblings, 0 replies; 14+ messages in thread From: Paul Eggert @ 2020-01-07 19:32 UTC (permalink / raw) To: Stefan Monnier, dancol; +Cc: niwtrx, 38912, Eli Zaretskii, Pip Cet, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1302 bytes --] On 1/7/20 6:16 AM, Stefan Monnier wrote: > I'd be in > favor of introducing this backward incompatibility in Emacs-28, unless > we can find a good use case where the structural-equality is needed > for them. I looked for use cases within Emacs, and found only one: a test case that I changed to use compare-window-configurations instead. I don't think this was a good use case; it's just a hack in a test. I agree with Martin that comparing window configurations is something of a botch. Despite some documentation to the contrary, neither 'equal' nor compare-window-configurations compares all components of window configurations (though the two functions do compare different sets of components). If there's a solid need for comparing different sets of components of window configurations (and I doubt whether the test case establishes a need), it could be implemented by adding an argument to compare-window-configurations to say how to do the comparison. However, there doesn't seem to be a significant need to make all this part of 'equal'. So, after writing some sxhash-equal test cases and then fixing Emacs to handle these test cases properly, I boldly installed the attached patch into master. This should make sxhash-equal compatible with 'equal'. Comments welcome as usual. [-- Attachment #2: 0001-Fix-sxhash-equal-on-bytecodes-markers-etc.patch --] [-- Type: text/x-patch, Size: 12564 bytes --] From 724af7671590cd91df37f64df6be73f6dca0144d Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Tue, 7 Jan 2020 11:23:11 -0800 Subject: [PATCH] Fix sxhash-equal on bytecodes, markers, etc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Pip Cet (Bug#38912#14). * doc/lispref/objects.texi (Equality Predicates): Document better when ‘equal’ looks inside objects. * doc/lispref/windows.texi (Window Configurations): Don’t say that ‘equal’ looks inside window configurations. * etc/NEWS: Mention the change. * src/fns.c (internal_equal): Do not look inside window configurations. (sxhash_obj): Hash markers, byte-code function objects, char-tables, and font objects consistently with Fequal. * src/window.c (compare_window_configurations): Now static. Remove last argument. Caller changed. * test/lisp/ffap-tests.el (ffap-other-window--bug-25352): Use compare-window-configurations, not ‘equal’. * test/src/fns-tests.el (test-sxhash-equal): New test. --- doc/lispref/objects.texi | 8 +++++-- doc/lispref/windows.texi | 4 ---- etc/NEWS | 6 +++++ src/fns.c | 52 ++++++++++++++++++++++++---------------- src/lisp.h | 4 ++-- src/window.c | 21 ++++------------ src/window.h | 1 - test/lisp/ffap-tests.el | 2 +- test/src/fns-tests.el | 16 +++++++++++++ 9 files changed, 67 insertions(+), 47 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 4be2eb6918..4242223a48 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2336,8 +2336,12 @@ Equality Predicates @end group @end example -However, two distinct buffers are never considered @code{equal}, even if -their textual contents are the same. +The @code{equal} function recursively compares the contents of objects +if they are integers, strings, markers, vectors, bool-vectors, +byte-code function objects, char-tables, records, or font objects. +Other objects are considered @code{equal} only if they are @code{eq}. +For example, two distinct buffers are never considered @code{equal}, +even if their textual contents are the same. @end defun For @code{equal}, equality is defined recursively; for example, given diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi index c9301c9d18..d0791d4019 100644 --- a/doc/lispref/windows.texi +++ b/doc/lispref/windows.texi @@ -5915,10 +5915,6 @@ Window Configurations structure of windows, but ignores the values of point and the saved scrolling positions---it can return @code{t} even if those aspects differ. - -The function @code{equal} can also compare two window configurations; it -regards configurations as unequal if they differ in any respect, even a -saved point. @end defun @defun window-configuration-frame config diff --git a/etc/NEWS b/etc/NEWS index d6cabf8e9e..0784160ce2 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -42,6 +42,12 @@ applies, and please also update docstrings as needed. \f * Incompatible Lisp Changes in Emacs 28.1 +** 'equal' no longer examines some contents of window configurations. +Instead, it considers window configurations to be equal only if they +are eq. To compare contents, use compare-window-configurations +instead. This change helps fix a bug in sxhash-equal, which returned +incorrect hashes for window configurations and some other objects. + \f * Lisp Changes in Emacs 28.1 diff --git a/src/fns.c b/src/fns.c index 4a0a8fd96d..4a463a8feb 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2434,6 +2434,9 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, same size. */ if (ASIZE (o2) != size) return false; + + /* Compare bignums, overlays, markers, and boolvectors + specially, by comparing their values. */ if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; if (OVERLAYP (o1)) @@ -2454,7 +2457,6 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, && (XMARKER (o1)->buffer == 0 || XMARKER (o1)->bytepos == XMARKER (o2)->bytepos)); } - /* Boolvectors are compared much like strings. */ if (BOOL_VECTOR_P (o1)) { EMACS_INT size = bool_vector_size (o1); @@ -2465,11 +2467,6 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, return false; return true; } - if (WINDOW_CONFIGURATIONP (o1)) - { - eassert (equal_kind != EQUAL_NO_QUIT); - return compare_window_configurations (o1, o2, false); - } /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) @@ -4703,22 +4700,35 @@ sxhash_obj (Lisp_Object obj, int depth) hash = sxhash_string (SSDATA (obj), SBYTES (obj)); break; - /* This can be everything from a vector to an overlay. */ case Lisp_Vectorlike: - if (BIGNUMP (obj)) - hash = sxhash_bignum (obj); - else if (VECTORP (obj) || RECORDP (obj)) - /* According to the CL HyperSpec, two arrays are equal only if - they are `eq', except for strings and bit-vectors. In - Emacs, this works differently. We have to compare element - by element. Same for records. */ - hash = sxhash_vector (obj, depth); - else if (BOOL_VECTOR_P (obj)) - hash = sxhash_bool_vector (obj); - else - /* Others are `equal' if they are `eq', so let's take their - address as hash. */ - hash = XHASH (obj); + { + enum pvec_type pvec_type = PSEUDOVECTOR_TYPE (XVECTOR (obj)); + if (! (PVEC_NORMAL_VECTOR < pvec_type && pvec_type < PVEC_COMPILED)) + { + /* According to the CL HyperSpec, two arrays are equal only if + they are 'eq', except for strings and bit-vectors. In + Emacs, this works differently. We have to compare element + by element. Same for pseudovectors that internal_equal + examines the Lisp contents of. */ + hash = sxhash_vector (obj, depth); + break; + } + else if (pvec_type == PVEC_BIGNUM) + hash = sxhash_bignum (obj); + else if (pvec_type == PVEC_MARKER) + { + ptrdiff_t bytepos + = XMARKER (obj)->buffer ? XMARKER (obj)->bytepos : 0; + hash = sxhash_combine ((intptr_t) XMARKER (obj)->buffer, bytepos); + hash = SXHASH_REDUCE (hash); + } + else if (pvec_type == PVEC_BOOL_VECTOR) + hash = sxhash_bool_vector (obj); + else + /* Others are 'equal' if they are 'eq', so take their + address as hash. */ + hash = XHASH (obj); + } break; case Lisp_Cons: diff --git a/src/lisp.h b/src/lisp.h index 1a1ae0399b..3681b7b2a7 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1069,7 +1069,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) with PVEC_TYPE_MASK to indicate the actual type. */ enum pvec_type { - PVEC_NORMAL_VECTOR, + PVEC_NORMAL_VECTOR, /* Should be first, for sxhash_obj. */ PVEC_FREE, PVEC_BIGNUM, PVEC_MARKER, @@ -1094,7 +1094,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) PVEC_CONDVAR, PVEC_MODULE_FUNCTION, - /* These should be last, check internal_equal to see why. */ + /* These should be last, for internal_equal and sxhash_obj. */ PVEC_COMPILED, PVEC_CHAR_TABLE, PVEC_SUB_CHAR_TABLE, diff --git a/src/window.c b/src/window.c index ff17cd88f3..8cdad27b66 100644 --- a/src/window.c +++ b/src/window.c @@ -7976,19 +7976,17 @@ foreach_window_1 (struct window *w, bool (*fn) (struct window *, void *), /* Return true if window configurations CONFIGURATION1 and CONFIGURATION2 describe the same state of affairs. This is used by Fequal. - IGNORE_POSITIONS means ignore non-matching scroll positions - and the like. + Ignore non-matching scroll positions and the like. This ignores a couple of things like the dedication status of window, combination_limit and the like. This might have to be fixed. */ -bool +static bool compare_window_configurations (Lisp_Object configuration1, - Lisp_Object configuration2, - bool ignore_positions) + Lisp_Object configuration2) { - register struct save_window_data *d1, *d2; + struct save_window_data *d1, *d2; struct Lisp_Vector *sws1, *sws2; ptrdiff_t i; @@ -8006,9 +8004,6 @@ compare_window_configurations (Lisp_Object configuration1, || d1->frame_menu_bar_lines != d2->frame_menu_bar_lines || !EQ (d1->selected_frame, d2->selected_frame) || !EQ (d1->f_current_buffer, d2->f_current_buffer) - || (!ignore_positions - && (!EQ (d1->minibuf_scroll_window, d2->minibuf_scroll_window) - || !EQ (d1->minibuf_selected_window, d2->minibuf_selected_window))) || !EQ (d1->focus_frame, d2->focus_frame) /* Verify that the two configurations have the same number of windows. */ || sws1->header.size != sws2->header.size) @@ -8041,12 +8036,6 @@ compare_window_configurations (Lisp_Object configuration1, equality. */ || !EQ (sw1->parent, sw2->parent) || !EQ (sw1->prev, sw2->prev) - || (!ignore_positions - && (!EQ (sw1->hscroll, sw2->hscroll) - || !EQ (sw1->min_hscroll, sw2->min_hscroll) - || !EQ (sw1->start_at_line_beg, sw2->start_at_line_beg) - || NILP (Fequal (sw1->start, sw2->start)) - || NILP (Fequal (sw1->pointm, sw2->pointm)))) || !EQ (sw1->left_margin_cols, sw2->left_margin_cols) || !EQ (sw1->right_margin_cols, sw2->right_margin_cols) || !EQ (sw1->left_fringe_width, sw2->left_fringe_width) @@ -8071,7 +8060,7 @@ DEFUN ("compare-window-configurations", Fcompare_window_configurations, and scrolling positions. */) (Lisp_Object x, Lisp_Object y) { - if (compare_window_configurations (x, y, true)) + if (compare_window_configurations (x, y)) return Qt; return Qnil; } diff --git a/src/window.h b/src/window.h index aa8d2c8d1d..167d1be7ab 100644 --- a/src/window.h +++ b/src/window.h @@ -1184,7 +1184,6 @@ #define CHECK_LIVE_WINDOW(WINDOW) \ extern Lisp_Object window_parameter (struct window *, Lisp_Object parameter); extern struct window *decode_live_window (Lisp_Object); extern struct window *decode_any_window (Lisp_Object); -extern bool compare_window_configurations (Lisp_Object, Lisp_Object, bool); extern void mark_window_cursors_off (struct window *); extern bool window_wants_mode_line (struct window *); extern bool window_wants_header_line (struct window *); diff --git a/test/lisp/ffap-tests.el b/test/lisp/ffap-tests.el index eaf39680e4..30c8f79457 100644 --- a/test/lisp/ffap-tests.el +++ b/test/lisp/ffap-tests.el @@ -74,7 +74,7 @@ ffap-other-window--bug-25352 (urls nil) (ffap-url-fetcher (lambda (url) (push url urls) nil))) (should-not (ffap-other-window "https://www.gnu.org")) - (should (equal (current-window-configuration) old)) + (should (compare-window-configurations (current-window-configuration) old)) (should (equal urls '("https://www.gnu.org"))))) (provide 'ffap-tests) diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el index 60be2c6c2d..c6ceae4a00 100644 --- a/test/src/fns-tests.el +++ b/test/src/fns-tests.el @@ -858,6 +858,22 @@ test-hash-function-that-mutates-hash-table (puthash k k h))) (should (= 100 (hash-table-count h))))) +(ert-deftest test-sxhash-equal () + (should (= (sxhash-equal (* most-positive-fixnum most-negative-fixnum)) + (sxhash-equal (* most-positive-fixnum most-negative-fixnum)))) + (should (= (sxhash-equal (make-string 1000 ?a)) + (sxhash-equal (make-string 1000 ?a)))) + (should (= (sxhash-equal (point-marker)) + (sxhash-equal (point-marker)))) + (should (= (sxhash-equal (make-vector 1000 (make-string 10 ?a))) + (sxhash-equal (make-vector 1000 (make-string 10 ?a))))) + (should (= (sxhash-equal (make-bool-vector 1000 t)) + (sxhash-equal (make-bool-vector 1000 t)))) + (should (= (sxhash-equal (make-char-table nil (make-string 10 ?a))) + (sxhash-equal (make-char-table nil (make-string 10 ?a))))) + (should (= (sxhash-equal (record 'a (make-string 10 ?a))) + (sxhash-equal (record 'a (make-string 10 ?a)))))) + (ert-deftest test-secure-hash () (should (equal (secure-hash 'md5 "foobar") "3858f62230ac3c915f300c664312c63f")) -- 2.24.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 2:38 ` Paul Eggert 2020-01-07 3:34 ` dancol @ 2020-01-07 15:47 ` Eli Zaretskii 2020-01-07 17:37 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2020-01-07 15:47 UTC (permalink / raw) To: Paul Eggert; +Cc: niwtrx, 38912, pipcet, emacs-devel > Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org, > niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org> > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Mon, 6 Jan 2020 18:38:17 -0800 > > Does anyone know offhand why we don't simply use eq to compare window > configurations? I guess because not all of that is Lisp data. struct save_window_data isn't. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 15:47 ` Eli Zaretskii @ 2020-01-07 17:37 ` Stefan Monnier 2020-01-07 17:43 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2020-01-07 17:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: niwtrx, Paul Eggert, emacs-devel, 38912, pipcet, dancol >> Does anyone know offhand why we don't simply use eq to compare window >> configurations? > I guess because not all of that is Lisp data. struct save_window_data > isn't. I think he meant: why doesn't `equal` applied on window configs behave like `eq`? Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 17:37 ` Stefan Monnier @ 2020-01-07 17:43 ` Eli Zaretskii 2020-01-07 18:01 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2020-01-07 17:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet, dancol > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Paul Eggert <eggert@cs.ucla.edu>, niwtrx@icloud.com, > 38912@debbugs.gnu.org, dancol@dancol.org, pipcet@gmail.com, > emacs-devel@gnu.org > Date: Tue, 07 Jan 2020 12:37:00 -0500 > > I think he meant: why doesn't `equal` applied on window configs behave > like `eq`? That's an entirely different question. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 17:43 ` Eli Zaretskii @ 2020-01-07 18:01 ` Stefan Monnier 2020-01-07 18:11 ` Eli Zaretskii 2020-01-07 18:29 ` martin rudalics 0 siblings, 2 replies; 14+ messages in thread From: Stefan Monnier @ 2020-01-07 18:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet, dancol >> I think he meant: why doesn't `equal` applied on window configs behave >> like `eq`? > That's an entirely different question. Indeed, but I think that's the only question that's actually been asked (Dan will hopefully correct me if I'm wrong). I actually *expected* that `equal` on window configs would behave like `eq`. It would have never occurred to me (before I looked at the code) that it could be different (although in retrospect, I can see reasons why it could make sense). Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 18:01 ` Stefan Monnier @ 2020-01-07 18:11 ` Eli Zaretskii 2020-01-07 18:47 ` Stefan Monnier 2020-01-07 18:29 ` martin rudalics 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2020-01-07 18:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 07 Jan 2020 13:01:17 -0500 > Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, > 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org > > I actually *expected* that `equal` on window configs would behave like > `eq`. It would have never occurred to me (before I looked at the code) > that it could be different (although in retrospect, I can see reasons > why it could make sense). Since we have a dedicated comparison function there, why is it important what eq and equal do with these objects? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 18:11 ` Eli Zaretskii @ 2020-01-07 18:47 ` Stefan Monnier 0 siblings, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2020-01-07 18:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet, dancol >> I actually *expected* that `equal` on window configs would behave like >> `eq`. It would have never occurred to me (before I looked at the code) >> that it could be different (although in retrospect, I can see reasons >> why it could make sense). > Since we have a dedicated comparison function there, why is it > important what eq and equal do with these objects? The immediate reason why it's relevant is that it affects what `sxhash` needs to do. The existence of `compare-window-configurations` is not directly relevant to the question (tho it arguably makes it less important for `equal` to behave structurally since it provides an alternative for those callers who would need it). Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 18:01 ` Stefan Monnier 2020-01-07 18:11 ` Eli Zaretskii @ 2020-01-07 18:29 ` martin rudalics 2020-01-07 18:43 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: martin rudalics @ 2020-01-07 18:29 UTC (permalink / raw) To: Stefan Monnier, Eli Zaretskii; +Cc: niwtrx, 38912, eggert, pipcet, emacs-devel > I actually *expected* that `equal` on window configs would behave like > `eq`. It would have never occurred to me (before I looked at the code) > that it could be different (although in retrospect, I can see reasons > why it could make sense). `eq' wouldn't make any sense at all. 'compare-window-configurations' per se is a misconception. But I have no intention to dig into strokes.el to find out why on earth it would need such a thing and how to remove it. martin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 18:29 ` martin rudalics @ 2020-01-07 18:43 ` Stefan Monnier 2020-01-07 18:58 ` martin rudalics 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2020-01-07 18:43 UTC (permalink / raw) To: martin rudalics; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet, Eli Zaretskii >> I actually *expected* that `equal` on window configs would behave like >> `eq`. It would have never occurred to me (before I looked at the code) >> that it could be different (although in retrospect, I can see reasons >> why it could make sense). > `eq' wouldn't make any sense at all. Why not? > 'compare-window-configurations' per se is a misconception. We're talking about the behavior of `equal`, not that of `compare-window-configurations`. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-07 18:43 ` Stefan Monnier @ 2020-01-07 18:58 ` martin rudalics 0 siblings, 0 replies; 14+ messages in thread From: martin rudalics @ 2020-01-07 18:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: niwtrx, eggert, emacs-devel, 38912, pipcet >> `eq' wouldn't make any sense at all. > > Why not? Where and how would you use it? >> 'compare-window-configurations' per se is a misconception. > > We're talking about the behavior of `equal`, not that of > `compare-window-configurations`. 'equal' is specified via compare_window_configurations which is a misconception just a 'compare-window-configurations' is. martin ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-01-07 19:32 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> [not found] ` <83ftgvh96l.fsf@gnu.org> [not found] ` <D1473DD8-48F8-4204-80B5-BE6396B8B668@icloud.com> [not found] ` <83a771g2tc.fsf@gnu.org> [not found] ` <CAOqdjBfjpSqhDcMiHGQfaOGZEodmjmvhQionRPO1OQ0sVsLDPg@mail.gmail.com> [not found] ` <83o8vgee85.fsf@gnu.org> [not found] ` <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> 2020-01-06 17:13 ` bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Pip Cet 2020-01-07 2:38 ` Paul Eggert 2020-01-07 3:34 ` dancol 2020-01-07 14:16 ` Stefan Monnier 2020-01-07 19:32 ` Paul Eggert 2020-01-07 15:47 ` Eli Zaretskii 2020-01-07 17:37 ` Stefan Monnier 2020-01-07 17:43 ` Eli Zaretskii 2020-01-07 18:01 ` Stefan Monnier 2020-01-07 18:11 ` Eli Zaretskii 2020-01-07 18:47 ` Stefan Monnier 2020-01-07 18:29 ` martin rudalics 2020-01-07 18:43 ` Stefan Monnier 2020-01-07 18:58 ` martin rudalics
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).