bug#6069: 23.1.96; sxhash, big uints and overflow-error in custom-file

Not sure if this is an error of Emacs, or if the fault is mine:

- `sxhash' of some object produced a 32-bit unsigned integer, which was represented just fine in Lisp.

- I stored it in a customization variable, which was subsequently saved to my custom-file.

- When reading back the file, I got an overflow error, as in

(read-from-string "2475893479")
--> overflow error

Due to the nature of hashes, it appears unreasonable hard for me to make a test case.  But looking at the code, 
sxhash is designed to produce an unsigned int and make a (signed?) Lisp integer from it.

 INTMASK is 0xffffffff at least on my system.

Artihmetic operations, OTOH convert big ints to floats in arith_driver():

(let ((bigint (+ 1475893479 1000000000)))
  (floatp bigint))

(Would sxhash in that case produce a negative value if its result is printed? I don't know.
Somewhere along the way to `custom-save-variables', some info about the meaning of bit #31 gets lost, and
Emacs produces string representation that can't be read.)

In GNU Emacs 23.1.96.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
of 2010-04-30 on braeburn.aquamacs.org - Aquamacs Distribution 2.0preview6
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-x' 'CFLAGS=-arch i386 -arch ppc' 'LDFLAGS=-arch
i386 -arch ppc''

bug#6065: Emacs Trunk Build Failure on Mac OS X 10.6

Please update from Bazaar and try again.

bug#6070: 23.1.96; delete-by-moving-to-trash

While experimenting some of the new features, I quite like to use
delete-by-moving-to-trash to double protect deleting files by accident.

However, with (setq delete-by-moving-to-trash t), a lot of (internal)
temporary files are also moved to the trash bin. See the attached file
for an output of `ls' in the .Trash directory after roughly two hours of
emacs.

To reproduce, just (setq delete-by-moving-to-trash t) and carry on with
normal Emacs editing. After a while you should notice the trash bin
heavily populated.

The trash bin is a buffer area to rescue a lost file. Flood it with many
internal temp files makes it very difficult to do so. Before emptying
the trash bin (or remove files permanently) I (I guess many will do the
same) often have a quick look at the files. This is now almost
impossible if delete-by-moving-to-trash has been used.

Could someone take a look at this issue? Thank you.

Leo

leo <at> Victoria ~/.Trash$ ls
!Users!leo!GNUS!.newsrc.eld.~106~ diff16258KRU                      diff26258KKg                      emacsca2LL8                       jka-com6258xvm
#%2Ascratch%2A#88815TN#           diff16258LEz                      diff26258WaT                      emacsgM68Dw                       jka-com8881_hQ
#%2Ascratch%2A#8969WYO#           diff16258XUm                      diff26258WhH                      emacsmgCrUd                       jka-com8881yXK
#*message*-20100308-115723#       diff16258jrN                      diff26258XNy                      emacsqCMK1i                       jka-com89692BS
#.newsrc-dribble#                 diff16258v7A                      diff26258Xba                      emacsvlXg3W                       jka-com8969ctF

bug#6070: 23.1.96; delete-by-moving-to-trash

Leo <sdl.web <at> gmail.com> writes:

> While experimenting some of the new features, I quite like to use
> delete-by-moving-to-trash to double protect deleting files by accident.
>
> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
> temporary files are also moved to the trash bin. See the attached file
> for an output of `ls' in the .Trash directory after roughly two hours of
> emacs.

Good point.  I have commited a change that inhibits trashing for
jka-compr, server, diff, and epg.  Probably more such changes are
required.

bug#6069: INTMASK on 32/64 bit machines

I have one post-scriptum.

I just noticed that the large `sxhash' integer was produced on a 64-bit machine with INTMASK 0xffffffff,
but that the read failure occurred with a binary compiled for 32-bit architectures.  In that Emacs, INTMASK
is 0x3fffffff.

I think that explains what I'm seeing.

Would it be sensible to make `sxhash' use a lower common denominator for modern machines, such as 0x3fffffff?

Or, should the lower INTMASK be used on 64-bit architectures as well?

It's less than ideal that printed Lisp expressions, especially those in customization files, are not
interchangeable between different builds of the same version of Emacs.

bug#6071: cc-(basic-)common-init not called in js-mode

I have a bug report that I believe is due to that cc-basic-common-init
is not called in js-mode. Due to this jus-mode modifies default values
instead of buffer local values:

  https://bugs.launchpad.net/nxhtml/+bug/572664

Could this please be fixed in js.el before the release?

bug#6070: 23.1.96; delete-by-moving-to-trash

On 2010-05-01 03:19 +0100, Chong Yidong wrote:
>> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
>> temporary files are also moved to the trash bin. See the attached file
>> for an output of `ls' in the .Trash directory after roughly two hours of
>> emacs.
>
> Good point.  I have commited a change that inhibits trashing for
> jka-compr, server, diff, and epg.  Probably more such changes are
> required.

Thank you for the quick fix. I will be using it and let you if there are
other cases need fixing.

Leo

bug#6070: 23.1.96; delete-by-moving-to-trash

On 2010-05-01 05:00 +0100, Leo wrote:
>> Good point.  I have commited a change that inhibits trashing for
>> jka-compr, server, diff, and epg.  Probably more such changes are
>> required.
>
> Thank you for the quick fix. I will be using it and let you if there are
> other cases need fixing.

delete-auto-save-file-if-necessary still creates a lot temp files in the
trash bin. Any idea where names like emacs6ljgy9 or emacsXWkc8c come
from? They look like temp file. Is it from with-temp-file?

Cheers,

Leo

bug#6065: Emacs Trunk Build Failure on Mac OS X 10.6

I built it successfully from the latest trunk.

I should mention that I did 'make' and not 'make bootstrap'. I don't
imagine that would make a difference for this particular error, but if
you'd like to know what 'make bootstrap' does, I'll test that too.

On Fri, Apr 30, 2010 at 7:51 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>
> Please update from Bazaar and try again.
>

bug#5984: Crash displaying composed characters

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
> Date: Fri, 30 Apr 2010 16:47:43 -0400
> 
> >   . Emacs then enters redisplay to display the echo area.  As part of
> [...]
> >   . Further down, autocmp_chars calls the value of
> >     auto-composition-function:
> [...]
> >   . Now the " *Echo Area0*" buffer holds a totally different text,
> >     unbeknownst to autocmp_chars, which still passes the old values 32
> >     and 33 to TEMP_SET_PT_BOTH:
> 
> More generally, this Lisp code could modify any buffer, so preventing
> the load-messages is not a sufficiently reliable solution (tho it might
> be desirable in any case).

I think the patch suggested by Andreas (now installed on the release
branch) does what's necessary.  It's unfortunate minor side-effect is
that the original message from Edebug gets lost; it would be good to
fix that on the trunk.