compile.el::grep-program - should it use egrep instead of grep?
There is (defvar grep-program egrep ...) in compile.el, but in some systems the grep is the old one, which does not provide the extended syntax. Would it be possible to set this by default to 'egrep'? I'm not aware of any *nix OS that would not include egrep. Jari ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: where-is-internal question
Drew Adams [EMAIL PROTECTED] writes: In previous Emacs versions, I could do this, to bind stuff that is bound to self-insert-command in the global map: (dolist (key (where-is-internal 'self-insert-command global-map)) (define-key my-map key 'my-command)) Now, however, it looks like I need to do something like the following. (dolist (key (or (condition-case nil (where-is-internal 'self-insert-command global-map nil nil t) (wrong-number-of-arguments nil)) (where-is-internal 'self-insert-command global-map))) (define-key my-map key 'my-command)) I forgot to mention that, whereas the above code is lightning-quick in Emacs 20 (without the 5th arg), in Emacs 22 it takes about 5 _seconds_ (on a pretty fast machine). Why so slow? IIRC, the problem probably is that with command remapping, where-is-internal in 22.x has to lookup the key binding for each command to see if it remapped -- in the normal case (where a command only has a few bindings), the penalty is neglible, but for self-insert-command specifically, that will be time consuming. The problem is that where-is-internal must return proper bindings for commands that are remapped to, so there really don't see to be an easy way to speed things up. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Shall we use etc/images more?
Bill Wohler [EMAIL PROTECTED] writes: In MH-E, I think I'd like to reference images in etc/images/mail and, say, etc/images/common, instead of lisp/mail and lisp/toolbar. I'd oppose to a common subdirectory -- such general purpose images should just be placed directly in etc/images. and the images in lisp/toolbar into etc/images/common (or nominate your favorite). etc/images -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Emacs CVS Crash
It happens in gcc 3.2.2 but not in 3.3.5 (I've just test it), so the bug is already fixed in gcc. How about writing a brief entry for etc/PROBLEMS? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Stefan just checked in a different fix to buff-menu.el, defining a lambda expression and interning it. This fix also has a problem: `C-h k' can't generate a hyperlink to the Lisp file: mouse-2 runs the command Buffer-menu-sort-by-name, which is an interactive Lisp function. Kim's solution doesn't have this problem. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: where-is-internal question
(if (boundp 'this-original-command) Hmm... didn't know about that one. I've used (fboundp 'command-remapping) instead, which feels better to me. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
(defun Buffer-menu-make-sort-button (name column) (if (equal column Buffer-menu-sort-column) (setq column nil)) (let* ((downname (downcase name)) ! (map (make-sparse-keymap))) ;; This keymap handles both nil and non-nil ;; values for Buffer-menu-use-header-line. ! (define-key map [header-line mouse-1] 'Buffer-menu-sort-by-column) ! (define-key map [header-line mouse-2] 'Buffer-menu-sort-by-column) ! (define-key map [mouse-2] 'Buffer-menu-sort-by-column) (define-key map [follow-link] 'mouse-face) ! (define-key map \C-m 'Buffer-menu-sort-by-column) (propertize name + 'column column 'help-echo (concat (if Buffer-menu-use-header-line mouse-1, mouse-2: sort by Then the keymap doesn't depend on `name' or `column', so it can be created once and for all at the toplevel, right? Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: recentf.el - digit shortcuts
The files with shortcuts are now unaligned with files without shortcuts. Is that intentional? Otherwise it seems fine. Yes it is, because items with extra alignment spaces doesn't look good (IMO) when they are grouped into sub-lists. As items with shortcuts are now grouped together at the top of the list, the extra alignment spaces seem no more necessary IMO. Also that simplifies the code a little ;-) I will commit the changes as soon as my free time will permit. Thanks! David ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Stefan Monnier [EMAIL PROTECTED] writes: (defun Buffer-menu-make-sort-button (name column) (if (equal column Buffer-menu-sort-column) (setq column nil)) (let* ((downname (downcase name)) ! (map (make-sparse-keymap))) ;; This keymap handles both nil and non-nil ;; values for Buffer-menu-use-header-line. ! (define-key map [header-line mouse-1] 'Buffer-menu-sort-by-column) ! (define-key map [header-line mouse-2] 'Buffer-menu-sort-by-column) ! (define-key map [mouse-2] 'Buffer-menu-sort-by-column) (define-key map [follow-link] 'mouse-face) ! (define-key map \C-m 'Buffer-menu-sort-by-column) (propertize name +'column column 'help-echo (concat (if Buffer-menu-use-header-line mouse-1, mouse-2: sort by Then the keymap doesn't depend on `name' or `column', so it can be created once and for all at the toplevel, right? Right! Chong, would you like to work on this? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
[PATCH] Moving Comments node from objects.texi to intro.texi
When going through objects.texi the oddest part I found,
was the section on comments. To me comments have nothing
to do with objects, and while tangentially related to read syntax
they are not part of any particular object's read syntax.
Since I've only gone through the two files so far, I can only
suggest moving it into intro.texi. This would keep it close to
the beginning of the reference. Below is the old menu from
objects.texi and the menu for where I propose to move the
node in intro.texi. Patch attached, with Changelog entry.
Old placement:
@menu
* Printed Representation:: How Lisp objects are represented as text.
* Comments::Comments and their formatting conventions.
* Programming Types:: Types found in all Lisp systems.
* Editing Types:: Types specific to Emacs.
* Circular Objects::Read syntax for circular structure.
* Type Predicates:: Tests related to types.
* Equality Predicates:: Tests of equality between any two objects.
@end menu
New placement
@menu
* Some Terms:: Explanation of terms we use in this manual.
* nil and t::How the symbols @code{nil} and @code{t} are used.
* Comments::Comments and their formatting conventions.
* Evaluation Notation:: The format we use for examples of evaluation.
* Printing Notation::The format we use when examples print text.
* Error Messages:: The format we use for examples of errors.
* Buffer Text Notation:: The format we use for buffer contents in examples.
* Format of Descriptions:: Notation for describing functions, variables, etc.
@end menu
To me the node on comments fits more naturally with the
other notation related nodes.
Josh
P.S. I tried to fix the text duplication in the e-mail, hopefully it's
back to normal.
comments-move.patch
Description: Binary data
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: where-is-internal question
(if (boundp 'this-original-command) (define-key my-map [remap self-insert-command] 'my-command) (dolist (key (where-is-internal 'self-insert-command global-map)) (define-key my-map key 'my-command))) Also the above dolist is advantageously replaced by a call to substitute-key-definition (whose docstring mentions the use of the [remap foo] binding). Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
Çarşamba 07 Eylül 2005 07:16 tarihinde, Eli Zaretskii şunları yazmıştı: From: Nick Roberts [EMAIL PROTECTED] Date: Wed, 7 Sep 2005 11:01:27 +1200 Cc: emacs-devel@gnu.org It seems to be due to this change: 2004-03-13 Eli Zaretskii [EMAIL PROTECTED] * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined. I guess it hasn't been noticed before because, although people may use tmm, most use a version of Emacs thats compiled with X (or at least HAVE_MENUS). I haven't reverted this change because it must be there for a reason. Eli? It _was_ for a reason. The 2 related changes I committed at that time were these: 2004-03-13 Eli Zaretskii [EMAIL PROTECTED] * Makefile.in (XMENU_OBJ): Include xmenu.o if HAVE_MENUS is defined. * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined. I don't remember the details (you will probably find them in emacs-devel or emacs-pretest-bug archives for that period of time), but there was some build failure, I think on MacOS, which these changes were part of fixing. Please don't take out this change without understanding what it was fixing in the first place. Is there a way to fix this for non-X users of emacs ? Regards, ismail ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: where-is-internal question
(dolist (key (where-is-internal 'self-insert-command global-map)) (define-key my-map key 'my-command))) Also the above dolist is advantageously replaced by a call to substitute-key-definition Of course! I've used substitute-key-definition a lot, but I forgot about its optional OLDMAP arg. Thanks. BTW, I wonder about the decision to not mention the PREFIX arg in the doc string of substitute-key-definition. It is visible anyway, when you do C-h f. I think it would be clearer to explicitly mention it, saying that it is for internal use only, or that it is for recursive calls only. That is, describe it, but tell people not to use it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
time.el and display-time-mail-function
Hello, Recently I tried to write a custom display-time-mail-function, as provided for in time.el (my mail system was being converted from mbox to maildir++ format, so I had to check for the existence of files in a directory, rather than for the existence of a single file). However I think there's a problem in the logic in time.el. In function display-time-update, it has the following: (mail (or (and display-time-mail-function (funcall display-time-mail-function)) (and (stringp mail-spool-file) where display-time-mail-function is a user-definable function, which seems like the perfect thing for my situation. The problem is the or -- if my display-time-mail-function returns nil (to indicate that there is no new mail), instead of stopping there, it will continue with the standard mail-spool-file check. I believe this logic is wrong, and it could be fixed by changing the or to a cond/if, e.g.: (mail (if display-time-mail-function (funcall display-time-mail-function) (and (stringp mail-spool-file) Does this seem like a reasonable change to make? It seems that, without this change, display-time-mail-function is useless. But maybe I'm missing some aspect. Thanks, -Jason ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: recentf.el - digit shortcuts
On 2005-09-07 05:44 PDT, David Ponce writes: The files with shortcuts are now unaligned with files without shortcuts. Is that intentional? Otherwise it seems fine. David Yes it is, because items with extra alignment spaces David doesn't look good (IMO) when they are grouped into David sub-lists. As items with shortcuts are now grouped David together at the top of the list, the extra alignment David spaces seem no more necessary IMO. Also that simplifies David the code a little ;-) David I will commit the changes as soon as my free time will David permit. OK. Thanks! -- Karl 2005-09-07 10:26 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
Çarşamba 07 Eylül 2005 21:04 tarihinde, Eli Zaretskii şunları yazmıştı: From: =?utf-8?q?=C4=B0smail_D=C3=B6nmez?= [EMAIL PROTECTED] Date: Wed, 7 Sep 2005 17:58:09 +0300 I don't remember the details (you will probably find them in emacs-devel or emacs-pretest-bug archives for that period of time), but there was some build failure, I think on MacOS, which these changes were part of fixing. Please don't take out this change without understanding what it was fixing in the first place. Is there a way to fix this for non-X users of emacs ? Sorry, I don't understand: what is that ``this'' which you want to be fixed? If that's the tmm problem, it _will_ be fixed, we just need to find a way to do that without breaking whatever it was that my change back in 2004 fixed. Problem is F10-O no longer works in emacs configured with --without-x . And as far as I can tell its a more recent change than in 2004 as I am using emacs cvs for long and this problem is new. Regards, ismail ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
From: =?utf-8?q?=C4=B0smail_D=C3=B6nmez?= [EMAIL PROTECTED] Date: Wed, 7 Sep 2005 17:58:09 +0300 I don't remember the details (you will probably find them in emacs-devel or emacs-pretest-bug archives for that period of time), but there was some build failure, I think on MacOS, which these changes were part of fixing. Please don't take out this change without understanding what it was fixing in the first place. Is there a way to fix this for non-X users of emacs ? Sorry, I don't understand: what is that ``this'' which you want to be fixed? If that's the tmm problem, it _will_ be fixed, we just need to find a way to do that without breaking whatever it was that my change back in 2004 fixed. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Then the keymap doesn't depend on `name' or `column', so it can be created once and for all at the toplevel, right? Right! Chong, would you like to work on this? Yes, it's not hard. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs: second stab at a patch.
Hi, Richard!
Here is mark II of my patch to searching.texi, incorporating most of the
changes you suggested. It isn't yet finished - I haven't made any
amendments to the sentence bits - so I haven't included a ChangeLog
entry. I'd appreciate further criticism on it.
On Sun, 4 Sep 2005, Richard M. Stallman wrote:
[ ]
Using @defvar inside of @table is a peculiar thing to do. It may look
bad in TeX or in Makeinfo.
I really wanted @subheading, which I've since found in the Texinfo manual
and now put into the text.
! This is the regular expression describing line-beginnings that
Describing is vague; what it does is match them.
I hadn't actually touched the bit about pages. I have now!
! Buffers divide into @dfn{paragraphs},
That is a strange way to put it. It sounds like you're saying that
buffers actually split up. It would be better to make this
parallel to the info about pages.
I was trying to suggest (i) that _all_ buffers have paragraphs, not just
special buffers, for whatever value of special; (ii) The set of
paragraphs in a buffer together with the separator lines COVER a buffer;
it is not the case that a buffer might have an isolated paragraph hiding
away somewhere inside it. (iii) Also, I was trying to avoid using the
passive voice.
I solved (i) by saying explicitly at the top that all buffers have p, p,
and s.
(ii)+(iii) are more difficult. In the version of the patch I'm
submitting with this email, I've left a passive in. I can't find a way
of expressing it which reads well and avoids passives. Suggestions would
be welcome.
! normally don't [EMAIL PROTECTED] is possible for a blank line to be
! both the last line of one paragraph and the first line of the next.}.
Are you sure? I don't think so. A blank line would normally
be a separator line, not the first or last line of any paragraph.
Try out this file:
--
1st Line[starter]
asdf
1st Line[starter]
asdf
-
Local Variables:
paragraph-separate: -
paragraph-start: 1st Line\\|-
End:
-
Do M-h on each of the lines asdf. The blank line is included in both
paragraphs. This happens because the blank line isn't a separator here.
It is an ordinary line of the upper paragraph and the heuristic (sorry
about the word) blank line tacked on to the paragraph below. Not
something to lose too much sleep about, perhaps. I've toned down the bit
about it in the patch.
Here is the patch:
*** searching-1.67.texi Tue Aug 30 09:15:42 2005
--- searching-1.67.acm.texi Wed Sep 7 16:49:38 2005
***
*** 1643,1685
@end table
@node Standard Regexps
! @section Standard Regular Expressions Used in Editing
@cindex regexps used standardly in editing
@cindex standard regexps used in editing
! This section describes some variables that hold regular expressions
! used for certain purposes in editing:
@defvar page-delimiter
! This is the regular expression describing line-beginnings that separate
! pages. The default value is @code{^\014} (i.e., @code{^^L} or
! @code{^\C-l}); this matches a line that starts with a formfeed
! character.
@end defvar
! The following two regular expressions should @emph{not} assume the
! match always starts at the beginning of a line; they should not use
! @samp{^} to anchor the match. Most often, the paragraph commands do
! check for a match only at the beginning of a line, which means that
! @samp{^} would be superfluous. When there is a nonzero left margin,
! they accept matches that start after the left margin. In that case, a
! @samp{^} would be incorrect. However, a @samp{^} is harmless in modes
! where a left margin is never used.
@defvar paragraph-separate
! This is the regular expression for recognizing the beginning of a line
! that separates paragraphs. (If you change this, you may have to
! change @code{paragraph-start} also.) The default value is
! @[EMAIL PROTECTED][@ \t\f]*$}}, which matches a line that consists entirely
of
! spaces, tabs, and form feeds (after its left margin).
@end defvar
@defvar paragraph-start
! This is the regular expression for recognizing the beginning of a line
! that starts @emph{or} separates paragraphs. The default value is
! @[EMAIL PROTECTED]\f\\|[ \t]*$}}, which matches a line containing only
! whitespace or starting with a form feed (after its left margin).
@end defvar
@defvar sentence-end
If [EMAIL PROTECTED], the value should be a regular expression describing
--- 1643,1750
@end table
@node Standard Regexps
! @section Regular Expressions for Pages, Paragraphs, and Sentences
@cindex regexps used standardly in editing
@cindex standard regexps used in editing
! This section specifies precisely what pages, paragraphs, and
! sentences are in Emacs and the regular expressions it uses to
! recognize them. By setting these variables
Re: [PATCH] Moving Comments node from objects.texi to intro.texi
Joshua Varner [EMAIL PROTECTED] writes: When going through objects.texi the oddest part I found, was the section on comments. To me comments have nothing to do with objects, and while tangentially related to read syntax they are not part of any particular object's read syntax. i tend to think that comments belong with objects in the same way a picture contains both background and foreground. another metaphor that comes to mind is that comments is the nil to the rest of the objects' non-nil; the truth of a piece of code is not completely describable subtracting one or the other. thi ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: where-is-internal question
(define-key some-map [remap self-insert-command] 'my-command) This really should be for help-gnu-emacs, but, since you've already been so helpful... What is a good way to undo this remapping? Looking at the doc (info), it looks as if I cannot then do this: (define-key some-map [remap my-command] 'self-insert-command) (The doc says that remapping only works through a single level and that you can only remap an ordinary binding.) IOW, if I have a mode (e.g. minor mode) that does the remapping, what's a good way to put things back the way they were in `some-map' (assuming that map exists independently of the mode)? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: where-is-internal question
(define-key some-map [remap self-insert-command] 'my-command) What is a good way to undo this remapping? Looking at the doc (info), it looks as if I cannot then do this: (define-key some-map [remap self-insert-command] nil) -- Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Check in MH-E changes
If you have outstanding changes to MH-E that you intended to check in soon (to Savannah *or* SourceForge), today would be a good time. I'm currently working on restructuring the MH-E sources (on the SourceForge side) to work with the sources in the Savannah repository. When I'm ready, I'll merge any Emacs MH-E changes back into SourceForge, make a release at SourceForge with the new structure, and then fold that release back into Emacs. I'll send out a note immediately preceding so ask that folks not check in MH-E changes during that sequence. If you don't check your changes in today, you shouldn't have any problem doing so afterward. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
Is there a way to fix this for non-X users of emacs ? If you have the X libraries you can compile with X and use it in terminal mode (emacs -nw). Sorry, I don't understand: what is that ``this'' which you want to be fixed? If that's the tmm problem, it _will_ be fixed, we just need to find a way to do that without breaking whatever it was that my change back in 2004 fixed. Problem is F10-O no longer works in emacs configured with --without-x . And as far as I can tell its a more recent change than in 2004 as I am using emacs cvs for long and this problem is new. Have you've always configured without X or just used Emacs in terminal mode? Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
New mirrors for my Emacs arch archive: [EMAIL PROTECTED]
For those of you who were using my arch archive, [EMAIL PROTECTED] to track Emacs sources: My previous publicly available mirror (at push.sourcecontrol.net) has been stale for quite some time, due to hardware failures. I just got two new mirrors, which are being properly updated: (1) http://mirrors.sourcecontrol.net/[EMAIL PROTECTED] (2) http://arch.orebokech.com/[EMAIL PROTECTED] [ (1) was previously available, but was out of date, as it used to mirror the old stale archive; now it should be updated properly. ] Thanks to Romain Francoise for providing the arch.orebokech.com mirror, and thanks to Tollef Fog Heen for telling about the mirrors.sourcecontrol.net push service and helping me to get it working. -miles -- Nah, there's no bigger atheist than me. Well, I take that back. I'm a cancer screening away from going agnostic and a biopsy away from full-fledged Christian. [Adam Carolla] ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: New mirrors for my Emacs arch archive: [EMAIL PROTECTED]
I wrote: I just got two new mirrors, which are being properly updated: (1) http://mirrors.sourcecontrol.net/[EMAIL PROTECTED] (2) http://arch.orebokech.com/[EMAIL PROTECTED] ... Thanks to Romain Francoise for providing the arch.orebokech.com mirror, and thanks to Tollef Fog Heen for telling about the mirrors.sourcecontrol.net push service and helping me to get it working. Also thanks to James Blackwell (and I gather, canonical.com these days) for the sourcecontrol.net mirror services, past and present, and for providing a helping hand. -miles -- Do not taunt Happy Fun Ball. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: where-is-internal question
(define-key some-map [remap self-insert-command] 'my-command) What is a good way to undo this remapping? (define-key some-map [remap self-insert-command] nil) Thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: where-is-internal question
IIRC, the problem probably is that with command remapping, where-is-internal in 22.x has to lookup the key binding for each command to see if it remapped -- in the normal case (where a command only has a few bindings), the penalty is neglible, but for self-insert-command specifically, that will be time consuming. Could you show me where the code is that does this? Maybe I can speed it up with some sort of memoization. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Paragraphs (and sentences) in Emacs cannot span pages.
But this is one way in which Emacs's pages/paragraphs/sentences don't correspond with what people might expect, On the contrary, it is exactly what people expect--for hand-edited files. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Patch: Follow convention for reading with the minibuffer.
I *much* prefer Enter the answer (default 42): which is what is used by pretty much everything except for C-x b (where the default is after the colon by accident AFAICT). It is embarrassing how dim my memory is getting. I looked at C-x b rather than go by memory, and I didn't remember that other things were different. Putting the colon at the end is definitely better. Can someone fix C-x b to work that way? Emilio, I apologize for the confusion I caused and for the waste of time that resulted. Thank you for offering to make things follow the convention that I mistakenly redacted. PS: Actually I even prefer Enter the answer [42]: because minibuffer width is limited. Now that the minibuffer prompt can be continued, saving space there is less important than it would have been before. And the word default will serve to explain to new users. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] access [additional default values] from the list [of default values]. Yes, that's what I had in mind. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
It seems to be due to this change: 2004-03-13 Eli Zaretskii [EMAIL PROTECTED] * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined. I guess it hasn't been noticed before because, although people may use tmm, most use a version of Emacs thats compiled with X (or at least HAVE_MENUS). I haven't reverted this change because it must be there for a reason. Eli? Eli is surely right that this change fixed a bug. However, this shows that the bug has to be fixed a different way. Perhaps the best way to find out what the bug was is to revert the change; then someone will see that bug again, and someone can write a new fix for it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: compile.el::grep-program - should it use egrep instead of grep?
There is (defvar grep-program egrep ...) in compile.el, No there isn't. The default value of grep-program is grep or zgrep. What version are you looking at? but in some systems the grep is the old one, which does not provide the extended syntax. Would it be possible to set this by default to 'egrep'? Sorry, no. Emacs's regexp syntax is based on the grep syntax rather than the egrep syntax. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
From: Richard M. Stallman [EMAIL PROTECTED] Date: Wed, 07 Sep 2005 22:41:46 -0400 Cc: [EMAIL PROTECTED], emacs-devel@gnu.org Perhaps the best way to find out what the bug was is to revert the change; then someone will see that bug again, and someone can write a new fix for it. No, this is IMHO a bad way: the chances of that someone to see that bug could be small, depending on what was the configuration in which it was found back then. It is much better to read the emacs-devel discussions related to my change and understand what was the bug I fixed. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
From: Nick Roberts [EMAIL PROTECTED] Date: Thu, 8 Sep 2005 10:04:25 +1200 Cc: [EMAIL PROTECTED], emacs-devel@gnu.org Please don't take out this change without understanding what it was fixing in the first place. I think this is the right fix. Please describe the reasons why you think this is the right fix. (I'm assuming you've read the discussions from 2004 that led to the original changes.) Actually I think the problem was caused by Kim's change: 2004-03-11 Kim F. Storm [EMAIL PROTECTED] * Makefile.in:... (XMENU_OBJ) [HAVE_MENUS]: Move declaration to proper place. That change was made for a reason as well: some problem on Carbon. We need to understand that problem, to be sure your change will not reintroduce it. I hope that the explanations I asked for above will clarify this (I still didn't have time to re-read those past discussions and retrace what problems we were trying to fix.) In addition, we need to explain why the OP says he started to see the problem only recently. The preamble for xmenu.c says: /* X Communication module for terminals which understand the X protocol. but xmenu.c is more general than that and compiles without X. Even its name is misleading (as with xdisp.c which also compiles without X). That's history: xmenu.c was originally written for X, but then menu support was added to the DOS port and later came tmm. If you think the name xmenu tricked Kim and myself into thinking it's only for X, that was not the reason. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tiny patch to ange-ftp
Sorry for the late reply. I seem to have fixed all the problems that I grasp. In [EMAIL PROTECTED] Stefan Monnier wrote: Your patch looks like a good first step. I would check `full' rather than (file-name-directory file) in order to determine whether to do a full dir listing or to extract a single line. I did so. Also I hoped that we would be able to use the cache so as to avoid doing the full-listing+extract-line thingy repeatedly. Using ange-ftp-get-files should do the trick here. But that can be changed later on. Well, using the cache seems useless for the remote file which is newly uploaded. Am I wrong? I tried some ways but I didn't get the right way to use those functions so far. Given that this fixes the problem mentioned in ange-ftp-send-cmd and should be orthogonal to the problem of hash marks, I suggest we install your patch. Any objections? I noticed `ange-ftp-process-filter' does not extract all hash marks because of the too strict regexp and it breaks the synchronous operation while at least uploading files. Here's a new patch: 2005-09-08 Katsumi Yamaoka [EMAIL PROTECTED] (tiny change) * net/ange-ftp.el (ange-ftp-process-filter): Fix regexp to extract hash marks. (ange-ftp-insert-directory): Work with a single file listing. --8---cut here---start-8--- *** ange-ftp.el~Thu Aug 11 21:55:21 2005 --- ange-ftp.el Thu Sep 8 03:57:18 2005 *** *** 1656,1662 ;; handle hash mark printing (and ange-ftp-process-busy ! (string-match \\`#+\\' str) (setq str (ange-ftp-process-handle-hash str))) (comint-output-filter proc str) ;; Replace STR by the result of the comint processing. --- 1656,1662 ;; handle hash mark printing (and ange-ftp-process-busy ! (string-match #+ str) (setq str (ange-ftp-process-handle-hash str))) (comint-output-filter proc str) ;; Replace STR by the result of the comint processing. *** *** 2332,2347 ;; This works around a misfeature of some versions of netbsd ftpd ;; where `ls' can only take one argument: either one set of flags ;; or a file/directory name. - ;; FIXME: if we're trying to `ls' a single file, this fails since we - ;; can't cd to a file. We can't fix this problem here, tho, because - ;; at this point we don't know whether the argument is a file or - ;; a directory. Such an `ls' is only every used (apparently) from - ;; `insert-directory' when the `full-directory-p' argument is nil - ;; (which seems to only be used by dired when updating its display - ;; after operating on a set of files). We should change - ;; ange-ftp-insert-directory so that this case is handled by getting - ;; a full listing of the directory and extracting the line - ;; corresponding to the requested file. (unless (equal cmd1 .) (setq result (ange-ftp-cd host user (nth 1 cmd) 'noerror))) (setq cmd1 cmd3))) --- 2332,2337 *** *** 4498,4504 (if wildcard (let ((default-directory (file-name-directory file))) (ange-ftp-ls (file-name-nondirectory file) switches nil nil t)) !(ange-ftp-ls file switches full (ange-ftp-real-insert-directory file switches wildcard full (defun ange-ftp-dired-uncache (dir) --- 4488,4510 (if wildcard (let ((default-directory (file-name-directory file))) (ange-ftp-ls (file-name-nondirectory file) switches nil nil t)) !;; That `full' is nil means we're going to do `ls' for !;; a single file in the current directory. !(if full !(ange-ftp-ls file switches full) ! ;; Get a full listing of the current directory and ! ;; extract the line corresponding to `file'. ! (when (string-match d\\' switches) !;; Remove d which dired added to `switches'. !(setq switches (substring switches 0 (match-beginning 0 ! (setq tem (ange-ftp-ls . switches nil)) ! (let ((case-fold-search nil)) !;; Assume the file name which a single space precedes !;; appears at the end of a line. !(if (string-match (concat ^.+[^ ] (regexp-quote file) $) ! tem) !(concat (match-string 0 tem) \n) ! )) (ange-ftp-real-insert-directory file switches wildcard full (defun ange-ftp-dired-uncache (dir) --8---cut here---end---8--- ___ Emacs-devel mailing list Emacs-devel@gnu.org
Re: Options menu is broken on CVS
I think this is the right fix. Please describe the reasons why you think this is the right fix. menu-updating-buffers is defined in syms_of_xmenu (). Currently syms_of_xmenu is only called in emacs.c if HAVE_MENUS is true. menu-updating-buffers is needed even if Emacs is configured without X (on GNU/Linux at least) but in this case HAVE_MENUS is not defined. xmenu.c is needed even HAVE_X_WINDOWS is not defined so I've moved it outside the conditional requiring it. (I'm assuming you've read the discussions from 2004 that led to the original changes.) I might not have followed it all but your change seemed to cover Carbon Emacs which it still does: #ifndef HAVE_CARBON XMENU_OBJ = xmenu.o #endif Now I've moved it outside #ifdef HAVE_X_WINDOWS you might need to add another condition for when w32menu.o is used, I'm not sure. Actually I think the problem was caused by Kim's change: 2004-03-11 Kim F. Storm [EMAIL PROTECTED] * Makefile.in:... (XMENU_OBJ) [HAVE_MENUS]: Move declaration to proper place. That change was made for a reason as well: some problem on Carbon. We need to understand that problem, to be sure your change will not reintroduce it. I hope that the explanations I asked for above will clarify this (I still didn't have time to re-read those past discussions and retrace what problems we were trying to fix.) I didn't find the discussion that led to this change. It might have been part of a general tidying process. In addition, we need to explain why the OP says he started to see the problem only recently. I've tried to explain that in another post: more calls to menu-updating-frame have been made in menu-bar.el (26/08/05). The preamble for xmenu.c says: /* X Communication module for terminals which understand the X protocol. but xmenu.c is more general than that and compiles without X. Even its name is misleading (as with xdisp.c which also compiles without X). That's history: xmenu.c was originally written for X, but then menu support was added to the DOS port and later came tmm. If you think the name xmenu tricked Kim and myself into thinking it's only for X, that was not the reason. I don't have an opinion on whether you or Kim were tricked, just that the description is misleading and that xmenu.c is needed even HAVE_X_WINDOWS is not defined. Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Parmacy Offr M eeddications
PrAmVaLeCeXaMeViCiUl opbilivilenariagaltr eciaenumtrabrexxdiaraisam $3$3$1 .75.33.21 http://www.parkilotoloodcom ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tiny patch to ange-ftp
In [EMAIL PROTECTED] Katsumi Yamaoka wrote: *** ange-ftp.el~ Thu Aug 11 21:55:21 2005 --- ange-ftp.el Thu Sep 8 03:57:18 2005 *** *** 1656,1662 ;; handle hash mark printing (and ange-ftp-process-busy !(string-match \\`#+\\' str) (setq str (ange-ftp-process-handle-hash str))) (comint-output-filter proc str) ;; Replace STR by the result of the comint processing. --- 1656,1662 ;; handle hash mark printing (and ange-ftp-process-busy !(string-match #+ str) (setq str (ange-ftp-process-handle-hash str))) (comint-output-filter proc str) ;; Replace STR by the result of the comint processing. Please replace #+ with the same ^#+$ as what is used in Emacs 21.4. While \\`#+\\' is intended to match the whole string, `str' often contains newline characters. This is the true cause in which this function breaks the synchronous operation. I guess someone changed it mistakenly. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
