Re: infloop in skeleton-insert
Nick Roberts [EMAIL PROTECTED] writes: A character in emacs is represented by a normal integer. Because emacs does have the concept of characters, separate from integers, it's just that they share a concrete representation in lisp. I agree. What's an abnormal integer? (A character in emacs is represented by an integer. ?) The word normal is simply to emphasize the point that they're the same integers which are generally used in lisp (I thought of leaving it out, but I think it sounds beter with it). -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts [EMAIL PROTECTED] writes: `eq' compares immediate values in lisp. All integers in emacs lisp are immediate values. Floating point numbers in Emacs lisp are boxed -- allocated on the heap -- just like cons-cells or whatever. Well a symbol also seems to be a pointer/allocated on the heap, but OK, thanks, that gives me some understanding. Symbols are indeed on the heap, and in fact it's quite possible to have two identically named symbols which aren't eq. However in normal usage symbols are interned when they are read, which makes them eq. -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Jose == Jose A Ortega [EMAIL PROTECTED] writes: Jose In a buffer with scheme-mode active, Jose delete-trailing-whitespace treats a traling vertical bar Jose character (|) as trailing whitespace (that is, the character Jose is deleted when invoking delete-trailing-whitespace, either Jose interactively or as a write hook). Other modes (elisp, Jose lisp, c, fundamental) seem to behave correctly. Jose This behaviour is also present in Emacs 21. Jose (tested using emacs -q, both in emacs 22 and 21) I suspect you're using an older version of quack.el. If so, upgrade to Version 0.29 or better. -- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode: crash in char_string()
In GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2007-04-02 on lamacq.ph.ed.ac.uk
Windowing system distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--enable-font-backend' '--with-xft'
'--prefix=/scratch/s0198183/applications/emacs-unicode''
If called with a negative number as an argument, functions such as
insert, char-to-string, and so forth will cause Emacs 23 to segfault
in char_string().
This may be reproduced as follows:
emacs -Q
M-: (char-to-string -1) RET
The crash occurs in char_string(). This is due to assuming the first
(character) argument is positive. If this is not the case, the code
does
if (c = MAX_3_BYTE_CHAR)
{
bytes = CHAR_STRING (c, p);
}
Since c is negative, this code path is taken and the CHAR_STRING() macro
is called. CHAR_STRING(), however, compares the unsigned value of c,
rather than the signed value:
((unsigned) (c) = MAX_3_BYTE_CHAR
...
: char_string (c, p))
Since the unsigned value of c is bigger than MAX_3_BYTE_CHAR, the
false code path is taken, calling char_string() again. This repeats
until we run out of stack, causing a segfault.
The fix is to check the type of c in char_string() to ensure that it
can represent a valid character:
Index: src/character.c
===
RCS file: /sources/emacs/emacs/src/Attic/character.c,v
retrieving revision 1.1.4.12
diff -c -r1.1.4.12 character.c
*** src/character.c 15 Feb 2007 11:27:15 - 1.1.4.12
--- src/character.c 11 Apr 2007 11:30:41 -
***
*** 105,110
--- 105,112
{
int bytes;
+ CHECK_CHARACTER (make_number (c));
+
if (c CHAR_MODIFIER_MASK)
{
/* As an non-ASCII character can't have modifier bits, we just
ChangeLog entry
2007-04-11 Lawrence Mitchell [EMAIL PROTECTED]
* character.c (char_string): Ensure that `c' is a valid character.
Cheers,
Lawrence
--
Lawrence Mitchell [EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segfault in Emacs 23 when attempting to insert a negative integer (was: Re: infloop in skeleton-insert)
In article [EMAIL PROTECTED], Lawrence Mitchell [EMAIL PROTECTED] writes: M-: (insert -1) RET resulting in a segmentation fault. The problem appears to lie in the code-path to char_string(), the code does not seem to check to see if the character to be inserted is valid: specifically, negative arguments cause the stack to overflow (I think). char_string(c, p) calls CHAR_STRING(c, p), which, since c is negative, calls char_string(c, p) as a fallback. I'm not sure how to go about fixing this, the naive approach of calling CHECK_CHARACTER at the beginning of char_string results in a segfault when building. Thank you for finding this bug. I changed INTEGERP to CHARACTERP in general_insert_function. If called with a negative number as an argument, functions such as insert, char-to-string, and so forth will cause Emacs 23 to segfault in char_string(). I changed CHECK_NUMBER to CHECK_CHARACTER in Fchar_to_string. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Symbols are indeed on the heap, and in fact it's quite possible to have two identically named symbols which aren't eq. However in normal usage symbols are interned when they are read, which makes them eq. A more common (but still not very common either) term for interned is hash-cons'd. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in gc_sweep (SIGH!)
Chong Yidong [EMAIL PROTECTED] writes: It's unlikely that such a bug would have gone undetected over the last few pretests. If it is a sublte bug in the GIF library, it may be been there forever. Could you me help check the last few checkins to the src directory for any obvious bugs? I looked at them when they were committed, and didn't see anything (obviously) wrong with them. And this is a non-GTK build. I've tried many ways / many times to reproduce the crash, but I cannot. However, I have found the reason why I initailly failed to display the GIF image - it's because I have delete-trailing-whitespace on the before-save-hook. Here's a recipe: First the base64 encoded image data: R0lGODlhZwAlAHAAACH5BAgAAP8ALABnACUAhwAASAAAdABISEgAAHQAAHQASHQAdHR0 SAAA/wBInAB0vwB0/0gA/3QA/0hInHRInEic30ic/3S//5xIAL90AJxISJxI/790/9+cSP+/dL+/ /5zf/7///9+c//+fnP//v//f/+zp2PLy8v///wAA AAj+AEcIHEiwoMGDCBMqXMiwIcMSECNKnEixosWLGDNq3KiRhMePJDiKHEmy5EiQH02qXMmSI0qP LWPKjPky5MybOF2+tOghgc+fHEQ0+Jmgw8wMAABEyKkT5cQMAkp4kFACw4QSFziU+MAA4ocEODMs nRmiwNiMNSOCIKBgolWJXCN6MFkhqQILWiGKlaghqVKJFJIOeBAxMIDBhQPkvZi2BAXFFN9GjOu1 ZIUFeiHrPVsixAaIFK6W2FuiQtvRY01LXHvaYk2knCVK9tq18sgQEC6ShrjWr+iySQUY7Vwg+HCJ sF3vdBwb4uyttaWSxK37bAgDeTOI5ts6oobuo8H+T2zsWHPE55RLOLA8tuz23SEOGF0rGi9EDZhL 2C+BXy1btMvx9p9URBklFFHbjWQYAFcB55dwoyUVAAIMOvbgcAtCWJZ5jAXI1IcgkgfiiDiJSOKJ LZmI4oolqciiSn7FCABNHr640owT4ciSizaSpGNEP6rEY48iBVmCkS2+hFSMivVmXElLNncjRUiS 9NpSFVxlX3/8QQillDBSSaNTEGXJV36oYVQXAHcttht/fnFmGGKgCUaYkVWeFKCZ3qHJZUWXZeYm Z56BJhppqqVZWlt4jglSRHze5yeaE1Fn0ZtOVkjck5sCAGGjKe6Z4J9vSmRpRfBhp1eC94n33ZFh YoZKZmmj5hffcRRV0F4B71knXwn0QbQfl8NiBuqOOy3p6XwExMgqRQs2WNyFEQIwYYUZYkjtsSsN SeRG3ApZ47cjhWuSt+RiZG6Ss6ZbroxJOZqSu/RChG69K96L74kBAQA7 This works: 0- emacs -Q 1- C-x C-f x.gif 2- yank image into buffer 3- C-x h 4- M-x base64-decode-region 5- C-c C-c = image is shown 6- C-c C-c = text is shown 7- C-x C-s = save 8- C-c C-c = image is shown Now, repeat the above sequence, but this time, add this between step 0 and 1: M-: (add-hook 'before-save-hook 'delete-trailing-whitespace) RET Everything looks ok, until you get to step 8 -- then the image file has been corrupted. Still, messing around with this in various ways does not crash Emacs no matter how much I try. I suggest we ignore the bug for now. -- 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: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
On Mon, 09 Apr 2007 10:51:42 +0200, martin rudalics wrote: (defcustom whitespace-check-indent-whitespace indent-tabs-mode Flag to check indentation whitespace. This is the global for the system. That fails to do the right thing if the user changes indent-tabs-mode mode after whitespace.el is loaded -- which is certainly not unlikely, especially given that indent-tabs-mode is automatically buffer local, and traditionally set on a per-buffer basis! I have to admit that I wanted the original poster to describe exactly this sequence of events. I set it in custom-set-variables; another likely scenario, I would think. With regard to your request, I'm unfamiliar with -Q and so far I haven't found documentation for it. So, more explicit instructions about what you'd like me to try would be appreciated. In general, using another variable as the initial value in a defvar/defcustom is almost never the right thing for exactly this reason. In particular if the variable comes from another group. The right thing to do with whitespace.el is probably support a special `auto' value for such settings. For instance, in `whitespace-cleanup-internal', instead of just checking the value of `whitespace-check-buffer-indent' (the local version of `whitespace-check-indent-whitespace'), it could do something like: (if (eq whitespace-check-buffer-indent 'auto) indent-tabs-mode whitespace-check-buffer-indent) IMHO there's no reasonable way to reconcile a user's settings of `indent-tabs-mode' with those of `whitespace-check-indent-whitespace'. I think `whitespace-indent-cleanup' should be executed iff `indent-tabs-mode' is non-nil in the current buffer. But I'm afraid that anything we change here will break existing customizations. Why isn't it reasonable for whitespace-indent-cleanup to change tabs in indentation to spaces when indent-tabs-mode is nil? -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: I want to put an overlay at the top of a buffer and display several lines of text there. I use an overlay of length 1 at point 1 with a 'before-string property to do this. Doing this I see some strange display problems when moving point to the beginning of buffer. When (point) is 1 I want the cursor to be displayed after the 'before-string. And as a pessimist I fear that it might be displayed before the 'before-string. However none of these alternatives happen. Instead the cursor is displayed at the end of the first line of the 'before-string. To reproduce the problem eval this code and go to the beginning of the buffer: (defvar temp-ovl nil) (defun temp-toggle-ovl() (interactive) (if temp-ovl (progn (delete-overlay temp-ovl) (setq temp-ovl nil)) (setq temp-ovl (make-overlay 1 1)) (let ((s A string\nwith several rows\nthat should be at top\n) (put-text-property 0 (length s) 'face (list (cons 'background-color yellow)) s) (overlay-put temp-ovl 'before-string s I have attached an image display the cursor at point 1. In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-09 Could I get some feedback on this please? I know now that the problem exists also on GNU/Linux. It looks to me like it could be easy to fix, but I do not know the code involved for displaying the cursor, 'before-string etc. I would really like this bug to be fixed before the release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
edebug-pop-to-buffer fails for dedicated windows
Hello, edebug-pop-to-buffer changes the buffer in the next window. However this results in an error, if that window is dedicated. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Why does etags ask me if I want to keep the old TAGS - I do not want to load a new
Date: Wed, 11 Apr 2007 07:53:27 +0200 From: Matzi Kratzi [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org If I have the *Message*-buffer in another window, I can now see this: k:/ERADIUM_kalle/LD_swmodules_005/TAGS and k:/ERADIUM_kalle/LD_SwModules_005/TAGS are the same file [2 times] Note that these two file names are identical, but for the letter-case. Since Windows filesystems are case-insensitive, these two names indeed specify the same file. The question is: where did Emacs get these two names? Thank you! The problem appears to be the letter-case. I can repeat this by using etags from the pretest on the files in src in the pretest source. If I load process.c, run find-tag and change the spelling of src to Src, I get the same behaviour the second time I use find-tag. Well, if the problem is that you yourself misspell the file's name, then simply don't do that ;-) I find this strange since emacs on MS windows does not care about letter-case in other places. It doesn't care about file names where it calls the Windows filesystem APIs, and in file-name completion. But if some Lisp code uses string comparison as a method to check for files' equality (because Emacs code is deeply rooted in the Posix world), then letter-case differences will cause false negatives. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Why does etags ask me if I want to keep the old TAGS - I do not want to load a new
Date: Wed, 11 Apr 2007 07:53:27 +0200 From: Matzi Kratzi [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org The problem appears to be the letter-case. I can repeat this by using etags from the pretest on the files in src in the pretest source. If I load process.c, run find-tag and change the spelling of src to Src, I get the same behaviour the second time I use find-tag. Please give me a complete self-contained test case, starting from emacs -Q. I'd like to see whether some of these problems can be easily fixed before Emacs 22.1 is released. TIA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. Should Emacs users always turn off use of ClearType? If so, can Emacs do it automatically? If not, is this documented in PROBLEMS or somewhere suitable? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
In a buffer with scheme-mode active, delete-trailing-whitespace treats a traling vertical bar character (|) as trailing whitespace (that is, the character is deleted when invoking delete-trailing-whitespace, either interactively or as a write hook). It seems that this does not happen in the current CVS. Looks like it's been this way for about 2 years. If that is the case, how come Jose gets this bug? His snapshot is surely not 2 years old. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
The iff idiom is sufficiently common that we don't want to shy away from it just at this one place. So either we rule it out everywhere, or we use it liberally. Now that I think about it, I realize that many Emacs users have not studied the advanced mathematics where they would encounter the term iff. So I think it is better to avoid that term. (I was the one who introduced it into Emacs doc strings.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
It seems that this does not happen in the current CVS. Looks like it's been this way for about 2 years. If that is the case, how come Jose gets this bug? His snapshot is surely not 2 years old. Yes, I was about to ask the same thing. But I've checked again, and noticed that with a version compiled on 03.02 the bug does not appear, while it seems to be back in a version compiled on 03.16---but that's on a different machine (a coworker running Emacs on OS X), so that could be something related to the OS or environment. Or maybe there was a regression during some time in mid-March that has been fixed now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Richard Matthew Stallman [EMAIL PROTECTED] writes: The iff idiom is sufficiently common that we don't want to shy away from it just at this one place. So either we rule it out everywhere, or we use it liberally. Now that I think about it, I realize that many Emacs users have not studied the advanced mathematics where they would encounter the term iff. So I think it is better to avoid that term. (I was the one who introduced it into Emacs doc strings.) I have added this to TODO for fixing post-22 release. ** Avoid using iff in doc strings. -- 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: Ugly W32 display bug - fontified letters chopped on right
Richard Matthew Stallman wrote: The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. Should Emacs users always turn off use of ClearType? If so, can Emacs do it automatically? If not, is this documented in PROBLEMS or somewhere suitable? No, unfortunately there are cases where it should be turned on instead. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
On 4/11/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: Should Emacs users always turn off use of ClearType? No. ClearType improves readability, and the problems depend on the font used and perhaps other factors. In my setup, for example, ClearType is quite usable. If so, can Emacs do it automatically? ClearType cannot be deactivated for specific apps, but it can be for specific fonts, so we could fix it in w32_load_system_font. That'd be overkill IMO. If not, is this documented in PROBLEMS or somewhere suitable? The problem and workaround are documented in PROBLEMS. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Richard Matthew Stallman wrote: It seems that this does not happen in the current CVS. Looks like it's been this way for about 2 years. If that is the case, how come Jose gets this bug? His snapshot is surely not 2 years old. I don't know. All I can say is that: emacs -q --no-site-file -f scheme-mode abcd| RET M-x delete-trailing-whitespace does the right thing for me (deletes the spaces, not the |). This is with the current CVS (the | is indeed removed in Emacs 21.3) and the last relevant-looking changes to scheme.el were 2 years ago. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
dnd bug with setting case-fold-search nil
Hi,All:Thanks for your great job:). I'm using NTemacs22 and have found one small bug.If you add the following statement in .emacs file: (setq-default case-fold-search nil)you can't drag and drop some files to emacs (eg: with : in its full path). I have tried to modify the dnd-get-local-file-name function in file dnd.el: %[A-Z0-9][A-Z0-9] ==%[a-zA-Z0-9][a-zA-Z0-9] But it won't work unless you add (load dnd.el) explicitly in your .emacs file. It seems that emacs has internal elisp functions which defined in dnd.el. I have trid to delete dnd.el and dnd.elc files. but the dnd-get-local-file-name is still available after restarting emacs. That's wierd.___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Richard == Richard Matthew Stallman [EMAIL PROTECTED] writes: Richard Should Emacs users always turn off use of ClearType? If Richard so, can Emacs do it automatically? Ugh. ClearType is a pretty nice feature, and it'd be very frustrating if using Emacs caused it to be turned off. Richard If not, is this documented in PROBLEMS or somewhere Richard suitable? It is indeed in PROBLEMS, and I think that's the best way to go; what I saw of the problem was not very annoying, so I don't think there's a need to take drastic measures like turning off ClearType. -- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Eli Zaretskii wrote:
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a grave bug.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
As for whether or not to change the code, I guess it's up to KFS.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: On 4/11/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: Should Emacs users always turn off use of ClearType? No. ClearType improves readability, and the problems depend on the font used and perhaps other factors. In my setup, for example, ClearType is quite usable. If so, can Emacs do it automatically? ClearType cannot be deactivated for specific apps, but it can be for specific fonts, so we could fix it in w32_load_system_font. That'd be overkill IMO. If not, is this documented in PROBLEMS or somewhere suitable? The problem and workaround are documented in PROBLEMS. Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
If that is the case then it is perhaps also easy and not dangerous to
fix it?
As for whether or not to change the code, I guess it's up to KFS.
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. -- 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: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
I set it in custom-set-variables; another likely scenario, I would think. whitespace.el has this form (defcustom whitespace-check-indent-whitespace indent-tabs-mode which, as Miles explained, gets evaluated when whitespace is loaded with the value `indent-tabs-mode' has at that time. Apparently you set `indent-tabs-mode' to a different value afterwards. Hence, the values of `indent-tabs-mode' and `whitespace-check-indent-whitespace' eventually conflict in one of your buffers. I just wanted to know your particular usage pattern in order to propose a solution. With regard to your request, I'm unfamiliar with -Q and so far I haven't found documentation for it. So, more explicit instructions about what you'd like me to try would be appreciated. -Q is an initial option. From the Emacs manual: `-Q' `--quick' Start emacs with minimum customizations. This is like using `-q' and `--no-site-file', but also disables the startup screen. IMHO there's no reasonable way to reconcile a user's settings of `indent-tabs-mode' with those of `whitespace-check-indent-whitespace'. I think `whitespace-indent-cleanup' should be executed iff `indent-tabs-mode' is non-nil in the current buffer. But I'm afraid that anything we change here will break existing customizations. Why isn't it reasonable for whitespace-indent-cleanup to change tabs in indentation to spaces when indent-tabs-mode is nil? It is reasonable. Unfortunately, the decisions of `whitespace-indent-cleanup' are based on the actual value of `whitespace-check-indent-whitespace' and not on that of `indent-tabs-mode'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dnd bug with setting case-fold-search nil
graphist [EMAIL PROTECTED] writes: I'm using NTemacs22 and have found one small bug. If you add the following statement in .emacs file: (setq-default case-fold-search nil) you can't drag and drop some files to emacs (eg: with : in its full path). I haven't been able to reproduce this, but this is probably windows-specific. Please give a more precise recipe. Some files is too vague. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Richard Matthew Stallman wrote: The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. Should Emacs users always turn off use of ClearType? These problems are not apparent with most fonts. I can only see them with some fonts if I reduce the size to 9 point, but it probably depends on screen resolution. If so, can Emacs do it automatically? Yes, this was my solution to Cleartype problems some time ago, but it was an unpopular one. We could add a user option. If not, is this documented in PROBLEMS or somewhere suitable? Eli just added it back, it had been previously removed because someone submitted some patches that was supposed to fix the problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: KDE background colors
(I accidentally replied only to the poster, not the list, sorry.) On Wed, 11 Apr 2007 16:10:57 +0300 Shraga Bor-Sood [EMAIL PROTECTED] wrote: This is Emacs23 CVS checkout on Wed Apr 11 12:37:53 UTC 2007 of the emacs-unicode-2 branch. The system is OpenSUSE 10.0 x86_64 KDE 3.4.2 When running emacs emacs -Q --enable-font-backend --font Courier new:pixelsize=14 the background of the text is different than the background of the rest of the window as can be seen in the attached image. I have experienced this problem with the GTK build of Emacs 22 in KDE on SUSE while using the gtk-qt-engine. If you're using that, try updating it or compiling it from the source; that helped me. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: ClearType cannot be deactivated for specific apps Yes it can. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
On 4/12/07, Jason Rumney [EMAIL PROTECTED] wrote: Yes it can. Cool. How? (I searched Microsoft's docs, but they are less than clear sometimes and I didn't find anything which seemed to imply app-specific settings of ClearType...) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: On 4/12/07, Jason Rumney [EMAIL PROTECTED] wrote: Yes it can. Cool. How? (I searched Microsoft's docs, but they are less than clear sometimes and I didn't find anything which seemed to imply app-specific settings of ClearType...) You can specify the antialiasing you want when you load fonts, using the lfQuality element of the LOGFONT struct. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: Kim F. Storm wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. I looked a bit at the code. (First time I used tags, quite nice.) Is it in set_point_both in intervals.c that the magic happens? It looks from that code like internally an intangible property is used in cases like this. I therefore compared using 'before-string with using (put-text-property 1 (point) 'intangible t) The cursor moves quite differently in those cases. Is there an intangible property missing internally on line endings in 'before-string? (A wild guess of course, but the best I can do at the moment.) BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dnd bug with setting case-fold-search nil
graphist wrote: I'm using NTemacs22 and have found one small bug. If you add the following statement in .emacs file: (setq-default case-fold-search nil) you can't drag and drop some files to emacs (eg: with : in its full path). I have tried to modify the dnd-get-local-file-name function in file dnd.el: %[A-Z0-9][A-Z0-9] ==%[a-zA-Z0-9][a-zA-Z0-9] I changed that regexp to %[A-Fa-f0-9][A-Fa-f0-9], since there is no point in trying to decode G-Z as hex characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: I looked a bit at the code. (First time I used tags, quite nice.) Is it in set_point_both in intervals.c that the magic happens? It looks from that code like internally an intangible property is used in cases like this. And that was totally wrong of course. That is not the display code. Looking at the code Chong mentioned instead. BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
As for whether or not to change the code, I guess it's up to KFS.
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
Index: xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 12 Apr 2007 00:40:36 -
***
*** 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT MATRIX_ROW_START_CHARPOS (++row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Date: Wed, 11 Apr 2007 22:48:34 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Chong Yidong [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] FWIW, I wouldn't touch this so close to the release: if no one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Date: Wed, 11 Apr 2007 22:53:18 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, Kim F. Storm [EMAIL PROTECTED] Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? What problems are those? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:53:18 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Kim F. Storm [EMAIL PROTECTED] Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? What problems are those? I mean those specific cases that has been discussed here lately. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
