Lennart Borgman (gmail | 1 Aug 21:53 2008
Picon

Re: On cut, copy, paste etc...

Eli Zaretskii wrote:
> Okay, but what does all this have to do with the original issue?  You
> are asking for a different behavior of C-w; I'm saying that no matter
> how it behaves wrt the X selection and the clipboard, we could modify
> kill-region in small ways so that clipboard-kill-region would be
> unnecessary, and we then could bind kill-region to menu-bar>Edit>Cut.

It sounds like a good thing to me.

Beside that I suggest applying something like the patch below to 
cua-base.el for similar reasons.

Index: cua-base.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emulation/cua-base.el,v
retrieving revision 1.98
diff -u -b -r1.98 cua-base.el
--- cua-base.el	27 Jun 2008 07:34:47 -0000	1.98
+++ cua-base.el	1 Aug 2008 19:44:20 -0000
 <at>  <at>  -1514,6 +1514,61  <at>  <at> 

  (defvar cua--saved-state nil)

+(defun cua-show-cua-in-edit-menu()
+  "Change the binding hints in the menus for CUA keys.
+If `cua-mode' is on then this function may change the binding
+hint text in the edit menu for the CUA keys C-c, C-x and C-v to
+show those strings.
+
+For this to happen the variable `cua-show-cua-in-edit-menu' must
(Continue reading)

Lennart Borgman (gmail | 1 Aug 22:00 2008
Picon

A lot of ^M in src/Changelog today

Just happened today. Yesterday it was ok.

Ted Zlatanov | 1 Aug 22:30 2008
X-Face

Re: eshell-defgroup. Do we really need this?

On Fri, 01 Aug 2008 19:08:04 +0200 Romain Francoise <romain <at> orebokech.com> wrote: 

RF> Hi Ted,
RF> Ted Zlatanov <tzz <at> lifelogs.com> writes:

>> Romain, can you set up build failures to be aggregated?  I can set
>> up buildbot (send me your setup if you can) for a confirmation
>> run; if both our builds fail then the Emacs CVS trunk is probably
>> broken.

RF> My experience with running this buildbot (and others) suggests that
RF> there is little value in doing this; buildbot does a clean build
RF> every time so if it fails then we can be fairly sure that CVS is
RF> broken.

You think so even considering the large amount of people that would get
this report?  I'd rather be cautious and have at least one confirmation
of the failure before reporting it.  But, of course, it's your
choice--as long as we report something.

RF> I'm not sure which platform you were offering to build on, but the
RF> standard way to set up a buildbot is to have a master instance with
RF> one builder per platform, say one for Debian, one for Windows, one
RF> for Mac OS X, etc. The instance at http://emacsbuild.orebokech.com/
RF> only has builders for Debian etch, having more would be nice.

I can set mine up on Ubuntu 6.x and 7.x and MacOS X.  Send me your
buildbot config so I know we're doing the same things.  It's probably
good to publicize these, actually, so others can set up Emacs buildbots
easily.  Maybe the Emacs wiki would be a good place to post the config?
(Continue reading)

David De La Harpe Golden | 1 Aug 22:30 2008
Picon

Re: On cut, copy, paste etc...

Eli Zaretskii wrote:

> Okay, but what does all this have to do with the original issue?

How C-w and menu-bar-≥edit->cut differ : one sets the
primary selection, and the other the clipboard....

(well, actually depends on x-select-enable-primary/clipboard
customisation too)

>  You are asking for a different behavior of C-w;

In my own opinion, menu-bar cut should ultimately do the same as C-w,
but not before other changes are introduced so that people
can still separately set primary and clipboard _somewhow_.

> I'm saying that no matter
> how it behaves wrt the X selection and the clipboard, we could modify
> kill-region in small ways so that clipboard-kill-region would be
> unnecessary, and we then could bind kill-region to menu-bar>Edit>Cut.

BUT there are people who apparently prefer C-w setting PRIMARY (see last
thread...). They may then _like_ the menu being different, for when they
_do_ want to set CLIPBOARD. (similar for C-y and paste getting).

My patch allowed, for active region, keyboard, menu+toolbar and mouse
operations, separate configuration of which x selections were got/set
(and whether the kill-ring was involved sometimes).

Certainly, if there was a decision to have menu-bar cut always do the
(Continue reading)

Angelo Graziosi | 1 Aug 22:47 2008
Picon

Re: Warning starting Emacs (Cygwin)

Dan Nicolaescu ha scritto:
> Angelo Graziosi <angelo.graziosi <at> alice.it> writes:
> 
>   > Dan Nicolaescu ha scritto:
>   > > Angelo Graziosi <angelo.graziosi <at> alice.it> writes:
>   > >
>   > >   > I wrote:
>   > >   >   > > starting Emacs it opens a buffer called Warnings in which
>   > > it prints:
>   > >   > >
>   > >   > > <beep>
>   > >   > > Emergency (alloc): Warning: past 95% of memory limit
>   > >   >   >   > I think there is some new problem.
>   > >   >   > Downloading cvs-trunk with -D "20080730 17:14" bootstraps
>   > > and works
>   > >   > without warning.
>   > >   >   > Instead -D "20080730 17:15" fails to bootstrap, but it is
>   > > solved with
>   > >   > the patch discussed here [1] or using systty.h from "20080730 17:14".
>   > >   >   > After solving the bootstrap problem the warning shows up.
>   > >   >   > Below [2] there are the differences between "20080730 17:14"
>   > > and
>   > >   > "20080730 17:15" and it seem hard to think that the patch is the cause
>   > >   > of the warning.
>   > >   >   > Perhaps the new handling (in 20080730 17:15) of getrlimit?
>   > >
>   > > Can you please try to verify that?  Doing a "cvs update" and
>   > > removing #undef HAVE_GETRLIMIT from
>   > > config.in should be enough.
>   > 
(Continue reading)

Ted Zlatanov | 1 Aug 23:07 2008
X-Face

Re: composed characters question and suggestions for quail-cyrillic-*

I updated NEWS with a brief summary of the cyrillic-translit method
changes.  Juri, feel free to adjust as needed.

Ted

Stephen Eilert | 1 Aug 23:27 2008
Picon

Emacs Package Management

Disclaimer: I have no idea if I am flogging a dead horse. If so, please disregard.

Compared to most people here, I am a pretty young Emacs user, barely a year and a half since I've "converted". However, my .emacs is already growing huge.

Part of this is due to Ruby on Rails development. I had to gather quite a lot of scripts to do what I want (rails-mode, nxhtml-mode, rinari [for find-file-in-project], color-theme, rdebug) and so on. This setup *almost* works, as some of the scripts do not play well with each other.

Since there appears to be work under way to get some IDE-like features into Emacs, I suppose some kind of "packaging system" wouldbe helpful. I have tried ELPA (http://tromey.com/elpa/) and loved its simplicity. It's an order of magnitude more convenient than seaching the web for a package, finding the appropriate download site, getting the latest revision, studying the README to figure out how to install it, copying it to .emacs.d and adding to .emacs... I am sure everyone here has done that, countless times.

With a slightly improved system, we could have dependencies. This could make easier to solve the aforementioned problem of gathering multiple, independent packages from different sources. 

Also, some packages have built-in bug reporting, but not all of them do. Some of them are maintained in the Emacs Wiki, some are not maintained at all, some have changed places more than once. Getting a package system inside Emacs *could* allow for simpler updating and a simpler way to notify bugs. I am aware of emacsbug, but it does require the ability to send e-mails from inside Emacs and is not aware of packages (obviously).

Has this already been tried before? My searches point to XEmacs, but I haven't installed it to see what its package manager looks like. 

Does anyone see a major flaw in a system like that? Or is it a matter of "show me the code and I'll comment"? ELPA could be the starting point.

--Stephen


programmer, n:
A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Nick Roberts | 2 Aug 00:30 2008
Picon

Re: Cocoa Emacs (2)

 > > In Cocoa Emacs using TAB in the GUD buffer (gud-gdb-complete-command)
 > > causes Emacs to freeze (C-g frees it).  It gets stuck waiting in
 > > accept-process-output in gud-gdb-run-command-fetch-lines.
 > 
 > I can't replicate it (Emacs -Q, M-x gud RET TAB) on Leopard.

TAB needs to be used as a completion.  Maybe you mean this, but just to be
clear, asssuming you have an executable called myprog:

M-x gdb<RET>
Run gdb (like this): gdb --annotate=3 ~/myprog

Then in the GUD buffer, doing:

Current directory is /home/nickrob/
GNU gdb 6.6-debian
...
(gdb) b m<TAB>

should complete on "m" if there is just one completion, e.g malloc <at> plt, or
generate a completions buffer if there is more than one.

YMMV but I have found this quite a good mode to debug Emacs itself.

 > Any special config details or anything else I should know?

I don't think so, but I, as I say, I don't really know what I'm doing on
Mac OS X.  I'll have another look.  Meanwhile, does anybody else see/not see
this?

--

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

Tom Tromey | 2 Aug 00:58 2008
Picon

Re: Emacs Package Management

>>>>> "Stephen" == Stephen Eilert <spedrosa <at> gmail.com> writes:

Stephen> With a slightly improved system, we could have
Stephen> dependencies. This could make easier to solve the
Stephen> aforementioned problem of gathering multiple, independent
Stephen> packages from different sources.

Just FYI -- package.el (the elisp side of ELPA) does handle dependencies.

:-)

Stephen> Does anyone see a major flaw in a system like that? Or is it
Stephen> a matter of "show me the code and I'll comment"? ELPA could
Stephen> be the starting point.

There was a discussion a while ago on this list.  RMS wanted to
restrict the available packages to those which had been assigned to
the FSF, but I did not agree with that.

I would reconsider my position if the Emacs maintainers were
interested -- I think it would be useful to Emacs users if there were
a simple, standard way to install and activate packages.

However, this would still not help you directly, because I think some
of the packages you want are not assigned.  So, you would have to
solve that problem as well.

Tom

Phil Hagelberg | 2 Aug 01:14 2008

Re: Emacs Package Management

Tom Tromey <tromey <at> redhat.com> writes:

> Stephen> Does anyone see a major flaw in a system like that? Or is it
> Stephen> a matter of "show me the code and I'll comment"? ELPA could
> Stephen> be the starting point.
>
> There was a discussion a while ago on this list.  RMS wanted to
> restrict the available packages to those which had been assigned to
> the FSF, but I did not agree with that.
>
> I would reconsider my position if the Emacs maintainers were
> interested -- I think it would be useful to Emacs users if there were
> a simple, standard way to install and activate packages.
>
> However, this would still not help you directly, because I think some
> of the packages you want are not assigned.  So, you would have to
> solve that problem as well.

As the original author of rinari, I can see a place for packages in such
a system that are not part of Emacs, but still have their copyright
assigned to the FSF. I have a number of elisp packages that are not
candidates for inclusion in Emacs (for a number of reasons, including
rapid change rate, usage of the CL library, or just limited appeal), and
I would be glad to assign copyright over if it meant that they could be
distributed via a built-in package manager.

This would make them much, much easier to install and try out, which I
think is a big win for the overall Elisp ecosystem. People are more
likely to get interested and contribute if you lower the barrier to
trying new things.

It seems the debate so far has been held in terms of "packaging system"
vs "don't make it too easy to install non-FSF-copyrighted code", but I
don't think the two need to be mutually exclusive.

-Phil


Gmane