headers
Miles Bader | 1 Aug 2007 05:04
Picon
Gravatar

Re: message.el user References control

On 7/26/07, jidanni <at> jidanni.org <jidanni <at> jidanni.org> wrote:
> I mean hardwiring any number without a defvar alternative should raise
> a red flag anyway.

Good point.

> Anyway, thanks for your persistence in this matter. Farther than I got
> last time just posting to bugs <at> gnus.org.

I'm not sure that anyone actually reads bugs <at> gnus.org -- every bug
report I send there seems to be entirely ignored...

-miles
--

-- 
Do not taunt Happy Fun Ball.
Permalink | Reply | 1 comment |
headers
Tom Rauchenwald | 1 Aug 2007 05:22
Picon
Gravatar

Re: unicode-2 branch: ^O goes missing

Kenichi Handa <handa <at> m17n.org> writes:

> In article <E1IDoSt-0001rV-Lc <at> walter>, Tom Rauchenwald <its.sec <at> gmx.net> writes:
>
>> To reproduce:
>> Create an empty File.
>> Do C-q C-o in it. A sequence that looks like ^O should appear.
>> Save the File and kill the buffer.
>> Open the file again. ^O is not there anymore.
>> With emacs22 this works.
>
>> Background is that i tried a elisp-program that parses color-sequences in IRC, and tried to match ^O, but
with the unicode-2 branch this doesn't work anymore because the ^O goes missing somewhere.
>
> ^O is a locking shift code of ISO-2022, and iso-2022
> detector of emacs-unicode-2 was too strong compared with
> that of Emacs 22.  I've just installed a fix.
>
> But, it is in general safer to specify a proper coding
> system (in your case, iso-safe or no-conversion?) if you are
> reading a file that contains some binary data (for instance
> by let-binding coding-system-for-read).  Another way is to
> let-bind inhibit-iso-escape-detection to t.

Okay, I rebuilt Emacs, and everything is fine now.

Thanks again,

Tom
(Continue reading)

Permalink | Reply | 0 comments |
headers
Per Abrahamsen | 1 Aug 2007 18:19
Picon

Re: no doc for `group' in custom :type

Basically, there are two "levels" of widgets.  The low level widgets
which provide the "inline form editing functionality" and the sexp
widgets which are suposed to represent Lisp s-expressions.  The sexp
widgets are build on top of the low level widgets.

In theory, if you are building a form where the data represents
something other than s-expressions, you should use the low level
widgets, while if what you are building is some textual representation
of s-expressions you should use the sexp widgets.

The custom types, by nature, always represent sexps.  So only the sexp
expressions should be used.

In practise, the distinction is muddy, as the low level widgets
naturally also must use s-expressions to hold their value.  So
whatever looks best tend to be used.

The group widget is a low level widget that represent allows you to
handle a group of widgets as a single widget.  The value of the group
widget is represented as a list whose members are the values of the
child widgets.  Which happens to be exactly the same as how the "list"
widget represent its value.  So the two are almost identical.

The difference is in the :format attribute, one of them shows both the
tag and the value, while the other does not.  I don't remember which
is which.

On 7/30/07, Richard Stallman <rms <at> gnu.org> wrote:
> Do you remember what the custom type `group' is for?  I would like to
> document it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Schlauer | 1 Aug 2007 22:54
Picon
Favicon

Re: BibTeX-mode: Key generation when latin-1 characters appear in author field

[Crossposting to gmane.emacs.auctex.devel where RefTeX is maintained
now]

The following is from a discussion in 2005, starting with
<http://article.gmane.org/gmane.emacs.pretest.bugs/6843>, where I wrote:

> I create the following entry in a BibTeX file -- the critical thing is
> that the name of the author contains an umlaut. (This is okay, as the
> BibTeX versions that nowadays come with TeX distributions are 8-bit
> capable, which means that I can enter umlauts in the .bib file
> directly instead of using \"o or something similar -- I just have to
> specify \usepackage[latin1]{inputenc} in the document preamble as
> well):
>
>  <at> Article{,
>   author = 	 {B. Blöd},
>   title = 	 {Test},
>   journal = 	 {A},
>   year = 	 {2005},
>   OPTkey = 	 {},
>   OPTvolume = 	 {},
>   OPTnumber = 	 {},
>   OPTpages = 	 {},
>   OPTmonth = 	 {},
>   OPTnote = 	 {},
>   OPTannote = 	 {}
> }
>
> Now, press `C-c C-c' inside the entry -- Emacs suggests `blöd05:_test'
> as the key to use
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 2 Aug 2007 18:25
Picon

