Re: Emacs puts binary junk into the clipboard, marking it as text
Kenichi Handa skrev: In article [EMAIL PROTECTED], Jan D. [EMAIL PROTECTED] writes: I've checked in a fix that changes UTF8_STRING to STRING if the data doesn't look like UTF8. However, this might give errors too. The only way to be sure to copy raw binary data correctly is by adding a new type (like application-specific/octet-stream). But if we do that, nobody will be able to get data from Emacs, as such a type is not standard and unsupported. Copy-paste with raw binary data is just something most apps don't do. AFAIK, only when TEXT is requested, an selection owner can choose the returning type from STRING, COMPOUND_TEXT, or UTF8_STRING. When UTF8_STRING is requested, we should return it or return nothing. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. What would that do to illegal UTF-8 sequences in the original unibyte string? I.e. will this procedure always produce valid UTF-8 data? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Kenichi Handa [EMAIL PROTECTED] writes: Peter Dyballa [EMAIL PROTECTED] writes: Launched with -Q unify-8859-on-decoding-mode is nil unify-8859-on-encoding-mode is t I start i-search in an Unicode encoded buffer (*Help*). In an ISO 8859-1 encoded buffer ä and Ä are found, also in ISO 8859-10, ISO 8859-13 (except for Ä), ISO 8859-14, and ISO 8859-16 encoded buffers, but fails in ISO 8859-2, ISO 8859-3, ISO 8859-4, ISO 8859-9, and ISO 8859-15. It is similiar to ö and ü, accept that these are not found in the ISO 8859-14 encoded buffer. Changing unify-8859-on-decoding- mode's value makes no difference. This is the story I remember. A while ago, I proposed to change isearch so that it translates characters by translation-table-for-input to solve such a problem, but there raised an objection that read-char should do that translation. RMS asked to check if such a change to read-char is surely safe or not, but as such a check is very difficult and time-consuiming, no one took on the job. So, this problem is still unfixed. I again propose to change isearch. When we know that changing read-char is safe in the future, we can cancel that change in isearch. in the future, namely after the release, we are going to switch to the unicode2 branch and presumably the problem will go away. So it does not sound like we should attempt any complicated fix for Emacs 22 that is not going to stay around, anyway. If the one problem where people are complaining is search-and-replace, we should fix that case for Emacs 22 and that's it for Emacs 22, in my opinion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
In article [EMAIL PROTECTED], Jan Djärv [EMAIL PROTECTED] writes: AFAIK, only when TEXT is requested, an selection owner can choose the returning type from STRING, COMPOUND_TEXT, or UTF8_STRING. When UTF8_STRING is requested, we should return it or return nothing. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. What would that do to illegal UTF-8 sequences in the original unibyte string? The original unibyte string won't be in UTF-8 format. But, string-make-multibyte will convert it to a correct multibyte string, thus encoding that multibyte string by UTF-8 will produce a correct UTF-8 string ... usually. I.e. will this procedure always produce valid UTF-8 data? No. If a byte in the original unibyte string is not a valid code point of the primary charset of the current lang. env., string-make-unibyte will produce a multibyte string that contains eight-bit-control or eight-bit-graphic character. Then, encoding it by UTF-8 will results in incorrect UTF-8 sequence. So, for safely, we must delete such eight-bit characters or replace them with U+FFFD (REPLACEMENT CHARACTER) before encoding by UTF-8. Or, in such a case, don't return anything (which means Emacs doesn't hold a requested data). --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
Increment of the counter is suspended during the file dialog/menu operation. And after the operation, the timer fires multiple times continuously until the counter catches up the value that it would be if no file dialog/menu were activated. Weird. Suppose `mouse-autoselect-window-select' cancels the timer after it fired the nth time, for some n 2. There's no reason why the timer was not cancelled when it fired the (n - 1)th time. What's even more troubling: There's no reason why the timer shouldn't fire a (n + 1)th time. My description above is about the count-up example in Simon's message. You can observe a similar behavior using the example and M-! sleep 5 RET Funnily enough, weird was the exact word I used in an email too. But then I thought buffering up the timers to run later might be the most logical thing to do, in the circumstances. Maybe it makes more sense than not running the timers at all. After all, as I'm sure the documentation aught to say, the timer will be repeated *as soon as possible* after REPEAT seconds. The behaviour is consistent at that level. A very quick simple test shows the behaviour seems consistent if the function run by the timer cancels the timer, when the function is run later due to buffering up of timers, in the scenario you describe. I found that buffering up of timers also occurs under X, at least for popups of the sort you get from File Open Directory... Under X, timers are buffered up when the mouse is within the popup (though they are run as you go in/out of the Filter, Directory, Files and Selection areas). I'm not sure why that needs to be so for this particular case though. You learn something every day. At least, I do about Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
My description above is about the count-up example in Simon's message. You can observe a similar behavior using the example and M-! sleep 5 RET I see, delayed window autoselection turns itself off in that case. Anyway, does it make sense that a timer fires more frequently than prescribed by the REPEAT argument? If you keep a dialog window open for a while, timers trying to catch up may keep your system rather busy. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
What did you think of treating the scroll-bars in the same way? (That is, suspend autoselection if scrolling.) I could write ((or (menu-or-popup-active-p) (not (coordinates-in-window-p (cons mouse-x-position mouse-y-position) window))) ;; A menu / popup dialog is active or the mouse is on the scroll-bar. ;; Suspend autoselection. (setq mouse-autoselect-window-suspend t)) in `mouse-autoselect-window-select'. Or did you think of something more elaborate? That looks good. (You can avoid the cons with (cdr mouse-position) instead.) I was thinking that it would also simplify mouse-autoselect-window-cancel, to avoid the tests specific to scrolling, but now I see maybe that's not the case. Ta, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
Funnily enough, weird was the exact word I used in an email too. But then I thought buffering up the timers to run later might be the most logical thing to do, in the circumstances. Maybe it makes more sense than not running the timers at all. After all, as I'm sure the documentation aught to say, the timer will be repeated *as soon as possible* after REPEAT seconds. The behaviour is consistent at that level. A very quick simple test shows the behaviour seems consistent if the function run by the timer cancels the timer, when the function is run later due to buffering up of timers, in the scenario you describe. I admit that the behavior is consistent in each and every sense. I'm not sure whether it's reasonable, though. It's better than not running the timers at all, admittedly. Nevertheless, I think that timers should not run more often than indicated by the repeat argument. The documentation is misleading in any case. It tells you that when Emacs is busy, timers might not run. It doesn't tell you that timers may trigger more frequently than requested when Emacs is idle. I found that buffering up of timers also occurs under X, at least for popups of the sort you get from File Open Directory... Under X, timers are buffered up when the mouse is within the popup (though they are run as you go in/out of the Filter, Directory, Files and Selection areas). I'm not sure why that needs to be so for this particular case though. I agree that one-shot timers are generally better. But when I tried to implement a one-shot timer for delayed autoselection, it occasionally didn't trigger for some reason. Maybe I should give it another try. You learn something every day. At least, I do about Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
I've checked in a fix that changes UTF8_STRING to STRING if the data doesn't look like UTF8. However, this might give errors too. The only way to be sure to copy raw binary data correctly is by adding a new type (like application-specific/octet-stream). But if we do that, nobody will be able to get data from Emacs, as such a type is not standard and unsupported. Copy-paste with raw binary data is just something most apps don't do. AFAIK, only when TEXT is requested, an selection owner can choose the returning type from STRING, COMPOUND_TEXT, or UTF8_STRING. When UTF8_STRING is requested, we should return it or return nothing. Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use to keep track of valid unicode chars that have no corresponding character in emacs-mule. So the presence of eight-bit-* chars does not imply that the utf-8 encoded form of the text will contain an invalid utf-8 byte sequence. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. That sounds terribly fragile/buggy. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes: AFAIK, only when TEXT is requested, an selection owner can choose the returning type from STRING, COMPOUND_TEXT, or UTF8_STRING. When UTF8_STRING is requested, we should return it or return nothing. Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use to keep track of valid unicode chars that have no corresponding character in emacs-mule. So the presence of eight-bit-* chars does not imply that the utf-8 encoded form of the text will contain an invalid utf-8 byte sequence. Yes, but such eight-bit-* chars can be detected by checking `untranslated-utf-8' property. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. That sounds terribly fragile/buggy. Then, what do you think Emacs should do in such a case? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
You learn something every day. At least, I do about Emacs. `timer-max-repeats' is the maximum number of times to repeat a timer, if real time jumps. Hence, there is an upper bound on the number of times such timer run. I think the Elisp manual should mention two things: (1) That a timer can fire more frequently than indicated by the repeat argument once it has been delayed. (2) That there's an upper bound on the number of times a timer may fire more frequently when it has been delayed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
I was thinking that it would also simplify mouse-autoselect-window-cancel, to avoid the tests specific to scrolling, but now I see maybe that's not the case. The test in `mouse-autoselect-window-cancel' serves to avoid that the pre-command hook cancels autoselection while scrolling. I could test whether the mouse is on the scroll bar in the pre-command hook. Do you think it's worth the trouble? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use to keep track of valid unicode chars that have no corresponding character in emacs-mule. So the presence of eight-bit-* chars does not imply that the utf-8 encoded form of the text will contain an invalid utf-8 byte sequence. Yes, but such eight-bit-* chars can be detected by checking `untranslated-utf-8' property. Sure, but the current code doesn't do that. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. That sounds terribly fragile/buggy. Then, what do you think Emacs should do in such a case? I think we can't know what should be done, so we should strive for simplicity and try to avoid losing information. I.e. just return the unibyte string as-is. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for ediff
It currently does word-granularity, and does it very well. Character granularity would probably be too much work compared to what it would provide. Actually, smerge-mode (take a look at smerge-refine) does character-granularity and it wasn't more work (quite the opposite, actually). It usually works great, but it turns out that character granularity sometimes fails spectacularly (diff gets confused by some apparent similarity somewhere and ends up getting completely out of sync). It'd probably be best to layer the diffs: first do a word-granularity diff and then do a char-granularity diff within words. But maybe that'd be too slow. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Unable to run (Carbon) emacs from the command line
This isn't so much a bug, per se, as it is missing functionality. It would be convenient to be able to run emacs from the command line, as well as emacsclient. However, the actual binaries are not on the path (obviously) and when I place a symlink to them in ~/bin and invoke them from there (~/ bin/emacs ~/.bashrc, for example) I get this: Warning: arch-dependent data dir (/Volumes/Emacs/Emacs.app/Contents/ MacOS/libexec/emacs/22.0.50/i386-apple-darwin8.7.1/) does not exist. Warning: arch-independent data dir (/Applications/Emacs.app/Contents/ Resources/share/emacs/22.0.50/etc/) does not exist. Subsequent to that, I get no emacs window. If I invoke the command by typing ~/Applications/Emacs.app/Contents/ MacOS/Emacs I get a working window. In GNU Emacs 22.0.50.1 (i386-apple-darwin8.7.1) of 2006-08-19 on petit.local X server distributor `Apple Computers', version 10.4.7 configured using `configure '--prefix=/Applications/Emacs.app/ Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/ Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 - arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI - DUSE_MAC_TSM'' Important settings: value of $LC_ALL: nil 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: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: encoded-kbd-mode: t show-paren-mode: t tooltip-mode: t mac-input-method-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p tab o tab r tab return Recent messages: Loading senator...done Source file `/Users/offline/.emacs.d/modules/cedet-1.0pre3/semantic/ semanticdb-find.el' newer than byte-compiled file Source file `/Users/offline/.emacs.d/modules/cedet-1.0pre3/semantic/ semantic-sort.el' newer than byte-compiled file Source file `/Users/offline/.emacs.d/modules/cedet-1.0pre3/semantic/ semantic-ia-sb.el' newer than byte-compiled file ECB 2.32 uses loaded semantic 2.0pre3, eieio 1.0pre3 and speedbar 1.0. Loading /Users/offline/.emacs.d/modules/nxml-mode-20041004/rng- auto.el (source)...done Loading semantic-el...done Loading encoded-kb...done Making completion list... [2 times] Loading emacsbug...done -- Chris Rose DeveloperACI Worldwide/TSA 424-4922 ext 339 [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
Stefan Monnier skrev: Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use to keep track of valid unicode chars that have no corresponding character in emacs-mule. So the presence of eight-bit-* chars does not imply that the utf-8 encoded form of the text will contain an invalid utf-8 byte sequence. Yes, but such eight-bit-* chars can be detected by checking `untranslated-utf-8' property. Sure, but the current code doesn't do that. And, if Emacs owns a unibyte string, perhaps the right thing is to make it multibyte according to the current lang. env. (by string-make-multibyte) at first, then encode it by utf-8. That sounds terribly fragile/buggy. Then, what do you think Emacs should do in such a case? I think we can't know what should be done, so we should strive for simplicity and try to avoid losing information. I.e. just return the unibyte string as-is. That was the problem the original report was about. Gtk+-applications print big warnings. And there is no agreed upon selection type that represents just bytes. W.r.t the standards, Emacs has two choices, return a valid UTF8-string or don't return anything at all. I'm beginning to think the second option is the best. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
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
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
A while ago, I proposed to change isearch so that it translates characters by translation-table-for-input to solve such a problem, but there raised an objection that read-char should do that translation. RMS asked to check if such a change to read-char is surely safe or not, but as such a check is very difficult and time-consuiming, no one took on the job. So, this problem is still unfixed. I again propose to change isearch. Yes, let's do it that way. Could you do it now? David Kastrup wrote: in the future, namely after the release, we are going to switch to the unicode2 branch and presumably the problem will go away. That is true, so we already have our long-term solution. For now, fixing isearch is sufficient. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs puts binary junk into the clipboard, marking it as text
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes: I think we can't know what should be done, so we should strive for simplicity and try to avoid losing information. I.e. just return the unibyte string as-is. Even if it doesn't conform to ICCCM? I'll attach the relevant part of that document. Jan D. [EMAIL PROTECTED] writes: W.r.t the standards, Emacs has two choices, return a valid UTF8-string or don't return anything at all. I'm beginning to think the second option is the best. This will be useful for checking UTF-8 validity. (define-ccl-program ccl-check-utf-8 '(0 ((r0 = 1) (loop (read-if (r1 #x80) (repeat) ((r0 = 0) (if (r1 #xC2) (end)) (read r2) (if ((r2 #xC0) != #x80) (end)) (if (r1 #xE0) ((r0 = 1) (repeat))) (read r2) (if ((r2 #xC0) != #x80) (end)) (if (r1 #xF0) ((r0 = 1) (repeat))) (read r2) (if ((r2 #xC0) != #x80) (end)) (if (r1 #xF8) ((r0 = 1) (repeat))) (read r2) (if ((r2 #xC0) != #x80) (end)) (if (r1 == #xF8) ((r0 = 1) (repeat))) (end)) Check if the input unibyte string is a valid UTF-8 sequence or not. If it is valid, set the register `r0' to 1, else set it to 0.) (defun string-utf-8-p (string) Return non-nil iff STRING is a unibyte string of valid UTF-8 sequence. (if (or (not (stringp string)) (multibyte-string-p string)) (error Not a unibyte string: %s string)) (let ((status (make-vector 9 0))) (ccl-execute-on-string ccl-check-utf-8 status string) (= (aref status 0) 1))) --- Kenichi Handa [EMAIL PROTECTED] Inter-Client Communication Conventions Manual Version 2.0.xf86.1 [...] 2.7. Use of Selection Properties The names of the properties used in selection data transfer are chosen by the requestor. The use of None property fields in ConvertSelection requests (which request the selection owner to choose a name) is not permitted by these conventions. The selection owner always chooses the type of the property in the selection data transfer. Some types have special semantics assigned by convention, and these are reviewed in the following sections. In all cases, a request for conversion to a target should return either a property of one of the types listed in the previous table for that target or a property of type INCR and then a property of one of the listed types. Certain selection properties may contain resource IDs. The selection owner should ensure that the resource is not destroyed and that its contents are not changed until after the selection transfer is complete. Requestors that rely on the existence or on the proper contents of a resource must operate on the resource (for example, by copying the con- tents of a pixmap) before deleting the selection property. The selection owner will return a list of zero or more items of the type indicated by the property type. In general, the number of items in the list will correspond to the number of disjoint parts of the selection. Some targets (for example, side-effect targets) will be of length zero irrespective of the number of disjoint selection parts. In the case of fixed-size items, the requestor may determine the number of items by the property size. Selection property types are listed in the table below. For variable-length items such as text, the separators are also listed. - Type Atom Format Separator - APPLE_PICT8 Self-sizing ATOM 32 Fixed-size ATOM_PAIR 32 Fixed-size BITMAP32 Fixed-size C_STRING 8 Zero COLORMAP 32 Fixed-size COMPOUND_TEXT 8 Zero DRAWABLE 32 Fixed-size INCR 32 Fixed-size INTEGER 32 Fixed-size PIXEL 32 Fixed-size PIXMAP32 Fixed-size SPAN 32 Fixed-size STRING8 Zero UTF8_STRING 8 Zero WINDOW32 Fixed-size - It is expected that this table will grow over time. 2.7.1. TEXT Properties In general, the encoding for the characters in a text string property is specified by its type. It is highly desirable for there to be a simple, invertible mapping between string property types and any character set names embedded within font names in any font naming standard adopted by the Con- sortium. The atom TEXT is a polymorphic target. Requesting conver- sion into TEXT will convert into whatever encoding is conve- nient for the owner. The encoding chosen will be indicated by the type of the property returned. TEXT is not defined as a type; it will never be the returned type from a selec- tion conversion request. If the requestor wants the owner to return the contents of the selection in a specific encoding, it
emacs conflicts with gnome-settings-daemon
There's a lot of report from chinese Emacs community that Emacs conflicts with gnome-settings-daemon. `C-SPC' is widely accepted as the hot-key to activate XIM input method such as SCIM or fcitx in chinese linux community. But when gnome-settings-daemon is running, `C-SPC' is swallowed by emacs and not passed to the system, it's really a big trouble because that mean's you can't input chinese with XIM in Emacs. I'm not sure it's a bug of GNOME or Emacs, but only Emacs users observed this phenomenon, so I report it here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: leim: No such file or directory
In article [EMAIL PROTECTED], Leon [EMAIL PROTECTED] writes: 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. Do you see the same bug with HEAD? Anyway, I'd like to repeat this. Please show us the full output mesage of make command. 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 You wrote that `make install prefix=/tmp/E/emacs' gives error, but `make install' will run without error.. The above procedure is the third pattern. Do you meant that the first two patterns give the same result as before? And does emacs still complains really mean that leim: No such file or directory is printed by Emacs, not by make command? --- Kenichi Handa [EMAIL PROTECTED] 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/sh! are/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/pack ages/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-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for ediff
Stefan Monnier [EMAIL PROTECTED] writes: It'd probably be best to layer the diffs: first do a word-granularity diff and then do a char-granularity diff within words. That's my opinion too. But maybe that'd be too slow. This is why I was proposing just looking at the beginning and end of each word, which is two comparison if the words are actually different, and linear in the number of common chars otherwise. -- Matthieu ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
