Re: Amendments in calc-units.el

> "Jay" == Jay Belanger <[EMAIL PROTECTED]> writes: >> P.S.: The patch also removes the "degree" for "Kelvin". Jay> Why? There is no such thing as degrees Kelvin, there are only Kelvins. (As an aside, I also agree that pt should remain pints.) -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTE

$B%j%"%k%?%$%`>R2p(B

$B>!R2p$7$?$$$N$G!"$4M}2r$rD:$-$?$/;W$$$^$9!#(B $BEv%5%$%H$O??7u$J=P2q6u4V$r1?1D$7$*$+$2$5$^$G9%I>[EMAIL PROTECTED](B $B$9!#%O!<%H$b%\%G%#!<$b%*!<[EMAIL PROTECTED];oEy$NJg=8$r$+$1!"(B $BLs#1#0#0#0L>[EMAIL PROTECTED],=8$^$j$^$7$?$N$G

Re: CORRECT VERSION: tramp (2.0.51); tramp and file-name-all-completions

"Kim F. Storm" <[EMAIL PROTECTED]> writes: > I'm trying to make ido work sensibly with tramp syntax -- but > getting a grip on file-name-all-completions is really a nightmare. I've committed a new tramp.el into Emacs CVS, please try this. Note that that I have set tramp-default-method to "ftp", t

Re: Fontifying one char strings.

> In a docstring, if I have : > > "`nil' if blahblah, `t' otherwise.", nil and t in docstrings shouldn't be quoted. This convention is described somewhere in the Emacs manual. That is true. However, there is still the question of what to do about other one-letter symbol n

Re: C-p on second line in shell-mode moves to beginning of buffer

In shell-mode, when point is on the second line (no matter which column), C-p (`previous-line') moves point to the beginning of the buffer. How comes that? Does this patch give good results? *** simple.el 16 Oct 2005 10:41:23 -0400 1.755 --- simple.el 17 Oct 2005 00:17:41 -0

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

I don't know where the bug, but may be fallback to default value of ispell-dictionary-alist if (ispell-aspell-find-dictionary) unsuccessfull? This is not fix bug, but fix spell checking in cases like described. I think this change should do it. Does it give good results? *** ispe

Re: Entering filenames with spaces

> However, I tend to think that the completion definition is not > essential, and is better for advanced users, while it can screw > beginners who don't know enough to use C-q SPC. Therefore, > I have concluded we should redefine SPC. > > Would someone like to implement thi

Re: Amendments in calc-units.el

Torsten Bronger <[EMAIL PROTECTED]> writes: ... > David Kastrup <[EMAIL PROTECTED]> writes: ... >> Anyway, I think it unreasonable to work with gal, qt, but then >> require "pint". If gal and qt are the usual abbreviations, then I >> think the normally used abbreviation for pint should also be us

Re: Saving minibuffer history

> Please remove emacs-devel from the Cc when discussing such issues. > Why? This was the gist of my reply: > If nothing is gained by breaking backward compatibility, why break it? > Is that not worthy of consideration as a design/development consideration > for Emacs? We're not talking about

[Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

Jason, Can you explain why you added that specific line. I can see that it looks like a reasonable thing to do, but Chong has problems with it (I don't). What problem was it supposed to fix? > From: Chong Yidong <[EMAIL PROTECTED]> > > The bug goes away if I remove the indicated line in > n

Re: image size limit?

Ok, I figured out how to do it. This patch imposes height and width limits based on the variable max-image-size. It should cause load_gif and the other image loading functions to return before the third-party libraries are called upon to load the image data, so we shouldn't get memory-overallocat

Re: Saving minibuffer history

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > Thank you. An improved version is now available at > . > > Someone reported trouble compiling it; could you say when it is ready? I think that was with regard to compiling it under Emacs

Re: Saving minibuffer history

"Drew Adams" <[EMAIL PROTECTED]> writes: > > Uh, Emacs 20? Why would one need to be compatible with > > that? Many, many people do use Emacs 20, for a variety of > > reasons. > > Please remove emacs-devel from the Cc when discussing such > issues. > > Why? This was the gi

Re: tramp (2.0.51); tramp and file-name-all-completions

Michael Albinus <[EMAIL PROTECTED]> writes: > When I wrote completion code for Tramp 3 years ago, I've introduced a > somehow obscure heuristic determining what is meant. This works more or > less the usual cases, but it breaks ido. Please note that I have managed to work around most problems in

Re: Saving minibuffer history

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > Thank you. An improved version is now available at > . > > Someone reported trouble compiling it; could you say when it is > ready? It should be ready. Feel free to forward problem rep

Re: tramp (2.0.51); tramp and file-name-all-completions

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > I would say these problems are all bugs in tramp. Yes. > file-name-all-completions has a simple spec, > and in principle it ought to work "right" for all meaningful args. The problem is the syntactical ambiguity of Tramp file names. (file-name

Re: Yet another emacs icons

2005/10/17, Richard M. Stallman <[EMAIL PROTECTED]>: > [*] Of course someone who doesn't use emacs won't know what the > crooked horns mean -- but so what? > > I do use Emacs, but I don't find crooked horns to have a self-evident > meaning. Also I am not sure I would recognize any crooked

Re: Shall we use etc/images more?

Richard M. Stallman <[EMAIL PROTECTED]> wrote: > I'm not sure whether to move the lc-* (low resolution copies) images to > etc/images/lc or leave them as etc/images/lc*. Thoughts? > > The most natural thing would be to replace `lc-' with a suffix > or infix; instead of lc-foo.pbm, it woul

RE: Saving minibuffer history

> Uh, Emacs 20? Why would one need to be compatible with that? > Many, many people do use Emacs 20, for a variety of reasons. Please remove emacs-devel from the Cc when discussing such issues. Why? This was the gist of my reply: If nothing is gained by breaking backward compati

RE: Yet another emacs icons

I think all of your icons are very pretty, but I liked the earlier "notebook" versions much better What do you mean by "notebook versions"? I can't match that with anything I remember seeing. Lennart has put all of the icons here: http://ourcomments.org/Emacs/NewIcons.htm

Re: Docstring for archive-zip-extract

I installed that. Thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

pgg*.el

Would someone please move the pgg files from lisp/gnus to lisp? These are a general facility, and there is no reason for it to be considered part of Gnus. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-deve

Re: Yet another emacs icons

I think all of your icons are very pretty, but I liked the earlier "notebook" versions much better What do you mean by "notebook versions"? I can't match that with anything I remember seeing. [*] Of course someone who doesn't use emacs won't know what the crooked horns mean -- bu

Re: Saving minibuffer history

Thank you. An improved version is now available at . Someone reported trouble compiling it; could you say when it is ready? I see that changes were installed in the file already. Is it up-to-date now? ___

Re: tramp (2.0.51); tramp and file-name-all-completions

I would say these problems are all bugs in tramp. file-name-all-completions has a simple spec, and in principle it ought to work "right" for all meaningful args. If there are some cases where it is just hopeless to ask tramp to do completion correctly, we could decide on some return value that mea

Re: image size limit?

As for libpng, the png_set_user_limits() function was only added in version 1.0.16rc1, from 2004, so if we use that we'll lose compatibility with older versions. I think it is ok for the new Emacs to use a feature of libpng that is one year old. Would you like to write the code? Perh

Re: Saving minibuffer history

> Uh, Emacs 20? Why would one need to be compatible with that? > Many, many people do use Emacs 20, for a variety of reasons. Please remove emacs-devel from the Cc when discussing such issues. Stefan ___ Emacs-devel mailing list Emacs-de

RE: Saving minibuffer history

Uh, Emacs 20? Why would one need to be compatible with that? Many, many people do use Emacs 20, for a variety of reasons. Emacs development does not have as a goal to be backward compatible - I understand that. I never said that Emacs 22 "needs" to be compatible with Emacs 20. If, however,

Re: Fontifying one char strings.

Jesper Harder <[EMAIL PROTECTED]> writes: > Michael Cadilhac <[EMAIL PROTECTED]> writes: > >> In a docstring, if I have : >> >> "`nil' if blahblah, `t' otherwise.", > > nil and t in docstrings shouldn't be quoted. This convention is > described somewhere in the Emacs manual. And what about

Re: Saving minibuffer history

>> I installed it. Thanks. > Thank you. An improved version is now available at > . Thank you. Installed. Along with a few minor changes, mostly to remove run-time dependency on CL and to get rid of most checks for XEmacs, replaced by checks fo

Re: Fontifying one char strings.

Michael Cadilhac <[EMAIL PROTECTED]> writes: > In a docstring, if I have : > > "`nil' if blahblah, `t' otherwise.", nil and t in docstrings shouldn't be quoted. This convention is described somewhere in the Emacs manual. ___ Emacs-devel mailing

Misleading error messages from bytecomp.el

Having line number and column in messages from bytecomp.el is a great help. When they are correct, that is. Otherwise they are very confusing. If one compiles a file foo.el with the lines 1: (defun foo (l) 2: (mapc (lambda (elm) 3: (consp elm)) 4: l) 5: (message "foo: %s" elm

Re: rcirc.el

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > Do you think the package should be renamed from "rcirc" to simply > "irc"? > > I have no opinion about the package name, but I think the most > important question is the name of the command used to invoke it. We > should make that name a

Fontifying one char strings.

Hello ! In a docstring, if I have : "`nil' if blahblah, `t' otherwise.", only nil will be fontified with font-lock-constant-face. I'm wondering why this should be that way, I'm using the following patch without being annoyed: *** emacs/lisp/font-lock.el 2005-10-16 17:07:12.0

Re: TUTORIAL.gz

On 13 Oct 2005, at 21:11, Richard M. Stallman wrote: I would like to suggest to enable help-with-tutorial to load .gz files. This would allow site maintainers to compress the files, saving around 600K in installs of binary distributions. (info has no problems with gzipped file

Re: Shall we use etc/images more?

I'm not sure whether to move the lc-* (low resolution copies) images to etc/images/lc or leave them as etc/images/lc*. Thoughts? The most natural thing would be to replace `lc-' with a suffix or infix; instead of lc-foo.pbm, it would be foo-lc.pbm. However, depending on the actual file nam

Re: wrapper fn for message and minibuffer-message?

Eval: (setq foo 'bar) typing `C-s foo' will display: Eval: (setq foo 'bar) [I-search backward: foo] and `foo' will be highlighted in `isearch' face, as usual. I suggest that those who find this interesting try it out. ___ Emacs-devel

Re: Qs on key-description, substitute-command-keys

The size of the command name plus 4 characters of the "M-x " string should define the maximum length of allowed substitutions, and if the command is bound to several key, then to print as many keys as many of them fits into this limit. For example: That would be a big in con

Re: M-g in dired

BTW, there is a bug related to key suggestions: `M-x next-error RET' typed in a dired buffer suggests the key binding `M-g n' even though `M-g' is not a prefix key in dired buffers. That seems like a bug. where-is-internal should never suggest a key which isn't really bound to the des

Re: M-g in dired

2. Rebind `dired-goto-file' to `M-g f' (and `M-g M-f'). That seems reasonable--in Dired mode alone. This key sequence could serve as a global key binding. Typing it in any buffer could create a dired buffer and move p

Re: Qs on key-description, substitute-command-keys

However, I would prefer a list of preferred bindings, in order of preference, to a single binding. If, for some reason, the exact binding is not known (e.g. might have changed), so that the first preference isn't available (bound), the next available binding would be used, in order.

Re: Dedicated *Completions* frame iconified but not de-iconified

Could you point me to the relevant code in Emacs responsible for de-iconifying the frame so that I can report to the fluxbox people? I presume it is the code in x_make_frame_visible (xterm.c). You could try first running under GDB and making sure that that function really is being called.

Re: rcirc.el

Do you think the package should be renamed from "rcirc" to simply "irc"? I have no opinion about the package name, but I think the most important question is the name of the command used to invoke it. We should make that name as natural and easy to remember as we can. _

Re: Qs on key-description, substitute-command-keys

> While I can understand the impulse behind this heuristic, it ultimately > seems paternalistic ("we need to prepare you for the great variety of > terminals that you may encounter"). No, it's just done for lack of anything better. Currently, Emacs almost never knows which keys you have access to

Re: Qs on key-description, substitute-command-keys

> I think we should devise some way to get the desired result > without going through contorsions like `advertized-bla'. > ... the first thing that jumps to my mind is to rely > on a `preferred-binding' property (containing a key-sequence) > on the command symbol, or otherwise r

Re: Saving minibuffer history

> 2. (defvar savehist-coding-system (if (string-match "XEmacs" emacs-version) >'iso-2022-8 > 'utf-8) Shouldn't it just use `emacs-mule'? This would ensure that no information can be lost, contrary to what happens

Docstring for archive-zip-extract

The docstring for the user option `archive-zip-extract' in lisp/arc-mode.el mentions the variable `archive-zip-use-pkzip', which has been deleted. The following patch fixes this. Would somebody please install it? *** arc-mode.el~2005-08-07 00:13:41.0 +0200 --- arc-mode.el 2005-10-

Re: Saving minibuffer history

"Drew Adams" <[EMAIL PROTECTED]> writes: > An improved version is now available at > . > > FYI - I had some problems trying to use this library with Emacs 20, > but if a few minor changes are made, it works well. Thanks for the testing, b

Re: Amendments in calc-units.el

Miles Bader <[EMAIL PROTECTED]> writes: > 2005/10/16, Torsten Bronger <[EMAIL PROTECTED]>: >> Secondly, "point" should be renamed "bp" (big point). It's not >> *the* point after all (but an invention by Adobe, as far as I know). > > I suspect more calc users use postscript points than "real point

Re: Saving minibuffer history

"Drew Adams" <[EMAIL PROTECTED]> writes: > An improved version is now available at > . > > FYI - I had some problems trying to use this library with Emacs 20, but if a > few minor changes are made, it works well. > > Here are the problems I

Re: Amendments in calc-units.el

Hallöchen! David Kastrup <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> I suggest two renamings of unit abbreviations in calc-units.el, >> in the attached patch. >> >> "pt" should become "pint" in order to make room for the >> typographic point (pt). I think this