Glenn Morris | 1 Apr 02:07 2011
Picon

bug#8392: Diary entries does not work with ISO date format


> I have configured my .emacs file to use ISO dates format

No you haven't. The only relevant setting in your attached .emacs is one
for calendar-date-display-form. This just affects how dates are
*displayed*, nothing else. There are other things you need to set,
notably diary-date-forms. But don't bother setting either of those by
hand, just customize calendar-date-style to `iso' instead. That will set
all the necessary variables.

> , but when I check for diary entries (throw 'd' option of calendar) I
> get "No diary entries for <date>". I attach my .emacs file and a sample
> diary file. Inserting new entries in the diary file to the calendar ('i
> d' option) writes the data in the correct format (ISO), so I guess that
> must be a problem in the diary interpretation by the calendar.
>
> Severity: normal
> In GNU Emacs 23.3.2 (x86_64-unknown-linux-gnu)
>  of 2011-03-30 on tambre

Glenn Morris | 1 Apr 02:25 2011
Picon

bug#8398: 24.0.50; info-mode adding spurious "see" to <at> ref links

Jason Earl wrote:

> For more information on info itself you can read
>  <at> iftex
>  <at> cite{Info: An Introduction}.
>  <at> end iftex
>  <at> ifnottex
>  <at> ref{Top, , Info, info, Info: An Introduction}.
>  <at> end ifnottex
>
> The info file produced, and it looked fine in the info client.
>
>    For more information on info itself you can read *note Info:
> (info)Top.
>
> However, in Emacs' info-mode it looks like this:
>
>    For more information on info itself you can read *note Info:
> (info)Top.
>
> Essentially it replaced the *note with the word "see" which makes the
> sentence read funny.

I think you mis-typed your second example...

The behaviour is customizable through Info-hide-note-references.

The elisp intro does not say "you can read", so looks OK IMO:

   This introduction to `Programming in Emacs Lisp' has a companion
(Continue reading)

David De La Harpe Golden | 1 Apr 02:44 2011
Picon

bug#8400: 24.0.50; Strange selection behavior in Gnus Article buffer

