Re: M-x gdb with large files
> "Nick" == Nick Roberts <[EMAIL PROTECTED]> writes: Nick> >> BTW there must be a new problem with the newest CVS version. A call like: >> M-x gdb -> gdb --annotate=3 umc.vx >> gives me the following error (taken from *Messages*): Nick> Nick> Is it a new problem? i.e. did it work previously? Yes and yes >> I could trace this down to the following lines in my .emacs file: >> (eval-after-load "gdb-ui" >> '(progn >> (message "Configuring gdb-ui") >> ;(setq gdb-show-main t) >> ;(setq gdb-many-windows t) >> ;(setq gdb-use-separate-io-buffer t) >> )) Nick> Nick> I think you should do: Nick> Nick> (add-hook 'gdb-mode-hook Nick> '(lambda () Nick>(message "Configuring gdb-ui") Nick>(setq gdb-show-main t) Nick>(setq gdb-many-windows t) Nick>(setq gdb-use-separate-io-buffer t))) Yes I know that there are different ways to configure the variables for gdb-ui. But I believe that this simple eval-after-load (especially with all settings commented out) shouldn't break gdb. Besides why should I do it in a hook that is run every time I call gdb, when configuring it once should be enough. Klaus -- -- | Klaus Zeitler Lucent Technologies | | Email: [EMAIL PROTECTED] | -- --- I never learned anything while I was talking. - Anonymous ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding system of compressed PO files is not recognized
Kenichi Handa wrote: At the header of po-compat.el, this comment is written. ;; Emacs 21.2 and newer already contain this file, under the name po.el, ;; and without portability hassles. So, there's no need of loading this file in the current version. Indeed, I think I'll have to move it out of the way to let your changes take effect. Anyway, I've just installed a change to Ffind_operation_coding_system so that it doesn't cause an error while running a function. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for fit-window-to-buffer should emphasize "height", not "size"
"Size" should be replaced by "height", since this command does not change the window width. Thanks. By the way - is there no command to change the window width to fit the buffer (e.g. fit its longest line)? Why not? Because horizontal splitting isn't used often enough to make it worth having one. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for temp-buffer-max-height and resize-temp-buffer-window
That seems like a lot of trouble. The mode doc says not to turn the mode on by binding the mode variable, so that is presumably not an option. It would be a lot simpler (and cleaner) if you could just bind a variable or two, wouldn't it? For instance, make such a binding around with-output-to-temp-buffer, so that it automatically resized the buffer's window. You can bind temp-buffer-show-hook. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word does not work without windows system
Why overload flyspell-auto-correct-word with a meaning it wasn't supposed to bear? To avoid the need to find a new keybinding. Why not bind flyspell-correct-word to some terminal key That's easier said than done. What key would you suggest? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 1. No doc for `help-mode-setup'. 2. Why do temp-buffer*-hookuse help-mode?
I did this because it turns out to be useful. If a specific caller wants some other mode, it's easy to switch. So this causes no problem. My point was that the doc says nothing about it, giving the impression that it is general. It IS general, it just has a default that isn't what you expected. I agree that should be documented. Would someone like to do that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x gdb with large files
> BTW there must be a new problem with the newest CVS version. A call like: > M-x gdb -> gdb --annotate=3 umc.vx > gives me the following error (taken from *Messages*): Is it a new problem? i.e. did it work previously? > --- snip --- > Configuring gdb-ui > error in process filter: apply: Args out of range: "(gdb) > prompt > ", 0, 68 > error in process filter: Args out of range: "(gdb) > prompt > ", 0, 68 > error in process filter: gdb-prompt: Phase error in gdb-prompt (got > pre-emacs) > error in process filter: Phase error in gdb-prompt (got pre-emacs) > --- snip --- > > I could trace this down to the following lines in my .emacs file: > (eval-after-load "gdb-ui" > '(progn >(message "Configuring gdb-ui") >;(setq gdb-show-main t) >;(setq gdb-many-windows t) >;(setq gdb-use-separate-io-buffer t) >)) I think you should do: (add-hook 'gdb-mode-hook '(lambda () (message "Configuring gdb-ui") (setq gdb-show-main t) (setq gdb-many-windows t) (setq gdb-use-separate-io-buffer t))) -- 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
hscroll-step doc bug; cannot turn off hscroll by binding
1. The doc string of `hscroll-step' refers to variable `automatic-hscroll-margin'. I believe this should be `hscroll-margin' (the former apparently does not exist). 2. I tried to bind `auto-hscroll-mode' to nil in a particular context, to prevent automatic scrolling (without changing the user's value of the option). It does not seem to work - scrolling occurs anyway. Likewise, binding `hscroll-margin' to 0 had no effect (didn't prevent auto scrolling). I used a let binding in a mouse command, but as soon as the command exited the window was scrolled anyway (after clicking near a window edge). I ended up setting `auto-hscroll-mode' as a buffer-local variable, which is OK, but I think binding it should also work. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-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 line-number-mode: t Recent input: Recent messages: (C:\Emacs-22-2006-03-20\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Swap GUD fringe/margin mouse-2 and mouse-3 bindings
> Something like this: > > In buffer I have something like > > if (a == b->c->d) ...; > > I would like to be able to "click" on "a" to see the value of a (in > message area), on "b" to see value of b, somewhere on "->c" to > see value of b->c and on "d" to see value of "b->c->d". Currently, you can select "a" as a region, then on the gud-print tool bar icon to print the value of a (in the GUD buffer), select "b" to see value of b, select "b->c" to see value of b->c and select "b->c->d" to see value of "b->c->d. But you seem to be saying bind a mouse event to gud-print and change how it parses expressions. Mouse-1 is needed for normal use of the source buffer, like editing. > It could be enhanced to > >(((a) + b) + c) > > so that clicking on the first ) shows value of (a), on second ) shows > value of ((a) + b) and on last ) shows value of whole expression. > > Well, just sort of SWIM (show what I mean) :-) Expressions aren't always bracketed. Parsing an expression can be quite complex as gud-find-c-expr shows. By selecting the user can ensure he gets exactly what he wants. > Alternatively: > > A way to toggle gud tool-tips in the GUD toolbar (I don't want them > enabled all the time). You can currently toggle them from the menu bar. With 80 columns and starting with "--fullname" there's no room left on my tool bar. > Make gud tooltips use gud-find-c-expr instead of > tooltip-identifier-from-point. I agree that tooltip-identifier-from-point doesn't always do what you want but it's safe. Gud-print will call procedures e.g abort (), which you wouldn't want to happen if the mouse just lingered too long over it. tooltip-identifier-from-point could be enhanced if you specified all the differences between existing behaviour and desired behaviour. -- 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: display weirdness: show cursor where it shouldn't be after scroll-left
Miguel Frasson <[EMAIL PROTECTED]> writes: > Kim F. Storm cua.dk> writes: > >> >> "Miguel V. S. Frasson" gmail.com> writes: >> >> > Hi >> > >> > In lenghty lines, using scroll-left and scroll-right in some >> > combination (how to reproduce bellow) results that the display shows >> > the middle of the line, I see the cursor there in the middle, but >> > point is in beginning of line. >> > >> > If one should be prepared to see cursor where the point isn't, then >> > this is not a bug. >> >> It's a bug, indeed. Thanks for reporting it. > > Then I understand the bug in the other way around. With the fixes, I see the > cursor at positions, blinking, where the point isn't. Just use the same test > case: point is at beginning of line, and scrolling I see the cursor blinking > in > the middle of the line. Yes, this is confusing! > If I can suggest a solution for this, I would like to have the cursor blinking > at the fringe (right fringe if point is before what we see, left fringe if > point > is after the displayed text), to sign clearly that the cursor is *not* in the > position. That might be an idea -- to be considered after the release. -- 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: display weirdness: show cursor where it shouldn't be after scroll-left
Kim F. Storm cua.dk> writes: > > "Miguel V. S. Frasson" gmail.com> writes: > > > Hi > > > > In lenghty lines, using scroll-left and scroll-right in some > > combination (how to reproduce bellow) results that the display shows > > the middle of the line, I see the cursor there in the middle, but > > point is in beginning of line. > > > > If one should be prepared to see cursor where the point isn't, then > > this is not a bug. > > It's a bug, indeed. Thanks for reporting it. Then I understand the bug in the other way around. With the fixes, I see the cursor at positions, blinking, where the point isn't. Just use the same test case: point is at beginning of line, and scrolling I see the cursor blinking in the middle of the line. If I can suggest a solution for this, I would like to have the cursor blinking at the fringe (right fringe if point is before what we see, left fringe if point is after the displayed text), to sign clearly that the cursor is *not* in the position. Miguel. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
with-current-buffer doc does not mention that buf can be a string
emacs -q C-h f with-current-buffer The doc does not mention that the argument can be a buffer name. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-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 line-number-mode: t Recent input: Recent messages: (C:\Emacs-22-2006-03-20\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word does not work without windows system
> From: Richard Stallman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] > Date: Mon, 29 May 2006 02:39:32 -0400 > > Would it make sense to change flyspell-auto-correct-word > to call flyspell-check-previous-highlighted-word, or to do some > of what it does? Since flyspell-auto-correct-word is the command > that is available on a tty. Why overload flyspell-auto-correct-word with a meaning it wasn't supposed to bear? Why not bind flyspell-correct-word to some terminal key and use the techniques of flyspell-auto-correct-word or of ispell.el to show the possible corrections, instead? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
'next-line' skips a line
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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: I have loaded emacs with -q and --no-site-file to reduce dependencies. Now suppose we have a buffer with the following content: (a) (b) (c) and the cursor is at the end of first line, immediately after "a)". If I want to come down one line, I press down-arrow (or C-n or M-x next-line), and cursor correctly comes at the end of second line after "b)". But if I have "show-paren-mode" turned ON, then next-line skips the entire second line and cursor lands at the end of 3rd line after "c)". It may be related to https://gna.org/bugs/?func=detailitem&item_id=5228 where C-e moves down to next line. In GNU Emacs 22.0.50.1 (i686-redhat-linux-gnu, GTK+ Version 2.4.14) of 2005-06-24 on box25.private.lan X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk' '--without-xim' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -m32 -march=i386 -mtune=pentium4' 'build_alias=i686-redhat-linux-gnu' 'host_alias=i686-redhat-linux-gnu' 'target_alias=i386-redhat-linux-gnu'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t tool-bar-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t next-error-follow-minor-mode: Fol Recent input: ( a ) ( b ) ( c ) M-x s h o w - p a r e n - m o d eM-x r e p o r t - e m Recent messages: Loading mwheel...done (emacs -q --no-site-file) Loading disp-table...done Loading tool-bar...done Loading image...done For information about the GNU Project and its goals, type C-h C-p. next-history-element: Beginning of history; no preceding item Loading paren...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: 1. No doc for `help-mode-setup'. 2. Why do temp-buffer*-hookuse help-mode?
> help-mode stuff by default? Is that correct? Why does Emacs assume > that with-output-to-temp-buffer is dealing with a help > buffer? The doc for with-output-to-temp-buffer says nothing about > help-mode or a help buffer - it seems to advertise the special > form as being completely general. I did this because it turns out to be useful. If a specific caller wants some other mode, it's easy to switch. So this causes no problem. My point was that the doc says nothing about it, giving the impression that it is general. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 1. No doc for `help-mode-setup'. 2. Why do temp-buffer*-hook use help-mode?
> help-mode stuff by default? Is that correct? Why does Emacs assume > that with-output-to-temp-buffer is dealing with a help buffer? The doc > for with-output-to-temp-buffer says nothing about help-mode or a help > buffer - it seems to advertise the special form as being completely > general. I did this because it turns out to be useful. If a specific caller wants some other mode, it's easy to switch. So this causes no problem. Most likely the best way to make it cleaner is to start by renaming with-output-to-temp-buffer: the buffer isn't temporary (at least not in the usual sense, as in with-temp-buffer). There is no need for that incompatibility, and I don't want it. There isn't a problem here. Please let's work on improvements that will really make Emacs better, not on this area. etc/TODO lists so many things that need to be done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in gtkutil.c
>> I got a crash in gtkutil.c while playing around with msb.el. I'll try >> to see if I can produce a recipe, but here is the backtrace; hopefully >> it is enough: > > I don't think \220&\212\b is valid UTF-8. What was the string you > tried to insert there? Strings passed to GTK-menus shall be UTF-8, it > is supposed to be taken care of in xmenu.c. But if the original > string was an invalid Emacs string, I suppose the conversion to UTF-8 > failed. I haven't been able to reproduce the crash. Maybe there is a bug in xmenu.c, or maybe it is gremlins at work. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund <[EMAIL PROTECTED]> writes: > Leon wrote: >>Thank you! I'm waiting until it can display properly bold and italic fonts:-) > See my remarks on http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs > for a workaround. > > Meik Thanks, Meik. Actually I have read your comments before the post. I was hoping someone could fix this. BTW, it seems you workaround still use the X core font, isn't it? Regards, -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Swap GUD fringe/margin mouse-2 and mouse-3 bindings
Nick Roberts <[EMAIL PROTECTED]> writes: > > BTW, besides the [p] button and gud-tooptips, is there some easy way to > > look at the value of the expression under the mouse? > > I'm not sure what you're looking for but: > > 1) Gud-tooltips use tooltip-identifier-from-point which extracts the most >basic part of a variable name at point e.g. a. > > 2) Gud-print uses gud-find-c-expr (for C) for this purpose which knows > something about C syntax e.g a->b. You can also select a region with the > mouse for printing an expression e.g a + 4*b (this a recent feature). > > 3) Watch expressions allow you to explore structures and arrays in the >speedbar, and watch variable values change during execution. Again this >uses gud-find-c-expr and expressions can be selected with the mouse. Something like this: In buffer I have something like if (a == b->c->d) ...; I would like to be able to "click" on "a" to see the value of a (in message area), on "b" to see value of b, somewhere on "->c" to see value of b->c and on "d" to see value of "b->c->d". It could be enhanced to (((a) + b) + c) so that clicking on the first ) shows value of (a), on second ) shows value of ((a) + b) and on last ) shows value of whole expression. Well, just sort of SWIM (show what I mean) :-) Alternatively: A way to toggle gud tool-tips in the GUD toolbar (I don't want them enabled all the time). Make gud tooltips use gud-find-c-expr instead of tooltip-identifier-from-point. -- 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: How to use xft font in unicode-xft branch
Leon wrote: >Thank you! I'm waiting until it can display properly bold and italic fonts:-) See my remarks on http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs for a workaround. Meik -- Meik Hellmund Institut fuer Mathematik, Uni Leipzig e-mail: [EMAIL PROTECTED] http://www.math.uni-leipzig.de/~hellmund ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x gdb with large files
> "Nick" == Nick Roberts <[EMAIL PROTECTED]> writes: Nick> Nick> Did you do this with gdb-many-windows set to t? tried it with gdb-many-windows set to "t" or "nil", doesn't seem to make a difference. Nick> How deep is your stack? Only 9 frames in this case, but we have about 130 threads, i.e. under Solaris that is 260 lightweight processes. Maybe this (besides the image/core size) causes problems. BTW there must be a new problem with the newest CVS version. A call like: M-x gdb -> gdb --annotate=3 umc.vx gives me the following error (taken from *Messages*): --- snip --- Configuring gdb-ui error in process filter: apply: Args out of range: "(gdb) prompt ", 0, 68 error in process filter: Args out of range: "(gdb) prompt ", 0, 68 error in process filter: gdb-prompt: Phase error in gdb-prompt (got pre-emacs) error in process filter: Phase error in gdb-prompt (got pre-emacs) --- snip --- I could trace this down to the following lines in my .emacs file: (eval-after-load "gdb-ui" '(progn (message "Configuring gdb-ui") ;(setq gdb-show-main t) ;(setq gdb-many-windows t) ;(setq gdb-use-separate-io-buffer t) )) When I remove the eval-after-load, it works. Klaus -- -- | Klaus Zeitler Lucent Technologies | | Email: [EMAIL PROTECTED] | -- --- I have discovered the art of deceiving diplomats. I tell them the truth and they never believe me. -- Camillo Di Cavour ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Swap GUD fringe/margin mouse-2 and mouse-3 bindings
> BTW, besides the [p] button and gud-tooptips, is there some easy way to > look at the value of the expression under the mouse? I'm not sure what you're looking for but: 1) Gud-tooltips use tooltip-identifier-from-point which extracts the most basic part of a variable name at point e.g. a. 2) Gud-print uses gud-find-c-expr (for C) for this purpose which knows something about C syntax e.g a->b. You can also select a region with the mouse for printing an expression e.g a + 4*b (this a recent feature). 3) Watch expressions allow you to explore structures and arrays in the speedbar, and watch variable values change during execution. Again this uses gud-find-c-expr and expressions can be selected with the mouse. -- 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: STOP button on gud tool-bar doesn't always work
Nick Roberts <[EMAIL PROTECTED]> writes: > > There is a strange anomaly (IMO) on the gdb toolbar: > > > > When the debugged program is stopped, you can click on the the button > > in any source window associated with the program, but when the program > > is running, you can only click on the button in the GUD buffer; > > if you click it in a source buffer (where works), the message is > > This should fix it. It does. Thanks. -- 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: Swap GUD fringe/margin mouse-2 and mouse-3 bindings
Nick Roberts <[EMAIL PROTECTED]> writes: > > IMO, we should swap "toggle enable/disable breakpoint" (on mouse-3) > > and "run until" (on mouse-2). > > > > In normal bindings, mouse-3 is "extend region until click position", > > so it resembles "execute until click position". > > I tend to feel that mouse-3 should pop up a menu. In general, yes, but emacs is different > > > Likewise, mouse-2 normally is "yank at point", which resembles "toggle > > at point". > > I'm not sure what "toggle at point" means, but using mouse-2 to toggle > a breakpoint doesn't seem intuitive to me. > > How about putting it on C-mouse-1? Because: > > 1) It's related to setting/clearing a breakpoint (on mouse-1). > 2) The poor souls mentioned below can still use it. Much better, yes. > > > I guess that "run until" is used more frequently that "enable/disable > > breakpoint", so let's make it easier to use "run until" for the poor > > soles with a two-button mouse (e.g. most laptop users). > > I think frequency of use is a more compelling reason to put it on mouse-3. Yes. > There's another command (not documented), gdb-mouse-jump, which allows you > to jump *backwards* so that you can go over the same code again > (to be used with caution). This is currently on C-mouse-2, and I would > move that to C-mouse-3. That's an excellent idea! BTW, besides the [p] button and gud-tooptips, is there some easy way to look at the value of the expression under the mouse? -- 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
Swap GUD fringe/margin mouse-2 and mouse-3 bindings
> IMO, we should swap "toggle enable/disable breakpoint" (on mouse-3) > and "run until" (on mouse-2). > > In normal bindings, mouse-3 is "extend region until click position", > so it resembles "execute until click position". I tend to feel that mouse-3 should pop up a menu. > Likewise, mouse-2 normally is "yank at point", which resembles "toggle > at point". I'm not sure what "toggle at point" means, but using mouse-2 to toggle a breakpoint doesn't seem intuitive to me. How about putting it on C-mouse-1? Because: 1) It's related to setting/clearing a breakpoint (on mouse-1). 2) The poor souls mentioned below can still use it. > I guess that "run until" is used more frequently that "enable/disable > breakpoint", so let's make it easier to use "run until" for the poor > soles with a two-button mouse (e.g. most laptop users). I think frequency of use is a more compelling reason to put it on mouse-3. There's another command (not documented), gdb-mouse-jump, which allows you to jump *backwards* so that you can go over the same code again (to be used with caution). This is currently on C-mouse-2, and I would move that to C-mouse-3. -- 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
STOP button on gud tool-bar doesn't always work
> There is a strange anomaly (IMO) on the gdb toolbar: > > When the debugged program is stopped, you can click on the the button > in any source window associated with the program, but when the program > is running, you can only click on the button in the GUD buffer; > if you click it in a source buffer (where works), the message is This should fix it. -- Nick http://www.inet.net.nz/~nickrob *** gud.el 24 May 2006 09:24:48 +1200 1.108 --- gud.el 29 May 2006 21:29:34 +1200 *** Used to grey out relevant togolbar icons *** 130,139 (defun gud-stop-subjob () (interactive) ! (if (string-equal !(buffer-local-value 'gud-target-name gud-comint-buffer) "emacs") ! (comint-stop-subjob) ! (comint-interrupt-subjob))) (easy-mmode-defmap gud-menu-map '(([help] "Info" . gud-goto-info) --- 130,139 (defun gud-stop-subjob () (interactive) ! (with-current-buffer gud-comint-buffer ! (if (string-equal gud-target-name "emacs") ! (comint-stop-subjob) ! (comint-interrupt-subjob (easy-mmode-defmap gud-menu-map '(([help] "Info" . gud-goto-info) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tumme and describe-function.
[EMAIL PROTECTED] (Michaël Cadilhac) writes: >> > With latest CVS, I don't think this is already fixed neither I think >> > it's due to a compilation error: >> > >> > $ emacs -q >> > $ C-h f tumme RET >> > describe-function: Symbol's function definition is void: >> tumme-show-all-from-dir >> >> I've added an autoload, it should be fixed now. Strange, I would think that was added long ago. But I never use tumme that way so I might have missed it. Thanks for adding it! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund <[EMAIL PROTECTED]> writes: > The unicode-xft branch is great but it inherited the bugs from > XFT_JHD_BRANCH, > (a) character under cursor is unreadable and (b) scrolling destroys modeline > I tried to accomodate the patches by YAMAMOTO Mitsuharu > http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-04/msg00301.html > and Michael Teske > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00466.html > and the following seems to work for me. > It would be great if someone put them into cvs. > > Meik Thank you! I'm waiting until it can display properly bold and italic fonts:-) -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: How to use xft font in unicode-xft branch
Meik Hellmund skrev: The unicode-xft branch is great but it inherited the bugs from XFT_JHD_BRANCH, (a) character under cursor is unreadable and (b) scrolling destroys modeline I tried to accomodate the patches by YAMAMOTO Mitsuharu http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-04/msg00301.html and Michael Teske http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00466.html and the following seems to work for me. It would be great if someone put them into cvs. Done. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Swap GUD fringe/margin mouse-2 and mouse-3 bindings
IMO, we should swap "toggle enable/disable breakpoint" (on mouse-3) and "run until" (on mouse-2). In normal bindings, mouse-3 is "extend region until click position", so it resembles "execute until click position". Likewise, mouse-2 normally is "yank at point", which resembles "toggle at point". I guess that "run until" is used more frequently that "enable/disable breakpoint", so let's make it easier to use "run until" for the poor soles with a two-button mouse (e.g. most laptop users). -- 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: Crash in gtkutil.c
Chong Yidong skrev: I got a crash in gtkutil.c while playing around with msb.el. I'll try to see if I can produce a recipe, but here is the backtrace; hopefully it is enough: (gdb) bt full #0 0xb7e17031 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #1 0xb7d3a3a5 in gtk_menu_item_new_with_label () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #2 0x080ee837 in create_menus (data=Variable "data" is not available. ) at gtkutil.c:2067 utf8_label = 0x0 item = (widget_value *) 0x8852600 wmenu = (GtkWidget *) 0x8752e28 group = (GSList *) 0x0 #3 0x080eed96 in xg_create_widget (type=0x81a32c8 "popup", name=0x81a32c3 "menu", f=0x86c03a0, val=0x85925b0, select_cb=0x808be80 , deactivate_cb=0x808aaf0 , highlight_cb=0x808ab00 ) at gtkutil.c:2152 w = Variable "w" is not available. (gdb) f 2 #2 0x080ee837 in create_menus at gtkutil.c:2067 2067 w = gtk_menu_item_new_with_label (utf8_label); (gdb) p utf8_label $3 = 0x0 (gdb) p item->name $4 = 0x884eccc "\220&\212\b:load-toplevel" I don't think \220&\212\b is valid UTF-8. What was the string you tried to insert there? Strings passed to GTK-menus shall be UTF-8, it is supposed to be taken care of in xmenu.c. But if the original string was an invalid Emacs string, I suppose the conversion to UTF-8 failed. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
"Smart" hiding of button in the GUD toolbar
I'm not convinced that the current "smart hiding" of various button in the gud toolbar is optimal from a user's pov. The rationale seems to be that if there is some other way to do the task with the mouse, hide the button. In particular, I think the following examples of "smart hiding" is undesireable (i.e. I suggest to always show the icons): Hide "toggle breakpoint" since we can do that by clicking mouse-1 in the fringe or margin. Hide "run until" since dragging mouse-1 or clicking mouse-2 in fringe does that. BTW, dragging only works for "what's on the screen" already, so if the arrow is not on screen, or the target is off screen, you cannot use the drag. Besides, I find that it is somewhat flaky. So I suggest that we remove that particular feature, which really seems quite superfluous. -- 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
STOP button on gud tool-bar doesn't always work
There is a strange anomaly (IMO) on the gdb toolbar: When the debugged program is stopped, you can click on the the button in any source window associated with the program, but when the program is running, you can only click on the button in the GUD buffer; if you click it in a source buffer (where works), the message is "Current buffer has no process". In GNU Emacs 22.0.50.52 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-05-28 on kfs-l.imdomain.dk X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure 'CFLAGS=-O0 -g'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: shell-dirtrack-mode: t gnus-topic-mode: t gnus-undo-mode: t cua-mode: t display-time-mode: t 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 transient-mark-mode: t -- 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
Overlay string not displayed on text with `display' property
I'm not quite sure if this is a bug or not. Please tell me if it is not. An overlay string is not displayed if it is on (before?) the text that has some `display' property. For example, 1. emacs -Q -D 2. (setq overlay (make-overlay 1 1)) 3. (overlay-put overlay 'before-string "aaa") Then "aaa" is displayed at the beginning of buffer. 4. (put-text-property 1 2 'display "bbb") Then "aaa" disappears. YAMAMOTO Mitsuharu [EMAIL PROTECTED] 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 /opt/local/src/emacs/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-05-29 on church X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t 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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-after-load bug
> In <[EMAIL PROTECTED]> Richard Stallman wrote: > (eval-after-load "w3m" FORM) [...] > While the FORM should be evaluated after the w3m.elc module is > loaded, it is done after the mime-w3m.elc module is loaded. > I think I fixed that. > Please test it. Works fine. Thank you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
