Re: Coding system of compressed PO files is not recognized
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes: > I have forgotten about this issue. Could you ask me again whatever > question you are waiting for me to answer? Actually, in the last mail, I answered to your question as this: -- In article <[EMAIL PROTECTED]>, "Richard M. Stallman" <[EMAIL PROTECTED]> writes: >> Could you give me an example or two? >> Which filename handler function does this? >> Looking at an example, I can understand the issue. > We are failing to communicate. Your patch is a change in > po-find-charset. po-find-charset is not a filename handler function. The patch contains also a change in po-find-file-coding-system-guts which is called from po-find-file-coding-system. And po-find-file-coding-system is a function registered in file-coding-system-alist and thus is called from find-operation-coding-system. I thought you meant such a function by "filename handler function" in the current context. --- Kenichi Handa [EMAIL PROTECTED] -- I attach the whole patch I proposed. We had been discussing about this topic by the subject: "po file charset via auto-coding-functions". Please check mails on that subject. Here's a brief summary. For PO file, the function po-find-file-coding-system is registered in file-coding-system-alist, and that function checks the file contents to decide a coding system. But, if a PO file is in an archive file, tar-mode and arc-mode call find-operation-coding-system with a filename that doesn't exist in the system, so po-find-file-coding-system fails. To solve it, I modified, tar-mode, arc-mode, and po.el as the attached patch. In short, I changed tar-mode and arc-mode to call find-operation-coding-system with buffer-file-name instead of the actual filename, and change po.el to visit a buffer by (get-file-buffer filename). But, if a PO file is compressed, we still have a problem because jka-compr also calls find-operation-coding-system (via decode-coding-inserted-region) with non-existing filename. For instance, if we are visiting temp.po.gz, find-operation-coding-system is called with "temp.po", and at that time, buffer-file-name is "temp.po.gz". So, po-find-file-coding-system can't check the contents. To solve it, I modified jka-compr as the attached patch. It binds buffer-file-name temporarily to "temp.po.gz!temp.po" and calls find-operation-coding-system (via decode-coding-inserted-region) with buffer-file-name as filename. Thus po-find-file-coding-system can visit it by get-file-buffer. It seems that this local binding of buffer-file-name is a little bit fishy part, but I can't think of any other way to fix the current problem without a drastic change in the current mechanism of find-operation-coding-system. While discussing with this problem, another discussion about making a file-name-handler for tared or archived file (e.g. for "temp.tar!temp.po" or "temp.zip:temp.po") was raised, and it seems that you got confused. --- Kenichi Handa [EMAIL PROTECTED] Index: lisp/arc-mode.el === RCS file: /cvsroot/emacs/emacs/lisp/arc-mode.el,v retrieving revision 1.72 diff -c -r1.72 arc-mode.el *** lisp/arc-mode.el8 Mar 2006 01:57:59 - 1.72 --- lisp/arc-mode.el25 Apr 2006 06:42:40 - *** *** 873,879 (let ((file-name-handler-alist '(("" . archive-file-name-handler (car (find-operation-coding-system 'insert-file-contents ! filename t)) (if (and (not coding-system-for-read) (not enable-multibyte-characters)) (setq coding --- 873,879 (let ((file-name-handler-alist '(("" . archive-file-name-handler (car (find-operation-coding-system 'insert-file-contents ! buffer-file-name t)) (if (and (not coding-system-for-read) (not enable-multibyte-characters)) (setq coding Index: lisp/tar-mode.el === RCS file: /cvsroot/emacs/emacs/lisp/tar-mode.el,v retrieving revision 1.105 diff -c -r1.105 tar-mode.el *** lisp/tar-mode.el6 Feb 2006 14:33:35 - 1.105 --- lisp/tar-mode.el25 Apr 2006 06:42:41 - *** *** 736,742 (funcall set-auto-coding-function name (- (point-max) (point) (car (find-operation-coding-system ! 'insert-file-contents name t (multibyte enable-multibyte-characters) (detected (detect-coding-region
Re: Mode-line display bug in XFT_JHD_BRANCH
> On Mon, 17 Apr 2006 13:09:16 +0530, Baishampayan Ghose <[EMAIL > PROTECTED]> said: > Hello, I am using the Emacs XFT_JHD_BRANCH and there is a weird > mode-line display bug in it. When the file has variable width fonts > like in LaTeX mode, the mode-line becomes garbled on scrolling. A > screen shot [0] is attached. I guess now that the XFT & Unicode > branches have been merged, this critical bug will be fixed. I can > help with testing the branch by doing daily builds, if it's being > developed actively. Miles, what do you think about this? Regards, > BG > [0] http://people.ubuntu-in.org/~ghoseb/emacs_xft_mode-line_bug.png I tried to make a small patch for some problems that don't require too many changes to fix (or workaround). This is for XFT_JHD_BRANCH, not for unicode-xft. I don't have a plan to work for Xft support, but I simply ported some results from my previous ATSUI support on Mac to Xft. YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xfaces.c === RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v retrieving revision 1.316.2.4 diff -c -r1.316.2.4 xfaces.c *** src/xfaces.c12 Jan 2006 10:25:47 - 1.316.2.4 --- src/xfaces.c25 Apr 2006 07:37:07 - *** *** 5282,5288 XQueryColors (FRAME_X_DISPLAY (f), FRAME_X_DISPLAY_INFO (f)->cmap, colors, 2); ! face->xft_fg.color.alpha = face->xft_fg.color.alpha = 0x; face->xft_fg.color.red = colors[0].red; face->xft_fg.color.green = colors[0].green; face->xft_fg.color.blue = colors[0].blue; --- 5282,5288 XQueryColors (FRAME_X_DISPLAY (f), FRAME_X_DISPLAY_INFO (f)->cmap, colors, 2); ! face->xft_fg.color.alpha = face->xft_bg.color.alpha = 0x; face->xft_fg.color.red = colors[0].red; face->xft_fg.color.green = colors[0].green; face->xft_fg.color.blue = colors[0].blue; *** *** 7243,7248 --- 7243,7251 { bcopy (base_face, face, sizeof *face); face->gc = 0; + #ifdef HAVE_XFT + face->xft_draw = NULL; + #endif /* Don't try to free the colors copied bitwise from BASE_FACE. */ face->colors_copied_bitwise_p = 1; Index: src/xterm.c === RCS file: /cvsroot/emacs/emacs/src/xterm.c,v retrieving revision 1.861.2.4 diff -c -r1.861.2.4 xterm.c *** src/xterm.c 12 Jan 2006 10:25:47 - 1.861.2.4 --- src/xterm.c 25 Apr 2006 07:37:08 - *** *** 1202,1210 x_set_glyph_string_clipping (s) struct glyph_string *s; { ! XRectangle r; ! get_glyph_string_clip_rect (s, &r); ! XSetClipRectangles (s->display, s->gc, 0, 0, &r, 1, Unsorted); } --- 1202,1216 x_set_glyph_string_clipping (s) struct glyph_string *s; { ! #define MAX_CLIP_RECTS 2 ! XRectangle r[MAX_CLIP_RECTS]; ! int n; ! ! n = get_glyph_string_clip_rects (s, r, MAX_CLIP_RECTS); ! XSetClipRectangles (s->display, s->gc, 0, 0, r, n, Unsorted); ! #ifdef HAVE_XFT ! XftDrawSetClipRectangles (s->face->xft_draw, 0, 0, r, n); ! #endif } *** *** 1382,1392 strlen (weight_name) + strlen (slant_name) + 5 + /* pixel */ ! 9 + /* stars */ 14 + /* dashes */ 1); /* null */ xlfd = malloc (len); ! sprintf(xlfd, "-%s-%s-%s-%s-*-*-%d-*-*-*-*-0-*-*", foundry, family, weight_name, slant_name, (int) (pixel + 0.5)); return xlfd; --- 1388,1398 strlen (weight_name) + strlen (slant_name) + 5 + /* pixel */ ! 6 + 1 + 8 + 1 + /* stars, "0", "iso10646", "1" */ 14 + /* dashes */ 1); /* null */ xlfd = malloc (len); ! sprintf(xlfd, "-%s-%s-%s-%s-*-*-%d-*-*-*-*-0-iso10646-1", foundry, family, weight_name, slant_name, (int) (pixel + 0.5)); return xlfd; *** *** 1551,1589 use XDrawImageString when drawing the cursor so that there is no chance that characters under a box cursor are invisible. */ #ifdef HAVE_XFT ! /* KOKO: Always clear background for now, there are some redraw problems ! otherwise. */ ! if (1 || ! (s->for_overlaps ! || (s->background_filled_p && s->hl != DRAW_CURSOR))) ! XftDrawRect (s->face->xft_draw, ! s->hl == DRAW_CURSOR ? &s->face->xft_fg : &s->face->xft_bg, ! s->x, ! s->y, ! s->width + s->right_overhang, ! s->height); ! if (s->tw
Re: read-abbrev-file (2)
Richard Stallman wrote: > > I cannot reproduce the problem. It only occurs at the very beginning, after starting Emacs. > > Maybe it has been fixed since February. > > Does it fail in the latest sources? Yes, noticed the change. > > If so, can you try to debug it by running under GDB and putting > > a breakpoint at Fsignal? > > Will try that, but it would take some time. I'm not familiar with. __ Andreas Roehler What about to use this until then?: ;(defalias 'read-abbrev-file 'ar-read-abbrev-file) ;(defalias 'quietly-read-abbrev-file 'ar-quietly-read-abbrev-file) (defun ar-read-abbrev-file (&optional file) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'" (interactive (list (read-from-minibuffer (concat "default: " abbrev-file-name ": " (if (or (string-match "[ \t]+" file) (string= "" file)) (setq file abbrev-file-name)) (load file nil) (setq abbrevs-changed nil)) (defun ar-quietly-read-abbrev-file (&optional file) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'. Does not display any message." (interactive) (let ((file file)) (unless (stringp file) (setq file abbrev-file-name)) (load file nil t) (setq abbrevs-changed nil))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding system of compressed PO files is not recognized
> I have forgotten about this issue. Could you ask me again whatever > question you are waiting for me to answer? Actually, in the last mail, I answered to your question as this: Now I am completely confused. Where does this issue stand? Have you resolved it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding system of compressed PO files is not recognized
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes: >> I have forgotten about this issue. Could you ask me again whatever >> question you are waiting for me to answer? > Actually, in the last mail, I answered to your question as this: > Now I am completely confused. > Where does this issue stand? Have you resolved it? I don't understand what exactly you are asking. Could you please paraphrase it? At least, the current problem is solved if my patch is accepted. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-abbrev-file (2)
What about to use this until then?: ;(defalias 'read-abbrev-file 'ar-read-abbrev-file) ;(defalias 'quietly-read-abbrev-file 'ar-quietly-read-abbrev-file) (defun ar-read-abbrev-file (&optional file) I do not understand. Who are you suggesting this to? What purpose is this code meant to serve? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug