Re: Patch: Follow convention for reading with the minibuffer.

Juri Linkov <[EMAIL PROTECTED]> writes: > In the first sentence "after the colon" should be changed to "before > the colon". But what to do with the second sentence? Commands that > read buffer names still put the default after the colon. This is being worked on. I'm waiting for the final OK f

spaceward Pharormaceutical

Good days Easy Fast Home Best Total OrdeShipDelivPrricConf ringpingeryesidentiality AmbVALXanLevVIACIA ienIUMax itraGRALIS  $  $ $ 3.75 3.331.21 More infoo ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/

Re: Shall we use etc/images more?

> 4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and >update lisp/speedbar.el. I can handle this one. A new version of speedbar, with a new set of images, is due to be checked in as soon as the papers get settled (there seems to be some delay at the FSF copyright assignm

Hello

Dear Sir/Madam, I am Mr.Xiao Jun,managinig director of HUAMAO ARTS AND CRAFTS Import/Export Corp.(HMARTS) we are a group of business men who deal on Art and Craft and export into the Canada/America and Europe, Asia,Australia. We are searching for representatives who can help us establish a medium o

Re: Shall we use etc/images more?

Regarding my last message about rehoming *all* of the images, I have the following specific proposal. Because the changes are large, I would like permission from the Emacs royals before proceeding. Otherwise, I'll just move the MH-E images (which, by the way, do not appear to be in use by other pa

Re: balance-windows again

It occurs to me that the nicest way to do this would be to turn the window-configuration data structure into a transparent structure from which this info can be extracted. I think the data structure as you've designed it won't do that job, but you could probably adapt it easily enough to do that j

Re: [EMAIL PROTECTED]: Crash when loading a particular gif image]

This patch probably fixes the bug, but Emacs should really enforce limits on the dimensions given by the GIF library. What if it reports an image width of two million pixels? Do we really want to allocate such large images and pixmaps? I agree we should have l

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

So, I would conclude, that there is no bug at all. Emacs can't possibly know, that the "Local Variables:" block isn't meant to be interpreted in the diff file. =20 Hmm. It still feels like a bug to me, and I want to find a way to fix it. One idea is to restrict what strings can be u

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

> E.g. major modes could set a "local-variables-prefix-regexp" which > the text leading to the "Local Variables" should match. E.g. c-mode > could set it to "\\`[ \t]*\\(//\\|/?\\*)[ \t]*\\'" Problem is: > in order for this to be useful for the OP, the test should be done > *after* using the Local

Re: Patch: Follow convention for reading with the minibuffer.

>> Here's my second take on this. Someone please check this patch before >> actually committing! It's too easy to make an error when doing such >> kind of changes. > > Thanks, I installed this patch (including the subsequent change you sent > to Richard). I noticed that now the Emacs manual does

Re: Patch: Follow convention for reading with the minibuffer.

> the elisp (and other) code i maintain never uses tabs for indentation, > accomplished primarily by setting `indent-tabs-mode' to nil. when i > edit code that uses tabs for indentation, i leave the part not relevant > to the edit alone but take no extra steps to use tabs for the part that > i'm e

Re: Shall we use etc/images more?

> revision 1.50 > date: 2005/09/18 14:04:46; author: cyd; state: Exp; lines: +20 -11 > (image-load-path): Use symbol `data-directory' instead of its value, > for backward compatibility with packages that bind it during > `find-image'. Suggested by Katsumi Yamaoka. > (image-search-load-path): Ha

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

Stefan Monnier <[EMAIL PROTECTED]> writes: > E.g. major modes could set a "local-variables-prefix-regexp" which the text > leading to the "Local Variables" should match. E.g. c-mode could set it to > "\\`[ \t]*\\(//\\|/?\\*)[ \t]*\\'" Problem is: in order for > this to be useful for the OP, the

find-image and image-load-path

Chong, Thanks very much for making the image-load-path modifications to find-image! Were you planning on moving the images from toolbar and mail to etc/images, or should I proceed as I have suggested? Actually, I had suggested just moving the MH-E images, but it would probably be good for complet

Re: jit-lock refontifies too much

