Lars Hansen <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
> > By the way, here is what ./configure --with-gtk shows. Note all the "none"
> > and "no" items that were previous all "yes" or something good.
> >
> I am no expert on t
Fixed. I found that configure looks for X11/Intrinsic.h. This file was
no longer present on my system, so the upgrade must have relocated it
into a separate package, which I found is libxt-dev. After installing
the libxt-dev package (on Debian etch), the output of configure looks
reasonable and Ema
By the way, here is what ./configure --with-gtk shows. Note all the "none"
and "no" items that were previous all "yes" or something good.
Configured for `i686-pc-linux-gnu'.
Where should the build process find the source code?
/usr/local/src/mh-e/src/emacs
What operating system and machine d
*** [bootstrap-build] Error 2
make[1]: Leaving directory `/home/usr.local.src/mh-e/src/emacs'
make: *** [bootstrap] Error 2
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bill Wohler <[EMAIL PROTECTED]> writes:
> Lars Hansen <[EMAIL PROTECTED]> wrote:
>
>> Stefan Monnier wrote:
>>
>> >>! `(let ((,temp-buffer (generate-new-buffer " *temp*"))
>> >>!(buffer-undo-list t))
>> >
e have their undo disabled by default.
> >I.e. someone thought of that years ago already,
> >
> >
> Then my previous patch can be simplified.
> Any objections?
None from me. I've applied it and will let you know how it goes. Thanks.
--
Bill Wohler <[EMAIL PRO
7;ll apply Richard's patch.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
___
here any reason to keep this buffer hanging around
> consuming some memory and being user visible?
Thanks, Luc. This exact thought coursed through my mind. Would Mr.
Desktop please chime in?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of co
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
>
>By the way, the only two desktop-related items in my .emacs are turning
>on desktop-save-mode (which is probably obvious ;-) and this:
>
> (run-at-time 60 300 'desktop-save "~")
ob" *I've* set up.
Still, I think Stefan might be correct. What does it mean to have undo
in the *desktop* buffer in the first place?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you
g snarky, I said "no" and
> Emacs crashed.
>
> Could you please provide the precise text of the message?
> The message includes a buffer name; what is the buffer name?
OK, it's back. Here's the message:
Buffer `*desktop*' undo info is 3159101 bytes long;
g snarky, I said "no" and
> Emacs crashed.
>
> Could you please provide the precise text of the message?
> The message includes a buffer name; what is the buffer name?
I haven't seen the prompt in a couple of days. Could a recent update
have suppressed it?
--
Bill Wo
Emacs complained about these local variables after a fresh update (it's
been a couple of weeks):
;; no-byte-compile: t
;; indent-tabs-mode: nil
I thought these had been made safe.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.
(popup-menu menu-bar-help-menu))
-'help
-:help "Pop up the Help menu")
+ (tool-bar-local-item "help" (lambda ()
+(interactive)
+(popup-menu menu-bar
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
>
>Weird, a copy of the message was *not* saved in the *Messages* buffer.
>
> It is not a message, but a yes-or-no-p prompt.
Oh, right. Duh.
Not the first time I've said something stupid before coffee
g snarky, I said "no" and
> Emacs crashed.
>
> Could you please provide the precise text of the message?
> The message includes a buffer name; what is the buffer name?
Weird, a copy of the message was *not* saved in the *Messages* buffer.
I'll write it down
Bill Wohler <[EMAIL PROTECTED]> writes:
> Every morning for the past weeks, I've had a message in my minibuffer
> that roughly goes, "Desktop undo buffer is 3+ MB, discard? (yes or no)".
> I've been saying "yes". This morning, feeling snarky, I said &
p undo buffer" by the way? And why does Emacs keep
asking me this question?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
let it go.
My (last) patch still seems to be working well for me. Is anyone else
observing this problem that can verify the patch? If not, does anyone
object if I try checking it in so we can see if it causes problems for
others? (Does anyone on this list use tool bars? ;-)
--
Bill Wohler <[E
't see the problem.
You can reproduce with "emacs22 -Q --xrm Emacs.toolBar:0".
Is this a corner-case we wish to fix? I think so.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you&#x
Bill Wohler <[EMAIL PROTECTED]> wrote:
> emacs22 -Q
> M-x info
> M-x tool-bar-mode
>
> Note how Preferences and Help icons are present.
>
> C-x b *scratch* RET
>
> Note how Preferences and Help icons are absent.
>
> To see what should have happe
ps))
+ (apply 'tool-bar-local-item icon def key (default-value 'tool-bar-map)
props))
;;;###autoload
(defun tool-bar-local-item (icon def key map &rest props)
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh F
em. The files that shouldn't
be byte-compiled are no longer byte-compiled.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're p
?
Ah, now I see what happened and I found the bug. I was actually being
asked for another variable in the same Local Variables stanza. If you
add the following to a file, make recompile will compile it:
;; Local Variables:
;; no-byte-compile: t
;; url-unreserved-chars: nil
;; End
--
Bill Wohler <
thing the MH-E package should be doing differently now?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you'
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
>
>If an update doesn't resolve the problem, please remove
>lisp/mh-e/*.elc and try again.
>
> All of that is apparently not sufficient to solve the problem. Still
> same error messa
ake[2]: Leaving directory `/home/brep/emacs-source/emacs-unicode-2/lisp'
> make[1]: *** [bootstrap-build] Error 2
> make[1]: Leaving directory `/home/brep/emacs-source/emacs-unicode-2'
> make: *** [bootstrap] Error 2
Fixed. Apologies.
If an update doesn't resolve the problem
obably should postpone creating different widgets for menus
and comboboxes until after the release.
> It is a bad idea for the closed state of a menu to
> represent one of the possible menu choices.
True, but you'd use a combobox widget in this case and it doesn't
apply to the State
I was
thinking along the same lines too, but was too timid to go up a function
call.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you'r
Bill Wohler <[EMAIL PROTECTED]> writes:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
>> signal(error ("Font-lock trying to use keywords before setting them up"))
>> error("Font-lock trying to use keywords before setting them up")
>>
Richard M. Stallman <[EMAIL PROTECTED]> wrote:
> Is this the usual way of injecting one's keywords?
>
> You don't want to start injecting keywords.
> What if you got addicted to them?
I'd probably get to know font-lock a lot more than I do now.
--
Bill
y-buffer calls
font-lock-set-defaults, it seems that font-lock-default-fontify-region
should as well, thereby fixing the problem.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail
Bill Wohler <[EMAIL PROTECTED]> writes:
> signal(error ("Font-lock trying to use keywords before setting them up"))
> error("Font-lock trying to use keywords before setting them up")
> font-lock-compile-keywords(nil t)
> font-lock-fontify-keywords-
-add-sequence-notation(1 t)
mh-notate-user-sequences()
mh-regenerate-headers(("all"))
mh-scan-folder("+tmp/laptops" "all")
mh-visit-folder("+tmp/laptops" "all")
call-interactively(mh-visit-folder)
OK, that's better, thanks! I stil
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> On closer look, it appears that the error can be triggered both at
> compile and at run time (because the keywords can be compiled at run
> time).
Thanks for looking...
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohle
Bill Wohler <[EMAIL PROTECTED]> writes:
> Can you guys take a quick peek and see if you see anything obvious? If
> not, I'll debug this.
I didn't see anything obvious, but I'm not intimately familiar with
the font-lock stuff. mh-visit-folder contains this:
(mak
fontification on a non-font-lock buffer.
>
> I've added a sanity check in font-lock-compile-keywords which should at
> least catch the offenders before they wreak havoc (hopefully the offenders
> are not font-lock itself).
This error was not triggered when I visited a folder in MH-E.
rst chapter of the MH-E manual--even the old one that is
currently in Emacs--is a tutorial which will help you do this.)
I've opened an MH-E bug #1393879 on this:
https://sourceforge.net/tracker/index.php?func=detail&aid=1393879&group_id=13357&atid=113357
--
Bill Wohler <[EMA
reproduce this bug with `emacs -Q'. Do you have a
> special font-lock configuration in .emacs, like calling
> `(font-lock-turn-on-thing-lock)' directly on non-font-lock buffers
> or something like that?
Nope, that setting above is the only hit for "font" in my load
again, the fonts are OK.
If I quit Gnus, run:
(set-default 'font-lock-keywords '(t nil))?
And then fire up Gnus again, the fonts are again AWOL. Who's calling that?
Is that enough information to find the culprit, or is there a watch I
can put on the global value of font-lock
Richard M. Stallman <[EMAIL PROTECTED]> wrote:
> I think I fixed this. Does it work now?
Yes, thanks!
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the
I tried to debug the problem by adding an --eval
'(toggle-debug-on-error)' and loaddefs.el were created!
Weird.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on
bolp, 0
make: *** [autoloads] Error 255
I see this change. Related?
2005-12-25 Richard M. Stallman <[EMAIL PROTECTED]>
* eval.c (un_autoload): Expect (0 . OFEATURES) in Vautoload_queue
to undo a `provide'.
* fns.c (Fprovide): Store (0 . OFEATU
ocs/doc/devguide.texi
% *info* 290114 Info
* *Messages*1576 Fundamental
% *Completions* 199 Completion List
* *desktop* 4791 Fundamental
*MH-E Log* 0 Fundamental
% *Occur* 537 Occur
% show-+inbox
in
*Help* buffers.
I think it was last week where I didn't observe this behavior at all.
Hard to say if I got lucky, or whether there was a good change a week
before that and a bad change this week. But it's what I observed.
Sorry, this is so sporadic that I haven't been able to generate
Romain Francoise <[EMAIL PROTECTED]> writes:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
>> Was this patch expected to fix the broken Gnus highlighting me and
>> others have reported?
>
> No, we fixed this one on November 24th.
This bug (Gnus losing its highli
url-history.el (url-history-track):
Call url-history-setup-save-timer in :set function.
:type allows three alternatives.
(url-history-setup-save-timer): Test url-history-track.
* url.el (url-retrieve): Test url-history-track.
--
Bill Wohler <[EMAIL PROTECT
Romain Francoise <[EMAIL PROTECTED]> wrote:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
> > Was this patch expected to fix the broken Gnus highlighting me and
> > others have reported?
>
> No, we fixed this one on November 24th.
That explains why
rticle*
buffers!
By the way, I haven't noticed the broken highlighting in the last
week. Maybe something got fixed. Maybe I've gotten lucky. I don't know.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH
mand not to call pop-to-buffer.
> >>
> >> I'll install a patch for it, thanks.
> > Thank you.
>
> Does the patch below solve the problem?
Yes, thanks.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of c
op-to-buffer.
>
> I'll install a patch for it, thanks.
Thank you.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
___
Twilight zone. I could have sworn that `e' of buffer-file-name before
the call showed the file name and an `e' of buffer-file-name after the
call showed nil but now I find that it was a different problem which I
was able to fix.
Here is the patch which I just checked in and ChangeLog entry w
e-name-handler is down in C which is beyond my ability to
debug. But the recipe is:
1. emacs -q
2. Visit a file that is under revision control and owned by someone
else (in my case /etc/network/interfaces is owned by `root' and is
checked into Subversion and I'm trying t
update the MH-E manual accordingly.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
___
emacs-
r to
highlight? If minibuffer-completing-file-name is nil, then the
highlighting is one character to the right of where it should be.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertari
can reproduce it, I will. Perhaps it is tickled by
something odd in the desktop file, much like some buffer causes the Gnus
buffers not to highlight properly (at least we know in that case it's a
buffer that uses hilite (?)).
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler
Satyaki Das <[EMAIL PROTECTED]> wrote:
> On 12/7/05, Bill Wohler <[EMAIL PROTECTED]> wrote:
>
> > In the code below, if I comment out the setting of
> > minibuffer-completing-file-name, the space again performs completion and
> > I can't discern any
-completion-map mh-folder-completion-map)
(mh-allow-root-folder-flag allow-root-folder-flag))
(completing-read prompt 'mh-folder-completion-function nil nil nil
'mh-folder-hist default))
t))
--
Bill Wohler <[EMAIL PROTECTED]> http://ww
-file-name t)
(completion-root-regexp "^[+/]")
(minibuffer-local-completion-map mh-folder-completion-map)
(mh-allow-root-folder-flag allow-root-folder-flag))
(completing-read prompt 'mh-folder-completion-function nil nil nil
w at the
bottom saying to use C-l to start editing. The coincidence is that this
small window is also three lines and is accompanied by the same light
show as I mentioned above.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh F
7;d feel better if someone else who could articulate the reason in the
ChangeLog better checked this in.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you&
I don't recognize the author "gm", but I'm pretty sure it's not me :-).
Ooops ;-).
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you&#x
n't allow any compiler errors in MH-E so that any
real error stands out like a sore thumb rather than being hidden in a
forest. I'd encourage this convention for the Emacs project as a whole.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
>
>Also, why does the same code work in Emacs 21 and not in Emacs 22?
>
> I believe that I answered this in an earlier reply, but maybe you had
> not yet read that reply when you asked this.
Yes, that
ork in Emacs 21 and not in Emacs 22?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
_
Romain Francoise <[EMAIL PROTECTED]> writes:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
>> apropos-score-symbol: Symbol's value as variable is void: apropos-regexp
>
> This use had escaped the renaming to `apropos-pattern', I fixed it.
> Thanks.
Confi
Bill Wohler <[EMAIL PROTECTED]> writes:
> I've found a problem where my mh-letter-mode-hook (in MH-E) isn't
> getting called. It is listed properly in the custom-set-variables
> stanza, but when I start Emacs, load MH-E, and run customize-option on
> mh-letter-mode-hoo
/drafts/5
Sending...backgrounded
inc +inbox...done
Fontifying show-+inbox... (regexps......)
Quit
Loading emacsbug...done
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
lp-mode...done
apropos-score-symbol: Symbol's value as variable is void: apropos-regexp
Mark set [2 times]
Loading emacsbug...done
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you&#x
Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Bill Wohler wrote:
>
>With today's CVS, the font in the menu bar got really small and the
>background went white. Is anyone else seeing this?
>
> Not me.
Thanks, Luc. I just discovered my error: I forgot to a
With today's CVS, the font in the menu bar got really small and the
background went white. Is anyone else seeing this?
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're pas
Bill Wohler <[EMAIL PROTECTED]> writes:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
>>
>>>> Make a buffer with this content:
>>>
>>>> In-reply-to: "foo bar" of Fri, 15 Ju
Bill Wohler <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>>> Make a buffer with this content:
>>
>>> In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
>>>
>>
>>> (2 lines only)
o-char (if (equal point data-end) (1+ data-end) data-end))
> t)))
>
> As you can see, this function sometimes returns non-nil (i.e. it says it's
> found a match) but with no begin/end of match 0.
Thanks for pointing this out. That should make it easy for us to fix.
--
Bi
Richard Stallman <[EMAIL PROTECTED]> wrote:
> I'll fix the warnings in the MH-E package unless you've already done
> so.
>
> Thanks.
I just checked MH-E version 7.84 into CVS Emacs. All of the files in the
package compile without warning.
--
Bill Wohl
Richard Stallman <[EMAIL PROTECTED]> writes:
> I will fix most of the rest now.
I'll fix the warnings in the MH-E package unless you've already done
so.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ a
76 matches
Mail list logo
