language environment should not be derived from LC_CTYPE
[ I already sent this yesterday (via Gmane), but apparently it didn't make it to the list ([EMAIL PROTECTED]). Sorry if you get it twice. ] `M-x report-emacs-bug' wrote: Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I have the following locale settings [1]: $ env|grep -e LC_ -e LANG LANG=en_US LC_COLLATE=POSIX [EMAIL PROTECTED] $ emacs -Q `current-language-environment's value is German and I get the German tutorial. I expected to see the English version and an English language environment: ,[ (info (libc)Locale Categories) ] | `LC_CTYPE' | This category applies to classification and conversion of | characters, and to multibyte and wide characters; see *Note | Character Handling::, and *Note Character Set Handling::. | | [...] | | `LC_MESSAGES' | This category applies to selecting the language used in the user | interface for message translation (*note The Uniforum approach::; | *note Message catalogs a la X/Open::) and contains regular | expressions for affirmative and negative responses. | | `LC_ALL' | This is not an environment variable; it is only a macro that you | can use with `setlocale' to set a single locale for all purposes. | Setting this environment variable overwrites all selections by the | other `LC_*' variables or `LANG'. | | `LANG' | If this environment variable is defined, its value specifies the | locale to use for all purposes except as overridden by the | variables above. ` In GNU Emacs 22.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of 2006-11-21 on viandante X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=...' '--with-gtk' '--exec-prefix=...'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: POSIX value of $LC_CTYPE: [EMAIL PROTECTED] value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Bye, Reiner. [1] If you wonder why I use a mixture of de_DE and en_US locales: I want to display the € in plain text files in xterm, but I prefer English program interfaces. (Some of my systems offer en_US.iso885915, but IIRC not all.) -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Use font-lock-support-mode rather than calling lazy-lock-mode
Dear Richard, Thank you for pointing out debug-on-entry to me. This seems to be the easiest solution if I find other new problems with pretest version concerning old elisp libraries that are OUTSIDE the standard distribution. I no longer have to load the emacs lisp source file and interactively define debug break point. Richard Stallman wrote: Now, I tried in vain to figure out where the lazy-lock-mode is possibly set in *my own library files. and/or impoted from emacs archive*. You can debug that by means of debug-on-entry; call it at the start of your .emacs file and you should find out what enables lazy-lock. I would not want to change turn-on-lazy-lock to enable jit-lock instead of lazy-lock; that would be incoherent. What MIGHT make sense is to make lazy-lock-mode an alias for jit-lock-mode. That is coherent, but somewhat drastic. Are we sure that there is no reason at all for anyone to use lazy-lock any more? Now, I have no idea whether depreciating lazy-lock may cause problems for others, but given that emacs 21 version has been around for a quite a while, it may take the users a prolonged time to update their *own* library files, initialization files, etc. to move over to newer packages/libraries. I leave the decision for the fate of lazy-lock to the experienced emacs hackers. But from the lusers's point of view, it would be nice to have a guideline of how to move over to newer and more powerful libraries/packages such as jit-lock from lazy-lock. (Info doesn't seem to have been updated... Just a thought. Happy Hacking, Chiaki Ishikawa ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
cc-mode: c-backslash-column silently truncated to even tab-width
Hello. If I set c-backslash-column to 79, I don't get backslahses at column 79, but at column 72. Cc-mode silently truncates the column to an even tab-width. I could not find any documentation on this behaviour, nor is there any way to turn it off, so I can get backslashes at column 79. This behaviour should be documented, and it should be possible to turn it off (i.e. always put backslashes at c-backslash-column regardless of tab-width. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
copying then yanking Czech 'e' character fails
Prepare a file containing a Czech e-with-a-hook character (followed by a newline) in Windows 1250 encoding: $ printf \354\n /tmp/file.txt Ensure DISPLAY is set, and run Emacs: $ emacs -Q Tell Emacs to prefer the Windows 1250 coding system: M-x eval-expression RET (prefer-coding-system 'windows-1250) RET Find the file: C-x C-f /tmp/file.txt RET Note that the \354 character is correctly displayed as a lower-case 'e' with a small 'v' shaped accent over the top of it. Copy the line: C-x h M-w Yank a copy of the line into the same buffer: C-y Note that the yanked copy is different than the text we copied. It shows up as a '?' character. Undo the yank: C-x u Copy the line as a *rectangle*: M- M-SPC C-e C-x r k Paste the killed rectangle a few times: C-x r y C-x r y Notice that now the 'e' character has been copied correctly. This bug only shows up if I use the X version of Emacs. Running emacs -nw 'fixes' it. Before copying the 'e' character, it is: character: ? (331835, #o1210073, #x5103b, U+011B) charset: mule-unicode-0100-24ff (Unicode characters of the range U+0100..U+24FF.) code point: #x20 #x3B syntax: w which means: word category: l:Latin buffer code: #x9C #xF4 #xA0 #xBB file code: #xEC (encoded by coding system windows-1250-unix) display: by this font (glyph code) -Misc-Fixed-Bold-R-Normal--13-120-75-75-C-70-ISO10646-1 (#x11B) After pasting the copied character, it is: character: ? (63, #o77, #x3f, U+003F) charset: ascii (ASCII (ISO646 IRV)) code point: #x3F syntax: . which means: punctuation category: a:ASCII l:Latin buffer code: #x3F file code: #x3F (encoded by coding system windows-1250) display: by this font (glyph code) -Misc-Fixed-Bold-R-Normal--13-120-75-75-C-70-ISO8859-1 (#x3F) In GNU Emacs 22.0.91.4 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-11-19 on chrislap X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: en_GB.UTF-8 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: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: show-paren-mode: t display-time-mode: t iswitchb-mode: t dynamic-completion-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-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: T h e SPC f u n c t i o n s SPC w h i c h SPC a l l o w SPC y o u SPC t o SPC v i e w SPC r e c e n t SPC k e y s t r o k e s SPC h a v e SPC b e e n C-j h i d d e n SPC b y SPC j - s h e l l , SPC t o SPC p r o t e c t SPC p a s s w o r d s SPC e n t e r e d SPC i n SPC s h e l l SPC b u f f e r s . Recent messages: kill-line: End of buffer Mark set Auto-saving...done Quit [2 times] Making completion list... uncompressing printf.1.gz...done WoMan formatting buffer...done in 0 seconds Quit Mark activated Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: copying then yanking Czech 'e' character fails
Note that the yanked copy is different than the text we copied. It shows up as a '?' character. I've tracked the bug down to 2 lines in lisp/term/x-win.el: In x-select-text(): ;; ICCCM says cut buffer always contain ISO-Latin-1 (encode-coding-string text 'iso-latin-1) In x-cut-buffer-or-selection-value(): ;; ICCCM says cut buffer always contain ISO-Latin-1, but ;; use next-selection-coding-system if not nil. (decode-coding-string cut-text (or next-selection-coding-system 'iso-latin-1)) So the text we copy is encoded to iso-latin-1 and then decoded again, which is what is resulting in the corruption. I've confirmed that replacing iso-latin-1 with windows-1250 in both places fixes the bug for me (for windows-1250 text, of course). This ELISP dialog shows how the corruption happens. I don't know if the 'e' character will show up correctly in this email, but the variable czech-e is bound to a string containing a single character, the czech e-with-a-hook: ELISP czech-e ì ELISP (string-to-list czech-e) (331835) ELISP (string-to-list (encode-coding-string czech-e 'iso-latin-1)) (63) ELISP (string-to-list (decode-coding-string (encode-coding-string czech-e 'iso-latin-1) 'iso-latin-1)) (63) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: copying then yanking Czech 'e' character fails
Note that the yanked copy is different than the text we copied. It shows up as a '?' character. I've tracked the bug down to 2 lines in lisp/term/x-win.el: In GNU Emacs 22.0.91.4 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-11-19 on chrislap 2006-11-20 Jan Djärv [EMAIL PROTECTED] * term/x-win.el (x-last-cut-buffer-coding): New variable. (x-select-text): Set it. (x-cut-buffer-or-selection-value): Check also x-last-cut-buffer-coding when checking for newness. Chris, This has been fixed. Update, rebuild and try it again. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: incorrect error message when reverting unreadable file
Does this change give good behavior? *** files.el13 Nov 2006 15:19:14 -0500 1.865 --- files.el21 Nov 2006 21:30:29 -0500 *** *** 4081,4086 --- 4081,4091 File %s no longer exists! Cannot revert nonexistent file %s) file-name)) + ((not (file-readable-p file-name)) + (error (if buffer-file-number + File %s no longer readable! + Cannot revert unreadable file %s) + file-name)) (t ;; Bind buffer-file-name to nil ;; so that we don't try to lock the file. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Well, it's simple enough for Emacs to generate, but if it's a constant strings, it's easier for the other process to recognize it. It is easy to recognize (comint. Please don't exaggerate these minor problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: The key ESC has been rebound, but you can use instead
| ** The key ESC has been rebound, but you can use instead [More information] ** ` I fail to understand what but you can use instead means. Is that because the value is nil? I think that case needs to be handled specially. It can say just The key ESC has been rebound, so you can't use it this way. Additionally, as the warning line is longer than 80 characters it's quite disturbing. Let's change `information' to `info'. I think everyone will understand `info'. BTW, if you do the same with a German language environment, the German tutorial is interrupted by lines in English. Also the NOTICE is in English. You can add German versions in tutorial.el. I think English is better than nothing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Slow operations on buffers of tens of megabytes
Is this in fact the case, for the default case table of Emacs unicode 2 branch, when the change I made for dotless i is installed there? Your change is not yet propagated to emacs-unicode-2 branch. is there any reason not to propagate it there? If it will be propagated, that will fix the problem, right? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: copying then yanking Czech 'e' character fails
A similar bug was fixed some days ago, make sure your CVS is up to date. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: The key ESC has been rebound, but you can use instead
On Wed, Nov 22 2006, Richard Stallman wrote: | ** The key ESC has been rebound, but you can use instead [More information] ** ` I fail to understand what but you can use instead means. Is that because the value is nil? I think that case needs to be handled specially. It can say just The key ESC has been rebound, so you can't use it this way. There must be a bug: I also get you can use instead when I do (global-set-key (kbd C-g) 'goto-line) after emacs -Q. Additionally, as the warning line is longer than 80 characters it's quite disturbing. Let's change `information' to `info'. Better, but even with [More info] or [More], the lines may get too long. I think summarizing the problematic keys _at the very beginning_ of the tutorial or in a splash screen at it's startup would be much better than interrupting the tutorial text several times in the middle of a sentence. Suggestion: Let's keep the colors on the changed keys within the text, but don't print the warning lines (** ... **). When the user clicks on the colored keys, display the corresponding help buffer like we do for on [More information] now. BTW, if you do the same with a German language environment, the German tutorial is interrupted by lines in English. Also the NOTICE is in English. You can add German versions in tutorial.el. I'll do so, but I think the current English version needs improvement first. I think English is better than nothing. I'm not sure. Please try: Enable CUA mode and try to read the French or the Spanish tutorial. --8---cut here---start-8--- Tapez C-v (Voir l'écran suivant) pour passer à l'écran suivant ** The key C-v has been rebound, but you can use next instead [More information] ** (faites-le, pressez la touche CTRL tout en pressant la touche v). À partir de maintenant, vous devrez le faire à chaque fois que vous avez fini de lire l'écran. Vous remarquerez qu'il y a un recouvrement de deux lignes lorsque l'on passe d'un écran à un autre : cela permet une certaine continuité dans la lecture du texte. La première chose que vous devez savoir est comment vous déplacer à travers le texte. Vous savez déjà comment avancer d'un écran avec C-v. Pour revenir un écran en arrière, tapez M-v (pressez la touche ** The key M-v has been rebound, but you can use prior instead [More information] ** META tout en appuyant sur v ou faites ESCv si vous n'avez pas de touche META, EDIT ou ALT). Faites M-v, puis C-v plusieurs fois. ** The key C-v has been rebound, but you can use next instead [More information] ** Si votre terminal en dispose, vous pouvez également utiliser les touches PgUp et PgDn pour monter ou descendre d'un écran, bien que les combinaisons C-v et M-v soient plus efficaces. ** The key M-v has been rebound, but you can use prior instead [More information] ** ** The key C-v has been rebound, but you can use next instead [More information] ** * RÉSUMÉ Les commandes suivantes servent à manipuler des écrans : C-v Avance d'un écran ** The key C-v has been rebound, but you can use next instead [More information] ** M-v Recule d'un écran ** The key M-v has been rebound, but you can use prior instead [More information] ** C-l Efface l'écran et réaffiche tout le texte autour du curseur, qui est placé au milieu de l'écran (il s'agit de CTRL-L, pas de CTRL-1). --8---cut here---end---8--- Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: The key ESC has been rebound, but you can use instead
Reiner Steib [EMAIL PROTECTED] writes: I think summarizing the problematic keys _at the very beginning_ of the tutorial or in a splash screen at it's startup would be much better than interrupting the tutorial text several times in the middle of a sentence. hand. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman [EMAIL PROTECTED] writes: Well, it's simple enough for Emacs to generate, but if it's a constant strings, it's easier for the other process to recognize it. It is easy to recognize (comint. Please don't exaggerate these minor problems. It would be even easier for a shell script to recongize without the parentheses I don't see their purpose (except making the value look like Lisp), so let's leave them out. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: The key ESC has been rebound, but you can use instead
Reiner Steib [EMAIL PROTECTED] writes: I think summarizing the problematic keys _at the very beginning_ of the tutorial or in a splash screen at it's startup would be much better than interrupting the tutorial text several times in the middle of a sentence. Suggestion: Let's keep the colors on the changed keys within the text, but don't print the warning lines (** ... **). When the user clicks on the colored keys, display the corresponding help buffer like we do for on [More information] now. I agree. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Well, it's simple enough for Emacs to generate, but if it's a constant strings, it's easier for the other process to recognize it. It is easy to recognize (comint. Please don't exaggerate these minor problems. I'm not saying it's hard. Just that it is easier for people to adapt to the new scheme if we only change the name of the variable but not its value and if we keep the value constant where it was constant (in some languages (e.g. in a /.bashrc file), changing an exact string match to a substring/prefix match may require more than just changing `equal' to `string-match'). I personally don't see *any* benefit to including the revision information there. So even if the inconvenience is small, it's still an inconvenience and I don't see any justification for it. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
building fails
uname -a gives: Linux hostname 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 i686 i386 GNU/Linux I checked out the unicode branch with tla and ran ./configure --with-gtk --enable-font-backend --with-xft make bootstrap which fails complaining about undefined symbol this_pos_byte on line 1537 in src/search.c; replacing this_pos_byte with pos_byte on line 1537 allows compilation of src/search.c running make bootstrap again then fails with the error messages: Updating /usr/local/src/emacs/leim/leim-list.el ... Loading vc-arch... Wrong type argument: number-or-marker-p, nil make[3]: *** [leim-list.el] Error 255 make[3]: Leaving directory `/usr/local/src/emacs/leim' make[2]: *** [leim] Error 2 make[2]: Leaving directory `/usr/local/src/emacs' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/usr/local/src/emacs' make: *** [bootstrap] Error 2 this appears to be caused by a bug in lisp/vc-hooks.el, line 719: (zerop (logand (file-modes buffer-file-name) 128)) function file-modes returns nil during compliation but logand requires a number; this modification allows it to compile with make bootstrap: (zerop (logand (or (file-modes buffer-file-name) 128) 128)) after these changes, make bootstrap succeeds and emacs works fine. In GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, GTK+ Version 2.10.4) of 2006-11-22 on plandom.phys.ocean.dal.ca X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--enable-font-backend' '--with-xft'' 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: en_DK value of $LANG: en_CA locale-coding-system: iso-latin-1-unix default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: copying then yanking Czech 'e' character fails
This has been fixed. Update, rebuild and try it again. Thanks Nick, that fixes it. I should have tried updating before reporting the bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: incorrect error message when reverting unreadable file
On 11/22/06, Richard Stallman [EMAIL PROTECTED] wrote: Does this change give good behavior? *** files.el13 Nov 2006 15:19:14 -0500 1.865 --- files.el21 Nov 2006 21:30:29 -0500 *** *** 4081,4086 --- 4081,4091 File %s no longer exists! Cannot revert nonexistent file %s) file-name)) + ((not (file-readable-p file-name)) + (error (if buffer-file-number + File %s no longer readable! + Cannot revert unreadable file %s) + file-name)) (t ;; Bind buffer-file-name to nil ;; so that we don't try to lock the file. Yes, it does. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: hexl-max-address in hexl-mode is incorrect]
Sorry, I made a mistaken. Should use encode-coding-string rather than decode-coding-string. On Thu, 23 Nov 2006 00:02:22 +0800, Chong Yidong [EMAIL PROTECTED] wrote: The hexl-max-address usually set to buffer-size, but when the buffer contain a multiple byte character or the file associated to the buffer is encoded by multibyte coding system such as utf-16, the hexl-max-address is usually less the the real byte of buffer. You can test like this: Test case 2: Open a new file, such as /tmp/test.txt. Use C-x RET f to set the file coding system to utf-16. Input any letters such as ab, and save the buffer. Then change mode to hexl-mode. C-h v hexl-max-address show the value is still 2 which is the buffer-size rather than the sizze of the file. Here is my solution to set hexl-max-address which might help: (setq hexl-max-address (1- (if buffer-file-name (nth 7 (file-attributes buffer-file-name)) (length (decode-coding-string (buffer-string) buffer-file-coding-system) The (nth 7 (file-attributes buffer-file-name)) method returns the correct byte count. However, the (decode-coding-string (buffer-string) buffer-file-coding-system) method doesn't seem to work for me; it returns erratic incorrect results. In the case of a utf-16 buffer containing just ab without an associated file, it returns 1; if there is an associated buffer, it returns 0. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Use font-lock-support-mode rather than calling lazy-lock-mode
But from the lusers's point of view, it would be nice to have a guideline of how to move over to newer and more powerful libraries/packages such as jit-lock from lazy-lock. (Info doesn't seem to have been updated... Would you please be more specific? Please show the text that doesn't seem to have been updated, and say the title of the section. Then we can fix it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: hexl-max-address in hexl-mode is incorrect]
Sorry for the mistaken. And I found that use file size may cause some error because the buffer may be modified. This my patch: diff -utbB /home/ywb/lisp/hexl.el /home/ywb/lisp/hexli.el --- lisp/hexl.el2006-10-30 14:47:26.0 +0800 +++ lisp/hexli.el 2006-11-23 14:58:49.0 +0800 @@ -207,31 +207,20 @@ (unless (eq major-mode 'hexl-mode) (let ((modified (buffer-modified-p)) (inhibit-read-only t) - (original-point (- (point) (point-min))) - max-address) - (and (eobp) (not (bobp)) - (setq original-point (1- original-point))) - (if (not (or (eq arg 1) (not arg))) - ;; if no argument then we guess at hexl-max-address - (setq max-address (+ (* (/ (1- (buffer-size)) 68) 16) 15)) -(setq max-address (1- (buffer-size))) -;; If the buffer's EOL type is -dos, we need to account for -;; extra CR characters added when hexlify-buffer writes the -;; buffer to a file. -(when (eq (coding-system-eol-type buffer-file-coding-system) 1) - (setq max-address (+ (count-lines (point-min) (point-max)) - max-address)) - ;; But if there's no newline at the last line, we are off by - ;; one; adjust. - (or (eq (char-before (point-max)) ?\n) - (setq max-address (1- max-address))) - (setq original-point (+ (count-lines (point-min) (point)) - original-point)) - (or (bolp) (setq original-point (1- original-point + original-point max-address) + ;; Characters are multibyte in some coding systems. Should encoding + ;; the buffer with buffer-file-coding-system, then set the origianl + ;; point and max address + (setq original-point +(length + (encode-coding-string (buffer-substring (point-min) + (point)) + buffer-file-coding-system))) + (set (make-local-variable 'hexl-max-address) + (1- (length (encode-coding-string (buffer-string) + buffer-file-coding-system (hexlify-buffer) -(restore-buffer-modified-p modified)) - (make-local-variable 'hexl-max-address) - (setq hexl-max-address max-address) + (restore-buffer-modified-p modified) (condition-case nil (hexl-goto-address original-point) (error nil))) On Thu, 23 Nov 2006 00:59:14 +0800, Chong Yidong [EMAIL PROTECTED] wrote: The hexl-max-address usually set to buffer-size, but when the buffer contain a multiple byte character or the file associated to the buffer is encoded by multibyte coding system such as utf-16, the hexl-max-address is usually less the the real byte of buffer. However, the (decode-coding-string (buffer-string) buffer-file-coding-system) method doesn't seem to work for me; it returns erratic incorrect results. Actually, I think the correct thing to do is to ENcode the buffer string, not DEcode it. (length (encode-coding-string (buffer-string) buffer-file-coding-system)) This seems to produce the correct results. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
