Re: Strange display behavior after filling
> On Tue, 18 Apr 2006 13:57:46 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > Please test if this gives good results, or if it has some bad > effects on existing features I tried the patch, and I found another case that shows a similar problem: 1. emacs -D -q (not -Q to show the message in *scratch*) 2. M-q 3. M-< C-e C-d C-e C-d Then the message ";; This buffer ... own buffer." is shown in one line. 4. M-< C-u 1 C-v 5. M-q 6. C-p C-n C-n The examples I've shown may look artificial, but I sometimes experience some redisplay glitches such as violation of the assertion "IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))" in set_iterator_to_next, or partial octal representation of a multibyte character after fill operations. (The buffer contents seems to be correct because C-l fixes redisplay in these cases.) So I was trying to find reliably reproducible cases. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Rmail failure
rmail fails to get new mail, with the following error: rmail-get-new-mail: Wrong type argument: char-or-string-p, nil In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit) of 2006-04-17 on pacem, modified by Debian X server distributor `The X.Org Foundation', version 11.0.6090 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'CFLAGS=-DDEBIAN -g -O2 -Wno-pointer-sign' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'' 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: en_IE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: tooltip-mode: t auto-compression-mode: t tool-bar-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 line-number-mode: t Recent input: x s h e l l d i r SPC / v a r / m a i l / b r x r m y q C-x k x r m y x e m a c s SPC b u u r e p o r t SPC t e m SPC Recent messages: File RMAIL is large (38MB), really open? (y or n) Counting messages...done Getting mail from /var/mail/brendan... rmail-get-new-mail: Wrong type argument: char-or-string-p, nil call-interactively: Text is read-only Making completion list... Loading help-mode...done Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: latest rfc2231-parse-string broken in multiple ways
Joe Wells <[EMAIL PROTECTED]> writes:
> Bug #1: The invocation
>
> (mail-header-parse-content-type "message/external-body;
>name*1*=plugh%2fhello-sailor%2fbing.pdf;
>name*0*=us-ascii''~%2ffoo%2fbar%2fbaz%2fxyzzy%2f;
>access-type=LOCAL-FILE")
>
> raises an error with this message:
>
> Invalid coding system: plugh%2fhello-sailor%2fbing\.pdfus-ascii
This has already been fixed.
> Bug #2: The invocation
>
> (mail-header-parse-content-type "message/external-body;
>name*0*=us-ascii''~%2ffoo%2fbar%2fbaz%2fxyzzy%2f;
>access-type=LOCAL-FILE;
>name*1*=plugh%2fhello-sailor%2fbing.pdf")
>
> returns this result:
>
> ("message/external-body"
>(name . "~/foo/bar/baz/xyzzy/")
>(access-type . "LOCAL-FILE")
>(name . "plugh/hello-sailor/bing.pdf"))
I've now fixed this in the development version of Gnus, but I don't
think it's a serious enough problem as to warrant fixing in Gnus
5.10. (That is, these types of encodings are rarely seen in the
wild.)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
Thanks for fixing this. I think your fix is sufficient. ___ 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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> I found some strange display behavior after filling. In the
> following, "row" means a displayed horizontal segment, and "line"
> means a sequence of characters delimited by newlines.
>
> 1. emacs -D -Q
> 2. M-q (I'm not sure why this is needed.)
> 3. Insert "123456789 " (without quotations or newlines) 18 times.
> Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e.
> It is displayed in three rows.
> 4. M-<
> 5. C-u 1 C-v
>
> Now the first row becomes continued to both directions.
>
> 6. M-q
>
> Then the first row is displayed shorter than the second one, whereas
> they have the same number of characters.
>
> 7. C-p C-n C-n
>
> The line number in the mode line says the cursor is at the third line.
> But it is displayed at the second row that corresponds to the second
> line.
The problem starts when the C-u 1 C-v scrolling command moves window
start to a position which happens to be in the middle of a
continuation line.
Now, when the filling command has reformatted the buffer text, the
redisplay code still starts window display at the old window start --
which still is in the middle of a line, but not at the same relative
position in the line as before ... so it gets confused.
This is just one way in which a buffer change can mess things up when
window start is not at the start of a line, so I think it is generally
a bit difficult to find a method which will always select the
intuitively best window start after such a change.
On the other hand, I guess this is not something which happens very
often, so a simpler method is probably ok. Below is a change which
simply will just recenter the display in this case.
Please test if this gives good results, or if it has some bad effects
on existing features
2006-04-18 Kim F. Storm <[EMAIL PROTECTED]>
* xdisp.c (try_window_id): If first window line is a continuation line,
and the first change is before window start, return -1 to select a new
window start.
*** xdisp.c 16 Apr 2006 23:05:20 +0200 1.1086
--- xdisp.c 18 Apr 2006 13:53:04 +0200
***
*** 14263,14269
but why that was tested escapes me at the moment. */
if (CHARPOS (start) >= first_changed_charpos
&& CHARPOS (start) <= last_changed_charpos)
! GIVE_UP (15);
/* Check that window start agrees with the start of the first glyph
row in its current matrix. Check this after we know the window
--- 14263,14278
but why that was tested escapes me at the moment. */
if (CHARPOS (start) >= first_changed_charpos
&& CHARPOS (start) <= last_changed_charpos)
! {
! /* If first window line is a continuation line, and the first
!change is before window start, return -1 to select a new
!window start.*/
! if (NILP (w->start_at_line_beg)
! && CHARPOS (start) > first_changed_charpos)
! return -1;
!
! GIVE_UP (15);
! }
/* Check that window start agrees with the start of the first glyph
row in its current matrix. Check this after we know the window
--
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: what is the status of the XFT branch?
In article <[EMAIL PROTECTED]>, "Jan D." <[EMAIL PROTECTED]> writes: > Kenichi Handa wrote: >> >> Actually, after reading codes of XFT branch, I started to >> design a new font handling mechanism. The basic plan is to >> use multiple font-backends drivers (xcore, xft, windows, >> bdf, atm, etc). The main motivation for this rewriting is >> that the current XFT code in the branch is very difficult to >> utilize fontconfig's help for font selection, and to drive >> OTF fonts. And also, I want to clean up the current fairly >> complicated font related codes (including many HAVE_XFT >> conditionals, many XLFD parsing code, etc). > This is a good idea, currently Emacs have too much XLFD knowledge builtin > (i.e. in face specifications) which makes the XFT code more complicated. Yes. And, I think this can be the first step toward the integeration of *term.c. >> But, as there are many other works to be done, the progress >> for the above code is slow. Please don't expect a quick >> response on this matter. Anyway, here's the current font.h >> file (not yet fully considered) with which you may get a >> feeling of the design. >> > At first glance it looks good. I guess the details will > work themselves out when this is applied to various font > mechanisms. I imagine some things that are available for > some font drivers are not available for others. Yes, perhaps. I have no knowlege about Windows font and ATM font. > Maybe there is a bit of speed overhead also, as current > Emacs accesses the X font struct directly. But I guess it > wont be noticable. I guess so too. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
