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
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
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
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: 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: 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: 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.
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: 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: 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 ---fallback to the default fontset--- 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] ---fallback to the default fontset---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: 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
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
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(#window 382 on *Backtrace* nil) gud-display-line(/home/leon/Testing/C/foo.c 2182) gud-display-frame() gud-filter(#process gud-a.out /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
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