On 31/03/11 23:05, Stephen Berman wrote:
> 1. emacs -Q
> 2. Carry out the steps in NEWS to return to the pre-24 selection behavior:
>     Change `mouse-drag-copy-region' to t.
>     Change `x-select-enable-primary' to t.
>     Change `x-select-enable-clipboard' to nil.

Please try:

(setq select-active-regions nil
       mouse-drag-copy-region t
       x-select-enable-primary t
       x-select-enable-clipboard nil)
(global-set-key [mouse-2] 'mouse-yank-at-click)

I'm not saying there isn't a real issue, what you describe does sound a 
bit similar to a problem that occasionally occurred with the new 
settings (without any changes to them) a while back, but please try with 
the above settings, which are AFAIK still* (whatever the NEWS file may 
currently say) the actual current recipe to restore the old behaviour 
(except on windows) - if you only did precisely what you said in your 
2., then AFAIK you were running with a doom-laden mix of old and new 
settings.

* bearing in mind I'm only beginning a personal catchup on about 3½ 
months of emacs developments.

Stefan Monnier | 1 Apr 03:01 2011
Picon

bug#8399: 23.3; save-some-buffers ignores buffer names

> The attached patch (on Emacs-23 head) modifies the dialogue so that
> file-names are used in the dialogue only when they coincide with the
> buffer names.  Otherwise, buffer names are used preferentially.

I think the file-name is only useful when you have buffer "file",
"file<2>", "file<3>", ... so your check is going in the right direction
but it should also use file-name when the buffer name matches
(concat "\\<" (regexp-quote (file-name-nondirectory buffer-file-name))
"<[0-9]+>\\'"), and it should never use file-names when uniquify
is used.
IMNSHO,

        Stefan

Paul Eggert | 1 Apr 08:47 2011

bug#8401: removing duplication and improving the readlink code

In two places Emacs calls readlink with similar code to reallocate
buffers until there's enough room to store the symbolic link's value.
And in both places there are minor problems with overflow, since Emacs
uses 32-bit int where modern 64-bit systems use 64-bit ssize_t, and it
doesn't check for overflow in buffer size calculations.  These
problems cause GCC to complain, if warnings are enabled.  I plan to
fix the problems with the following patch, which substitutes a gnulib
implementation of the same basic readlink idea; this implementation
does more-careful buffer size checking, and makes it possible to
avoid the malloc+free in the usual case.

This patch adds a couple of dependencies so it may affect the
Windows build.

The full patch (including autogenerated files) is attached as
a compressed file.

=== modified file 'ChangeLog'
--- ChangeLog	2011-03-28 01:03:57 +0000
+++ ChangeLog	2011-04-01 06:28:48 +0000
 <at>  <at>  -1,3 +1,10  <at>  <at> 
+2011-04-01  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Replace two copies of readlink code with single gnulib version.
+	* Makefile.in (GNULIB_MODULES): Add careadlinkat.
+	* lib/allocator.h, lib/careadlinkat.c, lib/careadlinkat.h:
+	* m4/ssize_t.m4: New files, automatically generated from gnulib.
+
 2011-03-28  Glenn Morris  <rgm <at> gnu.org>

(Continue reading)

Eli Zaretskii | 1 Apr 09:55 2011
Picon

bug#8398: 24.0.50; info-mode adding spurious "see" to <at> ref links

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Thu, 31 Mar 2011 20:25:43 -0400
> Cc: 8398 <at> debbugs.gnu.org
> 
> > However, in Emacs' info-mode it looks like this:
> >
> >    For more information on info itself you can read *note Info:
> > (info)Top.
> >
> > Essentially it replaced the *note with the word "see" which makes the
> > sentence read funny.
> 
> I think you mis-typed your second example...

No, he copy/pasted it from Emacs, and therefore the original text
replaced by Emacs display wizardry reappeared...

> Personally I think your "you can read  <at> ref" is not really Texinfo style (?),
> which is why the result looks a bit odd.

Indeed, that's bad Texinfo and should be fixed.

Eli Zaretskii | 1 Apr 10:33 2011
Picon

bug#8401: removing duplication and improving the readlink code

> Date: Thu, 31 Mar 2011 23:47:14 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>
> 
> In two places Emacs calls readlink with similar code to reallocate
> buffers until there's enough room to store the symbolic link's value.
> And in both places there are minor problems with overflow, since Emacs
> uses 32-bit int where modern 64-bit systems use 64-bit ssize_t, and it
> doesn't check for overflow in buffer size calculations.  These
> problems cause GCC to complain, if warnings are enabled.  I plan to
> fix the problems with the following patch, which substitutes a gnulib
> implementation of the same basic readlink idea; this implementation
> does more-careful buffer size checking, and makes it possible to
> avoid the malloc+free in the usual case.

Isn't much easier and much more elegant to use ssize_t instead of an
int for the buffer sizes in both cases?

> This patch adds a couple of dependencies so it may affect the
> Windows build.

If this patch is accepted, the new emacs_readlink function will be a
trivial "fail" stub on Windows.  I don't see a need to compile in all
this gnulib code just to return NULL because readlink always fails.

Stephen Berman | 1 Apr 10:48 2011
Picon
Picon

bug#8400: 24.0.50; Strange selection behavior in Gnus Article buffer

On Fri, 01 Apr 2011 01:44:13 +0100 David De La Harpe Golden <david <at> harpegolden.net> wrote:

> On 31/03/11 23:05, Stephen Berman wrote:
>> 1. emacs -Q
>> 2. Carry out the steps in NEWS to return to the pre-24 selection behavior:
>>     Change `mouse-drag-copy-region' to t.
>>     Change `x-select-enable-primary' to t.
>>     Change `x-select-enable-clipboard' to nil.
>
> Please try:
>
> (setq select-active-regions nil
>       mouse-drag-copy-region t
>       x-select-enable-primary t
>       x-select-enable-clipboard nil)
> (global-set-key [mouse-2] 'mouse-yank-at-click)
>
> I'm not saying there isn't a real issue, what you describe does sound a bit
> similar to a problem that occasionally occurred with the new settings (without
> any changes to them) a while back, but please try with the above settings,
> which are AFAIK still* (whatever the NEWS file may currently say) the actual
> current recipe to restore the old behaviour (except on windows) - if you only
> did precisely what you said in your 2., then AFAIK you were running with a
> doom-laden mix of old and new settings.

You're right.  So this is a -- rather insidious -- NEWS bug; fix below.
Thanks for setting me straight.

Steve Berman

(Continue reading)

Uday S Reddy | 1 Apr 10:39 2011
Picon
Picon

bug#8399: 23.3; save-some-buffers ignores buffer names

Stefan Monnier writes:

> I think the file-name is only useful when you have buffer "file",
> "file<2>", "file<3>", ... so your check is going in the right direction
> but it should also use file-name when the buffer name matches
> (concat "\\<" (regexp-quote (file-name-nondirectory buffer-file-name))
> "<[0-9]+>\\'"), and it should never use file-names when uniquify
> is used.

Thanks Stefan.  I didn't think of the file<n> case.  I will submit a
revised patch.  Is uniquifying file-names something that Emacs does?
Or, were you just referring to the VM's cache folder names?

Cheers,
Uday

Steve Purcell | 1 Apr 12:01 2011

bug#8402: 24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)

Hi,

If I set face colors using hex values, those colors are not displayed
correctly.

For example, 'M-x set-face-background RET default RET #fdf6e3 RET'
results in a frame background color which, when sampled using Apple's
"Digital Color Meter" utility, has hex value #fff8e8.

And, in fact, all colors are apparently skewed similarly, while other
Cocoa apps (e.g. iterm2) render them correctly.

To give an example from out in the field, here is a screenshot of a
color theme as rendered by Emacs: http://dropup.net/lz64u0ctpcge.png.html

and here is how those same colors would look if they were rendered
correctly:

http://ethanschoonover.com/img/solarized/solarized-screen-pandoc-dark.png

Note the significant difference in the background color, for instance.

Could it be that Emacs needs to hook into system-provided color
management routines on this platform in order for its colors to be
correctly calibrated?

-Steve

In GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
of 2011-03-20 on black.porkrind.org
(Continue reading)


Gmane