headers
Juri Linkov | 1 Dec 2009 01:02
Favicon
Gravatar

Re: Case mapping of sharp s

>> I tried this out, but it has no effect.  Maybe this used to work
>> in some older versions, but doesn't work in 23.1.
>
> Strange. Here it works with both 23.1 and current CVS trunk.
> After evaluating the expression, did you create a new buffer?
> (set-standard-case-table sets the case table for new buffers only.)

Thanks, I missed the fact that it affects new buffers.  So it works.
Provided it doesn't make the search slow, it would be nice to add
it to Emacs activating on some user settings.

Ignoring combining accents would be nice to have too, but perhaps
this is not possible to do using a case table?

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Permalink | Reply | 0 comments |
headers
Stephen J. Turnbull | 1 Dec 2009 02:21
Picon
Favicon

Re: Basic Bazaar guide for Emacs hackers.

Óscar Fuentes writes:

 > Stephen: I'll like to put back that workflow on the available
 > documentation.

You're misrepresenting what I wrote.  Please don't do that.
Permalink | Reply | 0 comments |
headers
Stephen J. Turnbull | 1 Dec 2009 02:53
Picon
Favicon

Re: Basic Bazaar guide for Emacs hackers.

Eli Zaretskii writes:

 >  . The page is biased towards contributors who don't have write access
 >    to the Emacs repository.  Notably, it gives almost all examples
 >    using the HTPP URL, not the SFTP one.

That's right, but the reason I left it that way was not "committers"
vs. "others".  It's "URLs we are almost sure will work" vs. "URLS we
hope will be replaced by much better schemes".  If at all possible, we
want the SFTP URL to be replaced by bzr+ssh, but that does not work at
all right now.  My logic is that as it stands, the reader who doesn't
remember the committer URL must go back to the beginning, where she
will see the warning about possibly changing URLs.

 <at> RMS: Is there no chance that you will intervene and ask the Savannah
admins to increase the priority of bzr+ssh?  This is extremely
important to the uptake of Bazaar on Savannah.  With dumb transports
like HTTP and SFTP, frequently network transfers of 25MB have been
observed in the process of committing a tiny (~10 lines) patch,
because a whole pack (essentially, a zip file full of diffs
representing revisions) gets transferred from the local system to the
upstream master.  With a bzr server, only the diff need be sent, and
the pack is rewritten on the upstream master's host.  This affects all
committer workflows, and IIRC locks the repository so that other
committers cannot write (AFAIK it's still readable, but of course
readers will get stale data).

But the concerns of the Savannah hackers are valid.  Although
discussion on bazaar <at> canonical.com indicates that their security
analysis is incorrect, they must convince themselves that is true, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen J. Turnbull | 1 Dec 2009 03:20
Picon
Favicon

Re: Making the tarball with bzr data

Lennart Borgman writes:

 > Why do I have to copy the files? Why can't this setup be done with
 > the already existing files?

Basically, because Bazaar is not git.  In git, each object is
summarized with an SHA1 hash, and so you can verify that you have a
clean tree (with very high probability) without actually comparing the
file content.  Bazaar uses a different, history-dependent method to
track files, assigning a globally unique, *permanent* ID to each
file.  So in order to verify that you have the right files for the
version Bazaar believes to be there, Bazaar must diff every single
file.  If you think about it, you'll see any other behavior would make
Bazaar a very unreliable tool.

There no savings in network transport (Bazaar can't send only the
content of the version you check out), and no savings in local file IO
(in the best case, every file differs in the first byte so you check
them all out anyway), by reusing existing files.

N.B. Reuse of an existing tree is a theoretical possibility only in
git.  AFAIK it has not been implemented.

In Bazaar, I suspect you can do the following:

1.  bzr branch --treeless <Emacs trunk URL> tmp
2.  mv tmp/.bzr <existing Emacs tree top directory>

But this doesn't save any network transport (you still get all the
branch data), and not much time locally since bzr will need to diff
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chong Yidong | 1 Dec 2009 03:18
Favicon

Mail mode and message mode hooks

I'd like to hear some opinions on how to treat the mail mode and message
mode hooks, given that message-mode is to be the default.

