Re: CONTRIBUTE file
> I see. But I guess we could ask package maintainers like Romain to > include files like this, if it's appropriate. > > We could say that. Where would we put the statement, so they would > see it? Romain has added the file to make-dist which presumably determines which files get included in the GNU tarballs so meybe we could put a comment in there to say which files we would like included in binary distributions. I don't whether package maintainers would see the comment or follow it - I'm just guessing. Perhaps Romain could say how he decides which files to include in the binary package for Debian. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
INSTALL file
The INSTALL file says that Compiling with LessTif or Motif causes a standard File Selection Dialog to pop up when you type "C-x C-f" and similar commands. but I believe that dialogs are used only for mouse commands, not for keyboard commands. -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Reentrant call to malloc/free
> On Wed, 05 Jul 2006 13:25:12 +0200, [EMAIL PROTECTED] (Dr. Carsten > Bormann) said: > While typing input (apparently often related to file/process > operations, such as minibuffer completions of file names), emacs > occasionally (say, once a day in heavy usage) hangs and uses high > CPU (most of which is system time). Attaching GDB says: > #11 0x000e0850 in poll_for_input () > #12 0x00213930 in alarm_signal_handler () > #13 > #14 0x90006a8c in szone_free () > #15 0x0320 in ?? () > #16 0x9005d7dc in getgr_internal () > #17 0x9005d070 in getgr () > #18 0x0013ed6c in Ffile_attributes () I've once posted a (not complete) list of Darwin library functions that may call malloc-related functions but are not protected by BLOCK_INPUT: localtime, gmtime, ctime, opendir, getc, getaddrinfo, fwrite, mkstemp fclose, closedir, freeaddrinfo, mktime (not used as of 2004-09) (http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html) I cannot detect `getgrgid' as such a function, but I guess this is due to the difference in name service backends (NIS, LDAP, ...). We can put BLOCK_INPUTs around every getpw* and getgr* call, but if the problem only occurs on Darwin, creating wrapper functions is an alternative way. Does anyone know the situation on other systems? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
CONTRIBUTE [was Re: read-face-name...]
> > The admin directory has files which go way beyond the needs of the average > > contributor. > > Those files aren't documented anywhere, and aren't included in the > distribution. So, if we don't mention them, there's no chance an > average contributor will learn about them. What's the harm of > mentioning them? Some of those files are quite useful for > maintenance. I've just tried to follow the 80-20 rule. If the admin directory has files that are generally useful and can be described briefly then clearly there's no harm. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name doc string incorrect
> From: Nick Roberts <[EMAIL PROTECTED]> > Date: Wed, 5 Jul 2006 20:49:55 +1200 > Cc: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org > > The admin directory has files which go way beyond the needs of the average > contributor. Those files aren't documented anywhere, and aren't included in the distribution. So, if we don't mention them, there's no chance an average contributor will learn about them. What's the harm of mentioning them? Some of those files are quite useful for maintenance. > Developers are more likely to look in a file called CONTRIBUTE than > INSTALL.CVS for guidelines and splitting the information makes it a bit like a > treasure hunt. 100% agreement. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name doc string incorrect
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org > From: [EMAIL PROTECTED] (Kim F. Storm) > Date: Wed, 05 Jul 2006 10:31:43 +0200 > > CONTRIBUTE should mention that _after_ checking out the sources, > the user should read the INSTALL.CVS file. I don't see how INSTALL.CVS is relevant to contributing code. > We can add information about FOR-RELEASE (and the admin/ directory > in general) to that file. That would be totally inappropriate, IMO. INSTALL.CVS is for people who want to build Emacs out of CVS; most of those don't contribute. And the file's name, "INSTALL.something", would cause it to be about the last place to look forf information how to contribute. > Specifically, the section > > o Supplemental information for Emacs Developers: > > belongs in INSTALL.CVS rather than CONTRIBUTE. No, it doesn't. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfo-format-buffer text.texi
Richard Stallman schrieb: makeinfo --fill-column=70 /home/speck/emacs/lispref/text.texi That file is not valid input, since it is just part of a manual. Try it with elisp.texi instead. With the complete elisp.texi it will work. Just took that file, as you asked "Would someone please check lispref/text.texi for accuracy?" To check a single texi I called `texinfo-format-buffer' before. BTW I like `texinfo-format-buffer' because it runs out of the box, you have not to switch to shell or something like that, no extra opening etc. The errors are mince; just reported them, because I wasn't sure where the few errors are coming from - could be something in the text.texi to correct still. Would be great to keep `texinfo-format-buffer' maintained. Will try to help this, but have to learn a little bit more about tex still. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Exit hooks not run at logout on w32
>> Could the problem that users unsaved data are not saved on w32 in this >> situation be put in FOR-RELEASE? I think it is a serious bug. > The user has requested a shutdown of the system, without saving their > data first. How is it a bug that Emacs respects their wishes? It's worth considering that the user may have requested the shutdown without remembering that Emacs was open (or that data remained unsaved in it), or that something else (e.g., an installer program) may have initiated the shutdown unexpectedly. I believe that the question of "save or discard data" has an obvious answer. It's just a question of 1) Auto-save, to protect files from bad unsaved edits 2) Save really, assuming that the user didn't break things and then shut down, and avoiding the issue of recovering the files 3) Ask the user (probably best, but is it in line with the UI guidelines?) For what it's worth, all sorts of W32 applications interrupt a normal shutdown just to offer to save files, IIRC. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[patch] pgg passphrase cache broken
In GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-06-23 on exponent X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/usr/local/stow/emacs-unicode-xft.20060623' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-freetype' '--with-xft' '--with-gtk' '--enable-font-backend'' The bug is that the passphrase cache works once but when the expiration time is reached, the entry in the cache changes to "" (as many _ as the characters in the passphrase) and pgg does not ask for the passphrase again. The root of the bug is that when pgg-remove-passphrase-from-cache calculates the key to lookup, it has already been clipped when it was added as a timer by pgg-add-passphrase-to-cache. That should be fine, but the macro pgg-truncate-key-identifier, where the bug actually exists, does not use the substring function correctly (I believe the semantics of substring changed in emacs23?). Instead of calling (substring ,key 8), it should call (substring ,key -8). You can see the difference here: (substring "0123456789" 8) ==> "89" (substring "0123456789" -8) ==> "23456789" That's all. Thanks, always yours, -- David D. Smith pgpXiMLFDx0pf.pgp Description: PGP signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Reentrant call to malloc/free
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: (This is the Carbon Emacs distribution, generated 2006-06-16:) While typing input (apparently often related to file/process operations, such as minibuffer completions of file names), emacs occasionally (say, once a day in heavy usage) hangs and uses high CPU (most of which is system time). Attaching GDB says: (gdb) where #0 0x85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186 #1 0x900038d4 in szone_malloc () #2 0x90003804 in malloc_zone_malloc () #3 0x907ba488 in CFAllocatorAllocate () #4 0x907db41c in CFRunLoopRunSpecific () #5 0x931eb740 in RunCurrentEventLoopInMode () #6 0x931ead4c in ReceiveNextEventCommon () #7 0x932ef940 in ReceiveNextEventInMode () #8 0x0024e5a0 in XTread_socket () #9 0x000eb1ec in read_avail_input () #10 0x000e0804 in poll_for_input_1 () #11 0x000e0850 in poll_for_input () #12 0x00213930 in alarm_signal_handler () #13 #14 0x90006a8c in szone_free () #15 0x0320 in ?? () #16 0x9005d7dc in getgr_internal () #17 0x9005d070 in getgr () #18 0x0013ed6c in Ffile_attributes () #19 0x001a4454 in Ffuncall () #20 0x001f96bc in Fbyte_code () #21 0x001a50e8 in funcall_lambda () #22 0x001a4798 in Ffuncall () #23 0x001a3054 in Fapply () #24 0x001a4210 in Ffuncall () #25 0x001f96bc in Fbyte_code () #26 0x001a50e8 in funcall_lambda () #27 0x001a4798 in Ffuncall () #28 0x001f96bc in Fbyte_code () #29 0x001a50e8 in funcall_lambda () #30 0x001a4798 in Ffuncall () #31 0x001f96bc in Fbyte_code () #32 0x001a50e8 in funcall_lambda () #33 0x001a4798 in Ffuncall () #34 0x001a3054 in Fapply () #35 0x001a4210 in Ffuncall () #36 0x001f96bc in Fbyte_code () #37 0x001a50e8 in funcall_lambda () #38 0x001a4798 in Ffuncall () #39 0x001f96bc in Fbyte_code () #40 0x001a50e8 in funcall_lambda () #41 0x001a4798 in Ffuncall () #42 0x001f96bc in Fbyte_code () #43 0x001a50e8 in funcall_lambda () #44 0x001a4798 in Ffuncall () #45 0x001a3748 in run_hook_with_args () #46 0x001a33c0 in Frun_hooks () #47 0x001a4210 in Ffuncall () #48 0x001f96bc in Fbyte_code () #49 0x001a50e8 in funcall_lambda () #50 0x001a4798 in Ffuncall () #51 0x001f96bc in Fbyte_code () #52 0x001a50e8 in funcall_lambda () #53 0x001a4798 in Ffuncall () #54 0x001f96bc in Fbyte_code () #55 0x001a50e8 in funcall_lambda () #56 0x001a4798 in Ffuncall () #57 0x001f96bc in Fbyte_code () #58 0x001a50e8 in funcall_lambda () #59 0x001a4798 in Ffuncall () #60 0x001a3338 in Fapply () #61 0x001a3a24 in apply1 () #62 0x0019ac08 in Fcall_interactively () #63 0x000f3520 in Fcommand_execute () #64 0x000def54 in command_loop_1 () #65 0x001a091c in internal_condition_case () #66 0x000dcd98 in command_loop_2 () #67 0x001a0070 in internal_catch () #68 0x000dccfc in command_loop () #69 0x000dc36c in recursive_edit_1 () #70 0x000dc5ec in Frecursive_edit () #71 0x000da14c in main () (gdb) I have seen this problem before in May/June vintage Mac (Carbon) Emacsen I generated straight from CVS, so this is not a completely new problem. - If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.6.0) of 2006-06-16 on mini.local X server distributor `Apple Computers', version 10.4.7 configured using `configure '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI -DUSE_MAC_TSM'' 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: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: show-paren-mode: t encoded-kbd-mode: t iswitchb-mode: t partial-completion-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-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 auto-compression-mode: t size-indication-mode: t line-number-mode: t Recent input: Recent messages: Loading /Users/cabo/el/xmlunicode.el (source)...done Loading comint-complete (compiled; note, source file is newer)...done Loading sendmail...done Loading ps-pr
Re: Documentation
From: Richard Stallman <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2006 13:03:52 -0400
Thanks. Would you like to change the manual(s), too?
i have made changes in man/{building,faq}.texi and
lispref/{edebug,loading}.texi similarly. these were
chosen based on M-x find-grep "eval-current-buffer".
thi
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Documentation
> * eval-current-buffer has been obsoleted and replaced by eval-buffer. > Some places in the Emacs and Emacs Lisp manuals refer to both > eval-current-buffer and eval-buffer, some refer only to > eval-current-buffer. i've fixed those sites to use eval-buffer where it is mentioned solely. i left alone those where both eval-buffer and eval-current-buffer are mentioned. Thanks. Would you like to change the manual(s), too? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfo-format-buffer text.texi
makeinfo --fill-column=70 /home/speck/emacs/lispref/text.texi That file is not valid input, since it is just part of a manual. Try it with elisp.texi instead. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CONTRIBUTE file
I see. But I guess we could ask package maintainers like Romain to include files like this, if it's appropriate. We could say that. Where would we put the statement, so they would see it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfo-format-buffer text.texi
[None of my previous messages got through to
[EMAIL PROTECTED] Let's try these other addresses.
Please tell me which address succeeds and then please have Emacs set
the `mail-default-reply-to' variable so I don't try sending them to
[EMAIL PROTECTED] Thanks!]
As for your latest message,
makeinfo-buffer doesn't work at all with
GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2006-06-18
That was about the time my motherboard was zapped by lightning.
However, both makeinfo-buffer and texinfo-format-buffer succeeded with
this morning's GNU Emacs CVS snapshot, Wed, 2006 Jul 5 11:47 UTC
GNU Emacs 22.0.50.20 (i686-pc-linux-gnu, GTK+ Version 2.8.18)
although I saw
Warning (initialization): Building Emacs overflowed pure space.
(See the node Pure Storage in the Lisp manual for details.)
I used regular but old commands in the first Texinfo file on which I
tested them.
In addition, I tried both commands with a second file. In that file,
the makeinfo-buffer succeeded but texinfo-format-buffer died at the
@slanted command. The texinfo-format-buffer command succeeded after I
change @slanted to @emph.
So the texinfo-format-buffer command does not know all the @-commands
that have been introduced since makeinfo superceded it.
Also, I was able to run
makeinfo --force --fill-column=70 --no-split --paragraph-indent=0 \
--verbose foo.texi
makeinfo --fill-column=70 --no-split --paragraph-indent=0 \
--verbose --no-headers --output=foo.txt \
foo.texi
makeinfo --no-split --html foo.texi
in a shell inside that instance of Emacs with no reported errors where
foo.texi is the second file with @slant replaced with @emph.
Regarding, the other messages:
AFAIU the var `fill-column' is commonly known as
line-break.
I wrote:
No, not at all. When automatic filling is set to a specified
value, the variable `fill-column' is the value *up to which* (and
including) a carriage return or other such line-break may occur.
Often, the variable `fill-column' is larger than that line's value
of its line break. At least, that is how I learned the difference
years ago.
A line break may occur anywhere [in what is defined as inter-word
space in the syntax table], as in this sentence.
(In the previous sentence, the line break occurred at column 53,
not at the value of the variable `fill-column' which is 70 in this
instance of Emacs.)
Is there a way to refer the var `fill-column'?
Yes. I use the term `fill-column'; that works for me. Sometimes,
I have to explain that `automatic filling' refers to the same
concept as `automatic wrapping' in other programs.
You wrote,
Calling `texinfo-format-buffer' at text.texi
produces a line
@anchor-yes-refill{Definition of sentence-end-double-space}
which is probably not correct. (Line 1408 now)
RMS sent me a note saying `if you are interested' and I responded
Hah! I see that @anchor-yes-refill is attributed to you on 2
July 1998. I have never used @anchor and do not know anything
about it. I see what you did: take into account that some
paragraphs should be filled and others not. That makes a
great deal of sense.
As far as I know, the @anchor-yes-refill command is correct [for
an intermediate command].
You also wrote that there was a problem formatting the Emacs Lisp
Reference manual. It did not format for me either but stopped
formatting sooner than you reported: at Node: Syntax Table Internals.
(Possibly you did not run the command so early.) As I wrote,
And as far as I know the `texinfo-format-region' and the
`texinfo-format-buffer' commands do not understand all the
@-commands introduced in the past 10 years. I know for sure that
it worked with the Emacs Lisp Reference Manual when it was first
written -- makeinfo had not yet been invented -- but not since.
Interestingly, I am still listed as the maintainer of texinfmt.el.
I guess no one else wants it. You are the first person to send me
a bug report in a long time. My hunch is that
`texinfo-format-buffer' and similar commands will be troubled by
the `modern' @-commands, that is to say, those of the last decade
or more, few or perhaps none of which I know.
That hunch looks as if it was confirmed this morning, when I was able
to run `texinfo-format-buffer' successfully on a file in which @emph
replaced @slanted, on which the command failed.
(I use Texinfo frequently; after all, you can produce seven direct
output formats from a single source file [for printing in hard
copy or for fast online listening or viewing or slow online
listening or viewing]. Also, you can create PostScript and RTF in
two steps and LaTeX in three steps. Strangely enough, Info is
still the most efficient online format. But I hardly ever us
Re: texinfo-format-buffer (2) - text.texi
texinfo-format-buffer is pretty much obsolete; we use makeinfo instead. However, Bob Chassell sometimes maintains texinfo-format-buffer. So I forwarded these reports to him. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > The example that you gave at the start didn't toggle anything: it just > added a function to tooltip-hook. Right, sorry. It would have been better to poste the complete minor mode function. --8<---cut here---start->8--- (defun rdictcc-tooltip-mode (&optional arg) "Display tooltips with the translations of the word under the mouse pointer." (interactive "P") (require 'tooltip) (require 'gud) ;; The tooltips are currently part of GUD (let ((val (if arg (> (prefix-numeric-value arg) 0) (not rdictcc-tooltip-mode (if val ;; Switch tooltip mode on (progn (make-local-variable 'rdictcc-tooltip-mode) (setq rdictcc-tooltip-mode val) (make-local-variable 'tooltip-delay) (setq tooltip-delay rdictcc-tooltip-delay) (gud-tooltip-mode 1) (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) (make-local-variable 'track-mouse) (setq track-mouse val)) ;; Switch tooltip mode off (kill-local-variable 'rdictcc-tooltip-mode) (kill-local-variable 'tooltip-delay) (kill-local-variable 'track-mouse) (remove-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t --8<---cut here---end--->8--- > Anyway, I'll look at splitting out the functionality after the > release. Thanks a lot. > The pretest is meant to be imminent, but the last one for Emacs 21 > took about a year, so I wouldn't hold your breath. No problem. I'll be patient. Bye, Tassilo -- My opinions may have changed, but not the fact that I am right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> > It might be fine for personalising Emacs but not a general package. > > Your construction above adds the function to the hook at the end. So, > > for example, if that's in a buffer that I'm using for debugging, the > > tooltips will display translations of my variable names rather than > > their values, which might not be what I want. > > Sure, but my rdictcc-tooltip-mode as well as dictionary-el's tooltip > mode are buffer local. If a user enables one of them in a debugging > buffer he might really want translations. After toggling the mode off, > the GUD-tooltips will be back again. The example that you gave at the start didn't toggle anything: it just added a function to tooltip-hook. Anyway, I'll look at splitting out the functionality after the release. The pretest is meant to be imminent, but the last one for Emacs 21 took about a year, so I wouldn't hold your breath. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name doc string incorrect
> >> Is there any reason why someone contributing code should know about > >> FOR-RELEASE? I do not see any. > > > > Contributors should be aware of the burning issues, if we want them to > > spend energy where we think it's most useful. > > > CONTRIBUTE should mention that _after_ checking out the sources, > the user should read the INSTALL.CVS file. > > We can add information about FOR-RELEASE (and the admin/ directory > in general) to that file. Other stuff which is relevant for > working on emacs could be added to that file. The admin directory has files which go way beyond the needs of the average contributor. > Specifically, the section > > oSupplemental information for Emacs Developers: > > belongs in INSTALL.CVS rather than CONTRIBUTE. I'm not sure it matters much as we're just talking about a few lines. Developers are more likely to look in a file called CONTRIBUTE than INSTALL.CVS for guidelines and splitting the information makes it a bit like a treasure hunt. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name doc string incorrect
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: Richard Stallman <[EMAIL PROTECTED]> >> CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org >> Date: Tue, 04 Jul 2006 13:29:53 -0400 >> >> Is there any reason why someone contributing code should know about >> FOR-RELEASE? I do not see any. > > Contributors should be aware of the burning issues, if we want them to > spend energy where we think it's most useful. CONTRIBUTE should mention that _after_ checking out the sources, the user should read the INSTALL.CVS file. We can add information about FOR-RELEASE (and the admin/ directory in general) to that file. Other stuff which is relevant for working on emacs could be added to that file. Specifically, the section o Supplemental information for Emacs Developers: belongs in INSTALL.CVS rather than CONTRIBUTE. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > It might be fine for personalising Emacs but not a general package. > Your construction above adds the function to the hook at the end. So, > for example, if that's in a buffer that I'm using for debugging, the > tooltips will display translations of my variable names rather than > their values, which might not be what I want. Sure, but my rdictcc-tooltip-mode as well as dictionary-el's tooltip mode are buffer local. If a user enables one of them in a debugging buffer he might really want translations. After toggling the mode off, the GUD-tooltips will be back again. I mean, there are always minor modes which can conflict, so the user has to decide what he needs at a time. Enabling flyspell-mode in a buffer with elisp code will overwrite the normal font-locking, which might be exactly what the user wants. Bye, Tassilo -- VI VI VI - The Roman Number Of The Beast ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Documentation
[EMAIL PROTECTED] (Johan Bockgård) writes: > * eval-current-buffer has been obsoleted and replaced by eval-buffer. > Some places in the Emacs and Emacs Lisp manuals refer to both > eval-current-buffer and eval-buffer, some refer only to > eval-current-buffer. i've fixed those sites to use eval-buffer where it is mentioned solely. i left alone those where both eval-buffer and eval-current-buffer are mentioned. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfo-format-buffer text.texi
Eli Zaretskii schrieb:
Date: Tue, 04 Jul 2006 07:54:34 +0200
From: Andreas Roehler <[EMAIL PROTECTED]>
Calling `texinfo-format-buffer' at text.texi
produces a line
@anchor-yes-refill{Definition of sentence-end-double-space}
which is probably not correct. (Line 1408 now)
AFAIR, `texinfo-format-buffer' is unmaintained and doesn't support all
the features of the latest versions of the Texinfo language. Don't
use it; use `makeinfo' instead. (I believe the Texinfo manual says
that as well somewhere.)
makeinfo-buffer doesn't work at all with
GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2006-06-18
it even kills the output. Surprisingly all messages in
German. Program complains references at non-existing
nodes. Error-messages end with:
makeinfo: Entferne Ausgabe-Datei „../info/text“ wegen Fehler; --force
benutzen, um diese beizubehalten.
Compilation exited abnormally with code 1 at Wed Jul 5 09:07:36
The whole output at the end
Running `makeinfo-buffer' with Edebug I get the
following messages:
Loading edebug...done
Edebug: makeinfo-region
makeinfo-region
Edebug: makeinfo-next-error
makeinfo-next-error
Edebug: makeinfo-compile
makeinfo-compile
Edebug: makeinfo-compilation-sentinel-region
makeinfo-compilation-sentinel-region
Edebug: makeinfo-current-node
makeinfo-current-node
Edebug: makeinfo-buffer
makeinfo-buffer
Edebug: makeinfo-compilation-sentinel-buffer
makeinfo-compilation-sentinel-buffer
Edebug: makeinfo-recenter-compilation-buffer
makeinfo-recenter-compilation-buffer
Wrote /home/speck/texte/20060705-an-makeinfo.txt
<<< Press Return to bury the buffer list >>>
Result: "/home/speck/emacs/lispref/text.texi"
Result: nil [3 times]
Result: 1 (#o1, #x1, ?\C-a) [2 times]
Result: 0 (#o0, #x0, ?\C-@)
Result: 4639 (#o11037, #x121f) [3 times]
Result: 292 (#o444, #x124)
Result: 280 (#o430, #x118)
Result: 292 (#o444, #x124)
Result: #("../info/text" 0 12 (fontified t))
Result: "/home/speck/emacs/info/text" [5 times]
Result: nil
Result: 1 (#o1, #x1, ?\C-a)
Result: nil
Result: "Top" [4 times]
Result: "makeinfo"
Result: "--fill-column=70"
Result: "/home/speck/emacs/lispref/text.texi"
Result: "makeinfo --fill-column=70 /home/speck/emacs/lispref/text.texi"
[2 times]
Result: # [2 times]
Result: nil
Result: compilation-next-error-function [3 times]
Result: #
Result: nil
Result: makeinfo-compilation-sentinel-buffer
Wrong type argument: processp, nil
error: "Cannot return from the debugger in an error"
;;;
With Emacs -q it's the same:
Here the bug-report:
In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2006-06-18 on kiste
X server distributor `The X.Org Foundation', version 11.0.60802000
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: de_DE.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Texinfo
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-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
auto-compression-mode: t
line-number-mode: t
Recent input:
C-x C-f e m / l i s p r e f
t e x t . t x e x i M-x m a k
e i n f o - b u f f e r M-x r e p o r t -
e m a c s - b u g
Recent messages:
text.texi has auto save data; consider M-x recover-this-file
Loading texinfo...
Loading regexp-opt...done
Loading easymenu...done
Loading texinfo...done
Loading vc-cvs...done
Loading makeinfo...done
Loading emacsbug...
Source file `/usr/local/share/emacs/22.0.50/lisp/mail/sendmail.el' newer
than byte-compiled file
Loading emacsbug...done
Here the full contents of *compilation*
-*- mode: compilation; default-directory: "~/emacs/lispref/" -*-
Compilation started at Wed Jul 5 09:37:16
makeinfo --fill-column=70 /home/speck/emacs/lispref/text.texi
/home/speck/emacs/lispref/text.texi:7: nächstesverweis auf nicht
existierenden Knoten „Non-ASCII Characters“ (vielleicht @section statt
@subsection o.ä.?).
/home/speck/emacs/lispref/text.texi:7: vorigesverweis auf nicht
existierenden Knoten „Markers“ (vielleicht @section statt @subsection
o.ä.?).
/home/speck/emacs/lispref/text.texi:7: aufwärtsverweis auf nicht
existierenden Knoten „Top“ (vielleicht @section statt @subsection o.ä.?).
/home/speck/emacs/lispref/text.texi:4353: Querverweis auf nicht
existierenden Knoten „Overlay Properties“ (vielleicht @section statt
@subsection o.ä.?).
/home/speck/emacs/lispref/text.texi:4146: Querverweis auf nicht
existierenden Knoten „Coding Systems“ (vielleicht @section statt
@subsection o.ä.?).
/home/speck/emacs/lispref/text.texi:
