RE: frame-set-background-mode changes frame backgroundforspecial-display frames
Why is it correct to use the default background of
`default-frame-alist' for a special-display frame
that I explicitly assigned a different background
color?
You did not say that you assigned a different background color.
I thought I did:
I have a set of frame parameters for
special-display frames, and other sets for frames
dedicated to buffers *Help* and *Completions* (using
`special-display-buffer-names' with explicit frame
parameters). What happens is that the background colors
of these frames are not what they should be.
Sorry if that wasn't clear enough.
Please provide a _complete, self-contained test case_ for every bug
report.
I see this problem systematically in my own setup - but, as I indicated,
only with CVS snapshots newer than GNU Emacs 22.0.50.2
(i386-mingw-nt5.1.2600) of 2005-04-16 on LAPTOP Distributor `Microsoft
Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'.
I have spent a *lot* of time trying to track this down in my own setup, as I
did not succeed in starting from emacs -Q and building up with pieces of my
code to reproduce it. That's why I started my bug report with the caveat: "I
don't have a simple recipe starting from emacs -Q".
I would have thought that putting the following code in a file foo.el and
then starting emacs with emacs -Q -l "foo.el" might be enough to reproduce
the bug (e.g. trying `C-h i'), but it is not enough. I must be doing
something more in my setup that manifests the bug.
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
(setq minibuffer-frame-alist
(append (list (cons 'minibuffer 'only)
(cons 'background-color "PaleGoldenrod"))
minibuffer-frame-alist))
(setq default-frame-alist
(append (list '(minibuffer)
(cons 'background-color "LightBlue"))
default-frame-alist))
(setq special-display-frame-alist
(append (list (cons 'background-color "LightSteelBlue"))
special-display-frame-alist))
(setq pop-up-frames t
pop-up-frame-alist (append default-frame-alist pop-up-frame-alist))
(setq my-minibuffer-frame (make-frame minibuffer-frame-alist))
Sorry, but I cannot do better than the description I gave. Please take a
look at the code that I found was causing the frames to change background
color. Hopefully it will provide some clue; in my setup, it is the culprit.
What I can't tell you is what there is in my setup that works together with
that code to cause the problem. I can say that my code works fine with Emacs
versions from 20.7 through the April 2005 CVS Emacs 22 snapshot. It's
possible that my code has always done something wrong that was always
tolerated before and is no longer, correctly. I suspect, instead, that a bug
was introduced into Emacs after April 2005.
I doubt that you want me to send multiple libraries to reproduce part of my
setup, and I don't have the time needed to narrow the problem down further
and provide a self-contained test case. I think that's the best I can do
now. If you could recognize a problem in the code in question, then that
would be good. If not, too bad for me. Thanks for taking a look.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: frame-set-background-mode changes frame background forspecial-display frames
Why is it correct to use the default background of `default-frame-alist' for a special-display frame that I explicitly assigned a different background color? You did not say that you assigned a different background color. Please provide a _complete, self-contained test case_ for every bug report. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Graphics files in archives cannot be toggled to display image or code
Am 01.04.2006 um 15:45 schrieb Richard Stallman: Can you debug why it fails? It ought to work. It works with ZIP archives that open in archive-mode. TAR files open in tar-mode. In image-mode.el we have now: 140 (let* ((image 141 (if (and (buffer-file-name) 142(not (buffer-modified-p)) 143(not (and (boundp 'archive-superior-buffer) 144 archive-superior-buffer))) 145 (progn (clear-image-cache) 146 (create-image (buffer-file-name))) 147 (create-image 148 (string-make-unibyte 149 (buffer-substring-no-properties (point-min) (point-max))) 150 nil t))) Archive-superior-buffer is set by ZIP archives, so they are treated differently here with clear-image-cache and clear-image. Or TAR files are treated that way -- I don't understand the code, but here's the difference that might explain why image-mode works for ZIP archives and not for TAR files. Well, that's actually your patch ... One thing this patch achieves is that *Messages* does not contain any more Cannot find image file `/Users/pete/Quellen/Emacs_CVS/ graphics_test_tar/images.tar!image.xbm' [2 times] Cannot find image file `/Users/pete/Quellen/Emacs_CVS/ graphics_test_tar/images.tar!image.xpm' [2 times] -- Greetings Pete Increase the size of your bike by at least *five* inches ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Graphics files in archives cannot be toggled to display image or code
Am 01.04.2006 um 15:45 schrieb Richard Stallman:
Can you debug why it fails?
It ought to work.
I am starting and I am observing with some files, when I toggle from
the initial image to the code view and then back to image, only code
is shown, and it's only a part of the code that is displayed. It
happens with JPG, PGM, PPM, TIFF. With XPM the columns are "encoded"
as lines, and I mean encoded:
/* XPM */
static char *image[] = {
/* width height num_colors chars_per_pixel */
"8880 2562",
/* colors */
".. c #040909",
".# c #748774",
".a c #bcc6a0",
".b c #414629",
".c c #ac946c",
".d c #dce6bc",
becomes
"aV#.#.bj.i#.an.p.B#Pabbj#.#.aLbj.E.E#2an#f.I#Uan#XacacaLbR#HaV.E#MbIa1
aW.jbX#Na5#wb.#w#1.za5#K.Haoapap..bY#x#x#l#F#R#F.#bk.j#o#N.H#F#R.N.E.EaG
bVa.#N.w.H.Ha.#5#5.VaV#HaVaVaVaVaV",
"#.a3#.abbnaMb0.i.BaM.i.i.BbMaM.iaMb2.L#U#AaE#2#0bR#HaLaV#H#.#H.Ba.#o#o
bua5a5bhb3a5#lao.HbJ#D.w.Ta5aAbmaA#laAapaN.Ybnbhbt#Nbub3#QbY#5.W#B#X#0.B
bW.4#Qat#Q#Q#Qb3ao.Tac#HaV#HaVaVaV",
"aVaVaLanbW.Cbe#Fbyby#F.zbV.C.C.C#M#M#Mbe#faE.E.6aLaVaVaV#HaL.
6.i#Q.G#ibq#i#ibq#i..#i.Gbz.H#D#w.Hbm#x.T.Vby#lbYbq.Ybn#l.G#lbh.l.G#x.z#
2#Xa7.Q.E#R#l#Q..#ibq..#i#Qaj#0aVaVaV#HaVaV",
--
Greetings
Pete
There's no sense in being precise when you don't
even know what you're talking about.
-- John von Neumann
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-abbrev-file function
Richard Stallman wrote: > Thanks for reporting the bug. I wrote a cleaner fix. > Until it's in the CVS-rep; Here the present state of art: ;; Bugged: read-abbrev-file function in abbrev.el ;; The `(interactive "f' - kontroll-letter takes just ;; the current buffer-file if you quit the demand ;; with RET. That's not what you want: If the file is ;; already open, there is no need to call ;; `read-abbrev-file', the `default-abbrev-file' should ;; be called in the case of no specified user input. ;; Fixed: ;; Loads the default-abbrev-file unless no file is specified. (defalias 'read-abbrev-file 'read-abbrev-file-ar) (defun read-abbrev-file-ar (&optional file quietly) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'. Optional second argument QUIETLY non-nil means don't print anything." (interactive (list ;; clear unavertedly inserted whitespaces (string-strip (read-from-minibuffer (concat "default: " abbrev-file-name)) t t))) (load (if (and file (> (length file) 0)) file abbrev-file-name) nil quietly) (setq abbrevs-changed nil)) ;; Function needed to clear unavertedly by users ;; inserted whitespaces ;; Source: comment-string-strip, newcomment.el, GNU Emacs 22.0.50.1;; (defun string-strip (str beforep afterp) "Strip STR of any leading (if BEFOREP) and/or trailing (if AFTERP) space. " (string-match (concat "\\`" (if beforep "\\s-*") "\\(.*?\\)" (if afterp "\\s-*\n?") "\\'") str) (match-string 1 str)) ;; Bugged: quietly-read-abbrev-file: ;; old: ;; Interactive calls have been disabled from ;; quietly-read-abbrev-file, probably to avoid the bug ;; with the `f'-interactive-kontroll-letter ;; new: `interactive' reinstalled (defun quietly-read-abbrev-file-ar (&optional file) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'. Does not display any message." (interactive) (read-abbrev-file-ar file t)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Send Bug Report is worse
On 3 Apr 2006, at 15:29, Jason Rumney wrote:
David Reitter wrote:
Lennart Borgman proposed to do this on Windows systems. That's
because apparently, long mailto:// URLs aren't supported well.
Lennart, do you think we can be more specific here and only enable
it when it's really needed, e.g. on old Windows installations?
I don't think the need for this is limited to old installations.
Windows has a 1024 byte limit to command-lines in general AFAIK.
OK, the limitation is due to ShellExecute (which is what's obviously
used on Windows, see `w32-shell-execute').
The mailto:// business in mailclient is a kludge, lacking a cross-
platform API.
The correct way to send an e-mail on Windows would be the mail API
("MAPI").
There is already an implementation of this available, even though
goes through Visual Basic:
http://www.emacswiki.org/cgi-bin/wiki/w32-send-mapi.el
One could take such a piece of code and implement an interface on the
C side to avoid the VB script. We could integrate that with
mailclient, and everyone would be happy.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Send Bug Report is worse
Jason Rumney wrote: David Reitter wrote: Lennart Borgman proposed to do this on Windows systems. That's because apparently, long mailto:// URLs aren't supported well. Lennart, do you think we can be more specific here and only enable it when it's really needed, e.g. on old Windows installations? I don't think the need for this is limited to old installations. Windows has a 1024 byte limit to command-lines in general AFAIK. Are you aware of that this includes the body too (body=...). It is even url encoded. I think there is quite a good chance that the mail url is bigger than 1024 bytes. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C indentation error.
Hi, Michael, Tim and Richard!
On Sun, 19 Mar 2006, Michael Cadilhac wrote:
>> > I got an error with some C indentation in macro definitions in GNU
>> > Emacs 22.0.50.34 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
>> > 2006-03-02.
>> > Error is triggered by:
>> > With emacs -Q :
>> > In scratch, insert the following:
>> > #foo :\
>> > bar
>> > Toggle to c-mode, and try to indent the last line.
>> > I get: Invalid search bound (wrong side of point).
, and on Fri, 24 Feb 2006, Tim Millet wrote:
> The following typedef describes the problem. It shows that when the
> struct member is of a user defined type, the bitfield specification
> causes the line syntax to be mistaken. The first struct member uses a
> builtin type and the indentation is correct. This problem didn't occur
> in version 5.28
> typedef struct {
> int chanCnt:5; // correct indentation
> u_char_t chanCntRsvd:3; // INCORRECT indentation
> } CbChanCnt_t;
The following patch should fix both of these bugs. :-) Would you please
try it out and get back to me on [EMAIL PROTECTED] if it doesn't.
Unless there are problems with it, I will release this fix with the next
CC Mode release (5.31.4), whence it will find its way into the Emacs CVS
at savannah.gnu.org.
*** ../cc-mode-5.32.cvs/cc-engine.elSun Feb 19 11:19:05 2006
--- cc-engine.elSun Apr 2 15:35:42 2006
***
*** 5791,5807
nil
(defun c-forward-label (&optional assume-markup preceding-token-end limit)
! ;; Assuming the point is at the beginning of a token, check if it
! ;; starts a label and if so move over it and return t, otherwise
! ;; don't move and return nil. The end of the label is taken to be
! ;; the end of the first submatch in `c-opt-extra-label-key' if it
! ;; matched, otherwise it's the colon. The point is directly after
! ;; the end on return. The terminating char is marked with
! ;; `c-decl-end' to improve recognition of the following declaration
! ;; or statement.
;;
;; If ASSUME-MARKUP is non-nil, it's assumed that the preceding
! ;; label, if any, has been marked up like that.
;;
;; If PRECEDING-TOKEN-END is given, it should be the first position
;; after the preceding token, i.e. on the other side of the
--- 5791,5822
nil
(defun c-forward-label (&optional assume-markup preceding-token-end limit)
! ;; Assuming the point is at the beginning of a token, check if it starts a
! ;; label and if so move over it and return t, otherwise don't move and
! ;; return nil. "Label" here means "most things with a colon".
! ;;
! ;; More precisely, a "label" is regarded as one of:
! ;; (i) a goto target like "foo:";
! ;; (ii) A case label - either the entire construct "case FOO:" or just the
! ;; bare "case", should the colon be missing;
! ;; (iii) a keyword which needs a colon, like "default:" or "private:";
! ;; (iv) One of QT's "extended" C++ variants of
! ;; "private:"/"protected:"/"public:"/"more:" looking like "public slots:".
! ;; (v) One of the keywords matched by `c-opt-extra-label-key' (without any
! ;; colon). Currently (2006-03), this applies only to Objective C's
! ;; keywords "@private", "@protected", and "@public".
! ;;
! ;; One of the things which will NOT be recognised as a label is a bit-field
! ;; element of a struct, something like "int foo:5".
! ;;
! ;; The end of the label is taken to be just after the colon, or the end of
! ;; the first submatch in `c-opt-extra-label-key'. The point is directly
! ;; after the end on return. The terminating char gets marked with
! ;; `c-decl-end' to improve recognition of the following declaration or
! ;; statement.
;;
;; If ASSUME-MARKUP is non-nil, it's assumed that the preceding
! ;; label, if any, has already been marked up like that.
;;
;; If PRECEDING-TOKEN-END is given, it should be the first position
;; after the preceding token, i.e. on the other side of the
***
*** 5817,5824
;;
;; This function might do hidden buffer changes.
! (let ((start (point)))
(cond
((looking-at c-label-kwds-regexp)
(let ((kwd-end (match-end 1)))
;; Record only the keyword itself for fontification, since in
--- 5832,5842
;;
;; This function might do hidden buffer changes.
! (let ((start (point))
! qt-symbol-idx
! macro-start); if we're in one.
(cond
+ ;; "case" or "default" (Doesn't apply to AWK).
((looking-at c-label-kwds-regexp)
(let ((kwd-end (match-end 1)))
;; Record only the keyword itself for fontification, since in
***
*** 5838,5844
(match-beginning 2))
(progn
! (goto-char (match-beginning 2))
(c-put-c-type-property (1- (point)) 'c-decl-end)
Re: C indentation error.
Alan Mackenzie <[EMAIL PROTECTED]> writes:
> Hi, Michael, Tim and Richard!
And hi everybody !
>>> > #foo :\
>>> > bar
>> typedef struct {
>> int chanCnt:5; // correct indentation
>> u_char_t chanCntRsvd:3; // INCORRECT indentation
>> } CbChanCnt_t;
>
> The following patch should fix both of these bugs. :-) Would you please
> try it out and get back to me on [EMAIL PROTECTED] if it doesn't.
Yes, that makes it :-) The error is no longer triggered.
Anyway, as I check the file where I had the error, and re-indent it,
I've a more or less unexpected behavior :
#define CHOICE_COMMAND(N, Command) \
case N: \
if ((Command) != ERROR) \
return false; \
break;
The « break » keyword is badly indented ; if I remove the line with
the #define, it could come back indented at the right place.
I'm saying « more or less » because I agree it's not a common use.
Greetings,
--
Michael Cadilhac, a.k.a. Micha [mika] |
Epita/LRDE promo 2007 | )\._.,--,'``.
123 av. de Fontainebleau | 08.70.65.13.14 | /. _.. \ _\ (` ._,.
94270 Le Kremlin Bicetre | 06.23.20.31.30 | '._.-(,_..'--(,_...`-..'
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: frame-set-background-mode changes frame background forspecial-display frames
The value of that :background attribute is the default background for `default-frame-alist' - that is, for non-special frames. So, what happens is that the `default' face for the new, special frame has its background set to the default value of the default face for the default-frame-alist. That seems like the right thing for it to do. Why is it correct to use the default background of `default-frame-alist' for a special-display frame that I explicitly assigned a different background color? As I said, in the beginning of an Emacs session, creating a special frame uses the correct background color. But if I delete the frame and then redisplay the buffer in a new frame (also special - should be exactly the same, following my specification), that frame has the default background of `default-frame-alist', not the special-display background I assigned. And from then on, `special-display-frame-alist' is not respected. Changing the background of face `default' is tantamount to changing the background of the frame itself, so as soon as this face-attribute change is made, displaying (frame-parameters ) shows that its background has been changed to the default background for default-frame-alist. Yes, that's normal, right? Why do you consider this wrong? Is it that you do something else to specify the background for that special display frame? If so, could you show precisely what? As I said, I use `special-display-frame-alist' (or, for the *Help*, *Completions*, and minibuffer frames, `special-display-buffer-names' with explicit frame properties) to specify the background colors of special-display frames. I want special frames to *always* have the backgrounds I assign to them via `special-display-frame-alist' (or `special-display-buffer-names'). I don't want them to change. This bug completely breaks the normal assignment of background colors to special-display frames - my assignments are not respected (or, some are at first, but then the background is changed). At the beginning of an Emacs session, `special-display-frame-alist' and `special-display-buffer-names' seem to be respected. After the code I detailed gets executed once, however, they are no longer respected. Note: it is not always the background color of the `default-frame-alist' that ends up getting used for special-display frames. Sometimes it is the background color of the previously selected frame. For example, a new special-display frame might be created with the color of the minibuffer frame or the *Help* frame, instead of the background color specified by `special-display-frame-alist'. IOW, the background of one frame is propagated to the next new frame created, with no attention paid to the colors specified in `special-display-frame-alist' and `special-display-buffer-names'. This is definitely incorrect behavior - `frame-set-background-mode' should not, as a side effect, also change the background *color*. If this is the intended behavior, that is, if there is no way to assign background colors to special-display frames and have those colors continue to be respected, then I guess I'll never move to Emacs 22, because it is unusable for me in that case. But in that case I'd be curious to hear *why* this is the intended behavior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Send Bug Report is worse
David Reitter wrote: Lennart Borgman proposed to do this on Windows systems. That's because apparently, long mailto:// URLs aren't supported well. Lennart, do you think we can be more specific here and only enable it when it's really needed, e.g. on old Windows installations? I don't think the need for this is limited to old installations. Windows has a 1024 byte limit to command-lines in general AFAIK. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Send Bug Report is worse
On 3 Apr 2006, at 08:48, Reiner Steib wrote: On Mon, Apr 03 2006, Richard Stallman wrote: This message: "*** E-Mail body has been placed on clipboard, please paste them here! ***" I don't see that message when I use it. It must be specific to some aspect of your configuration. Where does it come from? The message comes from `mailclient-send-it' which is the default `send-mail-function' on some platforms: This method of transferring the body to the mail client is (by default) only used on Windows, where the default of `mailclient-place- body-on-clipboard-flag' is non-nil. http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00660.html Lennart Borgman proposed to do this on Windows systems. That's because apparently, long mailto:// URLs aren't supported well. Lennart, do you think we can be more specific here and only enable it when it's really needed, e.g. on old Windows installations? I agree the message needs to be revised syntactically, I'll do that when improving the default for `mailclient-place-body-on-clipboard- flag'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Send Bug Report is worse
On Mon, Apr 03 2006, Richard Stallman wrote: > This message: > > "*** E-Mail body has been placed on clipboard, please paste > them here! ***" > > I don't see that message when I use it. It must be specific to some > aspect of your configuration. Where does it come from? The message comes from `mailclient-send-it' which is the default `send-mail-function' on some platforms: (defcustom send-mail-function (if (and window-system (memq system-type '(darwin windows-nt))) 'mailclient-send-it 'sendmail-send-it) "Function to call to send the current buffer as mail. [...]) `mailclient-send-it' tries to delegate the mail message to the system's default mail client. There have been suggestions to improve the message during a related discussion about `message-send-mail-function' on emacs-devel. (Cc-ing David Reitter, the author of `mailclient.el') Bye, Reiner. [1] See subject "gnus / message-send-mail-with-mailclient" in March. http://thread.gmane.org/[EMAIL PROTECTED] -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-abbrev-file function
Richard Stallman wrote: > Thanks for reporting the bug. I wrote a cleaner fix. > Please send copy of the fix, couldn't see it in the CVS-Rep. AFAIS there is a related bug in abbrev.el, the fix depends on the way `read-abbrev-file' is written: ;; Bugged: quietly-read-abbrev-file: ;; old: Interactive calls have been disabled from ;; quietly-read-abbrev-file, probably to avoid ;; disturbance caused by the ;; `f'-interactive-kontroll-letter bug ;; new: `interactive' reinstalled (defun quietly-read-abbrev-file-ar (&optional file) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'. Does not display any message." (interactive) (read-abbrev-file-ar file t)) __ Andreas Roehler PS.: Meanwhile I rewrote `read-abbrev-file' with `cond', so its better to read: (defun read-abbrev-file-ar (&optional file quietly) "Read abbrev definitions from file written with `write-abbrev-file'. Optional argument FILE is the name of the file to read; it defaults to the value of `abbrev-file-name'. Optional second argument QUIETLY non-nil means don't print anything." (interactive) (let* ((abbrevs-to-load (cond ((when (boundp file)) file) ;; if quietly was specified but no file given, ;; load default abbrev-file ((when quietly abbrev-file-name)) ;; clear unavertedly inserted whitespaces ((string-strip (read-from-minibuffer (concat "default: " abbrev-file-name)) t t) (when (string= abbrevs-to-load "") (setq abbrevs-to-load abbrev-file-name)) (load abbrevs-to-load nil quietly)) (setq abbrevs-changed nil)) ;; Function needed to clear unavertedly by users ;; inserted whitespaces ;; Source: comment-string-strip, newcomment.el, GNU Emacs 22.0.50.1;; (defun string-strip (str beforep afterp) "Strip STR of any leading (if BEFOREP) and/or trailing (if AFTERP) space. " (string-match (concat "\\`" (if beforep "\\s-*") "\\(.*?\\)" (if afterp "\\s-*\n?") "\\'") str) (match-string 1 str)) ;; end ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
