[EMAIL PROTECTED] wrote:
GM I cannot reproduce this.
At least you perhaps can reproduce in an emacs *shell* buffer:
No, I can't. Surprisingly, you just repeating most of what you said
the first time word for word has not helped me to do so.
___
Sven Joachim wrote:
Yes, I can reproduce this with Emacs 21.4.
How about outside Emacs?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Zhang Wei wrote:
Checking d:/emacs-gbk/lisp/calendar...
Compiling d:/emacs-gbk/lisp/calendar/calendar.el...
In toplevel form:
calendar/calendar.el:2215:1:Error: Symbol's function definition is void: i
There have been no changes in lisp/calendar/ in the past two weeks. It
works for me.
Dan Jacobson wrote:
I notice in the *shell* buffer, suspend/fg acts funny.
I cannot reproduce this. If you want this investigating, please
provide a clear recipe showing the minimum emacs and shell
configurations needed to produce the problem.
___
Tom Tromey wrote:
2. Visit a patch file; make sure it is in diff-mode
3. C-h b
4. Move your mouse around the *Help* buffer.
Note that diff-unified-context and diff-context-unified
do not highlight -- you cannot click on these to go to the
appropriate help text.
Thanks; I think I
emacs -Q -l printing
load: Symbol's value as variable is void: ps-print-version
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Michael Olson wrote:
I removed it mistakenly, thinking that it was autogenerated by the build
system.
No problem. Looks like Miles already restored it in CVS too.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
rev 1.58 of copyright.el breaks copyright-update-year in some modes,
eg texinfo, depending on the value of comment-start-skip:
emacs -Q man/calendar.texi
M-x copyright-update
Wrong type argument: integer-or-marker-p, nil
comment-start-skip does not contain any subexpressions in texinfo mode
Brian van den Broek wrote:
According to section `39.5 Writing Calendar Files' of the emacs info file:
If the variable `cal-tex-diary' is non-`nil' (the default is
`nil'), diary entries are included also (in weekly and monthly
calendars only).
However, the effect is observed only
root wrote:
on line 892
This is in CVS checkout withon teh last 5 minutes
sorry for the typo.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Francesco Potorti` wrote:
At http://directory.fsf.org/GNU/emacs.html a link is provided to the
source tarball of Emacs 21.4a, rather than 22.1.
The emacs developers have no direct access to this page. As it says at
the end of the page, problems should be reported to bug-directory at
gnu.org. I
YAMAMOTO Mitsuharu wrote:
Thanks. I applied your patch to both the trunk and the EMACS_22_BASE
branch.
I think you should alter the changelog entry to be under your name,
which seems perfectly acceptable for corrections which are simple
typos (ie purely factual).
Large numbers of tiny
Stefan Monnier wrote:
Agreed, and the file contents shouldn't make any difference in this
respect since the file's extension is explicit.
But they do, since magic-mode-alist describes itself as overriding
auto-mode-alist. Maybe you mean this is a Bad Thing?
Nick Roberts wrote:
Info-scroll-up/down are bound on the mode-line (over the node name)
to mouse-1 and mouse-3. However, in a split window configuaration
with Info at the top and the bottom window selected, clicking there
scrolls the _bottom_ window, and Emacs gets confused if this is
Kevin Ryde wrote:
If I'm not mistaken the html-mode regexp in magic-mode-alist demands a
html. It'd be nice if a html doctype like
!DOCTYPE HTML ...
or
!DOCTYPE html ...
could be considered html too.
Since plain html is already accepted, I don't see how this can do
any harm,
Lennart Borgman (gmail) wrote:
In the attached images I have one overlay one character long that has a
red underline.
[...]
In the second picture I have added another overlay, with a slightly blue
background. This overlay is 10 characters long and includes a new line.
The first overlay
Dave Love wrote:
I explained it to rms, but he wouldn't do anything bug reports
without patches.
I can't parse this.
I doubt anyone else can say anything useful unless they're privy to
legal advice, but I haven't been asked for details. Why are you
querying this? Can you give legal advice?
Kevin Ryde wrote:
I suspect it's because the file has a mixture of end-of-line types.
The first line is LF, but the second and subsequent are CRLF.
Obviously that's fairly bogus, but it'd be nice if emacs content
matching could tolerate it.
OK, the magic-mode-alist entry now tolerates
Lennart Borgman (gmail) wrote:
The link to Extended Menu Items in the doc string for define-key is broken.
Thanks; fixed.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Johan Bockgård wrote:
The doc string for dired-virtual-mode speaks about the nonexistent
variable `buffer-contents-mode-alist'. Also, the regexp is wrong (the
/?+ part) and a bunch of backslashes are missing.
Thank you; installed.
___
Richard Stallman wrote:
I think this is an issue for aspell or ispell (whichever one you are
using). Not for Emacs.
No, I think rather that flyspell should downcase abbrevs before
defining them, like define-mode-abbrev does.
Beyond that, given the way expand-abbrev treats case, does it make
For now, I installed the flyspell change. I suggest we think about the
wider issue after the release.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Dave Love wrote:
I found that you're distributing a version of python.el that
includes work I did a couple of years ago (some of which seems to
have been somewhat broken in the process).
What's the reason for disregarding my legal concerns about that
work?
Maybe this message is meant for
Robert Marshall wrote:
threshhold should be threshold - in the text rather than the variable name.
Thanks. Fixed.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
It seems bad form to abort in the middle of the build though. A small
addition to configure.in makes it clearer IMO:
*** configure.in02 Apr 2007 16:10:31 -0700 1.442
--- configure.in19 Apr 2007 00:21:22 -0700
***
*** 2204,2210
dnl Do not put
Miles Bader wrote:
The filesystem I was thinking of wasn't AFS; I don't know if it's still
used or not.
I think this may be the original bug report requesting this feature,
from 1989. It says: FREEDOMNET, TRFS, the NewCastle Connection, and
several other products all use the superroot.
Ulrich Mueller wrote:
libXaw Xaw3d
0 0 fails in lwlib.c due to missing X11/Xaw/Paned.h
0 1 OK, links against libXaw3d.so.8
I think it's also going to fail in this case if you configure
--without-toolkit-scroll-bars --with-x-toolkit=lucid because then
Richard Stallman wrote:
I think this is the Andrew file system. Indeed, I think that is the
reason why Emacs doesn't convert `/..' to `/',
I don't know whether AFS is still used. If not, we would like to
remove the support for it, by and by. But there is certainly no
reason to remove it
Richard Stallman wrote:
It would be good to add a sentence in the Emacs Lisp Reference Manual
to explain this. Would someone please do that?
Done.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Andreas Seltenreich wrote:
I just switched from 22.0.96 to 22.0.98 and noticed that the file-local
variables in my ~/diary file are no longer honored. It seems like the
following change causes buffer-local variables to be flushed on each
call to diary-view-entries:
Fixed.
John ffitch wrote:
Debugger entered--Lisp error: (error Autoloading failed to define
function diary-font-lock-keywords)
Works for me. Are you sure your CVS is fully up to date? A `make
bootstrap' never hurts. Failing that, please provide a full recipe
starting from `emacs -Q'.
Roland Winkler wrote:
The following patch appears much clearer to me.
[...]
Should I check it in?
Entirely up to you. I installed mine, but feel free to revert it.
+ (unless (string-match \\`\\({.*}\\|\.*\\\)\\' init)
+(setq init (concat (bibtex-field-left-delimiter) init
+
Kim F. Storm wrote:
Should we add quack.el to the list of packages which we recommend people
to upgrade when using Emacs 22.1 ? (The list is in etc/NEWS).
I don't think this was a quack + emacs 22 problem, it was just a
problem in older versions of quack, full stop.
Nick Roberts wrote:
It fails on Emacs 22 too (it would be best if you checked this first). I'm
pretty sure it relates to my changes, but I'm not sure yet that the bug is
in tmm.el. org-mode has an awesome menubar!
[...]
Looking at the local map, I see the keyword keymap in the list many
Christian Schlauer wrote:
So the curly braces are missing.
I think this patch fixes it.
*** bibtex.el 21 Jan 2007 13:45:48 - 1.124
--- bibtex.el 12 Apr 2007 22:49:20 -
***
*** 1785,1791
(set-mark (point))
(message Mark set)
I should also say that the Format of Keymaps section of the lispref
has an example (lisp-mode-map) with a keymap sitting there on its
own. It looks weird to me too, but there you go.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
Nick Roberts wrote:
Does it fix the bug, or just mask the error? I mean does the menu on
a tty for Org mode look as it should with this change?
Well, it looks alright to me (at least, it looks the same as it does
in 21.3 when I load org-mode), but I don't know what problem your
recent change
Richard Matthew Stallman wrote:
It seems that this does not happen in the current CVS. Looks like it's
been this way for about 2 years.
If that is the case, how come Jose gets this bug? His snapshot is
surely not 2 years old.
I don't know. All I can say is that:
emacs -q
Stefan Monnier wrote:
The iff idiom is sufficiently common that we don't want to shy
away from it just at this one place. So either we rule it out
everywhere, or we use it liberally.
Sufficiently common in Emacs (~ 600 instances); I've never seen it
anywhere else as far as I remember. All it
Jose A. Ortega wrote:
In a buffer with scheme-mode active, delete-trailing-whitespace treats
a traling vertical bar character (|) as trailing whitespace (that is,
the character is deleted when invoking delete-trailing-whitespace,
either interactively or as a write hook).
It seems that this
Stephen Berman wrote:
If you call (diary) from your init-file and use the Custom interface
to customize diary-date-forms, the customization gets evaluated after
diary-font-lock-keywords has been set, so your customized date form
does not get fontified as it should. To reproduce:
Thanks;
Jeffrey C Honig wrote:
M-xhanoiRET
Erk.
Seems to be a font-lock related transpose-regions problem.
emacs -Q
Type abcd in scratch
M-: (transpose-regions 1 2 3 4)
Debugger entered--Lisp error: (args-out-of-range 0 0)
get-text-property(0 font-lock-multiline)
Dan Jacobson wrote:
$ emacs -Q -f calendar
wraps ugly these days.
I could very briefly reproduce this [1], then it went away. It turns
out my build was incomplete, and I was running a bootstrap-emacs
rather than a finished emacs.
In GNU Emacs 22.0.92.1 (i486-pc-linux-gnu, X toolkit, Xaw3d
Stephen Berman wrote:
Set today-visible-calendar-hook to 'calendar-mark-today in your
init-file or via Custom. Then, if you have the calendar buffer open
before midnight and keep it open past the stroke of midnight, the
marked date remains unchanged, i.e., now yesterday is marked.
I'm
Lennart Borgman (gmail) wrote:
The variable is marked obsolete in the same file where it is used. I
would expect that the new name where used in that file instead of
the old.
I would even expect the new name to be used everywhere in Emacs,
leaving the old obsolete name only to external
Lennart Borgman (gmail) wrote:
The variable above is marked as obsolete but used in font-core.el.
Should it be that way?
Obviously even obsolete variables have to be used _somewhere_, else
they are not just obsolete but totally useless. Can you elaborate on
your question?
Chong Yidong wrote:
This seems to be a limitation of the venerable mkinstalldirs program.
I wonder how other projects handle this problem?
We could replace the mkinstalldirs in Emacs with one from a recent
automake, which seems to have addressed this issue. But I think that
trying to use
Stephen Berman wrote:
customize-variable RET diary-display-hook' and in the Customize buffer
fixed.
customize-variable RET diary-header-line-flag', toggle it to `off' and
fixed.
typos in diary-lib.el: the docstrings of the defcustoms of
diary-header-line-flag and diary-header-line-format
Stephen Berman wrote:
Now your ~/.emacs file contains these lines:
(appt-activate 1)
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If
Richard Stallman wrote:
I agree that there is no reason not to put the usual scratch buffer
message into the scratch buffer. So I guess this change should be made.
Glenn, would you please install your startup.el patch?
done
___
Richard Stallman wrote:
That sounds like a larger change. Is your change a reversion of that
whole previous change, or just an adjustment of it?
The change was a large one. This was tiny, IMO incidental part of it.
It looks to me that you simply decided not to insert the initial
Oliver Scholz wrote:
The initial scratch message (from `initial-scratch-message') is missing
*iff* `desktop-save-mode' is on and at least one file is actually
visited automatically.
I belive this is because command-line-1 only inserts the
initial-scratch-message if the scratch buffer is
Here's a somewhat more tested patch. The problem in question is caused
by a change in the behaviour of try-completion between 21 and 22.
(try-completion foo '((foo) (foo)))
returns foo in 21, but t in 22. I don't know if this is a correct
interpretation of the doc-string's unique match which is
Richard Stallman wrote:
Ok, but I am still puzzled by one thing. I thought that the more
recent fix consisted of reverting the change you had previously made.
How come that didn't bring back the old bug?
Is it the case that the more recent fix did NOT revert your change?
In essence, Jan's
Oops, this has all been discussed on emacs-devel. Apologies for the
total time waste.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Chong Yidong wrote:
./configure --prefix=/local --x-libraries=/usr/X11R6/lib
--x-includes=/usr/X11R6/include --with-x-toolkit=yes
As an additional data point, it builds fine for me with these options
on Red Hat Enterprise Linux WS release 3 (Taroon Update 8).
Johan Bockgård wrote:
$ emacs -Q -l complete
Insert (defma )
Place point after a and run M-x PC-lisp-complete-symbol
= Wrong type argument: sequencep, t
How about the following patch? The 1+ part fixes a different bug that
seems to be present in 21.4 as well.
*** complete.el 03 Mar 2007
Glenn Morris wrote:
The 1+ part fixes a different bug that seems to be present in 21.4
as well.
Whoops, no it doesn't. I don't use partial completion, but it seems to
be pretty broken when one selects completion from a list.
___
emacs-pretest-bug
Glenn Morris wrote:
Glenn Morris wrote:
The 1+ part fixes a different bug that seems to be present in 21.4
as well.
Whoops, no it doesn't. I don't use partial completion, but it seems to
be pretty broken when one selects completion from a list.
This patch seems to do better, but is pretty
Fails for me in the same way on Solaris 10 with just:
./configure --with-gtk --with-xft
Problem seems to be that LIB_XFT on Solaris 10 does NOT include -lX11,
despite what it says in src/Makefile.in.
`pkg-config --libs xft' returns:
-R/usr/openwin/lib -R/usr/sfw/lib
Stefan Monnier wrote:
Yes, I saw that, but it's still not clear to me what's going on
here. E.g. the match any non-identifier char can match a
parenthesis, is that correct?
I guess a quick fix is to replace [^()] by [^()\n].
Ping, anyone in CC land?
The problematic [^()]* part was
Stefan Monnier wrote:
Please try and play with the text being matched to try and see which
part of the regexp is causing an overflow. Most likely the problem
is that something is matching a much longer text than expected (e.g.
tens/hundreds of nonempty lines rather than 1 or 2).
Maybe it's
From the top-level directory of a recent Emacs build:
./src/emacs -Q --eval (add-hook 'c-mode-hook 'imenu-add-menubar-index) \
./etc/splash.xpm
Error in menu-bar-update-hook: (error Stack overflow in regexp matcher)
___
emacs-pretest-bug
Chong Yidong wrote:
I can't reproduce this with the latest CVS sources:
GNU Emacs 22.0.93.23 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
I see the problem on x86_64-unknown-linux-gnu (RHEL 4), but not on
i686-pc-linux-gnu. (GNU Emacs 22.0.93.1, X toolkit in both cases.)
Do any other
I've reduced the problem to a regexp search called from:
(imenu--generic-function imenu-generic-expression)
Evaluating the following in a buffer visiting splash.xpm as text
causes a stack overflow in the regexp matcher:
(goto-char (point-max))
(re-search-backward
Chris Moore wrote:
I don't know if this has been reported before - it's a bug that I've
become so used to that I almost don't notice myself working around it
any more...
Ditto. I reported the issue with the very same manpage in May 2004:
Kenichi Handa wrote:
I've just updated all AIST copyright years.
It seems as if in every case, you just added every year from the first
copyright date to the present. This is not exactly how it is supposed
to work. The idea is, you should add every year where the file was
released with a
Kenichi Handa wrote:
The files who have copyright year before 1997 were released
every year as part of Mule package.
Ok. Sorry for the lecture you did not need, then.
They are integrated into Emacs in 1997. And Emacs were released in
1997, 1998, and 1999. So, perhaps I didn't have to add
Nick Roberts wrote:
PS Fun times ahead in 3 weeks when every single file in Emacs needs
2007 adding to the Copyright years...
Doesn't this make it a bit silly then to just to do it for 2006?
I'm not just doing it for 2006. I'm clearing up the mess (IMO) that
remains several months after
Kenichi Handa wrote:
years that I modified the code. But, AIST keeps copyright
for all continuous years. If we must list all years
explicitely in such a case, could you please update the lines
for AIST too?
I've done my best, but I would ask you to check the files where AIST
holds
Eli Zaretskii wrote:
There's not a single change that has been done in config.bat in the
years 2003 and 2005. maintain.texi says (in node Copyright
Notices):
To update the list of year numbers, add each year in which
you have made nontrivial changes to the package.
Changes to
Nick Roberts wrote:
And I thought we said that CC mode was added to Emacs in 1992, yet e.g
;;; cc-langs.el --- language specific settings for CC Mode
;; Copyright (C) 1985, 1987, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
;; 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software
;;
Thanks for checking on the ones I was unsure of.
Richard Stallman wrote:
ps-bdf.el should have all the from 2001 to 2006.
Do I update the years for AIST as well as FSF?
t-mouse.el was added in 2006 so it is correct.
It can't be correct. See my thread in emacs-devel.
If Rubini and
On this subject, was it ever decided whether 2001 (the year 21.1 was
released) should be added to all files that were present in Emacs at
that time? When we went through this copyright update process the
first time, sometimes it was added and sometimes it was not. Or is it
not important?
Richard Stallman wrote:
On this subject, was it ever decided whether 2001 (the year 21.1 was
released) should be added to all files that were present in Emacs at
that time?
Yes, it should be.
Marvellous. It is missing from a large number of files. I just fixed
lisp/*.el, which
Stefan Monnier wrote:
However, I had to comment out lazy-lock from my .emacs.
Why? (I mean, it's good that you did, but Emacs should still work
just fine with lazy-lock: i.e. should not have been forced)
I see the .el file is now is lisp/obsolete where it does not get
installed by default,
Nick Roberts wrote:
I updated copyright years in the progmodes directory (for 2005 and
2006). I might have overlooked 1992-2003 but I think I was
following guidance at the time - I can't remember. Discussion on
emacs-devel in 2005 about copyright years might shed some light.
Snippet from
Richard Stallman wrote:
Should things of the form 1992-2003 be expanded to every member
year?
That is an interesting question. I don't think CC mode was part
of Emacs during all those years. When did it become part of Emacs?
And what copyright years did it have then?
The CVS
Scrolling with the mouse in a buffer with lines wider than the window
(with truncate-lines enabled) is problematic. As an example:
emacs -q --no-site-file
Delete the newlines in the initial message in the scratch buffer (so
as to get a single long line of text wider than the window).
M-x
These files still have bad Copyright years:
Makefile.in
lisp/progmodes:
cc-align.el
cc-awk.el
cc-cmds.el
cc-compat.el
cc-defs.el
cc-engine.el
cc-langs.el
cc-menus.el
cc-mode.el
cc-styles.el
cc-vars.el
vhdl-mode.el
Should things of the form 1992-2003 be expanded to every member
year?
Eli Zaretskii wrote:
I would assume that M-x calendar must use the database directly to
find out _when_ DST starts and ends to print the calendar correctly.
It can do that, but it doesn't have to: it could alternatively pass
the corresponding time_t value to the time routines and get the DST
Here's a patch that works in the manner I have tried to describe. It
works with no noticeable slow-down on my (admittedly, fairly new)
machine. I can install if desired.
*** cal-dst.el 07 Feb 2006 23:46:47 -0800 1.24
--- cal-dst.el 09 Nov 2006 01:37:31 -0800
***
***
Eli Zaretskii wrote:
In C, you pass probe time_t values to the function localtime, until
you find the value for which the tm_isdst flag in the struct tm
returned by localtime changes from 0 to 1 or vice versa.
In Lisp, we will need some Lisp binding to localtime or its sibling
functions, to
Eli Zaretskii wrote:
No, Windows doesn't support Posix timezoneinfo data bases. It has its
own information in the Registry, which is usually (maybe always) only
for the current year.
Thanks. I'm not surprised it's different...
I guess, if Emacs needs the timezone database, we could
James Cloos wrote:
As you can see from that output America/Phoenix has not done daylight
time since 1944 (US wartime national Mandate).
Ah, thank you again for enlightenment!
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Richard Stallman wrote:
I would assume that M-x calendar must use the database directly
to find out _when_ DST starts and ends to print the calendar
correctly.
I guess that is true, for the sake of the holiday display.
Given a way to check any given time for DST, it would not
T. V. Raman wrote:
while fixing this bug, it might be appropriate to update calendar
for next march -- when the US switches back to daylight saving time
in mid-March (was legistlated earlier this year)
The fact that it is _already_ using the new rules is the source of
this problem. Rather, it
Thanks for the report. I've installed a fix.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I've discovered that removing the line in mouse-set-region-1 that
turns on transient-mark-mode makes the problem go away, but I'm just
flailing around...
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Hezi Gildor wrote:
emacs -Q file.f
I drag the mouse to highlight a region
mouse-1- fortran-comment region
error message: mark is not active now
if I do set-mark using ctrl-@ or such, then use arrows to highlight a
region, then use the mouse to do comment region, it works fine.
The
Stefan Monnier wrote:
Should be fixed now,
The latest sh-script.el correctly fontifies everything I throw at it
so far. Many thanks; I found this bug quite annoying.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Stefan Monnier wrote:
#!/bin/bash
gbytes=`echo $bytes_total | gawk '{printf(%5.1f), $1 / (1024^3)}'`
echo The time is now `date`
This was messed up already a month ago, right? I.e. it's not related to my
recent changes?
Yes, this was broken by the changes in rev 1.181.
Stefan Monnier wrote:
Well, I believe the one I just installed does fix it, this time.
It fixes the previously posted example, but now this snippet is messed
up:
#!/bin/bash
gbytes=`echo $bytes_total | gawk '{printf(%5.1f), $1 / (1024^3)}'`
echo The time is now `date`
Stefan Monnier wrote:
This was messed up already a month ago, right? I.e. it's not related
to my recent changes?
Oh, could be. I just got back from vacation, so my previous version of
the CVS was a few weeks old. I'll check and see when this stopped
working...
Stefan Monnier wrote:
I believe the patch below (just installed) fixes it,
Sorry, but the patch has no effect on this case AFAICS.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
The (unintended?) change to sh-font-lock-keywords-1 in rev 1.182 of
sh-script.el breaks font-locking, eg of bash scripts:
emacs -q --no-site-file
M-x sh-mode
then type export
- Error during redisplay: (error No match 4 in highlight (4
font-lock-builtin-face))
Reverting from (4
Stefan Monnier wrote:
Thanks. I've reverted it. It's actually a patch I had suggested
(mistakenly as I know see) and was waiting for confirmation that it
fixes another bug. So, back to that other bug,
Thanks. I get the impression (catching up on emacs mailing lists) you
are trying to fix
Drew Adams wrote:
M-x customize-variable appt-display-format
The standard value is `ignore', and this is a mismatch (`ignore' is
not a valid value).
This is by design. ignore is a special value, meaning fall back on the
previous (now obsolete) way of doing it, which used different
variables.
Sorry, I did not read carefully enough the first time. I see custom
barfs if I have a default value which is not in the allowed value
list. I guess I will have to add 'ignore to the allowed value list. I
wanted to avoid this because I specifically wanted people to have to
choose any of the other
I think this is fixed now.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
1 - 100 of 129 matches
Mail list logo
