Nabble - Emacs - Dev

Re: AUTO_COMPOSED_PROP_IDX unused?

2009-11-30T20:14:49Z

> From: Kenichi Handa <handa@...>
> Cc: emacs-devel@...
> Date: Mon, 30 Nov 2009 10:13:18 +0900
>
> In article <83hbsemx26.fsf@...>, Eli Zaretskii <eliz@...> writes:
>
> > In dispextern.h we have:
> > enum prop_idx
> > {
> > AUTO_COMPOSED_PROP_IDX,
> [...]
>
> > However, no one seems to use AUTO_COMPOSED_PROP_IDX. It looks like a
> > left-over from the previous implementation of automatic compositions,
> > which used text properties.
>
> Right. The current Emacs never put `auto-composed' property now.
>
> > OK to delete AUTO_COMPOSED_PROP_IDX from the enumeration?
>
> I think so.
>
> In article <87skbyii7j.fsf@...>, Chong Yidong <cyd@...> writes:
>
> > I'm not sure it's safe. If you want to do it, please wait till after
> > the 23.2 release.
>
> If deleting it causes a problem, it means that we have some
> bug that is currently hidden but will be revealed by unknown
> condition. It is better to find out such a bug if any.

Yidong, do you still want to wait with this until after v23.2, or can
I go ahead and delete AUTO_COMPOSED_PROP_IDX?

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T20:10:55Z

Okay. Your experience trumps over my reasoning. Page deleted.

What page did you delete? I hope it was not your intro to simple use
of Bzr. I saved a copy; if necessary I will republish it.

Re: bzr repository ready?

2009-11-30T20:10:12Z

I think that once you have actually tried the workflow there (after the
switchover) you will find it is not hard to use.

I don't expect to ever try it. I am very busy, and I don't think
it will be worth the effort. I am going to use the simple method.

You're asking people to invest a substantial effort, saying they
will find it worth while. Those who do a substantial amount of
use of bzr may indeed find it so. But I probably won't use it
that much, so for me the investment would not be worth while.
I am sure there are many others in the same position.

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T20:09:55Z

* 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.

Re: Mail mode and message mode hooks

2009-11-30T19:40:20Z

> 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

Re: Making the tarball with bzr data

2009-11-30T19:24:06Z

>>> 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

Re: New bug tracker server

2009-11-30T19:22:28Z

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@... 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.

Re: Making the tarball with bzr data

2009-11-30T18:40:35Z

"Stephen J. Turnbull" <stephen@...> 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

Mail mode and message mode hooks

2009-11-30T18:18:37Z

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?

Re: Making the tarball with bzr data

2009-11-30T18:15:55Z

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
all the files to determine which ones to commit (it will believe they
have *all* changed based on timestamp).

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.

> I have put my little elisp library nXhtml at Launchpad so you can
> download it with bzr. However a lot of people already have nXhtml
> installed, but it was not checked out from Launchpad. It came from a
> zip file or similar.
>
> Now I believed that since bzr is a new modern system it would of
> course have thought of that kind of situation.

No, because Bazaar is a new modern system it assumes you have a new
modern network connection with which to download the Bazaar metadata
and revision history reasonably quickly. This is a one-time cost per
project you work on if you use the workflow recommended in
BzrForEmacsDevs.

> Maybe my believe is crazy. Maybe this should not be possible for some
> reason. But I do not understand why.

It is possible -- with git. Emacs isn't using git. And there are
things that Bazaar can do (eg, tracking renames efficiently) that git
cannot. Unfortunately, tracking renames depends exactly on the
feature I described above (tracking files in bzr vs. tracking content
in git). (In theory you could do both and get the best of both
worlds, but this hasn't been implemented in any VCS AFAIK.)

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T17:48:46Z

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.

@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@... indicates that their security
analysis is incorrect, they must convince themselves that is true, and
that is not costless. Only you have the stature to increase the
priority of that work.

> . A Unix-like system is assumed without any notice to that effect.
> Some commands will not work on Windows without subtle changes. For
> example,
>
> echo "public_branch = http://bzr.savannah.gnu.org/r/emacs/trunk" >> .bzr/branch/branch.conf

In this particular case AFAIK you don't need the quotes on Unix either.

> . "Other Resources" should be at the beginning. Someone who looks
> for a CVS-like way of doing things should not be required to read
> through such a long document to find the alternatives near the end.

You are welcome to edit it that way if you want. I believe you would
certainly have RMS's support in doing that. I'm not going to play
"last patch wins" if you do, and I don't think Karl will either.

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T17:17:08Z

Ó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.

Re: Case mapping of sharp s

2009-11-30T16:02:28Z

>> 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/

Re: Emacs 23.2 pretest freeze?

2009-11-30T15:05:59Z

Chong Yidong <cyd@...> writes:
> We're mostly waiting for Alan's code to land now. Hopefully in a week
> or so.

Thanks.

> That said, I'm still uneasy about the status of message-mode as default;
> I'm not sure we've done enough to smooth the transition from mail-mode
> as default.

I don't know the details of the transition. All I can say is I heartily
support message-mode as default, as it's awesome :-).

Since the freeze doesn't apply to documentation changes, if what you're
worried about can mostly be addressed by doc improvements, then
message-mode isn't an issue as far as the pretest goes anyway, right?

> (One more thing: sometime after the feature freeze and the start of the
> pretest, I will add one additional piece of code: the Python parser for
> Semantic. We're currently waiting for the paperwork. This is an
> extremely self-contained part of Semantic, so it should not impact the
> pretest.)

*nod*

One nice thing about working with Bazaar will be that paperwork delays
will have less impact on development, because it'll be easier for any
developer to try out a branch containing the not-yet-approved changes.
(Whereas in CVS, the "apply a patch and revert it later" process is a
bit awkward -- a shallow but still noticeable gumption sink.)

-Karl

Re: Emacs for new users

2009-11-30T15:02:45Z

On Tue, 24 Nov 2009 23:43:00 +0900 (JST), Renaud Casenave-Péré <renaud@...> wrote:
> From: Richard Stallman <rms@...>
> Subject: Re: Emacs for new users
> Date: Tue, 24 Nov 2009 09:10:53 -0500
>
>> Maybe we should have an "Emacs command immersion mode"
>> which disables all mouse clicks.
>
> `emacs -nw' ?

That's a very good point! At least it worked for me. I learned a far
greater number of key bindings *after* I started using text frames. The
lasting effects of using "emacs -nw" were especially manifest after a
couple of years of Gnus usage inside xterm + screen windows.

I don't necessarily recommend "emacs -nw" sessions for _new_ users, but
it really did help me learn many of the standard key bindings during my
own intermediate period between "newbie Emacs user" and "using Emacs to
do almost everything, including IRC, email, programming and what not".

Re: Bind s-~ to ns-prev-frame for Emacs.app

2009-11-30T15:01:28Z

Matthew Dempsky <matthew@...> writes:

> Would patches like this be better directed to bug-gnu-emacs?

Sure, at least that way they don't get lost.

> On Fri, Nov 27, 2009 at 1:41 AM, Matthew Dempsky <matthew@...> wrote:
> > On OS X, it's standard for Cmd-~ to cycle backwards through windows.
> > Patch below makes Emacs.app follow this convention too. (Currently
> > it's not bound to anything.)
> >
> > --- a/lisp/term/ns-win.el
> > +++ b/lisp/term/ns-win.el
> > @@ -208,6 +208,7 @@ The properties returned may include `top', `left',
> > `height', and `width'."
> > (define-key global-map [?\s-,] 'customize)
> > (define-key global-map [?\s-'] 'next-multiframe-window)
> > (define-key global-map [?\s-`] 'other-frame)
> > +(define-key global-map [?\s-~] 'ns-prev-frame)
> > (define-key global-map [?\s--] 'center-line)
> > (define-key global-map [?\s-:] 'ispell)
> > (define-key global-map [?\s-\;] 'ispell-next)
> >

Re: Emacs for new users

2009-11-30T15:01:07Z

On Mon, Nov 30, 2009 at 11:55 PM, Giorgos Keramidas
<keramida@...> wrote:

> On Mon, 23 Nov 2009 16:04:47 -0500, Chong Yidong <cyd@...> wrote:
>>Lennart Borgman <lennart.borgman@...> writes:
>>>> With that said, I think a solution to the learning-emacs-in-classroom and
>>>> emacs-for-new-users problems is the same: include a .emacs which turns
>>>> on things like CUA mode to make operation more familiar.
>>>
>>> The problem is that it does not work as good as it could in all
>>> situations. Since CUA is not the default not so much effort in
>>> getting rid of all ruogh things. Not that you can't work around them,
>>> but it is not so easy for a newcomer.
>>
>> The primary barrier to CUA is that it destroys the long-established
>> standard that C-c LETTER is free for binding to Emacs user commands.
>>
>> So we won't be moving to CUA any time soon. For those that want it,
>> it's just a click away on the Options menu.
>
> CUA also interferes in a non-trivial manner with `C-x', which is used
> far more often than `C-c'. I am always annoyed a bit when I start
> typing `C-x C-f' but pause half-way through to think of a good name for
> a new buffer, only to notice that a region has just been killed. Oops!

Yes, this is a problem. However you can start the key sequence C-S-x
and C-S-c (instead of C-x and C-s) when the region is highlighted to
avoid cutting/copying.

Re: Emacs for new users

2009-11-30T14:55:34Z

On Mon, 23 Nov 2009 16:04:47 -0500, Chong Yidong <cyd@...> wrote:

>Lennart Borgman <lennart.borgman@...> writes:
>>> With that said, I think a solution to the learning-emacs-in-classroom and
>>> emacs-for-new-users problems is the same: include a .emacs which turns
>>> on things like CUA mode to make operation more familiar.
>>
>> The problem is that it does not work as good as it could in all
>> situations. Since CUA is not the default not so much effort in
>> getting rid of all ruogh things. Not that you can't work around them,
>> but it is not so easy for a newcomer.
>
> The primary barrier to CUA is that it destroys the long-established
> standard that C-c LETTER is free for binding to Emacs user commands.
>
> So we won't be moving to CUA any time soon. For those that want it,
> it's just a click away on the Options menu.

CUA also interferes in a non-trivial manner with `C-x', which is used
far more often than `C-c'. I am always annoyed a bit when I start
typing `C-x C-f' but pause half-way through to think of a good name for
a new buffer, only to notice that a region has just been killed. Oops!

Having said that I like CUA mode a lot (especially the rectangular
selection mode and region highlighting). It is useful even when Emacs
runs inside xterm windows, so it is enabled more often than not in my
Emacs sessions of late.

Re: Emacs 23.2 pretest freeze?

2009-11-30T14:48:58Z

Karl Fogel <kfogel@...> writes:

> In [1], Alan MacKenzie suggested we wait until the 23.2 pretest is out
> before switching to Bazaar, and said he thought the pretest was close --
> end of the month or so.
>
> Is it almost ready?
>
> The thread starting at [2] also implies the end of November. The most
> recent exchange in that thread is [3], also with Alan, in which he says
> his CC mode changes should be done by the end of the month (Yidong
> replies "OK"). I don't know where that stands.

We're mostly waiting for Alan's code to land now. Hopefully in a week
or so.

That said, I'm still uneasy about the status of message-mode as default;
I'm not sure we've done enough to smooth the transition from mail-mode
as default.

(One more thing: sometime after the feature freeze and the start of the
pretest, I will add one additional piece of code: the Python parser for
Semantic. We're currently waiting for the paperwork. This is an
extremely self-contained part of Semantic, so it should not impact the
pretest.)

Re: Making the tarball with bzr data

2009-11-30T14:44:55Z

Lennart Borgman <lennart.borgman@...> writes:

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

You can do this, but it practice, it can cause a bit of confussion if
the files you already have correspond to a different revision than the
tip of the bzr branch you download. How would bzr know that those files
are not edited but instead belongs to a past revision?

> I have put my little elisp library nXhtml at Launchpad so you can
> download it with bzr. However a lot of people already have nXhtml
> installed, but it was not checked out from Launchpad. It came from a
> zip file or similar.
>
> Now I believed that since bzr is a new modern system it would of
> course have thought of that kind of situation. I am a bad manual
> reader so I had probably just not understod how to do it... - it is of
> course possible to update the files using only bzr. That was my
> believe.

First: if all your users had the very same version of your library, you
could distribute a tarballed .bzr/ directory with the necessary
metadata. Expecting this is unrealistic, though.

Second: the amount of traffic you save by re-using the source code on
the target machine is nil: when the user downloads the metadata, he gets
a compressed history of the source code. You could use a lightweight
checkout, and this would be a very short download indeed, but then the
user would be very constrained on their Bazaar usage, as almost all
interesting features of Bazaar are not usable when everything you have
at your disposal is a lightweight branch, apart from risking on the
problem mentioned above.

Third: if you are thinking about Bazaar as a system for distributing
your software, I think that pointing potential users to a bzr branch for
obtaining a copy of your library you are raising the entry barrier quite
a bit, unless your intended audience already knows Bazaar.

> Maybe my believe is crazy. Maybe this should not be possible for some
> reason. But I do not understand why.

It is possible. It is not worthwhile.

[snip]

--
Óscar

Re: Case mapping of sharp s

2009-11-30T14:34:32Z

>>>>> On Mon, 30 Nov 2009, Juri Linkov wrote:

> 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.)

Ulrich

Re: Making the tarball with bzr data

2009-11-30T14:33:58Z

On Mon, Nov 30, 2009 at 10:50 PM, Stefan Monnier
<monnier@...> wrote:
>> Why do I have to copy the files?
>
> Because the files are but a small part of the data that Bzr will want.

Does not that depend on if I want/need the history data locally? If I
do not want to use it at all?

>> 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.)

>> Now I believed that since bzr is a new modern system it would of
>> course have thought of that kind of situation. I am a bad manual
>> reader so I had probably just not understod how to do it... - it is of
>> course possible to update the files using only bzr. That was my
>> believe.
>
> That is the case if your zip file is a zip of the checkout Bzr tree
> (probably a lightweight checkout so it isn't bloated by a complete copy
> of the whole history), in which case it'll include a .bzr directory with
> the necessary metadata.

Thanks.

Re: Bind s-~ to ns-prev-frame for Emacs.app

2009-11-30T14:03:44Z

Would patches like this be better directed to bug-gnu-emacs?

On Fri, Nov 27, 2009 at 1:41 AM, Matthew Dempsky <matthew@...> wrote:

> On OS X, it's standard for Cmd-~ to cycle backwards through windows.
> Patch below makes Emacs.app follow this convention too. (Currently
> it's not bound to anything.)
>
> --- a/lisp/term/ns-win.el
> +++ b/lisp/term/ns-win.el
> @@ -208,6 +208,7 @@ The properties returned may include `top', `left',
> `height', and `width'."
> (define-key global-map [?\s-,] 'customize)
> (define-key global-map [?\s-'] 'next-multiframe-window)
> (define-key global-map [?\s-`] 'other-frame)
> +(define-key global-map [?\s-~] 'ns-prev-frame)
> (define-key global-map [?\s--] 'center-line)
> (define-key global-map [?\s-:] 'ispell)
> (define-key global-map [?\s-\;] 'ispell-next)
>

Re: Case mapping of sharp s

2009-11-30T13:57:17Z

> (let ((eqv-list '("aAàÀáÁâÂãÃäÄåÅ"
> "cCçÇ"
> "eEèÈéÉêÊëË"
> "iIìÌíÍîÎïÏ"
> "nNñÑ"
> "oOòÒóÓôÔõÕöÖøØ"
> "uUùÙúÚûÛüÜ"
> "yYýÝÿ"))
> (table (standard-case-table))
> canon)
> (setq canon (copy-sequence table))
> (mapcar (lambda (s)
> (mapcar (lambda (c) (aset canon c (aref s 0))) s))
> eqv-list)
> (set-char-table-extra-slot table 1 canon)
> (set-char-table-extra-slot table 2 nil)
> (set-standard-case-table table))

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.

In addition to equivalent groups above, it would be nice also
to ignore combining accents.

--
Juri Linkov
http://www.jurta.org/emacs/

Re: Making the tarball with bzr data

2009-11-30T13:50:44Z

> Why do I have to copy the files?

Because the files are but a small part of the data that Bzr will want.

> 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.

> Now I believed that since bzr is a new modern system it would of
> course have thought of that kind of situation. I am a bad manual
> reader so I had probably just not understod how to do it... - it is of
> course possible to update the files using only bzr. That was my
> believe.

That is the case if your zip file is a zip of the checkout Bzr tree
(probably a lightweight checkout so it isn't bloated by a complete copy
of the whole history), in which case it'll include a .bzr directory with
the necessary metadata.

Stefan

Re: Making the tarball with bzr data

2009-11-30T13:27:00Z

On Mon, Nov 30, 2009 at 8:35 PM, Óscar Fuentes <ofv@...> wrote:

> Lennart Borgman <lennart.borgman@...> writes:
>
>> On Mon, Nov 30, 2009 at 7:11 PM, grischka <grishka@...> wrote:
>>>> If I already have all the Emacs files locally (possibly with some
>>>> changes) how do I do to make this a bazaar thing? (This must be the
>>>> most common situation, or?)
>>>
>>> In any case you need to get the official emacs bazaar repository
>>> first.
>>
>>
>> Thanks grischka. I believe you, but this seems just crazy to me.
>
> Why?

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

>> What are the reasons for this limitation?
>
> How is that a limitation?
>
> Let me guess. You are thinking on the CVS checkout you have with all
> those patches for EmacsW32, right?

Partly, but there is another problem. I thought I would get some help
with that since there are some helpful guys here who can teach me a
bit. Maybe I should tell you that problem...

I have put my little elisp library nXhtml at Launchpad so you can
download it with bzr. However a lot of people already have nXhtml
installed, but it was not checked out from Launchpad. It came from a
zip file or similar.

Now I believed that since bzr is a new modern system it would of
course have thought of that kind of situation. I am a bad manual
reader so I had probably just not understod how to do it... - it is of
course possible to update the files using only bzr. That was my
believe.

Maybe my believe is crazy. Maybe this should not be possible for some
reason. But I do not understand why.

> Well, a brute force solution is to setup your personal bzr Emacs branch
> and then simply copy everything from your CVS checkout over the bzr
> branch, or in Windows parlance, copy the contents of the folder
> lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
> everythin. You can remove the CVS directories on the bzr branch, as they
> would be useless once the switch at Savannah is complete.

I am grateful for the explanations you and others have given for this.
I am just surprised that I have to copy the files. It certainly makes
the process slower in several ways. I have to do more. And there will
be more network traffic etc.

> It is a pity that you had no bzr at the time when EmacsW32 was started:
> you could keep a clean history of the applied patches and publish the
> branch on something like launchpad or from your webserver. At least, you
> can start taking advantage from bzr since now: instead of having a
> checkout with lots of patched files, once you copy them over the bzr
> branch commit the changes:
>
> bzr commit -m "All modifications I have so far"
>
> Since this, for applying a new patch:
>
> bzr commit -m "Fixes foo"

Thanks.

> Speaking as somebody who is interested on your modifications, it would
> be great if you could start from a pristine Emacs working tree and
> commit one patch at a time, with a descriptive commit message, then
> publish the branch :-)

I will think about it ;-)

> I'm willing to help you (and anybody else) on the transition to bzr, but
> please be more specific when describing the problems you are foreseeing.
>
> --
> Óscar

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T13:06:12Z

Eli Zaretskii <eliz@...> writes:
>> is there any reason you didn't just make the change, though?
>
> These are largely a matter of methodology: how to present this subject
> to Emacs developers. With all the differences of opinions on issues
> like this between myself and almost everybody else that we've seen
> lately here, I lost confidence that such changes will be welcome.

Oh, those differences have all been about what overall direction to
recommend to developers, which is a larger issue that's not really about
any individual document's structure.

AFAIK, everyone has welcomed organizational edits made to any page --
certainly I have, and so have Óscar and Stephen. Please don't be afraid
to edit. (But I'll take care of this one, since I'm already doing other
stuff on the page.)

-Karl

Re: auto-indent in emacs

2009-11-30T13:05:39Z

Lennart Borgman <lennart.borgman@...> writes:

> On Mon, Nov 30, 2009 at 6:06 PM, Lennart Borgman
> <lennart.borgman@...> wrote:
>>
>>> I think http://www.emacswiki.org/emacs/AltGrKey is obsolete and should
>>> be fixed.
>>
>>
>> Please help rewriting the page.
>
> Since no one answered I am doing that right now.

Sorry, I was into something else.

I saw you added more of these `impossible-to-type' keys. I've thought of
switching the keyboard layout to neo2 already :-)

Thank's for the update.

Sebastian

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T12:36:34Z

> From: Karl Fogel <karl.fogel@...>
> Cc: ofv@..., emacs-devel@...
> Date: Mon, 30 Nov 2009 13:37:06 -0600
>
> is there any reason you didn't just make the change, though?

These are largely a matter of methodology: how to present this subject
to Emacs developers. With all the differences of opinions on issues
like this between myself and almost everybody else that we've seen
lately here, I lost confidence that such changes will be welcome.

> > . "Other Resources" should be at the beginning. Someone who looks
> > for a CVS-like way of doing things should not be required to read
> > through such a long document to find the alternatives near the end.
>
> I was already planning to move the "quick start" links to the beginning,
> along with some explanation. The other other resources can stay where
> they are, I think.

In that case, at least mention right at the beginning that whoever
looks for something like that will find it near the end.

Re: auto-indent in emacs

2009-11-30T12:08:15Z

"Davis Herring" <herring@...> writes:

> > > > Why?
> > > > TAB does `indent-region' just fine
> > >
> > > Only with Transient Mark Mode.
> >
> > i.e. by default.
>
> Well, either `indent-region' is important enough, even in the presence of
> TAB/TMM, to get a keybinding (currently C-M-\), in which case it's

C-M-\ was there before t-m-m was the default.
t-m-m by default just made the binding not as useful as it used to be by
default, but people might still be using it.

TAB is a simple solution, it works by default.
We cannot provide generic solutions for all non-default options.

> worthwhile to consider whether certain keyboards have difficulty
> generating that event, or it's not, in which case we can just get rid of
> the keybinding altogether now that TMM is the default and have one more
> available for user customization (for those users on whose keyboards it is
> a convenient chord). Saying "it's a bad keybinding but we really don't
> want it anyway" strikes me as nonsensical.

I have not said or implied anything of the sort.

Emacs 23.2 pretest freeze?

2009-11-30T11:55:39Z

In [1], Alan MacKenzie suggested we wait until the 23.2 pretest is out
before switching to Bazaar, and said he thought the pretest was close --
end of the month or so.

Is it almost ready?

The thread starting at [2] also implies the end of November. The most
recent exchange in that thread is [3], also with Alan, in which he says
his CC mode changes should be done by the end of the month (Yidong
replies "OK"). I don't know where that stands.

-Karl

[1] http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00674.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00173.html
[3] http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00248.html

Re: auto-indent in emacs

2009-11-30T11:44:48Z

On Mon, Nov 30, 2009 at 8:39 PM, Davis Herring <herring@...> wrote:
>
> Well, either `indent-region' is important enough, even in the presence of
> TAB/TMM, to get a keybinding (currently C-M-\), in which case it's
> worthwhile to consider whether certain keyboards have difficulty
> generating that event, or it's not, in which case we can just get rid of
> the keybinding altogether now that TMM is the default and have one more
> available for user customization (for those users on whose keyboards it is
> a convenient chord). Saying "it's a bad keybinding but we really don't
> want it anyway" strikes me as nonsensical.

I agree. Let us get rid of C-M-\.

And I think we should get rid of the other troublesome keybindings
too, see http://www.emacswiki.org/emacs/AltGrKey where I have listed
those now.

If some of them are important (and I think some of them are) they
should get new key bindings.

Re: auto-indent in emacs

2009-11-30T11:39:33Z

> > > Why?
> > > TAB does `indent-region' just fine
> >
> > Only with Transient Mark Mode.
>
> i.e. by default.

Well, either `indent-region' is important enough, even in the presence of
TAB/TMM, to get a keybinding (currently C-M-\), in which case it's
worthwhile to consider whether certain keyboards have difficulty
generating that event, or it's not, in which case we can just get rid of
the keybinding altogether now that TMM is the default and have one more
available for user customization (for those users on whose keyboards it is
a convenient chord). Saying "it's a bad keybinding but we really don't
want it anyway" strikes me as nonsensical.

Davis

--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Basic Bazaar guide for Emacs hackers.

2009-11-30T11:37:06Z

Eli Zaretskii <eliz@...> writes:
>> Continued improvements to any of the docs welcome, of course.
>
> I fixed one or two factual inaccuracies and slightly improved wording
> in a couple of places.

Thank you!

> What's below are random stylistic and methodological comments. Feel
> free to do anything you want with them, including nothing at all.
>
> . 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. Sometimes it mentions the
> SFTP method, sometimes it does not. It could be a better idea to
> give both variants for each command.

Hmmm. Good point -- I'll take a look and see what I can do. If
anything, it should be biased toward SFTP and mention HTTP as an
alternate method.

> . A Unix-like system is assumed without any notice to that effect.
> Some commands will not work on Windows without subtle changes. For
> example,
>
> echo "public_branch = http://bzr.savannah.gnu.org/r/emacs/trunk" >> .bzr/branch/branch.conf
>
> will not do what you mean with the `echo' that it built into the
> Windows shell. Maybe someone could add footnotes with Windows
> equivalents, where applicable (in this case, either remove the
> quotes or use the ported GNU `echo').

Also a good point. I haven't used Windows for almost 18 years now, so
I'll just put in notes that it's Unix-centric.

> . The single-level sectioning is not the best one in this case,
> because the page actually has 5 top-level sections, which I would
> call Intro, Getting Started, One-Off Change, Feature Branch,
> Resources; and some of these have sub-sections. Presenting them as
> a single-level document makes it harder to grasp the outline of the
> narrative. Suggest to have 2 levels of sections, not one.

I can do that (is there any reason you didn't just make the change,
though?).

> . The "Overview of the Bazaar work routine" is too detailed, IMO, and
> thus unnecessarily longish. We will be explaining all the details
> in a moment, so I think only the main points should be left in this
> overview.

Will take a look and adjust accordingly.

> . "Other Resources" should be at the beginning. Someone who looks
> for a CVS-like way of doing things should not be required to read
> through such a long document to find the alternatives near the end.

I was already planning to move the "quick start" links to the beginning,
along with some explanation. The other other resources can stay where
they are, I think.

Thanks for the review, Eli.

-K

Re: Making the tarball with bzr data

2009-11-30T11:35:59Z

Lennart Borgman <lennart.borgman@...> writes:

> On Mon, Nov 30, 2009 at 7:11 PM, grischka <grishka@...> wrote:
>>> If I already have all the Emacs files locally (possibly with some
>>> changes) how do I do to make this a bazaar thing? (This must be the
>>> most common situation, or?)
>>
>> In any case you need to get the official emacs bazaar repository
>> first.
>
>
> Thanks grischka. I believe you, but this seems just crazy to me.

Why?

> What are the reasons for this limitation?

How is that a limitation?

Let me guess. You are thinking on the CVS checkout you have with all
those patches for EmacsW32, right?

Well, a brute force solution is to setup your personal bzr Emacs branch
and then simply copy everything from your CVS checkout over the bzr
branch, or in Windows parlance, copy the contents of the folder
lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
everythin. You can remove the CVS directories on the bzr branch, as they
would be useless once the switch at Savannah is complete.

It is a pity that you had no bzr at the time when EmacsW32 was started:
you could keep a clean history of the applied patches and publish the
branch on something like launchpad or from your webserver. At least, you
can start taking advantage from bzr since now: instead of having a
checkout with lots of patched files, once you copy them over the bzr
branch commit the changes:

bzr commit -m "All modifications I have so far"

Since this, for applying a new patch:

bzr commit -m "Fixes foo"

Speaking as somebody who is interested on your modifications, it would
be great if you could start from a pristine Emacs working tree and
commit one patch at a time, with a descriptive commit message, then
publish the branch :-)

I'm willing to help you (and anybody else) on the transition to bzr, but
please be more specific when describing the problems you are foreseeing.

--
Óscar