Re: [PATCH] make-dist fixes and clean-ups
Jérôme Marant <[EMAIL PROTECTED]> writes: > Lute Kamstra <[EMAIL PROTECTED]> writes: > >> So you do the following? >> >> 1. Checkout a clean working copy of Emacs' CSV. >> 2. Run "make-dist --snapshot" to get a tarball (without .elc or info >> files). >> 3. Unpack this tarball. >> 4. Run ".configure" and "make bootstrap" on that tree. > > Exactly. > >> What about the patch below then? It makes sure that make-dist never >> distributes ldefs-boot.el (that way, ldefs-boot.el will never be >> installed either) and it ensures that a tarball created by the above >> method can bootstrap. > > Many people already proposed that Huh? I didn't see it in any of the messages posted to emacs-devel. They all talked about changing Emacs' Makefiles or the Debian script, not about changing make-dist. > but this is wrong since 'make maintainer-clean', which undoes the > bootstrap, will remove loaddefs.el (which is fine since > autogenerated files have to be removed). > > Hence, I can't bootstrap more than once with the same tarball. Out of curiosity: do you have any special reason to do a "make maintainer-clean" before a second "make bootstrap"? Why do a second bootstrap at all? > How about leaving ldefs-boot.el and see if it hurts? Apart from being redundant under normal circumstances, it probably doesn't hurt in any way. Come to think of it: it's actually a nice feature that the distribution tarball allows a "make maintainer-clean" and then a ".configure" plus "make bootstrap". You convinced me to distribute ldefs-boot.el. ;-) Lute. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
emacs-devel@gnu.org
_/_/_/_/_/$B5U1g!y?M:[EMAIL PROTECTED](BSM$B!yB(2q$$!yD>%aD>EE(B_/_/_/_/_/ _/_/_/_/_/_/ http://awg.webchu.com/?springq _/_/_/_/_/_/ $B!xBg9%I>!V(B1$B1_!WL5NA%]%$%s%HB#Dh%-%c%s%Z!<%s7QB3http://awg.webchu.com/?springq $B!}7HBS!&(BPC$BBP1~$G%U%j!<%a!<%k$bMxMQ$G$-$^$9!#(B $B!}F?L>@-$,Hs>o$K9b$/!"0l;[EMAIL PROTECTED];[EMAIL PROTECTED]@Z4X$o$j$,$"$j$^$;$s$N$G0B?4$7$F$4MxMQ2<$5$$!#(B $B!}L5NA$G$?$C$W$jM7$s$GD:$-!"!V$3$3$J$i!*!W$H;W$C$FD:$1$?J}$O0B?4$NA0J'$$$r$4MxMQ2<$5$$!#$?$C$?(B3000$B1_$+$i$4MxMQD:$1$^$9!#(B $B"(Ev%a!<%k$NG[?.5qH]$O$3$A$i"*(B [EMAIL PROTECTED] $B$^$G$*http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: define-derived-mode
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Lute Kamstra wrote: > >> which was an incompatible change. > >Not compatible with what? > > With pre-existing defvars or defcustoms for these hooks. (Unless you > checked for _all_ uses of `define-generic-mode' that there are none. > But how did you get a list of _all_ outside packages that use it?) define-generic-mode is an all-in-one solution for defining a major mode. You call it, and every aspect of the major mode should be set up. I think it's very unlikely that anyone who uses define-generic-mode will add a defvar for the mode hook. (This certainly isn't the case in Emacs' sources.) > In the case of `define-minor-mode' two concrete examples of variables > with competing defcustoms are auto-revert-mode-hook and > global-auto-revert-mode-hook. In this particular case, not too much > harm is done, but it is not exactly very clean. > >I primarily wanted to define the mode hook as a variable so that I >could give it docstring. I chose defcustom over defvar because >define-minor-mode and quite some other major modes did that. I don't >strongly object to making the defcustom a defvar, but I don't >understand your problems with the use of defcustom: > > I have a problem with _both_ defvar and defcustom. Hooks do not need > a defvar, most hooks do not have them. The only reason for a defvar > is to add a docstring. You use the defvar to give the hook the > docstring: "Hook run when entering Mymode mode.". This "generic" > docstring contains no info that is not already contained in the hook's > name and it could overwrite _real_ info contained in a handwritten > defvar or defcustom. > > If you want to make people aware of the mode hook, it would seem > better to put an additional sentence in the default mode doc: > > "Mymode mode. > This a generic mode defined with `define-generic-mode'. > As all such modes, it runs `foo-mode-hook' as the very last thing it does." Ok, that sounds reasonable. I'll implement that. >I don't recall the bugs you refer to; could you give me the subject(s) >of the relevant thread(s)? > > It is scattered over several threads. Threads about Custom tend to be > superlong and unfocused. `find-file-hook as illustration of Custom problems' > is one of the threads, but several other threads about Custom were > going on at the same time and they all intertwined. > > There are several problems, related to the fact that hooks have to be > customized using add-hook and remove-hook and not using setq. But > Custom does use setq. Here is an example of the type of problems that > occur. (By no means the only one.) The user customizes foo-hook > using Custom. Then in the next Emacs version, a very essential > function badly-needed-fun is added to foo-hook. The user's > custom-set-variables form overrides the adding of badly-needed-fun to > foo-hook. > > These kind of problems are supposed to get fixed in 23 or 24, but it > is too tricky to still get it done for 22. Thanks for clarifying, Lute. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [PATCH] make-dist fixes and clean-ups
What about the patch below then? It makes sure that make-dist never distributes ldefs-boot.el (that way, ldefs-boot.el will never be installed either) Why adopt that as the goal? What is wrong with distributing ldefs-boot.el? What is wrong with installing ldefs-boot.el? Unless there is some specific reason it must be excluded, I would rather include it. It is not large. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Fwd: Preventing drag & drop the dired way
--- Begin Message ---
Hi there,
normally, if I drag a file onto an Emacs session Emacs opens
the file. But sometimes, such as when the window with focus
happens to contain a dired buffer something else happens.
dired will attempt to copy the file to it's current directory.
C-h k always reports w32-drag-n-drop which says nothing about
moving or copying a file.
Is there an easy way to cause Emacs to always open the file
I drag onto it no matter what buffer happens to be displayed?
thanks, olli
--- End Message ---
Hi,
I would have suggested to use `dired-mode-hook' to reset the dnd
variables to their standard values. But this won't work because the
DND setup is done after running the hooks in `dired-mode'.
I think it is reasonable that a user prefers to have the default drop
behavior in dired. Shouldn't we have an option for this? I'd suggest
the following patch. Okay to install?
2005-05-10 Reiner Steib <[EMAIL PROTECTED]>
* dired.el (dired-dnd-protocol-alist): New variable.
(dired-mode): Use `dired-dnd-protocol-alist'.
--8<---cut here---start->8---
--- dired.el12 Apr 2005 11:50:24 +0200 1.307
+++ dired.el10 May 2005 11:36:53 +0200
@@ -200,6 +200,18 @@
;; Note this can't simply be run inside function `dired-ls' as the hook
;; functions probably depend on the dired-subdir-alist to be OK.
+(defcustom dired-dnd-protocol-alist
+ '(("^file:///" . dired-dnd-handle-local-file)
+("^file://" . dired-dnd-handle-file)
+("^file:". dired-dnd-handle-local-file))
+ "The functions to call when a drop in `dired-mode' is made.
+See `dnd-protocol-alist' for more information. When nil, behave
+as in other buffers."
+ :type '(choice (repeat (cons (regexp) (function)))
+(const :tag "Behave as in other buffers" nil))
+ :version "22.1"
+ :group 'dired)
+
;; Internal variables
(defvar dired-marker-char ?* ; the answer is 42
@@ -1522,14 +1534,11 @@
'dired-desktop-buffer-misc-data)
(setq dired-switches-alist nil)
(dired-sort-other dired-actual-switches t)
- (run-mode-hooks 'dired-mode-hook)
(when (featurep 'dnd)
(make-variable-buffer-local 'dnd-protocol-alist)
(setq dnd-protocol-alist
- (append '(("^file:///" . dired-dnd-handle-local-file)
- ("^file://" . dired-dnd-handle-file)
- ("^file:". dired-dnd-handle-local-file))
- dnd-protocol-alist
+ (append dired-dnd-protocol-alist dnd-protocol-alist)))
+ (run-mode-hooks 'dired-mode-hook))
;; Idiosyncratic dired commands that don't deal with marks.
--8<---cut here---end--->8---
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [PATCH] make-dist fixes and clean-ups
Quoting Lute Kamstra <[EMAIL PROTECTED]>: > > Many people already proposed that > > Huh? I didn't see it in any of the messages posted to emacs-devel. > They all talked about changing Emacs' Makefiles or the Debian script, > not about changing make-dist. Sorry, you're right, it was proposed to do so out of make-dist, but it was the same idea. > > but this is wrong since 'make maintainer-clean', which undoes the > > bootstrap, will remove loaddefs.el (which is fine since > > autogenerated files have to be removed). > > > > Hence, I can't bootstrap more than once with the same tarball. > > Out of curiosity: do you have any special reason to do a "make > maintainer-clean" before a second "make bootstrap"? Why do a second > bootstrap at all? Yes, I do. I do build a package from within the unpacked tarball, and when I do many attempts, make bootstrap and make maintainer-clean are run on the same tree many times: not to have to unpack the same tree at every attempt is handy. > > How about leaving ldefs-boot.el and see if it hurts? > > Apart from being redundant under normal circumstances, it probably > doesn't hurt in any way. Come to think of it: it's actually a nice > feature that the distribution tarball allows a "make maintainer-clean" > and then a ".configure" plus "make bootstrap". Indeed. > You convinced me to distribute ldefs-boot.el. ;-) I'm glad I did :-) Thanks. -- Jérôme Marant ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
Peter Heslin <[EMAIL PROTECTED]> writes: > 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"? Some folks might set ispell-program-name to "/sw/foo/bin/aspell", so the variable is not redundant. Kai ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fwd: Preventing drag & drop the dired way
Reiner Steib <[EMAIL PROTECTED]> writes: > I would have suggested to use `dired-mode-hook' to reset the dnd > variables to their standard values. But this won't work because the > DND setup is done after running the hooks in `dired-mode'. That would appear to be a mistake: the purpose of the hook variables is to establish user preferences at a late point in the load sequence. > I think it is reasonable that a user prefers to have the default > drop behavior in dired. Shouldn't we have an option for this? I'd > suggest the following patch. Okay to install? It would appear more sensible to fix the hook executation to come last. Actually, your patch does that, too. It looks reasonable to me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ 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 they do not slow the first day.] Success so far! On 6 May 2005, Stefan Monnier said Maybe we just need to make goto-address mark its overlay with the `evaporate' propert so they disappear as soon as they beomce empty. and provided a patch. Using that patch, RMAIL deletions have been fast. At the moment, I have only 155 overlays in the RMAIL buffer rather than the many thousands as before. -- 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: [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers]
Richard Stallman <[EMAIL PROTECTED]> writes: > Would someone please investigate this bug? > Please respond to this message if you investigate it. Lute Kamstra writes: > I get a *grep* buffer with occurrences of "(define-minor-mode" in lisp > files. Every time that I tried, most lines in this buffer give the > text "(define-minor-mode" the grep-match-face, but a few lines don't > fontify "(define-minor-mode". The strange thing is that the lines > that don't fontify "(define-minor-mode" are different every time I > invoke grep. Very wild guess. Please do C-h v tramp-chunksize RET and run the Lisp code shown in the documentation for tramp-chunksize and report your findings. The Lisp snippet contains a number, 1000. If you do not observe a problem (i.e., you that bytes sent always equals bytes received), then please also try larger values, 1 or 10 or 100. Kai ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [PATCH] make-dist fixes and clean-ups
Richard Stallman <[EMAIL PROTECTED]> writes: > What about the patch below then? It makes sure that make-dist never > distributes ldefs-boot.el (that way, ldefs-boot.el will never be > installed either) > > Why adopt that as the goal? What is wrong with distributing > ldefs-boot.el? What is wrong with installing ldefs-boot.el? For installation purposes ldefs-boot.el is redundant. (In a distribution tarball it's also exactly the same as loaddefs.el.) But that's not really a problem. > Unless there is some specific reason it must be excluded, > I would rather include it. It is not large. Agreed. Jérôme Marant pointed out that including ldefs-boot.el allows a "make maintainer-clean" and then a ".configure" plus "make bootstrap" on an unpacked distribution tarball. I think that's a nice feature. Lute. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Mouse Sel mode and mouse-1-click-follows-link
>The trouble is, I can't get it to work with *Customize* buffers. >This is probably due to some widget magic that I'm ignorant of. Can >someone help me figure it out? > > That is because Custom implements the mouse-1 behavior in a different > way from mouse-1-click-follows-link. > > I believe that the best solution might be to get rid of the mouse-1 > binding and use the follow-link property to implement the mouse-1 > behavior in Custom, as is done elsewhere. I don't know enough about the widget library to have an opinion on changing it. Come to think of it, does mouse-1 on custom widgets work with mouse-sel-mode in Emacs 21? I suspect that it doesn't, but I can't check right now. If it's never worked, then maybe it's not so important to fix it for the release. The patch I posted does at least adapt mouse-sel-mode to mouse-1-click-follows-link, so Info and Help buffers will work. If someone could review it and check it in, that would be great. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Should overlays evaporate by default?
Robert J. Chassell <[EMAIL PROTECTED]> wrote: > [After running the same RMAIL for several days, deletions slow; but > they do not slow the first day.] > > Success so far! > > On 6 May 2005, Stefan Monnier said > > Maybe we just need to make goto-address mark its overlay with the > `evaporate' propert so they disappear as soon as they beomce > empty. > > and provided a patch. Last year I reported a similar problem with mh-e (see below). Perhaps it would be better for overlays to evaporate by default. I can only think of one case where its not better, and that's where the contents of an editable field are deleted and new contents reinserted. If the overlay evaporates the field disappears, but the bug is immediately obvious and quickly fixed. On the other hand, for the case where overlays are used to decorate buffer contents, the consequence (massive memory leakage) is not obvious, and goes undetected. I suspect that this case is far more common. For reference here is what I said back on 15 July 2004: > > MH-E uses parts of GNUS to display messages, and the overlays used by > GNUS do not have the evaporate property set, and so do not get deleted > when the mh-show buffer is erased in preparation for the next message > (see below). > > Yes MH-E, and any other packages that use these utilities, could be > changed to explicitly delete overlays when reusing buffers, but it would > be easier for maintainers and future package writers if the GNUS > overlays would evaporate. > > It would not surprise me if other packages using overlays to decorate > buffer contents also leak. > > The real problem is that anyone using overlays to decorate the contents > of a reusable buffer is required to know that they must either > explicitly set the evaporate property on any overlays they create, or > explicitly delete overlays when using erase-buffer, or both. > > This requirement is not obvious. There should be a note in the > erase-buffer documentation pointing out that only overlays with the > evaporate property will be deleted, and with a reference to the new > remove-overlays function. > > I think it preferable that erase-buffer also remove the overlays. Right > now it results in _all_ the non-evaporating overlays being reduced to > zero length at the begining of the buffer. Inserting text into the > buffer cannot ressurect them unless they have a non-default end > advance behaviour. I guess erase-buffer could be selective about which > overlays it removes, but that sounds like overkill as I doubt anyone > intentionally uses overlays and erase-buffer that way. > > Here is the result of my tests on the MH-E message show buffer after > using it to browse several email messages... > > (pp (save-current-buffer > (set-buffer (get-buffer-create "show-+inbox")) > (mapcar (lambda (ov) (list (overlay-start ov) (overlay-end ov) >(overlay-properties ov))) > (overlays-in (point-min) (point-max))) > )) > > Overlays used in current message... > > ((515 558 > (face gnus-cite-face-2)) > (443 512 > (face gnus-cite-face-2)) > (378 437 > (face gnus-cite-face-2)) > (302 374 > (face gnus-cite-attribution-face)) > (302 374 > (face gnus-cite-face-2)) > > Overlays used in previous messages... > > (1 1 > (face gnus-cite-face-2)) > (1 1 > (face gnus-cite-face-2)) > (1 1 > (face gnus-cite-attribution-face)) > (1 1 > (face gnus-cite-face-3)) > (1 1 > (keymap > (keymap > (mouse-2 . smiley-mouse-toggle-buffer) > (down-mouse-2 . ignore)) > help-echo "mouse-2: toggle smilies in buffer" smiley t mouse-face > highlight display > (when smiley-active image :type pbm :file > "/usr/local/share/emacs/21.3.50/lisp/gnus/smile.pbm" :ascent center))) > (face gnus-cite-face-2)) > > ...and many, many, more > ) -- Peter Whaite (http://whaite.ca) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fwd: Re: junk in *grep* buffers
The following hack fixes the problem, but this is an imperfect solution. It sets the local variable `pos' from `font-lock-fontify-keywords-region' to avoid changing the current position on the line: Could the code in font-lock-fontify-keywords-region use a marker to maintain that position? Then it would be relocated automatically. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
[cstacy@dtpq.com: dissociated usenet]
People might find this amusing. --- Start of forwarded message --- Date: Mon, 9 May 2005 17:49:46 -0400 (EDT) From: "Christopher C. Stacy" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: dissociated usenet X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 I recently saw these two consecutive header lines on one of the Emacs newsgroups: [ 11: rgb ] One handed Emacs [ 31: Gordon Snyder ] Much better than Viagra Cheaper, too! Warning: If editing session lasts more than 6 hours, consult physician. --- End of forwarded message --- ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Unclear in etc/NEWS
Many mouse wheels also function as mouse-2, by pressing them. It is all too easy to accidentally press the wheel while you rotate it. This fix presumably ignores mouse-2 clicks interspersed with wheel rotations. Does anyone know if that is what it really does? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fwd: Re: junk in *grep* buffers
> The following hack fixes the problem, but this is an imperfect solution. > It sets the local variable `pos' from `font-lock-fontify-keywords-region' > to avoid changing the current position on the line: > Could the code in font-lock-fontify-keywords-region use a marker to > maintain that position? Then it would be relocated automatically. Would the patch below do the trick? Stefan --- font-lock.el05 mai 2005 16:09:23 -0400 1.245 +++ font-lock.el10 mai 2005 13:35:07 -0400 @@ -1405,6 +1405,7 @@ (let ((case-fold-search font-lock-keywords-case-fold-search) (keywords (cddr font-lock-keywords)) (bufname (buffer-name)) (count 0) +(pos (make-marker)) keyword matcher highlights) ;; ;; Fontify each item in `font-lock-keywords' from `start' to `end'. @@ -1439,12 +1440,13 @@ (while highlights (if (numberp (car (car highlights))) (font-lock-apply-highlight (car highlights)) - (let ((pos (point))) + (set-marker pos (point)) (font-lock-fontify-anchored-keywords (car highlights) end) ;; Ensure forward progress. - (if (< (point) pos) (goto-char pos +(if (< (point) pos) (goto-char pos))) (setq highlights (cdr highlights - (setq keywords (cdr keywords) + (setq keywords (cdr keywords))) +(set-marker pos nil))) ;;; End of Keyword regexp fontification functions. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
> Cc: emacs-devel@gnu.org, [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED] > From: Juri Linkov <[EMAIL PROTECTED]> > Date: Tue, 10 May 2005 08:04:07 +0300 > > Note that automatic changing the value of `ispell-program-name' > in `ispell-check-version' might surprise users of the aspell's > implementation of ispell. Anyhow, this is the better place to > change ispell program name to "aspell" than defcustom. I think the right thing to do is to modify what's currently in CVS so that it doesn't fail with non-English dictionaries. Can you describe how it fails in that case, and why? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Extending GUD tooltips
Nick Roberts <[EMAIL PROTECTED]> writes: > I have actually done this now. I found it compelling for several reasons: > > 1) It was a lot easier to do than I thought it would be. > 2) Normal tooltips and GUD tooltips can be toggled independently. > 3) The define lists for macro expansion need only be generated when GUD >tooltips is enabled as a minor mode (as Stefan suggested). > 4) The arrangement is more modular (as Jérôme suggested). > 5) Only normal tooltips get loaded into Emacs through loadup.el > > I attach reduced tooltip.el file below. I also have the changes for > GUD tooltips ready to include in gud.el. Thanks a lot, Nick, for improving the quality of Emacs code that way! Cheers, -- Jérôme Marant ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Relation with package authors (CPerl-mode follow-ups)
Stefan Monnier <[EMAIL PROTECTED]> writes: >> I've been recently in touch with Ilya Zakharevich (CPerl-mode author) >> about Cperl-mode bugs I found in current version from Emacs CVS >> trunk (version 5). > > Please post them here. I will do. Last time I reported one, you told me perl-mode did not have such a bug :-P >> He was kind to take a look at them and found out those bugs have >> already been fixed in 5.0 (I do confirm) and decided to stop >> investigating further. This means changes to the CVS version lead >> to regressions. Now, I'm left alone with my bugs. > > What makes you think so? Obviously someone else than Ilya must have caused Last time I reported a bug, I had the impression noone wanted to maintain it in favour of perl-mode. I'm glad if not. > the changes between Ilya's version and Emacs's and it's quite likely > he/she's reading this mailing-list. Quite. ... >> Why patches to Cperl-mode have never been sent back to him? >> Isn't he meant to be the author of the mode? > > There was a disagreement about what the code should look like (I don't know > the specifics but my understanding is that Richard wanted some changes that > Ilya rejected), so his version and the Emacs version are not the same. > I do send him every patch I apply to Emacs's cperl-mode.el. I'm happy you do. How does he react to your changes? -- Jérôme Marant ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
MY MAIL''''
Dear one, I am YURIY LAGUTIN and I represent Mr. Mikhail Khordokovsky the former C.E.O of Yukos Oil Company in Russia. I have a very sensitive and confidential brief from this top (oligarch) to ask for your partnership in re-profiling funds over US$450 million. I will give the details, but in summary, the funds are coming via Bank Menatep. This is a legitimate transaction. You will be paid 4% for your "management fees". If you are interested, please write back by email yurlagutin@christzone.com OR [EMAIL PROTECTED] and provide me with your confidential telephone number, fax number and email address and I will provide further details and instructions. Please keep this confidential; we cant afford more political problems. Finally, please note that this must be concluded within two weeks. Please write back promptly.I will also suggest you visit these news sites on the internet to be better informed about this project. http://www.winne.com/topinterviews/khodorkovsky.htm http://newsfromrussia.com/main/2003/11/13/51215.html http://www.supportmbk.com/mbk/mbk_bio.cfm http://www.disinfopedia.org/wiki.phtml?title=khail_B._Khodorkovsky http://www.pbs.org/frontlineworld/stories/moscow/khodorkovskyinterview.html http://www.forbes.com/finance/lists/75/2004/LIR.jhtml?passListIdu&passYear 04&passListType=rson&uniqueId=IF&datatype=rson http://mikhail_khodorkovsky_society.blogspot.com/ Write me back. I look forward to it. Regards Mr. YURIY LAGUTIN ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Relation with package authors (CPerl-mode follow-ups)
>>> I've been recently in touch with Ilya Zakharevich (CPerl-mode author) >>> about Cperl-mode bugs I found in current version from Emacs CVS >>> trunk (version 5). >> >> Please post them here. > I will do. Last time I reported one, you told me perl-mode did not > have such a bug :-P But either you didn't mention or I didn't notice that the bug is also absent from the original cperl-mode.el. I'm not really interested in fixing cperl-mode bugs, but I do find it important that our local changes to cperl-mode don't add new bugs. >> There was a disagreement about what the code should look like (I don't know >> the specifics but my understanding is that Richard wanted some changes that >> Ilya rejected), so his version and the Emacs version are not the same. >> I do send him every patch I apply to Emacs's cperl-mode.el. > I'm happy you do. How does he react to your changes? He acknowledges them (along the lines of "OK, I'll check later whether these are appropriate for my version"). Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Adding missing copyright years
Just a small bug report about copyright-fix-years function (copyright.el, CVS:1.51) Insert this line into a buffer: ; Copyright (C) 99 by Some Company. Call copyright-fix-years function, we get: ;Copyright (C) 99, 05 by Some Company Call the same function again, we get: ;Copyright (C) 99, 2005 by Some Company Call the same function again, we get: ;Copyright (C) 99, 2005by Some Company Anybody cares to fix this? Is this function used at all? It should be at least wrapped in (save-excursion (save-restriction ...)), I suppose. -- Alexander Pohoyda <[EMAIL PROTECTED]> PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: c-macro-expand isn't part of CC Mode
Nick Roberts <[EMAIL PROTECTED]> wrote: > Within Emacs CVS, I think both cc-mode.el and cmacexp.el are part of > Emacs. Maybe so, but it's more relevant to note what the respective maintainers are inclined to support. If the CC Mode maintainers aren't prepared to support a certain feature then it's better to not add that feature to the cc-*.el files. That avoids confusion with bug reports sent to the wrong places, bitrot and possible lossage in merges. In this particular case the added feature was outside the scope of CC Mode, so it's good that it was taken out again (although I'm sure the feature in itself is very neat). The scope of CC Mode isn't spelled out anywhere, so I don't blame anyone for missing it. Anyway, it is something like this: o Provide functionality for syntax parsing in the supported languages. o Implement basic major mode operations for the supported languages, meaning buffer setup, movement/mark commands and miscellaneous simple tools for handling language constructs (e.g. aligning the backslashes in cpp macros). o Implement syntactically sensitive indentation and font locking. Some noteworthy things that are outside the scope: o Tracking of symbols, e.g. for providing tooltips containing symbol docs and type info etc, or for locating symbol definitions. o Stuff that requires knowledge of the compilation environment, e.g. pulling in include files, expand macros, tracking cross file references. o Templates for source constructs, e.g. to quickly insert a more or less complete class or method. These are not left out just because I personally don't consider them nice features (I do), but because implementing those things well is nontrivial and requires quite a bit of dedicated effort. I, and I probably speak for Alan Mackenzie as well here, have enough with getting the things inside the current scope to work as well as we would like. Also, there's no particular reason why stuff like that can't be in separate packages. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Bogus temporary frame created by Gnus
When I do "O f" in Gnus, I'm first prompted for a file name, and then a new frame is created that displays a temporary buffer that's immediately killed. I think it's just a bug, which is fixed by the patch below. Any objection? Note that several other gnus-summary-save-in-* functions may suffer from the same problem, but I don't have the time/energy to check them, Stefan PS: If you can't reproduce the problem, it's probably because your pop-up-frames and special-display-regexp settings are different from mine. --- orig/lisp/gnus/gnus-art.el +++ mod/lisp/gnus/gnus-art.el @@ -3314,7 +3314,7 @@ "Save %s in file:" filename gnus-file-save-name gnus-newsgroup-name gnus-current-headers 'gnus-newsgroup-last-file)) - (gnus-eval-in-buffer-window gnus-save-article-buffer + (with-current-buffer gnus-save-article-buffer (save-excursion (save-restriction (widen) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
