Re: `.newsrc.eld' saves chinese group name in wrong coding
> From: Richard Stallman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Date: Thu, 26 Oct 2006 04:52:56 -0400 > > There is a big difference between unibyte strings and encoded unibyte > strings. What is that difference? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Python mode and eldoc "freeze"
On Mon, 23 Oct 2006 02:46:43 -0400
John Sullivan <[EMAIL PROTECTED]> wrote:
#> Chong Yidong <[EMAIL PROTECTED]> writes:
#>
#> > After some trial and error, I propose the following patch. I have
#> > verified that it makes the reported bug go away. Does anyone disagree
#> > with it?
#>
#> Thanks, I tested this patch, and it solved the "freeze". But I
#> noticed that when point was over any of the builtins, the only thing
#> echoed was "()".
Current code works fine for me with __builtins__... or did you mean
"keywords"?
#> I don't have time to check at the moment whether this is a regression
#> -- ISTR that docs for things like "import" and "except" were echoed,
#> but maybe I'm misremembering.
On my machine, nothing is echoed for keywords. I don't use eldoc
normally, though, so I do not know if it always used to work like this.
What would you like to see displayed for things like import or except?
The output of "help('import')" is pretty long... First sentence might
make some sense, but I am not sure if it would be useful?
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
Take my advice, I don't use it anyway.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Python mode and eldoc "freeze"
> After some trial and error, I propose the following patch. I have > verified that it makes the reported bug go away. Does anyone disagree > with it? Yes, though I'm not interested in that fork. We cannot switch to a different version now, before the release. We need to fix the current code in local, safe ways. Would you please help? After the release, we could switch to your version if you help us do that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 32bit system on 64bit kernel
> So I wonder what is going on with the amdx86-64 configuration: > why someone else expected it to have 64-bit longs, while Stefan's > machine uses 32-bit longs. I think because he's using a 64-bit kernel, but 32-bit libraries etc (so programs like Emacs use a 32-bit ABI) -- and "uname" reports information from the kernel. There are two possible ways to fix for now: 1. Make a different configuration, perhaps amdx86-32. configure would have to tell which to use. 2. Make that particular configuration conditionally define BITS_PER_LONG, based perhaps on info that configure would have to collect. After the release we could perhaps move to having configure always determine BITS_PER_LONG. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
> There is a big difference between unibyte strings and encoded unibyte > strings. What is that difference? You can represent one of Emacs' supported Latin alphabets in (unencoded) unibyte strings, and Emacs will automatically convert to and from multibyte. However, if you store encoded text in unibyte strings, you are responsible for decoding and encoding when necessary. You have to keep track, everywhere, of whether the data is encoded or not. We implemented the ability to do encoding manually because sometimes it is necessary to decode parts of a file in different ways (e.g., mailboxes). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
> You can represent one of Emacs' supported Latin alphabets in > (unencoded) unibyte strings, and Emacs will automatically convert to > and from multibyte. And this use was very convenient for Emacs-20 where we wanted to keep some backward compatibility with code that was not MULE-aware. But nowadays any code which relies on this is simply broken, AFAIC, because it'll only work in environments using a iso-8859 encoding (more or less) and will thus be unusable with in asian environments or in utf-8 (which is very quickly taking over the iso-8859 world). > However, if you store encoded text in unibyte strings, you are > responsible for decoding and encoding when necessary. You have to > keep track, everywhere, of whether the data is encoded or not. It's pretty easy to keep track of it: unibyte == encoded, multibyte == decoded. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
For compare-windows ö is not ö (or ß is n ot ß, or ü is not ü, ...)
Hello! I have two files, saved *Messages* buffer. When I open them each mode- line starts with ``-u:´´. When I compare them, compare-windows reports ö in buffer a is not ö in buffer b, ß in buffer a is not ß in buffer, ü in buffer a is not ü in buffer b. Because "live" *Messages* do not contain these characters when I launch GNU Emacs with -Q, I copy part of *Messages* from another running GNU Emacs into *scratch* buffer, which also has a mode-line starting with ``-u:´´. Again ö, ß, and ü are not found to be equal. C- u C-x = on the ö characters reveals for *scratch* buffer: character: ö (3958, #o7566, #xf76, U+00F6) charset: latin-iso8859-15 (Right-Hand Part of Latin Alphabet 9 (ISO/IEC 8859-15): ISO- IR-203.) code point: #x76 syntax: w which means: word category: l:Latin buffer code: #x8E #xF6 file code: #xC3 #xB6 (encoded by coding system mule-utf-8) display: by this font (glyph code) -B&H-LucidaTypewriter-Medium-R-Normal-Sans-10-100-75-75-M-60- ISO8859-15 (#xF6) and for the opened file, i.e. the saved *Messages*: character: ö (2294, #o4366, #x8f6, U+00F6) charset: latin-iso8859-1 (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) code point: #x76 syntax: w which means: word category: l:Latin buffer code: #x81 #xF6 file code: #xC3 #xB6 (encoded by coding system mule-utf-8-unix) display: by this font (glyph code) -B&H-LucidaTypewriter-Medium-R-Normal-Sans-10-100-75-75-M-60- ISO10646-1 (#xF6) I cannot see any sense in treating UTF-8 characters so differently in an UTF-8 based environment. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.8.0, X toolkit, Xaw3d scroll bars) of 2006-10-27 on Latsche X server distributor `The XFree86 Project, Inc', version 11.0.4040 configured using `configure '--without-sound' '--without-pop' '--with- xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--enable- locallisppath=/Library/Application Support/Emacs/calendar22:/Library/ Application Support/Emacs/preview:/Library/Application Support/Emacs/ auctex/images:/Library/Application Support/Emacs/auctex:/Library/ Application Support/Emacs' 'CFLAGS=-pipe -fPIC -fast -mcpu=7450 - mtune=7450 -mpim-altivec -ftree-vectorize -foptimize-register-move - freorder-blocks -freorder-blocks-and-partition -fthread-jumps - fpeephole -fno-crossjumping' 'CPPFLAGS=-I/usr/local/include -I/sw/ include/libpng12 -I/sw/include' 'LDFLAGS=-dead_strip -L/usr/X11R6/lib -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib' 'CC=gcc' 'CPP=gcc -E - no-cpp-precomp -I/usr/local/include -I/sw/include/libpng12 -I/sw/ include -L/usr/X11R6/lib -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: shell-dirtrack-mode: t show-paren-mode: t display-time-mode: t desktop-save-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t view-mode: t -- Mit friedvollen Grüßen Pete "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs/pretest/emacs-22.0.90.tar.gz on intel Mac running OS 10.4.8
> With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Using Mac (intel) running OS 10.4.8. This version of emacs does not contain mac/make-package, to make a self-contained emacs for a mac. In the main directory: configure --without-x --enable-carbon-app finishes without error, but make bootstrap does not complete: . Writing LC_UNIXTHREAD command 1400 unused bytes follow Mach-O header 1099603 pure bytes used ./emacs -q -batch -f list-load-path-shadows make[3]: *** No rule to make target `/Users/gilberth/emacs-22.0.90/src/../mac/Emacs.app/Contents/Resources/Emacs .icns', needed by `macosx-bundle'. Stop. make[2]: *** [src] Error 2 make[1]: *** [bootstrap-build] Error 2 make: *** [bootstrap] Error 2 Gil ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs/pretest/emacs-22.0.90.tar.gz on intel Mac running OS 10.4.8
Gilbert Harman <[EMAIL PROTECTED]> writes:
>> With Richard's agreement, I've bumped the version number to 22.0.90
>> and rolled a pretest tarball. The tarball can be found at
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Using Mac (intel) running OS 10.4.8.
>
> This version of emacs does not contain mac/make-package, to make a
> self-contained emacs for a mac.
>
> In the main directory:
>
> configure --without-x --enable-carbon-app
>
> finishes without error, but
>
> make bootstrap does not complete:
It looks as though the file `make-dist' in the CVS emacs source
directory does not package mac/make-package. I believe this is just a
matter of changing line 525 of make-dist from
echo "Making links to \`mac'"
(cd mac
ln ChangeLog INSTALL README *.xml *.MPW ../${tempdir}/mac)
to
echo "Making links to \`mac'"
(cd mac
ln ChangeLog INSTALL README make-package *.xml *.MPW ../${tempdir}/mac)
Could someone verify that including make-package in the tarball fixes
this problem?
If so, I'll correct this in the next tarball.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs/pretest/emacs-22.0.90.tar.gz on intel Mac running OS 10.4.8
> On Fri, 27 Oct 2006 21:51:40 -0400, Chong Yidong <[EMAIL PROTECTED]> said: > Could someone verify that including make-package in the tarball > fixes this problem? mac/Emacs.app/Contents/Resources/Emacs.icns was also missing. I updated make-dist in CVS. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