As it stands, anyone using feedmail will likely suffer breakage in
upgrading to Emacs 23.2, as shown in bug#3942.  The feedmail package
relies on hooks, and contains documentation like this:

   feedmail-mail-send-hook-splitter is a Lisp function in `feedmail.el'.

   (feedmail-mail-send-hook-splitter)

   Facilitate dividing `mail-send-hook' things into queued and immediate
   cases.  If you have `mail-send-hook' functions that should only be
   called for sending/ queueing messages or only be called for the
   sending of queued messages, this is for you.  Add this function to
   `mail-send-hook' with something like this:

       (add-hook 'mail-send-hook 'feedmail-mail-send-hook-splitter)

So, the message-*-hook variables should probably be aliased to the
mail-*-hook variables.

One problem that I can see with this is that code intended for one mode
may not work properly for the other mode, but I can't think of any
concrete examples.  Any thoughts?
Permalink | Reply | 10 comments |
headers
Óscar Fuentes | 1 Dec 2009 03:40
Picon

Re: Making the tarball with bzr data

"Stephen J. Turnbull" <stephen <at> xemacs.org> writes:

[snip]

> Probably the best procedure is
>
> 1.  bzr branch <Emacs trunk URL> bzr-emacs
> 2.  rsync <options> old-emacs bzr-emacs
>
> assuming that rsync has appropriate options to ensure that it won't
> change the stat data (specifically size and timestamp, IIRC) that bzr
> uses to check if a file has been changed.

There is nothing wrong with changing the timestamp of a file versioned
under Bazaar. It will be not flagged as modified on `bzr status'.

OTOH, a change on size indicates a change on content, and this will be
flagged as an edited file (modulo eol settings, which bazaar supports as
system-wide options).

Lennart: if you copy files on Windows from your CVS working tree to your
bzr working tree maybe you will see files flagged as modified due to
differences on eol.

[snip]

--

-- 
Óscar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glenn Morris | 1 Dec 2009 04:22
Picon

Re: New bug tracker server

Stefan Monnier wrote:

> trying to access http://debbugs.gnu.org/cgi/bugreport.cgi?bug=850:
>
> An error occurred. Error was: Bad bug log for bug 850. Unable to read records: bad line 'From
tim.vanholder <at> gmail.com Mon Sep 1 03:15:46 2008' in state incoming-recv at
/usr/share/perl5/Debbugs/Log.pm line 256,  line 143. 

I simply commented out the line giving this error (in Log.pm), and it
seems to work fine.
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Dec 2009 04:24
Picon

Re: Making the tarball with bzr data

>>> Why can't this setup be done with the already existing files?
>> It can, but then you need to know which Bzr revision corresponds to the
>> files you have.
> In that case wouldn't it be possible to let bzr assume that the my
> files are checked out from the current revision and then changed? (As
> a separate command of course, for use in those circumstances where it
> might make sense.)

Yes, it'd be possible.  I know of no VCS that allows you to do that
(including CVS, which has had moe yeqars than any other to provide such
a feature), so I think it's just much too low on the list of priorities.

        Stefan
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Dec 2009 04:40
Picon

Re: Mail mode and message mode hooks

> So, the message-*-hook variables should probably be aliased to the
> mail-*-hook variables.

Yes.  Generally, message-mode should be considered as a derived-mode of
mail-mode, I think.  On this basis, it would make sense to run mail
mail-*-hook.

> One problem that I can see with this is that code intended for one mode
> may not work properly for the other mode, but I can't think of any
> concrete examples.  Any thoughts?

I have no idea what kind of code people may run from such hooks.

The main thing to remember: the old behavior is just one setq away.

And as a strong supporter of message-mode, I see nothing wrong with
people preferring mail-mode for themselves.  Heck, I've been living with
exactly such a setq in my .emacs for many years now because I preferred
message-mode over the default mail-mode.

So there is really no need to work that hard at making message-mode work
like mail-mode.  Such a thing would only be needed if we were to drop
mail-mode in favor of message-mode, whereas we're just changing
the default.
Changing defaults is not that big a deal.  We've been doing it for
decades.  Every time some people bitch, of course, but as long as it is
an improvement for the average user, the transient inconvenience is
nothing to worry about.

        Stefan
(Continue reading)

Permalink | Reply | 7 comments |
headers
Richard Stallman | 1 Dec 2009 05:09
Picon
Picon

Re: Basic Bazaar guide for Emacs hackers.

      * On http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs, I've
	moved the recommendation to try the "regular contributor" workflow
	(i.e., BzrForEmacsDevs) to the top, and strengthened it.

You are pushing too hard for people to use the more complex dVCS
workflow.
Permalink | Reply | 0 comments |

Gmane