Re: tool-bar doesn't work on the trunk with (default) GTK build

[Reiner Steib]

On Sat, Aug 04 2007, Jan Djärv wrote:

> Nick Roberts skrev:
>> On some of the GUD toolbar icons in a debug session, if I don't
>> move the mouse pointer off the tool-bar button and click again,
>> e.g., next, step nothing happens.  I have to move the pointer away
>> and back again to activate the button.  Oddly, there doesn't seem
>> to be a problem with other buttons like Info-next in Info.
>>
>
> That is another bug.  It only shows up in Gnus.

What is the bug showing up in Gnus?

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Reports to [EMAIL PROTECTED] (was: message.el user References control)

[Reiner Steib]

On Wed, Aug 01 2007, Miles Bader wrote:

> I'm not sure that anyone actually reads [EMAIL PROTECTED] -- every bug
> report I send there seems to be entirely ignored...

Within all articles in gnus.gnus-bug, I only found 2 unanswered
messages from you (8 years ago).  But it's true that there was quite a
long time when the group was full of spam (before Lars set up some
simple filter).  Nowaday the reports usually are answered, I think.

I wouldn't mind if the bug-report address would be changed to
[EMAIL PROTECTED] (so that the reports are archived on Gname), but Lars
doesn't want this because of the user settings included in the
auto-generated reports.  If I reply, I often Cc [EMAIL PROTECTED]

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: message.el user References control

[Reiner Steib]

On Thu, Jul 26 2007, [EMAIL PROTECTED] wrote:

>> Or are you saying that when the 21 limit is reached it incorrectly keeps the
>> oldest 21 rather than the most recent 21?  

Neither one is the case.  See below.

>> That would indeed be a plain bug.

> But that is what Lars said the RFC said the last time I brought this
> up. Which you can see somewhere in news://news.gnus.org/gnus.gnus-bug
> which is what http://gnus.org/resources.html says is the only way to
> see gnus bug reports.

ELISP> (message-shorten-references
 'References
 "<0> <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> \
 <11> <12> <13> <14> <15> <16> <17> <18> <19> <20> \
 <21> <22> <23> <24> <25> <26> <27> <28> <29> <30> \
 <31> <32> <33> <34> <35> <36> <37> <38> <39> <40>")
nil
ELISP> References: <0> <21> <22> <23> <24> <25> <26> <27> <28> <29> <30> \
<31> <32> <33> <34> <35> <36> <37> <38> <39> <40>

> Better add a nil/t defvar so the user can override the order just in
> case Lars wasn't joking.
>
>> While 21 references is probably always overkill, 1 is not always enough,

,[ http://www.landfield.com/usefor/drafts/gnksa-useage.txt ]
|   Comparison of GNKSA and USEAGE
|  C. H. Lindsey
|   5 June 2004
| 
| This document describes the differences between GNKSA
|  and USEAGE
| ,
| also with some references to USEFOR (draft-ietf-usefor-article-13.txt).
|
| [...]
|
| > The software MUST include at least three additional Message-IDs from
| > the original article's References header as well, if they are available.
| > Try to stay as close as possible to the spirit of "son-of-1036", which
| > states:
| > 
| > <   it  is absolutely necessary to shorten the header, as a des-
| >   perate last resort, a followup agent MAY do this by deleting
| >   some  of  the  message IDs.  However, it MUST not delete the
| >   first message ID, the last three message IDs (including that
| >   of  the immediate precursor), or any message ID mentioned in
| >   the body of the followup.>>
| 
| That requirement concerning Message-IDs in the body is no longer in
| USEFOR. It would be a pain to implement, and I doubt it ever was.
| 
| > 
| > However, it also says:
| > 
| > <   impose a limit on the length of header lines, body lines, or
| >   header  logical  lines,  that  limit  shall be at least 1000
| >   octets, including EOL representations.>>
| 
| USEAGE has 20 rather then 3.
`

20 + 1 = 21

> OK, make you a deal: 20, or OK, 25, anything, as long as you have a
> defvar so the user can override it -- allow him as big a beehive
> hairdo of references as he wants. Make 0 mean no references at all.
>
> I mean hardwiring any number without a defvar alternative should raise
> a red flag anyway.

Not if the hardwired number is recommended by the relevant standards.
I'm not convinced that we should have a defvar (or even a defconst for
this).

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Portability of `cp -p' (was: `cp' don't preserve timestamps by default on windows-xp)

[Reiner Steib]

On Wed, Jul 11 2007, Eli Zaretskii wrote:

>> -CP = cp -f
>> -CP_DIR = cp -rf
>> +CP = cp -fp
>> +CP_DIR = cp -rfp
>
> Thanks, but I don't want to rely on a GNU `cp' without checking.  

I'm not aware of any cp implementation that doesn't support `-p' and I
didn't find anything wrt this in (info "(autoconf)Limitations of Usual
Tools").  Do you have any example of a cp without `-p'?

> And I'd like us to understand the problem (which doesn't seem to
> happen to me) better before we consider solutions.

(I agree with this.)

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: A bug in doc string of `gnus-level-unsubscribed'?

[Reiner Steib]

On Mon, Jun 11 2007, Leo wrote:

>> Is the following doc string more clear?
>>
>> ,[  v gnus-level-unsubscribed RET ]
>> | gnus-level-unsubscribed is a variable defined in `gnus-start.el'.
>> | Its value is 7
>> | 
>> | 
>> | Documentation:
>> | Groups with levels less than or equal to this variable are
>> | unsubscribed. 
>
> This sentence looks redundant to me. The rest is clear.

The first sentence should fit in 80 columns including "  Variable: "
prepended.  So I tried to find a useful first line.  Does anyone have
a better suggestion?

>> | Groups with levels less than `gnus-level-subscribed', which should
>> | be less than this variable, are subscribed.  Groups with levels from
>> | `gnus-level-subscribed' (exclusive) upto this variable (inclusive)
>> | are unsubscribed.  See also `gnus-level-zombie', `gnus-level-killed'
>> | and the Info node `Group Levels' for details.
>> `

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Saving markup formats

[Reiner Steib]

