viewmail-info
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecode_{a


From: Stephen J. Turnbull
Subject: [VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecode_{arithcompare, arithop}().
Date: Mon, 16 Dec 2013 02:04:34 +0900

Aidan Kehoe writes:

 > I would like to move to returning markers in #'max, #'min when all
 > arguments are markers that point to the same buffer,

Are there efficiency implications to this?

What is the logic for returning markers (other than efficiency)?
Specifically, I would expect that most usages would be of the form

    (goto-char (max m1 m2 m3))

or other inline calls, and I would consider

    (setq last-marker (max m1 m2 m3))

to be a code smell whether you have an integer or marker result, and
would be rather suspicious of

    (let ((last-marker (max m1 m2 m3))) ...)

 > Note that a with number types build, before 3bfcdeb65578 , interpreted #'max
 > and #'min already returned markers, and we haven’t had any problems with
 > that.

I wouldn't expect to have a problem because I'd expect that any code
that actually behaves differently with markers and integers is buggy
anyway. ;-)

 > See also the comments in the tests. It surprised me strongly that the
 > markers weren’t preserved with changes that should have kept the same
 > relative character count, but it’s a separate issue that needs separate
 > investigation.

Yeah, that sucks.  I would go farther than "surprising" and just say
that's a bug.  But fixing that efficiently is probably not easy.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]