Re: strange behaviour of "//" in open file names
>> I use ffap and since file-name-shadow-mode was enabled it bothered me that >> the protocol part of URLs is shadowed and C-a doesn't go to the beginning >> of the minibuffer. > > Try M-x url-handler-mode RET Great. It takes care of handling file-name-shadow-mode in ffap prompts correctly. Does this mean that ffap.el should enable it by default? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Incorrect comment (?) in ffap.el
;; This version of ffap supports Emacs 20 only, see the ftp site ;; for a more general version. The following functions are necessary ;; "leftovers" from the more general version. Note: There are also other references to "Emacs 20" in the file that should perhaps be checked. I will fix the "Emacs 20" comments. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sort-columns uses obsolete options of sort
> Regardless of whether this interface to `sort' should have been > deleted, What is wrong with POSIX? That question is rather vague. The issue at hand is whether to delete an interface that users use. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: strange behaviour of "//" in open file names
> I use ffap and since file-name-shadow-mode was enabled it bothered me that > the protocol part of URLs is shadowed and C-a doesn't go to the beginning > of the minibuffer. Try M-x url-handler-mode RET Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shell-command-on-region fooled by long lines
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED]
> shell-command-on-region on this:
> perl -le 'for(1..6){print $_ x 111}'
> mistakenly thinks it is showing all the output in the minibuffer, so
> it doesn't create new a new buffer for the output, when in fact it
> gets fooled by the wrapped lines.
This bothered me for a long time too until I realized that the decision
whether to display the output in the echo area or in a separate window
has nothing to do with the amount of lines in the output.
Sometimes I need to display the output in a separate window
even with 1 line to switch to this window later and to do some operation
on it (e.g. save a part of the output to the kill ring). In all
other cases displaying the output in the echo area is more preferable
to not change the current window configuration.
But with the current code it is not possible to do this without
modifying the function `shell-command-on-region'. I propose the
following patch that changes this function to call `display-message-or-buffer'
conditionally depending on the value of a new variable
`shell-command-display-message'. This is not a new feature, but rather is
a fix for a misfeature.
With this variable, users can either set it permanently to nil
to always display the output in a separate window, or let-bind
it depending on the key used to exit the command-reading minibuffer:
(defadvice shell-command (around my-shell-command act)
(let* ((shell-command-display-message
(unless (eq last-input-char 'S-return)
shell-command-display-message)))
ad-do-it))
This displays the output in the echo area when the minibuffer is exited
with RET, and displays the output in a separate window when the minibuffer
is exited with S-RET.
Index: lisp/simple.el
===
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.790
diff -c -r1.790 simple.el
*** lisp/simple.el 4 Feb 2006 21:48:20 - 1.790
--- lisp/simple.el 9 Feb 2006 19:16:09 -
***
*** 1961,1966
--- 1967,1976
(car (cdr (cdr (process-command process
(substring signal 0 -1
+ (defvar shell-command-display-message t
+ "If nil, display the output in a pop-up buffer.
+ If non-nil, display the output in the echo area if the output
+ is not too long. See `display-message-or-buffer'".)
+
(defun shell-command-on-region (start end command
&optional output-buffer replace
error-buffer display-error-buffer)
***
*** 1987,1993
\(determined by the variable `max-mini-window-height' if
`resize-mini-windows' is non-nil), it is shown there. Otherwise
it is displayed in the buffer `*Shell Command Output*'. The output
! is available in that buffer in both cases.
If there is output and an error, a message about the error
appears at the end of the output.
--- 1997,2005
\(determined by the variable `max-mini-window-height' if
`resize-mini-windows' is non-nil), it is shown there. Otherwise
it is displayed in the buffer `*Shell Command Output*'. The output
! is available in that buffer in both cases. If the variable
! `shell-command-display-message' is nil, it displays the output
! in a pop-up buffer.
If there is output and an error, a message about the error
appears at the end of the output.
***
*** 2104,2110
(format " - Exit [%d]" exit-status)
(if (with-current-buffer buffer (> (point-max) (point-min)))
;; There's some output, display it
! (display-message-or-buffer buffer)
;; No output; error?
(let ((output
(if (and error-file
--- 2116,2126
(format " - Exit [%d]" exit-status)
(if (with-current-buffer buffer (> (point-max) (point-min)))
;; There's some output, display it
! (if shell-command-display-message
! (display-message-or-buffer buffer)
! (with-current-buffer buffer
! (goto-char (point-min))
! (display-buffer (current-buffer
;; No output; error?
(let ((output
(if (and error-file
--
Juri Linkov
http://www.jurta.org/emacs/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: strange behaviour of "//" in open file names
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED] > When I open a file with C-x C-f I have to enter its name in the minibuffer. > If > its name contains double slashs "//", everything before them is printed in > grey > (my global standard colour is orange). Additionally, a C-a doesn't go to the > first character in the file path but to the most recent double slash (if the > cursor was behind it). I use ffap and since file-name-shadow-mode was enabled it bothered me that the protocol part of URLs is shadowed and C-a doesn't go to the beginning of the minibuffer. In all other respects I like file-name-shadow-mode. I think there should be a way to tell file-name-shadow-mode not to shadow certain minibuffer strings with a patch like below: Index: lisp/rfn-eshadow.el === RCS file: /sources/emacs/emacs/lisp/rfn-eshadow.el,v retrieving revision 1.22 diff -u -w -b -r1.22 rfn-eshadow.el --- lisp/rfn-eshadow.el 6 Feb 2006 14:33:35 - 1.22 +++ lisp/rfn-eshadow.el 9 Feb 2006 19:16:11 - @@ -130,6 +130,10 @@ (defvar rfn-eshadow-overlay) (make-variable-buffer-local 'rfn-eshadow-overlay) +(defvar rfn-eshadow-update-overlay-p nil + "Function to disable shadow depending on the minibuffer contents. +Its return value nil removes shadow from the minibuffer.") + ;;; Hook functions @@ -168,6 +172,10 @@ This is intended to be used as a minibuffer `post-command-hook' for `file-name-shadow-mode'; the minibuffer should have already been set up by `rfn-eshadow-setup-minibuffer'." + (if (and (functionp rfn-eshadow-update-overlay-p) + (null (funcall rfn-eshadow-update-overlay-p))) + (move-overlay rfn-eshadow-overlay + (minibuffer-prompt-end) (minibuffer-prompt-end)) (condition-case nil (let ((goal (substitute-in-file-name (minibuffer-contents))) (mid (overlay-end rfn-eshadow-overlay)) @@ -195,7 +203,7 @@ (setq end mid))) (move-overlay rfn-eshadow-overlay (minibuffer-prompt-end) start))) ;; `substitute-in-file-name' can fail on partial input. -(error nil))) + (error nil (define-minor-mode file-name-shadow-mode "Toggle File-Name Shadow mode. Index: lisp/ffap.el === RCS file: /sources/emacs/emacs/lisp/ffap.el,v retrieving revision 1.53 diff -c -r1.53 ffap.el *** lisp/ffap.el19 Nov 2005 12:18:07 - 1.53 --- lisp/ffap.el9 Feb 2006 19:16:12 - *** *** 1255,1261 (abbreviate-file-name (expand-file-name guess)) )) (setq dir (file-name-directory guess ! (let ((minibuffer-completing-file-name t)) (setq guess (completing-read prompt --- 1255,1263 (abbreviate-file-name (expand-file-name guess)) )) (setq dir (file-name-directory guess ! (let ((minibuffer-completing-file-name t) ! (rfn-eshadow-update-overlay-p ! (lambda () (not (ffap-url-p (minibuffer-contents)) (setq guess (completing-read prompt -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ffap highlighting persists
Below is a patch that allows the user to turn off ffap highlighting. Actually, it was possible to do this without this patch because ffap.el checks for the face `ffap' with (facep 'ffap), but this possibility is hidden from users. A standard way to customize this is to define faces with `defface': Index: lisp/ffap.el === RCS file: /sources/emacs/emacs/lisp/ffap.el,v retrieving revision 1.54 diff -c -r1.54 ffap.el *** lisp/ffap.el6 Feb 2006 14:33:33 - 1.54 --- lisp/ffap.el9 Feb 2006 17:33:38 - *** *** 1321,1326 --- 1323,1334 (defvar ffap-highlight t "If non-nil, ffap highlights the current buffer substring.") + (defface ffap + '((t :inherit highlight)) + "Face used to highlight the current buffer substring." + :group 'ffap + :version "22.1") + (defvar ffap-highlight-overlay nil "Overlay used by `ffap-highlight'.") *** *** 1344,1351 (t (setq ffap-highlight-overlay (apply 'make-overlay ffap-string-at-point-region)) ! (overlay-put ffap-highlight-overlay 'face ! (if (facep 'ffap) 'ffap 'highlight) ;;; Main Entrance (`find-file-at-point' == `ffap'): --- 1352,1358 (t (setq ffap-highlight-overlay (apply 'make-overlay ffap-string-at-point-region)) ! (overlay-put ffap-highlight-overlay 'face 'ffap ;;; Main Entrance (`find-file-at-point' == `ffap'): -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ffap highlighting persists
> In case this is considered to be a feature, here are some arguments against > it: > > 1. Such mouse-face highlighting suggests a link or button - that is, it > suggests that you can click mouse-2 to follow the link. This is of course > not the case. We could bind [mouse-2] on highlighted URLs to follow a link exactly like lisp/net/goto-addr.el does. > 2. It is not needed - if you can use ffap the first time without such > highlighting, you can continue to do so without it. If you can get to all > such choices in a menu, you don't need them highlighted in the buffer. > > 3. It is distracting, and interferes with other highlighting. > > At the very least, such persistent highlighting should be optional. I agree. A new option would be useful. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: ffap highlighting persists
> In case this is considered to be a feature, here are some > arguments against it: > > 1. Such mouse-face highlighting suggests a link or button - >that is, it suggests that you can click mouse-2 to follow >the link. This is of course not the case. We could bind [mouse-2] on highlighted URLs to follow a link exactly like lisp/net/goto-addr.el does. Oh, I don't think we want to do that - unless perhaps the buffer is read-only. Ffap is used in all kinds of buffers, and you still want to be able to use mouse-2 to paste text within, say, a file name or URL. > 2. It is not needed - if you can use ffap the first time without such >highlighting, you can continue to do so without it. If you >can get to all such choices in a menu, you don't need them highlighted >in the buffer. > > 3. It is distracting, and interferes with other highlighting. > > At the very least, such persistent highlighting should be optional. I agree. A new option would be useful. We might want to distinguish the face from the mouse-face highlighting, in this discussion. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info fails to find history.info
> > Do users ever enter them? > > I can't imagine a situation where users might want to enter them. > > In that case, there is no reason to keep them. > > Since `toc' pertains to the Current Info file, it makes no sense > for that to be treated like a file of any kind. If anything, > it is more like a virtual node. It could have a node name > such as :toc: which can't really appear in an Info file. Supporting virtual nodes looks like a new feature. Are you sure this is necessary for the next release? > A phony node nane is not logically ideal for the history, > but maybe it would work. Do you mean a history node with references to nodes visited only in the current manual? As a user, I certainly wouldn't like this. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: ffap highlighting persists
Below is a patch that allows the user to turn off ffap highlighting. Actually, it was possible to do this without this patch because ffap.el checks for the face `ffap' with (facep 'ffap), but this possibility is hidden from users. A standard way to customize this is to define faces with `defface': Again - We might want to distinguish the face from the mouse-face highlighting, in this discussion. I personally will turn off all such highlighting (given the option), but some people might, say, like to keep the mouse-face highlighting but not the face highlighting. There is also the question of persistence - some people might want the highlighting temporarily, but be able to turn it off somehow later. If ffap were made into a minor mode, exiting it might also turn off the highlighting (since it would then be disabled). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mouse highlighting in header (and mode) line is too persistant
Stephen Berman wrote: 1. emacs -q (or -Q) 2. Invoke a mode that has a header line with highlightable text, e.g. Info, Buffer Menu (list-buffers), ruler mode, also tab bar mode from the external library tabbar.el. 3. Drag the mouse pointer over the header line until a portion of the header line highlighted. 4. Now drag the mouse completely off the highlighted portion of the header line and directly onto the tool bar: the highlighting in the header line remains. As soon as the mouse pointer leaves the tool bar, the header line highlighting vanishes. I only observe this with the tool bar enabled. I also see it with the mode line in the GTK build when the tool bar is detached and dragged down so that it abuts the mode line. I've checked in a fix, please try it. Thanks, Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: display-buffer can leave wrong frame with input focus
> On Thu, 9 Feb 2006 08:58:10 +, David Reitter <[EMAIL PROTECTED]> said: > Works as intended. The fact that newly opened frames get the focus > seems inconsistent, however. From a user's perspective, the same > sequence of inputs will not lead to the same results, depending on > whether the other frame happens to get focus or not. I think it'd be > better if the newly opened frame never gets focus - even if the > window manager initially gives it focus. That would implement the > documentation of display-buffer more closely: "Make buffer appear in > some window but don't select it." Anyway, that's no longer a Carbon-specific issue. All X11 window managers that I regularly use behave like this (i.e., a new frame created by make-frame will get focus). At least, you can customize the behavior so as not to change the focus like this: (defun my-special-display-popup-frame (buffer &optional args) (let ((orig-frame (selected-frame))) (special-display-popup-frame buffer args) (x-focus-frame orig-frame))) (setq special-display-function 'my-special-display-popup-frame) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: display-buffer can leave wrong frame with input focus
On 9 Feb 2006, at 08:04, YAMAMOTO Mitsuharu wrote: Could you try the following patch that prevents raise-frame from giving focus to a raised frame that is already visible? Note that a newly created or previously iconified frame still gets focus when the frame is popped up by display-buffer, but this behavior is also observed with some X11 window managers. Works as intended. The fact that newly opened frames get the focus seems inconsistent, however. From a user's perspective, the same sequence of inputs will not lead to the same results, depending on whether the other frame happens to get focus or not. I think it'd be better if the newly opened frame never gets focus - even if the window manager initially gives it focus. That would implement the documentation of display-buffer more closely: "Make buffer appear in some window but don't select it." ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
check_min_window_sizes
With Emacs -q evaluating (progn (split-window-horizontally) (let ((window-min-width 1)) (shrink-window (1- (window-width)) t))) removes scrollbars from both emanating windows and makes the left window inaccessible. For some strange reason `check_min_window_sizes' seems to fail here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
re-search-forward always finds the same link
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I have written the following function. It fetches a page from the web. In that page are links to archive pages, which should also be fetched, and appended to the buffer. The problem: re-search-forward always matches the same archive link, as if it would be start again from beginning-of-buffer. (defun advaita-all() (interactive) (with-temp-buffer ;; get base page (shell-command "lynx -dump http://advaitavedantameditations.blogspot.com/"; (current-buffer)) (let ((eob (save-excursion (end-of-buffer) (point ;; append to base page all archive pages that are referenced in ;; the base page (while (re-search-forward " \\(http://.*_archive.html$\\)" eob t) (let ((link (match-string 1))) (save-excursion (message (concat "Processing link: " link)) (end-of-buffer) (shell-command (concat "lynx -dump " link) (current-buffer) (write-region (point-min) (point-max) "~/Privat/advaita-all.txt" Changing the two lines ;; (end-of-buffer) ;; (shell-command (concat "lynx -dump " link) (current-buffer) (goto-char (point-max)) (insert (shell-command-to-string (concat "lynx -dump " link)) and it works. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu) of 2006-02-05 on brabbelbox X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure 'CC=gcc'' 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: [EMAIL PROTECTED] locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Major mode: Default-Major Minor modes in effect: partial-completion-mode: t recentf-mode: t minibuffer-electric-default-mode: t auto-image-file-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-fill-mode: t erc-netsplit-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t global-cwarn-mode: t outline-minor-mode: t delete-selection-mode: t pc-selection-mode: t show-paren-mode: t icomplete-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: display-buffer can leave wrong frame with input focus
> On Wed, 8 Feb 2006 19:59:22 +, David Reitter <[EMAIL PROTECTED]> said:
> The below issue is reproducible in a plain GNU Emacs (Carbon). Note
> that the X11 version is reported to work fine, but not Carbon Emacs.
> This might not be considered a bug by some of you (for example
> because the window manager selects the new frame), but I still think
> synchronizing the behavior of the X11 version and the Carbon
> implementation could be advantageous.
Could you try the following patch that prevents raise-frame from
giving focus to a raised frame that is already visible? Note that a
newly created or previously iconified frame still gets focus when the
frame is popped up by display-buffer, but this behavior is also
observed with some X11 window managers.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: lisp/frame.el
===
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.234
diff -c -r1.234 frame.el
*** lisp/frame.el 6 Feb 2006 14:33:33 - 1.234
--- lisp/frame.el 9 Feb 2006 07:38:16 -
***
*** 695,701
(select-frame frame)
(raise-frame frame)
;; Ensure, if possible, that frame gets input focus.
! (cond ((eq window-system 'x)
(x-focus-frame frame))
((eq window-system 'w32)
(w32-focus-frame frame)))
--- 695,701
(select-frame frame)
(raise-frame frame)
;; Ensure, if possible, that frame gets input focus.
! (cond ((memq window-system '(x mac))
(x-focus-frame frame))
((eq window-system 'w32)
(w32-focus-frame frame)))
Index: src/macfns.c
===
RCS file: /cvsroot/emacs/emacs/src/macfns.c,v
retrieving revision 1.75
diff -c -r1.75 macfns.c
*** src/macfns.c6 Feb 2006 15:23:21 - 1.75
--- src/macfns.c9 Feb 2006 07:38:17 -
***
*** 2714,2719
--- 2714,2752
XSETFRAME (xfocus, dpyinfo->x_focus_frame);
return xfocus;
}
+
+
+ DEFUN ("x-focus-frame", Fx_focus_frame, Sx_focus_frame, 1, 1, 0,
+doc: /* Set the input focus to FRAME.
+ FRAME nil means use the selected frame. */)
+ (frame)
+ Lisp_Object frame;
+ {
+ struct frame *f = check_x_frame (frame);
+ struct mac_display_info *dpyinfo = FRAME_MAC_DISPLAY_INFO (f);
+
+ if (dpyinfo->x_focus_frame != f)
+ {
+ BLOCK_INPUT;
+ #ifdef MAC_OSX
+ ActivateWindow (ActiveNonFloatingWindow (), false);
+ ActivateWindow (FRAME_MAC_WINDOW (f), true);
+ #else
+ #if !TARGET_API_MAC_CARBON
+ /* SelectWindow (Non-Carbon) does not issue deactivate events if
+the possibly inactive window that is to be selected is
+already the frontmost one. */
+ SendBehind (FRAME_MAC_WINDOW (f), NULL);
+ #endif
+ /* This brings the window to the front. */
+ SelectWindow (FRAME_MAC_WINDOW (f));
+ #endif
+ UNBLOCK_INPUT;
+ }
+
+ return Qnil;
+ }
+
DEFUN ("xw-color-defined-p", Fxw_color_defined_p, Sxw_color_defined_p, 1, 2,
0,
doc: /* Internal function called by `color-defined-p', which see. */)
***
*** 4513,4518
--- 4546,4552
defsubr (&Sx_close_connection);
defsubr (&Sx_display_list);
defsubr (&Sx_synchronize);
+ defsubr (&Sx_focus_frame);
/* Setting callback functions for fontset handler. */
get_font_info_func = x_get_font_info;
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.152
diff -c -r1.152 macterm.c
*** src/macterm.c 6 Feb 2006 15:23:21 - 1.152
--- src/macterm.c 9 Feb 2006 07:38:17 -
***
*** 5837,5843
if (f->async_visible)
{
BLOCK_INPUT;
! SelectWindow (FRAME_MAC_WINDOW (f));
UNBLOCK_INPUT;
}
}
--- 5837,5843
if (f->async_visible)
{
BLOCK_INPUT;
! BringToFront (FRAME_MAC_WINDOW (f));
UNBLOCK_INPUT;
}
}
***
*** 5964,5970
f->output_data.mac->asked_for_visible = 1;
- SelectWindow (FRAME_MAC_WINDOW (f));
CollapseWindow (FRAME_MAC_WINDOW (f), false);
ShowWindow (FRAME_MAC_WINDOW (f));
}
--- 5964,5969
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
