Re: Should killing a help or compile buffer also delete the window?
I'd like C-x 4 0 to just do its job without mithering me with kill buffer `foo'? (yes or no), unless it's an actual changed buffer that's getting killed. Today's GNU Emacs CVS snapshot, Mon, 2005 Apr 25 09:44 UTC GNU Emacs 22.0.50.14 (i686-pc-linux-gnu, GTK+ Version 2.6.4) started with /usr/local/src/emacs/src/emacs -Q -D does not ask me that question in either situation, changed buffer or not. It just kills the buffer and the window. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL slows
[After running the same RMAIL for several days, deletions slow; but not immediately. Using the `emacs/src/emacs' executable of 2005 Mar 30.] I think you said it was spending most of the time in regexp matching. Is that right? If so, can you determine what regexp it spends most of its time matching? ... Here are three instances. Each instance involved deleting 50 messages each and suspending in the middle of the action for GDB. In instances 1 and 3, `xbacktrace' showed rmail-reformat-message. Instance 2 did not. In instance 1, `backtrace' (not `xbacktrace') showed adjust_markers_for_delete; the other two instances showed re_match_2_internal. ## Instance 1 (gdb) xbacktrace delete-char rmail-reformat-message rmail-show-message rmail-summary-goto-msg rmail-summary-delete-forward call-interactively (gdb) bt #0 adjust_markers_for_delete (from=6865840, from_byte=6865840, to=6865841, to_byte=6865841) at insdel.c:353 #1 0x0814113b in del_range_2 (from=6865840, from_byte=6865840, to=6865841, to_byte=6865841, ret_string=0) at insdel.c:1946 #2 0x08140d94 in del_range_1 (from=6865840, to=6865841, prepare=1, ret_string=8310629) at insdel.c:1813 ## Instance 2 (gdb) xbacktrace re-search-forward goto-address-fontify goto-address run-hooks rmail-show-message rmail-summary-goto-msg rmail-summary-delete-forward call-interactively (gdb) bt #0 re_match_2_internal (bufp=0x83291ac, string1=0x41152088 From: Service de distribution du courrier [EMAIL PROTECTED]\nSubject: =?ISO-8859-15?Q?Notification_d'=E9tat_de_la_distribution?=\nTo: [EMAIL PROTECTED]: Sun, 24 Apr 2005 07:07:49 +020..., size1=202, string2=0x41152fb3 \nCe message MIME en plusieurs parties contient une notification d'\201\303\201\251tat de distribution.\nSi vous voyez ce texte, il est possible que votre client de courrier ne puisse pas\nlire les messages MIME for..., size2=1856, pos=2013, regs=0x8320268, stop=2058) at regex.c:4944 #1 0x08164102 in re_search_2 (bufp=0x83291ac, str1=0x41152088 From: Service de distribution du courrier [EMAIL PROTECTED]\nSubject: =?ISO-8859-15?Q?Notification_d'=E9tat_de_la_distribution?=\nTo: [EMAIL PROTECTED]: Sun, 24 Apr 2005 07:07:49 +020..., size1=202, str2=0x41152fb3 \nCe message MIME en plusieurs parties contient une notification d'\201\303\201\251tat de distribution.\nSi vous voyez ce texte, il est possible que votre client de courrier ne puisse pas\nlire les messages MIME for..., size2=1856, startpos=2013, range=45, regs=0x8320268, stop=2058) at regex.c:4328 ## Instance 3 (gdb) xbacktrace re-search-forward rmail-clear-headers rmail-reformat-message rmail-show-message rmail-summary-goto-msg rmail-summary-delete-forward call-interactively (gdb) bt #0 0x081660e5 in re_match_2_internal (bufp=0x832907c, string1=0x410f0d43 Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \Melba Andrade\ [EMAIL PROTECTED]\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin [EMAIL PROTECTED]\nMIME-version: 1.0\nX-Ma..., size1=0, string2=0x410f0d43 Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \Melba Andrade\ [EMAIL PROTECTED]\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin [EMAIL PROTECTED]\nMIME-version: 1.0\nX-Ma..., size2=557, pos=156, regs=0x8320268, stop=0) at regex.c:5631 #1 0x08164102 in re_search_2 (bufp=0x832907c, str1=0x410f0d43 Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \Melba Andrade\ [EMAIL PROTECTED]\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin [EMAIL PROTECTED]\nMIME-version: 1.0\nX-Ma..., size1=0, str2=0x410f0d43 Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \Melba Andrade\ [EMAIL PROTECTED]\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin [EMAIL PROTECTED]\nMIME-version: 1.0\nX-Ma..., size2=557, startpos=156, range=401, regs=0x8320268, stop=557) at regex.c:4328 -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Russian version of Emacs Tutorial is updated
From: Alex Ott [EMAIL PROTECTED] Date: Mon, 25 Apr 2005 09:42:09 +0400 Here is updated version of Emacs tutorial (russian version). thanks, installed. thi ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
$BBg;j5^$*4j$$$7$^$9(B
$B5.J}$NCO0h$G:#8=:_5U1g=u4uK[EMAIL PROTECTED],(B12$BL$$$^$9!#(B $BL5NA$G$9$N$G4v$i$G$b$4MxMQ2$5$$!#(B http://awg.webchu.com/?springd $B%a!%k$Nu?.$r5qH]$9$kl9g$O25-(BURL$B$KJV?.2$5$$(B [EMAIL PROTECTED] ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Should killing a help or compile buffer also delete the window?
Daniel Brockman daniel at brockman.se writes: I don't want to spend time on thinking about it because I think it is unlikely to get anywhere. To be honest, I'm growing less and less confident myself that it would be the best default behavior. While many people would definitely find it convenient, I suspect others would just be confused or annoyed. I have the same problem, yet I want the behavior that you suggested in most cases. Here's what we do in AquaMacs (an Emacs distro with UI customizations for the Mac). It's quite a hack considered that the solution is not generic, but lists specific buffer names that have their own behavior. However, we don't only close windows for killed buffers, but we also create new frames (and thus a new window) for many types of newly buffers. But we can only do so selectively, because a lot of modes open new windows with new buffers that are not supposed to go into a new frame (consider ispell). So this is the solution that I've arrived at after playing around a bit; but I don't consider it very universal. It's a difficult problem as it has been said before. === (setq one-buffer-one-frame t) (defun open-in-other-frame-p (buf default) (set 'bufname (if (eq (type-of buf) 'string) buf (buffer-name buf))) ;; i guess we should use ;; with special-display-regexps instead (if one-buffer-one-frame (if (string-match [ ]*\\*.*\\*[ ]* bufname) (if (or (equal \*Messages\* bufname) (equal \*info\* bufname) (equal \*scratch\* bufname) (equal \*Help\* bufname) (equal \*Backtrace\* bufname) (string-match [ ]*\*Customize* bufname) ) t nil) default) nil )) ;; only for certain special buffers (defadvice switch-to-buffer (around sw-force-other-frame (rest args) activate) (if (open-in-other-frame-p (car args) nil) (apply #'switch-to-buffer-other-frame args) ad-do-it) ) ;; we'd like to open new frames for some stuff (defadvice find-file (around force-other-frame (rest args) activate) (if one-buffer-one-frame (apply #'find-file-other-frame args) ad-do-it) ) ;; buffer selected from menu bar (but not from popup menu when doing C-mouse-1) (defadvice menu-bar-select-buffer (around select-buffer-force-other-frame (rest args) activate) (interactive) (if one-buffer-one-frame (switch-to-buffer-other-frame last-command-event) ad-do-it) ) ;; delete window when buffer is killed (defadvice kill-buffer (around force-delete-frame (rest args) activate) (setq last-sel-window (selected-window)) (if (and (open-in-other-frame-p (car args) t) (not (special-display-p (buffer-name))) (eq (window-buffer) (car args))) (list (condition-case nil ( list ad-do-it (delete-window last-sel-window) ) (error ;; if this is the last open frame, just make it invisible (make-frame-invisible (selected-frame) t) ) )) ;; else ; don't delete ad-do-it ) ) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Should killing a help or compile buffer also delete the window?
David Reitter [EMAIL PROTECTED] writes: Daniel Brockman daniel at brockman.se writes: I just thought I'd point out that substituting `at' for `@' in the body of a message is counter-effective against harvesting, since this makes the address slip through [1,2] the filter for the archive web interface which ordinarily removes all addresses completely (replacing them with `[EMAIL PROTECTED]' or somesuch). Of course, if someone has a copy of the actual message, they can just look in the CC header to find the address in plaintext. -- Daniel Brockman [EMAIL PROTECTED] [1] http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00893.html [2] http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00476.html ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Overlay arrow in *compilation* and *grep* buffers
Notice the overlay arrow that covered part of the file name: this is a bug, IMHO. If we want to have an arrow pointing out the current line, we should indent the buffer text to the right as many columns as the arrow string takes. It might be good to do that when overlaying the arrow on a compilation error buffer, but it would be a misfeature to do that when overlaying the arrow on a program file (which was the original use of the overlay arrow). Perhaps we need a user option to control these two features (scrolling and arrow) in a way that would by default prevent scrolling when the arrow is used to show the current line. Also, the arrow feature is not customizable. What about users who will dislike it and would wish to turn it off? I'd probably prefer to turn off the arrow and use just the scrolling, for compilation buffers. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Removing unloaded functions from auto-mode-alist.
So the provide merely sets a flag, and this flag causes the encompassing load not to throw the collected previous autoload data away at the end of the load sequence, but use it for marking the changed functions with the old autoloads in their properties. Clearer now? Why make this depend on the presence of `provide' in the file? If we implement this feature, it would be simpler and probably more useful to do it for all files, whether or not they include a `provide' call. The other issues make this a complex matter. I tend to think that unload-feature should be designed for well-behaved packages that do not redefine functions defined elsewhere. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
Date: Mon, 25 Apr 2005 20:08:51 +0800 From: Sun Yijiang [EMAIL PROTECTED] The %HOME% environment variable is used by many programs under w32, so it's really a mess sometime. Is HOME used for any other purpose than Emacs does: to store the user's private init files? If some programs use HOME for conflicting purposes, could you please name those programs and describe the details? I suggest Emacs use a different HOME variable=20 underw32, something like %EMACS_HOME% or %EHOME%. I don't think we should introduce such a variable without a very good reason; hence the questions above. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
Eli Zaretskii [EMAIL PROTECTED] writes: Date: Mon, 25 Apr 2005 20:08:51 +0800 From: Sun Yijiang [EMAIL PROTECTED] The %HOME% environment variable is used by many programs under w32, so it's really a mess sometime. Is HOME used for any other purpose than Emacs does: to store the user's private init files? If some programs use HOME for conflicting purposes, could you please name those programs and describe the details? I suggest Emacs use a different HOME variable=20 underw32, something like %EMACS_HOME% or %EHOME%. I don't think we should introduce such a variable without a very good reason; hence the questions above. kpathsea, the library for most TeX systems, has a scheme where you can override most environment variables on a per-application base. An analog construction for Emacs would be to something like (or (getenv HOME.emacs) (getenv HOME)) -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: font-lock-beginning-of-syntax-function semi-obsolete?
So, how do you make Font Lock use the function in the variable syntax-begin-function to move to top level? I don't understand the question. What have you tried? Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Should killing a help or compile buffer also delete the window?
Daniel Brockman wrote: I've always found it annoying that Emacs seems to have a habit of leaving junk windows around whenever you invoke something that needs to display information in a temporary buffer. I think it just gives a really sloppy impression, especially when you aren't used to it. Two of the most common examples might be `M-x compile' and `C-h f'. It also happens with things like `M-x grep' and `M-x locate'. I realize that you can't expect Emacs to know when you are done with a window unless you actually tell when. The obvious way to tell when is to type `C-x 1' or `C-x 0', but this leaves the temporary buffer lingering, which makes me nervous. When I was new to Emacs, I would always kill a garbage buffer before deleting its temporary window. Eventually, I discovered `C-x 4 0' and started using that. As time went by (and I got lazier), I gradually began to accept the fact that you really can't avoid having a bunch of old garbage buffers unless you spend a lot of time chasing them down, so I started just doing `C-x 1', though it always made me feel dirty. Now to the point of this message. Some time ago I started using Dictionary Mode[1], which has caused me to once again pick up the habit of killing temporary buffers. As you might know, killing a dictionary buffer automatically kills the window as well, unless the window was already there when the dictionary buffer was created. This makes a lot of sense to me --- so much sense that the normal Emacs behavior has once again started to annoy me. I believe the Right Thing to do when the user kills a temporary buffer whose window was created as a side-effect of displaying the buffer in question is to restore the old window configuration. At least when the automatically created window hasn't been used for anything else, Emacs should take the hint and get the window out of the user's face. Have you tried displaying those temporary buffers each in its own frame, via special-display-buffer-names (or special-display-regexps)? That frame's sole window is dedicated to the buffer, and so killing the buffer deletes the frame. -- Kevin Rodgers ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
Eli Zaretskii [EMAIL PROTECTED] writes: Cc: Sun Yijiang [EMAIL PROTECTED], emacs-devel@gnu.org From: David Kastrup [EMAIL PROTECTED] Date: Mon, 25 Apr 2005 19:04:34 +0200 kpathsea, the library for most TeX systems, has a scheme where you can override most environment variables on a per-application base. I know all about Kpathsea, but I don't think there's any reason to go to such complexities in Emacs. I was not suggesting we implement kpathsea's search semantics. I was merely saying that there was already a well-established scheme for application specific overrides of general environment variables. And that makes HOME.emacs for such an environment variable the natural choice. This is not complicated at all, and I see no reason not to just follow that practice _if_ we decide that being able to override HOME would be a good idea. I am not sure about that, but the complexity of kpathsea is completely irrelevant for resolving that question. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
The %HOME% environment variable is used by many programs under w32, so it's really a mess sometime. The above doesn't make any sense: the $HOME envvar is used by many/all programs under Unix and it's not a mess at all. Could you explain why under w32 it creates a mess? E.g. give examples of conflicting requirements. That will help us better assess the problem and the potential solutions, Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Title: : . , 27.4, 19:00," " " "." '' 37 ( ). : . . "" . ". " " ,. . 8. - - . . [ ] . . ,. , , ... , ! . \, , . , . . . inline: newsletter_head!!.gif___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
Eli Zaretskii [EMAIL PROTECTED] writes: Cc: [EMAIL PROTECTED], emacs-devel@gnu.org From: David Kastrup [EMAIL PROTECTED] Date: Mon, 25 Apr 2005 20:26:22 +0200 I am not sure about that, but the complexity of kpathsea is completely irrelevant for resolving that question. It's relevant: I wouldn't want to ever see Emacs in the need of something like kpsewhich to figure out where HOME (or any other variable related to Emacs) points this week. Looks like Guy Fawkes celebrations must be near. Straw men seem all the rage. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate HOME environment variable under w32?
Please see also the discussion in oct 2004 in the archives about $HOME default on w32. - Original Message - From: Sun Yijiang [EMAIL PROTECTED] To: emacs-devel@gnu.org Sent: Monday, April 25, 2005 2:08 PM Subject: What about a seperate HOME environment variable under w32? The %HOME% environment variable is used by many programs under w32, so it's really a mess sometime. I suggest Emacs use a different HOME variable underw32, something like %EMACS_HOME% or %EHOME%. This can be backward compatible if Emacs first look for %EHOME% variable, and if not found, search for %HOME% instead. User can also set simply set %EHOME% to %HOME% to get backward compatibility. Sun Yijiang ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Should killing a help or compile buffer also delete the window?
Drew Adams [EMAIL PROTECTED] writes: Wrt various efforts to deal with this and your comments on deleting windows and killing buffers: Deleting a window should not, in general, delete (kill) its buffer, but killing a buffer _interactively_ can often reasonably delete its window too (and frame, if `one-window-p'). Yes, I completely agree. Thanks for clarifying. -- Daniel Brockman [EMAIL PROTECTED] ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
On 2005-04-25, Stephen Eglen [EMAIL PROTECTED] wrote: Relevant settings: ispell-really-aspell t ispell-program-name ispell Aren't these contradictory settings? If you have ispell-really-aspell t ispell-program-name aspell your problem will go away, won't it? I never understood why there are two user-configurable variables here, myself. Shouldn't setting ispell-really-aspell to t automatically set ispell-program-name to aspell? Or are thing likely to be more complex depending on ispell/aspell version? Seems likely, and a good reason not to change that line willy-nilly. Peter ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: a problem of emacs-21.3 on FreeBSD-ia64
At Mon, 25 Apr 2005 12:05:12 -0400, Richard Stallman wrote: Emacs 21.3 is rather old. Could you try this with the current development Emacs from savannah.gnu.org? I've tried but bootstrap failed at Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Loading version.el (source)... Loading widget (source)... Loading custom (source)... Loading emacs-lisp/map-ynp (source)... Loading env (source)... Loading cus-start (source)... Invalid function: DEAD *** Error code 255 whole compile log attached. -- Yoichi NAKAYAMA pluto2-log.tar.gz Description: Binary data ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
