With symbol-at-point however, I intend to drop the
(if thing (intern thing))
form when called.
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?
___
em
My .gnus contains:
(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, bu
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-
[...]
> 1.36 (monnier 04-Jul-06): (if thing (intern thing
[...]
>
> 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
> | f
Here's a patch to fix this. It adds a newline to the end of the man
page whether or not there's one there already.
Chris.
On Fri, 2006-10-13 at 16:29 +0200, Chris Moore wrote:
> If a man page doesn't have a terminating newline, then M-x woman RET
> RET will go into an infinite loop.
>
> For ex
Chris Moore <[EMAIL PROTECTED]> writes:
> Here's a patch to fix this. It adds a newline to the end of the man
> page whether or not there's one there already.
I checked in a different fix some time ago.
> Chris.
>
> On Fri, 2006-10-13 at 16:29 +0200, Chris Moore wrote:
>> If a man page doesn't
>> >> My point was simply if you stay 100% within multibyte, it all works,
>> >> and if you stay 100% in unibyte it all works
>>
>> > The former is true, the latter isn't, AFAIK. ``Normal'' Emacs
>> > primitives and subroutines always do TRT with multibyte strings, while
>> > with unibyte you nee
>> ,[ 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'.
>> |(thi
Try C-x v ~ 1.35 to see the code before my change (or try C-x v = to
see the diff between 1.35 and 1.36). You'll see that the previous code
returned a symbol, not a string.
Silly me. I stubbornly decided the previous code returned a string
built from word and symbol constituents. Apologies
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Tue, 24 Oct 2006 11:22:51 -0400
>
> I'm not quite sure what is a "unibyte session"
A.k.a. "emacs --unibyte".
> but I think "stay 100% in
> uniby
Does this work right?
*** dired.el01 Oct 2006 23:09:50 -0400 1.352
--- dired.el24 Oct 2006 07:52:31 -0400
***
*** 791,796
--- 791,798
(run-hooks 'dired-before-readin-hook)
(if (consp buffer-undo-list)
(setq buffer-undo-list nil))
+
> It works correctly, provided the characters in that string can be
> expressed in the unibyte buffer.
But which characters can be expressed is poorly specified. E.g. Tell me
which chars can be expressed in a unibyte buffer in a BIG5 locale?
Mentioning the locale is somewhat of a
>> I'm not quite sure what is a "unibyte session"
> A.k.a. "emacs --unibyte".
I know that, but I'm not quite sure what it entails. This discussion is
within the scope of code such as Gnus's, i.e. code which should work
either way.
>> but I think "stay 100% in
>> unibyte" is fairly clear: only us
>> It works correctly, provided the characters in that string can be
>> expressed in the unibyte buffer.
> But which characters can be expressed is poorly specified. E.g. Tell me
> which chars can be expressed in a unibyte buffer in a BIG5 locale?
> Mentioning the locale is somewhat of a
Chong Yidong <[EMAIL PROTECTED]> writes:
> After some trial and error, I propose the following patch. I have
> verified that it makes the reported bug go away. Does anyone disagree
> with it?
Thanks, I tested this patch, and it solved the "freeze". But I noticed that
when point was over any of
Ok, I start up Gnus. Now, if I view an article by hitting RET
(`gnus-summary-scroll-up') on it in *Summary*, I get the following
behavior:
- as long as there are visible headers (Subject, From, etc.) on top of
the buffer, pressing RET scrolls exactly one line as it should be.
- when the l
Kenichi Handa <[EMAIL PROTECTED]> writes:
> That makes too many unnecessary calls of `kinsoku'. I've
> just installed a fix of the different way. Could you please
> try with the latest code?
The `kinsoku' processing works great now, but `nospace-between-words'
still doesn't work for:
(set-lang
I've recently switched my kernel from i686 to amd64 without changing the
rest of my system (so all programs use the compatibility x86 mode).
This seems to work just fine overall, except that Emacs gets confused and
thinks my `long' are 64bit wide.
This apparently comes from the use of `uname' in `
Stefan Monnier <[EMAIL PROTECTED]> writes:
> This apparently comes from the use of `uname' in `configure' which tells I'm
> running an x86-64 machine (aka amd64) and thus includes m/amdx86-64.h which
> says that `long' is 64bit.
Hmm, shouldn't configure just be using AC_CHECK_SIZEOF(long) instead
19 matches
Mail list logo
