Re: leim: No such file or directory
On Mon, 03/06/2006 07:58 +, Kenichi Handa wrote:
>> Hi,
>> This might be a bug.
>> During the last step of installation, ``make install prefix=/tmp/E/emacs"
>> gives error:
>> /tmp/E/emacs/share/emacs/23.0.0/leim: No such file or directory
>
>> ``make install" will run without error.
>> --
>> Leon
>> GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
>> 2006-03-06 on morannon
>
> Please show us the full output mesage of "make".
>
> At least, in my case, /tmp/E/emacs/share/emacs/23.0.0/leim
> is created at the toplevel Makfile by the target "mkdir".
>
I'm still seeing this bug in today's emacs-unicode-2 branch.
The procedure I used to compile emacs:
1.
./configure --prefix=/usr/local/packages/emacs --enable-debug
--with-gtk --with-xft --enable-font-backend
--enable-locallisppath=/usr/local/share/emacs/site-lisp:/usr/share/emacs/site-lisp
2.
make bootstrap
3.
make install INSTALL_STRIP="-s"
emacs still complains "leim: No such file or directory"
Then I manually mkdir leim to make emacs happy. But I won't be able to
use any input methods. It appears that leim is not in the load-path.
,[ load-path in "emacs -Q" ]
| load-path is a variable defined in `C source code'.
| Its value is
| ("/usr/local/share/emacs/site-lisp" "/usr/local/share/emacs/site-lisp/auctex"
"/usr/local/share/emacs/site-lisp/bbdb"
"/usr/local/share/emacs/site-lisp/circe"
"/usr/local/share/emacs/site-lisp/color-theme-el"
"/usr/local/share/emacs/site-lisp/emms" "/usr/local/share/emacs/site-lisp/epg"
"/usr/local/share/emacs/site-lisp/ess"
"/usr/local/share/emacs/site-lisp/gnuplot"
"/usr/local/share/emacs/site-lisp/imaxima"
"/usr/local/share/emacs/site-lisp/maxima"
"/usr/local/share/emacs/site-lisp/misc" "/usr/local/share/emacs/site-lisp/muse"
"/usr/local/share/emacs/site-lisp/nxml"
"/usr/local/share/emacs/site-lisp/planner"
"/usr/local/share/emacs/site-lisp/psgml"
"/usr/local/share/emacs/site-lisp/remember"
"/usr/local/share/emacs/site-lisp/vm" "/usr/local/share/emacs/site-lisp/w3m"
"/usr/local/share/emacs/site-lisp/xtla"
"/usr/local/share/emacs/site-lisp/auctex/var"
"/usr/local/share/emacs/site-lisp/color-theme-el/themes"
"/usr/local/share/emacs/site-lisp/muse/contrib"
"/usr/local/share/emacs/site-lisp/muse/experimental"
"/usr/local/share/emacs/site-lisp/nxml/char-name"
"/usr/local/share/emacs/site-lisp/nxml/schema"
"/usr/local/share/emacs/site-lisp/nxml/char-name/unicode"
"/usr/share/emacs/site-lisp"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/url"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/textmodes"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/progmodes"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/play"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/obsolete"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/net"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/mh-e"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/mail"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/language"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/international"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/gnus"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/eshell"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/erc"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/emulation"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/emacs-lisp"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/calendar"
"/usr/local/packages/emacs/share/emacs/23.0.0/lisp/calc")
|
|
| Documentation:
| *List of directories to search for files to load.
| Each element is a string (directory name) or nil (try default directory).
| Initialized based on EMACSLOADPATH environment variable, if any,
| otherwise to default specified by file `epaths.h' when Emacs was built.
`
--
Leon
GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.10.3) of
2006-09-19 on Hawk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs 23 crashes in muse-mode
Hi there,
Here is an example to crash emacs 23 (2006-07-07). I will assume that
muse is installed with:
,
| (load "muse-autoloads.el")
| (add-to-list 'auto-mode-alist '("\\.muse$" . muse-mode))
`
Steps:
1. emacs --enable-font-backend -fn mono-10
2. C-x C-f to open the file as in the attached
3. Move your cursor to a char and press C-u C-x =
4. Emacs exit with: Fatal error (11)Segmentation fault
# -*- coding: utf-8 -*-
θπ
αβγ δε
λ ϕρκψ
≤≥≠≈≔⊂⊃⊆⊇∈
ⅇⅈⅉ∞∆°
ℵℜℂℝℚℙℤ
ℓ∟∠∡
∀∃
∫∑∏
⊕⊗⊙⊚⊛∘∙
±
“”‘’©—
→←↑↓↔↗ ⇐⇑⇒⇓⇔⇗
■□•‣♥★☆
Xah
[EMAIL PROTECTED]
∑ http://xahlee.org/
Thanks,
--
Leon
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Building Emacs overflowed pure space
Hi there, With [ GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.19) of 2006-07-07 ], I get this warning: , | Warning (initialization): Building Emacs overflowed pure space. (See | the node Pure Storage in the Lisp manual for details.) ` Hope to see a fix soon! Thanks, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Simply change (tooltip-mode 1) to (gud-tooltip-mode 1) seems work well. Hope someone can make a proper patch for dictionary-el. It's a nice feature. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund <[EMAIL PROTECTED]> writes: > Leon <[EMAIL PROTECTED]> wrote: >>BTW, it seems you workaround still use the X core font, isn't it? > > Why do you think so? Admittedly, > Emacs.bold.attributeFont: -bitstream-bitstream vera sans > mono-bold-r-*-*-*-100-*-*-*-*-*-* > looks like XLFD, but on my machine I have no X font of this name: > > #xlsfonts -fn "*vera*" > xlsfonts: pattern "*vera*" unmatched > > and this XLFD also does not work with other X applications. > So my (totally uneducated) guess is that emacs23-xft somehow uses XLFD > syntax also for truetype fonts, but in an slightly inconsistent way > (otherwise, bold & italic xft fonts should work automagically). I see. Thanks for explaining this. A question come to my head, that it will not be straightforward to specify a XLFD style font name for a xft font. > > Perhaps someone who really understands this can explain it? > > PS: Sorry for destroying the threading. I'm still not subscribed to > this list and read it through the archive > http://lists.gnu.org/archive/html/emacs-pretest-bug which doesn't show > message-ids. Perhaps it's time to subscribe... Please join the list. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund <[EMAIL PROTECTED]> writes: > Leon wrote: >>Thank you! I'm waiting until it can display properly bold and italic fonts:-) > See my remarks on http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs > for a workaround. > > Meik Thanks, Meik. Actually I have read your comments before the post. I was hoping someone could fix this. BTW, it seems you workaround still use the X core font, isn't it? Regards, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund <[EMAIL PROTECTED]> writes: > The unicode-xft branch is great but it inherited the bugs from > XFT_JHD_BRANCH, > (a) character under cursor is unreadable and (b) scrolling destroys modeline > I tried to accomodate the patches by YAMAMOTO Mitsuharu > http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-04/msg00301.html > and Michael Teske > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00466.html > and the following seems to work for me. > It would be great if someone put them into cvs. > > Meik Thank you! I'm waiting until it can display properly bold and italic fonts:-) -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 fontset bug
Kenichi Handa <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes:
>
>> Maybe something wrong with my Xresources. May I have a look at how you
>> setup fontset for emacs? Thanks.
>
> This is my termius fonts and the setting of X resources.
>
> [dhcp085:~:1003] xlsfonts |grep terminus
> -xos4-terminus-bold-r-normal--0-0-72-72-c-0-iso8859-1
> -xos4-terminus-bold-r-normal--14-140-72-72-c-80-iso8859-1
> -xos4-terminus-bold-r-normal--16-160-72-72-c-80-iso8859-1
> -xos4-terminus-bold-r-normal--20-200-72-72-c-100-iso8859-1
> -xos4-terminus-bold-r-normal--24-240-72-72-c-120-iso8859-1
> -xos4-terminus-bold-r-normal--28-280-72-72-c-140-iso8859-1
> -xos4-terminus-bold-r-normal--32-320-72-72-c-160-iso8859-1
> -xos4-terminus-medium-r-normal--0-0-72-72-c-0-iso8859-1
> -xos4-terminus-medium-r-normal--12-120-72-72-c-60-iso8859-1
> -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso8859-1
> -xos4-terminus-medium-r-normal--16-160-72-72-c-80-iso8859-1
> -xos4-terminus-medium-r-normal--20-200-72-72-c-100-iso8859-1
> -xos4-terminus-medium-r-normal--24-240-72-72-c-120-iso8859-1
> -xos4-terminus-medium-r-normal--28-280-72-72-c-140-iso8859-1
> -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso8859-1
>
> [dhcp085:~:1004] xrdb -query
> Emacs.Fontset-0:
> -*-*-medium-r-*-*-16-*-*-*-*-*-fontset-unicode,ascii:-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1,mule-unicode-2500-33ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,mule-unicode-e000-:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,mule-unicode-0100-24ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1
> Emacs.Font: fontset-unicode
>
> ---
> Kenichi Handa
> [EMAIL PROTECTED]
I think my setting is comparable to yours. I don't know why but this
bug persists in my system:-(
By the way, M-x describe-font RET RET will generate an error in
Emacs-unicode-2:
Emacs 23:
,[ M-x describe-font ]
| Debugger entered--Lisp error: (wrong-type-argument stringp nil)
| font-info(nil)
| describe-font("")
| call-interactively(describe-font)
| execute-extended-command(nil)
| call-interactively(execute-extended-command)
`
Emacs 21.3
,[ M-x describe-font ]
| name (opened by): -xos4-terminus-medium-r-normal--16-160-72-72-c-80-iso8859-1
|full name: -xos4-Terminus-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1
| size: 8
| height: 16
| baseline-offset: 0
| relative-compose: 0
`
--
Leon
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 fontset bug
Kenichi Handa <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes: > >> I'm running Fedora 5. I have checked the emacs-unicode-2 branch to >> make sure I also have the latest version. > > I've just installed the terminus fonts and the latest > emacs-unicode-2 on Fedora 5, but I still can't reproduce the > bug. Very strange. Aren't there anyone else who can > reproduce that bug? > > --- > Kenichi Handa > [EMAIL PROTECTED] Kenichi, Thank you for your effort. Maybe something wrong with my Xresources. May I have a look at how you setup fontset for emacs? Thanks. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 fontset bug
Kenichi Handa <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes: > >> After many trials, I think I found another bug of emacs-unicode-2 >> branch. I have the following settings in ~/.Xresources: > >> ,[ ~/.Xresources ] >> | Emacs.Fontset-0: -*-*-medium-r-*-*-16-*-*-*-*-*-fontset-unicode,\ >> | ascii:-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1,\ >> | mule-unicode-2500-33ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,\ >> | mule-unicode-e000-:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,\ >> | mule-unicode-0100-24ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1 >> | Emacs.Font: fontset-unicode >> ` > >> In emacs-unicode-2, the font for ascii will be a font that matches >> "-*-*-medium-r-*-*-16-*-*-*-*-*" instead of >> "-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1". > >> However, emacs 21.3 will correctly pick up the font matches >> "-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1". > > I can't reproduce that bug here (Debian+XFree86) with the > latest emacs-unicode-2. With the above setting, Emacs > starts up using a terminus font, and C-u C-x = on various > characters tells that terminus fonts are being used. > > Have you tested it by starting Emacs with "-q"? > > What is the output of M-x describe-face RET default RET? > > --- > Kenichi Handa > [EMAIL PROTECTED] I'm running Fedora 5. I have checked the emacs-unicode-2 branch to make sure I also have the latest version. Start emacs with -q option: Emacs 23 ,[ M-x describe-face RET default RET ] | Face: default (customize this face) | Documentation: Basic default face. | Defined in `faces.el'. | | Family: etl-fixed | Width: normal | Height: 121 | Weight: normal | Slant: normal | Foreground: black | Background: white | Underline: nil | Overline: nil | Strike-through: nil |Box: nil |Inverse: nil |Stipple: nil | Font: -ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1 |Fontset: -*-*-medium-r-*-*-16-*-*-*-*-*-fontset-unicode |Inherit: unspecified ` In emacs 21.3: ,[ M-x describe-face RET default RET ] | Family: xos4-terminus | Width: normal | Height: 121 | Weight: normal | Slant: normal | Foreground: black | Background: white | Underline: nil |Overline: nil | Strike-through: nil | Box: nil | Inverse: nil | Stipple: nil | Font or fontset: fontset-unicode | Inherit: unspecified | | Documentation: | | Basic default face. | | You can customize this face. ` -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 fontset bug
Here is extra information. Run `C-u C-x =' on letter `B' in *scratch* buffer: ,[ Emacs 23 ] | character: B (66, #o102, #x42) | preferred charset: ascii (ASCII (ISO646 IRV)) |code point: 0x42 |syntax: w which means: word | category: a:ASCII l:Latin r:Japanese roman | buffer code: #x42 | file code: not encodable by coding system utf-8-emacs | display: by this font (glyph code) | -ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1 (#x42) | | Character code properties are not shown: customize what to show | | There are text properties here: | auto-composedt | fontifiedt | | [back] ` ,[ Emacs 21.3 ] | character: B (0102, 66, 0x42) | charset: ascii (ASCII (ISO646 IRV)) | code point: 66 | syntax: word |category: a:ASCII l:Latin | buffer code: 0x42 | file code: 0x42 (encoded by coding system nil) |font: -xos4-Terminus-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1 ` Regards, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode-2 fontset bug
-*-muleipa-* vietnamese-viscii-lower -*-viscii1.1-* vietnamese-viscii-upper -*-viscii1.1-* arabic-digit-*-*-*-mulearabic-0 arabic-1-column -*-*-*-mulearabic-1 ascii-right-to-left -*-iso8859-1 lao -*-*-*-mulelao-1 arabic-2-column -*-*-*-mulearabic-2 indian-is13194 -*-*-*-is13194-devanagari indian-1-column -*-*-*-muleindian-1 tibetan-1-column-*-*-*-muletibetan-1 mule-unicode-2500-33ff -gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1 mule-unicode-e000- -gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1 mule-unicode-0100-24ff -gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1 ethiopic-*-*-*-ethiopic-unicode chinese-cns11643-3 -*-*-*-cns11643.1992-3 chinese-cns11643-4 -*-*-*-cns11643.1992-4 chinese-cns11643-5 -*-*-*-cns11643.1992-5 chinese-cns11643-6 -*-*-*-cns11643.1992-6 chinese-cns11643-7 -*-*-*-cns11643.1992-7 indian-2-column -*-*-*-muleindian-2 tibetan -*-proportional-*-muletibetan-2 japanese-jisx0213-2 -*-*-*-jisx0213.2000-2 -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.17) of 2006-05-18 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
How to use xft font in unicode-xft branch
Hi there, Just compiled unicode-xft and it works. I don't know how to use xft fonts. And it seems no document at all about the xft branch. For example, emacs -fn "mono" will give ,[ emacs -fn mono ] | Font `mono' is not defined ` Any idea how to test if emacs has xft support?? -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.17) of 2006-05-15 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 23.0.0 does not compile: ‘struct co ding_system’ has no member named ‘eol_type’
Peter Dyballa <[EMAIL PROTECTED]> writes: > Hello! > > Here are details from the *compile* buffer: > > process.c: In function ‘setup_process_coding_systems’: > process.c:699: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:699: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use in > this function) > process.c:699: error: (Each undeclared identifier is reported only once > process.c:699: error: for each function it appears in.) > process.c:700: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > process.c:5078: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:5079: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use > in this function) > process.c:5080: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > process.c:5191: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:5193: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > callproc.c: In function ‘Fcall_process’: > callproc.c:298: error: ‘struct coding_system’ has no member named > ‘eol_type’ > callproc.c:298: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use > in this function) > callproc.c:298: error: (Each undeclared identifier is reported only once > callproc.c:298: error: for each function it appears in.) > callproc.c:299: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > It seems that the struct coding_system in src/coding.h wasn't patched > correctly so it does not include the eol_type component ... > > > > gcc-3.3 -I/sw/include -L/sw/lib -c -I/usr/local/include -I/sw/include/ > libpng12 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/ > lib/freetype219/include -I/sw/include -Demacs -DHAVE_CONFIG_H - > DUSE_LUCID -I. -I/Users/pete/Quellen/Emacs_CVS/ > emacs-23.0.0_NS-9.0pre2a/src -I/usr/X11R6/include -fpascal-strings - > DMAC_OSX -I../mac/src -Dtemacs -ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI process.c > > gcc-3.3 -I/sw/include -L/sw/lib -c -I/usr/local/include -I/sw/include/ > libpng12 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/ > lib/freetype219/include -I/sw/include -Demacs -DHAVE_CONFIG_H - > DUSE_LUCID -I. -I/Users/pete/Quellen/Emacs_CVS/ > emacs-23.0.0_NS-9.0pre2a/src -I/usr/X11R6/include -fpascal-strings - > DMAC_OSX -I../mac/src -Dtemacs -ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI callproc.c > > env CC=gcc-3.3 ./configure --without-sound --without-pop --with-xpm -- > with-jpeg --with-tiff --with-gif --with-png --enable-locallisppath=/ > Library/Application\ Support/Emacs/calendar23:/Library/Application\ > Support/Emacs/preview:/Library/Application\ Support/Emacs/auctex/ > images:/Library/Application\ Support/Emacs/auctex:/Library/Application > \ Support/Emacs CFLAGS="-ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI" CPPFLAGS="-I/usr/local/include -I/sw/include/libpng12 -I/ > sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/lib/ > freetype219/include -I/sw/include" LDFLAGS="-dead_strip -L/usr/X11R6/ > lib -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib/freetype219/lib -L/ > sw/lib/pango-ft219/lib -L/sw/lib" > > checking build system type... powerpc-apple-darwin8.6.0 > checking host system type... powerpc-apple-darwin8.6.0 > checking for gcc... gcc-3.3 > > Mac OS X 10.4.6 PPC Exactly same problem here. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fcitx and Emacs fights over C-Space key compostion.
"Yiyi Hu" <[EMAIL PROTECTED]> writes: > Since I prefer use fcitx to the im built-in within Emacs, > > But the problem now is, if you are in X, you can no longer activate > fcitx within emacs. > > If anyone need more info on this, please tell me. > > yours: xinming I would bet that few people in this list are using fcitx. Does it help if you unset the C-space key binding for emacs? -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fcitx and Emacs fights over C-Space key compostion.
Richard Stallman <[EMAIL PROTECTED]> writes: > What is fcitx? It's an app to input Chinese chars. http://packages.debian.org/unstable/utils/fcitx -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gnus makes emacs lose response
Leon <[EMAIL PROTECTED]> writes: > Dear all, > > If I am using gnus and disconnect the network cable, after a while > emacs will lose response. C-g won't work. I have to `killall emacs'. I > think this is due to demon trying to fetch news/emails. > > My setting of demon in gnus: > --8<---cut here---start->8--- > ;; fetch email while idle > (gnus-demon-add-handler 'gnus-group-get-new-news 3 t) > (gnus-demon-init) > --8<---cut here---end--->8--- > > Regards, I'm not sure if anybody is looking into this issue. Just want to double confirm that this bug exists and causes a lot of trouble when using shaky wireless network. If you need more debug information, please tell me how to get it and I'll post it here. -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of 2006-03-25 on sl392 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
gnus makes emacs lose response
Dear all, If I am using gnus and disconnect the network cable, after a while emacs will lose response. C-g won't work. I have to `killall emacs'. I think this is due to demon trying to fetch news/emails. My setting of demon in gnus: --8<---cut here---start->8--- ;; fetch email while idle (gnus-demon-add-handler 'gnus-group-get-new-news 3 t) (gnus-demon-init) --8<---cut here---end--->8--- Regards, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse cursor bug?
Leon <[EMAIL PROTECTED]> writes: > Hi all, > > I finally figure out how to reproduce this bug though I have known it > for a while. > > 1. Fire up gnus > > 2. middle click a group with a small number of unread articles so that > you won't be interrupted to enter the number of articles. Make sure > you mouse cursor won't be on any clickable text when enter the group. > > *NB*: You may need to hold down the middle button slightly longer than > usual when middle click the group. > > Your mouse cursor will still has a 'hand shape' after entering the > group. I have recorded this process in a gif file located here: > http://people.pwf.cam.ac.uk/sl392/emacs/emacs_cursor.gif > > Hope you can reproduce this and fix it. This bug has *NOT* been fixed in CVS 20060325. The above is just an example to reproduce it. It happens even with Mouse-1 click. I have found it annoying since it gives a wrong visual hint. Could anybody has similar experience confirm? -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of 2006-03-25 on sl392 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse cursor bug?
Leon <[EMAIL PROTECTED]> writes: > Hi all, > > I finally figure out how to reproduce this bug though I have known it > for a while. > > 1. Fire up gnus > > 2. middle click a group with a small number of unread articles so that > you won't be interrupted to enter the number of articles. Make sure > you mouse cursor won't be on any clickable text when enter the group. > > *NB*: You may need to hold down the middle button slightly longer than > usual when middle click the group. > > Your mouse cursor will still has a 'hand shape' after entering the > group. I have recorded this process in a gif file located here: > http://people.pwf.cam.ac.uk/sl392/emacs/emacs_cursor.gif > > Hope you can reproduce this and fix it. It turns out it's dictionary package that is causing the mouse cursor problem. So please ignore this. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse cursor bug?
Hi all, I finally figure out how to reproduce this bug though I have known it for a while. 1. Fire up gnus 2. middle click a group with a small number of unread articles so that you won't be interrupted to enter the number of articles. Make sure you mouse cursor won't be on any clickable text when enter the group. *NB*: You may need to hold down the middle button slightly longer than usual when middle click the group. Your mouse cursor will still has a 'hand shape' after entering the group. I have recorded this process in a gif file located here: http://people.pwf.cam.ac.uk/sl392/emacs/emacs_cursor.gif Hope you can reproduce this and fix it. -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of 2006-03-20 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fontset for mule-unicode-0100-24ff under emacs 23?
Kenichi Handa <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes: > >> It seems fontset defined for emacs 22 doesn't work under emacs 23. > >> My fontset is as follows and it doesn't display unicode-0100-24ff >> though both 'terminus' and 'unifont' are available. >> >> (create-fontset-from-fontset-spec >> (concat >> "-*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode," >> "mule-unicode-0100-24ff:-*-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1")) >> (set-default-font "fontset-unicode") >> > > Thank you for the report. I've just committed a fix. > Could you please try the latest version? > > --- > Kenichi Handa > [EMAIL PROTECTED] This might be a bug too! The following font setting in ~/.emacs can display all characters in: http://www.xahlee.org/Periodic_dosage_dir/text_editor_unicode/unicode.txt (create-fontset-from-fontset-spec (concat "-*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode," "mule-unicode-0100-24ff:-misc-fixed-medium-r-*-*-15-*-*-*-*-*-iso10646-1"));; (when window-system (set-default-font "fontset-unicode")) However, the following font setting in ~/.Xdefault can *not* display all characters in the above unicode.txt: Emacs*Fontset-0: -*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode, \ mule-unicode-0100-24ff: -misc-fixed-medium-r-*-*-15-*-*-*-*-*-iso10646-1 Emacs.Font: fontset-unicode Strangely, the two setting have the same output from M-x describe-fontset: Fontset: -*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode CHAR RANGE (CODE RANGE) FONT NAME (REQUESTED and [OPENED]) Ā .. ⓿ (#x100 .. #x24FF) -misc-fixed-medium-r-*-*-15-*-*-*-*-*-iso10646-1 -- C-@ .. DEL ... Cheers, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
leim: No such file or directory
Hi, This might be a bug. During the last step of installation, ``make install prefix=/tmp/E/emacs" gives error: /tmp/E/emacs/share/emacs/23.0.0/leim: No such file or directory ``make install" will run without error. -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of 2006-03-06 on morannon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fontset for mule-unicode-0100-24ff under emacs 23?
Great!Now it works properly. M-x describe-fontset has:--Fontset: -*-terminal-medium-r-*-*-16-*-*-*-*-*-fontset-unicode CHAR RANGE (CODE RANGE) FONT NAME (REQUESTED and [OPENED])Ā .. ⓿ (#x100 .. #x24FF) -*-fixed-medium-r-*-*-*-*-*-*-*-*-iso10646-1 [-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO10646-1] --C-@ .. DEL..--On 03/03/06, Kenichi Handa <[EMAIL PROTECTED]> wrote: In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes:> It seems fontset defined for emacs 22 doesn't work under emacs 23. > My fontset is as follows and it doesn't display unicode-0100-24ff> though both 'terminus' and 'unifont' are available.> > (create-fontset-from-fontset-spec> (concat> "-*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode,"> "mule-unicode-0100-24ff:-*-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1")) > (set-default-font "fontset-unicode")> Thank you for the report. I've just committed a fix.Could you please try the latest version? ---Kenichi Handa[EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Fontset for mule-unicode-0100-24ff under emacs 23?
Hi all, It seems fontset defined for emacs 22 doesn't work under emacs 23. My fontset is as follows and it doesn't display unicode-0100-24ff though both 'terminus' and 'unifont' are available. (create-fontset-from-fontset-spec (concat "-*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode," "mule-unicode-0100-24ff:-*-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1")) (set-default-font "fontset-unicode") I suspect there might be some changes between 22 and 23. Could you kindly help me configure a suitable fontset for emacs 23? Regards, -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of 2006-02-25 on morannon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fringe arrow conflict between compile and gud?
>>>>> "Nick" == Nick Roberts writes: > > I don't use more than one arrow per buffer. However, I do think compile > should use overlay-arrow-variable-list instead of making > overlay-arrow-position a local variable. I now can reproduce the conflict > that > Juan-Leon reports. GUD and Compile are operating on the same source buffer > and > the local variable masks the global one when set in gud-display-line. The > global value is used to set window-point and this remains unchanged (from > nil): > I can trigger the error with following sequence: emacs -Q (setq next-error-highlight 'fringe-arrow) C-x C-e C-x C-f foo.c create a foo.c with errors M-x compile gcc -g foo.c Jump to errors pressing RET on compilation buffer and fix it without deleting line where fringe arrow is, so it remains after doing: M-x compile gcc -g foo.c M-x gdb (line is gdb --fullname a.out) b main run now I get an error: error in process filter: Wrong type argument: integer-or-marker-p, nil error in process filter: gud-display-line: Wrong type argument: integer-or-marker-p, nil The overlay arrow is updated fine, but buffer is not scrolled to new position (if you make foo.c 100 lines long, the compilation error were in line 2 and main is in line 90 you'll see better this). Maybe this info regarding what I have may help with this: /compile.el/1.346/Wed Feb 9 15:50:36 2005// /gud.el/1.29/Wed Feb 2 05:52:51 2005// gdb --version = GNU gdb 5.1 Regards -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ibuffer-toggle-sorting-mode problem
In ibuffer, I can use the (default) key "," to call function `ibuffer-toggle-sorting-mode', that rotates between modes "sorting by size", "sorting by alphabetic", "sorting by major-mode", "sorting by mode-name" and "sorting by recency". Problem is that when toggling to "sorting by recency" ibuffer does not update the order (but it updates OK if right after this I press the "g" key, bound to `ibuffer-update') This is the revisions of ibuffer related files I have: /ibuf-ext.el/1.41/Wed Mar 2 21:27:05 2005// /ibuf-macs.el/1.16/Mon May 10 18:13:07 2004// /ibuffer.el/1.66/Wed Feb 9 15:50:42 2005// Regards -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fringe arrow conflict between compile and gud?
On Thu, 24 Mar 2005 23:27:27 +0200, Juri Linkov <[EMAIL PROTECTED]> wrote: > > If I find error while compiling, next-error put a fringe arrow in the > > error line. If I fix the error and compile again, the fringe arrow > > does not dissapear (I do not if this is intended to be this way). > > What is the most suitable time for the fringe arrow to disappear? > After recompile? After a delay for specified time? After the user > clicks on the fringe arrow? Maybe this should be configurable. IMHO, most suitable time would be when recompiling again. But despite of this, there is no guarantee that some other "package" (like gud) will not try to use the fringe arrow before recompiling, so making arrow to disapear based on user actions may be not the right solution. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: next-error-follow-minor-mode selects location window until next keystroke
On Wed, 23 Mar 2005 21:43:12 +0200, Juri Linkov <[EMAIL PROTECTED]> wrote: > JUAN-LEON Lahoz Garcia <[EMAIL PROTECTED]> writes: > > (setq next-error-highlight-no-select 2.0) > > > > In the following please suppose that I have activated > > `next-error-follow-minor-mode'. > > > > If in a grep or compilation buffer I move the cursor, the hit location > > buffer is shown in another window. Problem, IMHO, it that this window > > seems to be the selected one (cursor is not hollow and modeline shows > > it as selected window) until next keystroke (that is sent to grep or > > compilation buffer). This is quite confusing for me (specially now > > that great `mode-line-inactive' feature allows a faster visual > > recognition of witch is the selected window). > > > > OTHO, while `next-error-highlight-no-select' works great on > > compilation and grep buffers (and I really like it), occur buffers > > seems to ignore this variable (and also `next-error-highlight'). > > Does the following patch produce good results for you? If yes, > it could be also implemented for occur buffers too. > Yes, it works great. Thanks for looking into this. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fringe arrow conflict between compile and gud?
On Thu, 24 Mar 2005 11:33:45 +1200, Nick Roberts <[EMAIL PROTECTED]> wrote: > FWIW I could not reproduce Juan-Leon's error. In fact if I set > next-error-highlight to 'fringe-arrow I could only get one arrow to display > (in the compilation buffer). The source buffer showed nothing. This is what > I would expect, however, because the same thing happened in gdb-ui when > both the source buffer and assembler buffer until you made the changes which > allowed multiple overlay arrows. With Gnus and GUD, don't they constantly > steal the arrow from each other? > > Juan-Leon can you see an arrow in the compilation buffer and source buffer > at the same time? Yes, I can. If I hit RET on an error, both arrow are present. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
next-error-follow-minor-mode selects location window until next keystroke
Hi, I have set (setq next-error-highlight-no-select 2.0) In the following please suppose that I have activated `next-error-follow-minor-mode'. If in a grep or compilation buffer I move the cursor, the hit location buffer is shown in another window. Problem, IMHO, it that this window seems to be the selected one (cursor is not hollow and modeline shows it as selected window) until next keystroke (that is sent to grep or compilation buffer). This is quite confusing for me (specially now that great `mode-line-inactive' feature allows a faster visual recognition of witch is the selected window). OTHO, while `next-error-highlight-no-select' works great on compilation and grep buffers (and I really like it), occur buffers seems to ignore this variable (and also `next-error-highlight'). -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
fringe arrow conflict between compile and gud?
Hi,
I have:
(setq next-error-highlight 'fringe-arrow)
If I find error while compiling, next-error put a fringe arrow in the
error line. If I fix the error and compile again, the fringe arrow
does not dissapear (I do not if this is intended to be this way).
If the I open a gud session, I cannot track execution on file where
compilation fringe arrow is (I suppose some sort of conflict occurs).
Sometimes an error occurs:
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
set-window-point(# nil)
gud-display-line("/home/leon/Testing/C/foo.c" 2182)
gud-display-frame()
gud-filter(#
"/home/leon/Testing/C/foo.c:2182:59257:beg:0x805663b\n")
And sometimes no error, but "next" and "step" gud commands do not
scroll to line where program execution is.
Of course these problems dissapear as soon I reload source file where
fringe arrow was.
--
juanleon
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Problem at backup-buffer for writable files in not writable dirs
Hi, When you edit and save a writable file in a non writable dir, and you have `backup-by-copying' to nil (the default), backup-buffer fails to make a backup in the place user has defined with variable `backup-directory-alist' (because you cannot move files that are in a not writable dir, despite of file ownership), so it copies it to file "~/%backup%~". [ I know having writable files in non writable files is not very usual, but I have to edit some conf files in such directories and I got this ~/%backup%~ file around all the time ] IMHO this one-liner patch solves the problem, by detecting this situation as one of the cases where a copy should be used to backup the file instead of moving. You may want to review and/or apply it. Regards juanleon --- files.el.oriThu Mar 10 09:29:31 2005 +++ files.elThu Mar 10 10:02:00 2005 @@ -2686,6 +2686,7 @@ backup-by-copying ;; Don't rename a suid or sgid file. (and modes (< 0 (logand modes #o6000))) + (not (file-writable-p (file-name-directory real-file-name))) (and backup-by-copying-when-linked (> (file-nlinks real-file-name) 1)) (and (or backup-by-copying-when-mismatch ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
