Luc Teirlinck | 1 Dec 2004 01:45
Picon

Re: lispref gmake info build Error 2 on 11/29/2004 CVS pull

Richard Stallman wrote:

   The bootstrap mechanism should be fixed so that errors in generating
   an Info file don't prevent bootstrapping from finishing.

I am not sure about that.  It would mean that the user might wind up
without some important manuals.  Also, right now, errors in
bootstrapping (with the exception of the one we are talking about) are
usually fixed in a matter of hours, because a maintainer notices or a
user files a bug report.  If an error in the manual only causes some
error messages to be printed, that flash unread across the screen,
like all those tons of other error messages, serious non-deliberate
errors in the manual may remain unnoticed.

There are plenty of known problems with the Elisp and Emacs manuals
that still need to be fixed and that are more serious than the fact
that those two variables are not yet documented.  Why is remembering
those two problems both so unusually difficult and so unusually
important that it is worth disabling building the Elisp manual until
they are fixed?  There are other ways to catalogue and remember what
one still has to do than to cause errors.

If they are so important, why do we not fix them right now?  What
about the following three patches?  It would be good if somebody
really familiar with the frame parameter and variable `line-spacing'
could double check whether the description is 100 percent accurate.
(If not, then the docstring is unclear.)  Even if there would still be
some problems with the patches why do we not comment out these error
producing xrefs, so that people can bootstrap without problems again.
It should not take all eternity to get those two variables documented
(Continue reading)

Luc Teirlinck | 1 Dec 2004 02:18
Picon

Re: lispref gmake info build Error 2 on 11/29/2004 CVS pull

I believe that the following patch to man/frames.texi is better than
the one I sent before.  Only the first part is changed.

===File ~/man-frames.texi-diff-2============================
*** frames.texi	26 Nov 2004 13:39:13 -0600	1.66
--- frames.texi	30 Nov 2004 19:03:36 -0600	
***************
*** 761,773 ****
  frames yet to be created.  Customize the option  <at> code{scroll-bar-mode}
  to control the use of scroll bars at startup.  You can use it to specify
  that they are placed at the right of windows if you prefer that.  You
! can use the X resource  <at> samp{verticalScrollBars} to control the initial
! setting of Scroll Bar mode similarly.   <at> xref{Resources}.

   <at> findex toggle-scroll-bar
    To enable or disable scroll bars for just the selected frame, use the
  command  <at> kbd{M-x toggle-scroll-bar}.

   <at> vindex scroll-bar-width
   <at> cindex width of the scroll bar
    You can control the scroll bar width by changing the value of the
--- 761,781 ----
  frames yet to be created.  Customize the option  <at> code{scroll-bar-mode}
  to control the use of scroll bars at startup.  You can use it to specify
  that they are placed at the right of windows if you prefer that.  You
! have to set this variable through the  <at> samp{Customize} interface
! ( <at> pxref{Easy Customization}).  Otherwise, it will not work properly.
! You can use the X resource  <at> samp{verticalScrollBars} to control the
! initial setting of Scroll Bar mode similarly.   <at> xref{Resources}.

(Continue reading)

Richard.G.Bielawski | 1 Dec 2004 04:55
Picon
Favicon

A fix for show-paren-function problem

I believe the following patch to show-paren-function in paren.el
will fix a long standing bug that causes show-paren-mode to
incorrectly highlight matching parens as mismatched if their
syntax was assigned via font-lock-syntactic-keywords or put.

The patch does not change the current behavior in text where 
syntax is determined by the syntax table alone.  But it does 
afford the programmer assigning syntax arbitrarily more 
flexibility in determining what will be considered a match.

For example:
All these pairs should highlight as properly matched:
Begin End     begin end       BEGIN END    begin end;
^       ^     ^       ^       ^       ^    ^        ^
While these are mismatched because `block' requires `end block'.
block end;
^       ^
Such conditions are easily handled by the fix below while
not changing purely syntax-table based matching in any way.

   ;; If found a "matching" paren, see if it is the right
   ;; kind of paren to match the one we started at.
   (when (integerp pos)
     (let ((beg (min pos oldpos)) (end (max pos oldpos)))
       (when (/= (char-syntax (char-after beg)) ?\$)
         (setq mismatch
-              (not (eq (char-before end)
+              (not (eq (or (cdr (get-text-property (1- end) 'syntax-table))
+                           (char-before end))
                        ;; This can give nil.
(Continue reading)

Lars Magne Ingebrigtsen | 1 Dec 2004 22:52
Face
Picon
Favicon
Gravatar

Re: url-vars.el not loaded when using oort-gnus nnrss

"Clemens Fischer" <ino-qc <at> spotteswoode.de.eu.org> writes:

> i was using oort-gnus (recent CVS) and tried to enter a nnrss group.  here's
> the trace:
>
> 8<-- cut-from-here -->8
> Debugger entered--Lisp error: (void-variable url-nonrelative-link)
>   url-generic-parse-url("http://openpr.de/rss.php")

This is kinda surprising, since `url-generic-parse-url' is defined in
url-parse.el, and `url-nonrelative-link' is defined in url-vars.el,
and the former requires the latter.

What does `C-h f url-generic-parse-url' say, and does your
url-parse.el require url-vars.el?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi <at> gnus.org * Lars Magne Ingebrigtsen
Henrik Enberg | 2 Dec 2004 01:27
Picon

standard-diplay-table very broken

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

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

the 2004-12-01 change to disp-table.el completly breaks several parts of
Emacs, Gnus and Eshell among them.

Doing:

        (setq standard-display-table (make-display-table))

fixes the problem and makes Emacs usable for me again.

In GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, GTK+ Version 2.4.13)
 of 2004-12-01 on deathstar
Distributor `The XFree86 Project, Inc', version 11.0.40300001
configured using `configure '--with-gtk''

Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
(Continue reading)

C. Fischer | 2 Dec 2004 01:31
Favicon

Re: url-vars.el not loaded when using oort-gnus nnrss

* Lars Magne Ingebrigtsen:

> "Clemens Fischer" <ino-qc <at> spotteswoode.de.eu.org> writes:
>
>> Debugger entered--Lisp error: (void-variable url-nonrelative-link)
>>   url-generic-parse-url("http://openpr.de/rss.php")
>
> This is kinda surprising, since `url-generic-parse-url' is defined in
> url-parse.el, and `url-nonrelative-link' is defined in url-vars.el,
> and the former requires the latter.
>
> What does `C-h f url-generic-parse-url' say, and does your
> url-parse.el require url-vars.el?

url-generic-parse-url is a compiled Lisp function in `url-parse'.
(url-generic-parse-url URL)

Return a vector of the parts of URL.
Format is:
[proto username password hostname portnumber file reference attributes fullp]

this is a "shadowed lib" issue:

/usr/local/share/emacs/21.3.50/lisp/url/url-parse.el
/usr/local/share/emacs/site-lisp/w3/url-parse.el

emacs-w3m looks for "w3", but i have no idea if i can just dump (i.e. chmod 0
the "w3" directory) and see what breaks.

i'll tell you asap.
(Continue reading)

Kim F. Storm | 2 Dec 2004 10:21
Picon

Re: standard-diplay-table very broken

Henrik Enberg <henrik.enberg <at> telia.com> writes:

> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> the 2004-12-01 change to disp-table.el completly breaks several parts of
> Emacs, Gnus and Eshell among them.
>
> Doing:
>
>         (setq standard-display-table (make-display-table))
>
> fixes the problem and makes Emacs usable for me again.
>

You refer to the change below, which indeed looks broken,
as it assumes that (face-id 'glyph) is a fixed value, but
that is only true for a specific build of emacs.

Index: disp-table.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/disp-table.el,v
retrieving revision 1.52
(Continue reading)

Kim F. Storm | 2 Dec 2004 10:42
Picon

Re: standard-diplay-table very broken


I looked some more at this change, and there are several problems
with it.

- the code should not set standard-diplay-table unconditionally.

- the code should not use make-display-table which is autoloaded.

- perhaps the code shouldn't be in disp-table.el at all, but
  rather in faces.el right after "defface glyph" -- like this:

(or standard-diplay-table
    ;; avoid using autoloaded make-display-table here
    (setq standard-display-table (make-char-table 'display-table nil)))

(let* ((face (lsh (face-id 'glyph) 19))
       (backslash (+ face ?\\))
       (dot (+ face ?.)))
  (set-char-table-extra-slot standard-display-table 2 backslash)
  (aset standard-display-table 2208 (vector backslash ?\ ))
  (aset standard-display-table 2221 (vector backslash ?-))
  (set-char-table-extra-slot standard-display-table 3 (+ face ?^))
  (set-char-table-extra-slot standard-display-table 4 (vector dot dot dot)))

- the name of the 'glyph' face is not very good, as it doesn't say anything
  about what it's used for.  A better name could be 'escape-glyph'.

--

-- 
Kim F. Storm <storm <at> cua.dk> http://www.cua.dk
(Continue reading)

Kim F. Storm | 2 Dec 2004 11:45
Picon

Re: standard-diplay-table very broken

storm <at> cua.dk (Kim F. Storm) writes:

> I looked some more at this change, and there are several problems
> with it.
>
> - the code should not set standard-diplay-table unconditionally.
>
> - the code should not use make-display-table which is autoloaded.
>
> - perhaps the code shouldn't be in disp-table.el at all, but
>   rather in faces.el right after "defface glyph" -- like this:
>
> (or standard-diplay-table
>     ;; avoid using autoloaded make-display-table here
>     (setq standard-display-table (make-char-table 'display-table nil)))
>
> (let* ((face (lsh (face-id 'glyph) 19))
>        (backslash (+ face ?\\))
>        (dot (+ face ?.)))
>   (set-char-table-extra-slot standard-display-table 2 backslash)
>   (aset standard-display-table 2208 (vector backslash ?\ ))
>   (aset standard-display-table 2221 (vector backslash ?-))
>   (set-char-table-extra-slot standard-display-table 3 (+ face ?^))
>   (set-char-table-extra-slot standard-display-table 4 (vector dot dot dot)))
>
> - the name of the 'glyph' face is not very good, as it doesn't say anything
>   about what it's used for.  A better name could be 'escape-glyph'.

I have installed these changes.
(Continue reading)

Richard Stallman | 2 Dec 2004 14:10
Picon
Picon

Re: imenu fails in mode without comment-start-skip defined

For the various reasons that people have given, I've decided it
is better to remove the comment-checking code from imenu.el.
However, I will let the changes remain that prevent the loop from
getting stuck.

Gmane