Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > > | (setq track-mouse on)) >^^^ t? Just a typo. > > | (defun my-tooltip-function (event) > > | (interactive "e") > > | ;; process event... > > | (tooltip-show "Huzzah!")) > > ` > > This didn't seem to work very well on Emacs 21 when I tried it. Also > there's no mechanism to remove my-tooltip-function from tooltip-hook. > > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Indeed, this works. > > This convenient approach (used for example by dictionary-el) > > doesn't work anymore in Emacs 22. > > dictionary-el isn't part of Emacs 22. I have split GUD tooltips > (which use track-mouse from ordinary ones (which don't). dictionary-el and my own mode display tooltips based on the word under the mouse pointer. The event based approach makes it easy to extract the word. If there's a better way, please let me know. Currently I use an own timer an lots of ugly code to work arround this. > This means that they can be toggled independently. At some stage, if > other packages want to use tooltips in the way GUD does, that part > could be split out of gud.el. That would be really nice. Bye, Tassilo -- A child of five could understand this! Fetch me a child of five! ___ 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
> Many projects have a file called CONTRIBUTE. I think we should do this > also. There a many things that could go into it, but in particular we > could stress that new features should be documented (or at the least > noted in NEWS). Perhaps it should be made as a condition of the > commit. > > I don't understand what you are proposing; the proposal is incomplete. > Perhaps you are trying to solve the problem which we have already > solved by marking +++ in etc/NEWS. I am proposing that developers always document the changes they make. This often happens but its not always the case. The most common example of not updating documentation is adding an argument to a lisp function. Adding items to etc/NEWS is not immediately obvious to new developers and only mentioned in an ad hoc manner. The CONTRIBUTE file is not just about documentation, it mentions coding standards, copyright assignment, mailing lists, how to submit a patch etc. Some of these are described in the manual but not with a regular contributor in mind. In GDB I read CONTRIBUTE first, so I knew what was wanted. In Emacs I just stumbled along. -- 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 bugs
Well, I don't really care what you do with my bug report, but my point is that (I believe that) it does *not* reliably do the right thing. It does the right thing only if there is in fact no list of faces that matches ((foreground-color . "Firebrick")...). They have different data layouts; there is no way one could match the other. OK. So why (seemingly) test for (not (memq (car faceprop) '(foreground-color background-color? That test presumably is meant to exclude such an old-format attribute list. The test 1) doesn't do that and 2) is unnecessary, as you point out: such a list can never be confused with a list of faces. As I said: If you don't care about this case, then you are better off removing this part of the code - it simply does not serve any purpose. Either you rely upon no feasible confusion of a face list with the form above (in which case the test is not needed), or you worry about such possible confusion (in which case it does not work). In sum, the code is either useless or ineffective in doing what it tries to do. (foreground-color . "Firebrick") will *never be encountered*, so there is no reason to test for it. That is what (not (memq (car faceprop) '(foreground-color background-color does - uselessly. (:foreground "Firebrick"...) will be encountered, but it is filtered out by this test: (not (keywordp (car faceprop))). ((foreground-color . "Firebrick")...) will also be encountered, and it is not filtered out by the keywordp test, but, as you say, this form will never be taken for a list of faces. It gets excluded not by any explicit test, but by a failed attempt to treat it as a list of faces (the dolist). All I'm saying is that the test (not (memq (car faceprop) '(foreground-color background-color))) is 100% useless - it corresponds to nothing. ___ 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
> The main checking that is needed here is accuracy checking. Is the > information correct? Have the changes in etc/NEWS made it wrong? > So you need to reread NEWS, then read the text, and check the facts > it states. I've looked through etc/NEWS and AFAICS all the significant items have been updated. Checking undocumented details can now only really be done by trawling through the ChangeLogs. I think there is a misunderstanding about the job at hand. We know that the important items in etc/NEWS have been documented in the manuals, because we marked those items with +++ when this was done. However, just because we document the change in the manual does not mean that everything is accurate. We document the change in the principal place that the issue is referred to. But there can easily be other places that refer to the issue tangentially. They might need updating. So the job here is to check all the side-references, the examples, etc. Many projects have a file called CONTRIBUTE. I think we should do this also. There a many things that could go into it, but in particular we could stress that new features should be documented (or at the least noted in NEWS). Perhaps it should be made as a condition of the commit. I don't understand what you are proposing; the proposal is incomplete. Perhaps you are trying to solve the problem which we have already solved by marking +++ in etc/NEWS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name bugs
Well, I don't really care what you do with my bug report, but my point is that (I believe that) it does *not* reliably do the right thing. It does the right thing only if there is in fact no list of faces that matches ((foreground-color . "Firebrick")...). They have different data layouts; there is no way one could match the other. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
delete-indentation - text.texi
I'm afraid, `delete-indentation' is labeled from a side affect of two other functions: join-lines and fixup-whitespace, implemented in C however. From a function `delete-indentation' I wouldn't expect the behavior as it is now (and shown below) -- Buffer: foo -- When in the course of human -!-events, it becomes necessary -- Buffer: foo -- (delete-indentation) => nil -- Buffer: foo -- When in the course of human-!- events, it becomes necessary -- Buffer: foo -- rather -- Buffer: foo -- When in the course of human -!-events, it becomes necessary -- Buffer: foo -- (delete-indentation) => nil -- Buffer: foo -- When in the course of human -!-events, it becomes necessary -- Buffer: foo -- Deleting indentation has no inert connection with deleting newline-chars, AFAIU. Altogether the false `delete-indentation'-function takes the place of the real one in this bad world! :) __ Andreas Roehler ___ 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: > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Simply change (tooltip-mode 1) to (gud-tooltip-mode 1) seems work well. Hope someone can make a proper patch for dictionary-el. It's a nice feature. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
