headers
Leo | 5 Nov 2009 02:05
Picon
Gravatar

bug#4871: 23.1.50; Quit: "empty or unsupported pasteboard type"

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

1. Emacs -q
2. (setq save-interprogram-paste-before-kill t)
3. Highlight some region and hit M-w

You should hear a beap and then a message in the echo area `` Quit:
"empty or unsupported pasteboard type" ''.

In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-09-22 on neutron.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Leo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 5 Nov 2009 02:57
Picon
Picon

bug#4848: 23.1.50; \u and \x in string

    > Why shouldn't \ue1 work?

    Because the \u format is \uNNNN with exactly 4 hex digits.

In other words, "it doesn't work because we decided it should't work".
But why should't it work?  Why shouldn't two digits be allowed?

Is there a good reason not to allow that?
Permalink | Reply | 1 comment |
headers
Richard Stallman | 5 Nov 2009 02:56
Picon
Picon

bug#4848: 23.1.50; \u and \x in string

    I'm not sure what you wanted to be documented.  Is the description in
    "(elisp)General Escape Syntax" what you were looking for?

The version I have is from August.  If it has been substantially
improved since then, maybe it is good.  The text from August was
inadequate and even wrong:

      To use hex, write a question mark followed by a backslash,  <at> samp{x},
    and the hexadecimal character code.  You can use any number of hex
    digits, so you can represent any character code in this way.
    Thus,  <at> samp{?\x41} for the character  <at> kbd{A},  <at> samp{?\x1} for the
    character  <at> kbd{C-a}, and  <at> code{?\x8e0} for the Latin-1 character
     <at> iftex
     <at> samp{ <at> `a}.
     <at> end iftex
     <at> ifnottex
     <at> samp{a} with grave accent.
     <at> end ifnottex

And here is something from Non-ASCII In Strings:

      You can also represent a multibyte non- <at> acronym{ASCII} character with its
    character code: use a hex escape,  <at> samp{\x <at> var{nnnnnnn}}, with as many
    digits as necessary.  (Multibyte non- <at> acronym{ASCII} character codes are all
    greater than 256.)  Any character which is not a valid hex digit
    terminates this construct.  If the next character in the string could be
    interpreted as a hex digit, write  <at> w{ <at> samp{\ }} (backslash and space) to
    terminate the hex escape---for example,  <at> w{ <at> samp{\x8e0\ }} represents
    one character,  <at> samp{a} with grave accent.   <at> w{ <at> samp{\ }} in a string
    constant is just like backslash-newline; it does not contribute any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 5 Nov 2009 03:02
Picon

bug#4868: 23.1; "No fileset is available here"

>> I modified a file in a git-managed directory.
>> Then I typed `C-x v ='.
>> I got an error: "No fileset is available here".

> Is this file not registered with Git?

> If yes, then that's the error it would get.
> emacs-22 used to have a nicer looking error in that case: "File is not
> under version control".   Not sure why that check got removed, there's
> nothing in the ChangeLog to explain it :-(

Would the patch below make sense?  After all, at that point we've
already checked we're visiting a file, there's no backend and we're not
in vc-dir-mode, so a message like "No fileset is available here" is
probably never right.

        Stefan

=== modified file 'lisp/vc.el'
--- lisp/vc.el	2009-10-24 18:33:25 +0000
+++ lisp/vc.el	2009-11-05 02:00:24 +0000
 <at>  <at>  -922,7 +922,7  <at>  <at> 
 		nil)
 	(list (vc-backend-for-registration (buffer-file-name))
 	      (list buffer-file-name))))
