Re: grep-use-null-device
`compilation-start' needs to check if the process is running before calling `process-send-eof': That's odd. AFAICT no blobking operation takes place between the start-process and the process-send-eof, so the process-status should still be `run' no matter how quickly the process exits (because Emacs shouldn't process the SIGCHLD it receives until later). What am I missing? The process exits during execution of create_process. The gdb log below with a breakpoint on sigchld_handler demonstrates what really happens: Breakpoint 4, sigchld_handler (signo=17) at process.c:6249 6249 XSETINT (p-raw_status_low, u.i 0x); (gdb) n 6250 XSETINT (p-raw_status_high, u.i 16); (gdb) n 6253 if ((WIFSIGNALED (w) || WIFEXITED (w)) (gdb) n 6260 FD_CLR (XINT (p-infd), input_wait_mask); (gdb) n 6261 FD_CLR (XINT (p-infd), non_keyboard_wait_mask); (gdb) p w $1 = 512 -- WIFEXITED (gdb) bt #0 sigchld_handler (signo=17) at process.c:6261 #1 signal handler called #2 0x4031f784 in sigprocmask () from /lib/libc.so.6 #3 0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153 #4 0x0817a97d in Fstart_process (nargs=5, args=0xbfffea94) at process.c:1695 ... (gdb) fr 3 #3 0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153 2153 sigprocmask (SIG_SETMASK, procmask, 0); -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
yet again: problems with emacs-wiki and encodings
Hi all some time ago i reported about strange things with Emacs on Windows and emacs-wiki package I use GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC, and current version of emacs-wiki (from cvs) My problem is that my current lang env is Russian, but emacs-wiki pages in utf-8. To properly open this files i put record in file-encoding-system-alist, and when i open file manually (or with code in *scratch* buffer) it opened in right encoding. but if i use emacs-wiki-find-file (that asks for page name) and open it with find-file, then page is in wrong encoding here is information about my settings In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil 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: RUS locale-coding-system: cp1251 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: mml-mode: t delete-selection-mode: t show-paren-mode: t display-time-mode: t desktop-save-mode: t encoded-kbd-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol abbrev-mode: t -- With best wishes, Alex Ott Jet Infosystems, http://www.jetinfosoft.ru/ +7 (095) 411 76 01 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
(no subject)
Lennart Borgman wrote: I have added them to the web page now. Personally I am still in favour of you first suggestion and my suggestion with M-x and the gnu head. One of the reasons is that the screen normally contains so much horizontal and vertical elements. Your second suggestion with the parenthesis breaks this too and I like that one also. Hi, Attached you will find a new icon idea. I must confess that it is my favorite icon for now ;-) It looks quite good scaled to 16x16. Sincerely, David /home/ponce/.icons/hicolor/48x48/apps/emacs-logo-48x48.png Description: PNG image ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
AW: (no subject)
Title: AW: (no subject) IMHO a very felicitous design... Klaus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] im Auftrag von David PONCE Gesendet: Mi 31.08.2005 12:14 An: [EMAIL PROTECTED] Cc: emacs-devel@gnu.org Betreff: (no subject) Lennart Borgman wrote: I have added them to the web page now. Personally I am still in favour of you first suggestion and my suggestion with M-x and the gnu head. One of the reasons is that the screen normally contains so much horizontal and vertical elements. Your second suggestion with the parenthesis breaks this too and I like that one also. Hi, Attached you will find a new icon idea. I must confess that it is my favorite icon for now ;-) It looks quite good scaled to 16x16. Sincerely, David ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: AW: (no subject)
[EMAIL PROTECTED] writes: IMHO a very felicitous design... Klaus The E, the most prominent feature, is both out of character as well as ugly. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: AW: (no subject)
David Kastrup wrote: [EMAIL PROTECTED] writes: IMHO a very felicitous design... Klaus The E, the most prominent feature, is both out of character as well as ugly. It seems like for some it then makes the web page with the icons more ugly and for some more pretty: http://ourcomments.org/Emacs/NewIcons.html ;-) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
yet again: problems with emacs-wiki and encodings
Hi all some time ago i reported about strange things with Emacs on Windows and emacs-wiki package I use GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC, and current version of emacs-wiki (from cvs) My problem is that my current lang env is Russian, but emacs-wiki pages in utf-8. To properly open this files i put record in file-encoding-system-alist, and when i open file manually (or with code in *scratch* buffer) it opened in right encoding. but if i use emacs-wiki-find-file (that asks for page name) and open it with find-file, then page is in wrong encoding here is information about my settings In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil 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: RUS locale-coding-system: cp1251 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: mml-mode: t delete-selection-mode: t show-paren-mode: t display-time-mode: t desktop-save-mode: t encoded-kbd-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol abbrev-mode: t -- With best wishes, Alex Ott Jet Infosystems, http://www.jetinfosoft.ru/ +7 (095) 411 76 01 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: yet again: problems with emacs-wiki and encodings
Sorry - i forgot to attach images with right and brocken text Alex Ott wrote: Hi all some time ago i reported about strange things with Emacs on Windows and emacs-wiki package I use GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC, and current version of emacs-wiki (from cvs) My problem is that my current lang env is Russian, but emacs-wiki pages in utf-8. To properly open this files i put record in file-encoding-system-alist, and when i open file manually (or with code in *scratch* buffer) it opened in right encoding. but if i use emacs-wiki-find-file (that asks for page name) and open it with find-file, then page is in wrong encoding here is information about my settings In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil 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: RUS locale-coding-system: cp1251 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: mml-mode: t delete-selection-mode: t show-paren-mode: t display-time-mode: t desktop-save-mode: t encoded-kbd-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol abbrev-mode: t -- With best wishes, Alex Ott Jet Infosystems, http://www.jetinfosoft.ru/ +7 (095) 411 76 01 ___ 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 the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? By convention, M-n is supposed to insert _the default_. I do not want to make exceptions to that. We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. Now is not the time to implement this, but I'm interested in hearing if there are any objections to the idea. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
Neither of these functions returns `\n'. And `\n' is not an alternative for a literal newline. I am not sure what distinction you're making. `\n' is alternative Lisp syntax for a literal newline. Which one we use in writing a Lisp string is arbitrary, except when we're talking about print functions which use one or the other. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: should doc on case-fold-search mention that there are other such vars also?
I will doc this. Thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: jit-lock doesn't honor font-lock-lines-before
Because this means that every time I insert one character, redisplay would refontify `font-lock-lines-before' in addition to the current line. That might be somewhat slower--but how much? Would it even be noticeable? jit-lock's after-change hook would only reset the fontified property to nil. Whether and when these lines are refontified would be _also_ decided by the redisplay engine. It's not decided by the redisplay engine alone. When calls for a certain region to be fontified, jit-lock could be changed to look at the previous line too. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
What is a paragraph in Emacs? I can't find a @dfn{paragraph} anywhere
in the Emacs/Elisp manuals.
Do we need one? Certainly in the Emacs Lisp manual we don't.
It is a high-level concept used in just a few user-level commands.
Defining paragraphs better might be useful in the Emacs Manual.
Would this really make a difference for users, though? I am not sure.
Right now the manual effectively takes for granted that users
know what a paragraph is. Is this a problem?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Failing filename completion in large NFS-mounted directories
I have been having a problem whereby filename completion in a large
directory which lives over a slow NFS link sometimes fails to complete
filenames which are not near the top of the directory (according to ls
-U).
The machine exhibiting this problem gives
% uname -a
SunOS lukekelly 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R Solaris
I Google'd and came across Stefan Monnier's email:
http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00643.html
including this patch to dired.c:
--- dired.c 11 aoû 2005 05:27:35 -0400 1.117
+++ dired.c 14 aoû 2005 02:44:01 -0400
@@ -224,7 +224,7 @@
#ifdef EAGAIN
if (dp == NULL errno == EAGAIN)
- continue;
+ { QUIT; continue; }
#endif
if (dp == NULL)
@@ -533,6 +533,10 @@
dp = (*readfunc) (d);
#else
dp = readdir (d);
+#endif
+#ifdef EAGAIN
+ if (dp == NULL errno == EAGAIN)
+ { QUIT; continue; }
#endif
if (!dp) break;
and tried it, but it didn't help. truss suggested that the getdents64()
system call was being interrupted by SIGALRM, and putting some printf()s
into dired.c revealed that readdir() sometimes returned NULL with errno
set to EINTR rather than EAGAIN. I modified Stefan's test so that it's
if (dp == NULL (errno == EAGAIN || errno == EINTR))
rather than just
if (dp == NULL errno == EAGAIN)
in both places, and this seems to have fixed my problem. I also added
an assignment errno = 0; into file_name_completion() to match what's
done in directory_files_internal() and what the Solaris doc for
readdir() suggests.
Might this be useful more generally? I'm afraid I don't have access to
very many systems so I don't know which systems return EAGAIN and which
EINTR (the system call itself returns ERESTART so perhaps that should be
checked for too?). I guess this could become hairy but if there's a way
to do this portably it might fix this problem for all users.
Thanks,
Ben.
[I originally emailed Stefan directly and he suggested I passed it on to
the list.]
___
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 the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? By convention, M-n is supposed to insert _the default_. I do not want to make exceptions to that. We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. Now is not the time to implement this, but I'm interested in hearing if there are any objections to the idea. My opinion: Keep the history list (and ways of accessing it) separate from the default value (and ways of accessing it). M-n and M-p are for the history list. M-n already pulls the default value into the minibuffer and adds it (possibly edited) to the history list. This is enough connection between the two. In this case, you seem to want the default value to be the _previous_ history value (so that empty input searches the same thing again). This means that M-n, M-p, and empty input will all do more or less the same thing: use the last (i.e. previous) history value. That's a lot of convenience for accessing that one value, but it leaves no easy way to use the word/symbol at point - which several people have mentioned is an obvious thing to want to do with `occur'. For `occur', I would use the word/symbol at point as the default value, and let people use `M-p RET' to get the last history value. Consistent, and not terribly inconvenient, IMO (one extra keystroke: M-p). Wrt your general proposal - Given that you don't want the default value to be automatically inserted into the minibuffer (my preference), you should stick with M-n to insert it. I think extending this to a second M-n, for a possible second default value would be confusing, with little reward. However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. A reasonable (default) set of default-value candidates would be those in `minibuffer-completion-table' (perhaps as filtered by `minibuffer-completion-predicate'). This is what several existing libraries do, including my icicles library. You might look to such libraries for ideas on possibilities (food for thought). The icicles code is here: http://www.emacswiki.org/cgi-bin/emacs/icicles.el. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
I am not sure what distinction you're making. `\n' is alternative Lisp syntax for a literal newline. Which one we use in writing a Lisp string is arbitrary, except when we're talking about print functions which use one or the other. I meant that these functions return only a literal newline, not `\n'. It might be confusing for readers of the reference manual when they will try out an example and see that its real output is different from the documented output in regard to newlines. They might start to search for an (AFAIK, nonexistent) option that toggles a literal newline or `\n' in return values, or even to fill a bug report. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
From: Richard M. Stallman [EMAIL PROTECTED] Date: Wed, 31 Aug 2005 10:36:53 -0400 Cc: emacs-devel@gnu.org Right now the manual effectively takes for granted that users know what a paragraph is. Is this a problem? IMHO, we only need to define what's a paragraph if its Emacs definitions differs significantly from what a naive user will expect. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: patch for woman (woman-topic-at-point)
Drew Adams writes: Why don't we let `test-completion' return the completion (string) argument, whenever the return value is non-nil? I could imagine this is for consistency with `try-completion', which returns a string with the longest string common to all matches or t if the given string was already an exact match. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
Hi, Emacs!
On Wed, 31 Aug 2005, Richard M. Stallman wrote:
What is a paragraph in Emacs? I can't find a @dfn{paragraph}
anywhere in the Emacs/Elisp manuals.
Do we need one? Certainly in the Emacs Lisp manual we don't.
It is a high-level concept used in just a few user-level commands.
I disagree most strongly here. Hackers need to know how to set up
paragraph-s\(tart\|eparate\) so that they can make the canonical
paragraph commands behave the way they want them to.
For example, I was tearing my hair out in frustration a couple of years
back, trying to get the sentence/paragraph movement and filling stuff to
work properly in CC Mode. (Comment prefixes and escaped newlines in
strings complicate things.) In the end, I had to edebugger my way
through forward-paragraph to get a handle on things.
For another example, it would be nice if M-q in a Shell Script mode
comment would regard a line like #as a blank line (i.e. paragraph
separator). (Maybe this has already been done for 22.1 - if so,
apologies.) This would be easier, I think, with a clear definition of a
paragraph.
I think it would be far easier to understand a description like
The paragraph functions recognise the start of a paragraph as
expression containing p-start and p-separate and the end of a
paragraph as another such expression.
than the ones saying p-start matches and p-separate matches
Defining paragraphs better might be useful in the Emacs Manual.
I think they should either be properly defined there or the references to
paragraph-s\(tart\|eparate\) replaced by an xref to a description in the
Elisp manual. The logical absurdity (beginningless paragraphs)
implicit in the manual surely should be sorted out one way or the other.
Would this really make a difference for users, though? I am not sure.
Right now the manual effectively takes for granted that users know what
a paragraph is. Is this a problem?
I think Users will know exactly what a paragraph is until they've seen
the descriptions of paragraph-start and paragraph-separate, after which
they'll not be so sure any more. ;-)
#
Looking at @node Standard Regexps in Elisp's searching.texi, perhaps
the node's title should be amended. What does Standard Regular
Expressions used in Editing really say? Well, Standard and used in
Editing both seem content-free, so all the title really means is A few
regexps.
The four regexps documented on this page all define chunks of
natural-language text: paragraphs, pages and sentences. So how about
renaming this @section something like Sentences, Paragraphs and Pages,
and making the focus of the @node the definition of these things in terms
of the regexps, rather than the regexps themselves?
It goes without saying, I'm ready and willing to make these amendments
myself.
--
Alan Mackenzie (Munich, Germany)
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
(message (format File %s file))
A *lot* of source code contains easy-to-miss bugs like this: (message (format File: %s file)) which will lead to erers like these: Debugger entered--Lisp error: (error Not enough arguments for format string) if the filename contains %. I plan to go through the entire source code, and only in cases I am sure, fix these bugs (which mostly involves adding a %s% after `message', or getting rid of the unnecessary format call following (message). (I will be spotting these bugs with the aid of a regexp search tool). I have committ access, but this is the first time I am planning to make any real changes (which happen te be large-scale too), so I thought I should ask for permission as well as any suggestions before doing so. For each fix, I would add a proper changlog entry saying something like: message format spec fix. Here are a few examples: iswitchb: (message (format no buffer matching `%s' buf) printing.el: (message (error-message-string data) flyspell: (message (format duplicate `%s' word))) gud: (message (format Error parsing file %s. file)) I will leave any code alone unless I am absolutely sure of what I am doing. Here's an example of when I am not sure: (message (substitute-command-keys Press \\[wdired-finish-edit] when finished \ or \\[wdired-abort-changes] to abort changes))) Can the above code ever lead to errors? Either way, isn't it safe to insert a %s after message anyways? All this almost makes one wonder if it would make sense to provide a msg: (defun msg (arg) (message %s arg)) A lot of times, an author accidentally writes the code with msg in mind rather than message. This error is pervasive, especially if you look at all the add-on code (not part of emacs). I bet there is aon average, at least one bug per file. Sincerely, DG http://gnufans.net/ -- ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: (message (format File %s file))
Here's an example of when I am not sure: (message (substitute-command-keys Press \\[wdired-finish-edit] when finished \ or \\[wdired-abort-changes] to abort changes))) Can the above code ever lead to errors? Yes. Either way, isn't it safe to insert a %s after message anyways? The only case where it's not safe is when the existing code already does %-escaping, in which case adding the %s will cause any % sign in the output string to appear twice. That's extremely rare and I suspect it only happens in cases where the sole arg to message is a string constant (which thus contains a double % sign). All this almost makes one wonder if it would make sense to provide a msg: (defun msg (arg) (message %s arg)) A lot of times, an author accidentally writes the code with msg in mind rather than message. This error is pervasive, especially if you look at all the add-on code (not part of emacs). I bet there is aon average, at least one bug per file. In the past I suggested to make (message ARG) automatically behave like (message %s ARG) and AFAIK the only prolem with that was a few rare case like (message Compiling list...( 0%%)) and those problems are easy to fix. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: (message (format File %s file))
Stefan Monnier [EMAIL PROTECTED] writes: In the past I suggested to make (message ARG) automatically behave like (message %s ARG) and AFAIK the only prolem with that was a few rare case like (message Compiling list...( 0%%)) and those problems are easy to fix. ah, nice or it could do this: (message arg) behaves like (message %s arg) only if the arg has no %%. that way, one wouldn't have to break backward compatibility... .. or one could just provide an extra (msg) DG http://gnufans.net/ -- ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
MORE.STUFF calculator.el moved
The url for calculator.el in MORE.STUFF is a 404, it seems to have moved to, 2005-09-01 Kevin Ryde [EMAIL PROTECTED] * MORE.STUFF: Update url for calculator.el. --- MORE.STUFF.~1.51.~ 2005-08-28 10:15:20.0 +1000 +++ MORE.STUFF 2005-09-01 09:58:35.208784280 +1000 @@ -43,7 +43,7 @@ * BS: URL:http://www.geekware.de/software/emacs/index.html - * Calculator: URL:http://www.cs.cornell.edu/eli/misc/calculator.el + * Calculator: URL:http://www.barzilay.org/misc/calculator.el * CC mode: URL:http://cc-mode.sourceforge.net/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Info node (emacs)Faces
The info page for Faces says: `menu' This face determines the colors and font of Emacs's menus. Setting the font of LessTif/Motif menus is currently not supported; attempts to set the font are ignored in this case. I believe this paragraph also applies to GTK. In fact, maybe under all X toolkits (the only other one is Athena). -- Karl 2005-08-31 19:43 ___ 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
We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. This is already implemented by a small 9-line patch I proposed in http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg01755.html It allows M-n in the minibuffer to insert input from the list of default values. Each consecutive M-n inserts a new default value from the list. For `grep' and `occur' there are at least five useful default values: 1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) 4. last isearch regexp - (car regexp-search-ring) 5. last kill from the kill ring - (current-kill 0) With this patch, it is possible to make a list of all these default values accessible in the minibuffer via M-n. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
