Re: Symbol's value as variable is void: cl-struct-tramp-file-name-tags
On 6/12/07, Chris Moore <[EMAIL PROTECTED]> wrote: Running: emacs -Q /[EMAIL PROTECTED]:/ to attempt to use tramp to FTP, I see an error message. I fixed the problem by running a "make clean && make bootstrap", so maybe my previous message should be ignored. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Symbol's value as variable is void: cl-struct-tramp-file-name-tags
Running:
emacs -Q /[EMAIL PROTECTED]:/
to attempt to use tramp to FTP, I see an error message.
The *Messages* buffer contains the following:
-
("emacs" "-Q" "/[EMAIL PROTECTED]:/")
For information about the GNU Project and its goals, type C-h C-p.
Loading tramp...
Loading regexp-opt...done
Loading tramp...done
tramp-find-foreign-file-name-handler: Symbol's value as variable is
void: cl-struct-tramp-file-name-tags
Mark set [2 times]
-
I just built Emacs from CVS a few minutes ago.
In GNU Emacs 22.1.50.13 (i686-pc-linux-gnu, GTK+ Version 2.10.11)
of 2007-06-12 on trpaslik
Windowing system distributor `The X.Org Foundation', version 11.0.7000
configured using `configure '--with-gtk' '--prefix' '/usr/local'
'--with-xpm' '--with-jpeg' '--with-png' '--with-gif''
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
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display problem after renaming open image files
Have a PNG image in /tmp/pic.png, then: $ cd /tmp $ mkdir emacs $ cd emacs $ cp ../pic.png pic1.png $ cp ../pic.png pic2.png $ emacs -Q open the directory using dired: C-x d RET open the first file in the other window, go back to the direct window, go down a line: o C-x o n open the 2nd file in the other window, close that window, leaving only the dired window: o C-x 0 go back to the first file line, rename pic1.png to pic3.png: p R pic3.png RET revisit the first file (now called pic3.png): f The image shows up as a small square rather than the real image. (variations on the above theme, like renaming pic2 instead of pic1, or visiting pic2 after the rename don't seem to cause the problem). In GNU Emacs 22.0.96.22 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-04-01 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' 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_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
narrowing *shell* buffer causes odd error
I just tried to delete the contents of my *shell* buffer with C-x h C-w, because it was getting too big. The buffer appeared empty, so I guessed it had worked. Later, I tried hitting return to get a new prompt and saw: Debugger entered--Lisp error: (args-out-of-range 15737454 15737485) add-text-properties(15737454 15737485 (font-lock-face comint-highlight-prompt)) comint-snapshot-last-prompt() comint-send-input() call-interactively(comint-send-input) I couldn't work out what was going on, until I spotted that it said 'Narrow' on the mode-line. Widening the buffer allowed me to carry on working as normal. I don't know how the buffer got narrowed - maybe I didn't type what I thought I did, but rather than the cryptic "args out of range" error, could it say something about how the buffer is narrowed, preventing the mode from functioning properly? In GNU Emacs 22.0.96.19 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-30 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
error on undo
I've not found a way to reproduce this error, but it happens
repeatably in the session I currently have running.
I was working on a C++ source file for a few hours, then narrowed it
to a region and attempted to undo the last change. The last change
was outside the narrowed region. I would usually expect to see a
message telling me something to that effect, but instead I got an
error:
Debugger entered--Lisp error: (args-out-of-range 11911 11929)
primitive-undo(1 ((nil fontified nil 11911 . 11929) (11911 . 11929) nil
(#("synfig::_BlendFunc" 0 18 ...) . 11911) (nil fontified t 11911 . 11929) (t
17932 . 20398) nil (#("\n" 0 1 ...) . 11717) (# . 1) (#
. 1) (# . 1) (# . 1) (# . 1) (# . 1) (# . 1)
(# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) (# .
1) (# . 1) (# . 1) (# . 1) ...))
undo-more(1)
advertised-undo(nil)
call-interactively(advertised-undo)
In GNU Emacs 22.0.96.16 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-03-29 on trpaslik
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm'
'--with-jpeg' '--with-png' '--with-gif''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: .gif image fails to display correctly
On 3/22/07, Kim F. Storm <[EMAIL PROTECTED]> wrote: Chong Yidong <[EMAIL PROTECTED]> writes: > Animated gifs aren't supported in Emacs. Mine does :-) ;;; animage.el --- animated image API That's quite nice, but it doesn't work on the high-colour image either. Each frame is cleared before displaying the next. Also, even after killing the image buffer, Emacs continues to use all available CPU time. Shouldn't killing the buffer stop the animation loop from running? And: are you looping all animated gifs? Some aren't supposed to loop, I think. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ido-mode breaks filename completion in recursive minibuffers
run Emacs: $ emacs -Q enable recursive minibuffers: M-x set-variable RET enable-recursive-minibuffers RET t RET enable ido-mode for switching buffers: M-: (ido-mode 'buffers) RET start switching buffers, but don't finish: C-x b switch away from the minibuffer: C-x o try finding a file, notice that TAB lists buffers, not files C-x C-f TAB (TAB (translated from ) runs the command ido-complete, but I'm not using ido-mode to complete filenames). In GNU Emacs 22.0.96.9 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-24 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
can't customize compare-windows to have previous behaviour
The documenation string for compare-windows tells me: If `compare-windows-sync' is non-nil, then successive calls of this command work in interlaced mode Also, the documentation string for compare-windows-sync tells me: If the value of this variable is `nil', then function `ding' is called to beep or flash the screen when points are mismatched. Yet when I go to customise compare-windows-sync, I don't see any option to set it to nil; all I seem to be able to chose is to set it to a function or a regexp. I tried setting it to function nil, but was told: custom-variable-save: Saving compare-windows-sync: Invalid function: nil I also tried setting it to regexp nil, but then I see: compare-windows-sync is a variable defined in `compare-w.el'. Its value is "nil" ie. it's set to the string "nil", not to nil itself. So how can I get back the old behaviour of compare windows, where it stops at differences, rather than skipping over them in some semi-clever way? In GNU Emacs 22.0.96.5 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-22 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `move-beginning-of-line' doesn't move to beginning of line
A similar problem exists with the command kill-line. The documentation tells me: "Kill the rest of the current line" However, in a *shell* buffer, if I: $ echo aa RET $ echo bb RET C-p C-a C-k (go to the line with the 'bb' on it and kill it) C-p C-p C-y (go to the line with the 'aa' on it and yank the 'bb') C-a (go to the start of the line with 'bbaa' on it) C-k (kill the rest of the line with 'bbaa' on it) then only the 'bb' is killed. the 'aa' is on the same line, after the cursor, but it isn't killed. The line looks like a regular 4-character line, the cursor is at the beginning of it, yet C-k only kills half of the line. Maybe it's useful to have an invisible field in the bottom line of a *shell* buffer to allow the prompt to behave differently that the editable command, but once a command has been run these invisible fields don't seem to server any purpose other than to stop regular editing commands from working as documented. Am I missing something? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`move-beginning-of-line' doesn't move to beginning of line
In *shell* buffers, "C-h k C-a" tells me that: C-a runs the command move-beginning-of-line Move point to beginning of current line as displayed. However, when I hit C-a, the cursor stays at the end of the prompt, not at the beginning of the line. This may be desired behaviour (although I find it annoying; I often want to go to the beginning of the prompt) but it isn't the documented behaviour. The documentation should match the behaviour one way or the other. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`inhibit-point-motion-hooks' isn't configurable
In a regular *shell* buffer, I see that C-a doesn't go to the beginning of a line like it does in other buffers. I explore this by describing the key binding. I see that: C-a runs the command move-beginning-of-line and: To ignore intangibility, bind `inhibit-point-motion-hooks' to t. That sounds like it might be what I want to do, so I click on the link to see the docs for inhibit-point-motion-hooks. To my surprise, there's no "you can customize this variable" link, and since I'm so used to being mollycoddled by Emacs, I don't know how to customize it manually. I think we need to decide whether to mention this variable and make it customizable, or not mention it at all. As it stands, the new user is left with a variable which they can discover but not change. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.gif image fails to display correctly
http://i.iinfo.cz/urs-att/gif2_e-115572866858321.gif is an example of a .gif image which contains more than 256 colours. It does this by using multiple frames with a 0ms separation between them. Emacs only displays the first frame. This may well be something that isn't worth fixing in Emacs, but I thought I should mention it anyway. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
crash when reverting corrupted ppm image
Emacs crashes every time for me when I do the following:
1) download http://dooglus.rincevent.net/random/file2.ppm.bz2 (157KB)
2) bunzip2 the file
3) C-x C-f file2.ppm RET
4) C-x C-v RET
Here's the backtrace I see:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219708000 (LWP 30968)]
pbm_load (f=0x8605310, img=0x87a0e10) at image.c:5756
5756b = *p++;
(gdb) where
#0 pbm_load (f=0x8605310, img=0x87a0e10) at image.c:5756
#1 0x080ecfdc in lookup_image (f=0x8605310, spec=139033901) at image.c:1863
#2 0x08080ea7 in handle_single_display_spec (it=0xbf871254, spec=, object=142422636,
position=0xbf8712f4, display_replaced_before_p=0) at xdisp.c:4248
#3 0x080816f2 in handle_display_prop (it=0xbf871254) at xdisp.c:3851
#4 0x08074ebe in handle_stop (it=0xbf871254) at xdisp.c:3047
#5 0x08082893 in start_display (it=0xbf871254, w=0x8605478, pos={charpos = 1,
bytepos = 1}) at xdisp.c:2733
#6 0x08085686 in try_window (window=140530812, pos={charpos = 1, bytepos = 1},
check_margins=1) at xdisp.c:13558
#7 0x080874b7 in redisplay_window (window=140530812, just_this_one_p=0) at
xdisp.c:13187
#8 0x08088a73 in redisplay_window_0 (window=140530812) at xdisp.c:11784
#9 0x0815b401 in internal_condition_case_1 (bfun=0x8088a50
, arg=140530812, handlers=137458917,
hfun=0x80661c0 ) at eval.c:1529
#10 0x08075267 in redisplay_windows (window=0) at xdisp.c:11763
#11 0x0808928f in redisplay_internal (preserve_echo_area=)
at xdisp.c:11323
#12 0x08100c62 in read_char (commandflag=1, nmaps=2, maps=0xbf873010,
prev_event=137472201,
used_mouse_menu=0xbf8730b8, end_time=0x0) at keyboard.c:2670
#13 0x08103572 in read_key_sequence (keybuf=0xbf873164, bufsize=30,
prompt=137472201, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9133
#14 0x08105035 in command_loop_1 () at keyboard.c:1618
#15 0x0815b63b in internal_condition_case (bfun=0x8104ea0 ,
handlers=137516857,
hfun=0x80ff7b0 ) at eval.c:1481
#16 0x080feb7e in command_loop_2 () at keyboard.c:1329
#17 0x0815b6fc in internal_catch (tag=137510841, func=0x80feb50
, arg=137472201) at eval.c:1222
#18 0x080ff5fe in command_loop () at keyboard.c:1308
#19 0x080ff988 in recursive_edit_1 () at keyboard.c:1006
#20 0x080ffa75 in Frecursive_edit () at keyboard.c:1067
#21 0x080f58d2 in main (argc=Cannot access memory at address 0x0
) at emacs.c:1761
(gdb) p p
$1 = (unsigned char *) 0xb70e
(gdb) p *p
Cannot access memory at address 0xb70e
In GNU Emacs 22.0.95.11 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-03-18 on trpaslik
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm'
'--with-jpeg' '--with-png' '--with-gif''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: list-buffers-noselect: `when' should be `and'
On 2/18/07, Richard Stallman <[EMAIL PROTECTED]> wrote: These doc changes are ok with me. Does that mean someone should install them? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
M-x dirs RET doesn't work when there are spaces in the directory's name
Sometimes the *shell* buffer's directory tracking gets out of sync with its inferior shell process. In such cases, "M-x dirs RET" usually fixes the problem, but this doesn't work if there is a space in the directory's name: M-x shell RET $ cd /tmp $ mkdir 'one two' $ X='one two'; cd "$X" [ using $X here to deliberately confused comint ] M-x dirs RET => "Couldn't cd" I see "$ dirs" and "/tmp/one two" shown in the *shell* buffer, but an attempt is made to cd to "/tmp/one", rather than to "/tmp/one two". I realise that it's not possible to parse the output of 'dirs', since spaces in the path look identical to spaces separating the paths, but perhaps "dirs +0" could be used when it is detected that the shell is bash? In GNU Emacs 22.0.94.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-26 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
comint's directory tracking doesn't understand \( or \)
The *shell* buffer attempts to cd into the current working directory of the inferior shell process, but when that directory contains a ( or ), it seems to get lost, for example: M-x shell RET $ cd /tmp/ $ mkdir /tmp/'(2007)' $ cd \(2007\)/ The *shell* buffer ends up in /tmp/, not in /tmp/(2007)/ as expected. Note that if I use: $ cd '(2007)' instead, then the tracking works. But if I use single quotes like that, instead of backslashes, then tab-completion of filenames doesn't work. In GNU Emacs 22.0.94.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-26 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ 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: please use ?\u2014 instead of the unicode character inbuff-menu.el
"Drew Adams" <[EMAIL PROTECTED]> writes: > And replacing two em-dash characters with \u2014 is hardly making > "extraordinary efforts". I think if you're going to fix two of them you may as well go the extra mile and replace all three of them to prevent us having to have this argument at a later point about the remaining em-dash character. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: list-buffers-noselect: `when' should be `and'
Stefan Monnier <[EMAIL PROTECTED]> writes: >> `when' should be `and' in this code, for clarity. I don't think this >> has an effect on functioning, but `when' should generally not be used >> when its value is important, as in this case. Here, the return value >> is an argument to function `buffer-list'. > > I disagree, so let's leave it. If we're going to use the return value of 'when' in this manner, we should document 'when' to state what its return value is (and the same goes for 'unless' as well). These changes are based on the documentation for 'if': Index: lisp/subr.el === RCS file: /sources/emacs/emacs/lisp/subr.el,v retrieving revision 1.546 diff -u -r1.546 subr.el --- lisp/subr.el9 Feb 2007 23:09:16 - 1.546 +++ lisp/subr.el17 Feb 2007 23:28:34 - @@ -99,12 +99,24 @@ (list 'setq listname (list 'cdr listname) (defmacro when (cond &rest body) - "If COND yields non-nil, do BODY, else return nil." + "If COND yields non-nil, do BODY. +Returns nil or the value of the last of the BODY's. +If COND yields nil, the value is nil. +If COND yields non-nil, and there are no BODY's, the value is nil. +BODY... is zero or more expressions. + +\(fn COND BODY...)" (declare (indent 1) (debug t)) (list 'if cond (cons 'progn body))) (defmacro unless (cond &rest body) - "If COND yields nil, do BODY, else return nil." + "If COND yields nil, do BODY. +Returns nil or the value of the last of the BODY's. +If COND yields non-nil, the value is nil. +If COND yields nil, and there are no BODY's, the value is nil. +BODY... is zero or more expressions. + +\(fn COND BODY...)" (declare (indent 1) (debug t)) (cons 'if (cons cond (cons nil body ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customization: Toggle buttons vanish when clicked
On 2/12/07, Chris Moore <[EMAIL PROTECTED]> wrote: Doing the following causes the 'Toggle' button to vanish: $ emacs -Q M-x customize-variable RET case-fold-search RET C-s Togg RET RET The bug also exhibits itself with 'Value Menu' buttons. For example: M-: (customize-variable 'next-error-highlight) RET then click on the 'Value Menu' button and select a menu entry. The button vanishes. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp vs. following blanks highlighting
Chong Yidong <[EMAIL PROTECTED]> writes: > I brought up this issue long ago: > > http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00174.html So I see. I just read through that thread and see that: 1) it doesn't touch upon the mismatch between highlighting and queries in a query-replace-regexp; it's only talking about searching, not replacing, and 2) the thread died out without any decision having been made. I think that both string searches and regular expression searches should have "space-means-space" functionality by default, with there being 2 separate customisable settings to toggle space-means-space-in-string-search and space-means-space-in-regexp-search. There's no need to a special keystroke to toggle these 'on the fly' - just have the customisable. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp vs. following blanks highlighting
Chong Yidong <[EMAIL PROTECTED]> writes: > This is a new feature in Emacs 22. Use "^[ ]" if you want to > highlight exactly one space. What's the rationale for this feature? I thought the point of highlighting was to show which parts of the buffer match the regular expression being searched for, which is useful. What is the use of showing parts which don't match as well? It seems that the intention was to only affect regular expression incremental search (see the documentation for search-whitespace-regexp) but it also affects query-replace-regexp. If a buffer contains the following: - 1 2 1 2 1 2 - and you run: (query-replace-regexp "1 2" "3") then all 3 lines are highlighted, but only the middle line is offered for replacement. It's not good that 3 lines are highlighted, but only 1 line is replaced. We should fix it such that either: a) all 3 lines are highlighted, and offered for replacement or b) only the middle line is highlighted and offered for replacement. Since the documentation for search-whitespace-regexp says: "This applies to regular expression incremental search", I guess that (b) would be the preferred fix, as follows: Index: lisp/isearch.el === RCS file: /sources/emacs/emacs/lisp/isearch.el,v retrieving revision 1.293 diff -u -r1.293 isearch.el --- lisp/isearch.el 17 Jan 2007 13:20:47 - 1.293 +++ lisp/isearch.el 14 Feb 2007 12:09:30 - @@ -2374,7 +2374,8 @@ isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search isearch-lazy-highlight-regexp isearch-regexp -isearch-lazy-highlight-wrapped nil) +isearch-lazy-highlight-wrapped nil + isearch-lazy-highlight-space-regexp search-whitespace-regexp) (unless (equal isearch-string "") (setq isearch-lazy-highlight-timer (run-with-idle-timer lazy-highlight-initial-delay nil @@ -2385,7 +2386,7 @@ Attempt to do the search exactly the way the pending isearch would." (let ((case-fold-search isearch-lazy-highlight-case-fold-search) (isearch-regexp isearch-lazy-highlight-regexp) - (search-spaces-regexp search-whitespace-regexp)) + (search-spaces-regexp isearch-lazy-highlight-space-regexp)) (condition-case nil (isearch-search-string isearch-lazy-highlight-last-string Index: lisp/replace.el === RCS file: /sources/emacs/emacs/lisp/replace.el,v retrieving revision 1.249 diff -u -r1.249 replace.el --- lisp/replace.el 21 Jan 2007 03:53:11 - 1.249 +++ lisp/replace.el 14 Feb 2007 12:09:31 - @@ -1728,6 +1728,7 @@ (if query-replace-lazy-highlight (let ((isearch-string string) (isearch-regexp regexp) + (search-whitespace-regexp nil) (isearch-case-fold-search case-fold)) (isearch-lazy-highlight-new-loop range-beg range-end ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: PGG: can't encrypt only for myself?
Chris Moore <[EMAIL PROTECTED]> writes:
> the 'encrypt for me' setting is only used if I specify other recipients as
> well:
> I think I would expect pgg-encrypt-for-me to be consulted even if no other
> recipients are specified.
Here's a patch to fix it:
Index: lisp/pgg-gpg.el
===
RCS file: /sources/emacs/emacs/lisp/pgg-gpg.el,v
retrieving revision 1.21
diff -u -r1.21 pgg-gpg.el
--- lisp/pgg-gpg.el 21 Jan 2007 03:53:11 - 1.21
+++ lisp/pgg-gpg.el 14 Feb 2007 11:27:52 -
@@ -224,7 +224,7 @@
(list "--batch" "--armor" "--always-trust" "--encrypt")
(if pgg-text-mode (list "--textmode"))
(if sign (list "--sign" "--local-user" pgg-gpg-user-id))
- (if recipients
+ (if (or recipients pgg-encrypt-for-me)
(apply #'nconc
(mapcar (lambda (rcpt)
(list pgg-gpg-recipient-argument rcpt))
Index: lisp/pgg-pgp5.el
===
RCS file: /sources/emacs/emacs/lisp/pgg-pgp5.el,v
retrieving revision 1.5
diff -u -r1.5 pgg-pgp5.el
--- lisp/pgg-pgp5.el21 Jan 2007 03:53:11 - 1.5
+++ lisp/pgg-pgp5.el14 Feb 2007 11:27:52 -
@@ -155,7 +155,7 @@
(args
(append
`("+NoBatchInvalidKeys=off" "-fat" "+batchmode=1"
-,@(if recipients
+,@(if (or recipients pgg-encrypt-for-me)
(apply #'append
(mapcar (lambda (rcpt)
(list "-r"
Index: lisp/pgg-pgp.el
===
RCS file: /sources/emacs/emacs/lisp/pgg-pgp.el,v
retrieving revision 1.6
diff -u -r1.6 pgg-pgp.el
--- lisp/pgg-pgp.el 21 Jan 2007 03:53:11 - 1.6
+++ lisp/pgg-pgp.el 14 Feb 2007 11:27:52 -
@@ -143,7 +143,7 @@
(args
(concat
"+encrypttoself=off +verbose=1 +batchmode +language=us -fate "
- (if recipients
+ (if (or recipients pgg-encrypt-for-me)
(mapconcat 'shell-quote-argument
(append recipients
(if pgg-encrypt-for-me
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
auto-compression-mode doesn't work on backups of .bz2 files
If I have auto-compression-mode turned on and edit file.txt.gz~ or
file.txt.gz.~23~ then the files are decompressed on the fly before
being shown to me. This is good.
However, if instead I edit file.txt.bz2~ or file.txt.bz2.~23~ then the
files aren't decompressed on the fly.
This patch fixes the problem:
--- lisp/Backup/jka-cmpr-hook.el.~1~2007-01-28 04:47:56.0 +0100
+++ lisp/jka-cmpr-hook.el 2007-02-13 23:46:00.0 +0100
@@ -191,7 +191,7 @@
;; Formerly, these had an additional arg "-c", but that fails with
;; "Version 0.1pl2, 29-Aug-97." (RedHat 5.1 GNU/Linux) and
;; "Version 0.9.0b, 9-Sept-98".
-["\\.bz2\\'"
+["\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'"
"bzip2ing""bzip2" nil
"bunzip2ing" "bzip2" ("-d")
nil t "BZh"]
I notice also that backups of .tgz and .tbz files aren't handled, but
that's less of a problem because tar-mode fails to make backups when I
edit tar archives, so I've never seen a .tgz~ or .tbz~ file. tar-mode
uses tar-mode-write-file to save modified tar buffers, which in turn
uses write-region, which doesn't make backups. Perhaps this should be
fixed as well.
In GNU Emacs 22.0.93.39 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-02-13 on trpaslik
configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm'
'--with-jpeg' '--with-png' '--with-gif''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
On 2/13/07, Kenichi Handa <[EMAIL PROTECTED]> wrote: So, how about treating this matter as a documentation bug, and fix it to: "ISO646 IRV:1983[4/0] (ASCII graphic characters)" instead of modifying the code? That seems like a reasonable solution. I think it would be good to add some further explanation, because it's not clear what 'graphic characters' means, such that space is graphic but newline and tab aren't. Maybe explicitly state that it means characters in the range 32-126 inclusive. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
On 2/11/07, Chris Moore <[EMAIL PROTECTED]> wrote: (eval-expression (quote (skip-chars-forward "[:ascii:]")) nil) seems to know that tab and newline are ASCII characters. The code responsible for this behaviour is in src/regex.c: /* Map a string to the char class it names (if any). */ [...] else if (STREQ (string, "ascii")) return RECC_ASCII; and case RECC_ASCII: return IS_REAL_ASCII (ch); and /* 1 if C is an ASCII character. */ # define IS_REAL_ASCII(c) ((c) < 0200) ie. [:ascii:] matches all characters < 128 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
On 2/12/07, Eli Zaretskii <[EMAIL PROTECTED]> wrote: I hope we don't plan on changing _anything_ in this regard before the release, no matter what we find in the specs. The cited fragment from characters.el has been there since before Emacs moved into CVS in 1997! How is the age of the bug relevant? Searching for ASCII characters with \ca matches different characters than searching for ASCII class characters with [:ascii:]. Surely that's a bug that needs fixing, rather than a feature to be added later isn't it? We're not required to follow the spec, but it's not good to use 2 different definitions of ASCII. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
On 2/12/07, Richard Stallman <[EMAIL PROTECTED]> wrote: We should find out whether this is officially the case according to the specs of ASCII. We aren't required to obey that spec, but we should at least think about doing so. This page from ASA standard X3.4-1963 shows that 0 and 127 are part of ASCII, although some of the characters in between weren't defined at the time: http://www.wps.com/projects/codes/X3.4-1963/page5.JPG The other pages are here: http://www.wps.com/projects/codes/X3.4-1963/ See also http://www.wps.com/projects/codes/Revised-ASCII/page1.JPG, the "revised US ASCII code (X3.4-1967)" specification which includes lowercase characters. It shows all 128 characters (0 through 127) as being part of the ASCII code. The other pages are here: http://www.wps.com/projects/codes/Revised-ASCII/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Customization: Toggle buttons vanish when clicked
Doing the following causes the 'Toggle' button to vanish: $ emacs -Q M-x customize-variable RET case-fold-search RET C-s Togg RET RET Backing out this change fixes the problem: 2007-02-04 Per Abrahamsen <[EMAIL PROTECTED]> * wid-edit.el (widget-default-create): Insert new text at the :from marker _after_ the marker, not before it. Chris. In GNU Emacs 22.0.93.37 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-12 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
On 2/11/07, Chris Moore <[EMAIL PROTECTED]> wrote: Trying to search a buffer for non-ASCII characters using: C-u C-s \Ca finds all the newlines and tabs in the buffer as well as the non-ASCII characters, but tabs and newlines are ASCII characters. However, (eval-expression (quote (skip-chars-forward "[:ascii:]")) nil) seems to know that tab and newline are ASCII characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Horizontal Tab and Line Feed are non-ASCII according to the ASCII category
Trying to search a buffer for non-ASCII characters using: C-u C-s \Ca finds all the newlines and tabs in the buffer as well as the non-ASCII characters, but tabs and newlines are ASCII characters. lisp/international/characters.el lines 109-111 say: (let ((ch 32)) (while (< ch 127) ; All ASCII characters have (modify-category-entry ch ?a) ; the category `a' (ASCII) and this seems to be the problem. All characters from 0 to 127 are ASCII characters, not just from 32 to 126. Notice that the strict inequality here will result in DEL also being treated as non-ASCII. Here's a possible fix (although I don't know what the `l' (Latin) category is supposed to include, but according to the comment, all ASCII characters have category `l' as well). .~1~ lisp/international/characters.el --- lisp/international/Backup/characters.el.~1~ 2007-01-22 14:38:46.0 +0100 +++ lisp/international/characters.el2007-02-11 15:12:12.0 +0100 @@ -106,8 +106,8 @@ ;; ASCII -(let ((ch 32)) - (while (< ch 127); All ASCII characters have +(let ((ch 0)) + (while (< ch 128); All ASCII characters have (modify-category-entry ch ?a) ; the category `a' (ASCII) (modify-category-entry ch ?l) ; and `l' (Latin). (setq ch (1+ ch In GNU Emacs 22.0.93.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
PGG: can't encrypt only for myself?
pgg-encrypt-for-me is t I want to encrypt a file only with my own key, so I type: M-x pgg-encrypt RET RET and get an error: gpg: : skipped: malformed user id [GNUPG:] INV_RECP 0 gpg: [stdin]: encryption failed: malformed user id it seems that the 'encrypt for me' setting is only used if I specify other recipients as well: (from the definition of pgg-pgp-encrypt-region: (if recipients (mapconcat 'shell-quote-argument (append recipients (if pgg-encrypt-for-me (list pgg-pgp-user-id) ) I think I would expect pgg-encrypt-for-me to be consulted even if no other recipients are specified. Chris. In GNU Emacs 22.0.93.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
TRAMP: error in tramp-handle-file-exists-p
I was just using TRAMP to access a remote machine. Something went
wrong with the network connection, and things started locking up.
Eventually, I saw this error:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
format(nil "/home/dooglus/public_html/gaim/")
tramp-handle-file-exists-p("/scp:lukhas:/home/dooglus/public_html/gaim/")
apply(tramp-handle-file-exists-p
"/scp:lukhas:/home/dooglus/public_html/gaim/")
tramp-sh-file-name-handler(file-exists-p
"/scp:lukhas:/home/dooglus/public_html/gaim/")
apply(tramp-sh-file-name-handler file-exists-p
"/scp:lukhas:/home/dooglus/public_html/gaim/")
tramp-file-name-handler(file-exists-p
"/scp:lukhas:/home/dooglus/public_html/gaim/")
file-exists-p("/scp:lukhas:/home/dooglus/public_html/gaim/")
tramp-handle-file-attributes("/scp:lukhas:/home/dooglus/public_html/gaim/")
apply(tramp-handle-file-attributes
"/scp:lukhas:/home/dooglus/public_html/gaim/")
tramp-sh-file-name-handler(file-attributes
"/scp:lukhas:/home/dooglus/public_html/gaim/")
apply(tramp-sh-file-name-handler file-attributes
"/scp:lukhas:/home/dooglus/public_html/gaim/")
tramp-file-name-handler(file-attributes
"/scp:lukhas:/home/dooglus/public_html/gaim/")
file-attributes("/scp:lukhas:/home/dooglus/public_html/gaim/")
dired-directory-changed-p("/scp:lukhas:/home/dooglus/public_html/gaim/")
dired-internal-noselect("/scp:lukhas:/home/dooglus/public_html/gaim/"
nil)
dired-noselect("/scp:lukhas:/home/dooglus/public_html/gaim/" nil)
dired-other-window("/scp:lukhas:/home/dooglus/public_html/gaim/"
nil)
call-interactively(dired-other-window)
tramp-handle-file-exists-p makes this call:
(format
(tramp-get-file-exists-command multi-method method user host)
(tramp-shell-quote-argument localname))
It seems that tramp-get-file-exists-command is capable of returning
nil, which is passed as the first argument to format, which format
doesn't like. We need to either check the return from
tramp-get-file-exists-command before passing it to format, or change
tramp-handle-file-exists-p to stop it returning nil in some cases.
In GNU Emacs 22.0.93.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-02-09 on trpaslik
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk' '--prefix' '/usr/local'
'--with-xpm' '--with-jpeg' '--with-png' '--with-gif''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange completion in find-file after today's build?
Romain Francoise <[EMAIL PROTECTED]> writes: > What is the other bug that your change fixes? Perhaps there is > another way to fix it. The bug that the change fixed was that if enable-recursive-minibuffers is t, then typing C-x C-f M-x gives an "M-x" prompt in which SPC isn't bound to minibuffer-complete-word like it should be. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
hexl: doesn't play nicely with dynamic-completion-mode
In GNU Emacs 22.0.93.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-23 on trpaslik configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' make a file with some content: $ date > /tmp/date.txt start emacs: $ emacs -Q enable dynamic completion mode: M-x dynamic-completion-mode RET visit the file: C-x C-f /tmp/date.txt enable hexl-mode: M-x hexl-mode RET type some text containing full stops: hello.world. notice that the letters insert themselves properly into the hexl buffer, but the full stops corrupt the buffer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
hexl: auto-save saves file in hexlified format
In GNU Emacs 22.0.93.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-23 on trpaslik configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' While editing a file using hexl-mode, all auto-save files are written in 'hexlified' format, rather than in the raw binary format. This means that the auto-save files are 4.25 times bigger than they need to be, and take 4.25 times longer to save. Shouldn't auto-saving a file use the same hooks that save-buffer uses? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
turning off auto-save doesn't delete auto-save file
In GNU Emacs 22.0.93.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-23 on trpaslik configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' I'm editing a large file on a slow USB flash drive. Every so often, Emacs auto-saves the file, which takes a long time, so I type: M-x auto-save-mode RET to turn auto-save off for this file. I finish work on the file and save my changes. The #file# auto-save file is left on the disk, even after saving my changes. I would expect "M-x auto-save-mode RET" to have deleted the file when it turned auto-saves off. Either that, or saving the file should have deleted the auto-save file. One or the other. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ebnf2ps.el has some strange English
Also, the same source file lisp/progmodes/ebnf2ps.el repeatedly says "it's used `default-directory'", which again is bad grammar. Better to say "`default-directory' is used". And "The files in DIRECTORY that matches ..." should be "... that match ...". (and probably other similar errors exist - it's a big file). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ebnf2ps.el has some strange English
lisp/progmodes/ebnf2ps.el contains this warning, twice: "WARNING: It's *NOT* asked any confirmation to override an existing file." That's not good grammar. Something like: "WARNING: Existing files will be overwritten without confirmation." reads better. In GNU Emacs 22.0.93.15 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-28 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keybindings change for recursive minibuffers
Richard Stallman <[EMAIL PROTECTED]> writes: > Does this patch fix it? Yes. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > Drew Adams wrote: >> Clicking either of the "more info" links leads to further incorrect >> information... > Please tell what the incorrect information is. I'm guessing it's this: The default Emacs binding for the key is the command `backward-kill-word'. However, your customizations have rebound it to the command `nil'. "the command `nil'"? `nil' isn't a command! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
keybindings change for recursive minibuffers
In GNU Emacs 22.0.93.9 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-27 on trpaslik configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' $ emacs -Q M-x set SPC variable RET enable-recursive-minibuffers RET t RET C-x C-f M-x set SPC variable RET==> [No match] ie. notice that initially typing "M-x set SPC variable" will correctly insert a hyphen between "set" and "variable", and that trying the same in a recursive minibuffer (inside a find-file prompt) doesn't work. In a top-level minibuffer: SPC runs the command minibuffer-complete-word In a recursive minibuffer (while find-file's prompt is pending): SPC runs the command self-insert-command Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
can I customize source-directory please?
In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-21 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' I've recently been using Lennart's Windows build of Emacs. When I want to look at the C source definition of a function, it prompts me for "Emacs C source dir". This is the same every time, and I'm getting tired of typing the path. I would like to customize this variable, but it doesn't have a "you may customize this variable" link in the help, and also the description of the variable says: Directory in which Emacs sources were found when Emacs was built. which makes me think that maybe I shouldn't change it. So: 1) is it safe to change the value? It's currently set to "c:/eclean/bld/emacs/", which doesn't exist on this machine, and 2) if so, could the variable be made customizable, and have the doc string changed to make changing it less intimidating? Thanks. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Eli Zaretskii <[EMAIL PROTECTED]> writes: > At this late stage in the pretest, won't it be safer to bind > default-directory only if the original value doesn't exist? I don't think so, because it's possible for the original value to exist and yet not be accessible to us. For example, if the original value exists but we don't have execute permission on it, then call-process still fails like this: Debugger entered--Lisp error: (file-error "Setting current directory" "permission denied" "/tmp/444/") On the other hand, if we can't cd to (file-name-directory infile) then we won't be able to read infile anyway. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Richard Stallman <[EMAIL PROTECTED]> writes: > To see jka-compr failing, evaluate this: > > (let ((default-directory "/a/b/c")) > (insert-file-contents "/usr/share/man/man1/ls.1.gz")) > > Can someone please fix jka-compr? My post which started this thread contained a fix for jka-compr. The modified functions will need reindenting. I've left the indentation alone to make the patch more readable. $ cvs diff -c lisp/jka-compr.el Index: lisp/jka-compr.el === RCS file: /sources/emacs/emacs/lisp/jka-compr.el,v retrieving revision 1.92 diff -c -r1.92 jka-compr.el *** lisp/jka-compr.el 21 Jan 2007 03:53:11 - 1.92 --- lisp/jka-compr.el 26 Jan 2007 14:46:48 - *** *** 166,171 --- 166,172 ;; to discard the part we don't want. (let ((skip (/ beg jka-compr-dd-blocksize)) (err-file (jka-compr-make-temp-name)) + (default-directory (file-name-directory infile)) count) ;; Update PREFIX based on the text that we won't read in. (setq prefix (- beg (* skip jka-compr-dd-blocksize)) *** *** 204,209 --- 205,211 (defun jka-compr-call-process (prog message infile output temp args) + (let ((default-directory (file-name-directory infile))) (if jka-compr-use-shell (let ((err-file (jka-compr-make-temp-name)) *** *** 243,248 --- 245,251 (with-current-buffer temp (write-region (point-min) (point-max) output) (erase-buffer) + ) ;; Support for temp files. Much of this was inspired if not lifted ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
On 1/25/07, Eli Zaretskii <[EMAIL PROTECTED]> wrote: What do you mean by ``take into account''? File primitives already do take that into account, in a way, so I'm unsure what you meant here. I'm sorry. I guess all I mean is that we need to fix Tramp (and other file handlers) as well as jka-compr, because this also causes an error: $ emacs -Q (require 'shell) (let ((default-directory "/a/b/c")) (insert-file-contents "/scp:lukhas:/home/dooglus/.BASH_PROFILE" nil)) and so does this: $ emacs -Q (let ((default-directory "/a/b/c")) (require 'shell)) Both of these errors are caused by call-process not working when the current directory doesn't exist. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > Could you test if the following patch affects the stability? That seems to be fine, but then, the problem has already been fixed by a previous patch. I can't tell whether your patch has improved things or not. Behaviour looks the same with or without it - ie. fine. I'm not sure, but I think this is the change which fixed it: 2007-01-11 Jan Djärv <[EMAIL PROTECTED]> * alloc.c (BLOCK_INPUT_ALLOC, UNBLOCK_INPUT_ALLOC): Use pthread_equal, block/unblock SIGIO. Should I try backing that change out and seeing whether your patch alone fixes it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Richard Stallman <[EMAIL PROTECTED]> writes:
> There's no ``best way'', it depends on what code calls call-process.
> In some cases, you could bind default-directory to something sensible
> (e.g., invocation-directory), in others you _must_ fail, because the
> command arguments could use something like "./foo/bar" which precludes
> us from changing directories.
>
> That is a good point. Could you fix woman?
I don't think woman needs fixing. Woman is failing because jka-compr
is failing, and that's where this can be fixed.
To see jka-compr failing, evaluate this:
(let ((default-directory "/a/b/c"))
(insert-file-contents "/usr/share/man/man1/ls.1.gz"))
I see a backtrace like this:
Debugger entered--Lisp error: (file-error "Setting current directory" "no suc
signal(file-error ("Setting current directory" "no such file or directory"
(if (and (eq ... ...) (eq ... local-file)) (if visit (setq notfound error-c
(condition-case error-code (let (...) (if replace ...) (setq start ...) (if
(progn (and uncompress-message (message "%s %s..." uncompress-message base-
(unwind-protect (progn (and uncompress-message ...) (condition-case error-c
(let ((uncompress-message ...) (uncompress-program ...) (uncompress-args ..
(if info (let (... ... ... ... ... ... local-file size start) (setq local-f
(let* ((filename ...) (info ...)) (if info (let ... ... ... ... ... ... ...
jka-compr-insert-file-contents("/usr/share/man/man1/ls.1.gz" nil nil nil ni
apply(jka-compr-insert-file-contents ("/usr/share/man/man1/ls.1.gz" nil nil
jka-compr-handler(insert-file-contents "/usr/share/man/man1/ls.1.gz" nil ni
insert-file-contents("/usr/share/man/man1/ls.1.gz")
(let ((default-directory "/a/b/c")) (insert-file-contents "/usr/share/man/m
eval((let ((default-directory "/a/b/c")) (insert-file-contents "/usr/share/
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
(assuming /a/b/c doesn't exist, and /usr/share/man/man1/ls.1.gz does,
and is in gzip format)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Kevin Rodgers <[EMAIL PROTECTED]> writes: > It should signal an error, that the directory doesn't exist. How > does one create a buffer whose default-directory doesn't exist? One finds a file or creates a buffer which isn't associated with a file, but has default-directory set anyway, and then has someone else: rename the directory containing the file or rename one of the directories higher up the tree or umount the filesystem holding the file or ... I don't see why I shouldn't be allowed to pipe the contents of a buffer through 'wc -w' for example to count the words in the buffer just because the buffer's default-directory doesn't exist. In the case where I first saw this bug, the buffer in question wasn't associated with a file at all. I had simply typed "C-x b tmp RET" to create a temporary buffer. I was in a '*shell*' buffer at the time, which was in the "~/tmp/foo" directory. The 'tmp' buffer which I created therefore had a default-directory of "~/tmp/foo" - a directory which I then deleted before attempting to run a shell command on the contents of the tmp buffer. Note that when checking for the existance of default-directory, we need to take the filename handlers into account. /ssh:[EMAIL PROTECTED]:/tmp might look like a bad pathname, but it makes sense to Tramp. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
typo in hexl.el
I sent this 11 days ago, but it appears not to have reached the list. From: Chris Moore <[EMAIL PROTECTED]> To: emacs-pretest-bug@gnu.org, Chris Moore <[EMAIL PROTECTED]> Subject: typo in hexl.el --- lisp/hexl.el2006-12-01 00:30:52.0 +0100 +++ /tmp/hexl.el2007-01-11 15:05:53.0 +0100 @@ -400,7 +400,7 @@ (hl-line-mode 0)) (when (boundp 'hexl-mode-old-hl-line-range-function) (setq hl-line-range-function hexl-mode-old-hl-line-range-function)) - (when (boundp hexl-mode-old-hl-line-face) + (when (boundp 'hexl-mode-old-hl-line-face) (setq hl-line-face hexl-mode-old-hl-line-face)) (setq require-final-newline hexl-mode-old-require-final-newline) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
woman doesn't work if current buffer's directory doesn't exist
In GNU Emacs 22.0.92.24 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-21 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' $ mkdir /tmp/foo $ cd /tmp/foo $ emacs -Q# current directory is /tmp/foo M-x delete-directory RET RET # remove the current directory M-x woman RET ls RET # woman fails * File /usr/share/man/man1/ls.1.gz not found! * The error message is misleading, since the file does exist, and is readable. The cause of the problem is that call-process doesn't work if default-directory doesn't exist, and jka-compr.el uses call-process in a few places. This should probably be fixed in call-process (I can't use shell-command-on-region to pipe a region of a buffer through a shell command if default-directory doesn't exist, for example, and I'd like to be able to). Perhaps default-directory could default to the value of temporary-file-directory if it doesn't exist. Alternatively, a less far-ranging fix is to modify just jka-compr.el to bind default-directory while call-process is running: --- lisp/old/jka-compr.el 2006-12-05 07:15:38.0 +0100 +++ lisp/jka-compr.el 2007-01-22 04:50:57.0 +0100 @@ -166,6 +166,7 @@ ;; to discard the part we don't want. (let ((skip (/ beg jka-compr-dd-blocksize)) (err-file (jka-compr-make-temp-name)) + (default-directory (file-name-directory infile)) count) ;; Update PREFIX based on the text that we won't read in. (setq prefix (- beg (* skip jka-compr-dd-blocksize)) @@ -204,6 +205,7 @@ (defun jka-compr-call-process (prog message infile output temp args) + (let ((default-directory (file-name-directory infile))) (if jka-compr-use-shell (let ((err-file (jka-compr-make-temp-name)) @@ -243,6 +245,7 @@ (with-current-buffer temp (write-region (point-min) (point-max) output) (erase-buffer) + ) ;; Support for temp files. Much of this was inspired if not lifted Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> You are probably packaging only a single version, so you should only
> package a single DOC file, the one that goes with the binary you are
> packaging.
>
> If you include in the package emacs-XX.YY.ZZ as well as emacs, you
> should do the same with DOC.
I think the bug that Leo is reporting is that 'make install' installs
all DOC files, not just the newly built one.
The top level Makefile is quite explicit about doing this:
if [ `(cd ./etc; /bin/pwd)` != `(cd $(DESTDIR)${docdir}; /bin/pwd)` ]; \
then \
echo "Copying etc/DOC-* to $(DESTDIR)${docdir} ..." ; \
(cd ./etc; tar -chf - DOC*) \
[...]
A problem here is that the Makefile doesn't know which of the DOC-*
files is the correct one to install, since that is determined by some
Lisp code in loadup.el, and not written anywhere that the Makefile can
easily get at it.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
hack-local-variables-confirm loops forever when running keyboard macro
1. ensure temp file doesn't exist $ rm /tmp/file.txt 2. create a temp file with 'risky' local variable: $ printf "# Local Variables:\n# eval: (put 'w 't 'f)\n# End:\n" > /tmp/file.txt 3. run Emacs: $ emacs -Q 4. visit the temp file. it will prompt for whether to run the risky code: C-x C-f /tmp/file.txt RET 5. answer that you don't want to run it: n 6. start recording a macro: C-x ( 7. visit the risky temp file. it won't prompt this time, since the file is already visited C-x C-f /tmp/file.txt RET 8. stop recording the macro C-x ) 9. kill the temp file's buffer C-x k RET 10. run the macro. Emacs will hang forever: C-x e In GNU Emacs 22.0.92.18 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-19 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes: > By using sigblock/sigunblock we make sure that counter isn't > touched, so it fixes this particular case. However, why the counter > gets the wrong value is still not known. Can anyone even reproduce the bug other than me? If not, I'm more than happy to run any test cases you would like me to try. I've tried debugging it in various ways myself, but the timing seems to be so touchy that any attempt to observe what's going on changes things. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with tumme.el
Stefan Monnier <[EMAIL PROTECTED]> writes: > But tumme should not be using the user's login shell (especially since it > may be anything, including Emacs). It should use /bin/sh regardless. So it > doesn't really explain it. Would having 'set -o noclobber' in one of /bin/sh's startup files explain it? (debian) [EMAIL PROTECTED]:/tmp$ /bin/sh sh-3.1$ set -o noclobber sh-3.1$ date > /tmp/foo sh-3.1$ date > /tmp/foo sh: /tmp/foo: cannot overwrite existing file ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Kenichi Handa <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes: > >> Stefan Monnier <[EMAIL PROTECTED]> writes: >>>> Which function is it? >> > >> > I believe the function "at fault" is uudecode-decode-region > >> Yes, it's uudecode-decode-region. > > Ok, I've just installed a fix to make it work on a multibyte > buffer. Maybe I'm missing something, but isn't the problem in `insert', not in individual uses of it? Stefan wrote: | I believe the function "at fault" is uudecode-decode-region, although | personally I think the problem is much deeper, in the implicit use of | unibyte-char-to-multibyte in `insert'. So if the root cause of this is in `insert', isn't that where it should be fixed? Otherwise there's a risk that there's other code which is broken in the same way that uudecode-decode-region was before your patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
Richard Stallman <[EMAIL PROTECTED]> writes: > Sure, but I don't have access to commit the patch. > > Please send the patch again. I just tried, but got bounces both from you directly and from the list. From: Mail Delivery Subsystem <[EMAIL PROTECTED]> Subject: Delivery Status Notification (Failure) To: [EMAIL PROTECTED] Date: Thu, 11 Jan 2007 14:51:50 -0800 (PST) This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 12): 550 We don't want your stock spam There's a copy of the patch here: http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-01/msg00131.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Michael Albinus <[EMAIL PROTECTED]> writes: > I've committed a patch based on Chris' proposal. The has fixed the problem with copying the image file using TRAMP's ssh method, thanks. However, the underlying bug in `insert' remains I think. Stefan Monnier said the problem is that: | Basically, `insert' uses implicitly string-make-multibyte instead of | string-to-multibyte. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes: > The Gtk+ file dialog wants only absolute file names. Maybe tehre is > some case where we set the default file/directory to something > non-absolute? I'll investigate. I did exactly the same 4 times in a row, and only saw the message the first time. That may well have been the very first time the GTK file dialog was displayed since I booted as I never use it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes:
> It is probably very timing related. A small change changes the timing. Can
> you try the attachet patch?
That fixes the problem.
I ran the patched program 4 times, each time clicking the first icon a
lot of times to see if I could provoke a crash and I couldn't.
The first time I clicked the icon in the first run, however, I saw a
CRITICAL message in the terminal I ran it from:
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
(emacs:16263): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path:
assertion `g_path_is_absolute (local_full_path)' failed
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$ emacs -Q
[EMAIL PROTECTED]:~/programs/emacs$
This may of course be completely irrelevant.
Chris.
> Index: alloc.c
> *** alloc.c.~1.405.~ 2007-01-01 19:19:05.0 +0100
> --- alloc.c 2007-01-11 08:44:47.0 +0100
> ***
> *** 130,137
> #define BLOCK_INPUT_ALLOC \
> do\
> { \
> ! if (pthread_self () == main_thread) \
> ! BLOCK_INPUT;\
> pthread_mutex_lock (&alloc_mutex);\
> } \
> while (0)
> --- 130,137
> #define BLOCK_INPUT_ALLOC \
> do\
> { \
> ! if (pthread_equal (pthread_self (), main_thread)) \
> ! sigblock (sigmask (SIGIO)); \
> pthread_mutex_lock (&alloc_mutex);\
> } \
> while (0)
> ***
> *** 139,146
> do\
> { \
> pthread_mutex_unlock (&alloc_mutex); \
> ! if (pthread_self () == main_thread) \
> ! UNBLOCK_INPUT; \
> } \
> while (0)
>
> --- 139,146
> do\
> { \
> pthread_mutex_unlock (&alloc_mutex); \
> ! if (pthread_equal (pthread_self (), main_thread)) \
> ! sigunblock (sigmask (SIGIO)); \
> } \
> while (0)
>
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: is this a bug? string-equal seems to act strangely
Kenichi Handa <[EMAIL PROTECTED]> writes: > I don't remember why but the Lisp reader reads "\200" as a unibyte > string but if \x notation appears in a string, it is read as a > multibyte string. Thanks. I see that documented in (elisp) Non-ASCII in Strings: You can also represent a multibyte non-ASCII character with its character code: use a hex escape, `\xNNN', with as many digits as necessary. [...] using any hex escape in a string (even for an ASCII character) forces the string to be multibyte Is there a good reason why using \xNN should cause the string to be multibyte? It seems counterintuitive to me. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Stefan Monnier <[EMAIL PROTECTED]> writes: >> Which function is it? > > I believe the function "at fault" is uudecode-decode-region Yes, it's uudecode-decode-region. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii <[EMAIL PROTECTED]> writes: > I just tried this, and I cannot reproduce the problem with the > current CVS: I get an exact replica of the original file on my local > machine. I found what was causing the problem: I didn't have uudecode installed on the local machine, so TRAMP was using Emacs' Lisp version of uudecode, and using Emacs' write-region to save the results to a file. tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The " *tramp tmp*" buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. write-region uses fileio.c's e_write(), and that does the following, copying the buffer's value of enable-multibyte-characters into the coding system, before using it to write the region: coding->src_multibyte = !NILP (current_buffer->enable_multibyte_characters); My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? This patch demonstrates that it is enable-multibyte-characters which causes the problem, but I suspect that the bug really needs fixing in the C code: --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. +(set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
"Aaron S. Hawley" <[EMAIL PROTECTED]> writes: > This bug is really worth fixing. Otherwise, the lisp expression > aspect of `query-replace-regexp' will behave /unnecessarily/ slow. Sure, but I don't have access to commit the patch. Can someone who does please take a look and check it in if it's OK? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Do _all_ files from that machine copy incorrectly? Or just some? No. Plain text files copy correctly for example. And I just noticed that using /scp:... instead of /ssh:... works fine, too. I only used ssh in the first place because I didn't have ssh-agent running and the scp method prompts for the password over and over. > Also, could you show the contents of the *Messages* buffer after the > copy operation finishes? Certainly, but I don't know how much it will help. You see I have 2 machine here, both running debian sid. On one I can copy the 1-byte file and on the other it turns into a 2-byte file. The *Messages* buffer is identical on the 2 machines (other than the name of the temporary file used, which looks to be random). Here it is: Loading tramp... Loading regexp-opt...done Loading tramp...done tramp: Opening connection for [EMAIL PROTECTED] using ssh... tramp: Waiting for prompts from remote shell tramp: Waiting 60s for prompt from remote shell tramp: Sending password tramp: Found remote shell prompt. tramp: Initializing remote shell Loading time-date...done tramp: Waiting 30s for remote `/bin/sh' to come up... tramp: Setting up remote shell environment tramp: Checking remote host type for `send-process-string' bug tramp: Determining coding system tramp: Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE' tramp: Waiting 30s for `set +o vi +o emacs' tramp: Waiting 30s for `unset MAIL MAILCHECK MAILPATH' tramp: Waiting 30s for `unset CDPATH' tramp: Setting shell prompt tramp: Remote `/bin/sh' groks tilde expansion, good tramp: Finding command to check if file exists tramp: Finding a suitable `ls' command tramp: Checking remote `/usr/xpg4/bin/ls' command for `-n' option tramp: Checking remote `/bin/ls' command for `-n' option tramp: Testing remote command `/bin/ls' for -n...okay tramp: Using remote command `/bin/ls' for getting directory listings tramp: Sending the Perl `mime-encode' implementations. tramp: Sending the Perl `mime-decode' implementations. tramp: Checking remote encoding command `mimencode -b' for sanity tramp: Checking remote encoding command `mmencode -b' for sanity tramp: Checking remote encoding command `recode data..base64' for sanity tramp: Checking remote encoding command `uuencode xxx' for sanity tramp: Checking remote decoding command `uudecode -o /dev/stdout' for sanity tramp: Checking to see if encoding/decoding commands work on remote host...done tramp: Sending the Perl script `tramp_file_attributes'...done. tramp: Encoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1 with function uudecode-decode-region... Loading uudecode...done Wrote /tmp/tramp.5003zUW tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1...done tramp: Inserting local temp file `/tmp/tramp.5003zUW'...done Wrote /tmp/file Loading dired...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
Richard Stallman <[EMAIL PROTECTED]> writes: > Thanks. While looking into this problem, I discovered that some in-line images can't be scrolled even after the emacs-w3m fix. I don't know whether to report it or not because it's already known that image support in Emacs is pretty flaky, but, just in case this isn't known, I will: 1. create an image, 500 pixels tall in /tmp/image.jpg 2. make a new fundamental-mode buffer 3. insert a few lines of text, leave point at the end and evaluate (insert-image-file "/tmp/image.jpg") 4. go to the end of the buffer with M-> 5. repeat steps 3 and 4 a few times 6. go to the start of the buffer with M-< 7. resize the frame so that it's less than 500 pixels tall (ie. so that the image doesn't fit in the window) 8. scroll down repeatedly with C-v The first copy of the image will scroll properly, but scrolling gets stuck on the 2nd copy. the 2nd copy will scroll to the bottom and then jump back to the top. Hitting C-v very quickly (or holding it down) will eventually get past the 2nd copy, only to get stuck on the 3rd or 4th copy. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with transparent PNG image display
Leo <[EMAIL PROTECTED]> writes: > I actually have noticed this a long time ago using Gnus' Face/X-Face > feature. All transparent parts become black. Interesting. They go white here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman <[EMAIL PROTECTED]> writes: > * running the same build on the same debian sid machine under KDE > when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a ".deb" package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. > Unfortunately, the comparison between the two machines is not very > conclusive because so many things could be different between them. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! I arrived at that fix through a process of trial and error, not through any understand at all of what's going on. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes: > Thanks. Somehow the thread detection thingy isn't working > correctly. While I try to figure this out, please try the patch > suggested by YAMAMOTO Mitsuharu. That patch didn't appear to make any difference, but I've found one that fixes the bug for me. I have no idea why it works, but it does really seem to: --- src/blockinput.h2007-01-10 18:22:43.0 +0100 +++ src/new/blockinput.h2007-01-10 18:18:18.0 +0100 @@ -61,8 +61,10 @@ extern int pending_atimers; +static int mytmp; + /* Begin critical section. */ -#define BLOCK_INPUT (interrupt_input_blocked++) +#define BLOCK_INPUT (mytmp++, interrupt_input_blocked++) /* End critical section. I suppose this must be indicitive of some kind of race condition, since the mytmp++ doesn't do anything but delay the increment of interrupt_input_blocked by a very short amount of time. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
problem with transparent PNG image display
Download this image and open it in Emacs: http://tango-project.org/static/cvs/tango-art-tools/palettes/Tango-Palette.png The image has lots of transparent pixels. Using M-x set-background-colour RET and you'll see the background of the image changes with the background. Now use 'convert' from ImageMagick to make a copy of the image: $ convert Tango-Palette.png Tango-Palette-copy.png Open the new copy in Emacs and the transparent pixels show up as white pixels. Open the copy in The GIMP or gqview and you can see that the background really is still transparent. I'm using this version of convert: Version: ImageMagick 6.2.4 12/13/06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC In GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
> Katsumi Yamaoka <[EMAIL PROTECTED]> writes: > > > Thank you for the bug report. I see the present behavior of > > displaying big images in emacs-w3m buffers is really bad. [...] > > I will fix it anyway, next week. I received notice that this image scroll issue has been fixed in the CVS version of emacs-w3m now: > I've fixed the `w3m-modeline-title' function so as not to call > `w3m-force-window-update'. Formerly it was needed to update the > mode line appearance when a user shrinks or enlarges the frame > width manually, however I realized it has not to be done by the > application program for the most recent Emacs 22. Now we can > browse the page in question smoothly. Could you try the latest > CVS? You can also obtain it by: > > http://cvs.namazu.org/emacs-w3m.tar.gz?view=tar > > Although there is no difference in the sense that Emacs is not a > good image viewer for huge images, we have the `M-[' command. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore <[EMAIL PROTECTED]> writes: > It took 3 or 4 runs before I got the abort() to happen, but it still > happened. Told me something about a corrupted dwarf, which made me > smile. I tried a few experiments: no crash - works fine: - * running the same build on the same debian sid machine under KDE * running the same build on a different debian sid machine under GNOME * running the same build on a different debian sid machine under XFCE4 abort()s: * running the same build on the same debian sid machine with different GTK theme (tried Amaranth, Crux and Simple - all show the crash) So it's something specific to GNOME on this laptop. The laptop where it crashes has a dual core processor: [EMAIL PROTECTED]:~$ grep model /proc/cpuinfo model : 14 model name: Genuine Intel(R) CPU T2500 @ 2.00GHz model : 14 model name: Genuine Intel(R) CPU T2500 @ 2.00GHz The one where it doesn't is a 5 year old (single core) P4: (debian) [EMAIL PROTECTED]:~$ grep model /proc/cpuinfo model : 2 model name: Intel(R) Pentium(R) 4 CPU 2.20GHz The machine where it crashes is the same machine where I build Emacs (using the "-j 2" flag to use both cores to build). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Possible mouse-face redisplay glitch
[EMAIL PROTECTED] (Kim F. Storm) writes: > I can reproduce this on > > GNU Emacs 22.0.92.19 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) > of 2007-01-08 on kfs-l.imdomain.dk I can repoduce this on GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-09 on trpaslik too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > Could you try to see if the following patch changes the situation? It took 3 or 4 runs before I got the abort() to happen, but it still happened. Told me something about a corrupted dwarf, which made me smile. Here's the new gdb output: [EMAIL PROTECTED]:~/programs/emacs/src$ gdb ./emacs GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". DISPLAY = :0.0 TERM = dumb Breakpoint 1 at 0x80f4106: file emacs.c, line 431. Breakpoint 2 at 0x810d2e9: file sysdep.c, line 1385. (gdb) run -Q Starting program: /home/chris/programs/emacs/src/emacs -Q Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1219807008 (LWP 23559)] [Switching to Thread -1219807008 (LWP 23559)] Breakpoint 3 at 0x80c93f6: file xterm.c, line 7848. [New Thread -1230275664 (LWP 23562)] [New Thread -1233417296 (LWP 23563)] Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08148395 in emacs_blocked_free (ptr=0xb69005c8, ptr2=0xb78dbf21) at alloc.c:1223 #2 0xb75e08f5 in free () from /lib/tls/libc.so.6 #3 0xb78dbf21 in g_free () from /usr/lib/libglib-2.0.so.0 #4 0xb7da819d in gtk_rc_get_style () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7e608e8 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7e6120d in gtk_widget_set_name () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x080f0eae in xg_get_file_name (f=0x8603ac8, prompt=0x82bc04d "Find file: ", default_filename=0x87be7a4 "/home/chris/programs/emacs/src/", mustmatch_p=0, only_dir_p=0) at gtkutil.c:1551 #8 0x080d1c10 in Fx_file_dialog (prompt=136174920, dir=139876723, default_filename=140520968, mustmatch=137468105, only_dir_p=137468105) at xfns.c:5573 #9 0x08123df8 in Fread_file_name (prompt=136174923, dir=, default_filename=, mustmatch=137468105, initial=137468105, predicate=) at fileio.c:6401 #10 0x0815bc0a in Ffuncall (nargs=5, args=0xbfff00c0) at eval.c:3016 #11 0x0818642a in Fbyte_code (bytestr=136174603, vector=136174620, maxdepth=40) at bytecode.c:679 #12 0x0815b5e4 in funcall_lambda (fun=136174564, nargs=2, arg_vector=0xbfff0190) at eval.c:3184 #13 0x0815b7f7 in apply_lambda (fun=136174564, args=136174917, eval_flag=1) at eval.c:3108 #14 0x0815aeb8 in Feval (form=136174909) at eval.c:2370 #15 0x08158aa6 in Fcall_interactively (function=137779033, record_flag=137468105, keys=137508620) at callint.c:378 #16 0x080f8cd3 in Fcommand_execute (cmd=137779033, record_flag=dwarf2_read_address: Corrupted DWARF expression. ) at keyboard.c:10013 #17 0x081046da in command_loop_1 () at keyboard.c:1873 #18 0x0815a61b in internal_condition_case (bfun=0x8104360 , handlers=137512761, hfun=0x80fed00 ) at eval.c:1481 #19 0x080fe0de in command_loop_2 () at keyboard.c:1329 #20 0x0815a6dc in internal_catch (tag=137506745, func=0x80fe0b0 , arg=137468105) at eval.c:1222 #21 0x080feb4e in command_loop () at keyboard.c:1308 #22 0x080feed8 in recursive_edit_1 () at keyboard.c:1006 #23 0x080fefc6 in Frecursive_edit () at keyboard.c:1067 #24 0x080f4eb2 in main (argc=Cannot access memory at address 0x0 ) at emacs.c:1761 Lisp Backtrace: "read-file-name" (0x81ddd4b) "find-file-read-args" (0x81ddd4b) "call-interactively" (0x8365759) (gdb) info threads 3 Thread -1233417296 (LWP 23563) 0xb6fc655b in gnome_vfs_xfer_uri () from /usr/lib/libgnomevfs-2.so.0 2 Thread -1230275664 (LWP 23562) 0xb763ce49 in poll () from /lib/tls/libc.so.6 * 1 Thread -1219807008 (LWP 23559) abort () at emacs.c:431 (gdb) thr 1 [Switching to thread 1 (Thread -1219807008 (LWP 23559))]#0 abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at emacs.c:431 #1 0x08148395 in emacs_blocked_free (ptr=0xb69005c8, ptr2=0xb78dbf21) at alloc.c:1223 #2 0xb75e08f5 in free () from /lib/tls/libc.so.6 #3 0xb78dbf21 in g_free () from /usr/lib/libglib-2.0.so.0 #4 0xb7da819d in gtk_rc_get_style () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7e608e8 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7e6120d in gtk_widget_set_name () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x080f0eae in xg_get_file_name (f=0x8603ac8, prompt=0x82bc04d "Find file: ", default_filename=0x87be7a4 "/home/chris/programs/emacs/src/", mustmatch_p=0, only_dir_p=0) at gtkutil.c:1551 #8 0x080d1c10 in Fx_file_dialog (prompt=136174920, dir=139876723, default_filename=140520968, mustmatch=137468105, only_dir_p=137468105) at xfns.c:5573 #9 0x08123df8 i
Re: 4 week-old pretest bugs
Chris Moore <[EMAIL PROTECTED]> writes: > Incidentally, which file(s) did you edit? I had a look at some > Changelog files but can't see anything that looks relevant. Sorry, ignore that question. I was thinking that xterm.c was for Emacsen running inside a xterm... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes: > Chris Moore skrev: >> Jan Djärv <[EMAIL PROTECTED]> writes: >> >>> Can you run emacs in gdb and do a backtrace when this (Abort) >>> happens? >> >> Sure: > > Thanks for the info. I've checked in a change, can you test it? In my original report I mentioned that when I click the first icon, one of three things happens: 1) Emacs aborts 2) I see "Xlib: unexpected async reply" 3) It works as expected Your change seems to have eliminated number 3 in the above list. It now aborts almost every time I click the first icon, and about 1 in 4 times displays the Xlib error message. Incidentally, which file(s) did you edit? I had a look at some Changelog files but can't see anything that looks relevant. Here's new output from gdb: [EMAIL PROTECTED]:~/programs/emacs/src$ gdb ./emacs GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". DISPLAY = :0.0 TERM = dumb Breakpoint 1 at 0x80f40d6: file emacs.c, line 431. Breakpoint 2 at 0x810d239: file sysdep.c, line 1385. (gdb) run -Q Starting program: /home/chris/programs/emacs/src/emacs -Q Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1219311392 (LWP 23410)] [Switching to Thread -1219311392 (LWP 23410)] Breakpoint 3 at 0x80c93c6: file xterm.c, line 7848. [New Thread -1229780048 (LWP 23413)] [New Thread -1231381584 (LWP 23414)] [New Thread -1241515088 (LWP 23415)] Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08148278 in emacs_blocked_free (ptr=0x88d2d88, ptr2=0xb7954f21) at alloc.c:1223 #2 0xb76598f5 in free () from /lib/tls/libc.so.6 #3 0xb7954f21 in g_free () from /usr/lib/libglib-2.0.so.0 #4 0xb702c7ba in gnome_vfs_module_callback_invoke () from /usr/lib/libgnomevfs-2.so.0 #5 0xb6ee696e in gnome_authentication_manager_pop_async () from /usr/lib/libgnomeui-2.so.0 #6 0xb7084aa9 in fs_module_create () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #7 0xb7d9c166 in gtk_file_folder_list_children () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7d86e21 in _gtk_file_chooser_entry_set_base_folder () from /usr/lib/libgtk-x11-2.0.so.0 #9 0xb79dd057 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #10 0xb79c598b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #11 0xb79dd000 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #12 0xb794bda1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 #13 0xb794db21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0xb7950b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #15 0xb7951117 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #16 0xb7de50e5 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x080c926c in XTread_socket (sd=0, expected=1, hold_quit=0xbf8b3064) at xterm.c:7093 #18 0x080fb90d in read_avail_input (expected=1) at keyboard.c:6823 #19 0x080fbb0a in handle_async_input () at keyboard.c:6969 #20 0x08148175 in emacs_blocked_malloc (size=9, ptr=0xb79550b6) at alloc.c:1268 #21 0xb765bc05 in malloc () from /lib/tls/libc.so.6 #22 0xb79550b6 in g_malloc () from /usr/lib/libglib-2.0.so.0 #23 0xb7968489 in g_strdup () from /usr/lib/libglib-2.0.so.0 #24 0xb7e21170 in gtk_rc_get_style () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7ed98e8 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0 #26 0xb7e33387 in _gtk_size_group_get_child_requisition () from /usr/lib/libgtk-x11-2.0.so.0 #27 0xb7e33607 in _gtk_size_group_compute_requisition () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7ed928c in gtk_widget_size_request () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7da9970 in gtk_hbox_new () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb79d248b in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-2.0.so.0 #31 0xb79c3f49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #32 0xb79c5a7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0xb79d63b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #34 0xb79d7429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0xb79da1ce in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #36 0xb7e333ac in _gtk_size_group_get_child_requisition () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb7e33607 in _gtk_size_group_compute_requisition () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb7ed928c in gtk_widge
Re: 4 week-old pretest bugs
Jan Djärv <[EMAIL PROTECTED]> writes: > Can you run emacs in gdb and do a backtrace when this (Abort) > happens? Sure: Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) where #0 abort () at emacs.c:431 #1 0x08147f7b in emacs_blocked_malloc (size=16, ptr=0xb793c0b6) at alloc.c:1268 #2 0xb7642c05 in malloc () from /lib/tls/libc.so.6 #3 0xb793c0b6 in g_malloc () from /usr/lib/libglib-2.0.so.0 #4 0xb7e7dbcc in _gtk_tree_data_list_header_new () from /usr/lib/libgtk-x11-2.0.so.0 #5 0xb7dc9b77 in gtk_list_store_clear () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb7dc9e6f in gtk_list_store_new () from /usr/lib/libgtk-x11-2.0.so.0 #7 0xb7d6ddf7 in _gtk_file_chooser_entry_set_base_folder () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb79c4057 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #9 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #10 0xb79c4000 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 #11 0xb7932da1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 #12 0xb7934b21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #13 0xb7937b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #14 0xb7938117 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #15 0xb7dcc0e5 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x080c90ae in XTread_socket (sd=0, expected=1, hold_quit=0xbfc06b04) at xterm.c:7078 #17 0x080fb72d in read_avail_input (expected=1) at keyboard.c:6823 #18 0x080fb92a in handle_async_input () at keyboard.c:6969 #19 0x08148095 in emacs_blocked_free (ptr=0xb6005ba0, ptr2=0xb793bf21) at alloc.c:1223 #20 0xb76408f5 in free () from /lib/tls/libc.so.6 #21 0xb793bf21 in g_free () from /usr/lib/libglib-2.0.so.0 #22 0xb701caac in gnome_vfs_make_uri_canonical () from /usr/lib/libgnomevfs-2.so.0 #23 0xb706957f in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #24 0xb7d836b4 in gtk_file_system_uri_to_path () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7069169 in fs_module_init () from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so #26 0xb7d83416 in gtk_file_system_list_bookmarks () from /usr/lib/libgtk-x11-2.0.so.0 #27 0xb7d73fb5 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7d74201 in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7d742df in _gtk_file_chooser_default_new () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #31 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #32 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #34 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #36 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb7d3f5a5 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb7d020d0 in gtk_box_pack_start_defaults () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb7d3cecc in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb7d3f559 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0 #41 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #42 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #43 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #44 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #45 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #46 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #47 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #48 0xb7d6c933 in gtk_file_chooser_dialog_new () from /usr/lib/libgtk-x11-2.0.so.0 #49 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () #50 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #51 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #52 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #53 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #54 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #55 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #56 0xb7ed07c0 in gtk_window_new () from /usr/lib/libgtk-x11-2.0.so.0 #57 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #58 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #59 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #60 0xb79bd3b8 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #61 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #62 0xb79be5d9 in g_signal_emit () from /usr
Re: query-replace-regexp slow for evaluated lisp expressions
"Aaron S. Hawley" <[EMAIL PROTECTED]> writes: > Quoting Chris Moore <[EMAIL PROTECTED]>: > >> Or just replace it with \,\& for an even simpler test case. > > Damn right. Or: \,& makes it one character shorter, and gives lie to replace-match-string-symbols's docstring. It turns out that & doesn't need to be preceeded by a backslash in order to type it using Lisp syntax. >> Does this patch fix the bug? > > Yes, it does. I felt confident your patch would as soon as I looked > at it. I'm not confident about it. It seems to be working well for me still, but there's quite a lot of functionality available at the query-replace prompt which I neither understand nor use. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
replace.el documentation typo
--- old/replace.el 2007-01-07 19:23:43.0 +0100 +++ replace.el 2007-01-07 19:24:06.0 +0100 @@ -474,7 +474,7 @@ In interactive calls, the replacement text may contain `\\,' followed by a Lisp expression used as part of the replacement text. Inside of that expression, `\\&' is a string denoting the -whole match, `\\N' a partial matches, `\\#&' and `\\#N' the +whole match, `\\N' a partial match, `\\#&' and `\\#N' the respective numeric values from `string-to-number', and `\\#' itself for `replace-count', the number of replacements occured so far. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: inconsistent childish MS bashing
Richard Stallman <[EMAIL PROTECTED]> writes: > Also, we don't have to be consistent in our childishness. > A foolish consistency is the hobgoblin of little minds. You don't seem to like it when people refer to GNU/Linux as anything other than GNU/Linux, and yet you're happy to refer MS-DOS as MS-DOG? Is that a foolish inconsistency? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
Gregory Stark <[EMAIL PROTECTED]> writes: > I think it will if it's the first time you're saving the buffer since you > created it. But I tend to keep my emacs processes live for weeks or even > months. So I get one backup file and then no protection from then on. Right. I was getting confused. A new backup is caused by using C-x C-v, but not until the next time you save the buffer, and then the version which gets backed up is the version you overwrote your work with, so that's no help to you in this situation. > I think what I want is an option to make this the default behaviour. What if you customise after-save-hook's value to include (lambda () (setq buffer-backed-up nil)) ? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
"Aaron S. Hawley" <[EMAIL PROTECTED]> writes: > Then, do the most basic of replacements that would never be done in > practice, but shows how slow interactive regexp replacements can be: Or just replace it with \,\& for an even simpler test case. Does this patch fix the bug? --- old/replace.el 2007-01-07 01:40:26.0 +0100 +++ replace.el 2007-01-07 01:40:42.0 +0100 @@ -1518,8 +1518,7 @@ (set-match-data real-match-data) (setq next-replacement (funcall (car replacements) (cdr replacements) -replace-count) - noedit nil)) +replace-count))) (if (not query-flag) (let ((inhibit-read-only query-replace-skip-read-only)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
Gregory Stark <[EMAIL PROTECTED]> writes: > "Chris Moore" <[EMAIL PROTECTED]> writes: > >> When you typed 'yes' and hit return to say you wanted to save your >> work, Emacs will have made a backup of the file you were overwriting >> in ~. > > No, it didn't; I looked. The latest backup file I had was a couple weeks old. OK. I didn't test this much, but I thought when I did that I saw it make a backup at that point. > On that note I was wondering if there was any option to have emacs make more > backup files. There's this: C-x C-s runs the command save-buffer By default, makes the previous version into a backup file if previously requested or if this is the first save. Prefixed with one C-u, marks this version to become a backup when the next save is done. Prefixed with two C-u's, unconditionally makes the previous version into a backup file. Prefixed with three C-u's, marks this version to become a backup when the next save is done, and unconditionally makes the previous version into a backup file. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
[EMAIL PROTECTED] (Kim F. Storm) writes: > Great! > > Could you report this to the w3m maintainers. I reported it, and got a reply, as follows: Katsumi Yamaoka <[EMAIL PROTECTED]> writes: > Thank you for the bug report. I see the present behavior of > displaying big images in emacs-w3m buffers is really bad. IIRC, > the timer is used for only updating the title of a page in the > modeline (the title string has to be truncated when a user shrinks > the frame width). I will fix it anyway, next week. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
On 1/5/07, Kim F. Storm <[EMAIL PROTECTED]> wrote: Great! Could you report this to the w3m maintainers. Sure. One thing I still don't understand, however, is why timer-list is nil when I check it from inside Emacs, but Lisp_Object Vtimer_list in keyboard.c contains the w3m timer when process.c calls keyboard.c's timer_check(1). I thought Lisp's timer-list and C's Vtimer_list were just 2 names for the same data structure, but it seems I'm not seeing the full picture. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
[EMAIL PROTECTED] (Kim F. Storm) writes: > If you just break it in the debugger a few times and look at a backtrace. > If it is inside a select call, walk up the stack to see what the timeout > is - and where it is set. Thanks for your help. I found the 0.5 second timer in w3m.el: (run-at-time 0.5 nil This change stops the 'jumping back' behaviour that the original reported was complaining of, but I expect it breaks something else - I've just disabled the call which is causing the jump-back without understanding why or whether it's needed: --- Backup/w3m.el.~1~ 2007-01-02 09:50:03.0 +0100 +++ w3m.el 2007-01-05 15:27:40.0 +0100 @@ -7287,7 +7287,7 @@ (setq w3m-modeline-title-timer nil) (when (eq (selected-window) (get-buffer-window buffer)) - (w3m-force-window-update) + '(w3m-force-window-update) (current-buffer)) ;;;###autoload ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
inconsistent childish MS bashing
I just noticed the following text in the docstring for buffer-file-type: "This variable is meaningful on MS-DOG and Windows NT" If we're going to refer to MS-DOS as MS-DOG, shouldn't we demonstrate that we're consistent in our childishness by also referring to Windows as "Windoze" or "Winblows"? Alternatively we could use the proper "grown up" names "MS-DOS" and "Windows NT". ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undefined function defface
jpff <[EMAIL PROTECTED]> writes: > Did a "cvs update" this morning and then make bootstrap and it stopped > with > > Loading subr (source)... > Symbol's function definition is void: defface I did a 'cvs update' followed by a plain 'make' rather than 'make bootstrap' and it stopped with: Loading loadup.el (source)... Using load-path (/home/chris/programs/emacs/lisp) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Symbol's function definition is void: custom-declare-face make[1]: *** [emacs] Error 255 I then tried 'make bootstrap' and got the same error as Prof. ffitch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chris Moore <[EMAIL PROTECTED]> writes: > >> What else happens at 0.5 second intervals in Emacs that's not in >> timer-list or timer-idle-list? > > Could you run it under GDB and break it a couple of times to > see what happens (and particularly where the 0.5 seconds timeout > is coming from). Sure. But what should I break on? The refresh is very fast - I'm not going to be lucky enough to interrupt it during a refresh. Is there some function which you know will be called at the 0.5 second intervals? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
On 1/4/07, Leo <[EMAIL PROTECTED]> wrote: It turns out all hard links will be deleted after user log off. The file system is: `type ncpfs (rw,nosuid,nodev)' as I am running Emacs on my Univ's server. Is there any reason to choose hard link over symbolic link? All regular files are hard links. A hard link is just a name for a file on disk. "emacs" is one name for the executable and "emacs-22.0.92" is another name for the same executable. There's no concept of one being a link to the other, they are both names for the same file on disk. If "all hard links" are deleted, then both "emacs" and "emacs-22.0.92" will be deleted, along with all your other files. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Leo <[EMAIL PROTECTED]> writes: >> Can you paste the ./configure line you used exactly? > > ./configure --prefix=/home/sl392/packages/emacs22/ --with-gtk > --enable-locallisppath=/home/sl392/packages/emacs-local/site-lisp-22/ > && make install && make install INSTALL_STRIP="-s" Thanks. I'll try using something similar tomorrow. Someone asked whether the bug happens if you run ./emacs -Q to run Emacs without your .emacs file or site-lisp configuration, but I didn't see if you answered that. I'm guessing that something in your emacs-local/site-lisp-22/ directory might be to blame. Also, did you try compiling and installing Emacs and *not* running it at all? Does it still disappear after a while? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Leo <[EMAIL PROTECTED]> writes: > Hi all, > > To reproduce, > > 1. compile and install Emacs in dir "~/packages/emacs22" Compile it in ~/packages/emacs22" and install it to ~/packages/emacs22" as well? Can you paste the ./configure line you used exactly? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: "Control-X-prefix is now on M-x Control-X-prefix"
Richard Stallman <[EMAIL PROTECTED]> writes: >x iswitchb-mode C-h t C-s more C-b > > I am not sure what iswitchb-mode does that causes this, but I think it > is not a disaster if strange things happen in the tutorial when you > enable a mode that is not recommended for beginners. > > It would be nice to fix this some day, but we need not fix it now. I think it has already been fixed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: typo
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > BTW, I added a ChangeLog entry with a different e-mail address (the > one used in other entries). I suppose you're the same Chris Moore...? I am. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
[EMAIL PROTECTED] (Kim F. Storm) writes: > IMO, even better would be '-man' as that is what's passed to nroff > to format a normal man page. Well, '-m' is the flag and 'an' in the name of the macro package it's using, so 'an' isn't incorrect here, it's just not very clear. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chris Moore <[EMAIL PROTECTED]> writes: > >> If I visit a .jpg file and hit C-v a few times, I scroll down the >> image, but when I get to the bottom, it wraps back to the top again. > >> M-< and M-> don't do anything. > >> The scrollbar doesn't update to show >> my position through the image. Dragging the scrollbar's handle down >> doesn't scroll the image, These 3 together may each be minor, but together they make it very hard for me to get any feel for when I am in an image. end-of-buffer doesn't do anything, incrementally paging down loops forever, and there's no feedback about my current position in the image. For images with repeating patterns, it's very easy to get lost. Also, I was wrong when I said that the scrollbar doesn't update - it does sometimes update, but that seems to be random. Hold down C-v and let it auto-repeat for a while, and depending (in some way) on the image you're viewing, the scrollbar will move down a little. When it reaches the bottom, C-v fails with an 'end of buffer' error. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
[EMAIL PROTECTED] (Kim F. Storm) writes: > Before you scroll the image window in Emacs, could you try to select > some text in some other application (e.g. an xterm), so that the > selection is not "owned" by Emacs. Yes, and that doesn't change anything. I'm still seeing twice-secondly refreshes. (In GNOME, on debian unstable, if that's important). I cut my .emacs down to just 2 lines: (setq load-path (cons "~/emacs/share/emacs/site-lisp/w3m/" load-path)) (require 'w3m-load) and the refreshes still happen twice per second. It seems that freedesktop.org is down at the moment, so I found another page with large images: http://imagecomics.com/blog.php Interestingly, after I hit 'T' to load all images on this page, the images take quite a while to finish loading. Once the first big image has downloaded and is displayed, and while the rest of the images are still downloading, I can hit C-v and have it jump back many times per second. As soon as the other images have finished downloading, however, it goes back to the 0.5 second timer. My guess is that the messages displayed in the message area while images are downloading is what's causing the rapid refreshes during downloads. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tutorial: typo
--- tutorial.el~2007-01-03 10:08:23.0 +0100 +++ tutorial.el 2007-01-03 10:08:27.0 +0100 @@ -153,7 +153,7 @@ (insert "\n\nYou can use M-x " (format "%s" db) " RET instead.")) - (insert "\n\nWith you current key bindings" + (insert "\n\nWith your current key bindings" " you can use the key " where " to get the function `" In GNU Emacs 22.0.92.11 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-03 on trpaslik X server distributor `RealVNC Ltd', version 11.0.3370 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
Chong Yidong <[EMAIL PROTECTED]> writes: > Richard Stallman <[EMAIL PROTECTED]> writes: > >> That man page is written in doc rather than in an. >> >> Can we make woman detect use of the doc macros >> and give a meaningful error message? > > I checked in the test suggested by James Cloos. So now it says: "woman-decode-buffer: WoMan can only format manpages written in the an format" Wouldn't that be clearer if the 'an' was in quotes, what with 'an' being a word in the English language and all, and not a format many Emacs will have heard of I guess. I had to read the sentence a few times to parse it correctly. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tutorial: "Control-X-prefix is now on M-x Control-X-prefix"
Run $ emacs -Q and type: x iswitchb-mode C-h t C-s more C-b to see: The following key bindings used in the tutorial had been changed from the Emacs default in the TUTORIAL (English) buffer: Key Standard BindingIs Now On Remark C-x Control-X-prefixM-x Control-X-prefix more info there is no M-x Control-X-prefix command, and I've not rebound C-x to anything. In GNU Emacs 22.0.92.9 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-01 on trpaslik X server distributor `RealVNC Ltd', version 11.0.3370 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: en_GB.UTF-8 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_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
