Re: CUA/delete-selection-mode and remapped keys incompatibility
Stefan Monnier [EMAIL PROTECTED] writes: Maybe delete-selection-mode could do what you propose: when self-insert-command is called, it should kill the current command, delete the region, and re-run the command that it just killed. It's also bound to risk introducing bugs. Suppose you had defined slime-space as (defun slime-space () (interactive) (insert )) its effect would be identical, but how would CUA / delete-selection-mode know what to do? So the only safe solution that I can think of is the one currently used. I agree. Maybe it could be improved by making self-insert-command output a warning if the region is active and delete-selection-mode is activated as well. That's a dead end -- delete-selection-mode is not enabled when you use CUA, so it would have to check for CUA-mode too, and so would self-insert-iso, and numerous other commands. I don't think we can improve this without creating other problems. I used to have CUA explicitly know about the commands it modified, but it soon fell apart exactly because people added commands which failed to work with CUA in various ways ... and the only pratical interface is the current one: - where CUA / d-s-m does not have to know the commands explicitly, but can just investigate the properties of the current command, - and those commands can be marked in a trivial way which does not require loading the CUA and delete-selection-mode packages to do the marking ((this is a very good thing about the current approach)). -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No X even though DISPLAY is working
Eric Hanchrow answered my question: If not, then your system lacks the necessary headers and libraries to build X support into Emacs, which would explain what you're seeing. That was the case. I had recently reinstalled the OS on that computer and hadn't yet noticed that I had missed those packages. I apologize with a fed face. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock does not fontify C++ const pointer declaration
I think this bug report got lost somewhere or maybe the fix was incomplete. Emacs 19-21 fontifies the following C++ snippet: int *p; // ok const int *p; // ok int *const p; // not ok in CVS emacs const int *const p; // not ok in CVS emacs so that p is in font-lock-variable-name-face. In Emacs CVS, it does not fontify p when p is declared as a const pointer. (I think it also misfontified in C, when I first reported it, but now C is OK.) Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font Lock on-the-fly misfontification in C++
This bites on a frustratingly regular basis. Put the following in a
fubar.cpp:
class Fubar :
public Foo, // Foo fontified as a type, at first
public Bar// Bar fontified as a type, at first
{
Foo bar(Snafu snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
Foo bar(Snafu *snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
};
Then emacs -Q fubar.cpp. I see Foo, Bar and Snafu fontified as types even
where declaring functions and variables. The corresponding functions and
variables are fontified correctly. This is great!
Then do the following.
1. Append a space to the first (or second) commented line. Bug:
fontification of Foo (and/or Bar) is removed.
2. Append a space to the third commented line. Bug: fontification of Foo
and bar is removed from that line.
3. Append a space to the fourth commented line. Bug: fontification of Foo,
bar, Snafu and snafu is removed from that line.
Somewhat spookily, if you then repeat (2), then the fourth commented line
(3) gets fontified correctly after the deferral delay.
I think this is some sort of problem with Jit Lock mode multiline
fontification, at least for (2) and (3), since Lazy Lock mode works ok. (Of
course, Lazy Lock mode is now depreciated and lazy-lock-mode is not
autoloaded.)
Stefan Monnier kindly posted a possible partial fix (see
http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg01193.html) but
that thread went into a discussion about the font-lock-multiline text
property. I don't know how valid the approach is now (and obviously the
patch was not checked in).
Simon.
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person. Misys Banking
Systems is a trading name of Misys International Banking Systems Limited which
is registered in England and Wales under company registration number 00971479
and with its registered office address at Burleigh House, Chapel Oak, Salford
Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT
OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED.
PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF
THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE
DEALING.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Org-mode agenda and category text-property.
In GNU Emacs 22.0.93.3 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-09 on escpc40 X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk'' I tried to use `C-u C-x =' on some propertised text in an *Org Agenda* buffer (a TODO note), and this resulted in an error with the following backtrace: Debugger entered--Lisp error: (wrong-type-argument symbolp Notes) symbol-name(Notes) describe-property-list((org-agenda-type agenda day 732718 fontified nil category Notes tags nil prefix-length 26 time-of-day nil dotime #(2007-02-11 Sun 0 16 (fontified nil)) face org-warning org-not-done-regexp (TODO\\)\\ mouse-face highlight keymap (keymap (mouse-3 . org-agenda-show-mouse) (mouse-2 . org-agenda-goto-mouse) (left . org-agenda-earlier) (right . org-agenda-later) (S-down . org-agenda-priority-down) (S-up . org-agenda-priority-up) (45 . org-agenda-priority-down) (88 . org-clock-cancel) (79 . org-clock-out) (73 . org-agenda-clock-in) (43 . org-agenda-priority-up) (72 . org-agenda-holidays) (104 . org-agenda-holidays) (83 . org-agenda-sunrise-sunset) (77 . org-agenda-phases-of-moon) (109 . org-agenda-phases-of-moon) (67 . org-agenda-convert-date) (99 . org-agenda-goto-calendar) (105 . org-agenda-diary-entry) (44 . org-agenda-priority) (16 . org-agenda-previous-date-line) (14 . org-agenda-next-date-line) (112 . previous-line) (110 . next-line) (84 . org-agenda-show-tags) (80 . org-agenda-show-priority) (115 . org-save-all-org-buffers) (120 . org-agenda-exit) (113 . org-agenda-quit) (114 . org-agenda-redo) (103 . org-agenda-toggle-time-grid) (68 . org-agenda-toggle-diary) (108 . org-agenda-log-mode) (102 . org-agenda-follow-mode) (48 . digit-argument) (57 . digit-argument) (56 . digit-argument) (55 . digit-argument) (54 . digit-argument) (53 . digit-argument) (52 . digit-argument) (51 . digit-argument) (50 . digit-argument) (49 . digit-argument) (62 . org-agenda-date-prompt) (S-left . org-agenda-date-earlier) (S-right . org-agenda-date-later) (119 . org-agenda-week-view) (100 . org-agenda-day-view) ...) help-echo mouse-2 or RET jump to org file ~/Org/Notes.org org-marker #marker at 271 in Notes.org org-hd-marker #marker at 229 in Notes.org undone-face org-warning done-face org-done priority 1100)) describe-text-properties-1(304 #buffer *text-props*) describe-text-properties(304 #buffer *text-props*) describe-char(304) what-cursor-position((4)) call-interactively(what-cursor-position) This is due to the `category' key with value Notes, which trips up on symbol-name in describe-property-list: (cond ((eq key 'category) (insert-text-button (symbol-name value) Since category is documented as special: `category' If a character has a `category' property, we call it the category of the character. It should be a symbol. The properties of the symbol serve as defaults for the properties of the character. I guess it's an Org-mode bug. Thanks, Matt ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: write-region is mishandling an error
Possibly, I don't have the tools you speak of to tell. But then where is the data going? If the filename was simply being truncated but the data was still being written then I suppose I'd believe no 'error' occurred; that the OS simply sees the : as a file name terminator and continues successfully. But the file is empty. So it seems I'm also being asked to believe that subsequent write operations are also not getting errors. Being a programmer myself I can't help but find a claim that data is being discarded by a modern OS without error hard to believe. -Original Message- From: Richard Stallman [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 8:23 AM To: Richard Bielawski Cc: emacs-pretest-bug@gnu.org Subject: Re: write-region is mishandling an error Which creates an empty file named Test at 12 and no error occurs. Initially I didn't notice that the filename was truncated. Once I did I realized that : is illegal in a file name. Some kind of error must be occurring that isn't being reported. If you run under a debugger with a breakpoint at Fsignal you will see if any Emacs Lisp error occurs. I suspect you will find there is none; I suspect that Windows truncates the file name without complaining. * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of CH Robinson. CH Robinson accepts no liability for any damage caused by any virus transmitted by this email. CH Robinson Worldwide, 8100 Mitchell Road, Eden Prairie, MN, USA * ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CUA/delete-selection-mode and remapped keys incompatibility
Maybe it could be improved by making self-insert-command output a warning if the region is active and delete-selection-mode is activated as well. That's a dead end -- delete-selection-mode is not enabled when you use CUA, so it would have to check for CUA-mode too, and so would self-insert-iso, and numerous other commands. The implementation I'm imagining would be basically as follows: cua-mode (and delete-selection-mode) add a (global) before-change-function which outputs this warning. This would be modular and catch all cases I can think of, but maybe it would catch more than we'd want. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
Which creates an empty file named Test at 12 and no error occurs. Initially I didn't notice that the filename was truncated. Once I did I realized that : is illegal in a file name. Some kind of error must be occurring that isn't being reported. If you run under a debugger with a breakpoint at Fsignal you will see if any Emacs Lisp error occurs. I suspect you will find there is none; I suspect that Windows truncates the file name without complaining. foo:bar is a special thingy under WinNT (or maybe under NTFS), kind of like a fork in MacOS speech. It seems it's called stream. Maybe Emacs should warn the user that she's about to use a little-known corner of her OS semantics. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Org-mode agenda and category text-property.
Since category is documented as special: `category' If a character has a `category' property, we call it the category of the character. It should be a symbol. The properties of the symbol serve as defaults for the properties of the character. I guess it's an Org-mode bug. Yes, but I also think it's a bug in describe-text-properties, because it shouldn't burp on it. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
On 2/9/07, Stefan Monnier [EMAIL PROTECTED] wrote: foo:bar is a special thingy under WinNT (or maybe under NTFS), kind of like a fork in MacOS speech. It seems it's called stream. NTFS. http://msdn2.microsoft.com/en-us/library/aa364404.aspx /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
Stefan Monnier wrote: Which creates an empty file named Test at 12 and no error occurs. Initially I didn't notice that the filename was truncated. Once I did I realized that : is illegal in a file name. Some kind of error must be occurring that isn't being reported. If you run under a debugger with a breakpoint at Fsignal you will see if any Emacs Lisp error occurs. I suspect you will find there is none; I suspect that Windows truncates the file name without complaining. foo:bar is a special thingy under WinNT (or maybe under NTFS), kind of like a fork in MacOS speech. It seems it's called stream. Maybe Emacs should warn the user that she's about to use a little-known corner of her OS semantics. Yes, please. We have been discussing this before. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CUA/delete-selection-mode and remapped keys incompatibility
On 9 Feb 2007, at 15:12, Stefan Monnier wrote: The implementation I'm imagining would be basically as follows: cua-mode (and delete-selection-mode) add a (global) before-change- function which outputs this warning. This would be modular and catch all cases I can think of, but maybe it would catch more than we'd want. Why do you want to bother the end user with such a warning? As of now, the developer of a package such as SLIME would have a look at what a key is bound to. They find `self-insert-command' and then construct a function that calls this function with the same argument. If they are clever, they might even use call-interactively. At that point, they believe that self-insert-command when called from their function does exactly the same thing as when called (really) interactively. This is a reasonable assumption in a functional environment. And in fact, people write such code, as demonstrated. (I believe the real issue has to do with `last-command'...) The immediate solution to this is to document the necessary annotation of functions in the right place. Where? Maybe along with `self-insert-command' - I don't really know. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
On 2/9/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, please. We have been discussing this before. Yes, and I think we decided that doing nothing was the best course of action. I still agree. There's nothing wrong with streams. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
TRAMP: error in tramp-handle-file-exists-p
I was just using TRAMP to access a remote machine. Something went wrong with the network connection, and things started locking up. Eventually, I saw this error: Debugger entered--Lisp error: (wrong-type-argument stringp nil) format(nil /home/dooglus/public_html/gaim/) tramp-handle-file-exists-p(/scp:lukhas:/home/dooglus/public_html/gaim/) apply(tramp-handle-file-exists-p /scp:lukhas:/home/dooglus/public_html/gaim/) tramp-sh-file-name-handler(file-exists-p /scp:lukhas:/home/dooglus/public_html/gaim/) apply(tramp-sh-file-name-handler file-exists-p /scp:lukhas:/home/dooglus/public_html/gaim/) tramp-file-name-handler(file-exists-p /scp:lukhas:/home/dooglus/public_html/gaim/) file-exists-p(/scp:lukhas:/home/dooglus/public_html/gaim/) tramp-handle-file-attributes(/scp:lukhas:/home/dooglus/public_html/gaim/) apply(tramp-handle-file-attributes /scp:lukhas:/home/dooglus/public_html/gaim/) tramp-sh-file-name-handler(file-attributes /scp:lukhas:/home/dooglus/public_html/gaim/) apply(tramp-sh-file-name-handler file-attributes /scp:lukhas:/home/dooglus/public_html/gaim/) tramp-file-name-handler(file-attributes /scp:lukhas:/home/dooglus/public_html/gaim/) file-attributes(/scp:lukhas:/home/dooglus/public_html/gaim/) dired-directory-changed-p(/scp:lukhas:/home/dooglus/public_html/gaim/) dired-internal-noselect(/scp:lukhas:/home/dooglus/public_html/gaim/ nil) dired-noselect(/scp:lukhas:/home/dooglus/public_html/gaim/ nil) dired-other-window(/scp:lukhas:/home/dooglus/public_html/gaim/ nil) call-interactively(dired-other-window) tramp-handle-file-exists-p makes this call: (format (tramp-get-file-exists-command multi-method method user host) (tramp-shell-quote-argument localname)) It seems that tramp-get-file-exists-command is capable of returning nil, which is passed as the first argument to format, which format doesn't like. We need to either check the return from tramp-get-file-exists-command before passing it to format, or change tramp-handle-file-exists-p to stop it returning nil in some cases. In GNU Emacs 22.0.93.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
From: Stefan Monnier [EMAIL PROTECTED] Date: Fri, 09 Feb 2007 10:19:16 -0500 Cc: emacs-pretest-bug@gnu.org, Richard Bielawski [EMAIL PROTECTED] Maybe Emacs should warn the user that she's about to use a little-known corner of her OS semantics. Yes, I think we should add a warning and an option to shut up that warning. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
