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
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: 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
> > > It might still be logically true but generally it's best to say exactly > > > what > > > things are i.e "is a non-negative integer.", if this change is made. If > > > it's > > > not made then maybe the manual should be changed to be more precise: > > > > > > A "character" in Emacs Lisp is just an integer. > > > I think it would be more clear to say something like: > > >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. ?) -- 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: Why does etags ask me if I want to keep the old TAGS - I do not want to load a new
> 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. I find this strange since emacs on MS windows does not care about letter-case in other places. This is however easily worked around once you know the cause. /Mats /M ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> `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. -- 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: 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. > Sufficiently common in Emacs (~ 600 instances); I've never seen it > anywhere else as far as I remember. AFAIK it's pretty standard in math and logic. In French we similarly use "ssi" for "si et seulement si". Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
In article <[EMAIL PROTECTED]>, Miles Bader <[EMAIL PROTECTED]> writes: > Nick Roberts <[EMAIL PROTECTED]> writes: > > It might still be logically true but generally it's best to say exactly what > > things are i.e "is a non-negative integer.", if this change is made. If > > it's > > not made then maybe the manual should be changed to be more precise: > > > > A "character" in Emacs Lisp is just an integer. > I think it would be more clear to say something like: >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. --- Kenichi Handa [EMAIL PROTECTED] ___ 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 A. Ortega" wrote: > 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. ___ 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: > Yes. I still don't get it. `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. So if you do (let ((v1 5) (v2 5) (v3 5.0) (v4 5.0)) ...), v1's and v2's immediate values are the integer "5", so (eq v1 v2) will return t, but v4's and v5's immediate values are _pointers_ to heap locations containing 5.0. v3 and v4 may point to the same location in the heap or different locations (in this case probably different locations, but I don't know of any guarantee); (eq v3 v4) can return t or nil depending on which is the case. -Miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
> On Tue, 10 Apr 2007 10:36:08 -0400, Stefan Monnier <[EMAIL PROTECTED]>
> said:
>> + /* At this moment, we still don't know how to decode the directory
>> + name. So, we keep the bytes in multibyte form so that
>> + ENCODE_FILE correctly gets the original bytes. */
>> Vdata_directory
>> ! = Ffile_name_as_directory (string_to_multibyte
>> ! (make_unibyte_string (data_dir,
>> ! strlen (data_dir;
>> Vdoc_directory
>> ! = Ffile_name_as_directory (string_to_multibyte
>> ! (make_unibyte_string (doc_dir,
>> ! strlen (doc_dir;
> Why not just keep it in unibyte form?
Because the current ENCODE_FILE seems to assume that file name strings
are in multibyte or ASCII-only unibyte. Also, the initialization of
current_buffer->directory in init_buffer (buffer.c) does the same
thing.
If we allow non-ASCII unibyte strings for file names, maybe we need to
change ENCODE_FILE and Fexpand_file_name as below, and rule out the
use of concat in favor of expand-file-name to avoid implicit
string-make-multibyte for non-ASCII bytes.
By the way, I noticed that current_buffer->directory mentioned above
is decoded with local-coding-system in command-line (startup.el) after
coding systems are ready. Why not (default-)file-name-coding-system?
;; Decode all default-directory.
(if (and default-enable-multibyte-characters locale-coding-system)
(save-excursion
(dolist (elt (buffer-list))
(set-buffer elt)
(if default-directory
(setq default-directory
(decode-coding-string default-directory
locale-coding-system t
(setq command-line-default-directory
(decode-coding-string command-line-default-directory
locale-coding-system t
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/buffer.c
===
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.525
diff -c -p -r1.525 buffer.c
*** src/buffer.c29 Mar 2007 15:58:34 - 1.525
--- src/buffer.c11 Apr 2007 00:54:42 -
*** init_buffer ()
*** 5211,5222
#endif /* not VMS */
current_buffer->directory = make_unibyte_string (pwd, strlen (pwd));
- if (! NILP (buffer_defaults.enable_multibyte_characters))
- /* At this moment, we still don't know how to decode the
-directory name. So, we keep the bytes in multibyte form so
-that ENCODE_FILE correctly gets the original bytes. */
- current_buffer->directory
- = string_to_multibyte (current_buffer->directory);
/* Add /: to the front of the name
if it would otherwise be treated as magic. */
--- 5211,5216
Index: src/callproc.c
===
RCS file: /cvsroot/emacs/emacs/src/callproc.c,v
retrieving revision 1.221
diff -c -p -r1.221 callproc.c
*** src/callproc.c 17 Feb 2007 01:59:00 - 1.221
--- src/callproc.c 11 Apr 2007 00:54:42 -
*** init_callproc_1 ()
*** 1522,1533
char *data_dir = egetenv ("EMACSDATA");
char *doc_dir = egetenv ("EMACSDOC");
Vdata_directory
! = Ffile_name_as_directory (build_string (data_dir ? data_dir
!: PATH_DATA));
Vdoc_directory
! = Ffile_name_as_directory (build_string (doc_dir ? doc_dir
!: PATH_DOC));
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
--- 1522,1536
char *data_dir = egetenv ("EMACSDATA");
char *doc_dir = egetenv ("EMACSDOC");
+ if (!data_dir) data_dir = PATH_DATA;
+ if (!doc_dir) doc_dir = PATH_DOC;
+
Vdata_directory
! = Ffile_name_as_directory (make_unibyte_string (data_dir,
! strlen (data_dir)));
Vdoc_directory
! = Ffile_name_as_directory (make_unibyte_string (doc_dir,
! strlen (doc_dir)));
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
Index: src/coding.h
===
RCS file: /cvsroot/emacs/emacs/src/coding.h,v
retrieving revision 1.83
diff -c -p -r1.83 coding.h
*** src/coding.h21 Jan 2007 20:49:26 - 1.83
--- src/coding.h11 Apr 2007 00:54:42 -
*** struct coding_system
*** 580,592
/* Encode the file name NAME using the specified coding system
for file names, if any. */
#define ENCODE_FILE(name)
Re: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > It might still be logically true but generally it's best to say exactly what > things are i.e "is a non-negative integer.", if this change is made. If it's > not made then maybe the manual should be changed to be more precise: > > A "character" in Emacs Lisp is just an integer. I think it would be more clear to say something like: 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. -Miles -- Suburbia: where they tear out the trees and then name streets after them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > The manual says: > > > >A "character" in Emacs Lisp is nothing more than an integer. > > > > That would have to change. > > > Not really, since that statement does not imply that the reverse is true. It might still be logically true but generally it's best to say exactly what things are i.e "is a non-negative integer.", if this change is made. If it's not made then maybe the manual should be changed to be more precise: A "character" in Emacs Lisp is just an integer. -- 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: Ugly W32 display bug - fontified letters chopped on right
[EMAIL PROTECTED] (Kim F. Storm) writes: > I had to edit a simple html file on Windows XP, so I got the latest > unpatched Emacs 22 pretest from Lennart's site (thank you). > > If I put this in the file xx.htm: > > > TD class > The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. -- 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: miss spell in `accept-process-output' doc string
Glenn Morris wrote: Stefan Monnier wrote: 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. Sufficiently common in Emacs (~ 600 instances); I've never seen it anywhere else as far as I remember. All it does is save some typing at the expense of confusing people from time to time. Personally, I think it should not be used. I believe it is understandable to people used to math and logics, but the very bad thing about it is that in the context of more normal English text (like a doc string) it may very well be taken for a misspelling of "if". ___ 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
Stefan Monnier wrote: > 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. Sufficiently common in Emacs (~ 600 instances); I've never seen it anywhere else as far as I remember. All it does is save some typing at the expense of confusing people from time to time. Personally, I think it should not be used. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Display problems with 'before-string in overlay
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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
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). Other modes (elisp, lisp, c, fundamental) seem to behave correctly. This behaviour is also present in Emacs 21. (tested using emacs -q, both in emacs 22 and 21) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > I also find this confusing: > > > > (eq 1 1) > > t > > > > (eq 1.0 1.0) > > nil > > (eql 1.0 1.0) > t Yes. I still don't get it. -- 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: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > I also find this confusing: > > (eq 1 1) > t > > (eq 1.0 1.0) > nil (eql 1.0 1.0) t -- 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: Regression in WoMan
Sven Joachim <[EMAIL PROTECTED]> writes: > It seems that WoMan can no longer handle the case where a manpage > loads another one with a .so request. At least I got the error > > WoMan can only format man pages written with the usual `-man' macros > > when trying to view the manpage for dpkg-buildpackage, which consists > of a single line: > > .so man1/dpkg-source.1 > > Emacs 21.4 handles this well, and I'm sure that it worked in CVS at > least until a few months ago, too. This was a consequence of the recently-added checked for macro sets that woman can't handle. The case of a single .so line was overlooked. I've checked in a fix, thanks. ___ 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: Tue, 10 Apr 2007 08:07:02 +0200 > From: "Matzi Kratzi" <[EMAIL PROTECTED]> > > I work on a software project with the source files in quite some > directories. I create my TAGS table in > k:/ERADIUM_kalle/LD_swmodules_005 and work in another. The first time > I use "M-.", I am asked for the tags table to use. After responding to > this I am taken to the definition. > > If I then use "M-." to get to another definition, I am asked "Keep > current list of tags tables also?". Thank you for your report. > 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? > Confessions: > Since I haven't been able to find a way to produce TAGS-tables on > windows 2000 recursively, I use "ctags -e" with ctags from > "http://ctags.sourceforge.net/";. This is not the Emacs etags program, so we probably have no idea what it can do. Why not use etags.exe that comes with Emacs? it works flawlessly for me on Windows as well as on GNU/Linux, and I have yet to see such problems. > k: is where my clearcase mounts are located. Does that mean that drive k: is the so-called ClearCase ``dynamic view''? If so, it could be that the virtual filesystem created by ClearCase to mount its dynamic view somehow works differently than native Windows filesystems, and dupes Emacs into thinking that TAGS table was modified or moved/renamed. Do you see such problems with etags and in local filesystems (i.e. your hard disk)? If not, there's probably little we can do for you, since the problem seems to involve 2 pieces of non-trivial software that are not related to Emacs: ctags and ClearCase. Unless, of course, you debug this problem yourself and report here your findings that will indicate some bug in Emacs. ___ 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: Tue, 10 Apr 2007 08:07:02 +0200 > From: "Matzi Kratzi" <[EMAIL PROTECTED]> > > I work on a software project with the source files in quite some > directories. I create my TAGS table in > k:/ERADIUM_kalle/LD_swmodules_005 and work in another. The first time > I use "M-.", I am asked for the tags table to use. After responding to > this I am taken to the definition. > > If I then use "M-." to get to another definition, I am asked "Keep > current list of tags tables also?". Thank you for your report. > 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? > Confessions: > Since I haven't been able to find a way to produce TAGS-tables on > windows 2000 recursively, I use "ctags -e" with ctags from > "http://ctags.sourceforge.net/";. This is not the Emacs etags program, so we probably have no idea what it can do. Why not use etags.exe that comes with Emacs? it works flawlessly for me on Windows as well as on GNU/Linux, and I have yet to see such problems. > k: is where my clearcase mounts are located. Does that mean that drive k: is the so-called ClearCase ``dynamic view''? If so, it could be that the virtual filesystem created by ClearCase to mount its dynamic view somehow works differently than native Windows filesystems, and dupes Emacs into thinking that TAGS table was modified or moved/renamed. Do you see such problems with etags and in local filesystems (i.e. your hard disk)? If not, there's probably little we can do for you, since the problem seems to involve 2 pieces of non-trivial software that are not related to Emacs: ctags and ClearCase. Unless, of course, you debug this problem yourself and report here your findings that will indicate some bug in Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On 10 Apr 2007, at 03:59, YAMAMOTO Mitsuharu wrote: I think he is using Carbon Emacs with "self-contained" setting which puts subdirectories for runtime (lisp, etc, libexec, ...) below the Emacs.app directory so as to make the application bundle relocatable. Yes, that's correct. That requires some changes here and there. Though I just tried that, it may not be exhaustive and I'm not sure if it is safe to use ENCODE_FILE in init_callproc. Also, this kind of changes may not be appropriate at this stage. I tried your patch and unfortunately, it does not fix the startup problem. Error messages are the same. The good news is that I can start up an Emacs with -Q and -nw (as before, complaining about encoded-kb), but then, `load-file' works with a file that resides inside the offending path, which it didn't before. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
On 2007-04-10, Nick Roberts said: > > This bug is due to skeleton-internal-1 relying on > > char-or-string-p to return non-nil if its argument is an integer, > > while in fact, char-or-string-p returns nil if its argument is a > > negative integer. > > It doesn't on Emacs 22: > > (char-or-string-p -4) > t > > and if it does on Emacs 23 then I think that must be the bug. In Emacs 23: (char-or-string-p -4) => nil Regards, -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in redisplay_internal -> note_mode_line_or_margin_highlight
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chong Yidong <[EMAIL PROTECTED]> writes: > >> Kim, could you study this patch and tell me what you think? > > Looks alright to me. I've checked it in. ___ 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
> "iff" stands for "if and only if" but maybe > "Return non-nil if and only if we received output before the timeout expired." > would be more comprehensible. 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. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> Emacs 23 surely returns nil in that case. I think the > behaviour of Emacs 22 is a bug (or at least very confusing). I don't think it's that important and both sides have fierce proponents (just like the ()-vs-#t in the Lisp/Scheme community, and probably comparable to the little/big-endian silliness). So either way is fine, and I'd rather let the choice be based on implementation simplicity or some other such arbitrary method. This said, negative numbers are not the only problems: not all positive intergers are chars either. So the question is whether char-or-string-p should use `integerp' or `natnump' or `char-valid-p' and I think only the first and last of those three makes good sense. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
> + /* At this moment, we still don't know how to decode the directory > + name. So, we keep the bytes in multibyte form so that > + ENCODE_FILE correctly gets the original bytes. */ > Vdata_directory > ! = Ffile_name_as_directory (string_to_multibyte > !(make_unibyte_string (data_dir, > ! strlen (data_dir; > Vdoc_directory > ! = Ffile_name_as_directory (string_to_multibyte > !(make_unibyte_string (doc_dir, > ! strlen (doc_dir; Why not just keep it in unibyte form? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Regression in WoMan
It seems that WoMan can no longer handle the case where a manpage loads another one with a .so request. At least I got the error WoMan can only format man pages written with the usual `-man' macros when trying to view the manpage for dpkg-buildpackage, which consists of a single line: .so man1/dpkg-source.1 Emacs 21.4 handles this well, and I'm sure that it worked in CVS at least until a few months ago, too. In GNU Emacs 22.0.97.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-04-10 on debian Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C 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: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: display-time-mode: t auto-image-file-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: d p k g - b u M-x r e p o r Recent messages: For information about the GNU Project and its goals, type C-h C-p. Loading woman... Loading easymenu...done Loading woman...done Loading /home/sven/elisp/.woman-cache.el (source)...done Loading jka-compr...done uncompressing dpkg-buildpackage.1.gz...done woman-decode-buffer: WoMan can only format man pages written with the usual `-man' macros Making completion list... Loading emacsbug...done ___ 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
Thanks for suggestion. > [Tue, 10 Apr 2007 15:21:12 +0200] > martin rudalics <[EMAIL PROTECTED]> writes: > > Current CVS head. > > > > The last line of `accept-process-output' doc string says: > > > > > >>Return non-nil iff we received any output before the timeout expired. > > > > > > There is a miss spell. > "iff" stands for "if and only if" but maybe > "Return non-nil if and only if we received output before the timeout expired." > would be more comprehensible. So "iff" might be widely accepted, I guess. IMHO some users may appreciate description like one in elisp manual. The function `accept-process-output' returns non-`nil' if it did get some output, or `nil' if the timeout expired before output arrived. (Now I know the current doc string is all right, please just ignore.) Thanks. -- Tetsuo Tsukamoto ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Segfault in Emacs 23 when attempting to insert a negative integer (was: Re: infloop in skeleton-insert)
Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Nick Roberts <[EMAIL PROTECTED]> writes: >> It doesn't on Emacs 22: >> (char-or-string-p -4) >> t >> and if it does on Emacs 23 then I think that must be the bug. > Emacs 23 surely returns nil in that case. I think the > behaviour of Emacs 22 is a bug (or at least very confusing). > Don't people think OBJ can be safely used as an argument of > a function that expects a character (e.g. insert, > char-to-string) if (char-or-string-p OBJ) is true? This also throws up a further problem in the Emacs 23 branch: emacs -Q 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. [...] 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: infloop in skeleton-insert
I also find this confusing: (eq 1 1) t (eq 1.0 1.0) nil At present, each integer value has a unique Lisp object in Emacs Lisp. Therefore, `eq' is equivalent to `=' where integers are concerned. It is sometimes convenient to use `eq' for comparing an unknown value with an integer, because `eq' does not report an error if the unknown value is not a number--it accepts arguments of any type. By contrast, `=' signals an error if the arguments are not numbers or markers. However, it is a good idea to use `=' if you can, even for comparing integers, just in case we change the representation of integers in a future Emacs version. ___ 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 wrote: The manual says: A "character" in Emacs Lisp is nothing more than an integer. That would have to change. Not really, since that statement does not imply that the reverse is true. ___ 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
Current CVS head. The last line of `accept-process-output' doc string says: Return non-nil iff we received any output before the timeout expired. There is a miss spell. "iff" stands for "if and only if" but maybe "Return non-nil if and only if we received output before the timeout expired." would be more comprehensible. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
In article <[EMAIL PROTECTED]>, Nick Roberts <[EMAIL PROTECTED]> writes: > > It doesn't on Emacs 22: > > > (char-or-string-p -4) > > t > > > and if it does on Emacs 23 then I think that must be the bug. > > Emacs 23 surely returns nil in that case. I think the > behaviour of Emacs 22 is a bug (or at least very confusing). > Emacs 21 appears to have the same behaviour. > Don't people think OBJ can be safely used as an argument of > a function that expects a character (e.g. insert, > char-to-string) if (char-or-string-p OBJ) is true? > The manual says: >A "character" in Emacs Lisp is nothing more than an integer. > That would have to change. > And continues with: > In > other words, characters are represented by their character codes. For > example, the character `A' is represented as the integer 65. > Perhaps the `character' -4 just doesn't have a representation/character code. ??? If `character' -4 doesn't have a character code, what is -4 for that character? And, if it doesnt' have a representation, -4 doesn't represent a character, thus -4 is not a character. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
miss spell in `accept-process-output' doc string
Current CVS head. The last line of `accept-process-output' doc string says: > Return non-nil iff we received any output before the timeout expired. There is a miss spell. -- Tetsuo Tsukamoto ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > It doesn't on Emacs 22: > > > (char-or-string-p -4) > > t > > > and if it does on Emacs 23 then I think that must be the bug. > > Emacs 23 surely returns nil in that case. I think the > behaviour of Emacs 22 is a bug (or at least very confusing). Emacs 21 appears to have the same behaviour. > Don't people think OBJ can be safely used as an argument of > a function that expects a character (e.g. insert, > char-to-string) if (char-or-string-p OBJ) is true? The manual says: A "character" in Emacs Lisp is nothing more than an integer. That would have to change. And continues with: In other words, characters are represented by their character codes. For example, the character `A' is represented as the integer 65. Perhaps the `character' -4 just doesn't have a representation/character code. I also find this confusing: (eq 1 1) t (eq 1.0 1.0) nil but perhaps "Ours is not to reason why..." -- 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: infloop in skeleton-insert
In article <[EMAIL PROTECTED]>, Nick Roberts <[EMAIL PROTECTED]> writes: > It doesn't on Emacs 22: > (char-or-string-p -4) > t > and if it does on Emacs 23 then I think that must be the bug. Emacs 23 surely returns nil in that case. I think the behaviour of Emacs 22 is a bug (or at least very confusing). Don't people think OBJ can be safely used as an argument of a function that expects a character (e.g. insert, char-to-string) if (char-or-string-p OBJ) is true? I'm not claiming to change Emacs 22 now, but I think Emacs 23 should not be reverted to Emacs 22 about this. I propose to apply this patch to skeleton-internal-1 of Emacs 23. *** skeleton.el 30 Jan 2007 10:30:28 +0900 1.39.2.10 --- skeleton.el 10 Apr 2007 21:24:58 +0900 *** *** 355,369 (defun skeleton-internal-1 (element &optional literal recursive) (cond ((char-or-string-p element) ! (if (and (integerp element) ; -num !(< element 0)) ! (if skeleton-untabify ! (backward-delete-char-untabify (- element)) ! (delete-backward-char (- element))) ! (insert (if (not literal) ! (funcall skeleton-transformation-function element) ! element ((or (eq element '\n) ; actually (eq '\n 'n) ;; The sequence `> \n' is handled specially so as to indent the first ;; line after inserting the newline (to get the proper indentation). --- 355,369 (defun skeleton-internal-1 (element &optional literal recursive) (cond +((and (integerp element) ; -num +(< element 0)) + (if skeleton-untabify + (backward-delete-char-untabify (- element)) + (delete-backward-char (- element ((char-or-string-p element) ! (insert (if (not literal) ! (funcall skeleton-transformation-function element) ! element))) ((or (eq element '\n) ; actually (eq '\n 'n) ;; The sequence `> \n' is handled specially so as to indent the first ;; line after inserting the newline (to get the proper indentation). --- 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
> skeleton-internal-1 can enter an infinite loop if the ELEMENT argument > is a negative integer. To reproduce: > > emacs -Q > > M-x auto-insert-mode RET > > C-x C-f ~/tmp/test.tex > > Answer yes when asked to perform auto insertion for latex mode. > > Hit RET repeatedly. I can't reproduce this on Emacs 22, although oddly it tells me that the buffer is not modified when it completes. > This bug is due to skeleton-internal-1 relying on char-or-string-p to > return non-nil if its argument is an integer, while in fact, > char-or-string-p returns nil if its argument is a negative integer. It doesn't on Emacs 22: (char-or-string-p -4) t and if it does on Emacs 23 then I think that must be the bug. -- 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
infloop in skeleton-insert
skeleton-internal-1 can enter an infinite loop if the ELEMENT argument
is a negative integer. To reproduce:
emacs -Q
M-x auto-insert-mode RET
C-x C-f ~/tmp/test.tex
Answer yes when asked to perform auto insertion for latex mode.
Hit RET repeatedly.
This bug is due to skeleton-internal-1 relying on char-or-string-p to
return non-nil if its argument is an integer, while in fact,
char-or-string-p returns nil if its argument is a negative integer.
The following patch fixes this problem, and also stresses that an
integer only maps to a character if it is non-negative in the
docstring of char-or-string-p.
Cheers,
Lawrence
ChangeLog entry:
2007-04-10 Lawrence Mitchell <[EMAIL PROTECTED]>
* skeleton.el (skeleton-internal-1): Check if `element' is an
integer using integerp rather than relying on char-or-string-p: it
may be negative.
2007-04-10 Lawrence Mitchell <[EMAIL PROTECTED]>
* data.c (Fchar_or_string_p): Doc fix, a character is a
non-negative integer.
Index: lisp/skeleton.el
===
RCS file: /sources/emacs/emacs/lisp/skeleton.el,v
retrieving revision 1.39.2.10
diff -u -r1.39.2.10 skeleton.el
--- lisp/skeleton.el26 Jan 2007 06:15:09 - 1.39.2.10
+++ lisp/skeleton.el10 Apr 2007 11:37:59 -
@@ -355,7 +355,8 @@
(defun skeleton-internal-1 (element &optional literal recursive)
(cond
- ((char-or-string-p element)
+ (;; Negative integers are not `char-or-string-p'.
+(or (integerp element) (char-or-string-p element))
(if (and (integerp element); -num
(< element 0))
(if skeleton-untabify
Index: src/data.c
===
RCS file: /sources/emacs/emacs/src/data.c,v
retrieving revision 1.224.4.27
diff -u -r1.224.4.27 data.c
--- src/data.c 26 Jan 2007 06:15:07 - 1.224.4.27
+++ src/data.c 10 Apr 2007 11:38:00 -
@@ -435,7 +435,7 @@
}
DEFUN ("char-or-string-p", Fchar_or_string_p, Schar_or_string_p, 1, 1, 0,
- doc: /* Return t if OBJECT is a character (an integer) or a string. */)
+ doc: /* Return t if OBJECT is a character (a non-negative integer) or a
string. */)
(object)
register Lisp_Object object;
{
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''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in redisplay_internal -> note_mode_line_or_margin_highlight
Chong Yidong <[EMAIL PROTECTED]> writes: > Kim, could you study this patch and tell me what you think? Looks alright to me. -- 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
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: [EMAIL PROTECTED] (Kim F. Storm) >> Date: Mon, 09 Apr 2007 00:45:09 +0200 >> >> If I put this in the file xx.htm: >> >> >> TD class >> >> the rightmost pixels of the first D are lost as can be seen by the tiny >> screen-shot at the end of this message. The second D is shown normally. > > I cannot reproduce this on my machine. Does that Windows box have > some non-default display features enabled, like ClearType? If so, > could you turn that off and try again? (To turn off ClearType, > right-click on the desktop, select Properties, then click the > Appearance tab, click Effects, and under "Use the following method to > smooth edges of screen fonts", make sure that the setting is NOT > "Clear Type".) I don't have access to that Windows PC right now. I'll check when I get my hands on it again. BTW, it doesn't happen when I try on the other Windows XP system that I have at work. So I guess it is not a big problem - and we can ignore it for the 22 release. > >> Content-Type: image/gif; name=emacs-err.gif >> Content-Disposition: inline; filename=emacs-err.gif >> Content-Transfer-Encoding: base64 > > Yuck! GIF image... Many Emacs users will be unable to see it, as GIF > library is unavailable in many installations. I'm not an expert XP user, so I used what the screen grabber suggested. I didn't want to spend more time on this than necessary :-) -- 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: Crash in gc_sweep (SIGH!)
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: "Kim F. Storm" <[EMAIL PROTECTED]> >> Date: Mon, 9 Apr 2007 01:32:01 +0200 (CEST) >> >> Following my last bug report on W32 display error, I noticed that >> the image didn't get through. So I tried various stuff to decode >> the base64 stuff in various ways like this: >> >> - copy it to a new file buffer named x.gif, mark it, do >> base64-decode-region, >> and C-c C-c to view the image (no luck!) > > This works for me, if I invoke image-toggle-display by hand (you may > need to load image-mode before that). It is bound to C-c C-c only in > buffers that visit image files. > >> - create new file buffer y.gif, set file coding system to binary, copy image >> data into it, base64 decode it and C-c C-c (no luck) > > Works for me if I do the first part (``create new file buffer y.gif'') > with "M-x set-visited-file-name". How did you do that part in your > case? > > It also works to decode the base64 data externally (with `recode'), > then visit the resulting GIF directly. What I meant with "no luck" was that it displayed a square box instead of the image itself. After restarting Emacs, it seems that I can also display the image using the method that failed before. Maybe the gif image library messed something up when I invoked it on bad data, which caused it to fail even worse on subsequent attemts. I'm not sure how to see the library version. It is the one from redhat 9.0 libgif.so.4.1.0, It has this in the data section: GIF_LIBRARY IBMPC Version 4.0, Eric S. Raymond,Jan 24 2003, 23:33:26 I observed at one time that the base64-decode-region decoded the data into something different than on other occasions, but maybe I pasted the wrong base64 data ... it's a little difficult to say as all base64 looks the same to me :-) -- 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: CC Mode, labels not fontified
> > I wasn't able to reproduce the exact problem reported, in particular I > > couldn't find any dependency on jit-lock (but my Emacs hadn't been > > updated for some while). I hope nevertherless to have fixed the bug. > > > > Please let me know whether there are still problems. > > Excellent, thanks. Great, it fixes the OP and also seems to have fixed another misfontification I've seen of case statements (suddenly fontified as labels) in long switch statements. Thanks, Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