-     (t (error "No fileset is available here")))))
+     (t (error "File is not under version control")))))

 (defun vc-ensure-vc-buffer ()
   "Make sure that the current buffer visits a version-controlled file."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Nicolaescu | 5 Nov 2009 03:14
Picon

bug#4868: 23.1; "No fileset is available here"

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

  > >> I modified a file in a git-managed directory.
  > >> Then I typed `C-x v ='.
  > >> I got an error: "No fileset is available here".
  > 
  > > Is this file not registered with Git?
  > 
  > > If yes, then that's the error it would get.
  > > emacs-22 used to have a nicer looking error in that case: "File is not
  > > under version control".   Not sure why that check got removed, there's
  > > nothing in the ChangeLog to explain it :-(
  > 
  > Would the patch below make sense?  After all, at that point we've

Looks fine to me.

  > already checked we're visiting a file, there's no backend and we're not
  > in vc-dir-mode, so a message like "No fileset is available here" is
  > probably never right.

  > 
  >         Stefan
  > 
  > 
  > === modified file 'lisp/vc.el'
  > --- lisp/vc.el	2009-10-24 18:33:25 +0000
  > +++ lisp/vc.el	2009-11-05 02:00:24 +0000
  >  <at>  <at>  -922,7 +922,7  <at>  <at> 
  >  		nil)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 5 Nov 2009 03:48
Picon

bug#4848: 23.1.50; \u and \x in string

>> Why shouldn't \ue1 work?
>     Because the \u format is \uNNNN with exactly 4 hex digits.

> In other words, "it doesn't work because we decided it should't work".
> But why should't it work?  Why shouldn't two digits be allowed?
> Is there a good reason not to allow that?

I think the \u format is taken from C and it doesn't have an "end" like
our \x format has.  So for example "\u11111" means (concat "\u1111" "1").

        Stefan
Permalink | Reply | 0 comments |
headers
Glenn Morris | 5 Nov 2009 04:28
Picon

bug#4533: reverting fails to update line ending mode line


Hi,

Could you comment on this

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4533#15

(it seems related to your final comment in bug#1039)

The behaviour in this case seems odd to me, given that the coding
system is never explicitly specified.
Permalink | Reply | 2 comments |
headers
Emacs bug Tracking System | 5 Nov 2009 04:35

Processed: control

Processing commands for control <at> emacsbugs.donarmstrong.com:

> close 1363
bug#1363: Advertised key-bindings
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to Stefan Monnier <monnier <at> iro.umontreal.ca>

> close 1531
bug#1531: intro-string in byte-compiled files
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to Stefan Monnier <monnier <at> iro.umontreal.ca>

> close 2797
bug#2797: 23.0.91; problem with mairix entry in /usr/local/share/info/dir
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to Peter Dyballa <Peter_Dyballa <at> Freenet.DE>

> tags 4858 moreinfo
Bug #4858 [emacs] 23.1.50; Lines truncated, word-wrap=t and truncate-partial-...=nil
Added tag(s) moreinfo.
> reassign 3972 emacs,cc-mode
Bug #3972 [emacs] 23.1.50; c-mode sets M-q to c-fill-paragraph
bug reassigned from package 'emacs' to 'emacs,cc-mode'.
Warning: Unknown package 'cc-mode'
Warning: Unknown package 'cc-mode'
Warning: Unknown package 'cc-mode'
Warning: Unknown package 'cc-mode'
Warning: Unknown package 'cc-mode'
> tags 3859 moreinfo
Bug #3859 [emacs,w32] 23.1.50; (make-frame '(visibility)) problem on w32
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenichi Handa | 5 Nov 2009 05:17

bug#4533: 23.1: reverting fails to update line ending mode line

In article <1afaf6160909221901p527cca80jcbf81e589cde629d <at> mail.gmail.com>, Benjamin Peterson
<benjamin <at> python.org> writes:

> I had a buffer with a mode line like this:
> - U:(DOS)

> I ran dos2unix on the file, and did M-x revert-buffer.

> The DOS stayed in the mode line until I killed the buffer and
> revisited the buffer.

I found that insert-file-contents forgets to update
buffer-file-coding-system in case of replace.  I've just
installed a fix.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply | 0 comments |
headers
Kenichi Handa | 5 Nov 2009 05:18

bug#4533: reverting fails to update line ending mode line

In article <wfiqdpd508.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:

> Could you comment on this

> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4533#15

I've just installed a fix, and replied to the above message.

> (it seems related to your final comment in bug#1039)

I don't think so.  As I wrote in the mail, it's a simple bug
in insert-file-contents.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply | 1 comment |

Gmane