headers
Miles Bader | 1 Jul 2009 02:03
Picon
Gravatar

Re: patch for nsterm.m to fix visual-bell

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> This patch changes it to be 1 line height at the bottom of the window over
>> the minibuffer much like the previous visual-bell in 22.3. 22.3  also has
>
> That sounds fairly good.  I'd still expect the visual-bell to be
> implemented in the generic code

Or in elisp:  http://www.emacswiki.org/emacs/MilesBader#toc3

-miles

--

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.
Permalink | Reply | 2 comments |
headers
Juri Linkov | 1 Jul 2009 02:02
Favicon
Gravatar

Re: & and M-& to run programs asynchronously

>> Below is a ready patch submitted for verification before checking in:
>
> As it stands its usefulness is rather dubious: the user could just as
> easily type the extra & at the end.  Could someone remind me what were
> the arguments for adding it?  What are the expected use-cases and
> planned improvements?

Sure, in its current state it is useless.  That's why I said
it is just a starting point for adding more options relevant only
for asynchronous commands.  These options include using M-& as an
application launcher that will allow automatic creation of
multiple *Async Shell Command* buffers, deciding whether to
display the output buffer for GUI apps or not, etc.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Permalink | Reply | 6 comments |
headers
Juri Linkov | 1 Jul 2009 02:01
Favicon
Gravatar

Re: Virtual Info files and nodes

>>>>> - Why check (stringp filename) in Info-virtual-file?  Isn't it an
>>>>> error to call it with something else than a string.
>>>> Really only nil can be expected now,
>>> Can it?  In which circumstance?
>> `filename' can be nil when `Info-virtual-fun' is called with non-nil
>> `nodename'
>
> That part is obvious enough.
>
>> to check for a node name when a file name is irrelevant -
>> its argument value is nil in this case.
>
> But again: is that ever the case?
> I'd think a node name can only be meaningful when accompagnied by a filename.

There are valid calls with filename=nil where nil means the current
Info file: in Info-find-node-2 filename=nil means to not re-read
the current Info file, other places rely on the value nil returned
from Info-find-file when its argument filename is nil since this
function checks for (stringp filename).  So the same check should be
also in Info-virtual-fun because a call to Info-virtual-fun is outside
of branches that check for a non-string filename in Info-find-file
and Info-find-node-2.

>> This is done in the next version below with other fixes including the
>> handling of "dir":
>
> Thanks, looks fairly good now.  I just worry a little bit about binding
> inhibit-read-only around the call to (Info-virtual-call virtual-fun
> filename nodename no-going-back) since that may involve a lot of code
(Continue reading)

Permalink | Reply | 1 comment |
headers
Miles Bader | 1 Jul 2009 03:03
Picon
Gravatar

Re: & and M-& to run programs asynchronously

Juri Linkov <juri <at> jurta.org> writes:
>> As it stands its usefulness is rather dubious: the user could just as
>> easily type the extra & at the end.  Could someone remind me what were
>> the arguments for adding it?  What are the expected use-cases and
>> planned improvements?
>
> Sure, in its current state it is useless.  That's why I said
> it is just a starting point for adding more options relevant only
> for asynchronous commands.  These options include using M-& as an
> application launcher that will allow automatic creation of
> multiple *Async Shell Command* buffers, deciding whether to
> display the output buffer for GUI apps or not, etc.

I agree -- a separate command feels much cleaner to me than insisting
the user type "&" at the end of the command.  The "&" syntax is a nice
_add-on_ hack for people used to using a shell, but it shouldn't be the
primary method of invocation for background apps.

I personally would often like to use emacs to launch GUI apps, rather
than needing to use a shell or search through menus.

In general, the current Emacs support for asynchronous apps seems quite
clumsy.  I usually don't want the "*Async Shell Command*" output buffer,
or at least, don't want to see it unless there's actually some
output... (which there usually isn't).  The current restriction to a
single background app is simply dumb.

Fixing those problems isn't necessarily connected with having a
separate command -- both forms of invocation should benefit -- but the
dedicated command still seems a much nicer interface to me
(Continue reading)

Permalink | Reply | 4 comments |
headers
Glenn Morris | 1 Jul 2009 03:45
Picon

NEWS/antinews inconsistency


NEWS says support for libc5, COFF BSD, etc, will be removed in some
Emacs version after 23.1 (ie, is still present in 23.1).

antinews says support for those platforms will be added in Emacs 22.3
(ie, was not present in 23.1).

Timeline error... boom!
Permalink | Reply | 1 comment |
headers
Stephen J. Turnbull | 1 Jul 2009 08:09
Picon
Favicon

Re: cl-macs and (require 'cl)

Lennart Borgman writes:

 > The reason I am asking is that eieio.el

*shiver*

eieio has special needs.  You should ask the author(s) why they did it
this way, rather than using `(eval-when-compile (require 'cl))'.  If
they don't have any particular reason other than "well, it's been like
that since 1997", then you could try changing it to the recommended
form.
Permalink | Reply | 2 comments |
headers
Lennart Borgman | 1 Jul 2009 11:43
Picon
Gravatar

Re: cl-macs and (require 'cl)

On Wed, Jul 1, 2009 at 8:09 AM, Stephen J. Turnbull<stephen <at> xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > The reason I am asking is that eieio.el
>
> *shiver*
>
> eieio has special needs.  You should ask the author(s) why they did it
> this way, rather than using `(eval-when-compile (require 'cl))'.  If
> they don't have any particular reason other than "well, it's been like
> that since 1997", then you could try changing it to the recommended
> form.

Yes, that is why I asked here. Eric said he will change it.

But I do not know of any particular reason for including cl.el and
cl-macs.el like they did. Maybe you could explain?
Permalink | Reply | 1 comment |
headers
Eric M. Ludlam | 1 Jul 2009 13:25
Gravatar

Re: cl-macs and (require 'cl)

On Wed, 2009-07-01 at 11:43 +0200, Lennart Borgman wrote:
> On Wed, Jul 1, 2009 at 8:09 AM, Stephen J. Turnbull<stephen <at> xemacs.org> wrote:
> > Lennart Borgman writes:
> >
> >  > The reason I am asking is that eieio.el
> >
> > *shiver*
> >
> > eieio has special needs.  You should ask the author(s) why they did it
> > this way, rather than using `(eval-when-compile (require 'cl))'.  If
> > they don't have any particular reason other than "well, it's been like
> > that since 1997", then you could try changing it to the recommended
> > form.
> 
> Yes, that is why I asked here. Eric said he will change it.
> 
> But I do not know of any particular reason for including cl.el and
> cl-macs.el like they did. Maybe you could explain?

Indeed, that is just the way it has been for a long time.  I did try
switching to the `eval-when-compile' part, but this doesn't work.  EIEIO
has functions which create types with deftype, and uses typep.  If I
wrap the require of cl as above, then sources creating classes can't
find the typep symbol.

It could be I am using deftype and typep in some inconsistent way.  If
someone is interested in pointing out the correct way to do these
things, I'd appreciate it.

You can look at EIEIO w/out getting the whole CEDET suite here:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenichi Handa | 1 Jul 2009 14:39

Re: cp949 support

In article <863a9vb8jg.fsf <at> nirvana.pusto.de>, Eduard Wiebe <usenet <at> pusto.de> writes:

> PS: Sorry when i recur, but can we add following patch to improve
> information about korean language/environment?

> 2009-06-20  Eduard Wiebe  <usenet <at> pusto.de>

> 	* language/korean.el (set-language-info-alist): Add korean-cp949,
> 	cp949 to spec.

I've just installed that change to the trunk and the 23.1
branch.

---
Kenichi Handa
handa <at> m17n.org

> --=-=-=
> Content-Type: text/x-patch; charset=utf-8
> Content-Disposition: inline; filename=korean.diff
> Content-Transfer-Encoding: 8bit

> diff --git a/lisp/language/korean.el b/lisp/language/korean.el
> index e8e78bf..07382df 100644
> --- a/lisp/language/korean.el
> +++ b/lisp/language/korean.el
>  <at>  <at>  -70,11 +70,11  <at>  <at> 
>  	    (exit-function . exit-korean-environment)
>  	    (iso639-language . ko)
>  	    (tutorial . "TUTORIAL.ko")
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Jul 2009 15:04
Favicon

Re: NEWS/antinews inconsistency

Glenn Morris <rgm <at> gnu.org> writes:

> NEWS says support for libc5, COFF BSD, etc, will be removed in some
> Emacs version after 23.1 (ie, is still present in 23.1).
>
> antinews says support for those platforms will be added in Emacs 22.3
> (ie, was not present in 23.1).
>
>
> Timeline error... boom!

Fixed, thanks.
Permalink | Reply | 0 comments |

Gmane