Re: custom bug
> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > (defcustom foo 'foo > "doc string" > :type '(choice (const foo) (const bar))) > When I chose `bar', the value disappears in the screen. There was already this issue in another board: http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=17034/force_load=t Sorry for the noise. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
custom bug
Hi, Please try customizing the following option: (defcustom foo 'foo "doc string" :type '(choice (const foo) (const bar))) When I chose `bar', the value disappears in the screen. Even if I press the [Set for Current Session] button or the [Save for Future Sessions] button, the value is still hidden. I need to press the [Hide Value] button twice or the [Erase Customization] button to see the value. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
> > While it helps to just report bugs and with due respect, it's not > > reasonable to claim that the Emacs developers don't give the Window port a > > high priority, > > If you could cite from a message where I _claimed_ that, it would be > much easier for me to respond to that. I'm not asking you to respond to it, just to reflect on it. > After rereading my message, I think I didn't claim anything about Emacs > development, but only wrote up some personal experiences I've made with > Emacs on Windows during the last years. I was referring to: Peter Tury> I hope you can regenerate the situation easily and fix this bug. SH> I hope so, too. But unfortunately, given the fact that it's known for SH> nearly two years, I don't think the issue has high priority for the SH> developers. If that's related to the fact that it's only present in the SH> Windows port, I don't know. SH> At this time, you can't tell a person from Windows island to have a look SH> at LaTeX & Emacs+AUCTeX. He'd laugh at you and say: "It can't even SH> scroll your files without flickering. I like Office SH> better." Well, I don't know what auditorium Emacs targets to. But it's SH> obviously not (new) Windows users. First impression failed. > > if you're not in a position to even test the patches which are > > provided. > > Even if I were able to compile and test patches I don't think that > brought me into a position to claim anything about Emacs development. It would give your opinion more weight. > I'll try my best to make my points more clear in the future, but > honestly, I can't see yours. Currently, I tend to guess you're trying > to say: "You'd better shut up as long as you're not an active > developer!" Not at all. Just that the state of the Windows port reflects the level of contributions from the user community, of which you are a part. -- 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: unclear doc for existence of mark
I will clarify this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
Nick Roberts schrieb: > > > > Unfortunately, I have only a dial-up connection and can't give > > > > immediate feedback on new Emacs versions. > > > > > > One advantage of using CVS over tarballs is that you only need to > download > > > the (compressed) _changes_. Even with a dial-up connection that > shouldn't > > > take a long time. > > > > Thanks for the hint. I am already familiar with rcs, actually. But I > > didn't set up a proper environment for compiling Emacs by myself yet. > > There just wasn't much use in that so far. :) > > While it helps to just report bugs and with due respect, it's not reasonable > to > claim that the Emacs developers don't give the Window port a high priority, If you could cite from a message where I _claimed_ that, it would be much easier for me to respond to that. After rereading my message, I think I didn't claim anything about Emacs development, but only wrote up some personal experiences I've made with Emacs on Windows during the last years. In fact, in >>> Personally, I'd categorize this bug as a show-stopper for a >>> stable release. On the other hand, I don't know if Windows is an >>> officially supported platform. Could someone please clarify >>> that? And what user base does Emacs target to? I finally asked about the relevance of the Windows port, but couldn't see an answer or a pointer to some manifest or such so far. Honestly, it's not clear to me how Emacs and Windows relate. > if you're not in a position to even test the patches which are > provided. Even if I were able to compile and test patches I don't think that brought me into a position to claim anything about Emacs development. I'll try my best to make my points more clear in the future, but honestly, I can't see yours. Currently, I tend to guess you're trying to say: "You'd better shut up as long as you're not an active developer!" I could agree that this is not the right list. > Some developers work hard on that very issue, Sorry, for bothering you (all). I didn't notice that. To my defence, not being a developer, I don't see how I could have got aware of what's going on behind the scenes other than testing pre-built binaries from time to time and reading several Emacs related mailing lists (watching just this item). Best regards, Stephan Hennig ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Incorrect advice how to restore previous window
emacs -q
C-h C-n
C-x 2
M->
.. Now we have two windows showing different parts of the NEWS buffer.
C-h k k
.. The lower window now shows the *Help* buffer.
.. And the echo area says:
Type C-x 4 C-o to restore the other window.
But that's not true - for several reasons:
1) It suggests displaying the *scratch* buffer, not NEWS.
2) Even if I explicitly enters NEWS to the prompt, nothing changes,
as NEWS is already shown in the upper window.
3) And even _if_ it would have shown NEWS in the lower window,
it would have shown the wrong part of the file, namely the
same portion as is shown in the upper window.
Except for a lot of book-keeping via the pre-command-hook, there is
currently NO WAY Emacs can restore that lower window.
To be able to do that, we need some hook which allows us to record
what was shown in the window before displaying something else in it,
and what the window point was in that window.
Other settings might also need to be saved, but that's the minimum
we need.
The following patch add a "change-window-buffer-functions" hook:
*** window.c11 Feb 2007 21:37:29 +0100 1.573
--- window.c20 Feb 2007 17:11:57 +0100
***
*** 201,207
static int window_initialized;
! /* Hook to run when window config changes. */
Lisp_Object Qwindow_configuration_change_hook;
Lisp_Object Vwindow_configuration_change_hook;
--- 201,213
static int window_initialized;
!
! /* Hook to run before setting window buffer. */
!
! Lisp_Object Qchange_window_buffer_functions;
! Lisp_Object Vchange_window_buffer_functions;
!
! /* Hook to run after window config changes. */
Lisp_Object Qwindow_configuration_change_hook;
Lisp_Object Vwindow_configuration_change_hook;
***
*** 3275,3280
--- 3281,3293
struct buffer *b = XBUFFER (buffer);
int count = SPECPDL_INDEX ();
+ if (run_hooks_p
+ && BUFFERP (w->buffer)
+ && ! NILP (Vrun_hooks)
+ && ! NILP (Vchange_window_buffer_functions))
+ run_hook_with_args_2 (Qchange_window_buffer_functions,
+ window, buffer);
+
w->buffer = buffer;
if (EQ (window, selected_window))
***
*** 7289,7294
--- 7302,7311
Qtemp_buffer_show_hook = intern ("temp-buffer-show-hook");
staticpro (&Qtemp_buffer_show_hook);
+ Qchange_window_buffer_functions
+ = intern ("change-window-buffer-functions");
+ staticpro (&Qchange_window_buffer_functions);
+
staticpro (&Vwindow_list);
minibuf_selected_window = Qnil;
***
*** 7489,7494
--- 7506,7518
The selected frame is the one whose configuration has changed. */);
Vwindow_configuration_change_hook = Qnil;
+ DEFVAR_LISP ("change-window-buffer-functions",
+ &Vchange_window_buffer_functions,
+ doc: /* List of functions to call before changing buffer in window.
+ Each function is called with two arguments, the existing window and
+ its new buffer. */);
+ Vchange_window_buffer_functions = Qnil;
+
defsubr (&Sselected_window);
defsubr (&Sminibuffer_window);
defsubr (&Swindow_minibuffer_p);
One way to use this hook would be to keep a "restore-window-buffer-ring"
which could allow gradually "undoing" previous switch-to-buffer commands.
I've not written the code to do that (there are many ways this could
be done)
So here is just a trivial example of using the new hook to restore
the window used for the *Help* buffer.
(defvar last-help-window-buffer nil)
(defun my-change-window-buffer-hook (w b)
(if (string= (buffer-name b) "*Help*")
(setq last-help-window-buffer (list w (window-buffer w) (window-point
w)
(add-hook 'change-window-buffer-functions 'my-change-window-buffer-hook)
(defun restore-help-window-buffer ()
(interactive)
(if (and last-help-window-buffer
(window-live-p (car last-help-window-buffer))
(buffer-live-p (cadr last-help-window-buffer)))
(progn
(set-window-buffer (car last-help-window-buffer)
(cadr last-help-window-buffer))
(set-window-point (car last-help-window-buffer)
(nth 2 last-help-window-buffer)))
(call-interactively 'display-buffer)))
(global-set-key [kp-divide] 'restore-help-window-buffer)
--
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
Comint bug
Hi, comint-read-input-ring uses the default value of comint-input-ring-size instead of the buffer-local one when reading the ring from disk. Patch attached. Thanks, andreas Index: ChangeLog === RCS file: /sources/emacs/emacs/lisp/ChangeLog,v retrieving revision 1.10710 diff -c -0 -r1.10710 ChangeLog *** ChangeLog 19 Feb 2007 19:42:10 - 1.10710 --- ChangeLog 20 Feb 2007 22:29:56 - *** *** 0 --- 1,5 + 2007-02-20 Andreas Seltenreich <[EMAIL PROTECTED]> + + * comint.el (comint-read-input-ring): Use comint-input-ring-size + from the comint buffer instead of the temporary one. + Index: comint.el === RCS file: /sources/emacs/emacs/lisp/comint.el,v retrieving revision 1.357 diff -c -r1.357 comint.el *** comint.el 31 Jan 2007 13:20:52 - 1.357 --- comint.el 20 Feb 2007 22:30:53 - *** *** 896,902 ;; Watch for those date stamps in history files! (goto-char (point-max)) (let (start end history) ! (while (and (< count comint-input-ring-size) (re-search-backward comint-input-ring-separator nil t) (setq end (match-beginning 0))) (if (re-search-backward comint-input-ring-separator nil t) --- 896,902 ;; Watch for those date stamps in history files! (goto-char (point-max)) (let (start end history) ! (while (and (< count size) (re-search-backward comint-input-ring-separator nil t) (setq end (match-beginning 0))) (if (re-search-backward comint-input-ring-separator nil t) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
> > > Unfortunately, I have only a dial-up connection and can't give > > > immediate feedback on new Emacs versions. > > > > One advantage of using CVS over tarballs is that you only need to download > > the (compressed) _changes_. Even with a dial-up connection that shouldn't > > take a long time. > > Thanks for the hint. I am already familiar with rcs, actually. But I > didn't set up a proper environment for compiling Emacs by myself yet. > There just wasn't much use in that so far. :) While it helps to just report bugs and with due respect, it's not reasonable to claim that the Emacs developers don't give the Window port a high priority, if you're not in a position to even test the patches which are provided. Some developers work hard on that very issue, -- 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: (push-mark N t t) doesn't activate region in virgin buffer
"Drew Adams" <[EMAIL PROTECTED]> writes: > emacs -Q > M-x transient-mark-mode ; turn it on > M-: (goto-char (point-min)) > M-: (mark t) ; returns nil > M-: (push-mark 20 t t) > M-: (mark t) ; returns 20 > M-: mark-active ; returns nil > > The region is not activated by the call to push-mark Yes, it is. Your recipe doesn't prove what you think it proves. (progn (push-mark 20 t t) mark-active) => t -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No refresh of buffer before popup-menu
There still seems to be some problems with refreshing buffer contents. In the example below the buffer gets refreshed before the first popup menu, but not before the second popup menu. Do emacs -Q Paste the code into *scratch* and eval it: > (defun temp-test1() (interactive) (goto-char (point-max)) (insert ";; SOME STRING 1\n") (sit-for 0) (let ((pop-map (make-sparse-keymap "Temp map 1"))) (define-key pop-map [pop-map-test] (list 'menu-item "This 1" 'temp-test2 )) (popup-menu pop-map))) (defun temp-test2() (interactive) (goto-char (point-max)) (insert ";; SOME STRING 2\n") (sit-for 0) (let ((pop-map (make-sparse-keymap "Temp map 2"))) (define-key pop-map [pop-map-test] (list 'menu-item "This 2" (lambda() (interactive) (message "This is 2!" (popup-menu pop-map))) <<< Then first do M-x temp-test1 Note that the text SOME STRING 1 gets insert into the buffer before the first popup menu is shown. However the second string SOME STRING 2 does not get inserted before the second popup menu. Then do M-x temp-test2 Now SOME STRING 2 gets insert inserted in the buffer before the popup menu. So there seem to be a problem with refresh and 2 popup menus in a row. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock: doesn't colour non-ascii dash in string correctly
Chris Moore <[EMAIL PROTECTED]> writes: > describe-char tells me it's: [...] > hardcoded face: escape-glyph (info "(emacs)Text Display") Some character sets define "no-break" versions of the space and hyphen characters, which are used where a line should not be broken. Emacs normally displays these characters with special faces (respectively, `nobreak-space' and `escape-glyph') to distinguish them from ordinary spaces and hyphens. You can turn off this feature by setting the variable `nobreak-char-display' to `nil'. If you set the variable to any other value, that means to prefix these characters with an escape character. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock: doesn't colour non-ascii dash in string correctly
I have a string in a C file: "helloworld" Both quotes and all the letters are coloured in the usual string face, an orange kind of colour, but the dash is cyan. It's inside a string, so why isn't it "string coloured"? Here's the output of 'od' on the file: $ od -tc /tmp/man.el 000 " h e l l o 255 w o r l d " \n 016 $ od -tx1 /tmp/man.el 000 22 68 65 6c 6c 6f ad 77 6f 72 6c 64 22 0a 016 describe-char tells me it's: character: (2221, #o4255, #x8ad, U+00AD) charset: latin-iso8859-1 (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) code point: #x2D syntax: _ which means: symbol category: l:Latin buffer code: #x81 #xAD file code: #xAD (encoded by coding system windows-1250-unix) display: by this font (glyph code) -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1 (#xAD) hardcoded face: escape-glyph Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Unicode keyboard layouts does not work properly
On 19 Feb 2007, at 01:24, YAMAMOTO Mitsuharu wrote: Actually, I'm not sure why the current code does not work. But the Keyboard Layout Services API, which is available on Mac OS X 10.2 and later, seems to solve the problem. Could you try the following patch? Thank you, this did the job for me. - David smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: use-file-dialog and use-dialog-box on w32
I have been downloading the emacs version 22.** + auctex binaries since 22.0.50 and in none of them has the file dialog worked when clicking on the options under File on the menu bar. C-h v use-file-dialog and use-dialog-box reveals that both are set to t Does the problem happen in straight Emacs, from CVS on savannah.gnu.org? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
> Who cares? This sort of argument is no reason not to install a simple > change that will avoid problems. Nor was I implying that. If you were not implying that, then I don't see how your argument is relevant to the question at hand. But there is no need to argue. The change has been installed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
Nick Roberts schrieb: > > Unfortunately, I have only a dial-up connection and can't give immediate > > feedback on new Emacs versions. > > One advantage of using CVS over tarballs is that you only need to download the > (compressed) _changes_. Even with a dial-up connection that shouldn't take a > long time. Thanks for the hint. I am already familiar with rcs, actually. But I didn't set up a proper environment for compiling Emacs by myself yet. There just wasn't much use in that so far. :) Best regards, Stephan Hennig ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