Re: BibTeX-mode: Key generation when latin-1 characters appear in author field

>> text-mode:            Grüß Gott
>> tex-mode:             Gr\"u{\ss} Gott
>> german latex-mode:    Gr"u"s Gott
>> html-mode:            Gr&uuml;&szlig; Gott

AFAIK, nowadays in LaTeX, you're better off using "Grüß Gott" with the
proper input encoding.  For HTML mode as well.

ELISP> (reftex-latin1-to-ascii "räksmörgås")

Before trying to solve the problem for latin-1, then latin-2, then arabic,
then chinese, etc.. we'd better write a real fix that correctly (tho
suboptimally) handles all cases: drop non-ascii chars.  Then we can add
a preprocessing function that tries to be clever.

        Stefan
Permalink | Reply | 0 comments |
headers
Christian Schlauer | 2 Aug 2007 23:09
Picon
Favicon

Re: BibTeX-mode: Key generation when latin-1 characters appear in author field

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> text-mode:            Grüß Gott
>>> tex-mode:             Gr\"u{\ss} Gott
>>> german latex-mode:    Gr"u"s Gott
>>> html-mode:            Gr&uuml;&szlig; Gott
>
> AFAIK, nowadays in LaTeX, you're better off using "Grüß Gott" with the
> proper input encoding.

Yes, that's what I do since I started using LaTeX 10 years ago. (But I
didn't do it in .bib files until 2003.)

I also hope that Roland's
`convert-readable-words-in-backslash-or-ampersand-escaped-sequences'
function isn't necessary anymore.

>
> ELISP> (reftex-latin1-to-ascii "räksmörgås")
>
> Before trying to solve the problem for latin-1, then latin-2, then arabic,
> then chinese, etc.. we'd better write a real fix that correctly (tho
> suboptimally) handles all cases: drop non-ascii chars.

Does "drop non-ascii chars" mean that "räksmörgås" becomes "rksmrgs",
or "raksmorgas"? I'm afraid you mean the former ... But what would
such a function do to a Greek/Cyrillic/Japanese BibTeX entry? I'd
guess there is nothing left when you drop non-ascii chars.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 3 Aug 2007 02:08
Picon

Re: BibTeX-mode: Key generation when latin-1 characters appear in author field

> Does "drop non-ascii chars" mean that "räksmörgås" becomes "rksmrgs",
> or "raksmorgas"? I'm afraid you mean the former ... But what would
> such a function do to a Greek/Cyrillic/Japanese BibTeX entry? I'd
> guess there is nothing left when you drop non-ascii chars.

Yup, there's nothing left.  So what: we're talking about a suggestion to put
in the minibuffer.

        Stefan
Permalink | Reply | 0 comments |
headers
Nick Roberts | 3 Aug 2007 02:42
Picon

tool-bar doesn't work on the trunk with (default) GTK build


If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I
get messages like:

<write-file> is undefined
<dired> is undefined

I don't know if this is particular to the trunk, using GTK, or my build.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

In GNU Emacs 22.1.50.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11)
 of 2007-08-02 on kahikatea.snap.net.nz
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  'CFLAGS=-g3''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction
(Continue reading)

Permalink | Reply | 5 comments |
headers
Glenn Morris | 4 Aug 2007 04:42
Picon

printing.el is broken


emacs -Q -l printing

load: Symbol's value as variable is void: ps-print-version
Permalink | Reply | 0 comments |
headers
Jan Djärv | 4 Aug 2007 11:54
Picon

Re: tool-bar doesn't work on the trunk with (default) GTK build

Nick Roberts skrev:
> If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I
> get messages like:
> 
> <write-file> is undefined
> <dired> is undefined
> 
> I don't know if this is particular to the trunk, using GTK, or my build.
> 
> 

Now fixed, please test it.

	Jan D.
Permalink | Reply | 4 comments |

Gmane