Nabble - Emacs

Re: character syntax of linefeed?

2009-11-25T02:45:45Z

> I get ("
> " ">"), i.e. a syntax of type 'endcomment'.
>
> This behaviour seems to go through 23,22, and 21, so it's definitively
> not new.
>
> My question is, is the above paragraph just wrong? Can I count on it
> being ">"?

Emacs was conceived first of all to be convenient for lisp, and in lisp newline
means also end of comment.

Alin

From forum: Emacs - Dev

Re: bzr repository ready?

2009-11-25T02:27:48Z

Richard Stallman writes:

> > But note that bzr+ssh does not work with savannah, it only allows sftp
> > for pushing.
>
> That's indeed a problem that still needs fixing on the side of Savannah.
>
> Is someone here talking with the Savannah hackers about fixing this?

Somebody also ought to check on the "service not running, try again
later" message for http://bzr.savannah.gnu.org/lh/emacs. That's
Savannah service request sr #107142.

From forum: Emacs - Dev

Re: Visiting inexistent file

2009-11-25T02:22:52Z

B. T. Raven said the following on 11/25/09 05:03:

> B. T. Raven wrote:
>> Bernardo wrote:
>>>> Hi guys,
>>>>
>>>> I have an issue and I would like to have the most elegant solution.
>>>>
>>>> Whenever I visit an inexistent file, I would like to load an empty
>>>> template file for that type. EG.: for .c and .h files, for .py and so on.
>>>>
>>>> Is there any possibility?
>>>>
>>>> Thanx in advance,
>>>>
>>>> Gabaux
>>> see this documentation page:
>>> (info "(emacs) Autoinserting")
>>>
>>>
>> That gives: "No such node or anchor"

works fine here under GNU/Linux Emacs 23.1.1

>
> However C-h i d m autotype shows:
>
> 6. Autoinserting
>
> So:
>
> (info "(autotype) autoinserting")
>

i'm guessing you're running this under MS Windows (have seen a similar
effect on my PC at work)
looks like Autoinserting has been moved into a separate info file under
Windows, which is a bit of shame, it is not found in index under the
main info file

From forum: Emacs - Help

Re: Why my font setting changes?

2009-11-25T01:43:49Z

Water Lin <WaterLin@...> writes:

> I need to open some Emacs windows for better editing performances. One
> for normal text editing and the other for ECB coding.
>
> But I don't know why my Emacs font changes when I use command
> M-x new-frame to open a new Emacs frame.
>
> I just don't like the font Emacs using for my new frame. How can I set
> this?

You need to set the default frame parameters:

(require 'cl)
(let ((font-cell (assoc 'font default-frame-alist)))
(if font-cell
(setf (cdr font-cell) "your-font")
(setf default-frame-alist (acons 'font "your-font" default-frame-alist))))

Or just M-x customize-variable RET default-frame-alist RET

--
__Pascal Bourguignon__

From forum: Emacs - Help

Re: subword-mode

2009-11-25T01:31:56Z

Tassilo Horn <tassilo@...> writes:
> and subword uses those more elaborated ones
>
> "\\W*\$\\([[:upper:]]*\\W?\$[[:lower:][:digit:]]*\\)" (forward)
> "\$\\(\\W\\|[[:lower:][:digit:]]\$\$[[:upper:]]+\\W*\$\\|\\W\\w+\\)"
> (backward)
>
> Maybe just putting the subword regexps in cap-words.el achieves the
> desired behavior. If that's the case, then I agree with Miles that the
> cap-words approach is more elegant.

Just using the above regexps in cap-words.el doesn't work properly,
though perhaps it's closer.

With the new regexps, when moving forward with M-f, it stops one
character too early, and then the next M-f moves to the "proper" end of
the subword. E.g. (digits mark the stopping positions):

fooBarBAZ
12 34 5 (actual)
1 2 3 (desired)

Moving backward with M-b goes one character too far:

fooBarBAZ
3 2 1 (actual)
3 2 1 (desired)

Thanks,

-Miles

--
Monday, n. In Christian countries, the day after the baseball game.

From forum: Emacs - Dev

Re: bzr repository ready?

2009-11-25T00:55:04Z

Richard Stallman <rms@...> writes:
> > But note that bzr+ssh does not work with savannah, it only allows sftp
> > for pushing.
>
> That's indeed a problem that still needs fixing on the side of Savannah.
>
> Is someone here talking with the Savannah hackers about fixing this?

https://savannah.gnu.org/support/index.php?107143

-Karl

From forum: Emacs - Dev

Re: European characters in R.

2009-11-25T00:32:13Z

>>>>> "GJ" == Gérald Jean <gerald.jean@...>
>>>>> on Mon, 23 Nov 2009 12:29:44 -0500 writes:

GJ> Hello there,
GJ> I use:

GJ> R version 2.9.2 (2009-08-24)
GJ> Copyright (C) 2009 The R Foundation for Statistical Computing
GJ> ISBN 3-900051-07-0

GJ> on Ubuntu 9.10, Emacs-22.2.1 and ESS-5.4

GJ> I have a data file containing lots of European characters, French,
GJ> German, Italian and so on. I can read it ok in R but I can't display
GJ> the characters correctly. Here a simple example:

>> ttt.g <- "gérald"
GJ> Erreur : caractÃ¨res multioctets incorrects dans l'analyse de code
GJ> (parser) Ã la ligne 1

GJ> outputting the colnames of my data set I get:

>> names(ttt)
GJ> [1] "ID" "Domaine" "Nom" "MillÃ.Ã.sime"
GJ> "Pays"
GJ> [6] "RÃ.Ã.gion" "Appellation" "Vignoble" "Couleur"
GJ> "Alcool"
GJ> [11] "Classement" "Cuve" "mois" "Bio"
GJ> "CÃ.Ã.page..1"
GJ> [16] "X." "CÃ.Ã.page..2" "X..1" "CÃ.Ã.page..3"
GJ> "X..2"
GJ> [21] "CÃ.Ã.page..4" "X..3" "CÃ.Ã.page..5" "X..4"
GJ> "Prix"
GJ> [26] "QuantitÃ.Ã." "Internet"

GJ> The locale are set as follows:

>> Sys.getlocale()
GJ> [1]
GJ> "LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=C;
GJ> LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=fr_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_CA.UTF-8;
GJ> LC_IDENTIFICATION=C"

GJ> I tried to play with Emacs' coding systmes with no luck! Any idea on
GJ> how to handle this?

Yes, "in principle".

For some reasons, Ubuntu have decided to keep their default with
ISO-latin1 rather than Unicode, at least for emacs.

But there's a whole set of Commands with key strokes to deal
with coding systems inside Emacs.
The keystrokes all start with 'C-x RET' and that's the only
thing you need to remember, as you can quickly get the list via
C-x RET C-h

{General principle :
<key-sequence-beginning> C-h
always gives help (C-h) on all key sequences beginning
with <key-sequence-beginning>}

So, IIRC, you go into the *R* buffer and press
C-x RET p {p: "buffer-[p]rocess"}.

You may need a bit more, but this should help you getting into
the correct direction!

Regards,
Martin Mächler, ETH Zürich

GJ> Thanks,
GJ> Gérald Jean

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

From forum: ESS - Help

Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.)

2009-11-25T00:16:29Z

In article <87fx835elh.fsf@...>, "Stephen J. Turnbull" <stephen@...> writes:

> I'm not sure. As it seems that windows-1252 is a superset of
> iso-8859-1, it may be ok to give windows-1252 the higher priority.
> How do iso-8859-1 users think?

> Why not make a Windows-12xx coding-category? If you don't want to
> advertise what it is, you could call it "ascii8" or "pseudo-ascii" or
> something like that.

Ah!

A coding-category of a coding-system is automatically
determined by :coding-type arg (and by some other arg
depending on :coding-type) of define-coding-system. And
iso-8859-x and windows-12xx are exactly the same in this
aspect; i.e. both :coding-type is `charset' which means the
coding system is for decoding/encoding charsets in
:charset-list.

Perhaps it is good to add one more coding-category
`charset8' to which such coding-systems that handle a single
byte charset containing many 0x80..0x9F area code are
classified.

> (Wouldn't some of the obsolete Vietnamese
> standards fit this too? Ie, 0-0177 are the same as ISO-646, and
> 0200-0377 are used for the alternate script?)

Do you mean such coding-systems as vietnamese-tcvn and
vietnamese-viscii? Although their 0x00-0x1F are not the
same as ASCII, yes, they can be classified into `charset8'
category.

---
Kenichi Handa
handa@...

From forum: Emacs - Dev

Re: regexp/emacs selective replace

2009-11-25T00:15:27Z

m121212 <m121212@...> writes:

> Hi,
>
> I have a tricky problem that I'm not sure how to solve. I have a latex
> document with several figure environments that look like this:
>
> \begin{figure}
> \includegraphics{blah.ps}
> \end{figure}
>
> but need to look like this:
>
> \begin{figure}
> \begin{center} \includegraphics{blah.ps} \end{center}
> \end{figure}
>
> Some of the figure environments already have this however, and I don't want
> to end up with something like this:
>
> \begin{figure}
> \begin{center}\begin{center} \includegraphics{blah.ps}
> \end{center}\end{center}
> \end{figure}
>
> Any ideas? Also, is there a way Emacs can just wrap any selection with
> custom, predefined tags?

Anchor to the beginning and end of line.

M-x replace-regexp RET
^ *\\includegraphics{[^}]*} *$ RET
\\begin{center} \& \\end{center} RET

From forum: Emacs - Help

Re: subword-mode

2009-11-24T23:58:13Z

Miles Bader <miles@...> writes:

> Stefan Monnier <monnier@...> writes:
>> I just bumped into find-word-boundary-function-table, which lead me to
>> its only user: cap-words.el.
>>
>> It seems both subword.el and cap-words.el provide the same feature (tho
>> cap-words.el is obviously not good at advertising itself, ahem).
>
> Given that it's only about 3 lines long, and apparently works by
> taking advantage of some existing low-level mechanism, cap-words.el
> seems by far the more elegant implementation...
>
> However.... it doesn't seem to actually work correctly in many cases;
> perhaps the low-level feature has bit-rotted?
>
> E.g.: given the example word in the file "capitalizedWorDD", and turning
> on `capitalized-words-mode', moving _backwards_ from the end of the
> string with M-b stops at the first "D", then the "W', then the beginning
> "c" -- that's correct except that it should have stopped at the second
> "D" first. However moving _forwards_ from the beginning with M-f, it
> only stops at the second "D".

It looks to me that those differences come from the regexps used.
cap-words uses those simple ones

"\\=.\\w*[[:upper:]]" (forward)
"[[:upper:]]\\w*\\=" (backward)

and subword uses those more elaborated ones

"\\W*\$\\([[:upper:]]*\\W?\$[[:lower:][:digit:]]*\\)" (forward)
"\$\\(\\W\\|[[:lower:][:digit:]]\$\$[[:upper:]]+\\W*\$\\|\\W\\w+\\)"
(backward)

Maybe just putting the subword regexps in cap-words.el achieves the
desired behavior. If that's the case, then I agree with Miles that the
cap-words approach is more elegant.

If so, we should rename cap-words.el to subword.el. Additionally, the
docs of cap-words need to be polished, because there it seems to be
intended to stop at each capital letter, but in general that's not
desired.

With (the current) subword.el, the stop points are

fooBarBAZ
^ ^ ^ ^

which seems correct to me and matches the behavior of Eclipse or
IntelliJ.

Ah, and of course, I'd volunteer to test and do that changes, although I
probably won't do it before the weekend.

Bye,
Tassilo

From forum: Emacs - Dev

RE: Emacs crashes, network drives and hibernate

2009-11-24T23:43:29Z

This sounds like the /SWAPRUN:NET flag used with the MS LINK.EXE.

This will have the loader copy the executable to the swap file if
it resides on the network, and run from the swap file rather than
the original image.

-----Original Message-----
From: help-emacs-windows-bounces+michael=hotchin.net@...
[mailto:help-emacs-windows-bounces+michael=hotchin.net@...] On Behalf Of
andy.ling@...
Sent: Tuesday, November 24, 2009 5:28 AM
To: help-emacs-windows@...
Subject: Re: [h-e-w] Emacs crashes, network drives and hibernate

> I do not know, but please report this as a bug.
>

OK, done.

>
> On Tue, Nov 24, 2009 at 10:55 AM, <andy.ling@...> wrote:
> > I have recently moved up to Emacs 23.1.1 from 21.3 and I'm finding it
> > keeps crashing.
> >
> > I am running under Window XP. I have the emacs binaries on a network
drive

> > and I suspect
> > it crashes if there is a problem talking to the network drive.
> >
> > The easiest way to get it to crash is to hibernate the PC with emacs
> > running. When
> > I restore from hibernate emacs crashes.
> >
> > I had been running 21.3 like this for some years without a problem. So
> > this is something
> > new to 23. I seem to remember a similar problem many years ago which

was

> > fixed
> > by changing a compile flag.
> >
> > Does anybody know how to fix this?
> >
> > Thanks
> >
> > Andy Ling
>
>
>
>
> This message has been scanned by MailController

--

This e-mail is intended for the named addressees only. Its contents may be
privileged or confidential and should be treated as such. If you are not
an intended recipient please notify the sender immediately and then delete
it; do not copy, distribute, or take any action based on this e-mail. In
the pursuit of its legitimate business activities and its conformance with
relevant legislation, Quantel may access any e-mail (including
attachments) it originates or receives, for potential scrutiny.

Quantel is the trade name used by Quantel Holdings Limited and its
subsidiaries. Quantel Holdings Limited is registered in England & Wales.
Registration No: 4004913
Contact details for all Quantel Offices and Companies can be found on our
website www.quantel.com or by writing to the holding company.
Registered address: Turnpike Road, Newbury, Berkshire, RG14 2NX, United
Kingdom

From forum: Emacs - Windows - Help

Re: Displaying bytes (was: Inadequate documentation of silly

2009-11-24T22:20:12Z

Stefan Monnier writes:

> The problem with windows-1252 is that all files are valid in that
> coding-system.

Well, *pedantically* that's true of any ISO 8859 coding system too,
since ISO 8859 doesn't specify what might appear in C1 at all. In
practice for 1252

1. The only C0 controls you'll commonly see are \t, \r, and \n.
2. The set of C1 controls that are defined is limited IIRC (but
Microsoft does go around changing it without warning, so I could
be wrong by now ;-).
3. It's line-oriented text (even if long-lines): you'll very probably
see \r and \n only as \r\n, you might see only \n and no \r, and
you'll not see "random" use of \r or \n.

From forum: Emacs - Dev

Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.)

2009-11-24T21:54:47Z

Kenichi Handa writes:
> In article <E1ND4AD-0003Yg-Cc@...>, Richard Stallman <rms@...> writes:

> > If so, should we change the default priorities?
>
> I'm not sure. As it seems that windows-1252 is a superset of
> iso-8859-1, it may be ok to give windows-1252 the higher priority.
> How do iso-8859-1 users think?

Why not make a Windows-12xx coding-category? If you don't want to
advertise what it is, you could call it "ascii8" or "pseudo-ascii" or
something like that. (Wouldn't some of the obsolete Vietnamese
standards fit this too? Ie, 0-0177 are the same as ISO-646, and
0200-0377 are used for the alternate script?)

If you don't make a separate coding category for that, I don't like
the change, myself. Windows-12xx character sets are proprietary in
the sense that last I looked, the IANA registry for Windows-12xx coded
character sets pointed to internal Microsoft documents, and made no
promises about changes to those documents. As far as I know,
Microsoft added the EURO SIGN to Windows-1252 simply by editing that
internal page. There was no indication of the history of such changes
on the IANA page.

From forum: Emacs - Dev

Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.)

2009-11-24T21:40:32Z

>>>>> On Wed, 25 Nov 2009, Kenichi Handa wrote:

>> If so, should we change the default priorities?

> I'm not sure. As it seems that windows-1252 is a superset of
> iso-8859-1, it may be ok to give windows-1252 the higher priority.

Please don't.

I wonder why one would even *think* of changing Emacs's default to a
Microsoft proprietary "code page". :-(

> How do iso-8859-1 users think?

Seems to me that use of iso-8859-* is much more widespread on *nix
systems. I think the current default priorities are perfectly fine.

Ulrich

From forum: Emacs - Dev

Re: bzr repository ready?

2009-11-24T21:34:18Z

Eli Zaretskii writes:

> Funny I didn't get that before. Thanks for explaining.

You're very welcome. Dunno whether it's funny on your side or mine,
though. These days, it's quite possible that I'm writing
"syntactically correct English" but intending "Japanese semantics". :-þ

By the way, I just added the following reference to BzrForEmacsDevs:

http://doc.bazaar-vcs.org/migration/en/survival/bzr-for-git-users.html

(yeah, I wrote that, but it's pretty good :-) to the references.

While a lot of it only makes sense if you know git, there are two
glossary tables that give definitions of a lot of terms as used in git
and Bazaar, and I hope they might be useful to folks here. Unfortunately
the corresponding document for CVS remains a stub. :-(

From forum: Emacs - Dev

Re: bzr repository ready?

2009-11-24T21:24:13Z

David De La Harpe Golden writes:

> > You don't commit any local changes, because you didn't make any in
> > that branch. You *merge* local changes to it from your working
> > branch,
>
> well, to the working tree of branch trunk, not to the branch as such?

Uhm ... you're comparing with git merge, which commits-unless-conflict?
That's right, a "bzr merge" is entirely VC-data-to-working tree (you
can do it from a branch or a specially-formatted merge directive file)
operation, and doesn't automatically commit.

My point was that the commit in the suggested workflow is based on VCS
data, and therefore reversible and recoverable. It's not based on
user changes, which would be irrecoverable if you did something like
"bzr pull --overwrite".

The whole suggested workflow is designed with two principles in mind:

1. A user shall not be asked to choose between committing the content
of his workspace and getting an update from upstream.
2. The default view presented by "bzr log" shall be the list of the
user's commits in his workspace, and the list of contributions
(each of which may contain a long sequence of commits) in the
upstream master and its mirrors.

I don't really care, but no. 2 is a feature that people who like
Bazaar love until the fur comes off.

Caveat: in the above, I'm speaking for myself, not for Karl.

> > and these are *automatically* passed on to the upstream master
> > when you commit.
>
> So hybrid of D and non-D VCS. I suppose that's why "bound branch" was
> "checkout", it was by an analogy to non-D VCS where a cvs commit
> goes off to the remote server.

Yes. And that analogy is even closer with "checkout --lightweight",
which is why the terminology (and the default) is moving in that
direction.

> What happens when you commit "on" a bound branch without network
> connectivity? I guess it just fails, since you're not really
> committing to the bound branch but rather to the associated remote
> upstream branch?

Yes. If you know you're disconnected, you can do "bzr commit
--local". As Stefan mentioned in passing, there are some issues with
this. I don't know whether it's in the implementation of Bazaar or in
the implementation of Stefan ;-), but if it's the latter, I'm sure
you're aware that that implementation is quite advanced and robust, so
this feature is hard to use. :-)

> > Because it's pointless to do that. The race condition in using
> > my-trunk (not bound to upstream master) means that you can succeed in
> > committing the merge, but fail the push.
>
> Well, I suppose in the git world one just tends to avoid many
> committers in the first place (since given DVCS there's no actual
> need for much shared access beyond perhaps some redundancy),

That's false. Decentralized project workflows like Emacs's do need
it. The more centralized single-maintainer and gatewayed project
architectures (a la the well-known punk code artists "Linus and His
Lieutenants") don't, of course, but distributed VCS supports a wide
variety of workflows.

Be that as it may, the current proposal AIUI is to emulate the current
CVS-based *project-level* workflow as closely as possible.
Individuals with experience with dVCS are welcome to vary their own
workflows as they please, but as you will observe in this thread rms
and Eli Z are (to a greater or lesser extent personally) concerned
with workflow disruption, and Stefan has explicitly indicated that at
first minimizing disruption is a goal (sine qua non?)

> and the occasional conflict isn't the end of the world. Maybe it's
> easier to rewrite history in git though, I know nothing of bzr
> (though I did just find bzr rebase)

Much easier! Don't rewrite history in Bazaar. It's very limited,
painful, dangerous[1], and worst of all :-) you will be treated as a
pariah by many in the Bazaar community.

Footnotes:
[1] It's non-trivial to recover an obsoleted head. No reflogs, no
documentation of the commands needed to find heads.

From forum: Emacs - Dev

Re: subword-mode

2009-11-24T21:22:27Z

Stefan Monnier <monnier@...> writes:
> I just bumped into find-word-boundary-function-table, which lead me to
> its only user: cap-words.el.
>
> It seems both subword.el and cap-words.el provide the same feature (tho
> cap-words.el is obviously not good at advertising itself, ahem).

Given that it's only about 3 lines long, and apparently works by taking
advantage of some existing low-level mechanism, cap-words.el seems by
far the more elegant implementation...

However.... it doesn't seem to actually work correctly in many cases;
perhaps the low-level feature has bit-rotted?

E.g.: given the example word in the file "capitalizedWorDD", and turning
on `capitalized-words-mode', moving _backwards_ from the end of the
string with M-b stops at the first "D", then the "W', then the beginning
"c" -- that's correct except that it should have stopped at the second
"D" first. However moving _forwards_ from the beginning with M-f, it
only stops at the second "D".

-Miles

--
Absurdity, n. A statement or belief manifestly inconsistent with one's own
opinion.

From forum: Emacs - Dev

bug#5031: marked as done (23.1; abbrev and escapes)

2009-11-24T21:10:07Z

Your message dated Wed, 25 Nov 2009 00:00:09 -0500
with message-id <jwvr5rnp5mo.fsf-monnier+emacsbugreports@...>
and subject line Re: bug#5031: 23.1; abbrev and escapes
has caused the Emacs bug report #5031,
regarding 23.1; abbrev and escapes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@...
immediately.)

--
5031: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5031
Emacs Bug Tracking System
Contact owner@... with problems

It was possible under emacs 22 to expand abbrevs that start with an escape
character e.g. \ by setting words-include-escapes to true.
This does not work anymore under emacs 23. Here is a short example.

(progn
(define-abbrev-table 'my-table '(
("success" "success again")
("\\med" "\\medskip")))
(setq local-abbrev-table my-table)
(setq abbrev-mode t)
(setq words-include-escapes t))

Under emacs22, success expands to success again
\med expands to \medskip

Under emacs23, only success expands.

I tried to modify the :regexp property of the table without success.

In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
of 2009-09-14 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

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: fr_FR.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
show-paren-mode: t
display-time-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: 1
font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
temp-buffer-resize-mode: t
column-number-mode: t
line-number-mode: t

Recent input:
M-t g n u s <return> M-t C-g C-x b * s c a r DEL DEL
r a t c h * <return> M-t r e p o r t - b u g <return>

Recent messages:
nnimap: Mailbox INBOX modified
nnimap: Mailbox INBOX.Trash modified
nnimap: Checking mailboxes...done
Reading active file from sauvegarde via nnfolder...
Opening nnfolder server on sauvegarde...done
nnfolder: Reading incoming mail from file...
nnfolder: Reading incoming mail (no new mail)...done
Reading active file from sauvegarde via nnfolder...done
Checking new news...done
Quit

> It was possible under emacs 22 to expand abbrevs that start with an escape
> character e.g. \ by setting words-include-escapes to true.
> This does not work anymore under emacs 23. Here is a short example.

> (progn
> (define-abbrev-table 'my-table '(
> ("success" "success again")
> ("\\med" "\\medskip")))
> (setq local-abbrev-table my-table)
> (setq abbrev-mode t)
> (setq words-include-escapes t))

I've installed the patch below which should better match the
Emacs-22 behavior. Thanks for the report,

Stefan

=== modified file 'lisp/abbrev.el'
--- lisp/abbrev.el 2009-11-19 17:24:04 +0000
+++ lisp/abbrev.el 2009-11-25 04:45:07 +0000
@@ -680,11 +680,19 @@
(setq tables (append (abbrev-table-get table :parents) tables))
(setq res
(and (or (not enable-fun) (funcall enable-fun))
- (looking-back (or (abbrev-table-get table :regexp)
- "\\<\$\\w+\$\\W*")
- (line-beginning-position))
+ (let ((re (abbrev-table-get table :regexp)))
+ (if (null re)
+ ;; We used to default `re' to "\\<\$\\w+\$\\W*"
+ ;; but when words-include-escapes is set, that
+ ;; is not right and fixing it is boring.
+ (let ((lim (point)))
+ (backward-word 1)
+ (setq start (point))
+ (forward-word 1)
+ (setq end (min (point) lim)))
+ (when (looking-back re (line-beginning-position))
(setq start (match-beginning 1))
- (setq end (match-end 1))
+ (setq end (match-end 1)))))
(setq name (buffer-substring start end))
(let ((abbrev (abbrev-symbol name table)))
(when abbrev

From forum: Emacs - Bugs

subword-mode

2009-11-24T20:26:39Z

I just bumped into find-word-boundary-function-table, which lead me to
its only user: cap-words.el.

It seems both subword.el and cap-words.el provide the same feature (tho
cap-words.el is obviously not good at advertising itself, ahem).

Stefan

From forum: Emacs - Dev

bug#3717: M-x man completion

2009-11-24T20:21:42Z

> From: Kevin Ryde <user42@...>
> Date: Wed, 25 Nov 2009 09:58:09 +1100
> Cc: 3717@..., jidanni@...
>
> - (call-process "man" nil '(t nil) nil "-k" (concat "^" string))
> + (let ((process-connection-type nil) ;; pipe
> + (process-environment (copy-sequence process-environment)))
> + (setenv "COLUMNS" "999") ;; don't truncate long names
> + (call-process "man" nil '(t nil) nil "-k" (concat "^" string)))

This needs to deal with versions of `man' that don't support the -k
switch.

From forum: Emacs - Bugs

Re: Displaying bytes (was: Inadequate documentation of silly

2009-11-24T18:50:50Z

On Wed, Nov 25, 2009 at 3:29 AM, Stefan Monnier
<monnier@...> wrote:

>>> If so, should we change the default priorities?
>> I'm not sure. As it seems that windows-1252 is a superset of
>> iso-8859-1, it may be ok to give windows-1252 the higher priority.
>> How do iso-8859-1 users think?
>
> The problem with windows-1252 is that all files are valid in that
> coding-system. So it's OK if there's a really high chance of
> encountering such files, but otherwise it leads to many misdetections.
>
>> For that, it seems that adding that facility in
>> after-insert-file-set-coding is good. Here's a sample patch. The
>> actual change should give more information to a user.
>
> Maybe we could try that. But I really dislike adding a user-prompt in
> the middle of some operation that might be performed as part of
> something "unrelated". And indeed the actual change may need to give
> a lot more information, mostly displaying the buffer without which the
> user cannot make a good guess.

Maybe it is better to read in the file in the buffer with a best guess
and add a hook that is run the first time the buffer is shown in a
window with some notification to the user of the problem?

Then of course also provide enough hints to make it as easy to change
coding system in that situation to the relevant alternatives.

From forum: Emacs - Dev

Re: Bad choice of license in BzrForEmacsDevs

2009-11-24T18:38:01Z

> EmacsWiki? http://www.emacswiki.org/emacs/AlexSchroeder
> Can you tell me his email address? Email is the way I communicate.

Try

grep 'Schroeder' lisp/ChangeLog*

;-)

-- Stefan

From forum: Emacs - Dev

Re: Displaying bytes (was: Inadequate documentation of silly

2009-11-24T18:29:59Z

>> If so, should we change the default priorities?
> I'm not sure. As it seems that windows-1252 is a superset of
> iso-8859-1, it may be ok to give windows-1252 the higher priority.
> How do iso-8859-1 users think?

The problem with windows-1252 is that all files are valid in that
coding-system. So it's OK if there's a really high chance of
encountering such files, but otherwise it leads to many misdetections.

> For that, it seems that adding that facility in
> after-insert-file-set-coding is good. Here's a sample patch. The
> actual change should give more information to a user.

Maybe we could try that. But I really dislike adding a user-prompt in
the middle of some operation that might be performed as part of
something "unrelated". And indeed the actual change may need to give
a lot more information, mostly displaying the buffer without which the
user cannot make a good guess.

Stefan

From forum: Emacs - Dev

Re: Displaying bytes

2009-11-24T18:18:31Z

> I don't know you see this "tis620" stuff.
> How strange this discrepancy. I have a few changes that are not
> installed, but not in anything relevant here. I last updated
> source code on Nov 18.

Oh wait, I now see: you get `tis620' for chars between 128 ans 160
(i.e. eight-bit-control), and `eight-bit' for chars between 160 and 256.

> Here's what apparently defines that character set, in mule-conf.el:

> (define-charset 'tis620-2533
> "TIS620.2533"
> :short-name "TIS620.2533"
> :ascii-compatible-p t
> :code-space [0 255]
> :superset '(ascii eight-bit-control (thai-tis620 . 128)))

Looks like the eight-bit-control here is part of the problem.

> Anyway, please don't overlook the other suggestions in my message
> for how to make things clearer.

Of course.

>> What are the situations where a user is likely to see these stray
>> bytes.
> There pretty much shouldn't be any in multibyte buffers.
> Would it be good to ask people to send bug reports when these
> stray byte characters appear in multibyte buffers?

No, these chars can appear in cases where Emacs does the right thing.
I.e. sometimes they reflect bugs, but often they just reflect "pilot
errors" or corrupted data completely outside the control of Emacs.

Stefan

From forum: Emacs - Dev

Re: Case mapping of sharp s

2009-11-24T18:13:23Z

In article <4B0C32BF.2020708@...>, grischka <grishka@...> writes:

> DEC_BOTH is maybe not slower than INC_BOTH, but two DEC_BOTH
> are (as with Andy's patch). Moderately slower, still ;)

So, changing the current backward matching to forward
matching should is effective.

> The originally observed slowness was not because of the usage of
> CHAR_TO_BYTE, but because of the flaws in CHAR_TO_BYTE, such as
> using unrelated "best_below" and "best_above" in the same expression.

> For the numbers, with my 100MB file test case:

> backward search previously:
> 14 .. 90 s (random)
> backward search with fixed CHAR_TO_BYTE:
> 5.6 s

I don't see any fix of CHAR_TO_BYTE in the current CVS
code. Where is it?

> > (2) Pre-compute the character codes in PAT in an integer
> > array if LEN is not that long (perhaps LEN < 256, or
> > at most, sizeof (int) * LEN < MAX_ALLOCA).
> >
> > Then, you don't need the repeated STRING_CHAR on PAT. This
> > can be applicable to forward search too.
> >

> In practice searching a string is mostly about searching the first
> char in the string, basically like strchr(buf, pat[0]). (That is
> unless you'd search for "aabb" in "aaabaaaaaaababbaaaabb" which is
> not a practical example)

> So as to pre-computing the pattern, you'd get the most improvement
> already from just pre-computing "pat[0]" or "pat[len-1]" if you
> want to.

When there's no match, it's true that pre-computing of the
whole pattern is a waste. But, when there's a match, we
anyway compute character codes of the whole pattern. So
perhaps the good strategy will be to record the computed
character codes gradually when we need it.

> > (3) In addition to (2), pre-compute the character codes in
> > BUF too in an array of the same length as (2).
> >
> > Then you can avoid using STRING_CHAR and TRANSLATE
> > repeatedly on the same place of BUF. This requires modulo
> > calculation to get an index of the array, but I think it's
> > faster than the combination of STRING_CHAR and TRANSLATE.

> Because the first char matches rarely (on average), a repeated
> translation of the same place happens rarely too.

> Of course, TRANSLATE (-> Fassoc(trt, make_number())) per se is
> slow, so a translation table as C array for say the 0..127
> range, would help indeed.

> In any case, with some tweaking it is possible to improve both
> directions by ~70% (that is down to about 1 sec for the test
> case). I still don't know why boyer_moore with a one-char
> pattern takes only 0.5 seconds though. It's amazingly fast.

Are you comparing both methods with the same value of
case-fold-search?

> Btw it seems that long loading time for the big file has much to
> do with inefficient counting of newlines. Appearently it takes
> ~2 sec to load the file and then another ~6 sec to scan newlines.
> It should be (far) under 0.5 sec.

Why is the code of counting newlines called when we just
visit a file?

---
Kenichi Handa
handa@...

From forum: Emacs - Dev

Re: find-file-literally

2009-11-24T18:10:39Z

>>> ! (interactive
>>> ! (list (read-file-name
>>> ! "Find file literally: " nil default-directory
>>> ! (confirm-nonexistent-file-or-buffer))))
>> Good change, thank you.
> Please note that this change would be unnecessary if following lines
> were removed from `read-file-name':

> (unless default-filename
> (setq default-filename (if initial (expand-file-name initial dir)
> buffer-file-name)))

The part I like is (confirm-nonexistent-file-or-buffer) which wouldn't
be solved by removing those lines, right?

Stefan

From forum: Emacs - Dev

bug#5036: marked as done (23.1.50; Unexpected minibuffer tab completion behavior)

2009-11-24T17:55:07Z

Your message dated Tue, 24 Nov 2009 17:50:39 -0800
with message-id <d791b8790911241750h74ba8a83g50004f2700075f0c@...>
and subject line Bad bug
has caused the Emacs bug report #5036,
regarding 23.1.50; Unexpected minibuffer tab completion behavior
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@...
immediately.)

--
5036: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5036
Emacs Bug Tracking System
Contact owner@... with problems

It seems like the unexpected buffer switching is because the
'dedicated' flag on the temporary window created for *Completions* is
getting cleared by set-window-buffer.

My understanding of the situation so far is:

- The `(with-output-to-temp-buffer "*Completions*" ...)' form in
minibuffer-completion-help results in `display-buffer' being called
with `display-buffer-mark-dedicated' bound to `soft'.
- The `(and pop-up-windows ...)' clause of `display-buffer' is
evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
- However, the `window--display-buffer-2' call then calls
`set-window-buffer', which sets `w->dedicated = Qnil'.
- Later, when `(bury-buffer)' is called to hide the minibuffer help,
it sees the window is not dedicated, so it switches to a new buffer
instead of killing the window.

(* I haven't bothered yet to look into why that particular clause is
evaluated, but I don't think it matters; it's just the one that
stepping through the code took me to.)

Sorry, this message was meant to be added as a comment to #5030 instead.

From forum: Emacs - Bugs

Re: bzr repository ready?

2009-11-24T17:46:37Z

Richard Stallman <rms@...> writes:

> There are terminology changes going on, and I'm not fully
> up-to-date with those. But the *semantics* are not changing: the
> normal way to use Bazaar is to fetch full historical data with
> each branch, so you have everything locally, and this is also what
> we are recommending for Emacs development.
>
> I am not sure how to reconcile that statement with what people said
> about lightweight checkouts -- that they are comparable to CVS
> checkouts in what they contain.

Yes, a lightweight checkout is comparable to a CVS checkout in that it
relies on the branch it is pointing to for history. If you created a
lightweight checkout from a remote branch you would be coming as close
to recreating CVS as is possible with a more modern version control
system. Bzr would still give you atomic commits, and the ability to
move files around without losing history (to name a few advantages), but
you would have to be connected to the network for most commands to work.

> Is the idea of lightweight checkouts that you first make a local
> repository and then make a lightweight checkout from that?

Yes, that's it precisely. Lightweight checkouts basically allow you to
create a working tree from a branch that you have in the repository. If
you only plan on having one branch on your local machine then a
lightweight checkout is *not* what you want. However, if you are
working on several different branches at the same time and you don't
want to have several different copies of the Emacs source code lying
around (with the attendant requirement to run make bootstrap on each of
these source trees), then a lightweight checkout is the solution to your
problem.

In that case you create a local repository to hold your branches and you
connect a lightweight checkout to the local branch you want to hack on
using "bzr switch". If later you need to hack on a different branch you
commit your changes to your local branch and bzr switch to the other
branch and hack there. Your source tree will be changed to match the
contents of the branch that you switch too, and all of the unversioned
files (like the stuff make bootstrap generates) will be there so that
make will only build what needs to be built.

If you have read:

http://www.emacswiki.org/emacs/BzrForEmacsDevs

You'll notice that it doesn't cover lightweight checkouts at all as
these checkouts are a more advanced topic. Lightweight checkouts are
handy, but they are not necessary. I personally think that many Emacs
hackers are likely to end up using them in the long run, but bzr allows
for a great deal of flexibility when it comes to designing your own
workflow.

Jason

From forum: Emacs - Dev

Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.)

2009-11-24T17:33:54Z

In article <E1ND4AD-0003Yg-Cc@...>, Richard Stallman <rms@...> writes:

> $ od -c euro.txt
> 0000000 T h a t c o s t s 200 1 7 . \n
> 0000020
> $ emacs euro.txt

> This is really a windows-1252 file and the strange character is
> supposed to be a Euro sign.
> For me, with no particular setup to make Emacs expect windows-1252
> files that shows in emacs as
> "That costs \20017." with raw-text-unix.

> Why doesn't Emacs guess right, in this case?

Because some other coding system of the same coding-category of
windows-1252 (coding-category-charset) has the higher priority and
that coding system doesn't contain code \200.

> Could we make it guess right by changing the coding system
> priorities?

Yes.

> If so, should we change the default priorities?

I'm not sure. As it seems that windows-1252 is a superset of
iso-8859-1, it may be ok to give windows-1252 the higher priority.
How do iso-8859-1 users think?

The better thing is to allow registering multiple coding systems in
one coding-category, but I'm not sure I have a time to work on it.

> It may be that a different set of priorities would cause similar
> problems in some other cases and the current defaults are the best.
> But if we have not looked at the question in several years, it would
> be worth studying it now.

> In that case revert-buffer-with-coding-system. Ideally I'd like Emacs
> to ask directly when opening the file
> in such a case, if it can't determine anything better than raw-bytes.

> Maybe so.

For that, it seems that adding that facility in
after-insert-file-set-coding is good. Here's a sample patch. The
actual change should give more information to a user.

--- mule.el.~1.294.~ 2009-11-17 11:42:45.000000000 +0900
+++ mule.el 2009-11-25 10:17:49.000000000 +0900
@@ -1893,7 +1893,18 @@
coding-system-for-read
(not (eq coding-system-for-read 'auto-save-coding)))
(setq buffer-file-coding-system-explicit
- (cons coding-system-for-read nil)))
+ (cons coding-system-for-read nil))
+ (when (and last-coding-system-used
+ (eq (coding-system-base last-coding-system-used) 'raw-text))
+ ;; Give a chance of decoding by some coding system.
+ (let ((coding-system (read-coding-system "Actual coding system: ")))
+ (if coding-system
+ (save-restriction
+ (narrow-to-region (point) (+ (point) inserted))
+ (let ((modified (buffer-modified-p)))
+ (decode-coding-region (point-min) (point-max) coding-system)
+ (setq inserted (- (point-max) (point-min)))
+ (set-buffer-modified-p modified)))))))
(if last-coding-system-used
(let ((coding-system
(find-new-buffer-file-coding-system last-coding-system-used)))

---
Kenichi Handa
handa@...

From forum: Emacs - Dev

Re: regexp/emacs selective replace

2009-11-24T17:30:25Z

In article <mailman.11424.1259102060.2239.help-gnu-emacs@...>,
m121212 <m121212@...> wrote:

Does query-replace-regexp do what you want? It will prompt you before
each possible replacement, and you can say whether to replace that
instance.

--
Barry Margolin, barmar@...
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

From forum: Emacs - Help

Re: Frame titles which reflect contents

2009-11-24T17:26:43Z

On Nov 22, 10:04 am, Eduardo Cavazos <wayo.cava...@...> wrote:

> Hello!
>
> Today I had three frames open. One frame had a single window with file
> 'a'. Another had a single window with file 'b'. The third frame had 3
> windows; file 'a', file 'b', and a *scheme* buffer.
>
> I was running this Emacs in Gnome. The three frames are reflected in
> the window list in the bottom panel. The trouble is that, the third
> frame with the multiple windows is named based on the buffer that's
> currently selected in that frame. So if buffer 'b' is selected,
> there's no way to distinguish frame 2 and frame 3 based on the window
> list alone.
>
> Any thoughts on how to solve the problem?
>
> One approach is to have the frame title be based on more than just the
> name of the currently selected buffer. So for example, if a frame has
> two windows with buffers 'a.sls' and '*scheme*', the frame could be
> called "[a.sls] | *scheme*". I.e. with the [...] indicating which
> buffer in that frame is active.
>
> I'm sure there are other approaches as well! Comments, suggestions,
> and elisp welcome! :-)
>
> Ed

I think this will do what you want, it works for me anyway:

(defun window-to-buffer-name (w)
(buffer-name (window-buffer w)))

(setq frame-title-format
'("" (:eval (mapconcat #'window-to-buffer-name
(window-list)
" | "))))

The selected-window is always the first element in window-list by
default.

From forum: Emacs - Help

bug#4957: 23.1.50; idlwave activated spuriously

2009-11-24T16:37:53Z

Richard Stallman wrote:

> I suspect that some idlwave file does nontrivial actions when it is
> merely loaded.

emacs -Q -l idlwave

does some work to set up the `idlwave-routines' variable. Is this an
issue? It doesn't change any aspect of Emacs behaviour, it's just
(verbosely) initializing so that it can start up faster when actually
needed.

It only starts doing it if Emacs is idle for
`idlwave-init-rinfo-when-idle-after' seconds (default 10). Change this
variable to 0 and it won't do anything until the information is
actually needed.

From forum: Emacs - Bugs

bug#3717: M-x man completion

2009-11-24T15:45:47Z

Oh, and I've also found case-insensitive completion best for page names,
when trying to type bizarre-case things like the x11 funcs.

I was going to make the sensitivity configurable, or switchable with C-t
like isearch, but never thought of a good way, so it's hard coded
insensitive -- with the justification that man itself is
case-insensitive on the command line. :-)

From forum: Emacs - Bugs

Re: bzr repository ready?

2009-11-24T15:41:13Z

Thanks for the reply!

> In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a
> manually-maintained remote tracking branch.

Right so.

> You don't commit any local changes, because you didn't make any in
> that branch. You *merge* local changes to it from your working
> branch,

well, to the working tree of branch trunk, not to the branch as such?

> and these are *automatically* passed on to the upstream master
> when you commit.

So hybrid of D and non-D VCS. I suppose that's why "bound branch" was
"checkout", it was by an analogy to non-D VCS where a cvs commit
goes off to the remote server. What happens when you commit "on" a
bound branch without network connectivity? I guess it just fails,
since you're not really committing to the bound branch but rather
to the associated remote upstream branch?

> Because it's pointless to do that. The race condition in using
> my-trunk (not bound to upstream master) means that you can succeed in
> committing the merge, but fail the push.

Well, I suppose in the git world one just tends to avoid many committers
in the first place (since given DVCS there's no actual need for much
shared access beyond perhaps some redundancy), and the occasional
conflict isn't the end of the world. Maybe it's easier to rewrite
history in git though, I know nothing of bzr (though I did just find bzr
rebase)

From forum: Emacs - Dev

Processed: control

2009-11-24T15:30:06Z

Processing commands for control@...:

> tags 4944 =
Bug #4944 [emacs] 23.1.50; starting a server without forking a daemon
Removed tag(s) moreinfo.
> close 4977
bug#4977: 23.1.50; Error composing mail in latest CVS
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to Manoj Srivastava <srivasta@...>

> forcemerge 4977 4978
bug#4977: 23.1.50; Error composing mail in latest CVS
bug#4978: 23.1.50; Problems with citation highlight in Gnus
Forcibly Merged 4977 4978.

> reassign 4893 emacs,ns
Bug #4893 [ns] ns-face-at-pos incorrect
Warning: Unknown package 'ns'
bug reassigned from package 'ns' to 'emacs,ns'.
Warning: Unknown package 'ns'
Warning: Unknown package 'ns'
Warning: Unknown package 'ns'
Warning: Unknown package 'ns'
Warning: Unknown package 'ns'
> reassign 5028 spam
Bug #5028 [emacs] I revealed my biceps strong and bare
bug reassigned from package 'emacs' to 'spam'.
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
> reassign 5034 spam
Bug #5034 [emacs] TRANSFER OF FUND EFFECTED TODAY
bug reassigned from package 'emacs' to 'spam'.
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
> reassign 5035 spam
Bug #5035 [emacs] TRANSFER OF FUND EFFECTED TODAY
bug reassigned from package 'emacs' to 'spam'.
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
Warning: Unknown package 'spam'
> tags 5012 patch
Bug #5012 [emacs] avl-tree.el enhancements
Bug #5015 [emacs] avl-tree.el enhancements
Bug #5016 [emacs] avl-tree.el enhancements
Bug #5021 [emacs] avl-tree.el enhancements
Bug #5024 [emacs] avl-tree.el enhancements
Added tag(s) patch.
Added tag(s) patch.
Added tag(s) patch.
Added tag(s) patch.
Added tag(s) patch.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

From forum: Emacs - Bugs