$BBp5^JX!JBh0l9f!K(B
$BEv%5%$%H$N$4MxMQ$OA4$FL5NA!JCK=w6&!o(B0$B1_!K(B
$B$d$C$Q$j=P0)$&$J$i$46a=j$G5$7Z$KOC$79g$($k%a!<%k!&%(!{%A%U%l%s%I$,$G$9$h(B
$B$M!#Ev%5%$%H$OA49qCO0hJL$N;TD.Bhttp://loves.qsv20.com/
[EMAIL PROTECTED]"[EMAIL
PROTECTED]&$K%W%i%$%P%7!pJs$rBgNL8x3+$7$F$*$j$^$9!#(B
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes: > Kenichi Handa <[EMAIL PROTECTED]> writes: >> How about enabling quail-completion on using "TeX" input >> method as below? I think it's rare to use TAB while editing >> a TeX/LaTeX file, thus using it for quail-completion is ok >> while typing some letter. > I didn't realize that was implemented. It looks helpful, but it > doesn't do what I'd expect. For instance, if I type `\righta TAB', > I'd like it to complete to `\rightarrow', like normal completion. Ah, yes, that is better. But, it requires a non-trivial change to the current code which should be avoided for the moment. So, I've just enabled the current way of completion for "TeX" input method. > That's a separate issue from being able to complete on Unicode names, > of course. Yes. I agree that such an input method is useful. Do you want to implement it? Otherwise, I'll put that in my todo list. --- Ken'ichi HANDA [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: extra locale entries
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes: > Kenichi Handa <[EMAIL PROTECTED]> writes: >>> Doesn't this cause incompatible changes for some environments (like >>> Vietnamese changing from viscii)? >> >> Yes. > Shouldn't that be noted in NEWS anyway? I agree. I've just add this paragraph in NEWS. ** Languange environment and various default coding systems are setup more correctly according to the current locale name. If the locale name doesn't specify a charset, the default is what glibc defines. This change may result in using the different coding systems as default in some locale (e.g. vi_VN). --- Ken'ichi HANDA [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired-compare-directories
>From my previous message: I do not know whether anything relies on this behavior, but before making any incompatible change this close before a release, one would better be really extra careful. After grepping, I could not immediately find anything relying on the behavior, but, if you are going to make the change, it would be better if you double checked this yourself (but maybe you have already done so). The function apparently was (will be) introduced in 22.1, so that we do not have to worry about backward compatibility. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired-compare-directories
Juri Linkov wrote: For example, after typing RET in the minibuffer in the default directory "~/dir1/" after calling: (read-directory-name "Directory: " "~/dir2/") it returns "~/dir1/" instead of "~/dir2/" as would be more correct. Is this behavior not consistent with the description of the function in `(elisp)Reading File Names'? -- Function: read-directory-name prompt &optional directory default existing initial This function is like `read-file-name' but allows only directory names as completion possibilities. If DEFAULT is `nil' and INITIAL is non-`nil', `read-directory-name' constructs a substitute default by combining DIRECTORY (or the current buffer's default directory if DIRECTORY is `nil') and INITIAL. If both DEFAULT and INITIAL are `nil', this function uses the current buffer's default directory as substitute default, ignoring DIRECTORY. I do not know whether anything relies on this behavior, but before making any incompatible change this close before a release, one would better be really extra careful. Any change would of course, have to be accompanied by a change in the above description. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No autoload cookie for flymake-mode
In lisp/progmodes/flymake.el, the flymake-mode minor mode function has no autoload cookie. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
There are usually good reasons to follow standards. That's why we usually follow them. But that's not the issue I'm talking about. What I'm telling you is that the standards are not authorities. We do not *have to* follow them. Arguments that presume that the standard is an authority we must obey are simply invalid. The decision about whether to follow any given standard on any given issue is a practical decision. Telling us that "Unicode says XYZ" is an argument in favor of doing XYZ. It is not an open-and-shut decision. By the way, can anyone find a copy of the original announcement of the POSIXLY_CORRECT environment variable? It provides a good example of how we sometimes decide not to follow a standard, and was also funny, so it would be nice to publish it again. Are you abandoning Unicode-based Emacs? I still want a future version of Emacs to use primarily Unicode. My views on this issue are unchanged. A Unicode-based Emacs means an Emacs whose character codes are mostly those of Unicode, and which works more or less according to Unicode specifications. It does not mean an Emacs that slavishly obeys whatever Unicode says. We don't slavishly obey standards. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: browse-url doesn't support firefox
A script that's meant to provide the browser in Debian by dispatching to the right thing. See the man page, as you have a Debian system, don't you? There is no man page for sensible-browser. Apparently my version] of Debian is too old for that. Don't worry about it. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired-compare-directories
I propose the following fix for `read-directory-name'. It uses the same directory name DIR for DEFAULT-DIRNAME. This is on the border between a bug fix and a new feature. So I guess it can be installed. It might break something, but probably will not. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
> I don't recall rejecting "multilingual menus", and in principle I'm in > favor of them. However, that is a very terse description, and so I'm > not sure precisely what idea I might have discussed and rejected in > the past, or how it relates to this. You rejected the maths menu because it wouldn't display properly in the Lucid menu as far as I remember. That doesn't give me a clear picture of what the issue was, but it says enough to tell me that these are two different kinds of issue. The old issue was, it appears, about whether to USE certain multilingual text in the menu, not an issue of whether to implement multilingual menus. I am in favor of implement multilingual menus, and have been wanting this for years. So I really appreciate the work that has been done. When the Emacs implementation of multilingual menus gets good enough, at some point we might start putting some into Emacs. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: default value of terminal-coding-system
Emacs needs to learn more about combining characters before it can handle such things correctly. Emacs knows quite a bit about combining characters; what precisely is it doing wrong? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No autoloads in filesets.el
filesets.el, which is new to Emacs 22, contains no autoload cookies. The commentary says to put (require 'filesets) and (filesets-init) in your .emacs if you want to use it. This is strange for a package distributed with Emacs. It is not unacceptable. Since enabling the feature requires adding hooks in important places, just loading the file should not do it. However, it can't hurt to make filesets-init autoload. I will do that. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
turning off (or enhancing) a couple of new features
In the NEWS file it says ** TeX modes: [...] *** verbatim environments are now highlighted in courier by font-lock and super/sub-scripts are made into super/sub-scripts. Some people, including me, find such behavior bizarre, and prefer to have it off. Turning it off can be accomplished by running: (setq font-lock-maximum-decoration '((tex-mode . 2) (latex-mode . 2) (t . t))) However, this is not documented specifically anywhere in the manuals or docstrings (at least not that I am aware of), and I had to ask on help-gnu-emacs to learn how to get things back to "normal". I would like to suggest that the documentation be adjusted to make it more obvious how to get the "normal" (old) behavior. (And perhaps there could be a slightly more compact way of doing it thrown together.) Also, the NEWS file documents changes to the `undo' mechanism, ** When the undo information of the current command gets really large (beyond the value of `undo-outer-limit'), Emacs discards it and warns you about it. In fact, Emacs doesn't just warn me, I think it actually prompts me and asks if I think it is OK to discard the information. I always say yes, and I would like to know how to get it to always just *silently* throw the undo information away. According to the documentation I read, it is basically essential that the info be jettisoned whenever we get beyond `undo-outer-limit', so I don't see why I should be asked/told about it. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: default value of terminal-coding-system
In article <[EMAIL PROTECTED]>, Stefan <[EMAIL PROTECTED]> writes: >> So, which terminal-coding-system should we set by default when LANG is >> de_DE.UTF-8(en_US.UTF-8), iso-latin-1 or utf-8? > At least on reasonably recent xterms, it needs to be utf-8. > On older xterms, I'd expect people don't use a utf-8 locale anyway. > How 'bout the patch below? I agree with that change, and thank you for installing it. It should fix the problem I introduced with my previous change. --- Ken'ichi HANDA [EMAIL PROTECTED] > Index: mule-cmds.el > === > RCS file: /cvsroot/emacs/emacs/lisp/international/mule-cmds.el,v > retrieving revision 1.266 > diff -u -u -b -r1.266 mule-cmds.el > --- mule-cmds.el 15 Mar 2005 02:32:23 - 1.266 > +++ mule-cmds.el 24 Mar 2005 16:56:59 - > @@ -1734,7 +1734,7 @@ > (reset-language-environment) > -(defun set-display-table-and-terminal-coding-system (language-name) > +(defun set-display-table-and-terminal-coding-system (language-name > coding-system) >"Set up the display table and terminal coding system for LANGUAGE-NAME." >(let ((coding (get-language-info language-name 'unibyte-display))) > (if coding > @@ -1748,7 +1748,7 @@ > (dotimes (i 128) > (aset standard-display-table (+ i 128) nil > (or (eq window-system 'pc) > - (set-terminal-coding-system coding > + (set-terminal-coding-system (or coding-system coding) > (defun set-language-environment (language-name) >"Set up multi-lingual environment for using LANGUAGE-NAME. > @@ -1830,7 +1830,7 @@ > (with-current-buffer (car list) > (set-case-table (standard-case-table))) > (setq list (cdr list)) > -(set-display-table-and-terminal-coding-system language-name)) > +(set-display-table-and-terminal-coding-system language-name nil)) >(let ((required-features (get-language-info language-name 'features))) > (while required-features > @@ -2446,7 +2446,8 @@ > ;; we are using single-byte characters, > ;; so the display table and terminal coding system are irrelevant. > (when default-enable-multibyte-characters > - (set-display-table-and-terminal-coding-system language-name)) > + (set-display-table-and-terminal-coding-system > + language-name coding-system)) > ;; Set the `keyboard-coding-system' if appropriate (tty > ;; only). At least X and MS Windows can generate > ___ > Emacs-pretest-bug mailing list > Emacs-pretest-bug@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: better `up-list' for emacs-lisp, fundamental modes
Some time ago (Tue, 22 Feb 2005), I made a suggestion on how
`up-list' could be improved.
Specifically, I said - why do I get an error here?
(concat "this-is-a-string" "--this-is-too")
^;=> up-list: Scan error: "Unbalanced parentheses", 656 771
Stephen had me pretty well convinced that this error couldn't be
gotten rid of easily with the current technology. He said:
Try this:
(concat "hello (" var ") there")
^
with your suggestion of ignoring " (and hence in text-mode), in the above
scenario, you'd jump to the paren inside the string, which is wrong.
He also said:
Knowing whether you're inside a string can require scanning the whole buffer
from point-min, which can be problematic. The new function syntax-ppss can
be used to try and make this efficient, but any such change should be
postponed to after Emacs-22.1.
I do wonder how problematic things can be - since font lock seems to
do a pretty good job of identifying what is inside of a string and
what is outside. (And cases where it can't do this seem to be
legitimate bugs that should be fixed.)
Thus I would like to submit the following slightly adjusted
suggestion: do not turn off strings, rather, use what we already know
about strings from font lock, when it is turned on, specifically, what
is inside quotes and what is outside quotes, to set text properties of
characters that are *inside* quotes such that these characters are
ignored by `up-list'.
Something like this would appear to deal correctly with the
"hello (" ") there"
example.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Symbol's value as variable when byte-compiling an eval-when-compile
1. Byte-compiling a file nero.bug.el on gnu/linux containing only the following two defvars: (defvar nero-link-regexp "\\[\\([0-9]+\\)\\]" "Regular expression that tells nero what links look like. The first parenthesized subexpression is the unique string denoting the webpage to load, which will sought among the references.") (defvar nero-font-lock-keywords (eval-when-compile (list `(,nero-link-regexp . font-lock-keyword-face))) "Font lock for `nero-mode'. Currently, only numbered links are fontified.") Generates the following error in *Messages*: *Messages* buffer Compiling file /eng/eng10/ascott/nero.bug.el at Fri Mar 25 16:23:40 2005 Entering directory `/eng/eng10/ascott/' nero.bug.el:9:31:Error: Symbol's value as variable is void: nero-link-regexp 2. The author of the nero.el package supplied the following update to the 2nd defvar (removing the eval-when-compile), eliminating my byte-compile error: (defvar nero-font-lock-keywords (list `(,nero-link-regexp . font-lock-keyword-face)) "Font lock for `nero-mode'. Currently, only numbered links are fontified.") 3. Question: Is there an explanation of a. Why the package author wasn't seeing the original file byte-compile error with a recent CVS snapshot on MacOS, yet I was on gnu/linux? b. How the fix/workaround works? Thanks, Andy Scott In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit) of 2005-03-25 on chlr4920 Distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--prefix=/stor/garray/linux' '--x-includes=/usr/intel/pkgs/X11/R6.7.0/include' '--x-libraries=/usr/intel/pkgs/X11/R6.7.0/lib' 'CC=gcc' 'CFLAGS=-O2 -I/usr/intel/pkgs/X11/R6.7.0/include -L/usr/intel/pkgs/X11/R6.7.0/lib -I/usr/intel/pkgs/zlib/1.2.1/include -L/usr/intel/pkgs/zlib/1.2.1/lib -I/usr/intel/pkgs/ncurses/5.4/include -L/usr/intel/pkgs/ncurses/5.4/lib -I/usr/intel/pkgs/libungif/4.1.3/include -L/usr/intel/pkgs/libungif/4.1.3/lib -I/usr/intel/pkgs/libpng/1.0.16rc1/include -L/usr/intel/pkgs/libpng/1.0.16rc1/lib -I/usr/intel/pkgs/jpeg/6b/include -L/usr/intel/pkgs/jpeg/6b/lib' 'LDFLAGS=-L/usr/intel/pkgs/X11/R6.7.0/lib -L/usr/intel/pkgs/zlib/1.2.1/lib -L/usr/intel/pkgs/ncurses/5.4/lib -L/usr/intel/pkgs/libungif/4.1.3/lib -L/usr/intel/pkgs/libpng/1.0.16rc1/lib -L/usr/intel/pkgs/jpeg/6b/lib -Wl,-rpath=/usr/intel/pkgs/X11/R6.7.0/lib:/usr/intel/pkgs/zlib/1.2.1/lib:/usr/intel/pkgs/ncurses/5.4/lib:/usr/intel/pkgs/libungif/4.1.3/lib:/usr/intel/pkgs/libp! ng/1.0.16rc1/lib:/usr/intel/pkgs/jpeg/6b/lib'' Important settings: value of $LC_ALL: en_US value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: C locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Compilation Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent messages: Loading font-lock...done Fontifying *Compile-Log*... (regexps..) Loading font-lock...done Loading byte-opt...done Loading warnings...done Byte compile error for /eng/eng10/ascott/memo/emacs/nero.bug.el: t Mark set [2 times] Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: debug.el patch attached
Here's a test case against debug.el 1.77. Evaluate in *scratch*: (setq foo "100%") (debug) (debugger-record-expression 'foo) The error "Not enough arguments for format string" occurs. I have verified that DG's patch works. -Dave D Goel wrote: I do not have a test case where this causes problem, but I believe this missing "%s" after message is wrong. The patch is against the debug.el currently in cvs. Can you apply thid patch if it looks reasonable? Patch is attached. Would have applied myself, but can't build the latest cvs to test it before applying. (ref: accompanying bug report). Sincerely, DG http://gnufans.net/ -- ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
On Mar 25, 2005, at 8:15 AM, Dave Love wrote: I don't see what this has to do with Emacs. Why would you want that in an Emacs sub-process but not interacting with python from the shell? In the shell, the text wraps around to the next line, which is acceptable. This is not the case for Emacs windows split vertically with C-x 3 or ECB. Using pprint eliminates the need for horizontal scrolling in this case. You do make a good point though; this is essentially a Python configuration and not an Emacs one. I do notice that completion doesn't seem to work if an item's list of attributes is too long (try completing "os."). Is that one of these bugs, or have I managed to overlook something? What is the problem in that case? I don't see it on a quick try. On my system, the emacs.py rlcompleter interface works correctly and outputs a string, but python.el does not successfully read this string and reports "Can't find completion for "os."" I am using CVS from 20 March on Mac OS X. The problem occurs both in Emacs.app and emacs -q -nw. Judging by your experience, I fear it might be specific to my platform. Thanks, Steve ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
debug.el patch attached
I do not have a test case where this causes problem, but I believe this missing "%s" after message is wrong. The patch is against the debug.el currently in cvs. Can you apply thid patch if it looks reasonable? Patch is attached. Would have applied myself, but can't build the latest cvs to test it before applying. (ref: accompanying bug report). Sincerely, DG http://gnufans.net/ -- debug-diff.el Description: application/emacs-lisp ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacscvs 'make bootstrap' fails
Loading loaddefs.el (source)... ((107135 . 6946) (7503 . 0) (570 . 113) 1072301 18907 (40 . 33) (18 . 0) (13359 . 60)) Loading simple (source)... Loading help (source)... Loading international/mule-cmds (source)... Loading case-table (source)... Loading international/utf-8 (source)... Loading international/utf-16 (source)... Loading international/characters (source)... Loading international/latin-1 (source)... Loading international/latin-2 (source)... Loading international/latin-3 (source)... Loading international/latin-4 (source)... Loading international/latin-5 (source)... Loading international/latin-8 (source)... Loading international/latin-9 (source)... Loading language/chinese (source)... Loading language/cyrillic (source)... Symbol's value as variable is void: non-iso-charset-alist make[1]: *** [bootstrap-emacs] Error 255 make[1]: Leaving directory `/usr/spcusrmy/deego/pub/src/emacscvs/emacs/src' make: *** [bootstrap-build] Error 2 in the latest CVS. I did make sure to make distclean, and configure, before trying 'make bootstrap'. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Dave Love] python.el: block is ended prematurely
HallÃchen! Stefan Monnier <[EMAIL PROTECTED]> writes: >>> python.el ends the current block if a line starts with "return". >>> However, it doesn't checkt whether this is followed with "_". >>> So, if I write >>> >>> return_count = 4 >>> >>> python.el closes the current block wrongly. > > I've installed Dave's suggestion in Emacs-CVS. Can you confirm > that it fixes your bug? Yes, it does. Thanks to both of you! TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: icomplete-mode deactivates region
>>> This problem currently prevents AUCTeX users from marking LaTeX >>> environments as long as icomplete-mode is active. >> It only prevents them if they use M-x ..., not if they use a key-binding to >> mark the environment, right? > Yes. >> Does the patch below help? > Yes, it does. Thanks very much for looking into this. Thanks, I've installed it, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Dave Love] python.el: block is ended prematurely
>> python.el ends the current block if a line starts with "return". >> However, it doesn't checkt whether this is followed with "_". So, >> if I write >> >> return_count = 4 >> >> python.el closes the current block wrongly. I've installed Dave's suggestion in Emacs-CVS. Can you confirm that it fixes your bug? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
>> Check the code: I encode in the locale's coding system and I've changed >> lwlib to use the Xmb* functions. > I didn't see it. I assumed you were referring to: Well, there are several changes, spread over a few days. The Xmb* ones are of course listed in lwlib/ChangeLog. > It's a pity if you again spent time on stuff I'd done before. I couldn't find your code, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
obscure new display features
I find the new display features concerning `escape-glyph' and `show-nonbreak-escape' annoying, but also they're obscure and partly inconsistent. This is roughly what I went through on encountering them. First you wonder why, say, ^L in your source files is apparently being font-locked as a keyword. You use C-u C-x =, and there's no clue -- no face property or display table entry. You then look for an overlay with no joy. Huh? Surely something like this should be done with a display table. You have no clue how to turn it off without finding the entry in NEWS. There apparently isn't anything in Custom about it, either in the `display' group or via M-x customize-changed. You need to know to look for it either in a face doc string or the Lisp manual, but I wouldn't guess to search for `escape-glyph'. The situation is similar for `show-nonbreak-escape'. Actually that's more annoying since it changes the display and layout of things likely actually to use NBSP for layout. It's also inconsistent and partly incorrect. I've no idea why non-breaking characters should be displayed like this, but U+00AD isn't one -- it's SOFT HYPHEN. If you're going to change its display, the issue (see Unicode) is whether or not it should be displayed at all -- not that I think it should be invisible. NON-BREAKING HYPHEN is U+2011. The inconsistency is that non-breaking space is at codepoint 32 in at least all the iso8859 Emacs charsets, but apparently only the 8859-1 version is treated. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: extra locale entries
Kenichi Handa <[EMAIL PROTECTED]> writes: >> Doesn't this cause incompatible changes for some environments (like >> Vietnamese changing from viscii)? > > Yes. Shouldn't that be noted in NEWS anyway? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
Kenichi Handa <[EMAIL PROTECTED]> writes: > How about enabling quail-completion on using "TeX" input > method as below? I think it's rare to use TAB while editing > a TeX/LaTeX file, thus using it for quail-completion is ok > while typing some letter. I didn't realize that was implemented. It looks helpful, but it doesn't do what I'd expect. For instance, if I type `\righta TAB', I'd like it to complete to `\rightarrow', like normal completion. That's a separate issue from being able to complete on Unicode names, of course. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
Stefan <[EMAIL PROTECTED]> writes: > Check the code: I encode in the locale's coding system and I've changed > lwlib to use the Xmb* functions. I didn't see it. I assumed you were referring to: 2005-03-12 Stefan Monnier <[EMAIL PROTECTED]> * xmenu.c (ENCODE_MENU_STRING): Explicitly use string_make_unibyte. (list_of_panes, list_of_items, Fx_popup_menu): Use XCAR/XCDR. (digest_single_submenu, xmenu_show): Use ENCODE_MENU_STRING. * xfns.c (xic_defaut_fontset): New constant. (xic_create_fontsetname): New function. Extracted from create_frame_xic. Try to generate a slightly better fontset. (xic_create_xfontset): Use it. (create_frame_xic): Simplify. It's a pity if you again spent time on stuff I'd done before. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: utf-16 not auto-detected when finding file
Kenichi Handa <[EMAIL PROTECTED]> writes: > I don't know which coding systems should be utf-16 in that > environment. It seems that at least > default-file-coding-system should not be utf-16. Do you > know a precise recipe of utf-16 environment and when to use > it? No, sorry. You are right about default-file-coding-system, at least. Maybe it isn't appropriate to do that, but I'd have thought it would be useful at least for Emacs to auto-detect utf-16. That isn't likely to give false positives is it? (This started with wanting to edit Windows registry dumps, which are utf-16.) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
Stefan <[EMAIL PROTECTED]> writes: > I just find the symbols-as-hotkey to make more sense: after all, if you can > generate the proper char (via an XIM input method, for example or by > binding a key to the right keysym), you'll indeed get the same result, so it > is not an abuse of the "hotkey". I realize it's logical, but I don't like the resulting menu layout and I don't think the logic helps the user. > Maybe it's indeed easier for some people if the symbol is on the left-hand > side rather than on the right-hand side (and inside parenthese), but > I strongly suspect it's just a question of habit. I think there's a cognitive reason, but I remember that only gerd's brain seemed to work the same as mine in Emacs circles. > I didn't know about that, but if he rejected maths-menu because of lack for > non-ASCII support in the Lucid menu, he'd presumably not oppose a patch that > adds support for non-ASCII support (and indeed he didn't oppose it). The issue isn't non-ASCII per se. That's always worked to a small extent, e.g. the Latin-1 characters in the maths menu in my locale. It's _multilingual_ text, i.e. being able to display arbitrary characters independent of the locale. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
Steven Huwig <[EMAIL PROTECTED]> writes: >> Anyhow, I don't think it's appropriate for Emacs to override the >> user's Python startup like that. > > If nothing else in the Python environment is being overridden or having > its behavior changed by Emacs, I agree. That's the idea, apart from needing to import emacs.py. > Perhaps a line in documentation > or a customization variable would suffice. I have used Emacs and Python > for some time and never really realized that pprint would solve my line > wrap problems so easily until the question was raised for the dozenth > time by the dozenth acquaintance. I'd like to save others the time to > research the same question while making interacting with Python a bit > nicer out-of-the-box in Emacs. I don't see what this has to do with Emacs. Why would you want that in an Emacs sub-process but not interacting with python from the shell? > I do notice that completion doesn't seem to work if an item's list of > attributes is too long (try completing "os."). > Is that one of these bugs, or have I managed to overlook something? What is the problem in that case? I don't see it on a quick try. > I only just discovered python.el recently, having used python-mode and > being frustrated by it at various points. I'm glad if it's useful. It's a pity it requires an unreleased Emacs. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
Stefan <[EMAIL PROTECTED]> writes: > >> Also it would be better to fix the bugs in python.el... > > Which bugs? I don't remember them all, but apparently the sub-process fails on Windows and someone just complained to me about an instance where indentation failed where a word boundary should be a symbol boundary. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problems with utf8 chars
In article <[EMAIL PROTECTED]>, Joakim Verona <[EMAIL PROTECTED]> writes: > Symptoms: > utf-8 chars doesnt work in todays emacs. > they show up as empty spaces. > I tried emacs -nw --no-init > and typed some swedish chars =8e5=8e4=8f6. > swedish chars do work at the shell prompt. You are in en_US.UTF-8 locale, so Emacs sends UTF-8 sequence to your terminal. Are you sure that your terminal can display UTF-8 sequence correctly? What is shown when you type C-h C RET? --- Ken'ichi HANDA [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: icomplete-mode deactivates region
* Richard Stallman (2005-03-22) writes: > I think the right answer is to make deactivate-mark buffer-local. > > That might be right, but it is too radical for now. > There are hundreds of places that it might break, and surely > some of them will break. > > You can always fix these problems locally by setting or binding > deactivate-mark in the particular place. WOuld you please fix it that > way? Because I just compiled a fresh CVS checkout of Emacs and still see the problem and haven't found a check-in by Stefan related to the problem, I am a bit unsure whom you are referring to. Should it be fixed in Emacs or AUCTeX? As far as I understood Stefan, it has to be done in Emacs. At least my attempts to bind `deactivate-mark' in the concerned AUCTeX function were unsuccessful. Which is not surprising if the mark is deactivated during the minibuffer exit. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe key ESC ESC: Args out of range
Richard Stallman wrote: When I enter M-x describe-key ESC, then wait 2 or 3 seconds and then press a 2nd ESC, emacs complains: Args out of range: "ESC escape", 0, 14 I can't reproduce this. If it still fails for you, you should be able to debug it easily by putting a breakpoint at args_out_of_range. This error was also reported last month: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-02/msg00071.html I can reproduce it on ms_w32. Backtrace is: #0 args_out_of_range_3 (a1=35165091, a2=0, a3=112) at data.c:150 #1 0x010788d8 in Fsubstring (string=35165091, from=0, to=112) at fns.c:1274 #2 0x0100674b in echo_truncate (nchars=14) at keyboard.c:923 #3 0x01011c8a in read_key_sequence (keybuf=0x82f9a0, bufsize=30, prompt=35165283, dont_downcase_last=0, can_return_switch_frame=0, fix_current_buffer=0) at keyboard.c:8679 #4 0x01011f0e in Fread_key_sequence (prompt=35165283, continue_echo=23629825, dont_downcase_last=23629825, can_return_switch_frame=23629825, command_loop=23629825) at keyboard.c:9529 #5 0x01116d42 in Fcall_interactively (function=24685569, record_flag=23629825, keys=23707652) at callint.c:616 #6 0x0101239c in Fcommand_execute (cmd=24685569, record_flag=23629825, keys=23629825, special=23629825) at keyboard.c:9698 #7 0x010073d7 in command_loop_1 () at keyboard.c:1792 #8 0x0101e407 in internal_condition_case (bfun=0x10070c0 , handlers=23714417, hfun=0x1006ab0 ) at eval.c:1385 #9 0x01006ded in command_loop_2 () at keyboard.c:1319 #10 0x0101df0f in internal_catch (tag=23703513, func=0x1006dc0 , arg=23629825) at eval.c:1144 #11 0x01006d9c in command_loop () at keyboard.c:1298 #12 0x01006835 in recursive_edit_1 () at keyboard.c:991 #13 0x0100696d in Frecursive_edit () at keyboard.c:1052 #14 0x01003500 in main (argc=3, argv=0x1950e30) at emacs.c:1767 read_key_sequence() assumes that the minibuf starts with the initial prompt "Describe key: ", but it only contains "ESC escape". The prompt is cleared from the minibuf when you press the first ESC. This clearing behavior does not occur for me on 21.2. When describe-key is run interactively, echo_message_buffer is set to "Describe key: " by message3_nolog(), but then reset to Qnil by echo_area_display(): #0 echo_area_display (update_frame_p=1) at xdisp.c:8127 #1 0x0103da24 in message3_nolog (m=35054387, nbytes=14, multibyte=0) at xdisp.c:6976 #2 0x01006609 in echo_now () at keyboard.c:878 #3 0x01011d7c in read_key_sequence (keybuf=0x82f9a0, bufsize=30, prompt=35054387, dont_downcase_last=0, can_return_switch_frame=0, fix_current_buffer=0) at keyboard.c:8579 #4 0x01011f0e in Fread_key_sequence (prompt=35054387, continue_echo=23629825, dont_downcase_last=23629825, can_return_switch_frame=23629825, command_loop=23629825) at keyboard.c:9529 #5 0x01116d42 in Fcall_interactively (function=24685569, record_flag=23629825, keys=23707652) at callint.c:616 When read_char() gets its first char, it clears the minibuf by calling cancel_echoing() at line 2590, because echo_message_buffer is Qnil but echo_area_buffer[0] isn't. If echo_area_display() is modified to not change echo_message_buffer, this error goes away. CVS revision 1.976 made this change, but I don't know what it fixed... -Dave ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