[ I'd suggest to move this discussion to emacs-devel ]

On Sat, Jun 16 2007, Richard Stallman wrote:

[ Juri Linkov: ]
> What are the most preferable formats to save markup?  One variant is
> Enriched text.  It was designed for using in e-mail, but actually nobody
> uses it nowadays.  Most people prefer HTML in e-mail as a replacement of
> plain text.
>
> HTML would be useful.  RTF would be useful.  XML would be useful.
> The old Word format would be useful, at least to be able to read it.
> If you implement any of these, it will be a nice contribution.
> If you implement more than one, even better.

Oliver Scholz <[EMAIL PROTECTED]> (Cc-ed) has done some work on an
RTF reader for Emacs a couple of years ago.  Maybe his work is useful
in the current context.  Oliver has signed papers for Emacs (past and
future changes) and I'm quite sure he'd assign this code as well.

Here's the summary from the project page:

,[ http://savannah.nongnu.org/projects/emacs-rtf/ ]
| This package aims to implement the "Rich Text Format" (RTF), version
| 1.5, as a file format for GNU Emacs. It also provides the necessary
| framework to edit RTF documents in an Emacs buffer. It is thus
| intended to enhance the word processing capabilities of the Emacs
| environment. The goal is to enable a user to edit RTF documents
| without launching a non-Emacs application like OpenOffice or abiword.
| 
| This package is in a very early state of development. Currently only
| the reader is in the work, and only the main structure of it is
| implemented. Some RTF documents are already rendered correctly,
| though.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: A bug in doc string of `gnus-level-unsubscribed'?

[Reiner Steib]

[ Please report Gnus issues directly to the Gnus list [EMAIL PROTECTED],
  or at least Cc ding ]

On Mon, Jun 11 2007, Leo wrote:

> ,
> | gnus-level-unsubscribed is a variable defined in `gnus-start.el'.
> | Its value is 7
> | 
> | 
> | Documentation:
> | Groups with levels less than or equal to this variable are unsubscribed.
> | Groups with levels less than `gnus-level-subscribed', which should be
> | less than this variable, are subscribed.
> `
>
> The first 'less' should be 'more', right?

No, see (info "(gnus)Group Levels").  Is the following doc string more
clear?

,[  v gnus-level-unsubscribed RET ]
| gnus-level-unsubscribed is a variable defined in `gnus-start.el'.
| Its value is 7
| 
| 
| Documentation:
| Groups with levels less than or equal to this variable are
| unsubscribed.  Groups with levels less than `gnus-level-subscribed',
| which should be less than this variable, are subscribed.  Groups
| with levels from `gnus-level-subscribed' (exclusive) upto this
| variable (inclusive) are unsubscribed.  See also
| `gnus-level-zombie', `gnus-level-killed' and the Info node `Group
| Levels' for details.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars

[Reiner Steib]

On Fri, Jun 01 2007, Richard Stallman wrote:

> What version are you running?
> If it is from CVS, is it the trunk or which branch?

It was the trunk (tough not fully up-to-date) as written in my
original mail (or isn't 22.1.50.n unique to the trunk?):

| Note that my Emacs is not current, but from 2007-05-20 (trunk):
| 
| > In GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6)
| >  of 2007-05-20 on viandante
| > Windowing system distributor `The X.Org Foundation', version 11.0.70199902
| > configured using `configure  '--prefix=/import/xtra/emacs/HEAD'
| >  '--with-gtk' '--exec-prefix=/import/xtra/emacs/HEAD-i686''

Hopefully the installed patch by YAMAMOTO Mitsuharu will fix the
problem.  (BTW, I lost the crashed gdb session due to a reboot so I
cannot provide further info from the crashed session.)

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars

[Reiner Steib]

On Fri, Jun 01 2007, YAMAMOTO Mitsuharu wrote:

>> I think it crashed while creating the new frame; I don't recall
>> seeing the frame appear, but I'm not absolutely sure.

I think Emacs was creating a frame while/before my crash as well.

> I think this is due to string data relocation caused by ENCODE_UTF_8
> in x_set_name_internal (GTK+ only).

Thanks for analyzing the problem and providing the patch.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars

[Reiner Steib]

report-emacs-bug wrote:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

My Emacs session which has been already running for several days
(notebook with suspend to disk) crashed.  I don't recall which command
triggered the bug.

> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.

--8<---cut here---start->8---
(gdb) bt 
#0  0xb74fc4ca in memcpy () from /lib/libc.so.6
#1  0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6
#2  0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6
#3  0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6
#4  0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027)
at ~/.../cvs-HEAD/emacs/src/xfns.c:1653
#5  0x0807efec in prepare_menu_bars ()
at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015
#6  0x0808828a in redisplay_internal (preserve_echo_area=)
at ~/.../cvs-HEAD/emacs/src/xdisp.c:10964
#7  0x08100e72 in read_char (commandflag=1, nmaps=5, maps=0xbfd21040, 
prev_event=137472201, used_mouse_menu=0xbfd210f8, end_time=0x0)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:2670
#8  0x08103726 in read_key_sequence (keybuf=0xbfd211a4, bufsize=30, 
prompt=137472201, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:9215
#9  0x08105213 in command_loop_1 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1618
#10 0x0815b862 in internal_condition_case (bfun=0x8105080 , 
handlers=137517657, hfun=0x80ff9d0 )
at ~/.../cvs-HEAD/emacs/src/eval.c:1481
#11 0x080fee13 in command_loop_2 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1329
#12 0x0815b91a in internal_catch (tag=137510841, 
func=0x80fedf0 , arg=137472201)
at ~/.../cvs-HEAD/emacs/src/eval.c:1222
#13 0x080ff80c in command_loop ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1308
#14 0x080ffbab in recursive_edit_1 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1006
#15 0x080ffc96 in Frecursive_edit ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1067
#16 0x080f59e5 in main (argc=3, argv=0xbfd218a4)
at ~/.../cvs-HEAD/emacs/src/emacs.c:1762

(gdb) bt full
#0  0xb74fc4ca in memcpy () from /lib/libc.so.6
No symbol table info available.
#1  0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6
No symbol table info available.
#2  0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6
No symbol table info available.
#3  0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6
No symbol table info available.
#4  0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027)
at ~/.../cvs-HEAD/emacs/src/xfns.c:1653
bytes = 6
stringp = 1
do_free_icon_value = 0
do_free_text_value = 0
icon = {
  value = 0xf7a1a90 , 
  encoding = 31, 
  format = 8, 
  nitems = 6
}
coding_system = 137664729
#5  0x0807efec in prepare_menu_bars ()
at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015
tail = 
frame = 
f = 
tooltip_frame = 137472201
#6  0x0808828a in redisplay_internal (preserve_echo_area=)
at ~/.../cvs-HEAD/emacs/src/xdisp.c:10964
tail = 
w = (struct window *) 0xa0ccdf8
pause = 9
must_finish = 0
tlbufpos = {
  charpos = 0, 
  bytepos = 0
}
number_of_visible_frames = 30
polling_stopped_here = 0
consider_all_windows_p = 13764376
#7  0x08100e72 in read_char (commandflag=1, nmaps=5, maps=0xbfd21040, 
prev_event=137472201, used_mouse_menu=0xbfd210f8, end_time=0x0)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:2670
link = 
kb = (KBOARD *) 0x0
c = 137472201
local_getcjmp = {{
__jmpbuf = {-1076752632, 135895513, 137517177, 176817413, -1076752624, 0}, 
__mask_was_saved = 1, 
__saved_mask = {
  __val = {137472201, 3218214696, 267704, 3218214720, 175738212, 
3218214696, 135895680, 137472201, 137517177, 1, 267704, 3218214720, 
267704, 3218214936, 135619428, 137472201, 137517177, 175738212, 
0 , 33971, 639, 0}
}
  }}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0}, 
__mask_was_saved = 0, 
__saved_mask = {
  __val = {33971, 639, 0, 0, 298425, 175738212, 212582236, 33463, 
3218214536, 135893162, 267704, 33462, 33971, 639, 1, 0, 298425, 
175738212, 212582236, 33462, 3218214584, 135893162, 267696, 33461, 
3218214616, 135893373, 1, 137472201, 267696, 137517177, 267704, 
137472201}
}
  }}
key_already_recorded = 0
tem = 3
save = 0
previous_echo_area_message = 137472201
also_record = 137472201
reread = 0
polling_stopped_here = 
#8  0x08103726 in read_key_sequence (keybuf=0xbfd211a4, bufsize=30, 
prompt=137472201, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at ~/.../cvs-HEAD/emacs/src/keyboard

Re: Some libraries does (require 'cl)

[Reiner Steib]

On Fri, May 18 2007, Lennart Borgman (gmail) wrote:

> Lennart Borgman (gmail) wrote:
>>   (require 'cl)
>>
>> without (eval-when-compile ...). Is not that incorrect?
[...]
> More files doing this:
[...]

For the file from lisp/gnus/, these forms are no-ops in Emacs 21 and
up.  (In the development version of Gnus, we have removed these forms
because we o longer support Emacs < 21 there.)

>   gnus-registry.el

,[ gnus-registry.el ]
| (eval-when-compile (require 'cl))
| [...]
| ;; Function(s) missing in Emacs 20
| (when (memq nil (mapcar 'fboundp '(puthash)))
|   (require 'cl)
|   (unless (fboundp 'puthash)
| ;; alias puthash is missing from Emacs 20 cl-extra.el
| (defalias 'puthash 'cl-puthash)))
`

>   spam-stat.el

,[ spam-stat.el ]
| ;; Functions missing in Emacs 20
| 
| (when (memq nil (mapcar 'fboundp
|   '(gethash hash-table-count make-hash-table
| mapc puthash)))
|   (require 'cl)
|   (unless (fboundp 'puthash)
| ;; alias puthash is missing from Emacs 20 cl-extra.el
| (defalias 'puthash 'cl-puthash)))
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: visiting certain .c file adds to kill ring

[Reiner Steib]

On Sat, Apr 21 2007, martin rudalics wrote:

>> [subr.el]
>> ;; These are the XEmacs names:
>> (defalias 'point-at-eol 'line-end-position)
>> (defalias 'point-at-bol 'line-beginning-position)
>
> I think it's for Emacs < 20 compatibility.

I think the comment is correct.  XEmacs prefers point-at-[be]ol (which
are defined src/cmds.c in whereas line-*-position are defined in
lisp/obsolete.el) whereas Emacs prefers line-*-position (builtin;
point-at-[be]ol are aliases since Emacs 21 [1]).

Bye, Reiner.

[1]
,
| revision 1.209
| date: 1999-08-16 22:57:24 +0200;  author: kwzh;  state: Exp;  lines: +2 -0
| (point-at-eol, point-at-bol): New aliases.
`
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Sat, Mar 31 2007, Eli Zaretskii wrote:

>> From: Reiner Steib <[EMAIL PROTECTED]>
[...]
>> I've installed my patch after Richard's approval and there were no
>> further objections thereafter.
>
> I'm quite sure Richard didn't yet see my objection when he wrote his
> approval.  He normally lags one day behind everyone else in reading
> and responding to email.  I'd be happier if you waited for one more
> day before installing.

I'm sorry.  I didn't intend to install it prematurely.  I thought 48
hours (after your objection) was sufficient.  If Richard changes his
decision, I will revert the move of the icon.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Wed, Mar 28 2007, Eli Zaretskii wrote:

>> From: Reiner Steib <[EMAIL PROTECTED]>
[...]
>> This icon is already in Emacs (etc/images/exit.xpm) and used in Gnus.
>
> Yes.
>
>> I'd suggest to move `Info-exit' to the right side of the tool bar.
>
> I'd suggest to leave the location of the button alone.  Using a better
> icon is one thing, but changing location is quite another, one that is
> not called for by the problems discussed in this thread.  Why make
> such changes so close to a release?

Because exit.xpm as the first button looked strange to me.  For some
reason I'd expect it on the right.  (I can't explain why. I don't know
if some usability guidelines say anything about it.)

I've installed my patch after Richard's approval and there were no
further objections thereafter.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Wed, Mar 28 2007, Kim F. Storm wrote:

> Richard Stallman <[EMAIL PROTECTED]> writes:
>> It is possible that the solution of discarding the last few
>> global toolbar buttons to make room for the local ones
>> can be implemented now.  Would someone like to try?
>
> I don't think this is easy at all.
> Let's leave it alone for now.

ACK

> BTW, setting tool-bar-button-margin to 0 gives
> room for more tool bar items.

Maybe these variables should be customizable (after the release)?

,[ M-x apropos-variable RET ^tool-bar RET ]
| tool-bar-border
|   Variable: *Border below tool-bar in pixels.
| tool-bar-button-margin
|   Variable: *Margin around tool-bar buttons in pixels.
| tool-bar-button-relief
|   Variable: *Relief thickness of tool-bar buttons.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Wed, Mar 28 2007, Richard Stallman wrote:

[ http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. ]

> That sounds good, if there is no copyright issue for the icon.
> Can we use it without a delay?

This icon is already in Emacs (etc/images/exit.xpm) and used in Gnus.
I'd suggest to move `Info-exit' to the right side of the tool bar.

--8<---cut here---start->8---
--- info.el 27 Mar 2007 22:21:02 -  1.498
+++ info.el 28 Mar 2007 17:39:05 -
@@ -3244,7 +3248,6 @@
 (defvar info-tool-bar-map
   (if (display-graphic-p)
   (let ((map (make-sparse-keymap)))
-   (tool-bar-local-item-from-menu 'Info-exit "close" map Info-mode-map)
(tool-bar-local-item-from-menu 'Info-history-back "left-arrow" map 
Info-mode-map)
(tool-bar-local-item-from-menu 'Info-history-forward "right-arrow" map 
Info-mode-map)
(tool-bar-local-item-from-menu 'Info-prev "prev-node" map Info-mode-map)
@@ -3254,6 +3257,7 @@
(tool-bar-local-item-from-menu 'Info-goto-node "jump-to" map 
Info-mode-map)
(tool-bar-local-item-from-menu 'Info-index "index" map Info-mode-map)
(tool-bar-local-item-from-menu 'Info-search "search" map Info-mode-map)
+   (tool-bar-local-item-from-menu 'Info-exit "exit" map Info-mode-map)
map)))
 
 (defvar Info-menu-last-node nil)
--8<---cut here---end--->8---

Here's a screen shot:
<<< message/external-body;	name*=us-ascii''%2ftmp%2fste%2ftool-bar-exit.png; access-type=local-file: Unrecognized >>>

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Mon, Mar 26 2007, Richard Stallman wrote:

> * Maybe we should reduce the number of toolbar buttons in the
> default configuration.

I think the current icons are quite reasonable for an editor (and
comparable to gedit or kwrite).

Except for...
   : popping up a menu is not very useful for a toolbar
  icon (exception: context menus with mouse-3). [1]
... and maybe...
   : I don't think that opening the top level
  customization group is frequently used. [2]

> * If we assume that the global toolbar buttons are in order
> of decreasing importance, we can discard the last few
> so as to make room for all the buffer-specific toolbar buttons.

I don't think that icons are or should be ordered by "importance".
Related actions should be grouped ({new file, open file, ...}, {save,
save as}, {cut, copy, paste}, ...) and there are some conventions in
the order of the groups as well.

>At least , , , ,  are
>neither important nor useful (IMHO) in info mode.
>
> That is true for Info mode, but may not be true for other specialized
> modes.  But it suggests an idea: to have a feature for the mode to
> specify which buttons to retain from the global toolbar, or which
> buttons to discard.

There's such code in Gnus' gmm-utils.el[3].  In most Gnus modes, we
use a complete new tool bar.  But in message mode, we retain some
editing icons and remove other icons:

(defcustom message-tool-bar-zap-list
  '(new-file open-file dired kill-buffer write-file
 print-buffer customize help) ...)

An advantage of the code in gmm-utils.el is that the user can 
easily customize the tool bars.

> All this is for after the release.

Of course.

Bye, Reiner.

[1] In Gnus, the help button opens a mode specific info node:

,[  v gnus-info-nodes RET ]
| gnus-info-nodes is a variable defined in `gnus'.
| Its value is 
| ((gnus-group-mode "(gnus)Group Buffer")
|  (gnus-summary-mode "(gnus)Summary Buffer")
|  (gnus-article-mode "(gnus)Article Buffer")
|  (gnus-server-mode "(gnus)Server Buffer")
|  (gnus-browse-mode "(gnus)Browse Foreign Server")
|  (gnus-tree-mode "(gnus)Tree Display"))
| 
| Documentation:
| Alist of major modes and related Info nodes.
`

[2] In Gnus, this icon opens the mode's custom group.

[3]
(defun gmm-tool-bar-from-list (icon-list zap-list default-map)
  "Make a tool bar from ICON-LIST.

Within each entry of ICON-LIST, the first element is a menu
command, the second element is an icon file name and the third
element is a test function.  You can use \\[describe-key]
 to find out the name of a menu command.  The fourth
and all following elements are passed as the PROPS argument to the
function `tool-bar-local-item'.

If ZAP-LIST is a list, remove those item from the default
`tool-bar-map'.  If it is t, start with a new sparse map.  You
can use \\[describe-key]  to find out the name of an icon
item.  When \\[describe-key]  shows \" 
runs the command find-file\", then use `new-file' in ZAP-LIST.

DEFAULT-MAP specifies the default key map for ICON-LIST."
...)
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Sun, Mar 25 2007, Greg Bognar wrote:

> If we're talking about the proverbial Emacs newbie, there are few
> things more confusing than wiping out the toolbar ("Where did the
> buttons go?").  

I don't recall a single complaint or bug-report about this (before
yours). Note that info already behaves like this since Emacs 21.

> In contrast, modifying the toolbar by appending buttons to it is
> handy and easy to understand (not to mention that it suggests,
> correctly, that major modes *extend* Emacs's functionality).

Appending makes no sense, see below.

>> 1. There's not enough space (at least if the frame is 80 columns wide)
>>to add buttons without removing others.  At least with my settings,
>>there no room for any additional button on the standard tool bar.
>
> On modern graphical displays, this is a non-issue.  On my standard
> laptop display, if the frame is appr. 80 columns wide, 20-25 buttons
> can be placed on the toolbar (i.e., all the standard and Info buttons
> would be visible); 

You should be aware that other users use different settings than
yours.  On mine, only the 14 standard icons fit in one column:



> if the frame is maximized, you could have many more.  And at least
> Gtk Emacs does the right thing if there are two many buttons by
> placing a button on the right edge which pops up the toolbar buttons
> that couldn't fit.

I know.  But with the default X11 toolkit, a new row is opened, IIRC
(I don't have an Emacs 22 with X11 toolkit available).

> Talking about confusing: the button that resembles an `x' runs
> kill-this-buffer on the global toolbar; the same button runs Info-exit
> in Info mode.  The former kills the buffer, the latter merely buries
> it.  The same button behaves in inconsistently different ways in
> different contexts.  You thought you removed Info from the buffer
> list, and then it shows up unexpectedly as you move around your
> buffers.

Agreed.  We could use "exit.xpm" instead.

>> 2. The tool bar should only contain buttons for the most important
>>commands.  If too many buttons are present, it might be less
>>helpful / confusing.
>
> Modern word processors/text editors often have two or three toolbar
> lines with dozens of buttons.  If users don't find this confusing
> there, why would they find it confusing in Emacs?  

Are you thinking of badly designed interfaces like M$ Word?  Uses find
this confusing, I think.  No thanks, we don't need to follow bad
paragons.  Look at Firefox or Thunderbird for more carefully designed
tool bars.

> A more extensive toolbar could help newbies learn/explore Emacs
> faster.

I disagree.

>> 3. Which buttons from the standard tool bar would be very useful in
>>the info mode tool bar (or other major modes) as well?  Please give
>>concrete examples rather than general statements like "other
>>toolbar buttons".  At least , , ,
>>,  are neither important nor useful (IMHO) in info
>>mode.
>
> What about find-file, dired, copy, 

(I myself won't use the tool bar for these commands).  The user could
press   (Info-exit) and use the icons from there.  Or
use the menu, or M-x or ...

> print, 

Printing formated info file doesn't make much sense.  Use the
DVI-/PostScript-/PDF-output file for this.

> customize?  

After the release of Emacs 22, we could think about buttonizing
variables (like Gnus does it in article buffers).  I.e. in the
following text, "gnus-select-method" would be a button and pressing it
would end up in the corresponding customize buffer.

,[ (info "(gnus)Finding the News") ]
| The `gnus-select-method' variable says where Gnus should look for news.
| This variable should be a list where the first element says "how" and
| the second element says "where".  This method is your native method.
| All groups not fetched with this method are foreign groups.
| 
|For instance, if the `news.somewhere.edu' NNTP server is where you
| want to get your daily dosage of news from, you'd say:
`

> You are reading an Info file which mentions a file/library; you want
> find it with dired, or open it,

Same here, @file{foo.el} could be represented as link/button.

> or copy text from the Info buffer, or print your buffer, or open
> customize to implement the options you've just read about, etc.,
> etc.  It is very easy to disable/remove a particular button which is
> irrelevant in a context; this happens with the save button when you
> have a read-only buffer.

It is not invisible (i.e. room for other icons), but inactive.

> I don't want to sound obnoxious about this issue, and perhaps the
> buglist is not the right place to discuss it.  But I know many people
> who know a bit about Emacs, think it is great software, but don't use
> it because of its steep learning curve.  In my view, a well-designed
> toolbar and menubar can help people to climb that curve faster.  

We agree on the goal but not on the way, I think.

> There are also users who have their own ideas about the uses of

Re: Toolbar and info mode (and others)

[Reiner Steib]

On Sun, Mar 25 2007, Greg Bognar wrote:

> Many major modes add their own menus to the menubar.  Just as it would
> not be a good idea for them to wipe out the whole menubar, it is not a
> good idea for major modes to wipe out the toolbar.  After all, the
> user might want to use some other menu items.  Similarly, the user may
> want to use some other toolbar buttons.  So, for example, just because
> I read an Info file, I do not want other toolbar buttons to be
> unavailable.  If a major mode wants to modify the toolbar, it should
> *add* to it, without wiping the existing buttons out.

1. There's not enough space (at least if the frame is 80 columns wide)
   to add buttons without removing others.  At least with my settings,
   there no room for any additional button on the standard tool bar.

2. The tool bar should only contain buttons for the most important
   commands.  If too many buttons are present, it might be less
   helpful / confusing.

3. Which buttons from the standard tool bar would be very useful in
   the info mode tool bar (or other major modes) as well?  Please give
   concrete examples rather than general statements like "other
   toolbar buttons".  At least , , ,
   ,  are neither important nor useful (IMHO) in info
   mode.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Bug#412896: Error when trying to sign an e-mail: Problem with non-ASCII chars in passphrase

[Reiner Steib]

On Thu, Mar 01 2007, Frank Küster wrote:

> I am using the Debian "emacs-snapshot" package, for details see below,
> and experience problems when trying to gpg-sign an E-mail.  I press C-c
> RET C-s which produces in the first line "<'hashsign'part sign=pgpmime>"
>   (with s/'hashsign'/#/, but writing this literally has the effect that
>Gnus wants to sign the mail, which obviously wouldn't work),

,[ `C-h k C-c RET q' ]
| C-c RET q runs the command mml-quote-region
|   which is an interactive compiled Lisp function in `mml'.
| It is bound to   , C-c RET q.
| (mml-quote-region beg end)
| 
| Quote the MML tags in the region.
`

> and it asks for the passphrase when sending.  I enter it and get a "bad
> passphrase" together with an error (backtrace below)
>
> I have created a test gpg key and played with the passphrase, and one
> that triggered the error was "MitPara§".  "MitDollar$", on the other
> hand, worked fine.
>
> What should I do to debug this?  Is this list the right one, or should I
> ask the gnus people? 

I'm Cc-ing Daiki Ueno, the author of PGG.

This problem has been discussed in March 2006:
http://thread.gmane.org/gmane.emacs.gnus.general/62428/focus=62441
(BTW, Frank I've Cc-ed you in this thread.)

I don't know if the patch (which was "not the right fix" according to
Daiki) has been applied and what would be the right fix.  Should we
simply document that non-ascii characters don't work / may cause
problems?

> ,[ C-h v emacs-version RET ]
> | emacs-version is a variable defined in `version.el'.
> | Its value is "22.0.94.1"
> ,[ C-h v gnus-version RET ]
> | gnus-version is a variable defined in `gnus.el'.
> | Its value is "Gnus v5.11"

[ See http://thread.gmane.org/gmane.emacs.pretest.bugs/17314 for the
  complete message. ]

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: aspell dictionaries not initialized properly

[Reiner Steib]

On Fri, Jan 19 2007, Richard Stallman wrote:

> It would be simpler to call ispell-maybe-find-aspell-dictionaries
> unconditionally.  It does nothing if the job is already done, right?
> I think that would be cleaner.
>
> Aside from that, this clearly can't hurt anything, so if it fixes the
> bug, please install it.

Installed.

Franz, please update from CVS and test if it fixed the problem for
you.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

aspell dictionaries not initialized properly

[Reiner Steib]

Hi,

when `ispell-change-dictionary' is called interactively,
`ispell-valid-dictionary-list' initializes `ispell-dictionary-alist'
through `ispell-maybe-find-aspell-dictionaries' (which calls
`ispell-find-aspell-dictionaries').  But if the first call of
`ispell-change-dictionary' is non-interactively, aspell's dictionaries
are not added correctly so `ispell-change-dictionary' errors out with
"Undefined dictionary" (see IELM session below).  The patch[1] below
seems to solve the problem, but I'm not sure it the right thing to do.

Here's a sample Emacs session starting from "emacs -Q -f ielm" shows
the problem:

,
| ELISP> (featurep 'ispell)
| nil
| ELISP> (require 'ispell)
| ispell
| ELISP> ispell-program-name
| "/usr/bin/aspell"
| ELISP> ispell-local-dictionary
| nil
| ELISP> (with-temp-buffer
|(call-process ispell-program-name nil t nil "dicts")
|(buffer-string))
| "en\nen-variant_0\nen-variant_1\nen-variant_2\n[...]"
| ELISP> (mapcar 'car ispell-local-dictionary-alist)
| nil
| ELISP> (mapcar 'car ispell-dictionary-alist)
| (nil "american" "brasileiro" "british" "castellano" [... no "en" etc. ...])
| 
| ELISP> (ispell-change-dictionary "en")
| *** Eval error ***  Undefined dictionary: en
| ELISP> (message "With patch [1]")
| "With patch [1]"
| ELISP> (ispell-change-dictionary "en")
| "Local Ispell dictionary set to en"
| ELISP> 
`

[1]
--8<---cut here---start->8---
*** ispell.el   18 Jan 2007 12:27:56 +0100  1.204
--- ispell.el   18 Jan 2007 22:51:25 +0100  
***
*** 2607,2612 
--- 2607,2616 
   (mapcar 'list (ispell-valid-dictionary-list)))
  nil t)
 current-prefix-arg))
+   (unless (called-interactively-p)
+ ;; If interactive, `ispell-valid-dictionary-list' has already set up
+ ;; aspell ditionaries.
+ (ispell-maybe-find-aspell-dictionaries))
(unless arg (ispell-buffer-local-dict 'no-reload))
(if (equal dict "default") (setq dict nil))
;; This relies on completing-read's bug of returning "" for no match
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Failure to submit second netnews message

[Reiner Steib]

On Fri, Jan 05 2007, [EMAIL PROTECTED] wrote:

> I am still getting the error that I cannot submit two approved
> messages to a moderated mailing list without restarting emacs.

We already asked you several time go give a complete, self-contained
recipe (starting with "emacs -Q") to reproduce the bug.

> *Messages* says
[...]
> load-library: Cannot open load file: moderate
> Loading /bigdisk/jpff/News/moderate.elc...
> Package rnews is obsolete
> Loading /bigdisk/jpff/News/moderate.elc...done

`moderate.el' is not part of Emacs.

> Loading rmail...done
> Counting messages...done
> Loading rmime...done
> Formatting MIME message... done
> Loading mail-extr...done
> Loading rmailkwd...done
> Loading rnewspost...done
> Package rnewspost is obsolete
> Mark set
> Loading rmailmime...done

`rmailmine' is not part of Emacs.

> call-interactively: Beginning of buffer
> Mark set
> Loading newcomment...done
> Auto-saving...done
> Mark set [2 times]
> Sending...
> The article contains an Approved header.  Really post? (y or n) 
> Really use this possibly unknown group: comp.music.research? (y or n) 
> Sending news via news using nntp...
> Sending...done
> Making completion list...
> Fontifying *Completions*... (syntactically...)
> Mark set [3 times]
> Sending...
> message-send: Denied posting -- multiple copies
> call-interactively: Beginning of buffer
>
> ==John ffitch

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: safe-local-variable stuff

[Reiner Steib]

On Wed, Jan 03 2007, Stefan Monnier wrote:

>> +(default-directory   . string-or-null-p) ;; C source code
>
> Why "-or-null-" ?  default-directory should never be nil.

I though because the global value is nil.  But maybe this makes no
sense.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: safe-local-variable stuff

[Reiner Steib]

On Wed, Jan 03 2007, Peter Dyballa wrote:

> When I save a *compilation* buffer and I later visit that file, the
> GNU Emacsen from CVS (22.0.*, 23.0.0) complain about the
> default-directory variable used. Is there some reason why this
> variable is treated as unsafe? Why are the *compilation* buffers
> settings this unsafe variable at all?

I think it makes sense to mark `default-directory' as safe.  If nobody
objects, I'll commit this change:

--8<---cut here---start->8---
--- files.el03 Jan 2007 12:13:53 +0100  1.875
+++ files.el03 Jan 2007 14:21:21 +0100  
@@ -2442,6 +2442,7 @@
 (mapc (lambda (pair)
(put (car pair) 'safe-local-variable (cdr pair)))
   '((buffer-read-only. booleanp) ;; C source code
+   (default-directory   . string-or-null-p) ;; C source code
(fill-column . integerp) ;; C source code
(indent-tabs-mode. booleanp) ;; C source code
(left-margin . integerp) ;; C source code
--8<---cut here---end--->8---

We could also use `file-directory-p' or `stringp' instead of
`string-or-null-p', but I think `string-or-null-p' is the best choice.

> Or did I miss some customisation?
>
> One AUCTeX variable is treated as unsafe, too: TeX-command-default. 

emacs-pretest is the wrong list for this.  I'll answer to this part on
auctex-devel (Cc-ing you).

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: [Gnus,pgg,mml2015.el] Flash of raw encrypted article

[Reiner Steib]

On Sun, Dec 31 2006, Ralf Angeli wrote:

> With the setting
> (setq mm-verify-option 'known)
> the raw article will be shown for a split second before the rendered
> one appears when an encrypted article like
> <[EMAIL PROTECTED]> (from emacs-devel) is to be
> displayed in Gnus (up-to-date No Gnus).
[...]
> (emacs-pretest-bug is probably not the ideal list for this report, 

JFTR: The PGG code in No Gnus (development version) and Emacs CVS
differ [1].  Unless this is reproducible with Gnus 5.11, we can
disregard this report with regards to the Emacs release.

> but my messages to ding seem to have gone to a black hole.)

How did you send it (direct mail, posting through Gmane [2], posing
through news.gnus.org)?  Please resend by mail.  If it doesn't appear
on the list, please contact the list owner (Jason L Tibbitts III
).

Bye, Reiner.

[1] Daiki Ueno suggested to use the PGG from v5-10 also in No Gnus.  I
don't have a strong opinion on this.  I don't recall the
differences.

[2] From time to time my postings to gmane.emacs.gnus.general
disappear, then I resend by mail (`S D e').
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: [Gnus,pgg,mml2015.el] Flash of raw encrypted article

[Reiner Steib]

On Sun, Dec 31 2006, Ralf Angeli wrote:

> With the setting
> (setq mm-verify-option 'known)
> the raw article will be shown for a split second before the rendered
> one appears when an encrypted article like
> <[EMAIL PROTECTED]> (from emacs-devel) is to be
> displayed in Gnus (up-to-date No Gnus).
[...]
> (emacs-pretest-bug is probably not the ideal list for this report, 

JFTR: The PGG code in No Gnus (development version) and Emacs CVS
differ [1].  Unless this is reproducible with Gnus 5.11, we can
disregard this report with regards to the Emacs release.

> but my messages to ding seem to have gone to a black hole.)

How did you send it (direct mail, posting through Gmane [2], posing
through news.gnus.org)?  Please resend by mail.  If it doesn't appear
on the list, please contact the list owner (Jason L Tibbitts III
).

Bye, Reiner.

[1] Daiki Ueno suggested to use the PGG from v5-10 also in No Gnus.  I
don't have a strong opinion on this.  I don't recall the
differences.

[2] From time to time my postings to gmane.emacs.gnus.general
disappear, then I resend by mail (`S D e').
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: [bug] Gnus weird behavior

[Reiner Steib]

On Fri, Dec 29 2006, Richard Stallman wrote:

> > Would you please install your patch in the v5-10 branch?  Or do you or
> > anyone else see a problem with it or a better fix?
>
> Done.
>
> Is this patch installed in Emacs yet?

No.  But it has been installed in the stable (v5-10) branch of Gnus.
It will be synched to Emacs with Miles (Cc-ed) next sync.  [ There
have been some other fixed (mostly documentation issues) since the
last sync, so it's better to wait for Miles than to only apply this
patch. ]

> Does it fix the problem that Leo reported?

Yes.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: [bug] Gnus weird behavior

[Reiner Steib]

On Tue, Dec 26 2006, Daiki Ueno wrote:

>> In <[EMAIL PROTECTED]> 
>>  Leo <[EMAIL PROTECTED]> wrote:
>> To reproduce:
>
>>- go to the article buffer
>>- click the right arrow in the toolbar
>
>> Backtrace:
>> ,
>> | Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>> |   gnus-summary-next-article(nil)
>> |   call-interactively(gnus-summary-next-article)
>> `
>
> The cause of the problem seems that gnus-article-mode uses
> gnus-summary-mode's tool-bar-map and a few commands in it expect to be
> called from the summary buffers.
[...]
> Here is a patch.

Would you please install your patch in the v5-10 branch?  Or do you or
anyone else see a problem with it or a better fix?

> Index: lisp/gnus/gnus-sum.el
> ===
> RCS file: /sources/emacs/emacs/lisp/gnus/gnus-sum.el,v
> retrieving revision 1.96
> diff -c -r1.96 gnus-sum.el
> --- lisp/gnus/gnus-sum.el 12 Dec 2006 16:12:12 -  1.96
> +++ lisp/gnus/gnus-sum.el 26 Dec 2006 01:12:40 -
> @@ -7333,6 +7333,9 @@
>  If SUBJECT, only articles with SUBJECT are selected.
>  If BACKWARD, the previous article is selected instead of the next."
>(interactive "P")
> +  ;; Make sure we are in the summary buffer.
> +  (unless (eq major-mode 'gnus-summary-mode)
> +(set-buffer gnus-summary-buffer))
>(cond
> ;; Is there such an article?
> ((and (gnus-summary-search-forward unread subject backward)

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Failure to submit second netnews message

[Reiner Steib]

On Thu, Dec 07 2006, [EMAIL PROTECTED] wrote:

> ...and to be more precise

Please give a *complete recipe* to reproduce the problem.  Please also
read my previous reply
.

> I send a message to a newsgroup using gnus (as defined in
> lisp/gnus/message.el)
> The first message is sent successfully.
> I then send another message, totally different text to the same group
> (after all I moderate it and that is what I have to do) and it rejects
> the second message saying
> (error "Denied posting -- multiple copies")
> which is on line 3597 on lisp/gnus/message.el
>
> I am assuming that some value is not getting cleaned up when a message
> is sent.
>
> I will experiment with sending two unmoderated messages to see what
> happens, but I am late for a meeting now
>
> ==John ffitch

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: gnus crashes on threads deeper than 333 articles

[Reiner Steib]

On Tue, Dec 05 2006, Richard Stallman wrote:

> > What about providing an option and keep the current recursive as
> > default?  See the patch below (`gnus-sort-threads-loop' is your
> > function).
>
> I think this is a good approach.
>
> Why do we want to keep the recursive version?
> Why add an option?
>
> We know that the loop works, so let's just use that.

Well, the recursion is well tested (part of Gnus at least since 1997)
with only _two_ reported problems with it over all those years
(i.e. the situation when the recursion fails is *very rare*).  The new
function has been tested in practice only by two persons.  I wouldn't
feel comfortable to change such an important function so shortly
before the Emacs release without providing a simple way back in case
of problem with the loop implementation.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: gnus crashes on threads deeper than 333 articles

[Reiner Steib]

On Mon, Dec 04 2006, Chris Moore wrote:

> OK, so the 'loop' version of the sort function does seem to work, but
> fixing that has shown up a new problem.
>
[ gnus-make-thread-indent-array ]
> The '200' and '201' in this function limit the thread depth.

I'd suggest the following patch on top of the previous.  Which size
was sufficient for you?

--8<---cut here---start->8---
--- gnus-sum.el 08 Nov 2006 00:45:38 +0100  7.163
+++ gnus-sum.el 04 Dec 2006 19:54:43 +0100  
@@ -3442,11 +3442,14 @@
   t
 (not (cdr (gnus-data-find-list article)
 
+(defvar gnus-make-thread-indent-array-size 400)
+
 (defun gnus-make-thread-indent-array ()
-  (let ((n 200))
+  (let ((n gnus-make-thread-indent-array-size))
 (unless (and gnus-thread-indent-array
 (= gnus-thread-indent-level gnus-thread-indent-array-level))
-  (setq gnus-thread-indent-array (make-vector 201 "")
+  (setq gnus-thread-indent-array
+   (make-vector (1+ gnus-make-thread-indent-array-size) "")
gnus-thread-indent-array-level gnus-thread-indent-level)
   (while (>= n 0)
(aset gnus-thread-indent-array n
--8<---cut here---end--->8---

> Increasing these numbers has allowed me to finally open my large
> Increasing these mailbox!

Another workaround would be to turn off threading for this group,
wouldn't it?  I mean, from your description threading seems quite
useless for this group.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: gnus crashes on threads deeper than 333 articles

[Reiner Steib]

On Sun, Dec 03 2006, Chong Yidong wrote:

> Chris Moore <[EMAIL PROTECTED]> writes:
>
>> I just tried opening a mail folder using nnimap in gnus.
>>
>> One of the threads in the folder is 834 messages long, and each
>> message in the thread is a reply to the previous one which results in
>> the thread being 834 messages 'deep'.
>>
>> The definition of gnus-sort-threads in lisp/gnus/gnus-sum.el does
>> this:
>> (let ((max-lisp-eval-depth 5000))
>> but it doesn't increase max-specpdl-size.  Maybe it should?
>>
>> Or maybe it shouldn't impose fixed limits on the maximum allowable
>> thread length at all.  A re-implementation using a loop instead of
>> recursion should be able to get around this limit.  It's walking the
>> thread tree, sorting as it goes.
>
> The attached patch provides a reimplementation of gnus-sort-threads-1
> that uses a loop instead of recursion.  It may be a little too
> intricate a change to check into Emacs at this point, though.  What do
> people think?

I searched the archives and I only found one more report about this
problem, so it seems to be a *very rare* situation.  I'm not sure if
such a change should be made now (in the stable series).

What about providing an option and keep the current recursive as
default?  See the patch below (`gnus-sort-threads-loop' is your
function).

Is your implementation faster or slower than the recursion?

--8<---cut here---start->8---
--- gnus-sum.el 09 Nov 2006 13:32:35 +0100  7.163
+++ gnus-sum.el 04 Dec 2006 16:55:43 +0100  
@@ -4649,20 +4649,48 @@
  (1+ (point-at-eol))
(gnus-delete-line)))
 
-(defun gnus-sort-threads-1 (threads func)
+(defun gnus-sort-threads-recursive (threads func)
   (sort (mapcar (lambda (thread)
  (cons (car thread)
(and (cdr thread)
-(gnus-sort-threads-1 (cdr thread) func
+(gnus-sort-threads-recursive (cdr thread) func
threads) func))
 
+(defun gnus-sort-threads-loop (threads func)
+  (let* ((superthread (cons nil threads))
+(stack (list (cons superthread threads)))
+remaining-threads thread)
+(while stack
+  (setq remaining-threads (cdr (car stack)))
+  (if remaining-threads
+ (progn (setq thread (car remaining-threads))
+(setcdr (car stack) (cdr remaining-threads))
+(if (cdr thread)
+(push (cons thread (cdr thread)) stack)))
+   (setq thread (caar stack))
+   (setcdr thread (sort (cdr thread) func))
+   (pop stack)))
+(cdr superthread)))
+
+(defcustom gnus-sort-threads-function 'gnus-sort-threads-recursive
+  "Function used to sort threads.
+There are two pre-defined functions:
+`gnus-sort-threads-recursive', and `gnus-sort-threads-loop'.  If
+you get an error message \"Variable binding depth exceeds
+max-specpdl-size\" during threading, set this variable to
+`gnus-sort-threads-loop'."
+  :group 'gnus-thread
+  :version "22.1" ;; Gnus 5.10.9
+  :type '(choice (const :tag "recursion" gnus-sort-threads-recursive)
+(const :tag "loop" gnus-sort-threads-loop)))
+
 (defun gnus-sort-threads (threads)
   "Sort THREADS."
   (if (not gnus-thread-sort-functions)
   threads
 (gnus-message 8 "Sorting threads...")
 (let ((max-lisp-eval-depth 5000))
-  (prog1 (gnus-sort-threads-1
+  (prog1 (funcall gnus-sort-threads-function
 threads
 (gnus-make-sort-function gnus-thread-sort-functions))
 (gnus-message 8 "Sorting threads...done")
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Failure to submit second netnews message

[Reiner Steib]

On Sat, Nov 25 2006, Eli Zaretskii wrote:

>> From: Richard Stallman <[EMAIL PROTECTED]>
>> 
>> This is not a precise report, but even if it were precise
>> we would probably find it hard to try to reproduce this.
>
> At least please tell what package you used to post the articles, and
> what Emacs commands you typed for that.

| Recent messages:
| [...]
| Sending...
| message-send: Denied posting -- multiple copies

I believe he used `message-send' from `gnus/message.el'.  The error
comes from the GNKSA (Good Net-Keeping Seal of Approval) check
`multiple-copies':

,[  v message-shoot-gnksa-feet RET ]
| message-shoot-gnksa-feet is a variable defined in `message'.
| Its value is nil
| 
| Documentation:
| *A list of GNKSA feet you are allowed to shoot.
| Gnus gives you all the opportunity you could possibly want for
| shooting yourself in the foot.  Also, Gnus allows you to shoot the
| feet of Good Net-Keeping Seal of Approval.  The following are foot
| candidates:
| `empty-article' Allow you to post an empty article;
| `quoted-text-only'  Allow you to post quoted text only;
| `multiple-copies'   Allow you to post multiple copies;
| `cancel-messages'   Allow you to cancel or supersede messages from
| your other email addresses.
`

As the report is not precise, I don't know if he should add
`multiple-copies' to `message-shoot-gnksa-feet' or if there's a
different problem.  AFAIK, Gnus doesn't have any builtin capability
for moderating Usenet group, cf. (info "(gnus)Moderation").

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: tutorial: "The key has been rebound, but you can use instead"

[Reiner Steib]

On Wed, Nov 22 2006, Richard Stallman wrote:

> | ** The key  has been rebound, but you can use  instead [More 
> information] **
> `
>
> I fail to understand what "but you can use  instead" means.
>
> Is that because the value is nil?  I think that case needs to be
> handled specially.  It can say just "The key  has been rebound,
> so you can't use it this way."

There must be a bug: I also get "you can use  instead" when I do
(global-set-key (kbd "C-g") 'goto-line) after emacs -Q.

> Additionally, as the warning line is longer than 80 characters it's
> quite disturbing.
>
> Let's change `information' to `info'.

Better, but even with "[More info]" or "[More]", the lines may get too
long.

I think summarizing the problematic keys _at the very beginning_ of
the tutorial or in a splash screen at it's startup would be much
better than interrupting the tutorial text several times in the middle
of a sentence.

Suggestion: Let's keep the colors on the changed keys within the text,
but don't print the warning lines ("** ... **").  When the user clicks
on the colored keys, display the corresponding help buffer like we do
for on "[More information]" now.

> BTW, if you do the same with a German language environment, the German
> tutorial is interrupted by lines in English.  Also the "NOTICE" is in
> English.
>
> You can add German versions in tutorial.el.

I'll do so, but I think the current English version needs improvement
first.

> I think English is better than nothing.

I'm not sure.  Please try: Enable CUA mode and try to read the French
or the Spanish tutorial.

--8<---cut here---start->8---
>>  Tapez C-v (Voir l'écran suivant) pour passer à l'écran suivant
** The key C-v has been rebound, but you can use  instead [More 
information] **
(faites-le, pressez la touche CTRL tout en pressant la touche v).
À partir de maintenant, vous devrez le faire à chaque fois que
vous avez fini de lire l'écran.

Vous remarquerez qu'il y a un recouvrement de deux lignes lorsque l'on
passe d'un écran à un autre : cela permet une certaine continuité dans
la lecture du texte.

La première chose que vous devez savoir est comment vous déplacer à
travers le texte. Vous savez déjà comment avancer d'un écran avec
C-v. Pour revenir un écran en arrière, tapez M-v (pressez la touche
** The key M-v has been rebound, but you can use  instead [More 
information] **
META tout en appuyant sur v ou faites v si vous n'avez pas de
touche META, EDIT ou ALT).

>>  Faites M-v, puis C-v plusieurs fois.
** The key C-v has been rebound, but you can use  instead [More 
information] **

Si votre terminal en dispose, vous pouvez également utiliser les
touches PgUp et PgDn pour monter ou descendre d'un écran, bien que les
combinaisons C-v et M-v soient plus efficaces.
** The key M-v has been rebound, but you can use  instead [More 
information] **
** The key C-v has been rebound, but you can use  instead [More 
information] **

* RÉSUMÉ


Les commandes suivantes servent à manipuler des écrans :

C-v Avance d'un écran
** The key C-v has been rebound, but you can use  instead [More 
information] **
M-v Recule d'un écran
** The key M-v has been rebound, but you can use  instead [More 
information] **
C-l Efface l'écran et réaffiche tout le texte autour du
curseur, qui est placé au milieu de l'écran
(il s'agit de CTRL-L, pas de CTRL-1).
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

language environment should not be derived from LC_CTYPE

[Reiner Steib]

[ I already sent this yesterday (via Gmane), but apparently it didn't
  make it to the list (<[EMAIL PROTECTED]>).
  Sorry if you get it twice. ]

`M-x report-emacs-bug' wrote:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

I have the following locale settings [1]:

$ env|grep -e LC_ -e LANG
LANG=en_US
LC_COLLATE=POSIX
[EMAIL PROTECTED]

$ emacs -Q

`current-language-environment's value is "German" and I get the German
tutorial.  I expected to see the English version and an English
language environment:


,[ (info "(libc)Locale Categories") ]
| `LC_CTYPE'
|  This category applies to classification and conversion of
|  characters, and to multibyte and wide characters; see *Note
|  Character Handling::, and *Note Character Set Handling::.
|
| [...]
|
| `LC_MESSAGES'
|  This category applies to selecting the language used in the user
|  interface for message translation (*note The Uniforum approach::;
|  *note Message catalogs a la X/Open::)  and contains regular
|  expressions for affirmative and negative responses.
| 
| `LC_ALL'
|  This is not an environment variable; it is only a macro that you
|  can use with `setlocale' to set a single locale for all purposes.
|  Setting this environment variable overwrites all selections by the
|  other `LC_*' variables or `LANG'.
| 
| `LANG'
|  If this environment variable is defined, its value specifies the
|  locale to use for all purposes except as overridden by the
|  variables above.
`

> In GNU Emacs 22.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3)
>  of 2006-11-21 on viandante
> X server distributor `The X.Org Foundation', version 11.0.60802000
> configured using `configure '--prefix=...' '--with-gtk' '--exec-prefix=...''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

Bye, Reiner.

[1] If you wonder why I use a mixture of de_DE and en_US locales: I
want to display the € in plain text files in xterm, but I prefer
English program interfaces.  (Some of my systems offer
en_US.iso885915, but IIRC not all.)
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: tutorial: "The key has been rebound, but you can use instead"

[Reiner Steib]

On Tue, Nov 21 2006, Chong Yidong wrote:
> Lennart Borgman wrote:
>> Reiner Steib wrote:
[...]

> This should already be fixed in the latest CVS.

I had updated my sources less than 2 hours before my report (revision
1.6 of tutorial.el).

>>> Additionally, as the warning line is longer than 80 characters it's
>>> quite disturbing.
>
> I think [More information] can be replaced with [More].

ACK

In my current session, I get ("C-x" in red), despite that I'm not
aware of any C-x rebindings in my setup (no CUA, no viper, ...).

,
| Important note: to end the Emacs session, type C-x C-c.  (Two characters.)
| ** The key C-x has been rebound, but you can use  instead [More information] 
**
| The characters ">>" at the left margin indicate directions for you to
| try using a command.  For instance:
`

>>> BTW, if you do the same with a German language environment, the German
>>> tutorial is interrupted by lines in English.  Also the "NOTICE" is in
>>> English.  I'm not sure if these recent changes are a good idea for the
>>> non-English tutorials, given the fact that finding volunteers for the
>>> simple translation tasks listed in FOR-RELEASE (refcards, first line
>>> of the tutorial) is difficult.
>>
>> It is not good to give information in another language, but it seemed
>> better than giving no information at all.
>
> I think it's better to suppress the information if no translations can
> be found (which would be like Emacs 21, so nothing is lost).

Maybe inserting the warnings only at the top would be nicer (also in
the English version).  Maybe _not_ modifying the TUTORIAL buffer at
all, but display the warning as a splash screen before entering the
tutorial might be an improvement.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

tutorial: "The key has been rebound, but you can use instead"

[Reiner Steib]

`M-x report-emacs-bug' wrote:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

$ emacs -Q

M-: (global-set-key (kbd "ESC") 'ding) RET
 t

The tutorial says:

,
|  M-  means hold the META or EDIT or ALT key down while typing .
| If there is no META, EDIT or ALT key, instead press and release the
| ESC key and then type .  We write  for the ESC key.
| ** The key  has been rebound, but you can use  instead [More 
information] **
`

I fail to understand what "but you can use  instead" means.
Additionally, as the warning line is longer than 80 characters it's
quite disturbing.

BTW, if you do the same with a German language environment, the German
tutorial is interrupted by lines in English.  Also the "NOTICE" is in
English.  I'm not sure if these recent changes are a good idea for the
non-English tutorials, given the fact that finding volunteers for the
simple translation tasks listed in FOR-RELEASE (refcards, first line
of the tutorial) is difficult.

> In GNU Emacs 22.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3)
>  of 2006-11-21 on viandante
> X server distributor `The X.Org Foundation', version 11.0.60802000
> configured using `configure '--prefix=...' '--with-gtk' '--exec-prefix=...''

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Slow operations on buffers of tens of megabytes

[Reiner Steib]

On Thu, Nov 09 2006, Alexandre Oliva wrote:

> Ultimately, I'm a bit concerned about messing with the case table of
> an nnfolder buffer for the entire duration of the buffer.  It's hard
> to tell whether there'd be any less visible fallouts.

Richard has eliminated the peculiar upcasing dotless-i to I in CVS.
Does it fix your problem?

(IIUC, it should fix it _unless_ the user has a Turkish language
environment.  I.e. Turkish Gnus user's might still suffer from this
problem.)

,
| 2006-11-12  Richard Stallman  <[EMAIL PROTECTED]>
| 
|   * language/european.el (turkish-case-conversion-enable)
|   (turkish-case-conversion-disable): New functions.
|   ("Turkish" lang env): Use them.
| 
|   * international/characters.el (case table):
|   Do nothing special for i and I.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Slow operations on buffers of tens of megabytes

[Reiner Steib]

On Fri, Nov 10 2006, Richard Stallman wrote:

> It works in that it does speed up entering in new folders.
>
> However, it breaks mail splitting [...]
>
> That is a bad bug; was this patch installed?

No, I didn't install this patch.  I don't use the nnfolder back end of
Gnus, so I can't really test it.

However I think we must do something about this dotless-i/dotted-I
problem because it seems to render Gnus unusable with big (nnfolder)
mailbox files in Emacs 22.

As Elias Oltmanns already has pointed out, the problem is that
nnfolder often does re-searches for "X-Gnus-Article-Number: "
(`nnfolder-article-marker').  Wrapping these calls inside ...

  (with-case-table some-case-table-without-dotless-i/dotted-I
(re-search-forward nnfolder-article-marker ...))

... might be a possibility.  But there's no `with-case-table' and I
don't know enough about case table to develop a fix that doesn't break
anything else.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Slow operations on buffers of tens of megabytes

[Reiner Steib]

On Tue, Nov 07 2006, Reiner Steib wrote:

> Alexandre and Elias: Does this patch give good results?

Please consider this patch instead:

--8<---cut here---start->8---
--- nnheader.el 01 Aug 2006 12:10:19 +0200  7.24
+++ nnheader.el 08 Nov 2006 15:33:18 +0100  
@@ -997,7 +997,18 @@
 (val (symbol-value ffh)))
 (set ffh nil)
 (unwind-protect
-   (apply 'find-file-noselect args)
+   (with-current-buffer (apply 'find-file-noselect args)
+ (unless (or (featurep 'xemacs)
+ ;; Better check?
+ (< emacs-major-version 22))
+   (nnheader-message 7 "ASCII-only case-table in buffer `%s'."
+ (current-buffer))
+   ;; (sit-for 1)
+   ;; Apply ASCII-only case-table.  Don't modify the
+   ;; standard-case-table.
+   (set-case-table (make-char-table 'case-table))
+   ;; We must return the buffer:
+   (current-buffer)))
   (set ffh val
 
 (defun nnheader-directory-regular-files (dir)
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Slow operations on buffers of tens of megabytes

[Reiner Steib]

[ Cc-ing Elias Oltmanns; See
  <http://thread.gmane.org/or4ptezc71.fsf%40fsfla.org> or
  <http://thread.gmane.org/gmane.emacs.gnus.general/63925/focus=63929>
  for the full thread. ]

On Mon, Nov 06 2006, Alexandre Oliva wrote:

> On Nov  6, 2006, Reiner Steib <[EMAIL PROTECTED]> wrote:
>
>> My guess is that it's problem with case-fold-search when searching for
>> "X-Gnus-Article-Number" in mbox files in Emacs 22 as analyzed by Elias
>> Oltmanns back in June:
>
> Yep, that's it!
>
>> | --- ~/.emacs ---
>> | (unless (< emacs-major-version 22)
>> |   (set-case-syntax 331856 "w" (standard-case-table))
>> |   (set-case-syntax 331857 "w" (standard-case-table)))
>> | --- ~/.emacs ---
>
> This makes gnus blazingly fast again.
>
>> | We could also add a minor mode to set up the case table all the way
>> | for Turkish.
>> | 
>> | Would someone like to do that?
>
> I can try to take a stab at it, but not being an Emacs hacker I just
> barely understand the relationship between the reported bug and the
> ultimate cause reported in the e-mail, nevermind the proposed work
> around, that is indistinguishable from magic to me ;-)
>
> I guess this means I may need some hand-holding, and at this point I'm
> not sure that would be more work than actually making the changes.
> Please advise.

If the problem can't be solved in Emacs, we could maybe change
`nnheader-find-file-noselect' to change the case table for the mbox
files.  The current code reads:

--8<---cut here---start->8---
(defun nnheader-find-file-noselect (&rest args)
  "Open a file with some variables bound.
See `find-file-noselect' for the arguments."
  (let* ((format-alist nil)
 (auto-mode-alist (mm-auto-mode-alist))
 (default-major-mode 'fundamental-mode)
 (enable-local-variables nil)
 (after-insert-file-functions nil)
 (enable-local-eval nil)
 (coding-system-for-read nnheader-file-coding-system)
 (version-control 'never)
 (ffh (if (boundp 'find-file-hook)
  'find-file-hook
'find-file-hooks))
 (val (symbol-value ffh)))
(set ffh nil)
(unwind-protect
(apply 'find-file-noselect args)
  (set ffh val
--8<---cut here---end--->8---

I expect that (apply 'find-file-noselect args) could be changed to:

--8<---cut here---start->8---
(with-current-buffer (apply 'find-file-noselect args)
  (unless (or (featurep 'xemacs)
  ;; Better check?
  (< emacs-major-version 22))
;; Apply ASCII-only case-table. Don't modify the
;; standard-case-table.
(SOME-CASE-TABLE-CODE)))
--8<---cut here---end--->8---

I don't know much about case tables in Emacs (and I don't have time to
dig deeper into the Lisp Manual).  Any suggestion on what
SOME-CASE-TABLE-CODE should look like?  Alexandre and Elias: Does this
patch give good results?

--8<---cut here---start->8---
--- nnheader.el 01 Aug 2006 12:10:19 +0200  7.24
+++ nnheader.el 07 Nov 2006 15:08:52 +0100  
@@ -997,7 +997,13 @@
 (val (symbol-value ffh)))
 (set ffh nil)
 (unwind-protect
-   (apply 'find-file-noselect args)
+   (with-current-buffer (apply 'find-file-noselect args)
+ (unless (or (featurep 'xemacs)
+ ;; Better check?
+ (< emacs-major-version 22))
+   ;; Apply ASCII-only case-table.  Don't modify the
+   ;; standard-case-table.
+   (set-case-table (make-char-table 'case-table
   (set ffh val
 
 (defun nnheader-directory-regular-files (dir)
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Slow operations on buffers of tens of megabytes

[Reiner Steib]

On Mon, Nov 06 2006, Katsumi Yamaoka wrote:

>> In <[EMAIL PROTECTED]> Richard Stallman wrote:
>
>> Scoring of the messages closer to the beginning of the buffer is fast,
>> but as we move to higher-numbered messages, that are closer to the end
>> of such big files/buffers, gnus will only score 2-3 messages per
>> minute, and that's what kills performance.
[...]
> (setq gnus-article-button-face nil
>   gnus-signature-face nil
>   gnus-summary-selected-face nil
>   gnus-treat-highlight-citation nil
>   gnus-treat-emphasize nil)
>
> If it makes Gnus fast, improving the performance will be worth
> trying.  However, I didn't feel any difference, though it might
> be because I don't have huge mail folders.

I don't think this matches the problem description.  When scanning big
mbox files, article display isn't involved.  Or am I missing
something?

My guess is that it's problem with case-fold-search when searching for
"X-Gnus-Article-Number" in mbox files in Emacs 22 as analyzed by Elias
Oltmanns back in June:

,[ http://thread.gmane.org/gmane.emacs.devel/53901/focus=54013 ]
| From: Elias Oltmanns  uni-bonn.de>
| Subject: Re: New buffer-case-table makes search_buffer painfully slow
| Newsgroups: gmane.emacs.devel
| Date: 2006-05-06 19:10:08 GMT
| 
| Elias Oltmanns  uni-bonn.de> wrote:
| > Hi all,
| >
| > switching from emacs 21 to emacs 22 has a very significant performance
| > impact on packages that make heavy use of search_buffer. An example
| > that actually made me aware of this problem is gnus processing large
| > mbox files. Further analysis of this problem revealed that in emacs 22
| > an "i" in the search string makes search_buffer use simple_search()
| > instead of boyer_moore(). 
| 
| Emacs 22's EQUIVALENCES table relates i, and thus I as well, to two
| more characters with character codes 331857 and 331856. On
| www.unicode.org the character look up engine couldn't find a match for
| U+51051 or U+51050 saying that most likely those codes weren't
| assigned to any characters yet.
| 
| So, here is a plain question: Is there a bug in the case-table in
| emacs 22 or does the search engine on www.unicode.org for some reason
| miss certain character ranges? Slightly biassed, I'm disregarding the
| possibility of me being unable to use www.unicode.org properly, which,
| in fact, might well be the reason for my confusion.
| 
| Second question: If the case-table was right, what would be the right
| way to tacle the problem described in my original post? For me the
| following snippet in .emacs solves the problem:
| --- ~/.emacs ---
| (unless (< emacs-major-version 22)
|   (set-case-syntax 331856 "w" (standard-case-table))
|   (set-case-syntax 331857 "w" (standard-case-table)))
| --- ~/.emacs ---
| 
| This, of course, is a durty hack and I'm wondering whether emacs
| should provide a feature to "clean up" the EQUIVALENCES table in the
| ascii range in order to avoid falling back to a slow search
| algorithm when we are searching for pure ascii strings. Or do you
| think that packages like gnus which make heavy use of
| re-search-forward should handle these performance issues
| themselves---or indeed the users.
`

Alexandre, could you please try if the hack suggested by Elias makes
your problem go away?

Richard proposed a fix for this, but AFAICS, this has not been
implemented:

,[ http://thread.gmane.org/gmane.emacs.devel/53901/focus=54025 ]
| From: Richard Stallman  gnu.org>
| Subject: Re: New buffer-case-table makes search_buffer painfully slow
| Newsgroups: gmane.emacs.devel
| Date: 2006-05-07 05:01:27 GMT
|
| I think this has to do with the special characters for Turkish,
| lower-case i without dot and upper-case I with dot.  In Turkish,
| upcasing and downcasing preserve the dot, or the absence of the dot.
| 
| I think these lines in characters.el are the cause of the problem.
| 
|   (set-downcase-syntax  ?? ?i tbl)
|   (set-upcase-syntax?I ?? tbl)
| 
| They set up only half of what Turkish needs.
| They make dotless-i upcase into I, and they make
| I-with-dot downcase into i.  They can't do vice versa
| because that would break things for other languages.
| So they are not really useful.  We could simply delete them.
| 
| We could also add a minor mode to set up the case table all the way
| for Turkish.
| 
| Would someone like to do that?
`

Looking at the ChangeLog, it seems that the relevant code in
`characters.el' ...

,[ international/characters.el ]
| ;; In some languages, U+0049 LATIN CAPITAL LETTER I and U+0131 LATIN
| ;; SMALL LETTER DOTLESS I make a case pair, and so do U+0130 LATIN
| ;; CAPITAL LETTER I WITH DOT ABOVE and U+0069 LATIN SMALL LETTER I.
| ;; Thus we have to check language-environment to handle casing
| ;; correctly.  Currently only I<->i is available.
| [...] 
|   (set-downcase-syntax  ?İ ?i tbl)
|   (set-upcase-syntax?I ?ı tbl)
`

... has been changed back and forth several times:

,[ ChangeLog ]
| 2005-04-

Re: `gnus-summary-show-article' with prefix arg don't refresh the mode line

[Reiner Steib]

[ Adding [EMAIL PROTECTED] ]

On Tue, Oct 24 2006, Zhang Wei wrote:

> (setq gnus-summary-show-article-charset-alist
>   '((1 . utf-8)
> (2 . big5)
> (3 . gbk)
> (4 . utf-7)))
>
> When I say `1 g' `2 g' etc. to force gnus redisplay the article in
> specified charset, the article's subject displayed on the mode line
> don't refresh, but if I say `2 g'--for example--twice, the mode line
> got refreshed the second time.

I can confirm this.  But I don't know how and where we need to force
an update of the article buffer mode line.

Where: gnus-summary-show-article, gnus-summary-select-article,
   gnus-summary-display-article?

> And I found out if I say `1 g' `2 g' `3 g' `4 g' successively, every
> time the `subject' display on the mode line is the `subject' that was
> decoded last time.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: symbol-at-point

[Reiner Steib]

On Tue, Oct 24 2006, martin rudalics wrote:

> FWIW, the `intern' call has been inserted around July/August 2006 but I
> couldn't find a suitable ChangeLog entry.  Stefan did you write that?

M-x vc-annotate RET says:

1.20 (fx   02-Feb-00): ;;;###autoload
1.36 (monnier  04-Jul-06): (defun symbol-at-point ()
1.36 (monnier  04-Jul-06):   (let ((thing (thing-at-point 'symbol)))
1.36 (monnier  04-Jul-06): (if thing (intern thing
1.20 (fx   02-Feb-00): ;;;###autoload

and `L' prints the same entry as in lisp/ChangeLog:

,[ lisp/ChangeLog ]
| 2006-07-04  Stefan Monnier  <[EMAIL PROTECTED]>
| 
|   * thingatpt.el (symbol-at-point): Don't use `form-at-point' which
|   fails if the symbol contains chars like ( or '.
|   (bounds-of-thing-at-point): Remove unused vars `end' and `beg'.
|   (thing-at-point-bounds-of-url-at-point): Remove unused vars `url' and
|   `short'.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: `.newsrc.eld' saves chinese group name in wrong coding

[Reiner Steib]

On Thu, Oct 19 2006, Katsumi Yamaoka wrote:

> Gnus uses utf-8 encoded non-ASCII group names internally, those
> encoded names are saved in the .newsrc.eld file, and they are
> decoded by utf-8 when displaying.  I had no problem when I once
> tried nnrss groups with Japanese names.  So, I cannot imagine
> what is happening with Zhang Wei, sorry.
[...]
> (push '("\\`nndoc\\(?:\\+[^:]+\\)?:")
>   gnus-group-name-charset-group-alist)
>
> In addition, just now I noticed it is insufficient to solve the
> problem.  Maybe we need to do the fix here and there in Gnus to
> enable it to work with non-ASCII nndoc group names.

The default value of `gnus-group-name-charset-group-alist' is ((".*"
. utf-8)), so it should cover all groups, IIUC.  Or am I
misunderstanding the issue?

Why is setting it to nil for nndoc necessary?  Is nndoc handled
differently than other backends?

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

emacs-unicode-2: cpNNN and ibmNNN coding systems

[Reiner Steib]

Hi,

in emacs-unicode-2, the coding systems ibm437 and cp437 are aliases:

,[ M-x describe-coding-system RET ibm437 RET ]
| D -- ibm437 (alias of cp437)
| 
| DOS codepage 437
| Type: charset (charset)
| EOL type: Automatic selection from:
|   [cp437-unix cp437-dos cp437-mac]
| This coding system encodes the following charsets:
|   cp437
`

However, according to
, there
are minor (?) differences between the Microsoft and IBM mappings:

,[  ]
| Code Pages 00437 (US etc.)
|00860 (Portugal)
|00861 (Iceland)
|00862 (Israel)
|00863 (Canadian French)
|00865 (Nordic)
| 
|   Microsoft IBM
|   -   -
| 0x1A  U001A   U001C
| 0x1C  U001C   U007F
| 0x7F  U007F   U001A
| 0xE6  U00B5 (MICRO SIGN)  U03BC (GREEK SMALL LETTER MU)
| 
| The "rotation" of the control characters at 0x1A, 0x1C and
| 0x7F is due to the frequent use of 0x1A as end-of-file by
| PC file systems and applications.
`

I don't know if these and the differences in other code pages
mentioned there are worth to make different coding systems instead of
aliases.

If not, would it make sense to add aliases for ibmNNN in the trunk as
well?

[ Background: Today there was a posting with "charset=IBM437" in
  de.comp.text.tex ().  I thought
  of adding an alias (ibm437 . cp437) in `mm-charset-synonym-alist'
  (Gnus), but I wasn't sure if it's correct. ]

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Useless Local Variable in etc/grep.txt

[Reiner Steib]

On Sun, Oct 08 2006, Richard Stallman wrote:

> Independent of etc/grep.txt, I'd suggest to add `buffer-read-only' to
> the list of safe local variables:
>
> Please install that change.

Done.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Useless Local Variable in etc/grep.txt

[Reiner Steib]

On Sat, Oct 07 2006, Sven Joachim wrote:

> When visiting etc/grep.txt, I was asked about the variable
> buffer-read-only.

Independent of etc/grep.txt, I'd suggest to add `buffer-read-only' to
the list of safe local variables:

--8<---cut here---start->8---
--- files.el02 Oct 2006 10:24:22 +0200  1.859
+++ files.el07 Oct 2006 12:43:53 +0200  
@@ -2397,10 +2397,10 @@
 ;;
 ;; For variables defined in the C source code the declaration should go here:
 
-;; FIXME: Some variables should be moved according to the rules above.
 (mapc (lambda (pair)
(put (car pair) 'safe-local-variable (cdr pair)))
-  '((fill-column . integerp) ;; C source code
+  '((buffer-read-only. booleanp) ;; C source code
+   (fill-column . integerp) ;; C source code
(indent-tabs-mode. booleanp) ;; C source code
(left-margin . integerp) ;; C source code
(no-update-autoloads . booleanp)
--8<---cut here---end--->8---

> Although I answered 'n', the buffer was made read-only anyway, so
> the local variable seems superfluous.

grep-mode makes the buffer read-only, so we can remove it, AFAICS.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Tue, Oct 03 2006, Kenichi Handa wrote:

> In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>> > I don't think it uncommon.  People migrate from Windows to GNU/Linux
>> > (or switch between both), people exchange files with Windows users,
>> > ... (and on Windows, it's quite common to insert `smart quotes' and
>> > other non-Latin-1 characters).
>
>> True, but in my experience plain-text files using windows-1252 are still
>> rather uncommon under GNU/Linux.

Richard wrote:

,[ http://mid.gmane.org/[EMAIL PROTECTED] ]
| I agree with those that say editing Windows text files is more common
| than editing binary files with Emacs -- even on GNU/Linux.
`

>> Of course, it depends on the specifics, but adapting Emacs to the
>> specific circumstance should be done via the .emacs, I think.

BTW, I didn't get any answer to my question
:

,[  ]
| What would be the best way to do this in ~/.emacs?  Like this?
| 
| (prefer-coding-system 'windows-1252) ;; Prefer windows-1252, but...
| (prefer-coding-system 'iso-8859-1) ;; ... give Latin-1 a higher priority.
`

> What is the conclusion on this matter?  As I don't know the
> current situation about the usage of windows-1252, I have no
> idea.
>
> (1) Keep the curren code.

(5) If we decide to keep it, we should probably also add windows-1254
which is a superset of iso-8859-9 (Turkish) and windows-1255 which
is a superset of iso-8859-8 (Hebrew) accordingly.  (I don't know
if the situation is comparable to Latin-1/windows-1252.)

> (2) Cancel the change for windows-1252.
> (3) Cancel the change for windows-1252, and implement the \0
> byte detection now (before the release).

This approach (with "Cancel the change for windows-1252") won't fix
the original problem.

> (4) what else?

I did some tests with (see attached auto-coding.tar.gz)...

(a) a file containing only windows-1252 characters,

(b) a file with some Latin-1 text plus "reserved characters"
(i.e. chars not defined in windows-1252),

(c) a file with some Latin-1 and windows-1252 text plus a null-byte.

Emacs detected the files as:

(a) windows-1252 (-> correct)

(b) raw-text-unix (-> correct)

(c) windows-1252 (-> slightly incorrect, at least for people who argue
that binary is better here)

If null-byte detection is easy to implement, I'd suggest:

(6) Implement null-byte detection (to prevent binary files
   mis-detected as windows-12xx), keep the current code (windows-1252)
   and add windows-1254/1255 accordingly.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


auto-coding.tar.gz
Description: GNU Zip compressed data
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: gnus-registry.el on emacs-unicode-2 (Emacs 23)

[Reiner Steib]

On Thu, Sep 28 2006, CHENG Gao wrote:

[ ... in an unrelated thread: 
  .
  No trimming any quotes. ]

> I trust Gnus hashtb<->alist conversion functions have no problem.

Yes, my article on this was unrelated to your problem.

> I suspected function gnus-gnus-to-quick-newsrc-format is the culprit.
>
> As Handa said, # (blah blah ...) is representation of string with text
> properties.
> I had a test by removing all # and leave "0 40 (auto-composed nil)", and
> gnus registry works.
>
> In gnus-start.el function gnus-gnus-to-quick-newsrc-format line 2841
> ,
> |(print-readably t)
> `
> I juct checked. At least in my Emacs 23 (06-9-15 cvs), 

Could you please try if the problem also exists in Emacs 22 (trunk)?
As I understand from the previous messages, it only exists in
emacs-unicode-2 (Emacs 23).  Is this correct?  Then I could remove it
from the list of release-relevant bugs for Emacs 22
(admin/FOR-RELEASE).

> variable print-readably does not exist.

It exist in XEmacs; If it doesn't exist in Emacs, it is simply
ignored.  No problem.

I don't know about the rest of your questions:

> I nearly damaged my brain by reading code of prin1/princ/print.
>
> At last I think gnus-gnus-to-quick-newsrc-format should be ok. It does
> what it should do, even the result is bad.
>
> A silly question: 
> If an entry in gnus-reristry-alist carries text-property, prin1 will
> print it as string and use # as quoting character. Is it right?
>
> If so, I think we need check all puthash (to gnus-registry-hashtb) in
> gnus-registry.el for unremoved text property.
>
> My knowledge is not adquate for real useful finding. Wish what I found
> can be a little useful to you.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control

[Reiner Steib]

On Thu, Sep 28 2006, Miles Bader wrote:

> ./git_xorg.sh > file 1>&2

  ./git_xorg.sh > file 2>&1

> In case it's writing that stuff to stderr.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

gnus-registry.el on emacs-unicode-2 (Emacs 23) (was: [bug]Malformed -*- line)

[Reiner Steib]

On Wed, Sep 27 2006, CHENG Gao wrote:

> I tried twice to report the problem to gmail.emacs.gnus.general and
> failed.

I think you mean gmane.emacs.gnus.general (aka <[EMAIL PROTECTED]>).  Did
you reply to Gmane's confirmation request?  See
.

Then, the message might also be in the moderator's queue.

> It does not matter. I turned registry off. I can live with it.

Please report the problem on the Gnus list.  I don't know to which
part of the code you refer to here:

,
| (set-text-properties (point-min) (point-max) nil)
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: refcards

[Reiner Steib]

On Tue, Sep 26 2006, Andreas Roehler wrote:

> As it concerns refcard.ps - not de-refcard -, the date above is not
> indeed helpful.

Ah, I missed that you talked about both, de-refcard.ps and refcard.ps.
I've checked in a regenerated refcard.ps now.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: refcards

[Reiner Steib]

On Tue, Sep 26 2006, Andreas Roehler wrote:

>>> gv refcard.ps &
>>> still explains Emacs version 21
>>> 
>>
>> Then your Emacs checkout must be older than 2006-06-28:
>>
>>   
>
> ls -l  ...  2006-06-28 15:26 de-refcard.ps
>
> checked out today.


... starts with "Referenzkarte zu GNU Emacs [...]  Um GNU Emacs 22 zu
starten, [...]".  I don't see anything wrong there.

Please elaborate _where_ exactly it "still explains Emacs version 21".

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: refcards

[Reiner Steib]

On Tue, Sep 26 2006, Andreas Roehler wrote:

> gv de-refcard.ps &
>
> shows the document bottom-up. Is there a reason for
> this?

Probably because gv and dvips have different opinions about
"landscape" and "seascape".  dvips only offers rotating by 90 degrees
("-t landscape").

> gv refcard.ps &
>
> still explains Emacs version 21

Then your Emacs checkout must be older than 2006-06-28:

2006-06-28  Reiner Steib  <[EMAIL PROTECTED]>

* Makefile: Add rules for refcards.

* de-refcard.ps, fr-refcard.ps, pt-br-refcard.ps: Regenerate.
[...]
2006-06-04  Sven Joachim  <[EMAIL PROTECTED]>

* de-refcard.tex: Update for Emacs 22: Use German quotes
and umlauts; fix overfull /hboxes; many rewordings.

> Refcard utility itself seems not very present, which is considered a
> pity.
>
>  `M-x apropos refcard' doesn't know about it. Couldn't
>  find an info-node either. Also the tutorial doesn't
>  mention it.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Sat, Sep 23 2006, Eli Zaretskii wrote:

>> From: Reiner Steib <[EMAIL PROTECTED]>
[...]
>> What is the benefit to treat it as raw-text instead of window-1252
>> assuming that the file only contains characters from window-1252?  We
>> are taking about a file (> 30 chars of text) with mostly ASCII,
>
> You are clearly thinking about text files.  

Yes.  And I think that most users do so.  probably they aren't even
aware that Emacs might be useful for editing binary files.  The
reaction of most users seeing \202 etc. when opening such files will
just be that Emacs is broken.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Sat, Sep 23 2006, Jason Rumney wrote:

> Kenichi Handa wrote:
>> At least windows-1252 doesn't cover all eight-bit bytes.
>> There are a few invalid bytes: 0x81, 0x8c, 0x8e...
>>   
> 0x8c is "Latin capital ligature Oe", and 0x8e is "Latin capital letter Z with
> caron" according to Windows XP character map. 0x8d is missing, as is 0x90
> (nbsp in latin-1). I'm not sure if the latter is just filtered out from
> display in character map though (0x20 space is also not displayed).

NO-BREAK SPACE is A0 in both, Latin-1 and windows-1252 (all characters
present in Latin-1 are also in windows-1252 at the same position;
i.e. windows-1252 is a superset of Latin-1).

,[ http://en.wikipedia.org/wiki/Windows-1252 ]
| According to the information on Microsoft's and the Unicode
| Consortium's websites positions 81, 8D, 8F, 90, and 9D are
| unused. However the Windows API call for converting from code pages
| to Unicode maps these to the corresponding C1 control codes. The
| euro character at position 80 was not present in earlier versions of
| this code page, nor were the S and Z with caron (háček)
`

While I don't know if these five positions (81, 8D, 8F, 90, and 9D)
are sufficient to distinguish raw-text from windows-1252, together
with Eli's suggestion (detect null bytes) it might give good results.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Sat, Sep 23 2006, Stefan Monnier wrote:

> Of course, it depends on the specifics, but adapting Emacs to the
> specific circumstance should be done via the .emacs, I think.

What would be the best way to do this in ~/.emacs?  Like this?

(prefer-coding-system 'windows-1252) ;; Prefer windows-1252, but...
(prefer-coding-system 'iso-8859-1) ;; ... give Latin-1 a higher priority.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Fri, Sep 22 2006, Stefan Monnier wrote:

> Clearly, the issue is not latin-1 vs windows-1252, but windows-1252 vs
> raw-text.

It wasn't clear to me. ;-)

> Maybe there won't be any harm to always use windows-1252 rather than
> raw-text, but I'm not convinced, especially given the fact that in
> a GNU/Linux environment files in windows-1252 encoding are rather uncommon
> (email messages are another matter).

I don't think it uncommon.  People migrate from Windows to GNU/Linux
(or switch between both), people exchange files with Windows users,
... (and on Windows, it's quite common to insert `smart quotes' and
other non-Latin-1 characters).

> So I'd rather have a tool that explains what's going on, so that the user
> can decide to use window-1252 if it's a good choice for her, rather than
> force windows-1252 on all users most of whom won't ever edit a file with
> window-1252 encoding.

What is the benefit to treat it as raw-text instead of window-1252
assuming that the file only contains characters from window-1252?  We
are taking about a file (> 30 chars of text) with mostly ASCII,
some Latin-1 [ÄÖÜäöüß] (1.3%, probably typical for a German text), and
19 \202 characters (= 0.005%).

(I don't know if Emacs really checks the frequency of such characters
to decide about the coding.)

> PS: My remarks obviously assume a GNU/Linux environment.  Under w32, it
> probably makes sense to place window-125x in the preferred coding systems,
> just like it makes sense to put mac-roman under macosx.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Fri, Sep 22 2006, Stefan Monnier wrote:

> I'm not sure this is right, because windows-1252 covers basically all bytes,
> so there's no way to find out that a file is not in windows-1252.

As Latin-1 (still) has a higher priority than windows-1252 (at least
that's my understanding), windows-1252 will not be used unless there a
bytes from the region x80-x9f.  (windows-1252 is a superset of Latin-1.
They differ only this region, which is not used in Latin-1.)

> It's not terrible, but it means that this change is not completely
> harmless.  Now, given the fact that this problem is rare I'm not
> sure it's worth the risk.

Could elaborate on this risky scenario or prepare a test file?

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Thu, Sep 20 2006, Andreas Roehler wrote:

> Little correction, concerning last mail to Reiner Steib:
>
> Phenomen is gone if I
>
> - mark and delete a portion from the beginning of the buffer
> - mark and delete a portion from the end of the buffer
>
> - save and reopen;
>
> also - as reported - its gone, if I mark and copy the
> buffer into a new one.

Probably you didn't include the problematic char in this situations.

> Plain opening, reopening, delete something without
> mark-region doesn't change it.
>
>> Please try to visit that file by:
>>   C-x RET c iso-8859-1 RET C-x C-f FILENAME
>>   
>
> I get
>
> `jÃ1/4ngsten' instead of `jüngsten'
>
> `Ãsterreich' instead of `Österreich'

I suppose this was _after_ converting the file to UTF-8.

> Saving with
>
>>   C-x RET f utf-8 RET C-x C-s
>
> can't help here.

Please try again with Handa-san's changes to `language/european.el'.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Wed, Sep 20 2006, Andreas Roehler wrote:

> Also it seems to affect just one file in this
> directory.
>
> What makes it difficult to reproduce: it happens only
> just after opening. After a save, it reopens correct.
>
> Wll send you an example off-list.

I think I can reproduce your problem with just line 3891 of this file.

FYI: I tried to isolate the problematic characters by dividing the
file in two parts with approximately equal number of lines [1]
("Intervallhalbierungsverfahren" in German, I forgot the English
term).

You can even replace all characters by x in that line:

$ a=3891;e=3891; sed -ne "${a},${e}p" < roe.txt | tr '[a-z]' 'x' > problem.txt

Here is it (\202 is one char, of course; see attached problem.txt.gz):

,[ problem.txt ]
| Nxxx, xxx xxx xx \202xx M' xx x, xxx xxx x Dxx xx
`

The character \202 is from windows-1252:

,
| ‚ U+201A : SINGLE LOW-9 QUOTATION MARK
`

I can display it correctly using
  `C-x C-m c windows-1252 RET C-x C-f problem.txt RET'
but *not* with
  `C-x C-f problem.txt RET C-x C-m r windows-1252 RET'.

I think this is a bug, but surely Handa-san give you more accurate
information.

WRT auto-detection: Wouldn't it be possible to give windows-1252 a
higher priority than raw-text (in the default settings!)?

BTW, the sample file displays correctly if I only delete line 3891,
i.e. the only problem is \202.

$ a=3891;e=3891; sed -e "${a},${e}d" < roe.txt > skip-line-$a-$e.txt

Bye, Reiner.

[1] I used sed for this:

$ wc -l roe.txt 
6649 roe.txt
$ a=1;e=3000; sed -ne "${a},${e}p" < roe.txt > line-$a-$e.txt

[ Open in emacs, see if it fails => no => problem must be in the next part ]

$ a=3000;e=6649; sed -ne "${a},${e}p" < roe.txt > line-$a-$e.txt

[ Open in emacs, see if it fails => yes => problem must be in this
  part; Divide this part ...]

$ a=3000;e=5500; sed -ne "${a},${e}p" < roe.txt > line-$a-$e.txt

[...] Until you reach...

$ a=3891;e=3891; sed -ne "${a},${e}p" < roe.txt > line-$a-$e.txt
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


problem.txt.gz
Description: GNU Zip compressed data
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Wed, Sep 20 2006, Kenichi Handa wrote:

> Reiner Steib <[EMAIL PROTECTED]> writes:
>> On Wed, Sep 20 2006, Andreas Roehler wrote:
>> > ... Its value is raw-text-unix
>
> That means that Emacs couldn't detect a correct encoding of
> that file.  It seems that the file is encoded in iso-8859-1,
> but the encoding suggested by your locale is different.

Using his locale (LANG=de_DE.UTF-8; no other LC_* variables set), I
get with emacs -Q:

,
| coding-category-list is a variable defined in `C source code'.
| Its value is 
| (coding-category-utf-8 coding-category-iso-8-1 coding-category-iso-8-2
| coding-category-utf-16-be coding-category-utf-16-le
| coding-category-iso-7-tight coding-category-iso-7
| coding-category-iso-7-else coding-category-iso-8-else
| coding-category-emacs-mule coding-category-raw-text
| coding-category-sjis coding-category-big5 coding-category-ccl
| coding-category-binary)
| 
| Documentation:
| List of coding-categories (symbols) ordered by priority.
`

So Emacs should find out automatically that the content is not (valid)
utf-8 and fall back to iso-8-1 e.g. iso-8859-1.  Or am I missing
something?  (Is `coding-category-list' the right variable to check the
priority?)

> Please try to visit that file by:
>   C-x RET c iso-8859-1 RET C-x C-f FILENAME
>
> If you want to save that file in UTF-8, do this:
>   C-x RET f utf-8 RET C-x C-s

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: local chars displayed as numbers

[Reiner Steib]

On Wed, Sep 20 2006, Andreas Roehler wrote:

> Emacs -q
>
> When opening files written with previous Emacs
> versions, several chars - German Umlaute and also `-'

This is an ASCII HYPHEN-MINUS (U+002D), probably you mean EN DASH
(U+2013) or EM DASH (U+2014).

> for example - are displayed as numbers, not as symbol.
>
> So `Straße' is shown as `Stra\337e'
>
> C-x =
>
> at point gives the correct result and also shows the
> symbol:
>
> ->
> Char: ß (223, #o337, #xdf, file #xDF) point=395 of 2660 (15%) column=13

(Would `C-u C-x =' (M-x describe-char RET) give more useful
information in this case?)

> C-h v buffer-file-coding-system
> ->
> ... Its value is raw-text-unix

Didn't you say in de.comp.editoren (the thread following
) that you cannot reproduce this problem
anymore?  (I couldn't reproduce it with "LC_CTYPE=de_DE.utf8 emacs
-Q"[1]).  Can you reproduce it starting from "emacs -Q"?  Maybe it
helps if you send us a small gzipped test file.

[...]
>  value of $LANG: de_DE.UTF-8
>  locale-coding-system: utf-8
>  default-enable-multibyte-characters: t

Bye, Reiner.

[1]
$ echo Straße > /tmp/strasse.txt
$ LC_CTYPE=de_DE.utf8 em -Q /tmp/strasse.txt

See attached file:


strasse.txt.gz
Description: GNU Zip compressed data
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: emacs-lisp/cl.el (pushnew): void-variable x

[Reiner Steib]

On Mon, Sep 11 2006, Kim F. Storm wrote:

> Reiner Steib <[EMAIL PROTECTED]> writes:
>> Is this change correct?
>>
>> --8<---cut here---start->8---
>> --- cl.el11 Sep 2006 11:50:52 +0200  1.49
>> +++ cl.el11 Sep 2006 12:32:09 +0200  
>> @@ -160,7 +160,7 @@
>>(if (symbolp place)
>>(if (null keys)
>>`(let ((pushnew-internal ,place))
>> - (add-to-list 'pushnew-internal x nil 'eql)
>> + (add-to-list 'pushnew-internal ,x nil 'eql)
>>   (setq ,place pushnew-internal))
>>  (list 'setq place (list* 'adjoin x place keys)))
>>  (list* 'callf2 'adjoin x place keys)))
>> --8<---cut here---end--->8---
>
> Yes it seems correct.

I have installed it.

> But what's the wisdom behind pushnew-internal [we already know that
> PLACE is a symbol]?

I don't know.

> If it is aimed at handling the situation where PLACE is not bound on
> entry, the let binding to pushnew-internal will also fail AFAICS.
>
> This looks equivalent to me: [...]

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

emacs-lisp/cl.el (pushnew): void-variable x

[Reiner Steib]

M-x report-emacs-bug writes:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

Create a file "/tmp/pushnew-debug.el" with this lines:

--8<---cut here---start->8---
(setq debug-on-error t)
(require 'cl)
(defvar rs-tmp nil)
(pushnew 'foo rs-tmp)
--8<---cut here---end--->8---

With "emacs -Q /tmp/pushnew-debug.el", I get the following backtrace:

--8<---cut here---start->8---
Debugger entered--Lisp error: (void-variable x)
  (add-to-list (quote pushnew-internal) x nil (quote eql))
  (let ((pushnew-internal rs-tmp)) (add-to-list (quote pushnew-internal) x nil 
(quote eql)) (setq rs-tmp pushnew-internal))
  (pushnew (quote foo) rs-tmp)
  eval-buffer(# nil "/tmp/pushnew-debug.el" nil t)  ; Reading 
at buffer position 80
  load-with-code-conversion("/tmp/pushnew-debug.el" "/tmp/pushnew-debug.el" nil 
t)
  load("/tmp/pushnew-debug.el" nil t)
  command-line-1(("-l" "pushnew-debug.el"))
  command-line()
  normal-top-level()
--8<---cut here---end--->8---

> In GNU Emacs 22.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-09-11 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' 
> '--exec-prefix=/import/xtra/emacs/HEAD-x86_64' 
> 'CFLAGS=-DSITELOAD_PURESIZE_EXTRA=20 -g''

I have removed all *.elc files and did "make bootstrap".

Reverting Richard's last change to cl.el[1] fixed the problem.  The
following change seems to fix it.  Is this change correct?

--8<---cut here---start->8---
--- cl.el   11 Sep 2006 11:50:52 +0200  1.49
+++ cl.el   11 Sep 2006 12:32:09 +0200  
@@ -160,7 +160,7 @@
   (if (symbolp place)
   (if (null keys)
  `(let ((pushnew-internal ,place))
-(add-to-list 'pushnew-internal x nil 'eql)
+(add-to-list 'pushnew-internal ,x nil 'eql)
 (setq ,place pushnew-internal))
(list 'setq place (list* 'adjoin x place keys)))
 (list* 'callf2 'adjoin x place keys)))
--8<---cut here---end--->8---

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

> Major mode: Emacs-Lisp

> Minor modes in effect:
>   tooltip-mode: t
>   tool-bar-mode: t
>   mouse-wheel-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   line-number-mode: t

> Recent input:
>  
> 
>  M-x r e p o  r  

> Recent messages:
> (emacs -q -no-site-file pushnew-debug.el -l pushnew-debug.el)
> For information about the GNU Project and its goals, type C-h C-p.
> Loading debug...done
> Entering debugger...
> Loading help-mode...done
> Making completion list...
> Loading emacsbug...
> Loading regexp-opt...done
> Loading emacsbug...done

Bye, Reiner.

[1]
2006-09-10  Richard Stallman  <[EMAIL PROTECTED]>

[...]
* emacs-lisp/cl.el (pushnew): Use add-to-list when convenient.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: font-lock confused in sh-script-mode

[Reiner Steib]

On Tue, Aug 08 2006, Stefan Monnier wrote:

> I believe this is now fixed,

Yes, thanks.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: font-lock confused in sh-script-mode

[Reiner Steib]

On Thu, Jul 27 2006, Reiner Steib wrote:

> On Wed, Jul 26 2006, Reiner Steib wrote:
>
>> It seems like the unbalanced backquote in the comment «# force `ro» in
>> combination with the two «echo "... \\"» confused font-lock.
>
> Another example:

And yet another...



sh-font-lock-10.png
Description: PNG image
function abbrev2newsgroup
{
# eval grep -e `echo "$i"|sed -e 's|.|&[^.]*.|g;s|^|^|'` 
/var/spool/news/leaf.node/groupinfo
eval grep -e "`echo "$@"|sed -e 's|.|&[^.]*[.]|g;s|^|^|'`" 
/var/spool/news/leaf.node/groupinfo
}

function cd_newsgroup
{
eval cd /var/spool/news/"$(echo "$@"|tr . /)"
}

In all three example, the commented line was *not* completely ignored
for the fontification of the rest of the buffer.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: font-lock confused in sh-script-mode

[Reiner Steib]

On Wed, Jul 26 2006, Reiner Steib wrote:

> It seems like the unbalanced backquote in the comment «# force `ro» in
> combination with the two «echo "... \\"» confused font-lock.

Another example:

--8<---cut here---start->8---
#!/bin/sh
echo 'Running  $Id: quotas.sh,v 1.16 2006/01/03 14:17:31 ste Exp $'

allusers=`
ypcat passwd | awk -F: '{ if ($3 > 99) printf ("%10s %30s %14s\n", $1, $6, 
$7);}' |
while read user home shell; do
  if [ -d "$home" -a -x "$shell" -a "$shell" != /bin/false ]; then
echo "$user "
  fi
done
`

dev_home=/dev/data/home
dev_Disks=/dev/data/scratch
dev_mail=/dev/data/mail

  q_huge="50  70 $inodes  $dev_home"
 q_large="25  50 $inodes  $dev_home"
q_medium="10  20 $inodes  $dev_home"
 q_guest=" 5  10 $inodes  $dev_home"

exit 0
--8<---cut here---end--->8---

The line «q_guest=...» is not fontified like the three preceding
similar lines (the whole "..." expression is in
`font-lock-string-face').  See this screen shot:




Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: font-lock confused in sh-script-mode

[Reiner Steib]

On Wed, Jul 26 2006, Stefan Monnier wrote:

>> The buffer is font-locked incorrectly, see the attached screen shot:
> [...]
>> It seems like the unbalanced backquote in the comment «# force `ro» in
>> combination with the two «echo "... \\"» confused font-lock.
>
> I don't see anything wrong in the screen shot.

Sorry, for some reason this screen shot didn't show the problem.
Here's a new one:



Everything between \\" and \\" is displayed as a string
(`font-lock-string-face').  The string in «echo "#"» also is not
correct: «"#"» should be `font-lock-string-face', but the first «"» is
in default face and «#"» is in `font-lock-comment-face'.

After closing the backquote in the comment «# force `ro`», everything
is okay, AFAICS.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

font-lock confused in sh-script-mode

[Reiner Steib]

M-x report-emacs-bug wrote:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

Open the following file in emacs (emacs -Q sh-bogus-comment.sh):

--8<---cut here---start->8---
#!/bin/sh

do_untrusted()
{
  : ${squash:="squash_uids=0-149"}
  for host in $pc_untrusted; do
# force `ro
echo "  $host($squash,ro,sync)\\"
  done
}

while read dev point rest; do
  case $point
  in ( /Disks/var )
echo "$point \\"
rw_ro=rw do_hostlist
echo
echo "#"
  ;; ( * )
:
  esac
done < /etc/fstab
--8<---cut here---end--->8---

The buffer is font-locked incorrectly, see the attached screen shot:



It seems like the unbalanced backquote in the comment «# force `ro» in
combination with the two «echo "... \\"» confused font-lock.

> In GNU Emacs 22.0.50.11 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-07-26 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' 
> '--exec-prefix=/import/xtra/emacs/HEAD-x86_64''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

> Major mode: Shell-script

> Minor modes in effect:
>   tooltip-mode: t
>   tool-bar-mode: t
>   mouse-wheel-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   line-number-mode: t

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: (eval-after-load "info" ..) triggers on loading anything-info

[Reiner Steib]

On Sat, May 27 2006, Eli Zaretskii wrote:

>> From: Martin Schoenmakers <[EMAIL PROTECTED]>
>> Date: Thu, 25 May 2006 20:23:48 +0200
>> 
>> As of very recent CVS builds emacs mutters on startup about 'Recursive
>> `require' for feature `sb-info''. Some digging around revealed that
>> this in turn was triggered from loading emms-info.el due to an
>> (eval-after-load "info" '(require 'sb-info)). The recursive requires
>> are triggered by the same line, which lives just before the relevant
>> provide in sb-info.el.
>
> There are no files that go by these names (emms-info.el and
> sb-info.el) in the Emacs CVS.  So I think you need to talk to whoever
> wrote those two files.

No, the recent changes to `eval-after-load' lead to such kind of
problems whenever you write...

  (eval-after-load "bar" '(add-to-list 'bar-variable 'baz))

... and some (other) file provides `foo-bar'.  `add-to-list' is evaled
after `foo-bar' is provided; _not_ after `bar' is provided.  Thus
you'll get "variable is void: bar-variable".

See the recent reports by Katsumi Yamaoka (`w3m' vs `mime-w3m'[1]),
Romain Francoise (`ibuffer' vs. `this-is-not-ibuffer.el') [2] and me
(`tex' vs. `rs-tex') [3].

Bye, Reiner.

Footnotes: 
[1]  http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-05/msg00304.html
 http://mid.gmane.org/b4mhd3delpi.fsf%40jpl.org
 (on emacs-pretest-bug)

[2]  http://mid.gmane.org/873beywfew.fsf%40pacem.orebokech.com
 (on emacs-devel)

[3]  http://mid.gmane.org/v9lksodaft.fsf%40marauder.physik.uni-ulm.de
 (on emacs-devel)
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Mon, May 15 2006, Ken Manheimer wrote:

> the versions attached to this message correct that.

Installed.  Thanks.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Mon, May 15 2006, Ken Manheimer wrote:

> in light of these new realizations, i'm attaching a new allout patch
> and changelog.  reiner, i really like the compromise of using the
> simple predicates for safe-local-variable property qualifiers, when
> available, and falling back to the lambdas when they're not.  this
> patch includes changes that do that, and also has yet another minor
> allout fix.

Could you please send a ChangeLog entry that only considers these
changes?

As the lisp files are synced between different CVS branches, including
CVS keywords is problematic (often leads to conflicts).  Can we skip
the hunk introducing "$Revision: ... $"?

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Sun, May 14 2006, Johan Bockgård wrote:

> Reiner Steib <[EMAIL PROTECTED]> writes:
>
>> Emacs 21 doesn't look at the safe-local-variable property at all.
>
> It does.

Thanks for the correction.  If `allout.el' wants to be compatible with
Emacs 21, also `string-or-null-p' shouldn't be used.

Or `booleanp' and `string-or-null-p' might be conditionally, e.g.:

(put 'TeX-PDF-mode 'safe-local-variable (if (fboundp 'booleanp)
'booleanp
  '(lambda (x) (memq x '(nil t)

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Fri, May 12 2006, Ken Manheimer wrote:

> On 5/12/06, Reiner Steib <[EMAIL PROTECTED]> wrote:
[...]
> the lambdas are quoted, so they ought to show as text.  (they do for me.)

Sorry, my bad.

>> But here, I still don't think it makes much sense to provide backward
>> compatibility for older CVS Emacs versions.  Not using `booleanp'
>> makes the code and the output of `describe-variable' harder to read.
>
> i don't understand.  older emacs 22 CVS versions are not my concern -
> emacs 21 and earlier lack booleanp.

Emacs 21 doesn't look at the safe-local-variable property at all.  In
Emacs 21 there was the concept of risky-local-variable.  All variables
not marked as risky were considered safe (please CMIIW).  E.g. we had:
  (put 'mailcap-mime-data 'risky-local-variable t)
If `booleanp' is a problem in Emacs 21, `string-or-null-p' also would
be a problem.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Fri, May 12 2006, Ken Manheimer wrote:

> i've attached a patch (allout-patch.txt), ChangeLog
> (allout-ChangeLog.txt), and revised NEWS fragment (allout-NEWS.txt)
> for allout that addresses the stuff we've been discussing, and a few
> other things.

Thanks, I have committed your changes.

> in the patch, any autoloaded safe-local-variables lambdas are quoted.
> the patch also incorporates some of the other refinements that were
> suggested in this discussion, though i am leaving the
> safe-local-variable property assignments as active code (rather than
> containing them in the autoload comment) 

A drawback is that user's won't see the predicate in the output of
`describe-variable':

,
| This variable is safe as a file local variable if its value
| satisfies the predicate which is byte-compiled expression.
`

> and continuing to use a lambda rather than booleanp.  both of these
> measures will make it easier to use allout in older emacs, without
> adding significant complexity.

But here, I still don't think it makes much sense to provide backward
compatibility for older CVS Emacs versions.  Not using `booleanp'
makes the code and the output of `describe-variable' harder to read.

If you can't update your CVS Emacs, you could define `booleanp' if
it's not bound.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Fri, May 12 2006, Richard Stallman wrote:

> Maybe it would be better to shift it down so that it comes _after_ the
> documentation:
>
> No, because the documentation is much longer than the safe-values
> info.  if you put a small thing after a big thing, people tend not no
> notice the small thing.

In general, I agree to this.  But in this case, IMHO it would make
sense to have it below, because without reading the documentation
which should explain the meaning of the various allowed values,
printing the safe-value information often is not very useful.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Wed, May 10 2006, Ken Manheimer wrote:

> On 5/10/06, Reiner Steib <[EMAIL PROTECTED]> wrote:
>> ;;;###autoload
>> (put 'allout-numbered-bullet 'safe-local-variable
>>  (lambda (x) (or (not x) (stringp x
>>
>> ... instead of...
>>
>> ;;;###autoload(put 'allout-numbered-bullet 'safe-local-variable (lambda (x) 
>> (or (not x) (stringp x
>>
>> ... (and similar for other many other variables) in `allout.el'.
>
> i haven't seen some of this conversation (i looked in the archive, and
> these messages aren't there yet), and i'm not clear whether something
> is being requested here.

[ The archives on gmane.org are updated as soon as the message arrives
  from the list:
  http://news.gmane.org/gmane.emacs.devel
  http://news.gmane.org/gmane.emacs.pretest.bugs ]

> i deliberately chose to use the form that defines the variables in the
> file's bytecode, as well as in loaddefs, because i want to be able to
> use the most recent version of allout in versions of emacs that are
> not built with allout (eg, the old emacs version i'm running on my
> zaurus).  i would like to be able to use the same source code in such
> cases.  (i imagine other people might be in the same situation.)

AFAICS, Emacs 21 doesn't care about the safe-local-variable properties
in the first place, so you there no need for backward compatibility
here.  (I don't think we should try to be backward compatible with
older CVS versions.)

> i don't want to make allout objectionable for distribution with emacs,
> and am willing to conform to the conventions, if necessary.  is having
> the definitions exist only in loaddefs being asked, or will it be
> enough to have the active definitions in allout as well, but quote the
> lambda expressions so they're not byte-compiled (and so don't clutter
> the help)?

For Emacs 22, Richard recommended not to execute it again when the
file is loaded, i.e. use...

;;;###autoload(put '... 'safe-local-variable ...)

See <http://thread.gmane.org/gmane.emacs.devel/52972/focus=53151>.


On Wed, May 10 2006, Ken Manheimer wrote:

> On 5/10/06, Reiner Steib <[EMAIL PROTECTED]> wrote:
>> On Wed, May 10 2006, Stefan Monnier wrote:
>>
>> [ (lambda (x) (or (not x) (stringp x))) ]
>> > Actually, we should use string-or-null-p here.
>>
>> ACK.  And (member x (quote (t nil))) should be booleanp.
>
> i can make those changes.  (booleanp must be rather new addition -
> it's not in my CVS emacs built a week and a half ago.)

Stefan installed it on 2006-04-29.

>> But there are also expressions in `allout.el' where no predefined
>> predicate exists (AFAICS):
>>
>> allout-use-mode-specific-leader

  (lambda (x) (or (member x '(t nil)) (stringp x)))

I'd rewrite this as...

  (lambda (x) (or (booleanp x) (stringp x)))

>> allout-reindent-bodies

  (lambda (x) (member x '(nil t text force)))

>> allout-layout

  (lambda (x) (or (numberp x) (listp x) (integerp x)
  (member x '(: * + -

> is it necessary to have a predefined predicate in all cases, or will
> quoting the lambda be sufficient?  i could define functions to be used
> as predicates, and have them autoloaded, but i see no particular gain
> there.

I don't think it would be useful to define functions for these
predicates.  If you put them inside the autoload comment, you don't
need to quote them.  (Of course this is only _my_ opinion; maybe you
should wait for other comments before working on it.)

For completeness, here is a list of all safe-local-variable lambda
expressions in `loaddefs.el':

(lambda (x) (member x (quote (nil t text force; allout-reindent-bodies

==> no need for a defun, but use autoload comment.

(lambda (x) (member x (quote (t nil; allout-old-style-prefixes
(lambda (x) (member x (quote (t nil; allout-show-bodies
(lambda (x) (member x (quote (t nil; allout-stylish-prefixes
(lambda (x) (member x (quote (t nil; allout-use-hanging-indents

==> booleanp

(lambda (x) (memq x '(nil t exclusive))); ispell-check-comments

==> no need for a defun

(lambda (x) (or (member x (quote (t nil))) (stringp x))); 
allout-use-mode-specific-leader

==> no need for a defun, but use autoload comment.

(lambda (x) (or (not x) (stringp x))); allout-file-xref-bullet
(lambda (x) (or (not x) (stringp x))); allout-numbered-bullet

==> string-or-null-p

(lambda (x) (or (numberp x) (listp x) (integerp x) (member x (quote (: * + 
-); allout-layout

==> no need for a defun, but use autoload comment.

(lambda (x) (or (stringp x) (symbolp x))); reftex-fref-is-default
(lambda (x) (or (stringp x) (symbolp x))); reftex-vref-

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Wed, May 10 2006, Luc Teirlinck wrote:

> I personally still believe that the best thing to do would just be to
> simply remove this annoying safe-local-variable clutter from the `C-h v'
> output entirely.

I think Richard decided to include it.

Maybe it would be better to shift it down so that it comes _after_ the
documentation:

--8<---cut here---start->8---
*** help-fns.el 11 May 2006 13:10:03 +0200  1.89
--- help-fns.el 11 May 2006 13:12:12 +0200  
***
*** 642,656 
  (princ (if (stringp (car obsolete)) (car obsolete)
   (format "use `%s' instead." (car obsolete
  (terpri))
  (when safe-var
!   (princ "This variable is safe as a file local variable ")
(princ "if its value\nsatisfies the predicate ")
(princ (if (byte-code-function-p safe-var)
!  "which is byte-compiled expression.\n"
!(format "`%s'.\n" safe-var)))
!   (terpri))
! (princ "Documentation:\n")
!   (princ (or doc "Not documented as a variable.")))
;; Make a link to customize if this variable can be customized.
(if (custom-variable-p variable)
(let ((customize-label "customize"))
--- 642,656 
  (princ (if (stringp (car obsolete)) (car obsolete)
   (format "use `%s' instead." (car obsolete
  (terpri))
+ (princ "Documentation:\n")
+   (princ (or doc "Not documented as a variable."))
  (when safe-var
!   (princ "\n\n\nThis variable is safe as a file local variable ")
(princ "if its value\nsatisfies the predicate ")
(princ (if (byte-code-function-p safe-var)
!  "which is byte-compiled expression."
!(format "`%s'." safe-var)))
!   (terpri)))
;; Make a link to customize if this variable can be customized.
(if (custom-variable-p variable)
(let ((customize-label "customize"))
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Thu, May 11 2006, Richard Stallman wrote:

> I still think we should avoid printing byte-code even in case third
> party libraries forget to quote a lambda expression.  May I install
> the following change in `describe-variable'?  
>
> Yes, that change is ok.

Installed.  I also included Luc's improvement of the (previous)
wording.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Wed, May 10 2006, Stefan Monnier wrote:

[ (lambda (x) (or (not x) (stringp x))) ]
> Actually, we should use string-or-null-p here.

ACK.  And (member x (quote (t nil))) should be booleanp.

But there are also expressions in `allout.el' where no predefined
predicate exists (AFAICS):

allout-use-mode-specific-leader
allout-reindent-bodies
allout-layout

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Wed, May 10 2006, Reiner Steib wrote:

> I still think we should avoid printing byte-code even in case third
> party libraries forget to quote a lambda expression.

I noticed that we also get byte-code for the `allout.el' variables
like `allout-numbered-bullet'.  This happens because Ken Manheimer
(cc-ed) used...

;;;###autoload
(put 'allout-numbered-bullet 'safe-local-variable
 (lambda (x) (or (not x) (stringp x

... instead of...

;;;###autoload(put 'allout-numbered-bullet 'safe-local-variable (lambda (x) (or 
(not x) (stringp x

... (and similar for other many other variables) in `allout.el'.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Wed, May 10 2006, Richard Stallman wrote:

> The predicate is a lambda expression which was bytecomplied [I'm not
> sure if this is what you asked for].  I gave a recipe to reproduce in
> my first mail.  FWIW, if I quote[1] the lambda expression in my
> recipe, I get the expected result:
>
> In that case, I think the fix is just to quote it.
> Is there any reason NOT to do that?
>
> Maybe we should update something in the Lisp Manual
> advising people to quote lambda expressions in this case.

I've installed the following change.  Please adjust if necessary.

--8<---cut here---start->8---
--- variables.texi  02 May 2006 13:14:51 +0200  1.79
+++ variables.texi  10 May 2006 15:00:53 +0200  
@@ -1784,7 +1784,8 @@
 file variables standardly have @code{safe-local-variable} properties,
 including @code{fill-column}, @code{fill-prefix}, and
 @code{indent-tabs-mode}.  For boolean-valued variables that are safe,
-use @code{booleanp} as the property value.
+use @code{booleanp} as the property value.  Lambda expressions should
+be quoted so that @code{describe-variable} can display the predicate.
 
 @defopt safe-local-variable-values
 This variable provides another way to mark some variable values as
--8<---cut here---end--->8---

I still think we should avoid printing byte-code even in case third
party libraries forget to quote a lambda expression.  May I install
the following change in `describe-variable'?  (Suggestion for better
wording welcome.)

--8<---cut here---start->8---
--- help-fns.el 02 May 2006 13:14:50 +0200  1.87
+++ help-fns.el 10 May 2006 14:57:31 +0200  
@@ -642,10 +642,12 @@
 (princ (if (stringp (car obsolete)) (car obsolete)
  (format "use `%s' instead." (car obsolete
 (terpri))
- (when safe-var 
-   (princ "This variable is safe to use as a file local variable")
-   (princ (format " only if its value\nsatisfies the predicate 
`%s'.\n"
-  safe-var))
+ (when safe-var
+   (princ "This variable is safe to use as a file local variable ")
+   (princ "only if its value\nsatisfies the predicate ")
+   (princ (if (byte-code-function-p safe-var)
+  "which is byte-compiled expression.\n"
+(format "`%s'.\n" safe-var)))
(terpri))
  (princ "Documentation:\n")
   (princ (or doc "Not documented as a variable.")))
--8<---cut here---end--->8---

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Tue, May 09 2006, Richard Stallman wrote:

>   > | This variable is safe to use as a file local variable only if its 
> value
>   > | satisfies the predicate `#[(x) [BYTE-CODE stripped] [x (t nil 
> shared dwim)] 2]'.
>
> Why is the predicate a bytecode, instead of a symbol whose
> function definition is a bytecode?

The predicate is a lambda expression which was bytecomplied [I'm not
sure if this is what you asked for].  I gave a recipe to reproduce in
my first mail.  FWIW, if I quote[1] the lambda expression in my
recipe, I get the expected result:

,[  v rs-foo RET ]
| This variable is safe to use as a file local variable only if its value
| satisfies the predicate `(lambda (x) (or (stringp x) (member x (quote (t nil 
shared dwim)'.
`

On Mon, May 08 2006, Dan Nicolaescu wrote:

> I am not sure what to do in this situation. Should we print the
> bytecode? A disassembly of the bytecode (not very useful)? 
> Or nothing?
>
> Opinions?

Printing the bytecode looks like a bug from the user's POV; and it
isn't useful.

Bye, Reiner.

[1]
(defvar rs-foo nil)
(put 'rs-foo 'safe-local-variable
 ;; Quoted lambda expression:
 '(lambda (x)
(or (stringp x)
(member x (quote (t nil shared dwim))
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: add info about safe-local-variable to describe-variable

[Reiner Steib]

On Sat, Apr 29 2006, Dan Nicolaescu wrote:

> AFAIK to find out whether a variable is safe or not one has to read
> the source code. It would be nice to have describe-variable give this
> information. 

The output of ` v TeX-master RET' now includes some byte-code:

,[  v TeX-master RET ]
| TeX-master is a variable defined in `tex.el'.
| Its value is nil
| 
| Automatically becomes buffer-local when set in any fashion.
| 
| This variable is safe to use as a file local variable only if its value
| satisfies the predicate `#[(x) [BYTE-CODE stripped] [x (t nil shared dwim)] 
2]'.
| [...]
`

To reproduce:

- emacs -Q

- C-x C-f new-file.el RET

- insert...

--8<---cut here---start->8---
(defvar rs-foo nil)
(put 'rs-foo 'safe-local-variable
 (lambda (x)
   (or (stringp x)
   (member x (quote (t nil shared dwim))
--8<---cut here---end--->8---

- C-x C-s

- M-x emacs-lisp-byte-compile-and-load RET

-  v rs-foo RET

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Gnus MIME parsing bug?

[Reiner Steib]

[ CC-ing [EMAIL PROTECTED] ]

On Sat, May 06 2006, Giorgos Keramidas wrote:

> I have a UNIX mailbox with several MIME messages with multiple
> alternative parts, which comes up with seven different messages when
> opened in Mutt:
>
>1 r + 2006-02-26 Petros V (   67) about svn
>2 r + 2006-02-28 Petros V (   90) `->
>3 r + 2006-03-02 Petros V (   53)   `->
>4 r + 2006-03-04 Petros V (   91) `->
>5 r + 2006-03-06 Petros V (   47)   `->
>6 r + 2006-04-28 Petros V (   76) `->
>7   + 2006-04-29 Petros V (  328)   `->
>
> Then I create an nndoc group and try to import messages from this
> mailbox though, Gnus shows only 3 messages.  It looks like some of the
> messages are 'eaten' by the part that splits the mailbox in separate
> mail messages.  This only seems to happen with messages that have
> multiple alternative parts (i.e. text/plain and text/html).

Did you try to specify mbox explicitely instead of letting Gnus guess
the type of the file?  I.e. `C-u G f file RET m'?

> In GNU Emacs 22.0.50.1 (i386-unknown-freebsd7.0, GTK+ Version 2.8.17)
>  of 2006-05-06 on gothmog.pc

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: crash: x_set_name_internal, prepare_menu_bars

[Reiner Steib]

On Wed, Apr 12 2006, Reiner Steib wrote:

>> In GNU Emacs 22.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>>  of 2006-04-12 on bridgekeeper
>> X server distributor `The X.Org Foundation', version 11.0.60801000
>> configured using `configure '--prefix=[...]/HEAD' '--with-gtk' 
>> '--exec-prefix=[...]/HEAD-x86_64''
>
> Compiled using MYCPPFLAGS='-DENABLE_CHECKING=1'.

Another crash today, with the same build after ` k' + click on the
mode line.

(Is it better to keep this build and it's sources to investigate or
update from cvs and hope that it's fixed?)

--8<---cut here---start->8---
Detaching after fork from child process 17315.

Emacs fatal error: [...]/emacs/src/window.c:4292: assertion failed: 
GC_WINDOWP(parent)

Breakpoint 1, abort ()
at [...]/emacs/src/emacs.c:463
463 {
(gdb) bt
#0  abort () at [...]/emacs/src/emacs.c:463
#1  0x005a0bf4 in die (msg=Variable "msg" is not available.
)
at [...]/emacs/src/alloc.c:6211
#2  0x004b250f in Fadjust_window_trailing_edge (window=Variable 
"window" is not available.
)
at [...]/emacs/src/window.c:4267
#3  0x005c24e7 in Feval (form=Variable "form" is not available.
)
at [...]/emacs/src/eval.c:2247
#4  0x005c6312 in internal_lisp_condition_case (var=10815889, 
bodyform=9680605, handlers=9680669)
at [...]/emacs/src/eval.c:1418
#5  0x005fdca0 in Fbyte_code (bytestr=9680480, vector=Variable "vector" 
is not available.
)
at [...]/emacs/src/bytecode.c:884
#6  0x005c2c75 in funcall_lambda (fun=9680392, nargs=2, 
arg_vector=0x7fbfffcae8)
at [...]/emacs/src/eval.c:3088
#7  0x005c3332 in Ffuncall (nargs=Variable "nargs" is not available.
)
at [...]/emacs/src/eval.c:2956
#8  0x005fd729 in Fbyte_code (bytestr=15102417, vector=Variable 
"vector" is not available.
)
at [...]/emacs/src/bytecode.c:694
#9  0x005c24e7 in Feval (form=Variable "form" is not available.
)
at [...]/emacs/src/eval.c:2247
#10 0x005c2a9c in Fprogn (args=9682317)
at [...]/emacs/src/eval.c:432
#11 0x0053cc4a in Ftrack_mouse (args=9682317)
at [...]/emacs/src/keyboard.c:3485
#12 0x005c257a in Feval (form=Variable "form" is not available.
)
at [...]/emacs/src/eval.c:2241
#13 0x005c2a9c in Fprogn (args=9682285)
at [...]/emacs/src/eval.c:432
#14 0x005c2eb6 in funcall_lambda (fun=9682248, nargs=0, 
arg_vector=0x7fbfffcf98)
at [...]/emacs/src/eval.c:3081
#15 0x005c3332 in Ffuncall (nargs=Variable "nargs" is not available.
)
at [...]/emacs/src/eval.c:2956
#16 0x005fd729 in Fbyte_code (bytestr=15102705, vector=Variable 
"vector" is not available.
)
at [...]/emacs/src/bytecode.c:694
#17 0x005c2c75 in funcall_lambda (fun=9681512, nargs=2, 
arg_vector=0x7fbfffd148)
at [...]/emacs/src/eval.c:3088
#18 0x005c3332 in Ffuncall (nargs=Variable "nargs" is not available.
)
at [...]/emacs/src/eval.c:2956
#19 0x005fd729 in Fbyte_code (bytestr=15102609, vector=Variable 
"vector" is not available.
)
at [...]/emacs/src/bytecode.c:694
#20 0x005c2c75 in funcall_lambda (fun=9683544, nargs=1, 
arg_vector=0x7fbfffd358)
at [...]/emacs/src/eval.c:3088
#21 0x005c3332 in Ffuncall (nargs=Variable "nargs" is not available.
)
at [...]/emacs/src/eval.c:2956
#22 0x005bea39 in Fcall_interactively (function=15102993, 
record_flag=10815889, keys=10886996)
at [...]/emacs/src/callint.c:884
#23 0x005340ab in Fcommand_execute (cmd=Variable "cmd" is not available.
)
at [...]/emacs/src/keyboard.c:9759
#24 0x00549350 in command_loop_1 ()
at [...]/emacs/src/keyboard.c:1791
#25 0x005c1271 in internal_condition_case (
bfun=0x548c40 , handlers=10909985, 
hfun=0x53f7a0 )
at [...]/emacs/src/eval.c:1473
#26 0x0053e5ba in command_loop_2 ()
at [...]/emacs/src/keyboard.c:1328
#27 0x005c13d0 in internal_catch (tag=Variable "tag" is not available.
)
at [...]/emacs/src/eval.c:1211
#28 0x0053f1aa in command_loop ()
at [...]/emacs/src/keyboard.c:1307
#29 0x0053f251 in recursive_edit_1 ()
at [...]/emacs/src/keyboard.c:1000
#30 0x0053f3ee in Frecursive_edit ()
at [...]/emacs/src/keyboard.c:1061
#31 0x0052f226 in main (argc=3, argv=0x7fbfffdec8)
at [...]/emacs/src/emacs.c:1789

Lisp Backtrace:
"adjust-window-trailing-edge"
"mouse-drag-move-window-bottom"
"byte-code"
"track-mouse"
0x93bd4d Lisp type 5
"mouse-drag-mode-line-1"
"mouse-drag-mode-line"
"call-interactively"
(gdb) xbacktrace 
"adjust-

crash: x_set_name_internal, prepare_menu_bars

[Reiner Steib]

M-x report-emacs-bug RET wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

While creating a new frame, Emacs crashed.

> If emacs crashed, and you have the emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.

--8<---cut here---start->8---
Detaching after fork from child process 1444.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182940272320 (LWP 990)]
0x002a97462f9e in memcpy () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x002a97462f9e in memcpy () from /lib64/tls/libc.so.6
#1  0x002a9709ece0 in XChangeProperty () from /usr/X11R6/lib64/libX11.so.6
#2  0x002a970cb2f8 in XSetTextProperty () from /usr/X11R6/lib64/libX11.so.6
#3  0x002a970cb32e in XSetWMIconName () from /usr/X11R6/lib64/libX11.so.6
#4  0x0050835a in x_set_name_internal (f=0x23bd9d0, name=Variable 
"name" is not available.
)
at [...]/emacs/src/xfns.c:1651
#5  0x0048aec1 in prepare_menu_bars ()
at [...]/emacs/src/xdisp.c:8865
#6  0x0048fad8 in redisplay_internal (preserve_echo_area=Variable 
"preserve_echo_area" is not available.
)
at [...]/emacs/src/xdisp.c:10714
#7  0x00540caa in read_char (commandflag=1, nmaps=5, 
maps=0x7fbfffd410, prev_event=10815889, used_mouse_menu=0x7fbfffd4a4)
at [...]/emacs/src/keyboard.c:2549
#8  0x005456d5 in read_key_sequence (keybuf=0x7fbfffd640, bufsize=30, 
prompt=10815889, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at [...]/emacs/src/keyboard.c:8865
#9  0x00548f02 in command_loop_1 ()
at [...]/emacs/src/keyboard.c:1536
#10 0x005c1271 in internal_condition_case (
bfun=0x548c40 , handlers=10909985, 
hfun=0x53f7a0 )
at [...]/emacs/src/eval.c:1473
#11 0x0053e5ba in command_loop_2 ()
at [...]/emacs/src/keyboard.c:1328
#12 0x005c13d0 in internal_catch (tag=Variable "tag" is not available.
)
at [...]/emacs/src/eval.c:1211
#13 0x0053f1aa in command_loop ()
at [...]/emacs/src/keyboard.c:1307
#14 0x0053f251 in recursive_edit_1 ()
at [...]/emacs/src/keyboard.c:1000
#15 0x0053f3ee in Frecursive_edit ()
at [...]/emacs/src/keyboard.c:1061
#16 0x0052f226 in main (argc=3, argv=0x7fbfffdec8)
at [...]/emacs/src/emacs.c:1789
(gdb) xbacktrace 
(gdb) bt full
#0  0x002a97462f9e in memcpy () from /lib64/tls/libc.so.6
No symbol table info available.
#1  0x002a9709ece0 in XChangeProperty () from /usr/X11R6/lib64/libX11.so.6
No symbol table info available.
#2  0x002a970cb2f8 in XSetTextProperty () from /usr/X11R6/lib64/libX11.so.6
No symbol table info available.
#3  0x002a970cb32e in XSetWMIconName () from /usr/X11R6/lib64/libX11.so.6
No symbol table info available.
#4  0x0050835a in x_set_name_internal (f=0x23bd9d0, name=Variable 
"name" is not available.
)
at [...]/emacs/src/xfns.c:1651
bytes = Variable "bytes" is not available.
(gdb) up
#1  0x002a9709ece0 in XChangeProperty () from /usr/X11R6/lib64/libX11.so.6
(gdb) up
#2  0x002a970cb2f8 in XSetTextProperty () from /usr/X11R6/lib64/libX11.so.6
(gdb) up
#3  0x002a970cb32e in XSetWMIconName () from /usr/X11R6/lib64/libX11.so.6
(gdb) up
#4  0x0050835a in x_set_name_internal (f=0x23bd9d0, name=Variable 
"name" is not available.
)
at /home/dept/ste/src/links/emacs/cvs-HEAD/emacs/src/xfns.c:1651
1651XSetWMIconName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), 
&icon);
(gdb) p f
$1 = 0x23bd9d0
(gdb) p &icon
$2 = (XTextProperty *) 0x7fbfffc400
--8<---cut here---end--->8---

If I can provide more information, please tell me which gdb commands I
should use.

> If you would like to further debug the crash, please read the file
> [...]/HEAD/share/emacs/22.0.50/etc/DEBUG for instructions.


> In GNU Emacs 22.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-04-12 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=[...]/HEAD' '--with-gtk' 
> '--exec-prefix=[...]/HEAD-x86_64''

Compiled using MYCPPFLAGS='-DENABLE_CHECKING=1'.

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

> Major mode: Summary

> Minor modes in effect:
>   iswitchb-mode: t
>   msb-mode: t
>   savehist-mode: t
>   minibuffer-electric-default-mode: t
>   show-paren-mode: t
>   hl-line-mode: t
>   which-function-mode: t
>   recentf-mode: t
>   tooltip-mode: t
>   auto-compression-mode: t
>   tool-bar-mode: t
>   mouse-wheel-mode: t
>

Re: pgg-gpg stalls

[Reiner Steib]

On Thu, Apr 06 2006, Romain Francoise wrote:

> Thomas Baumann <[EMAIL PROTECTED]> writes:
>
>> sending of signed emails is currently impossible.
>
>> after sending an email in MH-E, emacs waits (endlessly) for something
>> until C-g is pressed leaving the process pgg-gpg running.
>
>> This worked before with pgg-gpg of 2006-02-10.
>
> Please update and try again, we (the Gnus developers) have decided to
> revert the last batch of new features that went in PGG, in order to
> stabilize the upcoming Gnus 5.10.8 release.

I wasn't not sure if `allout.el' depends on the symmetric encryption
features, so I didn't revert it in Emacs CVS.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Send Bug Report is worse

[Reiner Steib]

On Mon, Apr 03 2006, Richard Stallman wrote:

> This message:
>
>  "*** E-Mail body has been placed on clipboard, please paste
>  them here! ***"
>
> I don't see that message when I use it.  It must be specific to some
> aspect of your configuration.  Where does it come from?

The message comes from `mailclient-send-it' which is the default
`send-mail-function' on some platforms:

(defcustom send-mail-function
  (if (and window-system (memq system-type '(darwin windows-nt)))
  'mailclient-send-it
'sendmail-send-it)
  "Function to call to send the current buffer as mail.
[...])

`mailclient-send-it' tries to delegate the mail message to the
system's default mail client.  There have been suggestions to improve
the message during a related discussion about
`message-send-mail-function' on emacs-devel.

(Cc-ing David Reitter, the author of `mailclient.el')

Bye, Reiner.

[1] See subject "gnus / message-send-mail-with-mailclient" in March.
http://thread.gmane.org/[EMAIL PROTECTED]
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: "Funktion" in Elisp manual

[Reiner Steib]

Drew Adams wrote:

> In the Emacs Lisp manual, for example node Parameter Access, I see
> "Funktion" everywhere. That is not English.
>
> In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
>  of 2006-03-20 on W2ONE
> X server distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

I cannot find "Funktion" anywhere in the current sources:

,
| -*- mode: grep; default-directory: ".../emacs/lispref/" -*-
| Grep started at Sat Apr  1 12:11:12
| 
| grep -nH -ie funktion *.texi
| 
| Grep finished with no matches found at Sat Apr  1 12:11:12
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash: read_process_output

[Reiner Steib]

M-x report-emacs-bug RET wrote:
> If emacs crashed, and you have the emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /import/xtra/emacs/HEAD/share/emacs/22.0.50/etc/DEBUG for instructions.

--8<---cut here---start->8---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182940272320 (LWP 21178)]
0x002a974621ff in bcopy () from /lib64/tls/libc.so.6
(gdb) xbacktrace 
(gdb) bt
#0  0x002a974621ff in bcopy () from /lib64/tls/libc.so.6
#1  0x028731d8 in ?? ()
#2  0x00605720 in read_process_output (proc=38074996, channel=Variable 
"channel" is not available.
)
at [...]/cvs-HEAD/emacs/src/process.c:5071
#3  0x006069c9 in status_notify (deleting_process=0x0)
at [...]/cvs-HEAD/emacs/src/process.c:6571
#4  0x0060da97 in wait_reading_process_output (time_limit=30, 
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=10832881, 
wait_proc=0x0, just_wait_proc=0)
at [...]/cvs-HEAD/emacs/src/process.c:4364
#5  0x0044c6f1 in sit_for (sec=30, usec=0, reading=1, display=1, 
initial_display=0)
at [...]/cvs-HEAD/emacs/src/dispnew.c:6423
#6  0x00544653 in read_char (commandflag=1, nmaps=5, 
maps=0x7fbfffd4d0, prev_event=10832881, used_mouse_menu=0x7fbfffd564)
at [...]/cvs-HEAD/emacs/src/keyboard.c:2777
#7  0x005481eb in read_key_sequence (keybuf=0x7fbfffd700, bufsize=30, 
prompt=10832881, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at [...]/cvs-HEAD/emacs/src/keyboard.c:8874
#8  0x0054ba22 in command_loop_1 ()
at [...]/cvs-HEAD/emacs/src/keyboard.c:1536
#9  0x005c4951 in internal_condition_case (
bfun=0x54b760 , handlers=10926369, 
hfun=0x542280 )
at [...]/cvs-HEAD/emacs/src/eval.c:1465
#10 0x005410aa in command_loop_2 ()
at [...]/cvs-HEAD/emacs/src/keyboard.c:1328
#11 0x005c4aa0 in internal_catch (tag=Variable "tag" is not available.
)
at [...]/cvs-HEAD/emacs/src/eval.c:1211
#12 0x00541ca8 in command_loop ()
at [...]/cvs-HEAD/emacs/src/keyboard.c:1307
#13 0x00541d41 in recursive_edit_1 ()
at [...]/cvs-HEAD/emacs/src/keyboard.c:1000
#14 0x00541ee0 in Frecursive_edit ()
at [...]/cvs-HEAD/emacs/src/keyboard.c:1061
#15 0x00531b06 in main (argc=3, argv=0x7fbfffdf88)
at [...]/cvs-HEAD/emacs/src/emacs.c:1789
(gdb) list
1789  Frecursive_edit ();
1790  /* NOTREACHED */
1791  return 0;
1792}
1793^L
1794/* Sort the args so we can find the most important ones
1795   at the beginning of argv.  */
1796
1797/* First, here's a table of all the standard options.  */
1798
(gdb) bt full
#0  0x002a974621ff in bcopy () from /lib64/tls/libc.so.6
No symbol table info available.
#1  0x028731d8 in ?? ()
No symbol table info available.
#2  0x00605720 in read_process_output (proc=38074996, channel=Variable 
"channel" is not available.
)
at [...]/cvs-HEAD/emacs/src/process.c:5071
count = 2
odeactivate = 10832881
obuffer = Variable "obuffer" is not available.
--8<---cut here---end--->8---

If I can provide more information, please tell me which gdb commands I
should use.

> In GNU Emacs 22.0.50.11 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-03-09 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' 
> '--exec-prefix=/import/xtra/emacs/HEAD-x86_64''

Compiled using MYCPPFLAGS='-DENABLE_CHECKING=1'.

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Crash in xg_get_image_for_pixmap with ENABLE_CHECKING=1

[Reiner Steib]

On Fri, Feb 24 2006, Jan D. wrote:

>> If I can provide more information, please tell me which gdb commands I
>> should use.
>> 
>
> (gdb) fr 2
> (gdb) p file
> (gdb) pr
> (gdb) p specified_file
> (gdb) pr

--8<---cut here---start->8---
(gdb) fr 2
#2  0x0052a5df in xg_get_image_for_pixmap (f=0x1018880, img=0x24293b0, 
widget=0x1019a90, old_widget=0x1bef8a0)
at /home/dept/ste/src/links/emacs/cvs-HEAD/emacs/src/gtkutil.c:390
390   g_object_unref (G_OBJECT (icon_buf));
(gdb) p file
No symbol "file" in current context.
(gdb) pr
The history is empty.
(gdb) p f
$1 = 0x1018880
(gdb) pr
2109712
(gdb) p img
$2 = (struct image *) 0x24293b0
(gdb) pr
4739702
(gdb) p specified_file
$3 = 37902387
(gdb) pr
"/import/xtra/emacs/HEAD/share/emacs/etc/images/save.xpm"
--8<---cut here---end--->8---

This file doesn't exist anymore.  I'm not sure if it was there when
the crash occurred.  I've been working on new icons for Gnus' tool
bars and during this, I often copied and removed icons ("etc" is a
symlink to the directory containing the Gnus icons.)

But even when removing used icons while running Emacs, Emacs shouldn't
crash.

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash in xg_get_image_for_pixmap with ENABLE_CHECKING=1

[Reiner Steib]

M-x report-emacs-bug RET wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

Emacs crash when exiting from a group in Gnus.

> If emacs crashed, and you have the emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /import/xtra/emacs/HEAD/share/emacs/22.0.50/etc/DEBUG for instructions.

DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x530bb0: file [...]/emacs/src/emacs.c, line 463.
Breakpoint 2 at 0x55a050: file [...]/emacs/src/sysdep.c, line 1373.
[...]
Detaching after fork from child process 2334.

Emacs fatal error: [...]/emacs/src/gtkutil.c:352: assertion failed: 
GC_STRINGP(file)
[Switching to Thread 182940272320 (LWP 25641)]

Breakpoint 1, abort ()
at [...]/emacs/src/emacs.c:463
463 {
(gdb) bt full
#0  abort () at [...]/emacs/src/emacs.c:463
No locals.
#1  0x005a3634 in die (msg=Variable "msg" is not available.
)
at [...]/emacs/src/alloc.c:6193
No locals.
#2  0x0052a5df in xg_get_image_for_pixmap (f=0x1018880, img=0x24293b0, 
widget=0x1019a90, old_widget=0x1bef8a0)
at [...]/emacs/src/gtkutil.c:390
cmap = Variable "cmap" is not available.
(gdb) bt
#0  abort () at [...]/emacs/src/emacs.c:463
#1  0x005a3634 in die (msg=Variable "msg" is not available.
)
at [...]/emacs/src/alloc.c:6193
#2  0x0052a5df in xg_get_image_for_pixmap (f=0x1018880, img=0x24293b0, 
widget=0x1019a90, old_widget=0x1bef8a0)
at [...]/emacs/src/gtkutil.c:390
#3  0x0052ef95 in update_frame_tool_bar (f=0x1018880)
at [...]/emacs/src/gtkutil.c:3696
#4  0x0049adb1 in redisplay_window (window=35401764, just_this_one_p=0)
at [...]/emacs/src/xdisp.c:9588
#5  0x0049b79d in redisplay_window_0 (window=Variable "window" is not 
available.
)
at [...]/emacs/src/xdisp.c:11451
#6  0x005c4558 in internal_condition_case_1 (
bfun=0x49b770 , arg=35401764, handlers=10815189, 
hfun=0x463350 )
at [...]/emacs/src/eval.c:1506
#7  0x0047cf4f in redisplay_windows (window=35401764)
at [...]/emacs/src/xdisp.c:11430
#8  0x004902b5 in redisplay_internal (preserve_echo_area=Variable 
"preserve_echo_area" is not available.
)
at [...]/emacs/src/xdisp.c:10990
#9  0x00543696 in read_char (commandflag=1, nmaps=7, 
maps=0x7fbfffd490, prev_event=10832881, used_mouse_menu=0x7fbfffd534)
at [...]/emacs/src/keyboard.c:2549
#10 0x005480db in read_key_sequence (keybuf=0x7fbfffd6d0, bufsize=30, 
prompt=10832881, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at [...]/emacs/src/keyboard.c:8874
#11 0x0054b912 in command_loop_1 ()
at [...]/emacs/src/keyboard.c:1536
#12 0x005c4871 in internal_condition_case (
bfun=0x54b650 , handlers=10926353, 
hfun=0x542170 )
at [...]/emacs/src/eval.c:1465
#13 0x00540f9a in command_loop_2 ()
at [...]/emacs/src/keyboard.c:1328
#14 0x005c49c0 in internal_catch (tag=Variable "tag" is not available.
)
at [...]/emacs/src/eval.c:1211
#15 0x00541b98 in command_loop ()
at [...]/emacs/src/keyboard.c:1307
#16 0x00541c31 in recursive_edit_1 ()
at [...]/emacs/src/keyboard.c:1000
#17 0x00541dd0 in Frecursive_edit ()
at [...]/emacs/src/keyboard.c:1061
#18 0x005319f6 in main (argc=5, argv=0x7fbfffdf58)
at [...]/emacs/src/emacs.c:1789
(gdb) xbacktrace 
(gdb) 

If I can provide more information, please tell me which gdb commands I
should use.

> In GNU Emacs 22.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-02-22 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' 
> '--exec-prefix=/import/xtra/emacs/HEAD-x86_64''

Compiled with MYCPPFLAGS='-DENABLE_CHECKING=1'

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Emacs crashes repeatedly

[Reiner Steib]

On Fri, Feb 17 2006, Nick Roberts wrote:

> I have had three crashes from different places in the last two days.  They
> have originated in different plaves but the bottom of the stack always looks a
> bit like this:
>
> 0  0x005657a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x005a5df6 in kill () from /lib/tls/libc.so.6
> #2  0x0810e583 in fatal_error_signal (sig=11) at emacs.c:430
> #3  
> #4  0x080e89d1 in x_catch_errors_unwind (dummy=137858041) at xterm.c:7543
> #5  0x0818dc6e in unbind_to (count=44, value=137858041) at eval.c:3233
> #6  0x081c1193 in Fbyte_code (bytestr=140169739, vector=151464788, 
> maxdepth=56) at bytecode.c:716
> #7  0x0818d711 in funcall_lambda (fun=151465068, nargs=9, 
> arg_vector=0xfee66794) at eval.c:3066
> ...
>
> And in x_catch_errors_unwind I always have:
>
> (gdb) p x_error_message
> $2 = (struct x_error_message_stack *) 0x0

I had the same problem, see [1].

Following Stefan's advice, I updated and recompiled with
ENABLE_CHECKING some days ago.  But since then Emacs didn't crash
anymore.

> In GNU Emacs 22.0.50.62 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

So it's not specific to x86_64.

Bye, Reiner.

[1] 
Subject: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)
Date: Wed, 08 Feb 2006 18:19:23 +0100
Message-ID: <[EMAIL PROTECTED]>
To: emacs-pretest-bug@gnu.org
(further replies on emacs-devel)
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Reiner Steib]

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

` k [Ctrl  ]'  (But it's not reproducible.)

> If emacs crashed, and you have the emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /import/xtra/emacs/HEAD/share/emacs/22.0.50/etc/DEBUG for instructions.

GNU gdb 6.2.1
Copyright 2004 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 "x86_64-suse-linux"...Using host libthread_db library
 "/lib64/tls/libthread_db.so.1".

DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x4e7090: file [...]/emacs/src/emacs.c, line 463.
Breakpoint 2 at 0x5014c0: file [...]/emacs/src/sysdep.c, line 1373.
[...]
(gdb) r -l lisp-tmp/gnus-init-tool-bar.el --eval '(gnus )'
Starting program: [...]/emacs/cvs-HEAD/x86_64/src/emacs \
  -l lisp-tmp/gnus-init-tool-bar.el --eval '(gnus )'
[Thread debugging using libthread_db enabled]
[New Thread 182940272320 (LWP 4018)]
Detaching after fork from child process 4019.
[...]
Detaching after fork from child process 11601.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182940272320 (LWP 4018)]
x_catch_errors_unwind (dummy=9829361)
at [...]/emacs/src/xterm.c:7530
7530  Display *dpy = x_error_message->dpy;
(gdb) bt full
#0  x_catch_errors_unwind (dummy=9829361)
at [...]/emacs/src/xterm.c:7530
dpy = Variable "dpy" is not available.
(gdb) xbacktrace
(gdb) 

> In GNU Emacs 22.0.50.8 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
>  of 2006-02-08 on bridgekeeper
> X server distributor `The X.Org Foundation', version 11.0.60801000
> configured using `configure '--prefix=[...]/emacs/HEAD' '--with-gtk'
>  '--exec-prefix=[...]/emacs/HEAD-x86_64''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: [EMAIL PROTECTED]
>   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
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Key sequences reserved for users used in allout.el (was: existing work on TODO items)

[Reiner Steib]

On Mon, Jan 09 2006, Ken Manheimer wrote:

[ allout.el ]
> it defaults to using symmetric-mode encoding.  describe-key (`C-h k
> C-c x') will tell you that a single universal argument (ie, C-u) will
> use key-pair encryption, and a doubled universal argument will do the
> symmetric-mode encryption but disregard the cache.

The key binding `C-c x' is reserved for users, so you should change
it, I think.

,[ (info "(emacs)Keymaps") ]
|As a user, you can redefine any key; but it is usually best to stick
| to key sequences that consist of `C-c' followed by a letter (upper or
| lower case).  These keys are "reserved for users," so they won't
| conflict with any properly designed Emacs extension.  The function keys
|  through  are also reserved for users.  If you redefine some
| other key, your definition may be overridden by certain extensions or
| major modes which redefine the same key.
`

Bye, Reiner.
-- 
   ,,,
  (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

vc-annotate tries to load vc-nil

[Reiner Steib]

Hi Stefan,

the following change breaks `M-x vc-annotate RET' for me:

2005-12-22  Stefan Monnier  <[EMAIL PROTECTED]>

* vc.el: [...]
(vc-annotate-buffers): Remove var.
(vc-annotate-backend): Make it buffer-local.
(vc-annotate): Move the interaction to the interactive spec.
Add a `buf' argument.
(vc-annotate-warp-version): Use this new `buf' argument to avoid
killing&creating a vc-annotate buffer, which is very disruptive when
the buffers are shown in dedicated frames.

$ emacs-cvs -Q -f toggle-debug-on-error [...]/emacs/lisp/vc.el -f vc-annotate

Debugger entered--Lisp error: (file-error "Cannot open load file" "vc-nil")
  require(vc-nil)
  vc-find-backend-function(nil annotate-command)
  vc-annotate("[...]/emacs/lisp/vc.el" "1.409" nil)
  call-interactively(vc-annotate)
  command-execute(vc-annotate)
  command-line-1(("-f" "toggle-debug-on-error"
"[...]/emacs/lisp/vc.el" "-f" "vc-annotate"))
  command-line()
  normal-top-level()

If I revert to revision 1.407 of vc.el it works as expected:

$ emacs-cvs -Q -f toggle-debug-on-error \
  -l [...]/emacs/lisp/vc.el.~1.407~ \
 [...]/emacs/lisp/vc.el -f vc-annotate

Bye, Reiner.

`report-emacs-bug' output follows:

In GNU Emacs 22.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9)
 of 2005-12-28 on bridgekeeper
X server distributor `The X.Org Foundation', version 11.0.60801000
configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' 
'--exec-prefix=/import/xtra/emacs/HEAD-x86_64''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: [EMAIL PROTECTED]
  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
  locale-coding-system: iso-8859-15
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t

Recent input:
  M-x r e p o
r t  

Recent messages:
Annotating...
Loading debug...done
Entering debugger...
Loading help-mode...done
Making completion list...
Redisplaying annotation...done
Error during redisplay: (file-error Cannot open load file vc-nil)
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug