Hello Emacs-bidi ( Sun, 23 May 2004 05:11:36 -0200 ) E-ma_il is Lo_ading..... Fawct: 90% of doectors get their presrcription draugs from Canfada and then resell them back to you for more mowney ! Saq
I think I've seen something very much like the above in some installers on Mac OS X. I thought it was indeed much better than the "peephole" offered by typical assistants I'd seen before. I find it
Hi everybody, I assume some of you have opinions on how this should be actually be packaged, so this patch is mostly for introduction, testing and playing around. If this code is acceptable in princi
Thanks! Couldn't this be done without introducing Windows-specific options? AFAIK, the logic employed by Windows when it encodes clipboard text is quite simple, something like: if it cannot be encod
Give me some time to get my head around it more, but the big steps involve going over a (really large) patch file and classifying changes into categories like trivial-cleanup / obvious-bugfix / emacs
Agreed. This way the user does not need to change anything (selection-coding-system works just as before) and that things that used to work still work. I strongly suspect that any potential differen
* Ted Zlatanov: FWIW: I consider myself a power user, and I would be very happy to have assistants implemented as outlined (with a clear view of which steps are to be performed, and some flexibility
Hi all, I implemented this in the attached patch. I have tested it on W2K, 95 and 98SE. Please tell of any problem the code has or of other improvements I can make. I have a couple of notes: The C co
As I've never read w32select.c, the following may be out of point, but I'll briefly explain how X selection is handled. All decoding and encoding of X selection is done in select.el. For reading a se
How is this going to be managed? After all, Gnus also works for XEmacs. If it is maintained straight in the Emacs CVS trunk, this might affect the average stability experienced by XEmacs users. If we
I think the best thing might be to have neither, but rather do two-way merging very frequently. Since most changes do actually occur in the Gnus tree, this would end up being "mostly" one-way. To mak
I agree, and have been arguing the same thing when people complain that mail-extr* cannot handle their weird input. Unfortunately, it is a losing discussion, since I can't claim that mail-extr* is on
I find the separate branch for Gnus to be inconvenient. Since it seems the code already works well as it is, I think it makes more sense to move it to the trunk right away and to then do "merge left
I've merged Stefan's post-5.10-merge Gnus changes from the Emacs trunk into the Gnus v5-10 branch (they all look pretty reasonable to my quick eyeballing). I'll merge any future Emacs Gnus changes si
It does this already. It defines a face which it uses just for highlighting errors; it defaults to red underlining. One thing that I think would be a nice touch here is if emacs could do wavy underl
One thing that I think would be a nice touch here is if emacs could do wavy underlines. It's just a little more visually distinctive than a straight underline and slightly more suggestive of an error
* Simon Josefsson: Okay, I've done some debugging, mainly by instrumenting the garbage collector. Basically, the patch below is a hook into mark_object() and prints object types, address, and also co
I think the change is straight forward and not that big. But, for the moment, I'm too heavily overloaded to work on it. :-( -- Ken'ichi HANDA address@hidden
I think the change is straight forward and not that big. But, for the moment, I'm too heavily overloaded to work on it. :-( Can you suggest briefly where this change would be made? That would help so