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