>>> + (if (or (and (memq major-mode '(emacs-lisp-mode lisp-mode)) >>> +(or (= (nth 0 ppss) 1) >>> +(= (nth 0 jit-lock-context-ppss) 1))) >> >> Here I'd just compare (not (equal (nth 0 ppss) (nth 0 >> jit-lock-context-ppss))). > That w

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

>> > So, I would conclude, that there is no bug at all. Emacs can't >> > possibly know, that the "Local Variables:" block isn't meant to be >> > interpreted in the diff file. > [...] >> Perhaps, Emacs has to detect that the file is a patch before >> checking "-*- ... -*-" and "Local Variables".

emacs on mlterm

Hi, I am trying to use a recent cvs emacs on mlterm, a terminal with bidi support. It works reasonably well as long as no use is made of combining Hebrew characters with diacritical marks (which is a feature of mlterm). When combining is permitted, the cursor position becomes somewhat erratic.

ispell-aspell-find-dictionary: Opening input file: no such file or directory

Hi. After this: 2005-09-24 Magnus Henoch <[EMAIL PROTECTED]> * textmodes/ispell.el (ispell-maybe-find-aspell-dictionaries): New function, code extracted from ispell-valid-dictionary-list. (ispell-valid-dictionary-list, ispell-accept-buffer-local-defs): Call it.

HAVE YOUR VACATIONS ALLSET-ALL ABOUT THAILAND

  HIDEAWAY YOURSELF FROM ALL MESS  What's about a few days in Thailand??? If you are planning to spend a vacation, and if Thailand is one of your destination, www.allresortthailand.com, Thailand's on-line hotels and resorts reservation provider can have everything fixed. ++900 hotels and re

Re: color-grey-p and black?

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > All the colors that fit the new clause are very close to > black, so it is right to say they are gray. What about colors that are very close to white? -- Daniel Brockman <[EMAIL PROTECTED]> ___ Em

Re: color-grey-p and black?

Wouldn't it be better to simply replace "<" with "<=" in all 3 comparisons? That seems to me like a less radical change. I don't know if it is better. All the colors that fit the new clause are very close to black, so it is right to say they are gray. __

Re: Problem with national characters in XHTML

Piet van Oostrum wrote: Mathias Dahl <[EMAIL PROTECTED]> (MD) wrote: MD> I might be wrong here, but doesn't UTF-8 encode all characters in MD> Latin-1 (ISO 8859-1) exactly as they are *in* Latin-1 encoding? No. Iso 8859-1 uses 1 byte for all characters, while UTF-8 uses

Re: Problem with national characters in XHTML

Piet van Oostrum wrote: [EMAIL PROTECTED] (Tomas Zerolo) (TZ) wrote: TZ> Ah. You have to distinguish between Emacs's internal representation TZ> (that's possibly the 2276 you mention), which doesn't change (al least TZ> unless you try hard ;) and what is in the file (how Emacs

Re: Problem with national characters in XHTML

> Mathias Dahl <[EMAIL PROTECTED]> (MD) wrote: >MD> I might be wrong here, but doesn't UTF-8 encode all characters in >MD> Latin-1 (ISO 8859-1) exactly as they are *in* Latin-1 encoding? No. Iso 8859-1 uses 1 byte for all characters, while UTF-8 uses two bytes for those characters that are in

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

On Thu, Sep 29, 2005 at 09:24:43PM +0900, Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Sascha Wilde <[EMAIL PROTECTED]> writes: > > > So, I would conclude, that there is no bug at all. Emacs can't > > possibly know, that the "Local Variables:" block isn't meant to be > > interpreted in

Re: Problem with national characters in XHTML

> [EMAIL PROTECTED] (Tomas Zerolo) (TZ) wrote: >TZ> Ah. You have to distinguish between Emacs's internal representation >TZ> (that's possibly the 2276 you mention), which doesn't change (al least >TZ> unless you try hard ;) and what is in the file (how Emacs writes or >TZ> interprets what it r

Re: balance-windows again

[EMAIL PROTECTED] (Kim F. Storm) writes: > The following patch adds a window-split-tree function which returns a simple > tree presentation of the window split. You can use window-edges on the > elements of the tree to get the dimensions (and build your representation). I think exposing the "con

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

In article <[EMAIL PROTECTED]>, Sascha Wilde <[EMAIL PROTECTED]> writes: > So, I would conclude, that there is no bug at all. Emacs can't > possibly know, that the "Local Variables:" block isn't meant to be > interpreted in the diff file. > And I wouldn't consider the fact, that c-mode fontifi

no Emacs icon under GNOME?

This seems to be a FAQ, but can something be done about getting Emacs to show its own icon on the GNOME desktop? See for example . FWIW it displays fine under KDE last I tested it. Any ideas on how to fix this? Someone suggested that

Re: Problem with national characters in XHTML

Juanma Barranquero <[EMAIL PROTECTED]> writes: > On 9/28/05, LENNART BORGMAN <[EMAIL PROTECTED]> wrote: > >> I have run into a problem with swedish national characters in an >> XHTML document. The header of the document is like this: >> >> >> > "http://www.w3.org/TR/REC-html40/loo

Re: [EMAIL PROTECTED]: Emacs very slow opening file]

On Wed, Sep 28, 2005 at 01:11:10PM -0400, Richard M. Stallman wrote: > Would someone please investigate this bug report, > and then ack? [...] > I tried opening a debian 'patch' file in Emacs. The Emacs process > appeared to hang, using all my CPU. It wouldn't respond to C-g. > > After chopping do

Re: Problem with national characters in XHTML

On Wed, Sep 28, 2005 at 09:12:45PM +0200, Lennart Borgman wrote: > Lennart Borgman wrote: [...] > >I find this a bit confusing still. What character is entered by Emacs > >when I type ä on my swedish keyboard? When I look at the character ä > >in Emacs with (following-char) it in both test file